PDSCH for reduced capability user equipment

Abstract

According to some embodiments, a method is performed by a reduced capability (RedCap) wireless device. The method includes: receiving a physical downlink shared channel (PDSCH), the PDSCH including a schedule for an uplink transmission; determining whether a duration between receiving the PDSCH and a start of the scheduled uplink transmission is greater than a 5 threshold; and transmitting the scheduled uplink transmission in accordance with a determination that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is greater than a threshold. The threshold value depends on whether the PDSCH is received in a bandwidth greater than a reduced bandwidth associated with the RedCap wireless device.

Description

Technical Field

[0001] The present disclosure generally relates to communication networks, and more particularly, to a physical downlink shared channel (PDSCH) for a reduced capability (RedCap) user equipment (UE). Background Art

[0002] The next-generation paradigm shift in processing and manufacturing is known as Industry 4.0, where factories are automated and more flexible and dynamic with the help of wireless connectivity. This includes the use of time-critical machine type communication (cMTC) for real-time control of robots and machines, and the use of a large number of simple actuators and sensors (massive machine type communication or mMTC) to improve observability, control, and error detection. To support cMTC, ultra-reliable low-latency communication (URLLC) was introduced in the 3rd Generation Partnership Project (3GPP) Release 15 for both Long-Term Evolution (LTE) and New Radio (NR), and NR URLLC was further enhanced in Release 16 within the Enhanced URLLC (eURLLC) and Industrial Internet of Things (IoT) work items.

[0003] For mMTC and low-power wide-area (LPWA) support, 3GPP introduced both Narrowband Internet of Things (NB-IoT) and Long-Term Evolution for Machine Type Communication (LTE-MTC or LTE-M) in Release 13. These technologies have been further enhanced through all the releases up to and including the ongoing Release 17 work.

[0004] NR was introduced in 3GPP Release 15 and mainly focuses on enhanced mobile broadband (eMBB) and cMTC. However, there are still several other use cases that have requirements higher than those of LPWA networks (i.e., LTE-M / NB-IoT) but lower than those of URLLC and eMBB. To effectively support such use cases in between eMBB, URLLC, and mMTC, 3GPP has studied reduced capability (RedCap) NR devices in Release 17.

