Patent Description:
Wireless communication systems being developed (e.g., <NUM> NR) are increasingly looking to utilize unlicensed bands, such as the <NUM> or <NUM> bands (e.g., NR-U). The power spectral density (PSD) for bands such as <NUM>, however, may be limited to protect incumbent devices (e.g., video camera) within wireless devices, with the limitation being 10dBm/MHz or lower than current <NUM> bands' PSD for both gNodeBs (gNBs) and user equipment (UE). As the PSD in such bands may be limited, the total transmit power allowed will also be limited by the bandwidth occupied. Additionally, certain standards such as Release <NUM> of 3GPP's NR standard, have assumed that a <NUM> bandwidth is sufficient for transmit power. However, Release <NUM> introduced an uplink (UL) interlace waveform for the physical uplink control channel (PUCCH) and shared channel (PUSCH) and limited the PUCCH to the <NUM> bandwidth, as well as further introducing a wideband physical random access channel (PRACH) that is also limited to a <NUM> bandwidth. Assuming a low PSD limitation for NR unlicensed band systems (e.g., <NUM> dB lower at the UE side and 5dB lower at the gNB side), it is evident that the available resources are reduced.

<CIT> discloses a method performed by a wireless device (WD) that comprises receiving a control message. The control message indicating at least a Modulation and Coding Scheme (MCS) and a scaling factor for a downlink shared channel. The scaling factor indicates a value less than <NUM>. The method further comprises determining a transport block size (TBS) based on the MCS and the scaling factor indicated in the control message. A method performed by a network node comprises indicating in a control message at least a Modulation and Coding Scheme (MCS) and a scaling factor for a downlink shared channel. The scaling factor indicating a value less than <NUM>. The method further comprises sending the control message to a User Equipment (UE), the control message enabling determination of a Transport Block Size (TBS) for a shared downlink channel.

<CIT> discloses methods, systems, and devices for wireless communications are described. Some wireless communications systems may implement reliability thresholds for transmissions. Base stations and user equipment (UEs) may implement techniques to reduce coding rates in order to improve reliability. For example, a base station may dynamically indicate a UE-specific transport block size (TBS) scaling factor for communication. The base station may include an explicit TBS scaling factor indicator in a downlink transmission, an implicit indication of the TBS scaling factor based on an indicated mode of operation (for example, a repetition mode) for the UE, or a combination thereof. By dynamically selecting between different supported scaling factors, the wireless devices may implement TBS scaling factors that are non-proportional to resource scaling factors, resulting in lower coding rates. For example, the wireless devices may utilize lower scaling factors for repetition-based transmissions than single transmissions to improve the reliability of the repeated transmissions.

<CIT> discloses a network device (e.g., a user equipment (UE), a new radio NB (gNB), or other network component) that can process or generate a dynamic Physical Uplink Shared Channel (PUSCH) repetition indication that provides parameters about PUSCH repetition(s) for the uplink within one, two or other number of slots of a New Radio (NR) communication as an Ultra-Reliable Low-Latency Communication. The network device can also process or generate one or more multiple Configuration-Grant (CG) PUSCH configurations. The presence of a repetition level bit-field in a Downlink Control Information (DCI) carrying UL grant or activating UL configured grant PUSCH can be controlled by semi-static UE-specific RRC signaling enabling or disabling the dynamic signaling of PUSCH repetitions.

<CIT> discloses wireless devices may employ techniques for indicating alternative modulation coding schemes (MCSs) (e.g., MCS values or MCS indices not associated with a default list or default MCS table). That is, communications (e.g., such as physical downlink control channel (PDCCH) transmissions carrying downlink control information (DCI), physical downlink shared channel (PDSCH) transmissions carrying uplink grants, etc.) may include information (e.g., in MCS fields and reserved fields) that indicate alternative MCSs for subsequent communications. For example, random access radio network temporary identifier (RA-RNTI) scrambled DCI, random access response (RAR) messages, etc., may indicate an alternative MCS for subsequent messages in a random access procedure (e.g., for a RAR, an RRC connection request, etc.). The alternative MCS may be conveyed by indicating information such as MCS scaling factors, alternative MCS table IDs, MCS indices associated with the alternative MCS table, or some combination thereof.

In the following, apparatus and/or methods referred to as embodiments that nevertheless do not fall within the scope of the claims should be understood as examples useful for understanding the invention.

The aspects will become more fully understood upon a review of the detailed description, which follows. Other aspects, features, and embodiments will become apparent to those of ordinary skill in the art, upon reviewing the following description of specific, exemplary embodiments of in conjunction with the accompanying figures. While features may be discussed relative to certain embodiments and figures below, all embodiments 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 discussed herein. In similar fashion, while exemplary embodiments may be discussed below as device, system, or method embodiments such exemplary embodiments can be implemented in various devices, systems, and methods.

In wireless communication systems that utilize unlicensed bands such as the <NUM> band, it is anticipated that power spectrum density (PSD) limitations may be imposed on such bands. For example, the PSD limitations may be <NUM> dBm/MHz for gNBs and -<NUM> dBm/MHz for UEs, which are substantially lower than current <NUM> PSD limitations (e.g., 10dBm/MHz for both gNB and UE). As mentioned before, such limitations will result in the effect that the total transmit power allowed will be limited by the bandwidth occupied.

