CN117561776A - Small data transmission technology - Google Patents

Abstract

Embodiments attempt to address challenges in Small Data Transfer (SDT) systems. Embodiments describe various techniques, systems, and devices for supporting small data transmissions in a wireless communication system, such as a 3GPP 5G NR system. Other embodiments are described and claimed.

Description

Small data transmission technology

Cross Reference to Related Applications

The present application claims the benefit and priority of previously filed U.S. provisional patent application serial No. 63/270,363 entitled "SMALL DATA TRANSMISSION INFORMATION EXCHANGE BETWEEN NG RAN NODES" filed on day 21, 10, 2021 and previously filed U.S. provisional patent application serial No. 63/270,426 entitled "SMALL DATA TRANSMISSION SIGNALING SUPPORT FOR NO ANCHOR RELOCATION", filed on day 21, 10, 2021, both provisional patent applications being hereby incorporated by reference in their entirety.

Background

The use of wireless communication systems is growing rapidly. Furthermore, wireless communication technologies have evolved from voice-only communication to also include transmission of data, such as the internet and multimedia content, to various devices. To accommodate the increasing number of devices communicating, many wireless communication systems share available communication channel resources between the devices. Furthermore, the use of internet of things (IoT) devices is also growing and may coexist with user equipment in various wireless communication systems (e.g., cellular networks).

Drawings

To readily identify the discussion of any particular element or act, one or more of the most significant digits in a reference number refer to the figure number in which that element is first introduced.

Fig. 1 illustrates a wireless communication system according to one embodiment.

Fig. 2 illustrates a second wireless communication system according to one embodiment.

Fig. 3A illustrates a first message flow according to one embodiment.

Fig. 3B illustrates a second message flow according to one embodiment.

Fig. 4 illustrates a first logic flow in accordance with one embodiment.

Fig. 5 illustrates a third message flow according to one embodiment.

Fig. 6 shows an apparatus according to an embodiment.

FIG. 7 illustrates a second logic flow in accordance with one embodiment.

Fig. 8 illustrates a fourth message flow according to one embodiment.

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

Fig. 10 illustrates a fifth message flow according to one embodiment.

Fig. 11 illustrates a first network according to one embodiment.

Fig. 12 illustrates a second network according to one embodiment.

Fig. 13 illustrates a third network according to one embodiment.

FIG. 14 illustrates a computer-readable storage medium according to one embodiment.

Detailed Description

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 the various embodiments. However, it will be apparent to one skilled in the art having the benefit of this 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 this document, the phrases "A or B" and "A/B" mean (A), (B) or (A and B).

In many wireless communication systems, including Long Term Evolution (LTE) and fifth generation new air interface (5G NR) cellular networks, a User Equipment (UE) may need to transmit small amounts of data to a Base Station (BS) within the network. This is called Small Data Transfer (SDT). For example, in cellular internet of things (CIoT), a sensor device equipped with a communication device (e.g., a User Equipment (UE)) may take sensor readings and then send the readings or batch readings to a BS. Other examples include: an apparatus for mobile calling (MO) and mobile called (MT) use cases reporting a location via a BS is tracked. This disclosure describes, among other things, signaling mechanisms for supporting frequent small data transmissions with and without path switching between different base stations.

The 5G NR system may be defined, at least in part, by various third generation partnership project (3 GPP) Technical Standards (TS), technical Reports (TR), and/or Work Items (WI). The various embodiments discussed herein may be implemented in a wireless communication system as defined below: titled "Technical Specification Group Radio Access Network; NG-RAN; f1application protocol (F1 AP) ", version 17.0.0, 3gpp TS 38.473 month 4 of 2020; and titled "Technical Specification Group Radio Access Network; NG-RAN; xn application protocol (XnAP) ", version 17.0.0, release 4 in 2020 and version 17.1.0, 3gpp TS 38.423 for month 6 in 2020; both include any successes, revisions, or modifications. It is to be appreciated that embodiments may be implemented in accordance with other 3GPP TS and TR as well as other wireless standards promulgated by other standard entities. The embodiments are not limited in this context.

In a 5G NR system, e.g., defined by 3gpp TS 38.473 and/or TS28.423, a UE may enter different Radio Resource Control (RRC) states (e.g., idle state and connected state). The UE may also enter an inactive state in which the UE registers with the network but does not actively transmit data. The resume procedure may prepare the UE for subsequent data transmission by causing the UE to switch from the inactive state to the connected state. In 5G NR, RRC states of a UE for supporting 5G NR may include RRC IDLE, rrc_inactive, and rrc_connected states. When data is not transmitted in the rrc_connected state, the UE may switch to the rrc_inactive state, but still register with the network.

Whenever the UE is in the rrc_inactive state, it must switch to the rrc_connected state for data communication. However, this design introduces some inefficiency, especially for small or infrequent data that is not worth recovering the connection. To address this challenge, various 3GPP standards allow the UE to perform SDT while in rrc_inactive state without switching to rrc_connected state. The STD-enabled UE may initiate SDT by sending an RRC resume request message. SDT terminates when the UE is directed to an RRC IDLE state or rrc_inactive state (e.g., via an rrcressease message) or when the UE is directed to an rrc_connected state (e.g., via an rrcresseme message or an RRCSetup message). The initial UL SDT data is multiplexed with the RRC resume request message and during SDT there may be several UL/DL SDT data exchanges.

However, allowing the UE to perform SDT while in an INACTIVE state (e.g., rrc_inactive state) presents a new set of challenges, particularly when the access node (e.g., a gndeb (gNB) or eNodeB (eNB)) implements a split next generation radio access network (NG-RAN) architecture. The NG-RAN system may implement a gNB split architecture in which the gNB is split into multiple physical entities or nodes (e.g., a gNB distributed unit (gNB-DU) and a gNB central unit (gNB-CU)) that each perform a different set of operations or procedures. When the UE sends a resume request (e.g., via an rrcresme message), it is received by the gNB-DU. The gNB-DU may forward the resume request to the gNB-CU to inform the gNB-CU that the UE is requesting to resume the connection due to the SDT. Currently, the 3GPP standards do not define a standardized way for a gNB-DU to communicate a recovery request to a gNB-CU due to SDT.

Embodiments attempt to address these and other SDT related challenges. Embodiments describe various techniques, systems, and devices for supporting small data transmissions in a wireless communication system, such as a 3GPP 5G NR system. In one embodiment, for example, an apparatus for an access node (e.g., a gNB or eNB) may include a memory interface to send or receive SDT information to or from a data storage device for SDT signaling between gNB-DUs and gNB-CUs of a 3GPP Radio Access Network (RAN). The apparatus also includes a processor circuit communicatively coupled to the memory interface, the processor circuit to decode that the RRC restoration request message received by the gNB-DU from the UE in the inactive state is due to the SDT. The RRC recovery request message may include an SDT indication or other SDT information. The processor circuit may generate an initial Uplink (UL) RRC messaging message including an Information Element (IE) with one or more parameters for indicating that the RRC recovery request is due to the SDT information. The processor circuit may send an indication to send an initial UL RRC message transfer message from the gNB-DU to the gNB-CU, wherein the initial UL RRC message transfer message indicates a transfer of an RRC resume request message to the gNB-CU. Note that SDT may be in UL direction, downlink (DL) direction, or both. Other embodiments are described and claimed.

Another SDT challenge for the split NG-RAN architecture is to pass the underlying SDT configuration information for the UE between the gNB-CU and the gNB-DU before the gNB-CU sends the UE back to the rrc_inactive state. The gNB-CU may grant one or more "free" Physical Uplink Shared Channel (PUSCH) resources to the UE to initiate SDT without a Random Access Channel (RACH). The idle grant is defined by a Configuration Grant (CG), and the CG is configured for the UE via an RRCRelease message from the last serving cell for the UE. The resources indicated by CG are only valid when the UE is in the same serving cell, which means that the UE can initiate SDT only towards the same serving cell where it moves to rrc_inactive state.

In the split NG-RAN architecture, the gNB-DUs manage lower layers for the UE (e.g., medium Access Control (MAC) layer and/or Physical (PHY) layer (collectively referred to as MAC/PHY) configuration information for the UE). The gNB-DU manages and allocates scheduling resources for the UE operating the SDT. The gNB-CU regulates Radio Bearer (RB) configuration information and the UE's decision for SDT. Before the UE makes a decision on SDT, the gNB-CU needs the MAC/PHY configuration information for the UE from the gNB-DU in order to generate an RRCRelease message with CG for the UE. Currently, the 3GPP standard does not define a standardized way for gNB-CU and gNB-DU to communicate MAC/PHY configuration information for a UE to perform SDT operations. The challenge may also apply to RACH based SDT or any other type of SDT operation.

Embodiments attempt to address these and other SDT related challenges. Embodiments describe various techniques, systems, and devices for supporting small data transmissions in a wireless communication system, such as a 3GPP 5G NR system. In one embodiment, for example, an apparatus for an access node (e.g., a gNB or eNB) may include a memory interface to send or receive SDT information to or from a data storage device for SDT signaling between gNB-DUs of a 3GPP RAN and gNB-CUs. The apparatus may further include: a processor circuit communicatively coupled to the memory interface, the processor circuit to: determining that UE context information for the UE is modified by the gNB-CU of the RAN; generating a UE context modification request message to provide modified UE context information to a gNB-DU of the RAN, the UE context modification request message including an IE with one or more parameters indicating a request for configuration information of a UE for SDT operation from the gNB-DU; and sending an indication to send a UE context modification request message from the gNB-CU to the gNB-DU. The configuration information may include Medium Access Control (MAC) and/or Physical (PHY) layer information required for the UE based on configuration approval (CG) SDT. Note that SDT may be in UL direction, downlink (DL) direction, or both. Other embodiments are described and claimed.

Another challenge with 5G NR systems is that the UE maintains SDT capability when the UE switches (HO) between different serving cells. Various 3GPP standards are considering RACH-based and/or CG-based (e.g., configuration approval type-1) for SDT. When the UE is handed over from a last serving RAN node (e.g., gNB) (referred to as an "old RAN node" or "old gNB" or "anchor gNB") to a new RAN node (e.g., gNB) (referred to as a "new RAN node" or "new gNB"), the RACH-based SDT allows the UE to initiate an SDT session. In this case, the context information for the UE may be relocated to the new gcb or remain in the old gcb, which is decided by the old gcb. When the context information for the UE is not relocated to a new gNB, the information signaling and interaction (e.g., messages) may be similar to legacy cases (e.g., when the UE is supported with respect to periodic RAN Notification Area (RNA) updates). However, SDT may require different information signaling and interaction between the new and old gnbs. Currently, the 3GPP standards do not define a standardized way for the old and new gnbs to communicate information necessary for the UE to perform SDT operations when operating in the new gNB when context information is not relocated from the old to the new gNB.

Embodiments attempt to address these and other SDT related challenges. Embodiments describe various techniques, systems, and devices for supporting small data transmissions in a wireless communication system, such as a 3GPP 5G NR system. In one embodiment, for example, an apparatus for an access node (e.g., a gNB or eNB) includes a memory interface for transmitting to or receiving 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 further include: a processor circuit communicatively coupled to the memory interface, the processor circuit to: decoding an acquire UE context request message received by a second node of the RAN from a first node of the RAN, the acquire UE context request message including SDT information; generating, by a second node of the RAN, an acquire UE context request response message including an IE with one or more parameters representing part of the context information related to the SDT for the UE; and sending an indication to obtain the UE context request response message from the second node to the first node. Note that SDT may be in UL direction, downlink (DL) direction, or both. Other embodiments are described and claimed.

Referring now to the drawings, in which 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 may 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.

Fig. 1 illustrates an example of a wireless communication system 100. For convenience, and not limitation, the example wireless communication system 100 is described in the context of Long Term Evolution (LTE) and fifth generation (5G) new air interface (NR) (5G NR) cellular network communication standards defined by one or more 3GPP Technical Specifications (TS) and/or Technical Reports (TR). However, other types of wireless standards are possible.

The wireless communication system 100 includes a UE 102a and a UE 102b (collectively, "UE 102"). In this example, UE 102 is shown as a smartphone (e.g., a handheld touch screen mobile computing device connectable to one or more cellular networks). In other examples, any of the UEs 102 may include other mobile or non-mobile computing devices (e.g., consumer electronics, 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-vehicle entertainment (ICE) devices, dashboard (ICs), heads-up display (HUD) devices, on-board diagnostics (OBD) devices, dashboard mobile Devices (DME), mobile Data Terminals (MDT), electronic Engine Management Systems (EEMS), electronic/Engine Control Units (ECU), electronic/Engine Control Modules (ECM), embedded systems, microcontrollers, control modules, engine Management Systems (EMS), networking or "smart" devices, machine Type Communication (MTC) devices, machine-to-machine (M2M) devices, internet of things (IoT) devices, or combinations thereof, etc.

In some implementations, any UE 102 may be an IoT UE that may include a network access layer designed for low power IoT applications that utilize short term UE connections. IoT UEs may utilize technologies such as M2M or MTC for exchanging data with MTC servers or devices using, for example, public Land Mobile Networks (PLMNs), proximity services (ProSe), device-to-device (D2D) communications, sensor networks, ioT networks, or combinations thereof, and the like. The M2M or MTC data exchange may be a machine initiated data exchange. The IoT network describes interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure) with short-term connections. The IoT UE may execute a background application (e.g., keep-alive messages or status updates) to facilitate connection of the IoT network.

