EP4420458A1

EP4420458A1 - Small data transmission techniques

Info

Publication number: EP4420458A1
Application number: EP22884444.5A
Authority: EP
Inventors: Jaemin HAN; Marta Martinez TARRADELL; Youn Hyoung Heo; Ansab ALI; Sudeep Palat
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2021-10-21
Filing date: 2022-10-20
Publication date: 2024-08-28
Also published as: WO2023069568A1

Abstract

Embodiments attempt to solve challenges in a small data transmission (SDT) system. Embodiments describe various techniques, systems, and devices to support small data transfers in a 3GPP 5G NR system, among other wireless communications systems. Other embodiments are described and claimed.

Description

SMALL DATA TRANSMISSION TECHNIQUES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of and priority to previously filed United States Provisional Patent Application Serial Number 63/270,363, filed October 21, 2021, entitled “SMALL DATA TRANSMISSION INFORMATION EXCHANGE BETWEEN NG RAN NODES”, and previously filed United States Provisional Patent Application Serial Number 63/270,426, filed October 21, 2021, entitled “SMALL DATA TRANSMISSION SIGNALING SUPPORT FOR NO ANCHOR RELOCATION”, which are hereby incorporated by reference in their entireties.

BACKGROUND

[0002] Wireless communication systems are rapidly growing in usage. Further, wireless communication technology has evolved from voice-only communications to also include the transmission of data, such as Internet and multimedia content, to a variety of devices. To accommodate a growing number of devices communicating, many wireless communication systems share the available communication channel resources among devices. Further, Internet-of-Thing (loT) devices are also growing in usage and can coexist with user devices in various wireless communication systems such as cellular networks.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0003] To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0004] FIG. 1 illustrates a wireless communication system in accordance with one embodiment.

[0005] FIG. 2 illustrates second wireless communications system in accordance with one embodiment.

[0006] FIG. 3A illustrates a first message flow in according with one embodiment.

[0007] FIG. 3B illustrates a second message flow in accordance with one embodiment.

[0008] FIG. 4 illustrates a first logic flow in accordance with one embodiment.

[0009] FIG. 5 illustrates a third message flow in accordance with one embodiment.

[0010] FIG. 6 illustrates an apparatus in accordance with one embodiment.

[0011] FIG. 7 illustrates a second logic flow in accordance with one embodiment. [0012] FIG. 8 illustrates a fourth message flow in accordance with one embodiment.

[0013] FIG. 9 illustrates a third logic flow in accordance with one embodiment.

[0014] FIG. 10 illustrates a fifth message flow in accordance with one embodiment.

[0015] FIG. 11 illustrates a first network in accordance with one embodiment.

[0016] FIG. 12 illustrates a second network in accordance with one embodiment.

[0017] FIG. 13 illustrates a third network in accordance with one embodiment.

[0018] FIG. 14 illustrates a computer readable storage medium in accordance with one embodiment.

DETAILED DESCRIPTION

[0019] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrases “A or B” and “A/B” mean (A), (B), or (A and B).

[0020] In many wireless communication systems, including long-term evolution (LTE) and fifth generation new radio (5G NR) cellular networks, a user equipment (UE) may need to transmit a small amount of data to a base station (BS) within the network. This is referred to as a small data transmission (SDT). For example, in a Cellular Internet of Things (CIoT), a sensor device equipped with a communication device such as a user equipment (UE) can take a sensor reading and then transmit the reading, or a batch of readings, to the BS. Other examples include tracking devices for Mobile Originated (MO) and Mobile Terminated (MT) use cases that report positions via a BS. The present disclosure describes, among other things, signaling mechanisms to support frequent small data transmission with and without path switching between different base stations.

[0021] A 5G NR system may be defined, at least in part, by various Third Generation Partnership Project (3GPP) Technical Standards (TS), Technical Reports (TR) and/or Work Items (WI). Various embodiments discussed herein may be implemented in a wireless communications system as defined by the 3GPP TS 38.473 titled “Technical Specification Group Radio Access Network; NG-RAN; Fl application protocol (F1AP),” Release 17.0.0, April 2020; and 3GPP TS 38.423 titled “Technical Specification Group Radio Access Network; NG-RAN; Xn application protocol (XnAP),” Release 17.0.0, April 2020 and Release 17.1.0, June 2020; both including any progeny, revisions or variants. It may be appreciated that the embodiments may be implemented in accordance with other 3GPP TS and TR, as well as other wireless standards released by other standards entities. Embodiments are not limited in this context.

[0022] In a 5G NR system, such as defined by 3GPP TS 38.473 and/or TS 28.423, a UE can enter different radio resource control (RRC) states, such as an idle state and a connected state. The UE can also enter an inactive state where the UE is registered with the network but not actively transmitting data. A resume procedure can prepare a UE for subsequent data transmission by causing the UE to switch from an inactive state to a connected state. In 5G NR, the RRC states for a 5G NR enabled UE can include RRC IDLE, RRC_INACTIVE, and RRC_CONNECTED states. When not transmitting data in a RRC_CONNECTED state, the UE can switch to a RRC_INACTIVE state but remain registered with the network.

[0023] Whenever a UE is in an RRC_INACTIVE state, it must switch to an RRC_CONNECTED state for data communications. However, this design introduces some inefficiencies, particularly for small or infrequent data that does not merit resuming a connection. To solve this challenge, various 3GPP standards allow a UE to perform a SDT when in an RRC_INACTIVE state without having to switch to an RRC_CONNECTED state. An STD-enabled UE may initiate a SDT by sending an RRC resume request message. The SDT is terminated when the UE is directed to a RRC IDLE state or an RRC_INACTIVE state (e.g., via an RRCRelease message), or when the UE is directed to an RRC_CONNECTED state (e.g., via an RRCResume message or an RRCSetup message).

Initial UL SDT data is multiplexed with the RRC resume request message, and during a SDT, there could be several UL/DL SDT data exchanges.

[0024] Allowing a UE to perform a SDT while in an inactive state (e.g., an RRC_INACTIVE state), however, poses a new set of challenges, particularly when an access node, such as a gNodeB (gNB) or eNodeB (eNB) implements a split next generation radio access network (NG-RAN) architecture. A NG-RAN system can implement a gNB split-architecture where a gNB is separated into multiple physical entities or nodes, such as a gNB distributed unit (gNB-DU) and a gNB central unit (gNB-CU), each performing a different set of operations or procedures. When a UE sends a resume request (e.g., via an RRCResume message), it is received by a gNB-DU. The gNB-DU may forward the resume request to a gNB-CU in order to notify the gNB-CU that the UE is requesting to resume a connection due to SDT. Currently, the 3GPP standards do not define a standardized way for the gNB-DU to communicate to the gNB-CU that the resume request is due to a SDT.

[0025] Embodiments attempt to solve these and other SDT-related challenges. Embodiments describe various techniques, systems, and devices to support small data transfers in a 3GPP 5G NR system, among other wireless communications systems. In one embodiment, for example, an apparatus for an access node, such as a gNB or an eNB, may include a memory interface to send or receive, to or from a data storage device, SDT information for SDT signaling between a gNB-DU and a gNB-CU of a 3GPP radio access network (RAN). The apparatus also includes processor circuitry communicatively coupled to the memory interface, the processor circuitry to decode that a RRC resume request message received from a UE in an inactive state is due to SDT by the gNB-DU. The RRC resume request message may include an SDT indication or other SDT information. The processor circuitry may generate an initial uplink (UL) RRC message transfer message, the initial UL RRC message transfer message to include an information element (IE) with one or more parameters to indicate the RRC resume request is due to the SDT information. The processor circuitry may send an indication to transmit the initial UL RRC message transfer message from the gNB-DU to the gNB-CU, where the initial UL RRC message transfer message indicates a transfer of the RRC resume request message to the gNB-CU. Note the SDT can be in an UL direction, downlink (DL) direction, or both directions. Other embodiments are described and claimed.

[0026] Another SDT challenge for a split NG-RAN architecture is communicating lower layer SDT configuration information for a UE between a gNB-CU and a gNB-DU before the gNB-CU sends the UE back to an RRC_INACTIVE state. A gNB-CU may grant a UE one or more “free” Physical Uplink Shared Channel (PUSCH) resources to initiate a SDT without a Random Access Channel (RACH). The free grant is defined by a configured grant (CG), and the CG is configured for the UE via an RRCRelease message from a last serving cell for the UE. The resources indicated by the CG are only valid when the UE is in a same serving cell, which means that the UE can only initiate a SDT toward the same serving cell in which it was moved to an RRC_INACTIVE state.

[0027] In a split NG-RAN architecture, the gNB-DU governs lower layers for a UE, such as a medium access control (MAC) layer and/or a physical (PHY) layer (collectively referred to as MAC/PHY) configuration information for the UE. The gNB-DU manages and allocates scheduling resources for a UE operating a SDT. The gNB-CU governs radio bearers (RB) configuration information as well as a decision for SDT by a UE. Prior to making a decision for SDT by a UE, the gNB-CU needs the MAC/PHY configuration information for the UE from the gNB-DU in order to generate an RRCRelease message with a CG for the UE. Currently, the 3GPP standards do not define a standardized way for the gNB-CU and the gNB-DU to communicate MAC/PHY configuration information for a UE to perform SDT operations. This challenge may also be applicable to a RACH-based SDT or any other type of SDT operation.

[0028] Embodiments attempt to solve these and other SDT-related challenges. Embodiments describe various techniques, systems, and devices to support small data transfers in a 3GPP 5G NR system, among other wireless communications systems. In one embodiment, for example, an apparatus for an access node, such as a gNB or an eNB, may include a memory interface to send or receive, to or from a data storage device, SDT information for SDT signaling between a gNB-DU and a gNB-CU of a 3GPP RAN. The apparatus may also include a processor circuitry communicatively coupled to the memory interface, the processor circuitry to determine to modify UE context information for a UE by the gNB-CU of the RAN, generate a UE context modification request message to provide the modified UE context information to the gNB-DU of the RAN, the UE context modification request message to include an IE with one or more parameters to indicate a request for configuration information of the UE for SDT operation from the gNB-DU, and send an indication to transmit the UE context modification request message from the gNB- CU to the gNB-DU. The configuration information may include media access control (MAC) and/or physical (PHY) layer information needed for a configuration grant (CG) based SDT for the UE. Note the SDT can be in an UL direction, downlink (DL) direction, or both directions. Other embodiments are described and claimed.

[0029] Another challenge for a 5G NR system is for a UE to maintain SDT capabilities when the UE is handover (HO) between different serving cells. Various 3GPP standards are considering a RACH-based and/or CG-based (e.g., a configured grant type-1) for SDT. A RACH-based SDT allows a UE to initiate a SDT session when the UE is HO to a new RAN node such as a gNB (referred to as a “new RAN node” or a “new gNB") from a last serving RAN node such as a gNB (referred to as an “old RAN node” or an “old gNB” or “anchor gNB”). In this case, context information for the UE can be relocated to the new gNB or remain in the old gNB, which is up to the old gNB to decide. When the context information for the UE is not relocated to the new gNB, information signaling and interactions (e.g., messages) may be similar to legacy situations, such as when a UE is supported for periodic RAN notification area (RNA) updates. However, SDT may need different information signaling and interactions between the new gNB and the old gNB. Currently, the 3GPP standards do not define a standardized way for the old gNB and the new gNB to communicate information necessary for a UE to perform SDT operations when operating in the new gNB when the context information is not relocated from the old gNB to the new gNB.

[0030] Embodiments attempt to solve these and other SDT-related challenges. Embodiments describe various techniques, systems, and devices to support small data transfers in a 3GPP 5G NR system, among other wireless communications systems. In one embodiment, for example, an apparatus for an access node, such as gNB or an eNB, includes a memory interface to send or receive, to or from a data storage device, SDT information for SDT signaling between a first node and a second node of a 3GPP RAN. The apparatus may also include a processor circuitry communicatively coupled to the memory interface, the processor circuitry to decode a retrieve UE context request message received from a first node of a RAN by a second node of the RAN, the retrieve UE context request message to include the SDT information, generate a retrieve UE context request response message by the second node of the RAN, the retrieve UE context request response message to include an IE with one or more parameters to represent partial context information related to SDT for the UE, and send an indication to transmit the retrieve UE context request response message from the second node to the first node. Note the SDT can be in an UL direction, downlink (DL) direction, or both directions. Other embodiments are described and claimed.

[0031] Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. However, the novel embodiments can be practiced without these specific details. In other instances, well known structures and devices are shown in block diagram form in order to facilitate a description thereof. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject matter. [0032] FIG. 1 illustrates an example of a wireless communication wireless communications system 100. For purposes of convenience and without limitation, the example wireless communications system 100 is described in the context of the long-term evolution (LTE) and fifth generation (5G) new radio (NR) (5G NR) cellular networks communication standards as defined by one or more 3GPP technical specifications (TSs) and/or technical reports (TRs). However, other types of wireless standards are possible. [0033] The wireless communications system 100 includes UE 102a and UE 102b (collectively referred to as the "UEs 102"). In this example, the UEs 102 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks). In other examples, any of the UEs 102 can include other mobile or non-mobile computing devices, such as consumer electronics devices, cellular phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), pagers, wireless handsets, desktop computers, laptop computers, in- vehicle infotainment (IVI), in-car entertainment (ICE) devices, an Instrument Cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), Electronic Engine Management System (EEMS), electronic/engine control units (ECUs), electronic/engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or "smart" appliances, machine-type communications (MTC) devices, machine-to-machine (M2M) devices, Internet of Things (loT) devices, or combinations of them, among others.

[0034] In some implementations, any of the UEs 102 may be loT UEs, which can include a network access layer designed for low-power loT applications utilizing short-lived UE connections. An loT UE can utilize technologies such as M2M or MTC for exchanging data with an MTC server or device using, for example, a public land mobile network (PLMN), proximity services (ProSe), device-to-device (D2D) communication, sensor networks, loT networks, or combinations of them, among others. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An loT network describes interconnecting loT UEs, which can include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The loT UEs may execute background applications (e.g., keep-alive messages or status updates) to facilitate the connections of the loT network.

[0035] The UEs 102 are configured to connect (e.g., communicatively couple) with a radio access network (RAN) 112. In some implementations, the RAN 112 may be a next generation RAN (NG RAN), an evolved UMTS terrestrial radio access network (E- UTRAN), or a legacy RAN, such as a UMTS terrestrial radio access network (UTRAN) or a GSM EDGE radio access network (GERAN). As used herein, the term "NG RAN" may refer to a RAN 112 that operates in a 5G NR wireless communications system 100, and the term "E-UTRAN" may refer to a RAN 112 that operates in an LTE or 4G wireless communications system 100.

[0036] To connect to the RAN 112, the UEs 102 utilize connections (or channels) 118 and 120, respectively, each of which can include a physical communications interface or layer, as described below. In this example, the connections 118 and 120 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a global system for mobile communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a push-to-talk (PTT) protocol, a PTT over cellular (POC) protocol, a universal mobile telecommunications system (UMTS) protocol, a 3GPP LTE protocol, a 5G NR protocol, or combinations of them, among other communication protocols.

[0037] The UE 102b is shown to be configured to access an access point (AP) 104 (also referred to as "WLAN node 104," "WLAN 104," "WLAN Termination 104," "WT 104" or the like) using a connection 122. The connection 122 can include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, in which the AP 104 would include a wireless fidelity (Wi-Fi) router. In this example, the AP 104 is shown to be connected to the Internet without connecting to the core network of the wireless system, as described in further detail below.

[0038] The RAN 112 can include one or more nodes such as RAN nodes 106a and 106b (collectively referred to as "RAN nodes 106" or "RAN node 106") that enable the connections 118 and 120. As used herein, the terms "access node," "access point," or the like may describe equipment that provides the radio baseband functions for data or voice connectivity, or both, between a network and one or more users. These access nodes can be referred to as base stations (BS), gNodeBs, gNBs, eNodeBs, eNBs, NodeBs, RAN nodes, rode side units (RSUs), transmission reception points (TRxPs or TRPs), and the link, and can include ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell), among others. As used herein, the term "NG RAN node" may refer to a RAN node 106 that operates in an 5G NR wireless communications system 100 (for example, a gNB), and the term "E-UTRAN node" may refer to a RAN node 106 that operates in an LTE or 4G wireless communications system 100 (e.g., an eNB). In some implementations, the RAN nodes 106 may be implemented as one or more of a dedicated physical device such as a macrocell base station, or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0039] In some implementations, some or all of the RAN nodes 106 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a cloud RAN (CRAN) or a virtual baseband unit pool (vBBUP). The CRAN or vBBUP may implement a RAN function split, such as a packet data convergence protocol (PDCP) split in which radio resource control (RRC) and PDCP layers are operated by the CRAN/vBBUP and other layer two (e.g., data link layer) protocol entities are operated by individual RAN nodes 106; a medium access control (MAC)/physical layer (PHY) split in which RRC, PDCP, MAC, and radio link control (RLC) layers are operated by the CRAN/vBBUP and the PHY layer is operated by individual RAN nodes 106; or a "lower PHY" split in which RRC, PDCP, RLC, and MAC layers and upper portions of the PHY layer are operated by the CRAN/vBBUP and lower portions of the PHY layer are operated by individual RAN nodes 106. This virtualized framework allows the freed-up processor cores of the RAN nodes 106 to perform, for example, other virtualized applications. In some implementations, an individual RAN node 106 may represent individual gNB distributed units (DUs) that are connected to a gNB central unit (CU) using individual Fl interfaces (not shown in FIG. 1). In some implementations, the gNB-DUs can include one or more remote radio heads or RFEMs, and the gNB-CU may be operated by a server that is located in the RAN 112 (not shown) or by a server pool in a similar manner as the CRAN/vBBUP. Additionally or alternatively, one or more of the RAN nodes 106 may be next generation eNBs (ng-eNBs), including RAN nodes that provide E-UTRA user plane and control plane protocol terminations toward the UEs 102, and are connected to a 5G core network (e.g., core network 114) using a next generation interface.

