SP Meeting #SP-93E DRAFT REPORT

14 - 20 September 2021 - Electronic meeting

 

Source: Secretary of SP

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

Document for: Information

Status: This Report Generated 22-09-2021, 09:15


 

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.

0.1 Executive Summary

1 Opening of the Meeting by e-mail

Tuesday, 14 September 2021, 09:00 UTC

1.1 Welcome Speech

1.2 Introduction

1.3 IPR & Antitrust reminders

1.4 Approval of Agenda

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

TD SP-210800 (AGENDA) Agenda & Procedures & Time Schedule for TSG SA#93-e. (Source: TSG SA Chair).
Document for: Approval.
Abstract: The meeting agenda.

Comment:

This AGENDA was approved.

Discussion and conclusion:

CC#1: The meeting agenda was approved.

Status:

Approved.

TD SP-210831 (AGENDA) TSG SA#93-e GoToMeeting Sessions Agenda & Details. (Source: TSG SA Chair).
Document for: Information.
Abstract: TSG SA#93-e GoToMeeting Sessions Agenda & Details.

Comment:

This will be updated for each conference call. Noted at CC#1.

Discussion and conclusion:

CC#1: This will be updated for each conference call. This was then noted.

Status:

Noted.

1.5 Report from previous SA meetings

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

Comment:

This REPORT was approved.

Discussion and conclusion:

CC#1: The report of meeting TSG SA#92-e was approved.

Status:

Approved.

1.6 Reports from TSG SA ad-hoc meetings and workshops

2 Liaisons Statements

2.1 Incoming LSs - proposed to note

LSs for information - Block 1 (To note Tuesday 15:00 UTC)

TD SP-210807 (LS IN) LS from ITU-R WP5D: LIAISON STATEMENT TO GCS PROPONENTS AND TRANSPOSING ORGANIZATIONS ON THE PROVISION OF TRANSPOSITION REFERENCES AND CERTIFICATION C FOR DRAFT REVISION 5 OF RECOMMENDATION ITU-R M.2012. (Source: ITU-R WP5D (5D_TD_0350_IMT-ADV)).
Document for: Action.
Abstract: Introduction: Working Party (WP) 5D thanks the relevant GCS Proponents for their successful work in regards to completion of the milestone identified by Item 8 of Table 1 for the draft Revision 5 of Recommendation ITU-R M.2012 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications-Advanced (IMT-Advanced)' following the process in Document IMT-ADV/31(Rev.1), 'Schedule for the Revision 5 Update of Recommendation ITU-R M.2012'. WP 5D wishes to inform the GCS Proponents and the Transposing Organizations that during its 38th e-meeting (7-18 June 2021) the specific technology updates for the draft Revision 5 of Rec. ITU R M.2012 (not including the detailed transposition references) were finalized and provisionally agreed. Request to supply transpositions references: WP 5D draws the attention of the Transposing Organizations of LTE-Advanced to the need for each Transposing Organization to provide the relevant transposition references for Section 2 of Annex 1 by the requested firm deadline of 1 September 2021. Request to supply Certification C: Each identified Transposing Organization is required to provide to ITU-R, the Certification C by 1 September 2021. The Certification C is outlined in Document IMT-ADV/25(Rev.2) 'Procedure for the development of draft Revisions of Recommendation ITU-R M.2012' and Document IMT ADV/24 (Rev.3) 'Process and The Use Of Global Core Specification (GCS), References And Related Certifications In Conjunction With Recommendation ITU-R M.2012'. Procedurally, the Certification C from each Transposing Organization should be directed to the Counsellor for ITU R Study Group 5 and not provided as inputs to WP 5D. The Counsellor will prepare as an input to the 39th meeting of WP 5D meeting a summary statement regarding the receipt of the Certification C documents. Completion of relevant business matters: As indicated, there is also the consequential step of, as necessary, the completion of relevant business matters by 1 September 2021 and the indication of compliance with ITU policy on IPR, as appropriate. These matters should be directly addressed between the Transposing Organization and the ITU as appropriate via the contact point of the Counsellor for Study Group 5. Closure of the draft Revision 5 with references in Working Party 5D: At its 39th e-meeting (4-15 October 2021), WP 5D intends to review and seek final agreement of the full consolidated draft Revision 5 of Rec. ITU-R M.2012 including the transposition references. It will then be forwarded to ITU-R Study Group 5 for consideration at its November 2021 meeting in accordance with the ITU-R approval process in Resolution ITU-R 1-8, especially ¨ A.2.6.2. WP 5D looks forward to the continued cooperation with the Transposing Organizations in these final steps on concluding this update of the IMT-Advanced terrestrial radio interfaces.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210808 (LS IN) LS from ITU-R WP5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ENGAGED IN RECOMMENDATION ITU-R M.2012 ON THE SCHEDULE FOR UPDATING RECOMMENDATION ITU-R M.2012 TO REVISION 6. (Source: ITU-R WP5D (5D_TD_0356_IMT-ADV)).
Document for: Information.
Abstract: Working Party (WP) 5D thanks the relevant External Organizations for their on-going work in regard to the Revision 5 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. As formally announced in ITU-R Circular Letter 5/LCCE/93, WP 5D wishes to inform the relevant External Organizations that it is commencing the cycle for the development of the Revision 6 of Recommendation ITU-R M.2012 and provides a detailed schedule for Revision 6 of Recommendation ITU R M.2012. Background: This liaison provides guidance on the revision procedure and the detailed step-by-step schedule to External Organizations regarding updates of the terrestrial radio interfaces in the development of Revision 6 of Recommendation ITU-R M.2012 - Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications-Advanced (IMT-Advanced). 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 6. Schedule: For the Revision 6 of Recommendation ITU-R M.2012 a completion date of the WP 5D meeting #44, currently planned for June 2023, has been chosen. WP 5D announces that the first formal meeting in the meeting cycle ('Meeting Y') of the development of Revision 6 of Recommendation ITU-R M.2012 will be WP 5D meeting #40, which is scheduled for 7-18 February 2022. As explained in the Circular Letter, it should be noted that new technology proposals for IMT Advanced will not be accepted in the updating of Recommendation ITU-R M.2012, applicable on a going forward basis beginning with this Revision 6. The detailed timeline for the Revision 6 of Recommendation ITU-R M.2012 which accommodates the currently planned/anticipated schedule of meetings for WP 5D and Study Group 5 through the 2021 and 2023 time frame and some milestone activities/actions may be found in Document IMT ADV/32 - Schedule for Revision 6 of Recommendation ITU-R M.2012. The dates in Document IMT-ADV/32 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. As appropriate Document IMT-ADV/32 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:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210809 (LS IN) LS from NGMN Alliance Project '5G TDD Uplink': NGMN Liaison Statement to 3GPP Plenary on 5G NR TDD Uplink Throughput. (Source: NGMN Alliance Project '5G TDD Uplink' (210617 LS_from NGMN 5G TDD UL to RAN)).
Document for: Information.
Abstract: Intention of the LS and required actions: In 2021 NGMN Alliance started a new project concerned about finding solutions for improving the 5G TDD Uplink in particular for use cases that are relevant for the vertical industries. This project studies the following - Deploying 5G TDD networks in a multi-operator context requires synchronized operation of adjacent networks and, in particular, the adoption among operators of a compatible frame structure to avoid any BS-BS and MS-MS interference and allow coexistence without the need for guard bands or additional filters supporting efficient spectrum usage. - To avoid potential interference situations and ensure an efficient spectrum usage, regulatory conditions are attached to spectrum rights. In Europe for example, common TDD frame structures at national level are defined for the 3400 - 3800 MHz frequency band (Band n78). Current frame structures consist of 8 timeslots in the downlink (DL) and 2 timeslots in the uplink (UL) which allows a maximum of 180 Mbit/s peak throughput under optimum conditions in the uplink (with 100 MHz spectrum bandwidth, 2x2 UL MIMO and without UL carrier aggregation) and a minimum latency of 2 - 4 ms one-way in the RAN. The obligation to adopt the common national TDD frame structure can possibly be relaxed for local/regional licensing, while obligations to avoid interference remain in place. - On the other hand, there's the need to account for licensees' commercial service needs and the great variety of 5G use cases. - In fact, when working with industries (e. g. manufacturing, entertainment, news production, autonomous vehicles), a much higher uplink capacity is often required. For example, in SA WG1 22.261 there are requirements for cloud rendering and virtual reality which range from 100Mbps up to perhaps Gbps per user in some potential cases; even at the lower end of this requirement support within the constraints discussed in the previous paragraph would be limited to a very small number of users. In other examples from the automotive sector, extracting data from cars on a test track, it would need to be in excess of 600 Mbit/s. Other use cases require UL capacity, which exceeds the current capabilities, e.g. video surveillance with upload from multiple HD cameras. - Furthermore, among the frame structures that are defined for the NR by the 3GPP, currently only a limited subset has been realized by base station vendors, chipset vendors and device vendors. For both bands, n78 (3.5GHz) and n258 (26GHz), NGMN will appreciate, if base station vendors, chipset vendors and device vendors will also make available frame structures that provide a better balance between uplink and downlink throughput. - The scope of this NGMN project is to drive the study of both technical and regulatory solutions for lifting the current limitations to 5G NR uplink capacity, especially in the 3 400 - 3 800 MHz band and including consideration of the 26 GHz band, as appropriate. In addition, the project will correspondingly lobby with regulators as well as chipset and device vendors to represent the service capabilities drawbacks of current implementation limitations and work and act together to achieve the needed implementation flexibility for a more suitable distribution between uplink and downlink for Vertical Industries use cases. Additionally, alternative solutions will be studied together with the partners of the NGMN. Addressing TSG RAN Plenary: NGMN is looking for solutions to the 5G NR uplink challenge for the vertical industries, that are perceiving limitations in realizing their use cases as soon as their uplink requirements are in excess of the currently possible uplink throughput and response times in the public spectrum domain as allowed by current national regulations. NGMN will highly appreciate if 3GPP, as the relevant SDO working on such topic, continues to look for and specify solutions at the 5G NR interface, supporting high throughput uplink and low latency response times flexibly in public (and private) spectrum deployment cases for such vertical industries use cases. NGMN would like to thank you in advance TSG RAN Plenary for cooperation.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210810 (LS IN) LS from ETSI TC ITS: Open contribution or Review of the general C-ITS architecture (EN 302 665) update related to MCO (Multi-Channel Operation), stable draft ETSI TS 103 696 from ETSI TC ITS - 'Intelligent Transport Systems (ITS); C-ITS architecture; Mult. (Source: ETSI TC ITS (ITS(21)043023r3)).
Document for: Information.
Abstract: Draft LS from ETSI TC ITS to external SDOs e.g. 3GPP, IEEE, SAE, CEN/ISO and ITU, European ITS interested organisations C2C-CC, 5GAA, C-ROADS and European projects ENSEMBLE, Concorda, C-ROADS's, InterCor, PROSPECT, XCYCLE, Imagine, AutoPilot, C-Mobile and SafetyCube to provide feedback on the STF 858 work realizing the Multi-Channel Operation (MCO) specifications for ITS with specific operation in the 5.9 GHz spectrum band with current focus on the MCO study mature document TR 103 439.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210811 (LS IN) LS from MulteFire Alliance: LS on MulteFire PLMN-ID . (Source: MulteFire Alliance (MF LS to 3GPP June 2021.)).
Document for: Information.
Abstract: Overall description: MFA would like to thank TSG SA for the reply to MFA liaison statement regarding the use of MFA PLMNID in 5G NR private networks. [TSG SA answer]: It is not within 3GPP mandate to give consent (or deny) to MFA or other organizations to use their PLMN-ID on 5G NR private networks. However, TSG SA can confirm that in current 3GPP specifications, there is no restriction to use any PLMN-ID for 5G NR private network using SNPN as defined in TS 23.501. The description and limitations for SNPNs are described in TS 23.501 and other related 3GPP specifications. Technically the MFA PLMN ID as one option can be broadcasted by 5G NR private networks, using SNPN, without changes to existing 3GPP specifications. 3GPP specification also allow other PLMN-ID options for 5G NR private network, using SNPN. In that respect : MFA acknowledges that according to the 3GPP reply that MFA PLMN ID can be broadcasted by 5G NR private networks. MFA would like to notify TSG SA, that since 3GPP decided to include standalone operation of NR in the unlicensed bands, MFA does not currently consider to work further on the standardization of NR for unlicensed bands. MFA can also confirm that it is dedicated to propagate 5G NR private networks as specified by 3GPP by helping to create a global market for them. Action: MFA would like to reply to TSG SA LS as above.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210812 (LS IN) LS from TM Forum: Multi-SDO Autonomous Networks (AN) Formal Liaison: Request for review of Letter of Intent and report on the 21st of June Formal meeting Ref AN-SDO2021-08. (Source: TM Forum (MSDO_AN_Liasion LoI review 20210624.)).
Document for: Information.
Abstract: Letter of Intent Review Request The M-SDO AN, Formal MSDO meeting#7 on 21st June 2021, reviewed a proposal for an MoU for the Autonomous Networks Multi-SDO Initiative. The objective is to formally establish those who are willing to contribute and be referenced in joint press releases. The meeting agreed to: 1. Rename the proposal as a Letter of Intent - a revised version is attached (which also addresses some concerns about the length of the opportunities list being too ambitious). 2. Request each participating SDO to provide a preliminary response on two questions: a. Do you have comments on the attached Letter of Intent proposal? b. Indicate when your SDO could formally agree to the Letter of Intent and provide some indication of your internal process that would need to be satisfied (will depend on each SDO internal procedures). We would be grateful for a response with the timeframe suggested at the workshop, I.e., within two weeks, 5th July 2021. At the meeting, we also reviewed a specific initial joint work proposal - WP02 Landscape and Roadmap for Autonomous Networks (Operations Focus) - as a practical example of work to perform under the Letter of Intent. Results of 21st June 2021 M-SDO AN Formal Liaison Meeting #7 The notes of this meeting are attached and are also available on the shared workspace at: - 2021-06-21 M-SDO AN Formal Liaison Meeting notes #7 We identified several actions, the main points being: - To set up a joint working paper area to address WP02 Landscape and Roadmap for Autonomous Networks (Operations Focus). - To schedule a discussion of a proposal for a joint paper based on the IEEE WP04 proposal: Overarching Blueprint of Common Operational Principles of Autonomic/Autonomous Networks. - The meeting also identified that the meeting schedule that we agreed on has conflicts with a SA WG5 meeting in August. We decided to reschedule meetings as follows: - August 23rd meeting rescheduled to the 16th of August 2021. - August 30th meeting rescheduled to 6th of Sept 2021. - A copy of the revised meeting schedule for the Formal SDO meetings is attached in Annex B. We also identified a need to address the IPR arrangements for MSDO Joint White Papers. TM Forum took an Action: to come back to the MSDO Formal Group with an IPR proposal for discussion. Regards, Cecilia Ortega Lagos TM Forum.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210813 (LS IN) LS from ITU-R WP5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ON THE SCHEDULE FOR UPDATING RECOMMENDATION ITU-R M.2150 TO REVISION 'AFTER YEAR 2021. (Source: ITU-R WP5D (R19-WP5D-210607-TD-0353!!MSW-E_rev_out.)).
Document for: Information.
Abstract: Introduction: Working Party (WP) 5D thanks the relevant External Organizations for their work regarding Recommendation ITU-R M.2150 - 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications-2020 (IMT-2020)'. As formally announced in ITU-R Circular Letter 5/LCCE/94, WP 5D wishes to inform the relevant External Organizations that it is commencing the cycle for the development of the Revision 'After Year 2021' of Recommendation ITU-R M.2150 and provides a detailed schedule for Revision 'After Year 2021' of Recommendation ITU R M.2150. Background: This liaison provides guidance on the revision procedure and the detailed step-by-step schedule to External Organizations regarding updates of the terrestrial radio interfaces in the development of Revision 'After Year 2021' of Recommendation ITU-R M.2150 'Detailed specifications of the terrestrial radio interfaces of International Mobile Telecommunications-2020 (IMT-2020)'. Procedure: The procedure outlined in document IMT-2020/57 Procedure for the development of draft revisions of Recommendation ITU-R M.2150 applies to the development of this Revision 'After Year 2021'. Schedule: For the Revision 'After Year 2021' of Recommendation ITU-R M.2150, a completion date of the WP 5D meeting #44, currently planned for June 2023, has been chosen. WP 5D announces that the first formal meeting in the meeting cycle ('Meeting Z') of the development of Revision 'After Year 2021' of Recommendation ITU-R M.2150 will be WP 5D meeting #40, which is scheduled for 7-18 February 2022. While the deadline for receipt of 'complete' new candidate technology submissions is established in the schedule as WP 5D meeting No. 40, proponents of new candidate technology proposals are strongly encouraged to notify WP 5D at the meeting No. 39 (October 2021) of their intentions to submit so that the process, including the invitation for the registration of IEGs, could proceed in due time to support the downstream process timings. The detailed timeline for the Revision 'After Year 2021' of Recommendation ITU-R M.2150 which accommodates the currently planned/anticipated schedule of meetings for WP 5D and Study Group 5 through the 2021 and 2023 time frame and some milestone activities/actions may be found in Document IMT-2020/58 Schedule for Revision 'After Year 2021' of Recommendation ITU-R M.2150. For convenience it is also enclosed to this liaison as Attachment. The dates in Document IMT-2020/58 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. As appropriate, Document IMT-2020/58 may 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. The Radiocommunication Bureau maintains the IMT-2020 section on the web page of WP 5D which may be updated dynamically to provide additional information on the revision activities and to facilitate the development of update and new proposals and the work (if necessary) of the evaluation groups. 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:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210814 (LS IN) LS from ITU-R WP5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS Development of 'IMT Vision for 2030 and beyond'. (Source: ITU-R WP5D (R19-WP5D-210607-TD-0383!R1!MSW-E)).
Document for: Action.
Abstract: ITU-R has previously developed Recommendation ITU-R M.1645 (IMT Vision for 2010 and beyond) and then Recommendation ITU-R M.2083 (IMT Vision for 2020 and beyond). From the 37th meeting in March 2021, ITU-R Working Party 5D (WP 5D) has started to develop a draft new Recommendation on IMT Vision for 2030 and beyond. This Recommendation can be helpful to drive the industries and administrations to encourage further development of IMT for 2030 and beyond. This Recommendation will define the framework and overall objectives of the future development of IMT for 2030 and beyond, including the role that IMT could play to better serve the needs of the future society, for both developed and developing countries. For the development of this draft new Recommendation, WP 5D would like to invite the views of External Organizations on the IMT Vision for 2030 and beyond, including but not limited to, user and application trends, evolution of IMT, usage scenario, capabilities and framework and objectives. External Organizations are invited to submit material preferably to the 39th meeting of WP 5D but no later than the 41st meeting of WP 5D, as appropriate. Please check the WP 5D website for latest information of the coming WP 5D meetings: http://www.itu.int/ITU-R/go/rwp5d. Working Party 5D looks forward to receiving views on the new Recommendation on IMT Vision for 2030 and beyond. WP 5D looks further forward to collaborating with External Organizations on this matter.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210815 (LS IN) LS from ITU-T SG13: LS on the new work item ITU-T Y.NGNe-IBN-arch: 'Functional architecture of NGN evolution by adoption of Intent-Based Network'. (Source: ITU-T SG13 (SG13-LS221)).
Document for: Information.
Abstract: During the ITU-T SG13 virtual meeting (5-16 July 2021) Q2/13 (Next-generation network (NGN) evolution with innovative technologies including software-defined networking (SDN) and network function virtualization (NFV)) created a new work item on 'Functional architecture of NGN evolution by adoption of Intent-Based Network' (Y.NGNe-IBN-arch: TD621/WP3). ITU-T Y.NGNe-IBN-arch aims to provide the general functional architecture of NGNe by adoption of the Intent-Based Network, specifies its functional entities and defines the detailed functionalities of these functional entities, and aims to continue the research of the Intent-Based Network especially concerning the implementation and realization in NGNe. ITU-T Q2/13 would like to thank you for your attention, feedback and cooperation on this topic. In addition, please find below the A.1 justification form for the new work item Y.NGNe-IBN-arch.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210816 (LS IN) LS from 5GAA WG4: LS on MCO TS 103 696 . (Source: 5GAA WG4 (5GAA_S-210137)).
Document for: Information.
Abstract: 5GAA thanks ETSI TC ITS for the invitation to comment on draft TS 103 696. 5GAA would like to share two high-level comments as follows. First, 5GAA would like to ask if all the content in clause 5 'Essentials' are essential of MCO architecture. For example, it is difficult to find the essentialness and relevance to MCO concept from the clauses 5.4.2 'C-ITS hybrid communication architecture' and 5.4.3 'C-ITS time and location in the C-ITS constellations'. Second, 5GAA would also like to ask if the opening topics of clause 7 on 'layers and planes', and 'SAPs and interfaces' are focused on MCO extensions, or general issues of Release-1 architecture. If the latter is the case, we would like to ask if it is in work scope of the STF 585.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210817 (LS IN) LS from GSMA NG: New Whitepaper: 'E2E Network Slicing Architecture'. (Source: GSMA NG (E2E-NS WP Publish LS)).
Document for: Information.
Abstract: INTRODUCTION: The GSMA, one of the Market Representation Partners of 3GPP, have a project concerning End to end Network Slicing under the Network Group (NG). The project aims to identify potential gaps in standards and input recommendations to the related organisations toward the realisation of Network Slicing architecture designed from an End-to-End (E2E) perspective. This E2E notion means network slicing capabilities need to be integrated across the different domains (e.g., device, access network, core network, transport network and network management system), so that Service Level Agreement based on customers' requirements can be guaranteed. The GSMA NG would like to inform related organisations that the GSMA Whitepaper NG.127 'E2E Network Slicing Architecture' has been published on gsma.com at : https://www.gsma.com/newsroom/resources/ng-127-e2e-network-slicing-architecture-v1-0/ . The intention of this whitepaper is to show guidance of the entire industry ecosystem; for operators, vendors and service providers to be able to consider common solutions of network slicing which have not been fully defined yet. The scope of this whitepaper is to provide the description of: 1. Blueprint of E2E Network Slicing Architecture, 2. Technology aspect, 3. Ongoing SDOs and open-source projects, which are snapshot based on current status of these standardization activities, typically activities of the 3rd Generation Partnership Project (3GPP) Release 17. Action: The GSMA NG kindly asks related organisations to take our whitepaper into consideration for their standardisation work on E2E network slicing as well as provide feedback on our whitepaper.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210968 (LS IN) LS from ETSI ISG IPE: Liaison from ISG IPE on IPv6 Enhanced Innovation Gap Analysis. (Source: ETSI ISG IPE (IPE(21)000088)).
Document for: Information.
Abstract: ISG IPE is pleased to inform you of the latest GR of ETSI ISG IPE (IPv6 Enhanced Innovation) on 'IPv6 Gap Analysis' published in August 2021. IPE expects that this could be of interest to your committee. This deliverable has the following goals: - Identify gaps of existing IPv6 standards in both ETSI and other SDOs that need to be resolved to accelerate IPv6-based innovations - Communicate the identified gaps and corresponding recommendations for improvement to suitable ETSI TCs / ISGs and other SDOs. The major findings of the document are: - IPv6 has made much progress in last 5 years. The 'user device - network - content' value chain is ready for the first time in history. IPv6 already represents about 45% of Internet users (Google + China statistics). - IPv6 is different from IPv4, not just by bigger address space. IPv6 has more advanced functionalities that should be considered during all stages of the IP network lifecycle: design, development, support, and maintenance. Negligence to do so may lead to a sub-optimal deployment. - It is possible to transition overlay/services to IPv6 separately from underlay/infrastructure. It creates the possibility to split IPv6 transition into several stages and make them more manageable. Service transition typically has higher priority than infrastructure migration because address shortage typically happens first. - IPv6 does not have critical gaps that may prevent IPv6 transition. Meanwhile, IPv6 has many standardization activities for new and advanced functionalities that are not available in IPv4. - IPv6 progress in different countries and companies is very different. Lack of IPv6 knowledge and capacity building were the main reasons for fast IPv6 adoption. - New services like 5G, Cloud, IoT, and SD-WAN raise new requirements for the networks: ubiquitous resilient connectivity, ultra-high bandwidth, deterministic quality, low latency, automation, and security. IPv6 enhanced innovations like Proactive ND, SRv6, iOAM and BIER over IPv6 are needed to meet such requirements. The conclusions are: - IPv6 is about addressing the future of the Internet. and of any organization. It is possible to postpone the IPv6 transition for many organizations, but it is not possible to avoid it. Therefore, it is better to plan for IPv6 as soon as possible to avoid unnecessary investment in IPv4. The IETF has already warned the Internet community to move to IPv6 as IPv4 will not be maintained in the future. - The move to IPv6-Only by 2025 has been launched by the US government policy in June 2021. - China has also published its single stack (IPv6-Only) policy in July 2021: https://www.theregister.com/2021/07/26/china_single_stack_ipv6_notice/ - Section 5 analyses the typical technology challenges for IPv6 transition and concludes that IPv6 is fundamentally different from IPv4. Hence, it is important to account for the differences during the design, implementation, and support phases of the networking lifecycle. - Section 6 provides insight into the non-technical challenges. It is important to prepare the organizations, people, business processes, and tools for the transition to the new technology. - Section 7 has the overview of new technologies that are in development specifically for the requirements of new scenarios discussed in section 4. It is important to point out that IPv6 enhanced innovations discussed in section 7 do not have equivalents in IPv4. Hence, these requirements do not create the challenge for the transition from IPv4. - Following the proper guideline and best practices, IPv6 transition can be deployed almost for free. There are no general gaps that prevent this transition in any scenario. It is time to finalize the IPv6 transition plan to avoid unnecessary investments. It is key to request readiness for hardware and software at any refreshment cycle. ISG IPE invites interested parties to provide feedback.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210969 (LS IN) LS from RAN WG2: Reply LS on Inclusive language for ANR. (Source: RAN WG2 (R2-2108869)).
Document for: Action.
Abstract: RAN WG2 would like to thank SA WG5 for the LS on Inclusive language for ANR. RAN WG2 concludes the terminology chosen by SA WG5 differs from the terminology chosen by RAN WG2, where RAN WG2 has chosen to use the term 'exclude-list' to replace 'black-list'. RAN WG2 wonders if there would be issues if the terms are not fully aligned. RAN WG2 understands that RAN plenary (but not CT and SA plenary) appointed a contact person for cross-TSG coordination on this matter. Action: RAN WG2 asks SA and CT to consider appointing a coordinator for inclusive language to work together with the RAN coordinator for inclusive language on cross-TSG questions.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted
CC#2: A coordinator for TSG SA was requested. The coordinator role is to check that consistent terminology is used throughout the SA WGs. The SA WG2 Chair, Puneet Jain volunteered to take on this task. The SA WG6 Chair suggested there should also be a coordinator for CT WGs. This will be reviewed with the TSG CT Report.

Status:

Noted.

TD SP-210970 (LS IN) LS from RAN WG3: Reply LS on Inclusive Language for ANR. (Source: RAN WG3 (R3-214289)).
Document for: Information.
Abstract: RAN WG3 thanks SA WG5 for the LS on inclusive language for ANR. RAN WG3 has endorsed the attached CR, fixing ANR terminology and aligning toward RAN WG2's and RAN WG4's choice. The endorsed CR will be agreed by RAN WG3 at the end of Rel-17 according to the inclusive language way of working. RAN WG3 agrees that a common approach across WGs to align the replaced terminology seems beneficial. For your information, the attached discussion document was also discussed, and it was recommended to Specification Rapporteurs to improve alignment with other WGs where it makes sense.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210971 (LS IN) LS from RAN WG3: Response LS on PWS Support over SNPN. (Source: RAN WG3 (R3-214402)).
Document for: Action.
Abstract: RAN WG3 thanks SA for the Reply LS on Support of PWS for NPN. RAN WG3 has endorsed the attached draft CR for TS 38.300, which removes the existing stage 2 restriction, from RAN WG3 point of view. RAN WG3 requests RAN WG2, as the group responsible for TS 38.300, to take this endorsement into account, and proceed as RAN WG2 sees fit (i.e. use this CR, merge or implement an equivalent RAN WG2 CR, if agreeable). RAN WG3 would also like to inform SA that no stage 3 changes have been considered essential at this point in RAN WG3 specifications. RAN WG3 may revisit this topic in rel-17 if any such changes are identified. Action: RAN WG3 respectfully requests TSG SA and RAN WG2 to take the above into account.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210972 (LS IN) Reply LS on support of PWS over SNPN. (Source: SA WG1 (S1-213120)).
Document for: Information.
Abstract: SA WG1 thanks CT WG1 for the LS and respond to the questions. Question-1 to SA WG1: Can an SNPN support emergency services but not support PWS, in a country where PWS is deployed? Yes; it is possible that, subject to regional or national regulatory requirements, an SNPN may support emergency services but not support PWS in a country where PWS is deployed. Question-2 to SA WG1: Is there a need for the UE to prioritize SNPNs supporting PWS over SNPNs not supporting PWS for SNPN selection: - when the UE is in limited service state and SNPN-1 supporting PWS and SNPN-2 not supporting PWS, are available; or - when the UE is not in limited service state, SNPN-1 supporting PWS and SNPN-2 not supporting PWS are available, and SNPN-1 and SNPN-2 are otherwise of the same priority for SNPN selection by the UE? No; there is no need for a UE to prioritise SNPNs supporting PWS over SNPNs not supporting PWS for SNPN selection in either scenario shown in Question 2.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210973 (LS IN) LS from SA WG1: LS on Non-territorial emergency or distress call. (Source: SA WG1 (S1-213210)).
Document for: Information.
Abstract: 3GPP has undertaken a study in the group SA WG1 to consider the regulatory implications of extra-territorial communications for telecommunications standards. 3GPP standards have regulatory requirements, specifically services such as emergency call, public warning system and lawful interception. In the course of this study, SA WG1 has considered how these regulatory services apply when a user and their user equipment is located beyond any territory, as a passenger in an aircraft that is not over sovereign territory. It is possible for a passenger with a mobile telecommunications terminal to access network communications. We would be grateful if you could provide or indicate references to guidelines or recommendations whether and how to handle emergency calls made by passengers in aircraft using telecommunications equipment. SA WG1 seeks to conclude their recommendations on regulatory aspects of non-terrestrial telecommunication at their November meeting this year. Please, if it is possible, provide feedback so that we can take it into account at that meeting.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210974 (LS IN) Reply LS on UAS terminology alignment. (Source: SA WG1 (S1-213256)).
Document for: Action.
Abstract: SA WG1 thanks TSG SA for the LS requesting the alignment of UAS terminology in Rel-17 specifications of TS 22.125 about the change of term of 'Unmanned' to 'Uncrewed'. SA WG1 has agreed the corresponding alignment as attached CR. Action: SA WG1 respectfully asks TSG SA to take the above into consideration.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210976 (LS IN) LS from SA WG2: Rely LS to Liaison Statement on 5G & Wi-Fi RAN Convergence. (Source: SA WG2 (S2-2106533)).
Document for: Information.
Abstract: SA WG2 thanks WBA for the information on the 5G & Wi-Fi RAN Convergence activity and the related whitepaper. 3GPP has completed the Rel-17 normative work in the areas of ATSSS, Wireline access, Trusted and Untrusted Non-3GPP access defined in TS 23.501, TS 23.316, TS 23.502 and TS 23.503. SA WG2 would like to inform WBA that several Rel-18 proposals for improvements in the above areas are currently under discussion in SA WG2. However, the final decision on which of the potential proposals would be finally part of Rel-18 is under SA responsibility and currently is planned to be decided in December TSG SA plenary.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210977 (LS IN) LS on Reliable Data Service Serialization Indications in Rel-16. (Source: SA WG2 (S2-2106536)).
Document for: Information.
Abstract: SA WG2 thanks CT WG1 for their LS on Reliable Data Service Serialization Indications (S2-2105225/C1-207769) and indicating that 'CT WG1 has agreed the RDSSI WID in Rel-17 to implement the Reliable Data Service Serialization Indication feature in stage 3, whereas the corresponding stage 2 requirements are in Rel-16.' SA WG2 would like to indicate that, in Rel-16, the Reliable Data Service Serialization Indication feature has been removed from TS 23.682, TS 23.501, and TS 23.502. The associated CRs are attached.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210978 (LS IN) LS on EPS support for IoT NTN in Rel-17. (Source: SA WG2 (S2-2106679)).
Document for: Information.
Abstract: SA WG2 would like to inform TSG RAN that in view of RAN#92e approval of a new Work Item (RP-211601) to introduce IoT NTN support in EPS in Rel-17, it has agreed the attached Rel-17 Work Item to be sent for approval to SA#93e/Sep2021.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210980 (LS IN) Reply LS on OAuth2 misalignments between SA WG3 and CT WG4 specifications. (Source: SA WG3 (S3-213193)).
Document for: Information.
Abstract: SA WG3 thanks CT for their LS on OAuth2 misalignments between SA WG3 and CT WG4 specifications. SA WG3 would like to inform that SA WG3 has followed the requested action. SA WG3 chose to handle Rel-15 and Rel-16 with the changes in the CR S3-213178 (with Rel-16 mirror CR in S3-213177), while handling Rel-17 with the changes in the CR S3-213189. The two baseline CRs for Rel-15 and Rel-17 are attached. Action: SA WG3 kindly asks TSG CT, CT WG4 and TSG SA to take this information into account.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210981 (LS IN) LS on PSCELL ID availability in SGW CDR. (Source: SA WG5 (S5-214069)).
Document for: Information.
Abstract: SA WG5 thanks ETSI TC LI for their reply LS on making PSCELL ID available at the SGW of EPC, and SA WG2 for their LS (S5-213031/ S2-2100248) informing SA WG5 on availability of procedures for MME passing the PSCell ID information to SGW in Rel-17 TS 23.401. Based on availability of the PSCELL ID in the SGW by SA WG2 solution, SA WG5 has introduced this PSCELL ID in the Rel-17 SGW charging information and SGW-CDR definition in TS 32.251, with the corresponding stage 3 ASN.1 CDR agreed CR to TS 32.298 (S5-214068). SA WG5 would like to summarize for ETSI TC LI, about the availability of the PSCell Id in both 5GC and EPC CDRs for billing system, allowing CSPs to comply with Retained Data regulations, as follows. - 5GC: Rel-16 CHF CDRs for AMF specified in TS 32.256 with stage 3 TS 32.298 - EPC: Rel-17 SGW CDRs specified in TS 32.251 with stage 3 TS 32.298.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210982 (LS IN) LS from SA WG5: LS on Multi-SDO Autonomous Networks (AN) Letter of Intent proposal. (Source: SA WG5 (S5-214514)).
Document for: Action.
Abstract: SA WG5 wishes to thank TM Forum for the LS on Request for review of Letter of Intent and report on the 21st of June Formal meeting Ref AN-SDO2021-08, and we would like to give the following feedback and comments: As said at the MSDO meeting the 16th August, we would like the LoI to be more like statement of direction (like a press release) - without any binding commitment for some deliverables, and not to set too high expectations - any output documents e.g. Joint White Paper should be agreed by all participating SDOs case by case. We believe that the planned publications/deliverable(s) Solutions/specifications can only be published in each SDO following their applicable working procedures and IPR rules. We are happy to collaborate on harmonised definitions for AN, but it is each SDO's decision to update their respective definitions taking input proposals from this effort. We thought this would be the initial objective of this effort, and work beyond that can be then discussed and agreed after we have analysed the results of the first phase. At the current stage, we think the cooperation with participating organizations will need to be based on compatible IPR policies. We also need to check the response from '3GPP legal' before we can approve the LoI (especially regarding IPR rules, copyright, planned deliverables). Finally, some comments on the text in the first LoI proposal: - We feel that the description of state of the industry standards in clause 1 (The AN Challenge) is too negative - e.g. 'Existing 'silo' solutions have not yet demonstrated sufficient business value' and 'Lack of E2E view/framework, no interoperability'. - '-to build the next wave of intelligent and autonomous systems' in clause 4 sounds as if this multi SDO effort is aiming to deliver a new set of standards, like a new SDO.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210983 (LS IN) LS from SA WG5: LS reply to LS reply to 3GPP SA5 on Network Slice EE KPIs. (Source: SA WG5 (S5-214535)).
Document for: Information.
Abstract: SA WG5 would like to thank GSMA 5GJA for your LS on the network slice EE KPI informing SA WG5 about the update of the definition of the energy efficiency attribute in NG.116 clause 3.4.7 according to the 3GPP TS 28.554. SA WG5 would also like to inform GSMA 5GJA that the energyEfficiency attribute has been introduced in TS 28.541 (https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3400), as an attribute of the ServiceProfile data type which captures the network slice related requirements that should be supported by the NetworkSlice instance(s) in the 5G network.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210984 (LS IN) LS from SA WG5: LS to ETSI NFV on MANO performance measurements accuracy to estimate VNF energy consumption. (Source: SA WG5 (S5-214607)).
Document for: Information.
Abstract: SA WG5 (Telecom Management) has an ongoing Rel-17 study on new aspects of Energy Efficiency (EE) for 5G networks. One of the key issues addressed in this study is the definition of the EE KPI for a 3GPP network function, which is the ratio between some characteristic performance measurement of the network function (not detailed here, on purpose), and the Energy Consumption (EC) of the network function. {. . .}.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-210985 (LS IN) LS from ITU-T SG13 WP3: LS on information about draft Recommendation ITU-T Y.frd: 'Framework and Requirements of Network-oriented Data Integrity Verification Service based on Blockchain in Future Network'. (Source: ITU-T SG13 WP3 (SG13-LS212)).
Document for: Information.
Abstract: ITU-T Study Group 13, Q1 is progressing development of a draft ITU-T Recommendation Y.frd ' Framework and Requirements of Network-oriented Data Integrity Verification Service based on Blockchain in Future Network' in the virtual meeting (5-16 July 2021). This Recommendation describes the reference architecture of the network-oriented DIVS in relation to the data integrity verification and network capability exposure. The draft text is attached and will be further developed in future Q1/13 meetings. We thank you for your time and expertise, and look forward to cooperation and collaboration on this topic.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

