[{"name":"S2-2001777","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-2000025 from S2#136AH. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10060,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"S2-2000025","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"SA WG3, SA WG5","lsoriginalls":"S6-192399","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2001777.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001779","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-2000038 from S2#136AH. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10070,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"S2-2000038","revisedto":"","release":"Rel-16","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_137e_Electronic\/Docs\/S2-2001779.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001780","title":"LS from RAN WG2: LS on inter-RAT HO from SA to EN-DC","source":"RAN WG2","contact":"Ting Zhang","contact-id":70189,"tdoctype":"LS in","for":"Information","abstract":"RAN WG2 discussed the support of inter-RAT HO from NR SA to EN-DC in Rel-16 and agreed that: - The NR SA to EN-DC handover shall be supported in Rel-16 - Assume a new UE capability is needed RAN WG2 kindly asks all the involved groups to take above RAN WG2 decisions into account and update specifications accordingly if any.","secretary_remarks":"Postponed S2-2000039 from S2#136AH. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10200,"status":"noted","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"S2-2000039","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, RAN WG4","Cc":"SA WG2, CT WG1","lsoriginalls":"R2-1916600","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2001780.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001781","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-2000040 from S2#136AH. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10080,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"S2-2000040","revisedto":"","release":"Rel-16","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_137e_Electronic\/Docs\/S2-2001781.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001783","title":"LS from SA WG1: Reply LS on 5G-SRVCC from NG-RAN to UTRAN for emergency calls","source":"SA WG1","contact":"Betsy Covell","contact-id":68109,"tdoctype":"LS in","for":"Action","abstract":"SA WG1 has considered the LS on 5G-SRVCC from NG-RAN to UTRAN for emergency calls from SA WG2 requesting clarification on stage 1 requirements related to the support of emergency voice service continuity from NG-RAN to UTRAN CS. SA WG1 has the following response. TS 22.261 clause 5.1.2.2 includes the following requirement regarding 5G-SRVCC from NG-RAN to UTRAN: Voice service continuity from NG-RAN to UTRAN CS should be supported (see Note), NOTE: Architectural or protocol changes needed to support voice service continuity from NG-RAN to UTRAN CS are expected to have minimum impact on architecture, specifications, or the development of the 5G New Core and New Radio. Therefore, the requirement is clear that SA WG2 should consider whether voice service continuity from NG-RAN to UTRAN CS, including emergency voice calls, can be supported with minimal impact to the 5G systems (core and RAN). Action: SA WG1 requests SA WG2 to take the above into account in their work.","secretary_remarks":"Postponed S2-2000047 from S2#136AH. This was discussed at the previous meeting and no response was needed and this was 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-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"S2-2000047","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA","lsoriginalls":"S1-193593","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2001783.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001785","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-2000063 from S2#136AH. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10150,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"S2-2000063","revisedto":"","release":"Rel-16","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_137e_Electronic\/Docs\/S2-2001785.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001786","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-2000947 from S2#136AH. Response drafted in S2-2001988. Postponed","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10170,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"S2-2000947","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_137e_Electronic\/Docs\/S2-2001786.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001787","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10090,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"","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_137e_Electronic\/Docs\/S2-2001787.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001788","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10100,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"","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_137e_Electronic\/Docs\/S2-2001788.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001790","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10110,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"","revisedto":"","release":"Rel-17","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_137e_Electronic\/Docs\/S2-2001790.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001791","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10120,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"","revisedto":"","release":"Rel-17","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_137e_Electronic\/Docs\/S2-2001791.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001792","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10130,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 08:39:25","revisionof":"","revisedto":"","release":"Rel-17","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_137e_Electronic\/Docs\/S2-2001792.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001795","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10140,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-05 14:23:01","revisionof":"","revisedto":"","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_137e_Electronic\/Docs\/S2-2001795.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001796","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10160,"status":"postponed","reservation_date":"2020-02-05 08:38:29","uploaded":"2020-02-06 17:09:28","revisionof":"","revisedto":"","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_137e_Electronic\/Docs\/S2-2001796.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2001988","title":"Reply LS Correspondence from ATIS to SA WG2 Regarding a Slice Service Type","source":"Qualcomm Incorporated","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS out","for":"Approval","abstract":"LS response for the correspondence from ATIS to SA WG2 regarding a Slice Service Type","secretary_remarks":"Response to S2-2001786. Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10180,"status":"noted","reservation_date":"2020-02-17 11:14:44","uploaded":"2020-02-18 18:48:04","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":[{"winame":"TEI17"}],"crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ATIS, GSMA 5GJA","Cc":"TSG SA","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2001988.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002095","title":"Support of inter-RAT HO from NR SA to EN-DC","source":"NTT DOCOMO","contact":"Atsushi Minokuchi","contact-id":26474,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: AMF sets UE's subscription data related to Secondary RAT, which would apply to the UE when the UE is under EPC, into the MM context in the Forward Relocation request message. - Other clarification is also added: AMF sets S1 UE capability into the MM context in the Forward Relocation request message. - Alignment to RAN spec is also added: NG RAN sets an indication in the Source to Target Transparent Container if the HO is triggered by EPC fallback. (Texts related to emergency fallback already exists.)","secretary_remarks":"Revised to S2-2002551","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10210,"status":"revised","reservation_date":"2020-02-18 06:05:49","uploaded":"2020-02-18 06:16:37","revisionof":"","revisedto":"S2-2002551","release":"Rel-16","crspec":"23.502","crspecversion":"16.3.0","workitem":[{"winame":"TEI16"}],"crnumber":2127.0,"crrevision":"","crcategory":"F","tsg_crp":"","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2002095.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002197","title":"[DRAFT] LS to IETF on Multipath Solution based on QUIC\/MP-QUIC","source":"Deutsche Telekom AG","contact":"Dieter Gludovacz","contact-id":38203,"tdoctype":"LS out","for":"Approval","abstract":"LS to IETF on Multipath Solution based on QUIC\/MP-QUIC to enable IETF to scope and prioritize their work on QUIC\/MP-QUIC","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10190,"status":"noted","reservation_date":"2020-02-18 11:35:43","uploaded":"2020-02-18 17:12:59","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"IETF","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2002197.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002314","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10230,"status":"postponed","reservation_date":"2020-02-21 18:12:13","uploaded":"2020-02-21 18:12:40","revisionof":"","revisedto":"","release":"Rel-16","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_137e_Electronic\/Docs\/S2-2002314.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002315","title":"LS from SA WG1: Reply LS on Data Off applicability to non-3GPP PDU Session and MA PDU Session","source":"SA WG1","contact":"SungDuck Chun","contact-id":84730,"tdoctype":"LS in","for":"Action","abstract":"SA WG1 would like to thank SA WG2 for the LS. Regarding the questions raised by the LS, the responses are: Q1: Should Data Off apply to PDU Sessions transported over non-3GPP access? A1: No. PS Data off is not applicable to PDU Sessions transported over non-3GPP access. Q2: If the answer to Q1 is YES, is it applicable to both EPS and 5GS, or only to 5GS? and starting from which release noting that there may be service incompatibility between different UE releases\/network releases which cannot be completely overcome? A2: See Answer to Q1. Q3: If the answer to Q1 is YES, should Data Off settings for PDU Sessions transported over non-3GPP Access be distinguished from Data Off settings for PDU Sessions transported over 3GPP Access (e.g. due to different billing schemes for non-3GPP Access and 3GPP Access)? A3: See Answer to Q1 Q4: Multi-Access PDU Sessions are PDU Sessions that simultaneously have active User Plane over both 3GPP access and non-3GPP. If the answer to Q1 is NO, should Data Off apply also to the traffic carried over non-3GPP access for such Multi-Access PDU Sessions? A4: Even if PS Data Off is activated, it does not affect the data transport over non-3GPP access. Action: SA WG1 kindly requests SA WG2 to take above into account.","secretary_remarks":"Noted","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10240,"status":"noted","reservation_date":"2020-02-21 18:12:13","uploaded":"2020-02-21 18:12:40","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"","lsoriginalls":"S1-201086","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2002315.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002316","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10250,"status":"postponed","reservation_date":"2020-02-21 18:12:14","uploaded":"2020-02-21 18:12:40","revisionof":"","revisedto":"","release":"Rel-17","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":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2002316.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002317","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","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10260,"status":"postponed","reservation_date":"2020-02-21 18:12:14","uploaded":"2020-02-21 18:12:40","revisionof":"","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_137e_Electronic\/Docs\/S2-2002317.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"S2-2002551","title":"Support of inter-RAT HO from NR SA to EN-DC","source":"NTT DOCOMO","contact":"Atsushi Minokuchi","contact-id":26474,"tdoctype":"CR","for":"Approval","abstract":"Summary of change: AMF may retrieve UE's subscription data related to Secondary RAT, which would apply to the UE when the UE is under EPC, from UDM using secondaryRatRestrictions (see C4-195557(29.503CR0282r1)) and set it in the Forward Relocation request message.","secretary_remarks":"Revision R06 of S2-2002095. Approved","agenda_item_sort_order":5,"ainumber":"4.1","ainame":"Common issues and Incoming LSs","tdoc_agenda_sort_order":10220,"status":"agreed","reservation_date":"2020-02-28 13:24:40","uploaded":"2020-02-29 09:46:34","revisionof":"S2-2002095","revisedto":"","release":"Rel-16","crspec":"23.502","crspecversion":"16.3.0","workitem":[{"winame":"TEI16"}],"crnumber":2127.0,"crrevision":1.0,"crcategory":"F","tsg_crp":"SP-200081","lsreplyto":"","lsto":"","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/WG2_Arch\/TSGS2_137e_Electronic\/Docs\/S2-2002551.zip","group":"S2","meeting":"S2-ah-37776","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]