FIEED OF THE DISCEOSURE

[0001] This disclosure relates generally to wireless communications and, more particularly, to communication of uplink and/or downlink data between a user equipment (UE) and a radio access network (RAN) when the UE operates in an inactive or idle state associated with a protocol for controlling radio resources.

BACKGROUND

[0002] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] Generally, a base station operating a cellular radio access network (RAN) communicates with a user equipment (UE) using a certain radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of a RAT provides transport channels to the Medium Access Control (MAC) sublayer, which in turn provides logical channels to the Radio Link Control (RLC) sublayer, and the RLC sublayer in turn provides data transfer services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer is disposed above the PDCP sublayer.

[0004] The RRC sublayer defines an RRC_IDLE state, in which a UE does not have an active radio connection with a base station; an RRC_CONNECTED state, in which the UE has an active radio connection with the base station; and an RRC_INACTIVE state that allows a UE to more quickly transition back to the RRC_CONNECTED state using RAN- level base station coordination and RAN paging procedures. In some cases, the UE in the RRC_INACTIVE state has only one, relatively small packet to transmit. For situations such as these, 3GPP is discussing a Small Data Transmission (SDT) procedure to enable the 5G NR (New Radio), a wireless communication standard, to support data transmission for the UE operating in the RRC_INACTIVE state (i.e., without requiring that the UE transition to the RRC_CONNECTED state). [0005] SDT is enabled on a radio bearer basis and is initiated by the UE only if (1) the amount of uplink data awaiting transmission (across all radio bearers for which SDT is enabled) is below a configured threshold, (2) the downlink (DL) reference signal received power (RSRP) is above a configured threshold, and (3) a valid SDT resource is available. SDT procedure can be initiated by the UE with either a transmission over a random access channel (RACH), i.e., random access SDT (RA-SDT) or over Type 1 configured grant (CG) resources, i.e., CG-SDT. For the RA-SDT, the network configures 2-step and/or 4-step random access resources for SDT. In the RA-SDT (Random access based SDT), the UE can transmit an initial transmission including data in a message 3 (Msg3) of a 4-step random access procedure or in payload of a message A (MsgA) of a 2-step random access procedure. The network can then schedule subsequent uplink and/or downlink transmissions using dynamic uplink grants and downlink assignments, respectively, after the completion of the random access procedure.

[0006] The CG-SDT (configured grant based SDT) can only be initiated with valid uplink (UL) timing alignment. The UE maintains the UL timing alignment based on a network- configured, SDT-specific timing alignment timer and DL RSRP of a configured number of highest ranked SSBs (synchronization signal blocks). Upon expiry of the SDT-specific timing alignment timer, the CG resources are released. Upon initiating the CG-SDT, the UE transmits an initial transmission including data on a CG occasion using a CG configuration, and the network can schedule subsequent UL transmissions using dynamic grants or on future CG resource occasions. During the CG-SDT, the DL transmissions are scheduled using dynamic assignments. The UE can initiate subsequent UL transmission only after receiving, from the network, confirmation of the initial UL transmission.

[0007] However, it is not clear how the base station of a RAN manages UL synchronization for CG-SDT. Failure to properly manage UL synchronization can result in data communication latency and/or other network inefficiencies. Moreover, it is not clear how base stations manage CG-SDT configurations. Failure to properly manage CG-SDT configurations can likewise result in various network inefficiencies.

SUMMARY

[0008] In some implementations of this disclosure, a base station maintains a CG-SDT time alignment timer that indicates validity of a CG-SDT configuration for a UE. The base station sends the UE an RRC release message that includes the CG-SDT configuration, and then starts or restarts a time alignment timer. After subsequently receiving or attempting to receive transmissions from the UE in accordance with the CG-SDT configuration, the base station can either detect that the time alignment timer expires (and therefore release the CG- SDT configuration), or transmit a timing advance command to the UE (and therefore restart the time alignment timer).

[0009] In some implementations where the base station is a distributed base station, a distributed unit (DU) of the base station maintains the time alignment timer for CG-SDT operation. For example, the DU may transmit the CG-SDT configuration to the UE via a central unit (CU) of the distributed base station (e.g., by sending the CG-SDT configuration to the CU, receiving an RRC release message including the CG-SDT configuration from the CU in response, and then sending the RRC release message with CG-SDT configuration to the UE), and then start or restart the time alignment timer. After subsequently receiving or attempting to receive transmissions from the UE in accordance with the CG-SDT configuration, the DU may either detect that the time alignment timer expires (and therefore stop attempting to receive the UE transmissions), or transmit a timing advance command to the UE (and therefore restart the time alignment timer). In other distributed base station implementations, the CU, rather than the DU, maintains the time alignment timer for CG- SDT operation.

[0010] In some implementations, the CU of a distributed base station determines whether/when to release the CG-SDT configuration, and can transmit to the DU a CU-to-DU message indicating that the DU is to release the CG-SDT configuration. In other implementations, however, the DU determines whether/when to release the CG-SDT configuration, and can either inform the CU that a CG-SDT configuration is to be released, or send the CU a request to release the CG-SDT configuration.

[0011] In one aspect of this disclosure, a method, implemented by a DU of a distributed base station, of managing synchronization with a UE includes transmitting, to the UE via a CU of the distributed base station, a CG-SDT configuration for use by the UE when the UE is in an inactive state. The method also includes, after transmitting the CG-SDT configuration to the UE via the CU, starting or restarting a time alignment timer that indicates validity of the CG-SDT configuration, and while the time alignment timer is running, receiving or attempting to receive transmissions from the UE in accordance with the CG-SDT configuration. [0012] In another aspect of this disclosure, a method, implemented by a base station, of managing synchronization with a UE includes transmitting to the UE an RRC release message including a CG-SDT configuration for use by the UE when the UE is in an inactive state. The method also includes, after transmitting the RRC release message to the UE, starting or restarting a time alignment timer that indicates validity of the CG-SDT configuration, and while the time alignment timer is running, receiving or attempting to receive transmissions from the UE in accordance with the CG-SDT configuration.

[0013] In another aspect of this disclosure, a method, implemented by a CU of a distributed base station, of managing a CG-SDT configuration for use by a UE when the UE is in an inactive state includes transitioning the UE from a connected state to the inactive state by transmitting a message to the UE via a DU of the distributed base station. The method also includes, after transitioning the UE, transmitting to the DU a CU-to-DU message indicating that the DU is to release the CG-SDT configuration.

[0014] In another aspect of this disclosure, a method, implemented by a CU of a distributed base station, of managing a CG-SDT configuration for use by a UE when the UE is in an inactive state includes transitioning the UE from a connected state to the inactive state by transmitting a message to the UE via a DU of the distributed base station. The method also includes, after transitioning the UE, receiving from the DU a DU-to-CU message indicating or requesting release of the CG-SDT configuration, and in response to the DU-to-CU message, transmitting to the DU a CU-to-DU message.

[0015] In another aspect of this disclosure, a method, implemented by a DU of a distributed base station, of managing a CG-SDT configuration for use by a UE when the UE is in an inactive state includes transmitting the CG-SDT configuration to the UE. The method also includes, after transmitting the CG-SDT configuration, receiving, from a CU of the distributed base station, a CU-to-DU message indicating that the DU is to release the CG- SDT configuration, and in response to the CU-to-DU message, releasing the CG-SDT configuration.

[0016] In another aspect of this disclosure, a method, implemented by a DU of a distributed base station, of managing a CG-SDT configuration for use by a UE when the UE is in an inactive state, includes transmitting the CG-SDT configuration to the UE. The method also includes, after transmitting the CG-SDT configuration, determining to release the CG-SDT configuration, and in response to the determining, transmitting to a CU of the distributed base station a DU-to-CU message indicating or requesting release of the CG-SDT configuration.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Fig. 1A is a block diagram of an example wireless communication system in which a user device and a base station of this disclosure can implement the techniques of this disclosure, e.g., for reducing latency in data communication;

[0018] Fig. IB is a block diagram of an example base station in which a central unit (CU) and a distributed unit (DU) that can operate in the system of Fig. 1A;

[0019] Fig. 2 A is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with base stations;

[0020] Fig. 2B is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with a CU and a DU;

[0021] Figs. 3 and 4 are message sequence diagrams illustrating scenarios in which the devices of Figs. 1 A-2B can implement configured grant configuration in accordance with the techniques of this disclosure; and

[0022] Figs. 5-11 illustrate several methods, which can be implemented/performed by one or more devices of Figs. 1A-2B, for configured grant configuration in accordance with the techniques of this disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

[0023] As discussed in more detail below, a user equipment (UE) and/or a network node of a radio access network (RAN) can use the techniques of this disclosure for managing early data communication and transitioning a UE between states of a protocol for controlling radio resources between the UE and the RAN. As used in this disclosure, unless the context clearly indicates a more specific meaning, small data communication can refer to small data transmission (SDT) from the perspective of the network (i.e., SDT in the downlink direction), or SDT from the perspective of the UE (i.e., SDT in the uplink direction).

[0024] Referring first to Fig. 1A, an example wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 can operate in a RAN 105 connected to the CN 110. The CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160, for example. The CN 110 can also be implemented as a sixth generation (6G) core in another example.