TD SP-211095 (LS IN) LS from Automotive Edge Computing Consortium (AECC): LS on Prioritized Vehicle to Cloud Technical Solutions. (Source: AECC (AECC_3GPP_LS_final)).
Document for: Action.
Abstract: Overall Description: The Automotive Edge Computing Consortium (AECC, https://aecc.org/) was launched in February 2018 as a global consortium of automotive, telecommunication, cloud and mobility service companies. AECC is greatly interested in accelerating the deployment of automotive services based on network and distributed computing infrastructure. Such a goal is also achieved by identifying, developing and accessing functional and performance requirements of access networks and compute platforms, that are deemed important to enable prioritized and high-value automotive services. To this extent, AECC will require standardized solutions which are industry-wide aligned and introduced in the market. Use Case Development Working Group in AECC aims to develop use cases and requirements for the connected vehicles industry. The most relevant use case scenarios with 3GPP are intelligent driving, high-definition maps, vehicle-to-cloud cruise assist, and multi-tenant systems. Further details can be found in the attached AECC General Principle and Vision White Paper. Technical Solution Working Group in AECC focuses on developing and recommending technical solutions for the connected vehicles industry based on the requirements defined by the AECC service scenarios and use cases. The technical solution recommendations by AECC on edge data offloading, mobility service provider server selection and vehicle system reachability are in line with 3GPP Rel-17 work items. Also, AECC would like to share information about some new key issues that have been identified as important from connected vehicles industry perspective. The new key issues are access network selection, provisioning and configuration update and opportunistic data transfer. For AECC's recommendations to address these key issues, AECC would from a technical solution perspective recommend 3GPP in the Rel-18 development to study the technical gaps, and develop corresponding solutions for any identified one. For example, for key issue access network selection, a mechanism to expose information about network status to UE OS/Apps layer. Further details can be found in the chapters 3.4.3, 3.5.3 and 3.6.3 of the attached Technical Report. Another track of work undertaking in the AECC Technical Solution Working Group is around distributed computing architecture. AECC has defined the preliminary service and architecture level requirements as well as an initial functional architecture for distributed computing in the context of automotive edge computing. AECC would ask 3GPP to kindly take AECC service requirements and system architecture into account in 3GPP Rel-18 specification development as well. More technical details can be found in the attached Distributed Computing White Paper. Action: AECC kindly invites 3GPP to review and provide feedback to the attached white papers and technical report.

Comment:

Noted.

Discussion and conclusion:

CC#1: Block Noted.

Status:

Noted.

2.2 Incoming LSs which need an outgoing LS

TD SP-210802 (LS IN) LS from 5G-ACIA: 5G capabilities exposure for factories of the future - revised . (Source: 5G-ACIA (5G-ACIA_LS_3GPP_Exposure_18032021)).
Document for: Action.
Abstract: 5G-ACIA published a white paper in June 2020 on the exposed 5G capabilities that are needed by factory operators to manage and maintain industrial 5G devices and 5G Non-Public Networks (NPN) in a simple and efficient manner. That white paper has now been enhanced to include additional capabilities and some clarification to the capabilities and functions from the previous version of the white paper. In particular, device-centric requirements have been clarified and a few new ones added in accordance with SA WG1 requirements of Release 17. Concerning net-work-centric requirements, network monitoring have been detailed in the Annex of the white paper. Also, the Annex now lists parameters for QoS monitoring. Since 5G-ACIA believes that these service exposure requirements are valuable to be considered in ongoing work in 3GPP, we would like to make this new white paper availa-ble to you: - White paper title: Exposure of 5G capabilities for connected industries and automa-tion applications - Link www.5g-acia.org/publications - PDF copy: attached to this liaison statement 5G-ACIA would be eager to receive 3GPP's feedback on these new exposure interface requirements and related Stage-2 and Stage-3 work.

Comment:

Revision of Postponed SP-210281 from SP-92E. Response drafted in SP-211019. Final response in SP-211134.

Discussion and conclusion:

CC#1: Response drafted in SP-211019.

Status:

Replied to.

TD SP-210803 (LS IN) LS from SA WG2: LS on 5G capabilities exposure for factories of the future. (Source: SA WG2 (S2-2104794)).
Document for: Action.
Abstract: SA WG2 discussed the LS from 5G-ACIA, and would like to: 1. Suggest that TSG SA co-ordinates the answers from SA WG1, SA WG2, SA WG3 and SA WG6 to provide a single response from 3GPP perspective, 2. Inform SA plenary that SA WG2 plans to provide its technical input from SA WG2#146E August meeting i.e. for the September TSG SA plenary. Action: SA WG2 kindly asks TSG SA, SA WG1, SA WG3 and SA WG6 to take the above suggestion into account.

Comment:

Revision of Postponed SP-210457 from SP-92E. Noted.

Discussion and conclusion:

CC#1: This LS was noted.

Status:

Noted.

TD SP-210804 (LS IN) LS from SA WG5: LS to SA for a coordinated reply to 5G ACIA on -5G capabilities exposure for factories of the future-. (Source: SA WG5 (S5-213448)).
Document for: Action.
Abstract: SA WG5 has received the LS 'S5-213024: LS (5G-ACIA-LS-2020-WI039)' from 5G-ACIA on 5G capabilities exposure for factories of the future, and we wish to inform SA of our view to be taken into account in a coordinated reply from TSG SA. SA WG5 specifies 5G network management capabilities including: a) Network Element / Network Function management, e.g. RAN and CN NE/NF management b) Network management (including network slice management in a scenario such as 'NOP internals' - cf. TS 28.530), c) Service management (including network slice management in a scenario such as 'Network Slice as a Service' (NSaaS) - cf. TS 28.530). 3GPP 5G Management Services (MnS) offered by the 5G management system act on network elements / network functions, networks and services, and may be exposed to external consumers. The 3GPP exposure governance management function is in charge of management service exposure governance. 3GPP MnS consumers may be in the Network Operator (NOP) domain or outside the NOP domain (e.g. in the Vertical domain). SA WG5 is responsible for the specification of the 5G Management Services, as well as for the specification of the access control and exposure of 5G management services. Regarding the reference points in 5G-ACIA, both En and Nm reference points are related to SA WG5, and we believe they are used to address management exposure aspects. - 5G-ACIA 5G exposure reference point En supports interactions between 3GPP MnS producers and their consumers for network monitoring as described in section 4.3.1 and 9.2.1 of 5G-ACIA White Paper. The 3GPP Fault Supervision MnS and Performance management MnS can be used to support network monitoring. This also includes monitoring of a logical network e.g. network slice. - 5G-ACIA 5G exposure reference point Nm supports interactions between 3GPP MnS producers and their consumers for network configuration and maintenance as described in section 4.3.2 of 5G-ACIA White Paper. The 3GPP Provisioning MnS can be used to support network configuration and maintenance. This also includes the add, modify and remove logical networks e.g. network slice. Actions: 1. Please take the above information into account in the coordinated reply to 5G ACIA. 2. Please keep SA WG5 informed of the progress of their work on 5G capabilities exposure for factories of the future, especially on the network management related topics.

Comment:

Revision of Postponed SP-210462 from SP-92E. Noted.

Discussion and conclusion:

CC#1: This LS was noted.

Status:

Noted.

TD SP-210805 (LS IN) LS from SA WG6: LS on 5G capabilities exposure for factories of the future. (Source: SA WG6 (S6-211497)).
Document for: Action.
Abstract: SA WG6 discussed the incoming LS from 5G-ACIA on 5G capabilities exposure for factories of the future - revised in SA WG6#43-e, and decided: 1) Follow the decision of other involved WGs and request SA to provide a coordinated reply to 5G-ACIA; 2) Provide an input to SA about the work SA WG6 has addressed related to the 5G-ACIA white paper to be considered for the coordinated SA reply. Therefore, SA WG6 would like to request SA to coordinate such a reply to 5G-ACIA and take into consideration the following input about the related SA WG6 work. SA WG6 has addressed service layer exposure requirements for industrial applications within Release 17 in the study on application layer support for Factories of the Future in 5G network. This study was done based on 5G network exposure capabilities and SA WG1 requirements. The SA WG6 study is documented in the technical report 3GPP TR 23.745. As described in the latest version of 3GPP TR 23.745, identified key issues, solutions and conclusions at the application enablement layer have been addressed which may be of interest of 5G-ACIA. For instance, device management requirements on device identity management, device connectivity management (e.g. for time sensitive communication support, TSN support, QoS monitoring), device connectivity monitoring, device group management (e.g. 5GLAN group management) and device location information are some of the addressed key issues within the SA WG6 study. Other requirements have also been addressed within this study, e.g. clock synchronization. Also, some of the concluded solutions in 3GPP TR 23.745 have already been specified in Release 17 as part of enhancements to the Service Enabler Architecture Layer for Verticals (SEAL) in the technical specification 3GPP TS 23.434. Besides, SA WG6 would like to request 5G-ACIA to provide any feedback on the completed work in 3GPP TR 23.745 and the solutions introduced in SEAL in order to continue the collaboration on service exposure capabilities for industrial applications. Likewise, SA WG6 would like to ask 5G-ACIA to encourage its members to actively engage in the related SA WG6 activities.

Comment:

Revision of Postponed SP-210560 from SP-92E. Noted.

Discussion and conclusion:

CC#1: This LS was noted.

Status:

Noted.

TD SP-210979 (LS IN) LS from SA WG2: LS on 5G capabilities exposure for factories of the future . (Source: SA WG2 (S2-2106683)).
Document for: Action.
Abstract: SA WG2 have discussed the 5G ACIA LS S2-2105229 and its companion white paper. SA WG2 informs SA plenary that: a. Some requirements of 5G_ACIA whitepaper on 5G capabilities exposure for factories of the future are already satisfied by SA WG2 WIDs (i.e. Rel-15 5GS_Ph1, Rel-16 Vertical_LAN, Rel-17 IIOT and eNPN) while some are not. b. 3GPP is working on SA WG2 Rel-18 scope, i.e. which study and work items with their respective objectives will be part of release 18. Which study and work items will finally be part of Release 18 scope depends very much on the respective support by individual 3GPP members. Therefore, SA WG2 would also like remind 5G-ACIA that individual members need to directly engage in the related SA WG2 activities in order to increase likelihood that ACIA requirements will be covered. Action: SA WG2 kindly asks TSG SA to take the above information into account.

Comment:

Noted.

Discussion and conclusion:

CC#1: This LS was noted.

Status:

Noted.

TD SP-211019 (LS OUT) [DRAFT] Reply LS to 5G-ACIA on 5G capabilities exposure for factories of the future. (Source: SA WG6 Chair).
Document for: Approval.
Abstract: To: 5G-ACIA.

Comment:

Revision of SP-210556 from SP-92E. Response to SP-210802. CC#3: SP 211019_rev3 was approved. Revised to SP-211134.

Discussion and conclusion:

CC#1:Deutsche Telekom suggested only keeping the SA WGs on the CC list. Nokia agreed that only WGs should be in CC and suggested some changes to the text concerning SA WG2 and asked whether any feedback is expected from SA WG5. Nokia also asked to remove the SA WG5 work description from the reply. The SA WG3 Chair clarified that the feedback from SA WG3 had not been provided as there was no proposed reply at the last meeting. The SA WG5 Chair commented that the text had been agreed by SA WG5 and preferred not to remove it. The SA WG6 Chair suggested taking comments into account and only removing the 'SA WG5 is responsible ..' part. This should be further discussed over e-mail and will be reviewed at a future CC.
CC#3: SP 211019_rev3 was approved. (To be revised by MCC to a new TD number).

e-mail discussion:

Suresh Chitturi (SA6 Chair) provides 1019_rev2 to incorporate comments from GTM_Day1 meeting.
Rev3 is provided with the editorial correction.

Status:

Revised to SP-211134.

TD SP-211134 (LS OUT) Reply LS to 5G-ACIA on 5G capabilities exposure for factories of the future. (Source: TSG SA).
Document for: Approval.
Abstract: To: 5G-ACIA. CC: SA WG1, SA WG2, SA WG3, SA WG5, SA WG6, CT WG3.

Comment:

Revision of SP-211019_rev3. Approved.

Discussion and conclusion:

Approved.

Status:

Approved.

TD SP-210806 (LS IN) LS from TSG RAN: LS on Inclusive language review. (Source: TSG RAN (RP-211519)).
Document for: Action.
Abstract: As part of the ongoing activity on inclusive language review of specifications (see the endorsed RP-202179 for reference), TSG RAN has decided to also include ASN.1 IE and field name changes where needed, in the review. It has been clarified that ASN.1 IE and field names can be changed without compromising backwards compatibility of the protocols. RAN#92e instructed the RAN WG Chairs to recommend RAN specification Rapporteurs to act accordingly when preparing the related Rel-17 CRs for NR and LTE. Current consensus in RAN is that legacy GERAN and UTRAN specifications should also be part of the review activity, as previously reported to TSG SA (SP-210259). We welcome your feedback on this aspect. RAN also discussed and concluded that a harmonized 3GPP wide approach for changes to protocol / ASN.1 names would be appropriate, and asks TSG SA and TSG CT to consider acting accordingly. Action: TSG RAN respectfully asks TSG SA and TSG CT to take the above into account when planning the respective activity in TSG SA and CT WGs, and to also confirm whether GERAN and UTRAN specifications should be part of the inclusive language review.

Comment:

Revision of Postponed SP-210594 from SP-92E. Response drafted in SP-211103. Final response in SP-211140.

Discussion and conclusion:

CC#1: The SA WG2 Chair asked whether RAN has decided to go with the GERAN and UTRAN specifications or whether 3G specifications only would be considered, as the original scope of the exercise was for 3G aspects only, from Rel 17. It is assumed that this means UTRAN and GERAN specifications which have been upgraded to Rel 17. Vodafone clarified that these specifications are upgraded to next Release without changes and the updates for inclusive language could be done at the time of upgrade by MCC. The SA WG2 Chair agreed that in this case all Rel 17 specifications can be upgraded by the WGs and this should be possible within the next quarter for SA WG2 specifications. The TSG SA Chair commented that for new protocol elements introduced from Rel-17 on would be cleaned up. It was clarified that only Rel-17 specifications onwards should be cleaned up in this way. A response was drafted in SP-211103 which should be further discussed over e-mail and will be reviewed at a future CC.

Status:

Replied to.

TD SP-211105 (LS IN) LS from TSG CT: Reply LS on Inclusive language review. (Source: TSG CT (CP-212260)).
Document for: Action.
Abstract: TSG CT would like to thank TSG RAN for their LS on Inclusive language review. When discussing usage of inclusive language in 5G specifications, CT decided to also cover 2G, 3G and LTE specifications. The related CRs were approved in CT plenary #91 for Rel-17. Action: TSG CT respectfully asks TSGs SA and RAN to take note of the above.

Comment:

Related to LS from TSG RAN in SP-210806. CC#3: Noted.

Discussion and conclusion:

CC#3: The TSG CT Chair clarified that 2G, 3G and LTE will be updated for Rel-17 TSs, under CT responsibility. This LS was then noted.

Status:

Noted.

TD SP-211103 (LS OUT) [DRAFT] Reply LS to LS on Inclusive language review. (Source: TSG SA).
Document for: Approval.
Abstract: To: TSG RAN, TSG CT.

Comment:

Created at CC#1. Response to SP-210806. CC#3: SP 211103_rev1 was approved. Revised to SP-211140.

Discussion and conclusion:

CC#3: SP 211103_rev1 was approved. (To be revised by MCC to a new TD number).
CC#4: There were no issues raised and SP 211103_rev1 remained approved (To be revised by MCC to a new TD number).

e-mail discussion:

Puneet (SA2 Chair) provides draft LS response.
Puneet (SA2 Chair) provides rev1.

Status:

Revised to SP-211140.

TD SP-211140 (LS OUT) Reply LS on Inclusive language review. (Source: TSG SA).
Document for: Approval.
Abstract: To: TSG RAN, TSG CT, SA WG1, SA WG2, SA WG3, SA WG4, SA WG5, SA WG6.

Comment:

Revision of SP-211103_rev1. Approved.

Discussion and conclusion:

Approved.

Status:

Approved.

TD SP-211106 (LS OUT) [DRAFT] On Sustainability and Energy Efficiency. (Source: TSG SA).
Document for: Approval.
Abstract: To: TSG RAN, TSG CT, SA WG1, SA WG2, SA WG3, SA WG4, SA WG5, SA WG6, RAN WG1, RAN WG2, RAN WG3, RAN WG4, RAN WG5, CT WG1, CT WG3, CT WG4, TSG CT WG6.

Comment:

Created at meeting. CC#3: This was left for further e-mail discussion. CC#4: Noted.

Discussion and conclusion:

CC#3: SP 211106_rev4 was reviewed. The SA WG6 Chair asked what the WG leadership is expected to act when an LS like this is received. Samsung commented that the whole system energy efficiency needs to be taken into account and not individual parts. Oppo agreed with Samsung. Motorola Solutions did not think such an LS should be sent. Huawei asked for clarification of the action. Comments should be made over the e-mail list in a constructive way. This was left for further e-mail discussion.
CC#4: SP-211106_rev5 was proposed. Huawei proposed a revision in the drafts folder, but proposed to work on this until the next meeting if it is not acceptable. There were objections and this LS was then noted.

e-mail discussion:

Alessio(nokia) provides a draft LS on Sustainability and EE in the inbox.
Alessio (Nokia) comments and provides rev1
Samsung provides rev2-Samsung with some corrections and additional conditions
Guillaume (MediaTek Inc.) comments.
Haris (Qualcomm) provides revision in drafts folder
Saso (Intel) comments.
Alessio(Nokia) provides rev4
Suresh Chitturi (SA6 Chair) provides a revision to address the concerns, and a way forward.
Huawei provides a draft to r05 better reflecting their earlier comments.
TIM comments
Nokia cannot accept the revision proposed by Huawei as it is a ridiculous LS.
Huawei understands that this LS can go nowhere, and asks for it to be noted.
Guillaume (MediaTek Inc.) recommends to note all revisions of the LS: energy will be saved as a result.
Lars (Sony) responds to Guillaume (MediaTek Inc.)
Huawei still proposes one rewording to their proposal, in case there was some misunderstanding of Nokia's previous comment.
Dom Lazara (Motorola Solutions) comments on revision-6 of the draft LS (SP-211106).

Status:

Noted.

LSs for action with no proposed replies - Block 2 (To note Wednesday 16:00 UTC)

3 Items for early consideration

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

3.2 Issues highlighted for early treatment

(Please contact the chair in advance)

TD SP-211017 (DISCUSSION) On Sustainability and Energy Efficiency. (Source: Nokia, Nokia Shanghai Bell, Deutsche Telekom, Orange, Telecom Italia, Telefonica, KDDI, Verizon UK ltd.).
Document for: Agreement.
Abstract: Discussion paper to provide our view on the handling of Energy Efficiency in 3GPP going forward.

Comment:

Noted.

Discussion and conclusion:

CC#1: OPPO asked whether this should also apply to the UE or only the network. Nokia replied that this should be a system-wide effort. Huawei fully supported the need for energy efficiency considerations but did not see whether this can be determined on a individual TR level in the studies as it requires a system-wide analysis. Intel suggested a clarification of the wording of the proposals to avoid ambiguity. Vodafone agreed that EE is important and suggested a more pragmatic approach to show the cumulative gains over the whole system and a model of where energy is used in networks would help. China Telecom commented that EE is an important aspect for operators and indicated that progress on this has been made in SA WG5 but more analysis is needed in other areas and suggested some resources dedicated to this in other WGs. AT&T commented that the dedicated focus on EE in SA WG5 are useful and this should be considered throughout the project. China Mobile asked for some examples or reference to study item conclusions which can be used for this. Samsung commented that RAN WGs have done some progress on EE aspects and supported taking the necessary steps, but was not fully in line with the proposals in this document. Sony commented that reduction in signalling should be considered in all work. Motorola Solutions suggested a dedicated study being made for this, particularly in SA WG1 which can flow down to other WGs. Xiaomi asked whether there are any actions from the studies in downstream groups. Huawei agreed that this important aspect need to be considered but did not think this proposal was particularly actionable. The SA WG2 Chair commented that some KPIs need to be developed to allow groups to determine the Energy efficiency of proposed solutions. Nokia commented that their proposal is to consider this on a system level for each solution under discussion in order to facilitate an energy efficient resulting system. This was then noted.

e-mail discussion:

Samsung replies to Nokia comments
Alessio(Nokia) comments
Samsung replies to Nokia's comments
Xiaobao(Orange) proposes the way forward to make energy efficiency an essential 3GPP system wide consideration in Rel18 and future work.
Alessio(nokia) replies.

Status:

Noted.

TD SP-211035 (DISCUSSION) ON MuSIM Paging collision Avoidance in 5GS. (Source: Sony,Nokia, Nokia Shanghai Bell, Convida Wireless, Vivo).
Document for: Agreement.
Abstract: Example of when two options exist and the most power efficient solution is not pursued.

Comment:

Noted and the CR in SP-211007 was left for e-mail discussion and the CR will be reviewed at a future CC.

Discussion and conclusion:

CC#1: Intel reported that a related CR on this issue is in SP-211007. Qualcomm commented that they were happy to approve the technically endorsed CR but asked not to have the same discussion at TSG SA as was held in SA WG2. MediaTek also supported approving the technically endorsed CR but did not agree it was the most power efficient solution that was proposed. Nokia commented that the technical discussion on this should be held in SA WG2 and would like more time than available at this meeting for discussion of this CR. Ericsson supported approving the endorsed CR at this meeting and did not see any energy efficiency issues with the proposals which can be mitigated in other ways. Huawei did not support rediscussing this again in SA WG2 as the same arguments will remain. Samsung supported approving the CR at this meeting and did not think energy efficiency considerations can be evaluated for the proposed solutions. InterDigital suggested returning the CR to SA WG2. Vodafone commented that energy efficiency improvements would lead to complexity and privacy issues for MUSIM devices and did not support returning the CR to SA WG2. Sony was disappointed that energy efficiency is not considered an important factor by some companies and suggested returning the CR to SA WG2. This document was noted and the CR in SP-211007 was left for e-mail discussion and the CR will be reviewed at a future CC.

Status:

Noted.

3.3 Discussion papers on work in Rel-15 and earlier

3.4 Discussion papers on work in Rel-16

3.5 Discussion papers on work in Rel-17

TD SP-210854 (DISCUSSION) Way Forward for EASDF based EAS discovery. (Source: Qualcomm).
Document for: Approval.
Abstract: In the last few SA WG2 e-meetings, the issue of how to guarantee that the UE uses the DNS setting provided by operator for the subsequent DNS Query during the EASDF based EAS discovery has been raiseddiscussed. In the last SA2#146E e-meeting there was no.

Comment:

Revised to SP-211101.

Discussion and conclusion:

-

Status:

Revised to SP-211101.

TD SP-211101 (DISCUSSION) Way Forward for EASDF based EAS discovery. (Source: Qualcomm Incorporated, Convida Wireless, KPN, Vodafone, SK Telecom, Deutsche Telekom, BT, Orange, Ericsson, Telecom Italia, TNO, NTT DoCoMo, Charter Communications, Telstra, KDDI, Rakuten Mobile, Huawei, HiSilicon, Telefonica, Verizon Wireless, InterDigital Inc., Nokia, Nokia Shanghai Bell, Intel, CMCC, China Unicom, Telenor, Sandive, Rogers, Amdocs, Reliance Jio, Matrixx, AT&T, Facebook, NEC, T-Mobile USA).
Document for: Approval.
Abstract: In the last few SA WG2 e-meetings, the issue of how to guarantee that the UE uses the DNS setting provided by operator for the subsequent DNS Query during the EASDF based EAS discovery has been raiseddiscussed. In the last SA2#146E e-meeting there was no.

Comment:

Revision of SP-210854. This was left for further e-mail discussion and was noted.

Discussion and conclusion:

CC#1: Lenovo commented that they agree with the requirement but considered the requested functionality is already supported by UEs and asked whether it can be ensured that there is no requirement to also support this mechanism in the future when alternative mechanisms are already implemented. Huawei commented that there are other operating systems which will not be Android or OSX based in particular for non-smartphone devices. This was left for further e-mail discussion and was noted.

Status:

Noted.

TD SP-211092 (DISCUSSION) UE handling of DNS configuration - Way Forward Proposal. (Source: Apple).
Document for: Approval.
Abstract: UE handling of DNS configuration - Way Forward Proposal.

Comment:

This issue was left for further e-mail discussion and was noted.

Discussion and conclusion:

CC#1: Apple commented that they sustain their objection to the Qualcomm proposal and propose SA WG2 study this in a future release when it can be demonstrated why existing mechanisms are not sufficient. Intel commented that the reason for the discussion is to gain the allowance for SA WG2 to work on this in Rel 17, as there is no exception request for this. AT&T asked whether there are any documented requirements for the UE to support this feature. Qualcomm clarified that the concern in S2-2106480r05 states that if a UE supports this then it does not need to also implement the mechanism. Lenovo commented that their concern is that some equipment may use different APIs to achieve the same functionality and may not be considered conformant. Google objected to the proposal from Qualcomm as more time is needed to study the impacts in different regions. Huawei commented that the feature is proposed as optional according to S2-2106480r05. Apple commented that the issue of testing the API also needs to be considered. This issue was left for further e-mail discussion and was noted. The Draft TS in SP-210948 was removed from Block approval.

e-mail discussion:

Apple provides rev1.
Haris (Qualcomm) comments
Matrixx with question for clarification and suggestion to move on with SP-211101
Susana (Vodafone) comments
Sherry (Xiaomi) comments
Zhuoyun Zhang (Tencent) comments.
Haris (Qualcomm) proposes to document the following guidance in SA meeting minutes or LS to SA2: SA#93 grants time to SA WG2 to complete the work on the contentious issue documented in Editor's Note of TS 23.548: how to guarantee that that the UE uses the DNS setting provided by operator for the subsequent DNS Query during the EASDF based EAS discovery in Q4 '21 and close the corresponding editor's note in TS 23.548. SA2#147 to be prepared to take a technical vote on this issue, if needed
Apple proposes revisions to Qualcomm's text proposal, taking into account comments made in the online session that UEs already supporting this functionality would not need to implement anything further.
Tencent proposes revised wording: SA#93 approves the TS 23.548 and grants time to SA WG2 to find a compromised way to resolve the Editor's Note of TS 23.548 clause 6.2.3.2.2 in Q4 '21 with respect to privacy requirements, user preferences and following the current UE DNS implementation.
Apple proposes further rewording of the guidance text to SA2. Apple also supports Futurewei's suggestion for SA#93 to approve TS 23.548 but this should not be in the scope of the guidance text to SA2
Johannes (Deutsche Telekom) raises concerns on giving guidance to a WG on respecting existing pre-standard implementations.
Apple proposes that the guidance text to SA2 is revised as follows:
SA#93 grants time to SA WG2 to work on the Editor's Note of TS 23.548 clause 6.2.3.2.2 in Q4 '21, taking into account user privacy and user preferences.
Apple further proposes that this guidance to SA2 is recorded in the minutes, and that an LS to SA2 is not necessary.
Yusuke (KDDI) proposes further modification of the guidance texts;
'SA#93-e to grant time to SA WG2 to address the contentious issue documented in the Editor's note of TS23.548, clause 6.2.3.2.2 in Q4 '21. SA2 to be prepared to take a technical vote on this issue, if needed.'
Susana (Vodafone) prefers the guiding text to SA2 provided by Haris (QC) with some modifications 'SA#93 to grant time to SA WG2 to address the contentious issue documented in the Editor's Note of TS 23.48, clause 6.2.3.2.2 in Q4 '21. SA2 to be prepared to take a technical vote on this issue, if needed'
M. Pia (TIM) provides revision to the guidance text.
Apple proposes that the guidance text to SA2 is revised as follows:
SA#93 grants time to SA WG2 to work on the Editor's Note of TS 23.548 clause 6.2.3.2.2 in Q4 '21, taking into account user privacy and user preferences.

Apple further proposes that this guidance to SA2 is recorded in the minutes, and that an LS to SA2 is not necessary.
Susana (Vodafone) agrees with the TIM revision for the guidance text.

Status:

Noted.

3.6 Discussion papers on work in Rel-18 and later

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

Documents under this agenda item will not be presented

4.1 SA WG1 reporting

TD SP-211029 (REPORT) SA WG1 report to SA#93. (Source: SA WG1 Chair).
Document for: Information.
Abstract: SA WG1 report to SA#93.

Comment:

CC#1: SP-211029_rev1 was noted. Revised to SP-211135.

Discussion and conclusion:

CC#1: General: China Mobile commented that SA WG1 had done good work and asked whether more time should be provided for Rel 18 work as there is no hurry to start the Rel 19 Stage 1 work in December. The SA WG1 Chair replied that it was a TSG SA decision to freeze Rel 18 Stage 1 in December and SA WG1 are ready to do this and feedback from TSG SA on when to start Rel 19 would be useful. The TSG SA Chair suggested the Stage 1 Rel 19 planning is reviewed in December TSG SA meeting and to leave the current guidance as it is for now. The SA WG1 Chair was thanked for this report. SP-211029_rev1 was noted. (To be revised by MCC).

Status:

Revised to SP-211135.

TD SP-211135 (REPORT) SA WG1 report to SA#93. (Source: SA WG1 Chair).
Document for: Information.
Abstract: SA WG1 report to SA#93.

Comment:

Revision of SP-211029_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

4.2 SA WG2 reporting

TD SP-210901 (REPORT) SA WG2 Chair Report to TSG SA#93-e. (Source: SA WG2 Chair).
Document for: Presentation.
Abstract: SA WG2 Chair Report to TSG SA#93-e.

Comment:

Noted.

Discussion and conclusion:

CC#1: Slide 58: Orange asked whether the SA WG2 SIDs have been merged as there are more reported in the meeting than were provided to TSG SA. The SA WG2 Chair replied that 8 proposals were merged during the meeting, which would reduce the number, along with some companies not submitting their SIDs to TSG SA at this time. The SA WG2 Chair was thanked for this report, which was noted.

Status:

Noted.

4.3 SA WG3 reporting

TD SP-211079 (REPORT) SA WG3 Status Report. (Source: SA WG3 Chair).
Document for: Presentation.
Abstract: SA WG3 Status Report.

