[{"name":"S2-2002608","title":"LS from SA WG6: LS on Application Architecture for enabling Edge Applications","source":"SA WG6","contact":"Niranth Amogh","contact-id":39608,"tdoctype":"LS in","for":"Action","abstract":"The technical report for the study item on Application Architecture for enabling Edge Applications in 3GPP TR 23.758 captures key issues, architecture requirements, solutions to key issues and application architecture. Dependency on SA WG2 has been identified for the architecture and solutions. It is understood that SA WG2 is also studying the enhancements to 5GS for edge computing and have some common objectives. Coordination between SA WG6 and SA WG2 is expected in order to progress the application architecture and related solutions in the normative phase. SA WG6 asks SA WG2 to provide feedback on the application architecture and solutions in TR 23.758 which are dependent on SA WG2 study item. Action: SA WG6 asks SA WG2 group to provide feedback on the application architecture and solutions in TR 23.758.","secretary_remarks":"Postponed S2-2001777 from S2#137E. 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-03-26 10:57:36","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001777","revisedto":"S2-2003514","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG3, SA WG5","lsoriginalls":"S6-192399","lsreply":"S2-2004115","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002608.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002610","title":"LS from RAN WG2: LS on dependencies on AS design for mobility management aspects of NTN in 5GS","source":"RAN WG2","contact":"Nicolas Chuberre","contact-id":21633,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 would like to thank SA WG2 for their LS in S2-1910786 on dependencies on AS design for mobility management aspects of NTN in 5GS. In the LS, SA WG2 informed RAN WG2 and RAN WG3 that the feasibility study FS_5GSAT_ARCH has been addressing some key issues related to mobility management in TR 23.737. However, SA WG2 has focused only on SA WG2 aspects and has not considered impacts of RAN solutions on the 5GS architecture mobility management procedures. SA WG2 will wait to see the results of the RAN WG2 and RAN WG3 work and may modify some of the conclusions and solutions accordingly, or take these results duly into account during the normative phase, as required. \u00f0 SA WG2 asked RAN WG2 and RAN WG3 to inform SA WG2 of their solutions selected for the NTN mobility (e.g. cell selection and re-selection) as soon as they may be available. NTN mobility management has been studied in RAN WG2. The results of this study can be found in clause 7.3.1 Idle mode mobility enhancements and clause 7.3.2 Connected mode mobility enhancements of TR 38.821. Action: RAN WG2 requests SA WG2 to take the above information into account.","secretary_remarks":"Postponed S2-2001779 from S2#137E. 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-03-26 10:57:36","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001779","revisedto":"S2-2003516","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, RAN WG3","Cc":"CT WG1","lsoriginalls":"R2-1916470","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002610.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002611","title":"LS from RAN WG2: LS on LS on system level design assumptions for satellite in 5GS","source":"RAN WG2","contact":"Nicolas Chuberre","contact-id":21633,"tdoctype":"LS in","for":"Action","abstract":"RAN WG2 would like to thank SA WG2 for their LS in S2-1910787 on system level design assumptions for satellite in 5GS. In the LS, SA WG2 informed RAN WG2 and RAN WG3 that the feasibility study FS_5GSAT_ARCH has been addressing some key issues related to mobility management. Specifically, SA WG2 has considered a solution called 'distributed gNB for NGSO satellites', as described in section 6.9 of TR 23.737. Briefly, such solution assumes that a constellation of NGSO satellites and the corresponding Ground stations appear as a single gNB to both the UE and the CN (AMF and UPF), independently of how many satellites are in the constellation. Such distributed gNB has a single Tracking Area visible to the UE: - this is achieved by having the beams that the satellites project moving depending on the location of the satellites; once a serving satellite would become out of reach it will switch off the beam related to the given TA. To ensure continuity of service, the TA would be served by a new satellite already in reach of the TA; - when possible, each of the beams (from different satellites) that are related to the same TA are using the same radio characteristics, i.e. the same radio frequencies, the same cell information, the same SIB, etc. Thus, the UE will not be aware of which satellites it is connected to; - The solution assumes that the NGSO satellite constellation and ground stations can support multiple distributed gNBs and the corresponding distinct stationary TAs \u00f0 'SA WG2 kindly asks RAN WG2 and RAN WG3 to review and evaluate the design of distributed gNB for NGSO satellite networks and provide feedback as needed.' The architectures and solutions considered by RAN WG2 and RAN WG3 are captured in TR 38.821. No further study on NTN is expected in Rel-16 in RAN WG2. Action: RAN WG2 requests SA WG2 to take the above information into account.","secretary_remarks":"Postponed S2-2001781 from S2#137E. 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-03-26 10:57:36","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001781","revisedto":"S2-2003517","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, RAN WG3","Cc":"CT WG1","lsoriginalls":"R2-1916620","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002611.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002614","title":"LS from SA WG5: LS on analysis of GSMA GST attributes","source":"SA WG5","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"There is an ongoing 3GPP Rel-16 WID which is related to management support for network slicing: - Management Aspects of 5G Service-Level Agreement (SP-190789) SA WG5 thinks that SLA requirements can be fulfilled from management aspect and system aspect in a coordinated way. SA WG5 has started analysing the attributes from GSMA PRD NG.116 v1.0 and has approved S5-197621 in which the 3GPP network slicing ServiceProfile NRM is updated to implement some GST SLA attributes. SA WG5 is working on the translation from GST attributes to 3GPP ServiceProfile NRM and the translation from 3GPP ServiceProfile NRM to 3GPP SliceProfile NRM, and will provide the configurable attributes to 3GPP 5GC domain (e.g. AMF, SMF, UPF etc.) and NG-RAN domain (e.g. NG-RAN node) based on 3GPP SliceProfile NRM, and will provide TN requirements to non-3GPP TN domain management systems, see below figure. Action: SA WG5 respectfully requests SA WG2 to take this information into account and provide feedback, if necessary.","secretary_remarks":"Postponed S2-2001785 from S2#137E. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"postponed","reservation_date":"2020-03-26 10:57:36","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001785","revisedto":"S2-2003518","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, RAN WG3, IETF","Cc":"TSG SA, SA WG1, SA WG6, RAN WG2, GSMA 5GJA, ETSI ISG ZSM","lsoriginalls":"S5-197853","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002614.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002615","title":"LS from ATIS: Correspondence from ATIS to SA WG2 Regarding a Slice Service Type","source":"ATIS","contact":"Brian K. Daly","contact-id":13316,"tdoctype":"LS in","for":"Action","abstract":"Dear Mr. Puneet Jain (SA WG2 Chairman) and Mr. Maurice Pope (SA WG2 secretary), The Alliance for Telecommunications Industry Solutions (ATIS) launched an IoT Categorization Focus Group in late 2017 to address how the burgeoning growth in the IoT ecosystem is driving a wide range of new uses and requirements on the network infrastructure. Several recent industry initiatives have examined the main features of IoT applications to better understand the requirements posed by each. The objective of ATIS' work is to explore the multidimensional characteristics of IoT across devices, applications, subscription type and technology as well as regulatory and market drivers. This work is instrumental in identifying design features relevant to the standardization of 5G. Attached please find a whitepaper entitled 'IoT Categorization: Exploring the Need for Standardizing Additional Network Slices.' The purpose of this whitepaper is to aid service providers' efforts to build networks that support a full range of IoT devices and services. We believe that in order to achieve these efforts a new Slice Service Type (SST) needs to be defined by SA WG2 in TS 23.501 in order to meet the described IoT characteristics matrix. We kindly ask that SA WG2 review this whitepaper and provide us with feedback at your earliest convenience, but no later than February 7, 2020. Further action (e.g., CRs) will be taken by Individual Member companies in SA WG2#137. If you have any questions, please do not hesitate to contact us. Sincerely, Brian Daly (AT&T), ATIS TOPS Council IoT-CAT Focus Group Co-Leader Farrokh Khatibi (Qualcomm), ATIS TOPS Council IoT-CAT Focus Group Co-Leader Carroll Gray-Preston (ATIS), ATIS TOPS Council IoT-CAT Focus Group Technical Lead","secretary_remarks":"Postponed S2-2001786 from S2#137E. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"noted","reservation_date":"2020-03-26 10:57:36","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001786","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"IoT_CAT_Liaison_Letter_to_SA2","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002615.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002616","title":"LS from ITU-T FG-VM: LS on technical reports on use cases and requirements as well as architecture for vehicular multimedia","source":"ITU-T FG-VM","contact":"Jun Li","contact-id":69869,"tdoctype":"LS in","for":"Information","abstract":"This liaison statement informs SA WG1, SA WG2, SA WG3 and SA WG4 of the completion of the use case and requirements technical report and on the initial work on the architecture technical report.","secretary_remarks":"Postponed S2-2001787 from S2#137E. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10030,"status":"noted","reservation_date":"2020-03-26 10:57:36","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001787","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2, SA WG3, SA WG4","Cc":"","lsoriginalls":"FGVM-LS014","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002616.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002617","title":"LS from GSMA 5GJA: LS Response to SA WG2 on Clarification of NG.116","source":"GSMA 5GJA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"Overall Description: GSMA 5GJA thanks SA WG2 for their LS 'LS reply on Clarification NG.116 GST Throughput Attributes and Non-3GPP Access Support' and the review of the attributes listed in the NG.116. Question from SA WG2: In GSMA NG.116 GST v2.0, clauses 3.4.5, 3.4.6, 3.4.31 and 3.4.32 describe the Downlink throughput per network slice, Downlink throughput per UE, Guarantee Uplink\/Downlink Throughput and the Maximum Uplink\/Downlink Throughput attributes. Do these attributes apply across to GBR and non-GBR traffic or just non-GBR traffic? Answer: These attributes apply to both GBR and non-GBR traffic. Question from SA WG2: 3GPP 5G network slicing supports both 3GPP and non-3GPP accesses for a given S-NSSAI. When enforcing the two attributes above in Rel-17, we assume to apply the enforcement to 3GPP access only. Answer from GSMA: These attributes are for 3GPP access only. Actions: GSMA 5GJA kindly asks SA WG2 to take this information into account.","secretary_remarks":"Postponed S2-2001788 from S2#137E. 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-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001788","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA, SA WG5","lsoriginalls":"5GJA11_122_r1","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002617.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002619","title":"LS from SA WG6: LS on Requirements on positioning for UAS","source":"SA WG6","contact":"Atle Monrad","contact-id":13818,"tdoctype":"LS in","for":"Information","abstract":"As part of the study for UAS, SA WG6 has discussed the requirements for positioning and what systems it apply to. SA WG6 has the following understanding: - It is assumed that E-UTRA and NG-RAN (i.e. neither GSM\/GPRS nor UTRAN) are applicable accesses for UAS. - It is assumed that the requirements for positioning as outlined in TS 22.071 also apply to NG-RAN. TS 22.071 currently only mention E-UTRA, GERAN and UTRAN. - It is assumed that the requirements for positioning (clause 6.27) and high accuracy positioning (clause 7.3) as outlined in TS 22.261 are applicable to the 5GS including both NG-RAN and E-UTRA connected to 5GC o SA WG6 also notes that informative table B.1-1 contains location KPIs for the UAV use case. - It is assumed that SA WG1 has no additional requirements for positioning for UAS beyond what is currenty outlined in TS 22.071, 22.261, and TS 22.125.","secretary_remarks":"Postponed S2-2001790 from S2#137E. 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-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001790","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"SA WG2, RAN WG2","lsoriginalls":"S6-200269","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002619.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002620","title":"LS from SA WG6: Reply LS on Split of work responsibilities between SA WG2 and SA WG6","source":"SA WG6","contact":"Edward Hall","contact-id":43958,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 has discussed the split of work responsibilities between SA WG2 and SA WG6 as proposed by SA WG2 and has the following feedback: - SA WG2 has responsibility for the 3GPP system architecture and procedures SA WG6 agrees. - SA WG6 has responsibility for the application-layer architecture and solutions identified by SA WG6 SA WG6 agrees. - DNS-based EAS discovery and related enhancements are in the scope of SA WG2. Application layer EAS discovery is in the scope of SA WG6. Any conflict between these two methods will be resolved in coordination between SA WG2 with SA WG6 SA WG6 agrees that DNS-based EAS discovery and related enhancements in 5GC are in the scope of SA WG2 and SA WG6 also acknowledges that development of URSP and DNAI-based solutions are also in the scope of SA WG2. - Any potential related overall architecture impacts related with 5GC exposure to application layer are in the scope of SA WG2. Potential Edge-related modifications to NEF API are in the scope of SA WG2, but SA WG6 may add additional information to be exposed by the 3GPP network. Documentation of those will be eventually done in SA WG2 specifications (TS 23.501, TS 23.502). SA WG6 agrees. - Edge-related modifications to CAPIF are in the scope of SA WG6. SA WG6 agrees. - Study of deployment scenarios are in the scope of both SA WG2 and SA WG6. The impact of certain deployment scenarios may require co-ordination between SA WG2 and SA WG6. The 900-series TR that SA WG2 is planning for edge deployment guidelines is under responsibility of SA WG2. SA WG6 acknowledges the removal of the Release 17 work-task for SA WG2 to document the deployment scenarios and guidelines in a 900-series TR. SA WG6 is documenting deployment scenarios and guidelines related to SA WG6 specifications in an informative annex of TS 23.558. Action: SA WG6 asks SA WG2 to take this into account.","secretary_remarks":"Postponed S2-2001791 from S2#137E. 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-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001791","revisedto":"S2-2003519","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA","lsoriginalls":"S6-200357","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002620.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002621","title":"LS from SA WG3LI: Response LS on the 'LS OUT on Location of UEs and associated key issues'","source":"SA WG3LI","contact":"Alexander Markman","contact-id":35093,"tdoctype":"LS in","for":"Action","abstract":"SA WG3-LI thanks SA WG2 for a timely consideration of the LI aspects in designing candidate solutions to the key issues of the study. In principle, SA WG3-LI have no objections to the approaches emulating terrestrial cellular networks topologies (cells, tracking areas) to support network access and mobility for a satellite UE. However, SA WG3-LI want to emphasize the fundamental LI requirements to be met by any of those approaches: - The logical location information (Cell ID) shall be reliable, i.e. network-provided or network-verified. - The logical location shall unambiguously map to the geographical area of the UE physical location. Granularity of such geographical areas needs to be able to provide network location accuracy comparable with terrestrial networks. - Any solution shall support the ability to enforce the use of a Core Network of PLMN in the country where the UE is physically located. The enforcement needs to also include cross-border service continuity scenarios. Furthermore, SA WG3-LI would like to point out that any solution addressing extraterritorial (e.g. international maritime zone and aeronautical) use cases should provide means to notify the HPLMN on roaming in and out of those areas, including the cases when the serving PLMN has not changed. SA WG3-LI would also like to emphasize the importance of extending the LCS capabilities onto the non-terrestrial networks. Action: SA WG3-LI kindly ask SA WG2, RAN WG2 and RAN WG3 to consider the above requirements when designing and evaluating solutions for the satellite-based networks.","secretary_remarks":"Postponed S2-2001792 from S2#137E. 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-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001792","revisedto":"S2-2003520","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, RAN WG2, RAN WG3","Cc":"SA WG1","lsoriginalls":"S3i200056","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002621.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002624","title":"LS from ATIS UAV Ad-Hoc Group: Liaison Statement on UAV Remote ID Priority in Release 17","source":"ATIS UAV Ad-Hoc Group","contact":"Iain Sharp","contact-id":61357,"tdoctype":"LS in","for":"Action","abstract":"The ATIS UAV Ad-Hoc group believes that support for remote identification of UAVs in 3GPP standards is important to fulfil regulatory requirements and to maximize the opportunity for mobile networks develop their business serving UAVs. To ensure 3GPP is aware of the technical direction of regulations in the US, we would like to bring to your attention the Notice of Proposed Rulemaking published by the Federal Aviation Authority (FAA) in December 2019. The notice can be found here: https:\/\/www.federalregister.gov\/documents\/2019\/12\/31\/2019-28100\/remoteidentification-of-unmanned-aircraft-systems The notice describes the current plans for FAA regulations for the use of UAVs in the US. As explained in more detail in the notice, the proposed rulemaking would require most UAVs to support Network Publishing ID and Direct Broadcast ID. We kindly ask SA WG1 and SA WG2 experts study the notice and to work to ensure that 3GPP standards fulfill the technical requirements in Release 17 in anticipation of the FAA's final rules. Sincerely, Iain Sharp Chair, ATIS UAV Ad Hoc Group","secretary_remarks":"Postponed S2-2001795 from S2#137E. 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-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001795","revisedto":"S2-2003522","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2","Cc":"TSG SA, TSG RAN","lsoriginalls":"FAA NPRM for UAV Remote ID","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002624.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002625","title":"LS from ETSI TC LI: LS on making PSCELL ID available at the SGW of EPC","source":"ETSI TC LI","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"ETSI TC LI thanks SA WG5 for the reply LS and for highlighting the progress on 5G Cell ID(s) in the SA WG5 billing system. The Rel-16 pCR S5-197113 for the draft TS 32.256 '5G connection and mobility domain charging; Stage 2' will help CSPs to comply with regulations that require such information in the CDRs from 5GC. Based on the SA WG5 reply LS (S5-197481), ETSI TC LI kindly asks SA WG2 to make the PSCELL ID available at the SGW in EPC, in addition to the PCELL ID, in order to make it subsequently possible for SA WG5 to specify the SGW CDR accordingly. Action: ETSI TC LI kindly asks SA WG2 to make the PSCELL ID available at the SGW in EPC, in addition to the PCELL ID for Rel-17.","secretary_remarks":"Postponed S2-2001796 from S2#137E. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"postponed","reservation_date":"2020-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2001796","revisedto":"S2-2003523","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, SA WG5","Cc":"SA WG3-LI","lsoriginalls":"LI(20)P53048r2","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002625.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002628","title":"LS from SA WG1: Reply LS on manual CAG selection","source":"SA WG1","contact":"Francesco Pica","contact-id":57089,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 thanks CT WG1 for their incoming LS on Manual CAG Selection, and related questions. SA WG1 answers are provided below. Question 1: When the user performs manual CAG selection, shall the user be presented with all the available CAG IDs or shall the user be presented with only those CAG IDs of a PLMN that are available and are present in the UE's Allowed CAG list for the PLMN? SA WG1 answer: SA WG1 currently does not have the concept of manual CAG selection, nor the concept of an Allowed CAG list for a PLMN. However, SA WG1 understands that the Allowed CAG list is a mechanism that allows the following two requirements (specified in TS 22.261) to be fulfilled The 5G system shall support a mechanism to prevent a UE with a subscription to a non-public network from automatically selecting and attaching to a PLMN or non-public network it is not authorized to select. The 5G system shall support a mechanism to prevent a UE with a subscription to a PLMN from automatically selecting and attaching to a non-public network it is not authorized to select SA WG1 has now defined a new requirement (see attached CR) regarding manual selection of non-public networks hosted by a PLMN. Question 2: Can the HPLMN configure the optional 'manual CAG selection control' parameter also for the VPLMN SA WG1 answer: Please refer to the new requirement mentioned above (see attached CR). Question 3: Is the VPLMN expected to be able to control inbound roamers' usage of VPLMN's CAG cells before the UE registers with the VPLMN, without HPLMN's cooperation? Or is there any preference for a common requirement\/solution for the serving PLMN (HPLMN and VPLMN) to control access of the user selection of CAG cells that are not included in the Allowed CAG list? SA WG1 answer: Please refer to the new requirement mentioned above (see attached CR). Question 4: If the UE is configured to access a PLMN only via CAG cells and a non-CAG cell of the PLMN is available, shall the UE always display the PLMN ID of such a PLMN, or should this be controlled by the PLMN, HPLMN, or both of them? SA WG1 answer: the UE always display the PLMN ID of such a PLMN in manual network selection mode. Question 5: If the registration over a CAG cell for a PLMN is successful and the selected CAG-ID is not present in the UE's Allowed CAG list for the PLMN, shall the UE add the CAG-ID to the Allowed CAG list for the PLMN? SA WG1 answer: No. Question 6: If the registration over a non-CAG cell for a PLMN is successful and the UE has an indication that the UE is only allowed to access the PLMN via CAG cells, shall the UE delete the indication for the PLMN? SA WG1 answer: No.","secretary_remarks":"Postponed S2-2002314 from S2#137E. 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-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2002314","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"RAN WG2, SA WG2","lsoriginalls":"S1-201084","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002628.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002629","title":"LS from SA WG1: LS on Questions on onboarding requirements","source":"SA WG1","contact":"Kurt Bischinger","contact-id":26063,"tdoctype":"LS in","for":"Action","abstract":"SA WG1 thanks SA WG2 for their LS on onboarding requirements. SA WG2 raised several questions concerning the following onboarding requirement: The 5G system shall support a secure mechanism for a network operator of an NPN to remotely provision the non-3GPP identities and credentials of a uniquely identifiable and verifiably secure IoT device. SA WG1 would like to provide the following answers: Q1) SA WG2 would like to verify with SA WG1 whether the above-quoted requirement includes the provisioning of the following for Stand-alone non-public networks (SNPNs): a) IMSI accompanied by AKA credentials, both used for SNPN authentication b) IMSI accompanied by AKA credentials, the IMSI being used to derive a Network Specific Identifier that will be used for SNPN authentication with the AKA credentials A1) The quoted requirement applies to non-3GPP identities and credentials only, while SA WG2's question refers to 3GPP identities and credentials. As such, the answer is no, the above-quoted requirement does not include provisioning of the mentioned identities and credentials to SNPNs. However, SA WG1 would like to point out that a requirement for remote provisioning has been included in TS 22.261, clause 6.14.2, since Release 15: The 5G system shall support a secure mechanism for a home operator to remotely provision the 3GPP credentials of a uniquely identifiable and verifiably secure IoT device. This requirement was acknowledged as being part of 'Existing features partly or fully covering the use case functionality' during FS_AVPROD study (see TR 22.827). Q2) SA WG2 would like to verify with SA WG1 whether the above-quoted requirement applies to PNI-NPN, which is the NPN 'hosted by a PLMN' as described in TS 22.261 clause 6.25.1, or not, and what would be the corresponding use cases. A2) SA WG1 requests clarification on the question from SA WG2, specifically, is SA WG2 asking if the above quoted question is related to primary or secondary authentication for the PNI-NPN. Q3) If SA WG1 confirm the above-quoted requirement applies to PNI-NPN in Q2, SA WG2 have further Q3 as below. For PNI-NPN, a UE may perform secondary PDU session authentication using 3rd party credentials, if the NPN is integrated in PLMN by means of dedicated DNNs, and\/or a UE may perform Network specific slice authentication and authorisation (NSSAA) using 3rd party credentials if the NPN is integrated in PLMN by means of network slice. Given the authentication procedures already specified in TS 23.501, TS 24.501 and TS 33.501, SA WG2 would also like to ask whether provisioning for identities and credentials used for Network specific slice authentication and authorisation (NSSAA) and secondary PDU session authentication should be considered to be covered as part of NPN service requirement for onboarding and remote provisioning solution. A3) SA WG1 requests clarification on the question from SA WG2, specifically, is SA WG2 asking whether 3rd party credentials may be used for secondary network slice authentication and authorization or Is SA WG2 asking whether these 3rd party credentials for secondary authentication can be provisioned via the 3GPP system, or is SA WG2 asking something else. Action: SA WG1 asks SA WG2 group to take the answer to A1 into account and provide the requested clarifications to Q2 and Q3","secretary_remarks":"Postponed S2-2002316 from S2#137E. Responses drafted in S2-2003006 and S2-2003168. Final response in S2-2003216","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10290,"status":"replied to","reservation_date":"2020-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2002316","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA, CT WG1, SA WG3, CT WG6","lsoriginalls":"S1-201087","lsreply":"S2-2003216","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002629.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002630","title":"LS from SA WG1: Reply LS on UAV positioning","source":"SA WG1","contact":"Eldad Zeira","contact-id":72021,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 has considered the points and assumptions listed in the LS on UAV positioning from SA WG6 requesting clarification on stage 1 requirements, as copied below. 1. It is assumed that E-UTRA and NG-RAN (i.e. neither GSM\/GPRS nor UTRAN) are applicable accesses for UAS. 2. It is assumed that the requirements for positioning as outlined in TS 22.071 also apply to NG-RAN. TS 22.071 currently only mention E-UTRA, GERAN and UTRAN. 3. It is assumed that the requirements for positioning (clause 6.27) and high accuracy positioning (clause 7.3) as outlined in TS 22.261 are applicable to the 5GS including both NG-RAN and E-UTRA connected to 5GC a. SA WG6 also notes that informative table B.1-1 contains location KPIs for the UAV use case. 4. It is assumed that SA WG1 has no additional requirements for positioning for UAS beyond what is currently outlined in TS 22.071, 22.261, and TS 22.125. In response, SA WG1 would like to confirm or clarify the following: - For '1' above, SA WG1 would like to clarify that SA WG1 has not specified applicable access for UAV in TS 22.125. The access networks for UAS, as discussed in SA WG1 Rel16 and Rel17 SIs\/WIs, include E-UTRAN and NG-RAN. As part of Rel17 WI EAV (5G enhancement for UAVs) the positioning requirements for UAVs are specified in TS 22.125, which apply to a 5G system with NG-RAN and 5G Core network. - SA WG1 confirms that '2' above is correct, as all SA WG1 requirements, unless specifically excluded, are also considered applicable to 5GS. SA WG1 also agreed a Release 15 CR to update TS 22.071. - SA WG1 confirms that '3' above is correct. NG-RAN is defined as a radio access network connected to the 5GC, which uses NR, E-UTRA, or both. o SA WG1 confirms that '3a' above is correct, noting that the content in table B.1-1 is informative only. - SA WG1 can confirm that '4' above is correct. SA WG1 has specified positioning requirements for UAS in TS 22.125. TS 22.071 specifies location service requirements and TS 22.261 specifies 5G positioning service requirements.","secretary_remarks":"Postponed S2-2002317 from S2#137E. 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-03-26 10:57:37","uploaded":"2020-03-27 13:44:13","revisionof":"S2-2002317","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"SA WG2, RAN WG1, RAN WG2","lsoriginalls":"S1-201089","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002630.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002631","title":"LS from GSMA FSAG: Mandatory User Plane Integrity for 5G","source":"GSMA FSAG","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"1 Background GSMA has been made aware through its 'Coordinated Vulnerability Disclosure Programme' about new research on layer-2 attack scenarios against LTE. The research has been published at [1] and will be presented on the security conference NDSS [2] end of February 2020. 2 Item for Consideration 2.1 Abstract from the Research Paper The key findings of the research are copied from the research paper's abstract below: 'Long Term Evolution (LTE\/4G) establishes mutual authentication with a provably secure Authentication and Key Agreement (AKA) protocol on layer three of the network stack. Permanent integrity protection of the control plane safeguards the traffic against manipulations. However, missing integrity protection of the user plane still allows an adversary to manipulate and redirect IP packets, as recently demonstrated. In this work, we introduce a novel cross-layer attack that exploits the existing vulnerability on layer two and extends it with an attack mechanism on layer three. [\u2026] allows an active attacker to impersonate a user towards the network and vice versa; we name these attacks IMP4GT (IMPersonation attacks in 4G neTworks). In contrast to a simple redirection attack as demonstrated in prior work, our attack dramatically extends the possible attack scenarios and thus emphasizes the need for user-plane integrity protection in mobile communication standards.' 2.2 Observations from GSMA It is essential for security of 5G cellular networks that the 3GPP standards mandate support of user plane integrity protection at the full data rate of a UE. The new IMP4GT attacks exploit the same underlying issue as the earlier work described in [3], which was reported to 3GPP in 2018 [4]. GSMA gave 3GPP advance notice of the IMP4GT research in May 2019 [7]. The researchers executed the IMP4GT attacks in an LTE environment, but indicate that the same attack would in principle also work against 5G (UEs using NR connected to the 5GC) unless User Plane integrity protection is in place. It is GSMA's understanding of the current work in SA WG3 that a 5G 'standalone' SA network with NR radio connected to a 5G Core Network would support User Plane integrity protection, and thus could be immune against IMP4GT and similar attacks. The only aspect that remains unclear is the current implementation status of UEs, because [5] and [6] only mandate that UEs support a data rate of 64 kbps with integrity protection, while user plane integrity protection with full data rate is an optional UE feature. GSMA can only confirm the researcher's statement in the abstract: 'We emphasize the requirement for a mandatory and full-rate integrity protection for all 5G data connections to prevent IMP4GT' Even though the new attacks may have limited impact in real-world deployments, there is the need to strengthen the security of 5G networks and UEs for the future. It is essential to not create a large legacy of 5G networks and UEs that are vulnerable to such attacks. At this point in time no wide scale commercial penetration of \u00ab standalone \u00bb SA supporting terminals is in the market, hence it is now the right point in time to mandate this UE functionality. 3 Action: GSMA politely requests SA\/RAN\/CT to ask the affected working groups to agree the necessary CRs in the appropriate release to have mandatory support of full-rate user plane integrity protection for all UEs supporting NR connected to the 5GC. 3.1 Deadline GSMA would appreciate a response following the plenary meetings in March 2020.","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-03-26 10:57:37","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, TSG RAN, TSG CT, RAN WG2, SA WG3, CT WG1, SA WG2","Cc":"","lsoriginalls":"FSAG#79_002","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002631.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002635","title":"LS from CT WG1: Reply LS on configured NSSAI handling","source":"CT WG1","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 would like to thank SA WG2 for the further feedback on the LS from CT WG1 (C1-199063\/S2-2000024). In the LS (S2-2001110\/C1-200234) from SA WG2 the following description is included. Text from S2-2001110\/C1-200234 {...} The text (in red) in C1-199063\/S2-2000024 quoted by S2-2001110\/C1-200234 is about Rel-15 operation, which, of course, is restrictive and is not in line with the referenced Rel-16 CR. Text from C1-199063\/S2-2000024 {...}. Action: CT WG1 kindly asks SA WG2 to take the above into account.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10270,"status":"noted","reservation_date":"2020-03-26 10:57:37","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"C1-200718","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002635.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002637","title":"LS from CT WG1: Reply LS on Non-UE N2 Message Services Operations","source":"CT WG1","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 thanks SA WG2 for informing CT WG1 of the discussion and decision on documentation of Non-UE N2 Message Service operations - NonUeN2MessageTransfer, NonUeN2InfoSubscribe, NonUeN2InfoUnSubscribe, NonUeN2InfoNotify belonging to Namf_Communication service. CT WG1 agrees that duplicated documentation should be avoided, and therefore CT WG1 intends to address this issue in the Rel-16 version of TS 23.041 as recommended by SA WG2 in a future meeting. Action: CT WG1 asks SA WG2 to take the information provided above into account.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10280,"status":"postponed","reservation_date":"2020-03-26 10:57:37","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"S2-2003525","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG4","lsoriginalls":"C1-200889","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002637.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002652","title":"LS from CT WG4: LS on subscribe\/notify for 5G Steering of Roaming","source":"CT WG4","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"CT WG4 is currently specifying stage 3 aspects of SOR-AF NF and 5G dynamic Steering of Roaming under the WI 'NSORAF'. In this sense, the question of the need to define the subscribe\/notify scheme for roaming scenarios as defined in Annex C of 3GPP\u00b0TS\u00b023.122 has been raised, mainly with regards to the recent definition of the relevant indicators (cf. extract from clause 4.2.2.2.2 of 3GPP\u00b0TS\u00b023.502 below) to enable the sending of SoR information during every registration procedure for which the registration type is 'INITIAL REGISTRATION' (or 'EMERGENCY REGISTRATION'). {...} CT WG4 has therefore the following questions: Q1. Focusing on the roaming scenarios, is this subscribe\/notify scheme needed given the recent changes (definition of indicators) that enable the sending of SoR information during each registration procedure of type 'INITIAL REGISTRATION' (or 'EMERGENCY REGISTRATION')? Q2. Is this subscribe\/notify scheme also linked to the HPLMN use case, i.e. enable the sending\/update of SoR information when the UE is in its HPLMN? Is it planned to specify this HPLMN use case? As an alternative to the subscribe\/notify scheme, is the solution reusing the Nudm_ParameterProvision service as described in C4-200474 which allows the SOR-AF to update the UDM with steering information at any time acceptable to CT WG1? In addition to the above questions\/points, CT WG4 would also like to have a clear feedback on the following topic: Q3. With regards to the 'RAT Type' and 'Access Type' parameters that are considered in Annex C of 3GPP\u00b0TS\u00b023.122 as input parameters to the Nsoraf_SoR_Obtain request, CT WG4 would like some clarifications on the associated use cases \/ scenarios. Are these parameters intended to be used to filter the answer that is to be provided by the SOR-AF or simply to feed the underlying business logic? For the time being, CT WG4 has decided to not specify these parameters as it may imply that the HPLMN has to update SoR information at the UE each time there is a RAT type change and\/or Access type change.","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-03-26 10:57:38","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1","Cc":"SA WG2","lsoriginalls":"C4-201221","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002652.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002654","title":"LS from RAN WG2: Reply LS on CAG definition","source":"RAN WG2","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"RAN WG2 would like to thank SA WG5 for the LS on CAG definition, and would like to provide the following answers: a) How many CAG-identifiers need to be supported by an NG-RAN node supporting CAG? Is it possible for such an NG-RAN node to support more than one CAG list at the same time? RAN WG2: Up to 12 CAG-identifiers can be supported by a cell. In RAN sharing scenarios, RAN WG2 agreed that the total number of networks (PLMN + PNI-NPN with CAG + SNPN) supported by a cell shall not exceed 12. It is not defined in RAN WG2 how many cells can be supported by an NG-RAN node. A cell broadcasts the same CAG list for all UEs. Whether different cells of the same NG-RAN node will broadcast different CAG lists can be left to implementation, and will not be reflected in RAN WG2 spec. b) Can an NG-RAN node own CAG cell(s) and normal PLMN cell(s) at the same time? RAN WG2: Yes.","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-03-26 10:57:38","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG5","Cc":"SA WG2, RAN WG3, CT WG4","lsoriginalls":"R2-2001703","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002654.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002657","title":"LS from RAN WG3: Response LS on Enhancing Location Information Reporting with Dual Connectivity","source":"RAN WG3","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 thanks SA WG3-LI for the LS on Enhancing Location Information Reporting with Dual Connectivity. RAN WG3 has discussed the request and decided to agree the needed changes for S1AP and NGAP, as requested (please, see attached CRs).","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-03-26 10:57:38","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3LI","Cc":"SA WG2, SA WG3, ETSI TCLI","lsoriginalls":"R3-201249","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002657.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002664","title":"LS from 3GPP Rel16: Reply LS on analytics support for energy saving","source":"3GPP Rel16","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 thanks TSG SA for their Liaison Statement on 'analytics support for energy saving'. SA WG5 would like to inform SA and SA WG2 that our Rel-16 work item 'Energy efficiency of 5G' is about to be completed. The EE KPI and related performance measurements have been defined for NG-RAN as well as energy saving management use cases, requirements and information model. SA WG5 understands that the questions from SA WG2 are related to energy saving in a virtualized 5G core network. SA WG5 thinks that the relevance of virtualized 5GC energy saving use cases and solutions can be assessed when the means exist to measure the corresponding energy efficiency KPI before and after the energy saving functionality has been activated. As the 3GPP management system has the overall network view, the coordination between 5GC energy saving and NG-RAN energy saving needs to be considered from the OA&M aspect. SA WG5 is discussing the objectives of a Release 17 work item on use cases, requirements and solutions, as enhancement of Rel-16 energy efficiency and energy saving in 5G networks. The work includes the following aspects: a) 5GC network functions and b) the case of virtualized network functions. The potential usage of analytics and NWDAF is to be considered, in conjunction with OA&M (incl. MDAS - Management Data Analytics Service) in Rel-17 work. SA WG5 encourages SA WG2 to elaborate further on the description of potential energy saving use cases and solutions for 5GC, involving NWDAF or not, and in relationship with OA&M, and keep SA WG5 updated. To SA WG2: Please consider the information included above in SA WG2 work.","secretary_remarks":"Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"postponed","reservation_date":"2020-03-26 10:57:38","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"S2-2003532","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG2, SA WG3, SA WG3LI, RAN WG3","lsoriginalls":"S5-201472","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002664.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002666","title":"LS from TSG SA: LS on need for Multi-Path QUIC for ATSSS","source":"TSG SA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"3GPP has approved the study item on 'Study on Access Traffic Steering, Switch and Splitting support in the 5G system architecture Phase 2' as part of Release 17. This study aims to investigate the extension of Rel-16 ATSSS feature enabling the support of steering, switching and splitting the traffic of a PDU session supported over multiple accesses (namely 3GPP and Non-3GPP access), including the following objective: - Whether and how to support additional steering methods(s). Proposed solutions shall be based on IETF protocols or extension of such protocols (i.e. QUIC\/MP-QUIC). Please see attached document for details on study item objectives and timelines. The work on the study has not yet started in 3GPP, and there are thus no agreed conclusions. . The goal is to enable steering, switching and splitting of traffic (primarily UDP) across multiple accesses, including latency sensitive and real time traffic. Therefore 3GPP is interested to receive regular feedback on progress and prioritization on the multipath extensions to QUIC.","secretary_remarks":"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-03-26 10:57:38","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"IETF","Cc":"SA WG2","lsoriginalls":"SP-200289","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002666.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002667","title":"LS from TSG SA: Reply LS to ATIS IoT Group","source":"TSG SA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"TSG SA thanks ATIS for the LS correspondence regarding the LS sent to TSG SA and SA WG2 for review of the ATIS IoT Group whitepaper on IOT Categorisation. TSG SA would like to inform ATIS IoT Group the preferred approach for the handling of the addition of a new SST value in 3GPP TS 23.501 is that ATIS first cooperates with GSMA 5GJA to define the related Standardised Network Slice Type (S-NEST) in PRD NG.116. Then SA WG2 will allocate a new SST when GSMA requests SA WG2 to add a standardised SST value for this S-NEST following the normal working procedures (i.e. approval of necessary CRs).","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"noted","reservation_date":"2020-03-26 10:57:38","uploaded":"2020-03-27 15:57:56","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ATIS IoT Group, GSMA 5GJA","Cc":"SA WG2","lsoriginalls":"SP-200290","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002667.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002703","title":"LS from TCCA: LS on Generic Slice Template with Public Safety Feedback","source":"TCCA (LS on Generic Slice Template)","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"TCCA thanks GSMA for bringing this important topic, the definition of the Generic Slice Template (GST) and Network Slice Type (NEST), to our attention. Public Protection and Disaster Relief (PPDR) network operators have analysed and evaluated the provided document. Please find attached the feedback from this vertical, in the form of a cross-reference table to the attributes discussed with the revised document in the form of labels for each attribute, e.g. 'relevant' or 'not relevant' as well as in some cases as 'duplicate'. In addition, two new attributes provided to the list 'Attributes to be worked on' with the revised document. You also find additional information to several attributes in the form of comments, suggestions for improvements, additional use cases as well as some requests for clarifications. The following organisations support Public Safety services on a 24\/7 basis for around 593 Mio. people and have been involved in the analysis as well as support this feedback: - Federal Agency for Public Safety Digital Radio (BDBOS) in Germany - First Responder Network Authority (FirstNet) in USA - Ministry of State - RENITA in Luxembourg - RIKS (State Infocommunication Foundation) in Republic of Estonia - The Police of the Netherlands - The Swiss Federal Office for Civil Protection (FOCP) - The Norwegian Directorate for Civil Protection (DSB) - The French Ministry of Interior - Erillisverkot in Finland - Norwegian Communications Authority (Nkom) - Home Office of the United Kingdom - A.S.T.R.I.D. S.A. in Belgium. Action: 4: TCCA asks 3GPP kindly to take the feedback provided with the revised document together with the cross-reference table as information.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"noted","reservation_date":"2020-04-07 12:21:51","uploaded":"2020-04-07 12:25:49","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA","Cc":"TSG SA, SA WG1, SA WG2, SA WG3, SA WG5, RAN WG6, RAN WG3","lsoriginalls":"LS on Generic Slice Template","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2002703.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2003006","title":"[DRAFT] LS on Questions on onboarding requirements","source":"Huawei, HiSilicon","contact":"Marco Spini","contact-id":8356,"tdoctype":"LS out","for":"Approval","abstract":"This is the LS reponse to SA WG1 about PNI-NPN on-boarding","secretary_remarks":"Response to S2-2002629 Merged into S2-2003216","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10300,"status":"merged","reservation_date":"2020-04-10 09:04:11","uploaded":"2020-04-10 11:29:19","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_eNPN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"TSG SA, CT WG1, SA WG3, CT WG6","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2003006.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2003104","title":"[DRAFT] Reply LS to SA WG6 on provisioning EDN connection info by ECS","source":"Samsung","contact":"Jicheol Lee","contact-id":51554,"tdoctype":"LS out","for":"Approval","abstract":"Draft Reply LS on provisioning 'EDN connection info' by Edge Configuration Server","secretary_remarks":"Response to S2-2003201. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10340,"status":"postponed","reservation_date":"2020-04-10 12:31:10","uploaded":"2020-04-10 12:56:33","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG6","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2003104.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2003168","title":"[DRAFT] Reply LS on Questions on onboarding requirements","source":"China Mobile","contact":"Dan Wang","contact-id":72661,"tdoctype":"LS out","for":"Approval","abstract":"LS reply to SA WG1","secretary_remarks":"Response, merging S2-2003006, to S2-2002629. e-meeting r03 agreed. Revised to S2-2003216.","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10310,"status":"revised","reservation_date":"2020-04-10 17:35:17","uploaded":"2020-04-10 17:37:25","revisionof":"","revisedto":"S2-2003216","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"TSG SA, CT WG1, SA WG3, CT WG6","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2003168.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2003200","title":"LS from SA WG6: LS on Clarification of the definition of a UAS","source":"SA WG6","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"While working on FS_UASAPP, SA WG6 has discussed the definition of a UAS in TS 22.125 and in TS 23.755. The text in the definition of a UAS and other normative text in TS 22.125 is not aligned with the informative Annex A. Further, it can be noted that there is text in the informative Annex A that is normative. SA WG6 has discussed this and asks SA WG1 group to confirm the definition of a UAS.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"noted","reservation_date":"2020-04-11 13:29:53","uploaded":"2020-04-11 13:30:28","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"SA WG2","lsoriginalls":"S6-200544","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2003200.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2003201","title":"LS from SA WG6: LS on provisioning EDN connection info by Edge Configuration Server","source":"SA WG6","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"SA WG6 defined Service provisioning procedures between the Edge Configuration Server and the Edge Enabler Client as part of the EDGEAPP work. This Figure shows the architecture for enabling edge applications taken from TS 23.558 v0.1.2: As part of the Edge Configuration Server Provisioning response to the Edge Enabler Client, the Edge Configuration Server may provision the Edge Enabler Client with 'EDN connection info' which includes a DNN (or APN). It is SA WG6's understanding that a UE Application may provide a DNN. (TS 23.503 makes the following statement about the DNN field of a Traffic Descriptor: 'This is matched against the DNN information provided by the application.'). Q1: SA WG6 kindly requests that SA WG2 comment on whether SA WG6's understanding that a UE Application may provide a DNN is correct? During SA WG6#36-BIS-e meeting, it was discussed in context of S6-200460 the proposal that 'EDN connection info' also include S-NSSAI and DSCP markings that should be used for the connection with the EAS. It was recognized that in edge scenarios a potential conflict may arise between what is indicated in the EDN connection info and the URSP rules provided. SA WG6 is aware that use of provisioning or configuration of URSP rules is optional by the operator. TS 23.503 also states: 'The ANDSP and URSP may be pre-configured in the UE or may be provisioned to UE from PCF.' SA WG6 thinks that it is necessary to provision the Edge Enabler Client with Data Network Connectivity information in case URSP rules, ANDSP rules or UE local configuration are not configured or provisioned. SA WG6 is seeking advice from SA WG2 on how to handle the scenario when parameters provisioned by Edge Configuration Server create a conflict with URSP rules, ANDSP rules or UE local configuration. Q2: SA WG6 kindly requests that SA WG2 comment on how to handle the scenario when parameters provisioned by Edge Configuration Server create a conflict with URSP rules, ANDSP rules or UE local configuration? Q3: SA WG6 kindly requests that SA WG2 comment on whether S-NSSAI can be provisioned by 3rd party via the application layer? Action: SA WG6 kindly asks SA WG2 to answer the above questions.","secretary_remarks":"Response drafted in S2-2003104. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10330,"status":"postponed","reservation_date":"2020-04-11 13:29:53","uploaded":"2020-04-11 13:30:28","revisionof":"","revisedto":"S2-2003534","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S6-200617","lsreply":"S2-2004114","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2003201.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2003202","title":"LS from SA WG6: LS on Clarification of requirements for UAS application enablement","source":"SA WG6","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"As part of the work on FS_UASAPP, SA WG6 has discussed potential key issues on: - Whether and how to enable flight route support in 3GPP network - Whether and how to control a UAV fly route under 3GPP network - Whether and how to enable NOTAM\/TFR support under 3GPP network, see references: FAA NOTAM: https:\/\/notams.aim.faa.gov\/notamSearch\/nsapp.html#\/ FAA TFR: https:\/\/tfr.faa.gov\/tfr2\/list.html This has caused discussions in SA WG6 on the division between functionality within the realm of the UAS application enablement layer to be specified by SA WG6 versus the UAS application itself (which is out of 3GPP scope). Further, some of the parameters listed in requirements [R-5.1-003] and [R-5.1-004] in subclause 5.1 of TS 22.125 V17.1.0 are considered more related to the UAS application itself than to the application enablement layer. [R-5.1-003] The 3GPP system shall enable a UAS to send UTM the UAV data which can contain: unique identity (this may be a 3GPP identity), UE capability of the UAV, make & model, serial number, take-off weight, position, owner identity, owner address, owner contact details, owner certification, take-off location, mission type, route data, operating status. [R-5.1-004] The 3GPP system shall enable a UAS to send UTM the UAV controller data which can contain: unique identity (this may be a 3GPP identity), UE capability of the UAV controller, position, owner identity, owner address, owner contact details, owner certification, UAV operator identity, UAV operator license, UAV operator certification, UAV pilot identity, UAV pilot license, UAV pilot certification and flight plan.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"noted","reservation_date":"2020-04-11 13:29:53","uploaded":"2020-04-11 13:30:28","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1","Cc":"SA WG2","lsoriginalls":"S6-200620","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2003202.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2003216","title":"Reply LS on Questions on onboarding requirements","source":"SA WG2","contact":"Dan Wang","contact-id":72661,"tdoctype":"LS out","for":"Approval","abstract":"To: SA WG1. CC: SA, CT WG1, SA WG3, CT WG6","secretary_remarks":"Revision of S2-2003168, merging S2-2003006. 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-04-27 09:06:41","uploaded":"2020-04-28 06:57:51","revisionof":"S2-2003168","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"FS_eNPN"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"S2-2002629","lsto":"SA WG1","Cc":"TSG SA, CT WG1, SA WG3, CT WG6","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_138e_Electronic\/Docs\/S2-2003216.zip","group":"S2","meeting":"S2-ah-35701","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]