Data transmission in energy saving state

Abstract

The present disclosure relates to methods, systems, and devices related to digital wireless communications, and more particularly to techniques related to data transmission in energy saving states. In one example aspect, a method for wireless communication is disclosed. The method includes sending, by a terminal in a first state, a first message to a network node to initiate a data communication resumption procedure to the network node. The method also includes monitoring, after sending the first message, a control channel with a network temporary identifier for a response to the first message.

Description

Technical Field

[0001] This patent document generally relates to wireless communication. Background Technology

[0002] Mobile communication technology is leading the world towards an increasingly interconnected and networked society. The rapid growth and technological advancements in mobile communications have resulted in greater demands for capacity and connectivity. Other factors, such as energy consumption, equipment cost, spectrum efficiency, and latency, are also important in meeting the needs of various communication scenarios. Various technologies, including new ways to provide higher quality of service, are currently under discussion. Summary of the Invention

[0003] This document discloses methods, systems, and apparatuses related to digital wireless communication, and more specifically relates to techniques related to data transmission in energy-saving states.

[0004] In one exemplary aspect, a method for wireless communication is disclosed. The method includes: sending a first message from a terminal in a first state to a network node to initiate a data communication recovery process to the network node. The method further includes: after sending the first message, monitoring a control channel having a network temporary identifier in response to the first message.

[0005] In another exemplary aspect, a method for wireless communication is disclosed. The method includes receiving, by a network node, a first message from a terminal in a first state for initiating a data communication recovery process. The method further includes: the network node sending a response to the first message to a terminal monitoring a control channel having a network temporary identifier in response to the response to the first message.

[0006] In another exemplary aspect, a wireless communication device including a processor is disclosed. The processor is configured to implement the methods described herein.

[0007] In yet another exemplary aspect, the techniques described herein can be embodied in processor-executable code and stored on a computer-readable program medium.

[0008] Details of one or more implementations are set forth in the accompanying appendices, figures, and description below. Other features will be apparent from the description and figures, as well as from the terms and conditions. Attached Figure Description

[0009] Figure 1 This is an example signaling process used to release inactive data transmissions of the RRC after data transmission is complete.

[0010] Figure 2 This is an example signaling process that demonstrates inactive data transmission involving RRC and RRC release before data transmission begins.

[0011] Figure 3 This is an example signaling procedure for inactive data transmission that does not involve RRC.

[0012] Figure 4 This is an example signaling process for inactive data transmission that does not involve RRC.

[0013] Figure 5 This is an example of signaling processing for anchor point relocation, where data is buffered in the target node.

[0014] Figure 6 This is an example signaling process used for data forwarding in place of anchor point relocation.

[0015] Figure 7 This is a block diagram of an example method for data transmission in an energy-saving state.

[0016] Figure 8 An example of a wireless communication system in which one or more embodiments of the present technology can be applied is shown.

[0017] Figure 9 It is a block diagram representation of a part of a hardware platform. Detailed Implementation

[0018] The development of next-generation wireless communication—5G New Radio (NR)—is part of the ongoing evolution of mobile broadband to meet ever-increasing network demands. NR will offer greater throughput to allow more users to connect simultaneously. Other aspects, such as energy consumption, equipment cost, spectrum efficiency, and latency, are also important for meeting the needs of various communication scenarios.

[0019] The RRC_INACTIVE state is introduced to provide an energy-saving state with low CP latency. For various services, such as those involving devices with variable data, short control plane (CP) latency may be required because the device may need to report when anomalies are detected. Additionally, the UE can be configured to be in the RRC_INACTIVE state while considering power consumption. Furthermore, in many cases, the device can periodically handle small data transmissions in addition to video transmissions when anomalies are detected.

[0020] However, for UEs in the RRC_INACTIVE state, since the current standard does not support stateless data transmission, the UE must first enter the RRC_CONNECTED state and then initiate data transmission whenever it has data to transmit. This requirement to enter the RRC_CONNECTED state to send or receive data can result in considerable signaling overhead and may not meet the requirements of SA1 for 3GPP systems to support efficient signaling mechanisms (e.g., signaling overhead can be less than the data payload requirements). This problem can be particularly severe when data packets are small and infrequent.

[0021] The NR can support the RRC_INACTIVE state, and UEs with infrequent (periodic and / or non-periodic) data transmissions are typically maintained by the network in the RRC_INACTIVE state. The RRC_INACTIVE state may not support data transmission. Therefore, the UE can initially restore the connection for any downlink (DL) (MT) and uplink (UL) (MO) data transmission (i.e., move to the RRC_CONNECTED state). For each data transmission, regardless of how small and infrequent the data packets are, connection restoration and subsequent release to an inactive state may occur. This can lead to unnecessary power consumption and signaling overhead.

[0022] Examples of small and infrequent data traffic can include smartphone applications. Smartphone applications can include traffic from instant messaging services, heartbeat / keep-alive traffic from instant messaging (IM) / email clients and other applications, push notifications from various applications, etc. Another example of small and infrequent data traffic can include non-smartphone applications. Non-smartphone applications can include traffic from wearable devices (e.g., periodic location information), sensors (e.g., industrial wireless sensor networks that periodically or event-triggeredly transmit temperature and pressure readings), smart meters, and smart meter networks that send periodic meter readings, etc.

[0023] For low-throughput, short data bursts, NR systems can be efficient and flexible, supporting efficient signaling mechanisms (e.g., signaling less than payload), reducing overall signaling overhead, and so on. Signaling overhead from inactive UEs can be a common problem for small data packets, and for more UEs in NR, it can become a critical issue not only for network performance and efficiency but also for UE battery performance. Generally, any device with intermittent small data packets in an inactive state can benefit from enabling small data transmission during inactivity.

[0024] In many cases, key enablers for small data transmission in NR may have already been specified, namely the inactive state, 2-step, 4-step RACH, and configuration authorization type 1. Therefore, this embodiment enables data transmission in the inactive state of NR.

[0025] System overview

[0026] This embodiment relates to data transmission in an inactive state. The data transmission process described herein is primarily applicable to idle (IDLE) and / or inactive states. In the following description, the inactive state is used as an illustrative example. It should be noted that this embodiment can also be applied to the IDLE state. Furthermore, this embodiment can be further extended to any power-saving state where UL synchronization is not maintained on the UE and NW sides. In addition, in the following description, a single-connectivity scenario (e.g., NR standalone or LTE standalone) can be used as an illustrative example. This embodiment can also be further extended to EN-DC, MR-DC, LTE-DC, NR-DC, and / or multi-connectivity scenarios, in which case both MCG and SCG can be configured as UEs, and based on the configuration from the network side, inactive data transmission can be applied to the MCG (primary cell group) and / or SCG (secondary cell group).

[0027] The process described herein can combine a 2-step Random Access Channel (RACH) procedure and / or a 4-step RACH procedure. The payload of MsgA in a 2-step RACH can be carried in Msg3 in a 4-step RACH, and / or the payload carried in MsgB in a 2-step RACH can be carried in Msg4 in a 4-step RACH. In a 2-step RACH, the contention resolution ID can be included in MsgB, but in a 4-step RACH, the contention resolution ID can be included in Msg4.

[0028] Example embodiment 1

[0029] In the first example embodiment, several alternatives may be disclosed. A first alternative may include an RRC-related solution that releases the RRC after data transmission is complete. A second alternative may include an RRC-related solution that releases the RRC before data transmission ends. A third alternative may include a solution that does not involve RRC messages.

[0030] In the first alternative, the UE can determine that it needs to initiate data transmission while inactive. The UE can initiate an RRC recovery request procedure. In some embodiments, the data PDU and / or MAC SDU can be within the same MAC PDU.

[0031] In a CG-based solution, the UE can directly send an RRC recovery request message via CG resources, optionally including data PDU and / or MAC SDU packets. Once the message is sent, the UE can monitor the PDCCH using a known cell-specific UE identifier such as the C-RNTI. The C-RNTI can be configured (i.e., via the network) in advance by the UE (i.e., during the period when the UE is in the RRC_CONNECTED state earlier), or configured by the network when the UE enters an inactive state (e.g., the C-RNTI for subsequent recovery procedures is included by the network in an RRC release message, which is the message that causes the UE to enter an inactive state).

[0032] In a two-step RACH-based solution, the first step may include the UE initiating a RACH procedure and sending an RRC recovery request message via MsgA, optionally including a data PDU and / or MAC SDU. Once MsgA is sent, the second step may include the UE receiving MsgB. Once MsgB is successfully received, the UE can monitor the PDCCH using the C-RNTI included in MsgB or using the pre-configured C-RNTI as described above.

[0033] The UE can perform UL / DL data transmission based on a permission received on the PDCCH with the corresponding C-RNTI. Once an RRC release message is received, the UE can stop monitoring the PDCCH addressed to the C-RNTI and discard the C-RNTI.

[0034] Figure 1 This is an example signaling process 100 used to release inactive data transmissions of RRC after data transmission is complete. Figure 1 This corresponds to the first alternative as described above.

[0035] like Figure 1 As shown, in step 106a, the RACH-based solution may include MsgA with an RRC recovery request from UE 102 to gNB 104. In step 106a, the UE may also optionally include a data PDU and / or a MAC SDU. The RACH-based solution may also include MsgB with contention resolution from gNB 104 to UE 102 in step 108. In step 106b, the first message may include MsgA with an RRC recovery request from UE 102 to gNB 104.

[0036] In step 110, gNB 104 may send data transmission scheduled by C-RNTI to UE 102. In step 112, UE 102 may send data transmission scheduled by C-RNTI to gNB 104. In step 114, gNB 104 may send an RRC release message to UE 102.

[0037] In another embodiment, the UE can use a timer to determine when to discard the C-RNTI and / or enter a normal inactive state. This timer can be configured by the network and sent to the UE via a signal. In a first alternative, the timer can be configured in an RRC reconfiguration message (e.g., before the UE enters an inactive state). In a second alternative, the timer can be configured in an RRC release message (e.g., when the UE enters an inactive state). In a third alternative, the timer can be configured in system information related to the data transmission.

