Patent Description:
New Radio (NR) will support a bitfield in the downlink control information (DCI) to select the time-domain resource allocation for the physical uplink shared channel (PUSCH) and physical downlink shared channel (PDSCH) out of preconfigured entries in a table. Each entry in the table specifies a starting orthogonal frequency division multiplexing (OFDM) symbol and length in OFDM symbols of the allocation. Note that the starting OFDM symbol can be expressed either relative to the scheduling physical downlink control channel (PDCCH)/control channel resource set (CORESET) symbol(s) or in absolute OFDM symbol number within a slot or subframe.

There currently exist certain challenge(s). Although, NR is very flexible, for example, in that NR supports different ways how to distribute system information and supports slot-based transmissions and non-slot-based transmissions, using a single time-domain resource allocation table is very limiting and can restrict scheduling in many cases. One possible solution would be to increase the resource allocation table size and by that enable more time-domain resource allocations. However, a drawback of that solution would be an increased downlink control information (DCI) size because more bits are needed to select an appropriate resource allocation.

Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges. The present invention is set out in the independent claims whereas preferred embodiments and further implementations are outlined in the dependent claims, description, and figures.

There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. Certain embodiments may provide one or more of the following technical advantage(s). Certain embodiments allow for more flexible scheduling of time-domain resources without increasing the number of DCI bits.

Additional information may also be found in Appendix A and Appendix B.

<FIG> shows a wireless device configured with multiple (in the example, two) time-domain resource allocation tables. Examples of time-domain resource allocation tables include pre-defined tables with default values for the time domain resource allocation, tables configured using RRC signaling, and a combination of pre-defined and RRC-configured tables. The time-domain resource allocation tables indicate an allocation of time-domain resources, such as time-domain resources of the PUSCH or PDSCH, for transmission or reception of a wireless signal. In some embodiments, the time-domain resource allocation tables indicate the allocation of time-domain resources with reference to OFDM symbols. For example, <FIG> shows that the time-domain resource allocation tables comprise different combinations of starting OFDM symbol position and duration in OFDM symbols for the time-domain resource allocation. As can be seen, the time-domain resource allocation tables include multiple entries, and the different table entries may differ in at least one of OFDM starting symbol and/or scheduled time duration in OFDM symbols. The OFDM symbols may be indicated using any two parameters selected from start symbol, stop symbol, and duration in symbols (e.g., start symbol and stop symbol, start symbol and duration, or stop symbol and duration). The start symbol can be absolute with respect to the slot boundary, or relative to a scheduling DCI/CORESET. Different tables could also have different definitions with respect to the starting (or ending) OFDM symbol. For example, some tables could express the starting (or ending) OFDM symbol in absolute OFDM symbol number of a slot while other tables would express the starting (or ending) symbol relative to PDCCH/CORESET symbol(s) used to schedule PDSCH/PUSCH. The absolute numbering could be useful for slot-based or Type A transmission while relative numbering could be preferred by non-slot-based or Type B transmission. In principle, different tables could have different number of entries; however, in the examples shown in <FIG>, the same number of entries in each table is assumed.

The wireless device determines which time-domain resource allocation table to use based on first information received from a network node, such as a base station. The wireless device determines a time-domain resource allocated to the wireless device based on the time-domain resource allocation table determined from the first information and based on second information received from the network node. The second information is different from the first information. In some embodiments, the second information indicates which entry of the determined table to use to determine the time-domain resource allocated to the wireless device. For example, the second information may comprise a time-domain resource allocation field, such as a bit field, received in DCI. With respect to the example illustrated in <FIG>, each table includes four entries such that a time-domain resource allocation field comprising a two bits-wide bit field may be used to select one of the four entries in the table (e.g., "<NUM>" to select the first entry, "<NUM>" to select the second entry, "<NUM>" to select the third entry, and "<NUM>" to select the fourth entry).

As described above, the wireless device determines the table based on first information. The first information comprises information other than the time-domain resource allocation field received in the DCI. Examples of this other information could be a Radio Network Temporary Identifier (RNTI), information contained in the DCI, which DCI format has been used for scheduling, which CORSET/search space has been used for scheduling, if the transmission is slot-based or non-slot-based, carrier aggregation related information, bandwidth part related information, slot format, and/or information indicating numerology (e.g., a cyclic prefix, an OFDM subcarrier spacing, etc.), as further described below.