[0040] In vehicle-to-everything (V2X) scenarios, one or more of the RAN nodes 106 may be or act as RSUs. The term "Road Side Unit" or "RSU" refers to any transportation infrastructure entity used for V2X communications. A RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where a RSU implemented in or by a UE may be referred to as a "UE-type RSU," a RSU implemented in or by an eNB may be referred to as an "eNB-type RSU," a RSU implemented in or by a gNB may be referred to as a "gNB-type RSU," and the like. In some implementations, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs 102 (vUEs 102). The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications or other software to sense and control ongoing vehicular and pedestrian traffic. The RSU may operate on the 5.9 GHz Direct Short Range Communications (DSRC) band to provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low latency communications, as well as other cellular communications services. Additionally or alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) or provide connectivity to one or more cellular networks to provide uplink and downlink communications, or both. The computing device(s) and some or all of the radiofrequency circuitry of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and can include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network, or both.

[0041] Any of the RAN nodes 106 can terminate the air interface protocol and can be the first point of contact for the UEs 102. In some implementations, any of the RAN nodes 106 can fulfill various logical functions for the RAN 112 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. [0042] In some implementations, the UEs 102 can be configured to communicate using orthogonal frequency division multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 106 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, OFDMA communication techniques (e.g., for downlink communications) or SC-FDMA communication techniques (e.g., for uplink communications), although the scope of the techniques described here not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

[0043] The RAN nodes 106 can transmit to the UEs 102 over various channels. Various examples of downlink communication channels include Physical Broadcast Channel (PBCH), Physical Downlink Control Channel (PDCCH), and Physical Downlink Shared Channel (PDSCH). Other types of downlink channels are possible. The UEs 102 can transmit to the RAN nodes 106 over various channels. Various examples of uplink communication channels include Physical Uplink Shared Channel (PUSCH), Physical Uplink Control Channel (PUCCH), and Physical Random Access Channel (PRACH). Other types of uplink channels are possible. [0044] In some implementations, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 106 to the UEs 102, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

[0045] The PDSCH carries user data and higher-layer signaling to the UEs 102. The PDCCH carries information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 102 about the transport format, resource allocation, and hybrid automatic repeat request (HARQ) information related to the uplink shared channel. Downlink scheduling (e.g., assigning control and shared channel resource blocks to the UE 102b within a cell) may be performed at any of the RAN nodes 106 based on channel quality information fed back from any of the UEs 102. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the UEs 102.

[0046] The PDCCH uses control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a subblock interleaver for rate matching. In some implementations, each PDCCH may be transmitted using one or more of these CCEs, in which each CCE may correspond to nine sets of four physical resource elements collectively referred to as resource element groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. In LTE, there can be four or more different PDCCH formats defined with different numbers of CCEs (e.g., aggregation level, L=l, 2, 4, or 8). [0047] Some implementations may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some implementations may utilize an enhanced PDCCH (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced CCEs (ECCEs). Similar to above, each ECCE may correspond to nine sets of four physical resource elements collectively referred to as an enhanced REG (EREG). An ECCE may have other numbers of EREGs.

[0048] The RAN nodes 106 are configured to communicate with one another using an interface 132. In examples, such as where the wireless communications system 100 is an LTE system (e.g., when the core network 114 is an evolved packet core (EPC) network), the interface 132 may be an X2 interface 132. The X2 interface may be defined between two or more RAN nodes 106 (e.g., two or more eNBs and the like) that connect to the EPC 114, or between two eNBs connecting to EPC 114, or both. In some implementations, the X2 interface can include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide flow control mechanisms for user data packets transferred over the X2 interface, and may be used to communicate information about the delivery of user data between eNBs. For example, the X2-U may provide specific sequence number information for user data transferred from a master eNB to a secondary eNB; information about successful in sequence delivery of PDCP protocol data units (PDUs) to a UE 102 from a secondary eNB for user data; information of PDCP PDUs that were not delivered to a UE 102; information about a current minimum desired buffer size at the secondary eNB for transmitting to the UE user data, among other information. The X2-C may provide intra- LTE access mobility functionality, including context transfers from source to target eNBs or user plane transport control; load management functionality; inter-cell interference coordination functionality, among other functionality.

[0049] In some implementations, such as where the wireless communications system 100 is a 5G NR system (e.g., when the core network 114 is a 5G core network), the interface 132 may be an Xn interface 132. The Xn interface may be defined between two or more RAN nodes 106 (e.g., two or more gNBs and the like) that connect to the 5G core network 114, between a RAN node 106 (e.g., a gNB) connecting to the 5G core network 114 and an eNB, or between two eNBs connecting to the 5G core network 114, or combinations of them. In some implementations, the Xn interface can include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support/provide data forwarding and flow control functionality. The Xn-C may provide management and error handling functionality, functionality to manage the Xn-C interface; mobility support for UE 102 in a connected mode (e.g., CM- CONNECTED) including functionality to manage the UE mobility for connected mode between one or more RAN nodes 106, among other functionality. The mobility support can include context transfer from an old (source) serving RAN node 106 to new (target) serving RAN node 106, and control of user plane tunnels between old (source) serving RAN node 106 to new (target) serving RAN node 106. A protocol stack of the Xn-U can include a transport network layer built on Internet Protocol (IP) transport layer, and a GPRS tunneling protocol for user plane (GTP-U) layer on top of a user datagram protocol (UDP) or IP layer(s), or both, to carry user plane PDUs. The Xn-C protocol stack can include an application layer signaling protocol (referred to as Xn Application Protocol (Xn-AP or XnAP)) and a transport network layer (TNL) that is built on a stream control transmission protocol (SCTP). The SCTP may be on top of an IP layer, and may provide the guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver the signaling PDUs. In other implementations, the Xn-U protocol stack or the Xn-C protocol stack, or both, may be same or similar to the user plane and/or control plane protocol stack(s) shown and described herein.

[0050] The RAN 112 is shown to be communicatively coupled to a core network 114 (referred to as a "CN 114"). The CN 114 includes multiple network elements, such as network element 108a and network element 108b (collectively referred to as the "network elements 108"), which are configured to offer various data and telecommunications services to customers/subscribers (e.g., users of UEs 102) who are connected to the CN 114 using the RAN 112. The components of the CN 114 may be implemented in one physical node or separate physical nodes and can include components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some implementations, network functions virtualization (NFV) may be used to virtualize some or all of the network node functions described here using executable instructions stored in one or more computer-readable storage mediums, as described in further detail below. A logical instantiation of the CN 114 may be referred to as a network slice, and a logical instantiation of a portion of the CN 114 may be referred to as a network sub-slice. NFV architectures and infrastructures may be used to virtualize one or more network functions, alternatively performed by proprietary hardware, onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches. In other words, NFV systems can be used to execute virtual or reconfigurable implementations of one or more network components or functions, or both. [0051] An application server 110 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS packet services (PS) domain, LTE PS data services, among others). The application server 110 can also be configured to support one or more communication services (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, among others) for the UEs 102 using the CN 114. The application server 110 can use an IP communications interface 130 to communicate with one or more network elements 108a.

[0052] In some implementations, the CN 114 may be a 5G core network (referred to as "5GC 114" or "5G core network 114"), and the RAN 112 may be connected with the CN 114 using a next generation interface 124. In some implementations, the next generation interface 124 may be split into two parts, a next generation user plane (NG-U) interface 114, which carries traffic data between the RAN nodes 106 and a user plane function (UPF), and the SI control plane (NG-C) interface 126, which is a signaling interface between the RAN nodes 106 and access and mobility management functions (AMFs). Examples where the CN 114 is a 5G core network are discussed in more detail with regard to later figures.

[0053] In some implementations, the CN 114 may be an EPC (referred to as "EPC 114" or the like), and the RAN 112 may be connected with the CN 114 using an SI interface 124. In some implementations, the SI interface 124 may be split into two parts, an SI user plane (Sl-U) interface 128, which carries traffic data between the RAN nodes 106 and the serving gateway (S-GW), and the Sl-MME interface 126, which is a signaling interface between the RAN nodes 106 and mobility management entities (MMEs).

[0054] As previously discussed, in some implementations, an individual RAN node 106 may be implemented as a gNB split-architecture comprising multiple gNB-DUs that are connected to a gNB-CU using individual Fl interfaces. An example of a gNB splitarchitecture for a RAN node 106 is shown in FIG. 2.

[0055] FIG. 2 illustrates a wireless communications system 200. The wireless communications system 200 is a sub-system of the wireless communications system 100 illustrated in FIG. 1. The wireless communications system 200 depicts a UE 202 connected to a gNB 204 over a connection 212. The UE 202 and connection 212 are similar to the UE 102 and the connections 118, 120 described with reference to FIG. 1. The gNB 204 is similar to the RAN node 106, and represents an implementation of the RAN node 106 as a gNB with a split-architecture.

[0056] As depicted in FIG. 2, the gNB 204 is divided into two physical entities referred to a centralized or central unit (CU) and a distributed unit (DU). The gNB 204 may comprise a gNB-CU 214 and one or more gNB-DU 210. The gNB-CU 214 is further divided into a gNB-CU control plane (gNB-CU-CP) 206 and a gNB-CU user plane (gNB-CU-UP) 208. The gNB-CU-CP 206 and the gNB-CU-UP 208 communicate over an El interface. The gNB-CU-CP 206 communicates with one or more gNB-DU 210 over an Fl-C interface. The gNB-CU-UP 208 communicates with the one or more gNB-DU 210 over an Fl-U interface.

[0057] The gNB-CU-CP 206 and the gNB-CU-UP 208 provides support for higher layers of a protocol stack such as Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP) and RRC. The gNB-DU 210 provides support for lower layers of the protocol stack such as Radio Fink Control (RLC), MAC layer, and PHY layer. In some implementations, there is a single gNB-CU 214 for each gNB 204 that controls multiple gNB-DU 210. For example, the gNB 204 may have more than 100 gNB-DU 210 connected to a single gNB-CU 214. Each gNB-DU 210 is able to support one or more cells, where one gNB 204 can potentially control hundreds of cells in a 5G NR system.

[0058] As previously discussed, in a 5G NR system, such as defined by 3GPP TS 38.473 and/or TS 28.423, the UE 202 can enter different RRC states, such as an idle state and a connected state. The UE 202 can also enter an inactive state where the UE 202 is registered with the network but not actively transmitting data. A resume procedure can prepare the UE 202 for subsequent data transmission by causing the UE 202 to switch from an inactive state to a connected state. In 5G NR, the RRC states for a 5G NR enabled UE can include RRC IDLE, RRC_IN ACTIVE, and RRC_CONNECTED states. When not transmitting data in a RRC_CONNECTED state, the UE 202 can switch to a RRC_INACTIVE state but remain registered with the network. An example of the UE 202 implementing a resume procedure when switching to a connected state is described with reference to FIG. 3A.

[0059] FIG. 3A illustrates a message flow 300a that provides an example of a resume procedure for a small data transmission (SDT) with the UE 202 entering a RRC_CONNECTED state prior to SDT operations. In the message flow 300a, a wireless system includes the UE 202, multiple RAN nodes such as a new RAN 302 and an old RAN 304, and a device providing a UPF 306. From time to time, the UE 202 may need to transmit a small amount of data, referred to in 3GPP as a SDT. In this example, a context for the UE 202 is stored at the old RAN 304, which is referred to as an "anchor” for the UE 202. The UE 202 starts to communicate with a new RAN 302 when in the RRCJNACTIVE state 308. The UE 202, in the RRCJNACTIVE state 308, sends a message 310 to the new RAN 302. The message 310 may comprise an RRC resume request message to the new RAN 302. At block 312, the new RAN 302 and the old RAN 304 perform a UE context retrieval and forward tunnel establishment procedure. The new RAN 302 sends a message 314 to the UE 202. The message 314 may comprise an RRC resume message. The RRC resume message causes the UE 202 to enter the RRC_CONNECTED state 316. The UE 202 starts sending one or more messages 318 to the UPF 306. The messages 318 may comprise SDT messages. At block 320, the UE 202 and new RAN 302 performs a connection inactive procedure. A connection inactive procedure can include causing the UE 202 to switch back to a RRC_IN ACTIVE state 308. For subsequent SDT, the UE 202 may initiate a SDT session by sending a message 322 to the new RAN 302. The message 322 may comprise an RRC resume request message.

[0060] As indicated in the message flow 300a of FIG. 3A, whenever the UE 202 is in an RRC_INACTIVE state, it must switch to an RRC_CONNECTED state for a SDT.

However, this design introduces some inefficiencies, particularly for small or infrequent data that does not merit resuming a connection. To solve this challenge, various 3GPP standards allow the UE 202 to perform a SDT when in an RRC_INACTIVE state without necessarily having to switch to an RRC_CONNECTED state. When the UE 202 is an STD- enabled UE, the UE 202 may initiate a SDT by sending an RRC resume request message. The SDT is terminated when the UE 202 is directed to a RRC IDLE state or an RRC_INACTIVE state (e.g., via an RRCRelease message), or when the UE 202 is directed to an RRC_CONNECTED state (e.g., via an RRCResume message or an RRCSetup message). Initial UL SDT data is multiplexed with the RRC resume request message, and during a SDT, there could be several UL/DL SDT data exchanges. An example of the UE 202 implementing a resume procedure without switching to a connected state is described with reference to FIG. 3B.

[0061] FIG. 3B illustrates a message flow 300b that provides an example of a resume procedure for a small data transmission (SDT) without the UE 202 entering a RRC_CONNECTED state prior to SDT operations. As previously discussed, a RACH- based SDT allows the UE 202 to initiate an SDT session on a new gNB 324 which is a gNB other than the old gNB 326 (e.g., the anchor gNB). The UE context can be relocated to the new gNB 324 or kept in the old gNB 326, which is up to the old gNB 326 to decide. The message flow 300b depicts a signaling flow for the case where the old gNB 326 decides to relocate the context for the UE 202 to the new gNB 324. More particularly, the message flow 300b provides an example of a RACH based SDT with anchor relocation procedure, as defined by various 3GPP standards, such as 3GPP TS 38.423 and TS 38.300, among other 3GPP and non-3GPP standards.

[0062] In the message flow 300b, a wireless system includes the UE 202, multiple RAN nodes implemented as gNB nodes, such as a new gNB 324 and an old gNB 326, and a device providing an Access and Mobility management Function (AMF) 328. From time to time, the UE 202 may need to transmit a small amount of data, referred to in 3GPP as a SDT. In this example, a context for the UE 202 is stored at the old gNB 326, which is referred to as an "anchor” for the UE 202.

[0063] The message flow 300b illustrates an example of a message exchange initiated by a RRC resume request containing a small data indication. In some implementations, the messages can be implemented as XnAP messages which are generated and transmitted based on 3GPP TS 38.423, among other 3GPP and non-3GPP standards.

[0064] In this example, the UE 202 sends a small data indication to the new gNB 324, where the old gNB 326 provides a RRC release configuration or message to the new gNB 324 via a context retrieval procedure. The UE 202 indicates its small data intention during a resume procedure. In block 330, the UE 202, in the RRC_INACTIVE state, sends a message 332 as an RRC resume request message to the new gNB 324. The RRC resume request message is communicated over SRB0, and it includes a small data indication with UL SDT data.

[0065] At block 334, the new gNB 324 determines that initial UL SDT data is for the old gNB 326. The new gNB 324 communicates the small data indication in message 336 to the old gNB 326 via an XnAP message, which accordingly includes a small data indication. The old gNB 326 can send a message 338 as an XnAP retrieve UE context request message. The old gNB 326 can determine whether to relocate the anchor or not. The anchor is when a path switch is triggered from the new gNB 324 as the normal UE 202 triggered transmission from RRC_INACTIVE to RRC_CONNECTED scenario as described in 3GPP TS 38.300, Section 9.2.2.4.I.

[0066] After receiving the XnAP retrieve UE context request message, the old gNB 326 can determine whether to relocate the anchor for the UE 202 and send a message 338 as an XnAP retrieve UE context response message to the new gNB 324. The new gNB 324 sends a message 340 with the initial UL SDT data to the UPF 358.

[0067] The new gNB 324 also sends a message 342 with an Xn-U address indication to the old gNB 326. In some implementations, the new gNB 324 sends a XnAP DL data forwarding address indication message to the old gNB 326 as legacy. The legacy already provides a UL NG user plane interface (NG-U) transport network layer (TNL) at user plane function (UPF) to the new gNB 324 via the XnAP retrieve UE context response message, which means that UL data does not have to go through the old gNB 326.

