[{"name":"R5-232040","title":"Reply LS from CT6 to review mandate of the implementation of UI\/MMI features for Wearable form factor.","source":"TSG WG CT6","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"3GPP CT WG6 thanks GCF-CAG for its LS to review mandate of the implementation of UI\/MMI features for wearable form factors.\nThe LS request the following to 3GPP CT WG6 for consideration:\n\u201cThere should be a mechanism available for OEMs to disable certain features (that are not practical to implement for certain form factors such as wearables) and therefore have an option to leave it disabled in USIM\/USAT test specification\"\n3GPP CT WG6 would like to clarify the following.\ni.\t3GPP TS 22.011 Section 3.2.1 (responsibility of 3GPP SA WG1) mandates the UE to support both manual and automatic network selection (modes).\nii.\tPer, 3GPP TS 31.111 (Section 5.2) and ETSI TS 102.223 (Section 5.2), there is a provision to handle devices with limited UI\/MMI features. Terminal Profile bit(s) can be set accordingly to reflect the CAT facilities that are supported by the terminal. Example, for certain class of devices with 'no display capability (class ND)', or devices with 'no keypad capability (class NK) 'the Terminal Profile bits can be set accordingly. \niii.\tFurther, the necessity to run related conformance tests from 3GPP TS 31.124 (USAT test specification) becomes optional when the device manufacturer declares the support of possible options in table A.1 of 3GPP TS 31.124 (Section 3.3) for the device under test. For example - Terminal support of display capability (O_No_Type_ND), Terminal supports keypad (O_No_Type_NK) can be disabled if not supported by the wearable device.\nACTION: \t3GPP CT WG6 asks GCF-CAG to take above into account.","secretary_remarks":"LS R5-206259 on failing initial registration without Retry-After header field from RAN4","agenda_item_sort_order":5,"ainumber":"3","ainame":"Incoming Liaison Statements","tdoc_agenda_sort_order":20400,"status":"noted","reservation_date":"2023-04-19 16:00:17","uploaded":"2023-04-19 16:57:04","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_99_Incheon\/Docs\/R5-232040.zip","group":"R5","meeting":"R5-99","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-232042","title":"Reply LS to ETSI TC MSG\/TFES on NR TRP and TRS requirements","source":"TSG WG RAN4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"3GPP RAN4 thanks ETSI TC MSG\/TFES for the LS (R4-2300042\/TFES(23)074029) on NR TRP and TRS requirements.\n3GPP RAN4 is responsible to define OTA requirements and testing methods for UE. \nFor the standardization work of BHH (Beside Head and Hand) NR TRP and TRS, the test parameters for FR1 bands and permitted test method have been specified in the latest 3GPP specification TS 38.161 v17.1.0 [1]. However, the corresponding FR1 BHH requirements have not been finalized in RAN4. \nAfter the successful completion of Rel-17 NR FR1 TRP TRS WI, a new Work Item on Rel-18 FR1 TRP TRS enhancement was approved in RAN#97-e meeting, the objectives are listed in the latest WID [2]. In Rel-18, RAN4 will specify handheld UE requirements, for devices wider than 72 mm and narrower than 92 mm as the first priority. RAN4 has decided to work on requirements for both browsing mode (hand phantom only) and talk mode (Beside Head and Hand), and the requirements for both browsing mode and talk mode will be introduced together per band. \nThe workplan for Rel-18 FR1 TRP TRS WI was approved in RAN4#104bis-e meeting, the completion of requirements targets to RAN4#111 meeting, May 20-24, 2024.\n3GPP RAN4 looks forward to further cooperation with TC MSG\/ERM TFES on NR FR1 TRP TRS work.\n2\tActions\nTo ETSI TC MSG\/TFES: \nACTION: \t3GPP RAN4 asks ETSI TC MSG\/TFES to take the above feedback into account.","secretary_remarks":"LS R5-206259 on failing initial registration without Retry-After header field from RAN5","agenda_item_sort_order":5,"ainumber":"3","ainame":"Incoming Liaison Statements","tdoc_agenda_sort_order":20420,"status":"noted","reservation_date":"2023-04-19 16:00:17","uploaded":"2023-04-19 16:57:04","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_99_Incheon\/Docs\/R5-232042.zip","group":"R5","meeting":"R5-99","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-232044","title":"Reply to 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":"TSG RAN","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"TSG RAN thanks ETSI TC MSG\/ERM TFES for their LS informing of the ECC request for standardisation support on implementation in harmonised standard of relevant components of ECC Decision (22)07 on \u201charmonised framework on aerial UE usage in MFCN harmonised bands\u201d.\n\nTSG RAN discussed the issues raised in the LS and took the following actions:\n\u2022\tTo address the OOBE requirements listed in point a), a RAN4 objective was added to the Rel-18 NR UAV work item to study and specify the necessary UE types and OOBE requirements for protection of the referred frequency ranges from aerial UE emissions. The updated work item is attached in RP-230782.\no\tThe above referred Rel-18 NR UAV work item only addresses NR RAT. To address the same requirements for E-UTRA, a corresponding work item was agreed in RP-230783.\no\tAs ETSI TFES work on aerial UE is supposed to be based on the UE conformance testing specification from RAN5, related work is planned to be triggered once RAN4 completes its task in Q2 2023. \n\u2022\tFor requirements listed in points b), c) and d), RAN2 will in the existing Rel-18 NR UAV work item do further technical analysis of existing 3GPP specifications to verify if these three ECC requirements are already covered by the specifications. Depending on the outcome of the analysis, RAN will decide if additional work is needed in the working groups.\n\nTSG RAN will keep ETSI TC MSG\/TFES updated on the progress of the work.\n2. Actions: 3GPP TSG RAN asks ETSI TC MSG\/TFES to consider the above information.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"Incoming Liaison Statements","tdoc_agenda_sort_order":20440,"status":"noted","reservation_date":"2023-04-19 16:00:17","uploaded":"2023-04-19 16:57:04","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"NR_UAV"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ran\/WG5_Test_ex-T1\/TSGR5_99_Incheon\/Docs\/R5-232044.zip","group":"R5","meeting":"R5-99","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-232045","title":"LS Reply 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":"TSG WG SA2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"SA2 thanks ETSI TSG MSG\/TFES for the incoming liaison. SA2 has discussed the content and has the following comments.\n\nSA2 noticed the definition of aerial UE from ETSI TSG MSG\/TFES:\n\u201cAccording to this ECC Decision, an aerial UE refers to a UE supporting UAS features and services and requiring an aerial subscription. An aerial UE is installed either on-board an Unmanned Aircraft (e.g. drones) or on-board manned aircraft (e.g. helicopter). It identifies itself to the mobile network as being in this class.\u201d\nSuch definition goes beyond what 3GPP has considered before 3GPP release 17 that a 3GPP aerial UE is simply a UE with an aerial subscription. However, in release 17 SA2 has introduced the concept that a UE provisioned and configured to act as an Uncrewed Aerial Vehicle (UAV) in addition to having an aerial subscription shall also indicate it is a UAV by providing an application layer identifier (the CAA-Level UAV ID, assigned by the UTM, see 3GPP TS 23.256) before receiving aerial services from the 3GPP network. This allows the 3GPP network to obtain authentication and authorization for the UAV by the UTM. Moreover, since Release 15 the LTE RAN is informed of the UE aerial subscription, and a similar mechanism is being added to NG-RAN (NR) for release 18. As such, SA2 believes that 3GPP specifications from release 17 already supports Uncrewed Aircraft (i.e., the 3GPP term for Unmanned Aircraft) of the above definition. However, 3GPP specifications so far have not addressed Crewed Aircraft use cases.\nRegarding bullet points b, c, and d:\nb)\tmechanism\/feature coherent with the above aerial UE definition in order to differentiate aerial UE, as defined by ECC Decision 22(07) from terrestrial UE operating under LTE\/NR 5G networks \nSA2 believes that mechanisms from release 17 (for LTE) and from release 18 (for NR) will enable the differentiation as described in bullet (b).\n\nc)\tdifferentiation of aerial UE from other terrestrial UE shall not be changed by the end-user \nThough SA2 agrees that an aerial UE shall not be allowed to operate flight operations without indicating to the network that it is an aerial UE as per the ETSI definition, we recommend considering the scenarios we describe in relation to bullet (d) below.\n\nd)\tthe aerial UE shall not be capable to connect to LTE\/NR 5G networks without aerial subscription\nSA2 has discussed bullet (d) and understands that this is done to ensure the operation of actual aerial UEs in the correct frequencies to avoid the misuse of frequencies not allowed for aerial UEs. In 3GPP specifications before Release 17, it is not possible to enforce such requirement Since a UAV UE configured to behave as a UAV and with an aerial subscription, when not in flight, can connect as a regular UE to access services not related to UAV\/flight operations. However, since Release 17 the functionality exists for an operator to restrict specific bands for aerial UEs as defined by ETSI TSG, i.e. to only UEs that are provisioned and configured to act as a UAV in addition to having an aerial subscription.\n\n3GPP would like in addition for ETSI TSG MSG\/TFES to consider the following scenarios:\n-\tthe aerial UE while on the ground (i.e. not in a flying state) may need to perform operations not related to any flight missions, e.g. large media dump, software updates, etc.\n-\tcertain aerial UEs (e.g. robotic videocamera drones) may also perform surveillance operations on the ground without taking a flight (e.g. as surveillance cameras).\n[..]\nIn conclusion, 3GPP SA2 is of the opinion that most of the points raised by ETSI TC MSG\/TFES are already supported by release 17 standards.\n2. Actions: SA2 ask ETSI TC MSG\/TFES to take the above into account and in particular to consider the comments on the requirements in bullet (c) and (d).","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"Incoming Liaison Statements","tdoc_agenda_sort_order":20450,"status":"noted","reservation_date":"2023-04-19 16:00:17","uploaded":"2023-04-19 16:57:04","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"UAS_Ph2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_ran\/WG5_Test_ex-T1\/TSGR5_99_Incheon\/Docs\/R5-232045.zip","group":"R5","meeting":"R5-99","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-232048","title":"Non-Support of Ciphering Algorithm GEA2","source":"GCF SG","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"GCF has implemented relevant certification criteria to ensure that Mobile Stations do not support GEA2 if they are REL-16 and higher. GCF has also implemented transparency in their Certification Declaration to indicate which of the UEs of REL-15 and earlier do support GEA2.\nUnfortunately, there are still quite a number of UE certifications which indicate implementation of GEA2.\nIdentically to GEA1, the GPRS ciphering algorithm GEA2 is known as being not secure since many years, but we experience that an unacceptably high number of devices are being GCF certified supporting GEA2 which have a pre-REL-16 GPRS implementation. Instead of a decrease we can see from the product statistics even a significant increase (almost double!) of devices certified with support of GEA2!\nGCF understands that making use of the compromised ciphering algorithms in Mobile Stations is diluting the integrity of the 3GPP radio technologies, being known as very secure all over the world, and GCF would like to support 3GPP in abandoning such security leaks.\nHowever, current 3GPP specifications still allow pre-REL-16 Mobile Stations to implement GEA2, and for REL-6\u2026REL-10 Mobile Stations, GEA2 is even a mandatory feature!\nGCF SG has already agreed in principle at their meeting #94, 28-30 March 2023, that from GCF-CC Version 3.90 onwards (July 2023), devices can only be certified which do not support GEA2, irrespective of their implemented 3GPP Release.\nIt is not desirable that GCF applies stronger or even contradicting certification criteria than outlined in the related 3GPP standards. In order to fully prevent implementation of insecure ciphering algorithms, GCF would like to request 3GPP SA WG3 to explicitly prohibit support of GEA2 in all releases of TS 43.020. GCF would also like to request 3GPP RAN5 to remove mandatory status of GEA2 in 3GPP Conformance Test Specifications with immediate effect.\n\nActions\n3GPP SA3: To explicitly prohibit support of GEA2 in all releases of TS 43.020.\n3GPP RAN5: To remove mandatory status of GEA2 in 3GPP Conformance Test Specifications with immediate effect.","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"Incoming Liaison Statements","tdoc_agenda_sort_order":20480,"status":"noted","reservation_date":"2023-04-19 16:00:17","uploaded":"2023-05-26 18:11:11","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_99_Incheon\/Docs\/R5-232048.zip","group":"R5","meeting":"R5-99","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"R5-232049","title":"NR Bandwidth for OTA TRS testing","source":"GSMA TSGAP","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"GSMA TSG Antenna Performance sub group, has been informed about progress of 5G NR OTA WI  for FR1 in 3GPP RAN 4\nThe GSMA TSGAP has concerns on the test configuration defined for TRS (TIS) since only 100 MHz is used as the Channel Bandwidth for n78. GSMA TSGAP understands that 20 MHz is more appropriate to be used as CBW for test purposes. \nUsing 20 MHz as CBW will allow 5G NR test results to be compared with LTE test results which are already tested with 20MHz. \nOther NR bands may only support 20 MHz so it would be appropriate to test all band with same configuration. \nGSMA TSGAP would like to inform 3GPP RAN 4 and RAN 5 that both CTIA and GSMA have adopted the use of 20 MHz channel bandwidth for TRS testing  in  high and mid bands ( e.g. n78) and 10 MHz in low bands ( e.g. n28) .   \n2\tAction \nGSMA TSGAP would like to kindly ask 3GPP RAN4 to update their test specs to include the TRS with 20MHz and 10MHz  CBW as described above","secretary_remarks":"","agenda_item_sort_order":5,"ainumber":"3","ainame":"Incoming Liaison Statements","tdoc_agenda_sort_order":20490,"status":"noted","reservation_date":"2023-04-19 16:48:24","uploaded":"2023-04-19 16:57:04","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_99_Incheon\/Docs\/R5-232049.zip","group":"R5","meeting":"R5-99","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0}]