[{"name":"S2-2210167","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-2208111 from SA2#153E","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10030,"status":"available","reservation_date":"2022-10-21 13:22:35","uploaded":"2022-10-25 12:17:21","revisionof":"S2-2208111","revisedto":"S2-2300003","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_154_Toulouse_2022-11\/Docs\/S2-2210167.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210169","title":"LS from CT WG3: Reply LS on Traffic Identification within 5G Media Streaming","source":"CT WG3","contact":"Jedrzej Stanczak","contact-id":68469,"tdoctype":"LS in","for":"Action","abstract":"CT WG3 would like to thank SA WG2 for the LS on Traffic Identification within 5G Media Streaming. CT WG3 would like to feedback to SA WG2 questions mentioned on CT WG3 in LS C3-224022\/S2-2204725. SA WG2 Question 1: 'SA WG2 discussed the solution in the attached TS 23.502 CR3431 (not agreed yet). SA WG2 understands that currently stage 3 specification has a note stating that ToS\/TC cannot be provided on this interface, and SA WG2 would like to understand if CT WG3 has any concern in including ToS\/TC on the N33 interface with a condition e.g. operator and the Service Provider needs to ensure, via SLA, there is no ToS\/TC remarking applied from the application to the PSA UPF and the specific ToS\/TC values are managed properly to avoid potential collision with other usage .' CT WG3 Feedback 1: If stage 2 can clarify the condition to prevent ToS\/TC remarking and ToS\/TC values collision with other usage along the path between the PSA UPF and the external AF, CT WG3 currently has no","secretary_remarks":"Revision of Postponed S2-2208130 from SA2#153E. Response drafted in S2-2210247","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"available","reservation_date":"2022-10-21 13:22:35","uploaded":"2022-10-25 12:17:21","revisionof":"S2-2208130","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C3-224556","lsreply":"S2-2211127","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210169.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210171","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-2208133 from SA2#153E","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"available","reservation_date":"2022-10-21 13:22:35","uploaded":"2022-10-25 12:17:21","revisionof":"S2-2208133","revisedto":"S2-2300005","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_154_Toulouse_2022-11\/Docs\/S2-2210171.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210178","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-2208158 from SA2#153E","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"available","reservation_date":"2022-10-21 13:22:35","uploaded":"2022-10-25 12:17:21","revisionof":"S2-2208158","revisedto":"S2-2300007","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_154_Toulouse_2022-11\/Docs\/S2-2210178.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210180","title":"LS from MITRE Engenuity Open Generation 5G Consortium:","source":"MITRE Engenuity Open Generation 5G Consortium","contact":"Jiayao Tan","contact-id":90833,"tdoctype":"LS in","for":"Action","abstract":"Background: MITRE Engenuity Open Generation 5G Consortium understands that SA WG2 has been studying how PC5 \/ side link could be used to support Detect and Avoid (DAA) and broadcast Remote ID, with key issues and solutions being documented in 3GPP TR23.700-58. Open Generation would like to inform SA WG2 that it has performed some initial experiments in the field of DAA for UAs using 3GPP technology. As part of these experiments Open Generation has taken off-the-shelf C-V2X commercial implementations and performed a test to see how C-V2X could be used as a DAA solution. The experiments were designed to be proof of concept to see how PC5 \/ side link functionally perform for UA DAA operations. Initial tests consisted of flying 2 UASs and gathering KPIs to see if C-V2X should be investigated further in more complex scenarios \/ use cases and performing actions based on UA flight characteristics. Recommendation: Open Generation would like to report that the PC5 \/ side link using a","secretary_remarks":"Revision of Postponed S2-2208168 from SA2#153E. Response drafted in S2-2210843","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"available","reservation_date":"2022-10-21 13:22:35","uploaded":"2022-10-25 12:17:21","revisionof":"S2-2208168","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"OG0022","lsreply":"S2-2211125","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210180.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210182","title":"LS from 5GAA WG4, WG1, WG2: LS on QoS Sustainability analytics and V2X service adaptations","source":"5GAA WG4, WG1, WG2","contact":"Lei Yixue","contact-id":73172,"tdoctype":"LS in","for":"Action","abstract":"A 5GAA cross-WI called PRESA has been studying QoS prediction and V2X service adaptation, considering also pre-Rel18 features which have been standardized by 3GPP [1], [2] and Rel-18 features which are under study in FS_AIMLsys [3] , eNA_Ph3 [4] related to QoS sustainability analytics. In PRESA work item, three representative use cases have been analyzed, including: Tele-operated Driving, as an example of session-based use cases. Infrastructure-assisted environment perception, as an example of periodic use cases. Cooperative Lane Merge, as an example of short-time lived use cases. According to the above use case analysis, system requirements as well as open issues have been identified. Previous WIs, NESQO\/eNESQO had also identified some requirements or areas of improvement (AOI) for QoS prediction. All the above-mentioned requirements\/AOIs and open issues have been captured in Section 6.1 and 6.2 of the attached 5GAA PRESA TR, respectively. 5GAA would like to recommend SA WG1 and SA WG2 to review Section 6.1 and 6.2 and take the outcome of the 5GAA WI into account and also would like to ask the following questions. - Q1: whether these requirements and area of improvements are expected to be covered by Release 18 and - in case they are not covered - whether any 3GPP work is planned beyond Release 18, and specifically answer the following questions: o Q.1.1: In the context of Requirement 1 Increase granularity of QoS predictions (e.g., below Cell level, more KPIs reporting, richer information, aware of the specific UE context) also by means of more input data to the analytics enabler (e.g. from core network, RAN, etc.) 5GAA believes that this has been partially addressed in [4], KI#7. According to currently proposed solutions, the 3GPP System is capable of retrieving the UE list for a finer granular area smaller than the cell, and use such UE list to retrieve QoS measurements and other additional input data that can be used for the calculation of higher accuracy QoS Sustainability analytics: Q.1.1.1: Will the UE list be determined only once when the consumer request is received or will 3GPP system capable of keeping the UE list up to date, over time while serving a specific consumer request? In the second case, 3GPP is expected to exclude from the UE list the UEs that are moving out of the finer granular area and adding to the UE list the new UEs that are entering the finer granular area, for the whole time that data collection is required and until the analytics output is provided to the consumer. Q.1.1.2: What accuracy in the determination of the location can be expected in order to determine the UE list? Q.1.1.3: What is the delay that can be assumed between the time in which the UE position is collected to determine whether it is in the finer granular area and the time when the QoS measurement or other input data for the related UE is collected by the NWDAF? Can such delay impact the accuracy of the QoS measurement and of the analytics? Q.1.1.4: Will the additional input data for the UE in the UE list (QoS measurements, UE info, subscription info, etc.) be collected for all the UEs in the UE list or only for the UEs in such list which are experiencing QoS issues? In the second case input data may limit the possibility to use QoS Sustainability for UEs not experiencing QoS issues, or for QoS prediction related to QoS improvement. Q.1.1.5: Will the 3GPP System collect the additional input data for the UEs (QoS measurements, etc.) in the UE list only after the consumer has subscribed to the analytics, or are there mechanisms to collect such info before the consumer has subscribed? 5GAA believes that in the first case consumer may have to wait a long time for the analytics to be available to the consumer. This may depend on the analytics filter information provided by the consumer and whether the consumer request is the first that has been received by the NWDAF for the relevant finer granular area. This delay in the provisioning","secretary_remarks":"Response drafted in S2-2210736","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":0,"status":"available","reservation_date":"2022-10-21 13:22:35","uploaded":"2022-10-25 15:47:31","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"FS_AIMLsys"},{"winame":" FS_eNA_Ph3"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG1","Cc":"","lsoriginalls":"S-220077","lsreply":"S2-2211411","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210182.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210183","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":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"available","reservation_date":"2022-10-21 13:22:35","uploaded":"2022-10-26 16:03:08","revisionof":"","revisedto":"S2-2300009","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_154_Toulouse_2022-11\/Docs\/S2-2210183.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210187","title":"LS from RAN WG1: Reply LS on Terminology Alignment for Ranging\/Sidelink Positioning","source":"RAN WG1","contact":"Qun Zhao","contact-id":73547,"tdoctype":"LS in","for":"Action","abstract":"RAN WG1 would like to thank SA WG2 for the LS (R1-2208338\/S2-2207129) on terminology alignment for ranging\/sidelink positioning. RAN WG1 would like to provide the following feedback. From RAN WG1 perspective, there is no difference between Anchor UE and SL reference UE, and RAN WG1 assumes that any distinction between Assistant UE and SL reference UE is transparent to RAN WG1. RAN WG1 asks SA WG2 to take this into account and decide whether to further update the terminologies defined by SA WG2. Action: RAN WG1 respectfully asks SA WG2 to take the above information into account.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-10-26 16:03:09","revisionof":"","revisedto":"S2-2300012","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"RAN WG2, RAN WG3","lsoriginalls":"R1-2210567","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210187.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210189","title":"LS from RAN WG2: Response to 'Reply to LS on UE capability signaling for IoT-NTN'","source":"RAN WG2","contact":"Srinivasan Selvaganapathy","contact-id":70008,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 thanks SA WG2 for their LS Reply on IoT-NTN UE capabilities. RAN WG2 has analyzed the two options proposed by SA WG2 for overall specification impacts and functionality impacts. Option 1: Single container is used for eMTC and NB-IoT including both TN and NTN capabilities. Option 2: Separate containers are maintained for TN and NTN for IoT-NTN UE, i.e., UE reports its E-UTRAN radio access capabilities depending on the network type (TN or NTN) to which it is connected. Based on the analysis RAN WG2 concluded that option 2 is preferred from the RAN WG2 perspective which is aligned with previous RAN WG2 agreements on TN and NTN capabilities of IoT-NTN. RAN WG2 also acknowledges that option 2 may require some change to CT WG1 specifications (e.g., new TAU trigger for UE capability update procedure when transitioning between TN and NTN). RAN WG2 intends to further discuss in the next meeting whether enhancements are needed in Rel-17 due to its preference on option 2 (e.g., Connected mode mobility support, RACS support for eMTC-NTN). These enhancements may have some additional impacts on other working groups. Action: RAN WG2 requests SA WG2 to consider the above as a response to SA WG2 s analysis on the RAN WG2 agreements and provide further feedback if necessary.","secretary_remarks":"Response drafted in S2-2210698","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-10-26 16:03:09","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1, RAN WG3","lsoriginalls":"R2-2210829","lsreply":"S2-2211431","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210189.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210192","title":"LS from RAN WG2: Reply LS on Terminology Alignment for Ranging\/Sidelink Positioning","source":"RAN WG2","contact":"XIAOWEI JIANG","contact-id":66759,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 would like to thank SA WG2 for the LS on terminology alignment for ranging\/sidelink positioning. RAN WG2 agreed to adopt the following terminologies defined by RAN WG1: {. . .} RAN WG2 does not see conflicts on these terminologies with SA WG2 definition (SL reference UE refers to anchor UE). {. . .} For the terminology of Network assisted Operation, the use of assisted by SA WG2 is not aligned with TS 38.305 {. . .}. Action: RAN WG2 kindly ask SA WG2 to take above information into consideration.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-10-26 16:03:09","revisionof":"","revisedto":"S2-2300013","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"RAN WG1, RAN WG3","lsoriginalls":"R2-2210982","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210192.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210200","title":"LS from SA WG3: Reply LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network","source":"SA WG3","contact":"Abhijeet Kolekar","contact-id":66157,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 would like to thank the SA WG6 for their LS on FS_eEDGEAPP Solution for Support of NAT deployed within the edge data network. Regarding whether there is security issue if the EEC share its private IP address with a trusted 3rd party EES. If yes, could SA WG3 address security issues related to this , SA WG3 agreed that, in general, it is not desirable for the network to rely on unverifiable\/unverified information provided by the UE. The security issue is that such information can be faked and thus can be used to impersonate a UE. Moreover, SA WG3 has observed that the solution suggested by SA WG6 is incomplete. A private IP address can be shared by multiple UEs. In order to disambiguate this IP address, additional information needs to be used\/provided. Providing\/disclosing this as yet unspecified additional information may have its own security risks. Without further information on the intended complete solution, however, SA WG3 cannot assess these risks.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-10-26 16:03:08","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG2","lsoriginalls":"S3-223018","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210200.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210202","title":"LS from SA WG3: Reply LS on NCR Solutions","source":"SA WG3","contact":"Yuze Liu","contact-id":97142,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 would like to thank the RAN WG3 for their LS on NCR Solutions. SA WG3 has further discussion on the Questions from RAN WG3 and would like to share the views as below: To SA WG3 Q1a: Is there any security issue for solution 2 which does not provide Uu security, non-protected NCR indication info and the OAM container in Step 5? Answer to RAN WG3: Yes. For solution 2, SA WG3 believes that this information can be tampered due to the lack of Uu security. It exposes the OAM indirectly to attacks over the air interface. To SA WG3 Q1b: Does SA WG3 believe that the NCR needs to be securely validated? Any security issue for configuring locally stored information in the gNB in Solution 1? Answer to RAN WG3: For the 1st question in Q1b, SA WG3 is not clear about what does 'validation' mean. For the 2nd question in Q1b, SA WG3 cannot provide answers before the security validation related steps in solution1 are clarified. In addition, the feasibility of such additional steps and what kind of information is stored in RAN are also unclear. Further clarification is expected.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-10-26 16:03:08","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"RAN WG2, SA WG2, SA WG5","lsoriginalls":"S3-223080","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210202.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210205","title":"LS from SA WG6: LS on PIN Management","source":"SA WG6","contact":"Arunprasath Ramamoorthy","contact-id":85694,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 is currently studying Application layer support for Personal IoT Network as part of a Release 18 Study Item (FS_PINAPP). Currently in 3GPP TS 22.261, Establishing duration of the PIN is included as part of PIN management requirements. SA WG6 is considering an intermediary state (Active and not-active) for the PIN between creation and deletion of PIN to address this requirement. With this capability, the PIN owner\/admin would be able to temporarily suspend the PIN when required and can activate the PIN without going through the process of creating the PIN. This would be advantageous when the duration of the PIN is set as Valid during 9AM to 5PM everyday , Valid only during weekdays . 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.? Question 2 to SA WG1: Whether the PIN owner or Admin can be able to suspend the PIN temporarily as part of PIN management? Question 3 to SA WG2: Has SA WG2 considered this perspective and would SA WG2 consider this functionality in scope of SA WG2 solutions (depending on SA WG1 responses on the validity of the SA WG6 interpretation of the requirement)?. Action: SA WG6 asks SA WG2 to provide answer for above question upon reception of the SA WG1 responses.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-10-26 16:03:08","revisionof":"","revisedto":"S2-2300015","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2","Cc":"","lsoriginalls":"S6-222870","lsreply":"S2-2301044","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210205.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210206","title":"LS from SA WG6: LS on Support PIN application architecture and interaction","source":"SA WG6","contact":"Huazhang Lv","contact-id":75760,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 is currently studying the Study on Application layer support for Personal IoT Network as part of a Release 18 Study Item (FS_PINAPP). As a part of the study, some of the solutions in PINAPP (refer to 3GPP TR 23.700-78) are referred to the procedures defined in SA WG2 and SA WG3. SA WG6 would like to share some questions in order to complete and aligned these solutions. {. . .}. Action: SA WG6 asks SA WG2 and SA WG3 to kindly consider above request and provide answers.","secretary_remarks":"Response drafted in S2-2210665","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10180,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-10-26 16:03:08","revisionof":"","revisedto":"S2-2300016","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3","Cc":"","lsoriginalls":"S6-223028","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210206.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210208","title":"LS from SA WG6: LS on Network Parameters Configuration by IoT Platforms","source":"SA WG6","contact":"Catalina Mladin","contact-id":81603,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 has identified and studied SEAL functionality to support application capability exposure to general purpose servers or 3rd party IoT applications via IoT Platforms as part of FS_ACE_IoT. Key issues and corresponding solutions necessary to ensure efficient use and deployment of IoT Platforms in the 5G network have been captured in 3GPP TR 23.700-97, including Key issue #3 on IoT Platform PSM monitoring and configuration. {. . .}. Action: SA WG6 asks SA WG2 to review the clause 5.7 solution in 3GPP TR 23.700-97 V 1.1.0 and to provide feedback related to the SA WG6 solution for aggregation of network parameter configurations at IoT-PCS level as follows: i. Whether SA WG2 is planning to address different network parameter configurations aggregation methods based on Application Server requests. ii. Whether it is feasible to have an SA WG6 solution for aggregation of network parameter configurations coexisting with and different from the existing SA WG2 mechanisms, or with any upcoming ones based on (i).","secretary_remarks":"Response drafted in S2-2210856","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10200,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-10-26 16:03:08","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S6-223075","lsreply":"S2-2211128","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210208.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210209","title":"LS from GSMA OPG: LS on GSMA OPG PRDs publication","source":"GSMA OPG","contact":"Sandra Ondrusova","contact-id":77474,"tdoctype":"LS in","for":"Action","abstract":"Introduction: GSMA OPG would like to notify 3GPP and ETSI of the recent release of several GSMA PRDS: OPG.02 Operator Platform Telco Edge Requirements version 3.0, available at gsma.com. The new version contains the following changes: Enhanced Network capabilities exposure New interface - Edge Interconnection Network Cellular Service continuity OPG.03 Southbound Interface Network Resources APIs version 1.0 Available at gsma.com OPG.04 East-Westbound Interface APIs version 1.0 Available at gsma.com Actions: GSMA OPG kindly ask 3GPP and ETSI to take the above into consideration.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-11-02 16:00:11","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG6, ETSI ISG MEC","Cc":"TSG SA","lsoriginalls":"OPG_111_Doc 03","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210209.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210210","title":"LS from SA WG3-LI: Response LS on Identifier availability for Lawful Interception during Inter-PLMN handover","source":"SA WG3-LI","contact":"Tim Ashton","contact-id":84816,"tdoctype":"LS in","for":"Action","abstract":"SA WG3-LI thanks SA WG2 for their preliminary analysis of the transfer of MSISDN and IMEI at inter-PLMN handover in EPC and 5GC. Presuming no issues arise from SA WG3 and CT WG4 response to LS S2-2209262, SA WG3-LI endorses SA WG2 s proposal to prepare CR(s) to add the MSISDN to the stage 2 TS 23.401 for inter-MME handover (and to include inter-RAT cases, possibly TS 23.502) to Release 18. Action: SA WG3-LI endorses the SA WG2 proposal to prepare CR(s) to add the MSISDN to the stage 2 TS 23.401 for inter-MME handover (and to include inter-RAT cases, possibly TS 23.502) to Release 18.","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"available","reservation_date":"2022-10-21 13:22:36","uploaded":"2022-11-03 13:13:58","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG3, CT WG4, SA WG3","lsoriginalls":"S3i220660","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210210.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210247","title":"[DRAFT] Reply LS on Traffic Identification within 5G Media Streaming","source":"Ericsson","contact":"Judy Gan Juying","contact-id":72307,"tdoctype":"LS out","for":"Approval","abstract":"This paper replies that ToS\/TC over N33 can be used under certain condition, originally requested in S2-2201960 (S4-220305) in SA WG2#150E","secretary_remarks":"Revision of (Postponed) S2-2208353. Response to S2-2210169","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10050,"status":"revised","reservation_date":"2022-02-11 20:22:26","uploaded":"2022-11-04 22:10:31","revisionof":"S2-2208353","revisedto":"S2-2211127","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3, SA WG4","Cc":"","lsoriginalls":"C3-224556","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210247.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210248","title":"Traffic Identification using ToS\/TC for 5G Media Streaming","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Replace Flow description with Flow description information and add in service operations a reference to clause 6.1.3.6 of TS 23.503.","secretary_remarks":"Revision of (Postponed) S2-2208354. Revised in parallel session to S2-2210932.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10180,"status":"revised","reservation_date":"2022-02-11 20:22:26","uploaded":"2022-11-04 22:10:31","revisionof":"S2-2208354","revisedto":"S2-2210932","release":"Rel-17","crspec":"23.502","crspecversion":"17.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3431.0,"crrevision":4.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210248.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210249","title":"Traffic Identification using ToS\/TC for 5G Media Streaming","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clause 6.2.1.2, replace Flow description with Flow description information . Clause 6.1.3.1, clarify that AF may provide flow description information to PCF directly or via NEF Clause 6.1.3.6, Update NOTE 3 to cover the case that ToS\/TC is provided by the AF to the PCF via the NEF.","secretary_remarks":"Revised in parallel session to S2-2210933.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10200,"status":"revised","reservation_date":"2022-02-11 20:22:28","uploaded":"2022-11-04 22:10:31","revisionof":"","revisedto":"S2-2210933","release":"Rel-17","crspec":"23.503","crspecversion":"17.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":760.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210249.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210665","title":"[DRAFT] Reply LS on Support PIN application architecture and interaction","source":"Nokia, Nokia Shanghai Bell","contact":"Pallab Gupta","contact-id":87959,"tdoctype":"LS out","for":"Agreement","abstract":"To: SA WG6. CC: SA WG3","secretary_remarks":"Response to S2-2210206","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10190,"status":"available","reservation_date":"2022-04-11 11:51:15","uploaded":"2022-11-04 13:15:39","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_154_Toulouse_2022-11\/Docs\/S2-2210665.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210698","title":"[DRAFT] Response to Reply to LS on UE capability signaling for IoT-NTN","source":"VODAFONE","contact":"Chris Pudney","contact-id":1122,"tdoctype":"LS out","for":"Agreement","abstract":"To: RAN WG2, CT WG1. CC: RAN WG3. Attachments: CR 3719 to TS 23.401","secretary_remarks":"Response to S2-2210189","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"revised","reservation_date":"2022-04-11 12:43:59","uploaded":"2022-11-04 12:47:47","revisionof":"","revisedto":"S2-2211041","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2, CT WG1","Cc":"RAN WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210698.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210736","title":"[DRAFT] Reply LS on QoS Sustainability analytics and V2X service adaptations","source":"Qualcomm Incorporated","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS out","for":"Approval","abstract":"To: 5GAA Working Group 4. CC: SA WG1. Attachments: CR XXXX to TS 23.xxx","secretary_remarks":"Response to S2-2210182","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"revised","reservation_date":"2022-04-11 13:41:32","uploaded":"2022-11-04 14:21:40","revisionof":"","revisedto":"S2-2210931","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5GAA Working Group 4","Cc":"SA WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210736.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210831","title":"IMS cross border mobility with Home routed IMS calls","source":"Nokia, Nokia Shanghai Bell","contact":"Rainer Liebhart","contact-id":68375,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding procedure for mobility between PLMNs for IMS Home routed roaming scenarios. Editorial updates","secretary_remarks":"Revision of (Agreed) S2-2209268. Revised in parallel session to S2-2210936.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10410,"status":"revised","reservation_date":"2022-04-11 15:50:07","uploaded":"2022-11-04 19:50:04","revisionof":"S2-2209268","revisedto":"S2-2210936","release":"Rel-18","crspec":"23.228","crspecversion":"17.3.0","workitem":[{"winame":"V8"},{"winame":" TEI18"}],"crnumber":1257.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210831.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210843","title":"[DRAFT] LS Reply to MITRE Engenuity Open Generation 5G Consortium","source":"QUALCOMM Europe Inc. - Italy","contact":"Faccin Stefano","contact-id":79506,"tdoctype":"LS out","for":"Approval","abstract":"To: MITRE Engenuity Open Generation 5G Consortium. Attachments: TR 23.700-58 v.1.0.0","secretary_remarks":"Response to S2-2210180","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"revised","reservation_date":"2022-04-11 16:20:48","uploaded":"2022-11-04 17:46:08","revisionof":"","revisedto":"S2-2210935","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"MITRE Engenuity Open Generation 5G Consortium","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210843.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210855","title":"Discussion on Network Parameters Configuration for IoT Platforms.","source":"Convida Wireless LLC","contact":"Catalina Mladin","contact-id":80144,"tdoctype":"discussion","for":"Discussion","abstract":"This paper discusses Network Parameters Configuration by IoT Platforms as it relates to the incoming LS from SA WG6 (S2-2210208\/ S6-220375).","secretary_remarks":"","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"available","reservation_date":"2022-04-11 17:32:11","uploaded":"2022-11-04 18:30:56","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210855.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210856","title":"Reply LS on Network Parameters Configuration for IoT Platforms","source":"Convida Wireless LLC","contact":"Quang Ly","contact-id":79480,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6","secretary_remarks":"Response to S2-2210208","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"revised","reservation_date":"2022-04-11 17:34:43","uploaded":"2022-11-04 18:30:56","revisionof":"","revisedto":"S2-2210934","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210856.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210931","title":"[DRAFT] Reply LS on QoS Sustainability analytics and V2X service adaptations","source":"Qualcomm Incorporated","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS out","for":"Approval","abstract":"To: 5GAA Working Group 4. CC: SA WG1. Attachments: CR XXXX to TS 23.xxx","secretary_remarks":"Revision of S2-2210736. Revised in parallel session to S2-2211130.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"revised","reservation_date":"2022-11-22 06:30:54","uploaded":"2022-11-22 07:01:15","revisionof":"S2-2210736","revisedto":"S2-2211130","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5GAA Working Group 4","Cc":"SA WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210931.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210932","title":"Traffic Identification using ToS\/TC for 5G Media Streaming","source":"Ericsson, Huawei","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Replace Flow description with Flow description information and add in service operations a reference to clause 6.1.3.6 of TS 23.503.","secretary_remarks":"Revision of S2-2210248. Agreed in parallel session. Block approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10190,"status":"agreed","reservation_date":"2022-11-22 06:30:54","uploaded":"2022-11-22 07:01:15","revisionof":"S2-2210248","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"17.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3431.0,"crrevision":5.0,"crcategory":"F","tsg_crp":"SP-221079","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210932.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210933","title":"Traffic Identification using ToS\/TC for 5G Media Streaming","source":"Ericsson, Huawei","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clause 6.2.1.2, replace Flow description with Flow description information . Clause 6.1.3.1, clarify that AF may provide flow description information to PCF directly or via NEF Clause 6.1.3.6, Update NOTE 3 to cover the case that ToS\/TC is provided by the AF to the PCF via the NEF.","secretary_remarks":"Revision of S2-2210249. Revised in parallel session to S2-2211126.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"revised","reservation_date":"2022-11-22 06:30:56","uploaded":"2022-11-22 07:01:15","revisionof":"S2-2210249","revisedto":"S2-2211126","release":"Rel-17","crspec":"23.503","crspecversion":"17.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":760.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210933.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210934","title":"Reply LS on Network Parameters Configuration for IoT Platforms","source":"Convida Wireless LLC","contact":"Quang Ly","contact-id":79480,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6","secretary_remarks":"Revision of S2-2210856. Revised in parallel session to S2-2211128.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"revised","reservation_date":"2022-11-22 06:30:57","uploaded":"2022-11-22 07:01:15","revisionof":"S2-2210856","revisedto":"S2-2211128","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210934.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210935","title":"[DRAFT] LS Reply to MITRE Engenuity Open Generation 5G Consortium","source":"QUALCOMM Europe Inc. - Italy","contact":"Faccin Stefano","contact-id":79506,"tdoctype":"LS out","for":"Approval","abstract":"To: MITRE Engenuity Open Generation 5G Consortium. Attachments: TR 23.700-58 v.1.0.0","secretary_remarks":"Revision of S2-2210843. Revised in parallel session to S2-2211125.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10360,"status":"revised","reservation_date":"2022-11-22 06:30:57","uploaded":"2022-11-22 07:01:15","revisionof":"S2-2210843","revisedto":"S2-2211125","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"MITRE Engenuity Open Generation 5G Consortium","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210935.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2210936","title":"IMS cross border mobility with Home routed IMS calls","source":"Vodafone, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Rainer Liebhart","contact-id":68375,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding procedure for mobility between PLMNs for IMS Home routed roaming scenarios. Editorial updates. The content of clause W.3 is moved to clause W.4.1 for better reading.","secretary_remarks":"Revision of S2-2210831. Revised in parallel session to S2-2211129.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10420,"status":"revised","reservation_date":"2022-11-22 06:30:57","uploaded":"2022-11-22 07:01:15","revisionof":"S2-2210831","revisedto":"S2-2211129","release":"Rel-18","crspec":"23.228","crspecversion":"17.3.0","workitem":[{"winame":"V8"},{"winame":" TEI18"}],"crnumber":1257.0,"crrevision":3.0,"crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2210936.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211125","title":"[DRAFT] LS Reply to MITRE Engenuity Open Generation 5G Consortium","source":"QUALCOMM Europe Inc. - Italy","contact":"Faccin Stefano","contact-id":79506,"tdoctype":"LS out","for":"Approval","abstract":"To: MITRE Engenuity Open Generation 5G Consortium. Attachments: TR 23.700-58 v.1.0.0","secretary_remarks":"Revision of S2-2210935. Agreed in parallel session. Block approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10370,"status":"approved","reservation_date":"2022-11-22 06:32:55","uploaded":"2022-11-22 07:01:18","revisionof":"S2-2210935","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2210180","lsto":"MITRE Engenuity Open Generation 5G Consortium","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211125.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211126","title":"Traffic Identification using ToS\/TC for 5G Media Streaming","source":"Ericsson, Huawei","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clause 6.2.1.2, replace Flow description with Flow description information . Clause 6.1.3.1, clarify that AF may provide flow description information to PCF directly or via NEF Clause 6.1.3.6, Update NOTE 3 to cover the case that ToS\/TC is provided by the AF to the PCF via the NEF.","secretary_remarks":"Revision of S2-2210933. Agreed in parallel session. Block approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"agreed","reservation_date":"2022-11-22 06:32:55","uploaded":"2022-11-22 07:01:18","revisionof":"S2-2210933","revisedto":"","release":"Rel-17","crspec":"23.503","crspecversion":"17.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":760.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"SP-221079","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211126.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211127","title":"[DRAFT] Reply LS on Traffic Identification within 5G Media Streaming","source":"Ericsson","contact":"Judy Gan Juying","contact-id":72307,"tdoctype":"LS out","for":"Approval","abstract":"This paper replies that ToS\/TC over N33 can be used under certain condition, originally requested in S2-2201960 (S4-220305) in SA WG2#150E","secretary_remarks":"Revision of S2-2210247. Agreed in parallel session. Block approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"approved","reservation_date":"2022-11-22 06:32:56","uploaded":"2022-11-22 07:01:18","revisionof":"S2-2210247","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2210169","lsto":"CT WG3, SA WG4","Cc":"","lsoriginalls":"C3-224556","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211127.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211128","title":"Reply LS on Network Parameters Configuration for IoT Platforms","source":"Convida Wireless LLC","contact":"Quang Ly","contact-id":79480,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG6","secretary_remarks":"Revision of S2-2210934. Agreed in parallel session. Block approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"approved","reservation_date":"2022-11-22 06:32:56","uploaded":"2022-11-22 07:01:18","revisionof":"S2-2210934","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2210208","lsto":"SA WG6","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211128.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211129","title":"IMS cross border mobility with Home routed IMS calls","source":"Vodafone, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Rainer Liebhart","contact-id":68375,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding procedure for mobility between PLMNs for IMS Home routed roaming scenarios. Editorial updates. The content of clause W.3 is moved to clause W.4.1 for better reading.","secretary_remarks":"Revision of S2-2210936. Revised in parallel session to S2-2211131.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10430,"status":"revised","reservation_date":"2022-11-22 06:32:56","uploaded":"2022-11-22 07:01:18","revisionof":"S2-2210936","revisedto":"S2-2211131","release":"Rel-18","crspec":"23.228","crspecversion":"17.3.0","workitem":[{"winame":"V8"},{"winame":" TEI18"}],"crnumber":1257.0,"crrevision":4.0,"crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211129.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211130","title":"[DRAFT] Reply LS on QoS Sustainability analytics and V2X service adaptations","source":"Qualcomm Incorporated","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS out","for":"Approval","abstract":"To: 5GAA Working Group 4. CC: SA WG1. Attachments: CR XXXX to TS 23.xxx","secretary_remarks":"Revision of S2-2210931. Revised in parallel session to S2-2211284.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"revised","reservation_date":"2022-11-22 06:32:58","uploaded":"2022-11-22 07:01:18","revisionof":"S2-2210931","revisedto":"S2-2211284","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5GAA Working Group 4","Cc":"SA WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211130.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211131","title":"IMS cross border mobility with Home routed IMS calls","source":"Vodafone, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Rainer Liebhart","contact-id":68375,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding procedure for mobility between PLMNs for IMS Home routed roaming scenarios. Editorial updates. The content of clause W.3 is moved to clause W.4.1 for better reading.","secretary_remarks":"Revision of S2-2211129. Revised in parallel session to S2-2211285.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10440,"status":"revised","reservation_date":"2022-11-22 06:32:58","uploaded":"2022-11-22 07:01:18","revisionof":"S2-2211129","revisedto":"S2-2211285","release":"Rel-18","crspec":"23.228","crspecversion":"17.3.0","workitem":[{"winame":"V8"},{"winame":" TEI18"}],"crnumber":1257.0,"crrevision":5.0,"crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211131.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211284","title":"[DRAFT] Reply LS on QoS Sustainability analytics and V2X service adaptations","source":"Qualcomm Incorporated","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS out","for":"Approval","abstract":"To: 5GAA Working Group 4. CC: SA WG1. Attachments: CR XXXX to TS 23.xxx","secretary_remarks":"Revision of S2-2211130. Revised in parallel session to S2-2211411.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"revised","reservation_date":"2022-11-22 06:37:01","uploaded":"2022-11-22 07:01:21","revisionof":"S2-2211130","revisedto":"S2-2211411","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5GAA Working Group 4","Cc":"SA WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211284.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211285","title":"IMS cross border mobility with Home routed IMS calls","source":"Vodafone, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Rainer Liebhart","contact-id":68375,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding procedure for mobility between PLMNs for IMS Home routed roaming scenarios. Editorial updates. The content of clause W.3 is moved to clause W.4.1 for better reading.","secretary_remarks":"Revision of S2-2211131. Agreed in parallel session. Block approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10450,"status":"agreed","reservation_date":"2022-11-22 06:37:01","uploaded":"2022-11-22 07:01:21","revisionof":"S2-2211131","revisedto":"","release":"Rel-18","crspec":"23.228","crspecversion":"17.3.0","workitem":[{"winame":"V8"},{"winame":" TEI18"}],"crnumber":1257.0,"crrevision":6.0,"crcategory":"C","tsg_crp":"SP-221094","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211285.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2211411","title":"[DRAFT] Reply LS on QoS Sustainability analytics and V2X service adaptations","source":"Qualcomm Incorporated","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS out","for":"Approval","abstract":"To: 5GAA Working Group 4. CC: SA WG1. Attachments: CR XXXX to TS 23.xxx","secretary_remarks":"Revision of S2-2211284. Agreed in parallel session. Block approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"approved","reservation_date":"2022-11-22 06:40:11","uploaded":"2022-11-22 07:01:22","revisionof":"S2-2211284","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2210182","lsto":"5GAA Working Group 4","Cc":"SA WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_154_Toulouse_2022-11\/Docs\/S2-2211411.zip","group":"S2","meeting":"S2-154","year":2022,"uicc_affected":"","me_affected":"","ran_affected":"","cn_affected":"","clauses_affected":"","crsinpack":null,"crsinpacknumber":0},
{"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}]