SP Meeting #SP-89E DRAFT REPORT

15 - 21 September 2020, - Electronic meeting

Source: Secretary of SP

Title: Draft Auto-Generated Report of SP meeting #SP-89E

Document for: Information

Status: This Report Generated 24-09-2020, 10:30

0 Definitions

Noted: A document is "noted" to indicate that its content was made available to the meeting, but that the document itself was not agreed or endorsed by the meeting. Any agreements or actions resulting from discussion of the document are explicitly indicated in the meeting report.

Approved: A document "approved" in this report refers to the status within the WG. For some document types (e.g. CR, WID/SID), the final status of documents are determined at the TSG level, whereas this report always uses "approved", which may be translated in the 3GU document lists as "agreed" (e.g. for CRs).

Agreed (in parallel session): A document is "agreed" at a parallel or drafting session to indicate it's temporary status until the closing WG plenary sessions. The final status is determined in WG plenary sessions or via an e-mail approval process.

IPR Call Reminder:

The Chairman of the meeting made the following call for IPRs, and asked ETSI members to check the latest version of ETSI's policy available on the web server:

The attention of the delegates to the meeting of this Technical Specification Groupwas drawn to the fact that 3GPP Individual Members have the obligation underthe IPR Policies of their respective Organizational Partners to inform theirrespective Organizational Partners of Essential IPRs they become aware of.

The delegates were asked to take note that they were thereby invited:

- to investigate whether their organization or any other organization owns IPRs which wereor were likely to become Essential in respect of the work of 3GPP.

- to notify their respective Organizational Partners of all potential IPRs e.g. for ETSIby means of the IPR Information Statement and the Licensing declaration forms (https://www.3gpp.org/3gpp-calendar/89-call-for-ipr-meetings).

Antitrust declaration:

The Chairman of the meeting made the following Antitrust declaration:

The attention of the delegates to the meeting was drawn to the fact that 3GPP activities were subject to antitrust and competition laws and that compliance with said laws was therefore required by any participant of the meeting including the Chairman and Vice-Chairmen and were invited to seek any clarification needed with their legal counsel. The present meeting would be conducted with strict impartiality and in the interests of 3GPP. Delegates were reminded that timely submission of work items in advance of TSG/WG meetings was important to allow for full and fair consideration of such matters.

Statement Regarding Engagement with Companies Added to the U.S. Export Administration Regulations (EAR).

Entity List in3GPP Activities https://www.3gpp.org/about-3gpp/legal-matters

1. Public Information is Not Subject to EAR

3GPP is an open platform where all contributions (including technology protected or not by patent) made by the different Individual Members under the membership of each respective Organizational Partner are publicly available. Indeed, contributions by all and any Individual Members are uploaded to a public file server when received and then the documents are effectively in the public domain.

In addition, since membership of email distribution lists is open to all, documents and emails distributed by that means are considered to be publicly available.

As a result, information contained in 3GPP contributions, documents, and emails distributed at 3GPP meetings or by 3GPP email distribution lists, because it is made available to the public without restrictions upon its further dissemination, is not subject to the export restrictions of the EAR.

Meeting minutes are maintained for 3GPP meetings. Such meeting minutes for 3GPP meetings are made available to the public without restrictions upon its further dissemination. As a result, information, including conveyed orally, contained in 3GPP meetings is not subject to the export restriction of the EAR.

2. Non-Public Information

Non-public information refers to the information not contained or not intended to be contained in 3GPP contributions, documents or emails. Such non-public information may be disclosed during informal meetings, exchanges, discussions or any form of other communication outside the 3GPP meetings and email distribution lists.

For the duration of the Temporary General License (TGL) issued by the Bureau of Industry and Security (BIS) of the US Department of Commerce on May 20, 2019, there are no restrictions on the release of non-public information to companies added to the Entity List on May 16, 2019, to the extent that information is necessary to maintain, service, or support existing handsets, networks or equipment, or "as necessary for development of 5G standards."

3. Other Information

Certain encryption software controlled under the International Traffic in Arms Regulations (ITAR), even if publicly available, may still be subject to US export controls other than the EAR.

4. Conduct of Meetings

Until further notice, the situation should be considered as "business as usual" during all the meetings called by 3GPP.

5. Responsibility of Individual Members

It should be remembered that contributions, meetings, exchanges, discussions or any form of other communication in or outside the 3GPP meetings are of the accountability, integrity and the responsibility of each Individual Member. In addition, Individual Members remain responsible for ensuring that none of their technical contributions include classified encryption software or other information that is subject to US export control under the ITAR or other applicable US export control regulations.

Individual Members with questions regarding the impact of laws and regulations on their participation in 3GPP should contact their companies' legal counsels.

0.1 Executive Summary

Executive Summary
- Rel-17 stage 2 gets more time - SA WG2 to finish their Studies and start related WIDs in December 2020.
- Rel-17 timeline will be decided in December 2020 between TSGs SA, CT, RAN.
- All meetings (WGs and TSGs) in H1/2021 will be planned as e-meetings.
- New Working Agreement #37 on GUTI reallocation for CIoT endorsed (SP-200870).
- Broadcasting acknowledged to be part of Rel-17.
- AKMA (authentication key management for applications) - existing SA material proposed to be shifted to Rel-17, SA WG3 & SA WG1 will provide related CRs in Q4, TSG CT started related work in Rel-17 only.
- Service Function Chaining (SA SID) - sent back to SA WG1, should be WID.
- MINT (Minimization of Service Interruption) - stage 2 will be done by CT1, as requested (SP-200880).
- Approved: Rel-17 SIDs: 8, Rel-17 WIDs: 10, Rel-18 SIDs: 2.
- SA#89-e was held as a 5 day meeting, with Tuesday to Friday for technical discussion and the Monday reserved for reporting issues only. 2 hour GoToMeeting sessions were held on every day of the meeting.
- E-Meeting output from WG meetings is stable and has high quality, this is reflected by the few issues which were brought up during TSG SA plenary for technical discussion.
- Traceability of Requirements (Enumeration) - a moderated e-mail discussion will be ongoing till TSG SA#90-e, related SA WG1 CRs were postponed.
- Agreement that features which are only partially completed in a release cannot be automatically shifted on all stages / all aspects to the next release - case-by-case investigation of such rare cases is needed.

1 Opening of the Meeting by e-mail

Tuesday, 15 September 2020, 09:00 UTC

1.1 Welcome Speech

1.2 Introduction

1.3 IPR & Antitrust reminders

1.4 Approval of Agenda

(comments and objections need to be sent by mail before start of the meeting)

TD SP-200632 (AGENDA) Agenda & Procedures & Time Schedule for TSG SA#88-e. (Source:TSG SA Chairman).
Document for: Approval.
Abstract: Agenda for the meeting.

Comment:

Approved.

Discussion and conclusion:

CC#1: The meeting agenda was approved.

Status:

Approved.

TD SP-200855 (AGENDA) SA#89-e GoToMeetings Agenda. (Source:TSG SA Chairman).
Document for: Approval.
Abstract: SA#89-e GoToMeetings Conference Calls Agenda.

Comment:

Noted.

Discussion and conclusion:

CC#4: The latest revision of the CC agenda was Rev3. Slide 7 should read 'Friday' rather than 'Thursday'. The agenda (and it's revisions) was noted.

Status:

Noted.

1.5 Report from previous SA meetings

TD SP-200633 (REPORT) Draft report of TSG SA meeting #88E. (Source:TSG SA Secretary).
Document for: Approval.
Abstract: Report of meeting TSG SA#88E for approval.

Comment:

Approved.

Discussion and conclusion:

The report of TSG SA#88-e was approved.

Status:

Approved.

1.6 Reports from TSG SA ad-hoc meetings and workshops

2 Liaisons Statements

2.1 Incoming LSs - proposed to note

Block 1: For Block Noting - Tuesday 15:00 UTC

TD SP-200635 (LS IN) LS from ITU-R WP 5D: LIAISON STATEMENT TO RIT⁄SRIT PROPONENTS ON THE COMPLETION AND CONCLUSIONS OF STEPS 5 TO 7 OF THE IMT-2020 PROCESS FOR THE FIRST RELEASE OF NEW RECOMMENDATION ITU-R M.[IMT-2020.SPECS]. (Source:ITU-R WP 5D (5D_TD_159R1)).
Document for: Information.
Abstract: This liaison is to update you on the progress and results on Working Party 5D Meeting #35e particularly with regard to the completion of Steps 5-7 of the IMT-2020 process and the decisions on which of the candidate technology submissions have move forward to Step 8. ITU-R Working Party 5D (WP 5D) thanks the RIT⁄SRIT Proponents and the GCS Proponents for their work regarding the submissions for IMT-2020 under the IMT-2020 development process. WP 5D has previously informed the relevant External Organizations of the detailed schedule for finalization of the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] 'Detailed specifications of the radio interfaces of IMT-2020' in prior liaison related to two IMT-2020 Documents (IMT-2020⁄20, IMT-2020⁄21). WP 5D notes, for the IMT-2020 process, that it does not anticipate any major adjustments to the planned schedule for the completion of the Recommendation and Step 8 in year 2020 as planned, absent further unanticipated COVID-19 disruptions. It is advised to monitor the WP 5D webpage for any adjustments to dates for either physical or virtual (e-meetings).

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200636 (LS IN) LS from ITU-R WP5D: LIAISON STATEMENT TO TRANSPOSING ORGANIZATIONS ON THE COMPLETION OF STEP 8 OF IMT-2020 PROCESS FOR THE FIRST RELEASE OF NEW RECOMMENDATION ITU-R M.[IMT-2020.SPECS]. (Source:ITU-R WP5D (5D_TD_163R1e_IMT-2020.)).
Document for: Information.
Abstract: This liaison is to update you on the progress and results on Working Party 5D Meeting #35e particularly with regard to the completion of Steps 5-7 of the IMT-2020 process and the decisions on which of the candidate technology submission have moved forward to Step 8. It also identifies specific actions required by a Transposing Organizations with regard to the upcoming tasks, necessary contribution, and actions in the Step 8 work and the associated obligations and the respective timelines. ITU-R Working Party 5D (WP 5D) thanks the RIT⁄SRIT Proponents and the GCS Proponents for their work regarding the submissions for IMT-2020 under the IMT-2020 development process. WP 5D has previously informed the relevant External Organizations of the detailed schedule for finalization of the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] 'Detailed specifications of the radio interfaces of IMT-2020' in prior liaison related to two IMT-2020 Documents (IMT-2020⁄20, IMT-2020⁄21). WP 5D notes, for the IMT-2020 process, that it does not anticipate any major adjustments to the planned schedule for the completion of the Recommendation and Step 8 in year 2020 as planned, absent further unanticipated COVID-19 disruptions. It is advised to monitor the WP 5D webpage for any adjustments to dates for either physical or virtual (e-meetings).

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200637 (LS IN) LS from ETSI ISG E4P: Request for information exchange. (Source:ETSI ISG E4P (E4P(20)000_022)).
Document for: Information.
Abstract: 1. Introduction to ETSI ISG E4P: In the context of a pandemic with a transmittable virus such as SARS-CoV-2, digital contact tracing systems can be used to alert people of a potential risk of infection due to having been in close contact with an infected person. The ETSI ISG E4P (Europe for Privacy-Preserving Pandemic Protection) has been created to develop a framework and consistent set of specifications for contact tracing systems using proximity detection methods. Membership (see link) has grown to about 40 organizations since the ISG launched on 26th May 2020. The framework and specifications will be designed to ensure data privacy and to facilitate the development of interoperable applications and platforms. The working plan of E4P is to produce a comparison between existing systems and four related specifications in a short timeframe. The four specifications will describe the requirements for contact tracing systems (especially privacy preservation), the device-based proximity detection mechanisms, the back-end notification mechanisms and an interoperability framework across multiple systems. The first specifications will be available soon, before end of 2020, so as to be applicable to the existing needs. 2. Exchanging information: With this liaison letter, ETSI ISG E4P would like to inform your members about our work plan, which is visible here: https:⁄⁄portal.etsi.org⁄⁄tb.aspx?tbid=890&SubTB=890#⁄ ETSI ISG E4P would like to kindly invite your organization to share any information that could support the development of the E4P work. In case your organization would like to discuss collaborations, or to highlight work in your group, please contact the Chairman of ETSI ISG E4P.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200639 (LS IN) LS from TM Forum Autonomous Networks: Introduction of TM Forum Autonomous Network project and Coordination Proposal. (Source:TM Forum Autonomous Networks (Liaison AN results ETSI GSMA 3GPPv2)).
Document for: Information.
Abstract: General: There is a growing interest across many Communication Service Providers (CSPs) and their suppliers into the opportunities presented by Autonomous Networks (AN) and Services to substantially improve operational efficiency and enable service innovations through intelligence-driven self-operating of networks and services. TM FORUM started an official project on Autonomous Networks Project (ANP) since July 2019. The scope of the project consists of: - User stories⁄use cases - Vision & roadmap - Business requirements and architecture - Technical architecture The vision of Autonomous Networks in TM FORUM: - The long term vision is to provide innovative ICT infrastructure, capabilities and services with 'Zero X' (zero wait, zero touch, zero trouble, zero friction) experience for the users of vertical industries and consumers through Self-X capabilities (self-serving, self-fulfilling, self-assuring), which makes them simpler to consume by the users, and leaves the implementation complexity with the providers. - Autonomous Networks are likely to evolve step by step according to different autonomous levels, with corresponding services and capabilities. The framework of Autonomous Networks consists of '3-layer, 4-closed-loop' which cover from business operation layer to the network layer, i.e. - 3-layers: business operations layer, service operations layer and resource operations layers, and - 4-closed loops: resource closed loop, service closed loop, business closed loop and more importantly user closed loop from an E2E user perspective. TM FORUM Autonomous network project had published the following documents: 1. Whitepaper: 'Autonomous Networks: Empowering Digital Transformation For Telecoms Industry', May 2019 2. IG1193 'Cross-Industry Autonomous Networks - Vision and Roadmap v1.0', October 2019 3. IG1218 'Autonomous Networks Business Requirements & Architecture v1.0', July 2020, which defined basic concept, vision, framework, autonomous network levels, user stories category, business requirements, architecture and capabilities, as well as example use cases for Autonomous Networks. Further detailed information can be found in attached publications. TM FORUM Next steps: - TM FORUM is now working on the enhanced version of Autonomous Networks Business Requirements & Architecture 1.1 and Autonomous Networks Technical Requirements & Architecture 1.0, and Whitepaper R2.0. All of them are targeted to be published in Oct 2020. - -TM FORUM is seeking the Cross SDO collaboration, starting from this information sharing Liaison and planning a Multi-SDO collaboration workshop in Oct 2020. Cross-SDO collaboration proposal: We noticed that recently Autonomous Network initiatives are being progressed in multiple SDOs. We believe that alignment on Autonomous Network concept, vision, framework and key topics, and discussion on the responsibility and collaboration for the future works would best guide the industry to progress in a coordinated way on this topic. Given that AN initiatives are being progressed in multiple SDO, it would be beneficial for the industry to hold a Cross SDO workshop to review activities, identify key topics and gaps across multiple SDOs towards an industry collaboration ecosystem on Autonomous Networks. Invitation to Cross-SDO Collaboration Workshop on Autonomous Networks: TM Forum is willing to organize a virtual workshop in the last week of September (29th or 30th) to kick off the collaboration discussion on the Autonomous Network. We invite representatives from your organization to the virtual workshop, share information on autonomous network related work in your organization, and also your suggestions on future collaborations. The suggested virtual workshop objectives are: 1. Share information and ideas on the vision, key points and activities of each organizations developing AN solutions using their unique domain skills. 2. Discuss the gaps and key topics in industry activities for reaching industry consensus and building the collaboration ecosystem for E2E AN blueprint. 3. Establish the collaboration proposal and technical topics of common interest as the basis for subsequent multi-SDO discussions for Autonomous Networks. At this stage, we would like to: - Solicit feedback on key topics that you believe would benefit from a discussion at this virtual workshop. - Secure your organizations' interest and commitment in principle to participate in this virtual workshop. Please advise if you can support this proposal by sending one or more representatives and indicating available date for the virtual workshop. Your early reply would be very much appreciated, to help us finalize the virtual workshop agenda. We look forward to your feedback and the opportunity for collaboration. Concluding Remarks: We look forward to your feedback on the enclosed documents on the virtual workshop ⁄ collaboration proposal.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200640 (LS IN) LS from IETF: Re: LS on need for Multi-Path QUIC for ATSSS. (Source:IETF (LS_from_IETF)).
Document for: Information.
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.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200641 (LS IN) LS from IETF DRIP: Drone Remote ID Protocol Working Group (DRIP). (Source:IETF DRIP (LSs_from_IETF_9June2020)).
Document for: Information.
Abstract: Information of the DRIP working group can be found on the following web page: https:⁄⁄datatracker.ietf.org⁄wg⁄drip⁄about⁄ This is where the latest version of the charter can be found - reminded in the following section as well as the status an progress of the WG documents we detail in the following section. Charter for Working Group Civil Aviation Authorities (CAAs) worldwide have initiated rule making for Unmanned Aircraft Systems (UAS) Remote Identification (RID). CAAs currently promulgate performance-based regulations that do not mandate specific techniques, but rather cite industry-consensus technical standards as acceptable means of compliance. One key standard is ASTM International (formerly the American Society for Testing and Materials) WK65041 [1]. This technical specification defines UAS RID message formats, and transmission methods. Network RID defines a set of information for UAS to be made available globally via the Internet. Broadcast RID defines a set of messages for UAS to send locally one-way over Bluetooth or Wi-Fi. WK65041 does not address how to populate⁄query registries, how to ensure trustworthiness of information, nor how to make the information useful. DRIP's goal is to specify how RID can be made trustworthy and available in both Internet and local-only connected scenarios, especially in emergency situations. Some UAS operate in environments where the network or the devices or both are severely constrained [2] in terms of processing, bandwidth (e.g., Bluetooth 4 beacon payload is 25 bytes long), or battery life, and DRIP aims to function in these environments. The specifications produced by the WG will need to balance public safety authorities' need to know trustworthy information with UAS operators' and other involved parties' privacy. The working group will primarily leverage Internet standards (including HIP, EPP, RDAP, and DNS) and infrastructure as well as domain name registration business models. The WG will track and align with the requirements being developed by regulatory authorities, e.g., the International Civil Aviation Organization the European Union Aviation Safety Agency (EASA) delegated [3] and implementing [4] regulations, and the US Federal Aviation Administration (US FAA) [5]. The working group will work on the following items: - Requirements: the WG is expected to provide an informational document that lists the technical requirements for applying IETF protocols to the UAS Remote Identification (UAS RID) - that is the system for identifying Unmanned Aircraft (UA) during flight by other parties. These requirements also include showing that new or adapted identifiers from existing protocols conform and meet the specifications to be certified as a UAS RID. - Architecture: the WG will propose a standard document that describes the architecture that address the technical requirements and that will attempt to re-use protocols or architectures already standardized at the IETF. - Protocol design: while the primary purpose of DRIP WG is to leverage existing protocols, the specificities of the UAS environment are likely to require existing protocols to be extended or new protocols to be designed. The WG will focus on getting these protocols or extensions standardized, coordinating with other WGs relevant for the protocol(s) in question on the most appropriate home for any given piece of work.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200642 (LS IN) LS from ITU-R WP5A: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ON ITS Connected Automated Vehicles (CAV). (Source:ITU-R WP5A (5A_TEMP_29_R1)).
Document for: Information.
Abstract: ITU-R Working Party (WP) 5A has initiated its work on Question ITU-R 261⁄5 'Connected Automated Vehicles (CAV)' and a working document is being developed, see Annex 16 to Document 5A⁄85. Section 3 of this initial draft of the working document contains references to the related ITU-R texts. Working Party 5A kindly requests the interested external organizations to provide material on the description, architecture, applications, technologies, and operational scenarios of CAVs and the radiocommunication requirements for CAVs. The next meeting of Working Party 5A is scheduled for 9-20 November 2020 and the deadline for contributions is 16:00 hours UTC, 2 November 2020.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200643 (LS IN) LS from TSG RAN: Reply LS to RP-200030 on relevant 3GPP Specs for PC5 Sidelink. (Source:TSG RAN (RP-201285)).
Document for: Information.
Abstract: TSG RAN would like to thank 5GAA for the information on the ITU-T Data Base related to the Collaboration on ITS Communication Standards. TSG RAN notices that the SA WG3 TS 33.536 is missing from the list provided by 5GAA. TSG RAN prefers to remove the internal TRs from the list which are 3GPP internal documents. The TSG RAN clarifies that the relevant stage-3 specs can be found in the stage-2 references and adds some key stage-3 specifications.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200644 (LS IN) LS from TSG RAN: Reply LS to GSMA_5GSI_28_Doc003 = RP-193053 on 5G indicator enhancement. (Source:TSG RAN (RP-201358)).
Document for: Information.
Abstract: TSG RAN would like to make the GSMA Network Group (NG) aware of the completion of the activities as requested by the GSMA 5GSI in their LS Reply in RP-193053 sent to RAN#86 in December 2019 (5GSI#28 Doc 003). Within the Ls Reply there was a request for 3GPP to take into consideration the new requirements when defining specifications that impact the display of the 5G status indicator. In order to implement these requirements from GSMA, TSG RAN agreed on introducing enhancements to the existing 5G indicator handling based on the upperLayerIndication bit in the E-UTRA SIB2 and tasked RAN WG2 to introduce further changes to the E-UTRA RRC specification (TS 36.331), please refer to 'LS on 5G Indicator' from RAN to RAN WG2 in RP-193265. During the RAN WG2#110-e meeting the Rel-16 CR to TS 36.331 in R2-2006081 (attached) was agreed and provided to RAN#88e within the RP-201166 CR pack, where the changes suggested in RP-193265 are specified from Rel-16 onwards. It is worth to note that the implementation of this CR from Rel-15 will not cause interoperability issues.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200645 (LS IN) LS from ITU-T SG13: LS⁄o on information about consent of Machine Learning related ITU-T Recommendation Y.3176. (Source:ITU-T SG13 (SG13-LS160)).
Document for: Information.
Abstract: ITU-T SG13 would like to inform you that the new ITU-T Machine Learning related Recommendations Y.3176 'Machine learning marketplace integration in future networks including IMT-2020' (Ref. SG13-TD314⁄PLEN) was consented at the ITU-T SG13 virtual meeting held on 20-31 July 2020. ITU-T SG13 looks forward for future collaboration on topics related to machine learning in future networks including IMT-2020.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200649 (LS IN) LS from CT WG4: LS on AUSF⁄UDM discovery based on SUCI information. (Source:CT WG4 (C4-204337)).
Document for: Information.
Abstract: CT WG4 has analyzed the issue of insufficient length of Routing Indicator within SUCI, see attached discussion paper in C4-204078 for details. The current 4 digits of the Routing Indicator enables only 10 K ranges of subscriptions, which may not provide enough granularity and flexibility for moving subscriptions across UDRs not controlled by the same AUSF⁄UDM, for operators with a large number of subscriptions (e.g. 100 K users per range for a PLMN with 1 billion subscriptions). CT WG4 agreed that the above limitation should be addressed. CT WG4 has also discussed the solution proposed in C4-204339 (attached) for solving this problem, enabling to use the Home Public Key ID as an additional parameter (that allows to encode e.g. a 5th digit, in addition to the key ID on 4 bits) for the discovery of the AUSF⁄UDM. CT WG4 would be fine in principle to specify this solution in Rel-17, provided corresponding stage-2 requirements are agreed first.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

CC#3: This was presented by China Mobile. The TSG CT Chairman asked SA WG2 to make time to progress the Stage 2 enhancement in the next Quarter, to allow CT WG4 to progress with this. The SA WG2 Chairman replied that this will be on the agenda for the e-meeting and will require company contribution of CRs for this, with Category F CRs, as no exception is expected to be produced for Rel-17 work. This remained noted.

e-mail discussion:

Tao (China Mobile) ask for SA discussion on proper way forward in stage 2 so that stage 3 can start.

Status:

Noted.

TD SP-200653 (LS IN) LS from SA WG5: LS reply to LS on M.resm-AI “Requirements for energy saving management of 5G RAN system with AI”. (Source:SA WG5 (S5-204516)).
Document for: Information.
Abstract: SA WG5 (Telecom Management), thanks ITU-T Q5⁄2 for your LS on M.resm-AI 'Requirements for energy saving management of 5G RAN system with AI'. In its Release 16, SA WG5 has worked on use cases and requirements for a) the collection of measurements in the NG-RAN so as to be able to calculate the NG-RAN EE KPI and b) the optimization of this EE KPI by saving the energy of the NG-RAN. The resulting specification is TS 28.310 (Energy efficiency of 5G) (https:⁄⁄portal.3gpp.org⁄desktopmodules⁄Specifications⁄SpecificationDetails.aspx?specificationId=3550) In its Release 17, SA WG5 has started: - a (non-normative) study item on new aspects of EE for 5G networks, aiming to study the definition of new Energy Efficiency (EE) KPIs, and means to measure them, from various aspects including in case of multi-RAT sites, of 5G RAN sharing, of 5G Core Network, of standardized network slice types (eMBB, URLLC, mIoT, V2X), of Virtualized Network Functions, etc. The draft TR 28.813 can be found at: https:⁄⁄portal.3gpp.org⁄desktopmodules⁄Specifications⁄SpecificationDetails.aspx?specificationId=3743; - a (normative) work item on enhancements of EE for 5G networks, to enhance ⁄ complement existing 3GPP Technical Specifications, based on outcomes from the aforementioned study item. Besides, SA WG5 has an ongoing Rel-17 study on enhancement of Management Data Analytics Service (MDAS), whose outcomes are captured in TR 28.809 (https:⁄⁄portal.3gpp.org⁄desktopmodules⁄Specifications⁄SpecificationDetails.aspx?specificationId=3694), where a use case, potential requirements and potential MDAS-based solutions for energy saving in 5G networks are described. Management Data Analytics, in conjunction with AI and ML techniques, brings intelligence and automation to the network service management & orchestration. Finally, SA WG5 would like to highlight that the 3GPP management of 5G networks is specified in terms of Management Services (MnS) such as e.g. Provisioning MnS, Fault Supervision MnS, Performance Assurance MnS, etc. MnS producers expose APIs; authorized consumers may consume MnSs. The Service-based Management Architecture (SBMA) replaces the traditional NMS-EMS-NE architecture (cf. TS 28.533 'Management and orchestration; Architecture framework' - https:⁄⁄portal.3gpp.org⁄desktopmodules⁄Specifications⁄SpecificationDetails.aspx?specificationId=3416). SA WG5 kindly requests ITU-T Q5⁄2 to take the above information into account and provide any feedback if needed. SA WG5 also kindly requests ITU-T Q5⁄2 to keep us informed of the progress of your work on M.resm-AI 'Requirements for energy saving management of 5G RAN system with AI'.

Convenor comment:

Block 1.

Comment:

CC#1: This was block noted.

Discussion and conclusion:

-

Status:

Noted.

2.2 Incoming LSs which need an outgoing LS

LSs with related documents⁄replies

TD SP-200652 (LS IN) LS from SA WG2: LS on RAN impact of FS_5MBS Study. (Source:SA WG2 (S2-2006044)).
Document for: Action.
Abstract: SA WG2 has been discussing on Rel-17 FS_5MBS solutions since SA WG2 #135 meeting in TR 23.757, and captured several proposed solutions. SA WG2 would like to kindly inform RAN WG2 and RAN WG3 the following interim agreements in SA WG2: - SA WG2 will develop means to provide QoS requirements for an MBS Session to RAN nodes. - SA WG2 agrees that for N3 transport of the shared delivery method of MBS data, GTP-U tunnelling using a transport layer IP multicast method and shared N3 (GTP-U) Point-to-Point tunnel shall be supported from MB-UPF to NG-RAN nodes. This tunnel can use either IP multicast transport (NG-RAN sends IGMP⁄MLD Join⁄Leave to a multicast router) or point-to-point unidirectional N3 tunnels from MB-UPF to NG-RAN nodes. For unicast transport there shall be 1-1 mapping between MBS Session and GTP-U tunnel towards a RAN node, and for multicast transport there shall be 1-1 mapping between MBS Session and the GTP-U tunnel. - SA WG2 agreed that the UE shall be able to receive on-going data of a multicast MBS session while in CM-CONNECTED state. - Based on SA plenary decisions, Key Issue #5 ('Support of Broadcast TV Video and Radio communication services') is out of scope of Rel-17. {. . .}.

Comment:

Response drafted in SP-200810. Final response in SP-200884.

Discussion and conclusion:

-

Status:

Replied to.

TD SP-200809 (DISCUSSION) Discussion on support for broadcast in Rel-17 MBS. (Source:Huawei, HiSilicon).
Document for: Endorsement.
Abstract: Proposal: The scope of Rel-17 5MBS SID remains as it is (i.e. NR broadcast is included), and no further down-scoping or prioritization is needed.

Comment:

Noted.

Discussion and conclusion:

CC#1: This was noted.

Status:

Noted.

TD SP-200810 (LS OUT) [DRAFT] Reply LS on RAN impact of FS_5MBS Study. (Source:Huawei [SA]).
Document for: Approval.
Abstract: To: TSG RAN, SA WG2. CC: RAN WG2, RAN WG3.

Comment:

Response to SP-200652. SP 200810_Rev2 was approved. (To be revised into a new TD number by MCC). Revised to SP-200884.

Discussion and conclusion:

CC#1: Response to SP-200652. Huawei introduced this proposed response LS which states that the NR Broadcast is within the scope of the SID. Qualcomm commented that there is also a discussion in TSG RAN on this LS and requested more time to determine the results of those discussions before agreeing a response from TSG SA. It was understood that a response LS will be needed from this meeting. This should be discussed over e-mail.
CC#3: SP 200810_Rev2 was provided. It was noted that the document file in the zip was marked rev3, although it was rev2 on the zip file. SP 200810_Rev2 was approved. (To be revised into a new TD number by MCC).

