Wireless terminal, base station, method in wireless terminal, and method in base station

Abstract

To provide an alternative method and device for user equipment (UE) to efficiently and flexibly determine specific physical uplink control channel (PUCCH) resources that the UE is expected to use.SOLUTION: In a cellular communication system, a base station has a system bandwidth and communicates with UE via an associated cell, the system bandwidth including a partial band having a set of contiguous physical resource blocks. The base station initiates a random access procedure for the UE, provides first information identifying a set of frequency resources for an uplink channel, and provides second information identifying at least one particular frequency resource within the set of frequency resources for uplink communication. The first information is provided before the random access procedure is completed.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] The present invention relates to a wireless terminal, a base station, and a method therein, particularly but not exclusively to a wireless terminal, a base station, and a method therein that operate in accordance with the 3GPP (3rd Generation Partnership Project) standard or an equivalent or derivative standard, and in particular but not exclusively to the provision of control channels and resource allocation in so-called "next generation" systems. [Background technology]

[0002] The latest developments in 3GPP standards are referred to as LTE (Long Term Evolution) with EPC (Evolved Packet Core) networks and E-UTRAN (Evolved UMTS Terrestrial Radio Access Network), commonly referred to as 4G. Furthermore, the terms 5G and NR (New Radio) refer to evolving communication technologies expected to support various applications and services. Details of 5G networks are described, for example, in the NGMN 5G White Paper V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, available at https: / / www.ngmn.org / 5g-white-paper.html. 3GPP plans to support 5G through the so-called 3GPP NextGen (Next Generation) RAN (Radio Access Network) and 3GPP Next Generation Core Network. 3GPP Technical Specification 23.799 V14.0.0 describes the overall architecture and general procedures of the NextGen (5G) system being considered for Release 14 of the 3GPP standards. 3GPP is also exploring the possibility of using frequency bands up to 100 GHz for new (5G) radio access networks.

[0003] In 3GPP standards, a NodeB (or "eNB" in LTE, "gNB" in 5G, etc.) is a base station through which communication devices (user equipment, or "UE") connect to a core network and communicate with other communication devices or remote servers. For simplicity, in this application, the term base station will refer to any such base station, and the term mobile device or UE will refer to any such communication device. The core network (i.e., EPC in the case of LTE) is responsible for subscriber management, mobility management, charging, security, and call session management (etc.) functions, and connects communication devices to external networks such as the Internet.

[0004] The communication device may be, for example, a mobile communication device such as a mobile phone, a smartphone, user equipment, a personal digital assistant, a laptop / tablet computer, a web browser, an e-reader, etc. Such mobile (or generally fixed) devices are typically operated by a user, although so-called Internet of Things (IoT) devices and similar machine-type communication (MTC) devices may also be connected to the network. For simplicity, this application will refer to mobile devices (or UE) throughout the specification, but it will be understood that the techniques described herein may be implemented on any (mobile and / or generally fixed) communication device capable of connecting to a communication network and transmitting and receiving data, regardless of whether the communication device is controlled by human input or by software instructions stored in a memory.

[0005] Recent advances in communications have significantly increased the use of MTC devices, which are network devices configured to communicate and operate without human assistance. Examples of such devices include smart meters that can be configured to take measurements and relay these measurements to other devices over a communications network. Standards for MTC devices support a reduced bandwidth of 1.4 MHz in the downlink and uplink. As such, some MTC devices (referred to as "reduced-bandwidth MTC devices") may support only a limited bandwidth (typically 1.4 MHz) compared to the overall system bandwidth and / or may have fewer / simplified components. This allows such "reduced-bandwidth" MTC devices to be manufactured more economically than MTC devices that support larger bandwidths and / or have more complex components. It may be understood that other types of MTC devices and / or UEs may support different bandwidths that are smaller than the system bandwidth used in some cells (even if the bandwidth supported by these devices is greater than 1.4 MHz).

[0006] To communicate via a base station, a communication device needs to monitor the control channels operated by the base station. Physical control channels are transmitted in a collection of one or more consecutive CCEs (Control Channel Elements). One of these physical control channels, the so-called PDCCH (Physical Downlink Control CHannel), carries downlink assignment scheduling and related control information to individual communication devices. The so-called PUCCH (Physical Uplink Control CHannel) carries a set of information called "UCI (Uplink Control Information)" from a communication device to a serving base station. UCI includes, among other things, so-called HARQ (Hybrid Automatic Repeat Request) feedback, which is generated by a communication device and sent to a serving base station in response to downlink data transmissions received from the base station. UCI may also include a CQI (Channel Quality Indication), although this is optional. It may be understood that in NextGen systems, the physical uplink control channel may be referred to as "NR-PUCCH."

[0007] In LTE, depending on the specific configuration applied to a cell, the PUCCH region typically occupies both ends of the system bandwidth to support "slot hopping." (Slot hopping is a technique for improving frequency diversity by frequently changing the location of PUCCH physical resources between the ends of the cell bandwidth, which helps improve signal reception at the UE.) However, this existing (LTE-specific) design cannot easily be reused for 5G NR systems because transceivers that may be installed in different UEs (e.g., MTC devices) designed for different application scenarios support different operating bandwidths, which may be smaller than the system bandwidth. Thus, while most UEs are expected to support simultaneous reception over the entire system bandwidth (up to 1 GHz for NR), some UEs (e.g., MTC devices) with relatively limited bandwidth (compared to the system bandwidth of a given cell) may not be able to successfully receive all PUCCH data transmitted near the edges of the system bandwidth.

[0008] To address this issue, 3GPP is currently discussing allocation of PUCCH resources to subbands and new PUCCH designs for NR. In this context, the term "BandWidth Part" (BWP) refers to a (contiguous) portion of the system bandwidth that has a bandwidth substantially equal to (or smaller than) the radio frequency bandwidth supported by a specific UE (or group of UEs). Providing a BWP can be particularly beneficial for, for example, MTC devices that have an operating bandwidth smaller than the system bandwidth in a given cell. It can be understood that a (UE-specific) PUCCH region can be provided near the edge of a given BWP, i.e., within the radio frequency bandwidth supported by the UE using that BWP. 3GPP has agreed to include PUCCH resources associated with each configured UL BWP in each serving cell where a PUCCH is configured to support reduced UE bandwidth capabilities within a wideband carrier. 3GPP also anticipates that a downlink (or uplink) BWP configured for a given UE in a serving cell may overlap in the frequency domain with another downlink (or uplink) BWP configured in that cell.