Given the potential very low PSD limitations of the <NUM> band (e.g., <NUM> dB lower at UE side and <NUM> dB lower at gNB side than the current <NUM> band) and the disparity between the uplink (UL) and downlink (DL) (i.e., a relative <NUM> dB difference between UL and DL), this presents challenges to balance the resource allocation between the DL and UL. In order to increase the transmit power, the only way is to transmit the signal with wider bandwidth (i.e., the signal needs to occupy each MHz in bandwidth of frequencies). For PDSCH and PUSCH channels in <NUM> NR, this may already be done by scheduling. Notwithstanding, in <NUM> NR the transport block (TB) size scales with the size of frequency domain resource allocation, and the use of a smaller assignment cannot then boost power anymore. In this case, a large assignment in the frequency domain with higher coding gain (e.g., a higher modulation coding scheme (MCS)) would be needed. Again, however, in <NUM> NR a larger assignment implies a larger transport block size (TBS) given the same modulation coding scheme (MCS). Accordingly, some TB size adjustment (i.e., TB size reduction) may be useful to lower the coding rate or gain, similar to what is done for P-RNTI and RA-RNTI DCI 1_0 with a TB scaling field. Of further note, according to releases <NUM> and <NUM> for <NUM> NR, a TB scaling field is two (<NUM>) bits for P-RNTI, RA-RNTI and msgB-RNTI for DCI 1_0, with the scaling of the TB allowed to be scaled down by a factor of ½ (. <NUM>) or ¼ (. Accordingly, the present disclosure provides for further transport block (TB) scaling by providing a scaling factor, scaling bits, and/or a scaling field through various mechanisms, particular for systems operating in unlicensed bands (e.g. NR-U bands) such as <NUM>.

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.

Referring now to <FIG>, as an illustrative example without limitation, a schematic illustration of a wireless system <NUM> of one or more radio access networks (RANs) is provided. The RANs may implement any suitable wireless communication technology or technologies to provide radio access. As one example, a RAN may operate according to 3GPP New Radio (NR) specifications, often referred to as <NUM> or <NUM> NR. As another example, a RAN may operate under a hybrid of <NUM> NR and Evolved Universal Terrestrial Radio Access Network (eUTRAN) standards, often referred to as LTE. 3GPP refers to this hybrid RAN as a next-generation RAN, or NG-RAN.

The geographic region covered by the one or more radio access networks shown in illustration <NUM> may be divided into a number of cellular regions (cells) that can be uniquely identified by a user equipment (UE) based on an identification broadcasted over a geographical area from one access point or base station. <FIG> illustrates macrocells <NUM>, <NUM>, <NUM>, and <NUM> and a small cell <NUM>, 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 general, a respective base station (BS) serves each cell. A BS may also 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) or some other suitable terminology.

In <FIG>, three base stations <NUM>, <NUM>, and <NUM> are shown in cells <NUM>, <NUM>, and <NUM>, respectively; and a further base station <NUM> is shown controlling a remote radio head (RRH) <NUM> in cell <NUM>. 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 <NUM>, <NUM>, <NUM>, and <NUM> may be referred to as macrocells, as the base stations <NUM>, <NUM>, <NUM>, and <NUM> support cells having a large size. The base stations <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> provide wireless access points to a core network for any number of mobile apparatuses.

In general, base stations may include a backhaul interface for communication with a backhaul portion (not shown in this figure) of the network. The backhaul may provide a link between a base station and a core network (not shown), and in some examples, the backhaul may provide interconnection between the respective base stations. The core network may be a part of a wireless communication system and may be independent of the radio access technology used in the radio access network.

The one or more RANs shown in illustration of wireless system <NUM> are illustrated supporting wireless communication for multiple mobile apparatuses. A mobile apparatus is commonly referred to as user equipment (UE) in standards and specifications promulgated by 3GPP, 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 may be an apparatus that provides a user with access to network services.

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. 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" (IoT). 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 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.

The cells may include UEs that may be in communication with one or more sectors of each cell. For example, UEs <NUM> and <NUM> may be in communication with base station <NUM>; UEs <NUM> and <NUM> may be in communication with base station <NUM>; UEs <NUM> and <NUM> may be in communication with base station <NUM> by way of RRH <NUM>; UE <NUM> may be in communication with base station <NUM>; UEs <NUM> and <NUM> may be in communication with base station <NUM>, as well as with each other over a sidelink (SL) <NUM>; and UE <NUM> may be in communication with mobile base station <NUM>. Here, each base station <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be configured to provide an access point to a core network (not shown) for all the UEs in the respective cells. In another example, a mobile network node (e.g., quadcopter <NUM>) may be configured to function as a UE.

Wireless communication between a RAN and a UE (e.g., UE <NUM> or <NUM>) may be described as utilizing an air interface. Transmissions over the air interface from a base station (e.g., base station <NUM>) to one or more UEs (e.g., UE <NUM> and <NUM>) 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 base station (e.g., base stations <NUM>, <NUM>, or <NUM>). In accordance with further aspects of the present disclosure, the term uplink may refer to a point-to-point transmission originating at a UE (e.g., UE <NUM>).

According to aspects, DL transmissions may include unicast or broadcast transmissions of control information and/or data (e.g., user data traffic or other type of traffic) from a base station (e.g., base station <NUM>) to one or more UEs (e.g., UEs <NUM> and <NUM>), while UL transmissions may include transmissions of control information and/or traffic information originating at a UE (e.g., UE <NUM>). 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 <NUM> or <NUM> OFDM symbols. A subframe may refer to a duration of <NUM>. 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.

The air interface in the one or more radio access networks of <FIG> may utilize one or more multiplexing and multiple access algorithms to enable simultaneous communication of the various devices. For example, <NUM> NR specifications provide multiple access for UL or reverse link transmissions from UEs <NUM> and <NUM> to base station <NUM>, and for multiplexing DL or forward link transmissions from the base station <NUM> to UEs <NUM> and <NUM> utilizing orthogonal frequency division multiplexing (OFDM) with a cyclic prefix (CP). In addition, for UL transmissions, <NUM> 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 <NUM> to UEs <NUM> and <NUM> 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.

Further, the air interface in the radio access networks of <FIG> 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. 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 time division duplex (TDD). In FDD, transmissions in different directions operate at different carrier frequencies. 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 the wireless system <NUM>, the ability for a UE to communicate while moving, independent of their location, is referred to as mobility. The various physical channels between the UE and the RAN are generally set up, maintained, and released under the control of an access and mobility management function (AMF), 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. In various aspects of the disclosure, a RAN <NUM> 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 <NUM> may move from the geographic area corresponding to its serving cell <NUM> to the geographic area corresponding to a neighbor cell <NUM>. When the signal strength or quality from the neighbor cell <NUM> exceeds that of its serving cell <NUM> for a given amount of time, the UE <NUM> may transmit a reporting message to its serving base station <NUM> indicating this condition. In response, the UE <NUM> may receive a handover command, and the UE may undergo a handover to the cell <NUM>.

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 <NUM>, <NUM>, <NUM>, or <NUM>/<NUM> 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 <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may receive the unified synchronization signals, derive the carrier frequency and radio frame 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 <NUM>) may be concurrently received by two or more cells (e.g., base stations <NUM> and <NUM>/<NUM>) within the RAN <NUM>. Each of the cells may measure a strength of the pilot signal, and the RAN (e.g., one or more of the base stations <NUM> and <NUM>/<NUM> and/or a central node within the core network) may determine a serving cell for the UE <NUM>. As the UE <NUM> moves through the RAN <NUM>, the network may continue to monitor the uplink pilot signal transmitted by the UE <NUM>. 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 RAN <NUM> may handover the UE <NUM> from the serving cell to the neighboring cell, with or without informing the UE <NUM>.

