Method and apparatus for operating enhanced capability reduction device in wireless communications

Abstract

Embodiments herein provide a wireless communication system for an enhanced capability reduction (eRedCap) user equipment. The wireless communication system may include a network node that notifies a user equipment whether an eRedCap device is prohibited. The UE may indicate that it is an eRedCap device. The UE may be configured to transmit via an uplink physical uplink shared channel including contiguous resource blocks.

Description

Technical Field

[0001] The present application generally relates to wireless communication systems, including support for enhanced reduced capability devices. Background Art

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless communication devices. Wireless communication system standards and protocols may include, for example, the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) (e.g., 4G), 3GPP New Radio (NR) (e.g., 5G), and the IEEE 802.11 standard for wireless local area networks (WLANs), commonly referred to within industry organizations as WLANs. ).

[0003] As envisioned by 3GPP, different wireless communication system standards and protocols may use various radio access networks (RANs) to facilitate communication between base stations of the RAN (which may also sometimes be generally referred to as RAN nodes, network nodes, or simply nodes) and wireless communication devices, referred to as user equipment (UEs). 3GPP RANs may include, for example, Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and / or Next Generation Radio Access Network (NG-RAN).

[0004] Each RAN may use one or more radio access technologies (RATs) to perform communications between base stations and UEs. For example, GERAN implements GSM and / or EDGE RATs, UTRAN implements Universal Mobile Telecommunications System (UMTS) RATs or other 3GPP RATs, E-UTRAN implements LTE RATs (sometimes referred to herein as LTE), and NG-RAN implements NR RATs (sometimes referred to herein as 5G RATs, 5G NR RATs, or simply NR). In some deployments, E-UTRAN may also implement NR RATs. In some deployments, NG-RAN may also implement LTE RATs.

[0005] The base stations used by the RAN may correspond to the RAN. An example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, enhanced Node B, eNodeB, or eNB). An example of an NG-RAN base station is a Next Generation Node B (sometimes also referred to as a gNode B or gNB).

[0006] The RAN provides communication services with external entities through its connection to the Core Network (CN). For example, E-UTRAN may utilize the Evolved Packet Core (EPC), while NG-RAN may utilize the 5G Core Network (5GC).

[0007] The frequency bands of 5G NR can be divided into two or more different frequency ranges. For example, frequency range 1 (FR1) may include frequency bands operating at frequencies below 6 GHz, some of which may be used by previous standards and may potentially be expanded to cover new spectrum products from 410 MHz to 7125 MHz. Frequency range 2 (FR2) may include frequency bands from 24.25 GHz to 52.6 GHz. Note that in some systems, FR2 may also include frequency bands from 52.6 GHz to 71 GHz (or higher). The frequency bands in the millimeter wave (mmWave) range of FR2 may have smaller coverage than the frequency bands in FR1 but potentially higher available bandwidth. The skilled person will recognize that these frequency ranges, provided by way of example, may change over time or from region to region. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] To easily identify the discussion of any particular element or action, the most significant digit(s) in a reference number refers to the drawing number that first introduces that element.

[0009] Figure 1 A signal flow diagram illustrating a wireless communication system identifying a Rel-18e RedCap device based on PRACH transmissions according to some embodiments is illustrated.

[0010] Figure 2 A master information block according to some embodiments is illustrated.

[0011] Figure 3 Scheduling DCI including an access restriction indication according to some embodiments is illustrated.

[0012] Figure 4 Illustrated is the eRedCap disabling IE according to some embodiments.

[0013] Figure 5 Frequency Domain Resource Allocation (FDRA) for Rel-18e Redcap UEs according to some embodiments is illustrated.

[0014] Figure 6 An embodiment is illustrated in which both Type 0 RA and Type 1 RA can be supported under the restriction of contiguous RBs.

[0015] Figure 7 A method for frequency domain resource allocation for a UE according to some embodiments is illustrated.

[0016] Figure 8 A method for frequency domain resource allocation for a network node according to some embodiments is illustrated.

[0017] Figure 9 Illustrated are the initial uplink BWP for Rel-18 eRedCap and the initial uplink BWP for non-eRedCap according to some embodiments.

[0018] Figure 10 Partially overlapping resource blocks of PUCCH resources are illustrated, wherein devices use different base sequences, according to some embodiments.

[0019] Figure 11 Partially overlapping resource blocks of PUCCH resources are illustrated, wherein devices use orthogonal codes to limit interference, according to some embodiments.

[0020] Figure 12 An example architecture of a wireless communication system according to the embodiments disclosed herein is illustrated.

[0021] Figure 13 A system for performing signaling between a wireless device and a network device according to embodiments disclosed herein is illustrated. DETAILED DESCRIPTION

[0022] Various embodiments are described with reference to user equipment (UE). However, reference to UE is provided for illustrative purposes only. Example embodiments may be used with any electronic component that can establish a connection with a network and is configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, UE as described herein is used to represent any suitable electronic component.

[0023] Wireless communication systems support UEs with a variety of capabilities. Some UEs are designed to robustly support many features of wireless communication systems. Conversely, some UEs may be designed for reduced complexity and / or lower power consumption. Wireless communication systems may use different frameworks to support different UEs.

[0024] The 3rd Generation Partnership Project (3GPP) has established a framework for implementing Reduced Capability (RedCap) New Radio (NR) devices. Devices supported by this framework are referred to as Reduced Capability (RedCap) UEs. RedCap UEs can be designed for a range of use cases, including industrial sensors, video surveillance, and wearables. RedCap UEs may have requirements for low UE complexity and sometimes also have requirements for low UE power consumption.

[0025] It may be desirable to further expand the market for RedCap use cases with relatively low cost, low energy consumption, and low data rate requirements. For example, it may be desirable to expand the capabilities of industrial wireless sensor network use cases. These new devices may have enhanced capabilities and, therefore, may be referred to as enhanced RedCap (eRedCap) UEs. Since eRedCap devices will be implemented in 3GPP Release 18, they may also be referred to as Rel-18 eRedCap UEs or devices. However, expanding the use of RedCap devices may introduce additional issues.

[0026] For example, a first question might be whether an eRedCap UE can support separate early indications, and if so, how the eRedCap indications should be implemented.Embodiments herein describe eRedCap indications that can be used by the network to identify that a device is an eRedCap device and not just a RedCap device.