[0038] A timer can be used to control the duration of inactive data transmission. In the first alternative, the timer can be started once an RRC recovery message is generated or sent. In the second alternative, the timer can be started once the MAC layer transmits the RRC recovery message to the lower layer. In the third alternative, the timer can be started once MsgB is received during a 2-step RACH process. In the fourth alternative, the timer can be started once Msg4 or MAC RAR corresponding to the UE is received during a 4-step RACH process. In the fifth alternative, the timer can be started once a PDCCH addressed to C-RNTI is received. In the sixth alternative, the timer can be a time calibration timer or a new timer specifically for inactive data transmission.

[0039] The timer can be stopped whenever an RRC release is received. If the timer expires, the UE can discard the C-RNTI, stop monitoring the PDCCH with the C-RNTI, and / or suspend the DRB and / or PDCP.

[0040] A second alternative could include a solution involving RRC that releases the RRC before the data transmission ends. In the first alternative to the RACH-based solution, when the UE initiates an RRC recovery request procedure, the UE can initiate a RACH procedure and send an RRC recovery request message via MsgA, optionally including a data PDU or MAC SDU. Once MsgA is sent, in addition to a successful RAR (e.g., contention resolution ID, C-RNTI, etc.), the UE can also receive MsgB, and an RRC connection release message can be sent to the UE (either in MsgB or after MsgB in DL scheduling).

[0041] In some embodiments, a 4-step RACH procedure is used, and the UE may initiate the RACH procedure first and send a preamble. Once the preamble is sent, the UE can monitor the PDCCH addressed to the RA-RNTI to receive the MAC RAR. Once the MAC RAR is received, the UE can send Msg3 (which may include an RRC recovery request message and optionally a data PDU or MAC SDU) based on the UL clearance received in the MAC RAR. Once Msg3 is sent, the UE can monitor the PDCCH addressed to the C-RNTI or temporary C-RNTI included in the MAC RAR for the reception of Msg4. Once Msg4 is received, if the CCCH message is included in Msg3, the UE can perform contention resolution based on the contention resolution ID included in Msg4. If the C-RNTI is included in Msg3, the C-RNTI can be used in the reception of Msg4 (e.g., monitoring the PDCCH addressed to the C-RNTI).

[0042] Although various messages such as the RRC recovery request message are identified in this embodiment, this embodiment is not limited to using such messages. For example, this embodiment can utilize the terminal's RRC setting request message in idle mode, and can also use the RRC recovery request message in idle mode.

[0043] In another alternative, before the timer expires, the network can send a message to the UE that can extend the timer or cause the UE to move to the RRC_CONNECTED state. This message, which would cause the UE to extend its timer, can be sent from the network to the UE using a MAC CE or an RRC message (such as an RRC connection message). Once such a message is received, the UE can extend the timer and remain in its state of continuing to monitor C-RNTI for a longer period, or move to the RRC_CONNECTED state. The network can determine to send such a message to extend the timer or move the UE to the RRC_CONNECTED state based on observed traffic patterns from the UE or based on the arrival of DL (MT) traffic, etc.

[0044] In a second alternative that includes a CG-based solution, the UE can directly send RRC recovery request messages via CG resources, optionally including data packets.

[0045] Once the message is sent, the UE can use the C-RNTI to monitor the PDCCH. The C-RNTI can be configured to the UE before or during the inactive state. Upon successful receipt of an RRC connection release and based on the received message, the UE should handle inactive data transmission. An inactive data transmission timer can then be started, and the UE can use the C-RNTI to monitor the PDCCH until the inactive data transmission timer expires. The timer can be restarted whenever a PDCCH schedule with a C-RNTI is received.

[0046] In an alternative solution, instead of an inactive data transmission timer, a time calibration timer can be used to control inactive data transmission. In this case, while the time calibration timer is running, the UE will monitor the PDCCH addressed to the C-RNTI. The time calibration timer can be started or restarted whenever a timing advance command is received. Alternatively, in addition to the inactive data transmission timer, a time calibration timer can also be used to control inactive data transmission. In this case, while both the inactive data transmission timer and the time calibration timer are running, the UE can monitor the PDCCH addressed to the C-RNTI.

[0047] The UE can process UL / DL transmissions based on a permission received on the PDCCH with the corresponding C-RNTI. Once the inactive data transmission timer and / or time calibration timer expires, the UE can stop monitoring the PDCCH using the C-RNTI, discard the C-RNTI, and / or suspend the DRB and / or PDCP. If the UE receives a data transmission stop indicator, which can be a MAC layer command (e.g., MAC CE), a physical layer command (e.g., DCI), or a PDCP-level command (e.g., PDCP control PDU), the UE can stop monitoring the PDCCH using the C-RNTI, discard the C-RNTI, and / or suspend the DRB and / or PDCP.

[0048] Figure 2 This is example signaling processing 200, demonstrating inactive data transmission involving RRC and RRC release before data transmission begins. (Example:) Figure 2 As shown, in the RACH-based solution, UE 202 can send MsgA with RRC recovery request 206 to gNB 204. gNB 204 can send MsgB with RRC connection release 208 to UE 202.

[0049] In the CG-based solution, UE 202 can send an RRC recovery request 210 to gNB 204 via CG resources. gNB 204 can send an RRC connection release 212 scheduled by C-RNTI to UE 202.

[0050] In step 214, the UE may start an inactive data transmission timer and begin monitoring C-RNTI. In step 216, gNB 204 may send the data transmission scheduled by C-RNTI to UE 202. In step 218, UE 202 may send the data transmission scheduled by C-RNTI to gNB 204.

[0051] While the C-RNTI can be used as an example temporary radio network identifier scheduled by a network node (e.g., a gNB), the temporary radio network identifier can include other identifiers, such as the I-RNTI or another RNTI assigned by the network or selected by the UE from a pool of RNTIs, which is configured by the network, for example, via dedicated signaling for system information. Furthermore, while a gNB can be used as an example network node, this embodiment is not limited to such instances. For example, the network node can include an eNB.

[0052] In step 220, once the timer expires, the UE can discard the C-RNTI and enter a normal inactive state. In step 222, gNB 204 can send a MAC CE with a release indication to UE 202. Alternatively, once the time calibration timer expires, the UE can discard the C-RNTI and / or stop monitoring the PDCCH addressed to the C-RNTI. In a normal inactive state, the UE may not need to monitor the PDCCH addressed to the C-RNTI.

[0053] The duration of a timer can be configured for the UE (e.g., an inactivity data transmission timer and / or a time calibration timer). In a first alternative, the timer can be configured in the RRC reconfiguration message (e.g., before the UE enters an inactive state). In a second alternative, the timer can be configured in the RRC release message (e.g., when the UE enters an inactive state). In a third alternative, the timer can be configured in the system information for performing data transmission.

[0054] A third alternative may include inactive data transmission that does not involve RRC. In the first alternative to the RACH-based solution, to determine whether to initiate inactive data transmission, the UE may initiate a RACH procedure, including a MAC PDU with an I-RNTI or C-RNTI in MsgA, and optionally a data PDU and / or MAC CE. Once MsgA is sent, the UE can receive MsgB. If the I-RNTI is included in MsgA, the UE can monitor the PDCCH addressed to the RA-RNTI (or MsgB RNTI) for MsgB reception, and the I-RNTI in MsgB can be used for contention resolution. If the C-RNTI is included in MsgA, the UE can monitor the PDCCH addressed to the C-RNTI for MsgB reception.

[0055] In a second alternative to the CG-based solution, the UE can transmit UL data packets via CG resources. Once the CG resources are transmitted, the UE can monitor the PDCCH addressed to the C-RNTI, which can be configured to the UE before or during the UE's inactivity state.

[0056] Once MsgB is successfully received (for RACH-based solutions), or an initial UL transmission with CG resources is sent (for CG-based solutions), an inactive data transmission timer can be started, and the UE can monitor the PDCCH addressed to the C-RNTI until the inactive data transmission timer expires. The UE can then process UL / DL transmissions based on the permission received on the PDCCH with the corresponding C-RNTI.

[0057] In one alternative, instead of an inactive data transmission timer, a time calibration timer can be used to control inactive data transmission. In this case, while the time calibration timer is running, the UE can monitor the PDCCH addressed to the C-RNTI. The time calibration timer can be started or restarted whenever a timing advance command is received. Alternatively, in addition to the inactive data transmission timer, a time calibration timer can also be used to control inactive data transmission. In this case, while both the inactive data transmission timer and the time calibration timer are running, the UE will monitor the PDCCH addressed to the C-RNTI.

[0058] Once the inactive data transmission timer or time calibration timer expires, the UE can stop using C-RNTI to monitor PDCCH, discard the C-RNTI, and / or suspend DRB and / or PDCP.

[0059] If the UE receives a data transmission stop indicator, which can be a MAC layer command (e.g., MAC CE), a physical layer command (e.g., DCI), or a PDCP level command (e.g., PDCP control PDU), the UE can stop using C-RNTI to monitor PDCCH, discard C-RNTI, and / or suspend DRB and / or PDCP.

[0060] Figure 3 This is an example signaling procedure 300 for inactive data transmission that does not involve RRC. In step 306, in a RACH-based solution, UE 302 may send MsgA with I-RNTI and MAC PDU to gNB 304. In step 308, gNB 304 may send MsgB with I-RNTI for contention resolution to UE 302. In a CG-based solution, UE 302 may send data to gNB 304 via CG resource 310.

[0061] In step 312, UE 302 may declare an inactive data transmission timer and begin monitoring the C-RNTI. In step 314, gNB 304 may send the data transmission scheduled by the C-RNTI to UE 302. In step 316, UE 302 may send the data transmission scheduled by the C-RNTI to gNB 304. In step 318, once the timer expires, UE 302 may discard the C-RNTI and enter a normal inactive state. In step 320, gNB 304 may send a MAC CE with a release indication to UE 302.

[0062] In some embodiments, the inactive data transfer timer is restarted whenever a PDCCH addressed to C-RNTI is received and / or whenever a UL or DL ​​license for a new transfer is received.

[0063] Example embodiment 2

[0064] The second example embodiment relates to data forwarding. Data forwarding can be used when the target gNB (where inactive data transmission is performed) differs from the source gNB (where the UE enters an inactive state).

[0065] In order to perform data forwarding, whenever the first NW node receives a data packet from the UE, the first NW node can forward the received data packet to the second NW node.

[0066] The first NW node can forward data packets in a control plane solution, which includes data packets in containers that may be included within XnAP or XnAP messages. The first NW node can also forward data packets in a user plane-based solution, which includes data packets that can be forwarded to the source node via a GTP tunnel, wherein the GTP tunnel can be a public GTP tunnel that can be shared by multiple tunnels, or a UE-dedicated tunnel.