[0068] At block 344, the UPF 358 and the UE 202 perform a procedure for DL SDT data forwarding. The new gNB 324 sends a message 346 as a path switch request message to the AMF 328. In response, the AMF 328 sends a message 348 as a path switch request acknowledge message to the new GNB 324. At block 350, the UPF 358 and the UE 202 perform a procedure for DL SDT data forwarding. At block 352, the new gNB 324 terminates the SDT session. The new GNB 324 sends a message 354 as an RRC release message (e.g., RRCRelease) or an RRC resume message (e.g., RRCResume) to the UE 202. The new gNB 324 then sends a message 356 as a UE context release message to the AMF 328.

[0069] As discussed with reference to the message flow 300a, a NR RRC_INACTIVE procedure has been designed that a UE 202 should resume connection for any data transmission with a network node. This design, however, introduces some inefficiency, especially for small or infrequent data that does not merit a connection resume. To this end, the 3GPP standards body has a Small Data Transmission (SDT) WI (e.g., Release 17) to allow small data transfer during RRC_INACTIVE without entering RRC_CONNECTED, as depicted in the message flow 300b. A SDT is initiated by any SDT-capable UE 202 by sending a RRC resume request message and is terminated when the UE 202 is directed to RRC IDLE or RRCJNACTIVE (via RRCRelease) or directed to RRC_CONNECTED (via RRCResume or RRCSetup). Initial UL SDT data is multiplexed with the resume request message, and during SDT, there could be several UL/DL SDT data exchanges.

[0070] The 3GPP SDT WI is considering a RACH-based (2-step or 4-step) and CG-based (configured grant type-1) for SDT. A RACH-based SDT allows the UE 202 to initiate a SDT session on a new gNB 324 (other than the old gNB 326, also referred to as an anchor gNB). In this case, the UE context can be relocated to the new gNB 324, or kept in the old gNB 326, which is up to the old gNB 326 to decide. The message flow 300b depicts a signaling flow for the case that the old gNB 326 decides to relocate the context to the new gNB 324. This procedure may be referred to as a RACH based SDT with anchor relocation. [0071] As described herein, embodiments may relate to several signaling enhancements to support SDT in a split gNB architecture and assistance information from a new gNB 324 to help an old gNB 326 make a decision to relocate or keep a context for SDT. It is worthy to note that the new mechanisms described herein assume that RRC signaling (e.g., RRCResumeRequest and RRCRelease) is involved when exchanging the SDT. However, similar operations could also be enabled without this RRC signaling, such as when a UE 202 is accessing in the cell where the UE context was stored. Embodiments may include, for example: (1) mechanisms for DU to indicate to CU, the initiation of SDT from the UE; (2) mechanisms for new gNB to provide assistance information that helps the last serving gNB make decision to relocate or keep the context for SDT; (3) mechanisms for DU to indicate CU, to expose its capability of whether it can support "no anchor relocation" scenario for SDT or not; (4) mechanisms for CU to another CU, to expose its capability of whether it support SDT or not; and (5) mechanisms for CU to indicate to DU, to supply the lower layer SDT configuration before CU sends the UE back to INACTIVE. The described signaling and information enables small data transfer during NR INACTIVE seamlessly, and works in a split NG-RAN architecture to help a serving network node make better decisions on choosing a connection management point for the UE for overall system performance optimization. Further, the embodiments may target 3GPP radio access network three (RAN3) specifications for F1AP and XnAP, among other 3GPP standards and non- 3GPP standards. Embodiments are not limited in this context.

[0072] Operations for the disclosed embodiments may be further described with reference to the following figures. Some of the figures may include a logic flow. Although such figures presented herein may include a particular logic flow, it can be appreciated that the logic flow merely provides an example of how the general functionality as described herein can be implemented. Further, a given logic flow does not necessarily have to be executed in the order presented unless otherwise indicated. Moreover, not all acts illustrated in a logic flow may be required in some embodiments. In addition, the given logic flow may be implemented by a hardware element, a software element executed by a processor, or any combination thereof. The embodiments are not limited in this context.

[0073] FIG. 4 illustrates an embodiment of a logic flow 400. The logic flow 400 may be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow 400 my include some or all of the operations performed by devices or entities within the wireless communications system 100 or the wireless communications system 200, such as the gNB 204. More particularly, the logic flow 400 illustrates a use case where the gNB 204 implements a gNB split-architecture, and includes techniques for a gNB -DU 210 to indicate to a gNB-CU 214 initiation of a SDT session from the UE 202. For instance, the gNB-DU 210 may forward an RRC resume request message received from the UE 202 to the gNB-CU 214 to indicate the RRC resume request message is due to SDT. Embodiments are not limited in this context.

[0074] In block 402, logic flow 400 receives an indication that a radio resource control (RRC) resume request message is received from a user equipment in an inactive state by a gNodeB (gNB) distributed unit (gNB-DU) of a radio access network (RAN). For example, a gNB-DU 210 serves a cell for a new RAN 302. The UE 202 is within the cell for the new RAN 302, and in an RRC_INACTIVE state 308. The UE 202 sends a message 322 in the form of an RRC resume request message to the gNB-DU 210 of the new RAN 302 while in the RRC_INACTIVE state 308. The gNB-DU 210 receives the RRC resume request message from the UE 202.

[0075] In block 404, logic flow 400 decodes that the RRC resume request message received from the UE is due to a small data transmission (SDT). For example, the gNB-DU 210 decodes that the RRC resume request message received from the UE 202 is due to a small data transmission (SDT) based on the initial UL data multiplexed together. The RRC resume request message may include an indication of a small data transmission (SDT). [0076] In block 406, logic flow 400 generates an initial uplink (UL) RRC message transfer message, the initial UL RRC message transfer message to include an information element (IE) with one or more parameters to indicate the RRC resume request is due to the SDT. For example, the gNB-DU 210 generates an initial uplink (UL) RRC message transfer message, the initial UL RRC message transfer message to include an information element (IE) with one or more parameters to indicate the RRC resume request is due to the SDT.

[0077] In block 408, logic flow 400 send an indication to transmit the initial UL RRC message transfer message from the gNB-DU to a gNB central unit (gNB-CU), the initial UL RRC message transfer message to indicate a transfer of the RRC resume request message to the gNB-CU. For example, the gNB-DU 210 sends an indication to transmit the initial UL RRC message transfer message from the gNB-DU 210 to a gNB-CU 214. The initial UL RRC message transfer message indicates a transfer of the RRC resume request message to the gNB-CU 214. The gNB-DU 210 transmits the UL RRC message transfer message to the gNB-CU 214 using a signaling service, such as a Fl interface, using an Fl application protocol (F1AP).

[0078] FIG. 5 illustrates a message flow 500. The message flow 500 provides an example of messages to support the logic flow 400. As depicted in FIG. 5, the UE 202 generates information suitable for a SDT. The UE 202 is in an RRC_INACTIVE state 502. In case of a RACH-based SDT, RA specific resources may be used for the SDT initiation as well as RACH resources that are shared for SDT and non-SDT. As such, the UE 202 generates an RRC resume request message (e.g., RRCResumeRequest) that includes a SDT indication or other SDT information. The UE 202 sends a message 504 which is the RRC resume request message to the new RAN 302, which is implemented in a split-architecture gNB-DU 210 and gNB-CU 214. The gNB-DU 210 generates an initial UL RRC message transfer message, and sends it as a message 506 to the gNB-CU 214 over an Fl interface using the F1AP. At block 508, the UE 202 and the gNB-CU 214 perform a procedure to perform SDT with the UE 202 in the RRC_INACTIVE state 502 or with the UE 202 entering an RRC_CONNECTED state (not shown). The UE 202 starts sending one or more messages 510 to the UPF 306 (not shown) via the gNB 204. The messages 510 may comprise SDT messages. If the UE 202 previously entered the RRC_CONNECTED state 316 at block 508, then at block 512, the UE 202 and the gNB 204 optionally performs a connection inactive procedure. A connection inactive procedure can include causing the UE 202 to switch back to an RRC_IN ACTIVE state 514.

[0079] In a case of a split NG-RAN architecture where the receiving gNB 204 is split into a gNB-CU 214 and a gNB-DU 210, the gNB-DU 210 can know of the SDT initiation by a number of ways: (1) initial UL SDT data multiplexed; (2) RA specific resources used (e.g., when RA resources are allocated for RACH-based SDT); or (3) a configured grant (CG) used (CG-based SDT) together with the usage of the assigned C-RNTI. Current 3GPP standards, however, do not define a different resume cause specific SDT within RRCResumeRequest message generated by the UE 202. As a result, it may be desirable for there to be some mechanisms for the gNB-DU 210 to indicate to the gNB-CU 214, when forwarding the received RRCResumeRequest message to the gNB-CU 214, that the UE 202 is requesting to resume due to a SDT.

[0080] One possible implementation is to add a new resume cause (e.g., an information element with suitable parameters) in the RRCResumeRequest message. Another possible implementation is to enhance the F1AP INITIAL UL RRC MESSAGE TRANSFER message, that is used to forward the received RRCResumeRequest message, to indicate that the resume request is due to an SDT.

[0081] Referring again to FIG. 5, the gNB-DU 210 sends a message 506 to the gNB-CU 214. The message 506 may represent an initial UL RRC message transfer message. In one embodiment, the initial UL RRC message transfer message may be implemented as an INITIAL UL RRC MESSAGE TRANSFER message as defined by Section 9.2.3.1 of the 3GPP TS 38.473 titled “Technical Specification Group Radio Access Network; NG-RAN; Fl application protocol (F1AP),” Release 17.0.0, April 2020, including any progeny, revisions and variants. Other message types and standards may be implemented as well. Embodiments are not limited in this context.

[0082] An example of how new information elements (IES) are added in an INITIAL UL RRC MESSAGE TRANSFER message to support or indicate that a resume request is due to an SDT is shown in Table 1 as follows:

[0083] 9.2.3.1 INITIAL UL RRC MESSAGE TRANSFER

[0084] This message is sent by the gNB-DU to transfer the initial layer 3 message to the gNB-CU over the Fl interface. [0085] Direction: gNB-DU -A gNB-CU

[0086] TABLE 1

[0087] FIG. 6 illustrates an apparatus 600 suitable for a gNB 204 to support the message flows 300a and/or 300b, the logic flow 400 and/or the message flow 500. As depicted in FIG. 6, the apparatus 600 includes a memory interface 606 to send or receive, to or from a data storage device 610, small data transmission (SDT) information for SDT signaling between a gNB-DU 210 and a gNB-CU 214 of a radio access network 112. The apparatus 600 also includes a processor circuitry 602 communicatively coupled to the memory interface 606, the processor circuitry 602 to comprise a decoder 604 to decode that an RRC resume request message received from a UE in an inactive state by the gNB-DU 210 is due to SDT. The processor circuitry 602 may comprise a decider 620 to make logic decisions in support of SDT operations. The processor circuitry 602 may comprise a generator 608 to generate an initial uplink (UL) RRC message transfer message, the initial UL RRC message transfer message to include an information element (IE) with one or more parameters to indicate the RRC resume request is due to SDT. The processor circuitry 602 may comprise an interface 612 to send an indication to transmit the initial UL RRC message transfer message from the gNB-DU 210 to the gNB-CU 214, the initial UL RRC message transfer message to indicate a transfer of the RRC resume request message to the gNB-CU 214.

[0088] The apparatus may also include radio frequency (RF) circuitry 618 communicatively coupled to the processor circuitry 602, the RF circuitry 618 to receive RF signals representing the RRC resume request message from the UE 202.

[0089] The apparatus may also include a signaling service 616 between the gNB-DU and the gNB-CU to provide UE-associated services, the signaling service to transmit the initial UL RRC message transfer message from the gNB-DU 210 to the gNB-CU 214 over a Fl interface in accordance with an Fl application protocol (F1AP). The interface 612 outputs the indication to transmit to a transceiver 614 implementing the signaling service 616. The signaling service 616 may comprise, for example, an Fl interface that operates in accordance with the F1AP as defined in the 3GPP TS 38.473, as well as other 3GPP and non-3GPP standards.

[0090] The generator 608 of the apparatus 600 may generate the initial UL RRC message transfer message in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.473.

[0091] The generator 608 of the apparatus 600 may generate the initial UL RRC message transfer message, where an IE group name for the initial UL RRC message transfer message is a SDT initiation or a SDT information.

[0092] The generator 608 of the apparatus 600 may generate the initial UL RRC message transfer message, where an IE group name for the initial UL RRC message transfer message is a SDT information, and where a presence for the IE is optional.

[0093] The generator 608 of the apparatus 600 may generate the initial UL RRC message transfer message, where the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT indicator of an enumerated type with a Boolean parameter, such as TRUE or FALSE, the enumerated type of TRUE to indicate that the UL RRC message transfer message to transfer the RRC resume request is due to a SDT.

[0094] The generator 608 of the apparatus 600 may generate the initial UL RRC message transfer message in accordance with 3GPP TS 38.473, Section 9.3.1.262, SDT Information. For instance, the initial UL RRC message transfer message may include an IE to indicate an SDT transaction and to provide assistant information from the UE. The IE may include SDT information, such as an IE Group Name of SDT indicator with a presence of mandatory (M) and an IE type and reference of an enumerated type with a Boolean parameter, such as TRUE or FALSE. Additionally or alternatively, the IE may include SDT information, such as an IE Group Name of SDT assistant information with a presence of optional (O) and an IE type and reference of an enumerated type, the enumerated type to comprise a single packet parameter to indicate no subsequent SDT transmission is expected or a multiple packets parameter to indicate subsequent SDT transmission is expected.

[0095] The apparatus 600 may be implemented by a gNB 204 in order to solve a SDT challenge of providing a standardized procedure to support or indicate that a resume request is due to an SDT when the gNB 204 utilizes a gNB split or split-architecture.

[0096] Another SDT challenge for a split NG-RAN architecture is communicating lower layer SDT configuration information for a UE 202 between a gNB-CU 214 and a gNB-DU 210 before the gNB-CU 214 sends the UE back to an RRC_INACTIVE state. The gNB-CU 214 may grant the UE 202 one or more free PUSCH resources to initiate a SDT without a RACH. The free grant is defined by a configured grant (CG), and the CG is configured for the UE via an RRCRelease message from a last serving cell (e.g., the old RAN 304) for the UE 202. The resources indicated by the CG are only valid when the UE 202 is in a same serving cell (e.g., the new RAN 302), which means that the UE 202 can only initiate a SDT toward the same serving cell in which it was moved to an RRC_INACTIVE state.

[0097] In a split NG-RAN architecture, the gNB-DU 210 governs lower layers for a UE, such as MAC/PHY configuration information for the UE 202. The gNB-DU 210 manages and allocates scheduling resources for the UE 202 while performing a SDT. The gNB-CU 214 governs RB configuration information as well as a decision for SDT by the UE 202. Prior to making a decision for SDT by the UE 202, the gNB-CU 214 needs the MAC/PHY configuration information for the UE 202 from the gNB-DU 210 in order to generate an RRCRelease message with a CG based SDT for the UE 202. Currently, the 3GPP standards do not define a standardized way for the gNB-CU 214 and the gNB-DU 210 to communicate MAC/PHY configuration information for the UE 202 to perform SDT operations. This challenge may also be applicable to a RACH-based SDT or any other type of SDT operation.

[0098] Embodiments attempt to solve these and other SDT-related challenges. Embodiments describe various techniques, systems, and devices to support small data transfers in a 3GPP 5G NR system, among other wireless communications systems.

[0099] FIG. 7 illustrates a logic flow 700. The logic flow 700 may be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow 700 may include some or all of the operations performed by devices or entities within the wireless communications system 100 or the wireless communications system 200, such as the gNB 204. More particularly, the logic flow 700 illustrates a use case where the gNB 204 implements a gNB split-architecture, where the gNB-DU 210 sends configuration information for the UE 202 to the gNB-CU 214 so the gNB-CU 214 can generate a CG based SDT for a UE 202 based on the configuration information. Embodiments are not limited in this context.

[0100] In block 702, logic flow 700 determines to modify user equipment (UE) context information for a UE by a gNB central unit (gNB-CU) of a radio access network (RAN). For example, an apparatus 600 for an access node, such as a gNB 204 or an eNB, may include a memory interface 606 to send or receive, to or from a data storage device 610, SDT information for SDT signaling between a gNB-DU 210 and a gNB-CU 214 of a 3GPP radio access network 112. The apparatus 600 may also include a processor circuitry 602 communicatively coupled to the memory interface 606, the processor circuitry 602 to include a decider 620 to determine to modify UE context information for a UE 202 by the gNB-CU 214 of the RAN 112.

[0101] In block 704, logic flow 700 generates a UE context modification request message to provide the modified UE context information by a gNB distributed unit (gNB-DU) of the RAN, the UE context modification request message to include an information element (IE) with one or more parameters to indicate a request for configuration information of the UE for small data transmission (SDT) operation from the gNB-DU. For example, the processor circuitry 602 may generate a UE context modification request message to provide the modified UE context information to the gNB-DU 210 of the RAN 112, the UE context modification request message to include an IE with one or more parameters to indicate a request for configuration information of the UE 202 for SDT operation from the gNB-DU 210.

[0102] In block 706, logic flow 700 send an indication to transmit the UE context modification request message from the gNB-CU to the gNB-DU. For example, the processor circuitry 602 may send an indication to transmit to the transceiver 614. The transceiver 614 may transmit the UE context modification request message from the gNB- CU 214 to the gNB-DU 210 over a signaling service 616. The signaling service 616 may send the UE context modification request message over an Fl interface in accordance with F1AP.

