WO2022061655A1

WO2022061655A1 - Small data random access channel procedure fallback

Info

Publication number: WO2022061655A1
Application number: PCT/CN2020/117467
Authority: WO
Inventors: Ruiming Zheng; Linhai He; Ozcan Ozturk; Gavin Bernard Horn
Original assignee: Qualcomm Inc
Current assignee: Qualcomm Inc
Priority date: 2020-09-24
Filing date: 2020-09-24
Publication date: 2022-03-31
Anticipated expiration: 2023-03-24

Abstract

Technologies and techniques for configuring a user equipment (UE) to fallback from small data communication during a random access (RA) procedure in an inactive state to a legacy connected state. The UE may be configured with small data retransmission limits and/or small data retransmission time limits in which the UE reverts from small data communication if the limits have been reached. A fallback bit may also be provided by a base station in which the UE engages in fallback from small data communication to legacy communication. In further examples, a UE may be configured with fallback during an RA procedure with an unlicensed network.

Description

SMALL DATA RANDOM ACCESS CHANNEL PROCEDURE FALLBACK

TECHNICAL FIELD

The technology discussed below relates generally to wireless communication networks, and more particularly, to techniques for providing channel state information in random-access messages.

INTRODUCTION

New Radio (NR) , which may also be referred to as 5G, is a set of enhancements to the LTE mobile standard promulgated by the Third Generation Partnership Project (3GPP) . NR is designed to better support mobile broadband Internet access by improving spectral efficiency, lowering costs, improving services, making use of new spectrum, and better integrating with other open standards using orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP) (CP-OFDM) on the downlink (DL) , using CP-OFDM and/or SC-FDM (e.g., also known as discrete Fourier transform spread OFDM (DFT-s-OFDM) ) on the uplink (UL) , as well as supporting beamforming, multiple-input multiple-output (MIMO) antenna technology, and carrier aggregation.

Recent enhancements to NR include technologies such as NR-Light and Small Data Transfer that enable transmission without going through the full connection set-up to minimize power consumption. These technologies may be used in various applications including, but not limited to, Internet of Things (IoT) , sensors, and smartphone applications. Random access (RA) is a procedure in cellular networks, enabling a device to initiate communications and time alignment to a base station. Downlink synchronization may be obtained after a device successfully decodes a synchronization signal block (SSB) received from the base station, in order to perform a random-access channel (RACH) procedure to establish uplink synchronization and radio resource control (RRC) connections.

BRIEF SUMMARY OF SOME EXAMPLES

The following presents a summary of one or more aspects of the present disclosure, in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated features of the disclosure, and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in a form as a prelude to the more detailed description that is presented later.

In one example, a method of wireless communication at a user equipment (UE) , is disclosed, the method comprising: receiving configuration data comprising a small data random-access channel (RACH) retransmission limit for establishing small data communications with a wireless network; transmitting a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and retransmitting the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission limit has not been reached.

In one example, a method of wireless communication at a user equipment (UE) , is disclosed, the method comprising: receiving configuration data comprising a random-access channel (RACH) retransmission time limit for establishing small data communications with a wireless network; transmitting a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and retransmitting the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission time limit has not been reached.

In one example, a method of wireless communication at a user equipment (UE) , is disclosed, the method comprising: receiving random-access channel (RACH) configuration data for establishing small data communications with a wireless network; transmitting a first RACH message for small data communication while the UE is in an inactive, state; receiving a fallback data on a random-access response from the transmission of the first RACH message; and transmitting a second RACH message without containing the user small data in response to the fallback data if a contention resolution with the network is not successful.

In one example, a method is disclosed of wireless communication at a user equipment (UE) for an unlicensed wireless network (NR-U) , the method comprising: receiving random-access channel (RACH) configuration data for establishing small data communications with the unlicensed wireless network; detecting the energy level on multiple sub-bands of a communications channel to determine if the energy is above or below a configured threshold; transmitting a first RACH message for small data communication while the UE is in an inactive state; detecting one or more failures of transmitting the first RACH message, based on the detected energy level being above the configured threshold; and transmitting a second RACH message without containing the user small data, based on the RACH configuration data, and on the detected energy level being below the configured threshold.

In one example, a method is disclosed of wireless communication at a base station (BS) , the method comprising: transmitting configuration data comprising a small data random-access channel (RACH) retransmission limit for a UE to establish small data communications with the BS; receiving a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and receiving a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.

In one example, a method is disclosed of wireless communication at a base station (BS) , the method comprising: transmitting configuration data comprising a random-access channel (RACH) retransmission time limit for the UE to establish small data communications with the BS; receiving a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and receiving a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.

In one example, a method is disclosed of wireless communication at a base station (BS) , the method comprising: transmitting random-access channel (RACH) configuration data for the UE to establish small data communications with a wireless network; receiving a first RACH message for small data communication while the UE is in an inactive, state; transmitting a fallback data on a random-access response from the receipt of the first RACH message; and receiving a second RACH message from the UE without containing the user small data in response to the fallback data if a contention resolution with the UE is not successful.

In one example, a user equipment (UE) is disclosed, comprising: a processor; and a memory coupled to the processor, wherein the processor and the memory are configured to receive configuration data comprising a small data random-access channel (RACH) retransmission limit for establishing small data communications with a wireless network; transmit a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and retransmit the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission limit has not been reached.

In one example, a user equipment (UE) is disclosed, comprising: a processor; and a memory coupled to the processor, wherein the processor and the memory are configured to receive configuration data comprising a random-access channel (RACH) retransmission time limit for establishing small data communications with a wireless network; transmit a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and retransmit the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission time limit has not been reached.

In one example, a user equipment (UE) is disclosed, comprising: a processor; and a memory coupled to the processor, wherein the processor and the memory are configured to receive random-access channel (RACH) configuration data for establishing small data communications with a wireless network; transmit a first RACH message for small data communication while the UE is in an inactive state; receive a fallback data on a random-access response from the transmission of the first RACH message; and transmit a second RACH message without containing the user small data in response to the fallback data if a contention resolution with the network is not successful.

In one example, a user equipment (UE) is disclosed for communicating with an unlicensed wireless network (NR-U) , comprising: a processor; and a memory coupled to the processor, wherein the processor and the memory are configured to receive random-access channel (RACH) configuration data for establishing small data communications with the unlicensed wireless network; detect the energy level on multiple sub-bands of a communications channel to determine if the energy is above or below a configured threshold; transmit a first RACH message for small data communication while the UE is in an inactive state; detect one or more failures of transmitting the first RACH message, based on the detected energy level being above the configured threshold; and transmit a second RACH message without containing the user small data, based RACH configuration data, and on the detected energy level being below the configured threshold.

In one example, a base station (BS) is disclosed, comprising: a processor; and a memory coupled to the processor, wherein the processor and the memory are configured to transmit configuration data comprising a small data random-access channel (RACH) retransmission limit for a UE to establish small data communications with the BS; receive a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and receive a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.

In one example, a base station (BS) is disclosed, comprising: a processor; and a memory coupled to the processor, wherein the processor and the memory are configured to transmit configuration data comprising a random-access channel (RACH) retransmission time limit for the UE to establish small data communications with the BS; receive a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and receive a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.

In one example, a base station (BS) is disclosed, comprising: a processor; and a memory coupled to the processor, wherein the processor and the memory are configured to transmit random-access channel (RACH) configuration data for the UE to establish small data communications with a wireless network; receive a first RACH message for small data communication while the UE is in an inactive state; transmit a fallback data on a random-access response from the receipt of the first RACH message; and receive a second RACH message from the UE without containing the user small data in response to the fallback data if a contention resolution with the UE is not successful.

These and other aspects of the invention will become more fully understood upon a review of the detailed description, which follows. Other aspects, features, and embodiments of the present invention will become apparent to those of ordinary skill in the art, upon reviewing the following description of specific, exemplary embodiments of the present invention in conjunction with the accompanying figures. While features of the present invention may be discussed relative to certain embodiments and figures below, all embodiments of the present invention can include one or more of the advantageous features discussed herein. In other words, while one or more embodiments may be discussed as having certain advantageous features, one or more of such features may also be used in accordance with the various embodiments of the invention discussed herein. In similar fashion, while exemplary embodiments may be discussed below as device, system, or method embodiments it should be understood that such exemplary embodiments can be implemented in various devices, systems, and methods.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic illustration of a wireless communication system according to some aspects;

FIG. 2 is a conceptual illustration of an example of a radio access network according to some aspects;

FIG. 3 is a schematic diagram illustrating organization of wireless resources in an air interface utilizing orthogonal frequency divisional multiplexing (OFDM) according to some aspects;

FIG. 4 is a diagram illustrating an example of a four-step random-access channel (RACH) procedure according to some aspects.

FIG. 5 is a diagram illustrating an example two-step RACH procedure according to some aspects;

FIG. 6 is a block diagram illustrating an example of a random-access (RA) preamble that may be used in a two-step RACH procedure according to some aspects;

FIG. 7 is a diagram illustrating signaling between a scheduled entity and scheduling entity during a RACH procedure when a random-access (RA) payload is decoded according to some aspects;

FIG. 8 is a diagram illustrating signaling between a scheduled entity and scheduling entity during a RACH procedure when only a RA preamble is decoded according to some aspects;

FIG. 9 is a diagram illustrating a two-step RACH msgA retransmission configuration according to some aspects;

FIG. 10 is a diagram illustrating a RACH fallback procedure according to some aspects;

FIG. 11 is a diagram illustrating an example associated with uplink data transfer over random access or configured uplink resources, according to some aspects;

FIG. 12 is a flow diagram illustrating small data RACH fallback using a retransmission limit and/or a retransmission timing limit, according to some aspects;

FIG. 13 is a flow diagram illustrating small data RACH fallback using a fallback bit in a random-access response (RAR) , according to some aspects;

FIG. 14 is a diagram illustrating a media access control (MAC) RAR message for small data communications that includes a fallback bit according to some aspects;

FIG. 15 is a conceptual diagram illustrating an example of a hardware implementation for an exemplary wireless communication device employing a processing system according to some aspects;

FIG. 16 is a conceptual diagram illustrating an example of a hardware implementation a scheduling entity employing a processing system according to some aspects;

FIG. 17 is a flowchart of a method for retransmitting small data in accordance with a RACH retransmission limit according to some aspects;

FIG. 18 is a flowchart of a method for retransmitting small data in accordance with a RACH retransmission time limit according to some aspects;

FIG. 19 is a flowchart of a method for retransmitting small data in accordance with RACH fallback data (e.g., F bit) according to some aspects;

FIG. 20 is a flowchart of a method for retransmitting small data in an unlicensed wireless network (NR-U) according to some aspects;

FIG. 21 is a flowchart of a method for a base station to configure a UE to retransmit small data in accordance with a RACH retransmission limit according to some aspects;

FIG. 22 is a flowchart of a method for a base station to configure a UE to retransmit small data in accordance with a RACH retransmission time limit according to some aspects; and

FIG. 23 is a flowchart of a method for a base station to configure a UE to retransmit small data in accordance with RACH fallback data (e.g., F bit) according to some aspects.

DETAILED DESCRIPTION

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

While aspects and embodiments are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases may come about in many different arrangements and scenarios. Innovations described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, packaging arrangements. For example, embodiments and/or uses may come about via integrated chip embodiments and other non-module-component based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail/purchasing devices, medical devices, AI-enabled devices, etc. ) . While some examples may or may not be specifically directed to use cases or applications, a wide assortment of applicability of described innovations may occur. Implementations may range a spectrum from chip-level or modular components to non-modular, non-chip-level implementations and further to aggregate, distributed, or OEM devices or systems incorporating one or more aspects of the described innovations. In some practical settings, devices incorporating described aspects and features may also necessarily include additional components and features for implementation and practice of claimed and described embodiments. For example, transmission and reception of wireless signals necessarily includes a number of components for analog and digital purposes (e.g., hardware components including antenna, RF-chains, power amplifiers, modulators, buffer, processor (s) , interleaver, adders/summers, etc. ) . It is intended that innovations described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, end-user devices, etc. of varying sizes, shapes and constitution.

The various concepts presented throughout this disclosure may be implemented across a broad variety of telecommunication systems, network architectures, and communication standards. Referring now to FIG. 1, as an illustrative example without limitation, various aspects of the present disclosure are illustrated with reference to a wireless communication system 100. The wireless communication system 100 includes three interacting domains: a core network 102, a radio access network (RAN) 104, and a user equipment (UE) 106. By virtue of the wireless communication system 100, the UE 106 may be enabled to carry out data communication with an external data network 110, such as (but not limited to) the Internet.

The RAN 104 may implement any suitable radio access technology (RAT) or RATs to provide radio access to the UE 106. As one example, the RAN 104 may operate according to 3rd Generation Partnership Project (3GPP) New Radio (NR) specifications, often referred to as 5G. As another example, the RAN 104 may operate under a hybrid of 5G NR and Evolved Universal Terrestrial Radio Access Network (eUTRAN) standards, often referred to as LTE. The 3GPP refers to this hybrid RAN as a next-generation RAN, or NG-RAN. In another example, the RAN 104 may operate according to both the LTE and 5G NR standards. Of course, many other examples may be utilized within the scope of the present disclosure.

As illustrated, the RAN 104 includes a plurality of base stations 108. Broadly, a base station is a network element in a radio access network responsible for radio transmission and reception in one or more cells to or from a UE. In different technologies, standards, or contexts, a base station may variously be referred to by those skilled in the art as a base transceiver station (BTS) , a radio base station, a radio transceiver, a transceiver function, a basic service set (BSS) , an extended service set (ESS) , an access point (AP) , a Node B (NB) , an eNode B (eNB) , a gNode B (gNB) , a transmission and reception point (TRP) , or some other suitable terminology. In some examples, a base station may include two or more TRPs that may be collocated or non-collocated. Each TRP may communicate on the same or different carrier frequency within the same or different frequency band. In examples where the RAN 104 operates according to both the LTE and 5G NR standards, one of the base stations 108 may be an LTE base station, while another base station may be a 5G NR base station.

