Managing small data transfer configuration parameters

Abstract

A distributed unit (DU) in communication with a central unit (CU) may implement a method for managing small data transmission (SDT) configuration for a user equipment (UE). The method comprises: (i) receiving, at the DU, a first SDT configuration for the UE; (ii) receiving, at the DU and from the CU, a UE context modification message comprising an SDT configuration request; and (iii) transmitting a UE context modification response comprising the second SDT configuration from the DU to the CU based on the first SDT configuration in response to receiving the UE context modification message.

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 / 329,353, entitled “MANAGING SMALL DATA CONFIGURATION PARAMETERS,” filed on April 8, 2022. The entire contents of the 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 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 considered 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_INACTI VE, which is used to allow 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_INACTI VE state has only a relatively small packet to send. The Small Data Transfer (SDT) procedure enables 5G NR to support data transmission for UEs operating in the RRC_INACTI VE state (i.e., without transitioning to the RRC_CONNECTED state).

[0007] The device enables SDT for a specific radio bearer. The UE initiates SDT when less than the configured amount of uplink data is waiting to be sent on all radio bearers for which SDT is enabled, the downlink reference signal received power (RSRP) is above the configured threshold, and valid SDT resources are available. In addition, the UE initiates the SDT process by transmission on the random access channel (RACH) (as part of a random access SDT (RA-SDT) session) or on type 1 configured grant (CG) resources (as part of a CG-SDT session). For RA-SDT, the network configures 2-step and / or 4-step random access resources for SDT transmission. In a RA-SDT session, the UE performs an initial transmission including data in message 3 (MSG3) of a 4-step random access procedure or in message A (MSGA) of a 2-step random access procedure. After completing the random access procedure, the network then schedules subsequent uplink and / or downlink transmissions using uplink grants and downlink assignments, respectively.

[0008] The UE initiates a CG-SDT session with a valid uplink (UL) timing alignment. The UE uses the network-configured SDT-specific timing alignment timer and the downlink (DL) RSRP of the configured number of highest-ranked synchronization signal blocks (SSBs) to maintain UL timing alignment. After the SDT-specific timing alignment timer expires, the UE releases the CG resources. After initiating CG-SDT, the UE uses the CG to perform an initial transmission including data during the CG opportunity, and the network uses dynamic grants to schedule subsequent uplink transmissions. Alternatively, uplink transmissions occur during subsequent CG resource opportunities. During the CG-SDT, the base station uses dynamic assignments to schedule downlink transmissions. The UE initiates subsequent uplink transmissions after receiving confirmation of the initial transmission from the network.

[0009] However, in some scenarios and implementations, the UE may be connected to a Radio Access Network (RAN) node. It is unclear how the RAN node provides SDT configuration parameters to the UE to enable SDT. Summary of the invention

[0010] The DU manages the SDT configuration for the UE according to the first method when communicating with the CU. In particular, the DU node receives a first SDT configuration for the UE at the DU. Then, the DU receives a UE context modification message including an SDT configuration request at the DU and from the CU. Then, the DU sends a UE context modification response including a second SDT configuration from the DU to the CU based on the first SDT configuration in response to receiving the UE context modification message.

[0011] Similarly, the CU manages the SDT configuration for the UE according to the second method when communicating with the DU. In particular, the CU provides the first SDT configuration to the DU, and sends a UE context modification message from the CU to the DU. Then, the CU receives a UE context modification response including a second SDT configuration from the DU in response to the sending of the UE context modification message at the CU. Then, the CU sends a downlink message including the second SDT configuration from the CU to the UE via the DU. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1A is a block diagram of an example wireless communication system in which the user devices and base stations of the present disclosure may implement the techniques of the present disclosure for managing small data transmissions;

[0013] Figure 1B is a block diagram of an example base station in which a centralized unit (CU) and a distributed unit (DU) may be Figure 1A Operate in a system

[0014] Figure 2A is a block diagram of an example protocol stack, Figure 1A The UE communicates with the base station according to the protocol stack;

[0015] Figure 2B is a block diagram of an example protocol stack, Figure 1A The UE communicates with the CU and the DU according to the protocol stack;

[0016] Figure 3 An example scenario is shown in which the UE communicates with the DU of the RAN using a non-SDT configuration before the UE receives an SDT configuration from the DU and transitions to an inactive state;

[0017] Figure 4An example scenario is shown in which the UE communicates with the DU of the RAN while in an inactive state before the UE receives an SDT configuration from the DU and remains in an inactive state;

[0018] Figure 5A An example scenario is shown in which the UE transitions from an inactive state to a connected state before the UE receives an SDT configuration from a DU and transitions back to an inactive state;

[0019] Figure 5B Shown with Figure 5A A scenario similar to that of , but where the UE does not initially communicate small data with the DU when in the initial inactive state;

[0020] Fig. 6A An example scenario is shown in which the UE receives an SDT configuration with an RRC release command from the DU;

[0021] Figure 6B An example scenario is shown in which the UE initiates uplink SDT in an inactive state and continues to communicate uplink and / or downlink data via a DU;

[0022] Figure 6C An example scenario is shown in which a UE receives an SDT configuration in a connected state and communicates small data according to the received SDT configuration in an inactive state;

[0023] Fig. 7A An example scenario is shown in which a first base station hands over a UE to a second base station and the UE receives an SDT configuration from the second base station;

[0024] Figure 7B Shown with Fig. 7A A similar example scenario, except that the first base station is preparing to perform a handover with the second base station via the CN;

[0025] Figure 8 An example scenario for managing SDT configuration in an RRC re-establishment scenario is shown;

[0026] Fig. 9 Shown with Figure 8 The example scenario is similar to the scenario of , except that the CU releases the UE context instead of retaining the UE context;

[0027] Fig. 10A A flowchart illustrating an example method in a CU for sending an indication to a UE to continue applying an SDT configuration;

[0028] Fig. 10B Shown with Fig. 10A A flowchart of a similar example method, but wherein the CU sends an indication to the UE to update the SDT configuration;

[0029] Fig. 10C Shown with Fig. 10A A flowchart of a similar example method, but wherein the CU sends an indication to the UE to release the SDT configuration;

[0030] Fig. 10D Shown with Fig. 10A A flow chart of a similar example method, but wherein the CU determines whether to update the SDT configuration based on whether the CU receives a second SDT configuration;

[0031] Fig.10E Shown with Fig. 10A A flow chart of a similar example method, but wherein the CU obtains the SDT DU configuration from the DU and sends a release message including the SDT DU configuration to the UE;

[0032] Fig.10F Shown with Fig. 10A A flow chart of a similar example method, but wherein the CU discards the first SDT configuration and causes the UE to release the SDT configuration;

[0033] Fig.11 A flow chart illustrating an example method implemented in a CU for determining whether to include an SDT DU configuration in a message to a DU;

[0034] Fig. 12A A flow chart illustrating an example method implemented in a DU for receiving a request for an SDT DU configuration from a CU and sending or refraining from sending an SDT configuration in response;

[0035] Fig. 12B Shown with Fig. 12A A flow chart of a similar example method, but wherein the DU generates and sends a second SDT DU configuration;

[0036] Fig. 12C Shown with Fig. 12A A flow chart of a similar example method, but wherein the DU determines whether to send a second SDT DU configuration based on whether to update the first SDT DU configuration;

[0037] Fig.13A The method implemented in the DU for determining whether to execute the incremental configuration depends on whether the DU supports the incremental configuration. FIG. 12A to FIG. 12C One of the methods is also a flowchart of an example method for generating a full configuration;

[0038] Fig. 13B Shown with Fig.14A A flow chart of a similar example method, but wherein the DU makes a determination based on whether the DU has received or stored a first SDT DU configuration;

[0039] Fig.14A A flow chart illustrating an example method implemented in a DU for determining whether to send an SDT DU configuration and an indication that the SDT DU configuration is a full configuration;

[0040] Fig. 14B Shown with Fig.14A A flow chart of a similar example method, but wherein the determination is whether to send an indication of whether the SDTDU configuration is an incremental configuration; and

[0041] Fig. 14C Shown with Fig.14A Flowchart of a similar example method, but where the DU determines whether to send an indication of full configuration or incremental configuration. DETAILED DESCRIPTION

[0042] 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 for managing early data communications and transitioning the UE between states of a protocol for controlling radio resources between the UE and the RAN. As used in the present disclosure, early data communications may refer to early data transmission (EDT) from a network perspective (i.e., EDT in a downlink direction), or EDT from a UE perspective (i.e., EDT in an uplink direction).

[0043] First reference Figure 1A , the example wireless communication system 100 includes a UE 102, a base station (BS) 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 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.

[0044] 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, 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).

[0045] 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 deliver user plane packets related to audio calls, video calls, Internet services, 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 deliver user plane packets related to audio calls, video calls, Internet services, 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.

[0046] 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 can select a cell, reselect a cell, or switch from one of cells 124 and 126 to another. In order to directly exchange messages or information, 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.

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

[0048] 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) flow (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 (IIoT) data, Ethernet service data, Internet service data, or Short Message Service (SMS) messages. In addition, as discussed below, in some implementations, the UE 102 applies these techniques only if the size of the data is below a certain threshold.

[0049] 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 (IID) of UE 102 in the UL RRC message. RAN 105 may identify UE 102 based on the UE IID. 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).

[0050] 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-II) for integrity to protect the integrity of the data. Therefore, in this case, UE 102 generates a security-protected packet including data and MAC-II. When encryption is enabled, UE 102 may encrypt data to obtain an encrypted packet so that the security-protected packet includes encrypted data. When both integrity protection and encryption are enabled, UE 102 may generate a MAC-II for protecting the integrity of the data and encrypt the data together with the MAC-II 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.

[0051] 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 another implementation, 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 another implementation, 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-II is the resumeMAC-I field (e.g., as specified in 3GPP specification 38.331). In another implementation, the UE may utilize an integrity key (e.g., K RRCint The RRC MAC-II 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 DI RECTION (e.g., a 1-bit value).

[0052] In another 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) that 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.

[0053] 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 UEID of the UE 102 as described above.

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

[0055] In some scenarios and implementations, the base station 106 may retrieve the UEIID 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 UEIID. In an 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., an encryption and / or decryption key). If the security-protected packet is an integrity-protected packet, the integrity-protected packet may include data and MAC-II. The base station 104 may verify whether MAC-II is valid for the security-protected packet by using at least one security key (e.g., an integrity key). When the base station 104 confirms that MAC-I is valid, the base station 104 sends data to the CN 110 or the edge server. However, when the base station 104 determines that 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 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.

[0056] 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 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-II. In this case, the base station 106 decrypts the encrypted packet and the encrypted MAC-II to obtain the data and MAC-II. The base station 106 then determines whether MAC-II is valid for the data. If the base station 106 determines that MAC-II 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 MAC-II is invalid, the base station 106 discards the packet.

[0057] In other scenarios and implementations, the base station 104 can retrieve the UE ID of the UE 102 from the UL RRC message and recognize that the base station 104 stores the UE context information of the UE 102. Accordingly, 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.

[0058] In addition, 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.