[0103] FIG. 8 illustrates a message flow 800. The message flow 800 provides an example of messages to support the logic flow 700. As depicted in FIG. 8, at block 802, the gNB- CU 214 determines to modify UE context information for the UE 202 in order to generate a CG based SDT for the UE 202. Prior to making a decision for SDT for the UE 202, the gNB-CU 214 needs MAC/PHY configuration information for the UE 202 from the gNB-DU 210 in order to generate an RRCRelease message with a CG based SDT for the UE 202.

[0104] The gNB-CU 214 generates a message 804 as a UE context modification request message to provide the modified UE context information governed by the gNB-DU 210. The UE context modification request message includes an IE with one or more parameters to indicate a request for configuration information of the UE 202 for SDT operation from the gNB-DU 210, and sends the message 804 to the gNB-DU 210. The configuration information may comprise MAC and/or PHY layer information for the UE 202.

[0105] The gNB-DU 210 receives the message 804 from the gNB-CU 214. In response, at block 806, the gNB-DU 210 retrieves the configuration information for the UE 202, and it generates a message 808 as a UE context modification response message with the configuration information. The gNB-DU 210 sends the message 808 to the gNB-CU 214.

[0106] The gNB-CU 214 receives the message 808. At block 810, the gNB-CU 214 decodes the UE context modification response message received from the gNB-DU 210 in response to the UE context modification request message. The UE context modification response message may include the requested configuration information. The gNB-CU 214 generates a CG based SDT for SDT operation for the UE 202 in response to receiving the configuration information from the gNB-DU 210. The gNB-CU 214 then generates a message 812 as an RRCRelease message with the CG based SDT for the UE 202, and sends the RRCRelease message with the CG based SDT to the gNB-DU 210. At block 814, the UE 202 and the gNB 204 performs a connection inactive procedure or a SDT termination procedure. A connection inactive procedure can include sending the RRCRelease message with the CG based SDT to the UE 202, thereby causing the UE 202 to switch back to a RRC_INACTIVE state. For subsequent SDT, the UE 202 may use the CG based SDT for future SDT. The UE 202 may initiate a SDT session by sending an RRC resume request (e.g., RRCResumeRequest) message that includes SDT information to the gNB 204.

[0107] Currently, the 3GPP standards do not define a standardized way for the gNB-CU 214 and the gNB-DU 210 to communicate MAC/PHY configuration information for a UE 202 to perform SDT operations. This challenge may also be applicable to a RACH-based SDT or any other type of SDT operation. One possible implementation is to enhance the F1AP UE Context Modification procedure to support such retrieval over an Fl interface using the F1AP. [0108] Referring again to FIG. 8, the gNB-CU 214 generates a message 804 as a UE context modification request message to provide the modified UE context information governed by the gNB-DU 210. The UE context modification request message includes an IE with one or more parameters to indicate a request for configuration information of the UE 202 for SDT operation from the gNB-DU 210, and sends the message 804 to the gNB- DU 210. The configuration information may comprise MAC and/or PHY layer information for the UE 202. In one embodiment, the UE context modification request message may be implemented as a UE CONTEXT MODIFICATION REQUEST message as defined by Section 9.2.2.7 of the 3GPP TS 38.473 titled “Technical Specification Group Radio Access Network; NG-RAN; Fl application protocol (F1AP),” Release 17.0.0, April 2020, including any progeny, revisions and variants. Other message types and standards may be implemented as well. Embodiments are not limited in this context.

[0109] An example of how new information elements (IES) are added in a UE CONTEXT MODIFICATION REQUEST message to support SDT is shown in Table 2 as follows: [0110] 9.2.2.7 UE CONTEXT MODIFICATION REQUEST

[0111] This message is sent by the gNB-CU to provide UE Context information changes to the gNB-DU.

[0112] Direction: gNB-CU —7 gNB-DU

[0113] TABLE 2

[0114] Referring again to FIG. 6, the apparatus 600 may include a processor circuitry 602 to generate the UE CONTEXT MODIFICATION REQUEST message in accordance with the 3GPP TS 38.473, Section 9.2.2.7. As indicated in Table 2, the processor circuitry 602 may generate the UE CONTEXT MODIFICATION REQUEST message, where an IE group name for the UE context modification request message is a SDT configuration request or a configured grant (CG) SDT (CG-SDT) query indication.

[0115] As further indicated in Table 2, the processor circuitry 602 may generate the UE CONTEXT MODIFICATION REQUEST message, where an IE group name for the UE context modification request message is a configured grant (CG) SDT (CG-SDT) query indication, and where a presence for the IE is optional.

[0116] As further indicated in Table 2, the processor circuitry 602 may generate the UE CONTEXT MODIFICATION REQUEST message, where an IE type and reference for the UE context modification request message is an enumerated type with a Boolean parameter.

[0117] Other embodiments describe mechanisms for a new gNB 324 to provide assistance information that helps the old gNB 326 make decisions on whether to relocate a context or keep the context for a SDT session. RACH-based SDT allows the UE 202 to initiate SDT session on a new gNB 324 other than the anchor gNB. In this case, the UE context may be relocated to the new gNB 324, or kept in the old gNB 326, which is up to the old gNB 326 to decide.

[0118] If a SDT procedure takes a long time, relocation may be desirable. On the other hand, if a SDT session is short, keeping the context in the old gNB 326 may be a better fit. In fact, the decision could be based on various factors, such as a UE mobility pattern or DL data event.

[0119] For that case, some assistance information from the new gNB 324 may be useful in the XnAP RETRIEVE UE CONTEXT REQUEST message to help the old gNB 326 make a context transfer decision. Thus far, assistance information that has been discussed was in the form of whether a SDT session will be one-shot or multiple, or based on volume of SDT data. However, it is uncertain on how the new gNB 324 can be certain on how long a SDT session would last when it requests context retrieval. A BSR from the UE 202 is a good indicator, however, it may not be sent with RRCResumeRequest from the beginning. The new gNB 324 may have a difficult time in making this determination, based on the initial UL SDT data fitted into the grant size of MSG3/MSGA. Further, at this point, DL data does not even arrive to the new gNB 324.

[0120] Rather than trying to estimate an answer for a question of "how long a SDT session would last," what could be more useful is preference information from the new gNB 324. Once the old gNB 326 has decided to not relocate the context, then relocation in the middle of a SDT session is not allowed. Therefore, it may be better to provide preference information for the new gNB 324 at a beginning of an SDT procedure.

[0121] There may be a case that the new gNB 324 (which is capable of SDT) does not support a "no anchor relocation" scenario that requires different handling than a legacy case. In this case, the new gNB 324 should be able to indicate a preference of "anchor relocation" to prevent the decision to keep the context from the old gNB 326 as much as possible. On the other hand, the new gNB 324 may not want to take on the anchor role for the UE 202 if, for example, too many UEs are under its connection management. The new gNB 324 should be able to indicate its preference of a "no relocation" scenario to be taken into account by a decision made by the old gNB 326.

[0122] One possible implementation is to enhance the XnAP RETRIEVE UE CONTEXT REQUEST message to include the context relocation preference from the new gNB 324 to be taken into account. An example is shown in Table 3, as follows:

[0123] 9.1.1.8 RETRIEVE UE CONTEXT REQUEST

[0124] This message is sent by the new NG-RAN node to request the old NG-RAN node to transfer the UE Context to the new NG-RAN.

[0125] Direction: new NG-RAN node — old NG-RAN node.

[0126] TABLE 3

[0127] Other embodiments include mechanisms for a gNB-DU 210 to indicate to a gNB- CU 214, its capability of whether it can support a "no anchor relocation" scenario for a SDT session or not. A no anchor relocation scenario, as depicted in FIG. 10, involves new and sophisticated handling as compared to a legacy INACTIVE procedure in the gNB-DU 210 of the new gNB 324 (if split architecture) because the gNB-DU 210 needs to perform forwarding of user-plane SDT data directly between the old gNB 326.

[0128] On the other hand, an anchor relocation scenario (described in FIG. 3B) does not require special handling compared to a legacy INACTIVE procedure. For this reason, the gNB-DU 210 which is capable of SDT may support the anchor relocation scenario only for SDT operation. There should be some mechanisms to expose a capability of whether the gNB-DU 210 can support "no anchor relocation" or not toward the gNB-CU 214, so that it can be properly reflected in the gNB-CU 214 of the new gNB 324 and provide a preference to the old gNB 326 when requesting context retrieval (as discussed in previous embodiments).

[0129] One possible implementation is to enhance the F1AP Fl SETUP or gNB-DU CONFIGURATION UPDATE or gNB-CU CONFIGURATION UPDATE ACKNOWEEDGE procedures to expose its capability or update the change to the gNB-CU 214. Another possible implementation is to enhance the F1AP INITIAL UL RRC MESSAGE TRANSFER procedure, that is used to forward the RRC message initiating SDT, so that such capability of whether it can support "no anchor relocation" or not can be indicated to the gNB-CU 214 of the new gNB 324. An example is shown in Table 4 as follows:

[0130] 9.2.3.1 INITIAL UL RRC MESSAGE TRANSFER

[0131] This message is sent by the gNB-DU to transfer the initial layer 3 message to the gNB-CU over the Fl interface.

[0132] Direction: gNB-DU — > gNB-CU [0133] TABLE 4

[0134] Other embodiments include mechanisms for a CU to another CU in order to expose its capability of whether it supports SDT or not. If gNBs can exchange with each other capability for SDT operation, it could be useful for the old gNB 326 to determine the coverage of the UE 202 that is configured for SDT operation, because the old gNB 326 can take into account the neighboring gNB's support for SDT and is able to configure the UE 202 to perform SDT only on cells or coverages under gNBs which support SDT operation. This could prevent the UE 202 from initiating SDT on a cell that does not support SDT.

[0135] Such capability exchange can further be categorized on a per cell level and further by different scenarios that a gNB can support, such as a "relocation scenario only", a "no relocation scenario only", and so forth. One possible implementation is to enhance Neighbor Cell Relation related IE (that are exchanged between neighboring gNBs) over the Xn interface. An example is shown in Table 5 as follows:

[0136] 9.2.2.11 Served Cell Information NR [0137] This IE contains cell configuration information of an NR cell that a neighboring

NG-RAN node may need for the Xn AP interface.

[0138] TABLE 5