UE 102 is configured to connect (e.g., communicatively couple) with a Radio Access Network (RAN) 112. In some implementations, RAN 112 may be a next generation RAN (NG RAN), an evolved UMTS terrestrial radio access network (E-UTRAN), or a legacy RAN (e.g., 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 RAN 112 operating in 5G NR wireless communication system 100, and the term "E-UTRAN" may refer to RAN 112 operating in LTE or 4G wireless communication system 100.

For connection to RAN 112, ue 102 utilizes connections (or channels) 118 and 120, respectively, each of which may include a physical communication interface or layer described below. In this example, connections 118 and 120 are shown as air interfaces to enable communicative coupling, and may conform to cellular communication protocols (e.g., global system for mobile communications (GSM) protocols, code Division Multiple Access (CDMA) network protocols, push-to-talk (PTT) protocols, push-to-talk (POC) protocols, universal Mobile Telecommunications System (UMTS) protocols, 3GPP LTE protocols, 5G NR protocols, or combinations thereof, among other communication protocols).

UE 102b is shown configured to access an Access Point (AP) 104 (also referred to as "WLAN node 104", "WLAN termination 104", "WT 104", etc.) using connection 122. Connection 122 may comprise a local wireless connection (e.g., a connection conforming to any IEEE 802.11 protocol), where AP 104 would comprise a wireless fidelity (Wi-Fi) router. In this example, the AP 104 is shown connected to the internet rather than to the core network of a wireless system described in further detail below.

RAN 112 may include one or more nodes (e.g., RAN nodes 106a and 106b (collectively, "RAN nodes 106" or "RAN node 106")) implementing connections 118 and 120. As used herein, the terms "access node," "access point," and the like may describe devices that provide radio baseband functionality for data or voice connections or both between a network and one or more users. These access nodes may be referred to as Base Stations (BS), gNodeB, gNB, eNodeB, eNB, nodeB, RAN nodes, roadside units (RSUs), transmitting-receiving points (TRxP or TRP), and links, and may include ground stations (e.g., terrestrial access points), or satellite stations (e.g., cells) that provide coverage within a geographic area, and so forth. As used herein, the term "NG RAN node" may refer to a RAN node 106 (e.g., a gNB) operating in the 5G NR wireless communication system 100, and the term "E-UTRAN node" may refer to a RAN node 106 (e.g., an eNB) operating in the LTE or 4G wireless communication system 100. In some implementations, the RAN node 106 may be implemented as one or more of a dedicated physical device (e.g., a macrocell base station) or a Low Power (LP) base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, less user capacity, or higher bandwidth than the macrocell.

In some implementations, some or all of the RAN nodes 106 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as a Cloud RAN (CRAN) or virtual baseband unit pool (vbup). CRAN or vBBUP can implement RAN functional splitting, for example: packet Data Convergence Protocol (PDCP) split, wherein Radio Resource Control (RRC) and PDCP layers are operated by CRAN/vbup, while other layer two (e.g., data link layer) protocol entities are operated by separate RAN nodes 106; medium Access Control (MAC)/physical layer (PHY) split, where RRC, PDCP, MAC and Radio Link Control (RLC) layers are operated by CRAN/vbup, and PHY layers are operated by separate RAN nodes 106; or "lower PHY" split, where RRC, PDCP, RLC and MAC layers and upper portions of the PHY layers are operated by CRAN/vBBUP, while lower portions of the PHY layers are operated by separate RAN nodes 106. The virtualization framework allows the release processor core of the RAN node 106 to execute, for example, other virtualized applications. In some implementations, the individual RAN nodes 106 may represent individual gNB Distributed Units (DUs) that are connected to a gNB Central Unit (CU) using individual F1 interfaces (not shown in fig. 1). In some implementations, the gNB-DU may include one or more remote radio heads or RFEMs, and the gNB-CU may be operated by a server located in RAN 112 (not shown) or by a server pool in a similar manner as CRAN/vbBBUP. Additionally or alternatively, one or more of the RAN nodes 106 may be a next generation eNB (ng-eNB) and provide E-UTRA user plane and control plane protocol terminated RAN nodes towards the UE 102 and connect to a 5G core network (e.g., core network 114) using a next generation interface.

In a vehicle-to-everything (V2X) scenario, one or more of the RAN nodes 106 may be or may act as an RSU. The term "roadside unit" or "RSU" refers to any traffic infrastructure entity for V2X communications. The RSUs may be implemented in or by suitable RAN nodes or fixed (or relatively fixed) UEs, wherein the RSUs implemented in or by the UEs may be referred to as "UE-type RSUs", the RSUs implemented in or by the enbs may be referred to as "eNB-type RSUs", the RSUs implemented in or by the gnbs may be referred to as "gNB-type RSUs", and so on. In some implementations, the RSU is a computing device coupled with a radio frequency circuit located at the roadside that provides connectivity support for the passing vehicle UE 102 (vUE 102). The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, and applications or other software to sense and control ongoing vehicle and pedestrian traffic. The RSU may operate over the 5.9GHz Direct Short Range Communication (DSRC) band to provide the extremely low latency communications required for high speed events (e.g., collision avoidance, traffic alerting, etc.). Additionally or alternatively, the RSU may operate over a cellular V2X frequency band to provide the low latency communications described above, as well as other cellular communication 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 of the RSU and some or all of the radio frequency circuitry may be enclosed in a weather-proof 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 or both.

Any RAN node 106 may terminate the air interface protocol and may be the first point of contact for the UE 102. In some implementations, any RAN node 106 may perform various logic functions for RAN 112 including, but not limited to, radio Network Controller (RNC) functions (e.g., radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, mobility management, etc.).

In some implementations, the UE 102 may be configured to communicate with each other or any RAN node 106 using Orthogonal Frequency Division Multiplexing (OFDM) communication signals 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 herein is not limited in this respect. The OFDM signal may comprise a plurality of orthogonal subcarriers.

The RAN node 106 may transmit signals to the UE 102 over various channels. Various examples of downlink communication channels include a Physical Broadcast Channel (PBCH), a Physical Downlink Control Channel (PDCCH), and a Physical Downlink Shared Channel (PDSCH). Other types of downlink channels are possible. The UE 102 may send signals to the RAN node 106 over various channels. Various examples of uplink communication channels include a Physical Uplink Shared Channel (PUSCH), a Physical Uplink Control Channel (PUCCH), and a Physical Random Access Channel (PRACH). Other types of uplink channels are possible.

In some implementations, the downlink resource grid may be used for downlink transmissions from any RAN node 106 to the UE 102, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is a physical resource in the downlink in each time slot. This 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 the radio frame. The smallest time-frequency unit in a resource grid is called a resource element. Each resource grid contains several resource blocks that describe the mapping of specific physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this may represent the minimum number of resources that can be currently allocated. There are several different physical downlink channels transmitted using these resource blocks.

PDSCH carries user data and higher layer signaling to UE 102. The PDCCH carries information about a transport format and resource allocation etc. associated with the PDSCH channel. It may also inform the UE 102 of 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 UEs 102b within a cell) may be performed at any RAN node 106 based on channel quality information fed back from any UE 102. The downlink resource assignment information may be transmitted on a PDCCH for (e.g., assigned to) each of the UEs 102.

The PDCCH uses Control Channel Elements (CCEs) to convey control information. The PDCCH complex-valued symbols may first be organized into quadruples before being mapped to resource elements, and the quadruples may then be arranged for rate matching using a sub-block interleaver. In some implementations, each PDCCH may be transmitted using one or more of these CCEs, where 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. Depending on the downlink control protocol (DCI) and channel conditions, the PDCCH may be transmitted using one or more CCEs. In LTE, there may be four or more different PDCCH formats defined with different numbers of CCEs (e.g., aggregation level, l=1, 2, 4, or 8).

Some implementations may use the concept of resource allocation for control channel information, which is an extension of the above described concept. For example, some implementations may utilize 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 the above, each ECCE may correspond to nine sets of four physical resource elements collectively referred to as Enhanced REGs (EREGs). ECCE may have other amounts of EREGs.

RAN nodes 106 may be configured to communicate with each other using interface 132. In examples where, for example, wireless communication system 100 is an LTE system (e.g., when core network 114 is an Evolved Packet Core (EPC) network), 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, etc.) connected to the EPC 114 or between two enbs connected to the EPC 114 or both. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted over the X2 interface and may be used to communicate information about the delivery of user data between enbs. For example, X2-U may provide specific sequence number information for user data transmitted from a primary eNB to a secondary eNB; information about successful sequential delivery of PDCP Protocol Data Units (PDUs) from the secondary eNB to the UE 102 for user data; information of PDCP PDUs not delivered to the UE 102; other information about the current minimum expected buffer size at the secondary eNB for transmitting user data to the UE. X2-C may provide: an LTE access mobility function including context transfer from source to target eNB or user plane transfer control, etc.; a load management function; other information such as inter-cell interference coordination function.

In some implementations, for example, where wireless communication system 100 is a 5G NR system (e.g., when core network 114 is a 5G core network), interface 132 may be an Xn interface 132. An Xn interface may be defined between two or more RAN nodes 106 (e.g., two or more gnbs, etc.) connected to the 5G core network 114, between a RAN node 106 (e.g., a gNB) connected to the 5G core network 114 and an eNB, and/or between two enbs connected to the 5G core network 114, or a combination thereof. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U may provide non-guaranteed delivery of user plane PDUs and support/provide data forwarding and flow control functions. An Xn-C may provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for a UE 102 in a CONNECTED mode (e.g., CM-CONNECTED) includes other functions such as functions for managing UE mobility between one or more RAN nodes 106 for the CONNECTED mode. Mobility support may include context transfer from the old (source) serving RAN node 106 to the new (target) serving RAN node 106, and control of user plane tunnels between the old (source) serving RAN node 106 to the new (target) serving RAN node 106. The protocol stack of the Xn-U may include a transport network layer built on top of an Internet Protocol (IP) transport layer and a User Datagram Protocol (UDP) or GPRS tunneling protocol (GTP-U) layer for the user plane or both on top of the IP layer to carry the user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol, referred to as an Xn application protocol (Xn-AP or XnAP), and a transport network layer built on top of a Stream Control Transmission Protocol (SCTP). SCTP may be on top of the IP layer and may provide guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transport 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 the same as or similar to the user plane and/or control plane protocol stacks shown and described herein.

RAN 112 is shown communicatively coupled to a core network 114 (referred to as "CN 114"). CN 114 may include a plurality of network elements (e.g., network element 108a and network element 108b (collectively, "network elements 108")) configured to provide various data and telecommunications services to clients/subscribers (e.g., users of UEs 102) connected to CN 114 using RAN 112. The components of CN 114 may be implemented in one physical node or in a separate physical node, and may include components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some implementations, network Function Virtualization (NFV) may be used to virtualize some or all of the network node functions described herein using executable instructions stored in one or more computer-readable storage media, as described in further detail below. The logical instantiation of the CN 114 may be referred to as a network slice, while the logical instantiation of a portion of the CN 114 may be referred to as a network sub-slice. NFV architecture and infrastructure can be used to virtualize one or more network functions alternatively performed by proprietary hardware onto physical resources including industry standard server hardware, storage hardware, or a combination of switches. In other words, the NFV system may be used to perform virtual or reconfigurable implementations of one or more network components or functions, or both.

The application server 110 may be an element that provides an application (e.g., UMTS Packet Service (PS) domain, LTE PS data service, etc.) that uses IP bearer resources with the core network. The application server 110 may also be configured to support one or more communication services (e.g., voIP session, PTT session, group communication session, social networking service, etc.) for the UE 102 using the CN 114. Application server 110 may communicate with one or more network elements 108a using IP communication interface 130.

In some implementations, CN 114 may be a 5G core network (referred to as "5gc 114" or "5G core network 114"), and RAN 112 may connect with CN 114 using next generation interface 124. In some implementations, the next generation interface 124 can be split into two parts: a next generation user plane (NG-U) interface 114 that carries traffic data between the RAN node 106 and a User Plane Function (UPF); and an S1 control plane (NG-C) interface 126, which is a signaling interface between the RAN node 106 and an access and mobility management function (AMF). The CN 114 is an example of a 5G core network discussed in more detail with respect to later figures.

In some implementations, CN 114 may be an EPC (referred to as "EPC 114," etc.), and RAN 112 may connect with CN 114 using S1 interface 124. In some implementations, the S1 interface 124 can be split into two parts: an S1 user plane (S1-U) interface 128 that carries traffic data between the RAN node 106 and a serving gateway (S-GW); and an S1-MME interface 126, which is a signaling interface between the RAN node 106 and a Mobility Management Entity (MME).

As previously described, in some implementations, the individual RAN nodes 106 may be implemented as a gNB split architecture that includes multiple gNB-DUs that are connected to the gNB-CU using individual F1 interfaces. An example of a gNB split architecture for the RAN node 106 is shown in fig. 2.

Fig. 2 illustrates a wireless communication system 200. The wireless communication system 200 is a subsystem of the wireless communication system 100 shown in fig. 1. The wireless communication system 200 depicts a UE 202 connected to a gNB 204 through a connection 212. UE 202 and connection 212 are similar to UE 102 and 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.

As depicted in fig. 2, the gNB 204 is divided into two physical entities called a centralized or Central Unit (CU) and a Distributed Unit (DU). The gNB 204 may include a gNB-CU 214 and one or more gNB-DUs 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.gNB-CU-CP 206 and GNB-CU-UP 208 communicate via the E1 interface. gNB-CU-CP 206 communicates with one or more gNB-DUs 210 through the F1-C interface. The gNB-CU-UP 208 communicates with one or more gNB-DUs 210 through the F1-U interface.

The gNB-CU-CP 206 and gNB-CU-UP 208 provide support for higher layers of the 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 the Radio Link 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-DUs 210. For example, the gNB 204 may have more than 100 gNB-DUs 210 connected to a single gNB-CU 214. Each gNB-DU 210 is capable of supporting one or more cells, wherein one gNB 204 can potentially control hundreds of cells in a 5G NR system.

As previously described, in a 5G NR system, e.g., defined by 3gpp TS 38.473 and/or TS28.423, UE 202 may enter different RRC states (e.g., idle state and connected state). The UE 202 may also enter an inactive state in which the UE 202 registers with the network, but does not actively transmit data. The resume procedure may prepare the UE 202 for subsequent data transmission by causing the UE 202 to switch from the inactive state to the connected state. In 5G NR, RRC states of a UE for supporting 5G NR may include RRC IDLE, rrc_inactive, and rrc_connected states. When data is not transmitted in the rrc_connected state, the UE 202 may switch to the rrc_inactive state, but still register with the network. An example of the UE 202 implementing the resume procedure when switching to the connected state is described with reference to fig. 3A.

Fig. 3A illustrates a message flow 300a that provides an example of a recovery procedure for Small Data Transfer (SDT), wherein the UE 202 enters an rrc_connected state prior to SDT operation. In message flow 300a, the wireless system includes a UE 202, a plurality of RAN nodes (e.g., a new RAN 302 and an old RAN 304), and a device 306 that provides UPF. From time to time, the UE 202 may need to send small amounts of data, referred to as SDT in 3 GPP. In this example, the context for the UE 202 is stored at the old RAN 304, referred to as the "anchor point" for the UE 202. The UE 202 begins communicating with the new RAN 302 while in the rrc_inactive state 308. UE 202 in rrc_inactive state 308 sends message 310 to new RAN 302. Message 310 may include an RRC resume request message to the new RAN 302. At block 312, the new RAN 302 and the old RAN 304 perform UE context acquisition and forward tunnel establishment procedures. The new RAN 302 sends a message 314 to the UE 202. Message 314 may include an RRC restore message. The RRC resume message causes the UE 202 to enter the rrc_connected state 316. The UE 202 begins sending one or more messages 318 to the UPF 306. The message 318 may include an SDT message. At block 320, the UE 202 and the new RAN 302 perform a connection inactivity procedure. The connection inactivity procedure may include: causing UE 202 to switch back to rrc_inactive state 308. For subsequent SDTs, the UE 202 may initiate an SDT session by sending a message 322 to the new RAN 302. Message 322 may include an RRC resume request message.

As indicated in message flow 300a of fig. 3A, whenever UE 202 is in rrc_inactive state, it must switch to rrc_connected state for SDT. However, this design introduces some inefficiency, especially for small or infrequent data that is not worth recovering the connection. To address this challenge, various 3GPP standards allow the UE 202 to perform SDT while in rrc_inactive state 202, rather than having to switch to rrc_connected state. When the UE 202 is a STD-enabled UE, the UE 202 may initiate SDT by sending an RRC resume request message. SDT terminates when UE 202 is directed to an RRC IDLE state or rrc_inactive state (e.g., via an rrcressease message) or when UE is directed to an rrc_connected state (e.g., via an rrcresseme message or an RRCSetup message). The initial UL SDT data is multiplexed with the RRC resume request message and during SDT there may be several UL/DL SDT data exchanges. An example of the UE 202 implementing the resume procedure without switching to the connected state is described with reference to fig. 3B.

Fig. 3B illustrates a message flow 300B that provides an example of a recovery procedure for Small Data Transfer (SDT) without the UE 202 entering the rrc_connected state prior to SDT operation. As previously described, RACH-based SDT allows UE 202 to initiate an SDT session on a new gNB 324 that is a gNB other than the old gNB 326 (e.g., anchor gNB). The UE context may be relocated to the new gNB 324 or remain in the old gNB 326, which is decided by the old gNB 326. 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 specifically, message flow 300b provides an example of RACH-based SDT with anchor relocation procedure defined by various 3GPP standards (e.g., 3GPP TS 38.423 and TS 38.300, among other 3GPP and non-3GPP standards).

In message flow 300b, the wireless system includes UE 202, a plurality of RAN nodes implemented as gNB nodes (e.g., new gNB 324 and old gNB 326), and a device 328 that provides access and mobility management functions (AMFs). From time to time, the UE 202 may need to send small amounts of data, referred to as SDT in 3 GPP. In this example, the context for the UE 202 is stored at the old gNB 326, referred to as the "anchor point" for the UE 202.

Message flow 300b illustrates an example of message exchange initiated by an RRC resume request containing a small data indication. In some implementations, the message may be implemented as an XnAP message generated and sent based on other 3GPP and non-3GPP standards such as 3GPP TS 38.423.

In this example, UE 202 sends a small data indication to new gNB 324, where old gNB 326 provides an RRC release configuration or message to new gNB 324 via a context acquisition procedure. The UE 202 indicates its small data intent during the recovery procedure. In block 330, UE 202 in rrc_inactive state sends message 332 to new gNB 324 as an RRC resume request message. The RRC resume request message is conveyed through SRB0 and it includes a small data indication with UL SDT data.

At block 334, the new gNB 324 determines that the initial UL SDT data is for the old gNB 326. The new gNB 324 passes the small data indication to the old gNB 326 in message 336 via an XnAP message, so the message includes the small data indication. The old gNB 326 may send message 338 as an XnAP get UE context request message. The old gNB 326 may determine whether to relocate the anchor point. The anchor point is when a path switch is triggered from the new gNB 324 as the normal UE 202 triggers a transmission from rrc_inactive to rrc_connected scenario, as described in section 9.2.2.4.1 of 3gpp TS 38.300.

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

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 an XnAP DL data forwarding address indication message to the old gNB 326 as legacy. Legacy has provided the UL NG user plane interface (NG-U) Transport Network Layer (TNL) at the User Plane Function (UPF) to the new gNB 324 via the XnAP acquire UE context response message, meaning that UL data does not have to pass through the old gNB 326.

At block 344, the UPF 358 and the UE 202 perform a procedure for DL SDT data forwarding. The new gNB 324 sends message 346 to the AMF 328 as a path switch request message. In response, the AMF 328 sends a message 348 to the new GNB 324 as a path-switch request acknowledgement message. 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 to the UE 202 as an RRC release message (e.g., RRCRelease) or an RRC resume message (e.g., rrcreseume). The new gNB 324 then sends a message 356 to the AMF 328 as a UE context release message.