[0025] The base station 104 covers a cell 124, and the base station 106 covers a cell 126. If the base station 104 is a gNB, the cell 124 is an NR cell. If the base station 104 is an ng-eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the base station 106 is a gNB, the cell 126 is an NR cell, and if the base station 106 is an ng-eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, the RAN 105 can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an interface (e.g., SI or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

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

[0027] As illustrated in Fig. 1A, the base station 104 supports a cell 124, and the base station 106 supports a cell 126. The cells 124 and 126 can partially overlap, so that the UE 102 can select, reselect, or hand over from one of the cells 124 and 126 to the other. To directly exchange messages or information, the base station 104 and base station 106 can support an X2 or Xn interface. In general, the CN 110 can connect to any suitable number of base stations supporting NR cells and/or EUTRA cells. [0028] As discussed in detail below, the UE 102 and/or the RAN 105 may utilize the techniques of this disclosure when the radio connection between the UE 102 and the RAN 105 is suspended, e.g., when the UE 102 operates in an inactive or idle state of the protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the examples below refer to the RRC_INACTIVE or RRC_IDLE state of the RRC protocol.

[0029] As used herein, and unless a more specific meaning is indicated from the context of use, the term “data” or “data packet” can refer to signaling, control-plane information at a protocol layer of controlling radio resources (e.g., RRC), controlling mobility management (MM), or controlling session management (SM), or can refer to non-signaling, non-control- plane information at one or more protocol layers above the layer of the protocol for controlling radio resources (e.g., RRC), above the layer of the protocol for controlling MM, above the layer of the protocol for controlling SM, and/or above the layer of the protocol for controlling quality of service (QoS) flows (e.g., service data adaptation protocol (SDAP)). The data to which the UE and/or the RAN applies the techniques of this disclosure can include, for example, Internet of Things (loT) data, ethemet traffic data, internet traffic data, or a short message service (SMS) message. Further, as discussed below, the UE 102 in some implementations applies these techniques only if the size of the data is below a certain threshold value. It is also understood that, as used herein (and unless the context of its use indicates a more specific meaning), the term “configuration” can refer to a full configuration, or to a subset of parameters of a full configuration (e.g., a “delta” or other partial configuration that can augment an existing configuration without completely replacing the existing configuration).

[0030] In the example scenarios discussed below, the UE 102 transitions to the RRC_INACTIVE or RRC_IDLE state, selects a cell of the base station 104, and exchanges data with the base station 104, either via the base station 106 or with the base station 104 directly, without transitioning to the RRC_CONNECTED state. As a more specific example, after the UE 102 determines that data is available for UL transmission in the RRC_INACTIVE or RRC_IDLE state, the UE 102 can apply one or more security functions to an UL data packet, generate a first UL protocol data unit (PDU) including the security- protected packet, include a UL RRC message along with the first UL PDU in a second UL PDU, and transmit the second UL PDU to the RAN 105. The UE 102 includes a UE identity/identifier (ID) for the UE 102 in the UL RRC message. The RAN 105 can identify the UE 102 based on the UE ID. In some implementations, the UE ID can be an inactive Radio Network Temporary Identifier (I-RNTI), a resume ID, or a non-access stratum (NAS) ID. The NAS ID can be an S-Temporary Mobile Subscriber Identity (S-TMSI) or a Global Unique Temporary Identifier (GUTI), in some implementations.

[0031] The security function can include an integrity protection and/or encryption function. When integrity protection is enabled, the UE 102 can generate a message authentication code for integrity (MAC-I) to protect integrity of the data. Thus, the UE 102 in this case generates a security-protected packet including the data and the MAC-I. When encryption is enabled, the UE 102 can encrypt the data to obtain an encrypted packet, so that the security-protected packet includes encrypted data. When both integrity protection and encryption are enabled, the UE 102 can generate a MAC-I for protecting integrity of the data and encrypt the data along with the MAC-I to generate an encrypted packet and an encrypted MAC-I. The UE 102 then can transmit the security-protected packet to the RAN 105 while in the RRC INACTIVE or RRC IDLE state.

[0032] In some implementations, the data is an UL service data unit (SDU) of the packet data convergence protocol (PDCP) or SDAP. The UE 102 applies the security function to the SDU and includes the secured SDU in a first UL PDU (e.g., a UL PDCP PDU). The UE 102 then includes the UL PDCP PDU in a second UL PDU such as a UL MAC PDU, which can be associated with the medium access control (MAC) layer. Thus, the UE 102 in these cases transmits the secured UL PDCP PDU in the UL MAC PDU. In some implementations, the UE 102 can include, in the UL MAC PDU, a UL RRC message. In other implementations, the UE 102 may not include a UL RRC message in the UL MAC PDU. In this case, the UE 102 may not include a UE ID of the UE 102 in the UL MAC PDU not including a UL RRC message. In yet other implementations, the UE 102 can include the UL PDCP PDU in a UL RLC PDU and then include the UL RLC PDU in the UL MAC PDU. In some implementations in which the UE 102 includes the UL RRC message in the UL MAC PDU, the UE 102 generates an RRC MAC-I and includes the RRC MAC-I in the UL RRC message. For example, the RRC MAC-I can be a resumeMAC-I field, as specified in 3GPP specification 38.331. In other implementations, the UE 102 can obtain the RRC MAC-I from the UL RRC message with an integrity key (e.g., KRRCint key), an integrity protection algorithm, and parameters such as COUNT (e.g., 32-bit, 64-bit or 128-bit value), BEARER (e.g., 5-bit value), and DIRECTION (e.g., 1 -bit value). [0033] In other implementations, the data is a UL SDU of the NAS. The UE 102 applies the security function to the SDU and includes the secured SDU in a first UL PDU such as a NAS PDU, which can be associated with the NAS layer. For example, the NAS layer can be an MM sublayer or SM sublayer of 5G, Evolved Packet System (EPS), or 6G. The UE 102 can then include the UL NAS PDU in a second UL PDU such as a UL RRC message. Thus, the UE 102 in these cases transmits the (first) secured UL NAS PDU in the UL RRC message. In some implementations, the UE 102 can include the UL RRC message in a UL MAC PDU and transmit the UL MAC PDU to a base station (e.g., base station 104 or 106) via a cell (e.g., cell 124 or 126). In this case, the UE 102 may not include an RRC MAC-I in the UL RRC message. Alternatively, the UE 102 may include an RRC MAC-I as described above.

[0034] In some implementations, the UL RRC message described above can be a common control channel (CCCH) message, an RRC resume request message, or an RRC early data request message. The UL RRC message can include a UE ID of the UE 102 as described above.

[0035] More generally, the UE 102 can secure the data using encryption and/or integrity protection, include the secured data as a security-protected packet in the first UL PDU, and transmit the first UL PDU to the RAN 105 in the second UL PDU.

[0036] In some scenarios and implementations, the base station 106 can retrieve the UE ID of the UE 102 from the UL RRC message and identify the base station 104 as the destination of the data in the first UL PDU, based on the determined UE ID. In one example implementation, the base station 106 retrieves the first UL PDU from the second UL PDU and transmits the first UL PDU to the base station 104. The base station 104 then retrieves the security-protected packet from the first UL PDU, applies one or two security functions to decrypt the data and/or check the integrity protection, and transmits the data to the 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 the RAN 105. More specifically, the base station 104 derives at least one security key from UE context information of the UE 102. The base station 104 then retrieves the data from the security-protected packet by using the at least one security key and transmits the data to the CN 110 or edge server. When the security- protected packet is an encrypted packet, the base station 104 decrypts the encrypted packet to obtain the data by using the at least one security key (e.g., an encryption and/or decryption key). If the security-protected packet is an integrity-protected packet, the integrity-protected packet may include the data and the MAC-I. The base station 104 can verify whether the MAC-I is valid for the security-protected packet by using the at least one security key (e.g., an integrity key). When the base station 104 confirms that the MAC-I is valid, the base station 104 sends the data to the CN 110 or edge server. However, when the base station 104 determines that the MAC-I is invalid, the base station 104 discards the security-protected packet. Further, if the security-protected packet is both encrypted and integrity-protected, the encrypted and integrity-protected packet may include the encrypted packet along with the encrypted MAC-I. The base station 104 in this case decrypts the encrypted packet and the encrypted MAC-I to obtain the data and the MAC-I. The base station 104 then determines whether the MAC-I is valid for the data. If the base station 104 determines that the MAC-I is valid, the base station 104 retrieves the data and forwards the data to the CN 110 or edge server. However, if the base station 104 determines that the MAC-I is invalid, the base station 104 discards the packet.

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

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

[0039] Further, the RAN 105 in some implementations and scenarios transmits data in the DL direction to the UE 102 operating in the RRC_INACTIVE or RRC_IDLE state.

[0040] In one implementation, when the base station 104 determines that data is available for downlink transmission to the UE 102 currently operating in the RRC_INACTIVE or RRC_IDLE state, the base station 104 can apply at least one security function to the data to generate a security-protected packet, generate a first DL PDU including the security- protected packet, and include the first DL PDU in a second DL PDU. To secure the data, the base station 104 can apply the security function (e.g., integrity protection and/or encryption) to the DL data. More particularly, when integrity protection is enabled, the base station 104 can generate a MAC-I for protecting integrity of the data, so that the security-protected packet includes the DL data and the MAC-I. When encryption is enabled, the base station 104 can encrypt the data to generate an encrypted packet, so that the security-protected packet is an encrypted packet. Further, when both integrity protection and encryption are enabled, the base station 104 can generate a MAC-I for protecting the integrity of the data and encrypt the data along with the MAC-I to generate an encrypted packet and an encrypted MAC-I. The base station 104 in some implementations generates a first DL PDU, such as a DL PDCP PDU, using the security-protected packet, includes the first DL PDU in a second DL PDU associated with the MAC layer for example (e.g., a DL MAC PDU), and transmits the second DL PDU to the UE 102 without first causing the UE 102 to transition from the RRC INACTIVE or RRC IDLE state to the RRC_CONNECTED state. In some implementations, the base station 104 includes the DL PDCP PDU in a DL RLC PDU, includes the DL RLC PDU in the DL MAC PDU, and transmits the DL MAC PDU to the UE 102 without first causing the UE 102 to transition from the RRC_INACTIVE or RRC_IDLE state to the RRC_CONNECTED state.

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

[0042] In some implementations, the base station (i.e., the base station 104 or 106) generates a downlink control information (DCI) and a cyclic redundancy check (CRC) scrambled with an ID of the UE 102 to transmit the second DL PDU generated by the base station. In some implementations, the ID of the 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 transmits the DCI and scrambled CRC on a physical downlink control channel (PDCCH) to the UE 102 operating in the RRC_INACTIVE or RRC_IDLE state. The base station scrambles the CRC with the ID of the UE 102. In some implementations, the base station may assign the ID of the UE 102 to the UE 102 in a random access response or a message B (MsgB) that the base station transmits in a random access procedure with the UE 102 before transmitting the DCI and scrambled CRC. In other implementations, the base station may assign the ID of the UE 102 to the UE 102 in an RRC message (e.g., RRC release message or an RRC reconfiguration message) that the base station transmits to the UE 102 before transmitting the DCI and scrambled CRC, e.g., while the UE 102 was in the RRC_CONNECTED state.

[0043] The UE 102 operating in the RRC_INACTIVE or RRC_IDLE state can receive the DCI and scrambled CRC on the PDCCH, and then confirm that a physical downlink shared channel (PDSCH), including the second DL PDU, is addressed to the UE 102 according to the ID of the UE 102, the DCI, and the scrambled CRC. The UE 102 then can retrieve the data from the security-protected packet. If the security-protected packet is an encrypted packet, the UE 102 can decrypt the encrypted packet using the appropriate decryption function and the security key to obtain the data. If the security-protected packet is the integrity-protected packet including the data and the MAC-I, the UE 102 can determine whether the MAC-I is valid. If the UE 102 confirms that the MAC-I is valid, the UE 102 retrieves the data. If, however, the UE 102 determines that the MAC-I is invalid, the UE 102 discards the packet. If the security-protected packet is both encrypted and integrity-protected, with encrypted data and an encrypted MAC-I, the UE 102 can decrypt the encrypted packet and encrypted MAC-I to obtain the data and the MAC-I. The UE 102 can then verify that the MAC-I is valid for the data. If the UE 102 confirms that the MAC-I is valid, the UE 102 retrieves and processes the data. Otherwise, when the UE 102 determines that the MAC-I is invalid, the UE 102 discards the data.

[0044] The base station 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example implementation includes a MAC controller 132 configured to perform a random access procedure with one or more user devices, receive UL MAC protocol data units (PDUs) from one or more user devices (UEs), and transmit DL MAC PDUs to one or more user devices (UEs). The processing hardware 130 can also include a PDCP controller 134 configured to transmit and/or receive PDCP PDUs in accordance with the manner in which the base station 104 can transmit DL data and/or receive UL data. The processing hardware further can include an RRC controller 136 to implement procedures and messaging at the RRC sublayer of the protocol communication stack. The processing hardware 130 in an example implementation includes an RRC inactive controller 138 configured to manage uplink and/or downlink communications with one or more UEs operating in the RRC_INACTIVE or RRC_IDLE state. The base station 106 can include generally similar components. In particular, components 140, 142, 144, 146, and 148 of the base station 106 can be similar to the components 130, 132, 134, 136, and 138, respectively.

[0045] The UE 102 is equipped with processing hardware 150 that can include one or more general -purpose processors such as CPUs and non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units. The processing hardware 150 in an example implementation includes an RRC inactive controller 158 configured to manage uplink and/or communications when the UE 102 operates in the RRC_INACTIVE state. The processing hardware 150 in an example implementation includes a MAC controller 152 configured to perform a random access procedure with a base station, transmit uplink MAC PDUs to the base station, and receive downlink MAC PDUs from the base station. The processing hardware 150 can also include a PDCP controller 154 configured to transmit and/or receive PDCP PDUs in accordance with the manner in which the base station 106 transmits DL data and/or receives UL data. The processing hardware further can include an RRC controller 156 to implement procedures and messaging at the RRC sublayer of the protocol communication stack.

[0046] Fig. IB depicts an example distributed or disaggregated implementation of a base station 170, which may represent one or both of the base stations 104, 106. In this implementation, the base station 170 includes a central unit (CU) 172 and one or more distributed units (DUs) 174. The CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine- readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. For example, the CU 172 can include a PDCP controller, an RRC controller and/or an RRC inactive controller such as PDCP controller 134, 144, RRC controller 136, 146 and/or RRC inactive controller 138, 148. In some implementations, the CU 172 can include an RFC controller configured to manage or control one or more RLC operations or procedures. In other implementations, the CU 172 does not include an RLC controller.

[0047] Each of the DUs 174 also includes processing hardware that can 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 special-purpose processing units. For example, the processing hardware can include a MAC controller (e.g., MAC controller 132, 142) configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and/or an RLC controller configured to manage or control one or more RLC operations or procedures. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures. [0048] In some embodiments, the RAN 105 supports Integrated Access and Backhaul (IAB) functionality. In some implementations, the DU 174 operates as an (lAB)-node, and the CU 172 operates as an IAB -donor.

[0049] In some implementations, the CU 172 can include a logical node CU-CP 172 A that hosts the control plane part of the PDCP protocol of the CU 172. The CU 172 can also include logical node(s) CU-UP 172B that hosts the user plane part of the PDCP protocol and/or Service Data Adaptation Protocol (SDAP) protocol of the CU 172. The CU-CP 172A can transmit control information (e.g., RRC messages, Fl application protocol messages), and the CU-UP 172B can transmit the data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0050] The CU-CP 172 A can be connected to multiple CU-UP 172B through the El interface. The CU-CP 172A selects the appropriate CU-UP 172B for the requested services for the UE 102. In some implementations, a single CU-UP 172B can connect to multiple CU- CP 172A through the El interface. The CU-CP 172A can connect to one or more DU 174s through an Fl-C interface. The CU-UP 172B can connect to one or more DU 174 through the Fl-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 can connect to multiple CU-UP 172B under the control of the same CU-CP 172A. In such implementations, the connectivity between a CU-UP 172B and a DU 174 is established by the CU-CP 172A using Bearer Context Management functions.

