Managing mobile-terminated small data transmission

Abstract

A user equipment (UE) receives (482, 318), from a radio access network (RAN) and in an inactive state of a radio connection with the RAN, a paging message including a mobile- terminated small data transmission (MT-SDT) indication; transmits (422A), to the RAN and subsequent to the paging message, a request to resume the radio connection, the request including a non-SDT cause; and receives (466A), from the RAN and in response to the request, a command to resume the radio connection.

Description

MANAGING MOBILE-TERMINATED SMALL DATA TRANSMISSIONCROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63 / 493,718, entitled “Managing Mobile-Terminated Small Data Transmission,” filed on March 31, 2023. The entire contents of the provisional application are hereby expressly incorporated herein by reference.FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communications and, more particularly, to communication of downlink data using small data transmission (SDT) techniques at a user equipment (UE) and a distributed unit (DU) when the UE operates in an inactive or idle state associated with a protocol for controlling radio resources.BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] Generally speaking, a base station operating a cellular radio access network (RAN) communicates with a user equipment (UE) using a certain radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of a RAT provides transport channels to the Medium Access Control (MAC) sublayer, which in turn provides logical channels to the Radio Link Control (RLC) sublayer, and the RLC sublayer in turn provides data transfer services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer is disposed above the PDCP sublayer.

[0005] The RRC sublayer specifies the RRC_IDLE state, in which a UE does not have an active radio connection with a base station; the RRC_CONNECTED state, in which the UE has an active radio connection with the base station; and the RRC_INACTIVE state to allow a UE to more quickly transition back to the RRC_CONNECTED state using RAN-level base station coordination and RAN-level paging procedures. In some cases, the UE in the RRC_INACTIVEstate has only one, relatively small packet to transmit. For situations such as these, The 3rd Generation Partnership Project (3GPP) has defined a Small Data Transmission (SDT) procedure to allow the 5G NR to support data transmission for the UE operating in the RRC_INACTIVE state (i.e., without requiring that the UE transition to the RRC_CONNECTED state).

[0006] A network can enable SDT on a radio bearer basis, and a UE initiates Mobile- Originated SDT (MO-SDT) only when less than a configured amount of uplink data awaits transmission across all radio bearers for which SDT is enabled, the downlink Reference Signal Received Power (RSRP) is above a configured threshold, and a valid SDT resource is available. A UE can initiate an MO-SDT procedure with either a transmission over a random access channel (RACH), i.e., random access SDT (RA-SDT), or over Type 1 configured grant (CG) resources, i.e., CG-SDT.

[0007] For RA-SDT, the network configures 2-step and / or 4-step random access resources for SDT. The UE can transmit an initial transmission including data in a message 3 (MSG3) of a 4- step random access procedure or in payload of a message A (MSGA) of a 2-step random access procedure. The network can then schedule subsequent uplink and / or downlink transmissions using dynamic uplink grants and downlink assignments, respectively, after completion of the random access procedure.

[0008] A UE can initiate CG-SDT only with a valid uplink (UL) timing alignment. The UE maintains UL timing alignment UE based on a network-configured, SDT-specific timing alignment timer and DL RSRP of a configured number of highest ranked Synchronization System Blocks (SSBs). Upon expiry of the SDT-specific timing alignment timer, the system releases CG resources. Upon initiating CG-SDT, the UE transmits an initial transmission including data on a CG occasion using a CG, and the network can schedule subsequent uplink transmissions using dynamic grants or on the future CG resource occasions. During CG-SDT, the network schedules downlink transmissions using dynamic assignments. The UE can initiate subsequent uplink transmission only after receiving a confirmation for the initial transmission from the network.

[0009] In some scenarios and implementations, the UE connects to a 5G NR radio access network (NG-RAN) including base stations, where each of one or more base stations includes a central unit (CU) and at least one distributed unit (DU). However, it is not clear how a basestation including a CU and a DU should handle the control plane data or the user plane data for the UE during RA-SDT.

[0010] Further, 3GPP proposed to extend SDT support to Mobile-Terminated SDT (MT- SDT). However, the available techniques for MT-SDT often result in inefficiencies. For example, when a base station such as gNode B (gNB) or gNB-CU receives downlink (DL) data or signaling from the core network, the base station attempts to page the UE with an MT-SDT indication or information. When the UE receives the paging message with the MT-SDT indication, the UE may in response transmit an RRC Resume Request message with a resume cause indicating MT-SDT to the gNB (via a gNB-DU if the gNB is an aggregated base station) that paged the UE. The receiving gNB or the last serving gNB then starts to forward the DL data or signaling to the UE while the UE stays in the RRC_INACTIVE state. It is, however, unclear how the receiving gNB or the last serving gNB can support scenarios in which the DL data or signaling arrives while the UE transmits, or is prepared to transmit, MO-SDT or an RAN Notification Area (RNA) Update for example.SUMMARY

[0011] An example embodiment of the techniques of this disclosure is a method implemented in a user equipment (UE). The method comprises receiving, from a radio access network (RAN) and in an inactive state of a radio connection with the RAN, a paging message including a mobile-terminated small data transmission (MT-SDT) indication; transmitting, to the RAN and subsequent to the paging message, a request to resume the radio connection, the request including a non-SDT cause; and receiving, from the RAN and in response to the request, a command to resume the radio connection.

[0012] Another example embodiment of these techniques is a method implemented in a radio access network (RAN). The method comprises transmitting, to a user equipment (UE) operating in an inactive state of a radio connection with the RAN, a paging message including a mobile- terminated small data transmission (MT-SDT) indication; receiving, from the UE and subsequent to the paging message, a request to resume the radio connection, the request including a non- SDT cause; and transmitting, to the UE and in response to the request, a command to resume the radio connection.

[0013] Yet another example embodiment of these techniques is device comprising processing hardware and configured to implement one of the methods above.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Fig. 1 A is a block diagram of an example system in which a base station and / or a user equipment (UE) can implement the techniques of this disclosure for managing small data transmission between the UE and a radio access network (RAN);

[0015] Fig. IB is a block diagram of an example base station including a central unit (CU) and a distributed unit (DU) that can operate in the system of Fig. 1 A;

[0016] Fig. 2 is a block diagram of an example protocol stack according to which the UE of Fig. 1A communicates with base stations;

[0017] Fig. 3A is a messaging diagram of an example procedure for performing MT-SDT (Mobile-Terminated SDT) when a radio connection between the UE and the base station is inactive;

[0018] Fig. 3B is a messaging diagram of another example procedure for performing MT-SDT from a new base station when a radio connection between the UE and the base station is inactive;

[0019] Fig. 3C is a messaging diagram of yet another example procedure for performing MT- SDT from a new base station when a radio connection between the UE and the base station is inactive;

[0020] Fig. 4A is a messaging diagram of an example procedure for DL data delivery when a radio connection between the UE and the base station is resumed;

[0021] Fig. 4B is a messaging diagram of another example procedure for performing DL data delivery from a new base station when a radio connection between the UE and the base station is resumed;

[0022] Fig. 5A is a messaging diagram of an example procedure for performing MT-SDT when a radio connection between the UE and the base station is inactive in response to a resume cause of RNA update;

[0023] Fig. 5B is a messaging diagram of another example procedure for performing MT-SDT from a new base station when a radio connection between the UE and the base station is inactive in response to a resume cause of RNA update;

[0024] Fig. 5C is a messaging diagram of yet another example procedure for performing MT- SDT from a new base station when a radio connection between the UE and the base station is inactive in response to a resume cause of RNA update;

[0025] Fig. 5D is a messaging diagram of another example procedure for performing MT-SDT from a new base station when a radio connection between the UE and the base station is inactive in response to a resume cause of RNA update;

[0026] Fig. 6A is a flow diagram of an example method, which can be implemented in an RAN node, for transmitting MT-SDT data to a UE;

[0027] Fig. 6B is a flow diagram of another example method, which can be implemented in an RAN node, for transmitting MT-SDT data to a UE;

[0028] Fig. 7 is a flow diagram of an example method, which can be implemented in an RAN node, for transmitting MT-SDT data to a UE;

[0029] Fig. 8A is a flow diagram of an example method, which can be implemented in a UE for reacting to a Paging message from a RAN;

[0030] Fig. 8B is a flow diagram of another example method, which can be implemented in a UE for reacting to a Paging message from a RAN;

[0031] Fig. 9 is a flow diagram of an example method, which can be implemented in a UE for reacting to a Paging message from a RAN;

[0032] Fig. 10A is a flow diagram of an example method, which can be implemented in a RAN node for handling an RRC resume request message and transmitting MT-SDT data to a UE;

[0033] Fig. 10B is a flow diagram of another example method, which can be implemented in a RAN node for handling an RRC resume request message and transmitting MT-SDT data to a UE;

[0034] Fig. 10C is a flow diagram of yet another example method, which can be implemented in a RAN node for handling a Retrieve UE Context Request message and transmitting MT-SDT data to a UE via a new RAN node;

[0035] Fig. 11 A is a flow diagram of an example method, which can be implemented in a RAN node for handling an RRC resume request message and transmitting MT-SDT data to a UE;

[0036] Fig. 1 IB is a flow diagram of yet another example method, which can be implemented in a RAN node for handling a Retrieve UE Context Request message and transmitting MT-SDT data to a UE via a new RAN node.DETAILED DESCRIPTION OF THE DRAWINGS

[0037] Using the techniques discussed in more detail below, a UE and a base station can utilize network resources more efficiently in certain MT-SDT scenarios. In some of these scenarios, for example, the UE transmits an RRC Resume Request message with a resume cause other than MT-SDT, which can be for example MO-SDT or non-SDT cause such as a RAN Notification Area (RNA) Update. In some scenarios, the UE moves out of the configured RNA and becomes unreachable by the XnAP RAN Paging and or Uu Paging message from the gNBs within the RNA.

[0038] To forward the DL data or signaling, the receiving base station or the last serving base station may need to transmit an RRC Resume message to the UE operating in the RRC_INACTIVE state. In response, the UE transitions to the RRC_CONNECTED state and transmits an RRC Resume Complete message. Thus, the base station is unable to maintain the UE in the inactive state, where the UE would be able to perform SDT in accordance with the configuration. This can result in less efficient radio resource and / or power usage. For example, to serve the UE operating in the RRC_CONNECTED state, the base station uses more radio resources and consume more power than would be needed to serve the UE operating in the RRC_INACTIVE state. Similarly, the UE operating in the RRC_CONNECTED state consumes more power to communicate with the base station than the UE would consume in the RRC_1NACT1VE state. It is possible for the receiving base station or the last serving base station to transition the UE back to RRC_INACTIVE first when the base station sends an RRCResume message with resume cause other than the MT-SDT, and then for the receiving base station or the last serving base station to page the UE with an MT-SDT indication to let the UE initiate another RRC resume procedure for MT-SDT. Although the UE can continue to operate in RRC_INACTIVE, this approach however can result in a longer delay for the buffered DL data or signaling and the sub- sequent DL data or signaling communications. The approaches discussed below address these inefficiencies.

