3GPP TSG-RAN WG1 Meeting #103-e Tdoc R1-20xxxxx e-Meeting, October 26th – November 13th, 2020 Agenda Item: 8.6.1 Title: FL summary #8 for Potential UE complexity reduction features for RedCap Source: Moderator (Ericsson) Document for: Discussion, Decision 1 Introduction This document captures the following RAN1#103e RedCap email discussion. [103-e-NR-RedCap-02] Email discussion for potential UE complexity reduction features – Johan (Ericsson) The previous round of this email discussion is documented in FL summary #7 (FLS7) in R1-2009795. This round focuses on the following items. The latest versions of the proposals are tagged ‘FL2’ in this document. 1. TR clause 7.2.3: TP for reduced number of UE Rx branches on impact on power consumption 2. TR clause 7.2.4: TP for reduced number of UE Rx branches on impact on coexistence 3. TR clause 7.2.5: TP for reduced number of UE Rx branches on impact on specifications 4. TR clause 7.3.3: TP for UE bandwidth reduction on impact on data rates 5. TR clause 7.3.3: TP for UE bandwidth reduction on impact on power consumption 6. TR clause 7.3.4: TP for UE bandwidth reduction on impact on coexistence 7. TR clause 7.4.3: TP for half-duplex FDD operation on impact on data rates 8. TR clause 7.4.3: TP for half-duplex FDD operation on impact on latency and reliability 9. TR clause 7.4.4: TP for half-duplex FDD operation on impact on coexistence 10. TR clause 7.4.5: TP for half-duplex FDD operation on impact on specifications 11. TR clause 7.5.3: TP for relaxed UE processing time on impact on data rates 12. TR clause 7.5.3: TP for relaxed UE processing time on impact on power consumption 13. TR clause 7.5.4: TP for relaxed UE processing time on impact on coexistence 14. TR clause 7.5.5: TP for relaxed UE processing time on impact on specifications 15. TR clause 7.6.3: TP for relaxed maximum number of MIMO layers on impact on power consumption 16. TR clause 7.5.2: TP for relaxed UE processing time on UE complexity reduction for relaxed CSI computation time In ALL file names, please use hyphen characters (not underline characters) and include ‘v’ in front of the version numbers. Follow the naming convention in this example: * RedCapComplexityFLS8-v000.docx * RedCapComplexityFLS8-v001-CompanyA.docx * RedCapComplexityFLS8-v002-CompanyA-CompanyB.docx * RedCapComplexityFLS8-v003-CompanyB-CompanyC.docx If needed, you may “lock” a spreadsheet file for 30 minutes by creating a checkout file, as in this example: * Assume CompanyC wants to update RedCapComplexityFLS7-v008-CompanyA-CompanyB.docx. * CompanyC uploads an empty file named RedCapComplexityFLS7-v008-CompanyB-CompanyC.checkout * CompanyC then has 30 minutes to upload RedCapComplexityFLS7-v008-CompanyB-CompanyC.docx * If no update is uploaded in 30 minutes, other companies can ignore the checkout file. * Note that the file timestamps on the server are in UTC time. 2 Updated text proposals Based on email discussion responses in FLS7 (R1-2009795), the following TP for TR 38.875 can be considered, where the change tracking is relative to the corresponding TPs in FLS7. 7.2 Reduced number of UE Rx branches […] 7.2.3 Analysis of performance impacts […] Power consumption: The instantenous power consumption in the RF and the baseband modules of the UE is expected to be reduced due to the use of fewer RF chains and the reduction in the complexity of multi-antenna processing. However, downlink reception time may be longer for large payloads due to reduced spectal efficiency. […] 7.2.4 Analysis of coexistence with legacy UEs In general, RedCap UEs with reduced number of Rx branches can coexist with legacy UEs. However, the presence of RedCap UEs with reduced number of Rx branches may impact the performance for legacy UEs if some broadcast channels are used for both legacy UEs and RedCap UEs. This is because, if there is no early indication of RedCap UE, both legacy UEs and RedCap UEs will be treated the same by the network, which may lead to conservative treatment of all UEs. . If higher PDCCH aggregation levels are used for RedCap UEs, the PDCCH blocking probability for legacy UEs may be increased if they share the same CORESET. 7.2.5 Analysis of specification impacts For reduced number of Rx branches, work in RAN4 may be required to define new receiver characteristics, demodulation performance requirements, and requirements relating to CSI reporting, RF, RRM, and other procedures, such as cell handover or (re)selection, radio link management and beam management. RAN4 may also need to evaluate and specify new minimum numbers of Rx branches for RedCap UEs in different bands. Impacts on RAN4 specifications may also extend beyond the mentioned aspects. Additionally, to address the performance and coexistence impacts identified in subcluses 7.2.3 and 7.2.4, specification work in other working groups than RAN4 may be needed. […] 7.3 UE bandwidth reduction […] 7.3.3 Analysis of performance impacts Data rate: Bandwidth reduction results in a reduction in the achievable peak data rate. However, all the bandwidth options (20 MHz in FR1, and 50 MHz or 100 MHz in FR2) considered in the RedCap study are enough for meeting the peak data rate requirements for the RedCap use cases, at least when the bandwidth reduction is not combined with other UE complexity reduction techniques, except in some TDD configurations. For peak rate impacts from combinations of UE complexity reduction techniques, see clause 7.8.3. […] 7.3.4 Analysis of coexistence with legacy UEs In general, UE bandwidth options such as 20 MHz for FR1 UEs and 100 MHz for FR2 UEs achieve good coexistence performance with legacy UEs. * The 20-MHz bandwidth option for FR1 UEs allows a RedCap UE to reuse existing procedures for acquiring SSB, SIB1, other SIBs, RAR and Msg4. * The 100-MHz bandwidth option for FR2 UEs achieves the same coexistence benefits, except that for certain configurations for SSB/CORESET multiplexing patterns 2 and 3, the UE needs to acquire SSB and SIB1 in a sequential manner. However, the sequential SSB/SIB1 acqisition for a RedCap UE does not cause any performance degradation to legacy UEs. * The 50-MHz bandwidth option for FR2 UEs would result in coverage loss for PDCCH reception in CORESET#0 if CORESET#0 is configured to 69.12 MHz. In such cases, if coverage recovery is needed for PDCCH, PDCCH capacity of CORESET#0 may be affected, and this will have impact on legacy UEs. Furthermore, if early RedCap UE identification is not provided, supporting 50-MHz RedCap UEs requires the gNB to schedule the PDSCH of SIBs, RAR, and Msg4 within 50 MHz bandwidth. Such scheduling restrictions will have an impact on legacy UEs. If RedCap and eMBB UEs share the same initial BWP in downlink and uplink for initial access procedure, and the number of RedCap UEs in the network is large, gNB may need to use some means (e.g. access control) to avoid congestion due to high load or configuration restriction (e.g. for RACH occasions). […] 7.4 Half-duplex FDD operation […] 7.4.3 Analysis of performance impacts […] Data rate: There is minor impact from HD-FDD operation on instantaneous data rates for uplink or downlink, but similarly to TDD, HD-FDD reduces user throughput compared to FD-FDD, especially in case of simultaneous downlink and uplink traffic, and it may be challenging to meet the peak data rate requirements in downlink and uplink simultaneously. For peak rate impacts from other combinations of UE complexity reduction techniques, see clause 7.8.3. Latency and reliability: HD-FDD introduces longer latency than FD-HDD, especially in case of simultaneous downlink and uplink traffic, but the latency and reliability requirements of RedCap use cases can still be fulfilled at least for one direction (downlink or uplink). […] 7.4.4 Analysis of coexistence with legacy UEs Introducing HD-FDD operation might make gNB scheduling more complicated. The impact due to the support for HD-FDD Type B operation is greater than for Type A. For initial access, supporting HD-FDD Type B operation might have a potential impact on the RACH procedure in that longer time gaps between messages might be needed. One example is the switching time from PRACH to Msg2. Supporting HD-FDD Type B operation may cause a longer switching time from PRACH to Msg2 to be used for all UEs, if the RedCap UEs are not identified in Msg1. This is not an issue for Type A due to its faster UL-to-DL switching capability. 7.4.5 Analysis of specification impacts Introducing support for HD-FDD operation may have the following impacts on RAN1 specifications. * Specifying DL-to-UL and UL-to-DL switching time * Specifying how the UE handles DL/UL collision Depending on the detailed solution, it may or may not be possible to reuse existing RAN1 specification for non-full-duplex operation for support of HD-FDD operation type A (but not for type B). Additionally, HD-FDD support also has the following impacts on RAN4 specifications. * Specifying applicable bands * Specifying performance requirements such as reference sensitivity and RRM 7.5 Relaxed UE processing time […] 7.5.3 Analysis of performance impacts […] Data rate: No impact on instantaneous peak data rate is expected, but the UE throughput may be reduced if the HARQ round trip time is extended. The throughput requirements identified for the RedCap use cases are still expected to be fulfilled. Power consumption: Relaxed UE processing time in terms of N1 and N2 may allow for processing with lower clock frequency and lower voltage which may help reducing the UE power consumption. The impact on power consumption of relaxed UE processing time depends on implementation and traffic characteristics. […] 7.5.4 Analysis of coexistence with legacy UEs In scenarios where RedCap UEs coexist with legacy UEs, relaxed UE processing time capability for RedCap UEs may increase the complexity for the scheduling. The relaxed UE processing time capability may cause potential coexistence issues with legacy UEs during initial access if early identification of RedCap UEs prior to Msg2 scheduling is not supported or conservative scheduling is not possible. If gNB schedules all UEs according to relaxed timing relationships for RedCap UEs, legacy UEs may experience an increase in control plane latency. 7.5.5 Analysis of specification impacts A new UE processing time capability needs to be defined if relaxed UE processing time is introduced. New values of N1 and N2, as well as how the PDSCH processing time and PUSCH preparation time are determined by N1 and N2, need to be defined. Depending on the degree of relaxation of the N1 and N2 values, specification details on scheduling timing related to the default TDRA tables and HARQ-ACK timing range may also need to be updated. 7.6 Relaxed maximum number of MIMO layers […] 7.6.3 Analysis of performance impacts […] Since the email discussion is required to wrap up very soon, companies are encouraged to be flexible and accept the TP above as a whole. If there is an objection against some parts of the TP, companies are requested to propose a way forward that is more likely to be acceptable to the whole group in light of comments already received in FLS7 (R1-2009795). Proposal 1: Adopt the TP in section 2 of this document as baseline text for TR 38.875. Company Y/N Comments or suggested revisions DOCOMO Y vivo N The following parts are NOT acceptable. 7.2.3 Analysis of performance impacts Power consumption: The instantenous power consumption in the RF and the baseband modules of the UE is expected to be reduced due to the use of fewer RF chains and the reduction in the complexity of multi-antenna processing. Depending on the traffic characteristics, the average power consumption of the UE can increase or decrease. [Comment]: Evaluataion results in R1-2009212 has shown that reduced Rx has clear power saving benefit for various traffic models that agreed for RedCap. No other results have been provided to justfy the potential power consumption increase. [Possible wayforward] Alt 1: To keep the first sentence only which is always true from the power model. Alt 2: to delete the whole section about power consumption 7.3.3 Analysis of performance impacts Power consumption: UE bandwidth reduction reduces the instantaneous power consumption of the RF and baseband modules during transmission and reception. However, depending on the traffic characteristics (e.g. due to prolonged continuous downlink and uplink transmission), the average power consumption of the UE can increase or decrease. [Comment]: There has been no evaluation results submitted. [Possible wayforward] Alt 1: To keep the first sentence only which is always true from the power model. Alt 2: to delete the whole section about power consumption 7.6.3 Analysis of performance impacts […] Power consumption: The reduced number of MIMO layers can result in lower instantaneous power consumption due to the reduced peak data rate and reduced complexity in processing a smaller maximum transport block size. Depending on the traffic characteristics, the average power consumption of the UE may increase or decrease. [Comment]: Evaluataion results in R1-2009212 has shown that reduced MIMO layer (as a natural consequence from reduced number of Rx) has clear power saving benefit for various traffic models that agreed for RedCap. No other results have been provided to justfy the potential power consumption increase. [Possible wayforward] Alt 1: To keep the first sentence only which is always true from the power model. Alt 2: To delete the whole section about power consumption Excep the above three sections, we are fine with other parts of the TP. ZTE In Section 7.2.4, the first part has described the coexistence impact for broadcast channels. To avoid confusion, the decriptions with respect to broadcast channels in the second part should be deleted. So we propose to modify the second part as following: The need to use higher PDCCH aggregation levels for RedCap UEs may also increase the PDCCH blocking probability for legacy UEs if they share the same CORESET. Huawei, HiSi Y with suggestons Thanks for FL efforts. We are ok for most of the above FL’s handling except for below (which should be minor but still with accurace): On 7.2.4 Our previous comment is to change the below back, i.e. from ‘will’ to ‘may’ as it depends on what is the RedCap UEs capability v.s. legacy UEs (if no difference, then no need of different handling). In general, RedCap UEs with reduced number of Rx branches can coexist with legacy UEs. However, the presence of RedCap UEs with reduced number of Rx branches may impact the performance for legacy UEs if some broadcast channels are used for both legacy UEs and RedCap UEs. This is because, if there is no early indication of RedCap UE, both legacy UEs and RedCap UEs will be treated the same by the network, which may lead to conservative treatment of all UEs. Also there has no consensus for the need of higher AL. The potential coverage loss for PDCCH can be compensated by other techniques or not specifically treated if the loss is not significant. We suggest: Furthermore, due to the reduced downlink spectral efficiency, more resources may be needed for broadcast channels such as broadcast PDCCH. As one candidate if using higher PDCCH aggregation levels for RedCap UEs it may also increase the PDCCH blocking probability for legacy UEs if they share the same CORESET. On 7.4.4 We are ok to either keep the below or remove that if there is consensus, but we also suggest something as way forward (if Sony and Intel/others could be Ok). HD-FDD operation would impact coexistence with URLLC services when the Redcap UE is transmitting in the uplink and hence not able to monitor the downlink pre-emption indicator or uplink cancellation indicator. Some comments from other companies: - “This issue exists for all TDD deployments and the related features being alluded to are not even supported by most eMBB UEs. There is no need to bring this for RedCap UEs. We do not think UL cancelation is something RedCap UEs should be expected to support when it is challenging even for non-RedCap UEs” Our view: In order for RedCap UEs to support IWSN we think the coexisitence scenario of RedCap in URLLC with legacy UEs can happen. However, the pre-emption operation may mostly be used for the case of eMBB coexisiting with URLLC. If the RedCap UEs are used for a local URLLC network, the issue of pre-emption indication monitoring may be mitigated. Also, UL cancellation for TDD is specified in NR thus it is true that for TDD it is not new. However, using HD-FDD in FDD would introduce the need of handling of such cases, as reflected in the potential spec impact (or needs to be avoided by network scheduling restriction). Thus, we suggest: HD-FDD operation may impact coexistence with URLLC services if the downlink pre-emption indicator and/or uplink cancellation indicator is configured, depending on the deployment scenario, or the impact may be mitigated by network scheduling restriction. CMCC Y CATT Y We are fine with the current version. Regarding to Section 7.2.4, We think there is no need to modify it. The 1st paragraph is to tackle coexistence issue by network implementation/scheduling, while the 2nd paragraph is about the performance impact. Higher AL has been widely discussed in 8.6.3 (even new higher ALs are captured) and we think it is fine to mention it here. Samsung For the power saving description in 7.2.3, 7.3.3 and 7.6.3 we propose the following changes. Vivo’s two proposals are also fine with us. 7.2.3 Power consumption: The instantenous power consumption in the RF and the baseband modules of the UE is expected to be reduced due to the use of fewer RF chains and the reduction in the complexity of multi-antenna processing. However, DL receiving time may be longer for large TB due to reduced spectal efficiency. 7.3.3 UE bandwidth reduction reduces the instantaneous power consumption of the RF and baseband modules during transmission and reception. =>We suggest to delete the last sentence. Based on the analysis, there is no peak data rate impact, there is no spectral efficiency impact. It is hard for us to accept the increase of UE power consumption. 7.6.3 Power consumption: The reduced number of MIMO layers can result in lower instantaneous power consumption due to the reduced peak data rate and reduced complexity in processing a smaller maximum transport block size. => For MIMO layer reduction, it is unclear on the power consumtion. We are fine to say ”the power consumption impact is unclear.” 7.2.5 =?we sugges to make it clear as Additionally, to address the performance and coexistence impacts identified in subcluses 7.2.3 and 7.2.4, specification work in other working groups than RAN4 may be needed. 7.4.3 =?we don’t agree with new statement. If so, TDD cannot meet the peak data rate requirement. We suggest to change is back to orginal wording Data rate: There is minor impact from HD-FDD operation on instantaneous data rates for uplink or downlink, but HD-FDD reduces user throughput compared to FD-FDD, especially in case of simultaneous downlink and uplik traffic. 7.4.4 =?We are fine with FL’s proposal. But we don’t agree to bring deleted sentence on URLLC back. LG Y We are also fine with vivo’s proposals for 7.2.3, 7.3.3, and 7.6.3. The suggestion from Samsung on the HD-FDD data rate in 7.4.3 seems to make sense to us. So, we support it. Nokia, NSB Mostly Y We are supportive of Samsung’s proposal on HD-FDD data rate in 7.4.3 to revert back to the original text. On 7.4.4, we support FL’s proposal to delete the sentence. We also support FL’s proposals on power consumption in 7.2.3 and 7.6.3. SONY Y with suggestions We are basically OK with the FL proposed text. On the comments from vivo (7.2.3 / 7.3.3 / 7.6.3): - Our understanding of the text proposal is that it is a general statement and that it is not just talking about “power saving benefit for various traffic models that agreed for RedCap” - we would be OK with either Alt1 or Alt2 for the sake of progress. On the ZTE comment (7.2.4) : we tend to agree that some text can be deleted. It seems like the same / similar point is being made twice in the current FL text: the original FL text of “Furthermore, due to the reduced downlink spectral efficiency, more resources may be needed for broadcast channels such as broadcast PDCCH” seems to make the same point as “However, the presence of RedCap UEs with reduced number of Rx branches may impact the performance for legacy UEs if some broadcast channels are used for both legacy UEs and RedCap UEs” On the Huawei comments: - (7.2.4) OK to change “will” to “may”. We don’t see a significant change in meaning with such an update. - (7.2.4) We are OK with the FL text on higher AL in 7.2.4. We don’t really understand the structure of the text propsed by Huawei. Maybe something like this would be OK: “Furthermore, due to the reduced downlink spectral efficiency, more resources may be needed for broadcast channels such as broadcast PDCCH. If higher PDCCH aggregation levels are used for RedCap UEs, the PDCCH blocking probability for legacy UEs may be increased if they share the same CORESET.”. We would be open to other suggestions, but think that the text proposed by Huawei would benefit from updating. (7.4.4) We think the proposed text on URLLC coexistence is good and support the updated text. It is a good point that IWSN devices are likely to be used in a URLLC environment (there might also be eMBB-type devices on the network too: video monitoring etc) MediaTek Y with modifications We support the FL proposal on power consumption in 7.2.3 and 7.6.3. We don’t agree with Vivo’s proposal in this regard (i.e. Alt 1). We support Samsung’s proposal on HD-FDD (i.e. reverting back to the original text). Also, we don’t agree to bring back the deleted sentence on URLLC. Regarding the comment about coexistence of RedCap and URLLC UEs in IWSN use-case, we don’t agree that the HD-FDD will be the issue. UL inter-UE cancelation is defined with Cap#2 capability (hence UL-CI is not defined for FR2), and it is not expected that a RedCap UE to support cancelation with Cap#2. So, regardless if the UE supports FD-FDD or HD-FDD, it is not expected that RedCap UE will support UL inter-UE cancelation. It surprising to see a company that support reduced N1/N2 is interested in UL pre-emption cancelation. FUTUREWEI Y We are still not OK to only have the first sentence as suggested by Vivo for 7.2.3, prefer the FL but can accept Samsung’s suggestion as it shows at least some balance. The power model will show less power for reduced RX and more power from additional slots, which could come from from reduced data rate or from performance compensation if the TB is too big to use a lower MCS and transmit in a single slot. Qualcomm Thanks FL for the updated proposals. * For TPs 7.2.3, 7.3.3 and 7.6.3, we agree with the comments of Vivo. * For TP 7.3.4, we do NOT agree to include the second paragraph. This is because congestion is an upper layer issue, which should be discussed in RAN2. Actually, the presence of a large number of RedCap UEs does not necessarily mean higher access load, because individual RedCap UE tends to have much lower access rate than eMBB UEs. If there exists a temporarily high access load, network can apply access barring or access control to ensure RACH performance of eMBB is not impacted. In addition, configuring separate initial BWP for RedCap UE has spec impacts on MIB/SIB1 design, which deviates from the major motivation of supporting 20 MHz (100 MHz) UE BW in FR1 (FR2) for initial access. Therefore, we suggest to remove the following paragraph from TP 7.3.4: If RedCap and eMBB UEs share the same initial BWP in downlink and uplink for initial access procedure, and the number of RedCap UEs in the network is large, there may be impact to eMBB UE performance in initial BWP due to congestion and scheduling/configuration restriction (e.g. for RACH occasions). * For TP 7.4.3, we agree with the suggestion of Samsung. * For TPs 7.4.4 and 7.4.5, we are ok with the FL8 proposals. However, we do not agree to bring back the co-existence issue with URLLC. * For TPs 7.5.4 and 7.5.5, we prefer the previous version of the FL proposal, which is more clear than FL8 version. Intel On the observations on power consumption impact from # of Rx branches, # of MIMO layers, and reduced BW, we share similar views as Vivo and Samsung, and can accept Samsung’s versions as they state precisely what we can state based on anylses and discussions so far. On the observation on data rates from HD-FDD, we are also supportive of the version from Samsung. Lastly, we cannot accept bringing back any URLLC considerations. UL cancelation related features are not essential for coexistence between traffic flows with different priorities; they can be useful tools to improve cell spectral efficiency when such features can be reasonably implemented by UEs. In this regard, RedCap UEs should be accommodated without having to support such optimizations; e.g., via proper dimensioning and reservation of resources between RedCap and other use cases, including URLLC. For the rest, we are fine with FL8 proposals. Sierra Wireless Mostly Y We support Samsung’s proposal on HD-FDD – reverting back to the original text. NEC Y We are fine with Huawei’s first proposal to change “will” to “may”. In 7.3.3, “However” before “depending on …” may be deleted. No strong opinion, but in 7.5.3 if “N1/N2” may be read N1 over N2, it would be safer to change to “N1, N2”. Ericsson Y Huawei, HiSi-response To CATT/Sony on 7.2.4: The point of comments is to avoid the use of “the need” - no consensus has been made for such need. Thus, we are Ok with Sony suggested modification. To Samsung on the data rate of HD-FDD: You are correct that TDD will have the the similar issue, which has already been slightly captured in 7.3.3. It is well known that TDD would have lower peak data rate than FDD now the problem is the introduction of HD-FDD to FDD also causes the issue which does not previously exist for FD-FDD. Perhaps we could clarify that TDD has the same issue for simulatenous UL and DL peak rate? To MediaTek on HD-FDD coexisitence with URLLC: You are kindly reminded that we also indicate fine to remove that if there is a consensus. The comments are more about how to capture potential issue and suggest a way forward. To Qualcomm on the doubled N1, N2: The timing relationship and feedback mentioning msg2 and msg3 is already functionally included in the first section and last sentence of 7.5.5. We don’t need to mention all PxSCH. To NEC: Thanks. Ok with your suggestion for N1, N2. No strong preference as long as a consensus. FL The TP has been updated based on received comments. For a couple of paragraphs on the impact on power consumption in 7.3.3 and 7.6.3, no consensus seems to be possible to reach in the limited time we have left in this email discussion, and therefore the paragraphs have been deleted. For the paragraph on the impact on data rates from HD-FDD in 7.4.3, the text has been updated to strike a balance between different views (expressed above in in FLS7). If the proposed formulation is not acceptable, probably it will not be possible to reach consensus in the limited time left, meaning that the paragraph will probably have to be removed altogether, which seems a bit unfortunate. Since the email discussion is required to wrap up very soon, companies are encouraged to be very flexible, avoid repeating earlier discussions and try to accept the TP above as a whole as is. If there is an objection against some parts of the TP, companies are requested to propose a way forward that is highly likely to be acceptable to the whole group without further discussion in the light of the comments already received above and in FLS7 (R1-2009795). FL2: Proposal 1a: Adopt the TP in section 2 of this document as baseline text for TR 38.875. NEC Y vivo We can accept the current TP for sake of progress DOCOMO Y Intel On the observations on power consumption for # of MIMO layers and UE BW, instead of removing them altogether, we thought we could follow similar approach as for # of Rx branches, e.g., something like “However, downlink reception time may be longer for large payloads due to reduced spectal efficiency” for # of MIMO layers, and “However, downlink reception time may be longer for large payloads due to reduced peak throughput” for UE BW as the “second sentences”. However, we understand the time constraints, and can live with the latest FL proposal as well. CATT Y 3 TP for UE complexity reduction for relaxed CSI computation time RAN1#103e has agreed the following TP as baseline text for TR 38.875. 7.5 Relaxed UE processing time 7.5.1 Description of feature In the RedCap study item, relaxed UE processing time is considered in terms of more relaxed N1/N2 values compared to those of UE processing time capability 1. In the study, for the purpose of evaluation, the relaxed UE processing time in terms of N1/N2 are assumed to be doubled compared to those of capability 1, i.e., * N1 = 16, 20, 34, and 40 symbols for 15, 30, 60, and 120 kHz SCS (assuming only front-loaded DMRS) * N2 = 20, 24, 46, and 72 symbols for 15, 30, 60, and 120 kHz SCS In the study, for the purpose of evaluation, relaxed CSI computation time was also considered, assuming doubled Z/Z' compared to the values defined in TS 38.214 clause 5.4. TR clause 7.5.2 presents cost estimates for relaxed UE processing time in terms of N1/N2 but not for relaxed CSI computation time. Cost estimates for relaxed CSI computation time have been provided by Huawei/HiSilicon in RedCapCost-HWHiSi for CSI computation time relaxation.xlsx. Based on this input, the following TP can be considered. 7.5.2 Analysis of UE complexity reduction Relaxed UE processing time in terms of N1 and N2: The estimated cost for a device with relaxed UE processing time in terms of N1 and N2 (see evaluation methodology described in clause 6.1) and averaged over the results provided by the sourcing companies, is summarized in Table 7.5.2-1. As can be seen in the last row for the total cost, the average estimated cost reduction is ~6% for FR1 FDD, ~6% for FR1 TDD, and ~6% for FR2 TDD. Relaxed UE processing time in terms of N1 and N2 potentially reduces UE complexity by allowing a longer time for the processing of PDCCH and PDSCH and preparing PUSCH and PUCCH. By comparing Table 7.5.2-1 with the reference NR device cost breakdown in clause 6.1, it can be observed that the cost of the following functional blocks can be reduced: * Baseband: Receiver processing block * Baseband: LDPC decoding * Baseband: DL control processing & decoder * Baseband: UL processing block Whether the relaxed UE processing time in terms of N1 and N2 may reduce the cost/complexity in the ‘DL control processing & decoder’ block depends on the UE implementation. Furthermore, all sourcing companies indicated that these cost savings do not accumulate across supported bands. Table 7.5.2-1: Estimated relative device cost for relaxed UE processing time in terms of N1 and N2 Relaxed processing time (doubled N1 and N2) FR1 FDD FR1 TDD FR2 TDD RF: Antenna array - - 33.0% RF: Power amplifier 25.0% 25.0% 18.0% RF: Filters 10.0% 14.7% 8.0% RF: Transceiver (including LNAs, mixer, and local oscillator) 45.0% 54.3% 41.0% RF: Duplexer / Switch 20.0% 6.0% 0.0% RF: Total relative cost 100.0% 100.0% 100.0% BB: ADC / DAC 10.0% 9.0% 4.0% BB: FFT/IFFT 4.0% 4.0% 4.0% BB: Post-FFT data buffering 10.0% 10.0% 11.0% BB: Receiver processing block 20.3% 24.6% 19.5% BB: LDPC decoding 6.6% 5.9% 5.9% BB: HARQ buffer 14.0% 12.0% 11.0% BB: DL control processing & decoder 4.1% 3.3% 4.0% BB: Synchronization / cell search block 9.0% 9.0% 7.0% BB: UL processing block 3.7% 3.6% 5.0% BB: MIMO specific processing blocks 8.8% 8.8% 17.5% BB: Total relative cost 90.5% 90.1% 88.9% RF+BB: Total relative cost 94.3% 94.1% 94.4% Relaxed UE processing time in terms CSI computation time: One source provided estimates of the cost for a device with relaxed UE processing time in terms of CSI computation time (see evaluation methodology described in clause 6.1) as summarized in Table 7.5.2-2. As can be seen in the last row for the total cost, the estimated cost reduction is ~5% for FR1 FDD, ~4.5% for FR1 TDD, and ~6% for FR2 TDD. The cost reduction gain is estimated without combination with relaxation in terms of N1 and N2. Table 7.5.2-2: Estimated relative device cost for relaxed UE processing time in terms of CSI computation time Relaxed processing time (doubled Z and Z’) FR1 FDD FR1 TDD FR2 TDD RF: Antenna array - - 33.0% RF: Power amplifier 25.0% 25.0% 18.0% RF: Filters 10.0% 15.0% 8.0% RF: Transceiver (including LNAs, mixer, and local oscillator) 45.0% 55.0% 40.2% RF: Duplexer / Switch 20.0% 5.0% 0.0% RF: Total relative cost 100.0% 100.0% 99.2% BB: ADC / DAC 10.0% 9.0% 4.0% BB: FFT/IFFT 4.0% 4.0% 4.0% BB: Post-FFT data buffering 10.0% 10.0% 11.0% BB: Receiver processing block 24.0% 29.0% 24.0% BB: LDPC decoding 10.0% 9.0% 9.0% BB: HARQ buffer 14.0% 12.0% 11.0% BB: DL control processing & decoder 2.5% 2.0% 2.5% BB: Synchronization / cell search block 9.0% 9.0% 7.0% BB: UL processing block 4.0% 4.0% 5.6% BB: MIMO specific processing blocks 4.5% 4.5% 9.0% BB: Total relative cost 92.0% 92.5% 87.1% RF+BB: Total relative cost 95.2% 95.5% 93.6% Proposal 2: Adopt the TP in section 3 of this document as baseline text for TR 38.875. Company Y/N Comments or suggested revisions DOCOMO Y vivo Is it the correct understanding that Table 7.5.2-1 intends to capture the cost reduction analysis for the case with only N1/N2 relaxation (no CSI timeline relaxation), while Table 7.5.2-2 intends to capture the cost reduction analysis for the case with only CSI timeline relaxation (no N1/N2 relaxation)? ZTE We show similar concern as vivo. In addition, considering that the simulation result of CSI computation time is only from one source, we propose to delete ‘average’: One source provided estimates of the cost for a device with relaxed UE processing time in terms of CSI computation time (see evaluation methodology described in clause 6.1) as summarized in Table 7.5.2-2. As can be seen in the last row for the total cost, the estimated cost reduction is ~5% for FR1 FDD, ~4.5% for FR1 TDD, and ~6% for FR2 TDD. Huawei, HiSi Y And confirm vivo understanding. Ok with ZTE suggestion. CMCC Y CATT Y We suggest the following modification: One source provided estimates of the cost for a device with relaxed UE processing time in terms of CSI computation time (see evaluation methodology described in clause 6.1) as summarized in Table 7.5.2-2. As can be seen in the last row for the total cost, the average estimated cost reduction is ~5% for FR1 FDD, ~4.5% for FR1 TDD, and ~6% for FR2 TDD. The cost reduction gain is estimated without combination of any other features, e.g. N1/N2 relaxation. Samsung Agreed with the change from Vivo and ZTE, CATT LG Y We also think the modifications suggested by ZTE and CATT are needed. Nokia, NSB Y We also think the the modifications from ZTE & CATT are OK. SONY Y Modification from CATT looks good. FUTUREWEI Y Also ok with ZTE/CATT clarifications. Qualcomm Agree with the comments of ZTE and CATT. It is also necessary to clarify the use cases considered for CSI computation time relaxation, i.e. stationary/low mobility. Intel Y Fine with the latest version from CATT. NEC Y Fine with CATT’s modification. Ericsson Y We are also fine with the suggestions from ZTE and CATT. Huawei, HiSi-response No need for CATT suggestion of last sentence. This whole section is to capture cost estimate of individual technique. FL The TP has been updated based on received comments. Since the use cases have not been clarified in the corresponding TR clauses for other UE complexity reduction techniques, it does not seem necessary to do it in this TR clause either. Since the email discussion is required to wrap up very soon, companies are encouraged to be very flexible and try to accept the TP above as a whole as is. If there is an objection against some parts of the TP, companies are requested to propose a way forward that is highly likely to be acceptable to the whole group without further discussion. FL2: Proposal 2a: Adopt the TP in section 3 of this document as baseline text for TR 38.875. NEC Y vivo Y DOCOMO Y Intel Y CATT Y