Managing data communications before and after state transitions

Abstract

To manage communications from the UE during state transitions, a central unit (CU) of the base station performs, by processing hardware, an early data transmission procedure with the UE while the UE is in an inactive state, including transmitting at least one data packet of a sequence of data packets to the UE (802). The CU determines to transition the UE from the inactive state to a connected state (808). In response to transitioning the UE to the connected state, the CU transmits, by the processing hardware, a next data packet of the sequence of data packets to the UE, or retransmits, by the processing hardware, the at least one data packet to the UE in response to determining that the at least one data packet has not been received (812).

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to U.S. Provisional Patent Application No. 63 / 200,898, filed April 1, 2021, entitled “Managing Data Communication Before and After a State Transition,” the entire disclosure of which is expressly incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and more specifically to data communications between the user equipment (UE) and the radio access network (RAN) when the UE is operating in an inactive or idle state associated with a protocol for controlling radio resources and after the UE transitions to a connected state associated with the protocol for controlling radio resources. Background Technology

[0004] This background description is provided for the purpose of presenting the overall context of this disclosure. The work of the currently attributed inventors, to the extent described in this background section, and in aspects that may not qualify as prior art at the time of filing, is neither expressly nor implicitly acknowledged as prior art to this disclosure.

[0005] Generally, base stations operating a cellular radio access network (RAN) use a radio access technology (RAT) and multiple layers of a protocol stack to communicate with user equipment (UE). For example, the physical layer (PHY) of the RAT provides a transport channel to the media access control (MAC) sublayer, which in turn provides a logical channel to the radio link control (RLC) sublayer, and the RLC sublayer in turn provides data transmission services to the packet data convergence protocol (PDCP) sublayer. The radio resource control (RRC) sublayer sits above the PDCP sublayer.

[0006] The RRC sublayer specifies the RRC_IDLE (RRC Idle) state, where the UE has no active radio connection to the base station; the RRC_CONNECTED (RRC Connected) state, where the UE has an active radio connection to the base station; and the RRC_INACTIVE (RRC Inactive) state, to allow the UE to transition back to the RRC_CONNECTED state more quickly due to Radio Access Network (RAN) level base station coordination and RAN paging procedures. In some cases, a UE in the RRC_IDLE or RRC_INACTIVE state may only have a relatively small packet to transmit. In these cases, a UE in the RRC_IDLE or RRC_INACTIVE state may perform early data transmission (also referred to herein as small data transmission) without transitioning to the RRC_CONNECTED state, for example, by using the techniques specified in Section 7.3 of 3GPP specification 36.300 v16.54.0.

[0007] In some scenarios, during early data communication between the RAN and a UE operating in an inactive or idle state, the RAN transitions the UE to a connected state, for example, because the RAN needs to convey data packets associated with specific Quality of Service (QoS) requirements, or because the link quality between the UE and the RAN deteriorates. It is unclear how data communication proceeds after the UE transitions to a connected state. Summary of the Invention

[0008] An example embodiment of the technology disclosed herein is a method for managing communications from a UE during state transitions in a central unit (CU) of a base station. The method includes processing hardware performing an early data transmission process with the UE when the UE is in an inactive state, including communicating at least one data packet in a data packet sequence to the UE, and the processing hardware determining whether to transition the UE from an inactive state to a connected state. In response to transitioning the UE to a connected state, the method includes the processing hardware communicating the next data packet in the data packet sequence to the UE, or the processing hardware retransmitting the at least one data packet to the UE in response to failing to determine that the at least one data packet has been received.

[0009] Another example embodiment of these technologies is the CU of a base station, which includes processing hardware and is configured to implement the methods described above.

[0010] Another example embodiment of these technologies is a method for managing communications from a UE during state transitions in a distributed unit (DU) of a base station. The method includes, when the UE is in an inactive state, processing hardware performing an early data transmission process with the UE, including communicating at least one data packet in a data packet sequence to the UE. In response to the UE transitioning to a connected state, the method includes, either, communicating the next data packet in the data packet sequence to the UE by the processing hardware, or, in response to failing to determine that the at least one data packet has been received, retransmitting the at least one data packet to the UE.

[0011] Another example embodiment of these technologies is a base station DU, which includes processing hardware and is configured to implement the methods described above.

[0012] Another example embodiment of these technologies is a method in a UE for transmitting data to a base station during a state transition. The method includes: when the UE is in an inactive state, having processing hardware perform an early data transmission process with the central unit (CU) and distributed unit (DU) of the base station, including communicating at least one data packet in a data packet sequence via the DU and CU. The method further includes a transition from a processing hardware state to a connected state with the base station. In response to the transition to a connected state, the method includes having the processing hardware communicate the next data packet in the data packet sequence to the base station, or having the processing hardware retransmit at least one data packet with the base station in response to failing to determine that at least one data packet has been received.

[0013] Another example embodiment of these technologies is a UE that includes processing hardware and is configured to implement the methods described above. Attached Figure Description

[0014] Figure 1A This is a block diagram of an example wireless communication system in which the user equipment and base station of this disclosure can implement the techniques of this disclosure for reducing latency in data communication;

[0015] Figure 1B Centralized units (CUs) and distributed units (DUs) can be used in... Figure 1A A block diagram of an example base station operating in the system;

[0016] Figure 2A This is a block diagram of an example protocol stack. Figure 1A The UE communicates with the base station according to this example protocol stack;

[0017] Figure 2B This is a block diagram of an example protocol stack. Figure 1A The UE can communicate with the DU and CU according to this example protocol stack;

[0018] Figure 3AThis is a message sending and receiving diagram of an example procedure for managing communication from the UE during the state transition from an inactive state to a connected state with the base station;

[0019] Figure 3B This is another example of a message transmission graph used to manage communications from the UE during state transitions from an inactive state to a connected state with the base station, where the UE or CU reconstructs the Packet Data Convergence Protocol (PDCP) entity;

[0020] Figure 3C This is another example of a message transmission graph used to manage communications from the UE during the state transition from an inactive state to a connected state with the base station, where the initial radio resource control (RRC) message does not include the initial data packet;

[0021] Figure 3D This is another example of a message transmission graph used to manage communications from the UE during a state transition from an inactive state to a connected state with the base station, where the UE or CU reconstructs the PDCP entity and the initial radio resource control (RRC) message does not include an initial data packet;

[0022] Figure 3E This is another example of a message transmission diagram used to manage communication from the UE during the state transition from an inactive state to a connected state with the base station, in which the CU sends an RRC establishment message to the UE to restart rather than restore the connection with the base station;

[0023] Figure 4 This is a flowchart of an example method for managing communication from the UE during state transitions by resetting the Media Access Control (MAC) entity. This example method can be provided by... Figure 1A RAN implementation;

[0024] Figure 5 This is a flowchart of an example method for managing communications from the UE during state transitions by rebuilding the radio control link (RLC) entity. This example method can be derived from… Figure 1A RAN implementation;

[0025] Figure 6 This is a flowchart of an example method for managing communications from the UE during state transitions by reconstructing the PDCP entity. This example method can be derived from... Figure 1A RAN implementation;

[0026] Figures 7A-7C This is a flowchart of an example method for managing communication from the UE during state transitions by sending HARQ transmissions using a Hybrid Automatic Repeat Request (HARQ) process number. This example method can be derived from... Figure 1A RAN implementation;

[0027] Figure 8 This is a flowchart of an example method for managing communication from the UE during state transitions by assigning a first sequence number set (0, ..., X-1) to packets sent in the inactive state and resetting the sequence number set (0, ..., Y-1) for packets sent in the connected state. This example method can be derived from... Figure 1A RAN implementation;

[0028] Figure 9 This is a flowchart of an example method for managing communication from the UE during a state transition by resetting state variables used to communicate data packets in the inactive state to their initial values ​​when transitioning to a connected state. This example method can be derived from... Figure 1A RAN implementation;

[0029] Figure 10 This is a flowchart of an example method for managing communication from the UE during state transitions by avoiding resetting the MAC entity. This example method can be provided by... Figure 1A RAN implementation;

[0030] Figure 11 This is a flowchart of an example method for managing communication from the UE during state transitions by avoiding the reconstruction of the RLC entity. This example method can be derived from… Figure 1A RAN implementation;

[0031] Figure 12 This is a flowchart of an example method for managing communication from the UE during state transitions by avoiding the reconstruction of the PDCP entity. This example method can be derived from... Figure 1A RAN implementation;

[0032] Figures 13A-13B This is a flowchart of an example method for managing communication from the UE during state transitions by sending HARQ transmissions using a HARQ process number. This example method can be derived from... Figure 1A RAN implementation;

[0033] Figure 14 This is a flowchart of an example method for managing communication from the UE during state transitions by assigning a first set of sequence numbers (0, ..., X-1) to packets sent in the inactive state and assigning a second set of sequence numbers (X, ..., Y-1) to packets sent in the connected state, wherein the second set of sequence numbers begins with a number (X) following the last number (X-1) in the first set of sequence numbers. This example method can be derived from... Figure 1A RAN implementation;

[0034] Figure 15This is a flowchart of an example method for managing communication from the UE during state transitions by preserving state variables used to communicate data packets in the inactive state when transitioning to a connected state. This example method can be derived from... Figure 1A RAN implementation;

[0035] Figure 16 This is a flowchart of an example method for managing communication from a UE during a state transition by receiving information indicating that at least one data packet has not been received when the UE is in an inactive state. This example method can be derived from... Figure 1A RAN implementation;

[0036] Figure 17 This is a flowchart of an example method for managing communication from a UE during a state transition by sending a request to the UE for information indicating whether data packets have been received while the UE is in an inactive state. This example method can be provided by... Figure 1A RAN implementation;

[0037] Figure 18 This is a flowchart of an example method for managing communications from a UE during a state transition by retaining, resetting, rebuilding, or releasing MAC entities, RLC entities, and / or PDCP entities in response to transmitting a first or second message to the UE. This method can be... Figure 1A RAN implementation;

[0038] Figure 19 This is a flowchart of an example method for transmitting data to a base station during a state transition by resetting the MAC entity. This example method can be provided by... Figure 1A UE implementation;

[0039] Figure 20 This is a flowchart of an example method for transmitting data to a base station during a state transition by reconstructing an RLC entity. This example method can be derived from… Figure 1A UE implementation;

[0040] Figure 21 This is a flowchart of an example method for transmitting data to a base station during a state transition by reconstructing a PDCP entity. This example method can be derived from... Figure 1A UE implementation;

[0041] Figure 22 This is a flowchart of an example method for transmitting data to a base station during a state transition by sending a HARQ transmission using a HARQ process number. This example method can be provided by... Figure 1A UE implementation;

[0042] Figure 23This is a flowchart of an example method for transmitting data to a base station during a state transition by assigning a first sequence number set (0, ..., X-1) to packets transmitted in an inactive state and resetting the sequence number set (0, ..., Y-1) for packets transmitted in a connected state. This example method can be derived from... Figure 1A UE implementation;

[0043] Figure 24 This is a flowchart of an example method for transmitting data to a base station during a state transition by resetting a state variable used to communicate data packets in an inactive state to its initial value when transitioning to a connected state. This example method can be derived from… Figure 1A UE implementation;

[0044] Figure 25 This is a flowchart of an example method for transmitting data to a base station during a state transition by avoiding resetting the MAC entity. This example method can be provided by... Figure 1A UE implementation;

[0045] Figure 26 This is a flowchart of an example method for transmitting data to a base station during a state transition by avoiding the reconstruction of the RLC entity. This example method can be derived from… Figure 1A UE implementation;

[0046] Figure 27 This is a flowchart of an example method for transmitting data to a base station by avoiding the reconstruction of PDCP entities during state transitions. This example method can be derived from... Figure 1A UE implementation;

[0047] Figures 28A-28B This is a flowchart of an example method for transmitting data to a base station during a state transition by sending a HARQ transmission using a HARQ process number. This example method can be provided by... Figure 1A UE implementation;

[0048] Figure 29 This is a flowchart of an example method for transmitting data to a base station during a state transition by assigning a first set of sequence numbers (0, ..., X-1) to packets sent in an inactive state and a second set of sequence numbers (X, ..., Y-1) to packets sent in a connected state, wherein the second set of sequence numbers begins with a number (X) following the last number (X-1) in the first set of sequence numbers. This example method can be derived from... Figure 1A UE implementation;

[0049] Figure 30This is a flowchart of an example method for transmitting data to a base station during a state transition by preserving state variables used to communicate data packets in an inactive state when transitioning to a connected state. This example method can be derived from… Figure 1A UE implementation;

[0050] Figure 31 This is a flowchart of an example method for transmitting data to a base station during a state transition by receiving information indicating that at least one data packet has not been received while the UE is in an inactive state. This example method can be derived from… Figure 1A UE implementation;

[0051] Figure 32 This is a flowchart of an example method for transmitting data to a base station during a state transition by sending a request to the base station for information indicating whether data packets have been received while the UE is in an inactive state. This example method can be derived from... Figure 1A UE implementation;

[0052] Figure 33 This is a flowchart of an example method for transmitting data to a base station during a state transition by retaining, resetting, rebuilding, or releasing MAC entities, RLC entities, and / or PDCP entities in response to receiving a first or second message from the base station. This example method can be derived from… Figure 1A UE implementation;

[0053] Figure 34 This is a flowchart of an example method for managing communication from the UE during state transitions by sending messages to the DU to reconstruct the RLC entity. This example method can be provided by... Figure 1B CU implementation;

[0054] Figure 35 This is a flowchart of an example method for managing communication from the UE during state transitions by reconstructing the RLC entity. This example method can be derived from... Figure 1B DU implementation;

[0055] Figure 36 This is a flowchart of an example method for managing communication from the UE during a state transition by sending a message to the DU to reset the MAC entity. This example method can be provided by... Figure 1B CU implementation;

[0056] Figure 37 This is a flowchart of an example method for managing communication from the UE during a state transition by resetting the MAC entity. This example method can be provided by... Figure 1B The implementation of DU; and

[0057] Figure 38This is a flowchart of an example method for managing communication from a UE during a state transition by sending a message to the DU to release the UE's UE context information. This example method can be provided by... Figure 1B The CU implementation. Detailed Implementation

[0058] First refer to Figure 1A Example wireless communication system 100 includes UE 102, base station (BS) 104, base station 106, and core network (CN) 110. Base stations 104 and 106 can operate in RAN 105 connected to core network (CN) 110. For example, CN 110 can be implemented as evolved packet core (EPC) 111 or fifth-generation (5G) core (5GC) 160. In another example, CN 110 can also be implemented as a sixth-generation (6G) core.

[0059] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, then cell 124 is an NR cell. If base station 124 is an ng-eNB, then cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, if base station 106 is a gNB, then cell 126 is an NR cell, and if base station 126 is an ng-eNB, then cell 126 is an E-UTRA cell. Cells 124 and 126 can be in the same Radio Access Network Notification Area (RNA) or different RNAs. Typically, RAN 105 can include any number of base stations, and each base station can cover one, two, three, or any other suitable number of cells. UE 102 can support at least 5G NR (or simply "NR") or E-UTRA air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 can be connected to CN110 via an interface (e.g., an S1 or NG interface). Base stations 104 and 106 can also be interconnected via an interface (e.g., an X2 or Xn interface) used to interconnect NG RAN nodes.

[0060] Among other components, EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. SGW 112 is typically configured to transmit user plane packets related to audio calls, video calls, Internet services, etc., and MME 114 is configured to manage authentication, registration, paging, and other related functions. PGW 116 provides connectivity from the UE to one or more external packet data networks (e.g., Internet networks and / or Internet Protocol (IP) Multimedia Subsystem (IMS) networks). 5GC 160 includes a User Plane Function (UPF) 162 and Access and Mobility Management (AMF) 164, and / or Session Management Function (SMF) 166. Generally, UPF 162 is configured to transmit user plane packets related to audio calls, video calls, Internet services, etc., AMF 164 is configured to manage authentication, registration, paging, and other related functions, and SMF 166 is configured to manage PDU sessions.

[0061] like Figure 1A As shown, base station 104 supports cell 124, and base station 106 supports cell 126. Cells 124 and 126 may partially overlap, allowing UE 102 to select, reselect, or hand over to one of cells 124 and 126. For direct exchange of messages or information, base stations 104 and 106 may support X2 or Xn interfaces. Typically, CN 110 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells.

[0062] As discussed in detail below, UE 102 and / or RAN 105 implement the techniques of this disclosure to transmit data when the radio connection between UE 102 and RAN 105 is suspended (e.g., in an inactive or idle state of the protocol used to control radio resources between UE 102 and RAN 105). For clarity, the examples below relate to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol.

