DE102021112311A1 - SUPPORT OF BANDWIDTH-LIMITED USER DEVICES IN NEW RADIO SYSTEMS - Google Patents

Abstract

Method of wireless communication for a new radio (New-Radio - NR) user device with reduced capacity (RedCap) of a system of the fifth generation (5G) or an NR system that requires the determination of an initial downlink bandwidth fraction (DL BWP) and communicating at a first minimum value of the UE channel bandwidth (BW) in FR1 bands that is less than 100 MHz but not less than 5 MHz and / or communicating at a second minimum value of the UE channel bandwidth in FR2 bands which is less than 400 MHz but not less than 5 MHz.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority over the provisional U.S. patent application Ser. No. 63 / 023,148 , filed May 11, 2020 (AC9763); the preliminary U.S. patent application Ser. No. 63 / 070,766 , filed August 26, 2020 (AD2128); and U.S. Provisional Application Ser. No. 63 / 138,173 , filed January 15, 2021 (AD4712).

TECHNICAL AREA

This disclosure relates generally to systems and methods for wireless communication, e.g. the support of bandwidth-limited user devices for communication over a 5G network in accordance with one or more protocols or specifications of the Third Generation Partnership Project (3 GPP).

BACKGROUND

Various embodiments may relate generally to the field of wireless communications.

Figure list

• 1 veranschaulicht separate anfängliche DL-BWPs für gemeinsame UE-Steuerinformationen gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung.
• 2 zeigt einen anfänglichen UL-BWP für gemeinsame UE-Steuerinformationen gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung.
• 3 illustriert separate anfängliche UL BWPs für UE-Steuerinformationen gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung.
• 4 illustriert separate anfängliche UL BWPs für UE-Steuerinformationen gemäß einer oder mehreren Ausführungsformen der vorliegenden Offenbarung.
• 5 veranschaulicht ein Netzwerk gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung.
• 6 zeigt schematisch ein Drahtlos-Netzwerk gemäß verschiedenen Ausführungsformen der vorliegenden Offenbarung.
• 7 ist ein Blockdiagramm, das Komponenten gemäß einigen Ausführungsbeispielen veranschaulicht, die in der Lage sind, Anweisungen von einem maschinenlesbaren oder computerlesbaren Medium (z.B. einem nicht-transitorischen maschinenlesbaren Speichermedium) zu lesen und eine oder mehrere der Verfahren der vorliegenden Offenbarung durchzuführen.

Various aspects of the present disclosure are explained below on the basis of various embodiments with reference to the following drawings. The figures are not necessarily drawn to scale. Identical or similar components are provided with the same reference symbols in the figures.

• 1 illustrates separate initial DL BWPs for common UE control information in accordance with one or more embodiments of the present disclosure.
• 2 Figure 12 shows an initial UL BWP for common UE control information in accordance with one or more embodiments of the present disclosure.
• 3 illustrates separate initial UL BWPs for UE control information in accordance with one or more embodiments of the present disclosure.
• 4th illustrates separate initial UL BWPs for UE control information in accordance with one or more embodiments of the present disclosure.
• 5 Figure 3 illustrates a network in accordance with various embodiments of the present disclosure.
• 6th FIG. 3 schematically shows a wireless network in accordance with various embodiments of the present disclosure.
• 7th 13 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (eg, a non-transitory machine-readable storage medium) and performing one or more of the methods of the present disclosure, according to some example embodiments.

DETAILED DESCRIPTION

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

The 3GPP 5G New Radio (NR) family specifications support a wide variety of vertical applications (e.g. Vehicle-to-Anything (V2X) applications) and use cases, including Enhanced Mobile Broadband (eMBB) as well as the newly introduced Ultra- Reliable Low Latency Communication (URLLC) services. The support of Low Power Wide Area (LPWA) networks and use cases for devices with extremely low complexity / costs that aim for extreme coverage and ultra-long battery life are expected to be supported by Machine Type Communication (MTC) technologies (Category M User Equipments ( UEs)) and Narrow Band Internet of Things (NB-IoT) (category NB UEs).

Recently it was determined that it would be beneficial to support a class of NR UEs with less complexity and power consumption than Rel-15 NR UEs to support use cases such as industrial wireless sensor networks (IWSN), certain classes of wearables and video surveillance, to close the gap between current LPWA solutions and eMBB solutions in NR and also to facilitate a smooth migration from 3.5G and 4G technologies to 5G (NR) technology for bands currently in use that serve relevant use cases, that require relatively low to medium reference (e.g., (e.g. median) and peak user throughputs, low device complexity, small device form factors and relatively long battery life.

With this in mind, a class of NR user equipment (UEs) with reduced capacity (RedCap) can be defined, which can be served using the currently specified 5G NR framework with the necessary adaptations and extensions in order to limit the device complexity and power consumption while minimizing negative impacts on network resource usage, spectral system efficiency, and operational efficiency. The relaxed requirements to enable cost-effective, efficient use cases must be compatible with the 5G NR framework.

One of the main components for the complexity of the UE is the requirement to support the large channel bandwidths in NR. Rel-15 NR prescribes the support of carriers with up to 100 MHz bandwidth (BW) in frequency range 1 (FR1) bands and up to 400 MHz BW in frequency range 2 (FR2) bands. One possible way to limit the UE complexity is to reduce the requirements for the UE-BW. Depending on the exact characterization of the requirements for the UE BW and the associated features, e.g. support of carrier aggregation (CA), supplementary uplink (SUL), etc., there can be different approaches to support such UEs in NR- Systems.

Various embodiments herein include methods of supporting a new class of NR UEs with reduced capacity, with an emphasis on the introduction of NR UEs with reduced BW support.

Various embodiments include mechanisms to support a new class of NR UEs with reduced performance, with an emphasis on the introduction of NR UEs with reduced BW support.

Definition of the BW requirements for UEs with reduced capacity in NR systems

• - Industrielle Drahtlos-Sensoren: Referenz-Anwendungsfälle und Anforderungen sind in TR 22.832 und TS 22.104 beschrieben: Die Verfügbarkeit des Kommunikationsdienstes beträgt 99,99 % und die Ende-zu-Ende-Latenz weniger als 100 ms. Die Referenz-Bitrate beträgt weniger als 2 Mbit/s (potenziell asymmetrisch, z.B. bei starkem UL-Verkehr) für alle Anwendungsfälle und das Gerät ist stationär. Die Batterie sollte mindestens einige Jahre halten. Für sicherheitsrelevante Sensoren ist die Latenzanforderung geringer, 5-10 ms (TR 22.804)
• - Video-Überwachung: Wie in TS 22.804 beschrieben, wäre die wirtschaftliche Referenz-Videobitrate 2-4 Mbps, Latenz < 500 ms, Zuverlässigkeit 99%-99,9%. High-End-Video, z.B. für die Landwirtschaft, würde 7,5-25 Mbps erfordern. Es wird darauf hingewiesen, dass das Verkehrsmuster von UL-Übertragungen dominiert wird.
• - Wearables: Die Referenz-Bitrate für Smart Wearable-Anwendungen kann 10 - 50 Mbit/s in DL und mindestens 5 Mbit/s in UL betragen, die Spitzen-Bitrate des Geräts ist höher, 150 Mbit/s für Downlink und 50 Mbit/s für Uplink. Die Batterie des Geräts sollte mehrere Tage halten (bis zu 1-2 Wochen).

There are various applications for NR devices that do not require the support of a large channel bandwidth (BW) in the downlink (DL) and / or uplink (UL). In this context, the following use cases of 3GPP RAN were prioritized for upcoming Rel-17 studies on the possible introduction of NR UEs with reduced capacity (RedCap) [RP-193238]:

• - Industrial wireless sensors: Reference applications and requirements are described in TR 22.832 and TS 22.104: The availability of the communication service is 99.99% and the end-to-end latency is less than 100 ms. The reference bit rate is less than 2 Mbit / s (potentially asymmetrical, e.g. with heavy UL traffic) for all applications and the device is stationary. The battery should last at least a few years. The latency requirement is lower for safety-relevant sensors, 5-10 ms (TR 22.804)
• - Video surveillance: As described in TS 22.804, the economical reference video bit rate would be 2-4 Mbps, latency <500 ms, reliability 99% -99.9%. High-end video, e.g. for agriculture, would Require 7.5-25Mbps. It should be noted that the traffic pattern is dominated by UL transmissions.
• - Wearables: The reference bit rate for smart wearable applications can be 10 - 50 Mbit / s in DL and at least 5 Mbit / s in UL, the peak bit rate of the device is higher, 150 Mbit / s for downlink and 50 Mbit / s s for uplink. The device's battery should last for several days (up to 1-2 weeks).

As can be seen from the above, the requirements for data rate, latency and reliability are different. There is a significant variance in the values of the required bit rates across the various use cases - from 2 Mbit / s (reference data rate) to 150 Mbit / s (peak data rate) for DL and from 2 Mbit / s (reference data rate) to 50 Mbit / s ( Peak data rate) for UL. Note that the comparison includes both “reference” and “peak” bit rate requirements. From the perspective of determining the minimum channel BW support for UE, peak data rates are more suitable, particularly when determining the higher ends of the spectrum of data rate requirements.

Assuming a maximum modulation order of 64-QAM in the DL and UL and some typical assumptions of overhead factors (OH factors) for control channels of 8% and 14% for DL and UL, it can be shown that with channel BWs of 5 and 10 MHz for various values of the subcarrier spacing (SCS), the peak DL and UL throughput performance summarized in Table 1 can be achieved for transmissions on a MIMO layer (Multiple Input Multiple Output). Table 1: Peak DL / UL throughput in FR1 for various channel BW and SCS combinations for transmissions with a single MIMO layer Channel BW (MHz) SCS (kHz) Peak DL throughput (Mbit / s) Peak UL throughput (Mbit / s) 5 15th 20th 22nd 10 15th 42 44 10 30th 38 42 15th 15th 64 68 15th 30th 60 66 20th 15th 86 92 20th 30th 82 88 20th 60 78 82

In view of the desirable reuse of the Rel-15 synchronization signal block design (SSB) for RedCap NR UEs, the minimum supported channel BW should be at least 5 MHz (if only 15 kHz SCS are taken into account) and 10 MHz (if 15 kHz and 30 kHz SCS must be taken into account). Thus, in one embodiment, at least one value of the minimum required UE channel BW for RedCap NR UEs is defined as 10 MHz. In another exemplary embodiment, at least one value of the minimum required UE channel BW for RedCap NR UEs is defined as 20 MHz. A value of 20 MHz for the minimum channel BW could be seen as consistent with the consideration of defining RedCap UEs with an associated complexity and costs that are not less than that of a Category 0 or Category 1bis LTE (Long Term Evolution) UE.

In another exemplary embodiment, at least one value of the minimum required UE channel BW for RedCap NR UEs is defined with 5 MHz. In this case, such UEs are only allowed to support SCS of 15 kHz for SSB and the initial DL BWP (bandwidth shares).

In a further embodiment, a RedCap NR UE can be required to support different values of the minimum channel BW for DL and UL. For example, the minimum UE channel BW for DL can be 20 MHz, while for UL it could be 5 MHz or 10 MHz and so on.

However, as can be seen from the above, the choice of 10 MHz channel BW does not meet the required data rates for some of the prioritized use cases for RedCap NR UEs. As disclosed below, various approaches can be considered in order to achieve a scalable peak throughput performance.

In one embodiment, a RedCap NR UE is expected to support only a single MIMO layer for PDCSH (Physical Downlink Shared Channel) and PUSCH (Physical Uplink Shared Channel), and it can optionally support more support as a MIMO layer in the DL or UL, e.g. up to two layers. This would allow the peak throughput values given in Table 1 to be scaled up by the maximum number of MIMO layers supported. In a further exemplary embodiment, the support of several (eg up to two) MIMO layers by RedCap NR UEs is only for DL (eg for Physical Downlink Shared Channel (PDSCH)) and not for UL (Physical Uplink) - Shared Channel - Physical Uplink Shared Channel (PUSCH)) limited. In other words, for a RedCap UE, the maximum number of DL-MIMO layers can be one or two, while the maximum number of UL-MIMO layers can only be one.

In another embodiment, a RedCap NR UE can optionally support channel BWs greater than 5 MHz or 10 MHz, e.g. 15 MHz or 20 MHz.

In a further embodiment, the minimum required channel BW for RedCap NR UE is specified as either 5 MHz or 10 MHz, but the RedCap NR UE can optionally use carrier aggregation (CA) of multiple component carriers (CCs) (also known as serving cells). support to meet higher peak throughput requirements.

In one or more of the above-mentioned embodiments, the RedCap NR supports UE CA in order to achieve greater throughput. In one example of the embodiment, CA is only supported for DL but not for UL. Furthermore, the support of DL CA can be limited to a relatively small number of component carriers. Thus, in another example of the embodiment, a RedCap NR UE can indicate the support of DL CA with a maximum of two or four or eight DL CCs, one of these values being fixed. In another example, the maximum number of DL CCs supported for DL CA is set by the UE per UE or per band or per band combination or per feature set (e.g. per band in a band combination) or per feature set per carrier (FSPC ) reported. Such a message can also be subject to a maximum number of DL CCs that can be aggregated, which is less than 16, e.g. a maximum of four or eight DL CCs can be aggregated for a RedCap NR UE. The CCs can be contiguous or non-contiguous.

