Managing mobile terminated small data transmissions

Abstract

A user equipment (UE) receives (482, 318) a paging message comprising a Mobile Terminated Small Data Transmission (MT-SDT) indication from a Radio Access Network (RAN) in an inactive state of a radio connection with the RAN; sending (422A), after the paging message, a request to resume the radio connection to the RAN, the request comprising a non-SDT cause; and receiving (466A) a command for resuming the radio connection from the RAN in response to the request.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to Provisional U.S. Patent Application No. 63 / 493,718, filed March 31, 2023, entitled “Managing Mobile-Terminated Small Data Transmission.” The entire contents of that provisional application are hereby expressly incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to wireless communications, and more specifically to downlink data communication at the UE and the distributed unit (DU) using small data transmission (SDT) technology when the user equipment (UE) is operating in an inactive or idle state associated with a protocol for controlling radio resources. Background Technology

[0004] This background description is provided for the purpose of presenting the general context of this disclosure. The work of the currently attributed inventors (to the extent described in this background section) and aspects of the specification that would not have been considered prior art at the time of filing are neither expressly nor impliedly acknowledged as prior art to this disclosure.

[0005] Generally, base stations operating a cellular radio access network (RAN) use a specific radio access technology (RAT) and multiple layers of the protocol stack to communicate with user equipment (UE). For example, the physical layer (PHY) of the RAT provides a transport channel to the media access control (MAC) sublayer, which in turn provides a logical channel to the radio link control (RLC) sublayer, and the RLC sublayer then provides data delivery services to the packet data convergence protocol (PDCP) sublayer. The radio resource control (RRC) sublayer sits above the PDCP sublayer.

[0006] The RRC sublayer specifies: the RRC_IDLE state, in which the UE has no active radio connection with the base station; the RRC_CONNECTED state, in which the UE has an active radio connection with the base station; and the RRC_INACTIVE state, which allows the UE to transition back to the RRC_CONNECTED state more quickly using RAN-level base station coordination and RAN-level paging procedures. In some cases, a UE in the RRC_INACTIVE state may only have a relatively small packet to transmit. For situations like these, the 3GPP has defined a Small Data Transmission (SDT) procedure to allow 5G NR to support data transmission for UEs operating in the RRC_INACTIVE state (i.e., without requiring the UE to transition to the RRC_CONNECTED state).

[0007] The network can enable SDT on a radio bearer basis, and the UE initiates Mobile Originating SDT (MO-SDT) only when less than the configured amount of uplink data awaits transmission on all radio bearers for which SDT is enabled, the downlink reference signal received power (RSRP) is higher than the configured threshold, and effective SDT resources are available. The UE can initiate the MO-SDT procedure using a transmission on the Random Access Channel (RACH) (i.e., Random Access SDT (RA-SDT)) or a transmission on Type 1 Configured Grant (CG) resources (i.e., CG-SDT).

[0008] For RA-SDT, the network configures 2-step and / or 4-step random access resources for SDT. The UE can send the initial transmission of data in the payload of Message 3 (MSG3) of the 4-step random access procedure or Message A (MSGA) of the 2-step random access procedure. Then, after the random access procedure is completed, the network can schedule subsequent uplink and / or downlink transmissions using dynamic uplink granting and downlink assignment, respectively.

[0009] A UE can initiate CG-SDT using only valid uplink (UL) timing alignment. The UE maintains UL timing alignment based on a network-configured SDT-specific timing alignment timer and the DL RSRP of the highest-ranking Synchronization System Block (SSB). After the SDT-specific timing alignment timer expires, the system releases CG resources. After initiating CG-SDT, the UE uses CG to send an initial transmission including data at the CG timing, and the network can schedule subsequent uplink transmissions using dynamic granting or at future CG resource timings. During CG-SDT, the network uses dynamic assignment to schedule downlink transmissions. The UE can only initiate subsequent uplink transmissions after receiving confirmation of the initial transmission from the network.

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

[0011] Additionally, 3GPP proposes extending SDT support to Mobile Termination SDT (MT-SDT). However, the available technologies for MT-SDT often result in inefficiencies. For example, when a base station (such as a gNode B (gNB) or gNB-CU) receives downlink (DL) data or signaling from the core network, the base station attempts to page the UE using an MT-SDT indication or information. When the UE receives a paging message with an MT-SDT indication, in response, the UE can send an RRC recovery request message with an indication of the reason for MT-SDT recovery to the gNB that paged the UE (or via gNB-DU if the gNB is a decomposed base station). The receiving gNB or the last serving gNB then begins forwarding the DL data or signaling to the UE while the UE remains in the RRC_INACTIVE state. However, it is unclear how the receiving gNB or the last serving gNB can support scenarios where the DL data or signaling arrives when the UE is sending or preparing to send, for example, MO-SDT or RAN notification area (RNA) updates. Summary of the Invention

[0012] An example embodiment of the technology disclosed herein is a method implemented in a user equipment (UE). The method includes: receiving from the RAN, while in an inactive state of radio connection with a radio access network (RAN), a paging message including a Mobile Termination Small Data Transmission (MT-SDT) indication; sending to the RAN, after the paging message, a request to restore the radio connection, the request including a non-SDT reason; and receiving from the RAN, in response to the request, a command for restoring the radio connection.

[0013] Another example embodiment of these technologies is a method implemented in a radio access network (RAN). The method includes: sending a paging message to a user equipment (UE) operating in an inactive state with a radio connection to the RAN, including a Mobile Termination Small Data Transmission (MT-SDT) indication; receiving, after the paging message, a request from the UE to restore the radio connection, the request including a non-SDT reason; and, in response to the request, sending a command to the UE to restore the radio connection.

[0014] Another example embodiment of these technologies is an apparatus that includes processing hardware and is configured to implement one of the methods described above. Attached Figure Description

[0015] Figure 1A This is a block diagram of an example system in which the base station and / or user equipment (UE) can implement the techniques disclosed herein for managing small data transmissions between the UE and the radio access network (RAN);

[0016] Figure 1B It is possible Figure 1A A block diagram of an example base station operating in the system, including a central unit (CU) and a distributed unit (DU);

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

[0018] Figure 3A This is a message passing diagram of an example procedure for performing MT-SDT (Mobile Termination SDT) when the radio connection between the UE and the base station is inactive;

[0019] Figure 3B This is another example of a message passing diagram for performing MT-SDT from a new base station when the radio connection between the UE and the base station is inactive;

[0020] Figure 3CThis is another example of a message passing diagram used to perform MT-SDT from a new base station when the radio connection between the UE and the base station is inactive;

[0021] Figure 4A This is a message passing diagram of an example procedure for delivering DL data when the radio connection between the UE and the base station is restored;

[0022] Figure 4B This is another example of a message passing diagram used to perform DL data delivery from a new base station when the radio connection between the UE and the base station is restored;

[0023] Figure 5A This is a message passing diagram of an example procedure for performing MT-SDT in response to a recovery cause of an RNA update when the radio connection between the UE and the base station is inactive;

[0024] Figure 5B This is another example of a message passing process used to perform MT-SDT from a new base station in response to a recovery reason of RNA update when the radio connection between the UE and the base station is inactive;

[0025] Figure 5C This is another example of a message passing process used to perform MT-SDT from a new base station in response to a recovery reason of RNA update when the radio connection between the UE and the base station is inactive;

[0026] Figure 5D This is another example of a message passing process used to perform MT-SDT from a new base station in response to a recovery reason of RNA update when the radio connection between the UE and the base station is inactive;

[0027] Figure 6A This is a flowchart of an example method for sending MT-SDT data to a UE, which can be implemented in a RAN node;

[0028] Figure 6B This is a flowchart of another example method for sending MT-SDT data to a UE, which can be implemented in the RAN node;

[0029] Figure 7 This is a flowchart of an example method for sending MT-SDT data to a UE, which can be implemented in a RAN node;

[0030] Figure 8A This is a flowchart of an example method that can be implemented in the UE to respond to paging messages from the RAN;

[0031] Figure 8BThis is a flowchart of another example method that can be implemented in the UE to respond to paging messages from the RAN;

[0032] Figure 9 This is a flowchart of an example method that can be implemented in the UE to respond to paging messages from the RAN;

[0033] Figure 10A This is a flowchart of an example method that can be implemented in the RAN node to handle RRC recovery request messages and send MT-SDT data to the UE;

[0034] Figure 10B This is a flowchart of another example method that can be implemented in the RAN node to handle RRC recovery request messages and send MT-SDT data to the UE;

[0035] Figure 10C This is a flowchart of yet another example method that can be implemented in the RAN node to handle UE context request messages and send MT-SDT data to the UE via a new RAN node;

[0036] Figure 11A This is a flowchart of an example method that can be implemented in the RAN node to handle RRC recovery request messages and send MT-SDT data to the UE;

[0037] Figure 11B This is a flowchart of yet another example method that can be implemented in the RAN node to handle UE context request messages and send MT-SDT data to the UE via a new RAN node. Detailed Implementation

[0038] Using the techniques discussed in more detail below, UEs and base stations can utilize network resources more efficiently in specific MT-SDT scenarios. In some of these scenarios, for example, the UE sends an RRC recovery request message with a recovery reason other than MT-SDT, which could be, for example, MT-SDT or a non-SDT reason (such as RAN notification area (RNA) update). In some scenarios, the UE moves out of a configured RNA and becomes unable to receive XnAP RAN paging and / or Uu paging messages from gNBs within the RNA.