[0027] A second issue may be due to the different baseband (BB) bandwidth (BW) requirements between Rel-18 eRedCap UEs and other UEs (including both Rel-17 RedCap and legacy standard devices). It may be desirable to support separate cell access control for Rel-18 eRedCap UEs. This can give the network flexibility to control whether to allow eRedCap UEs on a cell. The embodiments herein describe how to implement cell access control for eRedCap UEs.

[0028] The third issue is how to reduce UE complexity for eRedCap UEs. There may be options to use Bandwidth 3 (BW3) and Peak Data Rate 3 (PR3) to reduce the BB bandwidth for eRedCap UEs. Furthermore, the exact number of resource blocks (BBs) and detailed frequency domain resource allocation (FDRA) schemes for eRedCap devices remain uncertain. This implementation utilizes BW3 and PR3 and provides detailed RB number and FDRA schemes.

[0029] The fourth issue is to ensure the coexistence of eRedCap UEs with non-RedCap UEs and Rel-17 RedCap UEs. The embodiments herein provide a method for coordinating the physical uplink control channel (PUCCH) orthogonality between eRedcap-PUCCH without frequency hopping (FH) and legacy PUCCH with FH.

[0030] There is a clear need to develop solutions to the open problems listed above to improve resource efficiency for Rel-18e Redcap and legacy UEs (including both Rel-17 Redcap and ordinary devices).The embodiments herein provide solutions to these problems.

[0031] Early indication for Rel-18 eRedCap devices provides several benefits, including allowing a larger transport block size (TBS) in Message 3 (Msg3) for Random Access-Based Small Data Transmission (RA-SDT) for Rel-17 RedCap UEs, and allowing a larger TBS than eRedCap can handle for Msg4 (e.g., with Radio Resource Control (RRC) reconfiguration information) and Msg5 (if the UE comes from idle). According to certain aspects of the present disclosure, various methods may be considered to support early indication for Rel-18 eRedCap UEs. For example, Figure 1 The present invention illustrates a signal flow diagram of a wireless communication system identifying a Rel-18e RedCap device based on PRACH transmission.

[0032] In some embodiments, the network node 104 can determine the type of the UE 102 based on the initial uplink bandwidth part (BWP) used for physical random access channel (PRACH) transmissions. In these embodiments, the network node 104 can identify whether the UE 102 is a Rel-18e RedCap device without the UE 102 explicitly providing this information. Instead, the device type can be implicitly conveyed based on the uplink BWP used by the UE 102 for PRACH transmissions.

[0033] The network node 104 may configure 106 two uplink BWPs for PRACH. The first BWP may be used by Rel-17 RedCap UEs and non-RedCap UEs. The second BWP may be used by Rel-18e RedCap devices. The network node 104 may send configuration information for the two uplink BWPs via SIB 1108. The UE 102 may encode 110 and send 112 a PRACH transmission on one of the two configured BWPs.

[0034] The network node 104 may receive the PRACH transmission and identify 114 the device type based on the BWP used by the UE 102 to transmit the PRACH. The network node 104 may identify the UE 102 as a Rel-18eRedcap device type based on the PRACH transmission transmitted on the Rel-18 separate initial UL BWP.

[0035] In other embodiments, the network node 104 may identify the UE 102 as a Rel-18e RedCap device based on a Msg1 transmission that includes a dedicated RACH opportunity (RO) or a dedicated PRACH preamble configured by SIB1 108 within a shared initial uplink BWP or an initial uplink BWP that partially overlaps with a Rel-17 initial ULBWP. For example, the network node 104 may configure 106 the initial uplink BWP and transmit SIB1 108 to the UE 102. SIB1 108 may configure a dedicated RO or PRACH preamble for the Msg1 transmission. In some embodiments, early identification based on Msg1 is explicitly enabled by a dedicated IE in the SIB1 108 message for Rel-18e RedCap UEs. In some embodiments, early identification based on Msg1 is implicitly enabled or disabled by the presence of a network-specific RACH configuration.

[0036] The UE 102 may encode 110 and transmit the Msg1 transmission using a dedicated RO or PRACH preamble to indicate that the UE is an eRedCap device. If the Msg1 transmission uses a dedicated RO or PRACH preamble, the network node 104 may identify 114 the UE as an eRedCap device.

[0037] In other embodiments, Msg3 (in a 4-step RACH procedure) or MsgA PUSCH transmission (in a 2-step RACH procedure) may use two dedicated logical channel IDs (LCIDs) (one for the common control channel (CCCH) and the other for CCCH1) to identify Rel-18e RedCap devices early. In other words, the UE 102 may use two dedicated LCIDs to convey to the network node 104 an indication that the UE is a Rel-18e RedCap device. In some embodiments, Msg-3 early indication is always enabled and used by Rel-18e RedCap. In some embodiments, a new information element (IE) may be introduced in SIB1 for the network to explicitly indicate the enabling or disabling of Msg3 early indication for Rel-18e RedCap.

[0038] According to the present disclosure, various implementations and technologies may be considered for indicating access restrictions to Rel-18e RedCap devices by the network. A network node may indicate to a UE whether a Rel-18e RedCap UE is prohibited from entering a cell. If a Rel-18e RedCap UE determines that it is prohibited, the UE may stop attempting to establish a connection with the cell. Figures 2 to 4 Various ways in which a network node may convey access restrictions to a UE are illustrated.

[0039] Figure 2The Master Information Block (MIB 200) according to some embodiments is illustrated. In some embodiments, the network node may encode the MIB with an indication of whether eRedcap devices are barred from entering the cell. For example, spare bits 202 may be reused as the eRedcapCellBarred IE to indicate whether the cell is barred for Rel-18 eRedcap UEs.

[0040] In some embodiments, the physical broadcast channel (PBCH) payload can be used to indicate access restrictions by the network to Rel-18 eRedcap devices. For example, at least for the FR1 licensed band, one of the two reserved bits "a(6)" and "a(7)" in the PBCH payload can be reinterpreted as an eRedcapCellBarred IE to indicate whether the cell is barred for Rel-18 eRedcap UEs. The network node can set the eRedcapCellBarred IE in the PBCH payload to indicate whether the cell is barred.