The radio access network 104 is further illustrated supporting wireless communication for multiple mobile apparatuses. A mobile apparatus may be referred to as user equipment (UE) 106 in 3GPP standards, but may also be referred to by those skilled in the art as a mobile station (MS) , a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communications device, a remote device, a mobile subscriber station, an access terminal (AT) , a mobile terminal, a wireless terminal, a remote terminal, a handset, a terminal, a user agent, a mobile client, a client, or some other suitable terminology. A UE 106 may be an apparatus that provides a user with access to network services. In examples where the RAN 104 operates according to both the LTE and 5G NR standards, the UE 106 may be an Evolved-Universal Terrestrial Radio Access Network –New Radio dual connectivity (EN-DC) UE that is capable of simultaneously connecting to an LTE base station and a NR base station to receive data packets from both the LTE base station and the NR base station.

Within the present document, a “mobile” apparatus need not necessarily have a capability to move, and may be stationary. The term mobile apparatus or mobile device broadly refers to a diverse array of devices and technologies. UEs may include a number of hardware structural components sized, shaped, and arranged to help in communication; such components can include antennas, antenna arrays, RF chains, amplifiers, one or more processors, etc. electrically coupled to each other. For example, some non-limiting examples of a mobile apparatus include a mobile, a cellular (cell) phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a personal computer (PC) , a notebook, a netbook, a smartbook, a tablet, a personal digital assistant (PDA) , and a broad array of embedded systems, e.g., corresponding to an “Internet of Things” . A mobile apparatus may additionally be an automotive or other transportation vehicle, a remote sensor or actuator, a robot or robotics device, a satellite radio, a global positioning system (GPS) device, an object tracking device, a drone, a multi-copter, a quad-copter, a remote control device, a consumer and/or wearable device, such as eyewear, a wearable camera, a virtual reality device, a smart watch, a health or fitness tracker, a digital audio player (e.g., MP3 player) , a camera, a game console, etc. A mobile apparatus may additionally be a digital home or smart home device such as a home audio, video, and/or multimedia device, an appliance, a vending machine, intelligent lighting, a home security system, a smart meter, etc. A mobile apparatus may additionally be a smart energy device, a security device, a solar panel or solar array, a municipal infrastructure device controlling electric power (e.g., a smart grid) , lighting, water, etc.; an industrial automation and enterprise device; a logistics controller; agricultural equipment; military defense equipment, vehicles, aircraft, ships, and weaponry, etc. Still further, a mobile apparatus may provide for connected medicine or telemedicine support, i.e., health care at a distance. Telehealth devices may include telehealth monitoring devices and telehealth administration devices, whose communication may be given preferential treatment or prioritized access over other types of information, e.g., in terms of prioritized access for transport of critical service data, and/or relevant QoS for transport of critical service data.

Wireless communication between a RAN 104 and a UE 106 may be described as utilizing an air interface. Transmissions over the air interface from a base station (e.g., base station 108) to one or more UEs (e.g., UE 106) may be referred to as downlink (DL) transmission. In accordance with certain aspects of the present disclosure, the term downlink may refer to a point-to-multipoint transmission originating at a scheduling entity (described further below; e.g., base station 108) . Another way to describe this scheme may be to use the term broadcast channel multiplexing. Transmissions from a UE (e.g., UE 106) to a base station (e.g., base station 108) may be referred to as uplink (UL) transmissions. In accordance with further aspects of the present disclosure, the term uplink may refer to a point-to-point transmission originating at a scheduled entity (described further below; e.g., UE 106) .

In some examples, access to the air interface may be scheduled, wherein a scheduling entity (e.g., a base station 108) allocates resources for communication among some or all devices and equipment within its service area or cell. Within the present disclosure, as discussed further below, the scheduling entity may be responsible for scheduling, assigning, reconfiguring, and releasing resources for one or more scheduled entities. That is, for scheduled communication, UEs 106, which may be scheduled entities, may utilize resources allocated by the scheduling entity 108.

Base stations 108 are not the only entities that may function as scheduling entities. That is, in some examples, a UE may function as a scheduling entity, scheduling resources for one or more scheduled entities (e.g., one or more other UEs) .

As illustrated in FIG. 1, a scheduling entity 108 may broadcast downlink traffic 112 to one or more scheduled entities 106. Broadly, the scheduling entity 108 is a node or device responsible for scheduling traffic in a wireless communication network, including the downlink traffic 112 and, in some examples, uplink traffic 116 from one or more scheduled entities 106 to the scheduling entity 108. On the other hand, the scheduled entity 106 is a node or device that receives downlink control information 114, including but not limited to scheduling information (e.g., a grant) , synchronization or timing information, or other control information from another entity in the wireless communication network such as the scheduling entity 108.

In addition, the uplink and/or downlink control information and/or traffic information may be time-divided into frames, subframes, slots, and/or symbols. As used herein, a symbol may refer to a unit of time that, in an orthogonal frequency division multiplexed (OFDM) waveform, carries one resource element (RE) per sub-carrier. A slot may carry 7 or 14 OFDM symbols. A subframe may refer to a duration of 1ms. Multiple subframes or slots may be grouped together to form a single frame or radio frame. Of course, these definitions are not required, and any suitable scheme for organizing waveforms may be utilized, and various time divisions of the waveform may have any suitable duration.

In general, base stations 108 may include a backhaul interface for communication with a backhaul portion 120 of the wireless communication system. The backhaul 120 may provide a link between a base station 108 and the core network 102. Further, in some examples, a backhaul network may provide interconnection between the respective base stations 108. Various types of backhaul interfaces may be employed, such as a direct physical connection, a virtual network, or the like using any suitable transport network.

The core network 102 may be a part of the wireless communication system 100, and may be independent of the radio access technology used in the RAN 104. In some examples, the core network 102 may be configured according to 5G standards (e.g., 5GC) . In other examples, the core network 102 may be configured according to a 4G evolved packet core (EPC) , or any other suitable standard or configuration.

Referring now to FIG. 2, by way of example and without limitation, a schematic illustration of a RAN 200 is provided. In some examples, the RAN 200 may be the same as the RAN 104 described above and illustrated in FIG. 1. The geographic area covered by the RAN 200 may be divided into cellular regions (cells) that can be uniquely identified by a user equipment (UE) based on an identification broadcasted from one access point or base station. FIG. 2 illustrates

macrocells

202, 204, and 206, and a small cell 208, each of which may include one or more sectors (not shown) . A sector is a sub-area of a cell. All sectors within one cell are served by the same base station. A radio link within a sector can be identified by a single logical identification belonging to that sector. In a cell that is divided into sectors, the multiple sectors within a cell can be formed by groups of antennas with each antenna responsible for communication with UEs in a portion of the cell.

In FIG. 2, two base stations 210 and 212 are shown in

cells

202 and 204; and a third base station 214 is shown controlling a remote radio head (RRH) 216 in cell 206. That is, a base station can have an integrated antenna or can be connected to an antenna or RRH by feeder cables. In the illustrated example, the

cells

202, 204, and 126 may be referred to as macrocells, as the

base stations

210, 212, and 214 support cells having a large size. Further, a base station 218 is shown in the small cell 208 (e.g., a microcell, picocell, femtocell, home base station, home Node B, home eNode B, etc. ) which may overlap with one or more macrocells. In this example, the cell 208 may be referred to as a small cell, as the base station 218 supports a cell having a relatively small size. Cell sizing can be done according to system design as well as component constraints.

It is to be understood that the radio access network 200 may include any number of wireless base stations and cells. Further, a relay node may be deployed to extend the size or coverage area of a given cell. The

base stations

210, 212, 214, 218 provide wireless access points to a core network for any number of mobile apparatuses. In some examples, the

base stations

210, 212, 214, and/or 218 may be the same as the base station/scheduling entity 108 described above and illustrated in FIG. 1.

Within the RAN 200, the cells may include UEs that may be in communication with one or more sectors of each cell. Further, each

base station

210, 212, 214, and 218 may be configured to provide an access point to a core network 102 (see FIG. 1) for all the UEs in the respective cells. For example,

UEs

222 and 224 may be in communication with base station 210;

UEs

226 and 228 may be in communication with base station 212;

UEs

230 and 232 may be in communication with base station 214 by way of RRH 216; and UE 234 may be in communication with base station 218. In some examples, the

UEs

222, 224, 226, 228, 230, 232, 234, 238, 240, and/or 242 may be the same as the UE/scheduled entity 106 described above and illustrated in FIG. 1.

In some examples, an unmanned aerial vehicle (UAV) 220, which may be a drone or quadcopter, can be a mobile network node and may be configured to function as a UE. For example, the UAV 220 may operate within cell 202 by communicating with base station 210.

In the radio access network 200, the ability for a UE to communicate while moving, independent of its location, is referred to as mobility. The various physical channels between the UE and the radio access network are generally set up, maintained, and released under the control of an access and mobility management function (AMF, not illustrated, part of the core network 102 in FIG. 1) , which may include a security context management function (SCMF) that manages the security context for both the control plane and the user plane functionality, and a security anchor function (SEAF) that performs authentication.

A radio access network 200 may utilize DL-based mobility or UL-based mobility to enable mobility and handovers (i.e., the transfer of a UE’s connection from one radio channel to another) . In a network configured for DL-based mobility, during a call with a scheduling entity, or at any other time, a UE may monitor various parameters of the signal from its serving cell as well as various parameters of neighboring cells. Depending on the quality of these parameters, the UE may maintain communication with one or more of the neighboring cells. During this time, if the UE moves from one cell to another, or if signal quality from a neighboring cell exceeds that from the serving cell for a given amount of time, the UE may undertake a handoff or handover from the serving cell to the neighboring (target) cell. For example, UE 224 (illustrated as a vehicle, although any suitable form of UE may be used) may move from the geographic area corresponding to its serving cell 202 to the geographic area corresponding to a neighbor cell 206. When the signal strength or quality from the neighbor cell 206 exceeds that of its serving cell 202 for a given amount of time, the UE 224 may transmit a reporting message to its serving base station 210 indicating this condition. In response, the UE 224 may receive a handover command, and the UE may undergo a handover to the cell 206.

In a network configured for UL-based mobility, UL reference signals from each UE may be utilized by the network to select a serving cell for each UE. In some examples, the

base stations

210, 212, and 214/216 may broadcast unified synchronization signals (e.g., unified Primary Synchronization Signals (PSSs) , unified Secondary Synchronization Signals (SSSs) and unified Physical Broadcast Channels (PBCH) ) . The

UEs

222, 224, 226, 228, 230, and 232 may receive the unified synchronization signals, derive the carrier frequency and slot timing from the synchronization signals, and in response to deriving timing, transmit an uplink pilot or reference signal. The uplink pilot signal transmitted by a UE (e.g., UE 224) may be concurrently received by two or more cells (e.g., base stations 210 and 214/216) within the radio access network 200. Each of the cells may measure a strength of the pilot signal, and the radio access network (e.g., one or more of the base stations 210 and 214/216 and/or a central node within the core network) may determine a serving cell for the UE 224. As the UE 224 moves through the radio access network 200, the network may continue to monitor the uplink pilot signal transmitted by the UE 224. When the signal strength or quality of the pilot signal measured by a neighboring cell exceeds that of the signal strength or quality measured by the serving cell, the network 200 may handover the UE 224 from the serving cell to the neighboring cell, with or without informing the UE 224.

Although the synchronization signal transmitted by the

base stations

210, 212, and 214/216 may be unified, the synchronization signal may not identify a particular cell, but rather may identify a zone of multiple cells operating on the same frequency and/or with the same timing. The use of zones in 5G networks or other next generation communication networks enables the uplink-based mobility framework and improves the efficiency of both the UE and the network, since the number of mobility messages that need to be exchanged between the UE and the network may be reduced.

In various implementations, the air interface in the radio access network 200 may utilize licensed spectrum, unlicensed spectrum, or shared spectrum. Licensed spectrum provides for exclusive use of a portion of the spectrum, generally by virtue of a mobile network operator purchasing a license from a government regulatory body. Unlicensed spectrum provides for shared use of a portion of the spectrum without need for a government-granted license. While compliance with some technical rules is generally still required to access unlicensed spectrum, generally, any operator or device may gain access. Shared spectrum may fall between licensed and unlicensed spectrum, wherein technical rules or limitations may be required to access the spectrum, but the spectrum may still be shared by multiple operators and/or multiple RATs. For example, the holder of a license for a portion of licensed spectrum may provide licensed shared access (LSA) to share that spectrum with other parties, e.g., with suitable licensee-determined conditions to gain access.

In some examples, access to the air interface may be scheduled, where a scheduling entity (e.g., a base station) allocates resources (e.g., time–frequency resources) for communication among some or all devices and equipment within its service area or cell. Within the present disclosure, as discussed further below, the scheduling entity may be responsible for scheduling, assigning, reconfiguring, and releasing resources for one or more scheduled entities. That is, for scheduled communication, UEs or scheduled entities utilize resources allocated by the scheduling entity.

Base stations are not the only entities that may function as a scheduling entity. That is, in some examples, a UE may function as a scheduling entity, scheduling resources for one or more scheduled entities (e.g., one or more other UEs) . In this example, sidelink or other type of direct link signals may be communicated directly between UEs without necessarily relying on scheduling or control information from another entity. For example, UE 238 is illustrated communicating with

UEs

240 and 242. In some examples, the UE 238 is functioning as a scheduling entity, while the

UEs

240 and 242 may function as scheduled entities.

UEs

238, 240, and 242 may communicate over a direct link in a device-to-device (D2D) , peer-to-peer (P2P) , vehicle-to-everything (V2X) , and/or in a mesh network. In a mesh network example,

UEs

240 and 242 may optionally communicate directly with one another in addition to communicating with a scheduling entity (e.g., UE 238) . In some examples, UE 238 may be a transmitting sidelink device that reserves resources on a sidelink carrier for the transmission of sidelink signals to UEs 240 and 242 in a D2D or V2X network. Here,

UEs

240 and 242 are each receiving sidelink devices.