[0139] In addition to assigning resources for SDT operations, another challenge for a 5G NR system is for a UE to maintain SDT capabilities when the UE is handover (HO) between different serving cells. Various 3GPP standards are considering a RACH-based and/or CG- based (e.g., a configured grant type-1) for SDT. A RACH-based SDT allows a UE to initiate a SDT session when the UE is HO to a new gNB (referred to as a “new gNB") from a last serving gNB (referred to as an “old gNB” or “anchor gNB”). In this case, context information for the UE can be relocated to the new gNB or remain in the old gNB, which is up to the old gNB to decide. When the context information for the UE is not relocated to the new gNB, information signaling and interactions (e.g., messages) may be similar to legacy situations, such as when a UE is supported for periodic RAN notification area (RNA) updates. However, SDT may need different information signaling and interactions between the new gNB and the old gNB. Currently, the 3GPP standards do not define a standardized way for the old gNB and the new gNB to communicate context information for a UE to perform SDT operations when operating in the new gNB when the context information is not relocated from the old gNB to the new gNB.

[0140] Embodiments attempt to solve these and other SDT-related challenges. Embodiments describe various techniques, systems, and devices to support small data transfers in a 3GPP 5G NR system, among other wireless communications systems. The signaling and information described for one or more embodiments may enable support of small data transfer during 5G NR RRC_INACTIVE seamlessly across network nodes when the UE 202 initiates SDT operation toward a network node other than a previous network node that last served the UE 202. The signaling and information described for one or more embodiments may be implemented in one or more 3GPP standards, such as the 3GPP TS 38.423, which defines an Xn application protocol (XnAP) interface between the the new gNB 324 and the old gNB 326.

[0141] Referring again FIG. 3B, a UE 202 may initiate a SDT procedure without switching from an RRC_INACTIVE state to an RRC_CONNECTED state. A RACH-based (e.g., 2- step or 4-step) and a CG-based (e.g., configured grant type-1) are being considered for SDT. The RACH-based SDT allows the UE 202 to initiate a SDT session on a new gNB 324 other than the old gNB 326 (e.g., the anchor gNB). In this case, the UE context can be relocated to the new gNB 324, or kept in the old gNB 326, which is up to the old gNB 326 to decide. When the old gNB 326 decides to not relocate the context to the new gNB 324, this case may be referred to as a RACH based SDT with no anchor relocation.

[0142] A case where the old gNB 326 decides to not relocate the context may be implemented with a procedure that is similar to legacy situations where it was supported for periodic RAN notification area (RNA) updates. However, SDT requires different information signaling and interactions between the new gNB 324 and the old gNB 326. Embodiments herein relate to enhancements to support SDT for the case where the context for the UE 202 is not relocated. More particularly, embodiments include: (1) mechanisms to support user-plane data transfer between the UE 202 and the old gNB 326 through the new gNB 324; (2) mechanisms to support transfer of RRC messages between the UE 202 and the old gNB 326 through the new gNB 324; and (3) mechanisms to support UE context release in the new gNB 324 when the old gNB 326 sends an RRC message to terminate a SDT session for the UE 202.

[0143] FIG. 9 illustrates a logic flow 900. The logic flow 900 may be representative of some or all of the operations executed by one or more embodiments described herein. For example, the logic flow 900 may include some or all of the operations performed by devices or entities within the wireless communications system 100 or the wireless communications system 200, such as the gNB 204. More particularly, the logic flow 900 illustrates a use case where the gNB 204 implements a gNB split-architecture, where the gNB-DU 210 sends SDT information for the UE 202 to the gNB-CU 214 to inform the gNB-CU 214 that the UE 202 is initiating SDT. Embodiments are not limited in this context.

[0144] In block 902, logic flow 900 decodes a retrieve user equipment (UE) context request message received from a first node of a radio access network (RAN) by a second node of the RAN, the retrieve UE context request message to include small data transmission (SDT) information. For example, an apparatus 600 for an access node, such as gNB 204 or an eNB, includes a memory interface 606 to send or receive, to or from a data storage device 610, SDT information for SDT signaling between a first node and a second node of a 3GPP RAN. The apparatus 600 may also include a processor circuitry 602 communicatively coupled to the memory interface 606, the processor circuitry 602 to decode a retrieve UE context request message received from a first node of a RAN by a second node of the RAN, the retrieve UE context request message to include the SDT information.

[0145] In block 904, logic flow 900 generates a retrieve UE context request response message by the second node of the RAN, the retrieve UE context request response message to include an information element (IE) with one or more parameters to represent partial context information related to SDT for the UE. For example, the processor circuitry 602 may generate a retrieve UE context request response message by the second node of the RAN, the retrieve UE context request response message to include an IE with one or more parameters to represent partial context information related to SDT for the UE.

[0146] In block 906, logic flow 900 sends an indication to transmit the retrieve UE context request response message from the second node to the first node. For example, the processor circuitry 602 send an indication to transmit the retrieve UE context request response message from the second node to the first node. Note the SDT can be in an UL direction, downlink (DL) direction, or both directions. [0147] FIG. 10 illustrates a message flow 1000 that provides an example of a resume procedure for a small data transmission (SDT) without the UE 202 entering a RRC_CONNECTED state prior to SDT operations. As previously discussed, a RACH- based SDT allows the UE 202 to initiate an SDT session on a new gNB 324 which is a gNB other than the old gNB 326 (e.g., the anchor gNB). The UE context can be relocated to the new gNB 324 or kept in the old gNB 326, which is up to the old gNB 326 to decide. The message flow 1000 depicts a signaling flow for the case where the old gNB 326 decides to not relocate the context for the UE 202 to the new gNB 324. More particularly, the message flow 1000 provides an example of a RACH based SDT with no anchor relocation procedure, as defined by various 3GPP standards, such as 3GPP TS 38.423 and TS 38.300, among other 3GPP and non-3GPP standards.

[0148] In the message flow 1000, a wireless system includes the UE 202, the new gNB 324, the old gNB 326, and the UPF 358. From time to time, the UE 202 may need to transmit a small amount of data, referred to in 3GPP as a SDT. In this example, a context for the UE 202 is stored at the old gNB 326, which is referred to as an "anchor” for the UE 202.

[0149] The message flow 1000 illustrates an example of a message exchange initiated by a RRC resume request containing a small data indication. In some implementations, the messages can be implemented as XnAP messages which are generated and transmitted based on 3GPP TS 38.423, among other 3GPP and non-3GPP standards.

[0150] In this example, the UE 202 initiates SDT to the new gNB 324, where the old gNB 326 provides a RRC release configuration or message to the new gNB 324 via a context retrieval procedure. The UE 202 indicates its small data intention during a resume procedure. In block 330, the UE 202, in the RRC_INACTIVE state, sends a message 1002 as an RRC resume request message to the new gNB 324. The RRC resume request message is communicated over SRB0, and it includes a small data indication with UL SDT data.

[0151] At block 334, the new gNB 324 determines that initial UL SDT data is for the old gNB 326. The new gNB 324 communicates the small data indication in message 1004 to the old gNB 326 via an XnAP message. The new gNB 324 can send the message 1004 as an XnAP retrieve UE context request message. The old gNB 326 can determine whether to relocate the anchor or not.

[0152] After receiving the XnAP retrieve UE context request message, the old gNB 326 can determine whether to relocate the anchor for the UE 202 and send a message 1006 as an XnAP retrieve UE context failure message to the new gNB 324. The XnAP retrieve UE context failure message may comprise an IE with one or more parameters representing partial context information, including SDT RLC configuration information, for an UL TNL. Additionally or alternatively to the XnAP retrieve UE context failure message, the message 1006 may be implemented as a partial UE context transfer message with partial UE context transfer information for SDT message. This message is sent by the old gNB 326 to transfer part of the UE context information to the new gNB 324.

[0153] The new gNB 324 also sends a message 1008 with an Xn-U address indication to the old gNB 326. In some implementations, the new gNB 324 sends a XnAP DL data forwarding address indication message to the old gNB 326 as legacy.

[0154] At block 1010, the old gNB 326 and the UE 202 may communicate various RRC messages over one or more signaling radio bearers (SRBs). At block 1012, the old gNB 326 decides to terminate the SDT session. The old gNB 326 sends a message 1014 as an RRC message to terminate the SDT session for the UE 202 to the new gNB 324. The message 1014 may include UE context release information. The new gNB 324 may send a message 1016 to the UE 202. The message 1016 may comprise, for example, an RRC release message (e.g., RRCRelease) or an RRC resume message (e.g., RRCResume) for the UE 202.

[0155] As shown in the message flow 1000, a RACH-based SDT allows the UE 202 to initiate an SDT session on a new gNB 324 which is a gNB other than the old gNB 326 (e.g., the anchor gNB). The UE context can be relocated to the new gNB 324 or kept in the old gNB 326, which is up to the old gNB 326 to decide. The message flow 1000 depicts a signaling flow for the case where the old gNB 326 decides to not relocate the context for the UE 202 to the new gNB 324.

[0156] When the old gNB 326 decides on no anchor relocation, embodiments introduce various techniques to support user-plane data transfer between the UE 202 and the old gNB 326 through the new gNB 324. In a no relocation scenario, handling SDT data at a network side may require user-plane forwarding between the new gNB 324 and the old gNB 326. First, UL SDT data should be forwarded to the old gNB 326. The old gNB 326 holds a security anchor and it is the only place that can properly decrypt UL SDT data before uploading to the core network. Further, DL SDT data arriving to the old gNB 326 (if any) should also be forwarded to the new gNB 324 to be transmitted to the UE 202. As long as the old gNB 326 keeps the anchor role, there should not be a switch of path that changes the UE connection management point in RAN side.

[0157] One possibility is to forward user -plane data in the form of PDCP PDU (e.g., RLC SDU). Then, the corresponding user-plane forwarding tunnel may be established to forward user-plane data in the form of PDCP PDU, which is new for the RRC_INACTIVE procedure. And the UE 202 resumes its layer-2 configuration when initiating SDT, so the new gNB 324 should be able to retrieve at least the UE RLC configurations for processing RLC data properly. In the uplink, the new gNB 324 should be able to process the received RLC PDUs up to RLC SDUs (e.g., PDCP PDUs) so that they can be forwarded to the old gNB 326 for proper decryption. In the downlink, the new gNB 324 should be able to process the received PDCP PDUs from the old gNB 326 and should be able to transmit them to the UE 202. To enable this, some necessary information has to be provisioned from the old gNB 326 to the new gNB 324 during the context retrieval procedure.

[0158] As discussed in the message flow 1000, the old gNB 326 can determine to not relocate the anchor for the UE 202 and send a message 1006 as an XnAP retrieve UE context failure message to the new gNB 324. The XnAP retrieve UE context failure message may comprise an IE with one or more parameters representing partial context information, including SDT RLC configuration information, for an UL TNL. Additionally or alternatively to the XnAP retrieve UE context failure message, the message 1006 may be implemented as a partial UE context transfer message with partial UE context transfer information for SDT message. This message is sent by the old gNB 326 to transfer part of the UE context information to the new gNB 324.

[0159] In one embodiment, the UE context failure message may be implemented as a PARTIAL UE CONTEXT TRANSFER message as defined by Section 9.1.1.17 and Section 9.2.3.164 of the 3GPP TS 38.423 titled “Technical Specification Group Radio Access Network; NG-RAN; Xn application protocol (XnAP),” Release 17.0.0, April 2022 (2022-4) and Release 17.1.0, June 2022 (2022-06); both including any progeny, revisions or variants. Other message types and standards may be implemented as well. Embodiments are not limited in this context.

[0160] Section 9.1.1.17 of the 3GPP TS 38.423, Release 17.0.0, provides an example of how new IES are added in a PARTIAL UE CONTEXT TRANSFER message to support SDT is shown in Table 6 as follows:

[0161] 9.1.1.17 PARTIAL UE CONTEXT TRANSFER

[0162] This message is sent by the old NG-RAN node (e.g., the old gNB 326) or to transfer part of the UE Context to the new NG-RAN node (e.g., the new gNB 324).

[0163] Direction: old NG-RAN node new NG-RAN node.

[0164] TABLE 6

[0165] Section 9.2.3.164 of the 3GPP TS 38.423, Release 17.0.0, provides an example of a new IE for the PARTIAL UE CONTEXT TRANSFER message, where the new IE is referred to as a Partial UE Context Information for SDT. This IE contains UE context information within the PARTIAL UE CONTEXT TRANSFER message for NR SDT. An example for this new IE is shown in Table 7 as follows:

[0166] 9.2.3.164 Partial UE Context Information for SDT

[0167] This IE contains the UE context information within the PARTIAL UE CONTEXT TRANSFER message for NR SDT. [0168] TABLE 7

[0169] Section 9.1.1.17 of the 3GPP TS 38.423, Release 17.1.0, provides another example of how new IES are added in a PARTIAL UE CONTEXT TRANSFER message to support SDT is shown in Table 8 as follows: [0170] 9.1.1.17 PARTIAL UE CONTEXT TRANSFER

[0171] This message is sent by the old NG-RAN node to transfer part of the UE Context to the new NG-RAN node.

[0172] Direction: old NG-RAN node — new NG-RAN node.

[0173] TABLE 8

[0174] Section 9.2.3.164 of the 3GPP TS 38.423, Release 17.1.0, provides an example of a new IE for the PARTIAL UE CONTEXT TRANSFER message, where the new IE is referred to as a Partial UE Context Information for SDT. This IE contains UE context information within the PARTIAL UE CONTEXT TRANSFER message for NR SDT. An example for this new IE is shown in Table 9 as follows:

[0175] 9.2.3.164 Partial UE Context Information for SDT

[0176] This IE contains the UE context information within the PARTIAL UE CONTEXT TRANSFER message for NR SDT. [0177] TABLE 9

[0178] In one embodiment, the UE context failure message may be implemented as a

RETRIEVE UE CONTEXT FAILURE message as defined by Section 9.1.1.10 of the 3GPP TS 38.423 titled “Technical Specification Group Radio Access Network; NG-RAN; Xn application protocol (XnAP),” Release 17.0.0, April 2022 (2022-4) and Release 17.1.0, June 2022 (2022-06); both including any progeny, revisions or variants. Other message types and standards may be implemented as well. Embodiments are not limited in this context. [0179] Section 9.1.1.10 of the 3GPP TS 38.423, Release 17.0.0, provides an example of how new IES are added in a RETRIEVE UE CONTEXT FAILURE message to support SDT is shown in Table 10 as follows:

[0180] 9.1.1.10 RETRIEVE UE CONTEXT FAILURE

[0181] This message is sent by the old NG-RAN node (e.g., the old gNB 326) to inform the new NG-RAN node (e.g., the new gNB 324) that the RETRIEVE UE CONTEXT procedure has failed.

[0182] Direction: old NG-RAN node new NG-RAN node.

[0183] TABLE 10

[0184] The SDT Configuration IE may be implemented as shown in Table 11, as follows:

[0185] 9.2.3.XX2 SDT Configuration [0186] This IE includes necessary configuration information to process RLC PDUs and perform data forwarding related to SDT (small data transmission).

[0187] Table 11 [0188] The SDT Xn-U Context Information IE may be implemented in Table 12, as follows:

[0189] 9.2.3.XX3 SDT Xn-U Context Information

[0190] This IE includes information necessary to setup Xn-U bearers related to SDT (small data transmission). [0191] Table 12

[0192] The logic flow 900 and/or the message flow 1000 may be implemented by the apparatus 600 of a gNB 204, such as the old gNB 326 and/or the new gNB 324. In one example, an apparatus 600 for an access node, includes a memory interface 606 to send or receive, to or from a data storage device 610, small data transmission (SDT) information for SDT signaling between a first node such as the new gNB 324 and a second node such as the old gNB 326 of a radio access network 112. The apparatus 600 also includes processor circuitry 602 communicatively coupled to the memory interface 606, the processor circuitry 602 to decode a retrieve UE context request message received from the new gNB 324 of the radio access network 112 by a second node of the radio access network 112, the retrieve UE context request message to include the SDT information, generate a retrieve UE context request response message by the old gNB 326 of the radio access network 112, the retrieve UE context request response message to include an IE with one or more parameters to represent partial context information related to SDT for the UE, and send an indication to transmit the retrieve UE context request response message from the old gNB 326 to the new gNB 324.

[0193] The apparatus 600 may also include a signaling service 616 between the old gNB 326 and new gNB 324, the signaling service 616 to transmit the retrieve UE context request response message from the old gNB 326 to the new gNB 324 over an Xn interface in accordance with an Xn application protocol (XnAP) as defined by the 3GPP TS 38.423. [0194] The apparatus 600 may also include where the retrieve UE context request response message is defined in accordance with the 3GPP TS 38.423. For example, the retrieve UE context request response message may be implemented as a RETRIEVE UE CONTEXT FAILURE message as defined by the 3GPP TS 38.423.

[0195] The apparatus 600 may also include where the retrieve UE context request response message is a partial UE context transfer message. For example, the UE context request message may comprise, for example, a PARTIAL UE CONTEXT TRANSFER message as defined by the 3GPP TS 38.423. [0196] The apparatus 600 may also include where the retrieve UE context request response message is a partial UE context transfer message, and an IE group name for the IE of the partial UE context transfer message is a partial UE context information for SDT, the IE having a presence of optional. For example, the UE context request message may comprise, for example, a PARTIAL UE CONTEXT TRANSFER message with an IE named Partial UE Context Information for SDT as defined by the 3GPP TS 38.423.

[0197] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a PDU session resources to be added list or a PDU session resources to be added item.

[0198] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a DRBs to be setup list or a SDT DRBs to be setup list, the IE having a range of 0 to 1.

[0199] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a DRBs to be setup item or a SDT DRBs to be setup item, the IE having a range of 1 to a maximum number of DRBs, where the maximum number of DRBs allowed towards one UE is 32.

[0200] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a DRB identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with a value of 1 to 32.

[0201] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a UL PDCP UP TNL information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters.

[0202] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a UL TNL information, the IE having a presence of mandatory and one or more UP transport parameters.

[0203] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a DRB QoS, the IE having a presence of mandatory and one or more QoS flow level or QoS parameters.

[0204] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a PDCP SN length, the PDCP SN length IE includes a UL PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits, or the PDCP SN length includes a DL PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits. [0205] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a QoS flows mapped to DRB list or flows mapped to DRB list, the IE having a range of 1.

[0206] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a QoS flows mapped to DRB item or flows mapped to DRB item, the IE having a range of one to a maximum number of QoS flows, where the maximum number of QoS flows is 64.

[0207] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a QoS flow ID, the IE having a presence of mandatory and an IE type and reference of integer with values from 0 to 63.

[0208] The apparatus 600 may also include where an IE group name for the IE of the retrieve UE context request response message is a QoS flow mapping indication, the IE having an IE type and reference of enumerated with a value to indicate whether an uplink QoS is mapped to the DRB or a value to indicate whether a downlink QoS flow is mapped to the DRB .

[0209] On the other hand, in a split gNB architecture, the RLC processing may happen in a new DU of the new gNB 324 (e.g., the gNB-DU 210 of the new gNB 324) and data path will be from the new DU to the CU where the UE main context is located in case of uplink direction (e.g., the data path is opposite in case of downlink), which could be anchored in the last serving gNB (called anchoring) or it might be in a new CU of the new gNB 324 (e.g., the gNB-CU 214 of the new gNB 324) to which the DU is parented. If anchoring is used, the user-plane tunnel parameters are forwarded by the parent CU between the new DU and the anchoring CU (e.g., the CU of the last serving gNB). Or alternatively, for the anchoring CU, the parent CU (e.g., the CU of the new gNB) can process PDCP PDUs and forward the PDCP SDUs to the anchoring CU.

[0210] Other embodiments describe mechanisms to support transfer of RRC messages between the UE 202 and the old gNB 326 through the new gNB 324. There could be some RRC message exchange over signaling radio bearer (SRB) between the UE 202 and the old gNB 326 during a SDT session, for example, in-between a RRCResumeRequest message and a final RRC message from the old gNB 326 that terminates the SDT session. Forwarding of those PDCP PDUs between the new gNB 324 and the old gNB 326 is also new for RRC_INACTIVE as part of a new SDT procedure.

[0211] Conventionally, they are not carried via user -plane tunnel, and are instead carried through control plane. One possible implementation could be to enhance the XnAP RRC TRANSFER procedure (that has been defined for a DC, e.g., between a master node and secondary node) to carry PDCP PDUs for a SRB between the new gNB 324 and the old gNB 326.

[0212] Another possible implementation is to define a dedicated class-2 procedure (e.g., called "SRB TRANSFER") in XnAP to carry the SRB PDCP PDUs between the new gNB 324 and the old gNB 326, as shown in Table 13 as follows:

[0213] 9.1.1. YY SRB TRANSFER

[0214] This message is sent by the old NG-RAN node to the new NG-RAN node or by the new NG-RAN node to the old NG-RAN node to transfer a PDCP-C PDU encapsulating RRC message.

[0215] Direction: old NG-RAN node - new NG-RAN node or new NG-RAN node — > old NG-RAN node.

[0216] TABLE 13

[0217] On the other hand, in a split gNB architecture, the RLC processing will happen in a new DU (e.g., DU of the new gNB 324) and SRB path will be from the new DU to the CU where the UE main context is located in case of uplink direction (e.g., the path is opposite in case of downlink) - which could be anchored in the last serving gNB (called anchoring) or it might be in the CU of new gNB to which the DU is parented. If anchoring is used, the path would be between the DU and parent CU and the anchoring CU (e.g., the CU of the last serving gNB), or alternatively, for the anchoring CU, the parent CU (e.g., the CU of the new gNB 324) can process PDCP PDUs and forward the PDCP SDUs to the anchoring CU.

[0218] Other embodiments include mechanisms to support UE context release in a new gNB 324 when the old gNB 326 sends an RRC message to terminate a SDT session. When a SDT session is decided to be terminated by moving the UE 202 back to INACTIVE/IDLE, the old gNB 326 generates a final RRC message to be delivered to the UE 202 via the new gNB 324. The context in the new gNB 324 that was created to support SDT in a no anchor relocation scenario should also be removed together with this final RRC message. The old gNB 326 may decide to do so after several UL/DL SDT data exchange with the UE 202, e.g., some time after the context retrieval procedure, which is new for the RRC_IN ACTIVE procedure.

[0219] One possible implementation could be to enhance a new XnAP SRB TRANSFER procedure that is used to transfer the PDCP PDU of the final RRC message from the old gNB 326 to the new gNB 324 so that, upon receiving, the new gNB 324 delivers the final RRC message to the UE 202 and also removes the context. An example is shown in Table 14 as follows:

[0220] 9.1.1.YY SRB TRANSFER

[0221] This message is sent by the old NG-RAN node to the new NG-RAN node or by the new NG-RAN node to the old NG-RAN node to transfer a PDCP-C PDU encapsulating RRC message. [0222] Direction: old NG-RAN node new NG-RAN node or new NG-RAN node old NG-RAN node.

[0223] Table 14

[0224] Another possible implementation is to enhance an existing XnAP UE CONTEXT RELEASE procedure (that was designed to command the release of UE context) so that it is used to command the release of UE context in the new gNB 324 and also carry the PDCP PDU of the final RRC message from the old gNB 326. An example is shown in Table 15 as follows:

[0225] 9.1.1.5 UE CONTEXT RELEASE

[0226] This message is sent by the target NG-RAN node to the source NG-RAN node to indicate that resources can be released. [0227] In case of SDT, this message is sent by the target (new) NG-RAN node to the source (old) NG-RAN node, and vice versa.

[0228] Direction: target NG-RAN node — source NG-RAN node, M-NG-RAN node — S- NG-RAN node.

[0229] Direction: (in case of SDT), new NG-RAN node — old NG-RAN node, old NG- RAN node -4 new NG-RAN node.

[0230] Table 15

[0231] FIGS. 10-14 illustrate various systems, devices and components that may implement aspects of disclosed embodiments. The systems, devices, and components may be the same, or similar to, the systems, device and components described with reference to FIG. 1.

[0232] FIG. 11 illustrates a network 1100 in accordance with various embodiments. The network 1100 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like.

[0233] The network 1100 may include a UE 1102, which may include any mobile or non- mobile computing device designed to communicate with a RAN 1130 via an over-the-air connection. The UE 1102 may be communicatively coupled with the RAN 1130 by a Uu interface. The UE 1102 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in- car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.

[0234] In some embodiments, the network 1100 may include a plurality of UEs coupled directly with one another via a sidelink interface. The UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.

[0235] In some embodiments, the UE 1102 may additionally communicate with an AP 1104 via an over-the-air connection. The AP 1104 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 1130. The connection between the UE 1102 and the AP 1104 may be consistent with any IEEE 1102.11 protocol, wherein the AP 1104 could be a wireless fidelity (Wi-Fi®) router. In some embodiments, the UE 1102, RAN 1130, and AP 1104 may utilize cellular-WLAN aggregation (for example, LWA/LWIP). Cellular-WLAN aggregation may involve the UE 1102 being configured by the RAN 1130 to utilize both cellular radio resources and WLAN resources.

[0236] The RAN 1130 may include one or more access nodes, for example, AN 1160. AN 1160 may terminate air-interface protocols for the UE 1102 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and LI protocols. In this manner, the AN 1160 may enable data/voice connectivity between CN 1118 and the UE 1102. In some embodiments, the AN 1160 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool. The AN 1160 be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. The AN 1160 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0237] In embodiments in which the RAN 1130 includes a plurality of ANs, they may be coupled with one another via an X2 interface (if the RAN 1130 is an LTE RAN) or an Xn interface (if the RAN 1130 is a 5G RAN). The X2/Xn interfaces, which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.

