Managing small data transmission configuration in mobility scenarios

Abstract

A method for managing configuration information for SDT operation is performed by a first RAN node, the method including receiving an RRC message from a UE, receiving from a second RAN node an SDT configuration for use by the UE when the UE is operating in an RRC inactive state during a handover procedure from the second RAN node to the first RAN node, and communicating with the UE operating in an RRC inactive state after the handover procedure based on a UE context of the UE.

Description

[Technical Field]

[0001] The present disclosure relates generally to wireless communications, and more particularly to communication of uplink and / or downlink data between a user device (UE) and a radio access network (RAN) when the UE operates in an inactive or idle state in conjunction with protocols for controlling radio resources. [Background technology]

[0002] This Background is provided for the purpose of generally presenting the context of the present disclosure. The work of the inventors identified herein, to the extent described in this Background section, and aspects of the present specification that may not qualify as prior art at the time of filing, are not admitted expressly or impliedly as prior art to the present disclosure.

[0003] Typically, a base station operating in a cellular radio access network (RAN) communicates with a user device (UE) using a particular radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of the RAT provides transport channels to a medium access control (MAC) sublayer, which in turn provides logical channels to a radio link control (RLC) sublayer, which in turn provides data transfer services to a packet data convergence protocol (PDCP) sublayer. The radio resource control (RRC) sublayer is located above the PDCP sublayer.

[0004] The RRC sublayer defines an RRC_IDLE state in which the 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 a base station, and an RRC_INACTIVE state to enable the UE to more quickly return to the RRC_CONNECTED state through RAN-level base station coordination and RAN paging procedures. In some cases, a UE in the RRC_INACTIVE state has only one relatively small packet to transmit. For such situations, 3GPP has described a small data transmission (SDT) procedure that enables 5G New Radio (NR), a wireless communication standard, to support data transmission by UEs operating in the RRC_INACTIVE state (i.e., without requiring the UE to transition to the RRC_CONNECTED state).

[0005] SDT is enabled per radio bearer and is initiated by the UE only when (1) the amount of uplink (UL) data waiting for transmission (across all SDT-enabled radio bearers) is below a configured threshold, (2) the downlink (DL) reference signal received power (RSRP) exceeds a configured threshold, and (3) valid SDT resources are available. The SDT procedure can be initiated by the UE either via a random access channel (RACH), i.e., random access SDT (RA-SDT), or via type 1 configuration grant (CG) resources, i.e., CG-SDT. For RA-SDT, the network configures two-step and / or four-step random access resources for SDT. In RA-SDT, the UE can send an initial transmission containing data in the payload of message 3 (Msg3) of a four-step random access procedure or message A (MsgA) of a two-step random access procedure. The network can then schedule subsequent uplink and / or downlink transmissions after the random access procedure is completed using dynamic uplink grants and downlink allocations, respectively.

[0006] CG-SDT can only start with valid UL timing alignment. The UE maintains UL time alignment based on an SDT-specific time alignment timer configured by the network and the DL RSRP of a configured number of highest-ranking synchronization signal blocks (SSBs). When the SDT-specific time alignment timer expires, the CG resources are released. At the start of CG-SDT, the UE sends an initial transmission containing data about the CG occasion using the CG configuration, and the network can use dynamic grants to schedule subsequent UL transmissions on future CG resource occasions. During CG-SDT, DL transmissions are scheduled using dynamic allocation. The UE can start subsequent UL transmissions only after receiving confirmation of the initial UL transmission from the network.

[0007] However, it is unclear how a base station of a RAN, including a distributed base station including a central unit (CU) and at least one distributed unit (DU), manages the SDT configuration(s) of a UE during a handover procedure. Failure to properly manage the SDT configuration during handover can result in data communication latency and / or other network inefficiencies. Summary of the Invention

[0008] In various embodiments of the present disclosure, a RAN node (e.g., a base station or a CU in a distributed base station) performs operations to manage the configuration(s) of a UE (e.g., an SDT configuration).

[0009] In a first aspect of the present disclosure, during a handover procedure or a UE context acquisition procedure in which a first RAN node is a target node and a second RAN node is a source node, the first RAN node discards at least a portion of the SDT configuration received from the second RAN node.

[0010] In some embodiments, the first RAN node receives the SDT configuration and the UE context from the second RAN node and discards the SDT configuration but retains the UE context for use when communicating with the UE. Alternatively, the first RAN node can discard only a portion of the SDT configuration (e.g., the SDT DU configuration) while retaining another portion of the SDT configuration (e.g., the SDT CU configuration).

[0011] In another embodiment, the first RAN node receives handover preparation information including at least one non-SDT configuration and an SDT configuration of the UE, and discards the SDT configuration but retains the non-SDT configuration(s).

[0012] In a second aspect of the present disclosure, during a handover procedure or a UE context acquisition procedure in which a first RAN node is the source node and a second RAN node is the target node, the first RAN node includes at least one non-SDT configuration in handover preparation information that it sends to the second RAN node, but excludes SDT configurations from the handover preparation information.

[0013] In a third aspect of the present disclosure, a CU of a distributed base station sends handover preparation information to a RAN node, and the handover preparation information excludes or includes a configuration (e.g., an SDT configuration) based on whether the RAN node is a DU (e.g., a CU or another base station).

[0014] In one aspect, a method for managing configuration information for SDT operation is performed by a first RAN node, the method including receiving from a second RAN node an SDT configuration for use by the UE when the UE is operating in an inactive state during a handover procedure from the second RAN node to the first RAN node, the method also including discarding at least a portion of the SDT configuration and communicating with the UE operating in an inactive state after the handover procedure or the UE context acquisition procedure.

[0015] In another aspect, a method for managing configuration information for SDT operation is performed by a first RAN node. The method includes communicating with a UE operating in an inactive state using an SDT configuration, transitioning the UE from the inactive state to a connected state, communicating with the UE operating in the connected state using a non-SDT configuration, and determining to handover the UE to a second RAN node. The method also includes, in response to determining, transmitting handover preparation information to the second RAN node, the handover preparation information including the non-SDT configuration and excluding the SDT configuration.

[0016] In another aspect, a method for managing configuration information is performed by a CU of a distributed base station in a RAN. The method includes communicating with a UE and sending handover preparation information to the RAN node. If the RAN node is another base station or another CU, the handover preparation information includes a configuration for the UE to use when communicating with the RAN. If the RAN node is a DU, the handover preparation information excludes the configuration.

[0017] In one aspect, a method performed by a first Radio Access Network (RAN) node for managing configuration information for small data transmission (SDT) operation includes receiving a Radio Resource Control (RRC) message from a user device (UE); receiving from a second RAN node an SDT configuration for use by the UE when the UE is operating in an RRC inactive state during a handover procedure from the second RAN node to a first RAN node; and communicating with the UE operating in the RRC inactive state after the handover procedure based on a UE context of the UE.

[0018] In another aspect, a method for managing configuration information for small data transmission (SDT) operation performed by a first Radio Access Network (RAN) node includes communicating with a user device (UE) operating in a Radio Resource Control (RRC) inactive state using an SDT configuration, transitioning the UE from the RRC inactive state to an RRC connected state, communicating with the UE operating in the RRC connected state using a non-SDT configuration, determining to handover the UE to a second RAN node, and in response to determining, transmitting handover preparation information to the second RAN node, the transmitting handover preparation information excluding the SDT configuration. [Brief explanation of the drawings]

[0019] [Figure 1A] FIG. 1 is a block diagram of an example wireless communication system in which user devices and base stations of the present disclosure can implement techniques of the present disclosure, e.g., to reduce latency in data communications. [Figure 1B] 1B is a block diagram of an exemplary base station in which the central unit (CU) and distributed units (DU) can operate in the system of FIG. 1A. [Figure 2A] 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A communicates with a base station. [Figure 2B] 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A communicates with the CU and DU. [Figure 3] 1A-2B illustrate several scenarios in which the devices of FIGS. 1A-2B can manage small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. [Figure 4] 1A-2B illustrate several scenarios in which the devices of FIGS. 1A-2B can manage small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. [Figure 5] 1A-2B illustrate several scenarios in which the devices of FIGS. 1A-2B can manage small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. [Figure 6] 1A-2B illustrate several scenarios in which the devices of FIGS. 1A-2B can manage small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. [Figure 7] 1A-2B illustrate several methods that may be implemented by one or more of the devices of FIGS. 1A-2B for managing small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. [Figure 8] 1A-2B illustrate several methods that may be implemented by one or more of the devices of FIGS. 1A-2B for managing small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. [Figure 9] 1A-2B illustrate several methods that may be implemented by one or more of the devices of FIGS. 1A-2B for managing small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. [Figure 10] 1A-2B illustrate several methods that may be implemented by one or more of the devices of FIGS. 1A-2B for managing small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. [Figure 11]1A-2B illustrate several methods that may be implemented by one or more of the devices of FIGS. 1A-2B for managing small data transmission configurations in mobility scenarios in accordance with the techniques of this disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0020] As described in more detail below, a user device (UE) and / or a network node in a radio access network (RAN) can use the techniques of this disclosure to transition a UE between states of protocols for managing initial data communications and controlling radio resources between the UE and the RAN. As used in this disclosure, unless the context clearly dictates a more specific meaning, small data communications can refer to small data transmission (SDT) from the network's perspective (i.e., SDT in the downlink direction) or SDT from the UE's perspective (i.e., SDT in the uplink direction).

[0021] 1A , an exemplary 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 may operate within a RAN 105 connected to the CN 110. The CN 110 may be implemented, for example, as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160. The CN 110 may also be implemented as a sixth generation (6G) core, as another example.

[0022] The base station 104 covers cell 124, and the base station 106 covers 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 may be in the same Radio Access Network Region (RNA) or different RNAs. In general, the RAN 105 may include any number of base stations, each of which may cover one, two, three, or any other suitable number of cells. The UE 102 may 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 be connected to the CN 110 via an interface (e.g., an S1 interface or an NG interface). The base stations 104 and 106 can also be interconnected via an interface (e.g., an X2 interface or an Xn interface) for interconnecting NG RAN nodes.

[0023] Among other components, the EPC 111 may include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 is generally configured to forward user plane packets related to voice 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, such as an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management Function (AMF) 164, and / or a Session Management Function (SMF) 166. Generally, the UPF 162 is configured to forward user plane packets generally related to voice 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.

[0024] 1A, base station 104 supports cell 124, and base station 106 supports cell 126. Because cells 124 and 126 may overlap, UE 102 may select, reselect, or hand over from one of cells 124 and 126 to the other. To directly exchange messages or information, base station 104 and base station 106 may support an X2 interface or an Xn interface. In general, CN 110 may be connected to any suitable number of base stations supporting NR and / or EUTRA cells.

[0025] As described in more 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, such as when the UE 102 operates in an inactive or idle state of a protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the following examples refer to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol.

[0026] As used herein, unless the context of use dictates a more specific meaning, the terms "data" or "data packet" refer to signaling, control plane information at a protocol layer controlling radio resources (e.g., RRC), a protocol layer controlling mobility management (e.g., MM), a protocol layer controlling session management (e.g., SM), or non-signaling, non-control plane information at one or more protocol layers above a protocol layer controlling radio resources (e.g., RRC), a protocol layer controlling MM, a protocol layer controlling SM, and / or a protocol layer controlling quality of service (QoS) flows (e.g., Service Data Adaptation Protocol (SDAP)). Data to which the UE and / or RAN apply the techniques of this disclosure may include Internet of Things (IoT) data, Ethernet traffic data, Internet traffic data, or Short Message Service (SMS) messages. Furthermore, as described below, in some embodiments, the UE 102 applies the techniques of this disclosure only if the size of the data is below a certain threshold. It should also be understood that as used herein (and unless the context of its usage indicates a more specific meaning), the term "configuration" may refer to a complete configuration or to a subset of the parameters of the complete configuration (e.g., a "delta" or other partial configuration that can extend an existing configuration without completely replacing it).