UEs

240 and 242 may, in turn, reserve additional resources on the sidelink carrier for subsequent sidelink transmissions.

In some examples, two or more UEs (e.g., UEs 226 and 228) within the coverage area of a serving base station 212 may communicate with both the base station 212 using cellular signals and with each other using sidelink signals 227 without relaying that communication through the base station. In this example, the base station 212 or one or both of the

UEs

226 and 228 may function as scheduling entities to schedule sidelink communication between

UEs

226 and 228. For example,

UEs

226 and 228 may communicate sidelink signals 227 within a vehicle-to-everything (V2X) network.

In order for transmissions over the radio access network 200 to obtain a low block error rate (BLER) while still achieving very high data rates, channel coding may be used. That is, wireless communication may generally utilize a suitable error correcting block code. In a typical block code, an information message or sequence is split up into code blocks (CBs) , and an encoder (e.g., a CODEC) at the transmitting device then mathematically adds redundancy to the information message. Exploitation of this redundancy in the encoded information message can improve the reliability of the message, enabling correction for any bit errors that may occur due to the noise.

In early 5G NR specifications, user data is coded using quasi-cyclic low-density parity check (LDPC) with two different base graphs: one base graph is used for large code blocks and/or high code rates, while the other base graph is used otherwise. Control information and the physical broadcast channel (PBCH) are coded using Polar coding, based on nested sequences. For these channels, puncturing, shortening, and repetition are used for rate matching.

However, those of ordinary skill in the art will understand that aspects of the present disclosure may be implemented utilizing any suitable channel code. Various implementations of base stations (e.g., scheduling entities) 108 and UEs (e.g., scheduled entities) 106 may include suitable hardware and capabilities (e.g., an encoder, a decoder, and/or a CODEC) to utilize one or more of these channel codes for wireless communication.

The air interface in the radio access network 200 may utilize one or more duplexing algorithms. Duplex refers to a point-to-point communication link where both endpoints can communicate with one another in both directions. Full-duplex means both endpoints can simultaneously communicate with one another. Half-duplex means only one endpoint can send information to the other at a time. Half-duplex emulation is frequently implemented for wireless links utilizing time division duplex (TDD) . In TDD, transmissions in different directions on a given channel are separated from one another using time division multiplexing. That is, at some times the channel is dedicated for transmissions in one direction, while at other times the channel is dedicated for transmissions in the other direction, where the direction may change very rapidly, e.g., several times per slot. In a wireless link, a full-duplex channel generally relies on physical isolation of a transmitter and receiver, and suitable interference cancellation technologies. Full-duplex emulation is frequently implemented for wireless links by utilizing frequency division duplex (FDD) or spatial division duplex (SDD) . In FDD, transmissions in different directions may operate at different carrier frequencies (e.g., within paired spectrum) . In SDD, transmissions in different directions on a given channel are separated from one another using spatial division multiplexing (SDM) . In other examples, full-duplex communication may be implemented within unpaired spectrum (e.g., within a single carrier bandwidth) , where transmissions in different directions occur within different sub-bands of the carrier bandwidth. This type of full-duplex communication may be referred to herein as sub-band full duplex (SBFD) , also known as flexible duplex.

The air interface in the radio access network 200 may further utilize one or more multiplexing and multiple access algorithms to enable simultaneous communication of the various devices. For example, 5G NR specifications provide multiple access for UL transmissions from

UEs

222 and 224 to base station 210, and for multiplexing for DL transmissions from base station 210 to one or

more UEs

222 and 224, utilizing orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP) . In addition, for UL transmissions, 5G NR specifications provide support for discrete Fourier transform-spread-OFDM (DFT-s-OFDM) with a CP (also referred to as single-carrier FDMA (SC-FDMA) ) . However, within the scope of the present disclosure, multiplexing and multiple access are not limited to the above schemes, and may be provided utilizing time division multiple access (TDMA) , code division multiple access (CDMA) , frequency division multiple access (FDMA) , sparse code multiple access (SCMA) , resource spread multiple access (RSMA) , or other suitable multiple access schemes. Further, multiplexing DL transmissions from the base station 210 to UEs 222 and 224 may be provided utilizing time division multiplexing (TDM) , code division multiplexing (CDM) , frequency division multiplexing (FDM) , orthogonal frequency division multiplexing (OFDM) , sparse code multiplexing (SCM) , or other suitable multiplexing schemes.

Various aspects of the present disclosure will be described with reference to an OFDM waveform, an example of which is schematically illustrated in FIG. 3. It should be understood by those of ordinary skill in the art that the various aspects of the present disclosure may be applied to an SC-FDMA waveform in substantially the same way as described herein below. That is, while some examples of the present disclosure may focus on an OFDM link for clarity, it should be understood that the same principles may be applied as well to SC-FDMA waveforms.

Referring now to FIG. 3, an expanded view of an exemplary DL subframe 302 is illustrated, showing an OFDM resource grid. However, as those skilled in the art will readily appreciate, the PHY transmission structure for any particular application may vary from the example described here, depending on any number of factors. Here, time is in the horizontal direction with units of OFDM symbols; and frequency is in the vertical direction with units of subcarriers.

The resource grid 304 may be used to schematically represent time–frequency resources for a given antenna port. That is, in a multiple-input-multiple-output (MIMO) implementation with multiple antenna ports available, a corresponding multiple number of resource grids 304 may be available for communication. The resource grid 304 is divided into multiple resource elements (REs) 306. An RE, which is 1 subcarrier × 1 symbol, is the smallest discrete part of the time–frequency grid, and contains a single complex quantity representing data from a physical channel or signal. Depending on the modulation utilized in a particular implementation, each RE may represent one or more bits of information. In some examples, a block of REs may be referred to as a physical resource block (PRB) or more simply a resource block (RB) 308, which contains any suitable number of consecutive subcarriers in the frequency domain. In one example, an RB may include 12 subcarriers, a number independent of the numerology used. In some examples, depending on the numerology, an RB may include any suitable number of consecutive OFDM symbols in the time domain. Within the present disclosure, it is assumed that a single RB such as the RB 308 entirely corresponds to a single direction of communication (either transmission or reception for a given device) .

A UE generally utilizes only a subset of the resource grid 304. An RB may be the smallest unit of resources that can be allocated to a UE. Thus, the more RBs scheduled for a UE, and the higher the modulation scheme chosen for the air interface, the higher the data rate for the UE.

In this illustration, the RB 308 is shown as occupying less than the entire bandwidth of the subframe 302, with some subcarriers illustrated above and below the RB 308. In a given implementation, the subframe 302 may have a bandwidth corresponding to any number of one or more RBs 308. Further, in this illustration, the RB 308 is shown as occupying less than the entire duration of the subframe 302, although this is merely one possible example.

Each 1 ms subframe 302 may consist of one or multiple adjacent slots. In the example shown in FIG. 4, one subframe 302 includes four slots 310, as an illustrative example. In some examples, a slot may be defined according to a specified number of OFDM symbols with a given cyclic prefix (CP) length. For example, a slot may include 7 or 14 OFDM symbols with a nominal CP. Additional examples may include mini-slots having a shorter duration (e.g., one or two OFDM symbols) . These mini-slots may in some cases be transmitted occupying resources scheduled for ongoing slot transmissions for the same or for different UEs.

An expanded view of one of the slots 310 illustrates the slot 310 including a control region 312 and a data region 314. In general, the control region 312 may carry control channels (e.g., PDCCH) , and the data region 314 may carry data channels (e.g., PDSCH or PUSCH) . Of course, a slot may contain all DL, all UL, or at least one DL portion and at least one UL portion. The simple structure illustrated in FIG. 3 is merely exemplary in nature, and different slot structures may be utilized, and may include one or more of each of the control region (s) and data region (s) .

Although not illustrated in FIG. 3, the various REs 306 within a RB 308 may be scheduled to carry one or more physical channels, including control channels, shared channels, data channels, etc. Other REs 306 within the RB 308 may also carry pilots or reference signals. These pilots or reference signals may provide for a receiving device to perform channel estimation of the corresponding channel, which may enable coherent demodulation/detection of the control and/or data channels within the RB 308.

In some examples, the slot 410 may be utilized for broadcast or unicast communication. For example, a broadcast, multicast, or groupcast communication may refer to a point-to-multipoint transmission by one device (e.g., a base station, UE, or other similar device) to other devices. Here, a broadcast communication is delivered to all devices, whereas a multicast communication is delivered to multiple intended recipient devices. A unicast communication may refer to a point-to-point transmission by a one device to a single other device.

In an example of cellular communication over a cellular carrier via a Uu interface, for a DL transmission, the scheduling entity (e.g., a base station) may allocate one or more REs 406 (e.g., within the control region 412) to carry DL control information including one or more DL control channels, such as a physical downlink control channel (PDCCH) , to one or more scheduled entities (e.g., UEs) . The PDCCH carries downlink control information (DCI) including but not limited to power control commands (e.g., one or more open loop power control parameters and/or one or more closed loop power control parameters) , scheduling information, a grant, and/or an assignment of REs for DL and UL transmissions. The PDCCH may further carry HARQ feedback transmissions such as an acknowledgment (ACK) or negative acknowledgment (NACK) . HARQ is a technique well-known to those of ordinary skill in the art, wherein the integrity of packet transmissions may be checked at the receiving side for accuracy, e.g., utilizing any suitable integrity checking mechanism, such as a checksum or a cyclic redundancy check (CRC) . If the integrity of the transmission confirmed, an ACK may be transmitted, whereas if not confirmed, a NACK may be transmitted. In response to a NACK, the transmitting device may send a HARQ retransmission, which may implement chase combining, incremental redundancy, etc.

The base station may further allocate one or more REs 406 (e.g., in the control region 412 or the data region 414) to carry other DL signals, such as a demodulation reference signal (DMRS) ; a phase-tracking reference signal (PT-RS) ; a channel state information (CSI) reference signal (CSI-RS) ; and a synchronization signal block (SSB) . SSBs may be broadcast at regular intervals based on a periodicity (e.g., 5, 10, 20, 40, 80, or 140 ms) . An SSB includes a primary synchronization signal (PSS) , a secondary synchronization signal (SSS) , and a physical broadcast control channel (PBCH) . A UE may utilize the PSS and SSS to achieve radio frame, subframe, slot, and symbol synchronization in the time domain, identify the center of the channel (system) bandwidth in the frequency domain, and identify the physical cell identity (PCI) of the cell.

The PBCH in the SSB may further include a master information block (MIB) that includes various system information, along with parameters for decoding a system information block (SIB) . The SIB may be, for example, a SystemInformationType 1 (SIB1) that may include various additional system information. Examples of system information transmitted in the MIB may include, but are not limited to, a subcarrier spacing, system frame number, a configuration of a PDCCH control resource set (CORESET) (e.g., PDCCH CORESET0) , and a search space for SIB1. Examples of additional system information transmitted in the SIB1 may include, but are not limited to, a random-access search space, downlink configuration information, and uplink configuration information. The MIB and SIB1 together provide the minimum system information (SI) for initial access.

In an UL transmission, the transmitting device (e.g., the scheduled entity) may utilize one or more REs 306 to carry UL control information including one or more UL control channels, such as a physical uplink control channel (PUCCH) and/or a Random-Access Channel (RACH) . The RACH may be used, for example, in a random-access procedure during initial access of the uplink. UL control information may include a variety of packet types and categories, including pilots, reference signals, and information configured to enable or assist in decoding uplink data transmissions. For example, the UL control information may include a DMRS or SRS. In some examples, the control information may include a scheduling request (SR) , i.e., request for the scheduling entity to schedule uplink transmissions. Here, in response to the SR transmitted on the control channel, the scheduling entity may transmit downlink control information that may schedule resources for uplink packet transmissions. UL control information may also include HARQ feedback, channel state feedback (CSF) , or any other suitable UL control information. UL transmissions can be grant-based (i.e. grant delivered using DCI) , or grant-free, including type-1 (e.g., only based on RRC configuration without any L1 signaling) or type-2 (e.g., based on RRC configuration and L1 signaling for activation/deactivation) .

In addition to control information, one or more REs 306 (e.g., within the data region 314) may be allocated for user data or traffic data. Such traffic may be carried on one or more traffic channels, such as, for a DL transmission, a PDSCH; or for an UL transmission, a physical uplink shared channel (PUSCH) . In some examples, one or more REs 306 within the data region 314 may be configured to carry one or more SIBs or one or more DMRSs.

These physical channels described above are generally multiplexed and mapped to transport channels for handling at the medium access control (MAC) layer. Transport channels carry blocks of information called transport blocks (TB) . The transport block size (TBS) , which may correspond to a number of bits of information, may be a controlled parameter, based on the modulation and coding scheme (MCS) and the number of RBs in a given transmission.

The channels or carriers described above with reference to FIGs. 1–3 are not necessarily all of the channels or carriers that may be utilized between a scheduling entity and scheduled entities, and those of ordinary skill in the art will recognize that other channels or carriers may be utilized in addition to those illustrated, such as other traffic, control, and feedback channels.

FIG. 4 is a diagram illustrating an example of a four-step random-access channel (RACH) procedure 400 according to some aspects. The scheduling entity 402 may correspond, for example, to a gNB or any of the scheduling entities shown in FIGs. 1 and/or 2. In addition, the scheduled entity 404 may correspond, for example, to a UE or any of the scheduled entities shown in FIGs. 1 and/or 2.

The random-access procedure 400 shown in FIG. 4 is initiated when the scheduled entity 404 first receives an SSB, RS and RACH configuration 406. The scheduled entity 404 may then randomly select a preamble from an available set of preambles within the cell served by the scheduling entity 402 as indicated in the RACH configuration, and transmit the selected preamble to the scheduling entity 402 in a RACH preamble message 408 (msg1) . In an example, the scheduled entity 404 may select from 64 possible preamble sequences for inclusion in the RACH preamble message 406. The msg1 408 may be transmitted by the scheduled entity 404 over a selected PRACH resource corresponding to a RACH occasion (RO) with power ramping. The selected PRACH resource may include supplementary uplink resources or normal uplink resources. Here, supplementary uplink resources include lower frequency resources than normal uplink resources. Thus, supplementary uplink resources and uplink resources each correspond to a different respective uplink frequency band.

