Small data communication management

Abstract

A method for transferring uplink data including control or non-control plane information to a central unit (CU) is implemented by a distributed unit (DU) of a base station, the method including receiving uplink data from an inactive user equipment (UE) via a logical channel, determining whether to transmit the uplink data via a transport network layer protocol stack or in an uplink radio resource control (RRC) message transfer message based on the logical channel, and transmitting the uplink data to the CU based on the determining.

Description

[Technical field]

[0001] The present disclosure relates generally to wireless communications, and more specifically to communication of uplink and / or downlink data in a user equipment (UE) and a distributed unit (DU) when the UE operates in an inactive or idle state associated with a protocol for controlling radio resources. [Background technology]

[0002] This background description is provided for the purpose of generally presenting the context of the present disclosure. To the extent that the work of the currently named inventors is described as an illustrative aspect in this background section, and aspects 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] Generally speaking, a base station operating in a cellular radio access network (RAN) communicates with a user equipment (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 forwarding services to a data forwarding packet data convergence protocol (PDCP) sublayer. A radio resource control (RRC) sublayer is disposed above the PDCP sublayer.

[0004] The RRC sublayer specifies 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 allow the UE to transition back to the RRC_CONNECTED state more quickly using RAN level base station coordination and RAN level paging procedures. In some cases, a UE in the RRC_INACTIVE state has only one relatively small packet to transmit. For such situations, 3GPP describes a Small Data Transmission (SDT) procedure that allows 5G NR to support data transmission for 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 if uplink data waiting for transmission across all SDT-enabled radio bearers is less than a configured amount, downlink (DL) reference signal received power (RSRP) is above a configured threshold, and valid SDT resources are available. The SDT procedure can be initiated by the UE either with a transmission over a random access channel (RACH), i.e., random access SDT (RA-SDT), or with a transmission over 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 transmit an initial transmission including data in the payload of message 3 (MSG3) of the four-step random access procedure, or message A (MSGA) of the two-step random access procedure. The network can then schedule subsequent uplink and / or downlink transmissions using dynamic uplink grants and downlink allocations, respectively, after completion of the random access procedure.

[0006] CG-SDT can only start with a valid uplink (UL) timing alignment. The UE maintains UL timing alignment based on the SDT-specific timing alignment timer configured by the network and the DL RSRP of the configured number of highest-ranked SSBs. When the SDT-specific timing 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 schedule subsequent uplink transmissions using dynamic grants or at future CG resource occasions. During CG-SDT, downlink transmissions are scheduled using dynamic allocation. The UE can start subsequent uplink transmissions only after receiving confirmation of the initial uplink transmission from the network.

[0007] In some scenarios, a UE may connect to a 5G NR radio access network (NG-RAN) that includes base stations, each of which has a central unit (CU) and at least one distributed unit (DU). However, it is not clear how a base station including a CU and a DU should perform SDT with the UE. Summary of the Invention

[0008] According to certain techniques of the present disclosure, a base station may decide to transition a UE that has been communicating with the base station in SDT operation from an inactive state to a connected state (i.e., to enable non-SDT communication). The base station may decide to transition the UE to the connected state based on a request or notification from the UE (e.g., an indication that the UE has non-SDT uplink data available for transmission) or when the base station receives non-SDT downlink data, for example, from a core network.

[0009] Upon deciding to transition the UE in this manner, the base station can perform a UE context procedure to obtain a non-SDT configuration for the UE. For example, the CU of the distributed base station can send a UE context request message to the DU that was communicating with the UE, and the DU can respond by sending a UE context response message including the non-SDT DU configuration to the CU. The CU can then send a message including the non-SDT DU configuration and the non-SDT CU configuration to the UE via the DU (e.g., the DU transfers the non-SDT configuration in an RRC resume message).

[0010] According to another technique of the present disclosure, the CU of the distributed base station may process an information element of an interface message from a DU (i.e., a message from a DU to a CU) based on an SRB identity in the interface message to obtain an RRC message. In particular, if the SRB identity is zero, the CU may determine that the octet string in the information element is a UL-CCCH message and extract the RRC message from the UL-CCCH message. However, if the SRB identity is not zero (e.g., is 1 or 2), the CU may determine that the octet string is a PDCP PDU. In this latter case, the CU may process (e.g., decode a portion of) the PDCP PDU to obtain a UL-DCCH message and extract the RRC message from the UL-DCCH message.

[0011] According to another technique of the present disclosure, the DU of the distributed base station can determine how to forward the UL data packet to the CU based on the logical channel on which the DU receives the UL data packet from the UE and / or based on whether the DU receives the UL data packet via a configured grant radio resource. For example, the DU can use both of these factors to determine whether to send the UL data packet in a (non-initial) UL RRC message transfer message or in an initial UL RRC message transfer message via the transport network layer protocol stack.

[0012] As used herein, and unless a specific meaning is clear from the context of use, the term "data" or "data packet" may refer to signaling, i.e., control plane information at a protocol layer that controls radio resources (e.g., RRC), controls mobility management (MM), or controls session management (SM), or may refer to non-signaling, i.e., non-control plane information at a protocol layer above a layer of protocols for controlling radio resources (e.g., RRC), above a layer of protocols for controlling MM, above a layer of protocols for controlling SM, and / or above a layer of protocols for 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, for example, Internet of Things (IoT) data, Ethernet traffic data, Internet traffic data, or Short Message Service (SMS) messages, etc. Additionally, the UE, in some implementations, applies the SDT techniques only if the size of the data is below a certain (e.g., configured) 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 the existing configuration).

[0013] In some examples, a method for transferring uplink data including control plane information or non-control plane information to a CU is implemented by a DU of a base station, the method including receiving uplink data from an inactive UE via a logical channel, determining whether to transmit the uplink data via a transport network layer protocol stack or in an uplink RRC message transfer message based on the logical channel, and transmitting the uplink data to the CU based on the determining.

[0014] In another example, a method for obtaining an RRC message from an interface message is implemented by a CU of a base station, the method including: receiving, from a DU of the base station, a DU-to-CU message including an SRB identity and an octet string, determining whether the octet string is a PDCP PDU message or a UL-CCCH message based on the SRB identifier, and processing the PDCP PDU or the UL-CCCH to obtain the RRC message based on the determining.

[0015] In another example, a method for transferring uplink data including control plane information or non-control plane information to a CU is implemented by a DU of a base station, the method including: receiving uplink data from a UE in an inactive state via a radio resource; determining whether to transmit the uplink data in an initial uplink RRC message transfer message or a non-initial uplink RRC message transfer message based on whether the radio resource is a configuration grant radio resource; and transmitting the uplink data to the CU according to the determining.

[0016] In another example, a RAN node includes processing hardware and is configured to perform any one of the example methods described above. [Brief description of the drawings]

[0017] [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 the techniques of the present disclosure. [Figure 1B] FIG. 1B is a block diagram of an exemplary base station in which a centralized unit (CU) and a distributed unit (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]FIG. 1B is a block diagram of an example protocol stack according to which the UE of FIG. 1A communicates with the CU and DU. [Diagram 3] FIG. 11 is a messaging diagram of an example procedure for obtaining a non-SDT configuration for communicating data packets between a UE and a distributed base station when a radio connection between the UE and the base station is active, and an example procedure for obtaining an SDT configuration for communicating data packets between the UE and the distributed base station when a radio connection between the UE and the base station is inactive. [Figure 4] A messaging diagram of an example procedure for communicating data packets between a UE and a distributed base station when a radio connection between the UE and the base station is inactive. [Diagram 5] A messaging diagram of an example scenario in which a distributed base station transitions a UE that is in an inactive state and is performing small data communication with the base station to a connected state. [Figure 6] 1B for processing information elements of an interface message to obtain an RRC message. FIG. 1C is a flow diagram of an example method that may be implemented in the CU or CU-CP of FIG. [Figure 7] 1B is a flow diagram of an example method that may be implemented in the DU of FIG. 1B for forwarding UL data packets to a CU. [Figure 8] FIG. 1B is a flow diagram of an exemplary method that can be implemented in the base station of FIG. 1A (e.g., the CU or DU of FIG. 1B) for transitioning a UE that is in an inactive state and is performing small data communication with the base station to a connected state. [Figure 9] FIG. 1B is a flow diagram of an exemplary method that can be implemented in the base station of FIG. 1A (e.g., the CU or DU of FIG. 1B) for transitioning a UE that is in an inactive state and is performing small data communication with the base station to a connected state. [Figure 10] FIG. 1B is a flow diagram of an exemplary method that can be implemented in the base station of FIG. 1A (e.g., the CU or DU of FIG. 1B) for transitioning a UE that is in an inactive state and is performing small data communication with the base station to a connected state. [Figure 11]1B is a flow diagram of an example method that may be implemented in the UE of FIG. 1A for transitioning the UE from an inactive state to a connected state in which the UE is performing small data communication with a base station. [Figure 12] 1B for transferring UL data packets to the CU of FIG. 1B may be implemented by the DU of FIG. 1B is a flow diagram of another exemplary method. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] As described in more detail below, a user equipment (UE) and / or a network node of a radio access network (RAN) can use the techniques of this disclosure to transition a UE between states of protocols for managing small data communications and controlling radio resources between the UE and the RAN. As used in this disclosure, 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).

[0019] 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 core network (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 in another example.

[0020] The base station 104 covers the cell 124, and the base station 106 covers the 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 Notification 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 may be connected to the CN 110 via an interface (e.g., an S1 interface or an NG interface). The base stations 104 and 106 may also be interconnected via an interface (e.g., an X2 interface or an Xn interface) for interconnecting NG RAN nodes.

[0021] 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 audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162, an Access and Mobility Management Function (AMF) 164, and / or a Session Management Function (SMF) 166. Generally speaking, the UPF 162 is configured to forward user plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0022] 1A, base station 104 supports cell 124 and base station 106 supports cell 126. Cells 124 and 126 may overlap, so 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.

[0023] The CN 110 may also communicatively connect the UE 102 to an IMS network 170 via the RAN 105. The IMS network 170 may provide various IMS services to the UE 102, such as IMS short messages, IMS Unstructured Supplementary Service Data (USSD), IMS Value Added Service Data, IMS Supplementary Service Data, IMS voice calls, and IMS video calls. To this end, entities (e.g., a server or a group of servers) operating in the IMS network 170 support packet exchanges with the UE. The packets may carry signaling (such as Session Initiation Protocol (SIP) messages, IP messages, or other suitable messages) and data ("or media"), such as voice or video.