Comment:

Noted.

Discussion and conclusion:

CC#1: There were no questions or comments. The SA WG3 Chair was thanked for this report, which was noted.

Status:

Noted.

4.4 SA WG4 reporting

TD SP-210818 (REPORT) Report from SA WG4 to SA Plenary. (Source: SA WG4 Chair).
Document for: Information.
Abstract: Report from SA WG4 to SA Plenary.

Comment:

Noted.

Discussion and conclusion:

CC#1: There were no questions or comments. The TSG SA Chair congratulated the new Vice Chair and thanked the leaving Vice Chair for his work in SA WG4. The SA WG4 Chair was thanked for this report, which was noted.

Status:

Noted.

4.5 SA WG5 reporting

TD SP-210989 (REPORT) SA WG5 Status Report. (Source: Ericsson LM).
Document for: Presentation.
Abstract: SA WG5 Status Report.

Comment:

Noted.

Discussion and conclusion:

CC#1: General: China Mobile commented that there were some Rel-17 WIs which had not made much progress due to non-technical issues raised and asked whether SA WG5 could try to find a way forward on such issues. The SA WG5 Chair replied that these are OAM issues and the SA WG5 leadership cannot decide to agree proposals which receive objections, but may try to use the Working Agreement mechanism in future to try to resolve such issues. The TSG SA Chair congratulated the new and re-elected SA WG5 leadership and thanked the leaving Vice Chair for their long-term good work in SA WG5. The SA WG5 Chair was thanked for this report, which was noted.

Status:

Noted.

4.6 SA WG6 reporting

TD SP-210946 (REPORT) SA WG6 status report to TSG SA#93. (Source: SA WG6 Chair).
Document for: Presentation.
Abstract: SA WG6 status report to TSG SA#93.

Comment:

Noted.

Discussion and conclusion:

CC#1: Slide 3: Deutsche Telekom commented that there are already a number of Rel 18 SIDs and WIDs agreed and are considering 15 WIDs will fill the capacity of SA WG6 and asked whether any issues are expected when Rel 18 content is decided upon and taking into account face-to-face meeting resources whether any prioritization will be required. The SA WG6 felt that no prioritization should be needed for Rel 18 as it stands and would like to avoid it once work has begun on the items. The SA WG6 Chair added that a number of the WIs are moved forward from Rel 17 proposals and the number of contributions is a good indication that the workload is manageable. The TSG SA Chair added that prioritization need not always be done on the TSG SA level but can also be handled within WGs in many cases. KPN commented that it would be better to do prioritization at the TSG SA level to ensure alignment between the WGs. The TSG SA Chair suggested this is considered if and when necessary as SA WG6 status is input to TSG SA anyhow. The SA WG6 Chair was thanked for this report, which was noted.

Status:

Noted.

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

(will be handled on Monday 20 September in separate call)

TD SP-211115 (REPORT) Status Report of TSG RAN#93-e. (Source: TSG RAN Chair).
Document for: Presentation.
Abstract: Chairmans Report of TSG RAN#93-e.

Comment:

The TSG RAN Chair was thanked for this report, which was noted.

Discussion and conclusion:

CC#5: Slide 4: Inclusive Language: The TSG SA Chair commented that Puneet Jain, SA WG2 Chair will be the TSG SA Coordinator for this.
Slide 11: User Plane Integrity Protection support for EPC: Vodafone commented that there were concerns with a single company objecting to this security work and some other companies cutting down the scope of the work without involving SA WG3 on this and asked how this would move forward. The TSG RAN Chair replied that there had been extensive discussion, but no compromise could be found at the meeting, so off-line work will probably be necessary. The TSG SA Chair commented that this issue had been taken to a Working Agreement in TSG SA and suggested this may be the way forward if there is generally strong support for the work. Ericsson commented that they were also surprised on this as SA WG3 had worked on UP Integrity Protection for LTE for some time now. MediaTek commented that the concerns are that UPIP impacts and the time frame is over for solutions which have hardware impacts on devises and they had suggested some compromises which were not agreed, but which could be explored further. Huawei commented that they were also surprised that this had not moved forward. Vodafone commented that there are solutions available and this is an important aspect of Integrity protection for operators. Qualcomm asked what the guidance is to SA WGs for Q4 on E-UTRAN to 5G Core and UPIC in EPC topics, is this expected to be handled in December or moved to Rel-18. The TSG SA Chair suggested leaving this open and to decide in December whether this will be included in the Release. Vodafone commented that the E-UTAN to 5G Core issue, there are no existing products, but for UPIC to EPC there are existing products. The SA WG3 Chair commented that the UPIC-LTE issue has been worked upon and feedback has been received that this can be supported by many devices using NR PDCP. MediaTek replied that it is not about simplicity of implementation but that RAN had stated that if it is supported in Rel-17 then it will be limited to NRPDCP support. The TSG SA Chair suggested TSG RAN try to come to a conclusion on this.
Slide 1: Rel-17 Sidelink: FirstNet asked for clarification on the delay expected. The TSG RAN Chair replied that there are different schemes offered and TSG RAN could not make a technical decision on which to select, so this will be discussed in the WGs.
Slide 6: The SA WG2 Chair commented that the RAN WG12/3 package approval deadlines mean that SA WG2 needs to complete SID work in September 2021 and suggested the TSG RAN Chair provides guidance to RAN WG Chairs to handle Rel 18 Stage 2 work as early as possible.
Slide 6: Rel-18 timeline: Firstnet asked whether the timeline is now fixed, or is an estimate to be confirmed in December. The TSG SA Chair replied that the timelines are unlikely to change in December.
The TSG RAN Chair was thanked for this report, which was noted.

Status:

Noted.

4.8 TSG CT reporting

(will be handled on Monday 20 September in separate call)

TD SP-211114 (REPORT) Status report of TSG CT#93-e. (Source: TSG CT Chair).
Document for: Presentation.
Abstract: Status report of TSG CT#93-e.

Comment:

Noted.

Discussion and conclusion:

CC#5: Slide 26: The SA WG5 Chair commented that there had been an Open API reflector set up for this but no response had been received. Companies were encouraged to consider commenting on this. The TSG CT Chair commented that what is needed is a clear guideline in order to allow SA WG3-LI to continue their API work. The TSG SA Chair commented that the lack of response was likely due to busy meetings and summer vacations and encouraged companies to post on this list.
The TSG CT Chair was thanked for this report, which was noted.

Status:

Noted.

TD SP-211113 (REPORT) Draft report of TSG CT#93-e. (Source: TSG CT Secretary (MCC)).
Document for: Information.
Abstract: Draft report of TSG CT#93-e.

Comment:

Noted.

Discussion and conclusion:

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

Status:

Noted.

TD SP-211112 (REPORT) IETF Status report. (Source: TSG CT Chair).
Document for: Presentation.
Abstract: IETF Status report.

Comment:

Noted.

Discussion and conclusion:

CC#5: General: Intel asked what the action was for the QUIC work. WGs are asked to review the dependencies in their specifications. This is mainly a task for Rapporteurs and it was clarified that the QUIC is related to Rel-18 work.
The TSG CT Chair was thanked for this report, which was noted.

Status:

Noted.

TD SP-211142 (LS IN) LS from CT WG4: LS on Guidelines on Port Allocation for New 3GPP Interfaces. (Source: CT WG4 (C4-214848)).
Document for: Information.
Abstract: CT WG4 received Reply LS from RAN WG3 on Information on the port number allocation solutions (R3-212800, C4-214143). CT WG4 thanks RAN WG3 for their support with the FS_PortAl work. CT WG4 has also received updated reply LS from IETF IESG (C4-214811), which clarifies the existing procedure for obtaining IANA assigned port numbers. Based on the feedback, CT WG4 is able to finalize the primary outcome of the FS_PortAl work, which is documented in 3GPP TR 29.941. Reply LS from IETF IESG and the latest version of the 3GPP TR 29.941 v1.1.0 are attached to this LS. CT WG4 believes that the use of IANA assigned port numbers remain the simplest and most efficient solution to identify a particular protocol, interface or service. In particular, it is strongly recommended to apply to IANA for assigned service name and port number for any protocol potentially supported by inter-domain and/or roaming interfaces. However, when the IETF requirements for obtaining new port number from IANA cannot be met, 3GPP TR 29.941 describes solutions that can be adopted as alternative to the use of IANA assigned transport port numbers. CT WG4 believes that each of the solutions#1-8 have own merits and limitations. Each 3GPP WG is encouraged to study which solution would fit best the requirements of a given interface application. One of the solutions in 3GPP TR 29.941, 3GPP allocated port number solution#6 offers 3GPP specific mechanism to request and obtain new default port numbers from the subrange of 101 ports [65400 - 65500], which is taken from the Dynamic/Private range [49152 - 65535]. 3GPP TR 29.941 will maintain the repository of the 3GPP assigned port numbers.

Comment:

Referred to in TSG CT Report. Noted.

Discussion and conclusion:

CC#5: This was noted.

Status:

Noted.

4.9 Reports from external bodies

(provided by Liaison persons)

4.10 Other reports

5 Cross TSG Coordination

5.1 General Cross TSG Coordination

5.2 Rel-17 Focus Areas Status Reports & Issues

5.3 Rel-18 Focus Areas Status Reports & Issues

5.4 Input to Joint RAN/SA meeting

TD SP-210832 (DISCUSSION) TSG SA Chair Input to TSG SA/RAN/CT Joint Session. (Source: TSG SA Chair).
Document for: Endorsement.
Abstract: TSG SA Chair Input to TSG SA/RAN/CT Joint Session.

Comment:

Discussed in CC#1. CC#4: SP-210832_rev5 endorsed (in particular, Slide 2 was endorsed). Revised to SP-211118.

Discussion and conclusion:

CC#1: Deutsche Telekom commented that this proposal assumes a Rel 18 content freeze is decided in December 2021. The SA WG2 Chair asked to indicate that SA WG2 will need 8 meetings to do the Rel 18 Stage 2 work. The SA WG2 Chair commented that an option to keep a 12 month Release is to start the Stud work in Q4/2021 and to allow some larger Studies to run longer, with possible exceptions at the end of the Release which would also allow Stage 3 work to progress earlier on some work and have some exceptions at the Stage 3 end if necessary. Samsung asked to take the guidance for maximum 6 WG meetings per year to be upheld and added that an ad-hoc meeting added in 2022 would give 17 TUs extra and another possible ad-hoc in January 2023 would allow timely completion. CATT asked to discuss a 15 month Stage 2 and the possibility of SA WG2 holding 9 meetings in this period (option B). Motorola Solutions commented that CT WGs would need 9 months for the Stage 3 work. The TSG SA Chair commented that he did not want TSG SA to make decisions which put pressure on WGs in other TSGs and TSG CT had already discussed the options and Option C was not acceptable. Vivo agreed that Option B is the most reasonable option. Intel suggested that any show of hands should only focus on the 12 month versus 15 month question and not aspects which are controlled by other TSGs. The SA WG2 Chair suggested that only 8 meetings are planned for SA WG2, as planning on 9 meetings will result in filling the time units accordingly and will not provide benefit in the Rel-18 content planning. Option B: 11 With Option B: 8 meetings: 26 It was decided that planning should be for 8 SA WG2 meetings for Rel-18. Undecided on Option A and Option B: 6 Support for Option A: 2 Support for Option B: >20 The conclusion is main support for option B with 8 WG meetings: January 2022 to March 2023. Rel-18 content discussions should be based on TU availability with SA WG2 holding 8 meetings. It was clarified that this should include ad-hoc meetings.
CC#4: SP-210832_rev4 was presented at the Joint TSG SA/TSG RAN session The SA WG2 Chair asked to clarify slide 2 to show that SA WG2 currently plan to hold 8 meetings from Jan 2022 to March 2023 and clarify the following bullet to 'TU budget panning. This was updated in SP-210832_rev5 which was endorsed (in particular, Slide 2 was endorsed). (To be revised by MCC to a new TD number).

e-mail discussion:

Siemens provides a resolution for its objection.
Saso (Intel) comments on the addition from Siemens.
ETSI MCC WP Manager clarifies that the newly agreed Rel-18 timeline has been incorporated in the revised version of the Work Plan review (SP-211102), both in a diagram view (slide #19) and also in text version (slide #18).

Status:

Revised to SP-211118.

TD SP-211118 (DISCUSSION) TSG SA Chair Input to TSG SA/RAN/CT Joint Session. (Source: TSG SA Chair).
Document for: Endorsement.
Abstract: TSG SA Chair Input to TSG SA/RAN/CT Joint Session.

Comment:

Revision of SP-210832_rev5. Endorsed (in particular, Slide 2 was endorsed).

Discussion and conclusion:

Endorsed (in particular, Slide 2 was endorsed).

Status:

Endorsed.

6 Work Item Descriptions, Study Item Descriptions, Specifications

6.1 New Release 17 Study Item Descriptions

6.2 New Release 17 Work Item Descriptions

TD SP-210943 (WID NEW) New WID: 'Architecture Enhancement for NR Reduced Capability Devices' [ARCH_NR_REDCAP]. (Source: SA WG2).
Document for: Approval.
Abstract: Objective: This Work Item has the following objectives to support Reduced Capability NR Devices: - Support eDRX enhancements for RedCap UE, including: - Specify how to support Extended DRX for RRC Inactive and Idle with eDRX cycles up to 10.24 s, without using PTW and PH., e.g. potential enhancements on paging handling and/or registration area management. - Specify how to support extended DRX up to 10485.76 s for RRC_IDLE. - Support RedCap UE type identification and potential optimization, e.g. RedCap traffic identification in 5GC. - End-to-end functionality definition of RedCap UE, e.g. the functionality definition to support UE complexity reduction for RedCap UE, similar to Annex M (informative): Functions and procedures over NB-IoT RAT in TS 23.401. NOTE 1: the SA WG2 work need to be coordinated with RAN WGs.

Comment:

Target Release and Completion dates missing. Revised to SP-211100.

Discussion and conclusion:

-

Status:

Revised to SP-211100.

TD SP-211100 (WID NEW) New WID: 'Architecture Enhancement for NR Reduced Capability Devices' [ARCH_NR_REDCAP]. (Source: China Mobile).
Document for: Approval.
Abstract: Objective: This Work Item has the following objectives to support Reduced Capability NR Devices: - Support eDRX enhancements for RedCap UE, including: - Specify how to support Extended DRX for RRC Inactive and Idle with eDRX cycles up to 10.24 s, without using PTW and PH., e.g. potential enhancements on paging handling and/or registration area management. - Specify how to support extended DRX up to 10485.76 s for RRC_IDLE. - Support RedCap UE type identification and potential optimization, e.g. RedCap traffic identification in 5GC. - End-to-end functionality definition of RedCap UE, e.g. the functionality definition to support UE complexity reduction for RedCap UE, similar to Annex M (informative): Functions and procedures over NB-IoT RAT in TS 23.401. NOTE 1: the SA WG2 work need to be coordinated with RAN WGs.

Comment:

Revision of SP-210943. CC#2: This WID NEW was approved.

Discussion and conclusion:

CC#2: The SA WG2 Chair asked whether the target should show the TSG SA#94-e. As it shows December 2021, this was not necessary. This WID was then approved.

Status:

Approved.

TD SP-210944 (WID NEW) New WID: 'Architecture support for NB-IoT/eMTC Non-Terrestrial Networks in EPS' [IoT_SAT_ARCH_EPS]. (Source: SA WG2).
Document for: Approval.
Abstract: Objective: This Work Item covers the following objectives to introduce minimum essential functionality to support NB-IoT and eMTC over Non-Terrestrial Networks in EPS using 5GSAT_ARCH solutions as baseline: - Functionality to support NTN for NB-IoT and eMTC for transparent payload based scenarios, including: - Support for fixed Earth-based tracking areas - Support for policy and QoS control considering satellite access - Support for extended NAS timers at least for eMTC when GEO constellations are used, using existing NAS timer extension introduced for CE mode B as baseline NOTE: NB-IoT NAS timers are natively extended and thus expected to be reused as is (CT WG1 to confirm) - Support for regulatory services (e.g. Lawful intercept) with super-national satellite ground stations - Support for country-specific CN routing - Support for identification and restriction of satellite access - Support for broadcasting more than one TAC per PLMN - Related functionality to support the above as part of EPS: - Network access control - Packet routing and transfer - Mobility management - Radio resource management NOTE: Additional functionality to support satellite backhaul and discontinuous coverage is not included as part of this work item. - All functionality applicable to NB-IoT and/or LTE-M, except: - Support for Dedicated bearer, support for GBR bearer (not deemed minimum essential functionality for IoT use case with LTE-M) - MBMS (not discussed in RAN for Rel-17 IoT NTN) - WUS (not discussed in RAN for Rel-17 IoT NTN) This Work Item assumes UEs are able to determine their own location using GNSS.

Comment:

CC#2: SP 210944_rev3 approved. Revised to SP-211124.

Discussion and conclusion:

CC#2: SP 210944_rev02 was proposed. Qualcomm asked whether GBR bearer is necessary or whether a non-GBR bearer should be included for dedicated bearer as there is no additional functionality required for this. It was agreed to remove ', GBR bearer'. Apple asked to be added as a supporting company. This was revised to SP 210944_rev03, which was approved. (To be revised by MCC to a new TD number).

e-mail discussion:

Guillaume (MediaTek Inc.) provides rev1 (adding a clarification)
Chris(Vodafone) supports the update in rev 1
Ericsson also supports the update.
Guillaume (MediaTek Inc.) provides rev 2 (removing an inconsistency in rev1)
Guillaume (MediaTek Inc.): rev3 resulting from GTW was uploaded yesterday (FYI).

Status:

Revised to SP-211124.

TD SP-211124 (WID NEW) New WID: 'Architecture support for NB-IoT/eMTC Non-Terrestrial Networks in EPS' [IoT_SAT_ARCH_EPS]. (Source: SA WG2).
Document for: Approval.
Abstract: Objective: This Work Item covers the following objectives to introduce minimum essential functionality to support NB-IoT and eMTC over Non-Terrestrial Networks in EPS using 5GSAT_ARCH solutions as baseline: - Functionality to support NTN for NB-IoT and eMTC for transparent payload based scenarios, including: - Support for fixed Earth-based tracking areas - Support for policy and QoS control considering satellite access - Support for extended NAS timers at least for eMTC when GEO constellations are used, using existing NAS timer extension introduced for CE mode B as baseline NOTE: NB-IoT NAS timers are natively extended and thus expected to be reused as is (CT WG1 to confirm) - Support for regulatory services (e.g. Lawful intercept) with super-national satellite ground stations - Support for country-specific CN routing - Support for identification and restriction of satellite access - Support for broadcasting more than one TAC per PLMN - Related functionality to support the above as part of EPS: - Network access control - Packet routing and transfer - Mobility management - Radio resource management NOTE: Additional functionality to support satellite backhaul and discontinuous coverage is not included as part of this work item. - All functionality applicable to NB-IoT and/or LTE-M, except: - Support for Dedicated bearer, support for GBR bearer (not deemed minimum essential functionality for IoT use case with LTE-M) - MBMS (not discussed in RAN for Rel-17 IoT NTN) - WUS (not discussed in RAN for Rel-17 IoT NTN) This Work Item assumes UEs are able to determine their own location using GNSS.

Comment:

Revision of SP-210944_rev3. Approved.

Discussion and conclusion:

Approved.

Status:

Approved.

TD SP-210838 (WID NEW) New WID on Security Aspects of Proximity based Services (ProSe) in the 5G System (5GS). (Source: SA WG3).
Document for: Approval.
Abstract: Objective: The objective of this work item is to specify the security and privacy aspects of proximity based services (including public safety services and commercial services) in the 5G system. The WID is based on the conclusions reached in TR 33.847, TR 38.836 and TR 23.752. It may be possible to address the new security requirement based SA WG2 and RAN groups' progress. The following security and privacy aspects are considered: - Security and privacy protection for 5G ProSe direct discovery, including open discovery and restricted discovery; - Security and privacy protection for 5G ProSe direct communication, including groupcast mode and unicast mode for both in coverage and out of coverage; - Security and privacy protection for 5G ProSe UE-to-Network Relay, including Layer-2 UE-to-Network Relay and Layer-3 UE-to-Network Relay. The expected output will be captured in a new TS.

Comment:

CC#3: SP-210838_rev1 approved. Revised to SP-211120.

Discussion and conclusion:

CC#3: OPPO asked to be added as a supporting company. This was provided in SP-210838_rev1, which was approved. (To be revised by MCC to a new TD number).

Status:

Revised to SP-211120.

TD SP-211120 (WID NEW) New WID on Security Aspects of Proximity based Services (ProSe) in the 5G System (5GS). (Source: SA WG3).
Document for: Approval.
Abstract: Objective: The objective of this work item is to specify the security and privacy aspects of proximity based services (including public safety services and commercial services) in the 5G system. The WID is based on the conclusions reached in TR 33.847, TR 38.836 and TR 23.752. It may be possible to address the new security requirement based SA WG2 and RAN groups' progress. The following security and privacy aspects are considered: - Security and privacy protection for 5G ProSe direct discovery, including open discovery and restricted discovery; - Security and privacy protection for 5G ProSe direct communication, including groupcast mode and unicast mode for both in coverage and out of coverage; - Security and privacy protection for 5G ProSe UE-to-Network Relay, including Layer-2 UE-to-Network Relay and Layer-3 UE-to-Network Relay. The expected output will be captured in a new TS.

Comment:

Revision of SP-210838_rev1. Approved.

Discussion and conclusion:

Approved.

Status:

Approved.

TD SP-210858 (WID NEW) New WID Improved support for NSA in the service-based management architecture. (Source: SA WG5).
Document for: Approval.
Abstract: Objective: The objectives of this work item are to support enhancement of service based management architecture in the following aspects: 1. Specify the solution sets for management of 5G NSA scenarios identified in TR 28.925, (i.e. providing YANG and YAML solution set for legacy nodes NRM in the EUTRAN NRM and RAN NRM). 2. Specify what objects that is supporting the SBMA and IRP architecture in the Generic NRM.

Comment:

CC#3: SP-210858_rev1 approved.CC#4: SP-210858_rev2 approved. Revised to SP-211121.

Discussion and conclusion:

CC#3: Objective: 2 required some clarification. <<Ericsson?? Robert>> reported that as the SBMA and IRP are described in the same TS and some items belong to both this need to be determined. This will be clarified in the WID which was revised to SP-210858_rev1, which was approved.
CC#4: Siemens proposed an enhancement to SP-210858_rev1 after the CC#3, but did not create a new revision. This was updated in SP-210858_rev2 which was approved (To be revised by MCC to a new TD number).

e-mail discussion:

Revision request (editorial)
Siemens points out that objective two of this WID is unclear
Revision provided in SP-210858_rev1.
Siemens thanks Ericsson for SP-210858_rev1 and proposes a change of the proposed text.
Siemens provides the proposed changes of SP-210858_rev1 as a company revision.
SA5 chair provides the proposed changes of SP-210858_rev1 from Siemens in SP-210858_rev2 as the officially pre-approved revision at the GTM call today.

Status:

Revised to SP-211121.

TD SP-211121 (WID NEW) New WID Improved support for NSA in the service-based management architecture. (Source: SA WG5).
Document for: Approval.
Abstract: Objective: The objectives of this work item are to support enhancement of service based management architecture in the following aspects: 1. Specify the solution sets for management of 5G NSA scenarios identified in TR 28.925, (i.e. providing YANG and YAML solution set for legacy nodes NRM in the EUTRAN NRM and RAN NRM). 2. Specify what objects that is supporting the SBMA and IRP architecture in the Generic NRM.

Comment:

Revision of SP-210858_rev2. Approved.

Discussion and conclusion:

Approved.

Status:

Approved.

Block 3 (to approve Thursday 15:00 UTC)

TD SP-210835 (WID NEW) New WID on Security aspects of the 5GMSG Service. (Source: SA WG3).
Document for: Approval.
Abstract: Objective: The main objective of the work item is to produce normative specification based on the conclusions identified in TR 33.862 (clause 7). More specifically, the following objectives are expected to be specified as a result of this work item: - Support of authentication and authorization between the MSGin5G client and the MSGin5G server - Support of transport security protection for MSGin5G interfaces.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210836 (WID NEW) New WID for Security aspects on User Consent for 3GPP services. (Source: SA WG3).
Document for: Approval.
Abstract: Objective: The objective of this work item is to specify the security aspects on user consent for 3GPP services concluded in TR 33.867. The security aspects to be specified include two objectives as following: - Generic security requirements, services and guidance for user consent check and revocation as documented in section 8.5 of the TR. NOTE: In the present WID, a user is only identifiable by his/her subscription identifier. So, user consent is stored as subscription data.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210837 (WID NEW) New WID on Security aspects of enablers for Network Automation (eNA) for the 5G system (5GS) Phase 2. (Source: SA WG3).
Document for: Approval.
Abstract: Objective: The main objective of the work item is to produce normative specification based on the conclusions identified in TR 33.866 (clause 7). More specifically, the following objectives are expected to be specified as a result of this work item: - Authorization of NF Service Consumers for data access via DCCF - Protection of data transferred between AF and NWDAF - Protection of UE data in transit between NFs - Additional objectives will be included if additional conclusions are reached within TR 33.866 that require normative work.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210859 (WID NEW) New WID on access control for the management service. (Source: SA WG5).
Document for: Approval.
Abstract: Objective: - Extend service based management architecture to support authentication and authorization capabilities. Note: e.g. In TS 28.533, add authentication and authorization services in service based management architecture, and refine interactions between MnS producer and MnS consumer to include authentication and authorization steps. - Enhance generic Network Resource Model and generic management services, including stage 2 and stage 3, to support authentication and authorization capabilities. Note: authentication and authorization solutions may be dependent on solution sets and protocols. - Align the solutions with management plane security requirements and solutions of SA WG3 when applicable.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

e-mail discussion:

The last objective of this WID probably needs to be re-written.

Status:

Approved.

TD SP-210861 (WID NEW) New WID on Charging aspects of edge computing. (Source: SA WG5).
Document for: Approval.
Abstract: Objective: To specify the requirements, architectures and solutions for - 5GS capability usage based charging for Edge Computing, including -- subscriber charging; and -- inter-provider charging; - Edge enabling infrastructure resource charging; - Edge application server deployment charging; and - Edge enabling services usage charging. This work will be based on - the corresponding conclusions documented in clauses 7.1.6, 7.2.6, 7.3.6 and 7.4.6 of TR 28.815; - 5GS capabilities supporting Edge Computing as specified in TS 23.501; and - architecture for enabling Edge Applications as specified in TS TS 23.558.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

6.3 Revised Release 17 Study Item and Work Item Descriptions

Block 3 (to approve Thursday 15:00 UTC)

TD SP-210860 (WID REVISED) Revised WID on 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 effort 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. - Procedure to ensure that the 3GPP ServiceProfile can be updated without causing service interruption.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210967 (WI EXCEPTION REQUEST) Rel-17 Work Item Exception for Application Architecture for MSGin5G Service (5GMARCH). (Source: SA WG6).
Document for: Approval.
Abstract: Rel-17 Work Item Exception for Application Architecture for MSGin5G Service (5GMARCH).

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

6.4 New Release 18 Study Item Descriptions

TD SP-210954 (SID NEW) New SID study on enhanced architecture for UAS Applications. (Source: SA WG6).
Document for: Approval.
Abstract: Objective: The SA WG6 objectives of this study item include the following: 1) analyze requirements in 3GPP TS 22.125 and further identify key issues, develop corresponding architectural requirements and potential enhancements to the application layer architecture as required, including: a) support for multiple USS/ UTMs; b) support for monitoring by USS/UTM of C2 communication QoS and communication link status including for UAV moving between EPS and 5GS, see 3GPP TS 22.125 clause 6.2; c) support for service restriction for UEs onboard of UAV, see 3GPP TS 22.125 clause 6.3; d) usage of 5MBS; e) usage of PC5 communication between UAVs or UAV and UAV-C; and f) usage of multiple PLMNs; 2) identify potential solutions as required, including the information flows and the APIs satisfying the architectural requirements and enhancements identified in bullet 1) above; and 3) identify potential improvements to SEAL based on the architectural requirements and enhancements identified in bullet 1) above. For some items, e.g. d), e) and f) above, SA WG6 is dependent on progress and decisions by SA WG2.

Comment:

This SID NEW was approved.

Discussion and conclusion:

CC#3: This new SID was approved.

Status:

Approved.

TD SP-210955 (SID NEW) New SID Study on SEAL data delivery enabler for vertical applications. (Source: SA WG6).
Document for: Approval.
Abstract: Objective: The objectives of the study of a SEAL data delivery enabler to support different types of applications include: 1. Analyse the use cases and requirements (e.g. stage 1 requirements in TS 22.261 as listed in the justification) for the need of application layer support mechanisms to efficiently distribute and deliver the application content/data to the UE. 2. Identify key issues based on 1), study the potential solutions and develop a suitable overall application framework/enabling layer platform architecture for application data delivery considering the following aspects: a. How to integrate all the 3GPP application data delivery (e.g. potentially integrating with MSGin5G, potentially integrating MBSF-U for data delivery over 5G MBS) b. Define new capabilities including - Application support functions e.g. Caching, distribution and delivery of application content/data for multiple vertical applications. - Supporting different application data characteristics (e.g. temporal based, bandwidth based) considering more application data types (e.g. file, machine control) and without having the visibility into the application data itself. - Selection and optimal usage of Transport layer connection (e.g. TCP/UDP including lossless transmission considering UE mobility) for the above capabilities. - Data transmission quality measurement mechanisms for supporting data delivery for maintaining user experience. - Supporting E2E URLLC data delivery mechanism (e.g. considering E2E redundant User Plane paths using Dual Connectivity specified for URLLC cases in TS 23.501). NOTE: Aspects for supporting analytics for improved data and service awareness can be considered as per the status of Analytics study item focus in SA WG6.

Comment:

This SID NEW was approved.

Discussion and conclusion:

CC#3: This new SID was approved.

e-mail discussion:

Revision request (editorial)
This WID does not feature the SA header including the SP number.

Status:

Approved.

TD SP-210956 (SID NEW) New SID Study on enhancements to application layer support for V2X services; Phase 2. (Source: SA WG6).
Document for: Approval.
Abstract: Objective: The objectives of the study include: 1. Analyze the stage 1 requirements for advanced V2X services like V2P, ToD specified in TS 22.185 and TS 22.186, the corresponding 3GPP system architecture enhancements specified in TS 23.287 and the related scenarios specified in industry bodies (e.g. 5GAA, ETSI ITS) which have impact on the enabler layer services; 2) Analyze the impact of edge and data analytics architecture (specified in TS 23.501, TS 23.288, TS 23.548, TS 23.558) usage on the existing V2X application enabler functionalities specified in TS 23.286 and the corresponding support for edge computing for advanced V2X services; and 3) Based on (1) and (2), develop key issues, corresponding architecture requirements and solution recommendations to enable the application layer support for the advanced V2X services over 3GPP systems (5GS, EPS).

Comment:

This SID NEW was approved.

Discussion and conclusion:

CC#3: This new SID was approved.

Status:

Approved.

TD SP-210889 (SID NEW) New SID: Feasibility on Network Slicing Phase 3. (Source: ZTE,LG Electronics,Samsung, Alibaba,Apple,AT&T,CATT ,China Telecom,China Unicom,Convida Wireless LLC,Ericsson,Intel,InterDigital ,KDDI,Lenovo ,Matrixx,MITRE,Motorola Mobility,NEC ,Nokia,Nokia Shanghai Bell ,NTT Docomo,OPPO,Orange,Qualcomm,Sanechips ,T-Mobile USA ,Spreadtrum,Tencent,Verizon UK Ltd ,Xiaomi,).
Document for: Approval.
Abstract: new study on FS_eNS_Ph3. Objective: The objective of this study is to investigate the feasibility of further enhancement on network slicing.

Comment:

CC#4: _rev1 noted. Revised to SP-211122.

Discussion and conclusion:

CC#4: SP-210889_rev1 noted. (To be revised by MCC to a new TD number).

e-mail discussion:

Jinguo (ZTE) provides rev01.

Status:

Revised to SP-211122.

TD SP-211122 (SID NEW) New SID: Feasibility on Network Slicing Phase 3. (Source: ZTE,LG Electronics,Samsung, Alibaba,Apple,AT&T,CATT ,China Telecom,China Unicom,Convida Wireless LLC,Ericsson,Intel,InterDigital ,KDDI,Lenovo ,Matrixx,MITRE,Motorola Mobility,NEC ,Nokia,Nokia Shanghai Bell ,NTT Docomo,OPPO,Orange,Qualcomm,Sanechips ,T-Mobile USA ,Spreadtrum,Tencent,Verizon UK Ltd ,Xiaomi,).
Document for: Approval.
Abstract: new study on FS_eNS_Ph3. Objective: The objective of this study is to investigate the feasibility of further enhancement on network slicing.

Comment:

Revision of SP-210889_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-210891 (SID NEW) New SID: Study on MPS when access to EPC/5GC is WLAN. (Source: Peraton Labs, CISA ECD, Verizon UK Ltd., AT&T, T-Mobile USA).
Document for: Approval.
Abstract: Objective: The objective is to study support of the following: 1. MPS for MMTEL voice/video calls when the UE has WLAN access to the EPC, 2. MPS for MMTEL voice/video calls when the UE has WLAN access to the 5GC, 3. MPS for Data Transport Service sessions when the UE or IoT device has WLAN access to the EPC, 4. MPS for Data Transport Service sessions when the UE or IoT device has WLAN access to the 5GC, The scope includes both trusted and untrusted non-3GPP WLAN access. The study will identify stage 2 gaps and analyse solutions for: 1. Conveying 3GPP MPS subscription information to the WLAN/UE during attach/registration procedure, as well as optimization of UE selection of the ePDF/N3IWF; 2. Passing an indication of MPS to the WLAN for Bearer Establishment of MPS for MMTEL voice/video calls, and for MPS data sessions; and 3. Passing an indication of MPS to the WLAN for PDU Session Establishment of MPS for MMTEL voice/video calls, and for MPS data sessions. Actions taken by the non-3GPP/WLAN are outside of 3GPP scope (e.g., the WLAN may or may not act on the MPS related information received from the 3GPP system based on the capability of the WLAN). Total Expected Time Units: 4 study + 2 normative (estimate) => total = 6.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-210892 (SID NEW) New SID on Enhancement to the 5GC LoCation Services Phase 3.. (Source: CATT, Huawei).
Document for: Approval.
Abstract: This contribution proposes a new SID on Enhancement to the 5GC LoCation Services Phase 3.

