[{"name":"R5-214164","title":"Reply LS on 180 Ringing when preconditions are not used","source":"TSG WG CT1","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"LS R5-206259 on failing initial registration without Retry-After header field from RAN5","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41640,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R5-211359","lsto":"","Cc":"","lsoriginalls":"C1-212906","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214164.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214165","title":"LS reply on \"\"ICE support for establishing an MCPTT pre-established session\"\"","source":"TSG WG CT1","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"CT1 thanks RAN5 for their LS on ICE support for establishing an MCPTT pre-established session.\nCT1 notes that, while IETF RFC 5245 indicates that use of ICE is optional, 3GPP TS 24.379 mandates the use of ICE for an MCPTT pre-established session. \nRAN5 has asked two questions:\na)\tMay a participating MCPTT function leave out any ICE candidates in the SDP answer to indicate that support of ICE is not needed?\nCT1 reply: No. The participating MCPTT function shall include all ICE candidates in the SDP answer.\nb)\tMay an MCPTT client \u2013 based on UE capability of UE configuration \u2013 indicate by leaving out any ICE candidates in the SDP offer, that it does not support ICE?  Or \u2013 is support of ICE always mandatory for an MCPTT client at establishment of a pre-established session?\nCT1 reply: The client is required to support ICE for establishment of a pre-established session, and thus the MCPTT client shall include all usable ICE candidates in the SDP offer.\n2\tActions\nTo: RAN WG5: CT1 asks RAN5 to take the above information into consideration in your work.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41650,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R5-211360 \/ C1-212822","lsto":"","Cc":"","lsoriginalls":"C1-213546","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214165.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214166","title":"LS reply on SDP attribute a=key-mgmt:mikey","source":"TSG WG CT1","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"CT1 thanks RAN5 for their LS on SDP attribute a=key-mgmt:mikey.\nRegarding the questions asked: \nRAN5:\tCan the key-mgmt attribute be a session level attribute or is it a media level attribute?\nCT1:\tWhether the key-mgmt attribute is used at the session level or media level, all instances of the attribute need to specify the same PCK, since 3GPP TS 33.180 does not define how to establish an MCVideo session using different keys for video and the associated audio. A session level attribute applies to all m-lines. If the attribute is not intended to apply to all m-lines the normal solution is to use media level attributes.\nRAN5:\tShould the same key-mgmt attribute be used for audio and video?\nCT1:\tYes. A single PCK should be used for both.  3GPP TS 33.180 does not define how to establish an MCVideo session using different keys for video and the associated audio.\nRAN5:\tIf the key-mgmt attribute is a session level attribute, how should media stream (floor control \/ pre-established call signaling...) be handled since the CSK should be used?\nCT1:\tSince the key-mgmt attribute is applicable for the media streams which transport the video and associated audio media, SRTCP, which is derived depending on the interface, is used for the media streams that include the floor control, media control, and pre-established session call control messaging. Detailed information can be found in 3GPP TS 24.581 subclause 13 on media plane security.\n2\tActions\nTo: RAN WG5: CT1 asks RAN5 to take the above information into consideration in your work.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41660,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R5-206283 \/ C1-212820","lsto":"","Cc":"","lsoriginalls":"C1-213548","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214166.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214167","title":"Reply LS on confirming successful resource reservation","source":"TSG WG CT1","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41670,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R5-211311","lsto":"","Cc":"","lsoriginalls":"C1-213557","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214167.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214168","title":"LS reply on integrity and confidentiality protection of xcap-diff and pidf documents in MCPTT (TS 24.379)","source":"TSG WG CT1","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"CT1 thanks RAN5 for their LS on integrity and confidentiality protection of xcap-diff and pidf documents in MCPTT (TS 24.379).\nCT1 wishes to inform RAN5 that the xcap-diff and pidf documents were added to the list of protected documents in 3GPP TS 24.379 subclause 6.6.3.1 in C1-213068. \nWe also wish to note to RAN5 that similar changes were made to MCVideo in 3GPP TS 24.281 subclause 6.6.3.1 in C1-213595 and to MCData in 3GPP TS 24.282 subclause 6.5.3.1 in C1-213594.\n2\tActions\nTo: RAN WG5: CT1 asks RAN5 to take the above information into consideration in your work.","secretary_remarks":"LS R5-206258 on \" LS on inconsistency in specifying handling of MCPTT SIP 183 (Session Progress) response in TS 24.379\"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41680,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R5-206273 \/ C1-212819","lsto":"","Cc":"","lsoriginalls":"C1-213597","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214168.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214169","title":"LS on RAN4 recommendation for the 52.6 - 71 GHz frequency range designation","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"3GPP RAN WG4 would like to inform 3GPP TSG RAN on the progress of the discussion on 52.6 - 71 GHz frequency range designation. \nDuring the discussion in NR_ext_to_71GHz-Core work item, RAN WG4 was investigating various options for the 52.6 - 71 GHz frequency range designation, including such options as: \n-\tOption 1: Introduce FR2-1 (24.25 \u2013 52.6 GHz) and FR2-2 (52.6 \u2013 71 GHz) \nWithin option 1, indicate on the preferred approach: \no\t\u201cFR2-1 and FR2-2\u201d, or \no\t\u201cFR2.1 and FR2.2\u201d\n-\tOption 2: Introduce FR2-2 (52.6 \u2013 71 GHz) in addition to FR2 (24.25 \u2013 52.6 GHz)\n-\tOption 3: Define FR3\n-\tOption 4: \no\tAll UE RF\/demod requirements defined as function of band, BW, PC or band combo within FR2;\no\tBS requirements can be updated to cater for an extension of FR2 to include 52.6 \u2013 71 GHz;\no\tAll RRM requirements for higher SCS applicable for 52.6 \u2013 71 GHz can be defined as function of SCS within FR2;\n-\tOption 5: \no\tKeep FR2 definition as it is\no\tIntroduce FR2x (52.6 \u2013 71 GHz) and FR2-comb (24.25 \u2013 71 GHz)\n-\tExcept option 3, all above proposals intend not to introduce FR3.\n\nDuring the discussion on 52.6 - 71 GHz frequency range designation, pros and cons of the above options were analysed, including RAN4 specification impact considerations. Additionally, RAN5 decision on the introduction of FR2a \/ FR2b \/ FR2c terms for the MU and TT purposes was also recognized. \nBased on the RAN WG4 discussion, the following is provided as recommendation to 3GPP TSG RAN: \n1.\tTo drop \u201cFR3\u201d terminology from consideration on the 52.6 - 71 GHz frequency range designation. \n2.\tTerminology for BS operating in 52.6 - 71 GHz frequency range to be reused from TS 38.104 specification, i.e. BS type 2-O.\n\nFurthermore, RAN WG4 would like to inform that the discussion on the terminology for the NR operation in 52.6 - 71 GHz frequency range will continue in RAN WG4, including pros and cons analyses of concepts based on Option A, Option B and Option C, as listed below:\n-\tOption A: \no\tIntroduce FR2-1 (or FR2.1) for 24.25 \u2013 52.6 GHz, and FR2-2 (or FR2.2) for 52.6 \u2013 71 GHz,\no\tThe above two ranges to be introduced under the FR2 common range.\n-\tOption B: \no\tAll UE RF\/demodulation requirements defined as function of band, BW, PC or band combo within FR2,\no\tBS requirements can be updated to cater for an extension of FR2 to include 52.6 \u2013 71 GHz,\no\tAll RRM requirements for higher SCS applicable for 52.6 \u2013 71 GHz can be defined as function of SCS within FR2.\n\n-\tOption C: in addition to reusing the existing FR2 for 24.25 \u2013 52.6GHz:\no\tIntroduce FR2-2 (or FR2x) for 52.6 \u2013 71 GHz,\no\tPossibly introduce FR2-comb for 24.25 \u2013 71 GHz.\n2. Actions:\nTo 3GPP TSG RAN: 3GPP RAN WG4 kindly asks 3GPP TSG RAN to take the above recommendation into account.","secretary_remarks":"LS R5-206259 on failing initial registration without Retry-After header field from RAN5","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41690,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NR_ext_to_71GHz-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2107879","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214169.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214170","title":"Reply LS On minimum requirements for Transmit ON\/OFF time mask in UL MIMO FR1","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN4 thanks RAN5 for the LS on minimum requirements for Transmit ON\/OFF time mask in UL MIMO FR1 and would like to give following clarification on the minimum requirements for transmit ON\/OFF time mask for UL MIMO.\nRAN4 confirms that in Rel-15 the clause 6.3D.3, i.e. transmit ON\/OFF time mask requirements for UL MIMO are defined at each antenna connector. The per-connector OFF power is defined in 6.3D.2. The per-connector ON power is defined as any power level such that the sum of the measured powers from both connectors are bounded by the maximum output power requirement in sub clause 6.2D.1 and the minimum output power requirement in sub clause 6.3D.1.\nRAN4 also would like to clarify that the ON\/OFF time mask requirement for UE with Tx diversity is still under discussion, RAN4 will inform RAN5 with that if conclusions are made in Rel-16.\n2. Actions: To RAN5: RAN4 asks RAN5 to take the above into consideration.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41700,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_NR_LTE-UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R4-2104471 \/ R5-211826","lsto":"","Cc":"","lsoriginalls":"R4-2107904","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214170.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214171","title":"LS on time mask for NR V2X and LTE V2X switching in ITS band","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Time mask for NR V2X and LTE V2X switching in ITS band is a remaining issue for Rel-16 NR-V2X WI. RAN4 had reached consensus on the time mask requirement as below:\n\nThe switching time shall be located on the RAT of lower priority when NR SL and LTE SL have different priorities based on priority information specified in TS 38.213. It is up to UE implementation when NR SL and LTE SL have the same priority based on priority information specified in TS 38.213.\nFigure 1: Time mask for switching between NR SL and E-UTRA SL\nThe above time mask requirement is to give criteria on how the switching period position is decided based on priority information. RAN4 made an agreement that no RF test is needed for this SL switching time mask requirement defined in TS 38.101-3 Clause 6.3E.2. \n2. Actions: To RAN5: RAN4 asks RAN5 to take the above information into account.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41710,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5G_V2X_NRSL-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2108019","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214171.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214172","title":"Reply LS to RAN5 LS on Frequency Bands for testing of A-GNSS Sensitivity requirements in NR and LTE","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN4 thanks RAN5 for the LS on Frequency Bands for testing of A-GNSS Sensitivity requirements in NR and LTE. RAN4 looked into the aspects of how to reduce testing in LTE and NR bands and EN-DC band combinations by focusing on problematic frequency bands or band combinations that are likely to generate interference in the GNSS bands, and reached the following agreements:\n1.\tLTE and NR bands (SA): \nRAN4 will make a decision between the following two options at RAN4 meeting#100-e:\n\u2022\tOption 1: LTE Bands 13, 14, 24, 44 and NR Bands n13, n14, n24, n79 and n96. In case of the same LTE and NR band supported by a UE, e.g., 14\/n14, it suffices to test either LTE band 14 or NR band n14 because of the same interference mechanism\n\u2022\tOption 2: all UE supported bands\n\n2.\tEN-DC band combinations:\nWhen an EN-DC configuration generates second or third order intermodulation distortion (IMD) products falling into the following GNSS L1\/E1\/G1\/B1 typical receiver bands (where supported by the UE), it shall be considered as a candidate for testing:\n- GPS L1 C\/A :\t1574.3970 \u2013 1576.4430 MHz\n- Galileo E1 \/ GPS L1C:\t1573.3740 \u2013 1577.4660 MHz\n- GLONASS G1:\t1597.5515 \u2013 1605.8860 MHz\n- BDS B1I:\t\t1559.0520 \u2013 1563.1440 MHz\n\nTo further reduce testing, all EN-DC configurations are divided into groups with similar IMD level and risks. For each group, only one of the EN-DC configurations supported by the UE in the group shall be tested.\n \n3.\tMaintenance of lists of LTE and NR bands and EN-DC band combinations for testing: \nAs RAN4 continues to introduce new bands or new EN-DC band combinations, RAN4 shall maintain the lists.\n\n2. Actions: To RAN5: RAN4 respectfully asks RAN5 to take the above agreements into account in its further discussion.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41720,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"R5-206900","lsto":"","Cc":"","lsoriginalls":"R4-2108233","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214172.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214173","title":"LS on NR-U Test Cases subject to statistical testing","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"wrong zipfile","secretary_remarks":"LS R5-206258 on \" LS on inconsistency in specifying handling of MCPTT SIP 183 (Session Progress) response in TS 24.379\"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41730,"status":"withdrawn","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"NR_unlic-Perf"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2108262","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214173.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214174","title":"LS to RAN5 on MU work of FR1 TRP TRS WI","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"The FR1 TRP TRS WI started in RAN4 during RAN4#99-e. Both the workplan (R4-2108624 in the attachment) and the skeleton of TR 38.834 on FR1 TRP TRS test method (R4-2108625 in the attachment) have been agreed. According to the objectives in the WID, RAN5 is responsible to develop the MU assessment for SA and EN-DC test methods as the secondary responsibility working group.\nKey milestones for MU in the workplan:\n?\tMU work to start during August 2021 meeting in RAN5 (i.e. RAN5#92-e).\n?\tThe Text proposals for MU assessment should be finalized before the end of RAN4#102-e (2022 Feb) meeting. RAN4 will have a chance to accommodate the MU TPs in the TR with an after-meeting email approval process.\nIn this RAN4 meeting, the following key agreements related to MU assessment have been achieved:\n?\tFor SA test method, the test methodology for LTE could be reused as much as possible.\n?\tFor EN-DC OTA test method, dynamic power sharing is not considered. How to configure the power split between LTE and NR is under discussion.\n?\tA MU element for \u201csystem frequency flatness\u201d should be considered, given the test system should support up to 100MHz bandwidth testing.\n?\tHead&Hand test configuration is considered for FR1 TRP TRS testing, and thus related MU impacts should be considered.\n?\tFor both SA and EN-DC test method, the minimum measurement distance of 1.2 m is agreed.\nFor the detailed agreements for FR1 TRP TRS WI in this RAN4 meeting, please refer to the approved WF (R4-2108620) in the attachment.\nRAN4 has considered the following options on how to coordinate with RAN5 on MU work:\n\u2022\tOption 1: RAN4 and RAN5 coordinate on MU work via LSs\n\u2022\tOption 2: RAN5 directly contribute on the MU clause of TR 38.834\n\u2022\tOption 3: RAN5 create a new specification with the scope of MU \nConsidering there is no precedence in 3GPP of the secondary responsibility working group approving TPs\/CRs to a specification, or creating a new specification within the responsibility of primary working group, according to the guidance from MCC, the following coordination between RAN5 and RAN4 on MU work is recommended from RAN4 perspective:\n?\tIn the TR 38.834, Annex B: MU assessment is the clause to draft MU budget, which is assigned to capture RAN5 outcome on MU assessment.\n?\tAgreements or endorsed Test Proposals can be sent to RAN4 via LS including the required attachments. RAN4 will also inform RAN5 on the decisions of test methods and other aspects related to MU assessment.\n?\tTimely feedback on the progress of each part of work is needed to ensure a smooth progress of the whole WI. \nRAN4 would suggest RAN5 to take the above information into account and start the MU WP\/technical discussion for FR1 TRP TRS test methods.\n \n2.\tActions: To RAN5: \t3GPP RAN4 respectfully asks RAN5 to take the above information into account and start the MU discussion for FR1 TRP TRS WI.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41740,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NR_FR1_TRP_TRS"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2108622","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214174.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214175","title":"Reply LS on 5G FR1 OTA Testing Method","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"3GPP RAN4 would like to thank GSMA TSG-AP for their 23 April, 2021 LS requesting information concerning 5G FR1 OTA testing method in 3GPP.\n3GPP RAN4 is interested in working with GSMA TSG-AP to leverage the OTA Testing Method for 5G FR1. \nIn RAN#91e meeting, March 2021, the WI on FR1 TRP TRS was approved. This WI is to define FR1 OTA test methodology and specify corresponding FR1 TRP and TRS OTA requirements, for both SA and EN-DC UEs. \nThe WI includes two parts: core part and performance part. The key milestone is listed as follow:\n?\tThe core part of the WI focus on the development of FR1 OTA test methods, which will be finalized at RAN#95, March 2022, and the Technical Report TR 38.834 for 5G FR1 OTA test method named as \u201cMeasurements of User Equipment (UE) Over-the-Air (OTA) performance for NR FR1; Total Radiated Power (TRP) and Total Radiated Sensitivity (TRS) test methodology\u201d will be formally released. \n?\tThe performance part of the WI focus on the definition of the performance requirement of 5G UEs, which will be finalized at RAN#97, September 2022, and the Technical Specification for 5G FR1 OTA performance requirements named as \u201cNR; User Equipment (UE) Over-the-Air (OTA) performance requirements; Range 1 Standalone and Range 1 Interworking operation with other radios\u201d will be formally released.\nWith regards to the OTA test method question:\n \nYes, RAN4 is working on the OTA test methods for 5G FR1 UEs.\n\nWith regards to the use scenarios:\n \nThe above use scenarios have been adopted by RAN4 to develop FR1 TRP TRS OTA test methods. \nWith regards to the working scope and workplan:\n \nThe detailed working scope of the project is captured in section 4 Objective part of the WID [RP-210807]. The detailed workplan for both RAN4 and RAN5 is agreed in [R4-2108624]. The skeleton of the Technical Report (TR 38.834) for FR1 TRP TRS test methods has been approved in [R4-2108625]. \nSome key aspects related to the schedule of the WI are listed:\n?\tThe TR 38.834 for TRP TRS OTA test methods will be finalized and published in RAN#95, March 2022\n?\tRAN5 is working on MU assessment of the test methods and drafting Annex B: Measurement uncertainty of TR 38.834 as secondary responsibility group of the WI.\n?\tThe LS to CTIA for coordination on Head&Hand Phantoms is approved in [R4-2108622].\n?\tThe TS 38.1xy (spec number has not been assigned) for FR1 UE TRP TRS requirements will be finalized and published in RAN#97, September 2022.\nWith regards to the EN-DC power splitting:\n \nThe WI will define the configured power settings for EN-DC (1 CC LTE with 1 CC NR), the detailed power splitting is under discussion in RAN4. RAN4 will take the above recommendation into account in our future work. \nWith regards to the technical questions for Dynamic Power Sharing test method:\n \nWhether RAN4 will develop special OTA test method for Dynamic Power Sharing function is still under discussion. \nWith regards to the technical questions for TRS self-interference:\n \nIn the WID, there is an objective to discuss the NSA TRS requirements for potential UE self-interference due to IMD3 in EN-DC. The self-interference of UE will be considered as 2nd priority in this WI.\n2\tActions\nTo GSMA TSG-AP: \nACTION: \t3GPP RAN4 respectfully asks GSMA TSG-AP to take the above feedback into account and encourage GSMA TSG-AP to further collaborate with 3GPP RAN4 on 5G FR1 OTA test method and requirement.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41750,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NR_FR1_TRP_TRS"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2108623","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214175.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214176","title":"LS to RAN5 on LTE REFSENS Exceptions Simplification","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"RAN4 sent LS to RAN5 [1] from WG4 Meeting # 98-e informing RAN5 that it will adopt new MSD test point scheme for new REL-17 LTE CA combinations.\nRAN4 has now done more work on the topic and observed that due to the small number of new LTE combinations introduced in REL-17 the agreed method for only changing MSD test point scheme for new REL-17 LTE CA combinations does not really have much impact on RAN4 specification simplification or amount of RAN5 MSD test cases [2].\nRAN4 would like to hear RAN5 opinion if LTE REFSENS exceptions simplification should be limited only to new REL17 CA configurations (Option 1) as was already communicated in [1] or if the simplification can be also applied to CA configurations in earlier releases (Option 2).\nOption 1: \n-\tFor new Rel-17 band combinations:\n-\tFor TPs for TR: According to the agreed WF [1], do not specify higher order REFSENS test points if already covered by a fall-back combination,\n-\tFor 36.101: Remove REFSENS test points if already covered by fall-back combination via small CR.\n-\tFor legacy combinations:\n-\tDo not bring any change to TS 36.101.\nOption 2: \n-\tFor new Rel-17 band combinations:\n-\tFor TPs for TR: According to the agreed WF [1], do not specify higher order REFSENS test points if already covered by a fall-back combination,\n-\tFor 36.101: Remove REFSENS test points if already covered by fall-back combination via small CR.\n-\tFor legacy combinations:\n-\tKeep only the lowest order fall-back test points and remove all redundant REFSENS test points in TS 36.101.\n2. Actions: To RAN5: RAN4 asks RAN5 feedback concerning Option 1 versus Option 2.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41760,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-13 15:51:39","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"LTE_CA_R17_2BDL_1BUL"},{"winame":" LTE_CA_R17_3BDL_1BUL"},{"winame":" LTE_CA_R17_xBDL_1BUL"},{"winame":" LTE_CA_R17_2BDL_2BUL"},{"winame":" LTE_CA_R17_xBDL_2BUL"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2109739","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214176.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214178","title":"LS Announcing the publication of GSMA TS.48 Generic eUICC Test Profile for Device Testing version 4.0","source":"GSMA TSG eSIMTP","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"GSMA TSG is pleased to announce the publication of V4.0 of the TS.48 \u2018Generic eUICC Test Profile for Device Testing\u2019 which defines an eSIM test profile for use in testing product with System Simulators, typically for use when testing a device with a non-removable eSIM to ensure  compliance to 3GPP specifications.\n\nExternal Recipients:\tTo: 3GPP RAN5, 3GPP CT6, GCF SG, GCF CAG, CTIA, PTCRB, Global Platform, SIM Alliance\nCc: 3GPP TF160\nInternal Recipients:\tTSG, eSIM Group Plenary, eSIM WI4\n\n\n2\tTS.48 V4.0 Overview\n\nTS.48 V4.0 changes include:\nChange to the minimum security from 0x06 (Ciphering + CC) to 0x02 (CC only)\nChange to the OTA keys to align to 3GPP TS 31.124 test cases\nChange of the SUCI Calc information for device and USIM\nA download of a reference ASN.1 files and a Excel file detailing the test profile definition is available on GitHub, \nhttps:\/\/github.com\/GSMATerminals\/Generic-eUICC-Test-Profile-for-Device-Testing-Public\nThere are four reference ASN.1 Files are available:\nSAIP 2.3 with BER-TLV\nSAIP 2.3 without BER-TLV\nSAIP 2.1A without BER-TLV\nSAIP 2.1B without BER-TLV\n (SAIP = SIMAlliance Interoperable Profile)\n\n3\tAction\nThe basis for the Generic Test Profile is to enable continued use of existing process and procedures, validated test cases and test platforms in GCF and PTCRB when certifying device with a non-removable eUICC. It also removes the need for specific device hardware or modified hardware by an OEM testing 3GPP compliance in devices supporting eSIM.\nGSMA requests GCF and PTCRB to note the publication of TS.48 v4.0, and make appropriate references and guidance in their process and procedure documentation to encourage use of the TS.48 Generic Test Profile when testing 3GPP device compliance","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41780,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-30 06:21:34","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"TSG44_032","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214178.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214179","title":"LS on NR-U Test Cases subject to statistical testing","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"replacement of R5-214173 which had wrong file zipped.\nRAN4 is currently specifying RRM Performance TCs (Test Cases) related to NR-U; a subset of these TCs intends to test the impact of DL\/UL CCA failures. For this purpose, the Test Equipment is expected to implement CCA failure randomization, i.e. for each test the Test Equipment randomly assumes either a CCA success or a CCA failure with an overall probability of CCA success PCCA, PCCA being configured for a given Test Case with a value 0 < PCCA < 1. This is the case in particular for Random Access TCs.\nGiven the above, RAN4 has agreed that the corresponding TCs \u2013 including Random Access TCs - are subject to statistical testing, as defined by RAN5 Specification TS 38.533:\nRAN4 agreement:\n\u2022\tDetermine that TCs under CCA with 0 < PCCA <1 are subject to statistical testing.\no\tSend LS to inform RAN5 about the RAN4 decision.\nTo RAN5: RAN4 asks RAN5 to take the above into account.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41790,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-07-31 08:29:56","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"NR_unlic-Perf"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2108262","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214179.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"R5-214180","title":"LS on RAN4 updates to TR 37.901-5","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Under the release 16 study item on 5G NR UE Application Layer Data Throughput Performance (FS_UE_5GNR_App_Data_Perf), RAN4 evaluated the feasibility of defining absolute physical layer throughput requirements under link adaptation based on the simulation assumptions [2]. As per the evaluation results [3] and the agreed alignment criteria [1], RAN4 concluded that it is feasible to define such requirements [4]. \nAlthough this SI is a Rel-16 SI in RAN5, RAN4 was added as secondary responsibility working group to this SI for Rel-17. RAN4 suggests RAN5 to take the feasibility study conclusion on defining applicability layer data throughput performance from RAN4 into future work and prepare a RAN5 CR by including all endorsed RAN4 draft CRs [1~4] but with Rel-17 in the coversheet to request TR 37.901-5 to be upgraded to Rel-17.\n\n2. To RAN WG5 group. \nACTION: RAN4 respectfully asks RAN5 to take above into consideration when capturing the outcomes of study item FS_UE_5GNR_App_Data_Perf.","secretary_remarks":"","agenda_item_sort_order":4,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":41800,"status":"noted","reservation_date":"2021-07-01 20:44:21","uploaded":"2021-09-01 07:41:18","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_UE_5GNR_App_Data_Perf"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R4-2114569","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_92_Electronic\/Docs\/R5-214180.zip","group":"R5","meeting":"R5-92-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]