[0024] 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. As described below, the UE 102, in some implementations, applies the techniques of this disclosure only if the size of the data (e.g., UL data) is below a certain threshold.

[0025] In an exemplary scenario described below, the UE 102 transitions to an RRC_INACTIVE state or an RRC_IDLE state, selects a 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 uplink transmission in the RRC_INACTIVE state or the RRC_IDLE state, the UE 102 can apply one or more security functions to an uplink (UL) data packet, generate a first UL protocol data unit (PDU) including the secured packet, include a UL RRC message 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 implementations, 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).

[0026] 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, which in this case includes 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 an 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.

[0027] In some embodiments, the data is a Packet Data Convergence Protocol (PDCP) or SDAP UL Service Data Unit (SDU). The UE 102 applies a security function 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 a UL MAC PDU in these cases. In some embodiments, the UE 102 may include a UL RRC message in the UL MAC PDU. In other embodiments, the UE 102 may omit the UL RRC message from the UL MAC PDU. In this latter case, the UE 102 may omit the UE ID of the UE 102 from the UL MAC PDU that does not include the UL RRC message. In further embodiments, the UE 102 may include the UL PDCP PDU in a UL Radio Link Control (RLC) PDU and then include the UL RLC PDU in a UL MAC PDU. In some embodiments where the UL RRC message is included 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 a resumeMAC-I field as specified in 3GPP specification 38.331. In further embodiments, the UE may generate an integrity key (e.g., K RRCint The RRC MAC-I can be obtained from the UL RRC message having the COUNT (e.g., a 32-bit, 64-bit, or 128-bit value), BEARER (e.g., a 5-bit value), and DIRECTION (e.g., a 1-bit value), a key, an integrity protection algorithm, and parameters COUNT (e.g., a 32-bit, 64-bit, or 128-bit value), BEARER (e.g., a 5-bit value), and DIRECTION (e.g., a 1-bit value).

[0028] In further 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 an 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 a UL RRC message in a UL MAC PDU and transmits 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 an RRC MAC-I as described above.

[0029] 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.

[0030] More generally, the UE 102 may protect the data using at least one of encryption and 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.

[0031] In some scenarios and embodiments, the base station 106 may retrieve the UE ID of the UE 102 from the UL RRC message and identify the base station 104 as the destination of the data in the first UL PDU based on the determined UE ID. In such scenarios, the base station 106 may be referred to as an "anchor" base station that sent the UE 102 to an inactive state while retaining complete UE context information. In one exemplary embodiment, the base station 106 retrieves the first UL PDU from the second UL PDU and transmits the first UL PDU to the base station 104. The base station 104 then retrieves the secured packet 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 may 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. Then, the base station 104 retrieves data from the secured packet by using the at least one security key, and sends 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 to obtain the data by using the at least one security key (e.g., an encryption key and / or a decryption key). 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 the 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 sends 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 secure packet is both encrypted and integrity protected, the encrypted and integrity protected packet may include the encrypted packet along with the encrypted MAC-I. The base station 104 then 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.

[0032] In another embodiment, the base station 106 retrieves the secured packet from the first UL PDU. The base station 106 performs a UE context retrieval procedure with the base station 104 to obtain UE context information of the UE 102 from the base station 104. The base station 106 derives at least one security key from the UE context information. Then, the base station 106 retrieves data from the secured packet by using the at least one security key, and sends the data to the CN 110 (e.g., UPF 162) or an edge server. When the secured packet is an encrypted packet, the base station 106 decrypts the encrypted packet to obtain the data by using the at least one security key (e.g., an encryption key and / or a decryption key). 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 both encrypted and integrity protected, the encrypted and integrity protected packet may include the encrypted packet along with the encrypted MAC-I. The base station 106 in this case decrypts the encrypted packet and the encrypted MAC-I to obtain the data and the MAC-I. The base station 106 then determines whether the MAC-I is valid for the data. If the base station 106 determines that the MAC-I is valid, the base station 106 retrieves the data and forwards the data to the CN 110. However, if the base station 106 determines that the MAC-I is invalid, the base station 106 discards the packet.

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

[0034] Additionally, the RAN 105 may in some cases transmit data in the downlink (DL) direction to UEs 102 operating in the RRC_INACTIVE or RRC_IDLE states.

[0035] For example, when the base station 104 determines that data is available for downlink transmission to the UE 102 currently operating in an RRC_INACTIVE or RRC_IDLE state, the base station 104 may apply at least one security function to the data to generate a secured packet and generate a first DL PDU including the secured packet and 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 data. More specifically, when integrity protection is enabled, the base station 104 may generate a MAC-I for protecting the integrity of the data, so that the secured packet includes data and a MAC-I. When encryption is enabled, the base station 104 may encrypt the data to generate an encrypted packet, so that the secured packet is encrypted data. Furthermore, when both integrity protection and encryption are enabled, the base station 104 may generate a MAC-I for protecting the integrity of the data and encrypt the data together with the MAC-I to generate an encrypted packet and an encrypted MAC-I. The base station 104, in some implementations, generates a first DL PDU, such as a DL PDCP PDU, using the secured packet, includes the first DL PDU in a second DL PDU (e.g., a DL MAC PDU) associated with, for example, a MAC layer, and transmits the second DL PDU to the UE 102 without first transitioning the UE 102 from an RRC_INACTIVE state or an RRC_IDLE state to an RRC_CONNECTED state. In some implementations, the base station 104 includes the DL PDCP PDU in a DL RLC PDU, includes the DL RLC PDU in a DL MAC PDU, and transmits the DL MAC PDU to the UE 102 without first transitioning the UE 102 from an RRC_INACTIVE state or an RRC_IDLE state to an RRC_CONNECTED state.

[0036] In another embodiment, the base station 104 transmits the first DL PDU to the base station 106, which then generates a second 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 an RRC_INACTIVE or RRC_IDLE state to an 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.

[0037] In some implementations, the base station (i.e., base station 104 or 106) generates a downlink control information (DCI) and a cyclic redundancy check (CRC) scrambled with the ID of the UE 102 to transmit the second DL PDU generated by the base station. In some implementations, the ID of the UE 102 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 the 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 implementations, the base station may assign the ID of the UE 102 to the UE 102 in a random access response that the base station transmits in a random access procedure with the UE 102 before transmitting the DCI and the scrambled CRC. In a further embodiment, the base station may assign an ID for 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, for example, before transmitting the DCI and scrambled CRC while UE 102 is in the RRC_CONNECTED state.

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

[0039] 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. The processing hardware 130 in an exemplary embodiment includes a medium access control (MAC) controller 132 configured to perform random access procedures with one or more user devices, receive uplink MAC protocol data units (PDUs) for one or more user devices, and transmit downlink MAC PDUs to one or more user devices. The processing hardware 130 also includes a packet data convergence protocol (PDCP) controller 134 configured to transmit DL PDCP PDUs that allow the base station 104 to transmit data in the downlink direction according to DL PDCP PDUs in some scenarios, and receive UL PDCP PDUs that allow the base station 104 to receive data in the uplink direction according to UL PDCP PDUs in other scenarios. The processing hardware may further include an RRC controller 136 to implement procedures and messaging at the RRC sublayer of a protocol communication stack. The processing hardware 130 in the exemplary implementation includes an RRC inactivity controller 138 configured to manage uplink and / or downlink communications with one or more UEs operating in an RRC_INACTIVE or RRC_IDLE state. The base station 106 may include generally similar components. In particular, components 140, 142, 144, 146, and 148 of the base station 106 may be similar to components 130, 132, 134, 136, and 138, respectively.

[0040] 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 that stores machine-readable instructions executable by the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 150 in an exemplary embodiment includes an RRC inactivity controller 158 configured to manage uplink and / or downlink communications when the UE 102 operates in an RRC_INACTIVE state. The processing hardware 150 in an exemplary embodiment includes a medium access control (MAC) controller 152 configured to perform random access procedures with a base station, transmit uplink MAC protocol data units (PDUs) to the base station, and receive downlink MAC PDUs from the base station. The processing hardware 150 also includes a PDCP controller 154 configured to transmit DL PDCP PDUs that allow the base station 106 to transmit data in the downlink direction according to DL PDCP PDUs in some scenarios, and receive UL PDCP PDUs that allow the base station 106 to receive data in the uplink direction according to UL PDCP PDUs in other scenarios. The processing hardware may further include an RRC controller 156 for implementing procedures and messaging at the RRC sublayer of the protocol communications stack.

[0041] 1B illustrates an exemplary distributed or centralized implementation of any one or more of the base stations 104, 106. In this implementation, the base station 104, 106 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 that stores machine-readable instructions executable on 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 a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures. In further implementations, the CU 172 does not include an RLC controller.

[0042] 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.

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

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

[0045] The CU-CP 172A can be connected 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 be connected to multiple CU-CPs 172A via an E1 interface. The CU-CP 172A can be connected to one or more DUs 174 via an F1-C interface. The CU-UP 172B can be connected to one or more DUs 174 via an F1-U interface under the control of the same CU-CP 172A. In some embodiments, one DU 174 can be connected to multiple CU-UPs 172B under the control of the same CU-CP 172A. In such an embodiment, the connectivity between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using a bearer context management function.

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

[0047] In the example stack 200, the EUTRA physical layer (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 transmission services to a service data adaptation protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in FIG. 2A ). The UE 102, in some embodiments, 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.

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

[0049] 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 non-access stratum (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 in the NR PDCP sublayer 210 can be SDAP PDUs, IP packets, or Ethernet packets.

[0050] 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 hold all control and higher 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 a connection to 5GC, the NR PDCP 210 provides an SRB to the RRC 214, which provides a DRB to the SDAP 212, which provides an SRB to the RRC 214.

[0051] Next, some example scenarios involving some components of Figure 1A and transmitting data in an inactive or idle state will now be described with reference to Figures 3 and 4. To simplify the following description, the term "inactive state" will be used and may represent an RRC_INACTIVE state or an RRC_IDLE state, and the term "connected state" will be used and may represent an RRC_CONNECTED state.

[0052] 3, in a scenario 300, the base station 104 includes a central unit (CU) 172 and a distributed unit (DU) 174, where 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 DU configuration) (304), and communicates with the CU-CP 172A and / or the CU-UP 172B via the DU 174 using a CU configuration (i.e., a first non-SDT CU configuration) (304). While the UE communicates 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 DU configuration (i.e., non-SDT DU configuration) for the UE 102 to the CU-CP 172A (308). The CU-CP 172A generates an RRC reconfiguration message including a second non-SDT DU configuration and sends a first CU-to-DU message (e.g., 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., UL RRC message transfer message) including the RRC reconfiguration complete message to the CU-CP 172A (316).

[0053] After receiving the RRC reconfiguration message (312), the connected UE 102 communicates (318) with the DU 174 using the second non-SDT DU configuration and communicates with the CU-CP 172A and / or CU-UP 172B via the DU 174. If the RRC reconfiguration message does not include a CU configuration, the UE 102 communicates (318) with the CU-CP 172A and / or CU-UP 172B via the DU 174 using the first non-SDT CU configuration. If the RRC reconfiguration message includes a non-SDT CU configuration (i.e., a second non-SDT CU configuration), the UE 102 communicates (318) with the CU-CP 172A and / or CU-UP 172B via the DU 174 using the second non-SDT CU configuration. In some implementations, the second non-SDT CU configuration 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 a case, 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 implementations, 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 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 for 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 for 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.

[0054] 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 a case, the UE 102 and the DU 174 may communicate with each other using the second non-SDU DU configuration and also the 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 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 operates 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 are CellGroupConfig IEs.

[0055] 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.

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

[0057] After a particular data inactivity period, the CU-CP 172A may determine that the CU 172 and the UE 102 have not transmitted any data in the downlink or uplink direction, respectively, during the particular period (e.g., using any of the techniques described above for UE inactivity determination). In response to the determination, the CU-CP 172A may decide to transition the UE 102 to an inactive state with SDT configured. Alternatively, the CU-CP 172A may decide to immediately transition the UE 102 to an inactive state with SDT configured in response to determining that the UE 102 is in a data inactivity state, regardless of whether the CU 172 transmitted data in the downlink direction during any particular period.

[0058] In response to or after determining that UE 102 is in a data inactive state (for a particular period of time), or otherwise in response to deciding to transition UE 102 to an SDT configured inactive state, CU-CP 172A sends a modify bearer context request message to CP-CU 172B (324) to suspend data transmissions of UE 102. In response, CU-UP 172B suspends data transmissions of UE 102 and sends a modify bearer context response message to CU-CP 172A (326). Also, in response to or after determining that the UE 102 is in a data inactive state (for a particular period of time), or in response to otherwise determining to transition the UE 102 to an SDT-configured inactive state, the CU-CP 172A sends (328) a second CU-to-DU message (e.g., a UE context modification request message) to instruct the DU 174 to provide (i.e., request from the DU 174) an 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 (330) a second DU-to-CU message (e.g., a UE context modification response message) including the first SDT DU configuration to the CU-CP 172A. Instead, the DU 174 does not include the SDT DU configuration in the second DU-to-CU message, and after receiving the second CU-to-DU message (event 328) and / or after sending the second DU-to-CU message (event 330), the DU 174 instead sends another DU-to-CU message (e.g., a UE context modification request message) to the CU-CP 172A that includes the first SDT DU configuration.In some alternative embodiments, the CU-CP 172A may send a second CU-to-DU message and receive the second DU-to-CU message (or receive the alternative DU-to-CU message described above) before determining that the UE 102 is in a data inactive state. In other alternative embodiments, the CU-CP 172A may include an SDT request indication in the first CU-to-DU message of event 308, and the DU 174 includes the first SDT DU configuration in the first DU-to-CU message of event 310 in response to the SDT request indication.

[0059] 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 first SDT DU configuration and the first 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 or a UE context modification request message) including the RRC release message to the DU 174 (332). The DU 174 then sends an RRC release message to the UE 102 (334). The RRC release message instructs the UE 102 to transition to the 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 first 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 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.

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

