Managing data communications with network in inactive state

Abstract

To perform channel monitoring, a user equipment (UE) monitors (1104) a Physical Downlink Control Channel (PDCCH) using a Radio Network Temporary Identifier (RNTI) during a Small Data Transmission (SDT) procedure and when the UE is operating in an inactive state (1102). The UE transitioning from the inactive state to a connected state in response to a command from a radio access network (RAN) (1110); and monitoring (1110) the downlink control channel using the RNTI after the transition when the UE is operating in the connected state.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of Provisional U.S. Patent Application No. 63 / 345,018, entitled “Managing Data Communication in an Inactive State with a Network,” filed on May 23, 2022, and Provisional U.S. Patent Application No. 63 / 345,024, entitled “Managing Data Communication with a User Equipment Operating in an Inactive State,” filed on May 23, 2022. The entire contents of these provisional applications 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 base station 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 may not have been counted as prior art at the time of filing are neither explicitly nor implicitly admitted to be prior art to the present disclosure.

[0005] Generally speaking, base stations operating in a cellular radio access network (RAN) use a specific radio access technology (RAT) and multiple layers of a protocol stack to communicate with user equipment (UE). For example, the physical layer (PHY) of the RAT provides transport channels to the media access control (MAC) sublayer, which in turn provides logical channels 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 an RRC_INACTIVE state, which allows the UE to transition back to the RRC_CONNECTED state more quickly using RAN-level base station coordination and RAN-level paging procedures. In some cases, a UE in the RRC_INACTIVE state has only a relatively small packet to send. For cases such as these, a Small Data Transmission (SDT) procedure is used to enable a node to support data transmission for a UE operating in the RRC_INACTIVE state (i.e., without requiring the UE to transition to the RRC_CONNECTED state).

[0007] The RAN enables SDT on a radio bearer basis, and the UE initiates SDT when less than a configured amount of uplink data is pending for transmission across all radio bearers for which SDT is enabled, the downlink (DL) reference signal received power (RSRP) is above a configured threshold, and valid SDT resources are available. The UE may initiate the SDT process by transmission on a random access channel (RACH) (i.e., random access SDT (RA-SDT)) or by transmission on a type 1 configured grant (CG) resource (i.e., CG-SDT). For RA-SDT, the network configures 2-step and / or 4-step random access resources for SDT. In RA-SDT, the UE may send an initial transmission of data in a payload of a message 3 (MSG3) of a 4-step random access procedure or a message A (MSGA) of a 2-step random access procedure. Then, after completing the random access procedure, the network may schedule subsequent uplink and / or downlink transmissions using dynamic uplink grants and downlink assignments, respectively.

[0008] In addition, the UE can initiate CG-SDT with only valid uplink (UL) timing alignment. The UL timing alignment is maintained by the UE based on the network-configured, SDT-specific timing alignment timer and the DL RSRP of the configured number of highest-ranked SSBs. When the SDT-specific timing alignment timer expires, the CG resources are released. After initiating CG-SDT, the UE sends an initial transmission including data on the CG opportunity using the CG configuration, and the network can schedule subsequent uplink transmissions using dynamic grants or on future CG resource opportunities. During the CG-SDT, downlink transmissions are scheduled using dynamic assignments. The UE can initiate subsequent uplink transmissions only after receiving confirmation of the initial uplink transmission from the network.

[0009] In some scenarios, the MAC entity is configured by RRC with SDT, and the SDT process is initiated by the RRC layer. In further scenarios, the SDT process is performed by a random access process with a 2-step RA type or a 4-step RA type (i.e., RA-SDT) or by a configured grant type 1 (i.e., CG-SDT), as discussed above.

[0010] The RRC layer configures the following parameters for the SDT process: (i) sdt-DataVolumeThreshold: the data volume threshold for the UE to determine whether to perform the SDT process; (ii) sdt-RSRP-Threshold: the RSRP threshold for the UE to determine whether to perform the SDT process; and (iii) cg-SDT-RSRP-ThresholdSSB: the RSRP threshold configured for SSB selection for CG-SDT.

[0011] If the SDT process is initiated by the upper layer, the MAC entity performs the following operations: (i) If the data volume of pending UL data across all RBs configured for SDT is less than or equal to sdt-DataVolumeThreshold; and (ii) If the RSRP of the downlink path loss reference is higher than sdt-RSRP-threshold: (a) If the serving cell for SDT is configured with a supplementary uplink; and (b) If the RSRP of the downlink path loss reference is less than rsrp-ThresholdSSB-SUL: The MAC entity selects the SUL carrier. Otherwise, the MAC entity selects the NUL carrier. If CG-SDT is configured on the selected UL carrier and the configured TA of the grant type 1 resources is valid; and if at least one SSB configured for CG-SDT with an SS-RSRP higher than cg-SDT-RSRP-ThresholdSSB is available: The MAC entity indicates to the upper layer that the conditions for initiating the SDT process are met; and performs the CG-SDT process on the selected UL carrier.

[0012] In some scenarios, for the SDT process, the MAC entity also considers the suspended RBs configured with SDT for data amount calculation. How the UE calculates the data amount for the suspended RBs depends on the implementation of the UE. In a further scenario, the data amount calculation does not take into account the size of the CCCH message. Otherwise, if a set of random access resources used to indicate RA-SDT is available on the selected UL carrier: the MAC entity considers that the cg-SDT-TimeAlignmentTimer expires, and performs corresponding actions (for example, as specified in clause 5.2 of TS 38.321), and indicates to the upper layer that the conditions for initiating the SDT process are met. Otherwise, the MAC entity indicates to the upper layer that the conditions for initiating the SDT process are not met.

[0013] Otherwise, if (i) and (ii) are not met, the MAC entity indicates to the upper layer that the conditions for initiating the SDT process are not met.

[0014] If RA-SDT is selected above and after the random access procedure is successfully completed, the UE monitors the physical downlink control channel (PDCCH) addressed to the cell radio network temporary identifier (C-RNTI) until the RA-SDT procedure is terminated. If CG-SDT is selected above and after the initial transmission for CG-SDT is performed, the UE monitors the PDCCH addressed to C-RNTI and CS-RNTI until the CG-SDT procedure is terminated.

[0015] Thus, in some scenarios, the UE is connected to a RAN (e.g., a 5G NR radio access network (NG-RAN)) comprising base stations, each of which has a central unit (CU) and at least one distributed unit (DU). However, it is unclear how the UE manages data communications with the NG-RAN when operating in the RRC_INACTIVE state and when transitioning from the RRC_INACTIVE state to the RRC_CONNECTED state. For example, it is unclear how the UE obtains the CS-RNTI for CG-SDT.

[0016] In addition, the UE monitors the PDCCH addressed to the C-RNTI until the SDT procedure (i.e., RA-SDT or CG-SDT) is terminated. In other words, after terminating the SDT procedure, the UE does not monitor the PDCCH addressed to the C-RNTI. In some cases, the UE terminates the SDT procedure because the UE transitions from the inactive state to the RRC_CONNECTED state. In this case, it is unclear which C-RNTI the UE should use to monitor the PDCCH after transitioning from the RRC_INACTIVE state to the RRC_CONNECTED state. Summary of the invention

[0017] An example embodiment of the technology disclosed herein is a channel monitoring method implemented in a UE. The method includes: during a small data transmission (SDT) process and when the UE is operating in an inactive state, using a radio network temporary identifier (RNTI) to monitor a physical downlink control channel (PDCCH); transitioning from the inactive state to a connected state in response to a command from a radio access network (RAN); and when the UE is operating in the connected state, using the RNTI to monitor the downlink control channel after the transition.

[0018] Another example implementation of the techniques is a user equipment (UE) comprising a transceiver and processing hardware configured to implement the above method.

[0019] Another example embodiment of the techniques is a communication method implemented in a radio access network (RAN) node. The method includes: when a user equipment (UE) is operating in an inactive state, performing a small data transmission (SDT) procedure with the UE using a radio network temporary identifier (RNTI); sending a command to the UE to transition from the inactive state to a connected state; and when the UE is operating in the connected state, communicating with the UE using the RNTI.

[0020] Another example implementation of the techniques is a radio access network (RAN) node comprising a transceiver and processing hardware configured to implement the above method. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0025] Figure 3is a message passing diagram of an example process for obtaining a non-SDT configuration for obtaining an SDT configuration for communicating data packets between a UE and a distributed base station when a radio connection between the UE and the base station is inactive;

[0026] Figure 4 is a message passing diagram for an example process for communicating data packets between a UE and a distributed base station when a radio connection between the UE and the distributed base station is inactive;

[0027] Figure 5A is a message passing diagram of an example process for communicating data packets between a UE and a distributed base station when a radio connection between the UE and the base station is inactive and later active;

[0028] Figure 5B is a message passing diagram for an example process for communicating data packets between a UE and a distributed base station when a radio connection between the UE and the base station is inactive and later active; and

[0029] Fig. 6A is Figure 1A A flowchart of an example method implemented in a UE for receiving a CS-RNTI, SDT configuration parameters and non-SDT configuration parameters from a RAN;

[0030] Figure 6B is similar to Fig. 6A Flowchart of an example method of , but in this method, the UE receives the CS-RNTI and SDT configuration parameters in a release message;

[0031] Figure 7 is Figure 1A A flowchart of an example method implemented in a UE for performing SDT using a CS-RNTI received in an RRC release message or an RRC reconfiguration message;

[0032] Figure 8 is Figure 1A A flowchart of an example method implemented in a UE for determining whether to retain or release a CS-RNTI based on whether a release message configures a CG-SDT;

[0033] Fig. 9 is Figure 1A A flowchart of an example method implemented in a UE for determining whether to use a CS-RNTI to monitor a PDCCH based on whether a message includes a configured grant configuration;

[0034] Fig. 10A is Figure 1A A flowchart of an example method implemented in a UE for monitoring a PDCCH using a C-RNTI before and after transitioning to a connected state;

[0035] Fig. 10B is similar to Fig. 10A a flowchart of an example method of , but in which the UE transitions to the connected state in response to receiving a setup message instead of a resume message;

[0036] Fig.11 is Figure 1A A flowchart of an example method implemented in a UE for determining whether to continue to use a C-RNTI to monitor a PDCCH based on whether a message causes the UE to transition to a connected state;

[0037] Fig. 12A is Figure 1A A flowchart of an example method implemented in a RAN for sending SDT configuration parameters, non-SDT configuration parameters, and CS-RNTI to perform data communication with a UE in an inactive state;

[0038] Fig. 12B is similar to Fig. 12A A flow chart of an example method of, but in which the RAN receives a capability indicating support for CS-RNTI, and sends the SDT configuration parameters and the CS-RNTI in a release message;

[0039] Fig. 12C is similar to Fig. 12A a flow chart of an example method of , but in this method, the RAN determines whether to send the SDT configuration parameters and the CS-RNTI in the release message based on whether the UE supports receiving the CS-RNTI;

[0040] Fig.13 is Figure 1A A flowchart of an example method implemented in a RAN for determining whether to send a message to configure or release CG-SDT based on whether the RAN configures CG-SDT for the UE;

[0041] Fig.14 is Figure 1B A flowchart of an example method implemented in a DU for determining whether to retain or release a CS-RNTI and a CG configuration based on whether the CS-RNTI and the CG configuration are configured for CG-SDT;

[0042] Fig.15A is Figure 1A A flowchart of an example method implemented in a RAN of a UE for performing data communications with a UE using a C-RNTI before and after stopping SDT via a resume message to the UE;

[0043] Fig. 15B is similar to Fig.15Abut in this method, the RAN stops the SDT by sending a setup message to the UE; and

[0044] Fig.16 is Figure 1A A flow chart of an example method implemented in a RAN of a UE for determining whether to continue or stop using a C-RNTI to perform data communications with a UE based on whether a message to the UE causes the UE to transition to a connected state.

[0045] Specific implementation method

[0046] 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 small 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, small data communications may refer to small data transmission (SDT) from a network perspective (i.e., SDT in a downlink direction), or SDT from a UE perspective (i.e., SDT in an uplink direction).

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

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

[0049] 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 traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks (e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). The 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management function (AMF) 164 and / or a session management function (SMF) 166. In general, the UPF 162 is configured to deliver user plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

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

[0051] The CN 110 may also communicatively connect the UE 102 to an Internet Protocol (IP) Multimedia Subsystem (IMS) network 170 via the RAN 105. The IMS network 170 may provide various IMS services, such as IMS short messages, IMS unstructured supplementary service data (USSD), IMS value-added service data, IMS supplementary service data, IMS voice calls, and IMS video calls, to the UE 102. To this end, an entity (e.g., a server or server group) operating in the IMS network 170 supports packet exchanges with the UE. The packets may convey signaling (such as Session Initiation Protocol (SIP) messages, IP messages, or other suitable messages) as well as data ("or media"), such as voice or video.

[0052] As discussed in detail below, when the radio connection between the UE 102 and the RAN 105 is suspended, for example, 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, the UE 102 and / or the RAN 105 can utilize the techniques of the present disclosure. For clarity, the examples below refer to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol. As discussed below, in some implementations, the UE 102 applies the techniques of the present disclosure only if the size of the data (e.g., UL data) is below a certain threshold.

[0053] In the example scenario discussed below, UE 102 transitions to the 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 the 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 a UL RRC message in a second UL PDU along with the first UL PDU, and send the second UL PDU to RAN 105. UE 102 includes a UE identity / identifier (ID) of UE 102 in the UL RRC message. RAN 105 may identify UE 102 based on the UE ID. In some implementations, the UE ID may be an active 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).

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

[0055] In some implementations, the data is a 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 other implementations, the UE 102 may omit the UL RRC message from the UL MAC PDU. In this latter case, the UE 102 may omit the UE ID of the UE 102 from the UL MAC PDU that does not include the UL RRC message. In further implementations, the UE 102 may include the UL PDCP PDU in a UL radio link control (RLC) PDU, and then include the UL RLC PDU in a UL MAC PDU. In some implementations where the UL RRC message is included in the UL MAC PDU, the UE 102 generates an RRC MAC-I and includes the RRC MAC-I in the UL RRC message. For example, the RRC MAC-I may be a resumeMAC-I field, as specified by 3GPP specification 38.331. In further implementations, the UE may utilize an integrity key (e.g., K RRCint The RRC MAC-I is obtained from the UL RRC message using a key), an integrity protection algorithm, and the 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).

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

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

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

[0059] In some scenarios and implementations, the base station 106 may retrieve the UE ID of the UE 102 from the UL RRC message and identify the base station 104 as the destination of the data in the first UL PDU based on the determined UE ID. In such scenarios, the base station 106 may be referred to as an "anchor" base station that transfers the UE 102 to an inactive state while retaining complete UE context information. 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. Then, the base station 104 retrieves data from the security-protected packet by using 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 decrypts the encrypted packet by using at least one security key (e.g., an encryption and / or decryption key) to obtain the data. If the security-protected packet is an integrity-protected packet, the integrity-protected packet may include data and MAC-I. The base station 104 may verify whether the MAC-I is valid for the security-protected packet by using at least one security key (e.g., an integrity key). When the base station 104 confirms that the MAC-I is valid, the base station 104 transmits the data to the CN 110 or the edge server. However, when the base station 104 determines that the MAC-I is invalid, the base station 104 discards the security-protected packet. In addition, if the security-protected packet is both encrypted and integrity-protected, the encrypted and integrity-protected packet may include the encrypted packet together with the encrypted MAC-I. In this case, the base station 104 decrypts the encrypted packet and the encrypted MAC-I to obtain the data and the MAC-I. The base station 104 then determines whether the MAC-I is valid for the data. If the base station 104 determines that the MAC-I is valid, the base station 104 retrieves the data and forwards the data to the CN 110 or the edge server. However, if the base station 104 determines that the MAC-I is invalid, the base station 104 discards the packet.