[0067] Using data packets, I-RNTI and / or cell ID and / or PCI can be forwarded together with the data packets. For UP-based solutions, I-RNTI and / or cell ID and / or PCI can be included in the header of user plane packets or in the control frames of user plane packets.

[0068] In this alternative, a release request or end marker can be sent from the destination node to the source node to notify the end of inactive data transmission. The release request or end marker can be sent from the source node to the destination node to notify the end of inactive data transmission. The release request or end marker can be sent in control plane signaling (e.g., XnAP signaling) or in user plane packets (e.g., in the header of a user plane packet or in a user plane control frame).

[0069] Figure 4 This is an example signaling process 400 that illustrates inactive data transmission that does not involve RRC. Figure 4 As shown, in step 408, in the RACH-based solution, UE 402 can send MsgA with I-RNTI and MAC PDU to the target gNB 404. In step 410, the target gNB 404 can send MsgB with I-RNTI for contention resolution to UE 402. In step 412, for the CG-based solution, UE 402 can send a data PDU to the target gNB 404 via CH resources.

[0070] In step 414, the source gNB 406 can perform data forwarding to the target gNB 404. The target gNB 404 can perform data forwarding to the source gNB 406 in step 416. In step 418, the UE can start an inactive data transmission timer and begin monitoring C-RNTI.

[0071] In step 420, the target gNB 404 may send the data transmission scheduled by the C-RNTI to the UE 402. In step 422, the UE 402 may send the data transmission scheduled by the C-RNTI to the target gNB 404. In step 424, once the timer expires, the UE 402 may discard the C-RNTI and enter a normal inactive state. In step 426, the source gNB 406 may send a release request to the target gNB 404. In step 428, the target gNB 404 may send a release indication to the source gNB 406. In step 430, the target gNB 404 may send a MAC CE with a release indication to the UE 402.

[0072] Example embodiment 3

[0073] The third example embodiment may involve anchor point relocation. For inactive data transmission involving RRC, anchor point relocation can be supported due to the involvement of the control plane. In the first alternative, the UE can fall back to the recovery procedure, where both UE-based and NW-based solutions can be considered. In the first alternative, a region range can be configured for the UE, and the UE can be allowed to initiate inactive data transmission only within the configured region (e.g., configuring cells belonging to the same DU within the region). If we restrict inactive data transmission to cells where the UE enters an inactive state, a region range may not be necessary.

[0074] In the second alternative, the UE can initiate a recovery procedure using an RRC recovery request, and the NW can determine whether to use inactive data transmission or reconfigure the UE to the RRC_CONNECTED state. During this process, the NW can configure a PDCP recovery / reconstruction procedure to trigger the retransmission of a PDCP PDU, which is transmitted along with the RRC recovery request message (if any).

[0075] In the second alternative, the target node can buffer the received data and process it after the context extraction process. During this process, a new RLC entity can be established accordingly, and once the new RLC is established, the buffered data will be processed. The RLC configuration can be the same as the RLC configuration used in the source node.

[0076] Figure 5This is an example signaling process 500 for anchor point relocation, where data is buffered in the target node. In step 510, in the RACH-based solution, UE 502 can send MsgA with an RRC recovery request to the target gNB 504. In step 512, the target gNB 504 can send MsgB with contention resolution to UE 502. In step 514, in the CG-based solution, UE 502 can send an RRC recovery request to the target gNB 504 via CG resources.

[0077] In step 516, the target gNB 504 can buffer the received data. In step 518, the target gNB 504 can send a UE context retrieval request to the source gNB 506. In step 520, the source gNB 506 can send a UE context retrieval response to the target gNB 504. In step 522, the target gNB 504 can establish the UE context in the CU / DU and process the buffered data.

[0078] In step 524, the target gNB 504 may send a path handover request to AMF 508. In step 526, AMF 508 may send a path handover request confirmation to the target gNB 504. In step 528, the target gNB 504 may send a UE context release 528 to the source gNB 506. In step 530, the target gNB 504 may send data transmissions scheduled by C-RNTI to UE 502. In step 532, UE 502 may send data transmissions scheduled by C-RNTI to the target gNB 504. In step 534, the target gNB 504 may send an RRC release to UE 502.

[0079] In the third alternative, data forwarding can be used instead of anchor relocation. In this process, the target node can forward the received RRC recovery request message and data packets to the source node.

[0080] The source node can indicate whether context relocation is required. If context relocation is not required, data forwarding can be performed instead. In the first alternative, the new RLC entity can always be established in the gNB (or in the DU of the gNB) for inactive data transmission, and a default configuration can be used for the established RLC entity, which can be specified in the protocol or broadcast in system information. Since both AM and UM RLCs can be supported, alternatively, the target node may still need to know the configured RLC type from the source node through a context retrieval procedure or based on an RLC type indication sent from the UE (e.g., in UL MAC CE).

