[{"name":"S2-2308269","title":"LS from BBF: BBF answer to your liaison S2-2207761 solutions for 5WWC_Ph2 Key Issue 1","source":"BBF","contact":"Lincoln Lavoie","contact-id":39231,"tdoctype":"LS in","for":"Action","abstract":"Dear colleagues, We would like to thank you for sharing TR23.700-17 and for requesting BBF feedback regarding your study on How to support differentiated services (e.g., QoS and charging) for the same and different Non-3GPP devices, and UEs connected behind a 5G-RG . We would also like to thank you for the effort spent in highlighting the key elements and assumptions of the different solutions in TR23-700-17. At first, for any solution you would consider, we would like to expose how managing both RGs and end-user devices in the home network is happening via TR-069 and\/or TR-369 (USP), based on the TR-181i2 Device:2 Data Model. To this end, we attach a slide presentation on this topic. We would like to request 3GPP to consider this for any solution chosen.","secretary_remarks":"Revision of Postponed S2-2306266 from S2#157. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"postponed","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306266","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CableLabs","lsoriginalls":"LIAISE-562-05","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308269.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308270","title":"LS from CableLabs: Feedbacks on solutions for 5WWC_Ph2 Key Issue 1","source":"CableLabs","contact":"Yunjung Yi","contact-id":93023,"tdoctype":"LS in","for":"Information","abstract":"Dear Colleagues, CableLabs thanks SA WG2 for LS S2-2207761 regarding solutions studied under FS_5WWC_Ph2. The following table captures CableLabs feedback. For each solution, CableLabs assumes the applicable device type(s) as listed in column 3 of the table. CableLabs prefers solutions supporting both 5G-RG and FN-RG (e.g., via W-AGF), wherever applicable, in 3GPP s normative work.","secretary_remarks":"Revision of Postponed S2-2306267 from S2#157. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"postponed","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306267","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"BBF","lsoriginalls":"CableLabs LS Response on 3GPP Rel-18 5WWC_Ph2","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308270.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308271","title":"LS from GSMA 5GMRR: LS to 3GPP on IPX Requirements for 5GS Roaming","source":"GSMA 5GMRR","contact":"PRADEEP BHARDWAJ","contact-id":78621,"tdoctype":"LS in","for":"Action","abstract":"GSMA 5GMRR thanks SA WG3 for their reply LS (S3-231389) on PRINS middle boxes. This LS response focuses on the requirements from IPX providers, one of the roles in the roaming eco-system. Actions: GSMA 5GMRR kindly asks 3GPP to take the following actions: SA WG1 to update their specifications in order to support IPX provider requirements that are currently not covered. SA WG2 to enhance the 5G architecture to meet the IPX provider requirements. SA WG3 to define a security solution that includes the IPX providers requirements","secretary_remarks":"Revision of Postponed S2-2306271 from S2#157. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10270,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306271","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2, SA WG3","Cc":"TSG SA, CT WG4","lsoriginalls":"5GMRR#41 Doc 38r2","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308271.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308272","title":"LS from GSMA 5GMRR: LS Roaming Value Added Service Requirements","source":"GSMA 5GMRR","contact":"Gery Verwimp","contact-id":20103,"tdoctype":"LS in","for":"Action","abstract":"This LS focusses on one of the three roles in the roaming eco-system, namely roaming value-added service (RVAS) providers. Actions: GSMA NRG 5GMRR kindly requests 3GPP to consider the attached service requirements from RVAS providers. GSMA 5GMRR kindly asks 3GPP to determine how the 5G specifications can be adapted to support these requirements. GSMA 5GMRR asks 3GPP to take note of the current sponsored roaming facilitation using dual or multi-IMSI profiles on the SIM, and advise on any concerns with respect to authentication or concealment algorithms. SA WG1, SA WG2, and SA WG3 are kindly asked to take into account the above requirements of GSMA 5GMRR to enable RVAS providers.","secretary_remarks":"Revision of Postponed S2-2306272 from S2#157. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10280,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306272","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2, SA WG3","Cc":"TSG SA, CT WG4","lsoriginalls":"5GMRR Doc 41_39r2","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308272.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308273","title":"LS from GSMA 5GMRR: LS with Roaming Hubbing requirements and LS response to 3GPP SA3 LS (S3-214456) on 5GS Roaming Hubbing","source":"GSMA 5GMRR","contact":"Pieter Veenstra","contact-id":86411,"tdoctype":"LS in","for":"Action","abstract":"This LS lists Roaming Hubbing specific requirements and responds to SA WG3 LS on 5GS roaming hubbing (S3-214456). Actions: GSMA NRG 5GMRR kindly requests 3GPP to consider the above service requirements for roaming hubs and to provide advice on how these requirements can be supported using current specifications. Moreover, the group kindly requests SA WG1, SA WG2 and SA WG3, and CT WG4 to update their specifications in order to support requirements that are currently not covered to support the RH use cases that are established in roaming to date and that should be provided for 5G SA roaming and interconnect, too. 5GMRR would like to work together with 3GPP in order to develop solutions that meet these requirements while complying to the 5GS architecture and security specifications.","secretary_remarks":"Revision of Postponed S2-2306273 from S2#157. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10290,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306273","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2, SA WG3","Cc":"TSG SA, CT WG4","lsoriginalls":"5GMRR Doc 41_40r4","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308273.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308274","title":"LS from GSMA 5GMRR: LS on GSMA 5GMRR Working solution assumption on L-PRINS and Data Session Control","source":"GSMA 5GMRR","contact":"Ahmad Muhanna","contact-id":84435,"tdoctype":"LS in","for":"Action","abstract":"This LS describes a working solution assumption aiming to converge the needs of a service provider and the security architecture as put forward in the 5G SA roaming eco-system. Action to SA WG2: GSMA 5GMRR kindly requests SA WG2 to consider the Service Provider Data Session Control call flow in this LS and to provide feedback.","secretary_remarks":"Revision of Postponed S2-2306274 from S2#157. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306274","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3, CT WG4","Cc":"TSG SA, SA WG1","lsoriginalls":"5GMRR Doc 41_41r3","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308274.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308280","title":"LS from CT WG4: Reply LS on Proposed new draft Recommendation Signalling requirements and procedures for bypassing network elements of IMS","source":"CT WG4","contact":"Liu Liu","contact-id":76788,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 thanks ITU Study Group 11 for their LS on Proposed new draft Recommendation 'Signalling requirements and procedures for bypassing network elements of IMS'. CT WG4 acknowledges that how to deal with the network element (such as IMS HSS) with service interruption to alleviate the impact to the served user is not specified. CT WG4 would like to point to ITU Study Group 11 that the IMS Restoration Procedures for the SCC-AS service interruption is specified in clause 6 of 3GPP TS 23.380. Action: CT WG4 kindly asks SA WG2 for SA WG2 s view from normative Stage 2 perspective on the ITU-T LS (C4-231011), and to provide feedback to ITU-T SG11 and CT WG4.","secretary_remarks":"Revision of Postponed S2-2306301 from S2#157. Response drafted in S2-2309411 (withdrawn). Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10390,"status":"postponed","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306301","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ITU-T Study Group 11, SA WG2","Cc":"ITU-T Study Group 2, CT WG1","lsoriginalls":"C4-231396","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308280.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308282","title":"LS from SA WG4: Reply LS on the reuse of EVEX as specified in TS 26.531","source":"SA WG4","contact":"Richard Bradbury","contact-id":82569,"tdoctype":"LS in","for":"Action","abstract":"SA WG4 thanks SA WG6 for its LS on possible reuse of the SA WG4-defined EVEX framework in the context of the Application Data Analytics Enablement Services (ADAES) and application service management in eSEAL2 work items in order to avoid duplication of effort. {. . .} Action: In relation to requirement 1, SA WG4 asks SA WG2 to comment on the possibility of extending the Naf_EventExposure service to include a query operation in support of the stated SA WG6 requirement.","secretary_remarks":"Revision of Postponed S2-2306308 from S2#157. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10380,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306308","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG2, CT WG3","lsoriginalls":"S4-230683","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308282.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308283","title":"LS from ITU-T SG13: LS on Y.3159 'Framework for classifying network slice level in future networks including IMT-2020'","source":"ITU-T SG13","contact":"Yushuang Hu","contact-id":96973,"tdoctype":"LS in","for":"Action","abstract":"This liaison statement informs about the consented Recommendation ITU-T Y.3159 'Framework for classifying network slice level in future networks including IMT-2020'.","secretary_remarks":"Revision of Postponed S2-2306315 from S2#157. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"S2-2306315","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG5, GSMA","Cc":"","lsoriginalls":"SG13-LS80","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308283.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308286","title":"LS from GSMA 5GMRR: LS to 3GPP on the introduction of the domain 'ipxnetwork.org' in addition to '3gppnetwork.org'","source":"GSMA 5GMRR","contact":"Pieter Veenstra","contact-id":86411,"tdoctype":"LS in","for":"Action","abstract":"Background: GSMA 5GMRR has defined procedures for SEPP Discovery in support of 5G SA Roaming and would like to inform 3GPP about the usage of the domain name ipxnetwork.org in addition to the well-known '3gppnetwork.org'. Discussion: To differentiate between SEPP instances deployed by either a PLMN or managed by a service provider on behalf a PLMN (Outsourced SEPP) versus SEPP instances of a service provider (Hosted SEPP and Hub based use cases), the new distinct domain name ipxnetwork.org has been introduced in support of the latter instances. The domain name '3gppnetwork.org' has been referenced in TS 23.003 and TS 33.310, and there may be more instances in other 3GPP specifications. It is suggested to add a reference to the domain 'ipxnetwork.org' in those cases as well. Please note that the domain 'ipxnetwork.org' is an existing dormant GSMA domain name and was originally introduced in anticipation for the support of e.g. specific roaming use cases with SS7 and Diameter. Action: GSMA 5GMRR kindly asks 3GPP to take the above information into account and to update existing 3GPP specifications were needed.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3, CT WG4","Cc":"5GMRR, NRG, DESS","lsoriginalls":"5GMRR Doc 42a_04r2","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308286.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308287","title":"LS from ITU-T SG11: LS on initiation of new work item Q.FMSC-SA 'Signalling architecture of fixed, mobile and satellite convergence for IMT-2020 networks and beyond'","source":"ITU-T SG11","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"This liaison statement is to inform ITU-T SG13 and 3GPP SA2 about the initiation of new work item Q.FMSC-SA \"Signalling architecture of fixed, mobile and satellite convergence for IMT-2020 networks and beyond\"","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10050,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ITU-T SG13, SA WG2","Cc":"","lsoriginalls":"SG11-LS70","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308287.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308288","title":"LS from TSG SA: Reply LS on GSMA requirements regarding intermediaries in the roaming ecosystem and related LSs","source":"TSG SA","contact":"Johannes Achter","contact-id":94365,"tdoctype":"LS in","for":"Information","abstract":"This reply LS also takes into account the following LSs received from GSMA: SP-230351: LS to 3GPP on IPX Requirements for 5GS Roaming (5GMRR Doc 41_38r2) SP-230352: LS to 3GPP (SA WG1, SA WG2, SA WG3) on Roaming Value Added Services requirements (5GMRR Doc 41_39r2) SP-230353: LS with Roaming Hubbing requirements and LS response to SA WG3 LS (S3-214456) on 5GS Roaming Hubbing (5GMRR Doc 41_40r4) SP-230376: LS on GSMA 5GMRR Working Solution Assumption L-PRINS and Data Session Control (5GMRR Doc 41_41r3) TSG SA has concluded that the roaming requirements in the LSs from GSMA 5GMRR need a SA WG1 study to describe and discuss the use cases and derive potential service requirements. SA invites interested parties to contribute their use cases and requirements in SA WG1 as per normal 3GPP working procedures. This would then be followed by any architectural and protocol work as needed. TSG SA would like to inform GSMA that earliest possibility to undertake this work would be Rel-19 (refer to 3GPP workplan in SP 230738).","secretary_remarks":"SA WG2 replied to the GSMA LS at SA2#157 in S2-2307983. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"noted","reservation_date":"2023-06-28 15:24:35","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA 5GMRR","Cc":"SA WG1, SA WG2, SA WG3, SA WG5, CT WG4","lsoriginalls":"SP-230763","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308288.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308299","title":"LS from CT WG3: LS on Support of multiple UEs in Northbound APIs","source":"CT WG3","contact":"Narendranath Durga Tangudu","contact-id":73161,"tdoctype":"LS in","for":"Action","abstract":"CT WG3 is currently working under NBI18 WID (which is a stage 3 only WI), on specifying the technical enhancements to the 3GPP Northbound and Application Layer interfaces and APIs. In this regard, CT WG3 is discussing the support of list of UE(s) in various northbound APIs like NEF APIs in TS 29.522, SCEF APIs in TS 29.122, SEAL APIs in TS 29.549 etc. Currently, various northbound APIs only support either single UE information (external Identifier, MSISDN, Gpsi etc) or group of UEs (external group identifier, VAL group Identifier, etc). The northbound function (NEF, SCEF, Edge Enabler Server, SEAL server, etc) receiving the API request, may use the UE(s) information to further invoke the downstream 3GPP network services to fulfil the AF s request. When the AF has to invoke a northbound API targetting multiple UE(s) that do not belong to same group (identified by a group identifier like external group identifier), then the AF can either invoke the multiple northbound API individually for each UE or modify\/create an external group for this set of UE(s) and invoke the northbound API for the created\/modified group. CT WG3 has also observed that other APIs allow a third option, namely providing a list of UE(s) as the target of the request (instead of a GPSI or a group id). Question 1: Do SA WG2 and SA WG6 believe that the addition of this option (i.e. the option to provide a list of UE(s) as the target) to any API can be implemented by stage 3 as a signalling optimization or are there pros and cons that render it necessary to determine the existence (or not) of this option in stage 2 on a case by case basis? The implications on the E2E procedures (whether downstream APIs, e.g. 5GC APIs, should also be updated to support this list of UE(s) mechanism) should also be considered. Action: CT WG3 kindly asks SA WG2 and SA WG6 to clarify on the above question and update the specifications accordingly (if required).","secretary_remarks":"Response drafted in S2-2308613. This was Postponed.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10350,"status":"postponed","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG6","Cc":"","lsoriginalls":"C3-232510","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308299.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308300","title":"LS from CT WG3: LS on AKMA service restrictions in Rel-17","source":"CT WG3","contact":"Rajesh Babu Natarajan","contact-id":89232,"tdoctype":"LS in","for":"Information","abstract":"As per Rel-17 TS 33.535, cl 4.4.0, Roaming aspects are not considered in the present document. CT WG3 noticed that if Non-3GPP access can be supported for AKMA services, it is unclear for the network on how to identify the roaming scenario: As per current SA WG2 architecture, an LBO roaming UE could connect via 3GPP access in VPLMN and simultaneously connect via Non-3GPP access to HPLMN. When the UE establish PDU session via 3GPP access, VPLMN AMF\/SMF is selected, and PDU session is treated as roaming. When the UE establish PDU session via Non-3GPP access, HPLMN AMF\/SMF is selected, and PDU session is treated as non-roaming. It is possible that the UE could use 3GPP access (VPLMN) related PDU session and connect to the AF in the HPLMN to access AKMA services, which should be detected and denied by the Home Network in the release 17 as defined in Rel-17 TS 33.535. However, the UE can connect to the AF in the HPLMN to access AKMA services via the Non-3GPP access from above scenario. CT WG3 would like to ask SA WG3: Question1: Is Rel-17 AKMA services supported for the UE connected via Non-3GPP access? Question2: If the answer to Question 1 is affirmative, then how the network could identify the PDU session is related to roaming UE and deny AKMA services?","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"SA WG2","lsoriginalls":"C3-232563","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308300.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308307","title":"LS from CT WG4: Reply LS on the maximum length of Routing ID","source":"CT WG4","contact":"Hao Jing","contact-id":93660,"tdoctype":"LS in","for":"Information","abstract":"CT WG4 would like to thank RAN WG3 for the LS R3-232170. CT WG4 would like to provide the following response to the information provided from RAN WG3: Regarding LMF Routing ID IE in the NRPPa transport messages defined in TS 38.413, RAN WG3 has agreed to the attached CRs which clarify that the maximum length of the Routing ID IE is 16 octets, referring to the value of NfInstanceId defined in TS 29.571. CT WG4 would like to confirm that the maximum length of the Routing ID IE which is defined in RAN WG3 specification is correct. Furthermore, CT WG4 would like to suggest RAN WG3 refer to RFC 4122 for the encoding of the 16 octets (NF Instance ID encoded as UUID version 4) instead of referring to NF Instance ID of TS 29.571, because the encoding of the NF Instance ID is defined differently over 5GC SBIs. CT WG4 respectfully asks RAN WG3 to take the above information into account.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"SA WG2","lsoriginalls":"C4-232623","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308307.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308311","title":"LS from RAN WG2: LS on applicability of UAC for Network Controlled Repeater","source":"RAN WG2","contact":"Jonas Sedin","contact-id":98348,"tdoctype":"LS in","for":"Information","abstract":"In Release 18 WI Network-Controlled Repeater, at the RAN WG2#119bis-e meeting the following agreement, where the part related to UAC is highlighted: NCR-MT should ignore cellBarred, cellReservedForOperatorUse, cellReservedForFutureUse cellReservedForOtherUse, intraFreqReselection indications and UAC configuration if broadcast in system information. The agreement means that the NCR-MT skips the access control check for its access attempts to a cell. The NCR node is a network node similar to the IAB-node. For IAB which is also a network node, specification text in 24.501for an IAB-node to skip the access control was introduced, triggered based on LS R2-2003868 as highlighted below:","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"SA WG2","lsoriginalls":"R2-2306611","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308311.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308312","title":"LS from RAN WG2: Reply LS on GNSS integrity parameters","source":"RAN WG2","contact":"Yinghao Guo","contact-id":72226,"tdoctype":"LS in","for":"Information","abstract":"RAN WG2 would like to thank CT WG4 for the LS on GNSS integrity requirement parameters definition, and would like to ask CT WG4 to take the following RAN WG2 feedback into consideration: Question: CT WG4 would like to kindly ask RAN WG2 to define the data structure of TTA, TIR and AL, and provide the related reference to CT WG4 in order to implement this feature. Answer: The requested parameters TIR, AL and TTA are represented as follows - Target Integrity Risk (TIR): The range can be adopted from TS 37.355 defined within TargetIntegrityRisk-r17 of IE CommonIEsRequestLocationInformation. The recommended range is calculated by P=10-0.1n [hour-1] where n is from 10 to 90 and the range of the TIR is 10-1 to 10-9 per hour. - Alert Limit (AL): The parameter is separated into a horizontal and vertical alert limit. The range can be adopted from horizontal and vertical protection level defined in TR 37.355 within IntegrityInfo-r17 of the IE CommonIEsProvideLocationInformation. The recommended range for both horizontal and vertical alert limit are 0 to 500 meters, with 0.01 meters granularity. - Time to Alert (TTA): The range can be adopted from the use cases for integrity listed in TR 38.857, Table 9.2.4, where the TTAs listed in different use cases have the range from 100ms to 30s. The recommended value range is from 0.1 to 30s, with 0.1s granularity.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"SA WG2","lsoriginalls":"R2-2306681","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308312.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308319","title":"LS from RAN WG3: Reply LS on the use of PEI during an Emergency PDU Session","source":"RAN WG3","contact":"Philippe Godin","contact-id":68843,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 thanks RAN WG2 for their LS on the use of PEI during an emergency PDU session. RAN WG3 considers that specification impacts on RAN WG3 procedures would be necessary to have gNB disable the UE-ID based subgrouping when paging UEs in Emergency PDU session in RRC idle or RRC inactive state. RAN WG3 will not initiate to discuss these enhancements unless requested by RAN WG2.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10180,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"CT WG1, SA WG2","lsoriginalls":"R3-233313","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308319.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308324","title":"LS from RAN WG3: LS on Multiple Trace\/MDT configurations","source":"RAN WG3","contact":"Aijuan Liu","contact-id":43714,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 discussed the case that a NG-RAN node receives multiple Trace\/signalling based MDT configurations from the CN for the same UE. RAN WG3 has reached the following understanding: When a NG-RAN node receives a Trace activation request, it should start the new session if the Trace Reference is different from the Trace Reference of any existing session for the UE. During handover procedure or UE context retrieval procedure, the source NG-RAN node forwards only one Trace\/MDT configuration to the target NG-RAN node and informs the AMF of the failure of the non-forwarded Trace\/MDT configurations via the Trace Failure Indication procedure.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10190,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:53","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG5","Cc":"SA WG2","lsoriginalls":"R3-233481","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308324.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308325","title":"Reply LS to RAN2 on flightpath information forwarding for UAV","source":"RAN WG3","contact":"Yansheng Liu","contact-id":85003,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 thanks RAN WG2 for informing the progress on UAV flight path information transmission during handover. RAN WG3 agreed adding the UAV flight path information into RAN WG3 specifications for NGAP (TS 38.413), and XNAP (TS 38.423). The agreed TP capturing the UAV flight path information are attached, while the referred IE to RRC is FFS to wait until RAN WG2 finalization of the definition of UAV fight path information.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:53","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"SA WG2","lsoriginalls":"R3-233493","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308325.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308330","title":"LS from SA WG1: LS on GSMA requirements regarding intermediaries in the roaming ecosystem and related LSs","source":"SA WG1","contact":"Kurt Bischinger","contact-id":26063,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 has discussed the LSs from GSMA 5GMRR, S1-231055, 056, 057 and 058 as well as the LS from SA WG3 S1-231034, and concluded that a SA WG1 study would be needed to describe and discuss the use cases and derive potential service requirements. SA WG1 suggest SA to inform GSMA 5GMRR that SA WG1 welcomes all interested parties to contribute in SA WG1 with their use cases and requirements.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:53","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG3","Cc":"SA WG2, CT WG4","lsoriginalls":"S1-231776","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308330.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308331","title":"Reply LS on 3GPP work on Energy Efficiency","source":"SA WG1","contact":"Laurent Walter Goix","contact-id":99061,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 thanks SA WG5 for their LS S5-232903, and questions. SA WG1 answers and clarifications are provided below: Q1: Please correct and\/or complement the table present in the attached document if and where deemed appropriate. [SA WG1 answer]: SA WG1 would like to inform that there is no ongoing study related to Rel-18 anymore. However, SA WG1 provides an update to the table provided by SA WG5 here below. Note that the ongoing SID on Energy Efficiency as service criteria (SP-230235) relates to Rel-19 and not Rel-18. For SA WG5 convenience, changes below are provided as highlighted text (new text in red, old text strikethrough). {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:53","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG5","Cc":"CT WG4, CT WG3, RAN WG4, RAN WG3, RAN WG2, RAN WG1, SA WG6, SA WG4, SA WG3, SA WG2, SA WG1, TSG CT, TSG RAN, TSG SA","lsoriginalls":"S1-231805","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308331.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308334","title":"LS from SA WG3: LS on Further input to address GSMA LS on requirements for intermediaries in the roaming ecosystem (S3-232344)","source":"SA WG3","contact":"Anja Jerichow","contact-id":68341,"tdoctype":"LS in","for":"Information","abstract":"In addition to SA WG3 response in LS S3-232155, SA WG3 would like to provide further input to 3GPP working groups in preparation of a consolidated 3GPP response to GSMA. Document S3-233349 provides an overview of related requirements captured in 3GPP. After having reviewed the requirements, SA WG3 believes that further refinement and clarification is needed, as follows. (a) Some requirements may be outside 3GPP scope. Identifying such requirements may require a collaborative effort among multiple 3GPP working groups, and may require clarifications from GSMA. (b) The current 5G service architecture appears to cover the majority of the new GSMA requirements. Some requirements, however, may not be covered. For such requirements, which are also considered to lie within 3GPP scope, SA WG3 has sent a LS to SA WG2(S3-232155) and is expecting feedback. SA WG3 remains open for this to be a collaborative effort. (c) The main requirement provided in the GSMA LSs (S3-232344 bundle) appears to be that 'entities may need access to messages exchanged between PLMNs to be able to offer their services and that any action of these entities is to be attributable . The requirements received in the S3-232344 LS bundle need to be reconciled with the 5G architecture and the e2e security requirements received in S3-180338, as they retain their validity, as captured in TS 33.501, clause 5.9.3 (requirements for e2e core network interconnection security). {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"noted","reservation_date":"2023-06-28 15:24:36","uploaded":"2023-06-28 15:29:53","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG1, SA WG2, CT WG4","lsoriginalls":"S3-233308","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308334.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308339","title":"LS from SA WG4: Reply LS on alignment of activities on UE data collection, reporting and event exposure","source":"SA WG4","contact":"Richard Bradbury","contact-id":82569,"tdoctype":"LS in","for":"Information","abstract":"SA WG4 acknowledges TSG SA LS on the topic of alignment of activities on UE data collection, reporting and event exposure and provides the following answers to the questions posed. {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10200,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-06-28 15:29:53","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG2, SA WG6","lsoriginalls":"S4-231092","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308339.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308340","title":"Reply LS on the reuse of EVEX as specified in TS 26.531","source":"SA WG4","contact":"Richard Bradbury","contact-id":82569,"tdoctype":"LS in","for":"Information","abstract":"SA WG4 thanks SA WG6 for its continued interest in the possible reuse of the SA WG4-defined EVEX framework in the context of its current Work Items 'Application Data Analytics Enablement Services' (ADAES) and 'application service management in eSEAL2'. SA WG4 also thanks SA WG6 for explaining its requirements in more detail and is pleased to provide the following information which it hopes is useful. {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"CT WG3, SA WG2","lsoriginalls":"S4-231109","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308340.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308341","title":"LS on 3GPP work on Energy Efficiency","source":"SA WG4","contact":"Nikolai Leung","contact-id":38562,"tdoctype":"LS in","for":"Information","abstract":"SA WG4 fully supports SA WG5 s and 3GPP s overall efforts addressing energy efficiency and the ongoing climate emergency. {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG CT, TSG RAN, TSG SA, SA WG5","Cc":"CT WG4, CT WG3, CT WG1, RAN WG4, RAN WG3, RAN WG2, RAN WG1, SA WG6, SA WG3, SA WG2, SA WG1","lsoriginalls":"S4-231111","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308341.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308342","title":"LS from SA WG5: LS on Slice based (wholesale) differentiation and charging in roaming","source":"SA WG5","contact":"Maryse Gardella","contact-id":68914,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 thanks GSMA NG ENSWI for their LS on Slice based (wholesale) differentiation and charging in roaming. SA WG5 would like to inform GSMA NG ENSWI, SA WG5 has created a Rel-18 work item to cover the charging solution for addressing the Business requirements for slice-based (wholesale) differential reporting and charging of traffic in the roaming case, expressed in the LS, based on the TS 23.501 and TS 23.502 procedures related description. This work item (attached S5-234455) is submitted for approval to the next June TSG SA#100. SA WG5 can confirm, by allowing the mapping of the VPLMN S-NSSAI(s) to the HPLMN S-NSSAI(s) to be available to CHF in VPLMN, this solution will allow wholesale with slice based differentiation. The solution is valid for Roaming Home routed as well as for LBO.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10230,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA NG ENSWI","Cc":"SA WG2, TSG SA, GSMA NRG, GSMA IDS, GSMA WAS","lsoriginalls":"S5-234453","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308342.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308343","title":"LS from SA WG5: Reply LS to LS on Y.3159 'Framework for classifying network slice level in future networks including IMT-2020'","source":"SA WG5","contact":"Tim Costello","contact-id":73305,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 thanks ITU-T SG13 Q21 for their LS SG13-LS80 on Y.3159 Framework for classifying network slice level in future networks including IMT-2020 . SA WG5 would like to inform ITU-T Q21\/13 that there is no overlap between the work item in ITU-T on developing a framework for classifying network slice levels and the work in SA WG5 on network slice management and charging. SA WG5 addresses Management and Charging aspects of the Network Slice with: 1. Network Slice Management 2. Network Slice Charging {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ITUT SG13\/Q21","Cc":"SA WG2, GSMA","lsoriginalls":"S5-234651","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308343.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308345","title":"LS from SA WG6: Reply LS on the reuse of EVEX as specified in TS 26.531","source":"SA WG6","contact":"Sapan Shah","contact-id":76271,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 thanks SA WG4 for their rely LS on possible reuse of the SA WG4-defined EVEX framework and also for providing agreed CR 0005 for TS 26.531. Regarding SA WG4 kindly invites SA WG6 to explain their requirements in greater detail to SA WG4 , SA WG6 would like to provide following details about the requirements. For, 2. The UE Application shall be able to send\/push collected data on-demand (i.e. without need for setting up session) to ASP through a request\/response mechanism. {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG4","Cc":"CT WG3, SA WG2","lsoriginalls":"S6-232001","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308345.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308347","title":"LS from SA WG6: LS to GSMA on publication of GSMA OPG and OPAG documents","source":"SA WG6","contact":"Jian Zhang","contact-id":95096,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 would like to thank GSMA OPG for the information about published documents from OPG\/OPAG. SA WG6 notices that GSMA OPG is working on the transformation aspect of southbound network API(s) to the northbound service API(s)\/OAM API(s), which are related to several work items in SA WG6. SA WG6 also notices that network slice is one of important topics in GSMA OPG. SA WG6 would like to inform GSMA OPG that SA WG6 has an on-going work about the network slice capability enablement (NSCE) in service enabler architecture layer (SEAL) and the related specification in TS 23.435. The NSCE work item focuses on defining the slice service API (i.e. northbound API) to the third party s application by aggregating southbound APIs defined by SA WG5 for slice management as well as APIs defined by SA WG2 (e.g. NEF API for network slice status report). The NSCE mainly provides the following services: - Application layer network slice lifecycle management - Network slice optimization based on AF policy - Network slice related performance and analytics monitoring - predictive slice modification in edge based NSCE deployments\/in Inter-PLMN deployment - Multiple slices coordinated resource optimization - Network slice adaptation for VAL application - Network slice fault management capability exposure, etc.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-06-28 15:29:52","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA OPG, OPAG","Cc":"SA WG2, SA WG5","lsoriginalls":"S6-232145","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308347.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308348","title":"LS from GSMA OPG: LS on GSMA OPG PRDs publication and document name change","source":"GSMA OPG","contact":"Sandra Ondrusova","contact-id":77474,"tdoctype":"LS in","for":"Action","abstract":"GSMA OPG would like to notify 3GPP and ETSI of the recent release of several GSMA PRDs: OPG.02 Operator Platform: Requirements and Architecture version 5.0. OPG.03 Southbound Interface Network Resources APIs version 3.0. OPG.04 East-Westbound Interface APIs version 3.0. Action: GSMA OPG kindly ask 3GPP and ETSI to take the above into consideration.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-08-02 11:36:50","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG5, SA WG6, ETSI ISG MEC, ETSI ISG NFV","Cc":"TSG SA","lsoriginalls":"OPG_142_Doc_03","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308348.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308349","title":"LS from GSMA TSGUEWIFI: LS reply to SA WG2 on 3GPP and non-3GPP interworking information in VoWiFi","source":"GSMA TSGUEWIFI","contact":"Di Zhang","contact-id":96672,"tdoctype":"LS in","for":"Action","abstract":"GSMA TSG UEWIFI would like to thank SA WG2 for the reply LS in S2-2307898\/UEWiFi10_003 on 3GPP and non-3GPP interworking capabilities. SA WG2 pointed out that specifications 3GPP TS 24.167 already have mechanisms that indicate to the UE which types of handovers are allowed, i.e., Allow_Handover_PDN_connection_WLAN_and_EPS, Allow_Handover_PDU_session_non-3GPP_and_NG-RAN, Allow_Handover_PDN_connection_non-3GPP_and_NG-RAN. However, 3GPP TS 24.167 does not completely address the problem statement that the UEWIFI group formulated. Firstly, configuration of Management Objects that inform the UE of the supported handovers are cumbersome and prone to failures. That is: These Management Objects are pre-configured by OEM and\/or configured with OTA (over the Air) methods by OEM. This makes these Management Objects static . Therefore, whenever network policy changes the MNO has to share the parameters with the OEM and the OEM needs to update this with OTA methods. Updating Management Objects this way has a number of limitations, e.g., it can take a long time to update all devices in the affected operators network, OEM may not support such updates after some time. OTA upgrade is not a reliable way as end users may ignore OTA upgrade notification. The update success rate is not guaranteed. If the operator doesn t support Device Management protocol, configurations cannot be updated by using OTA methods, then UE will encounter a handover failure and call drop when choose an undesired target network. Secondly, configuration of Management Objects that inform the UE of the supported handovers do not allow different handover policy for different parts of the network. The Management Objects don t allow for differentiating policies between different regions of a country served by the operator. It is difficult for operator to deploy nationwide 5G coverage in the near future (or in some cases never). Operators may want to have different cellular and Wi-Fi handover policy in different parts of the network, e.g. allow HO to VoNR in sub-set of the regions covered by their network. The Management Objects only apply to IMS PDN connection, non-IMS services which use other PDN connections will also need the interworking indication to make handover decision. Thirdly, configuration of Management Objects that inform the UE of the supported handovers are not useful in roaming scenarios. The Management Objects don t allow for differentiation handover capability when cellular and WLAN network belongs to different operators. When UE roams to cellular network of PLMN B and simultaneously connected to ePDG of PLMN A, there is no way to decide whether handover of IMS PDN connection from ePDG of PLMN A to SMF of PLMN B is supported depends on these parameters. In addition, though the procedures specified in 3GPP TS 23.502 for transfer of PDU session from non-3GPP access (WLAN) to 5GS or EPS using EPS fallback provides a solution when network doesn t support VoNR. However, when UE initiates a IMS voice call over WiFi and it is camped on NR simutaneously, this solution can not solve the handover issue when network doesn t support the handover from VoWiFi to VoNR but support VoNR. Therefore, we propose to convey the 3GPP and non-3GPP interworking handover indications from cellular network and\/or Wi-Fi network to UE rather than using Management Objects. {. . .} Actions: GSMA TSG UEWIFI kindly requests SA WG2 to take the information above into account and define possible solutions for the proposals.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"postponed","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-08-10 12:37:30","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"UEWIFI11_005","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308349.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308350","title":"LS from SA WG3: LS-Reply on Introduction of the domain 'ipxnetwork.org'","source":"SA WG3","contact":"Anja Jerichow","contact-id":68341,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 thanks 5GMRR for their LS to 3GPP on the introduction of the domain 'ipxnetwork.org' in addition to '3gppnetwork.org'. SA WG3 acknowledges that the domain 'ipxnetwork.org' has been introduced by GSMA for specific pre-5G roaming use cases. The 5G architecture as currently specified, however, stipulates that for any given roaming relation, exactly two SEPPs are involved, and that they mutually authenticate each other using a combination of the PLMN ID of the operator whose network edge they represent, and the domain name '3gppnetwork.org'. While it is in principle possible to use a different domain suffix like 'ipxnetwork.org' for SEPP discovery purposes in the context of intermediaries, such discovery and SEPP identification may have security implications. Given that an anticipated SA WG1 study will cover scenarios involving intermediaries, it seems prudent to await the results of this study before updating specifications with respect to introducing domain names for intermediary discovery. SA WG3 believes that a SEPP discovery procedure that covers all deployment scenarios in a manner that preserves e2e security between roaming partners is required, and kindly asks GSMA to provide further details on the mechanisms already documented. SA WG3 would also like to get confirmation on the following: If an operator decides to use a Hosted SEPP managed by a service provider instead of operating its own SEPP, then the Hosted SEPP s service provider would become the edge of one PLMN and, hence, the Hosted SEPP should become part of the PLMN security domain. If this is the correct understanding, an operator should also allow the IPX provider to use the operator domain name to connect to the other PLMN s SEPP to fulfil the SEPP behaviour as specified in clause 5.9.3 of 33.501.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"noted","reservation_date":"2023-06-28 15:24:37","uploaded":"2023-08-16 05:16:08","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA 5GMRR, SA WG1","Cc":"SA WG2, CT WG4","lsoriginalls":"S3-233786","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308350.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308425","title":"RFCs related to DHCPv6 are obsoleted by RFC 8415","source":"Nokia, Nokia Shanghai Bell, LG Electronics, Ericsson","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Update the IETF reference for the prefix Delegation RFC Replace in 9.6.2 reference to [17] (was an IETF spec) to proper reference [18] to TR -069","secretary_remarks":"This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10450,"status":"agreed","reservation_date":"2023-05-08 12:21:32","uploaded":"2023-08-10 06:03:53","revisionof":"","revisedto":"","release":"Rel-17","crspec":23.316,"crspecversion":"17.4.0","workitem":[{"winame":"5WWC"},{"winame":" TEI17"},{"winame":" 5GProtoc17-non3GPP"}],"crnumber":2106.0,"crrevision":"","crcategory":"F","tsg_crp":"SP-230838","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308425.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":false,"me_affected":true,"ran_affected":false,"cn_affected":true,"clauses_affected":"2; 4.6.2.2 ; 4.6.2.3 ; 9.6.2","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308426","title":"RFCs related to DHCPv6 are obsoleted by RFC 8415","source":"Nokia, Nokia Shanghai Bell, LG Electronics, Ericsson","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Rel-18 mirror CR: Summary of change: Update the IETF reference for the prefix Delegation RFC Replace in 9.6.2 reference to [17] (was an IETF spec) to proper reference [18] to TR-069","secretary_remarks":"This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10460,"status":"agreed","reservation_date":"2023-05-08 12:21:33","uploaded":"2023-08-10 06:03:53","revisionof":"","revisedto":"","release":"Rel-18","crspec":23.316,"crspecversion":"18.2.0","workitem":[{"winame":"5WWC"},{"winame":" TEI17"},{"winame":" 5GProtoc17-non3GPP"}],"crnumber":2107.0,"crrevision":"","crcategory":"A","tsg_crp":"SP-230838","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308426.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":false,"me_affected":true,"ran_affected":false,"cn_affected":true,"clauses_affected":"2; 4.6.2.2 ; 9.6.2","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308431","title":"Replacing obsoleted RFC related to DHCPv6 with RFC 8415","source":"LG Electronics, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Laeyoung Kim","contact-id":40613,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: 2 - Make [14] Void. - Add RFC 8415. 5.8.2.2.1 - Replace RFC 3736 with RFC 8415.","secretary_remarks":"This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10410,"status":"agreed","reservation_date":"2023-06-08 06:38:38","uploaded":"2023-08-11 02:42:19","revisionof":"","revisedto":"","release":"Rel-17","crspec":23.501,"crspecversion":"17.9.0","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":4701.0,"crrevision":"","crcategory":"F","tsg_crp":"SP-230838","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308431.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":false,"me_affected":true,"ran_affected":false,"cn_affected":true,"clauses_affected":"2, 5.8.2.2.1","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308432","title":"Replacing obsoleted RFC related to DHCPv6 with RFC 8415","source":"LG Electronics, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Laeyoung Kim","contact-id":40613,"tdoctype":"CR","for":"Approval","abstract":"Rel-18 mirror CR: Summary of change: 2 - Make [14] Void. - Add RFC 8415. 5.8.2.2.1 - Replace RFC 3736 with RFC 8415.","secretary_remarks":"This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10420,"status":"agreed","reservation_date":"2023-06-08 06:40:43","uploaded":"2023-08-11 02:42:19","revisionof":"","revisedto":"","release":"Rel-18","crspec":23.501,"crspecversion":"18.2.2","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":4702.0,"crrevision":"","crcategory":"A","tsg_crp":"SP-230838","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308432.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":false,"me_affected":true,"ran_affected":false,"cn_affected":true,"clauses_affected":"2, 5.8.2.2.1","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308433","title":"Replacing obsoleted RFCs related to DHCPv6 with RFC 8415","source":"LG Electronics, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Laeyoung Kim","contact-id":40613,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: 2 - Make [20] and [21] Void. - Add RFC 8415. 4.3.9.2 & 5.3.1.1 - Replace RFCs 3736 and 3633 with RFC 8415. 5.3.1.2.6 - Replace RFC 3633 with RFC 8415.","secretary_remarks":"This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10430,"status":"agreed","reservation_date":"2023-06-08 06:44:00","uploaded":"2023-08-11 02:42:19","revisionof":"","revisedto":"","release":"Rel-17","crspec":23.401,"crspecversion":"17.8.0","workitem":[{"winame":"SAES"},{"winame":" TEI17"}],"crnumber":3738.0,"crrevision":"","crcategory":"F","tsg_crp":"SP-230838","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308433.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":false,"me_affected":true,"ran_affected":false,"cn_affected":true,"clauses_affected":"2, 4.3.9.2, 5.3.1.1, 5.3.1.2.6","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308434","title":"Replacing obsoleted RFCs related to DHCPv6 with RFC 8415","source":"LG Electronics, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Laeyoung Kim","contact-id":40613,"tdoctype":"CR","for":"Approval","abstract":"Rel-18 mirror CR: Summary of change: 2 - Make [20] and [21] Void. - Add RFC 8415. 4.3.9.2 & 5.3.1.1 - Replace RFCs 3736 and 3633 with RFC 8415. 5.3.1.2.6 - Replace RFC 3633 with RFC 8415.","secretary_remarks":"This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10440,"status":"agreed","reservation_date":"2023-06-08 06:46:00","uploaded":"2023-08-11 02:42:19","revisionof":"","revisedto":"","release":"Rel-18","crspec":23.401,"crspecversion":"18.2.0","workitem":[{"winame":"SAES"},{"winame":" TEI17"}],"crnumber":3739.0,"crrevision":"","crcategory":"A","tsg_crp":"SP-230838","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308434.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":false,"me_affected":true,"ran_affected":false,"cn_affected":true,"clauses_affected":"2, 4.3.9.2, 5.3.1.1, 5.3.1.2.6","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308611","title":"General corrections and alignment for TS23.501","source":"China Mobile","contact":"Dan Wang","contact-id":87155,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Alignment of NF services for TS 23.501.","secretary_remarks":"Check Acronym (General)! Revised to S2-2309412.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10470,"status":"revised","reservation_date":"2023-10-08 11:12:00","uploaded":"2023-08-11 16:11:21","revisionof":"","revisedto":"S2-2309412","release":"Rel-18","crspec":23.501,"crspecversion":"18.2.2","workitem":[{"winame":"5GS_Ph1"}],"crnumber":4748.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308611.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308612","title":"General corrections and alignment for TS23.502","source":"China Mobile","contact":"Dan Wang","contact-id":87155,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Alignment of NEF services for TS 23.502.","secretary_remarks":"Check Acronym (General)! Revised to S2-2309413.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10490,"status":"revised","reservation_date":"2023-10-08 11:12:01","uploaded":"2023-08-11 16:11:21","revisionof":"","revisedto":"S2-2309413","release":"Rel-18","crspec":23.502,"crspecversion":"18.2.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":4300.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308612.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2308613","title":"[DRAFT] Reply LS on support of multiple UEs in Northbound APIs","source":"China Mobile","contact":"Dan Wang","contact-id":87155,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS on support of multiple UEs in Northbound APIs","secretary_remarks":"Response to S2-2308299. Revised to S2-2309410.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10360,"status":"revised","reservation_date":"2023-10-08 11:14:52","uploaded":"2023-08-11 16:36:34","revisionof":"","revisedto":"S2-2309410","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"SA WG6","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2308613.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2309201","title":"[DRAFT] LS on Support of NSWO for 3GPP UE behind 5G-RG","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"This includes the LS that last meeting was not send. It would be preferable to send this meeting and not wait next one.","secretary_remarks":"Revision of (unhandled) S2-2306862 from S2#158. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10340,"status":"postponed","reservation_date":"2023-11-08 11:14:20","uploaded":"2023-08-11 12:04:54","revisionof":"S2-2306862","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC_Ph2"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"BBF, CableLabs","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2309201.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2309287","title":"Further clarification on transfer of emergency PDU session from non-3GPP to 3GPP access","source":"ZTE","contact":"Jinguo Zhu","contact-id":32987,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add or normally in the last sentence.","secretary_remarks":"Revised to S2-2309414.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10510,"status":"revised","reservation_date":"2023-11-08 15:16:17","uploaded":"2023-08-11 16:15:10","revisionof":"","revisedto":"S2-2309414","release":"Rel-18","crspec":23.501,"crspecversion":"18.2.2","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":4891.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2309287.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"5.16.4.1","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2309365","title":"Discussion on clarification of non-allowed area for MPS and MCX","source":"T-Mobile USA INC","contact":"Christopher Joul","contact-id":31136,"tdoctype":"discussion","for":"Agreement","abstract":"This document discusses the issue of bypassing non-allowed area for MPS and MCX use case. LS from CT WG1 in S2-2306265 at SA WG2#157 with a partial reply sent in S2-2307790.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10540,"status":"noted","reservation_date":"2023-11-08 18:41:19","uploaded":"2023-08-11 18:48:34","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2309365.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2309410","title":"[DRAFT] Reply LS on support of multiple UEs in Northbound APIs","source":"China Mobile","contact":"Dan Wang","contact-id":87155,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS on support of multiple UEs in Northbound APIs","secretary_remarks":"Revision of S2-2308613. WITHDRAWN","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10370,"status":"withdrawn","reservation_date":"2023-08-28 10:53:07","uploaded":null,"revisionof":"S2-2308613","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"SA WG6","lsoriginalls":"","lsreply":"","link":"","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2309411","title":"[DRAFT] Reply LS on Proposed new draft Recommendation Signalling requirements and procedures for bypassing network elements of IMS","source":"SA WG2","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"To: . CC: . Attachments: .","secretary_remarks":"Created at meeting. Response to S2-2308280. Not provided. WITHDRAWN","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10400,"status":"withdrawn","reservation_date":"2023-08-28 10:53:07","uploaded":null,"revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, ITU-T Study Group 11","Cc":"ITU-T Study Group 2, CT WG1","lsoriginalls":"","lsreply":"","link":"","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2309412","title":"General corrections and alignment for TS23.501","source":"China Mobile","contact":"Dan Wang","contact-id":87155,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Alignment of NF services for TS 23.501.","secretary_remarks":"Revision of S2-2308611. This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10480,"status":"agreed","reservation_date":"2023-08-28 10:53:07","uploaded":"2023-08-28 11:31:05","revisionof":"S2-2308611","revisedto":"","release":"Rel-18","crspec":23.501,"crspecversion":"18.2.2","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":4748.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-230859","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2309412.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2309413","title":"General corrections and alignment for TS23.502","source":"China Mobile","contact":"Dan Wang","contact-id":87155,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Alignment of NEF services for TS 23.502.","secretary_remarks":"Revision of S2-2308612. This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10500,"status":"agreed","reservation_date":"2023-08-28 10:53:08","uploaded":"2023-08-28 11:31:05","revisionof":"S2-2308612","revisedto":"","release":"Rel-18","crspec":23.502,"crspecversion":"18.2.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":4300.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-230859","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2309413.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2309414","title":"Further clarification on transfer of emergency PDU session from non-3GPP to 3GPP access","source":"ZTE","contact":"Jinguo Zhu","contact-id":32987,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add or normally in the last sentence.","secretary_remarks":"Revision of S2-2309287. Revised off-line to S2-2310024.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10520,"status":"revised","reservation_date":"2023-08-28 10:53:09","uploaded":"2023-08-28 11:31:05","revisionof":"S2-2309287","revisedto":"S2-2310024","release":"Rel-18","crspec":23.501,"crspecversion":"18.2.2","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":4891.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2309414.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2310024","title":"Further clarification on transfer of emergency PDU session from non-3GPP to 3GPP access","source":"ZTE","contact":"Jinguo Zhu","contact-id":32987,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify the last sentence as following to avoid ambiguous During the session transfer the UE may be registered to receive emergency services over both 3GPP access and non-3GPP access concurrently","secretary_remarks":"Revision of S2-2309414. This CR was agreed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10530,"status":"agreed","reservation_date":"2023-08-28 11:01:10","uploaded":"2023-08-28 11:31:10","revisionof":"S2-2309414","revisedto":"","release":"Rel-18","crspec":23.501,"crspecversion":"18.2.2","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":4891.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"SP-230859","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_158_Goteborg_2023-08\/Docs\/S2-2310024.zip","group":"S2","meeting":"S2-158","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0}]