[0238] The ANs of the RAN 1130 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 1102 with an air interface for network access. The UE 1102 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 1130. For example, the UE 1102 and RAN 1130 may use carrier aggregation to allow the UE 1102 to connect with a plurality of component carriers, each corresponding to a Pcell or Scell. In dual connectivity scenarios, a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG. The first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.

[0239] The RAN 1130 may provide the air interface over a licensed spectrum or an unlicensed spectrum. To operate in the unlicensed spectrum, the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells. Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol. [0240] In V2X scenarios the UE 1102 or AN 1160 may be or act as a RSU, which may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic. The RSU may provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communications services. The components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.

[0241] In some embodiments, the RAN 1130 may be an LTE RAN 1126 with eNBs, for example, eNB 1154. The LTE RAN 1126 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc. The LTE air interface may rely on CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operating on sub-6 GHz bands.

[0242] In some embodiments, the RAN 1130 may be an NG-RAN 1128 with gNBs, for example, gNB 1156, or ng-eNBs, for example, ng-eNB 1158. The gNB 1156 may connect with 5G-enabled UEs using a 5G NR interface. The gNB 1156 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface. The ng- eNB 1158 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface. The gNB 1156 and the ng-eNB 1158 may connect with each other over an Xn interface.

[0243] In some embodiments, the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 1128 and a UPF 1138 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN 1128 and an AMF 1134 (e.g., N2 interface).

[0244] The NG-RAN 1128 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data. The 5G- NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking. The 5G-NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.

[0245] In some embodiments, the 5G-NR air interface may utilize BWPs for various purposes. For example, BWP can be used for dynamic adaptation of the SCS. For example, the UE 1102 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 1102, the SCS of the transmission is changed as well. Another use case example of BWP is related to power saving. In particular, multiple BWPs can be configured for the UE 1102 with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 1102 and in some cases at the gNB 1156. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.

[0246] The RAN 1130 is communicatively coupled to CN 1118 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 1102). The components of the CN 1118 may be implemented in one physical node or separate physical nodes. In some embodiments, NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 1118 onto physical compute/storage resources in servers, switches, etc. A logical instantiation of the CN 1118 may be referred to as a network slice, and a logical instantiation of a portion of the CN 1118 may be referred to as a network subslice.

[0247] In some embodiments, the CN 1118 may be an LTE CN 1124, which may also be referred to as an EPC. The LTE CN 1124 may include MME 1106, SGW 1108, SGSN 1114, HSS 1116, PGW 1110, and PCRF 1112 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 1124 may be briefly introduced as follows.

[0248] The MME 1106 may implement mobility management functions to track a current location of the UE 1102 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc.

[0249] The SGW 1108 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 1124. The SGW 1108 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

[0250] The SGSN 1114 may track a location of the UE 1102 and perform security functions and access control. In addition, the SGSN 1114 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 1106; MME selection for handovers; etc. The S3 reference point between the MME 1106 and the SGSN 1114 may enable user and bearer information exchange for inter-3GPP access network mobility in idle/active states.

[0251] The HSS 1116 may include a database for network users, including subscription- related information to support the network entities’ handling of communication sessions. The HSS 1116 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc. An S6a reference point between the HSS 1116 and the MME 1106 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 1118.

[0252] The PGW 1110 may terminate an SGi interface toward a data network (DN) 1122 that may include an application/content server 1120. The PGW 1110 may route data packets between the LTE CN 1124 and the data network 1122. The PGW 1110 may be coupled with the SGW 1108 by an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 1110 may further include a node for policy enforcement and charging data collection (for example, PCEF). Additionally, the SGi reference point between the PGW 1110 and the data network 1122 may be an operator external public, a private PDN, or an intra- operator packet data network, for example, for provision of IMS services. The PGW 1110 may be coupled with a PCRF 1112 via a Gx reference point.

[0253] The PCRF 1112 is the policy and charging control element of the LTE CN 1124. The PCRF 1112 may be communicatively coupled to the app/content server 1120 to determine appropriate QoS and charging parameters for service flows. The PCRF 1110 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.

[0254] In some embodiments, the CN 1118 may be a 5GC 1152. The 5GC 1152 may include an AUSF 1132, AMF 1134, SMF 1136, UPF 1138, NSSF 1140, NEF 1142, NRF 1144, PCF 1146, UDM 1148, and AF 1150 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the 5GC 1152 may be briefly introduced as follows.

[0255] The AUSF 1132 may store data for authentication of UE 1102 and handle authentication-related functionality. The AUSF 1132 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 1152 over reference points as shown, the AUSF 1132 may exhibit an Nausf service-based interface.

[0256] The AMF 1134 may allow other functions of the 5GC 1152 to communicate with the UE 1102 and the RAN 1130 and to subscribe to notifications about mobility events with respect to the UE 1102. The AMF 1134 may be responsible for registration management (for example, for registering UE 1102), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 1134 may provide transport for SM messages between the UE 1102 and the SMF 1136, and act as a transparent proxy for routing SM messages. AMF 1134 may also provide transport for SMS messages between UE 1102 and an SMSF. AMF 1134 may interact with the AUSF 1132 and the UE 1102 to perform various security anchor and context management functions. Furthermore, AMF 1134 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 1130 and the AMF 1134; and the AMF 1134 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection. AMF 1134 may also support NAS signaling with the UE 1102 over an N3 IWF interface.

[0257] The SMF 1136 may be responsible for SM (for example, session establishment, tunnel management between UPF 1138 and AN 1160); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 1138 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 1134 over N2 to AN 1160; and determining SSC mode of a session. SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 1102 and the data network 1122.

[0258] The UPF 1138 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 1122, and a branching point to support multi-homed PDU session. The UPF 1138 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UU/DU rate enforcement), perform uplink traffic verification (e.g., SDF-to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 1138 may include an uplink classifier to support routing traffic flows to a data network.

[0259] The NSSF 1140 may select a set of network slice instances serving the UE 1102. The NSSF 1140 may also determine allowed NSSAI and the mapping to the subscribed S- NSSAIs, if needed. The NSSF 1140 may also determine the AMF set to be used to serve the UE 1102, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 1144. The selection of a set of network slice instances for the UE 1102 may be triggered by the AMF 1134 with which the UE 1102 is registered by interacting with the NSSF 1140, which may lead to a change of AMF. The NSSF 1140 may interact with the AMF 1134 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 1140 may exhibit an Nnssf service-based interface.

[0260] The NEF 1142 may securely expose services and capabilities provided by 3GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 1150), edge computing or fog computing systems, etc. In such embodiments, the NEF 1142 may authenticate, authorize, or throttle the AFs. NEF 1142 may also translate information exchanged with the AF 1150 and information exchanged with internal network functions. For example, the NEF 1142 may translate between an AF-Service-Identifier and an internal 5GC information. NEF 1142 may also receive information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 1142 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 1142 to other NFs and AFs, or used for other purposes such as analytics. Additionally, the NEF 1142 may exhibit an Nnef service-based interface.

[0261] The NRF 1144 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 1144 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF 1144 may exhibit the Nnrf service-based interface.

[0262] The PCF 1146 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior. The PCF 1146 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 1148. In addition to communicating with functions over reference points as shown, the PCF 1146 exhibit an Npcf service-based interface.

[0263] The UDM 1148 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 1102. For example, subscription data may be communicated via an N8 reference point between the UDM 1148 and the AMF 1134. The UDM 1148 may include two parts, an application front end and a UDR. The UDR may store subscription data and policy data for the UDM 1148 and the PCF 1146, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 1102) for the NEF 1142. The Nudr service-based interface may be exhibited by the UDR 221 to allow the UDM 1148, PCF 1146, and NEF 1142 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR. The UDM may include a UDM-FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management. In addition to communicating with other NFs over reference points as shown, the UDM 1148 may exhibit the Nudm service-based interface.

[0264] The AF 1150 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control. [0265] In some embodiments, the 5GC 1152 may enable edge computing by selecting operator/3^rd party services to be geographically close to a point that the UE 1102 is attached to the network. This may reduce latency and load on the network. To provide edgecomputing implementations, the 5GC 1152 may select a UPF 1138 close to the UE 1102 and execute traffic steering from the UPF 1138 to data network 1122 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 1150. In this way, the AF 1150 may influence UPF (re)selection and traffic routing. Based on operator deployment, when AF 1150 is considered to be a trusted entity, the network operator may permit AF 1150 to interact directly with relevant NFs. Additionally, the AF 1150 may exhibit an Naf service-based interface.

[0266] The data network 1122 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application/content server 1120.

[0267] FIG. 12 schematically illustrates a wireless network 1200 in accordance with various embodiments. The wireless network 1200 may include a UE 1202 in wireless communication with an AN 1224. The UE 1202 and AN 1224 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.

[0268] The UE 1202 may be communicatively coupled with the AN 1224 via connection 1246. The connection 1246 is illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols such as an ETE protocol or a 5G NR protocol operating at mmWave or sub-6GHz frequencies.

[0269] The UE 1202 may include a host platform 1204 coupled with a modem platform 1208. The host platform 1204 may include application processing circuitry 1206, which may be coupled with protocol processing circuitry 1210 of the modem platform 1208. The application processing circuitry 1206 may run various applications for the UE 1202 that source/sink application data. The application processing circuitry 1206 may further implement one or more layer operations to transmit/receive application data to/from a data network. These layer operations may include transport (for example UDP) and Internet (for example, IP) operations

[0270] The protocol processing circuitry 1210 may implement one or more of layer operations to facilitate transmission or reception of data over the connection 1246. The layer operations implemented by the protocol processing circuitry 1210 may include, for example, MAC, RLC, PDCP, RRC and NAS operations. [0271] The modem platform 1208 may further include digital baseband circuitry 1212 that may implement one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 1210 in a network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may include one or more of space-time, space-frequency or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

[0272] The modem platform 1208 may further include transmit circuitry 1214, receive circuitry 1216, RF circuitry 1218, and RF front end (RFFE) 1220, which may include or connect to one or more antenna panels 1222. Briefly, the transmit circuitry 1214 may include a digital-to-analog converter, mixer, intermediate frequency (IF) components, etc.; the receive circuitry 1216 may include an analog-to-digital converter, mixer, IF components, etc.; the RF circuitry 1218 may include a low-noise amplifier, a power amplifier, power tracking components, etc.; RFFE 1220 may include filters (for example, surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (for example, phase-array antenna components), etc. The selection and arrangement of the components of the transmit circuitry 1214, receive circuitry 1216, RF circuitry 1218, RFFE 1220, and antenna panels 1222 (referred generically as “transmit/receive components”) may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be disposed in the same or different chips/modules, etc.

[0273] In some embodiments, the protocol processing circuitry 1210 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.

[0274] A UE reception may be established by and via the antenna panels 1222, RFFE 1220, RF circuitry 1218, receive circuitry 1216, digital baseband circuitry 1212, and protocol processing circuitry 1210. In some embodiments, the antenna panels 1222 may receive a transmission from the AN 1224 by receive-beamforming signals received by a plurality of antennas/antenna elements of the one or more antenna panels 1222. [0275] A UE transmission may be established by and via the protocol processing circuitry 1210, digital baseband circuitry 1212, transmit circuitry 1214, RF circuitry 1218, RFFE 1220, and antenna panels 1222. In some embodiments, the transmit components of the UE 1224 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panels 1222.

[0276] Similar to the UE 1202, the AN 1224 may include a host platform 1226 coupled with a modem platform 1230. The host platform 1226 may include application processing circuitry 1228 coupled with protocol processing circuitry 1232 of the modem platform 1230. The modem platform may further include digital baseband circuitry 1234, transmit circuitry 1236, receive circuitry 1238, RF circuitry 1240, RFFE circuitry 1242, and antenna panels 1244. The components of the AN 1224 may be similar to and substantially interchangeable with like-named components of the UE 1202. In addition to performing data transmission/reception as described above, the components of the A 1204 may perform various logical functions that include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

[0277] FIG. 13 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, FIG. 13 shows a diagrammatic representation of hardware resources 1330 including one or more processors (or processor cores) 1310, one or more memory/storage devices 1322, and one or more communication resources 1326, each of which may be communicatively coupled via a bus 1320 or other interface circuitry. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1302 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1330.

[0278] The processors 1310 may include, for example, a processor 1312 and a processor 1314. The processors 1310 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0279] The memory/storage devices 1322 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1322 may include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

[0280] The communication resources 1326 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1304 or one or more databases 1306 or other network elements via a network 1308. For example, the communication resources 1326 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.

[0281] Instructions 106, 1318, 1324, 1328, 1332 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1310 to perform any one or more of the methodologies discussed herein. The instructions 106, 1318, 1324, 1328, 1332 may reside, completely or partially, within at least one of the processors 1310 (e.g., within the processor’s cache memory), the memory/storage devices 1322, or any suitable combination thereof. Furthermore, any portion of the instructions 106, 1318, 1324, 1328, 1332 may be transferred to the hardware resources 1330 from any combination of the peripheral devices 1304 or the databases 1306. Accordingly, the memory of processors 1310, the memory/storage devices 1322, the peripheral devices 1304, and the databases 1306 are examples of computer-readable and machine-readable media.

[0282] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

[0283] FIG. 14 illustrates computer readable storage medium 1400. Computer readable storage medium 1700 may comprise any non-transitory computer-readable storage medium or machine-readable storage medium, such as an optical, magnetic or semiconductor storage medium. In various embodiments, computer readable storage medium 1400 may comprise an article of manufacture. In some embodiments, computer readable storage medium 1400 may store computer executable instructions 1402 with which circuitry can execute. For example, computer executable instructions 1402 can include computer executable instructions 1402 to implement operations described with respect to logic flows 600 (deleted), 1100 (deleted) and 900. Examples of computer readable storage medium 1400 or machine-readable storage medium 1400 may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or nonremovable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. Examples of computer executable instructions 1402 may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like.

[0284] First Set of Examples

[0285] Example 1 may include the method for network to support small data transfer with the UE in a dormant state, the network providing information to the UE on how to initiate the procedure and how to process the data.

[0286] Example 2 may include where the system is 5G NR, and the dormant state is RRCJNACTIVE state.

[0287] Example 3 may include where the data may be sent in one packet or in separate sub-sequent packets over the radio.

[0288] Example 4 may include where the data sent over the radio is with a gNB in a split NG-RAN architecture, split into Centralized Unit (CU) and Distributed Unit (DU).

[0289] Example 5 as per example 4 or some other example herein, where the DU may inform small data transfer operation from the UE to the CU.

[0290] Example 6 may include as per example 5 or some other example herein, where a new message or an indicator in the existing message may be used.

[0291] Example 7 may include as per example 5 or some other example herein, where the CU may contact, among neighboring gNBs, a gNB that has previously served the UE and holds the UE context.

[0292] Example 8 may include as per example 7 or some other example herein, where the CU may inform small data transfer operation from the UE to the last serving gNB and may request for UE context information. [0293] Example 9 may include as per example 8 or some other example herein, where the last serving gNB may decide to keep the UE context.

[0294] Example 10 may include as per example 8 or some other example herein, where the last serving gNB may decide to move the UE context to the CU.

[0295] Example 11 may include as per example 8 or some other example herein, where the CU may provide information to assist the last serving gNB making decision as in example 9 or example 10.

[0296] Example 12 may include as per example 11 or some other example herein, where the information is the preference of CU for keeping the UE context in the last serving gNB or moving the UE context toward itself.

[0297] Example 13 may include as per example 4 or some other example herein, where the DU may provide its capability to the CU whether it supports small data transfer operation or not.

[0298] Example 14 may include as per example 13 or some other example herein, where the capability is provided based on support for context relocation or not.

[0299] Example 15 may include as per example 13 or some other example herein, where the capability is provided per cell.

[0300] Example 16 may include as per example 13 or some other example herein, where the capability may be provided via the interface setup or update procedure.

[0301] Example 17 may include as per example 13 or some other example herein, where the capability may be provided via the message that informs small data transfer operation to the CU.