e-mail discussion:

Haris (Qualcomm) proposes that SA conveys the message to SA2 that for NR broadcast SA2 needs to spend more time to document more solutions
Wanqiang (Huawei) give the feedback on QC proposal and make further update.
Andy (Samsung) comments on rev2, provides rev3.

Status:

revised into a new TD number by MCC). Revised to SP-200884.

TD SP-200884 (LS OUT) Reply LS on RAN impact of FS_5MBS Study. (Source:TSG SA).
Document for: Approval.
Abstract: To: TSG RAN, SA WG2. CC: RAN WG2, RAN WG3.

Comment:

Revision of SP-200810_Rev2. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200871 (LS IN) LS from TSG RAN: Reply LS on RAN impact of FS_5MBS Study. (Source:TSG RAN (RP-202086)).
Document for: Action.
Abstract: Regarding the following question, that SA WG2 asked RAN to feedback on: SA WG2 is debating whether broadcast (i.e. without the network's awareness about UEs receiving broadcast contents and for other use cases than the ones excluded already for Rel-17) should be further down-scoped in Rel-17 for remaining broadcast requirement in the SID. Some companies have provided solutions on broadcast (which are documented in the TR). SA WG2 would like to ask SA, RAN, RAN WG2 and RAN WG3 for feedback on broadcast support in Rel-17. RAN would like to clarify that NR-based broadcast is within the scope of RAN WI for NR MBS in Rel-17, as per the WID approved in RP-201038. According to the discussion at RAN#89e, it is concluded that the scope of RAN WI for NR MBS in Rel-17 is kept as was. RAN would like to ask TSG SA and SA WG2 to take the above answer into account.

Comment:

Related to incoming LS in SP-200652. CC#4: This LS was noted.

Discussion and conclusion:

CC#4: This LS was noted.

Status:

Noted.

TD SP-200634 (LS IN) LS from IALA: Liaison Note to TSG SA - Request for information. (Source:IALA (C71-11.5.1)).
Document 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.

Comment:

Postponed SP-200310 from SA#88E. Response drafted in SP-200655. Final response in SP-200877.

Discussion and conclusion:

-

Status:

Replied to.

TD SP-200655 (LS OUT) [DRAFT] Reply LS on request for information from IALA. (Source:SyncTechno Inc.).
Document for: Approval.
Abstract: This contribution is the reply liaison on request information from IALA.

Comment:

Response to SP-200634. MCC will need to revise to remove 'draft'. Revised to SP-200877.

Discussion and conclusion:

CC#1: SyncTechno Inc introduced this proposed response LS. This LS was approved. MCC will need to revise to remove 'draft'. Revised to SP-200877.

Status:

Revised to SP-200877.

TD SP-200877 (LS OUT) Reply LS on request for information from IALA. (Source:TSG SA).
Document for: Approval.
Abstract: To: IALA, SA WG1.

Comment:

Revision of SP-200655. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200654 (LS IN) LS from CT WG1: LS on the stage 2 aspects of MINT. (Source:CT WG1 (C1-205332)).
Document for: Action.
Abstract: CT WG1 has discussed a WID proposal for CT aspects of Minimization of Service Interruption (MINT-CT) in the CT WG August meetings, in order to support the service requirements specified for Rel-17. The WID on MINT-CT includes a study phase on both stage-2 and stage-3 aspects. CT WG1 is also planning to define end-to-end call flow regarding registration after selection of a disaster roaming PLMN in the stage-2 specification owned by CT WG1. CT WG1 would like to ask TSG SA if there is any concern on this approach. CT WG1 expects any feedback on this way forward until the next WG meeting so that both study phase and normative phase can progress within Rel-17 timeframe. Action: CT WG1 kindly asks TSG SA to take the information above into account and to provide feedback.

Comment:

Response drafted in SP-200775. Final response in SP-200880.

Discussion and conclusion:

-

Status:

Replied to.

TD SP-200774 (DISCUSSION) Discussion on the WI MINT. (Source:LG Electronics).
Document for: Endorsement.
Abstract: Discussion paper for LS from CT WG1 (C1-205332) on the stage 2 aspects of MINT.

Comment:

Noted.

Discussion and conclusion:

CC#1: LGE presented these background discussion slides. It concludes that there is no concern on the approach suggested by CT WG1. This was then noted.

Status:

Noted.

TD SP-200775 (LS OUT) [DRAFT] Reply LS on the stage 2 aspects of MINT. (Source:LG Electronics).
Document for: Approval.
Abstract: [DRAFT] Reply LS on the stage 2 aspects of MINT (CT WG1 LS, C1-205332).

Comment:

Response to SP-200654. CC#1: A revision will be provided based on the comments received. SP 200775_rev3 was approved. (This will be cleaned up and revised into a new TD number by MCC). Revised to SP-200880.

Discussion and conclusion:

CC#1: LG Electronics introduced this proposed response LS which indicates that there is no concern on the approach suggested by CT WG1. MediaTek raised some concerns on how the UE will be informed about the use of disaster recovery networks. Vodafone commented that also cases of network overload needs to be taken into consideration to prevent one failing network overloading it's neighbouring network, causing it's failure, and so on. AT&T suggested that in order to be able to manage prioritisation correctly, if there is work needed in other groups, such as SA WG1 or SA WG2, that this is determined before leaving everything to CT WG1. MediaTek commented that the information to the UE is necessary and whether there are existing solutions for this or not, SA WG2 will need to be involved in this. Vivo commented that CT WG1 could indicate that provision of such a list is TBD, so that SA WG2 could handle this later. Huawei agreed with Vivo that this is network selection related and should be lead by CT WG1 and LSs used to get information needed from other WGs. The LS should be updated to take these concerns into account. LG Electronics stressed that this is a needed feature for South Korean operators. LG Uplus supported the way forward and would like to see work started as soon as possible. This should be discussed over e-mail and a revision proposed.
CC#3: SP 200775_rev2 was provided. There was some discussion and a further revision was proposed by Vodafone in _rev3. SP 200775_rev3 was approved. (This will be cleaned up and revised into a new TD number by MCC).

e-mail discussion:

Chia-Lin (MediaTek) still think SA2 should be involved from the study phase Hyunsook (LGE) initiates discussion for the revision of SP-200775, and provides rev1. Guillaume (MediaTek) can agree moving forward as proposed Hyunsook (LGE) provides comments. Chris (Vodafone) believes that it will be OK for CT (1) to open a SID on this topic provided that the study includes the topics of protecting non-failed PLMNs and recovering PLMNs from signalling overload. Once the STUDY is completed, 3GPP should then decide on how to proceed with any normative work. Hyunsook (LGE) think Chris's suggestion is same to CT1 approach. CT1 LS already describes a study phase, and as usual CT1 business, CT1 will have normative work based on study results. Chris (Vodafone): it is OK for CT(1) to commence a SID but NOT to include a normative work in it. The SID needs to include at least: a) How one PLMN failure does not lead to signalling overload in other PLMNs; and b) how to avoid 'returning UEs' overloading the PLMN that had earlier failed. Chris (Vodafone): it is OK for CT(1) to commence a SID but NOT to include a normative work in it. The SID needs to include at least: a) How one PLMN failure does not lead to signalling overload in other PLMNs; and b) how to avoid 'returning UEs' overloading the PLMN that had earlier failed.
Hyunsook (LGE) think Chris's suggestion is same to CT1 approach.
CT1 LS already describes a study phase,
and as usual CT1 business, CT1 will have normative work based on study results.

Status:

revised into a new TD number by MCC). Revised to SP-200880.

TD SP-200880 (LS OUT) Reply LS on the stage 2 aspects of MINT. (Source:TSG SA).
Document for: Approval.
Abstract: To: CT WG1. CC: TSG CT, SA WG2, SA WG3, CT WG3, CT WG4.

Comment:

Revision of SP-200775_Rev3. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200814 (DISCUSSION) The Importance of Maintaining Broadcast Services in Rel-17 NR MBS. (Source:CBN, ABS, ABP, China Telecom, China Unicom, IRT, Reliance Jio).
Document for: Decision.
Abstract: Broadcast is essential to NR MBS - SA WG2 is debating whether broadcast (for other use cases than the ones excluded already for Rel-17) should be further down-scoped in Rel-17 for remaining broadcast requirement in the SID. Some companies have provided solutions on broadcast (which are documented in the TR). SA WG2 sent an LS to SA asking the above question. - NR MBS with only multicast is just a feature improving network efficiency. With Broadcast, NR MBS creates new business models serving more scenarios, as well as enabling the 5G refarming of the broadcast-dedicated spectrum in many countries. - Down-scoping broadcast will cause NR MBS incapable to deal with emerging demand in many new businesses for 5G NR. NR Broadcast: Enable new business cases - Public Services - Government and public service entities have urgent demand for 5G-enabled innovative ways of communicating with citizens. Broadcast shall be adopted to more efficiently deliver real-time emergency multi-media notifications to a wide variety of devices under the scope of public safety (like disaster warning, security, pandemic control, etc.). - Multimedia Live Streaming in crowed activities(Concerts⁄Sport Games) - Innovative broadcast services like Multi-angle live viewing, game statistics broadcasting, XR enhanced viewing, etc. Broadcast mode is essential for such highbitrate-high-concurrency services. CBN is planning to showcase innovative NR MBS broadcast services in Beijing Olympic Winter Games 2022. - Massive IoT - Identical content needs to be distributed to a massive number of devices like smart home appliances. It is inefficient to use unicast⁄multicast for this, but ideal for broadcast. It makes OTA (over-the-air) firmware upgrades⁄group messaging⁄etc. much more efficient. - V2X - Broadcast enables vehicles to efficiently communicate with the network and its surroundings, making the network to more efficiently deliver real-time information, such as software and traffic updates, as well as the emergency Multimedia notifications to the vehicle driver⁄passengers.

Comment:

Noted.

Discussion and conclusion:

CC#1: This was related to the LS in SP-200810. CBN presented these slides, which argues against reducing the scope of the broadcast work, as this is needed for many new business demands on 5G NR. FirstNet supported this proposal and added that all Mission Critical procedures use broadcast and do not use multicast. AT&T, SynchTechno, Huawei, ZTE supported this contribution proposal. Qualcomm asked what was intended for massive IoT work on this. ZTE added that the original scoping of Rel-17 should not be changed now. FirstNet asked all delegates with interest in Mission Critical to also follow and contribute to this topic in the TSG RAN meeting. This was then noted.

Status:

Noted.

Block 2: For Block Noting - Wednesday 15:00 UTC

TD SP-200638 (LS IN) LS from ITU-T JCA-IMT2020: LS on Invitation to update the information in the IMT2020 roadmap. (Source:ITU-T JCA-IMT2020 (JCA-IMT2020-O-015-R1_LS08)).
Document for: Action.
Abstract: The ITU-T Joint Coordination Activity for IMT2020 (JCA IMT2020) thanks all that have replied to previous requests for input on IMT-2020 related standardization work. The current online version of the roadmap is available from the JCA-IMT2020 website. The Objective: of the roadmap is to support IMT-2020 standardization coordination. IMT-2020 is an important topic for our industry, and many standardization-related activities are held in various entities. The JCA is progressing this work in a form of roadmap of IMT2020 standardization. JCA-IMT2020 will keep updating this roadmap, and therefore we solicit your information about updates. If you send us the latest information of your activity related to 5G as well as Network Function Virtualization (NFV), programmable networks, self-managed networks, slicing (including orchestration and capability exposure), fixed-mobile convergence (FMC) and Information-Centric Networking (ICN), machine learning and other activities that are strongly related to IMT 2020, we will reflect it in the next roadmap update, which will be performed online soon after the next JCA IMT2020 meeting. Please submit your updates using the template to be found in appendix below. Should you wish to communicate any additional information about your specifications and projects, we invite you to do so. In addition, if not done yet, we invite the ITU-T Study Groups, SDOs, fora to nominate a representative to this group. JCA-IMT2020 anticipates having its next meeting in 2021, modalities and exact date⁄timing will be fix and communicated later. We invite your inputs⁄updates to the roadmap.

Comment:

Response drafted in SP-200856. Final response in SP-200887.

Discussion and conclusion:

-

Status:

Replied to.

TD SP-200856 (LS OUT) [DRAFT] Reply to LS on Invitation to update the information in the IMT2020 roadmap. (Source:Samsung).
Document for: Approval.
Abstract: To: .ITU-T JCA-IMT2020.

Comment:

Created at meeting. Response to SP-200638. MCC will need to revise to remove 'draft'. Revised to SP-200887.

Discussion and conclusion:

Created at meeting. Response to SP 200638. CC#2: There were no adverse comments and this LS was approved. (MCC will need to revise to remove 'draft' so there is time for final review and comments).

Status:

Revised to SP-200887.

TD SP-200887 (LS OUT) Reply to LS on Invitation to update the information in the IMT2020 roadmap. (Source:TSG SA).
Document for: Approval.
Abstract: To: .ITU-T JCA-IMT2020.

Comment:

Revision of SP-200856. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200646 (LS IN) LS from TM Forum: TM Forum implementation experiences 3GPP NRM Models. (Source:TM Forum (Liaison 3GPP SA5 TM Forum SID and NRM Models)).
Document for: Action.
Abstract: Several TM Forum Members have participated in a series of 5G related Proof of Concept Catalyst projects beginning in 2016. These Catalyst have generally focused on 5G enabled services that are exposed to industry vertical applications, such as media, emergency services, remote maintenance, etc. The common elements of these Catalysts have been captured by the Open Digital Architecture (ODA) Production team into a model for exposing 5G Enabled services in GB999 ODA Production Implementation Guidelines v4.0 The essential elements in this work for 5G implementation are captured in IG1211 ODA 5G Management Implementation Guidelines v1.0. The key elements are: - Use of TMF909 API Suite Specification for NaaS v3.0.1 for 5G enabled exposed services. - Mapping from operations domains exposing NaaS API using TM Forum Information Framework (SID) Customer Facing Service (CFS) models to resource level models from 3GPP as realised by 5G vendors. The Business rationale and requirements for this approach are documented in IG1194 Focus on Services not Slices v1.0.1 Which also covers the use of the GSMA GST ⁄ NeST attributes. Liaison Many of our Communication Service Providers have been asking for practical guidance on how to integrate OSS⁄BSS solutions based on TM Forum Management standards with Resource level solutions emerging from network technology focused SDO including 3GPP for 3⁄4⁄5G technologies. This has stimulated the production of the documents listed below for which SA WG5 feedback would be appreciated and for which focussed joint liaison work might be required for onward evolution of TM Forum and 3GPP assets. The two pieces of detailed modelling work are attached in: - IG1217 Resource Inventory of 3GPP NRM for Service Assurance v1.0 which describes how to practically map from 3GPP Network Resource Models (NRM) to TM Forum information models (SID) and Open APIs (REST) with JSON data models using Resource Inventory as an exemplar. - IG1211 ODA 5G Management Implementation Guidelines v1.0 which provides guidelines for five implementation questions that have arisen from members and extends IG1217 to cover concepts such as models for Resource Functions to model Network Slice and Network Slice Subnet with associated JSON representations. These impact three current 3GPP documents: - TS 28.620 Fixed Mobile Convergence (FMC) Federated Network Information Model (FNIM) Umbrella Information Model (UIM) (Release 15) - TS 32.107 Fixed Mobile Convergence (FMC) Federated Network Information Model (FNIM) (Release 15) - TR 28.805 Study on management aspects of communication services (Release 16) And there are impacts on the GSMA GST slicing model which are referenced in TR 28.805. {. . .} We look forward to your feedback and the opportunity to collaborate further though direct discussion. Regards, Cecilia Ortega Lagos TM Forum.

Convenor comment:

Block 2.

Comment:

CC#2: This was Block Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200647 (LS IN) LS from SA WG2: LS on mandatory support of full rate user plane integrity protection for 5G. (Source:SA WG2 (S2-2006181)).
Document for: Action.
Abstract: SA WG2 thanks SA for their LS on mandatory support of full rate user plane integrity protection for 5G. SA WG2 would like to inform SA that SA WG2 fulfilled SA's request to mandate UE support of full rate user plane integrity protection for architecture option 2 in Release 16 via the agreement of the attached Release 16 CRs. Regarding support of full data rate user plane integrity protection for other architecture options in Release 17, SA WG2 expects SA WG3 to take the lead on specifying solutions for other architecture options and will update their specification after SA WG3 agrees normative requirements. Action: SA WG2 asks SA group to take the information above into account.

Convenor comment:

Block 2.

Comment:

CC#2: This was Block Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200648 (LS IN) LS on mandatory support of full rate user plane integrity protection for 5G. (Source:CT WG1 (C1-205392)).
Document for: Action.
Abstract: CT WG1 thanks TSG SA for their LS on mandatory support of full rate user plane integrity protection for 5G. CT WG1 would like to inform TSG SA that CT WG1 fulfilled TSG SA's request to mandate UE support of full rate user plane integrity protection for architecture option 2 in Release 16 via the agreement of the attached Release 16 CR. Regarding support of full rate user plane integrity protection for other architecture options in Release 17, CT WG1 expects SA WG3 to take the lead on specifying solutions for other architecture options and will update their specification after SA WG3 agrees normative requirements. Action: CT WG1 asks TSG SA group to take the information above into account.

Convenor comment:

Block 2.

Comment:

CC#2: This was Block Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200650 (LS IN) LS from RAN WG2: Response LS to TSG SA on mandatory support of full rate user plane integrity protection for 5G. (Source:RAN WG2 (R2-2008643)).
Document for: Action.
Abstract: RAN WG2 would like to thank TSG SA#88-e for their LS on 'mandatory support of full rate user plane integrity protection for 5G' [SP-200617] and the decision for which architecture options the requirement shall apply from Rel-16 onwards. RAN WG2 has discussed the request from SA#88-e and concluded that the requirement shall apply for NR connected to 5GC (aka Architecture Option 2) and further that it applies for NR-DC (handled in RAN terminology under the MR-DC framework), which has no explicit 'Option notation'. As RAN WG2 concluded based on company input that NR-DC would absolutely make sense considering the request from SA and the technical challenges are negligible once the UE implemented support for full rate UPIP for SA Option 2; based on this technical analysis RAN WG2 also decided to apply the mandatory full rate UPIP for NE-DC with MN terminated bearers as technically this is similar to NR-DC and covered in RAN WG2 already under the MR-DC framework. NE-DC with SN terminated bearers (i.e. in the eNB) should be subject to the further work in SA WG3 for Rel-17 and should consequently being covered in their new WI. RAN WG2 agreed during it's RAN WG2#111e meeting two CRs to reflect the UE requirements for Rel-16 in TS 38.300 [R2-2008513] and TS 37.340 [R2-2008639]. Regarding the addition of NE-DC with MN terminated bearers into the agreement, RAN WG2 would like to advise CT WG1 and SA WG2 to check their related changes to their specifications for any cross-WG inconsistency. To conclude corresponding work for other Architecture options in Rel-17, RAN WG2 will wait for the outcome of the discussions in SA WG3, looking forward receiving related requirements. Action: RAN WG2 asks TSG SA, CT WG1, SA WG2, SA WG3, TSG RAN and TSG CT to take the decisions above of RAN WG2 into account and note that the request by SA#88e has been accomplished for Rel-16. It should be especially noted that based on the discussions in RAN#111e NR-DC and NE-DC with MN terminated bearers are also already part of the agreement in RAN WG2.

Convenor comment:

Block 2.

Comment:

CC#2: This was Block Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200651 (LS IN) LS from RAN WG3: Reply LS on mandatory support of full rate user plane integrity protection for 5G. (Source:RAN WG3 (R3-205653)).
Document for: Action.
Abstract: RAN WG3 would like to thank TSG SA for the LS on mandatory support of full rate user plane integrity protection for 5G. RAN WG3 has analysed the agreed CR to TS 33.501 in SP-200628 and thinks that this does not impact RAN WG3 specifications. Regarding release 17, RAN WG3 intends to wait for SA WG3 to analyse the impact on security requirements and architecture. RAN WG3 will follow up based on SA WG3's conclusions. Action: RAN WG3 kindly asks TSG SA, TSG RAN, TSG CT, SA WG2, SA WG3, RAN WG2, and CT WG1 to take the above information into account, and inform RAN WG3 of further progress on this topic.

Convenor comment:

Block 2.

Comment:

CC#2: This was Block Noted.

Discussion and conclusion:

-

Status:

Noted.

3 Items for discussion and early consideration

3.1 Challenges to working agreements (Must have been previously requested)

3.2 Issues highlighted for early treatment (Please contact the chairman in advance)

3.3 Discussion papers on work in Rel-15 and earlier

3.4 Discussion papers on work in Rel-16

TD SP-200795 (DISCUSSION) On 5G GUTI reallocation for CIoT. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: Discusses the requirement of 5G GUTI re-allocation and how it impacts the CIoT signalling transactions.

Comment:

Noted.

Discussion and conclusion:

CC#1: Huawei supported Option 1, which was the preference of the majority of companies in CT WG1. Intel supported Option 1. Ericsson commented that it has traditionally been an operator decision depending on the security risks inherent and supported Option 2. Nokia preferred Option 1. MediaTek supported Option 1. Vodafone commented that assuming the mandatory requirement was only in the SA WG3 TS and not the CT WG1 TS, in reality Option 2 will be implemented. As many IoT devises are likely to be used by individual users, there is likely to be a large exposure risk to users. Qualcomm commented that the complication was dependent on whether the signalling procedures allow the allocation of a new 5G GUTI or not. Vodafone replied that in this case Option 1 was preferred. Sony supported Option 2. This document was then noted.

Status:

Noted.

TD SP-200796 (LS OUT) [DRAFT] LS On 5G GUTI reallocation for CIoT. (Source:Qualcomm Korea).
Document for: Approval.
Abstract: Provides instructions on allocating new 5G GUTI at every signalling transaction trigged by paging.

Comment:

CC#1: This LS was left for further consideration over e-mail. CC#3: This was left for further off-line discussion. CC#4: SP-200796_Rev1 was approved. Revised to SP-200883.

Discussion and conclusion:

CC#1: This LS was left for further consideration over e-mail.
CC#3: SP-200796_Rev3 was the latest proposal. Qualcomm commented that they objected to Rev3. Ericsson commented that it was unfortunate that there were 'hidden agendas' in companies leading to a blocking in progress on these discussions. Intel asked how urgent it was to make a decision at this meeting and whether SA WG3 would be asked to further discuss this. Nokia commented that SA WG3 had already discussed this extensively and supported the proposal of Qualcomm and asked to consider the latest proposals. Huawei commented that no further progress can be expected from SA WG3 and suggested making a Working Agreement if this cannot be resolved. Ericsson commented that there is higher security being considered for this feature, rather than lower, and there are studies done by outside bodies which identify the difficulties of different methods of tracking UE identities and recommended companies review these. The TSG SA Chairman commented that a Working Agreement on the LS may not be possible and will check on this as a possibility if required. This was left for further off-line discussion.
CC#4: Sony objected to approving the original LS. The proposal for a way forward in SP-200870 was reviewed and a Working agreement was established based upon it. Ericsson asked to clarify in the LS that the statement is based upon an unconfirmed working agreement. Orange asked to use the normative terminology of the working agreement in the LS. The LS was revised accordingly. Qualcomm asked whether the LS was still needed if SP-200870 can be endorsed. The SA WG3 chairman asked whether companies need to bring CRs to SA WG3 based on the working agreement or whether the leadership needs to identify the CRs. Objections on these CRs based on objection to the working agreement should not be allowed, but objections for other valid technical reasons need to be resolved. The SA WG2 Chairman asked if there are objections to a number of CRs, it may be difficult to determine whether the objections are valid with respect to the Working Agreement. Such CRs which have sustained objections can either be brought by the WG to TSG SA for resolution or can be contributed directly to TSG SA by company contribution. Ericsson commented that TSG SA has had a procedural discussion and SA WG3 should be expected to do a full analysis of this issue before agreeing to CRs. The SA WG2 Chairman asked to add that WGs take the working agreement into account and provide relevant CRs into account. The working agreement in SP-3200870 should be referenced and attached to the LS. Qualcomm provided the updated LS in SP-200796_Rev1. SP-200796_Rev1 was approved. (This will be revised by MCC into a new TD number with correction from TSG SA#90-e to TSG SA#89-e).

e-mail discussion:

Haris (Qualcomm) starts email discussion
Krister (Ericsson) states that me the option 1 is a special case of option 2. As said I see that the frequency of refresh of a temporary identifier is decided by the network operator. The operator may then configure AMF so option 1 is the behavior. That can be the correct behavior for normal UEs as there is a risk of an attack of tracking a UE, which is a privacy concern for the user.
There may be other IoT devices which does not have the same strict privacy requirement, and as such could benefit from a less often refresh of GUTI. The gain would be in signaling optimizations.
Wanqiang (Huawei) comment that option 2 brings extra complexity and makes the system unmanageable. It is not a reasonable approach to move forward.
Johannes (Deutsche Telekom) supports option1 and supports the text in the LS as is. DT ranks the privacy and security issues as higher priority than optimizations. Exception to the existing procedures shall not be granted.
Lars (Sony) comment that option 1 will bring extra complexity and new triggers for AMF to perform UCU. And ask a question on the privacy issue.
Krister (Ericsson) comments that there is has only been a discussion here about privcay related to tracking a UE moving. No other security related issues identified.
Johannes (Deutsche Telekom) clarifies that option1 reflects the specified solution of 5GS and option2 is the request for exceptional hanlding of certain UEs in 5GS
Lars (Sony) option1 goes beyond the existing procedures.
Haris (Qualcomm) provides response to Wangqiang
Erik⁄Andy (Samsung) supports option 1, as there is privacy threat.
Hucheng(CATT) supports option1, but thinks, if understanding is correct, the wording of option 1 could be enhanced:
'Option 1: Allocation of a new 5G-GUTI temporary identifier to the UE in IDLE mode in response to paging in 5G is mandatory and shall apply in all cases including all CIoT optimisations'
From the clarifying question(s) I (Chris, Vodafone) asked in the Tuesday web call, I understand that the options are actually:

Option 1: the standards shall enable GUTI reallocation at every Mobile Terminating RRC connection establishment.

Option 2: the standard prevents GUTI reallocation at every Mobile Terminating RRC connection establishment.

In which case Vodafone prefers option 1.
Haris (Qualcomm) observes that there is preference to go with Option 1 and suggests companies to propose comments to the wording
Orange supports Option 1.

While Option 2 may give operators the flexibility of managing the (signalling) optimization which can be of significance for CIoT devices⁄applications without temporary GUTI allocated each time paging is performed, it may introduce some extra complexity, if, e.g. the exception should be given by HPLMN and⁄or VPLMN in roaming, when and for what CIoT devices⁄applications should be given the exception, even if it is configurable. This may adversely affect the optimization intended by Option 2.

In addition, SA3 has already clearly defined in TS33.501 from Release 15 that the mandatory allocation by AMF of a new 5G-GUTI temporary identifier to the UE in response to a Paging message as a security and privacy protection enhancement of 5G. Option 2 would cause some mis-alignment and even contradictions with the SA3 specifications and open up more discussions⁄work in SA2, SA3 and CT1 at least about to dynamically configure GUTI for those that requires enhanced security for some CIoT devices⁄applications vs those that may have less security constraints. This may adversely affect achievable optimization after all.
Saad (Interdigital). Interdigital also preferers option 1.
Wanqiang (Huawei) provides further comments regarding the update from Ericsson and propose to stick to the original text in SP-200796.
Krister (Ericsson) provides update of the text in option 1. Option 1: Upon receiving a temporary identifier (S-TMSI or I-RNTI) sent by a UE in response to a paging message, it is mandatory for the network to re-allocate the used temporary identifier that was sent in the response message from the UE. This requirement is valid for any type of UE.
Haris (Qualcomm) provides response to Chris(Vodafone)
Lars (Sony) provides further comments on the privacy issue.
Krister (Ericsson) asks Wanqiang to explain the loose comment which missed to explain 'track the link'. Ericsson can not agree the original text of QC as it is not covering the 3rd case that I describe below.
Wanqiang (Huawei) provides response and ask further question.
Lars (Sony) We support Krister's alternative option 1 wording.
Haris (Qualcomm) comments that the thread is for the approval of original or potentially revised text in SP-200796 and the text in SP-200795 is not going to be further modified since the paper is already noted
Krister (Ericsson) provides provide revision to the draft LS in rev1.
(Samsung) provides details on the privacy threat. Clarifies that temporary identifiers (S-TMSI and⁄or I-RNTI) that were used in the paging message and sent by a UE in response to a paging message should be re-allocated. Re-allocation of I-RNTI is mandated by TS 33.501, similarly 5G-GUTI needs to be reallocated.
Lars (Sony) we support rev1 of the LS.
Patrice (Huawei) proposes to produce a slide with the statement for working agreement based on the original proposal.
Haris (Qualcomm) agrees with the proposal from Patrice and produces first draft
Krister (Ericsson) provides response giving an explanation how the failure case also will be handled including a S-TMSI reallocation taking place. Ericsson clear see that that the text proved by Ericsson in LS response rev1 covers mandatory re-allocation requirement needed to handle the privacy issue of tracking threat.
Wanqiang(Huawei) supports the draft from Haris and provides a small update.
Lars(Sony) The ppt is only a copy of the original LS and serves no additional purpose than the original version of the LS.
Krister (Ericsson)
Dear all,
This discussion we are having in SA plenary #89-e is to protect privacy threat through tracking of a CIoT UE.

In Rel-16 we have two solutions fully specified including ASN.1 coding. The Control Plane CIoT solution as well as the User Plane CIoT solution. As shown with reasonable logical evidence in the mails sent by Ericsson and SONY to SA public mail reflector show that the UP CIoT solution has higher protection against tracking of a UE, since there is no one-to-one correlation between the temporary
Identifier sent by the network and the paging response sent by the UE.