In some embodiments, the first information could be another field in the DCI (i.e., a field other than the time-domain resource allocation field) that is already being signaled for another purpose. For example, if DCI includes a bit to differentiate Type A scheduling and Type B scheduling, this bit can be used to select one of the two tables in <FIG>. Another example could be a bit that differentiates slot-based transmissions and non-slot-based transmission. Slot B scheduling, non-slot-based transmissions, and mini-slots are transmissions which duration is typically short. Slot-based transmissions typically have transmission lengths in the order of a slot. Therefore, it makes sense to use two different time-domain resource allocation tables based on a Type A/Type B or non-slot-based-transmission/slot-based-transmission differentiator bit.

If multi-slot scheduling is dynamically indicated in the DCI using a multi-slot indicator bit, this bit can be used as the first information to differentiate a time-domain resource allocation table to be used for single slot and multi-slot (slot aggregation) transmission. In these two cases resource allocations are obviously different. A multi-slot time-domain resource allocation can - in addition to the symbol information - also contain slot information. Here the time-domain resource allocation field received in DCI could be larger bit field if the multi-slot indicator bit is set to enable more time-domain resource allocations. The same principle applies if multi-slot scheduling is not indicated via a multi-slot indicator bit in the DCI but in any other way.

Certain embodiments of the present disclosure use the DCI format (e.g., regular DCI or fallback DCI) as the first information for selecting a time-domain resource allocation table. For example, for NR, it has been discussed in 3GPP to use two different DCI variants. The first variant is a regular DCI which can be used for all kinds of signaling or configuring needed. This regular DCI varies in size and format depending on the its use (i.e., depending on the actual RRC configuration), somewhat similar to LTE DCI formats. The second variant is a fallback DCI with a fixed and predefined size. The fixed-size fallback DCI is typically needed during RRC reconfigurations, when there may be a period of configuration uncertainty during which it is valuable to have a fixed sized DCI known to both the network and the UE, to limit the effect of the configuration uncertainty for the wireless communication. The problem of configuration uncertainty occurs when the network does not know when the UE applies the RRC reconfiguration. For example, the UE may have to list the information, or there may be multiple retransmissions needed before the RRC command reaches the UE. Hence there is a period when the UE may have applied the new configuration, but the network is not aware of it, or vice versa. During this period there is thus a need for a way to communicate which is "always" known by both sides and, and this need is fulfilled by using the fallback DCI that is not configurable.

A wireless device can be configured with multiple control channel resource sets (CORESETS) and each CORESET can contain one or more search spaces. The CORESET and/or search space that has been used to schedule the transmission can be used as the first information for determining the time-domain resource allocation table.

A DCI contains a downlink/uplink (DL/UL) indicator bit that indicates if the transmission is DL or UL. Due to the difference in frame structure and different processing times between DL assignment reception → DL data reception and UL grant reception →UL data transmission, it is likely that DL and UL require different time-domain resource allocations. Therefore, the DL/UL indicator bit can be used as the first information for determining the time-domain resource allocation table.

In case of carrier aggregation, a wireless device is configured with multiple carriers. Different carriers might have different numerologies, and different need to coexist with long term evolution (LTE), and are set up with different DL/UL configurations. Then it makes sense to support different time-domain resource allocations for different carriers. Therefore, depending on the scheduled carrier, a time-domain resource allocation table is selected (i.e.. , the scheduled carrier may be used as first information for determining the time-domain resource allocation table). If no cross-carrier scheduling is applied (i.e., PDCCH is transmitted on same carrier as PDSCH or on associated carrier to PUSCH carrier) the carrier on which the scheduling DCI is transmitted determines the time-domain resource allocation table. If cross carrier scheduling is used (i.e., PDCCH is transmitted on another carrier as PDSCH or associated carrier to PUSCH carrier), information in the DCI or how the DCI is transmitted indicates the PDSCH/PUSCH carrier. For example, a Carrier Indicator Field (CIF) can be included in the DCI pointing to the PDSCH/PUSCH carrier. Different offsets with respect to how a search space is located in a CORESET might also be used to indicate the PDSCH/PUSCH carrier. Based on the identified carrier, a time-domain resource allocation table is selected.

In LTE and NR, transmissions can be scheduled using different Radio Network Temporary Identifiers (RNTI). As the name implies, RNTI is a kind of identification number, used to identify a specific radio channel and sometimes also a specific UE. Some examples are:.

For example, it could be envisioned that different RNTIs are used to schedule slot-based transmission and non-slot-based transmissions. Different RNTls can therefore be mapped to different time-domain resource allocation and the wireless device - depending on which RNTI it detects - selects a time-domain resource allocation table. Thus, an RNTI may be used as first information for determining the time-domain resource allocation table.

