SP Meeting #SP-87E DRAFT REPORT

17 - 20 March 2020, - Electronic meeting

Source: Secretary of SP

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

Document for: Information

Status: This Report Generated 23-03-2020, 17:57

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.

1 Opening of the Meeting by e-mail

1.3 IPR & Antitrust reminders

1.4 Approval of Agenda

TD SP-200001 (AGENDA) Agenda for TSG SA meeting #87E. (Source:TSG SA Chairman).
Document for: Approval.
Abstract: Draft agenda for TSG SA meeting #87E.

Comment:

Proposed action: Approved at start of meeting. Approved.

Discussion and conclusion:

Status:

Approved.

2 Liaisons Statements

2.1 Incoming LSs - proposed to note

TD SP-200003 (LS IN) LS from TSG RAN: LS on Local NR positioning in NG-RAN. (Source:TSG RAN ()).
Document for: Information.
Abstract: RAN WG3 has studied the feasibility and specification impact of local LMF (i.e., LMC) in NG-RAN as per the SA WG2 conclusion from the study (Study on Enhancement to the 5GC Location Services, TR 23.731), as well as the RAN WG2 conclusion (Study on NR Positioning Support, TR 38.855). RAN WG3 also concluded as below (see TR 38.856 for more details). RAN WG3 has studied the feasibility and specification impact of local LMF (i.e., LMC) in NG-RAN. Three architecture alternatives have been studied. It is concluded that support of LMC in NG-RAN is feasible Architecture 3 seems like the most promising option among the ones studied. RAN WG3 did not evaluate the benefits of any of the architecture options in terms of latency towards the core network, RAN WG3 also did not fully evaluate, e.g., mobility issues associated with the introduction of the LMC. RAN WG3 could not reach consensus on any recommendation for normative work. RAN discussed LMC, but has not reached consensus on any follow-on work. Questions were raised during the discussion about the benefit and deployment scenario.

Comment:

Postponed SP-191367 from SP#86. Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200004 (LS IN) LS from TSG RAN: LS on 5G indicator. (Source:TSG RAN ()).
Document for: Information.
Abstract: TSG RAN received and discussed the LS from GSMA on 'Requirements for NR carrier frequency mismatch in 5G status indication.' [RP-193053]. In order to implement the requirements from GSMA, RAN concluded the following changes to the E-UTRA RRC specification are required: 1 Introduce signalling to enable a UE camped on an E-UTRA cell to be informed, with frequency band granularity, of the NR frequency bands available for configuration of EN-DC operation within the area of this cell. In the case of RAN sharing, it must be possible to provide the NR frequency bands independently per PLMN. RAN WG2 can involve other groups as necessary to introduce the appropriate signalling. 2 For a UE in RRC Idle (or Inactive), specify that the presence of the upperLayerIndication is only provided to upper layers if the UE supports EN-DC operation for one or more of the indicated frequency bands. 3 For a UE in RRC Connected, specify that the presence or absence of the upperLayerIndication is provided to upper layers depending on whether or not the UE is configured by RRC for EN-DC operation. TSG RAN has decided that further 3GPP work related to the display of any user interface indication, such as hysteresis to avoid toggling between displaying 4G and 5G icon as mentioned in the GSMA LS, is not needed.

Comment:

Postponed SP-191368 from SP#86. Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200005 (LS IN) LS from GSMA 5GJA: LS Response to SA WG2 on Clarification of NG.116. (Source:GSMA 5GJA (5GJA11_122_r1)).
Document for: Information.
Abstract: Overall Description: GSMA 5GJA thanks SA WG2 for their LS 'LS reply on Clarification NG.116 GST Throughput Attributes and Non-3GPP Access Support' and the review of the attributes listed in the NG.116. Question from SA WG2: In GSMA NG.116 GST v2.0, clauses 3.4.5, 3.4.6, 3.4.31 and 3.4.32 describe the Downlink throughput per network slice, Downlink throughput per UE, Guarantee Uplink/Downlink Throughput and the Maximum Uplink/Downlink Throughput attributes. Do these attributes apply across to GBR and non-GBR traffic or just non-GBR traffic? Answer: These attributes apply to both GBR and non-GBR traffic. Question from SA WG2: 3GPP 5G network slicing supports both 3GPP and non-3GPP accesses for a given S-NSSAI. When enforcing the two attributes above in Rel-17, we assume to apply the enforcement to 3GPP access only. Answer from GSMA: These attributes are for 3GPP access only.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200006 (LS IN) LS from ATIS UAV Ad-Hoc Group: Liaison Statement on UAV Remote ID Priority in Release 17. (Source:ATIS UAV Ad-Hoc Group (LS on FAA NPRM for UAV Remote ID)).
Document for: Information.
Abstract: The ATIS UAV Ad-Hoc group believes that support for remote identification of UAVs in 3GPP standards is important to fulfil regulatory requirements and to maximize the opportunity for mobile networks develop their business serving UAVs. To ensure 3GPP is aware of the technical direction of regulations in the US, we would like to bring to your attention the Notice of Proposed Rulemaking published by the Federal Aviation Authority (FAA) in December 2019. The notice can be found here: https://www.federalregister.gov/documents/2019/12/31/2019-28100/remoteidentification-of-unmanned-aircraft-systems The notice describes the current plans for FAA regulations for the use of UAVs in the US. As explained in more detail in the notice, the proposed rulemaking would require most UAVs to support Network Publishing ID and Direct Broadcast ID. We kindly ask SA WG1 and SA WG2 experts study the notice and to work to ensure that 3GPP standards fulfill the technical requirements in Release 17 in anticipation of the FAA's final rules. Sincerely, Iain Sharp Chair, ATIS UAV Ad Hoc Group.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200007 (LS IN) LS from ETSI TC MTS: Liaison statement from ETSI MTS on Methodology for RESTful APIs specifications and testing. (Source:ETSI TC MTS (MTS(20)079038)).
Document for: Information.
Abstract: ETSI TC MTS is pleased to inform all interested parties that an early draft of EG 203 647: 'Methods for Testing and Specification (MTS); Methodology for RESTful APIs specifications and testing' is now available. ETSI TC MTS welcomes and encourages feedback even at this early stage of the deliverable to help ensure that the methodology and guidelines address the needs of all stakeholders at ETSI and its partnership projects with regard to the specification and testing of RESTful APIs. The stable EG 203 647 is expected to be delivered in May 2020, followed by the publication of the final draft at the end of June 2020. As part of the work on EG 203 647, experts within STF 576 conducted a survey on the use of RESTful APIs within ETSI and its partnership projects and the needs of the different stakeholders. The survey results were discussed at a webinar on January 17th and are attached to this liaison Statement. All interested parties are invited to find out more about the status of the work of STF 576 in the Progress report attached to this Liaison Statement: and also follow the latest developments and provide feedback on EG 203 647 by joining the dedicated mailing list at: https://list.etsi.org/scripts/wa.exe?SUBED1=REST&A=1 . Detailed information about the MTS work programme can be found at: https://portal.etsi.org//tb.aspx?tbid=97&SubTB=97,875,860#/.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200008 (LS IN) LS from ITU-T SG2: LS on Enhancements of Cell-Broadcast based Public Warning Service over 3GPP Systems. (Source:ITU-T SG2 (SG2-LS135)).
Document for: Information.
Abstract: SG2 Q1/2 would like to thank you for your liaison regarding Enhancements of Cell-Broadcast based Public Warning Service over 3GPP Systems. The following intends to provide answers to the questions you raised. - Does ITU-T SG2 have or have any plans to develop or recommend a set of internationally recognized language-independent contents such as pictograms mapping to disasters that can be compatible with Unicode-based texts and can be included in public warning message? Answer: No. Currently, ITU-T SG2 has no plan to develop new Recommendations for such kind of Public Warning Services including requirements for language-independent contents. - What kind of disasters does ITU-T SG2 take into account for current public warning? In addition, are there any categories of disasters that are not supported by current public warning but need to be notified to the new IoT devices described above? ITU-T SG2 has developed several Recommendations for disaster relief services, such as ITU-T E.108 https://www.itu.int/rec/T-REC-E.108-201601-I and ITU-T E.119 https://www.itu.int/rec/T-REC-E.119-201704-I. However, these Recommendations do not focus on specific types of disasters, although they are developed mostly for natural disasters such as earthquakes and tsunamis. For additional information, ITU-T SG2 also developed a supplement document on 'Framework of disaster management for disaster relief system (E.100SerSup1)' https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=13896&lang=fr . This supplement describes 'Lead time for early warning systems' and suggests some examples of lead times for some kinds of natural disasters as follows: earthquakes, tornadoes and tsunamis, volcanic eruptions, hurricanes, droughts, El Nino and climate change.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200009 (LS IN) LS from ETSI ISG ZSM: Publication of major ZSM specifications. (Source:ETSI ISG ZSM (ZSM(19)000687r2)).
Document for: Information.
Abstract: The ETSI ISG Zero-touch network and Service Management (ZSM) would like to inform you of the publication of major ZSM specifications: GS ZSM 001 (ZSM Requirements), GS ZSM 002 (ZSM Reference Architecture) and GS ZSM 007 (ZSM Terminology). In GS ZSM 001, the ZSM ISG examined business-oriented scenarios and the related automation challenges faced by telecom operators and vertical industries. Subsequently, the ISG specified the architectural, functional and operational requirements for end-to-end network and service automation. The ZSM reference architecture specified in GS ZSM 002 was developed to satisfy these requirements. The architecture harnesses modular, flexible, scalable, extensible and service-based properties. It is designed to support advanced, data-driven automation based on closed-loop and integration of AI/ML techniques. The published specifications are publicly available at Link to Specifications. The ETSI ISG ZSM is currently working on the specification of solutions and management interfaces for the orchestration and automation of the emerging end-to-end network slicing technology (GS ZSM003) as well as of the end-to-end, cross-domain service orchestration and automation (GS ZSM008). Recently, the group has started work on specifying solutions for closed-loop automation. Specifically, the ISG works on generic enablers for closed-loop automation (GS ZSM009-1), solutions to closed-loop automation use cases (GS ZSM009-2), and investigation of advanced topics for next generation closed-loop operations (GR ZSM 009-3). In addition, the group is studying security aspects related to the ZSM framework and solutions (GR ZSM010), which include identifying potential security threats and mitigation options to be considered by the ZSM specifications to ensure that the automated processes are secured automatically and deliver the intended business outcomes. All the draft specifications are available via the ZSM open area (Link). The ETSI ISG ZSM invites you to study these specifications and consider them in your technical work. The ISG looks forward towards close and fruitful cooperation to achieve alignment, leverage synergies and ensure that end-to-end automation can be efficiently and consistently achieved.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200010 (LS IN) LS from SA WG2: Reply LS to 'new task group named 5G Intelligent Network Architecture and Use Case'. (Source:SA WG2 (S2-2001293)).
Document for: Information.
Abstract: SA WG2 thanks Artificial Intelligence Industry Alliance (AIIA) for their Liaison Statement on 'new task group named 5G Intelligent Network Architecture and Use Case'. SA WG2 welcomes further information on AIIA. 3GPP has a well-defined process and successful track record in delivering global standards to meet market requirements for multivendor interoperation (see http://www.3gpp.org/about-3gpp/about-3gpp). SA WG2 will consider input from AIIA if submitted via 3GPP individual members in accordance with 3GPP working procedures.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200013 (LS IN) LS from SA WG2: Reply LS to LS S3-194452 on UP gateway function on the N9 interface. (Source:SA WG2 (S2-2001727)).
Document for: Information.
Abstract: SA WG2 thanks SA WG3 for their Reply LS on UP gateway function on the N9 interface in S3-194452. SA WG2 agreed to the attached CR. When referring to SA WG3 TS 33.501, requirements for User Plane Gateway Function (UPGF) include: '- The UPGF shall only forward valid GTP-U packets on the N9 interface to the concerned UPF.' The above requirement bullet indicates that the IPUPS functionality (called UPGF in current SA WG3 spec) supports 'GTP-u packet filtering'. However, it is unclear to SA WG2 what information a UPF that supports the IPUPS functionality needs from SMF to achieve this 'GTP-u packet filtering'.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200014 (LS IN) LS from SA WG2: Questions on onboarding requirements. (Source:SA WG2 (S2-2001729)).
Document for: Information.
Abstract: SA WG2 has started working on the study on enhanced support of non-public networks. Based on service requirements documented in clause 5.1 of TS 22.263, SA WG2 developed key issue #4: UE Onboarding and remote provisioning in TR 23.700-07. SA WG2 started working on solutions for this key issue and is looking for clarification on the interpretation of the term: 'non-3GPP identities and credentials' documented in the following service requirement in TS 22.263: The 5G system shall support a secure mechanism for a network operator of an NPN to remotely provision the non-3GPP identities and credentials of a uniquely identifiable and verifiably secure IoT device. Q1) SA WG2 would like to verify with SA WG1 whether the above-quoted requirement includes the provisioning of the following for Stand-alone non-public networks (SNPNs): a) IMSI accompanied by AKA credentials, both used for SNPN authentication b) IMSI accompanied by AKA credentials, the IMSI being used to derive a Network Specific Identifier that will be used for SNPN authentication with the AKA credentials SA WG2 would like to emphasise that use of (a) above is explicitly supported and (b) is not precluded by SA WG2 specifications for SNPNs. Q2) SA WG2 would like to verify with SA WG1 whether the above-quoted requirement applies to PNI-NPN, which is the NPN 'hosted by a PLMN' as described in TS 22.261 clause 6.25.1, or not, and what would be the corresponding use cases. Q3) If SA WG1 confirm the above-quoted requirement applies to PNI-NPN in Q2, SA WG2 have further Q3 as below. For PNI-NPN, a UE may perform secondary PDU session authentication using 3rd party credentials, if the NPN is integrated in PLMN by means of dedicated DNNs, and/or a UE may perform Network specific slice authentication and authorisation (NSSAA) using 3rd party credentials if the NPN is integrated in PLMN by means of network slice. Given the authentication procedures already specified in TS 23.501, TS 24.501 and TS 33.501, SA WG2 would also like to ask whether provisioning for identities and credentials used for Network specific slice authentication and authorisation (NSSAA) and secondary PDU session authentication should be considered to be covered as part of NPN service requirement for onboarding and remote provisioning solution.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200015 (LS IN) LS from SA WG2: LS on AMF Reallocation via RAN re-routing. (Source:SA WG2 (S2-2001730)).
Document for: Information.
Abstract: SA WG2 has discussed further on the issue of AMF reallocation via RAN re-routing in the context of network slice isolation. A number of proposals for Rel-16 have been submitted to SA WG2#136ah, but SA WG2 could not reach consensus on any of these proposals: - One alternative was proposing to reject the UE Registration request while still providing the Allowed NSSAI, and ask the UE to re-register, overriding for this re-registration the privacy setting for the NSSAI (i.e. the UE shall send the NSSAI in Access Stratum independently of the setting of the Access Stratum Connection Establishment NSSAI Inclusion Mode) and using the SUCI. Concerns were expressed about the such inclusion of the NSSAI in the clear in RRC signalling even when the NSSAI Inclusion mode could indicate it should not be included, thus temporarily infringing the NSSAI privacy, for the benefit of accessing the right AMF set when the UE re-registers In addition, this proposal impacts the UE. - Another alternative was proposing to re-purpose the NSSF to act as a 'well-connected NF' to provide parts of the UE context between initial and target AMF, including the NAS security context. Concerns were expressed about the level of achievement on network slice isolation, considering that the AMF of the network slice is not properly isolated from the rest of the network, because the AMF can still be reached from AMFs belonging to other slices. In addition, this proposal modifies the functionality of the NSSF. - Alternatively, the existing Rel-15 architecture allows to purpose certain AMFs to act as 'well-connected NF' within the network and configure the RAN to select them as initial AMF (list of default AMFs) when not enough information is available to route directly the request to the proper target AMF, avoiding the problem in the first place when initial AMF is such 'well-connected-NF'. Concerns were expressed about the level of achievement on network slice isolation, considering that the AMF of the network slice is not properly isolated from the rest of the network, because the AMF can still be reached from AMFs belonging to at least some other slices which need to have N14 connectivity with this isolated slice, and that this might not address some cases when the UE requests change of network slices that leads to change of AMF. During the work on eNS in Rel-16, network slice isolation was considered in the context of a UE not being able to use simultaneously network slices that are isolated from each other (but not necessarily isolated against all other network slices or NFs), whereas the context of the discussion here some companies consider network slice isolation to be preventing any signalling between AMFs belonging each to slices isolated from each other, and even more, isolated from any NF not belonging to the network slice. SA WG2 lacks clarity regarding what network slice isolation is really expected to mean from SA WG3 angle and the impacts on the selection of a solution for AMF Reallocation. For instance, why is it important to avoid support of N14 (AMF-AMF interactions) for network slice isolation? Which security threat is avoided by removing the support of N14 within a PLMN? Would privacy loss be acceptable for the benefit of accessing directly the right AMF? SA WG2 invites SA WG3 to provide definition of the necessary isolation requirements from SA WG3 perspective and the security aspects or solutions that SA WG2 needs to take into account, and for feedback on the scenarios where network slice isolation takes place in a PLMN, and the security impacts that derive from it. Other proposals to resolve the issue are also welcome.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200016 (LS IN) LS from SA WG6: Reply LS on Split of work responsibilities between SA WG2 and SA WG6. (Source:SA WG6 (S6-200357)).
Document for: Information.
Abstract: SA WG6 has discussed the split of work responsibilities between SA WG2 and SA WG6 as proposed by SA WG2 and has the following feedback: - SA WG2 has responsibility for the 3GPP system architecture and procedures SA WG6 agrees. - SA WG6 has responsibility for the application-layer architecture and solutions identified by SA WG6 SA WG6 agrees. - DNS-based EAS discovery and related enhancements are in the scope of SA WG2. Application layer EAS discovery is in the scope of SA WG6. Any conflict between these two methods will be resolved in coordination between SA WG2 with SA WG6 SA WG6 agrees that DNS-based EAS discovery and related enhancements in 5GC are in the scope of SA WG2 and SA WG6 also acknowledges that development of URSP and DNAI-based solutions are also in the scope of SA WG2. - Any potential related overall architecture impacts related with 5GC exposure to application layer are in the scope of SA WG2. Potential Edge-related modifications to NEF API are in the scope of SA WG2, but SA WG6 may add additional information to be exposed by the 3GPP network. Documentation of those will be eventually done in SA WG2 specifications (TS 23.501, TS 23.502). SA WG6 agrees. - Edge-related modifications to CAPIF are in the scope of SA WG6. SA WG6 agrees. - Study of deployment scenarios are in the scope of both SA WG2 and SA WG6. The impact of certain deployment scenarios may require co-ordination between SA WG2 and SA WG6. The 900-series TR that SA WG2 is planning for edge deployment guidelines is under responsibility of SA WG2. SA WG6 acknowledges the removal of the Release 17 work-task for SA WG2 to document the deployment scenarios and guidelines in a 900-series TR. SA WG6 is documenting deployment scenarios and guidelines related to SA WG6 specifications in an informative annex of TS 23.558.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200017 (LS IN) LS from ITU-R WP 5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ON THE SCHEDULE FOR UPDATING RECOMMENDATION ITU-R M.2012 TO REVISION 5. (Source:ITU-R WP 5D (5D_TD_39e_IMT-ADV)).
Document for: Information.
Abstract: Introduction Working Party (WP) 5D thanks the relevant External Organizations for their successful work in regards to completion of the Revision 4 of Recommendation ITU-R M.2012 - 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications-Advanced (IMT-Advanced)' which will be available as a published ITU-R Recommendation. WP 5D wishes to inform the relevant External Organizations that it is commencing the cycle for the development of the Revision 5 of Recommendation ITU-R M.2012 and provides a detailed schedule for Revision 5 of Recommendation ITU R M.2012. Background This liaison provides guidance to External Organizations regarding updates of the terrestrial radio interfaces in the development of Revision 5 of Recommendation ITU-R M.2012 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications-Advanced (IMT-Advanced)'. Confirmed meeting dates of WP 5D for 2020 and 2021 will be published on the ITU website (http://www.itu.int/events/upcomingevents.asp?sector=ITU-R&lang=en). Procedure The procedure outlined in document IMT-ADV/25(Rev.2) Procedure for the development of draft revisions of Recommendation ITU-R M.2012 applies to the development of this Revision 5. Schedule For the Revision 5 of Recommendation ITU-R M.2012 a completion date of the WP 5D meeting #39, currently planned for October 2021, has been chosen. WP 5D announces that the first formal meeting in the meeting cycle ('Meeting Y') of the development of Revision 5 of Recommendation ITU-R M.2012 will be WP 5D meeting #35, which is scheduled for 23 June - 1 July 2020. It should be noted that the contribution deadline for WP 5D meeting #35 is also the cut-off date for the submission of new candidate RIT and SRIT proposals for inclusion in Revision 5. The detailed timeline for the Revision 5 of Recommendation ITU-R M.2012 which accommodates the currently planned/anticipated schedule of meetings for WP 5D and Study Group 5 through the 2020 and 2021 time frame and some milestone activities/actions may be found in Document IMT-ADV/31 'Schedule for Revision 5 of Recommendation ITU-R M.2012'. The dates in Document IMT-ADV/31 were developed considering not only the WP 5D and Study Group 5 dates but also with a view towards coordinating with the understood planned dates of the relevant External Organizations to the extent they were known. Some adjustment of these dates might be required to accommodate availability of facilities at specific venues in conjunction with the scheduling of the ITU-R WP 5D and Study Group 5 meetings. Every effort will be made to keep these dates as listed. Please check the ITU website in case meeting details have changed (http://www.itu.int/events/monthlyagenda.asp?lang=en). As appropriate Document IMT-ADV/31 will be updated to accommodate such date changes and further correspondence with the External Organization could be forthcoming throughout the update cycle as warranted by the circumstances. External Organizations are encouraged to consult the ITU-R IMT-Advanced web page (http://www.itu.int/ITU-R/go/rsg5-imt-advanced/) which may be updated dynamically to provide additional information. WP 5D looks forward to the continued cooperation with the External Organizations in the on-going work on the IMT-Advanced terrestrial radio interfaces.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200018 (LS IN) LS from ITU-R WP 5D: LIAISON STATEMENT TO POTENTIAL GCS/DIS PROPONENTS ON THE REQUEST TO SUBMIT THE MATERIALS FOR THE FIRST RELEASE OF NEW RECOMMENDATION ITU-R M.[IMT-2020.SPECS. (Source:ITU-R WP 5D (5D_TD_42e_IMT-2020)).
Document for: Information.
Abstract: Introduction ITU-R Working Party 5D (WP 5D) thanks the relevant External Organizations for their work regarding the submissions for IMT-2020 under Step 3 of the IMT-2020 development process. WP 5D informed the relevant External Organizations of the detailed schedule for finalization of the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] in the previous liaison with two IMT-2020 Documents (IMT-2020/20, IMT-2020/21). Background Working Party 5D (WP 5D) thanks the relevant External Organizations (RIT/SRIT Proponents) for submitting Form A Document. WP 5D recognizes that potential GCS Proponent of each candidate RIT or SRIT is as following: IMT-2020 document number RIT/ SRIT Potential GCS Proponent GCS /DIS style RIT/SRIT Proponent(s) 1 IMT-2020/13 SRIT ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC GCS 3GPP Proponent 2 IMT-2020/14 RIT ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC GCS 3GPP Proponent 3 IMT-2020/15 RIT CCSA GCS China 4 IMT-2020/16 RIT TTA GCS Korea 5 IMT-2020/17 Rev.1 SRIT ETSI GCS DECT Forum, ETSI 6 IMT-2020/18 Rev.1 RIT Nufront DIS Nufront 7 IMT-2020/19 Rev.1 RIT TSDSI GCS TSDSI WP 5D recognizes that the IMT-2020 development process is still under Steps 5, 6 and 7 and has completed evaluating the candidate RIT and SRIT proposals in 34th meeting of WP 5D; and is considering of evaluation results, consensus building and decision. RIT(s)/SRIT(s) for inclusion in the standardization phase (Step 8) will be decided formally at the 35th meeting of WP 5D. However, due to the tight schedule for developing the new Recommendation, WP 5D needs to take accelerate actions for the first release of the new Recommendation as indicated in Document IMT 2020/21. Requests for Action: WP 5D kindly requests the relevant External Organizations (potential GCS Proponent(s)) to submit package of GCS list, Certification B (Annex 2 of IMT-2020/20) and the texts for Overview section to the 35th meeting (23 June-1 July 2020). If the relevant External Organization (potential GCS Proponent) decides to employ DIS style, it doesn't need to submit GCS list but needs to submit full materials for describing its RIT/SRIT in the Recommendation and Certification B at 35th meeting. For convenience, the working document towards preliminary draft New Recommendation ITU-R M.[IMT-2020.SPECS] is enclosed to this liaison as Attachment. Please refer to Annex X for GCS utilized style and Annex Y for DIS style when developing the texts for Overview section or full materials for describing its RIT/SRIT in the Recommendation. WP 5D also kindly encourage the potential GCS Proponents to start consensus building in Step 7 for achieving global harmonization and having the potential for wide industry support for the radio interfaces that are developed for IMT-2020. This may include grouping of RITs or modifications to RITs to create SRITs that better meet the objectives of IMT-2020. When potential GCS Proponents agreed to consolidate their RITs/SRITs as a result of consensus building (Step 7), one of the potential GCS Proponents needs to submit above requested materials and the other potential GCS Proponent(s) needs to input following information instead of those materials as reply: - Consolidated RIT/SRIT numbers (e.g. RIT/SRIT Proposal (IMT-2020/a) is consolidated with RIT/SRIT Proposal (IMT-2020/b)) - GCS Proponent member list of consolidated RIT/SRIT if GCS Proponent member added. The Cut-off day for submissions for 35th meeting is 16 June 2020. WP 5D looks forward to the continued cooperation with the External Organizations in the on-going work on the IMT-2020 terrestrial radio interfaces.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200022 (LS IN) LS from CT WG1: Reply LS on general status of work. (Source:CT WG1 (C1-200309)).
Document for: Information.
Abstract: CT WG1 would like to thank Broadband Forum for the LS (LIAISE-363/C1-200211) on General Status of Work. Broadband Forum's LS states: ----------------- 5) We are looking to complete protocol work for the support of NAS exchange across Y4. We would like 3GPP to confirm that the maximum length of a NAS message can exceed 1490 bytes, to assist us in finalizing the design. ----------------- CT WG1 confirms that the maximum length of a NAS message can exceed 1490 bytes. NOTE: E.g. SUCI contained in a NAS message can be longer than 3000 octets, according to TS 33.501.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200023 (LS IN) LS from CT WG1: Reply LS on Rel-16 NB-IoT enhancements. (Source:CT WG1 (C1-201024)).
Document for: Information.
Abstract: CT WG1 thanks SA WG2 for their LS on 'Reply LS on Rel-16 NB-IoT enhancements'. CT WG1 has discussed the NAS impacts of both options provided by SA WG2 and would like to provide the following feedback: - Both options are feasible from the NAS protocol perspective. Additionally, CT WG1 would like to receive feedback on the following questions to decide the NAS part of the solution to pursue: - Question to RAN WG2: What values shall be supported for UE specific DRX for NB-IoT? - Question to RAN WG3: When the UE is accessing via NB-IoT, is the legacy MME is mandated to provide the stored UE specific DRX value, that was requested by the UE over NAS, in the S1 paging message to the eNB?

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200025 (LS IN) LS from CT WG1: LS on Unicode symbol numbers representing disasters. (Source:CT WG1 (C1-201043)).
Document for: Information.
Abstract: CT WG1 would like to inform ISO/IEC JTC1/SC2 of recent 3GPP work on the enhancements of Public Warning Service (ePWS) for 5G. One of objectives in 3GPP work on ePWS aims to improve the comprehension of text-based warning messages for users not literate in the local languages. Following provides links to the relevant 3GPP technical reports/technical specifications related to 3GPP work on ePWS. - 3GPP Stage 1 TR 22.869 V16.1.0 http://www.3gpp.org/ftp//Specs/archive/22_series/22.869/22869-g10.zip - 3GPP Release 16 Stage 1 TS 22.268 V16.3.0 http://www.3gpp.org/ftp//Specs/archive/22_series/22.268/22268-g30.zip - 3GPP TR 23.735 V16.0.0 http://www.3gpp.org/ftp//Specs/archive/23_series/23.735/23735-g00.zip - 3GPP Stage 2 23.041 V16.2.0 http://www.3gpp.org/ftp//Specs/archive/23_series/23.041/23041-g20.zip CT WG1 kindly asks ISO/IEC JTC1/SC2 the following questions related to the recent 3GPP work on ePWS: Question 1. CT WG1 would like to ask ISO/IEC JTC1/SC2 to provide what Unicode symbols defined in ISO/IEC 10646 are possible to be recommended as language-independent contents such as pictograms mapping to disasters (earthquake, tsunami, fire, flood, typhoon, hurricane, cyclone, tornado, volcanic eruption, epidemic and chemical hazard) that can be compatible with Unicode-based texts and can be included in public warning message. Question 2. If there are no proper Unicode symbols recommendable for the ePWS purpose to address the language issue existed in text-based warning messages in ISO/IEC 10646, CT WG1 would like to request ISO/IEC JTC1/SC2 the standardization of Unicode-based language-independent contents representing earthquake, tsunami, fire, flood, typhoon, hurricane, cyclone, tornado, volcanic eruption, epidemic and chemical hazard.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200026 (LS IN) LS from RAN WG3: Reply LS on Rel-16 NB-IoT enhancements. (Source:RAN WG3 (R3-201417)).
Document for: Information.
Abstract: RAN WG3 thanks SA WG2 for the LS 'Reply LS on Rel-16 NB-IoT enhancements'. RAN WG3 has discussed how to support UE specific DRX for NB-IoT in both EPS and 5GS in RAN WG3 specifications. RAN WG3 would like to provide the following feedback: From RAN WG3 point of view, both options are feasible and have same potential RAN WG3 specification impact.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200027 (LS IN) LS from ITU-R WP 5D: Availability of Addendum 5 to Circular Letter 5/LCCE/59. (Source:ITU-R WP 5D (ITU_R_WP5D_TEMP_31)).
Document for: Information.
Abstract: ITU-R has commenced the process of developing ITU-R Recommendations for the terrestrial components of the IMT-2020 radio interface(s). The invitation for submission of proposals for candidate radio interface technologies for the terrestrial components of IMT-2020 was issued in Circular Letter 5/LCCE/59 by ITU-R on 22 March 2016. Following the first invitation, four addenda have been issued to provide further information on the availability of related IMT-2020 documents, Reports, and workshop. These addenda can be found at the same web page as Circular Letter 5/LCCE/59. During its 33nd meeting of Working Party 5D (WP 5D), Addendum 5 to the Circular Letter was developed to announce the relevant information. WP 5D kindly invites interested organizations to take into account the information for the process of future development of the terrestrial components of IMT-2020 and to participate in the subsequent evaluation. WP 5D looks forward to collaborating with external organizations on this matter and will continuously provide information on future Addenda to the Circular Letter.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200028 (LS IN) LS from ITU-R WP 5d: ON THE REQUEST TO SUBMIT THE MATERIALS FOR THE FIRST RELEASE OF NEW RECOMMENDATION ITU-R M.[IMT-2020.SPECS]. (Source:ITU-R WP 5D (ITU_R_WP5D_TEMP_26)).
Document for: Information.
Abstract: Introduction ITU-R Working Party 5D (WP 5D) thanks the relevant External Organizations for their work regarding the submissions for IMT-2020 under Step 3 of the IMT-2020 development process. WP 5D informed the relevant External Organizations of the detailed schedule for finalization of the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] in the previous liaison (Attachment 7.4 to Document 5D/1297, filename 5D_TD_736e_IMT-2020.docx attached to the email sent on 23 July 2020) referring to two IMT-2020 Documents (IMT-2020/20, IMT-2020/21). Background WP 5D recognizes that the IMT-2020 development process is still under Steps 4, 5, 6 and 7 and WP 5D is evaluating the candidate RIT and SRIT proposals. RIT(s)/SRIT(s) for inclusion in the standardization phase (Step 8) will be decided formally at the 35th meeting of WP 5D. However, due to the tight schedule for developing the new Recommendation, WP 5D needs to take accelerate actions for the first release of the new Recommendation as indicated in Document IMT 2020/21. Requests for Action: WP 5D kindly requests the relevant External Organizations (RIT/SRIT Proponents, potential GCS Proponent(s)) to submit the Form A (Annex 1 of IMT-2020/20) to the 34th meeting of WP 5D (19 26 February 2020) and package of GCS list, Form B (Annex 2 of IMT-2020/20) and the texts for Overview section to the 35th meeting (24 June-1 July 2020). If the relevant External Organization (potential GCS Proponent) decides to employ DIS style, it doesn't need to submit GCS list but needs to submit full materials for describing its RIT/SRIT in the Recommendation and Form B at 35th meeting. WP 5D also asks the relevant External Organizations to start consensus building in Step 7 for achieving global harmonization and having the potential for wide industry support for the radio interfaces that are developed for IMT-2020. This may include grouping of RITs or modifications to RITs to create SRITs that better meet the objectives of IMT-2020. The cut-off days for submissions are: For 34th meeting: 12 February 2020 For 35th meeting: 17 June 2020. WP 5D looks forward to the continued cooperation with the External Organizations in the on-going work on the IMT-2020 terrestrial radio interfaces.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200029 (LS IN) LS from SA WG1: LS on Questions on onboarding requirements. (Source:SA WG1 (S1-201087)).
Document for: Information.
Abstract: SA WG1 thanks SA WG2 for their LS on onboarding requirements. SA WG2 raised several questions concerning the following onboarding requirement: The 5G system shall support a secure mechanism for a network operator of an NPN to remotely provision the non-3GPP identities and credentials of a uniquely identifiable and verifiably secure IoT device. SA WG1 would like to provide the following answers: Q1) SA WG2 would like to verify with SA WG1 whether the above-quoted requirement includes the provisioning of the following for Stand-alone non-public networks (SNPNs): a) IMSI accompanied by AKA credentials, both used for SNPN authentication b) IMSI accompanied by AKA credentials, the IMSI being used to derive a Network Specific Identifier that will be used for SNPN authentication with the AKA credentials A1) The quoted requirement applies to non-3GPP identities and credentials only, while SA WG2's question refers to 3GPP identities and credentials. As such, the answer is no, the above-quoted requirement does not include provisioning of the mentioned identities and credentials to SNPNs. However, SA WG1 would like to point out that a requirement for remote provisioning has been included in TS 22.261, clause 6.14.2, since Release 15: The 5G system shall support a secure mechanism for a home operator to remotely provision the 3GPP credentials of a uniquely identifiable and verifiably secure IoT device. This requirement was acknowledged as being part of 'Existing features partly or fully covering the use case functionality' during FS_AVPROD study (see TR 22.827). Q2) SA WG2 would like to verify with SA WG1 whether the above-quoted requirement applies to PNI-NPN, which is the NPN 'hosted by a PLMN' as described in TS 22.261 clause 6.25.1, or not, and what would be the corresponding use cases. A2) SA WG1 requests clarification on the question from SA WG2, specifically, is SA WG2 asking if the above quoted question is related to primary or secondary authentication for the PNI-NPN. Q3) If SA WG1 confirm the above-quoted requirement applies to PNI-NPN in Q2, SA WG2 have further Q3 as below. For PNI-NPN, a UE may perform secondary PDU session authentication using 3rd party credentials, if the NPN is integrated in PLMN by means of dedicated DNNs, and/or a UE may perform Network specific slice authentication and authorisation (NSSAA) using 3rd party credentials if the NPN is integrated in PLMN by means of network slice. Given the authentication procedures already specified in TS 23.501, TS 24.501 and TS 33.501, SA WG2 would also like to ask whether provisioning for identities and credentials used for Network specific slice authentication and authorisation (NSSAA) and secondary PDU session authentication should be considered to be covered as part of NPN service requirement for onboarding and remote provisioning solution. A3) SA WG1 requests clarification on the question from SA WG2, specifically, is SA WG2 asking whether 3rd party credentials may be used for secondary network slice authentication and authorization or Is SA WG2 asking whether these 3rd party credentials for secondary authentication can be provisioned via the 3GPP system, or is SA WG2 asking something else.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200242 (LS IN) LS from GSMA 5GJA: LS reply on GST attributes and on NG.116 publication and future co-operation. (Source:GSMA 5GJA (5GJA11_123r2)).
Document for: Information.
Abstract: GSMA NG/5GJA would like to thank SA WG5 for detail review of GSMA PRD NG.1116. We welcome the collaboration with SA WG5 on the mapping of GST attributes and 3GPP NRM attributes. SA WG5 questions [Availability] SA WG5 suggests considering the 3GPP definition of 'communication service availability', see clause 3.1 in 3GPP TS 22.261 (https://www.3gpp.org/ftp/Specs/archive/22_series/22.261/). SA WG5 NRM 'ServiceProfile' object class already supports communication service availability. [GSMA] 5GJA has approved the same definition. This attribute will be updated in the version 3.0. [Coverage] SA WG5 needs clarification on this attribute. There are different proposals on how to describe the coverage area of the network slice in GSMA GST as below: - Based on base station location and coverage - Generic based on geographical partitioning SA WG5 suggests considering the generic based on geographical partitioning as the only approach since this approach is independent from the network deployment, and independent from deployment changes from network operator. [GSMA] 5GJA has renamed this attribute to Area of service and has been working on improving the description and values. At the moment, it is not clear how to express the geographical partitioning. There is a proposal to use Tracking Areas. [Energy efficiency] SA WG5 would like to highlight that, so far, the energy efficiency of a network slice is not defined. [GSMA] 5GJA has agreed to remove this attribute as the energy efficiency of a network slice is not defined. [Performance prediction] This attribute defines the capability to allow the mobile system to predict the network and service status. Predictive Quality of Service (QoS) can be done for various Key Quality Indicators (KQIs) and Key Performance Indicators (KPIs). KQIs reflect the end-to-end service performance and quality, while KPIs reflect the performance of the network. The prediction is done for a specific point of time in the future and for a specific geolocation. What is the relationship between this attribute and service performance assurance? Need some clarification on the usage of this attribute. [GSMA] System's prediction capability is only one way to achieve service performance assurance, but not the only way, hence these two attributes may have some indirect dependency. If the service performance is not assured, for instance, the typical 2C services, the customer could still order prediction capability from the operator to understand where the bottleneck is, and if something could be done from application level in advance to avoid problem. [Reliability] SA WG5 suggests considering the 3GPP definition of 'reliability', see clause 3.1 in 3GPP TS 22.261. [GSMA] 5GJA has decided to remove this attribute as it can be express by other attribute - Packet Error Rate (part of Slice quality of service) [Simultaneous use of the network slice] Question: Is this an attribute related to UE capability to support network slicing or not? Need more clarification on the purpose and usage of this attribute. [GSMA] This attribute describes whether a network slice can be simultaneously used by a device together with other network slices and, if so, with which other classes of network slices. The device mentioned above must support to use more than one network slice. NG.116 v3.0 will provide a better attribute description. [Supported access technologies] This attribute defines which access technologies are supported by the network slice: 1: GERAN 2: UTRAN 3: E-UTRA 4: NR 5: LTE-M 6: NB-IoT 7: Wi-Fi 8: Bluetooth 9: Fixed access, e.g. DSL, Fibre Considering the network slicing as a new feature introduced in 5G, SA WG5 would like to suggest using the following access technologies supported by the network slice: 4: NR 6: NB-IoT 7: Wi-Fi 9: Fixed access (e.g. DSL, Fibre) [GSMA] This attribute has been removed and new attribute NB-IoT support has been introduced instead. [Synchronicity] Question: Is this related to sync at the application level or not? [GSMA] This is application requirement, but mainly aims to provide hint how system level should provide synchronicity. [User data access] Question: Need clarification on the name of the attribute. What is the purpose of this attribute? [GSMA] This attribute specifies where the customer data will terminate. For example, eMBB slice all the data will go directly to the internet. Some of the NSCs may require terminating all the data in their private company network and in this case UPF needs to support some tunnelling mechanism. The third option is that the data will be exchanged only between the devices that have access to the given slice. [V2X communication mode] This parameter describes if the V2X communication mode is supported by the network slice: 0: NO 1: YES-EUTRA 2: YES- NR 3: YES -NR and E-UTRA Considering the network slicing as a new feature introduced in 5G, SA WG5 would like to suggest using NR: 0: NO 2: YES- NR [GSMA] 5GJA took the suggestion into consideration and prepared a change request based on the suggestion.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200243 (LS IN) LS from CT WG1: Reply LS on Mobile-terminated Early Data Transmission. (Source:CT WG1 (C1-201062)).
Document for: Information.
Abstract: CT WG1 thanks RAN WG2 for the information provided on MT-EDT. CT WG1 has agreed updates to 24.301 based on approved updates of 23.401 and the feedback given by RAN WG2. The CT WG1 updates of NAS protocol will introduce explicit support indicators from UE to network for control plane MT-EDT and user plane MT-EDT respectively. For further details, see the attached CT WG1 agreed CR.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200245 (LS IN) LS from SA WG3: Reply LS on UP gateway function on the N9 interface. (Source:SA WG3 (S3-200482)).
Document for: Information.
Abstract: SA WG3 thanks SA WG2 for their reply LS on UP gateway function on the N9 interface. In this LS, SA WG2 asks the following question to SA WG3: Question from SA WG2: [I]t is unclear to SA WG2 what information a UPF that supports the IPUPS functionality needs from SMF to achieve this 'GTP-u packet filtering'. To the above question, SA WG3 would like to provide the following answer: Answer from SA WG3: A UPF that supports the IPUPS functionality needs to receive the following information from the SMF: 1. PDU session establishment: Request to allocate destination IP address and TEID of a GTP-U tunnel for the PDU Session. 2. PDU session release: Information that the GTP-U tunnel is to be released. 3. During PDU Session lifetime: Request to allocate or release destination IP address and TEID in case the destination IP address and TEID for some reason need to change. SA WG3 foresees that only information that is currently sent on N4 from SMF to UPF will need to be sent from SMF to UPF with IPUPS functionality. That means, in release 16, the sent information between SMF and UPF with IPUPS functionality will be a subset of current N4. However, additions in future releases are not precluded.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200277 (LS IN) LS from 5GAA WG4: LS on eCall Support on 5G Core with NR . (Source:5GAA WG4 (5GAA_S-200065)).
Document for: Action.
Abstract: 5GAA is aware of the LS sent from SA WG2 (S2-2001677) to TSG SA on the restriction which is currently applied in 3GPP specifications on eCall over IMS over NR. 5GAA has discussed the topic in its WG4 #12 meeting and car OEMs indicated that early support of eCall over IMS over NR in the 3GPP specifications is needed. Due to possible different 5G network deployment scenarios and the long lifetime of cars, it is necessary to support NG eCall in all deployment scenarios. Therefore, 5GAA encourages TSG SA to conclude to remove the restriction that prevents support for eCall over IMS over NR in Rel-16. Action: 5GAA kindly asks TSG SA to carry out work needed to remove the restriction that prevents support for eCall over IMS over NR preferably in Rel-16.

Comment:

This is marked 'for action' but can be noted. Response drafted in SP-200286. Final response in SP-200291.

Discussion and conclusion:

Reply LS provided in SP-200286. Final response in SP-200291.

Status:

Replied to.

TD SP-200286 (LS OUT) LS reply on eCall Support on 5G Core with NR. (Source:Vodafone).
Document for: Approval.
Abstract: To: 5GAA WG4.

Convenor comment:

Comment:

Created at meeting. Response to SP-200277. SP-200286_rev1 approved. Revised to SP-200291.

Discussion and conclusion:

Gerald proposes editorial updates Fr07:57, which are covered in _rev1. SP-200286_rev1 approved.

Status:

Revised.

TD SP-200291 (LS OUT) LS reply on eCall Support on 5G Core with NR. (Source:TSG SA).
Document for: Approval.
Abstract: To: 5GAA WG4. CC: TSG RAN.

Convenor comment:

Comment:

Revision 1 of SP-200286. Approved.

Parallel:

Status:

Approved.

2.2 Incoming LSs which need an outgoing LS and for which a related outgoing LS was contributed by the tdoc deadline

TD SP-200011 (LS IN) LS from SA WG2: LS on Sending CAG ID. (Source:SA WG2 (S2-2001616)).
Document for: Action.
Abstract: SA WG2 conditionally agreed (pending confirmation from CT WG1) the attached CRs clarifying that the UE does not send the CAG ID to the network, and the NG-RAN provides the list of supported CAG IDs to the AMF. The AMF uses the list of CAG IDs from the NG-RAN and the Allowed CAG list from the UE subscription (part of Mobility Restrictions) as to perform access control. SA WG2 would like to clarify that the CAG IDs are used to represent areas, in form of CAG cells, from which the UEs having the CAG IDs in their subscription are allowed to access the network. Having to explicitly list all the Cell IDs would provide an equivalent functionality but would not be as efficient. From a system perspective, SA WG2 does not think there is any need for the UE to provide the CAG ID to the network. It was asked that CT WG1 should confirm whether the CRs are ok from CT WG1 perspective. Action: Kindly note the attached CRs shall be approved after CT WG1 confirmation.

Comment:

Proposed Action: Postponed to SA#88 . Proposed noted by mail from Krister (Ericsson) Tue0957. Noted.

Discussion and conclusion:

Proposed noted by mail from Krister (Ericsson) Tue0957.

Status:

Noted.

TD SP-200012 (LS IN) LS from SA WG2: LS on support for eCall over NR. (Source:SA WG2 (S2-2001677)).
Document for: Action.
Abstract: In Release 14, support for eCall was extended from the CS domain to eCall in IMS over LTE access (See the extract from TR 21.914 'Release 14 Work Item Summary' in Annex 1). In Release 15 the related functionality for eCall in IMS was specified for the 5G System. However Release 15 TS 23.501 prohibits eCall in IMS over NR with 5GCore (see annex 2). This prohibition was included because there were concerns that the relevant studies had not been performed by other working groups (e.g. by SA WG4 or by ETSI groups) for performance of eCall over NR. As a result, the 5GS in Release 15 only supports eCall in IMS over LTE. As eCall devices (e.g. cars) can have a long life, in order to allow the refarming of spectrum from LTE to NR and/or the removal of the CS domain core network, SA WG2 believes that 3GPP work should be undertaken to remove this restriction on the use of NR. Hence SA WG2 invites TSG SA to coordinate and potentially task other WGs, e.g. SA WG4, to investigate whether they see any problems with 3GPP introducing support for eCall in IMS over NR with 5GCore. Separately, some companies in SA WG2 indicated that they were concerned that EU regulations for eCall, and type approval, are only available for CS domain eCall. SA WG2 invites TSG SA to investigate this topic. Action: SA WG2 requests that: a) 'eCall over NR' is considered in the TSGs' work planning activities and that the target Release is identified b) TSG SA coordinates the work of SA/RAN/CT working groups to investigate whether they see any problems with 3GPP introducing support for eCall in IMS over NR with 5GCore. c) the existing EU regulations on eCall are investigated with respect to the use of LTE and NR.