[0005] The expected RedCap user equipment (UE) is associated with a lower cost, lower complexity, longer battery life, and potentially smaller form factor compared to traditional NR UEs. Therefore, several different complexity reduction features are specified for RedCap UEs in Release 17. These complexity reduction features are listed in the Release 17 Work Item Description (WID) for RedCap ("Revised WID on support of reduced capability NR device", Ericsson, 3GPP TSG RAN #95e, March 2022).

[0006] The work item includes support for the following UE complexity reduction features. One feature is the reduced maximum UE bandwidth. The maximum bandwidth of a Frequency Range 1 (FR1) RedCap UE during and after initial access is 20 MHz. The maximum bandwidth of a Frequency Range 2 (FR2) RedCap UE during and after initial access is 100 MHz.

[0007] Another feature is the reduced minimum number of receive (Rx) branches. For bands where traditional NR UEs are required to be equipped with at least 2 Rx antenna ports, the minimum number of Rx branches supported by the specification for RedCap UEs is 1. The specification also supports two Rx branches for RedCap UEs in these bands.

[0008] For bands where traditional NR UEs (except 2-Rx vehicular UEs) are required to be equipped with at least four Rx antenna ports, the minimum number of Rx branches supported by the specification for RedCap UEs is one. The specification also supports two Rx branches for RedCap UEs in these bands.

[0009] It shall be specified how the gNB can know the number of Rx branches of the UE.

[0010] Another feature is the reduced maximum number of downlink multiple-input multiple-output (MIMO) layers. For a RedCap UE with one Rx branch, one downlink MIMO layer is supported. For a RedCap UE with two Rx branches, two downlink MIMO layers are supported.

[0011] Another feature is the relaxed maximum modulation order. For FR1 RedCap UEs, support for 256QAM in the downlink is optional (instead of mandatory). No other relaxations of the maximum modulation order are specified for RedCap UEs.

[0012] Another feature is the duplex operation. A type A of half-duplex frequency division duplex (HD-FDD) with minimal specification impact (note that full-duplex FDD (FD-FDD) and time division duplex (TDD) are also supported).

[0013] In Release 18, further UE complexity reduction has been studied to further expand the market for RedCap use cases with relatively low cost, low power consumption, and low data rate requirements, followed by related work items. Potential Release 18 enhancements can be referred to as enhanced RedCap (eRedCap). The terms "Release 18 RedCap UE" and "eRedCap UE" can be used interchangeably in this document.

[0014] The fifth-generation (5G) network aims to accelerate industrial transformation and digitization, which improves flexibility, increases productivity and efficiency, reduces maintenance, and enhances operational safety. Industrial sensors play an important role in realizing this vision. Industrial sensors are not only widely used in industrial automation and digitization use cases but also in general environmental monitoring use cases, such as monitoring critical infrastructure (e.g., buildings, bridges, dams, etc.) or monitoring natural disasters (e.g., wildfires, floods, tsunamis, earthquakes, etc.). Another emerging new 5G use case is the smart city vertical, which covers data collection and processing to more effectively monitor and control urban resources and provide services to urban residents. In particular, the deployment of surveillance cameras is an important part of smart cities and also of factories and industries. In addition, there is a growing interest in wearable use cases such as smartwatches, electronic health-related devices, and medical monitoring devices. Compared with eMBB devices, these use cases require different design considerations and have different requirements in terms of form factor, UE complexity, and energy efficiency.

[0015] The support for industrial sensors, video surveillance, and wearable devices is the motivation behind Release 17 RedCap. Through the Release 17 NR RedCap work item, 3GPP has established a framework for implementing NR devices with reduced capabilities suitable for a range of use cases, including industrial sensor, video surveillance, and wearable device use cases, which require low UE complexity and sometimes also low UE power consumption.

[0016] To further expand the market for RedCap use cases with relatively low cost, low power consumption, and low data rate requirements, such as industrial wireless sensor network use cases, some further complexity reduction enhancements should be considered. Release 18 RedCap should provide NR support for the capabilities of low-layer devices among existing LPWA UEs and Release 17 RedCap UEs. The peak data rate supported by Release 18 RedCap targets 10 Mbps.

[0017] The objectives of the 3GPP Release 18 RedCap research project are as follows (RP-213661, "New SID on Study on further NR RedCap UE complexity reduction", Ericsson, 3GPP TSG RAN#94e, December 2021). One objective is further UE complexity reduction techniques based on the Release 17 evaluation method in TR 38.875.

[0018] One objective is to consider network impacts, coexistence of Release 17 and Release 18 RedCap and non-RedCap UEs in the cell, UE impacts, and specification impacts. Potential solutions for reducing device complexity that can complement each other focus on: (a) reducing the UE bandwidth in FR1 to 5 MHz, possibly combined with a relaxed UE processing timeline for the Physical Downlink Shared Channel (PDSCH) and / or Physical Uplink Shared Channel (PUSCH) and / or Channel State Information (CSI); and (b) reducing the UE peak data rate in FR1, which may include restricted bandwidth for the PDSCH and / or PUSCH and may be combined with a relaxed UE processing timeline for the PDSCH and / or PUSCH and / or CSI.

[0019] The results of the study are documented in the technical report TR 38.865, V18.0.0, "Study on further NR RedCap UE complexity reduction (Release 18)" in September 2022. After this research project, the corresponding work item was approved RP-222675, "New WID on enhanced support of reduced-capability NR devices", Ericsson, 3GPP TSG RAN#97e, September 2022, which has the following objectives regarding complexity / cost reduction.

[0020] One objective is to reduce the UE baseband (BB) bandwidth. The 5 MHz BB bandwidth is only used for the PDSCH (for both unicast and broadcast) and PUSCH, while the 20 MHz radio frequency (RF) bandwidth is used for both uplink and downlink. Other physical channels and signals are still allowed to use bandwidth parts (BWPs) not exceeding the 20 MHz maximum UE RF+BB bandwidth.

[0021] Another objective is to reduce the UE peak data rate, including relaxation of the constraint (vLayers·Qm·f≥4) for peak data rate reduction. The relaxed constraint is, for example, 1 (instead of 4). The parameters (vLayers, Qm, f) can be as in Release 17 RedCap.

[0022] Both 15 kHz subcarrier spacing (SCS) and 30 kHz SCS are supported.

[0023] Another objective is to define at most one Release 18 RedCap UE type for further UE complexity reduction.

[0024] Use the existing UE capability framework and specify changes to the capability signaling only when necessary. By default, all UE capabilities applicable to Release 17 RedCap UEs are applicable unless otherwise specified.

[0025] Figure 1 An example of UE baseband bandwidth reduction for the data channel (e.g., baseband bandwidth reduction for Release 18e RedCap) is shown. As shown, the size of the BWP can be no more than 20 MHz, but data transmission / reception / processing (both uplink and downlink) is limited to a 5 MHz continuous bandwidth. The location of the 5 MHz BB bandwidth for data can be anywhere within the 20 MHz RF bandwidth.

[0026] The following conventions can be found in R1-2210637 “RAN1 agreements for Rel-18 NR RedCap”, reporter (Ericsson), 3GPP TSG RAN WG1 meeting #110bis-e, October 2022.

[0027] For UE BB bandwidth reduction, for PUSCH, if applicable, screen between the following options for the maximum number of physical resource blocks (PRBs) that can be transmitted per UE time slot or per hop: ● Option 1: 28 PRBs for 15 kHz SCS and 14 PRBs for 30 kHz SCS ● Option 2: 27 PRBs for 15 kHz SCS and 13 PRBs for 30 kHz SCS ● Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS ● Option 4: 25 PRBs for 15 kHz SCS and 11 PRBs for 30 kHz SCS

[0028] For UE BB bandwidth reduction, for PDSCH (at least for unicast), screening is performed between the following options for the maximum number of PRBs that a UE can process per time slot: ● Option 1: 28 PRBs for 15 kHz SCS and 14 PRBs for 30 kHz SCS ● Option 2: 27 PRBs for 15 kHz SCS and 13 PRBs for 30 kHz SCS ● Option 3: 25 PRBs for 15 kHz SCS and 12 PRBs for 30 kHz SCS ● Option 4: 25 PRBs for 15 kHz SCS and 11 PRBs for 30 kHz SCS

[0029] The same option will be selected for both PDSCH (at least for unicast) and PUSCH.

[0030] For UE BB bandwidth reduction, for System Information Block 1 (SIB1) (PDSCH), scheduling of SIB1 is allowed to be greater than 5 MHz (as in traditional operation).

[0031] For UE BB bandwidth reduction, for broadcasting Other System Information (OSI) (PDSCH), scheduling of broadcasting OSI (PDSCH) is allowed to be greater than 5 MHz (as in traditional operation).

[0032] For UE BB bandwidth reduction, for the paging channel (PDSCH) to Release 18 RedCap UEs, screening is performed between the following options: ● Option 1: Limit the scheduling of the paging channel within 5 MHz. ● Option 2: Allow the scheduling of the paging channel to be greater than 5 MHz (as in traditional operation).

[0033] For UE BB bandwidth reduction, for the Random Access Response (RAR) (PDSCH) to Release 18 RedCap UEs, screening is performed between the following options: ● Option 1: Limit the scheduling of the RAR PDSCH within 5 MHz. ● Option 2: Allow the scheduling of the RAR PDSCH to be greater than 5 MHz (as in traditional operation).

[0034] For UE BB bandwidth reduction, if applicable, it is not expected that the UE receives an uplink grant in the Downlink Control Information (DCI), where the PUSCH resource allocation spans a bandwidth greater than ~5 MHz per time slot or per hop.

[0035] For UE BB bandwidth reduction, if applicable, the UE is not expected to be configured with configured grant (CG) where the PUSCH resource allocation spans a bandwidth greater than ~5 MHz per time slot or per hop.

[0036] There are currently some challenges. For example, the reduced capabilities associated with Release 18 RedCap UEs may need to be addressed by the network and / or Release 18 RedCap UEs, as Release 18 RedCap UEs may not be able to match the performance that can be expected from full-capability UEs. New ways to solve this problem are desired. Summary of the Invention

[0037] As described above, there are currently some challenges in the context of reduced-capability (RedCap) user equipment (UE).

[0038] Certain aspects of the present disclosure and their embodiments can provide solutions to these or other challenges. For example, certain embodiments include various processes by which Release 18 RedCap UEs with a 5 MHz baseband bandwidth for data channels (Physical Downlink Shared Channel (PDSCH) and Physical Uplink Shared Channel (PUSCH)) handle broadcast PDSCHs (e.g., paging and Random Access Response (RAR)) greater than 5 MHz.

[0039] According to some embodiments, a method is performed by a RedCap wireless device. The method includes: receiving a PDSCH that includes scheduling for an uplink transmission; determining whether a duration between receiving the PDSCH and a start of the scheduled uplink transmission is greater than a threshold; and transmitting the scheduled uplink transmission based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is greater than the threshold. The threshold depends on whether the PDSCH is received in a bandwidth greater than a reduced bandwidth associated with the RedCap wireless device.

[0040] In certain embodiments, the method further includes: not transmitting the scheduled uplink transmission based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold.

[0041] In certain embodiments, the reduced bandwidth is a reduced baseband bandwidth associated with the RedCap wireless device.

[0042] In certain embodiments, a difference between a value applied to the threshold when the PDSCH is received in a bandwidth greater than the reduced bandwidth and a value applied to the threshold when the PDSCH is received in a bandwidth not greater than the reduced bandwidth depends on a subcarrier spacing.

[0043] In a particular embodiment, the PDSCH includes a broadcast PDSCH (e.g., RAR).

[0044] In a particular embodiment, based on determining that a duration between receiving the PDSCH and a start of a scheduled uplink transmission is not greater than a threshold, the method includes retransmitting a physical random access channel PRACH.

[0045] According to some embodiments, a wireless device includes processing circuitry operable to perform any of the wireless device methods described above.

[0046] A computer program product is also disclosed, including a non-transitory computer-readable medium storing computer-readable program code that, when executed by the processing circuitry, is operable to perform any of the methods performed by the wireless device described above.

[0047] According to some embodiments, a method performed by a network node includes transmitting a PDSCH to a RedCap wireless device. The PDSCH includes scheduling for an uplink transmission. When a duration between when the wireless device receives the PDSCH and a start of the scheduled uplink transmission is greater than the threshold, the method further includes receiving the scheduled uplink transmission from the wireless device. The threshold depends on whether the PDSCH is transmitted in a bandwidth larger than a reduced bandwidth associated with the RedCap wireless device.

[0048] In a particular embodiment, when the duration between when the wireless device receives the PDSCH and a start of the scheduled uplink transmission is not greater than the threshold, the method further includes not receiving the scheduled uplink transmission from the wireless device.

[0049] In a particular embodiment, when the duration between when the wireless device receives the PDSCH and a start of the scheduled uplink transmission is not greater than the threshold, the method may further include receiving a retransmission of the PRACH from the wireless device.

[0050] According to some embodiments, a network node includes processing circuitry operable to perform any of the network node methods described above.

[0051] Another computer program product includes a non-transitory computer-readable medium storing computer-readable program code that, when executed by the processing circuitry, is operable to perform any of the methods performed by the network node described above.

[0052] Some embodiments may provide one or more of the following technical advantages. For example, certain embodiments facilitate scheduling the broadcast PDSCH to be greater than 5 MHz (as in conventional operations), and thus the same broadcast PDSCH can be shared between eRedCap UEs and non-eRedCap UEs. This in turn results in better scheduling flexibility, lower network overhead, and lower network power consumption. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The present disclosure may be best understood by reference to the following description and the drawings used to illustrate embodiments of the present disclosure. In the drawings:

[0054] Figure 1 An example of reduced UE baseband bandwidth for a data channel is shown;

[0055] Figure 2 An example of a communication system according to a particular embodiment is shown;

[0056] Figure 3 A user equipment (UE) according to a particular embodiment is shown;

[0057] Figure 4 A network node according to a particular embodiment is shown;

[0058] Figure 5 is a block diagram of a host according to a particular embodiment;

[0059] Figure 6 is a block diagram of a virtualization environment showing where functions implemented by some embodiments may be virtualized;

[0060] Figure 7 A communication diagram of a host communicating with a UE via a partial wireless connection through a network node according to some embodiments is shown;

[0061] Figure 8 is a flowchart showing an example method in a wireless device according to a particular embodiment; and

[0062] Figure 9 is a flowchart showing an example method in a network node according to a particular embodiment. DETAILED DESCRIPTION

[0063] As mentioned above, there are currently some challenges in the context of reduced-capability (RedCap) user equipment (UE). For example, current New Radio (NR) specifications allow the PDSCH carrying the random access response (RAR) in Msg2 to be scheduled with a frequency resource allocation greater than 5 MHz. As mentioned above, for Release 18 RedCap UEs with a reduced UE baseband bandwidth to 5 MHz, 3GPP is currently considering the following options for scheduling the RAR (PDSCH):

[0064] Option 1: Limit the scheduling of RAR within 5 MHz.

[0065] Option 2: Allow the scheduling of RAR to be greater than 5 MHz (as in traditional operations).

[0066] For Option 1, the early indication for Release 18 RedCap UEs in Msg1 should be configured (so that RAR can be scheduled within 5 MHz specifically for these UEs), or the network also needs to schedule RAR for other types of UEs within 5 MHz. In the latter case, although the early indication can be avoided, the ability to multiplex multiple RARs for different UEs in the same Msg2 may be negatively affected.

[0067] For Option 2, the early indication for Release 18 RedCap UEs may not be required. In addition, the network does not need to schedule RAR within 5 MHz to handle Release 18 RedCap UEs in the cell. However, with Option 2, although the UE can receive and buffer RARs of up to 20 MHz, the UE may only be able to handle 5 MHz per time slot. Therefore, the PUSCH time resource allocation for Msg3 in the uplink grant in the RAR should consider the minimum time between the last symbol of the RAR message with the uplink grant and the first symbol of the corresponding PUSCH transmission. In the existing specification, the minimum time is equal to N T,1 + N T,2 + 0.5 ms, where N T,1 is the duration of N 1 symbols corresponding to the PDSCH processing time for UE processing capability 1 when additional PDSCH demodulation reference signals (DMRS) are configured, and N T,2 is the duration of N 2 symbols corresponding to the PUSCH preparation time for UE processing capability 1 (TS 38.213, 17.3.0, "NR; Physical layer procedures for control (NR; Physicallayer procedure for control)", September 2022). Additionally, it is expected that the PUSCH frequency resource allocation in the uplink grant in the RAR does not exceed 5 MHz (per hop).

[0068] For Option 2, when a Release 18 RedCap UE receives an uplink grant in the RAR that does not match the RedCap UE capabilities, it is not clear how the Release 18 RedCap UE should handle the RAR.

[0069] The existing NR specification allows the PDSCH carrying the paging channel to be scheduled using a frequency resource allocation greater than 5 MHz. As described above, for the Release 18 RedCap UE with the UE baseband bandwidth reduced to 5 MHz, 3GPP is currently considering the following options for the scheduling of the paging channel (PDSCH):

[0070] Option 1: Limit the scheduling of the paging channel within 5 MHz.

[0071] Option 2: Allow the scheduling of the paging channel to be greater than 5 MHz (as in traditional operations).

[0072] For Option 1, the paging channel needs to be transmitted, especially to the Release 18 RedCap UE, using, for example, a separate physical downlink control channel (PDCCH) search space compared to the Type 2-PDCCH common search space (CSS), using a separate paging radio network temporary identifier (P-RNTI) to scramble the DCI containing the paging scheduling information, etc.), or the network needs to also schedule the paging channel within 5 MHz for other types of UEs. In the latter case, the ability to multiplex the paging records of different UEs in the same paging message may be negatively affected.

[0073] For Option 2, the network does not need to impose scheduling restrictions on paging to handle the Release 18 RedCap UE in the cell. However, with Option 2, although the UE can receive and buffer paging of no more than 20 MHz, the UE may only be able to handle 5 MHz per time slot.

[0074] For Option 2, when the Release 18 RedCap UE receives a DL allocation in the paging DCI that does not match the RedCap UE capabilities, it is not clear how the Release 18 RedCap UE should handle the paging channel.

[0075] Certain aspects and embodiments of the present disclosure may provide solutions to these challenges or other challenges. For example, certain embodiments include various processes by which a Release 18 RedCap UE with a 5 MHz baseband bandwidth for data channels (PDSCH and physical uplink shared channel (PUSCH)) processes a broadcast PDSCH greater than 5 MHz (e.g., paging and random access response (RAR)).

[0076] Certain embodiments are described more fully with reference to the accompanying drawings. The embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0077] Some embodiments include UE procedures for receiving RAR (PDSCH). In one embodiment, when receiving a PDSCH that conveys a RAR message with a RAR uplink grant, a Release 18 RedCap UE may apply the following procedure. If the frequency resource allocation for the PDSCH is greater than 5 MHz, and if the time resource allocation for the corresponding PUSCH transmission scheduled by the RAR uplink grant is such that the time between the last symbol of the PDSCH and the first symbol of the corresponding PUSCH is less than N T,1 +M T +N T,2 + 0.5 milliseconds, where N T,1 and N T,1 are defined in clause 8.4 of TS 38.213, and M T is defined later in this section, or if the frequency resource allocation for the corresponding PUSCH transmission scheduled by the RAR uplink grant exceeds 5 MHz, the UE shall not (or is not expected to) transmit the corresponding PUSCH, and if requested by a layer higher than the physical layer, the UE shall re-transmit the physical random access channel (PRACH). Otherwise, the UE shall apply the procedure described in clause 8 of TS 38.213 to the corresponding PUSCH transmission.