In various implementations, the air interface in the one or more RANs in wireless system <NUM> 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 order for transmissions over the RANs in wireless system <NUM> 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 <NUM> NR specifications, 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 and UEs 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.

In some examples, access to the air interface may be scheduled, wherein 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. That is, for scheduled communication, UEs or scheduled entities utilize resources allocated by the scheduling entity.

<FIG>, as another illustrative example without limitation, illustrates various aspects of the present disclosure are illustrated with reference to a wireless communication system <NUM>. The wireless communication system <NUM> includes three interacting domains: a core network <NUM>, a radio access network (RAN) <NUM>, and one or more user equipment (UE) 206a and/or 206b. By virtue of the wireless communication system <NUM>, the UEs 206a and 206b may be enabled to carry out data communication with an external data network <NUM>, such as (but not limited to) the Internet.

The RAN <NUM> may implement any suitable wireless communication technology or technologies to provide radio access to the UEs 206a and 206b. As one example, the RAN <NUM> may operate according to <NUM> NR. As another example, the RAN <NUM> may operate under a hybrid of <NUM> NR and Evolved Universal Terrestrial Radio Access Network (eUTRAN) standards, often referred to as LTE, such as in non-standalone (NSA) systems including EN-DC systems. The 3GPP also refers to this hybrid RAN as a next-generation RAN, or NG-RAN. Additionally, many other examples may be utilized within the scope of the present disclosure.

As illustrated in <FIG>, the RAN <NUM> includes a plurality of base stations <NUM>.

The RAN <NUM> is further illustrated supporting wireless communication for multiple mobile apparatuses. A mobile apparatus may be referred to as user equipment (UE) 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 may be an apparatus (e.g., a mobile apparatus) that provides a user with access to network services.

For purposes of the present disclosure, 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" (IoT). 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, e.g., 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 the RAN <NUM> and a UE 206a or 206b may be described as utilizing an air interface. Transmissions over the air interface from a base station (e.g., base station <NUM>) to a UE <NUM> may be referred to as downlink (DL) transmission. Transmissions from UE <NUM> to a base station (e.g., base station <NUM>) 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 UE (e.g., UE <NUM>).

As illustrated in <FIG>, a base station or scheduling entity <NUM> may broadcast downlink traffic <NUM> to one or more scheduled entities <NUM>. Broadly, the base station or scheduling entity <NUM> may be configured as a node or device responsible for scheduling traffic in a wireless communication network, including the downlink traffic <NUM> and, in some examples, uplink traffic <NUM> from one or more scheduled entities <NUM> to the scheduling entity <NUM>. The UE or scheduled entity <NUM> may be configured as a node or device that also receives downlink control information <NUM>, 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 <NUM>. Furthermore, the UEs <NUM> may send uplink control information <NUM> to the base station <NUM> including but not limited to scheduling information (e.g., grants), synchronization or timing information, or other control information.

That is, for scheduled communication, UE <NUM>, which may be a scheduled entity, may utilize resources allocated by the base station or scheduling entity <NUM>.

In other examples, two or more UEs (e.g., UEs <NUM> and <NUM> in <FIG> or UE <NUM> in <FIG>) may communicate with each other using sidelink signals <NUM> or <NUM> without conveying that communication through a base station (e.g., base station <NUM> or <NUM>) and without necessarily relying on scheduling or control information from a base station.

Various aspects of the present disclosure will be described with reference to an OFDM waveform, schematically illustrated in <FIG>. It should be understood by those of ordinary skill in the art that the various aspects of the present disclosure may be applied to other waveforms such as an SC-FDMA waveform in substantially the same way as described below. While some examples in <FIG> of the present disclosure may focus on an OFDM link for clarity, it should be understood that the same principles may be applied to other waveforms.

Referring now to <FIG>, an expanded view of an exemplary subframe <NUM> 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 <NUM> 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 <NUM> may be available for communication. The resource grid <NUM> is divided into multiple resource elements (REs) <NUM>. An RE, which is <NUM> subcarrier × <NUM> symbol, is the smallest discrete part of the time-frequency grid, and contains a single complex value 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 a resource block (RB) <NUM>, which contains any suitable number of consecutive subcarriers in the frequency domain. In one example, an RB may include <NUM> 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 <NUM> entirely corresponds to a single direction of communication (either transmission or reception for a given device).

Scheduling of UEs (e.g., scheduled entities) for downlink, uplink, or sidelink transmissions typically involves scheduling one or more resource elements <NUM> within one or more sub-bands. Thus, a UE generally utilizes only a subset of the resource grid <NUM>. In some examples, 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. The RBs may be scheduled by a base station or may be self-scheduled by a UE implementing D2D or relay sidelink communication.

In this illustration, the RB <NUM> is shown as occupying less than the entire bandwidth of the subframe <NUM>, with some subcarriers illustrated above and below the RB <NUM> in frequency.

Each <NUM> subframe <NUM> may consist of one or multiple adjacent slots. In the example shown in <FIG>, one subframe <NUM> includes four slots <NUM>, 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 <NUM> or <NUM> OFDM symbols with a nominal CP. Additional examples may include mini-slots, sometimes referred to as shortened transmission time intervals (TTIs), having a shorter duration (e.g., one to three OFDM symbols). These mini-slots or shortened transmission time intervals (TTIs) may in some cases be transmitted occupying resources scheduled for ongoing slot transmissions for the same or for different UEs. Any number of resource blocks may be utilized within a subframe or slot.

An expanded view of one of the slots <NUM> illustrates the slot <NUM> including a control region <NUM> and a data region <NUM>. In general, the control region <NUM> may carry control channels, and the data region <NUM> may carry data channels. Of course, a slot may contain all DL, all UL, or at least one DL portion and at least one UL portion. The structure illustrated in <FIG> is merely exemplary, 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>, the various REs <NUM> within a RB <NUM> may be scheduled to carry one or more physical channels, including control channels, shared channels, data channels, etc. Other REs <NUM> within the RB <NUM> may also carry pilots or reference signals, including but not limited to a demodulation reference signal (DMRS) a control reference signal (CRS), or a sounding reference signal (SRS). 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 <NUM>.

