[{"name":"R5-210014","title":"LS on nominal channel spacing calculation for two carriers at band n41 with 40MHz and 80MHz channel bandwidths","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN4 recognized that the nominal channel spacing for two carriers in band n41 with 40MHz and 80MHz channel bandwidths in TS 38.508 is not aligned with the nominal channel spacing definition in TS 38.101-1. RAN4 would like to clarify whetherthe specific parameter used in the calculation was misunderstood by RAN5 Following table compares parameters for the nominal channel space calculation. \nAccording to the calculation in the table, RAN4 would like to ask RAN5 following questions:\nQuestion 1: Is that correct understanding thatthe nominal channel spacing for two carriers in band n41 with 40MHz and 80MHz channel bandwidths calculated as 59.94MHz in TS 38.508 is because of incorrectly selected \u00b5=1 for GBchannel(i) ? \nActions: To: 3GPP TSG RAN WG1.\nACTION: RAN4 kindly asks RAN5 feedback on the above questions.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":140,"status":"noted","reservation_date":"2021-01-11 17:07:52","uploaded":"2021-01-19 06:53:45","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"NR_newRAT-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2016779","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-210014.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-210015","title":"LS on OTA LTE UE TRP and TRS Requirements","source":"MSG TFES","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"MSG TFES responsible for developing European Norm (ENs) intended to become Harmonized Standards under RED Directive, would like to inform the above standardization and certification bodies about the finalization of the definition of the OTA LTE UE requirements in MSG TFES LTE ad-hoc meeting (#34) on 7July 2020.\nAfter an independent test campaign and an associated process managed by ETSI Secretariat acting as third party ensuring the anonymity of the devices and the labs, MSG TFES group discussed, in several ad-hoc OTA UE Antenna parameters meetings, the UEs measurement results and agreed on the following:\nThe TRP and TRS BHH (Beside Head and Hand) are respectively defined as an average on the TRP Beside Head Hand Left and Beside Head Hand Right (BHHL\/BHHR) and TRS Beside Head Hand Left and Beside Head Hand Right (BHHL\/BHHR).\nThe TRP and TRS BHH minimum requirements are applicable for devices wider than or equal to  56 mm and narrower than or equal to 72 mm.\nMTSG TFES will capture these agreed OTA requirements on EN 301 908-13 v13.2.1 [1], in addition to a dedicated TR 103 803 v1.1.1 [2] that records the details of the work, which is expected to be published in the first quarter of 2021.\nThis EN 301 908-13 v13.2.1 Harmonised Standard, when approved, published and cited in the Official Journal of the European Union (OJEU), will be a route to prove the compliance with the Radio Equipment Directive [3] requirements.\nActions: MSG TFES is respectfully asking all the standardization and certification bodies to take into consideration the above LTE UE TRP TRS requirements for the related bands in their work.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":150,"status":"noted","reservation_date":"2021-01-11 17:07:52","uploaded":"2021-01-19 06:53:45","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"TFES(20)067025r5","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-210015.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-210016","title":"Test methods for over-the-air TRP field measurements of unwanted emissions from IMT radio equipment utilizing active antennas","source":"ITU-R WP 1C","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Working Party (WP) 1C would like to thank TSG RAN WG4 for the information in their liaison statement (Document 1C\/4, equally as 5D\/135). 3GPP indicated there are no plans to define test modes for OTA (over-the-air) TRP (total radiated power) field measurements. Furthermore, it was said that dedicated test modes would interrupt normal operation, consume resources, and may even interfere with the network if they consist of emissions that do not occur in normal operation.  \nNoting the concerns regarding dedicated test modes, WP 1C is of the opinion that while determination of the in-band, TRP is possible through measurement of the Synchronization Signal Block (SSB) during normal operation, the assessment of unwanted emissions is only possible during a time when the station transmits at full power and bandwidth. Otherwise, neither Out of Band (OoB) nor spurious emission levels defined in the specifications can be measured.\nAs an alternative to a dedicated test mode, WP 1C kindly requests 3GPP to consider defining a test signal to enable field measurement of the unwanted emission.  This test signal could be as short as one symbol and transmitted only at times when the scheduler does not need the resource for user traffic. However, it must be retransmitted in a reasonable interval (e. g. every few seconds). This should allow the station to maintain normal operation during the measurement, and degradation of the station\u2019s performance should be negligible. Further, the test signal could be transmitted by a normal traffic or broadcast beam with its nominal gain. It should therefore not interfere with the network because it occurs as part of normal operation.\nWorking Party 1C would kindly ask 3GPP to consider a test signal in the light of the above-mentioned requirements in order to measure and verify unwanted emission levels defined in 3GPP specifications by means of field measurements of IMT radio equipment utilizing active antennas.\nThe next meeting of WP 1C is planned for 25 May to 2 June 2021.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":160,"status":"noted","reservation_date":"2021-01-11 17:07:52","uploaded":"2021-01-19 06:53:45","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"ITU-R WP 1C LS 2 3GPP cc 1A,5A,5D-R19-WP1C-201124-TD-0014!!MSW-E (edited)","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-210016.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-210017","title":"LS on Use of Inclusive Language in 3GPP","source":"TSG SA","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"TSG SA# 90-e has endorsed the proposal (see SP-201042) to use more inclusive and neutral language in all 3GPP specifications.\nTSG SA#90-e has also approved a CR that introduces an Annex into the 3GPP TR 21.801 \"Specification drafting rules\" that lists all non-inclusive terminology to be replaced. Please see attached SP-201142.\nGeneral Guidance:\nBesides the detailed guidance in the Actions below, the following more general guidelines should be followed.\nIn general 3GPP should strive for more inclusive and neutral language, even if the related terminology is not explicitly listed below. Some examples can be found here: https:\/\/en.wikipedia.org\/wiki\/Gender-neutral_language.\nIf delegates feel offended by certain additional terminology in 3GPP specs or by other means of how 3GPP conducts its work, then the delegate should contact the chair and\/or MCC of the group. The leadership together with MCC will discuss such requests and will also check with other stakeholders in the industry, how to progress them. Besides that, there will be no formal process on how to put additional terms on the list.\n3GPP delegates and groups shall avoid use of language or pronunciation of 3GPP defined abbreviations in a way that may cause offense in all standards, verbal and written communications.  For abbreviations where such mispronunciation has become common place in wider industry usage, it may be necessary for 3GPP to consider replacing such abbreviations with alternatives that cannot be used in such a way as to cause offense. For example, the abbreviation GPSI should be pronounced in single letters, i.e. G-P-S-I.\nActions: To\tSA WG1, SA WG2, SA WG3, SA WG4, SA WG5, SA WG6, RAN WG1, RAN WG2, RAN WG3, RAN WG4, RAN WG5, CT WG1, CT WG3, CT WG4, CT WG6\nPlease take the above decision into account and take the following actions: \n1)\tStrictly avoid the use of non-inclusive terms in all-new 3GPP documents (including TS, TR, SID, WID, LS).\n2)\tReplace the non-inclusive terms used in all relevant 3GPP specifications per the updated 3GPP drafting rules.\n3)\tWG Chairs are requested to follow the following process for non-inclusive term replacement in the existing 3GPP specifications:\na.\tThe changes shall be applied to 3GPP Technical Specifications and 3GPP Technical Reports.\nb.\tThe changes shall in a first step be applied from Rel-17 onwards.\nc.\tThe changes shall only be done if they are of a purely editorial nature and do not lead to any backward incompatibility. These CRs should not include any further editorial changes.\nd.\tWG chairs shall request rapporteurs and MCC to check their specs as to whether the non-inclusive terminology is used therein.\ne.\tThe MCC of a WG  together with the specification rapporteurs should come up with related CRs to the affected specifications. The CRs should be issued under TEI17 and the CR title should start with \u201cInclusive language review\u201d. If terms are used in multiple specifications (possibly in different working groups), then the related rapporteurs and MCCs should coordinate to align the replacement terms.\n4)\tRelated CRs against already existing Rel-17 specifications should be submitted for approval at plenary (after WG agreement) in separate CR packs at the March 2021 TSGs meetings, except where coordination with external organizations is required.\n5)\tRel-17 specifications which are created after March 2021 should be updated per the updated 3GPP drafting rules at their creation in separate CR packs.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":170,"status":"noted","reservation_date":"2021-01-11 17:07:52","uploaded":"2021-01-19 06:53:45","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"SP-201143","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-210017.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-210018","title":"NGMN-GTI 5G Smart Devices Supporting Network Slicing","source":"NGMN Next Generation Mobile Networks Alliance Project 5G Smart Devices Supporting Network Slicing","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"NGMN is pleased to inform recipients of this liaison about the joint publication of NGMN and GTI on 5G smart devices supporting network slicing requirements, which highlights the importance of supporting network slicing defined by 3GPP and the requirements for 5G smart devices supporting network slicing. \nIn the 5G era, there will be a large number of different kinds of devices connected to 5G networks. These devices can belong to ordinary individual customers as well as different industrial fields, and their requirements can be quite different in network mobility, security, delay, reliability and even billing methods. If the traditional network constructions were adopted to meet the different requirements of large homogeneous network, it would require huge investments by operators and users still cannot get high-quality of services to meet their specific needs. In this regard, 5G network slicing technology is key to meet diversified services requirements.\nWith the introduction of network slicing technology, operators will be able to provide network capabilities with different functional characteristics, which will provide \"exclusive\" network for users with different KPI requirements to ensure a high-quality of service and meet differentiated scenario requirements. Users can enjoy more amazing application products, which will further stimulate the development of new industry applications as well as personal applications. Finally, it achieves the goal of improving the efficiency of network resource utilization, optimizing the network construction investment of operators, and building a flexible and agile 5G network.\nTo accelerate the realization of the above-mentioned, the NGMN Alliance and GTI have jointly published the White Paper \u201c5G Smart Devices Supporting Network Slicing\u201d. The document focuses on the service capability of network slicing in 5G devices, key technologies and the end-to-end procedure of 5G network slicing, challenges of the implementation for 5G network slicing in devices, reference solution of network slicing in 5G devices and test requirements of network slicing in 5G devices. Please refer to the attached White Paper for details.\nFrom NGMN\u2019s point of view, user experience is critical for commercial success, and testing is the key guarantee. To enable testing the 5G smart devices supporting network slicing at an \u2018end to end\u2019 level requires the inclusion of application layer functions at the device side, as the slice selection and traffic routing procedures use application related selection criteria and mappings that are configured within the device. This application layer and device implementation specific functionality, e.g. UE policies for URSP, matching UE application to URSP, requesting suitable network slices, is currently outside of the scope being developed by 3GPP RAN5. Suitable test interfaces and test\/verification procedures to support the implementation and inter-operability \/ consistency of network slicing for smart devices are required.\nRequired Actions\nNGMN appreciates 3GPP RAN5 taking this into consideration in the conformance test development planning. It will be highly appreciated if 3GPP RAN5 can define the test methods and test cases for application layer and device implementation specific functionality for 5G smart devices supporting network slicing.\nNGMN asks GSMA to consider the \u201c5G Smart Devices Supporting Network Slicing White Paper\u201d when setting up new Work Items on Network Slicing.\nNGMN asks GCF and PTCRB to take our results into consideration when planning new validation\/certification for 5G devices.\nAny feedback on the outcome of RAN5 test development planning for 5G smart devices supporting network slicing is welcome. Please contact us in case of any immediate question.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":180,"status":"noted","reservation_date":"2021-01-11 17:07:52","uploaded":"2021-01-20 18:02:40","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-210018.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-210019","title":"LS to 3GPP RAN5 on LTE frequency band grouping","source":"GCF CAG","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"Devices are now supporting an increased amount of RAT, Frequency Bands and Features.\nA typical device my support LTE Bands 1, 2, 3, 4, 5, 7, 8, 12, 13, 17, 18, 19, 20, 25, 26, 28, 38, 39, 40, 41, 66 together with NR support of n1, n3, n7, n8, n28, n38, n40, n41, n66, n77, n78 (SA and NSA) with dual SCS support.\nIn addition, devices are supporting up to DL 7CA and UL CA. Multiple antenna configurations for 2DL MIMO and 4DL MIMO is often supported as well as various types of modulation such as UL 64QAM and DL 256QAM. \nAdditional time and expense is now being incurred to fulfil the current requirements and CAG feel that it is time to look at optimization of LTE testing.\nCAG have discussed LTE RF\/RRM test optimization for multi-LTE band handsets by exempting some overlapping test cases by forming groups of similar frequency bands. This proposal applies to non-CA test cases only. Precondition is that the RF path for all frequency bands in each of the groups must be identical.\nExamples: [..]\nThe band\u2019s associated NS signalling values need also to be considered. Example: For band Group 3 the bands FDD19, FDD20 and FDD26 have different NS values as specified in TS 36.101 Table 6.2.4-1 (FDD19: NS_08, FDD20: NS_10 and FDD26: NS_12, NS_13, NS_14 and NS_15). \nCAG members will conduct a case-by-case analysis for each band group and test case to judge if a test case can be \u2018skipped\u2019 for certain bands in the group but initial investigations are looking at series 6 and 7 and series 9 for LTE RF\/RRM in TS36.521-1 and TS36.521-3.\nActions: Please review the above information and inform GCF CAG if there are any concerns in this approach.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":190,"status":"noted","reservation_date":"2021-01-11 17:07:52","uploaded":"2021-02-08 11:31:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"CAG-21-003","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-210019.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-211277","title":"LS on inter-RAT cell reselection for mobility state estimation","source":"TSG WG RAN2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN2 has discussed whether the inter-RAT cell reselection should be counted for mobility state estimation. RAN2 agreed that TS 38.304 is not clear whether the UE is required to continue or reset counting for mobility estimation in case of inter-RAT cell reselection. Similar as for LTE RAN2 agreed to:\n\u2022\tLeave up to UE implementation on whether to count inter-RAT cell reselections for mobility state estimation from Rel-15 onwards.\nRAN2 understands that a RAN5 test case (clause 6.2.3.9 in TS 38.523-1) is related to this and conclude that how to handle this test case would be RAN5 decision.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":127700,"status":"noted","reservation_date":"2021-03-08 12:20:57","uploaded":"2021-03-08 12:21:19","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"NR_newRAT-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R2-2102311","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-211277.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-211278","title":"Reply LS on Rel-16 mandatory RRM requirements","source":"TSG WG RAN2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN2 would like to thank RAN4 for the LS in R2-2100060 (R4-2017803). After discussion, RAN2 would like to inform RAN4 of the following:\n-\tAny UE indicating support of Rel-16 AS (i.e. accessStratumRelease) shall also support the mandatory RRM requirements (e.g. multiple SCell activation, UE-specific CBW change and UL spatial relation switch as mentioned in R4-2017803). \n-\tNetwork is always aware of the UE AS release indicator (i.e. accessStratumRelease) since that is part of the UE capabilities.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":127800,"status":"noted","reservation_date":"2021-03-08 12:20:57","uploaded":"2021-03-08 12:21:19","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"NR_RRM_enh-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R2-2100060 (R4-2017803)","lsto":"","Cc":"","lsoriginalls":"R2-2102338","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-211278.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-211279","title":"LS to RAN5 on RRC processing time with segmentation","source":"TSG WG RAN2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN2 would like respectfully provide some information to RAN5 that RAN2 agreed to extend the RRC processing time for NR and LTE RRC messages with segmentation as below. \n1>\tNR RRC processing time requirement for the NR RRC messages with segmentation\n2>\tLTE RRC processing time requirement for the LTE RRC messages with segmentation\nIt\u2019s RAN2\u2019s understanding that some test cases defined in TS38.523 for checking the RRC processing delay (see Annex) are not appropriate for the case of RRC message with segmentation, and RAN5 spec may need to be updated.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":127900,"status":"noted","reservation_date":"2021-03-08 12:20:57","uploaded":"2021-03-08 12:21:19","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"NR_newRAT-Core"},{"winame":" TEI16"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R2-2102488","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-211279.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-211280","title":"Reply LS on reporting of SINR measurements for serving cell","source":"TSG WG RAN2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN2 would like to thank RAN5 for the LS on reporting of SINR measurements for serving cell [1]. RAN2 has discussed the different interpretations on including SINR result in serving cell reporting. RAN2 concluded the interpretation A from R5-206274 is correct understanding with the following agreement.\n\u2022\tUEs supporting SINR measurements can include SINR metrics for serving cell (per UE implementation) in the measurement report even when the SINR is not configured as a trigger quantity or reporting quantity in any of the measIDs.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":128000,"status":"noted","reservation_date":"2021-03-08 12:20:58","uploaded":"2021-03-08 12:21:19","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"NR_newRAT-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R5-206274(R2-2100063)","lsto":"","Cc":"","lsoriginalls":"R2-2102499","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-211280.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-211284","title":"LS on change of methodology for new LTE-CA REL-17 combinations","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"In RAN4#97 meeting, MSD test point specification methodology for LTE CA REL-17 was approved as attached R4-2016940. The following agreements are listed.\n\u2013\tAdopt NR\/EN-DC MSD test point specification methodology for new LTE CA combinations:\n\u2022\t2DL\/1UL MSD test points cover cases of REFSENS: \n\u2022\tExceptions due to harmonic issue,\n\u2022\tExceptions due to for two bands due to close proximity of UL to DL channel,\n\u2022\tExceptions due to cross band isolation issues of TDD and FDD bands,\n\u2022\tCA with SDL band,\n\u2022\t2DL\/2UL MSD test points cover cases of REFSENS:\n\u2022\tExceptions for intermodulation interference due to dual uplink operation, \n\u2022\tExceptions for intra-band CA,\n\u2022\t3DL\/2UL MSD test points cover cases of REFSENS:\n\u2022\tExceptions for intermodulation interference into third band due to dual uplink operation,\n\u2022\tNo additional MSD test point is needed for higher-order combinations.\nActions\nTo TSG RAN WG5: RAN4 asks RAN5 to take account the above RAN4 agreements in the future.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":128400,"status":"noted","reservation_date":"2021-03-08 12:21:00","uploaded":"2021-03-08 12:21:19","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"LTE_CA_R17_2BDL_1BUL"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2101818","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-211284.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-211285","title":"LS on Signalling scheme of Transparent TxD","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN4 has agreed to introduce a new per-band capability signaling in Rel-16 for FR1 UEs supporting transparent TxD.\nRAN4 would also like to ask RAN2 to enable release-independent support of this new capability from Rel-15 for PC2, if possible.\nActions: To RAN2: RAN4 asks RAN2 to define respective signalling in Rel-16 and discuss release independence to Rel-15.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":128500,"status":"noted","reservation_date":"2021-03-08 12:21:00","uploaded":"2021-03-08 12:21:19","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"TEI16"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2103360","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-211285.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-211286","title":"LS on Test Methodology for UE URLLC Ultra Low BLER CQI requirements","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN4 discussed the test methodology for UE verification of support of CQI Table 3 as a part of discussion for Rel-16 WI Physical layer enhancements for NR URLLC. RAN4 agreed that CQI Table 3 will be verified in scenarios with static propagation conditions. RAN4 concluded that the early pass\/fail test methodology can be used for CQI requirements with static propagation conditions to achieve feasible testing time. CQI requirements with static propagation conditions have the following minimum requirements:\na)\tThe reported CQI value according to the reference channel shall be in the range of \u00b11 of the reported median more than 90% of the time. \nb)\tIf the PDSCH BLER using the transport format indicated by median CQI is less than or equal to 10-5, then the BLER using the transport format indicated by the (median CQI+1) shall be greater than 10-5. If the PDSCH BLER using the transport format indicated by the median CQI is greater than 10-5, then the BLER using transport format indicated by (median CQI-1) shall be less than or equal to 10-5\nc)\tThe reported CQI value according to the reference channel shall be greater than or equal to 1\nEarly pass\/fail test methodology can be used for part b) in the following way:\n\u2022\tIf DUT early pass the test using the PDSCH transport format indicated by median CQI, then DUT should early fail the test using the PDSCH transport format indicated by (median CQI+1). If DUT early fail the test using the PDSCH transport format indicated by median CQI, then DUT should early pass the test using the PDSCH transport format indicated by (median CQI-1). \nAlso, RAN4 concluded that confidence level 99% can be considered to achieve feasible testing time for CQI requirements with static propagation conditions.\nActions: To RAN WG5: RAN4 asks RAN5 to take into account the respective agreements when defining the test methodology for URLLC CQI test cases.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":128600,"status":"noted","reservation_date":"2021-03-08 12:21:00","uploaded":"2021-03-08 12:21:19","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"NR_L1enh_URLLC-Perf"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2103897","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_90_Electronic\/Docs\/R5-211286.zip","group":"R5","meeting":"R5-90-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]