Comment:

CC#4: _rev1 noted. Revised to SP-211123.

Discussion and conclusion:

CC#4: rev1 noted. (To be revised by MCC to a new TD number).

e-mail discussion:

Ming (CATT) provides rev01.

Status:

Revised to SP-211123.

TD SP-211123 (SID NEW) New SID on Enhancement to the 5GC LoCation Services Phase 3.. (Source: CATT, Huawei).
Document for: Approval.
Abstract: This contribution proposes a new SID on Enhancement to the 5GC LoCation Services Phase 3.

Comment:

Revision of SP-210892_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-210945 (SID NEW) New SID on 5G System Support for AI/ML-based Services. (Source: Guangdong OPPO Mobile Telecom, Samsung).
Document for: Approval.
Abstract: The intent of this study is to focus on enabling, as defined by SA WG1 Rel-18 AMMT requirements, the AI/ML Services & Transmissions with 5GS assistance to support AI/ML model distribution, transfer, training for various applications, e.g. video/speech rec.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-210986 (SID NEW) New SID: 5GC enhancement for satellite access in Rel18. (Source: THALES, XIAOMI).
Document for: Approval.
Abstract: Objective: The study item aims at investigating on further 5GC enhancements to support satellite access based on the R17 5GSAT_ARCH achievements with the following 5GC areas for study: Objectives: related with performance improvement: - A. Service continuity A.1 Hand Over based application preference: enhance architecture (new mobility triggers) such like application would have choice between satellite access for the benefits of service continuity, and terrestrial access taking advantage of the short delay, large bandwidth and strong reliability. A.2 Service continuity in case of shared satellite RAN, with multiple CN (e.g.: autonomous ships near coastal areas) - B. Support of Performance Enhancement Proxy - Enhancement of quality of experience for connected protocols, minimizing long delay impacts through use of Performance enhancement Proxy (PeP). Investigate where PEP can be placed I 5GC architecture. - C. Network based UE location determination C.1 Architectural impact to support network verified/provided UE location determination: - Refine triggering conditions after LCS framework new method definition. - Check compliancy with regulated service and extraterritoriality requirements (network provided or verified) according SA WG1 outcomes (i.e.: see SA WG1 extra-territoriality 5GET study). C.2 Possible architectural enhancement to meet location services requirements as defined in TS 22.261. Objectives: related with new features: - D. Discontinuous coverage D.1 Architectural enhancements to support discontinuous coverage for mobility enhancement (e.g. paging enhancement) D.2 Architectural enhancements considering prediction, awareness & notification of UE wake-up time, power saving optimizations. - E. Broadcast/multicast E.1 Support of broadcast/multicast service targeting specific geographical areas (e.g. counties, provinces,) E.2 Supporting differentiated QoS for MBS. E.3 User plane path selection between satellite path and terrestrial path for efficient content transfer E.4 Content transfer for UEs temporarily out of coverage due to discontinuous coverage or NGSO regenerative-based satellite access - F. Relay based architecture including satellite - Support of vehicle mounted relay UE with satellite access, in particular following SA WG1 requirements in TR 22.839 (Study on vehicle-mounted relays) - G. Store and forward G.1 Mobility management enhancements G.2 Session and User plane enhancements.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-210987 (SID NEW) New SID on Study on Architecture Enhancement to support Ranging based services and relative positioning. (Source: Xiaomi, OPPO, VIVO, Tencent, CATT, Huawei, HiSilicon, Philips, China Mobile, ZTE, Deutsche Telekom).
Document for: Approval.
Abstract: New SID on Study on Architecture Enhancement to support Ranging based services and relative positioning.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-210988 (DISCUSSION) 5GC enhancement for Satellite access in Rel18 (presentation slides for SP-210986). (Source: THALES, XIAOMI).
Document for: Presentation.
Abstract: Presentation slides for SP-210986: 5GC enhancement for satellite access in Rel18.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-210991 (DISCUSSION) Motivation of Passive IoT. (Source: China Mobile, Spreadtrum Communications, Huawei).
Document for: Discussion.
Abstract: The motivation of R18 Passive IoT SID is discussed.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-210992 (SID NEW) New SID on Study on Passive Internet of Things (Passive IoT) for 5G Advanced. (Source: China Mobile, Spreadtrum Communications, Huawei, HiSilicon, China Telecom, China Unicom, CATT, Tencent, vivo, Quanray, NTT DOCOMO).
Document for: Approval.
Abstract: A new R18 SID Passive IoT is proposed.

Comment:

CC#4: rev2 noted. Revised to SP-211125.

Discussion and conclusion:

CC#4: rev2 noted. (To be revised by MCC).

e-mail discussion:

KPN supports the passive IoT SID but SA1 should provide requirements
Yusuke (KDDI) ask a question for clarification from procedural perspective.
Spreadtrum replies the comments from KPN and KDDI, and provides revision 1 with an additional supporting company(KPN) and the primary/secondary Rapporteur.
Spreadtrum provides revision 2 with the TU estimation for the normative work: 5 TUs for the normative work.

Status:

Revised to SP-211125.

TD SP-211125 (SID NEW) New SID on Study on Passive Internet of Things (Passive IoT) for 5G Advanced. (Source: China Mobile, Spreadtrum Communications, Huawei, HiSilicon, China Telecom, China Unicom, CATT, Tencent, vivo, Quanray, NTT DOCOMO).
Document for: Approval.
Abstract: A new R18 SID Passive IoT is proposed.

Comment:

Revision of SP-210992_rev2. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-210993 (SID NEW) New Study about AF control of 5GC groups. (Source: Nokia, Nokia Shanghai Bell).
Document for: Information.
Abstract: New Study about AF control of 5GC groups.

Comment:

CC#4: _rev3 noted. Revised to SP-211126.

Discussion and conclusion:

CC#4: rev3 noted. (To be revised by MCC).

e-mail discussion:

Rainer (Nokia) provides rev01.
Gerald (Matrixx) please add Matrixx as supporting company
Rainer (Nokia) provides rev02.
Rainer (Nokia) provides rev03.

Status:

Revised to SP-211126.

TD SP-211126 (SID NEW) New Study about AF control of 5GC groups. (Source: Nokia, Nokia Shanghai Bell).
Document for: Information.
Abstract: New Study about AF control of 5GC groups.

Comment:

Revision of SP-210993_rev3. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-210994 (SID NEW) New SID on Study on Proximity based Services in 5GS - Phase 2. (Source: CATT).
Document for: Approval.
Abstract: Objective: The study item aims at further investigating 5G System enhancements to support Proximity Services, based on what has been specified in Rel-17, and based on the services requirements defined in TS 22.278 and TS 22.261. The detailed objectives are to investigate potential 5GS enhancements in order to support the followings: 1) 5G System enhancements to support Rel-17 5G ProSe leftovers: 1a) Support of service continuity when switching between direct NR Uu communication path and direct NR PC5 communication path (i.e. non-relay case). 1b) Support of service continuity when switching between two indirect network communication paths for Layer-3 and Layer-2 UE-to-Network Relay (NR PC5 and NR Uu are used). 1c) Support of MBS traffic to Remote UE by Layer-3 and Layer-2 UE-to-Network Relay. 1d) Enhancement of Layer-3 and Layer-2 UE-to-Network Relay for support of multiple NR PC5 hops. 1e) Support of one NR PC5 hop and multiple NR PC5 hops of Layer-3 and Layer-2 UE-to-UE Relay. 2) 5G System enhancements to support new Proximity Services requirements: 2c) Support of non-3GPP RAT (e.g. Wi-Fi or Bluetooth) over PC5 reference point for Layer-3 and Layer-2 UE-to-Network Relay. 2d) Support of Emergency Services for Remote UE over Layer-3 and Layer-2 UE-to-Network Relay. 2e) Whether and how 5GC-level Direct Discovery is supported. 2f) Support of Inter-gNB mobility for Layer-2 UE-to-Network Relay. 2i) Support of PWS/ePWS for Remote UE over Layer 3 and Layer 2 UE-to-Network Relay will be addressed during the normative phase. Architectural implications for RAN will be coordinated with RAN WGs. NOTE 1: Whether and how objectives on 1b), 1c), 1d), 1e), 2c), 2d), 2f) and 2i) for UE-to-Network Relay / UE-to-UE Relay will be supported is subject to RAN WGs study and coordination. NOTE 2: Whether all the regulatory service requirements for Emergency Services to be supported for UE-to-Network Relay needs investigation.

Comment:

CC#4: _rev1 noted. Revised to SP-211127.

Discussion and conclusion:

CC#4: rev1 noted. (To be revised by MCC).

e-mail discussion:

Ming (CATT) provides rev01.

Status:

Revised to SP-211127.

TD SP-211127 (SID NEW) New SID on Study on Proximity based Services in 5GS - Phase 2. (Source: CATT).
Document for: Approval.
Abstract: Objective: The study item aims at further investigating 5G System enhancements to support Proximity Services, based on what has been specified in Rel-17, and based on the services requirements defined in TS 22.278 and TS 22.261. The detailed objectives are to investigate potential 5GS enhancements in order to support the followings: 1) 5G System enhancements to support Rel-17 5G ProSe leftovers: 1a) Support of service continuity when switching between direct NR Uu communication path and direct NR PC5 communication path (i.e. non-relay case). 1b) Support of service continuity when switching between two indirect network communication paths for Layer-3 and Layer-2 UE-to-Network Relay (NR PC5 and NR Uu are used). 1c) Support of MBS traffic to Remote UE by Layer-3 and Layer-2 UE-to-Network Relay. 1d) Enhancement of Layer-3 and Layer-2 UE-to-Network Relay for support of multiple NR PC5 hops. 1e) Support of one NR PC5 hop and multiple NR PC5 hops of Layer-3 and Layer-2 UE-to-UE Relay. 2) 5G System enhancements to support new Proximity Services requirements: 2c) Support of non-3GPP RAT (e.g. Wi-Fi or Bluetooth) over PC5 reference point for Layer-3 and Layer-2 UE-to-Network Relay. 2d) Support of Emergency Services for Remote UE over Layer-3 and Layer-2 UE-to-Network Relay. 2e) Whether and how 5GC-level Direct Discovery is supported. 2f) Support of Inter-gNB mobility for Layer-2 UE-to-Network Relay. 2i) Support of PWS/ePWS for Remote UE over Layer 3 and Layer 2 UE-to-Network Relay will be addressed during the normative phase. Architectural implications for RAN will be coordinated with RAN WGs. NOTE 1: Whether and how objectives on 1b), 1c), 1d), 1e), 2c), 2d), 2f) and 2i) for UE-to-Network Relay / UE-to-UE Relay will be supported is subject to RAN WGs study and coordination. NOTE 2: Whether all the regulatory service requirements for Emergency Services to be supported for UE-to-Network Relay needs investigation.

Comment:

Revision of SP-210994_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-210995 (SID NEW) New SID: Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3.. (Source: Lenovo, Motorola Mobility, ZTE, Broadcom, Apple, Alibaba, Tencent, China Mobile, Convida Wireless, Deutsche Telekom, Nokia, Nokia Shanghai Bell, Samsung, Interdigital, Matrixx, Cisco Systems, Charter Communications, CableLabs, Comcast, CATT, Intelsat, Vivo, BT, Thales, HPE, Tessares, Telefonica).
Document for: Approval.
Abstract: New SID: Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3.

Comment:

CC#4: _rev1 noted. Revised to SP-211128.

Discussion and conclusion:

CC#4: rev1 noted. (To be revised by MCC).

e-mail discussion:

Apostolis (Lenovo) provides rev1 with additional supporting companies (KPN and Orange).

Status:

Revised to SP-211128.

TD SP-211128 (SID NEW) New SID: Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3.. (Source: Lenovo, Motorola Mobility, ZTE, Broadcom, Apple, Alibaba, Tencent, China Mobile, Convida Wireless, Deutsche Telekom, Nokia, Nokia Shanghai Bell, Samsung, Interdigital, Matrixx, Cisco Systems, Charter Communications, CableLabs, Comcast, CATT, Intelsat, Vivo, BT, Thales, HPE, Tessares, Telefonica).
Document for: Approval.
Abstract: New SID: Study on Access Traffic Steering, Switching and Splitting support in the 5G system architecture; Phase 3.

Comment:

Revision of SP-210995_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-210996 (SID NEW) New SID: Study on 5G support for Femto. (Source: Nokia, Nokia Shanghai Bell).
Document for: Information.
Abstract: New Study on 5G support for Femto.

Comment:

CC#4: _rev2 noted. Revised to SP-211129.

Discussion and conclusion:

CC#4: rev2 noted. (To be revised by MCC).

e-mail discussion:

Rainer (Nokia) provides rev01.
KPN to be added as supporting company
Rainer (Nokia) provides rev02.

Status:

Revised to SP-211129.

TD SP-211129 (SID NEW) New SID: Study on 5G support for Femto. (Source: Nokia, Nokia Shanghai Bell).
Document for: Information.
Abstract: New Study on 5G support for Femto.

Comment:

Revision of SP-210996_rev2. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-210997 (SID NEW) Study on 5G Timing Resiliency and TSC&URLLC enhancements. (Source: Nokia, Nokia Shanghai Bell).
Document for: Information.
Abstract: Study on 5G Timing Resiliency and TSC&URLLC enhancements.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-210998 (DISCUSSION) Rel-18 Requirements for Access Traffic Steering, Switching & Splitting (ATSSS). (Source: Lenovo, Motorola Mobility, ZTE, Broadcom, Apple, Alibaba, Tencent, China Mobile, Convida Wireless, Deutsche Telekom, Nokia, Nokia Shanghai Bell, Samsung, Interdigital, Matrixx, Cisco Systems, Charter Communications, CableLabs, Comcast, CATT, Intelsat, Vivo, BT, Thales, HPE, Tessares, Telefonica).
Document for: Information.
Abstract: Rel-18 Requirements for Access Traffic Steering, Switching & Splitting (ATSSS).

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-211001 (SID NEW) New SID on Enhancement of Support for Separation and Isolation of NF and data in 5GC. (Source: China Telecomunication Corp.).
Document for: Approval.
Abstract: Objective: The study item will study (Investigate the key issues and corresponding solutions) the potential enhancements for Separation and Isolation of NF and Data in 5GC, including: 1. Whether and how to support messages filter and topology hiding on the NF used to isolate the NFs deployed at the vertical and the NFs deployed at the PLMN to ensure that some information of the PLMN operator's network, e.g. the NF Instance ID, is not exposed to NFs deployed at the vertical. 2. Whether and how to support communications between the UDM deployed at vertical, which only stores subscription data of users of vertical customers, and NFs deployed at PLMN operator's network. a. Defining and identify which signaling should be forwarded to NFs deployed at operator's network and which to NFs deployed at vertical, e.g. signaling related to authentication should be forwarded to NFs deployed at operator's network, if NFs deployed at the vertical are not connect directly. b. How to authorize enterprise's UEs to obtain subscription data from UDM deployed at vertical after enterprise' UEs being authenticated through the AUSF and UDM located in the PLMN operator network. 3. Whether and how to support the positioning scenario where the vertical which may contain dedicated AMF, SMF and UPF communicates with the LMF located in the operator's network. 4. Whether and how to support the analysis scenario where the vertical which may contain dedicated AMF, SMF and UPF communicates with the NWDAF deployed at the operator's network. 3 TUs are foreseen to complete this study. And 1.5 TUs for normative work.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211002 (SID NEW) New SID: Study on UPF enhancement for control and SBA. (Source: China Mobile, AT&T, Vodafone, CATT, Tencent, Deutsche Telekom, SK Telecom, Sandvine, Matrixx).
Document for: Approval.
Abstract: Study on UPF enhancement for control and SBA.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211003 (SID NEW) New SID: Study on enhancement of 5G AM Policy. (Source: China Telecom Corporation Ltd., CATT, China Mobile, China Unicom, Ericsson, Huawei, Intel, Oracle, Tencent, vivo, ZTE).
Document for: Approval.
Abstract: New SID for SA2 on enhancement of 5G AM policy.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211006 (SID NEW) New SID: 5G Architecture enhancements for Harmonized Communication and Sensing service. (Source: Huawei, HiSilicon, vivo, CAICT, China Unicom, China Mobile, China Telecom, CATT, ZTE, OPPO).
Document for: Approval.
Abstract: New SID proposal: 5G Architecture enhancements for Harmonized Communication and Sensing service.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211008 (SID NEW) New SID: Study on enhancement of 5G UE Policy. (Source: Intel, Qualcomm Incorporated, OPPO, ZTE, NTT Docomo, vivo, Telecom Italia, China Unicom, Huawei, HiSilicon, Vodafone, CATT, MediaTek, KPN, China Telecom, CMCC, KDDI, Xiaomi, Apple, Verizon UK Ltd, Samsung, Lenovo, Motorola Mobility, LG Electronics, Rakute).
Document for: Approval.
Abstract: Study item on enhancement of 5G UE Policy; resubmission of S2-2106804.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211009 (SID NEW) New SID: Study on System Enabler for Service Function Chaining.. (Source: Intel, Telecom Italia, Spreadtrum, Sandvine, Convida Wireless, KPN, InterDigital, Microsoft, Matrixx, KDDI, AT&T, Deutsche Telekom, Cisco, Charter Communications).
Document for: Approval.
Abstract: Stage 2 system enabler for Service function chaining; resubmission of S2-2106815.

Comment:

CC#4: _rev1 noted. Revised to SP-211132.

Discussion and conclusion:

CC#4: rev1 noted. (To be revised by MCC).

e-mail discussion:

Saso (Intel) provides rev1 including TU estimations per objective.

Status:

Revised to SP-211132.

TD SP-211132 (SID NEW) New SID: Study on System Enabler for Service Function Chaining.. (Source: Intel, Telecom Italia, Spreadtrum, Sandvine, Convida Wireless, KPN, InterDigital, Microsoft, Matrixx, KDDI, AT&T, Deutsche Telekom, Cisco, Charter Communications).
Document for: Approval.
Abstract: Stage 2 system enabler for Service function chaining; resubmission of S2-2106815.

Comment:

Revision of SP-211009_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-211010 (SID NEW) New Rel-18 SID AI/ML management. (Source: Intel, Verizon).
Document for: Approval.
Abstract: Objective: To study the AI/ML management capabilities to support/coordinate AI/ML in 3GPP management system, 5GC and NG-RAN, including 1) the scenarios/use cases, potential requirements, and possible solutions for AI/ML management, including, but not limited to the following capabilities: - ML model creation - ML model testing - ML model validation - ML model deployment/distribution - ML model activation/deactivation - ML model configuration - ML model selection - ML model update - ML model replacement - ML model performance evaluation - ML model termination 2) Investigation of coordination between the AI/ML management capabilities mentioned in objective 1) and the ML model training and transfer capabilities in 5GC; 3) investigation of which MnSs (e.g., MDA) the AI/ML can be used for, and the data to support the ML model management for each MnS; 4) relation between AI/ML management and other MnSs and network functions/entities. The study will also investigate whether there are available AI/ML management mechanisms developed outside of 3GPP can be considered. Note: as a priority, the study will first focus on the objective 1), specifically addressing management capabilities for the ML model validation, deployment and update to support the AI/ML in NG-RAN.

Comment:

CC#3: This was then noted and can be contributed by companies to SA WG5.

Discussion and conclusion:

CC#3: Intel reported that the status after discussion was that Nokia and Ericsson are not in favour of approving this SA WG5 SID. The TSG SA Chair asked whether it is expected that this can be resolved by further discussion time. Nokia commented that they did not think there was any urgency to start this now and preferred to leave it for discussion in SA WG5. Ericsson added that this could also be done as part of another related WI in SA WG5. This was then noted and can be contributed by companies to SA WG5.

e-mail discussion:

Rainer (Nokia) agrees with Robert (Ericsson) and proposes to note S2-211010.
Ericsson express concern with bringing an ongoing and non-conclusive SA5 discussion on SIDs directly to SA plenary as there is no clear urgency for approval of such Rel-18 SID.
Saso (Intel) comments.
Ericsson comments.
Rainer (Nokia) replies to Saso (Intel).
Saso (Intel) replies to Robert (Ericsson).
Krister (Ericsson) ask why the RAN3 LS scope is not the urgent need to resolve.

Status:

Noted.

TD SP-211014 (SID NEW) New SID on Support of satellite backhaul in 5GS. (Source: CATT, Thales).
Document for: Approval.
Abstract: This contribution proposes a new SID on Support of satellite backhaul in 5GS.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211020 (SID NEW) Study on architecture enhancement for XR and media services. (Source: China Mobile, Huawei, Hisilicon, Tencent,Xiaomi).
Document for: Approval.
Abstract: Study on architecture enhancement for XR and media services.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211021 (SID NEW) New SID on Study of Architecture Enhancement for Vehicle Mounted Relays. (Source: Qualcomm Incorporated (rapporteur), Sony, InterDigital Inc. AT&T, Verizon UK Ltd, ZTE Corporation, Telstra, vivo Mobile Communications Ltd, Volkswagen AG, Philips International B.V., Xiaomi, SyncTechno Inc., FirstNet, Lenovo/Motorola Mobility, LG Electronics, Rakuten Mobile Inc.).
Document for: Approval.
Abstract: New SID on Study of Architecture Enhancement for Vehicle Mounted Relays (as per SA WG2#146 submitted S2-2106814).

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211022 (SID NEW) New SID on Personal IoT and Residential Networks architecture. (Source: vivo Mobile Communication,CATT, China Telecom, Convida Wireless, InterDigital, KPN, OPPO, Philips, Spreadtrum Communications, T-Mobile USA, Tencent, Xiaomi).
Document for: Approval.
Abstract: New SID on Personal IoT and Residential Networks architecture.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211023 (SID NEW) New SID of Further Architecture Enhancement for UAV and UAM. (Source: Qualcomm (rapporteur), Verizon, AT&T, Interdigital, FirstNet, Futurewei, CMCC, Oppo, Nokia, Nokia Shanghai Bell, T-Mobile, Panasonic, SK Telecom, Ericsson).
Document for: Approval.
Abstract: Study of Further Architecture Enhancement for UAV and UAM (as per SA WG2#146 submitted: S2-2106803).

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211024 (SID NEW) New SID on UE Aggregation for Industry with Multi-connectivity. (Source: vivo Mobile Communications Ltd, China Telecom, China Unicom, CATT, Spreadtrum Communications).
Document for: Approval.
Abstract: New SID on UE Aggregation for Industry with Multi-connectivity.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211025 (SID NEW) New Study on Service-based interface between NG-RAN and 5GC. (Source: Intel, Qualcomm Incorporated, Deutsche Telekom, Verizon UK Ltd., AT&T, Microsoft, Orange, Cisco, InterDigital).
Document for: Approval.
Abstract: Objective: This study item aims at investigating 5GS enhancements to enable the use of a service-based interface between NG-RAN and the 5GC for selected N2 functionality that is not related to UE mobility or NAS signalling. Specifically, the study aims to investigate the following aspects: 1. Identification of N2 functionality not related to UE mobility or NAS signalling that can benefit from a service-based interface. Examples include UE Radio Capability ID mapping, obtaining of non-UE associated assistance data, broadcast of assistance data by an LMF, Warning Request Transfer, communication between NG-RAN and NWDAF (depending on RAN WG3 progress), etc. As part of the study, and in close cooperation with RAN WG3, it will be investigated whether the service-based interface could also be used for direct conveyance of information between NG-RAN nodes that currently traverses the AMF transparently (e.g. RIM Information Transfer, Configuration Transfer for SON). 2. Mechanisms for implementation of the identified NG-RAN services (i.e. service registration, service discovery, request/response vs subscribe/notify paradigm, etc.). 3. Investigate the migration and co-existence aspects for deployments where NG-RAN nodes supporting a service-based interface need to co-exist with legacy NG-RAN nodes. The study will be coordinated with RAN WG3 and CT WG4 WGs as needed. The focus of the SA WG2 work will be on the generic stage 2 framework for a service-based interface for the identified N2 functionality (as listed in the objectives above) that falls under SA WG2 responsibility. As part of the study it will be concluded whether and how to proceed with normative work. The time for this study item is estimated at 5 TUs, as summarized in the table.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211027 (SID NEW) New SID on Study of Enhanced System enablers for Multi-USIM devices. (Source: Sony, Samsung, Convida Wireless, InterDigital, NEC).
Document for: Approval.
Abstract: Objective: The aim of this study work is to investigate and identify potential system level enablers for 5GS and EPS to support enhanced MUSIM operation. The study only includes Multi-USIM device which has the same UE radio implementation limitation as in the rel-17 MUSIM work item. Specifically, the objectives include: - Study system enablers that would allow more than one USIM to communicate simultaneous with the same or multiple networks. The simultaneous communication on multiple USIM is expected to use a time division (TD) scheme, due to UE radio limitations. - Study necessary signalling, e.g. UE to CN, CN to RAN and UE to RAN (out of scope for SA WG2 but may be important from overall system operation); including support of intra network coordination if Multi-USIM device uses USIMs with same operator. - Whether and how a network takes the TD scheme in consideration when establishing new QoS Flow(s) or modifies QoS Flow(s). - Revisit signalling and operation optimizations discussed during the rel-17 study, but judged to be out of scope for rel-17 normative work: - support of intra network UE coordination. TU Plan: estimate 6 TUs (4 TUs for the study and 2 TUs for the normative work).

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211041 (SID NEW) New SID: Study on system architecture for next generation real time communication services.. (Source: China Mobile, China Unicom, Huawei, Hisilicon, ZTE, CATT, Vivo).
Document for: Approval.
Abstract: New SID on system architecture for next generation interactive real time communication services.

Comment:

Revision of S2-2106816. CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211051 (DISCUSSION) Discussion about how to network based Sensing in R18. (Source: vivo Mobile Communication).
Document for: Information.
Abstract: Discuss how to network based Sensing in R18 and also share trial results for breathing monitoring by resusing existing UE measurement.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-211052 (SID NEW) Study on Enablers for Network Automation for 5G - phase 3. (Source: China Mobile, vivo).
Document for: Approval.
Abstract: Study on Enablers for Network Automation for 5G - phase 3.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211065 (SID NEW) New SID on Mobile Computing Power Network in 5GS. (Source: China Telecomunication Corp.).
Document for: Approval.
Abstract: Objective: The objectives of this SA WG2 study are to study how 5G system can be enhanced to support mobile computing power network, including - Identification and standardization of computing power; - How to support QoS for computing power- - How to negotiate and distribute computing power per the service requirements of 5G users, network conditions; - How to manage the function which jointly optimizes communication resource and computing resources - Enhancement on the control plane and/or the user plane of 5GC, e.g., whether new entity(s) for computing power control and new entity(s) providing computing power resource are needed. The time budget for this study is estimated at 8 TUs.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211077 (DISCUSSION) Discussion on Seamless UE context recovery. (Source: Samsung R&D Institute India).
Document for: Information.
Abstract: Discussion on Seamless UE context recovery.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-211078 (SID NEW) New SID: Study on Seamless UE context recovery. (Source: Samsung, NEC, CableLabs, Cisco ).
Document for: Approval.
Abstract: Objective: Following objectives are expected to be studied: 1) Study the mechanisms in which the 'unavailability period' is determined for the UE based on co-ordination between UE-5GC and 5GC-AF(s). 2) Study the mechanisms for zero or minimal impact on the UEs context at both UE and network side (e.g AMF, SMF) when UE gets into RM-DEREGISTERED state and re-register again. 3) Study the mechanisms for minimizing session management and upper layer service interruptions when UE gets into RM-DEREGISTERED state and re-register again. 4) Study the mechanisms in which minimal signalling impact is incurred on network when UE gets into RM-DEREGISTERED state and re-register again. NOTE 1: Example events in which UE gets in RM-DEREGISTERED state and re-register again are listed in justification section. NOTE 2: The RM-DEREGISTERED state and re-register again above indicates today's implementations, the solutions in this study can aim to achieve above objectives by retaining the UE in RM-REGISTERED state. TU Plan: estimate 6 TUs (4 TUs for the study and 2 TUs for the normative work).

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211080 (SID NEW) New SID: new Study on the support for 5WWC, Phase 2. (Source: Nokia, Nokia Shanghai Bell, Huawei, HiSilicon, Deutsche Telekom, Broadcom, Lenovo, Motorola Mobility, Qualcomm, KPN, China Telecom).
Document for: Information.
Abstract: Objective: Editor's Note: some items in this list are raising concerns. The following aspects will be studied: 1. Study on how support following enlacements requested by BBF: a) Heterogeneous wireline access MTUs for User plane traffic (see S2-2105358 / BBF LIAISE 464) b) Void 2. Whether and how to improve the support of devices connecting behind 5G-RG including: a) community WiFi for UE and Wireline devices connected via WLAN to a 5G RG (for example mobility support for device connecting from 3GPP access in external network to Community Wifi as guest) , b) the QoS and charging for UE connected behind an RG via Untrusted and Trusted Non-3GPP access solution. c) the mobility of Wireline devices connecting behind RG that does not participate in a community WiFi. 3. Trusted Non-3GPP access network a) How to support intra-TNGF and inter-TNGF mobility for UE accessing 5GC via trusted non-3GPP access network. b) How to select a TNGF that supports the S-NSSAI requested by the UE during registration via trusted non-3GPP access network. c) Whether and how to support mobility between 3GPP access network and trusted Non-3GPP access network for N5CW device. 4. Whether and how to improve mobility restriction granularity from TA granularity defined in R16 to a finer granularity in order to limiting the size of the area from where the 5G-RG with NG-RAN interface can connect to (this applies only to FWA). 5. ATSSS related a) Whether and how to improve the support of MA PDU session for 5G-RG done in R16, based on the R17 ATSSS_Ph2 normative work and ATSSS R18 studies. b) Whether and how to improve the support of MA PDU session for UE(s) that would wish to have MA PDU sessions while they are served by 5G RG that itself uses MA PDU Session 6. Whether and how the 5G-RG's subscription is automatically updated when it is moved to a different location, for example when user changes permanent addresses or move to a temporary location. (this applies only to FWA) 7. How to improve the support of L2 Bridge 5G-RG scenario for providing differentiated connectivity to devices behind the RG based on BBF requirements as expressed in their LS BBF-291/S2-1903875; 8. Whether and how to improve the support of RG in L3 gateway mode for providing differentiated connectivity to devices behind the RG, since a RG could work in L2 bridge mode, L3 gateway mode, or both simultaneously. 9. Whether and how to support the scenario with two layers of RGs, for example one 5G-RGs is deployed by the tenant of the building and several other 5G-RG are deployed in each single apartment which may belong to the same or a different 5GC. 10. Whether and how to support separate IPTV access rights for multiple STB(s) under the coverage of the same RG. 11. Study potential impacts from requirements defined as SA WG1 RESIDENT work onto the architecture defined in TS 23.316, This aspect excludes any work on PRAS; for this item any 5G RG requirement beyond the 3GPP UE functionality have to be addressed by BBF and cable labs which are responsible of the overall RG requirements Co-ordination with BBF and CableLabs will take place as needed during the study. 12 TU(s) are foreseen to complete this study. And 4 TU(s) for normative work.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211082 (SID NEW) Study on generic group management, exposure and communication enhancements. (Source: Huawei, China Mobile, China Telecom, China Unicom, Samsung, Juniper).
Document for: Approval.
Abstract: Study possible enhancements of generic group management and 5G capabilities exposure for industrial and automation applications, and enhancements of 5G VN group communication.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211083 (SID NEW) Study on Enhancement of support for Edge Computing in 5G Core network - phase 2. (Source: Huawei, HiSilicon, Alibaba, China Unicom, Convida Wireless, Intel, Toyota, vivo, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Objective: The study item will be conducted to study the potential system enhancements for enhanced edge computing support, including: 1) Improvements to roaming to support access to EHE in a VPLMN 2) Supporting consecutive traffic steering in different N6-LAN as described in clause 5.4 in TR 23.748. 3) Investigate the potential need and solutions for improved network exposure of UE traffic related information to common Edge Application Server via Local UPF/NEF. NOTE: XR/media and AI/ML services specific QoS information exposure are to be studied in corresponding study items with considering the same exposure framework as defined by this study. 4) Supporting EAS (re-)Discovery for split UEs with separated TE and MT. 5) Investigate the potential need and solutions for supporting offload policies to match collections of UE(s) considering categories of user subscriptions and applications.6) Investigate the potential need and solutions to influence of PSA-UPF and EAS (re)location for collection of UEs in scenarios when UE(s) should use the same EAS and are not members of a pre-defined group. 7) Investigate potential impacts related to the GSMA Operator Platform Group work, and potential improvements related with 5GC and EHE being operated by different organizations. NOTE: Existing solutions defined in Rel-15, Rel-16 and Rel-17 shall be considered as baseline in this study. NOTE: Alignment with corresponding work on EdgeApp in SA WG6 will take place as necessary. NOTE: Totally 8 TUs are estimated to be needed for this study and 5 TUs as an early estimation for normative work.

Comment:

CC#4: _rev1 noted. Revised to SP-211136.

Discussion and conclusion:

CC#4: rev1 noted. (To be revised by MCC).

e-mail discussion:

Huawei provides _rev1, adding KDDI as supporting company.

Status:

Revised to SP-211136.