[0051] Fig. 2A illustrates, in a simplified manner, an example protocol stack 200 according to which the UE 102 can communicate with an eNB/ng-eNB 201 A or a gNB/en-gNB 20 IB (e.g., one or both of the base stations 104, 106).

[0052] In the example stack 200, a PHY 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to SDAP 212 or an RRC sublayer (not shown in Fig. 2A). The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2A, to support handover between EUTRA and NR base stations and/or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2A, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

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

[0054] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or RRC sublayer (not shown in Fig. 2A) to exchange RRC messages or NAS messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide Data Radio Bearers (DRBs) to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets or Ethernet packets.

[0055] Fig. 2B illustrates, in a simplified manner, an example protocol stack 250, which the UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally split as shown by the radio protocol stack 250 in Fig. 2B. The CU at any of the base stations 104 or 106 can hold all the control and upper layer functionalities (e.g., RRC 214, SDAP 212, NR PDCP 210), while the lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connection to a 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0056] Next, several example scenarios that involve various components of Fig. 1A and relate to transmitting data in an inactive or idle state are discussed with reference to Figs. 3- 5B. To simplify the following description, the “inactive state” can represent the RRC_INACTIVE or RRC_IDLE state, and the “connected state” can represent the RRC_CONNECTED state.

[0057] Referring first to Fig. 3, in a scenario 300, the base station 104 includes a CU 172 and a DU 174 and the CU 172 includes a CU-CP 172 A and a CU-UP 172B. In this scenario 300, the UE 102 initially operates in a connected state 302 and communicates 304 with the DU 174, e.g., by using a DU configuration (i.e., a first non-SDT configuration), and communicates 304 with the CU-CP 172A and/or CU-UP 172B via the DU by using a CU configuration (i.e., a first non-SDT CU configuration). While the UE communicates 304 with the base station 104, the CU-CP 172A can send 306 a UE Context Modification Request message. In response, the DU 174 sends 308 a UE Context Modification Response message including a non-SDT configuration (i.e., a second non-SDT configuration) for the UE 102 to the CU-CP 172A. The CU-CP 172A generates a RRC reconfiguration message including the non-SDT DU configuration and transmits 310 a first CU-to-DU message (e.g., DL RRC Message Transfer message) including the RRC reconfiguration message to the DU 174. In turn, the DU 174 transmits 312 the RRC reconfiguration message to the UE 102. In response, the UE 102 transmits 314 an RRC reconfiguration complete message to the DU 174, which in turn transmits 316 a first DU-to-CU message (e.g., UL RRC Message Transfer message) including the RRC reconfiguration complete message to the CU-CP 172A.

[0058] After receiving 312 the RRC reconfiguration message, the UE 102 in the connected state communicates 318 with the DU 174 using the non-SDT DU configuration and communicates with the CU-CP 172A and/or CU-UP 172B via the DU. In cases where the RRC reconfiguration message does not include a CU configuration, the UE 102 communicates 318 with the CU-CP 172A and/or CU-UP 172B via the DU 174 using the first non-SDT CU configuration. In cases where the RRC reconfiguration message includes a non- SDT CU configuration (i.e., a second non-SDT CU configuration), the UE 102 communicates 318 with the CU-CP 172A and/or CU-UP 172B via the DU 174, using the second non-SDT CU configuration. In some implementations, the second non-SDT CU configuration can augment the first non-SDT CU configuration or include at least one new configuration parameter not included in the first non-SDT CU configuration. In such cases, the UE 102 and the CU-CP 172A and/or the CU-UP 172B can communicate 318 with one another using the second non-SDT CU configuration, and also using configuration parameters in the first non- SDT CU configuration that were not augmented by the second non-SDT CU configuration. In some implementations, the first non-SDT CU configuration includes configuration parameters related to operations of RRC and/or PDCP protocol layers (e.g., RRC 214 and/or NR PDCP 210), that the UE 102 and CU 172 use to communicate with one another while the UE 102 operates in the connected state. Similarly, the second non-SDT CU configuration can include configuration parameters related to operations of the RRC and/or PDCP protocol layers, that the UE 102 and CU 172 use to communicate with one another while the UE 102 operates in the connected state. In some implementations, the first non-SDT CU configuration includes configuration parameters in a RadioBearerConfig information element (IE) and/or MeasConfig IE as defined in 3GPP specification 38.331 vl6.7.0. Similarly, the second non-SDT CU configuration can include configuration parameters in the RadioBearerConfig IE and/or MeasConfig IE as defined in 3GPP specification 38.331 vl6.7.0. In some implementations, the first non-SDT CU configuration can be or include a RadioBearerConfig IE and/or a MeasConfig IE, and the second non-SDT CU configuration can be or include a RadioBearerConfig IE and/or MeasConfig IE.

[0059] In some implementations, the second non-SDT DU configuration can augment the first non-SDT DU configuration or include at least one new configuration parameter not included in the first non-SDT DU configuration. In such cases, the UE 102 and the DU 174 can communicate 318 with one another using the second non-SDT DU configuration and also using the configuration parameters in the first non-SDT DU configuration that were not augmented by the second non-SDT DU configuration. In some implementations, the first non-SDT DU configuration includes configuration parameters related to operations of RRC, RLC, MAC, and/or PHY protocol layers (e.g., RLC 206B, MAC 204B and/or PHY 202B), that the UE 102 and DU 174 use to communicate with one another while the UE 102 operates in the connected state. Similarly, the second non-SDT DU configuration can include configuration parameters related to operations of the RRC, RLC, MAC, and/or PHY protocol layers, that the UE 102 and DU 174 use to communicate with one another while the UE 102 operates in the connected state. In some implementations, the first non-SDT DU configuration includes configuration parameters in a CellGroupConfig IE as defined in 3GPP specification 38.331 vl6.7.0. Similarly, the second non-SDT DU configuration can include configuration parameters in the CellGroupConfig IE as defined in 3GPP specification 38.331 vl6.7.0. In some implementations, the first non-SDT DU configuration and the second non- SDT DU configuration can be CellGroupConfig IES.

[0060] The events 306, 308, 310, 312, 314, 316 and 318 are collectively referred to in Fig. 3 as a non-SDT resource (re)configuration procedure 390, which can be optional.

[0061] While the UE 102 communicates with the base station 104 or after the non-SDT resource (re) configuration procedure 390 (if performed), the CU-CP 172A can determine to transition the UE 102 to an inactive state from the connected state, based on data inactivity of the UE 102 (i.e., based on the UE 102 in the connected state having no data activity with the base station 104). In some implementations, while the UE 102 communicates with the base station 104 or after the non-SDT resource (re) configuration procedure 390 (if performed), the UE 102 determines or detects data inactivity and transmits 320 to the DU 174, UE assistance information (e.g., a UEAssistancelnformation message) indicating that the UE 102 requests to transition to the inactive state with SDT configured. In turn, the DU 174 transmits 321 a UL RRC Message Transfer message including the UE assistance information to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the UE assistance information. In other implementations, the DU 174 can perform data inactivity monitoring for the UE 102. The CU-CP 172 A can transmit a CU-to-DU message (e.g., a UE Context Setup Request message or a UE Context Modification Request message) to the DU 174 to request or command the DU 174 to perform the data inactivity monitoring. In cases where the DU 174 detects or determines that the UE 102 is in data inactivity during the monitoring, the DU 174 can transmit 322 an inactivity notification (e.g., UE Inactivity Notification message) to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the inactivity notification received from the DU 174. In yet other implementations, the CU-UP 172B can perform data inactivity monitoring for the UE 102. The CU-CP 172A can transmit a CP-to-UP message (e.g., a Bearer Context Setup Request message or a Bearer Context Modification Request message) to the CU-UP 172B to request or command the CU-UP 172B to perform the data inactivity monitoring. In cases where the CU-UP 172B detects or determines that the UE 102 is in data inactivity during the monitoring, the CU-UP 172B can transmit 323 an inactivity notification (e.g., Bearer Context Inactivity Notification message) to the CU-CP 172A. Thus, the CU-CP 172 A can determine that the UE 102 is in data inactivity based on the inactivity notification received from the CU-UP 172B. In some implementations, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the UE assistance information, the inactivity notification of the event 322, and/or the inactivity notification of the event 323.

[0062] After a certain period of data inactivity, the CU-CP 172 A can determine that neither the CU 172 (i.e., the CU-CP 172A and/or the CU-UP 172B) nor the UE 102 has transmitted any data in the downlink direction or the uplink direction, respectively, during the certain period. In response to the determination, the CU-CP 172A can determine to transition the UE 102 to the inactive state with SDT configured. Alternatively, the CU-CP 172A can determine to transition the UE 102 to the inactive state without SDT configured in response to determining that the UE 102 is in data inactivity.

[0063] In response to or after determining that the UE 102 is in data inactivity (for the certain period) or determining to transition the UE 102 to the inactive state with SDT configured, the CU-CP 172A sends 324 to the CP-CU 172B a Bearer Context Modification Request message to suspend data transmission for the UE 102. In response, the CU-UP 172B suspends data transmission for the UE 102 and sends 326 a Bearer Context Modification Response message to the CU-CP 172A. In response to or after determining that the UE 102 is in data inactivity (for the certain period) or determining to transition the UE 102 to the inactive state with SDT configured, the CU-CP 172A in some implementations can send 328 a second CU-to-DU message (e.g., a UE Context Modification Request message) to instruct the DU 174 to provide an SDT DU configuration for the UE 102. In some implementations, the CU-CP 172A can include an SDT request indication (e.g., an IE such as a CG-SDT Query Indication IE) to request an SDT DU configuration in the second CU-to-DU message. In response to the SDT request indication or the second CU-to-DU message, the DU 174 can transmit 330 a second DU-to-CU message (e.g., UE Context Modification Response message) to the CU-CP 172A. Alternatively, the DU 174 does not include the SDT DU configuration in the second DU-to-CU message. Instead, the DU 174 sends to the CU-CP 172A an additional DU-to-CU message (e.g., UE Context Modification Required message) including the SDT DU configuration, after receiving the second CU-to-DU message or transmitting the second DU-to-CU message. The CU-CP 172A can transmit an additional CU-to-DU message (e.g., UE Context Modification Confirm message) to the DU 174 in response to the additional CU-to-DU message. In some alternative implementations, the CU-CP 172A can transmit the second CU-to-DU message and receive the second DU-to-CU message or the additional DU- to-CU message, before determining that the UE 102 is in data inactivity. In other alternative implementations, the CU-CP 172A can include the SDT request indication in the first CU-to- DU message of the event 308 and the DU 174 includes the SDT DU configuration in the first DU-to-CU message of the event 310 in response to the SDT request indication.

[0064] In response to determining to transition the UE 102 to the inactive state with SDT configured, the CU-CP 172A can generate an RRC release message (e.g., RRCRelease message RRCConnectionRelease message) to transition the UE 102 to the inactive state. The CU-CP 172A can include the SDT DU configuration (if obtained from the DU 174) and/or an SDT CU configuration in the RRC release message. The CU-CP 172A then sends 332 to the DU 174 a third CU-to-DU message (e.g., a UE Context Release Command message, a UE Context Modification Request message or a DE RRC Message Transfer message), which includes the RRC release message. In turn, the DU 174 transmits 334 the RRC release message to the UE 102. In some implementations, the DU 174 generates a MAC PDU including the RRC release message and transmits 334 the MAC PDU to the UE 102. The RRC release message instructs the UE 102 to transition to the inactive state. The UE 102 transitions 336 to the inactive state from the connected state upon receiving the RRC release message. In response to the third CU-to-DU message, the DU 174 can retain the SDT DU configuration (if generated by the DU 174 during the procedure 328, 330) and may release or retain (a portion of) the first non-SDT DU configuration and/or (a portion of) the second non- SDT DU configuration. The DU 174 can send a third DU-to-CU message (e.g., a UE Context Release Complete message or a UE Context Modification Response message) to the CU-CP 172A in response to the third CU-to-DU message.

[0065] The UE 102 monitors a PDCCH using a C-RNTI to receive a DCI, while operating 302 in the connected state. In response to or after receiving 334 the RRC release message, the UE 102 stops using the C-RNTI to monitor a PDCCH. In some implementations, the UE 102 may retain the C-RNTI in response to or after receiving 334 the RRC release message or transitioning 336 to the inactive state from the connected state. In some implementations, the UE 102 performs a two-step or a four-step random access procedure with the base station 104 (e.g., the CU-CP 172A and/or DU 174) and receives from the DU 174 a random access response message including the C-RNTI in the random access procedure. In other implementations, the UE 102 receives a RRC message (e.g., RRC reconfiguration message) including the C-RNTI from the CU-CP 172A via the DU 174 or from another base station (e.g., base station 106) not shown in Fig. 3.