[0078] If the scheduled bandwidth of the PDSCH is greater than 5 MHz, the parameter M T is a duration in symbols or slots or milliseconds corresponding to the additional PDSCH processing time required for the Release 18 RedCap UE to process the PDSCH. Some non-limiting examples of M T are provided below.

[0079] When the scheduled bandwidth of the PDSCH is within 5 MHz, M T = 0. For this case, if further relaxation is needed, M T = s may also be supported, where s > 0 is the number of orthogonal frequency division multiplexing (OFDM) symbols (alternatively, ms or slots).

[0080] When the scheduled bandwidth of the PDSCH is greater than 5 MHz, the value of M T can be fixed (e.g., 2 slots) or can depend on the bandwidth of the PDSCH, e.g., as follows: <![CDATA[M T (time slot)]]> Scheduled Bandwidth of RAR PDSCH 0 <5MHz 1 5MHz - 10MHz 2 10MHz - 15MHz 3 >15MHz

[0081] M T The value of can be composed of M T,1 and M T,2 , i.e., M T = M T,1 + M T,2, where M T,1 is a fixed value, and M T,2 varies according to the scheduled bandwidth of the PDSCH carrying the RAR. In an alternative embodiment, a scaling factor R is applied to adjust the time between the last symbol of the PDSCH for a Release 18 RedCap UE and the first symbol of the corresponding PUSCH. For example, this condition can be based on [R × N T,1 + N T,2 + 0.5] milliseconds, where R can be fixed or depend on the scheduled bandwidth of the RAR PDSCH.

[0082] In another embodiment, based on the maximum scheduled bandwidth of the legacy RAR PDSCH (i.e., based on one extended parameter corresponding to the worst case for the maximum RAR PDSCH bandwidth), the minimum time between the last symbol of the PDSCH and the first symbol of the corresponding uplink is extended.

[0083] The new parameters (M T , M T,1 and / or M T,2 and R) defined above can depend on the subcarrier spacing (SCS) configuration of the PDSCH carrying the RAR and / or the SCS configuration of the corresponding PUSCH transmission scheduled by the RAR uplink grant, as well as the carrier frequency (e.g., frequency range 1 and frequency range 2).

[0084] Based on the above process, if a Release 18 RedCap UE retransmits a PRACH, the Release 18 RedCap UE does not apply the power ramping configuration within the information element (IE) RACH-ConfigGeneric. Alternatively, there may be an indication in the system information (SI) that is used to indicate to the Release 18 RedCap UE whether the same power ramping configuration within the IE RACH-ConfigGeneric applies to the above process. This indication can be implicit or explicit. For example, the absence of this indication in the SI is used to indicate to the UE that the same power ramping configuration applies.

[0085] In another embodiment, whenever a cell supports a Release 18e RedCap UE (i.e., the access barring bit for Release 18e RedCap is not set and the Release 18e RedCap configuration is provided in the SI), the minimum time of N T,1 + N T,2 + 0.5 milliseconds for Msg3 transmission is extended by a slot. Here BW RARis the transmission bandwidth of the RAR, and reasonably, in addition to the traditional time offset (including processing delay, etc.), the eRedCap UE requires an additional time slot every 5 MHz, and the RAR transmission bandwidth exceeds 5 MHz (since it can also handle 5 MHz / slot). In this case, the network needs to apply new restrictions on the uplink scheduling at the time of Msg3, but the UE behavior is not affected.

[0086] When the minimum time required between the last symbol of the PDSCH carrying the RAR uplink grant and the first symbol of the corresponding PUSCH scheduled by the RAR uplink grant is extended (as described in the previous embodiments), the scheduler may not be able to rely on the existing PUSCH time-domain resource allocation options.

[0087] In the current specification, if the UE receives a PDSCH of a RAR message with the end in time slot n, the UE will be scheduled to transmit the corresponding PUSCH in time slot n + k2 + Δ, where k2 is the time slot offset indicated by the PUSCH time-domain resource allocation field in the RAR uplink grant, and Δ is the additional time slot offset defined per SCS configuration of the PUSCH.

[0088] In one embodiment, when the PDSCH carrying the RAR message with the RAR uplink grant is transmitted using a frequency resource allocation greater than 5 MHz, the time line for the corresponding PUSCH transmission is determined as a function of the new time slot offset ΔM. In one example, if the UE receives a PDSCH of a RAR message with a frequency resource allocation greater than 5 MHz with the end in time slot n, the UE transmits the corresponding PUSCH in time slot n + k2 + Δ + ΔM, where k2 and Δ are based on the existing definitions, and ΔM is the new time slot offset defined in the specification. The value of ΔM can be fixed in the specification and depends on the subcarrier spacing configuration of the PUSCH. Alternatively, the value of ΔM can depend on the scheduled bandwidth of the PDSCH carrying the RAR and the subcarrier spacing configuration of the PUSCH.

[0089] Some embodiments include UE procedures for receiving paging (PDSCH). In one embodiment, when receiving a PDCCH with DCI scrambled with a paging radio network temporary identifier (P-RNTI) in a paging occasion, the Release 18 RedCap UE can apply the following procedure.

[0090] If the frequency resource allocation for the PDSCH scheduled by the DCI is greater than 5 MHz, the UE should not (or is not expected to) decode the corresponding PDSCH and, if applicable, continue to monitor paging in the next paging occasion.

[0091] Certain embodiments are applicable to both Frequency Range 1 (FR1) and Frequency Range 2 (FR2) as well as different UE bandwidth capabilities. Generally, the UE maximum radio frequency (RF) bandwidth can be X MHz, the UE baseband bandwidth can be Y MHz, and the legacy RAR / paging PDSCH bandwidth can be Z MHz. The above embodiments and new parameters can be a function of the values X, Y, and Z. An example of the [X, Y, Z] values in FR2 that can be considered for Release 18 RedCap is: X = 100 MHz UE RF bandwidth, Y = 20 MHz UE baseband bandwidth, and for RAR / paging PDSCH, the bandwidth Z = 69.12 MHz.

[0092] Figure 2 An example of a communication system 100 according to some embodiments is shown. In this example, the communication system 100 includes a telecommunications network 102, which includes an access network 104 such as a radio access network (RAN) and a core network 106 that includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which can be generally referred to as network nodes 110), or any other similar 3rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 110 facilitate the direct or indirect connection of user equipment (UE), such as connecting UEs 112a, 112b, 112c, and 112d (one or more of which can be generally referred to as UEs 112) to the core network 106 via one or more wireless connections.

[0093] Example wireless communications via a wireless connection include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without using wires, cables, or other material conductors. Additionally, in different embodiments, the communication system 100 can include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals via wired or wireless connections. The communication system 100 can include any type of communication, telecommunications, data, cellular, radio network, and / or other similar types of systems and / or interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar types of systems.

[0094] The UE 112 can be any of a variety of communication devices, including a wireless device arranged to, configured to, and / or operable to communicate wirelessly with the network node 110 and other communication devices. Similarly, the network node 110 is arranged to, capable of, configured to, and / or operable to communicate directly or indirectly with the UE 112 and / or with other network nodes or devices in the telecommunication network 102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as management in the telecommunication network 102.

[0095] In the depicted example, the core network 106 connects the network node 110 to one or more hosts, such as host 116. These connections can be direct or indirect via one or more intermediate networks or devices. In other examples, the network node can be directly coupled to the host. The core network 106 includes one or more core network nodes (e.g., core network node 108) constructed with hardware components and software components. The characteristics of these components can be substantially similar to those described with respect to the UE, network node, and / or host, such that their description generally applies to the corresponding components of the core network node 108. Example core network nodes include functions of one or more of a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier de-confliction function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF), and / or a user plane function (UPF).

