Managing positioning measurements in inactive states

Abstract

A central unit (CU) of a distributed base station further comprising a distributed unit (DU) is configured to: transmit to the DU a CU-to-DU message requesting sounding reference signal (SRS) resources for the UE; receiving, from the DU, a DU-to-CU message including an SRS configuration for the UE in response to the CU-to-DU message; and transmitting a command to release the radio connection to the UE via the DU, the command including the SRS configuration.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of the filing date of provisional U.S. patent application No. 63 / 334,648, entitled “MANAGING ASMALL DATATRANSMISSION CONFIGURATION,” filed on April 25, 2022. The entire contents of this provisional application are hereby expressly incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to wireless communications, and more particularly to communication of uplink and / or downlink data and sounding reference signals for positioning at a user equipment (UE) and a radio access network (RAN) when the UE is operating in an inactive or idle state associated with a protocol for controlling radio resources. Background Art

[0004] This background description is provided for the purpose of generally presenting the context of the present disclosure. The work of the presently named inventors, to the extent that it is described in this background section, and aspects of the specification that might not have been identified as prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

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

[0006] The RRC sublayer specifies: an RRC_IDLE state, in which the UE does not have an active radio connection with a base station; an RRC_CONNECTED state, in which the UE has an active radio connection with a base station; and RRC_INACTIVE, which allows the UE to transition back to the RRC_CONNECTED state more quickly due to radio access network (RAN) level base station coordination and RAN paging procedures. In some cases, a UE in the RRC_INACTIVE state has only one relatively small packet to transmit. In some such cases, a small data transfer (SDT) procedure will support data transmission for a UE operating in the RRC_INACTIVE state (i.e., without transitioning to the RRC_CONNECTED state).

[0007] SDT is enabled on a radio bearer basis and is initiated by the UE only when: less than the configured amount of uplink data is waiting to be transmitted on all radio bearers for which SDT is enabled, the downlink RSRP is above the configured threshold and valid SDT resources are available. The SDT process can be initiated by the UE through a transmission on the random access channel (RACH) (i.e., called random access SDT (RA-SDT)) or a transmission on type 1 configured grant (CG) resources (i.e., called CG-SDT). For RA-SDT, the network configures 2-step and / or 4-step random access resources for SDT. In RA-SDT, the UE sends an initial transmission including data in message 3 (Msg3) of a 4-step random access process or in the payload of message A (MsgA) of a 2-step random access process. Then, after the random access process is completed, the network can use dynamic uplink grants and downlink assignments to schedule subsequent uplink and / or downlink transmissions, respectively.

[0008] A CG-SDT session is initiated with a valid UL timing alignment. The UL timing alignment is maintained by the UE based on a network-configured SDT-specific timing alignment timer and the DL RSRP of a configured number of highest-ranked SSBs. When the SDT-specific timing alignment timer expires, the CG resources are released. When a CG-SDT session is initiated, the UE uses the CG to send an initial transmission including data on the CG opportunity, and the network may use dynamic grants to schedule subsequent uplink transmissions. Alternatively, the transmission is performed on subsequent CG resource opportunities. During the CG-SDT session, downlink transmissions are scheduled using dynamic assignments. After receiving confirmation of the initial transmission from the network, the UE initiates subsequent uplink transmissions.

[0009] A UE in the RRC_INACTIVE state can perform location services (e.g., as described in 3GPP specifications 38.305 v17.0.0 and 23.273 v17.4.0). To perform location services, the UE sends an uplink message to the RAN when operating in the RRC_INACTIVE state. The RAN sends the uplink message to a network node, such as an access and mobility management function (AMF) or a location management function (LMF). To perform location services, the AMF or LMF sends a downlink message to the RAN, and the RAN sends the downlink message to the UE operating in the RRC_INACTIVE state. The UE sends a sounding reference signal (SRS) for positioning when operating in the RRC_INACTIVE state. However, it is not clear how the RAN provides a sounding reference signal (SRS) configuration to the UE so that the UE operating in the RRC_INACTIVE state can send the SRS to the RAN. It is also not clear how a distributed base station configures the SRS configuration for a UE operating in the RRC_INACTIVE state to send the SRS. Summary of the invention

[0010] An example embodiment of the technology disclosed herein is a method implemented in a central unit (CU) of a distributed base station, the distributed base station further comprising a distributed unit (DU). The method includes: sending a CU-to-DU message to the DU requesting a sounding reference signal (SRS) resource for a UE; receiving a DU-to-CU message from the DU including an SRS configuration for the UE in response to the CU-to-DU message; and sending a command to release a radio connection to the UE via the DU, the command including the SRS configuration.

[0011] Another example embodiment of these techniques is a method implemented in a distributed unit (DU) of a distributed base station, the distributed base station further comprising a central unit (CU). The method includes: receiving a CU-to-DU message from the CU requesting a sounding reference signal (SRS) resource for a UE; receiving a DU-to-CU message from the UE including an SRS configuration for the UE in response to the CU-to-DU message; receiving a command to release a radio connection from the DU, the command including the SRS configuration; and sending the command to the UE.

[0012] Yet another example embodiment of the techniques is a network node configured to operate in a radio access network (RAN), the network node comprising processing hardware and configured to implement any of the methods described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A is a block diagram of an example wireless communication system in which user devices and base stations of the present disclosure may implement the disclosed techniques for reducing latency in data communications;

[0014] Figure 1B The centralized unit (CU) and the distributed unit (DU) can be Figure 1A A block diagram of an example base station operating in a system of FIG.

[0015] Figure 2A yes Figure 1A A block diagram of an example protocol stack according to which a UE communicates with a base station;

[0016] Figure 2B yes Figure 1A A block diagram of an example protocol stack according to which a UE communicates with a CU and a DU;

[0017] Figure 3 illustrating an example scenario in which a RAN node configures a UE for SDT using SRS resource configuration and the UE enters an inactive state;

[0018] Figure 4 Examples and Figure 3 A similar example scenario, but where the UE is already inactive when configured for SDT;

[0019] Figure 5A illustrating an example scenario in which a RAN node determines to resume a connection with a UE to send data before configuring the UE for SDT;

[0020] Figure 5B Examples and Figure 5A A similar example scenario, but where the UE initiates the process of resuming the connection with the RAN;

[0021] Fig. 6A illustrating an example scenario in which a UE requests connection to a RAN node and in which the RAN node communicates with a previously connected base station to retrieve UE context information;

[0022] Figure 6B Examples and Fig. 6A A similar example scenario, but where the UE communicates UL and / or DL ​​data with the CU of the RAN node via the DU before completing the SDT;

[0023] Figure 6C Examples and Fig. 6A A similar example scenario, but where the UE enters the connected state and receives configuration information before returning to the inactive state and communicating via SDT;

[0024] Fig. 7A An example scenario is illustrated in which a source base station performs a handover with a target base station and the target base station configures the UE for SDT communication;

[0025] Figure 7B Examples and Fig. 7A Similar example scenario, but where the core network (CN) handles the handover of the source and target base stations;

[0026] Figure 8 Illustrate an example scenario in which a UE requests to perform a reestablishment procedure with a base station and in which the base station communicates with a previously connected base station to retrieve UE context information;

[0027] Fig. 9 Examples and Figure 8 A similar example scenario, but where the base station communicates with the previously connected base station to release the UE context;

[0028] Fig. 10A is a flow chart of an example method implemented in a RAN node for sending an SRS configuration to a UE and a second RAN node or CN;

[0029] Fig. 10B is with Fig. 10A A flow chart of a similar example method, but wherein the RAN node sends the SRS configuration to the UE instead of the second RAN node or the CN;

[0030] Fig. 10C is with Fig. 10A a flow chart of a similar example method, but wherein the RAN node determines whether to send an SRS configuration to a second RAN node and / or the CN based on whether the second RAN node supports SDT or SRS for an inactive state;

[0031] Fig. 10D is with Fig. 10A a flow chart of a similar example method, but wherein the RAN node causes the UE to transition to a connected state and sends another SRS configuration to the UE that does so;

[0032] Fig.10E is with Fig. 10D A flow chart of a similar example method, but wherein the RAN node determines whether to send an additional SRS configuration to the UE;

[0033] Fig.10F is with Fig. 10A A flow chart of a similar example method, but wherein the RAN node sends a reconfiguration message to the UE to release the SRS configuration;

[0034] Fig.11A is a flow chart of an example method implemented in a RAN node for sending a release message to a UE to configure the UE to continue applying an SRS configuration;

[0035] Fig. 11B is with Fig.11AA flow chart of a similar example method, but wherein the RAN node sends a release message including a second SRS configuration to enhance the first SRS configuration;

[0036] Fig. 11C is with Fig.11A A flow chart of a similar example method, but wherein the RAN node sends a message to the UE to release the SRS configuration;

[0037] Fig.11D is with Fig.11A a flow chart of a similar example method, but wherein the RAN node determines whether to configure the UE to continue to apply, augment, or release the SRS configuration based on whether the RAN node adapts to the SRS configuration;

[0038] Fig. 12A is a flow chart of an example method implemented in a CU for sending SRS resource configuration and additional parameters to a DU;

[0039] Fig. 12B is with Fig. 12A A flow chart of a similar example method, but wherein the CU determines whether to send additional parameters based on whether the UE is configured to use SRS resource configuration in an inactive state;

[0040] Fig.13 is a flow chart of an example method implemented in a DU for sending SRS resource configuration and additional parameters to a CU and a UE;

[0041] Fig.14 is with Fig.13 A flow chart of a similar example method, but wherein the DU determines to include additional parameters when the DU configures the SRS resource configuration for a case where the UE operates in an inactive state;

[0042] Fig.15A is a flow chart of an example method implemented in a CU for sending an RRC release message including an SRS configuration to a UE;

[0043] Fig. 15B is with Fig.15A A flow chart of a similar example method, but wherein the CU determines whether to send a release message or a reconfiguration message based on whether the CU requests SRS resources that the UE can use in an inactive state;

[0044] Fig.16 is a flow chart of an example method implemented in a DU for receiving an SRS configuration and sending the SRS configuration to a UE in a release message;

[0045] Fig.17 is with Fig.16A flowchart of a similar example method, but wherein the DU determines whether to send the first SRS configuration or the second SRS configuration to the CU based on whether the message from the CU requests allocation of SRS resources for a UE in an inactive state; and

[0046] Fig.18 is a flow chart of an example method implemented in a CU for determining whether to include an indication of requested SRS resources in a DU message based on whether the CU requests SRS resources that a UE can use in an inactive state. DETAILED DESCRIPTION

[0047] As discussed in more detail below, a user equipment (UE) and / or a network node of a radio access network (RAN) may use the techniques of the present disclosure to manage early data communications and to transition the UE between states of a protocol for controlling radio resources between the UE and the RAN. As used in the present disclosure, small data communications or early data communications may refer to small data transmission (SDT) or early data transmission (EDT) from a network perspective (i.e., SDT / EDT in a downlink direction), or SDT / EDT from a UE perspective (i.e., SDT / EDT in an uplink direction).

[0048] First reference Figure 1A , the example wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, a core network (CN) 110, and a location management function (LMF) 168. The base stations 104 and 106 may operate in a RAN 105 connected to the core network (CN) 110. For example, the CN 110 may be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160. In another example, the CN 110 may also be implemented as a sixth generation (6G) core.

[0049] Base station 104 covers cell 124, and base station 106 covers cell 126. If base station 104 is a gNB, cell 124 is an NR cell. If base station 104 is an ng-eNB, cell 124 is an Evolved Universal Terrestrial Radio Access (E-UTRA) cell. Similarly, if base station 106 is a gNB, cell 126 is an NR cell, and if base station 106 is an ng-eNB, cell 126 is an E-UTRA cell. Cells 124 and 126 may be located in the same radio access network notification area (RNA) or in different RNAs. In general, RAN 105 may include any number of base stations, and each of the base stations may cover one, two, three, or any other suitable number of cells. UE 102 may support at least 5G NR (or simply "NR") or E-UTRA air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 may be connected to CN 110 via an interface (e.g., S1 or NG interface). The base stations 104 and 106 may also be interconnected via an interface for interconnecting NG RAN nodes (e.g., an X2 or Xn interface).

[0050] Among other components, the EPC 111 may include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. In general, the SGW 112 is configured to transfer user plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks (e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). The 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management function (AMF) 164 and / or a session management function (SMF) 166. In general, the UPF 162 is configured to transfer user plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions. LMF 168 and CN 110 (e.g., AMF 164) may be interconnected via an interface (e.g., NL). LMF 168 and RAN 105 may communicate with each other via CN 110 and a positioning protocol (e.g., NR Positioning Protocol A (NRPPa)) to provide location services to UE 102 or locate UE 102. In some cases, LMF 168 and RAN 105 may be interconnected via a new interface, and LMF 168 and RAN 105 may communicate directly with each other via the new interface and the positioning protocol.

[0051] like Figure 1A As shown, base station 104 supports cell 124, and base station 106 supports cell 126. Cells 124 and 126 may partially overlap, so that UE 102 may select, reselect, or switch from one of cells 124 and 126 to the other. In order to exchange messages or information directly, base station 104 and base station 106 may support an X2 or Xn interface. In general, CN 110 may be connected to any suitable number of base stations supporting NR cells and / or EUTRA cells.

[0052] As discussed in detail below, the UE 102 and / or the RAN 105 may utilize the techniques of this disclosure when a radio connection between the UE 102 and the RAN 105 is suspended, e.g., when the UE 102 is operating in an inactive or idle state of a protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the examples below relate to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol.

[0053] As used in the present disclosure, the term "data" or "data packet" refers to signaling, control plane information at the protocol layer for controlling radio resources (e.g., RRC), controlling mobility management (MM), controlling session management (SM); or non-signaling, non-control plane information at the protocol layer above the layer of the protocol for controlling radio resources (e.g., RRC), above the layer of the protocol for controlling mobility management (MM), above the layer of the protocol for controlling session management (SM), or above the layer of the protocol for controlling quality of service (QoS) flows (e.g., Service Data Adaptation Protocol (SDAP)). The data to which the UE and / or RAN applies the techniques of the present disclosure may include, for example, Internet of Things (IoT) data, Ethernet traffic data, Internet traffic data, or Short Message Service (SMS) messages. Further, as discussed below, in some implementations, the UE 102 applies these techniques only if the size of the data is below a certain threshold.

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

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

[0056] In some implementations, the data is an uplink (UL) service data unit (SDU) of a packet data convergence protocol (PDCP) or SDAP. The UE 102 applies a security function to the SDU and includes the protected SDU in a first UL PDU (e.g., a UL PDCP PDU). The UE 102 then includes the UL PDCP PDU in a second UL PDU (such as a UL MAC PDU), which may be associated with a media access control (MAC) layer. Therefore, in these cases, the UE 102 sends the protected UL PDCP PDU in the UL MAC PDU. In some implementations, the UE 102 may include the UL RRC message in the UL MAC PDU. In further implementations, the UE 102 may not include the UL RRC message in the UL MAC PDU. In this case, the UE 102 may not include the UE ID of the UE 102 in the UL MAC PDU that does not include the UL RRC message. In yet further implementations, the UE 102 may include the UL PDCP PDU in a UL radio link control (RLC) PDU, and then include the UL RLC PDU in a UL MAC PDU. In the case of including the UL RRC message in the UL MAC PDU, in some implementations, the UE 102 generates an RRC MAC-I and includes the RRC MAC-I in the UL RRC message. For example, the RRC MAC-I is the resumeMAC-I field, as specified in 3GPP specification 38.331. In further implementations, the UE may utilize an integrity key (e.g., K RRCint The RRC MAC-I is obtained from the UL RRC message, including a key, an integrity protection algorithm, and other 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).

[0057] In a further implementation, the data is a UL service data unit (SDU) of NAS. UE 102 applies a security function to the SDU and includes the protected SDU in a first UL PDU (such as a NAS PDU), which may be associated with a NAS layer. For example, the NAS layer may be an MM sublayer or an SM sublayer of 5G, an evolved packet system (EPS), or 6G. Then, UE 102 may include the UL NAS PDU in a second UL PDU (such as a UL RRC message). Therefore, in these cases, UE 102 sends the (first) protected UL NAS PDU in the UL RRC message. In some implementations, UE 102 may include the UL RRC message in a UL MAC PDU and send 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, UE 102 may not include the RRC MAC-I in the UL RRC message. Alternatively, UE 102 may include the RRC MAC-I as described above.

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

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

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

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

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

[0063] Further, in some cases, the RAN 105 sends data in the downlink (DL) direction to the UE 102 operating in the RRC_INACTIVE or RRC_IDLE state.

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

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

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

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

[0068] The base station 104 is equipped with processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable memory storing instructions executed by the one or more general-purpose processors. Additionally or alternatively, the processing hardware 130 may include a dedicated processing unit. In an example implementation, the processing hardware 130 includes a media access control (MAC) controller 132, which is configured to: perform a random access process with one or more user devices, receive uplink MAC protocol data units (PDUs) of one or more user devices, and send downlink MAC PDUs to one or more user devices. The processing hardware 130 may also include a packet data convergence protocol (PDCP) controller 134, which is configured to: send DL PDCP PDUs according to which the base station 104 can send data in the downlink direction in some scenarios, and receive UL PDCP PDUs according to which the base station 104 can receive data in the uplink direction in other scenarios. The processing hardware may further include an RRC controller 136 to implement processes and message delivery at the RRC sublayer of the protocol communication stack. In an example implementation, the processing hardware 130 includes an RRC inactive controller 138 that is configured to manage uplink and / or downlink communications with one or more UEs operating in an RRC_INACTIVE or RRC_IDLE state. The base station 106 may include substantially 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.

[0069] UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors such as CPUs, and non-transitory computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors, and / or a dedicated processing unit. In an example implementation, the processing hardware 150 includes an RRC inactive controller 158, which is configured to manage uplink and / or downlink communications when UE 102 operates in an RRC_INACTIVE state. In an example implementation, the processing hardware 150 includes a media access control (MAC) controller 152, which is configured to perform a random access procedure with a base station, send an uplink MAC protocol data unit (PDU) to the base station, and receive a downlink MAC PDU from the base station. The processing hardware 150 may also include a PDCP controller 154, which is configured to: in some scenarios, send a DL PDCP PDU according to which the base station 106 can send data in the downlink direction, and in further scenarios, receive a UL PDCP PDU according to which the base station 106 receives data in the uplink direction. The processing hardware may further include an RRC controller 156 to implement procedures and messaging at the RRC sublayer of the protocol communication stack.

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

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

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

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

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

[0075] Figure 2AAn example protocol stack 200 is illustrated in a simplified manner according to which a UE 102 may communicate with an eNB / ng-eNB or gNB (e.g., one or more of base stations 104, 106).