[0066] The events 320 (optional), 321 (optional), 322 (optional), 323, 324, 326, 328, 330, 332, and 334 are collectively referred to in Fig. 3 as an SDT configuration procedure 394.

[0067] In some implementations, the UE 102 releases the first non-SDT DU configuration and/or second non-SDT DU configuration or at least a portion of the first non-SDT DU configuration and at least a portion of the second non-SDT DU configuration, in response to the RRC release message. In other implementations, if the RRC release message instructs the UE 102 to transition to the inactive state (i.e., RRC_IDLE), the UE 102 releases the first non- SDT DU configuration and/or second non-SDT configuration. In still other implementations, if the RRC release message instructs the UE to transition to the inactive state (i.e., RRC_INACTIVE), the UE 102 releases a first portion of the first and/or second non-SDT DU configurations and retains a second portion of the first and/or second non-SDT DU configurations.

[0068] In some implementations, the CU-CP 172A does not include an indication in the third CU-to-DU message to instruct the DU 174 to retain the SDT DU configuration, and the DU 174 retains the SDT DU configuration as described above. In other implementations, the CU-CP 172A can include an indication in the third CU-to-DU message (e.g., a UE Context Release Command message) to instruct the DU 174 to retain the SDT DU configuration, and the DU 174 retains the SDT DU configuration in response to the indication. If the UE Context Release Command message excludes the indication, the DU 174 releases the SDT DU configuration. In yet other implementations, the CU-CP 172A does not include an indication in the third CU-to-DU message (e.g., a UE Context Modification Request message or a DL RRC Message Transfer message) for the UE 102 to instruct the DU 174 to release the SDT DU configuration. Thus, the DU 174 retains the SDT DU configuration in response to the third CU-to-DU message excluding the indication. If the third CU-to-DU message includes the indication, the DU 174 releases the SDT DU configuration.

[0069] In some implementations, the SDT CU configuration (e.g., SDT-Config IE) includes a DRB list (e.g., a std-DRB-List) including a list of DRB ID(s) indicating ID(s) of DRB(s) configured for SDT. In some implementations, the SDT CU configuration can include a SRB2 indication (e.g., sdt-SRB2-Indicatiori) indicating a SRB2 configured for SDT. In some implementations, the SDT CU configuration can include a compression protocol continue indication (e.g., sdl-DRB-ConlinueROHC) indicating whether a PDCP entity for the DRB(s) configured for SDT, during SDT operation (i.e., initial and/or subsequent SDT described in Fig. 4) continues. For example, the compression protocol can be a RObust Header Compression (ROHC). In some implementations, the SDT CU configuration can include a data volume threshold (e.g., sdt-DataVolumeThreshold) for the UE 102 to determine whether the UE 102 can initiate SDT. In some implementations, the CU-CP 172A can include the SDT DU configuration in the SDT CU configuration. The “SDT CU configuration” may also be referred to simply as an “SDT configuration”. [0070] In some implementations, the SDT DU configuration includes at least one of a buffer status reporting (BSR) configuration, a power headroom reporting (PHR) configuration, and/or CG-SDT configuration(s). The CG-SDT configuration(s) can include or be one or more CG configurations for CG-SDT, a DL bandwidth part (BWP) configuration for CG-SDT, a time alignment timer value for CG-SDT (i.e., a “CG-SDT time alignment timer value”), and/or a timing advance validity threshold for CG-SDT. The DU 174 configures the timing advance validity threshold (e.g., including an RSRP range) for the UE 102 to determine whether the UE 102 can initiate SDT using the configured grant configuration for CG-SDT as described for Fig. 4. In accordance with the timing advance validity threshold, the UE 102 can evaluate whether a stored timing advance value is still valid. If the UE 102 determines that the stored timing advance value is invalid, the UE 102 can initiate a RA-SDT with the CU 172 via the DU 174 as described for Fig. 4. In some implementations, the SDT DU configuration can be an SDT-MAC-PHY-CG-Config IE or SDT-MAC-PHY-Config IE.

[0071] In some implementations, the DU 174 can start or restart a DU CG-SDT timer in response to or after receiving the SDT request indication, generating the CG-SDT configuration(s), receiving 328 the second CU-to-DU message, transmitting 330 the CG-SDT configuration(s) to the CU 172, receiving 332 the third CU-to-DU message, or transmitting 334 the CG-SDT configuration(s) to the UE 102. In some implementations, the DU 174 can start or restart the DU CG-SDT timer with a timer value to manage the CG-SDT configuration(s). In some implementations, the timer value is the same as the CG-SDT time alignment timer value. In other implementations, the timer value is close to the CG-SDT time alignment timer value. For example, the timer value can be larger than and close to the CG- SDT time alignment timer value. In another example, the timer value can be smaller than and close to the CG-SDT time alignment timer value. If and when the DU CG-SDT timer expires, the DU 174 releases the CG-SDT configuration(s). When or after releasing the CG-SDT configuration(s), the DU 174 refrains from receiving PUSCH transmissions from the UE 102 on the radio resources that were reserved or configured for the CG-SDT configuration(s). When or after releasing the CG-SDT configuration(s), the DU 174 can schedule transmissions for other UE(s) on the radio resources that were reserved or configured for the CG-SDT configuration(s). [0072] As described above, the RRC release message 334 in some implementations can include the CG-SDT configuration(s). The UE 102 can start or restart a UE CG-SDT timer (e.g., CG-SDT time alignment timer (CG-SDT-TAT)) in response to or after receiving the CG-SDT configuration(s). In some implementations, the UE 102 can start or restart the UE CG-SDT timer with the CG-SDT time alignment timer value. If and when the CG-SDT timer expires, the UE 102 releases the CG-SDT configuration(s). When or after releasing the CG- SDT configuration(s), the UE 102 refrains from transmitting PUSCH transmissions on the radio resources that were reserved or configured for the CG-SDT configuration(s).

[0073] In some implementations, the DU 174 reserves radio resources configured in the CG configuration(s). In some implementations, the DU 174 releases the radio resources when releasing the SDT DU configuration or the CG-SDT configuration(s). In cases where the DU 174 does not provide the CG-SDT configuration(s) or the SDT DU configuration to the CU- CP 172A, the DU 174 releases all signaling and user data transport resources for the UE 102 in response to the third CU-to-DU message. In cases where the DU 174 provides the SDT DU configuration or the CG-SDT configuration(s) to the CU-CP 172A, the DU 174 retains signaling and user data transport resources for the UE 102 in response to or after receiving the third CU-to-DU message.

[0074] In cases where the SDT DU configuration does not include a configuration for CG- SDT, the CU-CP 172A and/or the DU 174 only configures RA-SDT for the UE 102. In such cases, the UE 102 can perform RA-SDT with the CU 172 via the DU 174 as described for Fig. 4.

[0075] In some implementations, the CU-CP 172A may not request the DU 174 to provide an SDT DU configuration when determining to transition the UE 102 to the inactive state with SDT configured. In such cases, the events 328 and 330 can omitted, and the CU-CP 172A does not include the SDT DU configuration in the RRC release message. Alternatively, the CU-CP 172A may generate the SDT DU configuration by itself (without requesting that the DU 174 provide an SDT DU configuration), and include the SDT DU configuration in the RRC release message.

[0076] In some implementations, the DU 174 does not include an SDT DU configuration in the second DU-to-CU message, e.g., if or because the UE 102 does not support CG-SDT, the DU 174 does not support CG-SDT or the DU 174 does not have available radio resources for CG-SDT. In such cases, the RRC release message does not include an SDT DU configuration. Otherwise, the DU 174 can transmit an SDT DU configuration to the CU-CP 172A as described above. In some implementations, the DU 174 may not include a configuration for CG-SDT in the SDT DU configuration in the second DU-to-CU message, e.g., if or because the UE 102 does not support CG-SDT, the DU 174 does not support CG- SDT or the DU 174 does not have available radio resources for CG-SDT. In such cases, the SDT DU configuration does not include a CG-SDT configuration. Otherwise, the DU 174 can include the CG-SDT configuration(s) in the SDT DU configuration as described above.

[0077] In some implementations, the CU-CP 172A may request the DU 174 to provide an SDT DU configuration as described above, in cases where the UE 102 supports CG-SDT and/or the DU 174 supports CG-SDT. In cases where the UE 102 does not support CG-SDT or the DU 174 does not support CG-SDT, the CU-CP 172A does not request the DU 174 to provide an SDT DU configuration. The CU-CP 172A can receive a UE capability (e.g., UE- NR-Capability IE) of the UE 102 from the UE 102, the CN 110 (e.g., MME 114 or AMF 164) or the base station 106, while the UE operates 302 in the connected state. The UE capability indicates whether the UE 102 supports CG-SDT. Thus, the CU-CP 172A can determine whether the UE 102 supports CG-SDT in accordance with the UE capability. In some implementations, the CU-CP 172A can receive from the DU 174 a DU-to-CU message indicating whether the DU 174 supports CG-SDT. The DU-to-CU message can be the second DU-to-CU message, the message of the event 308 or 316, or a non-UE associated message (e.g., a non-UE associated F1AP message defined in 3GPP specification 38.473).

[0078] In some implementations, the DU 174 may determine whether to provide an SDT DU configuration for the UE 102 to the CU-CP 172 A, depending on whether the UE 102 supports CG-SDT or not. In addition to whether the UE 102 supports CG-SDT or not, the DU 174 may additionally determine whether to provide an SDT DU configuration for the UE 102 to the CU-CP 172A, depending on whether the DU 174 supports CG-SDT or not. In cases where the UE 102 supports CG-SDT and/or the DU 174 supports CG-SDT, the DU 174 provides an SDT DU configuration for the UE 102 to the CU-CP 172A as described above. In cases where the UE 102 does not support CG-SDT or the DU 174 does not support CG- SDT, the DU 174 does not provide an SDT DU configuration for the UE 102 (e.g., the DU 174 does not include the SDT DU configuration in the second DU-to-CU message). The DU 174 can receive the UE capability from the CU-CP 172A, while the UE operates 302 in the connected state or in the inactive state before the event 302. Thus, the DU 174 can determine whether the UE supports CG-SDT in accordance with the UE capability. In some implementations, the DU 174 can send a DU-to-CU message to the CU-CP 172 A to indicate whether the DU 174 supports or does not support CG-SDT, as described above.

[0079] Referring now to Fig. 4, a scenario 400 depicts small data transmission. In the scenario 400, the base station 104 includes a CU 172 and a DU 174. The CU 172 includes a CU-CP 172 A and a CU-UP 172B. In the scenario 400, the UE 102 initially operates 402 in an inactive state with SDT configured. In some implementations or scenarios, the UE 102 can transition to the inactive state with SDT configured from the connected state as described for Fig. 3. In such implementations, the UE 102 can receive a first SDT CU configuration and/or a first SDT DU configuration in a RRC release message (e.g., event 334). In other implementations or scenarios, the UE 102 can transition to the inactive state with SDT configured from the inactive state without SDT configured. For example, the UE 102 can receive from a base station (e.g., the base station 104 or base station 106) an RRC release message that transitions the UE 102 to the inactive state but does not configure SDT (e.g., indicating releasing SDT, or not including an SDT configuration in the RRC release message). In this case, the UE 102 transitions to the inactive state without SDT configured in response to the RRC release message. The UE 102 in the inactive state with or without SDT configured may perform a RAN notification area (RNA) update with the base station without state transitions. During the RNA update, the UE 102 receives another RRC release message including a first SDT CU configuration and/or a first SDT DU configuration from the base station, similar to the RRC release message of the event 334.