In another embodiment, CA may only be restricted to intra-band CA for RedCap NR UEs. This could be further limited to CA via contiguous intra-band CCs.

Furthermore, various combinations of the above can be considered to enable a scalable framework based on a common base set of supported functions to address a wide range of QoS requirements from RedCap NR UEs.

In one or more of the above embodiments, the RedCap NR UE supports an additional UL bearer. In a further embodiment, a RedCap NR UE can optionally support an additional UL carrier (SUL) in addition to the UL carrier that is paired with the DL carrier (for paired spectra) or coincides with it (for unpaired spectra). In another embodiment, a RedCap NR UE can optionally support a SUL carrier, but only with the same numerology (including at least the SCS) between the SUL and the non-SUL UL carriers.

The above considerations were made for operation in the frequency range (FR) 1, which is e.g. limited to carrier frequencies between 410 MHz and 7125 MHz according to the current specifications.

For operation in FR2 bands (e.g. with carrier frequencies between 24250 MHz - 52600 MHz according to the current specifications), in one embodiment at least one value of the minimum required UE channel BW for RedCap NR UEs is defined as one or more of: 40 MHz , 80 MHz, 100 MHz. This enables the support of common SSB and PDCCH configurations (Physical Downlink Control Channel) of type 0 Common Search Space (CSS) for RedCap and non-RedCap NR UEs taking into account the required mandatory support of 120 kHz and 240 kHz SCS for SSB in FR2. Furthermore, in one embodiment, the minimum UE BW required can be limited to 40 MHz, with RedCap NR UEs only supporting SSB with 120 kHz SCS in FR2 bands.

Initial access, system information and other joint tax receipts for Reduced Capability NR UEs

As a result of the relaxation of the minimum requirements for the channel BW for RedCap NR UEs, the size of the initial DL BWP would be restricted in comparison to possible values from Rel-15. For standalone NR implementations, the initial DL BWP is critical for the transmission of common control information (including the scheduling and transmission of system information messages (SI), paging messages and random access related PDCCH and PDSCH, e.g. for the random Access-Response (RAR) and the scheduling of Message (Msg) 3 and Msg 4, Msg 4 PDSCH, MsgB for 2-Step RACH etc.). Limiting the maximum size of an initial DL BWP can result in significant overloads in the initial DL BWP in various NR implementations, especially in cells that serve a large number of UEs, as the load is related to paging and random access Procedures can scale with the number of UEs in the tracking area (TA).

In addition, similar overloads can also be observed in general in the case of the initial UL BWP, e.g. with regard to overloads of the PRACH resources within the initial UL BWP.

Therefore, one or more of the embodiments of the present disclosure supports the signaling of one or more RedCap NR UEs to let a RedCap NR UE know where to get system information or paging or random access related PDCCH and PDSCH (e.g. RAR , Message 4, etc.). In one embodiment of the disclosure, one or more RedCap NR UEs can be specified via MIB or via system information block (SIB) signaling or via a combination of explicit signaling and implicit mechanisms in order for PDCCH type 1 CSS (for random access) and / or PDCCH Monitor type 2 CSS (for paging) and receive associated PDSCH in a DL BWP that differs from the initial DL BWP defined by CORESET 0 as provided via pdcch-ConfigSIB 1 in MIB.

• - Für ein Nicht-RedCap-UE kann ein erstes (obligatorisches, wie in Rel-15) initialDownlinkBWP in SIB 1 verwendet werden, um die Konfiguration des anfänglichen DL BWP zu erhalten, und CORESET #0 wird für alle gemeinsamen Steuerempfänge verwendet. Dies folgt den Spezifikationen von Rel-15 NR
• - Für ein RedCap UE kann optional eine zweite Konfiguration des initialen DL BWP über additionalInitialDownlinkBWP in SIB1 bereitgestellt werden, um die Konfiguration des zusätzlichen oder alternativen initialen DL BWP abzuleiten, der einen „CORESET #0A“ enthält. Die additionalInitialDownlinkBWP-Konfiguration kann die entsprechenden CSS-Typen enthalten, die für Paging und/oder RA-bezogene DL-Empfänge konfiguriert sind (oder alternativ alle CSS-Typen, einschließlich auch der Typen 0/0A-CSS). Ein RedCap UE ignoriert Paging-SearchSpace- und/oder RA-SearchSpace-Konfigurationen (oder alternativ alle CSS-Typen) in initialDownlinkBWP, wenn es mit additionalInitialDownlinkBWP in SIB1 versorgt wird.
• - Es ist anzumerken, dass die controlResourceSetZero-Konfiguration in pdcch-ConfigCommon in initialDownlinkBWP bzw. additionalInitialDownlinkBWP mit der jeweiligen locationAndBandwidth-Konfiguration konsistent sein sollte.

Thus, an additional DL BWP # 0 (which contains at least one alternative CORESET # 0, e.g. "CORESET # 0A") can be configured for one or more RedCap UEs in order to provide at least some (e.g. paging and random access (RA) -related) DL channels from CORESET # 0 (ie to switch). Using this method, CORESET # 0 can be obtained from the Master Information Block (MIB) as in the 3GPP Release-15 NR specifications. However, RedCap and non-RedCap UEs can determine the initial DL-BWP configuration differently. In detail,

• - For a non-RedCap UE, a first (mandatory, as in Rel-15) initialDownlinkBWP can be used in SIB 1 to get the configuration of the initial DL BWP and CORESET # 0 is used for all common control receipts. This follows the specifications of Rel-15 NR
• - For a RedCap UE, a second configuration of the initial DL BWP can optionally be provided via additionalInitialDownlinkBWP in SIB1 in order to derive the configuration of the additional or alternative initial DL BWP, which contains a "CORESET # 0A". The additionalInitialDownlinkBWP configuration can contain the appropriate CSS types configured for paging and / or RA-related DL receptions (or alternatively all CSS types, including types 0 / 0A-CSS). A RedCap UE ignores paging SearchSpace and / or RA SearchSpace configurations (or alternatively all CSS types) in initialDownlinkBWP if it is supplied with additionalInitialDownlinkBWP in SIB1.
• - It should be noted that the controlResourceSetZero configuration in pdcch-ConfigCommon in initialDownlinkBWP or additionalInitialDownlinkBWP should be consistent with the respective locationAndBandwidth configuration.

Alternatively, an optional second pdcch-ConfigCommonAdditional configuration could be made available via initialDownlinkBWP, which RedCap UEs use (if available) to replace the pdcch-ConfigCommon parameter. Here pdcch-ConfigCommonAdditional can provide a reference to the "CORESET # 0A" and the associated PDCCH Search Space Sets (SS-Sets) for the corresponding PDCCH CSS types from one or more of the PDCCH CSS types 0 / 0A / 1 / 2 included.

A RedCap UE in the idle state, ie before the connection is established, can use a random access mechanism to inform the base station of its presence in order to establish the connection. The RedCap UE can reside on a BWP shared by non-RedCap UEs, but the base station may not know of the RedCap UE's presence until the RedCap UE sends a preamble (ie Msg1) according to the random access mechanism . The preamble message is on a common BWP, but the preamble message or the resources on which the preamble message is sent can be used to indicate a new BWP for transition to further communication. The base station can respond with a RAR (ie Msg2). The RedCap UE sends Msg3. The base station is able to differentiate between the RedCap UE and Msg3. Msg3 can be used to resolve conflicts. The base station can send a Msg4 to confirm a connection.

Alternatively or in addition, the base station can send a paging message via a common BWP, the paging message identifying a destination of one or more RedCap UEs and containing information about the new BWP to which further communication is to be made. A target RedCap UE can wake up and reply to the paging message.

In one option, a common BWP of RedCap UEs and non-RedCap UEs can be used for the initial detection of RedCap UEs, regardless of whether it was initiated by a RedCap UE or a base station. In another option, RedCap can provide the configuration of the UL BWP # 0 (initial UL BWP) via SIB1 separately from that for non-RedCap UEs. Due to the lower modulation scheme of the RedCap UEs, however, inefficiencies can arise if the RedCap UEs continue to use the resources of the non-RedCap UEs, in particular in the downlink for random access and paging reception. RedCap UEs can be outsourced or moved to another BWP in order not to affect the performance of non-RedCap UEs. In this context, the preamble and / or paging message can trigger a mechanism to move a RedCap UE to another BWP. For example, a RedCap UE can send a preamble signal to a base station via PRACH. The base station can know from the preamble signal via PRACH that the source is a RedCap UE. Offloading (switching) using PRACH partitioning can minimize the impact on non-RedCap UEs as PRACH can be used to signal the presence of a RedCap UE earlier. The present disclosure provides examples of a 4-stage RACH relocation and a 2-stage RACH relocation. In the 2-step RACH, msg1 and msg4 can be combined and viewed as one msgA.

In the RRC modes Idle / Inactive or Connected, an active DL BWP for a RedCap UE may not contain the SSB and / or CORESET # 0. In such a scenario, a RedCap UE may have to intermittently frequency retune to receive the SSB and / or CORESET # 0 in the initial DL BWP.

Alternatively, a base station can configure SSB broadcast opportunities for a RedCap UE in the associated active DL BWP for tracking purposes. However, a second UE could confuse the SSB as the cell-defining SSB and lead to incorrect detection. To avoid such possibilities, a base station can transmit each additional SSB in an active DL BWP of a UE in such a way that it maintains a non-zero offset from any position on the frequency grid for cell detection.

1 illustrates separate initial DL BWPs 110 , 120 for common UE control information according to one or more embodiments of the present disclosure. 1 illustrates an example of the system bandwidth 100 with separate initial DL BWPs 110 and 120 for RedCap or non-RedCap UEs. The separate initial DL BWPs can be overlapping or non-overlapping within the system bandwidth.

Method with implicit mechanisms for the identification of a DL BWP for the reception of common control information or for the identification of a UL BWP for the transmission of a UL channel for one or more RedCap NR UEs in the RRC idle or inactive mode can be achieved by selecting certain BWPs are linked with one or more of the following properties: UE-IDs as in IMSI (International Mobile Subscriber Identity) or S-TMSI (SAE (System Architecture Evolution) Temporary Mobile Station Identifier) , PRACH (Physical Random Access Channel) resources or PRACH sequences used to initiate random access, system frame number of the frame on which the PRACH preamble is transmitted, etc.

As specific examples, the DL BWP for paging DCI (Downlink Control Information) monitoring based on the UE ID and the configured set of candidates for the additional DL BWP for paging (for RedCap UEs) via SIB signaling can be used as specific examples to be determined. For random access, offloading or switching of one or more of: PDCCH, which plans RAR for 4-step RACH or MsgB for 2-step RACH, PDCCH, which (re) plans the transmission of message 3, PDCCH (re) scheduling message 4 and PDSCH carrying RAR for 4-step RACH and MsgB for 2-step RACH or message 4 to another DL BWP can be reached if one or more RedCap UEs do so are configured to transfer the additional DL BWP based on PRACH preambles and / or PRACH resources that are used for the PRACH transmission, and the mapping of the PRACH preambles or PRACH resource sets to candidate DL BWPs for random access (for RedCap UEs), which is provided by the gNB via SIB signaling. As part of the configuration of the one or more additional DL BWP or DL BWP candidates, the PDCCH CORESET configuration (equivalent to CORESET 0 in the initial DL BWP provided to the UE via pdcch-ConfigSIB 1) and the associated PDCCH search space (SS) set configuration for each of the corresponding DL BWP (s) can be provided via SIB signaling, e.g., SIB-1, SIB-x (x> 1) or message 4, or via an alternative configuration for the CORESET of the remaining minimum system information (RMSI), which is provided via the use of one or more reserved and / or free bits in the MIB. Further details on the options for such signaling and on the assumptions of the UE are disclosed below.

Alternatively, one or more of: PDCCH, which schedules RAR for 4-step RACH or MsgB for 2-step RACH, PDCCH, which (re) schedules the transmission of message 3, PDCCH, (re) schedules message 4, and PDSCH, which transmits RAR for 4-step RACH and MsgB for 2-step RACH or message 4, could be relocated or switched to the same DL BWP that is intended for paging.

As a further alternative, one or more of the following options can be used: PDCCH, which schedules RAR for 4-step RACH or MsgB for 2-step RACH, PDCCH, which (re) schedules the transmission of message 3, PDCCH, which Message 4 (re) rescheduled and PDSCH carrying RAR for 4-step RACH and MsgB for 2-step RACH or message 4 could be used to paging to the same DL BWP or to a to unload or switch another DL BWP that is configured via SIB signaling. The DCI format could either specify the new DL BWP as the BWP in which the UE should receive the corresponding PDSCH (with the RAR or message 4), or the new DL BWP can send the UE for subsequent PDCCH monitoring after the Transmission (if the DCI format indicates Msg3 retransmission) or the receipt of the corresponding PDSCH (if the DCI format indicates RAR or Msg4 scheduling). In another variant of this alternative, the indication of the new DL BWP can be provided to the UE via the PDSCH, which carries the RAR (as part of a MAC CE) or the Msg4 (as part of the RRC signaling).

