Managing radio resource configurations for data communications in inactive state

Abstract

A central unit, CU, of a distributed base station further comprising a distributed unit, DU: receives (606) i) a small data transmission, SDT, configuration related to an SDT operation and ii) a non-SDT configuration related to a non-SDT operation from the DU; providing (610) the SDT configuration to the UE; and ignoring (609) the non-SDT configuration at the CU.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of the filing date of provisional U.S. patent application No. 63 / 345,015, entitled “Managing Radio Resource Configurations for Data Communication in an Inactive State,” filed on May 23, 2022. The entire contents of said provisional application are hereby expressly incorporated herein by reference. Technical Field

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

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

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

[0006] The RRC sublayer specifies: an RRC_IDLE state, in which the UE does not have an active radio connection with a base station; an RRC_CONNECTED state, in which the UE has an active radio connection with a base station; and an RRC_INACTIVE state, which is used to allow the UE to transition back to the RRC_CONNECTED state more quickly using RAN-level base station coordination and RAN-level paging procedures. In some cases, a UE in the RRC_INACTIVE state has only a relatively small packet to send. For cases such as these, a small data transfer (SDT) procedure is used to enable a node to support data transmission for a UE operating in the RRC_INACTIVE state (i.e., without requiring the UE to transition to the RRC_CONNECTED state).

[0007] If less than the configured amount of uplink data is waiting to be sent on all radio bearers for which SDT is enabled, the downlink (DL) reference signal received power (RSRP) is higher than the configured threshold and valid SDT resources are available, SDT is enabled on a radio bearer basis and initiated by the UE. The SDT process can be initiated by the UE through a transmission on a random access channel (RACH) (i.e., random access SDT (RA-SDT)) or a transmission on a type 1 configured grant (CG) resource (i.e., CG-SDT). For RA-SDT, the network configures 2-step and / or 4-step random access resources for SDT. In RA-SDT, the UE sends an initial transmission including data in the payload of message 3 (MSG3) of a 4-step random access process or in a message A (MSGA) of a 2-step random access process. After completing the random access process, the network can then schedule subsequent uplink and / or downlink transmissions using dynamic uplink grants and downlink assignments, respectively.

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

[0009] In some scenarios, a UE is connected to a radio access network (e.g., 5G NR RAN (NG-RAN)) that includes base stations, each of which has a central unit (CU) and at least one distributed unit (DU). However, it is unclear how a base station including a CU and a DU should configure SDT configuration parameters for a UE to enable RA-SDT or CG-SDT. Summary of the invention

[0010] According to the technology of the present disclosure, for example, when the UE is connected to the RAN and has been communicating with the base station via the DU in non-SDT operation, or when the UE is in an inactive state and has been communicating with the base station via the DU in SDT operation, the CU of the base station can determine to configure or reconfigure the UE for SDT operation. In either scenario, the CU requests the SDT DU configuration by sending a first CU to DU message (e.g., a UE context modification request message) to the DU communicating with the UE, and the DU responds by sending a DU to CU message (e.g., a UE context modification response message) including the SDT DU configuration and the non-SDT DU configuration. The CU first sends a second CU to DU message including the SDT DU configuration to the DU, and the DU forwards the non-SDT DU configuration to the UE. For example, the CU can send the SDT configuration to the UE in an RRC release message via the DU. The CU ignores the SDT configuration.

[0011] An example embodiment of these techniques is a method implemented in a central unit (CU) of a distributed base station that also includes a distributed unit (DU), the method comprising: receiving (i) a small data transmission (SDT) configuration related to an SDT and (ii) a non-SDT configuration related to a non-SDT operation from the DU; providing the SDT configuration to a UE; and ignoring the non-SDT configuration at the CU.

[0012] Another example embodiment of the techniques is a Radio Access Network (RAN) node comprising processing hardware and configured to implement the method of any one of the preceding claims.

[0013] In another example, a method of handling SDT with a UE is implemented by a DU of a base station that also includes a CU. The method includes: communicating, by processing hardware of the DU, with the UE according to a first DU configuration; receiving, by the processing hardware, a CU-to-DU message from the CU requesting an SDT DU configuration for the UE; and sending, by the processing hardware, the SDT DU configuration to the UE.

[0014] In another example, a method of handling SDT with a UE is implemented by a CU of a base station that also includes a DU. The method includes: communicating, by processing hardware of the CU, with the UE via the DU according to a first CU configuration; sending, by the processing hardware, a CU-to-DU message requesting an SDT DU configuration for the UE to the DU; and receiving, by the processing hardware, a DU-to-CU message including the SDT DU configuration from the DU.

[0015] In another example, a method for handling SDT with a UE is implemented by a CU of a base station that also includes a DU. The method includes: communicating with the UE via the DU according to a first configuration by processing hardware of the CU; determining, by the processing hardware, to configure or reconfigure the UE for SDT; generating, by the processing hardware, an SDT configuration; and sending, by the processing hardware, the SDT configuration to the UE via the DU.