In some examples, the slot <NUM> may be utilized for broadcast, multicast or unicast communication. For example, a broadcast or multicast 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 a DL transmission, the transmitting device may allocate one or more REs <NUM> (e.g., within a control region <NUM>) to carry DL control information including one or more DL control channels, such as a PBCH; a PSS; a SSS; a physical control format indicator channel (PCFICH); a physical hybrid automatic repeat request (HARQ) indicator channel (PHICH); and/or a physical downlink control channel (PDCCH), etc., to one or more scheduled entities. The PCFICH provides information to assist a receiving device in receiving and decoding the PDCCH. The PDCCH carries downlink control information (DCI) including but not limited to power control commands, scheduling information, a grant, and/or an assignment of REs for DL and UL transmissions. The PHICH carries 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..

In an UL transmission, the transmitting device may utilize one or more REs <NUM> to carry UL control information including one or more UL control channels, such as a physical uplink control channel (PUCCH), to the scheduling entity. 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. 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.

In addition to control information, one or more REs <NUM> (e.g., within the data region <NUM>) may be allocated for user data traffic. Such traffic may be carried on one or more traffic channels, such as, for a DL transmission, a physical downlink shared channel (PDSCH); or for an UL transmission, a physical uplink shared channel (PUSCH). In some examples, one or more REs <NUM> within the data region <NUM> may be configured to carry system information blocks (SIBs), carrying information that may enable access to a given cell.

The channels or carriers described above in connection with <FIG> and <FIG> are not necessarily all of the channels or carriers that may be utilized between a base station or scheduling entity and UEs or 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.

Further, the 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), which were mentioned above. As an illustration, an exemplary MAC layer transport block <NUM> is shown mapped to subframe <NUM> in <FIG>, but is not limited to such mapping and this is only for illustration purposes to demonstrate a certain mapping. The transport block size (TBS), which may correspond to a number of bits of information, can be a controlled parameter based on the modulation and coding scheme (MCS) and the number of RBs in a given transmission. As will be explained in more detail below, aspects of the present disclosure relate to scaling of the TBS, particularly for systems utilizing various bands that may have limited PSD, as well as UL interlaced waveforms that have been introduced for the PUCCH and PUSCH in <NUM> NR specifications.

According to certain standards, the TB size scales with the size of frequency domain resource allocation (FDRA). Moreover, using a smaller assignment of resources cannot boost power and the use of a larger assignment (in frequency domain) with higher coding gain is needed. According to Release <NUM> of the <NUM> NR standards, however, given the defined TBS calculation, a larger assignment implies a larger TBS given the same modulation coding scheme (MCS). Accordingly, TB size adjustment may be useful for lowering the coding rate, such as what is done in a paging radio network temporary identifier (P-RNTI) and random access radio network temporary identifier (RA-RNTI) DCI 1_0 with a TB scaling field. In Releases <NUM>/<NUM> of <NUM> NR, for example, there is a two bit TB scaling field for P-RNTI and RA-RNTI, and msgB-RNTI for DCI 1_0, that allows a TB to be scaled down by factors of <NUM>, <NUM> (<NUM>/<NUM>), or ¼ (<NUM>). In some aspects, the present disclosure provides for TB scaling using various methods and apparatus to communicate such TB scaling in NR-U systems using existing capacity/resources or repurposing of resource to provide communication of a TB scaling field or TB scaling bits.

According to one aspect, it is noted that various existing locations in downlink control information (DCI) may be utilized to communicate TB scaling from a gNB to at least one UE. Here, a TB scaling field or TB scaling bits scaling field may be utilized in DCI for both UL grants and DL grants, and with both fallback and non-fallback DCIs. It is also noted that, in certain aspects, the TB scaling indications may only be utilized for only lower or lowest modulation coding schemes (MCSs) where the need for reduction in coding rates through TB scaling is more acute.

<FIG> illustrates one example of DCI (or a portion thereof) <NUM> that features two scaling bits that are placed within existing reserved bits in the DCI. As illustrated, according to an aspect the DCI <NUM> includes a number of reserved bits indicated by range <NUM>. In a particular aspect where a system information radio network temporary identifier (SI-RNTI) type is used with the DCI. In this example, as well as other types of DCIs, there is a range of reserved bits in the DCI such as range <NUM>, which may be from <NUM> to <NUM> bits in some examples. Accordingly, two TB scaling bits within the range <NUM> and indicated as b<NUM> and b<NUM> (also <NUM> and <NUM>) are selected for communicating TB scaling. Since two bits are used in this example, up to four values may be communicated. For example, binary value <NUM> may indicate a TB scaling factor of <NUM>, binary value <NUM> may indicate a TB scaling factor of <NUM> (<NUM>/<NUM>), binary value <NUM> may indicate a TB scaling factor of <NUM> (<NUM>/<NUM>), and binary value <NUM> may indicate a value of <NUM> (<NUM>/<NUM>). Additionally, DCI <NUM> may include cyclic redundancy check (CRC) bits masked or scrambled by SI-RNTI as indicated at <NUM>.

<FIG> illustrates another example of DCI (or a portion thereof) <NUM> that features two scaling bits that may be placed within an existing bit field in the DCI. As illustrated, according to an aspect the DCI <NUM> includes a number of known bits. In a particular aspect where temporary cell RNTI (TC-RNTI) type is used with the DCI, there are at least two reserved bits in the DCI known as the downlink assignment index (DAI) indicated at <NUM>. The DAI <NUM> is a TDD specific field that normally tells the UE the counts of downlink assignments scheduled for it within a given time frame. In this example, however, the two bit DAI field <NUM> is utilized for TB scaling bits indicated as b<NUM> and b<NUM> (also <NUM> and <NUM>) are reserved for communicating TB scaling. Again, since two bits are used in this example, up to four values may be communicated (e.g., binary value <NUM> may indicate a TB scaling factor of <NUM>, binary value <NUM> may indicate a TB scaling factor of <NUM> (<NUM>/<NUM>), binary value <NUM> may indicate a TB scaling factor of <NUM> (<NUM>/<NUM>), and binary value <NUM> may indicate a value of <NUM> (<NUM>/<NUM>)). Additionally, DCI <NUM> may include cyclic redundancy check (CRC) bits masked or scrambled by TC-RNTI as indicated at <NUM>.