[0080] Later in time, the UE 102 operating in the inactive state with SDT configured initiates SDT. In response to or after initiating SDT, the UE 102 generates an initial UL MAC PDU, which includes a UL RRC message and transmits 404 the initial UL MAC PDU to the DU 174 on the cell 124. The UE 102 may start an SDT session timer after (e.g., in response to) initiating the SDT or transmitting the initial UL MAC PDU. In some implementations, the SDT session timer can be a new timer defined in a RRC specification (e.g., vl7.0.0). The DU 174 retrieves the UL RRC message from the initial UL MAC PDU, generates a first DU-to- CU message including the UL RRC message, and sends 406 a first DU-to-CU message to the CU-CP 172A. In some implementations, the first DU-to-CU message can be an Initial UL RRC Message Transfer message. In other implementations, the first DU-to-CU message can be a UL RRC Message Transfer message. [0081] In scenarios in which the UE 102 initiates SDT to transmit UL data (e.g., a data packet) qualifying for SDT, the UE 102 includes the UL data in the initial UL MAC PDU that the UE 102 transmits 404. In scenarios in which the UE 102 initiates SDT to receive DL data, the UE 102 does not include a UL data packet in the initial UL MAC PDU that the UE 102 transmits 404. The UE 102 can initiate SDT to receive DL data in response to receiving a paging from the DU 174. In such scenarios, the UE 102 can include an SDT indication in the initial UL MAC PDU or the UL RRC message to indicate to the base station 104 that the UE 102 is initiating SDT to receive DL data.

[0082] In some implementations, the UE 102 in the inactive state performs a random access procedure with the DU 174 to transmit 404 the UL MAC PDU. In such cases, the SDT can be a RA-SDT. For example, the random access procedure can be a four-step random access procedure or a two-step random access procedure. In the case of the four-step random access procedure, the UE 102 transmits a random access preamble to the DU 174 and, in response, the DU 174 transmits to the UE 102 a random access response (RAR) including an uplink grant, a temporary C-RNTI and a timing advance command, and the UE 102 transmits 404 the UL MAC PDU in accordance with the uplink grant. The DU 174 receives 404 the UL MAC PDU in accordance with the uplink grant in the RAR. In the case of the two-step random access procedure, the UE 102 transmits 404 to the DU 174 a message A (MsgA) including a random access preamble and the UL MAC PDU in accordance with two-step random access configuration parameters. The UE 102 can receive a message B (MsgB) including a temporary C-RNTI and a timing advance command from the DU 174 in response to the MsgA. The UE 102 receives the two-step random access configuration parameters in system information broadcast by the DU 174 on the cell 124 before transmitting 404 the UL MAC PDU. The DU 174 receives 404 the UL MAC PDU in accordance with the two-step random access configuration parameters.

[0083] When the UE 102 succeeds in a contention resolution in the random access procedure, the UE 102 discards a previously retained C-RNTI (e.g., described for Fig. 3) and determines the temporary C-RNTI to be a particular C-RNTI (i.e., a new C-RNTI). The UE 102 monitors a PDCCH from the DU 174 using the C-RNTI to communicate 418 data with the DU 174. More specifically, the UE 102 receives a DCI and a CRC of the DCI on a PDCCH from the DU 174 and verifies the CRC using the C-RNTI. The DCI can include an uplink grant or a downlink assignment. If the UE 102 verifies the CRC is correct and the DCI includes an uplink grant, the UE 102 uses the uplink grant to transmit 418 UL data to the DU 174. If the UE 102 verifies the CRC is correct and the DCI includes a downlink assignment, the UE 102 uses the downlink assignment to receive 418 DL data from the DU 174.

[0084] In other implementations, the UE 102 can transmit 404 the UL MAC PDU on radio resources configured in a CG configuration for SDT (i.e., a CG-SDT configuration) in cases where the UE 102 received such a configuration as described for Fig. 3. Thus, the DU 174 receives 404 the UL MAC PDU on the radio resources.

[0085] In some implementations, the UE 102 can transmit 418 subsequent UL MAC PDU(s), including one or more UL data packets, on radio resources configured in the CG configuration. In some implementations, the UE 102 can transmit 418 the subsequent UL MAC PDU(s,) on radio resources configured in uplink grant(s) received on PDCCH(s) from the DU 174. In some implementations, the UE 102 can transmit 418 some of the subsequent UL MAC PDU(s) on radio resources configured in the CG configuration and transmit 418 the other of the subsequent UL MAC PDU(s) on radio resources configured in the uplink grant(s).

[0086] If the UE 102 includes UL data in the initial UL MAC PDU, the DU 174 retrieves the UL data from the initial UL MAC PDU. In such cases, the DU 174 can include the UL data in the DU-to-CU message of the event 406. Alternatively, the DU 174 can send 415 a DU-to-CU message including the UL data to the CU-CP 172A. In this alternative, the UL data can include or be a PDCP PDU, an RRC PDU, a NAS PDUn or an LTE positioning protocol (LPP) PDU. The PDCP PDU can include an RRC PDU. As yet another alternative, the DU 174 can send 416 the UL data to the CU-UP 172B separately via a user-plane (UP) connection as described below. In this alternative, the UL data can include or be a PDCP PDU and the PDCP PDU can include an SDAP PDU, an IP packet or an Ethernet packet.

[0087] After receiving 406 the first DU-to-CU message, the CU-CP 172 A in some implementations can send 408 a UE Context Setup Request message to the DU 174 to establish a UE Context of the UE 102 at the DU 174. In the UE Context Setup Request message, the CU-CP 172A can include transport layer information for one or more GTP-U tunnels between the CU-UP 172B and DU 174 so that the DU 174 can transmit the UL data and/or subsequent UL data (e.g., in small data communication 418) via the one or more GTP- U tunnels to the CU-UP 172B. In response, the DU 174 can send 410 a UE Context Setup Response message to the CU-CP 172A. After receiving 406 the first DU-to-CU message, transmitting 408 the UE Context Setup Request message, or receiving 410 the UE Context Setup Response message, the CU-CP 172A transmits 412 to the CU-UP 172B a Bearer Context Modification Request message to resume data transmission for the UE 102. In response, the CU-UP 172B resumes data transmission for the UE 102 and transmits 414 a Bearer Context Modification Response message to the CU-CP 172A. After receiving 408 the UE Context Setup Request message or transmitting 410 the UE Context Setup Response message, the DU 174 can transmit 415 the DU-to-CU message including the UL data to the CU-CP 172A, in cases where the UL data of the event 404 includes a RRC message or is associated with an SRB (e.g., SRB1 or SRB2). In cases where the UL data is associated with a DRB, the DU 174 can transmit 416 the UL data to the CU-UP 172B.

[0088] In some implementations, the CU-CP 172A can include transport layer information of the CU-UP 172B in the UE Context Setup Request message. The transport layer information of the CU-UP 172B can include an IP address and/or an uplink tunnel endpoint ID (e.g., TEID). The DU 174 can transmit 416 the UL data to the CU-UP 172B using the transport layer information of the CU-UP 172B. In cases where the UE 102 has subsequent UL data (e.g., one or more UL data packets) to transmit, the UE 102 can transmit 418 one or more subsequent UL MAC PDUs including the subsequent UL data to the DU 174. In turn, the DU 174 retrieves the subsequent UL data from the subsequent UL MAC PDU(s). In cases where the subsequent UL data is associated with one or more SRB (e.g., SRB1 and/or SRB2), the DU 174 transmits 418 the one or more DU-to-CU messages (e.g., UL RRC Message Transfer message(s)) including the subsequent UL data to the CU-CP 172A. Each DU-to-CU message can include a particular UL data packet of the subsequent UL data. In cases where the CU-CP 172 A receives DL data from the CN 110 or edge server, the CU-CP 172 A can transmit 418 one or more CU-to-DU messages (e.g., DL RRC Message Transfer message(s)) including the DL data (e.g., one or more DL data packets) to the DU 174. In turn, the DU 174 transmits 418 one or more DL MAC PDUs including the DL data to the UE 102 operating in the inactive state. In some implementations, the DL data can include or be NAS PDU(s) and/or LPP PDU(s).

[0089] In cases where the subsequent UL data is associated with one or more DRBs, the DU 174 transmits 418 the subsequent UL data to the CU-UP 172B, similar to the event 416. In some implementations, the DU 174 can include DU transport layer information of the DU 174 in the UE Context Setup Response message. The CU-CP 172A can then include the transport layer information of the DU 174 in the Bearer Context Modification Request message. The transport layer information of the DU 174 can include an IP address and/or a downlink TEID. In cases where the CU-UP 172B receives DL data from the CN 110 or edge server, the CU-UP 172B can transmit 418 the DL data (e.g., one or more DL data packets) to the DU 174 using the transport layer information of the DU 174. The DU 174 then transmits 418 one or more DL MAC PDUs including the DL data to the UE 102 operating in the inactive state.

[0090] In some implementations, the UE 102 can include a buffer status report or a power headroom report in the initial and/or subsequent UL MAC PDU(s), e.g., in accordance with the BSR configuration and/or PHR configuration, respectively. In the buffer status report, the UE 102 can include or indicate its buffer status for one or more logical channels or logical channel groups. In the power headroom report, the UE 102 can include or indicate power headroom status or value.

[0091] In some example scenarios, the subsequent UL data and/or DL data described above include IP packet(s), Ethernet packet(s), or application packet(s). In other scenarios, the UL data can include or be PDU(s) (e.g., RRC PDU(s), PDCP PDU(s) or RLC PDU(s)) that includes RRC message(s), NAS message(s), IP packet(s), Ethernet packet(s), or application packet(s).

[0092] The events 404, 406, 408, 410, 412, 414, 415, and 416 are collectively referred to in Fig. 4 as a small data transmission procedure 492.

[0093] In some implementations, the UL RRC message is an (existing) RRC resume request message (e.g., an RRCResumeRequest message, an RRCResumeRe quest message, an RRCConnectionResumeRequest message, or an RRCConnectionResumeRequest message). In other implementations, the UL RRC message can be a new RRC resume request message, similar to the existing RRC resume request message. For example, the new RRC resume request message may be defined in future 3GPP standards documentation. The new RRC resume request message may have the format of an existing RRC resume request message. In the case of the downlink SDT, the UL RRC message can include an SDT indication, which can be a field or information element (IE) (e.g., resumeCause or ResumeCause). In some implementations, the UL RRC message is a common control channel (CCCH) message. [0094] After the UE 102 transmits 404 the UL MAC PDU or communicates 418 the subsequent UL data and/or DL data with the DU 174, the CU-CP 172A can determine to stop the SDT for the UE 102 based on data inactivity of the UE 102 (i.e., based on the UE 102 in the inactive state having no data activity with the base station 104). After the UE 102 transmits 404 the UL MAC PDU or communicates 418 the subsequent UL data and/or DL data with the DU 174, the UE 102 in the inactive state determines or detects data inactivity and transmits 420 to the DU 174, UE assistance information (e.g., a UEAssistancelnformation message) indicating that the UE 102 decides (e.g., needs) or requests to stop the SDT. In turn, the DU 174 transmits 421 a UL RRC Message Transfer message including the UE assistance information to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the UE assistance information. In other implementations, the DU 174 can perform data inactivity monitoring for the UE 102. The CU-CP 172A can transmit a CU-to-DU message (e.g., the UE Context Setup Request message of the event 408 or a UE Context Modification Request message) to the DU 174 to request or command the DU 174 to perform the data inactivity monitoring. In cases where the DU 174 detects or determines that the UE 102 is in data inactivity during the monitoring, the DU 174 can transmit 422 an inactivity notification (e.g., UE Inactivity Notification message) to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the inactivity notification received from the DU 174. In yet other implementations, the CU-UP 172B can perform data inactivity monitoring for the UE 102. The CU-CP 172A can transmit a CP-to-UP message to the CU-UP 172B to request or command the CU-UP 172B to perform the data inactivity monitoring. In some implementations, the CP-to-UP message can be a Bearer Context Setup Request message or a Bearer Context Modification Request message if sent before the UE 102 initiates the SDT. In other implementations, the CP-to-UP message can be a Bearer Context Modification Request message if sent during the SDT (e.g., the event 412). In cases where the CU-UP 172B detects or determines that the UE 102 is in data inactivity during the monitoring, the CU-UP 172B can transmit 423 an inactivity notification (e.g., Bearer Context Inactivity Notification message) to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the inactivity notification received from the CU-UP 172B. In some implementations, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the UE assistance information, the inactivity notification of the event 422, and/or the inactivity notification of the event 423. [0095] After a certain period of data inactivity, the CU-CP 172 A can determine that neither the CU 172 nor the UE 102 has transmitted any data in the downlink direction or the uplink direction, respectively, during the certain period. In response to the determination, the CU-CP 172A can determine to stop the SDT. Alternatively, the CU-CP 172A can determine to immediately stop the SDT for the UE 102 in response to determining that the UE 102 is in data inactivity.