TD SP-211136 (SID NEW) Study on Enhancement of support for Edge Computing in 5G Core network - phase 2. (Source: Huawei, HiSilicon, Alibaba, China Unicom, Convida Wireless, Intel, Toyota, vivo, Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Objective: The study item will be conducted to study the potential system enhancements for enhanced edge computing support, including: 1) Improvements to roaming to support access to EHE in a VPLMN 2) Supporting consecutive traffic steering in different N6-LAN as described in clause 5.4 in TR 23.748. 3) Investigate the potential need and solutions for improved network exposure of UE traffic related information to common Edge Application Server via Local UPF/NEF. NOTE: XR/media and AI/ML services specific QoS information exposure are to be studied in corresponding study items with considering the same exposure framework as defined by this study. 4) Supporting EAS (re-)Discovery for split UEs with separated TE and MT. 5) Investigate the potential need and solutions for supporting offload policies to match collections of UE(s) considering categories of user subscriptions and applications.6) Investigate the potential need and solutions to influence of PSA-UPF and EAS (re)location for collection of UEs in scenarios when UE(s) should use the same EAS and are not members of a pre-defined group. 7) Investigate potential impacts related to the GSMA Operator Platform Group work, and potential improvements related with 5GC and EHE being operated by different organizations. NOTE: Existing solutions defined in Rel-15, Rel-16 and Rel-17 shall be considered as baseline in this study. NOTE: Alignment with corresponding work on EdgeApp in SA WG6 will take place as necessary. NOTE: Totally 8 TUs are estimated to be needed for this study and 5 TUs as an early estimation for normative work.

Comment:

Revision of SP-211083_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-211084 (SID NEW) Study on Architectural enhancements for 5G multicast-broadcast services Phase 2. (Source: Huawei).
Document for: Approval.
Abstract: The goal of this Study Item is to identify and evaluate further enhancements to the 5G Multicast/Broadcast Architecture in order to provide a wider usage for Multicast/Broadcast services.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211085 (DISCUSSION) Background on: Extensions to the TSC Framework to support DetNet. (Source: Ericsson).
Document for: Information.
Abstract: Provides background on DetNet & SA WG2 work scope.

Comment:

Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-211086 (SID NEW) New SID: Extensions to the TSC Framework to support DetNet. (Source: Ericsson).
Document for: Information.
Abstract: Proposed SI based on SA WG2#146E discussion and revision, converted from WI to SI.

Comment:

CC#4: _rev1 noted. Revised to SP-211137.

Discussion and conclusion:

CC#4: rev1 noted. (To be revised by MCC).

e-mail discussion:

Ericsson provides revision 1 with additional supporting companies and rapporteur name.

Status:

Revised to SP-211137.

TD SP-211137 (SID NEW) New SID: Extensions to the TSC Framework to support DetNet. (Source: Ericsson).
Document for: Information.
Abstract: Proposed SI based on SA WG2#146E discussion and revision, converted from WI to SI.

Comment:

Revision of SP-211086_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

TD SP-211089 (SID NEW) New SID: Study on enhanced support of NR RedCap with long eDRX for RRC INACTIVE state. (Source: Ericsson, Deutsche Telekom, Verizon, Xiaomi, Sony, Nokia, Nokia Shanghai Bell).
Document for: Information.
Abstract: Submission of leftover work from Rel-17 based on RAN work.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211090 (SID NEW) New SID: Study on enhanced support of Non-Public Networks phase 2. (Source: Ericsson).
Document for: Information.
Abstract: Continuation of NPN work.

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

TD SP-211094 (SID NEW) New SID: PWS over non-3GPP access. (Source: Apple, Verizon UK Ltd, Broadcom, Convida Wireless).
Document for: Approval.
Abstract: Objective: The objective of this study is to investigate the feasibility of Public Warning System (PWS) over non-3GPP access. Detailed objectives of the study item are: 1) study the architectural impacts of adding non-3GPP access, connected to 3GPP core network, to PWS in EPS and 5GS network architectures. 2) study how to filter warning messages over non-3GPP access that are not relevant to the UE so the UE only displays warning messages that are intended in the geolocation area the UE is currently located. The time budget is estimated to be 4 TUs (3 TUs for study, 1 TU for normative phase).

Comment:

CC#4: Noted.

Discussion and conclusion:

CC#4: Noted.

Status:

Noted.

6.5 New Release 18 Work Item Descriptions

TD SP-211087 (DISCUSSION) Time Critical Communication: Latency Critical High-Rate Adaptive services & Low Latency Low Loss Scalable Throughput (L4S). (Source: Ericsson).
Document for: Information.
Abstract: Provides backgound and justification of L4S & why WI.

Comment:

CC#3: This was noted.

Discussion and conclusion:

CC#3: This was noted.

Status:

Noted.

TD SP-211088 (WID NEW) New WID: Use of L4S in 5GS. (Source: Ericsson).
Document for: Information.
Abstract: Support of L4S in 5GS.

Comment:

CC#4: _rev1 noted. (To be revised by MCC). Revised to SP-211138.

Discussion and conclusion:

CC#4: SP-211088_rev1 was noted. (To be revised by MCC to a new TD number).

e-mail discussion:

Saso (Intel) seeks clarification on ME impact.
Ericsson provides revision 1 with additional supporting companies, responds to Intel question.
Haris (Qualcomm) asks question for CN box.

Status:

revised by MCC). Revised to SP-211138.

TD SP-211138 (WID NEW) New WID: Use of L4S in 5GS. (Source: Ericsson).
Document for: Information.
Abstract: Support of L4S in 5GS.

Comment:

Revision of SP-211088_rev1. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

Block 3 (to approve Thursday 15:00 UTC)

TD SP-210957 (WID NEW) New WID Application layer support for Factories of the Future (FF). (Source: SA WG6).
Document for: Approval.
Abstract: Objective: Develop stage 2 normative technical specification for the application layer enablement capabilities based on identified key issues, solutions and conclusions in TR 23.745, including the following aspects: a) Defining architecture requirements corresponding to the application layer support capabilities. b) The functional architecture of the FF application layer illustrating the application layer support capabilities being utilized by the FF application specific entities (e.g. factory automation system and application residing on AGV, robot). c) Procedures and information flows supporting the related solutions and usage of SEAL procedures. d) Support integration of Operation Technologies (e.g. OPC-UA) with 5G system by utilizing application support layer capabilities (e.g. CAPIF, SEAL). e) Enhancements related to geographic location and positioning information support f) Support for Private slice monitoring g) Support for Edge computing deployment h) Message communication support for non-TSN messaging communications i) Support for TSC services j) Establishing communication with FF application service requirements.

Comment:

This WID NEW was approved.

Discussion and conclusion:

CC#3: This new WID was approved.

e-mail discussion:

Revision request (editorial)
This WID does not feature the SA header including the SP number.
The SP number is included in the SP-210957 doc header. However as the header is placed in the word header field it is visible in print (or show header /footer) view mode only, not draft view. The matter was also pointed out in an earlier post:
It has been concluded not to use the word header for future SA6 submissions.

Status:

Approved.

TD SP-210958 (WID NEW) New WID Mission Critical Services over 5MBS. (Source: SA WG6).
Document for: Approval.
Abstract: Objective: The present work item will address the necessary normative subjects required for the support of MC Services over 5GS to cover focus area 2: On-network - multicast and broadcast communications for Mission Critical Services, with the following objectives: 1.) Functional model - To address necessary updates on MC common functional model and MC service functional models in correspondence to the 5MBS architectural model considering transport only mode for group communication purposes; - Functional changes in the 5MBS context on the use of broadcast session; - Functional changes in the 5MBS context on the use of multicast session; - To enable MC service operation using 5GS and EPS; 2.) Identification - To address differences in the use of 5MBS identifiers; 3.) Session management aspects - To address required subscription enhancements; - To address required configuration in the use of 5MBS; - To address differences in the use of QoS parameters; 4.) Mobility aspects - To address the differences caused by mobility in the use of multicast mode/broadcast mode within the 5GS; - To address the differences caused by mobility in the use of multicast mode/broadcast mode between 5GS and EPS;

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210959 (WID NEW) New WID Gateway UE function for Mission Critical Communication. (Source: SA WG6).
Document for: Approval.
Abstract: Objective: The results from the study captured in 3GPP 23.700-79 build the basis for the normative work. Following aspects will be addressed: 1) Definition of the functional model to support the MC Gateway UE functionality. 2) Specify the necessary procedures to perform authentication and authorisation of an MC user on a non-3GPP device that hosts an MC service client and an MC user on a non-3GPP device that does not host an MC service client. 3) Determine and specify how an MC user identity is mapped to a non-3GPP device which hosts MC service clients and how an MC user identity is mapped to a non-3GPP device which does not host MC service clients. 4) Specify the necessary solution for 3GPP access network and MC related location information management for non-3GPP devices which can host an MC service client. 5) Specify how the MC service client on a non-3GPP device routes data and signalling via the MC gateway UE. 6) Specify the necessary solution for MBMS support of those MC service clients residing on non-3GPP devices. No dependencies to other 3GPP groups were identified during the study phase.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

e-mail discussion:

Revision request (editorial)
This WID submission does not feature the SA header including the SP number.

Status:

Approved.

TD SP-211053 (WID NEW) New WID on Supporting tactile and multi-modality communication services (TACMM). (Source: SA WG1).
Document for: Approval.
Abstract: Objective: The objective of this work item is to specify 5G service requirements and communication performance KPIs to support tactile and multi-modality communication services, including: - Service exposure requirements to enable 5G system support of tactile and multi-modality applications. - Communication performance KPIs.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211054 (WID NEW) New WID on Requirements on Vehicle-mounted relays (VMR). (Source: SA WG1).
Document for: Approval.
Abstract: Objective: The aim of this work is to define normative service requirements for 5GS support of vehicle-mounted relays, referred to as 'mobile base station (BS) relays', i.e. BS relays mounted on moving vehicles which provide 5G coverage and communication to UEs (inside the vehicle and/or in its vicinity), and are connected wirelessly to the 5G network via RAN (donor) nodes. Target requirements are based on the consolidated potential requirements derived from the FS_VMR study, captured in TR 22.839. including: - Support of mobile BS relays operation, provisioning, control and configuration - UE access control, charging, QoS, Multi-PLMN RAN sharing - Service continuity (including mobility of the UE and/or relay) - Multi-link connectivity by means of one or a series of mobile base station relays - Relays' roaming, regulatory requirements, emergency services, security, priority services, RAN management. NOTE: it is assumed that the wireless link between a mobile BS relay and UEs, as well as between mobile BS relay and donor RAN, uses NR-Uu radio; in that regard, it should be clear that a BS relay is different than a UE relay (which uses instead a PC5-based link to provide indirect network connection to remote UEs). NOTE 2: while the identified service requirements target potential 5G system (UE and/or NW) enhancements, mobile relay operation with legacy UEs shall also be supported.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211055 (WID NEW) New WID on PIN + Resident Service requirements (PIRATES). (Source: SA WG1).
Document for: Approval.
Abstract: Objective: This work item shall specify requirements for using the 5G system for Customer Premises and Personal IoT Networks as derived from TR 22.858 and TR 22.859. Specifically, this work item shall address requirements for: - Creation, provisioning and management of local networks and management of entities within these networks (e.g. the Smart Home / Office or Personal IoT Network) - Service and UE/ device discovery within a Customer Premises or Personal IoT network - Interactions between UEs / devices / applications within a Personal IoT or Customer Premises network and with UEs and/or services / applications in the cellular network. - Support of radio access within a Customer Premises Network - Support of gateway functionality between Personal IoT or Customer Premises network and 5G network - Enhancements to 5GLAN networks, e.g. for scalability - Support security aspects.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211056 (WID NEW) New WID on Service exposure for industrial automation (EXPOSE). (Source: SA WG1).
Document for: Approval.
Abstract: Objective: This work items proposes new normative service exposure requirements for TS 22.261, and it also corrects and augments existing TS-22.261 requirements. All pursuant change requests are based on specific requirements in the 5G-ACIA document 'Exposure of 5G Capabilities for Connected Industries and Automation Applications'. The topics covered in the change requests are - QoS monitoring and - UE position information.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211057 (WID NEW) New WID on MPS when access to EPC/5GC is WLAN (MPS_WLAN). (Source: SA WG1).
Document for: Approval.
Abstract: Objective: The objective is to define normative stage 1 requirements to support: - MPS for MMTEL voice/video calls when the UE has WLAN access to the EPC/5GC, and - MPS for DTS sessions when the UE or IoT device has WLAN access to the EPC/5GC (including aspects for Non-seamless WLAN Offload (NSWO) case when the 3GPP system is used to verify MPS authorization).

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211058 (WID NEW) New WID on Supporting Ad Hoc Group Communication in Mission Critical (AHGC). (Source: SA WG1).
Document for: Approval.
Abstract: Objective: The objective of this work item will be to specify requirements to support Ad hoc Group communication feature as part of MCX Services and thereby available for MCPTT, MCVideo and MCData. Ad hoc Group communication will be treated as a type of MCX service Group communication and it supports the mechanism of call processing and call termination identical to MCX service Group communication. This work item will identify and specify service requirements for: o enabling users to choose an arbitrary set of users and establish group communication without having to create group ahead of communication o enabling administrators to configure parameters related to the ad hoc group communication (e.g., authorization aspects, maximum call duration, default priority, maximum number of participants etc.) o security aspects o affiliation aspects pertaining to the participants of the ad hoc group communication o off-network support.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211059 (WID NEW) New WID on Sharing administrative configuration between interconnected MCX Service systems (SACI_MCS). (Source: SA WG1).
Document for: Approval.
Abstract: Objective: The objective of this work is to define normative service requirements for adding support for sharing administrative configuration between interconnected MCX Service systems. Target requirements are based on the consolidated potential requirements derived from the FS_SACI_MCS study, captured in TR 22.881.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

6.6 Revised Release 18 Study Item Descriptions and Work Item Descriptions

Block 3 (to approve / note Thursday 15:00 UTC)

TD SP-210830 (WID REVISED) Lawful Interception Rel-18. (Source: SA WG3-LI).
Document for: Approval.
Abstract: Objective: The objective of this work item is to enhance the 3GPP LI service to accommodate Release 18 service enhancements and extensions. Enhancements to TS 33.126 will address LI Service Stage 1 requirements. Enhancements to TS 33.107 and TS 33.127 will address LI Architectures and LI functions, LI stage 2. Enhancements to TS 33.108 and TS 33.128 will address LI stage 3 aspects. While the WID includes update of TS 33.107 and TS 33.108, this is for maintenance purposes only, with only minor changes to 33.107 and 33.108 expected.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210951 (SID REVISED) Revised SID Study on enhanced Application Architecture for enabling Edge Applications. (Source: SA WG6).
Document for: Approval.
Abstract: Objective: The SA WG6 objectives of this study item include the following: 1. Identify key issues, develop corresponding architecture requirements and potential enhancements to the architecture as required, based on: a. elaborate support for roaming i.e. access to edge computing services by UEs that are attached to PLMN networks other than their home networks; b. federation of services across ECSPs i.e. access to edge computing services via an ECSP different from the one to which the UE is associated; c. service continuity support across MNOs and ECSPs, with support for roaming and federation scenarios; d. new or enhancement to EEL capabilities and related APIs to support high performance of EAS; e. application context relocation (ACR) between EAS and cloud Application Servers; f. specification of EDGE-5 interface between the AC and the EEC; g. a framework to enable and manage EEL service differentiation; h. enhancements and optimizations of existing features (e.g. efficient communication for constrained devices like discovery bypass, push notification support, dynamic EAS instantiation), which were not completed in Rel-17; i. co-existence of network and application layer architecture solutions for Edge Computing e.g. discovery; and j. alignment with ETSI MEC and GSMA OP architectures; 2. Identify potential solutions as required, including the information flows and the APIs satisfying the architecture requirements, enhancements and alignment aspects identified in 1); 3. Identify new edge enabler layer models considering the enhancements identified in 2); and 4. Identify potential alignment of any northbound API definitions (e.g. direct network capability exposure, Edge application server enablement, SCEF/NEF/SCEF+NEF APIs) with CAPIF (TS 23.222) and related enhancements. NOTE: The split of responsibilities between SA WGs to harmonize with ETSI MEC and GSMA OP architectures require alignment in SA.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210952 (SID REVISED) Revised SID Study of Interconnection and Migration Aspects for Railways. (Source: SA WG6).
Document for: Approval.
Abstract: Objective: Identify gaps in existing mechanisms on interconnection and on migration which are required for railway communication and develop solutions to fill those gaps. The focus is on the following: 1. Connectivity related optimizations: a. between MC service systems (signaling and media) b. between MC service organizations (signaling and media) 2. Functional alias related aspects: a. use of functional alias in one MC service system (organization) allocated by the home MC system (organization) b. use of functional alias via multiple MC service systems (organizations) allocated by the home MC system (organization) c. functional alias activation/deactivation when the MC service user is in a different MC system or MC organization d. transfer/retrieval of functional alias binding for MC service groups when using a functional alias over multiple MC service systems or MC organizations 3. Call forwarding/call transfer related aspects: a. call forwarding to users in a different MC service system (organization) b. call transfer to involving users in a different MC service system (organization) 4. IP connectivity and SDS related aspects: a. point-to point (standalone) that involves two MC service systems (organizations) case 1: MC service user is abroad and shall use home breakout case 2: MC service user is in the home MC system (organization) and shall use local breakout b. group standalone that involves two MC service systems (organizations) case 1: MC service user is abroad and shall use home breakout case 2: MC service user is in the home MC system (organization) and shall use local breakout 5. Group communication related aspects: a. groups that are spread of multiple MC systems (organizations) that also involves MC system (organization) relocation during the group communication (actual use case in border areas) b. security implications when MC service users are involved that belong to different MC service systems (organizations) 6. Need to migrate from one MC system (organization) to another MC system (organization) at high speed with no loss of service 7. Location related aspects when involving users of multiple MC service systems (organizations).

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

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

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

e-mail discussion:

Revision request (editorial)
This WID revision does not feature the SA header including the SP number.

Status:

Approved.

6.7 Specifications for Information

TD SP-210857 (DRAFT TR) TR 28.816 'Study on charging aspects of 5GS CIoT'. (Source: SA WG5).
Document for: Information.
Abstract: Abstract of document: This technical report study the enhancements of charging aspects for 5GS CIoT features, defined in TS 23.501 and specifications. This technical report investigate the related charging aspects, including 5G data connectivity domain charging, Control plane data transfer domain charging, Monitoring event domain charging and the North bound API charging, and the charging use cases of 5GS CIoT that can be applicable to those charging aspects. The technical report identifies the potential solutions to key issues in charging use cases, evaluate potential solutions, and provides recommendations for the normative work. Changes since last presentation to SA Meeting: 3GPP TR 28.816 is presented for the first time. Outstanding Issues: None. Contentious Issues: None.

Comment:

CC#3: Block Approved. Should be for information. Moved to agenda item 6.7. CC#4: Noted.

Discussion and conclusion:

CC#3: Block Approved.
Should be for information. Moved to agenda item 6.7
CC#4: This was mistakenly indicated for approval and under agenda item 6.8. It was reallocated to agenda item 6.7 and indicated for Information in the TD lists. This was then noted.

e-mail discussion:

MCC pointed out a mistake on the allocation of TR 28.816. It was meant to be sent for information, not for approval.

Status:

Noted.

Block 3 (to note Thursday 15:00 UTC)

TD SP-210819 (DRAFT TR) Submission of the TR 26.998 V 1.0.0 for information. (Source: SA WG4).
Document for: Information.
Abstract: Abstract of document: This technical report provides a set of use cases for AR/MR experiences and various device architectures for AR glasses, including how they are integrated into 5G networks. Based on these architectures, call flows and potential content formats to enable various scenarios, such as 5G streaming, interactive, cognitive, and conversational services, are addressed. In conclusion, the report identifies potential needs for normative works to support AR glasses and experiences in 5G. Changes since last presentation to SA#91-e: This is the first presentation to SA. Outstanding Issues: Given that the device functional architectures and basic call flow have been agreed, the remaining work includes the following items: 1. Refinements of call flows for device types and service scenarios to be integrated into 5G System 2. Instantiations of service architectures and call flows for AR conversational services 3. Exploration of potential normative works & Conclusions of the TR Contentious Issues: None foreseen.

Comment:

CC#3: Block Noted.

Discussion and conclusion:

CC#3: Block Noted.

Status:

Noted.

TD SP-210855 (DRAFT TR) TR 28.815 'Study on charging aspects of edge computing'. (Source: SA WG5).
Document for: Information.
Abstract: Abstract of document: It is the TR of Rel-17 study on charging aspects of edge computing. Changes since last presentation to SA Meeting #92e: - Added possible solutions for charging for Session with QoS; - Added possible solutions for edge application access charging; - Added ECS charging information aggregation and technical solution; - Added evaluations and conclusions for the possible solutions of charging for 5GS usage, edge enabling infrastructure resource usage, EAS deployment and edge enabling services; - Added general conclusions and recommendations; - Editorial clean-ups. Outstanding Issues: The remaining work to be completed: - solutions for charging for 5GS usage based on monitored QoS; - evaluation of the solutions for edge application access charging; - evaluation of the solutions for ECS charging information aggregation. Contentious Issues: None.

Comment:

CC#3: Block Noted.

Discussion and conclusion:

CC#3: Block Noted.

Status:

Noted.

TD SP-210950 (DRAFT TR) Presentation of TR 23.700-90 v1.0.0 for information. (Source: SA WG6).
Document for: Information.
Abstract: Abstract of document: The work done so far on Mission Critical interconnection and migration did not fully address the needs for railways, additional work is required. Before starting normative stage 2 work on certain aspects, a study has been initiated to identify gaps in existing mechanisms on interconnection and on migration and to develop solutions for those gaps. The technical report aims to provide recommendations for solutions which are candidates for normative work. The present version of the document has identified following key-issues: - Optimize the connectivity between MC systems - Functional alias handling - Group communication between MC systems - Location information with multiple MC systems - Key issue 5 - Quick migration towards another MC system - Key issue 6 - Call forwarding/transfer between MC systems - Key issue 7 - IP connectivity between MC systems The document also provides several solutions: - Solution on functional architecture enhancements to support location information - Solutions on providing location information - Private call using functional alias towards a partner MC system - Functional alias support for migrated users - Migration during an ongoing group communication - Migration during an ongoing private communication Changes since last presentation to SA Meeting: 3GPP TR 23.700-90 is presented first time. Outstanding Issues: - Study and describe the existing mechanism of routing of media and signalling between MC systems and investigate optimizations and develop solutions to improve media and signalling routing between MC service systems. - Develop solutions which enable call forwarding and call transfer to MC service users in a different MC system. - Investigate and develop solutions for IP connectivity point-to-point transmissions and IP connectivity group standalone transmissions that involves two MC systems (support home and local breakout). - Resolve remaining editor's notes, complete the overall evaluation part and provide recommendations on solutions as guidance for the normative phase. Contentious Issues: No contentious issues have been identified.

Comment:

CC#3: Block Noted.

Discussion and conclusion:

CC#3: Block Noted.

Status:

Noted.

TD SP-211000 (DRAFT TS) Draft TS 28.557 Management of Non-Public Networks (NPN); Stage 1 and stage 2. (Source: SA WG5).
Document for: Information.
Abstract: Abstract of document: The document TS 28.557 specifies concepts, use cases, requirements and solutions for management of non-public networks. Changes since last presentation to SA Meeting: Presented for the first time. Outstanding Issues: Remaining solutions to be addressed include solutions for management of SNPN and solutions for management of PNI-NPN. Contentious Issues: No contentious issues.

Comment:

CC#3: Block Noted.

Discussion and conclusion:

CC#3: Block Noted.

Status:

Noted.

TD SP-210999 (DRAFT TR) Draft TR 28.817 Study on the access control for management services. (Source: SA WG5).
Document for: Information.
Abstract: Abstract of document: This Technical Report describes access control on management service. Outstanding Issues: The technical report needs quite a few editorial fixes to comply with drafting rules and MCC's comments. Contentious Issues: No contentious issues.

Comment:

CC#3: Block Noted.

Discussion and conclusion:

CC#3: Block Noted.

Status:

Noted.

TD SP-211042 (DRAFT TR) TR 22.926 on FS_GET (Guidelines for Extra-territorial 5G Systems) for information. (Source: SA WG1).
Document for: Information.
Abstract: Abstract of document: The present document identifies use cases and associated guidelines for the provision of services when a 5G public network has an extraterritoriality access component. This Technical Report (TR) addresses: - Use cases and associated conditions generating extraterritoriality of public 5G systems (e.g. HAPS covering multiple countries, satellite access covering international waters, aeronautical networks), - 3GPP features (e.g. emergency calls, PWS, LI, charging) and technical aspects (e.g. MCC/MNC, location of UE/NW) for which extraterritoriality may be relevant, and types of regulations that may be applicable. - Guidelines on the fulfilment of relevant regulatory requirements (e.g. routing to a core network in a specific country, use of MCC). Changes since last presentation: First presentation Outstanding Issues: Conclusions Clean up Contentious Issues: None.

Comment:

CC#3: Block Noted.

Discussion and conclusion:

CC#3: Block Noted.

Status:

Noted.

TD SP-211043 (DRAFT TR) TR 22.990 on FS_OFFNETRAIL (Study on Off-Network for Rail) for information. (Source: SA WG1).
Document for: Information.
Abstract: Abstract of document: TR 22.990 captures the outcome of the SA WG1 Rel-18 study FS_OffNetRail, aiming at identifying new use cases and potential service requirements for 5GS support of Rail Off-Network. The attached TR 22.990 is submitted for information. Changes since last presentation to SA: Agreed updated use cases and requirements, and conclusions. Outstanding Issues: A further step is necessary to identify limitations, missing requirements and gaps in existing functionalities supported by 3GPP before any potential normative work. This step could be performed by external bodies involved in the definition of Rail Off-Network use cases (e.g., UIC, ETSI TC RT). It was therefore recommended to wait for further gap analysis before finalizing consolidated requirements in this TR and trigger potential subsequent normative work (if deemed necessary). Contentious Issues: None.

Comment:

CC#3: Block Noted.

Discussion and conclusion:

CC#3: Block Noted.

Status:

Noted.

6.8 Specifications for Approval / for Information and Approval

TD SP-210942 (DRAFT TS) TS 23.548: '5G System Enhancements for Edge Computing; Stage 2 (Release 17)' for approval. (Source: SA WG2).
Document for: Approval.
Abstract: Abstract of document: The TS 23.548 defines the Stage 2 specifications for enhancements of 5G System to support Edge Computing based on the conclusions achieved in TR 23.748. The main contents include: - Reference architecture and connectivity models for supporting Edge Computing; - Edge Application Server discovery and re-discovery; - Edge Relocation; - Network Exposure to Edge Application Server; - Support of 3GPP application layer architecture for enabling Edge Computing; - Services of EASDF (Edge Application Server Discovery Function) - Informative annexes on considerations in e.g., UE and application layer, on supporting Edge Computing. Changes since last presentation to SA: This is the second time the TS is presented to TSG SA. The following issues were resolved: - Support for EASDF based EAS discovery procedure, including: - Definition/Provisioning of EAS deployment information from AF to EASDF/SMF. - Possible usage of multiple ECS options. - Possible refinement on service definition and invocation of EASDF and UPF. - How the AF triggers EAS relocation to the network. - Whether/how to support for service specific authorization for a group of UEs and any UE. - ECS Address Configuration Information provided by AF (data structure, usage of the information in 5GC and whether/how to support 'any UE'). - Ensure that 23.548 can apply to SNPN deployments. The TS is 95% complete. Outstanding Issues: The following issue is outstanding: - How to guarantee that the UE uses the DNS setting provided by operator for the subsequent DNS Query. Contentious Issues: The following contentious issue is not yet resolved:

Comment:

CC#1: Removed from Block approval. CC#4: Approved.

Discussion and conclusion:

CC#4: Option 1:
TSG SA#93-e tasks SA WG2 to address the issue documented in the editor's note of TS 23.548, clause 6.2.3.2.2 in 2021/Q4 taking into account user privacy and preferences
Option 2:
TSG SA#93-e tasks SA WG2 to address and solve the issue documented in the editor's note of TS 23.548, clause 6.2.3.2.2 in 2021/Q4
Option 3:
TSG SA#93-e tasks SA WG2 to address the issue documented in the editor's note of TS 23.548, clause 6.2.3.2.2 in 2021/Q4

AT&T commented that adding 'user privacy' in option 1 does not add any value and did not see the relevance in this context. Lenovo commented that it could also be that there is nothing to be done by SA WG2. Qualcomm could only accept Option 2. FutureWei asked whether option 3 could be changed from 'solve' 'to 'resolve''.
Option 2 was agreed and the guidance to SA WG2 is as follows.
SA#93-e tasks SA WG2 to address and solve the issue documented in the Editor's Note of TS 23.548, clause 6.2.3.2.2 in Q4 '21.
TS 23.548 (in SP-210942) was then approved and placed under Change Control (Release 17).

Status:

Approved.

Block 3 (to approve Thursday 15:00 UTC)