[0081] A second alternative may include identifying RLC entities in the gNB (or the gNB's CU) for inactive data transmission. A third alternative may include introducing AM-like functionality (e.g., polling-based retransmission and status reporting) into the PDCP.

[0082] Data packets can be forwarded via the Xn interface or via a GTP tunnel established for user plane data forwarding. If data packets can be forwarded on the Xn interface via XnAP messages, the target node can forward the data packets directly to the source node along with a recovery request message. If a GTP tunnel is used, the tunnel can be UE-dedicated or cell-dedicated (i.e., a public tunnel shared by all UEs for inactive data transmission).

[0083] Both the source and destination nodes can initiate the release of inactive data transmissions. The destination node can initiate the release by sending a transmission end indication.

[0084] Figure 6 This is an example signaling process 600 used for data forwarding in place of anchor point relocation. (Example:) Figure 6 As shown, in step 608 of the RACH-based solution, UE 602 can send MsgA with an RRC recovery request to the target gNB 604. In step 610, the target gNB 604 can send MsgB with contention resolution to UE 602. In step 612, in the CG-based solution, UE 602 can send an RRC recovery request to the target gNB 604 via CG resources.

[0085] In step 614, the target gNB 604 can buffer the received data. In step 616, the target gNB 604 can send a UE context retrieval request to the source gNB 606. In step 618, the source gNB 606 can send a UE context retrieval response to the target gNB 604. In step 620, the target gNB 604 can establish a UE context in the DU. In step 622, the target gNB 604 can perform data forwarding to the source gNB 606. In step 624, the source gNB 606 can perform data forwarding to the target gNB 604.

[0086] In step 626, the target gNB 604 may send data transmission scheduled by C-RNTI to the UE 602. In step 628, the UE 602 may send data transmission scheduled by C-RNTI to the target gNB 604. In step 630, the target gNB 604 may send a transmission end indication to the source gNB 606. In step 632, the source gNB 606 may send a UE context release to the target gNB 604. In step 634, the target gNB 604 may send an RRC release to the UE 602.

[0087] Example embodiment 4

[0088] The fourth example embodiment may involve transmission type selection. In the procedure section, RACH-based and CG-based solutions can be discussed. Similarly, considering the conventional RRC recovery procedure, whenever the UE has available data in the buffer, the UE may need to determine the transmission type, including any of the following: RACH-based solution, CG-based solution, conventional RRC recovery procedure, RRC-involved procedure, and / or non-RRC-involved procedure.

[0089] Regarding the selection of the transmission type, any of the following scenarios can be considered: Initial transmission type selection: The UE can perform the initial transmission type selection whenever it determines to initiate data transmission based on the detection of UL data arrival. Transmission type switching can occur during inactive data transmission whenever the UE or NW determines that the criteria for inactive data transmission are no longer met, and the UE will be switched to connected mode and perform normal UL transmission.

[0090] The first process may include initial transport type selection.

[0091] For the initial transmission type selection, consider any of the following: whether inactive data transmission is allowed in the cell, whether inactive data transmission is suitable for ongoing services, and / or whether it supports both processes involving / not involving RRC, and which one should be used.

[0092] The second process may include determining whether inactive data transmission is permitted in a cell. The UE can determine whether inactive data transmission is permitted in a cell (and / or what type of inactive data transmission is permitted) by indications from system information or dedicated signaling. The following alternatives may also be considered:

[0093] A first alternative may include indicators in the system information. The system information may include one or more indicators to indicate whether "data transmission in an inactive state" is permitted in the cell. And if the indicator is set to true, the UE may initiate only "data transmission in an inactive state".

[0094] The indicator can be included in the system information. The indicator can be given by cell, by PLMN, or by RAN notification area. There can be multiple indicators, and each indicator is associated with a transmission type.

[0095] A second alternative may include indicators in dedicated signaling. One (e.g., for each UE) and / or multiple (e.g., for each transmission type) indicators may be included in dedicated RRC signaling to indicate whether “data transmission in an inactive state” is permitted for the UE.

[0096] The indicator can be introduced in dedicated RRC signaling. There can be multiple indicators, and each indicator is associated with a transport type.

[0097] In the third alternative, the area range can be configured in dedicated signaling. The area range can be configured for the UE via dedicated signaling, and "inactive data transmission" (e.g., area range configured for each UE) or a specific type of inactive data transmission (e.g., area range configured for each transmission type) can be permitted only within the configured area range. The area range can be a cell or a list of cells, an RNA or a list of RNAs. The dedicated RRC message can be signaling used to push the UE into an inactive efficient state, or a dedicated RRC message prior to the UE entering an inactive state. The RRC message can be an RRC reconfiguration or RRC release.

[0098] A region range can be introduced in RRC signaling. The region range can be for each UE or for each transmission type.

[0099] In the fourth alternative, an indicator for each cell is introduced within the RAN notification area. The area of ​​the RAN notification area can be given by a cell list. For each cell in the cell list of the RAN notification area, one (e.g., for each UE) or more (for each transmission type) indicators can be introduced to indicate whether "data transmission in an inactive state" is permitted in that cell. One or more indicators can be introduced into the cell information of the cell list, which can be used to configure the area of ​​the RAN notification area. These indicators can be used to indicate whether "data transmission in an inactive state" is permitted in that cell.

[0100] A fifth alternative could be based on resource configuration. Inactive data transmission is only permitted if the configuration and / or resources are configured in the cell. These resources and / or configurations can be provided by system information or dedicated RRC messages. Furthermore, in addition to resource configuration, some kind of verification rule can be defined. A specific type of inactive data transmission can only be permitted if there are valid resources for the transmission type. For example, a CG-based solution can only be used if a valid PUSCH configuration exists in the cell and a valid TA is maintained on the UE side.

[0101] The indicators mentioned above can be explicit or implicit. For implicit indicators, they can be derived from resources configured for inactive transmissions (e.g., once resources for a specific transmission type are configured, the UE can assume that the transmission type is supported and / or allowed).

[0102] A first example could include broadcasting an indicator in system information to indicate whether inactive data transmission is permitted in the cell. An indicator could be configured for the UE to indicate whether inactive data transmission is permitted for that UE.

[0103] With these two indicators, the UE can only initiate inactive data transmission if inactive data transmission is permitted within the cell according to the indication in the system information and the UE is also permitted inactive data transmission according to the indication configured in the dedicated signaling.

[0104] A second example could include: if a valid CG resource is configured, the UE can select the CG resource; otherwise, if inactive data transmission based on RACH is permitted, the UE should initiate a RACH procedure.

[0105] In this example, the validity of a CG can be determined based on any of the following: whether CG resources are configured and / or stored, whether valid CG resources can be found on a qualified beam (e.g., valid CG resources can be found on an SSB with quality higher than a pre-configured threshold, which can be configured in system information or in dedicated signaling), whether the configured and / or stored CG resources are permitted for inactive transmissions, whether a valid TA is maintained on the UE side (e.g., TAT is running on the UE side), and / or whether inactive data transmission is suitable for ongoing services.

[0106] Even if inactive data transmission is supported / permitted in a cell, ongoing services should be considered when selecting the transmission type, and the following information can be taken into account.

[0107] The buffer size for UE-side data. To achieve this, a buffer size threshold can be configured for the UE in system information or dedicated signaling. The buffer size threshold can be given for each UE or each logical channel, or for each logical channel group or the sum of the buffer sizes of LCHs (Logical Channels) or LCGs (Logical Channel Groups) that allow inactive data transmission. Once the UE-side buffer size is less than (less than or equal to) the threshold, the UE is allowed to initiate data transmission under RRC_INACTIVE; otherwise, the UE should initiate a conventional RRC recovery procedure (e.g., a state transition first). If a buffer size is defined for each logical channel or logical channel group, and a buffer is not included for a logical channel or logical channel group, then data buffered in such a logical channel or logical channel group will initiate a conventional RRC recovery procedure (e.g., for data transmission with a state transition, the UE or NW will directly trigger the state transition procedure, and the UE can send an RRC establishment request or RRC recovery request message to the NW to initiate the state transition). Alternatively, if no buffer size is configured, data transmission under RRC_INACTIVE is not allowed, and the UE can always initiate a state transition first. In an alternative approach, the buffer size can be configured in both dedicated signaling and system information. If the buffer size is configured in dedicated signaling, the UE can use the value configured in dedicated signaling; otherwise, the UE will use the value configured in system information.

[0108] Logical channel ID (or DRB ID, QoS flow ID, PDU session ID) data is available in the buffer.

[0109] To achieve this, an indicator for each logical channel or logical channel group can be configured for the UE in dedicated signaling (e.g., the indicator can be used to indicate whether data transmission without state transition is allowed for that logical channel or logical channel group) or a bitmap for logical channels or logical channel groups (e.g., the bitmap is used to indicate which logical channels or logical channel groups are allowed for data transmission without state transition). Using this indicator, the UE is allowed to initiate "RRC_INACTIVE data transmission" once buffered data exists on the UE side and all (or any) logical channels / logical channel groups with buffered data are allowed to initiate "RRC_INACTIVE data transmission". This indicator can be modeled as part of the LCP parameters.

[0110] Based on the combination of logical channels and buffer sizes, a new rule can be derived: the total buffer size of a logical channel or logical channel group that allows data transmission without state transitions.

[0111] Based on network configuration, in this option, the network can include an explicit indication in the suspend configuration whether the UE is allowed to use inactive data transmission.

[0112] In the initial transmission type selection method, either a UE-based solution or an NW-based solution can be considered for transmission type selection. In the UE-based solution, the UE can directly select the transmission type and determine whether data packets can be included in Msg3 / MsgA. In the NW-based solution, the UE can include an RRC message that can trigger a state transition in the payload of the RACH procedure or in the CG resources, and the NW can determine whether to initiate a state transition or allow the UE to perform data transmission in inactive mode. To assist the NW's determination, the UE can include auxiliary information in the RRC message, or in the MAC PDU payload of the MAC PDU in Msg3 / MsgA or the MAC CE or MAC header (or subheader). For example, a BSR or an inactive data transmission indication (which will be used to indicate whether the criteria for inactive data transmission are met) can be sent to the NW.

[0113] For transmission type switching, if a CG-based solution is initiated or if CG-based data transmission is configured, the UE may initiate a RACH procedure in any of the following situations: when the TA maintained by the UE is invalid (e.g., TAT expires); when the UE may not receive DL grants (or UL grants or PDCCHs addressed to C-RNTI) for a period of time or within multiple PDCCH opportunities, wherein the timer (for the time period) and / or counter (for the number of PDCCH opportunities) may be configured in system information or dedicated signaling (e.g., RRC reconfiguration messages or RRC release messages before or at the time the UE enters an inactive state); and / or when a qualified beam with CG resources cannot be found (e.g., SSB or CSI-RS), and / or the change of the best beam or the change of the qualified beam is altered, and / or the beam used in the current transmission is no longer valid (e.g., below a threshold that may be configured in system information or dedicated signaling before or at the time the UE enters an inactive state).

[0114] Example embodiment 5

[0115] Example embodiment 5 may involve beam mobility. Beam mobility can refer to the change of beam during inactive data transmission, where the beam refers to SSB or CSI-RS.

[0116] Regarding beam mobility, whenever a beam change is detected during I DT (Inactive Data Transmission), the UE may perform one of the following: initiate a RACH procedure; if there are stored and / or configured CG resources associated with the new beam, the UE may use the CG resources for transmission; and / or generate and / or include beam measurement result information in MAC CE or PHY layer signaling (e.g., UCI).

[0117] Beam change detection can be based on any of the following: a change in the beam (e.g., SSB), the quality of the source beam (or the current serving beam) being higher than a threshold, the quality of the serving beam (or the current serving beam) being lower than a threshold, and / or the quality of the target beam being higher than a threshold and the quality of the source beam (or the current serving beam) being lower than a threshold. The beam can be an SSB or a CSI-RS.

[0118] In some embodiments, the triggering time is also considered in the evaluation, in which case the event is considered to be triggered only if the criteria of the event are met within a period of time, and the period of time is controlled by a timer (e.g., the triggering time).

[0119] In some embodiments, if CG resources are configured for inactive data transmission, then upon detecting a beam change or if the quality of the currently serving beam is below a threshold, the UE may: if any available CG resource associated with an available beam exists (e.g., with quality above the threshold), the UE may use the CG resource associated with the available beam. If no available CG resource associated with an available beam is found, the UE may initiate a RACH procedure.

[0120] In some embodiments, the UE can include beam measurement information to the NW via MAC CE or PHY layer signaling (e.g., UCI). In some embodiments, the NW can configure one or more search spaces and / or CORESETs (control resource sets) for inactive states, and different search spaces and / or CORESETs can be associated with different beams.

[0121] In some embodiments, the UE can be configured to have one or more search spaces and / or CORESETs for inactive states, and different search spaces and / or CORESETs can be associated with different beams. The UE can determine the DL and / or UL beams based on the search space and / or CORESET of the reserved PDCCH. In some alternatives, the UE can determine which search space / CORESET should be used based on the selected serving beam.

[0122] Example embodiment 6

[0123] Example embodiment 6 may involve measurements during periods of inactive data transmission. Two alternatives can be considered for measurement gaps. A first alternative may include measurement gaps not being used for inactive data transmission, or measurements depending on the UE implementation (e.g., using autonomous mode via the UE implementation).

[0124] A second alternative may include: the measurement gap can be used for inactive data transmission, and the measurement gap is configured to the UE via dedicated signaling before or when the UE enters an inactive state. For example, the measurement gap for inactive data transmission can be configured to the UE via an RRC reconfiguration message before the UE enters an inactive state; or, the measurement gap for inactive data transmission can be configured to the UE via an RRC release message, which will be used to configure the UE into an inactive state.

[0125] In the third alternative, the measurement gap will be used for inactive data transmission, and the configuration of the measurement gap will be broadcast in the system information. Optionally, using the measurement gap configuration in the system information, the UE will determine the location of the measurement gap using the measurement gap configuration in the system information and the UE ID, where the UE ID can be I-RNTI or C-RNTI. For example, the UE determines the gap offset of the measurement gap using the following parameters: UE ID mod parameter A or (UE ID mod parameter A / B) * parameter B or (UE ID mod parameter A / B) * parameter B, where parameters A and B can be configurable parameters configured in the SIB, in dedicated signaling (e.g., parameter A can be the measurement gap repetition period, parameter B can be the measurement gap length), or constants specified in the specification parameters. As another alternative, a separate parameter C can be used instead of the UE ID, and parameter C can be configured via dedicated signaling before or when the UE enters an inactive state.

[0126] Example embodiment 7

[0127] Example 7 may involve cell reselection during I DT. During I DT, the UE can continue cell reselection evaluation. And, once cell reselection is performed, or once the conditions for cell reselection are met, or once the UE initiates I DT in the target cell for reselection, or once the UE initiates a recovery procedure in the target cell for reselection, the UE can perform the following operations (at least one of the following actions).

[0128] The first action may include suspending the DRB. The second action may include stopping inactive data transfer. The third action may include assuming that the inactive data transfer timer has expired, or assuming that the TAT has expired. The fourth action may include releasing the configured CG resource, assuming that the CG resource is unavailable, or releasing the C-RNTI.

[0129] The fifth action may include holding TX_NEXT for sending the PDCP entity (i.e., not setting TX_NEXT to its initial value). The sixth action may include holding RX_NEXT and RX_DELIV for receiving the PDCP entity (i.e., not setting RX_NEXT and RX_DELIV to their initial values).

[0130] The seventh action may include rebuilding and / or releasing the RLC entity for the DRB and / or SRB. The eighth action may include performing PDCP recovery or PDCP reconstruction for the DRB. The ninth action may include performing PDCP reconstruction for the SRB. In an alternative, if an I DT is initiated in the target cell for reselection, PDCP recovery or PDCP reconstruction may be triggered; if a conventional recovery procedure is initiated in the target cell for reselection, a PDCP suspension operation may be triggered.

[0131] In some embodiments, the above actions (e.g., actions 1 / 5 / 6) may only be required for DRBs that allow inactive data transmission. In some embodiments, the above actions may be performed during cell reselection. In some embodiments, the above actions may be performed when the UE initiates an inactive data transmission or RRC recovery procedure in the target cell. In some embodiments, if a cell reselection occurs during inactive data transmission or if the cell reselection criteria are met, the UE may initiate an RRC reconstruction procedure in the target cell.

[0132] Example embodiment 8

[0133] Example 8 may involve fault handling. Once a fault is detected during inactive data transmission, the following actions may be considered. A first alternative may include the UE initiating a normal recovery procedure. A second alternative may include the UE prioritizing the current serving cell during cell reselection. A third alternative may include the UE initiating an RRC reconstruction procedure (e.g., if a CG transmission fault or an RLC fault is detected). A fourth alternative may include the UE initiating a RACH procedure (e.g., if a CG transmission fault, an RLC fault, or a beam fault is detected, the UE should initiate a RACH procedure). A fifth alternative may include the UE entering an idle state (e.g., if a RACH fault is detected, or T319 expires, or coverage is exceeded).

[0134] For fault detection, any of the following faults can be considered: RLC fault, RACH fault, CG transmission fault, out-of-coverage detection, T319 expiration, and / or beam fault. For RLC fault, RACH fault, out-of-coverage, and beam fault, the fault detection defined for the connected state can be reused for the inactive state.

[0135] For fault detection (e.g., RLC fault detection, beam fault detection, etc.), inactive state-specific fault detection parameters (the parameters used to configure fault detection, and these parameters used in inactive state may differ from those used in connected mode) can be configured when or before the UE enters inactive state. For example, these fault detection parameters may be configured with system information or an RRC reconfiguration message, or with an RRC release message, before the UE enters inactive state, which will be used to configure the UE into an inactive state.

[0136] In some alternatives, parameters for fault detection can be configured in both system information and dedicated signaling, with parameters configured in dedicated signaling having a higher priority than those configured in system information (e.g., if both are configured, the parameter configured in dedicated signaling will be used). In other alternatives, parameters for fault detection can be configured in both system information and dedicated signaling, with parameters configured in dedicated signaling having a lower priority than those configured in system information (e.g., if both are configured, the parameter configured in system information will be used).

[0137] For CG transmission failures, a failure can be defined as the absence of a PDCCH address to the C-RNTI, or the receipt of UL / DL clearance before the timer expires or after N PDCCH timings. The timer and / or counter (a counter for the number of PDCCH timings) can be started at or after the initial transmission of the CG resource.

[0138] In some alternatives, if a fault is detected on the UE side, the UE can perform an RRC reconstruction procedure if it has a valid C-RNTI (or I-RNTI). In some alternatives, if a fault is detected on the UE side, the UE can enter an idle state if it does not have a valid C-RNTI (and / or I-RNTI).

[0139] Example embodiment 9

[0140] Example 9 may involve resource configuration. For RACH resource configuration, RACH resources for inactive data transmission can be configured to the UE via system information and / or dedicated signaling. The following resources can be configured for inactive data transmission: dedicated PRACH resources for inactive data transmission, a dedicated MsgA PUSCH resource pool for inactive data transmission, a dedicated CORESET / search space for inactive data transmission for Msg2 and / or MsgB reception, PDCCH resources, PUCCH resources, SRS resources, BWP configuration for inactive data transmission (e.g., the BWP for inactive data transmission may not be the initial BWP), DRX configuration used during inactive data transmission, RLC and / or MAC configuration used during inactive data transmission, other physical layer configurations used during inactive data transmission (other physical layer configurations not covered above), and / or bandwidth for inactive data transmission (e.g., channel bandwidth or cell bandwidth). In some embodiments, a timer (e.g., timer duration) can be configured to the UE to indicate the effective duration of the dedicated inactive data transmission resources. The timer can be started once a message is received or the UE enters an inactive state. Furthermore, once the timer expires, the inactive data transmission resources (e.g., CG resources, C-RNTI) configured by dedicated signaling can be removed on the UE side. In some embodiments, if the UE initiates an I DT in a cell different from the cell configured with inactive data transmission resources, the inactive data transmission resources (e.g., CG resources, C-RNTI) configured by dedicated signaling can be removed. In some embodiments, if the UE reselects a cell different from the cell configured with inactive data transmission resources, the inactive data transmission resources (e.g., CG resources, C-RNTI) configured by dedicated signaling can be removed. In some embodiments, if an SCG is configured (e.g., in LTE-DC, EN-DC, MR-DC, NR-DC, and / or multi-connectivity scenarios), configuration for inactive data transmission can be provided for the MCG (primary cell group) and / or SCG (secondary cell group). If inactive data transmission is provided to the SCG, the inactive data transmission will be applied to the SCG. This embodiment in this application can be applied to the MCG and / or SCG.

[0141] For resource configurations with dedicated signaling, the configuration can be provided in the RRC reconfiguration message or RRC release message before or when the UE enters an inactive state.

[0142] For resource configurations with dedicated signaling, in addition to the resource configurations listed above, contention-free RACH resources can also be configured for the UE. Contention-free RACH resources can be 2-step RACH contention-free resources or 4-step RACH contention-free resources. In some embodiments, a timer (e.g., the duration of the timer) can be configured for the UE to indicate the effective duration of the CFRA resource (e.g., once the timer expires, the CFRA resource will be released or considered invalid). The timer can be started upon receiving a message or when the UE enters an inactive state.

[0143] When configuring authorized resources, the following aspects can be considered: one or more CG resources can be configured for inactive data transfer. In some embodiments, if there are CG resources configured in the connected state, the NW can indicate in signaling (e.g., via a configured grant configuration index) which CG resource can be used in the inactive state.

[0144] A region range can be configured for CG resources, and CG resources can only be used within that region range. In some embodiments, the region range is a cell or a list of cells, an RNA (RAN Notification Area) or a list of RNAs, or a TA or a list of TAs. In some embodiments, the region range is limited to the cells where the UE enters an inactive state, in which case explicit configuration is not required.

[0145] Different CG resources can be configured for different beams, where the beam can be an SSB and / or CSI-RS. Different CG resources can be configured for different DRBs. In some embodiments, for each DRB or each LCH or each PDCP or each RLC, a CG resource ID (e.g., a configured license configuration index) or a list of CG resource IDs can be configured, and only the DRB (LCH / PDCP / RLC) configured with CG resource IDs can utilize the CG resources to perform inactive data transmission.

[0146] A TAT timer for the inactive state can be configured. In some embodiments, the duration of the TAT timer used in the inactive state may differ from the duration of the TAT timer used in the connected state. In some embodiments, if no TAT timer is available for the inactive state, the UE can use the duration of the TAT timer used in the connected mode. In some embodiments, if the duration of the TAT timer for the inactive state is configured in both system information and dedicated signaling, the UE can use the value configured in the dedicated signaling. In some embodiments, if the duration of the TAT timer for the inactive state is configured in both system signaling and dedicated signaling, the UE can use the value configured in the system information signaling.

[0147] A timer can be configured to specify the duration of CG resource availability during inactivity. Furthermore, CG resources can be considered valid before the timer expires. The timer can be configured per UE or per CG. The timer can be started once a message is received or the UE enters an inactive state. The timer duration can be configured in dedicated signaling (e.g., an RRC reconfiguration message or RRC release message before or at the time the UE enters an inactive state).

[0148] Additional resources can be configured for sending / receiving during inactivity. These resources may include C-RNTI, I-RNTI, search space, CORESET, SRS resources, PUCCH resources, PUSCH resources, and / or BWP configuration for inactive data transmission. The resources mentioned above may be the same as those used for connected states, or may be different from those used for connected states (i.e., inactive state-specific resources). In some embodiments, the UE can use these resources once inactive data transmission is initiated. In some embodiments, the UE can use these resources once an RRC recovery message is received and the UE is configured to perform inactive data transmission.

[0149] The above configuration can be provided in dedicated signaling (e.g., UE-specific resource configuration) or system information (cell-specific resource configuration). The above configuration can be configured to the UE via RRC messages (RRC reconfiguration or RRC release) before or when the UE enters an inactive state.

[0150] In some embodiments, CG resources are configured and broadcast via system information, and the UE can select a resource or subset of resources to be broadcast for inactive data transmission based on the configuration received in the system information. In some embodiments, multiple sets of CG resources can be configured in the system information, and the UE will select the configured CG resources based on QoS requirements, UE ID (C-RNTI or I-RNTI), slice, access category, or access type.

[0151] In some embodiments, the common CG configuration broadcast in system information can coexist with the private CG configuration configured in private signaling. When a private CG configuration is provided, the UE should use the private CG configuration; otherwise, the common CG configuration can be used instead.

[0152] It can support the exchange of resource configurations for inactive data transmission between two network nodes. This exchange can be performed via the X2 or Xn interface (or another interface between the two RAN access nodes). Resource configurations can be included in inter-node messages or X2AP / XnAP signaling.

[0153] For access control, separate access control parameters can be configured for inactive data transfers (for example, different parameters can be configured for initial access and inactive data transfers).

[0154] For the RACH and / or CG resources mentioned above, different resource configurations can be configured for different NW slices and / or CAG and / or NPN, and / or different access categories and / or different access types.

[0155] For the RACH resources and / or CG resources mentioned above, different resource configurations can be configured for idle or inactive states.

[0156] Parameters used for transmission type selection can be configured in system information and / or dedicated RRC messages (RRC reconfiguration messages or RRC release messages). In some embodiments, if the parameters for transmission type are configured using dedicated signaling, the UE can ignore the parameters configured in the system information.

[0157] The following parameters can be considered for selection based on the transmission type: RSRP threshold for inactive data transmission. In some embodiments, the UE can only initiate inactive data transmission if the cell RSRP is higher than (or equal to or higher than) the RSRP threshold. In some embodiments, the UE is only allowed to select a specific transmission type for inactive data transmission if the cell RSRP is higher than (or equal to or higher than) the RSRP threshold (in which case the RSRP threshold is configured by transmission type).

[0158] Path loss threshold for inactive data transmission. In some embodiments, a UE can only initiate inactive data transmission if the path loss is less than (or "equal to or less than") the path loss threshold. In some embodiments, a UE is only allowed to select a specific transmission type for inactive data transmission if the cell path loss is less than (or "equal to or less than") the path loss threshold (in which case the RSRP threshold is configured by transmission type).

[0159] Buffer size threshold for inactive data transmission. In some embodiments, the UE is only allowed to initiate inactive data transmission if the buffer size is less than (or equal to or less than) the buffer size threshold.

[0160] The buffer size can be the total buffer size for each UE, the total buffer size for a UE's DRB / LCH that allows inactive data transmission, and / or the buffer size for a DRB, LCH, or LCG.

[0161] Example embodiment 10

[0162] Example embodiment 10 may involve security processing. For security processing during periods of inactive data transmission, the following alternatives may be considered. A first alternative may include legacy security configurations that can be used during periods of inactive data transmission.

[0163] A second alternative could include using the old security configuration to secure the first message or the RRC recovery message. Furthermore, the new security configuration could be used in subsequent transmissions (e.g., once the RRC recovery request message is generated or sent).

[0164] A third alternative could include always using the new security configuration. The old security configuration could refer to the security configuration used before the UE entered an inactive state. The new security configuration could refer to the security configuration derived from the security configuration configured in the RRC release message (which will be used to configure the UE to an inactive state).

[0165] The security configuration may include security keys and / or security algorithms. In some embodiments, the UE may perform a horizontal key export if inactive data transmission is configured or if inactive data transmission is performed or initiated. In some embodiments, the UE may perform a vertical key export or a horizontal key export based on a configuration from the NW side. The configuration may be provided to the UE in dedicated RRC signaling (e.g., RRC reconfiguration and / or RRC release). In some embodiments, the UE may determine the type of key export based on the type of inactive data transmission selected. For example, if inactive data transmission that does not involve RRC is selected, the UE may always perform a horizontal key export.

[0166] Example embodiment 11

[0167] Example 11 may involve impacts on the user plane. In some embodiments, if an RRC release message is received and inactive data transmission is configured and / or allowed based on the received RRC release message, and / or CG resources for inactive data transmission are configured, then for DRBs and / or PDCPs that do not support inactive data transmission, the UE may: set TX_NEXT to its initial value and / or discard all stored PDCP PDUs in order to send the PDCP entity. In order to receive the PDCP entity, if the t-Reordering timer is running: stop and reset the t-Reordering timer, and after performing header decompression, transmit all stored PDCP SDUs to the upper layer in ascending order of their relevant count values, setting RX_NEXT and RX_DELIV to their initial values.

[0168] For DRBs and / or PDCPs that support inactive data transmission, in the first alternative, no PDCP suspension operation is performed, and no special operation is required in the PDCP. In the second alternative, the DRB is suspended. In the third alternative, PDCP resumption or PDCP reconstruction is performed. In the fourth alternative, for PDCP: For transmitting PDCP entities, TX_NEXT can be maintained (i.e., TX_NEXT is not set to its initial value). For receiving PDCP entities, RX_NEXT and RX_DELIV can be maintained (i.e., RX_NEXT and RX_DELIV are not set to their initial values).

[0169] In some embodiments, if an RRC release message is received and inactive data transmission is configured and / or allowed based on the received RRC release message, and / or CG resources for inactive data transmission are configured, the UE may not perform a PDCP suspension operation for each DRB, and no special operation is required in PDCP to suspend the DRB, perform PDCP recovery or PDCP reconstruction, and / or use PDCP.

[0170] For transmitting PDCP entities, TX_NEXT can be preserved (i.e., TX_NEXT is not set to its initial value). For receiving PDCP entities, RX_NEXT and RX_DELIV can be preserved (i.e., RX_NEXT and RX_DELIV are not set to their initial values).

[0171] In some embodiments, before or during the UE initiates an RRC recovery procedure, if "inactive data transmission is configured and / or allowed based on the received RRC release message" and / or "CG resources for inactive data transmission are configured" and "if the UE determines to initiate a normal RRC recovery procedure" or "the cell in which the UE initiates the RRC recovery procedure does not support or allows inactive data transmission", then the UE may perform a PDCP suspension for each DRB.

[0172] In some embodiments, before or at the time the UE initiates an RRC recovery procedure, if the UE determines that it is initiating inactive data transmission or if inactive data transmission is configured and / or allowed in the cell, the UE may perform a PDCP reconstruction procedure for each DRB, a PDCP reconstruction procedure for each DRB that allows inactive data transmission, a PDCP recovery procedure for each DRB, and / or a PDCP recovery procedure for each DRB that allows inactive data transmission.

[0173] In some embodiments, if I DT is allowed, the UE may not perform the PDCP suspension operation; otherwise, the UE may perform the PDCP suspension operation.

[0174] In some embodiments, before or during the UE initiates an RRC recovery procedure, if the UE determines that it is initiating inactive data transmission or if inactive data transmission is configured and / or permitted in the cell, the UE may rebuild (one or more) RLC entities for each RLC, LCH, or DRB and / or rebuild (one or more) RLC entities that permit inactive data transmission for each RLC, LCH, or DRB. Rebuilding RLCs can be replaced by releasing / adding or creating RLC entities.

[0175] For rebuilding an RLC entity (or releasing / adding or creating an RLC entity), the default configuration should be used, reusing the configuration used before the UE entered the inactive state, or the configuration configured for inactive data transmission should be used, and the configuration can be provided to the UE via an RRC reconfiguration message or an RRC release message before or when the UE enters the inactive state.

[0176] In some embodiments, if a CG resource is configured for inactive data transmission, or if a TAT is configured for inactive data transmission, or if inactive data transmission is configured / allowed, the UE can maintain the TAT (Time Calibration Timer) timer in an inactive state.

[0177] In some embodiments, if the TAT expires in an inactive state, the UE may release or clear any configured downlink allocations and / or CG resources.

[0178] Example method for data transmission in energy saving state

[0179] Figure 7 This is a block diagram 700 of an example method for data transmission in an energy-saving state. The method may include sending a first message from a terminal in a first state to a network node to initiate a data communication recovery process to the network node (block 702). As described herein, the first state may include an energy-saving state, such as an inactive or idle state.

[0180] The method may further include: after sending the first message, monitoring a control channel with a network temporary identifier (block 704) in response to the first message. In a first state, the terminal may restrict the network node's use of radio resources. As described herein, the network temporary identifier may include a Cell Radio Network Temporary Identifier (C-RNTI) or an Inactive Radio Network Temporary Identifier (I-RNTI).

[0181] In some embodiments, the first message is either a Radio Resource Control (RRC) Recovery Request message or an RRC Establishment Request message.

[0182] In some embodiments, the response to the first message includes a contention resolution, wherein the terminal monitors the control channel having the network temporary identifier, the control channel including a physical downlink control channel (PDCCH), and the network temporary identifier including a cell radio network temporary identifier (C-RNTI) identified in the response to the first message.

[0183] In some embodiments, the method includes the terminal receiving a first data transmission scheduled by the monitored network temporary identifier from the network node.

[0184] In some embodiments, the method includes the terminal sending a second data transmission scheduled by the monitored network temporary identifier to the network node.

[0185] In some embodiments, the method includes: receiving an RRC release message from the network node by the terminal; and in response to receiving the RRC release message, stopping monitoring of the control channel having the network temporary identifier configured for the terminal, and discarding the network temporary identifier.

[0186] In some embodiments, the RRC release message is a response to the first message.

[0187] In some embodiments, the first message includes an RRC recovery request sent via a configuration authorization (CG) resource, and wherein the RRC release message is scheduled by the network temporary identifier configured for the terminal.

[0188] In some embodiments, the method includes the terminal initiating an inactive data transmission timer in response to receiving a response to the first message, wherein, in response to initiating the inactive data transmission timer, the terminal monitors the control channel having the network temporary identifier configured for the terminal.

[0189] In some embodiments, the method includes: receiving PDCCH scheduling information with C-RNTI from the terminal; and restarting the inactive data transmission timer from the terminal in response to receiving the PDCCH scheduling information with C-RNTI.

[0190] In some embodiments, the method includes the terminal detecting the expiration of the inactive data transmission timer; and in response to detecting the expiration of the inactive data transmission timer, the terminal performing any one of stopping monitoring of the control channel using the network temporary identifier configured for the terminal, discarding the network temporary identifier, and / or suspending any one of the Private Radio Bearer (DRB) and / or Packet Data Convergence Protocol (PDCP).

[0191] In some embodiments, the duration of the inactive data transmission timer is configured by any one of an RRC reconfiguration message (e.g., received by the terminal before it transitions to an inactive state), an RRC release message (e.g., which will be used to configure the terminal to an inactive state), and system information of any message in which data transmission is performed.

[0192] In some embodiments, the first message includes an Inactive Radio Network Temporary Identifier (I-RNTI), a Media Access Control (MAC) Control Element (CE), a MAC Service Data Unit (SDU), and a MAC Protocol Data Unit (PDU).

[0193] In some embodiments, the response to the first message includes either a C-RNTI or an I-RNTI pending contention resolution.

[0194] In some embodiments, the first message includes data transmitted via CG resources.

[0195] In some embodiments, the method includes: receiving a MAC control element (CE) from a network node by the terminal, the MAC control element including an indication to release the network temporary identifier; in response to receiving the MAC CE from the network node, ceasing monitoring of the control channel having the network temporary identifier configured for the terminal; and discarding the network temporary identifier including a C-RNTI by the terminal.

[0196] In another embodiment, a method for wireless communication may include receiving, by a network node, a first message from a terminal in a first state for initiating a data communication recovery process. The method may further include: the network node sending a response to the first message to the terminal, which monitors a control channel having a network temporary identifier in response to the response to the first message.

[0197] In some embodiments, in the first state, the terminal's use of radio resources is restricted by the network node, or unless I DT is configured, it does not need to maintain UL synchronization, or unless I DT is performed, it does not need to address PDCCH monitoring to C-RNTI, or it needs to monitor the paging channel.

[0198] In some embodiments, the first message is either a Radio Resource Control (RRC) Recovery Request message or an RRC Establishment Request message.

[0199] In some embodiments, the response to the first message includes a contention resolution, wherein the terminal is configured to monitor the control channel having the network temporary identifier, the control channel including a physical downlink control channel (PDCCH), and the network temporary identifier including a cell radio network temporary identifier (C-RNTI) identified in the response to the first message.

[0200] In some embodiments, the method includes sending a first data transmission scheduled by the monitored network temporary identifier to the terminal from the network node.

[0201] In some embodiments, the method includes the network node receiving a second data transmission scheduled by the monitored network temporary identifier from the terminal.

[0202] In some embodiments, the method includes sending an RRC release message from the network node to the terminal, wherein the terminal is configured to, in response to receiving the RRC release message from the network node, stop monitoring the control channel having the network temporary identifier configured for the terminal and discard the network temporary identifier.

[0203] In some embodiments, the RRC release message is a response to the first message.

[0204] In some embodiments, the first message includes an RRC recovery request sent via a configuration authorization (CG) resource, and wherein the RRC release message is scheduled by the network temporary identifier configured for the terminal.

[0205] In some embodiments, the terminal is configured to initiate an inactive data transmission timer in response to receiving a response to the first message, and to monitor the control channel having the network temporary identifier configured for the terminal in response to initiating the inactive data transmission timer.

[0206] In some embodiments, the first message includes an Inactive Radio Network Temporary Identifier (I-RNTI), a Media Access Control (MAC) Control Element (CE), a MAC Service Data Unit (SDU), and a MAC Protocol Data Unit (PDU).

[0207] In some embodiments, the response to the first message includes either a C-RNTI or an I-RNTI pending contention resolution.

[0208] In some embodiments, the first message includes data transmitted via CG resources.

[0209] In some embodiments, the method includes sending a MAC control element (CE) from the network node to the terminal, the MAC control element including an indication to release the network temporary identifier, wherein the terminal is configured to stop monitoring the control channel having the network temporary identifier configured for the terminal and discard the network temporary identifier including the C-RNTI.

[0210] Example wireless system

[0211] Figure 8 An example of a wireless communication system in which one or more embodiments of the present technology can be applied is shown. The wireless communication system 800 may include one or more base stations (BS) 805a, 805b, one or more wireless devices or terminals 810a, 810b, 810c, 810d, and a core network 825. Base stations 805a, 805b may provide wireless services to wireless devices 810a, 810b, 810c, and 810d in one or more wireless sectors. In some implementations, base stations 805a, 805b include directional antennas for generating two or more directional beams to provide wireless coverage in different sectors. The base stations may implement cell scheduling or candidate cell functionality as described in this document.

[0212] The core network 825 can communicate with one or more base stations 805a and 805b. The core network 825 provides connectivity with other wireless and wired communication systems. The core network may include one or more service subscription databases to store information related to subscribed wireless devices 810a, 810b, 810c, and 810d. The first base station 805a can provide wireless services based on a first radio access technology, while the second base station 805b can provide wireless services based on a second radio access technology. Depending on the deployment scenario, base stations 805a and 805b can be located in the same location or installed separately in the field. Wireless devices 810a, 810b, 810c, and 810d can support multiple different radio access technologies.

[0213] In some implementations, a wireless communication system may include multiple networks using different wireless technologies. Dual-mode or multi-mode wireless devices include two or more wireless technologies that can be used to connect to different wireless networks.

[0214] Figure 9This is a block diagram representation of a hardware platform. Hardware platform 905, such as a network node, base station, terminal, or wireless device (or UE), may include processor electronics 910, such as a microprocessor implementing one or more of the technologies presented in this document. Hardware platform 905 may include transceiver electronics 915 for transmitting and / or receiving wired or wireless signals via one or more communication interfaces, such as antenna 920 or a wired interface. Hardware platform 905 may implement other communication interfaces according to defined protocols for transmitting and receiving data. Hardware platform 905 may include one or more memories (not explicitly shown) configured to store information such as data and / or instructions. In some implementations, processor electronics 910 may include at least a portion of transceiver electronics 915. In some embodiments, hardware platform 905 is used to implement at least some of the disclosed technologies, modules, or functions.

[0215] Conclusions

[0216] In summary, this will be understood and described as allowing wireless devices to, as regarding Figure 7 Several techniques for performing data transmission in a power-saving first state are described, wherein the base station or network device restricts the wireless device's use of wireless resources. For example, in the power-saving state, the network device may not provide the wireless device with opportunities to send or receive unicast IP layer data. For illustrative purposes, specific embodiments of the currently disclosed techniques have been described herein, but various modifications can be made without departing from the scope of the invention. Therefore, the techniques disclosed herein are limited only by the appended claims.

[0217] The disclosed embodiments and other embodiments, the modules and functional operations described in this document, can be implemented in digital electronic circuits or in computer software, firmware, or hardware (including the structures disclosed in this document and their structural equivalents), or combinations thereof. The disclosed embodiments 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 a data processing apparatus or for controlling the operation of a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a combination of substances influencing machine-readable propagation signals, or combinations thereof. The term "data processing apparatus" encompasses means, devices, and machines for processing data, including, for example, a programmable processor, a computer, or a plurality of processors or computers. In addition to hardware, the means may include code that creates an execution environment for the computer program in question, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or combinations thereof. Propagation signals are artificially generated signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information for transmission to a suitable receiver device.

[0218] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language, including compiled or interpreted languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units suited to a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), as a single file dedicated to the program in question, or as multiple coordinating files (e.g., files storing one or more modules, subroutines, or portions of code). A computer program can be deployed to execute on a single computer or on multiple computers located at one site or distributed across multiple sites and interconnected via a communication network.

