[{"name":"S2-2105225","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-2103718 from S2-145E. Response drafted in S2-2105386. Final response in S2-2106536","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10280,"status":"replied to","reservation_date":"2021-06-24 14:38:55","uploaded":"2021-06-25 10:42:11","revisionof":"S2-2103718","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, TSG CT, TSG SA","Cc":"CT WG3","lsoriginalls":"C1-207769","lsreply":"S2-2106536","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105225.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105229","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-2103727 from S2-145E. Response drafted in S2-2105854. Final response in S2-2106683","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10340,"status":"replied to","reservation_date":"2021-06-24 14:38:55","uploaded":"2021-06-25 10:42:11","revisionof":"S2-2103727","revisedto":"","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":"S2-2106683","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105229.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105231","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-2103729 from S2-145E. Duplicate LS in S2-2105365. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10030,"status":"noted","reservation_date":"2021-06-24 14:38:55","uploaded":"2021-06-25 10:42:11","revisionof":"S2-2103729","revisedto":"","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_146E_Electronic_2021-08\/Docs\/S2-2105231.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105233","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":"Revision of postponed S2-2103732 from S2-145E. Response drafted in S2-2105659. Final response in S2-2106534","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"replied to","reservation_date":"2021-06-24 14:38:55","uploaded":"2021-06-25 10:42:11","revisionof":"S2-2103732","revisedto":"","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":"S2-2106534","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105233.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105239","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":"Revision of postponed S2-2103765 from S2-145E. Responses drafted in S2-2105696 and S2-2106177. Final response in S2-2106684","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10400,"status":"replied to","reservation_date":"2021-06-24 14:38:56","uploaded":"2021-06-25 10:42:11","revisionof":"S2-2103765","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1","lsoriginalls":"C4-212401","lsreply":"S2-2106684","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105239.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105272","title":"LS from RAN WG2: LS on Paging Subgrouping","source":"RAN WG2","contact":"Li-Chuan Tseng","contact-id":59751,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 discussed ways to group UEs sharing a paging occasion into multiple subgroups, as a means to reduce paging false alarm, thereby leading to additional UE power savings. RAN WG2 made the following agreements in RAN WG2#113bis-e: ? We adopt Network controlled subgrouping (based on individual UE characteristics, not specified or limited to paging prob as EUTRA, possibly with additional randomization) ? If the network chooses to not provide specific subgrouping information, there will be configuration option where subgrouping can be supported by randomization (by UE-ID). RAN WG2 made the following agreements in RAN WG2#114-e: The following is supported: ? CN is responsible for allocating UEs to UE paging subgroups based on UE characteristics ? Use same UE subgroups when in RRC_IDLE and RRC_INACTIVE. RAN WG2 respectfully asks RAN WG3, SA WG2, and CT WG1 to take the above information into account for their future work.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"postponed","reservation_date":"2021-06-24 14:38:57","uploaded":"2021-06-25 10:42:12","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, SA WG2, CT WG1","Cc":"","lsoriginalls":"R2-2106552","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105272.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105275","title":"LS from RAN WG3: Reply LS to CT4 on Information on the port number allocation solutions","source":"RAN WG3","contact":"Xudong Yang","contact-id":47264,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 would like to thank CT WG4 for their LS on Information on the port number allocation solutions.RAN WG3 had discussions the different solutions in the TR, and reached the following understandings: From RAN WG3 perspective: - Both Solutions 1 and 2 are feasible. - RAN WG3 also noticed that Solution 11 is a once-and-for-all solution that can be considered, though its adoption is not entirely under 3GPP control. It requires IETF endorsement. - The rest of the solutions are not desirable.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10050,"status":"noted","reservation_date":"2021-06-24 14:38:57","uploaded":"2021-06-25 10:42:12","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"SA WG4, CT WG3, SA WG5, TSG SA, TSG CT, TSG RAN, SA WG2, RAN WG2","lsoriginalls":"R3-212800","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105275.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105277","title":"LS from RAN WG3: Reply LS to LS on User Plane Integrity Protection for eUTRA connected to EPC","source":"RAN WG3","contact":"Luis Lopes","contact-id":84588,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 thanks SA WG3 for the received LS on User Plane Integrity Protection for eUTRA connected to EPC. RAN WG3 can provide the following feedback on the questions raised by SA WG3: 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? Answer: As the impact is mostly on RAN WG2 protocols, RAN WG3 can follow RAN WG2's proposed way forward, i.e. to support UP IP only for NR PDCP in rel-17. c) (RAN 3 and CT 1) is a MME mandated to copy all the EEA\/EIA bits from NAS signalling into the S1-AP signalling? Answer: RAN WG3 thinks the MME may copy all the EEA\/EIA bits from NAS to S1-AP. However, RAN WG3 is not aware of a clear mandate on the MME to copy all EEA\/EIA bits from NAS signalling into S1AP, and so cannot rule out that some implementations may not do so. d) (RAN 3) is a legacy eNB mandated to copy all the EEA\/EIA bits from S1A-AP signalling into the X2-AP signalling at handover and secondary node addition? Answer: RAN WG3 thinks that eNB may copy all the EEA\/EIA bits from S1-AP signalling into X2AP signalling. However there is no explicit mandate on eNBs for this behaviour. Action: RAN WG3 kindly asks the above groups to take the above information into account and provide further updates as needed.","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":"2021-06-24 14:38:57","uploaded":"2021-06-25 10:42:12","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3, RAN WG2, CT WG1, CT WG4, SA WG2","Cc":"","lsoriginalls":"R3-212812","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105277.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105281","title":"LS from RAN WG3: LS on the mapping between service types and slice at application","source":"RAN WG3","contact":"Shankar Krishnan","contact-id":85873,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 is discussing how to support per-slice QoE i.e. QoE measurement collection and reporting separately for a given slice. While discussing solutions for per-slice QoE, RAN WG3 noticed that the application is aware of established 5GS PDU sessions including slice information via AT command +CGDCONT defined in TS 27.007. However, RAN WG3 is not sure whether the application is aware of the mapping between service types and slice. For example, in scenarios where an application can run on multiple slices, the mapping information might be needed in order to determine whether to perform QoE measurement collection on the configured slice.","secretary_remarks":"Response drafted in S2-2105862. Final response in S2-2106537","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10460,"status":"replied to","reservation_date":"2021-06-24 14:38:57","uploaded":"2021-06-25 10:42:12","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG4, CT WG1, SA WG5","Cc":"RAN WG2, SA WG2","lsoriginalls":"R3-212904","lsreply":"S2-2106537","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105281.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105284","title":"LS from RAN WG3: LS on Insufficient UE Capabilities Cause Value","source":"RAN WG3","contact":"Angelo Centonza","contact-id":45800,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 would like to kindly inform CT WG4 that the attached CRs have been agreed. In these CRs a new cause value has been added over the S1 and NG interfaces, the cause value being defined as follows: Radio Network Layer cause Meaning Insufficient UE Capabilities The procedure can't proceed due to insufficient UE capabilities. In order to make the new cause value visible over inter system handover procedures, RAN WG3 would like to ask CT WG4 to take the newly added cause value into account in their specifications and to allow for mapping of the cause value between the NGAP and S1AP handover failure procedures.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"noted","reservation_date":"2021-06-24 14:38:57","uploaded":"2021-06-25 10:42:12","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"SA WG2","lsoriginalls":"R3-212934","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105284.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105286","title":"LS from RAN WG3: LS on (de)activation and failure handling of NR QMC","source":"RAN WG3","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 is discussing the activation, deactivation and failure handling for NR QMC. The main open point is whether to reuse the Trace function as in LTE QMC or to define a new dedicated function to support NR QMC. The existing Trace function supported by RAN WG3's interfaces is based on the Trace mechanism described in TS 32.422. RAN WG3 noticed some principles of the Trace mechanism in TS 32.422: 'There can only be one Trace Recording Session Reference per Trace Reference at one given time for a UE trace session. So there shall be only one TR\/TRSR to be propagated during NG and Xn handover. If the Trace Reference is the same as an existing Trace Session for the same subscriber or equipment, and the Trace Recording Session Reference is the same as the existing Trace Recording Session in the existing Trace Session having the same Trace Reference, the NG-RAN node shall not start a new Trace Recording Session and shall continue with the existing trace session and ignore the second request. If the Trace Reference is the same as an existing Trace Session for the same subscriber or equipment, and the Trace Recording Session Reference is not the same as the existing Trace Recording Session in the existing Trace Session having the same Trace Reference, the NG-RAN node shall continue with the existing trace session and ignore the second request.' In the discussion about whether to reuse the Trace function or to define a new one for NR QMC, RAN WG3 has identified the following issues: - How to ensure that a Trace deactivation message does not necessarily deactivate the QMC configuration previously activated with the Trace message bearing the same NG-RAN Trace ID? - How to decouple legacy Trace\/MDT related failure from QMC-related failure? - In case the Trace function is reused, how to configure QoE measurement without configuring the trace session? RAN WG3 kindly requests SA WG5's feedback and support on the following questions: Q1: Whether and how the Trace mechanism can handle, or be enhanced to handle, the scenario that QMC is triggered after legacy trace for one UE, while the legacy trace and\/or MDT still need to be kept? In this case, will the TR\/TRSR for the QMC session be different from the TR\/TRSR used for legacy trace and\/or MDT session? If yes, will the TR\/TRSR for the QMC session and the TR\/TRSR used for legacy trace and\/or MDT session exist simultaneously for one UE? Q2: Whether and how the Trace mechanism can be enhanced to support multiple QMC activation\/deactivation towards one UE at same or different time? Will the triggered QMC sessions use different TR\/TRSR? Can the Trace mechanism be enhanced to support multiple QMC sessions for one UE with different TR\/TRSR? Q3: In case Multiple QMC is supported, whether one QMC job identified by QoE Reference is per service type or per slice for NR QoE? RAN WG3 assume below possibilities can be considered (both options involve multiple QMC jobs per UE): - One QMC job includes one QoE reference, slice(s), and multiple service types. - One QMC job includes one QoE reference, one service type, and slice(s). Q4: Whether the Measurement Collection Entity IP Address will be configured per service type or per QoE Reference? Q5: Is there a mechanism to ensure uniqueness of the QoE Reference for area-based QMC, where UE selection is performed by the NG-RAN?","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"noted","reservation_date":"2021-06-24 14:38:57","uploaded":"2021-06-25 10:42:13","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG5","Cc":"SA WG2","lsoriginalls":"R3-212975","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105286.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105287","title":"LS from SA WG1: LS Response on Media-Related Services and Requirements","source":"SA WG1","contact":"Xiaonan Shi","contact-id":83457,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 thanks SA WG4 for LS on Media-Related Services and Requirements. About SA WG1 Rel-18 ongoing media-related studies, use cases and potential requirements can be found in the following TRs: - TR 22.847 'Study on supporting tactile and multi-modality communication services' - TR 22.873 'Study on evolution of the IP Multimedia Subsystem (IMS) multimedia telephony service' - TR 22.874 'Study on traffic characteristics and performance requirements for AI\/ML model transfer' For any further updates on these studies and subsequent normative work, please refer to the latest 3GPP Work Plan (available at ftp:\/\/ftp.3gpp.org\/Information\/WORK_PLAN.) , and the SA WG1 chair reports to SA plenary. SA WG1 would like to kindly remind SA WG4 that Rel-18 Stage-1work is planned to be completed by December 2021 (80% ready by September).","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"noted","reservation_date":"2021-06-24 14:38:57","uploaded":"2021-06-25 10:42:13","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG4","Cc":"TSG SA, SA WG2, RAN WG1, SA WG6","lsoriginalls":"S1-211364","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105287.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105289","title":"LS from A WG3: LS on Clarifications of Network slice selection during AMF Reallocation","source":"SA WG3","contact":"Sheeba Backia Mary Baskaran","contact-id":86031,"tdoctype":"LS in","for":"Action","abstract":"SA WG3 is currently working on the 'Study on the security of Access and Mobility Management Function (AMF) re-allocation' in TR 33.864. The study is focusing on addressing the registration failure issue related to AMF re-allocation and indirect reroute via RAN (option (B)) specified in TS 23.502 Clause 4.2.2.2.3. TR 33.864 Key Issue #1 describes the registration failure scenario in detail. To solve the above repeated registration failure issue, SA WG3 is discussing solutions 6 and 7 from the TR 33.864. In the procedure of registration with AMF reallocation via RAN defined by SA WG2, the initial AMF may only be able to obtain Requested NSSAI by one of two methods for different scenarios mentioned in 33.864 Clause 4.3, i.e., (method 1) Requested NSSAI can be obtained after NAS SMC procedure, i.e. from the complete Registration Request message in NAS Security Mode Complete message (or) (method 2) if the UE sends a protected registration request, then the initial AMF if it can fetch current 5G security context from the source\/old AMF, then the initial AMF will be able to get the requested NSSAI without NAS SMC. For scenarios that require method-1, Solution 6, 7 in TR 33.864 however proposes not to run NAS SMC, just to fetch Requested NSSAI (which means that, the initial AMF may not have the Requested NSSAI). Solution 6, and 7 have the following points as their core principle, which need to be evaluated by SA WG2:. Questions: Based on the above information SA WG3 would like to know the views of SA WG2 for the following questions respectively. The Initial AMF during registration procedure after successful 'primary authentication' does not initiate NAS SMC, and hence may not obtain the Requested NSSAI. In case, the Initial AMF does not have the Requested NSSAI, - Question 1: If the initial AMF successfully obtains 'slice selection subscription data' from the UDM with SUPI, is it feasible for the initial AMF to perform network slice selection using the Nnssf_NSSelection_Get service operation without Requested NSSAI, but using all other existing IEs as inputs (e.g., subscribed NSSAI etc. as in 23.502 clause 5.2.16.2.1)? - Question 2: Is it feasible to use the Nnssf_NSSelection_Get service operation defined in TS 23.502 Clause 5.2.16.2.1 for network slice selection in Clause 4.2.2.3 Registration with AMF re-allocation? - Question 3: Can the initial AMF skip NAS SMC for retrieving the Full Registration Request containing Requested-NSSAI before performing the Nnssf_NSSelection_Get service operation? - Question 4: Can the initial AMF determine that NAS reroute is needed without Requested NSSAI? If yes, what slice will be used and How is target AMF determined? o Kindly also consider the following information where relevant while providing the response: ? TS 29.531 Clause 5.2.2.2.2, Clause 6.1.6.2.10 and Clause 6.1.6.2.2 respectively. - Question 5: How can target AMF obtain the Requested NSSAI? After the target AMF receives the Requested NSSAI, is it possible that an AMF reallocation can occur? Action: SA WG3 kindly asks SA WG2 to answer the above questions.","secretary_remarks":"Responses drafted in S2-2105344, S2-2105482 and S2-2106113. Final response in S2-2106686","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10490,"status":"replied to","reservation_date":"2021-06-24 14:38:58","uploaded":"2021-06-25 10:42:13","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S3-212124","lsreply":"S2-2106113","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105289.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105298","title":"LS from SA WG3: Reply-LS on Secondary AUTH for 5GS interworking with EPS","source":"SA WG3","contact":"Christine Jost","contact-id":49662,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 would like to thank CT WG3 for their LS S3-211376\/C3-210377 on Secondary AUTH for 5GS interworking with EPS, and SA WG2 for their reply-LS S3-211397\/S2-2101305 on the same topic. SA WG3 would like to provide the following replies to the question raised by CT WG3. The replies provided by SA WG2 are included for convenience. CT WG3 Q1: Whether EAP based secondary authorization\/ authentication is also applicable for EPS, when the UE supports EAP. [SA WG2 reply in S2-2101305]: EAP based secondary authorization\/ authentication has only been defined for 5GS and is thus not applicable to EPS in existing releases. SA WG2 expects that in case EAP based secondary authorization\/ authentication is to be introduced in EPS it would require a new work item in SA WG2.] SA WG3 reply: SA WG3 confirms SA WG2's reply. In case EAP-based secondary authentication is to be introduced in EPS, it would require a new work item in SA WG3 as well. SA WG3 currently has no plans to initiate such a work item, and no requirements for such a work item have been raised in SA WG3. CT WG3 Q2: When the DN-AAA server initiates EAP based re-authorization but UE has moved from 5GS to EPS, whether such re-authorization will be supported. [SA WG2 reply in S2-2101305: If the re-authorization is associated with EAP based re-authentication procedure, then the re-authorization will not be supported since EAP-based re-authentication cannot be performed when the UE is in EPS in existing releases. However, if based on local policy the DN-AAA server initiates DN-AAA re-authorization without performing re-authentication, then a DN-AAA re-authorization (without EAP-based re-authentication) can be supported even when UE is in EPS: this may be used. to provide new parameters from the DN-AAA server to SMF+PGW-C.] SA WG3 reply: SA WG3 confirms SA WG2's reply. CT WG3 Q3: If only PAP\/CHAP based secondary authorization\/authentication is applicable in EPS, how to handle the case when the DN-AAA server initiates EAP based re-authorization but UE has moved from 5GS to EPS. [SA WG2 reply in S2-2101305: SA WG2 assumes that CT WG3 refers to the re-authorization associated with EAP-based re-authentication procedure scenario. SA WG2 expects that in such case the SMF+PGW-C, that receives the re-authentication request from the DN-AAA, can inform the DN-AAA server that the UE is not available for EAP-based re-authentication at the moment. The SMF+PGW-C should not initiate PDN connection release: the DN-AAA can decide based on the reply from SMF+PGW-C and based on local policy what actions to take in that case, but this is out of 3GPP scope.] SA WG3 reply: SA WG3 confirms SA WG2's reply. SA WG3 believes that updates agreed by SA WG2 (S2-2101312, CR 2475r2 to TS 23.502) address the necessary changes to stage-2 specifications and no additional updates to specifications under the remit of SA WG3 are necessary.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"noted","reservation_date":"2021-06-25 10:32:22","uploaded":"2021-06-25 10:42:13","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3, SA WG2","Cc":"CT WG1","lsoriginalls":"S3-212366","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105298.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105304","title":"LS reply to LS from WSOLU to 3GPP SA5 - 5G charging architecture for wholesale scenarios","source":"SA WG5","contact":"Robert T\u00f6rnkvist","contact-id":35172,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 would like to thank GSMA WSOLU for their LS on 5G charging architecture for wholesale scenarios. To investigate on solutions for how SA WG5 can fulfilling the wholesale and retail business requirements outlined in the LS (S5-213020), at their SA WG5#137e meeting, SA WG5 has approved to start a study item on 5G roaming charging architecture for wholesale and retail scenarios planned for completion within 3GPP Rel-17 timeframe. This study is, waiting for TSG SA#92-e plenary approval in June.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"noted","reservation_date":"2021-06-25 10:32:23","uploaded":"2021-06-25 10:42:11","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA WSOLU","Cc":"GSMA IDS, GSMA NG, SA WG2","lsoriginalls":"S5-213583","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105304.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105305","title":"LS from SA WG6: LS on 5G capabilities exposure for factories of the future","source":"SA WG6","contact":"Camilo Solano","contact-id":80091,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 discussed the incoming LS from 5G-ACIA on 5G capabilities exposure for factories of the future - revised in SA WG6#43-e, and decided: 1) Follow the decision of other involved WGs and request SA to provide a coordinated reply to 5G-ACIA; 2) Provide an input to SA about the work SA WG6 has addressed related to the 5G-ACIA white paper to be considered for the coordinated SA reply. Therefore, SA WG6 would like to request SA to coordinate such a reply to 5G-ACIA and take into consideration the following input about the related SA WG6 work. SA WG6 has addressed service layer exposure requirements for industrial applications within Release 17 in the study on application layer support for Factories of the Future in 5G network. This study was done based on 5G network exposure capabilities and SA WG1 requirements. The SA WG6 study is documented in the technical report 3GPP TR 23.745. As described in the latest version of 3GPP TR 23.745, identified key issues, solutions and conclusions at the application enablement layer have been addressed which may be of interest of 5G-ACIA. For instance, device management requirements on device identity management, device connectivity management (e.g. for time sensitive communication support, TSN support, QoS monitoring), device connectivity monitoring, device group management (e.g. 5GLAN group management) and device location information are some of the addressed key issues within the SA WG6 study. Other requirements have also been addressed within this study, e.g. clock synchronization. Also, some of the concluded solutions in 3GPP TR 23.745 have already been specified in Release 17 as part of enhancements to the Service Enabler Architecture Layer for Verticals (SEAL) in the technical specification 3GPP TS 23.434. Besides, SA WG6 would like to request 5G-ACIA to provide any feedback on the completed work in 3GPP TR 23.745 and the solutions introduced in SEAL in order to continue the collaboration on service exposure capabilities for industrial applications. Likewise, SA WG6 would like to ask 5G-ACIA to encourage its members to actively engage in the related SA WG6 activities.","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10390,"status":"noted","reservation_date":"2021-06-25 10:32:23","uploaded":"2021-06-25 10:42:11","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG1, SA WG2, SA WG3, SA WG5, CT WG3","lsoriginalls":"S6-211497","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105305.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105344","title":"[DRAFT] Reply LS on Clarifications of Network slice selection during AMF Reallocation","source":"Nokia, Nokia Shanghai Bell","contact":"Alessio Casati","contact-id":82456,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3","secretary_remarks":"Response to S2-2105289. Merged into S2-2106686","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10500,"status":"merged","reservation_date":"2021-07-22 12:58:54","uploaded":"2021-08-02 15:36:00","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105344.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105355","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":"Response drafted in S2-2106047. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10350,"status":"noted","reservation_date":"2021-07-26 05:56:17","uploaded":"2021-07-26 08:04:39","revisionof":"","revisedto":"","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, ETG, IEC, IEEE, oneM2M, OPC, PI, TM Forum","lsoriginalls":"5G-ACIA_LS_3GPP_Exposure_18032021_Final","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105355.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105356","title":"LS from GSMA 5GJA: LS on Traffic Categories in URSP","source":"GSMA 5GJA","contact":"Ralf Keller","contact-id":11142,"tdoctype":"LS in","for":"Action","abstract":"GSMA NG 5GJA has profiled the use of URSP in GSMA PRD NG.114 and NG.113 based on the currently supported URSP functionality in 3GPP TS 23.503 and in 3GPP TS 24.526. GSMA NG 5GJA has discussed the need to support standardized and MNO-specific traffic categories in the traffic descriptor in URSP. Examples of traffic categories to be standardized are: - Enterprise: traffic from one or more applications related to Enterprise service - Gaming: traffic from one or more applications related to Gaming service, e.g., with low latency requirement - Video Streaming: traffic from one or more applications related to Video Streaming, e.g., HD video streaming, 4K video streaming Standardized traffic categories could be defined by 3GPP or by GSMA. MNO-specific traffic categories should be represented by a number of octets (flexible format to allow any string). A given traffic category can be used by more than one application simultaneously, and one application can simultaneously use more than one traffic category. Action: GSMA NG 5GJA kindly requests SA WG2 to consider the above requirements and to provide feedback to GSMA on how to support traffic categories.","secretary_remarks":"Postponed","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10180,"status":"postponed","reservation_date":"2021-07-26 05:56:17","uploaded":"2021-07-26 08:04:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"5GJA17_104","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105356.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105357","title":"LS from GSMA ACJA: 3GPP SA WG1 clarifications on problematic UAV","source":"GSMA ACJA","contact":"Ralf Keller","contact-id":11142,"tdoctype":"LS in","for":"Information","abstract":"ACJA thanks SA WG1 for their liaison statement in S1-210359. ACJA has discussed the changes to TS 22.125. With respect to the newly formulated requirement: [R-5.1-017] The 3GPP system shall support the UTM in detection of UAV operating without authorization. ACJA expresses concerns about the feasibility and logic of such requirement and sees the scenarios below to be considered:. ? Scenario A: a UAV without a 3GPP aerial subscription that happens to be flying (and thus unauthorized both from a subscription point of view and from an UTM point of view) ? Scenario B: a UAV with an aerial subscription that did not register to the 3GPP network using release 17 mechanisms and therefore did not get authorized for UAV operations in a 3GPP network ? Scenario C: a UAV with an aerial subscription tries to register to the 3GPP network using release 17 mechanisms and 3GPP network receives a negative authentication\/authorization response from UTM (i.e. the UAV is not authorized). 3GPP system may keep the UAV UE registered without access to aerial services i.e. not authorized for UAV operations using 3GPP network. ACJA kindly asks SA WG1 to clarify which scenario the requirement refers to, considering the following points: ? A UAV operating without authorization as in the scenarios A & B above is a UE that is registered and connected to the MNO network and has not indicated any UAV features and\/or does not have an aerial subscription. As such, it is indistinguishable from e.g. a normal UE on a helicopter, which is flying but not autonomously, or high speed elevator in a tall building, which may appear to be flying vertically. As such, ACJA believes it is not reasonable to ask a 3GPP system to detect which UEs are actually autonomously flying unauthorized UAVs versus regular UEs that may be in motion but not flying autonomously. ? Moreover, such unauthorized UAVs, based on 3GPP mechanisms, are not identifiable as aviation entities and the 3GPP system is not aware of any associated aviation identity, and as such, they cannot be reported to the UTM. o The only information available to the 3GPP system about such UEs is their permanent 3GPP identity, which is of no use to the UTM since it does not identify the UAV, the UAV operator, or the UAV pilot. o Without an aviation-level identity provided by the UAV to the 3GPP system, the 3GPP system does not know to which entity in the UTM the UAV should be reported to. o The UTM is only aware of aviation-level identifiers and maintains no correlation between such identifiers and the 3GPP identities, unless release 17 mechanisms being defined in SA WG2 are in place and the UAV is authorized and authenticated as may be required in the operating jurisdiction. Regarding the usage of the term 'UAV' in the requirements provided in the liaison statement, and the use of the same in 22.125, especially when in the context of identification and authorization for operation, we recognize a need to explicitly define what is the intended meaning. Is the UAV referring to: a. the aerial equipment, b. the modem with RAN access (UE) embedded in the aerial equipment, as registered in the UTM, c. the full-set of a and b together, or d. other As such, to avoid misinterpretation of such statements, we suggest that the definition be provided in express words as they lead to different interpretations on authorization for operation and identification. ACJA recommends describing the requirement more in detail considering the actual UTM functionality, or eliminating it completely","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"noted","reservation_date":"2021-07-26 05:56:17","uploaded":"2021-07-26 08:04:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG6","Cc":"SA WG2, SA WG3","lsoriginalls":"5GJA17_104","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105357.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105359","title":"LS from BBF: Alignment concerning 5G RG requirements and its remote management","source":"BBF","contact":"Lincoln Lavoie","contact-id":39231,"tdoctype":"LS in","for":"Information","abstract":"Dear colleagues, As you are aware, BBF and 3GPP are collaborating on the 5G WWC project. BBF is progressing its work on 5G RG specifications and its remote management via TR-069 and TR-369. You can find the latest specifications related to 5G WWC in Tr-470i1, Tr-456i1, Tr-124i6 and TR-181 amendment 14 on BBF web site. Issue 2 of those documents are in the making and expected for 4Q2021. It came to our attention that SA WG1 has also started working on a study document: TR 28.858, 'Technical Specification Group Services and System Aspects; Study of Enhancements for Residential 5G; Stage 1'. As this study is touching on some aspects of 5G RG behavior, we think now is the right time to align. We propose SA WG1 collaborate with the BBF on study of requirements dealing with 5G RG as well as the management of 5G RG, especially when these requirements go beyond the role of the 5G RG acting as a 3GPP UE? Further, we would request an opportunity to review the proposed requirements related to a 5G RG and its remote management before any normative requirements would be defined within SA WG2. We look forward to continuing our fruitful relationship. Thanks, Lincoln Lavoie Broadband Forum Technical Committee Chair","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"noted","reservation_date":"2021-07-26 05:56:17","uploaded":"2021-07-26 08:04:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"SA WG2","lsoriginalls":"LIAISE-467-03","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105359.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105360","title":"LS from GSMA NRG: LS to 3GPP SA2 on ARP PL","source":"GSMA NRG","contact":"Ralf Keller","contact-id":11142,"tdoctype":"LS in","for":"Action","abstract":"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. Action: The GSMA NG NRG kindly requests SA WG2 to take this information into account and to provide feedback.","secretary_remarks":"Duplicate LS in S2-2105233. Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"noted","reservation_date":"2021-07-26 05:56:17","uploaded":"2021-07-26 08:04:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG3","lsoriginalls":"NRG 009_201","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105360.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105363","title":"LS from ITU-T SG11: LS on the new work item Q.DC-SA 'Signalling architecture of data channel enhanced IMS network'","source":"ITU-T SG11","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"During the ITU-T Study Group 11 interim Rapporteur Group meeting (e-meeting, 7 -16 July 2021), Q1\/11 (Signalling and protocol architectures for telecommunication networks and guidelines for implementations) has created a new work item Q.DC-SA 'Signalling architecture of data channel enhanced IMS network' (SG11-TD102\/WP1). ITU-T Q.DC-SA provides the signalling architecture of data channel enhanced IMS network. It presents the overview of data channel technology and discusses the research on data channel based IMS network. It also analyzes the necessities of research on signalling architecture of data channel based IMS network and specifies the framework and interfaces of data channel enhanced IMS network. This draft Recommendation will build on 3GPP TS 26.114, IETF RFC8831 and ITU-T Y.3104 and will be aligned with them. ITU-T Q1\/11 would like to thank you for your attention, feedback and cooperation on this topic. The description of the new work item Q.DC-SA is available in the Q1\/11 report as highlighted in A.1 justification form (see Annex B of the report).","secretary_remarks":"Noted","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"noted","reservation_date":"2021-07-26 05:56:17","uploaded":"2021-07-26 08:05:36","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"-","Cc":"IETF RTCWEB WG, SA WG4, SA WG2","lsoriginalls":"SG11-LS200.","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105363.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105364","title":"LS from SMPTE 32NF Technology Committee: PTP device monitoring Public Committee Draft","source":"SMPTE 32NF Technology Committee","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Dear 3GPP Liaison Officer, The SMPTE Drafting Group on PTP monitoring (TC-32NF-80 DG on ST 2059-2 PTP Device Monitoring) is developing an engineering document that will provide guidance on implementing PTP monitoring into professional media equipment. The group designed a YANG Data Model based upon IETF RFC 8575 and extended the work to include additional containers covering further parameters that provide further information related to time transfer in an extended ecosystem. This work, SMPTE RP 2059-15, is currently in Public Committee Draft (PCD) and therefore publicly accessible online at the following location: https:\/\/github.com\/SMPTE\/rp2059-15 To finalize RP 2059-15, SMPTE is seeking feedback on the proposed data model in order to ensure it will match industry expectations in terms of capabilities and usability across a number of use cases. SMPTE would appreciate feedback on the proposed PTP monitoring YANG data model, from 3GPP and its membership, via the GitHub tools, conventional correspondence, and the online survey available at the following location: https:\/\/www.surveymonkey.com\/r\/29GGT87 Please send conventional correspondence to svp@smpte.org with cc: to liaisons-chair@smpte.org. Many thanks & best regards, Bruce Devlin SMPTE Standards Vice-Presiden","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":"2021-07-26 05:56:17","uploaded":"2021-07-26 08:04:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"3GPP","Cc":"","lsoriginalls":"SLC04-smpte-to-3GPP-PCD-RP2059-15-2021-04-28","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105364.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105365","title":"LS from WBA PMO: Liaison Statement on 5G & Wi-Fi RAN Convergence","source":"WBA PMO","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","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. Executive summary included in the annex below highlights potential challenges identified in these areas. Specific ask: Today it is possible that 5G services may be realized over WLAN, however these services may be enhanced by adding some standard based solutions for the challenges identified in the 5G and Wi_x0002_Fi RAN Convergence paper. As a result, we believe close cooperation with the industry and standard bodies is key, and we will be looking to receive any feedback on the challenges identified in the paper related to the 5G and Wi-Fi convergence, pertaining to the current scope of work of your organization. Some of the specific challenges for 3GPP considerations may include: - ATSSS related challenges, including ATSSS policy combining with other UE-based policy, deployment limitations of ATSSS MPTCP converter proxy, incorporating UE local conditions in ATSSS, support for packet level traffic steering for all traffic types, enabling ATSSS operation with MP-Capable servers, incorporating RAN level measurements for dynamic traffic steering decisions in ATSSS, and coexistence of ATSSS inner MPTCP with outer MPTCP on the UE. - End-to-end QoS related challenges, including considerations for leveraging standardized 5QI to DSCP mapping on TNGF\/N3IWF and UE, providing 5G QoS information to the UE for untrusted WLAN access, and considerations for mapping each 5G QoS flow to a separate IPsec SA on TNGF\/N3IWF to enable supporting per 5G flow QoS differentiation over the WLAN access. - Policy related challenges and potential enhancements, including extension to WLANSP rules with additional Wi-Fi QoS metrics for selection criteria and enhancement to URSP rules by extending the validity criteria to specify valid Wi-Fi networks for MA-PDU session. - Challenges related to supporting Wi-Fi only devices without USIM connecting to the 5G Core, including the need to define 3GPP architecture and procedures for supporting Wi-Fi only UEs with non-IMSI based identity and EAP-TLS\/EAP-TTLS based authentication to access 5G SNPN core over WLAN access via N3IWF, TNGF or TWIF. 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 highli","secretary_remarks":"Response drafted in S2-2106527. Final response in S2-2106533","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10190,"status":"replied to","reservation_date":"2021-07-26 05:56:17","uploaded":"2021-07-26 08:04:39","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG2","Cc":"","lsoriginalls":"WBA_LS_2021 v1F-3GPP SA","lsreply":"S2-2106533","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105365.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105367","title":"LS from NGMN: NGMN Liaison Statement on 5G Network Customization Based on Service-Based Architecture","source":"NGMN","contact":"Feifei Lou","contact-id":80387,"tdoctype":"LS in","for":"Information","abstract":"NGMN 5G Network Customization Based on Service-Based Architecture (SBA) White Paper The White Paper was started in July 2019, investigating the key technologies that can support operators to customize 5G network based on SBA. The main content includes four parts: - Service based UPF which includes control plane interaction and user plane service chaining - Enhancement of Edge Computing in 5G SBA network to support edge application server dynamic deployment and selection, and flexible service routing path configuration - Realization of Agile and Customized 5G Network to meet various verticals' requirement flexibly - Dynamic service management within one network slice, especially for dynamic control level mechanisms to pin resources within resource pool to specific customers. Intention of the LS and required Actions: This NGMN liaison is intended for information sharing about the completion of NGMN 5G Network Customization Based on SBA White Paper that have been introduced in the attached document. Please take this into account in the further study.","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":"2021-07-26 05:56:17","uploaded":"2021-07-30 08:33:24","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"210728 Liaison_NGMN","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105367.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105386","title":"[DRAFT] LS on Reliable Data Service Serialization Indications in Rel-16","source":"Convida Wireless LLC","contact":"Michael Starsinic","contact-id":72107,"tdoctype":"LS out","for":"Approval","abstract":"A reply LS to CT WG1 indicating that the Reliable Data Service Indications were removed from the Rel-16 specs.","secretary_remarks":"Response to S2-2105225. Revised to S2-2106536.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10290,"status":"revised","reservation_date":"2021-07-27 18:40:10","uploaded":"2021-07-27 18:53:48","revisionof":"","revisedto":"S2-2106536","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"RDSSI"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"TSG SA, TSG CT, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105386.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105387","title":"Removal of Reliable Data Service Serialization Indications","source":"Convida Wireless LLC","contact":"Michael Starsinic","contact-id":72107,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Removed the reliable data service serialization indications.","secretary_remarks":"Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"agreed","reservation_date":"2021-07-27 18:42:34","uploaded":"2021-07-27 18:53:48","revisionof":"","revisedto":"","release":"Rel-16","crspec":23.682,"crspecversion":"16.9.0","workitem":[{"winame":"RDSSI"}],"crnumber":480.0,"crrevision":"","crcategory":"F","tsg_crp":"SP-210934","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105387.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105388","title":"Removal of Reliable Data Service Serialization Indications","source":"Convida Wireless LLC","contact":"Michael Starsinic","contact-id":72107,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Removed the reliable data service serialization indications.","secretary_remarks":"Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"agreed","reservation_date":"2021-07-27 18:45:23","uploaded":"2021-07-27 18:53:48","revisionof":"","revisedto":"","release":"Rel-16","crspec":23.501,"crspecversion":"16.9.0","workitem":[{"winame":"RDSSI"}],"crnumber":3008.0,"crrevision":"","crcategory":"F","tsg_crp":"SP-210934","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105388.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105389","title":"Removal of Reliable Data Service Serialization Indications","source":"Convida Wireless LLC","contact":"Michael Starsinic","contact-id":72107,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Removed the reliable data service serialization indications.","secretary_remarks":"Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"agreed","reservation_date":"2021-07-27 18:47:57","uploaded":"2021-07-27 18:53:48","revisionof":"","revisedto":"","release":"Rel-16","crspec":23.502,"crspecversion":"16.9.0","workitem":[{"winame":"RDSSI"}],"crnumber":2897.0,"crrevision":"","crcategory":"F","tsg_crp":"SP-210934","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105389.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105482","title":"[DRAFT] Reply LS on Clarifications of Network slice selection during AMF Reallocation","source":"Lenovo, Motorola Mobility","contact":"Genadi Velev","contact-id":70944,"tdoctype":"LS out","for":"Action","abstract":"To: SA WG3","secretary_remarks":"Response to S2-2105289. Merged into S2-2106686","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10510,"status":"merged","reservation_date":"2021-08-05 20:51:07","uploaded":"2021-08-10 15:14:27","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105482.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105657","title":"ARP PL in EPS.","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"discussion","for":"Agreement","abstract":"This paper discusses the implication of downgrading ARP PL (Priority Level) in VPLMN and propose possible way forward.","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":"2021-08-09 11:06:58","uploaded":"2021-08-10 21:47:17","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105657.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105658","title":"ARP PL applied by MME per local configruation","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add in NOTE 9 of clause 4.7.2.1 that MME can downgrade ARP PL and the consequence of such downgrade.","secretary_remarks":"Revised to S2-2106535.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"revised","reservation_date":"2021-08-09 11:06:58","uploaded":"2021-08-10 21:47:17","revisionof":"","revisedto":"S2-2106535","release":"Rel-17","crspec":23.401,"crspecversion":"17.1.0","workitem":[{"winame":"TEI17"}],"crnumber":3648.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105658.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105659","title":"[DRAFT] Rely LS to LS SA WG2 on ARP PL","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"This paper replies to GSMA on ARP PL handling in MME","secretary_remarks":"Response to S2-2105233. Revised to S2-2106534.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10230,"status":"revised","reservation_date":"2021-08-09 11:06:59","uploaded":"2021-08-10 21:47:17","revisionof":"","revisedto":"S2-2106534","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105659.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105695","title":"Explicit indication for ATC","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add explicit indication to the AMF to show whether the ATC mechanism should be activated as proposed by CT WG4.","secretary_remarks":"CC#2: r07 agreed. Revised to S2-2106685.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10440,"status":"revised","reservation_date":"2021-08-09 13:49:01","uploaded":"2021-08-10 15:15:17","revisionof":"","revisedto":"S2-2106685","release":"Rel-17","crspec":23.501,"crspecversion":"17.1.1","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":3062.0,"crrevision":"","crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105695.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105696","title":"[DRAFT] LS Reply on Support of Asynchronous Type Communication in N1N2MessageTransfer","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"This LS clarifies the aspects on the ATC to CT colleagues.","secretary_remarks":"Response to S2-2105239. CC#2: r10 agreed. Revised, merging S2-2106177, to S2-2106684.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10410,"status":"revised","reservation_date":"2021-08-09 13:49:02","uploaded":"2021-08-10 15:15:17","revisionof":"","revisedto":"S2-2106684","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"SBIProtoc17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105696.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105854","title":"[DRAFT] LS on 5G capabilities exposure for factories of the future","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"[draft] LS on 5G capabilities exposure for factories of the future","secretary_remarks":"Response to S2-2105229. CC#2: r11 + changes agreed. Revised, merging S2-2106047, to S2-2106683.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10370,"status":"revised","reservation_date":"2021-08-09 21:07:34","uploaded":"2021-08-10 17:22:25","revisionof":"","revisedto":"S2-2106683","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105854.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2105862","title":"[DRAFT] Reply LS on the mapping between service types and slice at application","source":"Qualcomm Austria RFFE GmbH","contact":"Stefano Faccin","contact-id":57487,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3. CC: SA WG4, CT WG1, SA WG5, RAN WG2","secretary_remarks":"Response to S2-2105281. r03 agreed. Revised to S2-2106537.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10470,"status":"revised","reservation_date":"2021-08-09 22:34:27","uploaded":"2021-08-10 21:10:12","revisionof":"","revisedto":"S2-2106537","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"SA WG4, CT WG1, SA WG5, RAN WG2","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2105862.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106047","title":"[DRAFT] LS on 5G capabilities exposure for factories of the future","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"LS on 5G capabilities exposure for factories of the future","secretary_remarks":"Response to S2-2105355. Merged into S2-2106683","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10360,"status":"merged","reservation_date":"2021-08-10 08:54:53","uploaded":"2021-08-10 12:38:52","revisionof":"","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":[{"winame":"eNPN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA","Cc":"SA WG1, SA WG3, SA WG5, SA WG6, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106047.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106113","title":"[DRAFT] LS Response on Clarifications of Network slice selection during AMF Reallocation","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"LS response on clarifications of Network slice selection during AMF Reallocation","secretary_remarks":"Response to S2-2105289. CC#2: r15 + changes agreed. Revised, merging S2-2105344 and S2-2105482, to S2-2106686.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10520,"status":"revised","reservation_date":"2021-08-10 09:18:03","uploaded":"2021-08-10 15:08:40","revisionof":"","revisedto":"S2-2106686","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_AMFREAL_SEC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106113.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106177","title":"[DRAFT] Reply LS on Support of Asynchronous Type Communication in N1N2MessageTransfer","source":"Ericsson Inc.","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG4. CC: CT WG1","secretary_remarks":"Response to S2-2105239. Merged into S2-2106684","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10430,"status":"merged","reservation_date":"2021-08-10 11:02:05","uploaded":"2021-08-10 21:47:17","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"},{"winame":" SBIProtoc17"}],"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_146E_Electronic_2021-08\/Docs\/S2-2106177.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106223","title":"AUSF\/UDM discovery based SUCI information","source":"China Mobile","contact":"Yi Jiang","contact-id":40863,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Public Key ID is allowed to be used for AUSF\/UDM discovery.","secretary_remarks":"Revised to S2-2106538.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10540,"status":"revised","reservation_date":"2021-08-10 11:54:55","uploaded":"2021-08-10 16:21:41","revisionof":"","revisedto":"S2-2106538","release":"Rel-17","crspec":23.501,"crspecversion":"17.1.1","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":3170.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106223.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106224","title":"AUSF\/UDM discovery based SUCI information","source":"China Mobile","contact":"Yi Jiang","contact-id":40863,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Home Network Public Key ID is allowed to be used for AUSF\/UDM discovery.","secretary_remarks":"Revised to S2-2106539.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10560,"status":"revised","reservation_date":"2021-08-10 11:54:57","uploaded":"2021-08-10 16:21:41","revisionof":"","revisedto":"S2-2106539","release":"Rel-17","crspec":23.502,"crspecversion":"17.1.0","workitem":[{"winame":"TEI17"},{"winame":" 5GS_Ph1"}],"crnumber":3069.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106224.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106527","title":"[DRAFT] Rely LS to Liaison Statement on 5G & Wi-Fi RAN Convergence","source":"Huawei","contact":"Thomas Belling","contact-id":68266,"tdoctype":"LS out","for":"Approval","abstract":"To: TSG SA","secretary_remarks":"Created at CC#1. Response to S2-2105365. Revised to S2-2106533.","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10200,"status":"revised","reservation_date":"2021-08-17 05:54:29","uploaded":"2021-09-01 14:31:23","revisionof":"","revisedto":"S2-2106533","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106527.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106533","title":"Reply LS to Liaison Statement on 5G & Wi-Fi RAN Convergence","source":"SA WG2","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"To: WBA. CC: TSG SA","secretary_remarks":"Revision of S2-2106527r02. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"approved","reservation_date":"2021-08-23 07:58:34","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2106527","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2105365","lsto":"WBA","Cc":"TSG SA","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106533.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106534","title":"Reply LS to LS to 3GPP SA2 on ARP PL","source":"SA WG2","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"To: GSMA. CC: CT WG3. Attachments: 23.401 CR3648","secretary_remarks":"Revision of S2-2105659r00. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"approved","reservation_date":"2021-08-23 07:58:34","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2105659","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2105233","lsto":"GSMA","Cc":"CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106534.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106535","title":"ARP PL applied by MME per local configruation","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add in NOTE 9 of clause 4.7.2.1 that MME can downgrade ARP PL and PVI and the consequence of such downgrade.","secretary_remarks":"Revision of S2-2105658r02. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10270,"status":"agreed","reservation_date":"2021-08-23 07:58:34","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2105658","revisedto":"","release":"Rel-17","crspec":23.401,"crspecversion":"17.1.0","workitem":[{"winame":"TEI17"}],"crnumber":3648.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-210936","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106535.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106536","title":"LS on Reliable Data Service Serialization Indications in Rel-16","source":"SA WG2","contact":"Michael Starsinic","contact-id":72107,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1. CC: TSG SA, TSG CT, CT WG3. Attachments: TS 23.682 CR 0480, TS 23.501 CR 3008, TS 23.502 CR 2897","secretary_remarks":"Revision of S2-2105386r01. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"approved","reservation_date":"2021-08-23 07:58:35","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2105386","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"RDSSI"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2105225","lsto":"CT WG1","Cc":"TSG SA, TSG CT, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106536.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106537","title":"Reply LS on the mapping between service types and slice at application","source":"SA WG2","contact":"Stefano Faccin","contact-id":57487,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG3. CC: SA WG4, CT WG1, SA WG5, RAN WG2","secretary_remarks":"Revision of S2-2105862r03. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10480,"status":"approved","reservation_date":"2021-08-23 07:58:35","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2105862","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2105281","lsto":"RAN WG3","Cc":"SA WG4, CT WG1, SA WG5, RAN WG2","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106537.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106538","title":"AUSF\/UDM discovery based SUCI information","source":"China Mobile, Deutsche Telekom, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Yi Jiang","contact-id":40863,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Public Key ID is allowed to be used for AUSF\/UDM discovery.","secretary_remarks":"Revision of S2-2106223r05. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10550,"status":"agreed","reservation_date":"2021-08-23 07:58:35","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2106223","revisedto":"","release":"Rel-17","crspec":23.501,"crspecversion":"17.1.1","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3170.0,"crrevision":1.0,"crcategory":"B","tsg_crp":"SP-210915","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106538.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106539","title":"AUSF\/UDM discovery based SUCI information","source":"China Mobile, Deutsche Telekom, Nokia, Nokia Shanghai Bell, Ericsson","contact":"Yi Jiang","contact-id":40863,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Home Network Public Key ID is allowed to be used for AUSF\/UDM discovery.","secretary_remarks":"Revision of S2-2106224r04. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10570,"status":"agreed","reservation_date":"2021-08-23 07:58:36","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2106224","revisedto":"","release":"Rel-17","crspec":23.502,"crspecversion":"17.1.0","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3069.0,"crrevision":1.0,"crcategory":"B","tsg_crp":"SP-210915","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106539.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106683","title":"LS on 5G capabilities exposure for factories of the future","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"To: TSG SA. CC: SA WG1, SA WG3, SA WG5, SA WG6, CT WG3","secretary_remarks":"Revision of S2-2105854r11 + changes, merging S2-2106047. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10380,"status":"approved","reservation_date":"2021-08-23 07:47:03","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2105854","revisedto":"","release":"Rel-18","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2105229","lsto":"TSG SA","Cc":"SA WG1, SA WG3, SA WG5, SA WG6, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106683.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106684","title":"LS Reply on Support of Asynchronous Type Communication in N1N2MessageTransfer","source":"SA WG2","contact":"Haiyang Sun","contact-id":79579,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG4, CT WG1. Attachments: TS 23.501 CR 3062","secretary_remarks":"Revision of S2-2105696r10, merging S2-2106177. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10420,"status":"approved","reservation_date":"2021-08-23 07:47:03","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2105696","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"SBIProtoc17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2105239","lsto":"CT WG4, CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106684.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106685","title":"Explicit indication for ATC","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Add explicit indication to the AMF to show whether the AMF can activate the ATC mechanism. Since the explicit ATC indication is added only in Rel-17 and the AMF support for ATC was implementation specific in earlier releases, the feature is optional for the AMF for backwards compatibility.","secretary_remarks":"Revision of S2-2105695r07. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10450,"status":"agreed","reservation_date":"2021-08-23 07:47:03","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2105695","revisedto":"","release":"Rel-17","crspec":23.501,"crspecversion":"17.1.1","workitem":[{"winame":"5GS_Ph1"},{"winame":" TEI17"}],"crnumber":3062.0,"crrevision":1.0,"crcategory":"C","tsg_crp":"SP-210936","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106685.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2106686","title":"LS Response on Clarifications of Network slice selection during AMF Reallocation","source":"SA WG2","contact":"Fenqin Zhu","contact-id":26772,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3","secretary_remarks":"Revision of S2-2106113r15 + changes, merging S2-2105344 and S2-2105482. Approved","agenda_item_sort_order":6,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10530,"status":"approved","reservation_date":"2021-08-23 07:47:04","uploaded":"2021-09-01 14:31:23","revisionof":"S2-2106113","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_AMFREAL_SEC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2105289","lsto":"SA WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_146E_Electronic_2021-08\/Docs\/S2-2106686.zip","group":"S2","meeting":"S2-146-e","year":2021,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]