[0302] Example 18 may include as per example 13 or some other example herein, where the capability may be provided via the message that carries the first data from the UE.

[0303] Example 19 may include as per example 8 or some other example herein, where the CU may provide its capability to the last serving gNB whether it supports small data transfer operation or not.

[0304] Example 20 may include as per example 19 or some other example herein, where the capability is provided based on support for context relocation or not.

[0305] Example 21 may include as per example 19 or some other example herein, where the capability is provided per cell.

[0306] Example 22 may include as per example 19 or some other example herein, where the capability may be provided via the interface setup or update procedure. [0307] Example 23 may include as per example 19 or some other example herein, where the capability may be provided via the message that informs small data transfer operation to the last serving gNB.

[0308] Example 24 may include as per example 19 or some other example herein, where the capability may be provided via the message that carries the first data from the UE.

[0309] Example 25 may include as per example 4 or some other example herein, where the CU may request DU to provide lower layer configuration for small data transfer operation for a UE.

[0310] Example 26 may include as per example 23 or some other example herein, where the request is via a message addressed to the UE in the DU.

[0311] Example 27 may include as per example 23 or some other example herein, where the request is via a message that may setup, release, or modify the UE context in the DU.

[0312] Example 28 may include as per example 23 or some other example herein, where the DU may generate the lower layer configuration for small data transfer operation for the UE and provide to the CU.

[0313] Example 29 may include as per example 26 or some other example herein, where the CU may configure the UE with small data transfer operation based on the lower layer configuration provided from the DU.

[0314] Second Set of Examples

[0315] Example 1 may include the method for network to support small data transfer with the UE in a dormant state, the network providing information to the UE on how to initiate the procedure and how to process the data.

[0316] Example 2 may include where the system is 5G NR, and the dormant state is RRCJNACTIVE state.

[0317] Example 3 may include where the data may be sent in one packet or in separate sub-sequent packets over the radio.

[0318] Example 4 may include where the data sent over the radio is with a gNB in a split NG-RAN architecture, split into Centralized Unit (CU) and Distributed Unit (DU).

[0319] Example 5 may include where the CU may contact, among neighboring gNBs, a gNB that has previously served the UE and holds the UE context.

[0320] Example 6 may include where the last serving gNB may decide to keep the UE context. [0321] Example 7 may include as per example 6 or some other example herein, where the last serving gNB may provide information for processing data or RRC message to/from the UE and transfer between the CU and the last serving gNB.

[0322] Example 8 may include as per example 7 or some other example herein, where the information is provided via a message in response to the message used in example 5.

[0323] Example 9 may include as per example 7 or some other example herein, where the data is in the form of PDCP SDU or SDAP SDU.

[0324] Example 10 may include as per example 6 or some other example herein, where the last serving gNB may provide information for processing data to/from the UE and data transfer between the DU and the last serving gNB.

[0325] Example 11 may include as per example 10 or some other example herein, where the data is in the form of PDCP PDU.

[0326] Example 12 may include as per example 10 or some other example herein, where the data may transfer through the CU.

[0327] Example 13 may include as per example 6 or some other example herein, where the last serving gNB may terminate the small data transfer procedure.

[0328] Example 14 may include as per example 13 or some other example herein, where the last serving gNB may send a RRC message that terminate the small data transfer procedure for a UE to the CU.

[0329] Example 15 may include as per example 14 or some other example herein, where the RRC message is sent to the UE.

[0330] Example 16 may include as per example 14 or some other example herein, a message that is used to transfer the RRC message that terminates the small data transfer procedure to the UE may indicate the release of UE context in the CU or DU or both.

[0331] Example 17 may include as per example 16 or some other example herein, the DU may release the UE context while delivering the RRC message to the UE in example 14.

[0332] Third Set of Examples

[0333] In one example, an example apparatus for an access node, includes a memory interface to send or receive, to or from a data storage device, small data transmission (SDT) information for SDT signaling between a gNodeB (gNB) distributed unit (gNB-DU) and a gNB central unit (gNB-CU) of a radio access network (RAN). The example apparatus also includes processor circuitry communicatively coupled to the memory interface, the processor circuitry to decode that a radio resource control (RRC) resume request message received from a user equipment (UE) in an inactive state is due to SDT by the gNB-DU, generate an initial uplink (UL) RRC message transfer message, the initial UL RRC message transfer message to include an information element (IE) with one or more parameters to indicate the RRC resume request is due to the SDT, and send an indication to transmit the initial UL RRC message transfer message from the gNB-DU to the gNB-CU, the initial UL RRC message transfer message to indicate a transfer of the RRC resume request message to the gNB-CU.

[0334] The example apparatus may also include, in combination with any previous example, radio frequency (RF) circuitry communicatively coupled to the processor circuitry, the RF circuitry to receive RF signals representing the RRC resume request message from the UE.

[0335] The example apparatus may also include, in combination with any previous example, a signaling service between the gNB-DU and the gNB-CU to provide UE- associated services, the signaling service to transmit the initial UL RRC message transfer message from the gNB-DU to the gNB-CU over a Fl interface in accordance with an Fl application protocol (F1AP).

[0336] The example apparatus may also include, in combination with any previous example, where the initial UL RRC message transfer message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.473.

[0337] The example apparatus may also include, in combination with any previous example, where an IE group name for the initial UL RRC message transfer message is a SDT initiation or a SDT information.

[0338] The example apparatus may also include, in combination with any previous example, where an IE group name for the initial UL RRC message transfer message is a SDT information, and where a presence for the IE is optional.

[0339] The example apparatus may also include, in combination with any previous example, where the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT indicator of an enumerated type with a Boolean parameter.

[0340] The example apparatus may also include, in combination with any previous example, where the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT assistant information of an enumerated type with a single packet parameter to indicate no subsequent SDT transmission is expected or a multiple packets parameter to indicate subsequent SDT transmission is expected. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0341] In one example, an example method for an access node, includes receiving an indication that a radio resource control (RRC) resume request message is received from a user equipment in an inactive state by a gNodeB (gNB) distributed unit (gNB-DU) of a radio access network (RAN), decoding that the RRC resume request message received from the UE is due to a small data transmission (SDT), generating an initial uplink (UL) RRC message transfer message, the initial UL RRC message transfer message to include an information element (IE) with one or more parameters to indicate the RRC resume request is due to the SDT, and send an indication to transmit the initial UL RRC message transfer message from the gNB-DU to a gNB central unit (gNB-CU), the initial UL RRC message transfer message to indicate a transfer of the RRC resume request message to the gNB-CU.

[0342] The example method may also include, in combination with any previous example, receiving radio-frequency (RF) signals representing the RRC resume request message from the UE.

[0343] The example method may also include, in combination with any previous example, transmitting the initial UL RRC message transfer message from the gNB-DU to the gNB- CU over a Fl interface in accordance with an Fl application protocol (F1AP).

[0344] The example method may also include, in combination with any previous example, where the initial UL RRC message transfer message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.473.

[0345] The example method may also include, in combination with any previous example, where an IE group name for the initial UL RRC message transfer message is a SDT initiation or a SDT information.

[0346] The example method may also include, in combination with any previous example, where an IE group name for the initial UL RRC message transfer message is a SDT information, and where a presence for the IE is optional.

[0347] The example method may also include, in combination with any previous example, where the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT indicator of an enumerated type with a Boolean parameter.

[0348] The example method may also include, in combination with any previous example, where the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT assistant information of an enumerated type with a single packet parameter to indicate no subsequent SDT transmission is expected or a multiple packets parameter to indicate subsequent SDT transmission is expected. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0349] In one example, a non-transitory computer-readable storage medium, the computer- readable storage medium including instructions that when executed by a computer, cause the computer to receive an indication that a radio resource control (RRC) resume request message is received from a user equipment in an inactive state by a gNodeB (gNB) distributed unit (gNB-DU) of a radio access network (RAN), decode that the RRC resume request message received from the UE is due to a small data transmission (SDT), generate an initial uplink (UL) RRC message transfer message, the initial UL RRC message transfer message to include an information element (IE) with one or more parameters to indicate the RRC resume request is due to the SDT, and send an indication to transmit the initial UL RRC message transfer message from the gNB-DU to a gNB central unit (gNB-CU), the initial UL RRC message transfer message to indicate a transfer of the RRC resume request message to the gNB-CU.

[0350] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to receive indications of radio-frequency (RF) signals representing the RRC resume request message from the UE.

[0351] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to transmit the initial UL RRC message transfer message from the gNB-DU to the gNB-CU over a Fl interface in accordance with an Fl application protocol (F1AP).

[0352] The example computer-readable storage medium may also include, in combination with any previous example, where the initial UL RRC message transfer message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.473.

[0353] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the initial UL RRC message transfer message is a SDT initiation or a SDT information.

[0354] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the initial UL RRC message transfer message is a SDT information, and where a presence for the IE is optional. [0355] The example computer-readable storage medium may also include, in combination with any previous example, where the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT indicator of an enumerated type with a Boolean parameter. [0356] The example computer-readable storage medium may also include, in combination with any previous example, where the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT assistant information of an enumerated type with a single packet parameter to indicate no subsequent SDT transmission is expected or a multiple packets parameter to indicate subsequent SDT transmission is expected. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0357] In one example, an example apparatus for an access node, includes a memory interface to send or receive, to or from a data storage device, small data transmission (SDT) information for SDT signaling between a gNodeB (gNB) distributed unit (gNB-DU) and a gNB central unit (gNB-CU) of a radio access network (RAN). The example apparatus also includes processor circuitry communicatively coupled to the memory interface, the processor circuitry to determine to modify user equipment (UE) context information for a UE by the gNB-CU of the RAN, generate a UE context modification request message to provide the modified UE context information to the gNB-DU of the RAN, the UE context modification request message to include an information element (IE) with one or more parameters to indicate a request for configuration information of the UE for SDT operation from the gNB-DU, and send an indication to transmit the UE context modification request message from the gNB-CU to the gNB-DU.

[0358] The example apparatus may also include, in combination with any previous example, the processor circuitry to determine to modify the UE context information in order to generate a configuration grant (CG) based SDT for the UE.

[0359] The example apparatus may also include, in combination with any previous example, a signaling service between the gNB-CU and the gNB-DU to provide UE- associated services, the signaling service to transmit the UE context modification request message from the gNB-CU to the gNB-DU over a Fl interface in accordance with an Fl application protocol (F1AP). [0360] The example apparatus may also include, in combination with any previous example, where the UE context modification request message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.473.

[0361] The example apparatus may also include, in combination with any previous example, where an IE group name for the UE context modification request message is a SDT configuration request or a configured grant (CG) SDT (CG-SDT) query indication. [0362] The example apparatus may also include, in combination with any previous example, where an IE group name for the UE context modification request message is a configured grant (CG) SDT (CG-SDT) query indication, and where a presence for the IE is optional.

[0363] The example apparatus may also include, in combination with any previous example, where an IE type and reference for the UE context modification request message is an enumerated type with a Boolean parameter.

[0364] The example apparatus may also include, in combination with any previous example, where the confirmation information includes physical layer (PHY) or medium access control (MAC) layer configuration of the UE.

[0365] The example apparatus may also include, in combination with any previous example, the processing circuitry to decode a UE context modification response message received from the gNB-DU in response to the UE context modification request message, the UE context modification response message to include the requested configuration information.

[0366] The example apparatus may also include, in combination with any previous example, the processing circuitry to generate a configured grant (CG) for CG SDT operation for the UE in response to receipt of configuration information from the gNB-DU.

[0367] The example apparatus may also include, in combination with any previous example, the processing circuitry to send an indication to transmit a message with a configured grant (CG) for CG SDT operation for the UE from the gNB-CU to the gNB-DU.

[0368] The example apparatus may also include, in combination with any previous example, a signaling service between the gNB-CU and the gNB-DU, the signaling service to transmit a message with a configured grant (CG) for CG SDT operation for the UE from the gNB-CU to the gNB-DU. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims. [0369] In one example, an example method for an access node, includes determining to modify user equipment (UE) context information for a UE by a gNB central unit (gNB-CU) of a radio access network (RAN), generating a UE context modification request message to provide the modified UE context information by a gNB distributed unit (gNB-DU) of the RAN, the UE context modification request message to include an information element (IE) with one or more parameters to indicate a request for configuration information of the UE for small data transmission (SDT) operation from the gNB-DU, and send an indication to transmit the UE context modification request message from the gNB-CU to the gNB-DU.

[0370] The example method may also include, in combination with any previous example, determining to modify the UE context information in order to generate a configuration grant (CG) based SDT for the UE.

[0371] The example method may also include, in combination with any previous example, transmitting the UE context modification request message from the gNB-CU to the gNB-DU over a Fl interface in accordance with an Fl application protocol (F1AP).

[0372] The example method may also include, in combination with any previous example, where the UE context modification request message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.473.

[0373] The example method may also include, in combination with any previous example, where an IE group name for the UE context modification request message is a SDT configuration request or a configured grant (CG) SDT (CG-SDT) query indication.

[0374] The example method may also include, in combination with any previous example, where an IE group name for the UE context modification request message is a configured grant (CG) SDT (CG-SDT) query indication, and where a presence for the IE is optional.

[0375] The example method may also include, in combination with any previous example, where an IE type and reference for the UE context modification request message is an enumerated type with a Boolean parameter.

[0376] The example method may also include, in combination with any previous example, where the confirmation information includes physical layer (PHY) or medium access control (MAC) layer configuration of the UE.

[0377] The example method may also include, in combination with any previous example, decoding a UE context modification response message received from the gNB-DU in response to the UE context modification request message, the UE context modification response message to include the requested configuration information. [0378] The example method may also include, in combination with any previous example, generating a configured grant (CG) for CG SDT operation for the UE in response to receipt of configuration information from the gNB-DU.

[0379] The example method may also include, in combination with any previous example, sending an indication to transmit a message with a configured grant (CG) for CG SDT operation for the UE from the gNB-CU to the gNB-DU.

[0380] The example method may also include, in combination with any previous example, transmitting a message with a configured grant (CG) for CG SDT operation for the UE from the gNB-CU to the gNB-DU. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0381] In one example, a non-transitory computer-readable storage medium, the computer- readable storage medium including instructions that when executed by a computer, cause the computer to determine to modify user equipment (UE) context information for a UE by a gNB central unit (gNB-CU) of a radio access network (RAN), generate a UE context modification request message to provide the modified UE context information by a gNB distributed unit (gNB-DU) of the RAN, the UE context modification request message to include an information element (IE) with one or more parameters to indicate a request for configuration information of the UE for small data transmission (SDT) operation from the gNB-DU, and send an indication to transmit the UE context modification request message from the gNB-CU to the gNB-DU.

[0382] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to determine to modify the UE context information in order to generate a configuration grant (CG) based SDT for the UE.

[0383] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to transmit the UE context modification request message from the gNB-CU to the gNB-DU over a Fl interface in accordance with an Fl application protocol (F1AP).

[0384] The example computer-readable storage medium may also include, in combination with any previous example, where the UE context modification request message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.473.

[0385] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the UE context modification request message is a SDT configuration request or a configured grant (CG) SDT (CG-SDT) query indication.

[0386] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the UE context modification request message is a configured grant (CG) SDT (CG-SDT) query indication, and where a presence for the IE is optional.

[0387] The example computer-readable storage medium may also include, in combination with any previous example, where an IE type and reference for the UE context modification request message is an enumerated type with a Boolean parameter.

[0388] The example computer-readable storage medium may also include, in combination with any previous example, where the confirmation information includes physical layer (PHY) or medium access control (MAC) layer configuration of the UE.

[0389] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to decode a UE context modification response message received from the gNB- DU in response to the UE context modification request message, the UE context modification response message to include the requested configuration information.

[0390] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to generate a configured grant (CG) for CG SDT operation for the UE in response to receipt of configuration information from the gNB-DU.

[0391] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to send an indication to transmit a message with a configured grant (CG) for CG SDT operation for the UE from the gNB-CU to the gNB-DU.

[0392] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to transmit a message with a configured grant (CG) for CG SDT operation for the UE from the gNB-CU to the gNB-DU. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0393] In one example, an example apparatus for an access node, includes a memory interface to send or receive, to or from a data storage device, small data transmission (SDT) information for SDT signaling between a first node and a second node of a radio access network (RAN). The example apparatus also includes processor circuitry communicatively coupled to the memory interface, the processor circuitry to decode a retrieve user equipment (UE) context request message received from a first node of a RAN by a second node of the RAN, the retrieve UE context request message to include the SDT information, generate a retrieve UE context request response message by the second node of the RAN, the retrieve UE context request response message to include an information element (IE) with one or more parameters to represent partial context information related to SDT for the UE, and send an indication to transmit the retrieve UE context request response message from the second node to the first node.

[0394] The example apparatus may also include, in combination with any previous example, a signaling service between the second node and the first node, the signaling service to transmit the retrieve UE context request response message from the second node to the first node over an Xn interface in accordance with an Xn application protocol (XnAP).

[0395] The example apparatus may also include, in combination with any previous example, where the retrieve UE context request response message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.423.

[0396] The example apparatus may also include, in combination with any previous example, where the retrieve UE context request response message is a retrieve UE context failure message.

[0397] The example apparatus may also include, in combination with any previous example, where the retrieve UE context request response message is a partial UE context transfer message.