[0039] Referring first to Fig. 1A, an example wireless communication system 100 includes a UE 102 (e.g., UE 102A, 102B, 102C or 102D), a base station (BS) 104, a base station 106, and a core network (CN) 110. The base stations 104 and 106 can operate in a RAN 105 connected to the core network (CN) 110. The CN 110 can be implemented as an evolved packet core (EPC) 111 or a fifth generation (5G) core (5GC) 160, for example. The CN 110 can also be implemented as a sixth generation (6G) core, in another example.

[0040] The base station 104 covers a cell 124, and the base station 106 covers a cell 126. If the base station 104 is a gNB, the cell 124 is an NR cell. If the base station 104 is an ng-eNB, the cell 124 is an evolved universal terrestrial radio access (E-UTRA) cell. Similarly, if the base station 106 is a gNB, the cell 126 is an NR cell, and if the base station 106 is an ng-eNB, the cell 126 is an E-UTRA cell. The cells 124 and 126 can be in the same Radio Access Network Notification Areas (RNA) or different RNAs. In general, the RAN 105 can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the base stations 104 and 106. Each of the base stations 104, 106 can connect to the CN 110 via an interface (e.g., S 1 or NG interface). The base stations 104 and 106 also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0041] Among other components, the EPC 111 can include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. The SGW 112 in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 114 is configured to manage authentication, registration, paging, and other related functions. The PGW 116 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP)Multimedia Subsystem (IMS) network. The 5GC 160 includes a User Plane Function (UPF) 162 and an Access and Mobility Management (AMF) 164, and / or Session Management Function (SMF) 166. Generally speaking, the UPF 162 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 164 is configured to manage authentication, registration, paging, and other related functions, and the SMF 166 is configured to manage PDU sessions.

[0042] As illustrated in Fig. 1A, the base station 104 supports a cell 124, and the base station 106 supports a cell 126. The cells 124 and 126 can partially overlap, so that the UE 102 can select, reselect, or hand over from one of the cells 124 and 126 to the other. To directly exchange messages or information, the base station 104 and base station 106 can support an X2 or Xn interface. In general, the CN 110 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells.

[0043] As discussed in detail below, the UE 102 and / or the RAN 105 implement the techniques of this disclosure to communicate data when the radio connection between the UE 102 and the RAN 105 is suspended, e.g., in the inactive or idle state of the protocol for controlling radio resources between the UE 102 and the RAN 105. For clarity, the examples below refer to the RRC_1NACT1VE or RRC_1DLE state of the RRC protocol. As discussed below, the UE 102 in some implementations applies the techniques of this disclosure only if the size of the data (e.g., UL data) is below a certain threshold value.

[0044] In the example scenarios discussed below, the UE 102 transitions to the RRC_INACTIVE or RRC_IDLE state, selects a cell of the base station 104, and exchanges data with the base station 104 (cither via the base station 106 or with the base station 104 directly) without transitioning to the RRC_CONNECTED state. In particular, the UE 102 and the base station 104 of the RAN 105 can communicate using small data transmission procedures, without the UE 102 transitioning to the RRC_CONNECTED state.

[0045] As a more specific example, the UE 102 in some cases transmits data in the uplink (UL) direction to the RAN 105 while the UE 102 operates in the RRC_IN ACTIVE or RRC_IDLE state.

[0046] After the UE 102 determines that data is available for uplink transmission while the UE 102 operates in the RRC_INACTIVE or RRC_IDLE state, the UE 102 can apply one or more security functions to the UL data packet, generate a first UL protocol data unit (PDU) including the security-protected packet, include a UL RRC message along with the first UL PDU in a second UL PDU, and transmit the second UL PDU to the RAN 105. The UE 102 includes a UE identity / identifier (ID) of the UE 102 in the UL RRC message. The RAN 105 can identify the UE 102 based on the UE ID. In some implementations, the UE ID can be an inactive Radio Network Temporary Identifier (LRNTI), a resume identity, or a non-access stratum (NAS) ID. The NAS ID can be an S-Temporary Mobile Subscriber Identity (S-TMSI) or a Global Unique Temporary Identifier (GUTI).

[0047] The security function can include an integrity protection and / or encryption function. When integrity protection is enabled, the UE 102 can generate a message authentication code for integrity (MAC-I) to protect integrity of the data. Thus, the UE 102 in this case generates a security-protected packet including the data and the MAC-I. When encryption is enabled, the UE 102 can encrypt the data to obtain an encrypted packet, so that the security-protected packet includes encrypted data. When both integrity protection and encryption are enabled, the UE 102 can generate a MAC-I for protecting integrity of the data and encrypt the data along with the MAC-I to generate an encrypted packet and an encrypted MAC-I. The UE 102 can then transmit the security-protected packet to the RAN 105, while in the RRC_INACTIVE or RRC_IDLE state.

[0048] In some implementations, the data is an UL service data unit (SDU) of the packet data convergence protocol (PDCP) or SDAP. The UE 102 applies the security function to the SDU and includes the secured 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 can be associated with the medium access control (MAC) layer. Thus, the UE 102 in these cases transmits the secured UL PDCP PDU in the UL MAC PDU. In some implementations, the UE 102 can include, in the UL MAC PDU, a UL RRC message. In other implementations, the UE 102 may omit a UL RRC message from the UL MAC PDU. In such implementations, the UE 102 may omit a UE ID of the UE 102 from the UL MAC PDU. In yet other implementations, the UE 102 can include the UL PDCP PDU in a UL radio link control (RLC) PDU and theninclude the UL RLC PDU in the UL MAC PDU. In some implementations in which the UL MAC PDU includes the UL RRC message, 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 other implementations, the UE can obtain the RRC MAC-I from the UL RRC message with an integrity key (e.g., KRRCint key), an integrity protection algorithm, and the parameters COUNT (e.g., 32-bit, 64-bit or 128- bit value), BEARER (e.g., 5-bit value), and DIRECTION (e.g., 1 -bit value).

[0049] In other implementations, the data is an UL SDU of the NAS. The UE 102 applies the security function to the SDU and includes the secured SDU in a first UL PDU such as a NAS PDU, which can be associated with the NAS layer. For example, the NAS layer can be an MM sublayer or an SM sublayer of 5G, Evolved Packet System (EPS), or 6G. The UE 102 can then include the UL NAS PDU in a second UL PDU, such as a UL RRC message. Thus, the UE 102 in these cases transmits the (first) secured UL NAS PDU in the UL RRC message. In some implementations, the UE 102 can include the UL RRC message in a UL MAC PDU and transmits 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 omit an RRC MAC-I from the UL RRC message. Alternatively, the UE 102 may include an RRC MAC-I as described above.

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

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

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

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

[0054] In other scenarios and implementations, the base station 104 can retrieve the UE ID of the UE 102 from the UL RRC message and identify that the base station 104 stores UE context information of the UE 102. Thus, 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 edge server as described above.

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

[0056] For example, when the base station 104 determines that data is available for downlink transmission to the UE 102 that is currently operating in the RRC_INACTIVE or RRC_IDLE state, the base station 104 can 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 include the first DL PDU in a second DL PDU. To secure the data, the base station 104 can apply the security function (e.g., integrity protection and / or encryption) to the data. More particularly, when integrity protection is enabled, the base station 104 generates a MAC-I for protecting integrity of the data, so that the security-protected packet includes the data and the MAC-I. When encryption is enabled, the base station 104 encrypts the data to generate an encrypted packet, so that the security-protected packet is an encrypted packet. Further, when both integrity protection and encryption are enabled, the base station 104 can generate a MAC-Ifor protecting integrity of the data and encrypt the data along with the MAC-I to generate an encrypted packet and an encrypted MAC-I. The base station 104 in some implementations generates a first DL PDU, such as a DL PDCP PDU including the security-protected packet, and then includes the first DL PDU in a second DL PDU associated with the MAC layer, for example (e.g., a DL MAC PDU), and transmits the second DL PDU to the UE 102 without first causing the UE 102 to transition from the RRC_IN ACTIVE or RRC_IDLE state to the RRC_CONNECTED state. In some implementations, the base station 104 includes the DL PDCP PDU in a DL RLC PDU, then includes the DL RLC PDU in the DL MAC PDU, and then transmits the DL MAC PDU to the UE 102 without first causing the UE 102 to transition from the RRCJNACTIVE or RRC JDLE state to the RRC_CONNECTED state.

[0057] In another implementation, the base station 104 transmits the first DL PDU to the base station 106, which then generates a second PDU (e.g., a DL MAC PDU) including the first DL PDU and transmits the second DL PDU to the UE 102 without first causing the UE 102 to transition from the RRCJNACTIVE or RRC DLE 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 a DL RLC PDU and transmits the DL RLC PDU to the base station 106, which then generates a second DL PDU (e.g., a DL MAC PDU) including the DL RLC PDU and transmits the second DL PDU to the UE 102.

[0058] In some implementations, the base station (i.e., the base station 104 or 106) generates a downlink control information (DCI) and a cyclic redundancy check (CRC) scrambled with an ID of the UE 102 to transmit the second DL PDU generated by the base station. In some implementations, the ID of the UE 102 can be a Radio Network Temporary Identifier (RNTI). For example, the RNTI can be a cell RNTI (C-RNTI), a temporary C-RNTI, or an inactive C- RNTI. The base station transmits the DCI and scrambled CRC on a physical downlink control channel (PDCCH) to the UE 102 operating in the RRC NACTIVE or RRC JDLE state. The base station scrambles the CRC with the ID of the UE 102. In some implementations, the base station may assign the ID of the UE 102 to the UE 102 in a random access response that the base station transmits in a random access procedure with the UE 102 before transmitting the DCI and scrambled CRC. In other implementations, the base station may assign the ID of the UE 102 tothe UE 102 in an RRC message (e.g., an RRC release message or an RRC reconfiguration message) that the base station transmits to the UE 102 before transmitting the DCI and scrambled CRC, e.g., while the UE 102 was previously operating in the RRC_CONNECTED state, RRC_INACTIVE state, or RRC_IDLE state.