[0027] In the exemplary scenario described below, the UE 102 transitions to an RRC_INACTIVE state or an RRC_IDLE state, selects the cell of the base station 104, and exchanges data with the base station 104 either through the base station 106 or directly with the base station 104 without transitioning to an RRC_CONNECTED state. As a more specific example, after the UE 102 determines that data is available for UL transmission in the RRC_INACTIVE state or the RRC_IDLE state, the UE 102 can apply one or more security functions to the UL data packet, generate a first UL protocol data unit (PDU) including the secured 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) of the UE 102 in the UL RRC message. The RAN 105 can identify the UE 102 based on the UE ID. In some embodiments, the UE ID may be an Inactive Radio Network Temporary Identifier (I-RNTI), a Resumption ID, or a Non-Access Stratum (NAS) ID. The NAS ID may be an S-Temporary Mobile Subscriber Identity (S-TMSI) or a Globally Unique Identifier (GUTI).

[0028] The security function may include integrity protection and / or encryption functions. When integrity protection is enabled, the UE 102 may generate a message authentication code for integrity (MAC-I) to protect the integrity of the data. Thus, the UE 102 generates a secured packet, in this case, including the data and the MAC-I. When encryption is enabled, the UE 102 may encrypt the data to obtain an encrypted packet, so that the secured packet includes the encrypted data. When both integrity protection and encryption are enabled, the UE 102 may generate a MAC-I to protect the integrity of the data and encrypt the data together with the MAC-I to generate an encrypted packet and the encrypted MAC-I. The UE 102 may then transmit the secured packet to the RAN 105 while in the RRC_INACTIVE or RRC_IDLE state.

[0029] In some embodiments, the data is a Packet Data Convergence Protocol (PDCP) or SDAP UL Service Data Unit (SDU). The UE 102 applies security functions to the SDU and includes the protected 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 may be associated with a Medium Access Control (MAC) layer. Thus, the UE 102 transmits the protected UL PDCP PDU in the UL MAC PDU in these cases. In some embodiments, the UE 102 can include a UL RRC message in the UL MAC PDU. In other embodiments, the UE 102 cannot include a UL RRC message in the UL MAC PDU. In this case, the UE 102 cannot include the UE ID of the UE 102 in a UL MAC PDU that does not include a UL RRC message. In yet other embodiments, the UE 102 can include a UL PDCP PDU in a UL RLC PDU, and then include a UL RLC PDU in the UL MAC PDU. In some embodiments where 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 may be the resumeMAC-I field as specified in 3GPP specification 38.331. In other embodiments, the UE 102 generates an integrity key (e.g., K RRCint The RRC MAC-I can be obtained from the UL RRC message, which has parameters such as COUNT (e.g., a 32-bit value, a 64-bit value, or a 128-bit value), BEARER (e.g., a 5-bit value), and DIRECTION (e.g., a 1-bit value), as well as the COUNT, BEARER, and DIRECTION parameters.

[0030] In other embodiments, the data is a NAS UL SDU. The UE 102 applies a security function to the SDU and includes the protected SDU in a first UL PDU, such as a NAS PDU, which may be associated with a NAS layer. For example, the NAS layer may be the MM or SM sublayer of 5G, Evolved Packet System (EPS), or 6G. The UE 102 may then include the UL NAS PDU in a second UL PDU, such as a UL RRC message. Thus, the UE 102 transmits the (first) protected UL NAS PDU in a UL RRC message in these cases. In some embodiments, the UE 102 may 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. Instead, the UE 102 may include the RRC MAC-I as described above.

[0031] In some embodiments, the UL RRC message may be a Common Control Channel (CCCH) message, an RRC Resume Request message, or an RRC Initial Data Request message. The UL RRC message may include the UE ID of the UE 102, as described above.

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

[0033] In some scenarios and embodiments, the base station 106 can extract 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 exemplary embodiment, the base station 106 extracts 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 extracts the secured packets from the first UL PDU, applies one or two security functions to decrypt the data and / or check integrity protection, and transmits the data to the CN 110 (e.g., the SGW 112, the UPF 162, the MME 114, or the AMF 164) or an edge server. In some embodiments, the edge server can operate within the RAN 105. More specifically, the base station 104 derives at least one security key from the UE context information of the UE 102. Next, the base station 104 extracts data from the secured packet by using at least one security key and transmits the data to the CN 110 or the edge server. When the secured packet is an encrypted packet, the base station 104 decrypts the encrypted packet by using at least one security key (e.g., an encryption key and / or a decryption key) to obtain the data. When the secured packet is an integrity-protected packet, the integrity-protected packet may include data and a MAC-I. The base station 104 can verify whether the MAC-I is valid for the secured packet by using at least one security key (e.g., an integrity key). If the base station 104 confirms that the MAC-I is valid, the base station 104 transmits the data to the CN 110 or the edge server. However, if the base station 104 determines that the MAC-I is invalid, the base station 104 discards the secured packet. Furthermore, if the secured packet is encrypted and integrity-protected, the encrypted and integrity-protected packet may include the encrypted packet along with the encrypted MAC-I.In this case, the base station 104 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 the edge server. However, if the base station 104 determines that the MAC-I is invalid, the base station 104 discards the packet.

[0034] In another embodiment, the base station 106 extracts the secured packet from the first UL PDU and performs a UE context extraction 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. The base station 106 then extracts data from the secured packet by using the at least one security key and transmits the data to the CN 110 (e.g., the UPF 162) or an edge server. When the secured packet is an encrypted packet, the base station 106 decrypts the encrypted packet by using the at least one security key (e.g., an encryption key and / or a decryption key) to obtain the data. When the secured packet is an integrity-protected packet, the integrity-protected packet may include data and a MAC-I. The base station 106 can verify whether the MAC-I is valid for the secured packet by using the at least one security key (e.g., an integrity key). If the base station 106 verifies that the MAC-I is valid, the base station 106 transmits the data to the CN 110. On the other hand, if the base station 106 determines that the MAC-I is invalid, the base station 106 discards the secured packet. Furthermore, if the secured packet is encrypted and integrity protected, the encrypted and integrity protected packet may include the encrypted packet along with the encrypted MAC-I. In this case, the base station 106 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 it to the CN 110. However, if the base station 106 determines that the MAC-I is invalid, the base station 106 discards the packet.

[0035] In other scenarios and embodiments, the base station 104 may extract the UE ID of the UE 102 from the UL RRC message and identify that the base station 104 stores UE context information for the UE 102. Thus, the base station 104 extracts the secured packet from the first UL PDU, extracts the data from the secured packet, and transmits the data to the CN 110 or edge server, as described above.

[0036] Additionally, the RAN 105, in some embodiments, transmits data in the DL direction to a UE 102 operating in an RRC_INACTIVE state or an RRC_IDLE state.

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

[0038] In another embodiment, the base station 104 transmits a first DL PDU to the base station 106, which then generates a second DL PDU (e.g., a DL MAC PDU) that includes the first DL PDU and transmits the second DL PDU to the UE 102 without first transitioning the UE 102 from the RRC_INACTIVE or RRC_IDLE state to the RRC_CONNECTED state. In some embodiments, 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 embodiment, 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.

[0039] In some embodiments, the base station (i.e., base station 104 or 106) generates downlink control information (DCI) and a cyclic redundancy check (CRC) scrambled with the ID of the UE 102 and transmits the second DL PDU generated by the base station. In some embodiments, the ID of the UE 102 may be a radio network temporary identifier (RNTI). For example, the RNTI may 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 an RRC_INACTIVE state or an RRC_IDLE state. The base station scrambles the CRC with the ID of the UE 102. In some embodiments, the base station may assign the ID of the UE 102 to the UE 102 in a random access response or 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 embodiments, the base station may assign the ID of UE 102 to UE 102 in an RRC message (e.g., an RRC release message or an RRC reconfiguration message) that the base station sends to UE 102 before transmitting the DCI and scrambled CRC, for example while UE 102 is in the RRC_CONNECTED state.

[0040] The UE 102, operating in the RRC_INACTIVE state or the RRC_IDLE state, can receive the DCI and scrambled CRC on the PDCCH and then determine that a physical downlink shared channel (PDSCH) containing the second DL PDU is addressed to the UE 102 according to the UE's 102 ID, DCI, and scrambled CRC. The UE 102 can then extract the data from the secured packet. If the secured packet is an encrypted packet, the UE 102 can decrypt the encrypted packet using the appropriate decryption function and security key to obtain the data. If the secured packet is an integrity-protected packet containing data and a MAC-I, the UE 102 can determine whether the MAC-I is valid. If the UE 102 determines that the MAC-I is valid, the UE 102 extracts the data. However, if the UE 102 determines that the MAC-I is invalid, the UE 102 discards the packet. If the secured packet is encrypted and integrity protected, using the encrypted data and the encrypted MAC-I, the UE 102 can decrypt the encrypted packet and the 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 verifies that the MAC-I is valid, the UE 102 retrieves and processes the data. Otherwise, if the UE 102 determines that the MAC-I is invalid, the UE 102 discards the data.

[0041] The base station 104 includes processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory that stores instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware 130 may include special-purpose processing units. In an exemplary embodiment, the processing hardware 130 includes a MAC controller 132 configured to perform random access procedures with one or more user devices, receive UL MAC protocol data units (PDUs) for one or more user devices, and transmit DL MAC PDUs to one or more user devices. The processing hardware 130 may also include a PDCP controller 134 configured to transmit and / or receive PDCP PDUs according to how the base station 104 can transmit DL data and / or receive UL data. The processing hardware 130 may further include an RRC controller 136 to implement procedures and messaging at the RRC sublayer of a protocol communications stack. In the exemplary implementation, processing hardware 130 includes an RRC inactivity controller 138 configured to manage UL and / or DL communications with one or more UEs operating in an RRC_INACTIVE state or an RRC_IDLE state. Base station 106 may include generally similar components. In particular, components 140, 142, 144, 146, and 148 of base station 106 may be similar to components 130, 132, 134, 136, and 138, respectively.

[0042] The UE 102 includes processing hardware 150, which may include one or more general-purpose processors, such as a CPU, non-transitory computer-readable memory storing machine-readable instructions executable by the one or more general-purpose processors, and / or special-purpose processing units. In an exemplary embodiment, the processing hardware 150 includes an RRC inactivity controller 158 configured to manage uplink and / or downlink communications when the UE 102 operates in the RRC_INACTIVE state. In an exemplary embodiment, the processing hardware 150 includes a MAC controller 152 configured to perform random access procedures 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 may also include a PDCP controller 154 configured to transmit and / or receive PDCP PDUs according to how the UE 102 can transmit UL data and / or receive DL data. The processing hardware may further include an RRC controller 156 to implement procedures and messaging at the RRC sublayer of a protocol communications stack.

[0043] 1B illustrates an exemplary distributed or centralized 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 computer-readable memory storing machine-readable instructions executable by the general-purpose processor(s), and / or special-purpose processing units. For example, the CU 172 may include a PDCP controller, an RRC controller, and / or an RRC inactivity controller, such as the PDCP controllers 134, 144, the RRC controllers 136, 146, and / or the RRC inactivity controllers 138, 148. In some implementations, the CU 172 may include an RLC 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.

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

[0045] In some embodiments, the RAN 105 supports integrated access backhaul (IAB) functionality. In some implementations, the DU 174 acts as an (IAB) node and the CU 172 acts as an IAB donor.

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

[0047] The CU-CP 172A can connect to multiple CU-UPs 172B via an E1 interface. The CU-CP 172A selects an appropriate CU-UP 172B for a service requested by the UE 102. In some embodiments, a single CU-UP 172B can connect to multiple CU-CPs 172A via an E1 interface. The CU-CP 172A can connect to one or more DUs 174 via an F1-C interface. A CU-UP 172B can connect to one or more DUs 174 via an F1-U interface under the control of the same CU-CP 172A. In some embodiments, a single DU 174 can connect to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such embodiments, connectivity between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using a bearer context management function.

[0048] FIG. 2A illustrates a simplified example protocol stack 200 according to which a UE 102 can communicate with an eNB / ng-eNB 201A or a gNB 201B (e.g., one or both of base stations 104, 106).

[0049] In the example stack 200, the EUTRA PHY 202A 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 then provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the 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 then provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transfer services to the SDAP 212 or the RRC sublayer (not shown in FIG. 2A ). In some embodiments, the UE 102 supports both EUTRA and NR stacks, supports handover between EUTRA and NR base stations, and / or supports DC over EUTRA and NR interfaces, as shown in Figure 2A. Additionally, as shown in Figure 2A, the UE 102 can support layering of the NR PDCP 210 over the EUTRA RLC 206A and the SDAP sublayer 212 over the NR PDCP sublayer 210.

[0050] The EUTRA PDCP sublayer 208 and the NRPDCP sublayer 210 receive packets that may be referred to as SDUs (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on the PDCP layer 208 or 210) and output packets that may be referred to as PDUs (e.g., to the RLC layer 206A or 206B). For simplicity, this disclosure will refer to both SDUs and PDUs as "packets" except where the distinction between SDUs and PDUs is relevant.

[0051] In the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide a signaling radio bearer (SRB) or an RRC sublayer (not shown in FIG. 2A) to exchange, for example, RRC messages or NAS messages. In the user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide a data radio bearer (DRB) to support data exchange. The data exchanged over the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0052] 2B illustrates a simplified example protocol stack 250 by 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 divided by the radio protocol stack 250 of FIG. 2B as shown. The CU in either the base station 104 or 106 can retain all control and upper layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connectivity to 5GC, the NR PDCP 210 provides SRBs to the RRC 214, which in turn provides DRBs to the SDAP 212, which in turn provides SRBs to the RRC 214.