In one example, different PRACH resources can be configured for RedCap and non-RedCap UEs within the same initial UL BWP. Furthermore, independent PRACH resources in time and frequency can be configured by RMSI or SIB1 for either 4-step RACH or 2-step RACH for RedCap UEs in order to carry out a random access procedure. In another example, if common PRACH resources are configured, separate PRACH sequences can be configured for RedCap UEs and non-RedCap UEs, either for 4-step RACH or 2-step RACH. In this case, an offset for the start PRACH preamble index for RedCap UEs relative to the start PRACH preamble index for non-RedCap UEs can be configured for contention-based random access for 4-step or 2-step RACH. After the RedCap UE has sent the PRACH preamble in the PRACH resource configured for RedCap UEs, the UE starts monitoring the PDCCH, the RAR or MsgB, and the PDSCH, which carries the RAR or MsgB in the additional DL BWP, which is configured for RedCap UEs. The following procedure for 2-step or 4-step RACH can be carried out in the additional DL BWP and / or UL BWP.

2 illustrates an initial UL BWP 200 for common UE control information according to one or more embodiments of the present disclosure. 2 illustrates an example of different PRACH resources 212 , 214 for RedCap and non-RedCap UEs with the same initial UL BWP.

Alternatively, show 3 and 4th separate initial UL BWPs 210 , 220 for UE control information according to one or more embodiments of the present disclosure. As another example, if separate initial UL BWPs are configured for RedCap UEs from non-RedCap UEs, the UE can perform either 2-step or 4-step RACH in the configured initial UL BWP and start, PDCCH, the RAR or MsgB plans to monitor and PDSCH carrying RAR or MsgB in an additional DL BWP configured for RedCap UEs. Similarly, the following procedure can be performed for 2-step or 4-step RACH in the additional DL BWP and / or UL BWP.

With reference to 4th shows 4th an example of different PRACH resources 212 , 222 for RedCap and non-RedCap UEs in different initial UL BWPs 210 , 220 .

In another embodiment of the disclosure, the offloading or switching of BWPs can be implemented according to certain steps of the random access method. As an option, offloading to Msg2 for 4-step RACH or MsgB for 2-step RACH can be implemented for 4-step RACH. In particular, one or more RedCap UEs can be configured with a separate CORESET or a separate ra-SearchSpace in a same initial DL BWP in order to monitor PDCCH Scheduling RAR or MsgB.

Alternatively, one or more RedCap UEs follow the configuration of CORESET and / or ra-SearchSpace configured for non-RedCap UEs in a same initial DL BWP. When monitoring the PDCCH planning RAR or MsgB, the one or more RedCap UEs monitor PDCCH with CRC scrambling by an RNTI that differs from that for non-RedCap UEs for either 2-step or 4-step RACH, wherein the new RNTI for CRC scrambling is used alternatively or in addition to the RNTI for CRC scrambling for non-RedCap UEs. After one or more RedCap UEs have successfully received RAR or MsgB, the one or more RedCap UEs can switch to the additional DL BWP and / or UL BWP for the subsequent RACH procedure.

In a further option, one or more RedCap UEs follow the configuration of CORESET and / or ra-SearchSpace, which is configured for non-RedCap UEs in a same initial DL BWP. In addition, the one or more RedCap UEs monitor PDCCH with CRC that is scrambled by RA-RNTI or MsgB-RNTI. The RAR or MsgB can contain an explicit information in a new field or in the reserved field to indicate to the one or more RedCap UEs that they should switch to the additional DL BWP and / or UL BWP for the subsequent RACH procedure .

In a further option, an explicit indication in a new field or in the reserved field in the DCI, which is transmitted by PDCCH for the (re) planning of Msg3 and / or Msg4, can be used to identify the one or more RedCap Show UEs that they should switch to the additional DL BWP and / or UL BWP for the subsequent RACH procedure.

In a further option, an explicit configuration by Msg4 can be used to indicate to the one or more RedCap UEs that they should switch to the additional DL BWP and / or UL BWP after the RACH procedure.

According to these options, a RedCap UE sets the operation in the corresponding original (as provided by the Rel-15-MIB signaling) or additional (if provided to the UE via any combination of the methods disclosed above) when setting up the RRC (Radio Resource Control) connection ) initial DL and UL BWPs until it is switched / reconfigured. Furthermore, in one example, the same (original or additional) DL BWP is identified as the “standard DL BWP”, unless it is configured separately by higher layers.

In one embodiment of the disclosure, when a RedCap UE is configured with an additional initial DL BWP, upon RRC connection setup, it identifies the additional initial DL BWP to define CORESET # 0 instead of the CORESET specified by the SSB. In another example of the embodiment, a RedCap UE, when configured with an additional initial DL BWP, identifies the original initial DL BWP during RRC connection establishment as indicated by the SSB to define CORESET # 0.

In another variant of the embodiment, a RedCap UE, when configured with additional initial DL BWP, identifies either the original or the additional initial DL BWP when establishing the RRC in order to define CORESET # 0 as a function of the PDCCH CSS type defined by the SS-Set configuration or, equivalently, as a function of the RNTI used to scramble the CRC of the monitored PDCCH.

So, as an example, for a RedCap UE configured with an additional initial DL BWP to receive PDCCH scrambled with SI-RNTI (Type 0 / 0A CSS) corresponding to CORESET # 0 / SS (Search area) record # 0 is assigned, identifies the SSB-defined CORESET as "CORESET # 0"; and for receiving PDCCH scrambled with RA-RNTI, P-RNTI, C-RNTI, MCS-C-RNTI or CS-RNTI, or for receiving PDCCH with any type 3 PDCCH CSSS candidate, the ones on CORESET # 0 / SS record # 0 are mapped, the additional initial DL-BWP is identified as "CORESET # 0". As a further alternative example, for a RedCap UE configured with an additional initial DL BWP to receive PDCCH that is scrambled with SI-RNTI (Type 0 / 0A CSS) or PDCCH that is scrambled with P-RNTI and on CORESET # 0 / SS (search area) record # 0 is shown, the SSB-defined CORESET is marked as "CORESET # 0".

In the event that different frequency regions are identified as CORESET # 0 for different purposes (e.g. PDCCH with CRC scrambled with SI- / P- / RA-RNTI), a UE can be configured in such a way that it uses the corresponding "CORESET # 0" monitored within its active DL BWP with a corresponding interpretation of the FDRA (frequency domain resource allocation) bit field PDSCH resource allocation, if the frequency region is contained within the active DL BWP of the UE. Furthermore, in the event that the resulting DCI format size budget is exceeded, the size adjustment behavior specified in Rel-15 (TS 38.212, Section 7.3.1.0) can be followed, with a specified relative order of the DCI formats between the two categories of PDCCH, that are mapped to CORESET # 0 / SS set # 0 must be adjusted in size.

In another embodiment, the additional initial DL BWP and the SSB-defined initial DL BWP can be restricted to the same bandwidth (BW).

As part of the DL BWP configurations, the one or more RedCap NR UEs can be provided with CORESET configuration and associated PDCCH monitoring events in the additional initial DL BWP via instances of ra-SearchSpace and / or paging-SearchSpace that are designated by those for non- RedCap NR UEs are separate. It should be noted that in this section of the disclosure the terms “additional initial DL BWP” and “additional DL BWP” are used interchangeably to refer to the same concept, particularly in the context of UE behavior up to the point in time the UE is provided with a valid RRC configuration (e.g. until the UE goes into the RRC_CONNECTED state).

In one embodiment, the RedCap NR UE can assume that the additional initial DL BWP is configured with the same numerology as the initial DL BWP. In another example, the RedCap NR UE can assume that the BW of the additional initial DL BWP is the same as that of the initial DL BWP. Alternatively, both could be configured separately for the RedCap UE, together with the associated configurations for the PDCCH CORESET and the respective search space sets for the additional initial DL BWP.

In another embodiment of the disclosure, one or more RedCap NR-UEs can further be configured to monitor PDCCH with CRC scrambled with SI-RNTI for specific SIBs, e.g. B. separately configured for RedCap NR UEs or newly introduced for RedCap UEs compared to those for non-RedCap NR UEs in the additional initial DL BWP. In this case it may be necessary that the one or more RedCap NR UEs camping in the cell have to switch to the additional initial DL BWP during the SI windows corresponding to certain SIB-x messages.

In another embodiment, one or more RedCap NR UEs with additional SSB opportunities and CORESET and PDCCH types O / OA CSS monitoring opportunities in the additional initial DL BWP can be configured for SSB and SI coverage, respectively. That is, the gNB can also transmit SSB and SI messages in the additional initial DL BWP, which can be the same as those in the initial DL BWP defined by CORESET 0, which is provided by the Master Information Block (MIB) provided. Although such duplicate transmissions in the DL would lead to an increased system overhead, such an approach can be advantageous in order to avoid BWP switches by RedCap NR UEs between the initial DL BWP and the additional initial BWP.

Furthermore, in one embodiment, the RedCap NR UE can assume that the SSB configuration in the additional initial DL-BWP, including at least the SCS, is the same as in the additional initial DL-BWP. In another embodiment, the one or more RedCap UEs can be specified to use different sets of cyclic offsets for the primary synchronization signal (PSS) and / or the secondary synchronization signal (SSS) in the additional initial DL BWP compared to those used for PSS or SSS are specified in Rel-15. This can help to avoid incorrect identification of the SSB in the additional initial DL BWP as the cell-defining SSB in the initial DL BWP. As an example of the embodiment, for PSS in additional initial DL BWP an additional cyclic shift can be applied and the sequence index can be defined as m ^ '= (n + 43N_ID ^ ((2)) + x) mod 127, where e.g. x = 21 or x = 22, or in one In another example, the value of x can be made available to the RedCap NR UE via SIB signaling. In another example, for SSS in additional initial DL BWP, additional cyclic shifts of the M-sequences can be applied to the first and / or second cyclic shift values, m0 and m1, respectively, with such additional cyclic shifts either specified or provided to the RedCap UE via SIB Signaling are provided. Alternatively, in additional initial DL BWP, the RedCap UE for SSS can be provided with a value of NID (2) that differs from that which was used for the PSS sequence generation.

In a further embodiment, one or more RedCap UEs can be configured with different DL BWPs for PDCCH monitoring and PDSCH reception for SI and paging reception as well as for PDCCH monitoring and PDSCH reception with random access.

Similarly, in another embodiment of the disclosure, one or more RedCap NR UEs may be indicated to the UL via system information block (SIB) signaling or via a combination of explicit configuration and implicit mechanisms to transmit PRACH to PRACH resources that configured in a UL BWP that differs from the initial UL BWP indicated via SIB 1 (the latter is intended for non-RedCap UEs according to the Rel-15 specifications).

In 3-4 Examples of separate initial UL BWPs for RedCap and Non-RedCap NR-UEs are shown. The separate initial UL BWPs can be overlapping or non-overlapping within the system bandwidth. FIG 3 illustrates separate PRACH resources / used to link with different initial DL-BWPs for non-RedCap and RedCap NR-UEs, while FIG 4 shows the use of separate initial UL-BWPs.

If one or more RedCap UEs are configured with additional initial UL BWP, the one or more RedCap UEs are configured with a new pucch-ResourceCommon in the additional initial UL BWP.

In another embodiment of the disclosure, the offloading or switching of BWPs can also be implemented as a function of different “types” of RedCap NR UEs, in particular if these have different support from UE at least BW. Consider, for example, without loss of general validity, two types of RedCap NR UEs based on UE min.BW support, with a larger UE BW for RedCap _HE UEs and a smaller UE BW for RedCap_LE.

In a first step, RedCap LE, RedCap _HE and non-RedCap NR-UEs determine the initial DL-BWP based on the MIB.

In one example, the network (NW) can then configure a larger BW for the initial DL BWP via SIB-1, and in this case non-RedCap UEs (according to Rel-15 behavior) and RedCap _HE UEs follow the new configuration at the RRC - Connection establishment (according to R15 behavior), but RedCap _LE UEs ignore such a configuration in SIB1 and continue to receive the initial DL BWP (through MIB) until they are reconfigured / switched in RRC connection mode. Alternatively, the NW can configure a larger BW for the initial DL BWP via SIB-1, and in this case non-RedCap UEs (according to Rel-15 behavior) follow the new configuration when establishing the RRC connection (according to R15 behavior), however RedCap _LE UEs ignore such a configuration in SIB1 and continue receiving in the initial DL BWP (through MIB) until they are reconfigured / switched in RRC connection mode, while RedCap _HE UEs use the new DL BWP configuration for paging and random Interpret Access-related procedures. A similar approach can also be defined for additional UL BWP.

As a further alternative, the Remaining Minimum System Information (RMSI) (also referred to as SIB1) and Other System Information (OSI) (also referred to as SIB-x, x> 1) continue to be received in the initial DL BWP (from MIB). However, other common controls (RA, paging) for RedCap _HE UEs can be multiplexed (FDM-ed) in the larger DL BWP (which contains the initial DL BWP (via MIB)). In this case, non-RedCap and RedCap_LE-NR UEs continue to use the initial DL BWP and the associated CORESET # 0 for RA, paging monitoring.