[0060] 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 decrypts the encrypted packet by using at least one security key (e.g., encryption and / or decryption key) to obtain the data. 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 transmits the data to the CN 110. On the other hand, when the base station 106 determines that the MAC-I is invalid, the base station 106 discards the security-protected packet. In addition, if the security-protected packet is both encrypted and integrity-protected, the encrypted and integrity-protected packet may include the encrypted packet together with the encrypted MAC-I. In this case, the base station 106 decrypts the encrypted packet and the encrypted MAC-I to obtain the data and the MAC-I. The base station 106 then determines whether the MAC-I is valid for the data. If the base station 106 determines that the MAC-I is valid, the base station 106 retrieves the data and forwards the data to the CN 110. However, if the base station 106 determines that the MAC-I is invalid, the base station 106 discards the packet.

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

[0062] Furthermore, 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.

[0063] For example, when the base station 104 determines that data is available for downlink transmission to a UE 102 currently operating in an RRC_INACTIVE or RRC_IDLE state, the base station 104 may apply at least one security function to the data to generate a security-protected packet, generate a first DL PDU including the security-protected packet, and a first DL PDU in a 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 particularly, 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.

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

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

[0066] 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 confirms 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 confirms 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, using the encrypted data and the encrypted MAC-I, the UE 102 can decrypt the encrypted packet and the encrypted MAC-I to obtain the data and the MAC-I. The UE 102 can then verify that the MAC-I is valid for the data. If the UE 102 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.

[0067] 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 these 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: send DL PDCP PDUs according to which the base station 104 can send data in the downlink direction in some scenarios, and receive UL PDCP PDUs according to which the base station 104 can receive data in the uplink direction in other scenarios. The processing hardware may further include an RRC controller 136 to implement processes and message delivery at the RRC sublayer of the protocol communication stack. In an example implementation, the processing hardware 130 includes an RRC inactive controller 138 that is configured to manage uplink and / or downlink communications with one or more UEs operating in an RRC_INACTIVE or RRC_IDLE state. The base station 106 may include substantially similar components. In particular, 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.

[0068] 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 a dedicated processing unit. In an example implementation, the processing hardware 150 includes an RRC inactive controller 158, which is configured to manage uplink and / or downlink communications when UE 102 operates in an RRC_INACTIVE state. In an example implementation, the processing hardware 150 includes a media access control (MAC) controller 152, which is configured to perform a random access procedure with a base station, send an uplink MAC protocol data unit (PDU) to the base station, and receive a downlink MAC PDU from the base station. The processing hardware 150 may also include a PDCP controller 154, which is configured to: send a DL PDCP PDU according to which the base station 106 can send data in the downlink direction in some scenarios, and receive a UL PDCP PDU according to which the base station 106 can receive data in the uplink direction in other scenarios. The processing hardware may further include an RRC controller 156 to implement procedures and messaging at the RRC sublayer of the protocol communication stack.

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

[0070] Each DU in DU 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 one or more general-purpose processors, and / or dedicated processing units. For example, the processing hardware may include: a MAC controller (e.g., MAC controllers 132, 142) configured to manage or control one or more MAC operations or processes (e.g., random access processes), and / or an RLC controller configured to manage or control one or more RLC operations or processes. The processing hardware may also include a physical layer controller configured to manage or control one or more physical layer operations or processes.

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

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

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

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

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

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

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

[0078] Figure 2B An example protocol stack 250 is illustrated in a simplified manner in which UE 102 can communicate with a DU (e.g., DU 174) and a CU (e.g., CU 172). The radio protocol stack 200 is functionally divided, such as Figure 2B 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support the connection with 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.

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

[0080] First reference Figure 3, in scenario 300, the base station 104 includes a central unit (CU) 172 and a distributed unit (DU) 174, and the CU 172 includes a CU-CP 172A and a CU-UP 172B. In this scenario 300, the UE 102 initially operates in a connected state 302 and communicates 304 with the DU 174 using a DU configuration (i.e., a first non-SDT DU configuration). The UE 102 further communicates 304 with the CU-CP 172A and / or the CU-UP 172B via the DU 174 using the CU configuration (i.e., the first non-SDT CU configuration). In some implementations, while the UE 102 is communicating 304 with the base station 104, the CU-CP 172A transmits 306 a UE context modification request message to the DU 174. In response, DU 174 transmits 308 a UE context modification response message including a non-SDT DU configuration (i.e., a second non-SDT DU configuration) for UE 102 to CU-CP 172A. CU-CP 172A generates an RRC reconfiguration message including the second non-SDT DU configuration, and sends 310 a first CU-to-DU message (e.g., a DL RRC messaging message) including the RRC reconfiguration message to DU 174. In turn, DU 174 sends 312 the RRC reconfiguration message to UE 102. In response, UE 102 sends 314 an RRC reconfiguration complete message to 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 CU-CP 172A.

[0081] After receiving 312 the RRC reconfiguration message, the UE 102 in the connected state communicates 318 with the DU 174 using the second non-SDT DU configuration, and communicates with the CU-CP 172A and / or CU-UP 172B via the DU 174. 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., the second non-SDT CU configuration), the UE 102 communicates 318 with the CU-CP 172A and / or CU-UP 172B via the DU 174 using the second non-SDT CU configuration. In some implementations, the second non-SDT CU configuration augments the first non-SDT CU configuration, or includes at least one new configuration parameter not included in the first non-SDT CU configuration. In some such cases, the UE 102 and the CU-CP 172A and / or CU-UP 172B communicate 318 with each other using the second non-SDU CU configuration and the configuration parameters of the first non-SDT CU configuration that are not extended by the second non-SDU CU configuration. In some implementations, the first non-SDT CU configuration includes configuration parameters related to the operation of the RRC and / or PDCP protocol layers (e.g., RRC 214 and / or NR PDCP 210), which the UE 102 and CU 172 use to communicate with each other when the UE 102 operates in a connected state. Similarly, depending on the implementation, the second non-SDT CU configuration includes configuration parameters related to the operation of the RRC and / or PDCP protocol layers, which the UE 102 and CU 172 use to communicate with each other when the UE 102 operates in a connected state. In some implementations, the first non-SDTCU configuration includes configuration parameters in a RadioBearerConfig information element (IE) and / or a MeasConfig IE (e.g., as defined in 3GPP specification 38.331 v16.7.0). Similarly, the second non-SDT CU configuration includes configuration parameters in a RadioBearerConfig IE and / or a MeasConfig IE (e.g., as defined in 3GPP specification 38.331 v16.7.0). In some implementations, the first non-SDT CU configuration is or includes a RadioBearerConfig IE and / or a MeasConfig IE, and the second non-SDT CU configuration is or includes a RadioBearerConfig IE and / or a MeasConfig IE.

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

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

[0084] In some implementations, while the UE 102 is communicating with the base station 104, or after the non-SDT resource (re) configuration process 390, 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., based on the UE 102 in the connected state having 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, the UE 102 determines or detects data inactivity, and sends 320 UE assistance information (e.g., UEAssistanceInformation message) to the DU 174, the UE assistance information indicating that the UE 102 prefers or requests to transition to the inactive state of the configured SDT. Subsequently, the DU 174 sends 321 a UL RRC messaging message including the UE assistance information to the CU-CP 172A. Thus, in some such implementations, CU-CP 172A determines that UE 102 is in a data inactive state based on UE assistance information. In other implementations, DU 174 performs data inactivity monitoring for UE 102. In further implementations, for example, CU-CP 172A sends a CU to DU message (e.g., a UE context setup request message or a UE context modification request message) to DU 174 to request or command DU 174 to perform data inactivity monitoring. In some cases where DU 174 detects or determines that UE 102 is in a data inactive state during monitoring, DU 174 sends 322 an inactivity notification (e.g., a UE inactivity notification message) to CU-CP 172A. Thus, in some such implementations, CU-CP 172A determines that UE 102 is in a data inactive state based on an inactivity notification received from DU 174. In yet other implementations, CU-UP 172B performs data inactivity monitoring for UE 102. For example, CU-CP 172A sends a CP to UP message (e.g., a bearer context setup request message or a bearer context modification request message) to CU-UP 172B to request or command CU-UP 172B to perform data inactivity monitoring. In some cases where CU-UP 172B detects or determines that UE 102 is in a data inactive state during monitoring, CU-UP 172B sends 323 an inactivity notification (e.g., a bearer context inactivity notification message) to CU-CP 172A. Thus, CU-CP 172A determines that UE 102 is in a data inactive state based on the inactivity notification received from CU-UP 172B. In some implementations, CU-CP 172A determines that UE 102 is in a data inactive state based on any combination of UE assistance information, inactivity notification of event 322, and / or inactivity notification of event 323.

[0085] After a certain period of data inactivity, CU-CP 172A determines that CU 172 and UE 102 did not send any data in the downlink direction or uplink direction, respectively, during the certain period (e.g., using any of the techniques described above for UE inactivity determination). In some implementations, CU-CP 172A determines to transition UE 102 to an inactive state with SDT configured in response to the determination. Alternatively, CU-CP 172A determines to immediately transition UE 102 to an inactive state with SDT configured in response to determining that UE 102 is in a data inactive state, regardless of whether CU 172 has sent data in the downlink direction within any particular time period.

[0086] In response to determining that UE 102 is in a data inactive state (for a certain period of time) or after such determination, or otherwise in response to determining to transition UE 102 to an inactive state with SDT configured, CU-CP 172A transmits 324 a bearer context modification request message to CU-UP 172B to suspend data transmission for UE 102. In response, CU-UP 172B suspends data transmission for UE 102 and transmits 326 a bearer context modification response message to CU-CP 172A. In addition, in response to determining that UE 102 is in a data inactive state (for a certain period of time) or after such determination, or otherwise in response to determining to transition UE 102 to an inactive state with SDT configured, CU-CP 172A transmits 328 a second CU-to-DU message (e.g., a UE context modification request message) to instruct DU 174 to provide (i.e., request from DU 174) an SDT DU configuration for UE 102. In some implementations, CU-CP 172A includes an SDT request indication (e.g., a field, IE, or CG-SDT query indication) 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, DU 174 sends 330 a second DU-to-CU message (e.g., a UE context modification response message) including the first SDT DU configuration to CU-CP 172A. Alternatively, DU 174 does not include the SDT DU configuration in the second DU-to-CU message, but after receiving the second CU-to-DU message (event 328) and / or after sending the second DU-to-CU message (event 330), DU 174 transmits another DU-to-CU message (e.g., a UE context modification required message) including the second SDT DU configuration to CU-CP 172A. In some alternative implementations, the CU-CP 172A sends the second CU-to-DU message and receives the second DU-to-CU message (or receives the alternative DU-to-CU message discussed above) before determining that the UE 102 is in the data inactive state.

[0087] In some implementations, DU 174 includes the third non-SDT DU configuration in the second DU to CU message. In such implementations, CU-CP 172A generates an RRC reconfiguration message including the third non-SDT DU configuration, and transmits 338 an additional CU to DU including the RRC reconfiguration message to DU 174. DU 174 then sends 340 the RRC reconfiguration message to UE 102. In response, UE 102 sends 342 an RRC reconfiguration complete message to DU 174, which in turn sends 344 an additional DU to CU message (e.g., UL RRC messaging message) including the RRC reconfiguration complete message to CU-CP 172A. In some implementations, DU 174 includes the first SDT DU configuration in an IE (e.g., DU to CU RRC information IE) of the second DU to CU message. In such implementations, the DU 174 includes a non-SDT DU configuration according to the format of the IE, such that the DU 174 includes the third non-SDT DU configuration in the IE.

[0088] In some implementations, the third non-SDT DU configuration extends the first non-SDT DU configuration and / or the second non-SDT DU configuration, or includes at least one new configuration parameter not included in the first non-SDT DU configuration and / or the second non-SDT DU configuration. In some such cases, the UE 102 and the DU 174 in the connected state communicate with each other using the third non-SDU DU configuration and the configuration parameters in the first non-SDT DU configuration and / or the second non-SDT DU configuration that are not extended by the third non-SDU DU configuration. In some implementations, the third non-SDT DU configuration includes the configuration parameters included in the first non-SDT DU configuration and / or the second non-SDT DU configuration, and the DU 174 sets the configuration parameters in the first non-SDT DU configuration and / or the second non-SDT DU configuration to the same value. Depending on the implementation, the DU 174 includes or does not include the configuration parameters to extend the first non-SDT DU configuration and / or the second non-SDT DU configuration. Similarly, depending on the implementation, DU 174 includes or does not include at least one new configuration parameter that is not included in the first non-SDT DU configuration and / or the second non-SDT DU configuration.

[0089] In other implementations, DU 174 includes an indication to ignore or discard the third non-SDT DU configuration in the second DU to CU message of event 330. In response to the indication, CU 172 discards the third non-SDT DU configuration. Therefore, events 338, 340, 342, and 344 are omitted. For example, the indication is a non-SDT configuration ignore indication or a cell group configuration (CellGroupConfig) ignore indication.

[0090] In yet other implementations, DU 174 generates a third non-SDT DU configuration as a special non-SDT DU configuration. For example, the special non-SDT DU configuration is an empty non-SDT DU configuration, which neither (i) includes configuration parameters to expand the first non-SDT DU configuration and / or the second non-SDT DU configuration, nor (ii) includes new configuration parameters not included in the first non-SDT DU configuration and / or the second non-SDT DU configuration. In some such examples, the special non-SDT DU configuration includes a cell group ID, an empty IE, and / or a configuration parameter that has been configured for UE 102 or sent to UE 102. The empty IE does not include a configuration parameter. In another example, the special non-SDT DU configuration is a zero-length non-SDT DU configuration or a zero-length octet string. In some implementations, at events 338 and 340, CU 172 determines to send a special non-SDT DU configuration to UE 102 via DU 174. In other implementations, the CU 172 determines to ignore or discard the special non-SDT DU configuration. Therefore, events 338, 340, 342, and 344 are omitted.

[0091] In some implementations, DU 174 determines to use at least one configuration parameter for UE 102 to perform SDT, and the first SDT DU configuration does not support the at least one configuration parameter. In such a case, DU 174 includes at least one configuration parameter in the third non-SDTDU configuration. For example, the configuration parameters include RLC bearer configuration parameters, logical channel configuration parameters, and / or MAC configuration parameters and / or PHY configuration parameters. In some implementations, DU 174 avoids including MAC configuration parameters and / or PHY configuration parameters in the third non-SDT DU configuration.

[0092] In some implementations, the third non-SDT DU configuration includes configuration parameters in a CellGroupConfig IE (e.g., as defined in 3GPP specification 38.331 v17.0.0). In some implementations, the third non-SDT DU configuration is a CellGroupConfig IE including configuration parameters. In some implementations, the RLC bearer configuration parameters are RLC-BearerConfig IE, or include configuration parameters in RLC-BearerConfig IE. In some implementations, the logical channel configuration parameters are LogicalChannelConfig IE, or include configuration parameters in LogicalChannelConfig IE (e.g., logicalChannelGroup, logicalChannelSR-DelayTimerApplied, and logicalChannelSR-Mask). In some implementations, the MAC configuration parameters are MAC-CellGroupConfig IE, or include configuration parameters in MAC-CellGroupConfig IE (e.g., enhancedSkipUplinkTxDynamic, SkipUplinkTxDynamic, enhancedSkipUplinkTxConfigured, buffer status report (BSR) configuration and / or power headroom report (PHR) configuration). In some implementations, the PHY configuration parameters are PhysicalCellGroupConfig IE, or include configuration parameters in PhysicalCellGroupConfig IE (e.g., configured scheduling RNTI (CS-RNTI)).