<FIG> illustrates another example of DCI (or portion thereof) <NUM> that features two scaling bits that may be placed within an existing information bit field in the DCI, which is repurposed for the TB scaling bits. In this example, it is noted that for low code rates, each redundancy version (RV) may include almost all the coded bits of a mother code. The coding gain from different RVs is most likely neglected. Therefore, a single RV in the DCI <NUM> may be sufficient size to use for the two bits of the TB scaling factor. In this case, two bits of RV identifier (RVID) RV0 may be repurposed the existing DCI (e.g., <NUM>) can be reserved by always transmitting this RVID. As illustrated, according to an aspect the DCI <NUM> includes two bits <NUM> and <NUM> in the RVID <NUM>. Again, since two bits are used in this example, up to four values may be communicated (e.g., binary value <NUM> may indicate a TB scaling factor of <NUM>, binary value <NUM> may indicate a TB scaling factor of <NUM> (<NUM>/<NUM>), binary value <NUM> may indicate a TB scaling factor of <NUM> (<NUM>/<NUM>), and binary value <NUM> may indicate a value of <NUM> (<NUM>/<NUM>)). Additionally, DCI <NUM> may include cyclic redundancy check (CRC) bits masked or scrambled by C-RNTI/CS-RNTI/MCS-C-RNTI as indicated at <NUM>.

In a further aspect, it is noted that the repurposing of RVID bits may be particularly applicable to instances of low MCS. In such case, and according to the invention, the RRC is used to configure an MCS threshold, below which a UE will be instructed or configured to reinterpret the RVID field of TB scaling. Alternatively, an RRC controlled flag could be utilized to indicate that a hard coded MCS value or lower will cause the UE to reinterpret the RVID for TB scaling.

According to further aspects, it is noted that when a gNB receives a physical random access channel (PRACH) from a UE to request an UL, the gNB will transmit a feedback random access resource (RAR) message to the UE. This RAR includes a time advance (TA), a UL-grant for message <NUM> (msg3), and TC-RNTI. To improve the link budget for the msg3 transmission, a TB scaling indication may be included in the UL-grant in the RAR. Accordingly, <FIG> illustrates an exemplary RAR structure <NUM> that may be used in providing TB scaling from a base station or gNB to a UE.

As may be seen in <FIG>, the RAR <NUM> includes a number of <NUM> bit octets (e.g., Oct0 through Oct7). The TB scaling bits may be added to the RAR media access control element (MAC-CE) to indicate the TB scaling factor for the PUSCH scheduled by a UL-grant in this RAR <NUM>, which may be seen as contained in octets <NUM>, <NUM>, <NUM>, and <NUM>. In particular, the example of <FIG> illustrates that two bits in the UL-grant in RAR <NUM> may be repurposed for the TB scaling bits. One of the bits <NUM> in octet <NUM>, for example, which is a frequency hopping flag (i.e., <NUM> bit), is known to be disabled when an interlaced waveform is used. Accordingly, this bit <NUM> may be used or repurposed for one of the bits of the TB scaling bits (e.g., bit b<NUM>).

Furthermore, one bit <NUM> from the frequency domain resource assignment (FDRA) in the UL grant may be used as the other TB scaling bit (e.g., b<NUM>). It is noted that the FDRA may currently use <NUM> bits (note with already borrowed <NUM> bits for Channel Access-CPext (CAPC-Cpext)), but this many bits is not necessary if an interlaced waveform is used. Accordingly, bit <NUM> may be repurposed for use to transport a TB scaling bit (e.g., b<NUM>).

<FIG> illustrates another exemplary RAR structure <NUM> that may be used in communicating TB scaling from a base station or gNB to a UE. In this example, rather than repurpose bits in an existing RAR structure, at least two new bits for the TB scaling factor are introduced by adding another octet (<NUM> bits) to the RAR <NUM>. As illustrated in <FIG>, a further octet <NUM> is added to RAR <NUM>. At least two bits <NUM>, <NUM> within this octet <NUM> contain TB scaling bits b<NUM> and b<NUM>. Additionally, the addition of octet <NUM> adds the remaining six bits as further reserved bits at the same time, which may be utilized for other purposes. While the expansion of the RAR structure here does not impose too great of an additional loading burden on the PDSCH, in order to implement the RAR <NUM>, does require defining a new MAC-CE.

According to further aspects, the TB scaling information or factor may be encoded jointly with the time division resource allocation (TDRA). Of note, this joint encoding may be particularly applicable for C-RNTI/CS-RNTI/MCS-C-RNTI cases. The joint encoding may involve either a reconfiguration of a TDRA table (i.e., TDRA configuration information) for a PDSCH to add the TB scaling information to the TDRA table or a hard coded change where a default TDRA is modified to be able to add the TB scaling information, such as through adding an additional column to the TDRA table.

In one aspect of joint encoding of the TB scaling information or factor and the TDRA information, one or more special TDRA table entries may defined taking into consideration the TB scaling factor and a start and length indicator (SLIV, which indicates the start symbol and length of a PUSCH) for the time domain resource allocation to ensure correct accounting of this information to determine the TB size for the PUSCH. In one aspect, the TDRA table may be reconfigured such that a new entry in the TDRA table may be introduced by a UE specific TDRA configuration.

In another alternative, a default TDRA may be modified for a particular band (e.g., <NUM>) when coverage extension is needed. Here a remaining minimum system information (RMSI) may be used to configure the choice of the new default TDRA table.

In yet another alternative, rather than changing the TDRA, communication of TB scaling information or factors can be accomplished through associating the TB scaling with the MCS. In this alternative, the radio resource control (RRC) may configure (e.g., for an SIB or UE specific) to associate the TB scaling with the modulation coding scheme (MCS). Here, one or more MCSs may be associated with a particular TB scaling factor. For example, MCS values <NUM>-<NUM> could be associated with a ¼ TB scaling factor, MCS values <NUM>-<NUM> associated with a ½ TB scaling factor, and MCS values of five or more associated with a <NUM> TB scaling factor. In one aspect, this association could be applicable to all PUSCH or PDSCH channels regardless of the type of radio network temporary identifier (RNTI). In another aspect, the association of the TB scaling factor to the MCS value may be configured such that the association is only applied to DCIs received in a UE specific search space (USS), but not in a common search space (CSS).