[0061] 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 / or 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 configuration and retains a second portion of the first and / or second non-SDT DU configuration when the RRC release message instructs the UE to transition to an inactive state (i.e., RRC_INACTIVE).

[0062] In some embodiments, the CU-CP 172A does not include an indication instructing the DU 174 to retain the first SDT DU configuration in the message from the third CU to the DU, but the DU 174 nevertheless retains the first SDT DU configuration as described above. In another embodiment, the CU-CP 172A may include an indication instructing the DU 174 to retain the first SDT DU configuration in the message from the third CU to the DU, and the DU 174 retains the first SDT DU configuration in response to the indication. In this embodiment, when the DU 174 receives a UE context release command message for the UE 102 from the CU-CP 172A, excluding the indication, the DU 174 releases the first SDT DU configuration. In yet another embodiment, the CU-CP 172A does not include an indication instructing the DU 174 to release the first SDT DU configuration in the third CU-to-DU message, and the DU 174 holds the first SDT DU configuration in response to the third CU-to-DU message excluding the indication. In this embodiment, when the DU 174 receives a CU-to-DU message for the UE 102 including an indication (e.g., a UE context release command message or a UE context modification request message) from the CU-CP 172A, the DU 174 releases the first SDT DU configuration.

[0063] In some implementations, the first SDT CU configuration includes a DRB list (e.g., std-DRB list) including a list of DRB ID(s) indicating the ID(s) of the DRB(s) configured for the SDT. In some implementations, the first SDT CU configuration may include an SRB2 indication (e.g., sdt-SRB2 indication) indicating the SRB2 configured for the SDT. In some implementations, the first SDT CU configuration may include a compression protocol continue indication (e.g., sdt-DRB-ContinueROHC) indicating whether the PDCP entity of the DRB(s) configured for the SDT will continue during SDT operation (i.e., initial and / or subsequent SDT as described in FIG. 4). In some implementations, the SDT CU configuration may include a data volume threshold (e.g., sdt-DataVolumeThreshold) to determine whether the UE 102 can initiate the SDT.

[0064] In some embodiments, the first SDT DU configuration may include at least one common SDT configuration, at least one RA-SDT configuration, and / or at least one CG-SDT configuration for CG-SDT. For example, the at least one common SDT configuration may include a buffer status reporting (BSR) configuration and / or a power headroom reporting (PHR) configuration. In another example, the at least one RA-SDT configuration may include random access configuration parameters for a two-step and / or four-step random access procedure. In another example, the at least one CG-SDT configuration may include a configuration grant configuration for CG-SDT, a time alignment timer value for CG-SDT, and / or a timing advance validity threshold. The DU 174 configures a timing advance validity threshold for the UE 102 to determine whether the UE 102 can perform SDT using the configuration grant configuration for CG-SDT. According to the timing advance validity threshold, the UE 102 may 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 perform RA-SDT with the CU 172 via the DU 174, as described with respect to FIG.

[0065] If the DU 174 provides the CG-SDT configuration to the CU-CP 172A at event 330, the DU 174 retains at least the radio resources configured by the CG-SDT configuration while retaining the first SDT DU configuration. In some embodiments, the DU 174 releases the radio resources configured by the CG-SDT configuration when releasing the first SDT DU configuration or the CG-SDT configuration. If the DU 174 does not provide the CG-SDT configuration to the CU-CP 172A, the DU 174 releases all related signaling and user data transport resources for the UE 102 in response to a third CU-to-DU message. If the DU 174 provides the CG-SDT configuration to the CU-CP 172A, the DU 174 retains all related signaling and user data transport resources for the UE 102 in response to or after receiving a third CU-to-DU message.

[0066] If the first SDT DU configuration does not include a configuration for CG-SDT, the CU-CP 172A and / or the DU 174 only configures the RA-SDT for the UE 102. In such a case, the UE 102 can perform the RA-SDT with the CU 172 via the DU 174, as described in FIG.

[0067] In some embodiments, the CU-CP 172A may not request the DU 174 to provide an SDT DU configuration for transitioning the inactive state UE 102 with SDT configured. 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. Instead, the CU-CP 172A may generate the first SDT DU configuration by itself without requesting the DU 174 to provide the SDT DU configuration, and include the first SDT DU configuration in the RRC release message.

[0068] In some implementations, the DU 174 may not include the SDT DU configuration in the message from the second DU to the CU, for example, because the UE 102 does not or does not support CG-SDT, because the DU 174 does not or does not support CG-SDT, or because the DU 174 does not or does not support CG-SDT, or because the DU 174 does not or does not have radio resources available for CG-SDT. In such cases, the RRC release message does not include the SDT DU configuration. Otherwise, the DU 174 may include the first SDT DU configuration as described above. In some implementations, the DU 174 may not include the CG-SDT configuration in the first SDT DU configuration in the message from the second DU to the CU, for example, because the UE 102 does not or does not support CG-SDT, because the DU 174 does not or does not support CG-SDT, or because the DU 174 does not or does not support CG-SDT, or because the DU 174 does not or does not have radio resources available for CG-SDT. In such cases, the first SDT DU configuration does not include the CG-SDT configuration. Otherwise, the DU 174 may include at least one CG-SDT configuration in the first SDT DU configuration as described above.

[0069] 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., MME 114 or 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).

[0070] 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 first 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 first SDT DU configuration in a message from the second DU to the CU). While the UE operates in a connected or inactive state (302) before the event 302, the DU 174 can receive the UE capabilities from the CU-CP 172A. Thus, the DU 174 can determine whether the UE 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.