TD SP-210839 (DRAFT TR) Draft TR 33.854 'Study on security aspects of Uncrewed Aerial Systems (UAS)'. (Source: SA WG3).
Document for: Approval.
Abstract: Abstract of document: TR 33.854 is the study of the security aspects of Uncrewed Aerial Systems Changes since last presentation to <TSG> Meeting #<N>: None as first presentation Outstanding Issues: Abbreviations clause to be filled in, various corrections deriving from EditHelp review. Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210853 (DRAFT TS) Draft TS 33.326 'Security Assurance Specification for Network Slice-Specific Authentication and Authorization Function (NSSAAF)'. (Source: SA WG3).
Document for: Approval.
Abstract: Abstract of document: TS 33.326 is the NSSAAF SCAS Changes since last presentation to <TSG> Meeting #<N>: None as first presentation Outstanding Issues: None Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210856 (DRAFT TR) TR 28.814 'Study on enhancements of edge computing management'. (Source: SA WG5).
Document for: Approval.
Abstract: Abstract of document: It is the TR of Rel-17 study on enhancement of edge computing management. Changes since last presentation to TSG SA Meeting #92e: The major changes after SA#92e include: - Add concept and scenarios for 5GS enhancements for Edge Computing - Add management aspect for 5GS enhancements for Edge Computing - Add use cases and potential requirements for 5GS enhancements for Edge Computing - Add potential solutions for 5GS enhancements for Edge Computing Outstanding Issues: None Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210939 (DRAFT TS) TS 23.256: 'Support of Uncrewed Aerial Systems (UAS) connectivity, identification and tracking; Stage 2 (Release 17)' for approval. (Source: SA WG2).
Document for: Approval.
Abstract: Abstract of document: The TS 23.256 defines the Stage 2 specifications for enhancements of 5G System to support Uncrewed Aerial Systems (UAS) connectivity, identification and tracking based on the conclusions achieved in TR 23.754. The main contents include: - Support of UAV Remote Identification based on aviation industry regulations - Support of UAV authorization/authentication by USS/UTM to enable UAV tracking and identification once the UAV is authorized for flight by the USS/UTM, and UAV authorization revocation/failures - control plane solution for UAV authentication and authorization for the support of Remote Identification, UAV-USS connectivity, and UAV-UAV Controller connectivity, with the UAV authentication procedure with USS/UTM being supported optionally at 5GS registration (mandatory for UE, optional for the network) and with mandatory support (for both UE and network) at PDU session for 5GS and PDN connection establishment for EPS, and UAV- UAV Controller pairing and flight authorization performed at PDU session for 5GS and PDN connection establishment for EPS. - mechanisms for UAV tracking - mechanisms for pairing UAV with networked UAV Controller or UAV Controller connected to the UAV for C2 via the Internet - mechanism for revocation of UAV authorization - mechanism for revocation of UAV connectivity for C2 (command and control) - mechanisms for UAV Controller replacement The TS is 98% complete. Changes since last presentation to SA: This is the second time TS 23.256 is presented to TSG SA. Architecture and procedures have been added for the various objectives. The exceptions have been addressed. Outstanding Issues: No further functional modifications are expected. Some Editor's Notes need to be resolved. Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210940 (DRAFT TS) TS 23.304: 'Proximity based Services (ProSe) in the 5G System (5GS) (Release 17)' for approval. (Source: SA WG2).
Document for: Approval.
Abstract: Abstract of document: This document specifies the Stage 2 of the Proximity based Services (ProSe) features in 5GS. The following topics in SP-210272 have been standardized: - Support of PC5 Direct Discovery (including in-coverage and out-of-coverage cases). - Support of PC5 unicast, groupcast and broadcast modes communication (including in-coverage and out-of-coverage cases). - Support of PC5 Service Authorization and Policy/Parameter Provisioning. - Support of direct communication path selection between PC5 and Uu. - Support of Charging for PC5. - Support of Layer-3 and Layer-2 based UE-to-Network Relay (including QoS and service continuity aspects). Changes since last presentation to TSG SA: The following issues have been agreed: - Define the identification of ProSe Services. - Identify the additional parameters for UE-to-Network Relay and Group Member discovery. - Mobility restriction for UE-to-Network Relay and Remote UE. - Layer-2 and Layer-3 UE-to-Network Relay Distinction for relay discovery procedure. - IPv6 Prefix Delegation function to support Layer-3 UE-to-Network Relay. - Further enhancements of traffic control and RSC determination by the Remote UE. - Define conditions that would trigger L2 Connection Release procedure for UE-to-Network Relay operation. - The alignments with RAN on RAN dependency issues. The TS is 98% complete and no functional modifications are required. Some EN needs to be resolved. Outstanding Issues: - The alignments with the security procedures via coordination with SA WG3. - The alignments with RAN on RAN dependency issues. Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210941 (DRAFT TS) TS 23.247: 'Architectural enhancements for 5G multicast-broadcast services (Release 17)' for approval. (Source: SA WG2).
Document for: Approval.
Abstract: Abstract of document: This Technical Specification specifies architectural enhancements to the 5G system using NR to support multicast and broadcast communication services, and encompasses support for functions such as how to deliver multicast and broadcast communications including support within certain location areas, mobility, MBS session management, QoS and interworking with E-UTRAN and EPC based eMBMS for Public Safety. Changes since last presentation to SA: This is the second time TS 23.247 is presented to TSG SA. The progress of the TS is considered at 85%, some issues depend on the feedbacks of other WGs. Outstanding Issues: - Dependencies with RAN WGs/SA WG4/SA WG6/CT WG1/CT WG4 WG. Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210947 (DRAFT TR) Presentation of TS 23.554 v2.0.0 for approval. (Source: SA WG6).
Document for: Approval.
Abstract: Abstract of document: 3GPP TS 23.554 specifies the functional architecture, procedures, information flows and APIs for MSGin5G Service. MSGin5G Service provides messaging communication capability in 5GS especially for Massive Internet of Things (MIoT). The corresponding service requirements are defined in 3GPP TS 22.262. The TS includes the following aspects: 1. Architectural requirements; 2. Application layer architecture with the descriptions of functional entity, reference point and capability exposure overview; 3. Generic description of the MSGin5G Service (informative); 4. Detailed procedures and information flows, covering the following functionality: 1) Configuration of MSGin5G UE and Non-MSGin5G UE; 2) Registration of MSGin5G UE and Non-MSGin5G UE; 3) Message delivery procedures for the following message communication models: - Point-to-point message; - Application-to-point message/ Point-to-application message; - Group message; - Broadcast message; 4) Message Aggregation; 5) MSGin5G message Segmentation and Reassembly; 6) MSGin5G message interconnection between different PLMNs; 7) MSGin5G message store and forward; 8) Network Capabilities use. Changes since last presentation to SA Meeting #92-e: The following aspects listed in R-17 Work Item Exception sheet for 5GMARCH are finished: - Finalize development of how messages are routed by MSGin5G Server. - Develop procedure to support constrained devices in MSGin5G service. - Specify usage of SEAL group management for MSGin5G service - When MSGin5G UEs support different protocols, specify whether any entity other than MSGin5G Server is responsible for conversion. (see clause 5.3.2.3) - Develop the APIs of MSGin5G service including (not limited to) the following aspects: i. Registration ii. broadcast/group messaging - Alignment between specified functionality (e.g. UE reachability/ availability and store and forward, triggering, etc.). - Alignment among the existing procedures and functionalities in this TS - Conduct clean-up of TS 23.554 (e.g. resolve ENs). Outstanding Issues: The following aspects are considered to be finished in R-18: - Develop procedure to fulfil the store and forward requirement based on LS reply from SA WG1. - Conduct clean-up of TS 23.554 (e.g. resolves ENs). Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210948 (DRAFT TR) Presentation of TR 23.745 v2.0.0 for approval. (Source: SA WG6).
Document for: Approval.
Abstract: Abstract of document: TR 23.745 studies key issues, architecture requirements, FFAPP functional model, and corresponding solutions for application layer support for Factories of the Future in 5G network. This technical report progresses the objectives of the study, including the following: 1) Identification of 18 key issues and corresponding architecture requirements for application layer support for FF services including areas such as: - Use of network slicing for FFAPP. - Geographic location and positioning information support. - Clock synchronization. - TSN supporting. - QoS monitoring. - 5GLAN group management. - Device Onboarding. - Communication of FF application requirements with 5GS. - Communication service on the Edge deployments. - Integration with Existing Operation Technologies. - QoS coordination. - User authorization. - Capability Exposure related to Private Slice Network Status. - Device monitoring. - Support for group communication. - Constrained devices. - Using 5G CN capabilities for SEAL Groups. - Support for Message communication. 2) A FFAPP functional model is specified to support the FF application enabler functionalities which are illustrated via the solutions to the key issues. 3) 24 solutions specified address related key issues. 4) Solutions evaluation, overall evaluation and conclusion. Changes since last presentation to TSG SA: The following aspects are completed since the last presentation to SA: 1) Solutions modification. 2) Overall evaluation and conclusions are completed. Outstanding Issues: None Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210949 (DRAFT TR) Presentation of TR 23.700-79 v2.0.0 for approval. (Source: SA WG6).
Document for: Approval.
Abstract: Abstract of document: 3GPP TR 23.700-79 studies solutions to satisfy the requirements for a Gateway UE function. Requirements for this study were taken from stage 1 requirements, including 3GPP TS 22.179 and 3GPP TS 22.280. An MC gateway UE has the functionality of providing service access with the MC service system for multiple MC service clients. The MC gateway UE enables MC service access for those MC service clients operating on devices that have no MC service capabilities (incl. 3GPP transport). TR 23.700-79 has identified the key issues and corresponding solutions with recommendations for the normative work to be included into technical specifications for MCPTT, MCVideo, MCData and in the common functional architecture to support mission critical communications. Changes since last presentation to SA Meeting: 3GPP TR 23.700-79 was presented for information to SA#92-e first time. Latest changes: - Adding architectural changes and procedures to support MBMS for MC clients residing on non 3GPP devices that host an MC client (EPS only). - Elaborate and describe the routing of data and signalling by an MC gateway UE. - Clarifying aspects when multiple different MC gateway UEs are available (according latest stage 1 requirement changes). - Completing and refining the list of terms and resolve remaining editor's notes. - Complete the individual solution evaluation clauses. - Updating the overall evaluation clause according the latest achievements. - List the conclusions and recommendations for normative work. Outstanding Issues: There are no outstanding issues. Contentious Issues: No contentious issues have been identified.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211048 (DRAFT TR) TR 22.839 on FS_VMR (Study on vehicle-mounted relays) for approval. (Source: SA WG1).
Document for: Approval.
Abstract: Abstract of document: TR 22.839 captures the outcome of the SA WG1 Rel-18 study FS_VMR, aiming at identifying new use cases and potential service requirements for 5GS support of vehicle-mounted mobile BS relays, e.g. related to configuration, access control, service continuity, charging, mobility optimizations, PLMN-sharing, multi-connectivity, and other aspects. The attached TR 22.839 is submitted for approval. Changes since last presentation to SA: Agreed consolidated requirements, conclusions, and other clean-ups. Outstanding Issues: None Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211050 (DRAFT TR) TR 22.847 on FS_TACMM (Study on supporting tactile and multi-modality communication services in 5GS ) for one-step approval. (Source: SA WG1).
Document for: Approval.
Abstract: Abstract of document: TR 22.847 captures the outcome of the SA WG1 Rel-18 study FS_TACMM, aiming at identifying new use cases and potential service requirements for 5GS support of tactile and multi-modality communication services. Use cases involve immersive VR, remote control robot, support of skillset sharing for cooperative perception and maneuvering of robots, haptic feedback for a personal exclusion zone in dangerous remote environments, live event selective immersion, support for IEEE P1918.1 architecture and virtual factory. Requirements involves service exposure requirements to enable 5G system support of tactile and multi-modality applications. The attached TR 22.847 is submitted for approval. Changes since last presentation to SA: Not presented before. Outstanding Issues: Use cases have completed from rapporteur's point of view. Potential Requirements need to be to reviewed. Consolidated requirements need to be extracted from the existing use cases. Contentious Issues: None.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

7 Release Planning

7.1 General Release Planning issues

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

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

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

TD SP-210833 (DISCUSSION) Rel-18 Prioritization Proposal & General SA#93-e Preparation. (Source: TSG SA Chair).
Document for: Information.
Abstract: Rel-18 Prioritization Proposal & General SA#93-e Preparation.

Comment:

SP-210833_rev3 endorsed. Revised to SP-211119.

Discussion and conclusion:

CC#4: SP-210833_rev2 was presented.
Bullet 1: It should be clarified that SA WG2 are not expected to fit the WIs into the available TU budget (i.e. SA WG2 will not do prioritization). The SA WG2 Chair commented that if SA WG2 can determine whether a WI proposing a large number of TUs cannot be handled. The TSG SA Chair replied that this type of issue can be handled by SA WG2 in the normal way. Nokia commented that SA WG2 needs to define the TU budget but all WI proposals need to have realistic TU estimates. Ericsson commented that properly scoped WIs should be developed in SA WG2 and no changes are needed to this bullet. The first bullet was modified to: 'TU budget available for Rel-18 study/normative work needs to be derived under the assumption that 8 F2F can be organized until stage-2 functional freeze deadline. Even if some F2F meetings are organized as e-meetings the available TU budget should remain the same, i.e. such e-meetings will have the same TU limitations as the F2F meetings.'
Bullet 2: The TU estimates should be broken down to the level of objectives and their interdependencies.
Bullet 4: China Mobile suggested that this should be valid for all WGs. For the moment, this is only guidance to SA WG2. The SA WG2 Chair considered the responsibilities for secondary rapporteur was vague and suggested adding 'based on objectives'. Nokia commented that they preferred a single rapporteur for each WI and possibly another for the production of the TS/TR. CATT preferred to remove the bullet. As no agreement for it could be reached, the responsibilities of secondary rapporteur sub-bullet was then deleted. SA WG2 Char commented that the final sub-bullet should be clarified that the single Rapporteurship applies to both primary and secondary roles. It was decided to add 'this will be sorted out after the prioritization has taken place'. China Mobile asked whether it is correct that this is for the whole of Rel 18, not only the prioritization phase. The TSG SA Chair commented that the important thing is to have a primary Rapporteur to manage the Work Item who can do the job effectively.
Bullet 5: This repeats part of bullet 2 and was deleted.
Bullet 6: Nokia asked what is meant by 'time planning'. The TSG SA Chair clarified that if a company does not think there is time to include a WID, this can be raised at TSG SA and should not form the basis of an objection to the WI in SA WG2. The bullet was clarified to read 'such objections will not be considered by SA WG2'. Nokia asked to change 'time planning' to 'release planning'. Ericsson commented that SA WG2 needs to be able to provide a reasonable set of WIs to TSG SA#94-e and the SA WG2 Chair should be able to determine whether an objection has a technical basis. This was changed to 'overall time/release planning'.
Nokia commented that the output list for TSG SA on slide 3 should be removed as it has no value to SA WG2. The bullet was removed. The SA WG2 Chair suggested that the Rel-18 S/WI List in Slide 2 should not include ranking.
This was revised as SP-210833_rev3 which was endorsed (To be revised by MCC to a new TD number).

e-mail discussion:

Siemens thinks that the advice concerning SA2's TU allocation needs to be changed.
Huawei comments that the metrics used are not relecting the actual situation.
Saso (Intel) comments that the guidance in slide #4 should be understood as a mechanism to control the amount of workload in Rel-18.
Siemens asks Huawei for clarification on their statement of performance.
Huawei proposes a few hints to Siemens.
Siemens replies to Huawei
Tony (Futurewei) comments on the 3 bullets.
Tricci (OPPO) comments on the 3 bullets regarding the SA guidance to SA2
Puneet (SA2 Chair) comments
Siemens sustains its objection to treating SA2 e-meetings and face-to-face meetings as equal from a TU point of view.
Haris (Qualcomm) comments and proposes alternative text for one bullet
Yusuke (KDDI) requests for a clarification for a ranked list.
Siemens provides a resolution for its objection.
Siemens proposes an extension of the first bullet point on slide four based on discussions in this thread.
Huawei provides comments.

Status:

Revised to SP-211119.

TD SP-211119 (DISCUSSION) Rel-18 Prioritization Proposal & General SA#93-e Preparation. (Source: TSG SA Chair).
Document for: Information.
Abstract: Rel-18 Prioritization Proposal & General SA#93-e Preparation.

Comment:

Revision of SP-210833_rev3. Endorsed.

Discussion and conclusion:

Endorsed.

Status:

Endorsed.

TD SP-210834 (DISCUSSION) Rel-18 SA WG2 Related Study and Work Items. (Source: TSG SA Chair).
Document for: Endorsement.
Abstract: Rel-18 SA WG2 Related Study and Work Items.

Comment:

CC#3: Updated in SP 210834_rev1. CC#4: Revised to SP-211117.

Discussion and conclusion:

CC#3: This was presented by the TSG SA Chair and the items indicated with missing/multiple Rapporteurs and missing TU indications were reviewed. Agreed updates should be made to the SID/WID documents and revisions provided in the Revisions folder. The updated list was provided in SP 210834_rev1.
CC#4: This was revised to include all the updated TD numbers allocated after the close of the meeting in SP-211117.

e-mail discussion:

Saso (Intel) points that the SID in SP-211010 is an SA5 SID and should be handled separately from the SA2 SIDs.
Ericsson express concern with bringing an ongoing and non-conclusive SA5 discussion on SIDs directly to SA plenary as there is no clear urgency for approval of such Rel-18 SID.

Status:

Revised to SP-211117.

TD SP-211117 (DISCUSSION) Rel-18 SA WG2 Related Study and Work Items. (Source: TSG SA Chair).
Document for: Endorsement.
Abstract: Rel-18 SA WG2 Related Study and Work Items.

Comment:

Revision of SP-210834_rev1. Revised to SP-211143.

Discussion and conclusion:

This was uploaded without the new TD numbers by MCC, so was revised to include the newly allocated numbers in SP-211143.

Status:

Revised to SP-211143.

TD SP-211143 (DISCUSSION) Rel-18 SA WG2 Related Study and Work Items. (Source: TSG SA Chair).
Document for: Endorsement.
Abstract: Rel-18 SA WG2 Related Study and Work Items.

Comment:

Revision of SP-211117. Noted.

Discussion and conclusion:

-

Status:

Noted.

TD SP-210894 (DISCUSSION) Operators view on Rel18. (Source: Deutsche Telekom AG, BT, Orange, Telecom Italia, Telefonica).
Document for: Discussion.
Abstract: Operators perspective on Rel18 priorities and considerations.

Comment:

This was presented at the Rel-18 Workshop and was noted.

Discussion and conclusion:

CC#1: This was presented at the Rel-18 Workshop and was noted.

Status:

Noted.

TD SP-210899 (DISCUSSION) Views on Rel-18. (Source: MediaTek Inc.).
Document for: Discussion.
Abstract: MediaTek Inc. Views on Rel-18.

Comment:

Noted.

Discussion and conclusion:

MediaTek summarized the presentation which had been presented to the Rel-18 workshop. This was then noted.

Status:

Noted.

TD SP-211037 (DISCUSSION) On Rel-18 timeline and budgeting. (Source: Nokia, Nokia Shanghai Bell, MediaTek Inc, Sony, Samsung).
Document for: Agreement.
Abstract: On Rel-18 timeline and budgeting.

Comment:

This was left for further discussion over e-mail and was noted.

Discussion and conclusion:

CC#1: This was presented by Nokia. The source companies had analysed the number of SA WG2 meetings required and concluded that 8 meetings would be needed for Rel 18 and therefore proposed a 15 month Stage 2 Release period is needed. The TSG SA Chair did not want to discuss whether SA WG2 will do any Rel 18 work in Q4/2021, but agreed that it is unlikely that SA WG2 can start Rel 18 work before Q1/2022. Intel commented that the freeze date for Stage 2 is an important aspect for SA WG2 work planning and clear answer to this is expected at this TSG SA meeting. Ericsson asked whether the assumptions for meetings 1 and 2 are valid and asked whether only 7 meetings may be needed by combining the content of those meetings. Samsung commented that there are sound reasons why 6 meetings per year is the standard maximum and asked not to plan for SA WG2 to hold 8 meetings in 2022. MediaTek commented that this proposal is only to give SA WG2 15 months to do the Rel 18 Stage 2 work. Vodafone commented that trying to do a Release in 12 months is not workable as there are always the need for coordination with Stage 3 groups to complete the Stage 2 work. Deutsche Telekom supported Samsung in not scheduling more than 6 meetings per year and for a 15 month Rel 18 period for Stage 2. Nokia agreed that coordination with TSG RAN and TSG CT will be needed and did not think any discussions for more than 18 months should be entered into at this point. Nokia reminded the meeting that there had been a large number of SA WG2 Exceptions for Rel 17, which should be avoided for Rel 18. This was left for further discussion over e-mail and was noted.

Status:

Noted.

TD SP-211093 (DISCUSSION) SA WG2 Rel-18 Status and Planning Considerations. (Source: SA WG2 Chair ).
Document for: Presentation.
Abstract: SA WG2 Rel-18 Status and Planning Considerations.

Comment:

This was left for further discussion over e-mail and was noted.

Discussion and conclusion:

CC#1: This was left for further discussion over e-mail and was noted.

Status:

Noted.

8 Rel-8 CRs

9 Rel-9 CRs

10 Rel-10 CRs

11 Rel-11 CRs

12 Rel-12 CRs

TD SP-210825 (CR PACK) CR Pack on EVS Fixed Point and Floating Point source code and update of test vectors (26.442, 26.443 and 26.444). (Source: SA WG4).
Document for: Approval.
Abstract: 26.452 CR0004R1; 26.442 CR0039R1; 26.442 CR0040R1; 26.442 CR0041R1; 26.442 CR0042R1; 26.442 CR0043R1; 26.443 CR0036R1; 26.443 CR0037R1; 26.443 CR0038R1; 26.443 CR0039R1; 26.443 CR0040R1; 26.444 CR0036R1; 26.444 CR0037R1; 26.444 CR0038R1; 26.444 CR0039R1; 26.444 CR0040R1.

Comment:

This CR Pack was approved.

Discussion and conclusion:

CC#1: This CR Pack was approved.

Status:

Approved.

13 Rel-13 CRs

14 Rel-14 CRs

15 Rel-15 CRs

TD SP-210840 (CR PACK) Rel-15 CRs on Security aspects of 5G System - Phase 1. (Source: SA WG3).
Document for: Approval.
Abstract: 33.501 CR1145R1; 33.501 CR1146R1; 33.501 CR1191R1.

Comment:

This CR PACK was approved.

Discussion and conclusion:

CC#1: This CR Pack was approved.

Status:

Approved.

TD SP-210850 (CR PACK) Rel-15 CRs on TEI. (Source: SA WG3).
Document for: Approval.
Abstract: 33.501 CR1164; 33.501 CR1165; 33.501 CR1166; 33.501 CR1185R1; 33.501 CR1186R1; 33.501 CR1187R1.

Comment:

This CR PACK was approved.

Discussion and conclusion:

CC#1: This CR Pack was approved.

Status:

Approved.

TD SP-210879 (CR PACK) Rel-15 CRs on Network Resource Model (NRM) for 5G networks and network slicing. (Source: SA WG5).
Document for: Approval.
Abstract: 28.622 CR0109R1; 28.622 CR0110R1.

Comment:

This CR PACK was approved.

Discussion and conclusion:

CC#1: This CR Pack was approved.

Status:

Approved.

TD SP-210880 (CR PACK) Rel-15 CRs on Performance Assurance for 5G networks including network slicing. (Source: SA WG5).
Document for: Approval.
Abstract: 28.550 CR0067R1; 28.550 CR0068R1.

Comment:

This CR PACK was approved.

Discussion and conclusion:

CC#1: This CR Pack was approved.

Status:

Approved.

TD SP-210881 (CR PACK) Rel-15 CRs on Provisioning of network slicing for 5G networks and services. (Source: SA WG5).
Document for: Approval.
Abstract: 28.531 CR0067R1; 28.531 CR0068R1; 28.531 CR0069R1; 28.531 CR0073R1; 28.531 CR0075R1; 28.531 CR0076R1; 28.531 CR0077R1; 28.531 CR0078R1; 28.531 CR0079R1.

Comment:

This CR PACK was approved.

Discussion and conclusion:

CC#1: This CR Pack was approved.

Status:

Approved.

TD SP-210902 (CR PACK) CRs to 23.502: 5GS_Ph1 (Rel-15) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR3061R1; 23.502 CR3062R1; 23.502 CR3063R1; 23.502 CR2755R2; 23.502 CR2751R2; 23.502 CR2752R2.

Comment:

This CR PACK was approved.

Discussion and conclusion:

CC#1: This CR Pack was approved.

Status:

Approved.

TD SP-211030 (CR PACK) Stage 1 CR s on SMARTER. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0554R1; 22.261 CR0555R1; 22.261 CR0556R1; 22.261 CR0557R1.

Comment:

This CR PACK was approved.

Discussion and conclusion:

CC#1: This CR Pack was approved.

Status:

Approved.

16 Rel-16 CRs

TD SP-211026 (CR) 26.247 CR0168R4 (Rel-16, 'F'): QoE configuration release. (Source: Huawei).
Document for: Approval.
Abstract: Revision to Plenary: Correct the 'MTSI client' into the 'DASH client' in Annex L.1.

Comment:

Revision of 26.247 CR0168R3 in SP-210824. CC#2: This CR was approved.

Discussion and conclusion:

CC#2: Revision of 26.247 CR0168R3 in SP-210824. This CR was approved.

Status:

Approved.

TD SP-210824 (CR PACK) CR Pack on QoE configuration release (26.247). (Source: SA WG4).
Document for: Approval.
Abstract: 26.247 CR0168R3.

Comment:

Revision of 26.247 CR0168R3 proposed in SP-211026. CC#2: 26.247 CR0168R3 revised in SP-211026. Noted.

Discussion and conclusion:

CC#2: 26.247 CR0168R2 in this CR Pack was revised in SP 211026. This CR Pack was then noted.

Status:

Noted.

Block 4 (to approve Thursday 15:00 UTC)