As discussed with reference to message flow 300a, a NR rrc_inactive procedure has been devised in which the UE 202 should resume a connection with a network node for any data transmission. However, this design introduces some inefficiency, especially for small or infrequent data that is not worth recovering the connection. To this end, the 3GPP standards body has a Small Data Transfer (SDT) WI (e.g., release 17) to allow for small data transfer during rrc_inactive without entering rrc_connected, as depicted in message flow 300 b. SDT is initiated by any SDT-capable UE 202 by sending an RRC resume request message and terminates when UE 202 is directed (via RRCRelease) to RRC IDLE or rrc_inactive or (via rrcreseume or RRCSetup) to rrc_connected. The initial UL SDT data is multiplexed with the resume request message and during SDT there may be several UL/DL SDT data exchanges.

3GPP SDT WI is considering RACH-based (2 steps or 4 steps) and CG-based (configuration approval type-1) for SDT. RACH-based SDT allows UE 202 to initiate SDT sessions on new gNB 324 (except for old gNB 326 (also referred to as anchor gNB)). In this case, the UE context may be relocated to the new gNB 324 or remain in the old gNB 326, which is decided by the old gNB 326. Message flow 300b depicts a signaling flow for the case where the old gNB 326 decides to relocate the context to the new gNB 324. This process may be referred to as RACH based SDT with anchor relocation.

As described herein, embodiments may involve several signaling enhancements to support SDT in a split gNB architecture and assistance information from the new gNB 324 to help the old gNB 326 make decisions to relocate or maintain context for the SDT. Notably, the new mechanism described herein assumes that RRC signaling (e.g., RRCResumeRequest and RRCRelease) is involved when exchanging SDTs. However, similar operations may also be implemented without this RRC signaling (e.g., when UE 202 is accessing in a cell storing UE context). Embodiments may include, for example: (1) A mechanism for the DU to indicate to the CU the initiation of the SDT from the UE; (2) A mechanism for the new gNB to provide assistance information that helps the last serving gNB make a decision to relocate or maintain the context for the SDT; (3) A mechanism for the DU to indicate a CU to reveal whether it can support the capability of "anchor-free relocation" scenarios for SDT; (4) A mechanism for a CU to reveal to another CU whether it supports the capabilities of SDT; and (5) a mechanism for the CU to indicate to the DU to provide lower layer SDT configuration before the CU sends the UE back to INACTIVE. The described signaling and information seamlessly enables small data transfers during NR INACTIVE and works in a split NG-RAN architecture to help the serving network node make better decisions when choosing a connection management point for the UE for overall system performance optimization. Furthermore, embodiments may be directed to the 3GPP radio access network three (RAN 3) specifications for other 3GPP standards, such as F1AP and XnAP, and non-3GPP standards. The embodiments are not limited in this context.

Operations for the disclosed embodiments may be further described with reference to the following figures. Some of the figures may include logic flows. Although these 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 described herein can be implemented. Moreover, it is not necessary that a given logic flow be executed in the order presented unless otherwise indicated. Moreover, not all acts illustrated in a logic flow may be required in some embodiments. Furthermore, 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.

Fig. 4 illustrates an embodiment of a logic flow 400. Logic flow 400 may be representative of some or all of the operations executed by one or more embodiments described herein. For example, logic flow 400 comprises some or all of the operations performed by a device or entity (e.g., gNB 204) within wireless communication system 100 or wireless communication system 200. More specifically, logic flow 400 illustrates a use case where the gNB 204 implements a gNB split architecture and includes techniques for gNB-DU 210 to indicate to gNB-CU 214 the initiation of an SDT session from UE 202. For example, the gNB-DU 210 may forward the RRC resume request message received from the UE 202 to the gNB-CU 214 to indicate that the RRC resume request message is due to the SDT. The embodiments are not limited in this context.

In block 402, the logic flow 400 receives an indication that a gNodeB (gNB) distributed unit (gNB-DU) of a Radio Access Network (RAN) receives a Radio Resource Control (RRC) resume request message from a user equipment in an inactive state. For example, the gNB-DU 210 serves a cell for the new RAN 302. UE 202 is in a cell for new RAN 302 and in 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.

In block 404, the logic flow 400 decodes that the RRC resume request message received from the UE is due to a Small Data Transfer (SDT). For example, the gNB-DU 210 decodes the RRC resume request message received from the UE 202 based on the initial UL data multiplexed together due to Small Data Transfer (SDT). The RRC recovery request message may include an indication of Small Data Transfer (SDT).

In block 406, the logic flow 400 generates an initial Uplink (UL) RRC messaging message including an Information Element (IE) with one or more parameters for indicating that the RRC recovery request is due to the SDT. For example, the gNB-DU 210 generates an initial Uplink (UL) RRC message transfer message including an Information Element (IE) with one or more parameters for indicating that the RRC recovery request is due to the SDT.

In block 408, logic flow 400 sends an indication to send an initial UL RRC message transfer message from a gNB-DU to a gNB central unit (gNB-CU), the initial UL RRC message transfer message indicating transfer of an RRC resume request message to the gNB-CU. For example, gNB-DU 210 transmits an indication to transmit an initial UL RRC message transfer message from gNB-DU 210 to gNB-CU 214. The initial UL RRC message transfer message indicates transfer of an RRC resume request message to the gNB-CU 214. The gNB-DU 210 sends a UL RRC messaging message to the gNB-CU 214 using a signaling service (e.g., F1 interface) using the F1 application protocol (F1 AP).

Fig. 5 shows a message flow 500. Message flow 500 provides an example of messages for supporting logic flow 400. As depicted in fig. 5, the UE 202 generates information appropriate for the SDT. UE 202 is in rrc_inactive state 502. In the case of RACH based SDT, RA specific resources may be used for SDT initiation and RACH resources shared for SDT and non-SDT. As such, the UE 202 generates an RRC resume request message (e.g., RRCResumeRequest) that includes the SDT indication or other SDT information. The UE 202 sends a message 504 to the new RAN 302 as an RRC resume request message, implemented in the 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 message 506 to the gNB-CU 214 over the F1 interface using the F1 AP. At block 508, UE 202 and gNB-CU 214 perform procedures to perform SDT with UE 202 in rrc_inactive state 502 or with UE 202 entering an rrc_connected state (not shown). The UE 202 begins sending one or more messages 510 to the UPF 306 (not shown) via the gNB 204. Message 510 may comprise an SDT message. If the UE 202 previously entered the rrc_connected state 316 at block 508, the UE 202 and the gNB 204 optionally perform a connection inactivity procedure at block 512. The connection inactivity procedure may include: causing UE 202 to switch back to rrc_inactive state 514.

In the case of a split NG-RAN architecture where the receiving gNB 204 splits into gNB-CU 214 and gNB-DU 210, the gNB-DU 210 may learn of SDT initiation by: (1) multiplexed initial UL SDT data; (2) RA specific resources used (e.g., when RA resources are allocated for RACH based SDT); or (3) configuration approval (CG) (CG-based SDT) for use with the assigned C-RNTI. However, the current 3GPP standards do not define a different recovery cause specific SDT within the RRCResumeRequest message generated by the UE 202. As a result, when forwarding the received RRCResumeRequest message to the gNB-CU 214, some mechanism for the gNB-DU 210 to indicate to the gNB-CU 214 that the UE 202 requested recovery due to SDT may be desirable.

One possible implementation is to add a new recovery reason (e.g., a cell with the appropriate parameters) in the rrcresemerequest message. Another possible implementation is to enhance the F1AP initial UL RRC messaging message to forward the received RRCResumeRequest message to indicate that the recovery request is due to SDT.

Referring again to FIG. 5, gNB-DU 210 sends message 506 to gNB-CU 214. Message 506 may represent an initial UL RRC messaging message. In one embodiment, the initial UL RRC messaging message may be implemented as indicated by the heading "Technical Specification Group Radio Access Network; NG-RAN; f1 application protocol (F1 AP) ", version 17.0.0, 3gpp TS 38.473, month 4 of 2020, section 9.2.3.1 (including any successor, revision and modification) defined INITIAL UL RRC MESSAGE TRANSFER message. Other message types and standards may be implemented as well. The embodiments are not limited in this context.

An example of how a new Information Element (IE) may be added in an INITIAL UL RRC MESSAGE TRANSFER message to support or indicate that the recovery request is due to SDT is shown in table 1 as follows:

9.2.3.1 initial UL RRC message transmission

The message is sent by the gNB-DU to communicate an initial layer 3 message to the gNB-CU over the F1 interface.

The direction is: gNB-DU→gNB-CU

TABLE 1

Fig. 6 illustrates an apparatus 600 suitable for the 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, apparatus 600 includes a memory interface 606 for sending Small Data Transfer (SDT) information to data storage device 610 or receiving Small Data Transfer (SDT) information from data storage device 610 for SDT signaling between gNB-DU 210 and gNB-CU 214 of radio access network 112. The apparatus 600 further comprises a processor circuit 602 communicatively coupled to the memory interface 606, the processor circuit 602 comprising a decoder 604 for decoding that the RRC recovery request message received by the gNB-DU 210 from the UE in the inactive state is due to the SDT. The processor circuit 602 may include a decider 620 that makes a logical decision to support SDT operation. The processor circuit 602 may include a generator 608 to generate an initial Uplink (UL) RRC messaging message including an Information Element (IE) with one or more parameters to indicate that the RRC recovery request is due to the SDT. Processor circuitry 602 may include interface 612 to send an indication to send an initial UL RRC message transfer message from the gNB-DU 210 to the gNB-CU 214, the initial UL RRC message transfer message indicating transfer of an RRC resume request message to the gNB-CU 214.

The apparatus may further include a Radio Frequency (RF) circuit 618 communicatively coupled to the processor circuit 602, the RF circuit 618 receiving an RF signal from the UE 202 representative of the RRC recovery request message.

The apparatus may further include a signaling service 616 between the gNB-DU and the gNB-CU to provide UE association services, the signaling service sending an initial UL RRC messaging message from the gNB-DU 210 to the gNB-CU 214 over the F1 interface in accordance with the F1 application protocol (F1 AP). Interface 612 outputs an indication for transmission to transceiver 614 implementing signaling service 616. The signaling service 616 may include, for example, an F1 interface that operates in accordance with 3GPP TS 38.473 and other F1 APs defined in 3GPP and non-3GPP standards.

The generator 608 of the apparatus 600 may generate the initial UL RRC messaging message according to the third generation partnership project (3 GPP) Technical Specification (TS) 38.473.

The generator 608 of the apparatus 600 may generate an initial UL RRC messaging message, wherein an IE group name for the initial UL RRC messaging message is SDT initiation or SDT information.

The generator 608 of the apparatus 600 may generate an initial UL RRC messaging message, wherein an IE group name for the initial UL RRC messaging message is SDT information, and wherein the presence for the IE is optional.

The generator 608 of the apparatus 600 may generate an initial UL RRC messaging message, wherein the IE is to indicate an SDT transaction and provide assistance information from the UE, the IE includes SDT information including an SDT indicator having an enumeration type of boolean parameters (e.g., TRUE or FALSE), the enumeration type of TRUE indicating that the UL RRC messaging message for transmitting the RRC resume request is due to SDT.

The generator 608 of the apparatus 600 may generate the initial UL RRC message transfer message according to 3gpp TS 38.473, section 9.3.1.262 SDT Information. For example, the initial UL RRC messaging message may include an IE indicating an SDT transaction and providing assistance information from the UE. The IEs may include SDT information (e.g., IE type with mandatory (M) presence and enumerated type with boolean parameters (e.g., TRUE or FALSE) and the IE group name of the referenced SDT indicator). Additionally or alternatively, the IEs may include SDT information (e.g., SDT assistance information with the presence of optional (O) and an enumerated type of IE type and a referenced IE group name, the enumerated type including a single packet parameter for indicating that no subsequent SDT transmissions are expected or a multiple packet parameter for indicating that subsequent SDT transmissions are expected).

The apparatus 600 may be implemented by the gNB 204 to address SDT challenges: when the gNB 204 utilizes a gNB split or split architecture, a normalization process is provided to support or indicate that the recovery request is due to SDT.

Another SDT challenge for the split NG-RAN architecture is to pass the underlying SDT configuration information for the UE 202 between the gNB-CU 214 and the gNB-DU 210 before the gNB-CU 214 sends the UE back to the rrc_inactive state. The gNB-CU 214 may grant one or more idle PUSCH resources to the UE 202 to initiate SDT without RACH. The idle grant is defined by a Configuration Grant (CG), and the CG is configured for the UE via an RRCRelease message from the last serving cell (e.g., old RAN 304) for the UE 202. The resources indicated by CG are only valid when the UE 202 is in the same serving cell (e.g., new RAN 302), meaning that the UE 202 can only initiate SDT towards the same serving cell where it moves to rrc_inactive state.

In the split NG-RAN architecture, the gNB-DU 210 manages lower layers for the UE (e.g., MAC/PHY configuration information for the UE 202). The gNB-DU 210 manages and allocates scheduling resources for the UE 202 while performing SDT. The gNB-CU 214 manages RB configuration information and decisions by the UE 202 regarding SDT. Before the UE 202 makes a decision on SDT, 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 CG-based SDT for the UE 202. Currently, the 3GPP standards do not define a standardized way for gNB-CU 214 and gNB-DU 210 to communicate MAC/PHY configuration information for UE 202 to perform SDT operations. The challenge may also apply to RACH based SDT or any other type of SDT operation.

Embodiments attempt to address these and other SDT related challenges. Embodiments describe various techniques, systems, and devices for supporting small data transmissions in a wireless communication system, such as a 3GPP 5G NR system.

Fig. 7 illustrates a logic flow 700. Logic flow 700 may be representative of some or all of the operations executed by one or more embodiments described herein. For example, logic flow 700 may comprise some or all of the operations performed by a device or entity (e.g., gNB 204) within wireless communication system 100 or wireless communication system 200. More specifically, logic flow 700 illustrates a use case where the gNB 204 implements a gNB split architecture, wherein the gNB-DU 210 sends configuration information for the UE 202 to the gNB-CU 214, and thus the gNB-CU 214 may generate a CG-based SDT for the UE 202 based on the configuration information. The embodiments are not limited in this context.

In block 702, logic flow 700 determines that a gNB central unit (gNB-CU) of a Radio Access Network (RAN) modifies User Equipment (UE) context information for the UE. For example, an apparatus 600 for an access node (e.g., a gNB 204 or eNB) may include a memory interface 606 for transmitting to a data storage device 610 or receiving from the 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. Apparatus 600 may further include a processor circuit 602 communicatively coupled to memory interface 606, processor circuit 602 including a determiner 620 to determine that the gNB-CU 214 of RAN 112 modifies the context information for UE 202.

In block 704, logic flow 700 generates a UE context modification request message to provide modified UE context information to a gNB distributed unit (gNB-DU) of the RAN, the UE context modification request message including an Information Element (IE) having one or more parameters to indicate a request for configuration information of a UE for Small Data Transfer (SDT) operation from the gNB-DU. For example, processor circuitry 602 may generate a UE context modification request message to provide modified UE context information to the gNB-DU 210 of RAN 112, the UE context modification request message including an IE with one or more parameters indicating a request for configuration information for SDT operation of UE 202 from the gNB-DU 210.

In block 706, logic flow 700 sends an indication to send a UE context modification request message from the gNB-CU to the gNB-DU. For example, the processor circuit 602 may transmit an indication for transmission to the transceiver 614. Transceiver 614 may send a UE context modification request message from gNB-CU 214 to gNB-DU 210 through signaling service 616. The signaling service 616 may send a UE context modification request message over the F1 interface according to the F1 AP.

Fig. 8 shows a message flow 800. Message flow 800 provides an example of messages for supporting logic flow 700. As depicted in fig. 8, at block 802, the gNB-CU 214 determines to modify the UE context information for the UE 202 in order to generate a CG-based SDT for the UE 202. Before making a decision for the SDT for 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 CG-based SDT for the UE 202.

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

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

gNB-CU 214 receives 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. In response to receiving the configuration information from the gNB-DU 210, the gNB-CU 214 generates a CG-based SDT for SDT operation of the UE 202. The gNB-CU 214 then generates 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 perform a connection inactivity procedure or an SDT termination procedure. The connection inactivity procedure may include: an RRCRelea message with CG-based SDT is sent to UE 202, thereby causing UE 202 to switch back to rrc_inactive state. For subsequent SDTs, the UE 202 may use CG-based SDTs for future SDTs. The UE 202 may initiate the SDT session by sending an RRC resume request (e.g., RRCResumeRequest) message to the gNB 204 that includes the SDT information.

Currently, the 3GPP standards do not define a standardized way for gNB-CU 214 and gNB-DU 210 to communicate MAC/PHY configuration information for UE 202 to perform SDT operations. The challenge may also apply to 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 acquisition over the F1 interface using the F1 AP.