It has also been showed that procedures are specified for the Network to re-allocate the 5G-GUTI (S-TMSI) as frequent as network finds appropriate (similar to legacy specifications) are also specified.

It has also been shown and proposed as a new requirement to clarify in TS 33.501:
Upon receiving a temporary identifier (S-TMSI or I-RNTI) sent by a UE in response to a paging message, it is mandatory for the network to re-allocate the used temporary identifier that was sent in the response message from the UE. This requirement is valid for any type of UE.
This text will also fully answer the question from CT1 in the LS to SA3 (S3-2000615⁄C1-200967)

Furthermore, It has also been shown that current procedures of the RCC resume failure will lead to release of RRC connection and that NAS level procedures will follow on. It is then required to re-allocate the 5G-GUTI as already required and specified.

It has also been seen that two of the main companies behind the UP CIoT solutions are providing all these evidence. Still the companies with main interest in the CP CIoT Solution are putting unjustified demand on the UP CIoT solution. This without any detailed analysis presented that is showing that the protection level against a tracking attack of the UE is less compared to a CP CIoT UE. On the contrary, the protection level against tracking is higher than for the CP CIoT solution.

Going back to any text in mails on SA3 mailing list and tdocs over the last three SA3 meetings, it is clear that this weeks SA plenary discussion on this subject is more detailed on both describing possible attack scenario as well as on how the currently Rel-16 procedures for the UP CIoT are specified and expected to work.

Therefore, I finds it unfair and unjustified for companies, with little interest in UP CIoT solution, to go for a working agreement on these grounds presented in SP-200870. I would rather task SA3 to make a detailed analysis of the potential tracking attack scenarios that shows any evidence.

Furthermore that CT1 clarifies where it may be unclear in specifications if determined necessary. Our analysis of specifications are that procedures cross interfaces are in place to handle this properly but as always behavior description can be more clear in particular related to failure cases.

BR ⁄ Krister
Krister (Ericsson) thanks Lars for the analysis. After going through a mails and tdoc over the last 3 SA3 meeting it is clear that the analysis of both the attack scenarios and analysis of the current Rel-16 specifications has been in more details in SA#89-e than what has been in done in SA3. Clearly SA3 needs to do their job here in upcoming meetings.

Status:

Revised to SP-200883.

TD SP-200883 (LS OUT) LS on 5G GUTI re-allocation. (Source:TSG SA).
Document for: Approval.
Abstract: To: SA WG2, SA WG3, CT WG1 .CC: TSG CT.

Comment:

Revision of SP-200796_Rev1. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200870 (DISCUSSION) Presentation on 5G GUTI reallocation. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: Proposal for endorsement: SA discussed and acknowledged the trade-off between user privacy protection and signalling optimisation for 5G CIoT. Considering this trade off if the same 5G-GUTI is used multiple times for paging even for CIoT UEs, there exists a privacy risk (identification of the UE's presence in a particular location). Therefore, for a UE in 5GMM-IDLE mode with suspend indication, the network shall always allocate a new 5G-GUTI after paging and resume of a connection, even if a NAS message is not sent.

Comment:

Endorsed. A working Agreement will be created based on this proposal.

Discussion and conclusion:

CC#4: Qualcomm propose to endorse this text as a way forward. Sony objected to this text as it is the same as in the original LS. Who would endorse the proposal as a working agreement: 21 Who does not endorse the proposal as a working agreement: 2 A working agreement was made based on SP-200870. This will be posted on the Web pages and may result in a Vote at TSG #90-e if there are any challenges by the deadline which cannot be resolved at the meeting. This contribution was then endorsed.

Status:

Endorsed.

3.5 Discussion papers on work in Rel-17

3.6 Discussion papers on work in Rel-18 and later

4 Reporting from SA Working Groups, other TSGs, and Others

Documents under this agenda item will not be presented

All reports in agenda item 4 (Reporting) and its sub-agenda items will get a max 5 minute slot on the GTM call on Wednesday for presenting issues which need plenary decision

4.1 SA WG1 reporting

Block 3: For Block Noting - Wednesday 15:00 UTC

TD SP-200778 (REPORT) SA WG1 Report to TSG SA#89e. (Source:SA WG1 Chairman).
Document for: Presentation.
Abstract: SA WG1 Report to TSG SA#89-e.

Convenor comment:

Block 3.

Comment:

The SA WG1 Chairman presented rev1 of the report. Noted.

Discussion and conclusion:

CC#2: The SA WG1 Chairman presented rev1 of the report: https:⁄⁄www.3gpp.org⁄ftp⁄tsg_sa⁄TSG_SA⁄TSGs_89E_Electronic⁄Inbox⁄Revisions⁄SP-200778_rev1.zip Slide 4: The TSG SA Chairman asked for confirmation that these times can be adjected if changes are made in the Rel-17 planning in December 2020. This was confirmed. Slide 3: AT&T commented that it was too soon to start considering Rel-19 and asked SA WG1 not to do this at this time. Also if further deprioritization is needed then items may slip from one Release to the next. Slide 3: Intel asked how the limit of 15 units was arrived at, if it assumed all WIs need the same amount of time. The SA WG1 Chairman replied this is not a rule, but a recommendation from the SA WG1 Chairman and 15 is not a 'rule' but a workable limit to the time without needing to start using time units. CMCC commented that it can be useful to make SA WG1 more efficient, but as there are a large number of studies ongoing the limits should be set earlier in the cycle. Xiaomi commented that is no new Rel-18 work can be proposed after September 2021 and asked whether given the Rel-17 slippage, more Rel-18 proposals could be possible. This should be discussed over the e-mail. Ericsson commented that there are two issues, the capacity of SA WG1 and its delegates' availability for the diverse topics and also the expectation of deprioritised Rel-17 work which is likely to be included in Rel-18. Huawei commented that imposing a limit of 15 study items is acceptable as a guideline, but should not block SID proposals just because it has been reached. General: The proposed Rel-18 Freeze dates should be further discussed over e-mail. The SA WG1 Chairman was thanked for this report, which was noted.
CC#4: There had been discussion over the suggested Stage 1 Rel-18 freeze dates proposed by SA WG1. AT&T suggested that no artificial boundaries are created to a certain SA WG1 meeting. The TSG SA Chairman suggested this is reviewed again at the December TSG SA meeting. SA WG1 should take new Rel-18 proposals (e.g. SID) at least in it's next meeting. TSG SA will discuss this issue again at the December TSG SA meeting. Sony asked whether the SA WG1 ad-hoc meeting had been decided. The SA WG1 Chairman replied that the decision will be made in December. The ad-hoc meeting has been planned and may need to be cancelled in December.

e-mail discussion:

New revision uploaded where slide 8 incorporates all the latest information about future SA1 meetings.
Sherry (Xiaomi) requests for clarification about the timeline for R18 new SIDs proposal.
Wenruo (Huawei) commented that Rel-18 stage1 timeline should keep open before R-17 timeline is stabilized. It is clear the freeze date of R18 stage 1 should not be earlier than Sept. 2021. With that, it is too early to close the door for any new R18 SID proposal in SA1 in the coming SA1 meeting.
Saso (Intel) supports Wenruo's view that the door for new R18 SID proposals in SA1 should remain open at least in Q4. If SA1 is in overload situation, then prioritization exercise should take place.
Ming (CATT) supports Wenruo's view and think the door for new R18 SID proposals in SA1 should remain open. If necessary, prioritization exercise on approved Rel-18 SA1 SID should take place either within SA1 or at SA plenary.
Tony (Futurewei) supports the view expressed by Huawei, Intel, and CATT regarding the Rel-18 timeline (i.e., kept open till Rel-17 timeline is decided), allowing new Rel-18 proposal till then, and doing prioritization exercise of SA1 SID⁄WIDs if needed.
Tao Sun (China Mobile) share the same view as the previous companies that it is too early to put new SIDs into R19 with the situation that even R17 timeline not fully settled down with likely 6 months delay. We suggest not close the door of R18 stage 1 study in this stage and prioritization within SA1 can be done if considered needed.
Telefonica supports the previous statement by China Mobile.

Status:

Noted.

4.2 SA WG2 reporting

Block 3: For Block Noting - Wednesday 15:00 UTC

TD SP-200670 (REPORT) SA WG2 Report to TSG SA. (Source:SA WG2 Chairman).
Document for: Presentation.
Abstract: SA WG2 Report to TSG SA#89-e.

Convenor comment:

Block 3.

Comment:

Noted.

Discussion and conclusion:

CC#2: Slide 50: Orange asked whether the Rel-17 timeline should be decided now rather than in December, in order allow better planning in SA WG2. The TSG SA Chairman replied that this is part of the e-mail discussions, but it is also unlikely that TSG RAN will come to a decision at this meeting. The SA WG2 Chairman was thanked for this report, which was noted.

Status:

Noted.

4.3 SA WG3 reporting

Block 3: For Block Noting - Wednesday 15:00 UTC

TD SP-200669 (REPORT) SA WG3 Status report. (Source:SA WG3 Chairman).
Document for: Presentation.
Abstract: SA WG3 Status report o TSG SA#89-e.

Convenor comment:

Block 3.

Comment:

Noted.

Discussion and conclusion:

CC#2: Slide 2: Adrian Escott was congratulated for receiving the 2019 excellence award. The SA WG3 Chairman was thanked for this report, which was noted.

Status:

Noted.

4.4 SA WG4 reporting

Block 3: For Block Noting - Wednesday 15:00 UTC

TD SP-200658 (REPORT) SA WG4 Chairman's Report. (Source:3GPP SA4).
Document for: Presentation.
Abstract: SA WG4 Chairman's Report to TSG SA#89-e.

Convenor comment:

Block 3.

Comment:

Noted.

Discussion and conclusion:

CC#2: The SA WG4 Chairman was thanked for this report, which was noted.

Status:

Noted.

4.5 SA WG5 reporting

Block 3: For Block Noting - Wednesday 15:00 UTC

TD SP-200805 (REPORT) SA WG5 Status Report to SA#89-e. (Source:SA WG5 Chairman).
Document for: %%DOCFOR%%.
Abstract: SA WG5 Status Report to SA#89-e.

Convenor comment:

Block 3.

Comment:

Noted.

Discussion and conclusion:

CC#2: The SA WG5 Chairman was thanked for this report, which was noted.

Status:

Noted.

4.6 SA WG6 reporting

Block 3: For Block Noting - Wednesday 15:00 UTC

TD SP-200825 (REPORT) SA WG6 status report to TSG SA#89. (Source:SA WG6 Chairman).
Document for: Presentation.
Abstract: SA WG6 status report to TSG SA#89.

Convenor comment:

Block 3.

Comment:

Noted.

Discussion and conclusion:

CC#2: The SA WG6 Chairman was thanked for this report, which was noted.

Status:

Noted.

4.7 TSG RAN reporting and RAN ITU-R Ad Hoc Matters

(Will be handled on Monday 20th September in separate call)

TD SP-200863 (LS IN) LS from TSG RAN: Draft Letter to ITU - Response LS on 3GPP’s activities related to WRC-19 Resolutions. (Source:TSG RAN (RP-202054)).
Document for: Information.
Abstract: The ITU Secretary-General (Houlin Zhao) informed 3GPP via a letter to the PCG Chairman of the outcome of WRC19. The LS is asking 3GPP to keep the ITU Secretary-General informed of 3GPP's Action: on the listed WRC-19 Resolutions (240, 241, 242, 243, 811, 812) and Recommendations (208), which are considered to be of interest to 3GPP. Since the topic is RAN specific, RAN prepared the answer to be submitted by PCG to the Secretary-General. ITU-R Working Party 5D (WP 5D) informed 3GPP on their schedule towards Revision 5 of Recommendation M.2012. TSG RAN#89e endorsed the document as submitted by the ITU-R Ad Hoc without any modification.

Comment:

To be noted. CC#4: This LS was noted.

Discussion and conclusion:

CC#4: This LS was noted.

Status:

Noted.

TD SP-200866 (LS IN) LS from TSG RAN: DRAFT LTI - answer to ITU-R WP5A LS on CONNECTED AUTOMATED VEHICLES (CAV) . (Source:TSG RAN (RP-202057)).
Document for: Action.
Abstract: ITU-R Working Party 5A (WP 5A) informed 3GPP that they initiated work on Question ITU-R 26⁄5, 'Connected Automated Vehicles (CAV)', and requested interested organizations to provide material on the description, architecture, applications, technologies, and operational scenarios of CAVs and the radiocommunication requirements for CAVs. TSG RAN#89e endorsed the document as submitted by the ITU-R Ad Hoc without any modification. Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by September 18, 2020. It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R WP5A is 2 November 2020 (16:00 UTC). As a consequence 3GPP PCG is asked to approve the document by correspondence by September 24th, 2020.

Comment:

For endorsement and creating an LS to the PCG. CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200875.

Discussion and conclusion:

CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200875.

Status:

Endorsed.

TD SP-200875 (LS OUT) LS to PCG: DRAFT LTI - answer to ITU-R WP5A LS on CONNECTED AUTOMATED VEHICLES (CAV) . (Source:TSG SA).
Document for: Approval.
Abstract: To: PCG. Actions: It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R WP5A is 2 November 2020 (16:00 UTC). As a consequence 3GPP PCG is asked to approve the document by correspondence by September 24th, 2020.

Comment:

Approved at CC#4.

Discussion and conclusion:

Approved at CC#4.

Status:

Approved.

TD SP-200864 (LS IN) LS from TSG RAN: DRAFT LTI - answer to ITU-R WP5D LS on DEVEOPMENT OF DRAFT NEW RPORT ITU-R.M[IMT.C-V2X] – APPLICATION OF THE TERRESTRIAL COMPONENT OF IMT FOR CELLULAR-V2X. (Source:TSG RAN (RP-202055)).
Document for: Action.
Abstract: ITU-R Working Party 5D (WP 5D) informed 3GPP that they started the development of a draft new report ITU-R M.[IMT.C-V2X] on 'Application of the Terrestrial Component of IMT for Cellular-V2X', and informed interested organizations they may wish to provide information on the relevant work as indicated in Question ITU-R 262⁄5. TSG RAN#89e endorsed the document as submitted by the ITU-R Ad Hoc without any modification. Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by September 18, 2020. It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R WP5A is 2 November 2020 (16:00 UTC). As a consequence 3GPP PCG is asked to approve the document by correspondence by September 24th, 2020.

Comment:

For endorsement and creating an LS to the PCG. CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200873.

Discussion and conclusion:

CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200873.

Status:

Endorsed.

TD SP-200873 (LS OUT) LS to PCG: DRAFT LTI - answer to ITU-R WP5D LS on DEVEOPMENT OF DRAFT NEW RPORT ITU-R.M[IMT.C-V2X] – APPLICATION OF THE TERRESTRIAL COMPONENT OF IMT FOR CELLULAR-V2X. (Source:TSG SA).
Document for: Approval.
Abstract: To: PCG. Actions: It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R WP5A is 2 November 2020 (16:00 UTC). As a consequence 3GPP PCG is asked to approve the document by correspondence by September 24th, 2020.

Comment:

Approved at CC#4.

Discussion and conclusion:

Approved at CC#4.

Status:

Approved.

TD SP-200865 (LS IN) LS from TSG RAN: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on update submission for LTE-Advanced towards Revision 5 of Recommendation ITU-R M.2012 . (Source:TSG RAN (RP-202056)).
Document for: Action.
Abstract: ITU-R Working Party 5D (WP 5D) informed 3GPP on their schedule towards Revision 5 of Recommendation M.2012. The following table summarizes the actions required by 3GPP: Step Action: by Action: Deadline Status 1 3GPP Delivery to ITU-R of the initial announcement that a revision to a particular RIT or SRIT will be proposed 16 June 2020 (WP5D#35) This document 2 3GPP Delivery to ITU-R of further information, including a summary of the proposed update 28 September 2020 (WP5D#36) 3 3GPP Delivery to ITU-R of the detailed update 26 January 2021 (WP5D#37) 4 OPs Delivery to ITU-R of transposition references by each Transposing Organization 1 September 2021 Note that Revision 4 is based on 3GPP Release 14. Based on the decisions taken at TSGs#87e the submission plan is the following: - Submit to ITU-R WP5D #35 (June 2020) the initial statement 3GPP is willing to submit a contribution towards Revision 5 of M.2012 (see PCG44_11) - State that the contents will be based on 3GPP Release 15 and 16, June 2020 version - Submit to ITU-R WP5D #36 (October 2020) a high level overview of 3GPP update (this document) - Submit to ITU-R WP5D #37 (February 2020) the complete material towards updating M.2012 to Revision 5 TSG RAN#89e endorsed the document as submitted by the ITU-R Ad Hoc without any modification. Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by September 18, 2020. It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R is September 28h, 2020. Therefore, 3GPP PCG is asked to approve the document by correspondence by September 24th, 2020, and provide the approved version of the material to ATIS. The final version of the document will be submitted to ITU-R WP5D by ATIS on behalf of 3GPP OPs.

Comment:

For endorsement and creating an LS to the PCG. CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200874.

Discussion and conclusion:

CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200874.

Status:

Endorsed.

TD SP-200874 (LS OUT) LS to PCG: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on update submission for LTE-Advanced towards Revision 5 of Recommendation ITU-R M.2012 . (Source:TSG SA).
Document for: Approval.
Abstract: To: PCG. Attachments: 21915-f00.zip, 21916-050.zip. Actions: It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R WP5A is 2 November 2020 (16:00 UTC). As a consequence 3GPP PCG is asked to approve the document by correspondence by September 24th, 2020.

Comment:

Approved at CC#4.

Discussion and conclusion:

Approved at CC#4.

Status:

Approved.

TD SP-200867 (LS IN) LS from TSG RAN: Draft Letter to ITU in answer to LS to RIT⁄SRIT Proponents on the completion and conclusions of steps 5 to 7 of the IMT-2020 process for the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] . (Source:TSG RAN (RP-202058)).
Document for: Action.
Abstract: ITU-R Working Party 5D (WP 5D) informed 3GPP that ITU normally uses a formal name for the Radio Interface Technologies (so called as ITU name) which may be different from ones used in the specifications of each SDOs. WP 5D currently identifies the technologies using ITU-R placeholder names based on the Proponent's submission. 3GPP is kindly asked to confirm the placeholder name or provide a revised proposal. name for your technology(ies). The new proposed name will be considered by WP 5D, so that the Recommendation ITU-R M.[IMT-2020.SPECS] might if appropriate, include such name. The current placeholder name are as follows: Proponent Acknowledgement of submission under Step 3 Name in Draft new Report M.[IMT-2020.OUTCOME] 3GPP IMT-2020⁄13 (3GPP 5G: SRIT) 3GPP IMT-2020⁄14 (3GPP 5G: RIT) This document provides an answer to the LS received by ITU-R WP5D. In particular, it is proposed to remove the ':' and restate the footnotes as submitted by 3GPP: - '3GPP 5G-SRIT' ; - '3GPP 5G-RIT' ; TSG RAN#89e endorsed the document as submitted by the ITU-R Ad Hoc without any modification. Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by September 18, 2020.

Comment:

For endorsement and creating an LS to the PCG. CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200876.

Discussion and conclusion:

CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200876.

Status:

Endorsed.

TD SP-200876 (LS OUT) LS to PCG: Draft Letter to ITU in answer to LS to RIT⁄SRIT Proponents on the completion and conclusions of steps 5 to 7 of the IMT-2020 process for the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] . (Source:TSG SA).
Document for: Approval.
Abstract: To: PCG. Actions: It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R WP5A is 2 November 2020 (16:00 UTC). As a consequence 3GPP PCG is asked to approve the document by correspondence by September 24th, 2020.

Comment:

Approved at CC#4.

Discussion and conclusion:

Approved at CC#4.

Status:

Approved.

TD SP-200890 (REPORT) Chairmans Report of TSG RAN#89-e. (Source:TSG RAN Chairman).
Document for: Presentation.
Abstract: Chairmans Report of TSG RAN#89-e. Outline - RAN meeting timeplan until June 2021 - The March TSG meeting may be extended to start earlier, on Thursday 18 March 2021, if elections need to be held - Key elements of the proposed plan - Quarters with multiple WG meetings may have staggered handling of items - Initial soft-staggering of topics is shown in the TU allocation tables, subject to further refining in future RAN plenaries - Inactive periods are installed between meetings to allow proper internal preparation and observe key regional holidays - No email discussions are allowed on any WG reflector or TSG_RAN or TSG_RAN_Drafts reflector during these periods. - No GTW sessions are allowed, not even informal ones. - 23-29⁄Nov (Thanksgiving) - 21⁄Dec - 3⁄January (Christmas+New Year) - 8-21⁄Feb (Lunar New Year) - 29⁄March - 5⁄April (Easter) - 26⁄April-9⁄May - Tightening of scope for some existing WIs may be addressed at December plenary to ensure timely progress - Potential follow-on Work Items of Study Items will need a very well defined tight scope! - TSG#91 may have 2 days set aside exclusively for conducting election rounds on Thursday and Friday before the normal meeting week - Submissions deadlines - RAN WG1 - 103-e: 16Oct for maintenance & Rel-17 4 SIs (RedCap, ePos, CovEnh, 60GHz); 23Oct for other Rel-17 items - 104-e: 18Jan; 104b-e: 6April; 105-e: 11May - RAN WG2 - 112-e: 22Oct (23.59 PST); 113-e: 14Jan (23.59 PST); 113b-e: 6April (23.59 PST); 114-e: 11May (23.59 PST) - RAN WG3: business as usual - RAN WG4 - 97-e: 23Oct; 98-e: 15Jan; 98b-e: 6April; 99-e: 11May - RAN WG5 - 90-e: 8Feb - Release 17 timeline considerations - The RAN leadership is committed to facilitate delivering Rel-17 with minimal additional delay - Detailed analysis still needed to understand what is feasible -> Overall timeline decision to be taken only in December - Leadership will provide detailed analysis (TUs, etc.) for December with the goal of keeping the additional delay at a minimum (6 months) - Firmly commit to a new timeline (in December), and endorse a detailed RAN planning (meetings and TUs) to meet this timeline - Release 16 stability - Guidance to implementations will be added to the RRC specs on 3GPP website specification page - On the 38.331 specification webpage, add 'A UE or network vendor wishing to support Rel-16 must use version 16.2.0 or later of TS 38.331'. This is the September version of 38.331. - On the 36.331 specification webpage, add 'A UE or network vendor wishing to support Rel-16 must use version 16.2.0 or later of TS 36.331'. This is the September version of 36.331. - It is understood that the bar for potential non-backwards compatible changes to Rel-16 from Q4 onwards will be very high - Technical topics - NR Multicast Broadcast - SA WG2 was debating whether broadcast work scope should be reduced and asked RAN on the matter - RAN concluded that the scope of it's broadcast work would be unchanged - Non-Public Networks - RAN approved the Work Item to cover the RAN WG2 and RAN WG3 impacts coming from the SA WG2-led item - TEI handling - RAN plans to further explore the details of TEI handling in an email discussion that is to be conducted 5-16⁄October on the RAN_Drafts exploder - Main focus is on traceability aspects of TEI CRs.

Comment:

CC#5: Noted.

Discussion and conclusion:

CC#5: General: The TSG SA Chairman confirmed that most decisions in TSG RAN were in line with TSG SA and intended to have a discussion on the inactivity period for WGs, but the TEI handling will need further discussion. Slide 4: Nokia welcomed TSG SA discussing the inactive periods agreed by TSG RAN for TSG SA groups. This discussion is likely to happen the first or second week of October. Slide 3: The MCC Director asked whether the 2020⁄2021 meeting plan was final and could be entered in the Calendar. This was confirmed. AT&T asked what the meaning of the further shift out to 9 months delay if there are no F2F meetings possible in 2021 and whether this planning was fixed and the implications on the SA WGs schedules. It was clarified that TSG SA had identified a 3-month shift, but the final decision cannot be made at present and will be reviewed again in December. The TSG RAN Chairman was thanked for this report, which was noted.

Status:

Noted.

Block 3: For Block Noting - Wednesday 15:00 UTC

TD SP-200779 (LS IN) LS from TSG RAN ITU AH: Draft Letter to ITU - Response LS on 3GPP's activities related to WRC-19 Resolutions. (Source:TSG RAN ITU AH (RT-200037)).
Document for: Information.
Abstract: This ITU input will become part of ITU deliverable(s): no Responsible 3GPP group for final output to ITU: 3GPP PCG deadline for the final output to ITU: not indicated way to make this document available for ITU (see Art.51 of 3GPP working procedures): [.] a. via OPs as a deliverable from their organizations (for PCG review only) [ ] b. via Individual Members (for PCG or TSG review) coordinated by ITU sector convener [ ] c. via 3GPP LS coordinator (for TSG or WG review) Since the LS in is addressed to the PCG chairman, the source of the answer to ITU should be PCG.

Convenor comment:

Block 3.

Comment:

For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 To: 3GPP PCG, CC: TSG SA. This was block noted at CC#2.

Discussion and conclusion:

This was block noted at CC#2.

Status:

Noted.

TD SP-200780 (LS IN) LS from TSG RAN ITU AH: DRAFT LTI - answer to ITU-R WP5A LS on CONNECTED AUTOMATED VEHICLES (CAV). (Source:TSG RAN ITU AH (RT-200039)).
Document for: Information.
Abstract: This ITU input will become part of ITU deliverable(s): yes Responsible 3GPP group for final output to ITU: 3GPP PCG deadline for the final output to ITU: 2 November 2020 (16:00 UTC) way to make this document available for ITU (see Art.51 of 3GPP working procedures): [ ] a. via OPs as a deliverable from their organizations (for PCG review only) [∝] b. via Individual Members (for PCG or TSG review) coordinated by ITU sector convener [ ] c. via 3GPP LS coordinator (for TSG or WG review).

Convenor comment:

Block 3.

Comment:

For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 to: 3GPP TSG SA in: 3GPP TSG SA feedback LS before: September 18, 2020 to: 3GPP PCG. This was block noted at CC#2.

Discussion and conclusion:

This was block noted at CC#2.

Status:

Noted.

TD SP-200781 (LS IN) LS from TSG RAN ITU AH: DRAFT LTI - answer to ITU-R WP5D LS on DEVEOPMENT OF DRAFT NEW RPORT ITU-R.M[IMT.C-V2X] - APPLICATION OF THE TERRESTRIAL COMPONENT OF IMT FOR CELLULAR-V2X. (Source:TSG RAN ITU AH (RT-200040)).
Document for: Information.
Abstract: This ITU input will become part of ITU deliverable(s): yes Responsible 3GPP group for final output to ITU: 3GPP PCG deadline for the final output to ITU: 28 September 2020 way to make this document available for ITU (see Art.51 of 3GPP working procedures): [ ] a. via OPs as a deliverable from their organizations (for PCG review only) [∝] b. via Individual Members (for PCG or TSG review) coordinated by ITU sector convener [ ] c. via 3GPP LS coordinator (for TSG or WG review).

Convenor comment:

Block 3.

Comment:

For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 to: 3GPP TSG SA in: 3GPP TSG SA feedback LS before: September 18, 2020 to: 3GPP PCG. This was block noted at CC#2.

Discussion and conclusion:

This was block noted at CC#2.

Status:

Noted.

TD SP-200782 (LS IN) LS from TSG RAN ITU AH: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on update submission for LTE-Advanced towards Revision 5 of Recommendation ITU-R M.2012. (Source:TSG RAN ITU AH (RT-200041)).
Document for: Information.
Abstract: This ITU input will become part of ITU deliverable(s): yes Responsible 3GPP group for final output to ITU: 3GPP PCG deadline for the final output to ITU: September 28th, 2020 (16:00 hours UTC) way to make this document available for ITU (see Art.51 of 3GPP working procedures): [∝] a. via OPs as a deliverable from their organizations (for PCG review only) [ ] b. via Individual Members (for PCG or TSG review) coordinated by ITU sector convener [ ] c. via 3GPP LS coordinator (for TSG or WG review).

Convenor comment:

Block 3.

Comment:

For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 to: 3GPP SA in: 3GPP TSG SA feedback LS before: September 18, 2020 to: 3GPP PCG. This was block noted at CC#2.

Discussion and conclusion:

This was block noted at CC#2.

Status:

Noted.

TD SP-200783 (LS IN) LS from TSG RAN ITU AH: Draft Letter to ITU in answer to LS to RIT⁄SRIT Proponents on the completion and conclusions of steps 5 to 7 of the IMT-2020 process for the first release of new Recommendation ITU-R M.[IMT-2020.SPECS]. (Source:TSG RAN ITU AH (RT-200042)).
Document for: Information.
Abstract: His ITU input will become part of ITU deliverable(s): yes Responsible 3GPP group for final output to ITU: 3GPP PCG deadline for the final output to ITU: September 28th, 2020 (16:00 hours UTC) way to make this document available for ITU (see Art.51 of 3GPP working procedures): [∝] a. via OPs as a deliverable from their organizations (for PCG review only) [ ] b. via Individual Members (for PCG or TSG review) coordinated by ITU sector convener [ ] c. via 3GPP LS coordinator (for TSG or WG review).

Convenor comment:

Block 3.

Comment:

For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 to: 3GPP SA in: 3GPP TSG SA feedback LS before: September 18, 2020 to: 3GPP PCG. This was block noted at CC#2.

Discussion and conclusion:

This was block noted at CC#2.

Status:

Noted.

4.8 TSG CT reporting

(Will be handled on Monday 20th September in separate call)

TD SP-200861 (LS IN) LS from TSG CT: LS on information of stage 3 aspects for AKMA. (Source:TSG CT (CP-202255)).
Document for: Action.
Abstract: TSG CT has approved the WID AKMA-CT in Release 17 to implement the AKMA in stage 3, whereas the corresponding stage 2 requirements are in Rel-16. Action: TSG CT kindly ask TSG SA and SA WG3 to take above into account.

Comment:

