[{"name":"SP-200313","title":"LS from ETSI: Liaison about ETSI ISG NIN (Non-IP Networking)","source":"ETSI","contact":"Emmanuelle Chaulot-Talmon","contact-id":13254,"tdoctype":"LS in","for":"Information","abstract":"Dear Madam, Dear Sir, We are pleased to inform you of a new Industry Specification Group on Non-IP Networking (ISG NIN). ISG NGP (Next Generation Protocols) investigated the problems network operators have had with the use of the current Internet protocol suite in core and access networks, and ways to better support the huge performance and capacity improvements planned for 5G, considering both evolution of TCP\/IP and use of new kinds of protocol. Its conclusion was that a fundamental change is needed, and ISG NIN has been created to take that forward. ISG NIN aims to define and test packet networking technology that will meet the requirements identified by ISG NGP, including: - dramatic reduction in size and complexity of packet headers and other overheads - guaranteed ultra-low latency in packet switches for continuous media - improved security and privacy - simpler management We invite any interested parties from your group to follow our progress via the ETSI portal, mailing lists, or attendance at our ISG meetings. Participation in the ISG NIN is subject to signature of an ISG NIN Agreement which you can find at: https:\/\/portal.etsi.org\/tb.aspx?tbid=887&SubTB=887. Explanation about those agreements is also available from the same location. The following Work Items are currently being scoped with more to follow: - report detailing the shortcomings of TCP\/IP in mobile systems and how a new model would avoid them - framework for testing the efficiency and effectiveness of the new protocols, including over radio - outline specification of a mobile network based on non-IP technologies Meeting dates for 2020: - NIN#2: 21-22 July - NIN#3: 25-26 November For further information please consult: https:\/\/portal.etsi.org\/tb.aspx?tbid=887&SubTB=887 else please do not hesitate to contact our ISG NIN Support: Emmanuelle Chaulot-Talmon In addition, I would be pleased to speak with you and\/or your group to explain further what we are doing and the progress we've made thus far. Best regards, John Grant ETSI ISG NIN Chairman","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10070,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"3GPP SA, ETSI, ISO\/IEC, GSMA, AES, IETF, ITU-T, SCION","Cc":"","lsoriginalls":"NIN(20)000011r1","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200313.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-200314","title":"LS from ITU-WRC: World Radiocommunication Conference, Sharm el-Sheikh, 2019 (WRC-19) Resolutions","source":"ITU-WRC","contact":"Houlin Zhao","contact-id":17006,"tdoctype":"LS in","for":"Information","abstract":"Dear Sir, The World Radiocommunication Conference, Sharm el-Sheikh, 2019 (WRC-19) adopted or revised a number of Resolutions which it considered to be of interest to your organization and has instructed me to bring these Resolutions to your attention. In pursuance of the above instruction, I have the honor to forward herewith, for information and appropriate action, the said Resolutions. The same documents in the six official languages of the ITU are also available for download at http:\/\/www.itu.int\/go\/wrc-19\/res. It would be greatly appreciated if you would keep me informed of your organization's action on any of these matters, so that I may advise the ITU administrations accordingly. Yours faithfully, Houlin Zhao","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10080,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"PCG, 3GPP","Cc":"","lsoriginalls":"O-2020-001473 (3GPP)","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200314.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-200315","title":"LS from TSG SA: LS on Sidelink Positioning for advanced V2X applications","source":"SAE Advanced Application Technical Committee","contact":"Brian K. Daly","contact-id":13316,"tdoctype":"LS in","for":"Information","abstract":"Overall Description: The SAE Advanced Application Technical Committee (AA TC) has been identifying, analyzing and formulating new use cases, features, and requirements for advanced V2X services, such as Application Protocol and Requirements for Maneuver Sharing and Coordinating Service and V2X Sensor-Sharing for Cooperative & Automated Driving. AA TC closely follows industry-led activities, such as newly added Use Cases (UCs) in 5GAA's whitepaper [1]. AA TC is aware that 3GPP Release 16 5G_HYPOS and cyberCAV had already created important UCs and their related performance requirements (KPIs) for higher accuracy positioning [2], which are considered quite useful for supporting advanced V2X services. At the same time, however, the TC also identified that the stage-1 performance requirements on positioning were not sufficiently followed by stage-2\/3 solutions. AA TC considers it very important and helpful if study continued in stage-2\/3 to support advanced V2X services. Especially, the absence of a 3GPP radio solution for higher accuracy positioning outside of cellular network coverage can be a problem in supporting the performance requirements necessary for advanced V2X services. AA TC understands 3GPP work prioritization status through observations of recent TSG meetings, which demonstrated a maximum effort on Release 17 prioritization and scheduling within the tight time budget. However, because V2X using 3GPP transport-layer technology, has been considered one of the most successful verticals so far, AA TC recommends, from an automotive industry perspective, that TSG RAN should start a Feasibility Study, looking into the core value of side-link (SL) positioning as a supplementary means for improving the operational cost and performance of the advanced V2X services coming soon. AA TC analysis has also concluded that some service level requirements (SLRs) from a 5GAA perspective (e.g., positioning requirement for VRU discovery UC) and 3GPP positioning requirements still have some gaps to close; for example, (1) positioning service latency in regard to vehicle's actual or predictive position when moving fast (e.g., more than 30m\/s) (2) verifying operational complexity and cost-effectiveness when only a Uu-interface is used, and (3) improving robust operation in out-of-coverage scenarios. It wouldn't be too early to start Feasibility Study as there is some gap - which we consider a good business opportunity - that can possibly be reduced by technical study in the transport layer so that useful UCs can be made available for achieving safety and efficiency in the near future.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10090,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG RAN, RAN WG1","Cc":"TSG SA, SA WG1","lsoriginalls":"SAE AA TC LS to 3GPP RAN v07a","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200315.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-200316","title":"LS from GSMA SECAG: NESAS Official Launch","source":"GSMA SECAG","contact":"Sven Lachmund","contact-id":62366,"tdoctype":"LS in","for":"Information","abstract":"Introduction: In 2013, SA WG3 asked GSMA to create procedures and a governance scheme to operate and maintain security assurance in the mobile industry. Since then, GSMA's Security Assurance Group (SECAG) has worked on creating a solution that covers both - Equipment vendor's development and lifecycle process security assessment and - Equipment testing by competent test laboratories. In GSMA SECAG, representatives from equipment vendors, mobile network operators and national IT security agencies have worked together to create the Network Equipment Security Assurance Scheme (NESAS). Status Update: GSMA SECAG would like to inform SA WG3 that NESAS Release 1 was approved by GSMA at the end of 2019 and it is now officially launched and operational. All the NESAS documentation and additional information can be found under the following Internet link: https:\/\/www.gsma.com\/nesas SECAG would like to invite SA WG3 to recognise the availability of the complete NESAS documentation and would also like to invite SA WG3 members to promote the use of NESAS within their organisations. Specifically, GSMA recommends network operators to require their suppliers to participate in the scheme, it invites the suppliers to do so and it encourages national authorities to assess how NESAS can complement and enhance local security initiatives. SECAG has decided to maintain and publish a list of all current SCAS documents on the NESAS Web site to allow stakeholders to easily and conveniently access all documents and information pertaining to NESAS and SCAS testing at one location. SECAG assumes this approach is supported by SA WG3 but if there are any concerns or objections SA WG3 should inform GSMA. If publication by GSMA is supported, in order to keep the list up-to-date, SECAG would be grateful to be notified whenever new SCAS documents are published by SA WG3.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10100,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG3","Cc":"TSG SA","lsoriginalls":"SECAG Doc 57_015","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200316.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-200317","title":"LS from ITU-T SG13: LS\/o on the agreement of Supplement 59 to ITU-T Y.3100-series Recommendations 'IMT-2020 standardization roadmap'","source":"ITU-T SG13","contact":"Scott Mansfield","contact-id":42415,"tdoctype":"LS in","for":"Information","abstract":"This document is to inform that SG13 agreed a new Supplement 59 to ITU-T Y.3100-series Recommendations 'IMT-2020 standardization roadmap' at SG13 meeting on 13 March 2020.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10110,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"3GPP, ETSI, BBF, IEEE, ISO\/IEC, MEF, NGMN, TM Forum","Cc":"ITU-R SG5, ITU-T SG2, SG5, SG9, SG11, SG12, SG15, SG17, SG20","lsoriginalls":"SG13-LS150","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200317.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-200318","title":"LS from ITU-T SG3: LS\/o on ongoing work within ITU-T Study Group 3 (SG3) on new Technical Report on 'IMT2020-Related Policy Considering MVNOs'","source":"ITU-T SG3","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"ITU-T Study Group 3 (SG3) draws your attention to its ongoing work on STUDY_IMT2020MVNOs, a Technical Report on 'IMT2020-Related Policy Considering MVNOs', a new work item started at the April 2019 meeting of SG3. At its most recent meeting in April 2020, SG3 received the attached input contribution SG3-C337 from the Internet Initiative of Japan (IIJ), proposing initial draft text for the Technical Report. SG3 plans to discuss this contribution further during its next Q3\/3 Rapporteur Group Meeting (RGM). To help inform our discussion and progress the work, we welcome any feedback you may have on this contribution or on the work item overall. SG3 looks forward to your input and to continued collaboration and cooperation on this topic.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10120,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ITU-T SG13","Cc":"[3GPP], ITU-D SG1, ITU-T SG3 Regional Groups","lsoriginalls":"SG3-LS80","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200318.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-200319","title":"LS from CT WG6: Reply LS to LS on support for eCall over NR","source":"CT WG6","contact":"Amandeep Virk","contact-id":74918,"tdoctype":"LS in","for":"Information","abstract":"As asked by SA in LS SP-200287, CT WG6 has added text to support eCall over IMS over NG-RAN.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10130,"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","Cc":"TSG CT","lsoriginalls":"C6-200332","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200319.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-200320","title":"LS from RAN WG3: LS on port allocation","source":"RAN WG3","contact":"Philippe Reininger","contact-id":35013,"tdoctype":"LS in","for":"Information","abstract":"RAN WG3 discussed the port allocation in the context of the W1 interface and future interface e.g. E1' (CU-UP separation eNB and ng-eNB). RAN WG3 considers that the current port allocation by IANA is cheap and easy to implement and specify and it is robust. It relies on IANA port allocation, a 3GPP specification and a hard coded implementation. Any other solution e.g. based on DNS or OAM will be less efficient, less cost effective and affected by longer time to market, e.g. development, testing etc \u2026 Considering that the issue is not technical, RAN WG3 asks for guidance to RAN either to LS IANA in order to continue the port allocation to the Telecom Industry (3GPP), or to coordinate with CT in order to find an alternative 3GPP solution, or to task RAN WG3 to provide the best alternative for RAN interface port allocation.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10140,"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 RAN, TSG CT","Cc":"TSG SA","lsoriginalls":"R3-202553","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200320.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-200321","title":"LS from SA WG1: Reply LS on Questions on onboarding requirements","source":"SA WG1","contact":"Shuo Wang","contact-id":84932,"tdoctype":"LS in","for":"Information","abstract":"SA WG1 thanks SA WG2 for their incoming LS on Questions on onboarding requirements, and related questions. SA WG1 answers are provided below. SA WG2 raised several questions concerning the following onboarding requirement in SA WG2#136AH meeting. 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. 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. A2 from SA WG2) SA WG2 is asking whether the non-3GPP identities and credentials (provided by authority of the PNI-NPN, e.g. enterprise, factory) for NSSAA or PDU session secondary authentication, can be remotely provisioned to UE which only has normal PLMN credentials and configuration. A2 from SA WG1) Since PNI-NPN is a type of NPN, the above-quoted requirement applies to 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. A3 from SA WG2) SA WG2 is asking whether 3rd party identities and credentials (provided by authority of the PNI-NPN, e.g. enterprise, factory) used for NSSAA and PDU secondary authentication can be provisioned via the 3GPP system to UE, which only has normal PLMN credentials and configuration. A3 from SA WG1) Yes, the case when 3rdparty identities and credentials are provisioned to be used for secondary authentication is a service requirement for onboarding and remote provisioning.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10150,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","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-202266","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200321.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-200322","title":"LS from SA WG2: Reply LS on Questions on onboarding requirements","source":"SA WG2","contact":"Dan Wang","contact-id":72661,"tdoctype":"LS in","for":"Information","abstract":"SA WG2 thanks SA WG1 for their reply for on boarding requirements. SA WG2 have the knowledge of Q1 and would like to provide response for the Q2 and Q3. SA WG2 raised several questions concerning the following onboarding requirement in SA WG2#136AH meeting. 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. 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. A2 from SA WG2) SA WG2 is asking whether the non-3GPP identities and credentials (provided by authority of the PNI-NPN, e.g. enterprise, factory) for NSSAA or PDU session secondary authentication, can be remotely provisioned to UE which only has normal PLMN credentials and configuration. 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. A3 from SA WG2) SA WG2 is asking whether 3rd party identities and credentials (provided by authority of the PNI-NPN, e.g. enterprise, factory) used for NSSAA and PDU secondary authentication can be provisioned via the 3GPP system to UE, which only has normal PLMN credentials and configuration.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10160,"status":"noted","reservation_date":"2020-06-03 14:46:17","uploaded":"2020-06-09 09:41:28","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-2003216","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200322.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-200327","title":"LS from SA WG3: LS on Updated User Plane Integrity Protection advice","source":"SA WG3","contact":"Tim Evans","contact-id":49202,"tdoctype":"LS in","for":"Information","abstract":"SA WG3 has reviewed the information provided by the GSMA regarding user plane integrity protection (UPIP) related attacks on 3GPP 4G and 5G networks. Whilst these attacks are very difficult, require very skilled attackers to exploit and are currently localised attacks based on false base stations, SA WG3 is conscious that once such attacks are known, refinements and the development of tools for less skilled attacks usually follow. SA WG3 advises that it has agreed the following 2 CR's: 1. S3-201442 (attached) - CR to 33.501 (5G security) - Adds an informative annex describing how to secure DNS and ICMP traffic 2. S3-201443 (attached) - CR to TS 33.401 (LTE security) - Adds an informative reference to the informative annex added into TS 33.501 describing how to secure DNS and ICMP traffic Additionally, SA WG3 discussed S3-201457 (attached), but several delegates raised concerns about the impacts of this solution on SA WG2 specifications. SA WG2 are invited to comment as to whether S3-201296 has any adverse impacts.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10170,"status":"noted","reservation_date":"2020-06-09 07:37:57","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG1, SA WG2","Cc":"TSG SA, TSG RAN","lsoriginalls":"S3-201487","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200327.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-200328","title":"LS from SA WG5: LS on network data analysis energy saving","source":"SA WG5","contact":"Jean Michel Cornily","contact-id":7599,"tdoctype":"LS in","for":"Information","abstract":"In S5-201169 \/ S2-1912770 (LS on analytics support for energy saving), SA WG2 describes the following use case related to energy saving in the 5GC: ' In particular, the network data analysis may indicate that all the UEs served by some UPF instances are low priority UEs. Based on this information, the SMF can intentionally re-allocate the low priority UEs among fewer dedicated UPF instances which are used only for serving the low priority UEs at night and running on fewer dedicated servers. As a result, there can be more UPF instances having no UE allocated to them and can be removed by the NFV orchestrator. Consequently, there can be more physical resources, such as servers, to be shut down at night and less energy to be consumed. '. As part of its Rel-17 study item 'Study on new aspects of EE for 5G networks' (FS_EE5G), SA WG5 has studied this use case. From SA WG5 point of view, some points are to be clarified {...} SA WG5 kindly requests SA WG2 to provide feedback on the above analysis.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10180,"status":"noted","reservation_date":"2020-06-09 07:37:57","uploaded":"2020-06-09 09:41:28","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"SA WG2","Cc":"TSG SA","lsoriginalls":"S5-203360","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200328.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-200329","title":"LS from SA WG6: Reply LS on ITU-R WP5D report on the use of IMT for PPDR","source":"SA WG6","contact":"Camilo Solano","contact-id":80091,"tdoctype":"LS in","for":"Information","abstract":"SA WG6 thanks RAN AHG-ITU for forwarding the LS from ITU-R Working Party 5D to provide inputs to update Annex 1 of the Report ITU-R M.2291-1 on the use of international mobile telecommunications (IMT) for broadband public protection and disaster relief (PPDR) applications. SA WG6 has reviewed and provided inputs to Annex 1 based on the working draft report available at RAN AHG-ITU before SA WG6#37-e. SA WG6 has taken up to R16 as the reference release for the provided inputs.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10200,"status":"noted","reservation_date":"2020-06-09 07:37:57","uploaded":"2020-06-09 09:41:29","revisionof":"","revisedto":"","release":"","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"TSG RAN","Cc":"TSG SA","lsoriginalls":"S6-200934","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200329.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-200330","title":"LS from SA WG5: Reply LS on energy efficiency","source":"SA WG5","contact":"Jean Michel Cornily","contact-id":7599,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 thanks RAN WG3 for their Liaison Statement on energy efficiency. SA WG5 would like to inform RAN WG3 that our Rel-16 work item 'Energy efficiency of 5G' is about to be completed and that a Rel-17 study item 'Study on new aspects of EE for 5G networks' (FS_EE5G) and a Rel-17 work item 'Enhancements on EE for 5G networks' (EE5GPLUS) have both been submitted at SA#87e and approved. SA WG5 has discussed RAN WG3 statement that 'a proper measure of data volume per site, needed to calculate the energy efficiency of base stations, needs to be measured at the gNB-DU and can therefore be based on RLC data volumes'. Our understanding is that this can be valid for future cases when one CU-UP may serve gNB-DUs at different sites. SA WG5 would like to highlight that, in case gNBs with geographically distributed gNB-DUs: 1. The existing EE KPI for NG-RAN, defined in TS 28.554, is calculated based on: a) Measuring PDCP Data Volumes (DV) at gNB-CU level, i.e. centrally, b) Measuring Energy Consumption (EC) at each site (at gNB-CU site and at each gNB-DU site), c) Collect all these measurements and calculate the EE KPI 2. According to our understanding of RAN WG3 TR 37.816, the EE KPI would be calculated based on: a) Measuring RLC Data Volumes for each gNB-DU of a given gNB, i.e. at each site b) Measuring Energy Consumption in the same way as in 1b) above. SA WG5 thinks that: a) given that these two measurement methods are different, a new EE KPI would have to be defined; b) though these two measurement methods are different, the resulting EE KPI value, aggregated at gNB level, should be the same. SA WG5 kindly requests RAN WG3 to provide feedback on the above analysis.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10190,"status":"noted","reservation_date":"2020-06-09 07:37:57","uploaded":"2020-06-09 15:21:41","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3","Cc":"RAN WG2, TSG SA","lsoriginalls":"S5-203016","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200330.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-200451","title":"LS from SA WG5: LS on SA5 Rel-17 work on SLA","source":"SA WG5","contact":"Xiaonan Shi","contact-id":83457,"tdoctype":"LS in","for":"Information","abstract":"SA WG5 has cooperated with GSMA 5GJA on implementing NG.116 (v2.0) GST SLA attributes as network slice ServiceProfile attributes in the 3GPP Network Resource Model (NRM) (TS 28.541 clauses 6.3.3, 6.4.1) in the Rel-16 work item Management Aspects of 5G Service-Level Agreement. This work item has been finalised in Rel 16, and a continuing Rel-17 work item Enhancement of Management Aspects of 5G Service-Level Agreement (SP-200190) has been approved. In Rel-17, SA WG5 will continue working on implementing updated GST SLA attributes, as GSMA 5GJA will continue working on NG.116. In addition, SA WG5 will work on breaking down SLA requirements to NetworkSliceSubnet to update the SliceProfile in the 3GPP NRM, which can provide clear requirements to CN, RAN and TN (TS 28.541 clauses 6.3.4, 6.4.1).","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10210,"status":"noted","reservation_date":"2020-06-16 05:14:05","uploaded":"2020-06-16 08:38:17","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"GSMA 5GJA, SA WG2, RAN WG3, IETF TEAS WG","Cc":"TSG SA, SA WG1, SA WG6, RAN WG2, ETSI ISG ZSM","lsoriginalls":"S5-203370","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200451.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-200459","title":"LS from CT WG1: Reply LS on Updated User Plane Integrity Protection advice","source":"CT WG1","contact":"Maurice Pope","contact-id":648,"tdoctype":"LS in","for":"Information","abstract":"CT WG1 thanks SA WG3 for sending the LS and the agreed CRs S3-201442 and S3-201443 in the LS. CT WG1 has discussed SA WG3 requirement mentioned in the attached CRs S3-201442\/43 of the LS and captured the requirements in the CR C1-204119, C1-204120 and C1-204121. The CRs are attached with the LS.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10220,"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":"SA WG3","Cc":"TSG SA, TSG RAN, SA WG2","lsoriginalls":"C1-204194","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200459.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-200460","title":"LS from SA WG2: Reply LS on Statement on UAV Remote ID Priority in Release 17","source":"SA WG2","contact":"Stefano Faccin","contact-id":57487,"tdoctype":"LS in","for":"Information","abstract":"SA WG2 thanks the ATIS UAV Ad-Hoc Group for their LS on UAV Remote ID Priority in Release 17. SA WG2 has defined a set of architectural requirements, architectural assumptions, and a reference architecture aiming at satisfying the requirements related to the support of remote identification of UAVs in 3GPP standards. SA WG2 is discussing solutions and a new version of the Technical Report 23.754 will be available after SA WG2 #139 e-meeting. Companies contributing to the SA WG2 work have considered both the Notice of Proposed Rulemaking published by the Federal Aviation Authority (FAA) in December 2019 in the study work. As a reminder, the study item in Rel. 17 does not consider the use of a 3GPP radio link for Broadcast Remote Identification, as decided in the prioritization of the Rel. 17 work. However, existing 3GPP mechanisms, if any, for supporting such local broadcast are not excluded.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10230,"status":"noted","reservation_date":"2020-06-16 10:57:17","uploaded":"2020-06-16 10:57:37","revisionof":"","revisedto":"","release":"Rel-17","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"ATIS UAV AdHoc Group","Cc":"TSG SA, TSG RAN, SA WG1","lsoriginalls":"S2-2004663","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200460.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-200521","title":"LS from CT WG4: Reply LS on port allocation","source":"CT WG4","contact":"Yong Yang","contact-id":42295,"tdoctype":"LS in","for":"Information","abstract":"CT WG4 thanks RAN WG3 for the LS on port allocation (R3-202553 \/ C4-203405). CT WG4 recommends CT and RAN to request again IANA\/IESG to allocate a port for the W1 interface, to simplify implementations and comply with Rel-16 timeframe. When doing so, CT WG4 also recommends 3GPP to commit towards IANA\/IESG that 3GPP will develop alternative solutions from Rel-17 onwards, i.e. that no further port allocation requests for use in private networks will be issued towards IANA in future, in accordance to IANA instructions. CT WG4 also discussed the following possible alternatives for port allocation for new 3GPP applications\/interfaces in future but couldn't reach a conclusion. Each alternative is further described in the attachment: - 3GPP may specify a port in the Private\/Dynamic Port Numbers range [49152 - 65535] for a new 3GPP application; - Operator may specify a port in the Private\/Dynamic Port Numbers range [49152 - 65535] for a new 3GPP application; - DNS based solution.","secretary_remarks":"Block Noted in CC#1","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10240,"status":"noted","reservation_date":"2020-06-22 07:19:39","uploaded":"2020-06-22 07:29:50","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"RAN WG3, TSG CT, TSG RAN","Cc":"TSG SA, IESG, IANA","lsoriginalls":"C4-203712","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200521.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-200615","title":"LS from TSG CT: Reply LS on port allocation","source":"TSG CT","contact":"Bruno Landais","contact-id":68755,"tdoctype":"LS in","for":"Information","abstract":"TSG CT thanks CT WG4 and RAN WG3 for their LS on Port allocation. The way forward proposed by CT WG4 is endorsed by TSG CT, TSG RAN and TSG SA. TSG CT has asked IESG to approve the request for port number allocation for the W1 interface. CT WG4 is kindly asked to submit a WID for approval at the next TSG meeting, 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.","secretary_remarks":"Noted at CC#3","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10250,"status":"noted","reservation_date":"2020-07-02 12:18:50","uploaded":"2020-07-02 12:19:17","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"CT WG4, RAN WG3","Cc":"TSG RAN, TSG SA","lsoriginalls":"CP-201316","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200615.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-200616","title":"LS from TSG CT: LS on port allocation for the W1 interface","source":"TSG CT","contact":"Bruno Landais","contact-id":68755,"tdoctype":"LS in","for":"Information","abstract":"The 3GPP Technical Specification Groups (responsible of the technical specification development work within 3GPP) have decided to undertake a specific work in Rel-17 on the specification of alternative solutions for port allocation for new 3GPP interfaces from Rel-17 onwards, that will avoid future IANA port number assignment requests for network internal services. The description of the corresponding 3GPP Work Item should be discussed and approved in Sept 2020. The solutions that will be defined in Rel-17 will not be ready for many months and therefore cannot be applied to the W1 interface. Instead due to more urgent timescales, 3GPP needs the approval of the IANA port number assignment request for the W1 interface (IANA#1172452) and asks the IESG to take account of the present situation and give the request due consideration.","secretary_remarks":"Noted at CC#3","agenda_item_sort_order":9,"ainumber":"2.1","ainame":"Incoming LSs - proposed to note","tdoc_agenda_sort_order":10260,"status":"noted","reservation_date":"2020-07-02 12:18:50","uploaded":"2020-07-02 12:19:17","revisionof":"","revisedto":"","release":"Rel-16","crspec":"","crspecversion":"","workitem":"","crnumber":"","crrevision":"","crcategory":"","tsg_crp":"","lsreplyto":"","lsto":"IESG","Cc":"TSG RAN, TSG SA, IANA, RAN WG3","lsoriginalls":"CP-201349","lsreply":"","link":"http:\/\/www.3gpp.org\/ftp\/tsg_sa\/TSG_SA\/TSGS_88E_Electronic\/Docs\/SP-200616.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}]