[0063] As used in this disclosure, the terms "data" or "data packet" refer to signaling and control plane information at the protocol layer controlling radio resources (e.g., RRC), controlling mobility management (MM), and controlling session management (SM), or to non-signaling and non-control plane information at the protocol layer above the layer of the protocol used to control radio resources (e.g., RRC), the layer of the protocol used to control MM, the layer of the protocol used to control SM, or the layer of the protocol used to control quality of service (QoS) flow (e.g., Service Data Adaptation Protocol (SDAP)). Data for which the UE and / or RAN apply the techniques of this disclosure may include, for example, Internet of Things (IoT) data, Ethernet service data, Internet service data, or Short Message Service (SMS) messages. Furthermore, as described below, in some implementations, UE 102 applies these techniques only when the data size is below a certain threshold.

[0064] In the example scenario discussed below, UE 102 transitions to the RRC_INACTIVE or RRC_IDLE state, then selects the cell of base station 104, and exchanges data with base station 104 via base station 106 or directly with base station 104, without transitioning to the RRC_CONNECTED state. Specifically, UE 102 and base station 104 of RAN 105 can communicate using an earlier data transmission procedure without UE 102 transitioning to the RRC_CONNECTED state.

[0065] As a more specific example, in some cases, when UE 102 is operating in RRC_INACTIVE or RRC_IDLE state, UE 102 sends data to RAN 105 in the uplink (UL) direction.

[0066] When UE 102 operates in RRC_INACTIVE or RRC_IDLE state, after UE 102 determines that data is available for uplink transmission, UE 102 can apply one or more security functions to UL data packets, generate a first UL Protocol Data Unit (PDU) including a security protection packet, include the UL RRC message along with the first UL PDU in a second UL PDU, and send the second UL PDU to RAN 105. UE 102 includes its UE identifier / identifier (ID) in the UL RRC message. RAN 105 can identify UE 102 based on the UE ID. In some implementations, the UE ID can be an Inactive Radio Network Temporary Identifier (I-RNTI), a Recovery ID, or a Non-Access Stratum (NAS) ID. The NAS ID can be an S-Temporary Mobile Subscriber Identifier (S-TMSI) or a Globally Unique Temporary Identifier (GUTI).

[0067] Security features may include integrity protection and / or encryption. When integrity protection is enabled, UE 102 can generate a Message Authentication Code (MAC-I) for integrity to protect data integrity. Therefore, in this case, UE 102 generates a security protection packet that includes data and the MAC-I. When encryption is enabled, UE 102 can encrypt the data to obtain an encrypted packet, such that the security protection packet includes encrypted data. When both integrity protection and encryption are enabled, UE 102 can generate a MAC-I for protecting data integrity and encrypt the data along with the MAC-I to generate an encrypted packet and an encrypted MAC-I. UE 102 can then send the security protection packet to RAN 105 while in the RRC_INACTIVE or RRC_IDLE state.

[0068] In some implementations, the data is an uplink (UL) Service Data Unit (SDU) of Packet Data Convergence Protocol (PDCP) or SDAP. UE 102 applies security features to the SDU and includes the secure SDU in a first UL PDU (e.g., a ULPDCP PDU). UE 102 then includes the UL PDCP PDU in a second UL PDU (such as a UL MAC PDU), which may be associated with the Media Access Control (MAC) layer. Therefore, in these cases, UE 102 transmits the secure UL PDCP PDU within the UL MAC PDU. In some implementations, UE 102 may include a UL RRC message in the UL MAC PDU. In other implementations, UE 102 may omit the UL RRC message from the UL MAC PDU. In such implementations, UE 102 may omit the UE ID from the UL MAC PDU. In other implementations, UE 102 may include a UL PDCP PDU in a UL Radio Link Control (RLC) PDU, and then include a UL RLC PDU in a UL MAC PDU. In some implementations where the UL RRC message is included in the UL MAC PDU, UE 102 generates an RRC MAC-I and includes the RRC MAC-I in the UL RRC message. For example, the RRC MAC-I is the resumeMAC-I field, as specified in 3GPP specification 38.331. In other implementations, the UE may obtain an integrity key (e.g., K) from the UL RRC message. RRCintThe RRC MAC-I includes the key, integrity protection algorithm, and other parameters such as COUNT (count) (e.g., 32-bit, 64-bit, or 128-bit value), BEARER (bearer) (e.g., 5-bit value) and DIRECTION (direction) (e.g., 1-bit value).

[0069] In other implementations, the data is the NAS uplink (UL) protocol data unit (SDU). UE 102 applies security features to the SDU and includes the secure SDU in a first UL PDU (such as a NAS PDU) that can be associated with the NAS layer. For example, the NAS layer could be the MM or SM sublayer of 5G, Evolved Packet System (EPS), or 6G. UE 102 can then include the UL NAS PDU in a second UL PDU (such as a UL RRC message). Therefore, in these cases, UE 102 sends the (first) secure UL NAS PDU in the UL RRC message. In some implementations, UE 102 can include the UL RRC message in the UL MAC PDU and send the UL MAC PDU to the base station (e.g., base station 104 or 106) via the cell (e.g., cell 124 or 126). In this case, UE 102 can omit the RRC MAC-I from the UL RRC message. Alternatively, UE 102 can include the RRC MAC-I as described above.

[0070] In some implementations, the aforementioned UL RRC message may be a Common Control Channel (CCCH) message, an RRC Recovery Request message, or an RRC Early Data Request message. The UL RRC message may include the UE ID of UE 102 as described above.

[0071] More generally, UE 102 may use at least one of encryption and integrity protection to protect the data, include the protected data as a security protection packet in a first UL PDU, and send the first UL PDU to RAN 105 in a second UL PDU.

[0072] In some scenarios and implementations, base station 106 can retrieve the UE ID of UE 102 from the UL RRC message and, based on the determined UE ID, identify base station 104 as the destination of data in the first UL PDU. In one example implementation, base station 106 retrieves the first UL PDU from the second UL PDU and sends the first UL PDU to base station 104. Base station 104 then retrieves the security protection packet from the first UL PDU, applies one or two security functions to decrypt the data and / or check integrity protection, and sends the data to CN 110 (e.g., SGW 112, UPF 162, MME 114, or AMF 164) or an edge server. In some implementations, the edge server can operate within RAN 105. More specifically, base station 104 derives at least one security key from the UE context information of UE 102. Base station 104 then retrieves data from the security protection packet using the at least one security key and sends the data to CN 110 or the edge server. When the security protection packet is an encrypted packet, base station 104 decrypts the encrypted packet using at least one security key (e.g., an encryption / decryption key) to obtain the data. If the security protection packet is an integrity protection packet, the integrity protection packet may include data and a MAC-I. Base station 104 can verify the validity of the MAC-I for the security protection packet using at least one security key (e.g., an integrity key). When base station 104 confirms the MAC-I is valid, base station 104 sends the data to CN 110 or the edge server. On the other hand, when base station 104 determines the MAC-I is invalid, base station 104 discards the security protection packet. Furthermore, if the security protection packet is both encrypted and integrity-protected, the encrypted and integrity-protected packet may include the encrypted packet along with an encrypted MAC-I. In this case, base station 104 decrypts the encrypted packet and the encrypted MAC-I to obtain the data and the MAC-I. Base station 104 then determines whether the MAC-I is valid for the data. If base station 104 determines the MAC-I is valid, base station 104 retrieves the data and forwards it to CN 110 or the edge server. However, if base station 104 determines that MAC-I is invalid, then base station 104 discards the packet.

[0073] In another implementation, base station 106 retrieves a security protection packet from a first UL PDU. Base station 106 performs a UE context retrieval procedure with base station 104 to obtain UE context information of UE 102 from base station 104. Base station 106 derives at least one security key from the UE context information. Then, base station 106 retrieves data from the security protection packet using at least one security key and sends the data to CN 110 (e.g., UPF 162) or an edge server. When the security protection packet is an encrypted packet, base station 106 decrypts the encrypted packet using at least one security key (e.g., an encryption / decryption key) to obtain the data. If the security protection packet is an integrity protection packet, the integrity protection packet may include data and a MAC-I. Base station 106 can verify the validity of the MAC-I for the security protection packet using at least one security key (e.g., an integrity key). When base station 106 confirms that the MAC-I is valid, base station 106 sends the data to CN 110. On the other hand, when base station 106 determines that the MAC-I is invalid, base station 106 discards the security protection packet. Furthermore, if the security protection packet is both encrypted and integrity-protected, the encrypted and integrity-protected packet may include the encrypted packet along with an encrypted MAC-I. In this case, base station 106 decrypts the encrypted packet and the encrypted MAC-I to obtain the data and the MAC-I. Base station 106 then determines whether the MAC-I is valid for the data. If base station 106 determines the MAC-I is valid, base station 106 retrieves the data and forwards it to data CN 110. However, if base station 106 determines the MAC-I is invalid, base station 106 discards the packet.

[0074] In other scenarios and implementations, base station 104 can retrieve the UE ID of UE 102 from the UL RRC message and identify that base station 104 stores the UE context information of UE 102. Therefore, base station 104 retrieves the security protection packet from the first UL PDU, retrieves the data from the security protection packet, and sends the data to CN 110 or the edge server, as described above.

[0075] In addition, in some cases, RAN 105 transmits data in the downlink (DL) direction to UE 102 operating in RRC_INACTIVE or RRC_IDLE state.

[0076] For example, when base station 104 determines that data is available for downlink transmission to UE 102 currently operating in RRC_INACTIVE or RRC_IDLE state, base station 104 may apply at least one security function to the data to generate a security protection packet, generate a first DL PDU including the security protection packet, and include the first DL PDU in a second DL PDU. To protect the data, base station 104 may apply security functions (e.g., integrity protection and / or encryption) to the data. More specifically, when integrity protection is enabled, base station 104 generates a MAC-I for protecting data integrity, such that the security protection packet includes the data and the MAC-I. When encryption is enabled, base station 104 encrypts the data to generate an encrypted packet, such that the security protection packet is an encrypted packet. Furthermore, when both integrity protection and encryption are enabled, base station 104 may generate a MAC-I for protecting data integrity and encrypt the data along with the MAC-I to generate an encrypted packet and an encrypted MAC-I. In some implementations, base station 104 generates a first DL PDU (such as a DL PDCP PDU) including a security protection packet, includes the first DL PDU in a second DL PDU (e.g., a DL MAC PDU) associated with, for example, the MAC layer, and sends the second DL PDU to UE 102 without first transitioning UE 102 from the RRC_INACTIVE or RRC_IDLE state to the RRC_CONNECTED state. In some implementations, base station 104 includes the DL PDCP PDU in a DL RLC PDU, includes the DL RLC PDU in a DL MACP PDU, and sends the DL MAC PDU to UE 102 without first transitioning UE 102 from the RRC_INACTIVE or RRC_IDLE state to the RRC_CONNECTED state.

[0077] In another implementation, base station 104 sends a first DL PDU to base station 106, then base station 106 generates a second PDU (e.g., a DL MAC PDU) including the first DL PDU and sends the second DL PDU to UE 102 without first transitioning UE 102 from the RRC_INACTIVE or RRC_IDLE state to the RRC_CONNECTED state. In some implementations, base station 106 generates a DL RLC PDU including the first DL PDU and includes the DL RLC PDU in the second DL PDU. In yet another implementation, base station 104 includes the first DL PDU in the DL RLC PDU and sends the DL RLC PDU to base station 106, then base station 106 generates a second DL PDU (e.g., a DL MAC PDU) including the DL RLC PDU and sends the second DL PDU to UE 102.

[0078] In some implementations, the base station (i.e., base station 104 or 106) generates downlink control information (DCI) and a cyclic redundancy check (CRC) scrambled with the ID of UE 102 to send a second DL PDU generated by the base station. In some implementations, the ID of UE 102 can be a radio network temporary identifier (RNTI). For example, the RNTI can be a cell RNTI (C-RNTI), a temporary C-RNTI, or an inactive C-RNTI. The base station sends the DCI and scrambled CRC to UE 102 operating in the RRC_INACTIVE or RRC_IDLE state on the physical downlink control channel (PDCCH). The base station scrambles the CRC with the ID of UE 102. In some implementations, the base station can assign the ID of UE 102 to UE 102 in the random access response sent during random access with UE 102 before sending the DCI and scrambled CRC. In other implementations, the base station may assign the UE 102 ID to the UE 102 in an RRC message (e.g., an RRC release message or an RRC reconfiguration message) sent to the UE 102 before sending the DCI and scrambled CRC (e.g., when the UE 102 was previously operating in the RRC_CONNECTED, RRC_INACTIVE, or RRC_IDLE state).

[0079] UE 102, operating in RRC_INACTIVE or RRC_IDLE state, can receive DCI and scrambled CRC on the PDCCH. Then, UE 102 confirms the Physical Downlink Shared Channel (PDSCH) addressing, including the second DL PDU, based on UE 102's ID, DCI, and scrambled CRC. UE 102 can then retrieve data from the security protection packet. If the security protection packet is encrypted, UE 102 can decrypt the encrypted packet using appropriate decryption functions and a security key to obtain the data. If the security protection packet is an integrity protection packet including data and MAC-I, UE 102 can determine if the MAC-I is valid. If UE 102 confirms the MAC-I is valid, UE 102 retrieves the data. However, if UE 102 determines the MAC-I is invalid, UE 102 discards the packet. Finally, when the secure protection packet containing encrypted data and an encrypted MAC-I is both encrypted and protected for integrity, UE 102 can decrypt the encrypted packet and the encrypted MAC-I to obtain the data and MAC-I. UE 102 can then verify that the MAC-I is valid for the data. If UE 102 confirms that the MAC-I is valid, UE 102 retrieves and processes the data. Otherwise, if UE 102 determines that the MAC-I is invalid, UE 102 discards the data.

[0080] Base station 104 is equipped with processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable storage of instructions executed by the one or more general-purpose processors. Alternatively or additionally, processing hardware 130 may include dedicated processing units. In an example implementation, processing hardware 130 includes a Media Access Control (MAC) controller 132 configured to perform random access procedures with one or more user equipments, receive uplink MAC Protocol Data Units (PDUs) from one or more user equipments, and transmit downlink MAC PDUs to one or more user equipments. Processing hardware 130 may also include a Packet Data Convergence Protocol (PDCP) controller 134 configured to transmit DL PDCP PDUs (which base station 104 can transmit in the downlink direction) in some scenarios and receive UL PDCP PDUs (which base station 104 can receive in the uplink direction) in other scenarios. The processing hardware may also include an RRC controller 136 to implement process and message transmission and reception at the RRC sublayer of the protocol communication stack. In the example implementation, processing hardware 130 includes an RRC inactivity controller 138, which is configured to manage uplink and / or downlink communication with one or more UEs operating in the RRC_INACTIVE or RRC_IDLE state. Base station 106 may include generally similar components. In particular, components 140, 142, 144, 146, and 148 may be similar to components 130, 132, 134, 136, and 138, respectively.

[0081] UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors (such as a CPU) and non-transitory computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors and / or dedicated processing units. In an example implementation, processing hardware 150 includes an RRC_INACTIVE controller 158 configured to manage uplink and / or downlink communications when UE 102 operates in the RRC_INACTIVE state. In an example implementation, processing hardware 150 includes a Media Access Control (MAC) controller 152 configured to perform random access procedures with a base station, transmit uplink MAC Protocol Data Units (PDUs) to the base station, and receive downlink MAC PDUs from the base station. Processing hardware 150 may also include a PDCP controller 154 configured to transmit DL PDCP PDUs (data that base station 106 can transmit in the downlink direction) in some scenarios, and receive UL PDCP PDUs (data that base station 106 can receive in the uplink direction) in other scenarios. The processing hardware may also include an RRC controller 156 to implement process and message sending and receiving at the RRC sublayer of the protocol communication stack.

[0082] Figure 1B Example distributed or decomposed implementations of any one or more base stations 104, 106 are depicted. In this implementation, base stations 104, 106 include a central unit (CU) 172 and one or more dedicated units (DUs) 174. CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the general-purpose processor and / or dedicated processing units. For example, CU 172 may include a PDCP controller, an RRC controller, and / or an RRC inactivity controller, such as PDCP controllers 134, 144, RRC controllers 136, 146, and / or RRC inactivity controllers 138, 148. In some implementations, CU 172 may include a radio link control (RLC) controller configured to manage or control one or more RLC operations or processes. In other implementations, CU 172 does not include an RLC controller.

[0083] Each of DU 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units. For example, the processing hardware may include a MAC controller (e.g., MAC controller 132, 142) configured to manage or control one or more MAC operations or procedures (e.g., random access procedures), and / or an RLC controller configured to manage or control one or more RLC operations or procedures. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