SA WG3 and SA WG1 will work on CRs that will propose to shift AKMA SA WG3 to Rel-17. Additional changes for separate discussions. Proposal to change BB to Feature for discussion in SA WG3. Noted.

Discussion and conclusion:

CC#3: The question on whether to leave AKMA in Rel-16 or to move it to Rel-17 in the specifications. The SA WG3 Chairman commented that there is no issue with either decision and there are two TSs which will need update if the AKMA functionality needs to be removed from Rel 16. SA WG3 wee asked to create CRs to remove functionality from Rel 16 and include it in Release 17. Huawei commented that this should be done by first inserting it into Rel 17 with a TS upgrade to Rel 17 and then to remove from Rel 16 with CRs. The SA WG3 Chairman commented that the provision of any necessary WID update and CRs should follow the usual contribution-based process at SA WG3 meetings. CMCC commented that SA WG2 can move the AKMA functionality to Rel-17 but it should not be re-scoped due to this decision. Any proposals for change to the scope of the work should follow the usual procedures. Matrixx suggested moving this from a Building Block to a Feature in the Work Plan. Summary: SA WG3 and SA WG1 will work on CRs that will propose to shift AKMA SA WG3 to Rel-17. If additional changes are requested in SA WG3⁄SA WG1 then those requests need to be handled in separate discussions. Matrixx proposed to change SA WG3 WID from BB to Feature - this will be handled in SA WG3 discussions. This LS was then noted.

Status:

Noted.

TD SP-200858 (REPORT) Status report of TSG CT#89-e. (Source:TSG CT Chairman).
Document for: Presentation.
Abstract: Status report of TSG CT#89-e. Yvette Koza, CT WG4 Vicechair has announced her retirement and the Vice Chairman ship for CT WG4 will remain vacant for the time-being. For Information to SA E-meetings in 1H 2021: - Based on the current situation, it is assumed that meetings in 1H⁄2021 will be in electronic format - TSG plenary dates are confirmed and will not be changed - WG meetings scheduled taking into account the plenary dates - If it appears that F2F meetings for one group or all the WGs can be safely resumed in the upcoming months, e-meetings will be converted to F2F meetings when feasible. Rel-17 timeline: - SA#89 may decide to shift stage 2 completion date to SA#91 - Could be 3-month delay - CT will check the SA#89 final output and decide on: - Stage 3 freeze date: Stage 2 freeze date + 9 months? - OpenAPI freeze date: Stage 3 freeze date + 3 months? - The final decision for CT will be taken in December - Any decision on the stage 2 freeze date should be considered as firm and definitive - A moving target makes difficult to correctly plan the stage 3 work Resuming the ToR Update process: - Work on a common description form for all working groups - Work on a common style for all working groups (Template) - Present draft version to the WG - Target for completion: TSG#90 For Action to SA Handling of TEI17-x WI: - TEI17-X created in SA WG2 have to be treated as normal WI in CT - If stage 3 work needed, a corresponding WI will be created in CT - Reusing the same WI code would ease the tracking of the all the CRs agreed - However, it should be made clear that any TEI17 CR in SA WG2 should not require a specific WI - Especially when TEI17 CRs are triggered based on work on done in CT - Example: LS on AUSF⁄UDM discovery based on SUCI information (CP-202214) - Moreover, CT can approve TEI17 cat B CR without WID - Need for cross-TSG alignment CR: Procedure updates relating to WI: - Aim: Add guidance on the use of TEI. - SA#82 - SP-181188: First presentation - SA#83 - SP-190270: Approval - No LS has been sent to CT - Therefore, CT was not able to - evaluate the proposal - provide a formal feedback to SA before the update of TS 21.900 AUSF⁄UDM discovery based on SUCI information: - LS in CP-202214 (C4-204337) - CT WG4 has analyzed the issue of insufficient length of Routing Indicator within SUCI, currently it is only 4 digits which is too short. - CT WG4 has also discussed the solution enabling to use the Home Public Key ID as an additional parameter (that allows to encode e.g. a 5th digit, in addition to the key ID on 4 bits) for the discovery of the AUSF⁄UDM. - SA WG2 should provide corresponding stage-2 requirements first - SA WG2 is kindly asked to handle this topic in Q4 2020. AKMA Stage 3 issue: - Authentication and key management for applications based on 3GPP credential in 5G - Stage 2 completed in Rel-16 in SA WG3 - CT approved a WID for Rel-17 (too late for rel-16) - Stage 2 and stage 3 should be part of the same release - Stage 2 without stage 3 implies vendor-specific implementation - SA and SA WG3 are kindly requested to shift AKMA from Rel-16 to Rel-17 Acknowledgement: - Thanks to CT vice chairs, CT WG chairs and vice chairs and rapporteurs for excellent coordination of and work. Special thanks to MCC for excellent meeting support. - Thanks to the delegates in CT WGs and CT for achieving all deadlines as promised and delivering an enormous amount of CRs and input papers.

Comment:

Noted.

Discussion and conclusion:

CC#4: Slide 14: Motorola Solutions asked for confirmation that 3GPP will move to F2F meetings as a group and not on a per-WG basis. The TSG SA Chairman could not give such an assurance at present as different WGs have different compositions of delegates from countries and it may be possible for some to hold F2F meetings before others, but it is important to allow the resumption of F2F meetings as soon as it is practical in order to more efficiently progress the work. Slide 15: The MCC Work Plan Manager commented that there are 3 Rel-17 time lines from each TS, and as they are roughly aligned, there is a problem in having three separate timelines. The TSG SA Chairman replied that there is a single timeline, decided in March, but these are proposals for what shift may be needed for decision in December. All 3 TSGs are indicating that a shift of 3 months is to be expected, depending on developments by December 2020. For Rel-18 there is no official timeline, but only assumptions being made by SA WG1 to progress their work. Slide 21: Intel asked what the decision on the stage 2 shift was for AKMA in TSG CT. It was clarified that the Stage 3 WID was approved for Rel-17 and the Stage 2 AKMA work will need to be moved to Rel-17 and the Stage 2 Rel-16 TS will need to be removed and references to it updated. The TSG CT Chairman was thanked for this report, which was noted.

Status:

Noted.

TD SP-200859 (REPORT) Draft report of TSG CT#89-e. (Source:TSG CT Secretary (MCC)).
Document for: Information.
Abstract: Draft meeting report of TSG CT#88E.

Comment:

Noted.

Discussion and conclusion:

CC#4: This was provided for information and was noted.

Status:

Noted.

TD SP-200860 (REPORT) IETF Status report. (Source:TSG CT Chairman).
Document for: Presentation.
Abstract: IETF Status report. Summary: - 1 ongoing request for IANA port number assignment - 15 drafts have become RFC already - final CR in 3GPP still needed, for some of them - 19 drafts are in the RFC Editors Queue, - 4 drafts still under IESG review, - 4 individual drafts and - 4 drafts that have expired. IANA number Assignment: - Thanks to IESG, IANA has allocated the port 37472 to W1 interface - 3GPP is tasked to work on alternative solutions to avoid the need for port assignment for (private) 3GPP interfaces - A study has been initiated in CT WG4 (WID approved at CT#89-e) New published RFCs - RFC 8684 Title: TCP Extensions for Multipath Operation with Multiple Addresses - Was: draft-ietf-mptcp-rfc6824bis To be updated: TS 23.501 Rel-16 - RFC 8693 Title: OAuth 2.0 Token Exchange Was: draft-ietf-oauth-token-exchange To be updated: TS 24.482 (since rel-14) - RFC 8787 (NEW) Title: Location Source Parameter for the SIP Geolocation Header Field Was: draft-ietf-sipcore-locparam To be updated: TS 24.229 Rel-16 - RFC 8898 Title: Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP) Was: draft-ietf-sipcore-sip-token-authnz To be updated: TS 24.371 (since rel-12) - RFC 8803 Title: 0-RTT TCP Convert Protocol Was: draft-ietf-tcpm-converters To be updated: TS 23.501, 24.193, 29.244 (since rel-16) Drafts in RFC Editor queue: - draft-ietf-rtcweb-overview Title: Overview: Real Time Protocols for Browser-based Applications - draft-ietf-rtcweb-data-channel Title: WebRTC Data Channels - draft-ietf-rtcweb-data-protocol WebRTC Data Channel Establishment Protocol - draft-ietf-rtcweb-security Title: Security Considerations for WebRTC - draft-ietf-clue-framework Title: Framework for Telepresence Multi-Streams - draft-ietf-clue-signaling Title: Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) - draft-ietf-clue-datachannel (NEW) Title: CLUE Protocol data channel - draft-ietf-clue-data-model-schema Title: An XML Schema for the CLUE data model - draft-ietf-clue-rtp-mapping Title: Mapping RTP streams to CLUE Media Captures - draft-ietf-clue-protocol (NEW) Title: Protocol for Controlling Multiple Streams for Telepresence (CLUE) - draft-ietf-mmusic-sctp-sdp Title: SDP Offer⁄Answer Procedures For SCTP over DTLS Transport. - draft-ietf-mmusic-sdp-simulcast Title: Using Simulcast in SDP and RTP Sessions - draft-ietf-mmusic-data-channel-sdpneg Title: SDP-based Data Channel Negotiation - draft-ietf-mmusic-rid Title: RTP Payload Format Restrictions - draft-ietf-mmusic-dtls-sdp Title: SDP Offer⁄Answer Considerations for DTLS and TLS - draft-ietf-mmusic-t140-usage-data-channel Title: T.140 Real-time Text Conversation over WebRTC Data Channels - draft-ietf-mmusic-mux-exclusive Indicating Exclusive Support of RTP⁄RTCP Multiplexing using SDP - draft-ietf-mmusic-sdp-bundle-negotiation Title: Negotiating Media Multiplexing Using the SDP - draft-ietf-mmusic-msrp-usage-data-channel (NEW) Title: MSRP over Data Channels - draft-ietf-ice-trickle Title: Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol - draft-ietf-stir-passport-divert Title: PASSporT Extension for Diverted Calls Drafts under IESG review: - draft-ietf-emu-rfc5448bis Title: Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') Individual submission: - Managed by https:⁄⁄json-schema.org⁄ Status: it seems a controversial topic in IETF. Not sure one of them get RFCized - draft-handrews-json-schema-validation [REST_SS] Title: JSON Schema Validation: A Vocabulary for Structural Validation of JSON - Published : 2019-09-17 - draft-handrews-json-schema [REST_SS] Title: JSON Schema: A Media Type for Describing JSON Documents - Published : 2019-09-17 - draft-handrews-json-schema-hyperschema [REST_SS] Title: JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON Expired Drafts: - draft-schwarz-mmusic-sdp-for-gw - Still to be done - draft-jesske-sipcore-sip-tree-cap-indicators - Removed from CT WG1 spec. No more dependency - draft-ietf-oauth-pop-architecture Title: OAuth 2.0 Proof-of-Possession (PoP) Security Architecture - Seems not required anymore as we could refer to RFC 7800 - draft-jesske-update-p-visited-network Title: Update to P-Visited-Network-ID in SIP Requests and Responses - To be reactived by Roland.

Comment:

Noted.

Discussion and conclusion:

CC#4: General: The SA WG2 Chairman reported that the SA WG2 report contains information on IETF updates from draft to RFC. The TSG CT Chairman asked WG Chairmen to provide newly references RFCs and updates when draft RFCs are published and can be removed from the dependencies list. The TSG CT Chairman was thanked for this report, which was noted.

Status:

Noted.

4.9 Reports from external bodies

(Provided by Liaison persons)

4.10 Other reports

5 Cross TSG Coordination

5.1 General Cross TSG Coordination

5.2 Rel-16 Focus Areas Status Reports & Issues

5.3 Rel-17 Focus Areas Status Reports & Issues

5.4 Input to Joint RAN⁄SA meeting

6 Work Item Descriptions, Study Item Descriptions, Specifications

6.1 New Release 16 and earlier Study Item Descriptions and Work Item Descriptions

Block 4: For Block Approval - Thursday 15:00 UTC

6.2 Revised Release 16 and earlier Study Item Descriptions and Work Item Descriptions

TD SP-200656 (WID REVISED) Revised WID on the normative aspects of User Plane Integrity Protection for NR.. (Source:Vodafone).
Document for: Approval.
Abstract: Updates Objectives, Impacted TSs and Supporting companies.

Comment:

Approved. The 3GPP Work Plan will need to be updated to indicate Rel-16 for UPIP_SEC.

Discussion and conclusion:

CC#1: The SA WG3 Chairman reported that this revision of the WID was provided after the revisions deadline and has been circulated over the SA WG3 e-mail list. It was clarified that this should be a Rel-16 WI to align the Rel-16 work. This revised WID was then approved. The 3GPP Work Plan will need to be updated to indicate Rel-16 for UPIP_SEC.

Status:

Approved.

Block 4: For Block Approval - Thursday 15:00 UTC

TD SP-200763 (WID REVISED) Revised WID Self-Organizing Networks (SON) for 5G networks.. (Source:SA WG5).
Document for: Approval.
Abstract: Updates expected output TS.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200770 (WID REVISED) Revised WID on Discovery of management services in 5G.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective of this work item is to: - Specify the use cases and requirements related to MnS discovery in 5G network and network slicing management. - Specify the necessary management capabilities that are needed to fulfil the MnS discovery in 5G network and network slicing management. - Specify the information which should be published to describe the capabilities of a Management Service. - Specify the list of Management Services which should publish information. - Specify the publish and query methods related to MnS discovery in 5G network and network slicing management. - Specify the procedures and solutions of MnS discovery in 5G network and network slicing management. The management operations and management information specified in the Generic Management service specification shall be reused as far as possible. Existing discovery mechanisms that meet SA WG5 requirements shall be reused as far as possible.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

6.3 New Release 17 Study Item Descriptions

TD SP-200812 (SID NEW) New Study on User Consent for 3GPP services. (Source:Huawei, Hisilicon, China Unicom, CAICT, CATT).
Document for: Approval.
Abstract: This SID is to identify and evaluate the requirements and solutions to support user consent for 3GPP services.

Comment:

CC#1: SP 200812_r01 was approved (to be revised by MCC). Revised to SP-200885.

Discussion and conclusion:

CC#1: NTT DOCOMO confirmed that they were happy with SP 200812_r01. This new SID, SP 200812_r01, was then approved.

e-mail discussion:

Haris (Qualcomm) comments that we can accept approving this SID only with ME box ticked to NO
Wenruo (Huawei) provide rev1 to cover Apple and Qualcomm's comment.
Request for revision.
Apple suggests to add a note in the objectives:
Note: Even where solutions exist to obtain user consent, collection and exposure of user sensitive data should be minimised and only be allowed where critical to the operation of the related feature
Request for revision.
Apple suggests to add a note in the objectives:
Note: Even where solutions exist to obtain user consent, collection and exposure of user sensitive data should be minimised and only be allowed where critical to the operation of the related feature.

Status:

revised by MCC). Revised to SP-200885.

TD SP-200885 (SID NEW) New Study on User Consent for 3GPP services. (Source:Huawei, HiSilicon, China Unicom, CAICT, CATT).
Document for: Approval.
Abstract: Objective: The objectives of this study are to identify and evaluate the requirements and solutions to support user consent for 3GPP services while compliant with user privacy consideration. The detailed objectives are as follows: - Review TR 33.849 with regards to the concept of user consent for 3GPP users, and to identify what type of data collection and conditions under which the support of the user consent is required; then update them if needed; - Identify target usage scenarios and trust domains; - Analyze potential security threats and requirements for conditions under which user sensitive data is collected without user consent, and when user consent indication is not protected; - Identify potential solutions to address the above security requirements. NOTE: Principles, regulations, and definitions related to privacy, which are recognized differently in each different country or area, are taken into account when deriving the concept of user consent for 3GPP users. NOTE: Even where solutions exist to obtain user consent, collection and exposure of user sensitive data should be minimized and only be allowed where critical to the operation of the related feature.

Comment:

Revision of SP-200812_Rev1. Approved.

Discussion and conclusion:

-

Status:

Approved.

Block 4: For Block Approval - Thursday 15:00 UTC

TD SP-200717 (SID NEW) New SID on security aspects of the 5GMSG Service.. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The objectives of this study item are - Analyze the security requirements from SA WG1 and SA WG6 about 5GMSG service, and further identify security key issues to fulfil the security requirements. - Based on the security key issues, find out solutions to ensure the functional architecture (including APIs) and the procedures for 5GMSG to avoid security vulnerabilities.

Comment:

CC#2: SP 200717_rev1 was approved. Revised to SP-200878.

Discussion and conclusion:

CC#2: SP 200717_rev1 was approved.

e-mail discussion:

Request for Revision.
SA6 Chair (Suresh Chitturi) requests the revision of SA3 SID in SP-200717, to align the terminology with SA6 work on MSGin5G service.
The changes are fine and were confirmed offline by the rapporteur. Rev1 based on the proposed changes is available in the Revisions folder.

Status:

Revised to SP-200878.

TD SP-200878 (SID NEW) New SID on security aspects of the MSGin5G Service. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The objectives of this study item are - Analyze the security requirements from SA WG1 and SA WG6 about MSGin5G service, and further identify security key issues to fulfil the security requirements. - Based on the security key issues, find out solutions to ensure the functional architecture (including APIs) and the procedures for MSGin5G to avoid security vulnerabilities.

Comment:

Revision of SP-200717_Rev1. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200721 (SID NEW) New study on the security of AMF re-allocation.. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The aim of this work is to collect the requirements related to the AMF re-allocation procedure and to study the potential enhancements to the security mechanisms in order to fulfil them. More precisely, the objectives are: 1. Collect the requirements related to the AMF re-allocation procedure 2. Study the potential enhancements to the security mechanisms in order to fulfil the requirements for the AMF re-allocation.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200722 (SID NEW) New SID on security aspects of enablers for Network Automation (eNA) for the 5G System (5GS) Phase 2.. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The aim of this study item is to study the security aspects of enablers for network automation for the 5G system developed by SA WG2 and identified by SA WG3, based on the outcome of their study in TR 23.700-91. More specifically, this study item will identify security issues and requirements and provide corresponding security solutions related to the following scenarios: - UE data collection protection to fulfil the NWDAF functionalities including privacy consideration, data authenticity, data integrity, accessibility aspects and user consent requirements. - Detection of cyber-attacks and anomaly events supported by NWDAF and its related functions, specifically to define parameters provided by UE to help detect attacks and abnormal behaviours; - Protection of data transferring (e.g. privacy consideration) in the inter-NWDAF⁄NWDAF instances.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200765 (SID NEW) New SID on YANG PUSH.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: This study of YANG-Push will: 1. Investigate whether there will be any benefits with using the RFC 8639 and RFC 8641 for Telecom Management of a 3GPP system. 2. List all the functionality in the RFC 8639 and RFC 8641 and compare them to the corresponding existing 3GPP specifications' functionality. 3. Investigate if there are any SDOs ⁄ groups which have a demand for 3GPP MnS's to support YANG notifications. 4. Evaluate the use of YANG-Push for CM, FM, PM and Heartbeat and document potential proposals for encoding CM, FM, PM and Heartbeat notifications for YANG based data. The proposal will include use cases, potential requirements and solutions for potential changes in the 3GPP specifications. Include proposals for any needed new interfaces and any interfaces that may no longer be needed for the YANG⁄Netconf SS. 5. If YANG notifications are proposed for CM and⁄or for FM, PM and Heartbeat, investigate whether Stage 1 or 2 specifications need modification, especially considering notification subscriptions. 6. Investigate whether SA WG5 can have protocol agnostic stage 2. 7. Make conclusion and recommendations for normative work.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200767 (SID NEW) New SID on charging aspects of Enhanced Proximity-based Services in 5GC.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: This study item is to investigate the charging aspects for ProSe in 5GS in terms of: 1. Studying the potential impact on charging architecture, for supporting charging of ProSe Direct Discovery and Direct Communication related to Public Safety and commercial proximity service; 2. Identify the potential charging requirements for scenarios related to the enhanced ProSe service in 5GS; 3. Identify the potential charging solutions for the enhanced ProSe service in 5GS; Based on the key issue #7 Charging for PC5 and other solutions, e.g. ProSe direct discovery, which is processing in TR 23.752 in SA WG2, this study will continue to identify the ProSe charging implications in 5GS and coordinate with SA WG2 the conclusions.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200771 (SID NEW) Study on charging aspects of 5GS CIoT.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: This study item is to investigate charging enhancements on 5G data connectivity domain charging, control plane data transfer domain charging and Monitoring Events charging for 5GS CIoT for the corresponding functionalities in TS 23.501: - Control Plane CIoT 5GS Optimisation - Non-IP Data Delivery (NIDD) - Support for Monitoring Events - Support of rate control of user data, including small data rate control - Category M UEs differentiation - Exception report This study item is to investigate charging enhancements for 5GS CIoT functionalities as following: - Charging scenarios (e.g., 5G data connectivity charging enhancement, control plane data transfer charging enhancement regarding NIDD scenario and charging for Monitoring Events ) - Potential requirements and charging information regarding charging.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200764 (SID NEW) New SID on the access control for management service.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective is to study use cases and various access scenarios on management services, and propose management capabilities and solutions to: - support access control policy (including authentication and authorization policy) enforcement, e.g. enforce management service consumer authentication, authorization before exposing management services and processing service requests for the consumer, etc. - support identity management of management service, management service producer and consumer, e.g., create, delete, update identity of management service or management service consumer⁄producer. - support access control policy (including authentication and authorization policy) management, e.g. create, delete, update, etc., procedures. - support permission management, e.g. create, delete, update, etc., procedures. - Align the solution with management plane security requirements and solutions of SA WG3 when applicable.

Comment:

Revised to SP-200853.

Discussion and conclusion:

-

Status:

Revised to SP-200853.

TD SP-200853 (SID NEW) New SID on the access control for management service.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective is to study use cases and various access scenarios on management services, and propose management capabilities and solutions to: - support access control policy (including authentication and authorization policy) enforcement, e.g. enforce management service consumer authentication, authorization before exposing management services and processing service requests for the consumer, etc. - support identity management of management service, management service producer and consumer, e.g., create, delete, update identity of management service or management service consumer⁄producer. - support access control policy (including authentication and authorization policy) management, e.g. create, delete, update, etc., procedures. - support permission management, e.g. create, delete, update, etc., procedures. - Align the solution with management plane security requirements and solutions of SA WG3 when applicable.

Convenor comment:

Block 4.

Comment:

Revision of SP-200764. Change of 'Other related Work Items and dependencies' as suggested by the Work Plan Manager. This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

6.4 New Release 17 Work Item Descriptions

TD SP-200718 (WID NEW) New WID on mission critical security enhancements phase 2.. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: This work item will address the SA WG3 normative security work for the mission critical architecture based on the output of SA WG6 as specified in TS 23.379, TS 23.280, TS 23.281, TS 23.282, 23.283 and TS 23.180 including: - Mission critical PTT, MCPTT individual and group functional architecture and information flows; - Mission critical data, MCData individual and group functional architecture and information flows; - Mission critical Video, MCVideo individual and group functional architecture and information flows; - Mission critical interconnection between MCPTT systems, with a scope that includes the mission critical services of individual and group MCPTT, MCVideo and MCData; - Mission critical interworking between MC systems and LMR systems which includes MCPTT and MCData (SDS only) individual and group services. - Mission critical migration between MCPTT systems, which includes the mission critical services of individual and group MCPTT, MCVideo and MCData; - MONASTERY, mission critical future railway architecture for individual and group MCPTT, MCData and MCVideo; - IOPS, mission critical isolated operation for public safety including individual and group MCPTT, MCData and MCVideo. The Stage 2 security architecture defined in Release 16 shall form the basis of the Release 17 architecture to maintain cohesion, integration and backward compatibility across Mission Critical services.

Comment:

CC#3: SP-200718_rev2 was approved. (To be revised into a new TD number by MCC). Revised to SP-200879.

Discussion and conclusion:

CC#3: SP-200718_rev2 was provided and was approved. (To be revised into a new TD number by MCC).

e-mail discussion:

AT&T supports approval of 'New WID on mission critical security enhancements phase 2' in SP-200718.
'Airbus' supports approval of 'New WID on mission critical security enhancements phase 2' in SP-200718
The WID has been revised to correct and extend the list of supporting companies.
'Erillisverkot' supports approval of 'New WID on mission critical security enhancements phase 2' in SP-200718
FirstNet supports approval of 'New WID on mission critical security enhancements phase 2' in SP-200718
The WID has been further revised to extend the list of supporting companies.

Status:

revised into a new TD number by MCC). Revised to SP-200879.

TD SP-200879 (WID NEW) New WID on mission critical security enhancements phase 2. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: This work item will address the SA WG3 normative security work for the mission critical architecture based on the output of SA WG6 as specified in TS 23.379, TS 23.280, TS 23.281, TS 23.282, 23.283 and TS 23.180 including: - Mission critical PTT, MCPTT individual and group functional architecture and information flows; - Mission critical data, MCData individual and group functional architecture and information flows; - Mission critical Video, MCVideo individual and group functional architecture and information flows; - Mission critical interconnection between MCPTT systems, with a scope that includes the mission critical services of individual and group MCPTT, MCVideo and MCData; - Mission critical interworking between MC systems and LMR systems which includes MCPTT and MCData (SDS only) individual and group services. - Mission critical migration between MCPTT systems, which includes the mission critical services of individual and group MCPTT, MCVideo and MCData; - MONASTERY, mission critical future railway architecture for individual and group MCPTT, MCData and MCVideo; - IOPS, mission critical isolated operation for public safety including individual and group MCPTT, MCData and MCVideo. The Stage 2 security architecture defined in Release 16 shall form the basis of the Release 17 architecture to maintain cohesion, integration and backward compatibility across Mission Critical services.

Comment:

Revision of SP-200718_Rev2. Approved.

Discussion and conclusion:

-

Status:

Approved.

Block 4: For Block Approval - Thursday 15:00 UTC

TD SP-200667 (WID NEW) New Work Item on 'Operation Points for 8K VR 360 Video over 5G'.. (Source:Intel, NHK, Ericsson LM, AT&T, Qualcomm Incorporated, Dolby Laboratories Inc., Beijing Xiaomi Electronics, Tencent, Huawei Technologies Co Ltd.).
Document for: Approval.
Abstract: Objective: The objective of this Work Item is to specify operation points in VR streaming specification TS 26.118 as well as new media decoding capabilities for 5GMS in TS 26.511 in order to enable support for up to 8K video. More specifically, this work item aims to conduct the following normative work in TS 26.118 and TS 26.511, toward fulfilling this objective: - Define new 360-degree video operation point(s) for VR streaming to be used in conjunction with the Main Video Profile with conforming bitstream requirement based on H.265⁄HEVC Main-10 Profile Main Tier Profile beyond the existing level 5.1 decoding capability, supporting spatial resolutions up to 8K as well as frame rates up to 120fps. - Provide implementation guidelines for deploying such new profiles and operation points. - Include the newly defined decoding capabilities and associated profiles and operation points into 5G Media Streaming. - Document typical traffic characteristics of such 8K VR 360 video services.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200719 (WID NEW) New WID on UPIP support in 5GS.. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: As per the conclusion in TR 33.853, extend the UPIP support in 5GS to cover the following RAN architecture (NG-RAN) options: - Option 4 - 5G Core based Dual Connectivity (NR master - eUTRA secondary) - Option 5 - 5G Core with eUTRA - Option 7 - 5G Core based Dual Connectivity (eUTRA master - NR secondary).

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200720 (WID NEW) New WID on Security Assurance Specification for Network Slice-Specific Authentication and Authorization Function (NSSAAF).. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The objective is to develop the Security Assurance Specification (SCAS) for the Network Slice-Specific Authentication and Authorization Function (NSSAAF) network product class, with the aims to: - identify critical assets and threats of the NSSAAF network product class not already identified in TR 33.926 - develop and⁄or adapt NSSAAF specific security functional requirements and related test cases - develop and⁄or adapt NSSAAF specific basic vulnerability testing requirements and related test cases This new work item assumes that the network element is not based on virtualization architecture. This new work item shall not create functional requirements in test specs which are not in TS 33.501.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200768 (WID NEW) New WID on N40 Interface Enhancements to Support GERAN and UTRAN.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective of this work item is to specify charging enhancements to support 2G⁄3G based on N40 interface, such as: - Specify charging functionality enhancements for PGW to support N40 interface; - Specify corresponding parameters and open API impacts;

Comment:

Revised to SP-200854.

Discussion and conclusion:

-

Status:

Revised to SP-200854.

TD SP-200854 (WID NEW) New WID on N40 Interface Enhancements to Support GERAN and UTRAN.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective of this work item is to specify charging enhancements to support 2G⁄3G based on N40 interface, such as: - Specify charging functionality enhancements for PGW to support N40 interface; - Specify corresponding parameters and open API impacts;

Convenor comment:

Block 4.

Comment:

Revision of SP-200768. Alignment of acronym with SA WG2's acronym TEI17_NIESGU. This was Block approved in CC#3.

Discussion and conclusion:

-

e-mail discussion:

Gerald (Matrixx) suggest the revision on parent WID (2.2) and other WID (2.3) to cover the correct allocation.
The SA5 chair does not support the suggestion from Gerald (Matrixx) which suggests the revision on parent WID (2.2) and other WID (2.3) to 'cover the correct allocation'. We switched to having full SA5 features instead of inserting our work items into other groups' features some years ago. The features are gathered by acronym together in the work plan so no need to use the BB structure here.
Gerald (Matrixx) is asking MCC to resolve the observation on different handling on WIDs in the 3GPP work plan.

Status:

Approved.