[0041] Figure 3 The following illustrates a scheduling DCI format (e.g., DCI format 1_0 300) including an access restriction indication according to some embodiments. DCI format 1_0 300 may consist of an existing field 302 for scheduling, reserved bits 304, and a cyclic redundancy check field (CRC 306). In NR, 15 reserved bits 304 may be present in DCI format 1_0 with a cyclic redundancy check (CRC) scrambled by the system information-radio network temporary identifier (SI-RNTI). DCI format 1_0 300 may be used for scheduling SIB messages.

[0042] In some embodiments, one of the reserved bits 304 can be reinterpreted to indicate whether the cell is barred for Rel-18 eRedcap UEs. For example, one of the reserved bits 304 (e.g., a "spare" bit in the MIB payload) can be designated as the eRedCap barred field 308. The network node can set the eRedCap barred field 308 to indicate whether a Rel-18 eRedcap UE is barred from entering the cell. The Rel-18 eRedcap UE can receive and decode DCI format 1_0 300 to determine the barring status based on the eRedCap barred field 308.

[0043] Figure 4The eRedCap Barred IE 400 according to some embodiments is illustrated. In some embodiments, a new IE (e.g., eRedCap Barred IE 400) with a value of {barred, notBarred} may be introduced in SIB1 to indicate access restrictions for Rel-18 eRedcap devices. If a Rel-18 eRedcap UE is barred from entering the cell, the network node may set the eRedCap Barred IE 400 to barred, or if a Rel-18 eRedcap UE is allowed on the cell, the eRedCap Barred IE 400 may be set to not barred. The network node may transmit the eRedCap Barred IE 400 to the UE via SIB1.

[0044] The eRedCap prohibited IE 400 may include a cellBarredRedCap1Rx-r18 variable 402 and a cellBarredRedCap2Rx-r18 variable 404. The prohibited value means that the cell is prohibited for Rel-18 eRedCap UEs with 1Rx leg or 2Rx leg. The cellBarredRedCap1Rx-r18 variable 402 and the cellBarredRedCap2Rx-r18 variable 404 may be ignored by non-RedCap UEs.

[0045] Figure 5 Illustrated is a frequency domain resource allocation (FDRA 500) for a Rel-18e Redcap UE according to some embodiments. Some embodiments herein may use FDRA to reduce the bandwidth of a Rel-18e Redcap UE. As illustrated, FDRA 500 may be different for the uplink and downlink. In some embodiments, the uplink and downlink for a Rel-18e Redcap UE may have the same maximum number of resource blocks (RBs), however the arrangement of the RBs may be different. In some embodiments, downlink RBs 504 may be discontinuous, and uplink RBs 502 may be contiguous, and both may have the same maximum number of RBs for a Rel-18e Redcap UE.

[0046] In some embodiments, FDRA for uplink physical uplink shared channel (PUSCH) may appear as shown in uplink FDRA bandwidth 508. In some embodiments for Rel-18e Redcap, only uplink RB allocations of size 5. The active bandwidth portion of the continuous uplink RB 502 is within the active bandwidth portion of the continuous uplink RB 502.

[0047] Various alternatives may be considered to determine the possible maximum number of RBs that a UE may transmit: For example, in some embodiments, reusable corresponds to The value of 5MHz is configured for the maximum transmit bandwidth N RB .For example, RBs (15kHz subcarrier spacing (SCS)), and RBs (30kHz SCS). In this implementation, new implementations for Rel-18e Redcap UEs when component carriers (CCs) operate with 5MHz BW can be avoided.

[0048] In some embodiments, slack variables may be introduced to simplify the implementation. For example, in one possible embodiment, based on the current N defined for a 5 MHz CC, RB The new value of value can be defined as: Δ≥0, where the exact value is determined to ensure Thereby simplifying the UE specific implementation for the Fast Fourier Transform (FFT) operation and hence these exact values ​​can be SCS specific.Following this rule, Δ=0, 1 are used for 15kHz SCS and 30kHz SCS respectively.

[0049] In some embodiments, the FDRA for the downlink unicast physical downlink shared channel (PDSCH) may be as shown below in downlink FDRA bandwidth 506. In some embodiments, both contiguous (Type 1 RA) and non-contiguous RBs 504 (Type 0 RA) may be supported across RBs of size In this paper, the active uplink bandwidth portion (i.e., ) is expressed as Similarly, the maximum value of the active downlink bandwidth portion (i.e. ).

[0050] In some embodiments, for Rel-18e Redcap devices, different maximum bandwidth sizes may be supported in the downlink and uplink, including both frequency division duplex (FDD) systems and time division duplex (TDD) systems. For example, in some embodiments, In some embodiments, To ensure the same data processing requirements in downlink and uplink.

[0051] Embodiments herein may use various FDRA solutions to allocate contiguous RBs (e.g., contiguous uplink RBs 502) for PUSCH transmission. In some embodiments, for PUSCH resource allocation for eRedcap Rel-18 UEs, only uplink RA Type 1 (i.e., based on SLIV) may be supported. For RA Type 1 RA, the Resource Indication Value (RIV) field in the DCI may correspond to the length of the contiguously allocated RBs. For example, the length of the RB (L RB ) can be less than or equal to the minimum of the number of RBs and the value of the active uplink bandwidth portion. In other words, a bandwidth of size within the active bandwidth portion of in The maximum number of RBs supported by the Rel-18eRedcap device.

[0052] In some embodiments, the wireless communication system may support both Type 0 and Type 1 RA with the limitation of contiguous RBs. In other words, in these embodiments, both Type 0 and Type 1 RA are used for contiguous RBs. For RA Type 0 RA, the following subfields may be introduced for Rel-18 Redcap UEs to reduce DCI overhead. Subfield 1 may indicate the starting RBG index, denoted as RBG 起始 RBG_start. Therefore, subfield 1 may include an RGB index indicator. Subfield 2 may indicate Length field of 1 bit, where P represents the RBG size configured by RRC signaling. For FDRA Type 0 in 20 MHz BWP, in some embodiments, the RBG size can be configured as 4 or 8. Accordingly, 2 or 3 RBGs can be used for FDRA with RBG granularity. To improve resource efficiency, smaller RBG sizes, such as 2 or 3 RBs, can be introduced for eRedcap UEs.