[0071] Referring now to FIG. 4, a scenario 400 illustrates a small data transmission. In the scenario 400, the base station 104 includes the CU 172 and the DU 174. The CU 172 includes the CU-CP 172A and the CU-UP 172B. In the scenario 400, the UE 102 initially operates in an inactive state with an SDT configured (402). In some embodiments or scenarios, prior to the events illustrated in FIG. 4, the UE 102 may transition from a connected state to an inactive state with an SDT configured, as described in FIG. 3 (i.e., event 402 may follow event 336). In other embodiments or scenarios, prior to the events illustrated in FIG. 4, the UE 102 may transition from an inactive state with no SDT configured to an inactive state with an SDT configured. For example, the UE 102 receives an RRC release message from a base station (e.g., the base station 104 or the base station 106) that transitions the UE 102 to an inactive state and does not include an SDT configuration. In this case, the UE 102 transitions to an inactive state with no SDT configured in response to the RRC release message. A UE 102 in an inactive state with either an SDT configured or not configured may perform a RAN Notification Domain (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 the first SDT CU configuration and / or the first SDT DU configuration, similar to the RRC release message of event 334.

[0072] Later, the UE 102 operating in an inactive state with the SDT configured starts the SDT. In response to or after starting 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 on the cell 124 (404). In response to starting the SDT, the UE 102 may start an SDT timer. 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.

[0073] In a scenario where 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 where 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.

[0074] In some embodiments, the UE 102 may include a buffer status report or a power headroom report in the initial UL MAC PDU of the event 404. In other embodiments, the UE 102 refrains from including a buffer status report and / or a power headroom report in the initial UL MAC PDU of the event 404, e.g., according to a BSR configuration and / or a PHR configuration, respectively. In a buffer status report, the UE 102 may include or indicate its buffer status for one or more logical channels or logical channel groups. In a power headroom report, the UE 102 may include or indicate a power headroom status or value.

[0075] In some embodiments, the UE 102 in the inactive state performs a random access procedure with the DU 174 to transmit a UL MAC PDU (404). In such a case, the SDT is a 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 case of the four-step random access procedure, the UE 102 transmits a random access preamble to the DU 174, and in response, the DU 174 transmits a random access response (RAR) including an uplink grant to the UE 102, and the UE 102 transmits a UL MAC PDU according to the uplink grant (404). The DU 174 receives a UL MAC PDU according to the uplink grant of the RAR (404). In the case of the two-step random access procedure, the UE 102 transmits a message A including a random access preamble and a UL MAC PDU to the DU 174 according to two-step random access configuration parameters (404). Before transmitting 404 the UL MAC PDU, the UE 102 receives 2-step random access configuration parameters in system information broadcast by the DU 174 on the cell 124. The DU 174 receives 404 the UL MAC PDU according to the 2-step random access configuration parameters.

[0076] In a further embodiment, the UE 102 may transmit 404 a UL MAC PDU on radio resources configured with a configuration grant for SDT (CG) configuration if the UE 102 receives a CG-SDT configuration as described with respect to Figure 3. Thus, the DU 174 receives 404 a UL MAC PDU on radio resources. In such an embodiment, the UE 102 may transmit (at event 418) a subsequent UL MAC PDU(s) including one or more UL data packets, as described below, on radio resources configured with the CG configuration.

[0077] If the UE 102 includes the 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 send the UL data separately to the CU-CP 172A in the DU-to-CU message (i.e., event 415). In some embodiments, the DU-to-CU message of event 415 may be a UL RRC message transfer message. As yet another alternative, the DU 174 may send the UL data separately (416) to the CU-UP 172B via a user plane (UP) connection, as described below (i.e., event 416). After receiving the first DU-to-CU message (406), the CU-CP 172A in some embodiments may send a UE context setup request message (408) to the DU 174 to establish a UE context for the UE 102 in the DU 174. In the UE context setup request message, the CU-CP 172A may include transport layer information for one or more GTP-U tunnels between the CU-UP 172B and the DU 174 so that the DU 174 can transmit 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 may transmit a UE context setup response message to the CU-CP 172A (410). After receiving the first DU-to-CU message (406), transmitting the UE context setup request message (408), and / or receiving the UE context setup response message (410), the CU-CP 172A transmits a bearer context modification request message to the CU-UP 172B to resume data transmission of the UE 102 (412). In response, the CU-UP 172B resumes data transmission for the UE 102 and sends a modify bearer context response message to the CU-CP 172A (414).After receiving (408) the UE context setup request message and / or sending (410) the UE context setup response message, the DU 174 may send (415) a DU-to-CU message containing UL data to the CU-CP 172A if the UL data packet (received in event 404) contains an RRC message or is associated with an SRB (e.g., SRB1 or SRB2). If the UL data packet is associated with a DRB, the DU 174 may send (416) the UL data packet to the CU-UP 172B via one of one or more GTP-U tunnels.

[0078] In some implementations, the CU-CP 172A may 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 may include an IP address and / or an uplink tunnel endpoint ID (e.g., TEID). The DU 174 may 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 may transmit (at event 418) one or more subsequent UL MAC PDUs including 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 including the subsequent UL data to the CU-CP 172A (418). Each DU-to-CU message may include a specific UL data packet of the subsequent UL data. If the subsequent UL data is associated with one or more DRBs, the DU 174 sends the subsequent UL data to the CU-UP 172B (at event 418). In some embodiments, the DU 174 may include its DU transport layer information in a UE context setup response message. The CU-CP 172A may then include its transport layer information 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 (418) the DL data (e.g., one or more DL data packets) to the DU 174 using the transport layer information of the DU 174. The DU 174 then transmits (at event 418) one or more DL MAC PDUs containing the DL data to the UE 102 operating in an inactive state.In some implementations, the UE 102 may include a buffer status report and / or a power headroom report in a subsequent UL MAC PDU, e.g., according to a BSR configuration and / or a PHR configuration, respectively. In a buffer status report, the UE 102 may include or indicate its buffer status for one or more logical channels or logical channel groups. In a power headroom report, the UE 102 may include or indicate a power headroom status or value.

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

[0080] Events 404, 406, 408, 410, 412, 414, 415, and 416 are collectively referred to as SDT procedure 494 in FIG.

[0081] In some embodiments, the UL RRC message is a (existing) RRC Resume Request message (e.g., an RRCResumeRequest message, an RRCResumeRequest1 message, an RRCConnectionResumeRequest message, or an RRCConnectionResumeRequest1 message). In other embodiments, the UL RRC message can be a new RRC Resume Request message as well as 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 case of downlink SDT, the UL RRC message can be a field element or information element (IE) (e.g., resumeCause or ResumeCause) or can include an SDT indication. In some embodiments, the UL RRC message is a Common Control Channel (CCCH) message.

[0082] After the UE 102 transmits a UL MAC PDU (404) or communicates subsequent UL and / or DL ​​data with the DU 174 (418), the CU-CP 172A can determine to stop the SDT of the UE 102 based on the data inactivity state of the UE 102 (i.e., a UE 102 in an inactive state has no data activity with the base station 104). For example, after the UE 102 transmits a UL MAC PDU (404) or communicates subsequent UL and / or DL ​​data with the DU 174 (418), a UE 102 in an inactive state can determine or detect a data inactivity state and transmit UE assistance information (e.g., a UE Assistance Information message) to the DU 174 indicating that the UE 102 prefers or requests to stop the SDT (420). The DU 174 then transmits a UL RRC Message Transfer message including the UE assistance information to the CU-CP 172A (421). Therefore, the CU-CP 172A can determine that the UE 102 is in a data inactive state based on the UE assistance information. In another embodiment, the DU 174 can perform data inactive state monitoring for the UE 102. For example, 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 inactive state monitoring. If the DU 174 detects or determines that the UE 102 is in a data inactive state during monitoring, the DU 174 can send an inactive state notification (e.g., a UE inactive state notification message) to the CU-CP 172A (422). Thus, the CU-CP 172A can determine that the UE 102 is in a data inactive state based on the inactive state notification received from the DU 174. In yet another embodiment, the CU-UP 172B can perform data inactive state monitoring for the UE 102. For example, the CU-CP 172A may send a CP-to-UP message to the CU-UP 172B to request or command the 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 modification request message before the UE 102 starts the SDT. In other embodiments, the CP to UP message may be a bearer context modification request message 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 inactive 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 inactive 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 any combination of the UE assistance information, the inactive state notification of event 422, and / or the inactive state notification of event 423.

[0083] After a particular data inactivity period, the CU-CP 172A may determine that neither the CU 172 nor the UE 102 have transmitted any data in the downlink or uplink direction, respectively, during the particular period (e.g., using any of the techniques described above for UE inactivity determination). In response to the determination, the CU-CP 172A may decide to stop the SDT. Alternatively, the CU-CP 172A may decide to immediately stop the SDT of the UE 102 in response to determining that the UE 102 is in a data inactivity state, regardless of whether the CU 172 transmitted data in the downlink direction during any particular period.

[0084] In response to or after determining that the UE 102 is in a data inactive state (for a particular period of time), or in response to or after determining that the SDT is otherwise stopped, the CU-CP 172A sends a bearer context modification request message to the CP-CU 172B (424) to suspend data transmission of the UE 102. In response to this, the CU-UP 172B suspends data transmission of the UE 102 and sends a bearer context modification response message to the CU-CP 172A (426). Also, in response to or after determining that the UE 102 is in a data inactive state (for a particular period of time), or in response to or after determining that the SDT is otherwise stopped, the CU-CP 172A sends a second CU-to-DU message (e.g., a UE context modification request message) (428) to instruct the DU 174 to provide (i.e., request from the DU 174) an 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 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 (430). Alternatively, the DU 174 does not include the SDT DU configuration in the second DU-to-CU message, and instead 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 after receiving the second CU-to-DU message (event 428) and / or after sending the second DU-to-CU message (event 430). 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 receive the alternative DU-to-CU message described above) before determining that the UE 102 is in a data inactive state.

[0085] In response to deciding to stop the SDT, the CU-CP 172A can generate an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelase message) to stop the SDT while keeping the UE 102 in an inactive state. The CU-CP 172A can include the SDT DU configuration (if requested and received) and 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 or a UE context modification request message) including the RRC release message to the DU 174 (432). The DU 174 then sends an RRC release message to the UE 102 (434). Upon receiving the RRC release message, the UE 102 stops the SDT and remains in an inactive state. In response to or after stopping the SDT, the UE 102 may stop the SDT timer, may stop monitoring the PDCCH for the SDT, and / or may release the C-RNTI that the UE 102 uses to monitor the PDCCH for the SDT. Instead, the UE 102 retains the C-RNTI. In response to the third CU-to-DU message, the DU 174 may retain the SDT DU configuration and may or may not release the first non-SDT DU configuration and / or the second non-SDT DU configuration described above in connection with FIG. 3. 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. In some embodiments, if the RRC release message instructs the UE 102 to transition to an inactive state (specifically, RRC_IDLE), the UE 102 transitions to the RRC_IDLE state and releases the non-SDT configuration (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 first SDT DU configuration and / or the first SDT CU configuration described in FIG. 3).

[0086] The examples and embodiments described above 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 stopping the SDT, the UE 102 can perform another small data transmission procedure with the base station 104 or base station 106, similar to procedure 490.