[0059] The UE 102 operating in the RRC_INACTIVE or RRC_IDLE state can receive the DCI and scrambled CRC on the PDCCH. The UE 102 then confirms that a physical downlink shared channel (PDSCH), including the second DL PDU, is addressed to the UE according to the ID of the UE 102, DCI, and scrambled CRC. The UE 102 then can retrieve the data from the security-protected packet. If the security-protected packet is an encrypted packet, the UE 102 can decrypt the encrypted packet using the appropriate decryption function and the security key to obtain the data. If the security-protected packet is an integrity-protected packet including the data and the MAC-I, the UE 102 can determine whether the MAC-I is valid. If the UE 102 confirms that the MAC-I is valid, the UE 102 retrieves the data. If, however, 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 — with encrypted data and an encrypted MAC-I — the UE 102 can decrypt the encrypted packet and 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.

[0060] The base station 104 is equipped with processing hardware 130 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 in an example implementation includes a Medium Access Control (MAC) controller 132 configured to perform a random access procedure with one or more user devices, receive uplink MAC protocol data units (PDUs) from one or more user devices, and transmit downlink MAC PDUs to one or more user devices. The processing hardware 130 can also include a Packet Data Convergence Protocol (PDCP) controller 134 configured to transmit DL PDCP PDUs in accordance with which the base station 104 can transmit data in the downlink direction in some scenarios, and receive UL PDCP PDUs in accordance with which the basestation 104 can receive data in the uplink direction in other scenarios. The processing hardware further can include an RRC controller 136 to implement procedures and messaging at the RRC sublayer of the protocol communication stack. The processing hardware 130 in an example implementation includes an RRC inactive controller 138 configured to manage uplink and / or downlink communications with one or more UEs operating in the RRC_INACTIVE or RRC_IDLE state. The base station 106 can include generally similar components. In particular, components 140, 142, 144, 146, and 148 can be similar to the components 130, 132, 134, 136, and 138, respectively.

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

[0062] Fig. IB depicts an example distributed or disaggregated implementation of any one or more of the base stations 104, 106. In this implementation, the base station 104, 106 includes a central unit (CU) 172 and one or more DUs 174. The CU 172 includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and / or special-purpose processing units. For example, the CU 172 can include a PDCP controller, an RRC controller and / or an RRC inactive controller such as PDCP controller 134, 144, RRCcontroller 136, 146 and / or RRC inactive controller 138, 148. In some implementations, the CU 172 can include a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures. In other implementations, the CU 172 does not include an RLC controller.

[0063] Each of the DUs 174 also includes processing hardware that can 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 specialpurpose processing units. For example, the processing hardware can include a MAC controller (e.g., MAC controller 132, 142) configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and / or an RLC controller configured to manage or control one or more RLC operations or procedures. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures.

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

[0065] The CU-CP 172A can be connected to multiple CU-UP 172B through the El interface. The CU-CP 172A selects the appropriate CU-UP 172B for the requested services for the UE 102. In some implementations, a single CU-UP 172B can be connected to multiple CU-CP 172A through the El interface. The CU-CP 172A can be connected to one or more DU 174s through an Fl-C or Wl-C interface. The CU-UP 172B can be connected to one or more DU 174 through an Fl-U or Wl-U interface under the control of the same CU-CP 172A. In some implementations, one DU 174 can be connected to multiple CU-UP 172B under the control of the same CU-CP 172A. In such implementations, the connectivity between a CU-UP 172B and a DU 174 is established by the CU-CP 172A using Bearer Context Management functions. A bearer context is a block of information in a CU-UP node associated with one UE that is used for communication over the El interface. It may include the information about data radio bearers,PDU sessions and QoS flows associated with the UE. The block of information contains the necessary information required to maintain user-plane services for the UE.

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

[0067] In the example stack 200, a 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 an EUTRA PDCP sublayer 208 and, in some cases, to an NR PDCP sublayer 210. Similarly, the NR PHY 202B provides transport channels to the NR MAC sublayer 204B, which in turn provides logical channels to the NR RLC sublayer 206B. The NR RLC sublayer 206B in turn provides data transfer services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 in turn can provide data transfer services to Service Data Adaptation Protocol (SDAP) 212 or a radio resource control (RRC) sublayer (not shown in Fig. 2A). The UE 102, in some implementations, supports both the EUTRA and the NR stack as shown in Fig. 2A, to support handover between EUTRA and NR base stations and / or to support DC over EUTRA and NR interfaces. Further, as illustrated in Fig. 2, the UE 102 can support layering of NR PDCP 210 over EUTRA RLC 206A, and SDAP sublayer 212 over the NR PDCP sublayer 210.

[0068] The EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer 208 or 210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer 206 A or 206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

[0069] On a control plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide signaling radio bearers (SRBs) or an RRC sublayer (not shown in Fig. 2A) to exchange RRC messages or non-access-stratum (NAS) messages, for example. On a user plane, the EUTRA PDCP sublayer 208 and the NR PDCP sublayer 210 can provide DRBs to support data exchange. Data exchanged on the NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0070] Figs. 3A-3C, 4A-4B, and 5A-5D are messaging diagrams of example scenarios in which a UE (e.g., UE 102) and nodes of a RAN (e.g., RAN 105) implement the techniques of this disclosure for uplink and / or downlink small data transmission. Generally speaking, events in Figs. 3A-3C, 4A-4B, and 5A-5D that are similar are labeled with similar reference numbers (e.g., event 302 in Fig. 3A is similar to event 302 in Figs 3B and 3C, events 402 in Figs. 4A and 4B), with differences discussed below where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e.g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures.

[0071] Referring first to Fig. 3A, in a scenario 300A, where the UE 102 is paged by the BS 104 about an MT-SDT and performs RRC connection resume procedure to receive the DL data and / or signaling while maintaining in an inactive state. The base station (BS) 104 includes a CU 172 and a DU 174.

[0072] The UE 102 previously operated 302 in a connected state or inactive state with the base station 104, before transitioning to or maintaining in the inactive state. After a (first) certain period of data inactivity for the UE 102, the CU 172 of the BS 104 can determine that neither the BS 104 nor the UE 102 has transmitted any data in the downlink direction or the uplink direction, respectively, during the (first) certain period. In response to the determination, the CU 172 of the BS 104 transmits 304 a CU-to-DU message (e.g., DL RRC Message Transfer message or UE Context Release Command message) carrying a first RRC release message (e.g., RRCRelease message or RRCConnectionRelease message) to the DU 174. The DU 174 then transmits 306 the first RRC release message to the UE 102 to instruct the UE 102 to transition to or remain in the inactive state. The UE 102 transitions to or remains in the inactive state upon receiving the first RRC release message and operates 308 in the inactive state. In some implementations, the first RRC release message includes a suspendConfig which further includes an SDT configuration (e.g., sdt-Config as specified in the 3GPP TS 38.331). The UE 102 suspends all SRB(s) and DRB(s) and multicast MRB(s), except SRB0 and broadcast MRBs and applies the suspendConfig and SDT configuration and performs corresponding actions. The events 302, 304, and 306 can be collectively referred to as an SDT configuration procedure 380. The CU 172 of the BS 104 can assign UE identity / identifier (ID) (e.g., an I-RNTI or a resumeID) to the UE 102 and include the assigned value in the first RRC release message. After the UE 102 transitions to or remains in the inactive state, the UE 102 may perform one or more RAN notification area (RNA) updates with the CU-CP 172A via the DU 174 without state transitions, in some cases.

[0073] In some implementations, the CU-CP 172A can include a security parameter (e.g., Next Hop Chaining Count) in the first RRC release message. The UE 102 derives security keys (i.e., base key, integrity key(s) and / or encryption key(s)) using the security parameter. For example, the UE 102 derives a base key (e.g., KSNB) using the security parameter and derives integrity key(s) (e.g., KRRCint key and / or the Kupint key) and encryption key(s) (e.g., KRRCenc key and / or Kupenc key) from the base key. The CU-CP 172A derives security keys (i.e., same as the security keys derived by the UE 102) in a similar manner as the UE 102. The CU-CP 172A sends the integrity key (e.g., the Kupiut key) and / or encryption key (e.g., the Kupeuc key) to the CU-UP 172B. The UE 102 and CU-UP 172B use the integrity key (e.g., the Kupint key) and / or encryption key (e.g., the Kupenckey) in data communication. The UE 102 and CU-CP 172A use the integrity key (e.g., the KRRCint key) and / or encryption key (e.g., the KRRCenc key) in communication of the first RRC release message. In the case of a CP-UP split, the CU-CP 172A configures UP ciphering and / or integrity protection over the bearer context setup / modification procedure, with the CU-UP 172B including the security algorithm and User Plane security keys (the encryption key and / or the integrity protection key). In some implementations, the UP ciphering algorithm may require input parameters including a cipher key KEY (e.g., 128-bit), a COUNT (e.g., 32-bit), a bearer identity BEARER (e.g., 5-bit), a transmission direction DIRECTION (e.g., 1-bit), and the required length of the keystream LENGTH. A keystream can be generated by the ciphering algorithm to encrypt the plaintext to generate the ciphertext and to recover / decrypt the ciphertext to the plaintext.