[0053] Next, some example scenarios involving various components of Figure 1A and related to transmitting data in an inactive or idle state will be described with reference to Figures 3 to 6. To simplify the following description, an "inactive state" can refer to an RRC_INACTIVE state or an RRC_IDLE state, and a "connected state" can refer to an RRC_CONNECTED state.

[0054] 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 172A and a CU-UP 172B. In this scenario 300, the UE 102 initially operates in a connected state (302), communicates with the DU 174 using a DU configuration (i.e., a first non-SDT configuration) (304), and communicates with the CU-CP 172A and / or CU-UP 172B via the DU using a CU configuration (i.e., a first non-SDT CU configuration) (304). While the UE is communicating with the base station 104 (304), the CU-CP 172A can send a UE context modification request message to the DU 174 (306). In response, the DU 174 sends a UE context modification response message including a non-SDT configuration for the UE 102 (i.e., a second non-SDT configuration) to the CU-CP 172A (308). The CU-CP 172A generates an RRC reconfiguration message including the non-SDT DU configuration and sends a first CU-to-DU message (e.g., a DL RRC message transfer message) including the RRC reconfiguration message to the DU 174 (310). The DU 174 then sends an RRC reconfiguration message to the UE 102 (312). In response, the UE 102 sends an RRC reconfiguration complete message to the DU 174 (314), which then sends a first DU-to-CU message (e.g., a UL RRC message transfer message) including the RRC reconfiguration complete message to the CU-CP 172A (316).

[0055] After receiving the RRC reconfiguration message (312), the connected UE 102 communicates with the DU 174 using the non-SDT DU configuration (318) and communicates with the CU-CP 172A and / or CU-UP 172B via the DU. If the RRC reconfiguration message does not include a CU configuration, the UE 102 communicates with the CU-CP 172A and / or CU-UP 172B via the DU 174 using the first non-SDT CU configuration (318). If the RRC reconfiguration message includes a non-SDT CU configuration (i.e., a second non-SDT CU configuration), the UE 102 communicates with the CU-CP 172A and / or CU-UP 172B via the DU 174 using the second non-SDT CU configuration (318). In some embodiments, the second non-SDT CU configuration may extend 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 may communicate with each other using the second non-SDU CU configuration and configuration parameters in the first non-SDT CU configuration that were not extended by the second non-SDU CU configuration (318). In some embodiments, the first non-SDT CU configuration includes configuration parameters related to the operation of the RRC and / or PDCP protocol layers (e.g., RRC 214 and NR PDCP 210) that the UE 102 and the CU 172 use to communicate with each other while the UE 102 operates in a connected state. Similarly, the second non-SDT CU configuration may include configuration parameters related to the operation of the RRC and / or PDCP protocol layers that the UE 102 and the CU 172 use to communicate with each other while the UE 102 is operating in a connected state.In some embodiments, the first non-SDT CU configuration includes configuration parameters of a RadioBearerConfig information element (IE) and / or a MeasConfig IE defined in 3GPP specification 38.331 V16.7.0. Similarly, the second non-SDT CU configuration includes configuration parameters of a RadioBearerConfig IE and / or a MeasConfig IE defined in 3GPP specification 38.331 V16.7.0. In some embodiments, the first non-SDT CU configuration may be or may include configuration parameters of a RadioBearerConfig IE and a MeasConfig IE, and the second non-SDT CU configuration may be or may include a RadioBearerConfig IE and / or a MeasConfig IE.

[0056] In some embodiments, the second non-SDT DU configuration may extend the first non-SDT DU configuration or may 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 may communicate with each other using the second non-SDU DU configuration and also configuration parameters of the first non-SDT DU configuration that were not extended by the second non-SDU DU configuration (318). In some embodiments, the first non-SDT DU configuration includes configuration parameters related to the operation of the RRC, RLC, MAC, and / or PHY protocol layers (e.g., RLC 206B, MAC 204B, and / or PHY 202B) that the UE 102 and the DU 174 use to communicate with each other while the UE 102 operates in a connected state. Similarly, the second non-SDT DU configuration may include configuration parameters related to the operation of the RRC, RLC, MAC, and / or PHY protocol layers that the UE 102 and the DU 174 use to communicate with each other while the UE 102 is operating in a connected state. In some embodiments, the first non-SDT DU configuration includes configuration parameters of a CellGroupConfig IE defined in 3GPP specification 38.331 V16.7.0. Similarly, the second non-SDT DU configuration includes configuration parameters of a CellGroupConfig IE defined in 3GPP specification 38.331 V16.7.0. In some embodiments, the first non-SDT DU configuration and the second non-SDT DU configuration may be CellGroupConfig IEs.

[0057] 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 may be optional.

[0058] While the UE 102 is communicating with the base station 104, or after a non-SDT resource (re)configuration procedure 390 (if performed), the CU-CP 172A can decide to transition the UE 102 from the inactive state to the connected state based on the UE 102's data inactivity state (i.e., based on the UE 102, in the connected state, having no data activity with the base station 104). In some embodiments, while the UE 102 is communicating with the base station 104, or after a non-SDT resource (re)configuration procedure 390 (if performed), the UE 102 determines or detects the data inactivity state and sends 320 UE assistance information (e.g., a UEAssistanceInformation message) to the DU 174 indicating that the UE 102 requests a transition to an SDT-configured inactive state. The DU 174 then sends 321 a UL RRC message transfer message including the UE assistance information to the CU-CP 172A. Therefore, the CU-CP 172A can determine that the UE 102 is in a data inactivity state based on the UE assistance information. In another embodiment, the DU 174 can perform data inactivity state monitoring for the UE 102. The CU-CP 172A can send 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 instruct the DU 174 to perform data inactivity state monitoring. If the DU 174 detects or determines during monitoring that the UE 102 is in a data inactivity state, the DU 174 can send (322) an inactivity state notification (e.g., a UE inactivity state notification message) to the CU-CP 172A. Therefore, the CU-CP 172A can determine that the UE 102 is in a data inactivity state based on the inactivity state notification received from the DU 174. In yet another embodiment, the CU-UP 172B can perform data inactivity state monitoring for the UE 102.CU-CP 172A can send a CP-to-UP message (e.g., a Bearer Context Setup Request message or a Bearer Context Modify Request message) to CU-UP 172B to request or instruct CU-UP 172B to perform data inactivity monitoring. If CU-UP 172B detects or determines during monitoring that UE 102 is in a data inactivity state, CU-UP 172B can send (323) an inactivity state notification (e.g., a Bearer Context Inactivity State Notification message) to CU-CP 172A. Thus, CU-CP 172A can determine that UE 102 is in a data inactivity state based on the inactivity state notification received from CU-UP 172B. In some embodiments, CU-CP 172A can determine that UE 102 is in a data inactivity state based on UE assistance information, the inactivity state notification of event 322, and / or the inactivity state notification of event 323.

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

[0060] In response to or after determining that UE 102 is in a data inactive state (for a period of time), or in response to or after determining to transition UE 102 to an SDT-configured inactive state, CU-CP 172A sends a Modify Bearer Context Request message (324) to CP-CU 172B to suspend data transmission for UE 102. In response, CU-CP 172B suspends data transmission for UE 102 and sends a Modify Bearer Context Response message (326) to CU-CP 172A. Also, in response to or after determining that the UE 102 is in a data inactive state (for a period of time) or in response to or after determining to transition the UE 102 to an SDT-configured inactive state, the CU-CP 172A in some embodiments sends (328) a second CU-to-DU message (e.g., a UE Context Modify Request message) to instruct the DU 174 to provide an SDT DU configuration for the UE 102. In some embodiments, the CU-CP 172A can include an SDT request indication (e.g., an IE such as a CG-SDT Query Indication IE) in the second CU-to-DU message to request the SDT DU configuration. In response to the SDT request indication or the second CU-to-DU message, the DU 174 sends (330) a second DU-to-CU message (e.g., a UE Context Modify Response message) to the CU-CP 172A, including the first SDT DU configuration. Alternatively, the DU 174 does not include the SDT DU configuration in the second DU-to-CU message, but instead sends an additional DU-to-CU message (e.g., a UE context modification request message) including the SDT DU configuration to the CU-CP 172A after receiving or sending the second DU-to-CU message.In response to the additional CU-to-DU message, the CU-CP 172A can send an additional CU-to-DU message (e.g., a UE context modification confirm message) to the DU 174. In some alternative embodiments, the CU-CP 172A can send 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 a data inactive state. In other alternative embodiments, the CU-CP 172A can include an SDT request indication in the first CU-to-DU message of event 308, and the DU 174 includes an SDT DU configuration in the first DU-to-CU message of event 310 in response to the SDT request indication.