[0016] In another example, a RAN node comprises processing hardware and is configured to perform any of the methods described above.

[0017] In another example, a method of handling SDT with a base station is implemented by a UE. The method includes: communicating with the base station by processing hardware of the UE; sending a request or preference for an SDT operating mode to the base station by the processing hardware; and receiving a message from the base station by the processing hardware to cause the UE to change to the requested or preferred SDT operating mode. In another example, a UE includes processing hardware and is configured to perform this method.

[0018] In another example, a method of handling SDT with a UE is implemented by a base station. The method includes: communicating with the UE by processing hardware of the base station; receiving a request or preference for an SDT operating mode from the UE by the processing hardware; and sending a message to the UE by the processing hardware to cause the UE to change to the requested or preferred SDT operating mode. In another example, a base station includes processing hardware and is configured to perform this method.

[0019] In another example, a method of handling SDT with a RAN is implemented by a UE. The method includes: receiving, by processing hardware of the UE, an SDT configuration from the RAN; performing, by the processing hardware, an SDT with the RAN according to the SDT configuration; determining, by the processing hardware, that the SDT configuration does not include one or more configuration parameters for performing at least one function; and performing, by the processing hardware, at least one function using one or more other configuration parameters not included in the SDT configuration when performing the SDT with the RAN. In another example, a UE includes processing hardware and is configured to perform this method. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1Ais a block diagram of an example wireless communication system in which the user equipment and base station of the present disclosure may implement the techniques of the present disclosure for reducing latency in data communications;

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

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

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

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

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

[0026] Figure 5A is Figure 1B A flowchart of an example method implemented in a DU of the present invention for providing SDT configuration and non-SDT configuration to a UE via a CU;

[0027] Figure 5B is with Figure 5A A flow chart of a similar example method, but wherein the DU includes an indication to ignore or discard non-SDT DU configurations in a message to the CU;

[0028] Figure 5C is with Figure 5A A flow chart of a similar example method, but wherein the DU includes a specific non-SDT DU configuration in a message to the CU;

[0029] Figure 5D is with Figure 5A A flow chart of a similar example method, but wherein the DU excludes mandatory fields configured by non-SDT DUs in messages to the CU;

[0030] Fig. 6A is Figure 1B A flowchart of an example method implemented in a CU of for providing SDT configuration and non-SDT configuration to a UE;

[0031] Figure 6B is with Fig. 6A A flowchart of a similar example method, but where the CU ignores or discards non-SDT configurations;

[0032] Figure 6C is with Fig. 6A A flow chart of a similar example method, but wherein the CU determines whether to ignore or discard a non-SDT configuration based on whether the non-SDT DU configuration is new;

[0033] Fig.6D is with Fig. 6A A flowchart of a similar example method, but wherein the CU determines whether to ignore or discard a non-SDT configuration based on whether the DU provides an ignore or discard indication;

[0034] Fig. 6E is with Fig. 6A A flow chart of a similar example method, but wherein the CU selects between the first message and the second message for the UE based on whether the DU includes a non-SDT configuration in a message to the CU;

[0035] Fig. 6F is with Fig. 6A A flow chart of a similar example method, but wherein the CU selects the second message based on whether the DU excludes the mandatory field in the message to the CU;

[0036] Figure 7 is Figure 1B A flowchart of an example method implemented in a CU of a device for determining whether a CU should ignore and / or discard a non-SDT DU configuration based on a CU-to-DU message;

[0037] Fig. 8A is Figure 1B A flowchart of an example method implemented in a CU of a system for determining whether to send a message including a DU configuration to a UE based on whether a received message includes a specific configuration;

[0038] Figure 8B is with Fig. 8A A similar example flow chart, but wherein the CU determines whether the DU to CU message includes a specific indication;

[0039] Fig. 9A is Figure 1B A flowchart of an example method implemented in a DU of a UE for configuring SDT and / or non-SDT communications with a UE; and

[0040] Fig. 9B is with Fig. 9AFlowchart of a similar example method, but in the DU, determining whether to apply non-SDT DU configuration is based on whether the message is a release command for UE context. DETAILED DESCRIPTION

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

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

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

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

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

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

[0047] As discussed in detail below, when the radio connection between the UE 102 and the RAN 105 is suspended, for example, when the UE 102 is operating in an inactive or idle state of a protocol for controlling radio resources between the UE 102 and the RAN 105, the UE 102 and / or the RAN 105 can utilize the techniques of the present disclosure. For clarity, the examples below refer to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol. As discussed below, in some implementations, the UE 102 applies the techniques of the present disclosure only if the size of the data (e.g., UL data) is below a certain threshold.

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

[0049] 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 encrypted data. When both integrity protection and encryption are enabled, UE 102 may generate a MAC-I for protecting the integrity of the data and encrypt the data together with the MAC-I to generate an encrypted packet and an encrypted MAC-I. Then, UE 102 may send the security-protected packet to RAN 105 when in RRC_INACTIVE or RRC_IDLE state.

