[{"name":"R5-230017","title":"NGMN Liaison on Pre-Commercial Network Slicing Trials Major Conclusions","source":"Next Generation Mobile Networks Alliance","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"2.\tNGMN Network Slicing for Operating Systems of 5G Smart Phones Project\nNGMN Network Slicing for Operating Systems of 5G Smart Phones Project Phase 2 was kicked off together with GTI in 2021. The main purpose of the project is to assess the functionality and performance of Network Slicing implementation in 5G Devices based on 5G NR Release 15 and onward by lab test\/field trials, so as to ensure the user experience. \n3.\tIntention of the LS and required actions\nNGMN and GCF had several liaisons on network slicing test. This time, NGMN would like to share with GCF the latest progress of network slicing test and inform GCF about the publication of the NGMN-GTI joint White Paper \u201cPre-Commercial Network Slicing Trials Major Conclusions\u201d, concluding with the proposal to suggest GCF starting the certification of the service capability test for 5G devices supporting network slicing.\nIn the second half of 2021, China Mobile, SK Telecom and Turkcell started the field trials following NGMN\u2019s 5G device network slicing testing framework for pre-commercial trials. Two types of devices have been tested, including 5G smart phones and 5G S-Modules. Four mainstream chipset platforms have been covered in the trial. The scope includes both, signalling test and service capability test. Detailed information is included in the released NGMN-GTI joint White Paper \u201cPre-Commercial Network Slicing Trials Major Conclusions\u201d. \nSeveral mainstream device\/chipset vendors have participated in the network slicing trials, including Huawei, MediaTek, OPPO, Qualcomm, Quectel, Samsung, Unisoc, vivo, Xiaomi and ZTE (in alphabetical order). The test results are in line with the expectations. The majority of the devices have passed the signalling test. For video service capability test and FTP\/Speedtest download service capability test, a significant performance improvement has been observed for the service with network slicing, compared to the service without network slicing. The test results indicate that the 5G devices supporting network slicing are ready for commercial launch. \nIn addition, during the service capability test, it was observed that it is difficult to create a unified testing environment with the actual network elements. And the service capability testing environment is not easy to be set up, when using actual network elements. It is believed that the network slicing service capability test with test equipment is a better alternative, which can dramatically reduce the testing execution complexity and the testing costs. Moreover, the convenience and conformance of network slicing service capability test with test equipment is better than the test with actual network elements, which makes the unification of testing of various kinds of devices more conducive. \nTaking account of the maturity of 5G devices supporting network slicing and the progress in 3GPP RAN5, NGMN suggests that GCF considers kicking off the validation and certification of the service capability testing for 5G devices supporting network slicing. Please keep NGMN informed, if there is any further progress of validation\/certification for network slicing testing in GCF.","secretary_remarks":"LS R5-206259 on failing initial registration without Retry-After header field from RAN4","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":170,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","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_98_Athens\/Docs\/R5-230017.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230018","title":"Network selection for specific consumer type mobiles","source":"TSG WG CT1","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"CT1 thank GCF-CAG for their LS requesting CT1 to review the necessity for the mandate of the implementation of Manual Network selection mode and explore ways of making the feature optional for consumer wearable form factors.\nCT1 clarify to GCF-CAG that CT1\u2019s responsibilities with regard to network selection are to specify the stage 2 for NAS functions related to the UE in idle mode, based on the service requirements for network selection set out by 3GPP SA1, see clause 3.2 of 3GP TS 22.011 (i.e. the stage 1 network selection requirements).\nThus, it is not within CT1\u2019s remit to make exceptions for any specific type, categories or characteristics of mobile devices other than what has been specified by SA1. CT1 include SA1 in this response and attaches the LS CT1 received from GCF-CAG so that SA1 can consider if any work or action is needed regarding GCF-CAG\u2019s request for consumer wearables form factors.\nActions: To GCF-CAG CT1 kindly request GCF-CAG to take into consideration CT1\u2019s response above.\nTo 3GPP SA1: CT1 request SA1 to consider if any action on SA1\u2019s part is needed.","secretary_remarks":"LS R5-206259 on failing initial registration without Retry-After header field from RAN5","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":180,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","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_98_Athens\/Docs\/R5-230018.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230019","title":"LS to RAN5 on UE TxD for OTA testing","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"RAN4 is working on FR1 TRP and TRS OTA test method for UE supporting TxD capability. RAN4 seeks a few answers from RAN5 on the following questions in order to proceed further on the study of UE configuration and test procedure. \nQuestion 1: How to ensure stable TxD mode during RF MOP testing? Is sending continuously uplink power control \"up\" commands sufficient? \nQuestion 2: Is test mode used for TxD testing in conductive RF MOP testing?\nQuestion 3: Is conductive RF MOP testing for TxD based on testing 1 antenna port at a time and summing two ports or testing 2 antennas ports transmitting simultaneously?\nNote: RAN4 agrees to define test methods for TxD capable UE with two antennas transmission simultaneously as 1st priority.\nRAN4 also would like to ask RAN5 to provide any information that may help RAN4 determine TRP OTA test method for UE supporting TxD capability.\nActions To RAN5: RAN4 asks RAN5 to provide answers for the above questions and any additional information that may help RAN4 determine TRP OTA test method for UE supporting TxD capability.","secretary_remarks":"LS R5-206259 on failing initial registration without Retry-After header field from RAN5","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":190,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"NR_FR1_TRP_TRS_enh"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_98_Athens\/Docs\/R5-230019.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230020","title":"Reply LS on NS_50 A-MPR","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN4 thanks RAN5 for the LS on A-MPR regions for NS_50 (Power Class 2) in R5-225650. It is RAN4\u2019s understanding that the A-MPR regions are defined in terms of frequency limits within a given channel bandwidth. If there is no valid RB allocation in a given region due to e.g., increased SCS, the specified A-MPR value is not applicable.\nMore specifically, RAN4 has made the following observations regarding the test points for SCS=60kHz.\nObservation 1: For channel BW=10MHz and SCS=60kHz, no RB would be allocated to the A-MPR region with A-MPR value A4. Hence, no A-MPR is applicable for this case.\nObservation 2: For channel BW=15MHz and SCS=60kHz, the test point may be defined using RB_start=5 and L_CRB=13 for CP-OFDM, and using RB_start=6 and L_CRB=12 for DFT-s-OFDM.\nObservation 3: For channel BW=20MHz and SCS=60kHz, the test point may be defined using RB_start=7 and L_CRB=17 for CP-OFDM, and using RB_start=8 and L_CRB=16 for DFT-s-OFDM.\nActions: To TSG RAN WG5: RAN4 asks RAN5 to take the above information into account when developing the test specifications for NS_50 A-MPR for PC2.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":200,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NR_UE_PC2_n39-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_98_Athens\/Docs\/R5-230020.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230021","title":"LS on FR2 SEM test time reduction","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"RAN4 has discussed the potential applicability of an EIRP-based test metric for FR2 SEM verifications to reduce test time. The background behind is the following approximation relation between the SEM TRP and the intended EIRP-based test metric which has been discussed based on Lab measurement data [1].\nSEM_TRP ? SEM_Peak EIRP \u2013 (PUMAX \u2013 PTMAX)\nThe method is to verify by only measuring SEM in beam peak direction and subtracting the power difference between maximum peak EIRP (PUMAX) and max TRP (PTMAX) of the wanted signal.\n\nIn addition to EIRP-based test metric, RAN4 also discussed a coarse TRP method for reducing the FR2 SEM test time [2], similar to the methodology already used by RAN5 for the spurious emission test case.\n\nWhile RAN4 sees the benefit of an improved test time by applying the EIRP-based test metric or coarse TRP for FR2 SEM verifications, the decision on the proposed test metric is left to RAN5 with the consideration of testability and the impact on MU\/TT.\nActions: To: 3GPP TSG RAN WG5: RAN4 asks RAN5 if improving test time is essential, and if so, whether a metric change is needed or the coarse TRP method can be utilized.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":210,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":[{"winame":"NR_newRAT-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_98_Athens\/Docs\/R5-230021.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230022","title":"Reply LS on ModifiedMPR-Behaviour clarification for different power classes","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN4 thanks RAN5 for clarification questions on ModifiedMPR-Behaviour for different power classes.\nApart from the previous reply in R4-2215091, RAN4 made further conclusion for the remaining questions as follows:\nQuestion c) For Rel-16 PC3 UE, is the MPR as defined in 38.101-2 v16.2.0 mandatory or optional? In case it is mandatory then is the Rel-16 UE expected to signal modifiedMPR-Behaviour bit 0=true?\nAnswer: For Rel-16 PC3 UE, the MPR as defined in 38.101-2 v16.2.0 is optional according to the current specification.\nQuestion d) For Rel-16 PC3 UE, which version of specification is taken as default MPR requirement, 38.101-2 v16.2.0 or latest version (v16.11.0 released in Apr 2022)? What are the Rel-16 MPR requirements if the UE signals respectively modifiedMPR-Behaviour bit 0=false and modifiedMPR-Behaviour bit 0=true?\nAnswer: For Rel-16 PC3 UE, default MPR is specified in 38.101-2 v16.1.0 and if UE signals modifiedMPR-Behaviour bit 0=true, UE shall support latest Rel-16 requirements unless new modified MPR-Behaviour bit is defined for the same requirement which the bit 0 relates to; if the bit is set to false, the PC3 UE just needs to meet the default MPR requirement.\nActions: To RAN5: RAN4 asks RAN5 to take the above feedback and agreed CRs [1][2] into account for the future work.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":220,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"NR_RF_FR2_req_enh-UEConTest"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_98_Athens\/Docs\/R5-230022.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230023","title":"LS on testability for beam correspondence in initial access","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Currently RAN4 is discussing beam correspondence requirement and the implications on testability aspects in initial access. It is found that UE beam lock function (UBF) is not available in initial access. Without UBF, it\u2019s unclear how to measure the PRACH transmit power from both polarizations. \nRAN4 would like to invite RAN5 to check the testability aspects for beam correspondence in initial access. e.g.  whether it is necessary to introduce the UBF function in initial access for simplification of the test (note that the beam used in initial access may be different from the beam in connected mode). If necessary but not feasible, RAN4 would also like to invite RAN5 to check if there is any other solution on testing the EIRP in initial access. e.g., for testing EIRP of Msg1. \nRAN4 would also like to know how to ensure P-MPR is set to 0 during the test.\nActions: To RAN2: RAN4 requests RAN5 feedback on the above question raised by RAN4.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":230,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"NR_RF_FR2_req_Ph3-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/TSG_RAN\/WG5_Test_ex-T1\/TSGR5_98_Athens\/Docs\/R5-230023.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230024","title":"LS to RAN5 on IMS Data Channel Profile","source":"GSMA TSG","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"GSMA NG UPG IDCTF has been working on GSMA PRD NG.134 profiling 3GPP TS 26.114 IMS Data Channels. The document is submitted to GSMA TSG#50 for information and comments prior to being submitted for NG#17 approval in 2023Q2. \nThere are no further technical changes expected to PRD NG.134 between TSG#50 (November, 2022) and NG#17(April, 2023) when the document will go for approval. \nGSMA PRD NG.134 defines the minimum mandatory set of features that a User Equipment (UE) and network are required to implement in order to guarantee interoperable, high quality end to end IMS-based communication services for IMS data channel over LTE (Long Term Evolution) radio access to EPC and NR (New Radio) access connected to 5GC.\nAs 3GPP RAN5 is the Conformance Testing Group for User Equipment (UE), NG.134 may be of 3GPP RAN5 interest.\nActions: To 3GPP RAN5 group: GSMA TSG requests 3GPP RAN5 to take the information above into account.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":240,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","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_98_Athens\/Docs\/R5-230024.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230025","title":"OTA LTE UE TRP and TRS Requirements","source":"GSMA TSGAP","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"GSMA would like to inform you that in the latest version of TS.24 the 5G OTA antenna requirements have been defined. \nThose requirements cover NSA (Non-Stand Alone) and SA (Stand Alone) modes. Furthermore, device power class 3 and power class 2 have been considered.\nHowever, the current requirement is only covering 5G FR1 frequency range (410 MHz -7125 MHz).\nThe attached document is the new version of TS.24 (V5.0) which was approved in GSMA TSG#49  September meeting.\nTS.24 v5.0 has been uploaded to the GSMA Website here:\nhttps:\/\/www.gsma.com\/newsroom\/resources\/ts-24-v-5-0\/","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":250,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-01-25 20:37:05","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_98_Athens\/Docs\/R5-230025.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230026","title":"LS to 3GPP RAN WG4 on NR TRP and TRS requirements","source":"ETSI TC MSG\/TFES","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"ETSI TC MSG\/ERM TFES is responsible to set TRP and TRS limits for LTE and NR in European markets as captured by EN 301 908-13 and EN 301 908-25, respectively. \nCurrently EN 301-908-13 contains BHH (Beside Head and Hand) LTE TRP and TRS requirements for devices with width between 56 mm and 72 mm. However, BHH LTE and NR requirements for devices wider than 72 mm and narrower than 92 mm are still absent.\nBHH mode is important for European markets, especially for emergency calls, which are legal requirements for operators.\nTherefore, ETSI TC MSG\/ERM TFES would like to know the schedule of 3GPP RAN WG4 for BHH NR TRP and TRS requirements, including VoNR (Voice over NR), for devices wider than 72 mm and narrower than 92 mm and would suggest to prioritize them if those requirements cannot be completed by the end of 2023.\nTC MSG\/ERM TFES looks forward to further cooperation with 3GPP RAN WG4 on this matter.\nActions: ETSI TC MSG\/TFES ask 3GPP TSG RAN to consider the above information, and to provide status of related standardization work and prioritize them if necessary.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":260,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-02-16 15:56:30","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_98_Athens\/Docs\/R5-230026.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230027","title":"LS to 3GPP on ECC request for standardisation support related to ECC Decision (22)07 on \u201charmonised framework on aerial UE usage in MFCN harmonised bands\u201d","source":"ETSI TC MSG\/TFES","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":270,"status":"noted","reservation_date":"2023-01-17 19:50:15","uploaded":"2023-02-16 15:56:30","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_98_Athens\/Docs\/R5-230027.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-230028","title":"LS Reply to NGMN on 5G Smart Devices Supporting Network Slicing","source":"GCF SG","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"GCF would like to thank NGMN for sharing the publication of the White Paper NGMN-GTI joint White Paper \u201cPre-Commercial Network Slicing Trials Major Conclusions\u201d.\nFor GCF to add Network Slicing testing to its certification scheme it is required that a test specification (pass\/fail criteria) is available. GCF\u2019s current understanding is that:\na. Due to difficulties in using live networks for Service Capability testing, GCF would agree with NGMN and recommend the development of test platform(s) for conformance related testing.\nb. The test procedures (not test cases) have been defined by 3GPP RAN5 in TR 38.918 which was formally published in June 2022. These Test Procedures cover Service Level Signalling (Annex A.2) and Performance (Annex A.3).\nc. Network Slicing Service Level Signalling requirements and Performance requirements are outside the scope of 3GPP, so no core requirements have been specified by 3GPP, hence RAN5 cannot define conformance test cases with pass\/fail criteria for these. So RAN5 will not have the mandate to define conformance test cases now or any time in the future.\nTo progress with certification in GCF, the test requirements must be completed and published by a recognised SDO. As an example, NGMN may consider approaching GSMA TSG requesting them to develop the relevant test cases and test criteria for Network Slicing.\nGCF looks forward to continuing to work with NGMN in the future.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":280,"status":"noted","reservation_date":"2023-01-17 19:50:16","uploaded":"2023-02-17 14:54:32","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_98_Athens\/Docs\/R5-230028.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-231389","title":"LS on CTIA Certification OTA Performance Test Plan Version 5.0 Publication","source":"CTIA Certification OTA Working Group","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"CTIA Certification has released the Test Plan for Wireless Device Over-the-Air Performance\nVersion 5.0 in December 2022.\nDiscussion\nOne year ago, the restructured OTA Test Plan Version 4.0 was released to support the expansion\nof the CTIA Certification OTA test scope to accommodate new airlink technologies, new operating\nbands, new test methodologies, new device types, new phantoms, etc.\nCTIA Certification is pleased to announce that the next major revision of the Test Plan for\nWireless Device Over-the-Air Performance Version 5.0 which include the following documents\nwas released in December 2022 (available to download at https:\/\/ctiacertification.org\/test-plans\/).\nSome of the new features and test requirements introduced in Version 5.0 are as follows:\n? Test reduction of LTE when NR SA is supported\n? Extended testing in reverberation chambers to include Category M1 and Category NB1\ndevices\n? GNSS testing\no Standalone GPS L5 (informative)\no Updated EN-DC A-GNSS testing to add GPS L5 and GALILEO E1\no NR SA A-GNSS (including GPS L1 and L5 and GALILEO E1)\no Test Time Reduction for A-GNSS OTA with LTE and NR\n? Support of ankle-worn devices on the new ankle phantom (informative)\n? Fast TIS category of measurements targeting IoT devices\n? Option for Receive Signal Strength (RSS) pattern measurements for single receiver\ndevices for test time reduction\n? Addition of bands:n12, n14, n26, n30, n48, n77\n? Updated TRP and C-TIS test parameters for NR FR1 to maintain comparable results with\nLTE and to allow for better antenna performance evaluation across the operating band\no RF Channel BW\n? FDD: 10 MHz, SCS=15kHz\n? TDD: 20 MHz, SCS=30kHz\no TRP\n? Utilize 12 RB UL allocation (RBstart=6, 20, 34) for FDD\n? Utilize 9 RB UL allocation (RBstart=4, 21, 38) for TDD\n? Allows for common UL Tx BW with LTE while maintaining MPR=0dB and\nlow and high allocations closer to band edges\no C-TIS (equivalent to TRS in 3GPP)\n? Utilize full downlink allocation\n? Allows for comparable C-TIS results with LTE\nThe mandatory date for each test methodology has not been finalized\/defined yet as the\ndevelopment of the System Validation Documents (SVDs) and Laboratory Authorization\nDocuments (LADs) is still in progress.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":138900,"status":"noted","reservation_date":"2023-09-03 17:25:07","uploaded":"2023-03-09 17:31:07","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_98_Athens\/Docs\/R5-231389.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-231400","title":"Reply LS on Network selection for specific consumer type mobiles","source":"TSG WG SA1","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"late LS\nSA1 thanks CT1 for forwarding the LS from GCF-CAG and would like to provide SA1\u2019s views and answers to the questions raised by GCF-CAG. \nSA1 would like to confirm there is a requirement mandating Manual Network selection mode for all UEs (3GPP TS 22.011 clause 3.2.1): \nThe UE shall support both manual and automatic network selection mechanisms (modes).\nSA1 does not currently have any exceptions to this requirement for wearables.\nActions: To CT1, GCF-CAG: SA1 asks CT1 and GCF-CAG to take the above answer into account.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"\tIncoming Liaison Statements","tdoc_agenda_sort_order":140000,"status":"noted","reservation_date":"2023-09-03 17:25:10","uploaded":"2023-03-09 17:31:07","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_98_Athens\/Docs\/R5-231400.zip","group":"R5","meeting":"R5-98","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0}]