[0059] 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. In addition, 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.

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

[0061] 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_INACTI VE 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 another 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) sent by the base station to UE 102 before sending the DCI and the scrambled CRC (e.g., when UE 102 is in the RRC_CONNECTED state).

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

[0063] 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, and the one or more general-purpose processors execute the instructions. 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: in some scenarios, send DL PDCP PDUs, and the base station 104 can send data in the downlink direction according to the DL PDCP PDU; and in other scenarios, receive UL PDCP PDUs, and the base station 104 can receive data in the uplink direction according to the UL PDCP PDU. The processing hardware may also 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, which is configured to manage uplink and / or downlink communications when one or more UEs operate in an RRC_INACTI VE or RRC_IDLE state. The base station 106 may include substantially similar components. In particular, the components 140, 142, 144, 146, and 148 of the base station 106 may be similar to the components 130, 132, 134, 136, and 138, respectively.

[0064] 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 that can be executed on one or more general-purpose processors, and / or special-purpose processing units. 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 the RRC_INACTI VE 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 DL PDCP PDUs, and the base station 106 can send data in the downlink direction according to the DL PDCP PDU; and in other scenarios, receive UL PDCP PDUs, and the base station 106 can receive data in the uplink direction according to the UL PDCP PDU. The processing hardware may also include an RRC controller 156 to implement processes and message delivery at the RRC sublayer of the protocol communication stack.

[0065] 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 another implementation, the CU 172 does not include an RLC controller.

[0066] 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), which is configured to manage or control one or more MAC operations or processes (e.g., random access processes), and / or an RLC controller, which is configured to manage or control one or more RLC operations or processes. The processing hardware may also include a physical layer controller, which is configured to manage or control one or more physical layer operations or processes.

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

[0068] 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).

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

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

[0071] 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 NRRPHY 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 In some implementations, UE 102 supports both EUTRA and NR stacks, such as Figure 2A As shown, to support switching between EUTRA and NR base stations and / or to support DC on EUTRA and NR interfaces. Figure 2A As shown, the UE 102 can support NR PDCP 210 layered on the EUTRA RLC 206A, and the SDAP sublayer 212 layered on the NR PDCP sublayer 210.

[0072] 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 difference between SDUs and PDUs is relevant.

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

[0074] 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 split, 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 provides SRBs to the RRC 214.

[0075] Next, refer to Figures 3 to 9 To discuss the Figure 1A Several components of and several example scenarios related to sending data in an inactive or idle state. In general, Figures 3 to 9 Similar events are marked with similar reference numerals (e.g., FIG. 5A to FIG. 5B Event 508 in Figure 6C Event 608 in Figure 8 Event 808 and Fig. 9 908 in FIG. 1 ), with differences discussed below where appropriate. In addition to the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for message delivery and processing) may apply to events labeled with similar reference numerals in other figures. To simplify the following description, "inactive state" is used and may refer to the RRC_INACTI VE or RRC_IDLE state, and "connected state" is used and may refer to the RRC_CONNECTED state.

[0076] first, Figure 3A scenario 300 is shown in which a 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 of the base station 104 by using a DU configuration (i.e., a first non-SDT configuration), and communicates 304 with the CU-CP 172A and / or CU-UP 172B via the DU by using a CU configuration (i.e., a first non-SDT-CU configuration). While the UE 102 is communicating 304 with the base station 104, the CU-CP 172A may send 306 a UE context modification request message. In response, the DU 174 sends 308 a UE context modification response message including a non-SDT configuration 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 RR 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.

[0077] 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 may augment the first non-SDT CU configuration or include at least one new configuration parameter that is not included in the first non-SDT CU configuration. In some such cases, the UE 102, CU-CP 172A, and / or CU-UP 172B 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.

[0078] 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., RRC214 and / or NR PDCP 210), and when the UE 102 operates in a connected state, the UE 102 and the CU 172 use the configuration parameters to communicate with each other. In another implementation, the second non-SDT CU configuration also includes configuration parameters related to the operation of the RRC and / or PDCP protocol layers. 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). Similarly, the second non-SDT CU configuration includes configuration parameters in a RadioBearerConfig IE and / or a MeasConfig IE. In some implementations, the first non-SDT CU configuration is or includes a RadoBearerConfig IE and / or a MeasConfig IE, and the second non-SDT CU configuration is or includes a RadoBearerConfig IE and / or a MeasConfig IE.

[0079] In some implementations, the second non-SDT DU configuration may extend the first non-SDT DU configuration or include at least one new configuration parameter not included in the first non-SDT DU configuration. In 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-SDT DU configuration that are not extended 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 use the configuration parameters to communicate with each other when the UE 102 operates in a connected state. In other implementations, the second non-SDT DU configuration includes configuration parameters related to the operation of the RRC, RLC, MAC, and / or PHY protocol layers. 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). Similarly, the second non-SDT DU configuration includes configuration parameters in a CellGroupConfig IE. In some implementations, the first non-SDT DU configuration and the second non-SDT DU configuration are CellGroupConfig IEs.

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

[0081] 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 has no data activity with the base station 104). 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 UE 102 determines or detects the data inactivity and sends 320 UE assistance information (e.g., a UEAssistanceInformation message) to the DU 174, the UE assistance information indicating that the UE 102 prefers or requests to transition to the inactive state or leave the connected state. In some implementations, the UE 102 may indicate in the UE assistance information that the UE 102 prefers or requests to transition to the inactive state configured with SDT. Then, DU 174 sends 321 a UL RRC messaging message including the UE assistance information to CU-CP 172A. Thus, CU-CP 172A determines that UE 102 is in data inactivity based on the UE assistance information.

[0082] In other implementations, DU 174 performs data inactivity monitoring for UE 102. CU-CP 172A may send 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 some cases 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 may determine 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. CU-CP 172A may send 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 the event that 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 may determine 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, an inactivity notification of event 322, and / or an inactivity notification of event 323.

[0083] After a specific period of data inactivity, CU-CP 172A may determine that CU 172 (i.e., CU-CP 172A and / or CU-UP 172B) or UE 102 did not send any data in the downlink direction or uplink direction during the specific period, respectively. In response to the determination, CU-CP 172A determines to transition UE 102 to an inactive state with SDT configured. 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.

[0084] In response to or after determining that the UE 102 is in data inactivity (for a specific period of time) or determining to transition the UE 102 to an inactive state configured with SDT, 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 a specific period of time) or determining to transition the UE 102 to an inactive state configured with SDT, or after determining that the UE 102 is in data inactivity (for a specific period of time) or determining to transition the UE 102 to an inactive state configured with SDT, 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 or an SDT query indication IE) for requesting the SDT DU configuration in the second CU-to-DU message. In response to the SDT request indication or the second CU-to-DU message, the DU 174 may send 330 a second DU-to-CU message (e.g., a UE context modification response message) to the CU-CP 172A. Alternatively, 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, DU 174 sends an additional DU to CU message (e.g., UE context modification required message) including the SDT DU configuration to CU-CP 172A.

[0085] In some implementations, CU-CP 172A sends an additional CU-to-DU message (e.g., a UE context modification confirmation message) to 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 information 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 of event 308, and DU 174 includes an SDT DU configuration in the first DU-to-CU message of event 310 in response to the SDT request indication.

[0086] In some alternative implementations, DU 174 does not send the SDT DU configuration for UE 102 to CU-CP 172A because DU 174 is congested or does 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.

[0087] In response to determining that the UE 102 is transitioned to an inactive state configured with SDT, the CU-CP 172A may generate 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 may include a suspension configuration (e.g., a SuspendConfi g IE) in the RRC release message. The CU-CP 172A may include an SDT DU configuration (if obtained from DU 174) and / or an SDT CU 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) to the DU 174, and the third CU to DU message includes the RRC release message. Subsequently, the DU 174 sends 334 an RRC release message to the UE 102. In some implementations, DU 174 generates a MAC PDU including an 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. Upon receiving the RRC release message, UE 102 transitions 336 from a connected state to an inactive state. Depending on the implementation, 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 / or releases or retains at least some of the first non-SDT DU configuration and / or at least some 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.

[0088] 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 after receiving 334 an RRC release message, 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 a connected state to an inactive state, or after receiving 334 an RRC release message or transitioning 336 from a connected state to an inactive state, the UE 102 retains the C-RNTI. In some implementations, the UE 102 performs a two-step or four-step random access procedure with a 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 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.

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

[0090] In some implementations, the UE 102 releases at least a portion of the first non-SDT DU configuration and / or at least a portion of the second non-SDT DU configuration in response to the RRC release message. In other implementations, if the RRC release message instructs the UE 102 to transition to an inactive state (i.e., RRC_IDLE), the 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 the UE to transition to an inactive state (i.e., RRC_INACTI VE), the 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. In still other implementations, if the RRC release message instructs the UE 102 to transition to an inactive state (ie, RRC_INACTIVE), the UE 102 retains the first non-SDT DU configuration (not augmented by the second non-SDT DU configuration (if received)) and / or the second non-SDT DU configuration.

[0091] In some implementations, CU-CP 172A does not include an indication instructing DU 174 to retain the SDT DU configuration in a third CU to DU message. DU 174 retains the SDT DU configuration as described above. In other implementations, CU-CP 172A may include an indication 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. In some such implementations, 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 instructing DU 174 to release the SDT DU configuration for UE 102 in a third CU to DU message (e.g., a UE context modification request message or a DL RRC messaging message). Therefore, DU 174 retains the SDT DU configuration in response to the third CU to DU message excluding the indication. If the third CU-to-DU message includes the indication, the DU 174 releases the SDT DU configuration.

[0092] In some implementations, the SDT CU configuration (e.g., SDT-Config IE) includes an SDT DRB list (e.g., std-DRB-List), the 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 an SDT DU configuration in the SDT CU configuration. In some implementations, the “SDT CU configuration” is simplified to “SDT configuration”.

[0093] 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. The UL BWP configuration may include a CG configuration, a PUCCH configuration, a PUSCH configuration, and / or a sounding reference signal (SRS) configuration. In some implementations, the DL BWP configuration configures a dedicated DL BWP for the UE 102 during the CG-SDT. In another implementation, the DL BWP configuration includes a PDCCH configuration and / or a PDSCH configuration for UE 102 to receive DL control signals from DU 174 on PDCCH and receive data on PDSCH when the UE performs CG-SDT with DU 174. Each of the CG configurations configures periodic radio resources (i.e., CG resources) that UE 102 can use to send data without receiving a dynamic grant for data transmission. Each of the CG configurations configures or includes a periodicity indicating that the CG resources appear 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.