[0084] In some implementations, CU 172 may include a logical node CU-CP 172A that hosts the control plane portion of the PDCP protocol for CU 172. CU 172 may also include a logical node CU-UP 172B that hosts the user plane portion of the PDCP protocol and / or the Service Data Adaptation Protocol (SDAP) protocol for CU 172. CU-CP 172A may send control information (e.g., RRC messages, F1 application protocol messages), and CU-UP 172B may send data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0085] A CU-CP 172A can connect to multiple CU-UP 172Bs via an E1 interface. The CU-CP 172A selects the appropriate CU-UP 172B for the requested service of UE 102. In some implementations, a single CU-UP 172B can connect to multiple CU-CP 172As via an E1 interface. A CU-CP 172A can connect to one or more DU 174s via an F1-C or W1-C interface. A CU-UP 172B can connect to one or more DU 174s under the control of the same CU-CP 172A via an F1-U or W1-U interface. In some implementations, a DU 174 can connect to multiple CU-UP 172Bs under the control of the same CU-CP 172A. In such implementations, the connection between the CU-UP 172B and DU 174 is established by the CU-CP 172A using bearer context management functions.

[0086] Figure 2A An example protocol stack 200 is shown in a simplified manner, according to which UE 102 can communicate with eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106).

[0087] In example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208, and in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data transmission services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transmission services to the Serving Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer. Figure 2A (Not shown in the image) provides data transmission services. In some implementations, UE 102 supports, for example... Figure 2A The EUTRA and NR stacks shown are designed to support handover between EUTRA and NR base stations and / or support DC on the EUTRA and NR interfaces. Additionally, as... Figure 2A As shown, UE 102 can support the layering of NR PDCP 210 on EUTRA RLC 206A, and the layering of SDAP sublayer 212 on NR PDCP sublayer 210.

[0088] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 (e.g., from an Internet Protocol (IP) layer that is directly or indirectly layered on PDCP layer 208 or 210) receive packets that can be referred to as Service Data Units (SDUs), and (e.g., to RLC layer 206A or 206B) output packets that can be referred to as Protocol Data Units (PDUs). Except where the difference between SDU and PDU is relevant, for simplicity, this disclosure refers to both SDU and PDU as "packets".

[0089] On the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide signaling radio bearer (SRB) or RRC sublayer ( Figure 2A (Not shown) to exchange, for example, RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide DRBs to support data exchange. The data exchanged on NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0090] Figure 2B An example protocol stack 250 is shown in a simplified manner, illustrating how UE 102 can communicate with DU (e.g., DU 174) and CU (e.g., CU 172). Figure 2B As shown in the radio protocol stack 250, the radio protocol stack 200 is functionally segmented. The CU at any of the base stations 104 or 106 can retain all control and upper-layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower-layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connectivity to the 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0091] Next, refer to Figures 3A-3E Discussion involves Figure 1A Several components and several example scenarios involving sending and / or receiving data in an inactive or idle state. Generally speaking, Figures 3A-3E The same events are labeled with the same reference numerals. To simplify the following description, "inactive state" can refer to the RRC_INACTIVE or RRC_IDLE state, and "connected state" can refer to the RRC_CONNECTED state.