Referring again to fig. 8, the gNB-CU 214 generates a message 804 as a UE context modification request message to provide modified UE context information regulated by the gNB-DU 210. The UE context modification request message includes an IE with one or more parameters indicating a request from the gNB-DU 210 for configuration information of the UE 202 for SDT operation and sends a message 804 to the gNB-DU 210. The configuration information may include MAC and/or PHY layer information for the UE 202. In one embodiment, the UE context modification request message may be implemented as a message entitled "Technical Specification Group Radio Access Network; NG-RAN; f1 application protocol (F1 AP) ", release 17.0.0, 3gpp TS 38.473, month 4 of 2020, section 9.2.2.7 (including any successor, revision and modification). Other message types and standards may be implemented as well. The embodiments are not limited in this context.

An example of how a new cell (IE) may be added in a UE CONTEXT MODIFICATION REQUEST message to support SDT is shown in table 2 as follows:

9.2.2.7 UE context modification request

The message is sent by the gNB-CU to provide the gNB-DU with the UE context information change.

The direction is: gNB-CU- & gtgNB-DU

TABLE 2

Referring again to fig. 6, the apparatus 600 may include a processor circuit 602 to generate a UE context modification request message according to 3gpp TS 38.473, section 9.2.2.7. As indicated in table 2, the processor circuit 602 may generate a UE context modification request message, wherein an IE group name for the UE context modification request message is an SDT configuration request or configuration approval (CG) SDT (CG-SDT) query indication.

As further indicated in table 2, the processor circuit 602 may generate a UE context modification request message, wherein an IE group name for the UE context modification request message is a configuration approval (CG) SDT (CG-SDT) query indication, and wherein presence for the IE is optional.

As further indicated in table 2, the processor circuit 602 may generate a UE context modification request message, wherein the IE type and reference for the UE context modification request message is an enumeration type with boolean parameters.

Other embodiments describe mechanisms for the new gNB 324 to provide assistance information that helps the old gNB 326 regarding whether to relocate the context or keep the context for the SDT session to make decisions. RACH based SDT allows UE 202 to initiate SDT sessions on a new gNB 324, except the anchor gNB. In this case, the UE context may be relocated to the new gNB 324 or remain in the old gNB 326, which is decided by the old gNB 326.

Relocation may be desirable if the SDT procedure requires a long time. On the other hand, if the SDT session is short, it may be more appropriate to keep the context in the old gNB 326. In fact, the decision may be based on various factors (e.g., UE mobility mode or DL data event).

For this case, some assistance information from the new gNB 324 may be useful in XnAP RETRIEVE UE CONTEXT REQUEST messages to help the old gNB 326 make the context transfer decision. The side information that has been discussed so far is in the form of whether the SDT session is to be one-time or multiple times, or based on the amount of SDT data. However, it is not yet determined how the new gNB 324 can determine how long the SDT session will last when it requests context acquisition. The BSR from UE 202 is a good indicator, however, it may not be sent with the rrcresmerequest from the beginning. The new gNB 324 may have a difficult time making this determination based on the initial UL SDT data fit into the approved size of the MSG 3/MSGA. Further, at this point, DL data does not even reach the new gNB 324.

Rather than attempting to estimate an answer to the question of how long the "SDT session will last," what may be more useful is preference information from the new gNB 324. Once the old gNB 326 has decided not to relocate the context, intermediate relocation of the SDT session is not allowed. Accordingly, preference information about the new gNB 324 is preferably provided at the beginning of the SDT process.

There may be cases where: the new gNB 324 (which has SDT capabilities) does not support "anchor-free relocation" scenarios that require different processing than legacy cases. In this case, the new gNB 324 should be able to indicate a preference for "anchor relocation" to prevent a decision to keep as much context as possible from the old gNB 326. On the other hand, the new gNB 324 may not want to assume the anchor role for the UE 202 (e.g., if too many UEs are under its connection management). The new gNB 324 should be able to indicate its preference for "no relocation" scenarios to take into account the decisions made by the old gNB 326.

One possible implementation is to enhance the XnAP acquisition UE context request message to include the context relocation preference from the new gNB 324 to take into account. Examples are shown in table 3, as follows:

9.1.1.8 acquire UE context request

The message is sent by the new NG-RAN node to request that the old NG-RAN node communicate the UE context to the new NG-RAN.

The direction is: new NG-RAN node→old NG-RAN node.

TABLE 3 Table 3

Other embodiments include mechanisms for the gNB-DU 210 to indicate to gNB-CU 214 whether it can support the capability of a "no anchor relocation" scenario for an SDT session. As depicted in fig. 10, the anchor-free relocation scenario involves new and complex processing compared to the legacy inactive procedure in the gNB-DUs 210 of the new gNB 324 (if split architecture), because the gNB-DUs 210 need to perform forwarding of user plane SDT data directly between the old gnbs 326.

On the other hand, anchor point relocation scenarios (depicted in fig. 3B) do not require special handling compared to legacy inactivity procedures. To this end, the SDT-capable gNB-DU 210 can support anchor relocation scenarios only for SDT operations. There should be some mechanism to reveal whether the gNB-DU 210 can support the ability to "anchor-free relocation" towards 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 for the old gNB 326 when context retrieval is requested (as described in the previous embodiments).

One possible implementation is to enhance the F1AP F1 setup or gNB-DU configuration update or gNB-CU configuration update confirmation procedure to reveal its capabilities or update changes to gNB-CU 214. Another possible implementation is to enhance the F1AP initial UL RRC messaging procedure to forward the SDT-initiated RRC message so that the gNB-CU 214 of the new gNB 324 can be indicated whether it can support this capability of "anchor-free relocation". Examples are shown in table 4, as follows:

9.2.3.1 initial UL RRC message transmission

The message is sent by the gNB-DU to communicate an initial layer 3 message to the gNB-CU over the F1 interface.

The direction is: gNB-DU→gNB-CU

TABLE 4 Table 4

Other embodiments include mechanisms for a CU to go to another CU to reveal if it supports SDT's capability. If the gnbs can process exchange capabilities for SDT operation, it may be useful for the old gNB 326 to determine the coverage of the UE 202 configured for SDT operation because the old gNB 326 may consider the support of SDT by the neighboring gnbs and be able to configure the UE 202 to perform SDT only on cells or coverage under the gnbs supporting SDT operation. This may prevent the UE 202 from initiating SDT on cells that do not support SDT.

Such capability exchange may be further classified at a per-cell level and further classified by different scenarios that the gNB may support (e.g., "relocate only scenario", etc.). One possible implementation is to enhance the neighbor cell relation related IEs (exchanged between neighbor gnbs) over the Xn interface. Examples are shown in table 5, as follows:

9.2.2.11 serving cell information NR

The IE contains configuration information of neighboring NG-RAN nodes about NR cells that may be needed for an Xn AP interface.

TABLE 5

Range boundaries	Interpretation of the drawings
		maxnoofBPLMNs	The maximum number of PLMNs is broadcast by the cell. The value is 12.

In addition to assigning resources for SDT operation, another challenge with 5G NR systems is that the UE is to maintain SDT capability when the UE is Handed Over (HO) between different serving cells. Various 3GPP standards are considering RACH-based and/or CG-based (e.g., configuration approval type-1) for SDT. When the UE switches from the last serving gNB (referred to as the "old gNB" or "anchor gNB") to the new gNB (referred to as the "new gNB"), the RACH-based SDT allows the UE to initiate an SDT session. In this case, the context information for the UE may be relocated to the new gcb or remain in the old gcb, which is decided by the old gcb. When the context information for the UE is not relocated to a new gNB, the information signaling and interaction (e.g., messages) may be similar to legacy cases (e.g., when the UE is supported with respect to periodic RAN Notification Area (RNA) updates). However, SDT may require different information signaling and interaction between the new and old gnbs. Currently, the 3GPP standards do not define a standardized way for the old and new gnbs to communicate context information for the UE to perform SDT operations when operating in the new gNB when the context information is not relocated from the old to the new gNB.

Embodiments attempt to address these and other SDT related challenges. Embodiments describe various techniques, systems, and devices for supporting small data transmissions in a wireless communication system, such as a 3GPP 5G NR system. When the UE 202 initiates SDT operations towards a network node other than the previous network node that last served the UE 202, the signaling and information described for one or more embodiments may enable seamless support of small data transfers during 5G RRC_INACTIVE NR across network nodes. The signaling and information described for one or more embodiments may be implemented in one or more 3GPP standards (e.g., 3GPP TS 38.423, which defines an Xn application protocol (XnAP) interface between the new gNB 324 and the old gNB 326).

Referring again to fig. 3b, the ue 202 may initiate the SDT procedure without switching from the rrc_inactive state to the rrc_connected state. RACH based (e.g., 2 steps or 4 steps) and CG based (e.g., configuration approval type 1) are being considered for SDT. RACH based SDT allows UE 202 to initiate SDT sessions on a new gNB 324 other than the old gNB 326 (e.g., point gNB). In this case, the UE context may be relocated to the new gNB 324 or remain in the old gNB 326, which is decided by the old gNB 326. When the old gNB 326 decides not to relocate the context to the new gNB 324, this situation may be referred to as RACH based SDT without anchor relocation.

The case where the old gNB 326 decides not to relocate the context may be implemented with a procedure similar to its legacy case with respect to periodic RAN Notification Area (RNA) updates being supported. However, SDT requires different information signaling and interaction between the new gNB 324 and the old gNB 326. Embodiments herein relate to enhancements to support SDT in the event that the context for the UE 202 is not relocated. More specifically, the embodiment includes: (1) A mechanism for supporting user plane data transfer between the UE 202 and the old gNB 326 through the new gNB 324; (2) A mechanism for supporting transmission of RRC messages between UE 202 and old gNB 326 through gNB 324; and (3) a mechanism for supporting UE context release in the new gNB 324 when the old gNB 326 sends an RRC message to terminate the SDT session for the UE 202.

Fig. 9 illustrates a logic flow 900. Logic flow 900 may be representative of some or all of the operations executed by one or more embodiments described herein. For example, logic flow 900 may include some or all of the operations performed by a device or entity (e.g., gNB 204) within wireless communication system 100 or wireless communication system 200. More specifically, logic flow 900 illustrates an example of a use case of gNB 204 implementing a gNB split architecture in which gNB-DU 210 sends SDT information for UE 202 to gNB-CU 214 to inform gNB-CU 214 that UE 202 is initiating an SDT. The embodiments are not limited in this context.

In block 902, the logic flow 900 decodes a get User Equipment (UE) context request message received by a second node of a Radio Access Network (RAN) from a first node of the RAN, the get UE context request message including Small Data Transfer (SDT) information. For example, an apparatus 600 for an access node (e.g., a gNB 204 or eNB) includes a memory interface 606 to send to a data storage device 610 or receive SDT information from the data storage device 610 regarding SDT signaling between a first node and a second node of a 3GPP RAN. The apparatus 600 may further include a processor circuit 602 communicatively coupled to the memory interface 606, the processor circuit 602 to decode a get UE context request message received by the second node of the RAN from the first node of the RAN, the get UE context request message including SDT information.

In block 904, the logic flow 900 generates, by a second node of the RAN, an acquire UE context request response message including an Information Element (IE) having one or more parameters for representing a portion of the context information related to the SDT for the UE. For example, the processor circuit 602 may generate, by the second node of the RAN, an acquire UE context request response message including an IE with one or more parameters for representing part of the context information related to the SDT for the UE.

In block 906, the logic flow 900 sends an indication to obtain a UE context request response message from the second node to the first node. For example, the processor circuit 602 sends an indication to obtain the UE context request response message from the second node to the first node. Note that SDT may be in UL direction, downlink (DL) direction, or both.

Fig. 10 illustrates a message flow 1000 that provides an example of a recovery procedure for Small Data Transfer (SDT) without the UE 202 entering the rrc_connected state prior to SDT operation. As previously described, RACH-based SDT allows UE 202 to initiate an SDT session on a new gNB 324 that is a gNB other than the old gNB 326 (e.g., anchor gNB). The UE context may be relocated to the new gNB 324 or remain in the old gNB 326, which is decided by the old gNB 326. Message flow 1000 depicts a signaling flow for the case where the old gNB 326 decides not to relocate the context for the UE 202 to the new gNB 324. More specifically, message flow 1000 provides an example of RACH-based SDT without anchor relocation procedure defined by various 3GPP standards (e.g., 3GPP TS 38.423 and TS 38.300, among other 3GPP and non-3GPP standards).

In message flow 1000, the wireless system includes UE 202, new gNB 324, old gNB 326, and UPF 358. From time to time, the UE 202 may need to send small amounts of data, referred to as SDT in 3 GPP. In this example, the context for the UE 202 is stored at the old gNB 326, referred to as the "anchor point" for the UE 202.

Message flow 1000 illustrates an example of message exchange initiated by an RRC resume request containing a small data indication. In some implementations, the message may be implemented as an XnAP message generated and sent based on other 3GPP and non-3GPP standards such as 3GPP TS 38.423.

In this example, UE 202 initiates SDT to new gNB 324, where old gNB 326 provides an RRC release configuration or message to new gNB 324 via a context acquisition procedure. The UE 202 indicates its small data intent during the recovery procedure. In block 330, UE 202 in rrc_inactive state sends message 1002 to new gNB 324 as an RRC resume request message. The RRC resume request message is conveyed through SRB0 and it includes a small data indication with UL SDT data.

At block 334, the new gNB 324 determines that the initial UL SDT data is for the old gNB 326. The new gNB 324 passes the small data indication in message 1004 to the old gNB 326 via an XnAP message. The new gNB 324 may send the message 1004 as an XnAP get UE context request message. The old gNB 326 may determine whether to relocate the anchor point.

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

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 an XnAP DL data forwarding address indication message to the old gNB 326 as legacy.

At block 1010, the old gNB 326 and the UE 202 may communicate various RRC messages via 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 to the new gNB 324 as an RRC message to terminate the SDT session for the UE 202. Message 1014 may include UE context release information. The new gNB 324 may send a message 1016 to the UE 202. Message 1016 may include, for example, an RRC release message (e.g., RRCRelease) or an RRC resume message (e.g., rrcreseum) for UE 202.

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

When the old gNB 326 decides about anchor-free 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 non-relocation scenario, processing SDT data at the 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 old gNB 326. The old gNB 326 maintains a secure anchor and is the only place where UL SDT data can be properly decrypted before uploading to the core network. In addition, DL SDT data (if any) arriving at the old gNB 326 should also be forwarded to the new gNB 324 for transmission to the UE 202. As long as the old gNB 326 retains the anchor role, there should be no handover to change the path of the UE connection management point on the RAN side.

One possibility is to forward the user plane data in the form of PDCP PDUs (e.g. RLC SDUs). A corresponding user plane forwarding tunnel may then be established to forward the user plane data in the form of PDCP PDUs, which is new to the rrc_inactive procedure. UE 202 resumes its layer 2 configuration when SDT is initiated, so new gNB 324 should be able to at least acquire the UE RLC configuration for proper processing of RLC data. 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 deciphering. In the downlink, the new gNB 324 should be able to process PDCP PDUs received from the old gNB 326 and should be able to send them to the UE 202. To achieve this, some necessary information must be distributed from the old gNB 326 to the new gNB 324 during the context acquisition process.

As discussed in message flow 1000, old gNB 326 may determine whether to relocate the anchor point for UE 202 and send message 1006 to new gNB 324 as an XnAP acquisition UE context failure message. The XnAP acquisition UE context failure message may include an IE with one or more parameters representing part of the context information for UL TNL (including SDT RLC configuration information). Additionally or alternatively to the XnAP acquisition UE context failure message, message 1006 may be implemented as a partial UE context transfer message with partial UE context transfer information for the SDT message. This message is sent by the old gNB 326 to communicate a portion of the UE context information to the new gNB 324.

In one embodiment, the UE context failure message may be implemented as a partial UE context transfer message defined by: section 9.1.1.17 and section 9.2.3.164 of 3GPP TS 38.423 entitled "Technical Specification Group Radio Access Network; NG-RAN; xn application protocol (XnAP) ", version 17.0.0, 2022, month 4 (2022-4) and version 17.1.0, 2022, month 6 (2022-06); both include any successes, revisions, or modifications. Other message types and standards may be implemented as well. The embodiments are not limited in this context.

Section 9.1.1.17 of 3gpp TS 38.423 version 17.0.0 provides an example of how to add a new IE in a partial UE context transfer message to support SDT, as shown in table 6 as follows:

9.1.1.17 part UE context transfer

The message is sent by the old NG-RAN node (e.g., old gNB 326) or used to communicate part of the UE context to the new NG-RAN node (e.g., new gNB 324).

The direction is: old NG-RAN node→new NG-RAN node.

TABLE 6

Section 9.2.3.164 of 3gpp TS 38.423 version 17.0.0 provides an example of a new IE for a partial UE context transfer message, where the new IE is referred to as partial UE context information for SDT. The IE contains the UE context information in a partial UE context transfer message for NR SDT. Examples for this new IE are shown in table 7 as follows:

