Managing small data transmissions with radio access network

Abstract

A user equipment (UE) receives, from a radio access network (RAN), a configuration for skipping uplink transmissions. The UE obtains an uplink (UL) grant. When operating under an inactive radio connection between the UE and the RAN, the UE skips the uplink transmission corresponding to the UL grant according to the received configuration.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 334,074, entitled “Managing Small Data Transmission with a User Equipment,” filed on April 22, 2022, and U.S. Provisional Patent Application No. 63 / 334,081, entitled “Managing Small Data Transmission with a Radio Access Network,” filed on April 22, 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 configurations for managing small data communications of uplink and / or downlink data at a user equipment (UE) and a radio access network (RAN) when the UE is operating in an inactive or idle state associated with a protocol for controlling radio resources. Background Art

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

[0005] Generally speaking, 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 RRC_INACTIVE, which allows the UE to transition back to the RRC_CONNECTED state more quickly due to radio access network (RAN) level base station coordination and RAN paging procedures. In some cases, a UE in the RRC_INACTIVE state has only a relatively small packet to transmit. In some such cases, a small data transmission (SDT) procedure will support data transmission for UEs operating RRC_INACTIVE (i.e., without transitioning to the RRC_CONNECTED state).

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

[0008] During an SDT session with a base station (e.g., gNB), the UE obtains an uplink grant (e.g., a dynamic grant or a configured grant) for data transmission. In such cases, the UE may not have data available for transmission using the uplink grant. It is unclear whether the UE skips the uplink transmission configured by the uplink grant. It is also unknown how the base station manages small data communications for the UE. Summary of the invention

[0009] An example embodiment of the technology of the present disclosure is a method for wireless communication. The method is implemented in a UE and includes: receiving a configuration for skipping uplink transmission from a RAN; obtaining a UL grant; and when operating under an inactive radio connection between the UE and the RAN, skipping uplink transmission corresponding to the UL grant according to the received configuration.

[0010] Another example embodiment of the technology of the present disclosure is a UE that includes a transceiver and processing hardware configured to implement the above method.

[0011] Yet another example embodiment of these techniques is a method for wireless communication implemented in a node of a RAN, and the method includes: transmitting to the UE a configuration for skipping uplink transmission according to a UL grant when the UE operates under an inactive radio connection between the UE and the RAN; and communicating with the UE according to the configuration when the UE operates under the inactive radio connection.

[0012] Yet another exemplary embodiment of the technology of the present disclosure is a node of a RAN, which includes a transceiver and processing hardware configured to implement the above method. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0017] Figure 3 An example scenario is shown in which a RAN node configures a UE for SDT and the UE enters an inactive state;

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

[0019] Figure 5A An example scenario is shown in which a RAN node determines to resume a connection with a UE to transmit data before configuring the UE for SDT;

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

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

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

[0023] Figure 6C Shown with Fig. 6A A similar example scenario, but where the UE enters the connected state and receives configuration information, then returns to the inactive state and communicates via SDT;

[0024] Fig. 7A An example scenario is shown in which the RRC layer of the UE initiates SDT, during which the upper layers of the UE communicate UL and / or DL ​​data directly with the PDCP layer;

[0025] Figure 7B Shown with Fig. 7A Similar example scenario, but where the upper layers transmit UL and / or DL ​​data via the RRC layer and the PDCP layer;

[0026] Figure 7C Shown with Fig. 7A A similar example scenario, but where the RRC layer communicates with upper layers of the UE via the PDCP layer before performing the SDT procedure;

[0027] Fig. 8A is a flow chart of an example method implemented in a UE for determining whether to transmit SDT data to a RAN using a UL grant based on whether the UE has UL data to transmit;

[0028] Figure 8B is with Fig. 8A A flow chart of a similar example method, but wherein the UE determines whether to transmit a data packet when the UE has no UL data to transmit based on whether the first SDT configuration configures UL transmission skipping;

[0029] Figure 8C is with Figure 8B A flow chart of a similar example method, but wherein the UE determines whether to transmit a data packet based on whether the SIB is configured and / or whether the UE supports UL transmission skipping;

[0030] Fig.8D is with Figure 8B A flow chart of a similar example method, but wherein the UE determines whether to transmit a data packet based on whether UL transmission skipping is configured for a non-SDT configuration;

[0031] Fig. 9A is a flow chart of an example method implemented in a UE for determining whether to enable UL transmission skipping based on whether UL transmission skipping is configured in an SDT configuration before determining whether to transmit SDT data or data packets;

[0032] Fig. 9B is with Fig. 9A A flow chart of a similar example method, but wherein the UE determines whether to enable UL transmission skipping based on whether the SIB configures UL transmission skipping and / or whether the UE supports UL transmission skipping;

[0033] Fig. 9C is with Fig. 9A A flow chart of a similar example method, but wherein the UE determines whether to enable UL transmission skipping based on whether UL transmission skipping is configured for a non-SDT configuration;

[0034] Fig. 10A is a flow chart of an example method implemented in a UE for generating a UE capability IE including non-SDT, SDT, and UL transmission skipping capabilities;

[0035] Fig. 10B is with Fig. 10A A flow chart of a similar example method, but wherein the UE transmits a UE capability identifier to a base station, the UE capability identifier identifying stored UE capabilities for non-SDT, SDT, and UL transmission skipping capabilities;

[0036] Fig.11A is a flow chart of an example method implemented in a UE for determining whether to use a UL grant to transmit SDT data after generating and transmitting UE capability information to a RAN node;

[0037] Fig. 11B is with Fig.11A A flow chart of a similar example method, but wherein the UE transmits to the base station a UE capability identifier identifying the stored UE capabilities;

[0038] Fig.12 is a flow chart of an example method implemented in a UE for determining whether to indicate to a RAN node that the UE supports transmission skipping;

[0039] Fig.13A is a flow chart of an example method implemented in a UE for communicating with a RAN node via an SDT configuration and avoiding communicating via a non-SDT configuration in an inactive state;

[0040] Fig. 13B is with Fig.13A Flowchart of a similar example method, but wherein the UE communicates with a RAN node in an inactive state via an SDT configuration and a portion of a non-SDT configuration.

[0041] Fig.14A is a flow chart of an example method implemented in a DU of a RAN node for including a transmission skip configuration in an SDT configuration to configure a UE;

[0042] Fig. 14B is with Fig.14A A flow chart of a similar example method, but wherein the DU avoids including a transmission skip configuration in an SDT configuration;

[0043] Fig. 14C is with Fig.14A A flow chart of a similar example method, but wherein the DU determines whether to include a transmission skip configuration in the SDT configuration based on whether the UE and / or the DU supports UL transmission skipping;

[0044] Fig.15 is a flow chart of an example method implemented in a RAN node for determining whether to include a transmission skip configuration based on whether a UE and / or the RAN node supports UL transmission skipping;

[0045] Fig.16A is a flow chart of an example method implemented in a RAN node for including a transmission skip configuration in an SDT configuration and broadcasting the SDT configuration on a cell;

[0046] Fig. 16B is with Fig.16A a flow chart of a similar example method, but wherein the RAN node avoids including a transmission skip configuration in the SDT configuration;

[0047] Fig. 16C is with Fig.16A A flow chart of a similar example method, but wherein the RAN node determines whether to include a transmission skip configuration based on whether the RAN node supports UL transmission skipping;

[0048] Fig.17A is a flow chart of an example method implemented in a DU for including a transmission skip configuration in a non-SDT configuration, transmitting the non-SDT configuration to a UE, and enabling a transmission skip detection function for the UE;

[0049] Fig. 17B is with Fig.17A A flow chart of a similar example method, but wherein the DU avoids including a transmission skip configuration in a non-SDT configuration;

[0050] Fig. 17C is with Fig.17A A flow chart of a similar example method, but wherein the DU determines whether to include a transmission skip configuration in a non-SDT configuration based on whether the UE and / or the DU supports UL transmission skipping;

[0051] Fig.18 is a flow chart of an example method implemented in a RAN node for determining whether to include a transmission skip configuration in a non-SDT configuration based on whether a UE and / or the RAN node supports UL transmission skipping;

[0052] Fig.19A is a flow chart of an example method implemented in a RAN node for communicating with a UE in an inactive state by using an SDT configuration and avoiding the use of a non-SDT configuration; and

[0053] Fig.19B is with Fig.19A Flowchart of a similar example method, but where the RAN node communicates with a UE in an inactive state by using an SDT configuration and a portion of a non-SDT configuration. DETAILED DESCRIPTION

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

[0055] 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. The CN 110 may be implemented as, for example, 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.

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

[0057] Among other components, the EPC 111 may also include a serving gateway (SGW) 112, a mobility management entity (MME) 114, and a packet data network gateway (PGW) 116. Generally speaking, the SGW 112 is configured to deliver user plane packets related to audio calls, video calls, Internet services, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks (e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network). The 5GC 160 includes a user plane function (UPF) 162 and an access and mobility management function (AMF) 164 and / or a session management function (SMF) 166. Generally speaking, UPF 162 is configured to deliver user plane packets associated with audio calls, video calls, Internet services, etc., AMF 164 is configured to manage authentication, registration, paging and other related functions, and SMF 166 is configured to manage PDU sessions.

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

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

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

[0061] 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 uplink (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 transmit the second UL PDU to RAN 105. UE 102 includes a UE identity / identifier (ID) of UE 102 in the UL RRC message. RAN 105 may identify UE 102 based on the UE ID. In some implementations, the UE ID may be an Inactive Radio Network Temporary Identifier (I-RNTI), a Recovery ID, or a Non-Access Stratum (NAS) ID. The NAS ID may be an S-Temporary Mobile Subscriber Identity (S-TMSI) or a Globally Unique Temporary Identifier (GUTI).

[0062] 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 transmit the security-protected packet to RAN 105 when in RRC_INACTIVE or RRC_IDLE state.

[0063] In some implementations, the data is an uplink (UL) service data unit (SDU) of a packet data convergence protocol (PDCP) or SDAP. The UE 102 applies a security function to the SDU and includes the protected SDU in a first UL PDU (e.g., 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 transmits the protected UL PDCP PDU in the UL MAC PDU. In some implementations, the UE 102 may include the UL RRC message in the UL MAC PDU. In further implementations, the UE 102 may not include the UL RRC message in the UL MAC PDU. In this case, the UE 102 may not include the UE ID of the UE 102 in the UL MAC PDU that does not include the UL RRC message. In yet further implementations, the UE 102 may include the UL PDCP PDU in a UL radio link control (RLC) PDU, and then include the UL RLC PDU in a UL MAC PDU. In the case of including the UL RRC message in the UL MAC PDU, in some implementations, the UE 102 generates an RRC MAC-I and includes the RRC MAC-I in the UL RRC message. For example, the RRC MAC-I is the resumeMAC-I field (e.g., as specified in 3GPP specification 38.331). In further implementations, the UE may utilize an integrity key (e.g., K RRCint The RRC MAC-I is obtained from the UL RRC message using a key), an integrity protection algorithm, and other parameters COUNT (e.g., a 32-bit, 64-bit, or 128-bit value), BEARER (e.g., a 5-bit value), and DIRECTION (e.g., a 1-bit value).

[0064] In a further implementation, the data is a UL service data unit (SDU) of NAS. UE 102 applies a security function to the SDU and includes the protected SDU in a first UL PDU such as a NAS PDU, which may be associated with a NAS layer. For example, the NAS layer may be an MM sublayer or an SM sublayer of 5G, an evolved packet system (EPS), or 6G. Then, UE 102 may include the UL NAS PDU in a second UL PDU such as a UL RRC message. Therefore, in these cases, UE 102 transmits the (first) protected UL NAS PDU in the UL RRC message. In some implementations, UE 102 may include the UL RRC message in a UL MAC PDU and transmit the UL MAC PDU to a base station (e.g., base station 104 or 106) via a cell (e.g., cell 124 or 126). In this case, UE 102 may not include the RRC MAC-I in the UL RRC message. Alternatively, UE 102 may include the RRC MAC-I as described above.

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

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

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

[0068] 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 transmits the data to the CN 110 (e.g., UPF 162) or an edge server. When the security-protected packet is an encrypted packet, the base station 106 obtains the data by decrypting the encrypted packet using at least one security key (e.g., encryption and / or decryption key). If the security-protected packet is an integrity-protected packet, the integrity-protected packet may include data and MAC-I. The base station 106 may verify whether the MAC-I is valid for the security-protected packet by using at least one security key (e.g., integrity key). When the base station 106 confirms that the MAC-I is valid, the base station 106 sends the data to the CN 110. On the other hand, when the base station 106 determines that the MAC-I is invalid, the base station 106 discards the security-protected packet. Further, 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.

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

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

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

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

[0073] 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 transmit 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 transmits the DCI and the scrambled CRC to UE 102 operating in an RRC_INACTIVE or RRC_IDLE state on a physical downlink control channel (PDCCH). The base station scrambles the CRC with the ID of UE 102. In some implementations, the base station may assign the ID of UE 102 to UE 102 in a random access response or message B (MsgB) transmitted by the base station in a random access process with UE 102 before transmitting 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) transmitted by the base station to UE 102 before transmitting the DCI and the scrambled CRC (e.g., when UE 102 is in the RRC_CONNECTED state).

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

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

[0076] UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors such as CPUs, and non-transitory computer-readable memory storing machine-readable instructions executable on one or more general-purpose processors, and / or dedicated processing units. In an example implementation, the processing hardware 150 includes an RRC inactive controller 158, which is configured to manage uplink and / or downlink communications when UE 102 operates in 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, transmit an uplink MAC protocol data unit (PDU) to the base station, and receive a downlink MAC PDU from the base station. The processing hardware 150 may also include a PDCP controller 154, which is configured to: in some scenarios, a DL PDCP PDU according to which the transmitting base station 106 can transmit data in the downlink direction; and in further scenarios, a UL PDCP PDU according to which the receiving base station 106 receives data in the uplink direction. The processing hardware may further include an RRC controller 156 to implement procedures and messaging at the RRC sublayer of the protocol communication stack.

[0077] 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 that can be executed 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 that is configured to manage or control one or more RLC operations or processes. In further implementations, the CU 172 does not include an RLC controller.

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

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

[0080] 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 transmit control information (e.g., RRC messages, F1 application protocol messages), and the CU-UP 172B may transmit data packets (e.g., SDAP PDUs or Internet Protocol packets).

[0081] 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 requested service of 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, connectivity between CU-UP 172B and DU 174 is established by CU-CP 172A using a bearer context management function.

[0082] Figure 2AAn example protocol stack 200 is shown 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).