[0092] First refer to Figure 3AIn scenario 300A, UE 102 initially operates in an inactive state (e.g., RRC_INACTIVE or RRC_IDLE), and base station 104 includes CU 172 and DU 174. In some scenarios and implementations, UE 102 previously interacted with RAN 105 (e.g., with base station 104, base station 106, or...) before transitioning to the inactive state. Figure 1A RAN 105 operates in a connected state (as shown in the diagram, at another base station). After a (first) specific period of data inactivity for UE 102, RAN 105 can determine that neither RAN 105 nor UE 102 has transmitted any data in the downlink or uplink direction during the (first) specific period. In response to this determination, RAN 105 can send a first RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to UE 102 and instruct UE 102 to transition to an inactive state. UE 102 transitions to an inactive state upon receiving the first RRC release message and operates in the inactive state 302. RAN 105 can assign a UE identifier / identifier (ID) (e.g., I-RNTI or Recovery ID) to UE 102 and include the assigned value in the first RRC release message. In some cases, after UE 102 transitions to an inactive state, UE 102 can perform one or more RAN Notification Area (RNA) updates via DU174 and CU 172 without a state transition. For example, an inactive UE 102 can send an RRC recovery request message (e.g., an RRCResumeRequest message or an RRCConnectionResumeRequest message) to RAN 105 for RNA update, and RAN 105 can send a first RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to UE 102 and instruct UE 102 to remain inactive. In some implementations, CU 172 may include security parameters (e.g., next-hop chain count) in the first RRC release message. UE 102 uses the security parameters to derive security keys (i.e., a base key, an integrity key, and / or an encryption key). For example, UE 102 uses security parameters to derive the base key (e.g., K...). gNB ), and derive the integrity key (e.g., K) from the base key. RRCint Key and / or K UPint Key) and encryption key (e.g., K) RRCenc Key and / or K UPencThe CU 172 derives the security key in a similar manner to UE 102 (i.e., the same security key derived by UE 102). UE 102 may include the UE ID in the UL RRC message sent by UE 102 in event 302. In events 304, 312, 314, 334, and 336, UE 102 and CU 172 use the integrity key (e.g., K) in data communication. UPint Key) and / or encryption key (e.g., K UPenc In events 324 and 332, UE 102 and CU 172 use an integrity key (e.g., K) in communications of the RRC recovery message and the RRC recovery completion message, respectively. RRCint Key) and / or encryption key (e.g., K RRCenc (Key).

[0093] At a later time, the inactive UE 102 initiates initial UL early data communication (380) to send uplink (UL) data. In response to or after initiating early data communication, UE 102 generates an initial UL MAC PDU including a UL RRC message and a UL PDCP PDU with sequence number (SN) = 0, and sends the initial UL MAC PDU (304) to DU 174 on cell 124. DU 174 retrieves the UL RRC message and the UL PDCP PDU with SN = 0 from the initial UL MAC PDU and generates an Initial UL RRC Message Transfer (306) message including the UL RRC message. DU 174 then transmits the Initial UL RRC Message Transfer (306) message to CU 172. Upon receiving the Initial UL RRC Message Transfer (306) message, in some implementations, CU 172 may transmit a UEContext Setup Request (306) message to DU 174. Figure 3A (Not shown in the image) to establish the UE context of UE102 at DU 174. In response, DU 174 sends a UE Context Setup Response message to CU 172. Figure 3A(Not shown in the image). In some implementations, DU 174 may include a UL PDCP PDU with SN=0 in the Initial UL RRC Message Transfer message. In other implementations, DU 174 may transmit the UL PDCP PDU with SN=0 to CU 172 via a user plane interface (e.g., an F1-U interface or a W1-U interface) instead of including the UL PDCP PDU with SN=0 in the Initial UL RRC Message Transfer message. In this case, DU 174 may transmit the UL PDCP PDU with SN=0 to CU 172 via the user plane interface after receiving a UE Context Setup Request message or sending a UE Context Setup Response message.

[0094] Upon receiving an Initial UL RRC Message Transfer message or a UE Context Setup Response message, CU 172 avoids transitioning UE 102 to a connected state and performs early data communication 312, 314 with CU 172 via DU 174 to convey UL data and / or DL ​​data. More specifically, after sending an initial UL MAC PDU, UE 102 may send 312 to DU 174 one or more UL PDCP PDUs with SN = 1, ..., K respectively, where K is an integer greater than 0. UE 102 may transmit 312 to DU 174 a UL MAC PDU including one or more UL PDCP PDUs. DU 174 forwards one or more UL PDCP PDUs to CU 172 via a control plane interface (e.g., F1-C or W1-U) or a user plane interface (F1-U or W1-U). UE 102 may include application data packets, RRC messages, or NAS PDUs in a particular UL PDCP PDU. In some implementations, a UL MAC PDU in one or more UL MAC PDUs may include a specific UL PDCPPDU or a segment including a specific UL PDCP PDU. In other implementations, UE 102 may transmit 312 UL MAC PDUs including at least two of K UL PDCP PDUs. In some implementations, UE 102 may include a specific UL PDCP PDU in a ULRLC PDU and include a ULRLC PDU in a UL MAC PDU in one or more UL MAC PDUs. In other implementations, UE 102 may include a segment of a specific UL PDCP PDU in a UL RLC PDU segment, include other segments of the UL PDCP PDU in other UL RLC PDU segments, and include other UL RLC PDU segments in a UL MAC PDU in one or more UL MAC PDUs. In other implementations, UE 102 may transmit 312 UL MAC PDUs comprising at least two UL RLC PDUs, each UL RLC PDU comprising a specific UL PDCPPDU from K UL PDCP PDUs. When DU 174 receives all segments of the UL PDCP PDUs from UE 102, DU 174 assembles these segments to obtain a UL PDCP PDU and transmits the UL PDCP PDU to CU 172.

[0095] After receiving an Initial UL RRC Message Transfer message, sending a UE Context Setup Request message, or receiving a UE Context Setup Response message, CU 172 may send 314 one or more DL PDCP PDUs with SN = 0, ..., M respectively to DU 174, where M is an integer greater than or equal to 0. DU 174 may send 314 DL MAC PDUs comprising one or more DL PDCP PDUs to UE 102. CU 172 may receive one or more DL data packets from CN 110 or an edge server and include specific DL data packets in specific DL PDCP PDUs. In some implementations, the DL MAC PDUs in one or more DL MAC PDUs may include specific DL PDCP PDUs or segments comprising specific DL PDCP PDUs. In other implementations, DU 174 may send 314 DL MAC PDUs comprising at least two of the M+1 PDCP PDUs to UE 102. In some implementations, DU 174 may include a specific DL PDCP PDU within a DL RLC PDU, and a DL RLC PDU within a DL MAC PDU in one or more DL MAC PDUs. In other implementations, DU 174 may include segments of a specific DL PDCP PDU within segments of a DL RLC PDU, other segments of the DL PDCP PDU within segments of other DL RLCPDUs, and other segments of the DL RLC PDU within segments of one or more DL MAC PDUs. In still other implementations, DU 174 may transmit to UE 102 314 DL MAC PDUs comprising at least two DL RLC PDUs, each DL RLC PDU comprising a specific DL PDCP PDU from M+1 DL PDCP PDUs. When UE 102 receives all segments of the DL PDCP PDUs from DU 174, UE 102 assembles these segments to obtain a DL PDCPPDU.

[0096] Despite Figure 3A Not shown, but (subsequent) UL early data communication 312 and DL early data communication 314 may overlap or not overlap in time and / or frequency.

[0097] Following or simultaneously with early data communication with UE 102 via DU 174 (312, 314), CU 172 determines (316) to transition UE 102 to a connected state. As previously described, this determination can occur when the RAN needs to convey data packets associated with specific Quality of Service (QoS) requirements unavailable through early data transmission procedures, or because the link quality between the UE and the RAN deteriorates below a threshold. In response to this determination, CU 172 may transmit a (318) UE Context Request message to DU 174 to obtain radio configuration for UE 102. In response, DU 174 transmits (320) a UE Context Response including radio configuration for UE 102. In some implementations, the UE Context Request message and the UE Context Response message may be a UE Context Setup Request message and a UE Context Setup Response message, respectively. In other implementations, the UE Context Request message and the UE Context Response message may be a UE Context Modification Request message and a UE Context Modification Response message, respectively. After obtaining the radio configuration, CU 172 generates an RRC recovery message including the radio configuration and transmits a CU-DU message (322) including the RRC recovery message to DU 174. DU 174 then retrieves the RRC recovery message from the CU-DU message and transmits a 324 RRC recovery message to UE 102.

[0098] In some implementations, the radio configuration may include multiple configuration parameters that configure the radio resources for UE 102 to communicate with DU 174 via PCell (e.g., cell 124 or another cell) and zero or one SCell of DU 174. For example, the radio configuration may include PHY configuration, MAC configuration, and / or RLC configuration. In other implementations, the radio configuration may be a CellGroupConfig information element (IE) as defined in 3GPP specification 38.331. In other implementations, the radio configuration includes configuration parameters in an RRCReconfiguration message conforming to 3GPP TS 38.331, an RRCReconfiguration-IE, or a CellGroupConfig IE. In other implementations, the radio configuration includes configuration parameters in an RRCConnectionReconfiguration message conforming to 3GPP TS 36.331, or a RadioResourceConfigDedicatedIE.

[0099] In some implementations, CU 172 may apply one or more security functions to the RRC recovery message (i.e., an RRC PDU including the RRC recovery message), generate a DL PDCP PDU including the security protection of the RRC recovery message, and transmit 322 CU-DU messages including the DL PDCP PDU to DU 174. DU 174 then transmits 324 at least one DL MAC PDU including the DL PDCP PDU to UE 102. In one implementation, DU 174 may generate a DL MAC PDU including the DL PDCP PDU and send the DL MAC PDU to UE 102. More specifically, DU 174 may generate a DL RLC PDU including the DL PDCP PDU, include the DL RLC PDU in the DL MAC PDU, and send 324 DL MAC PDUs to UE 102. In another implementation, DU 174 may segment the DL PDCP PDU into multiple segments and generate multiple DL MAC PDUs, where each DL MAC PDU includes a specific segment. When UE 102 receives all segments, UE 102 assembles these segments to obtain a DL PDCP PDU. More specifically, DU 174 can generate a DL RLC PDU segment that includes a specific segment of the DL PDCP PDU, include the DL RLC PDU segment in a DL MAC PDU, and send the DL MAC PDU to UE 102. When UE 102 receives all DL RLC PDU segments, UE 102 assembles these segments to obtain a DL PDCP PDU.

[0100] In response to the RRC recovery message, UE 102 transitions to the connected state (326) and sends an RRC recovery complete message (332) to DU 174. DU 174 then sends a DU-to-CU message (333) to CU 172, which includes the RRC recovery complete message. Events 316, 318, 320, 322, 324, 326, 328, 330, 332, and 333 are collectively referred to as non-EDT configuration procedure 390.

[0101] After UE 102 transitions to the connected state, UE 102 performs 334 UL data communication and / or 336 DL data communication with CU 172 via DU 174. More specifically, UE 102 may send one or more 334 UL PDCP PDUs to DU 174, where the SN starts from K+1. Similarly, CU 172 may send one or more 336 DL PDCPPDUs to UE 102 via DU 174, where the SN starts from M+1. In some implementations, the UL PDCP PDUs at events 312 and 334 may be associated with a first radio bearer (e.g., DRB) and / or a first Quality of Service (QoS) flow. In other implementations, the DL PDCP PDUs at events 314 and 336 may be associated with a second radio bearer (e.g., DRB) and / or a second Quality of Service (QoS) flow. The first radio bearer and the second radio bearer may be the same or different.

[0102] In some implementations, UE 102 may (re)establish 328RLC and / or reset MAC in response to an RRC recovery message. In some implementations, UE 102 uses the UE RLC entity to transmit 312UL PDCP PDUs or ULRLC PDUs including UL PDCP PDUs, and uses the UE MAC entity to transmit 312UL MAC PDUs, as described above. UE 102 uses the UE RLC entity to receive 314DL PDCP PDUs or DL ​​RLC PDUs including DL PDCP PDUs as described above, and uses the UE MAC entity to receive 314DL MAC PDUs, as described above. In some implementations, UE 102 may rebuild the 328UERLC entity and / or reset the UE MAC entity in response to an RRC recovery message. UE 102 then uses the rebuilt UE RLC entity and / or the reset MAC entity to perform data communication with DU 174 via 334, 336, and DU 174. Alternatively, UE 102 may, in response to an RRC recovery message, release the UE RLC entity and / or the UE MAC entity and establish a new UE RLC entity and / or a new UE MAC entity. UE 102 then utilizes the new UE RLC entity and / or the new UE MAC entity to perform data communication with DU 174 via 334, 336, and DU 174.

[0103] Similarly, DU 174 may (re)establish 328RLC and / or reset MAC in response to DU 174 receiving UE Context Request message 318 or DU 174 receiving CU to DU message 322. In some implementations, DU 174 uses the DU RLC entity to send 314DL PDCP PDU or DL ​​RLC PDU including DL PDCP PDU, and uses the DU MAC entity to send 314DL MAC PDU. As described above, DU 174 uses the DU RLC entity to receive 312UL PDCP PDU or UL RLC PDU including ULPDCP PDU, and uses the DU MAC entity to receive 312UL MAC PDU. In response to DU 174 receiving UE Context Request message 318 or DU 174 receiving CU to DU message 322, DU 174 may rebuild 330DURLC entity and / or reset DU MAC entity. Then, DU 174 performs data communication with UE 102 using the reconstructed RLC entity and / or the reset MAC entity, as described in steps 334 and 336. Alternatively, in response to DU 174 receiving the UE Context Request message 318 or in response to DU 174 receiving the CU-DU message 322, DU 174 may release the DU RLC entity and / or the DU MAC entity and establish a new UE RLC entity and / or a new UE MAC entity. DU 174 then performs data communication with UE 102 using the new DU RLC entity and / or the new DU MAC entity, as described in steps 334 and 336.

[0104] In other implementations, UE 102 may avoid (re)establishing and / or releasing the RLC (e.g., the (new) UE RLC entity) and / or resetting and / or releasing (e.g., the (new) UE MAC entity) in response to an RRC recovery message. Similarly, in response to a UE Context Request message received by DU 174 at 318 or a CU-to-DU message received by DU 174 at 322, DU 174 may avoid (re)establishing and / or releasing the RLC (e.g., the (new) DU RLC entity) and / or resetting and / or releasing the MAC (e.g., the (new) DU MAC entity).

[0105] In some implementations, CU 172 can be implemented using an integrity key (e.g., K...). RRCint Key) and / or encryption key (e.g., K RRCencA key is used to apply one or more security features (e.g., encryption and / or integrity protection) to the RRC recovery message (i.e., the RRC PDU including the RRC recovery completion message). Then, CU 172 generates a DL PDCP PDU including the security protections in the RRC recovery message and sends the DL PDCP PDU to DU 174, which in turn sends the DL PDCP PDU to UE 102. In one implementation, DU 174 may generate a DL MAC PDU including the DL PDCP PDU and send the DL MAC PDU to UE 102. UE 102 retrieves the DL PDCP PDU from the DL MAC PDU. More specifically, DU 174 may generate a DL RLC PDU including the DL PDCP PDU, include the DL RLC PDU in the DL MAC PDU, and send the DL MAC PDU to UE 102. UE 102 retrieves the DL PDCP PDU from the DL MAC PDU and DL RLC PDU. In another implementation, DU 174 can segment the DL PDCP PDU into multiple segments and generate multiple DL MAC PDUs including specific segments. When UE 102 receives all segments, UE 102 assembles these segments to obtain the DL PDCP PDU. More specifically, DU 174 can generate DL RLC PDU segments, each DL RLC PDU segment including a specific segment of the DL PDCP PDU, include the specific DL RLC PDU segments in a specific DL MAC PDU, and send the specific DL MAC PDU to UE 102. When UE 102 receives all DL RLC PDU segments from the DL MAC PDU, UE 102 assembles these segments to obtain the DL PDCP PDU. When UE 102 receives the DL PDCP PDU, UE 102 uses an integrity key (e.g., K...) to... RRCint Key) and / or encryption key (e.g., K RRCenc A key (i.e., the same integrity and / or encryption key as the one applied to the RRC recovery message in CU 172) is used to apply one or more security functions (e.g., decryption and / or integrity checks) to the DL PDCP PDU to obtain a (non-securely protected) RRC recovery message.

[0106] In some implementations, UE 102 can be configured to use an integrity key (e.g., K...). RRCint Key) and / or encryption key (e.g., K RRCencA key is used to apply one or more security features (e.g., encryption and / or integrity protection) to the RRC recovery completion message (i.e., the RRC PDU including the RRC recovery completion message). Then, UE 102 generates a UL PDCP PDU including the security protections in the RRC recovery completion message and sends the UL PDCP PDU to DU 174 via 332. DU 174 then sends a DU-to-CU message including the UL PDCP PDU to CU 172 via 333. In one implementation, UE 102 may generate a UL MAC PDU including the UL PDCP PDU and send the UL MAC PDU to UE 102. DU 174 retrieves the UL PDCPPDU from the UL MAC PDU. More specifically, UE 102 may generate a UL RLC PDU including the UL PDCP PDU, include the UL RLC PDU in the UL MAC PDU, and send the UL MAC PDU to DU 174 via 332. DU 174 retrieves the UL PDCP PDU from the UL MAC PDU and UL RLC PDU. Then, as described above, DU 174 sends the UL PDCP PDU to CU 172. In another implementation, UE 102 can segment the UL PDCP PDU into multiple segments and generate multiple MAC PDUs including specific segments. When DU 174 receives all segments, DU 174 assembles these segments to obtain the UL PDCP PDU. More specifically, UE 102 can generate ULRLC PDU segments, each UL RLC PDU segment including a specific segment of the UL PDCP PDU, include the specific UL RLC PDU segment in a specific UL MAC PDU, and send the specific UL MAC PDU to DU 174. When DU 174 receives all UL RLC PDU segments from the UL MAC PDU, DU 174 assembles these segments to obtain the UL PDCP PDU. When CU 172 receives a 333UL PDCP PDU, CU 172 uses an integrity key (e.g., K) RRCint Key) and / or encryption key (e.g., K RRCenc A key (i.e., the same integrity and / or encryption key that UE 102 applies to the RRC recovery completion message) is used to apply one or more security functions (e.g., decryption and / or integrity checks) to the UL PDCP PDU to obtain a (non-securely protected) RRC recovery completion message.

[0107] In some implementations, UE 102 can be configured to use an integrity key (e.g., K...). UPint Key) and / or encryption key (e.g., K UPencA key is used to apply one or more security functions (e.g., encryption and / or integrity protection) to UL data packets in UL PDCP PDUs 304, 312, and 334. For each UL data packet, UE 102 generates a UL PDCP PDU that includes specific security protections for the UL data packet, and sends the securely protected UL PDCP PDU to CU 172 via DU 174 at events 304, 306, 312, and 334, respectively. In such an implementation, CU 172 uses an integrity key (e.g., K...) to apply one or more security functions (e.g., encryption and / or integrity protection) to UL data packets in UL PDCP PDUs 304, 312, and 334. UPint Key) and / or encryption key (e.g., K UPenc (i.e., the integrity key used by UE 102, e.g., K) UPint Key) and / or encryption key (e.g., K UPenc (Using the same key) to apply one or more security functions (e.g., decryption and / or integrity checks) to a UL data packet received in a UL PDCP PDU at events 306, 312, or 334 with security protection to obtain a (non-security protected) UL data packet.

[0108] In other implementations, CU 172 can use an integrity key (e.g., K...). UPint Key) and / or encryption key (e.g., K UPenc A security key is used to apply one or more security functions (e.g., encryption and / or integrity protection) to DL data packets in DL PDCP PDUs 314 and 336. For each DL data packet, CU 172 generates a DL PDCP PDU that includes specific security protections for the DL data packet, and sends the securely protected DL PDCPPDU to UE 102 via DU 174 at events 314 and 336, respectively. In such an implementation, UE 102 uses an integrity key (e.g., K...) to apply one or more security functions (e.g., encryption and / or integrity protection) to DL data packets in DL PDCP PDUs 314 and 336. UPint Key) and / or encryption key (e.g., K UPenc (i.e., the integrity key used with CU 172, e.g., K) UPint Key) and / or encryption key (e.g., K UPenc (Using the same key) to apply a security function (e.g., decryption and / or integrity check) to the securely protected DL data packets received in the DL PDCP PDU at events 314 and 336 to obtain (unsecurely protected) DL data packets.

[0109] In this way, despite the transition from an inactive state to a connected state, UE 102 and BS104 can continue to transmit UL and / or DL ​​data packets, starting with sequence number K+1 for UL PDCP PDUs and sequence number M+1 for DL ​​PDCP PDUs.

[0110] Next reference Figure 3B Scene 300B is depicted, which is generally similar to scene 300A. Events in this scene, similar to those discussed above, are labeled with the same reference numerals, and... Figure 3A Examples and implementations can be applied to Figure 3B In scenario 300B, after transitioning to a connected state, UE 102 and CU 172 reconstruct the corresponding PDCP entities and restart the sequence numbering for continuing UL and / or DL ​​PDCP PDUs. This is discussed further below. Figure 3A and Figure 3B The differences between the scenarios.

[0111] In scenario 300B, as part of the non-EDT configuration procedure 390, UE 102 transitions to a connected state, and UE 102 and CU 172 (re)establish PDCP entities corresponding to 340 and 342. When the two PDCP entities are (re)established, UE 172 performs 335 UL data communication and / or 337 DL data communication with CU 172 via DU 174. More specifically, UE 102 may send one or more UL PDCP PDUs (335) to DU 174, where the SN restarts from 0. Similarly, CU 172 may send one or more DL PDCP PDUs (337) to UE 102 via DU 174, where the SN restarts from 0. In some implementations, the UL PDCP PDUs at events 312 and 335 may be associated with a first radio bearer (e.g., DRB) and / or a first Quality of Service (QoS) flow. In other implementations, the DL PDCP PDUs at events 314 and 337 may be associated with a second radio bearer (e.g., a DRB) and / or a second Quality of Service (QoS) flow. The first and second radio bearers may be the same or different.

[0112] In some implementations, UE 102 can (re)establish 340PDCP in response to an RRC recovery message. In some implementations, UE 102 uses the UE PDCP entity to send a 312UL PDCP PDU or a UL RLC PDU including a UL PDCP PDU, and uses the UE PDCP entity to receive a 314DL PDCP PDU or a DL RLC PDU including a DL PDCP PDU, as described above. In some implementations, UE 102 can rebuild the 340UE PDCP entity in response to an RRC recovery message. Then, UE 102 performs data communications 335, 337 with CU 172 via DU 174 to the rebuilt UE PDCP entity. Alternatively, UE 102 can release the UE PDCP entity and establish a new UE PDCP entity in response to an RRC recovery message. Then, UE 102 performs data communications 335, 337 with CU 172 via DU 174 to the new UE PDCP entity.

[0113] Similarly, CU 172 can (re)establish 342PDCP in response to determination 316 to transition the UE to a connected state. In some implementations, CU 172 uses the CU PDCP entity to send 314DL PDCP PDUs and uses the CU PDCP entity to receive 312UL PDCP PDUs, as described above. In some implementations, CU 172 can rebuild the 342CU PDCP entity in response to making determination 316, sending a 318 UE context request message, receiving a 320 UE context response message, or sending a 322RRC recovery message, or after making determination 316, sending a 318 UE context request message, receiving a 320 UE context response message, or sending a 322RRC recovery message. Then, CU 172 performs data communication with UE 102 via DU 174 and the rebuilt CU PDCP entity, steps 335 and 337. Alternatively, CU 172 may, in response to making determination (316), sending a UE context request message (318), receiving a UE context response message (320), or sending a RRC recovery message (322), or after making determination (316), sending a UE context request message (318), receiving a UE context response message (320), or sending a RRC recovery message (322), release the CU PDCP entity and establish a new CU PDCP entity. Then, CU 172 performs data communication with UE 102 via DU 174 and the new CU PDCP entity (335, 337).

[0114] In other implementations, UE 102 may avoid (re)establishing and / or releasing PDCP (e.g., a (new) UE PDCP entity) in response to an RRC recovery message. Similarly, CU 172 may avoid (re)establishing PDCP (e.g., a (new) CU PDCP entity) in response to determination 316 transitioning the UE to a connected state.

[0115] Next reference Figure 3C Scene 300C is depicted, which is generally similar to scene 300A. Events in this scene, similar to those discussed above, are labeled with the same reference numerals, and... Figure 3A Examples and implementations can be applied to Figure 3C The difference between scenario 300C and scenario 300A is that the UE initiates the 381 Initial UL Early Data Communication without an Initial UL PDCP PDU. This will be discussed further below. Figure 3A and Figure 3C The differences between the scenarios.

[0116] In scenario 300C, UE 102, in an inactive state, initiates initial early data communication (381) to send uplink (UL) data or receive downlink (DL) data. In response to or after initiating early data communication, UE 102 generates an initial UL MAC PDU including a UL RRC message but without a UL PDCP PDU, and sends the initial UL MAC PDU (305) to DU 174 on cell 124. DU 174 retrieves the UL RRC message from the initial UL MAC PDU and generates an Initial UL RRC Message Transfer message including the UL RRC message. DU 174 then sends an Initial UL RRC Message Transfer message (307) to CU 172.

[0117] After sending the initial UL MAC PDU 381, UE 102 may send one or more UL PDCP PDUs 313 with SN = 0, ..., K to DU 174, where K is an integer greater than 0. UE 102 may send UL MAC PDUs 313 comprising one or more UL PDCP PDUs to DU 174. DU 174 forwards one or more UL PDCP PDUs to CU 172 via a control plane interface (e.g., F1-C or W1-U) or a user plane interface (F1-U or W1-U). UE 102 may include application data packets, RRC messages, or NAS PDUs in a particular UL PDCP PDU. In some implementations, the UL MAC PDU in one or more UL MAC PDUs may include a particular UL PDCP PDU or segments comprising a particular UL PDCP PDU. In other implementations, UE 102 may send 313 UL MAC PDUs comprising at least two UL PDCP PDUs from K UL PDCP PDUs. In some implementations, UE 102 may include a specific UL PDCP PDU in a UL RLC PDU and a UL RLC PDU in one or more UL MAC PDUs. In other implementations, UE 102 may include segments of a specific UL PDCP PDU in UL RLC PDU segments, other segments of UL PDCP PDUs in other UL RLC PDU segments, and other UL RLCPDU segments in one or more UL MAC PDUs. In other implementations, UE 102 may send 313 UL MACPDUs comprising at least two UL RLC PDUs, each UL RLC PDU comprising a specific UL PDCP PDU from K UL PDCP PDUs. When DU 174 receives all segments of the UL PDCP PDU from UE 102, DU 174 assembles these segments to obtain the UL PDCP PDU and sends the UL PDCP PDU to CU 172.

[0118] Next reference Figure 3DThe document describes scenario 300D, which combines aspects of scenario 300B with aspects of scenario 300C. Specifically, in scenario 300D, an inactive UE 102 initiates initial early data communication 381 to send uplink (UL) data or receive downlink (DL) data. After sending the initial UL MAC PDU, UE 102 can send one or more UL PDCP PDUs 313 with SN = 0, ..., K to DU 174, where K is an integer greater than 0. Additionally, in scenario 300D, UE 102 can (re)establish 340 PDCP in response to an RRC recovery message, as in scenario 300B. More specifically, UE 102 can (re)establish a 340 UE PDCP entity in response to an RRC recovery message. UE 102 uses the UE PDCP entity to send 313 UL PDCP PDUs or UL RLC PDUs including UL PDCP PDUs, as described above. UE102 uses the UE PDCP entity to receive 314DL PDCP PDU or DL ​​RLC PDU including DL PDCP PDU, as described above. Similarly, CU 172 can (re)establish 342PDCP in response to determination 316 that the UE has transitioned to a connected state. More specifically, CU 172 can (re)establish 342CU PDCP entity in response to determination 316 that the UE has transitioned to a connected state.

[0119] Next reference Figure 3E Scene 300E is depicted, which is generally similar to scene 300A. Events in this scene, similar to those discussed above, are labeled with the same reference numerals, and... Figure 3A Examples and implementations can be applied to Figure 3E The difference between Scenario 300E and Scenario 300A is that CU 172 sends an RRC establishment message instead of an RRC recovery message during non-EDT configuration. This will be discussed further below. Figure 3A and Figure 3E The differences between the scenarios.

[0120] In scenario 300E, during the non-EDT configuration process 392, CU 172 receives 320 radio configuration from DU, generates an RRC establishment message including the radio configuration, and sends 323 a CU-DU message including the RRC establishment message to DU 174. Then, DU 174 retrieves the RRC establishment message from the CU-DU message and sends the RRC establishment message 325 to UE 102. In this way, the connection is restarted, instead of restoring the connection with base station 104 as described in scenario 300A.

[0121] As a result, UE 102 can release 350 RLC and / or reset MAC in response to an RRC establishment message. For example, UE 102 can release 350 the RLC entity used by UE 102 to transmit UL data in the initial data communication 380 in response to an RRC establishment message. In response to the RRC establishment message, UE 102 sends 327 an RRC establishment complete message to DU 174. Then, DU 174 forwards the RRC establishment complete message 329 to CU 172 in a DU to CU message. Similarly, DU 174 can release 352 RLC and / or reset MAC in response to a UE Context Request message 318 received by DU 174 or a CU to DU message 323 received by DU 174. For example, in response to a CU to DU message 323 received by DU 174, DU 174 can release 355 the DU RLC entity used by DU 174 to receive UL data in the initial data communication 380.

[0122] Additionally, UE 102 may optionally send a 346 NAS message to DU 174. DU 174 then forwards the NAS message 354 to CU 172 in a DU-to-CU message. In response, CU 172 sends a 356 secure mode command to DU 174 in a CU-to-DU message, and DU 174 forwards the secure mode command 358 to UE 102. In response to the secure mode command, UE 102 sends a 360 secure mode complete message to DU 174, and DU 174 forwards the secure mode complete message 362 to CU 172 in a DU-to-CU message. UE 102 and CU 172 can derive at least one security key (i.e., a new security key) from the configuration parameters included in the secure mode command message, and apply the at least one new security key to messages exchanged between UE 102 and CU 172 (e.g., events 374, 376) as well as DL data communication 337 and UL data communication 335 in a similar manner to the above.

[0123] In response to receiving a safe mode complete message, CU 172 may send a 364 UE Context Request message to DU 174 to obtain the radio configuration for UE 102. In response, DU 174 sends a 366 UE Context Response, which includes the radio configuration for UE 102. In some implementations, the UE Context Request message and the UE Context Response message may be a UE Context Setup Request message and a UE Context Setup Response message, respectively. In other implementations, the UE Context Request message and the UE Context Response message may be a UE Context Modification Request message and a UE Context Modification Response message, respectively.

[0124] CU 172 sends a 372RRC reconfiguration message to DU 174 in a CU to DU message. Then, DU 174 forwards a 374RRC reconfiguration message to UE 102. In response, UE 102 sends a 376RRC reconfiguration complete message to DU 174, and DU 174 forwards the RRC reconfiguration complete message 378 to CU 172 in a DU to CU message.

[0125] In some implementations, UE 102 can establish a 368 RLC in response to an RRC reconfiguration message. More specifically, UE 102 can establish a new UE RLC entity (368) in response to an RRC reconfiguration message. Similarly, DU 174 can establish a 370 RLC in response to DU 174 receiving a UE Context Request message (364). More specifically, DU 174 can establish a new DU RLC entity (368) in response to DU 174 receiving a UE Context Request message (364).

[0126] Figures 4-37 It is a flowchart depicting a method that a UE (e.g., UE 102), a RAN (e.g., RAN 105) node (e.g., CU 172, DU 174, base station 104) or RAN can perform to manage data communication between the UE and RAN before and after the state transition from an inactive state to a connected state. Figures 4-6 An example method is shown for resetting or rebuilding MAC, RLC, and PDCP entities at the RAN to manage data communication before and after transitioning to a connected state. In contrast, Figures 10-12An example method is shown for maintaining (or avoiding reset or rebuild) MAC, RLC, and PDCP entities at the RAN to manage data communication before and after transitioning to a connected state. At the UE, Figures 19-21 Example methods are shown for resetting or rebuilding MAC, RLC, and PDCP entities to manage data communication before and after transitioning to a connected state. In contrast, Figures 25-27 An example method is shown for maintaining (or avoiding reset or rebuild) MAC, RLC, and PDCP entities at the UE to manage data communication before and after transitioning to a connected state.

[0127] Figure 4 This is a flowchart of an example method 400 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105).