Comment:

Responses drafted in SP-200035 and SP-200271. Proposed action: Consider responses. Final response in SP-200287.

Discussion and conclusion:

Final response in SP-200287.

Status:

Replied to.

TD SP-200035 (LS OUT) LS reply on Support for eCall over NR. (Source:Vodafone ).
Document for: Approval.
Abstract: To: SA WG2, SA WG1, SA WG4, RAN WG2, RAN WG5, CT WG1, CT WG3,CT WG4. CC: TSG RAN, TSG CT.

Comment:

Response to SP-200012. SP-200035_rev5 Approved. Revised to SP-200287.

Discussion and conclusion:

Proposed revision(s). Can _rev5 be approved?

Status:

Revised.

TD SP-200287 (LS OUT) Reply LS on support for eCall over NR. (Source:TSG SA).
Document for: Approval.
Abstract: To: SA WG2, SA WG1, SA WG4, RAN WG2, RAN WG5, CT WG1, CT WG3,CT WG4. CC: TSG RAN, TSG CT.

Convenor comment:

Comment:

Revision 5 of SP-200035. Approved.

Parallel:

Status:

Approved.

TD SP-200271 (LS OUT) [DRAFT] Reply LS on support for eCall over NR. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: Respond to LS from SA WG2 on eCall over IMS over NR.

Comment:

Response to SP-200012. Proposed Action: Merged.

Discussion and conclusion:

Was merged into SP-200035_rev1.

Status:

Merged.

TD SP-200281 (LS IN) LS from TSG CT: LS on Feedback on the Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on the schedule for updating Recommendation ITU-R M.2012 to Revision 5. (Source:TSG CT (CP-200295)).
Document for: Action.
Abstract: TSG CT has received the LS from ITU-R Ad Hoc on 'Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on the schedule for updating Recommendation ITU-R M.2012 to Revision 5' (CP-200282) It is the TSG CT understanding that the feedback is only required on the following text: 3GPP thanks ITU-R WP 5D for the information on the schedule for updating Recommendation ITU-R M.2012 to Revision 5. 3GPP intends to submit updated material on LTE-Advanced toward Revision 5 of Rec. ITU-R M.2012 according to the schedule communicated by ITU-R WP 5D. The updated material will be based on 3GPP Release 15 and 16. From a TSG CT point of view, the text is satisfactory. Action: TSG CT kindly asks TSG SA and TSG RAN to take the information provided above into account.

Comment:

Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200282 (LS IN) LS from TSG RAN: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on the schedule for updating Recommendation ITU-R M.2012 to Revision 5. (Source:TSG RAN (RP-200495)).
Document for: Action.
Abstract: For 3GPP review: in: TSG SA feedback LS before: March 20, 2020 to: 3GPP PCG Overall description: ITU-R Working Party 5D (WP 5D) informed 3GPP on their schedule towards Revision 5 of Recommendation M.2012.

Comment:

NEW TDOC (from RAN). Endorsed & Forwarded to PCG.

Discussion and conclusion:

Endorsed & Forwarded to PCG.

Status:

Endorsed.

TD SP-200269 (LS IN) LS from ITU-R Ad Hoc: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on the schedule for updating Recommendation ITU-R M.2012 to Revision 5. (Source:ITU-R Ad Hoc (RT-200015)).
Document for: Action.
Abstract: For 3GPP review: in: TSG RAN feedback LS before: March 19, 2020 to: TSG SA in: TSG CT feedback LS before: March 17, 2020 to: TSG RAN, TSG SA in: TSG SA feedback LS before: March 20, 2020 to: 3GPP PCG.

Comment:

For Endorsement and forwarding to PCG. Proposed action: Endorsed. Endorsed.

Discussion and conclusion:

For Endorsement and forwarding to PCG. Proposed action: Endorsed. Note: the SA related content of this LS was endorsed, it is reflected by the endorsed RAN version of this LS, which got forwarded to PCG.

Status:

Endorsed.

TD SP-200019 (LS IN) LS from 5GAA WG4: LS on relevant 3GPP Specs for PC5 Sidelink. (Source:5GAA WG4 (5GAA_S-200026)).
Document for: Action.
Abstract: The 5GAA has been contacted by ITU-T to provide a list of V2X and Sidelink 3GPP specifications. The objective is to have the information included in a Data Base related to the Collaboration on ITS Communication Standards. The attached specifications list contains the relevant 3GPP deliverables from the point of view of 5GAA. The related Data Base can be found at: https://www.itu.int/en/ITU-T/extcoop/cits/Pages/default.aspx. Action: 5GAA kindly ask TSG RAN and TSG SA to take this information into account and comment, if needed.

Comment:

Proposed Action: Postponed to SA#88. Postponed to SA#88.

Discussion and conclusion:

Postponed to SA#88.

Status:

Postponed.

TD SP-200020 (LS IN) LS from CableLabs: Status and Evolution of 5WWC. (Source:CableLabs (LS_5WWC status)).
Document for: Action.
Abstract: Dear Colleagues, CableLabs is aware that the proposed 5WWC study item as described in SP-191200 was not accepted as part of the scope in 3GPP release 17. CableLabs works with many operators who view the following convergence features to be of high priority in addition to those already standardized in 3GPP R16: - How to improve the support of L2 Bridge 5G-RG scenario for providing connectivity to devices behind the RG. This is similar to BBF requirements expressed in LS BBF-291/S2-1903875; - How to improve the support of QoS for UE connected behind an RG via Untrusted and Trusted Non-3GPP access. It is important that these convergence features and future converged core network evolution be included in 3GPP work planning. CableLabs requests SA plenary and SA WG2 take this information into account for future release planning. Sincerely Belal Hamzeh.

Comment:

Proposed Action: Postponed to SA#88. Postponed.

Discussion and conclusion:

Status:

Postponed.

TD SP-200021 (LS IN) LS from GSMA: Mandatory User Plane Integrity for 5G. (Source:GSMA (FSAG#79_002)).
Document for: Information.
Abstract: Background GSMA has been made aware through its 'Coordinated Vulnerability Disclosure Programme' about new research on layer-2 attack scenarios against LTE. The research has been published at [1] and will be presented on the security conference NDSS [2] end of February 2020. 2 Item for Consideration 2.1 Abstract from the Research Paper The key findings of the research are copied from the research paper's abstract below: 'Long Term Evolution (LTE/4G) establishes mutual authentication with a provably secure Authentication and Key Agreement (AKA) protocol on layer three of the network stack. Permanent integrity protection of the control plane safeguards the traffic against manipulations. However, missing integrity protection of the user plane still allows an adversary to manipulate and redirect IP packets, as recently demonstrated. In this work, we introduce a novel cross-layer attack that exploits the existing vulnerability on layer two and extends it with an attack mechanism on layer three. […] allows an active attacker to impersonate a user towards the network and vice versa; we name these attacks IMP4GT (IMPersonation attacks in 4G neTworks). In contrast to a simple redirection attack as demonstrated in prior work, our attack dramatically extends the possible attack scenarios and thus emphasizes the need for user-plane integrity protection in mobile communication standards.' 2.2 Observations from GSMA It is essential for security of 5G cellular networks that the 3GPP standards mandate support of user plane integrity protection at the full data rate of a UE. The new IMP4GT attacks exploit the same underlying issue as the earlier work described in [3], which was reported to 3GPP in 2018 [4]. GSMA gave 3GPP advance notice of the IMP4GT research in May 2019 [7]. The researchers executed the IMP4GT attacks in an LTE environment, but indicate that the same attack would in principle also work against 5G (UEs using NR connected to the 5GC) unless User Plane integrity protection is in place. It is GSMA's understanding of the current work in SA WG3 that a 5G 'standalone' SA network with NR radio connected to a 5G Core Network would support User Plane integrity protection, and thus could be immune against IMP4GT and similar attacks. The only aspect that remains unclear is the current implementation status of UEs, because [5] and [6] only mandate that UEs support a data rate of 64 kbps with integrity protection, while user plane integrity protection with full data rate is an optional UE feature. GSMA can only confirm the researcher's statement in the abstract: 'We emphasize the requirement for a mandatory and full-rate integrity protection for all 5G data connections to prevent IMP4GT' Even though the new attacks may have limited impact in real-world deployments, there is the need to strengthen the security of 5G networks and UEs for the future. It is essential to not create a large legacy of 5G networks and UEs that are vulnerable to such attacks. At this point in time no wide scale commercial penetration of « standalone » SA supporting terminals is in the market, hence it is now the right point in time to mandate this UE functionality. 3 Action: GSMA politely requests SA/RAN/CT to ask the affected working groups to agree the necessary CRs in the appropriate release to have mandatory support of full-rate user plane integrity protection for all UEs supporting NR connected to the 5GC. 3.1 Deadline GSMA would appreciate a response following the plenary meetings in March 2020.

Comment:

Responses drafted in SP-200240 and SP-200270. Proposed action: Consider responses. Postponed with text for guidance/meeting minutes.

Discussion and conclusion:

Postponed with text for guidance/meeting minutes.

e-mail discussion:

TSG SA tasks SA WG3 to determine how to mitigate identified security problems associated with user plane integrity from Release 16 onwards for UEs supporting Standalone NR connected to 5GC, including the proposal to mandate the support of full rate user plane integrity protection for those UEs, and report their progress at the next plenary. The SA WG3 meeting schedule is left for discussion in the SA WG3 working group. SA WG3 should make necessary arrangements including coordination with other groups to complete the work in R16.

Status:

Postponed.

TD SP-200240 (LS OUT) [DRAFT] Reply LS on mandatory support of full rate user plane integrity protection for 5G. (Source:BT, Deutsche Telekom, KPN, Orange, Telecom Italia, Telenor, Telia Company, Telstra, Vodafone).
Document for: Approval.
Abstract: To: GSMA CVD. CC: TSG RAN, TSG CT.

Comment:

Response to SP-200021. Noted.

Discussion and conclusion:

Which of these two documents (SP-200021 / SP-200270) should go forward? Haris (Qualcomm) objects to this LSout. Wed12:33. Erik (Samsung) supports objection. Wed13:18. Discussion on this issue is ongoing in parallel in RAN. Adrian(Vdf) requesting that SA WG3 allows for related study to be handled in SA WG3 during Q2, if necessary in additional e-meeting Wed14:06. Jianhua (OPPO) also objects to this version of the reply Thu7:32. Erik (Samsung) objects to _rev2. Thu10:59. Jianhua (OPPO) objects to _rev3 Thu15:19. Haris (Qualcomm) objects to rev4. Fri15:02. Jianhua also objects. Fri15:11. Chunhui (Spreadtrum) also objects. Fri15:23. Erik (Samsung) also objects. Fri15:56. Noted.

Status:

Noted.

TD SP-200270 (LS OUT) [DRAFT] Response to mandatory User Plane Integrity for 5G. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: Responds to GSMA LS to mandatory User Plane Integrity for 5G.

Comment:

Response to SP-200021. Noted.

Discussion and conclusion:

Which of these two documents (SP-200021 / SP-200270) should go forward? Johannes (DT) objects to this LSout. Wed13:26. Several companies supporting DT. Discussion on this issue is ongoing in parallel in RAN. Noted.

Status:

Noted.

TD SP-200247 (LS OUT) [DRAFT] LS on mandatory support of full rate user plane integrity protection for 5G. (Source:BT, Deutsche Telekom, KPN, Orange, Telecom Italia, Telenor, Telia Company, Telstra, Vodafone).
Document for: Approval.
Abstract: To: CT WG1, SA WG2, SA WG3, RAN WG2, RAN WG3. CC: TSG RAN, TSG CT.

Comment:

Related to SP-200240 ? Noted.

Discussion and conclusion:

Similar discussions as for SP-200240/SP-200270. Haris (Qualcomm) objects to rev2. Fri15:02. Jianhua also objects. Fri15:11. Chunhui (Spreadtrum) also objects. Fri15:23. Erik (Samsung) also objects. Fri15:56. Noted.

Status:

Noted.

TD SP-200024 (LS IN) LS from CT WG1: Reply LS on sending CAG ID. (Source:CT WG1 (C1-201027)).
Document for: Action.
Abstract: CT WG1 would like to thank SA WG2 for the LS (S2-2001616/C1-200252) on Sending CAG ID. SA WG2's LS states: ----------------- Attachments: S2-2001614, S2-2001615 .. 2 Actions .. To CT WG1: Action: Kindly confirm the attached CRs are fine from CT WG1 perspective. ----------------- CT WG1 confirms that the S2-2001614 and S2-2001615 are OK.

Comment:

Proposed Action: Postponed to SA#88. Proposed noted by mail from Krister (Ericsson) Tue0957. Noted.

Discussion and conclusion:

Proposed noted by mail from Krister (Ericsson) Tue0957.

Status:

Noted.

TD SP-200241 (LS IN) LS from ITU-R WP5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ON DRAFT REVISION OF REPORT ITU-R M.2291-1 'THE USE OF INTERNATIONAL MOBILE TELECOMMUNICATIONS (IMT) FOR BROADBAND PUBLIC PROTECTION AND DISASTER RELIEF (PPDR) APPLICATIONS'. (Source:ITU-R WP5D (5D_TD_52R1e)).
Document for: Action.
Abstract: Report ITU-R M.2291-1 was developed by ITU-R in 2016. Tables 2, 3 and 4 in Annex 1 of Report ITU-R M2291-1 were developed in collaboration with 3GPP. These tables detail how 3GPP LTE supports the various requirements of PPDR and provide the relevant 3GPP Release numbers, which are included in the last column of the tables. WP 5D has started revising Report ITU-R M.2291-1. This revision will update as necessary, tables in Annex 1 of the report to reflect technological developments in IMT-2020, in particular the work carried out by 3GPP (SA WG6) in the latest releases of 3GPP LTE and NR. A copy of the working document towards the preliminary draft revision of Report ITU-R M.2291-1 is enclosed to facilitate updating of Annex 1. As a part of this revision, WP 5D intends to include information on IMT-2020, similar to the information available on LTE in Annex 1. Blank columns have been added in the working document in Tables 2, 3 and 4 to facilitate this work by the External Organisations. It would also be useful if External Organizations could indicate any new features/applications that have been added in support of PPDR applications in their IMT-2020 specifications, which are currently not included in Annex 1 of the Report ITU-R M.2291-1, by adding additional rows, as necessary. WP 5D therefore requests External Organisations to kindly provide input to facilitate updating of Annex 1 of Report ITU-R M.2291-1 as explained above. WP 5D would appreciate receiving inputs towards this work in time for the 35th meeting of WP 5D scheduled to be held from 23rd June 2020 (deadline for contribution is 1600 hours UTC 16th June 2020).

Comment:

Proposed Action: Postponed to SA#88. Postponed & Forwarded to SA WG6.

Discussion and conclusion:

Suresh (SA WG6 chair) requests forwarding of the LS to SA WG6, Thu09:04. Giovanni (ITU-R AdHoc Convenor): Proposed conclusion: 3GPP RAN ITU-R AH will develop via E-mail discussion a reply LS with support from SA WGs (esp. SA WG6) by 20.05.2020. RAN will review it and agree by May 27th and they will provide it to SA (agreement on 03.06.20) and approval by PCG by 10.06.2020. Submission to ITU-R WP5D will be done by companies members of both 3GPP and ITU-R, as per working procedures. Postponed & Forwarded to SA WG6.

Status:

Postponed.

TD SP-200244 (LS IN) LS from RAN WG2: Reply LS on Rel-16 NB-IoT enhancements. (Source:RAN WG2 (R2-2001815)).
Document for: Action.
Abstract: Reply to S2-1912763: RAN WG2 thanks SA WG2 for their reply LS and for proposing two options for the introduction of UE specific DRX. In RAN WG2#109-e, RAN WG2 discussed the feasibility of the two options and preference from RAN WG2 point of view and would like to provide the following feedback: - From RAN WG2 point of view, both options are feasible. - From RAN WG2 point of view, option 2 is preferred as it can support separate value ranges for NB-IoT and WB-EUTRAN. Reply to C1-201024: RAN WG2 thanks CT WG1 for their question on the values for UE specific DRX cycle in NB-IoT. In RAN WG2#109-e, RAN WG2 discussed the value set for UE specific DRX cycle but there was no consensus in this RAN WG2 meeting. Action: RAN WG2 respectfully asks SA WG2, CT WG1, RAN WG3 and SA to take above information into account.

Comment:

Proposed Action: Postponed to SA#88. Postponed.

Discussion and conclusion:

Status:

Postponed.

TD SP-200246 (LS IN) LS from 3GPP Rel16: Reply LS on analytics support for energy saving . (Source:SA WG5 (S5-201472)).
Document for: Action.
Abstract: SA WG5 thanks TSG SA for their Liaison Statement on 'analytics support for energy saving'. SA WG5 would like to inform SA and SA WG2 that our Rel-16 work item 'Energy efficiency of 5G' is about to be completed. The EE KPI and related performance measurements have been defined for NG-RAN as well as energy saving management use cases, requirements and information model. SA WG5 understands that the questions from SA WG2 are related to energy saving in a virtualized 5G core network. SA WG5 thinks that the relevance of virtualized 5GC energy saving use cases and solutions can be assessed when the means exist to measure the corresponding energy efficiency KPI before and after the energy saving functionality has been activated. As the 3GPP management system has the overall network view, the coordination between 5GC energy saving and NG-RAN energy saving needs to be considered from the OA&M aspect. SA WG5 is discussing the objectives of a Release 17 work item on use cases, requirements and solutions, as enhancement of Rel-16 energy efficiency and energy saving in 5G networks. The work includes the following aspects: a) 5GC network functions and b) the case of virtualized network functions. The potential usage of analytics and NWDAF is to be considered, in conjunction with OA&M (incl. MDAS - Management Data Analytics Service) in Rel-17 work. SA WG5 encourages SA WG2 to elaborate further on the description of potential energy saving use cases and solutions for 5GC, involving NWDAF or not, and in relationship with OA&M, and keep SA WG5 updated. Action: To SA: Please take the above information in consideration.

Comment:

Proposed Action: Postponed to SA#88. Postponed.

Discussion and conclusion:

Status:

Postponed.

TD SP-200251 (LS OUT) [DRAFT] Liaison to ITU-R WP4B on the integration of satellite solutions into 5G networks. (Source:THALES).
Document for: Approval.
Abstract: To: ITU-R WP4B. CC: TSG RAN, 3GPP PCG, ETSI TC-SES.

Comment:

SP-200251_rev1 Approved. Revised to SP-200288.

Discussion and conclusion:

Nicolas (Thales) proposes update Wed10:22. Approved (_rev1).

Status:

Revised.

TD SP-200288 (LS OUT) Liaison to ITU-R WP4B on the integration of satellite solutions into 5G networks. (Source:TSG SA).
Document for: Approval.
Abstract: To: ITU-R WP4B. CC: TSG RAN, PCG, ETSI TC-SES. Attachments: SP-170849, SP-190556.

Convenor comment:

Comment:

Revision 1 of SP-200251. Approved.

Parallel:

Status:

Approved.

TD SP-200279 (LS IN) LS from TSG CT: LS on Feedback on the Draft Letter to ITU on 3GPP '5G' material for Recommendation ITU-R M.[IMT-2020 specs] - SRIT. (Source:TSG CT (CP-200293)).
Document for: Action.
Abstract: CT has received the LS from ITU-R Ad Hoc on 'Draft Letter to ITU on 3GPP '5G' material for Recommendation ITU-R M.[IMT-2020 specs] - SRIT' (CP-200279) It is the TSG CT understanding that TSG CT is only concerned by the following text in the Annex 2: Information on system and core network specifications can be found in the 3GPP web site for a complete system perspective. These system and core network specifications address the network, terminal, and service aspects required to provide an integrated mobility solution including aspects such as user services, connectivity, interoperability, mobility and roaming, security, codecs and media, operations and maintenance, charging, etc. All the 3GPP specifications can be found at the following link: https://www.3gpp.org/specifications/specification-numbering. 3GPP specifications are reviewed and updated after each Technical Specification Group Plenary meeting (held every year in March, June, September and December). From a CT point of view, the text is satisfactory. Action: TSG CT kindly asks TSG SA and TSG RAN to take the information provided above into account.

Comment:

Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200284 (LS IN) LS from TSG RAN: Draft Letter to ITU on 3GPP '5G' material for Recommendation ITU-R M.[IMT-2020 specs] - SRIT. (Source:TSG RAN (RP-200497)).
Document for: Information.
Abstract: For 3GPP review: in: TSG SA feedback LS before: March 20, 2020 to: 3GPP PCG Overall description: According to the procedures described in Circular Letter 5/LCCE/59, this contribution represents the material relevant to 3GPP '5G' - submission 1 SRIT - towards the finalization of ITU-R Recommendation M.[IMT-2020 specs], 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications 2020 (IMT-2020)'. The following documents are attached for approval by TSG SA: i. Attachment 1 of Rec. ITU-R M.[IMT-2020 specs] - Specification of the 3GPP 5G radio interface technology - SRIT (SRIT Section 1.zip); ii. Attachment 2 of Rec. ITU-R M.[IMT-2020 specs] - Detailed specification of the radio interface technology (SRIT Section 2.zip) Note that - Attachment 1 provides an overview of the radio characteristics of the radio access technology - Attachment 2 contains the list of 3GPP 5G Global Core Specifications whose Release 15 and Release 16 versions have to be transposed by 3GPP OPs. These specifications consist of RAN Core specifications. A list of non-Core radio specifications is also provided to ITU-R for information, while SA and CT specifications are referred via a link to the 3GPP site. - The creation of the list of GCS and subsequent actions are described in PCG#43_16 (in attachment). Note PCG#43_16 will not be submitted to ITU-R, but it is for information to SA - 3GPP OPs are reminded that they need to submit Certification B (Annex 2 of IMT-2020/20) by June 16th, 2020. Actions: TSG RAN asks TSG SA to review the attached annexes and provide feedbacks to the PCG, by March 20, 2020.

Comment:

NEW TDOC (from RAN). Endorsed & Forwarded to PCG.

Discussion and conclusion:

Endorsed & Forwarded to PCG.

Status:

Endorsed.

TD SP-200260 (LS IN) LS from ITU-R Ad Hoc: Draft Letter to ITU on 3GPP '5G' material for Recommendation ITU-R M.[IMT-2020 specs] - SRIT. (Source:ITU-R Ad Hoc (RT-200017)).
Document for: Action.
Abstract: For 3GPP review: in: TSG RAN feedback LS before: March 19, 2020 to: TSG SA in: TSG CT feedback LS before: March 17, 2020 to: TSG RAN, TSG SA in: TSG SA feedback LS before: March 20, 2020 to: 3GPP PCG.