[0083] In the example stack 200, the physical layer (PHY) 202A of EUTRA provides transport channels to the EUTRA MAC sublayer 204A, which in turn provides logical channels to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A in turn provides RLC channels to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NRRPHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn may provide data delivery 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 handover between EUTRA and NR base stations and / or support DC implemented through EUTRA and NR interfaces. Figure 2A As shown, UE 102 may support NR PDCP 210 layered on EUTRA RLC 206A, and SDAP sublayer 212 layered on NR PDCP sublayer 210.

[0084] 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). Unless the difference between SDUs and PDUs is relevant, for simplicity, this disclosure refers to both SDUs and PDUs as "packets".

[0085] On the control plane, for example, 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 exchange RRC messages or non-access stratum (NAS) messages. On the user plane, the 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.

[0086] 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 to the 5GC, the NR PDCP 210 provides SRBs to the RRC 214, and the NR PDCP 210 provides DRBs to the SDAP 212 and SRBs to the RRC 214.

[0087] 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 transmitting data in an inactive or idle state. To simplify the following description, "inactive state" is used and may refer to the RRC_INACTIVE or RRC_IDLE state, and "connected state" is used and may refer to the RRC_CONNECTED state.

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

[0089] 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. The UE 102 further communicates with the CU-CP 172A and / or the 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 the 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 the CU-UP 172B via the DU 174 using the second non-SDT CU configuration.

[0090] In some implementations, the second non-SDT CU configuration augments the first non-SDT CU configuration and / 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 at least one of the CU-CP 172A and / or CU-UP 172B communicate 318 with each other using the second non-SDU CU configuration and configuration parameters in the first non-SDT CU configuration that are not augmented 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), and the UE 102 and the CU 172 use these configuration parameters to communicate with each other when the UE 102 operates in a connected state. Similarly, in a further implementation, the second non-SDT CU configuration includes configuration parameters related to the operation of the RRC and / or PDCP protocol layers, and the UE 102 and the CU 172 communicate with each other using these configuration parameters when the UE 102 operates in the connected state.

[0091] In some implementations, the first non-SDT CU configuration includes configuration parameters in a RadioBearerConfig information element (IE) (e.g., as defined in 3GPP specification 38.331 v16.7.0 or later) and / or a MeasConfig IE. 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 or later). 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.

[0092] 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), which the UE 102 and the DU 174 use to communicate with each other when the UE 102 operates in a connected state. Similarly, in further implementations, the second non-SDT DU configuration includes configuration parameters related to the operation of the RRC, RLC, MAC, and / or PHY protocol layers, which the UE 102 and the DU 174 use to communicate with each other when the UE 102 operates in a connected state.

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

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

[0095] According to an implementation, while the UE 102 is communicating with the base station 104, or after the non-SDT resource configuration / reconfiguration process 390, the CU-CP 172A determines to transition the UE 102 from the connected state to the inactive state based on data inactivity of the UE 102 (i.e., the UE 102 in the connected state does not have data activity with the base station 104). In some implementations, while the UE 102 is communicating with the base station 104, or after the non-SDT resource configuration / reconfiguration process 390, the UE 102 determines or detects data inactivity and transmits 320 UE assistance information (e.g., a UEAssistanceInformation message) to the DU 174, the UE assistance information indicating that the UE 102 prefers or requests to transition to the inactive state or leave the connected state. In some implementations, the UE 102 indicates in the UE assistance information that the UE 102 prefers or requests to transition to the inactive state of the configured SDT. Then, DU 174 transmits 321 a UL RRC messaging message including the UE assistance information to CU-CP 172A. Thus, CU-CP 172A may determine that UE 102 has data inactivity based on the UE assistance information.

[0096] In other implementations, the DU 174 performs data inactivity monitoring for the UE 102. Depending on the implementation, the CU-CP 172A transmits a CU-to-DU message (e.g., a UE context setup request message or a UE context modification request message) to the DU 174 to request or command the DU 174 to perform data inactivity monitoring. In some cases where the DU 174 detects or determines that the UE 102 has data inactivity during monitoring, the DU 174 transmits 322 an inactivity notification (e.g., a UE inactivity notification message) to the CU-CP 172A. Thus, the CU-CP 172A can determine that the UE 102 has data inactivity based on the inactivity notification received from the DU 174.

[0097] In yet other implementations, CU-UP 172B performs data inactivity monitoring for UE 102. In some such implementations, CU-CP 172A transmits 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 has data inactivity during monitoring, CU-UP 172B transmits 323 an inactivity notification (e.g., a bearer context inactivity notification message) to CU-CP 172A. Thus, CU-CP 172A may determine that UE 102 has data inactivity based on the inactivity notification received from CU-UP 172B. In some implementations, CU-CP 172A determines that UE 102 has data inactivity based on UE assistance information, an inactivity notification of event 322, and / or an inactivity notification of event 323.

[0098] In some implementations, after a specific period of data inactivity, CU-CP 172A determines that neither CU 172 (i.e., CU-CP 172A and / or CU-UP 172B) nor UE 102 transmitted any data in the downlink direction or uplink direction, respectively, during the period. 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 transition UE 102 to an inactive state without SDT configured in response to determining that UE 102 has data inactivity.

[0099] In response to determining that the UE 102 has data inactivity (e.g., within a specific period of time) or determining to transition the UE 102 to an inactive state with SDT configured or thereafter, the CU-CP 172A sends 324 a bearer context modification request message to the CU-UP 172B to suspend data transmission of the UE 102. In response, the CU-UP 172B suspends data transmission of the UE 102 and sends 326 a bearer context modification response message to the CU-CP 172A. In some implementations, in response to determining that the UE 102 has data inactivity (e.g., within a specific period of time) or determining to transition the UE 102 to an inactive state with SDT configured or thereafter, the CU-CP 172A sends 328 a second CU-to-DU message (e.g., a UE context modification request message) to instruct the DU 174 to provide an SDT DU configuration for the UE 102. In some implementations, the CU-CP 172A includes an SDT request indication (eg, an IE such as a CG-SDT Query Indication IE or an SDT Query Indication IE) requesting SDT DU configuration in the second CU-to-DU message.

[0100] In a further implementation, in response to the SDT request indication or the second CU-to-DU message, the DU 174 transmits 330 a second DU-to-CU message (e.g., a UE context modification response message) to the CU-CP 172A. Alternatively, the DU 174 does not include the SDT DU configuration in the second DU-to-CU message. Instead, the DU 174 sends an additional DU-to-CU message (e.g., a UE context modification required message) including the SDT DU configuration to the CU-CP 172A after receiving the second CU-to-DU message or transmitting the second DU-to-CU message. In some implementations, the CU-CP 172A transmits an additional CU-to-DU message (e.g., a UE context modification confirmation message) to the DU 174 in response to the additional CU-to-DU message.

[0101] In other implementations, CU-CP 172A transmits a second CU to DU message and receives a second DU to CU message or an additional DU to CU message before determining that UE 102 has data inactivity. In still other implementations, CU-CP 172A includes an SDT request indication in the first CU to DU message of event 308, and DU 174 includes an SDTDU configuration in the first DU to CU message of event 310 in response to the SDT request indication.

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

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

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

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

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

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

[0108] In some implementations, the SDT DU configuration includes at least one of a buffer status report (BSR) configuration, a power headroom report (PHR) configuration, a configured grant (CG) configuration for CG-SDT, a UL bandwidth part (BWP) configuration, a DL BWP configuration for CG-SDT, a time alignment timer value for CG-SDT (e.g., a CG-SDT time alignment timer (CG-SDT-TAT) value), and / or a timing advance validity threshold for CG-SDT. In some implementations, the UL BWP configuration configures a dedicated UL BWP for the UE 102 to perform CG-SDT. Depending on the implementation, the UL BWP configuration includes a CG configuration, a PUCCH configuration, a PUSCH configuration, and / or a sounding reference signal (SRS) configuration. In some implementations, the DL BWP configuration configures a dedicated DL BWP for the UE 102 during the CG-SDT. In some implementations, the DL BWP configuration includes a PDCCH configuration and / or a PDSCH configuration for the UE to receive DL control signals from DU 174 on the PDCCH and data from DU 174 on the PDSCH when UE 102 performs a CG-SDT with DU 174. In some implementations, each of the CG configurations configures periodic radio resources (i.e., CG resources) that UE 102 uses to transmit data without receiving a dynamic grant for data transmission. Each of the CG configurations configures or includes a periodicity indicating that the CG resources occur periodically. In some implementations, the periodicity is a fixed number of symbols, time slots, or subframes. Depending on the implementation, some or all of the CG configurations have the same periodicity or different periodicities.

[0109] In some implementations, each of the CG configurations configures or includes an offset that indicates a time domain offset (e.g., timeDomainOffset) of the CG resources relative to a reference time (e.g., system frame number (SFN)). In some implementations, the CG configuration configures or includes a reference time (e.g., timeReferenceSFN). In some implementations, the CG configuration is or is similar to (e.g., as specified in 3GPP specification 38.331) ConfiguredGrantConfigIE. DU 174 configures a timing advance validity threshold (e.g., including an RSRP range) for UE 102 to determine whether UE 102 can initiate SDT using a configured grant configuration for CG-SDT, such as for Figure 4Based on the timing advance validity threshold, UE 102 evaluates whether the stored timing advance value is still valid. In an implementation where UE 102 determines that the stored timing advance value is invalid, UE 102 initiates a RA-SDT with CU 172 via DU 174, as described for Figure 4 In some implementations, the SDT DU configuration is an SDT-MAC-PHY-CG-Config IE or an SDT-MAC-PHY-Config IE.

[0110] In some implementations, "SDT DU configuration" is replaced with "CG-SDT configuration". In such implementations, the configurations in the SDTDU configuration are specific to CG-SDT. In other implementations, some of the SDT DU configurations described above are part of the CG-SDT configuration, while other configurations in the SDT DU configuration (e.g., BSR configuration and / or PHR configuration) are not part of the CG-SDT configuration. The SDT DU configuration includes the CG-SDT configuration. In such cases, UE 102 configures other configurations for CG-SDT or RA-SDT. In other implementations, the "SDT DU configuration" is simplified to the "SDT configuration".

[0111] In some implementations, the DU 174 starts or restarts the DU CG-SDT timer in response to or after receiving an SDT request indication, generating a CG-SDT configuration, receiving 328 a second CU to DU message, transmitting 330 a CG-SDT configuration to the CU 172, receiving 332 a third CU to DU message, or transmitting 334 a CG-SDT configuration to the UE 102. In further implementations, the DU 174 starts or restarts the DU CG-SDT timer with a timer value to manage the CG-SDT configuration.

[0112] In some implementations, the timer value is the same as the CG-SDT time alignment timer value. In other implementations, the timer value is close to the CG-SDT time alignment timer value. In one example, the timer value is greater than and close to the CG-SDT time alignment timer value. In another example, the timer value is less than and close to the CG-SDT time alignment timer value. In the event that the DU CG-SDT timer expires, DU 174 releases the CG-SDT configuration or the CG resources configured in the CG-SDT configuration. When or after the CG-SDT configuration is released, DU 174 avoids receiving PUSCH transmissions from UE 102 on radio resources reserved or configured by RAN 105 for the CG-SDT configuration. In some implementations, when or after the CG-SDT configuration is released, DU174 schedules transmissions for other UEs on radio resources reserved or configured for the CG-SDT configuration.

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

[0114] When the UE CG-SDT timer is running, the UE 102 in an inactive state communicates with the DU 174 via the dedicated DL BWP and the dedicated ULBWP (e.g., performs CG-SDT, transmits SRS, and / or receives DL control signals (e.g., DCI) and / or data). In some implementations, when the UE CG-SDT timer expires, the UE 102 in an inactive state switches from the dedicated DL BWP and the dedicated UL BWP to the initial DL BWP and the initial UL BWP, respectively. In some such cases, the UE 102 readjusts the transceiver of the UE 102 to switch to the initial DL BWP and the initial UL BWP. In some implementations, when the RAN 105 configures the UE 102 using the CG-SDT configuration, the UE 102 in an inactive state switches to the initial DL BWP and the initial ULBWP to perform a random access procedure. Depending on the implementation, the UE 102 performs a random access procedure for different situations as described below. In some implementations, the UE 102 in the inactive state switches to the initial DL BWP and the initial UL BWP to perform measurements on the SSBs transmitted by the DU 174 on the initial DL BWP.

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

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

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

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

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

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

[0121] In some implementations, DU 174 does not include the SDT DU configuration in the second DU to CU message. In some such implementations, DU 174 does not include the SDT DU configuration in the second DU to CU message because UE 102 does not support CG-SDT, and therefore DU 174 does not support CG-SDT. In other implementations, DU 174 does not include the SDT DU configuration in the second DU to CU message because DU 174 does not have available radio resources for CG-SDT. In such cases, the RRC release message does not include the SDT DU configuration. Otherwise, DU 174 transmits the SDT DU configuration to CU-CP 172A as described above. In some implementations, DU 174 does not include the configuration for CG-SDT in the SDT DU configuration in the second DU to CU message, similar to the above-mentioned SDT DU configuration.

[0122] In some implementations, such as when UE 102 supports CG-SDT and / or DU 174 supports CG-SDT, CU-CP 172A requests DU 174 to provide SDT DU configuration, as described above. In the case where UE 102 does not support CG-SDT or DU 174 does not support CG-SDT, CU-CP 172A does not request DU 174 to provide SDT DU configuration. Depending on the implementation, when UE 102 operates 302 in a connected state, CU-CP 172A receives UE capabilities (e.g., UE-ETURA-Capability IE, UE-NR-Capability IE, UE-6G-Capability IE) of UE 102 from UE 102, CN 110 (e.g., MME 114 or AMF 164), or base station 106. UE capabilities indicate whether UE 102 supports CG-SDT. Therefore, CU-CP 172A can determine whether 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 defined in 3GPP specification 38.473).

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

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

[0125] In other implementations or scenarios, UE 102 transitions from an inactive state in which SDT is not configured to an inactive state in which 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 but does not configure SDT (e.g., indicates release of SDT, or does not include SDT configuration in an RRC release message). In such a case, UE 102 transitions to an inactive state in which SDT is not configured in response to the RRC release message. In some implementations, UE 102 in an inactive state in which 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 including a first SDT CU configuration and / or a first SDT DU configuration, similar to the RRC release messages of events 332 and 334. Figure 4 The components in (e.g., UE 102, CU 172, DU 174, etc.) may be connected to Figure 3 Components with the same number are the same or different.

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

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

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

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