[0076] In the example stack 200, the physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 may in turn provide data transfer services to the Service Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer ( Figure 2A (not shown) provides data transmission services. In some implementations, such as Figure 2A As shown, UE 102 supports both EUTRA and NR stacks to support handover between EUTRA and NR base stations and / or support DC implemented through EUTRA and NR interfaces. Figure 2A As shown, the UE 102 can support the layering of NR PDCP 210 above the EUTRA RLC 206A, and the layering of SDAP sublayer 212 above the NR PDCP sublayer 210.

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

[0078] On the control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide a signaling radio bearer (SRB) or an RRC sublayer ( Figure 2AThe EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 may provide data radio bearers (DRBs) to support data exchange. The data exchanged on the NR PDCP sublayer 210 may be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0079] Figure 2B An example protocol stack 250 is shown in a simplified manner in which UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally divided, such as Figure 2B 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support the connection to the 5GC, the NR PDCP 210 provides SRBs to the RRC 214, and the NR PDCP 210 provides DRBs to the SDAP 212 and SRBs to the RRC 214.

[0080] Next, refer to Figures 3 to 9 To discuss the Figure 1A Several components of the present invention and several example scenarios related to sending data in an inactive or idle state. To simplify the following description, "inactive state" is used and may refer to the RRC_INACTIVE or RRC_IDLE state, and "connected state" is used and may refer to the RRC_CONNECTED state.

[0081] First, referring to the example scene 300 Figure 3, in which the base station 104 includes a central unit (CU) 172 and a distributed unit (DU) 174, and the CU 172 includes a CU-CP 172A and a CU-UP 172B. In the scenario 300, the UE 102 initially operates in a connected state 302, and communicates 304 with the DU 174 by using a DU configuration (i.e., a first non-SDT DU configuration), and further communicates 304 with the CU-CP 172A and / or CU-UP 172B via the DU 174 by using a CU configuration (i.e., a first non-SDT CU configuration). While the UE is communicating 304 with the base station 104, the CU-CP 172A sends 306 a UE context modification request message. In response, the DU 174 sends 308 a UE context modification response message including a non-SDT configuration for the UE 102 (i.e., a second non-SDT configuration) to the CU-CP 172A. The CU-CP 172A generates an RRC reconfiguration message including the non-SDT DU configuration and sends 310 a first CU-to-DU message (e.g., a DL RRC messaging message) including the RRC reconfiguration message to the DU 174. In turn, the DU 174 sends 312 the RRC reconfiguration message to the UE 102. In response, the UE 102 sends 314 an RRC reconfiguration complete message to the DU 174, which in turn sends 316 a first DU-to-CU message (e.g., an UL RRC messaging message) including the RRC reconfiguration complete message to the CU-CP 172A.

[0082] After receiving 312 the RRC reconfiguration message, the UE 102 in the connected state communicates 318 with the DU 174 using the non-SDT DU configuration, and communicates with the CU-CP 172A and / or CU-UP 172B via the DU 174. In the event that the RRC reconfiguration message does not include a CU configuration, the UE 102 communicates 318 with the CU-CP 172A and / or CU-UP 172B via the DU 174 using the first non-SDT CU configuration. In the event that the RRC reconfiguration message includes a non-SDT CU configuration (i.e., a second non-SDT CU configuration), the UE 102 communicates 318 with the CU-CP 172A and / or CU-UP 172B via the DU 174 using the second non-SDT CU configuration. In some implementations, the second non-SDT CU configuration augments the first non-SDT CU configuration, or includes at least one new configuration parameter not included in the first non-SDT CU configuration. In some such cases, the UE 102 and the CU-CP 172A and / or CU-UP 172B may communicate 318 with each other using the second non-SDU CU configuration and configuration parameters of the first non-SDT CU configuration that are not augmented by the second non-SDU CU configuration.

[0083] In some implementations, the first non-SDT CU configuration includes configuration parameters related to the operation of the RRC and / or PDCP protocol layers (e.g., RRC 214 and / or NR PDCP 210), which the UE 102 and CU 172 use to communicate with each other when the UE 102 operates in a connected state. Similarly, depending on the implementation, the second non-SDT CU configuration includes configuration parameters related to the operation of the RRC and / or PDCP protocol layers, which the UE 102 and CU 172 use to communicate with each other when the UE 102 operates in a connected state. In some implementations, the first non-SDT CU configuration includes configuration parameters in a RadioBearerConfig information element (IE) and / or a MeasConfig IE (e.g., as defined in 3GPP specification 38.331 v16.7.0). Similarly, the second non-SDT CU configuration includes configuration parameters in RadioBearerConfig IE and / or MeasConfig IE (e.g., as defined in 3GPP specification 38.331 v16.7.0). In some implementations, the first non-SDT CU configuration is or includes RadioBearerConfig IE and / or MeasConfig IE, and the second non-SDT CU configuration is or includes RadioBearerConfig IE and / or MeasConfig IE.

[0084] In some implementations, the second non-SDT DU configuration augments the first non-SDT DU configuration, or includes at least one new configuration parameter not included in the first non-SDT DU configuration. In some such cases, the UE 102 and the DU 174 communicate 318 with each other using the second non-SDU DU configuration and configuration parameters in the first non-SDU DU configuration that are not augmented by the second non-SDU DU configuration. In some implementations, the first non-SDT DU configuration includes configuration parameters related to the operation of the RRC, RLC, MAC, and / or PHY protocol layers (e.g., RLC 206B, MAC 204B, and / or PHY 202B), and the UE 102 and the DU 174 communicate with each other using the configuration parameters when the UE 102 operates in the connected state. Similarly, depending on the implementation, the second non-SDTDU configuration includes configuration parameters related to the operation of the RRC, RLC, MAC, and / or PHY protocol layers, which the UE 102 and the DU 174 use to communicate with each other when the UE 102 operates in a connected state. In some implementations, the first non-SDT DU configuration includes configuration parameters in a CellGroupConfig IE (e.g., as defined in 3GPP specification 38.331 v16.7.0). Similarly, the second non-SDT DU configuration includes configuration parameters in a CellGroupConfig IE (e.g., as defined in 3GPP specification 38.331 v16.7.0). In some implementations, the first non-SDT DU configuration and the second non-SDT DU configuration are CellGroupConfig IEs.

[0085] Events 306, 308, 310, 312, 314, 316, and 318 are Figure 3 It is collectively referred to as the non-SDT resource (re)configuration process 390.

[0086] In some implementations, while the UE 102 is communicating with the base station 104, or after the non-SDT resource (re) configuration process 390 (if performed), the CU-CP 172A determines to transition the UE 102 from the connected state to the inactive state based on the data inactivity of the UE 102 (i.e., the UE 102 in the connected state does not have data activity with the base station 104). In further implementations, while the UE 102 is communicating with the base station 104, or after the non-SDT resource (re) configuration process 390 (if performed), the UE 102 determines or detects data inactivity and sends 320 to the DU 174 UE assistance information (e.g., UEAssistanceInformation message) indicating that the UE 102 prefers or requests to transition to the inactive state configured with SDT. Then, the DU 174 sends 321 a UL RRC messaging message including the UE assistance information to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 is in data inactivity based on the UE assistance information. In other implementations, the DU 174 can perform data inactivity monitoring for the UE 102.

[0087] In some implementations, CU-CP 172A sends a CU to DU message (e.g., a UE context setup request message or a UE context modification request message) to DU 174 to request or command DU 174 to perform data inactivity monitoring. In the case where DU 174 detects or determines that UE 102 is in data inactivity during monitoring, DU 174 sends 322 an inactivity notification (e.g., a UE inactivity notification message) to CU-CP 172A. Thus, CU-CP 172A determines that UE 102 is in data inactivity based on the inactivity notification received from DU 174. In yet other implementations, CU-UP 172B performs data inactivity monitoring for UE 102. In some implementations, CU-CP 172A sends a CP to UP message (e.g., a bearer context setup request message or a bearer context modification request message) to CU-UP 172B to request or command CU-UP 172B to perform data inactivity monitoring. In some cases where CU-UP 172B detects or determines during monitoring that UE 102 is in data inactivity, CU-UP 172B sends 323 an inactivity notification (e.g., a bearer context inactivity notification message) to CU-CP 172A. Thus, CU-CP 172A determines that UE 102 is in data inactivity based on the inactivity notification received from CU-UP 172B. In some implementations, CU-CP 172A determines that UE 102 is in data inactivity based on UE assistance information, the inactivity notification of event 322, and / or the inactivity notification of event 323.

[0088] In some implementations, after a specific period of data inactivity, CU-CP 172A determines that neither CU 172 (i.e., CU-CP 172A and / or CU-UP 172B) nor UE 102 has sent any data in the downlink direction or uplink direction, respectively, during the period. Depending on the implementation, CU-CP 172A determines to transition UE 102 to an inactive state with SDT configured in response to the determination. Alternatively, CU-CP 172A determines to transition UE 102 to an inactive state without SDT configured in response to determining that UE 102 is in data inactivity.

[0089] In response to determining that the UE 102 is in data inactivity (for the specific period of time) or determining to transition the UE 102 to an inactive state configured with SDT or thereafter, the CU-CP 172A sends 324 a bearer context modification request message to the CP-CU 172B to suspend data transmission of the UE 102. In response, the CU-UP 172B suspends data transmission of the UE 102 and sends 326 a bearer context modification response message to the CU-CP 172A. In response to determining that the UE 102 is in data inactivity (for example, for the specific period of time) or determining to transition the UE 102 to an inactive state configured with SDT or thereafter, in some implementations, the CU-CP 172A sends 328 a second CU-to-DU message (e.g., a UE context modification request message) to instruct the DU 174 to provide an SDT DU configuration for the UE 102. In some implementations, the CU-CP 172A includes an SDT request indication (e.g., an IE, such as a CG-SDT query indication IE) for requesting the SDT DU configuration in the second CU to DU message. In further implementations, in response to the SDT request indication or the second CU to DU message, the DU 174 sends 330 a second DU to CU message (e.g., a UE context modification response message) to the CU-CP 172A. Alternatively, the DU 174 does not include the SDT DU configuration in the second DU to CU message. Instead, after receiving the second CU to DU message or sending the second DU to CU message, the DU 174 sends an additional DU to CU message (e.g., a UE context modification required message) including the SDT DU configuration to the CU-CP 172A. In some implementations, the CU-CP 172A sends an additional CU to DU message (e.g., a UE context modification confirmation message) to the DU 174 in response to the additional CU to DU message. In some alternative implementations, CU-CP 172A sends a second CU to DU message and receives a second DU to CU message or additional DU to CU messages before determining that UE 102 is in data inactivity. In other alternative implementations, CU-CP 172A includes an SDT request indication in the first CU to DU message at event 308, and DU 174 includes an SDT DU configuration in the first DU to CU message at event 310 in response to the SDT request indication.

[0090] In some alternative implementations, DU 174 may not be able to send the SDT DU configuration for UE 102 to CU-CP 172A because DU 174 may be congested or may not have sufficient resources. Therefore, DU 174 neither includes the SDT DU configuration in the second DU to CU message nor sends an additional DU to CU message to CU-CP 172A.

[0091] In some implementations, the CU-CP 172A sends 329 a CU-to-DU message (e.g., a positioning information request message) to request the DU 174 to allocate SRS resources for the UE 102. In response to or after receiving the CU-to-DU message 329, the DU 174 generates an SRS resource configuration that allocates SRS resources for the UE 102, and sends 331 a DU-to-CU message (e.g., a positioning information response message or a UE context modification required message) including the SRS resource configuration to the CU-CP 172A. In some cases where the UE context modification required message includes the SRS resource configuration, the DU 174 sends a positioning information response message to the CU-CP 172A in response to the positioning information request message, and the CU 172 sends a UE context modification confirmation message to the DU 174 in response to the UE context modification required message.

[0092] In some implementations, the CU-CP 172A includes a requested SRS transmission characteristics IE in the CU-to-DU message at event 329 to describe the SRS characteristics. Depending on the implementation, the DU 174 generates the SRS resource configuration to satisfy the SRS characteristics.

[0093] In some implementations, in response to or after determining that the UE 102 is in data inactivity or determining to transition the UE 102 to an SDT-configured inactive state, the CU-CP 172A sends 329 a CU to DU message to the DU 174. In further implementations, the CU-CP 172A sends 329 the CU to DU message before or after sending 328 the CU to DU message.

[0094] In some implementations, in response to determining that the UE 102 is to be transitioned to an inactive state configured with SDT, the CU-CP 172A generates an RRC release message (e.g., an RRCRelease message, an RRCConnectionRelease message) to transition the UE 102 to an inactive state. In some implementations, the CU-CP 172A includes a suspension configuration (e.g., a SuspendConfig IE) in the RRC release message. In a further implementation, the CU-CP 172A includes the SDT DU configuration (e.g., if obtained from DU 174) and / or the SDT CU configuration in the RRC release message. Depending on the implementation, the CU-CP 172A includes the SRS resource configuration in the RRC release message. Then, the CU-CP 172A sends 332 a third CU to DU message (e.g., a UE context release command message, a UE context modification request message, or a DL RRC messaging message) including the RRC release message to the DU 174. Then, DU 174 sends 334 an RRC release message to UE 102. In some implementations, DU 174 generates a MAC PDU including the RRC release message and sends 334 the MAC PDU to UE 102. The RRC release message instructs UE 102 to transition to an inactive state. UE 102 transitions 336 from a connected state to an inactive state upon receiving the RRC release message. In some implementations, in response to the third CU to DU message, DU 174 retains the SDT DU configuration (if generated by DU 174 during processes 328, 330) and releases or retains (a portion of) the first non-SDT DU configuration and / or (a portion of) the second non-SDT DU configuration. DU 174 may send a third DU to CU message (e.g., a UE context release complete message or a UE context modification response message) to CU-CP 172A in response to the third CU to DU message.

[0095] In some implementations, the CU-CP 172A additionally includes at least one of the following in the RRC release message: bandwidth part (BWP) configuration, time alignment timer configuration, reference signal received power (RSRP) variation threshold, timing advance verification configuration and / or absolute RSRP threshold.

[0096] In some implementations, CU-CP 172A receives at least one of a BWP configuration, a time alignment timer configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold from DU 174 in a DU-to-CU message at event 331. In other implementations, CU-CP 172A generates at least one of a BWP configuration, a time alignment timer configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold. In some such implementations, CU-CP 172A does not receive a BWP configuration, a time alignment configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold from DU 174. In some implementations, CU-CP 172A includes at least one of a BWP configuration, a time alignment timer configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold in a CU-to-DU message at event 329.

[0097] In some implementations, the CU-CP 172A or DU 174 generates an SRS configuration (e.g., an RRC IE), including an SRS resource configuration, a BWP configuration, a time alignment configuration, an RSRP change threshold, a timing advance verification configuration, and / or an absolute RSRP threshold. In some implementations, the SRS configuration (e.g., an SRS-PosRRC-InactiveConfig IE) is specific to SRS transmission during an inactive state. In some cases where the DU 174 generates the SRS configuration, the DU 174 includes the SRS configuration in a DU to CU message at event 331. For example, the DU 174 may include the SRS configuration in an IE (e.g., a DU to CURRC Information IE) of a DU to CU message at event 331. The CU-CP 172A includes the SRS configuration in an RRC release message to send the SRS resource configuration and the BWP configuration, the time alignment configuration, the RSRP change threshold, the timing advance verification configuration, and / or the absolute RSRP threshold to the UE 102. In some cases where CU-CP 172A receives an SRS configuration from DU 174 in a DU-to-CU message at event 331, CU-CP 172A directly or transparently includes the SRS configuration generated by DU 174 in the RRC release message. In such cases, CU-CP 172A does not need to generate an RRC IE, which saves processing power of CU-CP 172A. For example, the RRC message may include a SuspendConfig IE that transparently includes the SRS configuration as an octet string (OCTET STRING).

[0098] Further, depending on the implementation, the RRC message includes or is a HandoverPreparationInformation message that includes a context (e.g., a RAN required for DU 174 (e.g., an access stratum (AS) context or other such context), which in turn includes an SRS configuration as an octet string (e.g., as or including an SRS-Pos-InactiveConfig-r17 resource element, an SRS-PosRRC-InactiveConfig-r17 resource element, as part of a SetupRelease sequence, etc.). Depending on the implementation, this field is an optional field (e.g., an indication that the configuration is used if present and not used if not present), as discussed herein.

[0099] In some implementations, CU-CP 172A includes an indication instructing DU 174 to provide at least one of an SRS configuration or a time alignment timer configuration, an RSRP change threshold, a timing advance verification configuration, and / or an absolute RSRP threshold in a CU-to-DU message at event 329. In response to the indication, DU 174 includes at least one of an SRS configuration or a BWP configuration, a time alignment timer configuration, an RSRP change threshold, a timing advance verification configuration, and / or an absolute RSRP threshold in a DU-to-CU message at event 331. In some implementations, if CU-CP 172A determines that a UE operating in an inactive state is to be configured to transmit an SRS, CU-CP 172A includes the indication. Otherwise, CU-CP 172A avoids including the indication in the CU-to-DU message at event 329.

[0100] In some implementations, the CU-CP 172A includes in the third CU-to-DU message an indication (e.g., a positioning context reservation indication) for instructing the DU 174 to reserve the positioning UE context of the UE 102. In response to the indication, the DU 174 reserves the positioning UE context of the UE 102 (e.g., the SRS resource configuration, the SRS configuration, or the SRS resources configured in the SRS resource configuration or the SRS configuration).

[0101] In some implementations, an SRS resource configuration (e.g., SRS-PosConfig-r17 IE, srs-PosResourceSetToAddModList-r17, srs-PosResourceToAddModList-r17, or SRS-PosResource-r16 list) configures one or more SRS resources (e.g., one or more SRS-PosResource-r16 IEs). In some implementations, the SRS configuration or SRS resource configuration includes an ID (e.g., SRS-PosResourceSetId IE or SRS-PosResourceSetId-r16 IE) that identifies each of the one or more SRS resources or SRS resource configurations. In some implementations, a BWP configuration (e.g., BWP IE) configures the UL BWP where the UE 102 transmits the SRS during the inactive state. Depending on the implementation, the BWP configuration includes a cyclic shift configuration and a subcarrier spacing configuration. In some implementations, the time alignment timer (e.g., srs-TimeAlignmentTimer or inactivePosSRS-TimeAlignmentTimer field) is a timer value for configuring a TA timer for SRS for positioning transmission during an inactive state. In some implementations, the RSRP change threshold (e.g., inactivePosSRS-RSRP-changeThresh) is an RSRP threshold for RSRP increase / decrease for time alignment verification. In some implementations, the timing advance verification configuration (e.g., inactivePosSRS-NrofSS-BlocksToAverage) includes the number of SSBs with the highest RSRP for deriving a downlink path loss reference for TA verification. In some implementations, an absolute RSRP threshold (e.g., inactivePosSRS-AbsThreshSS-BlocksConsolidation) is provided for the UE to determine the SSBs suitable for deriving a downlink path loss reference for TA verification.

[0102] In some implementations, the CU-CP 172A starts an SRS validity timer (or referred to as a CU SRS time alignment timer) for counting the validity of the SRS resource configuration. Depending on the implementation, when the SRS validity timer expires, the CU-CP 172A releases the SRS resource configuration. In some implementations, in response to the expiration of the SRS validity timer, the CU-CP 172A sends a positioning deactivation message (i.e., a CU-to-DU message) to the DU 174 for indicating to the DU 174 that SRS transmission has been / should be deactivated in the UE 102. In other implementations, in response to receiving a positioning deactivation message (i.e., an LMF-to-CU message or an NRPPa message) from the LMF (e.g., LMF 168) or the AMF (e.g., AMF 164) or thereafter, the CU-CP 172A sends a positioning deactivation message (i.e., a CU-to-DU message) to the DU 174 for indicating to the DU 174 that SRS transmission has been / should be deactivated in the UE 102.

[0103] In some implementations, in response to receiving the CU-to-DU message of event 329, generating the SRS resource configuration, or sending the DU-to-CU message of event 331, or thereafter, the DU 174 starts an SRS validity timer (or DU SRS time alignment timer). When the SRS validity timer expires, the DU 174 releases the SRS resource configuration. In some implementations, in response to the expiration of the SRS validity timer, the DU 174 sends a positioning information update message to the CU-CP 172A to indicate to the CU-CP 174A that the SRS resource configuration has been released.

[0104] In some implementations, the CU-CP 172A or DU 174 starts the SRS validity timer based on the timer value in the time alignment timer configuration. For example, the CU-CP 172A or DU 174 may start the SRS validity timer with a timer value slightly larger than the timer value in the time alignment timer configuration. In some implementations, the DU 174 starts the SRS validity timer in response to or after receiving 332 a third CU-to-DU message from the CU-CP 172A. In other implementations, the DU 174 starts the SRS validity timer in response to or after receiving a CU-to-DU message of event 329 or sending a DU-to-CU message of event 331. In some implementations, DU 174 restarts the SRS validity timer in response to or after sending a timing advance command to UE 102, such as when UE 102 is sending SRS according to an SRS resource configuration or DU 174 is performing a positioning session for UE 102 with CU-CP 172A and LMF (e.g., LMF 168).

[0105] When operating 302 in a connected state, the UE 102 uses the C-RNTI to monitor the PDCCH to receive DCI. In response to receiving 334 an RRC release message or thereafter, the UE 102 stops using the C-RNTI to monitor the PDCCH. In some implementations, in response to receiving 334 an RRC release message or transitioning 336 from the connected state to the inactive state or thereafter, the UE 102 retains the C-RNTI. In some implementations, the UE 102 performs a two-step or four-step random access procedure with the base station 104 (e.g., CU-CP 172A and / or DU 174) and receives a random access response message including the C-RNTI from the DU 174 during the random access procedure. In other implementations, the UE 102 receives a random access response message from the CU-CP 172A or from the DU 174 via the DU 174. Figure 3 Another base station (eg, base station 106) not shown in the figure receives an RRC message (eg, an RRC reconfiguration message) including the C-RNTI.

[0106] Events 320, 321, 322, 323, 324, 326, 328, 330, 329, 331, 332, and 334 are Figure 3 Collectively referred to as the SDT configuration process 394.

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

[0108] In some implementations, CU-CP 172A does not include an indication for instructing DU 174 to retain the SDT DU configuration in the third CU to DU message. DU 174 retains the SDT DU configuration as described above. In other implementations, CU-CP 172A includes an indication for instructing DU 174 to retain the SDT DU configuration in a third CU to DU message (e.g., a UE context release command message), and DU 174 retains the SDT DU configuration in response to the indication. If the UE context release command message excludes the indication, DU 174 releases the SDT DU configuration. In yet other implementations, CU-CP 172A does not include an indication for instructing DU 174 to release the SDT DU configuration in a third CU to DU message (e.g., a UE context modification request message or a DL RRC messaging message) for UE 102. Therefore, DU 174 retains the SDT DU configuration in response to the third CU to DU message that excludes the indication. If the third CU-to-DU message includes the indication, the DU 174 releases the SDT DU configuration.

[0109] In some implementations, the SDT CU configuration (e.g., SDT-Config IE) includes an SDT DRB list (e.g., std-DRB-List) including a DRB ID list indicating the IDs of the DRBs configured for SDT. In some implementations, the SDT CU configuration includes an SRB2 indication (e.g., sdt-SRB2-Indication) indicating the SRB2 configured for SDT. In some implementations, the SDT CU configuration includes an SRB2 indication (e.g., sdt-SRB2-Indication) indicating the PDCP entity of the DRB configured for SDT in SDT operation (i.e., for Figure 4 In some implementations, the CU-CP 172A includes the SDT DU configuration in the SDT CU configuration. In some implementations, the “SDT CU configuration” may be simplified as “SDT configuration”.

[0110] In some implementations, the SDT DU configuration includes at least one of: a buffer status report (BSR) configuration, a power headroom report (PHR) configuration, a configured grant (CG) configuration for CG-SDT, a UL bandwidth part (BWP) configuration, a DL BWP configuration for CG-SDT, a time alignment timer value for CG-SDT (e.g., a CG-SDT time alignment timer (CG-SDT-TAT) value), and / or a timing advance validity threshold for CG-SDT. In some implementations, the UL BWP configuration configures a dedicated UL BWP for the UE 102 to perform CG-SDT. Depending on the implementation, the UL BWP configuration includes a CG configuration, a PUCCH configuration, a PUSCH configuration, and / or an SRS configuration. In some implementations, the UL BWP configuration configures a dedicated UL BWP for the UE 102 during the CG-SDT. In some implementations, the UL BWP configuration includes a PDCCH configuration and / or a PDSCH configuration for the UE to send UL control signals from DU 174 on the PDCCH and data from the DU on the PDSCH when the UE performs a CG-SDT with DU 174. Each CG configuration in the CG configuration configures a periodic radio resource (i.e., a CG resource) that the UE 102 can use to send data without receiving a dynamic grant for data transmission. Each CG configuration in the CG configuration configures or includes a periodicity indicating that the CG resource occurs periodically. In some implementations, the periodicity is a fixed number of symbols, time slots, or subframes. Some or all of the CG configurations may have the same periodicity or different periodicities. In some implementations, each CG configuration in the CG configuration configures or includes an offset that indicates a time domain offset (e.g., timeDomainOffset) of the CG resource relative to a reference time (e.g., a system frame number (SFN)). In some implementations, the CG configuration configures or includes a reference time (e.g., timeReferenceSFN). In some implementations, the CG configuration is or is similar to a ConfiguredGrantConfig IE (eg, as defined in 3GPP specification 38.331).

[0111] DU 174 configures a timing advance validity threshold (e.g., including an RSRP range) for UE 102 to determine whether UE 102 can initiate SDT using the configured grant configuration for CG-SDT, such as for Figure 4In some implementations, based on a timing advance validity threshold, UE 102 evaluates whether the stored timing advance value is still valid. In further implementations, if UE 102 determines that the stored timing advance value is invalid, UE 102 initiates a RA-SDT with CU 172 via DU 174, such as for Figure 4 As described. In some implementations, the SDT DU configuration is SDT-MAC-PHY-CG-Config IE, SDT-MAC-PHY-Config IE, SDT-CellConfig IE, or SDT-CellGroupConfig IE. In some implementations, the "SDT DU configuration" can be replaced by the "CG-SDT configuration". In such implementations, the configuration in the SDT DU configuration is specific to CG-SDT. In other implementations, some of the configurations in the SDT DU configuration described above can be grouped into the CG-SDT configuration, and other configurations in the SDT DU configuration (e.g., BSR configuration and / or PHR configuration) are not within the CG-SDT configuration. The SDT DU configuration includes a CG-SDT configuration. In some such cases, the other configuration is configured for CG-SDT or RA-SDT.

[0112] In some implementations, the DU 174 starts or restarts the DU CG-SDT timer in response to or after receiving an SDT request indication, generating a CG-SDT configuration, receiving 328 a second CU to DU message, sending 330 a CG-SDT configuration to the CU 172, receiving 332 a third CU to DU message, or sending 334 a CG-SDT configuration to the UE 102. In some implementations, the DU 174 uses a timer value to start or restart the DU CG-SDT timer to manage the CG-SDT configuration. In some implementations, the timer value is the same as the CG-SDT time alignment timer value. In other implementations, the timer value is close to the CG-SDT time alignment timer value. For example, the timer value may be greater than and close to the CG-SDT time alignment timer value. In another example, the timer value may be less than and close to the CG-SDT time alignment timer value. In some cases where the DU CG-SDT timer expires, the DU 174 releases the CG-SDT configuration or the CG resources configured in the CG-SDT configuration. When or after the CG-SDT configuration is released, DU 174 avoids receiving PUSCH transmissions from UE 102 on the radio resources reserved or configured for the CG-SDT configuration. When or after the CG-SDT configuration is released, DU 174 schedules transmissions for other UEs on the radio resources reserved or configured for the CG-SDT configuration.

[0113] As described above, in some implementations, the RRC release message 334 includes a CG-SDT configuration. Depending on the implementation, in response to receiving the CG-SDT configuration or thereafter, the UE 102 may start or restart the UE CG-SDT timer (e.g., CG-SDT-TAT). In some implementations, in response to receiving the CG-SDT configuration or thereafter, the UE 102 uses the CG-SDT time alignment timer value to start or restart the UE CG-SDT timer (i.e., the first UE CG-SDT timer). In some cases where the UE CG-SDT timer expires, the UE 102 releases the CG-SDT configuration. In other cases where the UE CG-SDT timer expires, the UE 102 retains the CG-SDT configuration instead and avoids sending UL transmissions (e.g., MAC PDUs) on the CG resources. In some such cases, the UE 102 releases the CG resources or determines that the CG resources are invalid. When the UE CG-SDT timer expires, the UE 102 may release the SRS configuration or the SRS resources configured in the SRS configuration. Alternatively, when the UE CG-SDT timer expires, the UE 102 retains the SRS configuration and refrains from sending one or more SRS to the DU 174 on the SRS resources.

[0114] While the UE CG-SDT timer is running, the inactive UE 102 communicates with the DU 174 via the dedicated DL BWP and the dedicated UL BWP (e.g., performs CG-SDT, sends SRS and / or receives DL control signals (e.g., DCI) and / or data). In some implementations, when the UE CG-SDT timer expires, the inactive UE 102 switches from the dedicated DL BWP and the dedicated UL BWP to the initial DL BWP and the initial UL BWP, respectively. In such cases, the UE 102 can re-tune the transceiver of the UE 102 to switch to the initial DL BWP and the initial UL BWP. In some implementations, when the UE 102 is configured with a CG-SDT configuration, the inactive UE 102 can switch to the initial DL BWP and the initial ULBWP to perform a random access procedure. The UE 102 can perform a random access procedure for different situations, as described below. In some implementations, the UE 102 in the inactive state switches to the initial DL BWP and the initial UL BWP to perform measurements on the SSBs sent by the DU 174 on the initial DL BWP.

[0115] In some implementations, the DU 174 or CU-CP 174A configures the dedicated DL BWP and the dedicated UL BWP to be the same as or include the initial DL BWP and the initial UL BWP, respectively. In some such implementations, when the UE CG-SDT timer expires, the UE 102 does not switch from the dedicated DL BWP and the dedicated UL BWP to the initial DL BWP and the initial UL BWP, respectively. In further such cases, the UE 102 does not re-tune the transceiver of the UE 102 due to switching BWP. In some such cases, when the UE 102 in an inactive state performs a random access procedure with the DU 174, the UE 102 performs the random access procedure without switching to the initial DL BWP and the initial UL BWP. In further such cases, the UE 102 performs measurements on the SSBs sent by the DU 174 within the initial DL BWP when performing the CG-SDT with the DU 174.

[0116] In some implementations, in response to or after the expiration of the UE CG-SDT timer, the UE 102 performs a RA-SDT with the CU 172 via the DU 174 on the initial UL BWP and the initial DL BWP, such as for Figure 4 That is, in response to or after the UE CG-SDT timer expires, the UE 102 determines that the RA-SDT is valid.

[0117] In some implementations, DU 174 reserves the CG resources configured in the CG configuration. In some implementations, DU 174 releases the CG resources when the SDT DU configuration or the CG-SDT configuration is released or when the DU CG-SDT timer expires. In some implementations, DU 174 releases the SRS resources configured in the SRS configuration when the SDT DU configuration or the CG-SDT configuration is released or when the DU CG-SDT timer expires.

[0118] In the case where DU 174 does not provide CG-SDT configuration or SDT DU configuration to CU-CP 172A, DU 174 releases all signaling and user data transmission resources for UE 102 in response to the third CU-to-DU message. In the case where DU 174 provides SDT DU configuration or CG-SDT configuration to CU-CP 172A, DU 174 reserves signaling and user data transmission resources for UE 102 in response to receiving the third CU-to-DU message or after receiving the third CU-to-DU message.

[0119] In the case where the SDT DU configuration does not include a configuration for CG-SDT, CU-CP 172A and / or DU 174 only configures RA-SDT for UE 102. In some such cases, UE 102 Figure 4 The RA-SDT with the CU 172 is performed via the DU 174 .

[0120] In some implementations, when determining to transition UE 102 to an inactive state configured with SDT, CU-CP 172A does not request DU 174 to provide an SDT DU configuration. In some such cases, events 328 and 330 are omitted, and CU-CP 172A does not include the SDT DU configuration in the RRC release message. Alternatively, CU-CP 172A generates the SDT DU configuration on its own without requesting DU 174 to provide the SDT DU configuration, and includes the SDT DU configuration in the RRC release message.

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

[0122] In some implementations, such as when UE 102 supports CG-SDT and / or DU 174 supports CG-SDT, CU-CP 172A requests DU 174 to provide SDT DU configuration, as described above. In the case where UE 102 does not support CG-SDT or DU 174 does not support CG-SDT, CU-CP 172A does not request DU 174 to provide SDT DU configuration. In some implementations, when the UE operates 302 in a connected state, CU-CP 172A receives UE capabilities (e.g., UE-NR-Capability IE) of UE 102 from UE 102, CN 110 (e.g., MME 114 or AMF 164), or base station 106. UE capabilities indicate whether UE 102 supports CG-SDT. Therefore, CU-CP 172A can determine whether the UE supports CG-SDT based on the UE capabilities. In some implementations, CU-CP 172A receives a DU-to-CU message from DU 174 indicating whether DU 174 supports CG-SDT. In some implementations, the DU-to-CU message is a second DU-to-CU message, a message of event 308 or 316, or a non-UE associated message (e.g., a non-UE associated F1AP message defined in 3GPP specification 38.473).

[0123] In some implementations, depending on whether the UE 102 supports CG-SDT, the DU 174 determines whether to provide the SDT DU configuration for the UE 102 to the CU-CP 172A. In further implementations, in addition to whether the UE 102 supports CG-SDT, the DU 174 additionally determines whether to provide the SDT DU configuration for the UE 102 to the CU-CP 172A depending on whether the DU 174 supports CG-SDT. In the event that the UE 102 supports CG-SDT and / or the DU 174 supports CG-SDT, the DU 174 provides the SDT DU configuration for the UE 102 to the CU-CP 172A, as described above. In the event that the UE 102 does not support CG-SDT or the DU 174 does not support CG-SDT, the DU 174 does not provide the SDT DU configuration for the UE 102 (e.g., the DU 174 does not include the SDT DU configuration in the second DU to CU message). In some implementations, when the UE is operating 302 in a connected state or in an inactive state before event 302, the DU 174 receives the UE capabilities from the CU-CP 172A. Therefore, the DU 174 can determine whether the UE supports CG-SDT based on the UE capabilities. In some implementations, the DU 174 sends a DU-to-CU message to the CU-CP 172A indicating whether the DU 174 supports or does not support CG-SDT, as described above.

[0124] Reference now Figure 4 , scenario 400 depicts a small data transmission similar to scenario 300, but wherein UE 102 is in an inactive state. In scenario 400, base station 104 includes CU 172 and DU 174. CU 172 includes CU-CP 172A and CU-UP 172B. In scenario 400, UE 102 initially operates in an inactive state with SDT configured 402. In some implementations or scenarios, UE 102 transitions from a connected state with SDT configured to an inactive state, such as for Figure 3 In some such implementations, the UE receives an RRC release message including the first SDT CU configuration and / or the first SDT DU configuration from the CU-CP 172A (eg, events 332, 334).

[0125] In other implementations or scenarios, the UE 102 transitions from an inactive state in which SDT is not configured to an inactive state in which SDT is configured. For example, the UE 102 receives an RRC release message from a base station (e.g., base station 104 or base station 106) that causes the UE 102 to transition to an inactive state but does not configure SDT (e.g., indicates release of SDT, or does not include the SDT configuration in the RRC release message). In this case, the UE 102 transitions to an inactive state in which SDT is not configured in response to the RRC release message. In some implementations, the UE 102 in an inactive state with or without SDT configured performs a RAN Notification Area (RNA) update with the base station without a state transition. During the RNA update, the UE 102 receives another RRC release message from the base station that includes a first SDT CU configuration and / or a first SDT DU configuration similar to the RRC release message of events 332, 334. Figure 4 The components in (e.g., UE 102, CU 172, DU 174, etc.) can be connected with Figure 3 Components with equivalent numbers may be the same or different.

[0126] Later, the UE 102 operating in the inactive state configured with SDT initiates SDT. In response to or after initiating SDT, the UE 102 generates an initial UL MAC PDU including a UL RRC message and sends an initial UL MAC PDU to a cell (e.g., cell 124 or base station 104). Figure 1A404 an initial UL MAC PDU is sent to DU 174 on another cell not shown in the figure. The following events between UE 102 and DU 174 occur on the cell. In some implementations, UE 102 starts an SDT session timer in response to initiating an SDT. In some implementations, the SDT session timer is a new timer (e.g., as defined in the RRC specification (e.g., v17.0.0)). DU 174 retrieves the UL RRC message from the initial UL MAC PDU, generates a first DU to CU message including the UL RRC message, and sends 406 the first DU to CU message to CU-CP 172A. In some implementations, the first DU to CU message is an initial UL RRC messaging message. In other implementations, the first DU to CU message is a UL RRC messaging message.

[0127] In a scenario where the UE 102 initiates an SDT to send UL data eligible for SDT, the UE 102 includes the UL data in an initial UL MAC PDU that the UE 102 sends 404. In some implementations, the UL data includes a PDU (e.g., a PDCP PDU) or a data packet (e.g., an IP packet or an Ethernet packet). In a scenario where the UE 102 initiates an SDT to receive DL data, the UE 102 does not include the UL data packet in the initial UL MAC PDU that the UE 102 sends 404. In some implementations, the UE 102 initiates an SDT to receive DL data in response to receiving a paging from the DU 174. In some such scenarios, the UE 102 includes an SDT indication for indicating to the base station 104 that the UE 102 is initiating an SDT to receive DL data in an initial UL MAC PDU or a UL RRC message. In some implementations, the DL data includes a PDU (e.g., a PDCP PDU) or a data packet (e.g., an IP packet or an Ethernet packet).

[0128] In some implementations, the UE 102 in an inactive state performs a random access procedure with the DU 174 to send 404 a UL MAC PDU. In some such cases, the SDT is a RA-SDT. For example, the random access procedure may be a four-step random access procedure or a two-step random access procedure. In the case of a four-step random access procedure, the UE 102 sends a random access preamble to the DU 174, and in response, the DU 174 sends a random access response (RAR) including an uplink grant, a temporary C-RNTI, and a timing advance command to the UE 102, and the UE 102 sends 404 a UL MAC PDU to the DU 174 according to the uplink grant. The DU 174 receives 404 the UL MAC PDU according to the uplink grant in the RAR, and in response, sends a DL MAC PDU including a contention resolution MAC control element to the UE 102. In the case of a two-step random access procedure, the UE 102 sends 404 a message A (MsgA) including a random access preamble and a UL MAC PDU to the DU 174 according to the two-step random access configuration parameters. In some implementations, the UE 102 receives a message B (MsgB) including a temporary C-RNTI and a timing advance command from the DU 174 in response to the MsgA. In a further implementation, the DU 174 includes a contention resolution MAC control element in the MsgB. The UE 102 receives the two-step random access configuration parameters in the system information broadcasted by the DU 174 on the cell 124 before sending 404 the UL MAC PDU. The DU 174 receives 404 the UL MAC PDU according to the two-step random access configuration parameters.

[0129] When UE 102 successfully resolves contention (i.e., receives a contention resolution MAC control element) during the random access procedure, UE 102 discards the previously reserved C-RNTI (e.g., for Figure 3 418 UL data and / or DL ​​data). In detail, the UE 102 receives the DCI and the cyclic redundancy check (CRC) of the DCI on the PDCCH from the DU 174, and verifies the CRC using the C-RNTI. Depending on the implementation, the DCI includes an uplink grant or a downlink assignment. If the UE 102 verifies that the CRC is correct and the DCI includes an uplink grant, the UE 102 uses the uplink grant to send 418 UL data to the DU 174. If the UE 102 verifies that the CRC is correct and the DCI includes a downlink assignment, the UE 102 uses the downlink assignment to receive 418 DL data from the DU 174.

[0130] In other implementations, such as when UE 102 receives or is configured with a CG configuration (e.g., Figure 3 In some implementations, in response to or after generating or sending the 404 UL MAC PDU, the UE 102 starts a UE timer (e.g., a second UE CG-SDT timer) when the CU-CP 172A or DU 174 configures the UE 102 to apply the UE timer during the SDT. In some implementations, the UE 102 uses a UE timer value (e.g., a cg-SDT-RetransmissionTimer value) to start the UE timer. In some implementations, the UE 102 receives an RRC release message including a UE timer value from the base station 104, similar to events 332, 334, 432, and 434. In some implementations, CP-CP172A includes the UE timer value in the CG-SDT configuration and sends the RRC release message including the CG-SDT configuration to UE 102 via DU 174. In other implementations, UE 102 receives the UE timer value in a system information block broadcast by DU 174 via cell 124. While the UE timer is running, the UE 102 in an inactive state or SDT session avoids retransmitting UL MAC PDUs on CG resources. In some implementations, in response to receiving 404 to the UL MAC PDU on the CG resources or thereafter, DU 174 uses the DU timer value to start a DU timer (e.g., a second DU CG-SDT timer). In some implementations, the DU timer value is the same as or greater than the UE timer value. While the DU timer is running, DU174 processes the UL transmission received from UE 102 on the CG resources as a new transmission.

[0131] In some implementations, the UE 102 sends 418 a subsequent UL MAC PDU including one or more UL data packets on the CG radio resources. In some implementations, the UE 102 sends 418 the subsequent UL MAC PDU on the radio resources configured in the uplink grant received on the PDCCH from the DU 174. In some implementations, the UE 102 sends 418 some of the subsequent UL MAC PDUs on the radio resources configured in the CG configuration and sends 418 other of the subsequent UL MAC PDUs on the radio resources configured in the uplink grant.

[0132] In some cases where the UE 102 sends 418 subsequent UL MAC PDUs on the CG resources, in response to or after generating or sending 418 each of the subsequent UL MAC PDUs, the UE 102 starts or restarts a timer (e.g., a second UE CG-SDT timer). The UE 102 may start or restart the timer using a timer value as described above. While the UE timer is running, the UE 102 in an inactive state or SDT session avoids retransmitting the UL MAC PDU. In some implementations, in response to or after receiving 418 each of the subsequent UL MAC PDUs on the CG resources, the DU 174 starts or restarts the DU timer (e.g., a second DU CG-SDT timer) using the DU timer value. While the DU timer is running, the DU 174 processes the UL transmission received from the UE 102 on the CG resources as a new transmission.

[0133] If the UE 102 includes the UL data in the initial UL MAC PDU, the DU 174 retrieves the UL data from the initial UL MAC PDU 404. In some such cases, the DU 174 includes the UL data in the DU to CU message of event 406. Alternatively, the DU 174 sends 415 a DU to CU message including the UL data to the CU-CP 172A. In some such alternatives, the UL data includes or is a PDCP PDU, an RRC PDU, a NAS PDU, or an LTE Positioning Protocol (LPP) PDU. The PDCP PDU may include an RRC PDU. The UL data may be associated with an SRB (e.g., SRB1 or SRB2). In some implementations, the UE 102 applies one or more security functions (e.g., encryption and / or integrity protection) to the UL data, as described above. The CU-CP 172A applies one or more security functions (e.g., decryption and / or integrity protection checking) to the UL data, as described above. Alternatively, DU174 sends 416 UL data to CU-UP 172B separately via a user plane (UP) connection (e.g., a GTP tunnel), as described below. In some such alternatives, the UL data includes or is a PDCP PDU, a SDAP PDU, an IP packet, or an Ethernet packet. In some implementations, the UL data is associated with an SDT DRB. In some implementations, the UE 102 applies one or more security functions (e.g., encryption and / or integrity protection) to the UL data, as described above. The CU-UP 172B applies one or more security functions (e.g., decryption and / or integrity protection check) to the UL data, as described above.

[0134] After receiving 406 the first DU-to-CU message, in some implementations, the CU-CP 172A sends 408 a UE context request message to the DU 174 to request the DU 174 to establish a UE context for the UE 102. In some implementations, in the UE context request message, the CU-CP 172A includes transport layer information of one or more GTP-U tunnels between the CU-UP 172B and the DU 174, so that the DU 174 can send UL data and / or subsequent UL data (e.g., in a small data communication 418) to the CU-UP 172B via the one or more GTP-U tunnels. In response, depending on the implementation, the DU 174 sends 410 a UE context response message to the CU-CP 172A.

[0135] In some implementations, the UE context request message and the UE context response message are a UE context setup request message and a UE context setup response message, respectively. In some such implementations, events 408 and 410 are grouped as a UE context setup procedure. In other implementations, the UE context request message and the UE context response message are a UE context modification request message and a UE context modification response message, respectively. In some implementations, such as when DU 174 already has a UE context for UE 102, CU-CP 172A does not send a UE context request message to DU 174. In some such implementations, events 408 and 410 may be omitted or skipped.

[0136] After receiving 406 the first DU to CU message, sending 408 the UE context request message, or receiving 410 the UE context response message, CU-CP 172A sends 412 a bearer context modification request message to CU-UP 172B to resume the SDT DRBs of UE 102. In response, CU-UP 172B resumes the SDT DRBs and sends 414 a bearer context modification response message to CU-CP 172A. Events 412 and 414 may be grouped as a bearer context modification process. In some implementations, CU-CP 172A includes a resume indication (e.g., a bearer context state change IE with a "ResumeforSDT" value) in a bearer context modification request message 424 to instruct CU-UP 172B to resume the SDT DRBs. In response to the resume indication, CU-UP 172B resumes the SDT DRBs and maintains the non-SDT DRBs as suspended or suspends the non-SDT DRBs.

[0137] In some implementations, after receiving 406 a to-UL RRC message, receiving 408 a to-UE context request message, or sending 410 a UE context response message, such as in the case where the UL data of event 404 includes an RRC message or is associated with an SRB (e.g., SRB1 or SRB2), DU 174 sends 415 a DU to CU message including the UL data to CU-CP 172A. In some cases where the UL data is associated with a DRB, after receiving 406 a to-UL RRC message, receiving 408 a to-UE context request message, or sending 410 a UE context response message, DU 174 sends 416 the UL data to CU-CP 172B.

[0138] In some implementations, the CU-CP 172A includes the transport layer information of the CU-UP 172B in the UE context request message. The transport layer information of the CU-UP 172B may include an IP address and / or an uplink tunnel endpoint ID (e.g., TEID). In some implementations, the DU 174 uses the transport layer information of the CU-UP 172B to send 416 UL data to the CU-UP 172B. In some cases where the UE 102 has subsequent UL data to send (e.g., one or more UL data packets), the UE 102 sends 418 one or more subsequent UL MAC PDUs including the subsequent UL data to the DU 174. Then, the DU 174 retrieves the subsequent UL data from the subsequent UL MAC PDU. In the case where the subsequent UL data is associated with one or more SRBs (e.g., SRB1 and / or SRB2), the DU 174 sends 418 one or more DU to CU messages (e.g., UL RRC messaging messages) including the subsequent UL data to the CU-CP 172A. Each DU to CU message may include a specific UL data packet of subsequent UL data. In some cases where the CU-CP 172A receives DL data from the CN 110 or edge server, the CU-CP 172A sends 418 one or more CU to DU messages (e.g., DL RRC messaging messages) including the DL data (e.g., one or more DL data packets) to the DU 174. In turn, the DU 174 sends 418 one or more DL MAC PDUs including the DL data to the UE 102 operating in the inactive state. In some implementations, the DL data includes or is a NAS PDU and / or an LPP PDU.

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

[0140] In some implementations, the UE 102 includes a buffer status report or a power headroom report in an initial and / or subsequent UL MAC PDU (e.g., based on a BSR configuration and / or a PHR configuration, respectively). In a buffer status report, the UE 102 may include or indicate a buffer status of one or more logical channels or logical channel groups thereof. In a power headroom report, the UE 102 may include or indicate a power headroom status or value.

[0141] In some example scenarios, the subsequent UL data and / or DL ​​data described above include Internet Protocol (IP) packets, Ethernet packets, or application packets. In other scenarios, the UL data includes or is a PDU (e.g., RRC PDU, PDCP PDU, or RLC PDU), which includes an RRC message, a NAS message, an LCS message, an LPP PDU, an IP packet, an Ethernet packet, or an application packet.

[0142] In some implementations, the UE 102 initiates an SDT to perform location services (LCS) and / or positioning. Depending on the implementation, the LCS is a mobile originated location request (MO-LR), a mobile terminated location request (MT-LR), or a deferred MT-LR. In some such implementations, the PDUs 404, 418 include an LCS message and / or an LTE Positioning Protocol (LPP) message. In some implementations, the UE 102 operating 402 in an inactive state has been configured with a first SRS configuration or a first SRS resource configuration. The UE 102 receives a first SRS configuration or a first SRS resource configuration in an RRC release message (e.g., Figure 3 4. In some implementations, during communication 418, UE 102 sends an SRS to DU 174 according to a first SRS configuration or a first SRS resource configuration. DU 174 receives the SRS, performs measurement on the received SRS to obtain a measurement result, and sends a DU-to-CU message (e.g., a positioning measurement response message) including the measurement result to CU-CP 172A. CU-CP 172A sends a BS-to-LMF message (e.g., an NRPPa message, such as a measurement response message) including the measurement result to LMF 168.

[0143] In some implementations, the DU 174 sends 418 a DL MAC PDU including an SRS activation command (e.g., a MAC control element) to the UE 102 to activate the first SRS configuration or the first SRS resource configuration. The UE 102 sends the SRS after receiving the SRS activation command. In some implementations, the DU 174 does not send an SRS activation command to the UE 102 to activate the first SRS configuration or the first SRS resource configuration during the SDT. In some such cases, the UE 102 avoids sending the SRS because the first SRS configuration or the first SRS resource configuration has not yet been activated.

[0144] Events 404, 406, 408, 410, 412, 414, 415, 416, and 418 are Figure 4 are collectively referred to as small data communication process 492.

[0145] In some implementations, the UL RRC message is an existing RRC recovery request message (e.g., RRCResumeRequest message, RRCResumeRequest1 message, RRCConnectionResumeRequest message, or RRCConnectionResumeRequest1 message). In other implementations, the UL RRC message is a new RRC recovery request message, similar to the existing RRC recovery request message. For example, the new RRC recovery request message may be defined in a future 3GPP standard document. The new RRC recovery request message may be in the format of an existing RRC recovery request message. In some implementations, for a downlink SDT, the UL RRC message includes an SDT indication, which may be a field or an information element (IE) (e.g., resumeCause or ResumeCause). In some implementations, the UL RRC message is a common control channel (CCCH) message.

[0146] After UE 102 sends 404 an UL MAC PDU or communicates 418 subsequent UL data and / or DL ​​data with DU 174, CU-CP 172A, CU-UP 172B, or DU 174 may determine that UE 102 is in data inactivity based on UE assistance information, an inactivity notification of event 422, and / or an inactivity notification of event 423, as described above with respect to Figure 3 described.

[0147] In some implementations, after a specific period of data inactivity, the CU-CP 172A determines that the CU 172 or the UE 102 did not send any data in the downlink direction or the uplink direction during the period, respectively. In response to this determination, the CU-CP 172A may determine to stop the SDT. Alternatively, the CU-CP 172A determines to immediately stop the SDT of the UE 102 in response to determining that the UE 102 is in data inactivity.

[0148] In response to or after determining that UE 102 is in data inactivity (for the particular period) or determining to transition UE 102 to an inactive state with SDT configured, CU-CP 172A configures the SDT DU configuration by executing events 424, 426 and / or 428, which are similar to events 324, 326 and / or 328, respectively.

[0149] Similarly, in response to the SDT request indication or the second CU-to-DU message, the DU 174 sends 430 a second DU-to-CU message (e.g., a UE context modification response message) to the CU-CP 172A. In some implementations, the DU 174 includes the second SDT DU configuration in the second DU-to-CU message. In some cases where the DU 174 obtains the first SDT DU configuration, the DU 174 generates the second SDT DU configuration as an extension (e.g., replacement or update) of the first SDT DU configuration. In some implementations, the DU 174 generates the second SDT DU configuration as a complete and self-contained configuration (i.e., a complete configuration) (e.g., because the DU 174 does not support incremental configuration or any configuration parameter in the first SDT DU configuration is invalid). In some such implementations, the DU 174 includes a first indication in the second DU-to-CU message indicating that the second SDT DU configuration is a complete and self-contained configuration (i.e., a complete configuration). For example, the first indication may be a setup indication or a complete configuration indication.

[0150] In other implementations, DU 174 generates the second SDT DU configuration as part of updating the first SDT DU configuration (e.g., because DU 174 supports incremental configuration). In some scenarios or implementations, DU 174 receives the first SDT DU configuration from CU-CP 172A (e.g., in a second CU-to-DU message). In other scenarios or implementations, the second CU-to-DU message does not include the first SDT DU configuration. In some such cases, DU 174 still generates the second SDT DU configuration as an augmented first SDT DU configuration because DU 174 generates and retains the first SDT DU configuration. In such implementations, DU 174 avoids including the first indication in the second DU-to-CU message to indicate that the second SDT DU configuration is an incremental configuration (i.e., the second SDT DU configuration includes configuration parameters that augment the first SDT DU configuration). In some implementations, DU 174 includes an indication in the second DU-to-CU message that the second SDT DU configuration is an incremental configuration. Alternatively, the DU 174 includes neither the second indication nor the first indication so as to indicate that the second SDT DU configuration is an incremental configuration.

[0151] Alternatively, DU 174 does not include the second SDT DU configuration in the second DU to CU message. Instead, (e.g., after receiving the second CU to DU message and / or sending the second DU to CU message) DU 174 sends another DU to CU message (e.g., UE context modification required message) including the second SDT DU configuration to CU-CP 172A. In some alternative implementations, CU-CP 172A sends the second CU to DU message before or after determining that UE 102 is in data inactivity and receives the second DU to CU message or another DU to CU message.

[0152] In still other implementations, DU 174 determines to continue configuring the first SDT DU configuration for UE 102. In some such cases, DU 174 does not include the first SDT DU configuration in the second DU to CU message. After CU-CP 172A receives the second DU to CU message that does not include the SDT DU configuration, CU-CP 172A determines that DU 174 continues to reuse the first SDT DU configuration for UE 102. In some implementations, DU 174 includes an indication in the second DU to CU message that the first SDT DU configuration continues to be used for UE 102. In other implementations, in the second DU to CU message, DU 174 indicates that the first SDT DU configuration is reused for UE 102 by not including the SDT DU configuration in the second DU to CU message.

[0153] In yet other implementations, CU-CP 172A avoids sending the first SDT DU configuration to DU 174. For example, CU-CP 172A avoids including the first SDT DU configuration in the second CU-to-DU message. In some cases where DU 174 does not have the first SDT DU configuration, DU 174 generates the second SDT DU configuration as a complete and self-contained configuration (e.g., a complete SDTDU configuration).

[0154] In yet other implementations, CU-CP 172A includes in the second CU-to-DU message an indication to DU 174 to generate the SDT DU configuration as a complete and self-contained configuration (e.g., a complete SDT DU configuration). In response to the indication, DU 174 generates the second SDT DU configuration as a complete and self-contained configuration (e.g., a complete SDT DU configuration).

[0155] In yet other implementations, the DU 174 determines to release the first SDT DU configuration and not configure the SDTDU configuration for the UE 102. In some such cases, the DU 174 includes an indication in the second DU to CU message indicating that the SDTDU configuration is not configured for the UE 102. For example, the indication may be a reason indicating why the DU 174 cannot configure the SDT DU configuration for the UE 102.

[0156] In some implementations, CU-CP 172A sends 429 a CU to DU message to request DU 174 to allocate SRS resources for UE 102, similar to event 329. In response to CU to DU message 429, DU 174 sends 431 a DU to CU message including a second SRS resource configuration or a second SRS configuration to CU-CP 172, similar to event 331. Depending on the implementation, the second SRS configuration is a full configuration (i.e., a self-contained and complete configuration) or an incremental configuration (e.g., based on (on top of) the first SRS configuration or the first SRS resource configuration).

[0157] In some implementations, in response to determining that the UE 102 is to be transitioned to an inactive state configured with an SDT, the CU-CP 172A generates an RRC release message (e.g., an RRCRelease message, an RRCConnectionRelease message) to transition the UE 102 to an inactive state. In some implementations, the CU-CP 172A includes the second SDT DU configuration (if obtained from the DU 174) and the second SDT CU configuration in the RRC release message. Alternatively, the CU-CP 172A does not include the SDT configuration in the RRC release message. In some such alternatives, the CU-CP 172A instructs the UE 102 to release or retain the first SDT CU configuration and / or the first SDT DU configuration in the RRC release message. For example, the CU-CP 172A may include a release indication indicating the release of the first SDT CU configuration or the first SDT DU configuration in the RRC release message. If CU-CP 172A or DU 174 determines to reuse the first SDT DU configuration, the RRC release message does not include a release indication, and the UE retains the first SDT CU configuration and / or the first SDT TU configuration. In some implementations, CU-CP 172A may or may not include the first SDT DU configuration in the RRC release message.

[0158] In some implementations, CU-CP 172A includes the second SRS configuration or the second SRS resource configuration in the RRC release message. In some implementations, CU-CP 172A includes the first SRS configuration in the CU to DU message of event 429. In some such cases, DU 174 generates the second SRS configuration or the second SRS resource configuration as an incremental configuration that expands (e.g., modifies) the first SRS configuration or the first SRS resource configuration. Alternatively, DU 174 generates the second SRS configuration or the second SRS resource configuration as a complete configuration that expands (e.g., replaces) the first SRS configuration or the first SRS resource configuration. In some implementations, DU 174 indicates whether to release the first SRS configuration or the first SRS resource configuration in the second SRS configuration or the second SRS resource configuration. For example, DU 174 may include a release indication for indicating the release of the first SRS configuration or the first SRS resource configuration in the RRC release message, the second SRS configuration, or the second SRS resource configuration. If the RRC release message, the second SRS configuration, or the second SRS resource configuration includes a release indication, the UE 102 releases the first SRS configuration or the first SRS resource configuration. In such a case, the second SRS configuration or the second SRS resource configuration replaces the first SRS configuration or the first SRS resource configuration. In some implementations, the release indication includes an ID (e.g., SRS-PosResourceSetId IE or SRS-PosResourceSetId-r16 IE) identifying the first SRS resource configuration. Otherwise, if the second SRS configuration or the second SRS resource configuration does not include a release indication and includes the same ID as the first SRS configuration or the first SRS resource configuration, the UE 102 uses the first SRS configuration or the first SRS resource configuration to expand the first SRS configuration or the first SRS resource configuration.

[0159] If UE 102 has been configured with the first SRS configuration or the first SRS resource configuration as described above, in some implementations, CU-CP 172A does not include the SRS configuration or the SRS resource configuration in the RRC release message to configure UE 102 to apply the first SRS configuration or the first SRS resource configuration.

[0160] Then, the CU-CP 172A sends 432 a third CU-to-DU message including an RRC release message to the DU 174. In turn, the DU 174 sends 434 the RRC release message to the UE 102. In some implementations, the DU 174 generates a MAC PDU including the RRC release message and sends 434 the MAC PDU to the UE 102. The RRC release message instructs the UE 102 to transition to an inactive state. The UE 102 stops the SDT upon receiving 434 the RRC release message and remains 436 in the inactive state.

[0161] Events 420, 421, 422, 423, 424, 426, 428, 430, 429, 431, 432, and 434 are Figure 4 are collectively referred to as SDT completion process 494.

[0162] During the SDT session (i.e., events 492 and 494), UE 102 monitors PDCCH using C-RNTI to receive DCI. In some implementations, UE 102 receives C-RNTI during the random access procedure described for event 404. In other implementations, UE 102 receives and retains C-RNTI, such as for Figure 3 In response to receiving 434 the RRC release message or thereafter, the UE 102 ends the SDT session and stops using the C-RNTI to monitor the PDCCH. In some implementations, in response to receiving 434 the RRC release message or transitioning 436 from the connected state to the inactive state or thereafter, the UE 102 retains the C-RNTI. In the case where the RRC release message 434 configures the CG-SDT, in some implementations, the UE 102 retains the C-RNTI. In some cases where the RRC release message 434 does not configure or release the CG-SDT, the UE 102 releases the C-RNTI.

[0163] After UE 102 ends the SDT session, the inactive UE 102 uses a paging RNTI (P-RNTI) to monitor the PDCCH. In some scenarios or implementations, the CU-CP 172A determines to page the UE 102 to receive a mobile terminated call or data. In some implementations, in response to the determination, the CU-CP 172A sends a CU-to-DU message (e.g., a paging message) to the DU 174 to request the DU 174 to page the UE 102. In response to the CU-to-DU message, the DU 174 generates a paging message, a DCI for scheduling a PDSCH transmission including the paging message, a CRC of the DCI; scrambles the CRC using the P-RNTI to obtain a scrambled C-RNTI; and sends the DCI and the scrambled CRC on the PDCCH monitored by the UE 102. The UE 102 receives the DCI and the scrambled CRC on the PDCCH and verifies the scrambled CRC using the G-RNTI. In the event that the UE 102 verifies that the scrambled CRC is valid, the UE 102 receives and decodes the PDSCH transmission according to the DCI and retrieves the paging message from the PDSCH transmission.

[0164] In some implementations, the second SDT CU configuration is the same as the first SDT CU configuration. In other implementations, the second SDT CU configuration is different from the first SDT CU configuration. Depending on the implementation, the UE 102 updates (e.g., replaces or modifies) the first SDT CU configuration using the second SDT CU configuration. In some implementations, the CU-CP 172A includes an indication in the RRC release message for indicating that the UE 102 updates the first SDT CU configuration using the second SDT CU configuration. In some such implementations, the UE 102 updates the first SDT CU configuration using the second SDT CU configuration in response to the indication. In other implementations, the CU-CP 172A includes a modification indication in the RRC release message for indicating that the UE 102 modifies the first SDT CU configuration using the second SDT CU configuration. In some such implementations, the UE 102 modifies the first SDT CU configuration using the second SDT CU configuration in response to the modification indication. In yet other implementations, CU-CP 172A includes a setup indication in the RRC release message for instructing UE 102 to replace the first SDT CU configuration with the second SDT CU configuration. In some such implementations, UE 102 replaces the first SDT CU configuration with the second SDT CU configuration in response to the setup indication.

[0165] In some implementations, the CU-CP 172A does not include the SDT CU configuration for the UE 102 in the RRC release message 432, 434 so as to configure the UE 102 to retain the first SDT CU configuration and keep using the first SDT CU configuration. When the UE 102 receives 434 the RRC release message, the UE 102 retains the first SDT CU configuration.

[0166] In some implementations, the second SDT DU configuration is the same as the first SDT DU configuration. In other implementations, the second SDT DU configuration is different from the first SDT DU configuration. Depending on the implementation, the UE 102 updates (e.g., replaces or modifies) the first SDT DU configuration with the second SDT DU configuration, similar to the SDT CU configuration described above.

[0167] In some implementations, the CU-CP 172A does not include the SDT DU configuration for the UE 102 in the RRC release message in order to configure the UE 102 to retain the first SDT DU configuration and keep using the first SDT DU configuration.

[0168] In some cases where the CU-CP 172A and / or DU 174 support incremental configuration, the CU-CP 172A does not send 428 a CU to DU message to obtain a second SDT DU configuration from the DU 174. Unless the conditions for releasing the first SDT configuration are met, the DU 174 retains the first SDT DU configuration. Alternatively, the CU-CP 172A includes the first SDT DU configuration in the second CU to DU message so that the DU 174 retains the first SDT DU configuration. In some such cases, the CU-CP 172A does not include the SDT DU configuration and / or the SDTCU configuration in the RRC release message so that the UE 102 continues to use the first SDT CU configuration and / or the first SDU DU configuration. In some implementations, the CU-CP 172A does not include a release indication in the RRC release message so as to configure the UE to continue to use the first SDT DU configuration and / or the first SDT CU configuration. The release indication indicates the release of the previously received SDT DU configuration and / or SDT CU configuration. In some cases where the CU-CP 172A includes the release indication in the RRC release message, the UE 102 releases the first SDT CU configuration and / or the first SDT DU configuration in response to the release indication.

[0169] In some cases where the CU-CP 172A and / or the DU 174 do not support incremental configuration, the CU-CP 172A includes the SDT DU configuration and / or the SDT CU configuration in the RRC release message as described above.

[0170] In some implementations, in response to the third CU-to-DU message, DU 174 retains the second SDT DU configuration and releases or does not release the first non-SDT DU configuration and / or the second non-SDT DU configuration. In further implementations, in response to the third CU-to-DU message, DU 174 sends a third DU-to-CU message (e.g., a UE context release complete message or a UE context modification response message) to CU-CP 172A. In some implementations, if the RRC release message instructs UE 102 to transition to an inactive state (i.e., RRC_IDLE), UE 102 releases the non-SDT configuration (e.g., for RRC_CONTENT). Figure 3 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) and at least one SDT configuration (e.g., for Figure 3 The SDT DU configuration and SDT CU configuration described above).

[0171] Events 420 (optional), 421 (optional), 422 (optional), 423, 424, 426, 428, 430, 432, and 434 are Figure 4 492. The SDT completion process 494 is collectively referred to as the SDT completion process 494, which is similar to the process 394. The examples and implementations for events 320, 321, 322, 323, 324, 326, 328, 330, 329, 331, 332, 334 can be respectively applicable to events 420, 421, 422, 423, 424, 426, 428, 430, 429, 431, 432, 434. After stopping the SDT, the UE 102 can perform 493 another small data communication process with the base station 104, which is similar to the process 492. After completing the process 493, the base station 104 can perform 495 an SDT completion process with the UE 102 similar to the process 494.

[0172] In some implementations, CU-CP 172A does not request DU 174 to provide an SDT DU configuration to transition UE 102 to an inactive state configured with SDT. In some such cases, events 428 and 430 are omitted. In such cases, CU-CP 172A does not include the SDT DU configuration in the RRC release message. Alternatively, CU-CP 172A generates the SDT DU configuration on its own and includes the SDT DU configuration in the RRC release message.

[0173] In some implementations, DU 174 does not include the SDT DU configuration in the second DU to CU message (e.g., if or because UE 102 does not support CG-SDT, DU 174 does not support CG-SDT, or DU 174 does not have available radio resources for CG-SDT). In such cases, the RRC release message does not include the SDT DU configuration. Otherwise, depending on the implementation, DU 174 includes the SDT DU configuration, as described above. In some implementations, DU 174 does not include the CG-SDT configuration in the SDT DU configuration in the second DU to CU message (e.g., if or because UE 102 does not support CG-SDT, DU 174 does not support CG-SDT, or DU 174 does not have available radio resources for CG-SDT). In such cases, the SDT DU configuration does not include the CG-SDT configuration. Otherwise, depending on the implementation, DU 174 includes the CG-SDT configuration in the SDT DU configuration, as described above.

[0174] In some implementations, such as when UE 102 supports CG-SDT and / or DU 174 supports CG-SDT, CU-CP 172A requests DU 174 to provide SDT DU configuration, as described above. In the case where UE 102 does not support CG-SDT or DU 174 does not support CG-SDT, CU-CP 172A does not request DU 174 to provide SDT DU configuration. In some implementations, before UE 102 initiates SDT, when the UE is operating in an inactive state 402, when the UE performs SDT (e.g., in a UE context setup request message of event 408 or a CU to DU message of event 428), or when the UE is performing SDT such as for Figure 3 When operating in the connected state, CU-CP 172A receives UE capabilities (e.g., UE-NR-Capability IE) of UE 102 from UE 102, CN 110 (e.g., MME 114 or AMF 164), or base station 106. The UE capabilities indicate whether UE 102 supports CG-SDT. Therefore, CU-CP 172A can determine whether the UE supports CG-SDT based on the UE capabilities. In some implementations, CU-CP 172A receives a DU to CU message from DU 174 indicating whether DU 174 supports CG-SDT. The DU to CU message can be a second DU to CU message, a message of event 308 or 316, or a non-UE associated message (e.g., a non-UE associated F1AP message defined in 3GPP specification 38.473).

[0175] In some implementations, depending on whether the UE 102 supports CG-SDT, the DU 174 determines whether to provide the SDT DU configuration for the UE 102 to the CU-CP 172A. In addition to whether the UE 102 supports CG-SDT, the DU 174 may additionally determine whether to provide the SDT DU configuration for the UE 102 to the CU-CP 172A depending on whether the DU 174 supports CG-SDT. In the event that the UE 102 supports CG-SDT and / or the DU 174 supports or enables CG-SDT, the DU 174 provides the SDT DU configuration for the UE 102 to the CU-CP 172A, as described above. In the event that the UE 102 does not support CG-SDT or the DU 174 does not support CG-SDT, the DU 174 does not provide the SDT DU configuration for the UE 102 (e.g., the DU 174 does not include the SDT DU configuration in the second DU to CU message). In some implementations, DU 174 receives UE capabilities from CU-CP 172A (e.g., when UE 102 is operating in a connected state or in an inactive state). Therefore, DU 174 can determine whether the UE supports CG-SDT based on the UE capabilities. In some implementations, DU 174 sends a DU-to-CU message to CU-CP 172A indicating whether DU 174 supports CG-SDT, as described above.

[0176] Reference now Figure 5A , scenario 500A depicts a small data transmission and a transition from an inactive state with SDT to a connected state with non-SDT. In scenario 500A, base station 104 includes CU 172 and DU 174. CU 172 includes CU-CP 172A and CU-UP 172B. In scenario 500A, UE 102 initially operates 502 in an inactive state with SDT configured, similar to event 402. Then, UE 102 performs 592 a small data communication process with base station 104, similar to event 492.

[0177] In some implementations, during the small data communication process 592, the CU-CP 172A determines (e.g., based on the UL or DL ​​data activity of the UE 102) whether to transition the UE 102 to the connected state. In some implementations, the UE 102 sends 503 a non-SDT indication message to the DU 174 to indicate that UL data is available or to request a transition to the connected state. In some implementations, the UE 102 sends 503 a non-SDT indication message to the DU 174 on the radio resources configured in the CG configuration (or CG-SDT configuration) for SDT. In other implementations, the UE 102 receives an uplink grant on the PDCCH from the DU 174 using the C-RNTI, and sends 503 a non-SDT indication message to the DU 174 on the radio resources configured in the uplink grant. Then, the DU 174 sends 505 a UL RRC messaging message including the non-SDT indication message to the CU-CP 172A. CU-CP 172A determines to transition UE 102 to a connected state in response to or based on a non-SDT indication message. In other implementations, CU-UP 172B receives DL data from CN 110, and in response to receiving the DL data, sends 507 to CU-CP 172A a DL data notification (e.g., a DL data notification message) indicating that DL data is available for transmission. In some implementations, CU-CP 172A determines to transition UE 102 to a connected state in response to or based on a DL data notification. In other implementations, CU-CP 172A determines to transition UE 102 to a connected state based on a measurement result received from UE 102. In yet other implementations, CU-CP 172A receives DL data (e.g., a NAS message) from CN 110, and in response to receiving the DL data, determines to transition UE 102 to a connected state.

[0178] In some implementations, UL data and DL data are associated with a radio bearer (e.g., SRB and / or DRB) of UE 102. For example, UL data includes an RRC message or NAS message associated with an SRB of UE 102. In another example, UL data includes an IP packet associated with a DRB of UE 102. In some implementations, the DRB is an SDT DRB. In other implementations, the DRB is a non-SDT DRB. In some implementations, UE 102 includes the ID of the radio bearer in a non-SDT indication message. Therefore, CU-CP 172A determines whether to cause UE 102 to transition to a connected state based on the ID. For example, if the radio bearer identified by the ID is not eligible for SDT, CU-CP 172A may determine to cause UE 102 to transition to a connected state. Otherwise, CU-CP 172A may determine not to cause UE 102 to transition to a connected state. In some implementations, UE 102 includes data volume information of UL data in a non-SDT indication message. Therefore, CU-CP 172A determines whether to make UE 102 transition to the connected state based on the data amount information. In some implementations, the data amount information includes the total data amount of UL data, which can be quantized or rounded to a value that can be indicated in the data amount information. In a further implementation, the data amount information includes the data amount of each of the radio bearers, which can be quantized or rounded to a value that can be indicated in the data amount information. For example, if the total data amount is higher than a predetermined threshold, CU-CP 172A may determine to make UE 102 transition to the connected state. Otherwise, CU-CP 172A may determine not to make UE 102 transition to the connected state. In another example, if the data amount for a particular radio bearer is higher than a predetermined threshold, CU-CP 172A determines to make UE 102 transition to the connected state. Otherwise, CU-CP 172A determines not to make UE 102 transition to the connected state. In yet another example, if the total data volume is above a predetermined threshold and the data volume of a specific radio bearer is above another predetermined threshold, the CU-CP 172A determines to transition the UE 102 to the connected state. Otherwise, the CU-CP 172A determines not to transition the UE 102 to the connected state.

[0179] In response to or after determining to transition UE 102 to a connected state, CU-CP 172A sends 508 a UE context request message (e.g., a UE context setup request message or a UE context modification request message) to DU 174. In response, DU 174 sends 510 a UE context response message (e.g., a UE context setup response message or a UE context modification response message) to CU-CP 172A. In some implementations, DU 174 includes a non-SDT DU configuration (i.e., a first non-SDT DU configuration) in the UE context response message. After receiving 510 the UE context response message, CU-CP 172A sends 545 a CU to DU message including an RRC resume message (e.g., an RRCResume message or an RRCConnectionResume message) to DU 174. Subsequently, DU 174 sends 546 an RRC resume message to UE 102. In some implementations, DU 174 sends 546 one or more PDUs including an RRC recovery message to UE 102. Depending on the implementation, the PDU is a MAC PDU or an RLC PDU. In some implementations, the CU to DU message is a DL RRC messaging message or a UE context modification request message. In some cases regarding the UE context modification request message, in response, DU 174 sends a UE context modification response message to CU-CP 172A. In response to the RRC recovery message, UE 102 transitions 548 to a connected state and sends 550 an RRC recovery completion message (e.g., an RRCResumeComplete message or an RRCConnectionResumeComplete message) to DU 174. In the case where the UE context response message includes a non-SDT DU configuration, CU-CP 172A includes the non-SDT DU configuration in the RRC recovery message. DU 174 sends 552 a DU to CU message including an RRC recovery completion message to CU-CP 172A. In some implementations, the DU to CU message is a UL RRC messaging message, a UE CONTEXT MODIFICATION REQUIRED message, or a UE CONTEXT MODIFICATION RESPONSE message.

[0180] In some implementations, after determining to transition the UE 102 to the connected state, the CU-CP 172A sends 554 a bearer context request message (e.g., a bearer context setup request message or a bearer context modification request message) to the CU-UP 172B to instruct the CU-UP 172B to resume the radio bearers (e.g., SDT DRBs and / or non-SDT DRBs) of the UE 102 (if suspended). In response, the CU-UP 172B resumes the suspended radio bearers of the UE 102 and sends 556 a bearer context response message (e.g., a bearer context setup response message or a bearer context modification response message) to the CUCP-172A. Events 554 and 556 may be grouped into a bearer context procedure (e.g., a bearer context setup procedure or a bearer context modification procedure).

[0181] In some implementations, the CU-CP 172A sends 554 a bearer context request message after sending 508 a UE context request message, receiving 510 a UE context response message, sending 545 a CU to DU message, or receiving 552 a DU to CU message. In the event that the CU-CP 172A determines that the radio bearers of the UE 102 are not suspended when determining to transition the UE 102 to the connected state, the CU-CP 172A does not send the bearer context request message 554 to the CU-UP 172B. In some implementations, the CU-CP 172A sends 545 a CU to DU message before or after sending 554 a bearer context request message or receiving 556 a bearer context response message.

[0182] In some implementations, CU-CP 172A includes an indication instructing DU 174 to generate a non-SDT configuration in a UE context request message, and DU 174 includes the first non-SDT DU configuration in a UE context response message in response to the indication. In yet other implementations, CU-CP 172A stores a non-SDT DU configuration (i.e., a second non-SDT DU configuration) used by a DU (e.g., DU 174 or another DU or base station) to communicate with UE 102. Depending on the implementation, UE 102 also stores the second non-SDT DU configuration. In some such cases, CU-CP 172A includes the second non-SDT DU configuration in a UE context request message, and DU 174 includes the first non-SDT DU configuration in a UE context response message in response to receiving the second non-SDT DU configuration. In some implementations, the first non-SDT DU configuration expands or replaces the second non-SDT DU configuration. Examples and implementations of the first non-SDT DU configuration and the second non-SDT DU configuration are the same as the non-SDT DU configuration described above. In some implementations, DU 174 sends an additional DU to CU message (e.g., UE context modification required message) including the first non-SDT DU configuration to CU-CP 172A instead of including the first non-SDT DU configuration in the UE context response message.

[0183] After transitioning to the connected state, the UE 102 communicates 518 UL data and / or DL ​​data with the CU-CP 172A and / or CU-UP 172B via the DU 174. In some implementations, the UL data includes UL data that triggers the UE to send a non-SDT indication message. In a further implementation, the UL data also includes new UL data that can be used for transmission. In some implementations, the UL data includes a PDCP PDU, an RRC PDU, a NAS PDU, or an LTE Positioning Protocol (LPP) PDU. Depending on the implementation, the UL data is associated with an SRB (e.g., SRB1 or SRB2). In some implementations, the UE 102 applies one or more security functions (e.g., encryption and / or integrity protection) to the UL data, as described above. The CU-CP 172A applies one or more security functions (e.g., decryption and / or integrity protection check) to the UL data, as described above. Depending on the implementation, the UL data includes a PDCP PDU, an SDAP PDU, an IP packet, or an Ethernet packet. In some implementations, the UL data is associated with a DRB (e.g., an SDT DRB and / or a non-SDT DRB). In some implementations, the UE 102 applies one or more security functions (e.g., encryption and / or integrity protection) to the UL data, as described above. The CU-UP 172B applies one or more security functions (e.g., decryption and / or integrity protection check) to the UL data, as described above.

[0184] In some implementations, the DL data includes DL data received from CN 110 as described above. In further implementations, the DL data includes new DL data received by CU-CP 172A and / or CU-UP 172B from CN 110. Depending on the implementation, the DL data includes DL data packets, such as NAS PDUs, IP packets, or Ethernet packets. In the case of NAS PDUs, CU-CP 172A receives NAS PDUs from CN 110 (e.g., AMF 164) and generates RRC PDUs that each include a specific NAS PDU in the NAS PDU. In some implementations, CU-CP 172A applies one or more security functions (e.g., encryption and / or integrity protection) to the RRC PDU, as described above. UE 102 applies one or more security functions (e.g., decryption and / or integrity protection check) to the RRC PDU, as described above. In the case of NAS PDU, CU-CP 172A receives NAS PDU from CN110 (e.g., AMF 164) and generates RRC PDUs each including a specific NAS PDU in the NAS PDU. In some implementations, CU-CP 172A applies one or more security functions (e.g., encryption and / or integrity protection) to the RRC PDU, as described above. UE 102 applies one or more security functions (e.g., decryption and / or integrity protection check) to the RRC PDU, as described above. In the case of IP packets or Ethernet packets, CU-UP 172B receives DL data packets from CN 110 (e.g., UPF162) or an edge server and generates PDCP PDUs each including a specific DL data packet in the DL data packet. In some implementations, CU-UP 172B applies one or more security functions (e.g., encryption and / or integrity protection) to the DL data packet, as described above. UE 102 applies one or more security functions (e.g., decryption and / or integrity protection check) to the DL data packet, as described above.

[0185] In the case where the RRC resume message includes the first non-SDT DU configuration, the UE 102 communicates 518 with the DU 174 using the first non-SDT DU configuration. In some cases where the second non-SDT DU configuration is not completely replaced by the first non-SDT DU configuration (i.e., the UE 102 does not release the second non-SDT DU configuration in response to the RRC resume message), the UE 102 communicates 518 with the DU 174 using configuration parameters in the second non-SDT DU configuration that are not augmented by the first non-SDT DU configuration.

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

[0187] In some implementations, the UE 102 releases the SDT configuration (e.g., SDT CU configuration, SDT DU configuration, and / or CG-SDT configuration) in response to an RRC recovery message or transitioning to a connected state. In some implementations, the base station 104 (e.g., CU-CP 172A and / or DU 174) releases the SDT configuration in response to transitioning the UE 102 to a connected state, receiving 510 a CU to DU message, or sending 545, 546 an RRC recovery message, or thereafter. In other implementations, the base station 104 releases the SDT configuration in response to receiving an acknowledgment (e.g., RLC acknowledgment or HARQ acknowledgment) for a PDU including an RRC recovery message, or thereafter. In yet other implementations, the base station 104 (e.g., CU-CP 172A and / or DU 174) releases the SDT configuration in response to communicating 508 a UE context request message or transmitting 510 a UE context response message, or thereafter.

[0188] In other implementations, in response to receiving an RRC recovery message or transitioning to a connected state or thereafter, the UE 102 retains the SDT configuration (e.g., SDT CU configuration, SDT DU configuration, and / or CG-SDT configuration). In some implementations, when operating in a connected state, the UE 102 avoids using the SDT configuration to communicate with the base station 104 (e.g., 550RRC recovery complete message and / or 518 data). In other implementations, when operating in a connected state, the UE 102 uses the SDT configuration to communicate with the base station 104 (e.g., 550RRC recovery complete message and / or 518 data). In some implementations, in response to transitioning the UE 102 to a connected state or sending an RRC recovery message or thereafter, the base station 104 retains the SDT configuration. In some implementations, the base station 104 avoids using the SDT configuration to communicate with the UE 102 operating in a connected state (e.g., 550RRC recovery complete message and / or 518 data). In other implementations, the base station 104 uses the SDT configuration to communicate with the UE 102 operating in the connected state (e.g., 550 RRC recovery complete message and / or 518 data).

[0189] In some implementations, in response to or after transitioning UE 102 to a connected state or sending an RRC resume message, UE 102 discards the UE inactive AS context. In some implementations, UE 102 releases one or more configuration parameters in a suspension configuration (e.g., suspendConfig), except for RAN notification area information (e.g., ran-NotificationAreaInfo). Depending on the implementation, UE 102 receives the suspension configuration in an RRC release message from base station 104 before performing the 592 process, similar to event 334 or 434.

[0190] In some implementations, the non-SDT indication message is or includes an RRC message (e.g., a UEAssistanceInformation message or a new RRC message). In some such implementations, the UE 102 continues to perform small data communication with the base station 104 after sending the non-SDT indication message. In some implementations, the UE 102 sends a UL MAC PDU including a non-SDT indication message to the CU-CP 172A via DU174. In some implementations, in addition to the non-SDT indication message, the UE 102 also includes data in the UL MAC PDU. In other implementations, the UE avoids including data in the UL MAC PDU. In some implementations, the UE 102 sends a non-SDT indication message to the CU-CP 172A via DU 174 and SRB1. In such implementations, in response to determining to send a non-SDT indication message, the UE 102 avoids reestablishing the UE PDCP entity of SRB1. UE 102 uses the UE PDCP entity to generate an UL PDCP PDU including a non-SDT indication message, and sends 503, 505 the UL PDCP PDU to CU-CP 172A via DU 174. Then, UE 102 uses the UE PDCP entity to receive 546 a DL PDCP PDU including an RRC recovery message without reestablishing the UE PDCP entity. CU-CP 172A uses the CU-CP PDCP entity to receive 505 the UL PDCP PDU. In response to receiving the non-SDT indication message, CU-CP 172A avoids reestablishing the CU-CP PDCP entity of SRB1. CU-CP 172A uses the CU-CP PDCP entity to generate a DL PDCP PDU, and sends 545, 546 the DL PDCP PDU to UE 102 via DU174 and SRB1. The UE 102 generates a UL PDCP PDU including an RRC recovery complete message using the UE PDCP entity, and transmits 550, 552 the UL PDCP PDU to the CU-CP 172A via DU 174 and SRB1. The CU-CP 172A receives 550, 552 the UL PDCP PDU from the UE 102 via DU 174 using the CU-CP PDCP entity. In these implementations, the UE 102 and the CU-CP 172A communicate PDCP PDUs via SRB1 without reestablishing the UE PDCP entity and the CU-CP PDCP entity.

[0191] In other implementations, the non-SDT indication message is an RRC recovery request message (e.g., an RRCResumeRequest message or an RRCResumeConnectionRequest message). In some such implementations, the UE 102 stops 592 small data communication with the base station 104 to send the non-SDT indication message. In some implementations, the UE 102 sends the non-SDT indication message to the CU-CP 172A via the DU 174 and SRB0. In some implementations, the UE 102 reestablishes the UE PDCP entity in response to determining to send a non-SDT indication. After reestablishing the UE PDCP entity, the UE 102 receives 546 a DL PDCP PDU from the DU174 using the UE PDCP entity. Similarly, the CU-CP 172A reestablishes the CU-CP PDCP entity upon receiving the non-SDT indication message. After re-establishing the CU-CP PDCP entity, the CU-CP 172A generates DL PDCP PDUs using the CU-CP PDCP entity, and transmits 545, 546 the DL PDCP PDUs to the UE 102 via DU 174 and SRB1. After re-establishing the UE PDCP entity, the UE 102 generates UL PDCP PDUs including an RRC recovery complete message using the UE PDCP entity, and transmits 550, 552 the UL PDCP PDUs to the CU-CP 172A via DU 174 and SRB1. After re-establishing the CU-CP PDCP entity, the CU-CP 172A receives 550, 552 UL PDCP PDUs from the UE 102 via DU 174 using the CU-CP PDCP entity.

[0192] Prior to performing 592 the small data communication process, the UE 102 operating 502 in the inactive state starts or restarts the first UE CG-SDT timer (e.g., CG-SDT-TAT), such as for Figure 3 and Figure 4 In some implementations, in response to receiving a timing advance command from DU 174 during the small data communication process 592, UE 102 starts or restarts a first UE CG-SDT timer. In some implementations, in response to receiving an RRC recovery message or thereafter, UE 102 maintains (e.g., keeps or does not stop, start or restart) the first UE CG-SDT timer (e.g., CG-SDT-TAT) running. In other implementations, in response to receiving an RRC recovery message or thereafter, UE 102 stops the first UE CG-SDT timer.

[0193] Similarly, depending on the implementation, the DU 174 runs a first DUCG-SDT timer for the UE 102 operating 502 in the inactive state, such as for Figure 3 and Figure 4 As described. In some implementations, in response to sending a timing advance command to UE102, DU 174 starts or restarts the first DU CG-SDT timer. In some implementations, in response to receiving 508 to a UE context request message, sending 510 a UE context response message, or sending 512 a recovery message or thereafter, DU 174 maintains (e.g., keeps or does not stop, start or restart) the first DU CG-SDT timer running. In other implementations, in response to receiving 508 to a UE context request message, sending 510 a UE context response message, or sending 545 an RRC recovery message or thereafter, DU 174 stops the first DU CG-SDT timer. In some cases where the first DU CG-SDT timer expires, DU 174 releases the CG-SDT configuration. In some cases where the first DU CG-SDT timer expires, DU 174 instead retains the CG-SDT configuration and avoids receiving or attempting to receive UL transmissions (e.g., MAC PDUs) on CG resources. In some such cases, DU 174 releases the CG resources or determines that the CG resources are invalid.

[0194] In some implementations, the UE 102 in an inactive state runs a second UE CG-SDT timer during the 592 small data communication process, as described for process 492. In the case where the second UE CG-SDT timer is running, in some implementations, in response to receiving 546 to the RRC recovery message or transitioning 548 to the connected state or thereafter, the UE 102 stops the second UE CG-SDT timer. Alternatively, in response to receiving 546 to the RRC recovery message or transitioning 548 to the connected state or thereafter, the UE 102 maintains the second UE CG-SDT timer running. In some implementations, the UE 102 receives an RRC setup message (e.g., an RRCSetup message) instead of an RRC recovery message. In response to receiving an RRC establishment message or thereafter, the UE 102 stops the second UE CG-SDT timer and sends an RRC setup completion message to the CU-CP 172A via the DU 174.

[0195] Similarly, in some implementations, DU 174 runs a second DU CG-SDT timer during the 592 small data communication process. In some implementations, DU 174 starts or restarts the second DU CG-SDT timer when or after receiving a PUSCH transmission from UE 102 on the radio resources configured in the CG-SDT configuration. While the second DU CG-SDT timer is running, DU 174 uses C-RNTI to send PDCCH. In some implementations, in response to receiving 508 to a UE context request message, sending 510 a UE context response message, or sending 546 an RRC recovery message or thereafter, DU 174 stops the second DU CG-SDT timer while the second DU CG-SDT timer is running. In other implementations, in response to receiving 508 to a UE context request message, sending 510 a UE context response message, or sending 546 an RRC recovery message or thereafter, DU 174 maintains the second DU CG-SDT timer. The DU 174 sends DCI on the PDCCH using the C-RNTI to the UE 102 operating in the connected state regardless of the second DU CG-SDT timer (eg, running, expired, or stopped).

[0196] Events 502, 592, 503, 505, 507, 508, 510, 545, 546, 548, 550, 552, 554, 556, and 518 are Figure 5A are collectively referred to as state transition process 588.

[0197] Later, the base station 104 performs 590 a non-SDT configuration procedure with the UE 102 and performs 594 an SDT configuration procedure with the UE, similar to the procedures 390 and 394, respectively. The UE 102 transitions 536 to the inactive state in response to receiving the RRC release message in the procedure 594. In some implementations, after transitioning to the inactive state, the UE 102 in the inactive state performs 593 a small data communication procedure with the base station 104 and performs 595 an SDT completion procedure with the base station, similar to the procedures 492 and 494, respectively.

[0198] Next reference Figure 5B , scenario 500B is generally similar to scenario 500A, except that UE 102 initiates an RRC recovery procedure instead of a small data communication procedure 592. The differences between scenarios 500B and 500A are discussed below.

[0199] In response to initiating the RRC recovery process, the UE 102 in the inactive state sends 542 an RRC recovery request message to the DU 174, which in turn sends 544 an initial UL RRC messaging message including an RRC recovery request message (e.g., an RRCResumeRequest message or an RRCConnectionResumeRequest message) to the CU-CP 172A. In response to receiving the RRC recovery request message, the CU-CP 172A determines to cause the UE 102 to transition to the connected state. In response to or after determining to cause the UE 102 to transition to the connected state, the CU-CP 172A transitions the UE to the connected state as described for scenario 500A.

[0200] In some implementations, the UE 102 generates a UL MAC PDU including the RRC recovery request message and sends 542 the UL MAC PDU to the DU 174. In some implementations, the UE 102 sends 542 the UL MAC PDU to the DU 174 on the radio resources configured in the CG configuration for the SDT. In other implementations, the UE 102 performs a random access procedure to send the UL MAC PDU, similar to event 404.

[0201] In some implementations, the UE 102 initiates an RRC recovery procedure to send non-SDT data (i.e., data that is not eligible for SDT). More specifically, an upper protocol layer (e.g., a NAS layer) of the UE 102 requests an RRC layer (e.g., RRC 214) of the UE 102 to initiate an RRC recovery procedure. In other implementations, the UE 102 receives a paging message from the DU 174 and initiates an RRC recovery procedure in response to the paging message. In some implementations, the RRC layer (e.g., RRC 214) initiates an RRC recovery procedure in response to the paging message. In yet other implementations, the UE 102 detects expiration of a periodic RAN Notification Area Update (RNAU) timer, and initiates an RRC recovery procedure in response to expiration of the periodic RNAU timer. In some implementations, the RRC layer (e.g., RRC 214) starts or restarts an RNAU timer, maintains the RNAU timer running, and initiates an RRC recovery procedure in response to expiration of the RNAU timer.

[0202] Events 502, 508, 510, 518, 542, 544, 545, 546, 548, 550, 552, 554, and 556 are Figure 5B are collectively referred to as state transition process 589.

[0203] Next reference Fig. 6A, scenario 600A depicts an RRC resume request and a response with an RRC release message. In example scenario 600A, base station 106 includes CU 172 and DU 174. CU 172 includes CU-CP 172A and CU-UP 172B. UE 102 initially operates in an inactive state 602. In some implementations, UE 102 operates in a connected state with base station 104 before operating in the inactive state 602, and later transitions to the inactive state 602, as for Figure 3 In other implementations, UE 102 operates in an inactive state, performs a small data transmission with base station 104, stops the small data transmission with base station 104, and remains in an inactive state 602, as described for Figure 4 In some such implementations, UE 102 is configured by base station 104 with SDTSDT configuration parameters (e.g., SDT CU configuration and / or SDT DU configuration), such as for Figure 3 or Figure 4 As shown. "SDT configuration" is used to represent SDT configuration parameters to simplify the following description. In some implementations, the SDU configuration includes a CG-SDT configuration. In some such cases, the UE 102 discards the CG-SDT configuration because the base station 106 does not configure the CG-SDT configuration for the UE 102 (i.e., the CG-SDT configuration is invalid).

[0204] Later, the UE 102 in the inactive state initiates an RRC recovery procedure with the base station 106. In some implementations, the UE 102 initiates the RRC recovery procedure for RNA update because the base station 106 belongs to another RNA that is different from the RNA of the cell in which the UE 102 receives the RRC release message, which configures the UE 102 to transition to the inactive state 602. In other implementations, the UE 102 performs the RRC recovery procedure for periodic RNA updates. In response to the initiation, the UE 102 in the inactive state sends 642 an RRC recovery request message to the DU 174, which in turn sends 644 an initial UL RRC messaging message including an RRC recovery request message (e.g., an RRCResumeRequest message or an RRCConnectionResumeRequest message) to the CU-CP 172A. In some implementations, the RRC recovery request message includes the UE ID of the UE 102. For example, the UE ID may be an I-RNTI (e.g., a fullI-RNTI or shortI-RNTI value or field). In some implementations, the RRC resume request message includes an RRC MAC-I. In further implementations, the RRC MAC-I is a resumeMAC-I field, and the UE 102 obtains the resumeMAC-I (e.g., as defined in 3GPP specification 38.331). In other implementations, the UE 102 uses an integrity key (e.g., K RRCint The UE 102 may obtain an RRC MAC-I (e.g., a resumeMAC-I field) from the RRC resume request, along with the following parameters: RRC MAC-I field, 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). In some implementations, the UE 102 may generate an RRC MAC-I by setting bits of the COUNT, BEARER, and DIRECTION sets to binary ones.

[0205] After receiving the RRC recovery request message, CU-CP 172A sends 607 a retrieve UE context request message to base station 104 to retrieve the UE context of UE 102. In response, base station 104 sends 609 a retrieve UE context response message including UE context information of UE 102 to CU-CP 172A. In some implementations, CU-CP 172A includes the RRC MAC-I in the retrieve UE context request message. In some implementations, CU-CP 172A determines the first IP address of base station 104, the CU-CP of base station 104, or the CU of base station 104 based on the UE ID. CU-CP 172A generates a first IP packet, which includes a source address (i.e., the IP address of CU-CP 172A), a destination address (i.e., the first IP address), and a retrieve UE context request message. CU-CP 172A sends the first IP packet to base station 104. The base station 104 generates a second IP packet including a source address (i.e., the first IP address or another IP address of the base station 104), a destination address (i.e., the IP address of the CU-CP 172A), and a retrieve UE context response message. The base station sends the second IP packet to the CU-CP 172A.

[0206] In some implementations, the UE context information includes security capabilities, security information, maximum bit rate, a list of PDU session resources to be set, an RRC context, a UE radio capability ID, and / or an SDT configuration. In some implementations, the RRC context includes configuration parameters that the base station 104 configures for a UE 102 operating in a connected state to communicate with the base station 104. For example, the configuration parameters include a cell group configuration (e.g., CellGroupConfig IE), a radio bearer configuration (e.g., RadioBearerConfig IE), and / or a measurement configuration (e.g., MeasConfig IE). In some implementations, the base station 104 includes the SDT configuration in the RRC context. In other implementations, the base station 104 avoids including the SDT configuration in the RRC context or the retrieve UE context response message.

[0207] In some cases where the SDT configuration includes a CG-SDT configuration, the base station 104 excludes the CG-SDT configuration from the SDT configuration. Alternatively, the base station 104 still includes the CG-SDT configuration from the SDT configuration. In some implementations, when the CU-CP 172A receives the CG-SDT configuration, the CU-CP 172A discards the CG-SDT configuration. In some implementations, the CU-CP 172A discards the SDT configuration (for example, when the CU-CP 172A does not support incremental configuration). In other implementations, the base station 104 avoids including the SDT configuration in the retrieve UE context response message.

[0208] In some implementations, after receiving 609 the retrieve UE context response message, CU-CP 172A sends 612 a bearer context setup request message to CU-CP 172B to request CU-UP 172B to establish a bearer context for the SDT DRB configured in the SDT configuration for UE 102. In response, CU-UP 172B establishes (i.e., sets) a bearer context for the SDT DRB and sends 614 a bearer context setup response message to CU-CP 172A to confirm that the bearer context for the SDT DRB has been established. In some implementations, if there are non-SDT DRBs for UE 102, CU-CP 172A requests CU-UP 172B to establish a bearer context for the non-SDT DRB in the bearer context setup request message. In this case, CU-UP 172B establishes a bearer context for the non-SDT DRB in response to the bearer context setup request message 612. In some implementations, CU-UP 172B includes the transport layer information of CU-UP 172B in the bearer context setup response message. The transport layer information of CU-UP 172B configures and / or includes an IP address and / or uplink TEID associated with the SDT DRB and / or non-SDT DRB. In some implementations, each of the SDT DRB and the non-SDT DRB is associated with a specific IP address and / or a specific uplink TEID that can identify a GTP tunnel. The bearer context setup request message and the bearer context setup response message can be grouped into a bearer context setup procedure.

[0209] In a further implementation, after receiving 609 to retrieve the UE context response message or receiving 614 to the bearer context setup response message, the CU-CP 172A sends 608 a UE context setup request message to the DU 174 to request the DU 174 to establish the UE context of the UE 102. In response, the DU 174 establishes the UE context of the UE 102 and sends 610 a UE context setup response message to the CU-CP 172A. In some implementations, the CU-CP 172A includes the transport layer information of the CU-UP 172B in the UE context setup request message. In some implementations, the DU 174 includes the transport layer information of the DU 174 in the UE context setup response message. The UE context setup request message and the UE context setup response message may be grouped into a UE context setup procedure. The transport layer information of the DU 174 configures and / or includes an IP address and / or downlink TEID associated with the SDT DRB and / or non-SDT DRB. In some implementations, each of the SDT DRB and the non-SDT DRB is associated with a specific IP address and / or a specific downlink TEID that can identify a GTP tunnel.

[0210] After receiving 614 the bearer context setup response message or receiving 610 the UE context setup response message, the CU-CP 172A sends 624 a bearer context modification request message to the CU-UP 172B. In response, the CU-UP 172B sends 626 a bearer context modification response message to the CU-CP 172A. In some implementations, the CU-CP 172A includes the transport layer information of the DU 174 in the bearer context modification request message. The bearer context modification request message and the bearer context modification response message may be grouped into a bearer context modification procedure.

[0211] In some implementations, CU-CP 172A includes a pause indication (e.g., a bearer context state change IE with a "pause" value) in a bearer context setup request message for indicating that one or more bearer contexts are to be suspended. Alternatively, CU-CP 172A includes the pause indication in a bearer context modification request message instead of including the pause indication in the bearer context setup request message. In response to the pause indication, CU-UP 172B suspends all DRBs (i.e., SDT DRBs and / or non-SDT DRBs) of UE 102. In some implementations, when CU-UP 172B suspends a DRB, CU-UP 172B suspends the bearer context of the DRB and / or data communication of the DRB.

[0212] In some implementations, after receiving 609 the retrieve UE context response message, 610 the UE context setup response message, 614 the bearer context setup response message, or 626 the bearer context modification response message, CU-CP 172A determines to obtain the SDT DU configuration from DU 174. In response to the determination, CU-CP 172A sends 628 a CU to DU message to DU 174 to obtain the SDT DU configuration, similar to events 328, 428. In response, DU 174 sends 630 a DU to CU message including the SDT DU configuration to CU-CP 172A, similar to events 330, 430. After receiving 609 the retrieve UE context response message, 610 the UE context setup response message, 614 the bearer context setup response message, 626 the bearer context modification response message, or 630 the DU to CU message, the CU-CP 172A sends 632, 634 an RRC release message to the UE 102 via the DU 174, similar to events 332, 334, 432, and 434. The UE 102 determines that the RRC recovery procedure is successfully completed upon receiving 634 the RRC release message, and remains in an inactive state.

[0213] In some implementations, after receiving 634 the RRC release message, UE 102 performs 692 a small data communication procedure and performs 695 an SDT completion procedure with base station 106, similar to events 492 and 494, respectively. In some implementations, events 608, 610, 612, 614, 624, and / or 626 are omitted. In some such implementations, the events occur during the small data communication procedure 692.

[0214] In some scenarios or implementations, CU-UP 172B receives a DL data packet for UE 102 from CN 110 (e.g., UPF 162) or an edge server, and the DL data packet is associated with one of the SDT DRBs. Since CU-UP 172B suspends the SDT DRB, CU-UP 172B suspends sending DL data packets to DU 174 and sends a UP to CP message (e.g., DL data notification message) to CU-CP 172A to notify CU-CP 172A that the SDT DRB has data arrival. In some implementations, CU-UP 172B includes the PDU session ID and / or QoS flow ID associated with the SDT DRB in the UP to CP message. In a further implementation, in response to or after receiving the UP to CP message, the CU-CP 172A sends a CU to DU message (e.g., an F1AP paging message) to the DU 174 to cause or instruct the DU 174 to send a paging message (e.g., an RRC paging message) to the UE 102. In response to the CU to DU message, the DU 174 sends the paging message to the UE 102.

[0215] In some scenarios or implementations, CU-UP 172B receives a DL data packet for UE 102 from CN 110 (e.g., UPF 162) or an edge server, and the DL data packet is associated with one of the non-SDT DRBs. Since CU-UP 172B suspends the non-SDT DRB, CU-UP 172B suspends sending the DL data packet to DU 174 and sends a UP to CP message (e.g., DL data notification message) to CU-CP 172A to notify CU-CP 172A that the non-SDT DRB has data arrival. In some implementations, CU-UP 172B includes the PDU session ID and / or QoS flow ID associated with the non-SDT DRB in the UP to CP message. In a further implementation, in response to or after receiving the UP to CP message, the CU-CP 172A sends a CU to DU message (e.g., an F1AP paging message) to the DU 174 to cause or instruct the DU 174 to send a paging message (e.g., an RRC paging message) to the UE 102. In response to the CU to DU message, the DU 174 sends the paging message to the UE 102.

[0216] Next reference Figure 6B, scenario 600B depicts a small data transfer, similar to scenarios 400 and 600A. Except for events 607 and 609, events 602, 604, 606, 608, 610, 612, 614, 615, 616, 618, 695, 636 are similar to events 402, 404, 406, 408, 410, 412, 414, 415, 416, 418, 494, 436, respectively. Figure 4 and Fig. 6A Examples and implementations can be applied to Figure 6B The following describes Figure 4 and Fig. 6A and Figure 6B The difference between.

[0217] In scenario 600B, UE 102 initially operates in an inactive state 602 and is configured with an SDT configuration. In some implementations, UE 102 receives a request for Figure 3 , Figure 4 , Figure 5A and / or Figure 5B The SDT configuration described. The UE 102 operating 602 in an inactive state initiates an SDT. In response to the initiation, the UE 102 sends 604 a UL MAC PDU including a UL RRC message to the DU 174. Subsequently, the DU 174 sends 606 a DU to CU message including the UL RRC message to the CU-CP 172A. In response to or after receiving 606 the UL RRC message, the CU-CP 172A sends 607 a retrieve UE context request message to the base station 104. In response, the base station 104 sends 609 a retrieve UE context response message to the CU-CP 172A.

[0218] In the event that UE 102 includes UL data in initial UL MAC PDU 604, DU 174 may send 615 a DU-to-CU message including the UL data to CU-CP 172A or send 616 the UL data, similar to event 415 or 416, respectively.

[0219] In some implementations, after sending 604 the initial UL MAC PDU, the UE 102 in the inactive state sends 618 subsequent UL data to the CU-CP 172A and / or CU-U 172B via DU 174, similar to event 418. In further implementations, after sending 604 the initial UL MAC PDU, the UE 102 in the inactive state receives 618 DL data from the CU-CP 172A and / or CU-U 172B via DU 174, similar to event 418. In some implementations, after events 604 and / or 618, the UE 102 and the base station 106 perform 694 an SDT completion procedure, similar to event 494. In response to or after performing 694 the SDT completion procedure, the UE 102 remains 636 in the inactive state.

[0220] In some implementations, the CU-CP 172A avoids including a suspend indication (e.g., a bearer context state change IE with a value of "suspend") in the bearer context setup request message 612. In some implementations, the CU-CP 172A includes a resume indication (e.g., a bearer context state change IE with a value of "ResumeforSDT") in the bearer context setup request message 612 that indicates that the CU-UP 172B suspends the non-SDT DRB. In response to the resume indication, the CU-UP 172B suspends the non-SDT DRB. In other implementations, the CU-CP 172A avoids including a resume indication in the bearer context setup request message 612. In some such implementations, the CU-CP 172A includes a resume indication (e.g., a bearer context state change IE with a value of "ResumeforSDT") in the bearer context modification request message 624 that indicates that the CU-UP 172B suspends the non-SDT DRB. In response to the resume indication, the CU-UP 172B suspends the non-SDT DRB. In some implementations, if the UE 102 is not configured with non-SDT DRBs, the CU-CP 172A excludes the resume indication in the bearer context setup request message 612 and / or the bearer context modification request message 624 .

[0221] In some implementations, when the CU-UP 172B suspends a non-SDT DRB, the CU-UP 172B suspends the bearer context of the non-SDT DRB and / or data communication of the non-SDT DRB.

[0222] In a further implementation, after establishing the bearer context for the SDT DRBs, the CU-UP 172B receives 616, 618 UL data from the DU 174 and processes the UL data because the SDT DRB to which the UL data is associated is not suspended by the CU-UP 172B. In some scenarios or implementations, the CU-UP 172B receives DL data packets for the UE 102 from the CN 110 (e.g., UPF 162) or edge server. If the DL data packet is associated with one of the SDT DRBs, the CU-UP 172B sends 618 the DL data packet to the DU 174, which in turn sends 618 the DL data packet to the UE 102. If the DL data packet is associated with one of the non-SDT DRBs, the CU-UP 172B suspends sending the DL data packet to the DU 174. In response to receiving the DL data packet associated with the non-SDT DRB, the CU-UP 172B sends a UP to CP message (e.g., a DL data notification message) to the CU-CP 172A to notify the CU-CP 172A that the DL data packet of the non-SDT DRB has arrived. In some implementations, the CU-UP 172B may include the PDU session ID and / or QoS flow ID associated with the non-SDT DRB in the UP to CP message.

[0223] Next reference Figure 6C , scenario 600C depicts a small data transfer, similar to scenarios 500A / 500B and 600A. Except for events 607 and 609, events 602, 604, 606, 608, 610, 645, 646, 648, 650, 652, 612, 614, 619, 690, 694, 636, 692, and 695 are similar to events 502, 542, 554, 506, 508, 510, 545, 546, 548, 550, 552, 512, 514, 518, 590, 594, 536, 592, and 595, respectively. Figure 5A , Figure 5B and Fig. 6A Examples and implementations can be applied to Figure 6C The following describes Figure 5A , Figure 5B as well as Fig. 6A and Figure 6C The difference between.

[0224] In scenario 600C, CU-CP 172A refrains from including a suspension indication (e.g., a bearer context state change IE with a “suspended” value) in the bearer context setup request message 612 and the bearer context modification request message 624. Thus, in response to or after receiving the bearer context setup request message 612 and the bearer context modification request message 624, CU-UP 172B does not suspend the DRB for UE 102.

[0225] In some implementations, after establishing the bearer context of the DRB of UE 102 (e.g., the SDT DRB and / or non-SDT DRB of UE 102), CU-UP 172B receives 616, 619 UL data packets from DU 174 and processes the UL data packets because the DRB associated with the UL data is not suspended by CU-UP 172B. The UL data packet may be a PDCP PDU, an SDAPPDU, an IP packet, or an Ethernet packet. The UL data packet is associated with a DRB (e.g., an SDT DRB and / or a non-SDT DRB). In some implementations, UE 102 applies one or more security functions (e.g., encryption and / or integrity protection) to the UL data packet, as described above. CU-UP 172B applies one or more security functions (e.g., decryption and / or integrity protection check) to the UL data packet, as described above. In some scenarios or implementations, CU-UP 172B receives DL data packets for UE 102 from a CN (e.g., UPF 162) or an edge server. The DL data packets may be IP packets or Ethernet packets and are associated with DRBs. In some implementations, the CU-UP 172B applies one or more security functions (e.g., encryption and / or integrity protection) to the DL data packets, as described above. The UE 102 applies one or more security functions (e.g., decryption and / or integrity protection checking) to the DL data packets, as described above.

[0226] Reference now Fig. 7A , scenario 700A depicts a handover scenario. Initially, UE 102 operates in an inactive state. UE 102 and base station 104 perform 788 a state transition process with each other, similar to process 588 or 589. As a result of the state transition process, UE 102 transitions to a connected state. Later, base station 104 determines to hand over UE 102 to base station 106. In some implementations, base station 104 makes a handover determination based on one or more measurement results received from UE 102 or obtained from uplink transmissions sent by UE 102. In other implementations, base station 104 makes a handover determination because base station 104 is congested.

[0227] In response to the handover determination, the base station 104 sends 702 a handover request message to the base station 106 to prepare for the handover for the UE 102. In some implementations, the base station 104 includes the first SDT configuration and the first non-SDT configuration for the UE 102 in the handover request message. In some implementations, the base station 104 includes the SDT configuration and the non-SDT configuration in an inter-node message (i.e., a first inter-node message, e.g., a HandoverPreparationInformation message), and includes the inter-node message in the handover request message. In some implementations, the UE 102 receives an RRC release message including the first SDT configuration from the base station 104, as described above. In some implementations, the UE 102 receives at least one RRC message (e.g., an RRC recovery message and / or an RRC reconfiguration message) including the first non-SDT configuration from the base station 104, as described above. In some implementations, the first non-SDT configuration includes a first non-SDT DU configuration. More examples and implementations of the first SDT configuration and the first non-SDT configuration are as described above.

[0228] In the case where the base station 106 is a distributed base station, the base station 106 includes a CU and a DU (e.g., Fig. 7A 172 and DU 174). In some implementations, the CU performs 709 a UE context setup process with the DU to establish a UE context for the UE 102. More specifically, the CU sends a UE context setup request message to the DU to perform 709 a UE context setup process, similar to event 608. In response, the DU sends a UE context setup response message to the CU, similar to event 610. In some implementations, the CU includes an inter-node message in the UE context setup request message. In some implementations, the DU includes a second non-SDT DU configuration in the UE context setup response message. In some implementations, the DU generates a second non-SDT DU configuration that expands (e.g., replaces or modifies) the first non-SDT DU configuration. In some implementations, the DU avoids including the SDT configuration in the UE context setup response message. In some implementations, the DU ignores or discards the first SDT configuration when receiving a UE context setup request message or an inter-node message. In other implementations, the DU retains the first SDT configuration and avoids including the SDT configuration in the UE context setup response message.

[0229] In some implementations, the first non-SDT DU configuration and the second non-SDT DU configuration are the first CellGroupConfig IE and the second CellGroupConfig IE, respectively. In some implementations, the DU includes configuration parameters for the UE 102 to be handed over to the base station 106 in response to the first inter-node message in the second non-SDT DU configuration. In some implementations, the DU includes the ReconfigurationWithSync IE in the second CellGroupConfig IE. In some implementations, the base station 104 does not include the ReconfigurationWithSync IE in the first non-SDT DU configuration.

[0230] In some implementations, the CU avoids including the first SDT configuration in the UE context setup request message to prevent the DU from receiving the first SDT configuration. In some scenarios or implementations, the DU does not understand the first SDT configuration, causing the DU to ignore the UE context setup request message or the first inter-node message or reject the UE context setup request message, which can cause problems. To prevent this problem, in some implementations, the CU removes the first SDT configuration from the first inter-node message, and then includes the first inter-node message in the UE context setup request message. In other implementations, the CU generates a second inter-node message (e.g., a HandoverPreparationInformation message) that includes the first non-SDT configuration and does not include the first SDT configuration. In such implementations, the CU includes the second inter-node message instead of the first inter-node message in the UE context setup request message.

[0231] In response to the handover request message, the base station 106 sends 704 to the base station 104 a handover request confirmation message including an RRC reconfiguration message for handing the UE 102 to the base station 106. In an implementation in which the base station 106 is a distributed base station, the CU of the base station 106 includes the second non-SDT DU configuration in the RRC reconfiguration message. In some implementations, the CU includes a first inter-node message including a first non-SDT configuration and a first SDT configuration in the UE context setup request message. The DU includes the second non-SDT DU configuration and the second SDT DU configuration in the UE context setup response message. In some implementations, the DU may generate a first non-SDT DU configuration that extends the second non-SDT DU configuration. In such implementations, the CU avoids including the second SDT DU configuration in the RRC reconfiguration message. In some implementations, the CU includes the second SDT DU configuration in the RRC release message in the SDT configuration process 794. In other implementations, the CU ignores or discards the second SDT DU configuration.

[0232] The base station 104 then sends 706 an RRC reconfiguration message to the UE 102. In response, the UE 102 performs a handover to the base station 104 and sends 708 an RRC reconfiguration complete message to the base station 106. After successfully connecting to the UE 102, in some implementations, the base station 106 performs 790 a non-SDT configuration procedure with the UE 102, similar to the procedures 390, 490, 590, and 690. After successfully connecting to the UE 102 or performing 790 a non-SDT configuration procedure, the base station 106 performs 794 an SDT configuration procedure with the UE 102, similar to the procedures 394, 494, 594, and 694. In response to the SDT configuration procedure, the UE 102 transitions 736 to an inactive state, similar to events 336, 436, 536, and 636. After transitioning 736 to the inactive state, UE 102 may perform 792 a small data communication procedure with base station 106, similar to procedures 492, 592, and 692. In some implementations, after performing 792 the small data communication procedure, base station 106 performs 795 an SDT completion procedure with UE 102, similar to procedures 394, 494, 594, and 694.

[0233] In some implementations, if the base station 106 (e.g., the CU 172, CU-CP 172A, CU-UP 172B, or DU 174 of the base station 106) does not support SDT, the base station 106 includes a complete configuration indication in the RRC reconfiguration message so as to configure the UE 102 to release the SDT configuration. Upon receiving the RRC reconfiguration message, the UE 102 releases the SDT configuration in response to the complete configuration indication. Otherwise, if the base station 106 supports SDT, the base station 106 avoids including the complete configuration indication in the RRC reconfiguration message. When the UE 102 receives the RRC reconfiguration message excluding the complete configuration indication, the UE 102 retains the SDT configuration in response to the RRC reconfiguration message.

[0234] Next reference Figure 7B, scenario 700B is substantially similar to scenario 700A, except that base station 104 prepares for handover of UE 102 with base station 106 via CN 110, rather than directly with base station 106 via a BS-to-BS interface. In response to the handover determination, base station 104 sends 701 a handover required message including an SDT configuration and a non-SDT configuration to CN 110. In response to or subsequent to receiving 701 the handover required message, CN 110 sends 703 a handover request message including an SDT configuration and a non-SDT configuration to base station 106. In some implementations, base station 104 includes the SDT configuration and the non-SDT configuration in an inter-node message (e.g., a HandoverPreparationInformation message), and includes the inter-node message in the handover required message. In such implementations, CN 110 retrieves the inter-node message from the handover required message, and includes the inter-node message in the handover request message.

[0235] In response to or after receiving 703 the handover request message, the base station 106 sends 705 to the CN 110 a handover request confirm message including an RRC reconfiguration message for handing the UE 102 to the base station 106. In response to or after receiving 703 the handover request confirm message, the CN 110 sends 707 to the base station 104 a handover command message including an RRC reconfiguration message.

[0236] Reference now Figure 8, scenario 800 depicts an RRC connection reestablishment scenario. Initially, UE 102 operates in an inactive state. UE 102 and base station 104 perform 888 a state transition process with each other, similar to process 588 or 589. As a result of the state transition process, UE 102 transitions to a connected state. When UE 102 operates in a connected state, UE 102 detects a failure and initiates an RRC connection reestablishment process in response to detecting the failure. In response to the initiation, UE 102 sends 842 an RRC reestablishment request message to DU 174, which in turn sends 844 an initial UL RRC messaging message including an RRC reestablishment request message (e.g., an RRCReestablishmentRequest message or an RRCConnectionReestabishmentRequest message) to CU-CP 172A. In some implementations, the RRC reestablishment request message includes a UE ID (e.g., C-RNTI) and a physical cell ID of UE 102. In some implementations, the RRC recovery request message includes an RRC MAC-I. In some implementations, the RRCMAC-I is a shortMAC-I field. Depending on the implementation, the UE 102 obtains the shortMAC-I (e.g., as defined in 3GPP specification 38.331). In other implementations, the UE 102 uses an integrity key (e.g., K RRCint The UE 102 may further include a key, an integrity protection algorithm, and other 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) to obtain an RRC MAC-I (e.g., a shortMAC-I field) from the RRC reestablishment request. In some implementations, the UE 102 sets the bits of COUNT, BEARER, and DIRECTION to binary ones to generate the RRC MAC-I.

[0237] After receiving the RRC reestablishment request message, CU-CP 172A sends 807 a retrieve UE context request message to base station 104 to retrieve the UE context of UE 102. In response, base station 104 sends 809 a retrieve UE context response message including UE context information of UE 102 to CU-CP 172A. In some implementations, CU-CP 172A includes RRC MAC-I in the retrieve UE context request message. In further implementations, CU-CP 172A determines a first IP address of base station 104, a CU-CP of base station 104, or a CU of base station 104 based on UE ID and / or physical cell ID. CU-CP 172A generates a first IP packet, which includes a source address (i.e., an IP address of CU-CP 172A), a destination address (i.e., a first IP address), and a retrieve UE context request message. CU-CP 172A sends the first IP packet to base station 104. The base station 104 generates a second IP packet including a source address (i.e., the first IP address or another IP address of the base station 104), a destination address (i.e., the IP address of the CU-CP 172A), and a retrieve UE context response message. The base station sends the second IP packet to the CU-CP 172A.

[0238] Depending on the implementation, events 808, 810, 812, 814, 824, and 826 occur similarly to events 608, 610, 612, 614, 624, and 626, respectively. FIG. 6A to FIG. 6C The implementation discussed can be applied accordingly to Figure 8 Related events in .

[0239] After receiving 809 the retrieve UE context response message, the CU-CP 172A sends 845 a CU to DU message including an RRC reestablishment message (e.g., an RRCReestablishment message or an RRCConnectionReestablishment message) to the DU 174. Subsequently, the DU 174 sends 846 the RRC reestablishment message to the UE 102. In response to the RRC reestablishment message, the UE 102 sends 850 an RRC reestablishment complete message (e.g., an RRCReestablishmentComplete message or an RRCConnectionReestablishmentComplete message) to the DU 174. Then, the DU 174 sends 852 a DU to CU message including the RRC reestablishment complete message to the CU-CP 172A. In some implementations, the CU-CP 172A sends 845 the CU to DU message before, during, or after a bearer context setup procedure, a UE context setup procedure, or a bearer context modification procedure.

[0240] In some implementations, after sending 845 the RRC reestablishment message or receiving 852 the RRC reestablishment complete message, the CU-CP 172A performs 890 a reconfiguration process with the UE 102 and the DU 174 to restore the SRB2 and / or DRB of the UE 102 , similar to process 390 .

[0241] In some implementations, CU-CP 172A avoids including a pause indication (e.g., a bearer context state change IE with a “pause” value) in the bearer context setup request message 812. In other implementations, CU-CP 172A includes a pause indication (e.g., a bearer context state change IE with a “pause” value) in the bearer context setup request message 812 or the bearer context modification request message 824. In some such implementations, CU-CP 172A performs a bearer context modification procedure with CU-UP 172B to recover the bearer context of the DRB, similar to events 824 and 846.

[0242] In some implementations, after performing 890 the reconfiguration process, the CU-CP 172A performs 891 a non-SDT configuration process with the UE 102 via the DU 174, similar to process 390. In further implementations, after performing 890 the reconfiguration process or 891 the non-SDT configuration process, the CU-CP 172A performs 894 an SDT configuration process with the UE via the DU 174, similar to process 394. In response to or after performing 894 the SDT configuration process, the UE 102 transitions 836 from the connected state to the inactive state. In still further implementations, after transitioning to the inactive state, the UE 102 performs 892 a small data communication process with the base station 106 and 895 an SDT completion process with the base station, similar to processes 492 and 494, respectively.

[0243] Next reference Fig. 9 , scenario 900 depicts an RRC connection reestablishment process similar to scenario 800, except for events 937 and 939. Base station 104 includes DU 174A, DU 174B, CU-CP 172A, and CU-UP 172B. Initially, UE 102 operates in an inactive state. UE 102, DU 174A, and CU 172 perform 988 state transition processes with each other, similar to process 588 or 589. In some implementations, after receiving 944 the RRC reestablishment request message, CU-CP 172A sends a UE context release command message to DU 174A to release the UE context of UE 102. In response, DU 174 sends 939 a UE context release complete message to CU-CP 172A. The UE context release command message and the UE context release complete message may be grouped into a UE context release process. In some implementations, the CU-CP 172A performs a UE context release procedure with the DU 174A before, during, or after a bearer context setup procedure, a UE context setup procedure, a bearer context modification procedure, sending 945 an RRC reestablishment message, receiving 952 an RRC reestablishment complete message, or performing 990 a reconfiguration procedure.

[0244] Next, refer to FIG. 10A to FIG. 18 Several example methods are discussed that may be implemented in one or more base stations, DUs, CUs, or otherwise in a RAN to support small data transfers with a UE in an inactive state.

[0245] Fig. 10AA method 1000A is illustrated for configuring a UE (e.g., UE 102) to apply an SRS configuration, which may be implemented by a first RAN node (e.g., base station 104 / 106, CU 172, or DU 174). In particular, the method 1000A is a method for sending an SRS configuration to a UE and a second RAN node (e.g., base station 104 / 106, CU 172, or DU 174) or a CN (e.g., CN 110).

[0246] Method 1000A begins at block 1002, where a first RAN node communicates with a UE. At block 1004, the first RAN node sends an RRC release message (e.g., a first RRC release message) including a first SRS configuration to the UE (see, e.g., events 332, 334, 394, 432, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). At block 1006, the first RAN node performs an SDT with the UE operating in an inactive state. At block 1008, the first RAN node receives an SRS transmission from the UE during the SDT according to the first SRS configuration (e.g., events 418, 492, 493, 592, 593, 618, 692, 792, 892, 992). At block 1010 , the first RAN node sends a first interface message including a first SRS configuration to a second RAN node or CN (eg, events 702 , 701 , 609 , 809 ). Blocks 1004 , 1006 , 1008 , and 1010 are grouped as block 1050 .

[0247] In some implementations, the first RAN node sends a second RRC release message to stop or end the SDT (e.g., events 432, 434, 494, 495, 595, 695, 795, 8965, 995), similar to the first RRC release message. In response to sending the first RRC release message or the second RRC release message or thereafter, the first RAN node avoids receiving SRS from the UE according to the first SRS configuration or performing measurements (e.g., positioning measurements) on the SRS, which saves power for the first RAN node. Similarly, in response to receiving the first RRC release message or the second RRC release message or thereafter, the UE avoids sending SRS to the first RAN node according to the first SRS configuration, which saves power for the UE.

[0248] In some implementations, in response to the first interface message, the first RAN node receives a second interface message from the second RAN (e.g., event 607), and sends the first interface message to the second RAN (e.g., event 609). In some such implementations, the first interface message and the second interface message may be a retrieve UE context response message and a retrieve UE context request message, respectively. In other implementations, the first interface message is a handover request message (e.g., event 702), and the first RAN node receives a handover request confirmation message from the second RAN node in response to the handover request message (e.g., event 704). In yet other implementations, the first interface message is a handover request message (e.g., event 701), and the first RAN node receives a handover command message from the CN in response to the handover request message (e.g., event 707).

[0249] Fig. 10B 1000B is a flow chart of an example method 1000B similar to method 1000A, except that method 1000B includes block 1011 instead of block 1010. Thus, the RAN node sends the SRS configuration to the UE but not to the second RAN node or the CN. In particular, at block 1011, the first RAN node sends an interface message excluding the first SRS configuration to the second RAN node or the CN. Blocks 1004, 1006, 1008, and 1011 are grouped into block 1051.

[0250] Fig. 10C 1000A and 1000B, except that the method 1000C includes a block 1009. Thus, the first RAN node determines whether to send the SRS configuration to the second RAN node and / or the CN based on whether the second RAN node supports SDT or SRS for the inactive state. In particular, at block 1009, the first RAN node determines whether the second RAN node supports SDT or SRS in the inactive state. If the second RAN node supports SDT or SRS in the inactive state, the flow proceeds to block 1010. Otherwise, if the second RAN node does not support SDT or SRS in the inactive state, the flow proceeds to block 1011.

[0251] Fig. 10D1000A and 100B, except that method 1000D includes blocks 1012, 1014, and 1016 instead of block 1010. Thus, the RAN node causes the UE to transition to a connected state and optionally sends another SRS configuration to the UE. In particular, at block 1012, the first RAN node causes the UE to transition to a connected state (e.g., events 545, 546, 588, 589, 645, 646, 788, 888, 988). At block 1014, in response to causing the UE to transition to a connected state, the first RAN node retains the first SRS configuration. At block 1016, the first RAN node sends a third SRS configuration to the UE while or after transitioning the UE to the connected state (e.g., events 545, 546, 588, 589, 645, 646, 788, 888, 988, 310, 312, 390, 590, 690, 790, 890, 891, 990, 991). In some implementations, the third SRS configuration (e.g., SRS-Config IE) configures one or more SRS resources for the connected state.

[0252] Alternatively, in response to causing the UE to transition to the connected state, the first RAN node releases the first SRS configuration. In some implementations, the third SRS configuration is different from the first SRS configuration. In other implementations, the third SRS configuration is the same as the first SRS configuration.

[0253] In some implementations, the first SRS configuration and the third SRS configuration configure the same SRS resources. In other implementations, the third SRS configuration includes the first SRS configuration and configuration parameters for configuring additional SRS resources. In still other implementations, the third SRS configuration includes a portion of the first SRS configuration. In still other implementations, the third SRS configuration includes a portion of the first SRS configuration and configuration parameters for configuring additional SRS resources. In the case where an inactive UE sends an SRS according to the first SRS configuration (e.g., to perform location services as described above), the UE sends an SRS or continues to send an SRS according to the third SRS configuration.

[0254] In some implementations, the first SRS configuration and the third SRS configuration configure different SRS resources. For example, the first RAN node may configure the first SRS configuration for positioning and the third SRS configuration for purposes other than positioning (e.g., when the UE operates in a connected state, MIMO, beam management, or scheduling uplink transmission).

[0255] In some implementations, the first RAN node includes the third SRS configuration in the interface message of block 1010. After receiving the third SRS configuration, the second RAN node determines to configure the UE 102 to reuse the third SRS configuration, or determines to augment the third SRS configuration by sending an RRC reconfiguration message to the UE (e.g., events 310, 312, 390, 590, 690, 706, 790, 890, 891, 990, 991).

[0256] In some scenarios or implementations, the first RAN node performs an RRC reestablishment procedure with the UE operating in a connected state. In some such cases, the first RAN releases the first SRS configuration and / or retains the third SRS configuration in response to the RRC reestablishment procedure. Alternatively, the first RAN node retains the first SRS configuration and / or the third SRS configuration in response to the RRC reestablishment procedure.

[0257] In some implementations, the first RAN node stops receiving SRS transmissions from the UE operating in the connected state according to the first SRS configuration. In the event that the first RAN node sends a third SRS configuration to the UE, the first RAN node begins receiving SRS transmissions from the UE operating in the connected state according to the third SRS configuration.

[0258] Fig.10E 1000E is a flow chart of an example method 1000E similar to methods 1000A and 1000D, except that method 1000E additionally includes blocks 1015 and 1017. Thus, the RAN node determines whether to send an additional SRS configuration to the UE. In particular, at block 1015, the first RAN node determines whether the UE is performing location services. If the UE is performing location services, the flow proceeds to block 1016. Otherwise, if the UE is not performing location services, the flow proceeds to block 1017. In some implementations, at block 1017, the first RAN node refrains from sending the SRS configuration to the UE.

[0259] Fig.10Fis a flow chart of an example method 1000F similar to methods 1000A and 1000D, except that method 1000F includes block 1013 instead of blocks 1010, 1011, 1014, and 1016. Therefore, the RAN node sends a reconfiguration message to the UE to release the SRS configuration. In particular, at block 1013, the first RAN node sends an RRC reconfiguration message to the UE operating in a connected state to release the first SRS configuration (e.g., events 310, 312, 390, 590, 690, 706, 790, 890, 891, 990, 991). In some implementations, the first RAN node includes a complete configuration indication in the RRC reconfiguration message to release the first SRS configuration.

[0260] Fig.11A A method 1100A is illustrated for configuring a UE (e.g., UE 102) to apply an SRS configuration that has been configured by a second RAN node, which can be implemented by a first RAN node (e.g., base station 104 / 106, CU 172, or DU 174). In particular, the method 1100A is a method for sending a release message to the UE to configure the UE to continue to apply the SRS configuration.

[0261] The method 1100A starts at block 1102, where a first RAN node receives a first SRS configuration for a UE from a second RAN node (e.g., base station 104 / 106, CU 172, or DU 174) or a CN (e.g., CN 110) (see, e.g., events 331, 394, 431, 494, 495, 594, 595, 609, 694, 695, 702, 703, 794, 795, 809). At block 1104, the first RAN node sends an RRC release message (e.g., a first RRC release message) to the UE to configure the UE to continue to apply the first SRS configuration (see, e.g., events 332, 334, 394, 432, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). At block 1106, the first RAN node performs an SDT with the UE operating in an inactive state (e.g., events 492, 493, 494, 495, 592, 593, 594, 595, 692, 695, 792, 795, 892, 895, 992, 995). At block 1108, the first RAN node receives an SRS transmission from the UE during the SDT according to the first SRS configuration. Blocks 1104, 1106, and 1108 are grouped as block 1150.

[0262] In some implementations, the first RAN node avoids including the SRS configuration in the RRC message at block 1104 to configure the UE to continue to apply the first SRS configuration. In other implementations, the first RAN node includes the first SRS configuration in the RRC release message at block 1104 to configure the UE to continue to apply the first SRS configuration.

[0263] In some implementations, the second RAN node is a base station or a CU. In further implementations, the first RAN node receives a first non-SDT configuration for the UE from the second RAN node. In some implementations, the first RAN node receives a first SDT configuration from the second RAN node. In some implementations, the first SDT configuration includes an SDT CU configuration and / or an SDT DU configuration. In other implementations, the first SDT configuration is an SDT CU configuration and / or an SDT DU configuration. In some implementations, the first RAN node receives an interface message including a first SRS configuration, a first non-SDT configuration, and / or a first SDT configuration from the second RAN node at box 1102. In some implementations, the interface message is an XnAP message, a 6GAP message, a handover request message, or a retrieve UE context response message. In other implementations, the message is an inter-node message (e.g., HandoverPreparationInformation).

[0264] In some implementations, the first RAN node sends an RRC reconfiguration message to the UE to configure the UE to continue to apply the first non-SDT configuration. In some implementations, the first RAN node avoids including the non-SDT configuration in the RRC reconfiguration message so as to configure the UE to continue to apply the first non-SDT configuration. In other implementations, the first RAN node includes the first non-SDT configuration in the RRC reconfiguration message to configure the UE to continue to apply the first non-SDT configuration. In other implementations, the first RAN node sends an RRC reconfiguration message including a second non-SDT configuration to the UE to expand (e.g., replace or modify) the first non-SDT configuration. In the case where the first RAN node is a CU, the first RAN node sends an RRC release message and an RRC reconfiguration message to the UE via the DU.

[0265] In some implementations, method 1100A is similar to method 1000A, and suitable implementations of method 1000A are applicable to method 1100A.

[0266] Fig. 11BAn example method 1100B is illustrated that is similar to method 1100A, except that method 1100B includes blocks 1105 and 1109 instead of blocks 1004 and 1108. Thus, the RAN node sends a release message including a second SRS configuration to augment the first SRS configuration. In particular, at block 1105, the first RAN node sends an RRC release message to the UE including the second SRS configuration to augment (e.g., replace or modify) the first SRS configuration (see, e.g., events 332, 334, 394, 432, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). At block 1109, the first RAN node receives an SRS transmission from the UE during the SDT according to the second SRS configuration. Blocks 1105, 1106, and 1109 are grouped into block 1151.

[0267] Fig. 11C An example method 1100C is illustrated that is similar to method 1100A, except that method 1100C includes blocks 1103 and 1107 instead of blocks 1104 and 1106. Therefore, the RAN node sends a message to the UE to release the SRS configuration. In particular, at block 1103, the first RAN node releases the first SRS configuration. At block 1107, the first RAN node sends a first message to the UE to release the first SRS configuration (see, e.g., events 312, 314, 390, 332, 334, 394, 432, 434, 494, 495, 545, 546, 588, 589, 590, 594, 595, 690, 694, 695, 790, 794, 795, 890, 891, 894, 895, 990, 991, 994, 995). In some implementations, the first message is an RRC release message, an RRC resume message, an RRC reconfiguration message, or an RRC setup message.

[0268] Fig.11D An example method 1100D is illustrated that is similar to methods 1100A, 1100B, and 1100C, except that method 1100D further includes block 1110. Thus, the RAN node determines whether to configure the UE to continue to apply, expand, or release the SRS configuration based on whether the RAN node adapts to the SRS configuration. In particular, at block 1110, the first RAN node determines whether the first RAN node adapts to the first SRS configuration. If the first RAN node adapts to the first SRS configuration, the flow proceeds to block 1150. Otherwise, if the first RAN node does not adapt to the first SRS configuration, the flow proceeds to block 1151 or 1107.

[0269] Fig. 12AA method 1200A is illustrated for configuring an SRS configuration for a UE (e.g., UE 102), which can be implemented by a CU (e.g., CU 172 or CU-CP 172A) via a DU (e.g., DU 174). In particular, the method 1200A is a method for sending an SRS resource configuration and additional parameters to a DU.

[0270] Method 1200A begins at block 1202, where the CU sends a first CU-to-DU message to the DU for requesting SRS resources for the UE (e.g., events 329, 394, 429, 494, 495, 594, 595, 695, 795, 895, 995). At block 1204, the CU receives a first DU-to-CU message including an SRS resource configuration from the DU (e.g., events 331, 394, 431, 494, 495, 594, 595, 695, 795, 895, 995). At box 1206, the CU sends a first RRC release message to the UE via the DU, and the first RRC release message includes SRS resource configuration and at least one of BWP configuration, time alignment configuration, RSRP variation threshold, timing advance verification configuration and / or absolute RSRP threshold (e.g., events 332, 334, 394, 432, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995).

[0271] In some implementations, the CU generates a BWP configuration, a time alignment configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold. In other implementations, the first DU to CU message includes a BWP configuration, a time alignment configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold.

[0272] In some implementations, the CU includes the SDT configuration in the first RRC release message. The SDT configuration includes the SDT CU configuration and / or the SDT DU configuration. In some implementations, the CU sends a second CU to DU message to the DU to obtain the SDT DU configuration, and in response, the DU sends a second DU to CU message including the SDT DU configuration to the CU.

[0273] In some implementations, the first CU to DU message is a positioning information request message. In some implementations, the first DU to CU message is a positioning information response message, a UE context modification request message, or a positioning information update message. For the UE context modification request message, in response, the CU sends a UE context modification confirmation message to the DU. In this case, the CU receives a positioning information response message from the DU in response to the positioning information request message.

[0274] Fig. 12B An example method 1200B similar to method 1200A is illustrated, except that method 1200B further includes blocks 1205 and 1208. Thus, the CU determines whether to send additional parameters based on whether the UE is configured to use the SRS resource configuration in an inactive state. In particular, at block 1205, the CU determines whether the UE is configured to use the SRS resource configuration for positioning in an inactive state. If the CU determines that the UE is configured to use the SRS resource configuration for positioning in an inactive state, the process proceeds to block 1206. Otherwise, if the CU determines that the UE is configured to use the SRS resource configuration for positioning in a connected state, the process proceeds to block 1208. At block 1208, the CU sends an RRC reconfiguration message (e.g., events 310, 312, 390, 590, 690, 706, 790, 890, 891, 990, 991) including the SRS resource configuration to the UE via the DU.

[0275] In some implementations, the CU refrains from including the BWP configuration, the time alignment configuration, the RSRP variation threshold, the timing advance verification configuration, and / or the absolute RSRP threshold in the RRC reconfiguration message at block 1208 .

[0276] Fig.13 A method 1300 is illustrated for configuring an SRS configuration for a UE (e.g., UE 102), which can be implemented by a DU (e.g., DU 174) in conjunction with a CU (e.g., CU 172). In particular, the method 1300 is a method for sending an SRS resource configuration and additional parameters to a CU and a UE.

[0277] The method 1300 starts at block 1302, where the DU receives a first CU-to-DU message from the CU requesting SRS resources for the UE (e.g., events 329, 394, 429, 494, 495, 594, 595, 695, 795, 895, 995). At block 1304, the DU sends a first DU-to-CU message (e.g., 331, 394, 431, 494, 495, 594, 595, 695, 795, 895, 995) to the CU including an SRS resource configuration and at least one of a BWP configuration, a time alignment configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold. At block 1306, the DU receives an RRC release message including an SRS resource configuration and at least one of a BWP configuration, a time alignment configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold from the CU (e.g., events 332, 394, 432, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). At block 1308, the DU sends an RRC release message to the UE (e.g., events 334, 394, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995).

[0278] In some implementations, the DU receives a second CU-to-DU message from the CU to obtain an SDT DU configuration for the UE (e.g., events 328, 428), and in response, the DU sends a second DU-to-CU message including the SDT DU configuration for the UE to the CU (e.g., events 330, 430). In some implementations, the RRC release message includes the SDT DU configuration.

[0279] In some implementations, the first CU-to-DU message may be a positioning information request message, as described above with respect to Fig. 12A Therefore, similar implementations are similarly applicable to the first CU to DU message and / or the DU to CU message.

[0280] Fig.14 A method 1400 is illustrated for configuring an SRS configuration for a UE (e.g., UE 102), which can be implemented by a DU (e.g., DU 174) communicating with a CU (e.g., CU 172). In particular, the method 1400 is a similar method to 1300, but wherein the DU determines to include additional parameters when the DU configures the SRS resource configuration for a case where the UE operates in an inactive state.

[0281] Method 1400 begins at block 1402, where the DU receives a first CU-to-DU message from the CU requesting SRS resources for the UE (e.g., events 329, 394, 429, 494, 495, 594, 595, 695, 795, 895, 995). At block 1404, the DU includes an SRS resource configuration in the first DU-to-CU message. At block 1406, the DU determines whether the DU configures the SRS resources for positioning in an inactive state. If the DU configures the SRS resources for positioning in an inactive state, the process proceeds to blocks 1408 and 1410. At block 1408, the DU includes at least one of a BWP configuration, a time alignment configuration, an RSRP variation threshold, a timing advance verification configuration, and / or an absolute RSRP threshold in the first DU-to-CU message. Otherwise, if the DU configures the SRS resource configuration for positioning in a connected state, the process proceeds to block 1410. That is, the DU avoids including the BWP configuration, the time alignment configuration, the RSRP variation threshold, the timing advance verification configuration, and / or the absolute RSRP threshold in the first DU to CU message. At block 1410, the DU sends the first DU to CU message to the CU (e.g., 331, 394, 431, 494, 495, 594, 595, 695, 795, 895, 995).

[0282] In some implementations, the first CU-to-DU message is a positioning information request message, as described above with respect to Fig. 12A Therefore, similar implementations are similarly applicable to the first CU to DU message and / or the DU to CU message.

[0283] Fig.15A A method 1500A is illustrated for configuring an SRS configuration for a UE (eg, UE 102), which may be implemented by a CU (eg, CU 172 or CU-CP 172A) in communication with a DU (eg, DU 174).

[0284] Method 1500A begins at block 1502, where the CU sends a first CU-to-DU message to the DU for requesting SRS resources for the UE (e.g., events 329, 394, 429, 494, 495, 594, 595, 695, 795, 895, 995). At block 1504, the CU receives a first DU-to-CU message including an SRS configuration from the DU (e.g., events 331, 394, 431, 494, 495, 594, 595, 695, 795, 895, 995). At block 1506, the CU sends a first RRC release message including an SRS configuration to the UE via the DU (e.g., events 332, 334, 394, 432, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995).

[0285] In some implementations, the CU includes the SDT configuration in the first RRC release message, as described above with respect to Fig. 12A In some implementations, the SRS configuration configures the SRS resources for positioning in an inactive state at block 1506. For example, the SRS configuration may be an SRS-PosRRC-InactiveConfig-r17 IE or an SRS-PosConfig-r17 IE. In some implementations, the first CU to DU message is a positioning information request message, as described above with respect to Fig. 12A , Fig.13 and Fig.14 Therefore, similar implementations are also similarly applicable.

[0286] Fig. 15B An example method 1500B similar to method 1500A is illustrated, except that method 1500B further includes blocks 1505 and 1508. Thus, the CU determines whether to send a release message or a reconfiguration message based on whether the CU requests SRS resources that the UE can use in an inactive state. In particular, at block 1505, the CU determines whether to request SRS resources that the UE can use in an inactive state. If the CU determines to request SRS resources that the UE can use in an inactive state, the process proceeds to block 1506. Otherwise, if the CU determines to request SRS resources that the UE can use in a connected state, the process proceeds to block 1508. At block 1508, the CU sends an RRC reconfiguration message (e.g., events 310, 312, 390, 590, 690, 706, 790, 890, 891, 990, 991) including an SRS configuration to the UE via the DU. In some implementations, the SRS configuration configures the SRS resources at block 1508 for positioning in a connected state. For example, the SRS configuration may be an SRS-Config IE.

[0287] Fig.16 A method 1600 is illustrated for configuring an SRS configuration for a UE (eg, UE 102), which may be implemented by a DU (eg, DU 174) in communication with a CU (eg, CU 172).

[0288] Method 1600 begins at block 1602, where the DU receives a first CU-to-DU message from the CU requesting SRS resources for the UE (e.g., events 329, 394, 429, 494, 495, 594, 595, 695, 795, 895, 995). At block 1604, the DU sends a first DU-to-CU message to the CU including a first SRS configuration (e.g., events 331, 394, 431, 494, 495, 594, 595, 695, 795, 895, 995). At block 1606, the DU receives an RRC release message from the CU including the first SRS configuration (e.g., events 332, 394, 432, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). At block 1608, the DU sends an RRC release message to the UE (e.g., events 334, 394, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995).

[0289] In some implementations, the first SRS configuration configures SRS resources for positioning in an inactive state. For example, the first SRS configuration may be SRS-PosRRC-InactiveConfig-r17 IE or SRS-PosConfig-r17 IE.

[0290] In some implementations, the first CU-to-DU message is a positioning information request message, as described above with respect to Fig. 12A Therefore, similar implementations are similarly applicable to the first CU to DU message and / or the DU to CU message.

[0291] In some implementations, the DU receives a second CU-to-DU message (e.g., a positioning information request message) from the CU requesting SRS resources for positioning by the UE (i.e., the first UE) or the second UE in a connected state. In some such implementations, in response, the DU sends a second DU-to-CU message including a second SRS configuration to the CU. In some implementations, the second SRS configuration configures the SRS resources for positioning in a connected state. For example, the second SRS configuration can be an SRS-Config IE. In some implementations, the DU receives an RRC reconfiguration message including a second SRS configuration and sends the RRC reconfiguration to the first UE or the second UE.

[0292] In some implementations, the DU receives a third CU-to-DU message from the CU to obtain an SDT DU configuration for the UE (e.g., events 328, 428), and in response, the DU sends a third DU-to-CU message including the SDT DU configuration for the UE to the CU (e.g., events 330, 430). The RRC release message may include the SDT DU configuration.

[0293] Fig.17 A method 1700 is illustrated for configuring an SRS configuration for a UE (e.g., UE 102), which can be implemented by a DU (e.g., DU 174) communicating with a CU (e.g., CU 172). In particular, method 1700 is a method similar to method 1600, but in which the DU determines whether to send a first SRS configuration or a second SRS configuration to the CU based on whether a message from the CU requests allocation of SRS resources for a UE in an inactive state.

[0294] Method 1700 begins at block 1702, where the DU receives a first CU-to-DU message from the CU requesting SRS resources for the UE (e.g., events 329, 394, 429, 494, 495, 594, 595, 695, 795, 895, 995). At block 1704, the DU determines whether the first CU-to-DU message requests SRS resources for positioning in an inactive state. If the first CU-to-DU message requests SRS resources for positioning in an inactive state, the process proceeds to block 1706. At block 1706, the DU includes the first SRS configuration in the first DU-to-CU message. Otherwise, if the first CU-to-DU message requests SRS resources for positioning in a connected state, the process proceeds to block 1708. At block 1708, the DU includes the second SRS configuration in the first DU-to-CU message. The process proceeds from block 1706 and from block 1708 to block 1710. At block 1710 , the DU sends a first DU-to-CU message to the CU (e.g., 331 , 394 , 431 , 494 , 495 , 594 , 595 , 695 , 795 , 895 , 995 ).

[0295] In some implementations, the first CU-to-DU message includes an indication to the DU that the CU requests SRS resources for positioning in an inactive state. Therefore, if the first CU-to-DU message includes the indication, the DU can determine that the first CU-to-DU message requests SRS resources for positioning in an inactive state. If the first CU-to-DU message does not include the indication, the DU determines that the first CU-to-DU message requests SRS resources for positioning in a connected state.

[0296] In some implementations, the first CU-to-DU message is a positioning information request message, as described above with respect to Fig. 12A Therefore, similar implementations are similarly applicable to the first CU to DU message and / or the DU to CU message.

[0297] In some implementations, the first SRS configuration configures SRS resources for positioning in an inactive state and / or the second SRS configuration configures SRS resources for positioning in a connected state, such as with respect to Fig.16 Therefore, similar implementations are also similarly applicable.

[0298] Fig.18A method 1800 is illustrated for configuring an SRS configuration for a UE (e.g., UE 102), which can be implemented by a CU (e.g., CU 172 or CU-CP 172A) via a DU (e.g., DU 174). In particular, the method 1800 is a method for determining whether to include an indication for requesting SRS resources in a DU message based on whether the CU requests SRS resources that the UE can use in an inactive state.

[0299] Method 1800 starts at block 1802, where the CU determines to request SRS resources for the UE. At block 1804, the CU determines whether to request SRS resources that the UE can / will use in an inactive state (i.e., whether to request SRS resources in an inactive state). If the CU determines to request SRS resources for positioning in an inactive state, the process proceeds to blocks 1806 and 1808. At block 1806, the CU includes an indication indicating that SRS resources are requested for an inactive state in a first CU-to-DU message (e.g., events 329, 394, 429, 494, 495, 594, 595, 695, 795, 895, 995). Otherwise, if the CU determines to request SRS resources for positioning in a connected state, the process proceeds to block 1808. At block 1808, the CU sends the first CU-to-DU message to the DU.

[0300] In some implementations, after the CU sends the first CU-to-DU message to the DU, the CU receives the first DU-to-CU message from the DU (e.g., events 331, 394, 431, 494, 495, 594, 595, 695, 795, 895, 995). If the first CU-to-DU message includes an indication, the first DU-to-CU message may include an indication for Fig.16 and Fig.17 If the first CU to DU message does not include an indication, the first DU to CU message may include an indication of Fig.16 and Fig.17 The second SRS configuration.

[0301] The examples and implementations of the first CU to DU message and the first DU to CU message may be applicable to Fig.18 .

[0302] The following considerations may apply to the above description.

[0303] Generally speaking, the description of one of the figures in the above-mentioned figures may apply to another figure in the above-mentioned figures. Any of the above-mentioned events or boxes may be optional. For example, events or boxes with dashed lines may be optional. In some implementations, "message" is used, and "message" can be replaced with "information element (IE)", and vice versa. In some implementations, "IE" is used and "IE" can be replaced with "field", and vice versa. In some implementations, "configuration" or "configuration parameter" can be replaced with "configuration", and vice versa. In some implementations, "early data transmission (EDT)" can be replaced with "small data transmission", and "SDT" can be replaced with "EDT", and vice versa. In some implementations, "small data transmission" can be replaced with "small data communication", and vice versa. In some implementations, "stop" can be replaced with "pause".

[0304] In some implementations, the "second UE CG-SDT timer" may be replaced with a "CG-SDT retransmission timer (cg-SDT-RetransmissionTimer)". In some implementations, "CG-SDT", "CG", and "SDT-CG" may be interchangeable.

[0305] The user device (e.g., UE 102) in which the technology of the present disclosure can be implemented can be any suitable device capable of wireless communication, such as a smart phone, a tablet computer, a laptop computer, a mobile game console, a point of sale (POS) terminal, a health monitoring device, a drone, a camera, a media streaming dongle or another personal media device, a wearable device such as a smart watch, a wireless hotspot, a femtocell or a broadband router. Further, in some cases, the user device can be embedded in an electronic system, such as a head unit (head unit) or an advanced driver assistance system (ADAS) of a vehicle. Still further, the user device can be operated as an Internet of Things (IoT) device or a mobile Internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0306] Certain embodiments are described in the present disclosure as including logic or multiple components or modules. A module may be a software module (e.g., a code or machine-readable instruction stored on a non-temporary machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and may be configured or arranged in a particular manner. A hardware module may include a dedicated circuit system (circuitry) or logic that is permanently configured to perform certain operations (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.). A hardware module may also include programmable logic or circuit systems (e.g., as contained in a general-purpose processor or other programmable processor) that are temporarily configured by software to perform certain operations. The decision to implement a hardware module with a dedicated and permanently configured circuit system or with a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

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

Claims

1. A method implemented in a central unit CU of a distributed base station, the distributed base station further comprising a distributed unit DU, the method comprising: sending (1502) a CU-to-DU message to the DU requesting a sounding reference signal (SRS) resource for the UE; receiving (1504) from the DU a DU-to-CU message including an SRS configuration for the UE in response to the CU-to-DU message; and A command to release a radio connection is sent (1506) to the UE via the DU, the command including the SRS configuration.

2. The method of claim 1, wherein the sending of the CU to DU message comprises: Send a request for location information.

3. The method of claim 2, wherein the receiving of the DU to CU message comprises: Receive positioning information response.

4. The method according to any one of the preceding claims, further comprising: An indication that the SRS resource is specific to SRS transmission in an inactive state of the UE is included in the CU-to-DU message.

5. The method of claim 4, further comprising: An SRS transmission is received (1008) from the UE in the inactive state based on the SRS configuration.

6. The method of claim 5, further comprising: The SRS configuration is retained (1014) after the UE transitions to a connected state.

7. The method of any one of the preceding claims, further comprising: The SRS-PosRRC-InactiveConfig information element IE is included in the SRS configuration.

8. The method of claim 7, further comprising: Include the SRS-PosRRC-InactiveConfigIE in the suspension configuration; as well as The suspension configuration is included in the command to release the radio connection.

9. The method of any one of the preceding claims, further comprising: An SRS validity timer is started in response to the sending of the command to release a radio connection to limit the validity of an SRS resource configuration at the UE.

10. A method implemented in a distributed unit DU of a distributed base station, the distributed base station further comprising a central unit CU, the method comprising: receiving (1602) a CU-to-DU message from the CU requesting a sounding reference signal (SRS) resource for the UE; sending (1604) a DU-to-CU message including an SRS configuration for the UE to the DU in response to the CU-to-DU message; receiving (1606) a command to release a radio connection from the CU, the command including the SRS configuration; and The command is sent (1608) to the UE.

11. The method of claim 10, wherein the receiving of the CU to DU message comprises: Receive a location information request.

12. The method of claim 11, wherein the sending of the DU to CU message comprises: Send positioning information response.

13. The method of any one of claims 10 to 12, further comprising: An indication is received in the CU-to-DU message that the SRS resource is specific to SRS transmission in an inactive state of the UE.

14. The method of any one of claims 10 to 13, further comprising: An SRS transmission is received from the UE in the inactive state based on the SRS configuration.

15. A network node configured to operate in a Radio Access Network, RAN, the network node comprising processing hardware and configured to implement the method according to any one of the preceding claims.

Images