[0087] In some embodiments, the CU-CP 172A may not require the DU 174 to provide the SDT DU configuration. In such a case, events 428 and 430 can be omitted, and the CU-CP 172A does not include the SDT DU configuration in the RRC release message. Instead, the CU-CP 172A may generate the second SDT DU configuration by itself and include the second SDT DU configuration in the RRC release message.

[0088] In some implementations, the DU 174 may not include the SDT DU configuration in the message from the second DU to the CU, 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 radio resources available for CG-SDT. In such cases, the RRC release message does not include the SDT DU configuration. Otherwise, the DU 174 may include the second SDT DU configuration as described above. In some implementations, the DU 174 may not include the CG-SDT configuration in the second SDT DU configuration in the message from the second DU to the CU, 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 radio resources available for CG-SDT. In such cases, the second SDT DU configuration does not include the CG-SDT configuration. Otherwise, the DU 174 may include at least one CG-SDT configuration in the second SDT DU configuration as described above.

[0089] 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 may receive the UE capability (e.g., UE-NR-Capability IE) of the UE 102 from the UE 102, the CN 110 (e.g., MME 114 or AMF 164), or the base station 106 while the UE 102 operates in an inactive state (402) before the UE 102 starts the SDT, while the UE 102 performs the 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 102 operates in a connected state as described in FIG. 3. The UE capability indicates whether the UE 102 supports CG-SDT. Thus, the CU-CP 172A may determine whether the UE 102 supports CG-SDT according to the UE capability. In some embodiments, the CU-CP 172A may receive a DU-to-CU message from the DU 174 indicating whether the DU 174 supports CG-SDT. The DU to CU message may 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).

[0090] 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 second 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 second SDT DU configuration in the second DU to CU message). For example, while the UE 102 operates in a connected or 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.

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

[0092] During the SDT procedure 594, the CU-CP 172A can determine whether to transition the UE 102 to a connected state, for example, based on the UL or DL ​​data activity of the UE 102. In some embodiments, the UE 102 can send a non-SDT request message to the DU 174 to request transition to a connected state and / or to indicate that UL data for non-SDT is available (504). The DU 174 then sends a UL RRC message transfer message including the non-SDT request message to the CU-CP 172A (506). The CU-CP 172A can determine to transition the UE 102 to a connected state based on the non-SDT request message (e.g., in response to the non-SDT request message). In other embodiments, the CU-UP 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 to the UE 102. The CU-CP 172A may determine to transition the UE 102 to a connected state based on the DL data notification (e.g., in response to the DL data notification). In yet other embodiments and / or scenarios, the CU-CP 172A determines to transition the UE 102 to a connected state based on measurement results received from the UE 102. In yet other embodiments and / or scenarios, the CU-CP 172A receives DL data (e.g., NAS message(s)) from the CN 110 and determines to transition the UE 102 to a connected state in response to receiving the DL data.

[0093] In some embodiments, the non-SDT request message of event 504 may be an RRC message (eg, a UEAssistanceInformation message or a new / dedicated RRC message).

[0094] In some embodiments, the UL data is associated with the 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 request message. Thus, the CU-CP 172A may determine whether to transition the UE 102 to a connected state based on the ID(s). For example, if the ID(s) include a particular ID(s), the CU-CP 172A may determine to transition the UE 102 to a connected state. Otherwise, the CU-CP 172A may determine not to transition the UE 102 to a connected state. In some embodiments, the UE 102 may include data amount information of the UL data in the non-SDT request message of the event 504. Therefore, the CU-CP 172A can determine whether to transition the UE 102 to a connected state based on the data volume information. In one embodiment, the data volume information includes a total data volume of UL data. For example, the UE 102 can quantify or round the total data volume to a value that the UE 102 then includes in the data volume information. In another embodiment, the data volume information includes a data volume of each of the radio bearer(s). For example, the UE 102 can quantify or round the data volume of each of the radio bearer(s) to a value that the UE 102 then includes in the data volume information. In some embodiments and / or scenarios, if the total data volume is above a predetermined threshold, the CU-CP 172A can determine to transition the UE 102 to a connected state. Otherwise, the CU-CP 172A can determine not to transition the UE 102 to a connected state. In another example, if the data volume of a particular radio bearer is above a predetermined threshold, the CU-CP 172A can determine to transition the UE 102 to a connected state. Otherwise, the CU-CP 172A may decide not to transition the UE 102 to a connected state.In yet another example, if the total amount of data is above a predetermined threshold and the amount of data of a particular radio bearer is above 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 a connected state.

[0095] After deciding (e.g., in response to deciding) to transition the UE 102 to a 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 (508). In response, the DU 174 sends a UE context response message to the CU-CP 172A (510). 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 RRC Resume message or an RRCConnectionResume message) to the DU 174 (512). The DU 174 then sends an RRC resume message to the UE 102 (514). In response, the UE 102 transitions to a connected state (516) and sends an RRC Resume Complete message (e.g., an RRCResumeComplete message or an RRCConnectionResumeComplete message) to the DU 174 (518). 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 (520). After deciding to transition the UE 102 to a 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 (522) to indicate that the CU-UP 172B resumes 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 Modify Response message) to the CU CP-172A (524).In some embodiments, the CU-CP 172A may send (522) a bearer context request message after sending (508) a UE context request message, after receiving (510) a UE context response message, after sending (512) a message from the CU to the DU, and / or after receiving (520) a CU message from the DU.

[0096] In some embodiments, the CU-CP 172A may include an indication to the DU 174 to generate a non-SDT configuration in the UE context request message of event 508, and the DU 174 may include the first non-SDT DU configuration in the UE context response message of event 510 in response to the indication. In 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 may also store the second non-SDT DU configuration. In such a case, the CU-CP 172A may include the second non-SDT DU configuration in the UE context request message, and the DU 174 may 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 embodiments of the first and second non-SDT DU configurations may include any of the exemplary non-SDT DU configurations described above. In some embodiments, instead of including the first non-SDT DU configuration in the UE context response message of event 510, 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.

[0097] After transitioning to the connected state (516), the UE 102 communicates UL data and / or DL ​​data with the CU-CP 172A and / or CU-UP 172B via the DU 174 (526). The UL data may include the UL data that triggered the UE to send the non-SDT request message at event 504. The UL data may also include new UL data available for transmission. The DL data may include DL data received by the CU 172 from the CN 110 as described above. The DL data may also include new DL data received by the CU 172 from the CN 110. If the RRC resume message of events 512 and 514 includes the first non-SDT DU configuration, the UE 102 communicates with the DU 174 using the first non-SDT DU configuration (526). 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 (526) with the DU 174 using configuration parameters of the second non-SDT DU configuration that have not been extended / replaced by the first non-SDT DU configuration.

[0098] 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 of events 512 and 514 does not include the first non-SDT DU configuration, and the UE 102 and the DU 174 communicate with each other using the second non-SDT DU configuration (526).

[0099] The CU-CP 172A may subsequently perform (592) an SDT configuration procedure with the UE 102, the DU 174, and the CU-CP 172B, similar to procedure 392. The UE 102 transitions (528) to an inactive state in response to receiving the RRC release message in procedure 592. The UE 102 may then initiate another SDT procedure with the base station 104 or base station 106, similar to procedures 494 and / or 594.

[0100] Next, some example methods that may be implemented in a UE or RAN (e.g., one or more base stations, a DU, or a CU) to support data communication in an inactive state will now be described with reference to Figures 6 to 12.

[0101] FIG. 6 illustrates a method 600 that may be implemented by a CU (eg, CU 172 or CU-CP 172A) for processing information elements of an interface message to obtain an RRC message.

[0102] The method 600 generally includes determining whether an octet string of a DU-to-CU message is a PDCP PDU or a UL-CCCH message based on an SRB identity (ID) of the DU-to-CU message. In the exemplary embodiment shown in FIG. 6, the method 600 begins at block 602 where the CU receives a DU-to-CU message from the DU (e.g., events 321, 406, 421, 506, 520). At block 604, the CU extracts the SRB ID and the container IE from the DU-to-CU message, where the container IE includes the octet string. At block 606, the CU determines whether the SRB ID is zero. If the CU determines that the SRB ID is not zero, the flow proceeds to block 608. At block 608, the CU determines that the octet string is a PDCP PDU. At block 610, the CU processes the PDCP PDU to obtain a UL-DCCH-message. In block 612, the CU extracts the RRC message from the UL-DCCH-message and processes the RRC message. Otherwise, if in block 606 the CU determines that the SRB ID is zero, then the flow proceeds to block 614. In block 614, the CU determines that the octet string is a UL-CCCH-message. In block 616, the CU extracts the RRC message from the UL-CCCH-message and processes the RRC message.

[0103] When the CU activates ciphering and integrity protection for communication with the UE, the CU extracts, for example, the PDCP sequence number, the ciphered data packet, and the ciphered MAC-I from the PDCP PDU. The CU also selects the ciphering algorithm, the ciphering key (e.g., K RRCene ), and the encryption parameters to decrypt the encrypted data packet and the encrypted MAC-I to obtain the data packet and MAC-I (i.e., the decrypted data packet and MAC-I). For example, the encryption parameters may include LENGTH, BEARER, DIRECTION, and / or COUNT. BEARER may be an SRB ID. COUNT may be a COUNT value of the PDCP PDU or the encrypted data packet, which consists of the PDCP sequence number and the hyperframe number (HFN). DIRECTION may be a 1-bit value, e.g., 0. LENGTH is the length of the encrypted data packet. The CU determines the integrity algorithm, the integrity key (e.g., K RRCint ), and an integrity check can be performed to verify the MAC-I using an integrity parameter. The integrity parameter may be similar to an encryption parameter. If the CU activates integrity protection for communication with the UE without activating ciphering, the CU performs an integrity check directly on the data packets extracted from the PDCP PDU, as described above.

[0104] If the RRC message included in the UL-CCCH-message is an RRC Resume Request message (e.g., RRCResumeRequest or RRCResumeRequest1 message), the CU may extract the MAC-I (e.g., resumeMAC-I) from the RRC Resume Request message and verify the MAC-I using an integrity algorithm, an integrity key (e.g., KRRCint), and integrity parameters. The integrity parameters may include BEARER, DIRECTION, and / or COUNT, which may be set to binary.

[0105] FIG. 7 illustrates a method 700 that may be implemented by a DU (eg, DU 174) that forwards UL data packets to a CU (eg, CU 172, or more specifically, CU-CP 172A).