[0061] In response to determining to transition the UE 102 to the SDT-configured inactive state, the CU-CP 172A can generate an RRC release message (e.g., an RRCRelease message or an 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 the SDT CU configuration in the RRC release message. The CU-CP 172A then sends a third CU-to-DU message (e.g., a UE Context Release Command message, a UE Context Modify Request message, or a DL RRC Message Transfer message) including the RRC release message to the DU 174 (332). The DU 174 then sends the RRC release message to the UE 102 (334). In some embodiments, the DU 174 generates a MAC PDU including the RRC release message and sends the MAC PDU to the UE 102 (334). The RRC release message instructs the UE 102 to transition to an inactive state. Upon receiving the RRC release message, the UE 102 transitions from the connected state to the inactive state (336). In response to the third CU-to-DU message, the DU 174 may retain the SDT DU configuration (if generated by the DU 174 during procedures 328, 330) and may or may not release (part of) the first non-SDT DU configuration and / or (part of) the second non-SDT DU configuration. In response to the third CU-to-DU message, the DU 174 may 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.

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

[0063] Events 320 (optional), 321 (optional), 322 (optional), 323, 324, 326, 328, 330, 332, and 334 are collectively referred to as SDT configuration procedure 394 in FIG.

[0064] In some embodiments, the UE 102 releases the first non-SDT DU configuration and / or the 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 embodiments, the UE 102 releases the first non-SDT DU configuration and / or the second non-SDT configuration when the RRC release message instructs the UE 102 to transition to an inactive state (i.e., RRC_IDLE). In yet other embodiments, 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 when the RRC release message instructs the UE to transition to an inactive state (i.e., RRC_INACTIVE).

[0065] In some embodiments, the CU-CP 172A does not include an indication in the third CU-to-DU message instructing the DU 174 to retain the SDT DU configuration, but the DU 174 retains the SDT DU configuration as described above. In another embodiment, the CU-CP 172A may include an indication in the third CU-to-DU message (e.g., a UE context release command message) instructing 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 another embodiment, 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 STT DU configuration. Therefore, the DU 174 retains the SDT DU configuration in response to the third CU-to-DU message that excludes the indication. If the third CU-to-DU message includes the indication, the DU 174 releases the SDT DU configuration.

[0066] In some embodiments, parameters in the SDT CU configuration (e.g., SDT-Config IE) include a DRB list (e.g., std-DRBList) containing a list of DRB ID(s) indicating the ID(s) of the DRB(s) configured for SDT. In some embodiments, parameters in the SDT CU configuration may include an SRB2 indication (e.g., sdt-SRB2Indication) indicating the SRB2 configured for SDT. In some embodiments, parameters in the SDT CU configuration may include a compression protocol continue indication (e.g., sdt-DRB-ContinueROHC) indicating whether the PDCP entities of the DRB(s) configured for SDT continue during the continuation of SDT operation (i.e., the initial and / or subsequent SDT described in FIG. 4). For example, the compression protocol may be RObust Header Compression (ROHC). In some embodiments, the SDT CU configuration may include a data volume threshold (e.g., sdt-DataVolumeThreshold) for determining whether the UE 102 can initiate SDT. The CU-CP 172A can include the SDT DU configuration in the SDT CU configuration. The "SDT CU configuration" may also be simply referred to as the "SDT configuration."

[0067] For example, 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) may include or be one or more CG configurations of the CG-SDT, a DL bandwidth portion (BWP) configuration of the CG-SDT, a time alignment timer value of the CG-SDT (e.g., a CG-SDT time alignment timer value), and / or a timing advance validity threshold of the CG-SDT. The DU 174 sets a timing advance validity threshold (e.g., including an RSRP range) for the UE 102 to determine whether the UE 102 can start the SDT using the allowed configurations set for the CG-SDT, as described in FIG. 4. According to the timing advance validity threshold, the UE 102 can evaluate whether the stored timing advance value is still valid. If the UE 102 determines that the stored timing advance value is invalid, the UE 102 may initiate RA-SDT with the CU 172 via the DU 174, as described in Figure 4. In some embodiments, the SDT DU configuration may be an SDT-MAC-PHY-CG-Config IE or an SDT-MAC-PHY-Config IE.

[0068] In some embodiments, the DU 174 can start or restart the DU CG-SDT timer in response to or after receiving an SDT request indication, in response to or after generating CG-SDT configuration(s), in response to or after receiving (328) a second CU-to-DU message, in response to or after transmitting (330) the CG-SDT configuration(s) to the CU 172, in response to or after receiving (332) a third CU-DU message, or in response to or after transmitting (334) the CG-SDT configuration(s) to the UE 102. In some embodiments, the DU 174 can start or restart the DU CG-SDT timer using a timer value that governs the CG-SDT configuration(s). In some embodiments, the timer value is the same as the CG-SDT time alignment timer value. In other embodiments, the timer value is close to the CG-SDT time alignment timer value. For example, the timer value may be greater than and close to the CG-SDT time alignment timer value. In another example, the timer value may be less than and close to the CG-SDT time alignment timer value. 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 reserved or configured for the CG-SDT configuration(s). When or after releasing the CG-SDT configuration(s), the DU 174 may schedule transmissions of other UE(s) on the radio resources reserved or configured for the CG-SDT configuration(s).

[0069] As noted above, in some embodiments, the RRC release message 334 may include the CG-SDT configuration(s). In response to or after receiving the CG-SDT configuration(s), the UE 102 may start or restart the UE's CG-SDT timer (e.g., a CG-SDT time alignment timer (CG-SDT-TAT)). In some embodiments, the UE 102 may start or restart the UE's CG-SDT timer with the CG-SDT time alignment timer value. When the UE CG-SDT timer expires, the UE 102 releases the CG-SDT configuration(s). Upon or after releasing the CG-SDT configuration(s), the UE 102 refrains from sending PUSCH transmissions on the radio resources reserved or configured for the CG-SDT configuration(s).

[0070] In some embodiments, the DU 174 reserves radio resources configured in the configured grant configuration(s). In some embodiments, the DU 174 releases the radio resources configured by the CG-SDT configuration when releasing the SDT DU configuration or the CG-SDT configuration. If 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. If the DU 174 provides the SDT DU configuration or the CG-SDT configuration(s) to the CU-CP 172A, the DU 174 retains the signaling and user data transport resources for the UE 102 in response to or after receiving the third CU-to-DU message.

[0071] If the SDT DU configuration does not include a configuration for CG-SDT, the CU-CP 172A and / or the DU 174 configure only the RA-SDT for the UE 102. In such a case, the UE 102 may perform the RA-SDT with the CU 172 via the DU 174, as described with reference to FIG.

[0072] In some embodiments, the CU-CP 172A may not request the DU 174 to provide an SDT DU configuration when it decides to transition the UE 102 to an SDT-configured inactive state. In such a case, events 328 and 330 can be 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 independently (without requesting the DU 174 to provide it) and include it in the RRC release message.

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

[0074] In some embodiments, if the UE 102 supports CG-SDT and / or the DU 174 supports CG-SDT, the CU-CP 172A may request the DU 174 to provide the SDT DU configuration as described above. If 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 the SDT DU configuration. The CU-CP 172A can receive the UE capabilities (e.g., UE-NR capability IE) of the UE 102 from the UE 102, the CN 110 (e.g., the MME 114 or the AMF 164), or the base station 106 while the UE operates in a connected state (302). The UE capabilities indicate whether the UE 102 supports CG-SDT. Thus, the CU-CP 172A can determine whether the UE supports CG-SDT according to the UE capabilities. In some embodiments, the CU-CP 172A can receive a DU-to-CU message from the DU 174 indicating whether the DU 174 supports CG-SDT. The DU-to-CU message can be a second DU-to-CU message, a message of event 308 or 316, or a non-UE-related message (e.g., a non-UE-related F1AP message defined in 3GPP specification 38.473).

[0075] In some embodiments, the DU 174 may determine whether to provide the SDT DU configuration of the UE 102 to the CU-CP 172A based on whether the UE 102 supports CG-SDT. In addition to whether the UE 102 supports CG-SDT, the DU 174 may further determine whether to provide the SDT DU configuration of the UE 102 to the CU-CP 172A based on whether the DU 174 supports CG-SDT. If the UE 102 supports CG-SDT and / or the DU 174 supports CG-SDT, the DU 174 provides the SDT DU configuration of the UE 102 to the CU-CP 172A, as described above. If the UE 102 does not support CG-SDT or the DU 174 does not support CG-SDT, the DU 174 does not provide the SDT DU configuration to the UE 102 (e.g., the DU 174 does not include the SDT DU configuration in the second DU-to-CU message). While the UE operates in a connected or inactive state (302) before event 302, the DU 174 may receive the UE capabilities from the CU-CP 172A. Thus, the DU 174 may determine whether the UE supports CG-SDT according to the UE capabilities. In some embodiments, the DU 174 may send a DU-to-CU message to the CU-CP 172A to indicate whether the DU 174 supports CG-SDT, as described above.

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

[0077] Later, the UE 102, operating in an inactive state with the SDT configured, initiates the SDT. In response to or after initiating the SDT, the UE 102 generates an initial UL MAC PDU including a UL RRC message and transmits the initial UL MAC PDU to the DU 174 over the cell 124 (404). The UE 102 may start an SDT session timer in response to initiating the SDT. In some embodiments, the SDT session timer may be a new timer defined in the RRC specification (e.g., v17.0.0). The DU 174 extracts the UL RRC message from the initial UL MAC PDU, generates a first DU-to-CU message including the UL RRC message, and transmits the first DU-to-CU message to the CU-CP 172A (406). In some embodiments, the first DU-to-CU message may be an initial UL RRC message transfer message. In other embodiments, the first DU-to-CU message may be a UL RRC message transfer message.

[0078] In a scenario in which the UE 102 initiates an SDT to transmit UL data (e.g., a data packet) that qualifies for the SDT, the UE 102 includes the UL data in the initial UL MAC PDU that the UE 102 transmits (404). In a scenario in which the UE 102 initiates an 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 an SDT to receive DL data in response to receiving a paging from the DU 174. In such a scenario, the UE 102 can include an SDT indication in the initial UL MAC PDU or an UL RRC message to indicate to the base station 104 that the UE 102 is initiating an SDT to receive DL data.

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

[0080] If the UE 102 successfully resolves the contention in the random access procedure, the UE 102 discards the C-RNTI it previously held (e.g., as described in FIG. 3 ) and determines a specific C-RNTI (i.e., a new C-RNTI) as the temporary C-RNTI. The UE 102 monitors the PDCCH from the DU 174 using the C-RNTI and communicates data with the DU 174 (418). More specifically, the UE 102 receives DCI and a CRC of the DCI on the PDCCH from the DU 174 and verifies the CRC using the C-RNTI. The DCI may include an uplink grant or a downlink allocation. If the UE 102 verifies that the CRC is correct and the DCI includes an uplink grant, the UE 102 transmits UL data to the DU 174 using the uplink grant (418). If the UE 102 verifies that the CRC is correct and the DCI includes a downlink allocation, the UE 102 receives 418 DL data from the DU 174 using the downlink allocation.

[0081] In a further embodiment, the UE 102 may transmit 404 the UL MAC PDU on the radio resource configured with the CG configuration for SDT (i.e., the CG-SDT configuration) if the UE 102 receives the CG-SDT configuration as described in Figure 3. Accordingly, the DU 174 receives 404 the UL MAC PDU on the radio resource.

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

[0083] If the UE 102 includes UL data in the initial UL MAC PDU, the DU 174 extracts the UL data from the initial UL MAC PDU. In such a case, the DU 174 may include the UL data in the DU-to-CU message of event 406. Alternatively, the DU 174 may transmit the DU-to-CU message including the UL data to the CU-CP 172A (415). In this alternative example, the UL data may include or be a PDCP PDU, an RRC PDU, a NAS PDU, or an LTE Positioning Protocol (LPP) PDU. The PDCP PDU may include an RRC PDU. As yet another alternative, the DU 174 may separately transmit the UL data to the CU-UP 172B over a user plane (UP) connection (416), as described below. In this alternative example, the UL data may include or be a PDCP PDU, and the PDCP PDU may include an SDAP PDU, an IP packet, or an Ethernet packet.