If the preamble is successfully detected by the scheduling entity 402, the scheduling entity 402 transmits a random-access response (RAR) message 410 (msg2) including a PDCCH and PDSCH to the scheduled entity 404. If no msg2 (RAR) 410 is received within a RAR window, the scheduled entity 404 may retransmit msg1 408 with power boost. The msg2 410 (PDCCH + PDSCH) includes an identifier of the preamble sent by the scheduled entity 404, a Timing Advance (TA) , a temporary cell radio network temporary identifier (TC-RNTI) or random-access (RA) RNTI for the scheduled entity 404 and a grant of assigned uplink (UL) resources. The PDCCH in msg2 410 may be scrambled with the RA-RNTI, which is a function of the RACH occasion (RO) (e.g., time-frequency resources allocated for RACH msg1) that the scheduled entity 404 used to send msg1 408. A medium access control -control element (MAC-CE) within the PDSCH provides an acknowledgement of the reception of msg1 408 and the UL grant. To receive msg2 410, the scheduled entity 404 may monitor DCI 1_0 for the PDCCH scrambled with the RA-RNTI corresponding to the RO used by the scheduled entity 404 to transmit msg1 408, and if detected, proceeds with PDSCH decoding. Upon receipt of the RAR message 410, the scheduled entity 404 compares the preamble ID to the preamble sent by the scheduled entity in the RACH preamble message 408. If the preamble ID matches the preamble sent in the RACH preamble message 408, the scheduled entity 404 applies the timing advance and starts a contention resolution procedure.

Since the preamble may be selected randomly by the scheduled entity, if another scheduled entity selects the same preamble in the same RO, a collision may result between the two scheduled entities. Any collisions may then be resolved using a contention resolution procedure. During contention resolution, the scheduled entity 404 transmits an uplink message (msg3) 412 such as a PUSCH on the common control channel (CCCH) using the TA and assigned uplink resources in the PDSCH of msg2 410. In an example, the uplink message 412 is a Layer 2/Layer 3 (L2/L3) message, such as a Radio Resource Control (RRC) Connection Request message. The uplink message 412 includes an identifier of the scheduled entity 404 (scheduled entity-ID) for use by the scheduling entity in resolving any collisions. Although other scheduled entities may transmit colliding uplink messages utilizing the TA and assigned uplink resources, these colliding uplink messages will likely not be successfully decoded at the scheduling entity since the colliding uplink messages were transmitted with TAs that were not intended for those scheduled entities.

Upon successfully decoding the uplink message, the scheduling entity 402 transmits a contention resolution message 414 (msg4) to the scheduled entity 404. The contention resolution message 414 may be, for example, an RRC-Connection Setup message. In addition, the contention resolution message 414 includes the identifier of the scheduled entity 404 that was received in the uplink message 412. The scheduled entity 404, upon receiving its own identity back in the contention resolution message 414, concludes that the random-access procedure was successful and completes the RRC connection setup process. Any other scheduled entity receiving the RRC-Connection Setup message with the identity of the scheduled entity 404 will conclude that the random-access procedure failed and re-initialize the random-access procedure. As mentioned above msg4 414 may have a PDCCH control component and a PDSCH payload component.

With the contention resolved, data may be communicated between the scheduled entity 404 and the scheduling entity 402 with the exchange of payloads in PUSCH and PDSCH messages. The scheduled entity may then transmit HARQ feedback (e.g., ACK/NACK) for the PDSCH payloads within, for example, PUCCH message 416.

FIG. 5 is a diagram illustrating an example two-step RACH procedure according to some aspects, where the four-step procedure 600 can be compressed into the two-step random-access procedure 500 illustrated in FIG. 5. The two-step random-access procedure 500 reduces overhead and latency associated with control signaling by removing a transmission in each direction between the scheduled entity 704 and the scheduling entity 502 (e.g., gNB) . In comparison to FIG. 6, the two-step random-access procedure 500 uses the same SSB, RS and RACH configuration messages 506 as in the four-step RA procedure described above. The 2 steps commence with a transmission by the scheduling entity 504 of a msgA 508 that includes the RACH preamble message and the uplink message of the contention-based random-access procedure shown in 600. Here, the uplink message may be a scheduled PUSCH transmission sent over a PUSCH resource and the RACH preamble message may be sent over a selected PRACH resource. The scheduling entity 502 responds with a single message (msgB 510) that includes the random-access response and the contention resolution message, similar to msg4 of the four-step procedure discussed above. This message includes the PDCCH and PDSCH. The scheduled entity 504 responds 512 to msgB with HARQ ACK/NACK in a PUCCH message.

FIG. 6 is a block diagram illustrating an example 600 of a random-access (RA) preamble that may be used in a two-step RACH procedure according to some aspects. Here, the RA preamble 602 is illustrated as msgA, which may be a similar to msgA (508) described above in connection with FIG. 5. In this example, the RA preamble 602 includes a msgA preamble 604, which includes PRACH 612 and a guard time slot 614. The msgA preamble is followed by the msgA payload 606, which includes DMRS/PUSCH 618 and guard period 620, having a configured time period T _GP 610. The RA preamble 602 may include TxG slot 616 between the msgA preamble 604 and msgA payload for transmitter antenna gain information over a configured time gap T _gap 608.

FIG. 7 is a diagram illustrating signaling 700 between a scheduled entity 704 and scheduling entity 702 during a RACH procedure when a RA payload (msgA) is decoded according to some aspects. The example of FIG. 7 is similar to two-step RACH procedure described above in connection with FIG. 5, in that the scheduled entity 704 receives the same SSB, RS and RACH configuration messages in 706. The scheduled entity 704 may then select a preamble from an available set of preambles within the cell served by the scheduling entity 702 as indicated in the RACH configuration, and transmit the selected preamble to the scheduling entity 702 in msgA that includes a PRACH preamble 708 and PUSCH payload transmission 710. The msgA PRACH preambles may be separate from the four-step RACH preambles, but can be transmitted in the same PRACH Occasions (ROs) as the preambles of four-step RACH, or in separate ROs. The PUSCH payload transmissions 710 may be configured into PUSCH Occasions (POs) that span multiple symbols and PRBs with optional guard periods and guard bands between consecutive POs.

In block 712, the scheduling entity 702 may decode the msgA payload and transmit a random-access response (RAR)

msgB

714, 716 that may include the detected preamble ID, a time-advance command, a temporary radio network temporary identifier C-RNTI (or msgB-RNTI) , and an uplink grant for scheduling a PUSCH, as well as a successRAR over PDSCH (716) to the UE with the contention resolution ID of msgA. In block 718, the scheduled entity 704 decodes successRAR and transmits to the scheduling entity 702 acknowledgement HARQ ACK 720 via PUCCH for msgB after contention resolution, establishing successful completion of RA procedure in 722.

FIG. 8 is a diagram illustrating signaling 800 between a scheduled entity 804 and scheduling entity 802 during a RACH procedure when only a RA preamble is decoded according to some aspects. The diagram 800 is similar to diagram 900 of FIG. 9 in that the scheduled entity 804 receives SSB, RS and RACH configuration messages in 806. The scheduled entity 804 may select a preamble from an available set of preambles within the cell served by the scheduling entity 802 as indicated in the RACH configuration, and transmit the selected preamble to the scheduling entity 802 in msgA that includes a PRACH preamble 808 and PUSCH payload transmission 810.

In block 812, the scheduling entity may detect the msgA preamble only (i.e., not the PUSCH payload) , resulting in the scheduling entity 802 transmitting msgB-RNTI over PDCCH 814 and a fallbackRAR in 816 via msgB PDSCH to the scheduled entity 804 and may also include the RAPID (random-access preamble ID) and an uplink grant for the MsgA PUSCH retransmission. In block 818, the scheduled entity decodes the fallbackRAR and falls back to four-step RACH with a transmission of msg3 (retransmission of the MsgA PUSCH) in 820. In block 822, the scheduling entity 802 decodes the msg3 and transmits in 824 a msg4 temporary C-RNTI (TC-RNTI) over a PDCCH resource and a msg4 contention resolution (CR) over a PDSCH resource in 826. In block 828, the scheduled entity 804 decodes the CR and transmits back an acknowledgement HARQ ACK 830 over a PUCCH resource, resulting in a successful completion of RA in 832.

In some examples, scheduled entities (e.g., UE) may be functioning in an operating environment that supports reduced-capability NR devices (also known as “NR Light” ) . NR light devices may be configured with lower device complexity and reduced energy consumption compared what can be provided by traditional NR devices and which, at the same time, have higher requirements in terms of data rates and latency compared to what can be provided with, for example, LTE machine-type communication (MTC) and narrowband internet of things (NB-IoT) . In terms of reduced device complexity, NR light devices may be configured with support for reduced number of TX/RX antennas at the device side, reduction of the minimum required device bandwidth and/or support for devices only capable of half-duplex operation (no simultaneous TX/RX) in paired spectrum. In terms of reduced device energy consumption, NR Light devices may be configured with reduced complexity in PDCCH monitoring by reducing the number of required blind decoding, as well as extended discontinuous reception (DRX) functionality. One having ordinary skill in the art will appreciate that the examples in the present disclosure are suited for applications utilizing NR Light, although they may be equally applied in traditional NR configurations as well.

Processes for UL small data transmissions (SDT) for RACH-based configurations are similar to those described above (e.g., two-step, four-step RACH) , except that the scheduled entity may execute a RACH process from an inactive state (e.g., RRC_INACTIVE) . In small data transmission during two-step RACH, the scheduled entity may select a configured preamble for mobile originating (MO) transmission. Since small data communications may be configured with data limitations, small data may transmit msgA, together with an RRC message, if the UL grant for msgA provided by the scheduling entity (e.g., gNB) is sufficiently large enough. This may be contrasted with legacy two-step RACH, where typically only a RRC message is transmitted in the msgA payload. Also, for small data communication, DL data for an ACK transmission in response to the UL small data may be scheduled in msgB together with the RRC message.

FIG. 9 is a diagram 900 illustrating a two-step RACH msgA retransmission configuration according to some aspects. As mentioned above, msgA 902 of a 2-step random-access procedure includes a preamble 904 on PRACH and a payload 906 on PUSCH (see FIG. 5) . After msgA is transmitted, the scheduled entity (UE) 920 monitors for a response (msgB) from the network within a configured RAR window 914 (msgB-ResponseWindow) having a start time 908 and end time 910 as shown in the figure. If the scheduling entity (gNB) 930 cannot decode the preamble 904 and payload 906 of msgA, and the scheduled entity 920 does not receive any response within the configured RAR time window 914, the scheduled entity 902 executes msgA 902 retransmission, that may include a back-off 912 and MAC processing latency. If the two-step RACH procedure is not completed after a configured number of msgA transmissions (e.g., msgA-TransMax) , the scheduled entity 1020 may be configured to switch to a contention-based random-access (CBRA) procedure such as a four-step RA, and begin transmission of, for example, msg1 of the CBRA.

FIG. 10 is a diagram 1000 illustrating a RACH fallback procedure according to some aspects. The example of FIG. 10 is similar to the example in FIG. 9 in that the scheduled entity (UE) 1020 transmits msgA 1002 of a 2-step random-access procedure, including a preamble 904 on PRACH and a payload 906 on PUSCH (see FIG. 5) . After msgA is transmitted, the scheduled entity (UE) 920 monitors for a response (msgB) , from the start 1008 of the msgB RAR time window 1014. At time period 1022, the scheduling entity (gNB) 1030 decodes only the preamble, but fails on the payload of msgA (see FIG. 8) . At this point, the scheduling entity 1030 may transmit a fallback message 1018 of msgB 1060 on PDSCH that includes fallbackRAR 1022 to instruct the scheduled entity 1020 to retransmit the msgA payload 1012 (similar to msg3 of four-step RACH) , subject to UL timing adjustments based on timing advance command (TAC) , and further monitor for contention resolution (similar to msg4 of four-step RACH) . In some examples, discussed in greater detail below, a small data fallback bit 1024 may be provided to transition a scheduled entity from an inactive RA process to a connected RA process. If contention resolution is still not successful after the end 1010 of msgB RAR time window 1010, the scheduled entity may revert to a new msgA transmission (e.g., preamble and payload, see FIG. 9) as part of a new RA procedure.

When RA procedures are utilized for small data communications, it may be inefficient to configure the maximum number of small data retransmissions the same as the maximum retransmissions configured for a legacy RA procedure (e.g., msgA-TransMax) . Due to the nature of small data communications, it may be difficult to decode RA procedure data, even after a number of msgA (re) transmissions occur in the contention-based uplink channel (PUSCH) during 2-step RACH, since the size of user data could be larger than the RRC message transmitted in the legacy RACH procedure. In some cases, the retransmitted msgA payload with user data in PUSCH may cause interference to other small data or legacy two-step RACH devices. Alternately or in addition, a scheduled entity may experience large latency during msgA retransmission.

In some examples, a configured timer is disclosed to manage and/or control small data transmission and retransmission delays. A fallback mechanism may also be used to allow the scheduled entity (UE) to fallback from transmitting small data in two-step RACH to a legacy RACH procedure (e.g., conducted during an RRC_CONNECTED state) . In some examples, after a number of small data transmissions and retransmissions in PUSCH of msgA exceed a small data retransmission limit, the scheduled entity may fallback to a legacy RACH procedure if the scheduling entity (gNB) still fails to decode the msgA payload. The scheduling entity may transition the scheduled entity to an RRC_CONNECTED state in order to transmit user data as a conventional RRC setup procedure after a legacy two-step RACH procedure is finished. Alternately or in addition, the scheduling entity may keep the scheduled entity in a RRC_INACTIVE state after legacy RACH is finished, and configure the scheduled entity with a dedicated uplink resource (e.g., configured grant, discussed below) in msgB/msg4, based on a small data request message transmitted in msgA/msg3.

