3GPP TSG RAN WG1 #120-bis R1-2502861
Wuhan, China, April 7th – 11th, 2025
Agenda item: 9.13.1
Source: Qualcomm Incorporated
Title: Time and Frequency Interleaving for 5G Broadcast
Document for: Discussion and Decision
Time Interleaver
Scheduling of time-interleaved MTCH
With the subframe mapping at the physical layer agreed in the last meeting, we turn our attention to how these time-interleaved transmissions are scheduled. As described in TS 36.321, the MSI MAC-CE is used to schedule the MTCHs for a set of sessions configured by the higher layer parameter MBMS-SessionInfoList, provided in TS 36.331.
In the last meeting, the following agreement was made, with down-selection to be performed:
Agreement
Regarding configuration for time interleaving transmission, the following options can be considered:
Option 2: Per PMCH configuration, e.g., via pmch-Config
Option 3: Per MBMS session, e.g., via MBMS-SessionInfo or via MAC CE
We propose to preserve a “per MBMS session” granularity with regards to time-interleaving parameters, when we use time-interleaved MTCH transmissions. This provides the network to multiplex different types of services at once, where some services may be targeted to low-mobility (e.g., pedestrian) UEs, while certain others may be targeted to high-speed UEs, such as those on trains. These services will have different time-interleaving parameters that are optimal. With a “per PMCH” configuration, there would be as many MSIs required as the number of time-interleaving configurations supported across sessions, which is inefficient in terms of overhead.
In the light of the above discussion, we make the following proposal.
Proposal 1: Configuration of time interleaving parameters shall be done per MBMS session, via MBMS-SessionInfo.
We further need to examine any potential issues with how the current MSI is specified, and whether it can seamlessly accommodate the scheduling of services with time-interleaving.
In our previous contribution, we noted that the periodicities of the MSI are not a multiple of the -subframe basic unit of a time-interleaved transmission, and it was agreed that this issue should be studied by RAN1, as indicated below.
Agreement
RAN1 to further study the potential issue of mismatch between MSI periodicity and the basic transmission pattern of (M x N) subframes.
As we demonstrate in Table 1, this mismatch creates resource wastage (due to misalignment with the periodicities) to the tune of (a rather significant) .
Table : Resource wastage while scheduling time-interleaved MTCH using legacy MSI periodicities.
Observation 1: There is an approximately resource wastage while scheduling MTCH with time interleaving, using legacy MSI periodicities.
To mitigate the above problem in the most flexible manner (i.e., without restricting any configurations), we demonstrate in Fig. 1, that allowing the last MTCH from one MCH scheduling period to “spillover” into the next scheduling period—with a “starting offset” applied to each scheduling period, to accommodate the spillover—mitigates the potential misalignment issues with scheduling.
Observation 2: Allowing the last MTCH within a given MCH scheduling period to spill over into the next MCH scheduling period, along with specifying a starting offset for each MCH scheduling period, mitigates the scheduling misalignment issue with time interleaved sessions.
Keeping these observations in mind, we make the following proposal.
Proposal 2: For a MCH scheduling period, signal via the corresponding MSI, a starting pointer to the first subframe (with respect to the MSI) from which the MTCHs are scheduled.
Figure 1: Starting pointers and inter-period spillover of MTCH to handle misalignment between time-interleaved MTCH segments and MCH scheduling periods.
The first MTCH scheduled by the MSI in a MCH scheduling period should begin after the decoding of the MSI itself, to prevent unnecessary buffering of data and wastage of UE power while the MSI is still being processed. To this end, the MTCHs should start at least after a processing time associated with the decoding of the MSI. This is captured in the following proposal, which also considers the starting pointers described above.
Proposal 3: The scheduling delay from the MSI to the first MTCH ( scheduled by the MSI is given by , where
and reading bits from the circular buffer
With regards to the value of , the following agreement was made in the last meeting.
Agreement
The equation of k0 for time interleaving is modified to avoid puncturing of systematic bits.
Further study the exact equation for k0 for the n-th subframe of a transmission belonging to a same TB , ), including
Option 1: for each CB of the TB, , where (as per TS 36.212), and is the redundancy version of the n-th subframe.
Option 2: For each CB of the TB, follow the principle of NR TBoMS to determine
Option 1 and Option 2 assumes all CBs of the TB have the same RV index for all CBs of the TB, indexed by
FFS whether different CBs of the TB mapped to each subframe may have different RV indices (e.g., indexed by different per CB)
We note that Option 2 in the agreement above would require maintaining multiple values of (corresponding to the CBs of the TB) for circular buffer management. This is difficult in terms of implementation and maintaining a single pointer across the entire TB is strongly preferred. There is expected to be negligible performance difference, it at all, between the two approaches. To this end, we make the following proposal.
Proposal 4: For time-interleaved PMCH, specify the starting pointer for each CB of the TB as , where and is the redundancy version of the n-th subframe.
Values of interleaving parameters and
In the previous meeting, the following agreements were made, regarding the values of .
Agreement
At least values of N= {1,4,8} are supported, where N=1 indicates time interleaving is disabled.
FFS: other values
Agreement
Values of M = 16 and M = 8 are supported.
FFS other values
Note: some UE categories and depending on factors such as (value of N, bandwidth, MCS) may not be able to receive an interleaved MTCH with M=16.
We note that the time diversity that is achieved by a time-interleaving scheme is essentially governed by the depth of the time interleaver—which, in the current design, is given by . According to the currently agreed values, the largest interleaving depth we can achieve is 128 ms (corresponding to ).
As we demonstrate via simulations in Fig. 2 below (simulation parameters are given in Table 2), this is inadequate to extract sufficient time diversity from a channel that varies slowly, as would be the case for a typical pedestrian UE, moving at 3 kmph. For example, we observe a gain of in going from the current maximum interleaving depth of 128 ms, to a depth of 2048 ms, and a gain of when using a depth of 512 ms.
Table : Simulation Parameters for evaluating different time-interleaving depths.
Figure : Performance gains with increasing interleaving depths.
Observation 3: Increasing the interleaving depth (i.e., ) from the currently agreed maximum of 128 ms (for ), provides the following performance gains at a BLER of :
gain, when interleaving depth is increased to 512 ms ()
gain, when interleaving depth is increased to 2048 ms
While the time diversity gains demonstrated above are too significant to not be harnessed by allowing for the configuration of larger values of , we must also stay within the processing constraints of UEs, in terms of the total soft buffer size and the maximum TBS supportable in a TTI, both of which are impacted by the values of and .
In discussing the above issue, we note that allowing the provision for large values does not mean that the network must use them—it provides the network the option to configure such values (e.g., in case the network is primarily addressing low mobility UEs, such as pedestrians carrying high-capability smartphones), so that the time-diversity gains that could be achieved in that scenario (as shown above) are not left unharnessed.
We also note that the lower the MCS, the larger the values of that can be supported. Even if the largest MCSs (indicated by the value) cannot be supported with the largest values of , there are several MCSs that can indeed support the largest values of .
In Table 3 below, we provide the maximum values of that can be supported for different values of and , for a Cat 12 UE, operating in a 6 MHz (30 PRB) UHF channel. In determining the quantity in the table, we used the following steps (which respects both the maximum TBS supportable in a TTI, as well as the total soft buffer size of the UE, as given by TS 36.306):
Computed as the maximum number of soft information bits per interleaved TB, where
Determine , as the maximum TBS supportable in a TTI, for a given UE category
Compute
Table : Max supportable for different values of for a Cat-12 UE in a 6 MHz UHF channel
Observation 4: Several MCSs can be supported with values of up to , while remaining within the processing constraints of the UE, in terms of its total soft buffer size and maximum supportable TBS.
For a Cat 12 UE, over a 6 MHz UHF channel:
can support
can support
can support
Note that, while we have shown the supportable values for a Cat 12 UE in Table 3, for higher category UEs, with larger total soft buffer sizes and/or larger maximum TBSs supported, even larger values can be supported. The provision to harness maximum time-diversity for such UEs should not be restricted by limiting the configurable values of and .
With the above discussion in mind, we make the following proposal.
Proposal 5: For time-interleaving parameters and , the following additional values are supported:
Frequency Interleaver
With regards to the row-column frequency interleaver, the following agreement was made.
Agreement
The previous agreement is modified as follows:
The modulation symbol vector (prior to frequency interleaving) is interleaved, according to the principles of subclause 5.1.4.1.1 of TS 36.212 as follows
Set the number of columns of the frequency interleaver, , set the number of rows to be the minimum integer satisfying , where Z is the number of data REs in one OFDM symbol
FFS: How to determine X
Option 1: X is equal to the number of codeblocks that are mapped to the OFDM symbol
Option 2: X=32
Other options are not precluded.
Append with elements, as required, to obtain
Write the elements of into the -matrix column-wise, with in column 0 of row 0.
FFS whether the rows and elements in each row will be permuted, with details to be further studied, e.g., intra-row cyclic shifts, inter-row permutations
Obtain the vector by reading the elements of the above -matrix row-wise, excluding the .
The vector shall then be mapped to resource elements, according to clause 6.3.5 of TS 36.211.
FFS: whether to apply a cyclic shift offset, and the details of the cyclic shift offset for the concatenated frequency interleaver outputs of all OFDM symbols before the mapping to REs of a subframe, where the cyclic shift offset is dependent on the RV index.
Guidance was also provided in terms of evaluation of the frequency interleaver over the “Two Path Ensemble” channel, as reproduced below. This is a particularly relevant channel model to test the performance of interleavers over Single Frequency Networks (SFNs), where multiple strong paths (from the transmitters constituting the SFN) can arrive with different delays, in the overall channel impulse response.
Guidance for the next meeting:
To evaluate frequency interleavers, the “Two Path Ensemble” channel profile defined in Table A.1.1, Annex A of A325-2024-04” (with delay to be selected by proponents but less than 0.95*CP) can be used by companies.
In this section, we will mainly focus on the following aspects, that are important for the design of the frequency interleaver, and provide simulation results supporting our proposals in the process:
The necessity of cyclic shifts applied to the rows of the frequency interleaver, to provide protection against strong nulls in frequency
The importance of appropriately selecting the number of columns, , in the interleaver design.
The impact of different numerologies (i.e., number of OFDM symbols in a subframe) on the interleaver design
Insights from a numerology with one OFDM symbol per subframe
We first evaluate the performance of the frequency interleaver in [1], using the { CP / } numerology, over the “Two Path Ensemble” channel, with different configurations of the number of columns , with and without the application of row-specific cyclic shifts. The simulation parameters are provided in Table 4, while the results are depicted in Fig. 3. As is well known, with this numerology, there is OFDM symbol per subframe.
To create a pessimistic scenario for the case when the number of columns , we use a relative delay between the two taps such that the periodic nulls in frequency exactly coincide with the REs of one of the codeblocks (in the absence of row-specific cyclic shifts), thereby making it nearly impossible to decode the TB, since the pathologically impacted codeblock will almost always fail. This is evident in the performance of the blue dashed curve in Fig. 3 (FI without cyclic shifts, ). Note that, with the same relative delay between the two taps, for (Option 2 in the previous RAN1 agreement), no codeblock is universally impacted by the nulls—in other words, even in the absence of cyclic shifts, the channel used is not pathologic for , and hence, we see that the black dashed curve in Fig. 3 (FI without cyclic shifts,) performs better than the blue-dashed curve, which is pathologically impacted by the channel, as described above. However, note that, over this channel, without cyclic shifts, even the performance of is unacceptable, due to the obvious flooring well before even a BLER of .
However, when cyclic shifts are introduced (the solid lines in Fig. 3), the entire calculus changes. The cyclic shifts spread the REs around such that the pathology is no longer concentrated in one codeblock, while—for —ensures that the other properties of the matrix (importantly, mapping one CB per column, before the permutation and cyclic shift operations) preserve the essence of the careful design. On the other hand, for , the “one CB per column” attribute is lost, which renders the following matrix operations (row permutation, cyclic shifts) to be highly suboptimal, due to the column-to-codeblock mismatch.
This is clearly evidenced by the fact that in Fig. 3, the blue solid curve (FI with Cyclic Shifts, ) significantly outperforms (and does not floor at a BLER of even ) the black solid curve (FI with Cyclic Shifts, ), which, due to the misalignment between codeblock boundaries and columns, cannot even harness the benefits from cyclic shifts.
This leads us to make the following observations and proposal:
Observation 5: For a two-tap channel with inter-tap delays explicitly chosen to be pathologic to a row-column interleaver with (which, by definition, is NOT pathologic to an interleaver with ), an interleaver with and row-specific cyclic shifts significantly outperforms an interleaver with and row-specific cyclic shifts.
This highlights the following key components in a good design of the frequency interleaver:
Alignment of codeblocks with column boundaries (i.e., one column does NOT contain large chunks of different codeblocks) is essential to maintain the desirable properties of the frequency interleaving matrix operations
Row-specific cyclic shits are critical to provide protection against periodic nulls in frequency
Proposal 6: Row-specific cyclic shifts, as described in [1], are specified for the frequency interleaver.
Table : Simulation parameters for performance evaluation of frequency interleavers.
Figure : Impact of cyclic shifts, and the number of columns , on frequency interleaver performance.
The evaluations in Figure 3 have been performed by applying the row permutation operation introduced in [1]. This row permutation spreads the systematic bits across the entire bandwidth, which can be seen to improve the performance.
Proposal 7: The row permutation operation described in [1] is applied to the frequency interleaver.
Insights from a numerology with
While the alignment of codeblocks with column boundaries is straightforward when (employing , as described in [1]), the design needs to be more nuanced when . While we have established in the previous subsection () that using a “fixed” value of (such as , in “Option 2”) is detrimental to frequency interleaver performance, we will further argue here, that “Option 1” (in the previous agreement) for determining the value of is also not the right way to go, when . In this section, we aim at adapting the design in [1] for the case where .
Let us first consider the numerology with { CP / }, which has . Assume that we have the same number of codeblocks as before, i.e., (CB1, CB2, …, CB5). Per Option 1 of the agreement, there would be three codeblocks (two complete, and one partial) that would be mapped to each of the two OFDM symbols in the subframe. As a result, the alignment between codeblocks and column boundaries for the second OFDM symbol will be totally lost—the first column will have (approximately) half of CB3 and half of CB4; the second column will have half of CB4 and half of CB5; the third column will have half of CB5 and the rest NULLs.
Observation 6: For , a TB comprising an odd number of CBs will lead to complete misalignment between codeblocks and column boundaries for the second OFDM symbol.
An immediate way to fix the misalignment appears to be setting in the TB. While this does mitigate the misalignment issue (each column contains of each codeblock), this creates the issue that we may be using more columns than the minimum necessary. When this is the case, during a “row-wise readout”, there will be several REs from the same CB that will be consecutive. This is not a desirable situation, since the row-specific cyclic shifts will not be to offer adequate protection against pathological fades, in this setting.
Observation 7: While ensures alignment between codeblocks and column boundaries, it does not minimize the “column span” of each CB (i.e., number of columns that each CB is mapped to)
During a row-by-row readout, this leads to consecutive elements (equal in number to the column span of each CB) from the same CB appearing adjacently in the output
This leads to susceptibility to pathologic fades in frequency, even in the presence of cyclic shifts.
The way to minimize the column span of each CB, while still maintaining codeblock alignment with the column boundaries is to divide the by the greatest common divisor (GCD) of and .
Observation 8: minimizes the column-span of each codeblock in the frequency interleaving matrix, while still maintaining alignment of codeblocks with column boundaries.
Proposal 8: Set the number of columns, , of the frequency interleaver as , where denotes the number of CBs in the TB, denotes the number of OFDM symbols of the PMCH, and denotes the operation to compute the greatest common divisor.
When , this is the same as “Option 1” in the RAN1 agreement and in [1]
With the value of in the proposal above, while we have minimized the column span of each CB, the column span for the CB is still greater than 1, in general. As a result, even with the application of a row-specific cyclic shift, there will be consecutive elements from the codeblock during a row-wise readout. Especially for larger ’s, (e.g., for larger values corresponding to 7.5 kHz or 15 kHz subcarrier spacings), these consecutive elements need to be spread out, before the application of the row-specific cyclic shift. The simplest way to achieve this, is to apply a column permutation, prior to the application of the cyclic shifts.
Observation 9: The column span of the codeblock, will result in consecutive elements from the same codeblock being mapped consecutively to physical resources
This results in suboptimal frequency diversity for the codeblocks
A column permutation operation prior to the application of row-specific cyclic shifts mitigates this issue
Proposal 9: At least for the case of , permute the columns of the frequency interleaving matrix, prior to applying row-specific cyclic shifts.
To illustrate the merits of the proposals made above, we provide simulation results for the 100/400 numerology , with the simulation parameters in Table 5, and the results provided in Fig. 4.
We observe in Fig. 4, that provides:
gain over (Option 2) at a BLER of
gain over (Option 1) at a BLER of
We also observe that the column permutation operation to spread out the sized chunks provide an additional improvement in performance—this gain is expected to increase for numerologies and TBSs with larger values.
Table : Simulation parameters for 100/400 numerology.
Figure : Impact of number of columns and column permutations on frequency interleaver performance for
Conclusion
In this contribution we presented our views on Time-Frequency Interleaving for 5G Broadcast. Our proposals and observations are summarized below.
Proposal 1: Configuration of time interleaving parameters shall be done per MBMS session, via MBMS-SessionInfo.
Observation 1: There is an approximately resource wastage while scheduling MTCH with time interleaving, using legacy MSI periodicities.
Observation 2: Allowing the last MTCH within a given MCH scheduling period to spill over into the next MCH scheduling period, along with specifying a starting offset for each MCH scheduling period, mitigates the scheduling misalignment issue with time interleaved sessions.
Proposal 2: For a MCH scheduling period, signal via the corresponding MSI, a starting pointer to the first subframe (with respect to the MSI) from which the MTCHs are scheduled.
Proposal 3: The scheduling delay from the MSI to the first MTCH ( scheduled by the MSI is given by , where
Proposal 4: For time-interleaved PMCH, specify the starting pointer for each CB of the TB as , where and is the redundancy version of the n-th subframe.
Observation 3: Increasing the interleaving depth (i.e., ) from the currently agreed maximum of 128 ms (for ), provides the following performance gains at a BLER of :
gain, when interleaving depth is increased to 512 ms ()
gain, when interleaving depth is increased to 2048 ms
Observation 4: Several MCSs can be supported with values of up to , while remaining within the processing constraints of the UE, in terms of its total soft buffer size and maximum supportable TBS.
For a Cat 12 UE, over a 6 MHz UHF channel:
can support
can support
can support
Proposal 5: For time-interleaving parameters and , the following additional values are supported:
Observation 5: For a two-tap channel with inter-tap delays explicitly chosen to be pathologic to a row-column interleaver with (which, by definition, is NOT pathologic to an interleaver with ), an interleaver with and row-specific cyclic shifts significantly outperforms an interleaver with and row-specific cyclic shifts.
This highlights the following key components in a good design of the frequency interleaver:
Alignment of codeblocks with column boundaries (i.e., one column does NOT contain large chunks of different codeblocks) is essential to maintain the desirable properties of the frequency interleaving matrix operations
Row-specific cyclic shits are critical to provide protection against periodic nulls in frequency
Proposal 6: Row-specific cyclic shifts, as described in [1], are specified for the frequency interleaver.
Proposal 7: The row permutation operation described in [1] is applied to the frequency interleaver.
Observation 6: For , a TB comprising an odd number of CBs will lead to complete misalignment between codeblocks and column boundaries for the second OFDM symbol.
Observation 7: While ensures alignment between codeblocks and column boundaries, it does not minimize the “column span” of each CB (i.e., number of columns that each CB is mapped to)
During a row-by-row readout, this leads to consecutive elements (equal in number to the column span of each CB) from the same CB appearing adjacently in the output
This leads to susceptibility to pathologic fades in frequency, even in the presence of cyclic shifts.
Observation 8: minimizes the column-span of each codeblock in the frequency interleaving matrix, while still maintaining alignment of codeblocks with column boundaries.
Proposal 8: Set the number of columns, , of the frequency interleaver as , where denotes the number of CBs in the TB, denotes the number of OFDM symbols of the PMCH, and denotes the operation to compute the greatest common divisor.
When , this is the same as “Option 1” in the RAN1 agreement and in [1]
Observation 9: The column span of the codeblock, will result in consecutive elements from the same codeblock being mapped consecutively to physical resources
This results in suboptimal frequency diversity for the codeblocks
A column permutation operation prior to the application of row-specific cyclic shifts mitigates this issue
Proposal 9: At least for the case of , permute the columns of the frequency interleaving matrix, prior to applying row-specific cyclic shifts.
References
[1] R1-2500582, “Design of Time and Frequency Interleaver for LTE-based 5G Broadcast” by Shanghai Jiao Tong University, ABS, NERC-DTV, in RAN1#120.
|