[0039] To forward DL data or signaling, the receiving base station or the last serving base station may need to send an RRC recovery message to a UE operating in the RRC_INACTIVE state. In response, the UE transitions to the RRC_CONNECTED state and sends an RRC recovery complete message. Therefore, the base station cannot maintain the UE in an inactive state where it would be able to perform SDT according to its configuration. This can lead to less efficient use of radio resources and / or power. For example, to serve a UE operating in the RRC_CONNECTED state, the base station uses more radio resources and consumes more power than it would need to serve a UE operating in the RRC_INACTIVE state. Similarly, a UE operating in the RRC_CONNECTED state consumes more power to communicate with the base station than it would consume in the RRC_INACTIVE state. When the base station sends an RRC recovery message with a recovery reason other than MT-SDT, the receiving base station or the last serving base station may first transition the UE back to RRC_INACTIVE, and then the receiving base station or the last serving base station may use the MT-SDT indication to page the UE to initiate another RRC recovery procedure for MT-SDT. While the UE can continue operating under RRC_INACTIVE, this approach can result in longer delays for buffered DL data or signaling, as well as subsequent DL data or signaling communications. The methods discussed below address these inefficiencies.

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

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

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

[0043] like Figure 1A As shown, base station 104 supports cell 124, and base station 106 supports cell 126. Cells 124 and 126 may partially overlap, allowing UE 102 to select, reselect, or hand over to one of cells 124 and 126. For direct exchange of messages or information, base stations 104 and 106 may support X2 or Xn interfaces. Generally, CN 110 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells.

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

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

[0046] As a more specific example, in some cases, when UE 102 is operating in RRC_INACTIVE or RRC_IDLE state, UE 102 sends data to RAN 105 in the uplink (UL) direction.

[0047] After UE 102 determines that data is available for uplink transmission when operating in RRC_INACTIVE or RRC_IDLE state, UE 102 may apply one or more security functions to UL data packets, generate a first UL Protocol Data Unit (PDU) including the security-protected packets, include the UL RRC message along with the first UL PDU in a second UL PDU, and send the second UL PDU to RAN 105. UE 102 includes its UE identifier / identifier (ID) in the UL RRC message. RAN 105 can identify UE 102 based on the UE ID. In some implementations, the UE ID may be an Inactive Radio Network Temporary Identifier (I-RNTI), a Recovery Identifier, or a Non-Access Stratum (NAS) ID. The NAS ID may be a S-Temporary Mobile Subscriber Identity (S-TMSI) or a Globally Unique Temporary Identifier (GUTI).

[0048] Security features may include integrity protection and / or encryption. When integrity protection is enabled, UE 102 can generate a Message Authentication Code for Integrity (MAC-I) to protect data integrity. Therefore, in this case, UE 102 generates a securely protected packet including data and the MAC-I. When encryption is enabled, UE 102 can encrypt the data to obtain an encrypted packet, such that the securely protected packet includes the encrypted data. When both integrity protection and encryption are enabled, UE 102 can generate a MAC-I to protect data integrity and encrypt the data along with the MAC-I to generate an encrypted packet and an encrypted MAC-I. UE 102 can then send the securely protected packet to RAN 105 while in the RRC_INACTIVE or RRC_IDLE state.

[0049] In some implementations, the data is a UL Service Data Unit (SDU) of Packet Data Convergence Protocol (PDCP) or SDAP. UE 102 applies security functions to the SDU and includes the protected SDU in a first UL PDU (e.g., a ULPDCP PDU). UE 102 then includes the UL PDCP PDU in a second UL PDU (such as a UL MAC PDU), which may be associated with a Media Access Control (MAC) layer. Therefore, in these cases, UE 102 transmits the protected UL PDCP PDU within the UL MAC PDU. In some implementations, UE 102 may include a UL RRC message in the UL MAC PDU. In other implementations, UE 102 may omit the UL RRC message from the UL MAC PDU. In such implementations, UE 102 may omit the UE ID from the UL MAC PDU. In other implementations, UE 102 may include the UL PDCP PDU in the UL Radio Link Control (RLC) PDU, and then include the UL RLC PDU in the UL MAC PDU. In some implementations where the UL MAC PDU includes the UL RRC message, 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 the resumeMAC-I field, as specified in 3GPP specification 38.331. In other implementations, the UE may utilize an integrity key (e.g., K...). RRCint The RRC MAC-I is obtained from the UL RRC message using the key, integrity protection algorithm, and parameters COUNT (e.g., a 32-bit, 64-bit, or 128-bit value), BEARER (e.g., a 5-bit value), and DIRECTION (e.g., a 1-bit value).

[0050] In other implementations, the data is a UL SDU of NAS. UE 102 applies security functions to the SDU and includes the protected SDU in a first UL PDU (such as a NAS PDU) that can be associated with a NAS layer. For example, the NAS layer could be the MM or SM sublayer of 5G, Evolved Packet System (EPS), or 6G. UE 102 can then include the UL NAS PDU in a second UL PDU (such as a UL RRC message). Therefore, in these cases, UE 102 sends the (first) protected UL NAS PDU in the UL RRC message. In some implementations, UE 102 can include the UL RRC message in a UL MAC PDU and send the UL MAC PDU to a base station (e.g., base station 104 or 106) via a cell (e.g., cell 124 or 126). In this case, UE 102 can omit the RRC MAC-I from the UL RRC message. Alternatively, UE 102 can include the RRC MAC-I as described above.

[0051] In some implementations, the UL RRC message described above can be a Common Control Channel (CCCH) message, an RRC Recovery Request message, or an RRC Early Data Request message. The UL RRC message may include the UEID of UE 102 as described above.

[0052] More generally, UE 102 may protect the data using at least one of encryption and integrity protection, including the protected data as a securely protected packet in a first UL PDU, and sending the first UL PDU to RAN 105 in a second UL PDU.

[0053] In some scenarios and implementations, base station 106 can retrieve the UE ID of UE 102 from the UL RRC message and identify base station 104 as the destination of data in the first UL PDU based on the determined UE ID. In this scenario, base station 106 may be referred to as an anchor base station, which puts UE 102 into an inactive state and preserves complete UE context information. In one example implementation, base station 104 retrieves the first UL PDU from the second UL PDU and sends the first UL PDU to base station 106. Base station 106 then retrieves the securely protected packet from the first UL PDU, applies one or two security functions to decrypt the data and / or check integrity protection, and sends the data to CN 110 (e.g., SGW 112, UPF 162, MME 114, or AMF 164) or an edge server. In some implementations, the edge server may operate within RAN 105. More specifically, base station 106 derives at least one security key from the UE context information of UE 102. Then, base station 106 retrieves data from the secure packet using at least one security key and sends the data to CN 110 or the edge server. When the secure packet is encrypted, base station 106 decrypts the encrypted packet using at least one security key (e.g., encryption and / or decryption key) to obtain the data. If the secure packet is integrity-protected, the integrity-protected packet may include data and a MAC-I. Base station 106 can verify the validity of the MAC-I for the secure packet using at least one security key (e.g., integrity key). When base station 106 confirms the MAC-I is valid, base station 106 sends the data to CN 110 or the edge server. On the other hand, when base station 106 determines the MAC-I is invalid, base station 106 discards the secure packet. Additionally, if the secure packet is both encrypted and integrity-protected, the encrypted and integrity-protected packet may include the encrypted packet along with the encrypted MAC-I. In this scenario, base station 106 decrypts the encrypted packet and the encrypted MAC-I to obtain the data and MAC-I. Base station 106 then determines whether the MAC-I is valid for the data. If base station 106 determines the MAC-I is valid, it retrieves the data and forwards it to CN 110 or the edge server. However, if base station 106 determines the MAC-I is invalid, it discards the packet.

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

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

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

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

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

[0059] In some implementations, the base station (i.e., base station 104 or 106) generates downlink control information (DCI) and a cyclic redundancy check (CRC) scrambled using the ID of UE 102 to send a second DL PDU generated by the base station. In some implementations, the ID of 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 sends the DCI and scrambled CRC to UE 102 operating in the RRC_INACTIVE or RRC_IDLE state on the physical downlink control channel (PDCCH). The base station scrambles the CRC using the ID of UE 102. In some implementations, the base station can assign the ID of UE 102 to UE 102 in the random access response sent by the base station during random access with UE 102 before sending the DCI and scrambled CRC. In other implementations, the base station may assign the ID of UE 102 to UE 102 in an RRC message (e.g., an RRC release message or an RRC reconfiguration message) sent by the base station to UE 102 before sending the DCI and scrambled CRC (e.g., when UE 102 was previously operating in the RRC_CONNECTED, RRC_INACTIVE, or RRC_IDLE state).

[0060] UE 102, operating in RRC_INACTIVE or RRC_IDLE state, can receive DCI and scrambled CRC on the PDCCH. Then, UE 102 verifies that the Physical Downlink Shared Channel (PDSCH), including the second DL PDU, is addressed to the UE based on UE 102's ID, DCI, and scrambled CRC. UE 102 can then retrieve data from secure packets. If the secure packet is encrypted, UE 102 can decrypt it using appropriate decryption functions and a security key to obtain the data. If the secure packet is an integrity-protected packet including data and MAC-I, UE 102 can determine if the MAC-I is valid. If UE 102 verifies the MAC-I is valid, UE 102 retrieves the data. However, if UE 102 determines the MAC-I is invalid, UE 102 discards the packet. Finally, when the securely protected packet is both encrypted and integrity protected (with encrypted data and an encrypted MAC-I), UE 102 can decrypt the encrypted packet and the encrypted MAC-I to obtain the data and MAC-I. UE 102 can then verify that the MAC-I is valid for the data. If UE 102 confirms that the MAC-I is valid, UE 102 retrieves and processes the data. Otherwise, if UE 102 determines that the MAC-I is invalid, UE 102 discards the data.