[0053] Figure 6 A possible implementation is illustrated, where both Type 0 RA and Type 1 RA can be supported with the limitation of contiguous RBs. In the illustrated implementation, the RBG size (P) configured by RRC signaling is equal to 4 (i.e., P=4), =20MHz, and there is a 30kHz SCS. In the illustrated embodiment, if the Rel-17 type ORA is reused (e.g., Rel UE 604), the FDRA field can be 13 bits, and for the embodiment using the new subfield 1 and the new subfield 2 (e.g., Rel-18eRedCap UE 606), the FDRA field is reduced to 6 bits (subfield 1 is 4 bits and subfield 2 is 2 bits). Therefore, there may be a 50% overhead reduction and ultimately improved coverage. As shown in the figure, RBG 起始 Indicated by subfield 1, and subfield 2 may indicate the length (e.g., N RBG =2).

[0054] Figure 7 A method 700 for frequency domain resource allocation for a UE is illustrated. The UE may receive 702 a downlink control information (DCI) transmission from a network node. The DCI transmission may include FDRA information for a set of contiguously allocated resource blocks for a physical uplink shared channel (PUSCH).

[0055] For uplink resource allocation type 1, the FDRA information may include the value of the FDRA field indicating the starting resource block (RB) and the length of the consecutively allocated resource blocks. The length of the consecutively allocated resource blocks may correspond to the minimum of the following: the size of the active bandwidth portion and the maximum number of resource blocks supported by the eRedCap UE. For uplink resource allocation type 2, the FDRA information may include: a first subfield indicating the starting resource block group index; and a second subfield indicating a length field indicating the number of RB groups (RBGs) used for PUSCH transmission, where the length field is:

[0056]

[0057] in:

[0058] P represents the resource block group size configured by radio resource control (RRC) signaling,

[0059] is the maximum number of resource blocks supported by the eRedCap UE,

[0060] is the size of the active bandwidth portion.

[0061] The UE may be configured 704 to transmit on the contiguously allocated resource blocks.The UE may use the contiguous resource blocks to transmit 706 PUSCH data.

[0062] In some embodiments, the resource block group size configured by RRC signaling is two or three. In some embodiments, the method may include: configuring non-contiguous resource blocks in the active downlink bandwidth portion for a physical downlink shared channel (PDSCH). In some embodiments, the size of the maximum bandwidth of the active downlink bandwidth portion for PDSCH is greater than the size of the maximum bandwidth of the active uplink bandwidth portion for PUSCH. In some embodiments, the first maximum number of resource blocks allocated for PDSCH is equal to the second maximum number of resource blocks allocated for PUSCH. Some embodiments may also include: receiving an indication from the network node that the eRedCap device is disabled or not disabled. In some embodiments, the indication may be provided by reusing sparse bits in the Master Information Block (MIB) payload; or reinterpreting one of the two reserved bits in the Physical Broadcast Channel (PBCH) payload for at least the FR1 licensed band; or reusing one of the fifteen reserved bits in DCI format 1_0 with a cyclic redundancy check field (CRC) scrambled by the System Information-Radio Network Temporary Identifier (SI-RNTI); or introducing a new information element (IE) in the System Information Block 1 (SIB1). In some embodiments, the method may include determining a frequency offset value for the PUCCH explicitly configured by a SIB1 message. In some embodiments, the method may also include using an orthogonal code or orthogonal root sequence for the PUCCH explicitly configured by a SIB1 message or hard-coded in the specification for the eRedCap UE. In some embodiments, the method may also include sending an indication to the network node that the eRedCap UE is an eRedCap device. In some embodiments, eRedcap devices are indicated by: PRACH transmissions on a separate initial uplink bandwidth portion; or PRACH resources configured by SIB1 within the shared initial uplink bandwidth portion; or two dedicated common control channel (CCCH) identifiers (IDs) used by Message 3 (Msg3) in a 4-step RACH procedure or MsgA PUSCH in a 2-step RACH procedure. In some embodiments, the use of CCCH IDs in Msg3 PUSCH or MsgA PUSCH is explicitly enabled by SIB1 or always defaults to eRedcap devices, or the use of PRACH transmissions for early identification of eRedcap devices is explicitly enabled or disabled by SIB1 messages.

[0063] Embodiments contemplated herein include an apparatus comprising means for performing one or more elements of method 700. The apparatus may be, for example, an apparatus of a UE, such as wireless device 1302 (UE), as described herein.

[0064] Embodiments contemplated herein include one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 700. The non-transitory computer-readable medium may be, for example, a memory of a UE (such as memory 1306 of wireless device 1302 (UE), as described herein).

[0065] Embodiments contemplated herein include an apparatus comprising logical components, modules, or circuits operable to perform one or more elements of method 700. The apparatus may be, for example, an apparatus of a UE, such as wireless device 1302 (UE), as described herein.

[0066] Embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 700. The apparatus may be, for example, a UE, such as wireless device 1302 (UE), as described herein.

[0067] Embodiments contemplated herein include a signal as described in or associated with one or more elements of method 700 .

[0068] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processor causes the processor to perform one or more elements of the method 700. The processor may be a processor of a UE (such as the processor 1304 of the wireless device 1302 (UE), as described herein). These instructions may be located, for example, in the processor and / or in a memory of the UE (such as the memory 1306 of the wireless device 1302 (UE), as described herein).

[0069] Figure 8 A method for frequency domain resource allocation for a network node is illustrated 800. The network node may encode 802 a downlink control information (DCI) transmission for an eRedCap UE. The DCI transmission may include FDRA information for a set of contiguously allocated resource blocks for a physical uplink shared channel (PUSCH).

[0070] For uplink resource allocation type 1, the FDRA information may include a resource indication value field indicating the length of the consecutively allocated resource blocks. The length of the consecutively allocated resource blocks may correspond to the minimum of the following: the size of the active bandwidth portion and the maximum number of resource blocks supported by the eRedCap UE. For uplink resource allocation type 2, the FDRA information may include: a first subfield indicating the starting resource block group index; and a second subfield indicating the length field, which may be:

[0071]

[0072] in:

[0073] P represents the resource block group size configured by radio resource control (RRC) signaling,

[0074] is the maximum number of resource blocks supported by the eRedCap UE,

[0075] is the size of the active bandwidth portion.

[0076] The network node may transmit 804 DCI to the eRedCap UE and receive 806 PUSCH data via consecutive resource blocks.