[0130] In other implementations, the UE 102 transmits 404 the UL MAC PDU on the CG resources, such as when the UE 102 receives or is configured with a CG configuration (e.g., as for Figure 3). In such a case, the UE 102 performs a CG-SDT. The UE 102 does not perform a random access procedure for transmitting 404 the UL MAC PDU. Therefore, the DU 174 receives 404 the UL MAC PDU on the CG resource. In some such implementations, in response to or after generating or transmitting 404 the UL MAC PDU, if the CU-CP 172A or DU 174 configures the UE 102 to apply a UE timer during the SDT, the UE 102 starts a UE timer (e.g., a second UE CG-SDT timer). In some implementations, the UE 102 starts a UE timer using a UE timer value (e.g., a cg-SDT-RetransmissionTimer value). In some implementations, the UE 102 receives an RRC release message including a UE timer value from the base station 104, similar to events 332, 334, 432, and 434. In some implementations, the CP-CP 172A includes the UE timer value in the CG-SDT configuration and transmits the RRC release message including the CG-SDT configuration to the UE 102 via the DU 174. In other implementations, the UE 102 receives the UE timer value in a system information block broadcast by the DU 174 via the cell 124. When the UE timer is running, the UE 102 in an inactive state or SDT session avoids retransmitting the UL MAC PDU on the CG resources. In some implementations, in response to receiving 404 to the UL MAC PDU on the CG resources or thereafter, the DU 174 uses the DU timer value to start a DU timer (e.g., a second DU CG-SDT timer). In some implementations, the DU timer value is equal to or greater than the UE timer value. When the DU timer is running, the DU 174 processes the UL transmission received from the UE 102 on the CG resources as a new transmission.

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

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

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

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

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

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

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

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

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

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

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

[0142] Events 404, 406, 408, 410, 412, 414, 415, 416, and 418 are Figure 4 404, 406, 408, 410, 412, 414, 415, and 416 are collectively referred to as small data communication process 492. Figure 4 It is collectively referred to as the initial small data transfer (SDT) process 480.

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

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

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

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

[0147] Similarly, in response to the SDT request indication or the second CU-to-DU message, the DU 174 transmits 430 a second DU-to-CU message (e.g., a UE context modification response message) to the CU-CP 172A. In some implementations, the DU 174 includes the second SDT DU configuration in the second DU-to-CU message. In some cases where the DU 174 obtains the first SDT DU configuration, the DU 174 generates the second SDT DU configuration to expand (e.g., replace or update) the first SDT DU configuration. In some implementations, the DU 174 generates the second SDT DU configuration as a complete and self-contained configuration (i.e., a complete configuration) (e.g., because the DU 174 does not support incremental configuration, or none of the configuration parameters in the first SDT DU configuration is valid). In some such implementations, the DU 174 includes a first indication in the second DU-to-CU message indicating that the second SDT DU configuration is a complete and self-contained configuration (i.e., a complete configuration). For example, the first indication may be an establishment indication or a complete configuration indication.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0166] The examples and implementations for events 320, 321, 322, 323, 324, 326, 328, 330, 332, and 334 may be respectively applicable to events 420, 421, 422, 423, 424, 426, 428, 430, 432, and 434. After stopping the SDT, the UE 102 may perform 493 another small data communication process with the base station 104, similar to the process 492. After completing the process 493, the base station 104 may perform 495 an SDT completion process with the UE 102, similar to the process 494.

[0167] 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 428 and 430 are omitted. In such cases, CU-CP 172A does not include the SDT DU configuration in the RRC release message. Alternatively, CU-CP 172A generates the SDT DU configuration on its own and includes the SDT DU configuration in the RRC release message.

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

[0169] 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 the UE initiates SDT when UE 102 is operating in an inactive state 402, when the UE performs SDT (e.g., in a UE context setup request message of event 408 or a CU to DU message of event 428), or as for Figure 3 As described, when the UE is operating 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. The UE capabilities indicate whether UE 102 supports CG-SDT. Therefore, CU-CP 172A can determine whether the UE supports CG-SDT based on the UE capabilities. In some implementations, CU-CP 172A receives a DU to CU message from DU 174 indicating whether DU 174 supports CG-SDT. The DU to CU message can be a second DU to CU message, a message of event 308 or 316, or a non-UE associated message (e.g., a non-UE associated F1AP message defined in 3GPP specification 38.473).

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

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

[0172] 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 cause the UE 102 to transition to a connected state. In some implementations, the UE 102 transmits 503 a non-SDT indication message to the DU 174 to indicate that UL data is available or to request a transition to a connected state. In some implementations, the UE 102 transmits 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 uses the C-RNTI to receive an uplink grant from the DU 174 on the PDCCH and transmits 503 a non-SDT indication message to the DU 174 on the radio resources configured in the uplink grant. Subsequently, the DU 174 transmits 505 a UL RRC messaging message including a non-SDT indication message to the CU-CP 172A. CU-CP 172A determines to cause UE 102 to transition to a connected state in response to or based on a non-SDT indication message. In other implementations, CU-UP 172B receives DL data from CN 110, and transmits 507 a DL data notification (e.g., a DL data notification message) to CU-CP 172A in response to receiving the DL data to indicate that the DL data is available for transmission. In some implementations, CU-CP 172A determines to cause UE 102 to transition to a connected state in response to or based on a DL data notification. In other implementations, CU-CP 172A determines to cause UE 102 to transition to a connected state based on a measurement result received from UE 102. In yet other implementations, CU-CP 172A receives DL data (e.g., a NAS message) from CN 110, and determines to cause UE 102 to transition to a connected state in response to receiving the DL data.

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