[0074] At a later time, while the UE 102 operates 308 in the inactive state, the CN 110 transmits 310 DL data and / or signaling for the UE 102 to the CU 172 of the BS 104. The CU 172 may check 312 the data size or the assistance information along with the DL data or signaling to determine whether and how to page the UE 102. In some implementations, the (CU 172 of) the BS 104 generates a DL data packet for MT-SDT for the UE 102 instead of receiving it in the event 310 from the CN 110. In response to the DL data, the CU 172 of the BS 104 transmits 314a (F1AP) Paging message with an MT-SDT indication or information to the DU 174. The DU 174 may determine 316 how to page the UE 102 based on the received MT-SDT indication or information. In response, the DU 174 of the BS 104 transmits 318 one or more (Uu) Paging message(s) to the UE 102. The DU 174 may include in the Paging message an MT-SDT indication (e.g., by adding an indicating bit or a paging cause of MT-SDT). The UE 102 is reached by the one or more Paging message(s). The events 312, 314, 316, or 318 can be collectively referred to as an MT-SDT Paging procedure 382. The UE 102, in response to the paging, performs 320A a random access procedure with the DU 174 of the BS 104. In some implementations, the UE 102 selects the Access Category as ‘0’ since the resumption of the RRC connection is triggered by response to NG-RAN paging. In other implementations, the UE 102 selects the Access Category as ‘2’ or ‘8’, for example, or other Access Category value provided by the upper layers and sets the resume cause correspondingly. The UE 102 transmits 322A an RRC resume request message (e.g., RRCResumeRequest message, RRCConnectionResumeRequest message, RRCResumeRequest 1 message, or RRCConnectionResumeRequestl message) to the DU 174. In some implementations, the UE 102 includes a resume cause MT-SDT in the RRC resume request message. In some implementations, the event 322A can be the MSG3 or MSGA as described earlier for the MO- SDT. In some implementations, the UE 102 may also include a UL data in the UL MAC PDU for the RRC resume request message in the event 322 A and the DU 174 buffers the UL MAC PDU. The DU 174 transmits 324A an Initial UL RRC Message Transfer message including the RRC resume request message with the resume cause MT-SDT to the CU 172. In some implementations, based on the resume cause (i.e., MT-SDT) and the buffered DL data and / or signaling, the CU 172 decides to keep the UE 102 in the inactive state for MT-SDT. The CU 172 transmits 326A, to the DU 174, a UE Context Setup Request message including the (stored) Fl UL TEIDs to create the UE Context at the DU 174. The DU 174 responds 328A, to the CU 172, with the UE Context Setup Response message including the Fl DL TEIDs allocated for the DRB(s) for the SDT or MT-SDT. The CU 172 transmits 330A, to the DU 174, the DL data and / or signaling from the CN 110. In some implementations, the CU 172 transmits the DL signaling in the DL RRC Message Transfer message to the DU 174. The DU 174 transmits 332A the DL data and / or signaling to the UE 102.

[0075] In some implementations, the UE 102 sets the contents of the RRC resume request message as described earlier (i.e., setting the resume cause as SDT or MT-SDT). In response to initiating the RRC connection resume procedure or transmitting an RRC Resume Request message of the RRC connection resume procedure, the UE 102, for each radio bearer that is configured for SDT and for SRB1, restores the RLC-BearerConfig associated with the RLC bearers of masterCellGroup and pdcp-Config from the UE Inactive AS context and re-establish PDCP entity for the radio bearer that is configured for SDT without triggering PDCP status report. The UE 102 resumes all the DRBs and SRB1 that are configured for SDT.

[0076] In some implementations, if MO-SDT is received at the DU 174, the DU 174 may include in the Initial UL RRC Message Transfer message of the event 324A an SDT indication. The SDT indication may be an explicit indication in an information element (IE), field, or flag of the Initial UL RRC Message Transfer message, for example.

[0077] After transmitting 310, 330A, 332A the DL data and / or signaling, the CN 110, the CU 172, and the DU 174 may perform subsequently DL data and / or signaling transmission(s). The CN 110 transmits 334 a subsequent DL data and / or signaling to the CU 172. The CU 172 then transmits 336 the subsequent DL data and / or signaling to the DU 174. The DU 174 then transmits 338 the subsequent DL data and / or signaling to the UE 102. The UE 102 may transmits 340 a UL data and / or signaling to the DU 174. The DU 174 then transmits 342 the UL data and / or signaling to the CU 172. The CU 172 then transmits 344 the UL data and / or signaling to the CN 110. The events 334, 336, 338, 340, 342, and 344 can be collectively referred to as a data / signaling communication procedure 392A. The CU 172 may later detect no further activity for the SDT bearers from either the CN 110 or the UE 102. The CU 172 transmits 346A a UE Context Release Command message including a second RRC release message. In other implementations, the CU 172 transmits the second RRC release message in a DL RRC Message Transfer message. The second RRC release message may include SDT configurations similar to the first RRC release message. The DU 174 transmits 348A the second RRC release message to the UE 102. The DU 174 may transmit a UE Context Release Complete message to the CU 172 not shown in the figure in response to the UE Context Release Command message. The UE 102 transitions to or remains in the inactive state upon receiving the second RRC release message and operates 309 in the inactive state. The UE 102 suspends all SRB(s) and DRB(s) andmulticast MRB(s), except SRBO and broadcast MRBs and applies suspendConfig and performs corresponding actions if it is included in the second RRC release message.

[0078] Now referring to Fig. 3B, a scenario 300B related to the scenario 300A but covering an inter-base station case for the MT-SDT since the UE 102 moves into the coverage of the BS 106. The differences between the scenario 300B of Fig. 3B and the scenario 300A Fig. 3A are discussed below.

[0079] Initially the BS 104 and the UE 102 perform the SDT configuration procedure 380 as described in the Fig. 3A and the UE 102 transitions 308 to or maintaining in the inactive state. At a later time, the UE 102 moves out of the coverage of the BS 104 and moves into the coverage of the BS 106. The CN 110 later transmits 310 DL data and / or signaling to the BS 104. The BS 104 may check 312 the data size and / or assistance information for the DL data or signaling and decides to page the UE 102. The BS 104 may pages locally within its coverage similar to the event 318 and transmits 313 an RAN Paging message to the BS 106 which is one of the configured base station within RNA. The BS 104 may include an MT-SDT indication or information in the RAN Paging message. The BS 106 in response to the RAN Paging performs 383 the MT-SDT Paging procedure as described in Fig. 3A. The events 310, 312, 313 and 383 can be collectively referred to as the DL data / signaling arrival and MT-SDT paging procedure 384. The UE 102, in response to the paging, performs 320B a random access procedure with the BS 106. In some implementations, the UE 102 selects the Access Category as ‘0’ since the resumption of the RRC connection is triggered by response to NG-RAN paging. In other implementations, the UE 102 selects the Access Category as ‘2’ or ‘8’, for example, or other Access Category value provided by the upper layers and sets the resume cause correspondingly. The UE 102 transmits 322B an RRC resume request message to the BS 106 similar to 322A which is sent to the BS 104. In some implementations, the UE 102 includes a resume cause MT- SDT in the RRC resume request message. In some implementations, the event 322B can be the MSG3 or MSGA as described earlier for the MO-SDT. In some implementations, the UE 102 may also include a UL data in the UL MAC PDU for the RRC resume request message in the event 322B. The BS 106 transmits 352 a Retrieve UE Context Request message to the BS 104. In some implementations, the BS 106 includes in the Retrieve UE Context Request message the UE Context ID and an RRC Resume Cause. The BS 106 can set the RRC Resume Cause as ‘MT-SDT. The BS 104 identifies the UE context by means of the UE Context ID, and successfully verifies the UE by means of the integrity protection contained in the Retrieve UE Context Request message, and decides to provide the UE context to the new NG-RAN node. In some implementations, the BS 104, based on the resume cause (i.e., MT-SDT) and the buffered DL data and / or signaling, decides to relocate the UE context to the BS 106. The BS 104 in response transmits a. Retrieve UE Context Response message to the BS 106 including the (full) RRC Context. In some implementations, the BS 104 may include a DL indication (e.g., a DL Forwarding IE set to ‘DL forwarding proposed’ in the Data Forwarding and Offloading Info from source NG-RAN node IE). In other implementation, the DL indication is a newly defined IE (e.g., MT-SDT data available) specifically for MT-SDT. The BS 106 transmits 356 an Xn-U Address Indication message to the BS 104 to provide transfer data forwarding information such as the DRB ID and the corresponding DL Forwarding UP TNL Information or PDU Session level DL data forwarding UP TNL Information. In some implementations, the BS 106 decides to transmit the Xn-U Address Indication message to the BS 104 based on the received DL indication in the event 354. In other implementations, the BS 106 decides to transmit the Xn-U Address Indication message to the BS 104 based on the received MT-SDT indication or information in the event 313. The BS 104, according to the DL data forwarding UP TNL information, transmits 330B the DL data to the BS 106. The BS 104 transmits 33OB the DL signaling using the RRC Transfer message to the BS 106 if any. In some implementations, based on the DL indication and the received DL data and / or signaling, the BS 106 decides to keep the UE 102 in the inactive state for MT-SDT. The BS 106 further transmits 332B the DL data and / or signaling to the UE 102. The BS 106 transmits 358 a Path Switch Request message to the CN 110 and the CN 110 in response transmits 360 a Path Switch Request Acknowledge to the BS 106. The BS 106 transmits 362 a UE Context Release message to the BS 104 and the BS 104 can release the radio and control plane resources for the associated UE context for the UE 102. The events 358, 360, and 362 can be collectively referred to as the path switch and UE context release procedure 385. The CN 110, BS 106, and the UE 102 may subsequently perform 392B the DL data and / or signaling communication procedure as described in the Fig. 3A. The BS 106 may later detect no further data or signaling activity for the SDT bearers and determine the end of SDT for the UE 102. The BS 106 transmits 346B an RRC release message to the UE 102 andthe UE 102 transitions 309 to the inactive state. The BS 106 may configure the suspendConfig and / or the sdt-Config in the RRC release message to the UE 102 similar to the Fig. 3A.

[0080] Referring next to Fig. 3C, a scenario 300C is generally similar to the scenario 300B, except that the BS 104 keeps the UE context without relocation. The differences between the scenario 300C of Fig. 3C and the scenarios 300A and 300B of Figs. 3A and 3B are discussed below.

[0081] After receiving 352 the Retrieve UE Context Request message from the BS 106, the BS 104 may decide to keep the UE context. In some implementations, based on the resume cause (i.e., MT-SDT) and the received DL data and / or signaling, the BS 104 decides to keep the UE 102 in the inactive state for MT-SDT. The BS 104, instead of transmitting 354 the Retrieve UE Context Response message, transmits 355 a Partial UE Context Transfer message to the BS 106. The BS 104 may include a DL indication (e.g., a Data Forwarding and Offloading Info from source NG-RAN node IE or a specific defined field / IE in the SDT DRB To Be Setup List or SDT SRB To Be Setup List). The BS 106 may infer that there is MT-SDT data from the CN 110 and buffered at the BS 104 by the RAN Paging message in the event 384 or by the DL indication in the event 355. The BS 106 in response transmits a Partial UE Context Transfer Acknowledge message to the BS 104 and provides the SDT Data Forwarding Information. The BS 104 transmits 330B the DL data (e.g., according to the data forwarding information) and / or signaling (e.g., via the RRC Transfer message) to the BS 106. The BS 106 further transmits 332B the DL data and / or signaling to the UE 102. The CN 110, the BS 104, the BS 106, the UE 102 may perform subsequent data or signaling communications. The CN 110 transmits 334 a DL data and / or signaling to the BS 104. The BS 104 further transmits 337 the DL data and / or signaling to the BS 106. The BS 106 further transmits 338C the DL data and / or signaling to the BS 104. The UE 102 transmits 340C a UL data and / or signaling to the BS 106. The BS 106 further transmits 343 the UL data and / or signaling to the BS 104. The BS 104 further transmits 344 the UL data and / or signaling to the CN 110. The events 334, 337, 338C, 340C, 343, and 344 can be collectively referred to as the data / signaling communication procedure 392C.