[0009] However, allocating a PUCCH region near the edge of the radio frequency bandwidth supported by the UE (as opposed to a PUCCH region near the edge of the system bandwidth) may result in a fragmented utilization of the frequency spectrum available to the base station, which may hinder continuous uplink transmissions (as some UE PUCCH regions would need to be located outside the system bandwidth edge, resulting in a fragmented portion of the system bandwidth available for data transmission). It can be appreciated that when multiple BWPs are provided within a cell, channels of a particular BWP may overlap (at least partially) with one or more channels of different BWPs, and collisions may occur between these channels. For example, collisions may occur between the PUCCH of a first BWP and the so-called PUSCH (Physical Uplink Shared Channel) of a second BWP.

[0010] FIG. 4 outlines several options and potential issues for providing BWP-specific PUCCHs in an NR system. Specifically, "Option A" shows that simply reusing existing LTE designs for allocating PUCCH resources for each UL BWP may result in PUSCH and / or PUCCH collisions in BWPs that overlap in the frequency domain within the same slot (denoted as "BWP1" and "BWP2" in FIG. 4). PUSCH1 / PUCCH1 and PUSCH2 / PUCCH2 represent the PUSCHs / PUCCHs of BWP1 and BWP2, respectively. Alternatively, as shown in "Option B," the base station may be configured to address PUSCH collisions between two overlapping BWPs by scheduling a reduced bandwidth for the PUSCH of one of the two overlapping BWPs (e.g., the BWP with a relaxed PUSCH error rate requirement). However, even in this case, the channel "PUCCH1" collides with "PUSCH2," resulting in resource fragmentation for BWP2. Such fragmentation can be avoided only if the corresponding PUCCH1 resources can be configured in the area above PUCCH2. However, this option may complicate the system design and prevent the application of an integrated solution for configuring and indicating PUCCH resources. This can be avoided, for example, by minimizing the overlap of UL BWPs within the same slot from the network perspective, as shown in "Option C" in Figure 4.

[0011] Table 6 shows the set of PUCCH resource allocation parameters for different PUCCH formats and the range of possible values ​​for these parameters. 3GPP expects each UE to know in which slot the PUCCH is transmitted by the base station in order to identify the PUCCH resource associated with it. 3GPP agreed that in an NR system, a PUCCH resource set can be configured via higher layer signaling (from the base station to the UE) and that PUCCH resources within the configured set are indicated by DCI. It also agreed to specify rules for determining appropriate PUCCH resources, at least when a UE does not know its individual PUCCH resources (however, the details of such PUCCH resource determination rules, including whether to use implicit resource mapping and / or explicit signaling, are for further study).

[0012] Therefore, it is expected that a PUCCH resource set is configured for a UE via higher layer signaling (e.g., RRC (Radio Resource Control) signaling), and that a specific PUCCH resource within the configured set for transmitting hybrid automatic repeat request (Hybrid ARQ or HARQ) feedback ("HARQ-ACK") is dynamically indicated to the UE by DCI. However, the PUCCH resource set is not known on the UE side until RRC configuration is complete. For example, the UE already needs to provide HARQ-ACK feedback for the last message ("Msg4") of the four-step random access procedure. However, this message is received before RRC configuration is complete, i.e., before the base station can perform higher layer signaling for the UE and, as predicted by 3GPP, before it can configure the PUCCH resource set for that UE. Although various explicit and implicit approaches have been proposed to enable the UE to transmit HARQ-ACK on the allocated PUCCH resources, there is no agreement in 3GPP on how to address the issue of PUCCH resource allocation in NR when BWP is used. Summary of the Invention [Problem to be solved by the invention]

[0013] Therefore, a preferred exemplary embodiment of the present invention aims to provide an alternative method and apparatus that can be used to address the above problems while ensuring efficiency and flexibility, and that allows a UE to determine the specific PUCCH resources that the UE is expected to use.

[0014] To facilitate understanding by those skilled in the art, the present invention will be described in detail in the context of a 3GPP system (5G network), but the principles of the present invention can be applied to other systems. [Means for solving the problem]

[0015] In one exemplary aspect, the present invention provides a method, performed by a UE (User Equipment), for identifying frequency resources for uplink communication, the method including initiating a random access procedure; obtaining first information identifying a set of frequency resources for an uplink channel; obtaining second information identifying at least one particular frequency resource within the set of frequency resources for the uplink communication; and identifying the frequency resources for the uplink communication based on the first information and the second information, wherein the first information is obtained before a random access procedure is completed.

[0016] In another exemplary aspect, the present invention provides a method performed by a base station for identifying frequency resources for uplink communication by a UE, the method including initiating a random access procedure for the user equipment; providing first information identifying a set of frequency resources for an uplink channel; and providing second information identifying at least one particular frequency resource within the set of frequency resources for the uplink communication, the first information being provided before the random access procedure is completed.

[0017] Exemplary aspects of the invention extend to corresponding apparatus, systems, and computer programs, such as computer-readable storage media, storing instructions operable to program a programmable processor to perform the methods and possibilities recited in the claimed exemplary aspects above, and / or to program a suitably adapted computer to provide an apparatus as recited in any of the claims.

[0018] Each feature disclosed in this specification (including the claims) and / or shown in the drawings may be incorporated into the present invention independently (or in combination with) other disclosed and / or shown features. In particular, but without limitation, features of claims dependent on a particular independent claim may be introduced into that independent claim in any combination or individually. [Brief explanation of the drawings]

[0019] Examples of illustrative embodiments of the present invention will now be described with reference to the accompanying drawings, in which:

[0020] [Figure 1] FIG. 1 is a diagram that illustrates schematically a cellular communication system in which exemplary embodiments of the present invention may be applied. [Figure 2] FIG. 2 is a schematic block diagram of a mobile device forming part of the system shown in FIG. [Figure 3] FIG. 3 is a schematic block diagram of a base station forming part of the system shown in FIG. [Figure 4] FIG. 4 illustrates schematically some options available for providing control channels within sub-bands forming part of the system bandwidth of the base station shown in FIG. [Figure 5] FIG. 5 is a diagram illustrating several exemplary sub-bands within a sub-band of the system bandwidth of the base station shown in FIG. [Figure 6] FIG. 6 is an exemplary signaling (timing) diagram that schematically illustrates a method performed by components of the system shown in FIG. DETAILED DESCRIPTION OF THE INVENTION

[0021] <Summary> FIG. 1 illustrates a (cellular) communication network 1 in which user equipment 3 (mobile phones and / or other mobile devices) can communicate with each other via base stations 5 (e.g., "gNBs" in an NR network) using an appropriate radio access technology (RAT). In a 5G system, a base station includes one or more transmission and reception points (TRPs). As will be appreciated by those skilled in the art, while FIG. 1 illustrates six UEs 3 and one base station 5 for illustrative purposes, a system implementation typically includes other base stations and mobile devices.

