Managing network initiated small data transmissions

Abstract

Comprising a central unit (CU) and a distributed unit (DU) receives (404), at a user plane (UP) entity (CU-UP) of the CU, a request to modify a bearer context for a user equipment (UE) from a control plane (CP) entity (CU-CP) of the CU, the request comprising information related to mobile terminated small data transmission (MT-SDT); receiving (410), at the CU-UP and in an inactive state of a radio connection between the UE and a radio access network (RAN), downlink (DL) data for the UE; and transmitting (412) an indication of DL data from the CU-UP to the CU-CP on the basis of the information relating to the MT-SDT received from the CU-CP, the indication comprising the MT-SDT indication.

Description

[0001] Cross-references to related applications

[0002] This application claims priority and benefit to Provisional U.S. Patent Application No. 63 / 493,709, filed March 31, 2023, entitled “Managing Network-Initiated SmallData transmission.” The entire contents of that provisional application are hereby expressly incorporated by reference. Technical Field

[0003] This disclosure generally relates to wireless communication, and more specifically to communication of uplink and / or downlink data at a user equipment (UE) when the 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 overall 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 might not have been considered prior art at the time of filing are neither expressly nor implicitly 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 transmission 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 to the base station; the RRC_CONNECTED state, in which the UE has an active radio connection to the base station; and RRC_INACTIVE, which allows the UE to transition back to the RRC_CONNECTED state more quickly due to Radio Access Network (RAN) level base station coordination and RAN paging procedures. In some cases, a UE in the RRC_INACTIVE state has only one relatively small packet to transmit. In these cases, a UE in the RRC_INACTIVE state can, for example, initiate Small Data Transmission (SDT) without transitioning to the RRC_CONNECTED state by using techniques as specified in Section 18.0.0 of 3GPP specification 38.300v17.4.0.

[0007] Distributed base stations can have DL small data packets for UEs operating in the RRC_INACTIVE state without an ongoing SDT session. How a distributed base station, including Central Unit (CU) Control Plane (CP) functions, CU User Plane (UP) functions, and Distributed Unit (DU) functions, should support mobile-terminated small data communication with the UE is unclear. Summary of the Invention

[0008] An example embodiment of the technology disclosed herein is a method implemented in a CU of a distributed base station including a central unit (CU) and distributed units (DU). The method includes: receiving, at a user plane (UP) entity (CU-UP) of the CU, a request from a control plane (CP) entity (CU-CP) of the CU to modify the bearer context for a user equipment (UE), the request including information related to Mobile Termination Small Data Transmission (MT-SDT); receiving, at the CU-UP and in a state of inactivity of the radio connection between the UE and the radio access network (RAN), downlink (DL) data for the UE; and an indication to transmit DL data from the CU-UP to the CU-CP based on the MT-SDT-related information received from the CU-CP, the indication including an MT-SDT indication.

[0009] Another embodiment of these technologies is a base station that includes processing hardware and is configured to implement the methods described above. Attached Figure Description

[0010] Figure 1A This is a block diagram of an example wireless communication system in which the user equipment and base station of this disclosure can implement the techniques of this disclosure for managing downlink early data transmission (EDT);

[0011] 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);

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

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

[0014] Figure 3 The example message sequence in which the CU determines to initiate SDT and sends an SDT indication to the DU causes the DU to generate a paging message for the UE indicating that the UE wants to initiate SDT;

[0015] Figure 4A Is with Figure 3 The message sequence is similar to the example message sequence, but in which the CU-UP (the user plane node of the CU) determines to initiate SDT and transmit the SDT instruction to the CU-CP (the control plane node of the CU);

[0016] Figure 4B Is with Figure 3 The message sequence is similar to the example message sequence, but in which the CU-CP determines to initiate SDT to transmit small data received from the core network;

[0017] Figures 5A to 5D This is a flowchart of an example method for transmitting an interface message including an SDT indication to a DU so that the DU transmits a paging message including an SDT indication to the UE. This method can be implemented by a CU-CP.

[0018] Figures 6A to 6D This is a flowchart of an example method for transmitting an interface message including an SDT indication to a base station so that the base station transmits a paging message including an SDT indication to the UE. This example method can be implemented by CU-CP.

[0019] Figure 7 This is a flowchart of an example method for performing a bearer context procedure in response to receiving CP data for a UE to restore at least one UP bearer for the UE. This example method can be implemented by CU-CP.

[0020] Figure 8 This is a flowchart of an example method for determining whether to include an SDT indication in a DU-to-CU message for a UE, which can be implemented by a DU;

[0021] Figure 9 This is a flowchart of an example method for performing UE context procedures (e.g., UE context setting procedure or UE context modification procedure) for Mobile Termination SDT (MT-SDT), which can be implemented by a CU;

[0022] Figure 10 This is a flowchart of an example method for performing UE context procedures for Random Access SDT (RA-SDT), Configuration Authorization SDT (CG-SDT), MT-SDT, or non-SDT, which can be implemented by a CU;

[0023] Figure 11 This is a flowchart of an example method for performing UE context procedures (e.g., UE context setting procedure or UE context modification procedure) for MT-SDT, which can be implemented by DU;

[0024] Figure 12 This is a flowchart of an example method for performing UE context procedures for SDT or non-SDT, which can be implemented by DU;

[0025] Figure 13 This is a flowchart of an example method for performing UE context procedures for SDT or non-SDT, which can be implemented by a CU;

[0026] Figure 14 This is a flowchart of an example method for transmitting interface messages that include MT-SDT indications in some cases, which can be implemented by CU-CP;

[0027] Figure 15 This is a flowchart of an example method for transmitting an interface message indicating the arrival of downlink data for the UE, which in some cases includes an MT-SDT indication; this example method can be implemented by CU-CP; and

[0028] Figures 16A to 16B This is a flowchart of an example method for transmitting an interface message indicating the arrival of downlink data for the UE, which in some cases includes an MT-SDT indication. This example method can be implemented by CU-UP. Detailed Implementation

[0029] First refer to Figure 1A Example wireless communication system 100 includes UE 102, 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.

[0030] 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 124 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 126 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 base station may cover one, two, three, or any other suitable number of cells. UE 102 may support at least 5G NR (or simply "NR") or E-UTRA air interface to communicate with base stations 104 and 106. Each of base stations 104 and 106 may be connected to CN 110 via an interface (e.g., 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.

[0031] Among other components, EPC 111 may also include a Serving Gateway (SGW) 112, a Mobility Management Entity (MME) 114, and a Packet Data Network Gateway (PGW) 116. Generally, SGW 112 is configured to transmit 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.

[0032] like Figure 1AAs illustrated, 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 switch from one cell to the other. For direct message or information exchange, base stations 104 and 106 may support X2 or Xn interfaces. Typically, CN 110 can connect to any suitable number of base stations supporting NR cells and / or EUTRA cells.

[0033] 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 transmit data. For clarity, the examples below refer to the RRC_INACTIVE or RRC_IDLE states of the RRC protocol.

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

[0035] In the example scenarios discussed below, UE 102 transitions to the RRC_INACTIVE or RRC_IDLE state, then 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 an early data transmission procedure without UE 102 transitioning to the RRC_CONNECTED state.

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

[0037] 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 transmit 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 Identifier (S-TMSI) or a Globally Unique Temporary Identifier (GUTI).

[0038] 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 a MAC-I. When encryption is enabled, UE 102 can encrypt the data to obtain an encrypted packet, such that the securely protected packet includes 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 transmit the securely protected packet to RAN 105 while in the RRC_INACTIVE or RRC_IDLE state.

[0039] In some implementations, the data is an uplink (UL) Service Data Unit (SDU) of Packet Data Convergence Protocol (PDCP) or SDAP. UE 102 applies security features to the SDU and includes the protected SDU in a first UL PDU (e.g., a UL PDCP 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 the 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, when including the UL RRC message in the UL MAC PDU, UE 102 generates an RRC MAC-I and includes the RRC MAC-I in the UL RRC message. For example, the RRC MAC-I is the resumeMAC-I field, 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, which contains the key, integrity protection algorithm, and other parameters such as 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).

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

[0041] 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 UE ID of UE 102, as described above.

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

[0043] 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 one example implementation, base station 106 retrieves the first UL PDU from the second UL PDU and transmits the first UL PDU to base station 104. Base station 104 then retrieves the secure packet from the first UL PDU, applies one or two security functions to decrypt the data and / or check integrity protection, and transmits the data to CN 110 (e.g., SGW 112, UPF 162, MME 114, or AMF 164) or an edge server. In some implementations, the edge server can operate within RAN 105. More specifically, base station 104 derives at least one security key from the UE context information of UE 102. Base station 104 then retrieves data from the secure packet using the at least one security key and transmits the data to CN 110 or the edge server. When the securely protected packet is an encrypted packet, base station 104 decrypts the encrypted packet using at least one security key (e.g., a (de)encryption key) to obtain the data. If the securely 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 securely protected packet using at least one security key (e.g., an integrity key). When base station 104 confirms the MAC-I is valid, base station 104 sends the data to CN 110 or the edge server. On the other hand, when base station 104 determines the MAC-I is invalid, base station 104 discards the securely protected packet. Further, if the securely protected packet is both encrypted and integrity-protected, the encrypted and integrity-protected packet may include the encrypted packet along with an encrypted MAC-I. In this case, base station 104 decrypts the encrypted packet and the encrypted MAC-I to obtain the data and the MAC-I. Then, base station 104 determines whether the MAC-I is valid for the data. If base station 104 determines that MAC-I is valid, then base station 104 retrieves the data and forwards it to CN 110 or the edge server. However, if base station 104 determines that MAC-I is invalid, then base station 104 discards the packet.

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

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

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

[0047] For example, when base station 104 determines that data is available 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. Further, 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, for example, includes this first DL PDU in a second DL PDU associated with the MAC layer (e.g., a DL MAC PDU), and transmits the second DL PDU to UE 102 without first causing UE 102 to transition 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 MACPDU, and then transmits the DL MAC PDU to UE 102 without first causing UE 102 to transition from the RRC_INACTIVE or RRC_IDLE state to the RRC_CONNECTED state.

[0048] In another implementation, base station 104 transmits a first DL PDU to base station 106. Then, base station 106 generates a second PDU (e.g., a DL MAC PDU) including the first DL PDU and transmits the second DL PDU to UE 102 without first causing UE 102 to transition 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 transmits a DL RLCPDU to base station 106. Then, base station 106 generates a second DL PDU (e.g., a DL MAC PDU) including the DL RLC PDU and transmits the second DL PDU to UE 102.

[0049] 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 transmit a second DL PDU generated by the base station. In some implementations, the ID of UE 102 may be a radio network temporary identifier (RNTI). For example, the RNTI may be a cell RNTI (C-RNTI), a temporary C-RNTI, or an inactive C-RNTI. The base station transmits the DCI and the scrambled CRC to UE 102 operating in 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 may assign the ID of UE 102 to UE 102 in the random access response transmitted by the base station during random access with UE 102 before transmitting the DCI and the 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) transmitted by the base station to UE 102 before transmitting DCI and scrambled CRC (e.g., when UE 102 was previously operating in RRC_CONNECTED, RRC_INACTIVE, or RRC_IDLE states).

