[{"name":"S2-2008329","title":"LS from SA WG3LI: LS on Location information for SMS over IMS","source":"SA WG3LI","contact":"Maurizio Iovieno","contact-id":23687,"tdoctype":"LS in","for":"Action","abstract":"LI requirements include the need for the operator to provide target's location information as part of intercepted signaling, when required by the LI warrant. With reference to SMS over IMS, SA WG3-LI would expect that, whenever an IMS user sends or receives a SMS over IMS, the CSCFs include the Network Provided Location Information (NPLI) in the PANI header (or equivalent functionalities), in addition to any possible user provided location information, for possible use by the LI functions in the operator network in case the user is a LI target. Location information is required to be the location when the SMS is sent\/received by the user. The requirement is applicable to both non-roaming and roaming scenarios. In order to ensure LI undetectability, this needs to be done for all users, no matter whether they are LI target. Looking at IMS Core Network specifications, it was however unclear to SA WG3-LI whether the needed capabilities, i.e. the inclusion of a NPLI in the PANI header when SMS over IMS are handled, are currently supported. Action: SA WG3-LI asks SA WG2 to provide feedback on the availability of location information at CSCFs when any IMS user sends or receives SMS over IMS and, if seen needed, to update their specifications in order to ensure that LI requirements on location information for LI of SMS over IMS are fulfilled.","secretary_remarks":"Revision of postponed S2-2006782 from S2#141E. Responses drafted in S2-2008391 and S2-2009016. FInal response in S2-2009332","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10280,"status":"replied to","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006782","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG1, CT WG3, SA WG3","lsoriginalls":"S3i200161","lsreply":"S2-2009332","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008329.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008331","title":"LS from CT WG1: LS on mandate to provide any PLMN entry in the non-3GPP access node selection information","source":"CT WG1","contact":"John-Luc Bakker","contact-id":37326,"tdoctype":"LS in","for":"Action","abstract":"Some companies in CT WG1 have discussed the requirement that mandates the inclusion of the 'any PLMN' entry in the non-3GPP access node selection information (TS 23.501, clause 6.3.6). The equivalent of the 'any PLMN' entry in the ePDG selection information is optional (see TS 23.402). According to the N3IWF selection procedure described in clause 6.3.6 of TS 23.501, a mandatory inclusion of the 'any PLMN' entry in the N3AN selection information makes impossible some roaming scenarios involving HPLMN's non-3GPP access (e.g. the scenarios presented in Figures 4.2.8.2.2-2 and 4.2.8.2.3-3 of TS 23.501). An example of conditions where a roaming scenario involving HPLMN's non-3GPP access would be impossible: - N3AN node selection for IMS service is performed; - the UE is not located in its home country; - the UE registered to 5GC of a VPLMN X over 3GPP access; and - the N3AN node configuration information is provisioned; - an N3AN node selection information entry for the VPLMN X is absent in the N3AN node selection information of the N3AN node configuration information; - the DNS server function is able to resolve N3IWF FQDN or ePDG FQDN constructed according to the 'Any_PLMN' N3AN node selection information entry of the N3AN node configuration information. For such scenarios, unless selection of the N3IWF or ePDG in the visited country is required, using the HPLMN's non-3GPP access node should be enabled and controlled by the HPLMN's policy. The HPLMN's policy could be expressed by absence of the 'Any_PLMN' N3AN node selection information entry of the N3AN node configuration information. Action: CT WG1 asks SA WG2 group to clarify the purpose of the mandatory presence of the 'any PLMN' entry in the non-3GPP access node selection information.","secretary_remarks":"Revision of postponed S2-2006787 from S2#141E. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"noted","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006787","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-204034","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008331.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008332","title":"LS from CT WG1: LS on maximum number of UP resources supported by NB-N1 mode UEs","source":"CT WG1","contact":"Mahmoud Watfa","contact-id":85785,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 would like to inform SA WG2 about the following agreements (see attachments) for UEs in NB-N1 mode: 1) Since the same lower layers are used as in NB-S1 mode, the UE indicates to the AMF whether it supports multiple UP resources (i.e. at most 2) in the 5GMM capability IE. 2) The UE and AMF enforce a maximum number of UP resources (i.e. 1 or 2) that can be active at any time based on the UE's capability as per the above. Action: CT WG1 respectfully asks SA WG2 to take the above information into account and update their specifications as needed.","secretary_remarks":"Revision of postponed S2-2006789 from S2#141E. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"noted","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006789","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-204083","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008332.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008333","title":"LS from RAN WG2: LS on AS RAI and optimization of release","source":"RAN WG2","contact":"Tuomas Tirronen","contact-id":73195,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 discussed whether UE power consumption can be optimized further when AS RAI is indicated if eNB can release the UE immediately, i.e., without waiting for an acknowledgement from the MME\/AMF if the UE indicates AS RAI implying that no further data are expected from the CN. RAN WG2 thinks the optimization can be beneficial to increase UE power savings in some cases, however some companies doubt power consumption gain, if any, would be significant. Some companies have expressed concerns with eNB immediately releasing UE could in some cases lead to state mismatch between UE and CN with increased power consumption and signalling load. Action: RAN WG2 kindly asks SA WG2 to take the above observations into account.","secretary_remarks":"Revision of postponed S2-2006791 from S2#141E. Response drafted in S2-2008962. CC#3: Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10350,"status":"noted","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006791","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"R2-2005839","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008333.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008334","title":"LS from SA WG3LI: Additional Clarifications on LI requirements applicable to SNPNs","source":"SA WG3LI","contact":"Alexander Markman","contact-id":35093,"tdoctype":"LS in","for":"Action","abstract":"SA WG3-LI would like to thank SA WG2 for their response LS and an opportunity to further clarify the LI requirements for SNPNs. {...} Action: SA WG3-LI kindly requests SA WG2 to take the above clarifications and answers into consideration when designing the solution for SNPN N3IWF selection. SA WG3-LI would also like SA WG2 to answer the question in the last paragraph above.","secretary_remarks":"Revision of postponed S2-2006793 from S2#141E. Response drafted in S2-2008477. FInal response in S2-2009335","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10480,"status":"replied to","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006793","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S3i200409","lsreply":"S2-2009335","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008334.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008335","title":"LS from CT WG3: LS on Support of Dual Connectivity end to end Redundant User Plane Paths","source":"CT WG3","contact":"Fuencisla Garcia Azorero","contact-id":43873,"tdoctype":"LS in","for":"Action","abstract":"TS 23.501 clause 5.33.2.1 specifies that the SMF determines whether the PDU session is to be handled redundantly based on 'the policies provided by PCF for the PDU Session, combination of the S-NSSAI, DNN, user subscription and local policy configuration' CT WG3 group has discussed the requirement above and has different understandings about which policies the PCF provides to the SMF to indicate the redundant PDU session policy. CT WG3 thanks SA WG2 to study the following questions: Q1: Is the policy provided by the PCF an explicit indication of whether a redundant PDU Session is allowed or forbidden? Or is it an implicit indication based on the combination of other policies delivered for the PDU session and\/or the PCC rules? Q2: If it is an implicit indication, which combination of PDU session and\/or PCC rules policies indicate to the SMF that the redundant PDU session policy is to be applied? Q3: Is it a correct understanding that the redundant PDU session policy cannot change during the PDU session lifetime?. Action: CT WG3 kindly asks SA WG2 to answer the questions above and update the corresponding TSs, if necessary.","secretary_remarks":"Revision of postponed S2-2006796 from S2#141E. Response drafted in S2-2008422. FInal response in S2-2009342","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10880,"status":"replied to","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006796","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C3-203678","lsreply":"S2-2009342","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008335.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008336","title":"LS from RAN WG2: Reply LS on early UE capability retrieval for eMTC","source":"RAN WG2","contact":"Veera Prasada Kadiri","contact-id":72325,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 thanks SA WG2 for their reply LS confirming that SA WG2 has not identified any technical issues to support early UE capability retrieval for eMTC UEs for EPS from system architecture perspective. RAN WG2 discussed the concerns raised by SA WG2 for 5GS and would like to provide the responses as follows: SA WG2 LS indicated: - Concerns to enable use of truncated 5G-S-TMSI for all UEs accessing ng-eNBs connected to 5GC as this would reduce the available AMF Set ID number space, AMF Pointer number space and TMSI number space (due to truncation) for all UEs. RAN WG2 response: RAN WG2 has a potential solution to identify in Msg3 to include InitialUE-Identity-5GC which enables ng-eNB to differentiate between BL UEs and non-BL UEs in CE mode. Such solution would allow AMF to allocate 40-bit truncated 5G-S-TMSI only for BL UEs. SA WG2 LS indicated: - Concerns about truncated 5G-S-TMSIs being used, with no additional checks, to retrieve the UE capabilities for all UEs and the high levels of coordination required between operators in RAN sharing cases for eMTC UEs using CP optimisations. - Concerns about introducing to EPS capabilities that are not supported by 5GS, or no clear path exists for its addition to 5GS. RAN WG2 thinks the above two concerns are out of RAN WG2 scope and up to SA WG2 to address. Action: RAN WG2 respectfully asks SA WG2 to take above response into consideration.","secretary_remarks":"Revision of postponed S2-2006799 from S2#141E. Response drafted in S2-2008571. FInal response in S2-2009345","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10950,"status":"replied to","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006799","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"RAN WG3, CT WG1","lsoriginalls":"R2-2008238","lsreply":"S2-2009345","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008336.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008337","title":"LS from CT WG4: LS on AUSF\/UDM discovery based on SUCI information","source":"CT WG4","contact":"Yue Song","contact-id":57977,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 has analyzed the issue of insufficient length of Routing Indicator within SUCI, see attached discussion paper in C4-204078 for details. The current 4 digits of the Routing Indicator enables only 10 K ranges of subscriptions, which may not provide enough granularity and flexibility for moving subscriptions across UDRs not controlled by the same AUSF\/UDM, for operators with a large number of subscriptions (e.g. 100 K users per range for a PLMN with 1 billion subscriptions). CT WG4 agreed that the above limitation should be addressed. CT WG4 has also discussed the solution proposed in C4-204339 (attached) for solving this problem, enabling to use the Home Public Key ID as an additional parameter (that allows to encode e.g. a 5th digit, in addition to the key ID on 4 bits) for the discovery of the AUSF\/UDM. CT WG4 would be fine in principle to specify this solution in Rel-17, provided corresponding stage-2 requirements are agreed first. Action: CT WG4 kindly asks SA WG2 to consider specifying stage 2 enhancements for selection of AUSF\/UDM based on SUCI in Rel-17 to address the reported issue.","secretary_remarks":"Revision of postponed S2-2006806 from S2#141E. Responses drafted in S2-2008616 and S2-2008547. FInal response in S2-2009207","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10530,"status":"replied to","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006806","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG CT, TSG SA, SA WG3","lsoriginalls":"C4-204337","lsreply":"S2-2009207","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008337.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008339","title":"LS from SA WG3: Reply LS on Reply PAP\/CHAP and other point-to-point protocols usage in 5GS","source":"SA WG3","contact":"Alf Zugenmaier","contact-id":52494,"tdoctype":"LS in","for":"Action","abstract":"SA WG3 would like to thank SA WG2 for their LS Reply PAP\/CHAP and other point-to-point protocols usage in 5GS (S3-201509\/S2-2004481). SA WG3 would like to make the following observations: - EAP based secondary authentication in 5GS is a replacement for PAP\/CHAP in EPC. Therefore SA WG3 recommends use of secondary authentication instead of PAP\/CHAP using ePCO unless there are legacy applications requiring it. - PAP is outdated and should not be used any more (RFC 1334 (PAP) has been obsoleted by RFC 1994). Therefore, the warning should be in any 5G spec referring to PAP as well. - CHAP also comes with disadvantages, such as being amenable to brute force attacks if the password is guessable. - It is up to the external network operator to perform the risk assessment if PAP\/CHAP is used for authentication. Action: SA WG3 kindly asks SA WG2, CT WG1 and CT WG3 to take the above into consideration.","secretary_remarks":"Revision of postponed S2-2006821 from S2#141E. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"postponed","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2006821","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG1, CT WG3","Cc":"CT WG4","lsoriginalls":"S3-202190","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008339.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008341","title":"LS from BBF: Your liaison S2-2005917","source":"BBF","contact":"Lincoln Lavoie","contact-id":39231,"tdoctype":"LS in","for":"Information","abstract":"Dear colleagues, We have considered the questions in your recent liaison, S2-2005917, and would offer the following reply: - Q1: Does BBF consider that the support for such 5G-RG(s) needs to be specified or does BBF plan to mandate that a 5G RG that supports MA PDU Session shall support MA PDU Session both over NR\/5GC and LTE\/EPC , if LTE\/EPC is supported. A: We would require support for both NR\/5GC and LTE\/EPC - Q2: If the 5G-RG does not support MA PDU session simultaneously over LTE\/EPC and wireline access, when 3GPP access of a MA PDU Session is handed over from NR to LTE\/EPC should the wireline or the wireless access of the MA PDU Session be released? A: We would prefer that the wireless access of the MA PDU session be released. - Q3: Does BBF have any preference on whether the release (see Q2) of the access should be initiated by the 5G RG or by the network (5GC)? A: We would prefer network initiated release. You have also advised us in liaison that with respect to DHCP, 3GPP does not go beyond referring to the relevant IETF RFCs. We do have three concerns at the present time: 1. That a lease associated with a PDU session would be required to have a common lifetime and fate share with the PDU session. This has implications with respect to coordination between an SMF and any external server. 2. That a DHCP server will need to accept and process DHCPv6 relay forward headers inserted by the access node as per RFC 6221 and by an AGF as a DHCPv6 relay. 3. That a DHCP server will accept an DHCPv4 unicast message with a non-zero GIADDR. A further query would be if there is a situation where for an IPv6 or IPv4\/v6 session that an SMF does not originate a router advertisement. Our read of section 5.8.2.2.3 of TS23.501 suggests some ambiguity. We also note that as specified in clause 5.16 of TS 29.244 support for framed routes by a UPF would be appear to be optional as support is specifically indicated in the UPF functional features IE . For our purposes we would require UPF support of framed routes to be mandatory and would indicate that in our next revision of our specifications. We look forward to continuing our fruitful relationship. Thanks, Lincoln Lavoie Broadband Forum Technical Committee Chair","secretary_remarks":"Revision of postponed S2-2007783 from S2#141E. Response drafted in S2-2008507. FInal response in S2-2009340","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10760,"status":"replied to","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2007783","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CableLabs","lsoriginalls":"LIAISE-423","lsreply":"S2-2009340","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008341.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008342","title":"LS from GSMA 5GJA: LS response to TCCA on Public Safety","source":"GSMA 5GJA","contact":"Mari Melander","contact-id":37233,"tdoctype":"LS in","for":"Information","abstract":"Overall Description: GSMA 5GJA thanks TCCA for their LS response 'LS on Generic Slice Template with Public Safety Feedback' and appreciate the detail review of GST Baseline v0.16. GSMA 5GJA would like to inform TCCA about the latest GSMA PRD NG.116 'Generic Network Slice Template' v3.0 that is available on this link: https:\/\/www.gsma.com\/newsroom\/wp-content\/uploads\/\/NG.116-v3.0.pdf. Response from 5GJA: ACTION 01: TCCA asks GSMA kindly to take the above information as well as the feedback provided with the revised document together with the cross-reference table into consideration. [GSMA 5GJA]: GSMA has published PRD NG.116 v3.0 and the link can be found in the Overall Description section. GSMA 5GJA has reviewed all comments provided in the document 'GST Baseline v0.16 v200310 cPublicSafety.docx' and is working on adding new attributes based on the requirement from TCCA. PRD NG.116 contains a list of NESTs that contains the minimum set of attributes needed to characterise a specific service\/slice. GSMA 5GJA would like to add a NEST for public safety once all values will be provided and agreed between GSMA 5GJA and TCCA. ACTION 02: TCCA asks GSMA kindly to respond to the clarification's requests \/ questions provided in the revised document. [GSMA 5GJA]: Some of the attributes were removed or modified and are not part of published NG.116. ACTION 03: TCCA asks GSMA kindly to inform TCCA about the next process steps and how TCCA could be part of it. [GSMA 5GJA]: GSMA 5GJA has reviewed comments and suggestions from TCCA and is working on implementing changes into the version of the document. We have prepared a draft version of NEST for public safety with some of the values provided by TCCA. The next step would be to review the draft NEST and provide missing information.","secretary_remarks":"Revision of postponed S2-2007794 from S2#141E. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10040,"status":"noted","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:54","revisionof":"S2-2007794","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TCCA","Cc":"TSG SA, SA WG1, SA WG2, SA WG3, SA WG5, SA WG6, RAN WG3","lsoriginalls":"5GJA14_121r1","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008342.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008344","title":"LS from ITU-R WP 5D: dering the successful accomplishments by ITU for the evolution of IMT-2000, IMT_x001E_Advanced and IMT-2020, similar actions are proposed for the evolution of IMT towards 2030 and beyond. The approach taken for IMT_x001E_Advanced evolution toward","source":"ITU-R WP 5D","contact":"Uwe Loewenstein","contact-id":11941,"tdoctype":"LS in","for":"Information","abstract":"Considering the successful accomplishments by ITU for the evolution of IMT-2000, IMT Advanced and IMT-2020, similar actions are proposed for the evolution of IMT towards 2030 and beyond. The approach taken for IMT Advanced evolution towards IMT-2020 was to start with the work on the Report ITU-R M.2320 entitled 'Future technology trends of terrestrial IMT systems' (approved in 2014) to develop the evolution for IMT-Advanced. At its 34th meeting (19-26 February 2020), ITU R Working Party (WP) 5D decided to start study on future technology trends for the future evolution of IMT. It is planned for WP 5D to complete this study at the 41st WP 5D meeting in June 2022. A preliminary draft new Report ITU-R M.[IMT.FUTURE TECHNOLOGY TRENDS] will be developed and will consider related information from various external organizations and country\/regional research programmes. The scope of the new Report ITU-R M.[IMT.FUTURE TECHNOLOGY TRENDS] focuses on the following aspects: 'This Report provides a broad view of future technical aspects of terrestrial IMT systems considering the time frame up to 2030 and beyond. It includes information on technical and operational characteristics of terrestrial IMT systems, including the evolution of IMT through advances in technology and spectrally-efficient techniques, and their deployment.' For the development of this report, WP 5D invites the views of External Organizations on future technology trends for terrestrial IMT systems, including but not limited to the motivation on driving factors such as new use cases, applications, capabilities, technology trends and enablers. These technical inputs are intended for the timeframe towards 2030 and beyond and are proposed to be significantly advanced and different from that of IMT-2020. The draft structure of new Report ITU-R M.[IMT.FUTURE TECHNOLOGY TRENDS] is in Annex 1. Working Party 5D kindly requests the External Organizations to share their information prior to the 38th meeting of WP 5D, 6-18 June 2021. The deadline for input contributions to the 38th meeting is 31 May 2021. It is noted that the 39th meeting of WP 5D is scheduled for 4-15 October 2021, and additional inputs will also be recognised during this meeting as well. WP 5D looks forward to collaborating productively with External Organizations on this matter.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10050,"status":"noted","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:53","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"EXTERNAL ORGANIZATIONS","Cc":"","lsoriginalls":"5D\/TEMP\/219(Rev.2)","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008344.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008347","title":"LS from CT WG1: LS on NSSAA at inter-PLMN mobility","source":"CT WG1","contact":"Mahmoud Watfa","contact-id":85785,"tdoctype":"LS in","for":"Action","abstract":"In the case of inter-VPLMN mobility, CT WG1 has discussed how the target VPLMN should perform NSSAA for a UE that first enters the target VPLMN. CT WG1 kindly requests guidance on the following question: \u00a7 If the target VPLMN decides to run NSSAA for an S-NSSAI whose NSSAA status is EAP-Success when a UE accesses the target VPLMN for the first time, how will the target VPLMN handle the S-NSSAI that is subject to NSSAA: will it be put in the pending NSSAI or will it be put in the allowed NSSAI included in the registration accept message sent to the UE, and how are existing PDU sessions associated with the S-NSSAI handled?. Action: SA WG2 is kindly requested to answer the question above.","secretary_remarks":"Responses drafted in S2-2008482, S2-2008556, S2-2008623 and S2-2009040. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10810,"status":"postponed","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:53","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG4, SA WG3","lsoriginalls":"C1-206508","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008347.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008348","title":"LS from CT WG1: LS on Clarification on processing of messages after NAS security establishment","source":"CT WG1","contact":"Mikael Wass","contact-id":42217,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 thanks SA WG3 for the LS on processing of messages after NAS security establishment. On the request for clarification: 'Particularly SA WG3 would like to understand whether the messages listed above a) to g) can still be processed by UE, after the secure exchange of NAS messages has been established e.g. using a NAS SMC procedure.' CT WG1 would like to provide the following answer: The messages listed in bullets a) to g) in 4.4.4.2 of 3GPP TS 24.501 are only accepted without successful integrity check by the UE before 'secure exchange of 5GS NAS messages' has been established for the NAS signalling connection. After establishment of 'secure exchange of 5GS NAS messages' the UE shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. Consequently no, the messages listed in bullets a) to g) cannot be processed by the UE without successful integrity check, after the secure exchange of NAS messages has been established.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"noted","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:53","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"SA WG2","lsoriginalls":"C1-206582","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008348.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008349","title":"LS from CT WG1: LS on MINT requirements","source":"CT WG1","contact":"Lena Chaponniere","contact-id":38080,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 has agreed a Rel-17 Study Item on MINT and has started discussing the related requirements. As a result of this discussion, CT WG1 would like to ask SA WG1 the following questions: Question 1: Which level of services are the PLMNs not subject to disaster required to provide to 'Disaster Inbound Roamers'? Emergency services only, a limited set of services hosted by the PLMN not subject to disaster (e.g. internet connectivity provided using local break-out), or the same set of services that the 'Disaster Inbound Roamers' would receive in their HPLMN? Question 2: If the answer to Question 1 is: a limited set of services hosted by the PLMN not subject to disaster, can it be assumed that the NFs of the PLMM subject to disaster required to support those services (the UDM and the AUSF) are still operational? Question 3: If the answer to Question 1 is: the same set of services that the 'Disaster Inbound Roamers' would receive in their HPLMN, can it be assumed that the NFs of the PLMM subject to disaster required to support those services (the UDM, the AUSF, the SMF and UPF for any DNN requiring home-routed PDU session, and the IMS) are still operational?. Action: CT WG1 asks SA WG1 group to provide answers to Questions 1, 2 and 3 above.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"noted","reservation_date":"2020-11-03 09:08:59","uploaded":"2020-11-03 09:12:53","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"SA WG2","lsoriginalls":"C1-206649","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008349.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008350","title":"LS from CT WG1: LS on SNPN access mode when UE accesses SNPN services via a PLMN","source":"CT WG1","contact":"Ivo Sedlacek","contact-id":78448,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 identified that the 'SNPN access mode' term definition in TS 23.501 states that the UE only selects an SNPN over Uu: ---------------------------- SNPN access mode: A UE operating in SNPN access mode only selects stand-alone Non-Public Networks over Uu. ---------------------------- However, TS 24.501 uses the 'SNPN access mode' term also in situation when the UE accesses SNPN services via a PLMN using 3GPP access. Given that Rel-16 is already frozen, CT WG1 has preference for extension of the 'SNPN access mode' term definition in TS 23.501 to address the situation above. Action: CT WG1 would like to ask SA WG2 to take the above into account and extend the 'SNPN access mode' term definition, if deemed appropriate.","secretary_remarks":"Responses drafted in S2-2008475, S2-2008769, S2-2008911 and S2-2009041. FInal response in S2-2009206","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10380,"status":"replied to","reservation_date":"2020-11-03 09:09:00","uploaded":"2020-11-03 09:12:53","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-206736","lsreply":"S2-2009206","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008350.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008356","title":"LS from SA WG3: Reply LS for IP address to GPSI translation","source":"SA WG3","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 would like to thank SA WG6 for their LS S6-200947 on IP address to GPSI translation. Since user consent is not only limited to MEC study, SA WG3 has started a new study captured in TR 33.867 on user consent for 3GPP services which aims to address user consent issues uniformly. SA WG3 will provide feedback once SA WG3 has came up with agreed observations.","secretary_remarks":"Responses drafted in S2-2008989 and S2-2009004. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10620,"status":"noted","reservation_date":"2020-11-03 09:09:00","uploaded":"2020-11-03 09:12:53","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG2","lsoriginalls":"S3-202753","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008356.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008358","title":"LS from SA WG6: Reply LS on IP address to GPSI translation","source":"SA WG6","contact":"Nishant Gupta","contact-id":62473,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 thanks SA WG2 on the reply LS, and as requested, would like to provide further clarification on the use cases and related requirements. In EDGEAPP architecture, multiple APIs exposed by the Edge Enabler Server (EES) to the Edge Application Server (EAS) require the EAS to identify the UE which is the subject of the API request e.g. UE location API (clause 8.6.2 of TS 23.558). In some use cases, it may be reasonable to expect that the Application Client (AC) within the UE can provide the GPSI (e.g. MSISDN) to the EAS as part of the application layer protocol, however, typically this may not be the case (i.e. the AC is not aware of its GPSI, neither MSISDN nor External Identifier). Yet in some other use cases, the user due to privacy concerns may not be comfortable to share his\/her MSISDN with certain applications. This means, there are many scenarios where the application is unaware of the UE identity and yet to serve the user\/UE, the application server (i.e. EAS) would need to query for certain information about the UE (e.g. location). Additionally, the AC within the UE may not be a trustworthy source for identifiers, thus a network provided identifier is preferred. Under such circumstances, the EAS that is not aware of UE identifier(s) can only provide UE's IP address (over the API) as the identifier of the UE. Using the EAS provided UE's IP address to identify the UE at the EES can result in issues that are explained on slide #6, and using EAS provided IP address by the EES for CN capability exposure APIs can result in issues that are explained on slide #7 of the attached presentation. Due to lack of reliable identification of the UE and the issues with using EAS provided IP address for CN capability exposure APIs, a better mechanism is desired. SA WG6 therefore requests SA WG2 and SA WG3 for a reliable and secure core network capability which enables exposure of network services to AFs (e.g. EAS\/EES) using a static identifier when only an IP address of the UE is known to them. Action: SA WG6 would like SA WG2 and SA WG3 to kindly consider the requirement to enable exposure of network services to AF (e.g. EAS\/EES) using a static identifier when only an IP address of the UE is known to them.","secretary_remarks":"Responses drafted in S2-2008989 and S2-2008807. FInal response in S2-2009339","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10630,"status":"replied to","reservation_date":"2020-11-03 09:09:00","uploaded":"2020-11-03 09:12:53","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG3","Cc":"","lsoriginalls":"S6-202008","lsreply":"S2-2009339","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008358.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008391","title":"[DRAFT] Reply LS on Location Information for SMS over IMS","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"This LS proposes a response to SA WG3-LI to on providing location for SMS over IP","secretary_remarks":"Response to S2-2008329. r00 agreed. Revised to S2-2009332.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10290,"status":"revised","reservation_date":"2020-11-06 14:58:53","uploaded":"2020-11-09 20:26:18","revisionof":"","revisedto":"S2-2009332","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3-LI","Cc":"CT WG1, CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008391.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008392","title":"Providing User Location during IP Messaging","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding a new clause to specify the need by the P-CSCF to retrieve nework location informatio depending on the access being used and to distribute the information to other IMS entities","secretary_remarks":"r06 agreed. Revised to S2-2009333.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"revised","reservation_date":"2020-11-06 14:58:53","uploaded":"2020-11-09 20:26:18","revisionof":"","revisedto":"S2-2009333","release":"Rel-16","crspec":"23.228","crspecversion":"16.5.0","workitem":[{"winame":"LI16"},{"winame":"TEI16"}],"crnumber":1237.0,"crrevision":"","crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008392.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008422","title":"[DRAFT] LS on Support of Dual Connectivity end to end Redundant User Plane Paths","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Draft LS reply to CT WG3 LS on Dual connectivity","secretary_remarks":"Response to S2-2008335. r01 agreed. Revised to S2-2009342.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10890,"status":"revised","reservation_date":"2020-11-06 19:18:58","uploaded":"2020-11-09 20:26:18","revisionof":"","revisedto":"S2-2009342","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5G_URLLC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008422.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008423","title":"Indication of redundancy transmission","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify that the PCF indicates if the PDU session requires redundant transmission to the SMF, that is used by the SMF to request redundant transmission at PDU session set up to RAN when the PCF is used for the PDU session. Clarify that if the PCF is not deployed, then the SMF applies local policies, for example can map a 5QI into redundancy requirements.","secretary_remarks":"Revision of (noted) S2-2005121 from S2#141E. r02 agreed. Revised to S2-2009343.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10910,"status":"revised","reservation_date":"2020-11-06 19:18:58","uploaded":"2020-11-09 20:26:18","revisionof":"S2-2005121","revisedto":"S2-2009343","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"5G_URLLC"}],"crnumber":2408.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008423.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008424","title":"Policy control for redundant transmission for URLLC","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Extend the PDU session policy information to include indication that the redundant transmission is allowed for the PDU session.","secretary_remarks":"Revision of (noted) S2-2005123 from S2#141E. r02 agreed. Revised to S2-2009344.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10930,"status":"revised","reservation_date":"2020-11-06 19:19:00","uploaded":"2020-11-09 20:26:18","revisionof":"S2-2005123","revisedto":"S2-2009344","release":"Rel-16","crspec":"23.503","crspecversion":"16.6.0","workitem":[{"winame":"5G_URLLC"}],"crnumber":483.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008424.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008474","title":"SNPN access mode correction","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: To avoid diverging the definition of SNPN access mode, the definition is extended with the case when UE selects an SNPN over NWu.","secretary_remarks":"Confirm CR Number - CR states 2154! Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10390,"status":"noted","reservation_date":"2020-11-06 20:03:29","uploaded":"2020-11-09 20:27:48","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":2514.0,"crrevision":"","crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008474.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008475","title":"[DRAFT] Reply LS on SNPN access mode when UE accesses SNPN services via a PLMN","source":"Ericsson","contact":"Peter Hedman","contact-id":27550,"tdoctype":"LS out","for":"Approval","abstract":"Reply to the CT WG1 LS on SNPN access mode when UE accesses SNPN services via a PLMN.","secretary_remarks":"Response to S2-2008350. CC#3: r01 was considered. This was agreed and revised to S2-2009206","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10430,"status":"revised","reservation_date":"2020-11-06 20:03:32","uploaded":"2020-11-09 20:27:48","revisionof":"","revisedto":"S2-2009206","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"Vertical_LAN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008475.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008476","title":"N3IWF selection procedure when accessing SNPN via PLMN","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding country information in the SNPN subscription in order to determine the relation between the UE's geographic location and the UE's subscription location. Clarifying the UE configuration when performing N3IWF selection for SNPN case. If the UE's geographic location is different from UE's subscription location, the UE performs the DNS-based regulatory requirement check as proposed in 6.3.6.2a. The following domain name described in TS 23.003 Annex E is to be extended to support DNS-based regulatory requirement check for SNPN case. .mcc.visited-country.pub.3gppnetwork.org Clause 6.3.6.2a proposes to include the specific information of the desired SNPN to construct the DNS query. The benefit of such approach is to limit the DNS query for a specific SNPN and restrict the DNS answer only relevant to a specific SNPN. The DNS query format for example is: .n3iwf.snpn-5gc.mcc.visited-country.pub.3gppnetwork.org The authority\/organization in the country that handles Visited Country Domain (mcc.visited-country.pub.3gppnetwork.org) for PLMNs will be responsible for managing entries for SNPNs, since both are subdomain of the Visited Country Domain and used for the same purpose, i.e. regulatory requirement check. The subdomain name of Visited Country FQDN for SNPN (n3iwf.snpn-5gc.mcc.visited-country.pub.3gppnetwork.org) shall be proposed according toTS 23.003 Annex E and applied from GSMA. In the query format proposed in clause 6.3.6.2a, any labels to the left of n3iwf.snpn-5gc does not require application from GSMA, according to TS 23.003 Annex E Note 4.","secretary_remarks":"Merged into S2-2009334","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10510,"status":"merged","reservation_date":"2020-11-06 20:03:32","uploaded":"2020-11-09 20:27:48","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":2515.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008476.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008477","title":"[DRAFT] Reply LS on Additional Clarifications on LI requirements applicable to SNPNs","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Replying to SA WG3-LI and informs CT WG1 and CT WG4 about the agreed SA WG2 CR","secretary_remarks":"Response to S2-2008334. Merged into S2-2009335","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10520,"status":"merged","reservation_date":"2020-11-06 20:03:33","uploaded":"2020-11-09 20:27:48","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"LI16"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3-LI, CT WG1, CT WG4","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008477.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008481","title":"Re-authentication of NSSAA","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: It is clarified that re-authentication may also map to an S-NSSAI in the Requested NSSAI. It is clarified that a PDU Session is released if NSSAA re-authentication fails.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10820,"status":"postponed","reservation_date":"2020-11-06 20:06:49","uploaded":"2020-11-09 20:27:48","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"eNS"}],"crnumber":2516.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008481.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008482","title":"[DRAFT] Reply LS on NSSAA at inter-PLMN mobility","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to CT WG1 on NSSAA at inter-PLMN mobility","secretary_remarks":"Response to S2-2008347. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10840,"status":"postponed","reservation_date":"2020-11-06 20:06:51","uploaded":"2020-11-09 22:06:06","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"eNS"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"CT WG4, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008482.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008491","title":"Discussion on IP address Translation .","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"discussion","for":"Agreement","abstract":"This contribution proposes a solution to support IP address translation to GPSI as requested by SA WG6 in S2-2008358\/S6-202008.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10640,"status":"noted","reservation_date":"2020-11-06 20:14:23","uploaded":"2020-11-09 20:27:48","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"},{"winame":"EDGEAPP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008491.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008492","title":"IP Address Translation","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"draftCR","for":"Agreement","abstract":"This contribution proposes a solution to support IP address translation to GPSI as requested by SA WG6 in S2-2008358\/S6-202008.","secretary_remarks":"Merged into S2-2009338","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10660,"status":"merged","reservation_date":"2020-11-06 20:14:23","uploaded":"2020-11-09 20:27:48","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"TEI17"},{"winame":"EDGEAPP"}],"crnumber":"","crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008492.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008494","title":"Reply LS on TX profile for NR PC5","source":"RAN WG2","contact":"Xiao Xiao","contact-id":62927,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 would like to thank SA WG2 for the LS on Tx Profile for NR PC5 (R2-2008757\/S2-2006191). RAN WG2 discussed the need to define the TX profile for NR PC5 in Rel-16 and agreed that it is not needed in this release. Action: RAN WG2 respectfully asks SA WG2 to take above information into consideration.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"noted","reservation_date":"2020-11-07 13:35:37","uploaded":"2020-11-12 10:16:20","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"R2-2010928","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008494.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008496","title":"LS on Support of L2TP on SGi\/N6 with Control and User Plane Separation","source":"CT WG4","contact":"yong yang","contact-id":59744,"tdoctype":"LS in","for":"Action","abstract":"CT WG4 has discussed the contribution C4-205509 which proposes a key issue for WI BEPoP (BEst Practice of PFCP), to study the support of L2TP tunnelling on SGi\/N6 with Control and User Plane Separation. L2TP is a legacy feature used in many operators' network to support various use cases, e.g. for POS\/ATM machine to establish a secured connection with its server, for a remote user to connect the enterprise private network. With CP and UP separation, it has not been specified how the CP function can provide the UP function with the necessary parameters (e.g. L2TP server address, username, password, etc.) to set up the L2TP tunnel to the third-party server (LNS), which results in proprietary implementations. Several companies expressed their support to define the N4 extensions to support L2TP and CT WG4 agreed to study corresponding call flows and possible N4 extensions in their study item on BEPoP (BEst Practice of PFCP). CT WG4 plans to come back to SA WG2 and SA WG3 before concluding this aspect of the study to receive potential feedback from SA WG2 and SA WG3 before CT WG4 starts any stage 3 work. It may also be considered then whether some requirements and\/or call flows studied by CT WG4 may be captured in stage 2. CT WG4 kindly requests SA WG2 to confirm whether they agree on CT WG4 studying N4 extensions for L2TP support and on the above process. CT WG4 also plans to consult SA WG3 during the study to check security related matters. Action: CT WG4 kindly requests SA WG2 to confirm whether they agree on CT WG4 studying N4 extensions for L2TP support and on the proposed process.","secretary_remarks":"Response drafted in S2-2009113. Final response in S2-2009331","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"replied to","reservation_date":"2020-11-07 13:35:37","uploaded":"2020-11-12 10:16:20","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG3, CT WG3","lsoriginalls":"C4-205478","lsreply":"S2-2009331","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008496.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008498","title":"LS from IEEE 802.1: Response to LS S2-2007821 on TSN support in 3GPP Release-16","source":"IEEE 802.1","contact":"Glenn Parsons","contact-id":17960,"tdoctype":"LS in","for":"Information","abstract":"Dear colleagues, Thank you for taking into account our comments and for the detailed explanation in your recent liaison statement S2-2007821 about the way they have been addressed. Please find our answers to your questions below. S2-2007821 asked: Is it possible to identify the ingress and egress ports of a TSN bridge for a particular TSN Stream, e.g., from management information? By default, a Stream is defined by its VLAN ID and Destination MAC Address without reference to the Source MAC address. It is possible to retrieve the egress bridge port for a given Destination MAC and VLAN ID pair from the FDB. Static filtering entries are used for Streams; therefore, the FDB is populated with egress port(s) for a given Destination MAC and VLAN ID pair. It is mandatory for any manageable bridge to support static filtering entries and the corresponding management parameters. There are no mandatory means of tracking the ingress port of a Stream defined by its VLAN ID and Destination MAC Address. Optional IEEE Std 802.1CB-2017 Stream identification functions provide counters on ingress and egress ports for specific Streams. There are optional features that can limit the ports from which a Stream can be forwarded, e.g., Per-Stream Filtering and Forwarding. S2-2007821 asked: If yes, then please provide the details on the following: - Does the CNC configure these management parameters for each TSN Stream? What are the corresponding YANG parameters? The CNC configures static filtering entries for each Stream. Therefore, the corresponding management information for egress ports is available. As there are no mandatory features corresponding to ingress ports; there is no corresponding management information available for each Stream. The YANG parameters for the egress port(s) for the static filtering entries are in the static-filteringentries in ieee802-dot1qbridge:bridges:bridge:component:filtering-database specified by IEEE Std 802.1Qcp-2018. IEEE Std 802.1Qcp-2018 does not specify YANG parameters for ingress port(s), i.e., there are no YANG parameters corresponding to ieee8021QBridgeStaticUnicastReceivePort and ieee8021QBridgeStaticMulticastReceivePort. The YANG parameters for IEEE Std 802.1CB are being defined in the ongoing IEEE P802.1CBcv project; the YANG parameters for PSFP are being defined in the ongoing IEEE P802.1Qcw project and the recently completed IEEE Std 802.1Qcr-2020. S2-2007821 asked: - Is it possible to identify the ingress port of the 5GS bridge for a particular TSN stream? e.g. using o Information element ieee8021QBridgeStaticMulticastReceivePort, or o Information element ieee8021QBridgeStaticUnicastReceivePort, or o Information Element in the 802.1CB clause 9.1 Stream identity table, or o Other management information? Although the ieee8021QBridgeStaticUnicastReceivePort and ieee8021QBridgeStaticMulticastReceivePort MIB parameters can be used, they are optional and are not tied to the Port Map (specified by subclause 8.8 in IEEE Std 802.1Q-2018) that does not include ingress ports. Note that IEEE Std 802.1Q-2018 does not specify how the MIB parameters are used. If supported, these MIB parameters can be configured by a CNC. However, frame forwarding does not depend on these optional MIB parameters; therefore, it cannot be assumed that a CNC configures them even if they are supported. The Stream identity table specified in IEEE Std 802.1CB-2017 is only for stream identification but not for frame forwarding; therefore, it is not suitable for determining the egress (or ingress) ports of a Stream. S2-2007821 asked: - Is it possible to identify the egress port of the 5GS bridge for a particular TSN stream? e.g. using o Only the PSFP information provided by CNC. Or o The PSFP information together with the static filtering entry from the CNC, or o Other management information? It is not possible to identify the egress port of a Stream from PSFP management information as the latter is per bridge component, not per port. Further","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10370,"status":"noted","reservation_date":"2020-11-07 13:35:37","uploaded":"2020-11-14 07:42:06","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"liaison-response-3GPP-SA2-TSN-support-1120-v02","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008498.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008502","title":"LS from RAN WG2: LS on UTRAN UE capabilities from CN to gNB","source":"RAN WG2","contact":"Xun Tang","contact-id":78305,"tdoctype":"LS in","for":"Action","abstract":"UTRA capabilities include information that changes every time the UE connects to UTRA, some of which concern START values. To avoid START values de-synchronization and the key replay, RAN WG2 agreed that o The gNB does not upload the UE UTRA-FDD capabilities to the AMF; o Prior to initiating mobility the gNB always retrieves the latest capabilities from the UE. I.e. would not use UTRA capabilities received from CN, if provided. RAN WG2 would like to know if o For the manufacturer assigned case, the UE capability ID is intended to cover UTRA capabilities; also, o CN may provide UTRA capabilities to gNB. Action: SA WG2 is kindly requested to take RAN WG2's consideration into account.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10180,"status":"postponed","reservation_date":"2020-11-07 13:35:37","uploaded":"2020-11-15 08:47:13","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG3","lsoriginalls":"R2-2011164","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008502.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008507","title":"[DRAFT] LS on5GC Support of DHCP signaling for RG","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"LS on5GC Support of DHCP signaling for RG","secretary_remarks":"Response to S2-2008341. r05 agreed. Revised to S2-2009340.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10770,"status":"revised","reservation_date":"2020-11-07 17:48:11","uploaded":"2020-11-09 15:43:42","revisionof":"","revisedto":"S2-2009340","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"BBF","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008507.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008508","title":"5GC Support of DHCP signaling for RG","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: When a DHCP server is used by the 5GC to serve DHCP requests coming from a wireline BBF access, this DHCP server shall support the DHCP server requirements described in TR-470 . In this release of the specification, a RG that supports MA PDU Sessions and LTE\/EPC access, shall also support MA PDU using LTE\/EPC as 3GPP access as defined in clause 4.12.3","secretary_remarks":"r04 agreed. Revised to S2-2009341.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10790,"status":"revised","reservation_date":"2020-11-07 17:48:11","uploaded":"2020-11-09 15:43:42","revisionof":"","revisedto":"S2-2009341","release":"Rel-16","crspec":"23.316","crspecversion":"16.5.0","workitem":[{"winame":"5WWC"}],"crnumber":2055.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008508.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008529","title":"Removal of Tx Profile for NR PC5","source":"LG Electronics","contact":"Laeyoung Kim","contact-id":40613,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Remove Tx Profile for NR PC5","secretary_remarks":"Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10270,"status":"agreed","reservation_date":"2020-11-08 08:08:45","uploaded":"2020-11-09 14:35:50","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.287","crspecversion":"16.4.0","workitem":[{"winame":"eV2XARC"}],"crnumber":153.0,"crrevision":"","crcategory":"F","tsg_crp":"SP-200950","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008529.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008545","title":"AUSF\/UDM discovery based SUCI information","source":"China Mobile","contact":"Yi Jiang","contact-id":40863,"tdoctype":"draftCR","for":"Approval","abstract":"Public Key ID is allowed to be used for AUSF\/UDM discovery.","secretary_remarks":"r01 agreed. Revised to S2-2009336.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10550,"status":"revised","reservation_date":"2020-11-09 01:31:06","uploaded":"2020-11-09 12:17:03","revisionof":"","revisedto":"S2-2009336","release":"Rel-17","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"TEI17"},{"winame":"5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008545.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008546","title":"AUSF\/UDM discovery based SUCI information","source":"China Mobile","contact":"Yi Jiang","contact-id":40863,"tdoctype":"draftCR","for":"Approval","abstract":"Public Key ID is allowed to be used for AUSF\/UDM discovery.","secretary_remarks":"r01 agreed. Revised to S2-2009337.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10570,"status":"revised","reservation_date":"2020-11-09 01:31:06","uploaded":"2020-11-09 12:17:03","revisionof":"","revisedto":"S2-2009337","release":"Rel-17","crspec":"23.502","crspecversion":"16.6.0","workitem":[{"winame":"TEI17"},{"winame":"5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008546.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008547","title":"[DRAFT] Reply LS on AUSF\/UDM discovery based on SUCI information","source":"China Mobile","contact":"Yi Jiang","contact-id":40863,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to CT WG4 AUSF\/UDM discovery based on SUCI information","secretary_remarks":"Response to S2-2008337. CC#3. r01 was considered. This was agreed and revised to S2-2009207","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10600,"status":"revised","reservation_date":"2020-11-09 01:31:06","uploaded":"2020-11-09 12:17:03","revisionof":"","revisedto":"S2-2009207","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008547.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008556","title":"[DRAFT] Reply LS on NSSAA at inter-PLMN mobility","source":"Samsung","contact":"Hoyeon Lee","contact-id":62489,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1","secretary_remarks":"Response to S2-2008347. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10850,"status":"noted","reservation_date":"2020-11-09 02:29:15","uploaded":"2020-11-09 11:27:11","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008556.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008571","title":"[DRAFT] Reply LS on early UE capability retrieval for eMTC","source":"Qualcomm Technologies Int","contact":"Miguel Griot","contact-id":84607,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to RAN WG2 mentioning SA WG2 is OK with moving forward with early UE capability retrieval but only in Rel-17","secretary_remarks":"Response to S2-2008336. r03 agreed. Revised to S2-2009345.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10960,"status":"revised","reservation_date":"2020-11-09 04:58:30","uploaded":"2020-11-09 18:22:08","revisionof":"","revisedto":"S2-2009345","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"5G_CIoT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"RAN WG3, CT WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008571.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008572","title":"Truncated 5G S-TMSI for early UE capability retrieval","source":"Qualcomm Incorporated","contact":"Miguel Griot","contact-id":84607,"tdoctype":"CR","for":"Endorsement","abstract":"Summary of change: Extend the AMF provisioning of truncated 5G S-TMSI information to UEs accesing via LTE-M.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10980,"status":"noted","reservation_date":"2020-11-09 05:03:51","uploaded":"2020-11-09 18:22:08","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"TEI17"}],"crnumber":2517.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008572.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008573","title":"Early UE capability retrieval support","source":"Qualcomm Incorporated","contact":"Miguel Griot","contact-id":84607,"tdoctype":"CR","for":"Endorsement","abstract":"Summary of change: Add reference to 36.300 and TS 36.413 for early UE capability retrieval procedure.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10990,"status":"noted","reservation_date":"2020-11-09 05:07:01","uploaded":"2020-11-09 18:22:08","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.401","crspecversion":"16.8.0","workitem":[{"winame":"TEI17"}],"crnumber":3616.0,"crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008573.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008615","title":"Discussion on AUSF\/UDM discovery based on SUCI information.","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"discussion","for":"Discussion","abstract":"This contribution discusses the AUSF\/UDM discovery based on SUCI information.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10540,"status":"noted","reservation_date":"2020-11-09 07:18:12","uploaded":"2020-11-09 14:11:44","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008615.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008616","title":"[DRAFT] Reply LS on AUSF&UDM discovery based on SUCI information","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"This paper proposes a Reply LS to CT WG4 on AUSF&UDM discovery based on SUCI information.","secretary_remarks":"Response to S2-2008337. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10590,"status":"noted","reservation_date":"2020-11-09 07:18:12","uploaded":"2020-11-09 14:11:44","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008616.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008623","title":"[DRAFT] Reply LS on NSSAA at inter-PLMN mobility","source":"OPPO","contact":"Fei Lu","contact-id":87831,"tdoctype":"LS out","for":"Approval","abstract":"This is the reply LS on NSSAA at inter-PLMN mobility (S2-2008347\/ C1-206508).","secretary_remarks":"Response to S2-2008347. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10860,"status":"noted","reservation_date":"2020-11-09 07:21:29","uploaded":"2020-11-09 10:25:20","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"eNS"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"CT WG4, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008623.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008688","title":"NSSAA at inter-PLMN mobility.","source":"OPPO","contact":"Fei Lu","contact-id":87831,"tdoctype":"discussion","for":"Discussion","abstract":"This is to analyse the questions in the incoming LS S2-2008347 and provides the discussion on the answers.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10830,"status":"noted","reservation_date":"2020-11-09 08:27:39","uploaded":"2020-11-09 10:25:20","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"eNS"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008688.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008749","title":"Discussion on URLLC QoS Monitoring.","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"discussion","for":"Approval","abstract":"This contribution proposes to note S2-2008237 (CR 2413) which was agreed at SA WG2#141E e-meeting and send an LS to RAN WG3 to update the information.","secretary_remarks":"Not on agenda for SA WG2#142E. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":11000,"status":"noted","reservation_date":"2020-11-09 10:32:10","uploaded":"2020-11-09 14:11:43","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"","workitem":[{"winame":"5G_URLLC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008749.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008750","title":"[DRAFT] LS on Clarification on URLLC QoS Monitoring","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"This LS is sent to RAN WG3 and CT WG4 to clarify on the reporting frequency parameter.","secretary_remarks":"Not on agenda for SA WG2#142E. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":11010,"status":"noted","reservation_date":"2020-11-09 10:32:10","uploaded":"2020-11-09 14:11:43","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5G_URLLC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, CT WG4","Cc":"SA WG5, RAN WG2","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008750.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008769","title":"[DRAFT] Reply LS on SNPN access mode when UE accesses SNPN services via a PLMN","source":"MediaTek Inc.","contact":"Guillaume Sebire","contact-id":45073,"tdoctype":"LS out","for":"Approval","abstract":"Reply LS to CT WG1 (S2-2008350\/C1-206736)","secretary_remarks":"Response to S2-2008350. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10450,"status":"noted","reservation_date":"2020-11-09 11:19:10","uploaded":"2020-11-09 18:03:33","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"Vertical_LAN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008769.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008770","title":"Definition of SNPN access mode","source":"MediaTek Inc.","contact":"Guillaume Sebire","contact-id":45073,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: The definition of SNPN access mode is revised to be applicable on both Uu and NWu.","secretary_remarks":"CC#3: Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10410,"status":"noted","reservation_date":"2020-11-09 11:19:10","uploaded":"2020-11-09 18:03:33","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":2518.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008770.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008796","title":"Correction to SNPN access mode","source":"Intel","contact":"Saso Stojanovski","contact-id":24932,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: This CR proposes to clarify that SNPN access mode is an interface setting applying on Uu and NWu, and controls the type of network selection that can be applied on that interface. For UEs capable of connecting to a PLMN and to an SNPN simultaneously (using a PLMN and SNPN credentials, respectively), the SNPN access mode setting on Uu is different from the SNPN access mode on NWu. It is noted that in this release the setting of SNPN access mode for a specific interface identifies the undelying network subscription type (i.e. SNPN subscription vs PLMN subscription) that is used for network selection.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10420,"status":"noted","reservation_date":"2020-11-09 12:38:53","uploaded":"2020-11-09 21:44:43","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":2519.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008796.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008807","title":"[DRAFT] Reply LS on IP address to GPSI translation","source":"Samsung","contact":"Jicheol Lee","contact-id":87580,"tdoctype":"LS out","for":"Approval","abstract":"SA WG2 understands the use case that the EAS that is not aware of UE identifier(s) can only provide UE's IP address (over the API) as the identifier of the UE.","secretary_remarks":"Response to S2-2008358. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10750,"status":"noted","reservation_date":"2020-11-09 12:47:11","uploaded":"2020-11-09 13:18:25","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008807.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008811","title":"GPSI translation based on UE IP address","source":"Samsung","contact":"Jicheol Lee","contact-id":87580,"tdoctype":"draftCR","for":"Approval","abstract":"It is proposed to return GPSI as a static UE identifiers when the static UE identifier is requested by AF using Nbsf_Management_Discovery service operation.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10700,"status":"noted","reservation_date":"2020-11-09 12:53:14","uploaded":"2020-11-09 13:18:25","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"16.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008811.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008813","title":"GPSI translation based on UE IP address","source":"Samsung","contact":"Jicheol Lee","contact-id":87580,"tdoctype":"draftCR","for":"Approval","abstract":"It is proposed to return GPSI as a static UE identifiers when the static UE identifier is requested by AF using Nbsf_Management_Discovery service operation.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10710,"status":"postponed","reservation_date":"2020-11-09 12:59:57","uploaded":"2020-11-09 13:18:25","revisionof":"","revisedto":"","release":"Rel-17","crspec":"23.503","crspecversion":"16.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"C","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008813.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008911","title":"[DRAFT] Reply LS on SNPN access mode when UE accesses SNPN services via a PLMN","source":"Intel","contact":"Saso Stojanovski","contact-id":24932,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1.","secretary_remarks":"Response to S2-2008350. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10460,"status":"noted","reservation_date":"2020-11-09 14:00:38","uploaded":"2020-11-09 21:44:43","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"Vertical_LAN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008911.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008962","title":"[DRAFT] Response to LS on AS RAI and optimization of release","source":"VODAFONE Group Plc","contact":"Chris Pudney","contact-id":1122,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG2","secretary_remarks":"Response to S2-2008333. CC#3: Huawei asked whether r05 can be accepted. Qualcomm could only accept the original r00. This was then noted.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10360,"status":"noted","reservation_date":"2020-11-09 15:59:19","uploaded":"2020-11-09 16:04:00","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008962.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2008989","title":"[DRAFT] Reply LS on IP address to GPSI translation","source":"Qualcomm Incorporated","contact":"Dario Serafino Tonesi","contact-id":88932,"tdoctype":"LS out","for":"Approval","abstract":"This LS replies that the issue is not addressed in Rel-17","secretary_remarks":"Response to S2-2008358. r12 agreed. Revised to S2-2009339.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10730,"status":"revised","reservation_date":"2020-11-09 16:51:51","uploaded":"2020-11-09 18:54:12","revisionof":"","revisedto":"S2-2009339","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_enh_EC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2008989.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009001","title":"Support of the mapping from IP addressing information provided to an AF to the user identity","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Endorsement","abstract":"Summary of change: In this case the 5GC first needs to retrieve the Permanent identifier of the UE before trying to fulfil the AF request. The 5GC may to determine the Permanent identifier of the UE based on: the UE addressing information (e.g. IP address and port information) of the UE as provided by the AF: this may correspond to an UE IP address as allocated by 5GC or to an IP address (and port) that has been NATed (Network and Port Address Translation) by an entity controlled by the 5GC operator. In the latter case the 5GC (NEF) needs to first get from the NATF (5GC NF that has carried out NAT at the user plane) the translation back from the IP addressing information provided by the AF to the IP address that the 5GC has allocated to the UE. the corresponding DNN and\/or S-NSSAI information: this may have been provided by the AF or determined by the NEF using the identity of the AF;","secretary_remarks":"Revision of S2-2007481 from S2#141E (Revised to S2-2008052 and approved!). r07 agreed. Revised, merging S2-2008492, to S2-2009338","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10670,"status":"revised","reservation_date":"2020-11-09 17:09:36","uploaded":"2020-11-09 18:23:49","revisionof":"S2-2004841","revisedto":"S2-2009338","release":"Rel-17","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"EDGEAPP"}],"crnumber":2385.0,"crrevision":1.0,"crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009001.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009002","title":"Support of the mapping from IP addressing information provided to an AF to the user identity","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Endorsement","abstract":"Summary of change: An AF may request (via the NEF) information exposure or parameter provisioning targetting an individual UE, identifying the target UE by providing UE addressing information (e.g. IP address and port of the UE). In this case the 5GC first needs to retrieve a Permanent Identifier of the UE IP addressing information (IP address and port information) of the UE provided by the AF may correspond to an UE IP address as allocated by 5GC or to an IP address that has been NATed (Network and Port Address Translation) by an entity controlled by the 5GC operator. In the latter case the 5GC needs to first get the translation back from the IP addressing information provided by the AF to the IP address that the 5GC has allocated to the UE and then can get a Permanent Identifier of the UE; On how 5GC can first get the translation back from the IP addressing information provided by the AF to the IP address that the 5GC has allocated to the UE , there multiple solutions, this CR version describes following solution but puts it as FFS (Editor's Note as it may be premature to conclude on this aspect): from the NATF (new 5GC NF that has carried out NAT at the user plane) The CR defines (Figure 4.15.3.2.X-1) how the NEF determines a Permanent Identifier of the UE in this case. Once the procedure described in Figure 4.15.3.2.X-1 has taken place, the NEF Event exposure or the parameter provisioning as defined in R16 may apply. Nnef_EventExposure_Subscribe, Nnef_Location_LocationUpdateNotify and Nnef_ParameterProvision operations are modified accordingly. NATF Services are introduced.","secretary_remarks":"Revision of (Postponed) S2-2007482 from S2#141E. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10690,"status":"postponed","reservation_date":"2020-11-09 17:09:38","uploaded":"2020-11-09 18:23:49","revisionof":"S2-2004842","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"16.6.0","workitem":[{"winame":"EDGEAPP"}],"crnumber":2329.0,"crrevision":1.0,"crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009002.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009003","title":"On UE ID in 5GS API(s).","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"discussion","for":"Agreement","abstract":"Discussion on UE ID in 5GS API(s) (relates with LS in S2-2008358)","secretary_remarks":"R02 endorsed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10650,"status":"endorsed","reservation_date":"2020-11-09 17:09:39","uploaded":"2020-11-09 18:23:49","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"EDGEAPP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009003.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009004","title":"[DRAFT] Reply LS on IP address to GPSI translation","source":"Nokia, Nokia Shanghai Bell","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"WITHDRAWN: Draft Reply LS on IP address to GPSI translation (relates with LS in S2-2008358)","secretary_remarks":"Response to S2-2008356. WITHDRAWN","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10720,"status":"withdrawn","reservation_date":"2020-11-09 17:09:39","uploaded":"2020-11-09 18:23:49","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"EDGEAPP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009004.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009013","title":"N3IWF selection procedure when accessing SNPN via PLMN","source":"Qualcomm Incorporated","contact":"Sebastian Speicher","contact-id":72922,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding a new clause to specify how the UE perform N3IWF selection when UE is accessing SNPN service via PLMN(s).","secretary_remarks":"r06 agreed. Revised merging S2-2008476, to S2-2009334,","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10490,"status":"revised","reservation_date":"2020-11-09 17:35:50","uploaded":"2020-11-09 19:36:16","revisionof":"","revisedto":"S2-2009334","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":2521.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009013.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009016","title":"[DRAFT] Reply LS on Additional Clarifications on LI requirements applicable to SNPNs","source":"Qualcomm Incorporated","contact":"Sebastian Speicher","contact-id":72922,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3-LI. CC: CT WG1, CT WG4","secretary_remarks":"Response to S2-2008329. r00 agreed. Revised, merging S2-2008477, to S2-2009335","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"revised","reservation_date":"2020-11-09 17:56:01","uploaded":"2020-11-09 19:36:16","revisionof":"","revisedto":"S2-2009335","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"Vertical_LAN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3-LI","Cc":"CT WG1, CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009016.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009040","title":"[DRAFT] LS Reply on NSSAA at inter-PLMN mobility","source":"Qualcomm Tech. Netherlands B.V","contact":"Stefano Faccin","contact-id":57487,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1. CC: CT WG4, SA WG3","secretary_remarks":"Response to S2-2008347. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10870,"status":"noted","reservation_date":"2020-11-09 19:03:48","uploaded":"2020-11-09 22:11:03","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"eNS"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"CT WG4, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009040.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009041","title":"[DRAFT] Reply LS on SNPN access mode when UE accesses SNPN services via a PLMN","source":"Qualcomm Incorporated","contact":"Sebastian Speicher","contact-id":72922,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1","secretary_remarks":"Response to S2-2008350. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10470,"status":"noted","reservation_date":"2020-11-09 19:08:46","uploaded":"2020-11-09 19:36:16","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"Vertical_LAN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009041.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009042","title":"Clarify SNPN access mode definition","source":"Qualcomm Incorporated","contact":"Sebastian Speicher","contact-id":72922,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify in clause 3.1 that a UE operating in SNPN access mode only selects stand-alone Non-Public Networks over Uu or only selects stand-alone Non-Public Networks over NWu established via a PDU session provided by a PLMN selected over Uu.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10400,"status":"noted","reservation_date":"2020-11-09 19:10:54","uploaded":"2020-11-09 19:36:16","revisionof":"","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":2522.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009042.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009097","title":"LS from RAN WG3: Reply LS on End Marker in NG-RAN initiated QoS Flow mobility","source":"RAN WG3","contact":"Philippe Godin","contact-id":68843,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 would like to provide feedback on the three proposed alternatives for the UPF sending end marker packets which are listed in CT WG4 LS: 1. UPF sends one or more End Marker messages without any QFI included; 2. UPF sends one or more End Marker messages including one QFI of those QoS flows be switched to the new N3 tunnel; 3. UPF sends one or more End marker messages including the QFI for each of those QoS flows be switched to the new N3 tunnel; RAN WG3 would like to feed back that the 1st option outlined is aligned with our understanding. Furthermore, RAN WG3 has agreed the attached CRs to clarify above in TS 37.340 where the QoS Flow mobility is specified in detail.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"noted","reservation_date":"2020-11-16 11:15:08","uploaded":"2020-11-16 11:17:03","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"SA WG2","lsoriginalls":"R3-207085","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009097.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009098","title":"LS from RAN WG3: LS to SA2 on Immediate Suspension","source":"RAN WG3","contact":"Zijiang Ma","contact-id":36270,"tdoctype":"LS in","for":"Action","abstract":"In Rel-16, immediate Suspension has been supported in NGAP. That means if the Suspend Request Indication IE is included in the UE CONTEXT RESUME REQUEST message, the AMF shall, if supported, consider that the NG-RAN node is requesting immediate transition to RRC IDLE with Suspend as specified in TS 23.502. If the Suspend Response Indication IE is included in the UE CONTEXT RESUME RESPONSE message, the NG-RAN node shall suspend the UE context, the UE-associated logical NG-connection and the related PDU session contexts and transitions the UE to RRC_IDLE. Thus, there is not additional UE Context Suspend procedure during immediate Suspension case. To support immediate Suspension procedure, RAN WG3 has agreed to introduce Information on Recommended Cells and RAN Nodes for Paging IE and Paging Assistance Data for CE Capable UE IE in NGAP: UE CONTEXT RESUME REQUEST message. Action: RAN WG3 respectfully asks SA WG2 to take the above information into account and update their related specification.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10190,"status":"postponed","reservation_date":"2020-11-16 11:15:08","uploaded":"2020-11-16 11:17:03","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"R3-207138","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009098.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009100","title":"LS from RAN WG3: Reply LS on NAS Non delivery for RRC_INACTIVE state","source":"RAN WG3","contact":"Jiancheng SUN","contact-id":62128,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 thanks SA WG2 for the LS on NAS Non delivery for RRC Inactive state. For the second answer, RAN WG3 further discussed how to inform AMF the non-delivery of the non-PDU session related NAS PDU received in the 'PDU Session Resource Setup' and 'Initial Context Setup'. For 'PDU Session Resource Setup', some companies in RAN WG3 still doubt if the scenario is valid, especially considering the following statement in TS 23.502 section 4.2.3.2: 'If the Service Request procedure is triggered by the Network (as described in clause 4.2.3.3) while the UE is in CM-CONNECTED state, only N2 SM information received from SMF is included in the N2 Request.' Question 1: For a UE in RRC_INACTIVE state, is there any use case for AMF to piggyback a non-PDU session related NAS PDU in PDU SESSION RESOURE SETUP REQUEST? For 'Initial Context Setup', the scenario is confirmed in RAN WG3, but we have not reached the consensus on how to inform AMF the non-delivery of the non-PDU session related NAS-PDU in the 'Initial Context Setup Request'. Here are two candidate solutions: - Solution 1: Use NAS NON DELIVERY INDICATION message to indicate the failure of the NAS delivery. - Solution 2: Use the 'Initial Context Setup failure' to implicitly indicate the failure of the NAS delivery. Question 2: Which solution is preferred to inform AMF the non-delivery of the non-PDU session related NAS-PDU in the 'Initial Context Setup Request'?. Action: RAN WG3 would like to further ask SA WG2 the following questions: Q1\/ For a UE in RRC_INACTIVE state, is there any use case for AMF to piggyback a non-PDU session related NAS PDU in PDU SESSION RESOURE SETUP REQUEST? Q2\/ Which solution is preferred to inform AMF the non-delivery of the non-PDU session related NAS-PDU in the 'Initial Context Setup Request'?","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10200,"status":"postponed","reservation_date":"2020-11-16 11:15:08","uploaded":"2020-11-16 11:17:03","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG4","lsoriginalls":"R3-207170","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009100.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009101","title":"LS from RAN WG3: Reply LS on QoS Monitoring for URLLC","source":"RAN WG3","contact":"Angelo Centonza","contact-id":45800,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 thanks SA WG5 for their Reply LS on QoS Monitoring for URLLC. SA WG5 outlined the following Action: for RAN WG3: Action: SA WG5 respectfully requests RAN WG3 to also provide an UL packet delay result by NG-RAN with focus on network side excluding the UL D1 packet delay occurred in the UE (UL PDCP queuing delay, as defined in the clause 4.2.1 of TS 38.314) for QoS monitoring. RAN WG3 would like to clarify that the measurements relative to the RAN part of the packet delay, excluding the UL D1 packet delay, can be collected by the OAM by means of the following measurements defined in TS28.552: - D2 (DL delay on gNB-DU), referring to Average delay in RLC sublayer of gNB-DU in TS 28.552, \u00a7 5.1.3.3.3. - D3 (DL delay on F1-U), referring to Average delay on F1-U in TS 28.552, \u00a7 5.1.3.3.2. - D4 (DL delay in CU-UP), referring to Average delay DL in CU-UP in TS 28.552, \u00a7 5.1.3.3.1. RAN WG3 has therefore concluded that no further changes to its specifications is needed.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"noted","reservation_date":"2020-11-16 11:15:08","uploaded":"2020-11-16 11:17:03","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG5, SA WG2","Cc":"RAN WG2","lsoriginalls":"R3-207177","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009101.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009102","title":"LS from RAN WG3: LS Reply on HO to congested cells","source":"RAN WG3","contact":"Yazid Lyazidi","contact-id":78235,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 thanks TSG SA for their LS on HO to congested cells. RAN WG3 has reached the conclusion that the potential issue raised by some companies in the TSG SA LS can be mitigated by the current NR mechanisms in RAN (including the support for e.g. slicing) and by proper implementation of admission control; this may include setting a less demanding (but still appropriate for the service, if possible) AQP. Action: RAN WG3 kindly asks SA WG2 to take the above information into account.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"noted","reservation_date":"2020-11-16 11:15:08","uploaded":"2020-11-16 11:17:03","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA","lsoriginalls":"R3-207182","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009102.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009105","title":"LS from RAN WG3: LS to SA5 on MDT Stage 2 and Stage 3 alignment","source":"RAN WG3","contact":"Angelo Centonza","contact-id":45800,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 could not converge on whether all the values specified in TS32.422 for the M4 and M5 configuration period for LTE should be reflected in the RAN WG3 stage 3 specifications. RAN WG3 would like to ask whether the RAN WG3 MDT specifications should align to the SA WG5 Stage 2 specifications.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"noted","reservation_date":"2020-11-16 11:15:08","uploaded":"2020-11-16 11:17:03","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG5, RAN WG2","Cc":"SA WG2","lsoriginalls":"R3-207222","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009105.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009106","title":"LS from RAN WG3: LS on PDU Session level Expected UE activity behaviour","source":"RAN WG3","contact":"Feng Han","contact-id":73581,"tdoctype":"LS in","for":"Action","abstract":"RAN WG3 has discussed whether to introduce the PDU session level 'Expected UE Activity Behaviour' from the AMF to NG-RAN since only the UE level 'Expected UE Activity Behaviour' is currently considered. During the discussion, RAN WG3 discussed two possible interpretations regarding the descriptions in section 5.4.6.2 of TS 23.501. - Interpretation 1: Both the UE level and PDU session level 'Expected UE Activity Behaviour' are provided to the NG-RAN, then the NG-RAN performs the aggregation. - Interpretation 2: only the UE level 'Expected UE Activity Behaviour' is provided to the NG-RAN. Before that, the AMF performs the aggregation of PDU session level 'Expected UE activity behaviour' into UE level. Also, especially in case of interpretation 1, it is not clear which exact Expected UE Activity Behaviour parameters are expected to be sent to NG-RAN at UE-level on one side and at PDU-session level on the other side, especially in relation to the table 4.15.6.3-1 of TS 23.502. Currently the Expected UE Activity Behaviour includes the Expected Activity Period, Expected Idle Period and Source of UE Activity Behaviour Information in RAN specification. Action: RAN WG3 kindly asks SA WG2 to feedback which interpretation is correct, which set of parameters is to be sent at which level, and how the two levels should work together, so that RAN WG3 can decide on an appropriate course of action.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"postponed","reservation_date":"2020-11-16 11:15:08","uploaded":"2020-11-16 11:17:03","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"R3-207223","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009106.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009108","title":"LS on the input parameters of the LCS subscription request from an AF via NEF","source":"CT WG3","contact":"Abdessamad EL MOATAMID","contact-id":80517,"tdoctype":"LS in","for":"Action","abstract":"CT WG3 has observed that the inclusion of the parameters 'External Client Type' and 'LCS Service Type' as input parameters to be provided by the AF to the NEF when creating a LCS monitoring event subscription is not clear enough in the current Stage 2 specifications. Indeed, step 1 of clause 6.1.2 of 3GPP TS 23.273 (cf. extract below) states that the 'LCS Service Type' should be part of the parameters provided by the AF to the GMLC via the NEF, when sending a location monitoring event subscription. 1. The LCS Client or the AF (via NEF) sends a request to the (H)GMLC for a location and optionally a velocity for the target UE which may be identified by an GPSI or an SUPI. The request may include the required QoS, supported GAD shapes, LCS client type, LCS service type (see TS 22.071 [2]) and other attributes. (H)GMLC (for 1a) or NEF (for 1b) authorizes the LCS Client or the AF for the usage of the LCS service. If the authorization fails, step 2-23 are skipped and (H)GMLC (for 1a) or NEF (for 1b) responds to the LCS Client or the AF the failure of the service authorization in step 24. In some cases, the (H)GMLC derives the GPSI or SUPI of the target UE and possibly the QoS from either subscription data or other data supplied by the LCS Client or AF. At the same time, this parameter is not listed in clause 5.5 of 3GPP TS 23.273, which normally lists all the input parameters that can be provided by an AF or an LCS client. The 'External Client Type' parameter is also not present. In addition, Table 7.2.1-1 in clause 7.2.1 indicates that both the 'LCS Service Type' and the 'External Client Type' should be stored in the GMLC for an External LCS Client. In addition, 3GPP TS 29.515 (i.e. Ngmlc API), under the remit of CT WG4, defines these parameters as possible input parameters to be provided by the NEF to the GMLC (as per Table 6.1.5.2.2-1 of 3GPP TS 29.515) as part of the Ngmlc_Location_ProvideLocation service operation. The 'External Client Type' is even defined as a mandatory input parameter. In the meantime 3GPP TS 29.122, under the remit of CT WG3, currently does not define these parameters as possible input parameters to be provided by the AF when creating an LCS monitoring event subscription (as per Table 5.3.2.1.2-1 of 3GPP TS 29.122), which is a clear misalignment. Therefore, CT WG3 has the following questions: Q1: Should these parameters, i.e. 'LCS Service Type' and the 'External Client Type', be provided by an AF to the NEF when creating an LCS monitoring event subscription? This would enable the NEF to provide them to the GMLC in the Ngmlc_Location_ProvideLocation request. Q2: If the answer to the Q1 is yes, what is the behaviour of the NEF and GMLC when receiving these parameters? What are the checks, if any, that need to be performed? Q3: If the answer to Q1 is no, then how these parameters are derived by the NEF? Should these parameters only be stored and derived by the GMLC? In this case, this would mean that these parameters should be removed from the list of possible input parameters to be provided by the NEF in the Ngmlc_Location_ProvideLocation request. Action: CT WG3 kindly asks SA WG2 to provide answers and clarifications on the above questions and update the related Stage 2 specifications accordingly, if necessary.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10230,"status":"postponed","reservation_date":"2020-11-16 13:18:58","uploaded":"2020-11-16 13:19:47","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG4","lsoriginalls":"C3-205448","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009108.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009109","title":"LS from CT WG4: Reply LS on Restoration of profiles related to UDR","source":"CT WG4","contact":"Hiroshi Ishikawa","contact-id":72758,"tdoctype":"LS in","for":"Information","abstract":"CT WG4 would like to thank GSMA 5GJA for their LS on recovery procedures in case there is mismatch of profiles stored in AMF and UDR for registered UEs. CT WG4 would like to inform that a study item has been agreed to investigate the corresponding issue in Release 17.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"noted","reservation_date":"2020-11-16 13:18:58","uploaded":"2020-11-16 13:19:47","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA 5GJA","Cc":"SA WG2","lsoriginalls":"C4-205601","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009109.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009110","title":"LS from CT WG4: LS on Service Operation used during EPS to 5GS Handover with AMF re-allocation","source":"CT WG4","contact":"Zhijun Li","contact-id":39295,"tdoctype":"LS in","for":"Action","abstract":"During developing stage 3 protocols for the EPS to 5GS handover with AMF re-allocation, CT WG4 observed several issues. After discussion, CT WG4 reached some conclusion on one issue while still has questions to SA WG2 on the remaining issues. {. . .} Action: CT WG4 kindly asks SA WG2 to take CT WG4 discussion into account and provide feedback to these issues.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"postponed","reservation_date":"2020-11-16 13:18:58","uploaded":"2020-11-16 13:19:47","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C4-205702","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009110.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009111","title":"LS from CT WG4: LS on Network Configuration Parameters Consistent Handling in UDM","source":"CT WG4","contact":"Lu Yunjie","contact-id":74423,"tdoctype":"LS in","for":"Action","abstract":"When implementing Stage 3 specification, CT WG4 has observed the network configuration parameters handling in UDM are not consistent in different procedures: {. . .} Action: CT WG4 kindly asks SA WG2 to take the above information into account and possibly resolve the inconsistence in Stage 2 requirement to align with CT WG4 agreement.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"postponed","reservation_date":"2020-11-16 13:18:58","uploaded":"2020-11-16 13:19:47","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG3","lsoriginalls":"C4-205703","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009111.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009113","title":"LS Response on Support of L2TP in PFCP","source":"SA WG2","contact":"Stefan Rommer","contact-id":25950,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG4. CC: SA WG3, CT WG3","secretary_remarks":"Created at CC#1. Response to S2-2008496. r02 agreed. Revised to S2-2009331.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"revised","reservation_date":"2020-11-16 17:46:32","uploaded":"2020-11-17 13:34:18","revisionof":"","revisedto":"S2-2009331","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"BEPoP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4","Cc":"SA WG3, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009113.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009206","title":"Reply LS on SNPN access mode when UE accesses SNPN services via a PLMN","source":"SA WG2","contact":"Peter Hedman","contact-id":27550,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG1","secretary_remarks":"Revision of S2-2008475r01. This LS OUT was approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10440,"status":"approved","reservation_date":"2020-11-26 07:12:29","uploaded":"2020-11-26 07:31:14","revisionof":"S2-2008475","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"Vertical_LAN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008350","lsto":"CT WG1","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009206.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009207","title":"Reply LS on AUSF\/UDM discovery based on SUCI information","source":"SA WG2","contact":"Yi Jiang","contact-id":40863,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG4. CC: TSG CT, TSG SA, SA WG3. Attachments: S2-2009336 (23.501 draft CR) and S2-2009337 (23.502 draft CR)","secretary_remarks":"Revision of S2-2008547r01. This LS OUT was approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10610,"status":"approved","reservation_date":"2020-11-26 07:12:30","uploaded":"2020-11-26 07:31:14","revisionof":"S2-2008547","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"5GS_Ph1"},{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008337","lsto":"CT WG4","Cc":"TSG CT, TSG SA, SA WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009207.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009331","title":"LS Response on Support of L2TP in PFCP","source":"SA WG2","contact":"Stefan Rommer","contact-id":25950,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG4. CC: CT WG3, SA WG3","secretary_remarks":"Revision of S2-2009113r02. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"approved","reservation_date":"2020-11-26 07:12:42","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2009113","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":[{"winame":"BEPoP"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008496","lsto":"CT WG4","Cc":"SA WG3, CT WG3","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009331.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009332","title":"Reply LS on Location Information for SMS over IMS","source":"SA WG2","contact":"George Foti","contact-id":41317,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3-LI. CC: CT WG1, CT WG4. Attachments: S2-2009333 (TS 23.228 CR 1237)","secretary_remarks":"Revision of S2-2008391r00. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"approved","reservation_date":"2020-11-26 07:12:43","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008391","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"LI16"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008329","lsto":"SA WG3-LI","Cc":"CT WG1, CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009332.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009333","title":"Providing User Location during IP Messaging","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding text to specify the need by the P-CSCF to retrieve nework location information for SMS over IP (SIP:MESSAGE) depending on the access being used and to distribute the information to other IMS entities","secretary_remarks":"Revision of S2-2008392r06. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10340,"status":"agreed","reservation_date":"2020-11-26 07:12:43","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008392","revisedto":"","release":"Rel-16","crspec":"23.228","crspecversion":"16.5.0","workitem":[{"winame":"LI16"},{"winame":"TEI16"}],"crnumber":1237.0,"crrevision":1.0,"crcategory":"C","tsg_crp":"SP-200959","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009333.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009334","title":"N3IWF selection procedure when accessing SNPN via PLMN","source":"Qualcomm Incorporated, Ericsson, Rogers Communications Canada, Huawei","contact":"Sebastian Speicher","contact-id":72922,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Adding a new clause to specify how the UE perform N3IWF selection when UE is accessing SNPN service via PLMN(s). Clarify that a SNPN-enabled UE is additionally configured with an identifier of the country where each subscribed SNPN is deployed.","secretary_remarks":"Revision of S2-2009013r06 merging S2-2008476. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10500,"status":"agreed","reservation_date":"2020-11-26 07:12:44","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2009013","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"Vertical_LAN"}],"crnumber":2521.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-200953","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009334.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009335","title":"Reply LS on Additional Clarifications on LI requirements applicable to SNPNs","source":"SA WG2","contact":"Sebastian Speicher","contact-id":72922,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3-LI. CC: CT WG1, CT WG4. Attachments: S2-2009334 (TS 23.501 CR#2521)","secretary_remarks":"Revision of S2-2009016r00, merging S2-2008477. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10320,"status":"approved","reservation_date":"2020-11-26 07:12:45","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2009016","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"Vertical_LAN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008329","lsto":"SA WG3-LI","Cc":"CT WG1, CT WG4","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009335.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009336","title":"AUSF\/UDM discovery based SUCI information","source":"China Mobile","contact":"Yi Jiang","contact-id":40863,"tdoctype":"draftCR","for":"Approval","abstract":"Public Key ID is allowed to be used for AUSF\/UDM discovery.","secretary_remarks":"Revision of S2-2008545r01. Endorsed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10560,"status":"endorsed","reservation_date":"2020-11-26 07:12:45","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008545","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009336.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009337","title":"AUSF\/UDM discovery based SUCI information","source":"China Mobile","contact":"Yi Jiang","contact-id":40863,"tdoctype":"draftCR","for":"Approval","abstract":"Public Key ID is allowed to be used for AUSF\/UDM discovery.","secretary_remarks":"Revision of S2-2008546r01. Endorsed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10580,"status":"endorsed","reservation_date":"2020-11-26 07:12:45","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008546","revisedto":"","release":"Rel-17","crspec":"23.502","crspecversion":"16.6.0","workitem":[{"winame":"5GS_Ph1"},{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009337.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009338","title":"Support of the mapping from IP addressing information provided to an AF to the user identity","source":"Nokia, Nokia Shanghai Bell, Ericsson, Samsung","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Endorsement","abstract":"Summary of change: In this case the 5GC first needs to retrieve the Permanent identifier of the UE before trying to fulfil the AF request. The 5GC may to determine the Permanent identifier of the UE based on: the UE IP address as provided by the AF the corresponding DNN and\/or S-NSSAI information: this may have been provided by the AF or determined by the NEF using the identity of the AF;","secretary_remarks":"Revision of S2-2009001r07, merging S2-2008492. Endorsed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10680,"status":"endorsed","reservation_date":"2020-11-26 07:12:45","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2009001","revisedto":"","release":"Rel-17","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"EDGEAPP"}],"crnumber":2385.0,"crrevision":2.0,"crcategory":"B","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009338.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009339","title":"Reply LS on IP address to GPSI translation","source":"SA WG2","contact":"Dario Serafino Tonesi","contact-id":88932,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG3, SA WG6","secretary_remarks":"Revision of S2-2008989r12. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10740,"status":"approved","reservation_date":"2020-11-26 07:12:46","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008989","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_enh_EC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008358","lsto":"SA WG3, SA WG6","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009339.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009340","title":"LS on 5GC Support of DHCP signalling for RG","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"LS out","for":"Approval","abstract":"To: BBF, CableLabs. Attachments: 23.316 CR 2055","secretary_remarks":"Revision of S2-2008507r05. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10780,"status":"approved","reservation_date":"2020-11-26 07:12:46","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008507","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5WWC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008341","lsto":"BBF, CableLabs","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009340.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009341","title":"5GC Support of DHCP signaling for RG","source":"Nokia, Nokia Shanghai Bell, Ericsson","contact":"Laurent Thiebaut","contact-id":68713,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: When a DHCP server is used by the 5GC to serve DHCP requests coming from a wireline BBF access, this DHCP server shall support the DHCP server requirements described in TR-470 . In this release of the specification, a RG that supports MA PDU Sessions and LTE\/EPC access, shall also support MA PDU using LTE\/EPC as 3GPP access as defined in clause 4.12.3","secretary_remarks":"Revision of S2-2008508r04. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10800,"status":"agreed","reservation_date":"2020-11-26 07:12:46","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008508","revisedto":"","release":"Rel-16","crspec":"23.316","crspecversion":"16.5.0","workitem":[{"winame":"5WWC"}],"crnumber":2055.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-200954","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009341.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009342","title":"LS on Support of Dual Connectivity end to end Redundant User Plane Paths","source":"SA WG2","contact":"Belen Pancorbo","contact-id":78666,"tdoctype":"LS out","for":"Approval","abstract":"To: CT WG3. Attachments: 23.501 CR2408, 23.503 0483","secretary_remarks":"Revision of S2-2008422r01. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10900,"status":"approved","reservation_date":"2020-11-26 07:12:47","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008422","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5G_URLLC"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008335","lsto":"CT WG3","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009342.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009343","title":"Indication of redundancy transmission","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Clarify that the PCF indicates if the PDU session requires redundant transmission to the SMF, that is used by the SMF to request redundant transmission at PDU session set up to RAN when the PCF is used for the PDU session. Clarify that if the PCF is not deployed, then the SMF applies local policies, for example can map a 5QI into redundancy requirements.","secretary_remarks":"Revision of S2-2008423r02. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10920,"status":"agreed","reservation_date":"2020-11-26 07:12:47","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008423","revisedto":"","release":"Rel-16","crspec":"23.501","crspecversion":"16.6.0","workitem":[{"winame":"5G_URLLC"}],"crnumber":2408.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"SP-200951","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009343.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009344","title":"Policy control for redundant PDU Session for URLLC","source":"Ericsson","contact":"Shabnam Sultana","contact-id":21207,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: Extend the PDU session policy information to include indication that a PDU session is redundant PDU session.","secretary_remarks":"Revision of S2-2008424r02. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10940,"status":"agreed","reservation_date":"2020-11-26 07:12:48","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008424","revisedto":"","release":"Rel-16","crspec":"23.503","crspecversion":"16.6.0","workitem":[{"winame":"5G_URLLC"}],"crnumber":483.0,"crrevision":2.0,"crcategory":"F","tsg_crp":"SP-200951","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009344.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2009345","title":"Reply LS on early UE capability retrieval for eMTC","source":"SA WG2","contact":"Miguel Griot","contact-id":84607,"tdoctype":"LS out","for":"Approval","abstract":"To: RAN WG2. CC: TSG RAN, RAN WG3, CT WG1","secretary_remarks":"Revision of S2-2008571r03. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10970,"status":"approved","reservation_date":"2020-11-26 07:12:49","uploaded":"2020-11-26 07:31:17","revisionof":"S2-2008571","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":[{"winame":"5G_CIoT"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2008336","lsto":"RAN WG2","Cc":"TSG RAN, RAN WG3, CT WG1","lsoriginalls":"","lsreply":"","link":"https:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_142e_Electronic\/Docs\/S2-2009345.zip","group":"S2","meeting":"S2-142-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]