[{"name":"S2-2103718","title":"LS on stage 3 aspects for Reliable Data Service Serialization Indication","source":"CT WG1","contact":"Vivek Gupta","contact-id":74448,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 has agreed the RDSSI WID in Rel-17 to implement the Reliable Data Service Serialization Indication feature in stage 3, whereas the corresponding stage 2 requirements are in Rel-16. Action: CT WG1 kindly asks TSG SA, TSG CT and SA WG2 to take above into account.","secretary_remarks":"Revision of Postponed S2-2102086 from S2#144E. Postponed. Revised at S2-146E to S2-2105225","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"postponed","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"S2-2102086","revisedto":"S2-2105225","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, TSG CT, TSG SA","Cc":"CT WG3","lsoriginalls":"C1-207769","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103718.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103722","title":"LS from CT WG3: LS on Session Management Policy Data per PLMN","source":"CT WG3","contact":"Apostolos Papageorgiou","contact-id":81926,"tdoctype":"LS in","for":"Action","abstract":"In the procedure for SM Policy Association Establishment (TS 23.502 clause 4.16.4), SA WG2 has specified that in LBO, the V-PCF interacts with the UDR of the VPLMN but the retrieval of data using Nudr_DM_Query\/Subscribe from the UDR (or V-UDR) is specified per subscriber, as per the text highlighted below {. . .} In the LBO case, the Session Management Policy Data at the VPLMN cannot be stored per subscriber, since the subscribers of the HPLMN are not managed by the VPLMN, but the VPLMN can store Session Management Policy Data that are applicable to all the subscribers of a certain HPLMN. Although the above highlighted text could imply that the V-PCF can retrieve subscriber related data (which includes Session Management Policy Data) from the V-UDR, the key of Session Management Policy Data in the UDR is the SUPI. Based on the above, CT WG3 would like to ask the following clarification question to SA WG2: Q1. Can the UDR of the VPLMN store PDU Session policy control data per HPLMN? Q2. Is all the PDU Session policy control subscription information (specified in TS 23.503 Table 6.2-2) supported in the LBO scenario?. Action: CT WG3 kindly asks SA WG2 to provide feedback for questions Q1 and Q2 and update accordingly the specifications as necessary.","secretary_remarks":"Revision of Postponed S2-2102103 from S2#144E. Responses drafted in S2-2104002 and S2-2104140. CC#2: Moved to agenda item 9.4. Postponed. Revised at S2-146E to S2-2105227","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"postponed","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"S2-2102103","revisedto":"S2-2105227","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C3-211469","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103722.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103727","title":"LS from 5G-ACIA: 5G capabilities exposure for factories of the future - revised","source":"5G-ACIA","contact":"Andreas Mueller","contact-id":81087,"tdoctype":"LS in","for":"Action","abstract":"5G-ACIA published a white paper in June 2020 on the exposed 5G capabilities that are needed by factory operators to manage and maintain industrial 5G devices and 5G Non-Public Networks (NPN) in a simple and efficient manner. That white paper has now been enhanced to include additional capabilities and some clarification to the capabilities and functions from the previous version of the white paper. In particular, device-centric requirements have been clarified and a few new ones added in accordance with SA WG1 requirements of Release 17. Concerning net-work-centric requirements, network monitoring have been detailed in the Annex of the white paper. Also, the Annex now lists parameters for QoS monitoring. Since 5G-ACIA believes that these service exposure requirements are valuable to be considered in ongoing work in 3GPP, we would like to make this new white paper availa-ble to you: - White paper title: Exposure of 5G capabilities for connected industries and automa-tion applications - Link www.5g-acia.org\/publications - PDF copy: attached to this liaison statement 5G-ACIA would be eager to receive 3GPP's feedback on these new exposure interface requirements and related Stage-2 and Stage-3 work. Action: 5G-ACIA would like to respectfully request SA WG1, WG2, WG3 and WG6 to consider the identified requirements as captured in the updated whitepaper and to pro-vide feedback to 5G-ACIA concerning of how the identified new requirements can be ad-dressed in Rel-17 or future releases.","secretary_remarks":"Revision of Postponed S2-2102128 from S2#144E. Coordination response to 3GPP groups in S2-2104794. Postponed for feedback from TSG SA. Revised at S2-146E to S2-2105229","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"postponed","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"S2-2102128","revisedto":"S2-2105229","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2, SA WG3, SA WG6","Cc":"TSG SA, SA WG5, CT WG3, ...","lsoriginalls":"5G-ACIA_LS_3GPP_Exposure_18032021","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103727.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103729","title":"LS from WBA 5G Work Group: Liaison Statement on 5G & Wi-Fi RAN Convergence","source":"WBA 5G Work Group","contact":"Nigel Bird","contact-id":27137,"tdoctype":"LS in","for":"Information","abstract":"Dear TSG SA Chair Georg Mayer, and SA WG2 Chair Puneet Jain, WBA thanks TSG SA for ongoing work regarding WLAN integration into 3GPP 5G systems in the Release 16 and Release 17. The WBA 5G Work Group has been looking into 5G and Wi-Fi RAN convergence topic for over 2 years. WBA published phase 1 analysis on this topic jointly with the NGMN as part of a RAN Convergence Paper published in September 2019. During 2020, WBA Members approved the creation of a phase 2 project to conduct further in-depth analysis on 5G & Wi-Fi RAN Convergence (https:\/\/wballiance.com\/5g-wi-fi-ran-convergence-global-architecture-policy). The WBA 5G Work Group has now concluded the phase 2 of the project in the form of a whitepaper titled '5G and Wi-Fi RAN Convergence - Aligning the Industry on Opportunities and Challenges', identifying potential challenges and gaps related to providing end-to-end 5G services using both 5G and Wi-Fi accesses. Reason for contact: The WBA 5G Work Group has highlighted potential challenges and gaps in the following key areas related to the 5G and Wi-Fi convergence: - 5G and Wi-Fi convergence architecture (for Trusted and Untrusted WLAN access); - ATSSS multi-access functionality; - End-to-end QoS; - Policy Interworking and enhancements across 5G and Wi-Fi; - Support for Wi-Fi only devices. Potential challenges and gaps identified in these key areas are captured in Section 3 of the paper. Section 4 provides recommendations for the industry to address them and Section 5 lists specific items to be addressed by relevant standard bodies. {. . .} We believe that further actions are needed by the industry and standards bodies to address key challenges and gaps highlighted in the WBA 5G and Wi-Fi RAN Convergence paper, for realizing new business opportunities presented by the convergence between 5G and Wi-Fi. We look forward to working together with your organization to address the issues highlighted above. Please let us know if we could collaborate on any items that might be of interest to your organization. Looking forward to continued cooperation between our organizations. Thank you very much in advance and for any additional information please contact WBA PMO (pmo@wballiance.com). Best Regards, WBA PMO (pmo@wballiance.com","secretary_remarks":"Revision of Postponed S2-2102130 from S2#144E. Postponed. Revised at S2-146E to S2-2105231","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"postponed","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"S2-2102130","revisedto":"S2-2105231","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG2","Cc":"","lsoriginalls":"WBA LS on 5G Wi-Fi RAN Convergence","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103729.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103732","title":"LS from GSMA NG NRG: LS to 3GPP SA2 on ARP PL","source":"GSMA NG NRG","contact":"Ralf Keller","contact-id":11142,"tdoctype":"LS in","for":"Information","abstract":"Background: GSMA NG NRG has discussed and agreed that the settings of ARP PL\/PCI\/PVI are exclusively related to the VPMN service prioritization strategy and may change from one VPMN to another. To minimize the impact on individual VoLTE roaming agreements and implementation and testing, it must be possible that the VPMN's MME applies an MNO specific ARP PL value for inbound roamers, independent from the value provided by the HPMN HSS or PCEF. Hence GSMA NG NRG has discussed and agreed that the VPMN MME may apply the ARP PL value as per local configuration. This has been documented in GSMA PRD IR.88 as follows: As ARP settings are exclusively related to the VPMN service prioritization strategy and may change from one [\u2026] VPMN to another, the following handling for the negotiation of the ARP value should be applied: - For the establishment of the SIP bearer, the VPMN, may either apply the ARP Priority Level (PL) value received from HSS or apply values as per roaming agreement or local configuration. To prevent that the establishment of the SIP bearer fails, the HPMN should not upgrade the value of the ARP PL. - For the establishment of the media bearer, the HPMN sends an ARP PL value as per roaming agreement or local configuration. The VPMN should allow the bearer establishment with the ARP PL value received from the HPLMN. However, the VPMN may apply the ARP PL value as per roaming agreement or local configuration instead. GSMA NG NRG kindly asks 3GPP to check whether a local configuration of the ARP PL for inbound roamers is covered by the standard, and if not, add the option of a local configuration accordingly. Actions to SA WG2: The GSMA NG NRG kindly requests SA WG2 to take this information into account and to provide feedback.","secretary_remarks":"Postponed. Revised at S2-146E to S2-2105233","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10050,"status":"postponed","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"","revisedto":"S2-2105233","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG3","lsoriginalls":"NRG 009_201 - LS to 3GPP SA2 CT3 ARP","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103732.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103733","title":"LS from ITU-T FG-VM: LS on the latest results on the Vehicular Multimedia deliverables from ITU FG-VM","source":"ITU-T FG-VM","contact":"Jun Li","contact-id":72143,"tdoctype":"LS in","for":"Information","abstract":"We are pleased to inform you about the current status and results of the ITU Focus Group on Vehicular Multimedia (FG-VM), established by the ITU-T Study Group 16 in 2018. The FG-VM had already finalized the first technical report on 'Use Cases and Requirements for Vehicular Multimedia' [Flipbook]. This technical report was further improved by the parent ITU T Study Group 16, who has approved a new ITU-T Recommendation 'Use cases and requirements for the vehicular multimedia networks' Rec.ITU-T F.749.3. In addition, at the recent April 2021 meeting, the FG-VM has finalized its second Technical Report on 'Architecture of Vehicle Multimedia Systems' [FGVM-O-058]. This second deliverable was also submitted for consideration of the parent ITU T Study Group 16, which plans to review and endorse it as ITU-T Recommendation similarly to the first deliverable. The new FG-VM deliverable is attached to this liaison. The FG-VM started working on a third deliverable which will cover Vehicular Multimedia Implementation aspects, under the WG3 leadership. We will keep you informed and would welcome joint participation and collaboration with your group as well as participation from individual experts. Next FG-VM plenary meeting will take place on 29-30 June 2021. A couple of interim meetings of WG3 are planned. See more information on: - FG-VM home page: https:\/\/www.itu.int\/en\/ITU-T\/focusgroups\/vm Please kindly note that all FG-VM documents are accessible, through a free ITU Account, in our SharePoint site (https:\/\/extranet.itu.int\/sites\/itu-t\/focusgroups\/vm\/SitePages\/Home.aspx) (a free ITU Account is needed in order to access FG-VM documents. Create an account here if you do not have one. Please select 'I AM A NEW USER' and then, if applicable, select 'NON ITU MEMBERS'\/ Media and Other Organizations). A mailing list is also available for self-subscription, please check the FG-VM home page and\/or contact tsbfgvm@itu.int for further information you may need.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"noted","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2, SA WG3, SA WG4, . . .","Cc":"","lsoriginalls":"FGVM-LS51","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103733.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103734","title":"Reply LS on User Plane Integrity Protection for eUTRA connected to EPC","source":"RAN WG2","contact":"Mungal Singh Dhanda","contact-id":84552,"tdoctype":"LS in","for":"Information","abstract":"RAN WG2 thanks SA WG3 for their LS in R2-2102667\/S3-210563. RAN WG2 discussed the specific question to RAN WG2 in the LS and would like to provide the follow feedback. a) (RAN 2 and RAN 3) when supporting UP IP do you have any feedback on whether it should be supported with NR PDCP or LTE PDCP or both? Ans: For Release 17, NR PDCP only. UPIP support with LTE PDCP when connected to EPC can be considered in future releases.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"noted","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, SA WG3","Cc":"SA WG2, CT WG4, CT WG1","lsoriginalls":"R2-2104349","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103734.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103741","title":"LS from SA WG4: LS on Media-Related Services and Requirements","source":"SA WG4","contact":"Thomas Stockhammer","contact-id":60397,"tdoctype":"LS in","for":"Information","abstract":"SA WG4 has recently updated its Terms of References (SP-200929) to address new developments in the media industry. The ToR includes responsibilities, among others, on supporting other 3GPP groups on media related matters both for operator and third-party services concerning QoS parameters, traffic characteristics and other system implications. In addition, SA WG4 is regularly consulted through LSs for example from SA WG1, SA WG2 and RAN WG1 to support their work on defining service requirements, specifying 5QIs for new types of services, or supporting the evaluation of radio enhancements, in particular related to media and XR services. Some of the requests are related to exact bitrates in uplink and downlink of such services, delay and latency requirements, detailed traffic characteristics, statistical models, KPIs and quality criteria, etc. While SA WG4 generally has a broad pool of experts on media related topics, responding to such requests in a short amount of time is basically infeasible and may also lead to lower quality or non-satisfying responses. Based on this, SA WG4 is interested to improve the support and guide other 3GPP groups on such matters. However, in order to prepare and allocate sufficient time in SA WG4 for related media matters, we kindly ask SA WG1, when approving new work in SA WG1 related to media, to explicitly tag any needed media related support in the appropriate WID Clause 8 'Aspects that involve other WGs'. We also would like to invite SA WG1, when appropriate in the course of a Study or Work Item related to media, to liaise with SA WG4 as early as possible. A possible approach is provided in the SA WG4 agreed document S4-210279 for SA WG1's information. Other approaches may be considered as well. SA WG4 appreciates your support on this matter.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"noted","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"SA WG6, RAN WG1, SA WG2, TSG SA","lsoriginalls":"S4-210680","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103741.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103745","title":"LS from SA WG6: Reply LS on IP address to GPSI translation","source":"SA WG6","contact":"Nishant Gupta","contact-id":62473,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 thanks SA WG2 for the reply LS on IP address to GPSI translation. SA WG6 would like to express the following view for GPSI: On SA WG2's question #1: In SA WG6's understanding, although GPSI is a public identifier, a user may not be willing to share the GPSI with AFs in the form of MSISDN, due to its potential misuse (e.g. SMS spam). SA WG3 recognized this concern in their LS to SA WG6 and SA WG2 in S6-210012\/ S2-2100044. On SA WG2's question #2 and #3: If GPSI is designed to be in the form of an External Identifier per AF and is also temporary (based on e.g. temporal validity or invalidated on a request by the subscriber), it will help in preventing the tracking of user's behaviour across AFs. Action: SA WG6 kindly requests SA WG2 and SA WG3 to consider the above information when designing the required features.","secretary_remarks":"Postponed. Revised at S2-146E to S2-2105235","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"postponed","reservation_date":"2021-04-21 06:59:57","uploaded":"2021-04-28 11:28:11","revisionof":"","revisedto":"S2-2105235","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG3","lsoriginalls":"S6-211082","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103745.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103748","title":"LS from CT WG1: LS on the conclusion of FS_MINT-CT","source":"CT WG1","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 has studied on the CT aspects of MINT (Minimization of Service Interruption) based on the service requirements that SA WG1 had specified for Rel-17. As decided in TSG SA#89 (as described in SP-200880), it was confirmed that CT WG1 has responsibilities on the stage 2 aspects of MINT, but with final confirmations by SA and SA WG2 on the conclusions of the study. After CT WG1 has intensively studied for four WG meetings including two WG meetings in Q4 2020 before the SID was approved in TSG#90, it resulted in 9 key issues with 60 potential solutions described in TR 24.811. In CT WG1#129e meeting, CT WG1 has agreed on the interim conclusions of the Key Issues as specified in clause 8 of 3GPP TR 24.811 v1.1.0. The conclusions which are incomplete and preliminary as of TR 24.811 v1.1.0 are marked as such via Editor's notes in the corresponding subclause. CT WG1 would like to ask SA WG2 to take above information into consideration and to update their specifications accordingly. Action: CT WG1 kindly asks SA WG2 to take above information into consideration and to update their specifications based on the conclusions described in TR 24.811 if deemed necessary.","secretary_remarks":"Response drafted in S2-2104043. Final response in S2-2104994","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10400,"status":"replied to","reservation_date":"2021-04-21 06:59:58","uploaded":"2021-05-03 06:24:45","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-212598","lsreply":"S2-2104994","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103748.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103763","title":"Reply LS on Server Domain Name Usage for Application Traffic Detection","source":"CT WG3","contact":"Yali Yan","contact-id":66362,"tdoctype":"LS in","for":"Information","abstract":"CT WG3 would like to thank SA WG4 for the LS with Q2. Q2: What is the relationship between the AF Identifier (SCS\/AS ID in 4G) and the AF application ID and\/or the application identifier? CT WG3 considers the question only focusing on 5G Nnef_AFSessionWithQoS and Nnef_ChargeableParty APIs. Based on current stage 3 definition in Release 16, CT WG3 takes the Nnef_AFSessionWithQoS API as an example, and provides the following answers for the question: The AF Identifier identifies the Application Function (AF) in 5G. The AF Application Identifier identifies (in the NEF and in the PCF) an application which is associated with an AF. The term Application Identifier is not used in the context of the Nnef_AFSessionWithQoS API. Upon receipt of the API initial request from the AF which also provides the AF Identifier, the NEF shall map the received AF Identifier to only one AF application Identifier based on operator policy and\/or local configuration. NOTE: It is implementation specific on how to map the AF Identifier to the AF Application Identifier. The above answers also apply to the Nnef_ChargeableParty API but with the difference that the NEF may (not shall) map the AF Identifier to an AF Application Identifier. Since the exact definition and the relationship of the same or similar terms might differ in the context of other APIs, CT WG3 can further clarify if SA WG4 have more concern on other APIs.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"noted","reservation_date":"2021-05-03 05:55:58","uploaded":"2021-05-03 06:24:45","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG4","Cc":"SA WG2","lsoriginalls":"C3-212404","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103763.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103765","title":"LS from CT WG4: LS on Support of Asynchronous Type Communication in N1N2MessageTransfer","source":"CT WG4","contact":"yong yang","contact-id":59744,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 has discussed the attached CR (Postponed) addressing potential issues related to the support of Asynchronous Type Communication by the AMF. The support of Asynchronous Type Communication has been introduced since Rel-15 and specified in clause 5.23 of 3GPP TS 23.501: For network function (e.g. PCF, UDM, etc.) triggered signalling procedure (e.g. network triggered Service Request procedure, network triggered PDU Session Modification procedure, etc.), if the UE CM state in the AMF is CM-IDLE state, the AMF updates and stores the UE context based on the received message without paging UE immediately. When the UE CM state in the AMF enters CM-CONNECTED state, the AMF forwards N1 and N2 message to synchronize the UE context with the (R)AN and\/or the UE. For example, during a Network triggered PDU Session modification (as specified in clause 4.3.3 of 3GPP TS 23.502), the N1N2MessageTransfer service operation in Namf_Communication service is used by a NF Service Consumer (e.g. SMF) to transfer N1 message, e.g. PDU Session Modification Command, to the UE. Based on the quoted requirements, if the AMF supports Asynchronous Type Communication, upon receiving such a N1N2MessageTransfer request containing a N1 message, it shall not page the UE if the UE is in CM-IDLE state; however the SMF is waiting for a reply to the NAS SM message, and if the UE is not paged, the whole procedure fails. It is similar for the following procedures where the consumer will use N1N2MessageTransfer to transfer a N1 message to the UE and expect to receive a timely response from the UE. - Network triggered Service Request (see clause 4.2.3.3 of 3GPP TS 23.502) - PDU Session modification (see clause 4.3.3 of 3GPP TS 23.502) - SMS over NAS procedures (see clause 4.13.3 of 3GPP TS 23.502) - UE assisted and UE based positioning procedure (see clause 6.11.1 of 3GPP TS 23.273) - Network assisted positioning procedure (see clause 6.11.2 of 3GPP TS 23.273) - LCS Event Report, LCS Cancel Location and LCS Periodic-Triggered Invoke procedures (see clause 6.3 of 3GPP TS 23.273) CT WG4 would like to ask SA WG2 the following questions: Q1: What are the use cases targeted by Asynchronous Type Communication? Do they require support of the aforementioned procedures? Does ATC apply for all UEs when activated in AMF? Q2: Should ATC be applicable for N1N2MessageTransfer in the aforementioned procedures for all UEs\/PDU sessions served by a given AMF or should the AMF configured with ATC be permitted to page UEs for scenarios where the NF service consumer expects a timely response from the UE? Q3: If so, how does the AMF know whether ATC can be used for a given current N1N2MessageTransfer request (i.e. whether the NF service consumer expects a timely response from the UE or not)? In Rel-16, the N1N2MessageTransfer is also used to deliver mtData for Control Plane CIoT 5GS Optimisation: - UPF anchored Mobile Terminated Data Transport in Control Plane CIoT 5GS Optimisation (see clause 4.24.2 of 3GPP TS 23.502) - NEF Anchored Mobile Terminated Data Transport (see clause 4.25.5 of 3GPP TS 23.502) Q4: Can the AMF use ATC or not for delivering mtData? Q5: Should CT WG4 consider a solution that enables the NF service consumer of N1N2Message Transfer to indicate if ATC may be applied for the sending of the N1 message, so that the AMF configured with ATC may still page the UE in CM-IDLE state if the sender of the message (e.g. SMF) expects a timely response for the procedure to succeed. Action: CT WG4 kindly requests SA WG2 to provide answers to the questions and feedback on the attached CR and to update their specification if necessary.","secretary_remarks":"Response drafted in S2-2103895. Postponed. Revised at S2-146E to S2-2105239","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"postponed","reservation_date":"2021-05-03 05:55:58","uploaded":"2021-05-03 06:24:45","revisionof":"","revisedto":"S2-2105239","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1","lsoriginalls":"C4-212401","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103765.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103769","title":"LS from RAN WG2: LS on introducing extended DRX for RedCap UEs","source":"RAN WG2","contact":"Tuomas Tirronen","contact-id":73195,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 has started work on the support of reduced capability (RedCap) NR devices, where the related study item has been concluded in TR 38.875, v17.0.0 and work has been started according to WID in RP-210918. The WID has the following objectives on introduction of extended DRX: - Specify support for the following Extended DRX enhancements for RedCap UEs [RAN WG2, RAN WG3, RAN WG4]: o Extended DRX for RRC Inactive and Idle with eDRX cycles up to 10.24 s, without using PTW and PH, and with common design (e.g. common set of eDRX values) between RRC Inactive and Idle o Extended DRX for RRC Inactive and Idle with eDRX cycles up to 10485.76 s; the details of mechanisms and feasibility regarding maximum length of the extended DRX cycles for RRC Inactive and Idle need to be checked by SA WG2, CT WG1 and\/or RAN WG4. o RAN WG2 to decide which Node(s) configure eDRX in RRC_Idle and RRC_Inactive. RAN WG2 has discussed support for extended DRX for RedCap UEs during RAN WG2#113bis-e and has reached the following agreements and would like to ask SA WG2 and CT WG1 for feedback, if any: - RAN decides and configures eDRX via RRC for RRC_INACTIVE (FFS on the need and details of coordination with the CN) - At least for eDRX cycle, the configurations of the eDRX for RRC_IDLE and RRC_INACTIVE can be different (FFS for PTW, e.g. length and starting point, when eDRX cycles are longer than 10.24s) - RAN WG2 assumes that CN provides necessary assistance information on eDRX config. for RRC_IDLE to RAN (e.g. reusing eDRX config. defined in 'CN Assistance Information for RRC INACTIVE IE' for E-UTRA\/5GC). - eDRX feature, including the related parameters (i.e. PH, PTW. H-SFN) and corresponding paging operation defined for E-UTRA\/5GC is used as baseline to enable eDRX >10.24sec for both RRC_IDLE and RRC_INACTIVE in NR\/5GC. RAN WG2 would like to ask whether it is feasible from SA WG2 and CT WG1 perspective to introduce extended DRX up to 10485.76 s in RRC_IDLE and RRC_INACTIVE and if feasible, to specify the necessary support. RAN WG2 would like SA WG2 and CT WG1 to take the above aspects into consideration in their work and further consult with RAN WG2 if needed. Action: 1) RAN WG2 respectfully requests SA WG2 and CT WG1 to evaluate whether it is feasible to specify extended DRX up to 10485.76 s for RRC_IDLE and RRC_INACTIVE and if found feasible, specify the necessary support. 2) RAN WG2 respectfully requests SA WG2 and CT WG1 to take above information into account and provide feedback, if any.","secretary_remarks":"Responses drafted in S2-2103796, S2-2103902 and S2-2104343 (Postponed). Postponed. Revised at S2-146E to S2-2105241","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"postponed","reservation_date":"2021-05-03 05:55:59","uploaded":"2021-05-03 06:24:45","revisionof":"","revisedto":"S2-2105241","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG1","Cc":"RAN WG3","lsoriginalls":"R2-2104374","lsreply":"S2-2105802","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103769.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103772","title":"LS from RAN WG2: LS on R17 Layer-2 SL Relay of UE ID exposure in paging mechanism","source":"RAN WG2","contact":"Qianxi Lu","contact-id":71851,"tdoctype":"LS in","for":"Information","abstract":"For R17 SL relay, during SI phase, as captured in TR 38.836 4.5.5.2 Paging The Option 2 as studied in TR36.746 [7] for FeD2D paging is selected as the baseline paging relaying solution for L2 UE-to-Network relaying case (i.e. Relay UE monitors the Remote UE's Paging Occasion(s) in addition to its own Paging Occasion(s).) . The paging relaying solution applies to both CN paging and RAN paging via the Option 2. In RAN WG2#113bis-e, in the WI phase, RAN WG2 discussed the scheme on how to support the requirement above. RAN WG2 respectfully requests SA WG3 to feedback on the following question, supposing 5G-S-TMSI\/I-RNTI of remote UE are to be provided to relay UE: Q1: Is there any security issue on exposing the 5G-S-TMSI\/I-RNTI of remote UE to relay UE over the established securePC5\/Uu connection?","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"noted","reservation_date":"2021-05-03 05:55:59","uploaded":"2021-05-03 06:24:45","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"SA WG2, CT WG1","lsoriginalls":"R2-2104654","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103772.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103774","title":"LS from GSMA 5GJA: LS to 3GPP SA2 on URSP Traffic Descriptor","source":"GSMA 5GJA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"Background: The purpose of this LS is to engage on proposed content changes to 3GPP TS23.503, specifically section 6.6.2.1: Structure Description. In particular, the following statements are made in Section 6.6.2.1: Each URSP rule contains a list of Route Selection Descriptors containing one or multiple Route Selection Descriptors each having a different Route Selection Descriptor Precedence value. A Route Selection Descriptor contains one or more of the following components: - DNN Selection: Indicates that the traffic of the matching application shall be routed via a PDU Session supporting any of the included DNNs. It includes one or more DNN(s). When DNN is used in Traffic descriptor, corresponding Route Selection Descriptor of the rule shall not include DNN Selection component. [End TS 23.530 Reference] GSMA 5GJA contends that 'DNN (Data Network Name) requested by the application' is a traffic descriptor that enables a match in the URSP rules. Once the match is identified, how to route it should be flexible. In some cases, the same DNN name can be used in route selector by either not specifying the DNN in the route selection or specify the DNN using the same string. However, in some other cases, MNO's should be able to route that traffic to a PDU session that has a different DNN string. The application owner may prefer to have one version of the application where it always asks for the same DNN string, independent of which MNO will be serving the devices that the app resides. Different MNOs may want to route that app's traffic differently. For example, one MNO may want to route it to a common internet PDU session, while another MNO may want to route it to a PDU session with a DNN name that is different than the DNN string requested by the app. Actions: The GSMA 5GJA task force requests the following adjustments be made to 3GPP TS 23.503: Removal of the second sentence in the bullet specific to DNN selection in Section 6.6.2.1: - DNN Selection: Indicates that the traffic of the matching application shall be routed via a PDU Session supporting any of the included DNNs. It includes one or more DNN(s). When DNN is used in Traffic descriptor, corresponding Route Selection Descriptor of the rule shall not include DNN Selection component. In addition, the following clarifications is proposed to be added to the same bullet point: If a DNN is provided in the Route Selection Descriptor then it must be used, instead of the DNN requested by the application in the traffic descriptor. If there is no DNN in the Route Selection Descriptor, then the UE should use the DNN requested in the traffic descriptor. Thus, the new bullet would read as follows: - DNN Selection: Indicates that the traffic of the matching application shall be routed via a PDU Session supporting any of the included DNNs. It includes one or more DNN(s). If a DNN is provided in the Route Selection Descriptor then it must be used, instead of the DNN requested by the application in the traffic descriptor. If there is no DNN in the Route Selection Descriptor, then the UE should use the DNN requested in the traffic descriptor","secretary_remarks":"Postponed. Revised at S2-146E to S2-2105243","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"postponed","reservation_date":"2021-05-03 05:55:59","uploaded":"2021-05-04 11:49:02","revisionof":"","revisedto":"S2-2105243","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"5GJA16_109r2","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103774.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103775","title":"LS from RAN WG2: LS to CT WG1 on Small data transmission","source":"RAN WG2","contact":"Marta Martinez Tarradell","contact-id":47010,"tdoctype":"LS in","for":"Information","abstract":"RAN WG2 is working on small data transmission in RRC_INACTIVE where multiple UL and DL packets can be exchanged between the network and the UE without UE transitioning to RRC_CONNECTED with WID (RP-210870). RAN WG2 agreed to the following points and would like to ask CT WG1 to inform RAN WG2 of any feedback: 1) SDT is transparent to NAS layer (i.e. NAS generates one of the existing resume causes and AS decides SDT vs non-SDT access) 2) Small data transmission (SDT) with RRC message is supported as baseline. a) For small data when the UE receives RRC release with Suspend config, the UE at least performs the following actions (i.e. same Action: as in legacy): SRBs and DRBs are suspended except SRB0. b) Upon initiating RESUME procedure for SDT initiation (i.e. for first SDT transmission), the UE shall re-establish at least the SDT PDCP entities and resume the SDT RBs that are configured for small data transmission (along with the SRB1). c) The first UL SDT message (i.e. MSG3 for 4-step RACH, MSGA payload for 2-step RACH and the CG transmission for CG) may contain at least the following contents (depending on the size of the message): CCCH message (needs to be included); data from one or more RBs which are configured by the network for small data transmission. d) Support configuring of SRB1 and SRB2 for small data transmission for carrying RRC and NAS messages. e) Small data transmission is configured by the network on a per DRB basis. f) RAN WG2 design assumes that RRCRelease message is sent at the end to terminate the SDT procedure from RRC point of view. g) When UE is in RRC_INACTIVE, it should be possible to send multiple UL and DL packets as part of the same SDT mechanism and without transitioning to RRC_CONNECTED. 3) The UE behaviour for handling of non-SDT data arrival after sending the first UL data packet is fully specified (i.e. not left to UE implementation) a) Non-SDT radio bearers are only resumed upon receiving RRCResume (same as today) b) Switching from SDT to non-SDT is supported. UE receive indication from network to switch to non-SDT procedure. Network can send RRCResume to transit the UE to RRC_CONNECTED during an ongoing SDT session. RAN WG2 also have an additional question: RAN WG2 agreed that only radio bearers configured for SDT are resumed and additional UL and DL data can be exchanged between UE and network as part of a given SDT session while the UE is still in RRC_INACTIVE (i.e. without transition to RRC_CONNECTED). In this case, if new UL data or NAS message becomes available for non-SDT radio bearers (which are suspended), would it be possible that NAS triggers another request to transition into RRC_CONNECTED and provides access category, access identities and resume cause.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"noted","reservation_date":"2021-05-03 05:55:59","uploaded":"2021-05-06 14:12:08","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"SA WG2","lsoriginalls":"R2-2104644","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103775.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103796","title":"[DRAFT] Reply LS on introducing extended DRX for RedCap UEs","source":"Qualcomm Technologies Int","contact":"Miguel Griot","contact-id":84607,"tdoctype":"LS out","for":"Approval","abstract":"Replies to RAN WG2 with SA WG2 conclusion on eDRX for NR RedCAp","secretary_remarks":"Response to S2-2103769. Postponed","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"postponed","reservation_date":"2021-05-06 20:23:38","uploaded":"2021-05-10 17:15:30","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NR_redcap-Core"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2, RAN WG3, CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103796.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103798","title":"Extended DRX for NR (RedCap)","source":"Qualcomm Inc.","contact":"Miguel Griot","contact-id":84607,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Extend eDRX support to 5GS with NR: eDRX beyond 10.24s for CM idle. eDRX up to RRC inactive for CM-Connected with RRC inactive.","secretary_remarks":"Postponed","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"postponed","reservation_date":"2021-05-06 21:07:40","uploaded":"2021-05-10 17:15:30","revisionof":"","revisedto":"","release":"Rel-17","crspec":23.501,"crspecversion":"17.0.0","workitem":[{"winame":"TEI17"},{"winame":" NR_redcap-Core"}],"crnumber":2857.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103798.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103895","title":"[DRAFT] Reply LS on Support of Asynchronous Type Communication in N1N2MessageTransfer","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to CT WG4 infroming the ATC handling agreement","secretary_remarks":"Response to S2-2103765. Postponed","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"postponed","reservation_date":"2021-05-07 16:50:01","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"SBIProtoc17"},{"winame":" TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"CT WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103895.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103896","title":"Removal of ATC","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Remove the support of asynchronous type communication in clause 5.23.","secretary_remarks":"CC#2: Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"noted","reservation_date":"2021-05-07 16:50:01","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"S2-2200510","release":"Rel-15","crspec":23.501,"crspecversion":"15.12.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2866.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103896.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103897","title":"Removal of ATC","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-16 mirror CR: Summary of change: Remove the support of Asynchronous type communication in clause 5.23.","secretary_remarks":"CC#2: Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"noted","reservation_date":"2021-05-07 16:50:02","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"S2-2200511","release":"Rel-16","crspec":23.501,"crspecversion":"16.8.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2867.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103897.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103898","title":"Removal of ATC","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-17 mirror CR: Summary of change: Remove the support of Asynchronous type communication in clause 5.23.","secretary_remarks":"CC#2: Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"noted","reservation_date":"2021-05-07 16:50:03","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"S2-2200512","release":"Rel-17","crspec":23.501,"crspecversion":"17.0.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2868.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103898.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103899","title":"Removal of ATC","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Update Network triggered service request procedure to remove the asynchronous type communication","secretary_remarks":"CC#2: Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"noted","reservation_date":"2021-05-07 16:50:04","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"S2-2200513","release":"Rel-15","crspec":23.502,"crspecversion":"15.13.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2746.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103899.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103900","title":"Removal of ATC","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-16 mirror CR: Summary of change: Update Network triggered service request procedure to remove the asynchronous type communication","secretary_remarks":"CC#2: Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10340,"status":"noted","reservation_date":"2021-05-07 16:50:06","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"S2-2200514","release":"Rel-16","crspec":23.502,"crspecversion":"16.8.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2747.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103900.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103901","title":"Removal of ATC","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Rel-17 mirror CR: Summary of change: Update Network triggered service request procedure to remove the asynchronous type communication","secretary_remarks":"CC#2: Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10350,"status":"noted","reservation_date":"2021-05-07 16:50:07","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"S2-2200515","release":"Rel-17","crspec":23.502,"crspecversion":"17.0.0","workitem":[{"winame":"5GS_Ph1"}],"crnumber":2748.0,"crrevision":"","crcategory":"A","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103901.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103902","title":"[DRAFT] Reply LS on introducing extended DRX for RedCap UEs","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to RAN WG2 informing the SA WG2 view on eDRX value range support and agreements from SA WG2","secretary_remarks":"Response to S2-2103769. Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"noted","reservation_date":"2021-05-07 16:50:08","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NR_redcap-Core"},{"winame":" TEI17"}],"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_145E_Electronic_2021-05\/Docs\/S2-2103902.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2103903","title":"Support for RedCap UE indication and eDRX","source":"Ericsson, MediaTek Inc.","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Introducing the support for RedCap UE in NR with indication and eDRX.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"noted","reservation_date":"2021-05-07 16:50:08","uploaded":"2021-05-10 21:23:07","revisionof":"","revisedto":"S2-2105804","release":"Rel-17","crspec":23.501,"crspecversion":"17.0.0","workitem":[{"winame":"NR_redcap-Core"},{"winame":" TEI17"}],"crnumber":2869.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2103903.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104002","title":"[DRAFT] LS on Session Management Policy Data per PLMN","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"[draft] LS on Session Management Policy Data per PLMN","secretary_remarks":"Response to S2-2103722. CC#2: Moved to 9.4. Postponed","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"postponed","reservation_date":"2021-05-09 19:42:40","uploaded":"2021-05-10 15:52:22","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"SBIProtoc17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104002.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104043","title":"[DRAFT] Reply LS on the conclusion of FS_MINT-CT","source":"LG Electronics","contact":"Hyunsook Kim","contact-id":42013,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS on the conclusion of FS_MINT-CT (S2-2103748 \/ C1-212598)","secretary_remarks":"Response to S2-2103748","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10410,"status":"revised","reservation_date":"2021-05-10 02:58:00","uploaded":"2021-05-10 03:41:42","revisionof":"","revisedto":"S2-2104994","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_MINT-CT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"TSG SA","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104043.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104046","title":"SA WG2 specification impact on FS_MINT-CT .","source":"LG Electronics, KT Corp., LG Uplus, SK Telecom","contact":"Hyunsook Kim","contact-id":42013,"tdoctype":"discussion","for":"Discussion","abstract":"This contribution considers SA WG2 specification impact based on the interim conclusion of FS_MINT-CT (TR 24.811 v1.1.0)","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10420,"status":"noted","reservation_date":"2021-05-10 03:03:38","uploaded":"2021-05-10 03:41:42","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_MINT-CT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104046.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104140","title":"LS Reply on Session Management Policy Data per PLMN","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"Reply to CT WG3 C3-211469","secretary_remarks":"Response to S2-2103722. Merged into S2-2104002 (Postponed)","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"postponed","reservation_date":"2021-05-10 07:09:17","uploaded":"2021-05-10 15:52:06","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104140.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104189","title":"Work analytics on 5G capabilities for factories of the future requested by 5G-ACIA.","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"discussion","for":"Discussion","abstract":"This discussion paper aims at providing analysis on the gaps and maps for the 5G-ACIA LS: 5G capabilities for factories of the future and proposes a way forward to address the gaps.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10230,"status":"noted","reservation_date":"2021-05-10 09:17:53","uploaded":"2021-05-10 14:47:21","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104189.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104329","title":"Discussion on architecture impact for REDCAP.","source":"China Mobile","contact":"Aihua Li","contact-id":58162,"tdoctype":"discussion","for":"Discussion","abstract":"This document discusses the potential architecture impact to support eDRX for RedCap UEs in 5GC.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"noted","reservation_date":"2021-05-10 10:58:50","uploaded":"2021-05-10 15:11:49","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104329.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104343","title":"[DRAFT] Reply LS on introducing extended DRX for RedCap UEs","source":"China Mobile","contact":"Aihua Li","contact-id":58162,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS on introducing extended DRX for RedCap UEs","secretary_remarks":"Response to S2-2103769. Merged into S2-2103796 (Postponed)","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10270,"status":"postponed","reservation_date":"2021-05-10 11:06:32","uploaded":"2021-05-10 15:11:49","revisionof":"","revisedto":"","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_145E_Electronic_2021-05\/Docs\/S2-2104343.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104358","title":"Discussion on long eDRX value system impact to support RedCap.","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"discussion","for":"Agreement","abstract":"This document discusses the long eDRX value system impact to support the REDCAP.","secretary_remarks":"Noted","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"noted","reservation_date":"2021-05-10 11:58:07","uploaded":"2021-05-10 21:23:10","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"NR_redcap-Core"},{"winame":" TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104358.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104617","title":"Updates of Processing AF requests to influence AM policies procedure","source":"China Mobile","contact":"Dan Wang","contact-id":87155,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Update procedure of supporting SM-PCF influence AM policies, PCF for the PDU Session takes the initiative to find the PCF for UE by requiring BSF or NRF.","secretary_remarks":"Confirm Spec version used - CR states 17.1.0! Not Handled","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10400,"status":"not treated","reservation_date":"2021-05-10 14:38:03","uploaded":"2021-05-10 14:41:58","revisionof":"","revisedto":"","release":"Rel-17","crspec":23.502,"crspecversion":"17.0.0","workitem":[{"winame":"TEI17_DCAMP"}],"crnumber":2848.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104617.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104787","title":"[DRAFT] LS on 5G capabilities exposure for factories of the future","source":"Nokia","contact":"Laurent Thiebaut","contact-id":72921,"tdoctype":"LS out","for":"Approval","abstract":"SA WG2 have discussed the LS from 5G-ACIA and would like to 1. Suggest that TSG SA co-ordinates the answers from SA WG1, SA WG2, SA WG3 and SA WG6 to provide an unique answer from 3GPP perspective 2. Tell SA plenary that it plans to provide its own technical at its August meeting i.e. for the TSG SA plenary","secretary_remarks":"Related to S2-2103727","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"revised","reservation_date":"2021-05-17 15:18:14","uploaded":"2021-05-17 15:19:31","revisionof":"","revisedto":"S2-2104794","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG1, SA WG3, SA WG6","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104787.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104794","title":"LS on 5G capabilities exposure for factories of the future","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":72921,"tdoctype":"LS out","for":"Approval","abstract":"To: TSG SA, SA WG1, SA WG3, SA WG6. CC: SA WG5, CT WG3","secretary_remarks":"Revision of S2-2104787r03. Approved","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10180,"status":"approved","reservation_date":"2021-05-25 06:15:58","uploaded":"2021-06-01 06:21:31","revisionof":"S2-2104787","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG1, SA WG3, SA WG6","Cc":"SA WG5, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104794.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2104994","title":"Reply LS on the conclusion of FS_MINT-CT","source":"SA WG2","contact":"Hyunsook Kim","contact-id":42013,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1, TSG SA","secretary_remarks":"Revision of S2-2104043r02 + changes. Approved","agenda_item_sort_order":7,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10380,"status":"approved","reservation_date":"2021-05-25 06:17:16","uploaded":"2021-06-01 06:21:31","revisionof":"S2-2104043","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_MINT-CT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2103748","lsto":"CT WG1, TSG SA","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_145E_Electronic_2021-05\/Docs\/S2-2104994.zip","group":"S2","meeting":"S2-145-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]