NR supports different numerologies, e.g., OFDM subcarrier spacing and/or cyclic prefix. Different numerologies (including cyclic prefix) can be used to optimize transmissions with respect to latency or individually adopt the numerology to the current radio conditions of a terminal. Different numerologies can be mapped to different time-domain resource allocation and the wireless device, based on the numerology of a transmission, selects the correct time-domain resource allocation table. In NR, different bandwidth parts (BWP) will be used for different numerologies. Different BWP might thus use different time-domain resource allocation tables. For example, If the DCI contains a BWP indicator field this can be used as first information for determining the time-domain resource allocation table.

Yet another possibility is to use the slot format as first information for determining the time-domain resource allocation table. For example, the wireless device can determine which table to use based on a slot format determined by the wireless device. The slot format can be determined based on the slot in which PDSCH is received (or PUSCH is transmitted). Alternately the slot format can be determined based on the format applicable to the first slot from which the PDSCH is received (or PUSCH is transmitted) in case of multi-slot transmissions. The slot format can be determined by the wireless device via higher layer signaling and/or L1 signaling (e.g., slot format indicator received in DCI or group-common PDCCH) and indicates at least one more of downlink/uplink/unknown symbols within a slot.

In initial access, Remaining Minimum System Information (RMSI) can be transmitted based on slot-based transmissions and non-slot-based transmissions. The Master Information Block (MIB) on the Physical Broadcast Channel (PBCH) contain information about how RMSI is distributed. Depending on how RMSI is transmitted, different time-domain resource allocation tables can be used to maximize scheduling flexibility for RMSI. Thus, information related to how the RMSI is transmitted may be used as first information for determining the time domain resource allocation table.

<FIG> shows a flow chart of a method in a wireless device for how to select a time-domain resource allocation table and a time-domain resource allocation entry within the table. First, the method comprises selecting a time-domain resource allocation table. In some embodiments, the method comprises selecting one of multiple time-domain resource allocation tables based on information available to the network node and the wireless device, for example, without the network node having to send DCI explicitly indicating which time-domain resource allocation table the wireless device should select. Second, the method comprises determining a time-domain resource allocation entry within the selected table. For example, from the network node perspective, the network node determines the time-domain resource allocation entry and explicitly signals the entry in the time-domain resource allocation field in DCI. From the wireless device perspective, the wireless device determines the time-domain resource allocation entry within the selected table based on the time-domain resource allocation field received in DCI from the network node.

In addition, it is possible that the tables discussed above are configured from a set of possible time-domain resource allocations. An example of a collection of time-domain resource allocations is given below in Table <NUM>.

In Table <NUM>, the multi-slot scheduling has been directly included as a separate column in the table. It is found under the column "Applicable slots (L2 slots). " In other embodiments, the multi-slot scheduling may be indicated by other means. In some embodiments, four entries of Table <NUM> could be configured to build Table A of <FIG> (e.g., Table A has four entries in the example shown in <FIG>). The signaling for this can be in system information or by wireless device-specific signaling by radio resource control (RRC). Similar methods can also be done for Table B and so on.

A table would then be selected according first information, such as an RNTI, information contained in the DCI, which DCI format has been used for scheduling, which CORSET/search space has been used for scheduling, if the transmission is slot-based or non-slot-based, carrier aggregation related information, bandwidth part related information, slot format, and/or information indicating numerology (e.g., a cyclic prefix, an OFDM subcarrier spacing, etc.). The time-domain resource allocation field in the DCI will point out an entry in the selected table. It is further observed that although Table <NUM> is described for PDSCH, a similar table can be constructed for PUSCH. As said earlier, different tables (Table A, Table B,. ) can be configured for different CORESET/search spaces/. , and each Table A, B,. is configured with rows from Table <NUM>.

Specific for initial access, some entries for Table <NUM> can be directly hardcoded in the specification for scheduling of example system information, paging, random access response, Message <NUM> in the random access procedure. If there would be no default values, additional signaling would be needed in MIB/PBCH to configure the default time-domain resource allocation(s). These values can also be default values the wireless device uses unless configured with a new time-domain resource allocation table.