[0050] In some implementations, the data is a UL service data unit (SDU) of a packet data convergence protocol (PDCP) or SDAP. The UE 102 applies a security function to the SDU and includes the protected SDU in a first UL PDU (e.g., a UL PDCP PDU). The UE 102 then includes the UL PDCP PDU in a second UL PDU (such as a UL MAC PDU), which may be associated with a media access control (MAC) layer. Therefore, in these cases, the UE 102 sends the protected UL PDCP PDU in the UL MACPDU. In some implementations, the UE 102 may include the UL RRC message in the UL MAC PDU. In other implementations, the UE 102 may omit the UL RRC message from the UL MAC PDU. In this latter case, the UE 102 may omit the UE ID of the UE 102 from the UL MAC PDU that does not include the UL RRC message. In yet another implementation, the UE 102 may include the UL PDCP PDU in a UL radio link control (RLC) PDU, and then include the UL RLC PDU in a UL MAC PDU. In some implementations where the UL RRC message is included in the UL MAC PDU, the UE 102 generates an RRC MAC-I and includes the RRC MAC-I in the UL RRC message. For example, the RRC MAC-I may be a resumeMAC-I field, as specified in 3GPP specification 38.331. In another implementation, the UE may include an integrity key (e.g., K RRCintThe RRC MAC-I is obtained from the UL RRC message using a key), an integrity protection algorithm, and the parameters COUNT (e.g., a 32-bit, 64-bit, or 128-bit value), BEARER (e.g., a 5-bit value), and DIRECTION (e.g., a 1-bit value).

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

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

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

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

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

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

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

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

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

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

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

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

[0063] 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 special-purpose processing units. In an example implementation, 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, processing hardware 150 includes a media access control (MAC) controller 152, which is configured to perform a random access procedure with a base station, send an uplink MAC protocol data unit (PDU) to the base station, and receive a downlink MAC PDU from the base station. The processing hardware 150 may also include a PDCP controller 154 configured to: in some scenarios, send DL PDCP PDUs, according to which the base station 106 can send data in the downlink direction; and in other scenarios, receive UL PDCP PDUs, according to which the base station 106 can receive data in the uplink direction. The processing hardware may also include an RRC controller 156 to implement procedures and message delivery at the RRC sublayer of the protocol communication stack.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0089] In some implementations, in response to determining that the UE 102 is transitioned to an inactive state configured with an 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 the case where the CU-CP 172A sends 338 an RRC reconfiguration, the CU-CP 172A sends the RRC release message after sending 338 an RRC reconfiguration message or receiving 344 an RRC reconfiguration complete message. In some implementations, the CU-CP 172A includes the first SDT DU configuration in the RRC release message. In another implementation, the CU-CP 172A additionally includes the first 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 or a UE context modification request message) to the DU 174, and the third CU to DU message includes the RRC release message. Then, DU 174 sends 334 an RRC release message to UE 102. In some implementations, DU 174 receives (e.g., at event 332) a DL PDCP PDU including an RRC release message from CU-CP 172A. DU 174 generates a DL RLC PDU including the DL PDCP PDU, generates a DL MAC PDU including the DL RLC PDU, and sends 334 the DL MAC PDU to UE 102. In some implementations, DU 174 determines that UE 102 receives the RRC release message after receiving a HARQ ACK for the DL MAC PDU from UE 102. In yet other implementations, DU 174 determines that UE 102 receives the RRC release message after receiving an RLC ACK for the DL RLC PDU from UE 102. In yet other implementations, DU 174 starts a release timer in response to sending or determining to send the RRC release message. When the release timer expires, DU 174 determines that UE 102 receives the RRC release message.

[0090] The RRC release message instructs UE 102 to transition to an inactive state. After receiving the RRC release message, UE 102 transitions 336 from the connected state to the inactive state. In some implementations, in response to receiving the third CU to DU message or after receiving the third CU to DU message, DU 174 retains the first SDT DU configuration. In some implementations, in response to receiving the third CU to DU message or after receiving the third CU to DU message, DU 174 releases the first non-SDT DU configuration and / or the second non-SDT DU configuration. In other implementations, in response to receiving the third CU to DU message or after receiving the third CU to DU message, DU 174 retains the first non-SDT DU configuration and / or the second non-SDT DU configuration. In yet other implementations, in response to receiving the third CU to DU message or after receiving the third CU to DU message, DU 174 retains a portion of the first non-SDT DU configuration and / or the second non-SDT DU configuration and releases the remainder of the first non-SDT DU configuration and / or the second non-SDT DU configuration. For example, DU 174 retains RLC bearer configuration parameters, logical channel configuration parameters, MAC configuration parameters, and / or PHY configuration parameters (e.g., CS-RNTI). In some implementations, DU 174 sends a third DU to CU message (e.g., a UE context release complete message or a UE context modification response message) to CU-CP 172A in response to the third CU to DU message.

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

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