[0094] In some implementations, each of the CG configurations 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., system frame number (SFN)). In some implementations, the CG configuration may configure or include a reference time (e.g., timeReferenceSFN). In other implementations, the CG configuration is or is similar to a ConfiguredGrantConfig IE (e.g., as specified in 3GPP specification 38.331). DU 174 configures a timing advance validity threshold (e.g., including an RSRP range) for use by the UE 102 to determine whether the UE 102 can initiate SDT using the configured grant configuration for CG-SDT, such as for Figure 4 Depending on the implementation and based on the timing advance validity threshold, UE 102 evaluates whether the stored timing advance value is still valid. If UE 102 determines that the stored timing advance value is invalid, UE 102 initiates RA-SDT with CU 172 via DU 174, as for Figure 4 Described. In some implementations, the SDT DU configuration is an SDT-MAC-PHY-CG-Config IE, an SDT-MAC-PHY-Config IE, an SDT-CellConfig IE, or an SDT-CellGroupConfig IE. In some implementations, "SDT DU configuration" is replaced with "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 are grouped into the CG-SDT configuration, and other configurations in the SDT DU configuration (e.g., BSR configuration and / or PHR configuration) are not CG-SDT configurations. The SDT DU configuration includes a CG-SDT configuration. In some such cases, other configurations are configured for CG-SDT or RA-SDT.

[0095] In some implementations, 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 CU 172, receiving 332 a third CU to DU message, or sending 334 a CG-SDT configuration to UE 102. In another implementation, 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. When the DU CG-SDT timer expires, DU 174 releases the CG-SDT configuration or the CG resources configured in the CG-SDT configuration. When the CG-SDT configuration is released, 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 and / or scheduling transmissions for other UEs on the radio resources reserved or configured for the CG-SDT configuration.

[0096] 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 after receiving the CG-SDT configuration, the UE 102 starts or restarts the UE CG-SDT timer (e.g., CG-SDT-TAT). In some implementations, in response to receiving the CG-SDT configuration, or after receiving the CG-SDT configuration, the UE 102 starts or restarts the UE CG-SDT timer (i.e., the first UE CG-SDT timer) using the CG-SDT time alignment timer value. When the UE CG-SDT timer expires, the UE 102 can release the CG-SDT configuration. Alternatively, when the UE CG-SDT timer expires, the UE 102 retains the CG-SDT configuration and avoids sending UL transmissions (e.g., MAC PDUs) on the CG resources. In some such implementations, the UE 102 releases the CG resources or determines that the CG resources are invalid. When the UECG-SDT timer expires, the UE 102 may release the SRS configuration or the SRS resources configured in the SRS configuration. Alternatively, when the UECG-SDT timer expires, the UE 102 retains the SRS configuration and avoids sending one or more SRSs to the DU 174 on the SRS resources.

[0097] 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 some such cases, the UE 102 retunes 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 switches to the initial DL BWP and the initial UL BWP 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 DLBWP.

[0098] In some implementations, the DU 174 or CU-CP 172A 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 some such cases, the UE 102 does not re-tune the transceiver of the UE 102 due to switching BWP. In other 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 still other 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.

[0099] In some implementations, in response to or after 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 the expiration of the UE CG-SDT timer, or after the expiration of the UE CG-SDT timer, the UE 102 determines that the RA-SDT is valid.

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

[0101] 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 or after receiving the third CU-to-DU message.

[0102] 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 performs RA-SDT with CU 172 via DU 174, such as for Figure 4 described.

[0103] 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 an SDT DU configuration without requesting DU 174 to provide an SDT DU configuration, and includes the SDT DU configuration in the RRC release message.

[0104] 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, DU 174 may send 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 may include the CG-SDT configuration in the SDT DU configuration as described above.

[0105] In some implementations, such as when UE 102 supports CG-SDT and / or DU 174 supports CG-SDT, CU-CP 172A may request 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. Depending on the implementation, when the UE is operating 302 in a connected state, CU-CP 172A receives UE capabilities (e.g., UE-EUTRA-Capability IE, UE-NR-Capability IE, or UE-6G-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. The DU-to-CU message may 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 as defined in 3GPP specification 38.473).

[0106] In some implementations, DU 174 determines whether to provide the SDT DU configuration for UE 102 to CU-CP 172A depending on whether UE 102 supports CG-SDT. Depending on the implementation, in addition to whether UE 102 supports CG-SDT, DU 174 additionally determines whether to provide the SDT DU configuration for UE 102 to CU-CP 172A depending on whether DU 174 supports CG-SDT. In the case that UE 102 supports CG-SDT and / or DU 174 supports CG-SDT, DU 174 provides the first SDT DU configuration for UE 102 to CU-CP 172A, as described above. In the case that UE 102 does not support CG-SDT or DU 174 does not support CG-SDT, DU 174 does not provide the SDT DU configuration for UE 102 (e.g., DU 174 does not include the SDT DU configuration in the second DU to CU message). When the UE operates in a connected state 302 or operates in an inactive state before event 302, the DU 174 may receive UE capabilities from the CU-CP 172A. Thus, the DU 174 may determine whether the UE 102 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 to indicate whether the DU 174 supports CG-SDT, as described above.

[0107] Reference now Figure 4 , scenario 400 depicts a small data transfer. Although UE 102 in scenario 300 begins in a connected state (e.g., event 302), scenario 400 illustrates a process when UE 102 begins in an inactive state (e.g., event 402). 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 3Described. In such an implementation, the UE receives a first SDT CU configuration and / or a first SDT DU configuration in an RRC release message (e.g., similar to event 334). In other implementations or scenarios, the UE 102 transitions from an inactive state where SDT is not configured to an inactive state where 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 and does not configure SDT (e.g., indicating release of SDT or not including the SDT configuration in the RRC release message). In some such implementations, the UE 102 transitions to an inactive state where SDT is not configured in response to the RRC release message. The UE 102 in an inactive state where SDT is configured or not configured performs a RAN Notification Area (RNA) update with the base station without a state transition. During the RNA update, UE 102 receives another RRC release message (e.g., similar to the RRC release message in event 334) from the base station that includes the first SDT CU configuration and / or the first SDT DU configuration.

[0108] At a later time, the UE 102 operating in the inactive state configured with SDT initiates SDT. In response to initiating SDT, 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 1A The UE 102 sends 404 an initial UL MACPDU to the DU 174 on another cell (not shown in FIG. 1 ). The following events between the UE 102 and the DU 174 occur on the cell.

[0109] In some implementations, the UE 102 starts an SDT session timer in response to initiating the SDT. In some implementations, the SDT session timer is a new timer (e.g., T319a defined in the RRC specification (e.g., v17.0.0)). The DU 174 retrieves the UL RRC message from the initial UL MAC PDU, generates a first DU to CU message including the UL RRC message, and sends 406 the first DU to CU message to the 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.

[0110] In a scenario where the UE 102 initiates an SDT to send UL data (e.g., data packets) eligible for SDT, the UE 102 sends 404 an initial UL MAC PDU including the UL data. In a scenario where the UE 102 initiates an SDT to receive DL data, the UE 102 sends 404 an initial UL MAC PDU without an UL data packet. Depending on the implementation, the UE 102 initiates an SDT to receive DL data in response to receiving (not shown) a paging message from the DU 174. In some such scenarios, the UE 102 includes an SDT indication in the initial UL MAC PDU or UL RRC message to indicate to the base station 104 that the UE 102 is initiating an SDT to receive DL data.

[0111] In some implementations, the UE 102 in an inactive state performs a random access procedure with the DU 174 to send 404 an 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 where the procedure is 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 a dynamic uplink grant, a temporary C-RNTI, and a timing advance command to the UE 102. The UE 102 then sends 404 an UL MAC PDU to the DU 174 based on the dynamic uplink grant. The DU 174 receives 404 the UL MAC PDU based on the dynamic uplink grant in the RAR, and in response, sends a DL MAC PDU including a contention resolution MAC control element to the UE 102.

[0112] In the case where the procedure is 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. 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. The DU 174 includes a contention resolution MAC control element in the MsgB. Before sending 404 the UL MAC PDU, the UE 102 receives the two-step random access configuration parameters in the system information broadcasted by the DU 174 on the cell 124. The DU 174 receives 404 the UL MAC PDU according to the two-step random access configuration parameters.

[0113] When UE 102 successfully performs contention resolution (i.e., receives a contention resolution MAC control element) during the random access procedure, UE 102 discards the previously reserved C-RNTI (e.g., as for Figure 3418 UL data and / or DL ​​data). The UE 102 uses the C-RNTI to monitor the PDCCH from the DU 174 to communicate 418 data (e.g., UL data and / or DL ​​data) with the base station 104. 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. The DCI may include a dynamic uplink grant or a downlink assignment. If the UE 102 verifies that the CRC is correct and the DCI includes a dynamic uplink grant, the UE 102 uses the dynamic 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. In some implementations, the DU 174 scrambles the CRC using the C-RNTI, and the UE 102 verifies the scrambled CRC using the C-RNTI.

[0114] In other implementations, after UE 102 receives the CG configuration or RAN 105 configures the CG configuration to UE 102 (e.g., Figure 3 404 UL MAC PDU on CG resources. In some implementations, after generating or sending 404 UL MAC PDU, if CU-CP 172A or DU 174 configures UE 102 to apply UE timer during SDT, UE 102 starts UE timer (e.g., second UE CG-SDT timer). In some implementations, UE 102 uses UE timer value (e.g., cg-SDT-RetransmissionTimer value) to start UE timer. After sending 404 the UL MAC PDU, the UE 102 stops the UE timer when it receives the DCI and the CRC of the DCI on the PDCCH from the DU 174 and uses the C-RNTI to verify that the CRC is correct. In some implementations, the DU 174 uses the C-RNTI to scramble the CRC and the UE 102 uses the C-RNTI to verify the scrambled CRC.

[0115] In another implementation, the UE 102 receives 432, 434 an RRC release message including a UE timer value from the base station 104, similar to events 332, 334. The CU-CP 172A includes the UE timer value in the CG-SDT configuration and sends the RRC release message including the CG-SDT configuration to the UE 102 via the DU 174. In other implementations, the UE 102 receives the UE timer value in a system information block broadcast by the DU 174 via the cell 124. While the UE timer is running, the UE 102 in an inactive state or an SDT session avoids retransmitting the UL MAC PDU on the CG resources. In some implementations, in response to receiving 404 to the UL MAC PDU on the CG resources, or after receiving 404 to the UL MAC PDU on the CG resources, the 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, DU 174 processes the UL transmission received from UE 102 on the CG resources as a new transmission.

[0116] 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 other implementations, the UE 102 sends 418 the subsequent UL MAC PDU on radio resources configured in a dynamic 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 radio resources configured in the CG configuration and sends 418 the remaining subsequent UL MAC PDUs on radio resources configured in the dynamic uplink grant.

[0117] In some implementations in which the UE 102 sends 418 subsequent UL MAC PDUs on CG resources, the UE 102 starts or restarts a timer (e.g., a second UE CG-SDT timer) after generating or sending 418 each of the subsequent UL MAC PDUs. Depending on the implementation, the UE 102 starts or restarts the timer using the 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 receiving 418 each of the subsequent UL MAC PDUs on CG resources, or after receiving 418 each of the subsequent UL MAC PDUs on 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. In other implementations, the DU 174 processes 404, 418 the UL MAC PDU without starting a DU timer.

[0118] If the UE 102 includes the UL data in the initial UL MAC PDU 404, the DU 174 retrieves the UL data from the initial UL MAC PDU. 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 this alternative implementation, the UL data includes or is a PDCP PDU, an RRC PDU, a NAS PDU, or an LTE Positioning Protocol (LPP) PDU. Depending on the implementation, the PDCP PDU includes an RRC PDU. In another implementation, the DU 174 sends 416 UL data to the CU-UP 172B separately via a user plane (UP) connection, as described below. In some such implementations, the UL data includes or is a PDCP PDU, and the PDCP PDU includes an SDAP PDU, an IP packet, or an Ethernet packet.

[0119] After receiving 406 the first DU to CU message, in some implementations, the CU-CP 172A sends 408 a UE context setup request message to the DU 174 to establish a UE context for the UE 102 at the DU 174. In some implementations, the CU-CP 172A includes transport layer information of one or more GTP-U tunnels between the CU-UP 172B and the DU 174 in the UE context setup request message. Thus, the DU 174 can send UL data and / or subsequent UL data (e.g., in small data communications 418) to the CU-UP 172B via the one or more GTP-U tunnels. In response, the DU 174 sends 410 a UE context setup response message to the CU-CP 172A. After receiving 406 the first DU to CU message, sending 408 the UE context setup request message, or receiving 410 the UE context setup response message, CU-CP 172A sends 412 a bearer context modification request message to CU-UP 172B to resume data transmission of UE 102. In response, CU-UP 172B resumes data transmission of UE 102 and sends 414 a bearer context modification response message to CU-CP 172A. 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), after receiving 408 the UE context setup request message or sending 410 the UE context setup response message, DU 174 sends 415 a DU to CU message including UL data to CU-CP 172A. In some cases where the UL data is associated with a DRB, DU 174 sends 416 the UL data to CU-UP 172B. In some cases, such as when CU-CP 172A determines that DU 174 already has the UE context of UE 102, CU-CP 172A omits events 408 and 410, e.g., such as when, in the case of CG-SDT, CU-CP 172A commands DU 174 to retain the UE context of UE 102, as described above. In some such cases, CU-CP 172A sends a UE context modification request message to DU 174 to modify the UE context, instead of sending a UE context setup request message, and in response, DU 174 sends a UE context modification response message.