In another embodiment of the disclosure, RedCap NR UEs can be identified and, accordingly, a RedCap UE type can be defined based on form factor constraints. Such Form factor restrictions may arise to support small form factors for various RedCap use cases (e.g. industrial wireless sensors, low-end wearables, etc.) that could negatively impact antenna efficiency, especially for operation in frequency range 1 (FR1) Ribbons. For example, RedCap UEs can be identified on the basis of restrictions for small form factors, at least in frequency range 1 (FR1) for DL and UL. Antenna efficiency is to be understood here generally as the entire MIMO capability for DL reception or UL transmission. Specifically, this can also include, for example, one or more parameters that indicate the MIMO capabilities of the UE, such as the number of receiver (Rx) branches or an implicit specification of the same, for example about the maximum number of DL-MIMO layers , the number of transmitter (Tx) branches, the antenna gain factors for DL or UL, etc.

In a further embodiment, a RedCap NR UE can be classified based on whether the UE has small form factor restrictions or reduced capabilities on one or more antenna efficiency parameters and accordingly the gNB can either exclude such UE from access to the network or an appropriate one Provide planning and connection adjustment during the random access procedure, e.g. for Msg2, Msg3, Msg4 scheduling or even before random access by configuring separate PRACH resource sets for RedCap UEs with and without small form factor restrictions or as an additional mechanism cell lock by broadcasting cell lock information for a particular type of RedCap UEs, and in this case depending on whether or not the RedCap UE has form factor restrictions

In another embodiment of the disclosure, as an example of MIB signal-based offloading, one or more RedCap NR UEs can be provided with an indication for PDCCH CORESET 0 and an associated SS-Set configuration for types 0 / 0A and possibly also for Types 1 or 2 PDCCH are provided by using one or more reserved and / or free bits that are available in the Master Information Block (MIB) transmitted by the Physical Broadcast Channel (PBCH). Such an approach can enable separate configuration and reception of SIB-1 (and subsequent SIB-x, x> 1) between non-RedCap and RedCap NR UEs.

According to the Rel-15 and Rel-16-NR specifications, there are two reserved bits in the MIB for FR1 and a spare bit in the MIB for both FR1 and FR2.

In one example of the embodiment, up to one or two reserved bits in the MIB in FR1 bands are used to indicate to the RedCap NR UEs the frequency (and possibly time) resources for CORESET 0 (the RMSI CORESET) that the RedCap NR UEs are intended to monitor for the planning of SIB1. In a further embodiment, a single spare bit in the FR1 and / or FR2 band is used to indicate to the RedCap UEs the frequency (and possibly also time) resources for CORESET 0, which the RedCap NR UEs for the planning of SIB 1 should monitor.

In a further exemplary embodiment, the additional display for RedCap NR UEs, which indicates the location of the alternative CORESET 0 for the SIB 1 scheduling (and thus the display of the additional initial DL BWP), only indicates the start of the frequency resources, for example the location of the Initial subcarrier of CORESET in relation to the SSB location in the frequency. Certain (e.g. up to two or four, including the offset value of 0) frequency offsets in relation to the SSB position or in relation to the standard CORESET 0 position specified via pdcch-ConfigSIB 1 can be predefined e.g. is provided by subCarrierSpacingCommon, and the indication using the reserved or free bits can be used to provide RedCap NR UEs with a certain value from the set of predefined offsets. In another variant of the example, the predefined frequency offsets can be defined separately for FR1 and FR2 bands, or alternatively only apply to FR1 bands. In another example of FR2 bands where SSB and CORESET 0 (also known as "RMSI CORESET") multiplexing patterns 2 and 3 can be used, the RMSI CORESET (and therefore the additional initial DL BWP) can be in frequency overlap with the SSB positions, e.g. the RMSI CORESET can be time division multiplexed (TDM-ed) with the SSB instead of frequency division multiplexed (FDM-ed) with the SSB following SSB-RMSI CORESET multiplexing patterns 2 or 3. In this case, the monitoring events for PDCCH-CSS of type 0 / 0A can also be interpreted differently compared to the display via pdcch-ConfigSIB 1 due to the predefined mappings.

In another embodiment, one of the reserved or spare bits in the MIB for FR1 bands or the spare bit in the MIB for FR2 bands can be used to indicate that the cell is locked to RedCap NR UEs.

In general, different combinations of the approaches mentioned above can be defined in order to implement different signaling of the offloading / switching behavior for one or more of RMSI, OSI, paging and random access.

SYSTEMS AND IMPLEMENTATIONS

5-6 illustrate various systems, devices, and components that can implement aspects of the disclosed embodiments.

5 shows a network 500 according to various embodiments. The network 500 can be operated in a way that complies with the technical specifications of 3GPP for LTE or 5G / NR systems. However, the example embodiments are not limited in this regard, and the described embodiments may apply to other networks that benefit from the principles described here, such as future 3GPP systems or the like.

The network 500 can a UE 502 which may include any mobile or non-mobile computing device designed to RAN with a radio access network 504 Communicate over an over-the-air connection. The UE 502 can communicate with the RAN via a Uu interface 504 be coupled. The UE 502 a smartphone, a tablet computer, a portable computing device, a desktop computer, a laptop computer, an infotainment device in the vehicle, an entertainment device in the vehicle, an instrument cluster, a head-up display device, an onboard Diagnostic device, a mobile Dashtop device, a mobile data terminal device, but is not limited to, electronic engine management system, electronic / engine control unit, electronic / engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked device, machine-like communication device, machine-to -Machine M2M or device-to-device D2D device, IoT device, etc.

In some embodiments, the network 500 comprise a plurality of UEs that are directly connected to one another via a sidelink interface. The UEs can be M2M / D2D devices that communicate via physical sidelink channels, such as the physical sidelink broadcast channel PSBCH, the physical sidelink downlink channel PSDCH, the physical sidelink shared channel PSSCH , but not limited to the sidelink physical control channel PSCCH, the sidelink physical feedback channel PSFCH, etc.

In some embodiments, the UE 502 additionally with an access point (AP) 506 communicate over an over-the-air connection. The AP 506 can manage a wireless local area network WLAN connection, which can serve to take part / all network traffic from the RAN 504 to relieve. The connection between the UE 502 and the AP 506 can conform to any IEEE 802.11 protocol, with the AP 506 could be a Wireless Fidelity (Wi-Fi®) router. In some embodiments, the UE 502 , the RAN 504 and the AP 506 use a cell WLAN aggregation (e.g. LWA / LWIP). With cellular WLAN aggregation, the UE 502 from the RAN 504 configured to use both cellular and WiFi resources.

The RAN 504 can contain one or more access nodes, e.g. AN 508 . AT 508 can use air interface protocols for the UE 502 by providing access layer protocols including RRC, packet data convergence protocol PDCP, radio link control RLC, media access control MAC and LI protocols. In this way, the AN 508 Data / voice connectivity between the core network CN 520 and the UE 502 enable. In some embodiments, this may be AN 508 be implemented in a discrete device or as one or more software entities running on server computers, for example as part of a virtual network that can be referred to as a CRAN or virtual baseband unit pool. The AN 508 can be referred to as BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. The AN 508 may be a macro cell base station or a low power base station to provide femtocells, picocells or similar cells with smaller coverage areas, lower user capacity or higher bandwidth compared to macro cells.

In embodiments where the RAN 504 comprises a large number of ANs, these can be accessed via an X2 interface (if the RAN 504 is an LTE-RAN) or an Xn interface (if the RAN 504 a 5G RAN is) coupled to each other. The X2 / Xn interfaces, which in some embodiments can be subdivided into control / user level interfaces, enable the ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

The ANs of the RAN 504 can each manage one or more cells, cell groups, component carriers, etc. to the UE 502 provide an air interface for network access. The UE 502 may be connected to multiple cells at the same time from the same or different ANs of the RAN 504 to be provided. For example, the UE 502 and the RAN 504 Use carrier aggregation to provide the UE 502 enable connection to a large number of component carriers, each corresponding to a P-cell or Scell. In dual connectivity scenarios, a first AN can be a master node providing an MCG and a second AN can be a secondary node providing an SCG. The first / second ANs can be any combination of evolved NodeB eNB, next generation nodeB gNB, ng-eNB, etc.

The RAN 504 can provide the air interface via a licensed spectrum or an unlicensed spectrum. For operation in the unlicensed spectrum, the nodes can use the licensed assisted access LAA, the extended LAA eLAA and / or further extended LAA feLAA mechanisms based on CA technology with PCells / Scells. Prior to accessing the unlicensed spectrum, the nodes may perform media / carrier sensing operations based, for example, on a listen-before-talk (LBT) protocol.

In V2X scenarios, the UE 502 or AN 508 be or act as a Road Side Unit (RSU), which may refer to any traffic infrastructure unit used for V2X communication. An RSU can be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by a UE may be referred to as a “UE-Type RSU”; an eNB can be referred to as an “eNB-type RSU”; a gNB can be referred to as a “gNB-type RSU”; and the same. In one example, an RSU is a computing device that is coupled to a radio frequency circuit located on the roadside that provides connectivity to the UEs of passing vehicles. The RSU may also contain internal data storage circuitry to store intersection geometry, traffic statistics, media, and applications / software to capture and control ongoing vehicle and pedestrian traffic. The RSU can provide the very low latency communication required for high speed events such as accident avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU can provide other cellular / WLAN communication services. The components of the RSU can be housed in a weatherproof housing suitable for outdoor installation and can contain a network interface controller to establish a wired connection (e.g. Ethernet) to a traffic signal controller or a backhaul network.

In some embodiments, the RAN 504 an LTE-RAN 510 with eNBs, e.g. eNB 512. The LTE RAN 510 can provide an LTE air interface with the following features: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; Turbo codes for data and TBCC for control; etc. The LTE air interface can rely on CSI-RS for CSI acquisition and beam management, PDSCH / PDCCH dereference modulation signal DMRS for PDSCH / PDCCH demodulation and CRS for cell search and initial acquisition, channel quality measurements and channel estimation for the Support coherent demodulation / detection at the UE. The LTE air interface can work on bands below 6 GHz.

In some embodiments, the RAN 504 an NG-RAN 514 with gNBs, for example gNB 516 , or ng-eNBs, for example ng-eNB 518 , be. The gNB 516 can connect to 5G-capable UEs via a 5G-NR interface. The gNB 516 can connect to a 5G core via an NG interface, which can include an N2 interface or an N3 interface. The ng-eNB 518 can also connect to the 5G core via an NG interface, but can connect to a UE via an LTE air interface. The gNB 516 and the ng-eNB 518 can connect to each other via an Xn interface.

In some embodiments, the NG interface can be split into two parts, an NG-U interface (NG-U), which carries traffic data between the nodes of the NG-RAN 514 and a UPF 548 (e.g. N3 interface) transmits, and an NG-Control-Plane-Interface (NG-C), which is a signaling interface between the nodes of the NG-RAN 514 and an AMF 544 (e.g. N2 interface).

The NG-RAN 514 can provide a 5G NR air interface with the following features: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; Polar, repetition, simplex and reed-Muller codes for control and LDPC for data. Similar to the LTE air interface, the 5G-NR air interface can be based on CSI-RS, PDSCH / PDCCH DMRS. The 5G-NR air interface cannot use a CRS, but can use PBCH DMRS for PBCH demodulation, PTRS for phase tracking for PDSCH and a reference signal for time tracking. The 5G NR air interface can operate on FR1 bands, which include bands below 6 GHz, or FR2 bands, which include bands from 24.25 GHz to 52.6 GHz. The 5G NR air interface may include an SSB, which is a portion of a downlink resource grid that includes PSS / SSS / PBCH.

In some embodiments, the 5G NR air interface can use BWP for various purposes. For example, BWP can be used to dynamically adjust the SCS. For example, the UE 502 configured with multiple BWPs, with each BWP configuration having a different SCS. If the UE 502 a BWP change is indicated, the SCS of the transfer is also changed. Another use case example for BWP relates to energy saving. In particular, several BWPs can be used for the UE 502 be configured with a different number of frequency resources (e.g. physical resource blocks PRBs) to support data transmission under different traffic load scenarios. A BWP that contains a smaller number of PRBs can be used for data transmission with a low traffic load and at the same time enables energy saving at the UE 502 and in some cases with the gNB 516. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic loads.

The RAN 504 is communicative with the CN 520 coupled, which contains network elements to provide various functions to support data and telecommunication services for customers / subscribers (e.g. users of the UE 502 ) to provide. The components of the CN 520 can be implemented in a physical node or in separate physical nodes. In some embodiments, the network function virtualization NFV may be used to identify some or all of the network elements of the CN 520 to virtualize the functions provided on physical computing / storage resources in servers, switches, etc. A logical instantiation of the CN 520 can be referred to as a network slice, and a logical instantiation of part of the CN 520 can be referred to as a network sub-slice.

In some embodiments, the CN 520 an LTE CN 522 which can also be referred to as Evolved Packet Core EPC. The LTE CN 522 the mobility management unit MME 524 , the Serving Gateway SGW 526 , the Serving GPRS Support Node SGSN 528 , the Home Subscriber Server HSS 530 , the Packet Data Network Gateway PGW 532 and the Policy Control and Charging Rules Function PCRF 534 that are interfaced (or "reference points") as shown. The functions of the elements of the LTE CN 522 can be briefly introduced as follows.