[0022] Each base station 5 operates one or more cells associated via a TRP located at the base station (and / or one or more remotely located TRPs). In this example, for simplicity of explanation, the base station 5 operates a single cell with an associated system bandwidth. The base stations 5 are connected to the core network 7 (e.g., via appropriate gateways and / or user plane / control functions), and neighboring base stations are also connected to each other (directly or via appropriate base station gateways). The core network 7 may include, among other things, control plane management entities and user plane management entities, as well as one or more gateways (GWs) for providing connectivity between the base stations 5 and other networks (such as the Internet) and / or servers hosted outside the core network.

[0023] Each mobile device 3 can connect to a suitable cell (depending on its location, and other factors such as signal conditions, subscription data, capabilities, etc., as appropriate) by establishing an RRC connection with the base station 5 serving that cell. To establish such an RRC connection, the mobile device 3 must perform a so-called random access procedure with the base station 5, which typically includes four messages (called "Msg1" to "Msg4"). The mobile device 3 and the base station 5 (and other transmission points in the network) communicate over an appropriate air interface that depends on the RAT used. The mobile device 3 communicates with the core network node using so-called Non-Access Stratum (NAS) signaling, which is relayed between the mobile device 3 and the appropriate core network node by the serving base station 5 / TRP of the mobile device 3.

[0024] Some mobile devices 3-1 may include conventional user equipment such as mobile phones (e.g., smartphones) equipped with appropriate transceiver circuitry capable of communicating over a relatively wide bandwidth (e.g., the entire system bandwidth of the cell of the base station 5). Other mobile devices 3-2 (e.g., MTC devices) may be equipped with transceiver circuitry that supports simultaneous communication over a relatively narrow bandwidth (e.g., a bandwidth smaller than the system bandwidth of the cell of the base station 5).

[0025] To support both types of mobile devices 3-1 and 3-2 (and potentially other types of UEs), the base station 5 in this embodiment allocates one or more BWPs within the system bandwidth, with each BWP configured to support a specific operating bandwidth (smaller than but not exceeding the system bandwidth). From the base station 5's perspective, it may be beneficial to minimize the frequency domain overlap of UL BWPs within the same slot, to avoid the need for complex scheduler algorithm design and PUCCH resource configuration and indication mechanisms.

[0026] Furthermore, the base station 5 is configured to indicate to each mobile device 3 the appropriate (UE-specific) PUCCH resources so that the mobile device 3 can determine the PUCCH resources allocated to that mobile device 3 even if an RRC connection with the base station 5 is not established.

[0027] More specifically, the base station 5 may use either explicit or implicit mechanisms (or both) to indicate the allocation of PUCCH resources within a given BWP.

[0028] If the base station 5 uses explicit indication, the base station 5 may be configured to broadcast appropriate information (e.g., via so-called remaining minimum system information) indicating the (UE-specific) PUCCH resource set. Furthermore, the base station 5 may be configured to indicate to a given mobile device 3 the specific resource (e.g., a single resource from the potential PUCCH resource set) to be used for PUCCH transmission. For example, the base station 5 may use an appropriate field in the DCI scheduling of "Msg4" (the fourth and final message of the random access procedure). It is thus possible to indicate the PUCCH resource allocation to the mobile device before the establishment of the RRC connection with the base station 5 is complete.

[0029] The base station 5 may be configured to indicate the PUCCH resource set in an appropriately formatted random access response (i.e., "Msg2" preceding "Msg4") instead of broadcasting an explicit indication.