[0050] UE 102, operating in RRC_INACTIVE or RRC_IDLE state, can receive DCI and scrambled CRC on the PDCCH. Then, UE 102 confirms 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 confirms 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 (containing 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.

[0051] 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. Alternatively or additionally, 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: allow transmitting base station 104 to transmit DL PDCP PDUs of data in the downlink direction in some scenarios, and allow receiving base station 104 to receive UL PDCP PDUs of data in the uplink direction in other scenarios. The processing hardware may further 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 the RRC_INACTIVE or RRC_IDLE state. Base station 106 may include generally similar components. Specifically, components 140, 142, 144, 146, and 148 may be similar to components 130, 132, 134, 136, and 138, respectively.

[0052] 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 random access procedures 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: allow transmitting base station 106 to transmit DL PDCP PDUs of data in the downlink direction in some scenarios, and allow receiving base station 106 to receive UL PDCP PDUs of data in the uplink direction in other scenarios. The processing hardware may further include an RRC controller 156 to implement process and message passing at the RRC sublayer of the protocol communication stack.

[0053] Figure 1B Example distributed or decomposed implementations of one or more of base stations 104 and 106 are depicted. In this implementation, base stations 104 and 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 and 144, RRC controllers 136 and 146, and / or RRC inactivity controllers 138 and 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.

[0054] Each DU in DU 174 also includes processing hardware, which may include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on 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.

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

[0056] CU-CP 172A can connect to multiple CU-UP 172Bs via the E1 interface. 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 172A via the E1 interface. CU-CP 172A can connect to one or more DU 174 via the F1-C or W1-C interface. CU-UP 172B can connect to one or more DU 174 via the 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 CU-UP 172B and DU 174 is established by CU-CP 172A using bearer context management functions.

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

[0058] 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 NR PHY 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 transmission services to the NR PDCP sublayer 210. The NR PDCP sublayer 210 can then provide data transmission 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 transmission services. In some implementations, UE 102 supports both EUTRA and NR stacks, such as... Figure 2A As shown, this supports handover between EUTRA and NR base stations and / or supports DCs via EUTRA and NR interfaces. Further, as... Figure 2A As shown, UE 102 can support NR PDCP 210 layering on EUTRA RLC 206A, and SDAP sublayer 212 layering on NR PDCP sublayer 210.

[0059] 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). Except where the difference between SDU and PDU is relevant, for simplicity, this disclosure refers to both SDU and PDU as "packets".

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

[0061] Figure 2BAn example protocol stack 250 is shown in a simplified manner, illustrating how UE 102 can communicate with DU (e.g., DU 174) and CU (e.g., CU 172). The radio protocol stack 200 is functionally broken down as follows: Figure 2B The radio protocol stack 250 is shown in the diagram. The CU at either base station 104 or 106 can retain all control and upper-layer functions (e.g., RRC 214, SDAP 212, NR PDCP 210), while lower-layer operations (e.g., NR RLC 206B, NR MAC 204B, and NR PHY 202B) are delegated to the DU. To support connectivity to the 5GC, NR PDCP 210 provides SRBs to RRC 214, and NR PDCP 210 provides DRBs to SDAP 212 and SRBs to RRC 214.

[0062] Figure 3 and Figures 4A to 4B This is a message passing diagram of an example scenario in which the UE and RAN nodes implement the techniques disclosed herein for early downlink data transmission.

[0063] First refer to Figure 3In scenario 300, base station 104 includes CU 172 and DU 174, and UE 102 initially operates in an inactive state (e.g., RRC_INACTIVE or RRC_IDLE) or a connected state with base station 104 (e.g., CU 172) (e.g., RRC_CONNECTED) 302. In some implementations, after a (first) specific period of data inactivity for UE 102, CU 172 may determine that neither base station 104 nor UE 102 has transmitted any data in the downlink or uplink direction, respectively, during that (first) specific period. In response to this determination, CU 172 may generate a first RRC release message (e.g., an RRCRelease message) to instruct UE 102 to transition to an inactive state, and transmit a CU-DU message including the first RRC release message 304 to DU 174. Subsequently, DU 174 transmits the first RRC release message 306 to UE 102. Upon receiving the first RRC release message, UE 102 transitions 308 to an inactive state and operates 308 in the inactive state. In other implementations, CU 172 transmits the first RRC release message 304, 306 to UE 102 in response to receiving an RRC recovery request message (e.g., an RRC Resume Request message or an RRC Resume Request1 message) from UE 102 operating in the inactive state. UE 102 maintains 308 in the inactive state in response to receiving the first RRC release message. CU 172 includes SDT configuration in the first RRC release message to configure SDT for UE 102. In some implementations, the CU-DU message is a UE context release command message, and DU 174 transmits a UE context release complete message to the CU in response to the UE context release command message. In other implementations, the CU-DU message is a DL RRC message passing message.

[0064] In some implementations, CU 172 may 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. In some implementations, CU 172 may include security parameters (e.g., next-hop link count) in the first RRC release message.

[0065] In some implementations, CU 172 includes an SDT DRB configuration (e.g., an sdt-DRB-List field) that configures one or more DRBs for SDT within the SDT configuration. In some implementations, CU 172 includes an SDT SRB configuration (e.g., an sdt-SRB2-Indication field) that configures an SRB (e.g., SRB2) for SDT within the SDT configuration. In some implementations, CU 172 includes the MT-SDT configuration in the SDT configuration or the first RRC release message to explicitly configure MT-SDT for UE 102. In some implementations, prior to event 304, CU 172 receives UE capabilities (e.g., UE-NR-CapabilityIE) of UE 102 from UE 102, CN 110 (e.g., AMF 164), or base station 106. The UE capability includes MT-SDT capability, which indicates that UE 102 supports MT-SDT as a result of this MT-SDT capability. Therefore, CU 172 determines to include MT-SDT configuration in the first RRC release message. If the UE's UE capability does not include MT-SDT capability, then CU 172 does not configure MT-SDT for that UE (e.g., if UE 102's UE capability does not include MT-SDT capability, then CU 172 does not include MT-SDT configuration in the first RRC release message). In other implementations, CU 172 does not include MT-SDT configuration in the first RRC release message to configure MT-SDT for UE 102, even though UE 102 supports MT-SDT. In such cases, when a paging message including the UE ID and an MT-SDT indication for UE 102 is received from RAN 105, as described with respect to event 314, UE 102 determines that RAN 105 configures or initiates MT-SDT for UE 102. If a UE that does not support MT-SDT receives a paging message including its UE ID and an MT-SDT indication for that UE, as described with respect to event 314, the UE ignores or discards the MT-SDT indication and performs a (legacy) RRC connection restoration procedure via DU 174 and CU 172 to transition to a connected state. During the (legacy) RRC connection restoration procedure, the UE transmits an RRC restoration request message (e.g., an RRCResumeRequest message or an RRCResumeRequest1 message) to CU 172 via DU 174, including a restoration reason other than the MT-SDT reason.Because the recovery reason is set to a value other than the MT-SDT reason value, or the RRC recovery request message does not include an MT-SDT reason, CU 172 transmits an RRC recovery message (e.g., an RRC Resume message) to UE 102 via DU 174 to transition UE 102 to the connected state. In response, UE 102 transitions to the connected state and transmits an RRC recovery complete message (e.g., an RRC Resume Complete message) to UE 102.

[0066] Events 304 and 306 are in Figure 3 This is collectively referred to as SDT configuration procedure 380. In some implementations, UE 102 operates 302 in an inactive state or connected to CU 172 via another DU (i.e., the second DU) instead of DU 174 (i.e., the first DU). In such cases, CU 172 performs the SDT configuration procedure with UE 102 via the second DU to configure SDT for UE 102 and transition UE 102 to an inactive state or keep UE 102 in an inactive state, similar to procedure 380. After performing the SDT configuration procedure (e.g., in response to this), UE 102 transitions 308 to an inactive state or remains in an inactive state. In other implementations, UE 102 operates 302 in an inactive state or connected to base station 106. In such cases, base station 106 performs an SDT configuration procedure to configure SDT for UE 102 and transition UE 102 to an inactive state or keep UE 102 in an inactive state, similar to SDT procedure 380. After performing the SDT configuration procedure (e.g., in response to this), UE 102 transitions to an inactive state 308 or remains in an inactive state 308.