[0093] In some implementations, DU 174 avoids including a non-SDT DU configuration (e.g., CellGroupConfig IE) in the second DU to CU message. Therefore, DU 174 does not include the third non-SDT DU configuration in the second DU to DU message. In some implementations, DU 174 includes the first SDT DU configuration in an existing or new IE of the second DU to CU message instead of an IE (e.g., DU to CU RRC Information IE) of the second DU to CU message. The format of the existing or new IE does not include the non-SDT DU configuration (e.g., CellGroupConfig IE), so that DU 174 does not include the non-SDT DU configuration (e.g., CellGroupConfig IE) in the second DU to CU message. In other implementations, when DU 174 determines not to expand the first non-SDT DU configuration and / or the second non-SDT DU configuration or not to transmit new non-SDT configuration parameters to UE 102, DU 174 artificially excludes the non-SDT DU configuration (e.g., CellGroupConfigIE) from the IE of the second DU to CU message (e.g., DU to CU RRC information IE).

[0094] In some implementations, in response to determining to transition UE 102 to an inactive state with configured SDT, CU-CP 172A generates an RRC release message (e.g., RRCRelease message, RRCConnectionRelease message) to transition UE 102 to an inactive state. In the case where CU-CP 172A sends 338 RRC reconfiguration, CU-CP 172A sends the RRC release message after sending 338 the RRC reconfiguration message or receiving 344 the RRC reconfiguration complete message. In some implementations, CU-CP 172A includes the first SDT DU configuration in the RRC release message. In further implementations, CU-CP 172A additionally includes the first SDT CU configuration in the RRC release message. Then, CU-CP 172A transmits 332 a third CU to DU message (e.g., a UE context release command message or a UE context modification request message) including the RRC release message to DU174. Then, DU 174 sends 334 an RRC release message to UE 102. In some implementations, DU 174 receives a DL PDCP PDU including an RRC release message from CU-CP 172A (e.g., at event 332). DU 174 generates a DL RLC PDU including the DL PDCP PDU, generates a DL MAC PDU including the DL RLC PDU, and sends 334 the DL MAC PDU to UE 102. In some implementations, DU 174 determines that UE 102 receives the RRC release message when receiving a HARQ ACK for the DL MAC PDU from UE 102. In yet other implementations, DU 174 determines that UE 102 receives the RRC release message when receiving an RLCACK for the DL RLC PDU from UE 102. In yet other implementations, DU 174 starts a release timer in response to sending or determining to send the RRC release message. When the release timer expires, DU 174 determines that UE 102 receives the RRC release message.

[0095] The RRC release message instructs UE 102 to transition to an inactive state. UE 102 transitions 336 from a connected state to an inactive state upon receiving the RRC release message. In some implementations, DU 174 retains the first SDT DU configuration in response to receiving a third CU to DU message or after the reception. In some implementations, DU 174 releases the first non-SDT DU configuration and / or the second non-SDT DU configuration in response to receiving a third CU to DU message or after the reception. In other implementations, DU 174 retains the first non-SDT DU configuration and / or the second non-SDT DU configuration in response to receiving a third CU to DU message or after the reception. In yet other implementations, DU 174 retains a portion of the first non-SDT DU configuration and / or the second non-SDT DU configuration in response to receiving a third CU to DU message or after the reception, and releases the remaining portion of the first non-SDT DU configuration and / or the second non-SDT DU configuration. For example, DU 174 retains RLC bearer configuration parameters, logical channel configuration parameters, MAC configuration parameters, and / or PHY configuration parameters (e.g., CS-RNTI). In some implementations, DU 174 transmits 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.

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

[0097] In some implementations, CU-CP 172A does not include an indication in the third CU-to-DU message to direct DU 174 to retain the first SDT DU configuration, but DU 174 still retains the first SDT DU configuration as described above. In further implementations, CU-CP 172A includes an indication in the third CU-to-DU message to direct DU 174 to retain the first SDT DU configuration, and DU 174 retains the first SDT DU configuration in response to the indication. DU 174 retains at least a portion of the first non-SDT DU configuration, the second non-SDT DU configuration, and / or the non-SDT DU configuration. In such implementations, if DU 174 receives a UE context release command message for UE 102 that does not include the indication from CU-CP 172A, DU 174 releases the first SDT DU configuration and the first non-SDT DU configuration, the second non-SDT DU configuration, and / or the third non-SDT DU configuration.

[0098] In some implementations, the first SDT CU configuration includes a DRB list (e.g., std-DRB-List) including a DRB ID list indicating the IDs of the DRBs configured for SDT. In further implementations, the first SDT CU configuration includes an SRB2 indication (e.g., sdt-SRB2-Indication) indicating the SRB2 configured for SDT. In still further implementations, the first SDT CU configuration includes an SRB2 indication indicating the SRB2 configured for SDT. Figure 4 In another embodiment, the first SDT CU configuration includes a data volume threshold (e.g., sdt-DataVolumeThreshold) for the UE 102 to determine whether an SDT can be initiated.

[0099] In some implementations, the first SDT DU configuration includes at least one common SDT configuration, at least one RA-SDT configuration, and / or at least one CG-SDT configuration for CG-SDT. For example, at least one common SDT configuration includes a buffer status report (BSR) configuration and / or a power headroom report (PHR) configuration. In another example, at least one RA-SDT configuration includes random access configuration parameters for a two-step and / or four-step random access procedure. In another example, at least one CG-SDT configuration includes a CG-SDT configuration parameter for CG-SDT (e.g., CS-RNTI), a configured grant (CG) configuration for CG-SDT (e.g., ConfiguredGrantConfig IE), a time alignment timer value for CG-SDT, and / or a timing advance validity threshold. The CG configuration configures a configured grant (e.g., a CG opportunity such as a time slot) that occurs periodically in the time domain. In some implementations, the CG configuration includes configuration parameters for frequency hopping, demodulation reference signal (DMRS), modulation and coding scheme (MCS), transport block size (TBS), resource allocation, resource block group, CG timer, frequency domain resource allocation, HARQ operation, mapping mode, path loss reference, physical uplink shared channel (PUSCH), periodicity, power control, precoding and number of layers of multiple input multiple output (MIMO), time domain offset and / or time domain allocation. In yet another example, the CG-SDT configuration is an SDT-MAC-PHY-CG-Config IE, or includes CG-SDT configuration parameters in an SDT-MAC-PHY-CG-Config IE. In some implementations, DU 174 configures a timing advance validity threshold for UE 102 to determine whether UE 102 performs SDT using a configured authorization configuration for CG-SDT. In a further implementation, 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 or that CG-SDT is not appropriate, UE 102 performs RA-SDT with CU 172 via DU 174, as described with respect to Figure 4 described.

[0100] In the case where DU 174 provides the CG-SDT configuration to CU-CP 172A at event 330, DU 174 retains the radio resources configured by the CG-SDT configuration while retaining the first SDT DU configuration. After sending 330 a second DU to CU message, receiving 332 a third CU to DU message, sending 334 an RRC release message, receiving a HARQ ACK or RLC ACK for the RRC release message from UE 102, or expiration of a release timer, DU 174 starts or attempts to receive UL transmissions on the radio resources configured in the configured grant (CG) configuration for SDT in the CG-SDT configuration from UE 102. In some implementations, DU 174 releases the radio resources configured by the CG-SDT configuration when releasing the first SDT DU configuration or the CG-SDT configuration. In the case where DU 174 does not provide CG-SDT configuration to CU-CP 172A, DU 174 releases all relevant 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 CG-SDT configuration to CU-CP 172A, DU 174 reserves all relevant signaling and user data transmission resources for UE 102 in response to or after receiving the third CU-to-DU message.

[0101] In the case where the first SDT DU configuration does not include a configuration for CG-SDT, CU-CP 172A and / or DU 174 only configure RA-SDT for UE 102. In some such cases, UE 102 performs RA-SDT with CU 172 via DU 174, as described in relation to Figure 4 described.

[0102] 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 with SDT configured. 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, in some such implementations, CU-CP 172A generates a first SDT DU configuration on its own without requesting DU 174 to provide an SDT DU configuration, and includes the first SDT DU configuration in the RRC release message.

[0103] In some implementations, DU 174 does not include the SDT DU configuration in the second DU to CU message (e.g., if or because UE 102 does not support CG-SDT, DU 174 does not support CG-SDT, or DU 174 does not have available radio resources for CG-SDT). In some such cases, the RRC release message does not include the SDT DU configuration. Otherwise, DU 174 includes the first SDT DU configuration, as described above. In some implementations, DU 174 does not include the CG-SDT configuration in the first 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 first SDT DU configuration does not include the CG-SDT configuration. Otherwise, DU 174 includes at least one CG-SDT configuration in the first SDT DU configuration, as described above.

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

[0105] In some implementations, the DU 174 determines whether to provide the SDT DU configuration for the UE 102 to the CU-CP 172A based on whether the UE 102 supports CG-SDT. In further implementations, in addition to whether the UE 102 supports CG-SDT, the DU 174 determines whether to provide the SDT DU configuration for the UE 102 to the CU-CP 172A based on whether the DU 174 supports CG-SDT. In the case that the UE 102 supports CG-SDT and / or the DU 174 supports CG-SDT, the DU 174 provides the first SDT DU configuration for the UE 102 to the CU-CP 172A, as described above. In the case that the UE 102 does not support CG-SDT or the DU 174 does not support CG-SDT, the DU 174 does not provide the SDT DU configuration for the UE 102 (e.g., the DU 174 does not include the first SDT DU configuration in the second DU to CU message). When the UE 102 operates in the connected state 302 or in the inactive state before the event 302, the DU 174 receives the UE capabilities from the CU-CP 172A. Therefore, the DU 174 can determine whether the UE 102 supports CG-SDT based on the UE capabilities. In some implementations, the DU 174 transmits a DU-to-CU message to the CU-CP 172A to indicate whether the DU 174 supports CG-SDT, as described above.

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

[0107] Next reference Figure 4 , scenario 400 depicts small data transmission. In scenario 400, base station 104 includes CU 172 and DU 174. CU 172 includes CU-CP 172A and CU-UP 172B. In scenario 400, UE 102 initially operates in an inactive state with SDT configured 402. In some implementations or scenarios, Figure 4 Prior to the events shown, UE 102 Figure 3 The described transition from the connected state to the inactive state of the configured SDT (i.e., event 402 may be after event 336). In other implementations or scenarios, Figure 4Prior to the event shown, UE 102 transitions from an inactive state where SDT is not configured to an inactive state where SDT is configured. For example, UE 102 receives an RRC release message from a base station (e.g., base station 104 or base station 106) that causes UE 102 to transition to an inactive state and does not include an SDT configuration. In such a case, UE 102 transitions to an inactive state where SDT is not configured in response to the RRC release message. In some implementations, 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 from the base station that includes a first SDT CU configuration and / or a first SDT DU configuration similar to the RRC release message of event 334.

[0108] Later, the UE 102 operating in the inactive state with SDT configured initiates an SDT (e.g., an SDT session or process). In response to or after initiating the SDT, the UE 102 generates an initial UL MAC PDU including a UL RRC message and sends 404 the initial UL MAC PDU to the DU 174 on the cell 124. In some implementations, the UE 102 starts an SDT session timer (e.g., timer T319a) in response to or after initiating the SDT. In some implementations, the UE 102 starts the SDT session timer when initiating the SDT. In other implementations, the UE 102 starts the SDT session timer after sending 404 the initial UL MAC PDU. 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 transmits 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.

[0109] In a scenario where the UE 102 initiates an SDT to send UL data (e.g., a data packet) eligible for SDT, the UE 102 includes the UL data in an initial UL MAC PDU sent 404 by the UE 102. In a scenario where the UE 102 initiates an SDT to receive DL data, the UE 102 does not include the UL data packet in the initial UL MAC PDU sent 404 by the UE 102. In a further implementation, the UE 102 initiates an SDT to receive DL data in response to receiving a paging from the DU 174. In some such scenarios, the UE 102 includes an SDT indication in an 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.

[0110] In some implementations, the UE 102 includes a buffer status report or a power headroom report in an initial UL MAC PDU at event 404. In other implementations, the UE 102 refrains from including a buffer status report and / or a power headroom report in an initial UL MAC PDU at event 404 (e.g., depending on a BSR configuration and / or a PHR configuration, respectively). Depending on the implementation, in the buffer status report, the UE 102 includes or indicates a buffer status of the UE 102 for one or more logical channels or logical channel groups. In further implementations, in the power headroom report, the UE 102 includes or indicates a power headroom status or value.

[0111] In some implementations, the UE 102 in an inactive state performs a random access procedure with the DU 174 to send 404 an initial UL MAC PDU. In such a case, the SDT is a RA-SDT. For example, the random access procedure is a four-step random access procedure or a two-step random access procedure. In the case of the four-step random access procedure, the UE 102 sends a random access preamble to the DU 174, and in response, the DU 174 sends a random access response (RAR) including an uplink grant to the UE 102. In addition, the UE 102 sends 404 an initial UL MAC PDU according to the uplink grant. The DU 174 receives 404 the initial UL MAC PDU according to the uplink grant in the RAR. In the case of a two-step random access procedure, the UE 102 sends 404 a message A including a random access preamble and an initial UL MAC PDU to the DU 174 according to the two-step random access configuration parameters. The UE 102 receives 404 the two-step random access configuration parameters in the system information broadcast by the DU 174 on the cell 124 before sending 404 the initial UL MAC PDU. The DU 174 receives 404 the initial UL MAC PDU according to the two-step random access configuration parameters.

[0112] In a further implementation, the UE 102 sends 404 an initial UL MAC PDU on radio resources configured in a configured grant (CG) configuration for SDT, such as in the case where the UE 102 receives a CG-SDT configuration, as described with respect to Figure 3 As described. Thus, DU 174 receives 404 a UL MAC PDU on the radio resources according to the CG configuration. In some such implementations, UE 102 sends (e.g., at event 418) a subsequent UL MAC PDU including one or more UL data packets discussed below on the radio resources configured with the CG configuration.

[0113] In some implementations, if DU 174 fails to obtain the initial UL MAC PDU at event 404, DU 174 commands UE 102 to retransmit the initial UL MAC PDU. More specifically, DU 174 generates a DCI including a UL grant (i.e., a dynamic grant), generates a CRC for the DCI, scrambles the CRC using the ID of UE 102, and sends the DCI and the scrambled CRC on the PDCCH to command UE 102 to retransmit the initial UL MAC PDU. UE 102 receives the DCI and the scrambled CRC from DU 174 on the PDCCH, and verifies whether the CRC is valid using the ID of UE 102 and the DCI. If UE 102 verifies that the CRC is valid using the ID of UE 102, UE 102 retransmits the initial UL MAC PDU to DU 174 according to the DCI. Otherwise, if UE 102 verifies that the CRC is invalid, UE 102 discards the DCI. In some implementations, if DU 174 fails to obtain the initial UL MAC PDU from the retransmission of the initial UL MAC PDU, DU 174 again commands UE 102 to retransmit the initial UL MAC PDU in a manner similar to that described above. In some implementations, the ID is a CS-RNTI. For example, as described with respect to Figure 3 As described, UE 102 receives a CS-RNTI from base station 104. In another example, UE 102 receives an RRC recovery message including the CS-RNTI from base station 104 before initiating SDT at event 404. In other implementations, the ID is C-RNTI. In one implementation, UE 102 receives an RRC reconfiguration message including the C-RNTI from CU 172 via base station 106 or another DU. In another implementation, UE 102 performs a random access procedure with DU 174 before initiating SDT at event 404, and receives the C-RNTI from DU 174 in a random access response or message B (MSGB) during the random access procedure.