[0030] If the base station 5 uses implicit indication of the (potential) PUCCH resource set, the applicable (UE-specific) PUCCH resources are determined by appropriate cell-specific parameters (e.g. N pucch1 ) may be determined by the mobile device 3 based on the PUCCH resource of Msg4. In this case, the PUCCH resource of Msg4 may be determined by the mobile device 3 based on the PUCCH resource of Msg4, for example, based on Npucch1+ nCCE_index (n CCE_index may be derived based on a suitable formula known to the mobile device 3, such as (where Msg4 denotes the first index associated with the CCE of the PDCCH that schedules Msg4).

[0031] Advantageously, a combination of explicit indication and implicit determination can be used to dynamically signal PUCCH resources, reducing overhead (compared to other methods). When the base station 5 is configured to follow this method, the allocated PUCCH resources (n PUCCH,RI ) may be derived using the following formula:

[0032]

number

[0033] In another embodiment, the PUCCH resource allocated for Msg4 HARQ-ACK feedback transmission ( nPUCCH,RI ) may be derived using the following formula:

[0034]

number

[0035]

number

[0036] Alternatively, PUCCH resources within a particular PRB (n PUCCH,RI ) may be identified by an index k signaled separately by the detected PDCCH DCI, for example. In this case, 2 or 3 bits are sufficient for signaling the index k, with K=4 or 8, respectively. This approach allows the base station 5 to flexibly allocate resource indices (for PUCCH resources), for example to avoid collisions.

[0037] For both of the above alternatives, the index k (representing the index associated with a particular PUCCH resource within a given PRB) may be mapped to a CS (Cyclic Shift) and / or an OCC (Orthogonal Cover Code) by a predetermined look-up table or the like (known a priori by the mobile device 3 and the base station 5).

[0038] Other suitable formulas may be used, or the BWP may be divided into multiple subbands (to avoid resource fragmentation), each subband containing a set of contiguous PRBs, in which case the allocated PUCCH resources are provided within a particular subband.

[0039] <Mobile devices> FIG. 2 is a schematic block diagram illustrating the main components of the mobile device 3 (e.g., a mobile phone, other user equipment, etc.) shown in FIG. 1. As shown, the mobile device 3 includes a transceiver circuit 31 operable to transmit signals to and receive signals from a base station 5 via one or more antennas 33. The mobile device 3 includes a controller 37 that controls the operation of the mobile device 3. The controller 37 is associated with a memory 39 and connected to the transceiver circuit 31. It will be apparent that the mobile device 3 may include all of the standard functionality of a conventional mobile phone 3 (e.g., a user interface 35), although this functionality is not required for operation, and such functionality may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or downloaded, for example, via a communications network or from a removable data storage device (RMD).

[0040] Controller 37, in this example, is configured to control the overall operation of mobile device 3 by means of program or software instructions stored in memory 39. As shown, these software instructions include, among other things, an operating system 41, a communications control module 43, and an optional MTC module 45.

[0041] The communications control module 43 is operable to control communications between the mobile device 3 and its serving base station 5 (and with other communications devices, such as other mobile devices, core network nodes, etc., connected to that base station 5). The communications control module 43 also includes (among other things) a PUCCH and PUSCH portion for handling uplink communications via an associated uplink channel. Although not shown in FIG. 2 for simplicity, the communications control module 43 typically also includes a PDCCH and PDSCH portion for handling downlink communications via an associated downlink channel. The communications control module 43 is responsible for determining resources for the mobile device 3 to use and which subbands to allocate to the mobile device 3 (e.g., based on the bandwidth supported by the transceiver circuitry 31). The appropriate resources for the mobile device 3 to use may be determined based on one or more equations and / or (predetermined) lookup tables, as appropriate. The operating bandwidth (or current operating bandwidth) supported by the transceiver circuitry 31 may depend on whether the mobile device 3 operates as a conventional UE or as a machine-type device (using the associated MTC module 45).

[0042] If present, the MTC module 45 is responsible for performing machine-type communication tasks according to appropriate (eg, software) instructions.

[0043] <Base station> FIG. 3 is a schematic block diagram illustrating the main components of the base station 5 shown in FIG. 1. As shown, the base station 5 includes a transceiver circuit 51 for transmitting and receiving signals to and from communication devices (e.g., mobile devices 3 / user equipment) via one or more antennas 53 (e.g., antenna arrays / large-scale antennas), and a core network interface 55 (referred to as an "N2" interface in NR) for transmitting and receiving signals to and from network nodes in the core network 7. Although not shown, the base station 5 may be coupled to other base stations via appropriate interfaces (e.g., so-called "Xn" interfaces in NR). The base station 5 includes a controller 57 for controlling the operation of the base station 5. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 or may be downloaded, for example, via the communication network 1 or from a removable data storage device (RMD). The controller 57 is configured, in this example, to control the overall operation of the base station 5 via program or software instructions stored in the memory 59. As shown, these software instructions include, among other things, an operating system 61, a communication control module 63, and a partial band module 65.

[0044] The communication control module 63 is operable to control communications between the base station 5 and the mobile devices 3 (user equipment) and other network entities connected to the base station 5. The communication control module 63 also controls the respective flows of downlink user traffic and control data transmitted (via associated data radio bearers) to communication devices associated with that base station 5, including, for example, control data for determining the appropriate sub-band (including sub-bands, if necessary) for use by a particular mobile device 3 and the location of one or more resources carrying (control / data) channels within the associated BWP (e.g., related to the BWP and / or sub-band).

[0045] The subband module 65 is responsible for allocating an appropriate BWP (which may include multiple subbands) to the mobile devices 3 served by the base station 5. The subband module 65 is also responsible for explicitly and / or implicitly indicating the appropriate PUCCH resources allocated (within that BWP) to a particular mobile device 3.

[0046] For ease of understanding, the mobile device 3 and base station 5 have been described above as comprising multiple separate modules (e.g., a communications control module). While these modules may be provided in the manner described above for certain applications, e.g., by modifying an existing system to implement the present invention, for other applications, e.g., systems designed from the beginning with the features of the present invention in mind, these modules may be incorporated into the overall operating system or code, in which case they may not be recognized as separate entities. These modules may be implemented in software, hardware, firmware, or a combination thereof.

[0047] <Operation> As explained above, a base station 5 may provide multiple bandwidth portions within its cell, which may further include multiple sub-bands (etc.), and a mobile device 3 may be assigned to one of the bandwidth portions depending on its capabilities (e.g., depending on the current / supported operating bandwidth of its transceiver circuitry 31).

[0048] The base station 5 may be configured to perform one (or more) of the following methods to allocate the associated PUCCH resource set (a PUCCH resource set that the mobile device 3 can use even before the RRC configuration is complete) to the mobile device 3 (e.g., within a specific subband):

[0049] Method 1 - Explicit Instructions If the base station 5 is configured to follow this method, it may explicitly configure a set of (potential) PUCCH resources for the mobile device 3. For example, the base station 5 may be configured to broadcast appropriate information, e.g., via RMSI, indicating the (UE-specific) PUCCH resource set configured for the mobile device 3. In another embodiment, the base station 5 may be configured to indicate the PUCCH resource set in an appropriately formatted random access response ("RAR" or "Msg2" of the random access procedure) if the mobile device 3 does not know the dedicated resources.

[0050] The base station 5 may further be configured to indicate the specific resource (e.g., a single resource from the potential PUCCH resource set) to be used for PUCCH transmission, for example, using an appropriate field in the DCI scheduling of "Msg4" (the fourth and final message in the random access procedure) and / or any other appropriate message received by the mobile device 3 before completing the establishment of the RRC connection with the base station 5. In this case, the base station 5 needs to ensure that the number of PUCCH resources configured for transmitting HARQ-ACK feedback (for Msg4) is large enough to avoid PUCCH blocking (which may occur when multiple mobile devices 3 attempt to perform the random access procedure with the base station 5 at approximately the same time, in which case the PUCCH resource set may not be sufficient to carry the HARQ-ACK feedback from all these mobile devices 3). This problem can be solved, for example, by providing excess resources, but this may also affect spectral efficiency in some cases. To avoid or reduce radio resource inefficiencies and / or PUCCH resource blocking due to the use of pre-configured common PUCCH resources, the DCI for scheduling Msg4 can also be configured to include information about the allocated PRB (Physical Resource Block) (for a given UE) and the allocated sequence (e.g., cyclic shift of the base sequence) for Msg4 HARQ-ACK feedback, with less signaling overhead required.

[0051] The signaling overhead of explicitly indicating PRB indices may be reduced by employing an appropriate PRB indication technique. For example, a BWP may be divided into several virtual subbands, each with its own associated index value. In the example shown in FIG. 5, the BWP is divided into four subbands, each assigned an index number ranging from "0" to "3" (denoted as "SB0" to "SB3"), with each subband containing a set of contiguous PRBs (to avoid resource fragmentation). In other examples, the number of subbands per BWP may be different (e.g., 2, 8, 16, ...), provided that the mobile device 3 and the base station 5 are configured to use the same index (which may be preset or indicated by the base station via a system information broadcast, etc.). While the subbands shown in FIG. 5 are approximately equal in size, further flexibility may be achieved by defining subbands of different sizes as appropriate.

[0052] In the embodiment shown in Figure 5, the specific SB (subband) configured for PUCCH transmission of the mobile device 3 may be indicated using two bits of the RMSI (e.g., in an appropriate field / information element). The PRB index within the specific subband (if the subband is indicated in the RMSI) may be assigned using the [x] bit of the DCI scheduling the RAR (Msg2) or may be included in the RAR message itself. For example, N PRB If value = 100 (where N PRB denotes the total number of physical resource blocks per subband), the maximum number of bits for x (i.e., x max ) can be derived as follows:

[0053]

number

[0054] Therefore, it can be seen that several bits can be reserved for PRB indication. However, when allocating PUCCH resources near the edge of a subband, the value of x does not have to be equal to xmax (because the PRB index starts at the edge of the subband), which can further reduce the PRB signaling overhead. For example, a fixed value of 16 PRBs starting from the first PRB can be used, which is sufficient for the entire resources that need to be allocated during initial access.

[0055] Furthermore, the index of the appropriate initial CS can be indicated in the DCI scheduling Msg4 using 2 or 3 bits, in which case the same PRB can be assigned to multiple UEs with different cyclic shifts, thereby improving overall resource utilization efficiency.

[0056] Method 2 - Implicit Derivation It is also assumed that the base station 5 may implicitly configure a (potential) PUCCH resource set for the mobile device 3. If the base station 5 is configured to follow this method, the applicable PUCCH resources are determined by the mobile device 3 without wasting radio resources and without blocking PUCCH resources, while also reducing the associated DCI overhead. More specifically, the base station 5 may configure a (potential) PUCCH resource set for the mobile device 3 implicitly, without wasting radio resources and without blocking PUCCH resources, while also reducing the associated DCI overhead. pucch1 ) is broadcast via RMSI, the PUCCH resources for transmitting HARQ feedback for Msg4 are N pucch1 +n CCE_index It can be derived as (n CCE_index indicates the first index associated with the CCE of the PDCCH that schedules Msg4).