[0084] After receiving (406) the first DU-to-CU message, the CU-CP 172A in some embodiments can send (408) a UE context setup request message to the DU 174 to establish a UE context for the UE 102 at the DU 174. In the UE context setup request message, the CU-CP 172A can include transport layer information about one or more GTP-U tunnels between the CU-UP 172B and the DU 174 so that the DU 174 can send UL data and / or subsequent UL data (e.g., in small data communication 418) to the CU-UP 172B via one or more GTP-U tunnels. 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 and sending (408) a UE context setup request message or receiving (410) a UE context setup response message, the CU-CP 172A sends (412) a modify bearer context request message to the CU-UP 172B to resume data transmission for the UE 102. In response, the CU-UP 172B resumes data transmission for the UE 102 and sends (414) a modify bearer context response message to the CU-CP 172A. After receiving (408) the UE context setup request message or sending (410) the UE context setup response message, the DU 174 can send (415) a DU-to-CU message including UL data to the CU-CP 172A if the UL data in event 404 includes an RRC message or is associated with an SRB (e.g., SRB1 or SRB2). If the UL data is associated with the DRB, the DU 174 may transmit (416) the UL data to the CU-UP 172B.

[0085] In some embodiments, 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., a TEID). The DU 174 can transmit 416 UL data to the CU-UP 172B using the transport layer information of the CU-UP 172B. If the UE 102 has subsequent UL data to send (e.g., one or more UL data packets), the UE 102 can transmit 418 one or more subsequent UL MAC PDUs containing the subsequent UL data to the DU 174. The DU 174 then extracts the subsequent UL data from the subsequent UL MAC PDU(s). If the subsequent UL data is associated with one or more SRBs (e.g., SRB1 and / or SRB2), the DU 174 sends one or more DU-to-CU messages (e.g., UL RRC message transfer message(s)) containing the subsequent UL data to the CU-CP 172A (418). Each DU-to-CU message may contain a specific UL data packet of the subsequent UL data. If the CU-CP 172A receives DL data from the CN 110 or an edge server, the CU-CP 172A sends one or more CU-to-DU messages (e.g., DL RRC message transfer message(s)) containing the DL data (e.g., one or more DL data packets) to the DU 174 (418). The DU 174 then sends one or more DL MAC PDUs containing the DL data to the UE 102 operating in an inactive state (418). In some embodiments, the DL data may include or be NAS PDU(s) and / or LPP PDU(s).

[0086] If the subsequent UL data is associated with one or more DRBs, the DU 174 transmits the subsequent UL data to the CU-UP 172B (418), similar to event 416. In some embodiments, the DU 174 may include the DU transport layer information of the DU 174 in a UE context setup response message. The CU-CP 172A may then include the transport layer information of the DU 174 in a bearer context modification request message. The transport layer information of the DU 174 may include an IP address and / or a downlink TEID. If the CU-UP 172B receives DL data from the CN 110 or an edge server, the CU-UP 172B may transmit the DL data (e.g., one or more DL data packets) to the DU 174 (418) using the transport layer information of the DU 174. The DU 174 then transmits one or more DL MAC PDUs including the DL data to the UE 102 operating in an inactive state (418).

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

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

[0089] Events 404, 406, 408, 410, 412, 414, 415, and 416 are collectively referred to as small data transmission procedure 492 in FIG.

[0090] In some embodiments, the UL RRC message is an (existing) RRC resume request message (e.g., an RRCResumeRequest message, an RRCResumeRequest message, an RRCConnectionResumeRequest message, or an RRCConnectionResumeRequest message). In other embodiments, the UL RRC message can be a new RRC resume request message, similar to an existing RRC resume request message. For example, the new RRC resume request message can be defined in a future 3GPP standard document. The new RRC resume request message can be in the format of the existing RRC resume request message. In the case of downlink SDT, the UL RRC message can include an SDT indication, which can be a field element or information element (IE) (e.g., resumeCause or ResumeCause). In some embodiments, the UL RRC message is a common control channel (CCCH) message.

[0091] After the UE 102 transmits 404 an UL MAC PDU or communicates 418 subsequent UL and / or DL data with the DU 174, the CU-CP 172A can determine to stop the SDT of the UE 102 based on the UE 102's data inactivity state (i.e., based on the UE 102 being in an inactive state with no data activity with the base station 104). After the UE 102 transmits 404 an UL MAC PDU or communicates 418 subsequent UL and / or DL data with the DU 174, the UE 102 in an inactive state determines or detects the data inactivity state and transmits 420 UE assistance information (e.g., a UE Assistance Information message) to the DU 174 indicating that the UE 102 has determined (e.g., needs) to stop the SDT. The DU 174 then transmits 421 an UL RRC Message Transfer message including the UE assistance information to the CU-CP 172A. Therefore, the CU-CP 172A can determine that the UE 102 is in a data inactivity state based on the UE assistance information. In another embodiment, the DU 174 can perform data inactivity state monitoring for the UE 102. The CU-CP 172A can send a CU-to-DU message (e.g., a UE context setup request message or a UE context modification request message of event 408) to the DU 174 to request or instruct the DU 174 to perform data inactivity state monitoring. If the DU 174 detects or determines during monitoring that the UE 102 is in a data inactivity state, the DU 174 can send (422) an inactivity state notification (e.g., a UE inactivity state notification message) to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in a data inactivity state based on the inactivity state notification received from the DU 174. In yet another embodiment, the CU-UP 172B can perform data inactivity state monitoring for the UE 102. CU-CP 172A may send a CP-to-UP message to CU-UP 172B to request or command CU-UP 172B to perform data inactivity monitoring.In some embodiments, the CP-to-UP message may be a Bearer Context Setup Request message or a Bearer Context Modify Request message if it is sent before the UE 102 begins the SDT. In other embodiments, the CP-to-UP message may be a Bearer Context Modify Request message if it is sent during the SDT (e.g., event 412). If the CU-UP 172B detects or determines during monitoring that the UE 102 is in a data inactive state, the CU-UP 172B may send (423) an inactivity state notification (e.g., a Bearer Context Inactive State Notification message) to the CU-CP 172A. Thus, the CU-CP 172A may determine that the UE 102 is in a data inactive state based on the inactivity state notification received from the CU-UP 172B. In some embodiments, the CU-CP 172A may determine that the UE 102 is in a data inactive state based on the UE assistance information, the inactivity state notification of event 422, and / or the inactivity state notification of event 423.

[0092] After a period of data inactivity, CU-CP 172A may determine that neither CU 172 nor UE 102 transmitted data in the downlink or uplink direction, respectively, during the period. In response to the determination, CU-CP 172A may decide to stop SDT. Alternatively, CU-CP 172A may decide to immediately stop SDT for UE 102 in response to determining that UE 102 is in a data inactivity state.