The MME 524 can implement mobility management functions to a current location of the UE 502 track to enable paging, bearer activation / deactivation, handover, gateway selection, authentication, etc.

The SGW 526 can terminate an S1 interface to the RAN and data packets between the RAN and the LTE CN 522 forward onto. The SGW 526 can be a local mobility anchor point for inter-RAN node handover and can also provide an anchor for inter-3GPP mobility. Other tasks can include lawful interception, charging, and enforcing some policies.

The SGSN 528 can find the location of the UE 502 track and perform security functions and access control. In addition, the SGSN 528 Inter-EPC node signaling for mobility between different RAT networks, PDN and S-GW selection according to the specifications of the MME 524 , carry out the MME selection for handover etc. The S3 reference point between the MME 524 and the SGSN 528 can enable the exchange of user and bearer information for inter-3GPP access network mobility in the idle / active state.

The HSS 530 may contain a database for network users, including subscription-related information to aid in the handling of communication sessions by the network entities. The HSS 530 can provide support for routing / roaming, authentication, authorization, name / addressing resolution, location dependencies, etc. An S6a reference point between the HSS 530 and the MME 524 can transfer subscription and authentication data for authentication / authorization of user access to the LTE CN 520 enable.

The PGW 532 can be an SGi interface to a data network (DN) 536 complete an application / content server 538 may contain. The PGW 532 can send data packets between the LTE CN 522 and the data network 536 forward onto. The PGW 532 can with the SGW 526 be coupled via an S5 reference point in order to facilitate tunneling at the user level and tunnel management. The PGW 532 may also contain a policy enforcement and billing information node (eg PCEF). In addition, the SGi reference point between the PGW 532 and the data network 536 an operator-external public, a private PDN or an operator-internal packet data network, e.g. for the provision of IMS services. The PGW 532 can with a PCRF 534 be coupled via a Gx reference point.

The PCRF 534 is the policy and charge control element of the LTE CN 522 . The PCRF 534 can communicate with the app / content server 538 be coupled to determine suitable quality of service and charging parameters for service flows. The PCRF 532 can provide associated rules in a PCEF (via the Gx reference point) with suitable TFT and QCI.

In some embodiments, the CN 520 a 5GC 540 be. The 5GC 540 can EXECUTE an authentication server function 542 , an access and mobility management function AMF 544 , a session management function SMF 546 , a user level function UPF 548 , a network slice selector NSSF 550 , a network discovery function NEF 552 , a network function storage function NRF 554 , a policy control function PCF 556 , a uniform data management UDM 558 and an application function AF 560 that are interfaced (or "reference points") with each other as shown. The functions of the elements of the 5GC 540 can be briefly introduced as follows.

The AUSF 542 can provide data for the authentication of the UE 502 store and handle authentication-related functions. The AUSF 542 can enable a common authentication framework for different types of access. In addition to communicating with other elements of the 5GC 540 Via reference points, as shown, the AUSF 542 have a Nausf service based interface.

The AMF 544 there can be other functions of the 5GC 540 enable with the UE 502 and the RAN 504 to communicate and notify of mobility events related to the UE 502 to subscribe. The AMF 544 can be used for registration management (e.g. for the registration of the UE 502 ), connection management, availability management, mobility management, lawful interception of AMF-related events and access authentication and authorization. The AMF 544 can be the transport for SM messages between the UE 502 and the SMF 546 and act as a transparent proxy for routing SM messages. AMF 544 can also transport SMS messages between the UE 502 and provide an SMSF. AMF 544 can with the AUSF 542 and the UE 502 interact to perform various security anchor and context management functions. In addition, AMF 544 be a termination point of a RAN-CP interface, which is an N2 reference point between the RAN 504 and the AMF 544 may contain or be; and the AMF 544 can be a termination point of NAS (N1) signaling and perform NAS encryption and integrity protection. AMF 544 can also do NAS signaling with the UE 502 support via an N3 IWF interface.

The SMF 546 can be responsible for SM (e.g. session setup, tunnel management between UPF 548 and on 508 ); Assignment and management of UE IP addresses (including optional authorization); Selection and control of the UP function; Configuration of traffic routing on UPF 548 to get traffic to the right destination; Termination of interfaces to policy control functions; Control of part of the policy enforcement, charging and QoS functions; legally compliant interception (for SM events and interface to the LI system); Termination of SM parts of NAS messages; Downlink data notification; Initiation of AN-specific SM information that is sent via AMF 544 via N2 to AN 508 be sent; and determining the SSC mode of a session. SM can refer to the management of a PDU session, and a PDU session or "session" can refer to a PDU link service which enables the exchange of PDUs between the UE 502 and the data network 536 provides or enables.

The UPF 548 Can be used as an anchor point for intra-RAT and inter-RAT mobility, as an external PDU session connection point to the data network 536 and serve as a branch point to support multi-homed PDU sessions. The UPF 548 can also perform packet routing and forwarding, perform packet inspection, enforce the part of the policy rules for the user level, intercept packets lawfully (UP collection), create traffic usage reports, perform QoS handling for a user level (e.g. packet filtering, gating, UL / DL rate enforcement) ), Carry out uplink traffic checks (e.g. SDF-to-QoS flow mapping), carry out packet marking on the transport level in the uplink and downlink and Perform downlink packet buffering and downlink data notification triggering. The UPF 548 may contain an uplink classifier to aid in routing traffic flows to a data network.

The NSSF 550 can select a set of network slice instances that the UE 502 serve. The NSSF 550 can also determine permitted NSSAIs and the assignment to the subscribed S-NSSAIs, if necessary. The NSSF 550 can also determine the AMF rate to be used to identify the UE 502 or a list of candidate AMFs based on appropriate configuration and possibly by querying the NRF 554 . The selection of a set of network slice instances for the UE 502 can from the AMF 544 , where the UE 502 is registered by interacting with the NSSF 550 triggered, which can lead to a change in the AMF. The NSSF 550 can with the AMF 544 interact via an N22 reference point; and can communicate with another NSSF on a visited network via an N31 reference point (not shown). In addition, the NSSF 550 have an Nnssf service based interface.

The NEF 552 can services and capabilities provided by 3GPP network functions for third parties, internal exposure / re-exposure, AFs (e.g. AF 560 ), Edge computing or fog computing systems, etc. safely expose. In such embodiments, the NEF 552 authenticate, authorize or throttle the AFs. The NEF 552 can also translate information with the AF 560 and information exchanged with internal network functions. For example, the NEF 552 Translate between an AF service identifier and internal 5GC information. The NEF 552 can also receive information from other NFs based on the exposed capabilities of other NFs. This information can be found in the NEF 552 be stored as structured data or in a data-storing NF using standardized interfaces. The stored information can then be used by the NEF 552 passed on to other NFs and AFs or used for other purposes, such as analysis. In addition, the NEF 552 have an Nnef service interface.

The NRF 554 can support service discovery functions, receive NF discovery requests from NF instances and pass on the information of the discovered NF instances to the NF instances. The NRF 554 also manages information about available NF instances and their supported services. As used herein, the terms "instantiating", "instantiating" and the like can refer to the creation of an instance, and an "instance" can refer to a specific occurrence of an object, e.g. B. can occur during the execution of program code. In addition, the NRF 554 have the nnrf service-based interface.

The PCF 556 can provide policy rules for control plane functions to enforce them, and can also support a unified policy framework for regulating network behavior. The PCF 556 can also implement a front end to access subscription information necessary for policy decisions in a UDR of the UDM 558 are relevant. In addition to communicating with functions via reference points, as shown, the PCF 556 an npcf service based interface.

The UDM 558 can process subscription-related information to aid in the handling of communication sessions by the network entities; and subscription data of the UE 502 to save. For example, subscription data can be shared between the UDM 558 and the AMF 544 communicated. The UDM 558 can comprise two parts, an application front end and a UDR. The UDR can store subscription data and policy data for the UDM 558 and the PCF 556 and / or structured data for exposure and application data (including PFDs for application discovery, application requirement information for multiple UEs 502 ) for the NEF 552 to save. The Nudr service-based interface can be used by the UDR 221 issued to the UDM 558 , the PCF 556 and the NEF 552 to enable access to a certain set of the stored data as well as to read, update (e.g. add, modify), delete and subscribe to notifications relevant data changes in the UDR. The UDM may contain a UDM FE that is responsible for processing credentials, site management, subscription management, and so on. Several different front ends can serve the same user in different transactions. The UDM-FE accesses the subscription information stored in the UDR and carries out the processing of login information, the handling of the user identification, the access authorization, the management of the registration / mobility and the subscription management. In addition to communicating with other NFs via reference points, as shown, the UDM 558 have the Nudm service based interface.

The AF 560 can provide the application's impact on traffic routing, provide access to NEF, and interact with the policy framework for policy control.

In some embodiments, the 5GC 540 Enable edge computing by selecting operator / third party services to be geographically close to a point where the UE 502 connected to the network. This can reduce latency and load on the network. To provide edge computing implementations, the 5GC 540 a UPF 548 near the UE 502 and select a traffic control from the UPF 548 to the data network 536 Carry out via the N6 interface. This can be based on the UE subscription data, the UE location and that of the AF 560 information provided. In this way, the AF 560 Influence the UPF (re-) selection and the traffic routing. Based on the use of the network operator, the network operator can if the AF 560 is regarded as a trustworthy body, the AF 560 allow you to interact directly with relevant NFs. In addition, the AF 560 have an NF service-based interface.

The data network 536 can represent various network operator services, Internet access or third-party services that can be provided by one or more servers, e.g. the application / content server 538 .

6th shows schematically a wireless network 600 according to various embodiments. The wireless network 600 can a UE 602 in wireless communication with an AN 604 include. The UE 602 and the AN 604 may be similar and substantially interchangeable with like components described elsewhere herein.

The UE 602 can have a connection 606 with the AN 604 be communicatively coupled. The connection 606 is shown as an air interface to enable communicative coupling and can be compliant with cellular communication protocols such as an LTE protocol or a 5G NR protocol operating at mmWave or sub-6GHz frequencies.

The UE 602 can be a host platform 608 having that with a modem platform 610 is coupled. The host platform 608 can be a processing circuit 612 included with the protocol processing circuit 614 the modem platform 610 can be coupled. The processing circuit 612 can have different applications for the UE 602 execute, supply / sink application data. The processing circuit 612 can also implement one or more layer operations to send / receive application data to / from a data network. These layer operations can include transport (eg UDP) and Internet (eg IP) operations.

The protocol processing circuit 614 may implement one or more of the layer operations to transmit or receive data over the link 606 to facilitate. The one from the protocol processing circuit 614 implemented layer operations can include, for example, MAC, RLC, PDCP, RRC and NAS operations.

The modem platform 610 can also use a digital baseband circuit 616 that may implement one or more layer operations that are “below” the layer operations required by the processing circuitry 614 run on a network protocol stack. These operations can include, for example, PHY operations, including one or more HARQ-ACK functions, scrambling / descrambling, coding / decoding, layer mapping / de-mapping, modulation symbol mapping, determination of the received symbols / bit metric, precoding / Decoding of multi-antenna connections, which can comprise one or more space-time, space-frequency or spatial encodings, reference signal generation / recognition, preamble sequence generation and / or decoding, synchronization sequence generation / recognition, blind decoding of control channel signals and other related Functions.

The modem platform 610 can also have a transmission circuit 618 , a receiving circuit 620 , an RF circuit 622 and an RF front end (RFFE) 624 contain one or more antenna fields 626 may contain or be associated with them. In short, the transmission circuit can 618 a digital-to-analog converter, a mixer, intermediate frequency components, etc. The receiving circuit 620 may contain an analog-to-digital converter, mixer, IF components, etc.; the RF circuit 622 may include a low noise amplifier, a power amplifier, power tracking components, etc .; the RFFE 624 may contain filters (e.g. surface / bulk acoustic wave filters), switches, antenna tuners, beam shaping components (e.g. phase array antenna components), etc. The selection and arrangement of the components of the transmission circuit 618 , the receiving circuit 620 , the RF circuit 622 , the RFFE 624 and the antenna panels 626 (commonly referred to as "transmit / receive components") can be specific to the details of a particular implementation, such as whether the communication is TDM or FDM in mmWave or sub-6 GHz frequencies, etc. In some embodiments, the transmit / receive components can be arranged in several parallel transmit / receive chains, they can be housed in the same or in different chips / modules, etc.

In some embodiments, the processing circuitry for the protocol 614 contain one or more instances of control circuits (not shown) in order to provide control functions for the transmitting / receiving components.

UE reception can be through and via the antenna fields 626 who have favourited RFFE 624 who have favourited RF circuit 622 , the receiving circuit 620 who have favourited digital baseband circuit 616 and the protocol processing circuit 614 getting produced. In some embodiments, the antenna panels 626 a transfer from the contractor 604 by receiving beamforming of signals received from a plurality of antenna / antenna elements of the one or more antenna arrays 626 be received.