FIG. 11 is a diagram 1100 illustrating an example associated with uplink data transfer over random access or configured uplink resources, according to some aspects. The operations shown in FIG. 11 may be performed by a scheduled entity (e.g., UE 106) . In example 1100, the UE 106 starts in an inactive state, such as an RRC inactive state.

As shown by reference number 1102, the UE 106 may determine that data is to be transmitted on the uplink (referred to as a data transfer (DT) ) . The DT can be associated with any application or source. In some aspects, the DT may be associated with an IoT application, a wearable device application, and/or the like. In some aspects, the DT may be referred to as a small data transmission.

As shown by reference number 1104, the UE 106 may determine whether a timing advance (TA) of the UE 106 is valid. A TA value may identify a timing adjustment for an uplink transmission of the UE 106. The UE 106 may determine a TA value based at least in part on a RACH procedure or MAC messaging subsequent to the RACH procedure. For example, the UE 106 may receive the TA value in a RAR or in a TA MAC CE subsequent to the RACH procedure. The UE 106 may determine whether the TA is valid based at least in part on a timer, location information associated with the UE 106, and/or the like.

As shown by reference number 1104, if the UE 106 determines that the TA value is not valid ( “NO” ) , then the UE 106 may perform a RACH procedure in block 1106. The UE 106 may perform the RACH procedure to update a TA value associated with the UE 106 so that the UE 106 can successfully transmit the DT.

As shown by reference number 1108, the UE 106 may determine whether the DT satisfies a TBS threshold (also referred to herein as a size threshold) . The TBS threshold may indicate whether the DT is sufficiently small to be transmitted on a RACH message, such as msg3 or msgA. A configured uplink resource (CUR) is described in more detail below. As shown by reference number 1108, if the DT is larger than the TBS threshold ( “NO” ) , then the UE 106 may establish an RRC connection in block 1110 and transmit the DT via the RRC connection in block 1112. For example, the UE 106 may exit an RRC inactive state and may enter an RRC connected state for the transmission of the DT if the DT is larger than the TBS threshold. Example values of the TBS threshold include 328 bits, 504 bits, 680 bits, 936 bits, 1000 bits, 2000 bits, and/or the like.

In some examples, a scheduling entity, such as a BS 108 may configure the TBS threshold for the UE 106. In some aspects, the TBS threshold may include a single threshold. In this case, if the DT satisfies the single threshold (e.g., is larger than the single threshold) , then the UE 106 may not be permitted to transmit the DT in the RACH message or the CUR. If the DT fails to satisfy the single threshold (e.g., is smaller than or equal to the single threshold) , then the UE 106 may be permitted to transmit the DT in the RACH message or the CUR. In some aspects, the TBS threshold may include multiple thresholds. For example, the BS 108 may configure the UE 106 with the multiple thresholds. In this case, the BS 108 may transmit an RRC parameter to enable or disable whether an alternative TBS can be selected for the UE 106 when a size of the DT is smaller than the TBS threshold (e.g., to enable or disable whether the UE 106 can transmit the DT on the RACH message) . The TBS threshold may comprise a set of TBS values that indicate a set of thresholds for transmitting the DT on the RACH message. The BS 108 may activate one or more thresholds, of the set of thresholds, for the UE 106. Thus, the UE 106 can be configured to use different thresholds in different scenarios. References herein to “a TBS threshold” should be understood to encompass “a set of TBS thresholds” or “multiple TBS thresholds. ”

In some aspects, the TBS threshold may be signaled in a SIB. For example, the TBS threshold may be broadcasted to all UEs covered by a BS 108. Thus, all of the UEs covered by the BS 108 may be configured with a same TBS threshold. In this case, the BS 108 may provide the TBS threshold in a RACH-ConfigCommon parameter, a RACH-ConfigCommonTwoStepRA-r16 parameter, and/or the like. In some aspects, the BS 108 may signal the TBS threshold in dedicated RRC signaling. For example, the BS 108 may transmit an RRC release message (e.g., with a suspendConfig parameter to move the UE 106 to an RRC inactive state) including the TBS threshold configuration. In some aspects, the TBS threshold can be provided in a RACH-ConfigDedicated parameter.

As shown by reference number 1108, if the DT is smaller than or equal to the TBS threshold ( “YES” ) , then the UE 106 may determine whether the DT can be transmitted in a RACH message. For example, the UE 106 may determine whether the DT satisfies an uplink grant threshold indicating whether the UE 106 is permitted to transmit the DT in a RACH message. This uplink grant threshold may include a TBS threshold (e.g., may be configured as part of the TBS threshold) for an uplink grant for a payload of the RACH message. As shown by reference number 1114, if the DT can be transmitted in a RACH message ( “YES” ) , then the UE 106 may transmit the DT in a RACH message in block 1116, such as msgA or msg3. For example, the UE 106 may transmit the DT without entering an RRC connected mode or an RRC active mode, thereby conserving UE and network resources associated with entering the RRC connected mode or the RRC active mode.

As shown by reference number 1114, if the DT cannot be transmitted in a RACH message ( “NO” ) , indicating that the UE 106 is not permitted to transmit the DT in a RACH message, then the UE 106 may transmit a CUR request. In this example, the CUR request is transmitted in a RACH message, though in other examples described herein, the CUR request may be transmitted in another type of message. A CUR may refer to a configured uplink resource, a preconfigured uplink resource, a dedicated uplink resource, a dedicated preconfigured uplink resource (D-PUR) , and/or the like. A CUR may be a resource on which the UE 106 can perform an uplink transmission without entering an RRC connected mode or an RRC active mode. In some aspects, a CUR may have a TBS sufficient to transmit the DT in a single transport block, which is referred to as a one-shot CUR. In some aspects, a CUR may comprise multiple resources that are distributed in the time domain, so that the UE 106 can transmit data after transmitting the DT, or can transmit the DT on the multiple resources.

In some aspects, the UE 106 may transmit the CUR request based at least in part on the DT being smaller than or equal to the TBS threshold (indicating that the UE 106 can transmit the DT without establishing an RRC connection) and being too large to transmit on an RRC message. In some aspects, the UE 106 may transmit the CUR request based at least in part on determining that the UE 106 is to perform a subsequent transmission. For example, the UE 106 may transmit the CUR request based at least in part on determining that the UE 106 is associated with potential periodic data for a subsequent transmission.

In some aspects, the UE 106 may transmit the CUR request in a MAC CE. For example, the MAC CE may be a buffer status report (BSR) MAC CE, such as a short BSR with a byte indicating that the short BSR is a CUR request. As another example, the MAC CE may be specific to the CUR request. For example, the MAC CE may include a BSR (e.g., information indicating a logical channel identifier and a data amount associated with the logical channel identifier) , information indicating a traffic pattern associated with the DT (e.g., a single transmission traffic pattern, a periodic transmission traffic pattern) , a predicted amount of traffic associated with the DT, and/or the like. In some aspects, the UE 106 may transmit the CUR request in an RRC message, such as an RRC resume request message. In this case, an RRC parameter of the RRC message (e.g., an RRCResumeRequest parameter and/or the like) may indicate an amount of data of the DT and/or a traffic pattern associated with the DT. In some aspects, the UE 106 may transmit the CUR request in a RACH message, such as msgA or msg3. In this case, the CUR request may include a resume identifier, an authentication token (e.g., a shortResumeMac-I or a resume MAC-I) , and/or the like.

As shown by reference number 1120, the UE 106 may transmit the DT in a CUR. For example, the BS 108 may configure the UE 106 with the CUR based at least in part on the CUR request. In some aspects, the BS 108 may provide configuration information configuring the CUR via a RACH message, such as msgB or msg4. In some aspects, the BS 108 may provide the configuration information via an RRC message, such as an RRC release message or an RRC message associated with responding to the CUR request. The CUR can be a one-shot CUR or a multi-shot (e.g., configured grant, periodic, semi-persistent, and/or the like) CUR. In some aspects, the multi-shot CUR may recur until the multi-shot CUR is deactivated or reconfigured. In other words, the multi-shot CUR may have an infinite configuration in the time domain. In some aspects, the CUR may be based at least in part on the CUR request. In some aspects, the CUR may be based at least in part on subscription information associated with the UE 106 (e.g., indicating a set of services applicable to the UE 106) , network traffic information (e.g., network traffic statistics) associated with the UE 106 (e.g., associated with a UE context of the UE 106 or a traffic history of the UE 106) , and/or the like.

As shown by reference number 1122, if the TA value of the UE 106 is valid ( “YES” ) , then the UE 106 may determine whether a CUR is configured for the UE (shown as (1) ) and whether the CUR is associated with a size (e.g., a TBS) sufficient to transmit the DT (shown as (2) ) . For example, in some aspects, the CUR may be configured independently of the RACH procedure. For example, the configuration of the CUR may not involve the RACH procedure. In this case, the BS 108 may configure the CUR via RRC dedicated signaling, such as when the UE 106 is in an RRC connected state or when the UE 106 is in an RRC inactive state.

As shown by reference number 1124, if the UE 106 determines that the CUR is configured and is associated with a size sufficient to transmit the DT (block 112 - (1) “YES” and (2) “YES” ) , then the UE 106 may transmit the DT on the CUR without performing a RACH procedure. For example, since the UE 106 has a valid TA, the UE 106 can transmit the DT without updating the TA via the RACH procedure. Thus, the UE 106 may conserve communication resources that would otherwise have been used to perform the RACH procedure.

As shown by reference number 560, if the UE 106 determines that the CUR is not configured (block 550 – (1) “NO” and (2) “NO” ) , then the UE 106 may return to block 515. The UE 106 may then perform the operations described with regard to blocks 520, 525, 530, 535, 540, and 545. Thus, if no CUR is configured, the UE 106 may selectively transmit the DT in a RACH message, a CUR (based at least in part on requesting the CUR) , or via an RRC connection, depending on the size of the DT.

As shown by reference number 1128, if the UE 106 determines that the CUR is configured and is not of sufficient size to carry the DT (block 550 – (1) “YES” and (2) “NO” ) , then the UE 106 may use the CUR to transmit a CUR request. For example, the CUR request may request a CUR of sufficient size to carry the DT (e.g., as a one-shot CUR or a multi-shot CUR) . As shown by reference number 1130, the UE 106 may receive configuration information configuring the CUR. The configuration information may include at least part of the configuration information described with regard to reference number 1120, and the CUR request is described in more detail in connection with reference number 1118. As shown, the UE 106 may go to block 1120 after receiving the configuration information. For example, the UE 106 may transmit the DT on the CUR configured by the configuration information shown by reference number 1130.

As indicated above, Fig. 11 is provided as an example. Other examples may differ from what is described with regard to Fig. 11.

FIG. 12 is a flow diagram 1200 illustrating small data RACH fallback using a retransmission limit and/or a retransmission timing limit, according to some aspects. This example illustrates an operating environment for providing a parameter to a scheduled entity (UE) defining a maximum small data retransmission limit (e.g., msgA-SdtTransMax) for the number of msgA retransmissions during an RA procedure (e.g., two-step-RACH) . In some examples, the small data retransmission limit (msgA-SdtTransMax) should be smaller than a retransmission limit (e.g., msgA-TransMax) configured for an RA procedure. In some examples, a small data retransmission time limit (e.g., msgA-SdtTransTimer) may also be configured to limit the time period in which small data msgA messages will be retransmitted. The small data retransmission limit and/or small data retransmission time limit may be transmitted to the scheduled entity via system information during an RRC_IDLE or RRC_INACTIVE state. Alternately or in addition, the small data retransmission limit may be transmitted to the scheduled entity via RRC dedicated signaling during an RRC_CONNECTED state.

In block 1202, the scheduled entity may determine if it satisfies one or more configured transmission size thresholds for small data communication (e.g., TBS threshold; see FIG. 11) , and, if the threshold is met, transmit msgA that includes small data. In some examples, msgA may transmitted in block 1202 while the scheduled entity is in a RRC_INACTIVE state. In decision block 1204, the scheduled entity may determine if contention resolution and user data decoding (e.g., msgA preamble and payload) is successful. If successful ( “YES” ) , the process ends in block 1206, then the RACH procedure is completed and small data is transmitted successfully. If the contention resolution is not successful ( “NO” ) , the process moves to decision block 1208, where the UE determines if a response was received from the scheduling entity within a configured time window (e.g., 914, 1014) . If a response is received ( “YES” ) , the process moves to block 1210 where the scheduled entity performs the remainder of the RACH procedure based on the response.

If a response is not received ( “NO” ) in block 1208, the process 1200 moves to decision block 1212, where the scheduled entity determines if a configured maximum small data retransmission time limit (e.g., msgA-SdtTransTimer) has expired. If the timer is expired ( “YES” ) the process moves to block 1214 and the scheduled entity switches to legacy two-step RACH procedure as described above in connection with FIG. 5, as well as elsewhere in the present disclosure. If the configured time limit has not expired ( “NO” ) , the process moves to decision block 1216 to determine if the small data retransmission limit (e.g., msgA-StdTransMax) is configured and expired. If the small data retransmission limit is expired ( “YES” ) the process moves to block 1214, where the scheduled entity switches to legacy two-step RACH procedure state as described above in connection with FIG. 5, as well as elsewhere in the present disclosure. If the small data retransmission limit is not expired ( “NO” ) , the scheduled entity retransmits msgA (see FIG. 9) in block 1218 and reverts back to decision block 1204 to repeat the process.

The msgA that includes the small data of process 1200 may be retransmitted if the scheduling entity (e.g., gNB) cannot decode any of the preamble and/or payload, and, as a result, cannot transmit a response (e.g., msgB) back to the scheduled entity within the configured time window (e.g., msgB RAR window 914, 1014) . If the small data retransmission limit and time limit have both expired, the scheduled entity may switch to a legacy two-step RACH procedure to transmit RRC messaging only in msgA payload. Alternately or in addition, the scheduled entity may also include a small data request message in the form of a CUR (see FIG. 11) in the msgA payload. In some examples, if the two-step RACH procedure is still unsuccessful, the scheduled entity may switch to a four-step RACH as described above in connection with FIG. 4 and elsewhere in this disclosure.