[0096] The host 116 can be under the ownership or control of a service provider other than the operator or provider of the access network 104 and / or the telecommunication network 102, and can be operated by or on behalf of the service provider. The host 116 can host various applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services (such as retrieving and compiling data on various environmental conditions detected by multiple UEs), analysis functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.

[0097] As a whole, Figure 2The communication system 100 enables connections between UEs, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures (such as specific standards), including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards or any applicable next-generation standards (e.g., 6G); Wireless Local Area Network (WLAN) standards such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-wave, Near Field Communication (NFC), ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards such as LoRa and Sigfox.

[0098] In some examples, the telecommunications network 102 is a cellular network that implements 3GPP standardized features. Thus, the telecommunications network 102 can support network slicing to provide different logical networks to different devices connected to the telecommunications network 102. For example, the telecommunications network 102 can provide ultra-reliable low-latency communication (URLLC) services to some UEs, while providing enhanced mobile broadband (eMBB) services to other UEs, and / or providing massive machine type communication (mMTC) / massive IoT services to additional UEs.

[0099] In some examples, the UE 112 is configured to send and / or receive information without direct human interaction. For example, the UE can be designed to transmit information to the access network 104 at a predefined schedule when triggered by an internal or external event or in response to a request from the access network 104. Additionally, the UE can be configured to operate in single-RAT or multi-RAT or multi-standard modes. For example, the UE can operate with any one or combination of Wi-Fi, NR (New Radio), and LTE, i.e., be configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

[0100] In this example, the hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE 112c and / or UE 112d) and a network node (e.g., network node 110b). In some examples, the hub 114 can be a controller, router, content source and analyzer, or any other communication device described herein with respect to the UE. For example, the hub 114 can be a broadband router that allows the UE to access the core network 106. As another example, the hub 114 can be a controller that sends commands or instructions to one or more actuators in the UE. Commands or instructions can be received from the UE, network node 110, or through executable code, scripts, procedures, or other instructions in the hub 114. As another example, the hub 114 can be a data collector that acts as a temporary storage for UE data and, in some embodiments, can perform analysis or other processing of the data. As another example, the hub 114 can be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, the hub 114 can retrieve VR assets, videos, audio, or other media or data related to sensory information via the network node, and then the hub 114 directly provides the VR assets, videos, audio, or other media or data to the UE after performing local processing and / or after adding additional local content. In yet another example, the hub 114 acts as a proxy server or coordinator for the UE, particularly in cases where one or more UEs are low-energy IoT devices.

[0101] The hub 114 can have a constant / persistent or intermittent connection to the network node 110b. The hub 114 can also allow for different communication schemes and / or scheduling between the hub 114 and the UE (e.g., UE 112c and / or UE 112d) and between the hub 114 and the core network 106. In other examples, the hub 114 is connected to the core network 106 and / or one or more UEs via a wired connection. Additionally, the hub 114 can be configured to be connected to an M2M service provider via the access network 104 and / or to another UE via a direct connection. In some scenarios, the UE can establish a wireless connection with the network node 110 while still being connected via the hub 114 via a wired or wireless connection. In some embodiments, the hub 114 can be a dedicated hub, i.e., its primary function is to route communications to / from the UE to / from the network node 110b. In other embodiments, the hub 114 can be a non-dedicated hub, i.e., a device capable of operating to route communications between the UE and the network node 110b, but that can also operate as a communication origin and / or destination for certain data channels.

[0102] Figure 3FIG. 0 shows a UE 200 according to some embodiments. As used herein, a UE refers to a device capable of, configured to, arranged to, and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of UEs include, but are not limited to, smart phones, mobile phones, cellular phones, Internet Protocol voice (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, gaming consoles or devices, music storage devices, playback appliances, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premise equipment (CPEs), in-vehicle or vehicle embedded / integrated wireless devices, etc. Other examples include any UE identified by the Third Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine type communication (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0103] The UE may support device-to-device (D2D) communication, such as by implementing 3GPP standards for sidelink communication, dedicated short range communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the UE may not necessarily have a user in the sense of a human user owning and / or operating the associated device. Instead, the UE may represent a device intended to be sold to or operated by a human user but that may not be associated with or initially associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, the UE may represent a device not intended to be sold to or operated by an end user but that may be associated with or operate in the interest of a user (e.g., a smart meter).

[0104] The UE 200 includes processing circuitry 202, which is operably coupled via a bus 204 to an input / output interface 206, a power supply 208, a memory 210, a communication interface 212, and / or any other components or any combination thereof. Certain UEs may utilize Figure 2 all or a subset of the components shown. The level of integration between components may vary from one UE to another. Additionally, certain UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0105] The processing circuitry 202 is configured to process instructions and data and may be configured to implement any sequential state machine operable to execute instructions stored as a machine-readable computer program in the memory 210. The processing circuitry 202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, a field programmable gate array (FPGA), an application specific integrated circuit system (ASIC), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, a general purpose processor (such as a microprocessor or a digital signal processor (DSP)) together with appropriate software; or any combination of the above. For example, the processing circuitry 202 may include multiple central processing units (CPUs).

[0106] In this example, the input / output interface 206 may be configured to provide one or more interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, another output device, or any combination thereof. Input devices may allow a user to collect information into the UE 200. Examples of input devices include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a touchpad, a scroll wheel, a smart card, etc. A presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. The sensor may be, for example, an accelerometer, a gyroscope, an inclinometer, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. Output devices may use the same type of interface port as input devices. For example, a universal serial bus (USB) port may be used to provide input devices and output devices.

[0107] In some embodiments, the power supply 208 is configured as a battery or a battery pack. Other types of power supplies may be used, such as an external power supply (e.g., a power outlet), a photovoltaic device, or a battery. The power supply 208 may also include a power circuitry for delivering power from the power supply 208 itself and / or an external power supply to various parts of the UE 200 via an input circuitry or an interface such as a power cable. Delivering power may be, for example, for charging the power supply 208. The power circuitry may perform any formatting, conversion, or other modification of the power from the power supply 208 to make the power suitable for the corresponding components of the UE 200 to which the power is supplied.

[0108] Memory 210 may be or be configured to include a memory such as a random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), magnetic disk, optical disk, hard disk, removable cartridge, flash drive, etc. In one example, memory 210 includes one or more applications 214 (such as an operating system, a web browser application, a widget, a widget engine, or other applications) and corresponding data 216. Memory 210 may store any one or combination of various operating systems used by UE 200.

[0109] Memory 210 may be configured to include a plurality of physical drive units such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard drive, thumb drive, pen drive, key drive, high density digital versatile disc (HD-DVD) optical disc drive, internal hard drive, Blu-ray disc drive, holographic digital data storage (HDDS) optical disc drive, external micro dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro DIMM SDRAM, smart card memory (such as a tamper-resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs) such as USIM and / or ISIM), other memories, or any combination thereof. The UICC may be, for example, an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a "SIM card". Memory 210 may allow UE 200 to access instructions, applications, etc. stored on a transient memory medium or a non-transient memory medium to offload data or upload data. Such as an article of manufacture of a communication system may be tangibly embodied as or in memory 210, and memory 210 may be or include a device-readable storage medium.

[0110] Processing circuitry 202 may be configured to communicate with an access network or other network using communication interface 212. Communication interface 212 may include one or more communication subsystems and may include or be communicatively coupled to antenna 222. Communication interface 212 may include one or more transceivers for communication, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 218 and / or a receiver 220 adapted to provide network communication (e.g., optical, electrical, frequency allocation, etc.). Additionally, transmitter 218 and receiver 220 may be coupled to one or more antennas (e.g., antenna 222) and may share circuit components, software, or firmware, or alternatively be implemented separately.

[0111] In the illustrated embodiment, the communication functions of the communication interface 212 can include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication such as Bluetooth, near-field communication, location-based communication such as using the Global Positioning System (GPS) to determine location, another similar communication function, or any combination thereof. The communication can be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Synchronous Optical Network (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), etc.

[0112] Regardless of the type of sensor, the UE can provide an output of the data captured by the UE's sensors via a wireless connection to a network node through its communication interface 212. The data captured by the UE's sensors can be communicated to the network node via another UE through a wireless connection. The output can be periodic (e.g., every 15 minutes if it reports the sensed temperature), random (e.g., to equalize the load from reports from several sensors), in response to a trigger event (e.g., sending an alert when moisture is detected), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a real-time video feed of a patient).

[0113] As another example, the UE includes an actuator, a motor, or a switch associated with a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, motor, or switch can change. For example, the UE can include a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input, or adjusts a robotic arm performing a medical procedure according to the received input.

[0114] When in the form of an Internet of Things (IoT) device, the UE can be a device for use in one or more application domains, including but not limited to urban wearable technologies, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices are the following devices or devices embedded in the following: connected refrigerators or freezers, TVs, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / moisture sensors, electric door locks, connected doorbells, air conditioning systems (such as heat pumps), autonomous vehicles, monitoring systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smartwatches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for tactile or sensory enhancement, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any kind of medical device (such as a heart rate monitor or a remotely controlled surgical robot). In addition to the other components described with respect to Figure 2 the UE 200 shown, the UE in the form of an IoT device also includes circuitry and / or software depending on the intended application of the IoT device.

[0115] As yet another specific example, in an IoT scenario, the UE can represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another UE and / or network node. In this case, the UE can be an M2M device, which can be referred to as an MTC device in the 3GPP context. As a specific example, the UE can implement the 3GPP NB-IoT standard. In other scenarios, the UE can represent a means of transportation, such as a car, bus, truck, ship, and airplane, or other equipment capable of monitoring and / or reporting its operating state or other functions associated with its operation.