[0061] Base station 104 is equipped with processing hardware 130, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable storage of instructions executed by the one or more general-purpose processors. Additionally or alternatively, processing hardware 130 may include dedicated processing units. In an example implementation, processing hardware 130 includes a Media Access Control (MAC) controller 132 configured to: perform random access procedures with one or more user equipments, receive uplink MAC Protocol Data Units (PDUs) from one or more user equipments, and transmit downlink MAC PDUs to one or more user equipments. Processing hardware 130 may also include a Packet Data Convergence Protocol (PDCP) controller 134 configured to: in some scenarios, transmit DL PDCP PDUs that base station 104 can transmit data in the downlink direction, and in other scenarios, receive UL PDCP PDUs that base station 104 can receive data in the uplink direction. The processing hardware may also include an RRC controller 136 to implement procedures and message passing at the RRC sublayer of the protocol communication stack. In the example implementation, processing hardware 130 includes an RRC inactivity controller 138 configured to manage uplink and / or downlink communication with one or more UEs operating in RRC_INACTIVE or RRC_IDLE states. Base station 106 may include generally similar components. In particular, components 140, 142, 144, 146, and 148 may be similar to components 130, 132, 134, 136, and 138, respectively.

[0062] UE 102 is equipped with processing hardware 150, which may include one or more general-purpose processors (such as a CPU) and a non-transitory computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and / or dedicated processing units. In an example implementation, processing hardware 150 includes an RRC inactivity controller 158 configured to manage uplink and / or downlink communications when UE 102 is operating in an RRC_INACTIVE state. In an example implementation, processing hardware 150 includes a Media 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. Processing hardware 150 may also include a PDCP controller 154 configured to: in some scenarios, transmit DL PDCP PDUs that the base station 106 can transmit data in the downlink direction, and in other scenarios, receive UL PDCP PDUs that the base station 106 can receive data in the uplink direction. The processing hardware may also include an RRC controller 156 to implement process and message passing at the RRC sublayer of the protocol communication stack.

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

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

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

[0066] A CU-CP 172A can connect to multiple CU-UP 172Bs via an E1 interface. The CU-CP 172A selects the appropriate CU-UP 172B for the service requested by UE 102. In some implementations, a single CU-UP 172B can connect to multiple CU-CP 172As via an E1 interface. A CU-CP 172A can connect to one or more DU 174s via an F1-C or W1-C interface. A CU-UP 172B can connect to one or more DU 174s via an F1-U or W1-U interface under the control of the same CU-CP 172A. In some implementations, a DU 174 can connect to multiple CU-UP 172Bs under the control of the same CU-CP 172A. In such implementations, the connection between the CU-UP 172B and the DU 174 is established by the CU-CP 172A using bearer context management functions. A bearer context is an information block in the CU-UP node associated with a UE used for communication via the E1 interface. It may include information about the data radio point bearer associated with the UE, PDU sessions, and QoS flows. This information block contains the necessary information to maintain user plane services for the UE.

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

[0068] In example stack 200, the EUTRA physical layer (PHY) 202A provides a transport channel to the EUTRA MAC sublayer 204A, which in turn provides a logical channel to the EUTRA RLC sublayer 206A. The EUTRA RLC sublayer 206A then provides an RLC channel to the EUTRA PDCP sublayer 208 and, in some cases, to the NR PDCP sublayer 210. Similarly, the NRPHY 202B provides a transport channel to the NR MAC sublayer 204B, which in turn provides a logical channel to the NR RLC sublayer 206B. The NR RLC sublayer 206B then provides data delivery services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data delivery services to the Serving Data Adaptation Protocol (SDAP) 212 or the Radio Resource Control (RRC) sublayer. Figure 2A (Not shown in the image) provides data transfer services. In some implementations, UE 102 supports both EUTRA and NR stacks, such as... Figure 2A As shown, this is to support handover between EUTRA and NR base stations and / or support DC via EUTRA and NR interfaces. Additionally, as shown in Figure 2, UE 102 can support the layering of NR PDCP 210 on EUTRA RLC 206A, and the layering of SDAP sublayer 212 on NR PDCP sublayer 210.

[0069] EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 (e.g., from an Internet Protocol (IP) layer layered directly or indirectly on PDCP layers 208 or 210) receive packets that can be referred to as Service Data Units (SDUs), and (e.g., to RLC layers 206A or 206B) output packets that can be referred to as Protocol Data Units (PDUs). For simplicity, except where the difference between SDU and PDU is relevant, this disclosure refers to both SDU and PDU as "packets".