<FIG> depicts a method in accordance with particular embodiments. In certain embodiments, the method may be performed by a wireless device, such as a UE. The method begins at step <NUM> with determining one of a plurality of time-domain resource allocation tables based on first information received from a network node. The method continues to step <NUM> with determining a time-domain resource allocated to the wireless device for transmission or reception of a wireless signal based on the determined one of the plurality of time-domain resource allocation tables and second information received from the network node different from the first information. Examples of first information, i.e., information from which the wireless device may determine the time-domain resource allocation table and second information, i.e., information from which the wireless device may determine the time-domain resource include, but are not limited to, the examples described with respect to <FIG> and above and the Group A embodiments below. In some embodiments, the method further comprises transmitting or receiving the wireless signal at step <NUM> using the determined time-domain resource.

<FIG> depicts a method in accordance with particular embodiments. In certain embodiments, the method may be performed by a network node, such as a base station. The method begins at step <NUM> with determining a time-domain resource to allocate to a wireless device for transmission or reception of a wireless signal. For example, in some embodiments, the network node determines the time-domain resource allocation based on an identified table and other information, such as current scheduling needs. The network node may then select the entry from the table that corresponds to the determined time-domain resource allocation. Additionally, the network node may determine second information for indicating the selected entry to the wireless device. The method proceeds to step <NUM> with sending the wireless device first information from which the wireless device determines one of a plurality of time-domain resource allocation tables and second information from which the wireless device determines the time-domain resource based on the determined one of the plurality of time-domain resource allocation tables. The second information is different from the first information. Examples of first information, i.e., information sent to the wireless device from which the wireless device may determine the time-domain resource allocation table and second information, i.e., information sent to the wireless device from which the wireless device may determine the time-domain resource include, but are not limited to, the examples described with respect to <FIG> and above and the Group B embodiments below. In some embodiments, the method further comprises transmitting or receiving the wireless signal at step <NUM> using the allocated time-domain resource.

With respect to the examples in <FIG> and <FIG>, in certain embodiments, the first information comprises one or more of:.

The second information comprises a time-domain resource allocation field within downlink control information that allows the wireless device/UE to determine which entry to use within the determined one of the plurality of tables in order to determine the allocated time-domain resource.

<FIG> illustrates a schematic block diagram of an apparatus <NUM> in a wireless network (for example, the wireless network shown in <FIG>). The apparatus may be implemented in a wireless device or network node (e.g., wireless device <NUM> or network node <NUM> shown in <FIG>). Apparatus <NUM> is operable to carry out the example method described with reference to <FIG> or <FIG> and possibly any other processes or methods disclosed herein. It is also to be understood that the method of <FIG> and <FIG> are not necessarily carried out solely by apparatus <NUM>. At least some operations of the method can be performed by one or more other entities.

Virtual Apparatus <NUM> may comprise processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In some implementations, the processing circuitry may be used to cause configuration information unit <NUM>, time resource determination unit <NUM>, communication unit <NUM>, and any other suitable units of apparatus <NUM> to perform corresponding functions according one or more embodiments of the present disclosure.

As illustrated in <FIG>, apparatus <NUM> includes configuration information unit <NUM>, time resource determination unit <NUM>, and communication unit <NUM>. In certain embodiments, configuration information unit <NUM> is configured to determine first information and second information. For example, when used in a network node, configuration information unit <NUM> determines first information to send to a wireless device from which the wireless device determines one of a plurality of tables, and second information from which the wireless determines (based on the one of the plurality of tables determined from the first information) an allocated time-domain resource. When used in a wireless device, configuration information unit <NUM> determines the first and second information received from the network node. Time resource determination unit <NUM> determines a time resource allocated to the wireless device for transmission or reception of a wireless signal. When used in a network node, time resource determination unit <NUM> may allocate a time-domain resource and may indicate the allocated time-domain resource to the network node's configuration information unit <NUM> so that the configuration information unit <NUM> can determine the first and second information to send the wireless device (e.g., first and second information that corresponds to the allocated time-domain resource). When used in a wireless device, time resource determination unit <NUM> can receive the first and second information from the network node (e.g., via the wireless device's configuration information module <NUM>) and can use the first and second information to determine the time-domain resource that the network node has allocated for the transmission or reception of a wireless signal. Communication unit <NUM> transmits or receives the wireless signal according to the allocated time domain resource that was determined by the time resource determination unit <NUM>.

In some embodiments a computer program, computer program product or computer readable storage medium comprises instructions which when executed on a computer perform any of the embodiments disclosed herein. In further examples the instructions are carried on a signal or carrier and which are executable on a computer wherein when executed perform any of the embodiments disclosed herein.

Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 160b, and WDs <NUM>, 110b, and 110c. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device (WD) <NUM> are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

interface <NUM> is used in the wired or wireless communication of signalling and/or data between network node <NUM>, network <NUM>, and/or WDs <NUM>.