[0219] The processes and logic flows described in this document can be implemented by one or more programmable processors, which execute one or more computer programs to perform functions by manipulating input data and generating outputs. The processes and logic flows can also be implemented by devices, and these devices can be implemented as special-purpose logic circuit systems, such as field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs).

[0220] For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, as well as any one or more processors in any type of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or be operatively coupled to receive data from or transfer data to mass storage devices, or both. However, a computer does not need to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, 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 or integrated therein by dedicated logic circuitry.

[0221] Although this patent document contains numerous specific details, these details should not be construed as limiting the scope of any invention or what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular invention. Certain features described in the context of various embodiments in this patent document may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments, or in any suitable sub-combination. Furthermore, although features may be described above as functioning in certain combinations, and even initially claimed in this way, in some cases, one or more features in a claimed combination may be removed from that combination, and a claimed combination may refer to a sub-combination or a variation of a sub-combination.

[0222] Similarly, although the operations are described in a specific order in the accompanying drawings, this should not be construed as requiring that these operations be performed in the specific order or sequence shown, or that all of the operations shown be performed, in order to obtain the desired results. Furthermore, the separation of various system components in the embodiments described in this patent document should not be construed as requiring such separation in all embodiments.

[0223] Only some implementation methods and examples are described. Other implementation methods, improvements and changes can be made based on the description and explanation in this patent document.