TD SP-200769 (WID NEW) New work item on charging enhancement for URLLC.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: This work item is to specify charging enhancement to support URLLC: - Specify charging functionality and procedures for Redundant transmission for high reliability communication; - Specify charging functionality and procedures for QoS Monitoring to Assist URLLC Service; - Specify corresponding charging parameters and Open API.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200772 (CR PACK) Rel-17 CRs on Mission critical security enhancements phase 2. (Source:SA WG3).
Document for: Approval.
Abstract: 33.180 CR0150R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200831 (WID NEW) New WID for enhanced application layer support for V2X services.. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The SA WG6 objectives include the following: 1) Develop Stage 2 normative technical specification for the enhanced application layer support capabilities based on identified key issues, solutions and conclusions in TR 23.764 mainly considering 5GS aspects and enhanced V2X (eV2X) services, including: a) Defining architecture requirements corresponding to the application layer support capabilities. b) The enhanced functional architecture of the V2X application layer illustrating the application layer support capabilities being utilized by the V2X applications and services. c) Procedures and information flows supporting solutions for the application layer support capabilities specified in the justification clause above.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200832 (WID NEW) New WID Application Architecture for MSGin5G Service.. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The focus of this work item is to develop Stage 2 normative specification for MSGin5G Service based on conclusions from TR 23.700-24. The objectives include the following: 1) Develop architectural requirements and application architecture to realize the MSGin5G service. 2) Specify functional procedures and information flows to support MSGin5G service. 3) Identify potential Stage 2 architecture enhancements in 5G system to support the application layer architecture NOTE: For potential impacts to 5G system, coordination with SA WG2 will be necessary.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200833 (WID NEW) New WID Mission Critical Services over 5GS.. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The present work item will address the necessary normative subjects required for the support of MC Services over 5GS to cover focus area 1 i.e. on-network - unicast communication for Mission Critical Services, with the following objectives: 1. The aspect of Data Networks (DN) for MC services in the context of: a. Data Network Names and PDU connectivity services; b. Related authentication for the use of the Data Network(s); c. Necessary adjustments to the functional architecture; 2. The use of 5GS QoS model in the context of: a. ARP, RQA, predefined 5QI and operator defined 5QI; b. PDU connectivity service and the corresponding QoS flows; c. Necessary interface adjustments to the functional architecture; 3. Resource management and control: a. Media plane resource management based on 5GS user plane management; b. Signalling plane control based on 5GS session management; c. Reservation and resource sharing priority of simultaneous MC service communications; 4. Roaming aspects: a. Support of 5GS roaming 5. Network slicing in the MC service Application Function context; The results of the normative work to support MC service over 5GS will be captured in a new dedicated TS. NOTE 1: Some modifications to the existing Stage 2 MC specifications may be necessary to align with the new TS. NOTE 2: Some prioritization may be required within the objectives to align with the available time in 3GPP Rel-17.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

6.5 Revised Release 17 Study Item and Work Item Descriptions

Block 4: For Block Approval - Thursday 15:00 UTC

TD SP-200690 (SID REVISED) Revised SID: Architectural enhancements for 5G multicast-broadcast services.. (Source:SA WG2).
Document for: Approval.
Abstract: Adds related Work Items and dependencies, timescales andf Rapporteur.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200766 (SID NEW) New SID on network slice management enhancement to include security aspects.. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective of this study item is to: - Investigate and propose the potential network slice information model and management service enhancements to support cross-operator network slice management use case (e.g. for V2X, etc.) - Investigate and propose the potential new management capabilities to support end to end network slicing (e.g. identified by end to end network slicing ETSI ZSM work item, GSMA 5GJA work package 1, etc.) - Investigate and propose the potential new management capabilities to support security management of network slice (e.g. security isolation management, UP protection policy management, etc. ) Note: The study should clarify the meaning of the terms 'cross-operator network slice management' and 'end to end network slicing'.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3. CC#4: WGs to avoid agreeing to multiple rapporteurs for WIDs and SIDs.

Discussion and conclusion:

CC#4: (This was Block approved in CC#3). Intel asked if there were any rules or guidelines to the existence of multiple rapporteurs for SIDs and WIDs. The SA WG5 Chairman reported that this was a merge of an existing SID and a newly proposed SID and proposing companies both wanted rapporteurs for the different aspects of the work. The SA WG5 Chairman undertook to see whether TSG SA have an objection to this. The TSG SA Chairman replied that this is strongly discouraged and asked all WGs to avoid agreeing to multiple rapporteurs for WIDs and SIDs.

Status:

Approved.

TD SP-200834 (WID REVISED) Revised WID on Architecture for enabling Edge Applications .. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The SA WG6 objectives of this work item include the following: 1. Develop Stage 2 normative technical specification for enabling Edge Applications based on the key issues, architecture, solutions and conclusions captured in 3GPP TR 23.758, with potential enhancements (including new solutions). The Stage 2 normative technical specification will include the following aspects: a. Architecture requirements and an application layer functional model to enable Edge Apps over 3GPP networks; b. Supporting detailed solutions including procedures, information flows conforming to the functional architecture specified in a); 2. Specify models to support different Edge network deployment options at the application layer, considering the deployment options captured in the TR 23.758. 3. Alignment of any northbound API definitions (e.g. network capability exposure, Edge application server enablement, NEF APIs) with CAPIF (TS 23.222) and related enhancements. NOTE 1: Coordination with SA WG2 will be required for the aspects related to integration with 3GPP networks (e.g. configurations, usage of GPSI, NEF APIs). NOTE 2: Coordination with SA WG2 will be required for solutions where both, Application layer and Network based solutions, are identified by SA WG6 and SA WG2 respectively. NOTE 3: Analysis of related work in other standards bodies e.g. ETSI ISG MEC, based on Annex A of the TR 23.758 will be considered for the normative phase.

Comment:

CC#2: SP 200834_rev1 was approved. Revised to SP-200886.

Discussion and conclusion:

CC#2: SP 200834_rev1 was approved.

e-mail discussion:

Gerald (Matrixx) requests the revision to cover charging management aspects.
Suresh Chitturi (SA6 Chair): SP-200834_Rev1 is provided with the help of Rapporteur, taking into account the feedback from Gerald (Matrixx). In addition to Charging aspects from SA5, study on Edge management aspects from SA5 and security enhancements for Edge from SA3 have also been included in the clause 2.3 Other related work-items.
Gerald (Matrixx) is fine with the revision.

Status:

Revised to SP-200886.

TD SP-200886 (WID REVISED) Revised WID on Architecture for enabling Edge Applications .. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The SA WG6 objectives of this work item include the following: 1. Develop Stage 2 normative technical specification for enabling Edge Applications based on the key issues, architecture, solutions and conclusions captured in 3GPP TR 23.758, with potential enhancements (including new solutions). The Stage 2 normative technical specification will include the following aspects: a. Architecture requirements and an application layer functional model to enable Edge Apps over 3GPP networks; b. Supporting detailed solutions including procedures, information flows conforming to the functional architecture specified in a); 2. Specify models to support different Edge network deployment options at the application layer, considering the deployment options captured in the TR 23.758. 3. Alignment of any northbound API definitions (e.g. network capability exposure, Edge application server enablement, NEF APIs) with CAPIF (TS 23.222) and related enhancements. NOTE 1: Coordination with SA WG2 will be required for the aspects related to integration with 3GPP networks (e.g. configurations, usage of GPSI, NEF APIs). NOTE 2: Coordination with SA WG2 will be required for solutions where both, Application layer and Network based solutions, are identified by SA WG6 and SA WG2 respectively. NOTE 3: Analysis of related work in other standards bodies e.g. ETSI ISG MEC, based on Annex A of the TR 23.758 will be considered for the normative phase.

Comment:

Revision of SP-200834_Rev1. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200835 (SID REVISED) Revised SID Study on support of the 5GMSG Service.. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The objective of this study item is to evaluate and identify application layer solutions where it is necessary to fulfil the requirements from stage 1. This study will produce a technical report that includes: 1) Evaluation of existing messaging solutions to identify any gaps at the application layer 2) Key issues and solutions based on Stage 1 requirements, addressing the following scenarios: a) point-to-point message b) application-to-point message c) group message d) broadcast message 3) Functional model for 5GMSG Service and potential impact to 5G system The solutions, evaluations and conclusions from the technical report should be considered input to future normative work in this area. NOTE: For potential impacts to 5G system, coordination with SA WG2 will be necessary.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200836 (SID REVISED) Revised SID Study on application layer support for . Factories of the Future in 5G network .. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The objectives of the study include: 1) Investigate and analyse general applicability of Factories of the Future related cyber-physical control applications in 3GPP TS 22.261; 2) Develop key issues, corresponding architecture requirements to make the service enabler for 'Factories of the Future' applications over 3GPP networks; 3) Providing customized solutions for Factory applications to cross-layer optimize and redesign the actual applications which now based on the classical wired cable connection world.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200837 (SID REVISED) Revised SID Study on Mission Critical services support over 5G System.. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The objective of the study is to identify the impacts on and the necessary changes in the Stage 2 Mission Critical specifications to ensure that the set of Mission Critical services is supported over the 5GS. This objective includes: - Identify subclauses in the existing stage 2 Mission Critical specifications that should also apply to the 5GS, but which currently contain 4G specific terminology and therefore would require terminology changes. - Develop a common approach (e.g. terminology) for changes in stage 2 Mission Critical specifications that apply to the 5GS. - Review and identify the 5GS aspects (e.g. 5QI, network slicing) to support Mission Critical architecture. - Identify key issues and develop solutions to ensure support of Mission Critical services over 5GS. - Evaluate the solutions and make recommendations for normative work. - Study where and how to integrate solutions in stage 2 Mission Critical specifications, either in the existing specifications or in a new specification. NOTE: In order to enable and support normative work in Release 17 this study will provide early conclusions on those aspects that have been sufficiently explored.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

6.6 New Release 18 Study Item Descriptions

TD SP-200821 (DISCUSSION) Study on Support _x00B_for Service Function Chaining in 5G System (FS_SFCin5GS). (Source:Intel, Deutsche Telekom AG, Tencent, Telefónica, Affirmed Network, AT&T, Sandvine, Convida Wireless, InterDigital, KPN, Verizon UK Ltd., KDDI, Vodafone, Telecom Italia, Cisco, b<>com, Spirent Communications).
Document for: Discussion.
Abstract: Summary: The proposed Rel-18 SA WG1 study (FS_SFCin5GS; S1-203293; updated for SA plenary in SP-200822) is supported by a large number of companies. The study proposal was noted in SA WG1 based on objections that do not challenge the technical aspects of the proposal. The comments from objecting companies focused on the wording and whether the work should proceed directly with normative work in SA WG1, or whether it can be carried out directly by stage 2 groups. This contribution provides a clear illustration of the potential stage 1 specification impact, but that a study is necessary before a conclusion can be made. Proposal: Based on the above, it is proposed to approve this SA WG1 Rel-18 SID proposal (Support of Service function chaining in 5G system (FS_SFCin5GS)).

Comment:

Noted.

Discussion and conclusion:

CC#1: This was presented by Intel which proposes to approve this SA WG1 Rel 18 SID proposal in SP-200822 (Support of Service function chaining in 5G system (FS_SFCin5GS)). This was then noted.

Status:

Noted.

TD SP-200822 (SID NEW) New SID on Study on Support for Service Function Chaining in 5G System.. (Source:Intel Corporation, Deutsche Telekom AG, Tencent, Telefónica, Affirmed Network, AT&T, Sandvine, Convida Wireless, InterDigital, KPN, Verizon UK Ltd., KDDI, Vodafone, Telecom Italia, Cisco, b<>com, Spirent Communications).
Document for: Approval.
Abstract: Objective: The aim of this work is to study the enable support of service function chaining in 5G system for value-added services provided by network operators to third parties, including:. The study will consider useUse cases and service requirements related to: - provide service definition of supported service functions and service function paths; - provide service configuration and management support of service functions and service function paths to third parties for applications and their users with value-added services, e.g. provided by 5GS only or both of 5GS and 3rd parties; - provide continuing same value-added service experiences for UEs using 5G services, e.g. eMBB, V2X, AVPROD, NCIS, etc., and moving between networks. Gap analysis between the identified service requirements and existing 5GS service requirements or functionalities. Note: the gap analysis takes into account previous work related to stage 1 services requirements on SFC already developed in other SDOs (e.g. IETF RFC 7665, IETF RFC 8300, IETF RFC 8459, ITU-T Y.2242, etc).

Comment:

CC#1: This was left for further consideration over e-mail. CC#3: This issue will be handled further in SA WG1. Saso will provide a WID proposal for discussion on Friday. CC#4: Postoned.

Discussion and conclusion:

CC#1: Ericsson commented that this was studied in Rel-13, continuing to Rel-14 in SA WG1. The confusion appears in the boundary between this functionality the 5G system, which cannot be viewed from the stage 1 into the stage 2 architecture. Nokia agreed with the issues raised by Ericsson and suggested that if there are stage 1 requirements which need to be addressed that these gaps should be identified and can be handled if necessary by normative WID and CR proposals, but did not see the need of a study for it. This was left for further consideration over e-mail.
CC#3: Intel reported that there was no consensus on this and suggested going forward with a WID update and CRs in SA WG1 and asked TSG SA to endorse the 3 items: 1 Acknowledging that N6-LAN is in scope (22.101 currently states SGi-LAN is out of scope) 2. Allowing third parties to configure service functions and SF paths for their applications 3. Adding requirements for management of SFs and SFPs intended primarily for enabling SA WG5 work. Huawei commented that these issues should be raised in an input document to the meeting and suggested discussing this at the next meeting. Vodafone commented that this has been extensively discussed in SA WG1 and proposed TSG SA endorse such bullets and asked whether the SID should be also converted to a WID. Nokia considered it too late in the meeting to submit a new WID for discussion and asked whether this could be left for the next meeting, which would allow SA WG1 to discuss the detail and agree CRs. Deutsche Telekom agreed with Nokia and supported converting the SID to a WID at this meeting as objections to progressing a SID are difficult to understand from a technical point of view. Vodafone, Deutsche Telekom and Telecom Italia supported attempting to produce a WID for approval at this meeting. Intel agreed to provide a proposal as a rev of this SID. AT&T and Vivo supported this proposal. Summary: This issue will be handled further in SA WG1. Saso will provide a WID proposal for discussion on Friday.
CC#4: SP-200822_Rev4 was the latest proposal, which was presented by Intel. Huawei commented that one of their important comments had not been accepted in this text and asked that any work done in SA WG5 should be made generic and not impose it's provision to third parties by operators. Nokia asked where 'N6-LAN' is to be removed and why this is done only for Rel 18 onwards as this will lead to incompatibility. Nokia also commented that SA WG1 do not deal with interfaces and the interface names should be removed. It was also unclear whether the Stage 1 is needed for SA WG5 to work on OAM features they consider useful. Vivo asked why the deadline for this was set to march when there is no particular time constraint for the work and SA WG1 have other studies to progress, suggesting moving it to June or later. Intel asked for the objections to be recorded as some appeared invalid and suggested allowing SA WG1 to determine their workload and the timescales for this. Deutsche Telekom commented that in SA WG1 discussions objections had made this a SID and then it has been discussed here to become a WID, so returning this to SA WG1 for further discussion will not help. Vodafone commented that if this is returned to SA WG1 there will be a new set of objections and considered this needs to be decided at TSG SA. Huawei commented that delaying the approval of this work until the next TSG will not impact the work, given that it is proposed now as a WID, rather than SID. The TSG SA Chairman suggested postponing this if no resolution can be reached at this meeting. Intel reported a proposed SP-200822_Rev6. Huawei asked to allow more time to work on this off-line and in the next SA WG1 meeting, until the next TSG SA meeting. Nokia also asked to further discuss this offline. Huawei and Nokia were asked to put their concerns or objections with SP-200822_Rev6. into the e-mail minutes comments. This SID was then postponed.

e-mail discussion:

Saso (Intel) initiates discussion thread on SP-200822.
Nokia has concerns with approving a SID on this topic as we believe that the best course of action would be to ask companies to propose a WID and related CRs in Q4 with the delta requirements that are not yet captured in TS 22.261 ( also by inheritance of those in TS 22.101 clause 30).
Patrice (Huawei) provides concerns, and proposes that discussion continues further in WGs before we can approve something (for minutiae: objects to the original paper).
Adrian (vivo) asks a question for clarification.
Krister (Ericsson) has the same view as expressed by Huawei. In addition pointing out that the 22.261 has the requirement that
, the 5G system shall support all EPS capabilities (e.g. from TSs 22.011, 22.101, 22.278, 22.185, 22.071, 22.115, 22.153, 22.173, 22.468),
In SA1 we are with term 5G System including SA2 N6-LAN as part of 5G System.
Saso (Intel) replies to comments. Seeks clarification from SA1 Chairman.
Saso (Intel) provides SP-200822rev1.
Adrian (vivo) suggest to move completion date to June 2021.
Saso (Intel) prefers keeping the completion date to Mar 2021.
Haris (Qualcomm) comments on ticking the ME and AN boxes to NO
Saso (Intel) provides rev2 with ME impact changed to 'No'.
Patrice (Huawei) manages to propose a draft revision (in the drafts folder) that could be something we could work with in such a short notice.
Saso (Intel) provides rev4.
Saso (Intel) replies to Alessio.
Gerald (Matrixx) suggest small editorial on rev4 and support the WID.
Alessio(Nokia) is expressing further concerns and providing more suggestions.
Saso (Intel) provides rev5.
Patrice (Huawei) sees that the revisions do not address his comments, and are not based on correct statements, therefore continues to object.
Saso (Intel) provides r06.
Patrice (Huawei) provides the rationale why this work would benefit for more activity at SA1 before being discussed in SA plenary, maintains his request to mark the document as postponed.
Saso (Intel) replies to patrice.
Patrice (Huawei) provides the following reasons for postponing: beside the fact that the SID-now-WID provided by the supporting companies has changed drastically since its initial submission to SA#89e, we still have concerns on the contents of the latest revision, and we believe there is no rush to force an approval of the contribution at this plenary, and instead we should work on making the best content that is agreeable to all parties, following the principles of 3GPP of doing work based on consensus. Technical concerns have been raised in details during the week and recorded as part of the email exchange and can be retrieved on list.etsi.org. I expect that further discussion will be initiated ahead of the next SA1 meeting.
Saso (Intel) kindly asks Alessio ⁄ Nokia to provide a note about the remaining concern they have with SP-200822rev6 <https:⁄⁄www.3gpp.org⁄ftp⁄tsg_sa⁄TSG_SA⁄TSGs_89E_Electronic⁄Inbox⁄Revisions⁄SP-200822_rev6.zip> for the record.

Nokia provides the text about concerns expressed:

Looking at the objectives:

- Fixing the implication that N6-LAN is 'out of 3GPP scope'.
- Allowing authorized third parties to request utilisation of specific service functionality on N6 and service functionality chaining for their applications.
- Allowing the management of service functionality on N6 and service functionality chaining, intended primarily for enabling SA5 work.

* The first objective to us needs to impact existing 22.101 and this can be a normal CAT-F work.
* The other two objectives were unclear and volatile as even 5 minutes before the confcall evolved to imply charging requirements were targeted, and this was never discussed before. For this we have had no time to check internally. For OAM aspects, we believe that normally work in SA5 can start without stage one so the objectives were probably not needed to 'enable' SA5 work.

For these reasons, Nokia has expressed concerns to approve this WID at TSG SA#89 and has suggested to continue the discussion in SA1 in Q4. For the records Nokia request at the beginning of the week has been to discuss the WID and the CRs starting from Q4 in SA1 so Nokia was not proposing to agree to a WID at TSG SA level.

Status:

Postponed.

TD SP-200798 (SID NEW) New SID: Study on vehicle-mounted relays (FS_VMR).. (Source:SA WG1).
Document for: Approval.
Abstract: Objective: The aim of this work is to study use cases and potential new service requirements for 5G system support of base station relays mounted on vehicles, using NR self-backhauling to connect with donor gNB and 5GC, including: - Use cases and requirements related to: o Vehicle (base station) relays providing service to UEs inside the vehicle or in the vicinity of the vehicle; o End-to-end service continuity during mobility scenarios (including mobility of the relays); o Provisioning, policies and control mechanisms, e.g. ? Provisioning of spectrum used by the relays, geographic area restrictions for relays; ? Control of relay operation, UEs access and connectivity via relays. - Aspects related to roaming of relays, security, regulatory requirements (e.g. for emergency services), charging, spectrum interference. - Gap analysis between the identified requirements and existing 5GS requirements or functionalities. NOTE 1: potential conflicts with other ongoing studies⁄work on relays (e.g. RAN IAB) should be avoided. NOTE 2: the base station relay is assumed to use NR-Uu for the connection with the UE, and with donor gNB. NOTE 3: the study should investigate potential new requirements for both UEs and Network; support and impacts for legacy UEs should also be considered. NOTE 4: single-hop (NR-Uu) relay should be the main⁄baseline scenario; multi-hop (NR-Uu) can also be considered. NOTE 5: main focus should be on relays mounted on ground⁄land moving vehicles; applicability of general⁄common requirements to other types of mobile base station relays (e.g. using other moving vehicles or devices) may be considered.

Comment:

CC#3: China Mobile withdrew their objection. Approved.

Discussion and conclusion:

CC#2: Qualcomm suggested noting China Mobile comment and proceed to the approval of the SID. AT&T commented that their RAN colleagues did not see any overlap with their work with this proposed study. The TSG SA Chairman pointed out that this had been agreed in SA WG1 and should be further discussed. China Mobile commented that the TSG meeting was considered the right place to make their objections as this is where the approval takes place. This should be further discussed over e-mail.
CC#3: China Mobile withdrew their objection with the understanding that there will be a gap analysis done in the study phase and expressed their disappointment that this could not move forward after long discussions, contribution, clarification and merging of proposals. This new SID was then approved. China Mobile provided the following statement: With the understanding that requirement gap can be identified in study phase, as clearly stated in this SID, Tao Sun (China Mobile) recall the objection. China Mobile expect the same chance and raise the concern that R18 stage 1 Study proposal cannot move forward after 6 month effort with two companies' claim of insufficient gap analysis even contributors provided discussion paper, online and offline clarifications, long list of supporting companies, merge multiple proposals as requested.

e-mail discussion:

Tao (China Mobile) objects to SP-200798 and all its revisions. The SID is related with RAN on-going R17 work. In view of potential delay of R17, we believe neither it is right time nor need a study.
With the understanding that requirement gap can be identified in study phase, as clearly stated in this SID, Tao Sun (China Mobile) recall the objection.
China Mobile expect the same chance and raise the concern that R18 stage 1 Study proposal cannot move forward after 6 month effort with two companies' claim of insufficient gap analysis even contributors provided discussion paper, online and offline clarifications, long list of supporting companies, merge multiple proposals as requested.

Status:

Approved.

Block 4: For Block Approval - Thursday 15:00 UTC

TD SP-200799 (SID NEW) New SID: Study on 5G Networks Providing Access to Localized Services (FS_PALS).. (Source:SA WG1 ).
Document for: Approval.
Abstract: Objective: The objectives of this study are: - Study use cases for enhanced 5G system support of a hosting network providing users⁄devices access to specific services, offered by the hosting network operator, other mobile operator(s) or 3rd party provider(s). Including scenarios where: o Access to services through the hosting network could be on demand, temporary and⁄or cover specific location(s); o The operator of the hosting network, or other mobile operator offering services to users, can be a PLMN or NPN operator; o Different RATs (3GPP or non-3GPP) and spectrum (licensed or unlicensed) could be considered; o The hosting network can also provide specific network services, e.g. location based service, time synchronization etc. - Investigate potential new service requirements, including: o Enabling users⁄UEs to discover availability of specific target networks and specific services through a hosting network; o Network functionalities to negotiate and configure access and requirements for a specific service (e.g. QoS, network slicing, charging, onboarding etc.); ? Can include policy management, service⁄QoS monitoring, and interaction between the hosting network and other mobile operator or 3rd party (offering the service) , e.g. via API or other standard mechanisms o Enabling users⁄UEs to concurrently use specific target services offered through a hosting network and the regular services offered by the HPLMN of the user⁄UE; o Enabling access to the hosting network and specific services for users⁄UEs without previous relationship with the hosting network; o Consideration of regulatory and security aspects. - Gap analysis between potential new requirements and existing requirements and functionalities supported by 3GPP, e.g. VIAPA, NPN, slicing, QoS, etc.

Comment:

CC#3: China Mobile withdrew their objection. Approved.

Discussion and conclusion:

CC#2: China Mobile clarified that the proposal was to do the Gap analysis in the normative work, rather than in the study and they did not consider the study necessary as the functionality can be handled by existing Stage 2 features. Samsung replied that this was a Stage 1 study and agreed by SA WG1 and should be allowed to proceed. Intel commented that these SIDs do have a gap analysis in their scopes. The SA WG1 Chairman reported that these two SIDs were agreed without objection in SA WG1 and a Gap analysis is always done in SA WG1, even though there is no requirement to do one. Qualcomm suggested noting China Mobile comment and proceed to the approval of the SID. The TSG SA Chairman asked China Telecom to further discuss this to determine whether some minor changes can resolve their issues with these SIDs and TSG SA should carefully consider whether WG agreed Study items should be rejected this early into their target Release. This should be further discussed over e-mail.
CC#3: China Mobile withdrew their objection with the understanding that there will be a gap analysis done in the study phase and expressed their disappointment that this could not move forward after long discussions, contribution, clarification and merging of proposals. This new SID was then approved. China Mobile provided the following statement: With the understanding that requirement gap can be identified in study phase, as clearly stated in this SID, Tao Sun (China Mobile) recall the objection. China Mobile expect the same chance and raise the concern that R18 stage 1 Study proposal cannot move forward after 6 month effort with two companies' claim of insufficient gap analysis even contributors provided discussion paper, online and offline clarifications, long list of supporting companies, merge multiple proposals as requested.

e-mail discussion:

Tao (China Mobile) objects to SP-200799 and all its revisions. The SID shall justified why current VIAPA, NPN, slicing, QoS, edge computing cannot meet the requirement.
With the understanding that requirement gap can be identified in study phase, as clearly stated in this SID, Tao Sun (China Mobile) recall the objection.
China Mobile expect the same chance and raise the concern that R18 stage 1 Study proposal cannot move forward after 6 month effort with two companies' claim of insufficient gap analysis even contributors provided discussion paper, online and offline clarifications, long list of supporting companies, merge multiple proposals as requested.

Status:

Approved.

6.7 New Release 18 Work Item Descriptions

Block 4: For Block Approval - Thursday 15:00 UTC

TD SP-200797 (WID NEW) New WID on Subscriber-aware Northbound API access (SNA).. (Source:SA WG1 (from S1-203296)).
Document for: Approval.
Abstract: Objective: The objective of this work is to specify requirements on Subscriber-aware Northbound API access, in particular for the following aspects. - Authentication and authorization of the third-party and the UE, - Authentication and authorization of the UE, - UE's privacy (e.g. MSISDN, location, presence) protection against the third-party, and - Information provisioning to find APIs.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

6.8 Revised Release 18 Study Item Descriptions and Work Item Descriptions

Block 4: For Block Approval - Thursday 15:00 UTC

6.9 Specifications for Information

TD SP-200762 (DRAFT TS) Draft TS 28.555 'Network policy management for 5G mobile networks; Stage 1'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: The present document describes background, concepts, scenario, requirements and standard consideration for policy management in 5G network. Changes since last presentation to SA Meeting #: This is the first presentation. Outstanding Issues: No outstanding issues Contentious Issues: No contentious issues.

Comment:

Revised in SP-200820.

Discussion and conclusion:

-

Status:

Revised in SP-200820.

TD SP-200820 (DRAFT TS) Draft TS 28.555 'Network policy management for 5G mobile networks; Stage 1'. (Source:SA WG5).
Document for: Information.
Abstract: Abstract of document: The present document describes background, concepts, scenario, requirements and standard consideration for policy management in 5G network. Changes since last presentation to SA Meeting #: This is the first presentation. Outstanding Issues: Actor roles,telecommunication resources. Contentious Issues: No contentious issues.

Comment:

Revision of SP-200762. Noted.

Discussion and conclusion:

CC#1: It was clarified that this was revised because the previous submission was marked for approval, whereas it is for information. This draft TS was noted. Members were asked to provide any comments and update proposals to SA WG5.

Status:

Noted.

Block 4: For Block Noting - Thursday 15:00 UTC