As used herein, wireless device (WD) refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term WD may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a WD may be configured to transmit and/or receive information without direct human interaction. For instance, a WD may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a WD include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE). a vehicle-mounted wireless terminal device, etc.. A WD may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another WD and/or a network node. The WD may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the WD may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g., refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

UE <NUM> may be any UE identified by the <NUM>rd Generation Partnership Project (3GPP), including a NB-loT UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.

Hereinafter, further example embodiments related to NR resource allocation design issues are discussed, and more specifically time domain resource allocation.

In 3GPP RAN1#90bis meeting the following was agreed:
Agreements:.

Regarding whether one or more tables should be specified, it is believed that multiple tables can provide more flexibility in scheduling. However, in order to limit the DCI message size to select the tables, the number of tables may be limited to two. The table entries in the two tables can differ in starting OFDM symbol and/or duration. The selection of tables can be based on other fields in DCI message such as whether Type A or Type B scheduling is used, or a field that signals whether slot-based or mini-slot based transmission is scheduled.

Proposal <NUM>-<NUM>: To provide more flexibility in time domain resource allocation, two tables are specified with different starting OFDM symbol and duration in OFDM symbols.

For NR, data transmission may occupy (almost) all OFDM symbols in a slot or, in case of a mini-slot transmission, only some of them. These possibilities can be handled in a unified way by including information in the DCI about the PUSCH and PDSCH the starting and ending position. To limit the DCI overhead while at the same time provide some flexibility one possibility is to have, e.g., <NUM> bits in the DCI pointing into different combinations of starting and ending positions.

The combinations should also be aligned with OFDM symbol positions given by SFI (slot format indicator) in group common PDCCH (e.g., the combinations shown in [<NUM>]). For DL, the reference for starting and ending positions should be with respect to the first OFDM symbol of the PDCCH carrying the corresponding DCI. Some starting positions may be -ve values to accommodate the cases where PDSCH starts before the symbol in which PDCCH coreset is configured. To limit UE buffering requirements, only limited -ve values should be allowed (e.g., only -<NUM>, -<NUM>).

Data may also span multiple slots in case of slot aggregation/repetition. To handle slot aggregation, the UE assumes the same time resource allocation in slots wherein the transmission is repeated.

Proposal <NUM>-<NUM>: When slot aggregation/repetition is applied, the UE assumes the same time resource allocation in slots wherein the transmission is repeated.

To have more efficiency in DCI message it would be possible to make the bit fields in the DCI message depending on which CORESET the DCI is transmitted from. This is to allow more appropriate options of configurations of the starting and stop OFDM symbols for PDSCH and PUSCH.

Furthermore, for UL and DL in some cases there would be a need to define in which slot the transmission of PUSCH or PDSCH should occur in. Such information could either be a separate bitfield or be jointly encoded with the starting and ending position. It is noted here however that to be able to support rather long periods of UL slot there would be a need for around <NUM> bits to support these cases. A similar need does not strictly exist for DL as in DL a DCI message can be provided in each DL slot so for DL the information could be joint coded with the location information within the slot or a single bit could be introduced to indicate scheduling in the next preceding slot.

Some additional embodiments contemplated herein will now be described more fully with reference to <FIG>.

Alternatively, hardware <NUM> may be part of a larger cluster of hardware (e.g., such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) <NUM>, which, among others, oversees lifecycle management of applications <NUM>.

Wireless connection <NUM> between UE <NUM> and base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the data rate and latency, for example, by allowing for more flexible scheduling of time-domain resources, and thereby provide benefits such as reduced user waiting time.

Claim 1:
A method for determining a time-domain resource allocation, the method being performed by a system comprising a user equipment, UE, (<NUM>) and a base station (412a), the UE being wirelessly connectable to the base station, the method comprising:
the UE receiving from the base station a downlink control information, DCI, that schedules a downlink transmission from the base station to the UE;
the UE detecting a Radio Network Temporary Identifier, RNTI, used in the base station's scheduling of the downlink transmission;
the UE selecting a time-domain resource allocation table from multiple different time-domain resource allocation tables based on the detected RNTI, wherein each of the different time domain resource allocation tables is defined by a plurality of entries that specify different combinations of starting orthogonal frequency division multiplexing, OFDM, symbol and duration in OFDM symbols for a time-domain resource allocation; and
the UE determining a time-domain resource allocation for the downlink transmission based on a time-domain resource allocation field in the DCI, the time-domain resource allocation field indicating an entry within the selected time-domain resource allocation table.