[0077] In some embodiments, the resource block group size configured by RRC signaling is two or three. In some embodiments, the method may include configuring non-contiguous resource blocks in the active downlink bandwidth portion for the physical downlink shared channel (PDSCH). In some embodiments, the maximum bandwidth of the active downlink bandwidth portion for the PDSCH is greater than the maximum bandwidth of the active uplink bandwidth portion for the PUSCH. In some embodiments, the first maximum number of allocated resource blocks for the PDSCH is equal to the second maximum number of allocated resource blocks for the PUSCH. In some embodiments, the method may include transmitting an indication to the eRedCap UE that the eRedCap device is disabled or not disabled. In some embodiments, the method may include determining a frequency offset value for the PUCCH explicitly configured by a SIB1 message. In some embodiments, the method may include using an orthogonal code or orthogonal root sequence for the PUCCH that is explicitly configured by a SIB1 message or hard-coded in the specification for the eRedCap UE. In some embodiments, the method may include receiving an indication that the eRedCap UE is an eRedCap device.

[0078] Embodiments contemplated herein include an apparatus comprising means for performing one or more elements of method 800. The apparatus may be, for example, an apparatus of a base station, such as network device 1318 (base station), as described herein.

[0079] Embodiments contemplated herein include one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of method 800. The non-transitory computer-readable medium may be, for example, a memory of a base station (such as memory 1322 of network device 1318 (base station), as described herein).

[0080] Embodiments contemplated herein include an apparatus comprising logic, modules, or circuits operable to perform one or more elements of method 800. The apparatus may be, for example, a base station, such as network device 1318 (base station), as described herein.

[0081] Embodiments contemplated herein include an apparatus comprising one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method 800. The apparatus may be, for example, a base station, such as network device 1318 (base station), as described herein.

[0082] Embodiments contemplated herein include a signal as described in or associated with one or more elements of method 800 .

[0083] The embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processing element causes the processing element to perform one or more elements of method 800. The processor may be a processor of a base station (such as processor 1320 of network device 1318 (base station), as described herein). These instructions may be located, for example, in the processor and / or in a memory of the base station (such as memory 1322 of network device 1318 (base station), as described herein).

[0084] One of the design goals when introducing Rel-18 eRedCap UEs was to ensure coexistence with non-RedCap UEs and Rel-17 RedCap UEs. Therefore, some implementations include mechanisms for PUCCH orthogonality between eRedcap-PUCCH without frequency hopping and legacy PUCCH with frequency hopping.

[0085] When a separate initial uplink BWP is configured for a Rel-18eRedcap UE, in the RRC_IDLE state (i.e., before the UE is configured with a dedicated PUCCH resource set), various methods can be considered to configure the PUCCH resource set for Rel-18eRedcap UEs (PUCCH_eRedcap) and the PUCCH resource set for non-eRedcap UEs (PUCCH_Non_eRedcap). Because non-eRedcap UEs may use frequency hopping, while eRedcap UEs may not use frequency hopping, the following provides a method for reducing overlap between PUCCH resources.

[0086] Figure 9 The initial uplink BWP 912 for Rel-18 eRedCap and the initial uplink BWP 910 for non-eRedCap are illustrated. In some implementations, frequency hopping for common PUCCH resources for Rel-18 eRedCap can be explicitly enabled or disabled via SIB1 messaging. In the illustrated implementation, frequency hopping is disabled, and the eRedCap PUCCH resource sets (PUCCH 904 and PUCCH 914) do not change frequency. In contrast, the non-eRedCap PUCCH resource sets (PUCCH 902 and PUCCH 906) can use frequency hopping to utilize multiple frequencies.

[0087] Disabling frequency hopping for eRedCap PUCCH has several benefits. First, it enables coexistence with Rel-17 RedCap UEs that have a shared PUCCH resource set by disabling frequency hopping. Second, it avoids resource fragmentation and the corresponding reduction in peak data rate for non-RedCap UEs that only support PUSCH with continuous RA.

[0088] When frequency hopping for common PUCCH for Rel-18e Redcap is deactivated, the network may provide a new parameter to indicate to the UE an additional physical resource block (PRB) offset value ( 908). 908 can be selected from a set of values ​​hard-coded in the 3GPP specification. 908 may be added to the existing PRB offset value ( In some designs, the eRedcap UE may assume this parameter if the default value of '0' is not present in SIB1.

[0089] In some embodiments, when frequency hopping for common PUCCH resources for eRedCap is disabled, the UE may determine the PRB index for PUCCH transmission in one side of the uplink BWP by using one of the following formulas:

[0090]

[0091] in is the initial UL BWP for Rel-18e Redcap UE configured by SIB1.

[0092] Figure 10 Illustrate partially overlapping resource blocks of PUCCH resources according to some embodiments, where devices use different base sequences. Some embodiments may minimize inter-UE interference between eRedCap PUCCH 1006 without frequency hopping and non-RedCap PUCCH 1008 with frequency hopping within the initial uplink bandwidth portion 1004.

[0093] In some embodiments, different base sequences "m" may be used for different parts of the PUCCH for eRedcap UEs even if frequency hopping is not enabled. In some embodiments, orthogonal root sequences may exist for Rel-18 eRedcap UEs and other UEs with overlapping PUCCH sources. The symbol partitioning for the Redcap PUCCH may be determined based on the overlapping PUCCH resources used by non-Redcap UEs with FH.

[0094] Figure 11 The diagram illustrates partially overlapping resource blocks of PUCCH resources according to some embodiments, where devices use orthogonal codes to limit interference. As shown, within the initial uplink bandwidth portion, eRedCap PUCCH 1006 may not use frequency hopping, while non-RedCap PUCCH 1008 may use frequency hopping. This may result in times when PUCCH resources overlap (e.g., overlapping PUCCH resources 1106).

[0095] To limit interference, a new orthogonal code (OCC) with index X may be hard-coded in the specification or configured by SIB1, where X≠0. In some embodiments, X=[i / 2], where i is the number of PUCCH-eRedcap symbols. For example, Figure 11 In

[15] , i=8, where OCC#0 is used by non-Redcap UEs, and X=[i / 2]=[8 / 2]=4 for eRedcap UEs. This may result in orthogonality between resources to reduce interference.

[0096] Figure 12An example architecture of a wireless communication system 1200 according to the embodiments disclosed herein is illustrated. The following description is provided for an example wireless communication system 1200 operating in conjunction with the LTE system standard and / or the 5G or NR system standard provided in the 3GPP technical specifications.

[0097] like Figure 12 As shown, wireless communication system 1200 includes UE 1202 and UE 1204 (although any number of UEs may be used). In this example, UE 1202 and UE 1204 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing device configured for wireless communication.

[0098] UE 1202 and UE 1204 may be configured to be communicatively coupled to RAN 1206. In an embodiment, RAN 1206 may be an NG-RAN, E-UTRAN, or the like. UE 1202 and UE 1204 utilize connections (or channels) (shown as connection 1208 and connection 1210, respectively) with RAN 1206, where each connection (or channel) includes a physical communication interface. RAN 1206 may include one or more base stations (such as base station 1212 and base station 1214) that implement connection 1208 and connection 1210.

[0099] In this example, connection 1208 and connection 1210 are the air interfaces that enable such communicative coupling and may conform to the RAT used by RAN 1206, such as, for example, LTE and / or NR.

[0100] In some embodiments, UE 1202 and UE 1204 may also directly exchange communication data via side link interface 1216. UE 1204 is shown as being configured to access an access point (shown as AP 1218) via connection 1220. By way of example, connection 1220 may include a local wireless connection, such as a connection compliant with any IEEE 802.11 protocol, wherein AP 1218 may include In this example, AP 1218 may not be connected to another network (eg, the Internet) through CN 1224.

[0101] In an embodiment, UE 1202 and UE 1204 may be configured to communicate with each other or with base station 1212 and / or base station 1214 over a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication techniques, such as, but not limited to, orthogonal frequency division multiple access (OFDMA) communication techniques (e.g., for downlink communication) or single-carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or sidelink communication), although the scope of the embodiment is not limited in this respect. An OFDM signal may include multiple orthogonal subcarriers.