[0082] The BS 104 may later detect no further data or signaling activity for the SDT bearers and determine the end of SDT for the UE 102. The BS 104 generates an RRC release message and transmits 350 a Retrieve UE Context Failure message including the RRC release message tothe BS 106. The BS 106 transmits 346B an RRC release message to the UE 102 and the UE 102 transitions 309 to or maintains in the inactive state. The BS 104 may configure the suspendConfig and / or the sdt-Config in the RRC release message to the UE 102 similar to the Fig. 3A.

[0083] The events 320B, 322B, 352, 355, 357, 330B, 332B, 392C, 350, and 346B can be collectively referred to as an MT-SDT without a UE context relocation procedure 386.

[0084] Referring next to Fig. 4A, a scenario 400A is similar to the scenarios 300A, 300B, and 300C, but the UE 102 initiates the RRC resumption using a non-SDT cause. Events in this scenario similar to those discussed above are labeled with similar reference numbers, and the examples and implementations for Figs. 3A-3C can apply to Fig. 4A (e.g., event 302 is similar to event 402, event 307 is similar to event 407, and event 380 is similar to event 480). The differences between the scenario 400A of Fig. 4A and the scenarios 300A, 300B, and 300C of Figs. 3 A, 3B and 3C are discussed below.

[0085] The CU 172 and DU 174 of the BS 104, and the UE 102 initially performs SDT configuration procedure 480 similar to the event 380. The UE 102 transitions 408 to the inactive state. The CN 110 later transmits 410 a DL data and / or signaling to the CU 172 of the BS 104. The CU 172 and DU 174 of the BS 104 and the UE 102 performs an MT-SDT Paging procedure 482 for the DL data and / or signaling. The UE 102 performs 420 a random access procedure 420A with the DU 174. The UE 102, different from the scenarios 3OOA-3OOC, may initiate the random access procedure not in response to the paging procedure in the event 482 but with other triggering reasons (e.g., when upper layers or AS (upon triggering RNA updates while the UE is in RRC_IN ACTIVE, for NR sidclink communication / discovcry / V2X sidclink communication, etc.) requests the resume of a suspended RRC connection). The UE 102 therefore transmits 422A an RRC Resume Request message (e.g., RRCResumeRequest message, RRCConnectionResumeRequest message, RRCResumeRequest 1 message, or RRCConnectionResumeRequestl message) including a non-SDT cause (e.g., emergency, highPriority Access, mt-Access, mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo- SMS, rna-Update, mps-Priority Access, mcs-Priority Access, etc.) to the DU 174. The DU 174 transmits 424A an Initial UL RRC Message Transfer message including the RRC Resume Request message to the CU 172. In some implementations, based on the resume cause (i.e., non-SDT) and the buffered DL data and / or signaling, the CU 172 decides to transition the UE 102 to the connected state in order to transmit the DL data and / or signaling. The CU 172 transmits 426A a UE Context Setup Request message to the DU 174 and the DU 174 in response transmits 428A a UE Context Setup Response message to the CU 172. The DU 174 establishes the UE Context including, among others, SRB,DRB, BH RLC channel, Uu Relay RLC channel, PC5 Relay RLC channel, and SL DRB configuration. Therefore, the full UE context is established not only for the DRB(s) or SRB configured for SDT. The CU 172 generates an RRC resume message (e.g., RRCResume or RRCConnectionResume message) according to the received information in the event 428A and the CU 172 transmits 464A a DL RRC Message Transfer message including the RRC resume message to the DU 174. The DU 174 transmits 466A the RRC resume message to the UE 102. The UE 102 accordingly transitions 407 to the connected state. The UE 102 transmits 468A an RRC resume complete message to the DU 174. The DU 174 transmits 470A an UL RRC Message Transfer message including the RRC resume complete message to the CU 172. The CU 172 then starts to transmit 430A the DL data and / or signaling to the DU 174. The DU 174 transmits 432A the DL data and / or signaling to the UE 102. The CN110, CU 172, DU 174 and the UE 102 may perform subsequent data communication procedure 492A similar to 392A.

[0086] In some implementations, the UE 102 sets the resume cause of the RRC resume request message as non-SDT as described earlier. In response to initiating the RRC connection resume procedure or transmitting an RRC Resume Request message of the RRC connection resume procedure, the UE 102 refrains from restoring the RLC-BearerConfig associated with the RLC bearers of masterCellGroup and pdcp-Config from the UE Inactive AS context and reestablish PDCP entity for the radio bearer that is configured for SDT without triggering PDCP status report for each radio bearer that is configured for SDT and for SRB1. The UE 102 refrain from resuming all the DRBs and SRB1 that are configured for SDT and for non-SDT.

[0087] Referring next to Fig. 4B, a scenario 400B is similar to the scenarios 400A, 300A, 300B, and 300C, but the BS 106 (i.e., the receiving base station) decides to transition the UE 102 to the connected state to receive DL data and / or signaling after retrieving the UE context. The differences between the scenario 400B of Fig. 4B and the scenarios 400A, 300A, 300B, and 300C of Figs. 4A, 3A, 3B, and 3C are discussed below.

[0088] In the scenario 400B, the CN 110, BS 104, BS 106, and the UE 102 may perform the DL data / signaling arrival and MT-SDT paging procedure 484. In some implementations, the BS 106 may locate outside of configured RNA so that the RAN Paging message from the BS 104 cannot reach it. The UE 102 in such case is not paged by the BS 106 for the MT-SDT. Different from scenario 300B, the UE 102 initiates the random access procedure with the BS 106 and transmits 422B an RRC resume request message with a non-SDT cause to the BS 106. The BS 106 transmits 452 the Retrieve UE Context Request message with the non-SDT cause to the BS 104 similar to the event 352. The BS 104 decides to relocate the UE context and transmits 454 the Retrieve UE Context Response message to the BS 106 similar’ to the event 354. The BS 106 transmits 456 the Xn-U Address Indication message to the BS 104 similar’ to the event 356. The BS 106 decides, instead of the keeping the UE 102 in the inactive state, to transition the UE 102 to connected state to receive the DL data and / or signaling. The BS 106 transmits 466B an RRC resume message to the UE 102. The UE 102 transitions 407 to the connected state and transmits 468B an RRC resume complete message to the BS 106. The BS 104 forwards 430B the DL data and / or signaling to the BS 106 and the BS 106 transmits the DL data and / or signaling to the UE 102. The BS 106, BS 104 and the CN 110 performs the path switch and UE context release procedure 485. The CN 110, BS 106, BS 104 and the UE 102 may perform subsequent data / signaling communication procedure 492B.

[0089] In some implementations, the UE 102 sets the resume cause of the RRC resume request message as non-SDT as described earlier. In response to initiating the RRC connection resume procedure or transmitting an RRC Resume Request message of the RRC connection resume procedure, the UE 102 refrains from restoring the RLC-BearerConfig associated with the RLC bearers of masterCellGroup and pdcp-Config from the UE Inactive AS context and reestablish PDCP entity for the radio bearer that is configured for SDT without triggering PDCP status report for each radio bearer that is configured for SDT and for SRB1. The UE 102 refrain from resuming all the DRBs and SRB 1 that are configured for SDT and for non-SDT.

[0090] Referring next to Fig. 5A, a scenario 500A is similar to the scenarios 300A-300C and 400A-400B, but here the UE 102 initiates the RRC resumption using a resume cause “RNA update.” Events in this scenario similar to those discussed above are labeled with similar reference numbers, and the examples and implementations for Figs. 3A-3C or 4A-4B can applyto Fig. 5A (e.g., event 580 is similar to event 380 or 480). The differences between the scenario 500A and the scenarios 3OOA-3OOC and 400A-400B are discussed below.

[0091] The CN 110 transmits 510 a DL data and / or signaling to the CU 172 while the UE 102 is configured with SDT by the SDT configuration procedure 580 and operates in inactive state 508. The DU 174 may receive 514 a F1AP Paging message including an MT-SDT indication and / or information for the CU 172. In some implementations or situations, the UE 102 may performs 520A a random access procedure with the DU 174 before the DU 174 could page it. The UE 102 transmits 522A an RRC resume request message with a resume cause “RNA update” (or other non-SDT cause as described in Figs. 4A or 4B) to the DU 174. The RNA update may be triggered when the UE 102 moves out of the configured RNA, or periodically. The DU 174 transmits an Initial UL RRC Message Transfer message including the RRC resume request message to the CU 172. In some implementations, the CU 172 determines to keep the UE in the inactive state based on the buffered DL data and / or signaling and the resume cause. The CU 172 transmits 526A a UE Context Setup Request message to the DU 174 and the DU 174 in response transmits 528A a UE Context Setup Response message to the CU 172. The CU 172 transmits 530A the DL data and / or signaling to the DU 174. The DU 174 transmits 532A the DL data and / or signaling to the UE 102 while the UE operates in inactive state. The CN 110, CU 172, DU 174, and the UE 102 may perform subsequent data / signaling communication procedure 592A. The CU 172 may later detect no further data activity and determine the end of SDT for the UE 102. The CU 172 transmits 546A a UE Context Release Command message including an RRC release message to the DU 174. The DU 174 transmits 548A the RRC release message to the UE 102. The UE 102 transitions 509 to the inactive state and applies the suspendConfig and / or sdt-Config if included. Therefore, the UE 102 can be kept in the inactive state although it does not include an MT-SDT resume cause in the RRC resume request message.

[0092] In some implementations, in response to initiating the RRC connection resume procedure or transmitting an RRC Resume Request message including the RAN update resume cause (or other non-SDT cause) of the RRC connection resume procedure, the UE 102 restores the RLC-BearerConfig associated with the RLC bearers of masterCellGroup and pdcp-Config from the UE Inactive AS context for each radio bearers that is configured for SDT and for SRB 1. The UE 102 resumes all the radio bearers that arc configured for SDT.