[0096] In response to or after determining that the UE 102 is in data inactivity (for the certain period) or determining to transition the UE 102 to the inactive state with SDT configured, the CU-CP 172A sends 424 to the CP-CU 172B a Bearer Context Modification Request message to suspend data transmission for the UE 102. In response, the CU-UP 172B suspends data transmission for the UE 102 and sends 426 a Bearer Context Modification Response message to the CU-CP 172A. In response to or after determining that the UE 102 is in data inactivity (for the certain period) or determining to transition the UE 102 to the inactive state with SDT configured, the CU-CP 172A sends 428 a second CU-to-DU message (e.g., a UE Context Modification Request message) to instruct the DU 174 to provide an SDT DU configuration (e.g., a second SDT DU configuration) for the UE 102. In some implementations, the CU-CP 172A can include a SDT request indication (e.g., a field or IE) to request an SDT DU configuration in the second CU-to-DU message. In response to the SDT request indication or the second CU-to-DU message, the DU 174 transmits 430 a second DU-to-CU message (e.g., UE Context Modification Response message) including the second SDT DU configuration to the CU-CP 172A. Alternatively, the DU 174 does not include the second SDT DU configuration in the second DU-to-CU message. Instead, the DU 174 sends to the CU-CP 172A another DU-to-CU message (e.g., UE Context Modification Required message) including the second SDT DU configuration, after receiving the second CU-to-DU message or transmitting the second DU-to-CU message. In some alternative implementations, the CU-CP 172A can transmit the second CU-to-DU message and receive the second DU-to- CU message (or the another DU-to-CU message) before determining that the UE 102 is in data inactivity.

[0097] In response to determining to transition the UE 102 to the inactive state with SDT configured, the CU-CP 172A can generate an RRC release message (e.g., RRCRelease message or RRCConnectionRelease message) to transition the UE 102 to the inactive state. The CU-CP 172A can include the second SDT DU configuration (if obtained from the DU 174) and/or a second SDT CU configuration in the RRC release message.

[0098] Alternatively, the CU-CP 172A may not include an SDT configuration in the RRC release message. In this alternative, the CU-CP 172A can indicate the UE 102 to release or retain the first SDT CU configuration and/or the first SDT DU configuration in the RRC release message. For example, the CU-CP 172A can include a release indication indicating releasing the first SDT CU configuration or the first SDT DU configuration in the RRC release message. If the RRC release message does not include the release indication, the UE 102 retains the first SDT CU configuration and/or the first SDT DU configuration.

[0099] The CU-CP 172A then sends 432 to the DU 174 a third CU-to-DU message including the RRC release message. The DU 174 then transmits 434 the RRC release message to the UE 102. In some implementations, the DU 174 generates a MAC PDU including the RRC release message and transmits 434 the MAC PDU to the UE 102. The RRC release message instructs the UE 102 to be in the inactive state (e.g., to transition to the inactive state or to maintain the inactive state). The UE 102 stops the SDT and remains 436 in the inactive state upon receiving 434 the RRC release message.

[0100] The events 420 (optional), 421 (optional), 422 (optional), 423, 424, 426, 428, 430, 432 and 434 are collectively referred to in Fig. 4 as a SDT complete procedure 494.

[0101] During an SDT session (i.e., events 492 and 494), the UE 102 monitors a PDCCH using a C-RNTI to receive a DCI. In some implementations, the UE 102 receives the C-RNTI in the random access procedure described for the event 404. In other implementations, the UE 102 can receive and retain the C-RNTI as described for Fig. 3. In response to or after receiving 434 the RRC release message, the UE 102 stops using the C-RNTI to monitor a PDCCH. The UE 102 may retain the C-RNTI in response to or after receiving 434 the RRC release message or transitioning 436 to the inactive state from the connected state. In cases where the RRC release message 434 configures CG-SDT, the UE 102 in some implementations can retain the C-RNTI. In cases where the RRC release message 434 does not configure or releases CG-SDT, the UE 102 in some implementations can release the C- RNTI.

[0102] In some implementations, the second SDT CU configuration can be the same as the first SDT CU configuration. In other implementations, the second SDT CU configuration can be different from the first SDT CU configuration. The UE 102 can update (e.g., replace or modify) the first SDT CU configuration with the second SDT CU configuration. In some implementations, the CU-CP 172 A can include an indication in the RRC release message to indicate that the UE 102 is to update the first SDT CU configuration with the second SDT CU configuration. In such implementations, the UE 102 can update the first SDT CU configuration with the second SDT CU configuration in response to the indication. In other implementations, the CU-CP 172A can include a modification indication in the RRC release message to indicate that the UE 102 is to modify the first SDT CU configuration with the second SDT CU configuration. In such implementations, the UE 102 can modify the first SDT CU configuration with the second SDT CU configuration in response to the modification indication. In yet other implementations, the CU-CP 172A can include a setup indication in the RRC release message to indicate that the UE 102 is to replace the first SDT CU configuration with the second SDT CU configuration. In such implementations, the UE 102 can replace the first SDT CU configuration with the second SDT CU configuration in response to the setup indication.

[0103] In some implementations, the second SDT DU configuration can be the same as the first SDT DU configuration. In other implementations, the second SDT DU configuration can be different from the first SDT DU configuration. The UE 102 can update (e.g., replace or modify) the first SDT DU configuration with the second SDT DU configuration. In some implementations, the DU 174 can include an indication in the second SDT DU configuration to indicate that the UE 102 is to update the first SDT DU configuration with the second SDT configuration. In such implementations, the UE 102 can update the first SDT DU configuration with the second SDT DU configuration in response to the indication. In other implementations, the DU 174 can include a modification indication in the second SDT DU configuration to indicate that the UE 102 is to modify the first SDT DU configuration with the second SDT DU configuration. In such implementations, the UE 102 can modify the first SDT DU configuration with the second SDT DU configuration in response to the modification indication. In yet other implementations, the DU 174 can include a setup indication in the second SDT DU configuration to indicate that the UE 102 is to replace the first SDT DU configuration with the second SDT DU configuration. In such implementations, the UE 102 can replace the first SDT DU configuration with the second SDT DU configuration in response to the setup indication. [0104] In cases where the CU-CP 172 A and/or the DU 174 support delta configuration, the CU-CP 172A may not send 428 the CU-to-DU message to obtain the second SDT DU configuration from the DU 174. Unless a condition for releasing the first SDT configuration is satisfied, the DU 174 retains the first SDT DU configuration. Alternatively, the CU-CP 172A can include the first SDT DU configuration in the second CU-to-DU message to cause the DU 174 to retain the first SDT DU configuration. In these cases, the CU-CP 172A may not include an SDT DU configuration and/or an SDT CU configuration in the RRC release message to cause the UE 102 to continue using the first SDT CU configuration and/or the first SDT DU configuration. In some implementations, the CU-CP 172A may not include a release indication in the RRC release message in order to configure the UE 102 to continue using the first SDT DU configuration and/or the first SDT CU configuration. The release indication indicates that the UE 102 is to release the previously received SDT DU configuration and/or the SDT CU configuration. In cases where the CU-CP 172A includes the release indication in the RRC release message, the UE 102 releases the first SDT CU configuration and/or the first SDT DU configuration in response to the release indication.

[0105] In cases where the CU-CP 172 A and/or DU 174 do not support delta configurations, the CU-CP 172A may include the SDT DU configuration and/or the SDT CU configuration in the RRC release message as described above.

[0106] In response to the third CU-to-DU message, the DU 174 can retain the second SDT DU configuration and may or may not release the first non-SDT DU configuration and/or second non-SDT DU configuration. The DU 174 can send a third DU-to-CU message (e.g., a UE Context Release Complete message or a UE Context Modification Response message) to the CU-CP 172A in response to the third CU-to-DU message. In some implementations, if the RRC release message instructs the UE 102 to transition to the inactive state (i.e., RRC_IDLE), the UE 102 releases a non-SDT configuration (e.g., the first non-SDT DU configuration, first non-SDT CU configuration, second non-SDT DU configuration and/or second non-SDT CU configuration described for Fig. 3) and at least one SDT configuration (e.g., the SDT DU configuration and SDT CU configuration described for Fig. 3).

[0107] The events 420 (optional), 421 (optional), 422 (optional), 423, 424, 426, 428, 430, 432, and 434 are collectively referred to in Fig. 4 as an SDT complete procedure 494, similar to the procedure 394. Examples and implementations for events 320, 321, 322, 323, 324, 326, 328, 330, 332, 334 can apply to events 420, 421, 422, 423, 424, 426, 428, 430, 432, 434, respectively. After stopping the SDT, if the UE 102 is configured with an SDT configuration, the UE 102 can perform another SDT procedure 493 with the base station 104, similar to the procedure 492. After completing the procedure 493, the base station 104 can perform an SDT complete procedure 495 with the UE 102, similar to the procedure 494.

[0108] In some implementations, the CU-CP 172A does not request the DU 174 to provide an SDT DU configuration for transitioning the UE 102 to the inactive state with SDT configured. In such cases, the events 428 and 430 can be omitted, and the CU-CP 172A does not include an SDT DU configuration in the RRC release message. Alternatively, the CU-CP 172A may generate the SDT DU configuration by itself and include the SDT DU configuration in the RRC release message.

[0109] In some implementations, the DU 174 does not include an SDT DU configuration in the second DU-to-CU message, e.g., if or because the UE 102 does not support CG-SDT, the DU 174 does not support CG-SDT, or the DU 174 does not have available radio resources for CG-SDT. In such cases, the RRC release message does not include an SDT DU configuration. Otherwise, the DU 174 can include an SDT DU configuration as described above. In some implementations, the DU 174 does not include a CG-SDT configuration in the SDT DU configuration in the second DU-to-CU message, e.g., if or because the UE 102 does not support CG-SDT, the DU 174 does not support CG-SDT, or the DU 174 does not have available radio resources for CG-SDT. In such cases, the SDT DU configuration does not include a CG-SDT configuration. Otherwise, the DU 174 can include the at least one CG- SDT configuration in the SDT DU configuration as described above.

[0110] In some implementations, the CU-CP 172A can request the DU 174 to provide an SDT DU configuration as described above, in cases where the UE 102 supports CG-SDT and/or the DU 174 supports CG-SDT. In cases where the UE 102 does not support CG-SDT or the DU 174 does not support CG-SDT, the CU-CP 172A does not request the DU 174 to provide an SDT DU configuration. The CU-CP 172A can receive a UE capability (e.g., UE- NR-Capability IE) of the UE 102 from the UE 102, the CN 110 (e.g., MME 114 or AMF 164), or the base station 106, either before the UE 102 initiated the SDT, while the UE operates 402 in the inactive state, while the UE performs the SDT (e.g., in the UE Context Setup Request message of the event 408 or the CU-to-DU message of the event 428) or while the UE operates in the connected state as described for Fig. 3. The UE capability indicates whether the UE 102 supports CG-SDT. Thus, the CU-CP 172A can determine whether the UE supports CG-SDT in accordance with the UE capability. In some implementations, the CU-CP 172A can receive from the DU 174 a DU-to-CU message indicating whether the DU 174 supports CG-SDT. The DU-to-CU message can be the second DU-to-CU message, the message of the event 308 or 316, or a non-UE associated message (e.g., a non-UE associated F1AP message as defined in 3GPP specification 38.473).

[0111] In some implementations, the DU 174 may determine whether to provide an SDT DU configuration for the UE 102 to the CU-CP 172 A, depending on whether the UE 102 supports or does not support CG-SDT. In addition to whether the UE 102 supports CG-SDT or not, the DU 174 may additionally determine whether to provide an SDT DU configuration for the UE 102 to the CU-CP 172A, depending on whether the DU 174 supports CG-SDT or not. In cases where the UE 102 supports CG-SDT and/or the DU 174 supports or enables CG-SDT, the DU 174 provides an SDT DU configuration for the UE 102 to the CU-CP 172A as described above. In cases where the UE 102 does not support CG-SDT or the DU 174 does not support CG-SDT, the DU 174 does not provide an SDT DU configuration for the UE 102 (e.g., the DU 174 does not include the SDT DU configuration in the second DU-to-CU message). The DU 174 can receive the UE capability from the CU-CP 172A, e.g., while the UE 102 operates in the connected state or in the inactive state. Thus, the DU 174 can determine whether the UE 102 supports CG-SDT in accordance with the UE capability. In some implementations, the DU 174 can send a DU-to-CU message to the CU-CP 172A to indicate whether the DU 174 supports or does not support CG-SDT, as described above.

[0112] Next, several example methods, that can be implemented in one or more base stations, DUs or CUs or in a RAN to support data communications in the inactive state, are discussed next with reference to Figs. 5-11. In the following description, the “CG” can be replaced by “CG-SDT” or vice versa.

[0113] Fig. 5 illustrates a method 500, which can be implemented/performed by a CU (e.g., the CU 172 or CU-CP 172A) for managing CG-SDT for a UE (e.g., the UE 102).

