Management of small data communications

Abstract

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

Description

Technical Field

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

Background Art

[0002] The description of this background art is provided for the purpose of generally presenting the context of the present disclosure. Aspects described in this background art section as examples of the scope of the inventors' research, and aspects that may not be eligible as prior art at the time of filing, are not admitted as prior art to the present disclosure, either explicitly or implicitly.

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

[0004] The RRC sublayer specifies the RRC_IDLE state, where the UE does not have an active radio connection with the base station; the RRC_CONNECTED state, where the UE has an active radio connection with the base station; and the RRC_INACTIVE state, which allows the UE to transition more quickly to and back to the RRC_CONNECTED state 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® has described a Small Data Transmission (SDT) procedure that enables 5G NR to support data transmission from UEs operating in the RRC_INACTIVE state (i.e., not 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 the amount of uplink data waiting to transmit is below a set amount across all radio bearers where SDT is enabled, the downlink (DL) reference signal received power (RSRP) exceeds a set threshold, and a valid SDT resource is available. The SDT procedure can be initiated by the UE either via a random access channel (RACH), i.e., via a random access SDT (RA-SDT), or via a Type 1 configuration grant (CG) resource, i.e., via a CG-SDT. In the case of RA-SDT, the network configures two-step and / or four-step random access resources for the SDT. In RA-SDT, the UE can send an initial transmit containing data in the payload of message 3 (MSG3) for the four-step random access procedure, or message A (MSGA) for the two-step random access procedure. The network can then schedule subsequent uplink and / or downlink transmits using dynamic uplink grants and downlink allocations, respectively, after the random access procedure is complete.

[0006] CG-SDT can only be initiated with a valid uplink (UL) timing alignment. The UE maintains the UL timing alignment based on the SDT-specific timing alignment timer set by the network and the DL RSRP of the highest-ranked SSB in the configured number. When the SDT-specific timing alignment timer expires, the CG resource is 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 only initiate subsequent uplink transmissions after receiving confirmation from the network for the initial uplink transmission.

[0007] In some scenarios, a UE could connect to a 5G NR radio access network (NG-RAN) that includes base stations, each having a central unit (CU) and at least one distributed unit (DU). However, it is unclear how base stations, including the CU and DU, should perform SDT with the UE. [Overview of the project]

[0008] According to certain technologies of this disclosure, a base station can decide to transition a UE that was 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 a 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 from, for example, the core network.

[0009] Once a decision is made to migrate the UE in this manner, the base station can perform UE context procedures to obtain the UE's non-SDT configuration. For example, a CU of a distributed base station may send a UE context request message to the DU that was communicating with the UE, and the DU may respond by sending a UE context response message to the CU containing the non-SDT DU configuration. The CU can then send a message to the UE via the DU containing the non-SDT DU configuration and the non-SDT CU configuration (for example, the DU forwards the non-SDT configuration in an RRC restart message).

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

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

[0012] As used herein, and unless otherwise evident from the context of use, the terms “data” or “data packet” may refer to signaling control plane information at the protocol layer that controls radio resources (e.g., RRC), mobility management (MM), or session management (SM), or to non-signaling control plane information at the protocol layer above the protocol layer for controlling radio resources (e.g., RRC), above the protocol layer for controlling MM, above the protocol layer for controlling SM, and / or the protocol layer for controlling quality of service (QoS) flows (e.g., Service Data Adaptive Protocol (SDAP)). The 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. Furthermore, in some embodiments, the UE applies the SDT techniques only if the size of the data is below a certain (e.g., configured) threshold. Furthermore, as used herein (and unless the context of its use indicates a more specific meaning), the term “configuration” may refer to a complete configuration or a subset of the parameters of a complete configuration (for example, a “delta” or other partial configuration that extends an existing configuration without completely replacing it).

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

[0014] In another example, a method for obtaining an RRC message from an interface message is implemented by the base station's CU. The method includes receiving a message from the base station's DU to the CU, which contains the SRB identity and an octet character; determining, based on the SRB identifier, whether the octet character is a PDCP PDU message or a UL-CCCH message; and, based on the determination, processing the PDCP PDU or UL-CCCH to obtain an RRC message.

[0015] In another example, a method for forwarding uplink data, including control plane information or non-control plane information, to a CU is implemented by the base station's DU. The method includes receiving uplink data from an inactive UE via a radio resource, determining whether to send the uplink data in an initial uplink RRC message forwarding message or a non-initial uplink RRC message forwarding message based on whether the radio resource is a set-grant radio resource, and sending the uplink data to the CU according to the determination.

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

[0017] [Figure 1A] This is a block diagram of an exemplary wireless communication system in which the user devices and base stations of this disclosure can implement the technology of this disclosure. [Figure 1B] This is a block diagram of an exemplary base station in which centralized units (CUs) and distributed units (DUs) can operate in the system shown in Figure 1A. [Figure 2A] Figure 1A is a block diagram of an exemplary protocol stack in which the UE communicates with the base station accordingly. [Figure 2B]Figure 1A is a block diagram of an exemplary protocol stack in which the UE communicates with the CU and DU accordingly. [Figure 3] This is a messaging diagram illustrating exemplary procedures for obtaining a non-SDT configuration for communicating data packets between a UE and a distributed base station when the radio connection between the UE and the base station is active, and for obtaining an exemplary SDT configuration for communicating data packets between the UE and the distributed base station when the radio connection between the UE and the base station is inactive. [Figure 4] This is a messaging diagram illustrating an exemplary procedure for communicating data packets between a UE and a distributed base station when the radio connection between the UE and the base station is inactive. [Figure 5] This is a messaging diagram of an exemplary scenario in which a distributed base station transitions an inactive UE (User Interface Device) that is performing small data communication with the base station to a connected state. [Figure 6] This is a flowchart illustrating an exemplary method that can be implemented in the CU or CU-CP shown in Figure 1B for processing information elements of an interface message to obtain an RRC message. [Figure 7] This is a flowchart illustrating an exemplary method that can be implemented in the DU shown in Figure 1B for forwarding UL data packets to the CU. [Figure 8] This is a flowchart illustrating an exemplary method that can be implemented on the base station in Figure 1A (e.g., the CU or DU in Figure 1B) to transition a UE that is in an inactive state and performing small data communication with the base station to a connected state. [Figure 9] This is a flowchart illustrating an exemplary method that can be implemented on the base station in Figure 1A (e.g., the CU or DU in Figure 1B) to transition a UE that is in an inactive state and performing small data communication with the base station to a connected state. [Figure 10] This is a flowchart illustrating an exemplary method that can be implemented on the base station in Figure 1A (e.g., the CU or DU in Figure 1B) to transition a UE that is in an inactive state and performing small data communication with the base station to a connected state. [Figure 11]FIG. 1A is a flow diagram of an exemplary method that can be implemented in the UE of FIG. 1A for transitioning the UE from a non-active state in which the UE performs small data communication with a base station to a connected state. [Figure 12] FIG. 1B is a flow diagram of another exemplary method that can be implemented by the DU of FIG. 1B for transferring UL data packets to the CU of FIG. 1B. DETAILED DESCRIPTION OF THE INVENTION

[0018] As will be 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 the present disclosure for managing small data communication and transitioning the UE between protocol states for controlling radio resources between the UE and the RAN. As used in the present disclosure, small data communication can refer to small data transmission (SDT) from the perspective of the network (i.e., SDT in the downlink direction), or SDT from the perspective of the UE (i.e., SDT in the uplink direction).

[0019] Referring initially to FIG. 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. Base stations 104 and 106 can operate within a RAN 105 connected to a core network (CN) 110. CN 110 can be implemented, for example, as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160. CN 110 can also be implemented as a sixth generation (6G) core in another example.

[0020] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, then cell 124 is an NR cell. If base station 104 is an ng-eNB, then cell 124 is an Evolutionary Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, if base station 106 is a gNB, then cell 126 is an NR cell, and if base station 106 is an ng-eNB, then cell 126 is an E-UTRA cell. Cells 124 and 126 may be in the same Radio Access Network Notice Area (RNA) or different RNAs. Generally, RAN 105 can contain any number of base stations, and each base station may cover 1, 2, 3, or any other suitable number of cells. UE 102 may support at least a 5G NR (or simply "NR") or E-UTRA air interface to communicate with base stations 104 and 106. Each of the base stations 104 and 106 can connect to CN110 via an interface (e.g., S1 interface or NG interface). Base stations 104 and 106 can also be interconnected via an interface (e.g., X2 interface or Xn interface) for interconnecting NG RAN nodes.

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

[0022] As shown in Figure 1A, base station 104 supports cell 124, and base station 106 supports cell 126. Since cells 124 and 126 may partially overlap, UE 102 can select one of cells 124 or 126, re-select one, or pass one cell from 124 to the other. To directly exchange messages or information, base stations 104 and 106 can support either an X2 interface or an Xn interface. In general, CN 110 can connect to any appropriate number of base stations that support NR cells and / or EUTRA cells.

[0023] CN110 can also connect UE102 to IMS network 170 via RAN105 for communication. IMS network 170 can provide UE102 with various IMS services, including IMS short messages, IMS unstructured supplemental service data (USSD), IMS value-added service data, IMS supplemental service data, IMS voice calls, and IMS video calls. For this purpose, entities operating on IMS network 170 (e.g., a server or group of servers) support packet exchange with the UE. Packets can transmit signaling (such as Session Initiation Protocol (SIP) messages, IP messages, or other appropriate messages) and data ("or medium") such as voice or video.

[0024] As described in detail below, UE102 and / or RAN105 may utilize the techniques of this disclosure when the radio connection between UE102 and RAN105 is suspended, for example, when UE102 is operating in an inactive or idle state of the protocol for controlling radio resources between UE102 and RAN105. For clarity, the following examples refer to the RRC_INACTIVE or RRC_IDLE state of the RRC protocol. As described below, in some embodiments, UE102 applies the techniques of this disclosure only if the size of the data (e.g., UL data) is below a certain threshold.

[0025] In the exemplary scenario described below, UE102 transitions to the RRC_INACTIVE or RRC_IDLE state, selects a cell on base station 104, and exchanges data with base station 104 either via base station 106 or directly with base station 104 without transitioning to the RRC_CONNECTED state. In a more specific example, after UE102 determines that data is available for uplink transmission in the RRC_INACTIVE or RRC_IDLE state, UE102 may apply one or more security features to the uplink (UL) data packet, generate a first UL protocol data unit (PDU) containing the secured packet, include a UL RRC message in a second UL PDU along with the first UL PDU, and send the second UL PDU to RAN105. UE102 includes its UE identity / identifier (ID) in the UL RRC message. RAN105 can identify UE102 based on the UE ID. In some embodiments, the UE ID may be an inactive radio network temporary identifier (I-RNTI), a reactivation ID, or a non-access layer (NAS) ID. The NAS ID may be an S-TMSI or a globally unique identifier (GUTI).

[0026] Security features may include integrity protection and / or encryption features. When integrity protection is enabled, UE102 can generate a Message Authentication Code for Integrity (MAC-I) to protect the integrity of the data. Thus, UE102 generates a secure packet containing the data and the MAC-I in this case. When encryption is enabled, UE102 can encrypt the data and obtain an encrypted packet, so the secure packet contains encrypted data. When both integrity protection and encryption are enabled, UE102 can generate a MAC-I to protect the integrity of the data and encrypt the data along with the MAC-I to generate an encrypted packet and an encrypted MAC-I. UE102 can then send the secure packet to RAN105 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). UE102 applies security features to the SDU and includes the protected SDU in a first UL PDU (e.g., a UL PDCP PDU). UE102 then includes the UL PDCP PDU in a second UL PDU, such as a UL MAC PDU, which can be associated with the Media Access Control (MAC) layer. Thus, in these cases, UE102 transmits the protected UL PDCP PDU in a UL MAC PDU. In some embodiments, UE102 may include a UL RRC message in the UL MAC PDU. In other embodiments, UE102 may omit the UL RRC message from the UL MAC PDU. In the latter case, UE102 may omit its UE ID from the UL MAC PDU that does not contain a UL RRC message. In further embodiments, UE102 may include a UL PDCP PDU in a UL Radio Link Control (RLC) PDU, and then include a UL RLC PDU in a UL MAC PDU. In some embodiments where a UL RRC message is included in a UL MAC PDU, UE102 generates an RRC MAC-I and includes the RRC MAC-I in the UL RRC message. For example, the RRC MAC-I may be the resumeMAC-I field as specified in 3GPP Specification 38.331. In further embodiments, the UE may include an integrity key (e.g., K RRCint The RRC MAC-I can be obtained from a UL RRC message that has the key, 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 UL SDU of the NAS. UE102 can apply security features to the SDU and include the protected SDU in a first UL PDU, such as a NAS PDU, which can be associated with the NAS layer. For example, the NAS layer could be an MM sublayer or SM sublayer of 5G, Evolutionary Packet System (EPS), or 6G. UE102 can then include the UL NAS PDU in a second UL PDU, such as a UL RRC message. Thus, in these cases, UE102 transmits the (first) protected UL NAS PDU in a UL RRC message. In some embodiments, UE102 can include a UL RRC message in a UL MAC PDU and transmit the UL MAC PDU to a base station (e.g., base station 104 or 106) via a cell (e.g., cell 124 or 126). In this case, UE102 may not include an RRC MAC-I in the UL RRC message. Instead, UE102 may include an RRC MAC-I as described above.

[0029] In some embodiments, the UL RRC message described above may be a Common Control Channel (CCCH) message, an RRC restart request message, or an RRC initial data request message. The UL RRC message may include the UE ID of UE102 as described above.

[0030] More generally, UE102 can protect the data using at least one of encryption and integrity protection, include the protected data as a secure packet in a first UL PDU, and transmit the first UL PDU to RAN105 in a second UL PDU.

[0031] In some scenarios and embodiments, base station 106 can extract the UE ID of UE 102 from the UL RRC message and, based on the determined UE ID, identify base station 104 as the destination for the data in the first UL PDU. In such scenarios, base station 106 may be called an “anchor” base station that sent UE 102 to an inactive state while retaining complete UE context information. In one exemplary embodiment, base station 106 extracts the first UL PDU from the second UL PDU and transmits the first UL PDU to base station 104. Base station 104 then extracts a secured packet from the first UL PDU, decrypts the data by applying one or two security features and / or checks for integrity protection, and transmits the data to CN110 (e.g., SGW112, UPF162, MME114, or AMF164) or an edge server. In some embodiments, the edge server may operate within RAN105. More specifically, base station 104 derives at least one security key from the UE context information of UE 102. Then, base station 104 extracts data from the secured packet using at least one security key and sends the data to CN 110 or the edge server. If the secured packet is an encrypted packet, base station 104 decrypts the encrypted packet and obtains the data using at least one security key (e.g., an encryption key and / or a decryption key). If the secured packet is an integrity-protected packet, the integrity-protected packet may contain data and a MAC-I. Base station 104 can verify whether the MAC-I is valid for the secured packet using at least one security key (e.g., an integrity key). If base station 104 confirms that the MAC-I is valid, base station 104 sends the data to CN 110 or the edge server. However, if base station 104 determines that the MAC-I is invalid, 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 contain an encrypted packet along with an encrypted MAC-I. In this case, base station 104 decrypts the encrypted packet and the encrypted MAC-I to obtain the data and MAC-I. Base station 104 then determines whether the MAC-I is valid for the data. If base station 104 determines that the MAC-I is valid, base station 104 retrieves the data and forwards it to CN110 or the edge server. However, if base station 104 determines that the MAC-I is invalid, base station 104 discards the packet.

[0032] In another embodiment, base station 106 retrieves a secure packet from a first UL PDU. Base station 106 performs a UE context retrieval procedure with base station 104 to obtain UE context information for UE 102 from base station 104. Base station 106 derives at least one security key from the UE context information. Base station 106 then retrieves data from the secure packet by using at least one security key and transmits the data to CN110 (e.g., UPF162) or an edge server. If the secure packet is an encrypted packet, base station 106 decrypts the encrypted packet and retrieves the data by using at least one security key (e.g., an encryption key and / or a decryption key). If the secure packet is an integrity-protected packet, the integrity-protected packet may contain data and a MAC-I. Base station 106 can verify whether the MAC-I is valid for the secure packet by using at least one security key (e.g., an integrity key). If base station 106 confirms that the MAC-I is valid, base station 106 transmits the data to CN110. On the other hand, if base station 106 determines that the MAC-I is invalid, base station 106 discards the secure packet. Furthermore, if the secure packet is both encrypted and integrity protected, the encrypted and integrity protected packet may contain an encrypted packet along with an encrypted MAC-I. In this case, base station 106 decrypts the encrypted packet and the encrypted MAC-I to obtain the data and MAC-I. Base station 106 then determines whether the MAC-I is valid for the data. If base station 106 determines that the MAC-I is valid, base station 106 retrieves the data and forwards it to CN110. However, if base station 106 determines that the MAC-I is invalid, base station 106 discards the packet.

[0033] In other scenarios and embodiments, base station 104 can extract the UE ID of UE102 from the UL RRC message and identify that base station 104 stores the UE context information of UE102. Thus, base station 104 extracts a secure packet from the first UL PDU as described above, extracts data from the secure packet, and transmits the data to CN110 or the edge server.

[0034] Furthermore, in some cases, RAN105 transmits data in the downlink (DL) direction to UE102, which operates in either the RRC_INACTIVE or RRC_IDLE state.

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

[0036] In another embodiment, base station 104 transmits a first DL PDU to base station 106, which then generates a second PDU (e.g., a DL MAC PDU) containing the first DL PDU and transmits the second DL PDU to UE 102 without first transitioning UE 102 from the RRC_INACTIVE or RRC_IDLE state to the RRC_CONNECTED state. In some embodiments, base station 106 generates a DL RLC PDU containing the first DL PDU and includes the DL RLC PDU in the second DL PDU. In yet another embodiment, base station 104 includes the first DL PDU in the DL RLC PDU and transmits the DL RLC PDU to base station 106, which then generates a second DL PDU (e.g., a DL MAC PDU) containing the DL RLC PDU and transmits the second DL PDU to UE 102.

[0037] In some embodiments, a base station (i.e., base station 104 or 106) generates downlink control information (DCI) and cyclic redundancy check (CRC) scrambled with the ID of UE102 and transmits a second DL PDU generated by the base station. In some embodiments, the ID of UE102 may be a radio network temporary identifier (RNTI). For example, the RNTI may be a cell RNTI (C-RNTI), a temporary C-RNTI, or an inactive C-RNTI. The base station transmits the DCI and scrambled CRC to UE102 operating in the RRC_INACTIVE or RRC_IDLE state on the physical downlink control channel (PDCCH). The base station scrambles the CRC with the ID of UE102. In some embodiments, before transmitting the DCI and scrambled CRC, the base station may assign the ID of UE102 to UE102 in a random access response transmitted by the base station in a random access procedure with UE102. In a further embodiment, the base station may assign an ID to UE102 in an RRC message that the base station sends to UE102 (e.g., an RRC release message or an RRC reconfiguration message) before transmitting the DCI and scrambled CRC, for example, while UE102 is in the RRC_CONNECTED state.

[0038] UE102, operating in the RRC_INACTIVE or RRC_IDLE state, can receive the DCI and scrambled CRC on the PDCCH. UE102 then verifies that the Physical Downlink Shared Channel (PDSCH) containing the second DL PDU is addressed to UE102, according to UE102's ID, DCI, and scrambled CRC. UE102 can then extract data from the secure packet. If the secure packet is an encrypted packet, UE102 can decrypt the encrypted packet using the appropriate decryption function and security key to retrieve the data. If the secure packet is an integrity-protected packet containing data and MAC-I, UE102 can determine whether the MAC-I is valid. If UE102 verifies that the MAC-I is valid, UE102 extracts the data. However, if UE102 determines that the MAC-I is invalid, UE102 discards the packet. Finally, when a secure packet is encrypted and its integrity is protected, the UE102 can use the encrypted data and encrypted MAC-I to decrypt the encrypted packet and encrypted MAC-I and retrieve the data and MAC-I. The UE102 can then verify that the MAC-I is valid for the data. If the UE102 confirms that the MAC-I is valid, it retrieves and processes the data. Otherwise, if the UE102 determines that the MAC-I is invalid, it discards the data.

[0039] The base station 104 comprises processing hardware 130 which may include one or more general-purpose processors (e.g., CPUs) and non-temporary computer-readable memory for storing instructions executed by the one or more general-purpose processors. Furthermore, or alternatively, the processing hardware 130 may include special-purpose processing units. In an exemplary embodiment, the processing hardware 130 includes a media access control (MAC) controller 132 configured to perform random access procedures with one or more user devices, receive uplink MAC protocol data units (PDUs) to 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, which allow the base station 104 to transmit data downlink according to DL PDCP PDUs in some scenarios, and to receive UL PDCP PDUs, which allow the base station 104 to receive data uplink according to UL PDCP PDUs in other scenarios. The processing hardware may further include an RRC controller 136 for implementing procedures and messaging in the RRC sublayer of the protocol communication stack. In an exemplary embodiment, the processing hardware 130 includes an RRC inactive controller 138 configured to manage uplink and / or downlink communications with one or more UEs operating in the RRC_INACTIVE or RRC_IDLE state. The base station 106 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 UE102 comprises processing hardware 150 which may include one or more general-purpose processors such as a CPU, non-temporary computer-readable memory for storing machine-readable instructions executable by one or more general-purpose processors, and / or special-purpose processing units. In an exemplary embodiment, the processing hardware 150 includes an RRC inactive controller 158 configured to manage uplink and / or downlink communications when the UE102 is operating in the RRC_INACTIVE state. In an exemplary embodiment, the processing hardware 150 also includes a media access control (MAC) controller 152 configured to perform random access procedures with a base station, send 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 send DL PDCP PDUs that allow the base station 106 to send data downlink according to DL PDCP PDUs in some scenarios, and to receive UL PDCP PDUs that allow the base station 106 to receive data uplink according to UL PDCP PDUs in other scenarios. The processing hardware may further include an RRC controller 156 to implement procedures and messaging in the RRC sublayer of the protocol communication stack.

[0041] Figure 1B shows one or more exemplary distributed or centralized embodiments of base stations 104, 106. In these embodiments, base stations 104, 106 include 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 for storing machine-readable instructions executable on the general-purpose processors, and / or special-purpose processing units. For example, the CU 172 may include PDCP controllers, RRC controllers, and / or RRC inactive controllers such as PDCP controllers 134, 144, RRC controllers 136, 146, and / or RRC inactive controllers 138, 148. In some embodiments, 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 embodiments, the CU 172 does not include an RLC controller.

[0042] Each DU174 also includes processing hardware that may include one or more general-purpose processors (e.g., CPUs), computer-readable memory for storing machine-readable instructions executable on one or more general-purpose processors, and / or special-purpose processing units. For example, the processing hardware may include MAC controllers (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 RLC controllers configured to manage or control one or more RLC operations or procedures. The process hardware may also include physical layer controllers configured to manage or control one or more physical layer operations or procedures.

[0043] In some embodiments, RAN105 supports access backhaul integration (IAB) functionality. In some embodiments, DU174 acts as an IAB node and CU172 acts as an IAB donor.

[0044] In some embodiments, CU172 may include a logical node CU-CP172A that hosts the control plane portion of the CU172's PDCP protocol. CU172 may also include a logical node CU-UP172B that hosts the user plane portion of the CU172's PDCP protocol and / or Service Data Adaptive Protocol (SDAP) protocol. CU-CP172A can transmit control information (e.g., RRC messages, F1 application protocol messages), and CU-UP172B can transmit data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0045] A CU-CP172A can connect to multiple CU-UP172Bs via the E1 interface. The CU-CP172A selects the appropriate CU-UP172B for the service requested by the UE102. In some embodiments, a single CU-UP172B can connect to multiple CU-CP172As via the E1 interface. A CU-CP172A can connect to one or more DU174s via the F1-C interface. A CU-UP172B can connect to one or more DU174s via the F1-U interface under the control of the same CU-CP172A. In some embodiments, a single DU174 can connect to multiple CU-UP172Bs under the control of the same CU-CP172A. In such embodiments, connectivity between the CU-UP172B and DU174 is established by the CU-CP172A using bearer context management functionality.

[0046] Figure 2A shows a simplified exemplary protocol stack 200, which UE102 can use to communicate with an eNB / ng-eNB or gNB (e.g., one or more base stations 104, 106) according to the protocol stack 200.

[0047] In an exemplary stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which then provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208, and in some cases to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides a transport channel to the NR MAC sublayer 204B, which then provides a logical channel 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 the Service Data Adaptive Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer (not shown in Figure 2A). In some embodiments, the UE102 supports both EUTRA and NR stacks, as shown in Figure 2A, supports handover between EUTRA base stations and NR base stations, and / or supports DC via EUTRA and NR interfaces. Furthermore, as shown in Figure 2A, the UE102 can support layering of NR PDCP210 on EUTRA RLC206A and SDAP sublayer212 on NR PDCP sublayer210.

[0048] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 receive packets that may be called Service Data Units (SDUs) (e.g., from the IP layer layered directly or indirectly on PDCP layer 208 or 210) and output packets that may be called Protocol Data Units (PDUs) (e.g., to RLC layer 206A or 206B). Unless the difference between SDUs and PDUs is relevant, for simplicity, both SDUs and PDUs are referred to as “packets” in this disclosure.

[0049] On the control plane, the EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 provide a signal-transmitting radio bearer (SRB) or an RRC sublayer (not shown in Figure 2A) to exchange, for example, RRC messages or non-access layer (NAS) messages. On the user plane, the EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide a data radio bearer (DRB) to support data exchange. The data exchanged in the NR PDCP sublayer 210 may be SDAP PDUs, IP packets, or Ethernet packets.

[0050] Figure 2B shows a simplified exemplary protocol stack 250 that enables UE102 to communicate with DU (e.g., DU174) and CU (e.g., CU172). The radio protocol stack 200 is functionally divided by the radio protocol stack 250 in Figure 2B, as shown. The CU, located in either base station 104 or 106, can hold all control and higher-layer functions (e.g., RRC214, SDAP212, NR PDCP210), while lower-layer operations (e.g., NR RLC206B, NR MAC204B, and NR PHY202B) are delegated to the DU. To support connectivity to 5GC, NR PDCP210 provides SRB to RRC214, NR PDCP210 provides DRB to SDAP212, and NR PDCP210 provides SRB to RRC214.

[0051] Next, several exemplary scenarios relating to sending data in an inactive or idle state, including some components of Figure 1A, are described with reference to Figures 3 and 4. For the sake of simplicity in the following description, the term “inactive state” may refer to the RRC_INACTIVE state or the RRC_IDLE state, and the term “connected state” may refer to the RRC_CONNECTED state.

[0052] Referring first to Figure 3, in Scenario 300, base station 104 includes a central unit (CU) 172 and a distributed unit (DU) 174, where CU 172 includes CU-CP 172A and CU-UP 172B. In this Scenario 300, UE 102 initially operates in a connected state (302), communicates with DU 174 using the DU configuration (i.e., a first non-SDT DU configuration) (304), and communicates with CU-CP 172A and / or CU-UP 172B via DU 174 using the CU configuration (i.e., a first non-SDT CU configuration) (304). While the UE communicates with base station 104 (304), CU-CP 172A can send a UE context correction request message to DU 174 (306). In response, DU174 sends a UE context modification response message to CU-CP172A that includes a non-SDT DU configuration for UE102 (i.e., a non-SDT DU configuration) (308). CU-CP172A generates an RRC reconfiguration message that includes a second non-SDT DU configuration and sends a first CU-to-DU message (e.g., a DL RRC message forwarding message) containing the RRC reconfiguration message to DU174 (310). DU174 then sends the RRC reconfiguration message to UE102 (312). In response, UE102 sends an RRC reconfiguration complete message to DU174 (314), and DU174 then sends a first DU-to-CU message (e.g., a UL RRC message forwarding message) containing the RRC reconfiguration complete message to CU-CP172A (316).

[0053] After receiving an RRC reconfiguration message (312), the connected UE102 communicates with DU174 using a second non-SDT DU configuration (318) and communicates with CU-CP172A and / or CU-UP172B via DU174. If the RRC reconfiguration message does not include a CU configuration, UE102 communicates with CU-CP172A and / or CU-UP172B via DU174 using a first non-SDT CU configuration (318). If the RRC reconfiguration message includes a non-SDT CU configuration (i.e., a second non-SDT CU configuration), UE102 communicates with CU-CP172A and / or CU-UP172B via DU174 using a second non-SDT CU configuration (318). In some embodiments, the second non-SDT CU configuration may extend the first non-SDT CU configuration or include at least one new configuration parameter not included in the first non-SDT CU configuration. In such cases, UE102 and CU-CP172A and / or CU-UP172B can communicate with each other using the second non-SDU CU configuration and the configuration parameters in the first non-SDT CU configuration that were not extended by the second non-SDU CU configuration (318). In some embodiments, the first non-SDT CU configuration includes configuration parameters relating to the operation of the RRC and / or PDCP protocol layers (e.g., RRC214 and NR PDCP210) that UE102 and CU172 use to communicate with each other while UE102 is operating in a connected state. Similarly, a second non-SDT CU configuration may include configuration parameters related to the operation of the RRC and / or PDCP protocol layers used by UE102 and CU172 to communicate with each other while UE102 is operating in a connected state. In some embodiments, the first non-SDT CU configuration includes configuration parameters for RadioBearerConfig information elements (IE) and / or MeasConfig IE as defined in 3GPP specification 38.331 V16.7.0. Similarly, a second non-SDT CU configuration includes configuration parameters for RadioBearerConfig IE and / or MeasConfig IE as defined in 3GPP specification 38.331 V16.7.0.In some embodiments, the first non-SDT CU configuration may be or include configuration parameters of RadioBearerConfig IE and MeasConfig IE, and the second non-SDT CU configuration may be or include RadioBearerConfig IE and / or MeasConfig IE.

[0054] In some embodiments, the second non-SDT DU configuration may extend the first non-SDT DU configuration or include at least one new configuration parameter not included in the first non-SDT DU configuration. In such cases, UE102 and DU174 can communicate with each other using the second non-SDT DU configuration and the configuration parameters of the first non-SDT DU configuration that were not extended by the second non-SDT DU configuration (318). In some embodiments, the first non-SDT DU configuration includes configuration parameters relating to the operation of the RRC, RLC, MAC, and / or PHY protocol layers (e.g., RLC206B, MAC204B, and / or PHY202B) that UE102 and DU174 use to communicate with each other while UE102 is operating in a connected state. Similarly, the second non-SDT DU configuration may include configuration parameters relating to the operation of the RRC, RLC, MAC, and / or PHY protocol layers that UE102 and DU174 use to communicate with each other while UE102 is operating in a connected state. In some embodiments, the first non-SDT DU configuration includes configuration parameters of the CellGroupConfig IE as defined in 3GPP specification 38.331 V16.7.0. Similarly, the second non-SDT DU configuration includes configuration parameters of the CellGroupConfig IE as defined in 3GPP specification 38.331 V16.7.0. In some embodiments, the first and second non-SDT DU configurations are the CellGroupConfig IE.

[0055] Events 306, 308, 310, 312, 314, 316, and 318 are collectively referred to as the non-SDT resource (re)configuration procedure 390 in Figure 3, which may be optional.

[0056] While UE102 is communicating with base station 104, or (if performed) after the non-SDT resource (re)configuration procedure 390, CU-CP172A may decide to transition UE102 from an inactive state to a connected state based on UE102's data inactive state (i.e., based on the fact that UE102 in a connected state has no data activity with base station 104). In some embodiments, while UE102 is communicating with base station 104, or (if performed) after the non-SDT resource (re)configuration procedure 390, UE102 determines or detects a data inactive state and sends UE assistance information (e.g., a UEAssistanceInformation message) to DU174 indicating that UE102 prefers or requests to transition to an inactive state with SDT configured (320). DU174 then sends a UL RRC message forwarding message containing the UE assistance information to CU-CP172A (321). Therefore, CU-CP172A can determine that UE102 is in a data inactive state based on UE support information. In other embodiments, DU174 can perform data inactive state monitoring for UE102. CU-CP172A can request or instruct DU174 to perform, for example, data inactive state monitoring by sending a CU-to-DU message (e.g., a UE context setup request message or a UE context modification request message) to DU174. If DU174 detects or determines during monitoring that UE102 is in a data inactive state, DU174 can send an inactive state notification (e.g., a UE inactive state notification message) to CU-CP172A (322). Therefore, CU-CP172A can determine that UE102 is in a data inactive state based on the inactive state notification received from DU174. In yet another embodiment, CU-UP172B can perform data inactive state monitoring for UE102.CU-CP172A can send a message from CP to UP (e.g., a bearer context setup request message or a bearer context modification request message) to CU-UP172B to request or instruct CU-UP172B to perform, for example, data inactive state monitoring. If CU-UP172B detects or determines during monitoring that UE102 is in a data inactive state, CU-UP172B can send an inactive state notification (e.g., a bearer context inactive state notification message) to CU-CP172A (323). Thus, CU-CP172A can determine that UE102 is in a data inactive state based on the inactive state notification received from CU-UP172B. In some embodiments, CU-CP172A can determine that UE102 is in a data inactive state based on any combination of UE support information, the inactive state notification of event 322, and / or the inactive state notification of event 323.

[0057] After a specific period of data inactivity, CU-CP172A may determine that CU172 and UE102 did not transmit any data in the downlink or uplink direction, respectively, during that period (for example, using one of the techniques described above for determining the UE inactivity state). In response to this determination, CU-CP172A may decide to transition UE102 to the inactive state configured by SDT. Alternatively, CU-CP172A may decide to immediately transition UE102 to the inactive state configured by SDT, in response to the determination that UE102 is in a data inactivity state, regardless of whether CU172 transmitted data in the downlink direction during any specific period.

[0058] In response to determining that UE102 is in a data inactive state (for a specific period of time), or after such determination, or otherwise in response to SDT deciding to transition UE102 to a configured inactive state, CU-CP172A sends a bearer context correction request message to CP-CU172B (324) and suspends data transmission from UE102. In response, CU-UP172B suspends data transmission from UE102 and sends a bearer context correction response message to CU-CP172A (326). Furthermore, in response to or after determining that UE102 is in a data inactive state (for a specific period of time), or otherwise in response to SDT deciding to transition UE102 to a configured inactive state, CU-CP172A sends a second CU-to-DU message (e.g., a UE context correction request message) (328) instructing DU174 to provide (i.e., request from DU174) an SDT DU configuration for UE102. In some embodiments, CU-CP172A may include an SDT request indication (e.g., a field or IE) for requesting an SDT DU configuration in the second CU-to-DU message. In response to the SDT request indication or the second CU-to-DU message, DU174 sends a second DU-to-CU message (e.g., a UE context correction response message) containing the first SDT DU configuration to CU-CP172A (330). Instead, DU174 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 sending the second DU-to-CU message (event 330), DU174 instead sends another DU-to-CU message (e.g., a UE context correction request message) that includes the first SDT DU configuration to CU-CP172A.In some alternative embodiments, CU-CP172A may send a second CU-to-DU message and receive a second DU-to-CU message (or receive the alternative DU-to-CU messages described above) before determining that UE102 is in a data inactive state. In other alternative embodiments, CU-CP172A may include an SDT request indication in the first CU-to-DU message of event 308, and DU174 may include a 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 the SDT's decision to transition UE102 to an inactive state, CU-CP172A can generate an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to transition UE102 to the inactive state. CU-CP172A may include a first SDT DU configuration and a first SDT CU configuration in the RRC release message. CU-CP172A then sends a third CU-to-DU message (e.g., a UE context release command message or a UE context modification request message) containing the RRC release message to DU174 (332). DU174 then sends the RRC release message to UE102 (334). The RRC release message instructs UE102 to transition to an inactive state. Upon receiving the RRC release message, UE102 transitions from the connected state to the inactive state (336). In response to a third CU-to-DU message, DU174 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 a third CU-to-DU message, DU174 may send a third DU-to-CU message (e.g., a UE context release complete message or a UE context modification response message) to CU-CP172A.

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

[0061] In some embodiments, UE102 responds to an RRC release message by releasing 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 other embodiments, when an RRC release message instructs UE102 to transition to an inactive state (i.e., RRC_IDLE), UE102 releases the first non-SDT DU configuration and / or the second non-SDT configuration. In yet another embodiment, when an RRC release message instructs UE to transition to an inactive state (i.e., RRC_INACTIVE), UE102 releases the first portion of the first and / or second non-SDT DU configuration and retains the second portion of the first and / or second non-SDT DU configuration.

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

[0063] In some embodiments, the first SDT CU configuration includes a DRB list (e.g., std-DRB list) containing a list of DRB IDs(or IDs) indicating the IDs(or IDs) of the DRB(or IDs) configured for the SDT. In some embodiments, the first SDT CU configuration may include an SRB2 indicator (e.g., sdt-SRB2 indicator) indicating the SRB(or IDs) configured for the SDT. In some embodiments, the first SDT CU configuration may include a Compression Protocol Continue indicator (e.g., sdt-DRB-ContinueROHC) indicating whether the PDCP entities of the DRB(or IDs) configured for the SDT should continue during the SDT operation (i.e., the initial and / or subsequent SDT as described in Figure 4). In some embodiments, the SDT CU configuration may include a Data Volume Threshold (e.g., sdt-DataVolumeThreshold) for the UE102 to determine whether it can initiate the SDT.

[0064] In some embodiments, the first SDT DU configuration may include at least one common SDT configuration for CG-SDT, at least one RA-SDT configuration, and / or at least one CG-SDT configuration. For example, at least one common SDT configuration may include a buffer status report (BSR) configuration and / or a power headroom report (PHR) configuration. In another example, at least one RA-SDT configuration may include random access configuration parameters for two-step and / or four-step random access procedures. In yet another example, at least one CG-SDT configuration may include a setting grant configuration for CG-SDT, a time alignment timer value for CG-SDT, and / or a timing advance validity threshold. DU174 configures the timing advance validity threshold for UE102 so that UE102 can perform SDT using the setting grant configuration for CG-SDT. According to the timing advance validity threshold, UE102 can evaluate whether the stored timing advance value is still valid. If UE102 determines that the stored timing advance value is invalid, UE102 can perform RA-SDT with CU172 via DU174, as illustrated in Figure 4.

[0065] If DU174 provides a CG-SDT configuration to CU-CP172A in event 330, DU174 retains the radio resources configured by at least the CG-SDT configuration while retaining the first SDT DU configuration. In some embodiments, DU174 releases the radio resources configured by the CG-SDT configuration when it releases the first SDT DU configuration or the CG-SDT configuration. If DU174 does not provide a CG-SDT configuration to CU-CP172A, DU174 releases all relevant signaling and user data transport resources for UE102 in response to a message from the third CU to the DU. If DU174 provides a CG-SDT configuration to CU-CP172A, DU174 retains all relevant signaling and user data transport resources for UE102 in response to receiving, or after receiving, the message from the third CU to the DU.

[0066] If the first SDT DU configuration does not include a configuration for CG-SDT, then CU-CP172A and / or DU174 simply configure RA-SDT for UE102. In such a case, UE102 can perform RA-SDT with CU172 via DU174, as illustrated in Figure 4.

[0067] In some embodiments, CU-CP172A may not require DU174 to provide an SDT DU configuration to transition the inactive state UE102 with an SDT configured. In such cases, events 328 and 330 may be omitted, and CU-CP172A may not include the SDT DU configuration in the RRC release message. Alternatively, CU-CP172A may generate a first SDT DU configuration on its own without requiring DU174 to provide an SDT DU configuration, and include the first SDT DU configuration in the RRC release message.

[0068] In some embodiments, DU174 may not include an SDT DU configuration in the second DU-to-CU message, for example, because UE102 does not support or does not support CG-SDT, DU174 does not support or does not support CG-SDT, or DU174 does not have available radio resources for CG-SDT. In such cases, the RRC release message does not include an SDT DU configuration. Otherwise, DU174 may include a first SDT DU configuration as described above. In some embodiments, DU174 may not include a CG-SDT configuration in the first SDT DU configuration of the second DU-to-CU message, for example, because UE102 does not support or does not support CG-SDT, DU174 does not support or does not support CG-SDT, or DU174 does not have available radio resources for CG-SDT. In such cases, the first SDT DU configuration does not include a CG-SDT configuration. Otherwise, DU174 may include at least one CG-SDT configuration in the first SDT DU configuration as described above.

[0069] In some embodiments, if UE102 supports CG-SDT and / or DU174 supports CG-SDT, CU-CP172A may require DU174 to provide the SDT DU configuration as described above. If UE102 does not support CG-SDT, or if DU174 does not support CG-SDT, CU-CP172A does not require DU174 to provide the SDT DU configuration. While the UE is operating in a connected state (302), CU-CP172A can receive UE capabilities of UE102 (e.g., UE-NR capability IE) from UE102, CN110 (e.g., MME114 or AMF164), or base station 106. UE capability indicates whether UE102 supports CG-SDT. Thus, CU-CP172A can determine whether the UE supports CG-SDT according to its capabilities. In some embodiments, CU-CP172A can receive a DU-to-CU message from DU174 indicating whether DU174 supports CG-SDT. The DU-to-CU message may be a second DU-to-CU message, a message for event 308 or 316, or a non-UE related message (e.g., a non-UE related F1AP message as defined in 3GPP specification 38.473).

[0070] In some embodiments, DU174 may determine whether to provide the UE102's SDT DU configuration to CU-CP172A based on whether UE102 supports CG-SDT. In addition to whether UE102 supports CG-SDT, DU174 may further determine whether to provide the UE102's SDT DU configuration to CU-CP172A based on whether DU174 supports CG-SDT. If UE102 supports CG-SDT and / or DU174 supports CG-SDT, DU174 provides the UE102's first SDT DU configuration to CU-CP172A as described above. If UE102 does not support CG-SDT, or if DU174 does not support CG-SDT, DU174 does not provide the UE102 with an SDT DU configuration (for example, DU174 does not include the first SDT DU configuration in the second DU-to-CU message). While the UE operates in a connected or inactive state prior to event 302 (302), DU174 can receive UE capability from CU-CP172A. Thus, DU174 can determine whether the UE supports CG-SDT according to its UE capability. In some embodiments, DU174 can send a DU-to-CU message to CU-CP172A to indicate whether DU174 supports CG-SDT, as described above.

[0071] Referring here to Figure 4, Scenario 400 shows a small data transmission. In Scenario 400, base station 104 includes CU172 and DU174. CU172 includes CU-CP172A and CU-UP172B. In Scenario 400, UE102 initially operates in an inactive state with SDT configured (402). In some embodiments or scenarios, prior to the events shown in Figure 4, UE102 can transition from a connected state to an inactive state with SDT configured, as described in Figure 3 (i.e., event 402 can follow event 336). In other embodiments or scenarios, prior to the events shown in Figure 4, UE102 can transition from an inactive state without SDT configured to an inactive state with SDT configured. For example, UE102 receives an RRC release message from a base station (e.g., base station 104 or base station 106) that causes UE102 to transition to an inactive state and does not include SDT configuration. In this case, UE102 responds to the RRC release message by transitioning to an inactive state with the SDT not configured. In an inactive state with the SDT configured or not configured, UE102 can perform RAN notification area (RNA) updates with the base station without a state transition. During the RNA update, UE102 receives another RRC release message from the base station, including a first SDT CU configuration and / or a first SDT DU configuration, similar to the RRC release message for event 334.

[0072] Later, UE102, operating in an inactive state with SDT configured, starts SDT. In response to or after SDT has been started, UE102 generates an initial UL MAC PDU containing the UL RRC message and sends the initial UL MAC PDU to DU174 on cell 124 (404). UE102 may start the SDT timer in response to SDT being started. DU174 extracts the UL RRC message from the initial UL MAC PDU, generates a first DU-to-CU message containing the UL RRC message, and sends the first DU-to-CU message to CU-CP172A (406). In some embodiments, the first DU-to-CU message may be an initial UL RRC message forwarding message. In other embodiments, the first DU-to-CU message may be a UL RRC message forwarding message.

[0073] In a scenario where UE102 initiates SDT to send UL data (e.g., data packets) that qualify for SDT, UE102 includes the UL data in the initial (404) UL MAC PDU that UE102 transmits. In a scenario where UE102 initiates SDT to receive DL data, UE102 does not include the UL data packets in the initial (404) UL MAC PDU that UE102 transmits. UE102 may initiate SDT to receive DL data in response to receiving paging from DU174. In such a scenario, UE102 may indicate to base station 104 that UE102 is initiating SDT to receive DL data by including an SDT indication in the initial UL MAC PDU or UL RRC message.

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

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

[0076] In a further embodiment, UE102 may transmit a UL MAC PDU on a radio resource configured with a Setting Grant (CG) configuration for SDT (404) when UE102 receives a CG-SDT configuration, as described with respect to Figure 3. Thus, DU174 receives a UL MAC PDU on the radio resource (404). In such an embodiment, UE102 may transmit a subsequent UL MAC PDU (possibly multiple) containing one or more UL data packets as described below (in event 418) on the radio resource configured with the CG configuration.

[0077] If UE102 includes UL data in the initial UL MAC PDU, DU174 retrieves the UL data from the initial UL MAC PDU. In such a case, DU174 may include the UL data in the DU-to-CU message of event 406. Alternatively, DU174 may separately send the UL data to CU-CP172A 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 forwarding message. In yet another alternative, DU174 may separately send the UL data to CU-UP172B via a user plane (UP) connection (416) (i.e., event 416), as described below. After receiving the first DU-to-CU message (406), in some embodiments, CU-CP172A may establish the UE context for UE102 in DU174 by sending a UE context setup request message to DU174 (408). In the UE context setup request message, CU-CP172A may include transport layer information for one or more GTP-U tunnels between CU-UP172B and DU174 so that DU174 can transmit UL data and / or subsequent UL data to CU-UP172B via one or more GTP-U tunnels (e.g., in small data communication 418). In response, DU174 may send a UE context setup response message to CU-CP172A (410). After receiving the first message from DU to CU (406), sending the UE context setup request message (408), and / or receiving the UE context setup response message (410), CU-CP172A may send a bearer context correction request message to CU-UP172B to resume data transmission of UE102 (412). In response, CU-UP172B resumes data transmission from UE102 and sends a bearer context correction response message to CU-CP172A (414).After receiving a UE context setup request message (408) and / or sending a UE context setup response message (410), DU174 may send a DU-to-CU message containing the UL data to CU-CP172A (415) 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, DU174 may send the UL data packet to CU-UP172B (416) via one or more GTP-U tunnels.

[0078] In some embodiments, CU-CP172A may include transport layer information for CU-UP172B in the UE context setup request message. The transport layer information for CU-UP172B may include an IP address and / or an uplink tunnel endpoint ID (e.g., TEID). DU174 may use the transport layer information for CU-UP172B to send UL data to CU-UP172B (416). If UE102 has subsequent UL data to send (e.g., one or more UL data packets), UE102 may send one or more subsequent UL MAC PDUs containing the subsequent UL data to DU174 (in event 418). DU174 then retrieves the subsequent UL data from the subsequent UL MAC PDU(s). If subsequent UL data is associated with one or more SRBs (e.g., SRB1 and / or SRB2), DU174 sends one or more DU-to-CU messages containing the subsequent UL data to CU-CP172A (418). Each DU-to-CU message may contain specific UL data packets of the subsequent UL data. If subsequent UL data is associated with one or more DRBs, DU174 sends the subsequent UL data to CU-UP172B (in event 418). In some embodiments, DU174 may include DU transport layer information of DU174 in a UE context setup response message. CU-CP172A may then include DU174's transport layer information in a bearer context modification request message. DU174's transport layer information may include an IP address and / or downlink TEID. When CU-UP172B receives DL data from CN110 or an edge server, CU-UP172B may use the transport layer information of DU174 to send DL data (e.g., one or more DL data packets) to DU174 (418). DU174 then sends one or more DL MAC PDUs containing the DL data to UE102, which is operating in an inactive state (in event 418).In some embodiments, UE102 may include a buffer status report and / or a power headroom report in subsequent UL MAC PDUs, for example, according to the BSR configuration and / or PHR configuration, respectively. In the buffer status report, UE102 may include or indicate the buffer status for one or more logical channels or logical channel groups. In the power headroom report, UE102 may include or indicate the power headroom status or value.

[0079] In some exemplary scenarios, the (subsequent) UL data and / or DL ​​data described above include IP packets(or more), Ethernet packets(or more), or application packets(or more). In other scenarios, the UL data includes PDU(or more) containing RRC messages(or more), NAS messages(or more), IP packets(or more), Ethernet packets(or more), or application packets(or more) (e.g., RRC PDU(or more), PDCP PDU(or more), or RLC PDU(or more)).

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

[0081] In some embodiments, the UL RRC message is an (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 can an existing RRC resume request message. For example, a new RRC resume request message may be defined in a future 3GPP standard document. The new RRC resume request message may be in the same format as an existing RRC resume request message. For downlink SDT, the UL RRC message may be a field element or an information element (IE) (e.g., resumeCause or ResumeCause), or may include an SDT indication. In some embodiments, the UL RRC message is a Common Control Channel (CCCH) message.

[0082] After UE102 has transmitted a UL MAC PDU (404) or communicated subsequent UL data and / or DL ​​data with DU174 (418), CU-CP172A may decide to stop UE102's SDT based on UE102's data inactive state (i.e., UE102 in an inactive state has no data activity with base station 104). For example, after UE102 has transmitted a UL MAC PDU (404) or communicated subsequent UL data and / or DL ​​data with DU174 (418), the inactive UE102 may determine or detect a data inactive state and send UE assistance information (e.g., a UEAssistanceInformation message) to DU174 indicating that UE102 prefers or requests that SDT be stopped (420). DU174 then sends a UL RRC message forwarding message containing the UE assistance information to CU-CP172A (421). Therefore, CU-CP172A can determine that UE102 is in a data inactive state based on UE support information. In other embodiments, DU174 can perform data inactive state monitoring for UE102. For example, CU-CP172A can request or instruct DU174 to perform data inactive state monitoring by sending a CU-to-DU message to DU174 (e.g., a UE context setup request message or a UE context modification request message for event 408). If DU174 detects or determines during monitoring that UE102 is in a data inactive state, DU174 can send an inactive state notification (e.g., a UE inactive state notification message) to CU-CP172A (422). Therefore, CU-CP172A can determine that UE102 is in a data inactive state based on the inactive state notification received from DU174. In yet another embodiment, CU-UP172B can perform data inactive state monitoring for UE102. For example, CU-CP172A can send a message from CP to UP to CU-UP172B, requesting or instructing CU-UP172B to perform data inactivity monitoring.In some embodiments, the message from CP to UP may be a bearer context setup request message or a bearer context modification request message before UE102 initiates SDT. In other embodiments, the message from CP to UP may be a bearer context modification request message during SDT (e.g., event 412). If CU-UP172B detects or determines during monitoring that UE102 is in a data inactive state, CU-UP172B may send an inactive state notification (e.g., a bearer context inactive state notification message) to CU-CP172A (423). Thus, CU-CP172A can determine that UE102 is in a data inactive state based on the inactive state notification received from CU-UP172B. In some embodiments, CU-CP172A can determine that UE102 is in a data inactive state based on any combination of UE support information, the inactive state notification of event 422, and / or the inactive state notification of event 423.

[0083] After a specific period of data inactivity, CU-CP172A may determine that neither CU172 nor UE102 transmitted any data in the downlink or uplink direction, respectively, during that period (for example, using one of the techniques described above for determining the UE inactivity state). In response to this determination, CU-CP172A may decide to stop SDT. Alternatively, CU-CP172A may decide to immediately stop SDT for UE102 in response to the determination that UE102 is in a data inactivity state, regardless of whether CU172 transmitted data in the downlink direction during any specific period.

[0084] In response to, or after determining that UE102 is in a data inactive state (for a specific period of time), or otherwise in response to, or after determining that SDT should be stopped, CU-CP172A sends a bearer context correction request message to CP-CU172B (424) to suspend data transmission from UE102. In response, CU-UP172B suspends data transmission from UE102 and sends a bearer context correction response message to CU-CP172A (426). Also in response to, or after determining that UE102 is in a data inactive state (for a specific period of time), or otherwise in response to, or after determining that SDT should be stopped, CU-CP172A sends a second CU-to-DU message (e.g., a UE context correction request message) (428) instructing DU174 to provide (i.e., request from DU174) an SDT DU configuration for UE102. In some embodiments, CU-CP172A may include an SDT request indication (e.g., a field or IE) in the second CU-to-DU message to request an SDT DU configuration. In response to the SDT request indication or the second CU-to-DU message, DU174 sends a second DU-to-CU message (e.g., a UE context correction response message) containing the second SDT DU configuration to CU-CP172A (430). Alternatively, DU174 may not include an SDT DU configuration in the second DU-to-CU message, and after receiving the second CU-to-DU message (event 428) and / or after sending the second DU-to-CU message (event 430), DU174 may instead send another DU-to-CU message (e.g., a UE context correction request message) containing the second SDT DU configuration to CU-CP172A. In some alternative embodiments, CU-CP172A may send a second CU-to-DU message and receive a second DU-to-CU message (or receive the alternative DU-to-CU messages described above) before determining that UE102 is in a data inactive state.

[0085] In response to the decision to stop the SDT, CU-CP172A can stop the SDT while keeping UE102 in an inactive state by generating an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelase message). CU-CP172A may include the SDT DU configuration (if requested and received) and the SDT CU configuration in the RRC release message. CU-CP172A then sends a third CU-to-DU message containing the RRC release message (e.g., a UE context release command message or a UE context modification request message) to DU174 (432). DU174 then sends the RRC release message to UE102 (434). Upon receiving the RRC release message, UE102 stops the SDT and remains in an inactive state. In response to or after stopping the SDT, UE102 may stop the SDT timer, stop monitoring the PDCCH for the SDT, and / or release the C-RNTI that UE102 uses to monitor the PDCCH for the SDT. Alternatively, UE102 retains the C-RNTI. In response to a third CU-to-DU message, DU174 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 relation to Figure 3. In response to a third CU-to-DU message, DU174 may send a third DU-to-CU message (e.g., a UE context release complete message or a UE context modification response message) to CU-CP172A. In some embodiments, if an RRC release message instructs UE102 to transition to an inactive state (specifically, RRC_IDLE), UE102 transitions to the RRC_IDLE state and releases non-SDT configurations (e.g., the first non-SDT DU configuration, the first non-SDT CU configuration, the second non-SDT DU configuration, and / or the second non-SDT CU configuration as described in Figure 3) and at least one SDT configuration (e.g., the first SDT DU configuration and / or the first SDT CU configuration as described in Figure 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, UE102 can perform another small data transmission procedure with base station 104 or base station 106, similar to procedure 490.

[0087] In some embodiments, CU-CP172A may not require DU174 to provide an SDT DU configuration. In such cases, events 428 and 430 may be omitted, and CU-CP172A may not include an SDT DU configuration in the RRC release message. Instead, CU-CP172A may generate a second SDT DU configuration on its own and include the second SDT DU configuration in the RRC release message.

[0088] In some embodiments, DU174 may not include an SDT DU configuration in the second DU-to-CU message for reasons such as UE102 not supporting or not supporting CG-SDT, DU174 not supporting or not supporting CG-SDT, or DU174 not having or having available radio resources for CG-SDT. In such cases, the RRC release message does not include an SDT DU configuration. Otherwise, DU174 may include a second SDT DU configuration as described above. In some embodiments, DU174 may not include a CG-SDT configuration in the second SDT DU configuration of the second DU-to-CU message for reasons such as UE102 not supporting or not supporting CG-SDT, DU174 not supporting or not supporting CG-SDT, or DU174 not having or having available radio resources for CG-SDT. In such cases, the second SDT DU configuration does not include a CG-SDT configuration. Otherwise, DU174 may include at least one CG-SDT configuration in the second SDT DU configuration as described above.

[0089] In some embodiments, if UE102 supports CG-SDT and / or DU174 supports CG-SDT, CU-CP172A may require DU174 to provide the SDT DU configuration as described above. If UE102 does not support CG-SDT, or if DU174 does not support CG-SDT, CU-CP172A does not require DU174 to provide the SDT DU configuration. CU-CP172A can receive the UE capability of UE102 (e.g., UE-NR-Capability IE) from UE102, CN110 (e.g., MME114 or AMF164), or base station 106 before UE102 initiates SDT, while UE102 is operating in an inactive state (402), while UE102 is performing SDT (e.g., in a UE context setup request message in event 408, or a CU-to-DU message in event 428), or while UE102 is operating in a connected state as described in Figure 3. The UE capability indicates whether UE102 supports CG-SDT. Thus, CU-CP172A can determine whether UE102 supports CG-SDT according to its UE capability. In some embodiments, CU-CP172A can receive a DU-to-CU message from DU174 indicating whether DU174 supports CG-SDT. A message from a DU to a CU may be a second message from a DU to a CU, a message for event 308 or 316, or a non-UE related message (e.g., a non-UE related F1AP message as defined in 3GPP specification 38.473).

[0090] In some embodiments, DU174 may determine whether to provide the UE102's SDT DU configuration to CU-CP172A based on whether UE102 supports CG-SDT. In addition to whether UE102 supports CG-SDT, DU174 may further determine whether to provide the UE102's SDT DU configuration to CU-CP172A based on whether DU174 supports CG-SDT. If UE102 supports CG-SDT, and / or DU174 supports or enables CG-SDT, DU174 provides the UE102's second SDT DU configuration to CU-CP172A as described above. If UE102 does not support CG-SDT, or if DU174 does not support CG-SDT, DU174 does not provide the UE102 with an SDT DU configuration (for example, DU174 does not include the second SDT DU configuration in the second DU-to-CU message). For example, while UE102 is operating in a connected or inactive state, DU174 can receive UE capability from CU-CP172A. Thus, DU174 can determine whether UE102 supports CG-SDT according to its UE capability. In some embodiments, DU174 can send a DU-to-CU message to CU-CP172A to indicate whether DU174 supports CG-SDT, as described above.

[0091] Referring to Figure 5, Scenario 500 shows the transition from SDT to non-SDT and SDT. In Scenario 500, base station 104 includes CU172 and DU174. CU172 includes CU-CP172A and CU-UP172B. In Scenario 500, UE102 initially operates in an inactive state with SDT configured, similar to event 402 (502). UE102 then performs the SDT procedure with base station 104, similar to event 494 (594).

[0092] During the SDT procedure 594, CU-CP172A can decide whether to transition UE102 to the connected state, for example, based on UE102's UL data activity or DL ​​data activity. In some embodiments, UE102 may send a non-SDT request message to DU174 to request to transition to the connected state and / or to indicate that UL data for non-SDT is available (504). DU174 then sends a UL RRC message transfer message to CU-CP172A containing the non-SDT request message (506). CU-CP172A can decide to transition UE102 to the connected state based on the non-SDT request message (for example, in response to the non-SDT request message). In other embodiments, CU-UP172B receives DL data from CN110 and, in response, sends a DL data notification (for example, a DL data notification message) to CU-CP172A (507) to indicate that DL data is available for transmission to UE102. The CU-CP172A may decide to transition the UE102 to a connected state based on DL data notification (for example, in response to DL data notification). In yet another embodiment and / or scenario, the CU-CP172A may decide to transition the UE102 to a connected state based on measurement results received from the UE102. In yet another embodiment and / or scenario, the CU-CP172A may receive DL data (for example, NAS messages) from the CN110 and decide to transition the UE102 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 (e.g., a UEAssistanceInformation message or a new / dedicated RRC message).

[0094] In some embodiments, UL data is associated with a wireless bearer(s) (e.g., SRB(s) and / or DRB(s)). For example, UL data may include RRC messages(s) or NAS messages(s) associated with an SRB(s). In another example, UL data may include IP packets(s) associated with a DRB(s). In some embodiments, UE102 may include the ID(s) of the wireless bearer(s) in the non-SDT request message. Thus, CU-CP172A can decide whether to transition UE102 to the connected state based on the ID(s). For example, if the ID(s) include a specific ID(s), CU-CP172A can decide to transition UE102 to the connected state. Otherwise, CU-CP172A can decide not to transition UE102 to the connected state. In some embodiments, UE102 may include data volume information of the UL data in the non-SDT request message of event 504. Therefore, CU-CP172A can determine whether to transition UE102 to a connected state based on data volume information. In one embodiment, the data volume information includes the total data volume of UL data. For example, UE102 can quantify the total data volume or round it to a value that UE102 will next include in the data volume information. In another embodiment, the data volume information includes the data volume of each wireless bearer. For example, UE102 can quantify the data volume of each wireless bearer or round it to a value that UE102 will next include in the data volume information. In some embodiments and / or scenarios, if the total data volume exceeds a predetermined threshold, CU-CP172A can decide to transition UE102 to a connected state. Otherwise, CU-CP172A can decide not to transition UE102 to a connected state. In another example, if the data volume of a particular wireless bearer exceeds a predetermined threshold, CU-CP172A can decide to transition UE102 to a connected state. Otherwise, the CU-CP172A can decide not to transition the UE102 to a connected state.In yet another example, if the total data volume exceeds a predetermined threshold, and the data volume of a particular wireless bearer exceeds another predetermined threshold, the CU-CP172A may decide to transition the UE102 to a connected state. Otherwise, the CU-CP172A may decide not to transition the UE102 to a connected state.

[0095] After deciding to transition UE102 to a connected state (for example, in response to that decision), CU-CP172A sends a UE context request message (for example, a UE context setup request message or a UE context modification request message) to DU174 (508). In response, DU174 sends a UE context response message to CU-CP172A (510). In some embodiments, DU174 may 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, CU-CP172A sends a CU-to-DU message to DU174 that includes an RRC resume message (for example, an RRCResume message or an RRCConnectionResume message) (512). DU174 then sends the RRC resume message to UE102 (514). In response, UE102 transitions to a connected state (516) and sends an RRC resume complete message (e.g., an RRCResumeComplete message or an RRCConnectionResumeComplete message) to DU174 (518). If the UE context response message includes a non-SDT DU configuration, CU-CP172A includes the non-SDT DU configuration in the RRC resume message. DU174 sends a DU-to-CU message to CU-CP172A that includes the RRC resume complete message (520). After deciding to transition UE102 to a connected state, CU-CP172A may send a bearer context request message (e.g., a bearer context setup request message or a bearer context modification request message) to CU-UP172B (522) to indicate that CU-UP172B will resume all radio bearers that were suspended for UE102. In response, CU-UP172B resumes all radio bearers that had been paused for UE102 and sends a bearer context response message (e.g., a bearer context setup response message or a bearer context modification response message) to CU CP-172A (524).In some embodiments, CU-CP172A may send a bearer context request message (522) after sending a UE context request message (508), after receiving a UE context response message (510), after sending a message from CU to DU (512), and / or after receiving a CU message from DU (520).

[0096] In some embodiments, CU-CP172A may include an indication in the UE context request message of event 508 that points to DU174 to generate a non-SDT configuration, and DU174, in response to the indication, includes a first non-SDT DU configuration in the UE context response message of event 510. In other embodiments, CU-CP172A stores a non-SDT DU configuration (i.e., a second non-SDT DU configuration) that a DU (e.g., DU174 or another DU or base station) used to communicate with UE102. UE102 may also store a second non-SDT DU configuration. In such a case, CU-CP172A includes the second non-SDT DU configuration in the UE context request message, and DU174, in response to receiving the second non-SDT DU configuration, may include the first non-SDT DU configuration in the UE context response message. 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 for event 510, DU174 may send an additional DU-to-CU message (e.g., a UE context correction request message) containing the first non-SDT DU configuration to CU-CP172A.

[0097] After transitioning to a connected state (516), UE102 communicates UL data and / or DL ​​data with CU-CP172A and / or CU-UP172B via DU174 (526). The UL data may include the UL data that triggered the UE to send a non-SDT request message in event 504. The UL data may also include new UL data available for transmission. The DL data may include DL data received by CU172 from CN110 as described above. The DL data may also include new DL data received by CU172 from CN110. If the RRC restart messages in events 512 and 514 include a first non-SDT DU configuration, UE102 communicates with DU174 using the first non-SDT DU configuration (526). If the second non-SDT DU configuration has not completely replaced the first non-SDT DU configuration (i.e., UE102 has not released the second non-SDT DU configuration in response to the RRC restart message), UE102 may communicate with DU174 (526) using the 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, DU174 may not provide the first non-SDT DU configuration to CU-CP172A in UE context response messages and additional DU-to-CU messages. In such cases, the RRC restart messages for events 512 and 514 do not include the first non-SDT DU configuration, and UE102 and DU174 communicate with each other using a second non-SDT DU configuration (526).

[0099] Later, CU-CP172A can perform an SDT configuration procedure with UE102, DU174, and CU-CP172B, similar to procedure 392 (592). UE102 transitions to an inactive state in response to receiving the RRC release message in procedure 592 (528). UE102 can then initiate another SDT procedure with base station 104 or base station 106, similar to procedures 494 and / or 594.

[0100] Next, several exemplary methods that can be implemented in a UE or RAN (e.g., one or more base stations, DUs, or CUs) to support data communication in an inactive state are described below with reference to Figures 6 to 12.

[0101] Figure 6 shows a method 600 that can be implemented by a CU (e.g., CU172 or CU-CP172A) for processing information elements of an interface message to obtain an RRC message.

[0102] Method 600 generally involves determining whether the octet string of a message from DU to CU is a PDCP PDU or a UL-CCCH message, based on the SRB identity (ID) of the message from DU to CU. In the exemplary embodiment shown in Figure 6, Method 600 begins in block 602, where the CU receives the message from DU to CU (e.g., events 321, 406, 421, 506, 520). In block 604, the CU extracts the SRB ID and container IE from the message from DU to CU, where the container IE contains the octet string. In 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. In block 608, the CU determines that the octet string is a PDCP PDU. In 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, in block 606, if the CU determines that the SRB ID is zero, 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 encryption and integrity protection for communication with the UE, the CU retrieves, for example, the PDCP sequence number, encrypted data packets, and encrypted MAC-I from the PDCP PDU. The CU also retrieves the encryption algorithm and encryption key (e.g., K RRCene Using the encryption parameters, the encrypted data packet and encrypted MAC-I are decrypted 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 the SRB ID. COUNT may be the COUNT value of the PDCP PDU or encrypted data packet, consisting of the PDCP sequence number and hyperframe number (HFN). DIRECTION may be a 1-bit value, e.g., 0. LENGTH is the length of the encrypted data packet. CU is the integrity algorithm, integrity key (e.g., K RRCint ), and integrity checks can be performed to verify MAC-I using integrity parameters. Integrity parameters may be similar to encryption parameters. If the CU activates integrity protection for communication with the UE without activating encryption, the CU directly performs integrity checks on the data packets extracted from the PDCP PDU, as described above.

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

[0105] Figure 7 shows a method 700 that can be implemented by a DU (e.g., DU174) forwarding UL data packets to a CU (e.g., CU172, or more specifically, CU-CP172A).

[0106] Method 700 generally includes determining whether to send UL data in an early UL RRC message forwarding message or a non-early UL RRC message forwarding message, based on whether the radio resource is a configured grant radio resource. In the exemplary embodiment shown in Figure 7, Method 700 begins in block 702 where the DU receives a UL data packet from the UE via the CCCH (e.g., event 404). In block 704, the DU determines whether the DU receives the UL data packet on a radio resource configured with a configured grant. If the DU determines that the DU receives the UL data packet on a radio resource configured with a configured grant (and therefore the previous F1 interface / connection for the UE between the DU and the CU still exists), the flow proceeds to block 706. In block 706, the DU sends a message from the first DU to the first CU (e.g., a UL RRC message forwarding message) containing the UL data packet (e.g., event 406). Otherwise, if the DU decides to receive a UL data packet on a radio resource configured with a dynamic grant, the flow proceeds to block 708. In block 708, the DU sends a message from the second DU to the second CU containing the UL data packet (e.g., an initial UL RRC message forwarding message, rather than the non-initial UL RRC message forwarding message in block 706) (e.g., event 406).

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

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

[0109] In some embodiments, the DU may include the SRB ID0 in the UL RRC message forwarding message, but not in the initial UL RRC message forwarding message. 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.

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

[0111] Figure 8 shows a method 800 that can be implemented by a CU (e.g., CU172 or CU-CP172A) to transition a UE (e.g., UE102) to a connected state while performing small data communication with a UE operating in an inactive state.

[0112] Method 800 begins in block 802, where the CU communicates with the UE, which is operating in an inactive state, via the DU (e.g., events 404, 406, 418, 494, 594). In block 804, the CU decides to transition the UE to a connected state during data communication. In block 806, the CU responds to the decision by sending a UE context request message to the DU (e.g., event 508). In block 808, in response to the UE context request message, the CU receives a UE context response message from the DU containing a non-SDT DU configuration (e.g., CellGroupConfig IE) (e.g., event 510). In block 810, the CU sends a first message to the UE via the DU containing a non-SDT DU configuration to transition the UE to a connected state (e.g., events 512, 514). In 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 connected UE via the DU (e.g., event 526).

[0113] Figure 9 shows a method 900 that can be implemented by a DU (e.g., DU174) to transition a UE (e.g., UE102) to a connected state while performing small data communication with the UE operating in an inactive state.

[0114] Method 900 begins in block 902, where the DU communicates with the UE, which is operating in an inactive state, using an SDT configuration (e.g., events 404, 418, 494, 594). In block 904, the DU receives a UE context request message from the CU (e.g., event 508). In block 906, in response to the UE context request message, the DU sends a UE context response message to the CU containing a non-SDT DU configuration (e.g., CellGroupConfig IE) (e.g., event 510). In block 908, the DU receives a message from the CU to the DU containing a first message containing a non-SDT DU configuration for the UE (e.g., event 512). In block 910, the DU sends the first message to the UE (e.g., event 514). In block 912, the DU receives a second message from the UE in response to the first message and sends a message from the DU to the CU containing the second message (e.g., events 516, 518). In block 914, the DU communicates with the UE operating in a connected state using a non-SDT DU configuration (e.g., 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, messages from CU to DU and messages from DU to CU may be UL RRC message transfer messages and DL RRC message transfer messages, respectively. In other embodiments, messages from CU to DU and messages from DU to CU may be F1AP messages as defined in 3GPP specification 38.473.

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

[0117] In some embodiments, CUs and UEs operating in an inactive state communicate with each other (via the DU) using SDT CU configurations and non-SDT CU configurations. In some embodiments, the first and second messages are RRC restart messages and RRC restart complete messages, respectively. More specifically, the first and second messages may be DL-DCCH messages and UL-DCCH messages, respectively, containing the RRC restart messages and RRC restart complete messages. In some embodiments, the UE context request message and UE context response message may be UE context modification request messages and UE context modification response messages, respectively. In other embodiments, the UE context request message and UE context response message may be UE context setup request messages and UE context setup response messages, respectively. In some embodiments, the non-SDT DU configuration includes configuration parameters related to the MAC protocol layer (e.g., NR MAC204B) and the PHY protocol layer (e.g., NR PHY202B). After the UE enters a connected state, sends a first message, and / or receives a 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 a UE context request message, the CU may, in some embodiments, include a first indication (e.g., IE) indicating that the DU provides a non-SDT DU configuration or 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., IE) in the UE context request message indicating that the DU provides an SDT DU configuration. In response to a UE context request message that omits 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 send a first message to a DU or UE via a DU, the CU can generate a downlink PDCP PDU containing the first message and send the downlink PDCP PDU to the DU. If the CU activates one or more security features on the UE, the CU can apply one or more security features to the first message as described above to obtain a first secured message and generate a downlink PDCP PDU containing the first secured message. The CU can then send the downlink PDCP PDU to the DU. The DU then generates a downlink RLC PDU containing the downlink PDCP PDU and a downlink MAC PDU containing the logical channel ID (e.g., 1) and the downlink RLC PDU. The DU can then send the downlink MAC PDU to the UE using the SDT configuration. Alternatively, the CU can generate one or more RLC PDU segments to contain the downlink PDCP PDU and generate multiple downlink MAC PDUs, each containing the logical channel ID and a specific RLC PDU segment of one or more RLC PDU segments. The DU can then send a downlink MAC PDU to the UE.

[0120] To send a second message to the DU, the UE can generate an uplink PDCP PDU containing 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 one or more security features applied by the CU) to communicate with the CU, the UE can apply one or more security features to the second message as described above to obtain a second secured message and generate an uplink PDCP PDU containing the second secured message. The UE can then send the uplink PDCP PDU to the DU. More specifically, the UE can generate an uplink RLC PDU containing the uplink PDCP PDU and an uplink MAC PDU containing the logical channel ID (e.g., 1) and the uplink RLC PDU. The UE can then send the uplink MAC PDU to the DU using the SDT configuration.

[0121] In some embodiments, the DU continues to use the SDT configuration to communicate with the UE, for example, data (including downlink MAC PDUs), after generating a non-SDT DU configuration or sending a non-SDT DU configuration to the CU. The DU may stop using the SDT configuration if it receives a message from the CU indicating that the DU is discontinuing its use.

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

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

[0124] In some embodiments, a DU can configure a non-SDT DU configuration to include configuration parameters(s) in the SDT configuration. For example, configuration parameters(s) may include PDCCH configurations, control resource sets, and / or lookup space configurations for the UE to receive control signals, such as downlink control information (DCI), on one or more PDCCHs. Thus, there is no difficult switchover point for the DU to switch from an SDT configuration to a non-SDT DU configuration. In some embodiments, a non-SDT DU configuration includes additional configuration parameters(s) that are not present in the SDT configuration. In some embodiments, a DU can apply or begin applying additional configuration parameters(s) after generating the non-SDT DU configuration and / or after sending the non-SDT DU configuration to the CU. In other embodiments, a DU can apply or begin applying additional configuration parameters(s) before, during, or after sending a downlink MAC PDU(s). For example, a non-SDT DU configuration may include one or more RS configurations (e.g., multiple CSI-RS configurations). The DU may send or initiate transmissions of RS(s) according to the CSI-RS configuration after generating the non-SDT DU configuration or after sending the non-SDT DU configuration to the CU. Alternatively, the DU may send or initiate transmissions of RS(s) according to the CSI-RS configuration before, during, or after sending the downlink MAC PDU(s).

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

[0126] In some embodiments, a CU may include another non-SDT DU configuration (i.e., a second non-SDT DU configuration) in its UE context request message, and the DU uses the second non-SDT DU configuration to communicate with a connected UE before the UE transitions to an inactive state. Similarly, a connected UE communicates with the DU using the second non-SDT DU configuration and communicates with the CU via the DU using a non-SDT CU configuration. The second non-SDT DU configuration includes several configuration parameters related to the protocol layers of RRC, RLC, MAC, and PHY (e.g., RRC214, NR RLC206B, NR MAC204B, and / or NR PHY202B). In some embodiments, the second non-SDT DU configuration may be a CellGroupConfig IE or configuration parameters, or may contain them in a CellGroupConfig IE. In some embodiments, the DU may generate a first non-SDT DU configuration to extend the second non-SDT DU configuration. In such a case, the DU in block 912 may communicate with the connected UE using the configuration parameters of the first non-SDT DU configuration and / or the second non-SDT DU configuration. In other embodiments, the DU may generate the first non-SDT DU configuration to replace the second non-SDT DU configuration. In yet another embodiment, 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 communicates with the connected UE using the second non-SDT DU configuration.

[0127] In some embodiments, after transitioning the UE to a connected state, the CU may instruct the DU to release the SDT DU configuration by sending another CU-to-DU message (i.e., a second CU-to-DU message). In response to the second CU-to-DU message, the DU may 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 may include a release indication that the DU is releasing the SDT DU configuration. In some embodiments, the second CU-to-DU message and the second DU-to-CU message may 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 may be a UE context release command message and a UE context release complete message, respectively.

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

[0129] Method 1000 begins in block 1002 when the base station communicates with the UE operating in an inactive state using an SDT configuration (e.g., events 404, 406, 418, 494, 594). In block 1004, the base station decides to transition the UE to a connected state during data communication. In block 1006, the base station sends a first message to the UE containing a non-SDT configuration (e.g., a non-SDT DU configuration if the base station is a distributed base station) to transition the UE to a connected state (e.g., events 512, 514). In block 1008, the base station receives a second message from the UE in response to the first message (e.g., events 518, 520). In 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 DU and CU functions, and the embodiments and examples described above with respect to Figures 8 and 9 can be applied to method 1000 in 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 restart message, in some embodiments the base station may retain the SDT CU configuration and / or SDT DU configuration of the UE operating in the connected state as described above. If the first message is an RRC setup message, in some embodiments the base station may release the SDT CU configuration and / or SDT DU configuration of the UE operating in the connected state as described above. In such cases, the second message may be an RRC setup complete message.

[0131] Figure 11 shows a method 1100 that can be implemented by a UE (e.g., UE102) to transition to a connected state while the UE is in an inactive state and performing small data communication with a base station.

[0132] Method 1100 begins in block 1102, where the UE communicates with the base station while operating in an inactive state using an SDT configuration (e.g., events 404, 406, 418, 494, 594). In block 1104, the UE receives a first message from the base station, which includes a non-SDT configuration and transitions the UE to a connected state (event 512). In block 1106, the UE sends a second message to the base station in response to the first message (e.g., event 518). In 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 can be applied to method 1100 in 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 restart message, the UE in some embodiments may retain the SDT CU configuration and / or SDT DU configuration while operating in the connected state as described above. If the first message is an RRC setup message (e.g., an RRCSetup message), the UE in some embodiments may release the SDT CU configuration and / or SDT DU configuration while operating in the connected state as described above. In such cases, the second message may be an RRC setup complete message (e.g., an RRCSetupComplete message).

[0134] Figure 12 shows a method 1200 that can be implemented by a DU (e.g., DU174) forwarding UL data packets to a CU (e.g., CU172, CU-CP172A).

[0135] Method 1200 generally involves determining, based on the logical channel, whether to transmit uplink data via the transport network layer protocol stack or in a UL RRC message forwarding message. In the exemplary embodiment shown in Figure 12, Method 1200 begins in block 1202, where the DU receives a UL data packet from the UE. In block 1204, the DU determines whether to receive the UL data packet via the CCCH, the Dedicated Control Channel (DCCH), or the Dedicated Traffic Channel (DTCH). Once the DU has determined that it has received the UL data packet via the CCCH, DCCH, or DTCH, respectively, the flow proceeds to blocks 1206, 1208, or 1210. In block 1206, the flow proceeds to the uplink forwarding procedure 790, which is described in Figure 7. In block 1208, the DU transmits a UL RRC message forwarding message containing the UL data packet to the first or 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 from the UE, which includes a MAC subPDU. The MAC subPDU includes a logical channel ID and an uplink data packet. The logical channel ID identifies the CCCH, DCCH, or DTCH. Thus, the DU can determine, according to the logical channel ID, that the uplink data packet was received via the CCCH, DCCH, or DTCH. In the case of the CCCH, the uplink data packet may be a UL-CCCH message. In the case of the DCCH, the uplink data packet may be a PDCP PDU including a UL-DCCH message and a MAC-I. In the case of the DTCH, the uplink data packet may be a PDCP PDU including an application data packet. In some embodiments, the application data packet may 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 forwarding 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 forwarding 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 forwarding 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 as 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 the physical layer, data link layer, IP protocol, UDP protocol, and / or GTP-U protocol.

[0139] The following list of embodiments reflects the various embodiments expressly intended 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 device (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; transmitting the non-SDT configuration to the UE; and communicating with the UE according to the non-SDT configuration while the UE is connected.

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

[0142] Example 3. The method of Example 2, further comprising deciding to transition the UE to the connected state, wherein performing the UE context procedure is in response to the decision.

[0143] Example 4. The method according to Example 3, further comprising receiving a message from the UE via the DU, wherein the decision is to respond to the message.

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

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

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

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

[0148] Example 9. The method according to Example 3, further comprising receiving measurement results from the UE via the DU, wherein the determination is based on the measurement results.

[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 actions performed include sending a UE context correction request message to the DU and receiving a UE context correction response message from the DU that includes the non-SDT DU configuration.

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

[0151] Example 12. The method according to Example 11, wherein the non-SDT configuration is a non-SDT DU configuration, and the actions performed include receiving a UE context correction request message from the base station's central unit (CU) and sending a UE context correction response message to the CU, which includes the non-SDT DU configuration.

[0152] Example 13. The method of Example 12, wherein transmitting the non-SDT DU configuration to the UE includes transmitting a Radio Resource Control (RRC) restart 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 base station central unit (CU) for obtaining a radio resource control (RRC) message from an interface message, the method comprising: receiving a message from a base station distributed unit (DU) to the CU, which includes a signaling 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 determination, processing the PDCP PDU or the UL-CCCH to obtain the RRC message.

[0154] Example 15. The method of Example 14, wherein determining includes determining that the octet string is a PDCP PDU, and 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 according to Example 15, wherein processing the PDCP PDU includes extracting encrypted data packets from the PDCP PDU and decrypting the encrypted data packets.

[0156] Example 17. The method of Example 14, wherein determining includes determining that the octet string is UL-CCCH, and 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 restart request message, and the method further comprises extracting a message authentication code for integrity (MAC-I) from the RRC restart request message, and verifying the MAC-I using an integrity algorithm, an integrity key, and integrity parameters.

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

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

[0160] Example 21. The method according to Example 19 or 20, wherein the determination 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. The method according to any one of Examples 19 to 21, wherein the determination is to determine that the logical channel is a common control channel (CCCH) and that the reception occurs via a configured grant radio resource, and to determine that the uplink data is to be transmitted in a non-initial uplink RRC message transfer message when the logical channel is a CCCH and that the reception does not occur via a configured grant radio resource.

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

[0163] Example 24. The method according to Example 23, wherein the reception occurs via 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) which includes a logical channel identifier and an uplink data packet containing the uplink data, 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 via the non-initial uplink RRC message transfer message.

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

[0166] Example 27. A wireless access network (RAN) node equipped with processing hardware and configured to perform the method described in any one of Examples 1 to 26.

[0167] The following explanation may apply to the explanation above.

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

[0169] User devices (e.g., UE102) that can implement the technology of this disclosure may include smartphones, tablet computers, laptop computers, mobile game consoles, point-of-sale (POS) terminals, health management devices, drones, cameras, media streaming dongles or other personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, or any suitable wireless communication-capable device such as a broadband router. Furthermore, in some cases, user devices may be integrated into electronic systems such as vehicle head units or advanced driver-assistance systems (ADAS). Moreover, user devices may operate as Internet of Things (IoT) devices or mobile internet devices (MIDs). Depending on the type, user devices may include one or more general-purpose processors, computer-readable memory, user interfaces, one or more network interfaces, one or more sensors, etc.

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

[0171] When implemented in software, technology may be provided as part of an operating system, a library used by multiple applications, or a specific software application. Software can run on one or more general-purpose processors or one or more application-specific processors.

Claims

1. A method implemented by a distributed unit (DU) of a base station for transferring uplink data, including control plane information or non-control plane information, to a central unit (CU), Receiving the uplink data from an inactive user device (UE) via a logical channel, Based on the aforementioned logical channel, it is determined whether the uplink data is transmitted via the transport network layer protocol stack or via an uplink radio resource control (RRC) message forwarding message. In accordance with the above decision, the uplink data is transmitted to the CU, Methods that include...

2. The above decision is When the logical channel is a dedicated traffic channel (DTCH), it is decided to transmit the uplink data via the transport network layer protocol stack. The method according to claim 1, including the method described in claim 1.

3. The above decision is When the aforementioned logical channel is a dedicated control channel (DCCH), it is decided to transmit the uplink data in a non-initial uplink RRC message transfer message. The method according to claim 1 or 2, including the method according to claim 1 or 2.

4. The above decision is The logical channel is a common control channel (CCCH), and when the reception occurs via a configured grant radio resource, it is decided to transmit the uplink data in a non-initial uplink RRC message forwarding message. The logical channel is CCCH, and when the reception does not occur via the configured grant radio resource, it is decided to transmit the uplink data in the initial uplink RRC message forwarding message. The method according to any one of claims 1 to 3, including the method described in any one of claims 1 to 3.

5. A method implemented by a base station's central unit (CU) for obtaining radio resource control (RRC) messages from interface messages, The distribution unit (DU) of the base station receives a message from the DU to the CU that includes a signaling radio bearer (SRB) identifier and an octet string. Based on the SRB identifier, it is determined 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 above determination, the PDCP PDU or the UL-CCCH is processed to obtain the RRC message, Methods that include...

6. The determination described above includes determining that the octet string is PDCP PDU, The aforementioned processing involves processing the PDCP PDU to obtain the uplink-dedicated control channel (UL-DCCH) message, and extracting the RRC message from the UL-DCCH message. The method according to claim 5, including the method described in claim 5.

7. The method according to claim 6, wherein processing the PDCP PDU includes retrieving encrypted data packets from the PDCP PDU and decrypting the encrypted data packets.

8. The determination described above includes determining that the octet string is UL-CCCH, The aforementioned processing includes extracting the RRC message from the UL-CCCH. The method according to claim 5.

9. The RRC message is an RRC restart request message, and the method is Extracting the message authentication code (MAC-I) for integrity from the RRC restart request message, The MAC-I is verified using the integrity algorithm, integrity key, and integrity parameters. The method according to claim 8, further comprising:

10. A method implemented by a distributed unit (DU) of a base station for transferring uplink data, including control plane information or non-control plane information, to a central unit (CU), Receiving the uplink data via wireless resources from an inactive user device (UE), Based on whether the aforementioned radio resource is a configured grant radio resource, it is determined whether to transmit the uplink data in an initial uplink radio resource control (RRC) message forwarding message or in a non-initial uplink RRC message forwarding message. In accordance with the above decision, the uplink data is transmitted to the CU, Methods that include...

11. The method according to claim 10, wherein the reception occurs via a common control channel (CCCH).

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

13. The aforementioned transmission is When transmitting the uplink data in the non-initial uplink RRC message transfer message, the non-initial uplink RRC message transfer message includes a zero signaling radio bearer (SRB) identifier, When transmitting the uplink data in the initial uplink RRC message transfer message, refrain from including the zero SRB identifier in the initial uplink RRC message transfer message. The method according to any one of claims 10 to 12, including the method described in any one of claims 10 to 12.

14. A wireless access network (RAN) node comprising processing hardware and configured to perform the method described in any one of claims 1 to 13.

Images