[0128] In box 402, the RAN node performs early data communication with the UE operating in an inactive state using the MAC entity (e.g., events 304, 306, 312, 314). In box 404, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In box 406, the RAN node resets the MAC entity in response to transitioning the UE to a connected state (e.g., event 330). In box 408, the RAN node performs data communication with the UE operating in a connected state using the reset MAC entity (e.g., events 334, 336, 335, 337).

[0129] Figure 5 This is a flowchart of an example method 500 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105).

[0130] At block 502, the RAN node performs early data communication with the UE operating in an inactive state using the RLC entity (e.g., events 304, 306, 312, 314). At block 504, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). At block 506, the RAN node reconstructs the RLC entity in response to transitioning the UE to a connected state (e.g., event 330). At block 508, the RAN node performs data communication with the UE operating in a connected state using the reconstructed RLC entity (e.g., events 334, 336, 335, 337).

[0131] Figure 6This is a flowchart of an example method 600 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105).

[0132] In box 602, the RAN node performs early data communication with a UE operating in an inactive state using the PDCP entity (e.g., events 304, 306, 312, 314). In box 604, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In box 606, the RAN node reconstructs the PDCP entity in response to transitioning the UE to a connected state (e.g., event 342). In box 608, the RAN node performs data communication with a UE operating in a connected state using the reconstructed PDCP entity (e.g., events 335, 337).

[0133] Figure 7A This is a flowchart of an example method 700A for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). In method 700A, when the UE transitions from an inactive state to a connected state, the RAN node refreshes the HARQ buffer associated with the HARQ process number. In this way, the HARQ process number is reset, causing HARQ transmissions associated with the HARQ process to be scheduled as new transmissions.

[0134] In block 702A, the RAN node performs early data communication with the UE operating in an inactive state (e.g., events 304, 306, 312, 314). The RAN node sends a first downlink control information (DCI) to the UE to schedule the UE to receive a HARQ transmission. In block 704A, the RAN node sends a HARQ transmission to the UE during the early data communication using a HARQ process(number) (e.g., event 314). In block 706A, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In block 708A, the RAN node refreshes the HARQ buffer associated with the HARQ process(number) in response to the transition. After refreshing the HARQ buffer, the RAN node generates the next HARQ transmission associated with the HARQ process as a new transmission for the UE operating in the connected state. The RAN node sends a second DCI to the UE to schedule the UE to receive the next HARQ transmission after transitioning the UE to the connected state. The RAN node may include the same HARQ process number in both the first and second DCIs.

[0135] In some implementations, the UE uses a soft buffer associated with a HARQ process(number) to receive HARQ transmissions of the MAC PDU. The UE refreshes the soft buffer in response to a transition to the connected state. After refreshing the soft buffer, the UE determines the next HARQ transmission associated with the HARQ process(number) as a new transmission. The UE attempts to receive the DCI after transitioning to the connected state. Based on the DCI, the UE receives the next HARQ transmission and determines it as a new transmission.

[0136] Figure 7B This is a flowchart of an example method 700B for managing data communication before and after the state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). Method 700B is as follows: Figure 7A The alternative to method 700A is shown. In method 700B, when the UE transitions from an inactive state to a connected state, the RAN node sends a HARQ transmission using a different HARQ process number than the one used for HARQ transmissions when the UE was in an inactive state.

[0137] In box 702B, the RAN node performs early data communication with the UE operating in an inactive state (e.g., events 304, 306, 312, 314). In box 704B, the RAN node sends a HARQ transmission to the UE during early data communication using a HARQ process(number) (e.g., event 314). In box 706B, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In box 707B, the RAN node avoids using a HARQ process(number) to send a HARQ transmission to the UE operating in a connected state. In box 710B, after transitioning to a connected state, the RAN node sends a HARQ transmission to the UE using a different HARQ process number that the UE did not use during early data communication.

[0138] Figure 7CThis is a flowchart of an example method 700C for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). In example method 700C, after the UE transitions from an inactive state to a connected state, the reset MAC PDU is assigned a New Data Indicator (NDI) to indicate new data. This is because the HARQ buffer may not be maintained during the state change. If the RAN node receives a HARQ acknowledgment for a HARQ transmission of a MAC PDU sent when the UE was in an inactive state, the RAN node sends a new HARQ transmission of a subsequent MAC PDU to the UE. If the RAN node receives a HARQ NACK or does not receive a HARQ acknowledgment for a HARQ transmission of a MAC PDU sent when the UE was in an inactive state, the RAN node sends a new HARQ transmission of the MAC PDU, but with an NDI indicating new data to be restarted in the connected state.

[0139] In block 702C, the RAN node performs early data communication with the UE in an inactive state (e.g., events 304, 306, 312, 314). In block 705C, during the early data communication, the RAN node sends a HARQ transmission of the first MAC PDU to the UE using a HARQ process number (e.g., event 314). In block 706C, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In block 709C, the RAN node determines whether it has received a HARQ acknowledgment for the HARQ transmission of the first MAC PDU. If the RAN node receives a HARQ acknowledgment for the HARQ transmission of the first MAC PDU, then in block 711C, the RAN node sends a new HARQ transmission of the second MAC PDU to the UE operating in the connected state using a HARQ process number (e.g., events 336, 337).

[0140] If the RAN node does not receive a HARQ acknowledgment for the HARQ transmission of the first MAC PDU, then at block 712C, the RAN node sends a new HARQ transmission of the first MAC PDU to the UE operating in the connected state using the HARQ process (number). Alternatively, the RAN node does not send a HARQ transmission of the first MAC PDU at block 712C. In this alternative, the RAN node may refresh the HARQ buffer storing the first MAC PDU.

[0141] Figure 8This is a flowchart of an example method 800 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). In example method 800, the RAN node restarts the sequence numbering of DL PDCP PDUs associated with the same radio bearer after transitioning the UE to the connected state, as... Figure 3B As shown.

[0142] In box 802, the RAN node performs early data communication with the UE operating in an inactive state (e.g., events 304, 306, 312, 314). In box 804, the RAN node performs sequence numbering on SDUs with sequence numbers 0, ..., X-1, and generates a PDU for each SDU, including a specific SDU and a specific sequence number, where X is an integer greater than 0 (e.g., events 304, 306, 312, 314). In box 806, the RAN node communicates the PDU associated with the radio bearer to the UE during early data communication (e.g., events 304, 306, 312, 314). In box 808, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In block 810, the RAN node performs sequence numbering on subsequent SDUs with sequence numbers 0, ..., Y-1, and generates a PDU for each subsequent SDU, including the specific SDU and the specific sequence number, where Y is an integer greater than 0 (e.g., events 335, 337). At block 812, the RAN node communicates the subsequent PDUs associated with the radio bearer to the UE operating in connected state (e.g., events 335, 337). In some implementations, the PDU may be a PDCP PDU or an RLC PDU.

[0143] Figure 9 This is a flowchart of an example method 900 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). After the transition from an inactive state to a connected state, the flowchart uses state variables to track and (re)set and / or (re)establish according to... Figure 4-6 Any of the RLC, MAC and / or PDCP entities.

[0144] In block 902, the RAN node performs early data communication with the UE operating in an inactive state (e.g., events 304, 306, 312, 314). In block 904, the network node uses state variables to communicate PDUs to the UE during early data communication (e.g., events 304, 306, 312, 314). In block 906, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In block 908, the RAN node (re)sets the state variables to their initial values ​​in response to transitioning the UE from an inactive state to a connected state (e.g., events 330, 342). In block 910, the RAN node uses the state variables to communicate PDUs to the UE operating in a connected state (e.g., events 334, 336, 335, 337). In some implementations, the PDU may be a PDCP PDU or an RLC PDU.

[0145] Figure 10 This is a flowchart of an example method 1000 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105).

[0146] In box 1002, the RAN node performs early data communication with a UE operating in an inactive state using the MAC entity (e.g., events 304, 306, 312, 314). In box 1004, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In box 1006, the RAN node avoids resetting the MAC entity in response to transitioning the UE to a connected state. In box 1008, the RAN node performs data communication with a UE operating in a connected state using the MAC entity (e.g., events 334, 336, 335, 337).

[0147] Figure 11 This is a flowchart of an example method 1100 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105).

[0148] In box 1102, the RAN node performs early data communication with a UE operating in an inactive state using an RLC entity (e.g., events 304, 306, 312, 314). In box 1104, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In box 1106, the RAN node avoids rebuilding the RLC entity in response to transitioning the UE to a connected state. In box 1108, the RAN node performs data communication with a UE operating in a connected state using an RLC entity (e.g., events 334, 336, 335, 337).

[0149] Figure 12 This is a flowchart of an example method 1200 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105).

[0150] At block 1202, the RAN node performs early data communication with a UE operating in an inactive state using the PDCP entity (e.g., events 304, 306, 312, 314). At block 1204, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). At block 1206, the RAN node avoids rebuilding the PDCP entity in response to transitioning the UE to a connected state. At block 1208, the RAN node performs data communication with a UE operating in a connected state using the PDCP entity (e.g., events 334, 336).

[0151] Figure 13A This is a flowchart of an example method 1300A for managing data communication before and after the state transition from an inactive to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). Figure 7A Compared to method 700A, in method 1300A, the RAN node transmits the HARQ retransmission of the MAC PDU after the UE transitions from an inactive state to a connected state, instead of a new HARQ transmission.

[0152] In box 1302A, the RAN node performs early data communication with a UE operating in an inactive state (e.g., events 304, 306, 312, 314). In box 1304A, the RAN node transmits HARQ PDUs to the UE during early data communication using a HARQ process (e.g., events 304, 306, 312, 314). In box 1306A, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In box 1308A, the RAN node retransmits HARQ PDUs to the UE operating in a connected state using a HARQ process (e.g., events 322, 324).

[0153] Figure 13B This is a flowchart of an example method 1300B for managing data communication before and after the state transition from an inactive to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). Figure 7B Compared to method 700B, in method 1300B, the RAN node switches the NDI for the next HARQ retransmission associated with the HARQ process number after the UE transitions from an inactive state to a connected state, instead of using a different HARQ process number.

[0154] In box 1302B, the RAN node performs early data communication with the UE operating in an inactive state (e.g., events 304, 306, 312, 314). In box 1304B, the RAN node communicates HARQ transmissions of the MAC PDU with the UE during early data communication using a HARQ process (e.g., events 304, 306, 312, 314). In box 1306B, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In box 1307B, after transitioning the UE to a connected state, the RAN node toggles the new data indicator for the next HARQ transmission associated with the HARQ process (e.g., events 334, 336, 335, 337). In box 1309B, the RAN node communicates the next HARQ transmission with the UE operating in a connected state using a HARQ process (e.g., events 334, 336, 335, 337).

[0155] Figure 14This is a flowchart of an example method 1400 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). In example method 1400, after transitioning the UE to the connected state, the RAN node continues sequence numbering for DL ​​PDCP PDUs associated with the same radio bearer using a number following the last sequence number of the DL PDCP PDU when the UE was in an inactive state, such as... Figure 3A As shown. This is similar to... Figure 8 In contrast to method 800, in method 800, when the UE transitions from an inactive state to a connected state, the RAN node restarts the sequence number.

[0156] In box 1402, the RAN node performs early data communication with the UE operating in an inactive state (e.g., events 304, 306, 312, 314). In box 1404, the RAN node performs sequence numbering on SDUs with sequence numbers 0, ..., X-1, and generates a PDU for each SDU, including a specific SDU and a specific sequence number, where X is an integer greater than 0 (e.g., events 304, 306, 312, 314). In box 1406, the RAN node communicates the PDU associated with the radio bearer to the UE during early data communication (e.g., events 304, 306, 312, 314). In box 1408, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In block 1410, the RAN node performs sequence numbering on subsequent SDUs with sequence numbers X, ..., Y-1, and generates a PDU for each subsequent SDU, including a specific SDU and a specific sequence number, where Y is an integer greater than X (e.g., events 334, 336). In block 1412, the RAN node communicates the subsequent PDUs associated with the radio bearer to the UE operating in the connected state (e.g., events 334, 336). In some implementations, the PDU may be a PDCP PDU or an RLC PDU.

[0157] Figure 15 This is a flowchart of an example method 1500 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). After the transition from an inactive state to a connected state, the flowchart uses state variables to track and (re)set and / or (re)establish according to... Figure 4-6 Any of the RLC, MAC, and / or PDCP entities. (Similar to...) Figure 9Compared to method 900, in method 900, the RAN node retains state variables after the UE transitions from an inactive state to a connected state.

[0158] In block 1502, the RAN node performs early data communication with the UE operating in an inactive state (e.g., events 304, 306, 312, 314). In block 1504, the network node uses state variables to communicate PDUs to the UE during early data communication (e.g., events 304, 306, 312, 314). In block 1506, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In block 1508, the RAN node maintains the state variables (with their values) at their initial values ​​in response to transitioning the UE from an inactive state to a connected state. In block 1510, the RAN node uses state variables to communicate PDUs to the UE operating in a connected state (e.g., events 334, 336, 335, 337). In some implementations, the PDU may be a PDCP PDU or an RLC PDU.

[0159] Figure 16 This is a flowchart of an example method 1600 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). In method 1600, when the UE is in an inactive state, the UE fails to convey an acknowledgment of a PDU sent by the RAN node, or when the UE is in an inactive state, the UE conveys an indication that the UE has not received at least one PDU sent by the RAN node. Therefore, when the UE is in a connected state, the RAN node can retransmit the PDU to the UE.

[0160] In block 1602, the RAN node communicates a PDU to the UE operating in an inactive state (e.g., events 304, 306, 312, 314). In block 1604, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In block 1606, the RAN node communicates information to the UE operating in the connected state indicating that at least one of the PDUs has not been received. In block 1608, the RAN node communicates at least one PDU to the UE based on this information. In some implementations, the PDU may be a PDCP PDU or an RLC PDU. For example, the RAN node (e.g., base station 104, DU 174, or RAN 105) receives an RLC status PDU including this information from the UE operating in the connected state. In another example, the RAN node (e.g., base station 104, CU 172, or RAN 105) receives a PDCP control PDU including this information from the UE operating in the connected state. In yet another example, the RAN node (e.g., base station 104, CU 172, or RAN 105) receives an RRC message containing this information from a UE operating in connected state.

