Patent Description:
The present description generally relates to wireless communication systems and more specifically to handle slot offset for aperiodic sounding reference signals (SRS).

The sounding reference signal (SRS) is used in third generation partnership project (3GPP) systems Long Term Evolution (LTE) and New Radio (NR) to provide channel state information (CSI) in the uplink (UL). The application for the SRS is mainly to provide a reference signal to evaluate the channel quality at the gNodeB (gNB) in order to, e.g., derive the appropriate transmission/reception beams or to perform link adaptation (i.e., setting the rank, the modulation and coding scheme (MCS), and the multiple-input multiple-output (MIMO) precoder) for, e.g., physical uplink shared channel (PUSCH) transmission. The signal is, in terms of functionality, similar to the downlink (DL) CSI reference signal (CSI-RS), which provides similar beam management and link adaptation functions in the DL. Note that the SRS can be also used instead of (or in combination with) CSI-RS to acquire DL CSI (by means of reciprocity) for, e.g., enabling physical downlink shared channel (PDSCH) link adaptation.

In LTE and NR, the SRS is configured via radio resource control (RRC) and some parts of the configuration can be updated (for reduced latency) through medium access control (MAC) control element (CE) signaling. The configuration includes, for example, the SRS resource allocation (the physical mapping and sequence to use) as well as the time behavior (aperiodic/semi-persistent/periodic). For aperiodic SRS transmissions, the RRC configuration does not activate an SRS transmission from the user equipment (UE), but instead a dynamic activation trigger is transmitted from the gNB in the DL, via the downlink control information (DCI) in the physical downlink control channel (PDCCH), which instructs the UE to transmit the SRS once, at a predetermined time.

The SRS configuration allows generating an SRS transmission pattern based on SRS resource configurations grouped into SRS resource sets. The configuration of each SRS resource in RRC is illustrated in 3GPP <NUM> version <NUM>.

To create the SRS resource on the time-frequency grid with the current RRC configuration, each SRS resource is thus configurable with respect to:.

<FIG> illustrates a schematic description of how an SRS resource is allocated in time and frequency within a slot (note that semi-persistent/periodic SRS resources typically span several slots), in the case resourceMapping-r16 is not signaled. Note that c-SRScontrols the maximum sounding bandwidth, which can be smaller than the maximum transmission bandwidth that the User Equipment (UE) supports. For example, the UE may have capability to transmit over <NUM> bandwidth, but c-SRS is set to a smaller value corresponding to <NUM>, thereby focusing the available transmit power to a narrowband transmission which improves the SRS coverage and enables multiplexing of SRS resources (and, hence, UEs) over the <NUM> bandwidth.

In NR release <NUM>, an additional (and optional) RRC parameter called resourceMapping-r16 was introduced. If resourceMapping-r16is signaled, the UE shall ignore the RRC parameter resourceMapping. The difference between resourceMapping-r16 and resourceMapping is that the SRS resource (for which the number of OFDM symbols and the repetition factor is still limited to <NUM>) can start in any of the <NUM> OFDM symbols (see <FIG>) within a slot, configured by the RRC parameter startPosition-r16. <FIG> illustrates another schematic description of how an SRS resource is allocated in time and frequency within a slot if resourceMapping-r16 is signaled.

The RRC parameter resourceType determines whether the SRS resource is transmitted as periodic, aperiodic (single transmission triggered by DCI), or semi persistent (same as periodic except for the start and stop of the periodic transmission that is controlled through Medium Access Control (MAC) Control Element (CE) signaling instead of RRC signaling). The RRC parameter sequenceld specifies how the SRS sequence is initialized and the RRC parameter spatialRelationInfo configures the spatial relation for the SRS beam with respect to another reference signal (RS), which could be another SRS, a synchronization signal block (SSB), or a CSI-RS. If an SRS resource has a spatial relation to another SRS resource, then this SRS resource should be transmitted with the same beam (i.e., spatial transmit filter) as the indicated SRS resource.

The SRS resource will be transmitted as part of an SRS resource set. Note that all resources in a resource set must share the same resource type. Within an SRS resource set, the following parameters (common to all SRS resources in the set) are configured in RRC:.

Each SRS resource set is configured as illustrated in 3GPP <NUM> version <NUM>.

To summarize, the SRS resource-set configuration determines, e.g., usage, power control, aperiodic transmission timing, and CSI-RS resource association. The SRS resource configuration, on the other hand, determines the time-and-frequency allocation, the periodicity and offset of each resource, the sequence ID for each resource and the spatial-relation information.

In the ongoing standardization work for NR Rel-<NUM>, for enhanced DCI triggering flexibility, it has been agreed to introduce the option to indicate dynamically the slot offset for aperiodic SRS in the DCI triggering of SRS resource set(s). The new slot offset will be determined based on a new parameter, hereinafter referred to as t, which indicates the number of slots between a reference slot (reference slot will either be the slot containing the DCI triggering the SRS or the slot indicated by the legacy slot offset parameter) and the slot where the SRS should be transmitted. The following was agreed during the RAN1#<NUM>-e meeting:
A given aperiodic SRS resource set is transmitted in the (t + <NUM>)th available slot counting from a reference slot, where t is indicated from DCI, or RRC (if only one value of t is configured in RRC), and the candidate values of t at least include <NUM>. Adopt at least one of the following options for the reference slot.

As shown in this agreement, two different options are considered on how to indicate the t values for a triggered aperiodic SRS resource set, either explicitly or implicitly. For the explicit indication, it is expected that a new DCI field is used to indicate one out of a number of pre-configured t values. While for implicit indication, it is assumed that different t values are associated with different aperiodic SRS trigger states, and by, for example, triggering one SRS resource set with either SRS trigger state <NUM>, <NUM>, or <NUM>, different slot offsets t will be used for that SRS resource set. More detailed descriptions of the implicit and explicit aperiodic SRS slot offset indication can be found in https://www. org/ftp/tsg_ran/WG1_RL1/TSGR1_103-e/Docs/R1-<NUM>.