A UE transmission can be to and from the protocol processing circuit 614 who have favourited digital baseband circuit 616 , the transmission circuit 618 who have favourited RF circuit 622 who have favourited RFFE 624 and the antenna fields 626 being constructed. In some embodiments, the transmission components of the UE 604 apply a spatial filter to the data to be transmitted in order to form a transmit beam that is emitted by the antenna elements of the antenna arrays 626 is sent out.

Similar to the UE 602 can the AN 604 a host platform 628 include those with a modem platform 630 is coupled. The host platform 628 can be a processing circuit 632 included with the protocol processing circuit 634 the modem platform 630 is coupled. The modem platform can also have a digital baseband circuit 636 , a transmission circuit 638 , a receiving circuit 640 , an RF circuit 642 , an RFFE circuit 644 and antenna fields 646 contain. The components of the contractor 604 can be similar and essentially interchangeable with components of the UE of the same name 602 be. In addition to performing data transmission / reception as described above, the components of the AN 608 perform various logical functions, including RNC functions such as radio bearer management, dynamic uplink and downlink radio resource management and data packet scheduling.

7th FIG. 13 is a block diagram showing components capable of reading instructions from a machine-readable or computer-readable medium (eg, a non-transitory machine-readable storage medium) and performing one or more of the methods discussed herein, in accordance with some embodiments. In particular shows 7th a schematic representation of hardware resources 700 , including one or more processors (or processor cores) 710 , one or more storage / storage devices 720 and one or more communication resources 730 each of which has a bus 740 or another interface circuit can be communicatively coupled. In embodiments where node virtualization (e.g., NFV) is used, a hypervisor 702 be executed in order to provide an execution environment for one or more network slices / sub-slices to the hardware resources 700 to use.

The processors 710 can eg use a processor 712 and a processor 714 include. With the processors 710 For example, it can be a central processing unit (CPU), a RISC processor (Reduced Instruction Set Computing), a CISC processor (Complex Instruction Set Computing), a graphics processing unit (GPU) , a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

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

The communication resources 730 may include link or network interface controllers, components, or other suitable devices for interfacing with one or more peripheral devices 704 or one or more databases 706 or other network elements over a network 708 to communicate. The communication resources 730 can include, for example, wired communication components (eg for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components and other communication components.

The instructions 750 may include software, a program, an application, an applet, an app, or other executable code to run at least one of the processors 710 cause one or more of the methods discussed herein to be performed. The instructions 750 can be wholly or partially in at least one of the processors 710 (e.g. in the processor's cache memory), in the storage devices 720 or in a suitable combination thereof. In addition, any part of the instructions can 750 from any combination of the peripheral devices 704 or the databases 706 to the hardware resources 700 be transmitted. The memory of the processors are accordingly 710 who have favourited Storage / Storage Devices 720 who have favourited Peripherals 704 and the databases 706 Examples of computer readable and machine readable media.

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

EXAMPLES

Example 1 may include a method of wireless communication for a fifth generation system (5G) or a new radio system (NR), the method comprising supporting a reduced capacity NR-UE (RedCap), where a RedCap NR-UE is required to support a minimum value of the UE channel bandwidth (BW) that is less than 100 MHz (in FR1 bands) and less than 400 MHz (in FR2 bands), but not less than 5 MHz.

Example 2 may include the method of Example 1 or another example herein wherein at least one value of the minimum required UE channel BW for RedCap NR UEs is defined as 20 MHz.

Example 3 may include the method of Example 1 or another example herein, where at least one value of the minimum required UE channel BW for RedCap NR UEs is defined as 5 MHz and the subcarrier spacing (SCS) for SSB and initial DL BWP is 15 kHz is limited.

Example 4 may include the method of Example 1 or another example herein, wherein the minimum required UE channel BW is different for downlink (DL) and uplink (UL).

Example 5 may include the method of Example 1 or another example herein, where it is expected that the UE will mandatorily support a single MIMO layer for PDCSH and PUSCH and optionally support more than one MIMO layer in the DL or UL, e.g. up to two layers.

Example 6 may include the method of Example 5, or another example herein, where support for more than one MIMO layer is limited to DL and UL is limited to transmission with a single MIMO layer.

Example 7 may include the method of Example 1 or another example herein, wherein the UE may optionally support carrier aggregation (CA) of multiple component carriers (CCs).

Example 8 may include the method of Example 7 or another example herein, where CA is only supported for DL but not for UL.

Example 9 may include the method of Example 7 or 8, or another example herein, where CA is supported with a maximum of one of: two or four or eight DL CCs.

Example 10 may include the method of Example 7, or another example herein, where CA is limited to intraband CA.

Example 11 may include the method of Example 1 or another example herein, where the UE may optionally support an additional UL Carrier (SUL) in addition to the UL Carrier that is paired with the DL Carrier (for paired spectra) or coincides with it (for unpaired spectra).

Example 12 may include the method of Example 11, or another example herein, wherein the SUL and non-SUL UL carriers are configured with the same SCS.

Example 13 may include the method of Example 1 or another example herein, wherein in FR2 bands at least one value of the minimum required UE channel BW for RedCap NR UEs is defined as one or more of: 40 MHz, 80 MHz, 100 MHz.

Example 14 may include the method of Example 13 or another example herein wherein in FR2 bands the minimum UE BW required is limited to 40 MHz, with the RedCap NR UE only supporting SSB with 120 kHz SCS.

Example 15 may include the method of Example 1 or another example herein, wherein the RedCap NR UE is indicated via the MIB or via system information block (SIB) signaling, or via a combination of explicit signaling and implicit mechanisms to respond to PDCCH type 1 CSS (for random access) and / or PDCCH type 2 CSS (for paging) to monitor and to receive the associated PDSCH in a DL BWP (additional initial DL BWP) that differs from the initial DL BWP, which is defined by CORESET 0 as provided via pdcch-ConfigSIBl in the Master Information Block (MIB).

Example 16 may include the method of Example 15 or another example herein wherein for paging the DL BWP for paging DCI monitoring based on the UE ID and the configured set of candidates for the additional DL BWP for paging (for RedCap UEs ) is determined via SIB signaling.

Example 17 may comprise the method of Example 15 or any other example herein, wherein for random access, offloading one or more of: PDCCH planning RAR for 4-step RACH or MsgB for 2-step RACH, PDCCH, that (re) plans the transmission of message 3, PDCCH, that (re) plans message 4, and PDSCH that carries RAR for 4-step RACH and MsgB for 2-step RACH or message 4 to another DL BWP is achieved in that the RedCap NR UE is configured in such a way that it uses the additional DL BWP on the basis of the PRACH preamble and / or the PRACH resources that are used for the PRACH transmission and the mapping of the PRACH Preambles or PRACH resource sets on candidate DL BWPs for random access (for RedCap UEs), which are provided by the gNB via SIB signaling.

Example 18 may include the method of Example 15 or another example herein, wherein the additional initial DL BWP is limited to the same numerology as the initial DL BWP provided to the UE via pdcch-ConfigSIB 1 in MIB.

Example 19 may include the method of Example 15 or another example herein, wherein the additional initial DL-BWP is limited to the same BW as the initial DL-BWP provided to the UE via pdcch-ConfigSIB 1 in the MIB.

Example 20 may include the method of Example 15 or another example herein wherein the RedCap NR UE is configured to monitor BWP on PDCCH with CRC scrambled with SI-RNTI for specific SIBs e.g. for RedCap NR UEs have to be configured separately or newly introduced for RedCap UEs compared to those for non-RedCap NR UEs.

Example 21 may include the method of Example 15 or any other example herein wherein the RedCap NR UE with additional SSB opportunities and CORESET and PDCCH types O / OA CSS monitoring opportunities in the additional initial DL BWP for SSB and / or SSB, respectively. SI acquisition is configured.

Example 22 may include the method of Example 21 or another example herein wherein the RedCap NR UE may assume that the SSB configuration in the additional initial DL BWP, including at least the SCS, is the same as that in the additional initial DL BWP .

Example 23 may include the method of Example 21 or another example herein, wherein the one or more cyclic shifts for PSS and / or SSS in the additional initial DL BWP differ from those for PSS or SSS in Rel-15 NR -Specifications are given.

Example 24 may include the method of Example 15, or another example herein, wherein the RedCap NR UE is configured with different DL BWPs for PDCCH monitoring and PDSCH reception for SI and paging reception and random access PDCCH monitoring and PDSCH reception.

Example 25 may include the method of Example 1, or any other example herein, wherein the RedCap NR UE is indicated to the UL via system information block (SIB) signaling or via a combination of explicit configuration and implicit mechanisms to allocate PRACH to PRACH resources that are configured in UL BWP that differ from the initial UL BWP that is displayed via SIB1 (the latter is intended for non-RedCap UEs according to Rel-15 specifications).

Example 26 may include the method of Example 15 or another example herein, with the RedCap NR UE specifying PDCCH CORESET 0 and the associated SS-Set configuration for types 0 / 0A and possibly also for types 1 or 2 PDCCH is provided by using one or more reserved and / or free bits that are available in the Master Information Block (MIB) transmitted by the Physical Broadcast Channel (PBCH).

Example 27 may include the method of Example 26 or another example herein using up to one or two reserved bits in the MIB in FR1 bands to allocate frequency (and possibly time) resources for RedCap NR UEs CORESET 0 (the RMSI CORESET) that the RedCap NR UEs are expected to monitor for SIB1 scheduling.

Example 28 may include the method of Example 1 or any other example herein wherein the RedCap NR UE is further identified as a RedCap UE type based on form factor limitations that result in reduced antenna efficiency for reception to or transmission by the UE imply.

Example 29 may include the method of Example 28 or another example herein, with consideration of such form factor restrictions and associated identification of the RedCap UE type being limited to operation in frequency range 1 (FR1) bands.

Example 30 may include the method of Example 28, or another example herein, with the consideration of such form factor restrictions and the associated RedCap UE type identification defined for operation in frequency range 1 (FR1) or FR2 bands.

Example 31 may include the method of Example 28, or another example herein, wherein cell locks or congestion control mechanisms are defined to distinguish between RedCap UEs with or without form factor restrictions.

Example 32 may include the method of Example 15, or another example herein, wherein at RRC connection setup a RedCap UE, if configured with an additional initial DL BWP, identifies the additional initial DL BWP to define CORESET # 0 instead of the CORESET specified by the SSB.

Example 33 may include the method of Example 15, or any other example herein, wherein at RRC connection setup a RedCap UE, if configured with additional initial DL BWP, identifies the SSB specified initial DL BWP to define CORESET # 0.

Example 34 may include the method of Example 15, or another example herein, wherein at RRC connection establishment a RedCap UE, if configured with additional initial DL BWP, identifies either the original or the additional initial DL BWP to CORESET # 0 as to define a function of the PDCCH CSS type defined by the SS-Set configuration, or equivalently, as a function of the RNTI used to scramble the CRC of the monitored PDCCH.

Example 35 may include the method of Example 15, or another example herein, wherein the additional initial DL BWP and the SSB-defined initial DL BWP are limited to the same bandwidth (BW).

Example 36 may include a method of wireless communication for a fifth generation (5G) or New Radio (NR) system that includes support for an NR UE with reduced capacity (RedCap) that has a minimum value of the UE channel bandwidth (BW) that is less than 100 MHz (in FR1 bands) and less than 400 MHz (in FR2 bands) but not less than 5 MHz.

Example 37 may include the method of Example 36 or any other example herein, the method comprising: receiving an indication by the RedCap NR UE to search for PDCCH Type 1 CSS (for random access) and / or PDCCH Type 2 CSS (for paging ) and receive associated PDSCH in a DL BWP (additional initial DL BWP) different from the initial DL BWP defined by CORESET 0, as provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB).

Example 38 may include the method of Example 37, or another example herein, where the receipt of the indication is via system information block (SIB) signaling or a combination of explicit signaling and implicit mechanisms.

Example 39 may include the method of Example 37 or any other example herein, the method comprising: determining a DL BWP for paging DCI monitoring based on UE ID and configured set of candidates for additional DL BWP for paging (for RedCap UEs ) via SIB signaling.

Example 40 may include the method of Example 37, or another example herein, where random access is offloaded from one or more of the following: PDCCH scheduling RAR for 4-step RACH or MsgB for 2-step RACH , PDCCH, which (re) schedules the transmission of message 3, PDCCH, which (re) schedules message 4, and PDSCH, which carries RAR for 4-step RACH and MsgB for 2-step RACH or message 4, to one other DL BWP is achieved by configuring the RedCap NR UE to use the additional DL BWP based on the PRACH preamble and / or the PRACH resources used for the PRACH transmission and the mapping of the PRACH preambles or PRACH resource sets on candidate DL BWPs for random access (for RedCap UEs), which is provided by the gNB via SIB signaling.

Example 41 may include the method of Example 37 or any other example herein, the method comprising: receiving configuration information used to configure the RedCap NR UE to monitor for PDCCH with CRC scrambled with SI-RNTI for specific SIBs which, for example, have to be configured separately for RedCap NR UEs or newly introduced for RedCap UEs, compared to those for non-RedCap NR UEs in the additional initial DL BWP.

Example 42 may include the method of Example 37 or any other example herein, the method comprising: receiving configuration information to provide the RedCap NR UE with additional SSB opportunities and CORESET and PDCCH types 0 / 0A CSS monitoring opportunities in the configure additional initial DL BWP for SSB or SI acquisition.

Example 43 may include the method of Example 37 or another example herein, the method comprising: receiving configuration information to connect the RedCap NR UE with different DL BWPs for PDCCH monitoring and PDSCH reception for SI and paging reception and random access Configure PDCCH monitoring and PDSCH reception.

Example 44 may include the method of Example 37 or any other example herein, wherein for UL, the method includes determining an indication by the RedCap NR UE via system information block (SIB) signaling or via a combination of explicit configuration and implicit mechanisms is received to transmit PRACH on PRACH resources configured in a UL BWP different from the initial UL BWP indicated via SIB1 (the latter is intended for non-RedCap UEs according to Rel-15 specifications) .

Example 45 may include the method of Examples 36-44, or another example herein, wherein the RedCap NR UE is identified as a RedCap UE type based on one or more form factor constraints.

Example 46 may include the method of Example 45, or another example herein, wherein the one or more form factor limitations impart reduced antenna efficiency to the RedCap NR UE for reception and / or transmission compared to other UEs.

Example 47 may include the method of Example 45-46, or another example herein, wherein the RedCap NR UE is limited to operation in the frequency range 1 (FR1) band based on the one or more form factor restrictions and the associated RedCap UE type identification.

Example 48 may include the method of Example 45-47 or any other example herein, further comprising receiving configuration information for cell lockout or congestion control mechanisms to distinguish between RedCap UEs with or without form factor restrictions.

Example Z01 may include an apparatus that includes means for performing one or more elements of a method described in or associated with any of Examples 1-48 or another method or process described herein.

Example Z02 may include one or more non-transitory computer-readable media that include instructions to cause an electronic device, when the instructions are executed by one or more processors of the electronic device, to perform one or more elements of a method described in any of Examples 1 -48, or any other method or process described herein.

Example Z03 may include an apparatus that includes logic, modules, or circuitry to perform one or more elements of a method described in or related to any of Examples 1-48, or any other method or process described herein.

Example Z04 may include a method, technique, or process as described in or related to any of Examples 1-48, or portions or portions thereof.

Example Z05 may include an apparatus comprising: one or more processors and one or more computer readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform the method to perform the technique or process as described in or associated with any of Examples 1-48, or parts thereof.

Example Z06 may contain a signal as described in or related to any of Examples 1-48, or portions or portions thereof.

Example Z07 may include a datagram, packet, frame, segment, protocol data unit (PDU), or message as described or related to any of Examples 1-48, or portions thereof, or otherwise described in the present disclosure.

Example Z08 may include a signal encoded with data as described in any of Examples 1-48 or in sections or portions thereof, or as otherwise described in the present disclosure.

Example Z09 may contain a signal encoded with a datagram, packet, frame, segment, protocol data unit (PDU) or message, as described in or related to Examples 1-48, or parts thereof, or as described elsewhere in the present disclosure.

Example Z10 may include an electromagnetic signal carrying computer readable instructions, the execution of the computer readable instructions by one or more processors being to cause the one or more processors to perform the method, technique, or process, as in any of the Examples 1-48 or parts thereof described or associated therewith.

Example Z 11 may contain a computer program that includes instructions, the execution of the program by a processing element serving to cause the processing element to use the method, the techniques or the process as described in or associated with any of the examples 1-48, or to execute parts of it.

Example Z12 may include a signal on a wireless network as shown and described herein.

Example Z13 may include a method of communicating in a wireless network as shown and described herein.

Example Z14 may include a system for providing wireless communication as shown and described herein.

Example Z15 may include a device for providing wireless communication as shown and described herein.

Example M1 may be a method of wireless communication for a New Radio (NR) reduced capacity user equipment (RedCap) of a fifth generation (5G) system or an NR system, comprising: determining an Initial Downlink Bandwidth Part (DL BWP); and communicating with a first minimum value of the UE channel bandwidth (BW) in FR1 bands that is less than 100 MHz but not less than 5 MHz and / or communicating with a second minimum value of the UE channel bandwidth in FR2 bands that is is less than 400 MHz but not less than 5 MHz.

In example M2, the method of example M1 may further include: wherein the first minimum value is 20 MHz and the second minimum value is 100 MHz.

In example M3, the method of example M1 may further include: wherein the first minimum value is 5 MHz and a subcarrier spacing (SCS) for SSB and initial DL BWP is limited to 15 kHz.

In example M4, the method of one of examples M1-M3 can further comprise: using one or more MIMO layers (multiple input multiple output) in a downlink and / or an uplink communication, wherein a maximum number of MIMO layers in the downlink for PDSCH reception (Physical Downlink Shared Channel) is either one or two and a maximum number of MIMO layers in the uplink for PUSCH transmission ( Physical Uplink Shared Channel) is one.

In example M5, the method of any of examples M1-M4 may further include: indicating a presence of the RedCap NR UE; and determining an additional initial DL BWP that is different from the initial DL BWP, the initial DL BWP being defined by CORESET 0 as provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB).