In yet other aspects, it is noted that in the UL there are two types of configured grants (CGs) known as type <NUM> CG and type <NUM> CG. In a type <NUM> CG, the UL grant is configured by the RRC and, once configured, it is always active. A type <NUM> CG is first configured by the RRC, but then is additionally activated by the PDCCH scrambled with CS-RNTI before it can be utilized (e.g., an activation DCI). In the DL, semi-persistent scheduling (SPS) is used to allocate a UE with periodic DL assignments or UL grants (i.e., CGs) to serve a certain kind of traffic type that has a defined interval between when the packets have to be received and/or transmitted. The SPS resources are configured by the RRC with a given periodicity and the DL assignment that is scrambled with a specific CS-RNTI is then used for activation and deactivation of the resource (e.g., an activation DCI).

Thus, for type <NUM> CGs and DL SPS, an activation DCI is utilized and the previously described techniques for TB scaling can be applied using the activation DCI, in an example. For a type <NUM> CG for the UL, however, there is no activation DCI. Accordingly, various other techniques may be utilized to add TB scaling for such CGs. In a first aspect, TB scaling control may be added in the RRC configuration for type <NUM> CGs. This may be accomplished by adding a field in an information element (IE) for the CG configuration, and there is no definitive or tight requirement on the number of bits for the configuration. Accordingly, the TB scaling resolution can even be higher, instead of limited to merely <NUM> bits.

In another aspect, TB scaling control for a type <NUM> CG may be added for a msgA PUSCH configuration in common RRC signaling. Similar to the TB scaling added in the RRC above, there is not a tight requirement on the number of bits and the TB scaling control may have a greater resolution beyond just <NUM> bits. In still another aspect, the TB scaling for a msgA PUSCH may be linked to the PRACH repetition in the frequency domain. For example, if the PRACH is repeated four times in frequency, a TB scaling of four may be applied to msgA PUSCH.

In yet another aspect, for an RRC_CONNECTED UE, the UE may be further configured with TB scaling for the msgA PUSCH through dedicated RRC signaling. The dedicated RRC signaling can have better TB scaling control than the common RRC signaling or the default TB scaling linked to PRACH frequency domain repetition. Of note, in this aspect, if the TB scaling is not configured through the dedicated RRC signaling, the TB scaling would simply follow RRC common signaling or be tied to PRACH transmission.

<FIG> is a block diagram illustrating an example of a hardware implementation for a base station <NUM> employing a processing system <NUM>. For example, the base station <NUM> may correspond to any of the base stations or gNBs previously discussed herein. In further examples, the base station <NUM> may be an access point (AP) or remote radio head, or an IEEE <NUM> device such as a Wi-Fi access point, gateway, or router in some examples, or any other device that may utilize various bands such as NR-U bands in the <NUM> or <NUM> ranges.

The base station <NUM> may be implemented with a processing system <NUM> that includes one or more processors <NUM>. Examples of processors <NUM> 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 base station device <NUM> may be configured to perform any one or more of the functions described herein. That is, the processor <NUM>, as utilized in the base station <NUM>, may be used to implement any one or more of the processes and procedures described below.

In this example, the processing system <NUM> may be implemented with a bus architecture, represented generally by the bus <NUM>. The bus <NUM> may include any number of interconnecting buses and bridges depending on the specific application of the processing system <NUM> and the overall design constraints. The bus <NUM> links together various circuits including one or more processors (represented generally by the processor <NUM>), a memory <NUM>, and computer-readable media (represented generally by the computer-readable medium <NUM>). The bus <NUM> 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 <NUM> provides an interface between the bus <NUM> and a wireless transceiver <NUM>. The wireless transceiver <NUM> allows for the base station <NUM> to communicate with various other apparatus over a transmission medium (e.g., air interface). Depending upon the nature of the apparatus, a user interface <NUM> (e.g., keypad, display, touch screen, speaker, microphone, control knobs, etc.) may also be provided. Of course, such a user interface <NUM> is optional, and may be omitted in some examples.

The computer-readable medium <NUM> 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 <NUM> may reside in the processing system <NUM>, external to the processing system <NUM>, or distributed across multiple entities including the processing system <NUM>. The computer-readable medium <NUM> may be embodied in a computer program product. By way of example, a computer program product may include a computer-readable medium in packaging materials. In some examples, the computer-readable medium <NUM> may be part of the memory <NUM>. 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 <NUM> may include circuitry configured for various functions. For example, the processor <NUM> may include a transport block (TB) scaling factor determination circuitry <NUM>, which is configured for determining the TB scaling factor or bits as discussed herein. Further, processor <NUM> may include TB scaling communication circuitry <NUM> configured to communicate, transmit, or send the TB Scaling information or factor to one or more UEs, for example. Circuitry <NUM> may, at least in part, cause the base station to send the TB scaling information to a UE as is accomplished in the processes discussed above, as well as the process to be discussed later with respect to <FIG>. The processor <NUM> further includes DL traffic and control generation and transmission circuitry <NUM> for transmitting downlink (DL) data to one or more UEs or relay UEs. Furthermore, the processor <NUM> may include RRC control circuitry <NUM> that is configured to effect RRC control and signaling in connection with the methods discussed earlier and as will be discussed with respect to <FIG>.

The computer-readable medium <NUM> includes TB scaling determination software/instructions <NUM> and TB scaling communication software/information <NUM> to assist the TB scaling determination circuitry <NUM> and TB scaling communication circuitry <NUM> in performing their respective functions as described herein. Similarly, the computer readable medium <NUM> includes RRC control software/information <NUM> to assist the RRC control circuitry <NUM> perform its function as described herein.

<FIG> is a flow diagram of an exemplary method <NUM> for providing transport block (TB) scaling in a wireless communication system. It is noted that method <NUM> may be implemented within a base station or some other scheduling entity (e.g., an access point). Method <NUM> includes configuring a scaling field within at least one of downlink control information (DCI) to indicate a scaling factor corresponding to a transport block (TB) size for one of a physical uplink shared channel (PUSCH) or a physical downlink shared channel (PDSCH) as illustrated at block <NUM>. This configuring process in block <NUM> further includes disposing the scaling field within an existing bit field in the DCI. As an example, the existing bit field may be reserved bits, a DAI, or RVID field as illustrated in <FIG>. Moreover, it is noted that this process <NUM> may be implemented by a base station, such as base station <NUM> in <FIG> or base station <NUM> in <FIG>, as a couple examples. Furthermore, the process <NUM> may be implemented by one or more of circuitry <NUM> and <NUM> in <FIG>, as another example.