Compared to legacy NR aperiodic SRS slot offset, which count all slots (i.e., DL slots, UL slots and flexible/special slots), the new parameter t only counts the "available slots, which in RAN1#<NUM>-e was agreed to be defined as follows: Confirm the following working assumption with modifications. An "available slot" is a slot satisfying that there are UL or flexible symbol(s) for the time-domain location(s) for all the SRS resources in the resource set and it satisfies UE capability on the minimum timing requirement between triggering PDCCH and all the SRS resources in the resource set.

As can be concluded from the agreement, an "available slot" is a flexible slot or UL slot that contains OFDM symbols that can carry all the time-domain allocations of a triggered SRS resource set (i.e., slots that have sufficiently many UL symbols to support the SRS symbols configured by resourceMapping or resourceMapping-r16 for all SRS resources in the SRS resource set).

Document "<NPL> may be construed to disclose an evaluation on SRS enhancements techniques. Inter alia, the following observations and proposals were made. Proposal <NUM>: Support the RRC configuration of multiple available slot offsets for the aperiodic SRS resource set where each offset is associated with an SRS triggering codepoint that is dynamically indicated by the UL or DL DCI formats. Proposal <NUM>: Support implicit indication of the SRS triggering offset through the SRS request field in the DCI format and configuring a one-to-one association between each aperioidicSRS-Resource Trigger value and the slot offset. Proposal <NUM>: Support explicit indication of the SRS triggering offset through a dedicated bit field in the DCI format that selects one value of multiple RRC configured values of the available slots: - If the bitfield is absent in the DCI, then the default 't=<NUM>' first available slot is assumed; - Support for non-scheduling DCI (e.g. DCI format 0_1 or 0_2 with UL-SCH =<NUM>).

Document <CIT> may be construed to disclose a sounding method of user equipment (UE) in a wireless communication system, comprising the steps of: receiving configuration of one or more sounding reference signal (SRS) resource sets from a base station; receiving, from the base station, activation command information commanding the SRS transmission activation of a particular SRS resource set from among the one or more SRS resource sets; and transmitting, to the base station, the SRS corresponding to the particular SRS resource set, wherein the reference signal, for which a spatial relationship is assumed for each SRS resource included in the particular SRS resource set, can be determined on the basis of the activation command information.

Document <CIT> constitutes prior art under Article <NUM>(<NUM>) EPC may be construed to disclose a base station (BS) that transmits, to a user equipment (UE), a downlink control information (DCI) communication that is configured to trigger transmission of an aperiodic (AP) sounding reference signal (SRS). The UE determines a slot offset from the DCI communication to an SRS resource set for the AP SRS based at least in part on an DCI codepoint (i.e., AP SRS resource trigger value) of the DCI communication. The UE transmits the AP SRS on the SRS resource set in accordance with the determined slot offset.

There exist some challenges. Since different SRS resource sets can have different time-domain allocations (depending on which SRS resources that belong to the SRS resource set), which slots that are counted as "available slots" can be different for different SRS resource sets that are triggered by the same DCI. Furthermore, as it is possible to dynamically change the slot format (in order to, e.g. adapt the ratio of DL/UL resources to satisfy the current DL/UL traffic demand), a certain SRS resource-set configuration for which no SRS resources (over all the SRS resource sets triggered by the same DCI) are colliding for a time-division duplex (TDD) slot format, could contain colliding SRS resources after the slot format has dynamically been changed.

In <FIG>, an example of how changing the slot format could result in a collision between two SRS resource sets is illustrated. Here, SRS resource set <NUM> contains four single-symbol SRS resources and is configured with t = <NUM>, and SRS resource set <NUM> contains two single-symbol SRS resources and is configured with t = <NUM>. Consider the case when these two sets have been configured for the TDD slot format "DDDUUDDDUU". In this case, all UL slots will be counted as "available slots" since all SRS resources for both SRS resource sets can fit into each of the UL slots. Hence, the first SRS resource set, for which t = <NUM>, will be transmitted in the first "available slot", which corresponds to the first UL slot after the DCI, while SRS resource set <NUM>, for which t = <NUM>, will be transmitted in the second "available slot, which corresponds to the second UL slot after the DCI, and, thus, there are no collisions between any SRS resources in the two SRS resource sets (see the upper part of <FIG>).

Now, let's assume that the gNB changes the TDD slot format (e.g., to meet new DL traffic demands for example) to "DDDSUDDDSU". Here, S denotes a special slot with <NUM> DL symbols (OFDM symbol <NUM>-<NUM>), <NUM> switching symbols (OFDM symbol <NUM>-<NUM>), and <NUM> UL symbols (OFDM symbol <NUM>-<NUM>). Due to the limited number of UL symbols in the special slot, it will be counted as an" available slot" only for SRS resource set <NUM>, since not all SRS resources in SRS resource set <NUM> can fit in these UL symbols. Hence, since SRS resource set <NUM> is configured with t = <NUM> and SRS resource set <NUM> is configured with t = <NUM>, both of these sets will be transmitted in the first UL slot and, thus, there is a collision between SRS resources sets (see the lower part of <FIG>). Specifically, there will be a collision between SRS resources <NUM> and <NUM>, and between SRS resources <NUM> and <NUM>.

It should be noted that this collision can be avoided if the gNB, after changing the slot format, would instead send the DCI in the special slot (which would result in SRS resource set <NUM> and <NUM> being transmitted in the first UL symbol and the second special symbol, respectively). However, this would defeat the main purpose of the introduction of the new flexible aperiodic slot offset (i.e., that the gNB can send the DCI in a more flexible way, as discussed above).

In the current release of NR, there is no rule to define how the UE should behave if it has been configured with colliding SRS resource sets (as in the example above). Therefore, as mentioned in the RAN#<NUM>-e agreement, how to handle colliding SRS resource sets is marked as a topic for further study (FFS).