Comment:

For Endorsement and forwarding to PCG. Proposed action: Endorsed. Endorsed.

Discussion and conclusion:

For Endorsement and forwarding to PCG. Proposed action: Endorsed. Note: the SA related content of this LS was endorsed, it is reflected by the endorsed RAN version of this LS, which got forwarded to PCG.

Status:

Endorsed.

TD SP-200280 (LS IN) LS from TSG CT: LS on Feedback on the Draft Letter to ITU on 3GPP '5G' material for Recommendation ITU-R M.[IMT-2020 specs] - RIT. (Source:TSG CT (CP-200294)).
Document for: Action.
Abstract: TSG CT has received the LS from ITU-R Ad Hoc on 'Draft Letter to ITU on 3GPP '5G' material for Recommendation ITU-R M.[IMT-2020 specs] - RIT' (CP-200280) It is the TSG CT understanding that TSG CT is only concerned by the following text in the Annex 2: Information on system and core network specifications can be found in the 3GPP web site for a complete system perspective. These system and core network specifications address the network, terminal, and service aspects required to provide an integrated mobility solution including aspects such as user services, connectivity, interoperability, mobility and roaming, security, codecs and media, operations and maintenance, charging, etc. All the 3GPP specifications can be found at the following link: https://www.3gpp.org/specifications/specification-numbering. 3GPP specifications are reviewed and updated after each Technical Specification Group Plenary meeting (held every year in March, June, September and December). From a TSG CT point of view, the text is satisfactory. Action: TSG CT kindly asks TSG SA and TSG RAN to take the information provided above into account.

Comment:

Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200285 (LS IN) LS from TSG RAN: Draft Letter to ITU on 3GPP '5G' material for Recommendation ITU-R M.[IMT-2020 specs] - RIT. (Source:TSG RAN (RP-200498)).
Document for: Action.
Abstract: For 3GPP review: in: TSG RAN feedback LS before: March 19, 2020 to: TSG SA Overall description: According to the procedures described in Circular Letter 5/LCCE/59, this contribution represents the material relevant to 3GPP '5G' - submission 2 RIT - towards the finalization of ITU-R Recommendation M.[IMT-2020 specs], 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications 2020 (IMT-2020)'. The following documents are attached for approval by TSG SA: i. Attachment 1 of Rec. ITU-R M.[IMT-2020 specs] - Specification of the 3GPP 5G radio interface technology - RIT (RIT Section 1.zip); ii. Attachment 2 of Rec. ITU-R M.[IMT-2020 specs] - Detailed specification of the radio interface technology (RIT Section 2.zip) Note that - Attachment 1 provides an overview of the radio characteristics of the radio access technology - Attachment 2 contains the list of 3GPP 5G Global Core Specifications whose Release 15 and Release 16 versions have to be transposed by 3GPP OPs. These specifications consist of RAN Core specifications. A list of non-Core radio specifications is also provided to ITU-R for information, while SA and CT specifications are referred via a link to the 3GPP site. - The creation of the list of GCS and subsequent actions are described in PCG#43_16 (in attachment). Note PCG#43_16 will not be submitted to ITU-R, but it is for information to SA - 3GPP OPs are reminded that they need to submit Certification B (Annex 2 of IMT-2020/20) by June 16th, 2020. Actions: TSG RAN asks TSG SA to review the attached annexes and provide feedbacks to the PCG, by March 20, 2020.

Comment:

NEW TDOC (from RAN). Endorsed & Forwarded to PCG.

Discussion and conclusion:

Endorsed & Forwarded to PCG.

Status:

Endorsed.

TD SP-200261 (LS IN) LS from ITU-R Ad Hoc: Draft Letter to ITU on 3GPP '5G' material for Recommendation ITU-R M.[IMT-2020 specs] - RIT. (Source:ITU-R Ad Hoc (RT-200020)).
Document for: Action.
Abstract: For 3GPP review: in: TSG RAN feedback LS before: March 19, 2020 to: TSG SA in: TSG CT feedback LS before: March 17, 2020 to: TSG RAN, TSG SA in: TSG SA feedback LS before: March 20, 2020 to: 3GPP PCG.

Comment:

For Endorsement and forwarding to PCG. Proposed action: Endorsed. Endorsed.

Discussion and conclusion:

For Endorsement and forwarding to PCG. Proposed action: Endorsed. Note: the SA related content of this LS was endorsed, it is reflected by the endorsed RAN version of this LS, which got forwarded to PCG.

Status:

Endorsed.

TD SP-200283 (LS IN) LS from TSG RAN: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_58rev1 = RP-200043 on Development of a draft new report ITU-R M.[IMT.C-V2X] - Application of the Terrestrial Component of IMT for Cellular-V2X. (Source:TSG RAN (RP-200496)).
Document for: Action.
Abstract: For 3GPP review: in: TSG SA feedback LS before: March 20, 2020 to: 3GPP PCG Overall description: ITU-R Working Party 5D (WP 5D) informed 3GPP that they will develop draft ITU-R reports based on input contributions which will address the mutual relationship between IMT technologies and required functions of the specific application for the various scenarios including Cellular-Vehicles-to-Everything (C-V2X) application. Considering the above, WP 5D would like to inform external organizations that it has 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' (see Attachment 1). The finalization of the development is planned at its 38th meeting to be held 16-23 June 2021. WP5D is informing 3GPP that inputs are expected at WP5D#35 or WP5D#36. The deadlines for input contributions for its 35th meeting in June 2020 and 36th meeting in October 2020 are set for 16 June and 29 September, respectively. It is proposed that 3GPP submits a preliminary answer at WP5D#35 (this document) stating that 3GPP will contribute, and then submit the relevant material at WP5D#36. Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by March 20, 2020. Note: this document is the same as RT-200017, just changed the source from ITU-R Ad Hoc to RAN.

Comment:

NEW TDOC (from RAN). Endorsed & Forwarded to PCG.

Discussion and conclusion:

Endorsed & Forwarded to PCG.

Status:

Endorsed.

TD SP-200262 (LS IN) LS from ITU-R Ad Hoc: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_58rev1 = RP-200043 on Development of a draft new report ITU-R M.[IMT.C-V2X] - Application of the Terrestrial Component of IMT for Cellular-V2X. (Source:ITU-R Ad Hoc (RT-200023)).
Document for: Action.
Abstract: For 3GPP review: in: TSG RAN feedback LS before: March 19, 2020 to: TSG SA in: TSG SA feedback LS before: March 20, 2020 to: 3GPP PCG.

Comment:

For Endorsement and forwarding to PCG. Proposed action: Endorsed. Endorsed.

Discussion and conclusion:

For Endorsement and forwarding to PCG. Proposed action: Endorsed. Note: the SA related content of this LS was endorsed, it is reflected by the endorsed RAN version of this LS, which got forwarded to PCG.

Status:

Endorsed.

TD SP-200264 (LS OUT) [DRAFT] LS on need for Multi-Path QUIC for ATSSS. (Source:Apple, Broadcom, Deutsche Telekom AG, ZTE).
Document for: Approval.
Abstract: TSG SA kindly requests IETF to take the above information into account when discussing future work in prioritizing the multipath work for QUIC.

Comment:

Approved. Revised to remove draft in SP-200289.

Discussion and conclusion:

Status:

Revised.

TD SP-200289 (LS OUT) LS on need for Multi-Path QUIC for ATSSS. (Source:TSG SA).
Document for: Approval.
Abstract: To: IETF. CC: SA WG2. Attachments: SP-200095.

Convenor comment:

Comment:

Revision of SP-200264. Approved.

Parallel:

Status:

Approved.

TD SP-200276 (LS IN) LS from ATIS IoT Group. (Source:ATIS IoT Group (03122020_liason to 3GPP)).
Document for: Action.
Abstract: ATIS would like to inform TSG SA that, on January 8, it sent the attached LS (S2-2001786) asking SA WG2 to '…review the whitepaper on 'IoT Categorization: Exploring the Need for Standardizing Additional Network Slices' and provide us with feedback at your earliest convenience, but no later than February 7, 2020. Further action (e.g., CRs) will be taken by Individual Member companies in SA WG2#137.' ATIS understands that SA WG2 could not agree on a response to the LS in either SA WG2#137 or the SA WG2#137E meetings. After consulting the SA WG2 Chairman, ATIS Individual Members submitted proposals to address the ATIS request for the addition of a new Slice Service Type (SST) for HighPerformance Machine-Type Communications (HMTC) as a new 'TEI17 style' WID and liaise with GSMA NEST for capturing the corresponding KPIs in NG.116. The proposal was not agreed due to objection from a single company despite overwhelming support by a number of companies. ATIS is requesting an update on the status of its request for feedback from 3GPP. ATIS would also welcome further suggestions on how it may collaborate with 3GPP on this important topic. Action: TSG SA to provide advice on how to proceed with the allocation of Service Type (SST) for High-Performance Machine-Type Communications (HMTC).

Comment:

Response drafted in SP-200272. Proposed action: Consider response. Final response in SP-200290.

Discussion and conclusion:

Patrice proposes to either postpone or alternatively give a response as outlined in the mail. Tue16:05. Haris requests to go forward with the reply in this meeting as proposed Tue17:34. Final response in SP-200290.

Status:

Replied to.

TD SP-200272 (LS OUT) [DRAFT] Reply LS to ATIS IoT Group. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: Reply LS to ATIS IoT Group.

Comment:

Response to SP-200276. SP-200272_rev3 Approved. Revised to SP-200290.

Discussion and conclusion:

Patrice proposes to note this document - objects to content. Provides alternative content in case LSout is needed Tue16:05/Tue16:06. Haris requests to go forward with the reply in this meeting as proposed Tue17:34. -- ongoing discussion. Revision provided by Haris Wed13:10. Gerald (Matrixx) proposes smaller modifications Wed14:31. Revision rev3 provided by Haris Wed19:18. SP-200272_rev3 Approved.

Status:

Revised.

TD SP-200290 (LS OUT) Reply LS to ATIS IoT Group. (Source:TSG SA).
Document for: Approval.
Abstract: To: ATIS IoT Group, GSMA 5GJA. CC: SA WG2. Attachments: S2-2001786.

Convenor comment:

Comment:

Revision 3 of SP-200272. Approved.

Parallel:

Status:

Approved.

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

4.1 SA WG1 reporting

TD SP-200120 (REPORT) SA WG1 Report to TSG SA#87-e. (Source:SA WG1 Chairman).
Document for: Information.
Abstract: SA WG1 Report to TSG SA#87-e.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

4.2 SA WG2 reporting

TD SP-200059 (REPORT) SA WG2 Chairmans report to TSG SA#87E. (Source:SA WG2 Chairman).
Document for: Presentation.
Abstract: Report to SA WG2 Activities.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

4.3 SA WG3 reporting

TD SP-200132 (REPORT) SA WG3 Status report. (Source:SA WG3 Chairman).
Document for: Information.
Abstract: SA WG3 Status report.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

4.4 SA WG4 reporting

TD SP-200032 (REPORT) SA WG4 Status Report at TSG SA#87. (Source:SA WG4 Chairman).
Document for: Presentation.
Abstract: SA WG4 Status Report at TSG SA#87.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

4.5 SA WG5 reporting

TD SP-200218 (REPORT) SA WG5 Status report. (Source:Ericsson LM).
Document for: Information.
Abstract: SA WG5 Status report to TSG SA#87-E.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

4.6 SA WG6 reporting

TD SP-200106 (REPORT) SA WG6 status report to TSG SA#87E. (Source:SA WG6 Chairman).
Document for: Information.
Abstract: SA WG6 status report to TSG SA#87E.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

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

4.8 TSG CT reporting

TD SP-200278 (REPORT) Status report of TSG CT#87-e. (Source:TSG CT Chairman).
Document for: Information.
Abstract: TSG CT Status Report to TSG SA#87E.

Comment:

Noted.

Discussion and conclusion:

Status:

Noted.

6 Work Item Descriptions, Study Item Descriptions, Specifications

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

TD SP-200051 (WID NEW) Ambient noise test methodology for evaluation of acoustic UE performance (ANTeM). (Source:SA WG4).
Document for: Approval.
Abstract: Objective: The goal of this work item is to update clause 5.1.5.1 (Test Setup) of TS 26.132 in order to allow the flexible noise field simulations according to ETSI TS 103 224 for ambient noise testing. The test descriptions in clauses 7.12.1 (NB mode), 8.12.1 (WB mode) and 9.12.1 (SWB mode) only list the binaural noise types and thus does not seem to require additional modifications. However, editorial updates and/or further clarifications may be included in these clauses as well. Since these systems can be used in conjunction with the currently specified binaural noise types, the change is intended as an extension (not as a replacement) for the existing method. At least one suitable loudspeaker setup (4.0 and/or 4.1) should be specified as well. It is not intended to modify or update the performance objectives and/or requirements in TS 26.131.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

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

TD SP-200213 (WI EXCEPTION REQUEST) WI exception request Management of QoE measurement collection. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Exception sheet for Rel-16 Work Item Management of QoE measurement collection. Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200214 (WI EXCEPTION REQUEST) WI exception request CHF-Controlled Quota Management. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Exception sheet for Rel-16 Work Item CHF-Controlled Quota Management Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200150 (WI EXCEPTION REQUEST) Work Item Exception request for eV2X. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: One Face-to-Face meeting is needed to complete the tasks listed in the above table. This work item exception requests to extend the deadline of the SA WG3 eV2X work till June 2020. Contentious Issues: The following issues have been identified: - The security policy handling mechanism when the security policies are different in two peer UEs needs to be clearly defined. - How to securely convert the group ID to the destination ID for protecting privacy in groupcast needs more discussion.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200151 (WI EXCEPTION REQUEST) Work Item Exception for 5G_eSBA. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: At the completion of SA WG3#98e, normative work for several aspects of Rel-16 5G SBA security is still not concluded. The original target completion date for this WID is March 2020. This exception sheet is to request an extension to June 2020. Contentious Issues: 1. Authentication of service requests over indirect communications - there are two scenarios: a) Indirect service requests from consumer NF to NRF via SCP b) Indirect service requests from consumer NF to a producer NF via SCP There is no consensus on whether authentication of service requests over indirect communication can be based on hop by hop authentication at the transport layer. 2. Token based authorization for Model D scenarios (indirect communication with delegated discovery) - this is related to issue #1.a. Once the solution for issue #1.a is agreed, this issue can be resolved accordingly. 3. Access token verification by the producer - there is no consensus on whether additional access token verification by the producer is needed on top of existing procedures for access token verification by the producer. This is related to issue #1.b. 4. Authorization of Subscribe/Notify scenario - there is no consensus on whether additional security mechanisms may be needed for the Subscribe/Notify scenario.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200152 (WI EXCEPTION REQUEST) Work Item Exception request for Security for NR IAB. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: This exception sheet for Security for NR Integrated Access and Backhaul provides a list of remaining open items, which are planned to be completed by June 2020.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200153 (WI EXCEPTION REQUEST) Work Item Exception request for SEAL security aspects. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: This exception sheet for Security for Service Enabler Architecture Layer for Verticals provides a list of remaining open items, which are planned to be completed by June 2020.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200155 (WI EXCEPTION REQUEST) Work Item Exception request of Authentication and key management for applications based on 3GPP credential in 5G. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: This exception sheet for AKMA provides a list of remaining open issues, which are planned to be completed by June 2020. Contentious Issues: Several procedure details have not been concluded, including: - AKMA key identifier generation and routing related procedures; - Application key derivation; - Application key refresh, etc.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200156 (WI EXCEPTION REQUEST) Work Item Exception request for 5WWC. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: This work item intends to specify the security requirements and procedures for 5WWC. This exception sheet is to request an extension to June 2020 for introducing ERP related procedures which aims to align with SA WG2's work.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200157 (WI EXCEPTION REQUEST) Work Item Exception request for CIoT security. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: It is, hereby, requested that an exception to the completion date of 5G CIoT security work is granted, so that remaining contentious issues (below) can be resolved. Contentious Issues: 1. Protection of UE capability transfer procedure for UEs using Control plane CIoT optimization. This will affect 3GPP TS 33.501 and 3GPP TS 33.401. 2. Input parameters to the calculation of shortResumeMAC-I when UE is resuming the RRC connection from a suspended RRC connection. This will affect 3GPP TS 33.501.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200158 (WI EXCEPTION REQUEST) Work Item Exception request Network Slice security. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: Rel-16 Enhanced Network Slice security could not be completed because of outstanding issues yet to be resolved. Copy of draft CR attached. Contentious Issues: 1. Role of AUSF in Network Slice specific authentication and authorization 2. Sending of NSSAI to external AAA-S for Network Slice specific authentication and authorization.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200159 (WI EXCEPTION REQUEST) Work Item Exception request for Security of the enhancement to the 5GC Location Services. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: This work item aims to specify privacy enhancements for WLAN measurements and Bluetooth measurements. This exception sheet requires that the completion time of WI be extended to June 2020 in order to find the best balance between privacy protection and flexible deployment. Contentious Issues: An editor note for both WLAN positioning and Bluetooth positioning still need to be resolved, as shown below. - Editor's Note: Namespace to ensure only beacon information is collected is FFS. There is no consensus on namespace matching patterns and privacy protection policy.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200160 (WI EXCEPTION REQUEST) Work Item exception Mission Critical security. (Source:SA WG3).
Document for: Approval.
Abstract: Abstract of document: It is estimated that one additional meeting cycle is required to complete the tasks for Rel-16 mission critical security enhancements. This work item exception requests a deadline extension for Rel-16 MCXSec until June 2020. Contentious Issues: - MCData message store server access security is not defined. - MCData message store server SIP/HTTP communications between MCData message store client and message store server is not defined. - MCData message store server SIP/HTTP communications between MCData service server and MCData message store server is not defined. - Off-network security for protection of MONP signalling identities is not defined. - Interworking key management for groups needs to be re-evaluated and possibly moved from GMS to KMS.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200185 (WID REVISED) Revised WID for MA5SLA. (Source:SA WG5).
Document for: Approval.
Abstract: Updates objectives and impacted Specs.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200200 (WI EXCEPTION REQUEST) WI Exception request for Network Slice Management Charging in 5GS. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Exception sheet for Rel-16 Work Item Network Slice Management Charging in 5G System Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200201 (WI EXCEPTION REQUEST) WI Exception request Closed loop SLS Assurance. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Objective: The objective of this work item is to specify a closed loop assurance solution that helps an operator to continuously deliver the expected level of communication service quality. The closed loop assurance solution allows an operator to create a closed loop management service that automatically adjusts and optimizes the services provided by NG-RAN and 5GC based on the various performance management and QoE input data, and the state of the 5G network, using data analytics. Contentious Issues: No contentious issues.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200202 (WI EXCEPTION REQUEST) WI Exception request Charging Access Traffic Steering, Switching and Splitting in 5G system architecture. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Exception sheet for Rel-16 Work Item Charging Access Traffic Steering, Switching and Splitting in 5G system architecture Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200203 (WI EXCEPTION REQUEST) WI Exception request 5WWC charging. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Exception sheet for Rel-16 Work Item Charging Aspect for 5WWC Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200204 (WI EXCEPTION REQUEST) WI exception request Network Slice performance and Analytics Charging in 5GS. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Exception sheet for Rel-16 Work Item Network Slice performance and analytics charging in 5G System Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200044 (WI EXCEPTION REQUEST) E_FLUS exception request. (Source:SA WG4).
Document for: Approval.
Abstract: 5GMSA Updates needed to finalise TS 26.501.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200045 (WI EXCEPTION REQUEST) 5GMS3 exception request. (Source:SA WG4).
Document for: Approval.
Abstract: Abstract of document: A Release-16 exception is being sought for two of the three new specifications being produced in the 5GMS3 work item. Contentious Issues: Whether support for video format HEVC FullHD is to be mandated or recommended.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200205 (WI EXCEPTION REQUEST) WI exception request Energy efficiency of 5G. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: This document is the Exception request for Rel-16 Work Item 'Energy efficiency of 5G (EE_5G)'. Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200206 (WI EXCEPTION REQUEST) WI exception request Trace Management in the context of Services Based Management Architecture. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: This document is the Exception request for Rel-16 Work Item 'Trace Management in the context of Services Based Management Architecture' Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200207 (WI EXCEPTION REQUEST) WI exception request Streaming trace reporting. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: This document is the Exception request for Rel-16 Work Item 'Streaming trace reporting' Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200208 (WI EXCEPTION REQUEST) WI exception request Enhancement of 3GPP management system for multiple tenant environment support. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: This document is the Exception request for Rel-16 Work Item 'Enhancement of 3GPP management system for multiple tenant environment support'. Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200209 (WI EXCEPTION REQUEST) WI exception request Enhancement of performance assurance for 5G networks including network slicing. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: This document is the Exception request for Rel-16 Work Item 'Enhancement of performance assurance for 5G networks including network slicing (5G_SLICE_ePA)'. Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200210 (WI EXCEPTION REQUEST) WI exception request Discovery of management services in 5G. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Task(s) within work which are not complete: Stage 2 and Stage 3 work based on MnS producer profile concept. Consequences if not included in Release 16: Management services in 5G will not be discoverable in standardized way.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200211 (WI EXCEPTION REQUEST) WI exception request Self-Organizing Networks (SON) for 5G networks. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: The completion of this WI depends on the following information that are not yet specified in TS 38.331 and TS 38.300: - The UE information needed for the performance measurements definition. - Normative solutions for SON features, as described in TR 37.816.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200212 (WI EXCEPTION REQUEST) WI exception request NRM enhancements. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: Exception sheet for Rel-16 Work Item NRM Enhancements Contentious Issues: None.

Comment:

Block3 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

6.3 New Release 17 Study Item Descriptions

TD SP-200238 (SID NEW) Feasibility Study on Multicast Architecture Enhancements for 5G Media Streaming. (Source:TELUS).
Document for: Approval.
Abstract: Objective: The goal of this study item is to identify and evaluate potential enhancements to the 5G Media Streaming Architecture to provide multicast-broadcast media streaming services. The FS_5GMS_Multicast study has the objectives as follows: - Define collaboration scenarios where multicast ingestion or multicast distribution might be used, including potential IGMP termination options. Examples for such collaboration scenarios are transparent multicast delivery, multicast linear IPTV delivery, hybrid unicast/multicast (e.g. MooD or service continuity) and multicast ABR OTT live streaming. - Identify the relevant key issues and gaps in 5GMS to support the above collaboration scenarios based on the existing 5GS multicast architecture. - Document potential architecture extensions and procedures to support the above-defined scenarios. - Identify potential protocols to support the above extensions and procedures in 5GMS. - Identify Procedures for managing downlink multicast streaming and session lifecycle. - Select a subset of relevant collaboration scenarios that should be supported in extensions to 5G Media Streaming. The work should be carried out taking into account existing relevant multicast standards and architectures, such as TS 23.316, DVB BlueBook A176 , and CableLabs.

Comment:

Proposed revision of SP-200055. Approved.

Discussion and conclusion:

Shifted from 6.1 due to being R17 SID, based on SA WG4 Chairman request.