9.2.3.164 partial UE context information for SDT

The IE contains the UE context information in a partial UE context transfer message for NR SDT.

TABLE 7

Section 9.1.1.17 of 3gpp TS 38.423 version 17.1.0 provides another example of how to add a new IE in a partial UE context transfer message to support SDT, as shown in table 8 as follows:

9.1.1.17 part UE context transfer

The message is sent by the old NG-RAN node to communicate the portion of the UE context to the new NG-RAN node.

The direction is: old NG-RAN node→new NG-RAN node.

TABLE 8

Section 9.2.3.164 of 3gpp TS 38.423 version 17.1.0 provides an example of a new IE for a partial UE context transfer message, where the new IE is referred to as partial UE context information for SDT. The IE contains the UE context information in a partial UE context transfer message for NR SDT. Examples for this new IE are shown in table 9 as follows:

9.2.3.164 partial UE context information for SDT

The IE contains the UE context information in a partial UE context transfer message for NR SDT.

TABLE 9

Range boundaries	Interpretation of the drawings
		maxnoofDRBs	The maximum number of DRBs allowed towards one UE is 32.
maxnoofSRBs	The maximum number of SRBs allowed towards one UE is 5.

In one embodiment, the UE context failure message may be implemented as a get UE context failure message defined by: section 9.1.1.10 of 3GPP TS 38.423 entitled "Technical Specification Group Radio Access Network; NG-RAN; xn application protocol (XnAP) ", version 17.0.0, 2022, month 4 (2022-4) and version 17.1.0, 2022, month 6 (2022-06); both include any successes, revisions, or modifications. Other message types and standards may be implemented as well. The embodiments are not limited in this context.

Section 9.1.1.10 of 3gpp TS 38.423 version 17.0.0 provides an example of how to add a new IE in the get UE context transfer message to support SDT as shown in table 10 as follows:

9.1.1.10 failure to acquire UE context

The message is sent by the old NG-RAN node (e.g., old gNB 326) to inform the new NG-RAN node (e.g., new gNB 324) that the acquisition UE context procedure has failed.

The direction is: old NG-RAN node→new NG-RAN node.

Table 10

The SDT configuration IE may be implemented as shown in table 11 as follows:

xx2 SDT configuration

The IE includes necessary configuration information for processing RLC PDUs and performing data forwarding related to SDT (small data transfer).

TABLE 11

The SDT Xn-U context information IE may be implemented in Table 12 as follows:

9.2.3.XX3 SDT Xn-U context information

The IE includes information necessary to set the Xn-U bearer associated with the SDT (small data transfer).

Table 12

Logic flow 900 and/or message flow 1000 may be implemented by apparatus 600 of gNB 204 (e.g., old gNB 326 and/or new gNB 324). In one example, the apparatus 600 for an access node includes a memory interface 606 to send Small Data Transfer (SDT) information to a data storage device 610 or receive Small Data Transfer (SDT) information from the data storage device 610 for SDT signaling between a first node (e.g., the new gNB 324) and a second node (e.g., the old gNB 326) of the radio access network 112. The apparatus 600 further includes a processor circuit 602 communicatively coupled to the memory interface 606, the processor circuit 602 configured to: decoding a UE context request message received by a second node of the radio access network 112 from the new gNB 324 of the radio access network 112, the UE context request message including SDT information; generating, by the old gNB 326 of the radio access network 112, an acquire UE context request response message including an IE having one or more parameters representing part of the context information related to the SDT for the UE; and an indication to send a get UE context request response message from the old gNB 326 to the new gNB 324.

The apparatus 600 may further include a signaling service 616 between the old gNB 326 and the new gNB 324, the signaling service 616 sending a get UE context request response message from the old gNB 326 to the new gNB 324 over an Xn interface according to an Xn application protocol (XnAP) defined by 3gpp TS 38.423.

The apparatus 600 may further include: wherein the UE context request response message is acquired according to the 3gpp TS 38.423 definition. For example, the get UE context request response message may be implemented as a get UE context failure message defined by 3gpp TS 38.423.

The apparatus 600 may further include: wherein the acquire UE context request response message is a partial UE context transfer message. The UE context request message may comprise, for example, a partial UE context transfer message defined, for example, by 3gpp TS 38.423.

The apparatus 600 may further include: wherein the get UE context request response message is a partial UE context transfer message and the IE group name for the IE of the partial UE context transfer message is partial UE context information for the SDT, the IE having optional presence. For example, the UE context request message may include a partial UE context transfer message, e.g., with IE naming partial UE context information for SDT as defined in 3gpp TS 38.423.

The apparatus 600 may further include: the IE group name for the IE that obtains the UE context request message is the PDU session resource list to be added or the PDU session resource item to be added.

The apparatus 600 may further include: the IE group name for the IE that obtains the UE context request response message is a DRB list to be established or an SDT DRB list to be established, and the IE has a range of 0 to 1.

The apparatus 600 may further include: wherein the IE group name for the IE acquiring the UE context request response message is the DRB item to be established or the SDT DRB item to be established, the IE has a range of 1 to the maximum number of DRBs, wherein the maximum number of DRBs allowed towards one UE is 32.

The apparatus 600 may further include: wherein the IE group name for the IE that acquires the UE context request response message is a DRB Identifier (ID), the IE has a mandatory presence and an IE type and reference of an integer having a value of 1 to 32.

The apparatus 600 may further include: wherein the IE group name for the IE that obtains the UE context request response message is UL PDCP UP TNL information, the IE has mandatory presence and one or more User Plane (UP) transmission parameters.

The apparatus 600 may further include: wherein the IE group name for the IE that obtains the UE context request response message is UL TNL information, the IE has mandatory presence and one or more UP transmission parameters.

The apparatus 600 may further include: wherein the IE group name for the IE that acquired the UE context request response message is DRB QoS, the IE has mandatory presence and one or more QoS flow classes or QoS parameters.

The apparatus 600 may further include: wherein the IE group name for the IE acquiring the UE context request response message is a PDCP SN length, the PDCP SN length IE includes an IE type with mandatory presence and enumerated with a value of 12 or 18 bits and a referenced UL PDCP SN length, or the PDCP SN length includes an IE type with mandatory presence and enumerated with a value of 12 or 18 bits and a referenced DL PDCP SN length.

The apparatus 600 may further include: wherein the IE group name for the IE that acquires the UE context request response message is a QoS flow list mapped to the DRB or a flow list mapped to the DRB, the IE has a range of 1.

The apparatus 600 may further include: wherein the IE group name for the IE that obtains the UE context request message is a QoS flow item mapped to the DRB or a flow item mapped to the DRB, the IE has a range of 1 to the maximum number of QoS flows, wherein the maximum number of QoS flows is 64.

The apparatus 600 may further include: wherein the IE group name for the IE that gets the UE context request response message is the QoS flow ID, the IE has mandatory presence and an IE type and reference with an integer value from 0 to 63.

The apparatus 600 may further include: wherein the IE group name for the IE that obtains the UE context request response message is a QoS flow mapping indication, the IE having an IE type and reference enumerated with a value indicating whether uplink QoS is mapped to DRBs or a value indicating whether downlink QoS flows are mapped to DRBs.

On the other hand, in a split gNB architecture, RLC processing may occur in a new DU of the new gNB 324 (e.g., the gNB-DU 210 of the new gNB 324), and in the case of the uplink direction, the data path will be from the new DU to the CU where the UE master context is located (e.g., in the case of the downlink, the data path is the opposite) -it may be anchored in the last serving gNB (referred to as anchor), or it may be in the new CU of the new gNB 324 of the DU parent (e.g., the gNB-CU 214 of the new gNB 324). If anchoring is used, the user plane tunnel parameters are forwarded by the parent CU between the new DU and the anchor CU (e.g., the CU that last served the gNB). Or alternatively, for an anchor CU, a parent CU (e.g., the CU of the new gNB) may process the PDCP PDU and forward the PDCP SDU to the anchor CU.

Other embodiments describe mechanisms for supporting the transfer of RRC messages between UE 202 and old gNB 326 through new gNB 324. During the SDT session, there may be some RRC message exchange between the UE 202 and the old gNB 326 (e.g., in between the rrcreseumerequest message and the final RRC message from the old gNB 326 terminating the SDT session) over the Signaling Radio Bearer (SRB). Forwarding these PDCP PDUs between the new gNB 324 and the old gNB 326 as part of the new SDT procedure is also new to rrc_inactive.

Traditionally, they are not carried via user plane tunnels, but are carried additionally over the control plane. One possible implementation may be to enhance an XnAP RRC transfer procedure (e.g., already defined for DC between the primary and secondary nodes) to carry PDCP PDUs for SRBs between the new and old gnbs 324, 326.

Another possible implementation is to define a dedicated class 2 procedure (e.g., referred to as "SRB transfer") in XnAP to carry SRB PDCP PDUs between the new and old gnbs 324, 326, as shown in table 13 below:

yy SRB transfer

The 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 deliver PDCP-C PDUs encapsulating the RRC message.

The direction is: old NG-RAN node→new NG-RAN node or new NG-RAN node→old NG-RAN node.

TABLE 13

On the other hand, in a split gNB architecture, RLC processing will occur in a new DU (e.g., the DU of new gNB 324), and in the case of the uplink direction, the data path will be from the new DU to the CU where the UE primary context is located (e.g., in the case of the downlink, the path is opposite) -it may be anchored in the last serving gNB (referred to as anchored), or it may be in the CU of the new gNB of the DU parent. If anchoring is used, the path will be between the DU and the parent CU and the anchor CU (e.g., the CU that last served the gNB), or alternatively for the anchor CU, the parent CU (e.g., the CU of the new gNB 324) may process the PDCP PDU and forward the PDCP SDU to the anchor CU.

Other embodiments include mechanisms for supporting UE context release in the new gNB 324 when the old gNB 326 sends an RRC message to terminate the SDT session. When deciding to terminate the SDT session by moving the UE 202 back to INACTIVE/IDLE, the old gNB 326 generates a final RRC message for delivery to the UE 202 via the new gNB 324. The context in the new gNB 324 created to support SDT in the anchor-free relocation scenario should also be removed along with the final RRC message. The old gNB 326 may decide to do so after several UL/DL SDT data exchanges with the UE 202 (e.g., a period of time after the context acquisition procedure), which is new to the rrc_inactive procedure.

One possible implementation may be to enhance the new XnAP SRB transfer procedure to transfer PDCP PDUs of the final RRC message from the old gNB 326 to the new gNB 324, such that upon receipt, the new gNB 324 submits the final RRC message to the UE 202 and also removes the context.

Examples are shown in table 14, as follows:

yy SRB transfer

The 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 deliver PDCP-C PDUs encapsulating the RRC message.

The direction is: old NG-RAN node→new NG-RAN node or new NG-RAN node→old NG-RAN node.

TABLE 14

Another possible implementation is to enhance the existing XnAP UE context release procedure (which is designed to command release of UE context) so that it is used to command release of UE context in the new gNB 324 and also carry PDCP PDUs of the final RRC message from the old gNB 326.

Examples are shown in table 15 as follows:

9.1.1.5UE context release

The message is sent by the target NG-RAN node to the source NG-RAN node to indicate that resources may be released.

In the case of SDT, the message is sent by the target (new) NG-RAN node to the source (old) NG-RAN node and vice versa.

The direction is: target NG-RAN node→source NG-RAN node→m-NG-RAN node→s-NG-RAN node.

The direction is: (in the case of SDT), new NG-RAN node→old NG-RAN node, old NG-RAN node→new NG-RAN node.

TABLE 15

Fig. 10-14 illustrate various systems, devices, and components that may implement aspects of the disclosed embodiments. The systems, devices, and components may be the same or similar to those described with reference to fig. 1.

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 thereto, and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, and the like.

Network 1100 may include a UE 1102, and UE 1102 may include any mobile or non-mobile computing device designed to communicate with RAN 1130 via an over-the-air connection. UE 1102 may be communicatively coupled with RAN 1130 via a Uu interface. The UE 1102 may be, but is not limited to, a smart phone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment device, in-vehicle entertainment device, instrument cluster, head mounted display device, in-vehicle diagnostic device, dashboard mobile device, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networking appliance, machine type communication device, M2M or D2D device, ioT device, etc.

In some embodiments, the network 1100 may include multiple UEs directly coupled to each other via a side link interface. The UE may be an M2M/D2D device that communicates using a physical side link channel (e.g., without limitation, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.).

In some embodiments, UE 1102 may additionally communicate with AP 1104 via an over-the-air connection. AP 1104 may manage WLAN connections that may be used to offload some/all network traffic from RAN 1130. The connection between the UE 1102 and the AP 1104 may conform to any IEEE 802.11 protocol, where the AP 1104 may be wireless fidelity And a router. In some embodiments, UE 1102, RAN 1130, and AP 1104 may utilize cellular-WLAN aggregation (e.g., LWA/LWIP). cellular-WLAN aggregation may involve UE 1102 being configured by RAN 1130 to utilize both cellular radio resources and WLAN resources.

RAN 1130 may include one or more access nodes, such as AN 1160.AN 1160 may terminate the air interface protocol for UE 1102 by providing access layer protocols, including RRC, PDCP, RLC, MAC and L1 protocols. In this way, AN 1160 may enable a data/voice connection between CN 1118 and UE 1102. In some embodiments, AN 1160 may be implemented in a separate device or as one or more software entities running on a server computer as part of, for example, a virtual network (which may be referred to as a CRAN or virtual baseband unit pool). AN 1160 is referred to as BS, gNB, RAN node, eNB, ng-eNB, nodeB, RSU, TRxP, TRP, etc. AN 1160 may be a macrocell base station or a low power base station for providing a femto cell, pico cell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell.

In embodiments where the RAN 1130 includes multiple ANs, they may be coupled to each other 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 interface (which may be separated into control/user plane interfaces in some embodiments) may allow the AN to communicate information related to handoff, data/context transfer, mobility, load management, interference coordination, etc.

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

RAN 1130 may provide the air interface on licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, a node may use LAA, eLAA, and/or feLAA mechanisms with PCell/Scell based on CA technology. Prior to accessing the unlicensed spectrum, the node may perform medium/carrier sense operations based on, for example, a Listen Before Talk (LBT) protocol.

In a V2X scenario, the UE 1102 or AN 1160 may be or act as AN RSU, which may refer to any traffic infrastructure entity for V2X communications. The RSU may be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by: for a UE, it may be referred to as a "UE-type RSU"; for enbs, it may be referred to as "eNB-type RSUs"; for gNB, it may be referred to as "gNB-type RSU"; etc. In one example, the RSU is a computing device coupled with radio frequency circuitry located at the roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications/software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may provide very low latency communications required for high speed events (e.g., collision avoidance, traffic alerts, etc.). Additionally or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weather-proof enclosure suitable for outdoor installation, and may include a network interface controller for providing a wired connection (e.g., ethernet) to a traffic signal controller or backhaul network.

In some embodiments, the RAN 1130 may be an LTE RAN 1126 with an eNB (e.g., eNB 1154). The LTE RAN 1126 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; a CP-OFDM waveform for DL and an SC-FDMA waveform for UL; turbo codes for data and TBCCs 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 measurement, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate on the sub-6GHz band.

In some embodiments, RAN 1130 may be a NG-RAN 1128 with a gNB (e.g., gNB 1156) or a NG-eNB (e.g., NG-eNB 1158). The gNB 1156 may connect with a 5G enabled UE using a 5G NR interface. The gNB 1156 may connect with the 5G core through a NG interface, which may include an N2 interface or an N3 interface. The NG-eNB 1158 may also connect with the 5G core over the NG interface, but may connect with the UE via the LTE air interface. The gNB 1156 and the ng-eNB 1158 may be connected to each other via an Xn interface.

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

The NG-RAN 1128 may provide a 5G-NR air interface with the following characteristics: a variable SCS; CP-OFDM for DL, CP-OFDM for UL, and DFT-s-OFDM; polarization codes for control, repetition codes, simplex codes, and Reed-Muller codes, and LDPC codes for data. Similar to the LTE air interface, the 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS. The 5G-NR air interface may not use CRS but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signals for time tracking. The 5G-NR air interface may operate on an FR1 band including a sub-6GHz band or an FR2 band including a frequency band from 24.25GHz to 52.6 GHz. The 5G-NR air interface may comprise an SSB, which is an area of the downlink resource grid comprising PSS/SSS/PBCH.

In some embodiments, the 5G-NR air interface may utilize BWP for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, UE 1102 may be configured with multiple BWP's, where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 1102, the SCS of the transmission also changes. Another example of use of BWP relates to power saving. In particular, the UE 1102 may be configured with multiple BWPs having different amounts of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWP containing a smaller number of PRBs may 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. BWP containing a larger number of PRBs may be used for scenarios with higher traffic load.