Claims

1. A method for wireless communication, comprising: A first message is sent from a terminal in a first state to a network node to initiate a data communication recovery process to the network node, wherein the first message is sent by configuring authorized CG resources; and After sending the first message, in response to the first message, a control channel with a network temporary identifier is monitored; wherein the network temporary identifier is configured when the terminal was previously in a radio resource control connection state or when the terminal entered an inactive state in response to receiving a radio resource control release message. The response determines the cell radio network temporary identifier C-RNTI; The terminal uses a timer to determine when to discard the C-RNTI; in: - The terminal receives the timer configuration from the network node. - The timer is configured in the system information of the network node that performs the data transmission. - The timer starts when the first message is sent, or - The timer stops when another radio resource control release message is received.

2. The method according to claim 1, wherein, In the first state, the terminal's use of wireless resources is restricted by the network node.

3. The method according to claim 1, wherein, The first message also includes an RRC establishment request message.

4. The method according to any one of claims 1 and 3, wherein, The response to the first message includes a contention resolution, wherein the terminal monitors the control channel having the C-RNTI, the control channel including the Physical Downlink Control Channel (PDCCH).

5. The method of claim 1, further comprising: The terminal receives a first data transmission scheduled by the monitored network temporary identifier from the network node.

6. The method according to any one of claims 1 and 5, further comprising: The terminal sends a second data transmission scheduled by the monitored network temporary identifier to the network node.