TD SP-200691 (DRAFT TR) Presentation of TR 23.748 for information to TSG SA (FS_enh_EC). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: The TR 23.748 studies the potential system enhancements for enhanced edge computing support, investigates the key issues and corresponding solutions to support forwarding some UE application traffic to the applications⁄contents deployed in edge computing environment, including: - Discovery of IP address of application server deployed in edge computing environment in case application layer solutions are not applicable; - Improvements to 5GC support for seamless change of application server serving the UE; - How to efficiently (with a low delay) provide local applications with information on e.g. the expected QoS of the data path; - Investigate potential solutions for supporting PSA change when the application does not support notifications of UE IP address change; - Supporting I-SMF insertion or reselection based on AF request to route the traffic to edge application; Changes since last presentation to SA: This is first time TR 23.748 is presented to TSG SA. Outstanding Issues: Several Key issues and solutions are captured in TR 23.748. Solutions and Key issues are under evaluation for final conclusion. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200692 (DRAFT TR) Presentation of TR 23.700-20 for information to TSG SA (FS_IIoT). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: The document is the outcome of FS_IIoT study. The study would enable enhanced support of IEEE TSN, also enhancements for Time Sensitive Communication to support deterministic applications. Changes since last presentation to SA: First time it is presented. The TR comprises of solutions for all Key issues targeted for Rel-17. The TR has been progressed beyond 60% completion status and is presented for information. Outstanding Issues: 1) Evaluation and conclusion for all Key Issues. Contentious Issues: None identified as contentious.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200693 (DRAFT TR) Presentation of TR 23.761 for information to TSG SA (FS_MUSIM). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: The scope of the Technical Report is to study system enablers for support of devices having multiple USIMs. The following Key Issues have been prioritized for Rel-17 at TSG SA#86: Key Issue #1: Handling of Mobile Terminated service with Multi-USIM device. Key Issue #2: Enabling Paging Reception for Multi-USIM Device Key Issue #3: Coordinated leaving for Multi-USIM device Changes since last presentation: This is the first time the TR is presented to TSG SA. The TR includes 3 Key Issues that were agreed at TSG SA#86 to be prioritized for Rel-17 i.e. KI#1, 2 and 3. The TR includes solutions for all the above Key Issues. The TR includes initial evaluations on all three key issues and some interim conclusions for KI#3. Outstanding Issues: Feedback has been requested from relevant 3GPP working groups. Evaluation of the solutions and conclusion of what to progress towards a normative phase for the 3 Key Issues. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200694 (DRAFT TR) Presentation of TR 23.700-91 for Information to TSG SA (FS_eNA_Ph2). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: TR 23.700-91 aims at further investigating system enhancements for analytics and NWDAF, based on what has been specified in Rel-15 and Rel-16, for the following: - Remaining key issues from Release 16: UE driven analytics; How to ensure that slice SLA is guaranteed; Which data from UPF can be used by NWDAF (e.g. applications, other user data characteristics); - NWDAF architecture enhancements: Multiple NWDAF Instances in one PLMN including hierarchies, roles and inter-NWDAF instance cooperation; - NWDAF features enhancement: Enabling real-time or near real-time NWDAF communication, including mechanism for data collection; Service MOS based NWDAF-Assisted UP Optimization; Minimization of the load generated by NWDAF data collection; - New Use Cases⁄key issues: Interaction between NWDAF and AI Model & Training Service owned by the operator. Changes since last presentation to SA: This is first time TR 23.700-91 is presented to TSG SA. Outstanding Issues: Several Key issues and solutions are captured in TR 23.700-91. Evaluation of these solutions and conclusion need to be progressed. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200695 (DRAFT TR) Presentation of presentation of TR 23.700-07 for information to TSG SA (FS_eNPN). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: 3GPP Rel-16 added 5GS support for Non-Public Networks based on stage 1 service requirements in TS 22.261 [2]. The scope of the Technical Report is to study further enhancements to the 5GS to fulfil the not yet supported stage 1 service requirements for Non-Public Networks in TS 22.261 [2] and requirements described in e.g. TS 22.263 [3]. The following Key Issues have been prioritized for Rel-17 at TSG SA#86: Key Issue #1: Enhancements to Support SNPN along with credentials owned by an entity separate from the SNPN Study enhancements to enable support for SNPN along with subscription ⁄ credentials owned by an entity separate from the SNPN. Key Issue #2: NPN support for Video, Imaging and Audio for Professional Applications (VIAPA) Key Issue #3: Support of IMS voice and emergency services for SNPN Key issue #4: UE Onboarding and remote provisioning Changes since last presentation: This is the first time the TR is presented to TSG SA. The TR includes 4 Key Issues that were agreed at TSG SA#86 to be prioritized for Rel-17 i.e. KI#1, 2, 3 and 4. The TR includes solutions for all the above Key Issues. The TR includes interim conclusions for KI#2, KI3 and KI#4. Outstanding Issues: Get feedback from other WGs on questions sent by liasons. Evaluation of the solutions and conclusion of what to progress towards a normative phase for the 4 Key Issues. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200696 (DRAFT TR) Presentation of TR 23.757 for information to TSG SA (FS_5MBS). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: This Technical Report studies and evaluates architectural enhancements to the 5G System to enable general multicast-broadcast service over 5GS. In order to support general multicast and broadcast communication services, e.g., transparent IPv4⁄IPv6 multicast delivery, IPTV, software delivery over wireless, group communications and IoT applications, V2X applications, public safety, the following aspects are studied: - KI#1: MBS session management; - KI#2: Definition of Service Levels. - KI#3: Levels of authorization for Multicast communication services. - KI#4: QoS level support for Multicast and Broadcast communication services. - KI#6: Local MBS service; - KI#7: Reliable delivery method switching between unicast and multicast; - KI#9: Minimizing the interruption of public safety services upon transition between NR⁄5GC and E-UTRAN⁄EPC. Changes since last presentation to SA: This is the first time TR 23.757 is presented to TSG SA. Outstanding Issues: Solutions for the Key Issues are still under evaluation for conclusion. Some solutions are dependent on RAN output. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200698 (DRAFT TR) Presentation of TR 23.700-40 to TSG SA for information (FS_eNS_Ph2). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: This study aims at identifying the gaps that need to be filled in providing support in the specifications owned by SA WG2 for the Generic Network Slice Template (GST) attributes defined by GSMA 5GJA and are captured in document NG.116. According to NG.116, several Network Slice Types (NESTs) can be derived by assigning values to applicable attributes defined in the GST. The following Key Issues have been prioritized for Rel-17 at TSG SA#86: Key Issue #1: Support of network slice related quota on the maximum number of UEs Key Issue #2: Support of network slice related quota on the maximum number of PDU Sessions Key Issue #3: limitation of data rate per network slice in UL and DL per UE Key Issue #4: Support for network slice quota event notification in a network slice Key Issue #5: Dynamic adjustment to meet the limitation of data rate per network slice in UL and DL Key Issue #6: Constraints on simultaneous use of the network slice Key Issue #7: Support of 5GC assisted cell selection to access network slice Changes since last presentation: This is the first time the TR is presented to TSG SA. The TR includes 3 Key Issues that were originally agreed at TSG SA#86 and subsequently 4 additional KIs were added. The TR includes solutions for all the above Key Issues. Outstanding Issues: Get feedback from other WGs on questions sent by liasons. Evaluation of the solutions and conclusion of what to progress towards a normative phase for the 7 Key Issues. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200699 (DRAFT TR) Presentation of TR 23.700-93 to TSG SA for information (FS_ATSSS_Ph2). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: This study investigates following aspects for UEs that can establish a MA PDU Session to 5GC over both 3GPP and non-3GPP accesses. The following key Issues have been prioritized for Rel-17 at TSG SA#86: Key Issue #1: Whether and how to support additional steering mode(s), with potential PMF extensions if needed. Key Issue #2: Whether and how to support additional steering functionality(ies). Proposed solutions shall be based on IETF protocols or extension of such protocols (i.e. QUIC⁄MP-QUIC). Key Issue #3: Whether and how to support multi-access PDU session with one 3GPP access leg over EPC and the other access leg over non-3GPP access 5GS. Changes since last presentation: This is the first time the TR is presented to TSG SA. The TR includes 3 Key Issues that were agreed at TSG SA#86. The TR includes solutions for all the above Key Issues. Outstanding Issues: Get feedback from IETF on questions sent by liasons. Evaluation of the solutions and conclusion of what to progress towards a normative phase for the 3 Key Issues. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200700 (DRAFT TR) Presentation of TR 23.754 for information to TSG SA (FS_ID_UAS_SA2). (Source:SA WG2).
Document for: Information.
Abstract: Abstract of document: 3GPP Rel-16 added 5GS support for Unmanned Aerial Vehicles based on stage 1 service requirements in TS 22.225. The scope of the Technical Report is to address system enablers for supporting Unmanned Aerial Systems Connectivity, Identification, and Tracking. In particular, the Technical Report studies mechanisms for Unmanned Aerial Vehicles (UAV) controller and UAV(s) identification and tracking in the 3GPP system, including how the 3GPP system can provide support for UAV to ground identification (e.g. to authorized third parties such as police devices), mechanisms to support UAV controller and UAV(s) authorization and authentication by UAV Traffic Management, and mechanisms to handle unauthorized UAVs and revocation of authorization (e.g. lack of connectivity to carry the UAV command and control messages, denied registration, etc.) that enables the system to keep track of and control UAV(s). The following Key Issues are considered: Issue 1: UAV identification Issue 2: UAV authorization by UTM Issue 3: UAV Controller identification and authorization⁄authentication Issue 4: UAV and UAV Controller tracking Issue 5: UAV authorization revocation and (re)authorization failures Issue 6: UAV Controller and UAV association Issue 7: User Plane Connectivity for UAVs. Changes since last presentation: This is the first time the TR is presented to TSG SA. The TR includes 7 Key Issues, and solutions for all the above Key Issues. The TR includes some interim conclusions for Key Issues #1 and #2, and some generic conclusions on other aspects. Outstanding Issues: Evaluation of the solutions and conclusion of what to progress towards a normative phase for the 7 Key Issues. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200755 (DRAFT TR) Draft TR 28.809 'Study on enhancement of management data analytics'. (Source:SA WG5).
Document for: Information.
Abstract: Abstract of document: It is the TR of Rel-17 study on enhancement of Management Data Analytics (MDA). Changes since last presentation to <TSG> Meeting #<N>: N⁄A Outstanding Issues: The following issues still need to be worked further and expected to be completed in SA#90e. - Refinement of the potential solutions; - Analytics data collection control and reporting; - Conclusions and recommendations. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200828 (DRAFT TS) Presentation of TS 23.558 v1.0.0 for information. (Source:SA WG6).
Document for: Information.
Abstract: Abstract of document: TS 23.558 is a technical specification capturing the architecture for enabling edge applications over 3GPP networks. The TS includes architectural requirements for enabling edge applications, application layer architecture fulfilling the architecture requirements and corresponding procedures to enable the deployment of edge applications on the edge of 3GPP networks, with minimal impact to edge-based applications on the UE. The work is progressing on the objectives of EDGEAPP WID, and the technical specification includes the following: 1. 11 sets of architecture requirements covering the following: a. General requirements; b. Edge configuration data; c. Registration; d. Edge Application Server discovery; e. Capability exposure to Edge Application Servers; f. Security; g. Subscription service; h. Traffic management; i. Lifecycle management; j. Edge application KPIs; and k. Service continuity; 2. Application layer architecture with functional entity and reference point descriptions including cardinality rules, identities and commonly used values; 3. Detailed procedures including information flows and APIs, covering: a. Service provisioning including Edge Configuration Server discovery; b. Registrations, including: i. Edge Enabler Client Registration; ii. Edge Application Server; and iii. Edge Enabler Server Registration; c. Edge Application Server Discovery; d. EES capability exposure to EAS, providing: i. UE location API; ii. User plane path management events; iii. Application Client Information exposure API; iv. UE Identifier API; and v. Session with QoS API; e. 2 modes of network capability exposure to EAS: i. Direct network capability exposure; and ii. Network capability exposure via Edge Enabler Server; f. Service continuity (work in progress); g. Utilization of 3GPP core network capabilities by the architecture, including: i. Capabilities utilized by Edge Configuration Server; ii. Capabilities utilized by Edge Enabler Server; and iii. Capabilities utilized by Edge Application Server; and h. EEC Authentication⁄Authorization; 4. Deployment options and relationships involved in edge computing service (informative); and 5. Relationship with ETSI MEC architecture (informative). Changes since last presentation to SA: First presentation of TS 23.558 to SA. Outstanding Issues: Following in-progress work is expected to be complete by SA#90-e (December 2020): - Further details supporting service continuity; - Outstanding APIs and related details; and - Clean-up of open editor's notes. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200829 (DRAFT TR) Presentation of TR 23.745 v1.0.0 for information. (Source:SA WG6).
Document for: Information.
Abstract: Abstract of document: TR 23.745 studies key issues, architecture requirements, FFAPP functional model, and corresponding solutions for application layer support for Factories of the Future in 5G network. This technical report progresses the objectives of the study, including the following: 1) Identification of following key issues and corresponding architecture requirements for application layer support for FF services including areas such as: - Use of network slicing for FFAPP. - Geographic location and positioning information support. - Clock synchronization. - TSN supporting. - QoS monitoring. - 5GLAN group management. - Device Onboarding. - Communication of FF application requirements with 5GS. - Communication service on the Edge deployments. - Integration with Existing Operation Technologies. - QoS coordination. - User authorization. - Capability Exposure related to Private Slice Network Status. - Device monitoring. - Support for group communication. 2) A FFAPP functional model is specified to support the FF application enabler functionalities which are illustrated via the solutions to the key issues. 3) Individual solutions specified address some key issues. 4) Solutions evaluation and overall evaluation (work in progress). Remaining work is to complete the solutions for some key issues with evaluations and provide the conclusions regarding the normative work. Changes since last presentation to TSG SA: TR 23.745 is presented for the first time to SA. Outstanding Issues: 1) Architecture related to TSN Integration 2) Onboarding⁄Provisioning Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

TD SP-200830 (DRAFT TR) Presentation of TR 23.700-24 v1.0.0 for information. (Source:SA WG6).
Document for: Information.
Abstract: Abstract of document: 3GPP TR 23.700-24 studies solutions to satisfy the requirements for MSGin5G Service (message service for MIoT over 5G System). This TR develops the application architecture needed to support MSGin5G service over 5G system, based on the stage 1 requirements specified in 3GPP TS 22.262. The TR includes the following contents: - The analysis of scenarios from technical perspective. - Key issues and related solution to satisfy the requirements for MSGin5G Service. - Architectural requirements and application architecture of the MSGin5G Service. The analysis of whether the MSGin5G service can be provided by the 5G architecture will be also addressed in this TR. Changes since last presentation to SA: This is the first presentation to SA. Outstanding Issues: Major solutions and conclusion to be completed at SA WG6#40-e (11⁄20) Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was block noted in CC#3.

Discussion and conclusion:

-

Status:

Noted.

6.10 Specifications for Approval ⁄ for Information and Approval

Block 4: For Block Approval - Thursday 15:00 UTC

TD SP-200666 (DRAFT TS) Draft TS 26.512: 5G Media Streaming (5GMS); Protocols. (Source:SA WG4).
Document for: Approval.
Abstract: Abstract of document: TS 26.512 specifies the set of protocols and APIs for 5G Media Streaming (5GMS) services based on the 5G Media Streaming Architecture (5GMSA). The 5GMSA supports services including MNO and third-party Downlink Media Streaming Services, and MNO and third-party Uplink Media Streaming Services. Changes since last presentation to SA Meeting: The outstanding issues from first presentation are resolved and incorporated into the specification., specifically - some details of the provisioning session API, - the details of the Policy Template Configuration API, - the Consumption Reporting Configuration API, - basic procedures for Media Session Handler and Media Player interaction, - alignment of URL paths and resource handling across APIs. Outstanding Issues: - creation of the yaml schemas. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200756 (DRAFT TR) Draft TR 28.812 'Study on scenarios for Intent driven management services for mobile networks'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: The present document describes background, concepts, scenario, potential requirements and standard consideration for intent driven MnS. Changes since last presentation to SA Meeting #: This is the first presentation. Outstanding Issues: No outstanding issues Contentious Issues: No contentious issues.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200757 (DRAFT TS) Draft TS 28.309 'Management of Quality of Experience (QoE) measurement collection Integration Reference Point (IRP); Solution Set (SS) definitions'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Specification of stage 3 for the Quality of Experience measurement collection Integration Reference Point in UMTS and LTE. Changes since last presentation to <TSG> Meeting #<N>: This is the first presentation. Outstanding Issues: None. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200758 (DRAFT TS) Draft TS 28.313 'Study on new aspects of Energy Efficiency (EE) for 5G'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: The present document specifies the concepts, use cases, requirements, and procedures for the SON functions in 5GS. Changes since last presentation to TSG SA Meeting #<N>: This is the first presentation. Outstanding Issues: None Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200759 (DRAFT TR) Draft TR 28.810 'Study on concept, requirements and solutions for levels of autonomous network'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: The TR describes the background, concept, definition and classification of network autonomy levels, typical scenarios for managing network and service which need autonomous support, the potential solutions and relation with autonomous network related standardized features and recommendation on normative work for autonomous network level. Changes since last presentation to TSG SA Meeting #89: Add conclusion and recommendation. Outstanding Issues: None Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200760 (DRAFT TS) Draft TS 28.201 'Network slice performance and analytics charging in the 5G System (5GS); Stage 2'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: TS 28.201 specifies the network slice performance and analytics charging in 5G System, including the following aspects: - The charging principle for NSPA Charging; - Charging architecture for NSPA Charging, a new function CEF (Charging Enablement Function) is introduced; - The corresponding message flow, triggers and charging information for the charging principle and charging architecture; - Charging information for the new NF consumer of Nchf Charging service; - Extensions of Nchf Charging service API, and new CHF CDR(s) ASN.1. Changes since last presentation to SA Meeting #<N>: Complete the stage 2 work on charging information for NSPA charging and stage 3 work on Open API and CHF CDR. Outstanding Issues: There are no outstanding issues. Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200761 (DRAFT TS) Draft TS 28.202 'Network slice management charging in the 5G System (5GS); Stage 2'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: This document specifies the Converged Charging of network slice management in the 5G System (5GS). The network slice management in the scope relates to Provisioning management services defined by TS 28.531. The specification covers the charging architecture with converged charging service exposed by CHF over Nchf, the related procedures and corresponding CHF CDRs dedicated functional description. Changes since last presentation to SA Meeting #88: The new Charging Enablement Function (CEF) has been incorporated as the final name. The charging architectures are updated with the two alternatives: - Charging Trigger Function (CTF) based: MnS Producer (CTF) as a consumer CHF service - Charging Enablement Function (CEF) based: CEF as consumer of Provisioning MnS and CHF service The 'Tenant Identifier' and 'MnS Consumer Identifier' are introduced, and the full baseline structure of 'Network Slice Management (NSM) charging' is specified. Outstanding Issues: None Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200826 (DRAFT TS) Presentation of TS 23.180 v2.0.0 for approval. (Source:SA WG6).
Document for: Approval.
Abstract: Abstract of document: 3GPP TS 23.180 specifies the functional architecture, procedures and information flows needed to support mission critical services in the IOPS mode of operation. The normative work has been developed based on the study results captured in 3GPP TR 23.778, the existing stage 1 service requirements defined in 3GPP TS 22.346 and 3GPP TS 22.280, stage 2 work related to the definition of the IOPS mode of operation in 3GPP TS 23.401 and the support of mission critical (MC) services defined in 3GPP TS 23.280, 3GPP TS 23.379, and 3GPP TS 23.282. This technical specification has progressed the objectives of the work, including specifying the following: 1) The architecture requirements for the support of MC services in IOPS. 2) The functional architecture to support MC services in IOPS and specifying the required functional entities and reference points. 3) Application plane identities used in IOPS. 4) Application of functional model to deployments. 5) Procedures and information flows for the following features: - User authentication - IOPS discovery - IOPS subscription and notification - Use of MBMS transmissions - MCPTT group calls in IOPS - MCPTT private calls in IOPS - MCPTT floor control in IOPS - MCData one-to-one short data service in IOPS - MCData group short data service in IOPS 6) Configuration data required for the support of MC services in IOPS. 7) The definition of an MC IOPS notification on the primary MC system. Changes since last presentation to SA#88-e: The configuration data required for the support of MC services in the IOPS mode of operation has been introduced in TS 23.180. Also, several clauses have been updated to address editor's notes and to provide further needed descriptions. Outstanding Issues: None Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200827 (DRAFT TR) Presentation of TR 23.764 v2.0.0 for approval. (Source:SA WG6).
Document for: Approval.
Abstract: Abstract of document: TR 23.764 studies key issues, architecture requirements, updated V2XAPP functional model, and corresponding solutions for enhancements to application layer support for V2X services. This technical report progresses the objectives of the study, including the following: 1) Identification of 16 key issues and corresponding architecture requirements for application layer support for V2X services including areas such as: - eV2X application QoS requirements for V2X communication over PC5. - eV2X application QoS requirements for V2X communication over Uu. - V2X application support for network slicing. - Support for tele-operated driving. - V2X control and message distribution over Uu. - Multi-PLMN support by application enabler layer. - Capability exposure to V2X application specific server using CAPIF. - Application layer support for groupcast mode of V2X communication. - UE-to-UE application layer relay. - Support for switching modes for V2V communications. - V2X UE measurement reporting to VAE server - Supporting multiple V2X service providers - Usage and management of the range QoS parameter - Support for Local MBMS - Supporting dynamic information for HD maps - Enhancements to V2X group management and group communication 2) An updated V2XAPP functional model is specified to support the enhanced V2X application enabler functionalities which are illustrated via the solutions to the key issues. 3) Analysis of 3GPP 5GS architecture for V2X communications. 4) Individual solutions are specified addressing 13 key issues. 5) Solutions evaluation, overall evaluation and conclusion. Changes since last presentation to TSG SA Meeting #88e: The following aspects are completed since the last presentation to SA: 1) 6 Key issues are added 2) Solutions addressing 7 key issues are added. 3) Overall evaluation and conclusions are completed. Outstanding Issues: None Contentious Issues: None.

Convenor comment:

Block 4.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

7 Release Planning

7.1 General Release Planning issues

TD SP-200815 (DISCUSSION) 3GPP Meeting Planning H1⁄2021. (Source:TSG SA Chairman).
Document for: Information.
Abstract: H1⁄2021 WG and e-meetings should be planned as e-meetings.

Comment:

Noted.

Discussion and conclusion:

CC#1: This was presented by the TSG SA Chairman and indicates that it is likely that Q1⁄2021 and Q2⁄2021 will need to be e-meetings. It is possible that Elections may be held in March 2021, in which case the meeting may be extended to start early to allow time to hold electronic elections. It was clarified that any such extensions would not be for technical discussion. This was then noted.

Status:

Noted.

TD SP-200819 (DISCUSSION) Thoughts about enumerating SA WG1 requirements. (Source:Siemens, Philips).
Document for: Endorsement.
Abstract: We share our thoughts about an enumeration process for SA WG1 reports and specifications.

Comment:

CC#3: TSG SA Chairman will start a moderated TSG SA e-mail discussion on the enumeration issue until the next TSG SA meeting. This was then noted.

Discussion and conclusion:

CC#2: Deutsche Telekom asked whether the enumeration was intended only for requirements related to Verticals, as they have some concerns over doing this for all requirements including architecture requirements, etc. Currently, this was only related to SA WG1. LG Electronics welcomed this proposal which can be very useful, but could foresee problems if this goes beyond SA WG1 as suggested in clause 4, and also into other groups and bodies' specifications. The SA WG1 Chairman commented that within SA WG1 they should be consistent in all their specifications starting at Rel-18, so to enumerate all requirements and not only a subset of them. Qualcomm commented that currently requirements are not enumerated in 21.801 drafting rules and without a change to these this mechanism cannot be fully enabled. Samsung commented that this has been done already for Mission Critical requirements and this could be used as a basis on how to maintain the enumeration with added and removed requirements, without a need to update the drafting rules. Qualcomm asked whether there was any guidance in the drafting rules to ensure that removed lines are marked 'Void' rather than deleting the whole requirement to preserve enumeration. This should be further discussed over e-mail.
CC#3: Latest proposal was SP-200819_rev01. The TSG SA Chairman asked whether we can review and approve the related CR packs. Qualcomm commented that they could not agree to the CRs at this time and suggested further discussion. Deutsche Telekom commented that the CRs are only editorial categories (D) and suggested this is further discussed to have a method for handling such changes in the future. Vodafone agreed that this should be taken as a general procedural discussion on whether and how such changes should be allowed to frozen Releases. Siemens accepted that further discussion was required but these should not be rejected based on their category and only some of the CRs can be discarded. TSG SA Chairman will start a moderated TSG SA e-mail discussion on the enumeration issue until the next TSG SA meeting. This was then noted.

e-mail discussion:

LG Electronics indicates the facts that it is beneficial to have requirements enumerated in some specifications, if not all, and that the idea of enumeration can be made 'Recommended Practice' within a WG, which means that if enumeration of some requirements of a certain TR or TS is considered needed, it can be done in that particular WG but it does not have to be enforced. Generalization of this idea of enumeration may require careful consideration and examination as maintenance of them, if happens, is a different story requiring different dimension of complexity compared to the benefit it seems to bring in. No discussion for 21.801 is necessary. LG Electronics proposes the following sentence to be added to the revision of SP-200819 for endorsement.
The enumeration of requirements of a TR⁄TS is recommended on a need basis but is not necessarily required for all TR⁄TS's. The requirement numbers go with the TR⁄TS version, which mean they might be different in a different version of the TR⁄TS, i.e., changed, deleted, or replaced along with how an existing requirement is destined to be in the next version of TR⁄TS during the casual course of work, including changes by technical (p)CRs and⁄or maintenance CRs.
Adrian (vivo) asks LG what do they mean 'on a need basis?'
In response to NCSC's comment, LG provides the following:
The enumeration of requirements of a TR⁄TS is recommended on a need basis but is not necessarily required for all TR⁄TS's. The requirement numbers go with the TR⁄TS version, and are recommended not to change drastically in order to keep the ease of reference unless there are relevant reasons (e.g., deletion, merge, relocation, etc.) which mean they might be different in a different version of the TR⁄TS, i.e., changed, deleted, or replaced along with how an existing requirement is destined to be in the next version of TR⁄TS during the casual course of work, including changes by technical (p)CRs and⁄or maintenance CRs.
Haris (Qualcomm) would like to see first a CR to TR 21.801 before agreeing on this idea of enumerating SA1 requirements endorsed officially. Recommends to have some email discussion e.g. moderated by someone, that will discuss all aspects mentioned below and we can come to some smooth discussion in SA#90e.
Tony (Futurewei) would like to support the enumeration of the requirements in stage-1 specifications with the understanding that procedures for doing so will be captured⁄specified officially.
Ki-Dong (LGE) raises comments on what Puneet (SA2 Chairman) responded to Adrian(Vivo) to clarify that we do not need both mappings (e.g., b⁄w CPR and PR, CPR and UC) but one mapping table between CPRs and PRs is enough for traceability purposes as long as PRs come with clause numbers.
Puneet (SA2 Chairman) responds to Adrian(Vivo).
Adrian (vivo) support the enumeration of the requirements in stage-1 specifications and asks Puneet a question for clarification.
Puneet (SA2 Chairman) support the enumeration of the requirements in stage-1 specifications. Proposes further enhancements.
Ericsson wants to point out that it should not be any tracking process between SA1 TRs and TSs. The reason is that potential requirements are just potential and important that there is a freedom to change requirements in normative work, even beyond recognition. As we work consensus based that should be the principle.
Siemens agrees with Ericson that there should not be any tracking process between SA1 TRs and TSs and points out that SP-200819 does not stipulate such process.
Siemens also thinks that a change to a 21 document, for instance TR 21.801, is needed before requirement enumeration in Stage-1 specifications can become officially endorsed by SA. Siemens also agrees with Qualcomm that a pertinent CR should be discussed on the email reflector before presenting it at SA#90-e.
Johannes (Deutsche Telekom) does see a heavy overcomplication of introducing the need for requirements numbering and objects to endorsing a guidance before this is discussed in more details, potentially ending up in a CR to the drafting rules in TR 21.801.
Siemens uploaded SP-200819rev01 to the Revisions folder. Changes made: added Daimler and Sennheiser as source; included a sentence in clause 3.1, stating that the requirements in technical specifications do not track potential and consolidated potential requirements in technical reports.
Huawei support to develop a mechanism to better trace the requirements in stage-1. This is beneficial not only for verticals but also for coordination between SA1 and other WGs. We would also like to see a CR capturing the details in 21.801 and we can have an offline email discussion on it, and target to provide the concrete mechanism in next plenary. Whether we implement it to all the specifications in SA1 can also be discussed once the mechanism is clear.
ZTE prefers to stick to existing drafting rule and does not support the enumerating of requirement.
Philips responds to ZTE and DT.
Jinguo response to Philips and is fine if the enumerating requirement is only applied to SA1.
Johannes (Duetsche Telekom) asks for clarification on the proposal from SA1 chair: currently we have SA1 CRs submitted to this plenary even for Rel16 specs to implement the enumeration of requirements before we have concluded on a way forward. Do we postpone these CRs for a treatment in SA#90-e?

Status:

Noted.

7.2 Issues related to Release 16 and earlier planning (nothing expected here)

7.3 Release 17 Planning (schedule, prioritization, etc.)

TD SP-200800 (DISCUSSION) On Release 17 Schedule. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: Proposes finalisation of rel.17 schedule.

Comment:

Noted.

Discussion and conclusion:

CC#1: Qualcomm presented these slides which propose finalisation of the Rel-17 schedule, taking into account the current electronic meeting environment and expected slower progress of the normative work in electronic meetings. This proposed to extend the Rel-17 schedule at this TSG SA meeting (+6 months). This was then noted.
CC#2: The latest proposed text from e-mail was reviewed. Huawei commented that there could be objections to a WID produced for item 2) which should not automatically result in the removal of the WID from Rel 17. ZTE asked for clarifications on item 3). CATT commented that there was no advantage to generating exception sheets for SIDs and asked to add that coordination with RAN work can be done in the normative phase. Nokia commented that item 3) was unnecessary as we never had exceptions for Study items in the past. It was clarified that the Work Items will be produced as a result of the Study Item conclusions. Vivo asked to clarify item 3) to indicate which items exceptions can be provided for. Orange commented that it should be clarified that SA WG2 should only include already prioritised Rel 17 work items in item 1). Orange also commented that as this is the second time Rel 17 is being considered for extension, it should be stated that this will not happen again. The TSG SA Chairman replied that if we take into account all possible misinterpretations of the bullets, it would need a lot of time to draft the guidelines and the spirit of the text should be taken into account. The SA WG6 Charman asked to add some actions to clarify which parts apply to SA WG2 and which apply to SA WG6. This should be further discussed over the e-mail.

e-mail discussion:

Haris (Qualcomm) comments on the rel.17 timescales discussion
Puneet (SA2 Chairman) provides a proposal on SA guidance on Rel-17 timelines
Haris (Qualcomm) comments on the proposal
Adrian (vivo) comments on the rel.17 timescales discussion
Tony (Futurewei) comments on the proposal.
Puneet (SA2 Chairman) provides a response.
Adrian (vivo) provides an updated proposal on SA guidance on Rel-17 timelines
LaeYoung (LGE) asks some questions for clarification.
Miikka (Nokia) provides an updated proposal on SA guidance on Rel-17 timelines
Andy (Samsung) provides an updated proposal on SA guidance on Rel-17 timelines.
Jianhua(OPPO) would like to clarify clearly SA2 can have exceptions for Items or KIs which has dependency with other WGs progress if they can not be concluded in December,2020.
Haris (Qualcomm) also supports the modified text from Miikka
Krister (Ericsson) supports to be clear on what is expected by December completion of study items and new WIDs.
Adrian (vivo) asks a question for clarification on the modification made by LaeYoung.
Tricci (ZTE) asks for clarification for new wordings from LaeYoung.
LaeYoung (LGE) answers to Q from Tricci (ZTE) and Adrian (vivo).
Tony (Futurewei) comments on latest proposed text.
Puneet (SA2 Chairman) provides the updated text.
LaeYoung (LGE) can support the latest proposed text by Puneet (SA2 Chair).
Tony (Futurewei) supports the latest proposed text by Puneet.
Yusuke (KDDI) would like to support the latest proposed text by Puneet.
Adrian (vivo) would like to support the latest proposed text by Puneet.
Ming (CATT) would like to support the latest proposed text by Puneet.
Tricci (ZTE) would like to support the latest proposed text by Puneet.
Krister (Ericsson) would like to support the latest proposed text by Puneet.
Johannes (Deutsche Telekom) supports the CT chair to also list CT in the action as there is also stage2 work to be finalized in time. Addition of text is proposed.
Krisztian (Apple) supports the below proposed text by Puneet.
Puneet (SA2 Chairman) provides draft LS OUT in the revision folder.
Puneet (SA2 Chairman) provides r01 in the revision folder.
Puneet (SA2 Chairman) provides r02 in the revision folder.

Status:

Noted.

TD SP-200811 (DISCUSSION) Discussion on Rel-17 Schedule. (Source:Huawei, HiSilicon).
Document for: Agreement.
Abstract: Discussion on Rel-17 Schedule.

Comment:

Noted.

Discussion and conclusion:

CC#1: Huawei presented these slides which indicate tht SA WG2 study work is slower than originally predicted and normative work will consequently be delayed and proposed to extend the Rel 17 schedule at this TSG SA meeting (+3 months) and review again at the next TSG SA meeting. This was then noted.
CC#2: The latest proposed text from e-mail was reviewed. Huawei commented that there could be objections to a WID produced for item 2) which should not automatically result in the removal of the WID from Rel 17. ZTE asked for clarifications on item 3). CATT commented that there was no advantage to generating exception sheets for SIDs and asked to add that coordination with RAN work can be done in the normative phase. Nokia commented that item 3) was unnecessary as we never had exceptions for Study items in the past. It was clarified that the Work Items will be produced as a result of the Study Item conclusions. Vivo asked to clarify item 3) to indicate which items exceptions can be provided for. Orange commented that it should be clarified that SA WG2 should only include already prioritised Rel 17 work items in item 1). Orange also commented that as this is the second time Rel 17 is being considered for extension, it should be stated that this will not happen again. The TSG SA Chairman replied that if we take into account all possible misinterpretations of the bullets, it would need a lot of time to draft the guidelines and the spirit of the text should be taken into account. The SA WG6 Charman asked to add some actions to clarify which parts apply to SA WG2 and which apply to SA WG6. This should be further discussed over the e-mail.

e-mail discussion:

Haris (Qualcomm) comments on the rel.17 timescales discussion
Puneet (SA2 Chairman) provides a proposal on SA guidance on Rel-17 timelines
Haris (Qualcomm) comments on the proposal
Adrian (vivo) comments on the rel.17 timescales discussion
Tony (Futurewei) comments on the proposal.
Puneet (SA2 Chairman) provides a response.
Adrian (vivo) provides an updated proposal on SA guidance on Rel-17 timelines
LaeYoung (LGE) asks some questions for clarification.
Miikka (Nokia) provides an updated proposal on SA guidance on Rel-17 timelines
Andy (Samsung) provides an updated proposal on SA guidance on Rel-17 timelines.
Jianhua(OPPO) would like to clarify clearly SA2 can have exceptions for Items or KIs which has dependency with other WGs progress if they can not be concluded in December,2020.
Haris (Qualcomm) also supports the modified text from Miikka
Krister (Ericsson) supports to be clear on what is expected by December completion of study items and new WIDs.
Adrian (vivo) asks a question for clarification on the modification made by LaeYoung.
Tricci (ZTE) asks for clarification for new wordings from LaeYoung.
LaeYoung (LGE) answers to Q from Tricci (ZTE) and Adrian (vivo).
Tony (Futurewei) comments on latest proposed text.
Puneet (SA2 Chairman) provides the updated text.
LaeYoung (LGE) can support the latest proposed text by Puneet (SA2 Chair).
Tony (Futurewei) supports the latest proposed text by Puneet.
Yusuke (KDDI) would like to support the latest proposed text by Puneet.
Adrian (vivo) would like to support the latest proposed text by Puneet.
Ming (CATT) would like to support the latest proposed text by Puneet.
Tricci (ZTE) would like to support the latest proposed text by Puneet.
Krister (Ericsson) would like to support the latest proposed text by Puneet.
Johannes (Deutsche Telekom) supports the CT chair to also list CT in the action as there is also stage2 work to be finalized in time. Addition of text is proposed.
Krisztian (Apple) supports the below proposed text by Puneet.

Status:

Noted.

TD SP-200862 (LS OUT) [DRAFT] LS on R17 schedule. (Source:TSG SA).
Document for: Approval.
Abstract: To:TSG CT, SA WG1, SA WG2, SA WG3, SA WG4, SA WG5, SA WG6. CC: TSG RAN.

Comment:

CC#3: A corrected version was provided in the revisions folder as SP-200862_rev1. CC#4: SP-200862_Rev2 approved. Revised to SP-200888.

Discussion and conclusion:

CC#3: draft_r0 was provided and was reviewed on-line. TSG CT should be included in the 'To' field and Work items should be WIDs. Some further clarifications were needed and the corrected version was provided in the revisions folder as SP-200862_rev1.
CC#4: SP-200862_Rev2 was the latest proposal. This was approved. (To be revised into a new TD number by MCC).

Status:

Revised to SP-200888.

TD SP-200888 (LS OUT) LS on Rel-17 schedule. (Source:TSG SA).
Document for: Approval.
Abstract: To: SA WG1, SA WG2, SA WG3, SA WG4, SA WG5, SA WG6, TSG CT. CC: TSG RAN.

Comment:

Revision of SP-200862_Rev2. Approved.

Discussion and conclusion:

-

Status:

Approved.

7.4 Release 18 Planning (schedule, prioritization, etc.)

8 Rel-8 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

9 Rel-9 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

10 Rel-10 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200728 (CR PACK) Rel-10 CRs on TEI. (Source:SA WG5).
Document for: Approval.
Abstract: 32.103 CR0019; 32.103 CR0020; 32.103 CR0021; 32.103 CR0022; 32.103 CR0024; 32.103 CR0023R1; 32.103 CR0025R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

11 Rel-11 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200727 (CR PACK) Rel-11 CRs on TEI. (Source:SA WG5).
Document for: Approval.
Abstract: 28.623 CR0096R1; 28.623 CR0097R1; 28.623 CR0098R1; 28.623 CR0099R1; 28.623 CR0100R1; 28.623 CR0101R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

12 Rel-12 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200726 (CR PACK) Rel-12 CRs on TEI. (Source:SA WG5).
Document for: Approval.
Abstract: 32.107 CR0002; 32.107 CR0003; 32.107 CR0004; 32.107 CR0005; 32.107 CR0006.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

13 Rel-13 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200714 (CR PACK) Rel-13 CRs on Enhancements to WEBRTC interoperability. (Source:SA WG3).
Document for: Approval.
Abstract: 33.203 CR0253; 33.203 CR0254; 33.203 CR0255; 33.203 CR0256.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

14 Rel-14 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