[0114] In some implementations, if DU 174 successfully obtains the initial UL MAC PDU at event 404, DU 174 commands UE 102 to send or receive a new transmission. More specifically, in some such implementations, DU 174 generates a DCI, generates a CRC for the DCI, scrambles the CRC using the ID of UE 102, and sends the DCI and the scrambled CRC on the PDCCH to command UE 102 to send or receive a new transmission. If UE 102 receives the DCI and the scrambled CRC from DU 174 on the PDCCH, and verifies that the CRC is valid using the ID of UE 102 and the DCI, UE 102 determines that DU 174 successfully received the initial UL MAC PDU. In some implementations, UE 102 starts an SDT session timer in response to the determination. In some implementations, the DCI includes an UL grant to command UE 102 to send a new transmission. In such cases, UE 102 generates an UL MAC PDU and transmits the UL MAC PDU according to the DCI. In the case where UE 102 has UL data available for transmission, UE 102 includes the UL data in the UL MAC PDU. In some such cases, UE 102 includes or does not include a MAC control element and a subheader and / or padding bits for the MAC control element and a subheader for the padding bits in the UL MAC PDU. The MAC control element includes a BSR and / or a PHR. In some cases where UE 102 does not have UL data available for transmission, UE 102 only includes a MAC control element and a subheader and / or padding bits for the MAC control element and / or a subheader for the padding bits in the UL MAC PDU. In other implementations, the DCI includes a DL assignment to command UE 102 to receive a new transmission. DU 174 generates a DL MAC PDU and transmits a DL MAC PDU as a new transmission to UE 102 according to the DL assignment. UE 102 receives the new transmission according to the DCI and obtains a DL MAC PDU from the new transmission. In the case where DU 174 receives DL data from CU-CP 172A or CU-CP 172B, DU 174 includes the DL data in the DL MAC PDU. In some such cases, DU 174 may or may not include padding bits and / or a subheader for padding bits in the DL MAC PDU. In some cases where DU 174 has no DL data available for transmission, DU 174 only includes padding bits and / or a subheader for padding bits in the DL MAC PDU.

[0115] If UE 102 includes UL data in the initial UL MAC PDU, DU 174 retrieves the UL data from the initial UL MAC PDU. In some such cases, DU 174 includes the UL data in the DU to CU message of event 406. Alternatively, DU 174 transmits the UL data to CU-CP 172A separately in the DU to CU message (i.e., event 415). In some implementations, the DU to CU message of event 415 is a UL RRC messaging message. As yet another alternative, DU 174 transmits 416 the UL data separately to CU-UP 172B via a user plane (UP) connection, as described below (i.e., event 416). After receiving 406 to the first DU to CU message, in some implementations, CU-CP 172A transmits 408 a UE context setup request message to DU 174 to establish a UE context for UE 102 at DU 174. In some implementations, in the UE context setup request message, the CU-CP 172A includes transport layer information for one or more GTP-U tunnels between the CU-UP 172B and the DU 174, so that the DU 174 sends UL data and / or subsequent UL data to the CU-UP 172B via the one or more GTP-U tunnels (e.g., in the small data communication 418). In a further implementation, in response, the DU 174 transmits 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, and / or receiving 410 the UE context setup response message, the CU-CP 172A sends 412 a bearer context modification request message to the CU-UP 172B to resume data transmission to the UE 102. In response, the CU-UP 172B resumes data transmission to the UE 102 and sends 414 a bearer context modification response message to the CU-CP 172A. After receiving 408 the UE context setup request message and / 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, such as in the case where the UL data packet (received at event 404) includes an RRC message or is associated with an SRB (e.g., SRB1 or SRB2). In some cases where the UL data packet is associated with a DRB, DU 174 sends 416 the UL data packet to CU-UP 172B via one of the one or more GTP-U tunnels.

[0116] In some implementations, CU-CP 172A includes the transport layer information of CU-UP 172B in the UE context setup request message. In further implementations, the transport layer information of CU-UP 172B includes an IP address and / or an uplink tunnel endpoint ID (e.g., TEID). Depending on the implementation, 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 to send (e.g., one or more UL data packets), UE 102 sends (at event 418) one or more subsequent UL MAC PDUs including the subsequent UL data to DU 174. In some implementations, UE 102 sends subsequent UL MAC PDUs to DU 174 using CG configuration and / or UL grant (i.e., dynamic grant). DU 174 receives subsequent UL MAC PDUs from UE 102 according to the CG configuration and / or UL grant. DU 174 then retrieves subsequent UL data from a subsequent UL MAC PDU. In some implementations, UE 102 receives (at event 418) DCIs from DU 174, each DCI including a specific UL grant in the UL grant. To send each of the DCIs to UE 102, DU 174 generates a CRC for the DCI, scrambles the CRC using the ID of UE 102, and sends the DCI and the scrambled CRC on the PDCCH. In some implementations, the ID of UE 102 is a C-RNTI or a CS-RNTI. UE 102 receives the DCI and the scrambled CRC on the PDCCH, and sends a subsequent UL MAC PDU to DU 174 based on the DCI.

[0117] In some implementations, if DU 174 fails to obtain the UL MAC PDU at event 418, DU 174 commands UE 102 to retransmit the UL MAC PDU. More specifically, DU 174 generates a DCI including a UL grant (i.e., a dynamic grant), generates a CRC for the DCI, scrambles the CRC with the ID of UE 102, and sends the DCI and the scrambled CRC on the PDCCH (at event 418) to command UE 102 to retransmit the UL MAC PDU. UE 102 receives the DCI and the scrambled CRC from DU 174 on the PDCCH and retransmits the UL MAC PDU to DU 174 according to the UL grant or the DCI. In some implementations, if DU 174 still fails to obtain the UL MAC PDU, DU 174 again commands UE 102 to retransmit the UL MAC PDU in a manner similar to that described above.

[0118] For each DCI and scrambled CRC received by UE 102 at event 404 or 418, in some implementations, UE 102 verifies whether the CRC is valid using the ID of UE 102 and the DCI. If UE 102 verifies that the CRC is valid, UE 102 sends or resends the UL MAC PDU according to the DCI. Otherwise, if UE 102 verifies that the CRC is invalid, UE 102 discards the DCI.

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

[0120] In the event that the subsequent UL data is associated with one or more SRBs (e.g., SRB1 and / or SRB2), DU 174 sends 418 one or more DU to CU messages including the subsequent UL data to CU-CP 172A. Depending on the implementation, each DU to CU message includes a specific UL data packet of the subsequent UL data. In the event that the subsequent UL data is associated with one or more DRBs, DU 174 (at event 418) sends the subsequent UL data to CU-UP 172B. In some implementations, DU 174 includes the transport layer information of DU 174 in the UE context setup response message. Subsequently, in some implementations, 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 sends 418 the DL data (e.g., one or more DL data packets) to DU 174 using the transport layer information of DU 174. DU 174 then sends (at event 418) one or more DL MAC PDUs including the DL data to UE 102 operating in an inactive state. In some implementations, DU 174 sends (at event 418) the DL MAC PDUs to UE 102 using the DL assignments. UE 102 receives the DL MAC PDUs from DU 174 according to the DL assignments. UE 102 then retrieves the DL data from the DL MAC PDUs. In some implementations, UE 102 receives (at event 418) DCIs from DU 174, each DCI including a specific DL assignment in the DL assignments. To send each of the DCIs to UE 102, DU 174 generates a CRC for the DCI, scrambles the CRC using the ID (e.g., C-RNTI) of UE 102, and sends the DCI and the scrambled CRC on the PDCCH. UE 102 receives the DCI and the scrambled CRC on the PDCCH. UE 102 receives the DL transmission from DU 174 and obtains the DL MAC PDU from the DL transmission.

[0121] In some implementations, if UE 102 fails to obtain the DL MAC PDU at event 418, UE 102 sends a hybrid automatic repeat request (HARQ) negative acknowledgement (NACK) to DU 174. More specifically, DU 174 retransmits the DL MAC PDU as described below. In response to receiving the HARQ NACK or after receiving it, DU 174 generates a DCI including a DL assignment, generates a CRC for the DCI, scrambles the CRC using the ID of UE 102, and sends the DCI and the scrambled CRC on the PDCCH to indicate that UE 102 receives a retransmission of the DL MAC PDU. UE 102 receives the DCI and the scrambled CRC from DU 174 on the PDCCH, and verifies whether the CRC is valid using the ID of UE 102 and the DCI. If UE 102 verifies that the CRC is valid, UE 102 attempts to receive or receives a retransmission of the DL MAC PDU according to the DCI or the DL assignment. Otherwise, if the UE 102 verifies that the CRC is invalid, the UE 102 discards the DCI. If the UE 102 successfully obtains the DL MAC PDU from the retransmission, the UE 102 sends a HARQ acknowledgement (ACK) to the DU 174. Otherwise, the UE 102 sends a HARQ NACK to the DU 174. The DU 174 then retransmits the DL MAC PDU in a manner similar to that described above.

[0122] In some example scenarios, the 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 a PDU (e.g., an RRC PDU, a PDCP PDU, or an RLC PDU), which includes an RRC message, a NAS message, an IP packet, an Ethernet packet, or an application packet.

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