With regard to the small data retransmission time limit (e.g., msgA-SdtTransTimer) , the timer may be configured to start when msgA is transmitted for the first time, and may stop when the contention resolution is successful and the user data is decoded successfully. In some examples, if the small data retransmission limit (e.g., msgA-SdtTransMax) or legacy retransmission limit (e.g., msgA-TransMax) is reached before the small data retransmission time limit (e.g., msgA-SdtTransTimer) is expired during msgA retransmission, the small data retransmission time limit may be canceled. In some examples, if the small data retransmission time limit (e.g., msgA-SdtTransTimer) expires before the small data retransmission time limit (e.g., msgA-SdtTransTimer) or legacy retransmission limit (e.g., msgA-TransMax) , the scheduled entity may switch to a legacy two-step RACH procedure to transmit RRC messaging only in msgA payload. Alternately or in addition, the scheduled entity may also include a small data request message in the form of a CUR (see FIG. 11) in the msgA payload. In this example, the scheduling entity (e.g., gNB) may indicated to the scheduled entity (UE) to engage in a fallback procedure to switch the scheduled entity from transmitting small data to legacy two-step RACH.

FIG. 13 is a flow diagram 1300 illustrating small data RACH fallback using a fallback bit in a random-access response (RAR) , according to some aspects. As discussed above, for legacy two-step RACH procedure, the scheduled entity may perform msgA retransmission if the scheduling entity cannot decode any of the preamble and/or payload of msgA, and the scheduled entity does not receive any response within a configured time window (e.g., msgB-ResponseWindow) . Furthermore, the scheduled entity may also perform msgA retransmission if contention resolution is not successful after msg3 (re) transmissions. For small data transmission during 2-step RACH, the scheduling entity may set a fallback-to-legacy bit (F-bit, discussed in FIG. 13 below) in the fallbackRAR. The scheduling entity may replace the “R” bit in the MAC subheader with an “F” bit to indicate to the scheduled entity to instruct the scheduled entity to fallback from small data transmission to legacy two-step RACH. When the scheduled entity received the F bit, the scheduled entity may stop the timer/counter for msgA-SdtTransMax and msgA-SdtTransTimer, discussed above.

As can be seen in FIG. 13, the scheduled entity may transmit msgA as part of a small data RACH procedure in block 1302. In decision block 1304, the scheduled entity may determine if the fallbackRAR is received with the fallback-to-legacy bit (F) being set. If the fallbackRAR is received and the fallback-to-legacy bit is not set ( “NO” ) , the process 1300 moves to block 1306, where the UE may check other conditions for msgA retransmission (e.g., 1200) . If the fallbackRAR is received and the fallback-to-legacy bit is set ( “YES” ) , the process 1300 moves to block 1308, where the scheduled entity performs msgA payload retransmission.

In decision block 1310, the scheduled entity then determines if contention resolution and user data decoding is successful. If not ( “NO” ) , the process moves to block 1312 and the scheduled entity may switch to a legacy two-step RACH procedure to transmit RRC messaging only in msgA payload. Alternately or in addition, the scheduled entity may also include a small data request message in the form of a CUR (see FIG. 11) in the msgA payload. If the contention resolution and user data decoding is successful ( “YES” ) , the process ends as shown in the figure.

FIG. 14 is a diagram illustrating a media access control (MAC) RAR message or a fallbackRAR message1400 for small data communications that includes a fallback bit 1402 according to some aspects. The MAC RAR or a fallbackRAR may be configured with a fixed size (7 octets) , and may include a timing advance command (TAC) field 1404, an UL grant field 1406 and a temporary C-RNTI field 1408. The TAC 1404 may be configured, for example as a 12-bit field, and indicates the index value TA used to control the amount of uplink transmission timing. The index values of TA range may be, for example, 0, 1, 2, ..., 3846. The UL grant field 1406 may be configured, for example, as a 27-bit field and indicate the resources to be used on the subsequent uplink UL-SCH transmission. The temporary C-RNTI field may be, for example, a 16-bit field and indicate the temporary identity that is used by the MAC entity during a Random-Access procedure. It can take values, for example, between 0001 and FFEF. It may be used for Msg3 transmission in the uplink and for the purpose of Contention Resolution in the downlink (when no valid C-RNTI is available with the scheduled entity) .

Small data transmission during four-step RACH operates similarly to two-step RACH, described above. In some examples, the small data may be transmitted, for example, in msg3, provided the scheduled entity satisfies transmission size thresholds for small data communication (e.g., TBS threshold; see FIG. 11) . A parameter may be provided by the scheduling entity defining a small data retransmission limit (e.g., preambleStdTransMax) for a number of preambles (e.g., msg1) that may be transmitted during four-step RACH. In some examples, the small data retransmission limit is configured to be smaller than that for legacy four-step RACH (e.g., preambleTransMax) . In some examples, if the number of preamble (msg1) retransmissions reach or exceed the retransmission limit (e.g., preambleStdTransMax) , the scheduled entity may fallback to legacy four-step RACH, without transmitting small data in msg3.

Alternately or in addition, a small data retransmission time limit (e.g., msgA-SdtTransTimer) may be used, similar to the small data two-step RACH examples described above, where, if the contention resolution is not successful at the end of the time limit, the scheduled entity may fallback to legacy four-step RACH, without transmitting small data in msg3. In some examples, the scheduling entity (gNB) may provide a fallback-to-legacy four-step RACH (e.g., F bit, see 1024, 1402) , similar to the examples provided above, where the fallback-to-legacy bit may be contained in the msg2 (RA response) , where, once it is detected by the scheduled entity, it engages in fallback to legacy four-step RACH without transmitting small data in msg3.

In some examples, if a small data RACH retransmission limit (e.g., msgA-SdtTransMax, msgA-SdtTransTimer, F-bit, etc. ) is not configured for small data transmission during two-step RACH, a legacy switching mechanism may be applied (e.g., two-step to four-step RACH) . If the small data in two-step RACH is not completed after a configured number of msgA transmissions (e.g., msgA-TransMax) , the scheduled entity (UE) may switch to perform small data transmission in four-step RACH as described herein.

It should be understood that the technologies and techniques described herein may be applied to other systems and platforms as well. For example, the RACH procedures described above may similarly be applied to unlicensed NR platforms (NR-U) , where the gNB and UE may apply listen-before-talk (LBT) before engaging in a transmission on a cell configured with shared spectrum channel access. When utilizing LBT in an unlicensed network, a UE may detect the energy level on multiple sub-bands of a communications channel to determine if the energy is below a configured threshold in order to determine if the channel is free or busy. Energy levels detected to be under the configured threshold would indicate the channel is free, which in turn allows the UE to transmit. When lower layers of the UE perform an LBT procedure before transmission and the transmission fails, an LBT failure indication is transmitted to the MAC entity from the lower layers. During a small data RACH procedure, if the LBT fails for data transmission after a configured number of times, the UE may fallback to a legacy two-step RACH procedure for an RRC resume request (e.g., RRCResumeRequest) .

FIG. 15 is a conceptual diagram illustrating an example of a hardware implementation for an exemplary wireless communication device employing a processing system 1614. For example, the wireless communication device 1500 may be a UE or other scheduled entity as illustrated in any one or more of FIGs. 1-2, 4-5, and/or 7-10.

The wireless communication device 1500 may be implemented with a processing system 1514 that includes one or more processors 1504. Examples of processors 1504 include microprocessors, microcontrollers, digital signal processors (DSPs) , field programmable gate arrays (FPGAs) , programmable logic devices (PLDs) , state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. In various examples, the wireless communication device 1500 may be configured to perform any one or more of the functions described herein. That is, the processor 1504, as utilized in a wireless communication device 1500, may be used to implement any one or more of the processes described herein.

The processor 1504 may in some instances be implemented via a baseband or modem chip and in other implementations, the processor 1504 may itself comprise a number of devices distinct and different from a baseband or modem chip (e.g., in such scenarios is may work in concert to achieve embodiments discussed herein) . And as mentioned above, various hardware arrangements and components outside of a baseband modem processor can be used in implementations, including RF-chains, power amplifiers, modulators, buffers, interleavers, adders/summers, etc.

In this example, the processing system 1514 may be implemented with a bus architecture, represented generally by the bus 1502. The bus 1502 may include any number of interconnecting buses and bridges depending on the specific application of the processing system 1514 and the overall design constraints. The bus 1502 communicatively couples together various circuits including one or more processors (represented generally by the processor 1504) , a memory 1505, and computer-readable media (represented generally by the computer-readable medium 1506) . The bus 1502 may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further. A bus interface 1508 provides an interface between the bus 1502 and a transceiver 1510. The transceiver 1510 provides a means for communicating with various other apparatus over a transmission medium (e.g., air interface) . A user interface 1512 (e.g., keypad, display, speaker, microphone, joystick) may also be provided.

The processor 1504 is responsible for managing the bus 1502 and general processing, including the execution of software stored on the computer-readable medium 1506. The software, when executed by the processor 1504, causes the processing system 1514 to perform the various functions described below for any particular apparatus, and also serve as means for performing the various functions described herein. The computer-readable medium 1506 and the memory 1505 may also be used for storing data that is manipulated by the processor 1504 when executing software.

One or more processors 1504 in the processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The software may reside on a computer-readable medium 1506.

The computer-readable medium 1506 may be a non-transitory computer-readable medium. A non-transitory computer-readable medium includes, by way of example, a magnetic storage device (e.g., hard disk, floppy disk, magnetic strip) , an optical disk (e.g., a compact disc (CD) or a digital versatile disc (DVD) ) , a smart card, a flash memory device (e.g., a card, a stick, or a key drive) , a random access memory (RAM) , a read only memory (ROM) , a programmable ROM (PROM) , an erasable PROM (EPROM) , an electrically erasable PROM (EEPROM) , a register, a removable disk, and any other suitable medium for storing software and/or instructions that may be accessed and read by a computer. The computer-readable medium 1506 may reside in the processing system 1514, external to the processing system 1514, or distributed across multiple entities including the processing system 1514. The computer-readable medium 1506 may be embodied in a computer program product. In some examples, the computer-readable medium 1506 may be part of the memory 1505. By way of example, a computer program product may include a computer-readable medium in packaging materials. Those skilled in the art will recognize how best to implement the described functionality presented throughout this disclosure depending on the particular application and the overall design constraints imposed on the overall system.

In some aspects of the disclosure, the processor 1504 may include circuitry configured for various functions. For example, the processor 1504 may include communication and processing circuitry 1542, configured to communicate with a RAN node (e.g., a base station, such as a gNB) . In some examples, the communication and processing circuitry 1542 may include one or more hardware components that provide the physical structure and means that performs processes related to wireless communication (e.g., signal reception and/or signal transmission) and signal processing (e.g., processing a received signal and/or processing a signal for transmission) . The communication and processing circuitry 1542 may be configured to receive a paging message from the RAN node. The communication and processing circuitry 1542 may further be configured to execute communication and processing software 1552 stored in the computer-readable medium 1506 to implement one or more of the functions described herein.

In some examples, the processor 1504 may include small data RACH processing circuitry 1544 that may be configured to process small data RACH transmission and retransmission to a scheduling entity as described above based on configuration parameters and/or communication and/or network conditions determined in the communication and processing circuitry 1542. The small data RACH processing circuitry 1544 may further process and manage small data retransmission limits and small data time retransmission limits for small data fallback operations. The small data RACH processing circuitry 1544 may further process fallback bits (e.g., “F” ) for small data fallback operations. The small data RACH processing circuitry may further be configured to small data RACH processing software 1554 stored in the computer-readable medium 1506 as a means for implement one or more of the functions described herein.

FIG. 16 is a conceptual diagram illustrating an example of a hardware implementation a scheduling entity 1600 employing a processing system 1614. In some implementations, the scheduling entity 1600 may correspond to any of the base stations (e.g., gNBs, ) or scheduling entities shown in FIGs. 1-2, 4-5, and/or 7-10.

In accordance with various aspects of the disclosure, an element, or any portion of an element, or any combination of elements may be implemented with the processing system 1614. The processing system may include one or more processors 1604. The processing system 1614 may be substantially the same as the processing system 1514 illustrated in FIG. 15, including a bus interface 1608, a bus 1602, memory 1605, a processor 1604, and a computer-readable medium 1606. Furthermore, the scheduling entity 1600 may include an interface (e.g., a network interface) that provides a means for communicating with at least one other apparatus within a core network and with at least one radio access network.

The scheduling entity 1600 may be configured to perform any one or more of the operations described herein. In some aspects of the disclosure, the processor 1604, as utilized in the scheduling entity 1600, may include circuitry configured for various functions.

The processor 1604 may be configured to generate, schedule, and modify a resource assignment or grant of time-frequency resources (e.g., a set of one or more resource elements) . For example, the processor 1604 may schedule time–frequency resources within a plurality of time division duplex (TDD) and/or frequency division duplex (FDD) subframes, slots, and/or mini-slots to carry user data traffic and/or control information to and/or from multiple UEs. The processor 1604 may further be configured to schedule resources that may be utilized by the UE to transmit uplink control and/or uplink data. For example, the resources may include resources scheduled for transmission of a PUCCH, PUSCH, PRACH occasion or RRC message.

In some aspects of the disclosure, the processor 1604 may include communication and processing circuitry 1642. The communication and processing circuitry 1642 may be configured to communicate with a scheduled entity (e.g., 1500) including communicating lean SSB signals described herein. The communication and processing circuitry 1642 may include one or more hardware components that provide the physical structure that performs various processes related to communication (e.g., signal reception and/or signal transmission) as described herein. The communication and processing circuitry 1642 may further include one or more hardware components that provide the physical structure that performs various processes related to signal processing (e.g., processing a received signal and/or processing a signal for transmission) as described herein. The communication and processing circuitry 1642 may further be configured to execute communication and processing software 1652 included on the computer-readable medium 1606 to implement one or more functions described herein.