[0102] In some embodiments, all or part of base station 1212 or base station 1214 may be implemented as one or more software entities running on a server computer as part of a virtual network. Additionally, or in other embodiments, base station 1212 or base station 1214 may be configured to communicate with each other via interface 1222. In embodiments where wireless communication system 1200 is an LTE system (e.g., when CN 1224 is an EPC), interface 1222 may be an X2 interface. An X2 interface may be defined between two or more base stations (e.g., two or more eNBs, etc.) connected to an EPC and / or between two eNBs connected to an EPC. In embodiments where wireless communication system 1200 is an NR system (e.g., when CN 1224 is a 5GC), interface 1222 may be an Xn interface. An Xn interface may be defined between two or more base stations (e.g., two or more gNBs, etc.) connected to a 5GC, between base station 1212 (e.g., a gNB) and an eNB connected to a 5GC, and / or between two eNBs connected to a 5GC (e.g., CN 1224).

[0103] RAN 1206 is shown as being communicatively coupled to CN 1224. CN 1224 may include one or more network elements 1226 configured to provide various data and telecommunication services to customers / subscribers (e.g., UE 1202 and users of UE 1204) connected to CN 1224 via RAN 1206. The components of CN 1224 may be implemented in one physical device or separate physical devices that include components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium).

[0104] In an embodiment, CN 1224 may be an EPC, and RAN 1206 may be connected to CN 1224 via an S1 interface 1228. In an embodiment, S1 interface 1228 may be divided into two parts: an S1 user plane (S1-U) interface, which carries traffic data between base station 1212 or base station 1214 and a serving gateway (S-GW); and an S1 mobility management entity (S1-MME) interface, which is a signaling interface between base station 1212 or base station 1214 and an MME.

[0105] In an embodiment, CN 1224 may be a 5GC, and RAN 1206 may be connected to CN 1224 via an NG interface 1228. In an embodiment, NG interface 1228 may be divided into two parts: an NG user plane (NG-U) interface, which carries traffic data between base station 1212 or base station 1214 and a user plane function (UPF); and an S1 control plane (NG-C) interface, which is a signaling interface between base station 1212 or base station 1214 and an access and mobility management function (AMF).

[0106] Generally speaking, the application server 1230 may be an element that provides applications (e.g., packet-switched data services) that utilize Internet Protocol (IP) bearer resources with the CN 1224. The application server 1230 may also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for the UE 1202 and the UE 1204 via the CN 1224. The application server 1230 may communicate with the CN 1224 via the IP communication interface 1232.

[0107] Figure 13 A system 1300 is illustrated for performing signaling 1334 between a wireless device 1302 and a network device 1318 according to embodiments disclosed herein. System 1300 can be part of a wireless communication system as described herein. Wireless device 1302 can be, for example, a UE of the wireless communication system. Network device 1318 can be, for example, a base station (e.g., an eNB or gNB) of the wireless communication system.