[0093] In some implementations, the first SDT CU configuration includes a DRB list (e.g., std-DRB-List) including a DRB ID list indicating IDs of DRBs configured for SDT. In other implementations, the first SDT CU configuration includes an SRB2 indication (e.g., sdt-SRB2-Indication) indicating SRB2 configured for SDT. In still other implementations, the first SDT CU configuration includes an SRB2 indication indicating that the PDCP entity of the DRB configured for SDT is operating in SDT (i.e., as in Figure 4 In another implementation, the first SDT CU configuration includes a data volume threshold (e.g., sdt-DataVolumeThreshold) for UE 102 to determine whether an SDT can be initiated.

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

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

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

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

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

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

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

[0101] Next reference Figure 4 , scenario 400 depicts a small data transmission. In scenario 400, base station 104 includes CU 172 and DU 174. CU 172 includes CU-CP 172A and CU-UP 172B. In scenario 400, UE 102 initially operates in an inactive state configured with SDT 402. In some implementations or scenarios, Figure 4 Prior to the events shown in Figure 3 4. In other implementations or scenarios, the SDT may be configured to transition from a connected state to an inactive state as described above (i.e., event 402 may be after event 336). Figure 4Prior to the event shown in , UE 102 transitions from an inactive state where SDT is not configured to an inactive state where SDT is configured. For example, UE 102 receives an RRC release message from a base station (e.g., base station 104 or base station 106) that causes UE 102 to transition to an inactive state where SDT is not configured. In such a case, UE 102 transitions to an inactive state where SDT is not configured in response to the RRC release message. In some implementations, UE 102 in an inactive state where SDT is configured or not configured performs a RAN Notification Area (RNA) update with the base station without a state transition. During the RNA update, UE 102 receives another RRC release message from the base station that includes a first SDT CU configuration and / or a first SDT DU configuration, similar to the RRC release message of event 334.

[0102] At a later time, the UE 102 operating in an inactive state configured with SDT initiates an SDT (e.g., an SDT session or process). In response to or after initiating the SDT, the UE 102 generates an initial UL MAC PDU including an UL RRC message and sends 404 the initial UL MAC PDU to the DU 174 on the cell 124. In some implementations, in response to or after initiating the SDT, the UE 102 starts an SDT session timer (e.g., timer T319a). In some implementations, the UE 102 starts the SDT session timer after initiating the SDT. In other implementations, the UE 102 starts the SDT session timer after sending 404 the initial UL MAC PDU. The DU 174 retrieves the UL RRC message from the initial UL MAC PDU, generates a first DU to CU message including the UL RRC message, and sends 406 the first DU to CU message to the CU-CP 172A. In some implementations, the first DU to CU message is an initial UL RRC messaging message. In other implementations, the first DU to CU message is a UL RRC messaging message.

[0103] In scenarios where the UE 102 initiates an SDT to send UL data (e.g., data packets) eligible for SDT, the UE 102 includes the UL data in an initial UL MAC PDU that the UE 102 transmits 404. In scenarios where the UE 102 initiates an SDT to receive DL data, the UE 102 does not include the UL data packets in the initial UL MAC PDU that the UE 102 transmits 404. In additional implementations, the UE 102 initiates an SDT to receive DL data in response to receiving a page from the DU 174. In some such scenarios, the UE 102 includes an SDT indication in an initial UL MAC PDU or UL RRC message to indicate to the base station 104 that the UE 102 is initiating an SDT to receive DL data.

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

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

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

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

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

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

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

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

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

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

[0114] In the event that the subsequent UL data is associated with one or more SRBs (e.g., SRB1 and / or SRB2), DU 174 sends 418 one or more DU to CU messages including the subsequent UL data to CU-CP 172A. Depending on the implementation, each DU to CU message includes a specific UL data packet of the subsequent UL data. In the event that the subsequent UL data is associated with one or more DRBs, DU 174 sends (at event 418) the subsequent UL data to CU-UP 172B. In some implementations, DU 174 includes the transport layer information of DU 174 in the UE context setup response message. Subsequently, in some implementations, CU-CP 172A includes the transport layer information of DU 174 in the bearer context modification request message. Depending on the implementation, the transport layer information of DU 174 includes an IP address and / or a downlink TEID. In some cases where CU-UP 172B receives DL data from CN 110 or an edge server, CU-UP 172B uses the transport layer information of DU 174 to send 418 DL data (e.g., one or more DL data packets) to DU 174. DU 174 then sends (at event 418) one or more DL MAC PDUs including the DL data to UE 102 operating in an inactive state. In some implementations, DU 174 uses the DL assignment to send (at event 418) the DL MAC PDU to UE 102. UE 102 receives the DL MAC PDU from DU 174 according to the DL assignment. UE 102 then retrieves the DL data from the DL MAC PDU. In some implementations, UE 102 receives (at event 418) DCIs from DU 174, each of which includes a specific DL assignment in the DL assignment. To send each of the DCIs to the UE 102, the DU 174 generates a CRC for the DCI, scrambles the CRC with the ID of the UE 102 (e.g., C-RNTI), and sends the DCI and the scrambled CRC on the PDCCH. The UE 102 receives the DCI and the scrambled CRC on the PDCCH. The UE 102 receives the DL transmission from the DU 174 and obtains the DL MAC PDU from the DL transmission.

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

[0116] In some example scenarios, the UL data and / or DL ​​data described above include Internet Protocol (IP) packets, Ethernet packets, or application packets. In other scenarios, the UL data includes PDUs (e.g., RRC PDUs, PDCP PDUs, or RLC PDUs), which include RRC messages, NAS messages, IP packets, Ethernet packets, or application packets.

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

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

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

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

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

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

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

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

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

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

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

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

[0129] In some implementations, in response to determining to stop SDT, CU-CP 172A generates an RRC release message (e.g., an RRCRelease message or an RRCConnectionRelease message) to stop SDT and keep UE 102 in an inactive state. In some implementations, CU-CP 172A includes the SDT DU configuration and the SDT CU configuration in the RRC release message. Then, CU-CP 172A sends 432 a third CU to DU message (e.g., a UE context release command message or a UE context modification request message) to DU 174, and the third CU to DU message includes the RRC release message. Subsequently, DU 174 sends 434 an RRC release message to UE 102. UE 102 stops SDT (i.e., determines that the SDT session or process ends or terminates) after receiving the RRC release message and remains in an inactive state. In some implementations, in response to or after stopping the SDT, the UE 102 stops the SDT session timer, stops monitoring the PDCCH for the SDT, and / or releases the C-RNTI used by the UE 102 to monitor the PDCCH for the SDT. Alternatively, the UE 102 retains the C-RNTI. In another implementation, in response to the third CU to DU message, the DU 174 retains the SDT DU configuration and releases or does not release the first non-SDT DU configuration and / or the second non-SDT DU configuration, as described above in conjunction with Figure 3Depending on the implementation, DU 174 sends a third DU-to-CU message (e.g., a UE context release complete message or a UE context modification response message) to CU-CP 172A in response to the third CU-to-DU message. In some implementations, if the RRC release message instructs UE 102 to transition to an idle state (i.e., RRC_IDLE), UE 102 transitions to RRC_IDLE and releases the non-SDT configuration (e.g., for Figure 3 The first non-SDT DU configuration, the first non-SDT CU configuration, the second non-SDT DU configuration and / or the second non-SDT CU configuration described herein) and at least one SDT configuration (e.g., for Figure 3 The first SDT DU configuration and / or the first SDT CU configuration described herein).

[0130] The examples and implementations discussed above for events 320, 321, 322, 323, 324, 326, 328, 330, 338, 340, 342, 344, 332, 334 are respectively applicable to events 420, 421, 422, 423, 424, 426, 428, 430, 438, 440, 442, 444, 432, 434. In some implementations, after stopping SDT, UE 102 performs another small data transfer process with base station 104 or base station 106, similar to process 494.

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

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

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

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

[0135] Next, refer to FIG. 5A to FIG. 9B Several example methods that may be implemented in a UE, in one or more base stations, DUs or CUs, or in a RAN to support data communication in an inactive state are discussed.

[0136] Figure 5A A method 500A implemented by a DU (eg, DU 174) for providing SDT configuration parameters to a UE (eg, UE 102) via a CU (eg, CU 172 or CU-CP 172A) is shown.

[0137] Method 500A begins at block 502, where a DU communicates with a CU and a UE (eg, Figure 3 and Figure 4 At block 504, the DU receives a first CU-to-DU message (e.g., Figure 3 and Figure 4At block 506, the DU includes the SDT DU configuration in a first DU to CU message (e.g., Figure 3 and Figure 4 At block 508, the DU includes the non-SDT DU configuration in the first DU to CU message (e.g., Figure 3 and Figure 4 At block 510, in response to or after receiving a CU-to-DU message, the DU sends a first DU-to-CU message to the CU (e.g., Figure 3 and Figure 4 At block 512, the DU receives a first message including a non-SDT DU configuration from the CU (e.g., Figure 3 and Figure 4 At block 514, the DU sends a first message to the UE (e.g., Figure 3 and Figure 4 At block 516, the DU receives a second message including the SDT DU configuration from the CU (e.g., Figure 3 and Figure 4 At block 518, the DU sends a second message to the UE (e.g., Figure 3 and Figure 4 Events 336, 436).

[0138] In some implementations, the first CU-to-DU message is a UE context modification request message. In some implementations, the first DU-to-CU message is a UE context modification response message. In other implementations, the first DU-to-CU message is a UE context modification requirement message. In some such cases, the DU sends a second DU-to-CU message (e.g., a UE context modification response message) to the CU in response to the first CU-to-DU message, and the CU sends a second CU-to-DU message (e.g., a UE context modification confirmation message) to the DU in response to the first DU-to-CU message.

[0139] In some implementations, the DU uses SDT DU configuration and / or non-SDT DU configuration to communicate with a UE operating in an inactive state. In some implementations, the DU includes CS-RNTI and CG-SDT configuration parameters in the SDT DU configuration. In some implementations, the DU includes RLC bearer configuration parameters, logical channel configuration parameters, MAC configuration parameters and / or PHY configuration parameters in the non-SDT DU configuration. The DU uses CS-RNTI and CG-SDT configuration parameters to communicate with a UE operating in an inactive state. Alternatively, the DU includes CS-RNTI in the non-SDT DU configuration. Examples and implementations of configuration parameters are as described above.

[0140] In some implementations, after sending the first message, the DU receives a third message from the UE (e.g., Figure 3 and Figure 4 Event 342, 442 of the embodiment of the present invention) and sends an additional DU to CU message including the third message to the CU (e.g., event 344, 444). In some implementations, the first message and the third message are an RRC reconfiguration message and an RRC reconfiguration complete message, respectively. In other implementations, the first message and the third message are an RRC recovery message and an RRC recovery complete message, respectively. In some implementations, the DU sends the second message after sending the first message or receiving the third message. In some implementations, the second message is an RRC release message.

[0141] In some implementations, the first CU-to-DU message includes an SDT request indication (eg, a CG-SDT query indication). In response to the SDT request indication, the DU includes the SDT DU configuration in the first DU-to-CU message.

[0142] Figure 5B 5 is a flow chart of an example method 500B similar to method 500A, except that method 500B includes block 509 instead of blocks 512 and 514. At block 509, the DU includes an indication to ignore or discard the non-SDT DU configuration in the first DU to CU message. The CU ignores or discards the non-SDT DU configuration in response to the indication. In some examples, the indication is a non-SDT configuration ignore indication or a cell group configuration (CellGroupConfig) ignore indication.

[0143] Figure 5C 5 is a flow chart of an example method 500B similar to methods 500A and 500B, except that method 500C includes block 507 instead of blocks 509, 512, and 514. At block 507, the DU includes a specific non-SDT DU configuration in a first DU to CU message (e.g., Figure 3 and Figure 4Events 340, 430 of the present invention) may be executed to cause the CU 172 to ignore or discard the special non-SDT DU configuration. In some implementations, the CU ignores or discards the special non-SDT DU configuration in response to receiving the specific non-SDT DU configuration. Examples and implementations of the specific non-SDT DU configuration are described above.

[0144] Figure 5D is a flow chart of an example method 500D similar to methods 500A, 500B, and 500C, except that method 500D includes block 511 instead of blocks 507, 509, 512, and 514. At block 511, the DU excludes the mandatory fields of the non-SDT DU configuration from the first DU to CU message. In some implementations, the non-SDT DU configuration is the CellGroupConfig IE.

[0145] against Figure 3 and Figure 4 The examples and implementations described can be applied to FIG. 5A to FIG. 5D .

[0146] Fig. 6A A method 600A implemented by a CU (eg, CU 172 or CU-CP 172A) for providing SDT configuration parameters to a UE (eg, UE 102) via a DU (eg, DU 174) is shown.

[0147] Method 600A begins at block 602, where a CU communicates with a DU and a UE (eg, Figure 3 and Figure 4 At block 604, the CU sends a first CU-to-DU message (e.g., Figure 3 and Figure 4 At block 606, the CU receives a first DU-to-CU message including an SDT DU configuration and a non-SDT configuration from the DU after sending the first CU-to-DU message (e.g., Figure 3 and Figure 4 At block 608, the CU sends a first message (eg, Figure 3 and Figure 4At block 610, the CU sends a second message including a non-SDT configuration to the UE via the DU (eg, events 332, 334, 432, 434).

[0148] Figure 6B 6 is a flow chart of an example method 600B similar to method 600A, except that method 600B includes block 609 instead of block 608. At block 609, the CU discards or ignores the non-SDT DU configuration. Therefore, the CU does not send the non-SDT DU configuration to the DU and / or the UE. In some implementations, the first DU to the CU includes an indication to ignore or discard the non-SDT DU configuration, such as for Figure 5B The CU ignores or discards the non-SDT DU configuration in response to the indication. In other implementations, the non-SDT DU configuration is a specific non-SDT DU configuration, such as for Figure 5C Therefore, the CU ignores or discards the non-SDT DU configuration in response to receiving a specific non-SDT DU configuration.

[0149] Figure 6C 6 is a flow chart of an example method 600C similar to methods 600A and 600B, except that method 600C includes block 607. At block 607, the CU determines whether the non-SDT DU configuration includes (new or updated) configuration parameters. If the CU determines that the non-SDU DU configuration includes (new or updated) configuration parameters, the process proceeds to block 608. Otherwise, if the non-SDT DU configuration does not include (new or updated) configuration parameters, the process proceeds to block 609. In some examples, the non-SDT DU configuration is a specific non-SDT DU configuration. In another example, the non-SDT DU configuration includes configuration parameters that have been configured for the UE or sent to the UE.

[0150] Fig.6D 6 is a flow chart of an example method 600D similar to methods 600A, 600B, and 600C, except that method 600D includes block 617 instead of block 607. At block 617, the CU determines whether the first DU to CU message includes an indication to ignore or discard the non-SDT configuration. If the CU determines that the first DU to CU message does not include the indication, the process proceeds to block 608. Otherwise, if the first DU to CU message includes the indication, the process proceeds to block 609. In some examples, the indication is a non-SDT configuration ignore indication or a cell group configuration (CellGroupConfig) ignore indication.

[0151] Fig. 6E6 is a flow chart of an example method 600E similar to method 600A, except that method 600E includes blocks 605 and 612 instead of block 606. At block 605, the CU receives a first DU-to-CU message including an SDT DU configuration from the DU after sending the first CU-to-DU message (e.g., Figure 3 and Figure 4 At block 612, the CU determines whether the first DU-to-CU message includes a non-SDT DU configuration. If the CU determines that the first DU-to-CU message includes a non-SDT DU configuration, the flow proceeds to blocks 608 and 610. Otherwise, if the CU determines that the first DU-to-CU message does not include a non-SDT DU configuration, the flow proceeds to block 610.

[0152] Fig. 6F 6 is a flow chart of an example method 600F similar to method 600A, except that method 600F includes blocks 603 and 611 instead of blocks 606 and 608. At block 603, the CU receives a first DU-to-CU message from the DU that includes the SDT DU configuration and excludes the mandatory fields of the non-SDT DU configuration after sending the first CU-to-DU message. At block 611, the CU determines that the first DU-to-CU message is valid. In response to the determination, the CU retrieves the SDT DU configuration from the first DU-to-CU message and generates a second message including the SDT DU configuration.

[0153] against Figure 3 , Figure 4 and FIG. 5A to FIG. 5D The examples and implementations described can be applied to 6A to 6F .

[0154] Figure 7 A method 700 implemented by a CU (eg, CU 172 or CU-CP 172A) for requesting SDT configuration parameters for a UE (eg, UE 102) from a DU (eg, DU 174) is shown.

[0155] Method 700 begins at block 702, where a CU communicates with a DU and a UE (eg, Figure 3 and Figure 4 At block 704, the CU sends a first CU-to-DU message to the DU. At block 706, the CU receives a first DU-to-CU message from the DU (e.g., Figure 3 and Figure 4Events 308, 330, 410, 430 of FIG. 4 ). At block 708, the CU determines whether the first CU-to-DU message requests a specific configuration. In some examples, the specific configuration is an SDT DU configuration (e.g., SDT-MAC-PHY-CG-Config IE). When the CU determines that the DU-to-CU message requests a specific configuration, the process proceeds to block 710. At block 710, the CU ignores or discards the non-SDT DU configuration. Otherwise, when the CU determines that the first CU-to-DU message does not request a specific configuration, the process proceeds to block 712. At block 712, the CU sends a message including the non-SDT DU configuration to the UE via the DU (e.g., Figure 3 and Figure 4 Events 338, 340, 438, 440).

[0156] against Figure 3 , Figure 4 , FIG. 5A to FIG. 5D and 6A to 6F The examples and implementations described can be applied to Figure 7 .

[0157] Fig. 8A A method 800A implemented by a CU (eg, CU 172 or CU-CP 172A) for requesting SDT configuration parameters for a UE (eg, UE 102) from a DU (eg, DU 174) is shown.

[0158] Method 800A begins at block 802, where a CU communicates with a DU and a UE (eg, Figure 3 and Figure 4 At block 804, the CU receives a first DU-to-CU message (e.g., Figure 3 and Figure 4 Events 308, 330, 410, 430 of FIG. 1 ). At block 806, the CU determines whether the first DU to CU message includes a specific configuration. In some examples, the specific configuration is an SDT DU configuration. In other examples, the specific configuration is a positioning configuration. When the CU determines that the first DU to CU message does not include the specific configuration, the process proceeds to block 808. At block 808, the CU ignores or discards the first DU to CU message. Otherwise, when the CU determines that the first DU to CU message includes the specific configuration, the process proceeds to block 810. At block 810, the CU sends a message including the specific configuration to the UE via the DU (e.g., Figure 3 and Figure 4Events 338, 340, 438, 440).

[0159] In some implementations, the mandatory field includes or identifies a non-SDT DU configuration (eg, CellGroupConfig IE).

[0160] Figure 8B 800A, except that method 800B includes blocks 805 and 807 instead of block 806. At block 805, the CU receives a first DU-to-CU message from the DU that includes a specific configuration and excludes mandatory fields (e.g., events 308, 330, 410, 430). At block 807, the CU determines whether the first DU-to-CU message includes a specific indication. In some implementations, the specific indication is an indication to ignore or discard the mandatory fields. When the CU determines that the first DU-to-CU message includes a specific indication, the process proceeds to block 808. Otherwise, when the CU determines that the first DU-to-CU message does not include a specific indication, the process proceeds to block 810.

[0161] In some implementations, the specific indication is a non-SDT configuration ignore indication or a cell group configuration (CellGroupConfig) ignore indication.

[0162] against Figure 3 , Figure 4 , FIG. 5A to FIG. 5D , 6A to 6F and Figure 7 The examples and implementations described can be applied to Fig. 8A and Figure 8B .

[0163] Fig. 9A A method 900A implemented by a DU (eg, DU 174) for providing SDT configuration parameters to a UE (eg, UE 102) via a CU (eg, CU 172 or CU-CP 172A) is shown.

[0164] Method 900A begins at block 902, where a DU communicates with a CU and a UE (eg, Figure 3 and Figure 4At block 904, the DU sends a DU to CU message including a non-SDT DU configuration for the UE to the CU (e.g., events 308, 330, 430). At block 906, the DU receives a UE context release command message for the UE from the CU after sending the DU to CU message and before receiving the CU to DU message including an RRC message. Figure 3 and Figure 4 At block 908, the DU avoids applying a non-SDT DU configuration to communicate with the UE.

[0165] Fig. 9B 900B is a flow chart of an example method 900B similar to method 900A, except that method 900B includes blocks 905, 907, and 910 instead of block 906. At block 905, the DU receives a CU-to-DU message including an RRC message from the DU after sending the DU-to-CU message (e.g., Figure 3 and Figure 4 At block 907, the DU determines whether the CU-to-DU message is a UE context release command message (i.e., a CU-to-DU message that releases the UE context of the UE). If the DU determines that the CU-to-DU message is a UE context release command message, the flow proceeds to block 908. Otherwise, if the DU determines that the CU-to-DU message is not a UE context release command message, the flow proceeds to block 910. At block 910, the DU applies a non-SDT DU configuration to communicate with the UE (e.g., Figure 3 Event 318).

[0166] against Figure 3 , Figure 4 , FIG. 5A to FIG. 5D , 6A to 6F , Figure 7 and FIG. 8A to FIG. 8B The examples and implementations described can be applied to Fig. 9A and Fig. 9B .

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

[0168] Generally speaking, the description of one of the above figures may apply to another of the above figures. The events or boxes described above may be optional or omitted. For example, the events or boxes with dashed lines in the accompanying drawings may be optional or omitted. In some cases, if the events or boxes with solid lines in the accompanying drawings are not necessary, the events or boxes may still be optional or omitted. In some implementations, "message" (as the term is used above) can be replaced with "information element (IE)", and vice versa. In some implementations, "IE" (as the term is used above) can be replaced with "field", and vice versa. In some implementations, "configuration" (as the term is used above) can be replaced with "configurations" or "configuration parameters", and vice versa. In some implementations, "small data transmission" (as the term is used above) can be replaced with "early data transmission" (and "SDT" can be replaced with "EDT"), and vice versa. In some implementations, "small data communication" can be used to replace "small data transmission" (as the term is used above), and vice versa. In some implementations, "pause" can be used to replace "stop" (as the term is used above).

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

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

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

Claims

1. A method implemented in a central unit (CU) of a distributed base station further comprising a distributed unit (DU), the method comprising: receiving from the DU (i) a small data transfer (SDT) configuration associated with an SDT operation and (ii) a non-SDT configuration associated with a non-SDT operation; Providing the SDT configuration to the UE; as well as The non-SDT configuration is ignored at the CU.

2. The method of claim 1, further comprising: A request for the SDT configuration is sent to the DU prior to the receiving of the SDT configuration.

3. The method of claim 2, wherein: The sending of the request to the DU comprises sending a UE CONTEXT MODIFY REQUEST message; and The receiving of the SDT configuration includes receiving a UE context modification response message.

4. A method as claimed in any one of the preceding claims, wherein: The ignoring is responsive to the sending the request for the SDT configuration.

5. The method of any one of the preceding claims, wherein the providing of the SDT configuration to the UE comprises: A first command to release a context of the UE is sent to the DU, the first command including a second command to release a radio connection.

6. The method of claim 5, wherein the sending comprises: The second command to release the radio connection is sent to the UE via the DU, the second command including the SDT configuration.

7. A method as claimed in any preceding claim, wherein the non-SDT configuration comprises a cell group configuration. The method of claim 7 , wherein the cell group configuration comprises a CellGroupConfig IE.

9. The method of any one of the preceding claims, wherein the SDT configuration comprises a Configured-Authorized SDT (CG-SDT) configuration.

10. The method of any one of the preceding claims, wherein the receiving (i) the SDT configuration and (ii) the non-SDT configuration comprises receiving the SDT configuration and the non-SDT configuration in a DU to CU RRC Information IE.

11. A method as claimed in any one of the preceding claims, wherein: The SDT configuration includes a configured scheduling radio network temporary identifier (CS-RNTI).

12. A method as claimed in any one of the preceding claims, wherein: The SDT configuration includes a ConfiguredGrantConfig IE.

13. A method as claimed in any one of the preceding claims, wherein: The SDT configuration includes a time alignment value.

14. A method as claimed in any one of the preceding claims, wherein: The SDT configuration includes a timing advance validity threshold.

15. A Radio Access Network (RAN) node comprising processing hardware and configured to implement the method of any preceding claim.

Images