[0057] Method 3 - Combining explicit and implicit instructions The base station 5 may be configured to dynamically signal PUCCH resources using a combination of explicit indication and implicit determination, which may result in reduced overhead (compared to other methods). If the base station 5 is configured to follow this method, it may identify the particular PUCCH resource using any one of the following options:

[0058] Option 1: The base station 5 may be configured to use a modified version of the LTE design that allocates PUCCH resources at the edge of the BWP, in which case the resource index (n PUCCH,RI ) is n PUCCH,RI =N pucch1 +n CCE_index It can be derived as (n CCE_index is the CCE index of the DCI that schedules Msg4). Therefore, in this example, the mobile device 3 PUCCH,RI Advantageously, the HARQ feedback (ACK / NACK) for Msg4 may be transmitted over resources (PRBs) corresponding to N pucch1 To avoid the overhead associated with sending CCE_index is n PUCCH,RI =n CCE_index , it may be set to zero (or any fixed value).

[0059] Option 2: By dividing the BWP into four SBs, PUCCH resources may be flexibly scheduled in frequency regions that experience less interference than other regions within the BWP. The index of the specific SB scheduled for PUCCH transmission may be indicated via two bits in the RMSI.

[0060] In this case, there are two possible methods for deriving the PUCCH resources allocated within a given subband:

[0061] Option 2a: Start the PUCCH resource index for each SB from zero. Since the SB index is known, the allocated PUCCH resources within the SB (nPUCCH,RI ) is n PUCCH,RI =n CCE_index It may be derived as:

[0062] Option 2b: Allocated PUCCH resources (n PUCCH,RI ) may be derived using the following formula:

[0063]

number

[0064] In both options 2a and 2b, n CCE_index If y is too large, scheduling of DCI transmission for Msg4 may be limited to the first [y] CCEs in order to limit the size of the PUCCH resource in the initial access phase. For example, y may be 24.

[0065] Option 3: When multiple UEs receiving Msg4 in different DL slots transmit HARQ feedback using the same resource in an UL slot, resource collisions may occur in both Option 1 and Option 2. This can be avoided by modifying Option 2 to derive the PRB index of the PUCCH resource by the following formula:

[0066]

number

[0067] To avoid PUCCH resource collisions between UEs, the index of the initial cyclic shift is implicitly linked to the timing relationship between Msg4 and HARQ-ACK feedback transmission, allowing UEs to be distinguished based on their respective orthogonal sequences. The timing relationship between the reception of DCI in Msg4 and HARQ-ACK feedback is known to both the base station 5 and the mobile device 3. An index is assigned to this timing relationship, and the cyclic shift is determined according to a predefined mapping for the UE's HARQ-ACK transmission. Therefore, the base station 5 can distinguish PUCCHs transmitted from different mobile devices 3 within the same frequency resource based on the orthogonal sequences.

[0068] In summary, the appropriate PUCCH resource to be used by a particular mobile device 3 can be determined using both explicit and implicit mechanisms. Preferably, a combination of explicit and implicit indication may be used to identify PUCCH resources for Msg4 HARQ-ACK feedback transmission, which can reduce signaling overhead and radio resource waste (compared to other methods). In this case, the allocated PUCCH resource (n PUCCH,RI ) may be derived using the following formula:

[0069]

number

[0070] In another embodiment, the PUCCH resources (n PUCCH,RI ) may be derived using the following formula:

[0071]

number

[0072] Alternatively, PUCCH resources within a particular PRB (n PUCCH,RI) may be identified by an index k given by:

[0073]

number

[0074] Alternatively, PUCCH resources within a particular PRB (n PUCCH,RI ) may be identified by an index k signaled separately by the detected PDCCH DCI, for example. In this case, 2 or 3 bits are sufficient for signaling the index k, with K=4 or 8, respectively. This approach allows the base station 5 to flexibly allocate resource indices (for PUCCH resources), for example to avoid collisions.

[0075] For both of the above alternatives, the index k (representing the index associated with a particular PUCCH resource within a given PRB) may be mapped to the CS and / or OCC by a predetermined look-up table or the like (known in advance by the mobile device 3 and the base station 5).

[0076]

number

[0077] [Table 1]

[0078] Since CS separation is more effective in environments with relatively low delay spread (compared to OCC), and OCC is more effective at relatively low UE speeds (compared to CS separation), it is advantageous to predefine multiple lookup tables suitable for different cell types. The base station 5 may be configured to signal the lookup table to be used (within a given cell) in the RAR message (Msg2) or using an appropriate field (e.g., one bit) of the RMSI. For example, one bit shall be sufficient to indicate to the mobile device 3 whether to use the lookup table shown in Table 2 or Table 3 below (although multiple bits may be used if necessary).

[0079] Furthermore, since OCC is not applicable to PUCCH format 0, it may be advantageous to define different lookup tables for each PUCCH format (e.g., see Tables 3 and 5 for PUCCH format 1 with K=4 and K=8, respectively). Since the mobile device 3 knows the PUCCH format from the detected PUCCH DCI, it can select the appropriate table without requiring additional signaling.

[0080] [Table 2]

[0081] [Table 3]

[0082] [Table 4]

[0083] [Table 5]