[0108] The wireless device 1302 may include one or more processors 1304. The processor 1304 may execute instructions to cause various operations of the wireless device 1302 to be performed, as described herein. The processor 1304 may include one or more baseband processors implemented using, for example, a central processing unit (CPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a controller, a field programmable gate array (FPGA) device, another hardware device, a firmware device, or any combination thereof, configured to perform operations as described herein.

[0109] The wireless device 1302 may include a memory 1306. The memory 1306 may be a non-transitory computer-readable storage medium that stores instructions 1308, which may include, for example, instructions to be executed by the processor 1304. The instructions 1308 may also be referred to as program code or a computer program. The memory 1306 may also store data used by the processor 1304 and results computed by the processor.

[0110] The wireless device 1302 may include one or more transceivers 1310, which may include radio frequency (RF) transmitter and / or receiver circuitry that uses an antenna 1312 of the wireless device 1302 to facilitate signaling (e.g., signaling 1334) to and / or from the wireless device 1302 with other devices (e.g., network device 1318) in accordance with a corresponding RAT.

[0111] The wireless device 1302 may include one or more antennas 1312 (e.g., one, two, four, or more). For embodiments with multiple antennas 1312, the wireless device 1302 may utilize the spatial diversity of such multiple antennas 1312 to transmit and / or receive multiple different data streams on the same time-frequency resources. This behavior may be referred to as, for example, multiple-input, multiple-output (MIMO) behavior (referring to the multiple antennas used at each of the transmitting and receiving devices to implement this aspect). MIMO transmissions by the wireless device 1302 may be implemented based on precoding (or digital beamforming) applied to the wireless device 1302, which multiplexes the data streams across the antennas 1312 based on known or assumed channel characteristics, such that each data stream is received at an appropriate signal strength relative to the other streams and at a desired location in the spatial domain (e.g., the location of the receiver associated with the data stream). Certain embodiments may use single-user MIMO (SU-MIMO) methods (where data streams are all directed to a single receiver) and / or multi-user MIMO (MU-MIMO) methods (where separate data streams may be directed to separate (different) receivers in different locations in the spatial domain).

[0112] In certain embodiments with multiple antennas, the wireless device 1302 may implement analog beamforming techniques whereby the phases of the signals transmitted by the antennas 1312 are adjusted relative to each other so that the (joint) transmissions of the antennas 1312 can be directed (this is sometimes referred to as beam steering).

[0113] The wireless device 1302 may include one or more interfaces 1314. The interfaces 1314 may be used to provide input to or output from the wireless device 1302. For example, the wireless device 1302 (UE) may include interfaces 1314, such as a microphone, a speaker, a touch screen, and buttons, to allow a user of the UE to provide input to and / or output to the UE. Other interfaces of such a UE may consist of transmitters, receivers, and other circuits (e.g., in addition to the transceiver 1310 / antenna 1312 already described) that allow the UE to communicate with other devices, and may communicate according to known protocols (e.g., and etc.) to perform the operation.

[0114] The wireless device 1302 may include a configuration module 1316. The configuration module 1316 may be implemented via hardware, software, or a combination thereof. For example, the configuration module 1316 may be implemented as a processor, circuitry, and / or instructions 1308 stored in the memory 1306 and executed by the processor 1304. In some examples, the configuration module 1316 may be integrated within the processor 1304 and / or the transceiver 1310. For example, the configuration module 1316 may be implemented via a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuits) within the processor 1304 or the transceiver 1310.

[0115] The configuration module 1316 may be used in various aspects of the present disclosure, for example, Figures 1 to 11 The configuration module 1316 is configured to transmit an indication that the wireless device 1302 is an eRedCap device, receive an indication instructing the network device 1318 to allow or prohibit the eRedCap device, and configure the wireless device 1302 for communication with the network device 1318.

[0116] The network device 1318 may include one or more processors 1320. The processor 1320 may execute instructions to cause various operations of the network device 1318 to be performed, as described herein. The processor 1320 may include one or more baseband processors implemented using, for example, a CPU, a DSP, an ASIC, a controller, an FPGA device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

[0117] Network device 1318 may include memory 1322. Memory 1322 may be a non-transitory computer-readable storage medium that stores instructions 1324 (which may include, for example, instructions to be executed by processor 1320). Instructions 1324 may also be referred to as program code or a computer program. Memory 1322 may also store data used by processor 1320 and results computed by the processor.

[0118] The network device 1318 may include one or more transceivers 1326, which may include RF transmitter and / or receiver circuitry that uses an antenna 1328 of the network device 1318 to facilitate signaling (e.g., signaling 1334) to and / or from the network device 1318 with other devices (e.g., wireless device 1302) according to a corresponding RAT.

[0119] The network device 1318 may include one or more antennas 1328 (e.g., one, two, four, or more). In embodiments with multiple antennas 1328, the network device 1318 may perform MIMO, digital beamforming, analog beamforming, beam steering, etc., as described.

[0120] The network device 1318 may include one or more interfaces 1330. The interfaces 1330 may be used to provide input to or output from the network device 1318. For example, the network device 1318 (base station) may include an interface 1330 comprised of a transmitter, a receiver, and other circuitry (e.g., in addition to the transceiver 1326 / antenna 1328 already described) that enables the base station to communicate with other equipment in the core network and / or enables the base station to communicate with external networks, computers, databases, etc., for the purpose of operating, managing, and maintaining the base station or other equipment operatively connected to the base station.

[0121] The network device 1318 may include an eRedCap configuration module 1332. The eRedCap configuration module 1332 may be implemented via hardware, software, or a combination thereof. For example, the eRedCap configuration module 1332 may be implemented as a processor, circuitry, and / or instructions 1324 stored in the memory 1322 and executed by the processor 1320. In some examples, the eRedCap configuration module 1332 may be integrated within the processor 1320 and / or the transceiver 1326. For example, the eRedCap configuration module 1332 may be implemented via a combination of software components (e.g., executed by a DSP or general-purpose processor) and hardware components (e.g., logic gates and circuits) within the processor 1320 or the transceiver 1326.

[0122] The eRedCap configuration module 1332 may be used in various aspects of the present disclosure, for example, Figures 1 to 11 The eRedCap configuration module 1332 is configured to determine that the UE is an eRedCap device, configure the eRedCap device, or notify the eRedCap device that it is barred.

[0123] For one or more embodiments, at least one of the components described in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and / or methods as described herein. For example, a baseband processor as described herein in conjunction with one or more of the preceding figures may be configured to operate according to one or more of the examples described herein. For another example, circuitry associated with a UE, base station, network element, etc., as described above in conjunction with one or more of the preceding figures, may be configured to operate according to one or more of the examples described herein.

[0124] Unless expressly stated otherwise, any of the embodiments described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. In view of the teachings above, modifications and variations are possible or may be obtained from the practice of the various embodiments.

[0125] Embodiments and implementations of the systems and methods described herein may include various operations that may be embodied in machine-executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). A computer system may include hardware components that include specific logic for performing the operations; or may include a combination of hardware, software, and / or firmware.

[0126] It should be appreciated that the systems described herein include descriptions of specific embodiments. These embodiments may be combined into a single system, partially combined into other systems, separated into multiple systems, or otherwise divided or combined. In addition, it is contemplated that parameters, attributes, aspects, etc. of one embodiment may be used in conjunction with another embodiment. For clarity, these parameters, attributes, aspects, etc. are described only in relation to one or more embodiments, and it should be appreciated that these parameters, attributes, aspects, etc. may be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment unless expressly stated otherwise herein.

[0127] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly stated to users.

[0128] Although the foregoing has been described in considerable detail for purposes of clarity, it will be apparent that certain changes and modifications may be made without departing from the principles of the invention. It should be noted that there are many alternative ways of implementing both the processes and the apparatus described herein. The embodiments of the present invention are therefore to be considered illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