[0093] In response to or after determining that UE 102 is in a data inactive state (for a period of time), or in response to or after determining to transition UE 102 to an SDT-configured inactive state, CU-CP 172A sends a modify bearer context request message to CP-CU 172B (424) to suspend data transmission for UE 102. In response, CU-CP 172B suspends data transmission for UE 102 and sends a modify bearer context response message to CU-CP 172A (426). Also, in response to or after determining that the UE 102 is in a data inactive state (for a certain period of time) or in response to or after determining to transition the UE 102 to an 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 embodiments, the CU-CP 172A can include an SDT request indication (e.g., a field or IE) in the second CU-to-DU message to request the SDT DU configuration. In response to the SDT request indication or the second CU-to-DU message, the DU 174 sends (430) a second DU-to-CU message (e.g., a 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, and instead, after receiving or sending the second DU-to-CU message, the DU 174 sends another DU-to-CU message (e.g., a UE context modification request message) including the second SDT DU configuration to the CU-CP 172A.In some alternative embodiments, the CU-CP 172A may send a second CU-to-DU message and receive a second DU-to-CU message (or other DU-to-CU message) before determining that the UE 102 is in a data inactive state.

[0094] In response to determining to transition the UE 102 to the SDT-configured inactive state, the CU-CP 172A can generate an RRC release message (e.g., an RRCRelease message or an 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 the second SDT CU configuration in the RRC release message.

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

[0096] The CU-CP 172A then sends a third CU-DU message including an RRC release message to the DU 174 (432). The DU 174 then sends the RRC release message to the UE 102 (434). In some embodiments, the DU 174 generates a MAC PDU including the RRC release message and sends the MAC PDU to the UE 102 (434). The RRC release message instructs the UE 102 to become inactive (e.g., transition to an inactive state or remain in an inactive state). Upon receiving the RRC release message (434), the UE 102 stops the SDT and remains in the inactive state (436).

[0097] Events 420 (optional), 421 (optional), 422 (optional), 423, 424, 426, 428, 430, 432, and 434 are collectively referred to as SDT completion procedure 494 in FIG.

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

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

[0100] In some embodiments, the second SDT DU configuration may be the same as the first SDT DU configuration. In other embodiments, the second SDT DU configuration may differ from the first SDT DU configuration. The UE 102 may update (e.g., replace or modify) the first SDT DU configuration with the second SDT DU configuration. In some embodiments, the DU 174 may include an indication in the second SDT DU configuration that instructs the UE 102 to update the first SDT DU configuration with the second SDT DU configuration. In such embodiments, the UE 102 may update the first SDT DU configuration with the second SDT DU configuration in response to the indication. In some embodiments, the DU 174 may include a modification indication in the second SDT DU configuration that instructs the UE 102 to modify the first SDT DU configuration with the second SDT DU configuration. In such an embodiment, the UE 102 can modify the first SDT DU configuration with the second SDT DU configuration in response to the modification indication. In yet another embodiment, the DU 174 can include a setup indication in the second SDT DU configuration that instructs the UE 102 to replace the first SDT DU configuration with the second SDT DU configuration. In such an embodiment, the UE 102 can replace the first SDT DU configuration with the second SDT DU configuration in response to the setup indication.

[0101] If the CU-CP 172A and / or the DU 174 support the delta configuration, the CU-CP 172A may not send a CU-to-DU message to obtain the second SDT DU configuration from the DU 174 (428). The DU 174 retains the first SDT DU configuration unless the conditions for releasing the first SDT configuration are met. Alternatively, the CU-CP 172A may 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 such a case, the CU-CP 172A may not include the SDT DU configuration and / or the SDT CU configuration in the RRC release message, causing the UE 102 to continue using the first SDT CU configuration and / or the first SDT DU configuration. In some embodiments, CU-CP 172A may not include a release indication in the RRC release message to configure UE 102 to continue using the first SDT DU configuration and / or the first SDT CU configuration. The release indication instructs UE 102 to release the previously received SDT DU configuration and / or SDT CU configuration. If CU-CP 172A includes a release indication in the RRC release message, UE 102 releases the first SDT CU configuration and / or the first SDT DU configuration in response to the release indication.

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

[0103] 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 the second non-SDT DU configuration. In response to the third CU-to-DU message, 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 some embodiments, when the RRC release message instructs the UE 102 to transition to an inactive state (i.e., RRC_IDLE), the UE 102 releases the non-SDT configurations (e.g., the first non-SDT DU configuration, the first non-SDT CU configuration, the second non-SDT DU configuration, and / or the second non-SDT CU configuration described in FIG. 3) and at least one SDT configuration (e.g., the SDT DU configuration and / or the SDT CU configuration described in FIG. 3).

[0104] 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 procedure 394. Examples and implementations for events 320, 321, 322, 323, 324, 326, 328, 330, 332, and 334 are applicable to events 420, 421, 422, 423, 424, 426, 428, 430, 432, and 434, respectively. After terminating the SDT, if the UE 102 is still configured with an SDT configuration, the UE 102 may perform another SDT procedure with the base station 104 (493), similar to procedure 492. After completing procedure 493, the base station 104 may perform an SDT complete procedure 495 with the UE 102, similar to procedure 494.

[0105] In some embodiments, the CU-CP 172A may not request the DU 174 to provide an SDT DU configuration for transitioning an SDT-configured inactive UE 102. In such cases, events 428 and 430 may be omitted. In such cases, the CU-CP 172A does not include the SDT DU configuration in the RRC release message. Instead, the CU-CP 172A may independently generate the SDT DU configuration and include it in the RRC release message.

[0106] In some embodiments, the DU 174 does not include an SDT DU configuration in the second DU-to-CU message, for example, because the UE 102 does not or does not support CG-SDT, because the DU 174 does or does not support CG-SDT, or because the DU 174 does or 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 may include an SDT DU configuration as described above. In some embodiments, the DU 174 does not include a CG-SDT configuration in the SDT DU configuration of the second DU-to-CU message, for example, because the UE 102 does or does not support CG-SDT, because the DU 174 does or does not support CG-SDT, or because the DU 174 does or 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 may include at least one CG-SDT configuration in the SDT DU configuration as described above.

[0107] In some embodiments, if the UE 102 supports CG-SDT and / or the DU 174 supports CG-SDT, the CU-CP 172A can request the DU 174 to provide an SDT DU configuration as described above. If 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 the UE capabilities (e.g., a UE-NR-Capability IE) of the UE 102 from the UE 102, the CN 110 (e.g., the MME 114 or the AMF 164), or the base station 106 either before the UE 102 starts SDT, while the UE is operating in an inactive state (402), while the UE is performing SDT (e.g., in the UE Context Setup Request message of event 408 or the CU-to-DU message of event 428), or while the UE is operating in a connected state as described with respect to FIG. The UE capabilities indicate whether the UE 102 supports CG-SDT. Thus, the CU-CP 172A can determine whether the UE supports CG-SDT according to the UE capabilities. In some embodiments, the CU-CP 172A can receive a DU-to-CU message from the DU 174 indicating whether the DU 174 supports CG-SDT. The DU-to-CU message can be a second DU-to-CU message, a message of event 308 or 316, or a non-UE-related message (e.g., a non-UE-related F1AP message defined in 3GPP specification 38.473).

[0108] In some embodiments, the DU 174 may determine whether to provide the SDT DU configuration of the UE 102 to the CU-CP 172A based on whether the UE 102 supports CG-SDT. In addition to whether the UE 102 supports CG-SDT, the DU 174 may further determine whether to provide the SDT DU configuration of the UE 102 to the CU-CP 172A based on whether the DU 174 supports CG-SDT. If the UE 102 supports CG-SDT and / or the DU 174 supports or enables CG-SDT, the DU 174 provides the SDT DU configuration of the UE 102 to the CU-CP 172A, as described above. If the UE 102 does not support CG-SDT or the DU 174 does not support CG-SDT, the DU 174 does not provide the SDT DU configuration of the UE 102 (e.g., the DU 174 does not include the SDT DU configuration in the second DU-to-CU message). For example, while the UE 102 operates in a connected state or an inactive state, the DU 174 can receive the UE capabilities from the CU-CP 172A. Thus, the DU 174 can determine whether the UE 102 supports CG-SDT according to the UE capabilities. In some embodiments, the DU 174 can send a DU-to-CU message to the CU-CP 172A to indicate whether the DU 174 supports CG-SDT, as described above.

[0109] 5A, scenario 500A illustrates small data transmission and transition from SDT to non-SDT. In scenario 500A, base station 104 includes CU 172 and DU 174, CU 172 includes CU-CP 172A and CU-UP 172B, and UE 102 initially operates in an inactive state with SDT configured (502), similar to event 402. UE 102 then performs an SDT procedure 592 with base station 104, similar to event 492.

[0110] During the small data transmission procedure (592), the CU-CP 172A can determine whether to transition the UE 102 to a connected state, for example, based on the UL data activity or DL data activity of the UE 102. In some embodiments, the UE 102 can transmit a non-SDT indication message 503 to the DU 174 to indicate that UL data is available or to request a transition to a connected state. In some embodiments, the UE 102 can transmit the non-SDT indication message to the DU 174 on radio resources configured in a CG configuration for SDT (or a CG-SDT configuration) (503). In other embodiments, the UE 102 can receive an uplink grant on the PDCCH from the DU 174 using the C-RNTI and can transmit the non-SDT indication message to the DU 174 on radio resources configured in the uplink grant (503). The DU 174 then transmits a UL RRC message transfer message including the non-SDT indication message to the CU-CP 172A (505). The CU-CP 172A may decide to transition the UE 102 to the connected state in response to or based on the non-SDT indication message. In another embodiment, the CU-CP 172B receives DL data from the CN 110 and, in response, sends a DL data notification (e.g., a DL data notification message) to the CU-CP 172A (507) to indicate that DL data is available for transmission. The CU-CP 172A may decide to transition the UE 102 to the connected state in response to or based on the DL data notification. In yet another embodiment, the CU-CP 172A may decide to transition the UE 102 to the connected state based on measurement results received from the UE 102. In yet another embodiment, the CU-CP 172A may receive DL data (e.g., NAS message(s)) from the CN 110 and, in response to receiving the DL data, decide to transition the UE 102 to the connected state.

[0111] In some embodiments, the non-SDT indication message may be an RRC message (eg, a UEAssistanceInformation message or a new RRC message).

[0112] In some embodiments, the UL data and / or DL data are associated with radio bearer(s) (e.g., SRB(s) and / or DRB(s)). For example, the UL data may include RRC message(s) or NAS message(s) associated with the SRB(s). In another example, the UL data includes IP packet(s) associated with the DRB(s). In some embodiments, the UE 102 may include ID(s) of the radio bearer(s) in the non-SDT indication message. Thus, the CU-CP 172A may determine whether to transition the UE 102 to the connected state based on the ID(s). For example, if the radio bearer(s) identified by the ID(s) do not conform to SDT, the CU-CP 172A may determine to transition the UE 102 to the connected state. Otherwise, the CU-CP 172A may determine not to transition the UE 102 to the connected state. In some embodiments, the UE 102 may include data volume information of the UL data in the non-SDT indication message. Therefore, the CU-CP 172A may determine whether to transition the UE 102 to the connected state based on the data volume information. In one embodiment, the data volume information includes a total data volume of the UL data, which may be quantized or rounded to a value that can be indicated in the data volume information. In another embodiment, the data volume information includes a data volume for each radio bearer(s), which may be quantized or rounded to a value that can be indicated in the data volume information. For example, if the total data volume exceeds a predetermined threshold, the CU-CP 172A may determine to transition the UE 102 to the connected state. Otherwise, the CU-CP 172A may determine not to transition the UE 102 to the connected state. In another example, if the data volume of a specific radio bearer exceeds a predetermined threshold, the CU-CP 172A may determine to transition the UE 102 to the connected state. Otherwise, the CU-CP 172A may determine not to transition the UE 102 to the connected state. In yet another example, if the total amount of data exceeds a predetermined threshold and the amount of data for a particular radio bearer exceeds another predetermined threshold, the CU-CP 172A may decide to transition the UE 102 to a connected state.Otherwise, the CU-CP 172A may decide not to transition the UE 102 to the connected state.

[0113] In response to or after determining to transition the UE 102 to the connected state, the CU-CP 172A sends a UE context request message (e.g., a UE context setup request message or a UE context modification request message) to the DU 174 (506). In response, the DU 174 sends a UE context response message (e.g., a UE context setup response message or a UE context modification response message) to the CU-CP 172A (508). In some embodiments, the DU 174 can include a non-SDT DU configuration (i.e., a first non-SDT DU configuration) in the UE context response message. After receiving the UE context response message, the CU-CP 172A sends a CU-to-DU message including an RRC resume message (e.g., an RRCResume message or an RRCConnectionResume message) to the DU 174 (510). The DU 174 then sends the RRC resume message to the UE 102 (512). In some embodiments, the DU 174 may transmit one or more PDUs including an RRC resume message to the UE 102 (512). The PDU(s) may be MAC PDU(s) or RLC PDU(s). In some embodiments, the CU-to-DU message may be a DL RRC message transfer message or a UE context modification request message. In the case of a UE context modification request message, the DU 174 may transmit a UE context modification response message to the CU-CP 172A in response. In response to the RRC resume message, the UE 102 transitions to a connected state (513) and transmits an RRC resume complete message (e.g., an RRCResumeComplete message or an RRCConnectionResumeComplete message) to the DU 174 (514). If the UE context response message includes a non-SDT DU configuration, the CU-CP 172A includes the non-SDT DU configuration in the RRC resume message.The DU 174 sends a DU-to-CU message including an RRC resume complete message to the CU-CP 172A (516). After deciding to transition the UE 102 to the connected state, the CU-CP 172A can send a bearer context request message (e.g., a bearer context setup request message or a bearer context modification request message) to the CU-UP 172B (517) to instruct the CU-UP 172B to resume all radio bearer(s) that were suspended for the UE 102. In response, the CU-UP 172B resumes all radio bearer(s) that were suspended for the UE 102 and sends a bearer context response message (e.g., a bearer context setup response message or a bearer context modification response message) to the CU CP 172A (519). In some embodiments, the CU-CP 172A can send (517) a bearer context request message after sending (506) a UE context request message, after receiving (508) a UE context response message, after sending (510) a CU-to-DU message, or after receiving (516) a DU-to-CU message.

[0114] In some embodiments, the CU-CP 172A can include an indication in the UE context request message instructing the DU 174 to generate a non-SDT configuration, and the DU 174 includes the first non-SDT DU configuration in the UE context response message in response to the indication. In yet other embodiments, the CU-CP 172A stores the non-SDT DU configuration (i.e., the second non-SDT DU configuration) that the DU (e.g., the DU 174 or another DU or base station) used to communicate with the UE 102. The UE 102 can also store the second non-SDT DU configuration. In such a case, the CU-CP 172A can include the second non-SDT DU configuration in the UE context request message, and the DU 174 can include the first non-SDT DU configuration in the UE context response message in response to receiving the second non-SDT DU configuration. In some embodiments, the first non-SDT DU configuration extends or replaces the second non-SDT DU configuration. Examples and implementations of the first and second non-SDT DU configurations may be the same as any of the non-SDT DU configurations described above. In some implementations, instead of including the first non-SDT DU configuration in the UE context response message, the DU 174 can send an additional DU-to-CU message (e.g., a UE context modification request message) to the CU-CP 172A that includes the first non-SDT DU configuration.

[0115] After transitioning to the connected state, the UE 102 communicates UL data and / or DL data with the CU-CP 172A and / or CU-UP 172B via the DU 174 (518). The UL data may include UL data that triggers the UE 102 to send a non-SDT indication message. The UL data may also include new UL data available for transmission. The DL data may include DL data received from the CN 110 as described above. The DL data may also include new DL data received from the CN 110. If the RRC resumption message includes the first non-SDT DU configuration, the UE 102 communicates with the DU 174 using the first non-SDT DU configuration (518). If the second non-SDT DU configuration has not been completely replaced by the first non-SDT DU configuration (i.e., the UE 102 has not released the second non-SDT DU configuration in response to the RRC resume message), the UE 102 may communicate (518) with the DU 174 using the configuration parameters of the second non-SDT DU configuration that are not extended by the first non-SDT DU configuration.

[0116] In some embodiments, the DU 174 may not provide the first non-SDT DU configuration to the CU-CP 172A in the UE context response message and the additional DU-to-CU message. In such a case, the RRC resume message does not include the first non-SDT configuration, and the UE 102 and the DU 174 communicate with each other using the second non-SDT DU configuration (518).

[0117] In some embodiments, the UE 102 releases the SDT configuration(s) (e.g., the SDT CU configuration, the SDT DU configuration, and / or the CG-SDT configuration(s)) in response to an RRC Resume message or in response to transitioning to a Connected state. In some embodiments, the base station 104 (e.g., the CU-CP 172A and / or the DU 174) releases the SDT configuration(s) in response to or after transitioning the UE 102 to a Connected state, receiving a CU-to-DU message (510), or sending an RRC Resume message (510, 512). In other embodiments, the base station 104 releases the SDT configuration(s) in response to or after receiving an acknowledgment (e.g., an RLC acknowledgment or an HARQ acknowledgment) of the PDU(s) containing the RRC Resume message. In yet another embodiment, the base station 104 (e.g., the CU-CP 172A and / or the DU 174) releases the SDT configuration(s) in response to or after communicating a UE context request message (506) or a UE context response message (508).

[0118] In some embodiments, the UE 102 retains the SDT configuration(s) (e.g., the SDT CU configuration, the SDT DU configuration, and / or the CG-SDT configuration(s)) in response to or after receiving an RRC Resume message or transitioning to the Connected state. In some embodiments, the UE 102 refrains from using the SDT configuration(s) to communicate with the base station 104 (e.g., to send an RRC Resume Complete message (514) and / or to communicate data (518)) while operating in the Connected state. In other embodiments, the UE 102 can use the SDT configuration(s) to communicate with the base station 104 (e.g., to send an RRC Resume Complete message (514) and / or data (518)) while operating in the Connected state. In some embodiments, the base station 104 retains the SDT configuration(s) in response to or after transitioning the UE 102 to the Connected state or sending an RRC Resume message. In some implementations, the base station 104 refrains from using the SDT configuration(s) to communicate (e.g., receive 514 an RRC resume complete message and / or communicate 518 data) with the UE 102 operating in a connected state. In other implementations, the base station 104 can use the SDT configuration(s) to communicate (e.g., receive 514 an RRC resume complete message and / or communicate 518 data) with the UE 102 operating in a connected state.

[0119] Subsequently, the base station 104 can perform a non-SDT configuration procedure 590 and an SDT configuration procedure 594 with the UE 102, similar to procedure 390 and procedure 394, respectively. The UE 102 transitions to an inactive state (536) in response to receiving the RRC release message in procedure 594. The base station 104 can then perform an SDT procedure 593 and an SDT completion procedure 595 with the UE 102, similar to procedure 492 and procedure 494, respectively.

[0120] 5B, scenario 500B is generally similar to scenario 500A, except that UE 102 initiates an RRC connection resumption procedure instead of a small data communication procedure 592. The differences between scenarios 500B and 500A are described below.

[0121] In response to initiating the RRC connection resumption procedure, the UE 102 sends an RRC Resume Request message to the DU 174 (542), which then sends an Initial UL RCC Message Transfer message including the RRC Resume Request message (e.g., an RRCResumeRequest message or an RRCConnectionResumeRequest message) to the CU-CP 172A (544). In response to receiving the RRC Resume message, the CU-CP 172A decides to transition the UE 102 to the Connected state. In response to or after deciding to transition the UE 102 to the Connected state, the CU-CP 172A transitions the UE 102 to the Connected state as described for scenario 500A.

[0122] In some embodiments, the UE 102 may generate a UL MAC PDU including the RRC resume request message and transmit 542 the UL MAC PDU to the DU 174. In some embodiments, the UE 102 may transmit 542 the UL MAC PDU to the DU 174 on radio resources configured in the CG configuration of the SDT. In other embodiments, the UE 102 may perform a random access procedure to transmit the UL MAC PDU, similar to event 404.

[0123] Referring now to Figure 6, scenario 600 illustrates SDT operation similar to scenario 400, except for events 607 and 609. Events 602, 604, 606, 608, 610, 612, 614, 615, 616, 618, 694, and 636 are similar to events 402, 404, 406, 408, 410, 412, 414, 415, 416, 418, 494, and 436. The examples and implementations of Figure 4 can be applied to Figure 6. Differences between Figures 4 and 6 are described below.

[0124] In scenario 600, UE 102 initially operates in an inactive state with an SDT configuration configured by base station 104 (602), as described above with respect to Figure 3 or Figure 4. In some implementations, the SDT configuration includes one or more CG-SDT configurations. In such a case, because base station 104 does not configure the CG-SDT configuration(s) for UE 102, UE 102 can discard the CG-SDT configuration(s), i.e., the CG-SDT configuration(s) are not valid.

[0125] In response to or after receiving the UL RRC message (606), the CU-CP 172A sends a UE context acquisition request message to the base station 104 (607). In response, the base station 104 sends a UE context acquisition request message to the CU-CP 172A (609). After receiving the UE context acquisition response message, the CU-CP 172A sends a UE context setup request message to the DU 174 (608) and receives a UE context setup response message from the DU 174 (610). The CU-CP 172A sends a bearer context setup request message to the CU-UP 172B (612) to request the CU-UP 172B to set up bearer context(s) for the SDT DRB(s) configured in the SDT configuration. In response, CU-UP 172B sets up bearer context(s) for the SDT DRB(s) and sends (614) a bearer context setup response message to CU-CP 172A to confirm that the bearer context(s) for the SDT DRB(s) have been set up.

[0126] In some embodiments, base station 104 can include an SDT configuration in the UE context acquisition request message. If the SDT configuration includes one or more CG-SDT configurations, base station 104 can exclude the CG-SDT configuration(s) from the SDT configuration. Alternatively, CU-CP 172A still includes the CG-SDT configuration(s) from the SDT configuration. In some embodiments, when CU-CP 172A receives the CG-SDT configuration(s), CU-CP 172A discards the CG-SDT configuration(s). In some embodiments, CU-CP 172A can discard the SDT configuration(s) if CU-CP 172A does not support delta configurations. If CU-CP 172A supports delta configuration, CU-CP 172A can take the SDT configuration (e.g., the first SDT configuration) into account when CU-CP 172A decides to transition the UE to an inactive state in SDT completion procedure 694, similar to procedure 494.

[0127] In other embodiments, CU-CP 172A refrains from including the SDT configuration in the UE context acquisition request message.

[0128] Next, some example methods that may be implemented in one or more RAN nodes (e.g., base station(s), DU(s), or CU(s)) to support data communication in an inactive state will be described with reference to Figures 7A-11.

[0129] FIG. 7A shows a method 700A that may be implemented / performed by a first RAN node (e.g., a base station 104, a CU 172 of the base station 104, or a CU-CP 172A of the base station 104) to manage an SDT of a UE (e.g., a UE 102).

[0130] Method 700A begins at block 702, where a first RAN node communicates with a UE using at least one configuration (e.g., events 312, 314, 318, 390, 320, 334, 394, 514, 518, 596, 598). At block 704, the first RAN node sends an RRC release message including an SDT configuration to the UE to stop communication with the UE (e.g., events 334, 434, 394, 494, 594, 595). At block 706, the first RAN node receives a UE context get request message (e.g., event 607) from a second RAN node (e.g., the base station 106, the CU 172 of the base station 106, or the CU-CP 172A of the base station 106) requesting a UE context for the UE. At block 708, the first RAN node sends a UE context get response message to the second RAN node, the message including at least one configuration and excluding the SDT configuration (e.g., event 609).

[0131] In some embodiments, the at least one configuration includes a plurality of configuration parameters. In some embodiments, the first RAN node communicates with the UE operating in a connected state at block 702. In some embodiments, while the UE is operating in a connected state, the first RAN node sends an RRC Reconfiguration message to the UE including some or all of the plurality of configuration parameters. In other embodiments, the first RAN node sends an RRC Resume message to the UE including some or all of the plurality of configuration parameters while the UE is operating in an inactive state. In some embodiments, the plurality of configuration parameters may be configuration parameters included in a CellGroupConfig IE.

[0132] 7B is a flow diagram of an example method 700B, which is similar to method 700A, except that method 700B includes blocks 705 and 709 instead of blocks 704 and 706. At block 705, the first RAN node sends an RRC release message to the UE, including the SDT CU configuration and the SDT DU configuration, to stop communication with the UE (e.g., events 334, 434, 394, 494, 594, 595). At block 709, the first RAN node sends a UE context get response message to the second RAN node, including the SDT CU configuration and excluding the SDT DU configuration (e.g., events 334, 434, 394, 494, 594, 595).

[0133] FIG. 8A shows a method 800A that may be implemented / performed by a first RAN node (e.g., a base station 106, a CU 172 of the base station 106, or a CU-CP 172A of the base station 106) for managing an SDT of a UE (e.g., a UE 102).

[0134] Method 800A begins at block 802, where a first RAN node receives an UL RRC message from a UE operating in an inactive state (e.g., events 404, 503, 542, 604). At block 804, in response to the UL RRC message (e.g., event 607), the first RAN node sends a UE context get request message to a second RAN node (e.g., the base station 104, the CU 172 of the base station 104, or the CU-CP 172A of the base station 104) to request a UE context for the UE. At block 806, the first RAN node receives a UE context get response message from the second RAN node, which includes an SDT configuration and a UE context for the UE (e.g., event 609). At block 808, the RAN node discards the SDT configuration and retains the UE context. At block 810, the RAN node communicates with the UE based on the UE context (e.g., events 512, 514, 518, 596, 598, 618, 694).

[0135] 8B is a flow diagram of an example method 800B, which is similar to method 800A, except that method 800B includes block 807 instead of block 806 and block 809 instead of block 808. At block 807, the first RAN node receives a UE context get response message from the second RAN node, which includes an SDT CU configuration, an SDT DU configuration, and a UE context for the UE (e.g., event 609). At block 809, the first RAN node retains the SDT CU configuration and the UE context and discards the SDT DU configuration.

[0136] FIG. 9 illustrates a method 900 that may be implemented / performed by a first RAN node (e.g., a base station 104, a CU 172, or a CU-CP 172A) to manage an SDT of a UE (e.g., a UE 102).

[0137] Method 900 begins at block 902, where a first RAN node sends an RRC release message including an SDT configuration to a UE to cease communication with the UE (e.g., events 332, 334, 432, 434, 394, 494, 594, 595). At block 904, the first RAN node communicates with the UE operating in an inactive state using the SDT configuration (e.g., events 404, 406, 418, 492, 420, 421, 432, 434, 494, 592, 594, 593, 594). At block 906, the first RAN node transitions the UE to a connected state (e.g., events 510, 512). At block 908, the first RAN node communicates with the UE operating in the connected state using at least one configuration (e.g., events 514, 516, 518). At block 910, the first RAN node decides to hand over the UE to a second RAN node (e.g., the base station 106, the CU 172 of the base station 106, or the CU-CP 172A of the base station 106). At block 912, in response to the decision, the RAN node sends handover preparation information to the second RAN node, the handover preparation information including at least one configuration and excluding the SDT configuration. At block 914, the RAN node receives a handover command message for the UE from the second RAN node. At block 916, the RAN sends the handover command to the UE.

[0138] In some embodiments, the second RAN node can generate a handover command message, which can be, or can include, for example, an RRC reconfiguration message. In some embodiments, the first RAN node sends a handover request message including handover preparation information to the second RAN node. In response, the first RAN node receives a handover request confirmation message from the second RAN node that includes the handover command message.

[0139] In some embodiments, the first RAN node transmits handover preparation information to the second RAN node via a CN (e.g., CN 110) and receives a handover command message from the second RAN node via the CN. For example, the first RAN node transmits a handover required message including the handover preparation information to the CN (e.g., CN 110), which then transmits a handover request message including the handover preparation information to the second RAN node. In response, the second RAN node transmits a handover request confirm message including the handover command message to the CN, which then transmits a handover command message (i.e., an interface message such as an X2 or Xn interface message) including the handover command message to the first RAN node.

[0140] FIG. 10 shows a method 1000 that may be implemented / performed by a first RAN node (e.g., a base station 106, a CU 172 of the base station 106, or a CU-CP 172A of the base station 106) for managing an SDT of a UE (e.g., a UE 102).

[0141] Method 1000 begins at block 1002, where a first RAN node receives handover preparation information from a second RAN node, the handover preparation information including at least one configuration of the UE and an SDT configuration. At block 1004, the RAN node sends a handover command for the UE to the second RAN node. At block 1006, the RAN node retains the at least one configuration and discards the SDT configuration. At block 1008, the RAN node performs a random access procedure with the UE. At block 1010, the RAN node receives a handover complete message from the UE.

[0142] In some embodiments, the first RAN node and the second RAN node of Figure 10 may be the second RAN node and the first RAN node, respectively, of Figure 9. The examples and embodiments of Figure 9 are applicable to Figure 10.

[0143] FIG. 11 illustrates a method 1100 that may be implemented by a first CU (eg, CU 172 or CU-CP 172A) to manage an SDT of a UE (eg, UE 102).

[0144] Method 1100 begins at block 1102, where a CU communicates with a UE. At block 1104, the first CU determines to send handover preparation information to a RAN node. At block 1106, the first CU determines whether the RAN node is a DU. If the CU determines that the RAN node is a DU, flow proceeds to block 1108. At block 1108, the first CU sends handover preparation information, excluding configuration (e.g., the SDT configuration described above), to the DU. In some embodiments, the first CU can send a CU-to-DU message including the handover preparation information to the DU. Otherwise, if the first CU determines that the RAN node is not a DU (e.g., the RAN node is a second CU or a base station), flow proceeds to block 1110. At block 1110, the first CU sends handover preparation information, including the configuration, to the second CU. The example and embodiment of sending handover preparation information of FIG. 9 can be applied to FIG. 11.

[0145] The following list of examples reflects various embodiments expressly contemplated by this disclosure.

[0146] Example 1. A method performed by a first radio access network (RAN) node for managing configuration information for small data transmission (SDT) operation, the method comprising: receiving a radio resource control (RRC) message from a user device (UE); receiving from a second RAN node an SDT configuration for use by the UE when the UE is operating in an RRC inactive state during a handover procedure from the second RAN node to a first RAN node; and communicating with the UE operating in the RRC inactive state after the handover procedure based on a UE context of the UE.

[0147] Example 2. The method of Example 1, wherein receiving the SDT configuration includes receiving a UE context response message including the SDT configuration.

[0148] Example 3. The method of Example 2, further comprising: sending a UE context request message to the second RAN node after receiving the RRC message and before receiving the UE context response message.

[0149] Example 4. The method of Example 2 or 3, wherein receiving the SDT configuration includes receiving a UE context response message including the SDT configuration and the UE context.

[0150] Example 5. The method according to any one of Examples 1 to 4, wherein the RRC message is an RRC resumption message.

[0151] Example 6. The method of any one of Examples 1 to 5, further comprising discarding at least a portion of the SDT configuration after receiving the SDT configuration.

[0152] Example 7. A method performed by a first radio access network (RAN) node for managing configuration information for small data transmission (SDT) operation includes receiving from a second RAN node an SDT configuration for use by the UE when the UE is operating in a radio resource control (RRC) inactive state during a handover procedure from the second RAN node to the first RAN node, discarding at least a portion of the SDT configuration, and communicating with the UE operating in the RRC inactive state after the handover procedure.

[0153] Example 8. The method of Example 7, further comprising: sending a message to the second RAN node requesting a UE context before receiving the SDT configuration from the second RAN node; receiving the SDT configuration comprises receiving a message including the SDT configuration and the UE context; and communicating with the UE operating in the RRC inactive state comprises communicating with the UE based on the UE context.

[0154] Example 9. The method of Example 8, wherein the discarding includes discarding the SDT configuration.

[0155] Example 10. The method of example 8, wherein the discarding includes discarding an SDT distributed unit (SDT DU) configuration and retaining an SDT central unit (SDT CU) configuration.

[0156] Example 11. The method according to any one of Examples 8 to 10, further comprising receiving an RRC message and uplink data from the UE operating in the RRC inactive state before sending the message requesting the UE context.

[0157] Example 12. The method of Example 7, wherein receiving the SDT configuration includes receiving handover preparation information from the second RAN node, the handover preparation information including a non-SDT configuration and the SDT configuration, and the method includes retaining the non-SDT configuration and discarding the SDT configuration.

[0158] Example 13. The method of Example 12, further comprising: after receiving the handover preparation information, sending a handover command for the UE to the second RAN node.

[0159] Example 14. The method of Example 12 or 13, further including: after sending the handover command, performing a random access procedure with the UE; and receiving a handover complete message from the UE.

[0160] Example 15. The method according to any one of Examples 12 to 14, wherein receiving the handover preparation information is performed via a core network (CN).

[0161] Example 16. The method according to any one of Examples 7 to 15, wherein the first RAN node is a target base station of the handover procedure, and the second RAN node is a source base station of the handover procedure.

[0162] Example 17. The method according to any one of Examples 7 to 15, wherein the first RAN node is a central unit (CU) of a distributed base station that is a target base station in the handover procedure, the second RAN node is a source base station of the handover procedure, and communication with the UE is performed via a distributed unit (DU) of the distributed base station.

[0163] Example 18. A method for managing configuration information for small data transmission (SDT) operation performed by a first radio access network (RAN) node includes: communicating with a user device (UE) operating in a radio resource control (RRC) inactive state using an SDT configuration; transitioning the UE from the RRC inactive state to an RRC connected state; communicating with the UE operating in the RRC connected state using a non-SDT configuration; determining to handover the UE to a second RAN node; and in response to the determining, transmitting handover preparation information to the second RAN node, the handover preparation information excluding the SDT configuration.

[0164] Example 19. The method of Example 18, wherein the handover preparation information includes the non-SDT configuration.

[0165] Example 20. The method of Example 18 or 19, further comprising: before communicating with the UE operating in the RRC inactive state, sending an RRC release message including the SDT configuration to the UE.

[0166] Example 21. The method according to any one of Examples 18 to 20, wherein transitioning the UE to the RRC connected state includes sending an RRC resume message to the UE.

[0167] Example 22. The method according to any one of Examples 18 to 21, including receiving a handover command from the second RAN node to the UE after sending the handover preparation information to the second RAN node, and sending the handover command to the UE.

[0168] Example 23. The method according to any one of Examples 18 to 22, wherein transmitting the handover preparation information to the second RAN node includes transmitting a handover request message including the handover preparation information to the second RAN node.

[0169] Example 24. The method according to any one of Examples 18 to 23, wherein the sending of the handover preparation information to the second RAN node is performed via a core network (CN).

[0170] Example 25. The method according to any one of Examples 18 to 24, wherein the first RAN node is a source base station in a handover procedure, and the second RAN node is a target base station in the handover procedure.

[0171] Example 26. The method described in any one of Examples 18 to 24, wherein the first RAN node is a central unit (CU) of a distributed base station that is a source base station in a handover procedure, the second RAN node is a target base station in the handover procedure, and communication with the UE operating in the RRC inactive state and communication with the UE operating in the RRC connected state are performed via a distributed unit (DU) of the distributed base station.

[0172] Example 27. A first radio access network (RAN) node comprising one or more processors and configured to perform the method of any one of Examples 1-26.

[0173] Example 28. A method for managing configuration information, performed by a central unit (CU) of a distributed base station in a radio access network (RAN), comprising communicating with a user device (UE) and sending handover preparation information to a RAN node, wherein (i) if the RAN node is another base station or another central unit (CU), the handover preparation information includes a configuration for the UE to use when communicating with the RAN, and ii) if the RAN node is a distributed unit (DU), the handover preparation information excludes the configuration.

[0174] Example 29. The method of Example 28, wherein the RAN node is another base station or another CU, and the handover preparation information includes the configuration.

[0175] Example 30. The method of Example 28, wherein the RAN node is a DU and the handover preparation information excludes the configuration.

[0176] Example 31. The method according to any one of Examples 28 to 30, wherein the configuration is a small data transmission (SDT) configuration used by the UE when the UE operates in a radio resource control (RRC) inactive state.

[0177] Example 32. The method according to any one of Examples 28 to 31, wherein sending the handover preparation information to the RAN node includes sending a handover request message including the handover preparation information to the RAN node.

[0178] Example 33. The method according to any one of Examples 28 to 32, wherein the sending of handover preparation information to the RAN node is performed via a core network (CN).

[0179] Example 34. A central unit (CU) of a distributed base station, the CU having one or more processors and configured to execute the method described in any one of Examples 28 to 33.

[0180] The following explanations may be applied to the above explanations.

[0181] Generally speaking, a description of one of the above figures is also applicable to the other of the above figures. In some embodiments, "message" is used and can be replaced with "information element (IE)" or vice versa. In some embodiments, "IE" is used and can be replaced with "field" or vice versa. In some embodiments, "configuration" can be replaced by "configurations" or "configuration parameters" or vice versa. In some embodiments, "small data transmission" can be replaced with "early data transmission (EDT)" and "SDT" can be replaced with "EDT" or vice versa. In some embodiments, "small data transmission" can be replaced with "small data communication" or vice versa. In some embodiments, "stop" can be replaced with "pause".

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

[0183] Certain embodiments are described in this disclosure as including logic, or several components or modules. The modules can be software modules (e.g., code or machine-readable instructions stored on a 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 may include dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor such as a field programmable gate array (FPGA) or application-specific integrated circuit (ASIC), or a digital signal processor (DSP)) to perform certain operations. A hardware module may also include programmable logic or circuitry (e.g., contained 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, permanently configured circuitry or in temporarily configured circuitry (e.g., configured by software) may involve cost and time considerations.

[0184] If implemented in software, the techniques may be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software may be executable by one or more general-purpose processors or one or more special-purpose processors.

Claims

1. 1. A method performed by a first radio access network (RAN) node for managing configuration information for small data transmission (SDT) operations, the method comprising: communicating with a user device (UE) operating in a radio resource control (RRC) inactive state using an SDT configuration; transitioning the UE from the RRC inactive state to an RRC connected state; communicating with the UE operating in the RRC connected state using a non-SDT configuration; determining to handover the UE to a second RAN node; In response to determining, transmitting handover preparation information to the second RAN node, the handover preparation information excluding the SDT configuration.

2. The method of claim 1 , wherein the handover preparation information includes the non-SDT configuration.

3. The method of claim 1 , further comprising: sending an RRC release message including the SDT configuration to the UE before communicating with the UE operating in the RRC inactive state.

4. The method of claim 1 , wherein transitioning the UE to the RRC connected state includes sending an RRC resume message to the UE.

5. after transmitting the handover preparation information to the second RAN node; receiving a handover command for the UE from the second RAN node; The method of claim 1 , further comprising: transmitting the handover command to the UE.

6. 2. The method of claim 1, wherein transmitting the handover preparation information to the second RAN node comprises transmitting a handover request message including the handover preparation information to the second RAN node.

7. The method of claim 1 , wherein the transmission of the handover preparation information to the second RAN node is performed via a Core Network (CN).

8. the first RAN node is a source base station in a handover procedure; The method of claim 1 , wherein the second RAN node is a target base station for the handover procedure.

9. the first RAN node is a central unit (CU) of a distributed base station that is a source base station in a handover procedure; the second RAN node is a target base station in a handover procedure; 2. The method of claim 1, wherein communicating with the UE operating in the RRC inactive state and communicating with the UE operating in the RRC connected state is performed via a distributed unit (DU) of the distributed base station.

10. A first Radio Access Network (RAN) node comprising one or more processors and configured to perform the method of any one of claims 1 to 9.

Images