[0084] Method 4 - Other parameter instructions The base station 5 may be configured to indicate some of the other parameters to the mobile device 3, including but not limited to: PUCCH format and length: Whether using explicit indication (Method 1) or a combination of implicit and explicit indication (Method 3), in a small cell configuration (e.g., in the case of a home base station), a short PUCCH is sufficient to reliably transmit HARQ-ACK feedback for Msg4. However, a long PUCCH with a longer transmission period may be required to avoid potential PUCCH coverage limitations. Since the base station 5 knows its cell size, it may be configured to indicate in the DCI scheduling the RAR whether a long or short PUCCH format is to be used. Another option is to indicate the PUCCH format (long or short) via a bit in the DCI scheduling Msg4 or via the RMSI of the UE performing initial access. This is particularly useful in large (macro) cells where mobile devices 3 located at the cell edge require a long PUCCH format, while mobile devices 3 located near the center of the cell (relatively close to the base station 5) can use a short PUCCH. In this case, the base station 5 may be configured to determine (and indicate) the PUCCH format applicable to each mobile device 3, for example, depending on the time elapsed between the RAR transmission (by a particular mobile device 3) and the successful reception of the corresponding Msg3 (by that mobile device 3), or by utilizing TA (Timing Advance) information. PUCCH length: As a simple approach, the number of symbols that allows reliable PUCCH decoding may be predetermined for each format depending on the numerology of the BWP (assigned to the mobile device 3). - Frequency resources for the second hop: For frequency hopping, it is also possible to mirror resources in the frequency domain (within the BWP), similar to slot hopping adopted in LTE. However, in order to obtain more advanced control and flexibility at the base station 5, the sub-bands for the second hop may be different (and may also be indicated using 2 bits of the RAR).

[0085] The overview of the above procedure is shown in FIG. 6, which is a signaling (timing) diagram schematically showing some exemplary ways in which the base station 5 indicates a set of PUCCH resources and / or a specific PUCCH resource to the mobile device 3.

[0086] <Parameters of PUCCH Resource Configuration for RRC Connected UE> In 3GPP, as shown in Table 6 below, an agreement has been reached on the parameters to be set for the PUCCH resource set. Therefore, for each parameter in Table 6, a set of values for the PUCCH resource set can be set respectively. Further, when the DCI (applicable to the UE) indicates the index of the corresponding PUCCH resource, each value may be determined by the UE. Alternatively (for example, when using an appropriate implicit resource indication mechanism), the values of some parameters may be derived implicitly. An entry in the PUCCH resource set corresponds to one column in Table 6. This resource is defined by a plurality of parameters shown in the rows of the table.

[0087] Note that in Table 6, parameters indicating "FFS: special value for implicit derivation" or "FFS: whether implicit derivation is also used" indicate that further discussion is required in the relevant 3GPP working group (e.g., RAN1) to determine whether to use implicit and / or explicit methods to determine specific parameters in PUCCH resource entries. When an implicit mechanism is used, the corresponding value range may be narrowed and / or a special value outside the value range may be added to indicate "implicit derivation" or the setting may be disabled completely. Therefore, the contents of Table 6 should be interpreted as merely an example.

[0088] In addition, in 3GPP, it is necessary to consider whether the same PUCCH resource set shown in Table 6 can be configured for PDSCH mapping type A (slot-based transmission) and type B (non-slot-based transmission) or whether different PUCCH resource sets can be configured.

[0089] Table 7 shows some examples of parameters that are set semi-statically (that is, each parameter in Table 7 can be set to an appropriate value).

[0090] [Table 6]

[0091] [Table 7]

[0092] <Modifications and Alternatives>

[0033] Exemplary embodiments have been described in detail above. As will be appreciated by those skilled in the art, numerous variations and alternatives to the above exemplary embodiments are possible and may still benefit from the inventions embodied therein. For purposes of explanation, some examples of these variations and alternatives are provided.

[0093] Several exemplary lookup tables have been presented above (Tables 1-5). However, other suitable lookup tables may be used, in which case the value of k is determined by the CS index and / or different values ​​of the OCC index. The value of k may be determined by any suitable parameter (e.g., CS index and parameters other than the OCC index) as appropriate.

[0094] The lookup table(s) may be factory-configured and / or operator-specific, in which case signaling of the lookup table to the mobile device 3 may not be necessary (e.g., the mobile device 3 may be configured to select the appropriate lookup table based on its current operator and / or cell).

[0095] In the above exemplary embodiment, the base station communicates with the mobile device using 3GPP wireless communication (radio access) technology. However, any other wireless communication technology (i.e., WLAN, Wi-Fi, WiMAX, Bluetooth, etc.) may be used between the base station and the mobile device in accordance with the above exemplary embodiment. The above exemplary embodiment is applicable to "non-mobile" or fixed user equipment in general.

[0096] For ease of understanding, the mobile device and base station have been described above as comprising a number of separate modules. While these modules may be provided in the manner described above for certain applications, e.g., by modifying an existing system to implement the present invention, for other applications, e.g., systems designed from the beginning with the features of the present invention in mind, these modules may be incorporated into the overall operating system or code, in which case they may not be recognized as separate entities.

[0097] The above exemplary embodiments describe multiple software modules. As will be appreciated by those skilled in the art, the software modules may be provided in compiled or uncompiled form, or may be supplied to a base station, mobility management entity, or mobile device as a signal over a computer network or on a recording medium. Furthermore, the functions performed by some or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is recommended to speed up updates to the base station or mobile device.

[0098] Each controller may include any suitable form of processing circuitry, including, but not limited to: one or more hardware-implemented computer processors; a microprocessor; a central processing unit (CPU); an arithmetic logic unit (ALU); input / output (IO) circuitry; internal memory / cache (program and / or data); processing registers; communication buses (e.g., control, data and / or address buses); direct memory access (DMA) functions; hardware or software-implemented counters, pointers, timers, etc.

[0099] The random access procedure may be a procedure for establishing an RRC connection.

[0100] Obtaining the first information may also include receiving at least a portion of the first information as part of broadcasted system information (e.g., in the RMSI portion of the system information) before initiating a random access procedure. Obtaining the first information may also include receiving at least a portion of the first information after initiating a random access procedure (e.g., via a second message (“Msg2”) in a random access procedure or a Random Access Response (RAR)). Obtaining the second information may include receiving at least a portion of the second information as part of the random access procedure (e.g., via a fourth message (“Msg4”) in a random access procedure).

[0101] The first information may include information identifying a subband (e.g., a subband within a partial band) of the system bandwidth of the base station, and the second information may include information identifying a particular frequency resource (e.g., at least one PRB) within the subband identified by the first information (e.g., at least one PRB within the subband relative to a PRB representing an edge of the subband).

[0102] The set of frequency resources may include a set of PRBs (eg, a set of consecutive PRBs that form part of the system bandwidth of the base station), and the specific frequency resource may include a specific PRB.