[0067] In some implementations, when UE 102 operates in an inactive state 308, CU 172 receives DL data (e.g., DL data packet 1 in event 324) for UE 102 from a core network node (e.g., CN 110, AMF 164, or UPF 162). When UE 102 is performing an SDT configuration procedure with base station 106, when UE 102 is operating in an inactive state 308, CU 172 can receive a first BS-to-BS message (e.g., an XnAP paging message) from base station 106, including UE 102's UE ID and MT-SDT indication, to request MT-SDT paging of UE 102. Base station 106 transmits the first BS-to-BS message because it has received DL data for UE 102 from the core network node. In some example scenarios, the DL data is an Internet Protocol (IP) packet, an Ethernet packet, or an application packet. In other scenarios, DL data is a PDU (e.g., an RRC PDU or a PDCP PDU) that includes RRC messages, NAS messages, LTE Location Protocol (LPP) messages, IP packets, Ethernet packets, or application packets. Furthermore, in some scenarios, DL data can be an RRC PDU that includes a NAS PDU, such that the NAD PDU includes IP packets, Ethernet packets, or application packets.

[0068] In response to receiving DL data or a first BS-to-BS message, CU 172 determines 309 that MT-SDT is initiated. In response to this determination, CU 172 transmits a 310 CU-to-DU message (e.g., an F1 Application Protocol (F1AP) paging message) to DU 174, causing DU 174 to page UE 102. DU 174 generates a 312 paging message (e.g., an RRC paging message) to page UE 102 in response to receiving the CU-to-DU message. In some implementations, CU 172 includes the UE ID of UE 102 in the CU-to-DU message. For example, the UE ID is an I-RNTI or recovery ID. DU 174 includes the UE ID in the paging message to address UE 102. In some implementations, DU 174 generates a paging record including the UE ID and includes that paging record in the paging message. CU 172 includes a first MT-SDT indication in the CU-DU message, causing DU 174 to include a second MT-SDT indication in the paging message. The first MT-SDT indication can be an information element (IE), field, or flag of the CU-DU message. The first MT-SDT indication informs DU 174 that CU 172 has data available for UE 102, and UE 102 wants to use SDT to receive that data (i.e., without transitioning to a connected state). DU 174 includes the second MT-SDT indication in the paging record or paging message in response to the first MT-SDT indication. DU 174 then transmits a 314 paging message to UE 102. The second MT-SDT indication can be an IE, field, or flag generated by the DU and can be different from the first MT-SDT indication. The second MT-SDT indication instructs UE 102 to initiate MT-SDT to receive DL data.

[0069] Upon receiving a paging message, UE 102 generates a UL RRC message. In response to receiving a second MT-SDT indication in the paging message, UE 102 includes a third MT-SDT indication in the UL RRC message. UE 102 then transmits a UL RRC message 316 to DU 174, which in turn transmits a DU-CU message 318 including the UL RRC message to CU 172. In some implementations, UE 102 may include its UE ID in the UL RRC message 316 transmitted by UE 102. In some implementations, the UL RRC message may be an RRC recovery request message (e.g., an RRC Resume Request message), and the third MT-SDT indication is a first recovery reason (e.g., mt-SDT) indicating the MT-SDT. The third MT-SDT indication tells CU 172 that UE 102 is initiating an MT-SDT, rather than a legacy RRC connection recovery procedure, such as one where UE 102 transitions to a connected state. Therefore, CU 172 avoids transitioning UE 102 to a connected state in response to receiving a third MT-SDT indication. In some implementations, UE 102 generates a UL MAC PDU including a UL RRC message and transmits UL MAC PDU 316 to DU 174. DU 172 retrieves the UL RRC message from the UL MAC PDU and includes the UL RRC message in the DU-to-CU message. In some implementations, if UE 102 has UL data available for transmission, UE 102 may include that UL data in UL MAC PDU 316. In such cases, UE 102 avoids including an MT-SDT indication (e.g., a third MT-SDT indication) in the UL RRC message. For example, if the UL data includes UP data, UE 102 may include a second recovery reason set as Mobility Initiated Data (mo-Data) instead of including a first recovery reason. For example, if the UL data includes CP data, UE 102 may include a third recovery reason set to mo-Signalling instead of a first recovery reason. Alternatively, in such cases, UE 102 will still include the third MT-SDT indication in the UL RRC message. In other implementations, if UE 102 has UL data available for transmission, UE 102 may avoid including that UL data in UL MACPDU 316 and transmit that UL data in event 326. In some implementations, the DU to CU message is the initial UL RRC message delivery message. In other implementations, the DU to CU message is the UL RRC message delivery message.

[0070] After receiving the 318 DU to CU message, CU 172 may transmit a 320 UE Context Request message to DU 174 to establish or modify the UE context for UE 102 in DU 174. In response, DU 174 transmits a 322 UE Context Response message to CU 172. In the UE Context Request message, CU 172 may configure at least one UL tunnel for DU 174 to transmit UL data packets (i.e., UP data packets) received from UE 102 to CU 172. CU 172 includes UL UP tunnel configurations (e.g., UL UP tunnel information IE) for configuring each of the at least one UL tunnel in the UE Context Request message. In some implementations, each UL UP tunnel configuration in the at least one UL UP tunnel configuration is associated with a DRB. In some implementations, each UL UP tunnel configuration in the at least one UL UP tunnel configuration includes a transport layer address and a tunnel endpoint identifier (TEID). In some implementations, the transport layer address is an IP address, and the TEID is the GPRS Tunneling Protocol (GTP) TEID.

[0071] In the UE context response message, DU 174 can configure at least one DL tunnel for CU 172 to transmit DL data packets (i.e., UP data packets) received from CN110 or an edge server for UE 102. DU 174 includes the DL UP tunnel configuration (e.g., DL UP tunnel information IE) used to configure each of the at least one DL tunnel in the UE context response message. In some implementations, each DL UP tunnel configuration in the at least one DL UP tunnel configuration is associated with a DRB. In some implementations, each DL UP tunnel configuration in the at least one DL UP tunnel configuration includes a transport layer address and a TEID. In some implementations, the transport layer address is an IP address, and the TEID is a GPRS Tunneling Protocol (GTP) TEID.

[0072] In some implementations, the UE context request message and the UE context response message are the UE context setting request message and the UE context setting response message, respectively. In other implementations, the UE context request message and the UE context response message are the UE context modification request message and the UE context modification response message, respectively.

[0073] Events 310, 312, 314, 316, 318, 320, and 322 are in Figure 3 This is collectively referred to as the MT-SDT initiation process 382.

