[{"name":"SP-200003","title":"LS from TSG RAN: LS on Local NR positioning in NG-RAN","source":"TSG RAN","contact":"Tsunehiko Chiba","contact-id":70296,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 has studied the feasibility and specification impact of local LMF (i.e., LMC) in NG-RAN as per the SA WG2 conclusion from the study (Study on Enhancement to the 5GC Location Services, TR 23.731), as well as the RAN WG2 conclusion (Study on NR Positioning Support, TR 38.855). RAN WG3 also concluded as below (see TR 38.856 for more details). RAN WG3 has studied the feasibility and specification impact of local LMF (i.e., LMC) in NG-RAN. Three architecture alternatives have been studied. It is concluded that support of LMC in NG-RAN is feasible Architecture 3 seems like the most promising option among the ones studied. RAN WG3 did not evaluate the benefits of any of the architecture options in terms of latency towards the core network, RAN WG3 also did not fully evaluate, e.g., mobility issues associated with the introduction of the LMC. RAN WG3 could not reach consensus on any recommendation for normative work. RAN discussed LMC, but has not reached consensus on any follow-on work. Questions were raised during the discussion about the benefit and deployment scenario.","secretary_remarks":"Postponed SP-191367 from SP#86. Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10020,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:54","revisionof":"SP-191367","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA, RAN WG2, RAN WG3","lsoriginalls":"RP-193262","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200003.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200004","title":"LS from TSG RAN: LS on 5G indicator","source":"TSG RAN","contact":"Richard Burbidge","contact-id":14160,"tdoctype":"LS in","for":"Information","abstract":"TSG RAN received and discussed the LS from GSMA on 'Requirements for NR carrier frequency mismatch in 5G status indication.' [RP-193053]. In order to implement the requirements from GSMA, RAN concluded the following changes to the E-UTRA RRC specification are required: 1 Introduce signalling to enable a UE camped on an E-UTRA cell to be informed, with frequency band granularity, of the NR frequency bands available for configuration of EN-DC operation within the area of this cell. In the case of RAN sharing, it must be possible to provide the NR frequency bands independently per PLMN. RAN WG2 can involve other groups as necessary to introduce the appropriate signalling. 2 For a UE in RRC Idle (or Inactive), specify that the presence of the upperLayerIndication is only provided to upper layers if the UE supports EN-DC operation for one or more of the indicated frequency bands. 3 For a UE in RRC Connected, specify that the presence or absence of the upperLayerIndication is provided to upper layers depending on whether or not the UE is configured by RRC for EN-DC operation. TSG RAN has decided that further 3GPP work related to the display of any user interface indication, such as hysteresis to avoid toggling between displaying 4G and 5G icon as mentioned in the GSMA LS, is not needed.","secretary_remarks":"Postponed SP-191368 from SP#86. Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10030,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:54","revisionof":"SP-191368","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2","Cc":"TSG SA, TSG CT, GSMA","lsoriginalls":"RP-193265","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200004.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200005","title":"LS from GSMA 5GJA: LS Response to SA WG2 on Clarification of NG.116","source":"GSMA 5GJA","contact":"Sandra Ondrusova","contact-id":77474,"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.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10040,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:54","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\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200005.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200006","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":"Information","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":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10050,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:54","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG1, SA WG2","Cc":"TSG SA, TSG RAN","lsoriginalls":"LS on FAA NPRM for UAV Remote ID","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200006.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200007","title":"LS from ETSI TC MTS: Liaison statement from ETSI MTS on Methodology for RESTful APIs specifications and testing","source":"ETSI TC MTS","contact":"Philip Makedonski","contact-id":53942,"tdoctype":"LS in","for":"Information","abstract":"ETSI TC MTS is pleased to inform all interested parties that an early draft of EG 203 647: 'Methods for Testing and Specification (MTS); Methodology for RESTful APIs specifications and testing' is now available. ETSI TC MTS welcomes and encourages feedback even at this early stage of the deliverable to help ensure that the methodology and guidelines address the needs of all stakeholders at ETSI and its partnership projects with regard to the specification and testing of RESTful APIs. The stable EG 203 647 is expected to be delivered in May 2020, followed by the publication of the final draft at the end of June 2020. As part of the work on EG 203 647, experts within STF 576 conducted a survey on the use of RESTful APIs within ETSI and its partnership projects and the needs of the different stakeholders. The survey results were discussed at a webinar on January 17th and are attached to this liaison Statement. All interested parties are invited to find out more about the status of the work of STF 576 in the Progress report attached to this Liaison Statement: and also follow the latest developments and provide feedback on EG 203 647 by joining the dedicated mailing list at: https:\/\/list.etsi.org\/scripts\/wa.exe?SUBED1=REST&A=1 . Detailed information about the MTS work programme can be found at: https:\/\/portal.etsi.org\/\/tb.aspx?tbid=97&SubTB=97,875,860#\/.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10060,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:54","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ETSI ISG MEC, ETSI ISG NFV, TSG SA, TSG CT, CT WGs, SA WGs, OneM2M, ETSI TC SmartM2M, ETSI ISG CIM, ETSI ISG ZSM, ETSI OSG OSM, ETSI ISG QKD","Cc":"","lsoriginalls":"MTS(20)079038","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200007.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200008","title":"LS from ITU-T SG2: LS on Enhancements of Cell-Broadcast based Public Warning Service over 3GPP Systems","source":"ITU-T SG2","contact":"Philippe Fouquart","contact-id":30010,"tdoctype":"LS in","for":"Information","abstract":"SG2 Q1\/2 would like to thank you for your liaison regarding Enhancements of Cell-Broadcast based Public Warning Service over 3GPP Systems. The following intends to provide answers to the questions you raised. - Does ITU-T SG2 have or have any plans to develop or recommend a set of internationally recognized language-independent contents such as pictograms mapping to disasters that can be compatible with Unicode-based texts and can be included in public warning message? Answer: No. Currently, ITU-T SG2 has no plan to develop new Recommendations for such kind of Public Warning Services including requirements for language-independent contents. - What kind of disasters does ITU-T SG2 take into account for current public warning? In addition, are there any categories of disasters that are not supported by current public warning but need to be notified to the new IoT devices described above? ITU-T SG2 has developed several Recommendations for disaster relief services, such as ITU-T E.108 https:\/\/www.itu.int\/rec\/T-REC-E.108-201601-I and ITU-T E.119 https:\/\/www.itu.int\/rec\/T-REC-E.119-201704-I. However, these Recommendations do not focus on specific types of disasters, although they are developed mostly for natural disasters such as earthquakes and tsunamis. For additional information, ITU-T SG2 also developed a supplement document on 'Framework of disaster management for disaster relief system (E.100SerSup1)' https:\/\/www.itu.int\/ITU-T\/recommendations\/rec.aspx?rec=13896&lang=fr . This supplement describes 'Lead time for early warning systems' and suggests some examples of lead times for some kinds of natural disasters as follows: earthquakes, tornadoes and tsunamis, volcanic eruptions, hurricanes, droughts, El Nino and climate change.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10070,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:54","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"","lsoriginalls":"SG2-LS135","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200008.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200009","title":"LS from ETSI ISG ZSM: Publication of major ZSM specifications","source":"ETSI ISG ZSM","contact":"Nurit Sprecher","contact-id":74414,"tdoctype":"LS in","for":"Information","abstract":"The ETSI ISG Zero-touch network and Service Management (ZSM) would like to inform you of the publication of major ZSM specifications: GS ZSM 001 (ZSM Requirements), GS ZSM 002 (ZSM Reference Architecture) and GS ZSM 007 (ZSM Terminology). In GS ZSM 001, the ZSM ISG examined business-oriented scenarios and the related automation challenges faced by telecom operators and vertical industries. Subsequently, the ISG specified the architectural, functional and operational requirements for end-to-end network and service automation. The ZSM reference architecture specified in GS ZSM 002 was developed to satisfy these requirements. The architecture harnesses modular, flexible, scalable, extensible and service-based properties. It is designed to support advanced, data-driven automation based on closed-loop and integration of AI\/ML techniques. The published specifications are publicly available at Link to Specifications. The ETSI ISG ZSM is currently working on the specification of solutions and management interfaces for the orchestration and automation of the emerging end-to-end network slicing technology (GS ZSM003) as well as of the end-to-end, cross-domain service orchestration and automation (GS ZSM008). Recently, the group has started work on specifying solutions for closed-loop automation. Specifically, the ISG works on generic enablers for closed-loop automation (GS ZSM009-1), solutions to closed-loop automation use cases (GS ZSM009-2), and investigation of advanced topics for next generation closed-loop operations (GR ZSM 009-3). In addition, the group is studying security aspects related to the ZSM framework and solutions (GR ZSM010), which include identifying potential security threats and mitigation options to be considered by the ZSM specifications to ensure that the automated processes are secured automatically and deliver the intended business outcomes. All the draft specifications are available via the ZSM open area (Link). The ETSI ISG ZSM invites you to study these specifications and consider them in your technical work. The ISG looks forward towards close and fruitful cooperation to achieve alignment, leverage synergies and ensure that end-to-end automation can be efficiently and consistently achieved.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10080,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:54","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG5, ORAN Alliance, BBF, ETSI ISG MEC, ETSI ISG NFV, ETSI ISG SAI, OASIS, DMTF, IETF OPS, IETF TEAS WG, ONF, ITU-T SG 15, MEF, TMF, ITU-T SG 13, NGMN, GSMA, ETSI TC INT, ETSI ISG ENI, IRTF NMRG","Cc":"TSG SA","lsoriginalls":"ZSM(19)000687r2","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200009.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200010","title":"LS from SA WG2: Reply LS to 'new task group named 5G Intelligent Network Architecture and Use Case'","source":"SA WG2","contact":"Aihua Li","contact-id":58162,"tdoctype":"LS in","for":"Information","abstract":"SA WG2 thanks Artificial Intelligence Industry Alliance (AIIA) for their Liaison Statement on 'new task group named 5G Intelligent Network Architecture and Use Case'. SA WG2 welcomes further information on AIIA. 3GPP has a well-defined process and successful track record in delivering global standards to meet market requirements for multivendor interoperation (see http:\/\/www.3gpp.org\/about-3gpp\/about-3gpp). SA WG2 will consider input from AIIA if submitted via 3GPP individual members in accordance with 3GPP working procedures.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10090,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:54","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"AIIA","Cc":"TSG SA","lsoriginalls":"S2-2001293","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200010.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200013","title":"LS from SA WG2: Reply LS to LS S3-194452 on UP gateway function on the N9 interface","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":72921,"tdoctype":"LS in","for":"Information","abstract":"SA WG2 thanks SA WG3 for their Reply LS on UP gateway function on the N9 interface in S3-194452. SA WG2 agreed to the attached CR. When referring to SA WG3 TS 33.501, requirements for User Plane Gateway Function (UPGF) include: '- The UPGF shall only forward valid GTP-U packets on the N9 interface to the concerned UPF.' The above requirement bullet indicates that the IPUPS functionality (called UPGF in current SA WG3 spec) supports 'GTP-u packet filtering'. However, it is unclear to SA WG2 what information a UPF that supports the IPUPS functionality needs from SMF to achieve this 'GTP-u packet filtering'.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10100,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:55","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"CT WG4, TSG SA","lsoriginalls":"S2-2001727","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200013.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200014","title":"LS from SA WG2: Questions on onboarding requirements","source":"SA WG2","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS in","for":"Information","abstract":"SA WG2 has started working on the study on enhanced support of non-public networks. Based on service requirements documented in clause 5.1 of TS 22.263, SA WG2 developed key issue #4: UE Onboarding and remote provisioning in TR 23.700-07. SA WG2 started working on solutions for this key issue and is looking for clarification on the interpretation of the term: 'non-3GPP identities and credentials' documented in the following service requirement in TS 22.263: 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. 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 SA WG2 would like to emphasise that use of (a) above is explicitly supported and (b) is not precluded by SA WG2 specifications for SNPNs. 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. 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.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10110,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:55","revisionof":"","revisedto":"","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":"S2-2001729","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200014.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200015","title":"LS from SA WG2: LS on AMF Reallocation via RAN re-routing","source":"SA WG2","contact":"Patrice H\u00e9d\u00e9","contact-id":25646,"tdoctype":"LS in","for":"Information","abstract":"SA WG2 has discussed further on the issue of AMF reallocation via RAN re-routing in the context of network slice isolation. A number of proposals for Rel-16 have been submitted to SA WG2#136ah, but SA WG2 could not reach consensus on any of these proposals: - One alternative was proposing to reject the UE Registration request while still providing the Allowed NSSAI, and ask the UE to re-register, overriding for this re-registration the privacy setting for the NSSAI (i.e. the UE shall send the NSSAI in Access Stratum independently of the setting of the Access Stratum Connection Establishment NSSAI Inclusion Mode) and using the SUCI. Concerns were expressed about the such inclusion of the NSSAI in the clear in RRC signalling even when the NSSAI Inclusion mode could indicate it should not be included, thus temporarily infringing the NSSAI privacy, for the benefit of accessing the right AMF set when the UE re-registers In addition, this proposal impacts the UE. - Another alternative was proposing to re-purpose the NSSF to act as a 'well-connected NF' to provide parts of the UE context between initial and target AMF, including the NAS security context. Concerns were expressed about the level of achievement on network slice isolation, considering that the AMF of the network slice is not properly isolated from the rest of the network, because the AMF can still be reached from AMFs belonging to other slices. In addition, this proposal modifies the functionality of the NSSF. - Alternatively, the existing Rel-15 architecture allows to purpose certain AMFs to act as 'well-connected NF' within the network and configure the RAN to select them as initial AMF (list of default AMFs) when not enough information is available to route directly the request to the proper target AMF, avoiding the problem in the first place when initial AMF is such 'well-connected-NF'. Concerns were expressed about the level of achievement on network slice isolation, considering that the AMF of the network slice is not properly isolated from the rest of the network, because the AMF can still be reached from AMFs belonging to at least some other slices which need to have N14 connectivity with this isolated slice, and that this might not address some cases when the UE requests change of network slices that leads to change of AMF. During the work on eNS in Rel-16, network slice isolation was considered in the context of a UE not being able to use simultaneously network slices that are isolated from each other (but not necessarily isolated against all other network slices or NFs), whereas the context of the discussion here some companies consider network slice isolation to be preventing any signalling between AMFs belonging each to slices isolated from each other, and even more, isolated from any NF not belonging to the network slice. SA WG2 lacks clarity regarding what network slice isolation is really expected to mean from SA WG3 angle and the impacts on the selection of a solution for AMF Reallocation. For instance, why is it important to avoid support of N14 (AMF-AMF interactions) for network slice isolation? Which security threat is avoided by removing the support of N14 within a PLMN? Would privacy loss be acceptable for the benefit of accessing directly the right AMF? SA WG2 invites SA WG3 to provide definition of the necessary isolation requirements from SA WG3 perspective and the security aspects or solutions that SA WG2 needs to take into account, and for feedback on the scenarios where network slice isolation takes place in a PLMN, and the security impacts that derive from it. Other proposals to resolve the issue are also welcome.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10120,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:55","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"TSG SA","lsoriginalls":"S2-2001730","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200015.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200016","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":84572,"tdoctype":"LS in","for":"Information","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.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10130,"status":"noted","reservation_date":"2020-02-26 15:11:19","uploaded":"2020-02-26 15:13:55","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\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200016.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200017","title":"LS from ITU-R WP 5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ON THE SCHEDULE FOR UPDATING RECOMMENDATION ITU-R M.2012 TO REVISION 5","source":"ITU-R WP 5D","contact":"Sergio Buonomo","contact-id":79388,"tdoctype":"LS in","for":"Information","abstract":"Introduction Working Party (WP) 5D thanks the relevant External Organizations for their successful work in regards to completion of the Revision 4 of Recommendation ITU-R M.2012 - 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications-Advanced (IMT-Advanced)' which will be available as a published ITU-R Recommendation. WP 5D wishes to inform the relevant External Organizations that it is commencing the cycle for the development of the Revision 5 of Recommendation ITU-R M.2012 and provides a detailed schedule for Revision 5 of Recommendation ITU R M.2012. Background This liaison provides guidance to External Organizations regarding updates of the terrestrial radio interfaces in the development of Revision 5 of Recommendation ITU-R M.2012 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications-Advanced (IMT-Advanced)'. Confirmed meeting dates of WP 5D for 2020 and 2021 will be published on the ITU website (http:\/\/www.itu.int\/events\/upcomingevents.asp?sector=ITU-R&lang=en). Procedure The procedure outlined in document IMT-ADV\/25(Rev.2) Procedure for the development of draft revisions of Recommendation ITU-R M.2012 applies to the development of this Revision 5. Schedule For the Revision 5 of Recommendation ITU-R M.2012 a completion date of the WP 5D meeting #39, currently planned for October 2021, has been chosen. WP 5D announces that the first formal meeting in the meeting cycle ('Meeting Y') of the development of Revision 5 of Recommendation ITU-R M.2012 will be WP 5D meeting #35, which is scheduled for 23 June - 1 July 2020. It should be noted that the contribution deadline for WP 5D meeting #35 is also the cut-off date for the submission of new candidate RIT and SRIT proposals for inclusion in Revision 5. The detailed timeline for the Revision 5 of Recommendation ITU-R M.2012 which accommodates the currently planned\/anticipated schedule of meetings for WP 5D and Study Group 5 through the 2020 and 2021 time frame and some milestone activities\/actions may be found in Document IMT-ADV\/31 'Schedule for Revision 5 of Recommendation ITU-R M.2012'. The dates in Document IMT-ADV\/31 were developed considering not only the WP 5D and Study Group 5 dates but also with a view towards coordinating with the understood planned dates of the relevant External Organizations to the extent they were known. Some adjustment of these dates might be required to accommodate availability of facilities at specific venues in conjunction with the scheduling of the ITU-R WP 5D and Study Group 5 meetings. Every effort will be made to keep these dates as listed. Please check the ITU website in case meeting details have changed (http:\/\/www.itu.int\/events\/monthlyagenda.asp?lang=en). As appropriate Document IMT-ADV\/31 will be updated to accommodate such date changes and further correspondence with the External Organization could be forthcoming throughout the update cycle as warranted by the circumstances. External Organizations are encouraged to consult the ITU-R IMT-Advanced web page (http:\/\/www.itu.int\/ITU-R\/go\/rsg5-imt-advanced\/) which may be updated dynamically to provide additional information. WP 5D looks forward to the continued cooperation with the External Organizations in the on-going work on the IMT-Advanced terrestrial radio interfaces.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10140,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"External Organizations","Cc":"","lsoriginalls":"5D_TD_39e_IMT-ADV","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200017.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200018","title":"LS from ITU-R WP 5D: LIAISON STATEMENT TO POTENTIAL GCS\/DIS PROPONENTS ON THE REQUEST TO SUBMIT THE MATERIALS FOR THE FIRST RELEASE OF NEW RECOMMENDATION ITU-R M.[IMT-2020.SPECS","source":"ITU-R WP 5D","contact":"Sergio Buonomo","contact-id":79388,"tdoctype":"LS in","for":"Information","abstract":"Introduction ITU-R Working Party 5D (WP 5D) thanks the relevant External Organizations for their work regarding the submissions for IMT-2020 under Step 3 of the IMT-2020 development process. WP 5D informed the relevant External Organizations of the detailed schedule for finalization of the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] in the previous liaison with two IMT-2020 Documents (IMT-2020\/20, IMT-2020\/21). Background Working Party 5D (WP 5D) thanks the relevant External Organizations (RIT\/SRIT Proponents) for submitting Form A Document. WP 5D recognizes that potential GCS Proponent of each candidate RIT or SRIT is as following: IMT-2020 document number RIT\/ SRIT Potential GCS Proponent GCS \/DIS style RIT\/SRIT Proponent(s) 1 IMT-2020\/13 SRIT ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC GCS 3GPP Proponent 2 IMT-2020\/14 RIT ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC GCS 3GPP Proponent 3 IMT-2020\/15 RIT CCSA GCS China 4 IMT-2020\/16 RIT TTA GCS Korea 5 IMT-2020\/17 Rev.1 SRIT ETSI GCS DECT Forum, ETSI 6 IMT-2020\/18 Rev.1 RIT Nufront DIS Nufront 7 IMT-2020\/19 Rev.1 RIT TSDSI GCS TSDSI WP 5D recognizes that the IMT-2020 development process is still under Steps 5, 6 and 7 and has completed evaluating the candidate RIT and SRIT proposals in 34th meeting of WP 5D; and is considering of evaluation results, consensus building and decision. RIT(s)\/SRIT(s) for inclusion in the standardization phase (Step 8) will be decided formally at the 35th meeting of WP 5D. However, due to the tight schedule for developing the new Recommendation, WP 5D needs to take accelerate actions for the first release of the new Recommendation as indicated in Document IMT 2020\/21. Requests for Action: WP 5D kindly requests the relevant External Organizations (potential GCS Proponent(s)) to submit package of GCS list, Certification B (Annex 2 of IMT-2020\/20) and the texts for Overview section to the 35th meeting (23 June-1 July 2020). If the relevant External Organization (potential GCS Proponent) decides to employ DIS style, it doesn't need to submit GCS list but needs to submit full materials for describing its RIT\/SRIT in the Recommendation and Certification B at 35th meeting. For convenience, the working document towards preliminary draft New Recommendation ITU-R M.[IMT-2020.SPECS] is enclosed to this liaison as Attachment. Please refer to Annex X for GCS utilized style and Annex Y for DIS style when developing the texts for Overview section or full materials for describing its RIT\/SRIT in the Recommendation. WP 5D also kindly encourage the potential GCS Proponents to start consensus building in Step 7 for achieving global harmonization and having the potential for wide industry support for the radio interfaces that are developed for IMT-2020. This may include grouping of RITs or modifications to RITs to create SRITs that better meet the objectives of IMT-2020. When potential GCS Proponents agreed to consolidate their RITs\/SRITs as a result of consensus building (Step 7), one of the potential GCS Proponents needs to submit above requested materials and the other potential GCS Proponent(s) needs to input following information instead of those materials as reply: - Consolidated RIT\/SRIT numbers (e.g. RIT\/SRIT Proposal (IMT-2020\/a) is consolidated with RIT\/SRIT Proposal (IMT-2020\/b)) - GCS Proponent member list of consolidated RIT\/SRIT if GCS Proponent member added. The Cut-off day for submissions for 35th meeting is 16 June 2020. WP 5D looks forward to the continued cooperation with the External Organizations in the on-going work on the IMT-2020 terrestrial radio interfaces.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10150,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"POTENTIAL GCS\/DIS PROPONENTS","Cc":"3GPP, Republic of Korea, People's Republic of China, DECT Forum","lsoriginalls":"5D_TD_42e_IMT-2020","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200018.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200022","title":"LS from CT WG1: Reply LS on general status of work","source":"CT WG1","contact":"Ivo Sedlacek","contact-id":78448,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 would like to thank Broadband Forum for the LS (LIAISE-363\/C1-200211) on General Status of Work. Broadband Forum's LS states: ----------------- 5) We are looking to complete protocol work for the support of NAS exchange across Y4. We would like 3GPP to confirm that the maximum length of a NAS message can exceed 1490 bytes, to assist us in finalizing the design. ----------------- CT WG1 confirms that the maximum length of a NAS message can exceed 1490 bytes. NOTE: E.g. SUCI contained in a NAS message can be longer than 3000 octets, according to TS 33.501.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10160,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"Broadband Forum","Cc":"TSG SA, SA WG2, RAN WG3","lsoriginalls":"C1-200309","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200022.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200023","title":"LS from CT WG1: Reply LS on Rel-16 NB-IoT enhancements","source":"CT WG1","contact":"Mikael Wass","contact-id":42217,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 thanks SA WG2 for their LS on 'Reply LS on Rel-16 NB-IoT enhancements'. CT WG1 has discussed the NAS impacts of both options provided by SA WG2 and would like to provide the following feedback: - Both options are feasible from the NAS protocol perspective. Additionally, CT WG1 would like to receive feedback on the following questions to decide the NAS part of the solution to pursue: - Question to RAN WG2: What values shall be supported for UE specific DRX for NB-IoT? - Question to RAN WG3: When the UE is accessing via NB-IoT, is the legacy MME is mandated to provide the stored UE specific DRX value, that was requested by the UE over NAS, in the S1 paging message to the eNB?","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10170,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2, RAN WG3, SA WG2","Cc":"TSG CT, TSG RAN, TSG SA","lsoriginalls":"C1-201024","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200023.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200025","title":"LS from CT WG1: LS on Unicode symbol numbers representing disasters","source":"CT WG1","contact":"Hyounhee Koo","contact-id":65247,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 would like to inform ISO\/IEC JTC1\/SC2 of recent 3GPP work on the enhancements of Public Warning Service (ePWS) for 5G. One of objectives in 3GPP work on ePWS aims to improve the comprehension of text-based warning messages for users not literate in the local languages. Following provides links to the relevant 3GPP technical reports\/technical specifications related to 3GPP work on ePWS. - 3GPP Stage 1 TR 22.869 V16.1.0 http:\/\/www.3gpp.org\/ftp\/\/Specs\/archive\/22_series\/22.869\/22869-g10.zip - 3GPP Release 16 Stage 1 TS 22.268 V16.3.0 http:\/\/www.3gpp.org\/ftp\/\/Specs\/archive\/22_series\/22.268\/22268-g30.zip - 3GPP TR 23.735 V16.0.0 http:\/\/www.3gpp.org\/ftp\/\/Specs\/archive\/23_series\/23.735\/23735-g00.zip - 3GPP Stage 2 23.041 V16.2.0 http:\/\/www.3gpp.org\/ftp\/\/Specs\/archive\/23_series\/23.041\/23041-g20.zip CT WG1 kindly asks ISO\/IEC JTC1\/SC2 the following questions related to the recent 3GPP work on ePWS: Question 1. CT WG1 would like to ask ISO\/IEC JTC1\/SC2 to provide what Unicode symbols defined in ISO\/IEC 10646 are possible to be recommended as language-independent contents such as pictograms mapping to disasters (earthquake, tsunami, fire, flood, typhoon, hurricane, cyclone, tornado, volcanic eruption, epidemic and chemical hazard) that can be compatible with Unicode-based texts and can be included in public warning message. Question 2. If there are no proper Unicode symbols recommendable for the ePWS purpose to address the language issue existed in text-based warning messages in ISO\/IEC 10646, CT WG1 would like to request ISO\/IEC JTC1\/SC2 the standardization of Unicode-based language-independent contents representing earthquake, tsunami, fire, flood, typhoon, hurricane, cyclone, tornado, volcanic eruption, epidemic and chemical hazard.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10180,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ISO\/IEC JTC1\/SC2","Cc":"TSG CT, TSG SA","lsoriginalls":"C1-201043","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200025.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200026","title":"LS from RAN WG3: Reply LS on Rel-16 NB-IoT enhancements","source":"RAN WG3","contact":"Yan Wang","contact-id":72295,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 thanks SA WG2 for the LS 'Reply LS on Rel-16 NB-IoT enhancements'. RAN WG3 has discussed how to support UE specific DRX for NB-IoT in both EPS and 5GS in RAN WG3 specifications. RAN WG3 would like to provide the following feedback: From RAN WG3 point of view, both options are feasible and have same potential RAN WG3 specification impact.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10190,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, TSG RAN, TSG CT, RAN WG2, CT WG1","Cc":"TSG SA","lsoriginalls":"R3-201417","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200026.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200027","title":"LS from ITU-R WP 5D: Availability of Addendum 5 to Circular Letter 5\/LCCE\/59","source":"ITU-R WP 5D","contact":"Sergio Buonomo","contact-id":79388,"tdoctype":"LS in","for":"Information","abstract":"ITU-R has commenced the process of developing ITU-R Recommendations for the terrestrial components of the IMT-2020 radio interface(s). The invitation for submission of proposals for candidate radio interface technologies for the terrestrial components of IMT-2020 was issued in Circular Letter 5\/LCCE\/59 by ITU-R on 22 March 2016. Following the first invitation, four addenda have been issued to provide further information on the availability of related IMT-2020 documents, Reports, and workshop. These addenda can be found at the same web page as Circular Letter 5\/LCCE\/59. During its 33nd meeting of Working Party 5D (WP 5D), Addendum 5 to the Circular Letter was developed to announce the relevant information. WP 5D kindly invites interested organizations to take into account the information for the process of future development of the terrestrial components of IMT-2020 and to participate in the subsequent evaluation. WP 5D looks forward to collaborating with external organizations on this matter and will continuously provide information on future Addenda to the Circular Letter.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10200,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"EXTERNAL ORGANIZATIONS","Cc":"","lsoriginalls":"ITU_R_WP5D_TEMP_31","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200027.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200028","title":"LS from ITU-R WP 5d: ON THE REQUEST TO SUBMIT THE MATERIALS FOR THE FIRST RELEASE OF NEW RECOMMENDATION ITU-R M.[IMT-2020.SPECS]","source":"ITU-R WP 5D","contact":"Sergio Buonomo","contact-id":79388,"tdoctype":"LS in","for":"Information","abstract":"Introduction ITU-R Working Party 5D (WP 5D) thanks the relevant External Organizations for their work regarding the submissions for IMT-2020 under Step 3 of the IMT-2020 development process. WP 5D informed the relevant External Organizations of the detailed schedule for finalization of the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] in the previous liaison (Attachment 7.4 to Document 5D\/1297, filename 5D_TD_736e_IMT-2020.docx attached to the email sent on 23 July 2020) referring to two IMT-2020 Documents (IMT-2020\/20, IMT-2020\/21). Background WP 5D recognizes that the IMT-2020 development process is still under Steps 4, 5, 6 and 7 and WP 5D is evaluating the candidate RIT and SRIT proposals. RIT(s)\/SRIT(s) for inclusion in the standardization phase (Step 8) will be decided formally at the 35th meeting of WP 5D. However, due to the tight schedule for developing the new Recommendation, WP 5D needs to take accelerate actions for the first release of the new Recommendation as indicated in Document IMT 2020\/21. Requests for Action: WP 5D kindly requests the relevant External Organizations (RIT\/SRIT Proponents, potential GCS Proponent(s)) to submit the Form A (Annex 1 of IMT-2020\/20) to the 34th meeting of WP 5D (19 26 February 2020) and package of GCS list, Form B (Annex 2 of IMT-2020\/20) and the texts for Overview section to the 35th meeting (24 June-1 July 2020). If the relevant External Organization (potential GCS Proponent) decides to employ DIS style, it doesn't need to submit GCS list but needs to submit full materials for describing its RIT\/SRIT in the Recommendation and Form B at 35th meeting. WP 5D also asks the relevant External Organizations to start consensus building in Step 7 for achieving global harmonization and having the potential for wide industry support for the radio interfaces that are developed for IMT-2020. This may include grouping of RITs or modifications to RITs to create SRITs that better meet the objectives of IMT-2020. The cut-off days for submissions are: For 34th meeting: 12 February 2020 For 35th meeting: 17 June 2020. WP 5D looks forward to the continued cooperation with the External Organizations in the on-going work on the IMT-2020 terrestrial radio interfaces.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10210,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"EXTERNAL ORGANIZATIONS","Cc":"","lsoriginalls":"ITU_R_WP5D_TEMP_26","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200028.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200029","title":"LS from SA WG1: LS on Questions on onboarding requirements","source":"SA WG1","contact":"Kurt Bischinger","contact-id":26063,"tdoctype":"LS in","for":"Information","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.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10220,"status":"noted","reservation_date":"2020-03-05 10:20:25","uploaded":"2020-03-05 14:30:31","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\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200029.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200242","title":"LS from GSMA 5GJA: LS reply on GST attributes and on NG.116 publication and future co-operation","source":"GSMA 5GJA","contact":"Sandra Ondrusova","contact-id":77474,"tdoctype":"LS in","for":"Information","abstract":"GSMA NG\/5GJA would like to thank SA WG5 for detail review of GSMA PRD NG.1116. We welcome the collaboration with SA WG5 on the mapping of GST attributes and 3GPP NRM attributes. SA WG5 questions [Availability] SA WG5 suggests considering the 3GPP definition of 'communication service availability', see clause 3.1 in 3GPP TS 22.261 (https:\/\/www.3gpp.org\/ftp\/Specs\/archive\/22_series\/22.261\/). SA WG5 NRM 'ServiceProfile' object class already supports communication service availability. [GSMA] 5GJA has approved the same definition. This attribute will be updated in the version 3.0. [Coverage] SA WG5 needs clarification on this attribute. There are different proposals on how to describe the coverage area of the network slice in GSMA GST as below: - Based on base station location and coverage - Generic based on geographical partitioning SA WG5 suggests considering the generic based on geographical partitioning as the only approach since this approach is independent from the network deployment, and independent from deployment changes from network operator. [GSMA] 5GJA has renamed this attribute to Area of service and has been working on improving the description and values. At the moment, it is not clear how to express the geographical partitioning. There is a proposal to use Tracking Areas. [Energy efficiency] SA WG5 would like to highlight that, so far, the energy efficiency of a network slice is not defined. [GSMA] 5GJA has agreed to remove this attribute as the energy efficiency of a network slice is not defined. [Performance prediction] This attribute defines the capability to allow the mobile system to predict the network and service status. Predictive Quality of Service (QoS) can be done for various Key Quality Indicators (KQIs) and Key Performance Indicators (KPIs). KQIs reflect the end-to-end service performance and quality, while KPIs reflect the performance of the network. The prediction is done for a specific point of time in the future and for a specific geolocation. What is the relationship between this attribute and service performance assurance? Need some clarification on the usage of this attribute. [GSMA] System's prediction capability is only one way to achieve service performance assurance, but not the only way, hence these two attributes may have some indirect dependency. If the service performance is not assured, for instance, the typical 2C services, the customer could still order prediction capability from the operator to understand where the bottleneck is, and if something could be done from application level in advance to avoid problem. [Reliability] SA WG5 suggests considering the 3GPP definition of 'reliability', see clause 3.1 in 3GPP TS 22.261. [GSMA] 5GJA has decided to remove this attribute as it can be express by other attribute - Packet Error Rate (part of Slice quality of service) [Simultaneous use of the network slice] Question: Is this an attribute related to UE capability to support network slicing or not? Need more clarification on the purpose and usage of this attribute. [GSMA] This attribute describes whether a network slice can be simultaneously used by a device together with other network slices and, if so, with which other classes of network slices. The device mentioned above must support to use more than one network slice. NG.116 v3.0 will provide a better attribute description. [Supported access technologies] This attribute defines which access technologies are supported by the network slice: 1: GERAN 2: UTRAN 3: E-UTRA 4: NR 5: LTE-M 6: NB-IoT 7: Wi-Fi 8: Bluetooth 9: Fixed access, e.g. DSL, Fibre Considering the network slicing as a new feature introduced in 5G, SA WG5 would like to suggest using the following access technologies supported by the network slice: 4: NR 6: NB-IoT 7: Wi-Fi 9: Fixed access (e.g. DSL, Fibre) [GSMA] This attribute has been removed and new attribute NB-IoT support has been introduced instead. [Synchronicity] Question: Is this related to sync at the application le","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10230,"status":"noted","reservation_date":"2020-03-12 06:30:16","uploaded":"2020-03-12 07:29:56","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG5","Cc":"TSG SA, ETSI ZSM","lsoriginalls":"5GJA11_123r2","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200242.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200243","title":"LS from CT WG1: Reply LS on Mobile-terminated Early Data Transmission","source":"CT WG1","contact":"Mikael Wass","contact-id":42217,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 thanks RAN WG2 for the information provided on MT-EDT. CT WG1 has agreed updates to 24.301 based on approved updates of 23.401 and the feedback given by RAN WG2. The CT WG1 updates of NAS protocol will introduce explicit support indicators from UE to network for control plane MT-EDT and user plane MT-EDT respectively. For further details, see the attached CT WG1 agreed CR.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10240,"status":"noted","reservation_date":"2020-03-12 06:30:16","uploaded":"2020-03-12 07:29:56","revisionof":"","revisedto":"","release":"Rel-15","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2, SA WG2","Cc":"CT WG4, RAN WG3, TSG RAN, TSG SA","lsoriginalls":"C1-201062","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200243.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200245","title":"LS from SA WG3: Reply LS on UP gateway function on the N9 interface","source":"SA WG3","contact":"Christine Jost","contact-id":49662,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 thanks SA WG2 for their reply LS on UP gateway function on the N9 interface. In this LS, SA WG2 asks the following question to SA WG3: Question from SA WG2: [I]t is unclear to SA WG2 what information a UPF that supports the IPUPS functionality needs from SMF to achieve this 'GTP-u packet filtering'. To the above question, SA WG3 would like to provide the following answer: Answer from SA WG3: A UPF that supports the IPUPS functionality needs to receive the following information from the SMF: 1. PDU session establishment: Request to allocate destination IP address and TEID of a GTP-U tunnel for the PDU Session. 2. PDU session release: Information that the GTP-U tunnel is to be released. 3. During PDU Session lifetime: Request to allocate or release destination IP address and TEID in case the destination IP address and TEID for some reason need to change. SA WG3 foresees that only information that is currently sent on N4 from SMF to UPF will need to be sent from SMF to UPF with IPUPS functionality. That means, in release 16, the sent information between SMF and UPF with IPUPS functionality will be a subset of current N4. However, additions in future releases are not precluded.","secretary_remarks":"Block1 - Proposed: Noted. Noted.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10250,"status":"noted","reservation_date":"2020-03-12 06:30:16","uploaded":"2020-03-12 07:29:56","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"CT WG4, TSG SA","lsoriginalls":"S3-200482","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200245.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200277","title":"LS from 5GAA WG4: LS on eCall Support on 5G Core with NR","source":"5GAA WG4","contact":"Rishikesh Chakraborty","contact-id":76252,"tdoctype":"LS in","for":"Action","abstract":"5GAA is aware of the LS sent from SA WG2 (S2-2001677) to TSG SA on the restriction which is currently applied in 3GPP specifications on eCall over IMS over NR. 5GAA has discussed the topic in its WG4 #12 meeting and car OEMs indicated that early support of eCall over IMS over NR in the 3GPP specifications is needed. Due to possible different 5G network deployment scenarios and the long lifetime of cars, it is necessary to support NG eCall in all deployment scenarios. Therefore, 5GAA encourages TSG SA to conclude to remove the restriction that prevents support for eCall over IMS over NR in Rel-16. Action: 5GAA kindly asks TSG SA to carry out work needed to remove the restriction that prevents support for eCall over IMS over NR preferably in Rel-16.","secretary_remarks":"This is marked 'for action' but can be noted. Response drafted in SP-200286. Final response in SP-200291","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10260,"status":"replied to","reservation_date":"2020-03-16 17:26:33","uploaded":"2020-03-16 17:26:58","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"TSG RAN","lsoriginalls":"5GAA_S-200065","lsreply":"SP-200291","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200277.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200286","title":"LS reply on eCall Support on 5G Core with NR","source":"Vodafone","contact":"Adrian Neal","contact-id":31227,"tdoctype":"LS out","for":"Approval","abstract":"To: 5GAA WG4","secretary_remarks":"Created at meeting. Response to SP-200277. SP-200286_rev1 approved. Revised to SP-200291.","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10270,"status":"revised","reservation_date":"2020-03-19 08:12:27","uploaded":"2020-03-19 10:29:51","revisionof":"","revisedto":"SP-200291","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5GAA WG4","Cc":"","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200286.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200291","title":"LS reply on eCall Support on 5G Core with NR","source":"TSG SA","contact":"Adrian Neal","contact-id":31227,"tdoctype":"LS out","for":"Approval","abstract":"To: 5GAA WG4. CC: TSG RAN","secretary_remarks":"Revision 1 of SP-200286. Approved","agenda_item_sort_order":5,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10280,"status":"approved","reservation_date":"2020-03-21 15:13:54","uploaded":"2020-03-21 15:14:36","revisionof":"SP-200286","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"SP-200277","lsto":"5GAA WG4","Cc":"TSG RAN","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_87E_Electronic\/Docs\/SP-200291.zip","group":"SP","meeting":"SP-87-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]