[0120] In some implementations, CU-CP 172A includes the transport layer information of CU-UP 172B in the UE context setup request message. The transport layer information of CU-UP 172B may include an IP address and / or an uplink tunnel endpoint ID (e.g., TEID). DU 174 uses the transport layer information of CU-UP 172B to send 416 UL data to CU-UP 172B. In some cases where UE 102 has subsequent UL data (e.g., one or more UL data packets) to send, UE 102 sends 418 one or more subsequent UL MAC PDUs including the subsequent UL data to DU 174. DU 174 then 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), DU 174 sends 416 one or more DU to CU messages (e.g., UL RRC messaging messages) including the subsequent UL data to 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 416 one or more CU to DU messages (e.g., DL RRC messaging messages) including DL data (e.g., one or more DL data packets) to the DU 174. In turn, the DU 174 sends 416 one or more DL MAC PDUs including DL data to the UE 102 operating in the inactive state. In some implementations, the DL data includes NAS PDUs and / or LPP PDUs.

[0121] In the case where 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. Depending on the implementation, 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 uses the transport layer information of DU 174 to send 418 DL data (e.g., one or more DL data packets) to DU 174. Subsequently, DU 174 sends 418 one or more DL MAC PDUs including DL data to UE 102 operating in an inactive state.

[0122] 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 according to the BSR configuration and / or the PHR configuration, respectively. In the buffer status report, the UE 102 includes or indicates the buffer status of one or more logical channels or logical channel groups. In the power headroom report, the UE 102 includes or indicates the power headroom status or value.

[0123] 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 PDUs (e.g., RRC PDUs, PDCP PDUs, or RLC PDUs), which include RRC messages, NAS messages, IP packets, Ethernet packets, or application packets.

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

[0125] In some implementations, the UL RRC message is an existing RRC recovery request message (e.g., an RRCResumeRequest message, an RRCResumeRequest1 message, an RRCConnection ResumeRequest message, or an 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 document (e.g., a future 3GPP standard document). The new RRC recovery request message may be in a format similar to the existing RRC recovery request message. In the case of 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.

[0126] In some implementations, after the UE 102 sends 404 a UL MAC PDU or communicates 418 subsequent UL data and / or DL ​​data with the DU 174, the CU-CP 172A determines to stop the SDT of the UE 102 based on data inactivity of the UE 102 (i.e., the UE 102 in the inactive state has no data activity with the base station 104). After the UE 102 sends 404 a UL MAC PDU or communicates 418 subsequent UL data and / or DL ​​data with the DU 174, the UE 102 in the inactive state determines or detects data inactivity and sends 420 UE assistance information (e.g., a UEAssistanceInformation message) to the DU 174 indicating that the UE 102 prefers or requests to stop the SDT.

[0127] Events 420, 421, 422, 423, 424, 426, 428, 430, 432, and 434 are Figure 4 492. In the embodiment of the present invention, the UE 102 performs 493 a small data transmission process with the base station 104, which is similar to the process 492. In another embodiment, after completing the process 493, the base station 104 performs 495 an SDT completion process with the UE 102, which is similar to the process 494. The examples and implementations of events 320, 321, 322, 323, 324, 326, 328, 330, 332, 334 are applicable to events 420, 421, 422, 423, 424, 426, 428, 430, 432, 434, respectively. Depending on the implementation, after stopping the SDT, the UE 102 performs 493 another small data transmission process with the base station 104, which is similar to the process 492. In another implementation, after completing the process 493, the base station 104 performs 495 an SDT completion process with the UE 102, which is similar to the process 494.

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

[0129] 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 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, and 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 P-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. The UE 102 then retrieves the paging message from the PDSCH transmission.

[0130] 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 with the second SDT CU configuration. In some implementations, the CU-CP 172A includes an indication in the RRC release message for indicating to the UE 102 that the first SDT CU configuration is updated with the second SDT CU configuration. In some such implementations, the UE 102 updates the first SDT CU configuration with the second SDT CU configuration in response to the indication.

[0131] In other implementations, CU-CP 172A includes a modification indication for indicating to UE 102 that the first SDT CU configuration is modified with the second SDT CU configuration in the RRC release message. In some such implementations, UE 102 modifies the first SDT CU configuration with the second SDT CU configuration in response to the modification indication. In still other implementations, CU-CP 172A includes a setup indication for indicating to UE 102 that the first SDT CU configuration is replaced with the second SDT CU configuration in the RRC release message. In some such implementations, UE 102 replaces the first SDT CU configuration with the second SDT CU configuration in response to the setup indication.

[0132] 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. In some implementations, the DU 174 includes in the second SDT DU configuration an indication to the UE 102 that the first SDT DU configuration is updated with the second SDT DU configuration. In some such implementations, the UE 102 updates the first SDT DU configuration with the second SDT DU configuration in response to the indication.

[0133] In other implementations, DU 174 includes in the second SDT DU configuration a modification indication for indicating to UE 102 that the first SDT DU configuration is modified with the second SDT DU configuration. In some such implementations, UE 102 modifies the first SDT DU configuration with the second SDT DU configuration in response to the modification indication. In still other implementations, DU 174 includes in the second SDT DU configuration a setup indication for indicating to UE 102 that the first SDT DU configuration is replaced with the second SDT DU configuration. In some such implementations, UE 102 replaces the first SDT DU configuration with the second SDT DU configuration in response to the setup indication.

[0134] 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. In some such implementations, the DU 174 retains the first SDT DU configuration unless the conditions for releasing the first SDT configuration are met. Alternatively, the CU-CP 172A 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 SDT CU 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 102 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 the case where CU-CP 172A includes the release indication in the RRC release message, UE 102 releases the first SDT CU configuration and / or the first SDTDU configuration in response to the release indication. In some cases where CU-CP 172A and / or DU 174 do not support incremental configuration, CU-CP 172A includes the SDT DU configuration and / or SDT CU configuration in the RRC release message, as described above.

[0135] In some implementations, in response to the third CU-to-DU message, DU 174 retains the second SDT DU configuration and releases the first non-SDT DU configuration and / or the second non-SDT DU configuration. 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 response to the third CU-to-DU message. In some implementations, if the RRC release message instructs UE 102 to transition to an idle state (i.e., RRC_IDLE), UE 102 releases the non-SDT configuration (e.g., for 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 described herein) and at least one SDT configuration (e.g., for Figure 3 SDT DU configuration and SDTCU configuration described in ).

[0136] 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 separately and includes the SDT DU configuration in the RRC release message.

[0137] In some implementations, DU 174 does not include the SDT DU configuration in the second DU to CU message, similar to the above description of Figure 3 In addition, DU 174 does not include the configuration for CG-SDT in the SDT DU configuration in the second DU to CU message, also similar to the above description of Figure 3 Describe the process.

[0138] In some implementations where 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. Depending on the implementation, CU-CP 172A receives UE capabilities (e.g., UE-EUTRA-Capability IE, UE-NR-Capability IE, or UE-6G-Capability IE) of UE 102 from UE 102, CN 110 (e.g., MME 114 or AMF 164), or base station 106. Depending on the implementation, before the UE 102 initiates the SDT, when the UE 102 is operating in the inactive state 402, when the UE 102 performs the SDT (e.g., in the UE context setup request message of event 408 or the CU to DU message of event 428), or when the UE 102 is performing the SDT as directed to the UE 102. Figure 3 When operating in a connected state as described, CU-CP 172A receives UE capabilities. The UE capabilities indicate whether UE 102 supports CG-SDT. Therefore, CU-CP 172A can determine whether UE 102 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 as defined in 3GPP specification 38.473).

[0139] In some implementations, DU 174 determines whether to provide SDT DU configuration for UE 102 to CU-CP 172A depending on whether UE 102 or DU 174 supports CG-SDT, similar to the above. Figure 3 In addition, DU 174 may determine and signal UE 102 whether CG-SDT is supported, similar to the above Figure 3 .

[0140] Reference now Figure 5A , scenario 500A depicts a small data transfer, similar to Figure 4 .However, Figure 5A Also depicted is a process of transitioning from an inactive state with SDT to a connected state with non-SDT (e.g., based on a UE context request and an RRC recovery message). 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.

[0141] During the small data communication process 592, the CU-CP 172A may determine whether to transition the UE 102 to a connected state (e.g., based on the UL or DL ​​data activity of the UE 102). 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 a connected state. In some implementations, the UE 102 sends 503 a non-SDT indication message to the DU 174 on 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 radio resources configured in the uplink grant. Subsequently, the DU 174 sends 505 a UL RRC messaging message including a non-SDT indication message to the CU-CP 172A. CU-CP 172A may determine 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 DL data notification (e.g., DL data notification message) to CU-CP 172A to indicate that DL data is available for transmission. 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.

[0142] 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 IIP 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 can determine whether to transition UE 102 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 determines to transition UE 102 to a connected state. Otherwise, CU-CP 172A determines not to transition UE 102 to a connected state. In some implementations, UE 102 includes data volume information of UL data in a non-SDT indication message. Therefore, the CU-CP 172A may determine whether to transition the UE 102 to the connected state based on the data amount information.

