[{"name":"S2-2300003","title":"LS from BBF: BBF 5G-RG requirements for 3GPP Rel.18\/ATSSS (Enhanced Hybrid Access)","source":"BBF","contact":"Anja Jerichow","contact-id":68341,"tdoctype":"LS in","for":"Action","abstract":"Dear colleagues, In view of the finalization of the study phase for Rel. 18, BBF has analyzed TR 23.700-53 being developed by 3GPP to enhance the access traffic steering, switching and splitting (ATSSS) support in the 5G system architecture, with particular attention on the aspects relevant to 5G-RG. In the latest 3GPP released specifications, the support for bandwidth aggregation using Multi-Access PDU sessions is specified for TCP-based traffic (with the so called ATSSS-HL); however, traffic splitting for non-TCP traffic is not yet fully supported. One type of non-TCP traffic of high interest to BBF as it is relevant to 5G-RG is Ethernet traffic. A number of fixed broadband services, already deployed in many operators networks for business as well as for residential customers, are based on Layer 2 traffic. The lack of an efficient way to implement traffic splitting on 5G-RG would limit the possibility to enhance these services by exploiting simultaneously the dual connectiv","secretary_remarks":"Revision of postponed S2-2210167 from S2#154. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10630,"status":"postponed","reservation_date":"2022-12-19 08:34:53","uploaded":"2022-12-19 08:35:58","revisionof":"S2-2210167","revisedto":"S2-2302174","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"LIAISE-542-5G-RG-Hybrid-Access-Requirements-00","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300003.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300005","title":"LS from CT WG4: Reply to LS on VoLTE Roaming GBR Handling","source":"CT WG4","contact":"Xiaoyun Zhou","contact-id":77294,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 would like to thank SA WG2 for their LS on VoLTE Roaming GBR Handling. 3GPP TS 29.274 (GTPv2) already supports that the MME in a VPLMN can reject Create\/Update Bearer Request with the cause 'MME\/SGSN refuses due to VPLMN Policy' as below: 'MME\/SGSN refuses due to VPLMN policy' is used by the MME\/SGSN in the VPLMN to indicate to the PGW in the Create Bearer Response or Update Bearer Response that it does not allow the establishment or modification of the bearer due to VPLMN operator's policy. In principle, CT WG4 could extend the Create\/Update Bearer Response with a new VPLMN QoS IE providing the max GBR that the VPLMN allows when returning the above error. A better alternative could be to extend the Create Session Request message for an IMS PDN connection creation with a new VPLMN QoS IE containing a list of max GBRs for corresponding QCIs which is like what exists in 5GS (v-SMF providing its QoS constraints to H-SMF during the PDU session establishment). However, abov","secretary_remarks":"Revision of postponed S2-2210171 from S2#154. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10570,"status":"noted","reservation_date":"2022-12-19 08:34:53","uploaded":"2022-12-19 08:35:58","revisionof":"S2-2210171","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C4-224401","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300005.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300007","title":"LS from SA WG4: DRAFT Reply LS to 3GPP SA2 on VoLTE Roaming GBR Handling","source":"SA WG4","contact":"Xueqian Bai","contact-id":92286,"tdoctype":"LS in","for":"Action","abstract":"SA WG4 thanks SA WG2 for the LS on VoLTE Roaming GBR Handling. SA WG4 has discussed the issue and can confirm the SA WG2 understanding that a RAN GBR (in HPLMN or VPLMN) that is lower than what is needed to support the lowest voice codec mode the UE is configured to use (by the HPLMN), would result in voice packets being delayed and\/or dropped. It cannot be assumed that a UE would adapt below the lowest configured voice codec mode, even in the presence of substantial packet loss and even if the specific voice codec technology supports lower modes than what is included in the current UE configuration. Furthermore, the current TS 26.114 specification provides several optional and recommended speech adaptation procedures and possibilities to detect the need for speech adaptation. Currently, only one speech adaptation procedure is normative for the UE; adjusting speech codec mode based on received speech Codec Mode Request (CMR). However, neither sending CMR based on observed RTP","secretary_remarks":"Revision of postponed S2-2210178 from S2#154. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10580,"status":"noted","reservation_date":"2022-12-19 08:34:53","uploaded":"2022-12-19 08:35:58","revisionof":"S2-2210178","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S4-221192","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300007.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300009","title":"LS from 5G-ACIA: 5G capabilities exposure for factories of the future identified gaps","source":"5G-ACIA","contact":"Andreas Mueller","contact-id":81087,"tdoctype":"LS in","for":"Action","abstract":"Overall Description: In 2021, 5G-ACIA published a revised white paper on the exposed 5G capabilities that are needed by factory operators to manage and maintain industrial 5G devices and 5G NonPublic Networks (NPN) in a simple and efficient manner [1] . 5G-ACIA informed 3GPP about this work in SP-210281 and a reply LS was provided in SP-211134. 5G-ACIA wishes to thank 3GPP for their answer and collaborative spirit. In the meantime, 5G-ACIA mapped these requirements onto Rel-17 specifications and identified the gaps and possible limitations as listed below. Some of these gaps could be relevant for future 3GPP work. {. . .} Actions: 5G-ACIA kindly asks 3GPP to take note of the identified gaps and limitations in Rel-17 specifications for considerations in the ongoing and future activities of 3GPP.","secretary_remarks":"Revision of postponed S2-2210183 from S2#154. Responses drafted in S2-2300339, S2-2301189. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10540,"status":"postponed","reservation_date":"2022-12-19 08:34:53","uploaded":"2022-12-19 08:35:58","revisionof":"S2-2210183","revisedto":"S2-2302175","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, TSG CT","Cc":"SA WG1, SA WG2, SA WG3, SA WG5, SA WG6","lsoriginalls":"5G-ACIA-LS-2022-005","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300009.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300020","title":"LS from CT WG1: LS on NSWO feature","source":"CT WG1","contact":"Roozbeh Atarius","contact-id":75861,"tdoctype":"LS in","for":"Action","abstract":"For the clarity of the NSWO feature, CT WG1 kindly asks SA WG2 to provide responses to the following question: In TS 23.501, WLAN for PLMN List-5 deploys an AAA function so that it can connect with a 3GPP AAA server or proxy. Does this mean that NSWOF as described in clause 4.2.15 of TS 23.501, in both roaming and non-roaming scenarios always acts towards the WLAN as a 3GPP AAA server?. Action: CT WG1 asks SA WG2 group to kindly answer the above questions.","secretary_remarks":"Response drafted in S2-2300619. Final response in S2-2302168","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10440,"status":"replied to","reservation_date":"2022-12-19 08:34:54","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-227003","lsreply":"S2-2302168, S2-2302168","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300020.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300022","title":"LS from CT WG1: Reply LS on Nudm_UEContextManagement service for satellite NG-RAN","source":"CT WG1","contact":"Mikael Wass","contact-id":42217,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 thanks CT WG4 for their assessment and reply LS on Nudm_UEContextManagement service for satellite NG-RAN. CT WG1 has taken the provided information into account in further discussions. As a result of continued analysis and feedback received in the CT WG1\/CT WG4 telephone conference on the topic (2022-10-27), CT WG1 has concluded that the information currently provided by the UDM to the AMF, as part of the UE subscription information or as UDM response to a registration request, is sufficient for the CT WG1 specified NAS protocol enhancements related to the broadcast of multiple TAs in a satellite NG-RAN cell. I.e., if the UDM rejects the registration request the AMF can select a 5GMM cause and can determine which of the TAIs broadcasted in a satellite NG-RAN cell are forbidden TAs, using operator preference. Thus, for the CT WG4 request: CT WG4 ask CT WG1 to clarify whether the requirement exist for the UDM to make the AMF aware whether (based on subscription information) a given forbidden TAI is forbidden for roaming or forbidden for regional provision of services. the CT WG1 response is that there is no such requirement for the UDM.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10610,"status":"noted","reservation_date":"2022-12-19 08:34:54","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"SA WG2","lsoriginalls":"C1-227090","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300022.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300029","title":"LS from CT WG1: LS on Handling of the Allowed PDU session status IE in Non-allowed service area","source":"CT WG1","contact":"Robert Zaus","contact-id":85311,"tdoctype":"LS in","for":"Action","abstract":"At CT WG1#139e, CT WG1 discussed certain requirements related to the UE behaviour in a non-allowed service area. CT WG1 would like to ask SA WG2 for guidance on an issue. The scenario is as follows: 1) The UE is registered to an AMF both via 3GPP and non-3GPP access. The UE is currently in a non-allowed area. The registration area (TAI list) for 3GPP access includes both TAs from the UE's non-allowed area and TAs from the allowed area. The UE is currently in a non-allowed area. 2) The UE has at least 1 PDU session activated via non-3GPP access which cannot be transferred to 3GPP access. 3) The UE is in IDLE mode both for 3GPP and non-3GPP access, when it receives a paging via 3GPP access indicating non-3GPP access and responds with a Service Request. CT WG1 understands that if the UE responds to the paging when it is in a TA belonging to the allowed area, then the UE needs to include the Allowed PDU session status IE (in 23.502 terminology: 'List Of Allowed PDU Sessions') indicating which of the PDU sessions associated with non-3GPP access can be transferred to 3GPP access and may include the Uplink data status IE if it has uplink data pending. Question 1: Does the UE need to include the Allowed PDU session status IE also if it responds to the paging when it is in a non-allowed area? Question 2: Is the UE allowed to include the Uplink data status IE if it has uplink data pending if it responds to the paging when it is in a non-allowed area?. Action: CT WG1 kindly ask SA WG2 to answer CT WG1's question.","secretary_remarks":"Responses drafted in S2-2300216, S2-2300530, S2-2300562, S2-2300604, S2-2301070, S2-2301276. Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10030,"status":"postponed","reservation_date":"2022-12-19 08:34:55","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"S2-2302183","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-227197","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300029.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300031","title":"LS from CT WG3: Reply to LS on VoLTE Roaming GBR Handling","source":"CT WG3","contact":"Susana Fernandez","contact-id":42321,"tdoctype":"LS in","for":"Action","abstract":"CT WG3 would like to thank SA WG2 for their LS on VoLTE Roaming GBR Handling and would like to provide feedback on the appropriate reject causes and their possible extension with the maximum GBR rate. 3GPP TS 29.212 (Gx interface) already supports the reporting from the PGW to the PCRF of RESOURCE_ALLOCATION_FAILURE failure code together with the impacted PCC rules that could not be successfully installed or maintained since the bearer establishment\/modification failed. There is not a specific failure code to identify that the reason of the failure is that the VPLMN did not accept the requested GBR for that bearer. Gx interface would need to be extended to convey the maximum GBR that the VPLMN can support, under the assumption that the PGW receives that value from the MME\/SGSN. The existing failure code in addition to the maximum GBR supported by the VPLMN in the message could be enough to interpret that the failure of the resource allocation was due to a specific VPLMN QoS policy. 3GPP TS 29.214 (Rx interface) already supports INDICATION_OF_FAILED_RESOURCES_ALLOCATION value for the Specific-Action AVP, that is provided by the PCRF to the AF (P-CSCF in IMS network) together with the impacted flows. In order for the IMS network to learn that the resource allocation failed, as proposed for the Gx interface, the Rx interface can also be extended with the inclusion of the maximum GBR supported by the VPLMN, if the PCRF received it from the PGW. In principle, CT WG3 could extend the Gx\/Rx interface with a new AVP including the maximum GBR that the VPLMN allows provided by the MME\/SGSN when returning the above failure code. Action: CT WG3 kindly requests SA WG2 to take the above information into consideration","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10590,"status":"noted","reservation_date":"2022-12-19 08:34:55","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG4, CT WG4, GSMA NRG","lsoriginalls":"C3-225510","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300031.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300033","title":"LS from CT WG4: LS on Enabling operators to deploy N32 purpose specific SEPPs","source":"CT WG4","contact":"Bruno Landais","contact-id":68755,"tdoctype":"LS in","for":"Information","abstract":"CT WG4 has agreed the attached CR enabling operators to deploy N32 purpose specific SEPPs in their networks, i.e. not requiring all SEPPs deployed in a PLMN (or SNPN) to support the same N32 purposes (e.g. roaming, SMS interconnect, disaster roaming, inter-PLMN mobility, SNPN interconnect). Note: N32 purposes are defined in clause 6.1.5.3.9 of TS 29.573. The N32 purpose of a request is signalled from NF\/SCP to a SEPP in the 3gpp-Sbi-Interplmn-Purpose header (see TS 29.500). SCPs (or NFs) of PLMNs deploying N32 purpose specific SEPPs would route their requests towards a local SEPP that supports the N32 purpose of the request and, as per existing requirements, that enables to reach the target PLMN. SCPs (or NFs) of PLMNs not deploying N32 purpose specific SEPPs would route their requests towards a local SEPP as per existing requirements, i.e. that enables to reach the target PLMN. The local SEPP would then send the request to a remote SEPP that supports the N32 purpose of the request, if the remote PLMN deploys N32 purpose specific SEPPs. CT WG4 noted that DNS procedures specified in GSMA IR.67 to discover a remote SEPP uses a well-known SEPP FQDN (sepp.5gc.mnc345.mcc012.3gppnetwork.org) 'unless specified and agreed otherwise', and that GSMA also considered the possibility to support discovering different SEPPs for different N32 purposes: 'Note: Multiple NAPTR record lines may be foreseen in the future. For example: one NAPTR record for roaming and one NAPTR record for (SMS) interworking.' CT WG4 kindly ask GSMA NG to confirm the need for enabling operators to deploy N32 purpose specific SEPPs. If so, CT WG4 kindly asks GSMA NG to provide feedback on the proposed solution if any, and to consider possibly defining DNS procedure extensions to enable the discovery of a remote SEPP supporting a specific N32 purpose, if appropriate.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10640,"status":"noted","reservation_date":"2022-12-19 08:34:55","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA NG","Cc":"SA WG2","lsoriginalls":"C4-225493","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300033.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300034","title":"LS from CT WG4: Reply LS on Response LS on Identifier availability for Lawful Interception during Inter-PLMN handover","source":"CT WG4","contact":"Marco Broszeit","contact-id":82883,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 thanks SA WG3 for their request regarding the transfer of MSISDN and IMEI at inter-PLMN handover in EPC and 5GC. CT WG4 discussed the situation and agrees both with the SA WG3-LI request and the SA WG2 assessment. As announced in the SA WG2 LS, CT WG4 encourages SA WG2 to prepare CR(s) to add the MSISDN to the stage 2 specification for the outlined mobility scenarios for Release 18. CT WG4 will continue the work once stage 2 is finalised. Action: CT WG4 kindly asks SA WG2 to provide the required stage 2 changes and SA WG3-LI to take this into account.","secretary_remarks":"Response drafted in S2-2300614. Final response in S2-2302165","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10370,"status":"replied to","reservation_date":"2022-12-19 08:34:55","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3-LI","Cc":"SA WG3, CT WG3","lsoriginalls":"C4-225542","lsreply":"S2-2302165, S2-2302165","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300034.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300036","title":"LS from CT WG4: Reply LS on Re-establishment of the MBS context during mobility registration update or service request procedure","source":"CT WG4","contact":"Bruno Landais","contact-id":68755,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 thanks SA WG2 for their LS (S2-2209965) on Re-establishment of the MBS context during mobility registration update or service request procedure. CT WG4 would like to provide the following answers to SA WG2: For Q1: - Q1: Considering the related N1SM and N2SM information needs to be sent to UE and NG-RAN during the multicast session join\/leave procedures as specified in Rel-17, is it possible and desirable for the SMF to handle the procedure as described in the two solutions? For example, how is the MBS session related context information is sent to UE and NG-RAN without SM message? CT WG4 answer: N1 and N2 signalling for multicast session join\/leave procedures are exchanged between the AMF and the SMF through N1 and N2 SM Information containers, transparently to the Nsmf_PDUSession API and Namf_Communication APIs (as binary body part in HTTP multipart messages) and with corresponding N1 and N2 procedures specified within CT WG1 and RAN WG3 specifications respectively. This approach has been designed since Rel-15 to transfer any N1 or N2 SM information between the AMF and SMF without impacting the AMF and SMF APIs. Moving away from the existing design is not desirable since this would require defining SMF and AMF APIs specific extensions to carry (NAS SM related) MBS session information outside of any NAS SM message, and the associated error handling. This may also require to address potential backward compatibility issues, e.g. with SMFs not upgraded with the corresponding API extensions. For Q2: - Q2: Separating the MM and the SM signaling is a design principle of the 5GS from beginning. In the solutions, the UE includes multicast MBS session information container, which is information for SM handling, in the MM signalling (i.e. Registration Request and Service Request). Do CT WG1\/CT WG4\/RAN WG3 see problems with adopting this proposed procedure in Rel-18, considering the potential issue to be solved, e.g. coordinating the MM\/SM handling? CT WG4 answer: It is recommended to maintain the design principle of separating the MM and the SM signalling to avoid system impacts. The MBS session information is considered as SM-related handling, and hence sending this information outside of NAS SM message would break existing design principles. Action: CT WG4 kindly asks SA WG2 group to take the above answers into consideration.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10600,"status":"noted","reservation_date":"2022-12-19 08:34:55","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1, RAN WG3","lsoriginalls":"C4-225562","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300036.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300037","title":"LS from CT WG4: LS on NAI format for 5G NSWO","source":"CT WG4","contact":"Giorgi Gulbani","contact-id":82292,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 discussed what should be the NAI format for 5G NSWO and has agreed the attached CR. CT WG4 however could not determine if NAI decoration is required for 5G NSWO scenarios. CT WG4 kindly asks SA WG2 to answer whether the non-3GPP access network may be connected or not to multiple VPLMNs for 5G NSWO use case, and if so, whether the UE should be able to indicate a specific VPLMN through which the request should be sent. Action: CT WG4 kindly asks SA WG2 to answer whether the non-3GPP access network may be connected or not to multiple VPLMNs for 5G NSWO use case, and if so, whether the UE should be able to indicate a specific VPLMN through which the request should be sent.","secretary_remarks":"Response drafted in S2-2300620. Final response in S2-2302171","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10510,"status":"replied to","reservation_date":"2022-12-19 08:34:55","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1, SA WG3","lsoriginalls":"C4-225641","lsreply":"S2-2302171, S2-2302171","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300037.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300050","title":"LS from RAN WG2: Reply LS on GNSS integrity requirement provisioning","source":"RAN WG2","contact":"Yinghao Guo","contact-id":72226,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 would like to thank SA WG2 for the LS on GNSS integrity requirement provisioning. RAN WG2 would like to provide the following answer to SA WG2's question on the parameters that are needed: - LCS client\/UE\/AF sends TIR, AL, TTA to the LMF - LMF returns the system available\/unavailable indication to the LCS client\/UE\/AF. Action: RAN WG2 respectfully asks SA WG2 to take the above answer into account in the further work.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10650,"status":"noted","reservation_date":"2022-12-19 08:34:56","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG1","lsoriginalls":"R2-2213320","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300050.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300054","title":"LS from RAN WG3: Reply LS on Time Synchronization Status notification towards UE(s)","source":"RAN WG3","contact":"Man Zhang","contact-id":88630,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 thanks SA WG2 for the LS on Time Synchronization Status notification towards UE(s). RAN WG3 discussed the questions and would like to provide the following answers. Question : For key issue#1, One method proposes to use the Ciphered SIB approach that is used for broadcast of assistance data for positioning. SA WG2 would like to additionally get feedback on this from SA WG3 and RAN WG3 from security and NGAP impact perspective, respectively RAN WG3's Answer: There is no consensus in RAN WG3 on the feasibility of AMF providing ciphered RAN TSS information to gNB. The overall feasibility of this solution is to be determined by other working groups (e.g., RAN WG2, SA WG3). Question : SA WG2 would like to seek RAN WG3 input regarding the potential impacts in RAN WG3 specifications (e.g., NGAP, F1-AP) to enable RAN time synchronization status report control procedure. RAN WG3's Answer: RAN WG3 is unable to comment on the potential RAN WG3 impacts, without knowing details such as the content of RAN time synchronization status to be reported. Some information is implementation dependent. Action: RAN WG3 kindly asks SA WG2 to take 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":10660,"status":"noted","reservation_date":"2022-12-19 08:34:57","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"RAN WG1, RAN WG2, SA WG3","lsoriginalls":"R3-226774","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300054.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300057","title":"LS from RAN WG3: LS on static and dynamic TAC solutions for mobile IAB node","source":"RAN WG3","contact":"Ying Huang","contact-id":90961,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 discussed static and dynamic TAC solutions for mobile IAB and achieved the following agreement. Static TAC solution is not pursued. RAN WG3 assumes that dynamic TAC solution should be supported. RAN WG3 will further study the impacts (if any) of the dynamic TAC solution on RAN WG3 specifications. Action: RAN WG3 respectfully asks RAN WG2 and SA WG2 to take the above RAN WG3 agreements into account.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10670,"status":"noted","reservation_date":"2022-12-19 08:34:57","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2, SA WG2","Cc":"","lsoriginalls":"R3-226831","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300057.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300061","title":"LS from SA WG1: Reply LS on PIN Management","source":"SA WG1","contact":"Erik Guttman","contact-id":18782,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 thanks SA WG6 for their LS on PIN management. Question 1 to SA WG1: Whether the requirement Establishing duration of the PIN can also be considered to include a scheduled validity period such as Valid during particular time of the day , Valid only during weekdays etc.? The existing relevant requirement is: The 5G system shall support mechanisms for a network operator or authorized 3rd party (e.g., a PIN User) to create, remove and manage a PIN, including: ... - Establishing duration of the PIN; The interpretation of this requirement from a stage 2 perspective is left to the discretion of SA WG6. The requirement is not intended to include or exclude any possible technical realization. Question 2 to SA WG1: Whether the PIN owner or Admin can be able to suspend the PIN temporarily as part of PIN management? Whether and how this corresponds to the ability to 'suspend' a PIN temporarily is a matter for stage 2 groups to determine.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10680,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG2","lsoriginalls":"S1-223538","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300061.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300064","title":"LS from SA WG1: Reply LS on low latency communication applications to use RAN feedback on periodicity for scheduling","source":"SA WG1","contact":"Atsushi Minokuchi","contact-id":26474,"tdoctype":"LS in","for":"Action","abstract":"SA WG1 thanks SA WG2 for the LS asking the following question (taken from S2-2209964): - SA WG2 would like to ask whether SA WG1 sees a need for dynamic periodicity adjustment based on 5GS feedback for applications which need low latency communication. SA WG1 would like to provide the following comments: - There is no SA WG1 requirement that literally specifies the mentioned aspect. But there is a strict low latency communication KPI requirement as shown in the first row of Table 5.2-1 of TS 22.104, which is End-to-end latency maximum (incl. 1 wireless link) being 500 s. - SA WG1 expects that downstream working groups pay attention to this KPI value and consider necessary architecture enhancement. Factors that adversely affect communication performance need to be properly addressed in architecture work. SA WG1 does not prevent downstream working groups from specifying 'dynamic periodicity adjustment based on 5GS feedback for applications which need low latency communication' if that is beneficial to fulfil this KPI value. Action: SA WG1 kindly asks SA WG2 to take the answers above into account.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10690,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S1-223726","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300064.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300065","title":"LS from SA WG1: Reply LS on QoS Sustainability analytics and V2X service adaptations","source":"SA WG1","contact":"Yang Xu","contact-id":87111,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 thanks to 5GAA s LS and have discussed the questions in the LS based on the Section 6.1 and 6.2 in the 5GAA Technical Report, SA WG1 would like to provide the following answer to Q.1.2 and Q.1.3: {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10350,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG2, SA WG6","lsoriginalls":"S1-223734","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300065.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300066","title":"LS from SA WG3: Reply LS on user s consent for EDGEAPP","source":"SA WG3","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 would like to thank CT WG3 for the LS on user s consent for EDGEAPP (C3-223780) and would like to reply to the following questions: Question 2 to SA WG3, SA WG6: Whether the External Identifier used as GPSI needs user s consent or not? The generation and allocation of the AF specific GPSI in the form of External Identifier, which is arranged before the UE Id retrieval procedure, to its mobile subscription may need user s consent depending on different regulations. Question 3 to SA WG3, SA WG6: Whether the token is needed or not for the user s consent mechanism required in SA WG3 specification? SA WG3 did not specify any token-based mechanism for retrieval or checking of user consent. SA WG3 would like to point out that SA WG6 has already resolved this misalignment in SA WG6#49-bis-e meeting.","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":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"SA WG2, SA WG6, CT WG4","lsoriginalls":"S3-223904","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300066.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300067","title":"LS from SA WG3: Reply LS on User consent for Application Detection","source":"SA WG3","contact":"Christine Jost","contact-id":49662,"tdoctype":"LS in","for":"Action","abstract":"SA WG3 would like to thank SA WG2 for the LS on User consent for Application Detection (S2-2209973) and would like to reply to the following question: Question to SA WG3: SA WG2 kindly requests SA WG3 to provide feedback about the user consent checking for the NWDAF-assisted application detection by 5GC NWDAF (e.g. whether and which type of user consent is needed). SA WG3 thinks that for NWDAF-assisted application detection user consent is not applicable, since collecting user plane data on per UE's PDU session basis is a rather essential feature which is also needed for managing data traffic and charging. Action: SA WG3 kindly asks SA WG2 to take the above into account.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10700,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S3-223907","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300067.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300068","title":"LS from SA WG3: Reply LS on protection of the URSP rules from HPLMN","source":"SA WG3","contact":"Anand Palanigounder","contact-id":84545,"tdoctype":"LS in","for":"Action","abstract":"SA WG3 would like to thank SA WG2 for the LS on protection of the URSP rules from HPLMN. In the LS, SA WG2 ask the following two questions to SA WG3: - Do SA WG3 consider protection of the URSP rules provisioning in roaming scenarios adequate in Release -15 to Release-17 e.g. based on trust relationships between HPLMN and VPLMN? SA WG3 Answer: Yes. - Since SA WG2 is studying enhancement options for provisioning URSP in roaming scenarios (ref. KI#1 of TR 23.700-85) do SA WG3 see the need to enhance the security\/integrity protection of URSP rules when provided from HPLMN and\/or VPLMN? SA WG3 Answer: No. Action: SA WG3 kindly ask SA WG2 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":10710,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1","lsoriginalls":"S3-223911","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300068.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300069","title":"LS from SA WG3 : Reply LS on the IMS Data Channel Security Mode","source":"SA WG3","contact":"Vlasios Tsiatsis","contact-id":76181,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 would like to thank GSMA for the LS on the IMS Data Channel Security Mode(UPG04_109) and would like to reply to the following questions: Question 1 to SA WG3: Is end-to-end (e2e) security mode described in IETF RFC 8831 allowed for IMS data channel? What s the reason for SA WG3 just specifying the end-to-access-edge (e2ae) security mode for IMS data channel and leaving out e2e security mode? SA WG3 is working on the security of IMS data channel in KI#2 of TR 33.890 and has not concluded whether e2e can be allowed for IMS data channel. The reason why the current specs just specify the end-to-access-edge (e2ae) security mode for IMS data channel is due to WebRTC Gateway functionality which is described in 3GPP TS 24.371, where WebRTC data channel media is only present on access, carrying only either MSRP or BFCP content as sub-protocols to WebRTC data channel, as an extension of IMS MSRP\/BFCP media into the WebRTC domain used on access. In that scenario, WebRTC data channel (and thus DTLS) is always terminated at eIMS-AGW access side and only carrying the unencrypted payload of WebRTC data channel, that is MSRP or BFCP, in the IMS core. Thus, in that scenario\/use case, DTLS was never used in IMS core and there was thus no reason to specify anything else than e2ae security. Question 2 to SA WG3: If end-to-access-edge (e2ae) security mode is required by 3GPP, then whether the IMS-AGW will setup another DTLS association to the remote peer (e.g. IMS-AGW, Data Channel Server) to transmit IMS data channel contents and in that process IMS-AGW will play the role of DTLS client and the remote end as DTLS server? SA WG3 agrees that if the IMS-AGW sets up another DTLS association to the remote peer, then the IMS-AGW would need to decrypt\/re-encrypt the media content, and would need to be capable of acting both as DTLS client and server which requires enhancements to IMS-AGW. The impact on IMS-AGW needs to be further investigated. Question 3 to SA WG3: Whether the 3GPP Rel-17 IMS-AGW supporting Mb interface defined in 3GPP TS 23.002 would allow the data media pass-through to the next network element. That is whether IMS-AGW lacking support for e2ae security mode or having it disabled would permit the IMS data channel transport to the next IMS element on the path or rather this should fail according the current standard. SA WG3 Rel-17 standards neither preclude nor mandate the IMS-AGW behaviour that question 3 is looking for, i.e., it will depend on implementation and deployment decisions. SA WG3 has been studying this aspect in Rel-18 in the context of the study in TR 33.890. SA WG3 will inform GSMA if and when the conclusion is made. Question 4 to SA WG3: Whether DTLS encryption can be applied at Network to Network reference points in the case when e2ae security mode is used on User to Network reference point? That is whether the Izi media plane interface defined in 3GPP TS 29.165 or Mb media plane interface defined in 3GPP TS 23.002 can enable media plane encryption over NNI when e2ae security mode is used over UNI? SA WG3 thinks that DTLS encryption could be applied to Izi or Mb interface. SA WG3 would like to point out that end-to-end encryption may create issues with respect to LI therefore LI requirements may need to be taken into account in the SA WG3 study.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10720,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA","Cc":"SA WG2, SA WG3-LI","lsoriginalls":"S3-223913","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300069.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300070","title":"LS from SA WG3: Reply LS on Network federation interface for Telco edge consideration","source":"SA WG3","contact":"Bo Zhang","contact-id":49401,"tdoctype":"LS in","for":"Action","abstract":"SA WG3 would like to thank the SA WG6 for their LS on Network federation interface for Telco edge consideration. Regarding clause 5 of East West Bound Interface (EWBI) APIs PRD, i.e. Transport Level Security (TLS) shall be used to support the security communication between the OPs. The access to the E\/WBI APIs shall be authorized by means of OAuth2 protocol (see IETF RFC 6749 [4]), based on local configuration, using the 'Client Credentials' authorization grant. If OAuth2 is used, a client, prior to consuming services offered by an OP E\/WBI APIs, shall obtain a 'token' from the authorization server. , SA WG3 has discussed in the details and provides the following feedbacks: 1. It would be better to give the details on how to define the procedures of the OAuth2 protocol and Client Credentials, such as which network function will take the OAuth Authorization server role, what will be included in the token, the details for the Client Credentials, etc. TS 33.501 clause 13.4 may be referred here for the details. 2. In general, OAuth2 protocol is an optional feature. And its usage will depend on the operator policy. Both the static authorization defined in TS 33.501 clause 13.3.0, and OAuth2 protocol can be selected to perform the authorization for 5G. Hence, SA WG3 s suggestion would be The access to the E\/WBI APIs shall be authorized by means of OAuth2 protocol (see IETF RFC 6749 [4]), or based on static authorization . SA WG3 asks SA WG2, SA WG5 and SA WG6 to review the above technical response, which could be taken as the input for the coordinated LS response sent by TSG SA to GSMA OPAG in December. Action: SA WG3 would like to ask the SA WG2, SA WG6, SA WG5 and SA 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":10270,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6, SA WG2, SA WG5, TSG SA","Cc":"TSG CT, CT WG1, CT WG3, CT WG4","lsoriginalls":"S3-223914","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300070.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300074","title":"LS from SA WG4: Reply LS on EAS relocation affinity","source":"SA WG4","contact":"Richard Bradbury","contact-id":82569,"tdoctype":"LS in","for":"Information","abstract":"SA WG4 thanks SA WG6 for its liaison response on the subject of EAS instance placement and relocation, and is pleased to learn that SA WG6 will study this topic as KI#18 in TR 23.700-98. {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG2, SA WG5","lsoriginalls":"S4-221495","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300074.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300075","title":"LS from SA WG4: LS on split rendering in AR telephony communication","source":"SA WG4","contact":"Imed Bouazizi","contact-id":84417,"tdoctype":"LS in","for":"Action","abstract":"SA WG4 would like to thank SA WG2 for their LS on media negotiation for AR telephony communication. SA WG4 would like to point out that it has an ongoing work item on split rendering (SR_MSE), which has as objective to define a Media Service Enabler for split rendering that works with different types of applications. SA WG4 believes that the same split rendering enabler should be used for network rendering in AR communication. More specifically on the two raised questions, we would like to provide the following answers: 1. to determine which kind of information needs to be included in the media rendering negotiation request from the UE to enable network based rendering in the AR media rendering function, and The split rendering MSE will define the negotiation and configuration of a split rendering session. 2. whether this request should be send through SIP\/SDP via the IMS or through the application data channel to the AR AS. SA WG4 will define a mapping of the split rendering session negotiation and configuration onto WebRTC and IMS signalling. Action: SA WG4 would like to kindly ask SA WG2 to take the information in this reply into account for their FS_NG_RTC study.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10730,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S4-221534","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300075.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300076","title":"LS from SA WG4: Reply LS on N6 PDU Set identification","source":"SA WG4","contact":"Ahmed Hamza","contact-id":73989,"tdoctype":"LS in","for":"Action","abstract":"SA WG4 thanks SA WG2 for their LS on N6 PDU Set identification (S4-221244\/S2-2209905). SA WG2 asked SA WG4 to investigate option 2 which is to Define new protocol (e.g., RTP\/SRTP) header extensions by taking into account Network Abstraction Layer (NAL) units, RTP Payload type (e.g., H.264\/5\/6 and VP9\/AV1), etc., to identify PDU Sets in DL, including, e.g., PDU set sequence number, PDU Set size in bits, PDU Set length in number of PDUs, PDU sequence number within the PDU set. . SA WG2 also asked SA WG4 to provide timeline information so that SA WG2 can decide whether Option 2 can be considered within SA WG2 Rel-18 normative work (e.g., within Q1\/Q2 2023). SA WG4 discussed the requests from SA WG2 and would like to provide the following answers. SA WG4 will work on standardizing a new header extension for the RTP\/SRTP protocols to support the PDU Set feature within the Rel-18 timeframe (Q1\/Q2 of 2023) as part of the on-going work item on 5G Real-time Transport Protocols (5G_RTP). In developing new header extensions, SA WG4 will take into consideration the information that SA WG2 have identified as essential (i.e., what is listed in clause 8.4.2.1 of TR 23.700-60 when FS_XRM concludes) along with other PDU Set information. Action: SA WG4 kindly ask SA WG2 to take the above answers into account and invites SA WG2 to provide any feedback that is deemed helpful.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10740,"status":"postponed","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"S2-2302191","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S4-221548","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300076.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300077","title":"LS from SA WG4: Reply LS on the usage of DC application identifier in SDP","source":"SA WG4","contact":"Bo Burman","contact-id":16624,"tdoctype":"LS in","for":"Action","abstract":"At SA WG4#121 meeting, SA WG2 questions to SA WG4 in S4-221243\/S2-2209617 were discussed and SA WG4 would like to give the following answers: 1. SA WG2 is considering to support scenarios where a UE downloads multiple DC applications from a DC Server within one MMTel session. From SA WG4 perspective, how can the DC server in such a scenario associate the requested application DC with the corresponding DC application? Answer: When multiple, simultaneous DC applications are opened and if more than one of them make use of application DC, an application binding to related application DC will be necessary. No explicit binding is described by existing text. 2. How can information related to the DC application that was downloaded by the originating UE be signalled to the peer UE allowing the peer UE to download the same application with the assumption in bullet 1? Answer: There is no need to signal this explicitly to the peer UE. Both UE are connected to the same DC Server that is assumed to be aware of the call context and relates local and peer applications through their bootstrap DC streamID in that context. This is already described by TS 26.114 Table 6.2.10.1-2 that lists two application sources, the network provider (streamID 0 and 100) and the user (streamID 10 and 110), and by Figure 6.2.10.1-3 that highlights the use of streamIDs 10 and 110 in that way. 3. If multiple Data Channels are to be established by a DC application, how can the DC Server identify each Data Channel for the purpose of policy selection as indicated above? Answer: The existing TS 26.114 text leaves up to the DC Server to set the network DC media address conveyed to the local and peer UEs. For the UE-to-UE application DC, the address conveyed to a UE would be an address that is routable to the other UE. For the UE-to-network application DC, the address conveyed to a UE would be an address that is routable to a network-based peer. It is expected that one endpoint of an application DC will always be the UE but the other endpoint is application-dependent and can reasonably only be decided by the DC application itself. Considering that the DC Server has information on which DC application that is used in the session, the DC Server could also be assumed to have application metadata information on what application DC endpoint(s) that DC application makes use of. In that case, it may strictly not be necessary for the UE to also convey that information. However, it seems that a network-based application DC endpoint must be identified and addressed by the DC application, for the DC Server to provide a routable DC media address to it, which is currently not described. For the case where multiple application DC are used by the same DC application and where those application DC endpoints are different (potentially multiple, different network server addresses or the address representing the peer UE), there is some uncertainty in how those are mapped to SDP m= lines and thus which m= line that should get which address. SA WG4 will work to amend the text with a solution to the above and will inform SA WG2 when ready. Action: SA WG4 kindly requests SA WG2 to take the above answers into account.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10750,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1","lsoriginalls":"S4-221556","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300077.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300079","title":"LS from SA WG5: Reply LS on possibility of providing per UE speed and orientation on FS_eNA_Ph3","source":"SA WG5","contact":"Deepanshu Gautam","contact-id":81664,"tdoctype":"LS in","for":"Action","abstract":"SA WG5 thanks SA WG2 for the LS on possibility of providing per UE speed and orientation and would like to provide the response as follows: Q: Can OAM system provide per UE level speed and orientation to NWDAF as defined in Table 6.27.1-1(Information collected from OAM) TR23.700-81 regarding proximity analytics? SA WG5 Answer: This is very much possible. NWDAF can invoke TraceJob (clause 4.3.30 of 28.622) using Generic Provisioning Management Service (Clause 11.1 of 28.532) to get Sensor Information as part of MDT data collection mechanism. The UE sensor information includes Barometric pressure, UE speed and UE orientation (clause 5.10.29 of 32.422). Action: SA WG5 kindly asks SA WG2 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":10760,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA","lsoriginalls":"S5-226547","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300079.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300081","title":"LS from SA WG5: Reply LS to S5-226028 on Network federation interface for Telco edge consideration and proposals to answer GSMA LSs 5-226016 and S5-226017 from SA","source":"SA WG5","contact":"Deepanshu Gautam","contact-id":81664,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 would like to thank SA WG6 for the LS on Network federation interface for Telco edge consideration. SA WG5 would like to inform TSG SA and SA WG6 that SA WG5 is looking into solutions to support requirements on east\/west bound interface including edge federation in the edge computing management work and network slice management capability exposure in the management aspects of network slice management capability exposure work. SA WG5 would provide further updates as appropriate.","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":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG6","Cc":"SA WG2, SA WG3","lsoriginalls":"S5-227039","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300081.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300082","title":"LS from SA WG6: Reply LS on user s consent for EDGEAPP","source":"SA WG6","contact":"Wenliang Xu","contact-id":67079,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 thanks CT WG3 for the LS on EDGEAPP user s consent observations and related questions. This is a follow-up reply based on SA WG2 provided answer in S2-2209270. In S6-221510\/C3-223780, CT WG3 asked: Question 1 to SA WG6: For the Eees_UEIdentfier API, whether a trusted EES can directly utilize the relevant 3GPP 5GC services or can only utilize the relevant 3GPP 5GC services via the NEF? Answer 1: In S6-222555, SA WG6 replied CT WG3 that SA WG6 need to consult SA WG2 before replying CT WG3. In S2-2209270, SA WG2 replied that trusted AF bypassing NEF to obtain UE identifier is not supported in Rel-17, therefore EES can only utilize NEF service to obtain EAS specific UE identifier and a trusted EES interacting with 5GC without using NEF for obtaining EAS specific UE identifier is not supported in Rel-17.","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":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"SA WG2, SA WG3, CT WG4","lsoriginalls":"S6-223339","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300082.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300083","title":"LS from SA WG6: Reply LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","source":"SA WG6","contact":"Samar Shailendra","contact-id":93216,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 would like to thank SA WG2 for their LS response (S6-223087 \/ S2-2207394) providing information about the ongoing Rel-18 study FS_UPEAS. As part of FS_eEDGEAPP study, SA WG6 has agreed to extend Solution#23 for KI#16 - Support of NAT deployed within the edge data network, so that it allows the EAS to request a UE ID by providing UE s NATted IP address and port number. This is captured in the following sub-step of step 3 b. Alternatively (to step 3a), EES invokes the CN capability APIs for translating UE s NATed IP Address and the port number to its UE ID. Optionally, EAS may also provide UE s NATed IP address and port number to EES to obtain UE ID. and the subsequent NOTE 5: NOTE 5: For step 3.b., coordination with SA WG2 is required to check whether this can be implemented as alignment work in Rel-18. SA WG6 would like to check with SA WG2 the following: Q.1 Can SA WG2 provide support for the core network APIs (e.g., Nnef_UEId_Get) to resolve NATed IP address and Port number to UE ID as part of Rel-18 normative work? Q.2 SA WG2 mentioned The above DNN\/S-NSSAI or ipDomain attribute is not expected to be exposed outside the 5GC network . SA WG6 understands that DNN, S-NSSAI or ipDomain information can be exposed to AF in the PLMN trusted domain, and DNN\/S-NSSAI can be exposed to UE (e.g., in URSP). SA WG6 would request SA WG2 to confirm this understanding. Q.3 Can UE be provided with the ipDomain information together with UE IP address by the core network when UE IP address is allocated by the core network?. Action: SA WG6 kindly requests SA WG2 to answer the question above.","secretary_remarks":"Responses drafted in S2-2300613, S2-2300633, S2-2300920, S2-2301007, S2-2301097. Final response in S2-2302164","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10280,"status":"replied to","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG3","lsoriginalls":"S6-223487","lsreply":"S2-2302164, S2-2302164","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300083.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300084","title":"LS from SA WG6: Reply LS on Clarification of Edge Node Sharing","source":"SA WG6","contact":"Sapan Shah","contact-id":76271,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 thanks GSMA OPG for their reply LS on edge node sharing considering the mapping of GSMA OP and 3GPP EDGEAPP architecture. {. . .}","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":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA OPG","Cc":"TSG SA, SA WG2","lsoriginalls":"S6-223506","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300084.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300085","title":"LS from SA WG6: Reply LS on Network federation interface for Telco edge consideration for a consolidated reply","source":"SA WG6","contact":"Niranth Amogh","contact-id":100559,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 had sent an LS to TSG SA in S6-222543 to create a coordinated response to GSMA OPAG on the EWBI APIs. SA WG6 provides the following text to be included in the consolidated response to GSMA OPAG on this topic: SA WG6 has studied in Release 18, the enhancement to edge enabler layer in 3GPP TR 23.700-98 which addresses concepts of federation. SA WG6 has developed key issues and solutions which addresses the concept of federation and need some feedback on whether the study addresses the EWBI interface and APIs supporting federation concept proposed by GSMA OPAG. SA WG6 asks GSMA OPAG and OPG to provide their feedback on 3GPP TR 23.700-98 in view of EWBI for supporting federation.","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":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG2, SA WG3, SA WG5, TSG CT, CT WG3","lsoriginalls":"S6-223553","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300085.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300086","title":"LS from SA WG6: LS on the use of a non-network defined identifier for UE identification","source":"SA WG6","contact":"Walter Featherstone","contact-id":96406,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 has had a liaison exchange with both SA WG2 and SA WG3 on Key issue #16: support of NAT deployed within the edge data network that is provided in TR 23.700-98 and the associated Solution#23. The solution in the TR has recently been updated (S6-223543) to include an option for the edge enabler client identifier (EECID, reference clause 7.2.2 of TS 23.558) to be used by the enabler layer as an identifier of a specific UE. The definition of the EECID states that it shall be globally unique, but its specification is currently considered outside the scope of SA WG6 and it is not considered as core network defined identifier. Based on this, SA WG6 has questions to both SA WG2 and SA WG3. Questions to SA WG3: Is it considered feasible that a UE provided identifier that is not provided by the core network, specifically the globally unique EECID (reference clause 7.2.2 of TS 23.558), could be tied by the core network to a specific UE subscription in a secure manner? The motivation would be to enable such an identifier to be used by an AF, e.g., EES, to identify a specific UE to the core network in place of a UE address (i.e., IPv4\/IPv6 address or MAC address). Furthermore SA WG6, requests clarification on a EN presented in clause 8.3.3.3.2 of TS 23.558: Whether the EECID and the UE ID included in request of EDGE-1 & 4 interactions is part of the security credential is SA WG3's responsibility , specifically whether EECID is authenticated by the ECS and EES such that the EECID can be considered a verified identifier? Questions to SA WG2: Linked to the questions above, SA WG6 would also like to ask SA WG2 whether they could provide support for the core network APIs (e.g., Nnef_UEId_Get) to resolve EECID to UE ID as part of their Rel-18 normative work based on an association between the EECID and UE ID that is anticipated to be stored in the core network?. Action: SA WG6 kindly requests SA WG2 to respond on the question addressed to them in the description above.","secretary_remarks":"Responses drafted in S2-2301160, S2-2301227. Final response in S2-2302163","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10200,"status":"replied to","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3, SA WG2","Cc":"","lsoriginalls":"S6-223558","lsreply":"S2-2302163, S2-2302163","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300086.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300087","title":"LS from SA WG6: Reply LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","source":"SA WG6","contact":"Walter Featherstone","contact-id":96406,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 would like to thank SA WG3 for their LS response (S6-223096 \/ S3-223018) highlighting the security issue that arises if the network were to rely on unverifiable\/unverified information provided by the UE. In response, SA WG6 would like to ask SA WG3 whether they can offer any mechanism to support verification of information provided by a UE and if that is the case, kindly provide details on that mechanism? With regards to the completeness of solution#23 in TR 23.700-98 to resolve IP address overlap issues, SA WG2 has provided the following response through LS (S2-2207394) where SA WG3 was also copied. Use of ipDomain, in addition to a UE s private IP address, to disambiguate IP addresses between UEs is also captured in Solution #23 in TR 23.700-98 v1.3.0. SA WG6 would like SA WG3 to consider this additional information for assessing any potential security issues with an EEC sharing its private IP address with a trusted 3rd party EES. The case where multiple UEs are allocated with the same private 5GC IP address is currently addressed as follows - when this same private IP address is allocated to different UE(s) for different DNN and S-NSSAI(s) by associating the AF with a DNN and S-NSSAI - Otherwise and furthermore, the 'ipDomain' attribute as defined in TS 29.514 clause 4.2.2.2 Note 3 may be leveraged The above DNN\/S-NSSAI or ipDomain attribute is not expected to be exposed outside the 5GC network. In response to the LS from SA WG2, SA WG6 has sent a LS reply (S6-223487) seeking further clarification on the statement The above DNN\/S-NSSAI or ipDomain attribute is not expected to be exposed outside the 5GC network on which SA WG3 is also in copy.","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":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"SA WG2","lsoriginalls":"S6-223586","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300087.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300088","title":"LS from ITU-T SG13: LS on initiation of new work item Y.CCO-req: 'Requirements of orchestration supporting confidential computing for network slices in IMT-2020 networks and beyond'","source":"ITU-T SG13","contact":"Yushuang Hu","contact-id":96973,"tdoctype":"LS in","for":"Information","abstract":"This liaison statement informs about the initiation of new work item Y.CCO-req 'Requirements of orchestration supporting confidential computing for network slices in IMT-2020 networks and beyond' in Q21\/13.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10620,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ITU-T SG11, ITU-T SG17, ETSI ISG NFV, SA WG1, SA WG2, SA WG3","Cc":"","lsoriginalls":"SG13-LS39","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300088.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300089","title":"LS from ITU-T SG13: LS on the new work item Y.Arch_NGNe_ncp 'Architectural evolution of NGN control plane by applying SDN technology'","source":"ITU-T SG13","contact":"Yuan Zhang","contact-id":93840,"tdoctype":"LS in","for":"Information","abstract":"This liaison statement notifies about the creation of the new work item Y.Arch_NGNe_ncp in Q2\/13.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10770,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ITU-T SG11, SG15, 3GPP, ETSI","Cc":"","lsoriginalls":"SG13-LS43","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300089.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300090","title":"LS from TSG SA: Reply LS on QoS Sustainability analytics and V2X service adaptations","source":"TSG SA","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS in","for":"Information","abstract":"TSG SA would like to thank 5GAA WG4 regarding the LS on QoS Sustainability analytics and V2X service adaptations. The LS response below contains the consolidated answers from SA WG1 and SA WG2: {. . .}","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10360,"status":"noted","reservation_date":"2022-12-19 08:34:58","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-19","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5GAA Working Group 4, Working Group 1, Working Group 2","Cc":"SA WG1, SA WG2, SA WG6","lsoriginalls":"SP-221320","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300090.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300091","title":"LS from TSG SA: Reply LS on Network federation interface for Telco edge consideration","source":"TSG SA","contact":"Niranth Amogh","contact-id":100559,"tdoctype":"LS in","for":"Information","abstract":"TSG SA thanks GSMA OPAG for their LS on Network federation interface for Telco edge consideration and supports the collaboration efforts in order to avoid market fragmentation. TSG SA has coordinated with SA WGs on this topic and the following is the feedback: Feedback from SA WG6: SA WG6 has studied in Release 18, the enhancement to edge enabler layer in 3GPP TR 23.700-98 which addresses concepts of federation. SA WG6 has developed key issues and solutions which addresses the concept of federation and need some feedback on whether the study addresses the EWBI interface and APIs supporting federation concept proposed by GSMA OPAG. SA WG6 asks GSMA OPAG and OPG to provide their feedback on 3GPP TR 23.700-98 in view of EWBI for supporting federation. Feedback from SA WG3: Regarding clause 5 of East West Bound Interface (EWBI) APIs PRD, i.e. Transport Level Security (TLS) shall be used to support the security communication between the OPs. The access to the E\/WBI APIs shall be authorized by means of OAuth2 protocol (see IETF RFC 6749 [4]), based on local configuration, using the 'Client Credentials' authorization grant. If OAuth2 is used, a client, prior to consuming services offered by an OP E\/WBI APIs, shall obtain a 'token' from the authorization server. , SA WG3 has discussed in the details and provides the following feedbacks: 1. It would be better to give the details on how to define the procedures of the OAuth2 protocol and Client Credentials, such as which network function will take the OAuth Authorization server role, what will be included in the token, the details for the Client Credentials, etc. TS 33.501 clause 13.4 may be referred here for the details. 2. In general, OAuth2 protocol is an optional feature. And its usage will depend on the operator policy. Both the static authorization defined in TS 33.501 clause 13.3.0, and OAuth2 protocol can be selected to perform the authorization for 5G. Hence, SA WG3 s suggestion would be The access to the E\/WBI APIs shall be authorized by means of OAuth2 protocol (see IETF RFC 6749 [4]), or based on static authorization . Feedback from SA WG5: SA WG5 is looking into solutions to support requirements on east\/west bound interface including edge federation in the edge computing management work and network slice management capability exposure in the management aspects of network slice management capability exposure work. SA WG5 would provide further updates as appropriate. In addition, 3GPP considers that 'Edge Node Sharing' refers only to the case where compute resources are offered by the Partner OP to the Leading OP. TSG SA asks GSMA OPAG and GSMA OPG to consider the above feedback in their work and also provide further feedback on 3GPP work.","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":"2022-12-19 08:34:59","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA OPAG, GSMA OPG","Cc":"SA WG2, SA WG3, SA WG5, SA WG6, ETSI ISG MEC","lsoriginalls":"SP-221321","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300091.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300092","title":"LS from TSG SA: Reply LS on Use Cases and requirements for industrial factory applications","source":"TSG SA","contact":"Dimitrios Karampatsis","contact-id":72123,"tdoctype":"LS in","for":"Information","abstract":"TSG SA would like to thank 5G-ACIA for their LS requesting the status of specific use cases and requirements for supporting sidelink for industrial factory applications within 3GPP. In response to the following action to 3GPP: 5G-ACIA would like to be informed if and how these requirements have been addressed by stages 2 and 3 and if not, whether there are any ongoing or planned activities to address them. Regarding the requirements to support direct device communication for UEs supporting factory applications that belong to a private network (either standalone NPN or public-network integrated NPN). - TSG SA clarifies that the work in stage 2\/3 to date (inclusive of Release 18) on device-to-device communication focuses on commercial, V2X and public safety services. Support of device-to-device communication for deterministic services within private networks has not been addressed so far. Regarding the requirement to support positioning for a UE that is out of coverage. - TSG SA clarifies that there is ongoing work in Release 18 stage 2 to support positioning for in-coverage, out-of-coverage and partial-coverage as part of the FS_Ranging_SL study which studies 5G architecture enhancements to enable Ranging-based services and sidelink positioning for commercial, V2X and public safety services. 3GPP work is driven by company contributions, so companies interested in supporting device-to-device communication for industrial applications can propose corresponding study\/work items following the 3GPP working procedures and work plan in the related TSGs and Working Groups.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10780,"status":"noted","reservation_date":"2022-12-19 08:34:59","uploaded":"2022-12-19 12:42:51","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5G-ACIA","Cc":"TSG CT, TSG RAN, SA WG1, SA WG2","lsoriginalls":"SP-221322","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300092.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300216","title":"[DRAFT] Reply LS on handling of the allowed PDU session status IE","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to provide SA WG2 answers related to the issues raised by CT WG1 LS C1-227197","secretary_remarks":"Response to S2-2300029. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"noted","reservation_date":"2023-05-01 22:06:58","uploaded":"2023-01-09 21:41:01","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"5GProtoc18"},{"winame":" TEI18"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300216.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300217","title":"Non-allowed area clarification","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify the 3GPP access UP resource handling in non-allowed area.","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-05-01 22:06:58","uploaded":"2023-01-09 21:41:01","revisionof":"","revisedto":"S2-2302318","release":"Rel-18","crspec":"23.501","crspecversion":"18.0.0","workitem":[{"winame":"5GProtoc18"},{"winame":" TEI18"}],"crnumber":3846.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300217.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"5.3.4.1.1","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300339","title":"[DRAFT] Reply LS on 5G capabilities exposure for factories of the future identified gaps (5G-ACIA-LS-2022-005 \/ S2-220xxxx)","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Proposes a reply LS to SA with SA WG2 feedback on the 5G-ACIA LS.","secretary_remarks":"Response to S2-2300009. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10550,"status":"noted","reservation_date":"2023-06-01 14:38:22","uploaded":"2023-01-09 17:42:14","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"TSG CT, SA WG1, SA WG3, SA WG5, SA WG6","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300339.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300530","title":"[DRAFT] Reply LS on Handling of the Allowed PDU session status IE","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"Reply the LS on Handling of the Allowed PDU session status IE in Non-allowed service area","secretary_remarks":"Response to S2-2300029. 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-09-01 07:14:55","uploaded":"2023-01-09 13:31:58","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"5GProtoc18"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300530.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300531","title":"TS 23.501: Clarification of handling of the non-3GPP PDU session in Non-allowed service area","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify that the AMF shall not trigger the paging and shall reject the request from SMF holding the Non-3GPP PDU session context, as the AMF knows the UE is in the Non-Allowed Area and so the user plane cannot be activated via 3GPP access even if the PDU session of Non-3GPP access type is transferred to 3GPP access type.","secretary_remarks":"Revised to S2-2302162.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"revised","reservation_date":"2023-09-01 07:14:55","uploaded":"2023-01-09 13:31:58","revisionof":"","revisedto":"S2-2302162","release":"Rel-18","crspec":"23.501","crspecversion":"18.0.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":3928.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300531.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"5.3.4.1.1, 5.6.8","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300532","title":"TS23.502: Clarification of handling of the non-3GPP PDU session in Non-allowed service area","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify that the AMF shall not trigger the paging and shall reject the request from SMF holding the Non-3GPP PDU session context, as the AMF knows the UE is in the Non-Allowed Area and so the user plane cannot be activated via 3GPP access even if the PDU session of Non-3GPP access type is transferred to 3GPP access type.","secretary_remarks":"Revised to S2-2302161.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"revised","reservation_date":"2023-09-01 07:14:58","uploaded":"2023-01-09 13:31:58","revisionof":"","revisedto":"S2-2302161","release":"Rel-18","crspec":"23.502","crspecversion":"18.0.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":3742.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300532.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"4.2.3.3","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300562","title":"[DRAFT] Reply LS on Handling of the Allowed PDU session status IE in Non-allowed service area","source":"LG Electronics","contact":"Myungjune Youn","contact-id":60905,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1","secretary_remarks":"Response to S2-2300029. 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-09-01 07:36:11","uploaded":"2023-01-09 13:20:47","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300562.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300604","title":"[DRAFT] Reply LS on Handling of the Allowed PDU session status IE in Non-allowed service area","source":"OPPO","contact":"Fei Lu","contact-id":87831,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS of C1-227197","secretary_remarks":"Response to S2-2300029. 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-09-01 07:56:09","uploaded":"2023-01-09 09:28:32","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"5GProtoc18"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300604.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300613","title":"[DRAFT] LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","secretary_remarks":"Response to S2-2300083. Merged into S2-2302164","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10340,"status":"merged","reservation_date":"2023-09-01 07:57:47","uploaded":"2023-01-09 17:13:36","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300613.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300614","title":"[DRAFT] LS on Identifier availability for Lawful Interception during Inter-PLMN handover","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"[draft] LS on Identifier availability for Lawful Interception during Inter-PLMN handover","secretary_remarks":"Response to S2-2300034 (and S2-2210210, noted at SA2#154-e). Revised to S2-2302165.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10380,"status":"revised","reservation_date":"2023-09-01 07:57:47","uploaded":"2023-01-09 20:54:52","revisionof":"","revisedto":"S2-2302165","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"LI18"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, SA WG3-LI","Cc":"SA WG3, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300614.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300615","title":"Identifier availability for Lawful Interception during Inter-MME\/ MME-5GS handover","source":"Nokia, Nokia Shanghai Bell, Vodafone","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add transfer of MSISDN between MME(s) at inter MME mobility events where user data can flow before the Serving GW can currently obtain the MSISDN.","secretary_remarks":"Revised to S2-2302167.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10420,"status":"revised","reservation_date":"2023-09-01 07:57:48","uploaded":"2023-01-09 20:54:52","revisionof":"","revisedto":"S2-2302167","release":"Rel-18","crspec":"23.401","crspecversion":"18.0.0","workitem":[{"winame":"LI18"}],"crnumber":3720.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300615.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"5.5.1.2.2; 5.3.3.1","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300616","title":"Identifier availability for Lawful Interception during MME-5GS handover","source":"Nokia, Nokia Shanghai Bell, Vodafone","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add transfer of MSISDN between AMF and MME at 4G-5G mobility based on N26 Note that changes to following clauses are not needed 4.11.1.2.1 5GS to EPS handover using N26 interface already contains: The AMF sends a Forward Relocation Request as in step 3 in clause 5.5.1.2.2 (S1-based handover, normal) in TS 23.401 4.11.1.2.2 EPS to 5GS handover using N26 interface already contains: Step 3 from clause 5.5.1.2.2 (S1-based handover, normal) in TS 23.401 [13] with the following modifications","secretary_remarks":"Revised to S2-2302166.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10400,"status":"revised","reservation_date":"2023-09-01 07:58:05","uploaded":"2023-01-09 20:54:52","revisionof":"","revisedto":"S2-2302166","release":"Rel-18","crspec":"23.502","crspecversion":"18.0.0","workitem":[{"winame":"LI18"}],"crnumber":3757.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300616.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"4.11.1.3.2 ; 4.11.1.3.3","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300617","title":"5G NSWO clarifications and corrections","source":"Nokia, Nokia Shanghai Bell, Intel","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: As a non-3GPP access network may be connected to multiple local PLMNs for 5G NSWO, a UE when roaming shall be able to indicate a specific visited PLMN through which the NSWO request should be sent. In both roaming and non-roaming scenarios, the NSWOF acts towards the WLAN Access as a 3GPP AAA server. Adding SWa reference point that corresponds to SWa as defined in TS 23.402 [43] with the difference that SWa terminates at the NSWOF and that the EAP user ID is a SUCI and not an IMSI.","secretary_remarks":"Revised to S2-2302169.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10470,"status":"revised","reservation_date":"2023-09-01 07:58:13","uploaded":"2023-01-09 17:13:36","revisionof":"","revisedto":"S2-2302169","release":"Rel-17","crspec":"23.501","crspecversion":"17.7.0","workitem":[{"winame":"NSWO_5G"}],"crnumber":3947.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300617.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"5.42 ; 4.2.15","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300618","title":"5G NSWO clarifications and corrections","source":"Nokia, Nokia Shanghai Bell, Intel","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Rel-18 mirror CR: Summary of change: As a non-3GPP access network may be connected to multiple local PLMNs for 5G NSWO, a UE when roaming shall be able to indicate a specific visited PLMN through which the NSWO request should be sent. In both roaming and non-roaming scenarios, the NSWOF acts towards the WLAN Access as a 3GPP AAA server. Adding SWa reference point that corresponds to SWa as defined in TS 23.402 [43] with the difference that SWa terminates at the NSWOF and that the EAP user ID is a SUCI and not an IMSI.","secretary_remarks":"Revised to S2-2302170.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10490,"status":"revised","reservation_date":"2023-09-01 07:58:18","uploaded":"2023-01-09 17:13:36","revisionof":"","revisedto":"S2-2302170","release":"Rel-18","crspec":"23.501","crspecversion":"18.0.0","workitem":[{"winame":"NSWO_5G"}],"crnumber":3948.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300618.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"5.42; 4.2.15","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300619","title":"[DRAFT] LS on NSWO feature","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"[draft] LS on NSWO feature","secretary_remarks":"Response to S2-2300020. Revised to S2-2302168.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10450,"status":"revised","reservation_date":"2023-09-01 07:58:22","uploaded":"2023-01-09 17:13:36","revisionof":"","revisedto":"C1-230044, S2-2302168","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NSWO_5G"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300619.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300620","title":"[DRAFT] LS on NAI format for 5G NSWO","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"[draft] LS on NAI format for 5G NSWO","secretary_remarks":"Response to S2-2300037. Revised to S2-2302171.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10520,"status":"revised","reservation_date":"2023-09-01 07:58:22","uploaded":"2023-01-09 17:13:36","revisionof":"","revisedto":"C1-230045, S2-2302171","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NSWO_5G"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"CT WG1, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300620.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300633","title":"[DRAFT] Reply LS on Reply LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","source":"China Mobile","contact":"Yan Han","contact-id":93044,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6. CC: SA WG3. Attachments: 23.501 CR and 23.502 CR","secretary_remarks":"Response to S2-2300083. Merged into S2-2302164","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10290,"status":"merged","reservation_date":"2023-09-01 08:12:20","uploaded":"2023-01-09 13:23:54","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"FS_eEDGEAPP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300633.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2300920","title":"[DRAFT] Reply LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","secretary_remarks":"Response to S2-2300083. Merged into S2-2302164","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"merged","reservation_date":"2023-09-01 12:07:39","uploaded":"2023-01-09 19:09:35","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"UPEAS"},{"winame":" FS_eEDGEAPP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2300920.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2301007","title":"[DRAFT] Reply LS on support of NAT deployed within the edge data network","source":"Apple","contact":"Sudeep M Vamanan","contact-id":87305,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6. CC: SA WG3","secretary_remarks":"Response to S2-2300083. Merged into S2-2302164","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"merged","reservation_date":"2023-09-01 13:47:23","uploaded":"2023-01-09 20:48:32","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2301007.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2301070","title":"[DRAFT] Reply LS on handling of the Allowed PDU Session status IE in Non-allowed Area","source":"Nokia, Nokia Shanghai Bell","contact":"Hannu Hietalahti","contact-id":69922,"tdoctype":"LS out","for":"Approval","abstract":"Answer to C1 question on Allowed PDU Session IE","secretary_remarks":"Response to S2-2300029. 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-09-01 14:36:12","uploaded":"2023-01-09 16:16:05","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"5GProtoc18"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2301070.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2301097","title":"[DRAFT] Reply LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","source":"Intel","contact":"Saso Stojanovski","contact-id":24932,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6. CC: SA WG3. Attachments: 23501CR3829, 23.502CR3675","secretary_remarks":"Response to S2-2300083. Revised to S2-2302164, merging S2-2300633, S2-2300920, S2-2301007 and S2-2300613","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"revised","reservation_date":"2023-09-01 14:57:27","uploaded":"2023-01-09 17:49:19","revisionof":"","revisedto":"S2-2302164","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"FS_eEDGEAPP"},{"winame":" UPEAS"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2301097.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2301160","title":"[DRAFT] Reply LS on the use of a non-network defined identifier for UE identification","source":"Intel","contact":"Saso Stojanovski","contact-id":24932,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6. CC: SA WG3","secretary_remarks":"Response to S2-2300086. Merged into S2-2302163","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"merged","reservation_date":"2023-09-01 16:20:01","uploaded":"2023-01-09 17:49:19","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2301160.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2301189","title":"[DRAFT] Reply LS on 5G capabilities exposure for factories of the future identified gaps","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS on 5G capabilities exposure for factories of the future identified gaps","secretary_remarks":"Response to S2-2300009. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10560,"status":"noted","reservation_date":"2023-09-01 16:37:46","uploaded":"2023-01-09 17:13:33","revisionof":"","revisedto":"S2-2302854","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG1, SA WG3, SA WG5, SA WG6","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2301189.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2301227","title":"[DRAFT] LS on the use of a non-network defined identifier for UE identification","source":"Nokia Belgium","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6, SA WG3","secretary_remarks":"Response to S2-2300086. Revised to S2-2302163, merging S2-2301160","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"revised","reservation_date":"2023-09-01 17:55:49","uploaded":"2023-01-09 20:54:52","revisionof":"","revisedto":"S2-2302163","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"FS_eEDGEAPP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6, SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2301227.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2301276","title":"[DRAFT] Reply LS on Handling of the Allowed PDU session status IE in Non-allowed service area","source":"Samsung","contact":"Lalith Kumar","contact-id":80547,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1","secretary_remarks":"Response to S2-2300029. 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-09-01 20:44:57","uploaded":"2023-01-09 20:48:33","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2301276.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302161","title":"TS23.502: Clarification of handling of the non-3GPP PDU session in Non-allowed service area","source":"Huawei, HiSilicon, LG Electronics, Apple","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify that the AMF shall not trigger the paging and shall reject the request from SMF holding the Non-3GPP PDU session context, if the AMF knows the UE is in the Non-Allowed Area and so the user plane cannot be activated via 3GPP access even if the PDU session of Non-3GPP access type is transferred to 3GPP access type.","secretary_remarks":"Revision of S2-2300532. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"agreed","reservation_date":"2023-01-24 07:50:19","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300532","revisedto":"","release":"Rel-18","crspec":"23.502","crspecversion":"18.0.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":3742.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-230080","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302161.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":false,"me_affected":false,"ran_affected":false,"cn_affected":true,"clauses_affected":"4.2.3.3","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302162","title":"TS 23.501: Clarification of handling of the non-3GPP PDU session in Non-allowed service area","source":"Huawei, HiSilicon, Apple","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify that the AMF shall not trigger the paging and shall reject the request from SMF holding the Non-3GPP PDU session context, if the AMF detects the UE is in the Non-Allowed Area and so the user plane cannot be activated via 3GPP access even if the PDU session of Non-3GPP access type is transferred to 3GPP access type.","secretary_remarks":"Revision of S2-2300531. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"agreed","reservation_date":"2023-01-24 07:50:20","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300531","revisedto":"","release":"Rel-18","crspec":"23.501","crspecversion":"18.0.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI18"}],"crnumber":3928.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-230080","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302162.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302163","title":"LS on the use of a non-network defined identifier for UE identification","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6, SA WG3","secretary_remarks":"Revision of S2-2301227, merging S2-2301160. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10230,"status":"approved","reservation_date":"2023-01-24 07:50:21","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2301227","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"FS_eEDGEAPP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2300086","lsto":"SA WG6, SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302163.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302164","title":"Reply LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","source":"SA WG2","contact":"Saso Stojanovski","contact-id":24932,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6. CC: SA WG3. Attachments: S2-2301390 (23501 CR3825), S2-2301393 (23.502 CR3666)","secretary_remarks":"Revision of S2-2301097, merging S2-2300633, S2-2300920, S2-2301007 and S2-2300613. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"approved","reservation_date":"2023-01-24 07:50:21","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2301097","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"FS_eEDGEAPP"},{"winame":" UPEAS"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2300083","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302164.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302165","title":"LS on Identifier availability for Lawful Interception during Inter-PLMN handover","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG4, SA WG3-LI. CC: SA WG3, CT WG3. Attachments: CR 3720 to 23.401, CR 3757 to 23.502","secretary_remarks":"Revision of S2-2300614. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10390,"status":"approved","reservation_date":"2023-01-24 07:50:21","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300614","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"LI18"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2300034","lsto":"CT WG4, SA WG3-LI","Cc":"SA WG3, CT WG3","lsoriginalls":"","lsreply":"C4-230177, C4-230628","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302165.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302166","title":"Identifier availability for Lawful Interception during MME-5GS handover","source":"Nokia, Nokia Shanghai Bell, Vodafone","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add transfer of MSISDN between AMF and MME at 4G-5G mobility based on N26 Note that changes to following clauses are not needed 4.11.1.2.1 5GS to EPS handover using N26 interface already contains: The AMF sends a Forward Relocation Request as in step 3 in clause 5.5.1.2.2 (S1-based handover, normal) in TS 23.401 4.11.1.2.2 EPS to 5GS handover using N26 interface already contains: Step 3 from clause 5.5.1.2.2 (S1-based handover, normal) in TS 23.401 [13] with the following modifications","secretary_remarks":"Revision of S2-2300616. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10410,"status":"agreed","reservation_date":"2023-01-24 07:50:22","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300616","revisedto":"","release":"Rel-18","crspec":"23.502","crspecversion":"18.0.0","workitem":[{"winame":"LI18"}],"crnumber":3757.0,"crrevision":1.0,"crcategory":"B","tsg_crp":"SP-230069","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302166.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302167","title":"Identifier availability for Lawful Interception during Inter-MME\/ MME-5GS handover","source":"Nokia, Nokia Shanghai Bell, Vodafone","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add transfer of MSISDN between MME(s) at inter MME mobility events where user data can flow before the Serving GW can currently obtain the MSISDN.","secretary_remarks":"Revision of S2-2300615. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10430,"status":"agreed","reservation_date":"2023-01-24 07:50:23","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300615","revisedto":"","release":"Rel-18","crspec":"23.401","crspecversion":"18.0.0","workitem":[{"winame":"LI18"}],"crnumber":3720.0,"crrevision":1.0,"crcategory":"B","tsg_crp":"SP-230069","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302167.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302168","title":"LS on NSWO feature","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1. CC: CT WG4, SA WG3. Attachments: CR 3947 to 23.501","secretary_remarks":"Revision of S2-2300619. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10460,"status":"approved","reservation_date":"2023-01-24 07:50:24","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300619","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NSWO_5G"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2300020","lsto":"CT WG1","Cc":"CT WG4, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302168.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302169","title":"5G NSWO clarifications and corrections","source":"Nokia, Nokia Shanghai Bell, Intel, Ericsson","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: As a non-3GPP access network may be connected to multiple local PLMNs for 5G NSWO, a UE when roaming shall be able to indicate a specific visited PLMN through which the NSWO request should be sent. In both roaming and non-roaming scenarios, the NSWOF acts towards the WLAN Access as a 3GPP AAA server. Adding SWa reference point that corresponds to SWa as defined in TS 23.402 [43] with the difference that SWa terminates at the NSWOF and that the EAP user ID is a SUCI and not an IMSI.","secretary_remarks":"Revision of S2-2300617. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10480,"status":"agreed","reservation_date":"2023-01-24 07:50:24","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300617","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"17.7.0","workitem":[{"winame":"NSWO_5G"}],"crnumber":3947.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-230043","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302169.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302170","title":"5G NSWO clarifications and corrections","source":"Nokia, Nokia Shanghai Bell, Intel","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Rel-18 mirror CR: Summary of change: As a non-3GPP access network may be connected to multiple local PLMNs for 5G NSWO, a UE when roaming shall be able to indicate a specific visited PLMN through which the NSWO request should be sent. In both roaming and non-roaming scenarios, the NSWOF acts towards the WLAN Access as a 3GPP AAA server. Adding SWa reference point that corresponds to SWa as defined in TS 23.402 [43] with the difference that SWa terminates at the NSWOF and that the EAP user ID is a SUCI and not an IMSI.","secretary_remarks":"Revision of S2-2300618. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10500,"status":"agreed","reservation_date":"2023-01-24 07:50:25","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300618","revisedto":"","release":"Rel-18","crspec":"23.501","crspecversion":"18.0.0","workitem":[{"winame":"NSWO_5G"}],"crnumber":3948.0,"crrevision":1.0,"crcategory":"A","tsg_crp":"SP-230043","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302170.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2302171","title":"LS on NAI format for 5G NSWO","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG4. CC: CT WG1, SA WG3. Attachments: CR 3947 to 23.501","secretary_remarks":"Revision of S2-2300620. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10530,"status":"approved","reservation_date":"2023-01-24 07:50:26","uploaded":"2023-01-24 08:01:10","revisionof":"S2-2300620","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NSWO_5G"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2300037","lsto":"CT WG4","Cc":"CT WG1, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154AHE_Electronic_2023-01\/Docs\/S2-2302171.zip","group":"S2","meeting":"S2-154-AH-e","year":2023,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0}]