[0114] The method 500 begins at block 502, where the CU determines to configure CG- SDT for a UE. At block 504, in response to the determination at block 502, the CU obtains a CG configuration from a DU to configure CG-SDT for the UE (e.g., events 328, 330, 428, 430, 394, 494, 495). At block 506, the CU transmits an RRC release message including the CG configuration to the UE via the DU (e.g., events 332, 334, 432, 434, 394, 494, 495). At block 508, the CU starts a CG timer to manage the CG configuration in response to the determination or transmitting the RRC release message. After block 508, the flow proceeds to block 510 and/or block 514. At block 510, the CU detects that the CG timer expires. At block 512, the CU transmits a CU-to-DU message to the DU to indicate releasing the CG configuration in response to detecting (at block 510) that the CG timer expires. Otherwise (or additionally), the flow proceeds to block 514. At block 514, the CU receives a DU-to-CU message from the DU. At block 516, the CU restarts the CU timer in response to the DU-to- CU message.

[0115] To transmit the RRC release message to the UE via the DU, the CU in some implementations generates a PDCP PDU including the RRC release message and transmits a CU-to-DU message (e.g., a UE Context Release Command message or a DL RRC Message Transfer message) including the PDCP PDU to the DU. The DU retrieves the PDCP PDU from the CU-to-DU message, generates an RLC PDU including the PDCP PDU, generates a MAC PDU including the RLC PDU, and transmits the MAC PDU to the UE. To transmit the MAC PDU, the DU can generate a PDSCH transmission including the MAC PDU and transmit the PDSCH transmission to the UE.

[0116] In some implementations, the DU resets a MAC entity that the DU used to communicate with the UE after transmitting the RRC release message, the PDCP PDU, the RLC PDU, or the MAC PDU. In other implementations, the DU resets the MAC PDU entity after (e.g., in response to) receiving an RLC acknowledgement for the RLC PDU. In still other implementations, the DU resets the MAC entity in response to or after receiving an HARQ acknowledgement for the MAC PDU or the PDSCH transmission.

[0117] In some implementations, the CU can receive a DU-to-CU message (e.g., UE Context Modification Required message) from the DU and restarts the CU in response to the DU-to-CU message. In some implementations, the DU transmits a timing advance command to the UE, while communicating with the UE using the CG configuration. In response to transmitting the timing advance command to the UE, the DU can transmit the DU-to-CU message to CU.

[0118] In some implementations, the UE starts or restarts a CG-SDT-TAT in response to receiving the RRC release message. When the UE receives the timing advance command from the DU, the UE restarts the CG-SDT-TAT. [0119] In some implementations, the CU can include an indication indicating releasing the CG configuration in the CU-to-DU message. In some implementations, the indication can be a cause value.

[0120] Fig. 6A illustrates a method 600A, which can be implemented/performed by a DU (e.g., the DU 174) for managing CG-SDT for a UE (e.g., the UE 102).

[0121] The method 600A begins at block 602, where the DU receives from a CU a first CU-to-DU message requesting a CG configuration for a UE (e.g., events 328, 428, 394, 494, 495). At block 604, in response to the first CU-to-DU message, the DU transmits to the CU a first DU-to-CU message including a CG configuration for the UE. At block 606, the DU receives from the CU a second CU-to-DU message including an RRC release message for the UE (e.g., events 332, 432, 394, 494, 495). At block 608, the DU transmits the RRC release message to the UE (e.g., events 334, 434, 394, 494, 495). At block 610, the DU starts or restarts a CG timer to manage the CG configuration in response to the first CU-to-DU message or the second CU-to-DU message. At block 612, the DU (attempts to) receives a PUSCH transmission from the UE in accordance with the CG configuration. After block 612, the flow proceeds to block 614 and/or block 618. At block 614, the DU detects that the CG timer expires. At block 616, in response to detecting that the CG timer expires, the DU stops attempting to receive or stops receiving a PUSCH transmission in accordance with the CG configuration. Otherwise, the flow proceeds to block 618. At block 618, the DU transmits a timing advance command to the UE. At block 620, the DU restarts the CG timer in response to transmitting the timing advance command to the UE.

[0122] To transmit the RRC message to the DU in the second CU-to-DU message, the CU in some implementations generates a PDCP PDU including the RRC release message, and includes the PDCP PDU in the second CU-to-DU message. In such implementations, the DU at block 906 receives the second CU-to-DU message including the PDCP PDU. In turn, the DU generates an RLC PDU including the PDCP PDU, generates a MAC PDU including the RLC PDU, and transmits the MAC PDU to the UE. To transmit the MAC PDU, the DU can generate a PDSCH transmission including the MAC PDU, and transmit the PDSCH transmission to the UE.

[0123] In some implementations, the DU resets a MAC entity that the DU used to communicate with the UE after transmitting the RRC release message, the PDCP PDU, the RLC PDU, or the MAC PDU. In other implementations, the DU resets the MAC PDU entity in response to or after receiving an RLC acknowledgement for the RLC PDU. In still other implementations, the DU resets the MAC entity in response to or after receiving an HARQ acknowledgement for the MAC PDU or the PDSCH transmission.

[0124] In some implementations, the DU can include, in the CG configuration, a CG-SDT- TAT value for the UE to manage the CG configuration. In some implementations, the DU can set a CG timer value of the CG timer to a value based on (e.g., close to) the CG-SDT- TAT value to ensure that the DU does not miss to receive a PUSCH transmission that the UE transmits in accordance with the CG configuration. For example, the DU can set the CG timer value to a value larger than or equal to the CG-SDT-TAT value to ensure that the UE releases the CG configuration before the DU releases the CG configuration.

[0125] In some implementations, the DU releases the CG configuration upon detecting that the CG timer expires. In some implementations, upon detecting that the CG timer expires or releasing the CG configuration, the DU can transmit a DU-to-CU message to the CU to indicate that the CG configuration is released or the UE is not configured with a CG configuration. In some implementations, the DU can reset the MAC entity in response to detecting that the CG timer expires.

[0126] Fig. 6B is a flow diagram of an example method 600B, similar to the method 600A. The method 600B begins at block 602, where the DU receives from a CU a first CU-to-DU message requesting a CG configuration for a UE (e.g., events 328, 428, 394, 494, 495). At block 604, in response to the first CU-to-DU message, the DU transmits to the CU a first DU- to-CU message including a CG configuration for the UE (e.g., events 328, 428, 394, 494, 495). At block 606, the DU receives from the CU a second CU-to-DU message including an RRC release message for the UE (e.g., events 332, 432, 394, 494, 495). At block 609, the DU transmits a DL MAC PDU, including a timing advance command and the RRC release message, to the UE (e.g., events 334, 434, 394, 494, 495). At block 611, in response to transmitting the timing advance command or DL MAC PDU, the DU starts or restarts a CG timer to manage the CG configuration. At block 612, the DU (attempts to) receives a PUSCH transmission from the UE in accordance with the CG configuration. After block 612, the flow proceeds to block 614 and/or block 618. At block 614, the DU detects that the CG timer expires. At block 616, in response to detecting that the CG timer expires, the DU stops attempting to receive or stop receiving a PUSCH transmission in accordance with the CG configuration. Otherwise, the flow proceeds to block 618. At block 618, the DU transmits a timing advance command to the UE. At block 620, the DU restarts the CG timer in response to transmitting the timing advance command to the UE.

[0127] Fig. 6C is a flow diagram of an example method 600B, similar to the methods 600A and 600B. The method 600C begins at block 613, where the DU transmits a CG configuration to a UE via a CU (e.g., events 330, 332, 334, 430, 432, 434, 394, 494, 495). At block 615, the DU starts or restarts a CG timer to manage the CG configuration in response to or after transmitting the CG configuration to the CU. At block 612, the DU (attempts to) receives a PUSCH transmission from the UE in accordance with the CG configuration. After block 612, the flow proceeds to block 614 and/or block 618. At block 614, the DU detects that the CG timer expires. At block 616, in response to detecting that the CG timer expires, the DU stops attempting to receive or stops receiving a PUSCH transmission in accordance with the CG configuration. Otherwise, the flow proceeds to block 618. At block 618, the DU transmits a timing advance command to the UE. At block 620, the DU restarts the CG timer in response to transmitting the timing advance command to the UE.

[0128] Fig. 7 illustrates a method 700, which can be implemented/performed by a base station (BS) (e.g., the base station 104) for managing CG-SDT for a UE (e.g., the UE 102).

[0129] The method 700 begins at block 708, where the BS transmits an RRC release message including a CG configuration to a UE (e.g., events 332, 334, 432, 434, 394, 494, 495). At block 710, in response to or after transmitting the RRC release message, the BS starts or restarts a CG timer to manage the CG configuration. At block 712, the BS (attempts to) receives a PUSCH transmission from the UE in accordance with the CG configuration. After block 712, the flow proceeds to block 714 and/or block 718. At block 714, the BS detects that the CG timer expires. At block 716, the BS releases the CG configuration in response to detecting that the CG timer expires. Otherwise, the flow proceeds to block 718. At block 718, the BS transmits a timing advance command to the UE. At block 720, the BS restarts the CG timer in response to transmitting the timing advance command to the UE.

[0130] Fig. 8 illustrates a method 800, which can be implemented/performed by a CU (e.g., the CU 172 or CU-CP 172A) for managing CG-SDT for a UE (e.g., the UE 102).

[0131] The method 800 begins at block 802, where the CU determines to configure CG- SDT for a UE. At block 804, the CU obtains a CG configuration from a DU to configure CG- SDT for the UE in response to the determination (e.g., events 328, 330, 428, 430, 394, 494, 495). At block 806, the CU transmits an RRC release message including the CG configuration to the UE via the DU (e.g., events 332, 334, 432, 434, 394, 494, 495). At block 808, in response to the determination, the CU determines to release the CG configuration. At block 810, the CU transmits a CU-to-DU message to the DU to indicate the DU to release the CG configuration. At block 812, the CU receives a DU-to-CU message from the DU in response to the CU-to-DU message.

[0132] In some implementations, the CU-to-DU message and the DU-to-CU message can be a UE Context Modification Request message and a UE Context Modification Acknowledge message, respectively. In other implementations, the CU-to-DU message and the DU-to-CU message can be a UE Context Release Command message and a UE Context Release Complete message, respectively.

[0133] Fig. 9 illustrates a method 900, which can be implemented/performed by a DU (e.g., the DU 174) for managing CG-SDT for a UE (e.g., the UE 102).

[0134] The method 900 begins at block 902, where the DU transmits a CG configuration to a UE via a CU (e.g., events 330, 430, 394, 494, 495). At block 904, the DU attempts to receive or receives UL data from the UE in accordance with the CG configuration (e.g., events 404, 418, 420). At block 906, the DU receives from the CU a CU-to-DU message to indicate releasing the CG configuration. At block 908, in response to the CU-to-DU message, the DU releases the CG configuration and transmits a DU-to-CU message to the CU.

[0135] Fig. 10 illustrates a method 1000, which can be implemented/performed by a DU (e.g., the DU 174) for managing CG-SDT for a UE (e.g., the UE 102).

[0136] The method 1000 begins at block 1002, where the DU transmits a CG configuration to a UE via a CU (e.g., events 330, 430, 394, 494, 495). At block 1004, the DU attempts to receive or receives UL data from the UE in accordance with the CG configuration (e.g., events 404, 418, 420). At block 1006, the DU determines to release the CG configuration. At block 1008, the DU transmits a DU-to-CU message to the CU in response to the determination. At block 1010, the DU receives a CU-to-DU message from the CU upon transmitting the DU-to-CU message.

[0137] In some implementations, the CU can include a cause value indicating releasing the CG configuration in the CU-to-DU message. In some implementations, the CU-to-DU message can be a UE Context Release Command message. In some implementations, the DU-to-CU message can be a UE Context Release Request message.

[0138] In other implementations, the DU-to-CU message can be a UE Context Modification Required message. In such implementations, the CU can transmit a UE Context Modification Confirm message to the DU in response to the UE Context Modification Required message.

[0139] In some implementations, the DU releases the CG configuration in response to the CU-to-DU message. In some implementations, the DU stops attempting to receive or stops receiving a PUSCH transmission in accordance with the CG configuration in response to determining to release or the CG configuration or receiving the CU-to-DU message.

[0140] Fig. 11 illustrates a method 1100, which can be implemented/performed by a CU (e.g., the CU 172 or CU-CP 172A) for managing CG-SDT for a UE (e.g., the UE 102).

