[{"name":"S5-254231","title":"Reply LS on specification of dataset and model parameters exchange","source":"SA5","contact":"Hassan Al-kanani","contact-id":47274,"tdoctype":"LS out","for":"Approval","abstract":"NEC\nSA5 thanks RAN for the incoming LS on specification of dataset and model parameters exchange.\nSA5 recalls that it has already provided an initial reply on this topic in Rel-19 (S5-254083\/RP-251920 in response to R2-2503169\/S5-253287), confirming that non-OTA approaches involving OAM may be feasible subject to further evaluation.\nFurther to the discussion during SA#109, SA5 would like to confirm that the investigation of dataset and model parameter exchange, as highlighted by RAN2, is already planned as part of the ongoing Rel-20 Study on AI\/ML management phase 3 (SP-250867, WT-1.1, items 1 and 5).\nSA5 plans to coordinate with SA2, RAN1 and RAN2 on the progress of their investigation and will keep both SA and RAN updated.\n2\tActions\nTo SA and RAN:\nACTION: \tSA5 kindly asks SA and RAN to take the above information into consideration and keep SA5 informed of any updates or requirements.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":42310,"status":"revised","reservation_date":"2025-09-30 16:45:30","uploaded":"2025-10-03 19:45:10","revisionof":"","revisedto":"S5-254791","release":"Rel-20","crspec":"","crspecversion":"","workitem":[{"winame":"FS_AIML_MGT_Ph3"},{"winame":" NR_AIML_air-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA, RAN, RAN2","Cc":"SA2, RAN1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254231.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254232","title":"Reply to LS on a new measurement related to the maintainability of a QoS flow","source":"SA5","contact":"Qiang Zu","contact-id":42296,"tdoctype":"LS out","for":"Approval","abstract":"Ericsson, Verizon\nSA5 thanks SA2 for the incoming LS on a new measurement related to the maintainability of a QoS flow (S2-2508116). SA5 has been requested to monitor and capture statistics of downgraded QoS flows, and to consider adding a QoS Maintainability measurement at the QoS flow level. Such a measurement would reflect the probability of experiencing any type of QoS degradation while the QoS flow is in use.\nSA5 has studied the request and has following considerations.\n\u2022\tDefining \"downgraded QoS flows\": The term is not defined. However, the definitions in TS 23.501 clause 5.7.1.2a and clause 5.7.2.4, with respect to the GFBR, PDB, and PER of the QoS profile, could be used to progress the SA5 work on defining performance measurements and KPIs for QoS flows fulfilment. \n\u2022\tQoS flow monitoring at gNB: \no\tThe gNB currently measures \n?\tNumber of QoS flow failed to setup (see section 5.1.1.13.3.3 of TS 28.552): This measurement indicates that one or more QoS flows could not be fulfilled at PDU session establishment. It applies to transmission of PDU SESSION RESOURCE SETUP RESPONSE, INITIAL CONTEXT SETUP RESPONSE, or PDU SESSION RESOURCE MODIFY RESPONSE messages.\n?\tNumber of Initial QoS flow failed to setup (see section 5.1.1.13.3.6 of TS 28.552): This measurement indicates that one or more QoS flows could not be fulfilled at UE context establishment. It applies to transmission of INITIAL CONTEXT SETUP RESPONSE message.\n?\tNumber of QoS flows failed to modify (see section 5.1.1.13.4.3 of TS 28.552): This measurement indicates the QoS modification failure, e.g. an alternative QoS profile (from the list in SMF config) reflects currently achieved QoS level. It applies to transmission of PDU SESSION RESOURCE MODIFY RESPONSE message.\no\tNew measurements could be added: Number of QoS flows fulfilment and non- fulfilment notification (see attached CR). Those measurements would capture RAN-initiated QoS modification cases where active QoS flows are not fulfilled (partially or fully lost) and are fulfilled to a level as described by a referenced less preferred alternative. It applies to the transmission of PDU SESSION RESOURCE NOTIFY messages.\no\tThe above measurements can indicate QoS non-fulfilment or fulfilment with an alternative profile, but they do not necessarily show whether the fulfilment constitutes a downgrade.\n\u2022\tQoS flow KPI: The existing QoS Flow Retainability KPI specifies the frequency of abnormal, premature flow release. It seems to be beneficial for QoS Sustainability analytics to introduce a KPI that captures how often the performance for an end-user QoS non-fulfilment from the agreed QoS requirements of a QoS flow occurred during the time of the QoS flow is used.\nSA5 has discussed and agreed on the attached proposed changes related to QoS flow fulfilment performance measurements and QoS Flow Maintainability KPI. SA5 kindly asks SA2 to assess whether these proposed changes could meet SA2\u2019s requirements. \n2\tActions\nTo SA2\nACTION: \tSA5 kindly asks SA2 to assess whether the measurements specified by SA5 address SA2\u2019s requirements, and to provide any feedback.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":42320,"status":"revised","reservation_date":"2025-09-30 19:05:55","uploaded":"2025-10-03 15:59:11","revisionof":"","revisedto":"S5-254627","release":"Rel-19","crspec":"","crspecversion":"","workitem":[{"winame":"PM_KPI_5G_Ph4"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA2","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254232.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254316","title":"Reply LS on UE type identification for UAS charging requirements","source":"CT3","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"3GPP CT3 thanks SA5 for the LS on UE type identification for UAS charging requirements. CT3 would like to answer to the question as below. \n\nSA5 Question:\nAccording to TS 23.256, a UAV that is configured for UAS services (i.e. is provisioned with a CAA-Level UAV ID) registers to the 3GPP system for UAS services and provides the CAA-Level UAV ID and a UUAA Aviation Payload to 5GS or EPS. As defined in TS 24.501, the CAA-Level UAV ID is provided to 5GC with the value of service-level device ID setting to the CAA-Level UAV ID.\nConsidering the above information and charging requirements, SA5 has the following question:\nIs there any attribute already defined in Rel-19 CT specifications indicating AMF and SMF that a UE is a UAV UE or is using UAS services?\n\nCT3 Answer:\nFor CT3 part of the specifications, there is no definition that can identify the UE is a UAV UE or is using UAS services (e.g. via Network Exposure, Session Management Event Exposure, etc.). CT3 would inform that it defers to CT1 and CT4 specifications.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":[{"winame":"UAS_Ph3-CH"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"C3-253539","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254316.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254317","title":"Reply LS on UE type identification for UAS charging requirements","source":"CT4","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"3GPP CT4 thanks SA5 for the LS on UE type identification for UAS charging requirements. CT4 would like to answer to the question as below. \n\nSA5 Question:\nAccording to TS 23.256, a UAV that is configured for UAS services (i.e. is provisioned with a CAA-Level UAV ID) registers to the 3GPP system for UAS services and provides the CAA-Level UAV ID and a UUAA Aviation Payload to 5GS or EPS. As defined in TS 24.501, the CAA-Level UAV ID is provided to 5GC with the value of service-level device ID setting to the CAA-Level UAV ID.\nConsidering the above information and charging requirements, SA5 has the following question:\nIs there any attribute already defined in Rel-19 CT specifications indicating AMF and SMF that a UE is a UAV UE or is using UAS services?\n\nCT4 Answer:\nThe UE supporting UAS services provides CAA-level UAV ID included in the Service-level-AA container IE to the AMF\/SMF during the registration procedure\/PDU session establishment procedure as described in clause 4.22 of 3GPP TS 24.501, Authentication and authorization of UAV. Accordingly, the AMF\/SMF can identify the UE is an UAV UE or requesting UAV services.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43170,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":[{"winame":"UAS_Ph3-CH"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254317.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254318","title":"LS on need for modeling isInvariant and SystemCreated in YANG","source":"IETF NETMOD WG","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"Body: 1. Description\n \nDear 3GPP TSG SA WG5,\nWe thank you for your LS [1] dated, 2023-03-09, explaining your desire and rationale for the IETF to standardize proposed \"IsInvariant\" and \"SystemCreated\" annotations for use with the YANG language.\n\nWe apologize for the slightly delayed response, but the NETMOD working group has been considering a solution in this area, which although it may not exactly meet your concerns (further details below), we believe that we have documents [2][3] that have progressed reasonably far through the IETF publication process and hence now would be a good time for members in your community to review and provide comments on them.\n\nThe proposed solution is two-fold: 1) a new datastore called <system>, that can document what configuration is system-defined and 2) a new metadata annotation called \"immutable\", that a server may return for <system> defined data, thus enabling clients to know when certain edit operations against immutable data may fail.\n\nRegarding 1.2.1 isInvariant:\n\nWe are not able to offer an exact solution for standardizing an \"isInvariant\" extension because of concerns that such an extension would end up breaking the transactional behavior of NETCONF and RESTCONF. I.e., to help keep programmatic network management clients simple, there is a very strong desire to always allow a client to migrate a devices state from any valid configuration to any different valid configuration as a single committed configuration change. Defining a flag such as \"isInvariant\" that forces clients to make configuration changes in multiple independent steps breaks this transactional behavior and adds complexity to the client. Instead, the solution that the WG would propose is that servers are implemented such that if it is necessary to delete and recreate an object when a field within that object is changed, that instrumentation should be performed automatically by the server and be invisible to the client.\n\nThis would, as your liaison indicated, potentially be a traffic impacting change, but it has been observed that many such changes are possible and supported in general network device configuration that has not previously required an 'invariant' behavior annotation or a break in transactional behavior. As you indicate, it has also been observed that some vendors do indeed have configuration that exhibits \"isInvariant\" style behavior, but NETMOD's goal here is that it would be more desirable to gradually migrate away from such behavior rather than standardize and encourage further proliferation of such behavior that introduces unnecessary complexities to automated management clients. Instead, it is assumed that clients can be designed and implemented so that they can manage such changes appropriately.\n\nHence the \"immutable-flag\" draft [3] defines a metadata attribute called \"immutable\" that can be used by a system to declare which configuration nodes it deems immutable.\n\nRegarding 1.2.2 SystemCreated Classes:\n\nThe system datastore defined in [2] provides a similar, but slightly different solution to the problem described by SystemCreated Classes in your LS. The NETMOD WG believes that that the \"system-config\" draft provides a solution for your problem, whilst preserving NETCONF\/YANGs transactional behavior in an NMDA [4] compliant manner.  Specifically, the solution defines a new NMDA datastore called \"system\", where system-defined nodes may be declared.  \n\nThe NETMOD WG asks 3GPP TSG SA WG5 to review and provide comments on these solutions. We encourage the use of the NETMOD WG mailing list [5] as the most effective and expedient way to provide comments.\n\nKent and Lou, NETMOD chairs, on behalf of IETF NETMOD Working Group","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43180,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254318.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254319","title":"LS on Invitation to update the information in the IMT-2020 and beyond roadmap","source":"JCA-IMT2020","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"The ITU-T Joint Coordination Activity for IMT2020 and Beyond (JCA IMT2020) thanks all that have replied to previous requests for input on IMT-2020 and beyond related standardization work. The current online version of the roadmap is available from the JCA-IMT2020 website. \nThe objective of the roadmap is to support IMT-2020 and beyond standardization coordination. IMT-2020 and beyond are the important topics for our industry, and many standardization-related activities are held in various entities. \nThe JCA is progressing this work in a form of roadmap of IMT2020 and beyond standardization.\nJCA-IMT2020 will keep updating this roadmap, and therefore we solicit your information about updates. If you send us the latest information of your activity related to IMT-2020 and beyond as well as Network Function Virtualization (NFV), programmable networks, self-managed networks, autonomous network, slicing (including orchestration and capability exposure), fixed-mobile and satellite convergence (FMSC) and Information-Centric Networking (ICN), digital twin network, AI\/machine learning and other activities that are strongly related to IMT 2020, we will reflect it in the next roadmap update, which will be performed online soon after the next JCA IMT2020 meeting. Also, if you have IMT-2030 related work, please kindly send us the information.\nPlease submit your updates using the template to be found in appendix below. In the last column of this template we expect to get a direct pointer to your document and not to the website where one needs to search for your document. Should you wish to communicate any additional information about your specifications and projects, we invite you to do so. If you have a representative that wishes to present at an upcoming JCA-IMT2020 meeting, please let us know. \nIn addition, if not done yet, we invite the ITU-T Study Groups, SDOs, fora to nominate a representative to this group. \nJCA-IMT2020 anticipates having its next meeting on 29 October 2025, 13:00 - 14:30, alongside the ITU-T SG13 meeting (28 October \u2013 6 November 2025) in Tashkent, Republic of Uzbekistan. We invite your inputs\/updates to the roadmap.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43190,"status":"postponed","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254319.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254320","title":"LS on \"\"IETF Network Slice Application in 3GPP 5G End-to-End Network Slice\"\"","source":"IETF Traffic Engineering Architecture and Signaling Working Group (teas)","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"As a follow-up to the liaison statement [1] that was posted on 2023-10-09, the IETF TEAS WG [2] would like to inform 3GPP about the progress of \"IETF Network Slice Application in 3GPP 5G End-to-End Network Slice\" [3], an informational document that is almost ready for Working Group Last Call. This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control, and data planes.\n\nThe following is the mailing list where discussions related to these documents take place [4].\n\n2. Actions\n\nThe TEAS WG would like to request 3GPP to review the document and verify if the description of the 3GPP 5G End-to-End Network Slice is accurate, and if not, to kindly provide suggested clarifications. The TEAS WG would like to request that feedback on this be provided in an LS by the deadline. The TEAS WG also encourages the use of the TEAS WG mailing list for individuals to send comments, raise concerns, and seek clarification on the document.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43200,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254320.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254321","title":"LS on new GSMA OPG PRDs publication and changes to PRD OPG.02","source":"GSMA OPG","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"The GSMA OPG wishes to inform 3GPP and ETSI about significant and transformative updates to the requirements and architecture document (PRD OPG.02). In our latest revision, we have made a strategic decision to distinctly separate the generic platform requirements from those tailored for specific services, such as Edge. This reformulation led to a streamlined and focused PRD OPG.02 specification, where we meticulously restricted and extracted content to ensure that related information was clearly documented in the appropriate documents.\nThe following documents have been updated: \n\u2022\tOPG.02 Operator Platform: Requirements and Architecture version 9.0, available at gsma.com. The new version of the requirements and architecture for the Operator Platform contains the following changes:\n\u2022\tRouting to and from aggregators and separation of actors and architectural functions by covering the grouping and dependencies between those functions.\n\u2022\tAll edge related requirements were removed and moved to the new document OPG.11.\n\u2022\tAll other network service requirements were removed and moved to the new document OPG.12.\n\u2022\tNew document OPG.11 Requirements for Edge Services version 1.0, available at gsma.com. \n\u2022\tThis specification is dedicated to the Edge Services utilising the Operator Platform. The use cases, deployment scenarios, service flows, platform and interface requirements to support edge services were moved from GSMA PRD OPG.02 into this new document. \n\u2022\tThe Annex mapping these requirements into external fora, such as ETSI and 3GPP, has also been moved.\n\u2022\tNew document OPG.12 Requirements for Network as a Service version 1.0, available at gsma.com. \no\tThis specification is dedicated to the Network as a Service (e.g. network slicing) utilising the Operator Platform. The use cases, platform and interface requirements to support NaaS were moved from GSMA PRD OPG.02 into this new document. \nThe GSMA OPG wishes to inform that new versions of PRDs OPG.04 and OPG.09 were published as well. The former introduces capabilities for subscribing to and retrieving application-level events as well as to manage application-level and operation-level policies across OPs. The latter aligns more with the CAMARA Fall 24 Meta Release and provides guidance on further APIs: Location Verification, Device Geofencing, Call Forwarding Signal and Connectivity Insights. It also enhances the guidance provided on the APIs already covered in the previous version of the document and provides more details on the authentication and authorisation and the error handling.\nActions to \nGSMA OPG believes that the changes above may require updating references in the 3GPP and ETSI documents. Thus, we kindly ask 3GPP and ETSI to consider the changes in the above GSMA documents.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43210,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254321.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254323","title":"Reply LS on Logged Data Handling During Handover","source":"RAN3","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN3 thanks RAN2 for their LS on handling of Logged Data during Handover.\nRAN3 will not work on this aspect in Rel-19.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":[{"winame":"NR_AIML_air-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R3-255824","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254323.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254324","title":"Reply LS on MBS Communication Service Type","source":"RAN3","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN3 thanks SA4 for their reply LS on MBS Communication Service Type in S4-251096\/R3-255028. RAN3 has several follow up questions.\nRelated to the definition of the value \u2018all\u2019 of @communicationServiceType, SA4 indicates in their answer 1: \u201cOption 1 is the right interpretation.  It refers to all communication service types (not limited to MBS communication services).\u201d (Option 1: Value \u201call\u201d means that the UE shall conduct QoE measurements on broadcast, multicast and unicast.)\nQuestion A: In the CR to TS 26.247 agreed by SA4 in S4-251095, in the description of the @communicationServiceType attribute, it is stated that \u201cWhen present, this attribute indicates a list of communication service type(s) for which the QoE collection and reporting of QoE metrics is requested and shall contain one or more of the following values:\u201d. Regarding the \u201cone or more\u201d part, RAN3 would like to point out that, for a QMC configuration, only one communication service type is possible at a time. This effectively means that the \u201cor more\u201d should be deleted from the Description field of the attribute. RAN3 kindly asks SA4 to confirm this.\nQuestion B: In line with the above, a given QoE Reference can, in RAN3 specifications, only point to a single communication service type, and a combination of two or more communication service types in a single QMC configuration is therefore not supported in RAN3 specifications. This means that the value \u201call\u201d should be deleted from the @communicationServiceType attribute. RAN3 kindly asks SA4 to confirm this.\nRAN3 observes in SA4\u2019s answer 2 that \u201c\u201cOD\u201d is revised into \u201cO\u201d in TS 26.247\u201d. However, the CR to TS 26.247 agreed by SA4 in S4-251095 states: \u201cWhen absent, quality metrics collection is requested for all communication service types.\u201d\nQuestion C: Whether the @communicationServiceType can have a default value even though the Use is \u201cO\u201d? If the answer is \u201cno\u201d, RAN3 kindly asks SA4 to remove the following sentence from the Description field of the attribute: \u201cWhen absent, quality metrics collection is requested for all communication service types.\u201d. If the answer is \u201cyes\u201d, RAN3 kindly asks SA4 to confirm whether the default value can be \u201cunicast\u201d because the RAN3 specifications do not support combinations of two or more communication service types in a single QMC configuration.\nRAN3 assumes that the Rel-17 UE can perform QoE measurement collection and reporting only for unicast communication service. \n2. Actions:\nTo SA4: \tRAN3 kindly asks SA4 to take the above into account, provide answers to the questions above, and, if feasible update their specifications accordingly.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"replied to","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"NR_QoE_enh-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R3-255896","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254324.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254325","title":"LS on geographical area scope MDT","source":"RAN3","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"RAN3 has completed SON\/MDT for NTN work. For NTN, RAN3 has agreed to support geographical area scope for both logged and immediate MDT. More specifically, RAN3 has agreed that the geographical area scope for MDT can include a geographical area and optionally a PLMN ID list. The PLMN ID list allows the operator to collect data in specified PLMN(s) in that geographical area.\n2\tActions\nTo RAN2 and SA5:\nACTION: \tRAN3 kindly asks RAN2 and SA5 to take the above into consideration and to update their specifications according to RAN3 signaling design as captured in TS 38.413, if needed.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":[{"winame":"NR_ENDC_SON_MDT_Ph4-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"R3-255960","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254325.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254326","title":"LS on specification of dataset and model parameters exchange","source":"TSG RAN","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"RAN has received LSs from SA2 and SA5 in RP-251919 [1] and RP-251920 [2], respectively.  \n\nRAN would like to clarify that the request from RAN2 on feasibility of dataset\/model parameter exchange is for Rel-20, not for Rel-19. \n\nAfter discussing these LSs, RAN would like to further provide SA with the information included in the Actions. \n\n2.\tAction: \nTo SA, Cc: SA2, SA5\n\nAction: RAN respectfully asks SA to coordinate the completion of the study of dataset \/ model parameter exchange in Rel-20 in SA2 and SA5 and provide information to RAN#110 if feasible.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"Rel-20","crspec":"","crspecversion":"","workitem":[{"winame":"NR_AIML_air_Ph2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"RP-252966","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254326.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254327","title":"Reply LS on signalling feasibility of dataset and parameter sharing","source":"SA2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"SA2 thanks the LS on signaling feasibility of dataset and parameter sharing and provides feedback on the following RAN2\u2019s assumption on non-OTA solutions:\n-\tFor non-OTA approaches, i.e., \u2018NW dataset\/model parameters collection entity -> UE training entity (a server inside MNO or an OTT server)\u2019, RAN2 identified the following candidate solutions (see below Table 1).  From RAN2 point of view, it is assumed they can be supported within Rel-19 existing architecture framework. RAN3, SA2, and SA5 can further confirm the above RAN2 assumption.\n\nSA2 Feedback:\n-\tSA2 would like to inform RAN2 that the Rel-19 specifications do not support \u201c(gNB) -> CN -> UE-side training entity\u201d. Note that Rel-19 is frozen for SA2. The Rel-19 architecture provides exposure capabilities, which may still need to be enhanced depending on requirements.\n\u2022\tTo study non-OTA candidate solutions, SA2 would appreciate any further information from RAN2\/ RAN1\/RAN plenary on the requirements. The decision on whether to have study is also subject to SA\/SA2 planning.\n-\tSA2 would like to ask RAN2 about the difference between option 3 and the other two options. In particular, how option 3 (gNB -> OAM\/CN -> UE-side training entity) and option 2 (CN -> UE-side training entity) are different from the CN entity perspective?\n\n2. Actions:\nTo RAN2 \nACTION: \tSA2 kindly asks RAN2 to take the above feedback into account.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":[{"winame":"NR_AIML_air-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"S2-2508104","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254327.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254328","title":"LS for a new measurement related to the maintainability of a QoS flow","source":"SA2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"In TS 23.288 clause 6.9, QoS Sustainability Analytics can provide analytics information regarding the potential QoS change statistics for an Analytics target period in the past in a certain area or the likelihood of a QoS change for an Analytics target period in the future in a certain area.   The consumer of this analytics provides reporting threshold(s) to indicate the conditions on the analytic level for triggering the reporting. In other words, when the analytics result crosses the threshold of the expected QoS KPI, a report is triggered.\n\nAs indicated in TS 23.288 clause 6.9.1, for a GBR flow, the reporting threshold(s) refers to the QoS flow Retainability KPI. In other words, the sustainability of the flow is determined by a threshold related to how often the end user abnormally loses the QoS flow during the time the QoS flow is used. The QoS flow Retainability KPI is defined in TS 28.554 clause 6.5.1.1  \n\nThe QoS flow Retainability KPI is not sufficient to determine the ability of the wireless system to maintain a flow with some level of acceptable degradation.  \n\nIf the OAM system has the ability to monitor and capture statistics of downgraded QoS flows by for example counting the QoS degradation events per a period of time, then in addition to QoS flow Retainability, a QoS flow Maintainability should be added providing a measurement that reflects the probability to experience a QoS degradation. The measurement will serve as a measure to determine the ability of the wireless system to maintain the flow. \n\n2. Actions:\nTo SA5:\nACTION:\na)\tSA2 would like to understand the present or future ability of SA5 to monitor and capture statistics of downgraded QoS flows.\nb)\tIf the answer to question a is positive, SA2 kindly asks SA5 to consider adding a QoS Maintainability measurement on the basis of QoS flow level. The measurement will reflect the probability to experience a QoS degradation of any kind during the time when the QoS flow is used.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":[{"winame":"eNA_Ph3"},{"winame":" TEI19"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"S2-2508116","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254328.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254329","title":"LS on initiation of new work item ITU-T Y.DTNCM \u201cDigital twin network - collaboration and management in IMT-2020 networks and beyond\u201d","source":"ITU-T SG13","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43290,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254329.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254330","title":"LS on consent of new Recommendation ITU-T Y.3123 (ex.Y.IMT2020-CEFEC) \u201cFramework of edge computing capability exposure for IMT-2020 networks and beyond\u201d","source":"ITU-T SG13","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43300,"status":"noted","reservation_date":"2025-10-01 15:34:44","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254330.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254331","title":"LS on information and call for contributions to the new Focus Group on Artificial Intelligence Native for Telecommunication Networks (FG-AINN)","source":"ITU-T FG-AINN","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Action","abstract":"ITU-T Focus Group on Artificial Intelligence Native for Telecommunication Networks (FG-AINN) is pleased to inform you about its progress since its establishment by ITU-T Study Group 13 in July 2024. The FG-AINN studies the relevant AI Native techniques and the validation mechanisms for such techniques to enable AI Native Telecommunication networks.\nThe FG-AINN activities are organized according to 4 WGs, respectively, WG1 \u201cTerminology and Gap Analysis\u201d, WG2 \u201cUse Cases\u201d, WG3 \u201cArchitecture of AI-Native Approach\u201d and WG4 \u201cProof-of-Concepts (PoC) and Community Outreach\u201d and are conducted through - usually virtual - weekly meetings. More details on the Terms of Reference, the working groups and the deliverables of the Focus Group can be found in our website https:\/\/www.itu.int\/en\/ITU-T\/focusgroups\/ainn\/Pages\/default.aspx .  \n\nCurrently, the ongoing pre-standardization activities of the Focus Group include: \n\n\u2022\t(WG1) Study of concepts, characteristics and definitions of artificial intelligence native telecommunication networks. Please refer to FG-AINN-O-08 available from https:\/\/extranet.itu.int\/sites\/itu-t\/focusgroups\/ainn\/output\/FG-AINN-O-08.zip\n\u2022\t(WG1) Analysis of gaps\n\u2022\t(WG1) Vocabulary for Artificial Intelligence Native for Telecommunication Networks.\n\u2022\t(WG2) Study of use cases related to AI Native (focusing on non-radio aspects). Please refer to FG-AINN-I-149-R1 available from https:\/\/extranet.itu.int\/sites\/itu-t\/focusgroups\/ainn\/input\/FG-AINN-I-149-R3.docx \n\u2022\t(WG3) Study of architecture frameworks and technical enablers for AI Native (focusing on non-radio aspects)\n\u2022\t(WG4) Knowledge dissemination, including community building around the AI Native technologies, for e.g., workshops, PoCs, build-a-thon. Please refer to draft Build-a-thon Report and mentoring sessions available from FG-AINN-I-153-R1 https:\/\/extranet.itu.int\/sites\/itu-t\/focusgroups\/ainn\/input\/FG-AINN-I-153-R3.docx \n\nCall for contributions\n\nThe FG AINN calls for contributions to use cases, gap analysis, architectures and PoCs. \nIf you need guidance on preparing contributions, please contact us at tsbfgainn@itu.int \nFor your information, the next (5th) FG-AINN meeting will be conducted virtually on 23-25 September 2025, 1200-1630 CEST, as announced on the FG-AINN website https:\/\/www.itu.int\/en\/ITU-T\/focusgroups\/ainn\/Pages\/default.aspx. \n\nPlease note that the FG-AINN is currently conducting Build-a-thon 3.0 during August \u2013 September 2025. A series of mentoring sessions will be conducted and will conclude with the announcement of winners in October 2025. Interested parties can join the mentoring sessions via the link here https:\/\/itu.zoom.us\/j\/99217216989?pwd=SpKLTrfLDvP63Q4s2NxZcSJ9pdzsZF.1 and register for the Build-a-thon here: https:\/\/github.com\/ITU-AI-ML-in-5G-Challenge\/Build-a-thon2025\/issues\/new?template=register-build-a-thon-2025.yml \n\nThe FG-AINN encourages your contributions and participation in our meetings.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43310,"status":"noted","reservation_date":"2025-10-01 15:34:45","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254331.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254332","title":"LS\/r on methodology coordination","source":"ITU-T SG2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43320,"status":"noted","reservation_date":"2025-10-01 15:34:45","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254332.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254333","title":"LS on the consent of draft new Recommendation ITU-T M.3393 (M.rsmca): \u201cRequirements for smart maintenance of cell antenna\u201d","source":"ITU-T SG2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43330,"status":"noted","reservation_date":"2025-10-01 15:34:45","uploaded":"2025-10-01 16:20:27","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254333.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254334","title":"LS on Study on Modernization of Specification Format and Procedures for 6G","source":"TSG SA","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"TSG SA would like to draw the attention of delegates from all WGs to the ongoing Study on Modernization of Specification Format and Procedures for 6G which started at the TSG #108 meetings (see SID in SP-250802).\nInitial studies have gathered information on the benefits, shortcomings and pain-points of 3GPP\u2019s current specification formats and working methods, as well as potential benefits to be targeted. Further, requirements were identified for any improvements to specifications and working methods. This information is being captured in TR 21.802 v0.1.0.\nThe primary focus for the next two quarters will be on objectives 2 and 3 of the study.\nIt is important that this study takes into account the needs and ways of working of all groups in 3GPP, and therefore companies are encouraged to bring the collective experience of their delegates across 3GPP to engage with the study.\nCompanies are reminded that a dedicated email reflector 3GPP_SPEC_MODERNISATION@LIST.ETSI.ORG is in operation for this Study, and the Conference Calls for the study can be found as \u201c3GPP-Conference Call on 3GPP Spec Modernization\u201d on the 3GPP Portal and registration performed in the usual way. The next two conference calls are listed below for information below:\n-\t3GPP-Conference Call on 3GPP Spec Modernization #3\t13:00 - 15:00 (UTC)\t9th October 2025\n-\t3GPP-Conference Call on 3GPP Spec Modernization #4\t13:00 - 15:00 (UTC)\t10th November 2025\n2\tActions\nTo : RAN1, RAN2, RAN3, RAN4, RAN5, SA1, SA2, SA3, SA4, SA5, SA6, CT1, CT3, CT4, CT6 \nACTION: \tTSG SA asks all groups to remind delegates about the ongoing Study on Modernization of Specification Format and Procedures for 6G and to encourage participation to reflect the needs and ways of working of all groups.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"postponed","reservation_date":"2025-10-01 15:34:45","uploaded":"2025-10-01 16:20:28","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"FS_6GSpecs"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"S5-254334","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254334.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254335","title":"LS on Guidance on 6G data related work tasks","source":"TSG SA","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"TSG SA asks SA2 and SA5 to progress and collaborate (including with RAN2 and RAN3 where applicable) on 6G data related work tasks and taking the 5G working scope as the starting point. \nSA2 and SA5 should coordinate with SA3 for the data security and privacy requirements.\nRegular coordination and collaboration among the WGs are expected, including checks on the progress of each group for 6G data related work tasks in March 2026 (TSG SA#111) and\/or June 2026 (TSG#112), to avoid the duplicate design for the same functionality and to develop system wide consistent solutions.\n2\tActions\nTo SA2 and SA5\nACTION: \tSA requests SA2 and SA5 to follow the SA plenary guidance stated above.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"noted","reservation_date":"2025-10-01 15:34:45","uploaded":"2025-10-01 16:20:28","revisionof":"","revisedto":"","release":"Rel-20","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"SP-251261","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254335.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254336","title":"LS on unified management interface for multi-RAT support","source":"TSG SA","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"noted","reservation_date":"2025-10-01 15:34:45","uploaded":"2025-10-01 16:20:28","revisionof":"","revisedto":"","release":"Rel-20","crspec":"","crspecversion":"","workitem":[{"winame":"FS_UMMR_OAM"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"SP-251266","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254336.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254337","title":"Liaison Response to ZSM work on Agent and Autonomy","source":"TM Forum Autonomous Network Project","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43370,"status":"noted","reservation_date":"2025-10-01 15:34:45","uploaded":"2025-10-01 16:20:28","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254337.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254621","title":"Reply LS on OAM-centric solution for NW-side data collection","source":"RAN2","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS in","for":"Information","abstract":"Rel-19","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":462100,"status":"postponed","reservation_date":"2025-10-21 05:43:37","uploaded":"2025-10-24 11:01:57","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"S5-255153","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254621.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254625","title":"LS on Invitation to update the information in the IMT-2020 and beyond roadmap","source":"SA5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"CMCC","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43191,"status":"withdrawn","reservation_date":"2025-10-21 05:43:37","uploaded":null,"revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"JCA-IMT2020","Cc":"","lsoriginalls":"","lsreply":"","link":"","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254626","title":"LS on \"\"IETF Network Slice Application in 3GPP 5G End-to-End Network Slice\"\"","source":"SA5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"E\/\/\/ Jose`","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":0,"status":"withdrawn","reservation_date":"2025-10-21 05:43:37","uploaded":null,"revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"IETF Traffic Engineering Architecture and Signaling Working Group (teas)","Cc":"","lsoriginalls":"","lsreply":"","link":"","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254627","title":"Reply to LS on a new measurement related to the maintainability of a QoS flow","source":"SA5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"Ericsson, Verizon","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":42321,"status":"approved","reservation_date":"2025-10-21 05:43:37","uploaded":"2025-10-21 05:51:06","revisionof":"S5-254232","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":[{"winame":"eNA_Ph3"},{"winame":" TEI19"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA2","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254627.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254628","title":"Reply to LS on Study on Modernization of Specification Format and Procedures for 6G","source":"SA5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Information","abstract":"NEC\nSA5 thanks TSG SA for issuing the LS on FS_6GSpecs Study on Modernization of Specification Format and Procedures for 6G. The study\u2019s motivation to revisit and evolve current specification formats and CR-processing workflows in preparation for 6G normative work is fully supported.\nSA5 maintains a large number of specifications across multiple releases, primarily due to the extensive scope of OAM, with additional contributions from Charging specifications. Many of these specifications are interrelated or dependent and are extensively cross-referenced, reflecting the complexity of managing multi-release specification sets.\nExisting Stage 3 tool usage and pipeline behaviour, as documented in Table B-1 \/ Annex B of TR 21.802, illustrate SA5\u2019s practical experience in managing complex specification sets. Stage 1\/2 TS text is maintained in Microsoft Word, while Stage 3 artefacts including OpenAPI YAML files, ASN.1, GPB, XSD, and YANG data models are managed through the 3GPP Forge environment. An automated validation and generation pipeline on Forge ensures artefact consistency and efficient integration into TS releases. Stage 3 artefacts are distributed together with each published TS in the same ZIP package, reflecting SA5\u2019s established processes and tooling for Stage 3 artefacts and CR workflows.\nMany of the study objectives such as improved automation, better interoperability between formats, reduced CR implementation latency, and enhanced navigation and cross-referencing are closely aligned with the challenges faced by all TSGs in maintaining large multi-release specification sets.\n2\tActions\nTo TSG SA:\nACTION: \tSA5 kindly asks SA to take the above information into consideration.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43241,"status":"noted","reservation_date":"2025-10-21 05:43:37","uploaded":"2025-10-21 05:51:06","revisionof":"","revisedto":"","release":"Rel-20","crspec":"","crspecversion":"","workitem":[{"winame":"FS_6GSpecs"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"TSG RAN, TSG CT","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254628.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254630","title":"LS on need for modeling isInvariant and SystemCreated in YANG","source":"SA5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"E\/\/\/ Bal.\nAs described in the original 3GPP liaison statement[2] 3GPP needs YANG mapping for the modeling concepts isInvariant and SystemCreated. Informally the Netmod WG has raised issues with the two concepts. However, these concepts have been used by 3GPP SA5 for many years (>15) and have served their purposes. SA5 intends to continue to use these concepts, abandoning them would also lead to backward compatibility problems.\nUnfortunately the solutions proposed by the IETF Netmod WG are not seen as suitable to be used in 3GPP SA5 specifications. We see the following issues that prevent the usage of the IETF proposed solutions.\n ..\n    2\tActions\nTo IETF Netmod WG\nACTION: \t3GPP SA5 would like to inform IETF Netmod WG, that the solutions proposed by the Netmod WG are not suitable for SA5 modeling, and to inform Netmod WG about the 3GPP SA5 implemented solutions above. 3GPP SA5 would also like to ask if there is a possibility that IETF Netmod WG will modify their solution or whether 3GPP should continue with their 3GPP specific solution.","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":43181,"status":"approved","reservation_date":"2025-10-21 05:43:37","uploaded":"2025-10-21 05:51:06","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"SBMA_Ph3"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"IETF NETMOD WG","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254630.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254791","title":"Reply LS on specification of dataset and model parameters exchange","source":"SA5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":42311,"status":"revised","reservation_date":"2025-10-21 05:55:08","uploaded":"2025-10-21 06:01:08","revisionof":"S5-254231","revisedto":"S5-254846","release":"Rel-20","crspec":"","crspecversion":"","workitem":[{"winame":"FS_AIML_MGT_Ph3"},{"winame":" NR_AIML_air-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA, RAN, RAN2","Cc":"SA2, SA3, RAN1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254791.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S5-254846","title":"Reply LS on specification of dataset and model parameters exchange","source":"SA5","contact":"Ingbert Sigovich","contact-id":28887,"tdoctype":"LS out","for":"Approval","abstract":"","secretary_remarks":"","agenda_item_sort_order":10,"ainumber":"5.3","ainame":"Liaison statements at SA5 level","tdoc_agenda_sort_order":42312,"status":"approved","reservation_date":"2025-10-21 05:55:39","uploaded":"2025-10-21 06:01:08","revisionof":"S5-254791","revisedto":"","release":"Rel-20","crspec":"","crspecversion":"","workitem":[{"winame":"FS_AIML_MGT_Ph3"},{"winame":" NR_AIML_air-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA, RAN, RAN2","Cc":"SA2, SA3, RAN1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG5_TM\/TSGS5_163\/Docs\/S5-254846.zip","group":"S5","meeting":"S5-163","year":2025,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0}]