[{"name":"R5-197717","title":"Reply LS on propagation delay compensation for reference time information delivery","source":"TSG WG RAN1","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"Response to:\tR1-1907993 (R2-1908160) \nRelease:\tRelease 16\nWork Item:\tNR_IIOT-Core\nRAN1 would like to thank RAN2 for the LS on propagation delay compensation for reference time information. \nRAN1 discussed the following requests from RAN2:\nRAN1 discussed Q1, and would like to provide the response:\n\u2022\tTiming Advance based methods were used to obtain propagation delay compensation for the time synchronization accuracy analysis captured in Sec. 6.3.2.4. of TR 38.825. The evaluations assumed that the timing advance value is used by the gNB to align the reception timing of UEs\u2019 UL transmission with the DL timing at the gNB. \nRAN1 further discussed the issues raised in Q2, and would like to provide the response:\n\u2022\tRAN1 further discussed when the propagation delay needs to be compensated as the studies captured in TR 38.825 had been performed with and without propagation delay compensation. RAN1 continues discussing when and how to apply propagation delay compensation including TDD operation aspects.\n\u2022\tRAN1 discussed the need to define time synchronization accuracy requirements of the Uu interface (i.e. the maximum amount of uncertainty introduced when delivering a 5G system clock using RRC unicast or a SIB based method between gNB and UE as studied by RAN1 during the IIoT SI phase) and believes, that it is useful to define requirements and related UE test cases for the overall time synchronization accuracy of the Uu interface (and not just the propagation delay compensation). \nIt is the RAN1 understanding, that for such requirements and\/or the testing the existing NR physical layer specifications (incl. 38.215) cannot provide support for such requirements \/ testing. Moreover, the feasibility of defining related test cases for the UE overall is not clear to RAN1, which would need further clarification from RAN4 and RAN5. \nQuestion to RAN4 and RAN5: \nDoes RAN4\/RAN5 see it feasible to define performance requirements and related testing for time synchronization accuracy over Uu interface (i.e. between a gNB and a single UE)? Note: the time synchronization accuracy over Uu interface is on the order of hundreds of ns in order to achieve between sync master and device the time synchronization accuracy target of 1 \u00b5s.\n\u2022\tRAN1 discussed the need of Rel-16 enhancements in addition to propagation delay compensation to achieve a time synchronization error of less than 1\u00b5s as defined in TS 22.104. The achievable time synchronization accuracy over Uu interface in Sec. 6.3.2.4 of TR 38.825 is sufficient if following RAN2 analysis on the overall time synchronization accuracy from sync master to UE as captured in Sec. 6.3.5 of TR 38.825. As the evaluation results on timing synchronization accuracy of Sec. 6.3.2.4 of TR 38.825 can be achieved without additional Rel-16 enhancements in addition to the required propagation delay compensation support, RAN1 sees no need for additional enhancements in Rel-16. RAN1 may need to revisit the need of enhancements if the analysis \/ assumptions other than that of Uu interface deviate from those in Sec. 6.3.5 of TR 38.825 such that the clock synchronicity requirement cannot be satisfied.\n2. Actions: To RAN2: RAN1 respectfully asks RAN2 to take the above into account in the future work.  \nTo RAN4, RAN5: RAN1 respectfully asks RAN4 and RAN5 to answer the question on the feasibility of time synchronization accuracy requirements and related testing.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":77170,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-16 17:38:49","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"NR_IIOT-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R1-1907993 (R2-1908160)","lsto":"","Cc":"","lsoriginalls":"R1-1909906","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197717.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-197718","title":"LS on the testability of FR1 Tx diversity","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"Release:\tRel-15\nWork Item:\tNR_newRAT\nRAN4 would like to inform RAN5 about an ongoing discussion on introducing Tx diversity requirements in FR1 (see [1] & [2]). During the discussion, concerns have been raised about the testability of this feature, since UEs may utilize multiple antennas during its uplink transmission. Considering the usage of the Tx diversity scheme is up to the UE implementation, it may also be unknown which uplink transmit antennas a UE uses at a certain point in time.\nRAN4 respectfully asks RAN5 to identify potential issues with the testability of this feature, taking into account uplink transmission from multiple potentially unknown UE antenna connectors.\nPotential issues may include, but are not limited to:\n\u2022\tUL power measurements\n\u2022\tUL signal quality measurements\n\u2022\tUL channel detection (e.g. PRACH)\n\u2022\tImpact on Demod and RRM testing\n\u2022\tEtc.\n2. Actions: To RAN WG5 group: RAN4 respectfully asks RAN5 to take the above information into account and to inform RAN4 about potential testability issues with Tx diversity.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":77180,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-16 17:38:49","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"NR_newRAT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-1910344","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197718.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-197719","title":"Reply LS to RAN5 to update 38.101-4 with Link Adaptation requirements","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Response to:\tR5-195422\nRelease:\t16\nWork Item:\t5GS_NR_LTE-UEConTest\nRAN4 would like to thank RAN5 for the LS on updating 38.101-4 with Link Adaptation requirements for Rel-16. RAN4 has discussed the issue and concludes the following:\nQ1: To accept to be added as secondary responsibility WG in the proposed Study item for 5G NR Application Layer Data Throughput Performance (please refer attachment R5-194852)\nA1: RAN4 understanding is that it is up to RAN plenary to decide whether RAN4 should be added as secondary responsibility WG in the proposed Study item for 5G NR Application Layer Data Throughput Performance.\nQ2: That in order to proceed with the attached study item, to analyse the initial set of parameters identified in the appendix of this LS for use in link adaptation scenarios.\nA2: If RAN plenary adds RAN4 as secondary WG to this SI and requests RAN4 to study those set of parameters for the SI, RAN4 will further discuss the set of parameters for the study item and will use the initial set of parameters identified in the appendix of RAN5 LS as a starting point.\nQ3: To consider the possibility of defining physical layer throughput (link adaptation) requirements in 38.101-4 for the initial set of parameters identified in the appendix of this LS and\/or any other parameters, as deemed appropriate.\nA3: If RAN plenary adds RAN4 as secondary WG to this SI and agrees for RAN4 to study the physical layer throughput performance for TS38.101-4, RAN4 will study the feasibility of defining the physical layer throughput requirements with link adaptation in 38.101-4. \n2. Actions: To RAN5: RAN4 respectfully requests RAN5 to take the above information into consideration.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":77190,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-16 17:38:49","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_NR_LTE-UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R5-195422","lsto":"","Cc":"","lsoriginalls":"R4-1910562","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197719.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-197720","title":"LS on SS-RSRPB definition","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Release:\tRelease 15 and Release 16\nWork Item:\tFS_NR_MIMO_OTA_test\nRAN4 further discussed the NR ATF measurements on SS-RSRPB definition and reached the following additional agreements:\nThe following SS-RSRPB measurement definition is recommended to be revised in Rel-15 and Rel-16 as: [..]\n2. Actions: To: 3GPP TSG RAN WG5: RAN4 kindly asks RAN1 and RAN5 to take the above information into account.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":77200,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-16 17:38:49","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"FS_NR_MIMO_OTA_test"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-1910610","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197720.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-197722","title":"Reply LS on using GIBA for testing IMS over 5GS","source":"TSG WG SA2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Release:\tRel-15\nWork Item:\t5GS_Ph1\nSA2 thanks RAN5 for their LS in R5-197096 \/ S2-1908700 and would like to give the following feedback on the actions assigned on SA2.\nAction 1: SA2 to check TS 23.167 Annex K if it is deemed to be applicable for 5GS as well\nSA2 answer: SA2 thanks RAN5 for pointing out this oversight in TS 23.167, where Annex K is intended to apply also on IMS over 5GS case. SA2 intends to provide Rel-15 CR documenting this in SA2 #136.\nAction 2: SA2 to notify RAN5 about other scenarios where GIBA is to be used in 5GS.\nSA2 answer: SA2 is not aware of any other GIBA use cases for 5GS that would be missing in the existing Rel-15 specifications in addition to the one mentioned above in Action 1. \n2. Actions: To RAN5 group: SA2 kindly asks RAN5 to take this information into account when progressing their work.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":77220,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-23 15:14:44","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"S2-1910232","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197722.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-197723","title":"LS on Sweep time for LTE V2X UE co-existence spurious emission","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Release:\tRelease 14, Release 15 and Release 16\nWork Item:\tLTE_V2X-Core\nRAN4 has discussed the LTE V2X UE co-existence spurious emission requirement and measurement accuracy on 5815-5855MHz, since the highly stringent requirement is required immediately on the edge of the channel, RAN4 has reached the agreement on the sweep time setting and RBW to improve measurement accuracy. The sweep time and RBW setting are recommended to be set as following in Release 14, Release 15 and Release 16:\n\u2022\tThe sweep time shall be set larger than (symbol length)*(number of points in sweep). For 1000 points in sweep, the sweep time is recommended to be 100ms.\n\u2022\tResolution BW is 10% of the measurement BW and the result should be integrated to achieve the measurement bandwidth.\n2. Actions: To: 3GPP TSG RAN WG5: RAN4 kindly asks RAN5 to take the above information into account.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":77230,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-24 10:22:03","revisionof":"","revisedto":"","release":"Rel-14","crspec":"","crspecversion":"","workitem":[{"winame":"LTE_V2X-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-1912424","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197723.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-197724","title":"LS on EN-DC MSD Transmit Power Level Assumptions","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Release:\t15\nWork Item:\tNR_NewRAT-Core\nRAN4 has noticed that EN-DC MSD test procedure for setting both LTE and NR transmit power levels may not always ensure UE MSD is tested in accordance to RAN4 assumptions that were used to derive the MSD requirements. Therefore, RAN4 would like to inform RAN5 about the assumptions that have been adopted to derive MSD requirements: \n\u2022\tFor Intra-Band EN-DC operation, based on co-located assumption, RAN 4 has assumed equal Power Spectral Density between LTE and NR carriers, \n\u2022\tFor Inter-Band EN-DC operation, RAN 4 has assumed equal power between LTE and NR carriers.\n2. Actions to RAN5: RAN4 respectfully asks RAN5 to take the above-mentioned information on the RAN4 assumptions into account when developing the test procedure for EN-DC MSD requirements.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":77240,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-24 10:22:03","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"NR_newRAT-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-1912614","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197724.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-197725","title":"LS Response on the feasibility of time synchronization accuracy requirements and related testing","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Release:\tRel-16\nWork Item:\tNR_IIOT-Core\nResponse to:\tR1-1909906: Reply LS on propagation delay compensation for reference time information delivery\nRAN4 would like to thank RAN1 for their questions in their LS to RAN4 on propagation delay compensation for reference time information delivery (R1-1909906). RAN4 discussed the following request from RAN1:\nQuestion to RAN4 and RAN5: \nDoes RAN4\/RAN5 see it feasible to define performance requirements and related testing for time synchronization accuracy over Uu interface (i.e. between a gNB and a single UE)? Note: the time synchronization accuracy over Uu interface is on the order of hundreds of ns in order to achieve between sync master and device the time synchronization accuracy target of 1 \u00b5s.\nRAN4 would like to provide the following response:\nRAN4 will not define performance requirements and related testing for time synchronization accuracy over the Uu interface in Rel-16 since current RAN4 requirements in Rel-15 and Rel-16 only cover the synchronization accuracy error factors in the air interface.\nSince the synchronization requirements are E2E and independent of the RAT, testing should rely on E2E test cases specified outside of 3GPP. \n2. Actions: To RAN1 and RAN2 group: RAN4 requests RAN1 and RAN2 to kindly take the RAN4 responses into account in their future work.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":77250,"status":"noted","reservation_date":"2019-10-15 13:03:13","uploaded":"2019-10-24 10:22:03","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"NR_IIOT-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R1-1909906","lsto":"","Cc":"","lsoriginalls":"R4-1912743","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-197725.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-198830","title":"LS on Testing and Certification of 3GPP Mission Critical features\nA GCF-TCCA Joint Approach to Develop and Manage MC Certification","source":"TCCA","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"TCCA would like to request GCF to set up a joint GCF-TCCA taskforce to investigate and develop a testing & certification scheme for mission critical products.\n2.\tBackground\nIn February 2017 TCCA and GCF signed an MoU. GCF has since included MCPTT conformance test cases in its work program and has further engaged with the mission critical community at TCCA events to encourage the use of GCF certified products in mission critical deployments. TCCA is grateful for this support which goes in the right direction and would like to thank GCF for the support so far.\nHowever, we believe that further steps are now needed in order to ensure the adoption of certification by the mission critical industry to meet the specific needs of the critical communications community.\nOn top of the certification which GCF currently carries out for consumer devices there are specific requirements which mission critical users have. Mission Critical users heavily rely on the availability and reliability of the critical communications services, many of the users trust their lives to this communication.\nThe specific mission critical requirements need to be explored, understood and agreed in the context of certification. These issues include:\n\u2022\tEnsuring the availability of suitable conformance test equipment for Mission Critical products.\n\u2022\tEnabling a certification to be developed with inputs from the mission critical vendors, user and operators of mission critical networks.\n\u2022\tEnsuring end to end interoperability of mission critical products (devices and servers), applications, services and networks\n\u2022\tEnsuring the security of mission critical products\n\u2022\tInvestigating the need to define mission critical device profile(s)\n\u2022\tHow would a developed mission critical certification be managed and governed?\n3.\tPurpose of the proposed new joint GCF-TCCA working group\nTCCA would like to build on the very fruitful and existing collaboration with GCF.\nSpecifically, we believe that with the creation of a joint GCF-TCCA task force we can combine the expertise of both organisations to investigate and develop a suitable testing and certification scheme for the mission critical community.\nThis would enable key stakeholders from both GCF and TCCA to collaborate in this special field and would be a valuable next step towards a trusted certification which fits the purposes of both organisations. Possible topics for inclusion in the terms of reference of any new group could include:\n\u2022\tScope of the Mission Critical Certification (which elements, which interfaces)\n\u2022\tRequired types of Testing (Conformance, Interoperability, Field, Performance)\n\u2022\tOrganisation, Management and Governance of an ongoing scheme\n4.\tSupport for this approach\nTCCA, with the support of the GCF office, held a first workshop on 30 Oct 2019 with its members regarding testing and certification strategies. A summary of the workshop results was presented in the CCBG (Critical Communications Broadband Group) on 6 Nov 2019 and received very positive feedback and wide support from the TCCA members.\nTCCA would welcome support from GCF members and active participation in the proposed joint GCF-TCCA working group.\n5.\tRequest to GCF SG\nTCCA politely requests GCF SG to consider setting up a joint GCF-TCCA taskforce to investigate and develop certification for mission critical products. TCCA believes this would be a valuable extension to our existing MoU and would be to the benefit of both, the mission critical and the mobile industries, that are represented by our respective members.\nTCCA thanks GCF for the existing collaboration and looks forward to ongoing future collaboration.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":883000,"status":"noted","reservation_date":"2019-11-26 18:03:36","uploaded":"2019-11-26 18:08:01","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_85_Reno\/Docs\/R5-198830.zip","group":"R5","meeting":"R5-85","year":2019,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]