[0106] The method 700 generally includes determining whether to transmit UL data in an initial UL RRC message transfer message or a non-initial UL RRC message transfer message based on whether the radio resource is a configuration grant radio resource. In the exemplary implementation shown in FIG. 7, the method 700 begins at block 702 where the DU receives a UL data packet from the UE over a CCCH (e.g., event 404). At block 704, the DU determines whether the DU receives the UL data packet on the radio resource configured in the configuration grant. If the DU determines that the DU receives the UL data packet on the radio resource configured in the configuration grant (and thus the previous F1 interface / connection for the UE between the DU and the CU still exists), the flow proceeds to block 706. At block 706, the DU transmits a first DU-to-CU message (e.g., a UL RRC message transfer message) including the UL data packet to the first CU (e.g., event 406). Otherwise, if the DU determines that the DU will receive the UL data packet on the radio resources configured in the dynamic grant, the flow proceeds to block 708. In block 708, the DU sends to the second CU a second DU-to-CU message (e.g., an initial UL RRC message transfer message rather than the non-initial UL RRC message transfer message of block 706) that includes the UL data packet (e.g., event 406).

[0107] Blocks 704 , 706 , and 708 are collectively referred to herein as an uplink transmission procedure 790 .

[0108] In some embodiments, the DU can receive a UL MAC PDU including a MAC subPDU from the UE. The MAC subPDU includes a logical channel ID and an uplink data packet. The logical channel ID identifies a CCCH. Thus, the DU can determine that the uplink data packet is received via a CCCH. In some embodiments, the uplink data packet can be a UL-CCCH-message.

[0109] In some embodiments, the DU can include SRB ID0 in the UL RRC message transfer message and does not include SRB ID0 in the initial UL RRC message transfer message. In some embodiments, the first CU and the second CU can be the same CU or CU-CP. In other embodiments, the first CU and the second CU can be different CUs or different CU-CPs.

[0110] In some implementations, the UE may perform a random access procedure to transmit a UL data packet and receive a dynamic grant in a random access response of the random access procedure.

[0111] FIG. 8 illustrates a method 800 that may be implemented by a CU (e.g., CU 172 or CU-CP 172A) for transitioning a UE (e.g., UE 102) to a connected state while performing small data communication with the UE operating in an inactive state.

[0112] The method 800 begins at block 802, where the CU communicates with a UE operating in an inactive state via the DU (e.g., events 404, 406, 418, 494, 594). At block 804, the CU decides to transition the UE to a connected state during data communication. At block 806, in response to the decision, the CU sends a UE context request message to the DU (e.g., event 508). At block 808, in response to the UE context request message, the CU receives a UE context response message including a non-SDT DU configuration (e.g., CellGroupConfig IE) from the DU (e.g., event 510). At block 810, the CU sends a first message including a non-SDT DU configuration to the UE via the DU to transition the UE to a connected state (e.g., events 512, 514). At block 812, in response to the first message, the CU receives a second message from the UE via the DU (e.g., events 518, 520). In block 814, the CU communicates with the UE operating in a connected state via the DU (eg, event 526).

[0113] FIG. 9 illustrates a method 900 that may be implemented by a DU (eg, DU 174) to transition a UE (eg, UE 102) to a connected state while performing small data communication with the UE operating in an inactive state.

[0114] The method 900 begins at block 902 where the DU communicates with a UE operating in an inactive state using an SDT configuration (e.g., events 404, 418, 494, 594). At block 904, the DU receives a UE context request message from the CU (e.g., event 508). At block 906, in response to the UE context request message, the DU sends a UE context response message to the CU that includes a non-SDT DU configuration (e.g., CellGroupConfig IE) (e.g., event 510). At block 908, the DU receives a CU-to-DU message from the CU that includes a first message that includes a non-SDT DU configuration for the UE (e.g., event 512). At block 910, the DU sends the first message to the UE (e.g., event 514). At block 912, the DU receives a second message from the UE in response to the first message and sends a DU-to-CU message to the CU that includes the second message (e.g., events 516, 518). At block 914, the DU communicates with the UE operating in a connected state using a non-SDT DU configuration (eg, event 526).

[0115] In some embodiments, the SDT configuration includes an SDT broadcast configuration (e.g., event 403) and / or an SDT DU configuration (e.g., event 330). In some embodiments, the CU-to-DU and DU-to-CU messages may be UL and DL RRC message transfer messages, respectively. In other embodiments, the CU-to-DU and DU-to-CU messages may be F1AP messages defined in 3GPP specification 38.473.

[0116] The following embodiments and examples may be applied to methods 800 and 900.

[0117] In some embodiments, the CU and UE operating in the inactive state communicate with each other (via the DU) using an SDT CU configuration and a non-SDT CU configuration. In some embodiments, the first message and the second message are an RRC resume message and an RRC resume complete message, respectively. More specifically, the first message and the second message may be a DL-DCCH-message and a UL-DCCH-message, respectively, including an RRC resume message and an RRC resume complete message. In some embodiments, the UE context request message and the UE context response message may be a UE context modification request message and a UE context modification response message, respectively. In other embodiments, the UE context request message and the UE context response message may be a UE context setup request message and a UE context setup response message, respectively. In some embodiments, the non-SDT DU configuration includes configuration parameters related to the MAC protocol layer (e.g., NR MAC 204B) and the PHY protocol layer (e.g., NR PHY 202B). After the UE transitions to a connected state, transmits the first message, and / or receives the second message, the DU communicates with the UE using a non-SDT DU configuration. In some embodiments, the non-SDT DU configuration may be a CellGroupConfig IE.

[0118] In the UE context request message, the CU may, in some embodiments, include a first indication (e.g., an IE) indicating that the DU provides a non-SDT DU configuration or indicating that the UE needs to transition to a connected state. In response to the first indication, the DU generates a non-SDT DU configuration and includes the non-SDT DU configuration in the UE context response message. In other embodiments, the CU refrains from including a second indication (e.g., an IE) indicating that the DU provides an SDT DU configuration in the UE context request message. In response to a UE context request message that excludes the second indication, the DU generates a non-SDT DU configuration and includes the non-SDT DU configuration in the UE context response message.

[0119] To transmit the first message to the DU or UE via the DU, the CU may generate a downlink PDCP PDU including the first message and transmit the downlink PDCP PDU to the DU. If the CU activates one or more security features for the UE, the CU may apply the one or more security features to the first message to obtain a first secured message and generate a downlink PDCP PDU including the first secured message, as described above. The CU may then transmit the downlink PDCP PDU to the DU. The DU may then generate a downlink RLC PDU including the downlink PDCP PDU and generate a downlink MAC PDU including a logical channel ID (e.g., 1) and the downlink RLC PDU. The DU may then transmit the downlink MAC PDU to the UE using the SDT configuration. Alternatively, the CU may generate one or more RLC PDU segments to include the downlink PDCP PDU and generate multiple downlink MAC PDUs, each including a logical channel ID and a particular RLC PDU segment of the one or more RLC PDU segments. The DU can then transmit the downlink MAC PDU to the UE.

[0120] To send the second message to the DU, the UE may generate an uplink PDCP PDU including the second message and send the uplink PDCP PDU to the DU. If the UE activates one or more security features (i.e., the same as the one or more security features applied by the CU) to communicate with the CU, the UE may apply the one or more security features to the second message to obtain a second secured message as described above and generate an uplink PDCP PDU including the second secured message. The UE may then send the uplink PDCP PDU to the DU. More specifically, the UE may generate an uplink RLC PDU including the uplink PDCP PDU and generate an uplink MAC PDU including a logical channel ID (e.g., 1) and the uplink RLC PDU. The UE may then send the uplink MAC PDU to the DU using the SDT configuration.

[0121] In some embodiments, after generating or transmitting a non-SDT DU configuration to the CU, the DU continues to use the SDT configuration, e.g., to communicate data (including downlink MAC PDU(s)) with the UE. The DU may stop using the SDT configuration upon receiving a CU-to-DU message from the CU indicating that the DU is stopping use.

[0122] In some embodiments, the DU may receive a second message from the UE using a non-SDT DU configuration. More specifically, the DU may receive uplink MAC PDU(s) from the UE using a non-SDT DU configuration. In a non-SDT DU configuration, the DU refrains from including a configuration parameter (e.g., ReconfigurationWithSync IE) that causes or triggers the UE to perform a random access procedure. In some embodiments, the DU may decide to switch to or use a non-SDT DU configuration to communicate with the UE upon receiving at least one HARQ acknowledgement confirming receipt of downlink MAC PDU(s) from the UE. In such a case, the DU may stop using an SDT configuration to communicate with the UE upon receiving at least one HARQ acknowledgement. In other embodiments, the DU may decide to switch to or use a non-SDT DU configuration to communicate with the UE upon receiving at least one RLC acknowledgement confirming receipt of an uplink RLC PDU or uplink RLC PDU segment(s) from the UE. In such a case, the DU may stop using the SDT configuration to communicate with the UE upon receiving at least one RLC acknowledgement.

[0123] In other embodiments, the DU can receive a second message from the UE using the SDT configuration. More specifically, the DU can receive uplink MAC PDU(s) from the UE using the SDT configuration. In other words, the UE transmits the second message or uplink MAC PDU(s) to the DU using the SDT configuration. In some embodiments, the DU can decide to switch to or use a non-SDT DU configuration to communicate with the UE upon receiving the uplink MAC PDU(s) from the UE. In such a case, the DU can stop using the SDT configuration to communicate with the UE upon receiving the uplink MAC PDU(s). In some embodiments, the DU can release the SDT DU configuration after receiving (e.g., in response to receiving) a message from the CU to the DU that includes the first message, or after otherwise indicating that the DU will stop using or release the SDU DU configuration. In such a case, the CU can release the SDT CU configuration in response to transitioning the UE to a connected state. Similarly, the UE may release or stop using the SDT DU configuration and / or the SDT CU configuration after receiving (e.g., in response to receiving) the first message. In some embodiments, the DU may retain the SDT DU configuration after receiving (e.g., in response to receiving) the DU message from the CU or while the UE operates in a connected state. In such a case, the CU may retain the SDT CU configuration while communicating with a UE operating in a connected state. Similarly, the UE may retain the SDT DU configuration and / or the SDT CU configuration after receiving (e.g., in response to receiving) the first message or while operating in a connected state.