7. The method of claim 1, further comprising: The terminal receives the RRC release message from the network node; as well as In response to receiving the RRC release message, the terminal stops monitoring the control channel with the network temporary identifier configured for the terminal and discards the network temporary identifier.

8. The method according to claim 7, wherein, The RRC release message includes the response to the first message.

9. The method according to claim 8, wherein, The first message includes an RRC recovery request sent via configured authorized CG resources, wherein the RRC release message is scheduled by the network temporary identifier configured for the terminal.

10. The method of claim 9, further comprising: The terminal initiates an inactive data transmission timer in response to receiving a response to the first message, wherein, in response to initiating the inactive data transmission timer, the terminal monitors the control channel having the network temporary identifier configured for the terminal.

11. The method of claim 10, further comprising: The terminal receives PDCCH scheduling information with C-RNTI. as well as In response to receiving the PDCCH scheduling information with the C-RNTI, the terminal restarts the inactive data transmission timer.

12. The method of claim 11, further comprising: The terminal detects the expiration of the inactive data transmission timer; as well as In response to the detection of the expiration of the inactive data transmission timer, the terminal performs any of the following: stops monitoring of the control channel having the network temporary identifier configured for the terminal, discards the network temporary identifier, and / or suspends the Dedicated Radio Bearer (DRB) and / or the Packet Data Convergence Protocol (PDCP).

13. The method according to any one of claims 1 and 10-12, wherein, The duration of the inactive data transmission timer is configured by any one of the following: an RRC reconfiguration message received by the terminal before the terminal transitions to the inactive state, an RRC release message for configuring the terminal to the inactive state, and system information for any messages in which data transmission is performed.

14. The method according to claim 1, wherein, The first message includes an Inactive Radio Network Temporary Identifier (I-RNTI), a Media Access Control (MAC) Control Element (CE), a MAC Service Data Unit (SDU), and a MAC Protocol Data Unit (PDU).

15. The method according to any one of claims 1 and 14, wherein, The response to the first message includes either a C-RNTI or an I-RNTI that is pending contention resolution.

16. The method according to claim 1, wherein, The first message includes data transmitted via CG resources.