1. A method for an enhanced reduced capability (eRedCap) user equipment (UE), the method comprising: receiving a downlink control information (DCI) transmission from a network node, wherein the DCI transmission includes frequency domain resource allocation (FDRA) information of allocated contiguous resource blocks for a physical uplink shared channel (PUSCH), Wherein, for uplink resource allocation type 1, the FDRA information includes a value of an FDRA field indicating a starting resource block (RB) and a length of the allocated consecutive resource blocks, wherein the length of the allocated consecutive resource blocks corresponds to a minimum value of: the size of the active bandwidth portion, and The maximum number of resource blocks supported by the eRedCap UE; configuring to transmit on the allocated contiguous resource blocks; and PUSCH data is sent using the allocated contiguous resource blocks.

2. The method according to claim 1, wherein for uplink resource allocation type 0, the FDRA information includes: A first subfield, wherein the first subfield indicates a starting resource block group index; and A second subfield, wherein the second subfield indicates a length field, the length field indicating the number of RB groups (RBGs) used for PUSCH transmission, wherein the length field is: Bit, in: P represents the resource block group size configured by radio resource control (RRC) signaling, is the maximum number of resource blocks supported by the eRedCap UE, and is the size of the active bandwidth portion. 3 . The method according to claim 2 , wherein the resource block group size configured by RRC signaling is two or three.

4. The method according to claim 1, further comprising: Non-contiguous resource blocks are configured in the active downlink bandwidth portion for the Physical Downlink Shared Channel (PDSCH). 5 . The method of claim 4 , wherein the size of the maximum bandwidth of the active downlink bandwidth portion for PDSCH is greater than the size of the maximum bandwidth of the active uplink bandwidth portion for PUSCH. 6 . The method of claim 4 , wherein a first maximum number of resource blocks allocated for the PDSCH is equal to a second maximum number of resource blocks allocated for the PUSCH.

7. The method according to claim 1, further comprising: An indication is received from the network node that the eRedCap device is barred or not barred.

8. The method of claim 7, wherein the indication is provided by: Reusing sparse bits in the Master Information Block (MIB) payload; or reinterpreting one of the two reserved bits in the Physical Broadcast Channel (PBCH) payload for at least the FR1 licensed band; or Reusing one of the fifteen reserved bits in DCI format 1_0 with a cyclic redundancy check field (CRC) scrambled by a system information - radio network temporary identifier (SI-RNTI); or A new information element (IE) is introduced in the system information block 1 (SIB1).

9. The method according to claim 1, further comprising: Determine the frequency offset value for PUCCH explicitly configured by the SIB1 message.

10. The method according to claim 1, further comprising: Use orthogonal codes or orthogonal root sequences for PUCCH that are explicitly configured by SIB1 messages or hard-coded in the specifications for eRedcap UEs.

11. The method according to claim 1 , further comprising: An indication that the eRedCap UE is an eRedCap device is sent to the network node.

12. The method of claim 11, wherein the eRedCap device is indicated by: PRACH transmission on a separate initial uplink bandwidth portion; or Share the PRACH resources configured by SIB1 within the initial uplink bandwidth; or Two dedicated Common Control Channel (CCCH) identifiers (IDs) used by Message 3 (Msg3) in a 4-step RACH procedure or MsgA PUSCH in a 2-step RACH procedure.

13. The method according to claim 12, wherein: The use of CCCH ID in Msg3 or MsgA PUSCH is explicitly enabled by SIB1 or always defaults for eRedcap devices, or The use of PRACH transmission to early identify that the eRedcap device is explicitly enabled or disabled by SIB1 messages.

14. A method for a network node, the method comprising: encoding a downlink control information (DCI) transmission for an enhanced reduced capability (eRedCap) user equipment (UE), wherein the DCI transmission includes frequency domain resource allocation (FDRA) information of allocated contiguous resource blocks for a physical uplink shared channel (PUSCH), Wherein, for uplink resource allocation type 1, the FDRA information includes a value of an FDRA field indicating a starting resource block (RB) and a length of the allocated consecutive resource blocks, wherein the length of the allocated consecutive resource blocks corresponds to a minimum value of: the size of the active bandwidth portion, and The maximum number of resource blocks supported by the eRedCap UE; transmitting the DCI to the eRedCap UE; as well as PUSCH data is received via the allocated contiguous resource blocks.

15. The method according to claim 14, wherein for uplink resource allocation type 2, the FDRA information includes: A first subfield, wherein the first subfield indicates a starting resource block group index; and A second subfield, wherein the second subfield indicates a length field, the length field indicating the number of RB groups (RBGs) used for PUSCH transmission, wherein the length field is: Bit, in: P represents the resource block group size configured by radio resource control (RRC) signaling, is the maximum number of resource blocks supported by the eRedCap UE, and is the size of the active bandwidth portion. The method according to claim 15 , wherein the resource block group size configured by RRC signaling is two or three.

17. The method according to claim 14, further comprising: Non-contiguous resource blocks are configured in the active downlink bandwidth portion for the Physical Downlink Shared Channel (PDSCH).

18. The method of claim 17, wherein the size of the maximum bandwidth of the active downlink bandwidth portion for the PDSCH is greater than the size of the maximum bandwidth of the active uplink bandwidth portion for the PUSCH.

19. The method of claim 17, wherein a first maximum number of allocated resource blocks for the PDSCH is equal to a second maximum number of resource blocks allocated for the PUSCH.

20. The method according to claim 14, further comprising: An indication is transmitted to the eRedCap UE that the eRedCap device is barred or not barred.

21. The method according to claim 14, further comprising: Determine the frequency offset value for PUCCH explicitly configured by the SIB1 message.

22. The method according to claim 14, further comprising: Use orthogonal codes or orthogonal root sequences for PUCCH that are explicitly configured by SIB1 messages or hard-coded in the specifications for eRedcap UEs.

23. The method according to claim 14, further comprising: An indication is received that the eRedCap UE is an eRedCap device.

24. An apparatus comprising means for performing the method according to any one of claims 1 to 23. 25 . A computer-readable medium comprising instructions, which, when executed by one or more processors of an electronic device, cause the electronic device to perform the method according to claim 1 .

26. An apparatus comprising logic components, modules or circuits for performing the method according to any one of claims 1 to 23.

Images