[0103] The channel may include a PUCCH. The uplink communication may include transmitting HARQ feedback (e.g., HARQ feedback for a fourth message (“Msg4”) in a random access procedure) to the base station.

[0104] The at least one particular frequency resource is identified using at least one formula. For example, the at least one particular frequency resource may be identified using at least one of the following formulas:

[0105]

number

[0106]

number

[0107]

number

[0108] The method may further include obtaining third information identifying whether a short or long PUCCH format is used. The third information (e.g., 1 bit) may be included in the DCI or RMSI scheduling Msg4.

[0109] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0110] The following detailed description provides an example of how the above exemplary embodiments may be implemented in the context of currently proposed 3GPP standards. While various features are described as essential or required, this is only true for proposed 3GPP standards, e.g., when other requirements of the standards are imposed. Therefore, these descriptions should not be construed as limiting the present invention in any way.

[0111] <1> Introduction In the last meeting, RAN1 discussed PUCCH resource allocation before RRC connection setup / initial access and reached the following agreement: Agreement: (RAN1#91) HARQ-ACK resource allocation before RRC connection setup: --Only supports PUCCH format 0 and 1 --Resource allocation is derived based on a 4-bit parameter in RMSI. ---Other details of FFS (no additional RRC impact) Agreement: PUCCH resource allocation in the presence of fallback DCI is performed using the same approach as for normal DCI. Agreement: When HARQ-ACK resource allocation is performed before RRC connection setup, the UE identifies the PUCCH resource from the set of resources derived from the RMSI using the same approach as in the case after RRC connection setup.

[0112] In this contribution, we discuss how to configure and allocate PUCCH resources for Msg4 HARQ-ACK feedback transmission during initial access / before RRC connection setup.

[0113] <2> PUCCH Resource Allocation Before RRC Configuration Before RRC configuration, most of the parameters that determine PUCCH resource allocation must be specified, except for a few parameters that can be signaled in the DCI format or RMSI. Based on this understanding, we propose to predefine the PUCCH format and its transmission parameters as shown in Table 8.

[0114] [Table 8]

[0115] The PUCCH format is one of {format 0-1 symbols, format 0-2 symbols, format 1-10 symbols, format 1-14 symbols} and can be dynamically signaled in the DCI or RAR message (Msg2) that schedules Msg4. In this case, 2 bits are sufficient.

[0116] Proposal 1: Predefine four PUCCH formats {format 0-1 symbol, format 0-2 symbol, format 1-10 symbol, format 1-14 symbol} for initial access with one format dynamically signaled in the DCI or RAR message (Msg2) scheduling Msg4.

[0117] Proposal 2: The values ​​of transmission parameters such as the number of symbols, starting symbol, and hopping resource for each PUCCH format are predefined and fixed.

[0118] Proposal 3: A formula or method for obtaining the initial frequency resource (PRB number), CS index, and time-domain OCC is defined for each PUCCH format.

[0119] When defining the PUCCH resource for initial access, it is important to include an offset to position the PUCCH resource away from the subband edge, if necessary, for example, if the edge of the BWP experiences high levels of interference. Since it was agreed from previous meetings to use four bits to derive the PUCCH resource during initial access, we therefore propose using only two of the four bits to signal the offset in a cell-specific manner, while reserving the remaining two bits for other purposes. In this case, as shown in Figure 5, to avoid resource fragmentation when each subband contains consecutive PRBs, the BWP is divided into four virtual subbands, indexed 0 through 3. This allows for flexibility in starting PUCCH resources in frequency regions that experience less interference than other regions within the BWP.

[0120] Based on the above description, we propose the following formula for PUCCH resource allocation for Msg4 HARQ-ACK feedback transmission:

[0121]

number

[0122] Parameter L min The main reason for adding ∑ i = 1 ⁢ ...

[0123]

number

[0124] The main concerns with Alt-1 include the inability of the gNB to perform flexible scheduling, such as changing the PUCCH resource index, because the cyclic shift is implicitly derived from the formula itself.

[0125] Alt-2: Identify the PUCCH resource within 1 PRB with index k signaled in the detected PDCCH DCI. 2 or 3 bits are sufficient for this, with K=4 or 8, respectively.

[0126] The advantage of Alt-2 is that, for example, the gNB can flexibly allocate resource indices to avoid collisions between Ack / Nack feedbacks from different UEs.

[0127] In both Alt-1 and Alt-2, a resource index k within one PRB can be mapped to a CSS and an OCC using a predefined lookup table.

[0128] Since CS separation is more effective in low delay spread environments and OCC is more effective at low UE speeds, it is advantageous to predefine multiple lookup tables suitable for different cell types. The lookup table to be used for each cell can be signaled in the RMSI, either in the RAR message (Msg2) or using one of the remaining two bits.

[0129] Proposal 4: The PUCCH resource for Msg4 HARQ-ACK feedback transmission is defined by the following formula:

[0130]

number

[0131] Proposal 5: Define two different lookup tables for the combination of CS and OCC in PUCCH format 1, and use one bit of the remaining two bits for signaling with RMSI.

[0132] <3> conclusion In this contribution, we discuss how to configure and allocate PUCCH resources for Msg4 HARQ-ACK feedback transmission during initial access / before RRC connection setup, and make the following proposals:

[0133] Proposal 1: Predefine four PUCCH formats {format 0-1 symbol, format 0-2 symbol, format 1-10 symbol, format 1-14 symbol} for initial access with one format dynamically signaled in the DCI or RAR message (Msg2) scheduling Msg4.

[0134] Proposal 2: The values ​​of transmission parameters such as the number of symbols, starting symbol, and hopping resource for each PUCCH format are predefined and fixed.

[0135] Proposal 3: A formula or method for obtaining the initial frequency resource (PRB number), CS index, and time-domain OCC is defined for each PUCCH format.

[0136] Proposal 4: The PUCCH resource for Msg4 HARQ-ACK feedback transmission is defined by the following formula:

[0137]

number

[0138] Proposal 5: Define two different lookup tables for the combination of CS and OCC in PUCCH format 1, and use one bit of the remaining two bits for signaling with RMSI.

[0139] A part or all of the above-described embodiments can be described as, but not limited to, the following supplementary notes.

[0140] (Appendix 1) 1. A method executed by a user equipment (UE) for identifying frequency resources for uplink communication, comprising: initiating a random access procedure; obtaining first information identifying a set of frequency resources for an uplink channel; obtaining second information identifying at least one particular frequency resource within the set of frequency resources for the uplink communication; and identifying the frequency resource for the uplink communication based on the first information and the second information; The method, wherein the first information is obtained before a procedure for establishing an RRC connection is completed.

[0141] (Appendix 2) The method described in Supplementary Note 1, wherein the random access procedure is a procedure for establishing an RRC connection.

[0142] (Appendix 3) 3. The method of claim 1 or 2, wherein obtaining the first information includes receiving at least a portion of the first information as part of broadcasted system information (e.g., in a Remaining Minimum System Information (RMSI) portion of the system information) before initiating the random access procedure.

[0143] (Appendix 4) 4. The method of any one of Supplementary Notes 1 to 3, wherein obtaining the first information includes receiving at least a portion of the first information after initiating a random access procedure (e.g., via a second message ("Msg2") in the random access procedure or a Random Access Response (RAR)).

[0144] (Appendix 5) 5. The method of claim 1, wherein obtaining the second information includes receiving at least a portion of the second information as part of the random access procedure (e.g., via a fourth message ("Msg4") in the random access procedure).

[0145] (Appendix 6) 6. The method of any one of Supplementary Notes 1 to 5, wherein the set of frequency resources includes a set of PRBs (Physical Resource Blocks) (e.g., a set of contiguous PRBs that form part of a system bandwidth of the base station), and the specific frequency resource includes a specific PRB.

[0146] (Appendix 7) the first information includes information identifying a sub-band (e.g., a sub-band within a partial band) of a system bandwidth of the base station; the second information includes information identifying a particular frequency resource (e.g., at least one PRB) within the subband identified by the first information (e.g., at least one PRB within the subband relative to a PRB representing an edge of the subband); 7. The method of any one of appendices 1 to 6.

[0147] (Appendix 8) 8. The method of any one of claims 1 to 7, wherein the uplink communication includes transmitting Hybrid Automatic Repeat Request (HARQ) feedback (e.g., HARQ feedback for a fourth message ("Msg4") in a random access procedure) to the base station.

[0148] (Appendix 9) 9. The method of any one of claims 1 to 8, wherein the at least one particular frequency resource is identified using at least one formula.

[0149] (Appendix 10) 10. The method of any one of Supplementary Notes 1 to 9, wherein the channel comprises a Physical Uplink Control Channel (PUCCH).

[0150] (Appendix 11) The at least one particular frequency resource is identified using at least one of the following formulas:

number

number

number

[0151] (Appendix 12) 12. The method of claim 10 or 11, further comprising obtaining third information that identifies whether a short or long PUCCH format is used.

[0152] (Appendix 13) The method described in Supplementary Note 12, wherein the third information (e.g., 1 bit) is included in DCI or RMSI scheduling Msg4.

[0153] (Appendix 14) 1. A method performed by a base station for identifying frequency resources for uplink communication by a user equipment, comprising: initiating a random access procedure for the user equipment; providing first information identifying a set of frequency resources for an uplink channel; and providing second information identifying at least one particular frequency resource within the set of frequency resources for the uplink communication; The method, wherein the first information is provided before a random access procedure is completed.

[0154] (Appendix 15) The method described in Supplementary Note 14, wherein the random access procedure is a procedure for establishing an RRC connection.

[0155] (Appendix 16) Providing the first information includes providing at least a portion of the first information as part of broadcast system information (e.g., in an RMSI portion of the system information) before the start of the random access procedure; 16. The method of claim 14 or 15, comprising transmitting

[0156] (Appendix 17) 17. The method of any one of claims 14 to 16, comprising, after initiating the random access procedure, sending at least one message including at least one of the first information and the second information.

[0157] (Appendix 18) 18. The method of any one of claims 14 to 17, wherein the channel includes a PUCCH and the specific resource is identified using at least one format.

[0158] (Appendix 19) A user equipment (UE) of a communication system, the UE comprising a controller and a transceiver; The above controller is Initiate a random access procedure, obtaining first information identifying a set of frequency resources for an uplink channel; obtaining second information identifying at least one particular frequency resource within the set of frequency resources for the uplink communication; Operable to identify the frequency resources for the uplink communication based on the first information and the second information; The first information is obtained by the UE before the random access procedure is completed.

[0159] (Appendix 20) 1. A base station for identifying frequency resources for uplink communication by user equipment, the base station comprising: a controller and a transceiver; The above controller is initiating a random access procedure for the user equipment; providing first information identifying a set of frequency resources for an uplink channel; and operable to provide second information identifying at least one particular frequency resource within the set of frequency resources for the uplink communication; The first information is provided to a base station before the random access procedure is completed.

[0160] (Appendix 21) 21. A system comprising the UE of Supplementary Note 19 and the base station of Supplementary Note 20.

[0161] (Appendix 22) 19. A computer executable program comprising computer executable instructions for causing a programmable communications device to perform the method of any one of clauses 1 to 18.

[0162] This application is based on and benefits from priority from UK Patent Application Nos. 1718999.4 filed November 16, 2017 and 1800393.9 filed January 10, 2018, the disclosures of which are incorporated herein by reference in their entireties.

Claims

1. means for receiving, from a base station, Remaining Minimum System Information (RMSI) including first information indicating a set of Physical Uplink Control Channel (PUCCH) format, a starting symbol, a number of symbols, and Cyclic Shift (CS) index-related information; means for receiving downlink control information (Downlink Control Information: DCI) from the base station using at least one control channel element (CCE); means for determining a physical resource block (PRB) index based on the CS index-related information and an index of a first CCE of the at least one CCE; A wireless terminal comprising:

2. means for transmitting, to a wireless terminal, Remaining Minimum System Information (RMSI) including first information indicating a set of Physical Uplink Control Channel (PUCCH) format, a starting symbol, a number of symbols, and Cyclic Shift (CS) index related information; means for transmitting downlink control information (Downlink Control Information: DCI) to the wireless terminal using at least one control channel element (CCE); A physical resource block (PRB) index is determined based on the CS index-related information and an index of a first CCE of the at least one CCE; Base station.

3. receiving, from a base station, Remaining Minimum System Information (RMSI) including first information indicating a set of Physical Uplink Control Channel (PUCCH) format, a starting symbol, a number of symbols, and Cyclic Shift (CS) index-related information; receiving downlink control information (DCI) from the base station using at least one control channel element (CCE); determining a physical resource block (PRB) index based on the CS index-related information and an index of a first CCE of the at least one CCE; 20. A method in a wireless terminal, comprising:

4. transmitting, to the wireless terminal, Remaining Minimum System Information (RMSI) including first information indicating a set of information related to a Physical Uplink Control Channel (PUCCH) format, a starting symbol, a number of symbols, and a Cyclic Shift (CS) index; transmitting downlink control information (DCI) to the wireless terminal using at least one control channel element (CCE); A physical resource block (PRB) index is determined based on the CS index-related information and an index of a first CCE of the at least one CCE; A method in a base station.

Images