[0124] In some implementations, the UL RRC message is an existing RRC recovery request message (e.g., an RRCResumeRequest message, an RRCResumeRequest1 message, an RRCConnectionResumeRequest 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. Depending on the implementation, the new RRC recovery request message is the format of the existing RRC recovery request message. In some implementations, in the case of a downlink SDT, the UL RRC message includes an SDT indication (e.g., a field or information element (IE) (e.g., resumeCause or ResumeCause)). In some implementations, the UL RRC message is a common control channel (CCCH) message.

[0125] In some implementations, after the UE 102 sends 404 an UL MAC PDU or conducts subsequent UL data and / or DL ​​data communications 418 with the DU 174, the CU-CP 172A determines to stop the SDT for the UE 102 based on the data inactivity of the UE 102 (i.e., the UE 102 in the inactive state does not have data activity with the base station 104). For example, after the UE 102 sends 404 an UL MAC PDU or conducts subsequent UL data and / or DL ​​data communications 418 with the DU 174, the inactive UE 102 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. Subsequently, the DU 174 sends 421 an UL RRC messaging message including the UE assistance information to the CU-CP 172A. Therefore, the CU-CP 172A can determine that the UE 102 is in a data inactive state based on the UE assistance information. In other implementations, DU 174 performs data inactivity monitoring for UE 102. For example, CU-CP 172A sends a CU to DU message (e.g., a UE context setup request message or a UE context modification request message of event 408) 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 a data inactive state during monitoring, DU 174 sends 422 an inactivity notification (e.g., a UE inactivity notification message) to CU-CP 172A. Therefore, CU-CP 172A can determine that UE 102 is in a data inactive state based on the inactivity notification received from DU 174. In yet other implementations, CU-UP 172B performs data inactivity monitoring for UE 102. For example, CU-CP 172A sends a CP to UP message to CU-UP 172B to request or command CU-UP 172B to perform data inactivity monitoring. In some implementations, before UE 102 initiates SDT, the CP to UP message is a bearer context setup request message or a bearer context modification request message. In other implementations, during SDT, the CP to UP message is a bearer context modification request message (event 412). In the event that CU-UP 172B detects or determines that UE 102 is in a data inactive state during monitoring, CU-UP 172B sends 423 an inactivity notification (e.g., a bearer context inactivity notification message) to CU-CP 172A. Therefore, CU-CP 172A can determine that UE 102 is in a data inactive state based on the inactivity notification received from CU-UP 172B.In some implementations, CU-CP 172A determines that UE 102 is in a data inactive state based on any combination of UE assistance information, the inactivity notification of event 422 , and / or the inactivity notification of event 423 .

[0126] In some implementations, after a certain period of data inactivity, CU-CP 172A determines that neither CU 172 nor UE 102 has sent any data in the downlink direction or uplink direction during the certain period (e.g., using any of the techniques described above for UE inactivity determination). In further implementations, CU-CP 172A determines to stop SDT in response to the determination. Alternatively, CU-CP 172A determines to immediately stop SDT for UE 102 in response to determining that UE 102 is in a data inactive state, regardless of whether CU 172 has sent data in the downlink direction in any particular time period.

[0127] In response to determining that the UE 102 is in a data inactive state or after the determination or otherwise determining to stop the SDT, the CU-CP 172A transmits 424 a bearer context modification request message to the CU-UP 172B to suspend data transmission for the UE 102. In response, the CU-UP 172B suspends data transmission for the UE 102 and transmits 426 a bearer context modification response message to the CU-CP 172A. In response to determining that the UE 102 is in a data inactive state or after the determination or otherwise determining to stop the SDT, the CU-CP 172A transmits 428 a second CU-to-DU message (e.g., a UE context modification request message) to direct the DU 174 to provide (i.e., request from the DU 174) an SDT DU configuration for the UE 102. In some implementations, the CU-CP 172A includes an SDT request indication (e.g., a field or 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, DU 174 sends 430 a second DU-to-CU message (e.g., a UE context modification response message) including a second SDTDU configuration to CU-CP 172A. Alternatively, DU 174 does not include the SDT DU configuration in the second DU-to-CU message, and DU 174 instead transmits another DU-to-CU message (e.g., a UE context modification required message) including the second SDT DU configuration to CU-CP 172A after receiving the second CU-to-DU message (event 428) and / or after sending the second DU-to-CU message (event 430). In some alternative implementations, CU-CP 172A sends the second CU-to-DU message and receives the second DU-to-CU message (or receives the alternative DU-to-CU message discussed above) before determining that UE 102 is in a data inactive state.

[0128] In some implementations, DU 174 includes the non-SDT DU configuration in the second DU to CU message. In such implementations, CU-CP 172A generates an RRC recovery message including the non-SDT DU configuration and transmits 438 an additional CU to DU including the RRC recovery message to DU 174. Then, DU 174 sends 440 the RRC recovery message to UE 102. In response, UE 102 transitions 441 to a connected state and sends 442 an RRC recovery complete message to DU 174. Then, DU 174 sends 444 an additional DU to CU message (e.g., UL RRC messaging message) including the RRC recovery complete message to CU-CP 172A. In some implementations, DU 174 includes the second SDT DU configuration in an IE (e.g., DU to CU RRC information IE) of the second DU to CU message. In some such implementations, the DU 174 includes a non-SDT DU configuration according to the format of the IE, such that the DU 174 includes the third non-SDT DU configuration in the IE.

[0129] In some implementations, the third non-SDT DU configuration extends the first non-SDT DU configuration and / or the second non-SDT DU configuration, or includes at least one new configuration parameter not included in the first non-SDT DU configuration and / or the second non-SDT DU configuration. In some such cases, the UE 102 and the DU 174 in the connected state communicate with each other using the third non-SDU DU configuration and the configuration parameters in the first non-SDT DU configuration and / or the second non-SDT DU configuration that are not extended by the third non-SDU DU configuration. In some implementations, the third non-SDT DU configuration includes the configuration parameters included in the first non-SDT DU configuration and / or the second non-SDT DU configuration, and the DU 174 sets the configuration parameters in the first non-SDT DU configuration and / or the second non-SDT DU configuration to the same value.

[0130] In other implementations, DU 174 includes an indication to ignore or discard the third non-SDT DU configuration in the second DU to CU message of event 430. In response to the indication, CU 172 discards the third non-SDT DU configuration. Therefore, events 438, 440, 441, 442, and 444 are omitted. For example, the indication is a non-SDT configuration ignore indication or a cell group configuration (CellGroupConfig) ignore indication.

[0131] In yet other implementations, DU 174 generates a third non-SDT DU configuration as a special non-SDT DU configuration. For example, the special SDT DU configuration is an empty non-SDT DU configuration, which neither (i) includes configuration parameters to expand the first non-SDT DU configuration and / or the second non-SDT DU configuration, nor (ii) includes new configuration parameters not included in the first non-SDT DU configuration and / or the second non-SDT DU configuration. In some such examples, the special non-SDT DU configuration includes a cell group ID and / or an empty IE and / or a configuration parameter that has been configured for UE 102 or sent to UE 102. The empty IE does not include a configuration parameter. In another example, the special non-SDT DU configuration is a zero-length non-SDT DU configuration. In some implementations, at events 438 and 440, CU 172 determines to send the special non-SDT DU configuration to UE 102 via DU 174. In other implementations, the CU 172 determines to ignore or discard the special non-SDT DU configuration. Therefore, events 438, 440, 441, 442, and 444 are omitted.

[0132] In some implementations, DU 174 determines to use at least one configuration parameter for UE 102 to perform SDT, and the second SDT DU configuration does not support the at least one configuration parameter. In such a case, DU 174 includes at least one configuration parameter in the third non-SDTDU configuration. For example, at least the configuration parameters include RLC bearer configuration parameters, logical channel configuration parameters, MAC configuration parameters, and / or PHY configuration parameters. In some implementations, DU 174 avoids including MAC configuration parameters and / or PHY configuration parameters in the third non-SDT DU configuration.

[0133] In some implementations, the third non-SDT DU configuration includes configuration parameters in a CellGroupConfig IE (e.g., as defined in 3GPP specification 38.331 v17.0.0). In some implementations, the third non-SDT DU configuration is a CellGroupConfig IE including configuration parameters. In some implementations, the RLC bearer configuration parameters are RLC-BearerConfig IE, or include configuration parameters in RLC-BearerConfig IE. In some implementations, the logical channel configuration parameters are LogicalChannelConfig IE, or include configuration parameters in LogicalChannelConfig IE (e.g., logicalChannelGroup, logicalChannelSR-DelayTimerApplied, and logicalChannelSR-Mask). In some implementations, the MAC configuration parameters are MAC-CellGroupConfig IE, or include configuration parameters in MAC-CellGroupConfig IE (e.g., enhancedSkipUplinkTxDynamic, SkipUplinkTxDynamic, enhancedSkipUplinkTxConfigured, buffer status report (BSR) configuration and / or power headroom report (PHR) configuration). In some implementations, the PHY configuration parameters are PhysicalCellGroupConfig IE, or include configuration parameters in PhysicalCellGroupConfig IE (e.g., configured scheduling RNTI (CS-RNTI)).

[0134] In some implementations, DU 174 avoids including a non-SDT DU configuration (e.g., CellGroupConfig IE) in the second DU to CU message. In some implementations, DU 174 includes the first SDT DU configuration in an existing or new IE of the second DU to CU message, rather than in an IE of the second DU to CU message (e.g., DU to CU RRC information IE). The format of the existing or new IE does not include the non-SDT DU configuration (e.g., CellGroupConfig IE) so that DU 174 does not include the non-SDT DU configuration (e.g., CellGroupConfig IE) in the second DU to CU message. In other implementations, when DU 174 determines not to expand the first non-SDT DU configuration and / or the second non-SDT DU configuration or not to transmit new non-SDT configuration parameters to UE 102, DU 174 artificially excludes the non-SDT DU configuration (e.g., CellGroupConfig IE) from the IE of the second DU to CU message (e.g., DU to CU RRC information IE).

[0135] In some implementations, in response to determining to stop the SDT, the CU-CP 172A generates an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to stop the SDT, and keeps the UE 102 in an inactive state. In some implementations, the CU-CP 172A includes the SDT DU configuration and the SDT CU configuration in the RRC release message. Then, the CU-CP 172A transmits 432 a third CU-to-DU message (e.g., a UE context release command message or a UE context modification request message) including the RRC release message to the DU 174. Subsequently, the DU 174 sends 434 the RRC release message to the UE 102. Upon receiving the RRC release message, the UE 102 stops the SDT (i.e., determines that the SDT session or process ends or terminates) and remains in an inactive state. In some implementations, in response to or after stopping the SDT, the UE 102 stops the SDT session timer, stops monitoring the PDCCH for the SDT, and / or releases the C-RNTI used by the UE 102 to monitor the PDCCH for the SDT. Alternatively, the UE 102 retains the C-RNTI. In further implementations, in response to the third CU to DU message, the DU 174 retains the SDT DU configuration and releases or does not release the first non-SDT DU configuration and / or the second non-SDT DU configuration, as described above in conjunction with Figure 3Depending on the implementation, DU 174 transmits 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 transitions to RRC_IDLE and 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 The first SDT DU configuration and / or the first SDT CU configuration described herein).

[0136] Events 420, 421, 422, 423, 424, 426, 428, 430, 438, 440, 442, 444, 432, 434, and 436 are Figure 4 The SDT completion process 494 is collectively referred to as the SDT completion process, which is similar to the process 394. The examples and implementations discussed above for events 320, 321, 322, 323, 324, 326, 328, 330, 338, 340, 342, 344, 332, 334 can be respectively applied to events 420, 421, 422, 423, 424, 426, 428, 430, 438, 440, 442, 444, 432, 434. In some implementations, after stopping the SDT, the UE 102 performs another small data transmission process with the base station 104 or the base station 106 similar to the process 494.

[0137] In some implementations, CU-CP 172A does not request DU 174 to provide an SDT DU configuration to stop SDT and transition UE 102 to an inactive state with configured SDT (e.g., RA-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 a second SDT DU configuration on its own and includes the second SDT DU configuration in the RRC release message.

[0138] In some implementations, DU 174 does not include the SDT DU configuration in the second DU to CU message (e.g., if or because UE 102 does not support CG-SDT, DU 174 does not support CG-SDT, or DU 174 does not have available radio resources for CG-SDT). In some such cases, the RRC release message does not include the SDT DU configuration. Otherwise, DU 174 includes the second SDTDU configuration as described above. In some implementations, DU 174 does not include the CG-SDT configuration in the second 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 second SDT DU configuration does not include the CG-SDT configuration. Otherwise, DU 174 includes at least one CG-SDT configuration in the second SDT DU configuration as described above.

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

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

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

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

[0143] In some implementations, UL data and / or DL ​​data are associated with a radio bearer (e.g., SRB and / or DRB) of UE 102. For example, the UL data includes an RRC message or a NAS message associated with the SRB of UE 102. In another example, the UL data includes an IP packet associated with the 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 the non-SDT indication message of event 503. 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 the data volume information of UL data in the non-SDT indication message. Therefore, CU-CP 172A can determine whether to make UE 102 transition to the connected state based on the data volume information. In some implementations, the data volume information includes the total data volume of UL data. For example, in some implementations, UE 102 quantizes or rounds the total data volume to the value included in the data volume information by UE 102. In another implementation, the data volume information includes the data volume for each radio bearer in the radio bearer. For example, in a further implementation, UE 102 quantizes or rounds the data volume for each radio bearer in the radio bearer to the value included in the data volume information by UE 102. In some implementations and / or scenarios, if the total data volume is higher than a predetermined threshold, CU-CP 172A determines to make UE 102 transition to the connected state. Otherwise, in a further implementation, CU-CP 172A determines not to make UE 102 transition to the connected state. In another example, if the amount of data for a particular radio bearer is higher than a predetermined threshold, the CU-CP 172A determines to transition the UE 102 to the connected state. Otherwise, in a further example, the CU-CP 172A determines not to transition the UE 102 to the connected state. In yet another example, if the total amount of data is higher than a predetermined threshold and the amount of data for a particular radio bearer is higher than another predetermined threshold, the CU-CP 172A determines to transition the UE 102 to the connected state. Otherwise, in a further example, the CU-CP 172A determines not to transition the UE 102 to the connected state.

[0144] After determining to transition UE 102 to a connected state (e.g., in response thereto), 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 resume message to UE 102. Depending on the implementation, the PDU is a MAC PDU or an RLC PDU. In some implementations, the CU to DU message is a DL RRC messaging message or a UE context modification request message. In a further implementation, in the case of 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 resume message, UE 102 transitions 548 to a connected state and sends 550 an RRC resume 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 resume message. DU 174 sends 552 a DU to CU message including an RRC resume completion message to CU-CP 172A. In some implementations, the DU to CU message is a UL RRC messaging message, a UE CONTEXT MODIFICATION REQUIRED message, or a UE CONTEXT MODIFICATION RESPONSE message.

[0145] In some implementations, the UE 102 stops the SDT (e.g., determines that the SDT session or process ends or terminates) in response to receiving an RRC recovery message or transitioning to a connected state. In some implementations, the UE 102 stops the SDT session timer in response to receiving an RRC recovery message or transitioning to a connected state. In the case where the UE 102 is configured with a CG-SDT configuration as described above, the UE 102 stops using the CG-SDT configuration to send UL data in response to receiving an RRC recovery message or transitioning to a connected state. In response to stopping using the CG-SDT configuration, the UE 102 (e.g., PHY 202B or MAC 204B) clears any configured authorization configured in the CG-SDT configuration. In the case where the UE 102 is configured with a CS-RNTI for CG-SDT as described above, the UE 102 (e.g., PHY 202B) stops using the CS-RNTI to monitor the PDCCH in response to receiving an RRC recovery message or transitioning to a connected state. In some implementations, the UE 102 retains the C-RNTI in response to transitioning to a connected state or receiving an RRC resume message. The UE 102 in the connected state uses the C-RNTI to communicate with the DU 174. In some implementations, the UE 102 uses the C-RNTI in a small data communication 592 similar to process 492. The UE 102 receives the C-RNTI, such as for Figure 3 and Figure 4 described.

[0146] In some implementations, after determining to transition UE 102 to a connected state, CU-CP 172A sends 554 a bearer context request message (e.g., a bearer context setup request message or a bearer context modification request message) to CU-UP 172B to indicate that CU-UP 172B is 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 for 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).

[0147] In some implementations, the CU-CP 172A sends 554 a bearer context request message after sending 508 a UE context request message, after receiving 510 a UE context response message, after sending 545 a CU to DU message, and / or after receiving 552 a DU-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.

[0148] In some implementations, CU-CP 172A includes an indication of generating a non-SDT configuration for DU 174 in a UE context request message of event 508, and DU 174 includes the first non-SDT DU configuration in a UE context response message of event 510 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. In some such implementations, UE 102 also stores 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. Some examples and implementations of the first non-SDT DU configuration and the second non-SDT DU configuration include any of the example non-SDT DU configurations described above. In some implementations, DU 174 sends an additional DU-to-CU message (e.g., a 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 of event 510.

[0149] After transitioning 548 to the connected state, the UE 102 communicates 518 UL data and / or DL ​​data with the CU-CP 172A and / or CU-UP 172B via the DU 174. More specifically, in some implementations, the UE 102 sends 518 a UL MAC PDU including UL data to the DU 174 using a UL grant (i.e., a dynamic grant). The DU 174 receives 518 the UL MAC PDU from the UE 102 according to the UL grant. Then, the DU 174 retrieves the UL data from the UL MAC PDU. In some implementations, the UE 102 (at event 518) receives DCIs from the DU 174, each DCI including a specific UL grant in the UL grant. In order to send each of the DCIs to the UE 102, the DU 174 generates a CRC for the DCI, scrambles the CRC using the ID of the UE 102 (i.e., the C-RNTI), and sends the DCI and the scrambled CRC on the PDCCH. UE 102 receives the DCI and the scrambled CRC on the PDCCH and sends a UL MAC PDU to DU 174 according to the DCI, similar to event 418 .

[0150] In the case where DU 174 receives DL data from CU-CP 172A or CU-UP 172B, DU 174 (at event 518) sends one or more DL MAC PDUs including DL data to UE 102 operating in a connected state. In some implementations, DU 174 (at event 518) sends the DL MAC PDU to UE 102 using the DL assignment. UE 102 receives the DL MAC PDU from DU 174 according to the DL assignment. Then, UE 102 retrieves the DL data from the DL MAC PDU. In some implementations, UE 102 (at event 518) receives DCI from DU 174, each DCI including a specific DL assignment in the DL assignment. In order to send each of the DCIs to UE 102, DU 174 generates a CRC for the DCI, scrambles the CRC using the ID of UE 102 (e.g., C-RNTI), and sends the DCI and the scrambled CRC on the PDCCH. The UE 102 receives the DCI and the scrambled CRC on the PDCCH. The UE 102 receives the DL transmission from the DU 174 and obtains the DL MAC PDU from the DL transmission.

[0151] In some implementations, DU 174 uses a different PDCCH configuration for the PDCCH at event 518 than the PDCCH configuration used for the PDCCH at event 418. In other implementations, DU 174 uses the same PDCCH configuration for the PDCCH at event 518 as the PDCCH configuration used for the PDCCH at event 404 or 418. The PDCCH configuration includes a control resource set (CORESET) configuration and / or a search space configuration. In some implementations, the RRC recovery message of event 546 includes the PDCCH configuration. In some implementations, DU 174 includes the PDCCH configuration in the UE context response message of event 510, and CU-CP 172A includes the PDCCH configuration in the RRC recovery message. In other implementations, UE 102 receives the PDCCH configuration from base station 104 before initiating SDT.

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

[0153] In some implementations, the DL data includes DL data received by CU 172 from CN 110, as described above. In further implementations, the DL data also includes new DL data received by CU-CP 172A and / or CU-UP 172B from CN 110. The DL data includes DL data packets, such as NAS PDUs, LTE Positioning Protocol (LPP) PDUs, IP packets, or Ethernet packets. For NAS PDUs, CU-CP 172A receives NAS PDUs from CN 110 (e.g., AMF 164) and generates RRC PDUs, each of which includes a specific NAS PDU in the NAS PDU. In the case of LPP PDUs, CU-CP 172A receives LPP PDUs from CN 110 (e.g., location management function (LMF)) and generates RRC PDUs, each of which includes a specific LPP PDU in the LPP 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. For 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 PDCP PDU including a specific DL data packet in the DL data packet. In some implementations, CU-UP 172B applies one or more security functions (e.g., encryption and / or integrity protection) to the DL data packet, as described above. UE 102 applies one or more security functions (e.g., decryption and / or integrity protection check) to the DL data packet, as described above.

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

[0155] 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 cases, the RRC recovery message of event 545 and / or 546 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.

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

[0157] In other implementations, the UE 102 retains the SDT configuration (e.g., SDT CU configuration, SDT DU configuration, and / or CG-SDT configuration) in response to receiving an RRC recovery message or transitioning to a connected state or after the reception. In some implementations, the UE 102 avoids using the SDT configuration to communicate with the base station 104 when operating in a connected state (e.g., communicating 550RRC recovery complete message and / or communicating 518 data). In other implementations, the UE 102 uses the SDT configuration to communicate with the base station 104 when operating in a connected state (e.g., communicating 550RRC recovery complete message and / or communicating 518 data). In some implementations, the base station 104 retains the SDT configuration in response to transitioning the UE 102 to a connected state or sending an RRC recovery message or after the transition or the sending. In some implementations, the base station 104 avoids using the SDT configuration to communicate with the UE 102 operating in a connected state (e.g., communicating 550RRC recovery complete message 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., communicate 550 an RRC recovery complete message and / or communicate 518 data).

[0158] In some implementations, the UE 102 discards the UE inactive AS context in response to causing the UE 102 to transition to a connected state or sending an RRC resume message or after the transition or the sending. In some implementations, the UE 102 releases one or more configuration parameters other than the RAN notification area information (e.g., RAN-NotificationAreaInfo) in a suspension configuration (e.g., SuspendConfig). In further implementations, the UE 102 receives a suspension configuration in an RRC release message from the base station 104 before performing 592 the process, similar to event 334 or 434.

[0159] In some implementations, the non-SDT indication message of event 503 is an RRC message (e.g., a UEAssistanceInformation message or a new / dedicated RRC message). In some such cases, UE 102 continues to perform small data communication with base station 104 after sending the non-SDT indication message. In some implementations, UE 102 sends 503 a UL MAC PDU including a non-SDT indication message to CU-CP 172A via DU174. In some implementations, UE 102 includes data in the UL MAC PDU in addition to the non-SDT indication message. In other implementations, the UE avoids including data in the UL MAC PDU. In some implementations, UE 102 sends a non-SDT indication message to CU-CP 172A via DU 174 and SRB1.

[0160] To send 503 the non-SDT indication message, UE 102 generates a UL PDCP PDU including the non-SDT indication message, generates a UL RLC PDU including the UL PDCP PDU, generates a UL MAC PDU including the UL RLC PDU, and sends 503 the UL MAC PDU to DU 174 using the CG configuration and / or UL grant (i.e., dynamic grant). DU 174 receives the UL MAC PDU according to the CG configuration and / or the UL grant. Then, DU 174 retrieves the UL RLC PDU from the UL MAC PDU, retrieves the UL PDCP PDU from the UL RLC PDU, and sends the UL PDCP PDU to CU-CP 172A at event 505. CU-CP 172A retrieves the non-SDT indication message from the UL PDCP PDU. In some implementations, UE 102 receives a DCI including the UL grant from DU 174. To send the DCI to the UE 102, the DU 174 generates a CRC for the DCI, scrambles the CRC with the ID of the UE 102 (e.g., C-RNTI or CS-RNTI), and sends the DCI and the scrambled CRC on the PDCCH. In some implementations, if the DU 174 fails to obtain the UL MAC PDU at event 503, the DU 174 commands the UE 102 to resend the UL MAC PDU. More specifically, in some such implementations, the DU 174 generates a DCI including a UL grant (i.e., a dynamic grant), generates a CRC for the DCI, scrambles the CRC with the ID of the UE 102, and sends the DCI and the scrambled CRC on the PDCCH to command the UE 102 to resend the UL MAC PDU. The UE 102 receives the DCI and the scrambled CRC from the DU 174 on the PDCCH, and resends the UL MAC PDU to the DU 174 according to the UL grant or the DCI. In a further implementation, if the DU 174 fails to obtain the UL MAC PDU from the retransmission of the UL MAC PDU, the DU 174 again commands the UE 102 to retransmit the UL MAC PDU in a manner similar to that described above.

[0161] To send 545 the RRC recovery message to DU 174, CU-CP 172A generates a DL PDCP PDU including the RRC recovery message and includes the DL PDCP PDU in the CU-to-DU message of event 545. DU 174 generates a DL RLC PDU including the DL PDCP PDU, generates a DL MAC PDU including the DL RLC PDU, and sends 546 the DL MAC PDU to UE 102 using the DL assignment. UE 102 receives the DL MAC PDU according to the DL assignment. In turn, UE 102 retrieves the DL RLC PDU from the DL MAC PDU, retrieves the DL PDCP PDU from the DL RLC PDU, and sends the UL PDCP PDU to CU-CP 172A. In some implementations, UE 102 receives a DCI including the DL assignment from DU 174. To send the DCI to the UE 102, the DU 174 generates a CRC for the DCI, scrambles the CRC with the ID (e.g., C-RNTI) of the UE 102, and sends the DCI and the scrambled CRC on the PDCCH. In some implementations, if the UE 102 fails to obtain the DL MAC PDU at event 546, the UE 102 sends a HARQ NACK to the DU 174. In further implementations, in response to or after receiving the HARQ NACK, the DU 174 resends the DL MAC PDU to the UE 102. More specifically, the DU 174 generates a DCI including a DL assignment, generates a CRC for the DCI, scrambles the CRC with the ID of the UE 102, and sends the DCI and the scrambled CRC on the PDCCH to command the UE 102 to resend the DL MAC PDU. UE 102 receives DCI and the scrambled CRC from DU 174 on the PDCCH, and receives a retransmission of the DL MAC PDU from DU 174 according to the DL assignment or DCI. If UE 102 successfully obtains the DL MAC PDU from the retransmission of the DL MAC PDU, UE 102 sends a HARQ ACK to DU 174. Otherwise, in some implementations, if UE 102 fails to obtain the DL MAC PDU from the retransmission of the DL MAC PDU, UE 102 sends a HARQ ACK to DU 174. Then, in further implementations, DU 174 retransmits the DL MAC PDU to UE 102 in a manner similar to that described above.

[0162] To send 550 the RRC recovery complete message, UE 102 generates an UL PDCP PDU including the RRC recovery complete message, generates an UL RLC PDU including the UL PDCP PDU, generates an UL MAC PDU including the UL RLC PDU, and sends 550 the UL MAC PDU to DU 174 using an UL grant (i.e., a dynamic grant). DU 174 receives the UL MAC PDU according to the UL grant. Then, DU 174 retrieves the UL RLC PDU from the UL MAC PDU, retrieves the UL PDCP PDU from the UL RLC PDU, and sends the UL PDCP PDU to CU-CP 172A at event 505. CU-CP 172A retrieves the RRC recovery complete message from the UL PDCP PDU. In some implementations, UE 102 receives a DCI including an UL grant from DU 174. To send the DCI to the UE 102, the DU 174 generates a CRC for the DCI, scrambles the CRC using the ID (i.e., C-RNTI) of the UE 102, and sends the DCI and the scrambled CRC on the PDCCH. In some implementations, if the DU 174 fails to obtain the UL MAC PDU at event 503, the DU 174 commands the UE 102 to resend the UL MAC PDU. More specifically, in a further implementation, the DU 174 generates a DCI including a UL grant (i.e., a dynamic grant), generates a CRC for the DCI, scrambles the CRC using the ID of the UE 102, and sends the DCI and the scrambled CRC on the PDCCH to command the UE 102 to resend the UL MAC PDU. The UE 102 receives the DCI and the scrambled CRC from the DU 174 on the PDCCH, and resends the UL MAC PDU to the DU 174 according to the UL grant or the DCI. In a further implementation, if the DU 174 fails to obtain the UL MAC PDU from the retransmission of the UL MAC PDU, the DU 174 again commands the UE 102 to retransmit the UL MAC PDU in a manner similar to that described above.

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

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

[0165] Similarly, depending on the implementation, the DU 174 runs a first DUCG-SDT timer for the UE 102 operating 502 in the inactive state, such as for Figure 3 and Figure 4 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, DU 174 maintains (e.g., keeps or does not stop, start or restart) the first DU CG-SDT timer to run 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 the reception or the transmission. In other implementations, DU 174 stops the first DU CG-SDT timer in response to receiving 508 to a UE context request message, sending 510 to a UE context response message, or sending 545 to an RRC recovery message, or after the reception or the transmission. In some cases where the first DU CG-SDT timer expires, DU 174 releases the CG-SDT configuration. In other cases where the first DU CG-SDT timer expires, DU 174 alternatively retains the CG-SDT configuration and avoids receiving or attempting to receive UL transmissions (e.g., MAC PDUs) on CG resources. In some cases, the DU 174 releases the CG resources or determines the CG resources as invalid.

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

[0167] Similarly, depending on the implementation, DU 174 runs a second DU CG-SDT timer during the 592 small data communication process. In some implementations, when receiving a PUSCH transmission on the radio resources configured in the CG-SDT configuration from UE 102 or after the reception, DU 174 starts or restarts the second DU CG-SDT timer. In some implementations, when 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, DU 174 stops the second DU CG-SDT timer in response to receiving 508 to the UE context request message, sending 510 UE context response message, or sending 546 RRC recovery message or after the reception or the transmission. In other implementations, DU 174 maintains the second DU CG-SDT timer in response to receiving 508 to the UE context request message, sending 510 UE context response message, or sending 546 RRC recovery message or after the reception or the transmission. The DU 174 sends DCI and / or PDCCH to the UE 102 operating in the connected state using the C-RNTI regardless of whether the second DU CG-SDT timer (eg, running, expired, or stopped).

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

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

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

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

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

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

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

[0175] Next, refer to FIG. 6A to FIG. 16, discusses several example methods that can be implemented in a UE, in one or more base stations, DUs or CUs, or in a RAN to support data communications in an inactive state. Figure 3 , Figure 4 and FIG. 5A to FIG. 5B The examples and implementations described may be applicable to FIG. 6A to FIG. 16 .

[0176] Fig. 6A A method 600A implemented by a UE (eg, UE 102) for performing small data communication with a RAN (eg, RAN 105 or base stations 104, 106) is illustrated.

[0177] Method 600A begins at block 602, where a UE communicates with a RAN (eg, Figures 3 to 5B At block 604, the UE receives at least one first RRC message (e.g., Figures 3 to 5B At block 606, the UE receives a second RRC message (e.g., Figures 3 to 5B At block 608, the UE receives an RRC release message (e.g., Figures 3 to 5B At block 610, the UE performs data communications with the RAN using the UE's C-RNTI, SDT configuration parameters, CS-RNTI, and non-SDT configuration parameters (e.g., Figures 3 to 5B Events 404, 418, 492, 420, 440, 434, 592, 546).

[0178] In some implementations, the SDT configuration parameters include configuration parameters for SDT (e.g., CG-SDT and / or RA-SDT), as described above. In some implementations, the non-SDT configuration parameters include configuration parameters for non-SDT processes, as described above. In some implementations, at least one first RRC message includes a second RRC message, an RRC reconfiguration message, and / or an RRC recovery message. In some implementations, the second RRC message is an RRC reconfiguration message or an RRC recovery message. In some implementations, the second RRC message does not include a CG configuration. In some implementations, the RRC release message does not include a CS-RNTI.

[0179] Figure 6B 6 is a flow chart of an example method 600B similar to method 600A, except that method 600B includes blocks 603 and 609 instead of blocks 606 and 608. At block 603, the UE sends a first capability to the RAN indicating support for receiving a CS-RNTI included in an RRC release message. At block 609, the UE receives an RRC release message (e.g., Figures 3 to 5B Events 334, 434, 494, 594, 595).

[0180] In some implementations, the RAN determines to include the CS-RNTI in the RRC release message based on the first capability. If the UE does not send the first capability to the RAN, the RAN sends a second RRC message including the CS-RNTI to the UE, such as for Fig. 6A As described in block 606 of .

[0181] Figure 7 A method 700 implemented by a UE (eg, UE 102) for performing small data communications with a RAN (eg, RAN 105 or base stations 104, 106) is illustrated.

[0182] Method 700 begins at block 702, where a UE communicates with a RAN (e.g., Figures 3 to 5B At block 704, the UE receives at least one first RRC message (e.g., Figures 3 to 5BAt block 706, the UE receives an RRC release message (e.g., Figures 3 to 5B At block 708, the UE determines whether the RRC release message includes a CS-RNTI for SDT. If the UE determines that the RRC release message includes a CS-RNTI for SDT, the process proceeds to block 710. At block 710, the UE performs small data communications (e.g., Figure 4 If the UE determines that the RRC release message does not include a CS-RNTI for SDT, the flow proceeds to block 712. At block 712, the UE performs small data communications with the RAN using the SDT configuration parameters, the non-SDT configuration parameters, and the CS-RNTI that the UE received from the RAN in the RRC reconfiguration message (e.g., Figures 3 to 5B Events 312, 390, 340, 440, 546, 590, 404, 418, 492, 420, 440, 434).

[0183] Figure 8 A method 800 implemented by a UE (eg, UE 102) for performing small data communications with a RAN (eg, RAN 105 or base stations 104, 106) is illustrated.

[0184] Method 800 begins at block 802, where a UE communicates with a RAN (e.g., Figures 3 to 5B At block 804, the UE receives a first RRC message (e.g., Figures 3 to 5B At block 806, the UE receives an RRC release message (e.g., Figures 3 to 5BAt block 808, the UE determines whether the RRC release message configures CG-SDT. If the UE determines that the RRC release message configures CG-SDT, the process proceeds to block 810. At block 810, the UE retains the CS-RNTI. If the UE determines that the RRC release message does not configure CG-SDT, the process proceeds to block 812. At block 812, the UE releases the CS-RNTI.

[0185] In some implementations, the first RRC message is an RRC reconfiguration message, and the UE sends an RRC reconfiguration complete message to the RAN in response to the RRC reconfiguration message. In other implementations, the first RRC message is an RRC recovery message, and the UE sends an RRC recovery complete message to the RAN in response to the RRC recovery message.

[0186] In some implementations, the UE stores the CS-RNTI for CG-SDT in the UE inactive AS context upon or in response to receiving an RRC release message. In some implementations, the UE recovers the CS-RNTI when the UE initiates a CG-SDT procedure. In some implementations, the UE begins using the CS-RNTI to monitor the PDCCH in response to or after initiating a CG-SDT procedure to the RAN. In some implementations, the UE begins using the CS-RNTI when sending an initial SDT transmission (e.g., Figure 4 Event 404 of 405) starts to use CS-RNTI to monitor PDCCH. In some implementations, when UE uses CS-RNTI to monitor PDCCH, UE monitors PDCCH addressed to CS-RNTI. In some scenarios or implementations, when using CS-RNTI to monitor PDCCH or during this monitoring, UE receives DCI and CRC scrambled with CS-RNTI on PDCCH. UE uses CS-RNTI to verify whether CRC is valid. In some implementations, if UE verifies that CRC is valid and DCI includes UL grant, UE sends UL transmission to RAN using UL grant. In some implementations, UL transmission is a new transmission. In other implementations, UL transmission is a retransmission. In some implementations, if UE verifies that CRC is valid and DCI includes DL assignment, UE receives DL transmission from RAN using DL assignment.

[0187] In some implementations, when the UE stops or completes the CG-SDT process or at the time of stopping or completing (e.g., Figures 4 to 5BAfter events 403, 434, 494, 594, 595 of the RRC_RESUME message, the UE stops using the CS-RNTI to monitor the PDCCH. In some implementations, the UE responds to receiving an RRC_RESUME message (e.g., FIG. 5A to FIG. 5B event 546), RRC setup message or transition to connected state (e.g., FIG. 5A to FIG. 5B The CG-SDT process is stopped in response to event 548 of the RRC rejection message. In other implementations, the UE stops the CG-SDT process in response to receiving the RRC rejection message.

[0188] Fig. 9 A method 900 implemented by a UE (eg, UE 102) for performing small data communications with a RAN (eg, RAN 105 or base stations 104, 106) is illustrated.

[0189] Method 900 begins at block 902, where a UE communicates with a RAN (e.g., Figures 3 to 5B At block 904, the UE receives an RRC message (e.g., Figures 3 to 5B At box 906, the UE determines whether the RRC message includes the configured authorization configuration. If the UE determines that the RRC message includes the configured authorization configuration, the process proceeds to box 908. At box 908, the UE starts to monitor the PDCCH using the CS-RNTI. If the UE determines that the RRC message does not include the configured authorization configuration, the process proceeds to box 910. At box 910, the UE avoids monitoring the CS-RNTI on the PDCCH until the CG-SDT is performed.

[0190] In some implementations, the RRC message is an RRC reconfiguration message. In other implementations, the RRC message is an RRC recovery message. The UE begins to monitor the PDCCH using the CS-RNTI in response to initiating a CG-SDT or after the initiation. In some scenarios or implementations, when the CS-RNTI is used to monitor the PDCCH or during the monitoring, the UE receives the DCI and the CRC scrambled with the CS-RNTI on the PDCCH. The UE uses the CS-RNTI to verify whether the CRC is valid. In some implementations, if the UE verifies that the CRC is valid and the DCI includes a UL grant, the UE sends an UL transmission to the RAN using the UL grant. In some implementations, the UL transmission is a new transmission. In other implementations, the UL transmission is a retransmission. In some implementations, if the UE verifies that the CRC is valid and the DCI includes a DL assignment, the UE receives a DL transmission from the RAN using the DL assignment.

[0191] Fig. 10A A method 1000A implemented by a UE (eg, UE 102) for performing small data communication with a RAN (eg, RAN 105 or base stations 104, 106) is illustrated.

[0192] Method 1000A begins at block 1002, where the UE performs SDT with the RAN while operating in an inactive state (e.g., Figures 4 to 5B At block 1004, the UE uses the C-RNTI to monitor the PDCCH during the SDT. At block 1006, the UE receives an RRC resume message (e.g., FIG. 5A to FIG. 5B At block 1008, the UE stops SDT and transitions to a connected state (e.g., FIG. 5A to FIG. 5B Event 548). At block 1010, the UE continues to use the C-RNTI to monitor the PDCCH after transitioning to the connected state. In other words, the UE in the connected state uses the C-RNTI to perform data communications with the RAN (e.g., FIG. 5A to FIG. 5B Events 550, 518).

[0193] In some implementations, the UE starts an SDT session timer for the SDT in response to or after initiating the SDT. The UE stops the SDT session timer in response to or after receiving the RRC resume message.

[0194] In some implementations, a UE in a connected state sends an RRC recovery complete message to the RAN in response to an RRC recovery message. In some implementations, the SDT is a CG-SDT or a RA-SDT. In some implementations, the UE operates in a connected state and receives a C-RNTI in a first RRC message (e.g., an RRC reconfiguration message or an RRC recovery message) from the RAN before performing the SDT. In some implementations, the UE sends a first RRC response message (e.g., an RRC reconfiguration complete message or an RRC recovery complete message) to the RAN in response to the first RRC message. In other implementations, the UE performs a random access procedure with the RAN to initiate the SDT (i.e., RA-SDT) and receives the C-RNTI in a random access response in the random access procedure.

[0195] For CG-SDT, a UE in an inactive state uses C-RNTI and CS-RNTI to monitor PDCCH during CG-SDT. In some implementations, the UE receives a second RRC message including CS-RNTI from the RAN before performing SDT. In some implementations, the second RRC message is an RRC reconfiguration message, and the UE in a connected state sends an RRC reconfiguration complete message to the RAN in response to the RRC reconfiguration message. In other implementations, the second RRC message is an RRC recovery message, and the UE sends an RRC recovery complete message to the RAN in response to the RRC recovery message. In yet other implementations, the second RRC message is an RRC release message.

[0196] In some implementations, when or while monitoring the PDCCH using the C-RNTI, the UE receives the DCI on the PDCCH and the CRC scrambled with the C-RNTI. The UE uses the C-RNTI to verify whether the CRC is correct. In some implementations, if the UE verifies that the CRC is correct and the DCI includes a UL grant, the UE sends an UL transmission to the RAN using the UL grant. In some implementations, the UL transmission is a new transmission. In other implementations, the UL transmission is a retransmission. In some implementations, if the UE verifies that the CRC is correct and the DCI includes a DL assignment, the UE receives a DL transmission from the RAN using the DL assignment.

[0197] In some implementations, when the CS-RNTI is used to monitor the PDCCH during the CG-SDT or when monitoring, the UE in an inactive state receives the DCI and the CRC scrambled with the CS-RNTI on the PDCCH. The UE uses the CS-RNTI to verify whether the CRC is correct. In some implementations, if the UE verifies that the CRC is correct and the DCI includes a UL grant, the UE sends a UL transmission to the RAN using the UL grant. In some implementations, the UL transmission is a new transmission. In other implementations, the UL transmission is a retransmission.

[0198] Fig. 10B is a flow chart of an example method 1000B that is similar to method 1000A, except that method 1000B includes block 1007 instead of block 1006. At block 1007, the UE receives an RRC setup message from the RAN during the SDT.

[0199] In some implementations, the UE starts an SDT session timer for the SDT in response to or after initiating the SDT. The UE stops the SDT session timer in response to or after receiving the RRC setup message.

[0200] In some implementations, the UE in the connected state sends an RRC setup complete message to the RAN in response to the RRC setup message. In some implementations, the UE includes the service request message in the RRC setup complete message. Then, the UE in the connected state performs a security mode procedure and an RRC reconfiguration procedure with the RAN to activate security protection and establish SRB2 and / or DRB with the RAN, respectively. As a result of the security mode procedure, the UE and the RAN generate new security keys. Then, the UE in the connected state communicates data with the RAN via SRB1, SRB2 or DRB.

[0201] In some implementations, the new security key includes an encryption key and an integrity key. In one implementation, the encryption key includes an encryption key for RRC and / or an encryption key for user plane data, and the integrity key includes an integrity key for RRC. The UE performs an integrity protection operation on data sent by the UE to the RAN using the integrity key, and performs an integrity check on data received by the UE from the RAN. The UE encrypts data sent by the UE to the RAN using the encryption key, and decrypts data received by the UE from the RAN.

[0202] Fig.11 A method 1100 implemented by a UE (eg, UE 102) for performing small data communications with a RAN (eg, RAN 105 or base stations 104, 106) is illustrated.

[0203] Method 1100 begins at block 1102, where the UE performs SDT with the RAN while operating in an inactive state (e.g., Figures 4 to 5B At block 1104, the UE uses the C-RNTI to monitor the PDCCH during the SDT. At block 1106, the UE receives a first RRC message (e.g., Figures 4 to 5B Events 434, 546 of the first RRC message). At block 1108, the UE determines whether the first RRC message causes the UE to transition to a connected state. If the UE determines that the first RRC message causes the UE to transition to a connected state, the process proceeds to block 1110. At block 1110, the UE transitions to connected and continues to use the C-RNTI to monitor the PDCCH. In other words, the UE in the connected state performs data communication with the RAN using the C-RNTI in response to the first RRC message or after receiving the first RRC message (e.g., FIG. 5A to FIG. 5B Events 550, 518).

[0204] Otherwise, if the UE determines that the first RRC message does not cause the UE to transition to a connected state, flow proceeds to block 1112. At block 1112, the UE stops the SDT and stops monitoring the PDCCH using the C-RNTI in response to the first RRC message.

[0205] In the case where the first RRC message transitions the UE to the connected state, the UE stops the SDT, transitions to the connected state, and sends a first RRC response message to the RAN node in response to the first RRC message. In some implementations, the first RRC message and the first RRC response message are an RRC recovery message and an RRC recovery complete message, respectively. In other implementations, the first RRC message and the first RRC response message are an RRC setup message and an RRC setup complete message, respectively. In the case where the first RRC message does not transition the UE to the connected state, the first RRC message is an RRC release message (e.g., Figure 4 The UE stops SDT in response to receiving the first RRC message or after the reception and remains in an inactive state.

[0206] In some implementations, the UE starts an SDT session timer for SDT in response to performing SDT (e.g., initiating SDT or sending a UL RRC message for initiating SDT, similar to event 404). The UE stops the SDT session timer in response to receiving the first RRC message or after the reception.

[0207] In some implementations, the SDT is a CG-SDT or a RA-SDT. In some implementations, the UE receives a C-RNTI in a second RRC message (e.g., an RRC reconfiguration message or an RRC recovery message) from the RAN before initiating the SDT. In further implementations, the UE sends a second RRC response message (e.g., an RRC reconfiguration complete message or an RRC recovery complete message) to the RAN in response to the second RRC message. In other implementations, the UE performs a random access procedure to initiate the SDT (i.e., RA-SDT) and receives the C-RNTI in a random access response of the random access procedure.

[0208] For CG-SDT, the UE uses C-RNTI and CS-RNTI to monitor PDCCH during CG-SDT. In some implementations, the UE receives a third RRC message including CS-RNTI from the RAN before initiating CG-SDT. In some implementations, the third RRC message is an RRC reconfiguration message, and in response, the UE sends an RRC reconfiguration complete message to the RAN. In other implementations, the third RRC message is an RRC recovery message, and in response, the UE sends an RRC recovery complete message to the RAN. In yet other implementations, the third RRC message is an RRC release message.

[0209] In some scenarios or implementations, when or while monitoring the PDCCH using the C-RNTI, the UE receives the DCI on the PDCCH and the CRC scrambled with the C-RNTI. The UE uses the C-RNTI to verify whether the CRC is correct. In some implementations, if the UE verifies that the CRC is correct and the DCI includes a UL grant, the UE sends an UL transmission to the RAN using the UL grant. In some implementations, the UL transmission is a new transmission. In other implementations, the UL transmission is a retransmission. In some implementations, if the UE verifies that the CRC is correct and the DCI includes a DL assignment, the UE receives a DL transmission from the RAN using the DL assignment.

[0210] In some implementations, when monitoring the PDCCH using the CS-RNTI during the CG-SDT or while monitoring, the UE receives the DCI and the CRC scrambled with the CS-RNTI on the PDCCH. The UE uses the CS-RNTI to verify whether the CRC is correct. In some implementations, if the UE verifies that the CRC is correct and the DCI includes a UL grant, the UE sends a UL transmission to the RAN using the UL grant. In some implementations, the UL transmission is a new transmission. In other implementations, the UL transmission is a retransmission.

[0211] against Fig. 10A and Fig. 10B The examples and implementations described may be applicable to Fig.11 .

[0212] Fig. 12A A method 1200A implemented by a RAN node (eg, DU 174 or base station 104, 106) for performing data communication with a UE (eg, UE 102) via a CU (eg, CU 172 or CU-CP 172A) is illustrated.

[0213] Method 1200A begins at block 1202, where a RAN node communicates with a UE (e.g., Figures 3 to 5B At block 1204, the RAN node sends at least one first RRC message including non-SDT configuration parameters to the UE (e.g., events 312, 390, 340, 440, 546, 590). At block 1206, the RAN node sends a second RRC message including a CS-RNTI to the UE (e.g., events 304, 306, 318, 310, 312, 316, 314, 318, 390, 320, 321, 322, 404, 406, 408, 410, 415, 416, 418, 494, 420, 421, 422, 503, 592, 546, 550, 518, 588, 590). Figures 3 to 5B At block 1208, the RAN node sends an RRC release message (e.g., Figures 3 to 5B At block 1210, the RAN node performs data communication with the UE operating in the inactive state using the UE's C-RNTI, SDT configuration parameters, CS-RNTI and non-SDT configuration parameters (e.g., Figures 3 to 5B Events 404, 418, 492, 420, 440, 434, 592, 546).

[0214] In some implementations, the SDT configuration parameters include configuration parameters for SDT (e.g., CG-SDT and / or RA-SDT), as described above. In some implementations, the non-SDT configuration parameters include configuration parameters for non-SDT, as described above. In some implementations, at least one first RRC message includes a second RRC message, an RRC reconfiguration message, and / or an RRC recovery message. In some implementations, the second RRC message is an RRC reconfiguration message or an RRC recovery message. In some implementations, the second RRC message does not include a CG configuration. In some implementations, the RRC release message does not include a CS-RNTI.

[0215] Fig. 12B12 is a flow chart of an example method 1200B that is similar to method 1200A, except that method 1200B includes blocks 1203 and 1209 instead of blocks 1206 and 1208. At block 1203, the RAN node receives a first capability from the UE, the second RAN node, or the CN indicating support for receiving a CS-RNTI included in an RRC release message. At block 1209, the RAN node sends an RRC release message (e.g., Figures 3 to 5B Events 334, 434, 494, 594, 595).

[0216] In some implementations, the RAN determines to include the CS-RNTI in the RRC release message based on the first capability. If the UE does not send the first capability to the RAN, the RAN sends a second RRC message including the CS-RNTI to the UE, such as for Fig. 12A As described in box 1206 of .

[0217] Fig. 12C 1200C is a flow chart of an example method 1200C that is similar to methods 1200A and 1200B, except that method 1200C includes block 1205 instead of block 1203. At block 1205, the RAN node determines whether the UE supports receiving a CS-RNTI included in an RRC release message. If the RAN node determines that the UE supports receiving a CS-RNTI included in an RRC release message, the flow proceeds to blocks 1206 and 1208. Otherwise, if the RAN node determines that the UE does not support receiving a CS-RNTI included in an RRC release message, the flow proceeds to block 1209. From blocks 1209 and 1208, the flow proceeds to block 1210.

[0218] Fig.13 A method 1300 implemented by a RAN node (eg, DU 174 or base stations 104, 106) for performing data communications with a UE (eg, UE 102) is illustrated.

[0219] Method 1300 begins at block 1302, where a RAN node communicates with a UE (e.g., Figures 3 to 5B At block 1304, the RAN node sends at least one first RRC message (e.g., Figures 3 to 5BAt block 1306, the RAN node sends a second RRC message (e.g., Figures 3 to 5B At block 1308, the RAN node determines to send an RRC release to the UE. At block 1310, the RAN node determines whether to configure CG-SDT for the UE. If the RAN node determines to configure CG-SDT for the UE, the flow proceeds to block 1312. At block 1312, the RAN node sends an RRC release message (e.g., Figures 3 to 5B Events 334, 434, 494, 594, 595 of RRC release message). In some implementations, the RAN node includes the CG-SDT configuration in the RRC release message to configure the CG-SDT. In other implementations, the RAN node does not include the CG-SDT configuration in the RRC release message because the RAN node previously sent another RRC release message including the CG-SDT configuration to the UE. In such cases, the RAN node avoids including the CG-SDT configuration in the RRC release message to indicate reuse of the CG-SDT configuration in the RRC release message. At box 1314, the RAN node retains the CS-RNTI. In some implementations, the RAN node later uses the UE's C-RNTI, CG-SDT configuration parameters, CS-RNTI, and non-SDT configuration parameters to perform data communication with the UE operating in an inactive state (e.g., Figures 3 to 5B Events 404, 418, 492, 420, 440, 434, 592, 546).

[0220] Otherwise, if the RAN node determines to release the CG-SDT or not configure the CG-SDT for the UE, the flow proceeds to block 1316. At block 1316, the RAN node sends an RRC release message to the UE to release or not configure the CG-SDT. At block 1318, the RAN node releases the CS-RNTI.

[0221] In some implementations, at least one first RRC message includes a second RRC message, an RRC reconfiguration and / or an RRC recovery message. In some implementations, the second RRC message is an RRC reconfiguration message. In other implementations, the second RRC message is an RRC recovery message. In some implementations, the CG-SDT configuration includes a configured grant (CG) configuration (e.g., ConfiguredGrantConfig IE). The CG configuration includes configuration parameters to configure a configured grant (e.g., a CG opportunity such as a time slot) that occurs periodically in the time domain. When the UE performs CG-SDT, the UE sends an UL MAC PDU to the RAN node in the time slot according to the configured grant.

[0222] In the case where the RRC release message configures CG-SDT, the RAN node attempts to receive UL transmission from the UE operating in the inactive state in the CG opportunity using the configured grant. If the RAN node receives the UL transmission in the CG opportunity using the configured grant, the RAN node obtains the UL MAC PDU from the UL transmission and retrieves the UL PDCP PDU from the UL MAC PDU. In some implementations, the RAN node retrieves the UL RLC PDU from the UL MAC PDU and retrieves the UL PDCP PDU from the UL RLC PDU. In other implementations, the RAN node retrieves the UL PDCP PDU from the UL MAC PDU. In the case where the RAN node is a DU, the DU sends the UL PDCP PDU to the CU. The CU retrieves UL data from the UL PDCP PDU. In some implementations, the UL MAC PDU includes a logical channel ID for the UL RLC PDU or the UL PDCP PDU, respectively. If the logical channel ID identifies or indicates a common control channel (CCCH) or a dedicated control channel (DCCH), the DU sends the corresponding UL PDCP PDU to the CP of the CU. If the logical channel ID identifies or indicates a dedicated traffic channel (DCCH), the DU sends the corresponding UL PDCP PDU to the UP of the CU.

[0223] Fig.14 A method 1400 implemented by a DU (eg, DU 174) for performing data communications with a UE (eg, UE 102) via a CU (eg, CU 172) is illustrated.

[0224] Method 1400 begins at block 1402, where a DU communicates with a UE and a CU (e.g., Figures 3 to 5BAt block 1404, the DU sends a CS-RNTI and a configured grant (CG) configuration (e.g., Figures 3 to 5B At block 1406, the DU receives a UE context release command message (e.g., Figures 3 to 5B Events 332, 394, 432, 494, 594, 595).

[0225] At box 1408, the DU determines whether the CS-RNTI and CG configuration are configured for CG-SDT. If the DU determines that the CS-RNTI and CG configuration are configured for SDT, the process proceeds to box 1410. At box 1410, the DU retains the CS-RNTI and CG configuration in response to receiving a UE context release command message or after the reception. Otherwise, if the DU determines that the CS-RNTI and / or CG configuration are configured for non-SDT (i.e., data communication in a connected state), the process proceeds to box 1412. At box 1412, the DU releases the CS-RNTI and / or CG configuration in response to receiving a UE context release command message or after the reception. In other words, the DU determines that the CS-RNTI and / or CG configuration is invalid in response to receiving a UE context release command message or after the reception.

[0226] The CG configuration configures a configured grant that occurs periodically in the time domain (e.g., a CG opportunity such as a time slot). In the case where the DU retains the CS-RNTI and CG configuration, in some implementations, the DU attempts to receive UL transmissions from the UE on the radio resources configured in the CG configuration when or after sending the CS-RNTI and CG configuration to the UE or CU. In the case where the DU releases the CS-RNTI and / or CG configuration, the DU avoids receiving UL transmissions from the UE on the radio resources configured in the CG configuration or stops attempting such reception.

[0227] Fig.15A A method 1500A implemented by a RAN node (eg, DU 174 or base stations 104, 106) for performing data communications with a UE (eg, UE 102) is illustrated.

[0228] Method 1500A begins at block 1502, where a RAN node performs SDT with a UE operating in an inactive state (e.g., Figures 4 to 5B At block 1504, the RAN node uses the C-RNTI of the UE to perform data communications with the UE during the SDT (e.g., Figures 4 to 5B At block 1506, the RAN node sends an RRC resume message to the UE to stop SDT (e.g., FIG. 5A to FIG. 5B At block 1508, the RAN node continues to use the C-RNTI to perform data communications with the UE after stopping the SDT (e.g., FIG. 5A to FIG. 5B Events 550, 518).

[0229] In some implementations, the UE stops the SDT in response to the RRC recovery message, transitions to a connected state, and sends an RRC recovery complete message to the RAN node. In some implementations, the RAN node determines that the UE transitions to a connected state in response to receiving the RRC recovery complete message. Therefore, the RAN node uses the C-RNTI to perform data communication with the UE operating in the connected state after stopping the SDT. In the case where the RAN node is a DU, the DU receives a CU-to-DU message (e.g., an F1AP message, such as a DL RRC messaging message) including an RRC recovery message from a CU (e.g., CU 172 or CU-CP 172A), and sends a DU-to-CU message (e.g., an F1AP message, such as an UL RRC messaging message) including an RRC recovery complete message to the CU (as described for events 545 and 552, respectively).

[0230] In some implementations, the RAN node starts an SDT session timer for the SDT in response to performing the SDT (e.g., receiving an UL RRC message for initiating the SDT, similar to event 404). The RAN node stops the SDT session timer in response to sending an RRC resume message or receiving an RRC resume complete message or after the sending or the receiving.

[0231] In some implementations, the SDT is a CG-SDT or a RA-SDT. In some implementations, the RAN node sends a first RRC message (e.g., an RRC reconfiguration message or an RRC recovery message) including a first C-RNTI to the UE before performing the SDT procedure. In further implementations, the UE sends a first RRC response message (e.g., an RRC reconfiguration complete message or an RRC recovery complete message) to the RAN node in response to the first RRC message. In other implementations, the UE performs a random access procedure with the RAN node to initiate the SDT (i.e., RA-SDT). The RAN node sends a random access response including the C-RNTI to the UE in the random access procedure.

[0232] For CG-SDT, the RAN uses the C-RNTI and CS-RNTI of the UE to perform data communication with the UE. The RAN node sends a second RRC message including the CS-RNTI to the UE before performing the CG-SDT. In some implementations, the second RRC message is an RRC reconfiguration message, and in response, the UE sends an RRC reconfiguration complete message to the RAN. In other implementations, the second RRC message is an RRC recovery message, and in response, the UE sends an RRC recovery complete message to the RAN. In yet other implementations, the second RRC message is an RRC release message. In some implementations, the second RRC message includes a CG-SDT configuration that configures CG resources for the CG-SDT. Alternatively, the RAN node sends a third RRC message including the CG-SDT configuration to the UE. In some implementations, the third RRC message is an RRC reconfiguration message, and in response, the UE sends an RRC reconfiguration complete message to the RAN. In other implementations, the third RRC message is an RRC recovery message, and in response, the UE sends an RRC recovery complete message to the RAN. In yet other implementations, the third RRC message is an RRC release message. In some implementations, the RAN node stops using the CS-RNTI to communicate with the UE in response to or after stopping the SDT. In some implementations, the RAN node avoids receiving UL transmissions from the UE on radio resources configured in the CG configuration or stops attempting such reception in response to or after stopping the SDT. In some implementations, the RAN node releases the CG-SDT configuration in response to or after sending an RRC resume message.

[0233] When performing data communication with a UE using C-RNTI, the RAN node generates DCI, generates a CRC for each DCI in the DCI, and scrambles the CRC using the C-RNTI. The RAN node sends the DCI and the scrambled CRC to the UE on the PDCCH during the SDT process. Each DCI in the DCI includes a DL assignment or a UL grant. If the DCI includes a DL assignment, the RAN node sends a DL transmission to the UE according to the DCI or the DL assignment. If the DCI includes a UL assignment, the RAN node receives a UL transmission from the UE according to the DCI or the UL grant.

[0234] When using CS-RNTI to perform data communication with a UE, the RAN node generates DCI, generates a CRC for each DCI in the DCI, and scrambles each CRC with the CS-RNTI. The RAN node sends the DCI and the scrambled CRC to the UE on the PDCCH during the SDT process. Each DCI in the DCI includes a UL grant. The RAN node receives a UL transmission from the UE according to the DCI or the UL grant.

[0235] Fig. 15B is a flow chart of an example method 1500B that is similar to method 1500A, except that method 1500B includes block 1507 instead of block 1506. At block 1507, the RAN node sends an RRC setup message to the UE to stop SDT.

[0236] In some implementations, the UE transitions to a connected state in response to the RRC setup message and sends an RRC setup complete message to the RAN node. In some implementations, the RAN node determines that the UE transitions to a connected state in response to receiving the RRC setup complete message. Therefore, the RAN node uses the C-RNTI to perform data communication with the UE operating in the connected state after stopping the SDT. In the case where the RAN node is a DU, the DU receives a CU-to-DU message (e.g., an F1AP message, such as a DL RRC messaging message) including an RRC setup message from a CU (e.g., CU 172 or CU-CP 172A), and sends a DU-to-CU message (e.g., an F1AP message, such as an UL RRC messaging message) including an RRC setup complete message to the CU (similar to events 545 and 552, respectively).

[0237] In some implementations, the RAN node starts an SDT session timer for the SDT in response to performing the SDT (e.g., receiving an UL RRC message for initiating the SDT, similar to event 404). The RAN node stops the SDT session timer in response to sending an RRC setup message or receiving an RRC setup complete message or after the sending or the receiving.

[0238] In some implementations, the RRC setup complete message includes a service request message, and the RAN node transmits the service request message to the CN (e.g., CN 110 or AMF 164). Then, the RAN performs a security mode procedure and an RRC reconfiguration procedure in a case where the UE operates in a connected state to activate security protection and establish SRB2 and / or DRB for the UE, respectively. As a result of the security mode procedure, the UE and the RAN generate new security keys. Thereafter, the RAN communicates data with the UE operating in a connected state via SRB1, SRB2, or DRB.

[0239] In some implementations, the new security key includes an encryption key and an integrity key. In one implementation, the encryption key includes an encryption key for RRC and / or an encryption key for user plane data, and the integrity key includes an integrity key for RRC. The RAN node uses the integrity key to perform an integrity protection procedure on data sent by the RAN node to the UE, and performs an integrity check on data received by the RAN node from the UE. The RAN node uses the encryption key to encrypt data sent by the RAN node to the UE, and decrypt data received by the RAN node from the UE.

[0240] Fig.16 A method 1600 implemented by a RAN (eg, the RAN 105 or a RAN node such as the base stations 104, 106) for performing small data communications with a UE (eg, the UE 102) is illustrated.

[0241] Method 1600 begins at block 1602, where the RAN performs SDT with a UE operating in an inactive state (e.g., Figures 4 to 5B At block 1604, the RAN node uses the C-RNTI of the UE to perform data communications with the UE during the SDT (e.g., Figures 4 to 5B At block 1606, the RAN node sends a first RRC message to the UE to stop SDT (e.g., Figures 4 to 5B At block 1608, the RAN node determines whether the first RRC message causes the UE to transition to a connected state. If the RAN node determines that the first RRC message causes the UE to transition to a connected state, the flow proceeds to block 1610. At block 1610, the RAN node continues to use the C-RNTI to perform data communications with the UE after stopping SDT. In other words, the RAN node uses the C-RNTI to perform data communications with the UE operating in a connected state (e.g., FIG. 5A to FIG. 5B Events 550, 518).

[0242] Otherwise, if the RAN node determines that the first RRC message did not cause the UE to transition to a connected state, flow proceeds to block 1612. At block 1612, the RAN node stops using the C-RNTI to perform data communications with the UE after sending the first RRC message.

[0243] In the event that the first RRC message causes the UE to transition to a connected state, the UE stops SDT, transitions to a connected state, and sends a first RRC response message to the RAN node in response to the first RRC message. In some implementations, the RAN node determines that the UE transitions to a connected state in response to receiving the first RRC response message. In some implementations, the first RRC message and the first RRC response message are an RRC recovery message and an RRC recovery complete message, respectively. In other implementations, the first RRC message and the first RRC response message are an RRC setup message and an RRC setup complete message, respectively. In the event that the first RRC message does not cause the UE to transition to a connected state, the first RRC message is an RRC release message (e.g., Figure 4 The RAN node determines that the UE stops SDT in response to sending the first RRC message or after the sending of the first RRC message.

[0244] In some implementations, the RAN node starts an SDT session timer for the SDT in response to performing the SDT (e.g., receiving an UL RRC message for initiating the SDT, similar to event 404). The RAN node stops the SDT session timer in response to sending the first RRC message or receiving the first RRC response message or after the sending or the receiving.

[0245] In some implementations, the SDT is a CG-SDT or a RA-SDT. In some implementations, the RAN node sends a second RRC message (e.g., an RRC reconfiguration message or an RRC recovery message) including the C-RNTI to the UE before the SDT. In further implementations, the UE sends a second RRC response message (e.g., an RRC reconfiguration complete message or an RRC recovery complete message) to the RAN in response to the second RRC message. In other implementations, the UE performs a random access procedure to initiate the SDT (i.e., RA-SDT). The RAN node sends a random access response including the C-RNTI to the UE in the random access procedure.

[0246] For CG-SDT, the RAN uses the C-RNTI and CS-RNTI of the UE to perform data communication with the UE. The RAN node sends a third RRC message including the CS-RNTI to the UE before the CG-SDT process. In some implementations, the third RRC message is an RRC reconfiguration message, and in response, the UE sends an RRC reconfiguration complete message to the RAN. In other implementations, the third RRC message is an RRC recovery message, and in response, the UE sends an RRC recovery complete message to the RAN. In yet other implementations, the third RRC message is an RRC release message. In some implementations, the third RRC message includes a CG-SDT configuration that configures CG resources for CG-SDT. Alternatively, the RAN node sends a fourth RRC message including the CG-SDT configuration to the UE. In some implementations, the fourth RRC message is an RRC reconfiguration message, and in response, the UE sends an RRC reconfiguration complete message to the RAN. In other implementations, the fourth RRC message is an RRC recovery message, and in response, the UE sends an RRC recovery complete message to the RAN. In yet other implementations, the fourth RRC message is an RRC release message. In some implementations, the RAN node stops using the CS-RNTI in response to stopping the SDT or after the stopping. In some implementations, the RAN node stops attempting to receive UL transmissions on the CG resources in response to stopping the SDT or after the stopping. In some implementations, the RAN node releases the CG-SDT configuration in response to sending the first RRC message or after the sending.

[0247] against Fig.15A and Fig. 15B The examples and implementations described may be applicable to Fig.16 .

[0248] The following description may be applicable to the above description.

[0249] In general, the description for any one in the above figure may be applicable to another in the above figure. The above-mentioned events or boxes may be optional or omitted. For example, the events or boxes represented by dashed lines in the figure may be optional or omitted. In some cases, the events or boxes represented by solid lines in the figure are still optional or omitted, if the event or box is not necessary. In some implementations, "message" (as the term is used above) can be replaced by "information element (IE)", and vice versa. In some implementations, "IE" (as the term is used above) can be replaced by "field", and vice versa. In some implementations, "configuration" (as the term is used above) can be replaced by "configuration" or "configuration parameter", and vice versa. In some implementations, "small data transmission" (as the term is used above) can be replaced by "early data transmission" (and "SDT" can be replaced by "EDT"), and vice versa. In some implementations, "small data transmission" (as the term is used above) can be replaced with "small data communication", and vice versa. In some implementations, "stop" (as the term is used above) can be replaced with "pause".

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

[0251] 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 can perform certain operations and can be configured or arranged in a particular manner. A hardware module may include a dedicated circuit 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 (e.g., contained in a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in 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.

[0252] 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 wireless communication implemented in a UE, the method comprising: monitoring a physical downlink control channel (PDCCH) using a radio network temporary identifier (RNTI) during a small data transmission (SDT) procedure and when the UE is operating in an inactive state; transitioning from the inactive state to a connected state in response to a command from a radio access network (RAN); as well as When the UE operates in the connected state, the PDCCH is monitored using the RNTI after the transition.

2. The method according to claim 1, wherein: The RNTI is a cell-RNTI (C-RNTI).

3. The method according to claim 1 or 2, wherein: The command from the RAN comprises a Radio Resource Control (RRC) resume message.

4. The method according to claim 1 or 2, wherein: The command from the RAN comprises an RRC setup message.

5. A method according to any one of the preceding claims, wherein: The monitoring of the PDCCH using the RNTI after the transition is responsive to the command.

6. A method according to any one of the preceding claims, wherein: The SDT process is a configured-granted SDT (CG-SDT) process.

7. A user equipment (UE), comprising: Transceiver; as well as Processing hardware configured to implement a method according to any one of the preceding claims.

8. A method for wireless communication implemented in a radio access network (RAN) node, the method comprising: performing a small data transmission (SDT) procedure with a user equipment (UE) using a radio network temporary identifier (RNTI) when the UE is operating in an inactive state; sending a command to the UE to transition from the inactive state to a connected state; as well as When the UE operates in the connected state, the RNTI is used to communicate with the UE.

9. The method of claim 8, wherein the RNTI is a cell-RNTI (C-RNTI).

10. The method according to claim 8 or 9, wherein: The command from the RAN node comprises a Radio Resource Control (RRC) resume message.

11. The method according to claim 8 or 9, wherein: The command from the RAN comprises an RRC setup message.

12. The method according to any one of claims 8 to 11, wherein: Communicating with the UE using the RNTI is responsive to the command to transition to the connected state.

13. A method according to any one of the preceding claims, wherein: The SDT process is a configured-granted SDT (CG-SDT) process.

14. The method according to any one of claims 8 to 12, further comprising: An RRC message including the RNTI is sent to the UE before performing the SDT process.

15. A radio access network (RAN) node, comprising: Transceiver; as well as Processing hardware configured to implement the method according to any one of claims 8 to 14.

Images