[0116] In fact, any number of UEs can be used together with respect to a single use case. For example, a first UE can be a drone or integrated in a drone and provide speed information of the drone (obtained via a speed sensor) to a second UE that is a remote controller for operating the drone. When the user makes a change from the remote controller, the first UE can adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the speed of the drone. The first UE and / or the second UE can also include more than one of the above functions. For example, the UE can include sensors and actuators and process data communication for both the speed sensor and the actuator.

[0117] Figure 4FIG. 300 shows a network node according to some embodiments. As used herein, a network node refers to a device capable of, configured to, arranged to, and / or operable to communicate directly or indirectly with a UE and / or other network nodes or devices in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, NodeBs, evolved NodeBs (eNBs), and NR NodeBs (gNBs)).

[0118] Base stations can be classified based on the coverage they provide (or in other words, their transmission power levels), and thus depending on the coverage provided, a base station can be referred to as a femto base station, a pico base station, a micro base station, or a macro base station. A base station can be a relay node or a relay donor node controlling a relay. A network node can also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such a remote radio unit can be integrated with an antenna into an antenna integrated radio or can be not integrated with an antenna into an antenna integrated radio. Parts of a distributed radio base station can also be referred to as nodes in a distributed antenna system (DAS).

[0119] Other examples of network nodes include multi-transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) devices such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), operation and maintenance (O&M) nodes, operation support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., evolved serving mobile location center (E-SMLC)), and / or minimized drive test (MDT).

[0120] The network node 300 includes processing circuitry 302, a memory 304, a communication interface 306, and a power supply 308. The network node 300 can be composed of multiple physically separated components (e.g., a NodeB component and an RNC component, or a BTS component and a BSC component, etc.), and each component can have its respective components. In some scenarios where the network node 300 includes multiple separated components (e.g., a BTS component and a BSC component), one or more of the separated components can be shared among several network nodes. For example, a single RNC can control multiple NodeBs. In such scenarios, each unique NodeB and RNC pair can be considered as a single separated network node in some instances. In some embodiments, the network node 300 can be configured to support multiple radio access technologies (RATs). In such embodiments, some components (e.g., separate memories 304 for different RATs) can be replicated, and some components (e.g., the same antenna 310 can be shared by different RATs) can be reused. The network node 300 can also include multiple sets of various components shown for different wireless technologies (such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technology) integrated into the network node 300. These wireless technologies can be integrated into the same or different chips or chip sets and other components within the network node 300.

[0121] The processing circuitry 302 can include one or more combinations of a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application specific integrated circuit system, a field programmable gate array, or any other suitable computing device, resource, or a combination of hardware, software, and / or coded logic, which can operate alone or in combination with other components of the network node 300 (such as the memory 304) to provide the network node 300 functions.

[0122] In some embodiments, the processing circuitry 302 includes a system on a chip (SOC). In some embodiments, the processing circuitry 302 includes one or more of radio frequency (RF) transceiver circuitry 312 and baseband processing circuitry 314. In some embodiments, the radio frequency (RF) transceiver circuitry 312 and the baseband processing circuitry 314 can be on separate chips (or chip sets), boards, or units (such as a radio unit and a digital unit). In alternative embodiments, some or all of the RF transceiver circuitry 312 and the baseband processing circuitry 314 can be on the same chip or chip set, board, or unit.

[0123] Memory 304 may include any form of volatile or non-volatile computer-readable memory, including but not limited to persistent storage devices, solid-state memory, remotely installed memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disks), removable storage media (e.g., flash drives, compact discs (CDs) or digital video discs (DVDs)), and / or any other volatile or non-volatile, non-transitory device-readable and / or computer-executable memory device that stores information, data, and / or instructions that can be used by processing circuitry 302. Memory 304 may store any suitable instructions, data, or information, including computer programs, software, applications including one or more of logic, rules, code, tables, and / or other instructions that can be executed by processing circuitry 302 and utilized by network node 300. Memory 304 may be used to store any computations performed by processing circuitry 302 and / or any data received via communication interface 306. In some embodiments, processing circuitry 302 and memory 304 are integrated.

[0124] Communication interface 306 is for wired or wireless communication of signaling and / or data between network nodes, access networks, and / or UEs. As shown, communication interface 306 includes ports / terminals 316 for sending data to and receiving data from a network, for example, via a wired connection. Communication interface 306 also includes radio front-end circuitry 318, which may be coupled to antenna 310 or, in certain embodiments, to a portion of antenna 310. Radio front-end circuitry 318 includes filters 320 and amplifiers 322. Radio front-end circuitry 318 may be connected to antenna 310 and processing circuitry 302. The radio front-end circuitry may be configured to condition signals communicated between antenna 310 and processing circuitry 302. Radio front-end circuitry 318 may receive digital data to be transmitted to other network nodes or UEs via a wireless connection. Radio front-end circuitry 318 may convert the digital data into a radio signal with appropriate channel and bandwidth parameters using a combination of filters 320 and / or amplifiers 322. The radio signal may then be transmitted via antenna 310. Similarly, when receiving data, antenna 310 may collect radio signals, which are then converted into digital data by radio front-end circuitry 318. The digital data may be passed to processing circuitry 302. In other embodiments, the communication interface may include different components and / or different combinations of components.

[0125] In a particular alternative embodiment, the network node 300 does not include a separate radio front-end circuitry 318. Instead, the processing circuitry 302 includes the radio front-end circuitry and is connected to the antenna 310. Similarly, in some embodiments, all or some of the RF transceiver circuitry 312 is part of the communication interface 306. In other embodiments, the communication interface 306 includes one or more ports or terminals 316, the radio front-end circuitry 318, and the RF transceiver circuitry 312 as part of a radio unit (not shown), and the communication interface 306 communicates with a baseband processing circuitry 314 as part of a digital unit (not shown).

[0126] The antenna 310 may include one or more antennas or antenna arrays configured to transmit and / or receive wireless signals. The antenna 310 may be coupled to the radio front-end circuitry 318 and may be any type of antenna capable of wirelessly transmitting and receiving data and / or signals. In a particular embodiment, the antenna 310 is separate from the network node 300 and may be connected to the network node 300 via an interface or port.

[0127] The antenna 310, the communication interface 306, and / or the processing circuitry 302 may be configured to perform any of the receiving operations and / or particular acquisition operations described herein as being performed by the network node. Any information, data, and / or signals may be received from a UE, another network node, and / or any other network device. Similarly, the antenna 310, the communication interface 306, and / or the processing circuitry 302 may be configured to perform any of the transmission operations described herein as being performed by the network node. Any information, data, and / or signals may be sent to a UE, another network node, and / or any other network device.

[0128] The power supply 308 supplies power to the various components of the network node 300 in a form suitable for the respective components (e.g., at the voltage and current levels required for each respective component). The power supply 308 may also include or be coupled to a power management circuitry to power the components of the network node 300 to perform the functions described herein. For example, the network node 300 may be connected to an external power supply (e.g., a power grid, a power outlet) via an input circuitry or an interface such as a cable, and the external power supply powers the power circuitry of the power supply 308. As another example, the power supply 308 may include a power source in the form of a battery or a battery pack, which is connected to or integrated in the power circuitry. The battery may provide backup power if the external power supply fails.

[0129] Embodiments of the network node 300 may include in addition to Figure 4Additional components beyond those shown are used to provide functionality for specific aspects of the network node, including any functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 300 may include a user interface device to allow information to be input into network node 300 and to allow information to be output from network node 300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 300.

[0130] Figure 5 is a block diagram of host 400 according to various aspects described herein, and host 400 may be Figure 1 an embodiment of host 116. As used herein, host 400 may be or include various combinations of hardware and / or software, including standalone servers, blade servers, cloud-implemented servers, distributed servers, virtual machines, containers, or processing resources in a server farm. Host 400 may provide one or more services to one or more UEs.

[0131] Host 400 includes processing circuitry 402, which is operably coupled via bus 404 to input / output interface 406, network interface 408, power supply 410, and memory 412. Other components may be included in other embodiments. The characteristics of these components may be substantially similar to those described for the devices of the previous figures (such as FIGS. 10 and Figure 3 ), such that their description generally applies to the corresponding components of host 400.

[0132] The memory 412 may include one or more computer programs, which include one or more host applications 414 and data 416. The data 416 may include user data, e.g., data generated by the UE for the host 400 or data generated by the host 400 for the UE. Embodiments of the host 400 may utilize only a subset or all of the illustrated components. The host application 414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different categories, types, or implementations of the UE (e.g., mobile phone, desktop computer, wearable display system, head-up display system). The host application 414 may also provide user authentication and license checking and may periodically report health, routing, and content availability to a central node (such as a device in or on the edge of the core network). Thus, the host 400 may select and / or indicate different hosts for the over-the-top services for the UE. The main application 414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0133] Figure 6 FIG. is a block diagram showing a virtualization environment 500 in which functions implemented by some embodiments may be virtualized. In this context, virtualization means creating a virtual version of a device or equipment, which may include a virtualized hardware platform, storage devices, and network resources. As used herein, virtualization may be applied to any device or its components described herein and relates to an implementation in which at least a part of the functions are implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs), the one or more VMs being implemented in one or more virtualization environments 500 hosted by one or more hardware nodes (such as hardware computing devices operating as network nodes, UEs, core network nodes, or hosts). Additionally, in embodiments where the virtual node does not require a radio connection (e.g., core network node or host), then the node may be fully virtualized.

[0134] The application 502 (which may alternatively be referred to as a software instance, virtual device, network function, virtual node, virtual network function, etc.) runs in the virtualization environment Q400 to implement some features, functions, and / or benefits of some embodiments disclosed herein.

[0135] Hardware 504 includes processing circuitry, a memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interfaces, etc. The software may be executed by the processing circuitry to instantiate one or more virtualization layers 506 (also referred to as a hypervisor or virtual machine monitor (VMM)), provide VMs 508a and 508b (one or more of which may be generally referred to as VM 508), and / or perform any functions, features, and / or benefits described with respect to some embodiments described herein. The virtualization layer 506 may present a virtual operating platform that appears to network the hardware to the VMs 508.