[0161] For example, a RAN node (e.g., base station 104, DU 174, or RAN 105) sends an RLC status PDU including this information to a UE operating in a connected state, and receives at least one RLC PDU from a UE that has sent at least one RLC PDU based on the RLC status PDU. In another example, a RAN node (e.g., base station 104, CU 172, or RAN 105) sends a PDCP control PDU including this information to a UE operating in a connected state, and receives at least one PDCP PDU from a UE that has sent at least one PDCP PDU based on the PDCP control PDU. In yet another example, a RAN node (e.g., base station 104, CU 172, or RAN 105) sends an RRC message including information from a UE operating in a connected state, and receives at least one PDU from a UE that has sent at least one PDU based on the RRC message.

[0162] Figure 17 This is a flowchart of an example method 1700 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). Method 1700 includes, as Figure 16 Additional or alternative steps to method 1600 shown. In method 1700, the RAN node sends a request to the UE operating in the connected state to request the UE to send information indicating the reception status of a PDU sent when the UE was in an inactive state.

[0163] In block 1702, the RAN node performs early data communication with the UE operating in an inactive state (e.g., events 304, 306, 312, 314). In block 1704, the RAN node sends a PDU to the UE during the early data communication (e.g., event 314). In block 1706, the RAN node transitions the UE from an inactive state to a connected state (e.g., events 322, 324). In block 1708, the RAN node sends a request to the UE operating in the connected state, requesting the UE to send information indicating the reception status of the PDU. In some implementations, the PDU may be a PDCP PDU or an RLC PDU. In some implementations, the request may be a PDU that includes a field requesting the UE to send information or an IE. The PDU may be an RLC PDU, a PDCP PDU, or an RRC message. An RLC PDU may include polling bits, or it may be a control PDU that polls the UE to send information.

[0164] Figure 18 This is a flowchart of an example method 1800 for managing data communication before and after a state transition from an inactive state to a connected state, which can be implemented in one or more RAN nodes (e.g., CU 172, DU 174, base station 104, or RAN 105). In method 1800, a first message (e.g., an RRC recovery message) indicates that the MAC, RLC, and PDCP entities should be retained, and a second message (e.g., an RRC establishment message) indicates that the MAC, RLC, and PDCP entities should be reset, rebuilt, or released in response to the UE transitioning from an inactive state to a connected state.

[0165] In block 1802, the RAN node performs early data transmission with a UE operating in an inactive state using at least one of the MAC, RLC, and PDCP entities (e.g., events 304, 306, 312, 314). In block 1804, the RAN node sends a message to the UE to transition the UE to a connected state (e.g., events 322, 324). In block 1806, the RAN node determines to proceed to block 1808 or 1810. If the message is a first message, in block 1808, the RAN node retains at least one of the MAC, RLC, and PDCP entities in response to transitioning the UE to a connected state. If the message is a second message, the RAN node resets, rebuilds, or releases at least one of the MAC, RLC, and PDCP entities in response to transitioning the UE to a connected state (e.g., events 330, 342, 352). In the case of releasing at least one of the MAC, RLC, or PDCP entities, the RAN node may establish at least one new MAC, RLC, or PDCP entity in response to transitioning the UE to a connected state. The first message can be an RRC recovery message, and the second message can be an RRC establishment message.

[0166] Figure 19 This is a flowchart of an example method 1900 that can be implemented in UE 102 for managing data communication before and after the state transition from an inactive state to a connected state.

[0167] At block 1902, UE 102, operating in an inactive state, performs early data communication with base station 104 using a MAC entity (e.g., events 304, 306, 312, 314). At block 1904, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 1906, UE 102 resets the MAC entity in response to the transition to a connected state (e.g., event 330). At block 1908, UE 102, operating in a connected state, performs data communication with base station 104 using the reset MAC entity (e.g., events 334, 336, 335, 337).

[0168] Figure 20 This is a flowchart of an example method 2000 that can be implemented in UE 102 for managing data communication before and after the state transition from an inactive state to a connected state.

[0169] At block 2002, UE 102, operating in an inactive state, performs early data communication with base station 104 using the RLC entity (e.g., events 304, 306, 312, 314). At block 2004, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2006, UE 102 reconstructs the RLC entity in response to the transition to a connected state (e.g., event 330). At block 2008, UE 102, operating in a connected state, performs data communication with base station 104 using the reconstructed RLC entity (e.g., events 334, 336, 335, 337).

[0170] Figure 21 This is a flowchart of an example method 2100 that can be implemented in UE 102 for managing data communication before and after the state transition from an inactive state to a connected state.

[0171] At block 2102, UE 102, operating in an inactive state, performs early data communication with base station 104 using the PDCP entity (e.g., events 304, 306, 312, 314). At block 2104, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2106, UE 102 reconstructs the PDCP entity in response to the transition to the connected state (e.g., event 342). At block 2108, UE 102, operating in the connected state, performs data communication with base station 104 using the reconstructed PDCP entity (e.g., events 335, 337).

[0172] Figure 22 This is a flowchart of an example method 2200, which can be implemented in UE 102, for managing data communication before and after a state transition from an inactive state to a connected state. In method 2200, when the UE transitions from an inactive state to a connected state, the UE refreshes the HARQ buffer associated with the HARQ process number. In this way, the HARQ process number is reset, causing HARQ transmissions associated with the HARQ process to be scheduled as new transmissions.

[0173] At block 2202, UE 102, operating in an inactive state, performs early data communication with base station 104 (e.g., events 304, 306, 312, 314). At block 2104, UE 102 sends a HARQ transmission to base station 104 during the early data communication using a HARQ process(number) (e.g., event 314). At block 2106, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2108, UE 102 refreshes the HARQ buffer associated with the HARQ process(number) in response to the transition. After refreshing the HARQ buffer, UE 102, operating in the connected state, generates the next HARQ transmission associated with the HARQ process as a new transmission for base station 104. In some implementations, UE 102 receives a first DCI from base station 104, thereby scheduling UE 102 to send a HARQ transmission at block 2204. At block 2204, base station 104 receives a HARQ transmission based on a first DCI. UE 102 receives a second DCI from base station 104, and schedules UE 102 to send the next HARQ transmission after UE transitions to a connected state. Base station 104 may include the same HARQ process number in both the first and second DCIs. Base station 104 receives the next HARQ transmission based on the second DCI.

[0174] In some implementations, base station 104 uses a soft buffer associated with the HARQ process(s) to receive HARQ transmissions of the MACPDU. Base station 104 refreshes the soft buffer in response to UE 102 transitioning to a connected state. After refreshing the soft buffer, base station 104 determines the next HARQ transmission associated with the HARQ process(s) as a new transmission. Base station 104 attempts to receive a UCI after the UE transitions to a connected state. Based on a second DCI, the base station receives the next HARQ transmission and determines it as a new transmission.

[0175] Figure 23 This is a flowchart of an example method 2300, which can be implemented in UE 102, for managing data communication before and after a state transition from an inactive state to a connected state. In example method 2300, the UE transitions to a state such as... Figure 3B The connection status shown will then restart the sequence numbering of the UL PDCP PDU associated with the same radio bearer.

[0176] At block 2302, UE 102, operating in an inactive state, performs early data communication with base station 104 (e.g., events 304, 306, 312, 314). At block 2304, UE 102 performs sequence numbering on SDUs with sequence numbers 0, ..., X-1, and generates a PDU for each SDU, including a specific SDU and a specific sequence number, where X is an integer greater than 0 (e.g., events 304, 306, 312, 314). At block 2306, UE 102 transmits PDUs associated with radio bearers to base station 104 during early data communication (e.g., events 304, 306, 312, 314). At block 2308, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2310, UE 102 performs sequence numbering on subsequent SDUs having sequence numbers 0, ..., Y-1, and generates a PDU for each subsequent SDU, including a specific SDU and a specific sequence number, where Y is an integer greater than 0 (e.g., events 335, 337). At block 2312, UE 102, operating in connected state, communicates subsequent PDUs associated with radio bearers to base station 104 (e.g., events 335, 337). In some implementations, the PDU may be a PDCP PDU or an RLCPDU.

[0177] Figure 24 This is a flowchart of an example method 2400, which can be implemented in UE 102, for managing data communication before and after the state transition from an inactive state to a connected state. After the transition from an inactive state to a connected state, the flowchart uses state variables to track and (re)set and / or (re)establish according to... Figure 4-6 Any of the RLC, MAC and / or PDCP entities.

[0178] At block 2402, UE 102, operating in an inactive state, performs early data communication with base station 104 (e.g., events 304, 306, 312, 314). At block 2404, UE 102 uses state variables to communicate PDUs with base station 104 during early data communication (e.g., events 304, 306, 312, 314). At block 2406, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2408, UE 102 (re)sets state variables to their initial values ​​in response to the transition from an inactive state to a connected state (e.g., events 330, 342). At block 2410, UE 102, operating in a connected state, uses state variables to communicate PDUs with base station 104 (e.g., events 334, 336, 335, 337). In some implementations, the PDU can be a PDCP PDU or an RLC PDU.

[0179] Figure 25 This is a flowchart of an example method 2500 that can be implemented in UE 102 for managing data communication before and after the state transition from an inactive state to a connected state.

[0180] At block 2502, UE 102, operating in an inactive state, performs early data communication with base station 104 using a MAC entity (e.g., events 304, 306, 312, 314). At block 2504, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2506, UE 102 avoids resetting the MAC entity in response to transitioning to a connected state. At block 2508, UE 102, operating in a connected state, performs data communication with base station 104 using a MAC entity (e.g., events 334, 336, 335, 337).

[0181] Figure 26 This is a flowchart of an example method 2600 that can be implemented in UE 102 for managing data communication before and after the state transition from an inactive state to a connected state.

[0182] At block 2602, UE 102, operating in an inactive state, performs early data communication with base station 104 using an RLC entity (e.g., events 304, 306, 312, 314). At block 2604, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2606, UE 102 avoids rebuilding the RLC entity in response to transitioning to a connected state. At block 2608, UE 102, operating in a connected state, performs data communication with base station 104 using an RLC entity (e.g., events 334, 336, 335, 337).

[0183] Figure 27 This is a flowchart of an example method 2700 that can be implemented in UE 102 for managing data communication before and after the state transition from an inactive state to a connected state.

[0184] At block 2702, UE 102, operating in an inactive state, performs early data communication with base station 104 using the PDCP entity (e.g., events 304, 306, 312, 314). At block 2704, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2706, UE 102 avoids rebuilding the PDCP entity in response to transitioning to the connected state. At block 2708, UE 102, operating in the connected state, performs data communication with base station 104 using the PDCP entity (e.g., events 334, 336).

[0185] Figure 28A This is a flowchart of an example method 2800A, which can be implemented in UE 102 to manage data communication before and after the state transition from an inactive state to a connected state. (Compared to...) Figure 22 Compared to method 2200, in method 2800A, the UE transmits a HARQ retransmission of the MAC PDU after the UE transitions from an inactive state to a connected state, instead of a new HARQ transmission.

[0186] At block 2802A, UE 102, operating in an inactive state, performs early data communication with base station 104 (e.g., events 304, 306, 312, 314). At block 2804A, UE 102 transmits HARQ messages of the MAC PDU with base station 104 during early data communication using a HARQ process (e.g., events 304, 306, 312, 314). At block 2806A, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 2808A, UE 102, operating in a connected state, retransmits the MAC PDU of the MAC PDU with base station 104 using a HARQ process (e.g., events 322, 324).

[0187] In some implementations, UE 102 receives a first DCI from base station 104, thereby scheduling UE 102 to send a HARQ transmission at block 2804A. At block 2808A, base station 104 receives the HARQ transmission based on the first DCI. UE 102 receives a second DCI from base station 104, thereby scheduling UE 102 to send a HARQ retransmission at block 2808A after the UE transitions to a connected state. Base station 104 may include the same HARQ process number in both the first and second DCIs. Base station 104 receives the HARQ retransmission based on the second DCI. Base station 104 may include the same NDI (value) in both the first and second DCIs.

[0188] In other implementations, UE 102 receives a first DCI from base station 104, thereby scheduling UE 102 to receive HARQ transmissions at block 2804A. At block 2808A, base station 104 sends a HARQ transmission to UE 102 based on the first DCI. UE 102 receives a second DCI from base station 104, thereby scheduling UE 102 to receive HARQ retransmissions at block 2808A after the UE transitions to a connected state. Base station 104 may include the same HARQ process number in both the first and second DCIs. Base station 104 sends a HARQ retransmission to UE 102 based on the second DCI. Base station 104 may include the same New Data Indicator (NDI) (value) in both the first and second DCIs.

[0189] Figure 28B This is a flowchart of an example method 2800B, which can be implemented in UE 102 for managing data communication before and after a state transition from an inactive state to a connected state. In method 2800B, after the UE transitions from an inactive state to a connected state, the UE receives a handover value for the NDI associated with the next HARQ retransmission, instead of using a different HARQ process number.

[0190] At box 2802B, UE 102, operating in an inactive state, performs early data communication with base station 104 (e.g., events 304, 306, 312, 314). At box 2804B, UE 102 transmits HARQ PDUs to base station 104 during early data communication using a HARQ process(number) (e.g., events 304, 306, 312, 314). At box 2806B, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At box 2807B, after transitioning to the connected state, UE 102 receives a switching value for the new data indicator associated with the next HARQ transmission of the UE's HARQ process(number). At box 2809B, UE 102, operating in connected state, communicates with base station 104 as a new HARQ transmission by using HARQ process (number) based on the switching value of the new data indicator.

[0191] Figure 29 This is a flowchart of an example method 2900, which can be implemented in UE 102, for managing data communication before and after a state transition from an inactive state to a connected state. In example method 2900, for the transition to such... Figure 3A Following the connection state shown, for the UL PDCP PDU associated with the same radio bearer, the UE continues the sequence numbering using the number following the last sequence number of the UL PDCP PDU used when the UE is inactive. This is similar to... Figure 23 In contrast to method 2300, when the UE transitions from an inactive state to a connected state, the UE restarts the sequence number.

[0192] At block 2902, UE 102, operating in an inactive state, performs early data communication with base station 104 (e.g., events 304, 306, 312, 314). At block 2904, UE 102 performs sequence numbering on SDUs with sequence numbers 0, ..., X-1, and generates a PDU for each SDU, including a specific SDU and a specific sequence number, where X is an integer greater than 0 (e.g., events 304, 306, 312, 314). At block 2906, UE 102 communicates PDUs associated with radio bearers to base station 104 during early data communication (e.g., events 304, 306, 312, 314). At block 2908, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). In block 2910, UE 102 performs sequence numbering on subsequent SDUs having sequence numbers X, ..., Y-1, and generates a PDU for each of the subsequent SDUs, including a specific SDU and a specific sequence number, where Y is an integer greater than X (e.g., events 334, 336). At block 2912, UE 102, operating in connected state, communicates subsequent PDUs associated with radio bearers to base station 104 (e.g., events 334, 336). In some implementations, the PDU may be a PDCP PDU or an RLC PDU.

[0193] Figure 30 This is a flowchart of an example method 3000, which can be implemented in UE 102, for managing data communication before and after the state transition from an inactive state to a connected state. After the transition from an inactive state to a connected state, the flowchart uses state variables to track and (re)set and / or (re)establish according to... Figure 4-6 Any of the RLC, MAC, and / or PDCP entities. (Similar to...) Figure 24 Compared to method 2400, in method 900, the UE retains state variables after transitioning from an inactive state to a connected state.

[0194] At block 3002, UE 102, operating in an inactive state, performs early data communication with base station 104 (e.g., events 304, 306, 312, 314). At block 3004, UE 102 uses state variables to communicate PDUs with base station 104 during early data communication (e.g., events 304, 306, 312, 314). At block 3006, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 3008, UE 102 retains the values ​​of the state variables in response to the transition from an inactive state to a connected state. At block 3010, UE 102, operating in a connected state, uses state variables to communicate PDUs with base station 104 (e.g., events 334, 336, 335, 337). In some implementations, the PDU may be a PDCP PDU or an RLC PDU.

[0195] Figure 31 This is a flowchart of an example method 3100, which can be implemented in UE 102, for managing data communication before and after the state transition from an inactive state to a connected state. In method 3100, when the UE is in an inactive state, the RAN fails to convey an acknowledgment of a PDU sent by the UE, or when the UE is in an inactive state, the RAN fails to convey an indication that the RAN has not received at least one PDU sent by the UE. Therefore, when the UE is in a connected state, the UE can retransmit the PDU to the RAN.