Method <NUM> also includes transmitting the DCI to at least one user equipment (UE) for communication of the TB scaling information to the UE as shown in block <NUM>. This process <NUM> may be implemented by a base station, such as base station <NUM> in <FIG> or base station <NUM> in <FIG>, as a couple examples. Furthermore, the process <NUM> may be implemented by circuitry <NUM> and transceiver <NUM> in <FIG>, as another example.

According to other aspects, method <NUM> may include that the RVID field is repurposed for transmission of the scaling field and transmitting a particular identification value of the RVID field to the UE when the RVID field is repurposed for transmission of the scaling field. In further aspects, method <NUM> may include transmitting a radio resource control (RRC) signal to the UE with a predetermined modulation coding scheme (MCS) threshold that is usable by the UE to cause reinterpreting of the RVID field for TB scaling when the MCS threshold is below a particular value. In still further aspects, method <NUM> may include transmitting an RRC flag to the UE wherein the RRC flag is configured to indicate to the UE that the RVID field is to be used for TB scaling.

<FIG> illustrates a flow diagram of another exemplary method <NUM> for providing and communicating a transport block (TB) scaling factor in a wireless communication system. It is noted that method <NUM> may be implemented within a base station or some other scheduling entity (e.g., an access point). Method <NUM> includes adding one or more scaling bits within one or more fields of a random access resource (RAR) control element to indicate a scaling factor corresponding to a transport block (TB) size for a physical uplink shared channel (PUSCH) as shown in block <NUM>. As an example, the process in block <NUM> may include either placing bits into existing fields in the UL grant of the RAR as shown in <FIG>, or into added fields such as shown in <FIG>. Moreover, it is noted that this process <NUM> may be implemented by a base station, such as base station <NUM> in <FIG> or base station <NUM> in <FIG>, as a couple examples. Furthermore, the process <NUM> may be implemented by one or more of circuitry <NUM> and <NUM> in <FIG>, as well as RRC control circuitry <NUM>, as another example. Method <NUM> further includes transmitting the RAR control element with the one or more scaling bits to at least one user equipment (UE) as shown in block <NUM>. The process in block <NUM> may be implemented, according to one example, by circuitries <NUM> and <NUM>, as well as transceiver <NUM> in <FIG>.

According to further aspects, method <NUM> may include placing one of the one of more scaling bits in an uplink (UL) grant field of the RAR control element. Moreover, method <NUM> may include placing one of the one of more scaling bits in a frequency hopping bit location within a first uplink (UL) grant field of the RAR control element, and placing another one of the one of more scaling bits in a frequency domain resource assignment (FDRA) within a second uplink (UL) grant field of the RAR control element. In still another aspect, method <NUM> may include configuring the RAR control element with an additional control field and placing the one or more scaling bits in the additional control field.

<FIG> illustrates a flow diagram of another exemplary method <NUM> for providing transport block (TB) scaling in a wireless communication system. It is noted that method <NUM> may be implemented within a base station or some other scheduling entity (e.g., an access point). Method <NUM> includes determining, in a base station, a transport block (TB) scaling factor used for setting a transport block (TB) size for a physical downlink shared channel (PDSCH) as shown in block <NUM>. It is noted that this process in block <NUM> may be effected by base station <NUM> or base station <NUM>, as merely two examples. Further, this process <NUM> may be effectuated by circuitry <NUM> and <NUM> in another example.

Method <NUM> further includes encoding the scaling factor with a timed domain resource allocation (TDRA) as shown in block <NUM>. It is noted that this process in block <NUM> may be effected by base station <NUM> or base station <NUM>, as merely two examples. Further, this process <NUM> may be effectuated by circuitry <NUM> in another example. Method <NUM> then further includes transmitting the TDRA with the scaling field with the scaling factor used for setting the TB size to at least one user equipment (UE) as shown at block <NUM>. This process <NUM> may be implemented by a base station, such as base station <NUM> in <FIG> or base station <NUM> in <FIG>, as a couple examples. Furthermore, the process <NUM> may be implemented by circuitry <NUM> and transceiver <NUM> in <FIG>, as another example.

According to further aspects, method <NUM> may include encoding the scaling factor with the TDRA by adding a new entry or changing an existing entry in a TDRA table for a TRDR that is specific to the UE, and adding the TB scaling factor to the new entry or the changed existing entry in the TDRA table. In yet further aspects, method <NUM> may include encoding the scaling factor with the TDRA through modifying a default TDRA table using Remaining Minimum System Information (RMSI) to create a new TDRA table with one or more additional entries, and encoding the TB scaling factor in the new TDRA table.

<FIG> illustrates a flow diagram of another exemplary method <NUM> for providing transport block (TB) scaling in a wireless communication system. It is noted that method <NUM> may be implemented within a base station or some other scheduling entity (e.g., an access point). Method <NUM> includes determining a transport block (TB) scaling factor for scaling a TB size for one of a physical uplink shared channel (PUSCH) or a physical downlink shared channel (PDSCH) as shown in block <NUM>.

Method <NUM> further includes associating the TB scaling factor using a radio resource control (RRC) mechanism in the base station with at least one modulation coding scheme (MCS) as shown at block <NUM>. Moreover, method <NUM> includes transmitting the TB scaling via RRC signaling to at least one user equipment (UE) as shown in block <NUM>.

According to other aspects, method <NUM> may include the RRC configured signaling to include signal information block (SIB) signals from the base station to the at least one UE. Moreover, the TB scaling factor may be configured to apply to all PUSCH and PDSCH channels for a plurality of radio network temporary identifiers (RNTIs), and/or apply to all PUSCH and PDSCH channels. Still further, method <NUM> may include the TB scaling factor configured to apply to downlink control information (DCI) received in a UE specific search space (USS), but not to a common search space (CSS).

<FIG> illustrates a flow diagram of still another exemplary method <NUM> for providing transport block (TB) scaling in a wireless communication system. Method <NUM> includes determining transport block (TB) scaling information within a base station that is usable for scaling a TB size for a physical uplink shared channel (PUSCH) as indicated in block <NUM>. Further, method <NUM> includes adding the TB scaling information to a radio resource control (RRC) configuration as indicated in block <NUM>. Still further, method <NUM> includes transmitting the RRC configuration via RRC signaling from the base station to a user equipment (UE) including the TB scaling information for use in uplink (UL) transmission as shown in block <NUM>. It is noted that, according to one example, the processes in method <NUM> may be implemented by one or more of TB scaling determination circuit <NUM>, TB scaling communication circuitry <NUM>, and RRC control circuitry <NUM>, as well as transceiver <NUM>.