[0136] The VMs 508 include virtual processing, virtual memory, virtual networking or interfaces, and virtual storage, and may be run by the corresponding virtualization layer 506. Different embodiments of instances of the virtual device 502 may be implemented on one or more of the VMs 508 and may be implemented in different ways. Virtualization of hardware is referred to as network function virtualization (NFV) in some contexts. NFV can be used to consolidate many network device types onto industry-standard high-volume server hardware, physical switches, and physical storage that can be located in data centers and customer premise equipment.

[0137] In the context of NFV, a VM 508 can be a software implementation of a physical machine that runs programs as if those programs were executing on a physical, non-virtualized machine. Each of the VMs 508 and the portion of the hardware 504 that executes that VM (which is the hardware dedicated to that VM and / or shared by that VM with other VMs in the VMs) form separate virtual network elements. Still in the context of NFV, the virtual network functions are responsible for handling specific network functions that run in one or more of the VMs 508 on top of the hardware 504 and correspond to the application 502.

[0138] The hardware 504 may be implemented in a stand-alone network node with general or specific components. Some functions of the hardware 504 may be implemented via virtualization. Alternatively, the hardware 504 may be part of a larger hardware cluster (e.g., such as in a data center or CPE), where many hardware nodes work together and are managed via management and orchestration 510, which in particular supervises the lifecycle management of the application 502. In some embodiments, the hardware 504 is coupled to one or more radio units, each radio unit including one or more transmitters and one or more receivers that may be coupled to one or more antennas. The radio units may communicate directly with other hardware nodes via one or more suitable network interfaces and may be used in combination with virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, a control system 512 may be used to provide some signaling, and the control system 512 may alternatively be used for communication between the hardware node and the radio unit.

[0139] Figure 7 A communication diagram of a host 602 communicating with a UE 606 via a network node 604 through a partial wireless connection according to some embodiments is shown. According to various embodiments, reference will now be made to Figure 6 describe the UE discussed in the previous paragraphs (such as Figure 2 UE 112a and / or Figure 2 UE 200), network nodes (such as Figure 2 network node 110a and / or Figure 3 network node 300), and hosts (such as Figure 2 host 116 and / or Figure 4 host 400) of example implementations.

[0140] Similar to host 400, embodiments of host 602 include hardware, such as a communication interface, processing circuitry, and memory. Host 602 also includes software stored in or accessible by host 602 and executable by the processing circuitry. The software includes a host application operable to provide services to remote users, such as UE 606 connected via an over-the-top (OTT) connection 650 extending between UE 606 and host 602. When providing services to remote users, the host application may provide user data transmitted using the OTT connection 650.

[0141] The network node 604 includes hardware enabling it to communicate with host 602 and UE 606. The connection 660 may be direct or through a core network (such as Figure 1 core network 106) and / or one or more other intermediate networks, such as one or more public networks, private networks, or hosted networks. For example, the intermediate network may be a backbone network or the Internet.

[0142] The UE 606 includes hardware and software that is stored in or accessible by the UE 606 and executable by the processing circuitry of the UE. The software includes client applications, such as a web browser or a carrier-specific “app”, that are operable to provide services to a human or non-human user via the UE 606 with the support of the host 602. In the host 602, the execution of the host application can communicate with the execution of the client application via the OTT connection 650 that terminates at the UE 606 and the host 602. When providing services to the user, the client application of the UE can receive request data from the host application of the host and provide user data in response to the request data. The OTT connection 650 can transmit both the request data and the user data. The client application of the UE can interact with the user to generate the user data that it provides to the host application via the OTT connection 650.

[0143] The OTT connection 650 can extend via the connection 660 between the host 602 and the network node 604 and via the wireless connection 670 between the network node 604 and the UE 606 to provide a connection between the host 602 and the UE 606. The connection 660 and the wireless connection 670 through which the OTT connection 650 can be provided have been drawn abstractly to show the communication between the host 602 and the UE 606 via the network node 604 without explicitly referring to any intermediate devices and the exact routing of the messages via these devices.

[0144] As an example of transmitting data via the OTT connection 650, in step 608, the host 602 provides user data, which can be performed by executing the host application. In some embodiments, the user data is associated with a specific human user interacting with the UE 606. In other embodiments, the user data is associated with the UE 606, and the UE 606 shares data with the host 602 without explicit human interaction. In step 610, the host 602 initiates the transmission of the user data carried. The host 602 can initiate the transmission in response to a request transmitted by the UE 606. The request can be caused by a human interaction with the UE 606 or by the operation of the client application executing on the UE 606. According to the teachings of the embodiments described throughout this disclosure, the transmission can be relayed via the network node 604. Thus, according to the teachings of the embodiments described throughout this disclosure, in step 612, the network node 604 transmits the user data carried in the transmission initiated by the host 602 to the UE 606. In step 614, the UE 606 receives the user data carried in the transmission, which can be performed by the client application executing on the UE 606 that is associated with the host application executed by the host 602.

[0145] In some examples, the UE 606 executes a client application that provides user data to the host 602. The user data can be provided in response to data received from the host 602. Thus, in step 616, the UE 606 can provide the user data, which can be performed by executing the client application. When providing the user data, the client application can also consider user input received from the user via the input / output interface of the UE 606. Regardless of the specific manner of providing the user data, the UE 606 initiates, in step 618, the transmission of the user data to the host 602 via the network node 604. In step 620, according to the teachings of the embodiments described throughout this disclosure, the network node 604 receives the user data from the UE 606 and initiates the transmission of the received user data to the host 602. In step 622, the host 602 receives the user data carried in the transmission initiated by the UE 606.

[0146] One or more of the various embodiments improve the performance of the OTT services provided to the UE 606 using the OTT connection 650, where the wireless connection 670 forms the last leg. More precisely, the teachings of these embodiments can increase the data rate and reduce the latency, thereby providing benefits such as reduced user wait time, better responsiveness, and better QoE.