[0196] At block 3102, UE 102, operating in an inactive state, communicates a PDU to base station 104 (e.g., events 304, 306, 312, 314). At block 3104, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 3106, UE 102, operating in the connected state, communicates information to base station 104 indicating that at least one of the PDUs has not been received. At block 3108, UE 102 communicates at least one PDU to base station 104 based on this information. In some implementations, the PDU may be a PDCP PDU or an RLC PDU. For example, UE 102, operating in the connected state, receives an RLC status PDU including information from base station 104 and sends at least one RLC PDU to base station 104 based on the RLC status PDU. In another example, UE 102, operating in connected state, receives a PDCP control PDU including information from base station 104, and sends at least one PDCP PDU to base station 104 according to the PDCP control PDU. In yet another example, UE 102, operating in connected state, receives an RRC message including information from base station 104, and sends at least one PDU to base station 104 according to the RRC message.

[0197] For example, UE 102, operating in connected state, sends an RLC status PDU including the information to base station 104, and receives at least one RLC PDU from base station 104 that sends at least one RLC PDU based on the RLC status PDU. In another example, UE 102, operating in connected state, sends a PDCP control PDU including the information from base station 104, and receives at least one PDCP PDU from base station 104 that sends at least one PDCP PDU based on the PDCP control PDU. In yet another example, UE 102, operating in connected state, sends an RRC message including information from base station 104, and receives at least one PDU from base station 104 that sends at least one PDU based on the RRC message.

[0198] Figure 32 This is a flowchart of an example method 3200, which can be implemented in UE 102 for managing data communication before and after the state transition from an inactive state to a connected state. Method 3200 includes, for example... Figure 31 Additional or alternative steps to method 3100 shown. In method 3200, the UE sends a request to the RAN operating in the connected state to request the RAN to send information indicating the reception status of the PDU sent when the UE was in an inactive state.

[0199] At block 3202, UE 102, operating in an inactive state, performs early data communication with base station 104 (e.g., events 304, 306, 312, 314). At block 3404, UE 102 sends a PDU to base station 104 during the early data communication (e.g., event 314). At block 3206, UE 102 transitions from an inactive state to a connected state (e.g., events 322, 324). At block 3208, UE 102, operating in the connected state, sends a request to base station 104 to request base station 104 to send information indicating the reception status of the PDU. In some implementations, the PDU may be a PDCP PDU or an RLC PDU. In some implementations, the request may be a PDU that includes a field or IE requesting base station 104 to send information. The PDU may be an RLC PDU, a PDCPPDU, or an RRC message. The PDU may include polling bits, or it may be a control PDU that polls the UE to send information.

[0200] Figure 33This is a flowchart of an example method 3300, which can be implemented in UE 102, for managing data communication before and after a state transition from an inactive state to a connected state. In method 3300, a first message (e.g., an RRC recovery message) indicates that the MAC, RLC, and PDCP entities are retained, and a second message (e.g., an RRC establishment message) indicates that the MAC, RLC, and PDCP entities are reset, rebuilt, or released in response to the UE transitioning from an inactive state to a connected state.

[0201] At block 3302, UE 102, operating in an inactive state, performs early data transmission with base station 104 by using at least one of the MAC, RLC, and PDCP entities (e.g., events 304, 306, 312, 314). At block 3304, UE 102 receives a message from base station 104 indicating a transition to a connected state (e.g., events 322, 324). At block 3306, the UE transitions to a connected state (e.g., event 326). At block 3308, UE 102 determines whether to proceed to block 3310 or 3312. If the message is the first message, at block 3310, UE 102 retains at least one of the MAC, RLC, or PDCP entities in response to the transition to a connected state. If the message is the second message, UE 102 resets, rebuilds, or releases at least one of the MAC, RLC, or PDCP entities in response to the transition to a connected state (e.g., events 330, 342, 352). If at least one of the MAC, RLC, or PDCP entities is released, UE 102 may establish at least one new MAC, RLC, or PDCP entity in response to a transition to a connected state. The first message may be an RRC recovery message, and the second message may be an RRC establishment message.

[0202] Figure 34 This is a flowchart of an example method 3400, which can be implemented in CU 172, for managing data communication before and after the state transition from an inactive state to a connected state. In method 3400, CU 172 triggers DU to rebuild the RLC entity.

[0203] At block 3402, CU 172 communicates a PDU associated with the radio bearer to UE 102 operating in an inactive state via DU 174 (e.g., events 304, 306, 312, 314). The PDU may be a PDCP PDU. At block 3404, CU 172 determines to transition UE 102 from an inactive state to a connected state (e.g., event 316). At block 3406, in response to this determination, CU 172 sends a CU-to-DU message to DU 174 to reconstruct the RLC entity associated with the radio bearer (e.g., event 318). In some implementations, CU 172 may include an instruction in the CU-to-DU message to cause DU 174 to reconstruct the RLC entity. Subsequently, at block 3408, CU 172 receives a DU-to-CU message from DU 174 in response to the CU-to-DU message (e.g., event 320). For example, a CU to DU message can be a UE Context Modification Request message, and a DU to CU message can be a UEContext Modification Response message.

[0204] Figure 35 This is a flowchart of an example method 3500 that can be implemented in DU 174 for managing data communication before and after the state transition from an inactive state to a connected state.

[0205] At block 3502, DU 174 communicates a PDU associated with a radio bearer to CU 172 and UE 102 operating in an inactive state (e.g., events 304, 306, 312, 314). The PDU may be a PDCP PDU. At block 3504, DU receives a CU-to-DU message from CU 172 (e.g., event 318). In some implementations, the CU-to-DU message may include an indication for DU 174 to reconstruct the RLC entity. At block 3506, DU 174 reconstructs the RLC entity in response to the CU-to-DU message (e.g., event 330). At block 3508, DU 174 sends a DU-to-CU message to CU 172 in response to the CU-to-DU message (e.g., event 320). For example, the CU-to-DU message may be a UE Context Modification Request message, and the DU-to-CU message may be a UEContext Modification Response message.

[0206] Figure 36This is a flowchart of an example method 3600, which can be implemented in CU 172, for managing data communication before and after the state transition from an inactive state to a connected state. In method 3600, CU 172 triggers DU to reset the MAC entity.

[0207] At block 3602, CU 172 communicates a PDU to UE 102 operating in an inactive state via DU 174 (e.g., events 304, 306, 312, 314). The PDU may be a PDCP PDU. At block 3604, CU 172 determines to transition UE 102 from an inactive state to a connected state (e.g., event 316). At block 3606, CU 172, in response to this determination, sends a CU-to-DU message to DU 174 to reset the MAC entity (e.g., event 318). In some implementations, CU 172 may include an indication in the CU-to-DU message to cause DU 174 to reset the MAC entity. Subsequently, at block 3608, CU 172 receives a DU-to-CU message from DU 174 in response to the CU-to-DU message (e.g., event 320). For example, the CU-to-DU message may be a UE Context Modification Request message, and the DU-to-CU message may be a UE Context Modification Response message.

[0208] Figure 37 This is a flowchart of an example method 3700 that can be implemented in DU 174 for managing data communication before and after the state transition from an inactive state to a connected state.

[0209] At block 3702, DU 174 communicates a PDU associated with a radio bearer to CU 172 and UE 102 operating in an inactive state (e.g., events 304, 306, 312, 314). The PDU may be a PDCP PDU. At block 3704, DU receives a CU-to-DU message from CU 172 (e.g., event 318). In some implementations, the CU-to-DU message may include an indication for DU 174 to reset the MAC entity. At block 3706, DU 174 resets the MAC entity in response to the CU-to-DU message (e.g., event 330). At block 3708, DU 174 sends a DU-to-CU message to CU 172 in response to the CU-to-DU message (e.g., event 320). For example, the CU-to-DU message may be a UE Context Modification Request message, and the DU-to-CU message may be a UEContext Modification Response message.

[0210] Figure 38 This is a flowchart of an example method 3800, which can be implemented in CU 172, for managing data communication before and after the state transition from an inactive state to a connected state. In method 3800, CU 172 instructs DU 174 to release the UE's UE context. In this way, DU 174 releases resources configured for the UE, including protocol entities such as RLC, MAC, and PDCP entities.

[0211] At block 3802, CU 172 communicates a PDU to UE 102 operating in an inactive state via DU 174 (e.g., events 304, 306, 312, 314). The PDU may be a PDCP PDU. At block 3804, CU 172 determines to transition UE 102 from an inactive state to a connected state (e.g., event 316). At block 3806, CU 172 sends a first CU-DU message to DU 174 to release the UE context of UE 102 (e.g., event 318). At block 3810, CU 172 sends a second CU-DU message to DU 174 to establish a new UE context for UE 102. Subsequently, at block 3810, CU 172 receives a DU-CU message from DU 174 in response to the second CU-DU message (e.g., event 320). For example, the first and second CU to DU messages can be UE ContextRelease Command messages, and the DU to CU message can be UE Context SetupRequest messages.

[0212] The following list of examples reflects additional embodiments explicitly considered in this disclosure.

[0213] Example 1. A method for managing communication from a UE during a state transition in a central unit (CU) of a base station, the method comprising: when the UE is in an inactive state, performing an early data transmission procedure with the UE by processing hardware, including sending at least one data packet in a data packet sequence to the UE; determining, by the processing hardware, that the UE should transition from an inactive state to a connected state; and in response to transitioning the UE to a connected state: sending the next data packet in the data packet sequence to the UE by the processing hardware, or retransmitting the at least one data packet to the UE by the processing hardware in response to failure to determine that the at least one data packet has been received.

[0214] Example 2. According to the method of Example 1, wherein performing the early data transmission procedure includes: performing the early data transmission procedure by the processing hardware using a Packet Data Convergence Protocol (PDCP) entity, and further includes: reconstructing the PDCP entity by the processing hardware in response to transitioning the UE to a connected state.

[0215] Example 3. The method according to any one of the preceding examples, wherein the reconstructed PDCP entity is used to send the next data packet or retransmit the at least one data packet.

[0216] Example 4. The method according to any one of the foregoing examples further includes: assigning at least one sequence number to at least one data packet by processing hardware; and resetting the sequence number of the next data packet by processing hardware in response to rebuilding the PDCP entity.

[0217] Example 5. The method according to any one of the preceding examples, wherein performing the early data transmission procedure with the UE includes: receiving an RRC message without an initial data packet from the UE via a DU by the processing hardware; and receiving a data packet with a sequence number including an initial sequence number from the UE via a DU by the processing hardware.

[0218] Example 6. The method according to any one of the preceding examples, wherein sending at least one data packet to the UE comprises: sending at least one data packet to the UE by processing hardware via a distributed unit (DU) of a base station.

[0219] Example 7. The method according to any one of the foregoing examples further includes: in response to determining that the UE will transition from an inactive state to a connected state, the processing hardware sends a UE context request message to the DU of the base station to obtain radio configuration for the UE; the processing hardware receives a UE context response including the radio configuration for the UE from the DU; and the processing hardware sends a Radio Resource Control (RRC) recovery message to the UE via the DU.

[0220] Example 8. The method according to any one of the foregoing examples further includes: in response to determining that the UE will transition from an inactive state to a connected state, the processing hardware sends a UE context request message to the DU of the base station to obtain radio configuration for the UE; the processing hardware receives a UE context response including the radio configuration for the UE from the DU; and the processing hardware sends a radio resource control (RRC) establishment message to the UE via the DU.

[0221] Example 9. The method according to any one of the foregoing examples, wherein the UE context request message triggers the DU to rebuild the radio link control (RLC) entity.

[0222] Example 10. The method according to any one of the foregoing examples, wherein the UE context request message triggers the DU to reset the Media Access Control (MAC) entity.

[0223] Example 11. The method according to any one of the foregoing examples, wherein the UE context request message is a first UE context request message that causes the DU to release the UE context, and further includes: sending a second UE context request message by the processing hardware to establish a new UE context for the UE.

[0224] Example 12. The method according to any one of the preceding examples, wherein performing the early data transmission process with the UE includes: receiving an initial data packet with an initial sequence number from the UE via a DU by processing hardware; and receiving subsequent data packets with subsequent sequence numbers from the UE via a DU by processing hardware.

[0225] Example 13. The method according to any one of the foregoing examples, wherein the initial data packet and the subsequent data packets have sequence numbers from an initial sequence number to K, and further comprising: in response to transitioning the UE to a connected state, receiving by the processing hardware from the UE via the DU an additional data packet having a sequence number starting with K+1.

[0226] Example 14. The method according to any one of the preceding examples further includes: assigning at least one sequence number from an initial downlink sequence number to M to at least one data packet by the processing hardware; and assigning a sequence number M+1 to the next data packet by the processing hardware.

[0227] Example 15. The method according to any one of the foregoing examples, wherein performing the early data transmission procedure includes: performing the early data transmission procedure by processing hardware using a PDCP entity, and further includes: in response to transitioning the UE to a connected state, the processing hardware avoids rebuilding the PDCP entity.

[0228] Example 16. The method according to any one of the preceding examples, wherein the PDCP entity is used to send the next data packet or retransmit at least one data packet.

[0229] Example 17. The method according to any one of the preceding examples, wherein performing the early data transmission process includes: a HARQ transmission by which the processing hardware sends at least one data packet to the UE using a Hybrid Automatic Repeat Request (HARQ) process number.

[0230] Example 18. The method according to any one of the foregoing examples further includes: in response to transitioning the UE to a connected state, refreshing the HARQ buffer associated with the HARQ process number by the processing hardware; and generating a next HARQ transmission associated with the HARQ process number as a transmission to the UE by the processing hardware.

[0231] Example 19. The method according to any one of the foregoing examples further includes: in response to transitioning the UE to a connected state, avoiding the use of a HARQ process number for a HARQ transmission to a UE in the connected state; and having the processing hardware use a different HARQ process number not used in the inactive state to send the next HARQ transmission.

[0232] Example 20. The method according to any one of the foregoing examples, wherein at least one data packet is a first data packet, and further comprising: in response to transitioning the UE to a connected state, determining by processing hardware whether a HARQ acknowledgment for a HARQ transmission has been received from the UE; in a first instance, in response to determining that a HARQ acknowledgment has been received, sending a new HARQ transmission for a second data packet to the UE using a HARQ process number; and in a second instance, in response to determining that no HARQ acknowledgment has been received, sending a new HARQ transmission for the first data packet to the UE using a HARQ process number.

[0233] Example 21. The method according to any one of the foregoing examples further includes: in response to transitioning the UE to a connected state, the processing hardware sends a HARQ retransmission of at least one data packet to the UE using a HARQ process number.

[0234] Example 22. The method according to any of the foregoing examples, wherein the HARQ transmission is associated with a new data indicator, and further includes: in response to transitioning the UE to a connected state, the processing hardware switches the new data indicator for use in the next HARQ transmission; and the processing hardware sends the next HARQ transmission to the UE using the HARQ process number.

[0235] Example 23. The method according to any one of the foregoing examples, wherein performing the early data transmission process includes: sending at least one data packet to the UE by processing hardware using a state variable, and further includes: resetting the state variable to an initial value by processing hardware in response to transitioning the UE to a connected state; and using the reset state variable to send the next data packet or retransmit at least one data packet.

[0236] Example 24. The method according to any one of the preceding examples, wherein performing the early data transmission process includes sending at least one data packet to the UE using state variables by the processing hardware, and further includes: retaining state variables by the processing hardware in response to transitioning the UE to a connected state; and sending the next data packet or retransmitting at least one data packet using the state variables.

[0237] Example 25. The method according to any one of the foregoing examples further includes: in response to switching the UE to a connected state, receiving from the UE by the processing hardware information indicating that the UE has not received at least one data packet; and retransmitting at least one data packet by the processing hardware based on the information.

[0238] Example 26. The method according to any one of the foregoing examples further includes: in response to switching the UE to a connected state, sending a request to the UE by the processing hardware for sending information indicating the reception status of at least one data packet; and receiving from the UE by the processing hardware the information indicating the reception status of at least one data packet.

[0239] Example 27. The method according to any one of the foregoing examples further includes: sending a message to the UE by processing hardware for transitioning the UE to a connected state; determining by processing hardware whether the message is a first message or a second message; in a first instance, in response to determining that the message is a first message, retaining at least one of a MAC entity, an RLC entity, or a PDCP entity by processing hardware; and in a second instance, in response to determining that the message is a second message, resetting, rebuilding, or releasing at least one of a MAC entity, an RLC entity, or a PDCP entity by processing hardware.

[0240] Example 28. A CU of a base station, including processing hardware and configuring the method according to any one of the foregoing examples.

[0241] Example 29. A method for managing communication from a UE during a state transition in a distributed unit (DU) of a base station, the method comprising: when the UE is in an inactive state, performing an early data transmission procedure with the UE by processing hardware, including sending at least one data packet in a data packet sequence to the UE; and in response to the UE transitioning to a connected state: sending the next data packet in the data packet sequence to the UE by the processing hardware, or retransmitting the at least one data packet to the UE by the processing hardware in response to failure to determine that the at least one data packet has been received.