[0124] In some embodiments, the DU can configure the non-SDT DU configuration to include configuration parameter(s) in the SDT configuration. For example, the configuration parameter(s) may include a PDCCH configuration, a control resource set, and / or a search space configuration for the UE to receive control signals, such as downlink control information (DCI), on one or more PDCCHs. Thus, there is no difficult switching point for the DU to switch from the SDT configuration to the non-SDT DU configuration. In some embodiments, the non-SDT DU configuration includes additional configuration parameter(s) that are not in the SDT configuration. In some embodiments, the DU can apply or start applying the additional configuration parameter(s) after generating the non-SDT DU configuration and / or after transmitting the non-SDT DU configuration to the CU. In other embodiments, the DU can apply or start applying the additional configuration parameter(s) before, during, or after transmitting the downlink MAC PDU(s). For example, a non-SDT DU configuration may include one or more RS configuration(s) (e.g., CSI-RS configuration(s)). After generating a non-SDT DU configuration or sending a non-SDT DU configuration to a CU, the DU may transmit or start transmitting the RS(s) according to the CSI-RS configuration. Alternatively, the DU may transmit or start transmitting the RS(s) according to the CSI-RS configuration before, during, or after sending downlink MAC PDU(s).

[0125] In some embodiments, the DU may not understand the first message or the downlink PDCP PDU received in the CU-to-DU message. In such a case, the CU may include an indication in the CU-to-DU message indicating that the UE is about to transition to a connected state for the first message (or for the downlink PDCP PDU). Thus, the DU may prepare itself to apply a non-SDT DU configuration (i.e., the first non-SDT DU configuration) in response to the indication.

[0126] In some embodiments, the CU can include another non-SDT DU configuration (i.e., a second non-SDT DU configuration) in the UE context request message, and the DU uses the second non-SDT DU configuration to communicate with the UE operating in a connected state before the UE transitions to an inactive state. Similarly, the UE operating in a connected state communicates with the DU using the second non-SDT DU configuration and communicates with the CU using a non-SDT CU configuration via the DU. The second non-SDT DU configuration includes multiple configuration parameters related to the RRC, RLC, MAC, and PHY protocol layers (e.g., RRC 214, NR RLC 206B, NR MAC 204B, and / or NR PHY 202B). In some embodiments, the second non-SDT DU configuration can be or can include a CellGroupConfig IE or configuration parameters. In some embodiments, the DU can generate the first non-SDT DU configuration to extend the second non-SDT DU configuration. In such a case, the DU of block 912 may use the configuration parameters of the first non-SDT DU configuration and / or the second non-SDT DU configuration to communicate with the UE operating in a connected state. In other embodiments, the DU may generate the first non-SDT DU configuration to replace the second non-SDT DU configuration. In yet other embodiments, the DU may decide to use the second non-SDT DU configuration to communicate with the UE without generating a non-SDT DU configuration. In such a case, the DU may not include the non-SDT DU configuration in the UE context response message. After sending the first message to the UE, the DU uses the second non-SDT DU configuration to communicate with the UE operating in a connected state.

[0127] In some embodiments, after transitioning the UE to a connected state, the CU can send another CU-to-DU message (i.e., a second CU-to-DU message) to the DU to instruct the DU to release the SDT DU configuration. In response to the second CU-to-DU message, the DU can release the SDT DU configuration and send a second DU-to-CU message to the CU. In the second CU-to-DU message, the CU can include a release indication indicating that the DU releases the SDT DU configuration. In some embodiments, the second CU-to-DU message and the second DU-to-CU message can be a UE context modification request message and a UE context modification response message, respectively. In other embodiments, the second CU-to-DU message and the second DU-to-CU message can be a UE context release command message and a UE context release complete message, respectively.

[0128] FIG. 10 illustrates a method 1000 that may be implemented by a base station (e.g., base station 104 or 106) to transition a UE (e.g., UE 102) to a connected state while performing small data communication with the UE operating in an inactive state.

[0129] The method 1000 begins at block 1002, in which the base station communicates with a UE operating in an inactive state using an SDT configuration (e.g., events 404, 406, 418, 494, 594). At block 1004, the base station decides to transition the UE to a connected state during data communication. At block 1006, the base station sends a first message including a non-SDT configuration (e.g., a non-SDT DU configuration if the base station is a distributed base station) to the UE to transition the UE to a connected state (e.g., events 512, 514). At block 1008, the base station receives a second message from the UE in response to the first message (e.g., events 518, 520). At block 1010, the base station communicates with the UE operating in a connected state using a non-SDT (e.g., non-SDT DU) configuration (e.g., event 526).

[0130] The base station may include the functions of DU and CU, and the embodiments and examples described above with respect to Figures 8 and 9 may be applied to the method 1000 of Figure 10. The SDT configuration may include an SDT broadcast configuration, an SDT DU configuration, and / or an SDT CU configuration, as described above. If the first message is an RRC resume message, the base station in some embodiments may retain the SDT CU configuration and / or the SDT DU configuration of the UE operating in the connected state, as described above. If the first message is an RRC setup message, the base station in some embodiments may release the SDT CU configuration and / or the SDT DU configuration of the UE operating in the connected state, as described above. In such a case, the second message may be an RRC setup complete message.

[0131] FIG. 11 illustrates a method 1100 that may be implemented by a UE (eg, UE 102) to transition to a connected state while the UE in an inactive state is performing small data communication with a base station.

[0132] The method 1100 begins at block 1102 where the UE communicates with a base station while operating in an inactive state using an SDT configuration (e.g., events 404, 406, 418, 494, 594). At block 1104, the UE receives a first message from the base station including a non-SDT configuration and transitioning the UE to a connected state (event 512). At block 1106, the UE transmits a second message to the base station in response to the first message (e.g., event 518). At block 1108, the UE communicates with the UE operating in a connected state using a non-SDT DU configuration (e.g., event 526).

[0133] The base station may include DU and CU functions, and the embodiments and examples described above with respect to Figures 8 and 9 may be applied to the method 1100 of Figure 11. The SDT configuration may include an SDT broadcast configuration, an SDT DU configuration, and / or an SDT CU configuration, as described above. If the first message is an RRC resume message, the UE in some embodiments may retain the SDT CU configuration and / or the SDT DU configuration while operating in a connected state, as described above. If the first message is an RRC setup message (e.g., an RRC Setup message), the UE in some embodiments may release the SDT CU configuration and / or the SDT DU configuration while operating in a connected state, as described above. In such a case, the second message may be an RRC setup complete message (e.g., an RRC Setup Complete message).

[0134] FIG. 12 illustrates a method 1200 that may be implemented by a DU (eg, DU 174) that forwards UL data packets to a CU (eg, CU 172, CU-CP 172A).

[0135] The method 1200 generally includes determining whether to transmit uplink data over a transport network layer protocol stack or in a UL RRC message transfer message based on a logical channel. In the exemplary implementation shown in FIG. 12, the method 1200 begins at block 1202 where the DU receives a UL data packet from the UE. At block 1204, the DU determines whether to receive the UL data packet over a CCCH, a dedicated control channel (DCCH), or a dedicated traffic channel (DTCH). If the DU determines that the DU received the UL data packet over a CCCH, a DCCH, or a DTCH, respectively, the flow proceeds to block 1206, 1208, or 1210. At block 1206, the flow proceeds to the uplink transfer procedure 790 described in FIG. 7. At block 1208, the DU transmits a UL RRC message transfer message including the UL data packet to the first CU or the second CU. In block 1210, the DU sends the UL data packet to the third CU via the transport network layer protocol stack.

[0136] In some embodiments, the DU can receive a UL MAC PDU including a MAC subPDU from the UE. The MAC subPDU includes a logical channel ID and an uplink data packet. The logical channel ID identifies a CCCH, a DCCH, or a DTCH. Thus, the DU can determine that the uplink data packet is received via a CCCH, a DCCH, or a DTCH according to the logical channel ID. In the case of a CCCH, the uplink data packet can be a UL-CCCH-message. In the case of a DCCH, the uplink data packet can be a PDCP PDU including a UL-DCCH-message and a MAC-I. In the case of a DTCH, the uplink data packet can be a PDCP PDU including an application data packet. In some embodiments, the application data packet can be an IP packet or an Ethernet packet.

[0137] In some embodiments, the DU may include SRB ID1 or SRB ID2 in the UL RRC message transfer message of block 1208. If the logical channel ID is a first value (e.g., 1), the DU may include SRB ID1 in the UL RRC message transfer message of block 1208. If the logical channel ID is a first value (e.g., 2), the DU may include SRB ID2 in the UL RRC message transfer message of block 1208. In some embodiments, the first CU and the second CU may be the same CU or CU-CP. In other embodiments, the first CU and the second CU may be different CUs or different CU-CPs. In some embodiments, the third CU may be the same or different from the first CU and / or the second CU. In other embodiments, the third CU may be a CU-UP.

[0138] In some embodiments, the transport network layer protocol stack includes a physical layer, a data link layer, an IP protocol, a UDP protocol, and / or a GTP-U protocol.

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

[0140] Example 1. A method implemented by a radio access network (RAN) node for transitioning from small data transmission (SDT) to non-SDT with a user equipment (UE), the method comprising: communicating with the UE according to an SDT configuration while the UE is in an inactive state; performing a UE context procedure to obtain a non-SDT configuration; sending the non-SDT configuration to the UE; and communicating with the UE according to the non-SDT configuration while the UE is in a connected state.

[0141] Example 2. The method of example 1, wherein the RAN node is a central unit (CU) of a base station, and communicating with the UE according to the SDT configuration, sending the non-SDT configuration to the UE, and communicating with the UE according to the non-SDT configuration are performed via a distributed unit (DU) of the base station.

[0142] Example 3. The method of example 2, further comprising: determining to transition the UE to the connected state, and performing the UE context procedure in response to the determining.

[0143] Example 4. The method of example 3, further comprising receiving a message from the UE via the DU, and the determining is in response to the message.

[0144] Example 5. The method of example 4, wherein the message indicates that uplink data for non-SDT is available.

[0145] Example 6. The method of example 3, further comprising receiving downlink data from a core network, and wherein the determining is in response to receiving the downlink data.

[0146] Example 7. The method described in Example 6, wherein receiving the downlink data includes receiving the downlink data on a user plane (CU-UP) of the CU, and the method further includes sending a downlink data notification from the CU-UP to a control plane (CU-CP) of the CU in response to receiving the downlink data on the CU-UP, and the determining is in response to the downlink data notification.