[0074] After receiving a 304 to first RRC release message, or receiving a 314 to paging message, or initiating a UL RRC message transmission 316, UE 102 uses security parameters to derive a security key (i.e., a base key, an integrity key, and / or an encryption key). For example, UE 102 uses security parameters to derive a 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 UPenc The CU172 derives the security key in a similar manner to UE 102 (i.e., the same security key derived by UE 102). UE 102 and CU 172 use an integrity key (e.g., K) in data communication during events 324 and 326. UPint Key) and / or encryption key (e.g., K UPenc Integrity key (e.g., K) is used in the communication of the second RRC release message in events 328 and 330 between UE 102 and CU 172. RRCint Key) and / or encryption key (e.g., K RRCenc (Key).

[0075] Generally, this disclosure refers to an "MT-SDT indication" as an indication that UE 102 is initiating or requesting to initiate an MT-SDT to receive DL data from RAN 105 without transitioning to a connected state. The MT-SDT indication can be formatted according to a suitable protocol, depending on the transmitter of the MT-SDT indication (e.g., a node of RAN 105 or UE 102) and the receiver or visited address of the MT-SDT indication. For example, in scenario 300, the first MT-SDT indication of CU 172 transmission 314 is included as an element of a CU-DU message addressing DU 174. The first MT-SDT indication can be formatted according to a protocol (e.g., F1AP) with termination points at CU 172 and DU 174. The second MT-SDT indication of DU 174 transmission 314 is included as an element of a paging message or paging record addressing UE 102. As discussed in reference event 316 below, UE 102 may transmit a third MT-SDT indication to CU 172 via DU 174 to indicate that UE 102 is requesting to initiate an MT-SDT, wherein the third MT-SDT indication may be formatted according to a protocol having an end point at UE 102 and CU 172.

[0076] In some implementations, CU 172 may determine whether DL data is eligible for transmission in an inactive state based on one or more factors such as: whether the DL data is associated with a radio bearer configured for SDT (e.g., DRB or SRB) and / or whether UE 102 supports MT-SDT. Some of these factors will be... Figures 5A to 6D Further description follows. When CU 172 determines that DL data is not eligible for transmission in an inactive state, CU 172 determines to initiate a non-SDT instead of an SDT to UE 102. If CU 172 determines to initiate a non-SDT instead of an SDT to UE 102, CU 172 may generate a second CU to DU message, including the UE ID in the second CU to DU message (e.g., an F1AP paging message), and exclude the SDT indication from the second CU to DU message. In response to the second CU to DU message excluding the SDT indication, DU 174 may send a second paging message including the UE ID to UE 102. In response to receiving the second paging message or thereafter, UE 102 may perform the (legacy) RRC connection recovery procedure via DU 174 and CU 172 to transition to a connected state.

[0077] After receiving the UE context setting response message 322, CU 172 may transmit 316 downlink (DL) data packets for UE 102 to DU 174. CU 172 may receive the DL data packets from CN 110 or an edge server. DU 174 may then generate at least one DL MAC PDU including the at least one DL data packet and send 316 of the at least one DL MAC PDU to UE 102 operating in an inactive state. The at least one DL MAC PDU may include a specific DL data packet or a fragment including a specific DL data packet from the at least one DL data packet. In some implementations, the at least one DL data packet includes L DL data packets, where L is a positive integer and may be less than a predetermined value. In some implementations, CU 172 receives DL data packets 2, ..., L during procedure 382 or after transmitting DL data packet 1. In some implementations, DU 174 sends 324 L DL MAC PDUs to UE 102, where each DL MAC PDU includes at least one specific DL data packet from a DL data packet. In other implementations, DU 174 may send more than 324 DL MAC PDUs to UE 102, each DL MAC PDU including a fragment of a specific DL data packet. In yet another implementation, DU 174 may send 324 DL MAC PDUs to UE 102, where each DL MAC PDU includes at least two DL data packets from L data packets.

[0078] If CU 172 receives a DL data packet from a UP CN node (e.g., UPF 162) in the form of DL data packets 1, ..., L, then CU 172 transmits the DL data packet to DU 174 via at least one DL tunnel. If CU 172 receives a DL data packet from a CP CN node (e.g., AMF 164) in the form of DL data packets 1, ..., L, then CU 172 transmits a CU-DU message (e.g., an F1AP message such as a DL RRC message delivery message) including the DL data packet to DU 174. In some implementations, each CU-DU message in the CU-DU message includes a specific DL data packet from the DL data packets.

[0079] In some implementations, after receiving some or all of the DL data packets 1, ..., L, the UE 102, operating in an inactive state, may send 326 at least one UL data packet to CU 172 via DU 174. Specifically, UE 102 generates at least one UL MAC PDU including at least one UL data packet and sends 326 of the at least one UL MAC PDU to DU 174. The at least one UL MAC PDU may include a specific UL data packet from the at least one UL data packet or a fragment including a specific UL data packet. In some implementations, the at least one UL data packet includes M UL data packets, where M is an integer greater than 0 and may be less than a predetermined value. In some implementations, UE 102 sends 326 M UL MAC PDUs to DU 174, where each UL MAC PDU includes a specific UL data packet from the at least one UL data packet. In other implementations, UE 102 may send multiple UL MAC PDUs to DU 174, each UL MAC PDU including a fragment of a specific UL data packet. In another implementation, UE 102 may send a UL MAC PDU to DU 174, which includes at least two UL data packets out of M data packets.

[0080] After transmitting at least one DL data packet (324) and / or receiving at least one UL data packet (326), CU 172 may determine to stop SDT. In response to this determination, CU 172 may transmit a CU-DU message (328) including a second RRC release message to DU 174, which in turn transmits a DL MAC PDU (330) including the second RRC release message to UE 102. When UE 102 receives the second RRC release message (330), UE 102 determines that the SDT (session) has ended and remains inactive. In response to receiving the second RRC release message or afterward, UE 102 stops attempting to receive DL MAC PDUs including DL data packets and / or stops transmitting UL MAC PDUs including UL data packets. In some implementations, the second RRC release includes an SDT configuration similar to the SDT configuration in the first RRC release message to configure SDT for UE 102. In other implementations, the second RRC release message does not include an SDT configuration for configuring SDT for UE 102. In such cases, UE 102 continues to use the SDT configuration received in the first RRC release message. In some implementations, CU 172 may include the new UE ID (e.g., I-RNTI or recovery identifier) ​​and / or security parameters (e.g., next-hop link count) in the second RRC release message. UE 102 uses the security parameters to derive the security key (i.e., the 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 UPenc (Key). UE 102 uses a new UE ID, integrity key, and / or encryption key to transition to a connected state during the next SDT (session) or during the restoration of an existing RRC connection with RAN 105. For example, the next SDT could be an MT-SDT as described above. In another example, the next SDT could be a Mobile Initiated SDT (MO-SDT), where UE 102 initiates an SDT with RAN 105 without receiving a paging message. In this case, the MO-SDT could be a Random Access SDT (RA-SDT) or a Configuration Authorization SDT (CG-SDT).

[0081] Depending on the implementation, CU 172 may or may not include the DL data packets in the CU-DU message of CU 172 transmission 328. In one implementation, if CU 172 does include the DL data packets in the CU-DU message, then DU 174 may include the DL data packets in the DL MAC PDU of DU 174 transmission 330. In another implementation, DU 174 may generate at least one additional DL MAC PDU (e.g., Y DL MAC PDUs, where Y is a positive integer) that includes some or all of the DL data packets, and transmit this at least one additional DL MAC PDU to UE 102. In this implementation, DU 174 may or may not include fragments of the DL data packets in the DL MAC PDU of DU 174 transmission 330. DU 174 transmits at least one additional DL MAC PDU before DU 174 transmission 322 includes the DL MAC PDU containing the second RRC release message. In some implementations, DU 174 may transmit 330 DL MAC PDUs after receiving a Hybrid Automatic Repeat Request (HARQ) acknowledgment for an additional DL MAC PDU.

[0082] In some implementations, DU 174 transmits at least one DCI on the PDCCH with cyclic redundancy check (CRC) scrambled using at least one specific RNTI to transmit a 324 DL MAC PDU and / or a 330 DL MAC PDU, and / or schedules UE 102 to transmit a 326 UL MAC PDU. In response to receiving a second RRC release message or thereafter, UE 102 ceases attempting to monitor or receive at least one specific RNTI on the PDCCH. The at least one specific RNTI may include a C-RNTI and / or a configured scheduled RNTI (CS-RNTI).

[0083] In some implementations, the CU-DU message 328 transmitted by CU 172 can be a UE context release command message. In response, DU 174 can send a UE context release complete message to CU 172. In other implementations, the CU-DU message 328 transmitted by CU can be a DL RRC message delivery message or a UE context modification request message. DU 174 can send a UE context modification response message to CU 172 in response to a UE context modification response message. In such cases, CU 172 can send another UE context release command message for UE 102 to DU 174 after sending the CU-DU interface message 328 to DU 174. In response, DU 174 can send another UE context release complete message to CU 172. In yet another implementation, the CU-DU message 328 transmitted by CU 172 can be a new or existing F1AP message specified in 3GPP specification 38.473.

[0084] In some implementations, an inactive UE 102 may perform a random access procedure with DU 174 in response to receiving a paging message 314 or transmitting a UL RRC message 316. For example, the random access procedure may be a four-step random access procedure or a two-step random access procedure. In the case of a four-step random access procedure, UE 102 transmits a random access preamble to base station 104, and in response, base station 104 transmits a random access response (RAR) including uplink grant to UE 102, and UE 102 transmits a UL MAC PDU based on the uplink grant. DU 174 receives the UL MAC PDU based on the uplink grant in the RAR. In the case of a two-step random access procedure, UE 102 transmits message A, including a random access preamble and a UL MAC PDU, to DU 174 according to two-step random access configuration parameters. Before transmitting the 316 UL MAC PDU, UE 102 receives two-step random access configuration parameters in system information broadcast by DU 174 on cell 124. DU 174 receives either message 316A or the UL MAC PDU based on the two-step random access configuration parameters. In other implementations, UE 102 may transmit the 316 UL MAC PDU on radio resources configured for SDT in the CG configuration. CU 172 may receive the CG configuration from DU 174 and include the CG configuration in the first RRC release message or the SDT configuration in the first RRC release message. DU 174 receives the 316 UL MAC PDU on radio resources based on the CG configuration. In some implementations, CU 172 may receive the CG configuration for UE 102 from DU 174 and include the CG configuration in the second RRC release message or the SDT configuration in the second RRC release message.

[0085] If CU 172 determines that UE 102 has initiated MT-SDT in response to receiving DL data for UE 102, CU 172 may transmit a second BS-BS message (e.g., an XnAP paging message) including the UE ID of UE 102 and the MT-SDT indication to base station 106 to request the base station to page UE 102 for MT-SDT. In response to receiving the second BS-BS message, the CU of base station 106 transmits a CU-DU message including the UE ID and the first MT-SDT indication to the DU of base station 106, similar to event 310. The DU of base station 106 generates a paging message including the UE ID and the second MT-SDT indication, and transmits the paging message, similar to events 312 and 314, respectively. If UE 102 is within the coverage of base station 106, UE 102 transmits a UL RRC message to DU in response to receiving a paging message, similar to event 316, and DU and CU perform actions similar to events 318, 320, 322, 324, 326 and 384.

[0086] Figures 4A to 4B A scenario that might be similar to scenario 300 is shown. However, Figures 4A to 4B The specific actions that can be performed by the control plane node (i.e., CU-CP) and user plane node (i.e., CU-UP) of the CU are illustrated. Specifically, depending on the scenario, either the CU-CP or the CU-UP may determine whether to initiate an SDT.

[0087] First go to Figure 4A In scenario 400A, base station 104 includes DU 174, CU-CP 172A, and CU-UP 172B, where CU-CP 172A and CU-UP 172B are nodes of CU 172. Events 402, 480, 408, 482, 424-1 / 424-2, 426-1 / 426-2, and 484 are similar to events 302, 380, 308, 382, ​​324, 326, and 384, respectively. When CU-CP 172A determines that it is configuring SDT for UE 102, CU-CP 172, DU 174, and UE 102 perform the 480 SDT configuration procedure, similar to procedure 380.

[0088] In response to determining that SDT is configured for UE 102, CU-CP 172A performs a bearer context modification procedure by transmitting a 404 Bearer Context Modification Request message to CU-UP 172B. In response, CU-UP 172B transmits a 406 Bearer Context Modification Response message to CU-CP 172A. CU-CP 172A includes SDT DRB information in the bearer context modification request message to configure one or more DRBs for SDT. In some implementations, CU-CP 172A includes a suspension indication in the bearer context modification request message to indicate to CU-UP 172B that the bearer context of UE 102 is suspended. The bearer context includes one or more bearers configured for UP data communication for UE 102. The bearers include at least one bearer configured for SDT (i.e., an SDT bearer). In some implementations, the bearers may include at least one bearer other than the SDT bearer (i.e., a non-SDT bearer). The suspension indication indicates that all bearers are suspended. In some implementations, CU-CP 172A includes the MT-SDT information of UE 102 in the bearer context modification request message. Based on the MT-SDT information, CU-UP 172B determines that UE 102 is configured with MT-SDT. For example, the MT-SDT information indicates that MT-SDT is configured for UE 102. In other alternative implementations, CU-CP 172A does not include the MT-SDT information in the bearer context modification request message. In such cases, CU-UP 172B is unaware whether UE 102 is configured with MT-SDT. CU-CP 172A may perform the bearer context modification procedure with CU-UP 172B before, during, or after the SDT configuration procedure 480 (i.e., events 404 and 406).

[0089] In some scenarios and implementations, CU-CP 172A and CU-UP 172B communicate with the UE via another DU (i.e., the second DU) instead of DU 174. In such cases, CU-CP 172A performs the SDT configuration procedure with the UE via the second DU, similar to procedures 380 and 480.

[0090] At a later time, when UE 102 operates in an inactive state (408), CU-UP 172B receives DL data (i.e., UP data) for UE 102 from CN 110 or an edge server (410). The DL data includes one or more DL data packets. In response to receiving the DL data, CU-UP 172B initiates MT-SDT to transmit the DL data to UE 102. In some implementations, CU-UP 172B determines to initiate MT-SDT based on one or more factors. Factors include a data volume threshold and / or the ID of the DRB, PDU session, or QoS flow associated with the DL data. For example, CU-UP 172B determines to initiate MT-SDT because the size of the DL data is less than or equal to the data volume threshold and the specific ID of the DRB, PDU session, or QoS flow associated with the DL data. In response to determining to initiate MT-SDT or initiating MT-SDT, CU-UP 172B transmits a DL data notification message including an MT-SDT indication (412) to CU-CP 172A. The DL data notification message indicates the arrival of DL data for UE 102, and the MT-SDT instruction notifies CU-CP 172A (eligible) of the DL data for MT-SDT (i.e., without causing UE 102 to transition to a connected state). After receiving the DL data notification message 412, CU-CP 172A, along with DU 174 and UE 102, performs MT-SDT initiation procedure 482, similar to procedure 382.

[0091] After executing MT-SDT initiation procedure 482 or receiving a message from UE 102 or DU 174 during MT-SDT initiation procedure 482 (e.g., in response to this), CU-CP 172A and CU-UP 172B perform a bearer context procedure. During the bearer context procedure, CU-CP 172A transmits a 414 bearer context request message to CU-UP 172B to notify CU-UP 172B that UE 102 is connected to CU-CP 172A, or to request CU-UP 172B to set or modify the bearer context of UE 102. The message may be a UL RRC message, a DU to CU message, or a UE context response message, similar to events 326, 318, and 320, respectively. In some implementations, CU-CP 172A includes a recovery for the SDT indication in the bearer context request message, and the recovery for the SDT indication indicates that the UP bearer configured for the SDT of UE 102 (i.e., the SDT UP bearer) has been recovered. Upon receiving a recovery notification for the SDT indication, the CU-UP 172B determines that the SDT UP bearer has been restored and that non-SDT UP bearers (if configured) have been suspended. In response to the bearer context request message, the CU-UP 172B transmits a 416 bearer context response message to the CU-CP 172A. In some implementations, the bearer context request message and the bearer context response message are respectively a bearer context modification request message and a bearer context modification response message. In other implementations, the bearer context request message and the bearer context response message are respectively a bearer context setting request message and a bearer context setting response message.

[0092] Upon receiving a bearer context request message or a transmission bearer context response message (e.g., in response to this), CU-UP 172B then transmits at least one DL data packet (i.e., UP data packet) to DU 174 via DU 174, similar to event 324. CU-UP 172B receives at least one DL data packet from the UP node (e.g., UPF 162) in CN 110. This at least one DL data packet includes DL data packet 410. During or after DL small data transmission 424-1, if UE 102 has at least one UL UP data packet to transmit to base station 104, UE 102 may transmit the at least one UL UP data packet via DU 174 to CU-UP 172B, similar to event 326. CU-UP 172B transmits the at least one UL UP data packet to the UP node. During or after DL small data transmission 424-1, if CU-CP 172A has at least one DL CP data packet to transmit to UE 102, UE 102 can transmit 424-2 of the at least one DL CP data packet to CU-CP 172A via DU 174, similar to event 326. CU-CP 172A can receive the at least one DL CP data packet from the CP node (e.g., AMF 164) in CN 110. During or after DL small data transmission 424-1, if UE 102 has at least one UL CP data packet to transmit to base station 104, UE 102 can transmit 426-2 of the at least one UL CP data packet to CU-CP 172A via DU 174, similar to event 326. CU-CP 172A transmits the at least one UL CP data packet to the CP node.

[0093] If there is no additional DL or UL data to communicate with UE 102, CU-UP 172B may transmit a 428 Inactivity Notification Message (e.g., Bearer Context Inactivity Notification Message) to CU-CP172A to indicate (data) inactivity of UE 102. In some implementations, after a specific period of data inactivity for UE 102, CU-UP 172B may determine that neither base station 104 nor UE 102 has transmitted any data in the downlink or uplink direction during that specific period. In response to this determination, CU-UP 172B transmits a 428 Inactivity Notification Message to CU-CP 172A, and CU-CP 172A determines (data) inactivity of UE 102 based on this inactivity notification message. In other implementations, CU-UP 172B transmits a first data usage report message to CU-CP172A to report the first amount of data served by CU-UP 172B for UE 102. At a later time, CU-UP 172B transmits a second data usage report message to CU-CP 172A to report the second data volume served by CU-UP 172B for UE 102. If the second data volume is the same as the first data volume, CU-CP 172A determines that UE 102 is (data) inactive. When CU-CP 172A determines that UE 102 is (data) inactive, CU-CP 172A initiates a bearer context modification procedure with CU-UP 172B by transmitting a 430 bearer context modification request message to CU-UP 172B, similar to event 404. In response, CU-UP 172B transmits a 432 bearer context modification response message to CU-CP 172A, similar to event 406. When CU-CP 172A determines that UE 102 is (data) inactive, CU-CP 172A, UE 102, and DU 174 execute the 484 SDT stop procedure, similar to procedure 384. In some implementations, CU-CP 172A executes the bearer context modification procedure and the SDT stop procedure in parallel. In other implementations, CU-CP 172A executes the bearer context modification procedure before or after executing the SDT stop procedure.

[0094] Go to Figure 4BScenario 400B is largely similar to Scenario 400A, except that CU-CP 172A receives 411 DL data for UE 102 from the CP node (e.g., AMF 164) in CN 110 and determines that MT-SDT is initiated for UE 102 in response to receiving the DL data. In some implementations, CU-CP 172A can determine whether the DL data is eligible for MT-SDT based on the size of the DL data. For example, if the size of the DL data is less than or equal to a predetermined threshold, CU-CP 172A determines that MT-SDT is initiated for UE 102. In response to initiating MT-SDT for UE 102, CU-CP 172A, UE 102, and DU 174 perform 482 MT-SDT initiation procedure.

[0095] Figure 5A This is a flowchart of an example method 500A for transmitting interface messages to a DU (e.g., DU 174) to page a UE (e.g., UE 102) for MT-SDT. This example method can be implemented by a CU-CP (e.g., CU-CP 172A of base station 104).

[0096] Method 500A begins at block 502, where the CU-CP receives an UP-CP message from the CU-UP indicating that MT-SDT data for the UE has been detected (e.g., event 412). At block 504, the CU-CP includes the UE's UE identifier in a CU-DU message to page the UE (e.g., events 310, 382, ​​482). At block 506A, the CU-CP determines whether the UE supports MT-SDT. If the CU-CP determines at block 506A that the UE supports MT-SDT, the process proceeds to blocks 508 and 510. At block 508, the CU-CP includes the MT-SDT indication in a CU-DU message (e.g., events 310, 382, ​​482). At block 510, the CU-CP transmits a CU-DU message to the DU (e.g., events 310, 382, ​​482). Otherwise, if the CU-CP determines at box 506A that the UE does not support MT-SDT, the process skips box 508 and proceeds to box 510. In some implementations, the CU-CP avoids including the MT-SDT indication in the CU-to-DU message to skip box 608.

[0097] In some implementations, the UP to CP message is an E1 Application Protocol (E1AP) message (e.g., a DL data notification message). In some implementations, the CU to DU message is an F1 Application Protocol (F1AP) message (e.g., an F1AP paging message). In some implementations, the UE identifier is an Inactive Radio Network Temporary Identifier (I-RNTI) or a Full Radio Network Temporary Identifier (full-RNTI).

[0098] Figure 5B This is a flowchart of an example method 500B, similar to method 500A, except that method 500B includes block 506B instead of block 506A. At block 506B, the CU-CP determines whether the UE has MT-SDT configured. If the CU-CP determines at block 506B that the UE has MT-SDT configured, the process proceeds to blocks 508 and 510. Otherwise, if the CU-CP determines at block 506B that the UE does not have MT-SDT configured, the process skips block 508 and proceeds to block 510.

[0099] In some implementations, the CU-CP transmits an RRC release message (e.g., events 328, 330, 384, 484) configuring the MT-SDT to the UE via a DU or another DU. In such cases, the CU-CP may include the MT-SDT configuration (e.g., an MT-SDT indication) in the RRC release message to configure the MT-SDT.

[0100] Figure 5C This is a flowchart of an example method 500C, similar to method 500A, except that method 500C includes blocks 503 and 506C instead of blocks 502 and 506A. At block 503, the CU-CP receives an UP-to-CP message from the CU-UP, indicating that DL data for the UE has been detected (e.g., event 412). At block 506C, the CU-CP determines whether the UP-to-CP message includes an MT-SDT indication and whether the UE supports MT-SDT. If at block 506C the CU-CP determines that the UP-to-CP message includes a (first) MT-SDT indication and that the UE supports MT-SDT, the process proceeds to blocks 508 and 510. At block 508, the CU-CP includes a second MT-SDT indication in the CU-to-DU message (e.g., events 310, 382, ​​482). Otherwise, if the CU-CP determines that the UP to CP message does not include an MT-SDT indication or the UE does not support MT-SDT at box 506C, the process skips box 508 and proceeds to box 510.

[0101] Figure 5DThis is a flowchart of an example method 500D, similar to method 500C, except that method 500D includes block 506D instead of block 506C. At block 506D, the CU-CP determines whether the UP-to-CP message includes a (first) MT-SDT indication and whether the UE is configured with MT-SDT. If at block 506D the CU-CP determines that the UP-to-CP message includes a (second) MT-SDT indication and the UE is configured with MT-SDT, the process proceeds to blocks 508 and 510. Otherwise, if the CU-CP determines that the UP-to-CP message does not include an MT-SDT indication or the UE is not configured with MT-SDT, the process skips block 508 and proceeds to block 510.

[0102] Figure 6A This is a flowchart of an example method 600A for transmitting interface messages to a base station (e.g., base station 106 or CU-CP 172A or CU 172 of base station 106) to page a UE (e.g., UE 102) for MT-SDT, which can be implemented by a CU-CP (e.g., CU-CP 172A of base station 104).

[0103] Method 600A begins at block 602, where the CU-CP receives an UP-CP message from the CU-UP indicating that MT-SDT data for the UE has been detected (e.g., event 412). At block 604, the CU-CP includes the UE's UE identifier in a BS-BS message to page the UE. At block 606A, the CU-CP determines whether the UE supports MT-SDT. If the CU-CP determines at block 606A that the UE supports MT-SDT, the process proceeds to blocks 608 and 610. At block 608, the CU-CP includes the MT-SDT indication in a BS-BS message. At block 610, the CU-CP transmits a BS-BS message to the RAN node (e.g., the CU, CU-CP, or a base station). Otherwise, if the CU-CP determines at block 606A that the UE does not support MT-SDT, the process skips block 608 and proceeds to block 610. In some implementations, CU-CP avoids including the MT-SDT instruction in the BS-to-BS message to skip box 608.

[0104] In some implementations, the UP to CP message is an E1 Application Protocol (E1AP) message (e.g., a DL data notification message). In some implementations, the BS to BS message is an Xn Application Protocol (XnAP) message (e.g., an XnAP paging message). In some implementations, the UE identifier is an Inactive Radio Network Temporary Identifier (I-RNTI) or a Full Radio Network Temporary Identifier (full-RNTI).

[0105] Figure 6BThis is a flowchart of an example method 600B, similar to method 600A, except that method 600B includes block 606B instead of block 606A. At block 606B, the CU-CP determines whether the UE has MT-SDT configured. If the CU-CP determines at block 606B that the UE has MT-SDT configured, the process proceeds to blocks 608 and 610. Otherwise, if the CU-CP determines at block 606B that the UE does not have MT-SDT configured, the process skips block 608 and proceeds to block 610.

[0106] In some implementations, the CU-CP transmits an RRC release message (e.g., events 328, 330, 384, 484) configuring the MT-SDT to the UE via a DU or another DU. In such cases, the CU-CP may include the MT-SDT configuration (e.g., an MT-SDT indication) in the RRC release message to configure the MT-SDT.

[0107] Figure 6C This is a flowchart of an example method 600C, similar to method 600A, except that method 600C includes blocks 603 and 606C instead of blocks 602 and 606A. At block 603, the CU-CP receives an UP-to-CP message from the CU-UP, indicating that DL data for the UE has been detected (e.g., event 412). At block 606C, the CU-CP determines whether the UP-to-CP message includes an MT-SDT indication and whether the UE supports MT-SDT. If at block 606C the CU-CP determines that the UP-to-CP message includes an MT-SDT indication and that the UE supports MT-SDT, the process proceeds to blocks 608 and 610. Otherwise, if at block 606C the CU-CP determines that the UP-to-CP message does not include an MT-SDT indication or that the UE does not support MT-SDT, the process skips block 608 and proceeds to block 610.

[0108] Figure 6D This is a flowchart of an example method 600D, similar to method 600C, except that method 600D includes block 606D instead of block 606C. At block 606D, the CU-CP determines whether the UP-to-CP message includes an MT-SDT indication and whether the UE is configured with MT-SDT. If at block 606D the CU-CP determines that the UP-to-CP message includes an MT-SDT indication and the UE is configured with MT-SDT, the process proceeds to block 608. Otherwise, if the CU-CP determines that the UP-to-CP message does not include an MT-SDT indication or the UE is not configured with MT-SDT, the process proceeds to block 610.

[0109] In some implementations, any of the methods in methods 600A to 600D can be combined with any of the methods in methods 500A to 500D.

[0110] Figure 7 This is a flowchart of an example method 700 for transmitting UP data and CP data to a UE (e.g., UE 102) using MT-SDT, which can be implemented by CU-CP (e.g., CU-CP 172A of base station 104).

[0111] Method 700 begins at block 702, where the CU-CP receives DLCP data from the CN for a UE operating in an inactive state (e.g., events 309, 411). At block 704, in response to receiving the DLCP data, the CU-CP performs an MT-SDT initiation procedure with the UE and the DU (e.g., 382, ​​482). At block 706, in response to receiving the DLCP data or performing the MT-SDT initiation procedure, the CU-CP performs a bearer context procedure with the CU-UP to restore the SDT UP bearer used to communicate UP data with the UE (e.g., events 414, 416). At block 708, the CU-CP transmits the DLCP data to the UE operating in an inactive state via the DU (e.g., events 424-2).

[0112] In some implementations, the CU-CP receives UL CP data from a UE operating in an inactive state via the DU (e.g., event 426-2). In some implementations, after the SDT UP bearer is restored, the CU-UP can receive UL UP data transmitted by a UE operating in an inactive state (e.g., event 426-1). In other implementations, after the SDT UP bearer is restored, the CU-UP can receive DL UP data from the CN and transmit that DL UP data to a UE operating in an inactive state (e.g., event 424-1). If CU-CP omit box 706, the CU-UP cannot communicate SDT UL data and DL data with the UE.

[0113] In some implementations, DL CP data includes one or more CP messages (e.g., RRC messages, NAS messages, or LPP messages). In some implementations, UL CP data includes one or more CP messages (e.g., RRC messages, NAS messages, or LPP messages). In some implementations, DL UP data includes one or more IP packets and / or one or more Ethernet packets. In some implementations, UL UP data includes one or more IP packets and / or one or more Ethernet packets.

[0114] Figure 8This is a flowchart of an example method 800 for instructing a UE to initiate an SDT to a CU (e.g., CU 172 or CU-CP 172A of base station 104), which can be implemented by a DU (e.g., DU 174 of base station 104).

[0115] Method 800 begins at box 802, where the DU and UE perform a random access procedure. At box 804, the DU receives UL RRC messages from the UE during the random access procedure (e.g., events 316, 382, ​​482). At box 806, the DU includes the UL RRC messages in a DU-CU message (e.g., events 318, 382, ​​482). At box 808, the DU determines whether the random access resources used for the random access procedure are configured for SDT. If the DU determines at box 808 that the random access resources used for the random access procedure are configured for SDT, the procedure proceeds to box 810. At box 810, the DU includes an SDT indication in the DU-CU message. Otherwise, if the DU determines at box 808 that the random access resources used for the random access procedure are not configured for SDT, the procedure proceeds to box 812. At box 812, the DU sends a DU-CU message to the CU. That is, the DU avoids including the SDT indication in the DU-CU message. The process proceeds from box 806 and from box 808 to box 810.

[0116] Figure 9 This is a flowchart of an example method 900 for managing cell group configurations received from a DU (e.g., DU 174 of base station 104), which can be implemented by a CU (e.g., CU 172 or CU-CP 172A of base station 104).

[0117] Method 900 begins at block 902, where the CU transmits a UE context request message (e.g., events 320, 382, ​​482) to the DU for MT-SDT with the UE. At block 904, the CU receives a UE context response message (e.g., events 322, 382, ​​482) from the DU, including the cell group configuration. At block 906, the CU ignores or discards the cell group configuration. Because the CU ignores or discards the cell group configuration, the CU does not transmit an RRC message (e.g., an RRCResume message) including the cell group configuration to the UE to transition the UE to a connected state (e.g., RRC_CONNECTED).

[0118] In some implementations, the cell group configuration is CellGroupConfigIE as defined in 3GPP specification 38.331. In some implementations, the CU includes the SDT configuration in the UE context request message used for MT-SDT with the UE. For example, the SDT configuration (e.g., SDT RLC bearer configuration) configures the RLC bearer used for SDT. The RLC bearer may be associated with a radio bearer (e.g., SRB or DRB). In another example, the SDT configuration (e.g., SDT indicator setting or SDT indicator modification) indicates the radio bearer (e.g., SRB or DRB) configured for SDT.

[0119] Figure 10 This is a flowchart of an example method 1000 for managing cell group configurations received from a DU (e.g., DU 174 of base station 104), which can be implemented by a CU (e.g., CU 172 or CU-CP 172A of base station 104).

[0120] Method 1000 begins at block 1002, where the CU transmits a UE context request message for the UE to the DU (e.g., events 320, 382, ​​482). At block 1004, the CU receives a UE context response message from the DU including cell group configuration (e.g., events 322, 382, ​​482). At block 1006, the CU determines whether the UE has transmitted a UE context request message for the UE's RA-SDT, CG-SDT, or MT-SDT. If the CU determines at block 1006 that it has transmitted a UE context request message for the UE's RA-SDT, CG-SDT, or MT-SDT, the process proceeds to block 1008. At block 1008, the CU ignores or discards the cell group configuration. Otherwise, if the CU determines at block 1006 that it has transmitted a UE context request message unrelated to the UE's RA-SDT, CG-SDT, and / or MT-SDT, the process proceeds to block 1010. At box 1010, the CU transmits the cell group configuration to the UE via the RAN node. For example, the CU generates an RRC message including the cell group configuration and transmits this RRC message to the UE via the RAN node. In some implementations, the RAN node is a DU, another DU, or a base station. In some implementations, the RRC message is an RRC recovery message (e.g., an RRC Resume message) or an RRC reconfiguration message (e.g., an RRC Reconfiguration message).

[0121] In some implementations, the CU may include the SDT configuration in the UE context request message used for RA-SDT, CG-SDT, or MT-SDT with the UE. For example, the SDT configuration is the SDT RLC bearer configuration. In such cases, if the UE context request message includes the SDT configuration, the CU ignores or discards the cell group configuration. Otherwise, if the UE context request message does not include the SDT configuration, the CU transmits the cell group configuration to the UE via the RAN node.

[0122] In some implementations, the cell group configuration is CellGroupConfigIE as defined in 3GPP specification 38.331. If the UE or CU does not support CG-SDT, the "CG-SDT" mentioned above can be omitted. If the UE or CU does not support RA-SDT, the "RA-SDT" mentioned above can be omitted.

[0123] Figure 11 This is a flowchart of an example method 1100 for transmitting cell group configuration to a CU (e.g., CU 172 or CU-CP 172A of base station 104), which can be implemented by a DU (e.g., DU 174 of base station 104).

[0124] Method 1100 begins at block 1102, where the DU receives a UE context request message (e.g., events 320, 382, ​​482) for the UE from the CU. At block 1104, the DU determines whether the UE context request message is used for the RA-SDT, CG-SDT, or MT-SDT with the UE. If the DU determines at block 1104 that the UE context request message is not used for the RA-SDT, CG-SDT, and / or MT-SDT with the UE, the process proceeds to blocks 1106 and 1108. At block 1106, the DU includes the cell group configuration in the UE context response message. In some implementations, the DU uses the cell group configuration to communicate with the UE after transmitting the cell group configuration to the CU. Otherwise, if the DU determines at block 1104 that the UE context request message is used for the RA-SDT, CG-SDT, or MT-SDT with the UE, the process proceeds to block 1108. That is, the DU avoids including the cell group configuration in the UE context response message. At box 1108, the DU transmits the UE context response message to the CU. In some implementations, the cell group configuration is the CellGroupConfig IE defined in 3GPP specification 38.331.

[0125] In some implementations, the UE context request message may include SDT configuration for the RA-SDT, CG-SDT, or MT-SDT with the UE. For example, the SDT configuration is an SDT RLC bearer configuration. In such cases, if the UE context request message includes the SDT configuration, the DU avoids including the cell group configuration in the UE context response message. Otherwise, if the UE context request message does not include the SDT configuration, the DU includes the cell group configuration in the UE context response message. After receiving the cell group configuration, the CU transmits the cell group configuration to the UE via a RAN node (e.g., the DU, another DU, or a base station).

[0126] In some implementations, the cell group configuration is CellGroupConfigIE as defined in 3GPP specification 38.331. If the UE or CU does not support CG-SDT, the "CG-SDT" mentioned above can be omitted. If the UE or CU does not support RA-SDT, the "RA-SDT" mentioned above can be omitted.

[0127] Figure 12 This is a flowchart of an example method 1200 for transmitting cell group configuration to a CU (e.g., CU 172 or CU-CP 172A of base station 104), which can be implemented by a DU (e.g., DU 174 of base station 104).

[0128] Method 1200 begins at block 1202, where the DU receives a UE context request message for the UE from the CU (e.g., events 320, 382, ​​482). At block 1204, the DU transmits a UE context response message (e.g., events 322, 382, ​​482) to the CU, including the cell group configuration. At block 1206, the DU determines whether the UE context request message is used for SDT with the UE. If the DU determines at block 1206 that the UE context request message is not used for SDT with the UE, the process proceeds to block 1208. At block 1208, the DU uses the cell group configuration to communicate with the UE. Otherwise, if the DU determines at block 1206 that the UE context request message is used for SDT with the UE, the process proceeds to block 1210. At block 1210, the DU communicates with the UE without using the cell group configuration. In some implementations, the DU ignores or discards the cell group configuration.

[0129] In some implementations, the UE Context Request message may include SDT configuration for communication with the UE. For example, the SDT configuration may be an SDT RLC bearer configuration. In such cases, if the UE Context Request message includes the SDT configuration, the DU communicates with the UE without using the cell group configuration. Otherwise, if the UE Context Request message does not include the SDT configuration, the DU uses the cell group configuration to communicate with the UE. In some implementations, the cell group configuration is the CellGroupConfig IE defined in 3GPP specification 38.331. When the DU receives a UE Context Request message that includes the SDT configuration, the DU may not know whether the UE Context Request message is for RA-SDT or MT-SDT.

[0130] Figure 13 This is a flowchart of an example method 1300 for transmitting cell group configuration to a DU (e.g., DU 174 of base station 104), which can be implemented by a CU (e.g., CU 172 or CU-CP 172A of base station 104).

[0131] Method 1300 begins at box 1302, where the CU initiates a UE context procedure for the UE. At box 1304, the CU determines whether it initiates a UE context procedure for an SDT (e.g., events 320, 382, ​​482). If at box 1304 the CU determines that it initiates a UE context procedure for a non-SDT, the process proceeds to box 1306. At box 1306, the CU includes the UE's UE context in the UE context request message. For example, the UE context is or includes a cell group configuration (e.g., CellGroupConfig IE). The process proceeds from box 1306 to box 1312. Otherwise, if at box 1304 the CU determines that it initiates a UE context procedure for an SDT, the process proceeds to box 1308. At box 1308, the CU avoids including the UE context in the UE context request message. At box 1310, the CU includes at least one SDT configuration in the UE context request message. At box 1312, the CU transmits a UE context request message (e.g., events 320, 382, ​​482) to the DU.

[0132] In some implementations, at least one SDT configuration (e.g., an SDT RLC bearer configuration) configures an RLC bearer for the SDT. For example, each SDT configuration in at least one SDT configuration configures a specific RLC bearer. Each RLC bearer may be associated with a radio bearer (e.g., an SRB or a DRB). In other implementations, at least one SDT configuration (e.g., an SDT indicator setting or an SDT indicator modification) indicates a radio bearer (e.g., an SRB and / or a DRB) configured for the SDT. For example, each SDT configuration in at least one SDT configuration indicates a specific radio bearer configured for the SDT.

[0133] When the DU receives a UE context request message that does not include the UE context, the DU does not generate a cell group configuration for the UE or transmit the cell group configuration to the CU. Because the CU does not receive the cell group configuration for the UE, the CU keeps the UE in an inactive state. Therefore, the CU can use SDT (i.e., RA-SDT, CG-SDT, or MT-SDT) to communicate with the UE.

[0134] Figure 14 This is a flowchart of an example method 1400 for configuring MT-SDT for a UE (e.g., UE 102) by transmitting interface messages to a CU-UP (e.g., CU-UP 172B of base station 104). This example method can be implemented by a CU-CP (e.g., CU-CP 172A of base station 104).

[0135] Method 1400 begins at block 1402, where the CU-CP and CU-UP initiate a CP-UP procedure to configure SDT for the UE. In some implementations, the CP-UP procedure is a bearer context modification procedure. At block 1404, the CU-CP includes a CP-to-UP message that includes at least one SDT configuration (e.g., event 404). At block 1406, the CU-CP determines whether the UE supports MT-SDT. If the CU-CP determines at block 1406 that the UE supports MT-SDT, the process proceeds to blocks 1408 and 1410. At block 1408, the CU-CP includes the MT-SDT information in the CP-to-UP message (e.g., event 404). At block 1410, the CU-CP transmits the CP-to-UP message to the CU-UP (e.g., event 404). Otherwise, if the CU-CP determines at block 1406 that the UE does not support MT-SDT, the process skips block 1408 and proceeds to block 1410. In some implementations, CU-CP avoids including MT-SDT information in the CP-to-UP message to skip box 1408.

[0136] Figure 15This is a flowchart of an example method 1500 for transmitting interface messages to a CU-CP (e.g., CU-CP 172A of base station 104) to indicate the arrival of DL data for a UE (e.g., UE 102), which can be implemented by a CU-UP (e.g., CU-UP 172B of base station 104).

[0137] Method 1500 begins at block 1502, where CU-UP and CU-CP perform a bearer context procedure for the UE to configure the UP bearer for SDT. In some implementations, the bearer context procedure is a bearer context modification procedure. In other implementations, the bearer context procedure is a bearer context setting procedure. In some implementations, the UP bearer is a DRB. At block 1504, CU-UP receives DL UP data associated with the UP bearer for the UE from the CN (e.g., event 410). At block 1506, CU-UP determines whether the UE has MT-SDT configured. If CU-UP determines at block 1506 that the UE has MT-SDT configured, the process proceeds to blocks 1508 and 1510. At block 1508, CU-UP includes the MT-SDT indication in the DL data notification message (e.g., event 412). At block 1510, CU-UP transmits the DL data notification message to the DU (e.g., event 412). Otherwise, if CU-UP determines at box 1506 that the UE is not configured with MT-SDT, the process skips box 1508 and proceeds to box 1510. In some implementations, CU-UP avoids including the MT-SDT indication in the DL data notification message to skip box 1508.

[0138] Figure 16A This is a flowchart of an example method 1600A for transmitting interface messages to a CU-CP (e.g., CU-CP 172A of base station 104) to indicate the arrival of DL data for a UE (e.g., UE 102), which can be implemented by a CU-UP (e.g., CU-UP 172B of base station 104).

[0139] Method 1600 begins at block 1602, where CU-UP and CU-CP perform at least one bearer context procedure for the UE to configure a first UP bearer and a second UP bearer. In some implementations, the at least one bearer context procedure includes a bearer context modification procedure and / or a bearer context setting procedure. In some implementations, the first UP bearer and the second UP bearer are DRBs. At block 1604, CU-UP and CU-CP perform a bearer context procedure for the UE to configure the first UP bearer for SDT (e.g., events 404, 406). In some implementations, "SDT" generally refers to MT-SDT and MO-SDT. MO-SDT may include RA-SDT and / or CG-SDT. In such cases, CU-UP and CU-CP do not perform a bearer context procedure for the UE to configure the second UP bearer for SDT. In other words, the second UP bearer is not configured for SDT.

[0140] At box 1606, the CU-UP receives DL UP data for the UE from the CN (e.g., event 410). At box 1608, the CU-UP determines whether the DL UP data is associated with a first UP bearer or a second UP bearer. If the CU-UP determines at box 1608 that the DL UP data is associated with the first UP bearer, the process proceeds to box 1610. At box 1610, the CU-UP includes an MT-SDT indication in the DL data notification message (e.g., event 412). At box 1612, the CU-UP transmits the DL data notification message to the DU (e.g., event 412). Otherwise, if the CU-UP determines at box 1608 that the DL UP data is not associated with the first UP bearer (i.e., the DL UP data is associated with the second UP bearer), the process skips box 1610 and proceeds to box 1612. The CU-UP skips box 1610 because it recognizes that the second UP bearer is configured for SDT. In some implementations, CU-UP avoids including the MT-SDT instruction in the DL data notification message to skip box 1610.

[0141] Figure 16BThis is a flowchart of an example method 1600B, similar to method 1600A, except that method 1600B includes block 1605 instead of block 1604. At block 1605, CU-UP and CU-CP perform a bearer context procedure for the UE to configure a first UP bearer for MT-SDT (e.g., events 404, 406). In some implementations, CU-UP does not perform a bearer context procedure for the UE to configure a second UP bearer for MT-SDT. In other words, the second UP bearer is not configured for MT-SDT. In such cases, the bearer context procedure at block 1605 can configure the second bearer for MT-SDT. Alternatively, CU-UP does not perform a bearer context procedure for the UE to configure the second UP bearer for MT-SDT. CU-UP skips block 1610 because CU-UP recognizes that the second UP bearer is configured for MT-SDT.

[0142] The following list of examples illustrates various embodiments explicitly contemplated in this disclosure.

[0143] 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 the CU of a distributed base station comprising a central unit (CU) and a distributed unit (DU), the method comprising: transmitting information from a control plane (CP) entity of the CU to a user plane (UP) entity of the CU, the information relating to the UE's ability to receive data when the UE is operating without an active radio connection to the RAN; and in response to determining that data is available for transmission to the UE operating without an active radio connection to the RAN, and based on the UE's capability, initiating transmission of the data to the UE at the CP entity of the CU.

[0144] Example 2. The method as described in Example 1, wherein the data is associated with Mobile Termination Small Data Transfer (MT-SDT).

[0145] Example 3. The method as described in Example 1 or 2, wherein determining that the data is available for transmission includes: receiving downlink (DL) data for the UE at the UP entity of the CU; and an indication to transmit the DL data from the UP entity of the CU to the CP entity of the CU.

[0146] Example 4. The method described in Example 3, wherein the data includes Internet Protocol (IP) packets.

[0147] Example 5. The method as described in Example 3, wherein the data includes Ethernet packets.

[0148] Example 6. The method as described in Example 3, wherein the data includes application groups.

[0149] Example 7. The method as described in Example 1 or 2, wherein the determination that the data can be used for transmission includes receiving DL data for the UE at the CP entity of the CU.

[0150] Example 8. The method as described in Example 7, wherein the data includes Non-Access Stratum (NAS) messages.

[0151] Example 9. The method as described in Example 7, wherein the data includes LTE Location Protocol (LPP) messages.

[0152] Example 10. The method as described in any of the preceding examples, wherein the transmission of the information related to the capabilities of the UE includes transmitting the information in a request to modify the bearer context for the UE.

[0153] Example 11. The method of Example 10 further includes including radio bearer information for small data transmission in the request.

[0154] Example 12. The method as described in Example 10 further includes providing the UE with configuration for MT-SDT via the DU.

[0155] Example 13. A method for managing transmissions from a RAN to a UE operating without an active radio connection to the RAN, the method being implemented in the CU of a distributed base station comprising a CU and a DU, the method comprising: detecting at the CU that data is available for transmission to the UE currently operating without an active radio connection to the RAN; and, in response to determining that the UE is capable of receiving the data, transmitting from the CU to another RAN node an indication that the RAN intends to transmit the data to the UE while the UE continues to operate without an active radio connection to the RAN.

[0156] Example 14. The method as described in Example 13, wherein the indication that the RAN wants to transmit the data includes an MT-SDT indication.

[0157] Example 15. The method as described in Example 13 or 14, wherein the other RAN node is the DU of the distributed base station.

[0158] Example 16. The method as described in Example 13 or 14, wherein the other RAN node is a peer base station operating in the RAN.

[0159] Example 17. The method of any one of Examples 13 to 16, wherein the indication that the RAN wants to transmit the data includes an MT-SDT indication.

[0160] Example 18. The method of any one of Examples 13 to 17, wherein the detection comprises: receiving the data at the CP entity of the CU.

[0161] Example 19. The method of any one of Examples 13 to 17, wherein the detection includes: receiving an indication from the UP entity of the CU that the UP entity has received the data at the CP entity.

[0162] Example 20. The method of any one of Examples 13 to 16, wherein transmitting the indication includes initiating a paging of the UE.

[0163] Example 22. A method for managing communication between a RAN and a UE operating without an active radio connection to the RAN, the method being implemented in the DU of a distributed base station comprising a CU and a DU, the method comprising: receiving an uplink message for the CU from the UE during a random access procedure associated with a resource set; including an indication of data communication when the UE has no active radio connection to the RAN in a DU-CU message when the resource set is configured to communicate data with the UE and the RAN without an active radio connection; and transmitting the DU-CU message to the CU.

[0164] Example 23. The method as described in Example 22, wherein the indication includes an SDT indication.

[0165] Example 24. The method as described in Example 23, wherein the SDT indication is an MO-SDT indication.

[0166] Example 25. The method as described in Example 23, wherein the SDT indication is an MT-SDT indication.

[0167] Example 26. The method of any one of Examples 22 to 25, wherein the UE operating without an active radio connection to the RAN operates in the RRC_INACTIVE state.

[0168] Example 27. The method of any one of Examples 22 to 25, wherein the UE operating without an active radio connection to the RAN operates in the RRC_IDLE state.

[0169] Example 28. A base station, comprising: a transceiver; and processing hardware configured to implement the method as described in any of the preceding examples.

[0170] The following additional considerations apply to the foregoing discussion.

[0171] In some implementations, paging records can be used instead of paging messages. In other implementations, a paging message may include one or more paging records, each paging record paging a specific UE. For example, a paging message may include a paging record for UE 102.

[0172] User devices in which the technologies of this disclosure can be implemented (e.g., UE 102) can be any suitable device capable of wireless communication, such as smartphones, tablet computers, laptop computers, mobile game consoles, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media streaming dongles or other personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, or broadband routers. Furthermore, in some cases, the user device can be embedded in electronic systems such as a vehicle's main unit or an advanced driver assistance system (ADAS). Even further, 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.

[0173] Some embodiments described in this disclosure include logic or multiple components or modules. A module can be a software module (e.g., code 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 particular manner. A hardware module may include a dedicated circuit system or logic permanently configured to perform certain operations (e.g., configured as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware module may also include programmable logic or circuit systems temporarily configured by software to perform certain operations (e.g., as contained within a general-purpose processor or other programmable processor). The decision to implement a hardware module with a dedicated and permanently configured circuit system or with a temporarily configured circuit system (e.g., configured by software) may be driven by cost and time considerations.

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

Claims

1. A method implemented in the CU of a distributed base station including a central unit (CU) and distributed units (DU), the method comprising: At the user plane UP entity CU-UP of the CU, a request to modify the bearer context for the user equipment UE is received from the control plane CP entity CU-CP of the CU. The request includes information related to the Mobile Termination Small Data Transmission (MT-SDT). At the CU-UP and while the radio connection between the UE and the radio access network RAN ​​is inactive, downlink DL data for the UE is received; and An indication for transmitting the DL data from the CU-UP to the CU-CP based on the information received from the CU-CP related to the MT-SDT, the indication including the MT-SDT indication.

2. The method of claim 1, wherein: The request to modify the bearer context for the UE includes SDT DRB information for configuring the data radio bearer DRB for the MT-SDT.

3. The method of claim 2, wherein: The bearer context includes the DRB for the MT-SDT and at least one non-SDT bearer.

4. The method of claim 2 or 3, further comprising: When the size of the DL data is less than or equal to the data volume threshold of the DRB, the MT-SDT is initiated to transmit the DL data.

5. The method according to any one of claims 2 to 4, further comprising: The MT-SDT for transmitting the DL data is determined based on the identifier of the DRB.

6. The method as described in any of the preceding claims, wherein: The request to modify the bearer context for the UE includes a suspension indication for indicating that the bearer context of the UE is suspended.

7. The method as described in any of the preceding claims, wherein: The request to modify the bearer context for the UE includes a bearer context modification request message.

8. The method as described in any of the preceding claims, further comprising: At the CU-UP, it is determined that the UE is configured for the MT-SDT.

9. The method of claim 8, wherein: The determination that the UE is configured for the MT-SDT is based on the information related to the MT-SDT received from the CU-CP.

10. The method as described in any of the preceding claims, further comprising: The MT-SDT for transmitting the DL data is determined based on the Packet Data Unit (PDU) session associated with the DL data.

11. The method as described in any of the preceding claims, further comprising: The MT-SDT for transmitting the DL data is determined based on the Quality of Service (QoS) flow associated with the DL data.

12. The method as described in any of the preceding claims, wherein: The MT-SDT indication is a first MT-SDT indication; The method further includes: A message including a second MT-SDT indication is transmitted to the DU.

13. The method of claim 12, wherein the message indicated by the second MT-SDT is a request to page the UE.

14. The method of claim 12 or 13, wherein: The transmission including the message of the second MT-SDT indication is in response to determining that the UE supports the MT-SDT.

15. A base station including processing hardware and configured to implement the method as described in any of the preceding claims.

Images