TD SP-210821 (CR PACK) CR Pack on on QoE configuration release (26.114). (Source: SA WG4).
Document for: Approval.
Abstract: 26.114 CR0520R1; 26.114 CR0521R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210822 (CR PACK) CR Pack on Miscenallaneous Fixes to TV Video Profile (26.116). (Source: SA WG4).
Document for: Approval.
Abstract: 26.116 CR0016.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210826 (CR PACK) CR Pack on essential corrections to 26.512. (Source: SA WG4).
Document for: Approval.
Abstract: 26.512 CR0013R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210827 (CR PACK) CR Pack on Support of Network-Based Media Processing (26.939). (Source: SA WG4).
Document for: Approval.
Abstract: 26.939 CR0011R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210828 (CR PACK) Rel-16 CRs on Lawful Interception. (Source: SA WG3-LI).
Document for: Approval.
Abstract: 33.127 CR0137; 33.127 CR0138; 33.127 CR0143R1; 33.128 CR0224R1; 33.128 CR0226R1; 33.128 CR0223R1; 33.128 CR0225R1; 33.128 CR0236; 33.128 CR0237; 33.128 CR0238.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210849 (CR PACK) Rel-16 CRs on Security Assurance Specification for 5G. (Source: SA WG3).
Document for: Approval.
Abstract: 33.216 CR0023; 33.515 CR0008R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210851 (CR PACK) Rel-16 CRs on TEI. (Source: SA WG3).
Document for: Approval.
Abstract: 33.501 CR1175; 33.501 CR1176; 33.501 CR1201; 33.501 CR1160R1; 33.501 CR1159R2; 33.501 CR1170R1; 33.501 CR1149R1; 33.501 CR1150R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210862 (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 CR0320; 28.552 CR0316R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210865 (CR PACK) Rel-16 CRs on Management of MDT in 5G. (Source: SA WG5).
Document for: Approval.
Abstract: 28.622 CR0115; 28.623 CR0134; 32.422 CR0369; 32.422 CR0370; 28.622 CR0116; 28.623 CR0135; 32.422 CR0371; 32.422 CR0372; 32.422 CR0373R1; 32.422 CR0374R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210871 (CR PACK) Rel-16 CRs on NRM enhancements. (Source: SA WG5).
Document for: Approval.
Abstract: 28.541 CR0517; 28.541 CR0518; 28.541 CR0529; 28.541 CR0530; 28.622 CR0112; 28.541 CR0544; 28.541 CR0545; 28.541 CR0546; 28.541 CR0547; 28.541 CR0548; 28.623 CR0136; 28.541 CR0553; 28.541 CR0556; 28.541 CR0561; 28.541 CR0558R1; 28.541 CR0533R1; 28.541 CR0534R1; 28.622 CR0113R1.

Comment:

NOTE: 28.541 CR0548 should be WI Code adNRM, not eNRM. 3GU has been corrected for this CR. CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210878 (CR PACK) Rel-16 CRs on Methodology for 5G management specifications. (Source: SA WG5).
Document for: Approval.
Abstract: 32.160 CR0021R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210883 (CR PACK) Rel-16 CRs on Management of QoE measurement collection. (Source: SA WG5).
Document for: Approval.
Abstract: 28.404 CR0004; 28.405 CR0001.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210884 (CR PACK) Rel-16 CRs on Self-Organizing Networks (SON) for 5G networks. (Source: SA WG5).
Document for: Approval.
Abstract: 28.552 CR0317; 28.552 CR0318; 28.541 CR0521.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210885 (CR PACK) Rel-16 CRs on TEI batch 1. (Source: SA WG5).
Document for: Approval.
Abstract: 28.541 CR0522; 28.541 CR0523; 28.541 CR0524; 28.541 CR0552; 28.541 CR0555; 28.532 CR0185; 28.531 CR0081R1; 28.531 CR0071R1; 28.531 CR0082R1; 28.531 CR0074R1; 28.531 CR0083R1; 28.531 CR0080R1; 28.532 CR0178R1; 28.532 CR0179R1; 28.532 CR0180R1; 28.541 CR0565R1; 28.541 CR0557R1; 28.622 CR0111R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210886 (CR PACK) Rel-16 CRs on TEI batch 2. (Source: SA WG5).
Document for: Approval.
Abstract: 32.291 CR0336; 32.255 CR0323; 32.255 CR0324; 32.255 CR0325; 32.255 CR0326; 32.255 CR0327; 32.255 CR0328; 32.290 CR0166; 32.290 CR0167; 32.158 CR0021; 28.623 CR0132R1; 28.623 CR0131R1; 28.623 CR0133R1; 32.158 CR0018R2; 32.290 CR0168; 32.240 CR0427R1; 32.240 CR0428R1; 32.290 CR0169; 32.291 CR0342; 32.291 CR0335R1; 32.291 CR0337R1; 32.255 CR0329R1; 32.255 CR0330R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210903 (CR PACK) CRs to 23.501, 23.502: TEI16 (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2941; 23.502 CR3074; 23.502 CR3075; 23.501 CR3207; 23.501 CR3208; 23.502 CR3117; 23.502 CR3118; 23.682 CR0481R1; 23.682 CR0482R1; 23.502 CR3059R1; 23.502 CR3060R1; 23.502 CR2940R1; 23.501 CR3056R1; 23.501 CR3057R1; 23.502 CR3057R1; 23.502 CR3058R1; 23.502 CR2992R1; 23.502 CR2993R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210904 (CR PACK) CRs to 23.501, 23.502: 5G_CIoT (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3168; 23.501 CR3169; 23.502 CR3064; 23.502 CR3065; 23.502 CR3066; 23.502 CR3067.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210905 (CR PACK) CRs to 23.273: 5G_eLCS (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.273 CR0181; 23.273 CR0182; 23.273 CR0183R1; 23.273 CR0184R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210906 (CR PACK) CRs to 23.501: ATSSS (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3032R1; 23.501 CR3033R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210907 (CR PACK) CRs to 23.288: eNA (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.288 CR0397R1; 23.288 CR0398R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210908 (CR PACK) CRs to 23.501: eNS (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3234; 23.501 CR3190R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210909 (CR PACK) CRs to 23.502: ETSUN (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2812R3; 23.502 CR2813R3; 23.502 CR2971R1; 23.502 CR2972R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210910 (CR PACK) CRs to 23.401, 23.501, 23.502: RACS (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.401 CR3656; 23.401 CR3657R1; 23.501 CR3000R1; 23.501 CR3003R1; 23.502 CR2890R1; 23.502 CR2891R1; 23.401 CR3643R1; 23.401 CR3644R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210911 (CR PACK) CRs to 23.501, 23.502, 23.503: Vertical_LAN (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.503 CR0636; 23.501 CR3210; 23.501 CR3231; 23.501 CR3131R1; 23.503 CR0637R1; 23.502 CR3095R1; 23.501 CR3156R1; 23.501 CR3157R1; 23.501 CR2997R1; 23.501 CR2998R1; 23.502 CR2923R1; 23.501 CR3203R2; 23.501 CR3204R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210912 (CR PACK) CRs to 23.316, 23.501: 5WWC (Rel-16) and mirror CRs. (Source: SA WG2).
Document for: Approval.
Abstract: 23.316 CR2057; 23.316 CR2058; 23.501 CR3177; 23.501 CR3178.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210960 (CR PACK) Rel-16 CRs to TS23280 for enh2MCPTT. (Source: SA WG6).
Document for: Approval.
Abstract: 23.280 CR0294R3; 23.280 CR0292R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

17 Rel-17 CRs

17.1 SA WG1 Rel-17 CRs

Block 4 (to approve Thursday 15:00 UTC)

TD SP-211031 (CR PACK) Stage 1 CRs on TEI17. (Source: SA WG1).
Document for: Approval.
Abstract: 22.101 CR0576; 22.011 CR0324; 22.261 CR0572; 22.101 CR0577; 22.101 CR0574R1; 22.101 CR0575R1; 22.261 CR0575R1; 22.261 CR0576R1; 22.261 CR0571R1.

Comment:

Revised and CRs Reissued in SP-211096.

Discussion and conclusion:

-

Status:

Revised and CRs Reissued in SP-211096.

TD SP-211096 (CR PACK) Stage 1 CRs on TEI17. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0566; 22.101 CR0576; 22.011 CR0324; 22.261 CR0572; 22.101 CR0577; 22.101 CR0574R1; 22.101 CR0575R1; 22.261 CR0575R1; 22.261 CR0576R1; 22.261 CR0567R1; 22.261 CR0571R1.

Comment:

Reissue of SP-211031. CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211032 (CR PACK) Stage 1 CRs on eCPSOR_CON. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0559R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211033 (CR PACK) Stage 1 CRs on MSGin5G. (Source: SA WG1).
Document for: Approval.
Abstract: 22.262 CR0001R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211034 (CR PACK) Stage 1 CRs on EAV. (Source: SA WG1).
Document for: Approval.
Abstract: 22.125 CR0036R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211036 (CR PACK) Stage 1 CRs on MONASTERY2. (Source: SA WG1).
Document for: Approval.
Abstract: 22.280 CR0147.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211038 (CR PACK) Stage 1 CRs on eCAV. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0578; 22.261 CR0541R1; 22.104 CR0076R1; 22.104 CR0077R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

17.2 SA WG2 Rel-17 CRs

TD SP-211005 (CR) 23.401 CR3646R1 (Rel-17, 'F'): UE indication of support for Paging Timing Collision Control. (Source: Intel, Nokia, Qualcomm Incorporated).
Document for: Approval.
Abstract: The CR in S2-2105496r02 was not agreed due to unclear concerns that were raised for the first time only after revision deadline. Given that this CR clarifies a contradiction in the stage 2 text that has consequences on stage 3, it is proposed to approve the CR. There are no changes in the CR content.

Comment:

Revision of (Postponed) S2-2105496. CC#4: _rev4 approved. Revised to SP-211130.

Discussion and conclusion:

CC#2: Revision of (Postponed) S2-2105496. Intel proposed SP-211005_rev01. Huawei commented that there were ongoing discussions on this. This was left for further e-mail discussion.
CC#4: SP-211005_rev4 was approved (To be revised by MCC to a new TD number).

e-mail discussion:

Jianning (Xiaomi) provides the r01, based on what had discussed before the end of the SA2#146e
Saso (Intel) replies that this CR is already aligned with stage 3.
Alessio(nokia) support Intel
Lars (Sony) also support Intel
Jianning (Xiaomi) replies that the estimated PO/PF before Attach may be different from the allocated PO/PF after Attach, since some parameter(s) may depend on network feedback.
Alessio(Nokia) replies
Saso (Intel) reiterates that this CR is already aligned with stage 3.
Jianning (Xiaomi) replies that it is not right way to bring potential issue in order to align with other WGs.
Saso (Intel) replies to Jainning.
Haris (Qualcomm) comments and proposes to approve SP-211005
Jianning (Xiaomi) replies to Haris (Qualcomm)
Jianning (Xiaomi) replies to Saso (Intel)
Alessio (nokia) comments .
Jianning (Xiaomi) replies Alessio(Nokia) and propose to approve r01, and if needed minor alignment/clarification for stage 3.
Saso (Intel) replies to Jianning
Jianning (Xiaomi) replies to Saso (Intel) and Allesio (Nokia)
Alesio (Nokia) clarifies the problem withr01 which cannot be approved
Jianning (Xiaomi) replies to Alessio (Nokia) that CRr01 is the right way to go, which fix the potential issue coming from the CR that trying to introduce additional optimization but unfortunately with un-ignored negative impacts
Haris (Qualcomm) objects to r01 and proposes to agree the original version of the CR
Krisztian (Apple) supports Intel, Nokia and Qualcomm, objects to r01 and proposes to agree the original CR.
Jianning (Xiaomi) proposes r02 that leave it to UE implementaion to decide whether the UE brings IMSI offset value in the Attach.
Jianning (Xiaomi) proposes r02 that leave it to UE implementaion to decide whether the UE brings IMSI offset value in the Attach as well as for the TAU procedure.
Wanqiang(Huawei) is OK to go with r02, for the sake of progress.
Saso (MUSIM Rapporteur) replies to Jianning (Xiaomi); proposes to agree r00 and document Xiaomi's concerns in the meeting report.
Alessio (Nokia) supports Saso
Haris (Qualcomm) agrees with Saso and proposes to approve r0 (original version of the CR)
Andy (Samsung) agrees with previous comments and proposes to approve the original version of the CR, it is an alignment per CT1 the agreement.
Jianning (Xiaomi) replies to Saso (Intel) that r00 still has issue on the NOTEx for TAU procedure.
Saso (Intel) replies to Jianning (Xiaomi); provides rev3
Jianning (Xiaomi) provides r04 on top of r03 proposed by Saso (Intel), to fix the potential issue for TAU procedure.
Saso (Intel) is OK with r04.

Status:

Revised to SP-211130.

TD SP-211130 (CR) 23.401 CR3646R2 (Rel-17, 'F'): UE indication of support for Paging Timing Collision Control. (Source: Intel, Nokia, Qualcomm Incorporated).
Document for: Approval.
Abstract: Summary of change: Clause 4.3.33.1: Editorial fix: 'AMF' replaced with 'MME'. Clause 5.3.2.1: Clarify that the Requested Alternative IMSI Offset can be sent in Initial Attach as an exception to the general rule that UE shall use a MUSIM feature only after MME has indicated that it supports it.

Comment:

Revision of SP-211005_rev4. Approved.

Discussion and conclusion:

Approved.

Status:

Approved.

TD SP-211007 (CR) 23.502 CR2920R2 (Rel-17, 'F'): Exception #1: Enabling of paging reception for 5GS. (Source: Intel, MediaTek Inc., OPPO, Samsung, Orange, Ericsson, Apple, Charter Communications, LG Electronics, TelefÔnica, Deutsche Telekom).
Document for: Approval.
Abstract: The CR in S2-2106824 was technically endorsed in SA WG2#146E following a Show-of-Hands where 15 companies expressed support for the CR, while 2 companies were opposed to it. Given that this CR addresses one of the MUSIM exceptions approved in SA#92E, it is proposed to approve the CR in SA#93E. There are no changes in the CR content.

Comment:

Revision of (Technically Endorsed) S2-2106824. CC#4: _rev3 approved. Revised to SP-211131.

Discussion and conclusion:

CC#4: Sony commented that a 23.501 CR will be needed to document the solution on paging timing, which would not be Category F. Intel commented that in this case, this CR should also be Category B. It was agreed that a Category B CR to 23.501 will be allowed for the next TSG SA meeting. Nokia asked to add some text for the report on their concerns with this CR. Intel corrected the cover page and provided in SP-211007_rev3. SP-211007_rev3 was approved (To be revised by MCC to a new TD number).
Nokia asked for the following to be recorded:
Nokia has not sustained objection to this paper, but this should be remarked as an example, as outlined in SP-211035 'On MuSIM Paging collision Avoidance in 5GS', of how 3GPP is not always pursuing the most energy efficient and optimal solutions, which is the reason why we are now aiming to have TSG SA reach some standing agreement on pursuing EE in 3GPP specification efforts, like for other system-wide requirements that need to be met like security, Network sharing, roaming support etc. . Even, by agreeing CRs like this, the 5GS is less optimal in terms of enabling opportunities for EE than the EPS. Nokia encourages TSG SA to look into the issue of pursuing opportunities for EE more systematically going forward and especially ensure the latest 3GPP systems procedures can be at least as energy efficient as previous 3GPP systems.

e-mail discussion:

Xiaowan (vivo) provides comments and disagree the original version
Saso (intel) replies to Xiaowan (vivo)
Lars (Sony) makes a comment
Saso (Intel) replies to Lars (Sony)
Lars (Sony) responds to Saso (Intel), have not decided what we prefer.
Xiaowan(vivo) replies to Saso (intel) and provide company specific rev1
Alessio(nokia) retains objection to this CR and its revisions at this plenary. We should have more time to discuss in SA2.
Alessio(nokia) the problem with Rev1 is that this is not saying why the GUTI is requested. so it does not seem linked to the MUSIM feature at all. Also I am not sure we should allow UEs to randomly cause RRs for new GUTIs and should rather put some precise criterion on why a new GUTI could be requested. (in the interest of keeping the UE population well behaved and testable)
Saso (Intel) replies to Alessio(nokia).
Wanqiang (Huawei) is ok with the update provided by Xiaowan (vivo)
Ericsson asks why the condition applying 'to MuSIM UE' has been removed, haven't seen any justification or consequences, and would like to approve the original submission.
Krisztian (Apple) also prefers the original version. Rev1 allows any UEs to trigger new 5G-GUTI assignment anytime, while the original version has a precise condition specific to MUSIM mode. What's the motivation for rev1?
Andy (Samsung) agrees with previous comments that we should approve the original version.
Xiaowan (vivo) still disagrees the original version and provides rev2
Saso (Intel) is ok with rev2
Ericsson is ok with rev2
Saso (Intel) provides rev3 of the approved document to fix the cover page.

Status:

Revised to SP-211131.

TD SP-211131 (CR) 23.502 CR2920R3 (Rel-17, 'F'): Exception #1: Enabling of paging reception for 5GS. (Source: Intel, MediaTek Inc., OPPO, Samsung, Orange, Ericsson, Apple, Charter Communications, LG Electronics, TelefÔnica, Deutsche Telekom).
Document for: Approval.
Abstract: Summary of change: A new trigger is added to the triggers for initating a Mobility Registration procedure. This CR is based on S2-2104686r02.

Comment:

Revision of SP-211007_rev3. Approved.

Discussion and conclusion:

Approved.

Status:

Approved.

TD SP-211011 (DISCUSSION) On concerns with some eNS_Ph2 EPS interworking CRs. (Source: Nokia Nokia Shanghai Bell; Telecom Italia).
Document for: Discussion.
Abstract: On concerns with some eNS_Ph2 EPS interworking CRs.

Comment:

CC#4: This was noted.

Discussion and conclusion:

CC#2: Nokia propose noting S2-2106661 and S2-2106662 in CR Pack SP-210925. NEC disagreed that the CRs should not be approved as they add editor's note related to EPC which had been agreed to continue working on. Samsung supported the view of Nokia. Ericsson suggested the CRs are returned to SA WG2 for further discussion as there are issues which need to be addressed. ZTE suggested using the proposal in SP-211103 and adding an editor's note. Nokia commented that the quota could be enforced even when moving from EPS. The TSG SA Chair commented that more discussion was required on this and if no consensus can be reached the CRs will not be approved at this meeting. This was left for further e-mail discussion.
CC#4: This was noted.

e-mail discussion:

Iskren (NEC) disagrees with the proposal to not pursue with the SA2#146E agreed CRs in S2-2106661 <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_146E_Electronic_2021-08/Docs/S2-2106661.zip> and S2-2106662 <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_146E_Electronic_2021-08/Docs/S2-2106662.zip>
Alessio (Nokia) sustains the stance to not pursue with the SA2#146E agreed CRs in S2-2106661 <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_146E_Electronic_2021-08/Docs/S2-2106661.zip> and S2-2106662 <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_146E_Electronic_2021-08/Docs/S2-2106662.zip>
Iskren (NEC) answers Alessio (Nokia).
Matrixx with comment on quota management
Ericsson supports to continue approval of revision of S2-2106662 provided by NEC as well as approval of revision of S2-2106661 in SP 1013 (separate discussion) and provides comments.
Ashok (Samsung) provides comments
Iskren (NEC) answers Ashok (Samsung) and explains the service continuity issues
Ashok (Samsung) replies to Iskren (NEC)
Alessio(Nokia) unfortunately cannot modify the position these CRs are not approvable as they introduce a feature that has never been discussed (override of quota policy due to mobility from EPS) after the release is frozen. we cannot even find the stage one requirements for this. at the very least it should be reviewed by SA1, GSMA and SA5 (who are also working on quota management).
Iskren (NEC) disagrees with Alessio(Nokia) as the SA2 approved CRs in S2-2106661 and S2-2106662 are not a new feature and they address an EN and an issue that is part of the last SA plenary exceptions for further work (so, they could have been more than F type but they are not as the operator policy on quota is not standardized, rather facilitated by the standards so that if an operator wants to make use of it, they can. Also, the current standards already allow for the rejection based on reaching the quota unless the operator decides otherwise. So, there is no overriding the current agreements in the spec.

Status:

Noted.

TD SP-210925 (CR PACK) CRs to 23.501, 23.502: eNS_Ph2 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2883; 23.501 CR2995; 23.502 CR2943; 23.501 CR3232; 23.501 CR3058R1; 23.502 CR2950R1; 23.502 CR2963R1; 23.501 CR3220R1; 23.501 CR3074R1; 23.501 CR3077R1; 23.501 CR3201R1; 23.501 CR3066R1; 23.502 CR2909R1; 23.501 CR3072R1; 23.501 CR2994R1; 23.502 CR2884R1; 23.502 CR2887R1; 23.502 CR2888R1; 23.501 CR3004R1; 23.501 CR3067R1; 23.502 CR2964R1.

Comment:

Revision of 23.502 CR2950R1 proposed in SP-211104. CC#4: 23.502 CR2950R1 was postponed. 23.501 CR3058 was postponed. The remaining CRs in this CR Pack were approved. (This CR Pack was partially approved).

Discussion and conclusion:

CC#2: This was left for further e-mail discussion.
CC#4: 23.502 CR2950R1 was postponed. 23.501 CR3058 was postponed. The remaining CRs in this CR Pack were approved. (This CR Pack was partially approved).

Status:

Partially approved.

TD SP-211104 (CR) 23.502 CR2950R2 (Rel-17, 'F'): TS23.502 Correction to the NSAC to maintain service continuity. (Source: NEC).
Document for: Approval.
Abstract: Summary of change: It is suggested that the NSACF in 5GS is made aware of the UE handover from EPS to 5GS and based on the operator policy the NSACF may not reject the UE if the max number of registered UEs or the max number of established PDU Sessions for the network slice has been reached. 19/08/21, R02 - revised to align with the CR against TS23.501, i.e. the decision of NSACF to reject or not is based on the operator policy. SA#93E Plenary update - Removed the 'NSAC support in EPS' parameter from the AMF/SMF to the NSACF as NSACF may deduct itself that NSAC is not required in EPS if the UE is not found within the UEs registered with the network slice or within the UEs established PDU Session with the network slice.

Comment:

Revision of 23.502 CR2950R1 in CR Pack SP-210925. CC#4: Noted.

Discussion and conclusion:

CC#2: This was left for further e-mail discussion.
CC#4: Nokia commented that no revisions were fully agreed. NEC commented that this is still under discussion. The CR in the CR pack SP-210925 was postponed. This CR was noted.

e-mail discussion:

Iskren (NEC) provides a plenary revision for SA#146E agreed S2-2106662
Alessio (Nokia) strongly objects to this CR as it is not needed to make an exception just for the case of handover from EPS to 5GS.
Iskren (NEC) disagrees and answers Alessio (Nokia)
Alessio(nokia) comments and sustains objection
Iskren (NEC) replies to Alessio(Nokia) that addressing an EN on issue with service continuity is not a new feature.
Iskren (NEC) suggest we approve this CR (a simplified revision of SA2 approved S2-2106662) as it enables network operator's to tackle service continuity issue in EPS interworking (an Editor's Note in the current version of the SA2 spec and an identified issue in the SA plenary agreed exceptions to work for) based on the operator's policy.

Status:

Noted.

TD SP-210926 (CR PACK) CRs to 23.502, 23.503: eNS_Ph2 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.503 CR0626; 23.502 CR2973; 23.502 CR2999; 23.502 CR3090; 23.502 CR3091; 23.502 CR3000R1; 23.502 CR2976R1; 23.502 CR2970R1; 23.502 CR3094R1; 23.502 CR2977R1; 23.502 CR3026R1; 23.502 CR3071R1; 23.502 CR3072R1; 23.503 CR0608R1; 23.503 CR0629R1; 23.503 CR0633R1; 23.502 CR3084R1; 23.502 CR3056R1; 23.503 CR0622R1.

Comment:

CC#2: This CR PACK was approved.

Discussion and conclusion:

CC#2: This CR Pack was approved.

Status:

Approved.

TD SP-210893 (CR) 23.502 CR2981R2 (Rel-17, 'F'): ATSSS_update target access type during secondary reauth. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: The following changes is proposed: Apart from existing 3gpp and n3gpp, it is propsed that SMF can indicate as 'any' while sending the message to AMF. If AMF receives the target access type as 'any' then based on the operator policy it c.

Comment:

Revision of S2-2106580 in CR Pack SP-210938. Revised to SP-211012.

Discussion and conclusion:

-

Status:

Revised to SP-211012.

TD SP-211012 (CR) 23.502 CR2981R3 (Rel-17, 'F'): ATSSS_update target access type during secondary reauth. (Source: Samsung).
Document for: Approval.
Abstract: Summary of change: The following changes is proposed: Apart from existing 3gpp and n3gpp, it is propsed that SMF can indicate as 'any' while sending the message to AMF. If AMF receives the target access type as 'any' then based on the operator policy it can select one of the 3gpp or n3gpp access type to send the message to UE.

Comment:

Revision of SP-210893. Revision of S2-2106580 in CR Pack SP-210938. CC#2: This CR was approved.

Discussion and conclusion:

CC#2: This CR was approved.

e-mail discussion:

Marco (Huawei) asks clarification on motivation of this CR
Ashok (Samsung) provides clarification to Marco (Huawei).

Status:

Approved.

TD SP-211013 (CR) 23.501 CR3126R2 (Rel-17, 'B'): Resolve ENs in NSAC support for EPC interworking. (Source: Nokia, Nokia Shanghai Bell; Telecom Italia).
Document for: Approval.
Abstract: Summary of change: It is clarified that one NSACF can be in charge of registration and session admission control, or there are respective NSCAFs for registration and session admission control, depending on the deployement scenarios. Session continuity is not guaranteed if EPS counting is not performed. the revision at SA#93 removes the option that based on the operator's policy, the maximum number regarding the NSAC configured in the NSACF can be an independent limit for each 5GC and EPC.

Comment:

Revision of 23.501 CR3126R1 in SP-210938. CC#4: _rev2 approved. Revised to SP-211133.

Discussion and conclusion:

CC#2: This was left for further e-mail discussion.
CC#4: NEC preferred SP-211013_rev1 or could accept rev2 with the original note 2 is restored and the new added editor's note removed. Nokia did not agree that the editor's note on whether and how to add this was unacceptable, as it is still not decided whether to do it. Nokia commented that the editor's note would require an exception to continue working on it for Rel-17.
The TSG SA Chair held an informal show of hands:
Support for SP-211013_rev1 (resolved EN): 1
Support for SP-211013_rev2 (removes EN): 7
NEC then withdrew their objection. SP-211013_rev2 was then approved (To be revised by MCC to a new TD number).

e-mail discussion:

Iskren (NEC) proposes rev01 which is a merge with S2-2106661 <https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_146E_Electronic_2021-08/Docs/S2-2106661.zip> (in blue highlight) as both address the same clause in the spec.
alessio(Nokia) comments that this is not a NEC paper so they cannot provide revisions. the proposed revision, also, introduces text that is exactly what we do not like of S2-2106661 and S2-2106662 hence this is not acceptable.
Iskren (NEC) answers Nokia and explains why SP-211013 and baseline S2-2106841 are not acceptable without the solution in S2-2106661 and S2-2106662.
alessio(Nokia) provides rev2 based on comment received offline to remove the editor's note related to the new feature that we propose to remove for the SA-agreed CR.
Iskren (NEC) - current acceptable version is ver01 only.
Alessio(Nokia) comments rev1 is a rogue version injected by NEC taking over the source company role, so it cannot be even discussed.
Iskren (NEC) disagrees with Alessio(Nokia) and explains why.
Alessio(Nokia) clarifies for NEC that in SA plenary only the source to SA of a document can update the document, based on the rules. But regardless, rev1 provided by NEC is not acceptable.
Iskren (NEC) can not accept the initial version and rev2 off this CR as they do not address the Editor's note on service continuity which is also part of the last SA plenary agreed exceptions for further work.
Genadi (Lenovo) proposes to continue discussing the issue in SA2. The SA2 agreed solution to the specific EPC IWK may also apply to mobility withing 5GC.
Iskren (NEC) answers Genadi (Lenovo) that his use cases are rare racing conditions and can be addressed separately if required. They are not related to the Editor's Note that is about EPC interworking and is a subject to SA plenary exceptions.
alessio (nokia) reaffirms one more time this CR does address the Editor's note on service continuity (by taking the stance nothing special has to be done) .The issue with r1 by NEC is not procedural only, it is substantive. Also we complain NEC is trying to take over this CR to import the concept we do not agree with in the other CR set, this is not acceptable.
Iskren (NEC) answers Alessio (Nokia)- The other CR set is extensively discussed in SA2 approved. The problem is that Alessio is rejecting them with no valid reason. I do not thinks the 3GPP rules for right to object are meant to tolerate such behaviour.
Krisztian (Apple) proposes to approve SP-211013rev01and provides further comments.
Alessio(Nokia) cannot accept r01 and asks companies interested in the topic that is creating (in our opinion a non-preventable) backdoor to the quota enforcement to handle the topic in a separate thread and not hijack this CR
Iskren (NEC) answers that ver01 is the only acceptable version of this CR as only ver01 addresses with a solution the Editor's Note on service continuity which also is also a part of the SA plenary agreed exceptions. All other versions of this CR are not acceptable.
Alessio (nokia) comments that the CR was agreed in SA2 to remove the editor's note already so this CR was resolving the EN without the other CR by iskren being needed.
Alessio (nokia) comments r02 is only acceptable . if not we take this debate back to SA2.
Alessio (nokia) additionally comments that 'Editor's note: It is FFS whether and how to support session continuity if either the current number of UE registration or the current number of PDU sessions reaches the maximum number when the UE moves from EPC to 5GC.' means that if there is no agreement to support continuing sessions in face of quota constraints, then the decision is that on the 'whether' part there is not consensus to do this so really the editors note can be removed as in r02 with the statement there is no guaranteed the continuity happens when quota would be exceeded. So, we cannot agree the note implied an agreement a solution had to be provided allowing the continuity in the face of a policy to drop sessions over the quota as implied by Iskren who is plainly taking this CR hostage to continue the discussion. and also we believe there is no way our position will change so there is no point to keep this debate alive.
Iskren (NEC) proposes to agree rv01. Any other revision is unacceptable as they do not offer solution for service continuity issue. Alessio made it clear he is not just against the SA2 approved solution, he is also rejecting the SA2 agreed Editor's Note and SA plenary agreed exception to work on solving the service continuity issue. It is strange. It will stall us from working on solution at the next SA2 meeting. So, we better agree rev01 that offers a solution and discuss any further potential improvements at the next SA2 meeting.
Ericsson supports r02 as a way forward to make progress, rest of the discussion can be taken in SA2.
Jinguo(ZTE) supports r02 as a way forward to make progress
Ashok (Samsung) supports r02.

Status:

Revised to SP-211133.

TD SP-211133 (CR) 23.501 CR3126R3 (Rel-17, 'B'): Resolve ENs in NSAC support for EPC interworking. (Source: Nokia, NokiaShanghai Bell, Telecom Italia).
Document for: Approval.
Abstract: Summary of change: It is clarified that one NSACF can be in charge of registration and session admission control, or there are respective NSCAFs for registration and session admission control, depending on the deployement scenarios. Session continuity is not guaranteed if EPS counting is not performed. the revision at SA#93 removes the option that based on the operator's policy, the maximum number regarding the NSAC configured in the NSACF can be an independent limit for each 5GC and EPC.

Comment:

Revision of SP-211013_rev2. Approved.

Discussion and conclusion:

-

Status:

Approved.

TD SP-211015 (CR) 23.502 CR3045R2 (Rel-17, 'C'): Update NSAC for interworking. (Source: Nokia, Nokia Shanghai Bell; Telecom Italia).
Document for: Approval.
Abstract: Summary of change: New procedure of Network Slice Admission Control for EPC.

Comment:

Revision of 23.502 CR3045R1 in SP-210938. CC#2: This CR was approved.

Discussion and conclusion:

CC#2: This CR was approved.

Status:

Approved.

TD SP-211016 (CR) 23.501 CR3172R3 (Rel-17, 'F'): NSSAAF Discovery and Selection based on S-NSSAI or UE ID Range. (Source: Nokia, Nokia Shanghai Bell).
Document for: Approval.
Abstract: Summary of change: To add S-NSSAI, SUPI or Internal Group ID as the input factors for NSSAAF selection.

Comment:

Revision of 23.501 CR3172R2 in SP-210938. CC#2: Postponed.

Discussion and conclusion:

CC#2: Revision of 23.501 CR3172R2 in SP-210938. Nokia commented that the category of this was unclear and if a Cat C it should not be allowed as it introduces functionality after the Stage 2 freeze and if Cat F it should not be introducing an editor's note to add functionality. Ericsson commented that they had raised their concern that this is not a Cat F CR at SA WG2 and approving this CR without the editor's note is not acceptable, as this will need to be addressed by SA WG2 in the next Quarter and could only accept it with an editor's note. The TSG SA Chair commented that as long as the CR has consensus, an editor's note can be included in a Cat F CR. Nokia suggested that if it is known that more work is needed then it would be better to further discuss this in SA WG2 to provide a complete change for the next TSG SA meeting. This CR was then postponed.

e-mail discussion:

Ericsson provides revision in Drafts folder and also asks to change the Category of the CR from F to C, provides comments.
alessio(Nokia) agrees that Ericsson has identified a good issue with the CR and wonders whether the CR can be approved if this is a category C and not category F as rel-16 and rel17 were both frozen.
Ericsson does not object to the approval of the CR revision provided by Ericsson, independent of whether to correctly mark it as Cat C or leave it as Cat F, further work is needed and SA2 has many ENs to address still for Rel-17, comments.
Alessio(Nokia) believes we cannot agree category C CRs without a matching WID. So this CR cannot be approved as a category C. Furthermore, adding an editor's note is not acceptable if it is a category F CRs as this would mean the FASMO CR (which is the only category that can stand now without a WID) creates a FAMSO issue where there was none. all in all based on Ericsson technical comments we cannot proceed with this CR.

Status:

Postponed.

TD SP-211081 (CR) 23.502 CR3035R2 (Rel-17, 'F'): Update UE subscription to contain information indicating authentication towards AAA server. (Source: Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, Ericsson).
Document for: Approval.
Abstract: Update UE subscription to contain information indicating authentication towards AAA server.

Comment:

Revision of 22.502 CR3035R1 in CR Pack SP-210938. CC#2: This CR was approved.

Discussion and conclusion:

CC#2: Revision of 22.502 CR3035R1 in CR Pack SP-210938. This CR was approved.

Status:

Approved.

TD SP-210938 (CR PACK) CRs where alternative proposals are expected at TSG SA#93-e:. (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2981R1; 23.501 CR3172R2; 23.502 CR3035R1; 23.501 CR3126R1; 23.502 CR3045R1.

Comment:

23.502 CR2981R1 revised. 23.501 CR3172R2 postponed. 23.502 CR3045R1 revised. 22.502 CR3035R1 revised. 23.501 CR3126R1 revised. This CR pack was then noted.

Discussion and conclusion:

Revision of 23.502 CR2981R1 proposed in SP-211012. Revision of 23.501 CR3172R2 proposed in SP-211016. Revision of 23.502 CR3035R1 proposed in SP-211081. Revision of 23.501 CR3126R1 proposed in SP-211013. Revision of 23.502 CR3045R1 proposed in SP-211015.
23.502 CR2981R1 was considered as revised.
23.501 CR3172R2 was postponed.
23.502 CR3045R1 was considered as revised.
22.502 CR3035R1 was considered as revised.
23.501 CR3126R1 was still under discussion.
This was left for further e-mail discussion
CC#4: 23.501 CR3126R1 was considered as revised. This CR pack was then noted.

Status:

Noted.

TD SP-210915 (CR PACK) CRs to 23.501, 23.502: TEI17 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2886; 23.502 CR2947; 23.502 CR3019; 23.501 CR3222; 23.501 CR3170R1; 23.502 CR3069R1; 23.501 CR2993R1; 23.502 CR2882R1; 23.501 CR3054R1; 23.501 CR3213R1; 23.502 CR3110R1; 23.501 CR3230R1; 23.502 CR2858R2; 23.501 CR3044R1; 23.502 CR2948R1.

Comment:

Huawei raised issues with 23.502 CR2948R1. Removed from Block approval. CC#4: Huawei withdrew their issue with a CR and this CR Pack was approved.

Discussion and conclusion:

CC#2: Huawei raised issues with 23.502 CR2948R1. Removed from Block approval. Huawei clarified that it makes little sense to approve this CR as it will need to be removed when the feedback is received from CT WG1. Ericsson disagreed as it is SA WG2 responsibility to approve the Stage 2 in order to allow Stage 3 to work on it and they can then return to SA WG2 if they have issues with the Stage 2 and also that it appears that only Huawei have issues in CT WG1 on this which lead to the Stage 3 CR being postponed. Qualcomm commented that they should provide their technical concerns on the Stage 2 CR. Nokia commented that there were no concerns raised at the SA WG2 meeting from Huawei on the CR. AT&T also considered this CR should be approved. Nokia commented that there are no technical concerns raised and only that the Stage 3 CR has been postponed. This was left for further e-mail discussion.
CC#4: Huawei withdrew their issue with a CR and this CR Pack was approved.

e-mail discussion:

Huawei requests CR2948r1 on TS23.502 to be removed from the pack, and to be marked as postponed.
Ericsson comments that SA should approve the SA2 CRs and let CT1 provide any further comments, if they have any, officially, such as LS, for SA2 to consider.
Nokia share the views from Ericsson and support approval of the SA2 CR2948r1 on TS23.502. We have not seen any message from CT1 that could hint to any issue with this SA2 CR.
Huawei answers the comments from Nokia and Ericsson, and proposes to ask their CT1 colleagues to forward them the outcome of the CT1 tdoc status.
Nokia support approval of the SA2 CR2948r1 on TS23.502, and suggest that discussion in SA focuses on potential issues with the CR instead of speculating about what CT1 could do about the related stage 2 requirements in the future.
Huawei confirms the request to postpone the CR.
Ericsson asks to approve the CR as Huawei has provided no technical reason for stage 2 lead work to be not approved and requests that they make no assumption on inter company delegation communication.
Huawei clarifies further.
AT&T agrees with E/// and Nokia and asks for approval of the CR. CT working groups discussion will happen on their timeline and adjustment to stage 2 based on stage 3 input will also happen as needed. This is business as usual and nothing new and no reason to withhold approval.
Haris (Qualcomm) asks Huawei to indicate what are the technical concerns and provide references to CT1 papers that are not related to this specific CR but with CRs already approved by SA#92 and implemented in stage-2 specs
Huawei accepts the commitment mentioned by Qualcomm to resolve this issue in next quarter in CT1 and CT4. If any changes are required to SA2 specifications, CT WGs should inform SA2 in time, so that SA2 specifications can be updated accordingly before December plenary. With this disposition, Huawei is willing to let this CR be approved in this plenary.

Status:

Approved.

Block 4 (to approve Thursday 15:00 UTC)

TD SP-210913 (CR PACK) CRs to 23.032, 23.273, 23.502: 5G_eLCS_Ph2 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR3053; 23.032 CR0019R1; 23.273 CR0185R1; 23.273 CR0186R1; 23.273 CR0192R1; 23.273 CR0147R4; 23.273 CR0187R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210914 (CR PACK) CRs to 23.501, 23.503: 5G_ProSe (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3034R1; 23.503 CR0623R1; 23.503 CR0631R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210916 (CR PACK) CRs to 23.501, 23.502, 23.503: 5GSAT_ARCH (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2875R1; 23.501 CR2748R3; 23.501 CR3029R1; 23.503 CR0618R1; 23.501 CR3199R1; 23.501 CR3119R1.

Comment:

CC#2: This CR PACK was approved.

Discussion and conclusion:

CC#2: This CR PACK was approved.

Status:

Approved.

TD SP-210917 (CR PACK) CRs to 23.501, 23.502: 5MBS (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3091; 23.502 CR2878R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210918 (CR PACK) CRs to 23.501, 23.503: ATSSS_Ph2 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3114; 23.503 CR0642; 23.501 CR3027R1; 23.501 CR3111R1; 23.501 CR3116R1; 23.501 CR3179R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210919 (CR PACK) CRs to 23.501, 23.502: BEPoP (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3010R1; 23.502 CR2931R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210920 (CR PACK) CRs to 23.501, 23.502, 23.503: eEDGE_5GC (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3026; 23.502 CR2928; 23.502 CR2929; 23.502 CR3043; 23.502 CR3077; 23.501 CR3186; 23.501 CR3187; 23.502 CR2968R1; 23.502 CR3078R1; 23.501 CR3025R1; 23.502 CR2927R1; 23.503 CR0611R1; 23.503 CR0617R1; 23.501 CR3124R1; 23.502 CR3025R1; 23.502 CR3113R1; 23.502 CR3024R1; 23.503 CR0638R1; 23.502 CR3040R1; 23.501 CR3149R1; 23.502 CR3079R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210921 (CR PACK) CRs to 23.288: eNA_Ph2 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.288 CR0378; 23.288 CR0390; 23.288 CR0393; 23.288 CR0395; 23.288 CR0400; 23.288 CR0412; 23.288 CR0409R1; 23.288 CR0414R1; 23.288 CR0417R1; 23.288 CR0406R1; 23.288 CR0389R1; 23.288 CR0394R1; 23.288 CR0377R1; 23.288 CR0379R1; 23.288 CR0411R1; 23.288 CR0396R1; 23.288 CR0383R1; 23.288 CR0384R1; 23.288 CR0385R1; 23.288 CR0386R1; 23.288 CR0387R1; 23.288 CR0388R1; 23.288 CR0382R1; 23.288 CR0410R1; 23.288 CR0421R1; 23.288 CR0401R1; 23.288 CR0404R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210922 (CR PACK) CRs to 23.288, 23.501, 23.502, 23.503: eNA_Ph2 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2910; 23.503 CR0609; 23.502 CR2954; 23.501 CR3079; 23.502 CR2978; 23.502 CR2979; 23.288 CR0424; 23.288 CR0433; 23.288 CR0428R1; 23.288 CR0429R1; 23.288 CR0431R1; 23.501 CR3101R1; 23.502 CR2955R1; 23.288 CR0407R1; 23.501 CR3001R1; 23.501 CR3002R1; 23.502 CR2901R1; 23.502 CR2911R1; 23.288 CR0427R2; 23.288 CR0432R1; 23.288 CR0426R1; 23.502 CR3051R1; 23.288 CR0381R1; 23.502 CR2998R1; 23.288 CR0434R1; 23.288 CR0430R2; 23.502 CR3122.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210923 (CR PACK) CRs to 23.228, 23.501: eNPN (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3084; 23.501 CR3085; 23.501 CR3095; 23.501 CR3098; 23.501 CR3136; 23.501 CR3139; 23.501 CR3165; 23.501 CR2919R2; 23.501 CR2999R1; 23.501 CR3036R1; 23.501 CR3045R1; 23.501 CR3173R1; 23.501 CR3175R1; 23.501 CR3052R1; 23.228 CR1245R1; 23.228 CR1246R1; 23.501 CR3049R1; 23.501 CR3137R1; 23.501 CR3146R1; 23.501 CR3097R1; 23.501 CR2921R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210924 (CR PACK) CRs to 23.502: eNPN (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2982R1; 23.502 CR3070R1; 23.502 CR2889R1; 23.502 CR2994R1; 23.502 CR3033R1; 23.502 CR2995R1; 23.502 CR2801R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210927 (CR PACK) CRs to 23.287: eV2XARC_Ph2 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.287 CR0161; 23.287 CR0162; 23.287 CR0158R1; 23.287 CR0163R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210928 (CR PACK) CRs to 23.501, 23.502: ID_UAS (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2916; 23.502 CR2917; 23.502 CR2952; 23.502 CR2915R1; 23.502 CR2918R1; 23.501 CR3018R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210929 (CR PACK) CRs to 23.501: IIoT (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3112; 23.501 CR3142; 23.501 CR3143; 23.501 CR3040R1; 23.501 CR3038R1; 23.501 CR3041R1; 23.501 CR3144R1; 23.501 CR3051R1; 23.501 CR3162R1; 23.501 CR3039R1; 23.501 CR3042R1; 23.501 CR3150R1; 23.501 CR3160R1; 23.501 CR3161R1; 23.501 CR3189R1; 23.501 CR3198R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210930 (CR PACK) CRs to 23.502, 23.503: IIoT (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2924; 23.502 CR2962; 23.502 CR3096; 23.503 CR0615R1; 23.502 CR2925R1; 23.502 CR2935R1; 23.502 CR2936R1; 23.502 CR2965R1; 23.503 CR0625R1; 23.503 CR0640R1; 23.503 CR0641R1; 23.502 CR3048R1; 23.502 CR3073R1; 23.502 CR3081R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210931 (CR PACK) CRs to 23.501, 23.502: MINT (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3019R1; 23.502 CR2990R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210932 (CR PACK) CRs to 23.272, 23.401, 23.501, 23.502: MUSIM (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.401 CR3647; 23.501 CR3048; 23.502 CR2953; 23.401 CR3650; 23.502 CR3017; 23.501 CR3196; 23.401 CR3654; 23.501 CR3228; 23.502 CR3111; 23.272 CR0974; 23.501 CR3088R1; 23.502 CR2921R1; 23.502 CR3088R1; 23.502 CR2988R1; 23.401 CR3652R1; 23.501 CR3192R1; 23.401 CR3649R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210933 (CR PACK) CRs to 23.501: NR_redcap (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.501 CR3209R1; 23.501 CR3155R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210934 (CR PACK) CRs to 23.501, 23.502, 23.682: RDSSI (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.682 CR0480; 23.501 CR3008; 23.502 CR2897.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210935 (CR PACK) CRs to 23.401, 23.501: UPIP_SEC_LTE (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.401 CR3645R1; 23.501 CR3009R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210936 (CR PACK) CRs to 23.401, 23.501, 23.502, 23.503: TEI17 (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.167 CR0365; 23.501 CR3064; 23.502 CR2987; 23.401 CR3648R1; 23.503 CR0607R1; 23.502 CR2959R1; 23.502 CR2958R1; 23.503 CR0619R1; 23.503 CR0632R1; 23.502 CR2957R1; 23.501 CR3062R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210937 (CR PACK) CRs to23.501, 23.502, 23.503, 23.682: TEI17_<Mini-WIDs> (Rel-17). (Source: SA WG2).
Document for: Approval.
Abstract: 23.502 CR2900; 23.501 CR3011; 23.502 CR2902; 23.501 CR3043; 23.502 CR2961; 23.501 CR3108; 23.682 CR0483; 23.502 CR3106; 23.501 CR3035R1; 23.503 CR0620R1; 23.502 CR2903R1; 23.503 CR0621R1; 23.502 CR2904R1; 23.503 CR0606R1; 23.502 CR2905R1; 23.501 CR3065R1; 23.502 CR2960R1; 23.502 CR3012R1; 23.502 CR3018R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

17.3 SA WG3 and SA WG3 LI Rel-17 CRs

Block 4 (to approve Thursday 15:00 UTC)

TD SP-210829 (CR PACK) Rel-17 CRs on Lawful Interception. (Source: SA WG3-LI).
Document for: Approval.
Abstract: 33.128 CR0217; 33.128 CR0219; 33.127 CR0139; 33.128 CR0222; 33.127 CR0140R1; 33.127 CR0141R1; 33.127 CR0142R1; 33.127 CR0144R1; 33.127 CR0145R1; 33.127 CR0146R1; 33.128 CR0224R1; 33.128 CR0226R1; 33.128 CR0218R1; 33.128 CR0221R1; 33.128 CR0228R1; 33.128 CR0232R1; 33.127 CR0148; 33.128 CR0220R2; 33.127 CR0135R4; 33.127 CR0136R5; 33.128 CR0234R1; 33.128 CR0239R1; 33.128 CR0240R1; 33.128 CR0241R1; 33.128 CR0243R1; 33.128 CR0244R1; 33.128 CR0246R1; 33.128 CR0247R1; 33.128 CR0248R1; 33.128 CR0250R1; 33.128 CR0251R1; 33.128 CR0253R1; 33.128 CR0235R1; 33.128 CR0242R1; 33.128 CR0245R1; 33.128 CR0249R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210841 (CR PACK) Rel-17 CRs on AKMA TLS protocol profiles. (Source: SA WG3).
Document for: Approval.
Abstract: 33.535 CR0090R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210842 (CR PACK) Rel-17 CRs on SA WG3 aspects of AKMA. (Source: SA WG3).
Document for: Approval.
Abstract: 33.501 CR1151; 33.535 CR0088; 33.535 CR0093R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210843 (CR PACK) Rel-17 CRs on Enhancements of 3GPP profiles for cryptographic algorithms and security protocols. (Source: SA WG3).
Document for: Approval.
Abstract: 33.310 CR0120.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210844 (CR PACK) Rel-17 CRs on Security Assurance Specification for 5G (eSCAS_5G). (Source: SA WG3).
Document for: Approval.
Abstract: 33.512 CR0013.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

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

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210846 (CR PACK) Rel-17 CRs on Study on SECAM and SCAS for 3GPP virtualized network products. (Source: SA WG3).
Document for: Approval.
Abstract: 33.818 CR0001.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210847 (CR PACK) Rel-17 CRs on eSCAS_5G for Network Slice-Specific Authentication and Authorization Function (NSSAAF). (Source: SA WG3).
Document for: Approval.
Abstract: 33.926 CR0046R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210848 (CR PACK) Rel-17 CRs on eSCAS_5Gfor Inter PLMN UP Security. (Source: SA WG3).
Document for: Approval.
Abstract: 33.926 CR0048; 33.513 CR0005.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210852 (CR PACK) Rel-17 CRs on TEI. (Source: SA WG3).
Document for: Approval.
Abstract: 33.501 CR1168; 33.501 CR1174R1; 33.501 CR1182R1; 33.501 CR1158R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210897 (CR PACK) Rel-17 CRs on Study on the security of the system enablers for devices having multiple Universal Subscriber Identity Modules (USIM). (Source: SA WG3).
Document for: Approval.
Abstract: 33.873 CR0001; 33.873 CR0002.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210898 (CR PACK) Rel-17 CRs on eSCAS_5G for 5G NWDAF. (Source: SA WG3).
Document for: Approval.
Abstract: 33.521 CR0002R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

17.4 SA WG4 Rel-17 CRs

Block 4 (to approve Thursday 15:00 UTC)

TD SP-210820 (CR PACK) CR Pack on Typical Traffic Characteristics (26.925). (Source: SA WG4).
Document for: Approval.
Abstract: 26.925 CR0001R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210823 (CR PACK) CR Pack on Correction of missing figure for WB frequency mask in receiving (26.131). (Source: SA WG4).
Document for: Approval.
Abstract: 26.131 CR0082R3.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

17.5 SA WG5 Rel-17 CRs

TD SP-210990 (CR) 32.291 CR0343R1 (Rel-17, 'F'): Rel-17 CR 32.291 Update OpenAPI version. (Source: Huawei).
Document for: Approval.
Abstract: Summary of change: For converged Charging Service: - Nchf_ ConvergedCharging Service version number is incremented from '3.0.3' to '3.1.0-alpha.1' - TS 32.291 version number is incremented from '16.8.1' to '17.0.0'.

Comment:

Revision of S5-214710 in CR Pack SP-210887. CC#2: This CR was approved.

Discussion and conclusion:

CC#2: Revision of S5-214710 in CR Pack SP-210887. Huawei commented that this was an alignment of coding where inconsistences were discovered in ETSI Forge. This CR was approved.

Status:

Approved.

TD SP-210887 (CR PACK) Rel-17 CRs on TEI. (Source: SA WG5).
Document for: Approval.
Abstract: 32.299 CR0824; 32.298 CR0872; 32.160 CR0022; 28.541 CR0551; 32.160 CR0023; 32.291 CR0339R1; 32.291 CR0343.

Comment:

Revision of 32.291 CR0343R1 proposed in SP-210990. CC#2: 32.291 CR0343R1 was considered revised. The remaining CRs in this CR Pack were approved.

Discussion and conclusion:

Revision of 32.291 CR0343R1 proposed in SP-210990. 32.291 CR0343R1 was considered revised. The remaining CRs in this CR Pack were approved. (This CR Pack was partially approved).

Status:

Partially approved.

Block 4 (to approve Thursday 15:00 UTC)

TD SP-210863 (CR PACK) Rel-17 CRs on Charging enhancement for URLLC. (Source: SA WG5).
Document for: Approval.
Abstract: 32.255 CR0319R1; 32.255 CR0321R1; 32.291 CR0341; 32.298 CR0876.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210864 (CR PACK) Rel-17 CRS on Discovery of management services in 5G. (Source: SA WG5).
Document for: Approval.
Abstract: 28.533 CR0086; 28.537 CR0004R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210866 (CR PACK) Rel-17 CRs on IMS Charging in 5G System Architecture. (Source: SA WG5).
Document for: Approval.
Abstract: 32.291 CR0340R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210867 (CR PACK) Rel-17 CRs on Additional NRM features. (Source: SA WG5).
Document for: Approval.
Abstract: 28.541 CR0528; 28.541 CR0564; 28.541 CR0568; 28.541 CR0566R1; 28.623 CR0137R1; 28.541 CR0554R1; 28.541 CR0562R1; 28.541 CR0526R1; 28.541 CR0527R1; 28.541 CR0535R1; 28.541 CR0549R1; 28.541 CR0559R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210868 (CR PACK) Rel-17 CRs on enhancements of Closed loop SLS Assurance. (Source: SA WG5).
Document for: Approval.
Abstract: 28.535 CR0053R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210869 (CR PACK) Rel-17 CRs on Enhancements on EE for 5G networks. (Source: SA WG5).
Document for: Approval.
Abstract: 28.554 CR0082; 28.310 CR0017R1; 28.554 CR0083R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210870 (CR PACK) Rel-17 CRs on Enhancement on Management Aspects of 5G Service-Level Agreement. (Source: SA WG5).
Document for: Approval.
Abstract: 28.541 CR0525; 28.541 CR0542; 28.541 CR0543; 28.541 CR0520R1; 28.541 CR0539R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210872 (CR PACK) Rel-17 CRs on Enhancements of 5G performance measurements and KPIs. (Source: SA WG5).
Document for: Approval.
Abstract: 28.552 CR0312; 28.554 CR0084; 28.554 CR0085; 28.552 CR0311R1; 28.552 CR0313R1; 28.552 CR0315R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210873 (CR PACK) Rel-17 CRs on Enhancement of QoE Measurement Collection. (Source: SA WG5).
Document for: Approval.
Abstract: 28.404 CR0005R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210874 (CR PACK) Rel-17 CRs on Enhancements of Self-Organizing Networks (SON) for 5G networks. (Source: SA WG5).
Document for: Approval.
Abstract: 28.552 CR0309; 28.313 CR0026R1; 28.552 CR0308R1; 28.313 CR0017R3; 28.313 CR0027R1; 28.313 CR0028R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210875 (CR PACK) Rel-17 CRs on File Management. (Source: SA WG5).
Document for: Approval.
Abstract: 28.537 CR0006.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210876 (CR PACK) Rel-17 CRs on Management data collection control and discovery. (Source: SA WG5).
Document for: Approval.
Abstract: 28.537 CR0005.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210877 (CR PACK) Rel-17 CRs on Management Aspects of 5G Network Sharing. (Source: SA WG5).
Document for: Approval.
Abstract: 32.130 CR0014R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210882 (CR PACK) Rel-17 CRs on Management of non-public networks (NPN). (Source: SA WG5).
Document for: Approval.
Abstract: 28.541 CR0531R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210888 (CR PACK) Rel-17 CRs on SA WG5 aspects of N40 Interface Enhancements to Support GERAN and UTRAN. (Source: SA WG5).
Document for: Approval.
Abstract: 32.291 CR0332R1; 32.298 CR0874R1; 32.255 CR0322R1; 32.290 CR0165R1; 32.298 CR0875R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210895 (CR PACK) Rel-17 CRs on inclusive language review. (Source: SA WG5).
Document for: Approval.
Abstract: 32.250 CR0049; 32.272 CR0039; 32.295 CR0014; 32.298 CR0873; 32.299 CR0825.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

17.6 SA WG6 Rel-17 CRs

Block 4 (to approve Thursday 15:00 UTC)

TD SP-210961 (CR PACK) Rel-17 CRs to TS23558 for EDGEAPP. (Source: SA WG6).
Document for: Approval.
Abstract: 23.558 CR0001; 23.558 CR0007; 23.558 CR0009; 23.558 CR0010; 23.558 CR0012; 23.558 CR0019; 23.558 CR0020; 23.558 CR0011R1; 23.558 CR0004R1; 23.558 CR0017R1; 23.558 CR0006R2; 23.558 CR0003R2; 23.558 CR0034; 23.558 CR0041; 23.558 CR0024R1; 23.558 CR0008R4; 23.558 CR0033R1; 23.558 CR0039R1; 23.558 CR0040R1; 23.558 CR0044R1; 23.558 CR0026R2; 23.558 CR0027R2; 23.558 CR0036R2; 23.558 CR0030R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210962 (CR PACK) Rel-17 CRs to TS23282 for eMCData3. (Source: SA WG6).
Document for: Approval.
Abstract: 23.282 CR0281; 23.282 CR0282; 23.282 CR0283; 23.282 CR0285R1; 23.282 CR0284R1; 23.282 CR0286R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210963 (CR PACK) Rel-17 CRs to TS23280 and TS23379 for enh3MCPTT. (Source: SA WG6).
Document for: Approval.
Abstract: 23.280 CR0295R1; 23.379 CR0296R1; 23.280 CR0293R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210964 (CR PACK) Rel-17 CRs to TS23434 for eSEAL. (Source: SA WG6).
Document for: Approval.
Abstract: 23.434 CR0076R2; 23.434 CR0075R2; 23.434 CR0080R1; 23.434 CR0081R1; 23.434 CR0079R2; 23.434 CR0078R5.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210965 (CR PACK) Rel-17 CRs to TS23286 for eV2XAPP. (Source: SA WG6).
Document for: Approval.
Abstract: 23.286 CR0067; 23.286 CR0068; 23.286 CR0069R1; 23.286 CR0066R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-210966 (CR PACK) Rel-17 CRs to TS23255 for UASAPP. (Source: SA WG6).
Document for: Approval.
Abstract: 23.255 CR0007; 23.255 CR0003R1; 23.255 CR0004R1; 23.255 CR0005R1; 23.255 CR0006R1; 23.255 CR0008; 23.255 CR0009; 23.255 CR0010; 23.255 CR0011; 23.255 CR0015; 23.255 CR0012R1; 23.255 CR0013R1; 23.255 CR0014R1; 23.255 CR0016R1; 23.255 CR0017R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

18 Rel-18 CRs

18.1 SA WG1 Rel-18 CRs

TD SP-211074 (CR) 22.280 CR0148R2 (Rel-18, 'B'): Ad hoc group call requirements. (Source: FirstNet, Samsung, Ericsson, Kontron Transportation France, UIC).
Document for: Approval.
Abstract: A requirement was added that lacks change marks in the agreed revision in SA1. This CR restores the change marks so the CR will be implemented properly. The annexes A, B and C are updated with the change.

Comment:

Revision of 22.280 CR0148R1 in CR Pack SP-211073. CC#2: This CR was approved.

Discussion and conclusion:

CC#2: Revision of 22.280 CR0148R1 in CR Pack SP-211073. This CR was approved.

Status:

Approved.

TD SP-211073 (CR PACK) Stage 1 CRS on AHGC. (Source: SA WG1).
Document for: Approval.
Abstract: 22.280 CR0148R1.

Comment:

Revision of 22.280 CR0148R1 proposed in SP-211074. CC#2: 22.280 CR0148R1 was considered revised. This CR Pack was noted.

Discussion and conclusion:

CC#2: Revision of 22.280 CR0148R1 proposed in SP-211074. 22.280 CR0148R1 was considered revised. This CR Pack was noted.

Status:

Noted.

Block 4 (to approve Thursday 15:00 UTC)

TD SP-211039 (CR PACK) Stage 1 CRs on TEI18. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0558R1; 22.104 CR0084R1; 22.261 CR0518R3; 22.261 CR0564R1; 22.261 CR0546R1; 22.153 CR0050R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211060 (CR PACK) Stage 1 CRs on eMMTEL. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0549R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211061 (CR PACK) Stage 1 CRs on SACI_MCS. (Source: SA WG1).
Document for: Approval.
Abstract: 22.280 CR0146R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211062 (CR PACK) Stage 1 CRs for AMMT. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0551R1; 22.261 CR0552R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211063 (CR PACK) Stage 1 CRS on Pirates. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0534; 22.261 CR0533R1; 22.261 CR0535R1; 22.261 CR0536R1; 22.261 CR0539R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211064 (CR PACK) Stage 1 CRs on PALS. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0560R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211066 (CR PACK) Stage 1 CRS on VMR. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0568R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211068 (CR PACK) Stage 1 CRS on SENSE. (Source: SA WG1).
Document for: Approval.
Abstract: 22.011 CR0322R4.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211069 (CR PACK) Stage 1 CRS on SCVS. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0519R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211070 (CR PACK) Stage 1 CRS on SEI. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0565; 22.104 CR0078R1; 22.104 CR0087R1; 22.104 CR0080R1; 22.104 CR0082R1; 22.104 CR0083R1; 22.261 CR0550R1; 22.261 CR0547R1; 22.261 CR0577R2.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211071 (CR PACK) Stage 1 CRS on EXPOSE. (Source: SA WG1).
Document for: Approval.
Abstract: 22.261 CR0542R1; 22.261 CR0543R1; 22.261 CR0544R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211072 (CR PACK) Stage 1 CRS on MPS_WLAN. (Source: SA WG1).
Document for: Approval.
Abstract: 22.153 CR0049R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

18.2 SA WG2 Rel-18 CRs

18.3 SA WG3 and SA WG3 LI Rel-18 CRs

18.4 SA WG4 Rel-18 CRs

18.5 SA WG5 Rel-18 CRs

18.6 SA WG6 Rel-18 CRs

19 CR-s related to Study Items

Block 4 (to approve Thursday 15:00 UTC)

TD SP-211040 (CR PACK) Stage 1 CRs on FS_AMMT. (Source: SA WG1).
Document for: Approval.
Abstract: 22.874 CR0001R1; 22.874 CR0002R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211044 (CR PACK) Stage 1 CRs on FS_5GSEI. (Source: SA WG1).
Document for: Approval.
Abstract: 22.867 CR0012; 22.867 CR0013; 22.867 CR0015; 22.867 CR0002R1; 22.867 CR0003R1; 22.867 CR0004R1; 22.867 CR0005R1; 22.867 CR0006R1; 22.867 CR0007R3; 22.867 CR0014R1; 22.867 CR0011R1; 22.867 CR0001R1; 22.867 CR0008R1; 22.867 CR0009R1; 22.867 CR0010R1.

Comment:

Revised and CRs Reissued in SP-211097.

Discussion and conclusion:

-

Status:

Revised and CRs Reissued in SP-211097.

TD SP-211097 (CR PACK) Stage 1 CRs on FS_5GSEI. (Source: SA WG1).
Document for: Approval.
Abstract: 22.867 CR0012; 22.867 CR0013; 22.867 CR0015; 22.867 CR0002R1; 22.867 CR0003R1; 22.867 CR0004R1; 22.867 CR0005R1; 22.867 CR0006R1; 22.867 CR0007R3; 22.867 CR0014R1; 22.867 CR0011R1; 22.867 CR0001R1; 22.867 CR0008R1; 22.867 CR0009R1; 22.867 CR0010R1; 22.867 CR0016R1.

Comment:

Reissue of SP-211044. CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211045 (CR PACK) Stage 1 CRs on FS_Resident. (Source: SA WG1).
Document for: Approval.
Abstract: 22.858 CR0009; 22.858 CR0010; 22.858 CR0012; 22.858 CR0013; 22.858 CR0015; 22.858 CR0016; 22.858 CR0008R1; 22.858 CR0007R1; 22.858 CR0003R1; 22.858 CR0005R1; 22.858 CR0001R1; 22.858 CR0002R1; 22.858 CR0017R1; 22.858 CR0018R1; 22.858 CR0020R1; 22.858 CR0021R1; 22.858 CR0024R1; 22.858 CR0011R1; 22.858 CR0014R1; 22.858 CR0006R1.

Comment:

Revised and CRs Reissued in SP-211099.

Discussion and conclusion:

-

Status:

Revised and CRs Reissued in SP-211099.

TD SP-211099 (CR PACK) Stage 1 CRs on FS_Resident. (Source: SA WG1).
Document for: Approval.
Abstract: 22.858 CR0009; 22.858 CR0010; 22.858 CR0012; 22.858 CR0013; 22.858 CR0015; 22.858 CR0016; 22.858 CR0008R1; 22.858 CR0007R1; 22.858 CR0003R1; 22.858 CR0005R1; 22.858 CR0001R1; 22.858 CR0002R1; 22.858 CR0017R1; 22.858 CR0018R1; 22.858 CR0020R1; 22.858 CR0021R1; 22.858 CR0024R1; 22.858 CR0011R1; 22.858 CR0014R1; 22.858 CR0006R1; 22.858 CR0025R1.

Comment:

Reissue of SP-211045. CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211046 (CR PACK) Stage 1 CRs on FS_PIN. (Source: SA WG1).
Document for: Approval.
Abstract: 22.859 CR0004; 22.859 CR0008; 22.859 CR0002R1; 22.859 CR0001R1; 22.859 CR0003R1; 22.859 CR0007R1; 22.859 CR0009R1; 22.859 CR0012R1; 22.859 CR0013R1; 22.859 CR0005R1; 22.859 CR0017R1; 22.859 CR0018R1.

Comment:

22.859 CR0001R1 was revised at SA WG1 in 22.859 CR0001R3. Revised and CRs Reissued in SP-211098.

Discussion and conclusion:

-

Status:

revised at SA WG1 in 22.859 CR0001R3. Revised and CRs Reissued in SP-211098.

TD SP-211098 (CR PACK) Stage 1 CRs on FS_PIN. (Source: SA WG1).
Document for: Approval.
Abstract: 22.859 CR0004; 22.859 CR0008; 22.859 CR0002R1; 22.859 CR0003R1; 22.859 CR0007R1; 22.859 CR0009R1; 22.859 CR0012R1; 22.859 CR0013R1; 22.859 CR0005R1; 22.859 CR0001R3; 22.859 CR0017R1; 22.859 CR0018R1.

Comment:

Reissue of SP-211046. 22.859 CR0001R1 is withdrawn as replacement 22.859 CR0001R3 (in this CR Pack) was agreed in SA WG1. CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211047 (CR PACK) Stage 1 CRs on FS_PALS. (Source: SA WG1).
Document for: Approval.
Abstract: 22.844 CR0004; 22.844 CR0001R1; 22.844 CR0002R1; 22.844 CR0005R1; 22.844 CR0006R1; 22.844 CR0003R5; 22.844 CR0008R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

TD SP-211049 (CR PACK) CRs on FS_eFRMCS. (Source: SA WG1).
Document for: Approval.
Abstract: 22.989 CR0004R1; 22.989 CR0006R1.

Comment:

CC#3: Block Approved.

Discussion and conclusion:

CC#3: Block Approved.

Status:

Approved.

20 Project Management & TSG SA owned specifications

20.1 General project management issues

TD SP-211107 (LS IN) LS from TSG RAN: Draft LTI ANSWER TO LIAISON STATEMENT TO EXTERNAL ORGANISATIONS ON THE REVISION OF RECOMMENDATION ITU-R M.1801-2. (Source: TSG RAN (RP-212580)).
Document for: Action.
Abstract: For 3GPP review: Overall description: ITU-R Working Party 5A kindly invites external organizations to provide updated and/or new material, and any other relevant information, for the draft revision of Recommendation ITU R M.1801-2. Also, please indicate if any of the standards in Recommendation ITU-R M.1801-2 could be removed from the next revision should any of them have fallen into disuse. In RAN #92e, RAN ITU AH proposed that further consider a potential Reply LS to ITU-R WP5A, if an answer is needed and in case provide it to RAN#93e. Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by September 17, 2021. It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R is November 8th. 3GPP PCG#47e is asked to approve this document to allow Individual Members to submit it to ITU-R WP5A.

Comment:

For review and forwarding to PCG. CC#4: This LS was endorsed and will be forwarded to the PCG.

Discussion and conclusion:

CC#4: This LS was endorsed and will be forwarded to the PCG.

Status:

Endorsed.

TD SP-211108 (LS IN) LS from TSG RAN: DRAFT LTI on Liaison statement to External Organizations on the schedule for updating Recommendation ITU-R M.2012 to Revision 6. (Source: TSG RAN (RP-212538)).
Document for: Action.
Abstract: For 3GPP review: in: TSG SA feedback LS before: September 17, 2021 to: 3GPP PCG Overall description: ITU-R Working Party 5D (WP 5D) informed 3GPP on their schedule towards Revision 6 of Recommendation M.2012. Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by September 17, 2021. It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R is January 31st, 2022. Therefore, 3GPP PCG#47e is asked to approve and provide the approved version of the material to ATIS. The final version of the document will be submitted to ITU-R WP5D by ATIS on behalf of 3GPP OPs.

Comment:

For review and forwarding to PCG. CC#4: This LS was endorsed and will be forwarded to the PCG.

Discussion and conclusion:

CC#4: This LS was endorsed and will be forwarded to the PCG.

Status:

Endorsed.

TD SP-211109 (LS IN) LS from TSG RAN: DRAFT LTI on Liaison statement to External Organizations on the schedule for updating Recommendation ITU-R M.2150 to Revision -After Year 2021-. (Source: TSG RAN (RP-212576)).
Document for: Action.
Abstract: For 3GPP review: in: TSG SA feedback LS before: September 17, 2021 to: 3GPP PCG Overall description: ITU-R Working Party 5D (WP 5D) informed 3GPP on their schedule for updating Recommendation ITU-R M.2150 to Revision 'After Year 2021'. Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by September 17, 2021. It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R is January 31st, 2022. Therefore, 3GPP PCG#47e is asked to approve and provide the approved version of the material to ATIS. The final version of the document will be submitted to ITU-R WP5D by ATIS on behalf of 3GPP OPs.

Comment:

For review and forwarding to PCG. CC#4: This LS was endorsed and will be forwarded to the PCG.

Discussion and conclusion:

CC#4: This LS was endorsed and will be forwarded to the PCG.

Status:

Endorsed.

TD SP-211110 (LS IN) LS from TSG RAN: DRAFT LTI on 3GPP activities on 'Satellite IOT'. (Source: TSG RAN (RP-212578)).
Document for: Action.
Abstract: For 3GPP review: in: TSG SA feedback LS before: September 17, 2021 to: 3GPP PCG Overall description: WP4B requires information on 3GPP activities relevant to the topic of deployment scenarios and network architectures that are being considered to efficiently provide M2M/IoT applications over satellite systems. This document provides the 3GPP proposal, stating that 3GPP completed the Study Item, initiated a Work Item within the framework of Release 17 and provides the link to the TR 38.829 Study on Narrow-Band Internet of Things (NB-IoT ) / enhanced Machine Type Communication (eMTC ) support for Non-Terrestrial Networks (NTN ) Actions: TSG RAN asks TSG SA to review this document and provide feedbacks to the PCG, by September 17, 2021. It is reminded that before final submission to ITU-R, in footnote 1 of this document, the source PCG doc number has to be updated as soon as it is available. The submission deadline for the submission of the material to ITU-R is October 18th, before PCG#47e. Therefore, 3GPP PCG#47e is asked to approve this document by correspondence by October 11th. The final version of the document will be submitted to ITU-R WP4B by 3GPP Individual Members on behalf of TSG RAN.

Comment:

For review and forwarding to PCG. CC#4: This LS was endorsed and will be forwarded to the PCG.

Discussion and conclusion:

CC#4: This LS was endorsed and will be forwarded to the PCG.

Status:

Endorsed.

TD SP-211111 (LS IN) LS from TSG RAN: LS on how to handle satellite specific specifications in future submissions to ITU related to terrestrial-only technologies. (Source: TSG RAN (RP-212537)).
Document for: Action.
Abstract: TSG RAN#93e endorsed the following principle on how to manage satellite-specific technical specification in future submissions to ITU related to terrestrial-only technologies: Satellite specific technical specifications will not be submitted to ITU for inclusion in future submissions related to terrestrial-only technologies. Action: TSG RAN respectfully asks TSG SA and 3GPP PCG to take the above information into account.

Comment:

CC#4: This was left open for the Monday CC#5. Noted.

Discussion and conclusion:

CC#4: This was left open for the Monday CC#5.
CC#5: Discussion and conclusion:
Satellite specific technical specifications will not be submitted to ITU for inclusion in future submissions related to terrestrial-only technologies. It was understood that only specifications of relevance to ITU-R will be submitted, so no TSG SA specifications will need to be submitted. This LS was then noted.

Status:

Noted.

TD SP-211116 (LS IN) LS on EPS support for IoT NTN in Rel-17. (Source: TSG RAN (RP-212617)).
Document for: Action.
Abstract: TSG RAN would like to thank SA WG2 for their LS on EPS support for IoT NTN in Rel-17. TSG RAN notes that SA WG2 does not plan to define new functionality in Rel-17 to support discontinuous coverage. TSG RAN would like to emphasize that support for discontinuous coverage (incl. related impact on paging, (e)DRX, PSM, and PLMN search) is considered minimum essential functionality in TSG RAN with work under way in RAN WGs. Bearing in mind the scope of SA WG2 WID, TSG RAN would like to ask: - TSG SA, SA WG2 to reconsider supporting new functionality to support discontinuous coverage; - TSG CT/CT WG1 to consider whether low-hanging fruit solutions are feasible at NAS relying on existing functionality to support discontinuity in coverage, or, should TSG SA, SA WG2 decide to introduce new functionality to support discontinuous coverage, to align with TSG SA, SA WG2. - TSG SA/SA WG2/CT/CT WG1 to inform TSG RAN on the outcome of the discussion above. TSG RAN may adjust the scope of its Work Item depending on the outcome of the above discussions in TSG SA, SA WG2, CT, CT WG1. TSG RAN notes that SA WG2 decided not to support WUS, assuming it was not discussed in RAN for Rel-17 IoT NTN. TSG RAN would like to emphasize that work to support WUS in IoT NTN is indeed ongoing, with RAN WG2 concluding the existing WUS mechanism can be reused without enhancement (except for minor enhancements if needed to support discontinuous coverage). TSG RAN would therefore like to ask TSG SA, SA WG2, CT and CT WG1 to ensure WUS is not excluded. Action: TSG RAN would like to ask TSG SA, SA WG2, TSG CT and CT WG1 to take note of the information above.

Comment:

CC#4: This LS was noted.

Discussion and conclusion:

CC#4: This LS was noted.

Status:

Noted.

20.2 E-Meeting Procedures (TSG SA, SA WGs)

20.3 Review of the work plan

TD SP-211102 (WORK PLAN) 3GPP Work Plan review at Plenary #93e. (Source: MCC).
Document for: Presentation.
Abstract: 3GPP Work Plan review at Plenary #93e.

Comment:

Revised to SP-211141.

Discussion and conclusion:

-

Status:

Revised to SP-211141.

TD SP-211141 (WORK PLAN) 3GPP Work Plan review at Plenary #93e. (Source: MCC Work Plan Manager).
Document for: Presentation.
Abstract: 3GPP Work Plan review at Plenary #93e.

Comment:

Revision of SP-211102. Noted.

Discussion and conclusion:

CC#5: Slide 8: The SA WG2 Chair commented that the incomplete Rel-17 Stage 2 items are awaiting feedback from other groups or dependencies on other RAN WG work (e.g. RedCap).
Slide 18: The SA WG2 Chair commented that the term 'Stage 2 functional Freeze' should be used as 'normative' work is still ongoing after this point. The Work Plan Manager clarified that 'normative' was used to distinguish from Study work and it could be replaced by 'Functional'. The SA WG2 Chair asked for at least some note to be added to explain the meaning of the terminology used.
Slide 9: The SA WG2 Chair commented that SA WG6 have already started their Stage 2 Rel-18 work, so this could be shown separately in future presentations for clarity.
Slide 8: Qualcomm commented that SA WG2 have agreed 2 CRs on RedCap, so it should show closer to 100% rather than 0%. The Work Plan Manager replied that the work plan is a living document and this overview should not be used to focus on individual items, but the work plan should be updated with correct status when inaccuracies are discovered. Intel asked how the percentages are determined. The Work Plan manager replied that these are extracted from the Working Group reports at the TSGs, so some errors do enter the presentation, although this should be improved when WGs start using a common template for reporting. The SA WG2 Chair also reported that some of the rapporteur figures provided were changed at the discretion of the SA WG2 Chair for his report to TSG SA.
General : AT&T commented that there is much more information on RAN than SA and CT, in particular SA WG3, SA WG4 and SA WG5 work and asked if they can be included in future summaries. The Work Plan Manager agreed that the other groups work can be expanded in future presentations.
The Work Plan Manager was thanked for this report, which was noted.

Status:

Noted.

20.4 Specification Status

20.5 Work Item Summaries for TR 21.91x

Block 5 (to endorse Thursday 15:00 UTC)

TD SP-210890 (WI SUMMARY) WI Summary of eNS_Ph2. (Source: ZTE Corporation).
Document for: Approval.
Abstract: WI sumarry of eNS_Ph2.

Comment:

CC#3: Block Endorsed.

Discussion and conclusion:

CC#3: Block Endorsed.

Status:

Endorsed.

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

TD SP-211018 (DISCUSSION) Discussion on the use of status 'endorsed'. (Source: MCC).
Document for: Agreement.
Abstract: Discussion on the use of status 'endorsed'.

Comment:

CC#2: This was noted and further e-mail discussion was encouraged.

Discussion and conclusion:

CC#2: Samsung commented that Endorsed has a number of meanings which mean that the document cannot be further processed due to various reasons. Motorola Solutions commented that only agreed documents should be forwarded to the TSG, not endorsed. IDEMIA commented that it is clear that a CR needs to be 'agreed' to go to plenary for approval, or, if you have just very few companies against agreement, there is the option of a 'working agreement' which still can be challenged at plenary. The TSG SA Chair commented that the current use of endorsed is used and understood in the WGs. The SA WG2 Chair commented that the proposal is to distinguish between documents which are endorsed for further basis of work and those which are sent to the TSG for further discussion and potential approval. The TSG SA Char commented that this needs further discussion and any need for a new status would require a change to 21.900. This was noted and further e-mail discussion was encouraged.

e-mail discussion:

SA chair think that further status values would not lead to less discussions and therefore the meaning of endorsed could just be kept as it is. In general a reduction of status values would be more desirable.
SA2 chair thinks that it would be useful to differentiate the TDoc status for the endorsed CR that is sent to the plenary for approval vs. the endorsed CR that is not sent to the plenary for approval.

Status:

Noted.

20.7 MCC Status Report

(will be handled on Monday 20 September)

TD SP-210896 (REPORT) MCC Support Team report. (Source: ETSI - MCC).
Document for: Presentation.
Abstract: MCC Support Team report.

Comment:

Noted.

Discussion and conclusion:

CC#5: General: The SA WG6 Chair asked whether the search of CRs based on Impacts had made any progress and whether any work on the Voting Tool Performance and User Experience. The MCC Director reported that the Voting Tool issues have been resolved, which was due to maintenance work on the portal which made the tool performance non-optimal. For the searching tools, there has been little progress so far and hopefully some progress can be reported in December 2021.
The MCC Director was thanked for this report, which was noted.

Status:

Noted.

20.8 Future Meeting schedule

TD SP-211091 (DISCUSSION) Future TSG SA and SA WG Meetings Planning. (Source: TSG SA Chair).
Document for: Information.
Abstract: Future TSG SA and SA WG Meetings Planning.

Comment:

CC#4: _rev3 noted. Revised to SP-211139.

Discussion and conclusion:

CC#2: Ericsson suggested softening the last bullet to clarify what 'technical grounds' means and suggested excluding TEI18 related WIDs/SIDs in bullet 4. China Mobile suggested adding 'which will be subject to Rel-18 prioritization in bullet 4 and removing the bullet on Rapporteur Assignment. The TSG SA Chair replied that a Rapporteur is required for every Work Item and clarifying their responsibilities is considered important. Huawei considered the responsibility of secondary Rapporteur to be too restrictive as mainly this is for splitting responsibility on Objectives of a WID/SID. It was clarified that objections based on TUs and available resource should be handled by TSG SA, not in SA WG2. It was clarified that the available TUs are based on SA WG2 holding 8 Face to Face meetings in the Rel-18 Stage 2 timeline. The first bullet should read 'TU budget' rather than 'TU estimate'. The TSG SA Chair will update the slides and send for further discussion. This was left for further e-mail discussion.
CC#3: SP 211091_rev2 was presented. Deutsche Telekom commented that hosts require some lead time to arrange face to face meeting venues. The TSG SA Chair replied that this will be kept in mind with the planning. The March 2022 TSG SA#95-e dates remain the same but reporting will be moved to the Thursday.
CC#4: SP-211091_rev3 was noted (to be revised to a new TD number by MCC).

e-mail discussion:

Revision request (editorial)
Siemens proposes to change the first bullet on slide three in SP-211091.

Status:

Revised to SP-211139.

TD SP-211139 (DISCUSSION) Future TSG SA and SA WG Meetings Planning. (Source: TSG SA Chair).
Document for: Information.
Abstract: Future TSG SA and SA WG Meetings Planning.

Comment:

Revision of SP-211091_rev3. Noted.

Discussion and conclusion:

Noted.

Status:

Noted.

21 Any Other Business

22 Close of Meeting

Step 1: Latest 17:00 UTC on Friday 17 September 2021 Step 2: MCC/RAN/CT reporting on Monday 20 September 2021