[0070] On the control plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide signaling radio bearer (SRB) or RRC sublayer ( Figure 2A(Not shown) to exchange, for example, RRC messages or Non-Access Stratum (NAS) messages. On the user plane, EUTRA PDCP sublayer 208 and NR PDCP sublayer 210 can provide DRBs to support data exchange. The data exchanged on NR PDCP sublayer 210 can be SDAP PDUs, Internet Protocol (IP) packets, or Ethernet packets.

[0071] Figures 3A to 3C , Figures 4A to 4B and Figures 5A to 5D This is a message passing diagram illustrating an example scenario in which a UE (e.g., UE 102) and a RAN node (e.g., RAN 105) implement the techniques of this disclosure for uplink and / or downlink small data transmission. Generally speaking, Figures 3A to 3C , Figures 4A to 4B and Figures 5A to 5D Similar events in the text are labeled with similar reference numerals (e.g., ...). Figure 3A Event 302 and Figure 3B and Figure 3C Event 302 in Figure 4A and Figure 4B (Similar to event 402 in the figure), where differences are discussed below where appropriate. Apart from the differences shown in the figures and discussed below, any of the alternative implementations discussed for specific events (e.g., those used for messaging and processing) can be applied to events labeled similarly in other figures.

[0072] First refer to Figure 3A In scenario 300A, UE 102 is paged by BS 104 regarding MT-SDT and performs an RRC connection recovery procedure to receive DL data and / or signaling while remaining inactive. Base station (BS) 104 includes CU 172 and DU 174.

[0073] UE 102 previously operated in a connected or inactive state with base station 104 (302), and then transitioned to or remained in an inactive state. After data inactivity of UE 102 for a (first) specific period, CU 172 of BS 104 can determine that neither BS 104 nor UE 102 transmitted any data in the downlink or uplink direction during the (first) specific period. In response to this determination, CU 172 of BS 104 sends a CU-DU message (e.g., DL RRC messaging message or UE context release command message) carrying a first RRC release message (e.g., RRC Release message or RRC Connection Release message) to DU 174. Then, DU 174 sends a first RRC release message (306) to UE 102 to instruct UE 102 to transition to or remain in an inactive state. Upon receiving the first RRC release message, UE 102 transitions to or remains in an inactive state and operates (308) in the inactive state. In some implementations, the first RRC release message includes suspendConfig, which further includes SDT configuration (e.g., sdt-Config as specified in 3GPP TS 38.331). UE 102 suspends all SRBs and DRBs except SRB0 and broadcast MRBs, as well as multicast MRBs, and applies suspendConfig and SDT configuration and performs the corresponding actions. Events 302, 304, and 306 can be collectively referred to as SDT configuration procedure 380. CU 172 of BS 104 can assign a UE identifier / identifier (ID) (e.g., I-RNTI or recovery ID) to UE 102 and include the assigned value in the first RRC release message. After UE 102 transitions to or remains in an inactive state, in some cases, UE 102 can perform one or more RAN notification area (RNA) updates via DU 174 and CU-CP 172A without a state transition.

[0074] In some implementations, CU-CP 172A may include security parameters (e.g., next-hop chain count) in the first RRC release message. UE 102 uses security parameters to derive security keys (i.e., base key, integrity key, and / or encryption key). For example, UE 102 uses security parameters to derive the base key (e.g., K...). gNB ), and derive the integrity key (e.g., K) from the base key. RRCint Key and / or K UPint Key) and encryption key (e.g., K) RRCenc Key and / or K UPencThe CU-CP 172A derives the security key in a similar manner to UE 102 (i.e., the same security key derived by UE 102). The CU-CP 172A will also derive the integrity key (e.g., K...). UPint Key) and / or encryption key (e.g., K UPenc The integrity key is sent to the CU-UP 172B. The UE 102 and CU-UP 172B will then send the integrity key (e.g., K) to the CU-UP 172B. UPint Key) and / or encryption key (e.g., K UPenc Integrity keys are used for data communication. UE 102 and CU-CP 172A use integrity keys (e.g., K...) RRCint Key) and / or encryption key (e.g., K RRCenc A key is used for communication of the first RRC release message. In the case of a CP-UP split, the CU-CP 172A configures UP encryption and / or integrity protection through a bearer context establishment / modification process, wherein the CU-UP 172B includes a security algorithm and user plane security keys (encryption key and / or integrity protection key). In some implementations, the UP encryption algorithm may require input parameters including a cryptographic key (e.g., 128 bits), a COUNT (e.g., 32 bits), a bearer identifier (e.g., 5 bits), a transmission direction (e.g., 1 bit), and the desired length of the keystream (LENGTH). The keystream can be generated by the encryption algorithm to encrypt plaintext to generate ciphertext and to recover / decrypt the ciphertext back to plaintext.

[0075] At a later time, while UE 102 is operating in an inactive state (308), CN 110 sends DL data and / or signaling of UE 102 to CU 172 of BS 104 (310). CU 172 may check (312) the data size or auxiliary information along with the DL data or signaling to determine whether and how to page UE 102. In some implementations, instead of receiving the DL data packets from CN 110 in event (310), BS 104 (CU 172) generates DL data packets for MT-SDT for UE 102. In response to the DL data, CU 172 of BS 104 sends a (F1AP) paging message with MT-SDT indication or information (314) to DU 174. DU 174 may determine (316) how to page UE 102 based on the received MT-SDT indication or information (316). In response, DU 174 of BS 104 sends one or more (Uu) paging messages (318) to UE 102. DU 174 may include an MT-SDT indication in the paging message (e.g., by adding an MT-SDT indication bit or a paging reason). One or more paging messages arrive at UE 102. Events 312, 314, 316, or 318 may be collectively referred to as MT-SDT paging procedure 382. In response to the paging, UE 102 performs a random access procedure (320A) with DU 174 of BS 104. In some implementations, UE 102 selects access class '0' because the restoration of the RRC connection is triggered in response to an NG-RAN paging. In other implementations, UE 102 selects access class such as '2' or '8' or other access class values ​​provided by the upper layer, and sets the restoration reason accordingly. UE 102 sends a 322A RRC recovery request message (e.g., RRCResumeRequest, RRCConnectionResumeRequest, RRCResumeRequest1, or RRCConnectionResumeRequest1 message) to DU 174. In some implementations, UE 102 includes the recovery reason MT-SDT in the RRC recovery request message. In some implementations, event 322A can be MSG3 or MSGA as previously described for MO-SDT. In some implementations, UE 102 may also include UL data in the UL MAC PDU of the RRC recovery request message in event 322A, and DU 174 buffers the UL MAC PDU. DU 174 sends an initial UL RRC messaging message (324A) to CU 172, including the RRC recovery request message with the recovery reason MT-SDT.In some implementations, based on the recovery reason (i.e., MT-SDT) and buffered DL data and / or signaling, CU 172 decides to keep UE 102 in an inactive state for MT-SDT. CU 172 sends a UE context establishment request message (326A) including a (stored) F1 UL TEID to DU 174 to create a UE context at DU 174. DU 174 responds to CU 172 with a UE context establishment response message (328A) including an F1 DLTEID allocated for the DRB used for SDT or MT-SDT. CU 172 sends DL data and / or signaling from CN110 to DU 174 (330A). In some implementations, CU 172 sends DL signaling to DU 174 in a DL RRC message delivery message. DU 174 sends DL data and / or signaling to UE 102 (332A).

[0076] In some implementations, UE 102 sets the content of the RRC recovery request message as previously described (i.e., sets the recovery reason to SDT or MT-SDT). In response to initiating or sending an RRC recovery request message for an RRC connection recovery procedure, for each radio bearer configured for SDT and for SRB1, UE 102 recovers the RLC-BearerConfig associated with the RLC bearer of masterCellGroup and pdcp-Config from the UE inactive AS context, and reconstructs the PDCP entity for the radio bearers configured for SDT without triggering a PDCP status report. UE 102 recovers all DRBs and SRB1s configured for SDT.

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

[0078] After transmitting DL data and / or signaling 310, 330A, and 332A, CN 110, CU 172, and DU 174 may subsequently perform DL data and / or signaling transmission. CN 110 transmits subsequent DL data and / or signaling 334 to CU 172. CU 172 then transmits subsequent DL data and / or signaling 336 to DU 174. DU 174 then transmits subsequent DL data and / or signaling 338 to UE 102. UE 102 may transmit UL data and / or signaling 340 to DU 174. DU 174 then transmits UL data and / or signaling 342 to CU 172. CU 172 then transmits UL data and / or signaling 344 to CN 110. Events 334, 336, 338, 340, 342, and 344 can be collectively referred to as data / signaling communication procedure 392A. CU 172 may later detect that there is no further activity from the SDT bearer of CN 110 or UE 102. CU 172 sends 346A, a UE context release command message including a second RRC release message. In other implementations, CU 172 sends the second RRC release message in a DL RRC message delivery message. The second RRC release message may include an SDT configuration similar to the first RRC release message. DU 174 sends 348A, the second RRC release message, to UE 102. DU 174 may send a UE context release complete message to CU 172 in response to the UE context release command message. Upon receiving the second RRC release message, UE 102 transitions to or remains in an inactive state, and operates in the inactive state 309. UE 102 suspends all SRBs and DRBs except SRB0 and broadcast MRBs, as well as multicast MRBs, and applies suspendConfig and performs the corresponding action (if the suspendConfig is included in the second RRC release message).

[0079] Now for reference Figure 3B The scenario 300B is related to scenario 300A but covers MT-SDT between base stations because UE102 moves into the coverage area of ​​BS 106. This will be discussed below. Figure 3B Scene 300B and Figure 3A The differences between scenario 300A.

[0080] Initially, BS 104 and UE 102 performed as follows Figure 3AThe SDT configuration procedure 380 is described, and UE 102 transitions to or remains in an inactive state 308. Later, UE 102A moves out of the coverage area of ​​BS 104 and into the coverage area of ​​BS 106. CN 110 subsequently sends 310 DL data and / or signaling to BS 104. BS 104 can check the data size or auxiliary information of 312 DL data or signaling and decide to page UE 102. BS 104 can perform local paging within its coverage area, similar to event 318, and send a 313 RAN paging message to BS 106, which is one of the configured base stations within the RAN. BS 104 can include MT-SDT indications or information in the RAN paging message. BS 106 performs a 383 MT-SDT paging procedure in response to the RAN paging, as follows... Figure 3AAs described. Events 310, 312, 313, and 383 can be collectively referred to as DL data / signaling arrival and MT-SDT paging procedure 384. In response to paging, UE 102 performs a 320B random access procedure with BS 106. In some implementations, UE 102 selects access class '0' because the restoration of the RRC connection is triggered in response to an NG-RAN paging. In other implementations, UE 102 selects access class such as '2' or '8' or other access class values ​​provided by the upper layer, and sets the restoration reason accordingly. UE 102 sends a 322B RRC restoration request message to BS 106, similar to 322A sent to BS 104. In some implementations, UE 102 includes the restoration reason MT-SDT in the RRC restoration request message. In some implementations, event 322B can be MSG3 or MSGA as previously described for MO-SDT. In some implementations, UE 102 may also include UL data in the UL MACPDU of the RRC recovery request message in event 322B. BS 106 sends a 352 Retrieve UE Context Request message to BS 104. In some implementations, BS 106 includes the UE context ID and the RRC recovery reason in the Retrieve UE Context Request message. BS 106 may set the RRC recovery reason to 'MT-SDT'. BS 104 identifies the UE context using the UE context ID and successfully verifies the UE using the integrity protection included in the Retrieve UE Context Request message, and decides to provide the UE context to the new NG-RAN node. In some implementations, based on the recovery reason (i.e., MT-SDT) and buffered DL data and / or signaling, BS 104 decides to relocate the UE context to BS 106. In response, BS 104 sends a Retrieve UE Context Response message including the (complete) RRC context to BS 106. In some implementations, BS 104 may include a DL indication (e.g., a DL forwarding IE set to 'DL forwarding proposed' in the data forwarding and offloading information from the source NG-RAN node IE). In other implementations, the DL indication is a newly defined IE specifically for MT-SDT (e.g., available MT-SDT data). BS 106 sends a 356 Xn-U address indication message to BS 104 to provide delivery data forwarding information, such as the DRB ID and corresponding DL forwarding UP TNL information or PDU session-level DL data forwarding UP TNL information. In some implementations, BS 106 determines whether to send the Xn-U address indication message to BS 104 based on the DL indication received in event 354.In other implementations, BS106, based on the received MT-SDT indication or information, decides to send an Xn-U address indication message to BS104 in event 313. BS104 forwards UP TNL information to BS106 and sends 330B DL data. BS104 uses an RRC delivery message (if any) to send 330B DL signaling to BS106. In some implementations, based on the DL indication and the received DL data and / or signaling, BS106 decides to keep UE102 inactive for MT-SDT. BS106 further sends 332B DL ​​data and / or signaling to UE102. BS106 sends a 358 path handover request message to CN110, and in response, CN110 sends a 360 path handover request confirmation message to BS106. BS 106 sends UE context release message 362 to BS 104, and BS 104 can release the radio and control plane resources of the associated UE context of UE 102. Events 358, 360, and 362 can be collectively referred to as path switching and UE context release procedure 385. CN 110, BS 106, and UE 102 can then execute 392B as shown. Figure 3A The described DL data and / or signaling communication process. BS 106 may later detect that there is no further data or signaling activity on the SDT bearer and determine that UE 102's SDT has ended. BS 106 sends a 346B RRC release message to UE 102, and UE 102 transitions to an inactive state (309). BS 106 can configure suspendConfig and / or sdt-Config in the RRC release message to UE 102, in conjunction with... Figure 3A similar.

[0081] Next reference Figure 3C Scenario 300C is largely similar to Scenario 300B, except that BS 104 maintains the UE context without requiring relocation. This will be discussed below. Figure 3C Scene 300C and Figure 3A Scene 300A and Figure 3B The differences between scenario 300B.

[0082] After receiving the UE Context Retrieval Request message 352 from BS 106, BS 104 may decide to maintain the UE context. In some implementations, based on the recovery reason (i.e., MT-SDT) and the received DL data and / or signaling, BS 104 decides to keep UE 102 inactive for MT-SDT. Instead of sending the UE Context Retrieval Response message 354, BS 104 sends a Partial UE Context Delivery message 355 to BS 106. BS 104 may include DL indications (e.g., data forwarding and offloading information from the source NG-RAN node IE or a specific defined field / IE in the SDT DRB pending list or SDT SRB pending list). BS 106 may infer the presence of MT-SDT data from CN 110 and buffered at BS 104 via the RAN paging message in event 384 or the DL indication in event 355. In response, BS 106 sends a Partial UE Context Delivery Confirmation message to BS 104 and provides SDT data forwarding information. BS 104 sends 330B DL data (e.g., based on data forwarding information) and / or signaling (e.g., transmitting messages via RRC) to BS 106. BS 106 further sends 332B DL ​​data and / or signaling to UE 102. CN 110, BS 104, BS 106, and UE 102 may perform subsequent data or signaling communications. CN 110 sends 334 DL data and / or signaling to BS 104. BS 104 further sends 337 DL data and / or signaling to BS 106. BS 106 further sends 338C DL data and / or signaling to BS 104. UE 102 sends 340C UL data and / or signaling to BS 106. BS 106 further sends 343 UL data and / or signaling to BS 104. BS 104 further sends UL data and / or signaling to CN 110. Events 334, 337, 338C, 340C, 343, and 344 can be collectively referred to as data / signaling communication procedure 392C.

[0083] BS 104 may later detect that there is no further data or signaling activity on the SDT bearer and determine that UE 102's SDT has ended. BS 104 generates an RRC release message and sends a 350 UE context retrieval failure message including the RRC release message to BS 106. BS 106 sends a 346B RRC release message to UE 102, and UE 102 transitions to or remains in an inactive state. BS 104 can configure suspendConfig and / or sdt-Config in the RRC release message to UE 102, with... Figure 3A similar.

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

[0085] Next reference Figure 4A Scenario 400A is similar to scenarios 300A, 300B, and 300C, but UE 102 uses a non-SDT reason to initiate RRC recovery. Events in this scenario that are similar to those discussed above are marked with similar reference numerals as in the attached diagram. Figures 3A to 3C Examples and implementations can be applied to Figure 4A (For example, event 302 is similar to event 402, event 307 is similar to event 407, and event 380 is similar to event 480). This will be discussed below. Figure 4A Scene 400A and Figure 3A Scene 300A, Figure 3B Scene 300B and Figure 3C The differences between the 300C scenarios.

[0086] CU 172 and DU 174 of BS 104 and UE 102 initially execute an SDT configuration procedure 480 similar to event 380. UE 102 transitions to an inactive state 408. CN 110 later sends DL data and / or signaling 410 to CU 172 of BS 104. CU 172 and DU 174 of BS 104 and UE 102 execute an MT-SDT paging procedure 482 for the DL data and / or signaling. UE 102 executes a random access procedure 420A with DU 174. Unlike scenarios 300A to 300C, UE 102 may initiate a random access procedure not in response to the paging procedure in event 482, but due to other triggering reasons (e.g., when an upper layer or AS (after triggering an RNA update when the UE is in RRC_INACTIVE, for NR sidelink communication / discovery / V2X sidelink communication, etc.) requests the resumption of a suspended RRC connection). Therefore, UE 102 sends a 422A RRC recovery request message (e.g., RRCResumeRequest, RRCConnectionResumeRequest, RRCResumeRequest1, or RRCConnectionResumeRequest1 message) to DU 174, the RRC recovery request message including a non-SDT reason (e.g., emergency, highPriorityAccess, mt-Access, mo-Signalling, mo-Data, mo-VoiceCall, mo-VideoCall, mo-SMS, rna-Update, mps-PriorityAccess, mcs-PriorityAccess, etc.). DU 174 sends an initial UL RRC message delivery message (424A) including the RRC recovery request message to CU 172. In some implementations, based on the recovery reason (i.e., non-SDT) and buffered DL data and / or signaling, CU 172 decides to transition UE 102 to a connected state to send DL data and / or signaling. CU 172 sends a 426A UE context establishment request message to DU 174, and in response, DU 174 sends a 428A UE context establishment response message to CU 172. DU 174 establishes a UE context, which specifically includes the SRB, DRB, BH RLC channel, Uu trunk RLC channel, PC5 trunk RLC channel, and SL DRB configuration. Therefore, the complete UE context is not only established for the DRB or SRB configured for SDT.In event 428A, CU 172 generates an RRC recovery message (e.g., an RRCResume or RRCConnectionResume message) based on the received information, and CU 172 sends a 464A DL RRC message delivery message including the RRC recovery message to DU 174. DU 174 sends a 466A RRC recovery message to UE 102. UE 102 accordingly transitions to the connected state at 407. UE 102 sends a 468A RRC recovery complete message to DU 174. DU 174 sends a 470A UL RRC message delivery message including the RRC recovery complete message to CU 172. CU 172 then begins sending 430A DL data and / or signaling to DU 174. DU 174 sends 432A DL data and / or signaling to UE 102. CN 110, CU 172, DU 174 and UE 102 can perform a similar subsequent data communication procedure as 492A.

[0087] In some implementations, UE 102 sets the recovery reason for the RRC recovery request message to non-SDT, as previously described. In response to initiating or sending an RRC recovery request message for an RRC connection recovery procedure, for each radio bearer configured for SDT and for SRB1, UE 102 avoids recovering the RLC-BearerConfig associated with the RLC bearer of masterCellGroup and pdcp-Config from the UE inactive AS context, and rebuilds the PDCP entity for radio bearers configured for SDT without triggering a PDCP status report. UE 102 avoids recovering all DRBs and SRB1 configured for both SDT and non-SDT.

[0088] Next reference Figure 4B Scenario 400B is similar to scenarios 400A, 300A, 300B, and 300C, but BS 106 (i.e., the receiving base station) decides to transition UE 102 to a connected state to receive DL data and / or signaling after retrieving the UE context. This is discussed below. Figure 4B Scene 400B and Figure 4A Scene 400A, Figure 3A Scene 300A, Figure 3B Scene 300B and Figure 3C The differences between the 300C scenarios.

[0089] In scenario 400B, CN 110, BS 104, BS 106, and UE 102 can perform DL data / signaling arrival and MT-SDT paging procedure 484. In some implementations, BS 106 may be located outside the configured RAN, making RAN paging messages from BS 104 unreachable. In this case, BS 106 does not paging UE 102 for MT-SDT. Unlike scenario 300B, UE 102 initiates a random access procedure with BS 106 and sends a 422B RRC recovery request message with a non-SDT reason to BS 106. BS 106 sends a 452 UE context retrieval request message with a non-SDT reason to BS 104, similar to event 352. BS 104 decides to relocate the UE context and sends a 454 UE context retrieval response message to BS 106, similar to event 354. BS 106 sends a 456 Xn-U address indication message to BS 104, similar to event 356. BS 106 decides not to keep UE 102 in an inactive state, but instead transitions UE 102 to a connected state to receive DL data and / or signaling. BS 106 sends a 466B RRC recovery message to UE 102. UE 102 transitions to the connected state (407) and sends a 468 BRRC recovery complete message to BS 106. BS 104 forwards 430B DL data and / or signaling to BS 106, and BS 106 sends DL data and / or signaling to UE 102. BS 106, BS 104, and CN 110 perform path switching and UE context release procedure (485). CN 110, BS 106, BS 104, and UE 102 can then perform subsequent data / signaling communication procedure (492B).

[0090] In some implementations, UE 102 sets the recovery reason for the RRC recovery request message to non-SDT, as previously described. In response to initiating or sending an RRC recovery request message for an RRC connection recovery procedure, for each radio bearer configured for SDT and for SRB1, UE 102 avoids recovering the RLC-BearerConfig associated with the RLC bearer of masterCellGroup and pdcp-Config from the UE inactive AS context, and rebuilds the PDCP entity for radio bearers configured for SDT without triggering a PDCP status report. UE 102 avoids recovering all DRBs and SRB1 configured for both SDT and non-SDT.

[0091] Next reference Figure 5AScenario 500A is similar to scenarios 300A to 300C and 400A to 400B, but here, UE 102 uses the recovery reason "RNA update" to initiate RRC recovery. Events in this scenario similar to those discussed above are marked with similar reference numerals, and... Figures 3A to 3C or Figures 4A to 4B Examples and implementations can be applied to Figure 5A (For example, event 580 is similar to event 380 or 480). The differences between scenario 500A and scenarios 300A to 300C and 400A to 400B are discussed below.

[0092] When UE 102 is configured with SDT through SDT configuration procedure 580 and operates in inactive state 508, CN110 sends 510 DL data and / or signaling to CU 172. DU 174 can receive 514 F1AP paging message including MT-SDT indication and / or information for CU 172. In some implementations or scenarios, UE 102 can perform 520A random access procedure with DU 174 before DU 174 can page it. UE 102 sends 522A to DU 174 with recovery reason "RNA update" (or other non-SDT reason, such as...) Figure 4A or Figure 4BThe described RRC recovery request message. RNA updates can be triggered when UE 102 moves out of the configured RNA or periodically. DU 174 sends an initial ULRRC message delivery message to CU 172, including the RRC recovery request message. In some implementations, CU 172 determines whether to keep the UE inactive based on buffered DL data and / or signaling and the recovery reason. CU 172 sends a 526A UE context establishment request message to DU 174, and in response, DU 174 sends a 528A UE context establishment response message to CU 172. CU 172 sends a 530A DL data and / or signaling to DU 174. When the UE is operating in an inactive state, DU 174 sends a 532A DL data and / or signaling to UE 102. CN 110, CU 172, DU 174, and UE 102 can perform subsequent data / signaling communication procedure 592A. CU 172 may later detect the lack of further data activity and determine that UE 102's SDT has ended. CU 172 sends a UE context release command message (546A) including an RRC release message to DU 174. DU 174 sends an RRC release message (548A) to UE 102. UE 102 transitions to an inactive state (509) and applies suspendConfig and / or sdt-Config (if included). Therefore, although UE 102 does not include the MT-SDT resumption reason in the RRC resumption request message, the UE can remain inactive.

[0093] In some implementations, in response to an RRC recovery request message that includes a RAN update recovery reason (or other non-SDT reason) for initiating or sending an RRC connection recovery procedure, UE 102 recovers the RLC-BearerConfig associated with the RLC bearer of masterCellGroup and pdcp-Config from the UE inactive AS context for each radio bearer configured for SDT and for SRB1. UE 102 recovers all radio bearers configured for SDT.

[0094] Next reference Figure 5B Scenario 500B is similar to Scenario 500A in that UE 102 uses an RNA update reason to initiate RRC recovery. Events in this scenario that are similar to those discussed above are marked with similar reference numerals as shown in the attached diagram. Figures 3A to 3C , Figures 4A to 4B or Figure 5A Examples and implementations can be applied to Figure 5B(For example, event 522B is similar to events 322A, 422A, or 522A). The differences between scenario 500B and scenarios 300A to 300C, 400A to 400B, and 500A are discussed below.

[0095] When UE 102 is configured with SDT via SDT configuration procedure 580 and is operating in inactive state 508, CN110 sends DL data and / or signaling to BS 104. If BS 106 is within the configured RNA of BS 104, BS 106 can receive RAN paging message 513 including MT-SDT indication and / or information for BS 104. In some implementations or situations, UE 102 can perform random access procedure 520B with BS 106 before BS 106 can page it. UE 102 sends RRC recovery request message 522B with recovery reason "RNA update" (or another non-SDT recovery reason) to BS 106. RNA update can be triggered when UE 102 moves out of the configured RNA (i.e., BS 106 is outside the configured RNA) or periodically. BS 106 sends a 552 Request for Retrieve UE Context message to BS 104, including the RRC recovery reason "RAN Update". BS 104 determines the UE context to be relocated and sends a 554 Request for Retrieve UE Context response message to BS 106. In some implementations, BS 104 determines to relocate the UE context to BS 104 based on buffered DL data and / or signaling and recovery reason and / or whether BS 106 is outside the configured RNA. In some implementations, the Request for Retrieve UE Context response message in event 554 includes a DL indication. Figure 3B or Figure 4B Similarly, BS 106 sends an Xn address indication message to BS 104. BS 104 sends 530B DL data and / or signaling (e.g., via RRC message delivery) to BS 106. BS 106 avoids transitioning UE 102 to a connected state and sends 532B DL ​​data and / or signaling to UE 102. BS 106, BS 104, and CN 110 perform path switching and UE context release procedure 585. CN 110, BS 106, and UE 102 may perform subsequent data / signaling communication procedure 592B. BS 106 later detects that UE 102 has no further data activity and sends 546B RRC release message to UE 102. UE 102 transitions to an inactive state 509 and applies suspendConfig and sdt-Config (if included).

[0096] Next reference Figure 5CScenario 500C is similar to scenarios 500B or 500A in that UE 102 uses an RNA update reason to initiate RRC recovery. Events in this scenario that are similar to those discussed above are marked with similar reference numerals, and... Figures 3A to 3C , Figures 4A to 4B or Figures 5A to 5B Examples and implementations can be applied to Figure 5C The following section discusses the differences between scenario 500C and scenarios 300A to 300C, 400A to 400B, and 500A to 500B.

[0097] After receiving a UE context retrieval request message (552) from BS 106, which includes the RRC recovery reason "RNA update" (or another non-SDT recovery reason), BS 104 decides to maintain the UE context and keep UE 102 in an inactive state. In some implementations, BS 104 makes this decision based on received DL data (e.g., data size) and / or signaling (e.g., auxiliary information) and the recovery reason and / or that BS 104 has already configured SDT at UE 102. In some implementations, BS 104 receives the UE context retrieval request message from BS 106 before it may have already sent a RAN paging message (513) for UE 102. BS 104 sends a partial UE context delivery message (555) to BS 106. In some implementations, the partial UE context delivery message includes a DL indication (e.g., data forwarding and offloading information from the source NG-RAN node IE in the SDT DRB / SRB Be Setup Item, or a specific MT-SDT indication). In response, BS 106 sends a 557 partial UE context delivery confirmation message to BS 104. BS 104 then sends a 530B DL data and / or signaling message (e.g., via RRC delivery) to BS 106. BS 106 sends a 532B DL ​​data and / or signaling message to UE 102. CN 110, BS 104, BS 106, and UE 102 can then perform subsequent data / signaling communication procedure 592C. BS 104 later detects that UE 102 has no further data activity and decides to transition UE 102 to an inactive state. Unlike MO-SDT, the detection of the end of SDT is completed at the receiving BS (i.e., BS 106), and the receiving BS may need to send a retrieve UE context confirmation message to the last serving BS (i.e., BS 104) to indicate the end of SDT or data inactivity. BS 104 sends a 550 UE context retrieval failure message, including an RRC release message, to BS 106. BS 106 sends a 546B RRC release message to UE 102. UE 102, in response to receiving the RRC release message, transitions to or remains in an inactive state. In some implementations, the RRC release message includes suspendConfig and / or sdt-Config, and UE 102 applies suspendConfig and / or sdt-Config.

[0098] Next reference Figure 5DThe similarity between scenario 500D and scenarios 500A to 500C is that UE 102 uses an RNA update reason to initiate RRC recovery. The differences between scenario 500C and scenarios 300A to 300C, 400A to 400B, and 500A to 500C are discussed below.

[0099] After receiving a Retrieve UE Context Request message (552) from BS 106, which includes the RRC recovery reason "RNA Update" (or another non-SDT recovery reason), BS 104 decides to preserve the UE context and keep UE 102 inactive. In some implementations, BS 104 makes this decision based on received DL data (e.g., data size) and / or signaling (e.g., auxiliary information) and the recovery reason and / or that BS 104 has already configured SDT at UE 102. In some implementations, BS 104 receives the Retrieve UE Context Request message from BS 106 before it may have already sent a RAN paging message (513) for UE 102. BS 104 sends a Retrieve UE Context Failure message (550) to BS 106, which includes an RRC release message for UE 102. BS 106 sends an RRC release message (546B) to UE 102. UE 102 transitions to or remains in an inactive state 509 and applies suspendConfig and / or sdt-Config (if included in the RRC release message). BS 104 may send a (second) RAN paging message 570 to BS 106 after event 550, including MT-SDT indication or information. In response, BS 106 performs paging procedure 583 with UE 102. Then, CN 110, BS 104, BS 106, and UE 102 perform MT-SDT procedure 586 without UE context relocation, as... Figure 3C The described event 386 is similar. Compared to scenario 300C, scenario 500D has an additional step to return UE 102 to an inactive state in response to an RRC recovery process with a recovery reason "RNA update" (or another non-SDT reason). UE 102 is able to remain in the inactive state to perform SDT data communication, but in event 510, the initial DL data and / or signaling from CN 110 experiences a much longer delay than in scenario 300C.

[0100] Next, refer to Figures 6A to 7 and Figures 10A to 11B Several example methods are discussed that can be implemented in one or more base stations, DUs, CUs, or otherwise in the RAN to support MT-SDT with the UE in an inactive state. Additionally, see references... Figures 8A to 9 Several example methods that can be implemented in one or more UEs that are inactive with the RAN are discussed.

[0101] Figure 6A An example method 600A is shown for sending DL data to a UE (e.g., UE 102) and transitioning the UE to an inactive or connected state based on the recovery reason in the RRC recovery request message to send DL data. For example, method 600A can... Figures 3A to 3C , Figures 4A to 4B , Figures 5A to 5D It is implemented in the first RAN node (e.g., CU172 of BS 104, BS 104, or BS 106).

[0102] Method 600A begins at block 602, where the first RAN node notifies the UE to initiate MT-SDT (e.g., event 314, 382, ​​482, or 514). At block 604, the first RAN node receives an RRC recovery request message from the UE including a recovery reason (e.g., event 322A, 322B, 422A, 422B, 522A, or 522B). At block 606, the first RAN node determines whether the recovery reason is an MT-SDT reason. If the recovery reason is set to an MT-SDT reason at block 606, the process proceeds to block 608, where the first RAN node sends at least one DL data packet to the UE without transitioning the UE to a connected state (e.g., events 330A to 332A, 392A, 392B, or 332B). Otherwise, if at box 606 the recovery reason is not an MT-SDT reason (i.e., the recovery reason is a non-SDT reason), the process proceeds to box 610, where the first RAN node transitions the UE to a connected state (e.g., events 464A to 466A or 466B). At box 612, the first RAN node sends at least one DL data packet to the UE operating in the connected state (e.g., events 430A to 432A or 432B).

[0103] In some implementations, a first RAN node (e.g., a base station) transmits a paging message (e.g., an RRC paging message) on one or more cells, including the UE ID (e.g., an I-RNTI or a complete RNTI) and a first MT-SDT indication for the UE, to notify the UE to initiate MT-SDT. The UE ID addresses the UE, and the first MT-SDT indication indicates that the paging message is for paging the UE for MT-SDT. In other implementations, a first RAN node (e.g., a CU or CU-CP) transmits a CU-DU message (e.g., an F1AP paging message) to each of one or more DUs, causing each DU to transmit a paging message (e.g., an RRC paging message) on one or more cells of each DU. Each CU-DU message includes the UE ID and a second MT-SDT indication. In response to receiving a corresponding CU-DU message, each DU generates a corresponding paging message (e.g., an RRC paging message) including the UE ID and the first MT-SDT indication, and transmits the corresponding paging message on one or more cells operated by each DU. The second MT-SDT instruction instructs each DU to include the first MT-SDT instruction in the corresponding paging message.

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

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

[0106] Figure 6BAnother example method 600B, similar to method 600A, is shown, except that method 600B includes blocks 605 and 607 instead of blocks 604 and 606. At block 605, the first RAN node receives a UE context retrieval request message (e.g., event 352, 452, or 552) from the second RAN node. At block 607, the first RAN node determines whether the UE context retrieval request message includes an MT-SDT reason. If, at block 607, the UE context retrieval request message includes an MT-SDT reason, the process proceeds to block 608. Otherwise, if, at block 607, the UE context retrieval request message does not include a recovery reason or includes a recovery reason other than an MT-SDT reason, the process proceeds to block 610.

[0107] In some implementations, the MT-SDT reason in the UE context request message is retrieved as an RRC recovery reason IE / field with the value 'SDT' or 'MT-SDT'. In other implementations, the MT-SDT reason in the UE context request message is retrieved as an SDT support request IE / field with an SDT indicator or MT-SDT indicator.

[0108] Figure 7 An example method 700 is illustrated, in which the first RAN node determines whether to pass part or all of the UE context to the second RAN node, depending on whether the MT-SDT reason is included in the UE context retrieval request message received from the second RAN node. For example, method 700A can... Figures 3A to 3C , Figures 4A to 4B , Figures 5A to 5D It is implemented in the RAN node (e.g., CU 172, BS 104, or BS 106 of BS 104). Method 700 is similar to method 600B, wherein boxes 702, 704, and 706 are the same as boxes 602, 605, and 607, respectively.

[0109] If, at box 706, the UE context request message includes an MT-SDT reason, the process proceeds to box 708, where the first RAN node sends a partial UE context delivery message (e.g., event 355) to the second RAN node in response to the UE context request message. Otherwise, if, at box 706, the UE context request message does not include a recovery reason or includes a recovery reason other than an MT-SDT reason, the process proceeds to box 710, where the first RAN node sends a UE context response message (e.g., event 454 or 554) to the second RAN node in response to the UE context request message.

[0110] In some implementations, the MT-SDT reason in the UE context request message is retrieved as an RRC recovery reason IE / field with the value 'SDT' or 'MT-SDT'. In other implementations, the MT-SDT reason in the UE context request message is retrieved as an SDT support request IE / field with an SDT indicator or MT-SDT indicator. In some implementations, a partial UE context delivery message includes a partial UE context information IE for SDT, which contains UE context information for NR SDT, as defined in 3GPP TS 38.423, and the partial UE context delivery message includes a DL indicator.

[0111] In some implementations, the first RAN node sends 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 of method 600A.

[0112] Figure 8A An example method 800A is shown for a UE (e.g., UE 102) to respond to a paging message and set a corresponding recovery reason. For example, method 800A can... Figures 3A to 3C , Figures 4A to 4B , Figures 5A to 5D Implemented in the UE.

[0113] Method 800A begins at box 802, where the UE receives a paging message for the UE from the RAN (e.g., events 318, 383, 482, 484, or 583). At box 804, the UE determines whether the paging message includes an MT-SDT indication for the UE. If, at box 804, the paging message includes an MT-SDT indication for the UE, the procedure proceeds to box 806, where the UE sets the recovery cause (value) to the MT-SDT cause. Otherwise, if, at box 804, the paging message does not include an MT-SDT indication for the UE, the procedure proceeds to box 808, where the UE sets the recovery cause (value) based on the access identifier. The procedure then proceeds from boxes 808 and 806 to box 810. At box 810, the UE sends an RRC recovery request message to the RAN, including the recovery cause (e.g., events 322A, 322B, 422A, 422B, 522A, or 522B).

[0114] In some implementations, the paging message includes the UE's first paging record. The first paging record includes the UE's UEID (e.g., I-RNTI or full RNTI) and an MT-SDT indication. In other words, the RAN uses the first paging record for the MT-SDT to page the UE. In some implementations, the paging message may include a second paging record for the attached UE. The second paging record includes the attached UE's UEID and does not include the MT-SDT indication. In other words, the RAN does not use the second paging record for the MT-SDT to page the attached UE.

[0115] In some implementations, if the UE is configured for Multimedia Priority Service (MPS), the UE determines the access identifier to be 1. In this case, the UE sets the recovery reason to mps-PriorityAccess, indicating MPS priority access. In another example, if the UE is configured for Mission Critical Service (MCS), the UE determines the access identifier to be 2. In this case, the UE sets the recovery reason to mcs-PriorityAccess, indicating MCS priority access. In yet another example, if the UE has a Universal Subscriber Identity Module (USIM) that includes an access class with a value of N, the UE determines the access identifier to be N, where N is 11, 12, 13, 14, or 15. In this case, the UE sets the recovery reason to highPriorityAccess, indicating high-priority access. If the access identifier is a value other than 1, 2, 11, 12, 13, 14, or 15, the UE sets the recovery reason to mt-Access, indicating mobile termination access.

[0116] Figure 8B An example method 800B, similar to method 800A, is shown, except that method 800B includes box 805. If, at box 804, the paging message includes an MT-SDT indication for the UE, the process proceeds to box 805, where the UE determines whether one or more conditions of the MT-SDT are met. If, at box 805, one or more conditions of the MT-SDT are met, the process proceeds to box 806. Otherwise, if one or more conditions of the MT-SDT are not met, the process proceeds to box 808.

[0117] One or more conditions may include, for example, determining that the UE has received a System Information Block (SIB) broadcast by the RAN on the serving cell where the UE is camped, wherein the SIB indicates that SDT is permitted. For example, the SIB is SIB1, and SIB1 includes the SDT-ConfigCommon IE.

[0118] Additionally, one or more conditions may include determining that the UE has received SDT configuration (e.g., SDT-ConfigIE) from the RAN.

[0119] Furthermore, one or more conditions may include determining that the UE has obtained a DL signal strength above a certain threshold on the serving cell. For example, the DL signal strength is expressed in Reference Signal Received Power (RSRP). In some implementations, the RAN includes the threshold in the SIB (e.g., SIB1 or SDT-ConfigCommon IE). In some implementations, the UE obtains the DL signal strength from the DL path loss reference (signal).

[0120] Figure 9 An example method 900 is shown for a UE (e.g., UE 102) to respond to an incoming paging message and initiate an RRC connection restoration procedure. For example, method 800A can be used... Figures 3A to 3C , Figures 4A to 4B , Figures 5A to 5D Implemented in the UE.

[0121] Method 900 begins at block 902, where the UE receives from the RAN a first RRC release message configuring the UE to transition to an inactive state and configure SDT (e.g., events 304 to 306, 380, 480, 580). At block 904, the UE transitions to or remains in an inactive state in response to the first RRC release message (e.g., events 308, 408, 508). At block 906, the UE receives a paging message from the RAN (e.g., events 318, 383, 482). At block 908, the UE initiates an RRC connection restoration procedure (in response to the paging message) (e.g., events 322A, 322B, 422A, 422B, 522A, 522B). At block 910, in response to initiating an RRC connection restoration procedure or sending an RRC restoration request message for an RRC connection restoration procedure, the UE applies an RLC bearer configuration and PDCP configuration for each of at least one radio bearer configured for SDT and / or SRB1. At block 912, after applying the RLC bearer configuration and PDCP configuration, the UE receives DL data / signaling from the RAN via at least one radio bearer configured for SDT and / or SRB1. At block 914, the UE may, after applying the RLC bearer configuration and PDCP configuration or receiving DL data / signaling, send UL data / signaling to the RAN via at least one radio bearer configured for SDT and / or SRB1 (e.g., events 322A, 392A, 322B, 392B, 392C, 592A, 592B, 592C). At block 916, the UE may receive a second RRC release message from the RAN that transitions the UE to an inactive or idle state (e.g., events 348A, 346B, 548A, 546B). The UE transitions to an inactive or idle state in response to receiving the second RRC release message.

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

[0123] In some implementations, in response to initiating an RRC connection recovery procedure or sending an RRC recovery request message for an RRC connection recovery procedure, the UE recovers at least one suspended radio bearer configured for SDT and / or SRB1.

[0124] Figure 10A An example method 1000A is shown for sending MT-SDT data to a UE (e.g., UE102) in response to an RRC recovery request message with a cause RNA update. For example, method 1000A can... Figure 5BIt is implemented in the RAN node that acts as the receiving base station (e.g., CU 172 of BS 106, or BS 106).

[0125] Method 1000A begins at block 1006, where the RAN node (via DU) receives an RRC recovery request message containing an I-RNTI and a cause RNA update (e.g., event 522B). At block 1008, the RAN node sends a retrieve UE context request message (based on the I-RNTI) and a recovery cause RNA update to the last serving base station (e.g., event 552). At block 1010, the RAN node receives a retrieve UE context response message from the last serving base station, including the 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 sends data / signaling (and subsequent DL data / signaling) to the UE (e.g., events 532B or 592B). At block 1016, the RAN node detects the end of the SDT and decides to send the UE back to RRC inactivity. At box 1018, the RAN node generates an RRC release message including suspendConfig and / or MT-SDT configuration. At box 1020, the RAN node (via DU) sends an RRC release message to the UE (e.g., event 546B).

[0126] Figure 10B Another example method 1000B, similar to method 1000A, is shown. For example, method 1000A can... Figure 5A It is implemented in the RAN node that acts as both the receiving base station and the last serving base station (e.g., BS 104, or CU172 of BS 104).

[0127] Method 1000B begins at block 1002, where the RAN node configures the UE with a suspend configuration and MT-SDT for DRB and / or SRB1 (e.g., events 380, 480, or 580). At block 1004, the RAN node receives data / signaling from the CN (e.g., events 310, 410, or 510). At block 1006, the RAN node (via DU) receives an RRC recovery request message from the UE containing an I-RNTI and a cause RNA update (e.g., events 552A to 524A). At block 1014, the RAN node (via DU) sends data / signaling (and subsequent DL data / signaling) to the UE (e.g., events 530A to 532A or 592A). At block 1016, the RAN node detects the end of the SDT and decides to send the UE back to RRC inactivity. At block 1018, the RAN node generates an RRC release message including the suspendConfig and / or MT-SDT configuration. At box 1020, the RAN node (via DU) sends an RRC release message to the UE (e.g., events 546B to 548B).

[0128] Figure 10C Another example method, 1000C, similar to methods 1000A or 1000B, is shown. For example, method 1000C can... Figure 5C It is implemented in the RAN node that acts as the receiving base station (e.g., CU 172 of BS 106, or BS 106).

[0129] Method 1000C begins at block 1006, where the RAN node (via DU) receives an RRC recovery request message containing an I-RNTI and a cause RNA update (e.g., event 522B). At block 1008, the RAN node sends a retrieve UE context request message (based on I-RNTI) and a recovery cause RNA update to the last serving base station (e.g., event 552). At block 1011, the RAN node receives a partial UE context delivery message from the last serving base station, including a portion of the RRC context for SDT and a DL indication (indicating MT-SDT) (e.g., event 555). At block 1013, the RAN node sends a partial UE context delivery confirmation message to the last serving base station (e.g., event 557). 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 sends data / signaling (and subsequent DL data / signaling) to the UE (e.g., events 532B or 592C). At box 1019, the RAN node receives a UE context retrieval failure message from the last serving base station, which includes an RRC release message comprising suspendConfig and / or MT-SDT configuration (e.g., event 550). At box 1020, the RAN node sends an RRC release message to the UE (e.g., event 546B) via the DU.

[0130] Figure 11A An example method 1100A is shown for sending MT-SDT data to a UE (e.g., UE 102) in response to a retrieval UE context request message with a recovery cause RNA update. For example, method 1100A can... Figure 5B This is implemented in the RAN node that acts as the last serving base station (e.g., CU 172 of BS 104, or BS 104).

[0131] Method 1100A begins at block 1102, where the RAN node transitions the UE to an inactive state and configures the UE with a pause configuration for DRB and / or SRB1 and MT-SDT (e.g., event 582). At block 1104, the RAN node receives data / signaling from the CN (e.g., event 510). At block 1108, the RAN node receives a Retrieve UE Context Request message from the base station including the UE Context ID (= I-RNTI) and the recovery reason RNA update (e.g., event 552). At block 1110, the RAN node sends a Retrieve UE Context Response message to the base station including the RRC context and DL indication (indicating MT-SDT) (e.g., event 554). At block 1112, the RAN node sends data / signaling to the base station (e.g., event 530B).

[0132] Figure 11B Another example method 1100B, similar to method 1100A, is shown. For example, method 1100B can be... Figure 5C This is implemented in the RAN node that acts as the last serving base station (e.g., CU 172 of BS 104, or BS 104).

[0133] Method 1100B begins at block 1102, where the RAN node transitions the UE to an inactive state and configures the UE with a pause configuration for DRB and / or SRB1 and MT-SDT (e.g., event 582). At block 1104, the RAN node receives data / signaling from the CN (e.g., event 510). At block 1108, the RAN node receives a retrieve UE context request message from the base station including the UE context ID (= I-RNTI) and the recovery reason RNA update (e.g., event 552). At block 1111, the RAN node sends a partial UE context delivery message to the base station including a portion of the RRC context for SDT and a DL indication (indicating MT-SDT) (e.g., event 555). At block 1113, the RAN node receives a partial UE context delivery confirmation message from the base station (e.g., event 557). At block 1112, the RAN node sends data / signaling to the base station (e.g., event 530B). In block 1115, the RAN node detects the end of the SDT and decides to send the UE back to RRC inactivity. At box 1117, the RAN node generates an RRC release message including suspendConfig and / or MT-SDT configuration. At box 1119, the RAN node sends a UE context retrieval failure message (e.g., event 550) to the base station, including the RRC release message.

[0134] The following list of examples reflects various embodiments explicitly contemplated in this disclosure.

[0135] Example 1. A method for managing transmissions from a radio access network (RAN) to a user equipment (UE) operating without an active radio connection to the RAN, the method being 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 to the RAN; sending a paging message for the UE to a second RAN node, the paging message including an indication of the downlink data or signaling; receiving from the second RAN node a request to retrieve the context of the UE, the request having a cause value associated with the indication of the downlink data or signaling; and sending a response to the request to the second RAN node, the response including an indication that the downlink data or signaling is available.

[0136] Example 2. The method as described in Example 1, wherein the downlink data or signaling is associated with Mobile Termination Small Data Transmission (MT-SDT).

[0137] Example 3. The method as described in Example 2, wherein the indication of the downlink data or signaling is an MT-SDT indication.

[0138] Example 4. The method as described in any of the preceding examples, wherein the indication that the downlink data or signaling is available is a DL forwarding information element (IE) set to "DL forwarding proposal" in the data forwarding and offloading information.

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

[0140] Example 6. The method as described in any of the preceding examples, wherein: the request to retrieve the context is a UE context request message; and the response to the request is a UE context response message.

[0141] Example 7. The method as described in any of the preceding examples, wherein: the request to retrieve the context is a UE context retrieval request message; and the response to the request is a partial UE context delivery message.

[0142] Example 8. A method for downlink transmission to a UE, the method being implemented in a RAN node and comprising: receiving from the UE, which is currently operating with a suspended radio connection to the RAN, a request to restore the radio connection, the request including a restoration reason; and sending at least one data packet to the UE when a reason value indicates that mobile transmission of data using the suspended radio connection is terminated, while the UE continues to operate using the suspended radio connection.

[0143] Example 9. The method as described in Example 8, wherein the mobile termination transmission of data using the suspended radio connection is associated with MT-SDT.

[0144] Example 10. The method as described in Example 8 or 9, wherein the at least one data packet includes an Ethernet packet, an IP packet, or an application packet.

[0145] Example 11. The method as described in Example 8 or 9, wherein the at least one data packet includes a NAS message or an LLP message.

[0146] The following descriptions can be applied to the descriptions above.

[0147] Generally, a description of one of the above figures can be applied to another of the above figures. The examples, implementations, and methods described above can be combined if there is no conflict. The events or boxes described above can be optional or omitted. For example, events or boxes with dashed lines in the figures can be optional. In some implementations, “message” is used and “information element (IE)” can be used instead of “message” (as the term is used above), and vice versa. In some implementations, “field” can be used instead of “IE” (as the term is used above), and vice versa. In some implementations, “configurations” or “configuration parameters” can be used instead of “configuration” (as the term is used above), and vice versa. In some implementations, “early data transfer (EDT)” can be used instead of “small data transfer” (as the term is used above) (and “EDT” can be used instead of “SDT”), and vice versa. In some implementations, "small data communication" can be used instead of "small data transmission" (as the term is used above), and vice versa. Unless a more specific meaning becomes clear from the context of use, "small data transmission," "SDT," or "small data communication" can refer to small data transmission / communication in the uplink and / or downlink directions.

[0148] The user device in which the technologies of this disclosure are implemented (e.g., UE 102) can be any suitable device capable of wireless communication, such as a smartphone, tablet computer, laptop computer, mobile game console, point-of-sale (POS) terminal, health monitoring device, drone, camera, media streaming dongle or other personal media device, wearable device (such as a smartwatch), wireless hotspot, femtocell, or broadband router. Additionally, in some cases, the user device can be embedded in an electronic system (such as the main unit of a vehicle or an advanced driver assistance system (ADAS)). Furthermore, the user device can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.

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

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

Claims

1. A method implemented in a user equipment (UE), the method comprising: Receive a paging message from the RAN, including a Mobile Termination Small Data Transmission (MT-SDT) indication, while in an inactive state of radio connection with the Radio Access Network (RAN); Following the paging message, a request to restore the radio connection is sent to the RAN, the request including a non-SDT reason; and In response to the request, a command for restoring the radio connection is received from the RAN.

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

3. The method of claim 1, wherein the non-SDT cause indicates the RAN to notify area update (rna-Update).

4. The method as described in any of the preceding claims, wherein: The request to restore the radio connection includes either the RRCResumeRequest or RRCConnectionResumeRequest message.

5. The method of claim 4, wherein: The commands used to restore the radio connection include the RRCResume or RRCConnectionResume messages.

6. A method implemented in a radio access network (RAN), the method comprising: Send a paging message including a Mobile Termination Small Data Transmission (MT-SDT) indication to a user equipment (UE) operating in an inactive state with radio connection to the RAN; Following the paging message, a request to restore the radio connection is received from the UE, the request including a non-SDT reason; as well as In response to the request, a command is sent to the UE to restore the radio connection.

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

8. The method of claim 6, wherein the non-SDT cause instructs the RAN to notify of a regional update (rna-Update).

9. The method according to any one of claims 6 to 8, wherein: The request to restore the radio connection includes either the RRCResumeRequest or RRCConnectionResumeRequest message.

10. The method of claim 9, wherein: The commands used to restore the radio connection include the RRCResume or RRCConnectionResume messages.

11. The method of any one of claims 6 to 10, wherein the method is implemented in the DU of a distributed base station comprising a distributed unit (DU) and a central unit (CU), the method further comprising: Send an uplink (UL) radio resource control (RRC) message to the CU, including the request to restore the radio connection.

12. The method of claim 11, further comprising: In response to the UL RRC message transmission, a downlink RRC message transmission message including the command for restoring the radio connection is received from the CU.

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

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

15. An apparatus comprising processing hardware and configured to implement the method as described in any of the preceding claims.

Images