The need for introducing rules to handle colliding SRS resource set will be further exacerbated in NR Rel-<NUM>, as SRS resource sets with usage 'antennaSwitching' will be specified for UEs with up to <NUM> receive antennas. Furthermore, it will be possible to configure one or multiple SRS resource sets for each UE antenna-switching configuration (e.g., for 2T8R, up to <NUM> SRS resource sets might be allowed), as can be concluded from the agreement below (from RAN#<NUM>-e):
For aperiodic antenna switching SRS, support to configure N ≤ Nmax resource sets, where totally K resources are distributed in the N resource sets flexibly based on RRC configuration.

To summarize, since the TDD slot format can be changed dynamically by DCI, there is a risk that a certain RRC-based SRS configuration will work for one TDD slot format but not for another. Hence, there is a need to support a more dynamic update of the aperiodic slot offset t by using, e.g. a MAC CE. However, the details of how the MAC CE can be used to update the t value is still an open issue.

This disclosure provides a framework and details for updating the new aperiodic SRS slot offset parameter t using MAC CE signaling, for example.

According to the present disclosure, there are provided methods, a wireless device, a network node and computer-readable media according to the independent claims. Further developments are set forth in the dependent claims.

Exemplary embodiments will be described in more detail with reference to the following figures, in which:.

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments. Upon reading the following description in light of the accompanying figures, those skilled in the art will understand the concepts of the description and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the description.

In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description. Those of ordinary skill in the art, with the included description, will be able to implement appropriate functionality without undue experimentation.

Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to implement such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It will be further understood that the terms "comprises," "comprising," "includes," and/or "including" when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As described above, there are currently two possible options on how to indicate the slot offset with DCI, either explicitly or implicitly. These two methods require different solutions and, therefore, the embodiments are divided into two bundles, a first bundle of embodiments is related to implicit update of the slot offset, and a second bundle of embodiments is related to the explicit update of the slot offset.

Note that the words/terms "SRS trigger state" and "SRS trigger state ID" are used in the disclosure, however, there is no explicit RRC configuration of such parameters. Instead, these terms refer to the codepoints (<NUM>, <NUM> & <NUM>) used to trigger aperiodic SRS resource set(s) as specified in 3GPP <NUM> Table <NUM>. <NUM>-<NUM>: "SRS request". This means, for example, that when the disclosure refers to "SRS trigger state <NUM>" or "SRS trigger state ID <NUM>", it actually refers to the codepoint "<NUM>" of the SRS request field as specified in 3GPP <NUM>-Table <NUM>. <NUM>-<NUM>. When the terms "SRS trigger state <NUM>" or "SRS trigger state ID <NUM>" are used, they refer to the codepoint "<NUM>" of the SRS request field as specified in 3GPP <NUM>-Table <NUM>. <NUM>-<NUM>, and so on.

In this embodiment, each SRS resource set is RRC configured with a list of N t-values (as schematically illustrated in a data structure of Table <NUM> below in the srs-ResourceSetId) and where each entry of the list is implicitly associated with an SRS trigger state (e.g., the first entry in the list is associated with SRS trigger state <NUM>, the second entry in the list is associated with SRS trigger state <NUM> and so on). Assume that a UE is configured with the following t-values of the list slotOffsetList-r17: [<NUM>, <NUM>, <NUM>]. This would mean that if this SRS resource set is triggered with SRS trigger state <NUM>, the UE should apply t = <NUM>, if the SRS resource set is triggered with SRS trigger state <NUM>, then the UE should apply the t = <NUM>, and if the SRS resource set is triggered with SRS trigger state <NUM>, then the UE should apply t = <NUM>.

<FIG> illustrates one example of a MAC-CE message for this embodiment. The length of this MAC CE message can be fixed and correspond to the number of configured SRS resources sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE can determine the number of SRS resource set IDs and corresponding associated t-values and "SRS trigger-state-IDs" based on the length field included in the MAC CE header. The MAC CE contains the following fields:.

When a UE receives a MAC CE of <FIG>, the UE can determine that for an indicated/associated SRS resource set, a new value of time offset should be used for a certain SRS trigger state. As such, if this SRS trigger state is indicated, the UE can transmit the reference signal based on the new and updated time offset (or timing) associated with that SRS trigger state, and thus can avoid some potential collisions, for example.

<FIG> illustrates another example of a MAC CE message for this embodiment. The length of this MAC CE message can be fixed and correspond to the number of configured SRS resources sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE understands the number of SRS resource set IDs and corresponding associated t-values based on the length field included in the MAC CE header. The main difference between this MAC CE message and the previous MAC CE message (of <FIG>) is that, here, there is no explicit indication of which SRS trigger state that an indicated t-value should be updated for. Instead, an implicit mapping is used, as is exemplified by the arrows in <FIG>. Since there are only three SRS trigger states, three t-values should be indicated per SRS resource set. For example, the location of the field indicating the t-value in the MAC CE provides the SRS trigger state associated with that t-value. As one example, the field for the t-value in the second octet (Oct <NUM>) is associated with SRS trigger state <NUM>, the first field for the t-value in the third octet (Oct <NUM>) is associated with SRS trigger state <NUM> and the second field for the t-value in the third octet (Oct <NUM>) is associated with SRS trigger state <NUM>. Also, the UE considers the MAC CE in blocks of <NUM> octets. For example, Oct <NUM> and Oct <NUM> are associated with the SRS Resource ID #<NUM>, Oct <NUM> and Oct <NUM> are associated with SRS Resource ID #<NUM>, and so on. One benefit with this MAC CE message is that <NUM> bits can be used to indicate the t-values which increases the range of the candidate t-values.

In one variant of this embodiment, as illustrated in <FIG>, only <NUM> bits can be used to indicate the t values (i.e. the "t-value bitfield" only consists of <NUM> bits instead of <NUM> bits), which means that there will be one or two spare bits per octave/octet (depending on if there are one or two "t-value bitfields" in that octave/octet), and these additional spare bits could be used for other things and/or reserved for later use.

In one example, the additional bit (C field) in second octet (Oct <NUM>) can indicate to the UE what to do with the next octet. For instance, if C is set to <NUM> (zero), the next octet (e.g. Oct <NUM>) is omitted, and the UE only updates the t-value associated with SRS trigger state <NUM>. The <NUM> additional bits (e.g. D fields) in the third octet (e.g. Oct <NUM>) can indicate to the UE what to do with some fields. For instance, if D is set to <NUM>, the UE should ignore the bits of the t-value bitfield right before it. As such, the UE can ignore the t-value associated with SRS trigger state <NUM> or with SRS trigger state <NUM>. It should be appreciated that other uses of the additional bits can be considered.

In another example, the octet right after the SRS resource ID octet can contain two t-value fields and two bits of the third t-value field. The third bit of the t-value field is in the same octet as the SRS Resource set ID. This octet therefore has three bits to be used for other uses. For example, it may be specified that the first extra bit in the octet where the SRS Resource ID is indicates whether this octet follows with another octet or not. If not, e.g. the extra bit is set to the value of "<NUM>", the rest of the bits are used for one t-value field, which is then the only one present for the SRS Resource ID field. If it is set to the value of "<NUM>", it can indicate that there is another octet with more t-value fields. Then, in this particular case, the next bit in the same octet as the SRS Resource ID field can indicate whether the UE expects one or two t-value field in the follow up octet.

When the UE receives a MAC CE of <FIG> or <FIG>, the UE can determine that for a given SRS resource set, a t-value associated with a particular SRS trigger state has been used updated. If that SRS trigger state is indicated, then, the UE transmits the reference signal based on the updated t-value associated with that SRS trigger state.

In this embodiment, a t-value is RRC configured in a new field, which in this example will be called slotOffset-r17, and a MAC CE message is used to associate slotOffset-r17(and, hence, associate a t-value) for a given SRS resource set and SRS trigger state, as schematically illustrated in a data structure of Table <NUM> below.

<FIG> illustrates one example of a MAC CE message for this embodiment. The length of this MAC CE message can be fixed and correspond to the number of configured SRS resources sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE can determine the number of SRS resource set IDs and corresponding associated slotoffsetIDs based on the length field included in the MAC CE header. In this MAC CE message, a new field called slotOffsetId is included, which points to one of the RRC configured SlotOffset-r17 fields, and hence will associate a t-value with a SRS trigger state and SRS resource set indicated in the same octave/octet in the MAC CE.

When a UE receives a MAC CE of <FIG>, the UE can determine that for an indicated/associated SRS resource set, a new value of time offset (given by slotOffsetID) should be used for a certain SRS trigger state. As such, if that SRS trigger state is indicated, the UE can transmit the reference signal based on the new and updated time offset (or timing) associated with that SRS trigger state, and thus can avoid some potential collisions, for example.

<FIG> illustrates another example of a MAC CE message for this embodiment. The length of this MAC CE message can be fixed and correspond to the number of configured SRS resources sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE can determine the number of SRS resource set IDs and corresponding associated slotoffsetIDs based on the length field included in the MAC CE header. The main difference between this MAC CE message (from <FIG>) and the previous MAC CE message (of <FIG>) is that here there is no explicit indication of which SRS trigger state that an indicated t-value (via slotoffsetID) should be updated for. Instead, an implicit mapping is used, as is exemplified by the arrows in <FIG>. Since there are only three SRS trigger states, three t-values should be indicated per SRS resource set. As one example, the field for the slotoffsetID in the second octet (Oct <NUM>) is associated with SRS trigger state <NUM>, the first field for the slotoffsetID in the third octet (Oct <NUM>) is associated with SRS trigger state <NUM> and the second field for the slotoffsetIDin the third octet (Oct <NUM>) is associated with SRS trigger state <NUM>. One benefit with this MAC CE message is that <NUM> bits can be used to indicate the t-values, which increases the range of the candidate t-values.

In one variant of this embodiment, only <NUM> bits can be used to indicate the t values (given by the slotOffsetID bitfield, which has <NUM> bits in this variant instead of <NUM> bits). This means that there will be one or two spare bits per octave (depending on if there are one or two "slotOffsetID bitfields" in that octave), and these extra spare bits could be used for other things and/or reserved for later use.

In one example, the indication of the additional bits could be similar to the case as illustrated in <FIG>, with the t-value bitfield being replaced by the slotOffsetID field.

For example, the octet right after the SRS resource ID octet contains two slotOffsetId fields and two bits of the third sloOffsetID field. The third bit of the slotOffset field is in the same octet as the SRS Resource set ID. This octet therefore has then three bits to be used for other uses. For example, it may be specified that the first extra bit in the octet where the SRS Resource ID is indicates whether this octet follows with another octet or not. If not, e.g. the first extra bit is set to value "<NUM>", the rest of the bits are used for one slotOffsetId field, which is then the only one present for the SRS Resource field. If it is set the value "<NUM>", it indicates that there is another octet with more slotOffsetID fields. Then, in this particular case, the next bit in the same octet as the SRS Resource ID field indicates whether the UE expects one or two slotOffsetID field in the follow up octet.

When the UE receives a MAC CE of <FIG>, the UE can determine that for a given SRS resource set, a t-value associated with a particular SRS trigger state has been used updated. Then, if that particular trigger state is indicated, the UE transmits the reference signal based on the updated t-value associated with that SRS trigger state, for example. The t-value is given by the slotOffsetID field.

In these embodiments, a new bitfield in DCI (referred to as "Slot offset bitfield") is used to indicate one out of N preconfigured slot offsets (t-values). The "Slot offset bitfield" in DCI can for example contain <NUM> or <NUM> bits in order to indicate a maximum of <NUM> or <NUM> t-value candidates. For example, the size of the "Slot offset bitfield" depends on the maximum number of configured t-values for any SRS resource set, and is equal to ceil(log<NUM>(tmax)), where tmax is the maximum number of t-value candidates configured for any SRS resource set. So, for example, if the SRS resource set with the highest number of configured t-value candidates has <NUM> t-value candidates, the number of required bits in "Slot offset bitfield"is <NUM>. If a maximum of one candidate t-values is configured per SRS resource set for all SRS resource sets, the "Slot offset bitfield" can be omitted from the DCI.

In this embodiment, each SRS resource set is RRC configured with a list of N t-value candidates given by slotOffsetList-r17 (as illustrated in Table <NUM>) and where each entry of the list is associated with a codepoint of the "Slot offset bitfield" of the DCI (e.g., the first entry in the list is associated to codepoint <NUM> of "Slot offset bitfield", the second entry in the list is associated with codepoint <NUM> of "Slot offset bitfield", and so on). Assume that the UE is configured with the following t-values of the list slotOffsetList-rl7: [<NUM>, <NUM>, <NUM>] for a given SRS resource set. This would mean that if the "Slot offset bitfield" included in the same DCI that is used to trigger that SRS resource set indicates codepoint <NUM>, then the UE should apply t = <NUM>, if the "Slot offset bitfield" included in the same DCI that is used to trigger the SRS resource set indicates codepoint <NUM>, then the UE should apply t = <NUM>, and if the "Slot offset bitfield" included in the same DCI that is used to trigger the SRS resource set indicates codepoint <NUM>, then the UE should apply t = <NUM>.

<FIG> illustrates one example of a MAC CE message for this embodiment. The length of this MAC CE message can be fixed and equals the number of configured SRS resources sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE can determine the number of SRS resource set IDs, and corresponding t-values and DCI-codepoints of "Slot offset bitfield" based on the length field included in the MAC CE header. The field "DCI codepoint" indicates for which codepoint in the "Slot offset bitfield" that the updated t-value should be applied to (and, hence, it implicitly indicates which entry in the list slotOffsetList-r17 that should be updated).

When the UE receives a MAC CE of <FIG>, the UE can determine that for a given SRS resource set, a timing value/offset (t-value) of a DCI codepoint needs to be updated. To do so, the UE determines the updated timing value (t-value) from the MAC CE; the updated timing value is associated with the DCI codepoint to be updated. Then, the UE transmits the reference signal based on the updated t-value, for example.

<FIG> illustrates another example of a MAC CE message for this embodiment. The length of this MAC CE message can be fixed and equals the number of configured SRS resource sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE can determine the number of SRS resource set IDs and the corresponding t-values based on the length field included in the MAC CE header. The main difference between this MAC CE message (<FIG>) and the previous MAC-CE message (<FIG>) is that here there are no explicit indication of which codepoint in the "Slot offset bitfield" that is associated with which t-value. Instead, an implicit mapping is used, as is exemplified by the arrows in <FIG> and the different hatched patterns indicate which t-values are associated with which SRS resource sets. For example, the first t-value of Oct <NUM> (starting from the left) is associated with Codepoint <NUM>, the second t-value of Oct <NUM> is associated with Codepoint <NUM>. The first t-value of Oct <NUM> is associated with Codepoint <NUM> and the second t-value of Oct <NUM> is associated with Codepoint <NUM>. These <NUM> t-values are associated with a first SRS Resource Set ID (oblique hatched pattern, for example). The UE processes the MAC CE by blocks of <NUM> octets. For example, Oct <NUM> and Oct <NUM> are associated with a second SRS resource set (vertical only hatched pattern) and so on.

In one variant of this embodiment, the reserved bits (R) can also be used for the t-values, such that an additional two t-values can be indicated per SRS resource set.

When the UE receives a MAC CE of <FIG>, the UE can determine that for a given SRS resource set, a timing value/offset (t-value) provided by a DCI codepoint needs to be updated. To do so, the UE determines the updated timing value (t-value) from the MAC CE; the updated timing value is associated with the DCI codepoint to be updated. The associated DCI codepoint is given through the location of the t-value field in the MAC CE and octet. Then, the UE transmits the reference signal based on the updated t-value instead of the timing value given by the corresponding DCI codepoint, for example.

In this embodiment, a t-value is RRC configured in a new field, which in this example will be called SlotOffset-r17 as illustrated in Table <NUM> and a MAC CE is used to associate a "SlotOffset-r17" (and hence associate a t-value) for a given SRS resource set and a codepoint in the "Slot offset bitfield".

<FIG> illustrates an example of a MAC CE message for this embodiment. The length of this MAC CE message can be fixed and equals the number of configured SRS resources sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE can determine the number of SRS resource set IDs and corresponding "slotOffsetIds" and codepoints in the "Slot offset bitfield" based on the length field included in the MAC CE header. In this MAC CE, a new field called slotOffsetId is included, which points to one of the RRC-configured SlotOffset-r17, and hence will associate a t-value with the codepoint in the "Slot offset bitfield" and SRS resource set indicated in the same octave in the MAC CE.

When the UE receives a MAC CE of <FIG>, the UE can determine that, for a given SRS resource set, a timing value/offset provided by a DCI codepoint needs to be updated. To do so, the UE determines the updated timing value (given by SlotOffsetID) from the MAC CE; the updated timing value is associated with the DCI codepoint to be updated. Then, the UE transmits the reference signal based on the updated timing value instead of the timing value provided by the corresponding DCI codepoint, for example.

<FIG> illustrates another example of a MAC-CE message for this embodiment. The length of this MAC CE message can be fixed and equals the number of configured SRS resource sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE determines the number of SRS resource set IDs and corresponding "slotOffsetIds" based on the length field included in the MAC CE header. The main difference between this MAC CE message (<FIG>) and the previous MAC-CE message (<FIG>) is that here there is no explicit indication of which codepoints in the "Slot offset bitfield" is associated with which slotOffsetId. Instead, an implicit mapping is used, as is exemplified by the arrows in <FIG> and the different hatched patterns indicate which slotOffsetIds are associated with which SRS resource sets. For example, the first slotOffsetId of Oct <NUM> (starting from the left) is associated with Codepoint <NUM>, the second slotOffsetId of Oct <NUM> is associated with Codepoint <NUM>. The first slotOffsetId of Oct <NUM> is associated with Codepoint <NUM> and the second slotOffsetId of Oct <NUM> is associated with Codepoint <NUM>. These <NUM> slotOffsetId fields are associated with a first SRS Resource Set ID (oblique hatched pattern, for example). The UE processes the MAC CE by blocks of <NUM> octets. For example, Oct <NUM> and Oct <NUM> are associated with a second SRS resource set (vertical only hatched pattern) and so on.

In one variant of this embodiment, the reserved bits (R) can be also used for the slotOffsetIds such that an additional two slotOffsetIds can be indicated per SRS resource set.

When the UE receives a MAC CE of <FIG>, the UE can determine that for a given SRS resource set, a timing value/offset provided by a DCI codepoint needs to be updated. To do so, the UE determines the updated timing value (given by slotOffsetIds) from the MAC CE; the updated timing value is associated with the DCI codepoint to be updated. The associated DCI codepoint is given through the location of the slotOffsetIds field in the MAC CE and octet. Then, the UE transmits the reference signal based on the updated timing offset, given by slotOffsetIds, instead of the value given by the corresponding DCI codepoint, for example.

In this embodiment a t-value is RRC configured in a new field, which in this example will be called SlotOffset-r17, as illustrated in Table <NUM>, and a MAC CE is used to associate a "SlotOffset-r17" (and hence associate a t-value) for a given SRS resource set with a codepoint in the "Slot offset bitfield". Additionally, there may be a list SlotOffsetList-r17 in the abstract Syntax notation one (ASN1) as "SlotOffsetList-r17 SEQUENCE (SIZE(maxNOfcandidateTvalues) SlotOffset-r17)".

<FIG> illustrates an example of a MAC CE message for this embodiment. The length of this MAC CE message can be fixed and equals the number of configured SRS resource sets, or the length can be adaptable. In case it is adaptable, an extra field is needed to indicate the number of SRS resource set IDs that should be updated, or the UE can determine the number of SRS resource set IDs and corresponding Si (and potential Ti, Ui,Vi, etc.) values based on the length field included in the MAC CE header. The Si value corresponds to different variables associated with a first SRS resource set A, the Ti corresponds variables to a second SRS resource set B, and so on.

Below is the description of the variable Si, however the same description is also valid for Ti, Ui,Vi.

If the UE is not configured with a "slot offset r17" with "slot offset r17 ID" i, the MAC entity shall ignore the Si field.

The Si field is set to "<NUM>" to indicate that the "slot offset r17" with "slot offset r17 ID" i shall be activated and mapped to the codepoint of the DCI "Slot offset" field.

The Si field is set to "<NUM>" to indicate that the "slot offset r17" with "slot offset r17 ID" i shall be deactivated and is not mapped to the codepoint of the DCI "Slot offset" field.

It should be noted that the codepoint to which the "slot offset r17" is mapped is determined by the ordinal position among all the "slot offset r17" with Si field set to "<NUM>". That is: the first "slot offset r17" with Si field set to "<NUM>" shall be mapped to the codepoint value <NUM> of DCI "Slot offset"-field, the second "slot offset r17" with Si field set to "<NUM>" shall be mapped to the codepoint value <NUM> of DCI "Slot offset" field, and so on.

An alternative description for the S, T, U V field using T is as follows:
Ti: This field indicates the selection status of the Slot Offset configured within slotOffsetList, as specified in TS <NUM>. T<NUM> refers to the first slot offset within the list, T<NUM> to the second one and so on. If the list does not contain an entry with index i, the MAC entity shall ignore the Ti field. The Ti field is set to <NUM> to indicate that the Slot Offset i shall be mapped to the codepoint of the corresponding DCI field. The codepoint to which the Slot Offset is mapped is determined by its ordinal position among all the Slot Offsets with Ti field set to <NUM>, i.e. the first Slot Offset with Ti field set to <NUM> shall be mapped to the codepoint value <NUM>, second Slot Offset with Ti field set to <NUM> shall be mapped to the codepoint value <NUM> and so on. The maximum number of mapped Slot Offsets is a first number; the maximum number of selected Slot Offsets is a second number.

In one variant of this embodiment, there is a pre-determined mapping between the SRS resource sets A, B, C, etc. in the MAC CE and the RRC configured SRS resource sets with SRS resource set ID <NUM>,<NUM>,<NUM>, etc., such that SRS resource set A is always associated with SRS resource set ID <NUM>, SRS resource set B is always associated to SRS resource set ID <NUM> and so on, and if no SRS resource set is configured with for example SRS resource set ID <NUM>, then the UE should ignore the entries for the corresponding octave/octet (Oct <NUM> in the example) (i.e. the entries of the octave associated with SRS resource set A).

In another variant of this embodiment, the mapping between MAC CE SRS resource set A, B, C, etc. and the RRC configured SRS resource sets with SRS resource set ID <NUM>,<NUM>,<NUM>, etc. based on the currently RRC configured SRS resource sets and their corresponding SRS resource set IDs. For example, assume that three SRS resource sets are RRC configured with SRS resource set ID = [<NUM>,<NUM>,<NUM>]. Then one can associate the RRC configured SRS resource set with the SRS resource sets in the MAC-CE according to lowest SRS resource set IDs, such that the RRC configured SRS resource set with SRS resource set ID <NUM>, is associated with MAC CE SRS resource set A (i.e. Octave <NUM> in the example), the RRC configured SRS resource set with SRS resource set ID <NUM>, is associated with MAC CE SRS resource set B (i.e. Octave <NUM> in the example), and the RRC configured SRS resource set with SRS resource set ID <NUM>, is associated with MAC CE SRS resource set C (i.e. octave <NUM> in the example).

When the UE receives a MAC CE of <FIG>, the UE can determine which timing offset (slot offset) is activated or not, with each timing offset associated with a DCI codepoint, a timing value given by slot offset r-<NUM> and a SRS resource set.

Note that, throughout the disclosure, examples for ASN1 code (data structures) and MAC CE design are provided. There may be several other examples that fulfill the same principles and are thus covered by the embodiments.

<FIG> illustrates a flow chart of a method <NUM> for transmitting a reference signal. The method <NUM> can be implemented in a wireless device, for example and may comprise:.

According to an embodiment of the present disclosure, the size of the slot offset bitfield can depend on a number
of slot offset values in the list of slot offset values. For example, the size of the slot offset bitfield can be given by ceil(log<NUM>(tmax)), where tmax is the maximum number of offset values in the configured list of slot offset values.

According to the present disclosure, the size of the slot offset bitfield is equal to zero if a single slot offset value is configured in the list of slot offset values.

In some examples, a codepoint <NUM> of the slot offset bitfield can indicate a first slot offset value of the list of slot offset values, a codepoint <NUM> of the slot offset bitfield can indicate a second slot offset value of the list of slot offset values, a codepoint <NUM> of the slot offset bitfield can indicate a third slot offset value of the list of slot offset values and a codepoint <NUM> of the slot offset bitfield can indicate a fourth slot offset value of the list of slot offset values.

In some examples, the wireless device may receive a MAC CE for updating a slot offset value indicated by the slot offset bitfield in the DCI.

In some examples, upon receipt of the MAC CE, the wireless device may determine an updated slot offset value associated with a codepoint of the slot offset bitfield of the DCI. To do so, in some examples, the wireless device may obtain the updated slot offset value from the MAC CE, which is associated with the codepoint of the slot offset bitfield of the DCI. In other examples, the wireless device may obtain the updated slot offset value from the MAC CE, the updated slot offset value being associated with the codepoint of the slot offset bitfield of the DCI based on a position of the field comprising the updated offset value within the MAC CE.

As a note, the DCI triggering the SRS resource set may mean that the DCI indicates to the UE which SRS resource set to use when transmitting a SRS to the network node.

<FIG> illustrates a flow chart of a method <NUM> for receiving a reference signal from a wireless device. The method <NUM> can be implemented in a network node and may comprise:.

In some examples, the size of the slot offset bitfield may depend on a number of slot offset values in the list of slot offset values. For example, the size of the slot offset bitfield can be given by ceil(log<NUM>(tmax)), where tmax is the maximum number of offset values in the configured list of slot offset values.

In some examples, the size of the slot offset bitfield is equal to zero if a single slot offset value is configured in the list of slot offset values.

In some examples, the network node can send a MAC CE for updating a slot offset value indicated by the slot offset bitfield in the DCI.

<FIG> illustrates an example of a wireless network <NUM> that may be used for wireless communications. Wireless network <NUM> includes UEs <NUM> and a plurality of radio network nodes <NUM> (e.g., Node Bs (NBs) Radio Network Controllers (RNCs), evolved NBs (eNBs), next generation NB (gNBs), etc.) directly or indirectly connected to a core network <NUM> which may comprise various core network nodes. The network <NUM> may use any suitable radio access network (RAN) deployment scenarios, including Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (UTRAN), and Evolved UMTS Terrestrial Radio Access Network (EUTRAN). UEs <NUM> may be capable of communicating directly with radio network nodes <NUM> over a wireless interface. In certain embodiments, UEs may also be capable of communicating with each other via device-to-device (D2D) communication. In certain embodiments, network nodes <NUM> may also be capable of communicating with each other, e.g. via an interface (e.g. X2 in LTE or other suitable interface).

As an example, UE <NUM> may communicate with radio network node <NUM> over a wireless interface. That is, UE <NUM> may transmit wireless signals to and/or receive wireless signals from radio network node <NUM>. The wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information. In some embodiments, an area of wireless signal coverage associated with a radio network node <NUM> may be referred to as a cell.

It should be noted that a UE may be a wireless device, a radio communication device, target device, device to device (D2D) UE, machine type UE or UE capable of machine to machine communication (M2M), a sensor equipped with UE, iPAD, Tablet, mobile terminals, smart phone, laptop embedded equipped (LEE), laptop mounted equipment (LME), Universal Serial Bus (USB) dongles, Customer Premises Equipment (CPE) etc..

In some embodiments, the "network node" can be any kind of network node which may comprise of a radio network node such as a radio access node (which can include a base station, radio base station, base transceiver station, base station controller, network controller, gNB, NR BS, evolved Node B (eNB), Node B, Multi-cell/multicast Coordination Entity (MCE), relay node, access point, radio access point, Remote Radio Unit (RRU), Remote Radio Head (RRH), a multi-standard BS (also known as MSR BS), etc.), a core network node (e.g., MME, SON node, a coordinating node, positioning node, MDT node, etc.), or even an external node (e.g., 3rd party node, a node external to the current network), etc. The network node may also comprise a test equipment. The network node <NUM> may be an IAB node, a child IAB node, a parent IAB node or an IAB donor. Furthermore, the IAB node <NUM> nay have components as a MT and/or DU.

In certain embodiments, network nodes <NUM> may interface with a radio network controller (not shown). The radio network controller may control network nodes <NUM> and may provide certain radio resource management functions, mobility management functions, and/or other suitable functions. In certain embodiments, the functions of the radio network controller may be included in the network node <NUM>. The radio network controller may interface with the core network node <NUM>. In certain embodiments, the radio network controller may interface with the core network node <NUM> via the interconnecting network <NUM>.

The interconnecting network <NUM> may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. The interconnecting network <NUM> may include all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, or any other suitable communication link, including combinations thereof.

In some embodiments, the core network node <NUM> may manage the establishment of communication sessions and various other functionalities for wireless devices <NUM>. Examples of core network node <NUM> may include MSC, MME, SGW, PGW, O&M, OSS, SON, positioning node (e.g. E-SMLC), MDT node, etc. Wireless devices <NUM> may exchange certain signals with the core network node <NUM> using the non-access stratum layer. In non-access stratum signaling, signals between wireless devices <NUM> and the core network node <NUM> may be transparently passed through the radio access network. In certain embodiments, network nodes <NUM> may interface with one or more other network nodes over an internode interface. For example, network nodes <NUM> may interface each other over an X2 interface.

Although <FIG> illustrates a particular arrangement of network <NUM>, the present disclosure contemplates that the various embodiments described herein may be applied to a variety of networks having any suitable configuration. For example, network <NUM> may include any suitable number of wireless devices <NUM> and network nodes <NUM>, as well as any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device (such as a landline telephone). The embodiments may be implemented in any appropriate type of telecommunication system supporting any suitable communication standards and using any suitable components and are applicable to any radio access technology (RAT) or multi-RAT systems in which the wireless device receives and/or transmits signals (e.g., data). While embodiments are described for NR and/or LTE, the embodiments may be applicable to any RAT, such as UTRA, E-UTRA, narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT (NR, NX), <NUM>, <NUM>, LTE FDD/TDD, etc. The network <NUM> (with the wireless devices <NUM> and network nodes <NUM>) may be able to operate in LAA or unlicensed spectrum.

<FIG> is a schematic block diagram of the wireless device <NUM> according to some embodiments. As illustrated, the wireless device <NUM> includes circuitry <NUM> comprising one or more processors <NUM> (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like) and memory <NUM>. The wireless device <NUM> also includes one or more transceivers <NUM> each including one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. Furthermore, the processing circuitry <NUM> may be connected to an input interface <NUM> and an output interface <NUM>. The input interface <NUM> and the output interface <NUM> may be referred to as communication interfaces. The wireless device <NUM> may further comprise power source <NUM>.

In some embodiments, the functionality of the wireless device <NUM> described above may be fully or partially implemented in software that is, e.g., stored in the memory <NUM> and executed by the processor(s) <NUM>. For example, the processor <NUM> is configured to perform all the functionalities performed by the wireless device <NUM>, such as method <NUM> of <FIG>.

In some embodiments, a computer program including instructions which, when executed by the at least one processor <NUM>, causes the at least one processor <NUM> to carry out the functionality of the wireless device <NUM> according to any of the embodiments described herein is provided. In some embodiments, a carrier containing the aforementioned computer program product is provided.

<FIG> is a schematic block diagram of a network node <NUM> according to some embodiments of the present disclosure. As illustrated, the network node <NUM> includes a processing circuitry <NUM> comprising one or more processors <NUM> (e.g., CPUs, ASICs, FPGAs, and/or the like) and memory <NUM>. The network node also comprises a network interface <NUM>. The network node <NUM> also includes one or more transceivers <NUM> that each include one or more transmitters <NUM> and one or more receivers <NUM> coupled to one or more antennas <NUM>. In some embodiments, the functionality of the network node <NUM> described above may be fully or partially implemented in software that is, e.g., stored in the memory <NUM> and executed by the processor(s) <NUM>. For example, the processor <NUM> can be configured to perform any steps of the method <NUM> of <FIG>.

<FIG> is a schematic block diagram that illustrates a virtualized embodiment of the wireless device <NUM> or network node <NUM>, according to some embodiments of the present disclosure. As used herein, a "virtualized" node <NUM> is a network node <NUM> or wireless device <NUM> in which at least a portion of the functionality of the network node <NUM> or wireless device <NUM> is implemented as a virtual component (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). For example, in <FIG>, there is provided an instance or a virtual appliance <NUM> implementing the methods or parts of the methods of some embodiments. The one or more instance(s) runs in a cloud computing environment <NUM>. The cloud computing environment provides processing circuits <NUM> and memory <NUM>-<NUM> for the one or more instance(s) or virtual applications <NUM>. The memory <NUM>-<NUM> contains instructions <NUM> executable by the processing circuit <NUM> whereby the instance <NUM> is operative to execute the methods or part of the methods described herein in relation to some embodiments.

The cloud computing environment <NUM> comprises one or more general-purpose network devices including hardware <NUM> comprising a set of one or more processor(s) or processing circuits <NUM>, which may be commercial off-the-shelf (COTS) processors, dedicated Application Specific Integrated Circuits (ASICs), or any other type of processing circuit including digital or analog hardware components or special purpose processors, and network interface controller(s) (NICs) <NUM>, also known as network interface cards, which include physical Network Interface <NUM>. The general-purpose network device also includes non-transitory machine readable storage media <NUM>-<NUM> having stored therein software and/or instructions <NUM> executable by the processor <NUM>. During operation, the processor(s)/processing circuits <NUM> execute the software/instructions <NUM> to instantiate a hypervisor <NUM> (referred to as a virtual machine monitor (VMM)), and one or more virtual machines <NUM> that are run by the hypervisor <NUM>.

A virtual machine <NUM> is a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine; and applications generally do not know they are running on a virtual machine as opposed to running on a "bare metal" host electronic device, though some systems provide para-virtualization which allows an operating system or application to be aware of the presence of virtualization for optimization purposes. Each of the virtual machines <NUM>, and that part of the hardware <NUM> that executes that virtual machine <NUM>, be it hardware <NUM> dedicated to that virtual machine <NUM> and/or time slices of hardware <NUM> temporally shared by that virtual machine <NUM> with others of the virtual machine(s) <NUM>, forms a separate virtual network element(s) (VNE).

The hypervisor <NUM> may present a virtual operating platform that appears like networking hardware to virtual machine <NUM>, and the virtual machine <NUM> may be used to implement functionality such as control communication and configuration module(s) and forwarding table(s), this virtualization of the hardware is sometimes referred to as network function virtualization (NFV). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in Data centers, and customer premise equipment (CPE). Different embodiments of the instance or virtual application <NUM> may be implemented on one or more of the virtual machine(s) <NUM>, and the implementations may be made differently.

The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium, memory).

Claim 1:
A method (<NUM>), performed by a wireless device (<NUM>), for transmitting a reference signal, the method comprising:
- receiving (<NUM>) a configuration via Radio Resource Control, RRC, from a network node (<NUM>), the configuration comprising a list of slot offset values configured for a Sounding Reference Signal, SRS, resource set;
- receiving (<NUM>) Downlink Control Information, DCI, triggering the SRS resource set, wherein the DCI contains a slot offset bitfield for indicating one of the slot offset values in the list of slot offset values, wherein each entry of the list of slot offset values corresponds to a codepoint of the slot offset bitfield and wherein a size of the slot offset bitfield changes with a number of slot offset values in the list of slot offset values and the size of the slot offset bitfield is equal to zero if a single slot offset value is configured in the list of slot offset values; and
- transmitting (<NUM>) a reference signal using SRS resources configured in the triggered SRS resource set based on the indicated slot offset value.