[0093] Referring next to Fig. 5B, a scenario 500B is similar to the scenarios 500A that the UE 102 initiates the RRC resumption using a RNA update cause. Events in this scenario similar’ to those discussed above are labeled with similar reference numbers, and the examples and implementations for Figs. 3A-3C, 4A-4B, or 5A can apply to Fig. 5B (e.g., event 522B is similar to event 322A, 422A or 522A). The differences between the scenario 500B and the scenarios 300A-300C, 400A-400B, and 500A are discussed below.

[0094] The CN 110 transmits 510 a DL data and / or signaling to the BS 104 while the UE 102 is configured with SDT by the SDT configuration procedure 580 and operates in inactive state 508. The BS 106 may receive 513 an RAN Paging message including an MT-SDT indication and / or information for the BS 104 if the BS 106 is within the configured RNA of the BS 104. In some implementations or situations, the UE 102 may performs 520B a random access procedure with the BS 106 before the BS 106 could page it. The UE 102 transmits 522B an RRC resume request message with a resume cause “RNA update” (or another non-SDT resume cause) to the BS 106. The RNA update may be triggered when the UE 102 moves out of the configured RNA (i.e., the BS 106 is out of the configured RNA), or periodically. The BS 106 transmits 552 a Retrieve UE Context Request message including the RRC resume cause “RAN update” to the BS 104. The BS 104 determines to relocate the UE context and transmits 554 a Retrieve UE Context Response message to the BS 106. In some implementations, the BS 104 determines to relocate the UE context to the BS 104 based on the buffered DL data and / or signaling and the resume cause and / or whether the BS 106 is out of the configured RNA. In some implementations, the Retrieve UE Context Response message in the event 554 includes a DL indication. Similar’ to Fig. 3B or 4B, the BS 106 sends a Xn Address Indication message to the BS 104. The BS 104 transmits 530B the DL data and / or signaling (e.g., via the RRC Transfer message) to the BS 106. The BS 106 refrains from transitioning the UE 102 to the connected state and transmits 532B the DL data and / or signaling to the UE 102. The BS 106, BS 104, and the CN 110 performs the path switch and UE context release procedure 585. The CN 110, BS 106, and the UE 102 may perform subsequent data / signaling communication procedure 592B. The BS 106 later detects that no further data activity for the UE 102 and transmits 546B an RRC release message to the UE 102. The UE 102 transitions 509 to the inactive state and applies suspendConfig and sdt-Config if included.

[0095] Referring next to Fig. 5C, a scenario 500C is similar to the scenarios 500B or 500A that the UE 102 initiates the RRC resumption using a RNA update cause. Events in this scenario similar to those discussed above are labeled with similar reference numbers, and the examples and implementations for Figs. 3A-3C, 4A-4B, or 5A-5B can apply to Fig. 5C. The differences between the scenario 500C and the scenarios 300A-300C, 400A-400B, and 500A-500B are discussed below.

[0096] After receiving 552 from the BS 106 the Retrieve UE Context Request message including the RRC resume cause “RNA Update” (or another non-SDT resume cause), the BS 104 decides to keep the UE context and keep the UE 102 staying in the inactive state. In some implementations, the BS 104 makes the decision based on the received DL data (e.g., data size) and / or signaling (e.g., assistance information) and the resume cause and / or that the BS 104 had configured SDT at the UE 102. In some implementations, the BS 104 receives from the BS 106 the Retrieve UE Context Request message before it could have transmitted 513 the RAN Paging message for the UE 102. The BS 104 transmits 555 a Partial UE Context Transfer message to the BS 106. In some implementations, the Partial UE Context Transfer message includes a DL indication (e.g., Data Forwarding and Offloading Info from source NG-RAN node IE in the SDT DRB / SRB to Be Setup Item or a specific MT-SDT indication). The BS 106 in response transmits 557 a Partial UE Context Transfer Acknowledge message to the BS 104. The BS 104 then transmit 530B the DL data and / or signaling (e.g., via the RRC Transfer message) to the BS 106. The BS 106 transmits 532B the DL data and / or signaling to the UE 102. The CN 110, BS 104, BS 106, and the UE 102 may perform subsequent data / signaling communication procedure 592C. The BS 104 later detects no further data activity for the UE 102 and decides to transitions the UE 102 to the inactive state. Different from the MO-SDT that the detecting of end of SDT is done at the receiving BS (i.e., the BS 106) and the receiving BS may need to transmit a Retrieve UE Context Confirm message to the last serving BS (i.e., the BS 104) to indicate the end of SDT or data inactivity. The BS 104 transmits 550 a Retrieve UE Context Failure message including an RRC release message to the BS 106. The BS 106 transmits 546B the RRC release message to the UE 102. The UE 102 transitions 509 to or maintains in the inactive state in response to receiving the RRC release message. In some implementations, the RRC release message includes suspendConfig and / or sdt-Config and the UE 102 applies the suspendConfig and / or sdt-Config.

[0097] Referring next to Fig. 5D, a scenario 500D is similar to the scenarios 500A-500C that the UE 102 initiates the RRC resumption using a RNA update cause. The differences between the scenario 500C and the scenarios 300A-300C, 400A-400B, and 500A-500C are discussed below.

[0098] After receiving 552 from the BS 106 the Retrieve UE Context Request message including the RRC resume cause “RNA Update” (or another non-SDT resume cause), the BS 104 decides to keep the UE context and keep the UE 102 staying in the inactive. In some implementations, the BS 104 makes the decision based on the received DL data (e.g., data size) and / or signaling (e.g., assistance information) and the resume cause and / or that the BS 104 had configured SDT at the UE 102. In some implementations, the BS 104 receives from the BS 106 the Retrieve UE Context Request message before it could have transmitted 513 the RAN Paging message for the UE 102. The BS 104 transmits 550 a Retrieve UE Context Failure message to the BS 106 including an RRC release message for the UE 102. The BS 106 transmits 546B the RRC release message to the UE 102. The UE 102 transitions 509 to or maintains in the inactive state and applies suspendConfig and / or sdt-Config if included in the RRC release message. The BS 104 may transmit 570 a (second) RAN Paging message including the MT-SDT indication or information to the BS 106 after the event 550. The BS 106 in response performs the paging procedure 583 with the UE 102. The CN 110, BS 104, BS 106, and the UE 102 then performs an MT-SDT without a UE context relocation procedure 586 similar to the event 386 as described in the Fig. 3C. Compared with the scenario 300C, the scenario 500D has extra steps to put the UE 102 back to inactive state in response to the RRC resumption procedure with resume cause “RNA update” (or another non-SDT cause). The UE 102 is able to stay in the inactive state to perform SDT data communication but the initial DL data and / or signaling from the CN 110 in the event 510 experiences a much longer delay than in the scenario 300C.

[0099] Next, several example methods that can be implemented in one or more base stations, DUs, CUs, or otherwise in a RAN to support MT-SDT in the inactive state with a UE, are discussed with reference to Figs. 6A-7 and Figs. 10A-11B. In addition, several example methods that can be implemented in one or more UEs in the inactive state with a RAN, are discussed with reference to Figs. 8A-9.

[0100] Fig. 6A illustrates an example method 600A for transmitting DL data to a UE (e.g., UE 102) and, depending on the resume cause in the RRC resume request message, transitioning the UE to the inactive state or connected state to transmit the DL data. The method 600A can be implemented in a first RAN node (e.g., CU 172 of the BS 104, BS 104 or BS 106) of Figs. 3A- 3C, 4A-4B, 5A-5D, for example.

[0101] The method 600A begins at block 602, where the first RAN node notifies the UE of initiating MT-SDT (e.g., event 314, 382, 482, or 514). At block 604, the first RAN node receives an RRC Resume Request message including a resume cause from the UE (e.g., event 322A, 322B, 422A, 422B, 522A or 522B). At block 606, the first RAN node determines whether the resume cause is an MT-SDT cause. If the resume cause is set to an MT-SDT cause at block 606, flow proceeds to block 608 where the first RAN node transmits at least one DL data packet to the UE without transitioning the UE to a connected state (e.g., event 330A-332A, 392A, 392B or 332B). Otherwise if the resume cause is other than the MT-SDT cause (i.e., the resume cause is a non-SDT cause) at block 606, the flow proceeds to block 610 where the first RAN node transitions the UE to the connected state (e.g, event 464A-466A or 466B). At block 612, the first RAN node transmits the at least one DL data packet to the UE operating in the connected state (e.g., event 430A-432A or 432B).

[0102] In some implementations, the first RAN node (e.g., a base station) transmits a paging message (e.g., RRC paging message) including a UE ID (e.g., I-RNTI or full-RNTI) of the UE and a first MT-SDT indication for the UE on one or more cells to notify the UE of initiating MT- SDT. The UE ID addresses the UE and the first MT-SDT indication indicates the paging message pages the UE for MT-SDT. In other implementations, the first RAN node (e.g., a CU or CU-CP) transmits a CU-to-DU message (e.g., F1AP paging message) to each of one or more DUs to cause the each DU to transmit a paging message (e.g., an RRC paging message) on one or more cells of the each DU. Each of the CU-to-DU message(s) includes the UE ID and a second MT-SDT indication. In response to receiving the respective CU-to-DU message, the each DU generates a respective paging message (e.g., an RRC paging message) including the UE ID and the first MT-SDT indication and transmits the respective paging message on one or more cells operated by the each DU. The second MT-SDT indication indicates the each DU to include the first MT-SDT indication in the respective paging message.

[0103] In some implementations, the first RAN node receives the at least one DL data packet from a core network (e.g., the CN 110, the AMF 164 or UPF 162) and determines to notify the UE of initiating MT-SDT in response to receiving the at least one DL data packet.

[0104] In other implementations, the first RAN node receives a BS-to-BS message (e.g., XnAP Paging message) from another RAN node to request the first RAN node to page the UE for MT-SDT. The first RAN node determines to notify the UE of initiating MT-SDT in response to receiving the BS-to-BS message. The BS-to-BS message includes the UE ID of the UE and a third MT-SDT indication, and the first RAN node includes the UE ID and the first MT-SDT indication in the paging message (e.g., an RRC paging message) in response to the BS-to-BS message. The third MT-SDT indication indicates the first RAN node to include the first MT- SDT indication in the paging message.