[0147] Example 8. The method of example 7, wherein receiving the downlink data includes receiving the downlink data at a control plane (CU-CP) of the CU.

[0148] Example 9. The method of example 3, further comprising receiving a measurement result from the UE via the DU, and wherein the determining is based on the measurement result.

[0149] Example 10. The method according to any one of Examples 2 to 9, wherein the non-SDT configuration is a non-SDT DU configuration, and the performing includes sending a UE context modification request message to the DU, and receiving a UE context modification response message from the DU, the UE context modification response message including the non-SDT DU configuration.

[0150] Example 11. The method of example 1, wherein the RAN node is a distributed unit (DU) of a base station.

[0151] Example 12. The method of example 11, wherein the non-SDT configuration is a non-SDT DU configuration, and the performing includes receiving a UE context modification request message from a central unit (CU) of the base station, and sending a UE context modification response message to the CU, the UE context modification response message including the non-SDT DU configuration.

[0152] Example 13. The method of example 12, wherein sending the non-SDT DU configuration to the UE includes sending a radio resource control (RRC) resume message to the UE that includes the non-SDT DU configuration and causes the UE to transition to the connected state.

[0153] Example 14. A method implemented by a central unit (CU) of a base station for obtaining a radio resource control (RRC) message from an interface message, the method comprising: receiving, from a distributed unit (DU) of the base station, a DU-to-CU message including a signal radio bearer (SRB) identifier and an octet string; determining, based on the SRB identifier, whether the octet string is a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) or an Uplink Common Control Channel (UL-CCCH) message; and, based on the determining, processing the PDCP PDU or the UL-CCCH to obtain the RRC message.

[0154] Example 15. The method of example 14, wherein the determining includes determining that the octet string is a PDCP PDU, and the processing includes processing the PDCP PDU to obtain an uplink dedicated control channel (UL-DCCH) message, and extracting the RRC message from the UL-DCCH message.

[0155] Example 16. The method of example 15, wherein processing the PDCP PDU includes: extracting an encrypted data packet from the PDCP PDU; and decrypting the encrypted data packet.

[0156] Example 17. The method of example 14, wherein the determining includes determining that the octet string is a UL-CCCH, and the processing includes extracting the RRC message from the UL-CCCH.

[0157] Example 18. The method of example 17, wherein the RRC message is an RRC resume request message, and the method further includes extracting a message authentication code for integrity (MAC-I) from the RRC resume request message, and verifying the MAC-I using an integrity algorithm, an integrity key, and an integrity parameter.

[0158] Example 19. A method implemented by a distributed unit (DU) of a base station for transferring uplink data to a central unit (CU), comprising: receiving the uplink data from an inactive user equipment (UE) via a logical channel; determining, based on the logical channel, whether to transmit the uplink data via a transport network layer protocol stack or in an uplink radio resource control (RRC) message transfer message; and transmitting the uplink data to the CU based on the determining.

[0159] Example 20. The method of example 19, wherein the determining includes determining to transmit the uplink data over the transport network layer protocol stack when the logical channel is a dedicated traffic channel (DTCH).

[0160] Example 21. The method of example 19 or 20, wherein the determining includes determining to transmit the uplink data in a non-initial uplink RRC message transfer message when the logical channel is a dedicated control channel (DCCH).

[0161] Example 22. A method according to any one of Examples 19 to 21, wherein the determining includes: determining to transmit the uplink data in a non-initial uplink RRC message transfer message when the logical channel is a common control channel (CCCH) and the receiving occurs via configured grant radio resources; and determining to transmit the uplink data in an initial uplink RRC message transfer message when the logical channel is a CCCH and the receiving does not occur via configured grant radio resources.

[0162] Example 23. A method implemented by a distributed unit (DU) of a base station for transferring uplink data to a central unit (CU), comprising: receiving the uplink data from an inactive user equipment (UE) via a radio resource; determining whether to transmit the uplink data in an initial uplink radio resource control (RRC) message transfer message or in a non-initial uplink RRC message transfer message based on whether the radio resource is a configured grant radio resource; and transmitting the uplink data to the CU based on the determining.

[0163] Example 24. The method of example 23, wherein the receiving occurs over a common control channel (CCCH).

[0164] Example 25. The method of Example 24, wherein receiving the uplink data includes receiving an uplink medium access control (MAC) protocol data unit (PDU) including a logical channel identifier and an uplink data packet including the uplink data, and the method further includes determining that the uplink data packet is received via the CCCH before determining whether to transmit the uplink data via the uplink RRC message transfer message or the non-initial uplink RRC message transfer message.

[0165] Example 26. The method of any one of Examples 23 to 25, wherein the transmitting includes including a signaling radio bearer (SRB) identifier of zero in the non-initial uplink RRC message transport message when transmitting the uplink data in the non-initial uplink RRC message transport message, and refraining from including the SRB identifier of zero in the initial uplink RRC message transport message when transmitting the uplink data in the initial uplink RRC message transport message.

[0166] Example 27. A radio access network (RAN) node comprising processing hardware and configured to perform the method according to any one of Examples 1 to 26.

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

[0168] In some embodiments, "message" is used and may be replaced with "information element (IE)" or vice versa. In some embodiments, "IE" is used and may be replaced with "field" or vice versa. In some embodiments, "configuration" is replaced by "configurations" or "configuration parameters" or vice versa. In some embodiments, "small data transmission" is replaced with "early data transmission (EDT)" and "SDT" is replaced with "EDT" or vice versa. In some embodiments, "small data transmission" is replaced with "small data communication" or vice versa. In some embodiments, "stop" is replaced with "pause".

[0169] 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, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health management device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell, or a broadband router. Furthermore, a user device may in some cases be incorporated into an electronic system such as a vehicle head unit or an 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, and the like.

[0170] Certain embodiments are described in this disclosure as including logic, or several components or modules. A module can be a software module (e.g., code or machine-readable instructions stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. For example, a hardware module may include dedicated circuitry or logic that is permanently configured (e.g., as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), a digital signal processor (DSP), or other application specific processor) to perform certain operations. A hardware module may also include programmable logic or circuitry that is temporarily configured by software (e.g., contained within a general purpose processor or other programmable processor) to perform certain operations. The decision to implement a hardware module in a dedicated permanently configured circuitry or in a temporarily configured circuitry (e.g., configured by software) may be subject to cost and time considerations.

[0171] When 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 executed by one or more general-purpose processors or one or more application-specific processors.

Claims

1. 1. A method implemented by a distributed unit (DU) of a base station for forwarding uplink data including control or non-control plane information to a central unit (CU), comprising: receiving the uplink data from an inactive user equipment (UE) via a logical channel; determining whether to transmit the uplink data via a transport network layer protocol stack or in an uplink Radio Resource Control (RRC) message transfer message based on the logical channel; transmitting the uplink data to the CU in accordance with the determining; A method comprising:

2. The determining step comprises: determining to transmit the uplink data over the transport network layer protocol stack when the logical channel is a Dedicated Traffic Channel (DTCH); The method of claim 1 , comprising:

3. The determining step comprises: determining, when the logical channel is a Dedicated Control Channel (DCCH), to transmit the uplink data in a non-initial uplink RRC message transmission message; The method of claim 1 or 2, comprising:

4. The determining step comprises: determining, when the logical channel is a Common Control Channel (CCCH) and the receiving occurs over a configured grant radio resource, to transmit the uplink data in a non-initial uplink RRC message transfer message; determining, when the logical channel is a CCCH and the receiving does not occur via a configured grant radio resource, to transmit the uplink data in an initial uplink RRC message transmission message; The method according to any one of claims 1 to 3, comprising:

5. 1. A method implemented by a central unit (CU) of a base station for obtaining a radio resource control (RRC) message from an interface message, comprising: receiving, from a distributed unit (DU) of the base station, a DU-to-CU message including a signal radio bearer (SRB) identifier and an octet string; determining whether the octet string is a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) or an Uplink Common Control Channel (UL-CCCH) message based on the SRB identifier; processing the PDCP PDU or the UL-CCCH based on the determining to obtain the RRC message; A method comprising:

6. said determining including determining that the octet string is a PDCP PDU; The processing includes processing the PDCP PDU to obtain an uplink dedicated control channel (UL-DCCH) message and extracting the RRC message from the UL-DCCH message; The method of claim 5 , comprising:

7. 7. The method of claim 6, wherein processing the PDCP PDU comprises: extracting an encrypted data packet from the PDCP PDU; and decrypting the encrypted data packet.

8. said determining including determining that said octet string is a UL-CCCH; said processing including extracting the RRC message from the UL-CCCH. The method according to claim 5.

9. the RRC message is an RRC resume request message, Extracting a message authentication code for integrity (MAC-I) from the RRC resume request message; verifying said MAC-I using an integrity algorithm, an integrity key, and integrity parameters; The method of claim 8 , further comprising:

10. 1. A method implemented by a distributed unit (DU) of a base station for forwarding uplink data including control or non-control plane information to a central unit (CU), comprising: receiving the uplink data over radio resources from an inactive user equipment (UE); determining whether to transmit the uplink data in an initial uplink Radio Resource Control (RRC) message transmission message or in a non-initial uplink RRC message transmission message based on whether the radio resource is a configured grant radio resource; transmitting the uplink data to the CU in accordance with the determining; A method comprising:

11. 11. The method of claim 10, wherein said receiving occurs over a Common Control Channel (CCCH).

12. receiving the uplink data includes receiving an uplink medium access control (MAC) protocol data unit (PDU) including a logical channel identifier and an uplink data packet including the uplink data; the method further comprising determining, by the processing hardware, that the uplink data packet is received via the CCCH before determining whether to transmit the uplink data via the initial uplink RRC message transfer message or the non-initial uplink RRC message transfer message. The method of claim 11.

13. The transmitting When transmitting the uplink data in the non-initial uplink RRC message transmission message, including a signal radio bearer (SRB) identifier of zero in the non-initial uplink RRC message transmission message; refraining from including the zero SRB identifier in the initial uplink RRC message transmission message when transmitting the uplink data in the initial uplink RRC message transmission message; The method according to any one of claims 10 to 12, comprising:

14. A Radio Access Network (RAN) node comprising processing hardware and configured to carry out the method of any one of claims 1 to 13.

Images