[0141] The method 1100 begins at block 1102, where the CU determines to configure CG- SDT for a UE. At block 1104, in response to the determination, the CU obtains a CG configuration from a DU to configure CG-SDT for the UE (e.g., events 328, 330, 428, 430, 394, 494, 495). At block 1106, the CU transmits a RRC release message including the CG configuration to the UE via the DU (e.g., events 332, 334, 432, 434, 394, 494, 495). At block 1108, the CU receives from the DU a CU-to-DU message to indicate or request releasing the CG configuration. At block 1110, the CU transmits a CU-to-DU message to the DU in response to the DU-to-CU message.

[0142] In some implementations, the DU-to-CU message can be a UE Context Modification Required message or a UE Context Release Request message. In some implementations, the CU-to-DU message can be a UE Context Modification Confirm message or a UE Context Release Command message. In the case of the UE Context Release Command message, the CU receives a UE Context Release Complete message from the DU in response. In cases where the DU transmits the DU-to-CU to indicate releasing the CG configuration, the DU can (determines to) release the CG configuration without waiting for the CU-to-DU message. In cases where the DU transmits the DU-to-CU to request releasing the CG configuration, the DU can release the CG configuration in response to the CU-to-DU message. [0143] The following list of examples reflects a variety of the implementations explicitly contemplated by the present disclosure:

[0144] Example 1. A method, implemented by a distributed unit (DU) of a distributed base station, of managing synchronization with a user equipment (UE), the method comprising: transmitting, to the UE, a configured grant small data transmission (CG-SDT) configuration for use by the UE when the UE is in an inactive state; after transmitting the CG-SDT configuration to the UE, starting or restarting a time alignment timer that indicates validity of the CG-SDT configuration; and while the time alignment timer is running, receiving or attempting to receive transmissions from the UE in accordance with the CG-SDT configuration.

[0145] Example 2. The method of example 1, further comprising: detecting expiration of the time alignment timer; and in response to the detecting, stopping the receiving or attempting to receive transmissions from the UE in accordance with the CG-SDT configuration.

[0146] Example 3. The method of example 1 or 2, further comprising: transmitting a timing advance command to the UE; and after transmitting the timing advance command, restarting the time alignment timer.

[0147] Example 4. The method of any one of examples 1-3, wherein transmitting the CG- SDT to the UE includes transmitting the CG-SDT to the UE via a central unit (CU) of the distributed base station, and wherein the method further comprises: receiving a first CU-to- DU message from the CU, wherein the transmitting the CG-SDT configuration to the UE via the CU includes transmitting a first DU-to-CU message including the CG-SDT configuration to the CU in response to the first CU-to-DU message.

[0148] Example 5. The method of example 4, wherein transmitting the CG-SDT configuration to the UE via the CU includes: transmitting the first DU-to-CU message including the CG-SDT configuration to the CU in response to the first CU-to-DU message; receiving, from the CU, a second CU-to-DU message including a radio resource control (RRC) release message, the RRC release message including the CG-SDT configuration; and transmitting the RRC release message to the UE. [0149] Example 6. The method of example 5, wherein starting or restarting the time alignment timer is in response to the first CU-to-DU message or the second CU-to-DU message.

[0150] Example 7. The method of example 4, wherein transmitting the CG-SDT configuration to the UE via the CU includes: transmitting the first DU-to-CU message including the CG-SDT configuration to the CU; receiving, from the CU, a second CU-to-DU message including a radio resource control (RRC) release message, the RRC release message including the CG-SDT configuration; and transmitting a downlink (DL) medium access control (MAC) protocol data unit (PDU) that includes the RRC release message and a timing advance command to the UE.

[0151] Example 8. A distributed unit (DU) of a distributed base station, the DU comprising one or more processors and configured to implement the method of any one of examples 1-7.

[0152] Example 9. A method, implemented by a base station, of managing synchronization with a user equipment (UE), the method comprising: transmitting to the UE a radio resource control (RRC) release message including a configured grant small data transmission (CG-SDT) configuration for use by the UE when the UE is in an inactive state; after transmitting the RRC release message to the UE, starting or restarting a time alignment timer that indicates validity of the CG-SDT configuration; and while the time alignment timer is running, receiving or attempting to receive transmissions from the UE in accordance with the CG-SDT configuration.

[0153] Example 10. The method of example 9, further comprising: detecting expiration of the time alignment timer; and in response to the detecting, releasing the CG-SDT configuration.

[0154] Example 1 l.The method of example 9, further comprising: transmitting a timing advance command to the UE; and after transmitting the timing advance command, restarting the time alignment timer.

[0155] Example 12. The method of any one of examples 9-11, wherein the base station is a distributed base station, and wherein the method is implemented by a distributed unit (DU) of the distributed base station. [0156] Example 13.The method of example 12, further comprising, before transmitting the RRC release message to the UE: receiving a first CU-to-DU message from a central unit (CU) of the distributed base station; in response to the first CU-to-DU message, transmitting a first DU-to-CU message including the CG-SDT configuration to the CU; and receiving, from the CU, a second CU-to-DU message including the RRC release message.

[0157] Example 14. The method of example 13, wherein starting or restarting the time alignment timer is in response to the first CU-to-DU message or the second CU-to-DU message.

[0158] Example 15. The method of example 13 or 14, wherein transmitting the RRC release message to the UE includes transmitting a downlink (DL) medium access control (MAC) protocol data unit (PDU) that includes the RRC release message and a timing advance command to the UE.

[0159] Example 16. A base station comprising one or more processors and configured to implement the method of any one of examples 9-15.

[0160] Example 17. A method, implemented by a central unit (CU) of a distributed base station, of managing a configured grant small data transmission (CG-SDT) configuration for use by a user equipment (UE) when the UE is in an inactive state, the method comprising: transitioning the UE from a connected state to the inactive state by transmitting a message to the UE via a distributed unit (DU) of the distributed base station; after transitioning the UE, transmitting to the DU a CU-to-DU message indicating that the DU is to release the CG-SDT configuration.

[0161] Example 18. The method of example 17, further comprising: before the transitioning, obtaining the CG-SDT configuration from the DU.

[0162] Example 19. The method of example 17 or 18, wherein the message is a radio resource control (RRC) release message that includes the CG-SDT configuration.

[0163] Example 20. The method of any one of examples 17-19, wherein the CU-to-DU message is a UE context modification request message.

[0164] Example 21. The method of example 20, further comprising: after transmitting the UE context modification request message, receiving a UE context release complete message from the DU. [0165] Example 22. A method, implemented by a central unit (CU) of a distributed base station, of managing a configured grant small data transmission (CG-SDT) configuration for use by a user equipment (UE) when the UE is in an inactive state, the method comprising: transitioning the UE from a connected state to the inactive state by transmitting a message to the UE via a distributed unit (DU) of the distributed base station; after transitioning the UE, receiving from the DU a DU-to-CU message indicating or requesting release of the CG-SDT configuration; and in response to the DU-to-CU message, transmitting to the DU a CU-to-DU message.

[0166] Example 23. The method of example 22, further comprising: before the transitioning, obtaining the CG-SDT configuration from the DU.

[0167] Example 24. The method of example 22 or 23, wherein the message is a radio resource control (RRC) release message that includes the CG-SDT configuration.

[0168] Example 25. The method of any one of examples 22-24, wherein the DU-to-CU message is a UE context modification required message indicating release of the CG-SDT configuration and the CU-to-DU message is a UE context modification confirm message.

[0169] Example 26. The method of any one of examples 22-24, wherein the DU-to-CU message is a request to release the CG-SDT configuration, and the CU-to-DU message is a response indicating that the DU is to release the CG-SDT configuration.

[0170] Example 27. The method of example 26, wherein the DU-to-CU message is a UE context release request message and the CU-to-DU message is a UE context release command message.

[0171] Example 28. A central unit (CU) of a distributed base station, the CU comprising one or more processors and configured to implement the method of any one of examples 17- 27.

[0172] Example 29. A method, implemented by a distributed unit (DU) of a distributed base station, of managing a configured grant small data transmission (CG-SDT) configuration for use by a user equipment (UE) when the UE is in an inactive state, the method comprising: transmitting the CG-SDT configuration to the UE; after transmitting the CG-SDT configuration, receiving, from a central unit (CU) of the distributed base station, a CU-to-DU message indicating that the DU is to release the CG-SDT configuration; and in response to the CU-to-DU message, releasing the CG-SDT configuration. [0173] Example 30. The method of example 29, wherein transmitting the CG-SDT configuration to the UE includes: transmitting the CG-SDT configuration to the CU; receiving from the CU a radio resource control (RRC) release message that includes the CG- SDT configuration; and transmitting the RRC release message to the UE.

[0174] Example 31. The method of example 30, wherein transmitting the RRC release message to the UE includes transmitting a medium access control (MAC) protocol data unit (PDU) that includes the RRC release message.

[0175] Example 32. The method of any one of examples 29-31, wherein the CU-to-DU message is a UE context modification request message.

[0176] Example 33. The method of example 32, further comprising: in response to the CU- to-DU message, transmitting a UE context release complete message to the CU.

[0177] Example 34. A method, implemented by a distributed unit (DU) of a distributed base station, of managing a configured grant small data transmission (CG-SDT) configuration for use by a user equipment (UE) when the UE is in an inactive state, the method comprising: transmitting the CG-SDT configuration to the UE; after transmitting the CG-SDT configuration, determining to release the CG-SDT configuration; and in response to the determining, transmitting to a central unit (CU) of the distributed base station a DU-to-CU message indicating or requesting release of the CG-SDT configuration.

[0178] Example 35. The method of example 34, wherein transmitting the CG-SDT configuration to the UE includes: transmitting the CG-SDT configuration to the CU; receiving from the CU a radio resource control (RRC) release message that includes the CG- SDT configuration; and transmitting the RRC release message to the UE.

[0179] Example 36. The method of example 35, wherein transmitting the RRC release message to the UE includes transmitting a medium access control (MAC) protocol data unit (PDU) that includes the RRC release message.

[0180] Example 37. The method of any one of examples 34-36, further comprising: after transmitting the DU-to-CU message, receiving from the CU a CU-to-DU message, wherein the DU-to-CU message is a UE context modification required message and the CU-to-DU message is a UE context modification confirm message. [0181] Example 38.The method of any one of examples 34-36, further comprising: after transmitting the DU-to-CU message, receiving from the CU a CU-to-DU message, wherein the DU-to-CU message is a request to release the CG-SDT configuration, and the CU-to-DU message is a response indicating that the DU is to release the CG-SDT configuration.

[0182] Example 39. The method of example 38, wherein the DU-to-CU message is a UE context release request message and the CU-to-DU message is a UE context release command message.

[0183] Example 40. A distributed unit (DU) of a distributed base station, the DU comprising one or more processors and configured to implement the method of any one of examples 29-39.

[0184] Example 41. A method, implemented by a central unit (CU) of a distributed base station, of managing synchronization with a user equipment (UE), the method comprising: transitioning the UE from a connected state to an inactive state by transmitting a message to the UE via a distributed unit (DU) of the distributed base station; and after transitioning the UE, starting a time alignment timer that indicates validity of a configured grant small data transmission (CG-SDT) configuration for use by the UE when the UE is in the inactive state.

[0185] Example 42. The method of example 41, further comprising: detecting expiration of the time alignment timer; and in response to the detecting, transmitting a CU-to-DU message to the DU to indicate releasing the CG-SDT configuration.

[0186] Example 43. The method of example 41, further comprising: after transitioning the UE, receiving a DU-to-CU message from the DU; and in response to the DU-to-CU message, restarting the time alignment timer.

[0187] Example 44. The method of any one of examples 41-43, further comprising: before the transitioning, obtaining the CG-SDT configuration from the DU.

[0188] Example 45. The method of any one of examples 41-44, wherein the message is a radio resource control (RRC) release message that includes the CG-SDT configuration.

[0189] Example 46. A central unit (CU) of a distributed base station, the CU comprising one or more processors and configured to implement the method of any one of examples 41- 45.

[0190] The following description may be applied to the description above. [0191] Generally, the description for one of the above figures can apply to another of the above figures. In some implementations, “message” is used and can be replaced by “information element (IE)”, and vice versa. In some implementations, “IE” is used and can be replaced by “field”, and vice versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters”, and vice versa. In some implementations, “small data transmission” can be replaced by “early data transmission (EDT)” and “SDT” can be replaced by “EDT”, and vice versa. In some implementations, “small data transmission” can be replaced by “small data communication”, and vice versa. In some implementations, “stop” can be replaced by “suspend”.

[0192] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media- streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0193] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code, or machine- readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application- specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. 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.

[0194] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.