RAN 1130 is communicatively coupled to CN 1118, CN 1118 includes network elements to provide various functions to support data and telecommunications services for clients/subscribers (e.g., users of UE 1102). The components of CN 1118 may be implemented in one physical node or in a separate physical node. In some embodiments, NFV may be used to virtualize any or all of the functionality provided by the network elements of CN 1118 onto physical computing/storage resources in servers, switches, etc. The logical instantiation of the CN 1118 may be referred to as a network slice, while the logical instantiation of a portion of the CN 1118 may be referred to as a network sub-slice.

In some embodiments, CN 1118 may be an LTE CN 1124 (which may also be referred to as EPC). LTE CN 1124 may include MME 1106, SGW 1108, SGSN 1114, HSS1116, PGW 1110 and PCRF 1112, which are coupled to each other as shown by interfaces (or "reference points"). The function of the elements of LTE CN 1124 may be briefly described as follows.

MME 1106 may implement mobility management functions to track the current location of UE 1102 to facilitate paging, bearer activation/deactivation, handover, gateway selection, authentication, and so on.

SGW 1108 may terminate the S1 interface towards the RAN and route data packets between the RAN and LTE CN 1124. SGW 1108 may be a local mobility anchor for inter-RAN node handover and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include legal interception, billing, and some policy enforcement.

SGSN 1114 can track the location of UE 1102 and perform security functions and access control. Furthermore, SGSN 1114 may perform EPC inter-node signaling for mobility between different RAT networks; MME 1106 specified PDN and S-GW selection; MME selection for handover; etc. The S3 reference point between MME 1106 and SGSN 1114 may enable user and bearer information exchange for inter-3 GPP network mobility in idle/active state.

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

PGW 1110 may terminate the SGi interface towards Data Network (DN) 1122, which may include application/content server 1120. PGW 1110 may route data packets between LTE CN 1124 and data network 1122. PGW 1110 may be coupled with SGW 1108 via an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 1110 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. Further, the SGi reference point between PGW 1110 and data network 1122 may be an operator external public, private PDN, or an operator internal packet data network (e.g., for provisioning IMS services). PGW 1110 may be coupled with PCRF 1112 via a Gx reference point.

PCRF 1112 is a policy and charging control element of LTE CN 1124. PCRF 1112 may be communicatively coupled to app/content server 1120 to determine appropriate QoS and charging parameters for the service flows. PCRF 1110 may assign the associated rules to the PCEF with the appropriate TFTs and QCIs (via Gx reference points).

In some embodiments, CN 1118 may be a 5gc 1152. The 5gc 1152 may include AUSF 1132, AMF 1134, SMF 1136, UPF 1138, NSSF 1140, NEF 1142, NRF 1144, PCF 1146, UDM 1148, and AF 1150, which are coupled to each other as shown by interfaces (or "reference points"). The function of the elements of 5gc 1152 may be briefly described as follows.

AUSF 1132 may store data for authentication of UE 1102 and process authentication related functions. AUSF 1132 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5gc 1152 through a reference point as shown, the AUSF 1132 may also present an interface based on the Nausf service.

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

The SMF 1136 may be responsible for SM (e.g., session establishment, tunnel management between UPF 1138 and AN 1160); UE IP address allocation and management (including optional authorization); selection and control of the UP function; configuring the traffic steering at UPF 1138 to route traffic to the correct destination; terminating the interface towards the policy control function; control policy enforcement, charging, and a portion of QoS; legal interception (for SM events and interfaces to LI systems); terminating the SM portion of the NAS message; downlink data notification; initiate AN specific SM information sent to AN 1160 via AMF 1134 over N2; and determining the SSC mode of the session. SM may refer to the management of PDU sessions, and PDU sessions or "sessions" may refer to PDU connectivity services that provide or enable the exchange of PDUs between UE 1102 and data network 1122.

UPF 1138 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection to data network 1122, and a branching point to support multi-homing PDU sessions. UPF 1138 may also perform packet routing and forwarding, perform packet inspection, implement policy rules user plane parts, legal intercept packets (UP collection), perform traffic usage reporting, perform QoS processing for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic validation (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 the data network.

NSSF 1140 may select a set of network slice instances to serve UE 1102. NSSF 1140 may also determine allowed NSSAIs and mappings to subscribed S-NSSAIs (if needed). NSSF 1140 may also determine a set of AMFs or list of candidate AMFs to use for serving UE 1102 based on the appropriate configuration and possibly by querying NRF 1144. The selection of a set of network slice instances for the UE 1102 may be triggered by the AMF 1134 registered by the UE 1102 by interacting with the NSSF 1140, which may result in a change in AMF. NSSF 1140 may interact with AMF 1134 via an N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown). In addition, NSSF 1140 may expose an interface based on the Nnssf service.

NEF 1142 may securely open services and capabilities provided by 3GPP network functions for third parties, internal openness/reopening, AF (e.g., AF 1150), edge computing or fog computing systems, and the like. In such embodiments, NEF 1142 may authenticate, authorize, or restrict AF. NEF 1142 may also convert information exchanged with AF 1150 and with internal network functions. For example, NEF 1142 may translate between AF service identifiers and internal 5GC information. The NEF 1142 may also receive information from other NFs based on their ability to open. This information may be stored as structured data at NEF 1142 or at data store NF using a standardized interface. The stored information may then be re-opened by NEF 1142 to other NF and AF, or used for other purposes (e.g., analysis). Furthermore, NEF 1142 may expose an interface based on Nnef services.

NRF 1144 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of the discovered NF instances to the NF instances. NRF 1144 also maintains information of available NF instances and services supported by them. As used herein, the terms "instantiation", "instantiation" and the like may refer to the creation of an instance, while "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. Furthermore, NRF 1144 may expose an interface based on Nnrf services.

PCF 1146 may provide policy rules to control plane functions to implement them and may also support a unified policy framework to manage network behavior. PCF 1146 may also implement a front end to access subscription information related to policy decisions in the UDR of UDM 1148. In addition to communicating with functions through reference points as shown, PCF 1146 also presents an interface based on the Npcf service.

The UDM 1148 may process subscription related information to support the processing of communication sessions by network entities and may store subscription data for the UE 1102. For example, subscription data may be communicated via an N8 reference point between UDM 1148 and AMF 1134. UDM 1148 may include two parts: application front-end and UDR. The UDR may store subscription data and policy data for UDM 1148 and PCF 1146, and/or structured data for open and application data for NEF 1142 (including PFD for application detection, application request information for multiple UEs 1102). The Nudr service-based interface may be exposed by UDR 221 to allow UDM 1148, PCF 1146, and NEF 1142 to access a particular set of stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notifications of related data changes in the UDR. The UDM may include a UDM-FE that is responsible for handling credentials, location management, subscription management, etc. 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 processing, access authorization, registration/mobility management, and subscription management. In addition to communicating with other NFs through reference points as shown, the UDM 1148 may also expose Nudm service based interfaces.

AF 1150 may provide application impact on traffic routing, provide access to the NEF, and interact with the policy framework for policy control.

In some embodiments, the 5gc 1152 may enable edge computation by selecting an operator/third party service to be geographically close to the point where the UE 1102 attaches to the network. This may reduce latency and load on the network. To provide edge computing implementations, the 5gc 1152 may select a UPF 1138 near the UE 1102 and perform traffic steering from the UPF 1138 to the data network 1122 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by AF 1150. In this way, AF 1150 may affect UPF (re) selection and traffic routing. Based on the operator deployment, the network operator may allow AF 1150 to interact directly with the associated NF when AF 1150 is considered a trusted entity. In addition, AF 1150 may present an interface based on Naf services.

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, an application/content server 1120.

Fig. 12 schematically illustrates a wireless network 1200 in accordance with various embodiments. Wireless network 1200 may include a UE 1202 in wireless communication with AN 1224. UE 1202 and AN 1224 may be similar to, and substantially interchangeable with, similarly named components described elsewhere herein.

UE 1202 may be communicatively coupled with AN 1224 via a connection 1246. The connection 1246 is shown as an air interface implementing a communicative coupling and may conform to a cellular communication protocol, such as the LTE protocol or the 5G NR protocol operating at mmWave or sub-6GHz frequencies.

UE 1202 may include a host platform 1204 coupled to a modem platform 1208. Host platform 1204 may include application processing circuitry 1206, which may be coupled with protocol processing circuitry 1210 of modem platform 1208. The application processing circuit 1206 may run various applications for outgoing/incoming application data for the UE 1202. The application processing circuit 1206 may also implement one or more layer operations to send/receive application data to/from the data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

Protocol processing circuitry 1210 may implement one or more layer operations to facilitate the transmission or reception of data over connection 1246. Layer operations implemented by the protocol processing circuit 1210 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.

The modem platform 1208 may also include digital baseband circuitry 1212, and the digital baseband circuitry 1212 may implement one or more layer operations, which are "lower" layer operations in the network protocol stack performed by the protocol processing circuitry 1210. These operations may include, for example, PHY operations, including one or more of the following: HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/demapping, 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 space coding), reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

The modem platform 1208 may also include transmit circuitry 1214, receive circuitry 1216, RF circuitry 1218, and an RF front end (RFFE) 1220, which may include or be connected to one or more antenna panels 1222. Briefly, the transmit circuitry 1214 may include digital-to-analog converters, mixers, intermediate Frequency (IF) components, and the like; the receive circuitry 1216 may include analog-to-digital converters, mixers, IF components, etc.; the RF circuitry 1218 may include low noise amplifiers, power tracking components, and the like; RFFE 1220 may include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beam forming components (e.g., phased array antenna components), and so forth. The selection and arrangement of the components of the transmit circuitry 1214, receive circuitry 1216, RF circuitry 1218, RFFE 1220, and antenna panel 1222 (commonly referred to as "transmit/receive components") may be specific to the specifics of the particular implementation, such as whether the communication is TDM or FDM, at mmWave or sub-6GHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be provided in the same or different chips/modules, etc.

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

UE reception may be established by and through antenna panel 1222, RFFE 1220, RF circuitry 1218, receive circuitry 1216, digital baseband circuitry 1212, and protocol processing circuitry 1210. In some embodiments, antenna panel 1222 may receive transmissions from AN 1224 through receive beamformed signals received by multiple antennas/antenna elements of one or more antenna panels 1222.

UE transmissions may be established by and through protocol processing circuitry 1210, digital baseband circuitry 1212, transmit circuitry 1214, RF circuitry 1218, RFFE 1220, and antenna panel 1222. In some embodiments, the transmit component of UE 1224 may apply spatial filtering to data to be transmitted to form a transmit beam transmitted by the antenna elements of antenna panel 1222.

Similar to UE 1202, an 1224 may include a host platform 1226 coupled with a modem platform 1230. Host platform 1226 may include application processing circuitry 1228 coupled with protocol processing circuitry 1232 of modem platform 1230. The modem platform may also include digital baseband circuitry 1234, transmit circuitry 1236, receive circuitry 1238, RF circuitry 1240, RFFE circuitry 1242, and antenna panel 1244. Components of AN 1224 may be similar to, and substantially interchangeable with, similarly named components of UE 1202. In addition to performing data transmission/reception as described above, components of AN 1224 may perform various logic functions including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

Fig. 13 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some example embodiments. In particular, FIG. 13 shows a graphical representation of hardware resources 1330, the 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 that utilize node virtualization (e.g., NFV), hypervisor 1302 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize hardware resources 1330.

The processor 1310 may include, for example, a processor 1312 and a processor 1314. The processor 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 (e.g., baseband processor), an ASIC, an FPGA, a Radio Frequency Integrated Circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

Memory/storage 1322 may include main memory, disk storage, or any suitable combination thereof. Memory/storage 1322 may include, but is not limited to, any type of volatile, nonvolatile, 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 memory, and the like.

Communication resources 1326 may include an interconnection or network interface controller, component, or other suitable device to communicate with one or more peripheral devices 1304 or one or more databases 1306 or other network elements via network 1308. Communication resources 1326 may include, for example, wired communication components (e.g., for coupling via USB, ethernet, etc.), cellular communication component, NFC component,(or low power consumption->) Assembly, & gtof>Components and other communication components.

The instructions 106, 1318, 1324, 1328, 1332 may include software, programs, applications, applets, apps, or other executable code for causing at least any of the processors 1310 to perform any one or more of the methods discussed herein. The instructions 106, 1318, 1324, 1328, 1332 may reside wholly or partially within at least one of the processor 1310 (e.g., within a cache memory of the processor), the memory/storage device 1322, or any suitable combination thereof. Further, any portion of the instructions 106, 1318, 1324, 1328, 1332 may be transferred from the peripheral device 1304 or any combination of databases 1306 to the hardware resource 1330. Accordingly, the memory of the processor 1310, the memory/storage device 1322, the peripherals 1304, and the database 1306 are examples of computer readable and machine readable media.

For one or more embodiments, at least one component set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, procedures, and/or methods set forth in the following examples section. For example, the baseband circuitry described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more examples set forth below. As another example, circuitry associated with a UE, base station, network element, etc., 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 in the examples section below.

Fig. 14 illustrates a computer-readable storage medium 1400. The computer-readable storage medium 1400 may include any non-transitory computer-readable storage medium or machine-readable storage medium, such as optical, magnetic, or semiconductor storage media. 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 that circuitry may use to execute. For example, computer-executable instructions 1402 may include computer-executable instructions 1402 for implementing the 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 medium capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable 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.

First group of examples

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

Example 2 may include: wherein the system is a 5G NR and the dormant state is an rrc_inactive state.

Example 3 may include: wherein the data may be transmitted by the radio in one packet or in a separate subsequent packet.

Example 4 may include: wherein data transmitted by the radio is for a gNB in a split NG-RAN architecture split into a Centralized Unit (CU) and a Distributed Unit (DU).

Example 5 may include: as example 4 or some other examples herein, wherein the DU may inform of small data transfer operations from the UE to the CU.

Example 6 may include: as example 5 or some other example herein, wherein an indicator in a new message or an existing message may be used.

Example 7 may include: as example 5 or some other example herein, wherein the CU may contact between neighboring gnbs a gNB that has previously served the UE and maintained the UE context.

Example 8 may include: as in example 7 or some other example herein, wherein the CU may notify a small data transfer operation from the UE to the last serving gNB and may request UE context information.

Example 9 may include: the example 8 or some other example herein, wherein the last serving gNB may decide to maintain the UE context.

Example 10 may include: the example 8 or some other example herein, wherein the last serving gNB may decide to move the UE context to the CU.

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

Example 12 may include: the example 11 or some other example herein, wherein the information is a preference of the CU to keep the UE context in the last serving gNB or move the UE context towards itself.

Example 13 may include: as example 4 or some other example herein, wherein the DU may provide the CU with its ability to support small data transfer operations.

Example 14 may include: example 13 or some other example herein, wherein the capability is provided based on whether support for context relocation.

Example 15 may include: example 13 or some other example herein, wherein the capability is provided per cell.

Example 16 may include: as example 13 or some other example herein, the capability may be provided via an interface setup or update process.

Example 17 may include: the example 13 or some other example herein, wherein the capability may be provided to the CU via a message informing of a small data transfer operation.

Example 18 may include: as example 13 or some other example herein, wherein the capability may be provided via a message carrying the first data from the UE.

Example 19 may include: as example 8 or some other example herein, wherein the CU may provide the last serving gNB with its capability of whether it supports small data transfer operations.

Example 20 may include: the method of example 19 or some other example herein, wherein the capability is provided based on whether support for context relocation.

Example 21 may include: example 19 or some other example herein, wherein the capability is provided per cell.

Example 22 may include: example 19 or some other example herein, wherein the capability may be provided via an interface setup or update process.

Example 23 may include: as in example 19 or some other example herein, the capability may be provided to the last serving gNB via a message informing of a small data transfer operation.

Example 24 may include: the method of example 19 or some other example herein, wherein the capability may be provided via a message carrying the first data from the UE.

Example 25 may include: as example 4 or some other examples herein, wherein the CU may request that the DU provide the UE with a low-level configuration for small data transfer operations.

Example 26 may include: the example 23 or some other example herein, wherein the request is via a message addressed to the UE in the DU.

Example 27 may include: the example 23 or some other example herein, wherein the request is via a message that may establish, release, or modify the UE context in a DU.

Example 28 may include: the example 23 or some other example herein, wherein the DU may generate and provide the lower layer configuration for small data transfer operations of the UE to the CU.

Example 29 may include: the example 26 or some other example herein, wherein the CU may configure the UE with small data transfer operations based on the lower layer configuration provided from the DU.

Second group of examples

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

Example 2 may include: wherein the system is a 5G NR and the dormant state is an rrc_inactive state.

Example 3 may include: wherein the data may be transmitted by the radio in one packet or in a separate subsequent packet.

