[{"name":"SP-200302","title":"LS from 5GAA WG4: LS on relevant 3GPP Specs for PC5 Sidelink","source":"5GAA WG4","contact":"Philippe Reininger","contact-id":35013,"tdoctype":"LS in","for":"Action","abstract":"The 5GAA has been contacted by ITU-T to provide a list of V2X and Sidelink 3GPP specifications. The objective is to have the information included in a Data Base related to the Collaboration on ITS Communication Standards. The attached specifications list contains the relevant 3GPP deliverables from the point of view of 5GAA. The related Data Base can be found at: https:\/\/www.itu.int\/en\/ITU-T\/extcoop\/cits\/Pages\/default.aspx. Action: 5GAA kindly ask TSG RAN and TSG SA to take this information into account and comment, if needed.","secretary_remarks":"Postponed SP-200019 from SP-87E. Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10380,"status":"noted","reservation_date":"2020-06-03 14:46:16","uploaded":"2020-06-05 15:39:41","revisionof":"SP-200019","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG RAN, TSG SA","Cc":"","lsoriginalls":"5GAA_S-200026","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200302.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200303","title":"LS from CableLabs: Status and Evolution of 5WWC","source":"CableLabs","contact":"Bernie Mckibben","contact-id":13024,"tdoctype":"LS in","for":"Action","abstract":"Dear Colleagues, CableLabs is aware that the proposed 5WWC study item as described in SP-191200 was not accepted as part of the scope in 3GPP release 17. CableLabs works with many operators who view the following convergence features to be of high priority in addition to those already standardized in 3GPP R16: - How to improve the support of L2 Bridge 5G-RG scenario for providing connectivity to devices behind the RG. This is similar to BBF requirements expressed in LS BBF-291\/S2-1903875; - How to improve the support of QoS for UE connected behind an RG via Untrusted and Trusted Non-3GPP access. It is important that these convergence features and future converged core network evolution be included in 3GPP work planning. CableLabs requests SA plenary and SA WG2 take this information into account for future release planning. Sincerely Belal Hamzeh","secretary_remarks":"Postponed SP-200020 from SP-87E. Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10370,"status":"noted","reservation_date":"2020-06-03 14:46:16","uploaded":"2020-06-05 15:39:41","revisionof":"SP-200020","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, SA WG2","Cc":"","lsoriginalls":"LS_5WWC status","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200303.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200304","title":"LS from GSMA: Mandatory User Plane Integrity for 5G","source":"GSMA","contact":"James Moran","contact-id":82690,"tdoctype":"LS in","for":"Information","abstract":"Background GSMA has been made aware through its 'Coordinated Vulnerability Disclosure Programme' about new research on layer-2 attack scenarios against LTE. The research has been published at [1] and will be presented on the security conference NDSS [2] end of February 2020. 2 Item for Consideration 2.1 Abstract from the Research Paper The key findings of the research are copied from the research paper's abstract below: 'Long Term Evolution (LTE\/4G) establishes mutual authentication with a provably secure Authentication and Key Agreement (AKA) protocol on layer three of the network stack. Permanent integrity protection of the control plane safeguards the traffic against manipulations. However, missing integrity protection of the user plane still allows an adversary to manipulate and redirect IP packets, as recently demonstrated. In this work, we introduce a novel cross-layer attack that exploits the existing vulnerability on layer two and extends it with an attack mechanism on layer three. [\u2026] allows an active attacker to impersonate a user towards the network and vice versa; we name these attacks IMP4GT (IMPersonation attacks in 4G neTworks). In contrast to a simple redirection attack as demonstrated in prior work, our attack dramatically extends the possible attack scenarios and thus emphasizes the need for user-plane integrity protection in mobile communication standards.' 2.2 Observations from GSMA It is essential for security of 5G cellular networks that the 3GPP standards mandate support of user plane integrity protection at the full data rate of a UE. The new IMP4GT attacks exploit the same underlying issue as the earlier work described in [3], which was reported to 3GPP in 2018 [4]. GSMA gave 3GPP advance notice of the IMP4GT research in May 2019 [7]. The researchers executed the IMP4GT attacks in an LTE environment, but indicate that the same attack would in principle also work against 5G (UEs using NR connected to the 5GC) unless User Plane integrity protection is in place. It is GSMA's understanding of the current work in SA WG3 that a 5G 'standalone' SA network with NR radio connected to a 5G Core Network would support User Plane integrity protection, and thus could be immune against IMP4GT and similar attacks. The only aspect that remains unclear is the current implementation status of UEs, because [5] and [6] only mandate that UEs support a data rate of 64 kbps with integrity protection, while user plane integrity protection with full data rate is an optional UE feature. GSMA can only confirm the researcher's statement in the abstract: 'We emphasize the requirement for a mandatory and full-rate integrity protection for all 5G data connections to prevent IMP4GT' Even though the new attacks may have limited impact in real-world deployments, there is the need to strengthen the security of 5G networks and UEs for the future. It is essential to not create a large legacy of 5G networks and UEs that are vulnerable to such attacks. At this point in time no wide scale commercial penetration of \u00ab standalone \u00bb SA supporting terminals is in the market, hence it is now the right point in time to mandate this UE functionality. 3 Action: GSMA politely requests SA\/RAN\/CT to ask the affected working groups to agree the necessary CRs in the appropriate release to have mandatory support of full-rate user plane integrity protection for all UEs supporting NR connected to the 5GC. 3.1 Deadline GSMA would appreciate a response following the plenary meetings in March 2020.","secretary_remarks":"Postponed SP-200021 from SP-87E. Responses drafted in SP-200539 and SP-200540. Final response in SP-200618","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10390,"status":"replied to","reservation_date":"2020-06-03 14:46:16","uploaded":"2020-06-05 15:39:41","revisionof":"SP-200021","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, TSG RAN, TSG CT, RAN WG2, SA WG3, CT WG1, SA WG2","Cc":"","lsoriginalls":"FSAG#79_002","lsreply":"SP-200618","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200304.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200305","title":"LS from ITU-R WP5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ON DRAFT REVISION OF REPORT ITU-R M.2291-1 'THE USE OF INTERNATIONAL MOBILE TELECOMMUNICATIONS (IMT) FOR BROADBAND PUBLIC PROTECTION AND DISASTER RELIEF (PPDR) APPLICATIONS'","source":"ITU-R WP5D","contact":"Sergio Buonomo","contact-id":79388,"tdoctype":"LS in","for":"Action","abstract":"Report ITU-R M.2291-1 was developed by ITU-R in 2016. Tables 2, 3 and 4 in Annex 1 of Report ITU-R M2291-1 were developed in collaboration with 3GPP. These tables detail how 3GPP LTE supports the various requirements of PPDR and provide the relevant 3GPP Release numbers, which are included in the last column of the tables. WP 5D has started revising Report ITU-R M.2291-1. This revision will update as necessary, tables in Annex 1 of the report to reflect technological developments in IMT-2020, in particular the work carried out by 3GPP (SA WG6) in the latest releases of 3GPP LTE and NR. A copy of the working document towards the preliminary draft revision of Report ITU-R M.2291-1 is enclosed to facilitate updating of Annex 1. As a part of this revision, WP 5D intends to include information on IMT-2020, similar to the information available on LTE in Annex 1. Blank columns have been added in the working document in Tables 2, 3 and 4 to facilitate this work by the External Organisations. It would also be useful if External Organizations could indicate any new features\/applications that have been added in support of PPDR applications in their IMT-2020 specifications, which are currently not included in Annex 1 of the Report ITU-R M.2291-1, by adding additional rows, as necessary. WP 5D therefore requests External Organisations to kindly provide input to facilitate updating of Annex 1 of Report ITU-R M.2291-1 as explained above. WP 5D would appreciate receiving inputs towards this work in time for the 35th meeting of WP 5D scheduled to be held from 23rd June 2020 (deadline for contribution is 1600 hours UTC 16th June 2020).","secretary_remarks":"Postponed SP-200241 from SP-87E. This was resolved by endorsing and forwarding SP-200308 to the PCG. Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10360,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-05 15:39:41","revisionof":"SP-200241","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"EXTERNAL ORGANIZATIONS","Cc":"","lsoriginalls":"5D_TD_52R1e","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200305.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200306","title":"LS from RAN WG2: Reply LS on Rel-16 NB-IoT enhancements","source":"RAN WG2","contact":"Baokun Shan","contact-id":70626,"tdoctype":"LS in","for":"Action","abstract":"Reply to S2-1912763: RAN WG2 thanks SA WG2 for their reply LS and for proposing two options for the introduction of UE specific DRX. In RAN WG2#109-e, RAN WG2 discussed the feasibility of the two options and preference from RAN WG2 point of view and would like to provide the following feedback: - From RAN WG2 point of view, both options are feasible. - From RAN WG2 point of view, option 2 is preferred as it can support separate value ranges for NB-IoT and WB-EUTRAN. Reply to C1-201024: RAN WG2 thanks CT WG1 for their question on the values for UE specific DRX cycle in NB-IoT. In RAN WG2#109-e, RAN WG2 discussed the value set for UE specific DRX cycle but there was no consensus in this RAN WG2 meeting. Action: RAN WG2 respectfully asks SA WG2, CT WG1, RAN WG3 and SA to take above information into account.","secretary_remarks":"Postponed SP-200244 from SP-87E. Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10400,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-05 15:39:41","revisionof":"SP-200244","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2, CT WG1, RAN WG3, TSG SA","Cc":"TSG RAN, TSG CT","lsoriginalls":"R2-2001815","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200306.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200307","title":"LS from SA WG5: Reply LS on analytics support for energy saving","source":"SA WG5","contact":"Jean Michel Cornily","contact-id":7599,"tdoctype":"LS in","for":"Action","abstract":"SA WG5 thanks TSG SA for their Liaison Statement on 'analytics support for energy saving'. SA WG5 would like to inform SA and SA WG2 that our Rel-16 work item 'Energy efficiency of 5G' is about to be completed. The EE KPI and related performance measurements have been defined for NG-RAN as well as energy saving management use cases, requirements and information model. SA WG5 understands that the questions from SA WG2 are related to energy saving in a virtualized 5G core network. SA WG5 thinks that the relevance of virtualized 5GC energy saving use cases and solutions can be assessed when the means exist to measure the corresponding energy efficiency KPI before and after the energy saving functionality has been activated. As the 3GPP management system has the overall network view, the coordination between 5GC energy saving and NG-RAN energy saving needs to be considered from the OA&M aspect. SA WG5 is discussing the objectives of a Release 17 work item on use cases, requirements and solutions, as enhancement of Rel-16 energy efficiency and energy saving in 5G networks. The work includes the following aspects: a) 5GC network functions and b) the case of virtualized network functions. The potential usage of analytics and NWDAF is to be considered, in conjunction with OA&M (incl. MDAS - Management Data Analytics Service) in Rel-17 work. SA WG5 encourages SA WG2 to elaborate further on the description of potential energy saving use cases and solutions for 5GC, involving NWDAF or not, and in relationship with OA&M, and keep SA WG5 updated. Action: To SA: Please take the above information in consideration.","secretary_remarks":"Postponed SP-200246 from SP-87E. Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10410,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-05 15:39:41","revisionof":"SP-200246","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG2, SA WG3, SA WG3LI, RAN WG3","lsoriginalls":"S5-201472","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200307.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200308","title":"LS from TSG RAN: DRAFT LTI - answer to ITU-R WP5D LS on WORKING DOCUMENT TOWARDS A PRELIMINARY DRAFT REVISION OF REPORT ITU-R M.2291-1","source":"TSG RAN","contact":"Jingya Li","contact-id":78009,"tdoctype":"LS in","for":"Endorsement","abstract":"For 3GPP review: in: TSG SA feedback LS before: June 11th, 2020 to: 3GPP PCG","secretary_remarks":"For e-mail Endorsement and forwarding to PCG. Endorsed and forwarded to the PCG, 10 June 2020","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10350,"status":"endorsed","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-05 15:39:41","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"","lsoriginalls":"RP-200572","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200308.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200309","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":"All necessary CRs for eCall over NR have been completed. This LS was then noted.","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10310,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:29","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"TSG RAN","lsoriginalls":"5GAA_S-200065.","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200309.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200310","title":"LS from IALA: Liaison Note to TSG SA - Request for information","source":"IALA","contact":"Hyounhee Koo","contact-id":65247,"tdoctype":"LS in","for":"Action","abstract":"Introduction: The International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA) focuses on the maritime domain, particularly Aids to Navigation (AtoN), including Vessel Traffic Services (VTS), and their associated communication systems. 3GPP is becoming an important element in digital communications, including the exchange of digital data. IALA would like to thank TSG SA for their appointment of a liaison between IALA and 3GPP currently fulfilled by Ms Hyounhee Koo (koo@synctechno.com). IALA would like to invite Ms. Koo to participate at the ENAV26 meeting scheduled from 28 September to 2 October at the IALA HQ to provide an update on 3GPP developments and assist in the drafting of relevant IALA documentation related to 3GPP. It is noted by IALA that 3GPP has a work item focusing maritime communication services over 3GPP Systems in Release 16 called 'MARCOM'. IALA 3GPP interest: At the fifteenth meeting of the Joint IMO\/ITU Experts Group on Maritime radiocommunication matters (8 to 12 July 2019, IMO Headquarters, London) IALA was requested to report to IMO in respect of 3GPP developments. The report of the meeting (IMO document NCSR7\/12) records this decision in paragraph 8.9: 8.9 During the ensuing discussion, the delegations that took the floor recognized that these were relevant developments and that IMO should be more proactive and get involved in the work of the 3rd Generation Partnership Project (3GPP). Noting that IALA had been approached already by 3GPP, the Group invited IALA to keep IMO informed of future developments. In response to this, IALA provided an information paper to IMO (NCSR7 INF.6). This document was developed from the IALA perspective on the operational aspects of the developments in 3GPP that may be of interest to the members of NCSR7. In document SP-191366, 3GPP provided a liaison to IALA noting proposed amendments to the NCSR document. The paper was not addressed at NCSR7 plenary, according to the standard procedures of IMO. IALA will prepare an updated input for NCSR8 and would welcome input from 3GPP in the preparation of that document. Given this request, and IALA's own role in the development of AtoN and VTS technology, IALA closely following the development of maritime services within 3GPP. IALA would therefore like to register an interest in the work of 3GPP, particularly the maritime vertical domain. Action requested: The TSG SA is requested to: 1. Inform IALA which 5G enabling technologies that are specified in the 3GPP Release 16 technical specification which could be applicable in the maritime domain. 2. Inform IALA of ongoing 5G standardization works in 3GPP Release 17 which could be applicable in the maritime domain. 3. Advise IALA regarding appropriate inputs [to support] development of 3GPP Release 17 for use within the maritime domain. 4. Advise IALA on the schedule for future meetings and other opportunities for input relevant to the maritime domain (such as MARCOM) allowing adequate time to prepare inputs.","secretary_remarks":"This LS was postponed.","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10320,"status":"postponed","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:29","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"","lsoriginalls":"C71-11.5.1","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200310.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200311","title":"LS from TCCA: LS on Generic Slice Template with Public Safety Feedback","source":"TCCA","contact":"Juergen Rurainsky","contact-id":75914,"tdoctype":"LS in","for":"Action","abstract":"TCCA thanks GSMA for bringing this important topic, the definition of the Generic Slice Template (GST) and Network Slice Type (NEST), to our attention. Public Protection and Disaster Relief (PPDR) network operators have analysed and evaluated the provided document. Please find attached the feedback from this vertical, in the form of a cross-reference table to the attributes discussed with the revised document in the form of labels for each attribute, e.g. 'relevant' or 'not relevant' as well as in some cases as 'duplicate'. In addition, two new attributes provided to the list 'Attributes to be worked on' with the revised document. You also find additional information to several attributes in the form of comments, suggestions for improvements, additional use cases as well as some requests for clarifications. The following organisations support Public Safety services on a 24\/7 basis for around 593 Mio. people and have been involved in the analysis as well as support this feedback: - Federal Agency for Public Safety Digital Radio (BDBOS) in Germany - First Responder Network Authority (FirstNet) in USA - Ministry of State - RENITA in Luxembourg - RIKS (State Infocommunication Foundation) in Republic of Estonia - The Police of the Netherlands - The Swiss Federal Office for Civil Protection (FOCP) - The Norwegian Directorate for Civil Protection (DSB) - The French Ministry of Interior - Erillisverkot in Finland - Norwegian Communications Authority (Nkom) - Home Office of the United Kingdom - A.S.T.R.I.D. S.A. in Belgium. Action: to 3GPP: TCCA asks 3GPP kindly to take the feedback provided with the revised document together with the cross-reference table as information.","secretary_remarks":"Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10420,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:29","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA","Cc":"TSG SA, SA WG1, SA WG2, SA WG3, SA WG5, SA WG6, RAN WG3","lsoriginalls":"LS to GSMA on Generic Slice Template","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200311.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200312","title":"LS from IETF: Re: LS on need for Multi-Path QUIC for ATSSS","source":"IETF","contact":"Lars Eggert","contact-id":43655,"tdoctype":"LS in","for":"Action","abstract":"Thank you for your input to our specifications. Multipath capabilities for QUIC are currently under active discussion in the IETF's QUIC WG. Several individual proposals have been made, but the group is also considering whether the already-specified connection migration capabilities are sufficient to cover the majority of use cases. We encourage 3GPP to contribute their requirements for QUIC multipath capabilities in an Internet-Draft, especially if the already-specified connection migration capabilities are deemed insufficient. 3GPP's active involvement in any multipath QUIC standardization would be the best way to remain informed of the progress of any such work in the IETF. Kind regards, Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group chairs","secretary_remarks":"This LS was forwarded to SA WG2.","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10290,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:29","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"","lsoriginalls":"LS_from_IETF","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200312.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200323","title":"LS from SA WG2: Reply LS on support for eCall over NR","source":"SA WG2","contact":"Haris Zisimopoulos","contact-id":84603,"tdoctype":"LS in","for":"Action","abstract":"SA WG2 thanks TSG SA for the LS on support for eCall over NR: SA WG2 has approved the required specification changes needed to support eCall in IMS over NR (with 5G Core) in the attached CRs. Action: SA WG2 asks to take this information into account.","secretary_remarks":"Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10430,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, RAN WG2, CT WG1, TSG CT","Cc":"SA WG1, SA WG4, TSG RAN, SA WG5, RAN WG5","lsoriginalls":"S2-2003308","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200323.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200324","title":"LS from SA WG2: LS on SA WG2 status of MT-EDT in Rel-16","source":"SA WG2","contact":"Sebastian Speicher","contact-id":72922,"tdoctype":"LS in","for":"Action","abstract":"SA WG2 would like to provide an update on the alignment request by RAN WGs to introduce system support for MT-EDT also for 5GC in Rel-16. Even though SA WG2 introduced system support for MT-EDT in EPC in Rel-16, SA WG2 did not agree on a solution for MT-EDT in 5GC. The main identified issue for 5GC, compared to EPC, is the SA WG3 requirement to reallocate a new 5G GUTI also during MT-EDT transaction for CP CIoT 5GS optimization and UP CIoT 5GS optimization procedures. Proposed solutions to allow for efficient 5G GUTI reallocation for MT-EDT were not agreed mostly due to concerns about system impacts. Action: SA WG2 kindly asks the working groups listed above to take the SA WG2 status into account.","secretary_remarks":"Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10440,"status":"noted","reservation_date":"2020-06-03 15:52:50","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA, RAN WG2, RAN WG3, CT WG1, SA WG3","Cc":"","lsoriginalls":"S2-2003505","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200324.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200325","title":"LS from SA WG2: Reply LS on IAB supporting in NPN deployment","source":"SA WG2","contact":"Hong Cheng","contact-id":25668,"tdoctype":"LS in","for":"Information","abstract":"SA WG2 thanks RAN WG2 for the LS on IAB supporting in NPN deployment. SA WG2 do not see any issue on supporting the IAB functionality in non-public network deployment. The attached CR to TS 23.501 has been conditionally approved by SA WG2, and it can be formally approved by TSG SA if the corresponding RAN WG2 CRs are agreed.","secretary_remarks":"Actions to RAN WG2 and RAN WG3: To inform TSG SA the actual progress in order to decide whether the corresponding SA WG2 CR can be approved or not (SP-200435). Noted at CC#3","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10280,"status":"noted","reservation_date":"2020-06-05 15:44:16","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG2, RAN WG3, TSG SA","Cc":"CT WG1","lsoriginalls":"S2-2004469","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200325.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200326","title":"LS from SA WG2: Reply LS on S1\/NG DAPS handover","source":"SA WG2","contact":"Laurent Thiebaut","contact-id":72921,"tdoctype":"LS in","for":"Action","abstract":"SA WG2 thanks RAN WG3 for their LS. Considering that Core Network protocol change are required (to cover inter AMF\/MME mobility) while SA WG2 ensures that CT specifications are frozen in this quarter, SA WG2 has agreed to the attached R16 CR(s) based on the condition that TSG CT and TSG SA plenary agree to their inclusion in R16 specifications. SA WG2 will also like to highlight another issue which is not addressed in RAN WG3's LS and the attached RAN WG3 CR but considered in the attached SA WG2 CRs. It is assumed that S-RAN will only initiate the DAPS HO when both S-RAN and S-AMF support DAPS HO. T-RAN will only send the DAPS HO accept when both T-RAN and T-AMF support the DAPS HO. Action: Please decide whether to approve the attached CR(s) for inclusion in 3GPP R16.","secretary_remarks":"Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10450,"status":"noted","reservation_date":"2020-06-05 15:44:16","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG CT, TSG SA, CT WG4, RAN WG3","Cc":"TSG RAN","lsoriginalls":"S2-2004474","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200326.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200450","title":"LS from SA WG5: Reply LS to Reply LS on support for eCall over NR","source":"SA WG5","contact":"Maryse Gardella","contact-id":68914,"tdoctype":"LS in","for":"Action","abstract":"SA WG5 thanks TSG SA for the LS on support for eCall over NR. SA WG5 can confirm that the IMS charging enhancements, introduced from Rel-15 to cover IMS on top of 5GCore, include IMS emergency sessions, with no restriction on the 3GPP radio access type (E-UTRA or NR). Therefore, the support eCall in IMS over NR with 5G Core is already covered from charging's perspective from Rel-15. Action: SA WG5 kindly asks TSG SA to take into account the answer above.","secretary_remarks":"Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10460,"status":"noted","reservation_date":"2020-06-16 05:14:05","uploaded":"2020-06-16 08:38:17","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG2, RAN WG2, CT WG1, RAN WG5, SA WG1, SA WG4, TSG RAN, TSG CT","lsoriginalls":"S5-203369","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200450.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200458","title":"LS from CT WG1: Reply LS on support of eCall over NR","source":"CT WG1","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"CT WG1 thanks TSG SA for their LS on support of eCall over NR. CT WG1 would like to inform TSG SA that CT WG1 has completed the work required to support eCall in IMS over NR (with 5G Core) as requested by TSG SA, via the agreement of the attached CR. Action: CT WG1 asks TSG SA to take the above information into account.","secretary_remarks":"Block noted at CC#2","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10470,"status":"noted","reservation_date":"2020-06-16 08:37:52","uploaded":"2020-06-16 08:38:17","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG2, SA WG5, RAN WG2, RAN WG5, SA WG1, SA WG4, TSG RAN, TSG CT, CT WG6","lsoriginalls":"C1-203221","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200458.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200533","title":"LS from GSMA: Inclusion of full-rate UPIP for 5GSA in 3GPP Release 16","source":"GSMA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"Inclusion of full-rate UPIP for 5GSA in 3GPP Release 16: GSMA has communicated with 3GPP since April 2018 about security vulnerabilities arising from the lack of mandatory support of full-rate user plane integrity protection (UPIP) [1,2]. Practical attacks [4,5] exploiting these vulnerabilities have been shown to undermine the security of individual users and the network as a whole. In March 2020, GSMA submitted a Liaison Statement [3] requesting the inclusion of mandatory support of full-rate UPIP in Release 16 and the initial response we received was very positive. However, this feature has still yet to be included and the release is due to be frozen at the end of this month. The support of full-rate UPIP is of considerable importance to our members and was discussed during the GSMA Board Meeting on 2nd June 2020. In that meeting, it was unanimously agreed, that support of full-rate UPIP should be mandatory and made available as soon as possible in devices and networks regardless of the potential performance drawbacks. GSMA views the lack of full-rate UPIP as a significant setback for the security of the mobile industry as a whole and believes that not addressing a known security issue would cause harm to the reputation of 3GPP and, by reflection, of the mobile network operators. Action: The GSMA Board requests TSG SA to confirm, that mandatory support of full-rate UPIP in UEs supporting Standalone NR connected to 5GC will be required from Release 16 onwards. The network operator shall retain the ability to control the use of UPIP on a PDU session basis. Given the importance of this matter, we would appreciate a response in writing as soon as possible.","secretary_remarks":"Noted at CC#4","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10300,"status":"noted","reservation_date":"2020-06-22 14:28:09","uploaded":"2020-06-22 14:58:17","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"TSG RAN, TSG CT","lsoriginalls":"GSMA_LS200604","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200533.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200601","title":"LS from TSG CT: LS on port allocation","source":"TSG CT","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"In response to the RAN WG3 and CT WG4 LSs on port allocation for the W1 interface, TSG CT has endorsed the attached LSs to RAN WG3, CT WG4 and IESG requesting: - IESG to approve the IANA port number assignment request for the W1 interface; - CT WG4 to specify alternative solutions for port allocation for new 3GPP interfaces from Rel-17 onwards, that each 3GPP WG could rely upon when defining new interfaces, to avoid future IANA port number assignment requests for network internal services. CT kindly ask RAN and SA to endorse the proposed LSs or to provide feedback as appropriate. TSG CT intends to approve these LSs during TSG CT#88e if they are endorsed by TSG RAN and TSG SA. Action: TSG CT kindly asks TSG RAN and TSG SA to endorse the proposed LSs or to provide feedback as appropriate.","secretary_remarks":"The latest version developed by TSG CT was endorsed.","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10270,"status":"endorsed","reservation_date":"2020-06-29 13:49:00","uploaded":"2020-06-29 13:49:22","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG RAN, TSG SA","Cc":"","lsoriginalls":"CP-201315","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200601.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200602","title":"LS from 5G-ACIA: 5G capabilities exposure for factories of the future","source":"5G-ACIA","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Action","abstract":"Over the last two years, 5G-ACIA has collected and analysed many industrial use cases. These use cases - as well as inferred communication service characteristics - have been documented by 3GPP in TS 22.104 and TS 22.261. 5G-ACIA has further refined and analysed operational use cases that are needed by factory operators to manage and maintain 5G-enabled devices and 5G Non-Public Networks (NPN) in a simple and efficient manner. 5G-ACIA believes the service exposure requirements derived from the aforementioned operational use cases are valuable input for upcoming contributions addressing ongoing work in 3GPP, such as the study items documented in TR 23.700 and TR 23.745. These requirements have been published in the 5G-ACIA white paper Exposure of 5G capabilities for connected industries and automation applications (www.5g-acia.org\/publications), which is also attached to this LS. This white paper focuses on operational use cases pertaining to device management, for example use cases that enable factory operators to manage the life cycle of devices, and e.g. to change and monitor the devices' connectivity. In order to execute these operational use cases efficiently, the industrial systems require a set of well standardised and published APIs that hide a great deal of 3GPP complexity and yet provide the needed flexibility to the factory operator. These capabilities are needed by factories of the future and expected from 5G NPN and 5G-enabled devices. 5G-ACIA would like to highlight the importance of these refined requirements for industrial operations and would appreciate it very much, if 3GPP considered the provided information to ongoing and upcoming specification work. 5G-ACIA would be eager to receive 3GPP's feedback on these new exposure interface requirements and related Stage-2 and Stage-3 work. Action: Consider the content of the white paper and advice any related 3GPP WG on needed study items or actions and provide feedback to 5G-ACIA on planned activities.","secretary_remarks":"Response drafted in SP-200608. Noted at CC#3","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10330,"status":"noted","reservation_date":"2020-06-29 14:03:48","uploaded":"2020-06-29 14:04:05","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG SA","Cc":"SA WG1, SA WG2, SA WG3, SA WG5, SA WG6, CT WG3, IEC TC 65, oneM2M TP, OPC Foundation, PI, IEEE TSN, TM Forum, ETG","lsoriginalls":"5G-ACIA_LS_29062020","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200602.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0},
{"name":"SP-200608","title":"Reply-LS on 5G capabilities exposure for factories of the future","source":"TSG SA","contact":"Johannes Achter","contact-id":5595,"tdoctype":"LS out","for":"Approval","abstract":"To: 5G-ACIA. CC: SA WG1, SA WG2, SA WG3, SA WG5, SA WG6, CT WG3","secretary_remarks":"Response to SP-200602. Withdrawn at CC#3.","agenda_item_sort_order":10,"ainumber":"2.2","ainame":"Incoming LSs which need an outgoing LS and","tdoc_agenda_sort_order":10340,"status":"withdrawn","reservation_date":"2020-06-30 16:08:33","uploaded":"2020-07-01 11:26:07","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"5G-ACIA","Cc":"SA WG1, SA WG2, SA WG3, SA WG5, SA WG6, CT WG3","lsoriginalls":"","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200608.zip","group":"SP","meeting":"SP-88-e","year":2020,"uicc_affected":null,"me_affected":null,"ran_affected":null,"cn_affected":null,"clauses_affected":null,"crsinpack":null,"crsinpacknumber":0}]