The communication and processing circuitry 1642 may be configured to receive a request from the scheduled entity. For example, the request may be included in a MAC-CE carried in a PUSCH, UCI in a PUCCH or PUSCH, a random-access message, or an RRC message. The communication and processing circuitry 1642 may further be configured to receive a scheduling request (e.g., via UCI in a PUCCH) from the scheduled entity for an uplink grant for the PUSCH carrying the MAC-CE. The communication and processing circuitry 1642 may further be configured to receive an uplink signal. The uplink signal may include, for example, a PUCCH, PUSCH, SRS, DMRS, or PRACH.

In some implementations where the communication involves sending (e.g., transmitting) information, the communication and processing circuitry 1642 may obtain information (e.g., from another component of the processor 1604, the memory 1605, or the bus interface 1608) , process (e.g., encode) the information, and output the processed information. For example, the communication and processing circuitry 1642 may output the information to the transceiver 1610 (e.g., that transmits the information via radio frequency signaling or some other type of signaling suitable for the applicable communication medium) . In some examples, the communication and processing circuitry 1642 may send one or more of signals, messages, other information, or any combination thereof. In some examples, the communication and processing circuitry 1642 may send information via one or more channels. In some examples, the communication and processing circuitry 1642 may include functionality for a means for sending (e.g., means for transmitting) .

The processor 1604 may include small data RACH processing circuitry 1644 that allows the scheduling entity 1600 to process small data RACH from the scheduled entity and to transmit associated responses. The small data RACH processing circuitry 1644 may further be configured to transmit small data retransmission, small data retransmission time limits, and/or a fallback bit for configuring the scheduled entity to engage in small data fallback as described above. The small data RACH processing circuitry 1644 may further be configured to execute small data RACH processing software 1654 stored in the computer-readable medium 1606 to implement one or more of the functions described herein.

FIG. 17 is a flowchart 1700 of a method for retransmitting small data in accordance with a RACH retransmission limit (msgA-SdtTransMax, preambleSdtTransMax) according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all examples. In some examples, the method 1700 may be performed by the scheduled entity 1500, as described above and illustrated in FIG. 15, by a processor or processing system, or by any suitable means for carrying out the described functions.

In block 1702, the scheduled entity (UE) may receive configuration data comprising a small data random-access channel (RACH) retransmission limit for establishing small data communications with a wireless network. In block 1704, the scheduled entity may transmit a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state. In block 1706, the scheduled entity may retransmit the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission limit has not been reached.

FIG. 18 is a flowchart 1800 of a method for retransmitting small data in accordance with a RACH retransmission time limit (msgA-SdtTransTimer, preambleSdtTransTimer) according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all examples. In some examples, the method 1800 may be performed by the scheduled entity 1500, as described above and illustrated in FIG. 15, by a processor or processing system, or by any suitable means for carrying out the described functions.

In block 1802, the scheduled entity (UE) may receive configuration data comprising a random-access channel (RACH) retransmission time limit for establishing small data communications with a wireless network. In block 1804, the scheduled entity may transmit a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state. In block 1806, the scheduled entity may retransmit the first RACH preamble message if a contention resolution with the network is not successful, and if the preamble retransmission time limit has not been reached.

FIG. 19 is a flowchart 1900 of a method for retransmitting small data in accordance with RACH fallback data (e.g., F bit) according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all examples. In some examples, the method 1900 may be performed by the scheduled entity 1500, as described above and illustrated in FIG. 15, by a processor or processing system, or by any suitable means for carrying out the described functions.

In block 1902, the scheduled entity may receive random-access channel (RACH) configuration data for establishing small data communications with a wireless network. In block 1904, the scheduled entity (UE) may transmit a first RACH message for s mall data communication while the UE is in an inactive state. In block 1906, the scheduled entity may receive fallback data on a random-access response from the transmission of the first RACH message. In block 1908, the scheduled entity may transmit a second RACH message in response to the fallback data if a contention resolution with the network is not successful.

FIG. 20 is a flowchart 2000 of a method for retransmitting small data in an unlicensed wireless network (NR-U) according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all examples. In some examples, the method 2000 may be performed by the scheduled entity 1500, as described above and illustrated in FIG. 15, by a processor or processing system, or by any suitable means for carrying out the described functions.

In block 2002, the scheduled entity (UE) may receive random-access channel (RACH) configuration data for establishing small data communications with the unlicensed wireless network. In block 2004, the scheduled entity (UE) may detect the energy level on multiple sub-bands of a communications channel to determine if the energy is above or below a configured threshold. In block 2006, the scheduled entity (UE) may transmit a first RACH message for small data communication while the UE is in an inactive state. In block 2008, the scheduled entity (UE) may detect one or more failures of transmitting the first RACH message, based on the detected energy level being above the configured threshold. In block 2010, the scheduled entity (UE) may transmit a second RACH message without containing the user small data, based RACH configuration data, and on the detected energy level being below the configured threshold.

FIG. 21 is a flowchart 2100 of a method for a base station to configure a UE to retransmit small data in accordance with a RACH retransmission limit (msgA-SdtTransMax, preambleSdtTransMax) according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all examples. In some examples, the method 2100 may be performed by the scheduling entity 1600, as described above and illustrated in FIG. 16, by a processor or processing system, or by any suitable means for carrying out the described functions.

In block 2102, the BS may transmit configuration data comprising a small data random-access channel (RACH) retransmission limit for a UE to establish small data communications with the BS. In block 2104, the BS may receive a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state. In block 2106, the BS may receive a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.

FIG. 22 is a flowchart 2200 of a method for a base station to configure a UE to retransmit small data in accordance with a RACH retransmission time limit (msgA-SdtTransTimer, preambleSdtTransTimer) according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all examples. In some examples, the method 2100 may be performed by the scheduling entity 1600, as described above and illustrated in FIG. 16, by a processor or processing system, or by any suitable means for carrying out the described functions.

In block 2202, the BS may transmit configuration data comprising a random-access channel (RACH) retransmission time limit for the UE to establish small data communications with the BS. In block 2204 the BS may receive a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state. In block 2206, the BS may receive a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.

FIG. 23 is a flowchart 2300 of a method for a base station to configure a UE to retransmit small data in accordance with RACH fallback data (e.g., F bit) according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all examples. In some examples, the method 2100 may be performed by the scheduling entity 1600, as described above and illustrated in FIG. 16, by a processor or processing system, or by any suitable means for carrying out the described functions.

In block 2302, the BS may transmit random-access channel (RACH) configuration data for the UE to establish small data communications with a wireless network. In block 2304, the BS may receive a first RACH message for small data communication while the UE is in an inactive state. In block 2306, the BS may transmit a fallback data on a random-access response from the receipt of the first RACH message. In block 2308, the BS may receive a second RACH message from the UE without containing the user small data in response to the fallback data if a contention resolution with the UE is not successful.

Several aspects of a wireless communication network have been presented with reference to an exemplary implementation. As those skilled in the art will readily appreciate, various aspects described throughout this disclosure may be extended to other telecommunication systems, network architectures and communication standards.

By way of example, various aspects may be implemented within other systems defined by 3GPP, such as Long-Term Evolution (LTE) , the Evolved Packet System (EPS) , the Universal Mobile Telecommunication System (UMTS) , and/or the Global System for Mobile (GSM) . Various aspects may also be extended to systems defined by the 3rd Generation Partnership Project 2 (3GPP2) , such as CDMA2000 and/or Evolution-Data Optimized (EV-DO) . Other examples may be implemented within systems employing IEEE 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20, Ultra-Wideband (UWB) , Bluetooth, and/or other suitable systems. The actual telecommunication standard, network architecture, and/or communication standard employed will depend on the specific application and the overall design constraints imposed on the system.

Within the present disclosure, the word “exemplary” is used to mean “serving as an example, instance, or illustration. ” Any implementation or aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects of the disclosure. Likewise, the term “aspects” does not require that all aspects of the disclosure include the discussed feature, advantage or mode of operation. The term “coupled” is used herein to refer to the direct or indirect coupling between two objects. For example, if object A physically touches object B, and object B touches object C, then objects A and C may still be considered coupled to one another-even if they do not directly physically touch each other. For instance, a first object may be coupled to a second object even though the first object is never directly physically in contact with the second object. The terms “circuit” and “circuitry” are used broadly, and intended to include both hardware implementations of electrical devices and conductors that, when connected and configured, enable the performance of the functions described in the present disclosure, without limitation as to the type of electronic circuits, as well as software implementations of information and instructions that, when executed by a processor, enable the performance of the functions described in the present disclosure.

One or more of the components, steps, features and/or functions illustrated in FIGs. 1–20 may be rearranged and/or combined into a single component, step, feature or function or embodied in several components, steps, or functions. Additional elements, components, steps, and/or functions may also be added without departing from novel features disclosed herein. The apparatus, devices, and/or components illustrated in FIGs. 1-2, 4-5, and/or 7-10 may be configured to perform one or more of the methods, features, or steps described herein. The novel algorithms described herein may also be efficiently implemented in software and/or embedded in hardware.

It is to be understood that the specific order or hierarchy of steps in the methods disclosed is an illustration of exemplary processes. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the methods may be rearranged. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented unless specifically recited therein.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” Unless specifically stated otherwise, the term “some” refers to one or more. A phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a; b; c; a and b; a and c; b and c; and a, b and c. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.

Claims

A method of wireless communication at a user equipment (UE) , the method comprising:

receiving configuration data comprising a small data random-access channel (RACH) retransmission limit for establishing small data communications with a wireless network;

transmitting a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

retransmitting the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission limit has not been reached.
The method of claim 1, further comprising

determining that a size threshold for uplink data has been met; and

transmitting the first RACH message, based on the determination.
The method of claim 1, wherein retransmitting the first RACH message if the contention resolution with the network is not successful comprises retransmitting the first RACH message if a response is not received from the wireless network within a configured time window.
The method of claim 1, further comprising stopping the retransmitting of the first RACH message if the RACH retransmission limit has been reached, and transmitting a two-step RACH message without containing the user small data.
The method of claim 4, further comprising transmitting a four-step RACH message if a new contention resolution associated with the two-step RACH message is not successful.
The method of claim 4, wherein the two-step RACH message comprises a new RACH preamble message comprising a small data request message.
The method of claim 1, further comprising transitioning to a connected state if the contention resolution with the network is successful.
The method of claim 1, further comprising receiving configured uplink resources for data transmission if the contention resolution with the network is successful.
The method of claim 1, wherein the small data RACH preamble comprises a two-step RACH preamble, and further comprising transmitting a second RACH message comprising at least a small data four-step RACH preamble for small data communication while the UE is in an inactive state if the contention resolution with the network is not successful, and if the RACH retransmission limit has been reached.
The method of claim 1, wherein receiving the configuration data comprises receiving the configuration data as system information in one of RRC_IDLE or RRC_INACTIVE modes, or in radio resource control (RRC) dedicated signaling.
A method of wireless communication at a user equipment (UE) , the method comprising:

receiving configuration data comprising a random-access channel (RACH) retransmission time limit for establishing small data communications with a wireless network;

transmitting a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

retransmitting the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission time limit has not been reached.
The method of claim 11, wherein receiving configuration data further comprising a RACH retransmission limit for establishing small data communications with the wireless network.
The method of claim 12, further comprising stopping the retransmission time limit if the RACH retransmission limit is reached.
The method of claim 12, further comprising stopping retransmission of the first RACH preamble message if the RACH preamble retransmission limit has been reached.
The method of claim 11, further comprising

determining that a size threshold for uplink data has been met; and

transmitting the first RACH message, based on the determination.
The method of claim 11, wherein retransmitting the first RACH message if the contention resolution with the network is not successful comprises retransmitting the first RACH message if a response is not received from the wireless network within a configured time window.
The method of claim 11, further comprising stopping the retransmitting of the first RACH message if the RACH retransmission time limit has been reached, and transmitting a two-step RACH message without containing the user small data.
The method of claim 17, further comprising transmitting a four-step RACH message if a new contention resolution associated with the two-step RACH message is not successful.
The method of claim 18, wherein the four-step RACH message comprises a small data request message.
The method of claim 11, further comprising transitioning to a connected state if the contention resolution with the network is successful.
The method of claim 11, further comprising receiving configured uplink resources for data transmission if the contention resolution with the network is successful.
The method of claim 11, wherein the small data RACH preamble comprises a two-step RACH preamble, and further comprising transmitting a second RACH message comprising at least a small data four-step RACH preamble for small data communication while the UE is in an inactive state if the contention resolution with the network is not successful, and if the RACH retransmission limit has been reached.
The method of claim 11, wherein receiving the configuration data comprises receiving the configuration data as system information in one of RRC_IDLE or RRC_INACTIVE modes, or in radio resource control (RRC) dedicated signaling.
A method of wireless communication at a user equipment (UE) , the method comprising:

receiving random-access channel (RACH) configuration data for establishing small data communications with a wireless network;

transmitting a first RACH message for small data communication while the UE is in an inactive, state;

receiving a fallback data on a random-access response from the transmission of the first RACH message; and

transmitting a second RACH message without containing the user small data in response to the fallback data if a contention resolution with the network is not successful.
The method of claim 24, wherein the second RACH message comprises a small data request message.
The method of claim 24, further comprising stopping at least one of a retransmission limit and/or a retransmission time timer after receiving the fallback data
A method of wireless communication at a user equipment (UE) for an unlicensed wireless network (NR-U) , the method comprising:

receiving random-access channel (RACH) configuration data for establishing small data communications with the unlicensed wireless network;

detecting the energy level on multiple sub-bands of a communications channel to determine if the energy is above or below a configured threshold;

transmitting a first RACH message for small data communication while the UE is in an inactive state;

detecting one or more failures of transmitting the first RACH message, based on the detected energy level being above the configured threshold; and

transmitting a second RACH message without containing the user small data, based on the RACH configuration data, and on the detected energy level being below the configured threshold.
The method of claim 27, wherein the RACH configuration data comprises at least one of a retransmission limit and/or a retransmission time limit for establishing the small data communications with the unlicensed wireless network.
A method of wireless communication at a base station (BS) , the method comprising:

transmitting configuration data comprising a small data random-access channel (RACH) retransmission limit for a UE to establish small data communications with the BS;

receiving a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

receiving a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.
The method of claim 29, wherein receiving the retransmitted first RACH message if the contention resolution with the network is not successful comprises receiving the first retransmitted RACH message if a response is not transmitted from the BS within a configured time window.
The method of claim 29, wherein the configuration data comprises data instructing the UE to stop retransmission of the first RACH message if the RACH retransmission limit has been reached, and to transmit a two-step RACH message without containing the user small data.
The method of claim 29, further comprising receiving a four-step RACH message if a new contention resolution associated with the two-step RACH message is not successful.
The method of claim 29, wherein the two-step RACH message comprises a new RACH preamble message comprising a small data request message.
The method of claim 29, wherein the configuration data comprises data instructing the UE to transition to a connected state if the contention resolution with the network is successful.
The method of claim 29, further comprising transmitting configured uplink resources for data transmission if the contention resolution with the UE is successful.
A method of wireless communication at a base station (BS) , the method comprising:

transmitting configuration data comprising a random-access channel (RACH) retransmission time limit for the UE to establish small data communications with the BS;

receiving a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

receiving a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.
The method of claim 36, wherein the configuration data further comprises a RACH retransmission limit for the UE to establish small data communications with the BS.
The method of claim 36, wherein the configuration data comprises instructions for the UE to stop the retransmission time limit if the RACH retransmission limit is reached.
The method of claim 36, wherein the configuration data comprises instructions for the UE to stop retransmission of the first RACH message if the RACH retransmission limit has been reached.
The method of claim 36, wherein the configuration data comprises instructions for the UE to retransmit the first RACH message if a response is not received from the BS within a configured time window.
The method of claim 36, wherein the configuration data comprises instructions for the UE to stop the retransmitting of the first RACH message if the RACH retransmission time limit has been reached, and transmit a two-step RACH message without containing the user small data.
The method of claim 41, further comprising receiving a four-step RACH message from the UE if a new contention resolution associated with the two-step RACH message is not successful.
The method of claim 41, wherein the four-step RACH message comprises a small data request message.
The method of claim 36, wherein the configuration data comprises instructions for the UE to transition to a connected state if the contention resolution with the BS is successful.
The method of claim 36, further comprising transmitting configured uplink resources for data transmission if the contention resolution with the UE is successful.
A method of wireless communication at a base station (BS) , the method comprising:

transmitting random-access channel (RACH) configuration data for the UE to establish small data communications with a wireless network;

receiving a first RACH message for small data communication while the UE is in an inactive, state;

transmitting a fallback data on a random-access response from the receipt of the first RACH message; and

receiving a second RACH message from the UE without containing the user small data in response to the fallback data if a contention resolution with the UE is not successful.
The method of claim 46, wherein the second RACH message comprises a small data request message.
The method of claim 46, further comprising stopping at least one of a retransmission limit and/or a retransmission time timer after receiving the fallback data.
A user equipment (UE) , comprising:

a processor; and

a memory coupled to the processor,

wherein the processor and the memory are configured to

receive configuration data comprising a small data random-access channel (RACH) retransmission limit for establishing small data communications with a wireless network;

transmit a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

retransmit the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission limit has not been reached.
The UE of claim 49, wherein the processor and the memory are configured to

determine that a size threshold for uplink data has been met; and

transmit the first RACH message, based on the determination.
The UE of claim 49, wherein the processor and the memory are configured to retransmit the first RACH message if the contention resolution with the network is not successful by retransmitting the first RACH message if a response is not received from the wireless network within a configured time window.
The UE of claim 49, wherein the processor and the memory are configured to stop the retransmitting of the first RACH message if the RACH retransmission limit has been reached, and transmitting a two-step RACH message without containing the user small data.
The UE of claim 52, wherein the processor and the memory are configured to transmit a four-step RACH message if a new contention resolution associated with the two-step RACH message is not successful.
The UE of claim 52, wherein the two-step RACH message comprises a new RACH preamble message comprising a small data request message.
The UE of claim 49, wherein the processor and the memory are configured to transition to a connected state if the contention resolution with the network is successful.
The UE of claim 49, wherein the processor and the memory are configured to receive configured uplink resources for data transmission if the contention resolution with the network is successful.
The UE of claim 49, wherein the small data RACH preamble comprises a two-step RACH preamble, and further comprising transmitting a second RACH message comprising at least a small data four-step RACH preamble for small data communication while the UE is in an inactive state if the contention resolution with the network is not successful, and if the RACH retransmission limit has been reached.
The UE of claim 49, wherein receiving the configuration data comprises receiving the configuration data as system information in one of RRC_IDLE or RRC_INACTIVE modes, or in radio resource control (RRC) dedicated signaling.
A user equipment (UE) , comprising:

a processor; and

a memory coupled to the processor,

wherein the processor and the memory are configured to

receive configuration data comprising a random-access channel (RACH) retransmission time limit for establishing small data communications with a wireless network;

transmit a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

retransmit the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission time limit has not been reached.
The UE of claim 59, wherein the processor and the memory are configured to receive configuration data comprising a RACH retransmission limit for establishing small data communications with the wireless network.
The UE of claim 59, wherein the processor and the memory are configured to stop the retransmission time limit if the RACH retransmission limit is reached.
The UE of claim 59, wherein the processor and the memory are configured to stop retransmission of the first RACH preamble message if the RACH preamble retransmission limit has been reached.
The UE of claim 59, wherein the processor and the memory are configured to

determine that a size threshold for uplink data has been met; and

transmit the first RACH message, based on the determination.
The UE of claim 59, wherein the processor and the memory are configured to retransmit the first RACH message if the contention resolution with the network is not successful comprises retransmitting the first RACH message if a response is not received from the wireless network within a configured time window.
The UE of claim 59, wherein the processor and the memory are configured to stop the retransmitting of the first RACH message if the RACH retransmission time limit has been reached, and transmitting a two-step RACH message without containing the user small data.
The UE of claim 65, wherein the processor and the memory are configured to transmit a four-step RACH message if a new contention resolution associated with the two-step RACH message is not successful.
The UE of claim 66, wherein the four-step RACH message comprises a small data request message.
The UE of claim 59, wherein the processor and the memory are configured to transition to a connected state if the contention resolution with the network is successful.
The UE of claim 59, wherein the processor and the memory are configured to receive configured uplink resources for data transmission if the contention resolution with the network is successful.
The UE of claim 59, wherein the small data RACH preamble comprises a two-step RACH preamble, and further comprising transmitting a second RACH message comprising at least a small data four-step RACH preamble for small data communication while the UE is in an inactive state if the contention resolution with the network is not successful, and if the RACH retransmission limit has been reached.
The UE of claim 59, wherein receiving the configuration data comprises receiving the configuration data as system information in one of RRC_IDLE or RRC_INACTIVE modes, or in radio resource control (RRC) dedicated signaling.
A user equipment (UE) , comprising:

a processor; and

a memory coupled to the processor,

wherein the processor and the memory are configured to

receive random-access channel (RACH) configuration data for establishing small data communications with a wireless network;

transmit a first RACH message for small data communication while the UE is in an inactive, state;

receive a fallback data on a random-access response from the transmission of the first RACH message; and

transmit a second RACH message without containing the user small data in response to the fallback data if a contention resolution with the network is not successful.
The UE of claim 72, wherein the second RACH message comprises a small data request message.
The UE of claim 72, wherein the processor and the memory are configured to stop at least one of a retransmission limit and/or a retransmission time timer after receiving the fallback data
A user equipment (UE) for communicating with an unlicensed wireless network (NR-U) , comprising:

a processor; and

a memory coupled to the processor,

wherein the processor and the memory are configured to

receive random-access channel (RACH) configuration data for establishing small data communications with the unlicensed wireless network;

detect the energy level on multiple sub-bands of a communications channel to determine if the energy is above or below a configured threshold;

transmit a first RACH message for small data communication while the UE is in an inactive state;

detect one or more failures of transmitting the first RACH message, based on the detected energy level being above the configured threshold; and

transmit a second RACH message without containing the user small data, based RACH configuration data, and on the detected energy level being below the configured threshold.
The UE of claim 75, wherein the RACH configuration data comprises at least one of a retransmission limit and/or a retransmission time limit for establishing the small data communications with the unlicensed wireless network.
A base station (BS) , comprising:

a processor; and

a memory coupled to the processor,

wherein the processor and the memory are configured to

transmit configuration data comprising a small data random-access channel (RACH) retransmission limit for a UE to establish small data communications with the BS;

receive a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

receive a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.
The BS of claim 77, wherein the processor and the memory are configured to receive the retransmitted first RACH message if the contention resolution with the network is not successful by receiving the first retransmitted RACH message if a response is not transmitted from the BS within a configured time window.
The BS of claim 77 wherein the configuration data comprises data instructing the UE to stop retransmission of the first RACH message if the RACH retransmission limit has been reached, and to transmit a two-step RACH message without containing the user small data.
The BS of claim 79, wherein the processor and the memory are configured to receive a four-step RACH message if a new contention resolution associated with the two-step RACH message is not successful.
The BS of claim 79, wherein the two-step RACH message comprises a new RACH preamble message comprising a small data request message.
The BS of claim 77, wherein the configuration data comprises data instructing the UE to transition to a connected state if the contention resolution with the network is successful.
The BS of claim 77, wherein the processor and the memory are configured to transmit configured uplink resources for data transmission if the contention resolution with the UE is successful.
A base station (BS) , comprising:

a processor; and

a memory coupled to the processor,

wherein the processor and the memory are configured to

transmit configuration data comprising a random-access channel (RACH) retransmission time limit for the UE to establish small data communications with the BS;

receive a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

receive a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.
The BS of claim 84, wherein the configuration data further comprises a RACH retransmission limit for the UE to establish small data communications with the BS.
The BS of claim 85, wherein the configuration data comprises instructions for the UE to stop the retransmission time limit if the RACH retransmission limit is reached.
The BS of claim 85, wherein the configuration data comprises instructions for the UE to stop retransmission of the first RACH message if the RACH retransmission limit has been reached.
The BS of claim 84, wherein the configuration data comprises instructions for the UE to retransmit the first RACH message if a response is not received from the BS within a configured time window.
The BS of claim 84, wherein the configuration data comprises instructions for the UE to stop the retransmitting of the first RACH message if the RACH retransmission time limit has been reached, and transmit a two-step RACH message without containing the user small data.
The BS of claim 89, wherein the processor and the memory are configured to receive a four-step RACH message from the UE if a new contention resolution associated with the two-step RACH message is not successful.
The BS of claim 89, wherein the four-step RACH message comprises a small data request message.
The BS of claim 84, wherein the configuration data comprises instructions for the UE to transition to a connected state if the contention resolution with the BS is successful.
The BS of claim 84, wherein the processor and the memory are configured to transmit configured uplink resources for data transmission if the contention resolution with the UE is successful.
A base station (BS) , comprising:

a processor; and

a memory coupled to the processor,

wherein the processor and the memory are configured to

transmit random-access channel (RACH) configuration data for the UE to establish small data communications with a wireless network;

receive a first RACH message for small data communication while the UE is in an inactive, state;

transmit a fallback data on a random-access response from the receipt of the first RACH message; and

receive a second RACH message from the UE without containing the user small data in response to the fallback data if a contention resolution with the UE is not successful.
The BS of claim 94, wherein the second RACH message comprises a small data request message.
The BS of claim 94, further comprising stopping at least one of a retransmission limit and/or a retransmission time timer after receiving the fallback data.
A user equipment (UE) , comprising:

means for receiving configuration data comprising a small data random-access channel (RACH) retransmission limit for establishing small data communications with a wireless network;

means for transmitting a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

means for retransmitting the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission limit has not been reached.
A user equipment (UE) , comprising:

means for receiving configuration data comprising a random-access channel (RACH) retransmission time limit for establishing small data communications with a wireless network;

means for transmitting a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

means for retransmitting the first RACH message if a contention resolution with the network is not successful, and if the RACH retransmission time limit has not been reached.
A user equipment (UE) , comprising:

means for receiving random-access channel (RACH) configuration data for establishing small data communications with a wireless network;

means for transmitting a first RACH message for small data communication while the UE is in an inactive, state;

means for receiving a fallback data on a random-access response from the transmission of the first RACH message; and

means for transmitting a second RACH message without containing the user small data in response to the fallback data if a contention resolution with the network is not successful.
A user equipment (UE) for communicating with an unlicensed wireless network (NR-U) , comprising:

means for receiving random-access channel (RACH) configuration data for establishing small data communications with the unlicensed wireless network;

means for detecting the energy level on multiple sub-bands of a communications channel to determine if the energy is above or below a configured threshold;

means for transmitting a first RACH message for small data communication while the UE is in an inactive state;

means for detecting one or more failures of transmitting the first RACH message, based on the detected energy level being above the configured threshold; and

means for transmitting a second RACH message without containing the user small data, based RACH configuration data, and on the detected energy level being below the configured threshold.
A base station (BS) , comprising:

means for transmitting configuration data comprising a small data random-access channel (RACH) retransmission limit for a UE to establish small data communications with the BS;

means for receiving a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

means for receiving a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.
A base station (BS) , comprising:

means for transmitting configuration data comprising a random-access channel (RACH) retransmission time limit for the UE to establish small data communications with the BS;

means for receiving a first RACH message comprising at least a small data RACH preamble for small data communication while the UE is in an inactive state; and

means for receiving a retransmitted first RACH message according to the transmitted configuration data if a contention resolution with the UE is not successful.
A base station (BS) , comprising:

means for transmitting random-access channel (RACH) configuration data for the UE to establish small data communications with a wireless network;

means for receiving a first RACH message for small data communication while the UE is in an inactive, state;

means for transmitting a fallback data on a random-access response from the receipt of the first RACH message; and

means for receiving a second RACH message from the UE without containing the user small data in response to the fallback data if a contention resolution with the UE is not successful.