[0105] Fig. 6B illustrates another example method 600B similar to the method 600A, except that the method 600B includes blocks 605 and 607 instead of blocks 604 and 606. At block 605, the first RAN node receives a Retrieve UE Context Request message from a second RAN node (e.g., event 352, 452 or 552). At block 607, the first RAN node determines whether the Retrieve UE Context Request message includes an MT-SDT cause. If the Retrieve UE Context Request message includes an MT-SDT cause at block 607, flow proceeds to block 608. Otherwise, if the Retrieve UE Context Request message does not include a resume cause or includes a resume cause other than the MT-SDT cause at block 607, the flow proceeds to block 610.

[0106] In some implementations, the MT-SDT cause in the Retrieve UE Context Request message is an RRC Resume Cause lE / ficld with a value ‘SDT’ or ‘MT-SDT.’ In other implementations, the MT-SDT cause in the Retrieve UE Context Request message is an SDT Support Request lE / filed with an SDT indicator or an MT-SDT indicator.

[0107] Fig. 7 illustrates an example method 700, where depending on whether the MT-SDT cause is included in the Retrieve UE Context Request message received from a second RAN node, the first RAN node is for deciding whether to transfer partial or full UE context to the second RAN node. The method 700 can be implemented in a RAN node (e.g., CU 172 of the BS 104, BS 104 or BS 106) of Figs. 3A-3C, 4A-4B, 5A-5D, for example. The method 700 is similarto the method 600B, where blocks 702, 704 and 706 are identical to blocks 602, 605 and 607, respectively.

[0108] If the Retrieve UE Context Request message includes an MT-SDT cause at block 706, flow proceeds to block 708 where the first RAN node transmits a Partial UE Context Transfer message to the second RAN node in response to the Retrieve UE Context Request message (e.g., event 355). Otherwise, if the Retrieve UE Context Request message does not include a resume cause or includes a resume cause other than the MT-SDT cause at block 706, the flow proceeds to block 710 where the first RAN node transmits a Retrieve UE Context Response message to the second RAN node in response to the Retrieve UE Context Request message (e.g., event 454 or 554).

[0109] In some implementations, the MT-SDT cause in the Retrieve UE Context Request message is an RRC Resume Cause lE / field with a value ‘SDT’ or ‘MT-SDT.’ In other implementations, the MT-SDT cause in the Retrieve UE Context Request message is an SDT Support Request lE / filed with an SDT indicator or an MT-SDT indicator. In some implementations, the Partial UE Context Transfer message includes a Partial UE Context Information for SDT IE containing the UE context information for NR SDT as defined in 3GPP TS 38.423 and the Partial UE Context Transfer message includes a DL indication.

[0110] In some implementations, the first RAN node transmits a BS-to-BS message to the second RAN node to request the second RAN node to page the UE for MT-SDT. In response to receiving the BS-to-BS message, the second RAN node pages the UE for MT-SDT, similar to the first RAN node described in the examples and implementations for the method 600A.

[0111] Fig. 8A illustrates an example method 800A for a UE (e.g., UE 102) to react to a Paging message and set a corresponding resume cause. The method 800A can be implemented in a UE of Figs. 3A-3C, 4A-4B, 5A-5D, for example.

[0112] The method 800A begins at block 802, where the UE receives a Paging message for a UE from a RAN (e.g., event 318, 383, 482, 484 or 583). At block 804, the UE determines whether the Paging message includes an MT-SDT indication for the UE. If the Paging message includes an MT-SDT indication for the UE at block 804, the flow proceeds to block 806 where the UE sets a resume cause (value) to an MT-SDT cause. Otherwise, if the Paging message doesnot include the MT-SDT indication for the UE at block 804, the flow proceeds to the block 808 where the UE sets the resume cause (value) based on an Access Identity. The flow then proceeds from block 808 to block 810 as well as block 806. At block 810, the UE transmits an RRC Resume Request message including the resume cause to the RAN (e.g., event 322A, 322B, 422A, 422B, 522A or 522B).

[0113] In some implementations, the Paging message includes a first paging record for the UE. The first paging record includes a UE ID (e.g., I-RNTI or full-RNTI) of the UE and the MT- SDT indication. In other words, the RAN uses the first paging record to page the UE for MT- SDT. In some implementations, the Paging message may include a second paging record for an addition UE. The second paging record includes a UE ID of the additional UE and does not include the MT-SDT indication. In other words, the RAN uses the second paging record to page the additional UE not for MT-SDT.

[0114] In some implementations, if the UE is configured for multimedia priority service(s) (MPS), the UE determines the Access Identity is 1. In this case, the UE sets the resume cause to mps-Priority Access indicating MPS priority access. In another example, if the UE is configured for mission critical service(s) (MCS), the UE determines the Access Identity is 2. In this case, the UE sets the resume cause to mcs-Priority Access indicating MCS priority access. In yet another example, if the UE has a Universal Subscriber Identity Module (USIM) including an Access Class with value N, the UE determines the Access Identity is N, where N is 11, 12, 13, 14 or 15. In this case, the UE sets the resume cause to highPriority Access indicating high priority access. If the Access Identity is a value other than 1, 2, 11, 12, 13, 14 or 15, the UE sets the resume cause to mt- Access indicating mobile-terminated access.

[0115] Fig. 8B illustrates an example method 800B similar to 800A, except that the method 800B includes block 805. If the Paging message includes the MT-SDT indication for the UE at block 804, the flow proceeds to block 805, where the UE determines whether one or more conditions for MT-SDT are satisfied. If the one or more conditions for MT-SDT arc satisfied at block 805, the flow proceeds to block 806. Otherwise, if the one or conditions for MT-SDT are not satisfied, the flow proceeds to block 808.

[0116] The one or more conditions can include for example determining that the UE receives a system information block (SIB) broadcast by the RAN on a serving cell that the UE is campingon, where the SIB indicates SDT is allowed. For example, the SIB is a SIB 1 and the SIB 1 includes a SDT-ConfigCommon IE.

[0117] Further, the one or more conditions can include determining that the UE receives a SDT configuration (e.g., SDT-Config IE) from the RAN.

[0118] Still further, the one or more conditions can include determining that the UE obtained, on the serving cell, a DL signal strength above a certain threshold. For example, the DL signal strength is in unit of Reference Signal Received Power (RSRP). In some implementations, the RAN includes the threshold in the SIB (e.g., the SIB1 or SDT-ConfigCommon IE). In some implementations, the UE obtains the DL signal strength from a DL pathloss reference (signal).

[0119] Fig. 9 illustrates an example method 900 for a UE (e.g., UE 102) for reacting an incoming paging message and initiating an RRC connection resume procedure. The method 800A can be implemented in a UE of Figs. 3A-3C, 4A-4B, 5A-5D, for example.

[0120] The method 900 starts at block 902 where the UE receives, from an RAN, a first RRC Release message configuring the UE to transition to an inactive state and configuring SDT (e.g., event 304-306, 380, 480, 580). At block 904, the UE transitions to or remains in the inactive state in response to the first RRC Release message (e.g., event 308, 408, 508). At block 906, the UE receives a Paging message from the RAN (e.g., event 318, 383, 482). At block 908, the UE initiates an RRC connection resume procedure (in response to the Paging message) (e.g., event 322A, 322B, 422A, 422B, 522A, 522B). At block 910, the UE applies an RLC bearer configuration and a PDCP configuration for each of the at least one radio bearer configured for SDT and / or SRB1, in response to initiating the RRC connection resume procedure or transmitting an RRC Resume Request message of the RRC connection resume procedure. At block 912, the UE receives DL data / signaling from the RAN via the at least one radio bearer configured for SDT and / or SRB1, after applying the RLC bearer configuration(s) and PDCP configuration(s). At block 914, the UE may transmit UL data / signaling to the RAN via the at least one radio bearer configured for SDT and / or SRB 1 , after applying the RLC bearer configuration(s) and PDCP configuration(s) or receiving the DL data / signaling (e.g., event 322A, 392A, 322B, 392B, 392C, 592A, 592B, 592C). At block 916, the UE may receive, from the RAN, a second RRC Release message transitioning the UE to the inactive state or an idle state(e.g., event 348A, 346B, 548A, 546B). The UE transitions to the inactivate state or an idle state in response to receiving the second RRC release message.

[0121] In some implementations, the UE suspends at least one radio bearer configured for SDT and / or SRB1, after (e.g., in response to) receiving the first RRC Release message.

[0122] In some implementations, the UE resumes the at least one suspended radio bearer configured for SDT and / or SRB 1 in response to initiating the RRC connection resume procedure or transmitting an RRC Resume Request message of the RRC connection resume procedure.

[0123] Fig. 10A illustrates an example method 1000A for transmitting MT-SDT data to a UE (e.g., UE 102) in response to an RRC Resume Request message with a cause RNA update. The method 1000A can be implemented in an RAN node (e.g., CU 172 of the BS 106 or BS 106) of Fig. 5B acting as a receiving base station, for example.

[0124] The method 1000A begins at block 1006, where the RAN node receives an RRC Resume Request message containing I-RNTI and a cause RNA update (through a DU) (e.g., event 522B). The RAN node at block 1008 transmits, to the last serving base station, a Retrieve UE Context Request message (based on the I-RNTI) and a resume cause RNA update (e.g., event 552). The RAN node at block 1010 receives, from the last serving base station, a Retrieve UE Context Response message including RRC Context and a DL indication (indicating MT-SDT) (e.g., event 554). At block 1012, the RAN node receives data / signaling from the last serving base station (e.g., event 530B). At block 1014, the RAN node transmits, to the UE, the data / signaling (and subsequent DL data / signaling) (e.g., event 532B or 592B). At block 1016, the RAN node detects the end of SDT and decides to send UE back to RRC Inactive. The RAN node at block 1018 generates an RRC Release message including suspendConfig and / or MT-SDT configuration. At block 1020, the RAN node transmits, to the UE, the RRC Release message (through a DU) (e.g., event 546B).

[0125] Fig. 10B illustrates another example method 1000B similar to the method 1000A. The method 1000A can be implemented in a RAN node (e.g., BS 104 or CU 172 of the BS 104) of Fig. 5A acting as both the receiving and the last serving base stataion, for example.

