`
`Sevilla, Spain
`
`January 14 ~ 18, 2008
`
`________________________________________________________________________________
`
`Agenda item: 6.1.4
`
`Source: LG Electronics
`
`Title: PUSCH multiplexing of data, control, and ACK/NACK information
`
`Document for: Discussion & Decision
`
`________________________________________________________________________________
`
`1.
`
`Introduction
`
`In Athens (#50) it was decided that when control information is to be multiplexed with data, data information is
`
`rate matched with control, and that the ACK/NACK information is to be inserted into PUSCH by either puncturing data
`
`or control information bits. Also it was decided that all control information should be positioned next to the reference
`
`signal, and positioned in both slots of the subframe. In this contribution we propose a simple multiplexing structure for
`
`data and control information and ACK/NACK puncturing position candidates.
`
`2. PUSCH multiplexing structure for control information
`
`The current description of TS36.212 shows that the control information is multiplexed with rate matched data
`
`information so that control information is always positioned near the Reference Signal (RS). Although the current
`
`description does not show the multiplexing structure when ACK/NACK is also to be multiplexed, the rate matched data
`
`and control information should not be configured differently depending on whether ACK/NACK is to be multiplexed or
`
`not. This is because the ACK/NACK should be punctured into the data and control multiplexed bit stream, to avoid
`
`erroneous exceptions in the UE procedure. This is shown in figure 1. In figure 1, virtual subcarrier is the logical input
`
`indices to the DFT transform which output is mapped to the physical subcarriers of the IFFT input in SC-FDMA. We
`
`have dubbed them virtual sub-carriers since they do not actually represent the physical subcarriers.
`
`Figure 1. Example of data and control multiplex structure according to TS36.212
`
`According to the working assumption ACK/NACK information is also to be positioned near the RS. There may be
`
`1/19
`
`SC-FDMA Symbol
`
`Reference Signal
`
`Reference Signal
`
`Data
`
`Control
`
`Virtual sub-carrier
`
`Optis Cellular Ex 2013-p. 1
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`at least 2 options available. The first option is to position the ACK/NACK information right next the RS, effectively
`
`puncturing out either data or control information in the process. The second option is not to puncture out control
`
`information and only puncture out data information. The first option is not desirable due to disastrous cases where the
`
`ACK/NACK information may puncture out most of the control information, resulting in performance loss in control
`
`information as well as not able to meet the target error rate requirements. The difference between option 1 and option 2
`
`is shown in figure 2.
`
`(a) option 1
`
`
`
`
`
`
`
`
`
`(b) option 2
`
`Figure 2. Example of possible ACK/NACK puncturing positions
`
`
`
`
`
`The key point of option 2 is that the control information is prioritized before ACK/NACK information, and
`
`positioned closer the RS. While this seems to be one feasible solution, in general ACK/NACK information is more
`
`important than control information which is basically the channel quality information of the downlink. We can even see
`
`this in the target quality requirements on the PUCCH [1]. Since positioning of control information near the RS is so that
`
`we may utilize better channel estimation performances in high UE mobility scenerios, it seems more logical to position
`
`the ACK/NACK closer to the RS than the control information. So one possibility is to switch the positions of control
`
`and ACK/NACK in option 2 so that the ACK/NACK is positioned closer to the RS, but this would mean that the control
`
`information would be positioned further away from the RS even in cases where there is no ACK/NACK multiplexed in
`
`the PUSCH. In this possibility, we would sacrifice control information performance (even though it may be slight) in all
`
`cases regardless whether we have ACK/NACK transmitting in PUSCH.
`
`
`
`In light of these observations, we propose to multiplex the control information in a uniform manner across all SC-
`
`FDMA symbols. This would effectively mean that the control information is multiplexed so that it is not only positioned
`
`near the RS, rather positioned in all SD-FDMA symbols. Since the PUSCH is mapped to physical resources by a simple
`
`time-first mapping rule, our proposal would also mean that the control information is multiplexed with data by simple
`
`serial concatenation with data information and mapped altogether by this simple time-first mapping rule. This is
`
`illustrated in figure 3.
`
`2/19
`
`SC-FDMA Symbol
`
`SC-FDMA Symbol
`
`Reference Signal
`
`Reference Signal
`
`Reference Signal
`
`Reference Signal
`
`Virtual sub-carrier
`
`Virtual sub-carrier
`
`Data
`
`Control
`
`ACK/NACK
`
`Data
`
`Control
`
`ACK/NACK
`
`Optis Cellular Ex 2013-p. 2
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`Figure 3. Proposed data and control multiplexing structure
`
`
`
`This will simplify the control information multiplexing with data, compared to the current description of TS36.212.
`
`The current TS36.212 structure must incorporate different PUSCH subframe formats and control information size, and
`
`match them to one of the 18 tables and then multiplex the control information in between the data information so that
`
`the physical resource time-first mapping will position the control information near the RS. Using the proposed structure
`
`we only need to describe that the control information is serially concatenated with data information, and the physical
`
`resource time-first mapping will take care of the rest. It also has an advantage of having equal number of resource
`
`elements near the RS for each code block, when there are multiple code blocks, compared to the current description of
`
`TS36.212, where the number of resource elements near the RS for code block can be significantly different resulting in
`
`slightly different BLER performance for each code block in high UE mobility scenarios.
`
`Figure 4. Possible ACK/NACK puncturing positions in the proposed multiplexing structure
`
`
`
`
`
`3/19
`
`…
`
`…
`
`Time- First Mapping
`
`SC-FDMA Symbol
`
`Reference Signal
`
`Reference Signal
`
`Data
`
`Control
`
`ACK/NACK
`
`Virtual sub-carrier
`
`SC-FDMA Symbol
`
`Reference Signal
`
`Reference Signal
`
`Data
`
`Control
`
`ACK/NACK
`
`Virtual sub-carrier
`
`Optis Cellular Ex 2013-p. 3
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`The proposed structure also has the advantage of always being able to position the ACK/NACK information,
`
`which in our opinion by far more important than the channel quality information, near the RS. This is shown in figure 4.
`
`In this structure we may position the ACK/NACK information near the RS and always fully utilize better channel
`
`estimation effects. In figure 5, we have simulated BLER performance between the proposed control information
`
`mapping structure (called time uniform in the figures), and the current TS36.212 control information mapping structure
`
`(called Near RS in the figures). Simulation assumptions and more simulation results are given in the Annex.
`
`
`
`
`Figure 5. BLER performance of control information in PUSCH in 350km/hr UE mobility environment
`
`
`
`For a target quality requirement of 1% BLER there is no difference between the control information uniform
`
`spread over time and control information positioned only near RS up to 120km/hr UE mobility cases. There is only 1dB
`
`performance difference in 350km/hr UE mobility scenarios, but it is questionable whereas to channel quality
`
`information at these extreme speeds is very important, so in our opinion this marginal performance loss has almost no
`
`impact in the system. We have also simulated BLER performance of ACK/NACK information transmitted in the
`
`PUSCH. The simulated results are shown in figures 6. In the figures ‘Next to RS(1)’ means that the ACK/NACK signal
`
`is positioned right next the RSes, ‘Next to RS(2)’ means that the ACK/NACK signal is positioned one SC-FDMA
`
`symbol further away, and ‘Next to RS(3)’ means that the ACK/NACK signal is positioned two SC-FDMA symbols
`
`further away, which is the most extreme case.
`
`
`
`4/19
`
`ETU 350km, Payload 40bits, 1/3 Code Rate QPSK
`
`Near RS
`
`Time Uniform
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 4
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`Figure 6. BLER performance of ACK/NACK in PUSCH in 350km/hr UE mobility environment
`
`
`
`Since the proposed data, control and ACK/NACK multiplexing structure will always position the ACK/NACK
`
`information right next to the RS (even in the extreme cases), this can be seen as ‘Next to RS(1)’ or possibly mixture of
`
`‘Next to RS(1)’ and ‘Next to RS(2)’. For 350km/hr UE mobility and above in some cases the proposed structure may
`
`
`
`have 1 to 1.5dB gain in ACK/NACK performance.
`
`
`
`3. Puncturing positions for ACK/NACK information
`
`Currently the actual insertion position of the ACK/NACK information in the PUSCH is not yet agreed. When we
`
`decided on the ACK/NACK information position in the PUSCH we believe we also need to consider punctured out
`
`effects of the data information. From this point we shall call the current TS36.212 control information multiplexing
`
`structure to be structure A, and the proposed control information multiplexing structure to be structure B.
`
`
`
`Data information multiplexed with control information may have several code blocks according to transport block
`
`payload size. Depending on how and how much the control information is multiplexed each code blocks in the data
`
`information will be placed in different resource elements. Figure 9 shows an example of where each code block is
`
`positioned in structure A. Due the control information multiplexing and time-first mapping rule, the number of virtual
`
`subcarriers used for each code block can be different. Basically the lowest code blocks may be mapped to more virtual
`
`subcarriers because control information has already taken place.
`
`
`
`5/19
`
`ETU 350km, 24 Repetitions, 4RB PUSCH
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 5
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`Figure 7. An example of data code block mapping into the PUSCH subframe
`
`
`
`
`
`If we assume that the ACK/NACK information is punctured to certain positions so that it is continuing where the
`
`control signal left off (like in the example in figure 2a) then this will lead to unequal puncturing of data information in
`
`each code block. So we propose to spread the ACK/NACK information across the virtual subcarrier evenly when
`
`puncturing ACK/NACK information into the data information resources. The proposed scheme is shown in figure 16
`
`(b). We can intuitively see that evenly spread ACK/NACK information will alleviate un-equal puncturing of code
`
`blocks.
`
`(a) Alternative ACK/NACK positioning
`
`
`
`(b) Proposed ACK/NACK positioning
`
`Figure 8. An example relationship between ACK/NACK puncturing position and data code block mappings in
`
`
`
`
`
`PUSCH
`
`The same can be said for the proposed control information multiplexing structure which is structure B. If we
`
`positioned the ACK/NACK signals to be consecutive in virtual subcarrier domain then we risk of puncturing only one
`
`or few of the code blocks out of many. Figure 11 shows the Proposed ACK/NACK positioning and the Alternative
`
`6/19
`
`Code Block 1
`
`Code Block 2
`
`Virtual sub-carrier
`
`Reference Signal
`
`Reference Signal
`
`SC-FDMA Symbol
`
`Data
`
`Control
`
`Code Block 1
`
`Code Block 2
`
`Code Block 1
`
`Code Block 2
`
`Virtual sub-carrier
`
`Virtual sub-carrier
`
`Reference Signal
`
`Reference Signal
`
`Reference Signal
`
`SC-FDMA Symbol
`
`Reference Signal
`
`SC-FDMA Symbol
`
`Data
`
`Control
`
`ACK/NACK
`
`Data
`
`Control
`
`ACK/NACK
`
`Optis Cellular Ex 2013-p. 6
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`ACK/NACK positioning method for the proposed control information multiplexing structure B.
`
`
`
`
`
`(a) Alternative ACK/NACK positioning
`
`
`
`(b) Proposed ACK/NACK positioning
`
`Figure 9. An example relationship between ACK/NACK puncturing position and data code block mappings in
`
`PUSCH
`
`
`
`4. Conclusion
`
`In conclusion we propose to adapt the proposed multiplex structure and ACK/NACK position scheme. Since we
`
`do not see a clear benefit from the current description of the multiplexing structure in TS36.212 and it may sacrifice
`
`potential performance benefits ACK/NACK information may have, by prioritizing channel quality information. The
`
`proposed structure is a clean solution to data control multiplexing and at the same time has almost no significant impact
`
`to system performance. So in summary we propose the following;
`
`
`
`
`
`
`
` Multiplexing of data and control by simple serial concatenation of information bits
`
` Spread the control information uniformly over time rather than positioning them only to be near
`
`RS
`
` Positioning ACK/NACK information near the RS
`
` Spreading the ACK/NACK puncturing positions to be evenly spread over virtual subcarriers
`
`(prior to DFT input).
`
`Reference
`
`[1] R1-071839, “LS on target quality requirements on L1/L2 control channel”, RAN WG1, 3GPP TSG RAN WG1
`
`Meeting #48bis, St.Julians, Malta, March, 2007.
`
`
`
`
`
`7/19
`
`Code Block 1
`
`Code Block 2
`
`Code Block 1
`
`Code Block 2
`
`Virtual sub-carrier
`
`Virtual sub-carrier
`
`Reference Signal
`
`Reference Signal
`
`Reference Signal
`
`SC-FDMA Symbol
`
`Reference Signal
`
`SC-FDMA Symbol
`
`Data
`
`Control
`
`ACK/NACK
`
`Data
`
`Control
`
`ACK/NACK
`
`Optis Cellular Ex 2013-p. 7
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`Annex. Simulation Results
`
`Parameter
`
`System Bandwidth
`
`Simulation assumptions
`
`Value
`
`5 MHz
`
`Number of RB used for PUSCH transmission
`
`4RB
`
`Channel Estimation
`
`Real Channel estimation using;
`
`Slot Averaging (assuming Frequency hopping)
`
`Time interpolated (utilizing both RS in one subframe)
`
`Number of Tx Antenna in UE
`
`Number of RX Antenna in eNB
`
`1
`
`2
`
`Channel Model
`
`Modulation
`
`LTE Extended Typical Urban (ETU in TS36.201)
`
`QPSK, 16QAM
`
`Channel Coding for control information
`
`Tail Biting Convolution Code
`
`Channel Coding for ACK/NACK
`
`Symbol Repetition
`
`Decoder for TCC
`
`Sub-optimum decoder
`
`Control information Payload size
`
`20, 40, 80 bits
`
`Control information Code Rate
`
`1/3 code rate , 3/4 code rate
`
`Number of ACK/NACK symbol repetitions
`
`24
`
`
`
`Control information BLER performance
`
`
`
`8/19
`
`ETU 3km, Payload 20bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 8
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`9/19
`
`ETU 3km, Payload 40bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 3km, Payload 80bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 3km, Payload 20bits, 3/4 Code Rate 16QAM
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 9
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`10/19
`
`ETU 3km, Payload 40bits, 3/4 Code Rate 16QAM
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 3km, Payload 40bits, 3/4 Code Rate 16QAM
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 30km, Payload 20bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 10
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`11/19
`
`ETU 30km, Payload 40bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 30km, Payload 80bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 30km, Payload 20bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 11
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`12/19
`
`ETU 30km, Payload 40bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 30km, Payload 40bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 120km, Payload 20bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 12
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`13/19
`
`ETU 120km, Payload 40bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 120km, Payload 80bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 120km, Payload 20bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 13
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`14/19
`
`ETU 120km, Payload 40bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 120km, Payload 40bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 350km, Payload 20bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 14
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`15/19
`
`ETU 350km, Payload 40bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 350km, Payload 80bits, 1/3 Code Rate QPSK
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 350km, Payload 20bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 15
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`16/19
`
`ETU 350km, Payload 40bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 350km, Payload 40bits, 3/4 Code Rate 16QAM
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Near RS - Slot Avg CE
`
`Time Uniform - Slot Avg CE
`
`Near RS - Interpolation CE
`
`Time Uniform - Interpolation CE
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 16
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`ACK/NACK signal BLER performance when transmitted in PUSCH
`
`
`
`
`
`
`
`17/19
`
`ETU 3km, 24 Repetitions, 4RB PUSCH, Interpolated CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 30km, 24 Repetitions, 4RB PUSCH, Interpolated CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 120km, 24 Repetitions, 4RB PUSCH, Interpolated CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 17
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`18/19
`
`ETU 350km, 24 Repetitions, 4RB PUSCH, Interpolated CE
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 3km, 24 Repetitions, 4RB PUSCH, Slot Avg CE
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 30km, 24 Repetitions, 4RB PUSCH, Slot Avg CE
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 18
`Apple v Optis Cellular
`IPR2020-00465
`
`
`
`
`
`
`
`
`
`19/19
`
`ETU 120km, 24 Repetitions, 4RB PUSCH, Slot Avg CE
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`ETU 350km, 24 Repetitions, 4RB PUSCH, Slot Avg CE
`
`Next to RS (1)
`
`Next to RS (2)
`
`Next to RS (3)
`
`1.00E+00
`
`1.00E-01
`
`1.00E-02
`
`1.00E-03
`
`-10
`
`-7
`
`-4
`
`-1
`
`2
`
`5
`
`8
`
`11
`
`14
`
`17
`
`Optis Cellular Ex 2013-p. 19
`Apple v Optis Cellular
`IPR2020-00465
`
`