Example 4 may include: wherein data transmitted by the radio is for a gNB in a split NG-RAN architecture split into a Centralized Unit (CU) and a Distributed Unit (DU).

Example 5 may include: wherein the CU may contact between neighboring gnbs that have previously served the UE and maintained the UE context.

Example 6 may include: wherein the last serving gNB may decide to maintain the UE context.

Example 7 may include: as example 6 or some other examples herein, wherein the last serving gNB may provide information for processing data or RRC messages to/from the UE and transmissions between the CU and the last serving gNB.

Example 8 may include: as example 7 or some other example herein, wherein the information is provided via a message responsive to the message used in example 5.

Example 9 may include: example 7 or some other examples herein, wherein the data is in the form of PDCP SDUs or SDAP SDUs.

Example 10 may include: as in example 6 or some other example herein, wherein 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.

Example 11 may include: the example 10 or some other examples herein, wherein the data is in the form of PDCP PDUs.

Example 12 may include: the example 10 or some other examples herein, wherein the data may be transmitted by the CU.

Example 13 may include: as in example 6 or some other examples herein, the last serving gNB may terminate a small data transfer procedure.

Example 14 may include: as in example 13 or some other example herein, the last serving gNB may send an RRC message to the CU to terminate a small data transfer procedure for the UE.

Example 15 may include: the example 14 or some other example herein, wherein the RRC message is sent to the UE.

Example 16 may include: as example 14 or some other examples herein, the message to transmit an RRC message to the UE to terminate the small data transfer procedure may indicate release of UE context in the CU or DU or both.

Example 17 may include: as in example 16 or some other examples herein, the DU may release the UE context while submitting the RRC message to the UE in example 14.

Third group of examples

In one example, an example apparatus for an access node, comprising: a memory interface for transmitting to or receiving from a data storage device Small Data Transfer (SDT) information for SDT signaling between a gNB (gNB) distributed unit (gNB-DU) and a gNB central unit (gNB-CU) of a Radio Access Network (RAN). The example apparatus also includes a processor circuit communicatively coupled to the memory interface, the processor circuit to: decoding that a Radio Resource Control (RRC) resume request message received by the gNB-DU from a User Equipment (UE) in an inactive state is due to SDT; generating an initial Uplink (UL) RRC message transfer message including an Information Element (IE) having one or more parameters for indicating that the RRC recovery request is due to the SDT; and transmitting an indication to transmit an initial UL RRC message transmission message from the gNB-DU to the gNB-CU, the initial UL RRC message transmission message indicating transmission of the RRC resume request message to the gNB-CU.

The example apparatus may be combined with any of the previous examples further comprising a Radio Frequency (RF) circuit communicatively coupled to the processor circuit, the RF circuit to receive an RF signal from the UE representative of the RRC restoration request message.

The example apparatus may be combined with any of the previous examples further comprising a signaling service between the gNB-DU and the gNB-CU to provide UE association services, the signaling service to send the initial UL RRC messaging message from the gNB-DU to the gNB-CU over an F1 interface according to an F1 application protocol (F1 AP).

The example apparatus may be combined with any of the preceding examples further comprising: wherein the initial UL RRC messaging message is defined according to third generation partnership project (3 GPP) Technical Specification (TS) 38.473.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the initial UL RRC messaging message is SDT origination or SDT information.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the initial UL RRC messaging message is SDT information, and wherein the presence for the IE is optional.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE is to indicate an SDT transaction and provide side information from the UE, the IE including SDT information including an SDT indicator of an enumerated type with boolean parameters.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE is to indicate an SDT transaction and provide side information from the UE, the IE including SDT information including SDT side information having an enumeration type of single packet parameters for indicating that no subsequent SDT transmissions are expected or multi packet parameters for indicating that subsequent SDT transmissions are expected. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

In one example, an example method for an access node includes: an indication that a gNodeB (gNB) distributed unit (gNB-DU) of a Radio Access Network (RAN) receives a Radio Resource Control (RRC) resume request message from a user equipment in an inactive state; decoding the RRC resume request message received from the UE due to Small Data Transfer (SDT); generating an initial Uplink (UL) RRC message transfer message including an Information Element (IE) having one or more parameters for indicating that the RRC recovery request is due to the SDT; and transmitting an indication to transmit the initial UL RRC message transfer message from the gNB-DU to the gNB central unit (gNB-CU), the initial UL RRC message transfer message indicating transfer of the RRC resume request message to the gNB-CU.

The example method may be combined with any of the preceding examples further comprising: a Radio Frequency (RF) signal representing the RRC resume request message from the UE is received.

The example method may be combined with any of the preceding examples further comprising: the initial UL RRC messaging message is sent from the gNB-DU to the gNB-CU over an F1 interface according to an F1 application protocol (F1 AP).

The example method may be combined with any of the preceding examples further comprising: wherein the initial UL RRC messaging message is defined according to third generation partnership project (3 GPP) Technical Specification (TS) 38.473.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the initial UL RRC messaging message is SDT origination or SDT information.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the initial UL RRC messaging message is SDT information, and wherein the presence for the IE is optional.

The example method may be combined with any of the preceding examples further comprising: wherein the IE is to indicate an SDT transaction and provide side information from the UE, the IE including SDT information including an SDT indicator of an enumerated type with boolean parameters.

The example method may be combined with any of the preceding examples further comprising: wherein the IE is to indicate an SDT transaction and provide side information from the UE, the IE including SDT information including SDT side information having an enumeration type of single packet parameters for indicating that no subsequent SDT transmissions are expected or multi packet parameters for indicating that subsequent SDT transmissions are expected. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

In one example, a non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: an indication that a gNodeB (gNB) distributed unit (gNB-DU) of a Radio Access Network (RAN) receives a Radio Resource Control (RRC) resume request message from a user equipment in an inactive state; decoding the RRC resume request message received from the UE due to Small Data Transfer (SDT); generating an initial Uplink (UL) RRC message transfer message including an Information Element (IE) having one or more parameters for indicating that the RRC recovery request is due to the SDT; and transmitting an indication to transmit the initial UL RRC message transfer message from the gNB-DU to the gNB central unit (gNB-CU), the initial UL RRC message transfer message indicating transfer of the RRC resume request message to the gNB-CU.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: an indication of a Radio Frequency (RF) signal representing the RRC resume request message is received from the UE.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: the initial UL RRC messaging message is sent from the gNB-DU to the gNB-CU over an F1 interface according to an F1 application protocol (F1 AP).

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the initial UL RRC messaging message is defined according to third generation partnership project (3 GPP) Technical Specification (TS) 38.473.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the initial UL RRC messaging message is SDT origination or SDT information.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the initial UL RRC messaging message is SDT information, and wherein the presence for the IE is optional.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE is to indicate an SDT transaction and provide side information from the UE, the IE including SDT information including an SDT indicator of an enumerated type with boolean parameters.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE is to indicate an SDT transaction and provide side information from the UE, the IE including SDT information including SDT side information having an enumeration type of single packet parameters for indicating that no subsequent SDT transmissions are expected or multi packet parameters for indicating that subsequent SDT transmissions are expected. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

In one example, an example apparatus for an access node, comprising: a memory interface for transmitting to or receiving from a data storage device Small Data Transfer (SDT) information for SDT signaling between a gNB (gNB) distributed unit (gNB-DU) and a gNB central unit (gNB-CU) of a Radio Access Network (RAN). The example apparatus also includes a processor circuit communicatively coupled to the memory interface, the processor circuit to: determining that the gNB-CU of the RAN modifies User Equipment (UE) context information for a UE; generating a UE context modification request message to provide modified UE context information to the gNB-DU of the RAN, the UE context modification request message including an Information Element (IE) having one or more parameters for indicating a request for configuration information of a UE for SDT operation from the gNB-DU; and sending an indication to send a UE context modification request message from the gNB-CU to the gNB-DU.

The example apparatus may be combined with any of the preceding examples further comprising: the processor circuit is configured to: it is determined to modify the UE context information to generate a configuration approval (CG) -based SDT for the UE.

The example apparatus may be combined with any of the previous examples further comprising a signaling service between the gNB-CU and the gNB-DU to provide UE association services, the signaling service to send the UE context modification request message from the gNB-CU to the gNB-DU over an F1 interface in accordance with an F1 application protocol (F1 AP).

The example apparatus may be combined with any of the preceding examples further comprising: wherein the UE context modification request message is defined in accordance with a third generation partnership project (3 GPP) Technical Specification (TS) 38.473.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the UE context modification request message is an SDT configuration request or configuration approval (CG) SDT (CG-SDT) query indication.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the UE context modification request message is a configuration approval (CG) SDT (CG-SDT) query indication, and wherein the presence for the IE is optional.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE type and reference for the UE context modification request message is an enumeration type with boolean parameters.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the acknowledgement information includes a physical layer (PHY) or Medium Access Control (MAC) layer configuration of the UE.

The example apparatus may be combined with any of the preceding examples further comprising: the processing circuit is configured to: a UE context modification response message received from the gNB-DU in response to the UE context modification request message is decoded, the UE context modification response message including the requested configuration information.

The example apparatus may be combined with any of the preceding examples further comprising: the processing circuit is configured to: in response to receiving configuration information from the gNB-DU, a configuration approval (CG) for CG SDT operation of the UE is generated.

The example apparatus may be combined with any of the preceding examples further comprising: the processing circuit is configured to: an indication is sent for sending a message from the gNB-CU to the gNB-DU with a configuration approval (CG) for CG SDT operation of the UE.

The example apparatus may be combined with any of the preceding examples further comprising: signaling services between the gNB-CU and a gNB-DU for sending a CG approval (CG) message for CG SDT operation of 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.

In one example, an example method for an access node includes: determining that a gNB central unit (gNB-CU) of a Radio Access Network (RAN) modifies User Equipment (UE) context information for the UE; generating a UE context modification request message to provide modified UE context information to a gNB distributed unit (gNB-DU) of the RAN, the UE context modification request message including an Information Element (IE) having one or more parameters for indicating a request for configuration information of the UE for Small Data Transfer (SDT) operation from the gNB-DU; and sending an indication to send a UE context modification request message from the gNB-CU to the gNB-DU.

The example method may be combined with any of the preceding examples further comprising: it is determined to modify the UE context information to generate a configuration approval (CG) -based SDT for the UE.

The example method may be combined with any of the preceding examples further comprising: the UE context modification request message is sent from the gNB-CU to the gNB-DU over an F1 interface according to an F1 application protocol (F1 AP).

The example method may be combined with any of the preceding examples further comprising: wherein the UE context modification request message is defined in accordance with a third generation partnership project (3 GPP) Technical Specification (TS) 38.473.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the UE context modification request message is an SDT configuration request or configuration approval (CG) SDT (CG-SDT) query indication.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the UE context modification request message is a configuration approval (CG) SDT (CG-SDT) query indication, and wherein the presence for the IE is optional.

The example method may be combined with any of the preceding examples further comprising: wherein the IE type and reference for the UE context modification request message is an enumeration type with boolean parameters.

The example method may be combined with any of the preceding examples further comprising: wherein the acknowledgement information includes a physical layer (PHY) or Medium Access Control (MAC) layer configuration of the UE.

The example method may be combined with any of the preceding examples further comprising: a UE context modification response message received from the gNB-DU in response to the UE context modification request message is decoded, the UE context modification response message including the requested configuration information.

The example method may be combined with any of the preceding examples further comprising: in response to receiving configuration information from the gNB-DU, a configuration approval (CG) for CG SDT operation of the UE is generated.

The example method may be combined with any of the preceding examples further comprising: an indication is sent for sending a message from the gNB-CU to the gNB-DU with a configuration approval (CG) for CG SDT operation of the UE.

The example method may be combined with any of the preceding examples further comprising: a message with a configuration approval (CG) for CG SDT operation of the UE is sent 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.

In one example, a non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: determining that a gNB central unit (gNB-CU) of a Radio Access Network (RAN) modifies User Equipment (UE) context information about the UE; generating a UE context modification request message to provide modified UE context information to a gNB distributed unit (gNB-DU) of the RAN, the UE context modification request message including an Information Element (IE) having one or more parameters for indicating a request for configuration information of a UE for Small Data Transfer (SDT) operation from the gNB-DU; and sending an indication to send a UE context modification request message from the gNB-CU to the gNB-DU.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: it is determined to modify the UE context information to generate a configuration approval (CG) -based SDT for the UE.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: the UE context modification request message is sent from the gNB-CU to the gNB-DU over an F1 interface according to an F1 application protocol (F1 AP).

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the UE context modification request message is defined in accordance with a third generation partnership project (3 GPP) Technical Specification (TS) 38.473.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the UE context modification request message is an SDT configuration request or configuration approval (CG) SDT (CG-SDT) query indication.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the UE context modification request message is a configuration approval (CG) SDT (CG-SDT) query indication, and wherein the presence for the IE is optional.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE type and reference for the UE context modification request message is an enumeration type with boolean parameters.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the acknowledgement information includes a physical layer (PHY) or Medium Access Control (MAC) layer configuration of the UE.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: a UE context modification response message received from the gNB-DU in response to the UE context modification request message is decoded, the UE context modification response message for including the requested configuration information.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: in response to receiving configuration information from the gNB-DU, a configuration approval (CG) for CG SDT operation of the UE is generated.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: an indication is sent for sending a message from the gNB-CU to the gNB-DU with a configuration approval (CG) for CG SDT operation of the UE.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: a message is sent from the gNB-CU to the gNB-DU with CG approval (CG) for CG SDT operations of the UE. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

In one example, an example apparatus for an access node, comprising: a memory interface for transmitting to or receiving from a data storage device Small Data Transfer (SDT) information for SDT signaling between a first node and a second node of a Radio Access Network (RAN). The example apparatus also includes a processor circuit communicatively coupled to the memory interface, the processor circuit to: decoding a get User Equipment (UE) context request message received by a second node of the RAN from a first node of the RAN, the get UE context request message including the SDT information; generating, by the second node of the RAN, an acquire UE context request response message including an Information Element (IE) having one or more parameters for representing part of the context information related to the SDT for the UE; and sending an indication to send the acquire UE context request response message from the second node to the first node.

The example apparatus may be combined with any of the preceding examples further comprising: and signaling service between the second node and the first node, wherein the signaling service sends the UE context acquisition request response message to the first node from the second node through an Xn interface according to an Xn application protocol (XnAP).

The example apparatus may be combined with any of the preceding examples further comprising: wherein the acquire UE context request response message is defined in accordance with a third generation partnership project (3 GPP) Technical Specification (TS) 38.423.

The example apparatus may be combined with any of the preceding examples further comprising: wherein, the UE context acquisition request response message is a UE context acquisition failure message.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the acquire UE context request response message is a partial UE context transfer message.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the get 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 partial UE context information for SDT, the IE having optional presence.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Protocol Data Unit (PDU) session resource list to be added or a PDU session resource item to be added.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the acquire UE context request response message is a Data Radio Bearer (DRB) list to be established or an SDT DRB list to be established, the IE having a range of 0 to 1.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) item to be established or an SDT DRB item to be established, the IE having a range of 1 to the maximum number of DRBs, wherein the maximum number of DRBs allowed towards one UE is 32.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) Identifier (ID), the IE having a mandatory presence and an IE type and reference having a value of an integer from 1 to 32.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the acquire UE context request response message is Uplink (UL) Packet Data Convergence Protocol (PDCP) User Plane (UP) Transport Network Layer (TNL) information, the IE having mandatory presence and one or more User Plane (UP) transport parameters.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is Uplink (UL) Transport Network Layer (TNL) information, the IE having mandatory presence and one or more User Plane (UP) transport parameters.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) quality of service (QoS), the IE having a mandatory presence and one or more QoS flow classes or QoS parameters.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) length including an IE type and referenced Uplink (UL) PDCP SN length having a mandatory presence and enumerated with a 12-bit or 18-bit value, or including an IE type and referenced Downlink (DL) PDCP SN length having a mandatory presence and enumerated with a 12-bit or 18-bit value.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow list mapped to a Data Radio Bearer (DRB) or a flow list mapped to a Data Radio Bearer (DRB), the IE having a range of 1.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow item mapped to a Data Radio Bearer (DRB) or a flow item mapped to a Data Radio Bearer (DRB), the IE having a range of 1 to a maximum number of QoS flows, wherein the maximum number of QoS flows is 64.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow Identifier (ID), the IE having a mandatory presence and an IE type and reference having a value of an integer from 0 to 63.

The example apparatus may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow mapping indication, the IE having an IE type and reference enumerated with a value indicating whether uplink QoS is mapped to DRBs or a value indicating whether downlink QoS flows are mapped to DRBs. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

In one example, an example method for an access node includes: decoding a get User Equipment (UE) context request message received by a second node of a Radio Access Network (RAN) from a first node of the RAN, the get UE context request message for including Small Data Transfer (SDT) information; generating, by the second node of the RAN, an acquire UE context request response message for including an Information Element (IE) having one or more parameters for representing partial context information related to an SDT for the UE; and sending an indication to send the acquire UE context request response message from the second node to the first node.