[0143] In some implementations, the data volume information includes the total data volume of the UL data, which can be quantized or rounded to a value indicated in the data volume information. In other implementations, the data volume information includes the data volume of each of the radio bearers, which is quantized or rounded to a value that can be indicated in the data volume information. For example, if the total data volume is higher than a predetermined threshold, the CU-CP 172A determines to transition the UE 102 to a connected state. Otherwise, the CU-CP 172A determines not to transition the UE 102 to a connected state. In another example, if the data volume of a particular radio bearer is higher than a predetermined threshold, the CU-CP 172A determines to transition the UE 102 to a connected state. Otherwise, the CU-CP 172A determines not to transition the UE 102 to a connected state. In yet another example, if the total data volume is higher than a predetermined threshold and the data volume of a particular radio bearer is higher than another predetermined threshold, the CU-CP 172A determines to transition the UE 102 to a connected state. Otherwise, CU-CP 172A determines not to transition UE 102 to the connected state.

[0144] In response to determining to transition UE 102 to a connected state, 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. The PDU may be 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 implementations including a 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 may be a UL RRC messaging message, a UE context modification required message, or a UE context modification response message.

[0145] After determining to transition UE 102 to the connected state, CU-CP 172A may send 554 a bearer context request message (e.g., a bearer context setup request message or a bearer context modification request message) to CU-UP 172B to instruct CU-UP 172B to resume the radio bearers (e.g., SDT DRBs and / or non-SDT DRBs) of UE 102 (if suspended). In response, CU-UP 172B resumes the radio bearers of 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 CU CP-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).

[0146] 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 no radio bearers of the UE 102 are 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.

[0147] In some implementations, CU-CP 172A includes an indication to DU 174 for generating 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. UE 102 may also store a 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 augments 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 similar to 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.

[0148] 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 DU 174. Depending on the implementation, the UL data includes UL data that triggers the UE to send a non-SDT indication message. In another implementation, the UL data also includes new UL data that can be used for transmission. In some implementations, the UL data includes or is a PDCP PDU, an RRC PDU, a NAS PDU, or an LTE Positioning Protocol (LPP) 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 check) to the UL data, as described above. The UL data includes or is a PDCP PDU, an SDAPPDU, 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-SDTDRB). In other 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.

[0149] In some implementations, the DL data includes DL data received from CN 110 as described above. In another implementation, the DL data also includes new DL data received by CU-CP 172A and / or CU-UP 172B from CN 110. The DL data may be or include DL 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 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 NAS PDU, CU-CP 172A receives NAS PDU from CN 110 (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., UPF 162) 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. The UE 102 similarly applies one or more security functions (eg, decryption and / or integrity protection checking) to the DL data packets, as described above.

[0150] In the case where the RRC resume message includes the first non-SDT DU configuration, the UE 102 uses the first non-SDT DU configuration to communicate 518 with the DU 174. 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.

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

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

[0153] In other implementations, in response to receiving an RRC recovery message or transitioning to a connected state, or after receiving an RRC recovery message or transitioning to a connected state, 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., communicating 550RRC recovery complete messages and / or communicating 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., communicating 550RRC recovery complete messages and / or communicating 518 data). In some implementations, in response to transitioning the UE 102 to a connected state or sending an RRC recovery message, or after transitioning the UE 102 to a connected state or sending an RRC recovery message, 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 the connected state (e.g., communicating 550 RRC recovery complete messages and / or communicating 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., communicating 550 RRC recovery complete messages and / or communicating 518 data).

[0154] In some implementations, in response to transitioning UE 102 to a connected state or sending an RRC resume message, 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., suspendConfi g), except for RAN notification area information (e.g., ran-NotificationAreaInfo). UE 102 may receive a suspension configuration in an RRC release message from base station 104 before performing the 592 process, similar to event 334 or 434.

[0155] In some implementations, the non-SDT indication message is 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 another implementation, the UE 102 sends a UL MAC PDU including a non-SDT indication message to the CU-CP 172A via DU 174. In some implementations, in addition to the non-SDT indication message, the UE 102 may also include data in the UL MAC PDU. In other implementations, the UE 102 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 some such implementations, in response to determining to send a non-SDT indication message, the UE 102 avoids rebuilding the UE PDCP entity for SRB1.

[0156] 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 DU174. 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 for 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 DU 174 and SRB1. The UE 102 generates a UL PDCP PDU including an RRC recovery complete message using the UE PDCP entity, and sends 550, 552 the UL PDCP PDU to the CU-CP 172A via the DU 174 and SRB1. The CU-CP 172A receives 550, 552 the UL PDCP PDU from the UE 102 via the DU 174 using the CU-CP PDCP entity. In some such implementations, the UE 102 and the CU-CP 172A communicate the PDCP PDU via SRB1 without reestablishing the UE PDCP entity and / or the CU-CP PDCP entity.

[0157] In other implementations, the non-SDT indication message may be an RRC recovery request message (e.g., an RRCResumeRequest message or an RRCResumeConnectionRequest message). In such implementations, the UE 102 may stop 592 small data communication with the base station 104 to send the non-SDT indication message. In some implementations, the UE 102 sends a non-SDT indication message to the CU-CP 172A via the DU 174 and SRB0. In another implementation, 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 uses the UE PDCP entity to receive 546 DL PDCP PDUs from the DU 174. Similarly, the CU-CP 172A reestablishes the CU-CP PDCP entity after receiving the non-SDT indication message. After reestablishing the CU-CP PDCP entity, the CU-CP 172A generates DL PDCP PDUs using the CU-CP PDCP entity, and sends 545, 546 DL PDCP PDUs to the UE 102 via DU 174 and SRB1. After reestablishing the UE PDCP entity, the UE 102 generates UL PDCP PDUs including an RRC recovery complete message using the UE PDCP entity, and sends 550, 552 UL PDCP PDUs to the CU-CP 172A via DU 174 and SRB1. After reestablishing 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.

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

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

[0160] In some implementations, the UE 102 in the inactive state runs a second UE CG-SDT timer during the small data communication process 592, 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 after receiving 546 to the RRC recovery message or transitioning 548 to the connected state, 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 after receiving 546 to the RRC recovery message or transitioning 548 to the connected state, the UE 102 maintains the second UE CG-SDT timer. 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 the RRC setup message, or after receiving the RRC setup message, UE 102 stops the second UE CG-SDT timer and sends an RRC setup complete message to CU-CP 172A via DU 174.

[0161] Similarly, depending on the implementation, DU 174 runs a second DU CG-SDT timer during the small data communication process 592. In some implementations, DU 174 starts or restarts the second DU CG-SDT timer when a PUSCH transmission is received from UE 102 on the radio resources configured in the CG-SDT configuration, 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 the case where the second DU CG-SDT timer is running, in response to receiving 508 a UE context request message, sending 510 a UE context response message, or sending 546 an RRC recovery message, or after receiving 508 a UE context request message, sending 510 a UE context response message, or sending 546 an RRC recovery message, DU 174 stops the second DU CG-SDT timer. In other implementations, in response to receiving 508 a UE context request message, sending 510 a UE context response message, or sending 546 an RRC resume message, or after receiving 508 a UE context request message, sending 510 a UE context response message, or sending 546 an RRC resume message, the DU 174 maintains a second DU CG-SDT timer. Regardless of the second DU CG-SDT timer (e.g., running, expired, or stopped), the DU 174 uses the C-RNTI to send DCI on the PDCCH and / or PDCCH to the UE 102 operating in the connected state.

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

[0163] At a later time, the base station 104 may perform 590 a non-SDT configuration procedure and perform 594 an SDT configuration procedure with the UE 102, 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. After transitioning to the inactive state, the UE 102 in the inactive state may perform 593 a small data communication procedure and perform 595 an SDT completion procedure with the base station 104, similar to the procedures 492 and 494, respectively.

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

[0165] 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 transition the UE 102 to the connected state. In response to determining to transition the UE 102 to the connected state, or after determining to transition the UE 102 to the connected state, the CU-CP 172A transitions the UE to the connected state, as described for scenario 500A.

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

[0167] 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, keeps the RNAU timer running, and initiates an RRC recovery procedure in response to expiration of the RNAU timer.

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

[0169] Next reference Fig. 6A , scenario 600A depicts an RRC release message in response to an RRC resume request. In particular, Figures 3 to 5B 1. In contrast, scenario 600A depicts a request for resume operation at base station 106, which retrieves a UE context from base station 104. In 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 prior to operating in the inactive state 602, and transitions to inactive state 602 at a later time, such as for Figure 3 In other implementations, the UE 102 operates in an inactive state and performs a small data transmission with the base station 104, stops the small data transmission with the base station 104 and remains in the inactive state 602, as described for Figure 4 In some such implementations, the base station 104 configures the UE 102 with SDT configuration parameters (e.g., SDT CU configuration and / or SDT DU configuration), such as for Figure 3 or Figure 4 "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).