17. The method of claim 1, further comprising: The terminal receives a MAC control element (CE) from the network node, the MAC control element including an indication to release the network temporary identifier; In response to receiving the MAC CE from the network node, the terminal stops monitoring the control channel having the network temporary identifier configured for the terminal; as well as The terminal discards the network temporary identifier, including the C-RNTI.

18. The method according to claim 7, wherein, Stop the timer when an RRC release message is received.

19. The method according to claim 1, wherein, Data forwarding occurs when the first network node performing inactive data transmission is different from the network node where the terminal enters an inactive state.

20. The method according to claim 19, wherein, The first network node forwards data packets to the second network node through the Xn interface or a GTP tunnel, where the GTP tunnel is either a public GTP tunnel shared by multiple tunnels or a terminal-dedicated tunnel.

21. The method according to claim 19, wherein, The first network node sends a release request or end marker to the second network node to notify the end of inactive data transmission.

22. The method according to claim 1 or 19, wherein, The first network node buffers the received data and processes it after the context extraction process.

23. The method according to claim 22, wherein, When the terminal or network determines that it no longer meets the criteria for inactive data transmission, a transmission type switch occurs during the inactive data transmission period, and the terminal is switched to connected mode and performs normal UL transmission.

24. The method according to claim 22, wherein, Whether a CG is valid is determined based on any of the following: whether CG resources are configured and / or stored, whether valid CG resources can be found on a qualified beam, whether the configured and / or stored CG resources are allowed for inactive transmissions, whether valid TAs are maintained on the UE side, and / or whether inactive data transmissions are suitable for ongoing services.

25. The method according to claim 22, wherein, Configure a buffer size threshold for the terminal in system information or dedicated signaling. This buffer size threshold is determined based on the sum of the buffer sizes for each UE, each logical channel, or each logical channel group, or LCH or LCG logical channel groups that allow inactive data transmission. If the buffer on the UE side is less than or equal to the threshold, the UE is allowed to initiate data transmission in an inactive state; otherwise, the terminal initiates an RRC recovery process.

26. The method according to claim 22, wherein, If a CG-based solution is initiated or if CG-based data transmission is configured, the terminal initiates a RACH procedure if a qualified beam with CG resources cannot be found.

27. The method according to claim 1, wherein, When the terminal initiates an IDT in the target cell for reselection, or when it initiates a recovery process in the target cell for reselection, the terminal performs at least one of the following actions: Stop inactive data transmission. The inactive data transmission timer is considered to have expired, or Release the configured CG resources, or consider the CG resources unavailable, or release C-RNTI.

28. The method according to claim 1, wherein, When a fault is detected during inactive data transmission, the terminal UE enters an idle state.

29. The method according to claim 28, wherein, The faults include the detection of a RACH fault, T319 expiration, or detection of being out of coverage.

30. The method according to claim 1, wherein, If the terminal initiates an IDT in a different cell than the cell configured with inactive data transmission dedicated resources, the inactive data transmission dedicated resources configured by dedicated signaling are removed.

31. The method according to claim 1, further comprising resource allocation, wherein, The resource configuration includes configuring one or more CG resources for inactive data transmission, configuring different CG resources for different beams, configuring different CG resources for different DRBs, configuring a TAT timer for the inactive state, and configuring other resources for transmission / reception in the inactive state, wherein the other resources include search space, CORESET, PUSCH resources and / or BWP configuration for inactive data transmission.

32. The method according to claim 31, wherein, The transmission type is determined based on the cell's RSRP threshold.

33. The method according to claim 1, wherein, Before or during the RRC recovery process initiated by the terminal, if the terminal determines that it is initiating inactive data transmission or if inactive data transmission is configured and / or allowed in the cell, a PDCP reconstruction process is performed for each DRB that allows inactive data transmission.

34. The method according to claim 1, wherein, For rebuilding an RLC entity or releasing / adding or creating an RLC entity, reuse the configuration used before the terminal entered an inactive state.

35. A method for wireless communication, comprising: A network node receives a first message from a terminal in a first state to initiate a data communication recovery process, wherein the first message is sent by the terminal through configured authorized CG resources; and The network node sends a response to the first message to the terminal that monitors the control channel with a network temporary identifier in response to the response to the first message; wherein the network temporary identifier is configured when the terminal was previously in a radio resource control connection state or when the terminal entered an inactive state in response to receiving a radio resource control release message. The response determines the cell radio network temporary identifier C-RNTI; The terminal uses a timer to determine when to discard the C-RNTI; in: - The terminal receives the timer configuration from the network node. - The timer is configured in the system information of the network node that performs the data transmission. - The timer starts when the first message is sent, or - The timer stops when another radio resource control release message is received.

36. The method according to claim 35, wherein, In the first state, the terminal's use of wireless resources is restricted by the network node.

37. The method of claim 35, wherein, The first message also includes an RRC establishment request message.

38. The method according to claim 35, wherein, The response to the first message includes a contention resolution, wherein the terminal is configured to monitor the control channel having the C-RNTI, the control channel including the Physical Downlink Control Channel (PDCCH).

39. The method of claim 35, further comprising: The network node sends a first data transmission scheduled by the monitored network temporary identifier to the terminal.

40. The method according to any one of claims 35 and 39, further comprising: The network node receives a second data transmission scheduled by the monitored network temporary identifier from the terminal.

41. The method of claim 35, further comprising: The network node sends an RRC release message to the terminal, wherein the terminal is configured to, in response to receiving the RRC release message from the network node, stop monitoring the control channel having the network temporary identifier configured for the terminal, and discard the network temporary identifier.

42. The method according to any one of claims 35 and 41, wherein, The RRC release message is a response to the first message.

43. The method according to claim 42, wherein, The first message includes an RRC recovery request sent via configured authorized CG resources, and wherein the RRC release message is scheduled by the network temporary identifier configured for the terminal.

44. The method according to claim 43, wherein, The terminal is configured to start an inactive data transmission timer in response to receiving a response to the first message, and to monitor the control channel having the network temporary identifier configured for the terminal in response to starting the inactive data transmission timer.

45. The method according to claim 35, wherein, The first message includes an Inactive Radio Network Temporary Identifier (I-RNTI), a Media Access Control (MAC) Control Element (CE), a MAC Service Data Unit (SDU), and a MAC Protocol Data Unit (PDU).

46. ​​The method according to any one of claims 35 and 45, wherein, The response to the first message includes either a C-RNTI or an I-RNTI that is pending contention resolution.

47. The method of claim 35, wherein, The first message includes data transmitted via CG resources.

48. The method of claim 35, further comprising: The network node sends a MAC control element (CE) to the terminal, the MAC CE including an indication to release the network temporary identifier, wherein the terminal is configured to stop monitoring the control channel having the network temporary identifier configured for the terminal and discard the network temporary identifier including the C-RNTI.

49. The method according to claim 41, wherein, Stop the timer when an RRC release message is received.

50. The method of claim 35, wherein, Data forwarding occurs when the first network node performing inactive data transmission is different from the network node where the terminal enters an inactive state.

51. The method according to claim 50, wherein, The first network node forwards data packets to the second network node through the Xn interface or a GTP tunnel, where the GTP tunnel is either a public GTP tunnel shared by multiple tunnels or a terminal-dedicated tunnel.

52. The method according to claim 50, wherein, The first network node sends a release request or end marker to the second network node to notify the end of inactive data transmission.

53. The method according to claim 35 or 50, wherein, The first network node buffers the received data and processes it after the context extraction process.

54. The method according to claim 53, wherein, When the terminal or network determines that it no longer meets the criteria for inactive data transmission, a transmission type switch occurs during the inactive data transmission period, and the terminal is switched to connected mode and performs normal UL transmission.

55. The method according to claim 53, wherein, Whether a CG is valid is determined based on any of the following: whether CG resources are configured and / or stored, whether valid CG resources can be found on a qualified beam, whether the configured and / or stored CG resources are allowed for inactive transmissions, whether valid TAs are maintained on the UE side, and / or whether inactive data transmissions are suitable for ongoing services.

56. The method according to claim 53, wherein, Configure a buffer size threshold for the terminal in system information or dedicated signaling. This buffer size threshold is determined based on the sum of the buffer sizes for each UE, each logical channel, or each logical channel group, or LCH or LCG logical channel groups that allow inactive data transmission. If the buffer on the UE side is less than or equal to the threshold, the UE is allowed to initiate data transmission in an inactive state; otherwise, the terminal initiates an RRC recovery process.

57. The method according to claim 53, wherein, If a CG-based solution is initiated or if CG-based data transmission is configured, the terminal initiates a RACH procedure if a qualified beam with CG resources cannot be found.

58. The method according to claim 35, wherein, When the terminal initiates an IDT in the target cell for reselection, or when it initiates a recovery process in the target cell for reselection, the terminal performs at least one of the following actions: Stop inactive data transmission. The inactive data transmission timer is considered to have expired, or Release the configured CG resources, or consider the CG resources unavailable, or release C-RNTI.

59. The method according to claim 35, wherein, When a fault is detected during inactive data transmission, the terminal UE enters an idle state.

60. The method according to claim 59, wherein, The faults include the detection of a RACH fault, T319 expiration, or detection of being out of coverage.

61. The method according to claim 35, wherein, If the terminal initiates an IDT in a different cell than the cell configured with inactive data transmission dedicated resources, the inactive data transmission dedicated resources configured by dedicated signaling are removed.

62. The method of claim 35, further comprising resource allocation, wherein, The resource configuration includes configuring one or more CG resources for inactive data transmission, configuring different CG resources for different beams, configuring different CG resources for different DRBs, configuring a TAT timer for the inactive state, and configuring other resources for transmission / reception in the inactive state, wherein the other resources include search space, CORESET, PUSCH resources and / or BWP configuration for inactive data transmission.

63. The method according to claim 62, wherein, The transmission type is determined based on the cell's RSRP threshold.

64. The method according to claim 35, wherein, Before or during the RRC recovery process initiated by the terminal, if the terminal determines that it is initiating inactive data transmission or if inactive data transmission is configured and / or allowed in the cell, a PDCP reconstruction process is performed for each DRB that allows inactive data transmission.

65. The method according to claim 35, wherein, For rebuilding an RLC entity or releasing / adding or creating an RLC entity, reuse the configuration used before the terminal entered an inactive state.

66. An apparatus for wireless communication, comprising a processor configured to perform the method according to any one of claims 1 to 65.

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

Images