The example method may be combined with any of the preceding examples further comprising: and sending the UE context acquisition request response message from the second node to the first node through an Xn interface according to an Xn application protocol (XnAP).

The example method may be combined with any of the preceding examples further comprising: wherein the acquire UE context request response message is defined in accordance with a third generation partnership project (3 GPP) Technical Specification (TS) 38.423.

The example method may be combined with any of the preceding examples further comprising: wherein, the UE context acquisition request response message is a UE context acquisition failure message.

The example method may be combined with any of the preceding examples further comprising: wherein the acquire UE context request response message is a partial UE context transfer message.

The example method may be combined with any of the preceding examples further comprising: wherein the get 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 partial UE context information for SDT, the IE having optional presence.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Protocol Data Unit (PDU) session resource list to be added or a PDU session resource item to be added.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the acquire UE context request response message is a Data Radio Bearer (DRB) list to be established or an SDT DRB list to be established, the IE having a range of 0 to 1.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) item to be established or an SDT DRB item to be established, the IE having a range of 1 to the maximum number of DRBs, wherein the maximum number of DRBs allowed towards one UE is 32.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) Identifier (ID), the IE having a mandatory presence and an IE type and reference having a value of an integer from 1 to 32.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the acquire UE context request response message is Uplink (UL) Packet Data Convergence Protocol (PDCP) User Plane (UP) Transport Network Layer (TNL) information, the IE having mandatory presence and one or more User Plane (UP) transport parameters.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is Uplink (UL) Transport Network Layer (TNL) information, the IE having mandatory presence and one or more User Plane (UP) transport parameters.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) quality of service (QoS), the IE having a mandatory presence and one or more QoS flow classes or QoS parameters.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) length including an IE type and referenced Uplink (UL) PDCP SN length having a mandatory presence and enumerated with a 12-bit or 18-bit value, or including an IE type and referenced Downlink (DL) PDCP SN length having a mandatory presence and enumerated with a 12-bit or 18-bit value.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow list mapped to a Data Radio Bearer (DRB) or a flow list mapped to a Data Radio Bearer (DRB), the IE having a range of 1.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow item mapped to a Data Radio Bearer (DRB) or a flow item mapped to a Data Radio Bearer (DRB), the IE having a range of 1 to a maximum number of QoS flows, wherein the maximum number of QoS flows is 64.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow Identifier (ID), the IE having a mandatory presence and an IE type and reference having a value of an integer from 0 to 63.

The example method may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow mapping indication, the IE having an IE type and reference enumerated with a value indicating whether uplink QoS is mapped to DRBs or a value indicating whether downlink QoS flows are mapped to DRBs. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

In one example, a non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: decoding a get User Equipment (UE) context request message received by a second node of a Radio Access Network (RAN) from a first node of the RAN, the get UE context request message including Small Data Transfer (SDT) information; generating, by the second node of the RAN, an acquire UE context request response message including an Information Element (IE) having one or more parameters for representing part of the context information related to the SDT for the UE; and sending an indication to send the acquire UE context request response message from the second node to the first node.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising instructions that, when executed by a computer, cause the computer to: and sending the UE context acquisition request response message from the second node to the first node through an Xn interface according to an Xn application protocol (XnAP).

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the acquire UE context request response message is defined in accordance with a third generation partnership project (3 GPP) Technical Specification (TS) 38.423.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein, the UE context acquisition request response message is a UE context acquisition failure message.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the acquire UE context request response message is a partial UE context transfer message.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the get 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 partial UE context information about SDT, the IE having optional presence.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Protocol Data Unit (PDU) session resource list to be added or a PDU session resource item to be added.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the acquire UE context request response message is a Data Radio Bearer (DRB) list to be established or an SDT DRB list to be established, the IE having a range of 0 to 1.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) item to be established or an SDT DRB item to be established, the IE having a range of 1 to the maximum number of DRBs, wherein the maximum number of DRBs allowed towards one UE is 32.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) Identifier (ID), the IE having a mandatory presence and an IE type and reference having a value of an integer from 1 to 32.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the acquire UE context request response message is Uplink (UL) Packet Data Convergence Protocol (PDCP) User Plane (UP) Transport Network Layer (TNL) information, the IE having mandatory presence and one or more User Plane (UP) transport parameters.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is Uplink (UL) Transport Network Layer (TNL) information, the IE having mandatory presence and one or more User Plane (UP) transport parameters.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) quality of service (QoS), the IE having a mandatory presence and one or more QoS flow classes or QoS parameters.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) length including an IE type and referenced Uplink (UL) PDCP SN length having a mandatory presence and enumerated with a 12-bit or 18-bit value, or including an IE type and referenced Downlink (DL) PDCP SN length having a mandatory presence and enumerated with a 12-bit or 18-bit value.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow list mapped to a Data Radio Bearer (DRB) or a flow list mapped to a Data Radio Bearer (DRB), the IE having a range of 1.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow item mapped to a Data Radio Bearer (DRB) or a flow item mapped to a Data Radio Bearer (DRB), the IE having a range of 1 to a maximum number of QoS flows, wherein the maximum number of QoS flows is 64.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow Identifier (ID), the IE having a mandatory presence and an IE type and reference having a value of an integer from 0 to 63.

The example computer-readable storage medium may be combined with any of the preceding examples further comprising: wherein the IE group name for the IE of the get UE context request response message is a quality of service (QoS) flow mapping indication, the IE having an IE type and reference enumerated with a value indicating whether uplink QoS is mapped to DRBs or a value indicating whether downlink QoS flows are mapped to DRBs. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.

Terminology

For purposes of this document, the following terms and definitions apply to the examples and embodiments discussed herein.

The term "circuitry" as used herein refers to, is part of, or includes the following hardware components configured to provide the described functionality: such as electronic circuitry, logic circuitry, 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 (hcld), a structured ASIC, or a programmable SoC), a Digital Signal Processor (DSP), etc. 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 one or more hardware elements in combination with program code (or a combination of circuitry and program code for use in an electrical or electronic system) for performing the functions of the program code. In these embodiments, a combination of hardware elements and program code may be referred to as a particular type of circuit.

The term "processor circuit" as used herein refers to a circuit, part of or comprising, capable of sequentially and automatically performing a series of arithmetic or logical operations, or recording, storing and/or transmitting digital data. The processing circuitry may include one or more processing cores for executing instructions and one or more memory structures for storing 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 tri-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions (e.g., program code, software modules, and/or functional processes). The processing circuitry may include further 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 with "processor circuitry" and may be referred to as "processor circuitry".

The term "interface circuit" 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 circuit" may refer to one or more hardware interfaces, such as a bus, an I/O interface, a peripheral component interface, a network interface card, and the like.

The term "user equipment" or "UE" as used herein refers to a device having radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered as synonyms for the following terms and may be referred to as they: a client, mobile station, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio, reconfigurable mobile device, etc. Furthermore, the term "user equipment" or "UE" may include any type of wireless/wired device or any computing device that contains a wireless communication interface.

The term "network element" as used herein refers to a physical or virtualized device and/or infrastructure for providing wired or wireless communication network services. The term "network element" may be considered as a synonym for and/or referred to as the following terms: a networked computer, networking hardware, network device, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, etc.

The term "computer system" as used herein refers to any type of interconnected electronic device, computer device, or component thereof. Furthermore, the terms "computer system" and/or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the terms "computer system" and/or "system" may refer to a plurality of computer devices and/or a plurality of computing systems communicatively coupled to each other and configured to share computing and/or networking resources.

The terms "appliance," "computer appliance," and the like as used herein refer to a computer device or computer system having program code (e.g., software or firmware) specifically designed to provide a particular 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 is otherwise dedicated to providing specific computing resources.

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 a computer device, a mechanical device, a memory space, a processor/CPU time, a processor/CPU usage, a processor and accelerator load, a hardware time or usage, power, input/output operations, ports or network sockets, channel/link assignments, throughput, memory usage, storage, networks, databases and applications, workload units, and the like. "hardware resources" may refer to computing, storage, and/or network resources provided by physical hardware elements. "virtualized resources" may refer to computing, storage, and/or network resources provided by the virtualization infrastructure to applications, devices, systems, etc. The term "network resource" or "communication resource" may refer to a resource that is accessible to a computer device/system via a communication network. The term "system resource" may refer to any kind of shared entity that provides a service and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects, or services that are accessible through a server, where the system resources reside on a single host or multiple hosts and are clearly identifiable.

The term "channel" as used herein refers to any transmission medium, whether tangible or intangible, used to communicate data or data streams. The term "channel" may be synonymous with and/or equivalent to the following terms: "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term that refers to a path or medium through which data is transferred. Furthermore, the term "link" as used herein refers to a connection between two devices via a RAT for transmitting and receiving information.

The terms "instantiation", "instantiation" and the like as used herein refer to the creation of an instance. "instance" also refers to a specific occurrence of an object, which may occur, for example, during execution of program code.

The terms "coupled," "communicatively coupled," and their derivatives are used herein. The term "coupled" may mean that two or more elements are in direct physical or electrical contact with each other, may mean that two or more elements are in indirect contact with 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 elements that are considered to be coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact with each other. The term "communicatively coupled" may mean that two or more elements may be in communication with each other, including by wired or other interconnection connections, by wireless communication channels or links, and so forth.

The term "cell" refers to a structural element that contains one or more fields. The term "field" refers to the individual content of a cell, or a data element containing content.

The term "SMTC" refers to an SSB-based measurement timing configuration configured by SSB-measurementtiming configuration.

The term "SSB" refers to an SS/PBCH block.

The term "primary cell" refers to an MCG cell operating on a primary frequency in which a UE performs an initial connection establishment procedure or initiates a connection re-establishment procedure.

The term "primary SCG cell" refers to an SCG cell in which a UE performs random access when performing a synchronization reconfiguration procedure, for DC operation.

The term "secondary cell", for a UE configured with CA, refers to a cell that provides additional radio resources over a special cell.

The term "secondary cell group" refers to a subset of serving cells including PSCell and zero or more secondary cells for a UE configured with DC.

The term "serving cell" refers to a primary cell for a UE in rrc_connected that is not configured with CA/DC, and only one serving cell includes the primary cell.

The term "serving cell" or "plurality of serving cells" refers to a set of cells including a special cell and all secondary cells for a UE in rrc_connected configured with CA/DC.

The term "special cell" refers to the PCell of an MCG or the PSCell of an SCG for DC operation; otherwise, the term "special cell" refers to a Pcell.

Claims (25)

1. An apparatus for an access node, comprising:

a memory interface to send or receive data storage device data Storage (SDT) information for Small Data Transfer (SDT) signaling between a gndeb (gNB) distributed unit (gNB-DU) and a gNB central unit (gNB-CU) of a Radio Access Network (RAN); and

a processor circuit communicatively coupled to the memory interface, the processor circuit to:

decoding that a Radio Resource Control (RRC) resume request message received by the gNB-DU from a User Equipment (UE) in an inactive state is due to SDT;

generating an initial Uplink (UL) RRC messaging message including an Information Element (IE) with one or more parameters for indicating that the RRC recovery request is due to the SDT; and

an indication is sent for sending an initial UL RRC message transfer message from the gNB-DU to the gNB-CU, the initial UL RRC message transfer message indicating 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 association services, the signaling service to send the initial UL RRC messaging message from the gNB-DU to the gNB-CU over an F1 interface in accordance with an F1 application protocol (F1 AP).

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

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

5. The apparatus of claim 1, wherein the IE is to indicate an SDT transaction and to provide side information from the UE, the IE comprising SDT information comprising an SDT indicator of an enumerated type with boolean parameters.

6. The apparatus of claim 1, wherein the IE is to indicate an SDT transaction and to provide side information from the UE, the IE comprising SDT information comprising SDT side information of an enumerated type with a single packet parameter to indicate that no subsequent SDT transmissions are expected or a multiple packet parameter to indicate that subsequent SDT transmissions are expected.

7. The apparatus of claim 1, comprising a Radio Frequency (RF) circuit communicatively coupled to the processor circuit, the RF circuit to receive an RF signal from the UE representative of the RRC recovery request message.

8. An apparatus for an access node, comprising:

A memory interface to send or receive data storage device data Storage (SDT) information for Small Data Transfer (SDT) signaling between a gndeb (gNB) distributed unit (gNB-DU) and a gNB central unit (gNB-CU) of a Radio Access Network (RAN); and

a processor circuit communicatively coupled to the memory interface, the processor circuit to:

determining that UE context information for a User Equipment (UE) is modified by the gNB-CU of the RAN;

generating a UE context modification request message to provide modified UE context information to the gNB-DU of the RAN, the UE context modification request message including an Information Element (IE) having one or more parameters for indicating a request for configuration information of a UE for SDT operation from the gNB-DU; and

an indication is sent for sending the UE context modification request message from the gNB-CU to the gNB-DU.

9. The apparatus of claim 8, the processor circuit to:

it is determined to modify the UE context information to generate a configuration approval (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 association services, the signaling service to send the UE context modification request message from the gNB-CU to the gNB-DU over an F1 interface in accordance with an F1 application protocol (F1 AP).

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

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

13. The apparatus of claim 8, wherein the acknowledgement information comprises a physical layer (PHY) or Medium Access Control (MAC) layer configuration of the UE.

14. The apparatus of claim 8, the processing circuit to:

a UE context modification response message received from the gNB-DU in response to the UE context modification request message is decoded, the UE context modification response message including the requested configuration information.

15. The apparatus of claim 8, the processing circuit to:

generating a configuration approval (CG) for the UE for CG SDT operations in response to receiving configuration information from the gNB-DU.

16. An apparatus for an access node, comprising:

a memory interface for transmitting to or receiving from a data storage device Small Data Transfer (SDT) information for SDT signaling between a first node and a second node of a Radio Access Network (RAN); and

A processor circuit communicatively coupled to the memory interface, the processor circuit to:

decoding a get User Equipment (UE) context request message received by a second node of the RAN from a first node of the RAN, the get UE context request message including the SDT information;

generating, by the second node of the RAN, an acquire UE context request response message including an Information Element (IE) having one or more parameters for representing part of the context information related to the SDT for the UE; and

an indication is sent for sending the get UE context request response message from the second node to the first node.

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

18. The apparatus of claim 16, wherein the get 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 partial UE context information for SDT, the IE having optional presence.

19. The apparatus of claim 16, wherein the IE group name for the IE of the get UE context request response message is a list of Protocol Data Unit (PDU) session resources to be added or a PDU session resource item to be added.

20. The apparatus of claim 16, wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) list to be established or an SDT DRB list to be established, the IE having a range of 0 to 1.

21. The apparatus of claim 16, wherein the IE group name for the IE of the acquire UE context request response message is a Data Radio Bearer (DRB) item to be established or an SDT DRB item to be established, the IE having a range of a maximum number of 1 to DRBs, wherein the maximum number of DRBs allowed towards one UE is 32.

22. The apparatus of claim 21, wherein the IE group name for the IE of the get UE context request response message is a Data Radio Bearer (DRB) Identifier (ID), the IE having a mandatory presence and an IE type and reference of an integer having a value of 1 to 32.

23. The apparatus of claim 21, wherein an IE group name for the IE of the acquire UE context request response message is Uplink (UL) Packet Data Convergence Protocol (PDCP) User Plane (UP) Transport Network Layer (TNL) information, the IE having mandatory presence 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 acquire UE context request response message is Uplink (UL) Transport Network Layer (TNL) information, the IE having mandatory presence and one or more User Plane (UP) transport parameters.

25. The apparatus of claim 21, wherein the IE group name for the IE of the get UE context request response message is:

a Data Radio Bearer (DRB) quality of service (QoS), the IE having a mandatory presence and one or more QoS flow classes or QoS parameters;

a Packet Data Convergence Protocol (PDCP) Sequence Number (SN) length including an IE type and a referenced Uplink (UL) PDCP SN length having a mandatory presence and enumerated with a value of 12 or 18 bits, or including an IE type and a referenced Downlink (DL) PDCP SN length having a mandatory presence and enumerated with a value of 12 or 18 bits;

a quality of service (QoS) flow list mapped to a Data Radio Bearer (DRB) or a flow list mapped to a Data Radio Bearer (DRB), the IE having a range of 1;

a quality of service (QoS) flow item mapped to a Data Radio Bearer (DRB) or a flow item mapped to a Data Radio Bearer (DRB), the IE having a range of 1 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 mandatory presence and an IE type and reference of an integer having a value from 0 to 63; or (b)

A quality of service (QoS) flow mapping indication, the IE having an IE type and reference enumerated with a value indicating whether uplink QoS is mapped to the DRB or a value indicating whether downlink QoS flows are mapped to the DRB.