Status:

Approved.

TD SP-200055 (SID NEW) Feasibility Study on Multicast Architecture Enhancements for 5GMSA (FS_5GMS_Multicast). (Source:SA WG4).
Document for: Approval.
Abstract: Objective: The goal of this study item is to identify and evaluate potential enhancements to the 5G Media Streaming Architecture to provide multicast-broadcast media streaming services. The FS_5GMS_Multicast study has the objectives as follows: - Define collaboration scenarios where multicast ingestion or multicast distribution might be used, including potential IGMP termination options. Examples for such collaboration scenarios are transparent multicast delivery, multicast linear IPTV delivery, hybrid unicast/multicast (e.g. MooD or service continuity) and multicast ABR OTT live streaming. - Identify the relevant key issues and gaps in 5GMS to support the above collaboration scenarios based on the existing 5GS multicast architecture. - Document potential architecture extensions and procedures to support the above-defined scenarios. - Identify potential protocols to support the above extensions and procedures in 5GMS. - Identify Procedures for managing downlink multicast streaming and session lifecycle. - Select a subset of relevant collaboration scenarios that should be supported in extensions to 5G Media Streaming. The work should be carried out taking into account existing relevant multicast standards and architectures, such as TS 23.316, DVB BlueBook A176 , and CableLabs.

Comment:

Proposed update in SP-200238. Considered as revised in SP-200238.

Discussion and conclusion:

Shifted from 6.1 due to being R17 SID, based on SA WG4 Chairman request. Considered as revised in SP-200238.

Status:

Revised.

TD SP-200052 (SID NEW) Feasibility Study on 5G Video Codec Characteristics (FS_5GVideo). (Source:SA WG4).
Document for: Approval.
Abstract: Objective: Based on these discussions, the objectives of the study item are primarily to identify relevant interoperability requirements, performance characteristics and implementation constraints of video codecs in 5G services, and to characterize existing 3GPP video codecs, in particular H.264/AVC and H.265/HEVC in order to have a benchmark for the addition of potential future video codecs. The concrete objectives are as follows: - Collect a subset of relevant scenarios for video codecs in 5G-based services and applications, including video formats (resolution, frame rates, color space, etc.), encoding and decoding requirements, adaptive streaming requirements, predominantly based on scenarios defined for 5G media streaming as well as for TR 26.925 and TR 26.928. - Collect relevant and exemplary test conditions and material for such scenarios, including test sequences. - Define performance metrics for such scenarios with focus on objective performance metrics. - Collect relevant interoperability functionalities and enabling elements for video codecs in different 5G services such as MTSI and Telepresence (i.e. RTP based conversational communications), or 5G media streaming (e.g. based on DASH/CMAF) supporting the identified scenarios. - Collect relevant criteria and key performance indicators for the integration of video codecs in 5G processing platforms, taking into account factors such as encoding and decoding complexity in the context of the defined scenarios. - Characterize the existing codecs H.264/AVC and H.265/HEVC in the context of the above scenarios and document the findings in a consistent manner. - Identify gaps and deficiencies of existing codecs in such use cases and derive requirements for potential new codecs. - Collect initial information on how new codecs under development in ISO/IEC SC29 WG11 (MPEG)/JVET (in particular including VVC and EVC) may meet the above criteria based on the characterization results provided for example by ISO/IEC SC29 WG11 (MPEG)/JVET.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Shifted from 6.1 due to being R17 SID, based on SA WG4 Chairman request.

Status:

Approved.

TD SP-200053 (SID NEW) Study on the use of NBMP in EFLUS (FS_FLUS_NBMP). (Source:SA WG4).
Document for: Approval.
Abstract: Objective: Based on the above justification, the main objective of the study item is to identify the workflow for NBMP media processing with the TS26.238. Such workflow should start from a request for the establishment of a FLUS session and then include the instantiation, running and monitoring of media processing application requested by FLUS source on a FLUS sink. The concrete objectives are as follows: - Develop a detailed workflow of the establishment of FLUS session and NBMP workflow based on TS26.238. - Investigate if any signalling, format or protocol is missing from the TS26.238 and NBMP specifications to successfully establish the above workflow. - Collect relevant and exemplary use-cases for the above environment. - Map 3GPP network QoS parameters to the NBMP QoS parameters and identify the possible missing QoS parameters in the NBMP specification. - Investigate the possible improvements and extensions of the workflow by enhancing TS26.238 and NBMP specifications.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Shifted from 6.1 due to being R17 SID, based on SA WG4 Chairman request.

Status:

Approved.

TD SP-200054 (SID NEW) Feasibility Study on Typical Traffic Characteristics for XR Services and other Media (FS_XRTraffic). (Source:SA WG4).
Document for: Approval.
Abstract: Objective: Based on the above considerations, the objective of this work is as follows: - Collect and document traffic characteristics including for different services, but not limited to o Downlink data rate ranges o Uplink data rate ranges o Maximum packet delay budget in uplink and downlink o Maximum Packet Error Rate, o Maximum Round Trip Time o Traffic Characteristics on IP level in uplink and downlink in terms of packet sizes, and temporal characteristics. XR Services and Cloud Gaming based on the initial information documented in TR26.928 including. - Collect additional information, such as codecs and protocols in use. - Provide the information from above at least for the following services (initial services) o Viewport independent 6DoF Streaming o Viewport dependent 6DoF Streaming o Simple Single Buffer split rendering for online cloud gaming o Cloud gaming o MTSI-based XR conversational services - Identify additional relevant XR and other media services and document their traffic characteristics - Document additional developments in the industry that impact traffic characteristics in future networks - Identify the applicability of existing 5QIs/PQIs for such services and potentially identify requirements for new 5QIs/PQIs or QoS related parameters. - Communicate with other 3GPP groups and external organizations on relevant aspects related to the study.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Shifted from 6.1 due to being R17 SID, based on SA WG4 Chairman request.

Status:

Approved.

TD SP-200056 (SID NEW) New SID on Streaming Architecture extensions For Edge processing (FS_EMSA). (Source:SA WG4).
Document for: Approval.
Abstract: Objective: The study item will investigate the following issues: - determine the processes for discovering, configuring, running, and managing media processing workflows on the 5G edge and network - study the mapping of the new processes into the 5GMSA architecture - how to leverage architecture and functions defined by SA WG2 and SA WG6 for edge computing and applications - Validate the architecture extensions against the identified key use cases and recommendations from XR5G and E-FLUS (e.g. split rendering, VR stitching) - document architectural extensions for edge media processing to support other 5GMSA features such as: o Online gaming, Ad insertion, hybrid DASH/HLS services based on CMAF.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Shifted from 6.1 due to being R17 SID.

Status:

Approved.

TD SP-200187 (SID NEW) New SID New areas on EE for 5G networks. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective is to study (non-exhaustive list): - the definition of new EE KPIs, and means to measure them - in case of multi-RAT sites; - in case of 5G RAN sharing; - for 5G Core Network and, in particular, for 5GC Control Plane network functions; - for standardized network slice types (eMBB, URLLC, mIoT, V2X), - the definition of the Energy Consumption (EC) of a VNF, and means to measure it - if any comparison can be done between SNPN and PNI-NPN from an EE perspective - cross-WGs/SDOs issues related to energy efficiency / saving.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200195 (SID NEW) New SID on edge computing management. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objectives are to: - Study the use cases, requirements, and solutions on the enhancements of the management of edge computing, including: o The lifecycle management of EAS, EES and ECS needed to support edge computing, by taking into account the various deployment scenarios. o Deployment and provisioning of 5GC network functions needed to support the edge computing. o Provisioning of EES, and ECS needed to support edge computing. o Performance assurance of EES, ECS and relevant 5GC functions needed to support edge computing. o Fault supervision of EES, ECS and relevant 5GC functions needed to support edge computing. o Mechanism(s) to enable and support EAS deployment on a particular edge data network. o Mechanism(s) to enable and support ? ECSP to deploy and manage EES and ECS. ? ASP to deploy and manage EAS. o Studying the need of providing management provisions to create and manage communication service(s) at a particular edge data network. Note: The scope of EAS may be limited to certain areas, such as LCM, provisioning. This work will reuse generic management services, and take into account the works being done in SA WG2, SA WG6, ETSI MEC ISG, and ETSI NFV ISG.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

6.4 New Release 17 Work Item Descriptions

TD SP-200219 (DISCUSSION) Support for non-3GPP access to SNPN service as TEI17 WID. (Source:Charter Communications, INTEL, Motorola Mobility, Lenovo, Convida Wireless, Apple, Sennheiser, Broadcom, Interdigital, Philips).
Document for: Agreement.
Abstract: TEI17 proposal in SA WG2 can also be considered for a previously discussed self-contained Work-Task (WT) at SA#86, as long as it fits the requirements stated in TR 21.900.

Comment:

Proposed Action: Noted (maybe with some guidance in the meeting minutes). Noted. Guidance for SA WG3 included in minutes.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Curt (Charter) TEI17 can introduce items which were de-prioritized R17 WTs. Tue16:52. Noted with Guidance for SA WG3 included in minutes.

e-mail discussion:

Text for guidance/minutes: SA#87E understands that SA WG2#138E e-meeting will be the last meeting to submit new TEI17 proposals. SA WG2 can also consider TEI17 proposal for a previously discussed/de-prioritized self-contained Work-Task (WT) at SA#86, as long as the proposal satisfy the TEIxx requirements (as defined in clause 6.2 of TR 21.900).As usual any proposed WID requires 4 supporting companies and consensus.

Status:

Noted.

TD SP-200220 (WID NEW) New WID on Support for non-3GPP access to SNPN services. (Source:Charter Communications, INTEL, Motorola Mobility, Lenovo, Convida Wireless, Apple, Sennheiser, Broadcom, Interdigital, Philips).
Document for: Information.
Abstract: TEI17 proposal for re-consideration. For information only. This is related to the discussion paper in SP-200219.

Comment:

Proposed Action: Postponed. Noted.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Noted.

Status:

Noted.

TD SP-200084 (WID NEW) New WID: IMS Optimization for HSS Group ID in an SBA environment (TEI17). (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870003, Suggested acronym: TEI17_IMSGID).

Comment:

Proposed revision in SP-200257 Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Erik (Samsung) asks to add enhanced feature WID in 2.3 (Tue12:58). Postponed.

Status:

Postponed.

TD SP-200257 (WID NEW) New WID: IMS Optimization for HSS Group ID in an SBA environment (TEI17). (Source:Ericsson).
Document for: Approval.
Abstract: (UID: 870003, Suggested acronym: TEI17_IMSGID).

Comment:

Revision of SP-200084 Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Postponed.

Status:

Postponed.

TD SP-200085 (WID NEW) New WID: Support for Signed Attestation for Priority and Emergency Sessions (TEI17). (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870004, Suggested acronym: TEI17_SAPES).

Comment:

Proposed revision in SP-200258 Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- Postponed.

Status:

Postponed.

TD SP-200258 (WID NEW) New WID: Support for Signed Attestation for Priority and Emergency Sessions (TEI17). (Source:Ericsson).
Document for: Approval.
Abstract: (UID: 870004, Suggested acronym: TEI17_SAPES).

Comment:

Revision of SP-200085 Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Postponed.

Status:

Postponed.

TD SP-200082 (WID NEW) New WID: Enhancement to the 5GC Location Services - Phase 2. (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870001, Suggested acronym: 5G_eLCS_Ph2).

Comment:

This is a conversion of SID SP-190452 to a WID. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200083 (WID NEW) New WID: Stage 2 of Multimedia Priority Service (MPS) Phase 2. (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870002, Suggested acronym: MPS2_St2).

Comment:

This is a conversion of SID SP-190629 to a WID. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200086 (WID NEW) New WID: Dynamically Changing AM Policies in the 5GC (TEI17). (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870005, Suggested acronym: TEI17_DCAMP).

Comment:

Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Erik (Samsung) asks to add enhanced feature WID in 2.3 (Tue12:58). Postponed.

Status:

Postponed.

TD SP-200087 (WID NEW) New WID: IP address pool information from UDM (TEI17). (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870006, Suggested acronym: TEI17_IPU).

Comment:

Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Erik (Samsung) asks to add enhanced feature WID in 2.3 (Tue12:58). Postponed.

Status:

Postponed.

TD SP-200088 (WID NEW) New WID: Dynamic management of group-based event monitoring (TEI17). (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870007, Suggested acronym: TEI17_GroupEventMont).

Comment:

Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Postponed.

Status:

Postponed.

TD SP-200089 (WID NEW) New WID: Support of different slices over different Non 3GPP access (TEI17). (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870008, Suggested acronym: TEI17_N3SLICE).

Comment:

Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Erik (Samsung) asks to add enhanced feature WID in 2.3 (Tue12:58). Postponed.

Status:

Postponed.

TD SP-200090 (WID NEW) New WID: N7/N40 Interfaces Enhancements to Support GERAN and UTRAN (TEI17). (Source:SA WG2).
Document for: Approval.
Abstract: (UID: 870009, Suggested acronym: TEI17_NIESGU).

Comment:

Proposed Action: Postponed. Postponed.

Discussion and conclusion:

Johannes (DT) proposes to shift approval to June Plenary (mail Tue11:08). Haris (Qualcomm) proposes to endorse rather than approve (mail Tue12:06). Krister (Ericsson) proposes to approve (mail Tue13:19). -- ongoing discussion. Postponed.

Status:

Postponed.

TD SP-200146 (WID NEW) New WID on Security Assurance Specification for Non-3GPP InterWorking Function (N3IWF). (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The objective is to develop the Security Assurance Specification (SCAS) for the Non-3GPP InterWorking Function (N3IWF) network product class: - identify threats and critical assets of the N3IWF network product class not already identified in TR 33.926 - develop and/or adopt N3IWF specific security functional requirements and related test cases - identify and develop N3IWF specific basic vulnerability testing requirements and related test cases This new work item assumes that the network element is not based on virtualization architecture.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200147 (WID NEW) New WID on Security Assurance Specification for 5G NWDAF. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The objective is to develop the Security Assurance Specification(s) (SCAS) for the NWDAF network product class: - identify threats and critical assets to the NWDAF not already identified in TR 33.926 - develop and/or adapt NWDAF specific security functional requirements and related test cases - develop and/or adapt NWDAF specific basic vulnerability testing requirements and related test cases.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200148 (WID NEW) New WID on Security Assurance Specification for Service Communication Proxy (SECOP). (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The objective is to develop the Security Assurance Specification (SCAS) for the Service Communication Proxy (SECOP) network product class, with the aims to: - identify critical assets and threats of the SECOP network product class not already identified in TR 33.926 - develop and/or adapt SECOP specific security functional requirements and related test cases - develop and/or adapt SECOP specific basic vulnerability testing requirements and related test cases This new work item assumes that the network element is not based on virtualization architecture.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200149 (WID NEW) New WID for 5G SCAS Enhancement. (Source:SA WG3).
Document for: Approval.
Abstract: Objective: The aim is to update 5G SCAS with new 5G R16 features. Specifically, the objectives of this work item are to: - identify threats and critical assets for 5G R16 features not already identified in TR 33.926; - identify specific security functional requirements and related test cases for 5G R16 features in 5G SCAS documents; - develop more vulnerability testing requirements and related test cases if deemed necessary; - adopt corrections or potential new security assurance requirements identified during the course of testing practice of 5G SCAS R16; - Align with GSMA NESAS specifications on some aspects when the NESAS documents are developing; This work item assumes that the SCAS will be independent of whether the NF is based or not based on virtualization architecture. Impact of virtualization is covered in separate work.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200188 (WID NEW) New WID Enhancements on EE for 5G networks. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective is to: - address the cross-WGs/SDOs issues related to energy efficiency / saving, for the purpose of coordination on energy saving; - provide OA&M solutions where applicable, to requirements expressed by other 3GPP working groups; - introduce use cases and solutions in existing TSs, once they have been studied in the companion study item mentioned in clause 2.3; - define new EE KPIs, and means to measure them: o in case of multi-RAT sites, o in case of 5G RAN sharing, o for 5G Core Network and, in particular, for 5GC control plane network functions, o for standardized network slice types (eMBB, URLLC, etc.).

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200189 (WID NEW) New WI on management of non-public networks. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objectives of this work item are to support management of NPN (which may be deployed as SNPN or PNI-NPN) with the following functionality, in line with NPN functionality as defined by SA WG1, SA WG2 and RAN WG3/2: - Specify management requirements to align with SA WG1 service level requirements - Specify deployment scenarios for management of NPN, mainly includes the three typical cases as 1) Verticals independently manage NPN which is deployed by themselves 2) PLMN operator independently manages NPN which provides services to verticals 3) PLMN operator manages NPN with exposure of management capabilities to verticals as customer of the NPN - Specify the model for roles related to NPN management. - Provisioning of SNPN and PNI-NPN, such as isolation and specific SLA management for local deployments of NPNs in factories, enterprises and buildings to provide coverage within a specific geographic area. - Exposure of management services and management data related to NPN, such as local area based exposure of management services for network level and service level, and the corresponding performance measurements and/or KPIs. This work item will need to take 5G ACIA deployment scenarios and SA WG1 requirements into account, coordinate with SA WG2/ RAN WG3 with solutions and may need to cooperate with relevant standard groups and industry fora when needed.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200190 (WID NEW) New WID Enhancement on Management Aspects of 5G Service-Level Agreement. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: This work item aims to discussion the following aspects: - Continue the work of SLA management in R-16 include translating SLA requirements to network ServiceProfile, e.g. providing the Correspondence between GSMA GST/NEST and 3GPP ServiceProfile. - Continue this efforts on cooperation with GSMA and SA WG1, SA WG2, RAN to update potential SLA requirements for supporting various services like mMTC and V2X. - - Procedure of translation once SLA has been introduced to 5G management system and document SLA effects on existing and new procedures.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200191 (WID NEW) New WID on management of MDT enhancement in 5G. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: To specify: - Outstanding items from SA WG5 WI in Rel. 16: o MDT measurement configuration and reporting in a RAN split architecture - Management of Enhancement of logged and immediate MDT specified by RAN WG2 and RAN WG3 - MR-DC related MDT configuration and reporting specified by RAN WG2 and RAN WG3. o EN-DC is already supported in release 16. In release 17, support for NR as master node and LTE/NR as secondary will be included. - MDT reporting o Enhancement of reporting and internode communication specified in RAN WG2 and RAN WG3, e.g. RLF and accessibility measurements, Successful Handover reporting.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200192 (WID NEW) New WID on Additional NRM features. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: - Enhance NRM to support NR and 5GC features in Rel-17 and Rel-16, including further enhancement on MIMO for NR, architecture enhancements for the support of Integrated access and backhaul, 5G System Enhancement for Advanced Interactive Services and further Multi-RAT Dual-Connectivity enhancements. - Continue leftover of Rel16 NRM, including NR_CLI_RIM related attributes, 5G_eSBA related attributes, stage 3 enhancement and generic NRM enhancement.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200193 (WID NEW) New WID on Enhancement of QoE Measurement Collection. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective of the work item is to: - Complete the leftovers from the Rel-16 work item Management of QoE measurement collection: Signalling Based Activation in UMTS and LTE. - Include VR QoE. - Specify QoE Measurement Collection in NR.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200194 (WID NEW) New WID on Self-Organizing Networks (SON) for 5G networks. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objectives are to: - Specify the use cases, requirements, management services, and procedures for the following SON functions; - Self-establishment of 3GPP NF, including automated software management, Automatic Network Configuration Data Handling, - Centralized Capacity and Coverage Optimization - Load Balancing Optimization - NSI resource allocation optimization - Enhance the 5G NRM, performance measurements, and fault supervision services needed to support 5G SON. This work may require cooperation with RAN WGs and SA WG2 WG.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200196 (WID NEW) New WID on Enhanced Closed loop SLS assurance. (Source:SA WG5).
Document for: Approval.
Abstract: Objective: The objective of this work item is to specify a closed loop assurance solution that supports a service provider to continuously deliver the expected level of communication service quality. The closed loop assurance solution allows a service provider to create a closed loop management service that automatically adjusts and optimizes the services provided by NG-RAN and 5GC based on the various performance management and QoE input data, and the state of the 5G network, using data analytics provided by a MDAS (e.g. report on e2e latency analysis). To be able to deploy SLS assurance solution number of areas need to be addressed: 1. add new service assurance management related use cases and requirements according to deployment, assurance aspects. 2. describe the data, the management service can provide to the CN. 3. describe the solution realizing the management service for efficient data collection and exposure of coordination of the collection from RAN and CN 4. describe management of the management functions involved in SLS assurance loops, including configuration of data analytic functions, e.g. setting thresholds for prediction accuracy. 5. describe how to apply the ML models of MDA to closed loop SLS assurance. 6. describe procedures and artefacts applicable to design phase of closed loops in relation to the deployment of closed loops 7. describe the association between the following concepts, such as: service user experience, service optimization, service assurance and intent driven management 8. enhance the descriptions on closed loop and related interactions which are important for service assurance 9. describe new information in NRM and new measurements and KPIs which support the service assurance.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200108 (WID NEW) New WID on Enhanced Mission Critical Push-to-talk architecture phase 3. (Source:SA WG6).
Document for: Approval.
Abstract: Objective: The objectives include: 1. Review and identify requirements from Stage 1, which are applicable to MCPTT, and have yet to be fully supported by the MCPTT functional architecture and information flows. This includes items (a) through (g) in clause 3 - Justification. 2. Analyze the MCPTT architecture to identify those architectural aspects that have not been fully specified. 3. For those architectural aspects identified in objectives (1) and (2): - Specify the MCPTT architectural requirements, procedures, information flows, and configuration parameters as needed. - Where the underlying requirements support solutions that are applicable to other MC services (MCVideo, MCData), specify these solutions such that they can be applied to these other services. This work item will build upon the stage 2 architecture developed for Release 16, and provide for backward compatibility. Stage 2 architecture for MCPTT is contained both in 3GPP TS 23.280 and 3GPP TS 23.379. NOTE: Coordination with eMONASTERY2 will be done to prevent any overlap.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

6.5 Revised Release 17 Study Item and Work Item Descriptions

TD SP-200221 (DISCUSSION) Clarification on supporting service continuity for UE-to-Network Relay. (Source:OPPO, CATT).
Document for: Decision.
Abstract: This contribution introduces the supporting service continuity for UE-to-Network Relay discussion background in SA WG2 and ask SA plenary to clarify on this aspect.

Comment:

Proposed Action: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200239 (SID REVISED) Revised SID: Study on System enhancement for Proximity based Services in 5GS. (Source:CATT, OPPO).
Document for: Approval.
Abstract: The SID (SP-190443) is revised based on endorsed FS_5G_ProSe Work Task (SP-191371) at SA#86.

Comment:

Proposed revision of SP-190443. Postponed with Text for the meeting minutes.

Discussion and conclusion:

Guillaume (Mediatek) objects to the current version of the ProSe SID. Fr08:32. Proposed Action: Postponed. _rev1 provided in drafts folder, which is agreeable by several parties. Krister indicates concerns with _rev1. Alessio (Nokia) objects to the _rev1 (still only in drafts folder). Postponed with Text for the meeting minutes.

e-mail discussion:

Text for the meeting minutes: There is no consensus whether the support of service continuity for UE-to-Network Relay is to be de-scoped from Rel-17 FS_5G_ProSe SID (as per WT paper endorsed at SA#86) and it will be resolved in the future SA WG2/SA (e)-meetings. SA WG2 can try to get to improve the ProSe SID and if possible also resolve this issue in Q2 if there is time; If at SA#88 we are still in the same situation, SA#88 will take a decision (e.g. go for a Working Agreement if necessary). As we don't know yet the nature of SA#88 (f2f/e-meeting), the way to reach this decision will be announced over the next weeks.

Status:

Postponed.

TD SP-200091 (SID REVISED) Revised SID: Study on system enablers for multi-SIM devices. (Source:SA WG2).
Document for: Approval.
Abstract: Updates dependant WIs, Objectives and timescales.

Comment:

Revision of SP-190248. Block2 - Proposed: approved. SP-200091_rev1 approved. Revised to SP-200297.

Discussion and conclusion:

SP-200091_rev1 approved.

Status:

Revised.

TD SP-200297 (SID REVISED) Revised SID: Study on system enablers for multi-SIM devices. (Source:SA WG2).
Document for: Approval.
Abstract: Updates dependant WIs, Objectives and timescales.

Convenor comment:

Comment:

Revision 1 of SP-200091. Approved.

Parallel:

Status:

Approved.

TD SP-200092 (SID REVISED) Revised SID: Architectural enhancements for 5G multicast-broadcast services. (Source:SA WG2).
Document for: Approval.
Abstract: Updates justification and objectives.

Comment:

Revision of SP-190625. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200093 (SID REVISED) Revised SID: Study on enhancement of support for Edge Computing in 5GC. (Source:SA WG2).
Document for: Approval.
Abstract: Updates justification, objectives and timescales.

Comment:

Revision of SP-190185. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200094 (SID REVISED) Revised SID: Study on enhanced support of Non-Public Networks. (Source:SA WG2).
Document for: Approval.
Abstract: Updates justification, objectives and timescales.

Comment:

Revision of SP-190453. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200095 (SID REVISED) Revised SID: Study on Access Traffic Steering, Switch and Splitting support in the 5G system architecture Phase 2. (Source:SA WG2).
Document for: Approval.
Abstract: Updates objectives and timescales.

Comment:

Revision of SP-190558. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200096 (SID REVISED) Revised SID: Study on enhanced support of Industrial IoT. (Source:SA WG2).
Document for: Approval.
Abstract: Updates justification, objectives and timescales.

Comment:

Revision of SP-190932. Block2 - Proposed: approved. SP-200096_rev2 approved. Revised to SP-200298.

Discussion and conclusion:

Johannes (DT): could MCC correct the name of Deutsche Telekom on the cover? Wed11:59. Revision provided by Miikka. LaeYoung requests further small change. Thu09:35. _rev2 provided by Miikka. SP-200096_rev2 approved.

Status:

Revised.

TD SP-200298 (SID REVISED) Revised SID: Study on enhanced support of Industrial IoT. (Source:SA WG2).
Document for: Approval.
Abstract: Updates justification, objectives and timescales.

Convenor comment:

Comment:

Revision 2 of SP-200096. Approved.

Parallel:

Status:

Approved.

TD SP-200097 (SID REVISED) Revised SID: Study on supporting Unmanned Aerial Systems Connectivity, Identification, and Tracking. (Source:SA WG2).
Document for: Approval.
Abstract: Updates objectives.

Comment:

Revision of SP-181114. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200098 (SID REVISED) Revised SID: Study on Enablers for Network Automation for 5G - phase 2. (Source:SA WG2).
Document for: Approval.
Abstract: Updates objectives and timescales.

Comment:

Revision of SP-190557. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200109 (WID REVISED) Revised WID on Architecture for enabling Edge Applications. (Source:SA WG6).
Document for: Approval.
Abstract: Updates supporting companies.

Comment:

Block2 - Proposed: approved . Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200110 (SID REVISED) Revised SID on enhancements to application layer support for V2X services. (Source:SA WG6).
Document for: Approval.
Abstract: Updates timescales.

Comment:

Block2 - Proposed: approved . Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200111 (SID REVISED) Revised SID on Study on application layer support for UAS service. (Source:SA WG6).
Document for: Approval.
Abstract: Updates timescales and supporting companies.

Comment:

Block2 - Proposed: approved . Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200216 (DISCUSSION) FS_5G_ProSe: Way Forward. (Source:MediaTek Inc. et al.).
Document for: Approval.
Abstract: Way forward on FS_5G_ProSe.

Comment:

Proposed Action: Noted. Noted.

Discussion and conclusion:

Haris (Qualcomm) objects to this proposal. Wed18:32. Shabnam (Ericsson) objects as well. Wed23:40. Sangsoo (Samsung) also objects. Thu11:49. Dario (Huawei) indicates that in order to clarify the objecting parties' view, a revised SID would be needed. Thu11:26. Saso (Intel) agrees with the view expressed in the paper. Thu11:53. Noted with guidance/text for meeting minutes.

e-mail discussion:

Text for meeting minutes: There is no consensus whether the support of service continuity for UE-to-Network Relay is to be de-scoped from Rel-17 FS_5G_ProSe SID (as per WT paper endorsed at TSG SA#86) and it will be resolved in the future SA WG2/TSG SA (e)-meetings. SA WG2 can try to get to improve the ProSe SID and if possible also resolve this issue in Q2 if there is time; If at TSG SA#88 we are still in the same situation, TSG SA#88 will take a decision (e.g. go for a Working Agreement if necessary). As we don't know yet the nature of TSG SA#88 (f2f/e-meeting), the way to reach this decision will be announced over the next weeks.

Status:

Noted.

6.9 Specifications for Information

TD SP-200161 (DRAFT TR) TS 33.536, Security aspects of 3GPP support for advanced Vehicle-to-Everything (V2X) services. (Source:SA WG3).
Document for: Information.
Abstract: Abstract of document: TS 33.536 ('Security aspects of 3GPP support for advanced Vehicle-to-Everything (V2X) services (Release 16)') specifies requirements and security solutions to support eV2X services over NR PC5 and Uu reference points. Changes since last presentation: This is the first presentation to TSG SA. Outstanding Issues: Finalise the handling of UP security policy for unicast bearers over PC5 reference point Decide on the solution (if any) to add for Groupcast privacy over PC5 reference point Adding agreeable requirements and solutions (based on the TR conclusions) in the common security clause over PC5 reference point Contentious Issues: None.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200199 (DRAFT TR) Draft TR 28.807 'Study on mangement of non-public networks'. (Source:SA WG5).
Document for: Information.
Abstract: Abstract of document: Work done against WT level Study Item in SP-190137. UID 830024 Title Study on non-public networks management Acronym FS_OAM_NPN Rapporteur: Kai ZHANG (Huawei) This document describes use cases, potential requirements and solutions for the management aspects of non-public networks. Changes since last presentation to TSG SA Meeting #: This is the first presentation of the TR. Outstanding Issues: None. Contentious Issues: None.

Comment:

Block1 - Proposed: Noted. Noted.

Discussion and conclusion:

Status:

Noted.

TD SP-200237 (DRAFT TS) 26.512: Technical Specification on 5G Media Streaming (5GMS); Protocols. (Source:SA WG4).
Document for: Information.
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: This is the first presentation. Outstanding Issues: Align Stage 3 according to Stage 2 procedures, specifically - the 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. Contentious Issues: None.

Comment:

Block2 - Proposed: approved. Noted.

Discussion and conclusion:

Status:

Noted.

6.10 Specifications for Approval / for Information and Approval

TD SP-200049 (DRAFT TS) TS 26.117 5G Media Streaming (5GMS);. (Source:SA WG4).
Document for: Approval.
Abstract: Abstract of document: The present document specifies speech and audio media capabilities, operation points and media profiles for 5G Media Streaming in the context of 3GPP services and deployments. The speech and audio media capabilities defined in this clause are primarily introduced in order to be used as content format in the context of 5G Media Streaming, but not restricted to this use case. Parameters for audio encoder/decoder, content format and transport are defined. The present document defines: - Media decoding capabilities: the requirements for a receiver in terms of decoding - Media encoding capabilities: the requirements for a sender in terms of encoding - Operation Points: A collection of discrete combinations of different content formats and the encoding formats. Operation Points are supported by - Bitstream Requirements: A media bitstream that conforms to an audio or speech encoding format and certain Operation Point. - Receiver Requirements: A function that can decode and playback any Bitstream that is conforming to a certain Operation Point in real-time. - Sender Requirements: A function that can process and encode any Bitstream that is conforming to a certain Operation Point in real-time. - The integration of each Operation Point in 5G Media Streaming as defined in TS 26.501 and TS 26.511. Changes since last presentation: - Added support for uplink streaming - Final clarifications of encoding requirements - General editorial updates Outstanding Issues: none. Contentious Issues: none.

Comment:

Revised in SP-200263.

Discussion and conclusion:

Status:

Revised.

TD SP-200263 (DRAFT TS) TS 26.117 5G Media Streaming (5GMS); Speech and Audio Profiles, v2.0.0 (Release 16). (Source:SA WG4).
Document for: Approval.
Abstract: Abstract of document: The present document specifies speech and audio media capabilities, operation points and media profiles for 5G Media Streaming in the context of 3GPP services and deployments. The speech and audio media capabilities defined in this clause are primarily introduced in order to be used as content format in the context of 5G Media Streaming, but not restricted to this use case. Parameters for audio encoder/decoder, content format and transport are defined. The present document defines: - Media decoding capabilities: the requirements for a receiver in terms of decoding - Media encoding capabilities: the requirements for a sender in terms of encoding - Operation Points: A collection of discrete combinations of different content formats and the encoding formats. Operation Points are supported by - Bitstream Requirements: A media bitstream that conforms to an audio or speech encoding format and certain Operation Point. - Receiver Requirements: A function that can decode and playback any Bitstream that is conforming to a certain Operation Point in real-time. - Sender Requirements: A function that can process and encode any Bitstream that is conforming to a certain Operation Point in real-time. - The integration of each Operation Point in 5G Media Streaming as defined in TS 26.501 and TS 26.511. Changes since last presentation: - Added support for uplink streaming - Final clarifications of encoding requirements - General editorial updates Outstanding Issues: none. Contentious Issues: none.

Comment:

Revision of SP-200049. Minor editorial revisions. Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200046 (DRAFT TR) Extended Reality (XR) in 5G. (Source:SA WG4).
Document for: Approval.
Abstract: Abstract of document: This Technical Report collects information on eXtended Reality (XR) in the context of 5G radio and network services. Extended reality (XR) refers to all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables. It includes representative forms such as augmented reality (AR), mixed reality (MR), and virtual reality (VR) and the areas interpolated among them. In this Technical Report, baseline technologies for XR type of services and applications are introduced outlining the QoE/QoS issues of XR-based services, the delivery of XR in the 5G system, and an architectural model of 5G media streaming defined in TS 26.501. In addition to the conventional service categories, conversational, interactive, streaming, and download, a new category of split compute/rendering is identified. A survey of 3D, XR visual and audio formats is provided. Use cases and device types are classified. Processing and media centric architectures are introduced. This includes viewport independent and dependent streaming, as well as different distributed computing architectures for XR. Core use cases of XR include those unique to AR and MR in addition to those of VR discussed in TR 26.918, ranging from offline sharing of 3D objects, real-time sharing, multimedia streaming, online gaming, mission critical applications, and multi-party call/conferences. Based on the details in the report, proposals for potential standardisation areas are documented. Changes since last presentation: - Updates to baseline technologies including quality factors, rendering pipelines, compression tools and formats, device types and external standardisation areas. - Improved architectural decomposition of core use cases and delivery scenarios. - Added potential standardisation areas - Added conclusions and proposed next steps - General editorial updates Outstanding Issues: none. Contentious Issues: none.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200047 (DRAFT TS) Real-time Transport Protocol (RTP) / RTP Control Protocol (RTCP) verification procedures. (Source:SA WG4).
Document for: Approval.
Abstract: Abstract of document: This technical specification describes: - Test cases needed to ensure an adequate level of RTP operation and RTP stream monitoring. - Test methods capable to verify that information contained in the RTP header and in RTCP is correct and consistent with the observed characteristics of the related RTP streams: - Between RTP/RTCP within the scope of a single RTP stream (e.g. between an RTP stream and the corresponding RTCP reporting from the remote party, or between an RTP stream and the corresponding RTCP metadata, e.g. for sampling clock accuracy compensation between RTP sender and RTP receiver). - Between RTP/RTCP across RTP streams in the same RTP session (e.g. between sent and received RTP streams, or between audio RTP streams and video RTP streams). - Requirements on what constitutes acceptable RTP/RTCP protocol field values, including RTP payload header and RTP payload length, based on the observed characteristics of the related RTP streams. - A method for an RTP/RTCP implementation to announce on the network that it has passed the necessary tests and conforms to the new specification. Changes since last presentation to SA Meeting #86: Updated and detailed descriptions of RTCP tests. Minor clarification of Test Architecture description. Added basic tests for RTCP usage beyond IETF RFC 3550, e.g. RTCP feedback. Added basic tests for RTP. Added conformance announcement description. No tests only applicable for SRTP/SRTCP were considered required now and were left for further study. No tests for RTP Translators and Mixers were considered required and corresponding text was deleted. Outstanding Issues: None Contentious Issues: None.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200048 (DRAFT TR) Typical traffic characteristics of media services on 3GPP networks. (Source:SA WG4).
Document for: Approval.
Abstract: Abstract of document: This TR documents typical media traffic characteristics (including bandwidth and latency requirements) that are of importance for 3GPP standardization work. This includes demands based on current services, but also expectations for new services or emerging services, considering developments in the industry in terms of efficiency improvements. Changes since last presentation to TSG SA Meeting #86: Updated Cloud Gaming characteristics with latency requirements. Updated XR traffic characteristics clause to a reference to TR 26.928 and FFS for further elaboration in Rel-17. Editorial cleanup. Added one HDR format in use. Updated one reference and video/audio bitrates for broadcast auxiliary services. Outstanding Issues: None Contentious Issues: None.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200050 (DRAFT TR) TR 26.921 Investigations on ambient noise reproduction systems for acoustic testing of terminals. (Source:SA WG4).
Document for: Approval.
Abstract: Abstract of document: The technical report provides a collection of investigations on aspects of acoustic UE performance in the presence of ambient noise, which are related to the 3GPP terminal testing specifications TS 26.132 and performance requirements per TS 26.131. Descriptions and results of round robin tests conducted with UE devices in handset and handheld hands-free mode are included. Changes since last presentation to TSG SA Meeting #85: Results of the round robin test conducted within the feasibility study FS_ANTeM for devices in handset mode became available. These comprehensive results were analysed in multiple ways, leading to many figures and tables, which were added to the technical report. Finally, an overall conclusion on ambient noise testing for handset mode was added to the technical report. Outstanding Issues: None. Contentious Issues: None.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200197 (DRAFT TS) Draft TS TS 28.537 '5G System (5GS); 5G management capabilities'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: The present document contains the stage 1 specification for the 5G management capabilities. In this version of the document, it contains Stage 1 for Heartbeat. Work done against WT level Work Item in SP-191195. UID 860023 Title Management and orchestration; Management capabilities Acronym 5GMNC Rapporteur: Jean-Michel Cornily (Orange) Changes since last presentation to SA Meeting #-: This is the first presentation. Outstanding Issues: No outstanding issues. Contentious Issues: No outstanding issues.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200198 (DRAFT TS) Draft TS TS 28.310 'Management and orchestration; Energy efficiency of 5G'. (Source:SA WG5).
Document for: Approval.
Abstract: Abstract of document: The present document specifies concepts, use cases, requirements and solutions for the energy efficiency assessment and optimization for energy saving of 5G networks. Work done against WT level Work Item in SP-191193. UID 810023 Title Energy efficiency of 5G Acronym EE_5G Rapporteur: Jean-Michel Cornily (Orange) Changes since last presentation to SA Meeting #86: Solutions for both distributed and centralized energy saving have been introduced. An overall consistency check of the document has been done. Outstanding Issues: No outstanding issues. Contentious Issues: No outstanding issues.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200107 (DRAFT TR) Presentation of TR 23.774 v1.0.0 for approval. (Source:SA WG6).
Document for: Approval.
Abstract: Abstract of document: This TR was developed by SA WG6 under SID FS_MC5MBS (SP-190929: work approved at TSG SA#85, due for completion at TSG SA#87). Study of potential new/enhanced capabilities for mission critical communication services utilizing multicast-broadcast, to be provided in 5G. The study points out key issues, describes use cases, evaluates potential solutions, proposes enhancements and optimizations and identifies architectural requirements and/or design goals applicable to 3GPP work in support of public safety. Changes since last presentation to TSG SA: Not applicable (first time presentation). Outstanding Issues: None. Contentious Issues: None.

Comment:

Block2 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

7 Release Planning

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

TD SP-200222 (WORK PLAN) Work Plan review at TSG SA#87e. (Source:Work Plan Manager).
Document for: Information.
Abstract: Work Plan review at TSG SA#87e.

Comment:

Proposed Action: Noted. Noted.

Discussion and conclusion:

Was made available Wed14:37. Noted.

Status:

Noted.

TD SP-200225 (OTHER) Rel-17 Timeline Shift Due to Impact of COVID-19. (Source:TSG SA Chairman, TSG CT Chairman, SA WG1 Chairman, SA WG2 Chairman, SA WG6 Chairman, CT WG1 Chairman, CT WG4 Chairman).
Document for: Approval.
Abstract: Proposal for Rel-17 Timeline Shift Due to Impact of COVID-19.

Comment:

Proposed Action: Approved. Due to the impact of this contribution on other documents it is proposed to be approved on Wednesday 09:00 CET. Approved.

Discussion and conclusion:

Adrian (Vodafone) discuss additional contingency plans that enable delivery of Release 17 with only the 3-month’s slip. Tue19:19.

Status:

Approved.

TD SP-200226 (OTHER) Rel-16 Timeline Shift Due to Impact of COVID-19. (Source:TSG SA Chairman, TSG CT Chairman).
Document for: Approval.
Abstract: Proposal for Rel-16 Timeline Shift Due to Impact of COVID-19.

Comment:

Proposed Action: Approved. Due to the impact of this contribution on other documents it is proposed to be approved on Wednesday 09:00 CET. SP-200226_rev1 approved. Revised to SP-200292.

Discussion and conclusion:

SP-200226_rev1 approved.

Status:

Revised.

TD SP-200292 (OTHER) Rel-16 Timeline Shift Due to Impact of COVID-19. (Source:TSG SA Chairman, TSG CT Chairman).
Document for: Approval.
Abstract: Proposal TSG CT and TSG SA are asked to approve the following for Rel-16: 1. Rel-16 Stage 3 freeze: June 2020 (shifted by 3 months) 2. Rel-16 ASN.1 and OpenAPI specification freeze: June 2020 (stays as planned) 3. Exception sheets for Rel-16 items should be made available by the relevant TSG CT and WG groups at March plenaries. These exception sheets will not be approved but endorsed as guidance for the work in Q2be noted. 4. The Rel-16 work items and issues listed on the exception sheets have to be treated with priority in Q2/2020 WG meetings. Note that it is assumed that RAN approves aligned timelines (bullet 1 and 2) for Rel-16.

Convenor comment:

Comment:

Revision 1 of SP-200226. Approved.

Parallel:

Status:

Approved.

TD SP-200275 (DISCUSSION) Need to plan to avoid 6 months shift in Rel-17 Timeline. (Source:VODAFONE Group Plc).
Document for: Approval.
Abstract: Vodafone believe that 3GPP has reacted fast and well to the changing world circumstances that have occurred over the last few months. Owing to the loss of all Release 17 work in at least the February e-meetings, Vodafone supports the changes in Release 17 timeline proposed by the 3GPP chairs in SP-200225. Vodafone note that all the April and May 2020 Working Group face-to-face meetings have been cancelled (and are converting into electronic meetings).

Comment:

Proposed Action: Noted. Noted.

Discussion and conclusion:

Ongoing discussions on SA WG2 meetings necessary to meet current timelines. The latest approval time for SP-200275 (or any revision) is set to Friday 10:00 CET, in order to get input from the SA WG2 call on Thursday. SAChair Wed18:41. Georg (SA Chair): change the wording from 'avoid 6 months shift' to 'enable to complete with a 3 months shift (under the current circumstances)'. Thu09:20. Adrian: better phrase 'enable to complete with a 3 months shift even if all meetings before September have to be conducted as e-meetings'. Tue10:26. SA WG2 chair indicates that SA WG2 has had a conference call and planned meetings for Q3 to take care to keep R17 in SA WG2 within the envisaged time frame after the 3 month shift. Thu18:21. Farooq (AT&T) cannot agree to latest revision and proposes to note the paper rather than to approve it. Thu17:40. -- ongoing discussion. Noted.

Status:

Noted.

8 Rel-8 CRs

9 Rel-9 CRs

10 Rel-10 CRs

11 Rel-11 CRs

12 Rel-12 CRs

13 Rel-13 CRs

14 Rel-14 CRs

15 Rel-15 CRs

TD SP-200121 (CR PACK) SA WG1 CRs om TEI15. (Source:SA WG1).
Document for: Approval.
Abstract: 22.071 CR0083R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200060 (CR PACK) CRs to 23.228, 23.501, 23.502, 23.503 (5GS_Ph1, Rel-15, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2052; 23.503 CR0352R3; 23.502 CR2022R1; 23.501 CR2100R1; 23.502 CR2023R2; 23.502 CR1684R5; 23.502 CR1685R4; 23.502 CR1977R2; 23.502 CR1978R2; 23.502 CR2085R1; 23.501 CR2174R1; 23.501 CR2175R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200061 (CR PACK) CRs to 23.401 (CIOT_ext, Rel-15, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.401 CR3577R1; 23.401 CR3583R1; 23.401 CR3582R6.

Comment:

Block4 - Proposed: approved. Approved with exception of S2-2002552 and S2-2001686, which are both postponed (i.e. sent back to SA WG2). Partially approved.

Discussion and conclusion:

Shabnam (Ericsson) asks that the Rel-15 CR and its Rel-16 version (S2-2002552 and S2-2001686) in SP-200061 be sent back to SA WG2 due to information made available via the incoming RAN WG3 LS which came after the SA WG2#137E e-meeting where these CRs were agreed. Tue21:25. Chris (Vodafone) disagrees with the Ericsson reasoning Wed10:07. Jinguo (ZTE) supports postpoining these papers. Thu08:35. Laurent (Nokia) also supports sending back these CRs Thu09:09. Approved with exception of S2-2002552 and S2-2001686, which are both postponed (i.e. sent back to SA WG2). Partially approved.

Status:

Partially approved.

TD SP-200030 (CR PACK) Rel-15 CRs on Lawful Interception. (Source:SA WG3-LI).
Document for: Approval.
Abstract: 33.127 CR0062; 33.127 CR0063; 33.128 CR0060; 33.128 CR0061; 33.128 CR0064; 33.128 CR0065R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200134 (CR PACK) Rel-15 CRs on Security aspects of 5G System - Phase 1 (5GS_Ph1-SEC). (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0781; 33.501 CR0760R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200138 (CR PACK) Rel-15 CRs on TEI. (Source:SA WG3).
Document for: Approval.
Abstract: 33.401 CR0688R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

John (MCC) proposes to postpone the only CR in this CR pack (S3-200516) to SA WG3. Wed18:53. After clarification from SA WG3 Chairman, John withdrew his request. Thu09:17.

e-mail discussion:

Noamen BEN HENDA (SA WG3 Chairman): Below is some background and my own understanding. This CR is addressing a GSMA LS received few meetings back and is related to an important security issue. SA WG3 agreed to address it in Rel-15 and Rel-16. RAN WG2 and RAN WG3 have been involved as well. In Rel-16, SA WG3 has a WI covering this topic. This is still being extensively discussed in SA WG3. 1. On the type of the CR: The intention is to provide guidelines/recommendations on the network side for how to handle the UE RRC caps. Before the CR, it was left to the network. After the CR, there is a recommendation to set up AS security before the retrieval of the UE RRC caps in some scenarios. Neither does the CR introduce new functionality on the UE side, nor changes on the network interfaces. Therefore, in my understanding this was acceptable as a cat-F CR. 2. On the missing mirror CR: SA WG3's initial intention was to provide the same guidelines/recommendation (1st paragraph) for Rel-15 and Rel-16. However there is a gap in Rel-15 namely a special type of UEs not supporting AS security. For this type of UEs, there must be an exception to the guidelines and hence the 2nd paragraph. For Rel-16, the debate is ongoing and there are different option: (a) allow the exception as in the Re-15 CR, (b) to not allow it by mandating AS security support or (c) to introduce a new mechanism to address the security issue. Bringing a mirror means that SA WG3 agreed on option (a). Observe that depending on the conclusion we might end-up with a different handling in Rel-16. So we might face a similar problem in the next plenary, should SA send back this CR now.

Status:

Approved.

TD SP-200105 (CR PACK) CR to TS 26.260 on Correction of sensitivity calculation for immersive audio playback. (Source:SA WG4).
Document for: Approval.
Abstract: 26.260 CR0002R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200165 (CR PACK) Rel-15 CRs on TEI. (Source:SA WG5).
Document for: Approval.
Abstract: 32.422 CR0310R1; 32.422 CR0311R1; 32.423 CR0099R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200167 (CR PACK) Rel-15 CRs on Service Based Interface for 5G Charging Batch 1. (Source:SA WG5).
Document for: Approval.
Abstract: 32.298 CR0793; 32.298 CR0794R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200174 (CR PACK) Rel-15 CRs on Provisioning of network slicing for 5G networks and services. (Source:SA WG5).
Document for: Approval.
Abstract: 28.532 CR0089; 28.532 CR0104; 28.532 CR0106; 28.532 CR0099R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200181 (CR PACK) Rel-15 CRs on Performance Assurance for 5G networks including network slicing. (Source:SA WG5).
Document for: Approval.
Abstract: 28.533 CR0057R1; 28.550 CR0043R1; 28.550 CR0044R1; 28.550 CR0045R1; 28.550 CR0046R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200183 (CR PACK) Rel-15 CRs on REST Solution Sets (normative work). (Source:SA WG5).
Document for: Approval.
Abstract: 32.158 CR0011R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200227 (CR PACK) Rel-15 CRs on NETSLICE. (Source:SA WG5).
Document for: Approval.
Abstract: 28.533 CR0055R1; 28.533 CR0056R1; 28.533 CR0063R1; 28.533 CR0064R2.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

16 Rel-16 CRs

16.1 SA WG1 Rel-16 CRs

TD SP-200122 (CR PACK) SA WG1 CRs on TEI16. (Source:SA WG1).
Document for: Approval.
Abstract: 22.261 CR0435R1; 22.261 CR0436R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

16.2 SA WG2 Rel-16 CRs

TD SP-200268 (CR) 23.501 CR2179R2 (Rel-16, 'F'): Change of the restriction of enhanced coverage. (Source:Qualcomm Incorporated, Samsung, Interdigital Inc, Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify that when a change regarding the use of coverage enhancement occurs (e.g. due to a change in subscription) and the UE is in CM-CONNECTED, the AMF shall trigger the UE Configuration Update procedure to the UE and indicate a need to perform a registration procedure. The AMF also updates SMFs to apply extended NAS-SM timer as part of the registration procedure.

Comment:

Revision of S2-2002355 in CR Pack SP-200062. SP-200268_rev1 approved. Revised to SP-200293.

Discussion and conclusion:

Andy (Samsung) objects to this revised version of the CR. Wed11:14. Shabnam (Ericsson) Draft revision available in drafts folder. Wed16:30. Saad (interdigital) supports proposed text in revision. Wed17:30. Haris (Qualcomm) is fine with Ericsson's draft revision and proposes that Samsung will provide an official revision. Wed21:14. Approved (_rev1). SP-200268_rev1 approved.

Status:

Revised.

TD SP-200293 (CR) 23.501 CR2179R3 (Rel-16, 'F'): Change of the restriction of enhanced coverage. (Source:Qualcomm Incorporated, Samsung, Interdigital Inc, Ericsson).
Document for: Approval.
Abstract: Summary of change: Clarify that when a change regarding the use of coverage enhancement occurs (e.g. due to a change in subscription) and the UE is in CM-CONNECTED, the AMF shall trigger the UE Configuration Update procedure to the UE and indicate a need to perform a registration procedure. The AMF also updates SMFs to apply extended NAS-SM timer as part of the registration procedure.

Convenor comment:

Comment:

Revision 1 of SP-200268. Approved.

Parallel:

Status:

Approved.

TD SP-200062 (CR PACK) CRs to 23.501 (5G_CIoT, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2035; 23.501 CR2088R1; 23.501 CR1691R3; 23.501 CR1668R4; 23.501 CR2089R3; 23.501 CR2053R3; 23.501 CR2163; 23.501 CR2128R1; 23.501 CR2147R1; 23.501 CR2148R1; 23.501 CR2158R1; 23.501 CR2160R1; 23.501 CR2179R1.

Comment:

Revision of 23.501 CR2179R1 proposed in SP-200268. Approved with the exception of S2-2002355 (for which a revision is provided in SP-200268). Partially approved.

Discussion and conclusion:

Qualcomm objects to S2-2002355. Wed12:18. Discussion. Draft revision needs to be provided by Samsung. Approved with the exception of S2-2002355 (for which a revision is provided in SP-200268). Partially approved.

Status:

Partially approved.

TD SP-200267 (CR) 23.502 CR2043R4 (Rel-16, 'F'): Procedure udpate for PDU Session establishment and Bridge based information reporting. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: 1. Provide the 5GS Bridge ID and DS-TT port number to the DS-TT. 2. Decide the port pair before calculating the bridge delay. 3. UPF selection and NW-TT port selection clarification. Changes on top of rev3: Rev3 added '5GS Bridge ID and allocated DS-TT port number' in Step 11 of the PDU Session Establishment procedure in clause 4.3.2.2.1. DS-TT does however not need this information, 5GS Bridge ID and allocated DS-TT port number are also not used according to the CR. During the SA WG2#137e meeting it was also suggested that the UE/DS-TT may need this information to ensure that only a single PDU session is established per Ethernet port and UPF. However, this is incorrect: DS-TT is aware of the available Ethernet ports and needs to interact with the UE for the PDU session establishment anyhow (details are up to implementation but AT commands are one option). Therefore DS-TT can easily ensure that only a single PDU session is established per Ethernet port. In conclusion there is no need to signal 5GS Bridge ID and allocated DS-TT port number to the UE. Rev4 therefore removes the added '5GS Bridge ID and allocated DS-TT port number' from Step 11 of the PDU Session Establishment procedure.

Comment:

Revision of S2-2002569 in CR Pack SP-200077. Approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200077 (CR PACK) CRs to 23.502, 23.503 (Vertical_LAN, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR1763R2; 23.502 CR2030R2; 23.502 CR1797R4; 23.502 CR1796R7; 23.502 CR2041R4; 23.502 CR1956R4; 23.502 CR1582R2; 23.502 CR2142R1; 23.502 CR2092R1; 23.502 CR2093R1; 23.502 CR1673R7; 23.502 CR2137R1; 23.502 CR2043R3; 23.502 CR2150R1; 23.503 CR0394R5; 23.503 CR0372R3; 23.503 CR0344R5; 23.502 CR1792R4; 23.502 CR2091R1; 23.502 CR2108R1.

Comment:

Revision of 23.502 CR2043R3 proposed in SP-200267. Approved with the exception of S2-2002569, which was revised to SP-200267. Partially approved.

Discussion and conclusion:

Approved with the exception of S2-2002569, which was revised to SP-200267. Partially approved.

Status:

Partially approved.

TD SP-200063 (CR PACK) CRs to 23.502 (5G_CIoT, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2013; 23.502 CR2035; 23.502 CR1776R2; 23.502 CR2054; 23.502 CR2049R1; 23.502 CR2025R1; 23.502 CR1590R6; 23.502 CR1667R3; 23.502 CR2072R1; 23.502 CR2052R1; 23.502 CR2003R1; 23.502 CR2004R1; 23.502 CR2001R1; 23.502 CR1985R2; 23.502 CR2002R2; 23.502 CR2050R2; 23.502 CR1984R1; 23.502 CR1930R6; 23.502 CR2130R1; 23.502 CR1983R3; 23.502 CR2129R1.

Comment:

Block4 - Proposed: approved. Approved with the exception of S2-2001329, which is postponed (i.e. sent back to SA WG2). Partially approved.

Discussion and conclusion:

Shabnam (Ericsson): proposed revision in drafts folder. Wed17:10. Miikka (Nokia): doesn't agree to the draft revision Wed20:16. Approved with the exception of S2-2001329, which is postponed (i.e. sent back to SA WG2). Partially approved.

Status:

Partially approved.

TD SP-200064 (CR PACK) CRs to 23.273, 23.501, 23.502 (5G_eLCS, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.273 CR0091; 23.273 CR0089R1; 23.502 CR2056R1; 23.501 CR2102R1; 23.273 CR0075R2; 23.273 CR0070R2; 23.273 CR0092R1; 23.502 CR2055R1; 23.273 CR0081R1; 23.273 CR0108; 23.273 CR0115R1; 23.273 CR0095R1; 23.273 CR0103R1; 23.273 CR0105R1; 23.273 CR0106R1; 23.273 CR0107R1; 23.273 CR0111R1; 23.273 CR0112R1; 23.273 CR0113R1; 23.273 CR0114R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200065 (CR PACK) CRs to 23.501, 23.502, 23.503 (5G_eSBA, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2069R2; 23.501 CR2111R2; 23.502 CR1961R4; 23.502 CR1962R4; 23.502 CR1959R3; 23.501 CR2022R3; 23.502 CR2153; 23.501 CR2190R1; 23.502 CR2138R1; 23.502 CR1997R2; 23.502 CR2151R1; 23.502 CR2152R1; 23.502 CR2117R1; 23.503 CR0385R3; 23.502 CR1986R4; 23.501 CR2021R4.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200066 (CR PACK) CRs to 23.216 (5G_SRVCC, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.216 CR0364; 23.216 CR0358R5; 23.216 CR0366R1; 23.216 CR0367R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200067 (CR PACK) CRs to 23.501, 23.502, 23.503 (5G_URLLC, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR1992R1; 23.502 CR2064R1; 23.503 CR0388R1; 23.501 CR2122R2; 23.502 CR2121; 23.501 CR2123R5; 23.502 CR2007R2; 23.503 CR0429R1; 23.501 CR2154R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200068 (CR PACK) CRs to 23.316, 23.501, 23.502 (5WWC, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.316 CR0064; 23.316 CR1831R1; 23.316 CR0065R1; 23.501 CR2047R1; 23.502 CR1950R2; 23.316 CR1833R2; 23.316 CR0063R2; 23.501 CR2027R2; 23.316 CR1832R3; 23.316 CR1829R5; 23.501 CR2033R4; 23.316 CR1834; 23.316 CR1838; 23.501 CR2186; 23.502 CR2134; 23.316 CR2034; 23.316 CR1835R1; 23.316 CR2035R1; 23.316 CR2036R1; 23.316 CR2037R1; 23.316 CR1837R1; 23.501 CR2216R1; 23.501 CR2214R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200069 (CR PACK) CRs to 23.501, 23.502, 23.503 (ATSSS, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2017; 23.501 CR2051; 23.501 CR1957R2; 23.502 CR1906R2; 23.503 CR0361R2; 23.502 CR2018R1; 23.501 CR2044R1; 23.501 CR2079R1; 23.502 CR1969R2; 23.502 CR1840R4; 23.502 CR2016R1; 23.502 CR2045R2; 23.501 CR2036R2; 23.501 CR1947R3; 23.502 CR1970R3; 23.502 CR2015R3; 23.501 CR2032R3; 23.501 CR2141; 23.502 CR2100; 23.501 CR2150; 23.502 CR2166; 23.502 CR2096R1; 23.502 CR2098R1; 23.502 CR2104R1; 23.503 CR0420R1; 23.501 CR1782R4; 23.502 CR2155R1; 23.503 CR0424R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200070 (CR PACK) CRs to 23.288, 23.501, 23.502, 23.503 (eNA, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.288 CR0104; 23.288 CR0103R1; 23.288 CR0105R1; 23.288 CR0114R1; 23.288 CR0108R2; 23.503 CR0398R2; 23.288 CR0112R2; 23.288 CR0109R3; 23.288 CR0110R3; 23.288 CR0113R4; 23.502 CR2088; 23.502 CR2089; 23.502 CR2099; 23.288 CR0130; 23.288 CR0132; 23.288 CR0139; 23.288 CR0140; 23.288 CR0115R1; 23.288 CR0142R1; 23.288 CR0123R1; 23.288 CR0124R1; 23.288 CR0127R1; 23.288 CR0117R1; 23.501 CR2140R1; 23.288 CR0119R1; 23.503 CR0389R2; 23.502 CR2008R2; 23.503 CR0408R1; 23.288 CR0126R1; 23.288 CR0128R1; 23.288 CR0129R1; 23.501 CR2159R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200071 (CR PACK) CRs to 23.501, 23.502 (eNS, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2011R1; 23.501 CR2040R1; 23.501 CR2192R1; 23.502 CR2160R1; 23.502 CR1953R5.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200072 (CR PACK) CRs to 23.501, 23.502 (ETSUN, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR1989; 23.501 CR2048; 23.502 CR2039; 23.501 CR2030R1; 23.502 CR1998R1; 23.502 CR1963R1; 23.502 CR1825R6; 23.502 CR1964R1; 23.502 CR2019R1; 23.502 CR1981R2; 23.502 CR2139R1; 23.502 CR2115R1; 23.501 CR2169R1; 23.502 CR2118R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200073 (CR PACK) CRs to 23.287 (eV2XARC, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.287 CR0068; 23.287 CR0069; 23.287 CR0070; 23.287 CR0078; 23.287 CR0076R1; 23.287 CR0086R1; 23.287 CR0066R1; 23.287 CR0077R2; 23.287 CR0075R2; 23.287 CR0063R2; 23.287 CR0084R2; 23.287 CR0073R2; 23.287 CR0061R2; 23.287 CR0092; 23.287 CR0094; 23.287 CR0102; 23.287 CR0087R1; 23.287 CR0089R1; 23.287 CR0091R1; 23.287 CR0096R1; 23.287 CR0097R1; 23.287 CR0103R1; 23.287 CR0104R1; 23.287 CR0098R1; 23.287 CR0101R1; 23.287 CR0106R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200074 (CR PACK) CRs to 23.401, 23.501, 23.502, 23.682 (RACS, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.401 CR3579; 23.502 CR2034; 23.501 CR2117; 23.501 CR2116R1; 23.501 CR2106R2; 23.502 CR2066R2; 23.682 CR0467R2; 23.501 CR2161; 23.401 CR3588; 23.401 CR3587R1; 23.502 CR2107R1; 23.401 CR3593R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200075 (CR PACK) CRs to 23.501 (Vertical_LAN, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2009R1; 23.501 CR2026R1; 23.501 CR2073R2; 23.501 CR2064R3; 23.501 CR2007R1; 23.501 CR2067R1; 23.501 CR2070R2; 23.501 CR1749R7; 23.501 CR2019R2; 23.501 CR2028R3; 23.501 CR1799R7; 23.501 CR2029R4; 23.501 CR2042R4; 23.501 CR1595R2; 23.501 CR2069R5; 23.501 CR1951R4; 23.501 CR2050R2; 23.501 CR1482R7; 23.501 CR2046R2; 23.501 CR1520R4; 23.501 CR1882R4; 23.501 CR1980R3.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200076 (CR PACK) CRs to 23.501 (Vertical_LAN, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2097R2; 23.501 CR2084R3; 23.501 CR2074R3; 23.501 CR2171; 23.501 CR2178; 23.501 CR2199; 23.501 CR2205; 23.501 CR2197R1; 23.501 CR2143R1; 23.501 CR2165R1; 23.501 CR2183R1; 23.501 CR2085R4; 23.501 CR2198R1; 23.501 CR2202R1; 23.501 CR2204R1; 23.501 CR2172R1; 23.501 CR2133R1; 23.501 CR2212R1; 23.501 CR2137R1; 23.501 CR2164R1; 23.501 CR2194R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200078 (CR PACK) CRs to 23.501 (5GS_Ph1, TEI16, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.501 CR2057R1; 23.501 CR2031R1; 23.501 CR2087R1; 23.501 CR2017R1; 23.501 CR2015R2; 23.501 CR2054R2; 23.501 CR2056R2; 23.501 CR2038R2; 23.501 CR1848R14; 23.501 CR2109R2; 23.501 CR2020R3; 23.501 CR2132; 23.501 CR2136R1; 23.501 CR2191R1; 23.501 CR2195R1; 23.501 CR2108R3; 23.501 CR2201R1; 23.501 CR2209R1; 23.501 CR2060R4; 23.501 CR1783R6.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200079 (CR PACK) CRs to 23.502 (5GS_Ph1, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.502 CR2024; 23.502 CR1995R1; 23.502 CR2047R1; 23.502 CR1994R1; 23.502 CR1773R4; 23.502 CR1987R1; 23.502 CR2063R1; 23.502 CR2068R1; 23.502 CR1960R3; 23.502 CR2021R2; 23.502 CR1957R2; 23.502 CR1966R2; 23.502 CR1973R2; 23.502 CR2026R2; 23.502 CR1988R3; 23.502 CR2048R3; 23.502 CR1976R3; 23.502 CR2082; 23.502 CR2084; 23.502 CR2090; 23.502 CR1982R1; 23.502 CR2109; 23.502 CR2123; 23.502 CR1996R1; 23.502 CR2145; 23.502 CR2059R6; 23.502 CR2113R1; 23.502 CR2157R1; 23.502 CR2122R1; 23.502 CR2083R1; 23.502 CR1878R3; 23.502 CR2095R1; 23.502 CR1980R5; 23.502 CR2146R1; 23.502 CR2163R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200080 (CR PACK) CRs to 23.228, 23.503 (5GS_Ph1, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.503 CR0391; 23.503 CR0392; 23.503 CR0381R1; 23.503 CR0382R1; 23.228 CR1231R2; 23.503 CR0384R2; 23.503 CR0390R3; 23.503 CR0423R1; 23.503 CR0397R4; 23.503 CR0400R4; 23.503 CR0401R4; 23.503 CR0417R1; 23.503 CR0419R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200081 (CR PACK) CRs to 23.401, 23.501, 23.502, 23.682 (Miscellaneous TEI16, Rel-16). (Source:SA WG2).
Document for: Approval.
Abstract: 23.401 CR3581R4; 23.501 CR2157; 23.401 CR3586; 23.682 CR0468; 23.401 CR3589R1; 23.401 CR3578R2; 23.502 CR2162R1; 23.502 CR2127R1; 23.401 CR3558R2.

Comment:

23.401 CR3558R2 conditionally approved by SA WG2. Huawei suggest postponing for next SA WG2 meetng. Approved.

Discussion and conclusion:

Wanqiang (Huawei) proposes to postpone SA WG2 CR S2-2002553 of this pack Tu414:53. Haris (Qualcomm): proposes to approve the SA WG2 CR, if not approved no more time should be allocated on this issue in SA WG2 Tue15.28. Vodafone, Ericsson propose to approve CR. Wanqiang (Huawei) removes his proposal to postpone. Thu11:14.

Status:

Approved.

16.3 SA WG3 and SA WG3 LI Rel-16 CRs

TD SP-200031 (CR PACK) Rel-16 CRs on Lawful Interception. (Source:SA WG3-LI).
Document for: Approval.
Abstract: 33.127 CR0057R1; 33.127 CR0058R1; 33.127 CR0059R1; 33.127 CR0060R2; 33.127 CR0061R2; 33.127 CR0064R1; 33.127 CR0066R1; 33.128 CR0062; 33.128 CR0063; 33.128 CR0066; 33.128 CR0070R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200133 (CR PACK) Rel-16 CRs on Security for enhancements to the Service Based 5G System Architecture. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0755R1; 33.501 CR0756R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200135 (CR PACK) Rel-16 CRs on Mission Critical Services Security Enhancements. (Source:SA WG3).
Document for: Approval.
Abstract: 33.180 CR0135; 33.180 CR0137; 33.180 CR0139; 33.180 CR0136R1; 33.180 CR0138R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200136 (CR PACK) Rel-16 CRs on Security Assurance Specification for 5G. (Source:SA WG3).
Document for: Approval.
Abstract: 33.511 CR0012; 33.512 CR0005R1; 33.117 CR0057R1; 33.117 CR0058R1; 33.926 CR0032R1; 33.511 CR0011R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200139 (CR PACK) Rel-16 CRs on TEI. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0759R1; 33.401 CR0690R1; 33.501 CR0745R1; 33.401 CR0689R1; 33.926 CR0031R1; 33.216 CR0013R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200140 (CR PACK) Rel-16 CRs on Security for 5GS Enhanced support of Vertical and LAN Services. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0769; 33.501 CR0770; 33.501 CR0771R1; 33.501 CR0766R1; 33.501 CR0767R1; 33.501 CR0768R1; 33.501 CR0747R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

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

Comment:

Revised in SP-200255.

Discussion and conclusion:

Status:

Revised.

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

Comment:

Revision of SP-200141. Block4 - Proposed: approved. Block approved.

Parallel:

33.501 CR0689R2; 33.501 CR0754R1.

Status:

Approved.

TD SP-200142 (CR PACK) Rel-16 CRs on Security of URLLC for 5GS. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0783.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200143 (CR PACK) Rel-16 CRs on 3GPP profiles for cryptographic algorithms and security protocols. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0757; 33.210 CR0065; 33.210 CR0067; 33.310 CR0104R1; 33.210 CR0064R1; 33.310 CR0105R1; 33.210 CR0066R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200144 (CR PACK) Rel-16 CRs on Security for IAB. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0782; 33.401 CR0691.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200145 (CR PACK) Rel-16 CRs on Security of 5WWC. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0712; 33.501 CR0784.

Comment:

Approved with the exception of S3-200083. Partially approved.

Discussion and conclusion:

S3-200083 needs to be withdrawn and taken out of the pack. Proposed Action: approved with exception of S3-200083. Approved with the exception of S3-200083. Partially approved.

Status:

Partially approved.

TD SP-200223 (CR PACK) Rel-16 CRs on Security aspects of single radio voice continuity from 5GS to UTRAN. (Source:SA WG3).
Document for: Approval.
Abstract: 33.501 CR0765.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

16.4 SA WG4 Rel-16 CRs

TD SP-200033 (CR PACK) CRs to TS 26.114 and 26.223 on Addition and alignment of MTSI Data Channel Support [5G_MEDIA_MTSI_ext]. (Source:SA WG4).
Document for: Approval.
Abstract: 26.114 CR0496R2; 26.223 CR0013R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200037 (CR PACK) List of Change Requests (CRs) to TS 26.238 on E_FLUS for Uplink Streaming and NBMP Use in FLUS. (Source:SA WG4).
Document for: Approval.
Abstract: 26.238 CR0016; 26.238 CR0017.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200038 (CR PACK) List of Change Requests (CRs) to TS 26.118 and TS 26.234 on VR metrics PSS VR metrics support [VRQoE]. (Source:SA WG4).
Document for: Approval.
Abstract: 26.118 CR0003; 26.234 CR0229.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200039 (CR PACK) List of Change Requests (CRs) to TS 26.346, TS TS 26.347 and TS 26.348 on DAHOE. (Source:SA WG4).
Document for: Approval.
Abstract: 26.346 CR0631R1; 26.347 CR0008R1; 26.348 CR0006R1; 26.348 CR0007R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200040 (CR PACK) List of Change Requests (CRs) to TS 26.501 on 5GMSA. (Source:SA WG4).
Document for: Approval.
Abstract: 26.501 CR0004R1; 26.501 CR0005; 26.501 CR0006R1; 26.501 CR0007R1; 26.501 CR0008R1; 26.501 CR0009R1; 26.501 CR0010; 26.501 CR0011; 26.501 CR0012.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200103 (CR PACK) CR to TS 26.132 on Alternative noise field simulation method for terminal testing. (Source:SA WG4).
Document for: Approval.
Abstract: 26.132 CR0102.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200104 (CR PACK) CR to TS 26.44 on Corrections to Floating-Point Conformance Scripts. (Source:SA WG4).
Document for: Approval.
Abstract: 26.444 CR0028R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

16.5 SA WG5 Rel-16 CRs

TD SP-200162 (CR PACK) Rel-16 CRs on Enhancement of performance assurance for 5G networks including network slicing. (Source:SA WG5).
Document for: Approval.
Abstract: 28.552 CR0173; 28.552 CR0174; 28.554 CR0039; 28.552 CR0200; 28.552 CR0185R1; 28.552 CR0186R1; 28.552 CR0188R1; 28.552 CR0189R1; 28.552 CR0190R1; 28.552 CR0175R1; 28.552 CR0176R1; 28.552 CR0177R1; 28.552 CR0184R1; 28.552 CR0181R1; 28.552 CR0182R1; 28.552 CR0194R1; 28.552 CR0197R1; 28.552 CR0187R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200163 (CR PACK) Rel-16 CRs on Enhancement of performance assurance for 5G networks including network slicing-KPI reporting. (Source:SA WG5).
Document for: Approval.
Abstract: 28.554 CR0038R1; 28.622 CR0069R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200164 (CR PACK) Rel-16 CRs on Charging Aspect for 5WWC. (Source:SA WG5).
Document for: Approval.
Abstract: 32.255 CR0185R1; 32.255 CR0188R1; 32.255 CR0186R1; 32.255 CR0189R2; 32.255 CR0190R2.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200169 (CR PACK) Rel-16 CRs on NRM enhancements. (Source:SA WG5).
Document for: Approval.
Abstract: 28.540 CR0009; 28.541 CR0235; 28.541 CR0241; 28.541 CR0242; 28.541 CR0179R3; 32.160 CR0005; 28.532 CR0105; 28.541 CR0258; 28.623 CR0045; 28.532 CR0098R1; 28.541 CR0239R1; 28.541 CR0163R4; 28.541 CR0250R1; 28.622 CR0066R1; 28.623 CR0042R1; 28.541 CR0243R1; 28.622 CR0071R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200170 (CR PACK) Rel-16 CRs on Charging aspects of ETSUN. (Source:SA WG5).
Document for: Approval.
Abstract: 32.291 CR0199; 32.255 CR0203R1; 32.255 CR0140R2; 32.255 CR0141R2; 32.255 CR0167R1; 32.255 CR0172R1; 32.255 CR0182R2; 32.255 CR0200R2.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200172 (CR PACK) Rel-16 CRs on Methodology for 5G management specifications. (Source:SA WG5).
Document for: Approval.
Abstract: 32.156 CR0037; 32.160 CR0006; 32.160 CR0007.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200173 (CR PACK) Rel-16 CRs on Management of MDT in 5G. (Source:SA WG5).
Document for: Approval.
Abstract: 32.421 CR0095; 32.422 CR0314; 32.422 CR0315R1; 32.422 CR0319R1; 32.423 CR0100R1; 32.422 CR0318R1; 32.422 CR0316R1; 32.422 CR0317R1; 32.421 CR0093R1; 32.422 CR0320R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200175 (CR PACK) Rel-16 CRs on Streaming trace reporting. (Source:SA WG5).
Document for: Approval.
Abstract: 32.423 CR0101R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

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

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200177 (CR PACK) Rel-16 CRs on Management of QoE measurement collection. (Source:SA WG5).
Document for: Approval.
Abstract: 28.404 CR0002.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

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

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200179 (CR PACK) Rel-16 CRs on Charging Access of ATSSS. (Source:SA WG5).
Document for: Approval.
Abstract: 32.255 CR0168R1; 32.255 CR0169R1; 32.255 CR0170R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200180 (CR PACK) Rel-16 CRs on Closed loop SLS Assurance. (Source:SA WG5).
Document for: Approval.
Abstract: 28.533 CR0057R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200182 (CR PACK) Rel-16 CRs on CHF-controlled quota management. (Source:SA WG5).
Document for: Approval.
Abstract: 32.255 CR0204R3.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200166 (CR PACK) Rel-16 CRs on TEI. (Source:SA WG5).
Document for: Approval.
Abstract: 28.531 CR0039; 28.532 CR0096; 32.298 CR0795R1; 32.298 CR0797R1; 28.532 CR0101R1; 28.532 CR0092R1; 32.291 CR0209.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

This was left open due to an uncertainty of the TSG SA Chairman. No modification on this CR Pack is needed.

Status:

Approved.

TD SP-200229 (CR) 28.623 CR0041R2 (Rel-16, 'B'): Rel-16 CR TS 28.623 Add configurable KPI control NRM. (Source:ZTE, China Telecom, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Add the definition of KPI control NRM in stage 3 definitions to the XML and YANG definitions.

Comment:

Revision of S5-201582. Approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200230 (CR) 28.623 CR0043R1 (Rel-16, 'F'): Rel-16 CR 28.623 Add OpenAPI definitions required by the ProvMnS. (Source:Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: The OpenAPI definitions for the Generic NRM in JSON format are transferred into YAML format The OpenAPI definitions required in the HTTP message bodies of the Provisioning MnS are added to the OpenAPI definition (in YAML format) of the Generic NRM. The OpenAPI definitions of the Generic NRM are extended with the OpenAPI definitions (in YAML format) for the configurable KPI control NRM.

Comment:

Revision of S5-201397. Approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200231 (CR) 28.532 CR0103R2 (Rel-16, 'F'): Rel-16 CR 28.532 Correct OpenAPI definition of the ProvMnS. (Source:Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: The errors in the OpenAPI definition of the ProvMnS are corrected. The link to the OpenAPI definitions of the NRMs is added. The OpenAPI definitions are now provided in YAML format instead of JSON format.

Comment:

Revision of S5-201542. Approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200232 (CR) 28.541 CR0253R2 (Rel-16, 'B'): Rel-16 CR TS 28.541 Add Stage 3 NRM Info Model definitions for RRMPolicy and PLMNInfo related CRs. (Source:Ericsson, Nokia, Nokia Shanghai Bell, Huawei).
Document for: Approval.
Abstract: Summary of change: Added the missing Stage 3 Solution Sets (XML, YANG) for those CRs: - Update of RRM Policy (S5-201317 CR0179 rev- 3) - Correct the parameter sNSSAIList (S5-201334 CR0163 rev- 3) - Update of GNBCUUPFunction NRM (S5-201278 CR0250).

Comment:

Revision of S5-201546. Approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200233 (CR) 28.541 CR0245R2 (Rel-16, 'B'): Rel-16 CR TS 28.541 Add the RIM parameters of mapping relations for remote interference management. (Source:Huawei, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Add Aggressor Set ID and Victim Set ID to GNBDUFunction. Add mapping relationship between set ID and backhaul address of gNBs (gNB ID+TAI) to the GBNCUCPFunction.

Comment:

Revision of S5-201547. Approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200234 (CR) 28.541 CR0248R1 (Rel-16, 'F'): Rel-16 CR TS 28.541 Update on slice NRM and solution sets. (Source:Huawei, China Mobile, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: Update network slicing NRM and XML Solution Set.

Comment:

Revision of S5-201262. Approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200235 (CR) 28.541 CR0255R1 (Rel-16, 'F'): Rel-16 CR 28.541 Add OpenAPI definitions required by the ProvMnS. (Source:Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: The OpenAPI definitions for the Generic NRM, 5GC NRM and Slice NRM in JSON format are transferred into YAML format The OpenAPI definitions required in the HTTP message bodies of the Provisioning MnS are added to the OpenAPI definition (in YAML format) of the Generic NRM, 5GC NRM and Slice NRM. The required OpenAPI definition changes for the IS changes in the CRs listed above are provided.

Comment:

Revision of S5-201399. Approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200248 (CR) 32.291 CR0208R1 (Rel-16, 'F'): Rel-16 CR 32.291 Correct the style for TriggerType in OpenAPI. (Source:Huawei).
Document for: Approval.
Abstract: Summary of change: Correct the style.

Comment:

Revision of S5-201427. Approved.

Discussion and conclusion:

Status:

Approved.

16.6 SA WG6 Rel-16 CRs

TD SP-200112 (CR PACK) Rel-16 CRs to TS 23.222 for eCAPIF. (Source:SA WG6).
Document for: Approval.
Abstract: 23.222 CR0066R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200113 (CR PACK) Rel-16 CRs to TS 23.282 for eMCData2. (Source:SA WG6).
Document for: Approval.
Abstract: 23.282 CR0204R1; 23.282 CR0202R1; 23.282 CR0206; 23.282 CR0205R1; 23.282 CR0200R2; 23.282 CR0203R2; 23.282 CR0201R2; 23.282 CR0197R2; 23.282 CR0209R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200114 (CR PACK) Rel-16 CRs to TS 23.434 for SEAL. (Source:SA WG6).
Document for: Approval.
Abstract: 23.434 CR0016; 23.434 CR0017; 23.434 CR0019.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200115 (CR PACK) Rel-16 CRs to TS 23.286 for V2XAPP. (Source:SA WG6).
Document for: Approval.
Abstract: 23.286 CR0013; 23.286 CR0016R1; 23.286 CR0014R1; 23.286 CR0015R1; 23.286 CR0018R1; 23.286 CR0017R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

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

17.1 SA WG1 Rel-17 CRs

TD SP-200123 (CR PACK) SA WG1 CRs on TEI17. (Source:SA WG1).
Document for: Approval.
Abstract: 22.011 CR0310R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

17.2 SA WG2 Rel-17 CRs

17.3 SA WG3 and SA WG3 LI Rel-17 CRs

17.4 SA WG4 Rel-17 CRs

17.5 SA WG5 Rel-17 CRs

17.6 SA WG6 Rel-17 CRs

TD SP-200116 (CR PACK) Rel-17 CRs to TS 23.222 for EDGEAPP. (Source:SA WG6).
Document for: Approval.
Abstract: 23.222 CR0067R2.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200117 (CR PACK) Rel-17 CRs to TS 23.282 for eMCData3. (Source:SA WG6).
Document for: Approval.
Abstract: 23.282 CR0199R2; 23.282 CR0208R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200118 (CR PACK) Rel-17 CRs to TS 23.280, TS 23.281 and TS 23.379 for eMONASTERY2. (Source:SA WG6).
Document for: Approval.
Abstract: 23.281 CR0143R1; 23.281 CR0144R1; 23.280 CR0236R1; 23.379 CR0249R2; 23.379 CR0250R2; 23.281 CR0140R2; 23.281 CR0139R3; 23.379 CR0246R5; 23.379 CR0247R5.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

TD SP-200119 (CR PACK) Rel-17 CRs to TS 23.280 for TEI17. (Source:SA WG6).
Document for: Approval.
Abstract: 23.280 CR0233R1.

Comment:

Block4 - Proposed: approved. Block approved.

Discussion and conclusion:

Status:

Approved.

18 CRs related to Study Items (block approval if not otherwise requested)

19 Project Management and TSG SA owned specifications

TD SP-200130 (CR) 21.900 CR0063 (Rel-16, 'F'): OpenAPI specification file storage. (Source:Nokia, Nokia Shanghai-Bell).
Document for: Approval.
Abstract: MCC shall store OpenAPI files extracted from 3GPP specifications at https://forge.etsi.org/rep/3GPP/5G_APIs. This contribution was endorsed by CT WG4 Meeting #96e as C4-200900.

Comment:

Proposed Action: approved. Approved.

Discussion and conclusion:

Status:

Approved.

19.3 Work Item Summaries for TR 21.91x

TD SP-200034 (WI SUMMARY) Summary for work item 'RTCP Verification for Real-Time Services'. (Source:Ericsson LM).
Document for: Endorsement.
Abstract: This summarizes the progress of the new, normative specification accomplished during the course of the RTCPVer work item.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200036 (WI SUMMARY) Summary for work item 'Media Handling Extensions for 5G Conversational Services' (5G_MEDIA_MTSI_ext). (Source:Intel (Rapporteur)).
Document for: Endorsement.
Abstract: This summary reports on the normative specification progress accomplished during the course of the 5G_MEDIA_MTSI_ext work item. The related agreed CRs are in CR 26.114-0436, CR 26.114-0438, CR 26.114-0461, CR 26.114-0480, CR 26.114-0496 and CR 26.223-0013.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200057 (WI SUMMARY) Work Item Summary for RDSSI. (Source:Convida Wireless LLC).
Document for: Endorsement.
Abstract: This contribution adds a work item summary for RDSSI to TR 21.916.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200058 (WI SUMMARY) Work Item Summary for Rel-16 eV2XARC. (Source:LG Electronics).
Document for: Endorsement.
Abstract: Work Item Summary for Rel-16 eV2XARC including SA2, SA3 and CT WGs works.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200124 (WI SUMMARY) Work Item Summary for ATSSS. (Source:ZTE Wistron Telecom AB).
Document for: Endorsement.
Abstract: Summary for Release-16 ATSSS Feature to be used as insertion in 21.916.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200125 (WI SUMMARY) Work Item Summary for eNS. (Source:ZTE Wistron Telecom AB).
Document for: Endorsement.
Abstract: Summary for Release-16 eNS Feature to be used as insertion in 21.916.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200126 (WI SUMMARY) Work Item Summary for Rel-16 V2XIMP. (Source:LG Electronics France).
Document for: Endorsement.
Abstract: Work Item Summary for Rel-16 V2XIMP.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200128 (WI SUMMARY) Summary for work item 'VR QoE Metrics'. (Source:Ericsson LM).
Document for: Endorsement.
Abstract: Work item summary for the VRQoE completion.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200129 (WI SUMMARY) Work Item Summary for 5G_SRVCC. (Source:China Unicom).
Document for: Endorsement.
Abstract: Work item summary for 5G_SRVCC.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200131 (WI SUMMARY) Work Item Summary for User Identities and Authentication. (Source:Deutsche Telekom AG).
Document for: Endorsement.
Abstract: This paper describes the Rel. 16 functionality of the User Identity and Authentication feature.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200215 (WI SUMMARY) Work Item Summary for Provision of Access to Restricted Local Operator Services by Unauthenticated UEs. (Source:Nokia ).
Document for: Endorsement.
Abstract: This WI adds requirements to enhance the 3GPP PS Domain to provide an optional capability to allow unauthenticated UE's to access restricted local operator services based on operator policy and regional regulatory requirements. The requirements address identifying when restricted local operator services are available and enabling a UE to attach to a network for the purpose of accessing a restricted local operator service even if the UE is not able to be authenticated by the network. The requirements can be found in TS 22.101, TS 22.115, and TS 22.228.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200224 (WI SUMMARY) Work Item Summary for SMARTER-Ph2. (Source:VODAFONE Group Plc).
Document for: Endorsement.
Abstract: Work Item Summary for SMARTER-Ph2.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200228 (WI SUMMARY) Work Item Summary for Energy Efficiency of 5G. (Source:Orange).
Document for: Endorsement.
Abstract: Work Item Summary for Energy Efficiency of 5G in SA WG5.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200252 (WI SUMMARY) Work Item Summary for 5G_URLLC. (Source:Huawei).
Document for: Endorsement.
Abstract: This WI aims to enhance 5G core network to support ultra-high reliability and low latency communications. The main features introduced by the WI include supporting of redundant transmission, QoS monitoring, dynamic division of Packet Delay Budget, and enhancements of session continuity mechanism.

Comment:

Block6 - Proposed: endorsed. SP-200252_rev1 endorsed. Revised to SP-200295.

Discussion and conclusion:

Updated proposed by Joachim (Siemens) (mail Tue11:22). SP-200252_rev1 endorsed.

Status:

Revised.

TD SP-200295 (WI SUMMARY) Work Item Summary for 5G_URLLC. (Source:Huawei).
Document for: Endorsement.
Abstract: This WI aims to enhance 5G core network to support ultra-high reliability and low latency communications. The main features introduced by the WI include supporting of redundant transmission, QoS monitoring, dynamic division of Packet Delay Budget, and enhancements of session continuity mechanism.

Convenor comment:

Comment:

Revision 1 of SP-200252. Endorsed.

Parallel:

Status:

Endorsed.

TD SP-200253 (WI SUMMARY) Work Item Summary for 5WWC. (Source:Huawei).
Document for: Endorsement.
Abstract: This WI aimes to enhance 5G core network to support connection of residential gateway connected via wireline access network and via TSG RAN access. Furthermore the WI aimes to support Non-3GPP network as Trusted network in contrast with Untrusted network. The main features introduced by the WI includes the specification of new access network node, called W-AGF (Wireline Access Gateway function), the improvement of registration and session management procedures, policy, QoS etc, tailored to the specific characteristic of wireline access network. The main future for supporting Trusted network includes the definition of architecture with new Trusted Gateway Network Function, selection procedure of such gateway, improvement and extension of registration and session procedures, policy , etc for supporting such scenario.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200254 (WI SUMMARY) Work Item Summary for eNA. (Source:Huawei).
Document for: Endorsement.
Abstract: In order to improve the NWDAF initiated in Rel 15, the eNA (Enablers for Network Automation for 5G) feature specifies the data collected by NWDAF and the NWDAF output (i.e. statistics and predictions) to support network automation. The eNA feature includes: - Architecture enhancements of 5G System to support network data analytics service - A framework to enable data collection and provide analytics to consumers - Extensions to existing Nnwdaf services to support the analytics that are required. In addition, the eNA Work Item is applicable to the eV2XARC Work Item in which the V2X Application Server acting as an Application Function (AF) may consume relevant network data analytics provided by NWDAF for the purposes of adjustment of the application.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200256 (WI SUMMARY) Summary for work Item 'ETSUN'. (Source:Nokia Japan).
Document for: Endorsement.
Abstract: Summary for work Item ETSUN.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200259 (WI SUMMARY) Work Item Summary for Vertical_LAN. (Source:Nokia Japan).
Document for: Endorsement.
Abstract: Work Item Summary for Vertical_LAN.

Comment:

Block6 - Proposed: endorsed. SP-200259_rev1 endorsed. Revised to SP-200296.

Discussion and conclusion:

Joachim (Siemens) proposed re-wording (see drafts folder) Wed8:39. SP-200259_rev1 endorsed.

Status:

Revised.

TD SP-200296 (WI SUMMARY) Work Item Summary for Vertical_LAN. (Source:Nokia Japan).
Document for: Endorsement.
Abstract: Work Item Summary for Vertical_LAN.

Convenor comment:

Comment:

Revision 1 of SP-200259. Endorsed.

Parallel:

Status:

Endorsed.

TD SP-200265 (WI SUMMARY) Work Item Summary for 5GMSG. (Source:China Mobile).
Document for: Endorsement.
Abstract: This work item specifies the service level requirements of the MSGin5G Service and the new requirements of the 5G System to support the MSGin5G Service.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200266 (WI SUMMARY) Summary for WI Charging aspects of ETSUN. (Source:China Mobile).
Document for: Endorsement.
Abstract: SA WG2, CT WG3 & CT WG4 have studied the enhanced topology deployments of SMF and UPF in TR 23.726, TS 23.501 & 23.502. Based on the conclusion, S5 WI ETSUN specify charging support for deployments topologies with specific SMF service areas to line up with the other NF interfaces.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200273 (WI SUMMARY) WI summary for RACS. (Source:Qualcomm Incorporated, MediaTek).
Document for: Approval.
Abstract: Provides WI summary for RACS across RAN, SA and CT.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200274 (WI SUMMARY) Summary for work item 'Cellular IoT support and evolution for the 5G System'. (Source:Qualcomm Incorporated).
Document for: Approval.
Abstract: WI summary for 5G CIOT.

Comment:

Block6 - Proposed: endorsed. Endorsed.

Discussion and conclusion:

Status:

Endorsed.

TD SP-200217 (WI SUMMARY) Work Item Summary for Business Role Models for Network Slicing. (Source:Nokia).
Document for: Endorsement.
Abstract: This WI adds requirements to enable a 3GPP system to adequately support the variety of business role models for network slicing that are possible in a 5G system. The requirements address service exposure giving additional control to 3rd parties, impact of SLAs on network slice management, and non-public network access to MNO spectrum. Also addressed are security relationships between - a UE and a private slice, - a private slice and a network, and - a private slice and other slices of the same network. The requirements are captured in 3GPP TS 22.261.

Comment:

Block6 - Proposed: endorsed. SP-200217_rev1 endorsed. Revised to SP-200294.

Discussion and conclusion:

SP-200217_rev1 endorsed.

Status:

Revised.

TD SP-200294 (WI SUMMARY) Work Item Summary for Business Role Models for Network Slicing. (Source:Nokia).
Document for: Endorsement.
Abstract: This WI adds requirements to enable a 3GPP system to adequately support the variety of business role models for network slicing that are possible in a 5G system. The requirements address service exposure giving additional control to 3rd parties, impact of SLAs on network slice management, and non-public network access to MNO spectrum. Also addressed are security relationships between - a UE and a private slice, - a private slice and a network, and - a private slice and other slices of the same network. The requirements are captured in 3GPP TS 22.261.

Convenor comment:

Comment:

Revision 1 of SP-200217. Endorsed.

Parallel:

Status:

Endorsed.

19.5 MCC Status Report

TD SP-200127 (REPORT) Support Team report. (Source:MCC Director).
Document for: Information.
Abstract: MCC Support Team report.

Comment:

Block1 - Proposed: noted. Noted.

Discussion and conclusion:

Status:

Noted.

19.6 Future Meeting schedule

20 Any Other Business

21 Close of Meeting