[0174] In response to or after determining that UE 102 is caused to transition to a connected state, CU-CP 172A transmits 508 a UE context request message (e.g., a UE context establishment request message or a UE context modification request message) to DU 174. In response, DU 174 transmits 510 a UE context response message (e.g., a UE context establishment 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 transmits 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 transmits 546 the RRC resume message to UE 102. In some implementations, DU 174 transmits 546 one or more PDUs including an RRC recovery message to UE 102. Depending on the implementation, the PDU is a MAC PDU or an RLC PDU. In some implementations, the CU to DU message is a DL RRC messaging message or a UE context modification request message. In some cases regarding the UE context modification request message, in response, DU 174 transmits a UE context modification response message to CU-CP 172A. In response to the RRC recovery message, UE 102 transitions 548 to a connected state and transmits 550 an RRC recovery completion message (e.g., an RRCResumeComplete message or an RRCConnectionResumeComplete message) to DU 174. In the case where the UE context response message includes a non-SDT DU configuration, CU-CP 172A includes the non-SDT DU configuration in the RRC recovery message. DU 174 transmits 552 a DU to CU message including an RRC recovery completion message to CU-CP 172A. In some implementations, the DU to CU message is a UL RRC messaging message, a UE CONTEXT MODIFICATION REQUIRED message, or a UE CONTEXT MODIFICATION RESPONSE message.

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

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

[0177] In some implementations, CU-CP 172A includes an indication indicating that DU 174 generates a non-SDT configuration in a UE context request message, and DU 174 includes the first non-SDT DU configuration in a UE context response message in response to the indication. In yet other implementations, CU-CP 172A stores a non-SDT DU configuration (i.e., a second non-SDT DU configuration) used by a DU (e.g., DU 174 or another DU or base station) to communicate with UE 102. Depending on the implementation, UE 102 also stores 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 expands or replaces the second non-SDT DU configuration. Examples and implementations for the first non-SDT DU configuration and the second non-SDT DU configuration are as described above for the non-SDT DU configuration. In some implementations, DU 174 transmits an additional DU to CU message (e.g., UE context modification required message) including the first non-SDT DU configuration to CU-CP 172A instead of including the first non-SDT DU configuration in the UE context response message.

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

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

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

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

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

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

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

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

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

[0187] 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, in response to receiving a timing advance command from DU 174 during the small data communication process 592, UE 102 starts or restarts a first UE CG-SDT timer. In some implementations, in response to receiving an RRC recovery message or thereafter, UE 102 maintains (e.g., keeps or does not stop, start or restart) the first UE CG-SDT timer (e.g., CG-SDT-TAT) running. In other implementations, in response to receiving an RRC recovery message or thereafter, UE 102 stops the first UE CG-SDT timer.

[0188] 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, in response to transmitting a timing advance command to UE 102, DU 174 starts or restarts a first DU CG-SDT timer. In some implementations, in response to receiving 508 a UE context request message, transmitting 510 a UE context response message, or transmitting 512 a recovery message or thereafter, DU 174 maintains (e.g., keeps or does not stop, start, or restart) the first DU CG-SDT timer running. In other implementations, in response to receiving 508 a UE context request message, transmitting 510 a UE context response message, or transmitting 545 an RRC recovery message or thereafter, DU 174 stops the first DU CG-SDT timer. In some cases where the first DU CG-SDT timer expires, DU 174 releases the CG-SDT configuration. In some cases where the first DU CG-SDT timer expires, DU 174 instead retains the CG-SDT configuration and avoids receiving or attempting to receive UL transmissions (e.g., MAC PDUs) on CG resources. In some such cases, the DU 174 releases the CG resources or determines that the CG resources are invalid.

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

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

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

[0192] At a later time, 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 102, similar to the procedures 390 and 394, respectively. The UE 102 transitions 536 to the inactive state in response to receiving the RRC release message in the procedure 594. 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 104, similar to the procedures 492 and 494, respectively.

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

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

[0195] In some implementations, the UE 102 generates a UL MAC PDU including the RRC recovery request message and transmits 542 the UL MAC PDU to the DU 174. In some implementations, the UE 102 transmits 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 transmit the UL MAC PDU, similar to event 404.

[0196] In some implementations, the UE 102 initiates an RRC recovery procedure to transmit non-SDT data (i.e., data that does not meet the SDT condition). 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.

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

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

[0199] At a later time, the UE 102 in the inactive state initiates an RRC recovery procedure with the base station 106. In some implementations, the UE 102 initiates the RRC recovery procedure for RNA update because the base station 106 belongs to another RNA that is different from the RNA of the cell in which the UE 102 received the RRC release message that configured the UE 102 to transition to the inactive state 602. In other implementations, the UE 102 performs an RRC recovery procedure for periodic RNA updates. In response to the initiation, the UE 102 in the inactive state transmits 642 an RRC recovery request message to the DU 174, which in turn transmits 644 an initial UL RRC messaging message including an RRC recovery request message (e.g., an RRCResumeRequest message or an RRCConnectionResumeRequest message) to the CU-CP 172A. In some implementations, the RRC recovery request message includes a UE ID of the UE 102. For example, the UE ID may be an I-RNTI (e.g., a fullI-RNTI or a shortI-RNTI value or field). In some implementations, the RRC resume request message includes an RRC MAC-I. In further implementations, the RRC MAC-I is a resumeMAC-I field, and the UE 102 obtains the resumeMAC-I (e.g., as specified in 3GPP specification 38.331). In other implementations, the UE 102 uses an integrity key (e.g., K RRCint The UE 102 may further include a key, an integrity protection algorithm, and / or other parameters COUNT (e.g., a 32-bit, 64-bit, or 128-bit value), BEARER (e.g., a 5-bit value), and DIRECTION (e.g., a 1-bit value) to obtain an RRC MAC-I (e.g., a resumeMAC-I field) from the RRC resume request. In some implementations, the UE 102 sets bits of the COUNT, BEARER, and DIRECTION set to binary ones to generate the RRC MAC-I.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0221] First reference Fig. 7A, scenario 700A depicts data communication (i.e., small data transmission) between UE 102 and RAN 105 (e.g., base station 104 or 106) when UE 102 operates in an inactive state. In scenario 700A, UE 102 includes a MAC sublayer 204B, an RLC sublayer 206B, a PDCP sublayer 210, an RRC sublayer 214, and an upper layer 220. Depending on the implementation, the upper layer 220 includes a mobility management (MM) sublayer, a session management (SM) sublayer, an SDAP sublayer 212, a data transmission layer, a data connection manager, and / or a packet handler. For example, the MM sublayer and the SM sublayer may be a 5GMM sublayer and a 5GSM sublayer, respectively. In some implementations, the data transmission sublayer is an IP layer or an Ethernet layer. In some implementations, the data connection manager manages establishing, releasing, suspending, or resuming a data connection. The packet handler is a module that dispatches IP packets or Ethernet packets to a data connection. In some implementations, the data connection includes a packet data network (PDN) connection, a PDU session, an EPS bearer, a QoS flow, and / or a data path between a data transport layer, a packet processor, an SDAP sublayer 212, and / or a PDCP sublayer 210. In some implementations, the data connection manager is further divided into different modules (e.g., a PDN (connection) management module, a PDU (session) management module, a network service module, or a data service module), each module being responsible for a specific function.

[0222] To simplify the following description, “RRC 214,” “PDCP 210,” “RLC 206B,” “MAC 204B,” and “PHY 202B” are used to represent “RRC sublayer 214,” “PDCP sublayer 210,” “RLC sublayer 206B,” “MAC sublayer 204B,” and “PHY sublayer 202B,” respectively.

[0223] Initially, the UE 102 operates 702 in an inactive state with SDT configured (e.g., as for Figure 3 or Figure 4 102 ). At a later time, the upper layer 220 determines to initiate data transmission or to resume (suspend) the connection to transmit data. In response to the determination, the upper layer 220 sends 704 a connection recovery request message to the RRC 214. In response to the connection recovery request message or after receiving the connection recovery request message, the RRC 214 initiates 706 an SDT procedure (i.e., the UE 102 starts an SDT session). In some implementations, the RRC 214 may send 708 a connection recovery request confirmation message to the upper layer 220, thereby confirming that the RRC 214 received or is processing the connection recovery request message.

[0224] In some implementations, the upper layer 220 includes data volume information in the connection recovery request message. The data volume information includes or indicates the data volume of the data available for transmission. Based on the data volume information, the RRC 214 determines to initiate 706 the SDT process. For example, if the data volume in the data volume information is lower than the threshold, the RRC 214 determines to initiate 706 the SDT process. In some implementations, the UE 102 receives the threshold in a system information block (SIB) broadcast by the RAN 105. In other implementations, the RRC 214 receives the threshold in an RRC release message transmitted by the RAN 105 (e.g., similar to event 334 or 434). In the case where the RRC 214 receives the connection recovery request message including the data volume information and the data volume in the data volume information is higher than the threshold, the RRC 214 initiates the RRC connection recovery process to transition to the connected state instead of the SDT process.

[0225] In other implementations, the upper layer 220 includes an SDT indication in the connection restoration request message, and the SDT indication instructs the RRC 214 to initiate an SDT process. In response to the SDT indication, the RRC 214 initiates 706 the SDT. In such implementations, the RRC 214 sends a threshold to the upper layer 220. If the amount of data is below the threshold, the upper layer 220 determines to include the SDT indication. If the amount of data is above the threshold, the upper layer 220 avoids including the SDT indication in the connection restoration request message.

[0226] In response to initiating 706 the SDT procedure, RRC 214 generates an RRC recovery request message and sends 710 the RRC recovery request message to MAC 204B. In some implementations, RRC 214 sends 710 a UL SDT initiation indication to MAC 204B, indicating that the RRC recovery request message is for UL SDT initiation. In some implementations, RRC 214 sends an interface message including the RRC recovery request message and the UL SDT initiation to MAC 204B. In other implementations, RRC 214 sends separate interface messages including the RRC recovery request message and the SDT initiation indication to MAC 204B. In some implementations, MAC 204B sends a confirmation interface message to RRC 214 to confirm that MAC 204B received the interface message and will transmit the RRC recovery request message. When MAC 204B receives the SDT initiation indication and / or the RRC resume request message, MAC 204B waits to receive UL data from RLC 204B to generate an initial UL MAC PDU (as event 719).

[0227] In some implementations, in response to determining to initiate 706 the SDT process, the RRC 214 sends a resume indication message to the PDCP 210. In further implementations, the PDCP 210 resumes the SRB2 and / or DRB configured for SDT in response to the resume indication message. In some implementations, the RRC 214 indicates that the SRB2 and / or DRB will be resumed in the resume indication message. For example, the RRC 214 may include an ID of the SRB2 and an ID of the DRB in the resume indication message. In other implementations, the RRC 214 indicates that the resume indication message is for SDT. For example, the RRC 214 may include an SDT indication in the resume indication message.

[0228] After determining to initiate data transmission or restore connection, transmitting 704 a connection restoration request message, or receiving 708 a connection restoration request confirmation message, the upper layer 220 sends 712 UL data to the PDCP 210. In some implementations, the UL data includes data packets such as IP packets or Ethernet packets, and is generated by an application or an operating system (e.g., Android, Windows, iOS, Mac OS, and Chrome OS). In other implementations, the UL data includes an SDAP PDU. The PDCP 210 generates a UL PDCP PDU including UL data and sends 714 the UL PDCP PDU to the RLC 206B. In some implementations, the PDCP 210 sends 714 the UL PDCP PDU to the RLC 206B in response to receiving a restoration indication. The RLC 206B generates a UL RLC PDU including the UL PDCP PDU and sends 716 the UL RLC PDU to the MAC 204B. In some implementations, each UL RLC PDU includes a specific UL PDCP PDU in the UL PDCP PDU. The MAC 204B then generates 719 an initial UL MAC PDU including the RRC recovery request message and the UL RLC PDU. Alternatively, the RLC 206B generates a UL RLC PDU segment including the first part of the UL PDCPPDU and sends 716 the UL RLC PDU segment to the MAC 204B. The MAC 204B then generates 719 an initial UL MAC PDU including the RRC recovery request message and the UL RLC PDU segment. In some implementations, the MAC 204B includes at least one MAC control element (e.g., a buffer status report (BSR)) in the initial UL MAC PDU. In some implementations, the MAC 204B includes the amount of data in the BSR, and the amount of data indicates the data available for transmission.

[0229] MAC 204B performs 780 an initial SDT procedure to transmit an initial UL MAC PDU to RAN 105 via the cell, similar to event 404, process 480, or event 604. In the initial SDT procedure, MAC 204B transmits the initial UL MAC PDU to RAN 105, similar to event 404. In some implementations, after transmitting 780 the initial UL MAC PDU, MAC 204B determines 720 that the initial UL MAC PDU is successfully transmitted (i.e., the UL MAC PDU is received by RAN 105). In some implementations, MAC 204B performs a random access procedure with RAN 105 via the cell to transmit the initial UL MAC PDU to RAN 105 (i.e., RA-SDT). In such implementations, MAC 204B determines that the initial UL MAC PDU is successfully transmitted upon receiving a contention resolution MAC control element in the random access procedure. In the case where the random access procedure is a two-step random access procedure, the MAC 204B receives a contention resolution MAC CE in a message B (MsgB) of the random access procedure from the RAN 105. In the case where the random access procedure is a four-step random access procedure, the MAC 204B receives a contention resolution MAC control element in a message 4 (Msg4) (i.e., a DL MAC PDU) of the random access procedure from the RAN 105. In some implementations, the MAC 204B generates an initial UL MAC PDU before performing the random access procedure. For example, in some cases where the random access procedure is a two-step random access procedure, the MAC 204B generates 719 the initial UL MAC PDU according to the UL grant configured in the system information block (SIB).

[0230] In other implementations, MAC 204B generates an initial UL MAC PDU during the random access procedure. For example, in some cases where the random access procedure is a four-step random access procedure, MAC 204B performs a four-step random access procedure upon receiving 710 an RRC recovery request message or an SDT initiation indication from RRC 214. In further such cases, MAC 204B generates 719 an initial UL MAC PDU upon receiving an UL grant in a random access response in the random access procedure. Alternatively, MAC 204B generates 719 an initial UL MAC PDU according to a MAC PDU size before initiating random access. In some implementations, the MAC PDU size is a preconfigured size. In other implementations, UE 102 determines the MAC PDU size based on an UL grant in a random access response in a random access procedure previously performed by UE 102.

[0231] In some cases where the MAC 204B transmits 780 a UL MAC PDU to the RAN 105 via a cell on CG resources using a configured UL grant, the MAC 204B receives a UL grant from the PHY 202B ( Fig. 7A 104B , the PHY 202B receives a successful delivery indication indicating that the initial UL MAC PDU was successfully transmitted (not shown in the figure), and determines 720 that the initial UL MAC PDU is successfully transmitted. In some implementations, after transmitting 780 the initial UL MAC PDU, PHY202B receives a DCI and a CRC (of the DCI) scrambled with the ID of UE 102 on the PDCCH. In response to or after receiving the DCI and CRC, PHY 202B sends an indication to MAC 204B. In some implementations, the ID of UE 102 is a C-RNTI. In other implementations, the ID of UE 102 is a configured scheduling RNTI (CS-RNTI). In some implementations, the DCI includes a dynamic UL grant. In other implementations, the DCI includes a downlink assignment.

[0232] In some implementations, MAC 204B indicates the maximum RLC data size to RLC 206B. RLC 206B ensures that the total size of the UL RLC PDU or UL RLC PDU segment of event 716 is not greater than the maximum size. In some implementations, MAC 204B determines the MAC PDU size of the initial UL MAC PDU based on the UL grant in the SIB, the UL grant in the random access response, or the configured UL grant. MAC 204B determines the maximum RLC data size as (MAC PDU size-size of the RRC recovery request message-size of the subheader of the RRC recovery request message). In the case where MAC 204B determines to transmit at least one MAC control element (e.g., BSR), MAC 204B determines the maximum RLC data size as (MAC PDU size-size of the RRC recovery request message-size of the subheader of the RRC recovery request message-size of at least one MAC control element-size of the subheader of each of the at least one MAC control element).

[0233] In some cases where the initial UL MAC PDU includes the first part of the UL PDCP PDU, MAC 204B transmits other UL MAC PDUs including other UL RLC PDU segments to RAN 105. In further implementations, the segment includes the remainder of the UL PDCP PDU. Each RLC PDU segment includes a specific portion of the UL PDCP PDU. Depending on the implementation, each other UL MAC PDU includes a specific RLC PDU segment of the other UL RLC PDU segment. In some implementations, MAC 204B uses dynamic UL grants to transmit other UL MAC PDUs. UE 102 (e.g., PHY 202B) receives a dynamic UL grant on the PDCCH from RAN 105. In other implementations, MAC 204B uses the UL grant configured in the CG configuration received by UE 102 in the RRC release message to transmit other UL MAC PDUs (e.g., event 334 or 434). The RAN 105 receives the other UL MAC PDU, retrieves the other UL RLC PDU segments from the other UL MAC PDU, and assembles the other UL RLC PDU segments to obtain the UL PDCP PDU.

[0234] In response to the determination 720, the MAC 204B sends 722 an indication to the RRC 214 indicating that the SDT procedure was successfully initiated (i.e., the initial UL MAC PDU, the RRC resume request message, or the UL data was successfully transmitted). In response to receiving 722 the indication, the RRC 214 determines 724 that the SDT procedure was successfully initiated. In response to the determination 724 or the indication 722, the RRC 214 transmits 726 a connection resume message to the upper layer 220 to indicate that the connection is resumed. In some implementations, after receiving 726 the connection resume message, the upper layer 220 sends 728 subsequent UL data packets to the PDCP 210. For each subsequent UL data packet, the PDCP 210 generates a UL PDCP PDU including the subsequent UL data packet and sends 730 the UL PDCP PDU to the RLC 206B. In some implementations, RLC 206B generates a subsequent UL RLC PDU including the UL PDCP PDU, and / or generates a UL RLC PDU segment including the UL PDCP PDU. RLC 206 sends 732 the subsequent UL RLC PDU and / or the UL RLC PDU segment to MAC 204B. MAC 204B generates a subsequent UL MAC PDU including the subsequent UL RLC PDU and / or the UL RLC PDU segment. MAC 204B performs 718 SDT data communication to transmit the subsequent UL MAC PDU to RAN 105, similar to event 418. In some implementations, MAC 204B transmits the subsequent UL MAC PDU using a dynamic UL grant. UE 102 receives a dynamic UL grant on the PDCCH from RAN 105. In other implementations, MAC 204B transmits other UL MAC PDUs (e.g., event 334 or 434) using the UL grant configured in the CG configuration received by UE 102 in the RRC release message.

[0235] In some implementations, during the SDT session, the RAN 105 performs 718 SDT communication to transmit a DL MAC PDU to the UE 102, similar to event 418. The DL MAC PDU includes a MAC SDU. Each DL MAC PDU includes at least one MAC SDU. Depending on the implementation, the MAC SDU is or includes a DL RLC PDU and / or a DL RLC PDU segment. Each MAC SDU includes at least one DL RLC PDU and / or at least one DL RLC PDU segment. The MAC 204B retrieves the MAC SDU from the DL MAC PDU. The MAC 204B sends 734 the MAC SDU to the RLC 206B. The RLC 206B retrieves the DL PDCP PDU from the DL RLC PDU and / or the DL RLC PDU segment and sends 736 the DL PDCP PDU to the PDCP 210. The PDCP 210 retrieves the DL data packet from the DL PDCP PDU and sends 738 the DL data packet to the upper layer 220. In some implementations, the DL data packets are IP packets, Ethernet packets, or SDAP PDUs.

[0236] Events 728, 730, 732 and events 734, 736, 738 may or may not overlap. Events 728, 730, 732, 718, 734, 736, and 738 may overlap or not overlap. Fig. 7A It is collectively referred to as SDT data communication 782.

[0237] In some implementations, during the SDT session, the upper layer 220 (eg, the MM sublayer) communicates UL data and / or DL ​​data with the RAN 105 via the RRC 214, the PDCP 210, the RLC 206B, and the MAC 204B (see, e.g., Figure 7B SDT data communication 783).

[0238] In a further implementation, at a later time, the RAN 105 determines to stop the SDT session (e.g., as directed to Figure 4106B. In response to the determination, the RAN 105 generates an RRC release message to stop the SDT session and configure the UE 102 to remain in an inactive state, and transmits the RRC release message to the UE 102, similar to events 332, 334, 432, 434. The RAN 105 transmits 740 a DL MAC PDU including the RRC release message to the UE 102. In some implementations, the RAN 105 generates an RRC PDU (e.g., a DL-DCCH message) including the RRC release message, and generates a DL PDCP PDU including the RRC PDU message. In one implementation, the RAN 105 generates a DL RLC PDU including the DL PDCP PDU, generates a DL MAC PDU including the DL RLC PDU, and transmits 740 the DL MAC PDU to the UE 102. The MAC 204B retrieves the DL RLC PDU from the DL MAC PDU and sends 742 the DL RLC PDU to the RLC 206B. The RLC 206B retrieves the DL PDCP PDU from the DL RLC PDU and transmits 744 the DL PDCP PDU to the PDCP 210. The RRC 214 retrieves the RRC release message from the RRC PDU. In other implementations, the RAN 105 generates DL RLC PDU segments including the DL PDCP PDU. Each DL RLC PDU segment includes a specific portion of the DL PDCP PDU. The RAN 105 generates a DL MAC PDU, each DL MAC PDU including a specific DL RLC PDU segment in the DL RLC PDU segments, and transmits 740 the DL MAC PDU to the UE 102. The MAC 204B retrieves the DL RLC PDU segments from the DL MAC PDU and transmits 742 the DL RLC PDU segments to the RLC 206B. The RLC 206B retrieves the DL PDCP PDU from the DL RLC PDU segments and transmits 744 the DL PDCP PDU to the PDCP 210.

[0239] After receiving the DL PDCP PDU, the PDCP 210 retrieves the RRC PDU from the DL PDCP PDU and sends 746 an RRC PDU message to the RRC 214. The RRC 214 retrieves the RRC release message from the RRC PDU. The RRC 214 stops the SDT session in response to the RRC release message and remains in an inactive state. In some implementations, after receiving the RRC release message or in response to receiving the RRC release message, the RRC 214 sends 748 a connection suspension indication to the upper layer 220 indicating that the connection is suspended. Therefore, the upper layer 220 determines that the connection is suspended based on the connection suspension indication.

[0240] In a further implementation, after or in response to receiving the RRC release message, the RRC 214 sends 750 to the MAC 204B an indication (e.g., a suspend indication, a stop (SDT) indication, or a release indication) indicating to stop communicating with the RAN 105. In response to the indication 750, the MAC 204B stops communicating with the RAN 105. Depending on the implementation, in response to receiving the indication 750, the MAC 204B instructs the PHY 202B to stop communicating with the RAN 105. Alternatively, the RRC 214 sends to the PHY 202B an indication that the PHY 202B stops communicating with the RAN 105 ( Fig. 7A In response to an instruction from MAC 202B or RRC 214, PHY 202B stops communicating with RAN 105. For example, stopping communication includes stopping monitoring a PDCCH with an ID of UE 102. The ID includes a C-RNTI and / or a CS-RNTI. When stopping monitoring a PDCCH with an ID of UE 102, UE 102 monitors a PDCCH with one or more public RNTIs for receiving paging or system information. For example, the public RNTI includes a paging RNTI (P-RNTI) and / or a system information RNTI (SI-RNTI).

[0241] Next reference Figure 7B , scenario 700B depicts a small data transmission, similar to scenario 700A. Fig. 7A and Figure 7B The difference between.

[0242] In scenario 700B, upper layers 220 sends 711 UL data to RRC 214 instead of PDCP 212. In some implementations, the UL data may include NAS PDUs. RRC 214 generates a UL RRC PDU including the UL data and sends 713 the UL RRC PDU to PDCP 212. PDCP 212 generates a UL PDCP PDU including the UL RRC PDU and sends 714 the UL PDCP PDU to RLC 206B.

[0243] In some implementations, after receiving 726 the connection recovery message, the upper layers 220 sends 727 subsequent UL data packets (e.g., NAS PDUs or LPP PDUs) to the RRC 214. For each subsequent UL data packet, the RRC 214 generates a UL RRC PDU including the subsequent UL data packet and sends 729 the UL RRC PDU to the PDCP 210. When the PDCP 210 receives 736 a DL PDCP PDU from the RLC 206B, the PDCP 210 retrieves the DL RRC PDU from the DL PDCP PDU and sends 737 the DL RRC PDU to the RRC 214. The RRC 214 retrieves the DL data packet (e.g., NAS PDUs or LPP PDUs) from the DL RRC PDU and sends 739 the DL data packet to the upper layers 220.

[0244] Events 727, 729, 730, 732, 718, 734, 736, 737, and 739 Figure 7B It is collectively referred to as SDT data communication 783.

[0245] In some implementations, during an SDT session, upper layers 220 (e.g., data connection manager, packet processor, SDAP sublayer 212, etc.) communicate UL data packets and / or DL ​​data packets with RAN 105 via RRC 214, PDCP 210, RLC 206B, and MAC 204B (see, e.g., Fig. 7A In some implementations, the communication of UL data packets and / or DL ​​data packets overlaps with the SDT communication 783. In other implementations, the communication of UL data packets and / or DL ​​data packets occurs before or after the SDT communication 783.

[0246] Next reference Figure 7C , scenario 700C depicts a small data transfer, similar to scenarios 700A and 700B. Fig. 7A , Figure 7B and Figure 7C The difference between.

[0247] In scenario 700C, when upper layer 220 has UL data available for transmission, upper layer 220 sends 712 UL data to PDCP 210. Depending on the implementation, the UL data includes NAS PDUs or data packets (e.g., IP packets, Ethernet packets, or SDAP PDUs), as described above. When the connection is suspended, PDCP 210 buffers the UL data and sends 705 a connection recovery request message to RRC 214. In response to or after receiving the connection recovery request message, RRC 214 initiates 706 an SDT procedure (i.e., UE 102 starts an SDT session). In some implementations, RRC 214 sends 709 a connection recovery request confirmation message to PDCP 210, thereby confirming that RRC 214 received or is processing the connection recovery request message. After receiving 709 the connection recovery request confirmation message, PDCP 210 sends 714 a UL PDCP PDU to RLC 206B. In some implementations, SDT data communication 782 and SDT data communication 783 overlap. In other implementations, SDT data communication 782 occurs before or after SDT data communication 783.

[0248] Next, refer to Figures 3 to 7C Several example methods that may be implemented in a UE (eg, UE 102) to support small data transmission with a base station DU, CU, or other devices in a RAN in an inactive state are discussed.

[0249] Fig. 8A A method 800A for handling small data communications that can be implemented by a UE (eg, UE 102) is shown. Specifically, the method 800A is used to determine whether to transmit SDT data to a RAN (eg, RAN 105) using a UL grant based on whether the UE has UL data to transmit.

[0250] Method 800A begins at block 802, where the UE communicates with the RAN using a non-SDT configuration when operating in a connected state (e.g., events 304, 312, 314, 320, 550, 552, 518, 588, 589, 619). At block 804, the UE receives an RRC release message including a first SDT configuration from the RAN (e.g., events 332, 334, 432, 434, 394, 494, 495, 594, 595, 694, 695). At block 806, the UE receives a SIB from the RAN via a cell. At block 808, while operating in an inactive state, the UE performs SDT (i.e., initiates an SDT session) with the RAN via the cell according to the first SDT configuration (e.g., events 404, 418, 492, 493, 420, 494, 495, 592, 593, 594, 595, 692, 694, 695, 706, 710, 711, 712, 713, 714, 716, 719, 720, 722, 724, 780). At block 810, the UE obtains an UL grant for SDT during the SDT session. In some implementations, the UL grant is a dynamic grant (e.g., DCI), and a DU of the RAN (e.g., DU 174) transmits the dynamic grant to the UE on the PDCCH. In other implementations, the UL grant is a configured grant, and the first SDT configuration includes a configured grant configuration that configures the configured grant.

[0251] At block 812, the UE determines whether the UE has UL data to transmit during the SDT session. In some implementations, the UL data is data that meets the SDT condition (i.e., SDT data). If the UE determines that the UE has UL data to transmit, the process proceeds to block 814. At block 814, the UE transmits a first UL MAC PDU including the UL data or a portion of the UL data to the RAN using the UL grant (e.g., events 418, 492, 493, 592, 692, 693, 727, 729, 730, 732, 718). Otherwise, if the UE determines that the UE has no data to transmit, the process proceeds to block 820. At block 820, the UE transmits a second UL MAC PDU to the RAN using the UL grant (e.g., events 418, 492, 493, 592, 692, 693, 718).

[0252] In some implementations, the SIB (e.g., SIB1) includes a second SDT configuration. For example, the second SDT configuration is an SDT-ConfigCommonSIB IE (e.g., as defined in 3GPP specification v17.0.0). In some implementations, the second SDT configuration includes a logical channel timer value (e.g., sdt-LogicalChannelSR-DelayTimer-r17 as defined in 3GPP specification v17.0.0). In some implementations, the second SDT configuration includes configuration parameters for UL transmission skipping configured for SDT (e.g., CG-SDT). In some implementations, the second SDT configuration includes an RSRP range for the SDT (e.g., sdt-RSRP-Threshold-r17 or RSRP-Range). In some implementations, the second SDT configuration includes an SDT timer value (e.g., t319a-r17).

[0253] In some implementations, the UE performs SDT with the RAN via the cell according to the first SDT configuration and the second SDT configuration at block 808. In other implementations, the UE avoids applying the second SDT configuration to perform SDT at block 808. In some additional implementations, if the SDT is a CG-SDT, the UE avoids applying the second SDT configuration to perform SDT via the cell at block 808. Otherwise, if the SDT is a RA-SDT, the UE applies the second SDT configuration to perform SDT at block 808.

[0254] In some implementations, the first UL MAC PDU includes at least one MAC control element (CE) and at least one subheader for the at least one MAC CE. For example, the at least one MAC CE includes a BSR, and the at least one subheader includes a subheader for the BSR. In another example, the at least one MAC CE includes a PHR, and the at least one subheader includes a subheader for the PHR.

[0255] In some implementations, the second UL MAC PDU includes 1) at least one MAC CE and at least one subheader for the at least one MAC CE and / or 2) padding bits and a subheader for the padding bits. In other words, the second UL MAC PDU does not include SDT data. For example, the at least one MAC CE includes a BSR, and the at least one subheader includes a subheader for the BSR. In another example, the at least one MAC CE includes a PHR, and the at least one subheader includes a subheader for the PHR.

[0256] In some implementations, the non-SDT configuration includes configuration parameters in an RRC reconfiguration message (e.g., an RRCReconfiguration message). In some implementations, the configuration parameters include measurement configuration, and SRB configuration (e.g., SRB-ToAddMod IE) and / or DRB configuration (e.g., DRB-ToAddMod IE) associated with the SRB and / or DRB of the UE. In some implementations, the configuration parameters of the non-SDT configuration also include a cell group configuration (e.g., CellGroupConfig IE). The cell group configuration includes physical layer configuration parameters (e.g., PhysicalCellGroupConfig IE), MAC configuration parameters (e.g., MAC-CellGroupConfig IE), and RLC configuration parameters (e.g., one or more RLC bearer configurations (e.g., RLC-BearerConfig IE)) associated with all SRBs and / or DRBs of the UE, respectively. For example, the physical configuration parameters include beam-related configuration parameters, MIMO configuration parameters, SRS configuration parameters, physical channel configuration parameters, and / or BWP configuration parameters.

[0257] Figure 8B is a flow chart of an example method 800B, which is similar to method 800A except that method 800B further includes blocks 816 and 818. In this way, the UE determines whether to transmit a data packet when the UE has no UL data to transmit based on whether the first SDT configuration configures UL transmission skipping.

[0258] Specifically, at block 816, the UE determines whether the first SDT configuration configures UL transmission skipping. If the first SDT configuration configures UL transmission skipping, the process proceeds to block 818. At block 818, the UE avoids using UL grants to transmit UL MACPDUs. Otherwise, if the first SDT configuration does not configure UL transmission skipping, the process proceeds to block 820.

[0259] Figure 8C is a flow chart of an example method 800C, which is similar to methods 800A and 800B, except that method 800C includes block 815 instead of block 816. In this way, the UE determines whether to transmit a data packet based on whether the SIB is configured and / or whether the UE supports UL transmission skipping.

[0260] Specifically, at block 815, the UE determines whether the SIB configures UL transmission skipping and / or whether the UE supports UL transmission skipping. If the SIB configures UL transmission skipping and / or the UE supports UL transmission skipping, the process proceeds to block 818. Otherwise, if the SIB does not configure UL transmission skipping and / or the UE does not support UL transmission skipping, the process proceeds to block 820.

[0261] Fig.8D is a flow chart of an example method 800D, which is similar to methods 800A, 800B, and 800C, except that method 800D includes block 817 instead of blocks 815 and 816. In this way, the UE determines whether to transmit a data packet based on whether UL transmission skipping is configured for non-SDT configuration.

[0262] Specifically, at block 817, the UE determines whether the non-SDT configuration configures UL transmission skipping. If the non-SDT configuration configures UL transmission skipping, the process proceeds to block 818. Otherwise, if the non-SDT configuration does not configure UL transmission skipping, the process proceeds to block 820.

[0263] Fig. 9A An example method 900A for processing small data communications that can be implemented by a UE (e.g., UE 102) is shown. Specifically, method 900A is a method for determining whether to enable UL transmission skipping based on whether UL transmission skipping is configured in the SDT configuration before determining whether to transmit SDT data or data packets.

[0264] Method 900A starts at block 901, where the flow proceeds to blocks 802, 804, and 806 described with respect to FIG. 8. At block 916, the UE determines whether the first SDT configuration configures UL transmission skipping. If the first SDT configuration configures UL transmission skipping, the flow proceeds to block 903. At block 903, the UE enables the UL transmission skipping function. Otherwise, if the first SDT configuration does not configure UL transmission skipping, the flow proceeds to block 905. At block 905, the UE disables the UL transmission skipping function. The flow proceeds from block 903 and from block 905 to block 908.

[0265] At block 908, while operating in the inactive state, the UE performs SDT (i.e., initiates an SDT session) with the RAN (e.g., RAN 105) via the cell according to the first SDT configuration (e.g., events 404, 418, 492, 493, 420, 494, 495, 592, 593, 594, 595, 692, 694, 695, 706, 710, 711, 712, 713, 714, 716, 719, 720, 722, 724, 780). At block 910, the UE obtains an UL grant for SDT during the SDT session. At block 912, the UE determines whether the UE has UL data to transmit during the SDT session. If the UE has UL data to transmit, the flow proceeds to block 914. At block 914, the UE transmits a first UL MAC PDU including UL data or a portion of UL data to the RAN using the UL grant (e.g., events 418, 492, 493, 592, 692, 693, 727, 729, 730, 732, 718). Otherwise, if the UE has no data to transmit, the process proceeds to block 919. At block 919, the UE determines whether the UL transmission skip function is enabled. If the UL transmission skip function is enabled, the process proceeds to block 918. At block 918, the UE avoids transmitting the UL MAC PDU using the UL grant. Otherwise, if the UL transmission skip function is not enabled, the process proceeds to block 920. At block 920, the UE transmits a second UL MAC PDU to the RAN using the UL grant (e.g., events 418, 492, 493, 592, 692, 693, 718).

[0266] Fig. 9B is a flow chart of an example method 900B, which is similar to method 900A, except that method 900B includes block 915 instead of block 916. In this way, the UE determines whether to enable UL transmission skipping based on whether the SIB configures UL transmission skipping and / or whether the UE supports UL transmission skipping.

[0267] Specifically, at block 915, the UE determines whether the SIB configures UL transmission skipping and / or whether the UE supports UL transmission skipping. If the SIB configures UL transmission skipping and / or the UE supports UL transmission skipping, the process proceeds to block 903. Otherwise, if the SIB does not configure UL transmission skipping and / or the UE does not support UL transmission skipping, the process proceeds to block 905.

[0268] Fig. 9Cis a flow chart of an example method 900C, which is similar to methods 900A and 900B, except that method 900C includes block 917 instead of blocks 916 and 915. In this way, the UE determines whether to enable UL transmission skipping based on whether UL transmission skipping is configured for non-SDT configuration.

[0269] Specifically, at block 917, the UE determines whether the non-SDT configuration configures UL transmission skipping. If the non-SDT configuration configures UL transmission skipping, the process proceeds to block 903. Otherwise, if the non-SDT configuration does not configure UL transmission skipping, the process proceeds to block 905.

[0270] against Figures 8A-8D The examples and implementations described can be applied to FIG. 9A to FIG. 9B .

[0271] Fig. 10A 1 is a flow chart of an example method 1000A that may be implemented by a UE (eg, UE 102) for managing small data communications. Specifically, method 1000A is a method for generating a UE capability IE including non-SDT, SDT, and UL transmission skipping capabilities.

[0272] Method 1000A begins at block 1002, where a UE communicates with a base station of a RAN (e.g., RAN 105). At block 1004, the UE determines to transmit a UE capability IE. At block 1006, the UE generates a UE capability IE including a plurality of non-SDT capabilities, one or more SDT capabilities, and a first capability indicating support for UL transmission skipping. At block 1008, the UE transmits the UE capability IE to the base station in response to the determination. At block 1010, the flow proceeds to one of methods 800B, 800C, 900A, or 900C.

[0273] In some implementations, the UE determines to transmit the UE capability IE in response to receiving a UECapabilityEnquiry message from the base station. In some implementations, the UE capability IE is a UE-NR-Capability IE or a UE-6G-Capability IE. In some implementations, the UE transmits a message (e.g., an RRC message, such as a UECapabilityInformation message) including the UE capability IE to the base station at box 1008. Therefore, the base station can determine that the UE supports UL transmission skipping based on the first capability. In some implementations, the first capability is specific to UL transmission skipping for SDT (e.g., sdt-SkipUplinkTxDynamic-r17, sdt-SkipUplinkTxConfigured-r17, sdt-SkipUplinkTxDynamic-v17xy (x >1, y >1) and sdt-SkipUplinkTxConfigured-v17ab (a >1, b >1)).

[0274] In other implementations, the first capability applies to both SDT and non-SDT communications. In such implementations, if the DU receives the UE's SDT capability (e.g., CG-SDT capability, such as cg-SDT or cg-SDT-r17) and UL transmission skipping capability (e.g., skipUplinkTxDynamic, enhancedSkipUplinkTxConfigured-v1660, enhancedSkipUplinkTxDynamic-r16, enhancedSkipUplinkTxDynamic-r1660) from the CU, the DU determines that the UE supports UL transmission skipping for SDT. The SDT capability indicates that the UE supports SDT (e.g., CG-SDT). If the DU receives the first capability and does not receive the UE's SDT capability, the base station determines that the UE supports UL transmission skipping for non-SDT (i.e., data transmission when the UE is operating in a connected state).

[0275] In other implementations, the first capability is a general SDT capability. In such implementations, if the base station receives a general SDT capability (e.g., CG-SDT capability, such as cg-SDT-r17) and an UL transmission skip capability (e.g., skipUplinkTxDynamic, enhancedSkipUplinkTxConfigured-v1660, enhancedSkipUplinkTxDynamic-r16, enhancedSkipUplinkTxDynamic-r1660) of the UE, the DU determines that the UE supports UL transmission skipping of SDT. The general SDT capability indicates that the UE supports SDT (e.g., CG-SDT).

[0276] Fig. 10B 1000B is a flow chart of an example method 1000B, which is similar to method 1000A and method 900B, except that method 1000B includes blocks 1005 and 1007 instead of blocks 1004, 1006, and 1008. In this way, the UE transmits a UE capability identifier to the base station, the UE capability identifier identifying the stored UE capabilities for non-SDT, SDT, and UL transmission skipping capabilities.

[0277] Specifically, at block 1005, the UE determines to transmit a UE capability ID. At block 1007, the UE transmits a message including the UE capability ID to the base station in response to the determination, wherein the UE capability identification includes a plurality of non-SDT capabilities, one or more SDT capabilities, and a UE capability IE indicating a first capability of supporting UL transmission skipping.

[0278] In some implementations, the message is a UL NAS message (e.g., a Registration Request message), and the base station forwards the UL NAS message to the CN (e.g., the CN 110 including the AMF 164). The CN obtains the UE capability IE (e.g., from a storage area) based on the UE capability ID and transmits the UE capability IE to the base station. Alternatively, the CN transmits the UE capability ID to the base station, and the base station obtains the UE capability IE (e.g., from a storage area) based on the UE capability ID. The UE receives a DL NAS message (e.g., a Registration Accept message) from the CN in response to the UL NAS message.

[0279] Fig.11A 1 is a flow chart of an example method 1100A for managing small data communications that can be implemented by a UE (e.g., UE 102). Specifically, the method 1100A is a method for determining whether to use a UL grant to transmit SDT data after generating UE capability information and transmitting it to a RAN (e.g., RAN 105) node (e.g., base station 104).

[0280] Method 1100A begins at block 1102, where the UE communicates with a base station of the RAN (e.g., events 304, 312, 314, 320, 550, 552, 518, 588, 589, 619). At block 1104, the UE determines to transmit a UE capabilities IE. At block 1106, the UE generates a UE capabilities IE including a plurality of non-SDT capabilities and one or more SDT capabilities and excluding a first capability indicating support for UL transmission skipping. At block 1108, the UE responds to the determination at block 1104 and transmits the UE capabilities IE to the base station when communicating with the base station. At block 1110, the flow proceeds to blocks 802, 804, 806, 808, and 810. At block 1112, the UE determines whether the UE has UL data to transmit. If the UE has UL data to transmit, the flow proceeds to block 1114. At block 1114, the UE transmits a first UL MAC PDU including UL data or a portion of UL data to the RAN using the UL grant (e.g., events 418, 492, 493, 592, 692, 693, 727, 729, 730, 732, 718). Otherwise, if the UE has no data to transmit, the flow proceeds to block 1120. At block 1120, the UE transmits a second UL MAC PDU to the RAN using the UL grant (e.g., events 418, 492, 493, 592, 692, 693, 718).

[0281] against FIG. 8A to FIG. 8D and Fig. 10A The examples and implementations described can be applied to Fig.11A .

[0282] Fig. 11B is a flow chart of an example method 1100B that is similar to method 1100A except that method 1100B includes blocks 1105 and 1107 instead of blocks 1104, 1106, and 1108. In this manner, the UE transmits the UE capability identifier to the base station identifying the stored UE capabilities.

[0283] Specifically, at block 1105, the UE determines to transmit a UE capability ID. At block 1107, the UE transmits a message including the UE capability ID to the base station in response to the determination at block 1105 and when communicating with the base station, wherein the UE capability identification includes a plurality of non-SDT capabilities and one or more SDT capabilities and excludes a UE capability IE indicating a first capability of supporting UL transmission skipping.

[0284] against FIG. 8A to FIG. 8D and Fig. 10B The examples and implementations described can be applied to Fig. 11B .

[0285] Fig.121 is a flow chart of an example method 1200 that can be implemented by a UE (e.g., UE 102) for managing small data communications. Specifically, method 1200 is a method for determining whether to indicate to a RAN (e.g., RAN 105) node (e.g., base station 104) that the UE supports transmission skipping.

[0286] Method 1200 begins at block 1202, where the UE communicates with a base station while operating in a connected state (e.g., events 304, 312, 314, 320, 550, 552, 518, 588, 589, 619). At block 1204, the UE determines to transmit a UE capabilities IE. At block 1206, the UE includes a plurality of non-SDT capabilities and one or more SDT capabilities in the UE capabilities IE. At block 1208, the UE determines whether UL transmission skipping is supported. If UL transmission skipping is supported, the process proceeds to block 1210. At block 1210, the UE includes a first capability indicating support for UL transmission skipping of SDT in the UE capabilities IE. Otherwise, if UL transmission skipping is not supported, the process proceeds to block 1212. At block 1212, the UE avoids including the first capability in the UE capabilities IE. At block 1214, the UE transmits the UE capabilities IE to the base station while communicating with the base station. Flow continues from box 1212 and from box 1210 to box 1214.

[0287] against Fig. 10A The examples and implementations described can be applied to Fig.12 .

[0288] Fig.13A 1 is a flow chart of an example method 1300A for managing small data communications that can be implemented by a UE (e.g., UE 102). Specifically, the method 1300A is a method for communicating with a RAN (e.g., RAN 105) node (e.g., base station 104) via an SDT configuration and avoiding communicating via a non-SDT configuration in an inactive state.

[0289] Method 1300A begins at block 1302A, where the UE communicates with the RAN using a non-SDT configuration while operating in a connected state (e.g., events 304, 312, 314, 320, 550, 552, 518, 588, 589, 619). At block 1304, the UE receives an RRC release message including a first SDT configuration from the RAN (e.g., events 332, 334, 432, 434, 394, 494, 495, 594, 595, 694, 695). At block 1306, the UE receives a SIB from the RAN via a cell. At block 1308, while operating in the inactive state, the UE performs SDT with the RAN via the cell according to the first SDT configuration (e.g., events 404, 418, 492, 493, 420, 494, 495, 592, 593, 594, 595, 692, 694, 695, 706, 710, 711, 712, 713, 714, 716, 719, 720, 722, 724, 780). At block 1310, the UE avoids communicating with the RAN using a non-SDT configuration during the SDT. At block 1312, the UE transitions from the inactive state to the connected state during the SDT (e.g., events 545, 546, 645, 646). At block 1314, the UE communicates with the RAN using at least a portion of the non-SDT configuration while operating in the connected state (e.g., events 550, 552, 518, 590, 594).

[0290] In some implementations, the SIB includes a second SDT configuration and is SIB1 or a new SIB. In some implementations, the second SDT configuration also includes a first RSRP threshold (e.g., sdt-RSRP-Threshold, sdt-RSRP-Threshold-r17, or RSRP-Range), a data volume threshold (e.g., sdt-DataVolumeThreshold or sdt-DataVolumeThreshold-r17), an SDT timer value (e.g., t319a-r17), and / or a logical channel delay timer value (e.g., sdt-LogicalChannelSR-DelayTimer or sdt-LogicalChannelSR-DelayTimer-r17). In some implementations, the second SDT configuration is SDT-ConfigCommonSIB or SDT-ConfigCommonSIB-r17IE. The UE measures a DL signal from a cell and obtains a first RSRP value from the measurement. In some implementations, if the first RSRP value is higher than a first RSRP threshold and the UL data available for transmission is lower than a data amount threshold, the UE performs an SDT (e.g., RA-SDT) with the RAN via the cell. Otherwise, the UE performs an RRC recovery procedure with the RAN and transitions to a connected state to transmit UL data.

[0291] In some implementations, the first SDT configuration includes a second RSRP threshold (e.g., cg-SDT-RSRP-Threshold, cg-SDT-RSRP-ThresholdSSB, cg-SDT-RSRP-ThresholdSSB-r17, or RSRP-Range). The UE performs measurements on the SSB from the cell and obtains a second RSRP value from the measurements. In some implementations, if the first RSRP value is higher than the first RSRP threshold, the second RSRP value is higher than the second RSRP threshold, and the UL data available for transmission is lower than the data amount threshold, the UE performs an SDT (e.g., CG-SDT) with the RAN via the cell to transmit the UL data. Otherwise, if the first RSRP value is higher than the first RSRP threshold and the UL data available for transmission is lower than the data amount threshold, the UE performs an SDT (e.g., RA-SDT) with the RAN via the cell to transmit the UL data. Otherwise, the UE performs an RRC recovery procedure with the RAN and transitions to a connected state to transmit the UL data.

[0292] In some implementations, the RAN node configures the DL signal measured by the UE. For example, the RAN node configures the DL signal as SSB so that the UE does not need to perform additional measurements to obtain the second RSRP value. In this example, the first RSRP value and the second RSRP value are the same value. In another example, the RAN node can configure the DL signal to be partially the same as or different from the SSB so that the UE does not need to perform separate measurements to obtain the first RSRP value and the second RSRP value, respectively.

[0293] In some implementations, the non-SDT configuration includes physical layer configuration parameters (e.g., PhysicalCellGroupConfig IE) and / or MAC configuration parameters (e.g., MAC-CellGroupConfig IE). In some implementations, the UE avoids using the first SDT configuration to communicate with the RAN when operating in a connected state.

[0294] Fig. 13B 1300B is a flow chart of an example method 1300B, which is similar to method 1300A, except that method 1300B includes blocks 1309, 1311, and 1315 instead of blocks 1308, 1310, and 1314. In this way, the UE communicates with the RAN node via the SDT configuration and a portion of the non-SDT configuration when in an inactive state.

[0295] Specifically, at box 1309, when operating in an inactive state, the UE performs SDT with the RAN via a cell according to the first SDT configuration and the first partial non-SDT configuration (e.g., events 404, 418, 492, 493, 420, 494, 495, 592, 593, 594, 595, 692, 694, 695, 706, 710, 711, 712, 713, 714, 716, 719, 720, 722, 724, 780). At box 1311, the UE avoids using the second part of the non-SDT configuration to communicate with the RAN during the SDT. At box 1315, when operating in a connected state, the UE communicates with the RAN using at least a portion of the non-SDT configuration (e.g., events 550, 552, 518, 590, 594).

[0296] In some implementations, the non-SDT configuration includes configuration parameters in an RRC reconfiguration message (e.g., an RRCReconfiguration message). In some implementations, the configuration parameters include measurement configurations, and SRB configurations (e.g., SRB-ToAddMod IE) and / or DRB configurations (e.g., DRB-ToAddMod IE) associated with the SRBs and / or DRBs of the UE. In this case, the first part of the non-SDT configuration includes some or all of the SRB configurations (e.g., SRB-ToAddMod IE) and / or some or all of the DRB configurations (e.g., DRB-ToAddMod IE), which are associated with the DRBs or SRBs configured for SDT. The second part of the non-SDT configuration includes measurement configurations. Depending on the implementation, the second part of the non-SDT configuration includes some of the SRB configurations and / or some or all of the DRB configurations, which are associated with the DRBs or SRBs configured for non-SDT (if any).

[0297] In some implementations, the configuration parameters of the non-SDT configuration also include a cell group configuration (e.g., CellGroupConfig IE). The cell group configuration includes physical layer configuration parameters (e.g., PhysicalCellGroupConfig IE), MAC configuration parameters (e.g., MAC-CellGroupConfigIE), and RLC configuration parameters (e.g., one or more RLC bearer configurations (e.g., RLC-BearerConfig IE)) associated with all SRBs and / or DRBs of the UE, respectively. For example, the physical configuration parameters include beam-related configuration parameters, MIMO configuration parameters, SRS configuration parameters, physical channel configuration parameters, and BWP configuration parameters.

[0298] In some implementations, the first part of the non-SDT configuration includes some or all of one or more RLC bearer configurations associated with the SRBs and / or DRBs of the SDT. In some implementations, the second part of the non-SDT configuration includes some of one or more RLC bearer configurations associated with the SRBs and / or DRBs of the non-SDT, MAC configuration parameters, and / or physical layer configuration parameters. In other implementations, the first part of the non-SDT configuration includes the first part of the MAC configuration parameters, and the second part of the non-SDT configuration includes the second part of the MAC configuration parameters and / or the physical layer configuration parameters. For example, the first part of the MAC configuration parameters includes a UL transmission skip configuration and / or a data inactivity timer value, and the second part of the MAC configuration parameters includes a DRX configuration, a BSR configuration, a PHR configuration, and / or a scheduling request configuration.

[0299] In some implementations, the portion of the non-SDT configuration includes a first portion of the non-SDT configuration. In some implementations, the portion of the non-SDT configuration includes a measurement configuration, and an SRB configuration and / or a DRB configuration associated with the SRB and / or DRB of the UE, respectively. In some implementations, the portion of the non-SDT configuration includes one or more RLC bearer configurations associated with the SRB and / or DRB of the UE. In some implementations, the portion of the non-SDT configuration includes a portion of physical layer configuration parameters and a portion of MAC configuration parameters. In other implementations, the portion of the non-SDT configuration does not include physical layer configuration parameters. In some implementations, the UE avoids using the first SDT configuration to communicate with the RAN when operating in a connected state.

[0300] Fig.14A 14 is a flow chart of an example method 1400A that may be implemented by a DU (e.g., DU 174) for managing uplink transmission skipping of a UE (e.g., UE 102). Specifically, the method 1400A is a method for including a transmission skip configuration in an SDT configuration to configure a UE.

[0301] Method 1400A begins at block 1402, where the DU receives a CU-to-DU message from the CU requesting an SDT configuration for the UE (e.g., events 328, 394, 428, 494, 495, 594, 595, 694, 695). At block 1404, the DU includes at least one of the SDT configurations to configure the SDT for the UE. At block 1406, the DU includes an UL transmission skip configuration in the SDT configuration to configure UL transmission skip for the UE. At block 1408, the DU transmits a DU-to-CU message including the SDT configuration to the CU in response to the CU-to-DU message (e.g., events 330, 394, 430, 494, 495, 594, 595, 694, 695).

[0302] In some implementations, the CU-to-DU message includes an SDT indication (eg, a CG-SDT query indication) indicating that the CU requests the DU to provide an SDT configuration. The DU includes the SDT configuration in the DU-to-CU message in response to the SDT indication.

[0303] In some implementations, the DU receives an RRC release message including an SDT configuration from the CU and transmits the RRC release message to the UE (e.g., events 332, 334, 432, 434, 394, 494, 495, 594, 595, 694, 695). The UE transitions to an inactive state or remains in an inactive state in response to the RRC release message (e.g., events 336, 436, 536, 636). The UE in the inactive state initiates or performs an SDT session with the DU and the CU after receiving the SDT configuration. In the case where the UE obtains UL authorization and there is no SDT data to transmit during the SDT session, the UE avoids transmitting an UL MAC PDU to the DU because the UL transmission skip configuration allows the UE to do so.

[0304] In some implementations, the DU determines that the UE supports UL transmission skipping for SDT, and in response to the determination, includes the UL transmission skipping configuration in the SDT configuration. In some implementations, the DU determines whether the DU receives the UL transmission skipping capability of the UE from the CU, and the UL transmission skipping capability indicates that the UE supports UL transmission skipping. For example, the DU receives a UE capability IE (e.g., UE-NR-Capability IE or UE-6G-Capability) of the UE from the CU, and the UE capability IE includes the UL transmission skipping capability. In some implementations, the UL transmission skipping capability is specific to SDT (e.g., sdt-SkipUplinkTxDynamic-r17, sdt-SkipUplinkTxConfigured-r17, sdt-SkipUplinkTxDynamic-v17xy (x>1, y>1) and sdt-SkipUplinkTxConfigured-v114Ab (a>1, b>1)).

[0305] In other implementations, the UL transmission skip capability applies to both SDT and non-SDT. In such implementations, if the DU receives the UE's SDT capability (e.g., CG-SDT capability, such as cg-SDT or cg-SDT-r17) and UL transmission skip capability (e.g., skipUplinkTxDynamic, enhancedSkipUplinkTxConfigured-v1660, enhancedSkipUplinkTxDynamic-r16, enhancedSkipUplinkTxDynamic-r1660) from the CU, the DU determines that the UE supports UL transmission skipping for SDT. The SDT capability indicates that the UE supports SDT (e.g., CG-SDT). If the DU receives the UL transmission skip capability and does not receive the UE's SDT capability, the DU determines that the UE supports UL transmission skipping for non-SDT (i.e., data transmission when the UE is operating in a connected state).

[0306] In other implementations, if the UE supports SDT (e.g., CG-SDT), the UE automatically supports UL transmission skipping. In such cases, if the DU determines that the UE supports SDT (e.g., CG-SDT), the DU determines that the UE supports UL transmission skipping of SDT. For example, if the DU receives a general SDT capability (e.g., CG-SDT capability, such as cg-SDT or cg-SDT-r17) from the CU indicating that the UE supports SDT, the DU determines that the UE supports UL transmission skipping of SDT.

[0307] In some implementations, the DU enables a UL transmission skip detection function for the UE during an SDT session with the UE in response to configuring UL transmission skipping for the UE. In response to the enabling, the DU determines whether the UE skips UL transmission scheduled by the UL grant. In some implementations, the UL grant is a dynamic grant (e.g., DCI), and the DU transmits the dynamic grant to the UE on the PDCCH. In other implementations, the UL grant is a configured grant, and the SDT configuration includes a configured grant configuration to configure the configured grant. If the DU determines that the UE skips UL transmission, the DU avoids transmitting the DCI including the dynamic grant to the UE on the PDCCH. In some implementations, the DU detects energy on resources configured in the UL grant (e.g., time and frequency resources or physical resource blocks). If the energy is below a predetermined threshold, the DU determines that the UE skips UL transmission.

[0308] Fig. 14B is a flow chart of an example method 1400B, which is similar to method 1400A, except that method 1400B includes block 1407 instead of block 1406. Thus, the DU avoids including the transmission skip configuration in the SDT configuration.

[0309] Specifically, at block 1407, the DU avoids including the UL transmission skip configuration in the SDT configuration. Thus, in the case where the UE has no SDT data to transmit during the SDT session, the UE avoids skipping the UL transmission because the SDT configuration does not include the UL transmission skip configuration. In this case, the UE transmits a UL MAC PDU that does not include any UL data to the DU, i.e., the UL MAC PDU includes empty UL data.

[0310] In some implementations, the DU determines that the UE does not support UL transmission skipping. In such cases, the DU avoids including the UL transmission skipping configuration in the SDT configuration in response to the determination. In some implementations, the DU makes the determination when the DU does not receive the UL transmission skipping capability of the UE from the CU. For example, the DU receives a UE capability IE (e.g., a UE-NR-Capability IE or a UE-6G-Capability IE) of the UE from the CU, and the UE capability IE does not include the UL transmission skipping capability of the UE.

[0311] In some implementations, the DU determines that the DU does not support UL transmission skipping for SDT. In such cases, the DU avoids including the UL transmission skipping configuration in the SDT configuration in response to the determination. In other implementations, the DU is pre-configured to avoid including the UL skipping configuration in the SDT configuration when the DU generates the SDT configuration.

[0312] In some implementations, when the DU does not configure UL transmission skipping of the UE, the DU disables the UL transmission skip detection function of the UE. During an SDT session with the UE, when the DU receives a UL MAC PDU from the UE, the DU processes the UL MAC PDU. If the UL MAC PDU includes only a subheader for padding, the DU ignores or discards the UL MAC PDU after processing the subheader. In some implementations, if the UL MAC PDU includes only a MAC control element (e.g., a BSR), a subheader of the MAC control element, and a subheader for padding, the DU retrieves the MAC control element from the UL MAC PDU, processes at least one MAC control element, and ignores or discards the remaining portion of the UL MAC PDU after processing the subheader for padding.

[0313] Fig. 14C 1400C is a flow chart of an example method 1400C, which is similar to method 1400A and method 1400B, except that method 1400C also includes block 1405. In this way, the DU determines whether to include a transmission skip configuration in the SDT configuration based on whether the UE and / or DU supports UL transmission skipping.

[0314] Specifically, at block 1405, the DU determines whether the UE and / or DU supports UL transmission skipping. If the UE and / or DU supports UL transmission skipping, the flow proceeds to block 1406. Otherwise, if the UE and / or DU does not support UL transmission skipping, the flow proceeds to block 1407. The flow proceeds from block 1406 and from block 1407 to block 1408.

[0315] Fig.15 1 is a flow chart of an example method 1500 for managing uplink transmission skipping of a UE (e.g., UE 102) that may be implemented by a RAN node (e.g., base station 104 / 106 or DU 174). Specifically, the example method 1500 is a method for determining whether to include a transmission skip configuration based on whether the UE and / or the RAN node supports UL transmission skipping.

[0316] Method 1500 begins at block 1502, where the RAN node determines to configure SDT for the UE. At block 1504, the RAN node includes one or more configurations in the SDT configuration of the UE. At block 1505, the RAN node determines whether the UE and / or the RAN node supports UL transmission skipping. If the UE and / or the RAN node supports UL transmission skipping, the process proceeds to block 1506. At block 1506, the RAN node includes the UL transmission skipping configuration in the SDT configuration to configure UL transmission skipping for the UE. Otherwise, if the UE and / or the RAN node does not support UL transmission skipping, the process proceeds to block 1507. At block 1507, the RAN node refrains from including the UL transmission skipping configuration in the SDT configuration. The process proceeds from block 1506 and from block 1507 to block 1508. At block 1508, the RAN node transmits an RRC message including the SDT configuration to the UE (e.g., events 332, 334, 432, 434, 394, 494, 495, 594, 595, 694, 695).

[0317] Fig.16A 1 is a flow chart of an example method 1600A that may be implemented by a RAN node (e.g., base station 104 / 106 or DU 174) for managing uplink transmission skipping of a UE (e.g., UE 102). Specifically, method 1600A is a method for including a transmission skip configuration in an SDT configuration and broadcasting the SDT configuration on a cell.

[0318] Method 1600A begins at block 1602, where a RAN node enables SDT for a cell. At block 1604, the RAN node includes at least one first configuration in a first SDT configuration. At block 1606, the RAN node includes an UL transmission skip configuration in the first SDT configuration to configure UL transmission skip for the UE. At block 1608, the RAN node broadcasts a SIB including the first SDT configuration on the cell. At block 1610, the RAN node generates a second SDT configuration including at least one second configuration. At block 1612, the RAN node transmits an RRC release message (e.g., events 332, 334, 432, 434, 394, 494, 495, 594, 595, 694, 695) including the second SDT configuration to the UE.

[0319] In some implementations, the SIB is SIB1 or a new SIB. In some implementations, the first SDT configuration also includes an RSRP threshold (e.g., sdt-RSRP-Threshold-r17 or RSRP-Range IE), a data volume threshold (e.g., sdt-DataVolumeThreshold-r17), an SDT timer value (e.g., t319a-r17) and / or a logical channel delay timer value (e.g., sdt-LogicalChannelSR-DelayTimer-r17). In some implementations, the first SDT configuration is SDT-ConfigCommonSIB-r17 IE. In further implementations, the second SDT configuration is the above-mentioned SDT CU configuration and / or SDT DU configuration.

[0320] Fig. 16B 1600B is a flow chart of an example method 1600B, which is similar to method 1600A, except that method 1600B includes block 1607 instead of block 1606. Therefore, the RAN node avoids including the transmission skip configuration in the SDT configuration. Specifically, at block 1607, the RAN node avoids including the UL transmission skip configuration in the first SDT configuration.

[0321] Fig. 16C is a flow chart of an example method 1600C, which is similar to method 1600A and method 1600B, except that method 1600C also includes block 1605. In this way, the RAN node determines whether to include a transmission skip configuration based on whether the RAN node supports UL transmission skipping.

[0322] Specifically, at block 1605, the RAN node determines whether the RAN supports UL transmission skipping. If the RAN supports UL transmission skipping, the flow proceeds to block 1606. Otherwise, if the RAN does not support UL transmission skipping, the flow proceeds to block 1607. The flow proceeds from block 1606 and from block 1607 to block 1608.

[0323] Fig.17A 1700A is a flow chart of an example method 1700A that may be implemented by a DU (e.g., DU 174) for managing uplink transmission skipping of a UE (e.g., UE 102). Specifically, the method 1700A is a method for including a transmission skip configuration in a non-SDT configuration, transmitting the non-SDT configuration to the UE, and enabling a transmission skip detection function for the UE.

[0324] Method 1700A begins at block 1702, where the DU communicates with the UE and the CU (e.g., events 304, 492, 518, 588, 589, 592, 542, 544, 642, 644, 619). At block 1704, the DU determines to transmit a non-SDT configuration to the CU. At block 1706, the DU includes an UL transmission skip configuration in the non-SDT configuration to configure UL transmission skipping for the UE. At block 1708, the DU transmits a first DU-to-CU message including the non-SDT configuration to the CU (e.g., events 308, 390, 510, 588, 589, 590, 610, 690). At block 1710, the DU transmits a first RRC message including the non-SDT configuration to the UE (e.g., events 312, 390, 546, 588, 589, 590, 646, 690). At block 1712, the DU transmits a second DU-to-CU message including an SDT configuration to the CU (e.g., events 330, 394, 430, 494, 495, 594, 595, 694, 695). At block 1714, the DU transmits an RRC release message including an SDT configuration to the UE (e.g., events 334, 434, 394, 494, 495, 594, 595, 694, 695). At block 1716, the DU enables an UL transmission skip detection function of the UE during an SDT session with the UE (e.g., events 492, 494, 493, 495, 592, 692). Blocks 1706, 1708, 1710, 1712, 1714, and 1716 are grouped as block 1050.

[0325] Fig. 17B is a flow chart of an example method 1700B, which is similar to method 1700A, except that method 1700B includes blocks 1707 and 1717 instead of blocks 1706 and 1716. Thus, the DU avoids including the transmission skip configuration in the non-SDT configuration.

[0326] Specifically, at block 1707, the DU avoids including the UL transmission skip configuration in the non-SDT configuration. At block 1717, the DU disables the UL transmission skip detection function of the UE. Blocks 1707, 1708, 1710, 1712, 1714, and 1717 are grouped into block 1051.

[0327] Fig. 17C 1700C is a flow chart of an example method 1700C, which is similar to method 1700A and method 1700B, except that method 1700C also includes block 1705. In this way, the DU determines whether to include a transmission skip configuration in the non-SDT configuration based on whether the UE and / or DU supports UL transmission skipping.

[0328] Specifically, method 1700C begins at block 1702, where the DU communicates with the UE and the DU. At block 1704, the DU determines to transmit a non-SDT configuration to the CU. At block 1705, the DU determines whether the UE and / or the DU supports UL transmission skipping. If the UE and / or the DU supports UL transmission skipping, the process proceeds to block 1050. Otherwise, if the UE and / or the DU does not support UL transmission skipping, the process proceeds to block 1051.

[0329] against Figures 14A-14C The examples and implementations described can be applied to 17A to 17C .

[0330] Fig.18 1 is a flow chart of an example method 1800 for managing uplink transmission skipping of a UE (e.g., UE 102) that may be implemented by a RAN node (e.g., base station 104 / 106 or DU 174). Specifically, method 1800 is a method for determining whether to include a transmission skip configuration in a non-SDT configuration based on whether the UE and / or the RAN node supports UL transmission skipping.

[0331] Method 1800 begins at block 1802, where a RAN node communicates with a UE (e.g., events 304, 492, 542, 544, 518, 550, 552, 588, 589, 592, 642, 644, 650, 652, 619). At block 1804, the RAN node determines to transmit a non-SDT configuration to the UE. At block 1805, the RAN node determines whether the UE and / or the RAN node supports UL transmission skipping. If the UE and / or the RAN node supports UL transmission skipping, the process proceeds to block 1806. At block 1806, the RAN node includes the UL transmission skipping configuration in the non-SDT configuration to configure the UL transmission skipping for the UE. Otherwise, if the UE and / or the RAN node does not support UL transmission skipping, the process proceeds to block 1807. At block 1807, the RAN node refrains from including the UL transmission skipping configuration in the non-SDT configuration. Flow continues from box 1806 and from box 1807 to box 1808.

[0332] At block 1808, the RAN node transmits a first RRC message including a non-SDT configuration to the UE (e.g., events 310, 312, 390, 545, 546, 588, 589, 590, 645, 646, 690). At block 1814, the RAN node transmits an RRC release message including an SDT configuration to the UE (e.g., events 332, 334, 432, 434, 394, 494, 495, 594, 595, 694, 695). At block 1815, the RAN node determines whether to configure UL transmission skipping for the UE. If the RAN node determines to configure UL transmission skipping for the UE, the flow proceeds to block 1816. At block 1816, the RAN node enables a UL transmission skip detection function of the UE during the SDT session with the UE. Otherwise, if the RAN node determines not to configure UL transmission skipping for the UE, the flow proceeds to block 1817. At block 1817 , the RAN node disables the UE's UL transmission skip detection functionality.

[0333] against FIG. 14A to FIG. 14C The examples and implementations described can be applied to Fig.18 .

[0334] Fig.19A 1 is a flow chart of an example method 1900A that may be implemented by a RAN node (e.g., base station 104 / 106 or DU 174) for managing uplink transmission skipping of a UE (e.g., UE 102). Specifically, method 1900A is a method for communicating with a UE in an inactive state by using an SDT configuration and avoiding the use of a non-SDT configuration.

[0335] Method 1900A begins at block 1902, where a RAN node communicates with a UE operating in a connected state using a non-SDT configuration of the UE (e.g., events 304, 312, 314, 320, 550, 552, 518, 588, 589, 619). At block 1904, the RAN node transmits an RRC release message including a first SDT configuration to the UE (e.g., events 332, 334, 432, 434, 394, 494, 495, 594, 595, 694, 695). At block 1906, the RAN node broadcasts a SIB via a cell. At block 1908, the RAN node performs SDT with the UE operating in the inactive state via the cell according to the first SDT configuration and a portion of the non-SDT configuration (e.g., events 404, 418, 492, 493, 420, 494, 495, 592, 593, 594, 595, 692, 694, 695). At block 1910, the RAN node avoids using the non-SDT configuration to communicate with the UE during the SDT. At block 1912, the RAN node transitions the UE from the inactive state to the connected state during the SDT (e.g., events 545, 546, 645, 646). At block 1914, the RAN node communicates with the UE operating in the connected state using at least a portion of the non-SDT configuration (e.g., events 550, 552, 518, 590, 594).

[0336] In some implementations, the SIB includes a second SDT configuration and is SIB1 or a new SIB. In some implementations, the second SDT configuration also includes a first RSRP threshold (e.g., sdt-RSRP-Threshold, sdt-RSRP-Threshold-r17, or RSRP-Range), a data volume threshold (e.g., sdt-DataVolumeThreshold or sdt-DataVolumeThreshold-r17), an SDT timer value (e.g., t319a-r17), and / or a logical channel delay timer value (e.g., sdt-LogicalChannelSR-DelayTimer or sdt-LogicalChannelSR-DelayTimer-r17). In some implementations, the second SDT configuration is SDT-ConfigCommonSIB or SDT-ConfigCommonSIB-r17IE. The UE measures a DL signal from a cell and obtains a first RSRP value from the measurement. In some implementations, if the first RSRP value is higher than a first RSRP threshold and the UL data available for transmission is lower than a data volume threshold, the UE performs an SDT (e.g., RA-SDT) with the RAN node via the cell. Otherwise, the UE performs an RRC recovery process with the RAN node to transition to a connected state to transmit UL data. In a further implementation, the first SDT configuration includes a second RSRP threshold (e.g., cg-SDT-RSRP-Threshold, cg-SDT-RSRP-ThresholdSSB, cg-SDT-RSRP-ThresholdSSB-r17, or RSRP-Range). The UE performs measurements on the SSB from the cell and obtains a second RSRP value from the measurements. In some implementations, if the first RSRP value is higher than the first RSRP threshold, the second RSRP value is higher than the second RSRP threshold, and the UL data available for transmission is lower than the data volume threshold, the UE performs an SDT (e.g., CG-SDT) with the RAN node via the cell to transmit UL data. Otherwise, if the first RSRP value is higher than the first RSRP threshold and the UL data available for transmission is lower than the data amount threshold, the UE performs an SDT (e.g., RA-SDT) with the RAN node via the cell to transmit the UL data. Otherwise, the UE performs an RRC recovery procedure with the RAN node to transition to a connected state to transmit the UL data. In some implementations, the RAN node configures the DL signal measured by the UE. For example, the RAN node may configure the DL signal as SSB so that the UE does not need to perform additional measurements to obtain the second RSRP value. In some such examples, the first RSRP value and the second RSRP value are the same value.In another example, the RAN node may configure the DL signal to be partially the same as or different from the SSB so that the UE does not need to perform separate measurements to obtain the first RSRP value and the second RSRP value, respectively.

[0337] In some implementations, the non-SDT configuration includes physical layer configuration parameters (e.g., PhysicalCellGroupConfig IE) and / or MAC configuration parameters (e.g., MAC-CellGroupConfig IE). In some implementations, the RAN node avoids using the first SDT configuration to communicate with the UE operating in the connected state.

[0338] Fig.19B 1900B is a flow chart of an example method 1900B, which is similar to method 1900A, except that method 1900B includes blocks 1909, 1911, and 1915 instead of blocks 1908, 1910, and 1914. In this way, the RAN node communicates with the UE in an inactive state by using the SDT configuration and a portion of the non-SDT configuration.

[0339] Specifically, at block 1909, the RAN node performs SDT with the UE operating in an inactive state via the cell according to the first SDT configuration and a portion of the non-SDT configuration (e.g., events 404, 418, 492, 493, 420, 494, 495, 592, 593, 594, 595, 692, 694, 695). At block 1911, the RAN node avoids communicating with the UE using the second portion of the non-SDT configuration during the SDT. At block 1915, the RAN node communicates with the UE operating in a connected state using at least a portion of the non-SDT configuration (e.g., events 550, 552, 518, 590, 594).

[0340] In some implementations, the non-SDT configuration includes configuration parameters in an RRC reconfiguration message (e.g., an RRCReconfiguration message). In some implementations, the configuration parameters include measurement configurations, and SRB configurations (e.g., SRB-ToAddMod IE) and / or DRB configurations (e.g., DRB-ToAddMod IE) associated with the UE's SRBs and / or DRBs. In this case, the first part of the non-SDT configuration includes some or all of the SRB configurations (e.g., SRB-ToAddMod IE) and / or some or all of the DRB configurations (e.g., DRB-ToAddMod IE), which are associated with the DRBs or SRBs configured for SDT. The second part of the non-SDT configuration includes measurement configurations. In some implementations, the second part of the non-SDT configuration includes some of the SRB configurations and / or some or all of the DRB configurations, which are associated with the DRBs or SRBs configured for non-SDT (if any).

[0341] In some implementations, the configuration parameters of the non-SDT configuration also include a cell group configuration (e.g., CellGroupConfig IE). The cell group configuration includes physical layer configuration parameters (e.g., PhysicalCellGroupConfig IE), MAC configuration parameters (e.g., MAC-CellGroupConfigIE), and RLC configuration parameters (e.g., one or more RLC bearer configurations (e.g., RLC-BearerConfig IE)) associated with all SRBs and / or DRBs of the UE, respectively. For example, the physical configuration parameters include beam-related configuration parameters, MIMO configuration parameters, SRS configuration parameters, physical channel configuration parameters, and BWP configuration parameters. In some implementations, the first part of the non-SDT configuration includes some or all of the RLC bearer configurations associated with the SRBs and / or DRBs of the SDT. In some implementations, the second part of the non-SDT configuration includes some of the RLC bearer configurations, MAC configuration parameters, and / or physical layer configuration parameters associated with the SRBs and / or DRBs of the non-SDT. In other implementations, the first part of the non-SDT configuration includes a first part of the MAC configuration parameters, and the second part of the non-SDT configuration includes a second part of the MAC configuration parameters and / or a physical layer configuration parameter. For example, the first part of the MAC configuration parameters includes a UL transmission skip configuration and / or a data inactivity timer value, and the second part of the MAC configuration parameters includes a DRX configuration, a BSR configuration, a PHR configuration, and / or a scheduling request configuration.

[0342] In some implementations, the portion of the non-SDT configuration includes a first portion of the non-SDT configuration. In some implementations, the portion of the non-SDT configuration includes a measurement configuration, and an SRB configuration and / or a DRB configuration associated with the SRB and / or DRB of the UE, respectively. In some implementations, at least a portion of the non-SDT configuration includes an RLC bearer configuration associated with the SRB and / or DRB of the UE. In some implementations, the portion of the non-SDT configuration includes a portion of physical layer configuration parameters and a portion of MAC configuration parameters. In other implementations, the portion of the non-SDT configuration does not include physical layer configuration parameters. In some implementations, the RAN node avoids using the first SDT configuration to communicate with a UE operating in a connected state.

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

[0344] In general, the description of one of the figures in the above-mentioned figures may apply to another figure in the above-mentioned figures. The above-mentioned events or boxes may be optional or omitted. For example, the events or boxes with dotted lines in the figure may be optional. In some implementations, "message" is used, and "information element (IE)" can be used to replace "message", and vice versa. In some implementations, "IE" is used and "field" can be used to replace "IE", and vice versa. In some implementations, "configuration" or "configuration parameter" can be used to replace "configuration", and vice versa. In some implementations, "early data transmission (EDT)" can be used to replace "small data transmission", and "EDT" can be used to replace "SDT", and vice versa. In some implementations, "small data communication" can be used to replace "small data transmission", and vice versa. In some implementations, "SDT", "SDT process", "SDT session" are interchangeable. In some implementations, "pause" can be used to replace "stop", and vice versa. In some implementations, "configured grant" and "configured uplink grant" are interchangeable.

[0345] In some implementations, the “second UE CG-SDT timer” may be replaced by the “CG-SDT retransmission timer (cg-SDT-RetransmissionTimer)”. In some implementations, “CG-SDT”, “CG”, and “SDT-CG” may be interchangeable. In some implementations, the “sublayer” may be replaced by the “entity”. In some implementations, the “sublayer” may be replaced by the “entity”. In some implementations, the “SDT configuration”, “SDT DU configuration”, and “SDT CU configuration” are interchangeable.

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

[0347] 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-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit that is capable of performing certain operations and may be configured or arranged in a particular manner. A hardware module may include dedicated circuitry or logic that is permanently configured to perform certain operations (e.g., as a dedicated processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.). A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations (e.g., as contained in a general-purpose processor or other programmable processor). The decision to implement a hardware module with a dedicated and permanently configured circuit or with a temporarily configured circuit (e.g., configured by software) may be driven by cost and time considerations.

[0348] 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, the method being implemented in a user equipment (UE) and comprising: receiving a configuration from a radio access network (RAN) for skipping uplink transmission; Obtain uplink (UL) authorization; as well as When operating under an inactive radio connection between the UE and the RAN, the uplink transmission corresponding to the UL grant is skipped according to the received configuration.

2. The method of claim 1 , wherein the receiving of the configuration comprises: A small data transmission (SDT) configuration is received including the configuration for skipping the uplink transmission. 3 . The method of claim 2 , wherein the SDT configuration is included in a command to release the radio connection.

4. The method of claim 2, wherein the SDT configuration is included in a system information block (SIB).

5. The method of claim 1, wherein: The configuration for skipping the uplink transmission is applicable to both non-SDT communication and SDT communication.

6. The method according to any one of the preceding claims, further comprising: and transmitting to the RAN an indication of whether the UE supports the skipping of the uplink transmission. The method of claim 6 , wherein the indication is specific to SDT. The method of claim 6 , wherein the indication applies to both SDT and non-SDT.

9. The method of any one of claims 6 to 8, wherein: The transmitting of the indication is in response to receiving a query from the RAN.

10. The method of any preceding claim, wherein skipping the uplink transmission corresponding to the UL grant comprises: It is determined according to the UL grant that no data meeting the SDT condition is available for transmission.

11. The method of claim 10, wherein skipping the uplink transmission corresponding to the UL grant according to the received configuration comprises: When the received configuration allows the skipping, transmission of uplink medium access control (MAC) protocol data units (PDUs) to the RAN is avoided.

12. The method of any preceding claim, wherein the UL grant comprises a configured UL grant.

13. The method of any one of claims 1-11, wherein the UL grant comprises a dynamic UL grant.

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

15. A method for wireless communication, the method being implemented in a node of a radio access network (RAN) and comprising: transmitting to a user equipment (UE) a configuration for skipping uplink transmission according to an uplink (UL) grant when the UE is operating in an inactive radio connection between the UE and the RAN; as well as Communicating with the UE according to the configuration when the UE operates under the inactive radio connection.

16. The method of claim 15, wherein the transmitting of the configuration comprises: The transmission includes a small data transmission (SDT) configuration for skipping the configuration of the uplink transmission.

17. A node of a RAN, the node comprising: Transceiver; as well as Processing hardware configured to implement the method according to any one of claims 15-16.

Images