According to further aspects, method <NUM> may include adding the TB scaling information to the RRC configuration comprises adding a field in an information element (IE) for a type <NUM> configured grant (CG). In other aspects, method <NUM> may include adding the TB scaling information to the RRC configuration by adding the TB scaling information for a msgA PUSCH configuration that is transmitted by the RRC signaling to the UE, where this RRC signaling may be common RRC signaling in one aspect.

In yet further aspects, method <NUM> may include linking the TB scaling information for the msgA PUSCH to a frequency of repetition of the transmission of a physical random access channel (PRACH), wherein a number of PRACH repetitions is correlated to a particular TB scaling factor of the TB scaling information. In still another aspect, method <NUM> may include, for an RRC_CONNECTED UE, configuring the TB scaling for the msgA PUSCH using a dedicated RRC signaling, rather than through common RRC signaling.

<FIG> is a conceptual diagram illustrating an example of a hardware implementation for an exemplary UE <NUM> employing a processing system <NUM>. For example, the UE <NUM> may be a UE as illustrated in any one or more of the various examples herein.

The processing system <NUM> may be substantially the same as the processing system <NUM> illustrated in <FIG>, including a bus interface <NUM>, a bus <NUM>, memory <NUM>, a processor <NUM>, and a computer-readable medium <NUM>. Furthermore, the UE <NUM> may include a user interface <NUM> and a transceiver <NUM> substantially similar to those described above in <FIG>. 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 <NUM> that includes one or more processors <NUM>. That is, the processor <NUM>, as utilized in a UE <NUM>, may be used to implement any one or more of the processes described below.

In some aspects of the disclosure, the processor <NUM> may include circuitry configured for various functions. For example, the processor <NUM> may include TB scaling information circuitry <NUM> configured to receive the TB scaling information (e.g., TB scaling bits/factors) from a base station, including reception via RRC signaling in some aspects, as well as to decode received TB scaling information in other aspects. The processor <NUM> may further include TB scaling circuitry <NUM>, which may be configured and implement TB scaling based on the received (and decoded) TB scaling information.

The computer-readable medium <NUM> includes TB scaling information reception (and decoding) software/instructions <NUM> and TB scaling software/instructions <NUM> that receive the distributed joint grant (or a portion thereof) to perform their respective functions as previously described. Instructions or software <NUM> and <NUM> may be respectively used to assist the TB scaling information reception circuitry <NUM> and the TB scaling circuitry <NUM> in performing its function as previously described.

<FIG> is a flow chart of an exemplary method <NUM> for a UE to receive TB scaling information according to some aspects. In examples, method <NUM> may be implemented by UE <NUM> or UE <NUM>. As illustrated, method <NUM> includes receiving downlink control information (DCI) from a base station, the DCI including a scaling field configured to indicate a scaling factor corresponding to a transport block (TB) size for one of a physical uplink shared channel (PUSCH) or a physical downlink shared channel (PDSCH), wherein the scaling field is further disposed within an existing bit field in the DCI as shown in block <NUM>. Additionally, method <NUM> includes determining a size of a transport block based on the scaling factor as shown in block <NUM>.

<FIG> is a flow chart of another exemplary method <NUM> for a UE to receive TB scaling information according to some aspects. In examples, method <NUM> may be implemented by UE <NUM> or UE <NUM>. Method <NUM> includes receiving a random access resource (RAR) control element from a base station, the RAR including one or more scaling bits within one or more fields of the RAR control element configured to indicate a scaling factor corresponding to a transport block (TB) size for a physical uplink shared channel (PUSCH) as shown in block <NUM>. Further, method <NUM> includes determining a size of a transport block based on the scaling factor as shown in block <NUM>.

<FIG> is a flow chart of yet another exemplary method <NUM> for a UE to receive TB scaling information according to some aspects. In examples, method <NUM> may be implemented by UE <NUM> or UE <NUM>. Method <NUM> includes receiving a timed domain resource allocation (TDRA), the TDRA including a scaling field with a scaling factor used for setting a transport block (TB) size for a physical downlink shared channel (PDSCH) as shown in block <NUM>. Further, method <NUM> includes decoding the scaling factor within the TDRA as indicated at block <NUM>. Finally, method <NUM> includes determining a size of a TB based on the decoded scaling factor as shown in block <NUM>.

<FIG> is a flow chart of still another exemplary method <NUM> for a UE to receive TB scaling information according to some aspects. In examples, method <NUM> may be implemented by UE <NUM> or UE <NUM>. Method <NUM> include receiving from a base station a transport block (TB) scaling factor for scaling a TB size for one of a physical uplink shared channel (PUSCH) or a physical downlink shared channel (PDSCH) via radio resource control (RRC) configured signaling, wherein the TB scaling factor is associated with at least one modulation coding scheme (MCS) using an RRC mechanism as shown in block <NUM>. Furthermore, method <NUM> includes determining a TB size based on the TB scaling factor received via the RRC configured signaling as shown in block <NUM>.

<FIG> is a flow chart of still another exemplary method <NUM> for a UE to receive TB scaling information according to some aspects. In some examples, method <NUM> may be implemented by UE <NUM> or UE <NUM>. Method <NUM> features receiving an RRC configuration via RRC signaling from a base station including transport block (TB) scaling information for use in uplink (UL) transmissions as shown in block <NUM>. Furthermore, method <NUM> includes determining a TB size for a physical uplink shared channel (PUSCH). based on the TB scaling information in the RRC configuration as shown in block <NUM>.

The apparatus, devices, and/or components illustrated in <FIG>, <FIG>, <FIG>, or <FIG> may be configured to perform one or more of the methods, features, or steps described herein.

Claim 1:
A method of wireless communication performed by a base station in a wireless communication network, the method comprising:
configuring (<NUM>) a scaling field within downlink control information, DCI, to indicate a scaling factor corresponding to a transport block, TB, size for one of a physical uplink shared channel, PUSCH, or a physical downlink shared channel, PDSCH, wherein the scaling field is disposed within an existing bit field in the DCI and the existing bit field comprises a two bit redundancy version identifier, RVID, field;
transmitting a radio resource control, RRC, signal to a user equipment, UE, configuring a predetermined modulation coding scheme, MCS, threshold below which the UE is instructed to reinterpret the RVID field for TB scaling; and
transmitting (<NUM>) the DCI to the UE.