[0170] At a later time, 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 a RAN notification area (RNA) update because the base station 106 belongs to another RNA that is different from the RNA of another cell. The other cell is the cell in which the UE 102 receives an RRC release message that configures the UE 102 to transition to the inactive state 602. In other implementations, the UE 102 performs an 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-II. In some implementations, the RRC MAC-II is a resumeMAC-I field, and the UE 102 obtains the resumeMAC-I (e.g., as specified 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-II (e.g., resumeMAC-I field) from an RRC resume request. In some implementations, the UE 102 sets the bits of COUNT, BEARER, and DIRECTION to binary bits to generate the RRCMAC-I.

[0171] 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 UEIID. 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 IIP packet to base station 104. The base station 104 generates a second IIP packet, which includes a source address (i.e., the first IIP address or another IIP 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.

[0172] 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 in the retrieve UE context response message.

[0173] 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 in 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 other implementations, such as when the CU-CP 172A does not support incremental configuration, the CU-CP 172A discards the SDT configuration. In other implementations, the base station 104 avoids including the SDT configuration in the retrieve UE context response message.

[0174] Depending on the implementation, after receiving 609 the retrieve UE context response message, CU-CP 172A sends 612 a bearer context setup request message to CU-UP 172B to request CU-UP 172B to establish a bearer context for the SDT DRB configured in the SDT configuration of UE 102. In response, CU-UP 172B establishes (i.e., sets up) 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 is established. In some implementations where there are non-SDT DRBs for UE 102, CU-CP 172A requests CU-UP 172B in the bearer context setup request message 612 to establish a bearer context for the non-SDT DRB. 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.

[0175] Depending on the implementation, after receiving 609 the retrieve UE context response message or receiving 614 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 a UE context for the UE 102. In response, the DU 174 establishes the UE context for 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 IIP address and / or downlink TEID associated with the SDT DRB and / or the 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.

[0176] Depending on the implementation, 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.

[0177] In some implementations, CU-CP 172A includes a suspension indication (e.g., a bearer context state change IE with a "Suspend" value) in a bearer context setup request message to indicate to CU-UP 172B to suspend one or more bearer contexts. Alternatively, CU-CP 172A includes the suspension indication in a bearer context modification request message instead of including the suspension indication in the bearer context setup request message. In response to the suspension 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.

[0178] Depending on the implementation, after receiving 609 the retrieve UE context response message, receiving 610 the UE context setup response message, receiving 614 the bearer context setup response message, or receiving 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 a retrieve UE context response message, receiving 610 a UE context setup response message, receiving 614 a bearer context setup response message, receiving 626 a bearer context modification response message, or receiving 630 a DU to CU message, CU-CP 172A sends 632, 634 an RRC release message to UE 102 via DU 174, similar to events 332, 334, 432, and 434. UE 102 determines that the RRC recovery procedure is successfully completed after receiving 634 the RRC release message and remains in an inactive state.

[0179] Depending on the implementation, 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 occur during the small data communication procedure 692.

[0180] In some scenarios or implementations, CU-UP 172B receives a DL data packet for UE 102 from CN (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. 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 response to receiving the UP to CP message, 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 a paging message to the UE 102.

[0181] In some scenarios or implementations, CU-UP 172B receives a DL data packet for UE 102 from CN (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 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 non-SDT DRB has data. 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 response to receiving the UP to CP message, 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 a paging message to the UE 102.

[0182] Next reference Figure 6B, scenario 600B depicts a small data transmission, similar to scenarios 400 and 600A, but in which DU 174 communicates uplink data received from UE 102 to CU 172. Events 602, 604, 606, 608, 610, 612, 614, 615, 616, 618, 695, and 636 are similar to events 402, 404, 406, 408, 410, 412, 414, 415, 416, 418, 494, and 436, respectively. Figure 4 and Fig. 6A Examples and implementations can be applied to Figure 6B The following describes Figure 4 , Fig. 6A and Figure 6B The difference between.

[0183] In scenario 600B, UE 102 initially operates 602 in an inactive state and is configured with an SDT configuration. In some implementations, UE 102 receives an SDT configuration, such as for Figure 3 , Figure 4 , Figure 5A and / or Figure 5B As 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 receiving 606 the to UL RRC message, or after receiving 606 the to 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.

[0184] In some cases where the UE 102 includes UL data in the initial UL MAC PDU 604, the DU 174 sends 615 a DU-to-CU message including the UL data to the CU-CP 172A or sends 616 the UL data, similar to events 415 or 416, respectively.

[0185] Depending on the implementation, 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 some such 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 performing 694 the SDT completion procedure, or after performing 694 the SDT completion procedure, the UE 102 remains 636 in the inactive state.

[0186] 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 to indicate to the CU-UP 172B to suspend 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 to suspend the non-SDT DRB to the CU-UP 172B. 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 .

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

[0188] Depending on the 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 DRBs associated with the UL data are 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 (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, CU-UP 172B sends a UP to CP message (e.g., a DL data notification message) to CU-CP 172A to notify CU-CP 172A of the arrival of the DL data packet of the non-SDT DRB. In some implementations, the CU-UP includes the PDU session IID and / or QoS flow IID associated with the non-SDT DRB in the UP to CP message.

[0189] Next reference Figure 6C , scenario 600C depicts a small data transfer, similar to scenarios 500B and 600A in that UE 102 enters a connected state (e.g., event 648) and performs as described with respect to Fig. 6A UE context retrieval process described (e.g., events 607 / 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 6C and Figure 5A , Figure 5B and Fig. 6A The difference between.

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

[0191] Depending on the implementation, after establishing the bearer context for the DRB of UE 102 (e.g., 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 CU-UP 172B does not suspend DRBs associated with UL data. The UL data packet can be a PDCP PDU, an SDAPPDU, an IIP 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, the CU-UP 172B receives DL data packets for the UE 102 from the CN (e.g., UPF 162) or edge server. The DL data packets may be IIP 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 check) to the DL data packets, as described above.

[0192] Reference now Fig. 7A , scene 700A depicts a switching scene after entering the connected state, similar to Figure 5A and / or Figure 5B. 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. At a later time, base station 104 determines to handover 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.

[0193] In response to the handover determination, the base station 104 sends 702 a handover request message to the base station 106 to prepare the UE 102 for the handover. 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.

[0194] In the case where the base station 106 is a distributed base station, the base station 106 includes a CU and a DU ( Fig. 7A). In some such implementations, the CU and the DU perform 709 a UE context setup process 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 the inter-node message in the UE context setup request message. In another implementation, the DU includes the second non-SDT DU configuration in the UE context setup response message. In yet another implementation, the DU generates a second non-SDT DU configuration that expands (e.g., replaces or modifies) the first non-SDT DU configuration. In yet another implementation, 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 the UE context setup request message or the 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.

[0195] 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 the configuration parameters in the second non-SDT DU configuration in response to the first inter-node message for the UE 102 to switch to the base station 106. 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.

[0196] 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 causes problems. In order to prevent the problem, in some implementations, the CU may remove the first SDT configuration from the first inter-node message, and then include 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), which includes the first non-SDT configuration but 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.

[0197] In response to the handover request message, the base station 106 sends 704 a handover request confirmation message including an RRC reconfiguration message to the base station 104 for handing over the UE 102 to the base station 106. 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 generates a second SDT DU configuration that extends the first 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.

[0198] 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 may perform 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, 636. In some implementations, after transitioning 736 to the inactive state, the UE 102 performs 792 a small data communication procedure with the base station 106, similar to procedures 492, 592, 692. In other implementations, after performing 792 the small data communication procedure, the base station 106 performs 795 an SDT completion procedure with the UE 102, similar to procedures 394, 494, 594, and 694.

[0199] 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 full configuration indication in the RRC reconfiguration message so as to configure the UE 102 to release the SDT configuration. The UE 102 releases the SDT configuration in response to the full configuration indication after receiving the RRC reconfiguration message. Otherwise, if the base station 106 supports SDT, the base station 106 avoids including the full configuration indication in the RRC reconfiguration message. When the UE 102 receives the RRC reconfiguration message excluding the full configuration indication, the UE 102 retains the SDT configuration in response to the RRC reconfiguration message.

[0200] Next reference Figure 7B, scenario 700B is generally similar to scenario 700A, except that the base station 104 prepares the handover of the UE 102 with the base station 106 through the CN 110, rather than performing and / or preparing the handover directly with the base station 106 through the BS-to-BS interface. In response to the handover determination, the base station 104 sends 701 a handover required message including an SDT configuration and a non-SDT configuration to the CN 110. In response to receiving 701 the handover required message, or after receiving 701 the handover required message, the CN 110 sends 703 a handover request message including an SDT configuration and a non-SDT configuration to the base station 106. In some implementations, the 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, the CN 110 retrieves the inter-node message from the handover required message and includes the inter-node message in the handover request message.

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

[0202] Reference now Figure 8, scenario 800 depicts a scenario similar to scenario 600A, but in which the UE returns to a connected state and performs an RRC connection reestablishment process. 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. While UE 102 is operating 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 UEIID (e.g., C-RNTI) of UE 102 and a physical cell IID. In some implementations, the RRC resume request message includes an RRC MAC-II. In some implementations, the RRC MAC-II is a shortMAC-I field. Depending on the implementation, the UE 102 obtains a shortMAC-I, which is similar to the resumeMAC-I, as described above with respect to obtaining a resumeMAC-I.

[0203] After receiving the RRC reestablishment message, events 807, 808, 809, 810, 812, 814, 824, and / or 826 occur similarly to events 607, 608, 609, 610, 612, 614, 624, and / or 626, respectively. Therefore, the implementation described with respect to such events is similarly applicable to events 807, 808, 809, 810, 812, 814, 824, and / or 826 performed after receiving the RRC reestablishment request message.

[0204] Depending on the implementation, 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 RRC Reestablishment message or an RRC Connection Reestablishment message) to the DU 174. Subsequently, the DU 174 sends 846 an 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 RRC Reestablishment Complete message or an RRC Connection Reestablishment Complete message) to the DU 174. Then, the DU 174 sends 852 a DU to CU message including an RRC reestablishment complete message to the CU-CP 172A. In some implementations, the CU-CP 172A may send 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.

[0205] Depending on the implementation, 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.

[0206] In some implementations, CU-CP 172A avoids including a suspension indication (e.g., a bearer context state change IE with a value of “Suspend”) in the bearer context setup request message 812. In other implementations, CU-CP 172A includes a suspension indication (e.g., a bearer context state change IE with a value of “Suspend”) 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 for the DRB, similar to events 824 and 846.

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

[0208] Next reference Fig. 9 , scenario 900 depicts an RRC connection reestablishment process, similar to scenario 800, but in which CU 172 performs a UE context release process (e.g., events 937 and 939). Initially, UE 102 may operate 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 executes a UE context release command message to DU 174A to release the UE context of UE 102. In response, DU 174A 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.

[0209] Next, refer to Figures 3 to 9 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.

[0210] Fig. 10A A method 1000A implemented by a CU (eg, the CU 172 or CU-CP 172A of the base station 104 or 106 ) for handling SDT configuration for a UE (eg, the UE 102 ) is shown.

[0211] Method 1000A starts at block 1002, where the CU receives a first SDT DU configuration for a UE from a RAN node (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 609, 702, 703, 809). At block 1004, the CU sends a CU-to-DU message including the first SDT DU configuration to the first DU (see, e.g., events 328, 394, 428, 494, 495, 594, 595, 608, 628, 694, 695, 709, 794, 795, 808, 894, 895, 994, 995). At block 1006, the CU receives a DU-to-CU message that does not include an SDT DU configuration from the first DU (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 610, 630, 694, 695, 709, 794, 795, 810, 894, 895, 994, 995). At block 1008, the CU sends a first RRC release message to the UE via the first DU to configure the UE to continue to apply the first SDT DU configuration (see, e.g., events 332, 334, 394, 432, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). Blocks 1004, 1006, and 1008 may be grouped into block 1050.

[0212] In some implementations, the RAN node is a base station (e.g., base station 104) or a CU (e.g., CU 172 or CU-CP 172A of base station 106 or 104). In other implementations, the RAN node may be a first DU or a second DU connected to the CU.

[0213] In some implementations, the CU sends a second RRC release message including the first SDT DU configuration to the UE via the first DU or the second DU. In the case where the CU receives the first SDT DU configuration from the first DU, the CU sends the second RRC release message to the UE via the first DU. In the case where the CU receives the first SDT DU configuration from the second DU, the CU sends the second RRC release message to the UE via the second DU.

[0214] In some implementations, the CU excludes the SDT DU configuration from the first RRC release message. In other implementations, the CU includes the first SDT DU configuration in the first RRC release message.

[0215] In some implementations, the DU to CU message does not include an indication that the UE is not configured with an SDT DU configuration or that the first SDT DU configuration is released. In response to the DU to CU message omitting the indication, the CU configures the UE to apply the first SDT DU configuration, as described at block 1008.

[0216] Fig. 10B is a flow chart of an example method 1000B that is similar to method 1000A, except that method 1000B includes blocks 1007 and 1009 instead of blocks 1006 and 1008. At block 1007, the CU receives a DU-to-CU message including a second SDT DU configuration from the first DU (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 610, 630, 694, 695, 709, 794, 795, 810, 894, 895, 994, 995). At block 1009, the CU sends a first RRC release message including a second SDT DU configuration to the UE via the first DU to configure the UE to expand (e.g., replace or modify) the first SDT DU configuration (see, e.g., events 332, 334, 394, 432, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). Blocks 1004, 1007, and 1009 may be grouped into block 1051.

[0217] In some implementations, the CU generates an SDT configuration (eg, SDT-Config IE) including an SDT DU configuration, and includes the SDT configuration in the first RRC release message.

[0218] In some implementations, the DU to CU message includes a replacement indication or a full configuration indication, and the full configuration indication indicates that the second SDT DU configuration is a full configuration (i.e., a complete and independent configuration). In response to the replacement indication or the full configuration indication, the CU includes the SDT configuration or the SDT DU configuration and the first indication that the second SDT DU configuration is a full configuration in the first RRC release message. In response to the first indication, the UE discards the first SDT DU configuration or replaces the first SDT DU configuration with the second SDT DU configuration. In some implementations, the first indication is a "set" field or indication. In other implementations, the first indication is a full configuration indication.

[0219] In some implementations, if the DU to CU message excludes a replacement indication or a full configuration indication, the CU avoids including the first indication in the first RRC release message, the SDT configuration, or the second SDT DU configuration to indicate that the second SDT DU configuration is an incremental configuration. Therefore, the UE updates the first SDT DU configuration using the second SDT DU configuration in response to the first RRC release message, the SDT configuration, or the second SDT DU configuration excluding the first indication.

[0220] In some implementations, if the DU to CU message includes an incremental indication or a modification indication, the CU avoids including the first indication in the first RRC release message, the SDT configuration, or the second SDT DU configuration to indicate that the second SDT DU configuration is an incremental configuration. Therefore, the UE updates the first SDT DU configuration using the second SDT DU configuration in response to the first RRC release message, the SDT configuration, or the second SDT DU configuration excluding the first indication.

[0221] In some implementations, if the DU-to-CU message includes an incremental indication or a modification indication that the second SDT DU configuration is an incremental configuration that expands the first SDT DU configuration, the CU avoids including the first indication in the first RRC release message, the SDT configuration, or the second SDT DU configuration to indicate that the second SDT DU configuration is an incremental configuration. Therefore, the UE updates the first SDT DU configuration using the second SDT DU configuration in response to the first RRC release message, the SDT configuration, or the second SDT DU configuration excluding the first indication.

[0222] In some implementations, if the DU to CU message includes an incremental indication or a modification indication that the second SDT DU configuration is an incremental configuration that expands the first SDT DU configuration, the CU includes a second indication indicating that the second SDT DU configuration is an incremental configuration in the first RRC release message, the SDT configuration, or the second SDT DU configuration. Therefore, the UE updates the first SDT DU configuration using the second SDT DU configuration in response to the second indication. In some implementations, the second indication is a "modify" or "modify" field or indication. In other implementations, the second indication is a "set" field or indication.

[0223] In some implementations, the CU includes a full configuration indication in the CU to DU message. In response to the full configuration indication, the DU generates the second SDT DU configuration as a full configuration, as described above. In other implementations, the CU avoids including the full configuration indication in the CU to DU message. In such a case, the DU determines to generate the second SDT DU configuration as a full configuration.

[0224] Fig. 10C1004, 1006, and 1010 may be grouped into block 1052.

[0225] In some implementations, the DU to CU message of block 1006 includes an indication that the UE is not configured with an SDT DU configuration or that the first SDT DU configuration is released. In response to the indication, the CU determines to include a release indication in the first RRC release message, as described at block 1010.

[0226] Fig. 10D 1000A, 1000B, and 1000C, except that method 1000D includes blocks 1005 and 1012. At block 1005, the CU receives a DU-to-CU message from a first DU. At block 1012, the CU determines whether the DU-to-CU message includes a second SDT DU configuration. If the CU determines that the DU-to-CU message includes the second SDT DU configuration, the process proceeds to block 1009. Otherwise, if the first CU determines that the DU-to-CU message does not include the second SDT DU configuration, the process proceeds to block 1014. At block 1014, the CU performs blocks 1008 or 1010 as described above. By performing the check at block 1012, the CU can efficiently utilize resources by updating some portions of the SDT configuration while allowing the UE to retain continuing relevant portions of the SDT configuration.

[0227] Fig.10E1000E is a flow chart of an example method 1000E similar to method 1000A, except that method 1000E includes blocks 1003, 1011, and 1016 instead of blocks 1004 and 1008. At block 1003, the CU ignores or discards the first SDT DU configuration. At block 1016, the CU sends a CU-to-DU message to the first DU to obtain the SDT DU configuration (see, e.g., events 328, 394, 428, 494, 495, 594, 595, 608, 709). At block 1011, the CU sends a first RRC release message including a second SDT DU configuration to the UE via the first DU (see, e.g., events 332, 334, 394, 432, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). Blocks 1003, 1016, 1006, and 1011 may be grouped into block 1053. By executing blocks 1011 and 1016, the CU queries the DU to attempt to receive the second SDT DU configuration, and updates the UE with a separate SDT DU configuration when such second SDT DU configuration is not received.

[0228] In some implementations, the CU determines to ignore or discard the first SDT DU configuration because the CU does not support incremental configuration. In other implementations, the CU is configured to ignore or discard the first SDT DU configuration because the CU and the RAN node have different software. In other implementations, the CU determines to ignore or discard the first SDT DU configuration because different vendors implement the CU and the RAN node.

[0229] In case the RAN node is a base station or a CU, the second SDT DU configuration is a full configuration.

[0230] Fig.10F is a flow chart of an example method 1000F that is substantially similar to methods 1000C and 1000E, except that the RAN node sends a release message (eg, Fig. 10C 1010) before discarding the first SDT DU configuration (eg, Fig.10E By executing blocks 1003 and 1010, the CU may efficiently cause the UE to release an SDT DU configuration that the CU determines should be ignored (e.g., incorrect, irrelevant, or otherwise useless for communication).

[0231] Fig.11 A method 1100 implemented by a CU (eg, the CU 172 or CU-CP 172A of the base station 104 or 106 ) for handling SDT configuration for a UE (eg, the UE 102 ) is shown.

[0232] The method 1100 begins at block 1102, where the CU receives a first SDT configuration for the UE from a RAN node (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 609, 702, 703, 809). In some implementations, at block 1102, the CU receives an inter-node message (e.g., a HandoverPreparationInformation message) from the RAN node that includes the first SDT configuration. In such implementations, the CU retrieves the first SDT configuration from the inter-node message and includes the first SDT configuration in a CU-to-DU message.

[0233] At block 1104, the CU determines to send a CU-to-DU message to the first DU to obtain an SDT DU configuration for the UE. At block 1106, the CU determines whether the first SDT configuration includes the first SDT DU configuration. If the CU determines that the first SDT configuration includes the first SDT DU configuration, the flow proceeds to block 1108. At block 1108, the CU includes the first SDT DU configuration in the CU-to-DU message. Otherwise, if the CU determines that the first SDT configuration does not include the first SDT DU configuration, the flow proceeds to block 1110. At block 1110, the CU sends a CU-to-DU message to the first DU (see, e.g., events 328, 394, 428, 494, 495, 594, 595, 608, 694, 695, 794, 795, 894, 895, 994, 995). The flow proceeds from block 1108 and from block 1106 to block 1110.

[0234] In some implementations, the RAN node is a base station (e.g., base station 104) or a CU (e.g., CU 172 or CU-CP 172A of base station 106 or 104). In other implementations, the RAN node is a first DU or a second DU connected to the CU.

[0235] In some implementations, the CU receives a DU-to-CU message from the first DU in response to a CU-to-DU message (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 610, 694, 695, 794, 795, 894, 895, 994, 995). The DU-to-CU message is similar to FIG. 10A to FIG. 10F DU to CU message. FIG. 10A to FIG. 10F The examples and implementations described can be applied to Fig.11 .

[0236] Fig. 12A A method 1200A implemented by a DU (eg, DU 174 of base station 104 or 106) for handling SDT configuration for a UE (eg, UE 102) is shown.

[0237] Method 1200A begins at block 1202, where the DU obtains a first SDT DU configuration for the UE. At block 1204, the DU receives a CU-to-DU message from the CU requesting an SDT DU configuration for the UE (see, e.g., events 328, 394, 428, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). For example, the CU may be a CU 172 or a CU-CP 172A of a base station 104 or 106. At block 1206, the DU may reserve resources for the UE according to the first SDT DU configuration. After block 1206, the process proceeds to block 1208 or block 1210. At block 1208, the DU sends a DU-to-CU message including the first SDT DU configuration to the CU (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). At block 1210, the DU sends a DU-to-CU message excluding the first SDT DU configuration to the CU (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). Blocks 1206, 1208, and 1210 may be grouped into block 1250.

[0238] In some implementations, the CU-to-DU message includes a first SDT DU configuration, and the DU obtains the first SDT DU configuration from the CU-to-DU message. In other implementations, the DU generates the first SDT DU configuration before receiving the CU-to-DU message and sends the first SDT DU configuration to the UE via the DU (e.g., events 330, 332, 334, 430, 432, 434, 394, 494, 495, 594, 595). In the case where the DU generates the first SDT DU configuration, the DU continues to reserve resources for the UE according to the first SDT DU configuration.

[0239] In some implementations, the resources include radio resources (i.e., time and / or frequency resources) configured in the SDT DU configuration. For example, the radio resources include CG radio resources for CG-SDT. In another example, the radio resources include sounding reference signal (SRS) radio resources for transmission (e.g., for positioning) by an inactive UE.

[0240] In some implementations, at block 1210, the DU includes in the DU to CU message an indication that the DU accepts the first SDT DU configuration. In other implementations, at block 1208, the DU excludes in the DU to CU message an indication that the DU refuses to configure the SDT DU configuration for the UE.

[0241] In some implementations, the DU receives a UE context release command message from the CU after sending the DU to CU message. In some implementations, the UE context release command message includes an SDT indicator (e.g., a CG-SDT hold indicator) indicating to the DU that resources and / or configurations for SDT are reserved. The configuration includes a first SDT DU configuration. In another implementation, the configuration includes a C-RNTI.

[0242] Fig. 12B 1200B is a flow chart of an example method 1200B similar to method 1200A, except that method 1200B includes blocks 1205, 1207, and 1209 instead of blocks 1206, 1208, and 1210. At block 1205, the DU generates a second SDT DU configuration to augment (e.g., update or replace) the first SDT DU configuration. At block 1207, the DU may reserve resources for the UE according to the second SDT DU configuration. At block 1209, the DU sends a DU-to-CU message including the second SDT DU configuration to the CU (see, e.g., events 330, 394, 430, 494, 495, 594, 595). Blocks 1205, 1207, and 1209 may be grouped into block 1251.

[0243] In the case where the second SDT DU configuration reconfigures the resources configured in the first SDT DU configuration, the DU reserves resources for the UE according to the second SDT DU configuration. In the case where the second SDT DU configuration does not change the resources configured in the first SDT DU configuration, the DU continues to reserve resources according to the first SDT DU configuration.

[0244] In the case where the DU determines to generate a second SDT DU configuration to replace the first SDT configuration, the DU includes a replacement indication or a full configuration indication that the second SDT DU configuration is a full configuration (i.e., a complete and independent configuration) in the DU to CU message. In the case where the DU determines to generate a second SDT DU configuration to update the first SDT configuration, the DU excludes the replacement indication or the full configuration indication or includes a modification indication in the DU to CU message to indicate that the second SDT DU configuration is an incremental configuration.

[0245] In some implementations, the DU receives a UE context release command message from the CU after sending the DU to CU message. In some implementations, the UE context release command message includes an SDT indicator (e.g., a CG-SDT retention indicator) indicating to the DU that resources and / or configurations are reserved for SDT. The DU reserves resources and / or configurations for SDT. The configuration includes a second SDTDU configuration. In the case where the second SDT DU configuration updates the first SDT DU configuration, the configuration includes at least a portion of the first SDT configuration. Depending on the implementation, the configuration also includes a C-RNTI.

[0246] Fig. 12C 12 is a flow chart of an example method 1200C similar to methods 1200A and 1200B, except that method 1200C includes block 1212. At block 1212, the DU determines whether the DU should update the first SDT DU configuration. If the DU determines that the DU should not update the first SDT DU configuration, the flow proceeds to block 1214. By performing the check at block 1212, when the DU should or needs to update the SDT DU configuration, the DU updates the SDT DU configuration for the UE, otherwise saves resources. At block 1214, the DU performs as described above with respect to Fig. 12A Otherwise, if the DU determines that the DU should update the first SDT DU configuration, then the flow proceeds to block 1216. At block 1216, the DU performs the operations described above with respect to Fig. 12B Described in block 1251. Blocks 1212, 1214, and 1216 may be grouped into block 1252.

[0247] FIG. 12A to FIG. 12C The first SDT DU configuration, DU to CU message and CU to DU message are similar to FIG. 10A to FIG. 11 The first SDT DU configuration, DU to CU message and CU to DU message. FIG. 10A to FIG. 11 The examples and implementations described can be applied to FIG. 12A to FIG. 12C .

[0248] Fig.13A A method 1300A implemented by a DU (eg, DU 174 of base station 104 or 106) for handling SDT configuration for a UE (eg, UE 102) is shown.

[0249] Method 1300A begins at block 1302, where the DU obtains a first SDT DU configuration for the UE. At block 1304, the DU receives a CU-to-DU message from the CU requesting an SDT DU configuration for the UE (see, e.g., events 328, 394, 428, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). At block 1306, the DU determines whether the DU supports incremental configuration. If the DU determines that the DU supports incremental configuration, the flow proceeds to block 1308. At block 1308, the DU performs one of blocks 1250, 1251, or 1252. Otherwise, if the DU determines that the DU does not support incremental configuration, the flow proceeds to block 1310. At block 1310, the DU generates a second SDT DU configuration as a full configuration. At block 1312, the DU sends a DU-to-CU message including a second SDT DU configuration to the CU (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995).

[0250] By performing the check at block 1306, the DU updates the first SDT DU configuration (when supported), otherwise generates a full configuration, thereby generally saving resources for DUs that support incremental configuration.

[0251] In some implementations, the DU receives a UE context release command message from the CU after sending the DU to CU message. In another implementation, the UE context release command message includes an SDT indicator (e.g., a CG-SDT hold indicator) indicating to the DU that resources and / or configurations are reserved for SDT. The DU reserves resources and / or configurations for SDT in response to the SDT indicator. The configuration includes a second SDT DU configuration. Depending on the implementation, the configuration also includes a C-RNTI.

[0252] Fig. 13Bis a flow chart of an example method 1300B that is similar to method 1300A, except that method 1300B includes blocks 1303 and 1307 instead of blocks 1302, 1304, and 1306. At block 1303, the DU receives a CU-to-DU message from the CU requesting an SDT DU configuration for the UE. At block 1307, the DU determines whether the DU has received or stored a first SDT DU configuration for the UE. If the DU determines that the DU has received or stored a first SDT DU configuration for the UE, the process proceeds to block 1308. Otherwise, if the DU determines that the DU has not received or stored a first SDT DU configuration for the UE, the process proceeds to block 1310. Performing the check at block 1307 instead of the check at block 1306 allows the DU to update the SDT configuration at the UE instead of generating a full configuration for a DU that does not support incremental configuration.

[0253] The first SDT DU configuration, DU to CU message and CU to DU message are similar to FIG. 10A to FIG. 11 First SDT DU configuration, DU to CU message and CU to DU message. FIG. 10A to FIG. 11 The examples and implementations described can be applied to FIG. 13A to FIG. 13B .

[0254] Fig.14A A method 1400A implemented by a DU (eg, DU 174 of base station 104 or 106) for handling SDT configuration for a UE (eg, UE 102) is shown.

[0255] The method 1400A starts at block 1402, where the DU generates an SDT DU configuration for the UE. At block 1404, the DU determines whether to generate the SDT DU configuration as a full configuration. If the DU generates or determines to generate the SDT DU configuration as a full configuration, the flow proceeds to block 1406. At block 1406, the DU sends a DU-to-CU message to the CU including the SDT DU configuration and a first indication that the SDT DU configuration is a full configuration (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995). Otherwise, if the DU generates or determines to generate the SDT DU configuration as an incremental configuration (i.e., not a full configuration), the flow proceeds to block 1408. At block 1408, the DU sends a DU-to-CU message including the SDT DU configuration to the CU (see, e.g., events 330, 394, 430, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995).

[0256] In some implementations, the DU refrains from including the first indication in the DU to CU message at block 1408. In some implementations, the DU refrains from including an indication that the SDT configuration is an incremental configuration at block 1408. In some implementations, the DU sends the SDT configuration to the UE (see, e.g., events 334, 394, 434, 494, 495, 594, 595, 694, 695, 794, 795, 894, 895, 994, 995).

[0257] 1400B is a flow diagram of an example method 1400B that is similar to method 1400A, except that method 1400B includes block 1409 instead of block 1406. If at block 1404, the DU generates or determines to generate the SDT DU configuration as an incremental configuration (i.e., not a full configuration), then the flow proceeds to block 1409. At block 1409, the DU sends a DU-to-CU message to the CU that includes the SDT DU configuration and a second indication that the SDT DU configuration is an incremental configuration.

[0258] In some implementations, the DU refrains from including the second indication in the DU-to-CU message at block 1408. In some implementations, the DU refrains from including an indication that the SDT configuration is a full configuration at block 1408.

[0259] Fig. 14B The DU to CU message in block 1408 of indicates that the SDT DU configuration is a full configuration, and Fig.14A The DU to CU message in block 1408 indicates that the SDT DU configuration is an incremental configuration.

[0260] 1400C is a flow diagram of an example method 1400C similar to methods 1400A and 1400B. If at block 1404, the DU generates or determines to generate the SDT DU configuration as a full configuration, the flow proceeds to block 1406. If at block 1404, the DU generates or determines to generate the SDT DU configuration as an incremental configuration, the flow proceeds to block 1409.

[0261] The following description can be applied to the above description.

[0262] In general, the description of one of the above figures may apply to another of the above figures. Any event or box described above may be optional. For example, an event or box with a dotted line may be optional. In some implementations, "message" is used and "information element (IE)" can be used to replace "message", and vice versa. In some implementations, "IE" is used and "field" can be used to replace "IE", and vice versa. In some implementations, "configuration" or "configuration parameter" can be used to replace "configuration", and vice versa. In some implementations, "early data transmission (EDT)" can be used to replace "small data transmission", and "EDT" can be used to replace "SDT", 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".

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

[0264] 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. In addition, in some cases, the user device can be embedded in an electronic system (such as a head unit of a vehicle or an advanced driver assistance system (ADAS)). 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.

[0265] 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 certain manner. A hardware module may include a dedicated circuit system 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 a programmable logic or circuit system that is temporarily configured by software to perform certain operations (e.g., as contained in a general-purpose processor or other programmable processor). The decision to implement a hardware module in a dedicated and permanently configured circuit system or in a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

[0266] 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 for managing a small data transmission (SDT) configuration for a user equipment (UE) implemented in a distributed unit (DU) communicating with a central unit (CU), the method comprising: receiving, at the DU, a first SDT configuration for the UE; receiving, at the DU and from the CU, a UE context modification message including an SDT configuration request; as well as In response to the receiving of the UE context modification message, a UE context modification response including a second SDT configuration is sent from the DU to the CU based on the first SDT configuration.

2. The method of claim 1, further comprising: generating the second SDT configuration at the DU; Wherein said sending is further responsive to said generating.

3. The method of claim 2, wherein said generating comprises: The second SDT configuration is generated at the DU such that the second SDT configuration modifies at least a portion of the first SDT configuration. 4 . The method of claim 3 , wherein the generating the second SDT configuration such that the second SDT configuration modifies at least a portion of the first SDT configuration occurs when the DU supports incremental configuration.

5. The method of claim 2, wherein said generating comprises: The second SDT configuration is generated at the DU such that the second SDT configuration replaces the first SDT configuration. 6 . The method of claim 5 , wherein the generating the second SDT configuration such that the second SDT configuration replaces the first SDT configuration occurs when the DU does not support incremental configuration.

7. The method according to any one of the preceding claims, further comprising: A downlink message including the second SDT configuration is sent from the DU to the UE to indicate that the UE is to update the first SDT configuration.

8. The method of claim 7, wherein the downlink message is a release message of a protocol associated with controlling radio resources.

9. The method of any one of the preceding claims, wherein the first SDT configuration is a first SDT DU configuration and the second SDT configuration is a second SDT DU configuration.

10. A method for managing a small data transmission (SDT) configuration for a user equipment (UE) implemented in a central unit (CU) communicating with a distributed unit (DU), the method comprising: providing a first SDT configuration to the DU; Sending a UE context modification message from the CU to the DU; receiving, at the CU, a UE context modification response including a second SDT configuration from the DU in response to the sending of the UE context modification message; and A downlink message including the second SDT configuration is sent from the CU to the UE via the DU.

11. The method of claim 10, wherein the UE context modification response includes a CU indication that the second SDT configuration is to modify the first SDT configuration, and the downlink message includes a DU indication that the second SDT configuration is to modify the first SDT configuration.

12. The method of claim 10, wherein the UE context modification response includes a CU indication that the second SDT configuration is to replace the first SDT configuration, and the downlink message includes a DU indication that the second SDT configuration is to replace the first SDT configuration.

13. The method of any one of claims 10 to 12, wherein the providing comprises sending the first SDT configuration in the UE context modification message. 14 . The method of claim 10 , wherein the first SDT configuration is a first SDT DU configuration, and the second SDT configuration is a second SDT DU configuration.

15. The method according to any one of claims 10 to 14, further comprising: Receiving the first SDT configuration for the UE.

16. A network node comprising a transceiver and processing hardware, the network node being configured to implement a method according to any preceding claim.

Images