In Example M6, the method of Example 5 may further include: determining the additional initial downlink bandwidth fraction (DL BWP) based on receipt of one of: a master information block (MIB), a system information block signaling (SIB) or a combination of explicit signaling and implicit mechanisms for receiving a physical downlink control channel (PDCCH) in the common search space (CSS) of PDCCH type 1 (for random access) and / or PDCCH type 2 CSS (for paging) and each associated PDSCH, which is planned by the PDCCH.

In example M7, the method from one of the examples M1-M6 can further comprise the following: transmitting on an uplink (UL) carrier and an additional UL (SUL) carrier, the UL carrier with a downlink (DL) Carrier is paired (for paired spectra) or coincides with it (for unpaired spectra).

In Example M8, the method of Example 7 may further include: wherein the SUL bearer has equal numerology including an equal subcarrier spacing (SCS) between the SUL and UL bearers.

In example M9, the method from one of the examples M1-M8 can further comprise the following: determining one or more PRACH resources (Physical Random Access Channel) by the RedCap NR UE if a first set of one or more PRACH resources for a non - RedCap NR UE is provided in an initial UL BWP and a second set of one or more PRACH resources is provided for the RedCap NR UE in the same initial UL BWP.

In Example M10, the method of Example 9 may further include: wherein the first and second sets of one or more PRACH resources correspond to different RACH opportunities (ROs) within the same initial UL BWP, preferably with the first and second sets of one or multiple PRACH resources are configurable by RMSI or SIB1 for either 4-step RACH or 2-step RACH for RedCap NR UEs in order to perform a random access procedure.

In Example M11, the method of Example 9 may further include: wherein the first and second sets of one or more PRACH resources share common RACH opportunities (ROs) and separate PRACH sequences for the RedCap NR UE and a non-RedCap NR UE can be configured for either 4-step RACH or 2-step RACH.

In example M12, the method from one of examples M1-M8 can further comprise: wherein a system information block type 1 (SIB1) or a combination of explicit configuration and implicit mechanisms are used to configure a second initial UL BWP for the RedCap NR UE, which is separate from a first initial UL BWP which is indicated via SIB1 for non-RedCap UEs.

In Example M13, the method of Example 12 may further include: wherein a first set of one or more PRACH resources within the first initial UL BWP is configured for non-RedCap UEs and a second set of one or more PRACH resources within the second initial UL BWP is configured for the RedCap NR UE, and wherein the RedCap NR UE is further configured to perform a 2-step or 4-step RACH in the second initial UL BWP.

In example M14, the method according to one of examples M9-M11 can further comprise: wherein the RedCap NR UE is provided via SIB1 with a pucch-ResourceCommon configuration for the initial UL BWP for the RedCap UE that is the same or different from the initial one UL is BWP that is provided to non-RedCap UEs via SIB1.

In example M15, the method of any of examples M1-M14 may further include: wherein a type of the RedCap NR-UEs can be defined and identified based on the UE capability for antenna efficiency, wherein the UE capability for antenna efficiency is one or more includes several of the following features: maximum number of reception branches (Rx), maximum number of DL-MIMO layers or reduced antenna gain factor.

Example M16 may be one or more non-transitory computer readable media that contain instructions to cause a new radio (NR) device of a user equipment (UE) to execute the instructions by one or more processors of the user equipment (UE) with reduced capacity (RedCap) Device to carry out one or more elements of a method which is described in one of the examples M1-M15 or relates to these.

Example M17 may be a New Radio (NR) Reduced Capacity User Equipment (RedCap) device, where the device includes a radio frequency (RF) interface and one or more processors that communicate with the RF Interface coupled and configured to: carry out one or more elements of a method described in or in connection with any of Examples M1-M15.

Example M18 may be a method of wireless communication for a New Radio (NR) base station (BS) with reduced capacity (RedCap) of a fifth generation (5G) or NR system that includes: displaying an initial downlink Bandwidth part (DL BWP) for a RedCap NR UE; and communicating at a first minimum value of the UE channel bandwidth (BW) in FR1 bands that is less than 100 MHz but not less than 5 MHz and / or communicating at a second minimum value of the UE channel BW in FR2 bands which is less than 400 MHz but not less than 5 MHz, the first minimum value being 20 MHz and the second minimum value being 100 MHz.

In example M19, the method of example M18 may further include: displaying the initial DL BWP via one of: a master information block (MIB), system information block (SIB) signaling, or a combination of explicit signaling and implicit mechanisms to control the common search space (CSS) of the physical downlink channel (PDCCH) type 1 (for random access) and / or PDCCH type 2 CSS (for paging) to be monitored.

In example M20, the method of example M19 can further comprise: providing a system information block type 1 (SIB1) or a combination of explicit configuration and implicit mechanisms for configuring a second initial UL BWP for the RedCap NR UE, separate from a first initial UL BWP, which is specified via SIB 1 for non-RedCap UEs.

In example M21, the method of example M19 may further include: providing a first set of one or more PRACH resources to a non-RedCap NR-UE in an initial UL BWP and a second set of one or more PRACH resources to the RedCap-NR-UE in the same initial UL BWP.

In example M22, the method of example M1 may further include: establishing a radio resource control (RRC) connection; and operation in the initial DL BWP or the DL and UL BWPs when made available to the RedCap NR UE until they are reconfigured, preferably using the initial DL BWP or the DL BWP as the "standard DL BWP "Is identified unless it is configured separately by higher layers.

In example M23, the method of example M5 may further include: establishing a radio resource control (RRC) connection; and identifying the additional initial DL BWP to define CORESET 0 instead of CORESET 0 as provided via pdcch-ConfigS1B1 in the Master Information Block (MIB).

In Example M24, the method of Example M5 may further include: determining the additional initial DL BWP, wherein determining the additional initial DL BWP receiving a CORESET configuration and associated PDCCH monitoring occasions in the additional initial DL BWP via instances of ra-SearchSpace and / or paging SearchSpace separate from those for non-RedCap NR UEs.

In Example M25, the method of Example M5 may further include: wherein the additional initial DL BWP is configured with the same numerology as the initial DL BWP defined by CORESET 0, as provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB) , wherein preferably the BW of the additional initial DL BWP is the same as that of the initial DL BWP defined by CORESET 0, as provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB).

In example M26, the method of example M1 may further include: wherein the RedCap NR UE is configured with different DL BWPs for PDCCH monitoring and PDSCH reception for SI and paging reception and random access related PDCCH monitoring and PDSCH reception.

In example M27, the method from one of the examples M10, M11, M13 can further comprise: performing at least part of a random access procedure; Switchover from the initial DL BWP, which is defined by CORESET 0, as provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB), to an additional initial DL BWP, the switchover preferably after the transmission of Msg1 for 4-step RACH or after the transmission of MsgA for 2-step RACH takes place.

In example M28, the method of example M27 may further include: wherein the switch to the additional initial DL BWP is a function of a type of the RedCap NR UE.

In example M29, the method of example M1 can further include: wherein the RedCap NR UE is provided with an indication for the initial DL BWP that differs from a DL BWP defined by CORESET 0 as defined via pdcch-ConfigSIB 1 in the Master Information Block (MIB) and the associated SS-Set configuration for types 0 / 0A and possibly also for types 1 or 2 PDCCH is provided by using one or more reserved and / or free bits that are in the MIB available that is transmitted by the Physical Broadcast Channel (PBCH).

In example M30, the method of example M29 may further include: using up to one or two reserved bits in the MIB in FR1 bands to indicate the frequency and / or time resources for PDCCH CORESET 0 to the RedCap NR UE that differ from the initial DL BWP defined by CORESET 0 as provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB) that the RedCap NR UE is to monitor for the planning of SIB1.

In example M31, the method of example M29 may further include: wherein a single spare bit in FR1 and / or FR2 bands is used to indicate to the RedCap NR UE the frequency and / or time resources for PDCCH CORESET 0 that are changing from differ from the initial DL BWP, which is defined by CORESET 0, as it is provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB), and from which the RedCap NR UE is expected to monitor it for the scheduling of SIB1.