[0242] Example 30. The method according to Example 29, wherein performing the early data transmission procedure includes performing the early data transmission procedure by the processing hardware using a media access control (MAC) entity, and further includes: resetting the MAC entity by the processing hardware in response to the UE transitioning to a connected state.

[0243] Example 31. The method of either Example 29 or Example 30, wherein the next data packet is sent or at least one data packet is retransmitted using a reset MAC entity.

[0244] Example 32. The method according to any one of Examples 29-31, wherein performing the early data transmission procedure includes: performing the early data transmission procedure by processing hardware using a Radio Link Control (RLC) entity, and further includes: reconstructing the RLC entity by processing hardware in response to a UE transitioning to a connected state.

[0245] Example 33. The method according to any one of Examples 29-32, wherein the reconstructed RLC entity is used to send the next data packet or retransmit at least one data packet.

[0246] Example 34. The method according to any one of Examples 29-33 further includes: receiving a UE context request message from a central unit (CU) of a base station by processing hardware to obtain a radio configuration of the UE; sending a UE context response including a radio configuration for the UE to the CU by processing hardware; receiving a radio resource control (RRC) recovery message from the CU by processing hardware; and sending the RRC recovery message to the UE by processing hardware.

[0247] Example 35. The method according to any one of Examples 29-34 further includes: receiving a UE context request message from a central unit (CU) of a base station by processing hardware to obtain a radio configuration of the UE; sending a UE context response including a radio configuration for the UE to the CU by processing hardware; receiving an RRC establishment message from the CU by processing hardware; and sending an RRC establishment message to the UE by processing hardware.

[0248] Example 36. The method according to any one of Examples 29-35 further includes: in response to receiving an RRC recovery message or an RRC establishment message, reconstructing the RLC entity by processing hardware.

[0249] Example 37. The method according to any one of Examples 29-36 further includes: resetting the MAC entity by processing hardware in response to receiving an RRC recovery message or an RRC establishment message.

[0250] Example 38. The method according to any one of Examples 29-37, wherein performing the early data transmission procedure includes performing the early data transmission procedure by the processing hardware using a MAC entity, and further includes: in response to the UE transitioning to a connected state, the processing hardware avoids resetting the MAC entity.

[0251] Example 39. The method according to any one of Examples 29-38, wherein the next data packet is sent or at least one data packet is retransmitted using a MAC entity.

[0252] Example 40. The method according to any one of Examples 29-39, wherein performing the early data transmission procedure includes performing the early data transmission procedure by the processing hardware using the RLC entity, and further includes: in response to the UE transitioning to a connected state, the processing hardware avoids rebuilding the RLC entity.

[0253] Example 41. The method according to any one of Examples 29-40, wherein the next data packet is sent or at least one data packet is retransmitted using an RLC entity.

[0254] Example 42. A base station DU, including processing hardware, and configured to use the method according to any one of Examples 29-41.

[0255] Example 43. A method for transmitting data to a base station in a UE during a state transition, the method comprising: when the UE is in an inactive state, performing an early data transmission process with a central unit (CU) and a distributed unit (DU) of the base station by processing hardware, including: transmitting at least one data packet in a data packet sequence to the CU via the DU; transitioning to a connected state with the base station by the processing hardware; and in response to transitioning to the connected state: transmitting the next data packet in the data packet sequence to the base station by the processing hardware, or in response to failing to determine that at least one data packet has been received, retransmitting at least one data packet to the base station by the processing hardware.

[0256] Example 44. The method according to Example 43, wherein performing the early data transfer procedure includes performing the early data transfer procedure by the processing hardware using a media access control (MAC) entity, and further includes: resetting the MAC entity by the processing hardware in response to a transition to a connected state.

[0257] Example 45. According to the method of Example 43 or Example 44, the next data packet is sent or at least one data packet is retransmitted using a reset MAC entity.

[0258] Example 46. The method according to any one of Examples 43-45, wherein performing the early data transmission process includes: performing the early data transmission process by processing hardware using a radio link control (RLC) entity, and further includes: reconstructing the RLC entity by processing hardware in response to a transition to a connected state.

[0259] Example 47. The method of any one of Examples 43-46, wherein the reconstructed RLC entity is used to send the next data packet or retransmit at least one data packet.

[0260] Example 48. The method according to any one of Examples 43-47, wherein, in response to receiving an RRC recovery message or an RRC establishment message from the CU via the DU, the UE resets the MAC entity or rebuilds the RLC entity.

[0261] Example 49. The method according to any one of Examples 43-48, wherein performing the early data transmission process includes: performing the early data transmission process by processing hardware using a Packet Data Convergence Protocol (PDCP) entity, and further includes: reconstructing the PDCP entity by processing hardware in response to a transition to a connected state.

[0262] Example 50. The method according to any one of Examples 43-49, wherein the reconstructed PDCP entity is used to send the next data packet or retransmit at least one data packet.

[0263] Example 51. The method according to any one of Examples 43-50, wherein at least one data packet in the early data transmission process includes an initial data packet and a subsequent data packet, and wherein performing the early data transmission process with the base station includes: sending an initial data packet having an initial sequence number to the CU via the DU by processing hardware; and sending the subsequent data packet having a subsequent sequence number to the CU via the DU by processing hardware.

[0264] Example 52. The method according to any one of Examples 43-51, wherein at least one data packet in the early data transmission process includes an initial data packet and a subsequent data packet, and wherein performing the early data transmission process with the base station includes: sending an RRC message without an initial data packet to the CU via the DU by the processing hardware; and sending an initial data packet and a subsequent data packet having a sequence number including an initial sequence number to the CU via the processing hardware via the DU.

[0265] Example 53. The method according to any one of Examples 43-52, wherein the initial data packet and subsequent data packets have sequence numbers from an initial sequence number to K, and further comprising: assigning a sequence number K+1 to the next data packet by the processing hardware.

[0266] Example 54. The method according to any one of Examples 43-53 further includes: resetting the sequence number of the next data packet by processing hardware in response to reconstructing the PDCP entity.

[0267] Example 55. The method according to any one of Examples 43-54, wherein performing the early data transfer process includes performing the early data transfer process by the processing hardware using a MAC entity, and further includes: avoiding resetting the MAC entity by the processing hardware in response to a transition to a connected state.

[0268] Example 56. The method according to any one of Examples 43-55, wherein the next data packet is sent or at least one data packet is retransmitted using a MAC entity.

[0269] Example 57. The method according to any one of Examples 43-56, wherein performing the early data transfer process includes performing the early data transfer process by the processing hardware using the RLC entity, and further includes: in response to a transition to a connected state, the processing hardware avoids rebuilding the RLC entity.

[0270] Example 58. The method according to any one of Examples 43-57, wherein the next data packet is sent or at least one data packet is retransmitted using an RLC entity.

[0271] Example 59. The method according to any one of Examples 43-58, wherein performing the early data transfer procedure includes: performing the early data transfer procedure by processing hardware using a PDCP entity, and further includes: avoiding rebuilding the PDCP entity by processing hardware in response to a transition to a connected state.

[0272] Example 60. The method according to any one of Examples 43-59, wherein the next data packet is sent or at least one data packet is retransmitted using a PDCP entity.

[0273] Example 61. The method according to any one of Examples 43-60, wherein performing the early data transmission process includes: a HARQ transmission by which the processing hardware sends at least one data packet to the CU via the DU using a Hybrid Automatic Repeat Request (HARQ) process number.

[0274] Example 62. The method according to any one of Examples 43-61 further includes: in response to a transition to a connected state, refreshing the HARQ buffer associated with the HARQ process number by the processing hardware; and generating a next HARQ transfer associated with the HARQ process number as a transfer to the CU by the processing hardware.

[0275] Example 63. The method according to any one of Examples 43-62 further includes: in response to a transition to a connected state, the processing hardware sends a HARQ retransmission of at least one data packet to the CU using a HARQ process number.

[0276] Example 64. The method according to any one of Examples 43-63, wherein the HARQ transfer is associated with a new data indicator, and further includes: receiving a switching value of the new data indicator for the next HARQ transfer by the processing hardware in response to a transition to a connected state; and sending the next HARQ transfer to the CU by the processing hardware using the HARQ process number.

[0277] Example 65. The method according to any one of Examples 43-64, wherein performing the early data transmission process includes: sending at least one data packet to the CU using a state variable by the processing hardware, and further includes: resetting the state variable to an initial value by the processing hardware in response to a transition to a connected state; and sending the next data packet to the CU or retransmitting at least one data packet to the CU using the reset state variable.

[0278] Example 66. The method according to any one of Examples 43-65, wherein performing the early data transmission procedure includes: sending at least one data packet to the UE by processing hardware using a state variable, and further includes: retaining the state variable by processing hardware in response to a transition to a connected state; and sending the next data packet to the CU or retransmitting at least one data packet to the CU using the state variable.

[0279] Example 67. The method according to any one of Examples 43-66 further includes: in response to a transition to a connected state, receiving from the CU by the processing hardware information indicating that the CU has not received at least one data packet; and retransmitting at least one data packet by the processing hardware based on the information.

[0280] Example 68. The method according to any one of Examples 43-67 further includes: in response to a transition to a connected state, the processing hardware sending a request to the CU for sending information indicating the reception status of at least one data packet; and the processing hardware receiving the information indicating the reception status of at least one data packet from the CU.

[0281] Example 69. The method according to any one of Examples 43-68 further includes: receiving from the CU by processing hardware a message that transitions to a connected state during an early data transmission process; transitioning to a connected state with the base station by the processing hardware in response to receiving the message; determining by the processing hardware whether the message is a first message or a second message; in a first instance, retaining at least one of a MAC entity, an RLC entity, or a PDCP entity in response to determining that the message is a first message; and in a second instance, resetting, rebuilding, or releasing at least one of a MAC entity, an RLC entity, or a PDCP entity in response to determining that the message is a second message.

[0282] Example 70. A UE including processing hardware and configuring a method according to any one of Examples 43-69.

[0283] The following additional considerations apply to the foregoing discussion.

[0284] User equipment implementing the technologies disclosed herein (e.g., UE 102) can be any suitable device capable of wireless communication, such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or other personal media device, wearable device (such as a smartwatch), wireless hotspot, femtocell, or broadband router. Furthermore, in some cases, the device user can be embedded in electronic systems such as a head unit of a vehicle or an advanced driver assistance system (ADAS). Additionally, the user equipment can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user equipment may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

[0285] Some embodiments described in this disclosure include logic or multiple components or modules. A module can be a software module (e.g., code stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a certain way. A hardware module may include dedicated circuitry or logic permanently configured to perform certain operations (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware module may also include programmable logic or circuitry temporarily configured by software to perform certain operations (e.g., contained within a general-purpose processor or other programmable processor). The decision to implement a hardware module in dedicated and permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0286] When implemented in software, these technologies can be provided as part of an operating system, a library used by multiple applications, or a specific software application. The software can be executed by one or more general-purpose processors or one or more dedicated processors.

Claims

1. A method for managing communications from a user equipment (UE) during state transitions in a central unit (CU) of a base station, the method comprising: Early data transmission is performed by the CU and the UE in an inactive state, including sending at least one data packet in a data packet sequence via the distributed unit DU of the base station using a Packet Data Convergence Protocol (PDCP) entity. The CU determines to transition the UE from an inactive state to a connected state; as well as In response to determining to transition the UE to a connected state: Avoid rebuilding the PDCP entity; as well as The CU uses the PDCP entity to send the next data packet in the data packet sequence to the UE, or In response to the failure to determine that the at least one data packet has been received, the CU uses the PDCP entity to retransmit the at least one data packet to the UE via the DU.

2. The method according to claim 1, wherein, The process of performing early data transmission with the UE includes: The CU receives a Radio Resource Control (RRC) message without an initial data packet from the UE via the DU; and The CU receives data packets with a sequence number including an initial sequence number from the UE via the DU.

3. The method according to any one of the preceding claims further includes: In response to determining that the UE should be transitioned from the inactive state to the connected state, the CU sends a UE context request message to the DU of the base station to obtain radio configuration for the UE; The CU receives from the DU a UE context response including the radio configuration for the UE; and At least one of the following: The CU sends a Radio Resource Control (RRC) recovery message to the UE via the DU; or The CU sends a Radio Resource Control (RRC) establishment message to the UE via the DU.

4. The method according to claim 3, wherein, The UE context request message is a first UE context request message that causes the DU to release the UE context, and also includes: The CU sends a second UE context request message to establish a new UE context for the UE.

5. The method according to claim 1, wherein: The process of performing early data transmission with the UE includes: The CU receives an initial data packet with an initial sequence number from the UE via the DU; and The CU receives subsequent data packets with subsequent sequence numbers from the UE via the DU.

6. The method according to claim 5, further comprising: The CU assigns at least one sequence number from the initial downlink sequence number to M to the at least one data packet, and / or The initial data packet and the subsequent data packet from the UE have sequence numbers from the initial sequence number to K.

7. The method according to claim 6, wherein, Avoiding the reconstruction of the PDCP entity includes: Based on the absence of a reconstructed PDCP entity, assign a sequence number M+1 to the next data group; and / or The CU receives additional data packets with sequence numbers starting with K+1 from the UE via the DU, based on the fact that the PDCP entity has not been reconstructed.

8. The method according to claim 1, wherein, The early data transfer process includes: The CU sends the at least one data packet to the UE using the Hybrid Automatic Repeat Request (HARQ) process number.

9. The method of claim 8, further comprising at least one of the following: In response to transitioning the UE to a connected state, (i) The CU refreshes the HARQ buffer associated with the HARQ process number; and the CU generates the next HARQ transmission associated with the HARQ process number as a transmission to the UE; or (ii) Avoid using HARQ process numbers for HARQ transmissions to UEs in a connected state; and have the CU use different HARQ process numbers that are not used in an inactive state to send the next HARQ transmission; or (iii) wherein the at least one data packet is a first data packet, and further includes a determination by the CU of whether a HARQ acknowledgment for the HARQ transmission has been received from the UE; in a first instance, in response to determining that the HARQ acknowledgment has been received, the CU sends a new HARQ transmission of a second data packet to the UE using the HARQ process number; And in the second instance, in response to determining that no HARQ acknowledgment has been received, the CU sends a new HARQ transmission of the first data packet to the UE using the HARQ process number; or (iv) The CU sends the HARQ retransmission of the at least one data packet to the UE using the HARQ process number; or (v) wherein the HARQ transmission is associated with a new data indicator and further includes: the CU switching the new data indicator for the next HARQ transmission; and the CU sending the next HARQ transmission to the UE using the HARQ process number.

10. The method according to claim 1, further comprising: In response to switching the UE to the connected state, the CU receives information from the UE indicating that the UE has not received the at least one data packet; as well as The CU retransmits the at least one data packet based on the information.

11. The method of claim 10, further comprising: In response to transitioning the UE to the connected state, the CU sends a request to the UE for sending information indicating the reception status of the at least one data packet; as well as The CU receives information from the UE indicating the reception status of the at least one data packet.

12. A central unit (CU) of a base station, comprising processing hardware and configured to perform the method according to any one of the preceding claims.

13. A method for managing communications from a user equipment (UE) during state transitions in a distributed unit (DU) of a base station, the method comprising: The DU performs an early data transmission procedure with an inactive UE, the early data transmission procedure including sending at least one data packet from a data packet sequence to the central unit CU of the base station via the DU using a Packet Data Convergence Protocol (PDCP) entity; and In response to the UE transitioning to a connected state: Avoid rebuilding the PDCP entity; as well as The DU uses the PDCP entity to send the next data packet in the data packet sequence to the UE, or In response to the failure to determine that the at least one data packet has been received, the DU uses the PDCP entity to retransmit the at least one data packet to the UE.

14. The method of claim 13, further comprising: The DU receives a UE context request message from the CU to obtain radio configuration for the UE; The DU sends a UE context response, including the radio configuration for the UE, to the CU; as well as At least one of the following: The DU receives a Radio Resource Control (RRC) recovery message from the CU; and the DU sends the RRC recovery message to the UE; or The DU receives the RRC establishment message from the CU; and the DU sends the RRC establishment message to the UE.

15. The method according to claim 13, wherein, Performing the early data transmission procedure also includes having the DU perform the early data transmission procedure using a Media Access Control (MAC) entity, and further includes: In response to the UE transitioning to the connected state, the DU avoids resetting the MAC entity.

16. The method according to claim 13, wherein, Performing the early data transfer procedure further includes: the DU using an RLC entity to perform the early data transfer procedure, and also includes: The DU avoids rebuilding the RLC entity in response to the UE transitioning to the connected state.

17. A distributed unit (DU) of a base station, comprising processing hardware and configured to perform the method according to any one of claims 13 to 16.

Images