[0126] The method 1000B begins at block 1002, where the RAN node configures the UE with suspend configuration and MT-SDT for DRB(s) and / or SRB1 (e.g., event 380, 480 or 580). Atblock 1004, the RAN node receives data / signaling from the CN (e.g., event 310, 410, or 510). The RAN node at block 1006 receives, from a UE, an RRC Resume Request message containing I-RNTI and a cause RNA update (through a DU) (e.g., event 552A-524A). The RAN node at block 1014 transmits, to the UE, the data / signaling (and subsequent DL data / signaling) (through a DU) (e.g., event 530A-532A or 592A). At block 1016, the RAN node detects the end of SDT and decides to send UE back to RRC Inactive. The RAN node at block 1018 generates an RRC Release message including suspendConfig and / or MT-SDT configuration. At block 1020, the RAN node transmits, to the UE, the RRC Release message (through a DU) (e.g., event 546B- 548B).

[0127] Fig. 10C illustrates another example method 1000C similar to the method 1000A or 1000B. The method 1000C can be implemented in a RAN node (e.g., CU 172 of the BS 106 or BS 106) of Fig. 5C acting as a receiving base station, for example.

[0128] The method 1000C begins at block 1006, where the RAN node receives an RRC Resume Request message containing I-RNTI and a cause RNA update (through a DU) (e.g., event 522B). The RAN node at block 1008 transmits, to the last serving base station, a Retrieve UE Context Request message (based on the I-RNTI) and a resume cause RNA update (e.g., event 552). The RAN node at block 1011 receives, from the last serving base station, a Partial UE Context Transfer message including partial RRC Context for SDT and a DL indication (indicating MT-SDT) (e.g., event 555). At block 1013, the RAN node transmits, to the last serving base station, a Partial UE Context Transfer Acknowledge message (e.g., event 557). At block 1012, the RAN node receives data / signaling from the last serving base station (e.g., event 53OB). At block 1014, the RAN node transmits, to the UE, the data / signaling (and subsequent DL data / signaling) (e.g., event 532B or 592C). The RAN node at block 1019 receives, from the last serving base station, a Retrieve UE Context Failure message including an RRC Release message including suspendConfig and / or MT-SDT configuration (e.g., event 550). At block 1020, the RAN node transmits, to the UE, the RRC Release message (through a DU) (e.g., event 546B).

[0129] Fig. 11 A illustrates an example method 1100A for transmitting MT-SDT data to a UE (e.g., UE 102) in response to a Retrieve UE Context Request message with a resume cause RNAupdate. The method 1100 A can be implemented in an RAN node (e.g., CU 172 of the BS 104 or BS 104) of Fig. 5B acting as a last serving base station, for example.

[0130] The method 1100A begins at block 1102, where the RAN node transitions the UE to an inactive state and configures the UE with suspend configuration and MT-SDT for DRB(s) and / or SRB 1 (e.g., event 582). The RAN node at block 1104 receives data / signaling from the CN (e.g., event 510). The RAN node at block 1108 receives, from a base station, a Retrieve UE Context Request message including a UE Context ID (= I-RNTI) and a resume cause RNA update (e.g., event 552). The RAN node at block 1110 transmits, to the base station, a Retrieve UE Context Response message including RRC Context and a DL indication (indicating MT-SDT) (e.g., event 554). The RAN node at block 1112 transmits data / signaling to the base station (e.g., event 53OB).

[0131] Fig. 1 IB illustrates another example method 1100B similar to the method 1100A. The method 1100B can be implemented in an RAN node (e.g., CU 172 of the BS 104 or BS 104) of Fig. 5C acting as a last serving base station, for example.

[0132] The method 1100B begins at block 1102, where the RAN node transitions the UE to an inactive state and configures the UE with suspend configuration and MT-SDT for DRB(s) and / or SRB 1 (e.g., event 582). The RAN node at block 1104 receives data / signaling from the CN (e.g., event 510). The RAN node at block 1108 receives, from a base station, a Retrieve UE Context Request message including a UE Context ID (= I-RNTI) and a resume cause RNA update (e.g., event 552). The RAN node at block 1111 transmits, to the base station, a Partial UE Context Transfer message including a partial RRC Context for SDT and a DL indication (indicating MT- SDT) (e.g., event 555). The RAN node at block 1113 receives, from the base station, a Partial UE Context Transfer Acknowledge message (e.g., event 557). The RAN node at block 1112 transmits data / signaling to the base station (e.g., event 53OB). At block 1115, the RAN node detects the end of SDT and decides to send UE back to RRC Inactive. The RAN node at block 1117 generates an RRC Release message including suspendConfig and / or MT-SDT configuration. At block 1119, the RAN node transmits, to the base station, a Retrieve UE Context Failure message including the RRC Release message (e.g., event 550).

[0133] The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure.

[0134] Example 1. A method for managing transmission from a radio access network (RAN) to a user equipment (UE) operating without an active radio connection with the RAN, the method implemented in a first RAN node and comprising: receiving at least one of downlink data or signaling for the UE currently operating without an active radio connection with the RAN; transmitting, to a second RAN node, a paging message for the UE, the paging message including an indication of the downlink data or signaling; receiving, from a second RAN node, a request to retrieve a context for the UE, the request with a cause value related to the indication of the downlink data or signaling; and transmitting, to the second RAN node, a response to the request, the response including an indication that the downlink data or signaling is available.

[0135] Example 2. The method of example 1, wherein the downlink data or signaling is associated with mobile-terminated small data transmission (MT-SDT).

[0136] Example 3. The method of example 2, wherein the indication of the downlink data or signaling is an MT-SDT indication.

[0137] Example 4. The method of any of the preceding examples, wherein the indication that the downlink data or signaling is available is a DL Forwarding information element (IE) in a Data Forwarding and Offloading Info set to “DL forwarding proposed.”

[0138] Example 5. The method of any of the preceding examples, wherein the indication that the downlink data or signaling is available is a field dedicated exclusively to indicating that MT- SDT data is available.

[0139] Example 6. The method of any of the preceding examples, wherein: the request to retrieve the context is a Retrieve UE Context Request message; and the response to the request is a Retrieve UE Context Response message.

[0140] Example 7. The method of any of the preceding examples, wherein: the request to retrieve the context is a Retrieve UE Context Request message; and the response to the request is a Partial UE Context Transfer message.

[0141] Example 8. A method for downlink transmission to a UE, the method implemented in a RAN node and comprising: receiving, from the UE currently operating with a suspended radio connection with the RAN, a request to resume the radio connection, the request including a resume cause; and when the cause value indicates mobile-terminated transmission of data withthe suspended radio connection, transmitting at least one data packet to the UE while the UE continues to operate with the suspended radio connection.

[0142] Example 9. The method of example 8, wherein the mobile-terminated transmission of data with the suspended radio connection is associated with MT-SDT.

[0143] Example 10. The method of example 8 or 9, wherein the at least one data packet includes an Ethernet packet, an IP packet, or an application packet.

[0144] Example 11. The method of example 8 or 9, wherein the at least one data packet includes a NAS message or an LLP message.

[0145] The following description may be applied to the description above.

[0146] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, a “message” (as the term is used above) can be replaced by “information element (IE),” and vice versa. In some implementations, an “IE” (as the term is used above) can be replaced by “field,” and vice versa. In some implementations, a “configuration” (as the term is used above) can be replaced by “configurations” or “configuration parameters,” and vice versa. In some implementations, “small data transmission” (as the term is used above) can be replaced by “early data transmission (EDT)” (and “SDT” can be replaced by “EDT”), and vice versa. In some implementations, “small data transmission” (as the term is used above) can be replaced by “small data communication,” and vice versa. Unless a more specific meaning is clear from the context of use, “small data transmission,” “SDT,” or “small data communication” may refer to small data transmission / communication in the uplink and / or downlink direction(s).

[0147] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming 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 smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronicsystem such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0148] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code, or machine- readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special -purpose processor, such as a field programmable gate array (FPGA) or an application- specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0149] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more specialpurpose processors.

Claims

What is claimed is:

1. A method implemented in a user equipment (UE), the method comprising: receiving, from a radio access network (RAN) and in an inactive state of a radio connection with the RAN, a paging message including a mobile-terminated small data transmission (MT-SDT) indication; transmitting, to the RAN and subsequent to the paging message, a request to resume the radio connection, the request including a non-SDT cause; and receiving, from the RAN and in response to the request, a command to resume the radio connection.

2. The method of claim 1, wherein the non-SDT cause indicates mobile-originated data (mo-Data).

3. The method of claim 1, wherein the non-SDT cause indicates a RAN notification area update (ma-Update).

4. The method of any of the preceding claims, wherein: the request to resume the radio connection includes an RRCResumeRequest or RRCComectionResumeRequest message.

5. The method of claim 4, wherein: the command to command to resume the radio connection includes an RRCResume or RRCComectionResume message.

6. A method implemented in a radio access network (RAN), the method comprising: transmitting, to a user equipment (UE) operating in an inactive state of a radio connection with the RAN, a paging message including a mobile-terminated small data transmission (MT- SDT) indication;receiving, from the UE and subsequent to the paging message, a request to resume the radio connection, the request including a non-SDT cause; and transmitting, to the UE and in response to the request, a command to resume the radio connection.

7. The method of claim 6, wherein the non-SDT cause indicates mobile-originated data (mo-Data).

8. The method of claim 6, wherein the non-SDT cause indicates a RAN notification area update (ma-Update).

9. The method of any of claims 6-8, wherein: the request to resume the radio connection includes an RRCResumeRequest or RRCConnectionResumeRequest message.

10. The method of claim 9, wherein: the command to command to resume the radio connection includes an RRCResume or RRCConnectionResume message.

11. The method of any of claims 6-10 implemented in a distributed unit (DU) of a distributed base station including the DU and a central unit (CU), the method further comprising: transmitting, to the CU, an uplink (UL) radio resource control (RRC) Message Transfer message including the request to resume the radio connection.

12. The method of claim 11, further comprising: receiving, from the CU in response to the UL RRC Message Transfer, a downlink RRC Message Transfer message including the command to resume the radio connection.

13. The method of any of claims 6-10 implemented in a distributed unit (DU) of a distributed base station including the DU and a central unit (CU), wherein: the MT-SDT indication is a first MT-SDT indication; the method further comprising: receiving, from the CU, a F1AP paging message including a second MT-SDT indication; wherein the transmitting of the paging message to the UE is response to the RAN paging message.

14. The method of any of claims 6-10 implemented in a distributed unit (DU) of a distributed base station including the DU and a central unit (CU), wherein: the MT-SDT indication is a first MT-SDT indication; the method further comprising: receiving, from the CU, a RAN paging message including a second MT-SDT indication; wherein the transmitting of the paging message to the UE is response to the F1AP paging message.

15. A device comprising processing hardware and configured to implement a method of any of the preceding claims.

Images