[0147] In an example scenario, the host 602 can collect and analyze factory status information. As another example, the host 602 can process audio and video data that may have been retrieved from the UE for map creation. As another example, the host 602 can collect and analyze real-time data to help control vehicle congestion (e.g., control traffic lights). As another example, the host 602 can store the surveillance video uploaded by the UE. As another example, the host 602 can store or control access to media content (such as video, audio, VR, or AR that can be broadcast, multicast, or unicast to the UE). As other examples, the host 602 can be used for energy pricing, remotely controlling non-time-critical electrical loads to balance power generation demand, location services, presentation services (such as compiling a map from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing, and / or transmitting data.

[0148] In some examples, a measurement process can be provided for the purpose of monitoring data rate, latency, and other factors for one or more embodiment improvements. There can also be optional network functions for reconfiguring the OTT connection 650 between the host 602 and the UE 606 in response to changes in the measurement results. The measurement process and / or the network functions for reconfiguring the OTT connection can be implemented in the software and hardware of the host 602 and / or the UE 606. In some embodiments, sensors (not shown) can be deployed in or associated with other devices through which the OTT connection 650 passes; the sensors can participate in the measurement process by providing values of the monitored quantities illustrated above, or by providing values of other physical quantities from which the software can calculate or estimate the monitored quantities. The reconfiguration of the OTT connection 650 can include message format, retransmission settings, preferred routing, etc.; the reconfiguration does not need to directly change the operation of the network node 604. Such processes and functions can be known and practiced in the art. In a particular embodiment, the measurement can involve proprietary UE signaling that facilitates the host 602's measurement of throughput, propagation time, latency, etc. The measurement can be implemented in software that uses the OTT connection 650 to transmit messages, particularly empty messages or "dummy" messages, while monitoring propagation time, errors, etc.

[0149] Although the computing devices (e.g., UE, network node, host) described herein can include combinations of the hardware components shown, other embodiments can include computing devices with different combinations of components. It should be understood that these computing devices can include any suitable combination of hardware and / or software required to perform the tasks, features, functions, and methods disclosed herein. The determinations, calculations, acquisitions, or similar operations described herein can be performed by a processing circuitry that can process information by, for example, converting the acquired information into other information, comparing the acquired information or the converted information with information stored in the network node, and / or performing one or more operations based on the acquired information or the converted information, and making a determination as a result of the processing. Additionally, although a component is depicted as a single box located within a larger box or nested within multiple boxes, in practice, a computing device can include multiple different physical components that make up a single depicted component, and the functionality can be divided among separate components. For example, a communication interface can be configured to include any of the components described herein, and / or the functionality of a component can be divided between the processing circuitry and the communication interface. In another example, the non-computation-intensive functions of any such component can be implemented in software or firmware, and the computation-intensive functions can be implemented in hardware.

[0150] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry that executes instructions stored in a memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether or not instructions stored on a non-transitory computer-readable storage medium are executed, the processing circuitry may be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or other components of a computing device, but are generally enjoyed by the computing device as a whole and / or by an end user and a wireless network.

[0151] Figure 8 is a flowchart showing an example method 800 in a wireless device according to a particular embodiment. In a particular embodiment, Figure 8 one or more steps of may be performed by the UE 200 described with respect to Figure 3 .

[0152] Method 800 begins at step 812, where a RedCap wireless device (e.g., UE 200) receives a PDSCH. The PDSCH includes scheduling for an uplink transmission. The PDSCH may include a broadcast PDSCH, such as an RAR. The PDSCH may be received in a bandwidth larger than a reduced bandwidth associated with the RedCap wireless device (such as the RedCap wireless device performing method 800).

[0153] In certain embodiments, the reduced bandwidth is a reduced baseband bandwidth associated with the RedCap wireless device. In certain embodiments, the reduced bandwidth is based on the number of physical resource blocks and the subcarrier spacing. The reduced bandwidth may be 5 MHz.

[0154] At step 814, the RedCap wireless device determines whether the duration between receiving the PDSCH and the start of the scheduled uplink transmission is greater than a threshold. The threshold depends on whether the PDSCH is received in a bandwidth larger than a reduced bandwidth associated with the RedCap wireless device (such as the RedCap wireless device performing method 800).

[0155] In certain embodiments, the difference between the value applied to the threshold when the PDSCH is received in a bandwidth larger than the reduced bandwidth and the value applied to the threshold when the PDSCH is not received in a bandwidth larger than the reduced bandwidth depends on the subcarrier spacing. In certain embodiments, the threshold may be determined according to any of the embodiments and examples described herein.

[0156] Based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is greater than a threshold, the method proceeds to step 816, where the RedCap wireless device transmits the scheduled uplink transmission.

[0157] Based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold, the RedCap wireless device may, for example, not transmit the scheduled uplink transmission and may, for example, proceed to step 818, where the RedCap wireless device re - transmits the PRACH.

[0158] The method 800 may be modified, added to, or omitted. Additionally, Figure 8 one or more steps in the method may be performed in parallel or in any suitable order. Figure 8

[0159] Figure 9 is a flowchart showing an example method 900 in a network node according to a particular embodiment. In a particular embodiment, Figure 9 one or more steps of the method may be performed by the network node 300 described with respect to Figure 4 The method 900 begins at step 912, where a network node (e.g., network node 300) transmits a PDSCH to the RedCap wireless device. The PDSCH includes scheduling for an uplink transmission. The network node may or may not know that the wireless device is a RedCap wireless device.

[0160]

[0161] The PDSCH may include a broadcast PDSCH, such as an RAR. The PDSCH may be transmitted in a bandwidth larger than the reduced bandwidth associated with the RedCap wireless device (such as the RedCap wireless device receiving the PDSCH).

[0162]

[0163] In a particular embodiment, the reduced bandwidth is the reduced baseband bandwidth associated with the RedCap wireless device. In a particular embodiment, the reduced bandwidth is based on the number of physical resource blocks and the sub - carrier spacing. The reduced bandwidth may be 5 MHz.

[0164] When the duration between the wireless device receiving the PDSCH and the start of the scheduled uplink transmission is greater than the threshold, the method proceeds to step 914, where the network node receives the scheduled uplink transmission from the wireless device. The threshold depends on whether the PDSCH is transmitted in a bandwidth larger than the reduced bandwidth associated with the RedCap wireless device (such as the RedCap wireless device receiving the PDSCH).

[0164] In a particular embodiment, the difference between the value applied to the threshold when the PDSCH is transmitted in a bandwidth larger than the reduced bandwidth and the value applied to the threshold when the PDSCH is transmitted in a bandwidth not larger than the reduced bandwidth depends on the subcarrier spacing. In a particular embodiment, the threshold may be determined according to any of the embodiments and examples described herein.

[0165] When the duration between when the wireless device receives the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold, the method may, for example, proceed to step 916, where the network node does not receive the scheduled uplink transmission from the wireless device, but may receive a retransmission of the PRACH from the wireless device.

[0166] The method 900 of Figure 9 may be modified, added to, or omitted. Additionally, Figure 9 one or more steps in the method of

[0167] The foregoing description sets forth many specific details. However, it should be understood that embodiments may be practiced without these specific details. In other instances, well-known circuit systems, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification. By the description included, one of ordinary skill in the art will be able to implement appropriate functionality without undue experimentation.

[0168] References in the specification to "one embodiment," "an embodiment," "example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, implementation of such feature, structure, or characteristic in connection with other embodiments is within the knowledge of those skilled in the art whether or not explicitly described.

[0169] Although the present disclosure has been described in terms of particular embodiments, changes and permutations of the embodiments will be apparent to those skilled in the art. Accordingly, the above description of the embodiments does not limit the present disclosure. Other changes, substitutions, and alterations are possible without departing from the scope of the present disclosure as defined by the following claims.

[0170] Some example embodiments are described below. Examples of Group A 1. A method performed by a reduced-capability (RedCap) wireless device, the method comprising: - receiving a broadcast physical downlink shared channel (PDSCH) greater than 5 MHz, the PDSCH including a schedule for an uplink transmission; - Determine that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is greater than a threshold; and - Transmit the scheduled uplink transmission. 2. The method according to the foregoing embodiment, wherein the threshold is based on the bandwidth of the received PDSCH. 3. The method according to any one of the foregoing embodiments, wherein the threshold is based on the subcarrier spacing. 4. A method performed by a wireless device, the method comprising: - Any one of the wireless device steps, features or functions described above alone or in combination with other steps, features or functions described above. 5. The method according to the foregoing embodiment, further comprising one or more additional wireless device steps, features or functions described above. 6. The method according to any one of the foregoing embodiments, further comprising: - Provide user data; and - Forward the user data to a host computer via transmission to a base station. Examples of Group B 7. A method performed by a base station, the method comprising: - Transmit a broadcast physical downlink shared channel (PDSCH) greater than 5 MHz to a reduced-capability (RedCap) wireless device, the PDSCH including scheduling for uplink transmission, wherein the duration between the RedCap wireless device receiving the PDSCH and the start of the scheduled uplink transmission is greater than a threshold; and - Receive the scheduled uplink transmission. 8. The method according to the foregoing embodiment, wherein the threshold is based on the bandwidth of the transmitted PDSCH. 9. The method according to any one of the foregoing embodiments, wherein the threshold is based on the subcarrier spacing. 10. A method performed by a base station, the method comprising: - Any one of the steps, features or functions described above for the base station alone or in combination with other steps, features or functions described above. 11. The method according to the foregoing embodiment, further comprising one or more additional base station steps, features or functions described above. 12. The method according to any one of the foregoing embodiments, further comprising: - Obtain user data; and - Forward the user data to a host computer or a wireless device. Examples of Group C 13. A mobile terminal, comprising: - A processing circuitry configured to perform any step of the steps in any one of the Group A embodiments; and - A power supply circuitry configured to supply power to the wireless device. 14. A base station, comprising: - A processing circuitry configured to perform any step of the steps in any one of the Group B embodiments; - A power supply circuitry configured to supply power to the wireless device. 15. A user equipment (UE), comprising: - An antenna configured to transmit and receive wireless signals; - A radio front-end circuitry connected to the antenna and the processing circuitry and configured to condition signals communicated between the antenna and the processing circuitry; - A processing circuitry configured to perform any step of the steps in any one of the Group A embodiments; - An input interface connected to the processing circuitry and configured to allow information to be input into the UE for processing by the processing circuitry; - An output interface connected to the processing circuitry and configured to output from the UE information that has been processed by the processing circuitry; and - A battery connected to the processing circuitry and configured to supply power to the UE. 16. A communication system comprising a host computer, comprising: - A processing circuitry configured to provide user data; and - A communication interface configured to forward user data to a cellular network for transmission to a user equipment (UE), - wherein the cellular network includes a base station having a radio interface and a processing circuitry, and the processing circuitry of the base station is configured to perform any step of the steps in any one of the Group B embodiments. 17. The communication system according to the foregoing embodiment further comprises a base station. 18. The communication system according to the foregoing two embodiments further comprises a UE, wherein the UE is configured to communicate with the base station. 19. The communication system according to the foregoing three embodiments, wherein: - The processing circuitry of the host computer is configured to execute a host application to provide user data; and - The UE includes a processing circuitry configured to execute a client application associated with the host application. 20. A method in a communication system comprising a host computer, a base station, and a user equipment (UE) Implement, the method includes: - At the host computer, provide user data; and - At the host computer, initiate a transmission of user data to the UE via a cellular network including a base station, where the base station performs any of the steps of any of the embodiments in Group B. 21. The method according to the foregoing embodiment further includes transmitting user data at the base station. 22. The method according to the foregoing two embodiments, wherein the user data is provided at the host computer by executing a host application, and the method further includes executing a client application associated with the host application at the UE. 23. A user equipment (UE) configured to communicate with a base station, the UE includes a radio interface and a processing circuitry configured to perform any of the foregoing three embodiments. 24. A communication system including a host computer, comprising: - A processing circuitry configured to provide user data; and - A communication interface configured to forward user data to a cellular network for transmission to a user equipment (UE), - wherein the UE includes a radio interface and a processing circuitry, and the components of the UE are configured to perform any of the steps of any of the embodiments in Group A. 25. The communication system according to the foregoing embodiment, wherein the cellular network further includes a base station configured to communicate with the UE communicate. 26. The communication system according to the foregoing two embodiments, wherein: - The processing circuitry of the host computer is configured to execute a host application to provide user data; and - The processing circuitry of the UE is configured to execute a client application associated with the host application. 27. A method implemented in a communication system including a host computer, a base station, and a user equipment (UE) Implement, the method includes: - At the host computer, provide user data; and - At the host computer, initiate a transmission of user data to the UE via a cellular network including a base station, where the UE performs any of the steps of any of the embodiments in Group A. 28. The method according to the foregoing embodiment further includes receiving user data at the UE from the base station. 29. A communication system including a host computer, comprising: - A communication interface, configured to receive user data sourced from a transmission from a user equipment (UE) to a base station, - wherein the UE includes a radio interface and processing circuitry, and the processing circuitry of the UE is configured to perform any of the steps of any of the embodiments in Group A. 30. The communication system according to the foregoing embodiments, further comprising a UE. 31. The communication system according to the foregoing two embodiments, further comprising a base station, wherein the base station includes: a radio interface configured to communicate with the UE, and a communication interface configured to forward user data borne by a transmission from the UE to the base station to a host computer. 32. The communication system according to the foregoing three embodiments, wherein: - the processing circuitry of the host computer is configured to execute a host application; and - the processing circuitry of the UE is configured to execute a client application associated with the host application, thereby providing user data. 33. The communication system according to the foregoing four embodiments, wherein: - the processing circuitry of the host computer is configured to execute a host application, thereby providing request data; and - the processing circuitry of the UE is configured to execute a client application associated with the host application, thereby providing user data in response to the request data. 34. A method implemented in a communication system including a host computer, a base station, and a user equipment (UE), the method comprising: - at the host computer, receiving user data transmitted from the UE to the base station, wherein the UE performs any of the steps of any of the embodiments in Group A. 35. The method according to the foregoing embodiments, further comprising providing user data from the UE to the base station. 36. The method according to the foregoing two embodiments, further comprising: - at the UE, executing a client application, thereby providing user data to be transmitted; and - at the host computer, executing a host application associated with the client application. 37. The method according to the foregoing three embodiments, further comprising: - at the UE, executing a client application; and - at the UE, receiving input data to the client application, the input data being provided at the host computer by executing a host application associated with the client application, - wherein the user data to be transmitted is provided by the client application in response to the input data. 38. A communication system includes a host computer that includes a communication interface configured to receive user data sourced from a transmission from a user equipment (UE) to a base station, wherein the base station includes a radio interface and processing circuitry configured to perform any of the steps of any of the Group B embodiments. 39. The communication system according to the foregoing embodiment further includes a base station. 40. The communication system according to the foregoing two embodiments further includes a UE, wherein the UE is configured to communicate with the base station. 41. The communication system according to the foregoing three embodiments, wherein: - the processing circuitry of the host computer is configured to execute a host application; - the UE is configured to execute a client application associated with the host application so as to provide user data to be received by the host computer. 42. A method implemented in a communication system including a host computer, a base station, and a user equipment (UE), the method comprising: - at the host computer, receiving user data sourced from a transmission that the base station has received from the UE, wherein the UE performs any of the steps of any of the Group A embodiments. 43. The method according to the foregoing embodiment further includes receiving user data from the UE at the base station. 44. The method according to the foregoing two embodiments further includes, at the base station, initiating transmission of the received user data to the host computer.

Claims

1. A method (800) performed by a reduced-capability RedCap wireless device, the method comprising: receiving (812) a Physical Downlink Shared Channel (PDSCH), the PDSCH including scheduling for an uplink transmission; determining (814) whether a duration between receiving the PDSCH and a start of the scheduled uplink transmission is greater than a threshold; and transmitting (816) the scheduled uplink transmission based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is greater than the threshold, wherein the threshold depends on whether the PDSCH is received in a bandwidth larger than a reduced bandwidth associated with the RedCap wireless device.

2. The method according to claim 1, further comprising: not transmitting (816) the scheduled uplink transmission based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold.

3. The method according to any one of claims 1 to 2, wherein the reduced bandwidth is a reduced baseband bandwidth associated with the RedCap wireless device.

4. The method according to any one of claims 1 to 3, wherein a difference between a value applied to the threshold when the PDSCH is received in a bandwidth larger than the reduced bandwidth and a value applied to the threshold when the PDSCH is not received in a bandwidth larger than the reduced bandwidth depends on a subcarrier spacing.

5. The method according to claim 4, wherein the PDSCH carries a Random Access Response (RAR), and the scheduled uplink transmission is a Physical Uplink Shared Channel (PUSCH) transmission scheduled by an uplink grant of the RAR, wherein the subcarrier spacing is a subcarrier spacing configured for the PDSCH and / or a subcarrier spacing configured for the PUSCH transmission.

6. The method according to any one of claims 1 to 5, wherein the reduced bandwidth is based on a number of physical resource blocks and a subcarrier spacing.

7. The method according to any one of claims 1 to 5, wherein the reduced bandwidth is 5 MHz.

8. The method according to any one of claims 1 to 7, wherein the PDSCH includes a Broadcast PDSCH.

9. The method according to any one of claims 1 to 8, wherein the PDSCH includes a Random Access Response (RAR).

10. The method according to claim 9, further comprising: retransmitting (818) a Physical Random Access Channel (PRACH) based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold.

11. A reduced-capability RedCap wireless device (200) comprising processing circuitry (202) operable to: receive a Physical Downlink Shared Channel (PDSCH), the PDSCH including scheduling for an uplink transmission; Determine whether the duration between receiving the PDSCH and the start of the scheduled uplink transmission is greater than a threshold; and Transmit the scheduled uplink transmission based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is greater than the threshold, wherein the threshold depends on whether the PDSCH is received in a bandwidth larger than a reduced bandwidth associated with a RedCap wireless device.

12. The wireless device according to claim 11, wherein the processing circuitry is further operable to: Not transmit the scheduled uplink transmission based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold.

13. The wireless device according to any one of claims 11 to 12, wherein the reduced bandwidth is a reduced baseband bandwidth associated with a RedCap wireless device.

14. The wireless device according to any one of claims 11 to 13, wherein the difference between the value applied to the threshold when the PDSCH is received in a bandwidth larger than the reduced bandwidth and the value applied to the threshold when the PDSCH is not received in a bandwidth larger than the reduced bandwidth depends on the subcarrier spacing.

15. The wireless device according to claim 14, wherein the PDSCH carries a random access response RAR, and the scheduled uplink transmission is a physical uplink shared channel PUSCH transmission scheduled by the uplink grant of the RAR, wherein the subcarrier spacing is the subcarrier spacing configured for the PDSCH and / or the subcarrier spacing configured for the PUSCH transmission.

16. The wireless device according to any one of claims 11 to 15, wherein the reduced bandwidth is based on the number of physical resource blocks and the subcarrier spacing.

17. The wireless device according to any one of claims 11 to 15, wherein the reduced bandwidth is 5 MHz.

18. The wireless device according to any one of claims 11 to 17, wherein the PDSCH includes a broadcast PDSCH.

19. The wireless device according to any one of claims 11 to 18, wherein the PDSCH includes a random access response RAR.

20. The wireless device according to claim 19, wherein the processing circuitry is further operable to: Retransmit (818) a physical random access channel PRACH based on determining that the duration between receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold.

21. A method (900) performed by a network node, the method comprising: Transmitting (912) a physical downlink shared channel PDSCH to a RedCap wireless device with reduced capabilities, wherein the PDSCH includes a schedule for an uplink transmission; and When the duration between the wireless device receiving the PDSCH and the start of the scheduled uplink transmission is greater than a threshold, receive (914) the scheduled uplink transmission from the wireless device, wherein the threshold depends on whether the PDSCH is transmitted in a bandwidth larger than a reduced bandwidth associated with a RedCap wireless device.

22. The method according to claim 21, further comprising: When the duration between the wireless device receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold, do not receive (914) the scheduled uplink transmission from the wireless device.

23. The method according to any one of claims 21 to 22, wherein the reduced bandwidth is a reduced baseband bandwidth associated with the RedCap wireless device.

24. The method according to any one of claims 21 to 23, wherein the difference between the value applied to the threshold when the PDSCH is transmitted in a bandwidth larger than the reduced bandwidth and the value applied to the threshold when the PDSCH is not transmitted in a bandwidth larger than the reduced bandwidth depends on the subcarrier spacing.

25. The method according to claim 24, wherein the PDSCH carries a random access response RAR, and the scheduled uplink transmission is a physical uplink shared channel PUSCH transmission scheduled by the uplink grant of the RAR, wherein the subcarrier spacing is the subcarrier spacing configured for the PDSCH and / or the subcarrier spacing configured for the PUSCH transmission.

26. The method according to any one of claims 21 to 25, wherein the reduced bandwidth is based on the number of physical resource blocks and the subcarrier spacing.

27. The method according to any one of claims 21 to 25, wherein the reduced bandwidth is 5 MHz.

28. The method according to any one of claims 21 to 27, wherein the PDSCH includes a broadcast PDSCH.

29. The method according to any one of claims 21 to 28, wherein the PDSCH includes a random access response RAR.

30. The method according to claim 29, further comprising: When the duration between the wireless device receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold, receive (914) a retransmission of the physical random access channel PRACH from the wireless device.

31. A network node (300) comprising processing circuitry (302) operable to: Transmit a physical downlink shared channel PDSCH to a RedCap wireless device with reduced capabilities, wherein the PDSCH includes scheduling for an uplink transmission; and When the duration between the wireless device receiving the PDSCH and the start of the scheduled uplink transmission is greater than a threshold, receive the scheduled uplink transmission from the wireless device, wherein the threshold depends on whether the PDSCH is transmitted in a bandwidth larger than a reduced bandwidth associated with the RedCap wireless device.

32. The method according to claim 31, wherein the processing circuitry is further operable to: when the duration between the wireless device receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold, not receive the scheduled uplink transmission from the wireless device.

33. The method according to any one of claims 31 to 32, wherein the reduced bandwidth is a reduced baseband bandwidth associated with the RedCap wireless device.

34. The method according to any one of claims 31 to 33, wherein the difference between the value applied to the threshold when the PDSCH is transmitted in a bandwidth larger than the reduced bandwidth and the value applied to the threshold when the PDSCH is not transmitted in a bandwidth larger than the reduced bandwidth depends on the subcarrier spacing.

35. The method according to claim 34, wherein the PDSCH carries a random access response RAR, and the scheduled uplink transmission is a physical uplink shared channel PUSCH transmission scheduled by the uplink grant of the RAR, wherein the subcarrier spacing is the subcarrier spacing configured for the PDSCH and / or the subcarrier spacing configured for the PUSCH transmission.

36. The method according to any one of claims 31 to 35, wherein the reduced bandwidth is based on the number of physical resource blocks and the subcarrier spacing.

37. The method according to any one of claims 31 to 35, wherein the reduced bandwidth is 5 MHz.

38. The method according to any one of claims 31 to 37, wherein the PDSCH includes a broadcast PDSCH.

39. The method according to any one of claims 31 to 38, wherein the PDSCH includes a random access response RAR.

40. The method according to claim 39, wherein the processing circuitry is further operable to: when the duration between the wireless device receiving the PDSCH and the start of the scheduled uplink transmission is not greater than the threshold, receive a retransmission of the physical random access channel PRACH from the wireless device.

Images