[0398] The example apparatus may also include, in combination with any previous example, where the retrieve UE context request response message is a partial UE context transfer message, and an IE group name for the IE of the partial UE context transfer message is a partial UE context information for SDT, the IE having a presence of optional. [0399] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a protocol data unit (PDU) session resources to be added list or a PDU session resources to be added item.

[0400] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearers (DRBs) to be setup list or a SDT DRBs to be setup list, the IE having a range of 0 to 1. [0401] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearers (DRBs) to be setup item or a SDT DRBs to be setup item, the IE having a range of 1 to a maximum number of DRBs, where the maximum number of DRBs allowed towards one UE is 32.

[0402] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearer (DRB) identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with a value of 1 to 32.

[0403] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is an uplink (UL) packet data convergence protocol (PDCP) user plane (UP) transport network layer (TNL) information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters.

[0404] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is an uplink (UL) transport network layer (TNL) information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters.

[0405] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearer (DRB) quality of service (QoS), the IE having a presence of mandatory and one or more QoS flow level or QoS parameters.

[0406] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a packet data convergence protocol (PDCP) sequence number (SN) length, the PDCP SN length IE includes an uplink (UL) PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits, or the PDCP SN length includes a downlink (DL) PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits.

[0407] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flows mapped to data radio bearer (DRB) list or flows mapped to data radio bearer (DRB) list, the IE having a range of 1. [0408] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flows mapped to data radio bearer (DRB) item or flows mapped to data radio bearer (DRB) item, the IE having a range of one to a maximum number of QoS flows, where the maximum number of QoS flows is 64.

[0409] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flow identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with values from 0 to 63.

[0410] The example apparatus may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flow mapping indication, the IE having an IE type and reference of enumerated with a value to indicate whether an uplink QoS is mapped to the DRB or a value to indicate whether a downlink QoS flow is mapped to the DRB. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0411] In one example, an example method for an access node, includes decoding a retrieve user equipment (UE) context request message received from a first node of a radio access network (RAN) by a second node of the RAN, the retrieve UE context request message to include small data transmission (SDT) information, generating a retrieve UE context request response message by the second node of the RAN, the retrieve UE context request response message to include an information element (IE) with one or more parameters to represent partial context information related to SDT for the UE, and sending an indication to transmit the retrieve UE context request response message from the second node to the first node.

[0412] The example method may also include, in combination with any previous example, transmitting the retrieve UE context request response message from the second node to the first node over an Xn interface in accordance with an Xn application protocol (XnAP).

[0413] The example method may also include, in combination with any previous example, where the retrieve UE context request response message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.423.

[0414] The example method may also include, in combination with any previous example, where the retrieve UE context request response message is a retrieve UE context failure message. [0415] The example method may also include, in combination with any previous example, where the retrieve UE context request response message is a partial UE context transfer message.

[0416] The example method may also include, in combination with any previous example, where the retrieve UE context request response message is a partial UE context transfer message, and an IE group name for the IE of the partial UE context transfer message is a partial UE context information for SDT, the IE having a presence of optional.

[0417] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a protocol data unit (PDU) session resources to be added list or a PDU session resources to be added item.

[0418] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearers (DRBs) to be setup list or a SDT DRBs to be setup list, the IE having a range of 0 to 1.

[0419] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearers (DRBs) to be setup item or a SDT DRBs to be setup item, the IE having a range of 1 to a maximum number of DRBs, where the maximum number of DRBs allowed towards one UE is 32.

[0420] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearer (DRB) identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with a value of 1 to 32.

[0421] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is an uplink (UL) packet data convergence protocol (PDCP) user plane (UP) transport network layer (TNL) information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters.

[0422] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is an uplink (UL) transport network layer (TNL) information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters. [0423] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearer (DRB) quality of service (QoS), the IE having a presence of mandatory and one or more QoS flow level or QoS parameters.

[0424] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a packet data convergence protocol (PDCP) sequence number (SN) length, the PDCP SN length IE includes an uplink (UL) PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits, or the PDCP SN length includes a downlink (DL) PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits.

[0425] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flows mapped to data radio bearer (DRB) list or flows mapped to data radio bearer (DRB) list, the IE having a range of 1.

[0426] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flows mapped to data radio bearer (DRB) item or flows mapped to data radio bearer (DRB) item, the IE having a range of one to a maximum number of QoS flows, where the maximum number of QoS flows is 64.

[0427] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flow identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with values from 0 to 63.

[0428] The example method may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flow mapping indication, the IE having an IE type and reference of enumerated with a value to indicate whether an uplink QoS is mapped to the DRB or a value to indicate whether a downlink QoS flow is mapped to the DRB. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0429] In one example, a non-transitory computer-readable storage medium, the computer- readable storage medium including instructions that when executed by a computer, cause the computer to decode a retrieve user equipment (UE) context request message received from a first node of a radio access network (RAN) by a second node of the RAN, the retrieve UE context request message to include small data transmission (SDT) information, generate a retrieve UE context request response message by the second node of the RAN, the retrieve UE context request response message to include an information element (IE) with one or more parameters to represent partial context information related to SDT for the UE, and send an indication to transmit the retrieve UE context request response message from the second node to the first node.

[0430] The example computer-readable storage medium may also include, in combination with any previous example, instructions that when executed by a computer, cause the computer to transmit the retrieve UE context request response message from the second node to the first node over an Xn interface in accordance with an Xn application protocol (XnAP).

[0431] The example computer-readable storage medium may also include, in combination with any previous example, where the retrieve UE context request response message is defined in accordance with a third generation partnership project (3GPP) technical specification (TS) 38.423.

[0432] The example computer-readable storage medium may also include, in combination with any previous example, where the retrieve UE context request response message is a retrieve UE context failure message.

[0433] The example computer-readable storage medium may also include, in combination with any previous example, where the retrieve UE context request response message is a partial UE context transfer message.

[0434] The example computer-readable storage medium may also include, in combination with any previous example, where the retrieve UE context request response message is a partial UE context transfer message, and an IE group name for the IE of the partial UE context transfer message is a partial UE context information for SDT, the IE having a presence of optional.

[0435] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a protocol data unit (PDU) session resources to be added list or a PDU session resources to be added item.

[0436] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearers (DRBs) to be setup list or a SDT DRBs to be setup list, the IE having a range of 0 to 1.

[0437] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearers (DRBs) to be setup item or a SDT DRBs to be setup item, the IE having a range of 1 to a maximum number of DRBs, where the maximum number of DRBs allowed towards one UE is 32.

[0438] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearer (DRB) identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with a value of 1 to 32.

[0439] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is an uplink (UL) packet data convergence protocol (PDCP) user plane (UP) transport network layer (TNL) information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters.

[0440] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is an uplink (UL) transport network layer (TNL) information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters.

[0441] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a data radio bearer (DRB) quality of service (QoS), the IE having a presence of mandatory and one or more QoS flow level or QoS parameters.

[0442] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a packet data convergence protocol (PDCP) sequence number (SN) length, the PDCP SN length IE includes an uplink (UL) PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits, or the PDCP SN length includes a downlink (DL) PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits.

[0443] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flows mapped to data radio bearer (DRB) list or flows mapped to data radio bearer (DRB) list, the IE having a range of 1. [0444] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flows mapped to data radio bearer (DRB) item or flows mapped to data radio bearer (DRB) item, the IE having a range of one to a maximum number of QoS flows, where the maximum number of QoS flows is 64.

[0445] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flow identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with values from 0 to 63.

[0446] The example computer-readable storage medium may also include, in combination with any previous example, where an IE group name for the IE of the retrieve UE context request response message is a quality of service (QoS) flow map indication, the IE having an IE type and reference of enumerated with a value to indicate whether an uplink QoS is mapped to the DRB or a value to indicate whether a downlink QoS flow is mapped to the DRB. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

[0447] Terminology

[0448] For the purposes of the present document, the following terms and definitions are applicable to the examples and embodiments discussed herein.

[0449] The term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry. [0450] The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data. Processing circuitry may include one or more processing cores to execute instructions and one or more memory structures to store program and data information. The term “processor circuitry” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes. Processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer vision (CV) and/or deep learning (DL) accelerators. The terms “application circuitry” and/or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.”

[0451] The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like.

[0452] The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.

[0453] The term “network element” as used herein refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like.

[0454] The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and/or “system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources.

[0455] The term “appliance,” “computer appliance,” or the like, as used herein refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource. A “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource.

[0456] The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, workload units, and/or the like. A “hardware resource” may refer to compute, storage, and/or network resources provided by physical hardware element(s). A “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices/systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0457] The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.

[0458] The terms “instantiate,” “instantiation,” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

[0459] The terms “coupled,” “communicatively coupled,” along with derivatives thereof are used herein. The term “coupled” may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or link, and/or the like.

[0460] The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content.

[0461] The term “SMTC” refers to an SSB-based measurement timing configuration configured by SSB-MeasurementTimingConfiguration.

[0462] The term “SSB” refers to an SS/PBCH block.

[0463] The term “a “Primary Cell” refers to the MCG cell, operating on the primary frequency, in which the UE either performs the initial connection establishment procedure or initiates the connection re-establishment procedure.

[0464] The term “Primary SCG Cell” refers to the SCG cell in which the UE performs random access when performing the Reconfiguration with Sync procedure for DC operation. [0465] The term “Secondary Cell” refers to a cell providing additional radio resources on top of a Special Cell for a UE configured with CA.

[0466] The term “Secondary Cell Group” refers to the subset of serving cells comprising the PSCell and zero or more secondary cells for a UE configured with DC. [0467] The term “Serving Cell” refers to the primary cell for a UE in RRC_CONNECTED not configured with CA/DC there is only one serving cell comprising of the primary cell.

[0468] The term “serving cell” or “serving cells” refers to the set of cells comprising the Special Cell(s) and all secondary cells for a UE in RRC_CONNECTED configured with CAZ.

[0469] The term “Special Cell” refers to the PCell of the MCG or the PSCell of the SCG for DC operation; otherwise, the term “Special Cell” refers to the Pcell.

Claims

What is claimed is:

1. An apparatus for an access node, comprising: a memory interface to send or receive, to or from a data storage device, small data transmission (SDT) information for SDT signaling between a gNodeB (gNB) distributed unit (gNB-DU) and a gNB central unit (gNB-CU) of a radio access network (RAN); and processor circuitry communicatively coupled to the memory interface, the processor circuitry to: decode that a radio resource control (RRC) resume request message received from a user equipment (UE) in an inactive state is due to SDT by the gNB-DU; generate an initial uplink (UL) RRC message transfer message, the initial UL RRC message transfer message to include an information element (IE) with one or more parameters to indicate the RRC resume request is due to the SDT; and send an indication to transmit the initial UL RRC message transfer message from the gNB-DU to the gNB-CU, the initial UL RRC message transfer message to indicate a transfer of the RRC resume request message to the gNB-CU.

2. The apparatus of claim 1, comprising a signaling service between the gNB-DU and the gNB-CU to provide UE-associated services, the signaling service to transmit the initial UL RRC message transfer message from the gNB-DU to the gNB-CU over a Fl interface in accordance with an Fl application protocol (F1AP).

3. The apparatus of claim 1, wherein an IE group name for the initial UL RRC message transfer message is a SDT initiation or a SDT information.

4. The apparatus of claim 1, wherein an IE group name for the initial UL RRC message transfer message is a SDT information, and wherein a presence for the IE is optional.

5. The apparatus of claim 1, wherein the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT indicator of an enumerated type with a Boolean parameter.

6. The apparatus of claim 1, wherein the IE is used to indicate an SDT transaction and to provide assistant information from the UE, the IE to include SDT information, the SDT information to comprise a SDT assistant information of an enumerated type with a single packet parameter to indicate no subsequent SDT transmission is expected or a multiple packets parameter to indicate subsequent SDT transmission is expected.

7. The apparatus of claim 1, comprising radio frequency (RF) circuitry communicatively coupled to the processor circuitry, the RF circuitry to receive RF signals representing the RRC resume request message from the UE.

8. An apparatus for an access node, comprising: a memory interface to send or receive, to or from a data storage device, small data transmission (SDT) information for SDT signaling between a gNodeB (gNB) distributed unit (gNB-DU) and a gNB central unit (gNB-CU) of a radio access network (RAN); and processor circuitry communicatively coupled to the memory interface, the processor circuitry to: determine to modify user equipment (UE) context information for a UE by the gNB-CU of the RAN; generate a UE context modification request message to provide the modified UE context information to the gNB-DU of the RAN, the UE context modification request message to include an information element (IE) with one or more parameters to indicate a request for configuration information of the UE for SDT operation from the gNB-DU; and send an indication to transmit the UE context modification request message from the gNB-CU to the gNB-DU.

9. The apparatus of claim 8, the processor circuitry to determine to modify the UE context information in order to generate a configuration grant (CG) based SDT for the UE.

10. The apparatus of claim 8, comprising a signaling service between the gNB-CU and the gNB-DU to provide UE-associated services, the signaling service to transmit the UE context modification request message from the gNB-CU to the gNB-DU over a Fl interface in accordance with an Fl application protocol (F1AP).

11. The apparatus of claim 8, wherein an IE group name for the UE context modification request message is a SDT configuration request or a configured grant (CG) SDT (CG-SDT) query indication, and wherein a presence for the IE is optional.

12. The apparatus of claim 8, wherein an IE type and reference for the UE context modification request message is an enumerated type with a Boolean parameter.

13. The apparatus of claim 8, wherein the confirmation information comprises physical layer (PHY) or medium access control (MAC) layer configuration of the UE.

14. The apparatus of claim 8, the processing circuitry to decode a UE context modification response message received from the gNB-DU in response to the UE context modification request message, the UE context modification response message to include the requested configuration information.

15. The apparatus of claim 8, the processing circuitry to generate a configured grant (CG) for CG SDT operation for the UE in response to receipt of configuration information from the gNB-DU.

16. An apparatus for an access node, comprising: a memory interface to send or receive, to or from a data storage device, small data transmission (SDT) information for SDT signaling between a first node and a second node of a radio access network (RAN); and processor circuitry communicatively coupled to the memory interface, the processor circuitry to: decode a retrieve user equipment (UE) context request message received from a first node of a RAN by a second node of the RAN, the retrieve UE context request message to include the SDT information; generate a retrieve UE context request response message by the second node of the RAN, the retrieve UE context request response message to include an information element (IE) with one or more parameters to represent partial context information related to SDT for the UE; and send an indication to transmit the retrieve UE context request response message from the second node to the first node.

107

17. The apparatus of claim 16, comprising a signaling service between the second node and the first node, the signaling service to transmit the retrieve UE context request response message from the second node to the first node over an Xn interface in accordance with an Xn application protocol (XnAP).

18. The apparatus of claim 16, wherein the retrieve UE context request response message is a partial UE context transfer message, and an IE group name for the IE of the partial UE context transfer message is a partial UE context information for SDT, the IE having a presence of optional.

19. The apparatus of claim 16, wherein an IE group name for the IE of the retrieve UE context request response message is a protocol data unit (PDU) session resources to be added list or a PDU session resources to be added item.

20. The apparatus of claim 16, wherein an IE group name for the IE of the retrieve UE context request response message is a data radio bearers (DRBs) to be setup list or a SDT DRBs to be setup list, the IE having a range of 0 to 1.

21. The apparatus of claim 16, wherein an IE group name for the IE of the retrieve UE context request response message is a data radio bearers (DRBs) to be setup item or a SDT DRBs to be setup item, the IE having a range of 1 to a maximum number of DRBs, wherein the maximum number of DRBs allowed towards one UE is 32.

22. The apparatus of claim 21, wherein an IE group name for the IE of the retrieve UE context request response message is a data radio bearer (DRB) identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with a value of 1 to 32.

23. The apparatus of claim 21, wherein an IE group name for the IE of the retrieve UE context request response message is an uplink (UL) packet data convergence protocol (PDCP) user plane (UP) transport network layer (TNL) information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters.

24. The apparatus of claim 21, wherein an IE group name for the IE of the retrieve UE context request response message is an uplink (UL) transport network layer (TNL) information, the IE having a presence of mandatory and one or more user plane (UP) transport parameters.

108

25. The apparatus of claim 21, wherein an IE group name for the IE of the retrieve UE context request response message is: a data radio bearer (DRB) quality of service (QoS), the IE having a presence of mandatory and one or more QoS flow level or QoS parameters; a packet data convergence protocol (PDCP) sequence number (SN) length, the PDCP

SN length IE comprising an uplink (UL) PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits, or the PDCP SN length comprising a downlink (DL) PDCP SN length with a presence of mandatory and an IE type and reference of enumerated with values of 12 bits or 18 bits; a quality of service (QoS) flows mapped to data radio bearer (DRB) list or flows mapped to data radio bearer (DRB) list, the IE having a range of 1; a quality of service (QoS) flows mapped to data radio bearer (DRB) item or flows mapped to data radio bearer (DRB) item, the IE having a range of one to a maximum number of QoS flows, wherein the maximum number of QoS flows is 64; a quality of service (QoS) flow identifier (ID), the IE having a presence of mandatory and an IE type and reference of integer with values from 0 to 63; or a quality of service (QoS) flow mapping indication, the IE having an IE type and reference of enumerated with a value to indicate whether an uplink QoS is mapped to the DRB or a value to indicate whether a downlink QoS flow is mapped to the DRB.

109