15 Rel-15 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200671 (CR PACK) CRs to 23.501, 23.502 on 5GS_Ph1 (Rel-15, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2419; 23.501 CR2420; 23.502 CR2278R4; 23.502 CR2368R1; 23.502 CR2335R1; 23.502 CR2336R1; 23.502 CR2378R1; 23.502 CR2380R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200672 (CR PACK) CRs to 23.401 on NB_IOTenh-Core, CIoT_ext (Rel-15, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.401 CR3606; 23.401 CR3607.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200702 (CR PACK) Rel-15 CRs on Security Assurance Specification for eNB network product class. (Source:SA WG3).
Document for: Approval.
Abstract: 33.216 CR0016; 33.216 CR0017.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200709 (CR PACK) Rel-15 CRs on Security aspects of 5G System - Phase 1 batch 1. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0857; 33.501 CR0858; 33.501 CR0859; 33.501 CR0860; 33.501 CR0861; 33.501 CR0862; 33.501 CR0863; 33.501 CR0864; 33.501 CR0865; 33.501 CR0866; 33.501 CR0867; 33.501 CR0868; 33.501 CR0869; 33.501 CR0870; 33.501 CR0871; 33.501 CR0872; 33.501 CR0875; 33.501 CR0876; 33.501 CR0877; 33.501 CR0878; 33.501 CR0879; 33.501 CR0945; 33.501 CR0873R1; 33.501 CR0874R1; 33.501 CR0834R3.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

e-mail discussion:

CR 00908 33501 belonging to the CR pack SP-200709 belongs to the wrong specification and hence it should be removed from the pack.
The previous comment was made against the wrong document: CR 00908 33501 in CR pack SP-200706 and not SP-200709 belongs to the wrong specification and hence it should be removed from the pack.

Status:

Approved.

TD SP-200725 (CR PACK) Rel-15 CRs on TEI. (Source:SA WG5).
Document for: Approval.
Abstract: 32.291 CR0253; 32.422 CR0341; 32.422 CR0342.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200730 (CR PACK) Rel-15 CRs on Network Resource Model (NRM) for 5G networks and network slicing. (Source:SA WG5).
Document for: Approval.
Abstract: 28.541 CR0324; 28.541 CR0325; 28.541 CR0326R1; 28.541 CR0327R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200731 (CR PACK) Rel-15 CRs on Performance Assurance for 5G networks including network slicing. (Source:SA WG5).
Document for: Approval.
Abstract: 28.532 CR0142; 28.550 CR0062; 28.550 CR0063.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200735 (CR PACK) Rel-15 CRs on Provisioning of network slicing for 5G networks and services. (Source:SA WG5).
Document for: Approval.
Abstract: 28.531 CR0055; 28.531 CR0056.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200736 (CR PACK) Rel-15 CRs on Management and orchestration of 5G networks and network slicing. (Source:SA WG5).
Document for: Approval.
Abstract: 28.532 CR0140R1; 28.532 CR0141R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200742 (CR PACK) Rel-15 CRs on Service Based Interface for 5G Charging. (Source:SA WG5).
Document for: Approval.
Abstract: 32.291 CR0268; 32.291 CR0264R1; 32.291 CR0265R1; 32.291 CR0269.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200773 (CR PACK) Rel-15 CRs on Security aspects of 5G System - Phase 1 Batch 2. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0887; 33.501 CR0925; 33.501 CR0926; 33.501 CR0946; 33.501 CR0947; 33.501 CR0948; 33.501 CR0949; 33.501 CR0924R1; 33.501 CR0901R2; 33.501 CR0950; 33.501 CR0951; 33.501 CR0883R1; 33.501 CR0884R1; 33.501 CR0885R1; 33.501 CR0920R1; 33.501 CR0921R1; 33.501 CR0914R1; 33.501 CR0915R1; 33.501 CR0916R1; 33.501 CR0917R1; 33.501 CR0888R1; 33.501 CR0943R1; 33.501 CR0944R1; 33.501 CR0954.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200806 (CR PACK) Rel-15 CRs on Lawful Interception. (Source:SA WG3-LI).
Document for: Approval.
Abstract: 33.108 CR0420R1; 33.108 CR0421R1; 33.128 CR0115; 33.128 CR0116.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

16 Rel-16 CRs

TD SP-200657 (CR) 21.900 CR0064 (Rel-16, 'C'): CR to TR 21.900 on Relaxation of mini-WID requirement for Cat.B⁄C TEI CRs. (Source:NEC on behalf of TSG RAN).
Document for: Approval.
Abstract: TSG RAN endorsed (during the RAN#88e plenary) a draft CR to TR 21.900 in RP-200720 on Relaxation of mini-WID requirement for Cat.B⁄C CRs with the intention to submit the formal CR to SA#89e. It is also planned that RAN#89e plenary approves an accompanying LS to SA with explanation, but to comply with the SA Tdoc deadline and acquire a CR number, this Tdoc number is requested in advance. Summary of change: Restricts the requirement to provide a WID for Cat. B⁄C TEI CRs in such a way that it applies only to TSGs that have not agreed on an alternative process.

Comment:

Same as draft CR proposed by TSG RAN in SP-200868. CC#4: Postponed.

Discussion and conclusion:

CC#4: Deutsche Telekom commented that the CR introducing the TEI rules was introduced first in TSG SA#82, again in TSG SA#83 and TSG RAN should have been fully aware of this well before it was finally approved by TSG SA. This was postponed.

e-mail discussion:

Saso (Intel) recommends approving the CR in SP-200657.
Johannes (Deutsche Telekom) comments on the missing⁄vague justification of the CR.
Hans (NEC) added several examples of how RAN is providing transparency.
Saso (Intel) comments.
Xiaobao (Orange ) asks for the clarification of 'an alternative process' and questions if the propose change should be applied to the description of TEI.
Hans (NEC) responded to the SA Chairman's point on desirability of common procedures between the TSGs, agreeing in principle, but indicating that this also requires a consensus across the TSGs in advance of introducing such procedures and that the mini-WID procedure had been introduced before such consensus could be achieved.
Andy (Samsung) comments.
Alessio(nokia) expresses concerns on approving the CR in SP-200657
Xiaobao (Orange ) asks for the clarification of 'an alternative process' and questions if the propose change should be applied to the description of TEI.

Status:

Postponed.

TD SP-200868 (LS IN) LS from TSG RAN: LS on Relaxation of mini-WID requirement for Cat.B⁄C TEI CRs. (Source:TSG RAN (RP-202001)).
Document for: Action.
Abstract: At TSG SA#83 plenary, TSG SA approved SP-190270 (CR 0057 to TR 21.900). This CR introduced a number of major changes in the way in which TEI is handled. Although TSG RAN and the RAN WGs appreciate the tighter handling of TEI in general that resulted from TSG SA's decision, one of the changes introduced by SP-190270, namely the strict requirement on creating mini-Work Items for Cat. B⁄C TEI CRs, does not align with the way in which TSG RAN and RAN WGs have decided to handle such TEI CRs. As a result, TSG RAN and RAN WGs have in practice not been following the newly introduced text in TR 21.900 with regard to Cat.B⁄C TEI CRs, and have no intention of using the mini-WIDs in future either. TSG RAN finally endorsed a draft CR to TR 21.900 in RP-201291 on this topic at RAN#88 plenary. This change aims at keeping the strict requirement for TSG SA and TSG CT, while at the same time allowing TSG RAN to follow TR 21.900 also. TSG RAN thanks TSG SA for its understanding in this matter and requests TSG SA to approve the attached CR. Action: TSG RAN requests TSG SA to approve the attached CR.

Comment:

Attached CR is the same change as in SP-200657. CC#4: This LS was postponed.

Discussion and conclusion:

CC#4: This LS was postponed.

e-mail discussion:

Saso (Intel) recommends approving the CR in SP-200657.
Johannes (Deutsche Telekom) comments on the missing⁄vague justification of the CR.
Hans (NEC) added several examples of how RAN is providing transparency.
Saso (Intel) comments.
Xiaobao (Orange ) asks for the clarification of 'an alternative process' and questions if the propose change should be applied to the description of TEI.
Hans (NEC) responded to the SA Chairman's point on desirability of common procedures between the TSGs, agreeing in principle, but indicating that this also requires a consensus across the TSGs in advance of introducing such procedures and that the mini-WID procedure had been introduced before such consensus could be achieved.
Andy (Samsung) comments.
Alessio(nokia) expresses concerns on approving the CR in SP-200657
Xiaobao (Orange ) asks for the clarification of 'an alternative process' and questions if the propose change should be applied to the description of TEI.

Status:

Postponed.

16.1 SA WG1 Rel-16 CRs

TD SP-200790 (CR PACK) Stage 1 CRs on eCAV. (Source:SA WG1).
Document for: Approval.
Abstract: 22.104 CR0055; 22.832 CR0029; 22.832 CR0030; 22.261 CR0465R1; 22.104 CR0053R1; 22.104 CR0058R1; 22.261 CR0462R2.

Comment:

CC#4: 22.261 CR0462R2 revised in SP-200869. 22.104 0053r1 and 22.261 0465r1 were postponed. The other CRs in this CR pack were approved.

Parallel:

CC#4: 22.261 CR0462R2 revised in SP-200869. 22.104 0053r1 and 22.261 0465r1 were related to the recommendations enumeration issue and were postponed. The other CRs in this CR pack were approved. (This CR pack was partially approved).

e-mail discussion:

The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1
LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed⁄corrected.
Haris (Qualcomm) comments that this CR pack relates to the discussion of enumeration of requirements in SP-200819 and wants to flag it up for discussion.

Status:

Partially approved.

TD SP-200869 (CR) 22.261 CR0462R3 (Rel-17, 'D'): Quality improvement of TS 22.261 (R17) – editorial modifications. (Source:Siemens).
Document for: Approval.
Abstract: Summary of change: Correction of editorial slips.

Comment:

Revision of 22.261 CR0462R2 from CR Pack SP-200790. CC#4: SP-200869_Rev3 was approved. Revised to SP-200889.

Discussion and conclusion:

CC#4: LG Electronics commented that some corrections were required and this should be revised accordingly. SP-200869_Rev3 was provided and LG electronics accepted this. SP-200869_Rev3 was then approved. (This will be revised into a new TSD number by MCC).

Status:

Revised to SP-200889.

TD SP-200889 (CR) 22.261 CR0462R4 (Rel-17, 'D'): Quality improvement of TS 22.261 (R17) – editorial modifications. (Source:Siemens).
Document for: Approval.
Abstract: Summary of change: Correction of editorial slips.

Comment:

Revision of SP-200869. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200784 (CR PACK) Stage 1 CRs on cyberCAV. (Source:SA WG1).
Document for: Approval.
Abstract: 22.261 CR0455R1; 22.261 CR0456R1; 22.261 CR0464R1; 22.104 CR0054R1.

Comment:

CC#3: 22.104 CR0054r1 and 22.261 CR0464 removed from the pack for further discussion (postponed). The other CRs in this CR Pack were approved. (This CR Pack was partially approved).

Discussion and conclusion:

CC#3: This was removed from block approval due to issues raised. 22.104 CR0054r1 and 22.261 CR0464 removed from the pack for further discussion (postponed). The other CRs in this CR Pack were approved. (This CR Pack was partially approved).

Status:

Partially approved.

TD SP-200791 (CR PACK) Stage 1 CRs on ID_UAS. (Source:SA WG1).
Document for: Approval.
Abstract: 22.125 CR0028R5.

Comment:

CC#3: SP-200791_Rev1 was approved. (To be revised by MCC to provide a new TD number). Revised to SP-200881.

Discussion and conclusion:

CC#3: SP-200791_Rev1 was provided. This was approved. (To be revised by MCC to provide a new TD number).

e-mail discussion:

The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1
LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed⁄corrected.

Status:

revised by MCC to provide a new TD number). Revised to SP-200881.

TD SP-200881 (CR) 22.125 CR0028R6 (Rel-17, 'F'): Stage 1 CRs on ID_UAS. (Source:SA WG1).
Document for: Approval.
Abstract: 22.125 CR0028R6.

Comment:

Revision of 22.125 CR0028R5 in SP-200791_Rev1. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200793 (CR PACK) Stage 1 CRs FS_FRMCS3. (Source:SA WG1).
Document for: Approval.
Abstract: 22.889 CR0169R2.

Comment:

CC#3: SP-200793_Rev1 was approved. (To be revised by MCC to provide a new TD number). Revised to SP-200882.

Discussion and conclusion:

CC#3: SP-200793_Rev1 was provided. This was approved. (To be revised by MCC to provide a new TD number).

e-mail discussion:

The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1
LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed⁄corrected.

Status:

revised by MCC to provide a new TD number). Revised to SP-200882.

TD SP-200882 (CR) 22.889 CR0169R3 (Rel-17, 'F'): Stage 1 CRs FS_FRMCS3. (Source:SA WG1).
Document for: Approval.
Abstract: 22.889 CR0169R3.

Comment:

Revision of 22.889 CR0169R2 in SP-200793_Rev1. Approved.

Discussion and conclusion:

-

Status:

Approved.

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200785 (CR PACK) Stage 1 CRs on REAR. (Source:SA WG1).
Document for: Approval.
Abstract: 22.011 CR0313R1; 22.115 CR0103R1; 22.261 CR0458R1; 22.268 CR0064R1; 22.119 CR0003R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200786 (CR PACK) Stage 1 CRs on MARCOM. (Source:SA WG1).
Document for: Approval.
Abstract: 22.119 CR0004R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

e-mail discussion:

Ki-Dong (LG Electronics) provides the following comments on 22119_CR0004r1 (of SP-200786):
(1) CR0003r1 has minor leftovers cause by the first round of revision, to correct: In the main text, some references are no longer existent, i.e., [36], [37].
(2) FYI - the 2nd requirement of clause 7.1.2 was agreed to be removed by anther CR (maintenance CR, 22119_CR0003r1, LGE). This collision doesn't seem to be a problem at all as long as the maintenance can override the other.

Status:

Approved.

TD SP-200787 (CR PACK) Stage 1 CRs on 5GSAT. (Source:SA WG1).
Document for: Approval.
Abstract: 22.261 CR0468.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200788 (CR PACK) Stage 1 CRs on UIA. (Source:SA WG1).
Document for: Approval.
Abstract: 22.101 CR0569; 22.115 CR0104.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200789 (CR PACK) Stage 1 CRs on TEI16. (Source:SA WG1).
Document for: Approval.
Abstract: 22.011 CR0311R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200792 (CR PACK) Stage 1 CRs on AVPROD. (Source:SA WG1).
Document for: Approval.
Abstract: 22.263 CR0010R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

e-mail discussion:

The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1
LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed⁄corrected.

Status:

Approved.

TD SP-200794 (CR PACK) Stage 1 CRs on TEI17. (Source:SA WG1).
Document for: Approval.
Abstract: 22.011 CR0315R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

e-mail discussion:

The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1
LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed⁄corrected.

Status:

Approved.

16.2 SA WG2 Rel-16 CRs

TD SP-200685 (CR PACK) CRs to 23.401, 23.502 on RACS (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2383R1; 23.502 CR2326R1; 23.401 CR3605R1.

Comment:

Company proposed revision of 23.501 CR2383R1 in SP-200802. CC#1: 23.501 CR2383R1 was considered as revised and other CRs in this CR pack were approved.

Discussion and conclusion:

CC#1: Company proposed revision of 23.501 CR2383R1 in SP-200802. 23.501 CR2383R1 was considered as revised and other CRs in this CR pack were approved. (This CR Pack was partially approved).

Status:

Partially approved.

TD SP-200802 (CR) 23.501 CR2383R2 (Rel-16, 'F'): Signalling of UE Radio Capability ID in Registration procedure. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Clarifies the signalling of UE Radio Capability ID in Registration procedures.

Comment:

Revision of S2-2006493 (23.501 CR2383R1) in CR Pack SP-200685. CC#1: Vodafone supported this CR. This CR was approved. This CR was agreed.

Discussion and conclusion:

CC#1: Vodafone supported this CR. This CR was approved.

Status:

Approved.

TD SP-200688 (CR PACK) CRs to 23.501, 23.502, 23.503 on Vertical_LAN (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.503 CR0475; 23.502 CR2382; 23.501 CR2435; 23.502 CR2390; 23.503 CR0488; 23.501 CR2449; 23.501 CR2437R1; 23.502 CR2388R1; 23.501 CR2438R1; 23.501 CR2439R1; 23.501 CR2440R1; 23.501 CR2392R1; 23.501 CR2393R1; 23.501 CR2394R1; 23.502 CR2338R1; 23.501 CR2396R1; 23.501 CR2446R1; 23.503 CR0477R1; 23.501 CR2398R1; 23.501 CR2403R1; 23.501 CR2404R1; 23.501 CR2405R1; 23.501 CR2410R1; 23.503 CR0484R1; 23.501 CR2421R1; 23.501 CR2448R1; 23.501 CR2451R1; 23.502 CR2396R1; 23.503 CR0482R1; 23.502 CR2357R1; 23.501 CR2430R1; 23.502 CR2386R1; 23.501 CR2455R1; 23.501 CR2266R2; 23.501 CR2395R3.

Comment:

CC#1: 23.501 CR2448R1 was reported needing further work and was postponed. All other CRs in this CR pack were approved.

Discussion and conclusion:

CC#1: 23.501 CR2448R1 was reported needing further work and was postponed. All other CRs in this CR pack were approved. (This CR Pack was partially approved).

e-mail discussion:

Haris (Qualcomm) objects to 23501 CR2448r1 (S2-2005899) from this CR pack.

Status:

Partially approved.

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200673 (CR PACK) CRs to 23.501, 23.502, 23.503 on 5G_CIoT (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2340; 23.501 CR2424; 23.502 CR2370; 23.501 CR2425; 23.501 CR2426; 23.501 CR2428; 23.502 CR2371R1; 23.501 CR2427R1; 23.502 CR2372R1; 23.502 CR2373R1; 23.503 CR0489R1; 23.502 CR2398R1; 23.501 CR2443R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200674 (CR PACK) CRs to 23.501, 23.502 on 5G_eSBA (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2409R1; 23.502 CR2349R1; 23.501 CR2431R1; 23.501 CR2444R1; 23.502 CR2389R1; 23.501 CR2447R1; 23.502 CR2394R1; 23.502 CR2395R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200675 (CR PACK) CR to 23.501 on 5G_URLLC (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2387.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200676 (CR PACK) CRs to 23.316, 23.502 on 5WWC (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.316 CR2046R1; 23.316 CR2048; 23.502 CR2364; 23.502 CR2374; 23.502 CR2375R1; 23.502 CR2376R1; 23.316 CR2049R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200677 (CR PACK) CR to 23.501 on ATSSS (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2453.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200678 (CR PACK) CRs to 23.228, 23.501 on eIMS5G_SBA (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.228 CR1235; 23.228 CR1234R1; 23.501 CR2391R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200679 (CR PACK) CRs to 23.228, 23.502, 23.503 on eNA (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.288 CR0178; 23.288 CR0179; 23.502 CR2393; 23.288 CR0181R2; 23.502 CR2346R1; 23.288 CR0182R1; 23.288 CR0184R1; 23.288 CR0177R1; 23.503 CR0479R1; 23.503 CR0480R1; 23.502 CR2342R1; 23.288 CR0183R1; 23.288 CR0186R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200680 (CR PACK) CRs to 23.502 on eNS (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2328; 23.502 CR2331; 23.502 CR2333R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200681 (CR PACK) CRs to 23.502 on ETSUN (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2362; 23.502 CR2361R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200682 (CR PACK) CRs to 23.285, 23.287, 23.502, 23.503 on eV2XARC (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2334; 23.287 CR0141; 23.502 CR2356; 23.285 CR0063R2; 23.503 CR0478R1; 23.287 CR0144R1; 23.287 CR0145R1; 23.287 CR0146R1; 23.287 CR0147R1; 23.503 CR0486R1; 23.287 CR0148R1; 23.287 CR0151R1; 23.287 CR0149R1; 23.287 CR0150R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200683 (CR PACK) CR to 23.501 on IABARC (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2452R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200684 (CR PACK) CR to 23.401 on PARLOS (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.401 CR3610.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200686 (CR PACK) CRs to 23.214, 23.501, 23.502, 23.682 on TEI16 (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2341; 23.502 CR2345; 23.682 CR0471; 23.502 CR2367; 23.401 CR3611R1; 23.501 CR2400R1; 23.502 CR2330R1; 23.501 CR2442R1; 23.501 CR2407R1; 23.214 CR0075R1; 23.502 CR2392R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200687 (CR PACK) CR to 23.501 on UDICOM (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2390.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200689 (CR PACK) CR to 23.502 on xBDT (Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2344R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

16.3 SA WG3 and SA WG3 LI Rel-16 CRs

TD SP-200706 (CR PACK) Rel-16 CRs on Security for enhancements to the Service Based 5G System Architecture. (Source:SA WG3).
Document for: Approval.
Abstract: 33.536 CR0006R1; 33.501 CR0880R1; 33.501 CR0900R1; 33.501 CR0904R1; 33.501 CR0903R1; 33.501 CR0908R1; 33.501 CR0905R2.

Comment:

33.501 CR0908R1 should be a CR to 33.310, so should be rejected. Replacement CR to 33.310 provided in SP-200857. 33.501 CR0908R1 was rejected. Al other CRs in this CR Pack were approved.

Discussion and conclusion:

CC#3: 33.501 CR0908R1 was rejected. Al other CRs in this CR Pack were approved. (The CR Pack was partially approved).

e-mail discussion:

CR 00908 33501 in CR pack SP-200706 belongs to the wrong specification and hence it should be removed from the pack.

Status:

Partially approved.

TD SP-200857 (CR) 33.310 CR0112 (Rel-16, 'F'): Making NF instance id in SBA certificate profile mandatory to support. (Source:Nokia).
Document for: Approval.
Abstract: Summary of change: Text modified in the clause 6.1.3c.3 and removal of editor's note to allow full functioning of CCA concept. R1 - delete shall⁄should and use non-normative wording for referencing to names Clarification for 'should' make it conditional: If token-based authorization is used, subjectAltName shall contain URI for the NF Instance ID as an URN. If CCA is used, subjectAltName shall contain URI for the NF Instance ID as an URN. R2 - only keep shall⁄should changes in this CR.

Comment:

Incorrect TS was specified in the SA WG3 TD request. New CR allocated at TSG SA#89-e. CC#3: This CR was approved.

Discussion and conclusion:

CC#3: This CR was approved.

Status:

Approved.

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200701 (CR PACK) Rel-16 CRs on TEI. (Source:SA WG3).
Document for: Approval.
Abstract: 33.220 CR0203R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200703 (CR PACK) Rel-16 CRs on Security Assurance Specification for 5G. (Source:SA WG3).
Document for: Approval.
Abstract: 33.511 CR0015; 33.514 CR0003R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200705 (CR PACK) Rel-16 CRs on Security Aspects of eV2XARC. (Source:SA WG3).
Document for: Approval.
Abstract: 33.536 CR0001; 33.536 CR0002; 33.536 CR0014R1; 33.536 CR0007R1; 33.536 CR0009R1; 33.536 CR0010R1; 33.536 CR0011R1; 33.536 CR0013R1.

Comment:

CC#1: 33.536 CR0002 was reported needing further work and was postponed. All other CRs in this CR pack were approved.

Discussion and conclusion:

CC#1: 33.536 CR0002 was reported needing further work and was postponed. All other CRs in this CR pack were approved. (This CR Pack was partially approved).

e-mail discussion:

CR 33.536 0002 S3-201609 should have been revised to include the changes agreed during the SA3 meeting. The version included in this pack is not the one agreed by the group and hence must be withdrawn.

Status:

Partially approved.

TD SP-200707 (CR PACK) Rel-16 CRs on Security for IAB. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0937R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200708 (CR PACK) Rel-16 CRs on Authentication and key management for applications based on 3GPP credential in 5G. (Source:SA WG3).
Document for: Approval.
Abstract: 33.535 CR0020; 33.535 CR0027; 33.535 CR0026R1; 33.535 CR0023R1; 33.535 CR0024R1; 33.535 CR0025R1; 33.535 CR0009R1; 33.535 CR0013R1; 33.535 CR0001R1; 33.535 CR0032R1; 33.535 CR0034R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200710 (CR PACK) Rel-16 CRs on User Plane Gateway Function for Inter-PLMN Security. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0882.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200715 (CR PACK) Rel-16 CRs on Security aspects of SEAL. (Source:SA WG3).
Document for: Approval.
Abstract: 33.434 CR0002R1; 33.434 CR0001R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200716 (CR PACK) Rel-16 CRs on Security aspects of Enhanced Network Slicing. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0913R1; 33.501 CR0909R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200807 (CR PACK) Rel-16 CRs on Lawful Interception. (Source:SA WG3-LI).
Document for: Approval.
Abstract: 33.127 CR0076; 33.128 CR0095; 33.128 CR0092R1; 33.128 CR0093R1; 33.128 CR0090R1; 33.127 CR0078R1; 33.127 CR0079R1; 33.128 CR0091R1; 33.128 CR0098R1; 33.128 CR0088R2; 33.128 CR0101R1; 33.128 CR0102R1; 33.128 CR0103R1; 33.128 CR0104R1; 33.128 CR0105R1; 33.128 CR0106R1; 33.128 CR0094R5; 33.128 CR0110R1; 33.128 CR0111R1; 33.128 CR0112R1; 33.127 CR0086R1; 33.128 CR0117; 33.127 CR0088R1; 33.127 CR0089R1; 33.127 CR0090R1; 33.127 CR0091R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

16.4 SA WG4 Rel-16 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200659 (CR PACK) CRs to TS 26.116. (Source:SA WG4).
Document for: Approval.
Abstract: 26.116 CR0014R2.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200660 (CR PACK) CRs to TS 26.223. (Source:SA WG4).
Document for: Approval.
Abstract: 26.223 CR0014.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200661 (CR PACK) CRs to TS 26.234. (Source:SA WG4).
Document for: Approval.
Abstract: 26.234 CR0231.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200662 (CR PACK) CRs to TS 26.238. (Source:SA WG4).
Document for: Approval.
Abstract: 26.238 CR0025R2.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200663 (CR PACK) CRs to TS 26.501. (Source:SA WG4).
Document for: Approval.
Abstract: 26.501 CR0019.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200664 (CR PACK) CRs to TS 26.511. (Source:SA WG4).
Document for: Approval.
Abstract: 26.511 CR0001R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200665 (CR PACK) CRs to TS 26.114. (Source:SA WG4).
Document for: Approval.
Abstract: 26.114 CR0502; 26.114 CR0503R1; 26.114 CR0504.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200668 (CR PACK) CR to 26.247. (Source:SA WG4).
Document for: Approval.
Abstract: 26.247 CR0167R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200804 (CR PACK) CRs to RM_H263_MP4V (postponed from SA#88-e). (Source:SA WG4).
Document for: Approval.
Abstract: 26.114 CR0501; 26.140 CR0020; 26.244 CR0065; 26.346 CR0634.

Convenor comment:

Block 5.

Comment:

These CRs were postponed from SA#88-e. This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

16.5 SA WG5 Rel-16 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200723 (CR PACK) Rel-16 CRs on Streaming trace reporting. (Source:SA WG5).
Document for: Approval.
Abstract: 28.532 CR0139; 32.423 CR0116; 32.422 CR0343.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200724 (CR PACK) Rel-16 CRs on TEI. (Source:SA WG5).
Document for: Approval.
Abstract: 28.532 CR0137; 28.550 CR0061; 28.541 CR0339; 28.623 CR0103; 28.623 CR0104; 28.532 CR0143; 28.532 CR0144; 28.541 CR0369; 28.531 CR0057; 28.530 CR0028R1; 28.533 CR0072R1; 28.545 CR0007R1; 28.541 CR0368R1; 28.530 CR0029R1; 28.531 CR0053R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200729 (CR PACK) Rel-16 CRs on NRM enhancements. (Source:SA WG5).
Document for: Approval.
Abstract: 28.623 CR0095; 28.541 CR0321; 28.623 CR0102; 28.541 CR0323; 28.541 CR0331; 28.541 CR0332; 28.541 CR0333; 28.541 CR0345; 28.541 CR0370R1; 28.541 CR0329R1; 28.541 CR0336R1; 28.622 CR0088R1; 28.623 CR0106; 28.622 CR0087R1; 28.623 CR0105R1; 28.623 CR0107; 28.541 CR0366R1; 28.541 CR0322R1; 28.541 CR0330R2; 28.541 CR0334R1; 28.541 CR0335R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200732 (CR PACK) Rel-16 CRs on Self-Organizing Networks (SON) for 5G networks. (Source:SA WG5).
Document for: Approval.
Abstract: 28.552 CR0262R2.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200733 (CR PACK) Rel-16 CRs on Charging Access of ATSSS. (Source:SA WG5).
Document for: Approval.
Abstract: 32.255 CR0238; 32.291 CR0248R1; 32.298 CR0819R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200734 (CR PACK) Rel-16 CRs on Energy efficiency of 5G. (Source:SA WG5).
Document for: Approval.
Abstract: 28.310 CR0002.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200737 (CR PACK) Rel-16 CRs on Integration of ONAP and 3GPP 5G management framework. (Source:SA WG5).
Document for: Approval.
Abstract: 28.532 CR0147; 28.532 CR0138R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200738 (CR PACK) Rel-16 CRs on Enhancement of performance assurance for 5G networks including network slicing batch 1. (Source:SA WG5).
Document for: Approval.
Abstract: 28.550 CR0059; 28.532 CR0135; 28.532 CR0136; 28.554 CR0056; 28.552 CR0251R1; 28.552 CR0252R1; 28.552 CR0253R1; 28.552 CR0254R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200740 (CR PACK) Rel-16 CRs on Charging Enhancement of 5GC interworking with EPC. (Source:SA WG5).
Document for: Approval.
Abstract: 32.291 CR0267; 32.298 CR0828; 32.255 CR0236R1; 32.255 CR0237R1; 32.291 CR0245R1; 32.255 CR0243R1; 32.255 CR0242R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200741 (CR PACK) Rel-16 CRs on CHF-controlled quota management. (Source:SA WG5).
Document for: Approval.
Abstract: 32.290 CR0128R1; 32.291 CR0256R1; 32.298 CR0823R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200743 (CR PACK) Rel-16 CRs on Network Slice Performance and Analytics Charging in 5G System. (Source:SA WG5).
Document for: Approval.
Abstract: 32.298 CR0825R1; 32.291 CR0261R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200744 (CR PACK) Rel-16 CRs on Management of MDT in 5G. (Source:SA WG5).
Document for: Approval.
Abstract: 32.422 CR0344; 32.422 CR0346.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200745 (CR PACK) Rel-16 CRs on Network Slice Management Charging in 5G System. (Source:SA WG5).
Document for: Approval.
Abstract: 32.297 CR0038; 32.291 CR0249R1; 32.298 CR0820R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200750 (CR PACK) Rel-16 CRs on Closed loop SLS Assurance. (Source:SA WG5).
Document for: Approval.
Abstract: 28.535 CR0008; 28.535 CR0009; 28.535 CR0010; 28.536 CR0003; 28.536 CR0004; 28.536 CR0005; 28.536 CR0006; 28.536 CR0007.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200751 (CR PACK) Rel-16 CRs on KPI reporting. (Source:SA WG5).
Document for: Approval.
Abstract: 28.552 CR0265; 28.554 CR0055R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200753 (CR PACK) Rel-16 CRs on Trace Management in the context of Services Based Management Architecture. (Source:SA WG5).
Document for: Approval.
Abstract: 32.422 CR0336R1; 32.422 CR0337R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200754 (CR PACK) Rel-16 CRs on Management Aspects of 5G Service-Level Agreement. (Source:SA WG5).
Document for: Approval.
Abstract: 28.536 CR0001R1; 28.541 CR0338R1; 28.541 CR0371R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200813 (CR PACK) REl-16 CRs on TEI batch 2. (Source:SA WG5).
Document for: Approval.
Abstract: 32.274 CR0076; 32.291 CR0246; 32.291 CR0251; 32.291 CR0254; 28.628 CR0018; 32.298 CR0827; 32.158 CR0015R1; 32.291 CR0247R1; 32.255 CR0239R1; 32.291 CR0252R1; 32.298 CR0821R1; 32.291 CR0263R1; 32.255 CR0246R1; 32.255 CR0247R1; 32.290 CR0130R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200816 (CR PACK) Rel-16 CRs on Charging Aspects for 5WWC. (Source:SA WG5).
Document for: Approval.
Abstract: 32.255 CR0245R1; 32.298 CR0826R2.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200817 (CR PACK) REl-16 CRs on Nchf Online and Offline charging services. (Source:SA WG5).
Document for: Approval.
Abstract: 32.291 CR0262R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

16.6 SA WG6 Rel-16 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200838 (CR PACK) Rel-16 CRs to TS 23.283 for eMCCI. (Source:SA WG6).
Document for: Approval.
Abstract: 23.283 CR0053R1; 23.283 CR0054R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200839 (CR PACK) Rel-16 CRs to TS 23.282 for eMCData2. (Source:SA WG6).
Document for: Approval.
Abstract: 23.282 CR0235; 23.282 CR0227R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200840 (CR PACK) Rel-16 CRs to TS 23.222 for eCAPIF. (Source:SA WG6).
Document for: Approval.
Abstract: 23.222 CR0076R3; 23.222 CR0077R3.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200841 (CR PACK) Rel-16 CRs to TS 23.434 for SEAL. (Source:SA WG6).
Document for: Approval.
Abstract: 23.434 CR0024R1; 23.434 CR0023R2; 23.434 CR0026R1; 23.434 CR0025R2.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200842 (CR PACK) Rel-16 CRs to TS 23.286 for V2XAPP. (Source:SA WG6).
Document for: Approval.
Abstract: 23.286 CR0019; 23.286 CR0020R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

17 Rel-17 CRs (block approval if not otherwise requested)

17.1 SA WG1 Rel-17 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

17.2 SA WG2 Rel-17 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

17.3 SA WG3 and SA WG3 LI Rel-17 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

17.4 SA WG4 Rel-17 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

17.5 SA WG5 Rel-17 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200746 (CR PACK) Rel-17 CRs on Management of MDT enhancement in 5G. (Source:SA WG5).
Document for: Approval.
Abstract: 32.422 CR0335; 32.421 CR0096.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200747 (CR PACK) Rel-17 CRs on Enhancements of 5G performance measurements and KPIs. (Source:SA WG5).
Document for: Approval.
Abstract: 28.552 CR0249; 28.552 CR0250; 28.552 CR0260; 28.552 CR0255R1; 28.552 CR0257R1; 28.552 CR0258R1; 28.552 CR0259R1; 28.552 CR0261R1; 28.552 CR0263R1; 28.552 CR0264R1; 28.552 CR0243R1; 28.552 CR0244R1; 28.552 CR0245R1; 28.552 CR0256R1; 28.554 CR0057R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200748 (CR PACK) Rel-17 CRs on Additional NRM features. (Source:SA WG5).
Document for: Approval.
Abstract: 28.540 CR0011.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200749 (CR PACK) Rel-17 CRs on Enhancement on Management Aspects of 5G Service-Level Agreement. (Source:SA WG5).
Document for: Approval.
Abstract: 28.541 CR0342; 28.541 CR0362; 28.541 CR0341R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200752 (CR PACK) Rel-17 CRs on Enhancements of Self-Organizing Networks (SON) for 5G networks. (Source:SA WG5).
Document for: Approval.
Abstract: 28.541 CR0337R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

17.6 SA WG6 Rel-17 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200843 (CR PACK) Rel-17 CRs to TS 23.280, TS 23.281, TS 23.282 and TS 23.379 for eMONASTERY2. (Source:SA WG6).
Document for: Approval.
Abstract: 23.379 CR0261R1; 23.281 CR0145R1; 23.379 CR0265R1; 23.281 CR0147R1; 23.282 CR0226R1; 23.379 CR0262R1; 23.379 CR0263R1; 23.379 CR0269R1; 23.280 CR0273; 23.379 CR0278R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200844 (CR PACK) Rel-17 CRs to TS 23.280 and TS 23.379 for enh3MCPTT. (Source:SA WG6).
Document for: Approval.
Abstract: 23.280 CR0261R1; 23.379 CR0260R3; 23.280 CR0267; 23.280 CR0269R1; 23.280 CR0270R1; 23.379 CR0270R1; 23.379 CR0271R1; 23.379 CR0276R1; 23.280 CR0258R5.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200845 (CR PACK) Rel-17 CRs to TS 23.282 for eMCData3. (Source:SA WG6).
Document for: Approval.
Abstract: 23.282 CR0228R1; 23.282 CR0229R1; 23.282 CR0230R1; 23.282 CR0231R1; 23.282 CR0232R1; 23.282 CR0233R1; 23.282 CR0234R1; 23.282 CR0240; 23.282 CR0236R1; 23.282 CR0237R1; 23.282 CR0238R1; 23.282 CR0239R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200846 (CR PACK) Rel-17 CRs to TS 23.281 and TS 23.283 for TEI17. (Source:SA WG6).
Document for: Approval.
Abstract: 23.281 CR0146R1; 23.283 CR0055R1; 23.281 CR0148R1; 23.281 CR0149R1; 23.281 CR0150R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200847 (CR PACK) Rel-17 CR to TR 23.744 for FS_enhMCLoc. (Source:SA WG6).
Document for: Approval.
Abstract: 23.744 CR0001R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

18 Rel-18 CRs

(block approval if not otherwise requested)

18.1 SA WG1 Rel-18 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200818 (CR PACK) Stage 1 CRs on SNA. (Source:SA WG1).
Document for: Approval.
Abstract: 22.261 CR0472R1.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

18.2 SA WG2 Rel-18 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

18.3 SA WG3 and SA WG3 LI Rel-18 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

18.4 SA WG4 Rel-18 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

18.5 SA WG5 Rel-18 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

18.6 SA WG6 Rel-18 CRs

Block 5: For Block Approval - Thursday 15:00 UTC

19 CRs related to Study Items

(Block approval if not otherwise requested)

Block 5: For Block Approval - Thursday 15:00 UTC

TD SP-200711 (CR PACK) Rel-16 CRs for Study on Security Aspects of 3GPP support for Advanced V2X Services. (Source:SA WG3).
Document for: Approval.
Abstract: 33.836 CR0001.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200712 (CR PACK) Rel-16 CRs onStudy on Security Aspects of the 5G Service Based Architecture. (Source:SA WG3).
Document for: Approval.
Abstract: 33.855 CR0001.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

TD SP-200713 (CR PACK) Rel-16 CRs on Study on evolution of Cellular IoT security for the 5G System. (Source:SA WG3).
Document for: Approval.
Abstract: 33.861 CR0001; 33.861 CR0002; 33.861 CR0003.

Convenor comment:

Block 5.

Comment:

This was Block approved in CC#3.

Discussion and conclusion:

-

Status:

Approved.

20 Project Management & TSG SA owned specifications

20.1 Review of the work plan

TD SP-200850 (DISCUSSION) A Feature is like a worm: don't cut it. (Source:3GPP Work Plan Coordinator).
Document for: Agreement.
Abstract: Presentation of the problem: At TSG#89e, several WIDs are proposed for Release 17 for some essential aspects of a Feature when other essential aspects of the same Feature have been defined in an earlier Release. This paper is to remind that this is not a suitable approach.

Comment:

CC#3: Postponed.

Discussion and conclusion:

CC#2: The message of this was 'keep all WIDs for a feature in the same Release'. The TSG SA Chairman raised concerns that there may be cases where stage 2 is completed but stage 3 is then not ready and the whole Feature moves to the next Release, which would be counter-productive. The current process protects from unintentional splitting of work in the Work Plan. The Work Plan manager clarified that normal practice has been to keep all parts of feature in the same Release and they have not been split before. The SA WG6 Chairman suggested also tying this discussion with how Release Summaries are done for Features. CMCC agreed with the spirit of this paper and suggested that each non-conformance issue is determined on a case by case basis. The SA WG1 Chairman commented that the normal procedure is to trim the SA WG1 requirements to reflect the final content of the Release. The TSG SA Chairman commented that extracting Features at the stage 2 level is more complicated. The SA WG3 Chairman reported a case for ACMA where a Stage 2 change had needed Stage 3 work which had not been done in Rel-16. The TSG SA Chairman commented that is such a shift of a Feature from a Release is being considered, then this needs to be brought to the attention of all relevant groups and not done purely by MCC. This should be further discussed over e-mail.
CC#3: The latest revision SP-200850_Rev2 was presented. The SA WG6 Chairman commented that these proposals should be taken into account as far as possible with respect to determining when a feature is fully complete and there are no missing components which may be discovered later. This should be handled using the current rules of decision by company input contributions and consensus. Telefonica commented that this would need further consideration and that there are places where the wording can be significantly clarified. The TSG CT Chairman commented that this has resulted in a better understanding of the 3GPP procedures and could benefit from further clarification. This was then postponed.

e-mail discussion:

SA Chair disagrees with the paper, as it holds implications which might work negatively in progressing the work of 3GPP. The proposal from the SA Chair is to investigate features, which are only partially complete, on a case-by-case basis. This can be done as only very few such features appear in the end of the release.
Johannes (Deutsche Telekom) raises the point that SA1 is performing in each release a clean-up of requirements, which did not conclude in stage2 and stage3, e.g. just refer to documents SP-200785 (REAR), SP-200788 (UIA) and SP-200787 (5GSAT). DT concurs with the assessment of the conclusion in SP-200850 to have a full operational system per Release. So the general aim of 3GPP should be to have self-contained releases with functionable features. Exception sheets are sommonly used to conclude past the freeze date.
MCC clarifies that SP-200850 is not meant to open a debate but to remind delegates of a 3GPP basic principle: see 3GPP Working Procedures TR 21.900 sections 4.0B and 4. The principle of not cutting a Feature onto different Releases has been emphasized on several occasions, e.g. in SP-120387 (co-signed by the former SA1 and SA chairs), and it is the usual way of working in SA1, where the (elements of the) Stage 1 of the Features not completed in time for a given Release are removed from the documentation of this Release (see SP-200785, SP-200788 or SP-200789 just for TSG#89e), while retained in the documentation of the next Release.
Whatever the approach, it has to be consistent across all 3GPP WGs and TSGs. If this approach is not valid anymore, the Work Procedures should be amended.
Telefonica strongly disagrees with this paper. It goes against the independency of the work already developed in previous stages and it gives higher decision powers to the working groups (and therefore the companies) working on later stages
The SA5 chair supports the objection (on the contribution's original contents) and comments from the SA chair and SA3-LI chair.
Orange stated the Workplan and the Release roadmap is based on the principle that stage 1, stage 2 and stage 3 for a given feature are completed at the release date freeze. We can agree decide to allow exception to complete the work but it also assumed that features will be shift to the next release if not possible to complete in a given time. As long as 3GPP will rely on the notion of 'Release', the principles given in SP-200850 should be used as guidance, even if it is always possible to agree on a specific handling for a given feature.
The SA2 chair supports the objections and disagrees with the conclusions of the paper.
SA6 Chair (Suresh) agrees with points made by Georg (SA Chair) and Lionel (CT Chair), but prefers to defer any guidance to SA#90-e and continue this discussion offline with interested parties.
Telefonica still disagrees with v1 since it does not solve the issues pointed out by our previous comment
Upon providing SP-200850rev2, the MCC Work Plan manager (Alain) clarified that this document is not meant to modify anything in the 3GPP Working Procedures. On the contrary: it is meant to remind to all delegates the current, long-standing, 3GPP principles and check how they can be followed even better than now.
This document can be further improved, as e.g. to include the CT Chair's comments.

Status:

Postponed.

TD SP-200823 (WORK PLAN) Work Plan review at TSG#89. (Source:Work Plan Coordinator (MCC)).
Document for: Presentation.
Abstract: Work Plan review at TSG#89.

Comment:

CC#4: SP-200823_Rev2 was provided to take comments into account. Noted.

Discussion and conclusion:

CC#4: SP-200823_Rev1 was presented by the MCC Work Plan Manager. General: E-FLUS is 100% complete. Slide 10: Not all normative WIDs need to be produced, by December, but only SA WG2 WIDs. Slide 3-4: AT&T asked to also show TSG SA and TSG CT represented in the time-line as this could give the impression outside 3GPP that only RAN are concerned with the time schedule. The MCC Work Plan manager was asked to show this as an overall 3GPP schedule for clarity both inside and outside 3GPP. SP-200823_Rev2 was provided to take comments into account. The MCC Work Plan Manager was thanked for this presentation, which was noted.

Status:

Noted.

Block 6: For Block Endorsement - Thursday 15:00 UTC

20.2 Specification Status

Block 6: For Block Endorsement - Thursday 15:00 UTC

20.3 Work Item Summaries for TR 21.91x

(To be block approved)

Block 6: For Block Endorsement - Thursday 15:00 UTC

TD SP-200776 (WI SUMMARY) Work Item Summary for 5G_eSBA. (Source:China Mobile).
Document for: Endorsement.
Abstract: Provide eSBA work item summary to be included in TR 21.916.

Convenor comment:

Block 6.

Comment:

This was Block endorsed in CC#3.

Discussion and conclusion:

-

Status:

Endorsed.

TD SP-200777 (WI SUMMARY) Work Item Summary for Rel-16 UDICOM. (Source:Nokia Korea).
Document for: Endorsement.
Abstract: Work Item Summary for Rel-16 UDICOM.

Convenor comment:

Block 6.

Comment:

This was Block endorsed in CC#3.

Discussion and conclusion:

-

Status:

Endorsed.

TD SP-200801 (WI SUMMARY) Summary for Work Item on 'Removal of H.263 and MPEG-4 Visual from 3GPP Services'. (Source:Qualcomm Incorporated).
Document for: Endorsement.
Abstract: WI summary for RM_H263_MP4V.

Convenor comment:

Block 6.

Comment:

This was Block endorsed in CC#3.

Discussion and conclusion:

-

Status:

Endorsed.

TD SP-200808 (WI SUMMARY) Work Item Summary for Rel-16 eIMS5G_SBA. (Source:T-Mobile USA Inc.).
Document for: Endorsement.
Abstract: Work Item Summary for Rel-16 eIMS5G_SBA including SA WG2 and CT WGs works proposed to be included in TR 21.916.

Convenor comment:

Block 6.

Comment:

This was Block endorsed in CC#3.

Discussion and conclusion:

-

Status:

Endorsed.

TD SP-200848 (WI SUMMARY) Work item Summary for 5GMS3. (Source:Sony (Rapporteur)).
Document for: Endorsement.
Abstract: Work item Summary for 5GMS3.

Convenor comment:

Block 6.

Comment:

This was Block endorsed in CC#3.

Discussion and conclusion:

-

Status:

Endorsed.

TD SP-200849 (WI SUMMARY) Work item Summary for Enhancement of performance assurance for 5G. (Source:Intel (Rapporteur)).
Document for: Endorsement.
Abstract: Work item Summary for 5G_SLICE_ePA.

Convenor comment:

Block 6.

Comment:

This was Block endorsed in CC#3.

Discussion and conclusion:

-

Status:

Endorsed.

TD SP-200851 (WI SUMMARY) Work Item Summary for Rel-16 eCAPIF. (Source:Samsung).
Document for: Endorsement.
Abstract: Work Item Summary for Rel-16 CAPIF including SA WG6 and CT WGs works proposed to be included in TR 21.916.

Convenor comment:

Block 6.

Comment:

This was Block endorsed in CC#3.

Discussion and conclusion:

-

Status:

Endorsed.

TD SP-200852 (WI SUMMARY) Work Item Summary for Rel-16 SEAL. (Source:Samsung).
Document for: Endorsement.
Abstract: Work Item Summary for Rel-16 SEAL including SA WG6 and CT WGs works proposed to be included in TR 21.916.

Convenor comment:

Block 6.

Comment:

This was Block endorsed in CC#3.

Discussion and conclusion:

-

Status:

Endorsed.

TD SP-200824 (DRAFT TR) TR 21.916 v.0.6.0 on Rel-16 Summary. (Source:Work Plan Coordinator (MCC)).
Document for: Information.
Abstract: Abstract of document: TR 21.916 summarises all the Release 16 Features and other significant Work Items. This version includes all the inputs received up to a few days before TSG#89e and identifies all the inputs received at TSG#89e (which will be included shortly after TSG#89e). A vast majority of the summaries have been provided. The ones that seem to be still missing are: 800006 LAN support in 5G 5GLAN S1 SP-180593 KPN 840074 Application layer support for V2X services V2XAPP S6 SP-180898 Huawei Tel.India 800049 Stage 1 of 5G_HYPOS 5G_HYPOS S1 SP-180329 ESA 810004 MCData File Distribution support over xMB MC_XMB S4 SP-180665 Expway 800019 Enhanced Mission Critical System Migration and Interconnection eMCSMI S6 SP-180379 Motorola Solutions 800021 Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems eMCCI S6 SP-180680 Harris Corporation 800016 Stage 3 for MC Communication Interworking with Land Mobile Radio Systems MCCI_CT C1 CP-190203 Harris Corporation 820040 Mission Critical system migration and interconnection MCSMI_CT C1 CP-190143 Motorola Solutions 800032 Mission Critical Services Security Enhancements MCXSec S3 SP-180596 Motorola Solutions, Inc 800053 MBMS APIs for Mission Critical Services MBMSAPI_MCS S6 SP-180380 TD Tech Ltd. 760054 Mobile Communication System for Railways 2 MONASTERY2 SP-170451 Nokia 800008 Enhancement of LTE for Efficient delivery of Streaming Service eLSTR S1 SP-180322 China Telecom 800001 Enhancements to Framework for Live Uplink Streaming E_FLUS S4 SP-180285 Qualcomm 820002 Media streaming architecture 5GMSA S4 SP-180984 S4 Chair 810044 Multi-device and multi-identity MuD S1 SP-180315 Ericsson It is now becoming urgent for the contributors to either clarify the situation (e.g. Summary not needed, Summary already sent but missed, etc.) or to send their input, as to be able to complete this document by December 2020. The inputs should be sent by e-mail as soon as possible to the rapporteur of TR 21.916 (Alain dot Sultan at etsi dot org), Title 'WI summary for TR 21.916', and should be submitted as 'WI summary' to TSG#90e. Outstanding Issues: Complete the TR. Contentious Issues: None.

Convenor comment:

Block 6.

Comment:

This was Block noted in CC#3.

Discussion and conclusion:

CC#4: This had been noted at CC#3. The MCC Work Plan Manager thanked rapporteurs for the current input received and asked any outstanding ones to be provided with a view to finalising the TR at the next meeting if possible.

Status:

Noted.

TD SP-200872 (WI SUMMARY) Work Item Summary for QOED. (Source:Ericsson).
Document for: Endorsement.
Abstract: Work Item Summary for Rel-16 QOED.

Comment:

Late submission. CC#4: This WI Summary was endorsed.

Discussion and conclusion:

CC#4: This WI Summary was endorsed.

Status:

Endorsed.

20.4 Improvements to working methods & CRs against 3GPP TSG SA owned Specifications

20.5 MCC Status Report

TD SP-200803 (REPORT) Support Team report. (Source:MCC).
Document for: Information.
Abstract: MCC Director's report of MCC-related activities.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: This was presented by the MCC Director, Issam Toufik. It was announced that the outgoing MCC Director, John Meredith, will retire from 3GPP at the end of September 2020 and the replacement MCC Director, Issam Toufik will take over full-time. John was thanked for his outstanding and dedicated support to the 3GPP project and overview of MCC and the 3GPP procedures. The TSG SA Chairman, on behalf of TSG SA and the 3GPP project, thanked John for his excellent support and help and hoped to see him again in a future meeting in order to hold a formal farewell party. The MCC Director was thanked for this presentation, which was noted.

Status:

Noted.

20.6 Future Meeting schedule

21 Any Other Business

22 Close of Meeting

Step 1: Latest 16:00 UTC on Friday 18 September 2020 Step 2: RAN/CT reporting on Monday 21 September 2020