In example M32, the method of any of examples M29-M31 may further include: receiving an additional indication containing a location of PDCCH CORESET 0 that differs from the initial DL BWP defined by CORESET 0 as defined via pdcch -ConfigSIB 1 is provided in the Master Information Block (MIB) for SIB 1 planning, which only specifies a start of the frequency resources, the location of the PDCCH CORESET 0 specifying the additional initial DL BWP, and the start of the frequency resources preferably being a location of the initial subcarrier of the CORESET with respect to an SSB location in frequency.

In example M33, the method of example M1 may further include: transmitting a PRACH preamble on PRACH resources; receiving candidate DL BWPs for random access via SIB signaling; Determining a DL-BWP based on the PRACH preamble and / or the PRACH resources used for the PRACH preamble transmission and a mapping of the PRACH preambles and / or PRACH resource sets to the candidate DL-BWPs; and switching from the initial DL BWP, which is defined by CORESET 0, as provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB), to the DL BWP for receiving one or more of: PDCCH, the RAR for 4-step RACH or MsgB for 2-step RACH plans, PDCCH, which (re) plans the transmission of message 3, PDCCH, which (re) plans message 4, and PDSCH, the RAR for 4-step RACH and MsgB for 2- Step RACH or Message 4 carries.

Each of the examples described above can be combined with any other example (or any combination of examples), unless expressly stated otherwise. The foregoing description of one or more implementations has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or can be learned from practice of the various embodiments.

Abbreviations

Unless otherwise used here, the terms, definitions and abbreviations correspond to the terms, definitions and abbreviations defined in 3GPP TR 21.905 v16.0.0 (2019-06).

terminology

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

The term "circuit" as used herein refers to hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated or group) and / or memory (shared, dedicated or group), an application-specific integrated circuit ( ASIC), a field programmable device (FPD) (e.g., a field programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-performance PLD (HCPLD), a structured ASIC or a programmable SoC), digital signal processors (DSPs), etc. configured to provide the functionality described. In some embodiments, the circuit can execute one or more software or firmware programs to provide at least a portion of the functionality described. The term “circuit” can also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code . In these embodiments, the combination of hardware elements and program code can be referred to as a particular type of circuit.

As used herein, the term “processor circuit” refers to a circuit that is or is capable of sequentially and automatically executing a series of arithmetic or logical operations or recording, storing and / or transmitting digital data Part of such a circuit. The processing circuitry can contain one or more processor cores for executing instructions and one or more memory structures for storing program and data information. Of the The term "processing circuit" can refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core Processor and / or any other device capable of executing computer-executable instructions, e.g. B. program code, software modules and / or functional processes to execute or otherwise operate. The processing circuitry can contain other hardware accelerators, which can be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators can e.g. B. Computer Vision (CV) and / or Deep Learning (DL) accelerators. The terms “application circuit” and / or “baseband circuit” can be viewed and designated as a synonym for “processor circuit”.

As used herein, the term “interface circuit” refers to a circuit that enables, is a part of, or comprises the exchange of information between two or more components or devices. The term “interface circuit” can refer to one or more hardware interfaces, e.g. buses, I / O interfaces, interfaces of peripheral components, network interface cards and / or the like.

The term “user device” or “UE” as used herein refers to a device with radio communication capabilities and can describe a remote user of network resources on a communication network. The term "user device" or "UE" can be used as a synonym for client, mobile device, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio, reconfigurable radio , reconfigurable mobile device, etc., and can be referred to as such. In addition, the term “user device” or “UE” can include any type of wireless / wired device or any computing device with an interface for wireless communication.

The term “network element” as used herein refers to physical or virtualized devices and / or infrastructures that are used to provide network services for wired or wireless communication. The term "network element" can be used as a synonym for and / or as a designation for a networked computer, network hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI and / or the like can be considered.

As used herein, the term “computer system” refers to any type of interconnected electronic device, computing device, or component thereof. In addition, the term “computer system” and / or “system” can refer to various components of a computer that are communicatively coupled to one another. In addition, the term “computer system” and / or “system” can refer to a plurality of computing devices and / or a plurality of computer systems that are communicatively coupled to one another and are configured to share computer and / or network resources.

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

The term "resource" as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment and / or a physical or virtual component within a specific device, such as computing devices, mechanical devices, storage space, processor / CPU -Time, processor / CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input / output operations, ports or network jacks, channel / link assignment, throughput, memory usage, storage, network, database and applications, workload units and / or the like. A “hardware resource” can refer to computing, storage and / or network resources provided by one or more physical hardware elements. A “virtualized resource” can refer to computing, storage, and / or network resources provided by a virtualization infrastructure for an application, device, system, and so on. The term “network resource” or “communication resource” may refer to resources that computing devices / systems can access over a communication network. The term " System resources ”can refer to any type of shared unit for the provision of services and can include computer and / or network resources. System resources can be viewed as a set of interrelated functions, network data objects, or services accessible through a server, such system resources residing on a single host or multiple hosts and being uniquely identifiable.

The term “channel” as used here refers to any tangible or intangible transmission medium that is used to transmit data or a data stream. The term "channel" can be synonymous and / or synonymous with "communication channel", "data communication channel", "transmission channel", "data transmission channel", "access channel", "data access channel", "connection", "data connection", "carrier", " Radio Frequency Carrier ”and / or any other similar term used to designate a route or medium through which data is transmitted. In addition, as used herein, the term “link” refers to a connection between two devices over a RAT for the purpose of transmitting and receiving information.

The terms "instantiating", "instantiating" and the like, as used here, refer to the creation of an instance. An “instance” also refers to a specific occurrence of an object, e.g. B. can occur during the execution of program code.

The terms “coupled”, “communicatively coupled” and derivatives thereof are used here. The term “coupled” can mean that two or more elements are in direct physical or electrical contact with one another, can mean that two or more elements are indirectly in contact with one another but still cooperate or interact with one another, and / or can mean that one or more other elements between the elements that are considered to be coupled, coupled or connected to one another. The term “directly coupled” can mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements can be in contact with one another via a communication medium, including via a wire or other connection link, via a wireless communication channel or link, and / or the like.

The term “information element” refers to a structure element that contains one or more fields.

The term “field” refers to the individual content of an information element or to a data element that contains content.

The term “SMTC” refers to an SSB-based measurement timing configuration that is configured by SSB-MeasurementTimingConfiguration.

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

The term "primary cell" refers to the MCG cell operating on the primary frequency on which the UE is either performing the initial connection establishment procedure or initiating the connection establishment procedure.

The term “primary SCG cell” refers to the SCG cell in which the UE carries out random access when it carries out the reconfiguration procedure with sync for DC operation.

The term “secondary cell” refers to a cell that provides additional radio resources in addition to a special cell for a UE configured with CA.

The term “secondary cell group” refers to the subset of serving cells that includes the PSCell and zero or more secondary cells for a DC configured UE.

The term “serving cell” refers to the primary cell for a UE in RRC_CONNECTED that is not configured with CA / DC as there is only one serving cell made up of the primary cell.

The term “serving cell” or “serving cells” refers to the set of cells that includes the special cell (s) and all secondary cells for a UE in RRC_CONNECTED configured with CA / DC.

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

QUOTES INCLUDED IN THE DESCRIPTION

This list of the documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent literature cited

• US 63023148 [0001]
• US 63/070766 [0001]
• US 63/138173 [0001]

Claims (20)

Method for wireless communication for a new radio (New Radio - NR) user device (UE) with reduced capacity (RedCap) of a fifth generation (5G) system or an NR system, comprising: Determining an initial downlink bandwidth fraction (DL BWP); and Communicating with a first minimum value of the UE channel bandwidth (BW) in FR1 bands that is less than 100 MHz but not less than 5 MHz and / or communicating with a second minimum value of the UE channel BW in FR2 bands, which is less than 400 MHz but not less than 5 MHz. Procedure according to Claim 1 where the first minimum value is 20 MHz and the second minimum value is 100 MHz. Procedure according to Claim 1 where the first minimum value is 5 MHz and a subcarrier spacing (SCS) for SSB and initial DL BWP is limited to 15 kHz. The method according to one of the Claims 1 until 3 , further comprising using one or more multiple input multiple output (MIMO) layers in a downlink and / or an uplink communication, wherein a maximum number of MIMO layers in the Downlink for receiving the Physical Downlink Shared Channel (PDSCH) is either one or two and a maximum number of MIMO layers in the uplink for transmitting the Physical Uplink Shared Channel - PUSCH) is one. The method according to one of the Claims 1 - 4th , further comprising indicating a presence of the RedCap NR UE; and determining an additional initial DL BWP that is different from the initial DL BWP, the initial DL BWP being defined by CORESET 0 as provided via pdcch-ConfigSIB 1 in the Master Information Block (MIB). The method according to one of the Claims 5 , comprising: determining the additional initial downlink bandwidth fraction (DL BWP) based on the receipt of one of: a master information block (MIB), a system information block (SIB) signaling, or a combination of explicit signaling and implicit mechanisms for receiving a physical downlink control channel (PDCCH) in the common search space (CSS) of PDCCH type 1 (for random access) and / or PDCCH type 2 CSS (for paging) and any associated PDSCH scheduled by the PDCCH. Method according to one of the Claims 1 until 6th , further comprising: transmitted on an uplink (UL) carrier and an additional UL (SUL) carrier, the UL carrier being paired with a downlink (DL) carrier (for paired spectra) or coinciding with this (for unpaired spectra). Procedure according to Claim 7 wherein the SUL bearer has the same numerology including an equal subcarrier spacing (SCS) between the SUL and UL bearers. The method according to one of the Claims 1 - 8th , further comprising determining one or more PRACH resources (physical multiple access channel - physical random access channel) by the RedCap NR UE when a first set of one or more PRACH resources is provided for a non-RedCap NR UE in an initial UL BWP and providing a second set of one or more PRACH resources to the RedCap NR UE in the same initial UL BWP. Procedure according to Claim 9 , wherein the first and second sets of one or more PRACH resources correspond to different RACH opportunities (ROs) within the same initial UL BWP, preferably the first and second sets of one or more PRACH resources through either RMSI or SIB1 for 4-step RACH or 2-step RACH for RedCap NR UEs can be configured to perform a random access procedure. Procedure according to Claim 9 , wherein the first and second sets of one or more PRACH resources share common RACH opportunities (ROs), and separate PRACH sequences for the RedCap NR UE and a non-RedCap NR UE are configured, either for 4-step RACH or 2-step RACH. Method according to one of the Claims 1 until 8th , where a system information block type 1 (SIB1) or a combination of explicit configuration and implicit mechanisms is used to configure a second initial UL BWP for the RedCap NR UE, which is separate from a first initial UL BWP, which via SIB1 for Not -RedCap UEs is displayed. Procedure according to Claim 12 , wherein a first set of one or more PRACH resources is configured within the first initial UL BWP for non-RedCap UEs and a second set of one or more PRACH resources is configured in the second initial UL BWP for the RedCap NR UE, and wherein the RedCap NR UE is further configured to perform a 2-step or 4-step RACH in the second initial UL BWP. Method according to one of the Claims 9 - 11 , the RedCap NR UE being provided via SIB1 with a pucch ResourceCommon configuration for the initial UL BWP for the RedCap UE which is the same or different from the initial UL BWP provided via SIB1 for non-RedCap UEs. Method according to one of the Claims 1 until 14th , wherein a type of the RedCap NR-UEs can be defined and identified based on the UE capability with regard to antenna efficiency, wherein the UE capability with regard to antenna efficiency comprises one or more of the following features: maximum number of reception branches (Rx), maximum Number of DL-MIMO layers or reduced antenna gain factor. One or more non-transitory computer readable media comprising instructions to cause a New Radio (NR) User Equipment (UE) device with reduced capacity (RedCap) when the instructions are executed by one or more processors of the device to carry out one or more elements of a method, which in one of the Claims 1 - 15th is described or is related to it. A reduced capacity user equipment (UE) device (RedCap) for new radio (NR), the device including a radio frequency (RF) interface and one or more processors coupled to the RF interface and configured to: a or perform several elements of a process that is included in one of the Claims 1 - 15th is described or is related to it. Method for wireless communication for a new radio (New Radio - NR) base station (BS) with reduced capacity (RedCap) of a system of the fifth generation (5G) or NR, having Displaying an initial downlink bandwidth share (DL BWP) to a RedCap NR UE; and Communicating at a first minimum value of the UE channel bandwidth (BW) in FR1 bands that is less than 100 MHz but not less than 5 MHz, and / or communicating at a second minimum value of the UE channel bandwidth in FR2 bands that is less than 400 MHz, but not less than 5 MHz, the first minimum value being 20 MHz and the second minimum value being 100 MHz. Procedure according to Claim 18 , further comprising: displaying the initial DL-BWP via one of: a master information block (MIB), a system information block (SIB) signaling or a combination of explicit signaling and implicit mechanisms to the common search space (CSS) of the physical Down control channel (PDCCH) type 1 (for random access) and / or the CSS of the PDCCH type 2 (for paging) to be monitored. Procedure according to Claim 19 , further comprising providing a system information block type 1 (SIB1) or a combination of explicit configuration and implicit mechanisms for configuring a second initial UL BWP for the RedCap NR UE, separately from a first initial UL BWP, which is specified via SIB1 for non-RedCap UEs will.

Images