Chairman's notes

 

IPR call reminder:

“I draw your attention to your obligations under the 3GPP Partner Organizations’ IPR policies. Every Individual Member organization is obliged to declare to the Partner Organization or Organizations of which it is a member any IPR owned by the Individual Member or any other organization which is or is likely to become essential to the work of 3GPP.

Delegates are asked to take note that they are thereby invited:

  • to investigate whether their organization or any other organization owns IPRs which are, or are likely to become Essential in respect of the work of 3GPP.
  • to notify their respective Organizational Partners of all potential IPRs, e.g., for ETSI, by means of the IPR Information Statement and the Licensing declaration forms"

 

Antitrust policy Reminder:

“I also draw your attention to the fact that 3GPP activities are subject to all applicable antitrust and competition laws and that compliance with said laws is therefore required of any participant of this TSG/WG meeting including the Chairman and Vice Chairman. In case of question I recommend that you contact your legal counsel.

The leadership shall conduct the present meeting with impartiality and in the interests of 3GPP.

Furthermore, I would like to remind you that timely submission of work items in advance of TSG/WG meetings is important to allow for full and fair consideration of such matters.”

 

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

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

1. Public Information is Not Subject to EAR

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

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

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

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

 

2. Non-Public Information

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

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

 

3. Other Information

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

 

4. Conduct of Meetings

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

 

5. Responsibility of Individual Members

 

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

 

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

 

List for Meeting: All Sessions
Temporary Documents List - Ordered by Agenda Item
AI TD# Type Doc For Subject Source Rel Comments e-mail_Discussion Result
0 - - - All Agenda Items - - Docs:=0 -
1 - - - Opening of the Meeting by e-mail - - Docs:=0 -
1.1 - - - Welcome Speech - - Docs:=0 -
1.2 - - - Introduction - - Docs:=2 -
1.2 SP-200582 OTHER Information 3GPP Officials TSG SA Chairman Noted in CC#1 Noted
1.2 SP-200581 OTHER Information 3GPP Newcomer Orientation Session TSG SA Chairman Noted in CC#1 Noted
1.3 - - - IPR & Antitrust reminders - - Docs:=0 -
1.4 - - - Approval of Agenda - - Docs:=2 -
1.4 SP-200299 AGENDA Approval Agenda & Procedures & Time Schedule for TSG SA#88-e TSG SA Chairman Approved in CC#1 Approved
1.4 SP-200600 AGENDA Information SA#88-e GoToMeetings Agenda TSG SA Chairman Noted at CC#4 TSG SA Chairman provides _rev1 for CC#1.
TSG SA Chairman provides _rev2 for CC#2.
TSG SA Chairman provided SP-200600_Rev4 for CC#3.		 Noted
1.5 - - - Report from previous SA meetings - - Docs:=2 -
1.5 SP-200300 REPORT Approval Draft report of TSG SA meeting #86 TSG SA Secretary Approved in CC#1 Approved
1.5 SP-200301 REPORT Approval Draft report of TSG SA meeting #87E TSG SA Secretary Approved in CC#1 Approved
1.6 - - - Reports from TSG SA ad-hoc meetings and workshops - - Docs:=0 -
2 - - - Liaisons Statements - - Docs:=0 -
Block 1 - - - All documents in agenda item 2.1 (LS in - proposed to note) will be noted on Tuesday June 30, 15:00 UTC if not otherwise indicated - - Docs:=0 -
2.1 - - - Incoming LSs - proposed to note - - Docs:=20 -
2.1 SP-200313 LS In Information LS from ETSI: Liaison about ETSI ISG NIN (Non-IP Networking) ETSI (NIN(20)000011r1) Block Noted in CC#1 Noted
2.1 SP-200314 LS In Information LS from ITU-WRC: World Radiocommunication Conference, Sharm el-Sheikh, 2019 (WRC-19) Resolutions ITU-WRC (O-2020-001473 (3GPP)) Block Noted in CC#1 Noted
2.1 SP-200315 LS In Information LS from TSG SA: LS on Sidelink Positioning for advanced V2X applications SAE Advanced Application Technical Committee (SAE AA TC LS to 3GPP RAN v07a) Block Noted in CC#1 Noted
2.1 SP-200316 LS In Information LS from GSMA SECAG: NESAS Official Launch GSMA SECAG (SECAG Doc 57_015) Block Noted in CC#1 Noted
2.1 SP-200317 LS In Information LS from ITU-T SG13: LS/o on the agreement of Supplement 59 to ITU-T Y.3100-series Recommendations 'IMT-2020 standardization roadmap' ITU-T SG13 (SG13-LS150) Block Noted in CC#1 Noted
2.1 SP-200318 LS In Information LS from ITU-T SG3: LS/o on ongoing work within ITU-T Study Group 3 (SG3) on new Technical Report on 'IMT2020-Related Policy Considering MVNOs' ITU-T SG3 (SG3-LS80) Block Noted in CC#1 Noted
2.1 SP-200319 LS In Information LS from CT WG6: Reply LS to LS on support for eCall over NR CT WG6 (C6-200332) Rel-16 Block Noted in CC#1 Noted
2.1 SP-200320 LS In Information LS from RAN WG3: LS on port allocation RAN WG3 (R3-202553) Rel-16 Block Noted in CC#1 Noted
2.1 SP-200321 LS In Information LS from SA WG1: Reply LS on Questions on onboarding requirements SA WG1 (S1-202266) Rel-17 Block Noted in CC#1 Noted
2.1 SP-200322 LS In Information LS from SA WG2: Reply LS on Questions on onboarding requirements SA WG2 (S2-2003216) Rel-17 Block Noted in CC#1 Noted
2.1 SP-200327 LS In Information LS from SA WG3: LS on Updated User Plane Integrity Protection advice SA WG3 (S3-201487) Rel-16 Block Noted in CC#1 Noted
2.1 SP-200328 LS In Information LS from SA WG5: LS on network data analysis energy saving SA WG5 (S5-203360) Rel-17 Block Noted in CC#1 Noted
2.1 SP-200330 LS In Information LS from SA WG5: Reply LS on energy efficiency SA WG5 (S5-203016) Rel-16 Block Noted in CC#1 Noted
2.1 SP-200329 LS In Information LS from SA WG6: Reply LS on ITU-R WP5D report on the use of IMT for PPDR SA WG6 (S6-200934) Block Noted in CC#1 Noted
2.1 SP-200451 LS In Information LS from SA WG5: LS on SA5 Rel-17 work on SLA SA WG5 (S5-203370) Rel-17 Block Noted in CC#1 Noted
2.1 SP-200459 LS In Information LS from CT WG1: Reply LS on Updated User Plane Integrity Protection advice CT WG1 (C1-204194) Rel-16 Block Noted in CC#1 Noted
2.1 SP-200460 LS In Information LS from SA WG2: Reply LS on Statement on UAV Remote ID Priority in Release 17 SA WG2 (S2-2004663) Rel-17 Block Noted in CC#1 Noted
2.1 SP-200521 LS In Information LS from CT WG4: Reply LS on port allocation CT WG4 (C4-203712) Rel-16 Block Noted in CC#1 Noted
2.1 SP-200615 LS In Information LS from TSG CT: Reply LS on port allocation TSG CT (CP-201316) Rel-16 Noted at CC#3 MCC have allocated SP-200615 and SP-200616 for incoming LSs from TSG CT on port allocation.
It is proposed to note these LSs as they are for information to TSG SA.
 Noted
2.1 SP-200616 LS In Information LS from TSG CT: LS on port allocation for the W1 interface TSG CT (CP-201349) Rel-16 Noted at CC#3 Noted
Block 2 - - - All documents in agenda item 2.2 (LS in - actions) which have a proposed action 'noted' will be noted on Wednesday July 1, 15:00 UTC if not otherwise indicated - - Docs:=0 -
2.2 - - - Incoming LSs which need an outgoing LS and - - Docs:=21 -
2.2 SP-200601 LS In Action LS from TSG CT: LS on port allocation TSG CT (CP-201315) Rel-16 The latest version developed by TSG CT was endorsed. Endorsed
2.2 SP-200325 LS In Information LS from SA WG2: Reply LS on IAB supporting in NPN deployment SA WG2 (S2-2004469) Rel-16 Actions to RAN WG2 and RAN WG3: To inform TSG SA the actual progress in order to decide whether the corresponding SA WG2 CR can be approved or not (SP-200435). Noted at CC#3 Noted
2.2 SP-200312 LS In Action LS from IETF: Re: LS on need for Multi-Path QUIC for ATSSS IETF (LS_from_IETF) This LS was forwarded to SA WG2. Noted
2.2 SP-200533 LS In Action LS from GSMA: Inclusion of full-rate UPIP for 5GSA in 3GPP Release 16 GSMA (GSMA_LS200604) Rel-16 Noted at CC#4 Proposed Action: TBD Johannes (Deutsche Telekom AG): It is proposed to merge response LSs to GSMA Board and GSMA CVD and revise SP-200540 to address both groups with the outcome of the SA#88-e meeting. Noted
2.2 SP-200309 LS In Action LS from 5GAA WG4: LS on eCall Support on 5G Core with NR 5GAA WG4 (5GAA_S-200065.) All necessary CRs for eCall over NR have been completed. This LS was then noted. Proposed Action: Possibly reply needed Noted
2.2 SP-200310 LS In Action LS from IALA: Liaison Note to TSG SA - Request for information IALA (C71-11.5.1) This LS was postponed. Proposed Action: Reply LS to IALA is needed Hyounhee Koo (SyncTechno Inc.): It is proposed to postpone the discussion on the reply liaison for SP-200310 to TSG SA#89e in September 2020 because the next IALA meeting is scheduled to be held in October 2020. Postponed
2.2 SP-200602 LS In Action LS from 5G-ACIA: 5G capabilities exposure for factories of the future 5G-ACIA (5G-ACIA_LS_29062020) Response drafted in SP-200608. Noted at CC#3 MCC Allocates SP-200608 to response to this LS.
Deutsche Telekom proposes to note the LS IN		 Noted
2.2 SP-200608 LS OUT Approval Reply-LS on 5G capabilities exposure for factories of the future TSG SA Response to SP-200602. Withdrawn at CC#3. Johannes (Deutsche Telekom AG): provides SP-200608: Reply-LS to 5G-ACIA on 5G capabilities for factories of the future:
3GPP TSG SA would like to thank 5G-ACIA for the liaison statement and the attached white paper on Exposure of 5G capabilities for connected industries and automation applications.
3GPP work in all groups is contribution driven and the work plan captures the features based on work items agreed in different working groups.
3GPP invites individual member companies to provide contributions on these additional use cases and requirements to the individual 3GPP working groups starting at stage1, i.e. SA WG1. Subsequently stage2 and stage3 work will be progressed accordingly.
No further action to 5G-ACIA.
LaeYoung (LGE) provides updated version with editorial changes.
Krister (Ericsson): proposes revision SP-200608 to add some content to the response LS
Miikka (Nokia) comments version provided by Ericsson and LGE ('E_LGE').
Vodafone thinks there is value in retaining the original text as provided by Magenta and proposes to add SA6 to the information for 5G-ACIA.
Siemens questions whether non-3GPP entities need to be addressed in the reply. Proposed action: delete all non-3GPP addressees in the reply-LS
Deutsche Telekom likes to raise some concerns to depict specific working groups to act and suggest implicitly to external bodies to interact directly with working groups. Any work in 3GPP shall be done based on requirements and then downstream groups. Hence SA1 is the hook-up point for new features or gap analysis to be targeted.
Ericsson points out that 3GPP has been doing work in SA6 to address API developments in 3GPP that is utilizing lower layers such as NEF in SA2.
After offline discussion Vodafone proposed a slight alteration to their proposed wording.
Siemens provides background information on the 5G-ACIA whitepaper.
Ericsson prefer the draft version in the draft folder provided by LGE
Johannes (Deutsche Telekom): Editor provided a draft_rev1 in the inbox/drafts to reflect all the comments received up to now and to discuss potential way forward in the Call. There is somehow a deadlock on how to proceed with reflecting scope and additions of downstream groups. As DT has stated before, we are not agreeing to include any stage2 or stage3 group or their potential scope in an LS at the current stage. The LS came in late and the whitepaper was just published 2 days before the meeting started. Therefore it is premature to indicate some other potential stage2 and stage3 groups for potential work to do.
Huawei commented 5G-ACIA had good collaboration with 3GPP since R16, and this should continue. Since it is not possible to give a tech analysis in plenary, specific working groups are not needed to mention in this LS, as all 3GPP work is contribution driven.
Vodafone accepts the draft_ rev1 provided by the editor in the inbox/drafts folder on the grounds that less is more. As we cannot agree on more detailed wording it is better to use fewer words as per draft_rev1.
Ericsson disagrees with version from DT and provides an updated version in the draft folder.
Futurewei supports the way forward provided by Deutsche Telekom in Draft-Rev1_DT2 and provides minor editorials for Editor's consideration.
Deutsche Telekom provided Draft-Rev1_DT2. Proposed way forward trying to provide a compromise.
Siemens revised Ericsson's version for clarity and marked an unclear subclause. The updated document is provided in the draft folder.
Siemens proposes to include input from the SA2, SA3 and SA5 chairs into the version provided by Suresh Chitturi earlier today.
Deutsche Telekom does not agree with the proposal from Ericsson and SA WG6 chair
Huawei supports Draft-Rev1_DT2 from Deutsche Teledom
Ericsson support the LS version proposed by SA6 chair
Deutsche Telekom proposes to move forward with either simple LS to politely thank 5G-ACIA or to just note the incoming LS and withdraw the Reply-LS-draft (as 3GPP has done multiple times in the past with other bodies like GSMA and NGMN)
Miikka (Nokia) supports Draft-Rev1_DT2 from Johannes (DTAG)
Suresh Chitturi (SA6 Chair) believes the version in Draft-Rev1_DT2 from Johannes (DTAG) does not add any value, and does not offer any specific guidance to either WGs or 5G-ACIA.
Ericsson agrees with DT 3 comments and maybe we can withdraw responding to the LS since we will just provide info that 5G-ACIA already knows.
Noamen(SA3 chair): No related Rel-17 activities in SA3 yet.
Deutsche Telekom proposes to withdraw the Reply-LS SP-200608: based on the existing good collaboration with 5G-ACIA there seems to be no need to provide further introduction or guidance		 Withdrawn
2.2 SP-200304 LS In Information LS from GSMA: Mandatory User Plane Integrity for 5G GSMA (FSAG#79_002) Postponed SP-200021 from SP-87E. Responses drafted in SP-200539 and SP-200540. Final response in SP-200618 Proposed action: Noted (related discussion will be triggered by disc papers) Replied to
2.2 - - - Block 2: Proposed to note - - Docs:=12 -
2.2 SP-200308 LS In Endorsement LS from TSG RAN: DRAFT LTI - answer to ITU-R WP5D LS on WORKING DOCUMENT TOWARDS A PRELIMINARY DRAFT REVISION OF REPORT ITU-R M.2291-1 TSG RAN (RP-200572) For e-mail Endorsement and forwarding to PCG. Endorsed and forwarded to the PCG, 10 June 2020 Endorsed
2.2 SP-200305 LS In Action LS from ITU-R WP5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ON DRAFT REVISION OF REPORT ITU-R M.2291-1 'THE USE OF INTERNATIONAL MOBILE TELECOMMUNICATIONS (IMT) FOR BROADBAND PUBLIC PROTECTION AND DISASTER RELIEF (PPDR) APPLICATIONS' ITU-R WP5D (5D_TD_52R1e) Postponed SP-200241 from SP-87E. This was resolved by endorsing and forwarding SP-200308 to the PCG. Block noted at CC#2 This was resolved with SP-200308. Proposed action: Noted Noted
2.2 SP-200303 LS In Action LS from CableLabs: Status and Evolution of 5WWC CableLabs (LS_5WWC status) Postponed SP-200020 from SP-87E. Block noted at CC#2 Proposed action: Noted (if somebody wants to write a reply, please indicate) Noted
2.2 SP-200302 LS In Action LS from 5GAA WG4: LS on relevant 3GPP Specs for PC5 Sidelink 5GAA WG4 (5GAA_S-200026) Postponed SP-200019 from SP-87E. Block noted at CC#2 Proposed action: Noted Noted
2.2 SP-200306 LS In Action LS from RAN WG2: Reply LS on Rel-16 NB-IoT enhancements RAN WG2 (R2-2001815) Rel-16 Postponed SP-200244 from SP-87E. Block noted at CC#2 Proposed action: Noted Noted
2.2 SP-200307 LS In Action LS from SA WG5: Reply LS on analytics support for energy saving SA WG5 (S5-201472) Rel-17 Postponed SP-200246 from SP-87E. Block noted at CC#2 Proposed action: Noted Noted
2.2 SP-200311 LS In Action LS from TCCA: LS on Generic Slice Template with Public Safety Feedback TCCA (LS to GSMA on Generic Slice Template) Block noted at CC#2 Proposed Action: Noted (if no comments received) Noted
2.2 SP-200323 LS In Action LS from SA WG2: Reply LS on support for eCall over NR SA WG2 (S2-2003308) Rel-16 Block noted at CC#2 Proposed Action: Noted (if no comments received) Noted
2.2 SP-200324 LS In Action LS from SA WG2: LS on SA WG2 status of MT-EDT in Rel-16 SA WG2 (S2-2003505) Rel-16 Block noted at CC#2 Proposed Action: Noted (if no comments received) Noted
2.2 SP-200326 LS In Action LS from SA WG2: Reply LS on S1/NG DAPS handover SA WG2 (S2-2004474) Rel-16 Block noted at CC#2 Proposed Action: Noted (related issue with S2 CRs 23.502#2318 and 23.401#3602 needs to be resolved first) Noted
2.2 SP-200450 LS In Action LS from SA WG5: Reply LS to Reply LS on support for eCall over NR SA WG5 (S5-203369) Rel-16 Block noted at CC#2 Proposed Action: Noted Noted
2.2 SP-200458 LS In Action LS from CT WG1: Reply LS on support of eCall over NR CT WG1 (C1-203221) Rel-16 Block noted at CC#2 Proposed Action: Noted Noted
3 - - - Items for discussion and early consideration - - Docs:=0 -
3.1 - - - Challenges to working agreements - - Docs:=0 -
3.2 - - - Issues highlighted for early treatment - - Docs:=9 -
3.2 SP-200539 LS OUT Approval [DRAFT] LS on mandatory support of full rate user plane integrity protection for 5G Deutsche Telekom AG Rel-16 Response to SP-200304. SP-200539_rev1 approved at CC#3. Revised to SP-200617. Johannes (Deutsche Telekom AG): provides SP-200539_Rev1.
Revision1 includes the correct Number of the CR agreed, includes the GSMA Board LS IN, cleans up the wording according to the discussion paper in SP-200537, removes square brackets and corrects the date of the next SA Plenaries==== CC#3: SP-200539_Rev1. Approved. Revised to SP-200617 ====		 Revised
3.2 SP-200617 LS OUT Approval LS on mandatory support of full rate user plane integrity protection for 5G TSG SA Rel-16 Revision of SP-200539_Rev1. Approved Approved
3.2 SP-200540 LS OUT Approval [DRAFT] LS on mandatory support of full rate user plane integrity protection for 5G Deutsche Telekom AG Rel-16 Response to SP-200304. SP-200540_rev3 was approved at CC#3. Revised to SP-200618. Johannes (Deutsche Telekom AG): provides SP-200540_Rev1.
3GPP SA received 2 LSs from GSMA, i.e. one from GSMA Board in SP-200533 and one from GSMA CVD in SP-200304. It is proposed to have a common outgoing Reply-LS to both GSMA groups on the outcome of the discussion in SA#88-e meeting.
Johannes (Deutsche Telekom AG): provides SP-200540_Rev2.
Based on the agreement reached out of SP-200537 companies proposed offline an alignment of the text and also a clean up of abreviations used in the text.
Johannes (Deutsche Telekom AG): provides SP-200540_Rev3.
Revision3 add some editorials for clarity, deletion of extra spaces==== CC#3: SP-200540_Rev3. Approved. Revised to SP-200618 ====		 Revised
3.2 SP-200618 LS OUT Approval LS on mandatory support of full rate user plane integrity protection for 5G TSG SA Rel-16 Revision of SP-200540_Rev3. Approved Approved
3.2 SP-200537 DISCUSSION Decision Way forward on User Plane Integrity Protection Deutsche Telekom, T-Mobile US, A.S.T.R.I.D. S.A., AT&T, BDBOS, Bell Mobility, BMWi, BOSCH, Broadcom, BT, China Mobile, Erillisverkot, FirstNet, Huawei, HiSilicon, KPN, NCSC, Nkom, NTT DoCoMo, Orange, SEQUANS, Siemens, Swift Navigation, Telecom Italia, Tel Rel-16 Noted in CC#1 Noted
3.2 SP-200538 CR Approval 33.501 CR0852 (Rel-16, 'C'): CR to 33.501 - Update to User Plane Integrity Protection Deutsche Telekom AG, et al. Rel-16 CC#3: SP-200538_Rev6 was approved and revised in SP-200628 Johannes (Deutsche Telekom AG): provides SP-200538_Rev1. Offline discussions resulted in some changes in the CR text for clarification.
Johannes (Deutsche Telekom AG): provides SP-200538_Rev2. Offline discussions resulted in some changes in the CR text for clarification.
Adrian (vivo): provides editorial comment.
Johannes (Deutsche Telekom AG): provides SP-200538_Rev3. Based on the discussion in the GTM call it is proposed to remove the second change in the CR to section 5.3.3
Chunhui Zhu (Spreadtrum) requests clarifications about 'UE's maximum supported data rate' in the change.
Chris (Vodafone): provides SP-200538_rev4 to editorially improve rev 3.
Scott Migaldi of T-Mobile USA supports the latest version of the CR.
Johannes (Deutsche Telekom AG): Clarification of the maximum data rate: The maximum data rate is defined in TS38.300 chapter 13.1. The integrity protection check is done in PDCP based on PDCP PDUs. Hence the data rate refers to the PDCP data rate and not L1 or IP.
Johannes (Deutsche Telekom AG): provides SP-200538_Rev5. Based on the discussion and revisions proposed the Rev5 should reflect comments and proposal of the email discussions. The Coverpage is cleaned up and the wording is improved as well as aligned with the wording of other specifications like e.g. TS38.300 on the highest data rate. Additional supporting companies T-Mobile US, Telecom Italia, AT&T, Vodafone, Siemens are added to the CR coverpage. RAN impact is re-inserted.
MCC revised SP-200538_rev6 to SP-200628 after approval in CC#2.
Chunhui Zhu (Spreadtrum): Prefer leaving the TEI16 as only WI-code.
Johannes (Deutsche Telekom AG): provides Draft_SP-200538_Rev5. Based on the discussion and revisions proposed in the CC#2 final changes to the coverpage need to be fixed. The CR-Text was approved at the call CC#2, it has been agreed to leave the revision counter to MCC to fix, further the tickboxes for CN and RAN left empty as the change itself does not impact core or RAN but the affected specs in RAN and CT working groups are listed. The revision-history box is filled with only one revision as this reflects the update from the original submitted CR.
Johannes (Deutsche Telekom AG): provides SP-200538_Rev6. As there is only one comment received I move forward to have the work Item code set to TEI16 only, no comments on the other changes.
Tao Sun(China Mobile) would like to co-sign SP-200613.		 Revised
3.2 SP-200628 CR Approval 33.501 CR0852R1 (Rel-16, 'C'): CR to 33.501 - Update to User Plane Integrity Protection Deutsche Telekom AG, T-Mobile US, Telecom Italia, AT&T, Vodafone, Siemens Rel-16 Revision of SP-200538_Rev6. This CR was approved Approved
3.2 SP-200557 LS OUT Approval LS on UAS definition updates Qualcomm CDMA Technologies Rel-17 Approved at CC#3. Revised to SP-200619. ==== CC#3: SP-200557. Approved. Revised to SP-200619 ==== Revised
3.2 SP-200619 LS OUT Approval LS on UAS definition updates TSG SA Rel-17 Revision of SP-200557. WITHDRAWN at CC#4 Withdrawn
3.3 - - - Discussion papers on work in Rel-15 and earlier - - Docs:=0 -
3.4 - - - Discussion papers on work in Rel-16 - - Docs:=0 -
3.5 - - - Discussion papers on work in Rel-17 - - Docs:=0 -
3.6 - - - Discussion papers on work in Rel-18 and later - - Docs:=0 -
Block 3 - - - All reports in agenda item 4 (Reporting) and its sub-agenda items will get a max 5 minute slot on the GTM call Wednesday July 1 for presenting issues which need plenary decision. - - Docs:=0 -
3a - - - All documents in this agenda (and its sub-agenda items) will be Noted on Wednesday July 1, 15:00 UTC if not otherwise indicated - - Docs:=0 -
4 - - - Reporting from SA Working Groups, other TSGs, and Others - - Docs:=0 -
4.1 - - - SA WG1 reporting - - Docs:=1 -
4.1 SP-200559 REPORT Information SA WG1 Report to TSG SA#88e SA WG1 Chairman Noted at CC#2 Noted
4.2 - - - SA WG2 reporting - - Docs:=1 -
4.2 SP-200536 REPORT Presentation SA WG2 Chairman's report to TSG SA#88E SA WG2 Chairman Noted at CC#2 Noted
4.3 - - - SA WG3 reporting - - Docs:=1 -
4.3 SP-200346 REPORT Information SA WG3 Status report Ericsson LM Noted at CC#2 Noamen (SA3 chair): The formatting issue in the summary slides and the missing Tdoc number must to be corrected. SP-200346_rev1 implements the required changes. Noted
4.4 - - - SA WG4 reporting - - Docs:=1 -
4.4 SP-200385 REPORT Information Report on SA WG4 Status Update SA WG4 Chairman LATE DOC: Rx 26/06, 13:00. Noted at CC#2 Noted
4.5 - - - SA WG5 reporting - - Docs:=2 -
4.5 SP-200545 ToR Approval Revision of SA WG5 ToR SA WG5 CC#2: This updated ToR was approved. Approved
4.5 SP-200554 REPORT Information SA WG5 status report to TSG SA#88 Ericsson LM Noted at CC#2 Noted
4.6 - - - SA WG6 reporting - - Docs:=1 -
4.6 SP-200331 REPORT Information SA WG6 status report to TSG SA#88 SA WG6 Chairman Noted at CC#2 Noted
4.7 - - - TSG RAN reporting and RAN ITU-R Ad Hoc Matters (Friday morning, if available) - - Docs:=0 -
4.8 - - - TSG CT reporting - - Docs:=3 -
4.8 SP-200625 REPORT Presentation Status report of TSG CT#88-e TSG CT Chairman Noted at CC#4 Noted
4.8 SP-200626 REPORT Information Draft report of TSG CT#88-e TSG CT Secretary (MCC) Noted at CC#4 Noted
4.8 SP-200627 REPORT Presentation IETF Status report TSG CT Chairman Noted at CC#4. Noted
4.9 - - - Reports from external bodies (provided by Liaison persons) - - Docs:=1 -
4.9 SP-200583 OTHER Information 3GPP Liaison Persons (living document) TSG SA Chairman Noted at CC#3 Noted
4.10 - - - Other reports - - Docs:=0 -
5 - - - Cross TSG Coordination - - Docs:=0 -
5.1 - - - General Cross TSG Coordination - - Docs:=0 -
5.2 - - - Rel-16 Focus Areas Status Reports & Issues - - Docs:=0 -
5.3 - - - Rel-17 Focus Areas Status Reports & Issues - - Docs:=0 -
5.4 - - - Input to Joint RAN/SA meeting - - Docs:=0 -
Block 4 - - - All documents for approval in agenda item 6 (WIDs/SIDs/TSs/TRs, Exception Sheets) and its sub-agenda items which are not marked red will be marked approved onThursday July 2 15:00 UTC. - - Docs:=0 -
4a - - - All documents for information in this agenda item and its sub-agenda items will be marked noted at the same time. - - Docs:=0 -
6 - - - Work Item Descriptions, Study Item Descriptions, Specifications - - Docs:=0 -
6.1 - - - New Release 16 and earlier Study Item Descriptions and Work Item Descriptions - - Docs:=2 -
6.1 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=2 -
6.1 SP-200354 WID NEW Approval New WID on User Plane Integrity Protection for NR. SA WG3 Approved at CC#3 Chunhui Zhu (Spreadtrum): based on the discussion and output of SP-200540(LS reply to GSMA) and SP-200538(33.501 CR), the UPIP CR(SP-200367) and WID(SP-200354 ) from SA3 are not needed.
Vodafone support the approval of both the WID and the CRs produced by SA3 in parallel with the CR for full rate UPIP as these CRs apply to LTE and the other 5G options, whereas the tdoc SP-200538 only applies to 5G Option 2.
Chunhui Zhu(Spreadtrum): if we approve the SA3 R16 solution in the TS33.501 informative annex, R17 may have the backward compatible risk and the total solution will be fragmented.
Haris (Qualcomm) support the approval of the CR and WID
Based on the received comments and that the SA3 CR/WID are only informative, Spreadtrum can live with the CR/WID and would withdraw the objection.

Samsung argues that the mitigations in SP-200367 CR Pack CRs and the WID in SP-200354 are needed. Omission of these would be a grave mistake.
Approved
6.1 SP-200367 CR PACK Approval Rel-16 CRs on User Plane Integrity Protection SA WG3 This CR Pack was approved at CC#3 Chunhui Zhu (Spreadtrum): based on the discussion and output of SP-200540(LS reply to GSMA) and SP-200538(33.501 CR), the UPIP CR(SP-200367) and WID(SP-200354 ) from SA3 are not needed.
Chunhui Zhu(Spreadtrum): if we approve the SA3 R16 solution in the TS33.501 informative annex, R17 may have the backward compatible risk and the total solution will be fragmented.
Haris (Qualcomm) support the approval of the CR and WID
Samsung argues that the mitigations in SP-200367 CR Pack CRs and the WID in SP-200354 are needed. Omission of these would be a grave mistake.
Based on the received comments and that the SA3 CR/WID are only informative, Spreadtrum can live with the CR/WID and would withdraw the objection.		 Approved
6.2 - - - Revised Release 16 and earlier Study Item Descriptions and Work Item Descriptions - - Docs:=10 -
6.2 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=10 -
6.2 SP-200401 WI EXCEPTION REQUEST Approval Rel-16 Work Item Exception for 5GMS3 SA WG4 Rel-16 Block approved Approved
6.2 SP-200406 WI EXCEPTION REQUEST Approval Rel-16 Work Item Exception for RM_H263_MP4V SA WG4 Rel-16 Block approved Approved
6.2 SP-200461 WID REVISED Approval Revised WID on Enhancement of 3GPP management system for multiple tenant environment support. SA WG5 Rel-16 Block approved Approved
6.2 SP-200468 WI EXCEPTION REQUEST Approval Rel-16 Exception request for QOED SA WG5 Block approved Approved
6.2 SP-200469 WI EXCEPTION REQUEST Approval Rel-16 Exception request for eNRM SA WG5 Block approved Approved
6.2 SP-200470 WI EXCEPTION REQUEST Approval Rel-16 Exception request for 5GDMS SA WG5 Block approved Approved
6.2 SP-200471 WI EXCEPTION REQUEST Approval Rel-16 WI Exception for Network Slice performance and Analytics Charging in 5GS SA WG5 Block approved Approved
6.2 SP-200472 WI EXCEPTION REQUEST Approval Rel-16 WI Exception for Network Slice Management Charging in 5GS SA WG5 Block approved Approved
6.2 SP-200473 WI EXCEPTION REQUEST Approval Rel-16 WI Exception for ATSSS SA WG5 Block approved Approved
6.2 SP-200514 WI EXCEPTION REQUEST Approval Rel-16 Work Item Exception for SON_5G SA WG5 Block approved Approved
6.3 - - - New Release 17 Study Item Descriptions - - Docs:=12 -
6.3 SP-200353 SID NEW Approval Study on enhanced security support for Non-Public Networks. SA WG3 CC#2: Removed from block approval. SP-200353_Rev5 was approved at CC#3. Revised to SP-200620. Vodafone: Vodafone Object to this SID in its current form. The 'UE Onboarding and remote provisioning' section in clause 4 needs to be removed and a new section on 'the creation of required key materials from other EAP methods (than EAP-AKA')' should be added in clause 4. With these changes VF would support this SI.
Intel seeking clarification on Vodafone's objection.
Ericsson commented that UE onboarding was prioritized for Rel-17 by SA plenary in September and December meetings.
Orange maintains its objection to the approval of the SID as in the SA3#99-e meeting and asks SA to send it back to SA3 for further discussions.
Ericsson comment that there is no reason to delay the approval of the SA3 SID
Siemens supports Ericsson's view on SP-200353.
Siemens kindly asks the owner of SP-20353 to add Siemens to the list of supporting individual members in Clause 9 of the document.
MediaTek also see the SA3 SID can be approved in this plenary. However the timeline of the TR is unrealistic (for info in September / for approval in December) and needs discussion.
Miikka (Nokia) recommends to proceed with the study.
Haris (Qualcomm) recommends to proceed with the study
Clarifying that Vodafone support the principal of the SID but have issues with the wording of one area of the SID. Proposing updates to the SID as clarifications.
Bo (Sony) recommends approval of the study.
Noamen(SA3 chair): Included additions by Vodafone and added Siemens to the supporting company list in SP-200353_rev1.
Intel is OK with the changes proposed by Vodafone. Points to one typo.
SP-200353_rev1. Is fine for Vodafone and we withdraw our objection for this version. Please also add Vodafone as a supporting company. The dates need to be more realistic - based on the current SA3 schedule they need to slip the approval date by 3 months (This is not a blocking issue for Vodafone).
Noamen(SA3 chair): Included Vodafone to the supporting company list, corrected the typo pointed out by Intel and adjusted the time line as suggested in SP-200353_rev2.
Orange provided revisions on SP-200353 rev2 to clarify the description of the objectives.
Philips comments on proposal from Orange.
Noamen(SA3 chair): Included clarifications by Orange and Philips to the objectives in SP-200353_rev4.
Deutsche Telekom supports the revisions provided by Orange.
Orange supports SP-200353_rev4.
Deutsche Telekom supports SP-200353_rev4.
Noamen(SA3 chair): Cleaned up the document and added 'Charter Communications' to the list of supporting companies in SP-200353_rev5.
Siemens supports SP-200353_rev4.==== CC#3: SP-200353_Rev5. Approved. Revised to SP-200620 ====
Spreadtrum supports SP-200353_rev4 and requests to be included to the supporting company list.		 Revised
6.3 SP-200620 SID NEW Approval Study on enhanced security support for Non-Public Networks. TSG SA Revision of SP-200353_Rev5. Approved Approved
6.3 SP-200355 SID NEW Approval New SID on Industrial IoT Security. SA WG3 CC#2: Removed from block approval. SP-200355_Rev1 was approved at CC#3. Revised to SP-200621. Siemens kindly asks the owner of this document to add Siemens to the list of supporting individual members in clause 9.==== CC#3: SP-200355_Rev1. Approved. Revised to SP-200621 ==== Revised
6.3 SP-200621 SID NEW Approval New SID on Industrial IoT Security. TSG SA Revision of SP-200355_Rev1. Approved Approved
6.3 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=8 -
6.3 SP-200347 SID NEW Approval New SID on Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC. SA WG3 SP-200347_Rev2 was Approved at CC#3. Revised to SP-200624. Noamen (SA3 chair): Following MCC's recommendation, it is proposed to change the SID acronym to include the term EDGE.
Noamen (SA3 chair): Following MCC's recommendation, it is proposed to change the SID acronym to include the term EDGE. SP-200347_rev1 implements the required changes.
Noamen (SA3 chair): Following SA6 chair suggestions, it is proposed to change the SID acronym to include the term FS_EDGE_Sec and the title accordingly. SP-200347_rev2 implements the required changes.
Alain (WP Manager): It makes sense not to have 'enhancement' in the WID title and it is better to have 'EDGE' appearing clearly in the acronym.==== CC#3: SP-200347_Rev2. Approved. Revised to SP-200624 ====		 Revised
6.3 SP-200624 SID NEW Approval New SID on Study on Security Aspects of Enhancement of Support for Edge Computing in 5GC. TSG SA Revision of SP-200347_Rev2. Approved Approved
6.3 SP-200349 SID NEW Approval Study on security aspects of the Disaggregated gNB Architecture. SA WG3 CC#2: Removed from block approval. Approved at CC#4 Approved
6.3 SP-200350 SID NEW Approval Study on Security Aspects of Enhancement for Proximity Based Services in 5GS. SA WG3 Block approved Approved
6.3 SP-200351 SID NEW Approval New SID: Study on Security Aspects of Enhancement for 5G Multicast-Broadcast Services. SA WG3 Block approved Approved
6.3 SP-200352 SID NEW Approval New SID on security aspects of UAS. SA WG3 Block approved Approved
6.3 SP-200399 SID NEW Approval New SID on 5G Glass-type AR/MR Devices SA WG4 Block approved Approved
6.3 SP-200467 SID NEW Approval New SID on charging aspects of Edge Computing. SA WG5 Block approved Approved
6.4 - - - New Release 17 Work Item Descriptions - - Docs:=22 -
6.4 SP-200446 WID NEW Approval New WID on Dynamically Changing AM Policies in the 5GC (TEI17_DCAMP). SA WG2 Update of postponed SP-200086 from SP-87E. Proposed company revision in SP-200580. Noted at CC#3 Noted
6.4 SP-200580 WID NEW Approval New WID on Dynamically Changing AM Policies in the 5GC (TEI17) China Telecom Corporation Ltd. Rel-17 Proposed update of SA WG2 WID in SP-200446. Approved at CC#3. Approved
6.4 SP-200452 WID NEW Approval New WID: IMS Optimization for HSS Group ID in an SBA environment (TEI17) SA WG2 Resubmission of postponed SP-200084 from SP-87E. Proposed company revision in SP-200546. Noted at CC#3 Noted
6.4 SP-200546 WID NEW Approval New WID: IMS Optimization for HSS Group ID in an SBA environment (TEI17). Ericsson (SA WG2) Rel-17 Revision of postponed SP-200257 from SP#87-E. Proposed update of SA WG2 WID in SP-200452. Approved at CC#3 Approved
6.4 SP-200453 WID NEW Approval New WID: Support for Signed Attestation for Priority and Emergency Sessions (TEI17). SA WG2 Resubmission of postponed SP-200085 from SP-87E. Proposed company revision in SP-200547. Noted at CC#3 Noted
6.4 SP-200547 WID NEW Approval New WID: Support for Signed Attestation for Priority and Emergency Sessions (TEI17). Ericsson (SA WG2) Rel-17 Revision of postponed SP-200258 from SP#87-E. Proposed update of SA WG2 WID in SP-200453. Approved at CC#3 Approved
6.4 SP-200455 WID NEW Approval New WID: Dynamic management of group-based event monitoring (TEI17). SA WG2 Resubmission of postponed SP-200088 from SP-87E. Work Plan manager suggests shortening the acronym to 'TEI17_GEM'. SP-200455_Rev1 approved at CC#3. Revised to SP-200622. Shabnam (Ericsson) r01 revision provided to shorten the WI Code to TEI17_GEM.==== CC#3: SP-200455_Rev1. Approved. Revised to SP-200622 ==== Revised
6.4 SP-200622 WID NEW Approval New WID: Dynamic management of group-based event monitoring (TEI17). TSG SA Revision of SP-200455_Rev1. Approved Approved
6.4 SP-200465 WID NEW Approval New WID on Management data collection control and discovery. SA WG5 CC#2: Revisions suggested. Removed from Block approval. SP-200465_Rev1 was Approved at CC#3. Revised to SP-200623. Siemens kindly asks the owner of this document to add Siemens to the list of supporting individual members in clause 9.
There is a typo in the title of this WID ('New WID on Managemen data collection control and discovery' should read 'New WID on Management data collection control and discovery'). Please rectify.
The revision requests from Siemens, both correcting typos and adding Siemens as supporting company, have been addressed by the SA5 chair in SP-200465_rev1, together with two more editorial corrections, all shown with revision marks in the Word file.==== CC#3: SP-200465_Rev1. Approved. Revised to SP-200623 ====		 Revised
6.4 SP-200623 WID NEW Approval New WID on Management data collection control and discovery. TSG SA Revision of SP-200465_Rev1. Approved Approved
6.4 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=12 -
6.4 SP-200454 WID NEW Approval New WID: IP address pool information from UDM (TEI17). SA WG2 Resubmission of postponed SP-200087 from SP-87E Block approved Approved
6.4 SP-200456 WID NEW Approval New WID: Support of different slices over different Non 3GPP access (TEI17). SA WG2 Resubmission of postponed SP-200089 from SP-87E Block approved Approved
6.4 SP-200457 WID NEW Approval New WID: N7/N40 Interfaces Enhancements to Support GERAN and UTRAN (TEI17). SA WG2 Resubmission of postponed SP-200090 from SP-87E Block approved Approved
6.4 SP-200447 WID NEW Approval New WID on same PCF selection for AMF and SMF (TEI17_SPSFAS). SA WG2 Block approved Approved
6.4 SP-200448 WID NEW Approval New WID: System enhancement for Redundant PDU Session (TEI17_SE_RPS). SA WG2 Block approved Approved
6.4 SP-200348 WID NEW Approval New WID on Security Assurance Specification for Inter PLMN UP Security (IPUPS). SA WG3 Block approved Approved
6.4 SP-200398 WID NEW Approval New WID on Extension for headset interface tests of UE SA WG4 Block approved Approved
6.4 SP-200400 WID NEW Approval New WID on Removal of H.263 and MPEG-4 Visual from 3GPP Services SA WG4 Approved at CC#3 Approved
6.4 SP-200462 WID NEW Approval New WID on enhancements of 5G performance measurements and KPIs. SA WG5 Block approved Approved
6.4 SP-200463 WID NEW Approval New work item on management of the enhanced tenant concept . SA WG5 Block approved Approved
6.4 SP-200464 WID NEW Approval New WID on Autonomous network levels SA WG5 Block approved Approved
6.4 SP-200466 WID NEW Approval New WID on Enhancement of Handover Optimization. SA WG5 Block approved Approved
6.5 - - - Revised Release 17 Study Item and Work Item Descriptions - - Docs:=6 -
6.5 SP-200558 SID REVISED Approval Revised SID: Architectural enhancements for 5G multicast-broadcast services CBN, Huawei, Hisilicon, Qualcomm Incorporated Rel-17 Update to SP-200092. CC#2: Revisions suggested. Removed from Block approval. Rejected at CC#4 MediaTek requesting clarifications on the required workload (TU budget) for the proposed additional work, as well as on its technical scope.
Huawei give feedback regarding the workload and scope.
A proposal of this revised SID is out of scope of the endorsements in SP-191381 and SP-200225 .
Guillaume (MediaTek) requesting further clarification on the scope
Deutsche Telekom does not agree to revise the SID, as the Rel17 package was agreed in Dec19 at TSG #86 and it was a hard shuffle and delicate compromise. DT prefers to keep the Rel17 package as agreed also due to the difficulties to keep up the working speed due to e-meetings as a result of COVID19 issues.
CBN provides the business motivation and ongoing progress in RAN
Haris (Qualcomm) supports the SID update and propose revisions in drafts
Yusuke (KDDI) asks a question for clarification.
ZTE supports the update from Qualcomm and this should be studied in Rel-17 as there is clear requirements stated by CBN.
CBN answers Yusuke's (KDDI) question
EBU supports the SID update proposal from Qualcomm as this seems to be a balanced approach to cater for all issues that may arise in SA and its Working Groups.
Verizon does not agree to the SID revision. Verizon prefers to maintain the Release 17 scope as agreed after hard and difficult compromise among companies in TSG #86. Opening the scope at this late stage will only introduce risk to Release 17 which is already exacerbated by COVID-19.
CBN uploaded the new revision.
Haris (Qualcomm) comments on rev1 and indicates is not acceptable to Qualcomm		 Rejected
6.5 SP-200591 DISCUSSION Discussion otivation to Revise Architectural enhancements for 5G multicastbroadcast services CBN, ABS, ABP, EBU, IRT, Huawei Qualcomm Incorporated, Reliance Jio, ZTE LATE DOC: Rx 30/06 08:25. CC#2: Removed from Block approval. Noted at CC#3 Noted
6.5 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=4 -
6.5 SP-200444 SID REVISED Approval Revised SID: Study on System enhancement for Proximity based Services in 5GS (FS_5G_ProSe). SA WG2 Rel-17 Block approved Approved
6.5 SP-200445 WID REVISED Approval Change of rapporteur on WID 'Integration of satellite systems in the 5G architecture' (5GSAT_ARCH). SA WG2 Rel-17 Block approved Approved
6.5 SP-200519 WID REVISED Approval Revised WID: Stage 2 of Multimedia Priority Service (MPS) Phase 2. Perspecta Labs Rel-17 Revision of SP-200083 Block approved Approved
6.5 SP-200578 SID REVISED Approval Revised SID on FS_FRMCS3 SA WG1 Rel-17 Block approved Approved
6.6 - - - New Release 18 Study Item Descriptions - - Docs:=10 -
6.6 SP-200592 SID NEW Approval New SID on Study on Personal IoT Networks OPPO Rel-18 Proposed update of SP-200577. Approved at CC#3 Approved
6.6 SP-200577 SID NEW Approval New SID on Personal IoT Networks (FS_PIN) SA WG1 Rel-18 Proposed company revision in SP-200592. Noted at CC#3 Noted
6.6 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=8 -
6.6 SP-200335 SID NEW Approval New SID Study of Gateway UE function for Mission Critical Communication SA WG6 Block approved Approved
6.6 SP-200336 SID NEW Approval New SID Study of Interconnection and Migration Aspects for Railways SA WG6 Block approved Approved
6.6 SP-200571 SID NEW Approval New SID on Enhanced Access to and Support of Network Slice (FS_EASNS) SA WG1 Rel-18 Block approved Approved
6.6 SP-200572 SID NEW Approval New SID on Off-Network for Rail (FS_OffNetRail) SA WG1 Block approved Approved
6.6 SP-200573 SID NEW Approval New SID on 5G Timing Resiliency System (FS_5TRS) SA WG1 Rel-18 Block approved Approved
6.6 SP-200574 SID NEW Approval New SID on 5G Smart Energy and Infrastructure (FS_5GSEI) SA WG1 Rel-18 Block approved Approved
6.6 SP-200575 SID NEW Approval New SID on Ranging-based Services (FS_Ranging) SA WG1 Rel-18 Block approved Approved
6.6 SP-200576 SID NEW Approval New SID on Enhancements for Residential 5G (FS_Resident) SA WG1 Rel-18 Block approved Approved
6.7 - - - New Release 18 Work Item Descriptions - - Docs:=0 -
6.7 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=0 -
6.8 - - - Revised Release 18 Study Item Descriptions and Work Item Descriptions - - Docs:=0 -
6.8 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=0 -
6.9 - - - Specifications for Information - - Docs:=8 -
6.9 - - - Block 4: For block noting - Thursday July 2, 15:00 UTC - - Docs:=8 -
6.9 SP-200333 DRAFT TR Information Presentation of TR 23.764 v1.0.0 for information: Study on enhancements to application layer support for V2X services SA WG6 Rel-17 Block Noted Noted
6.9 SP-200334 DRAFT TR Information Presentation of TS 23.180 v1.0.0 for information: Mission Critical (MC) services support in the Isolated Operation for Public Safety (IOPS) mode of operation SA WG6 Rel-17 Block Noted Noted
6.9 SP-200377 DRAFT TR Information TR 33.853 'Key issues and potential solutions for Integrity protection of the user plane' SA WG3 Rel-16 Block Noted Noted
6.9 SP-200480 DRAFT TR Information TR 28.810 Study on concept, requirements and solutions for levels of autonomous network SA WG5 Rel-16 Block Noted Noted
6.9 SP-200481 DRAFT TS Information TS 28.201 Network Slice Performance and Analytics Charging in 5G System SA WG5 Rel-16 Wrong TS included. Revised to SP-200517 Revised
6.9 SP-200517 DRAFT TS Information TS 28.201 Network Slice Performance and Analytics Charging in 5G System SA WG5 Rel-16 Revision of SP-200481. Revised to SP-200518 Revised
6.9 SP-200518 DRAFT TS Information TS 28.201 Network Slice Performance and Analytics Charging in 5G System SA WG5 Rel-16 Revision of SP-200517. SP-200481 contained the wrong specification. SP-200517 didn't overwrite the current file in the server so this document contains version 1.0.1. Block Noted Noted
6.9 SP-200482 DRAFT TS Information TS 28.202 Charging management; Network slice management charging in the 5G System (5GS); Stage 2 SA WG5 Rel-16 Block Noted Noted
6.10 - - - Specifications for Approval / for Information and Approval - - Docs:=16 -
6.10 - - - Block 4: For block approval - Thursday July 2, 15:00 UTC - - Docs:=16 -
6.10 SP-200376 DRAFT TR Approval TR 33.861 'Study on evolution of Cellular IoT security for the 5G System' SA WG3 Rel-16 This is second presentation. Addition to coversheet: Changes since last presentation to SA Meeting: 'Additional key issues have been added and the documented key issues have been concluded. The normative phase is completed based on solutions in the TR and Approved
6.10 SP-200378 DRAFT TR Approval TR 33.935 'Detailed long term key update solutions' SA WG3 Rel-16 Block approved Approved
6.10 SP-200379 DRAFT TS Approval TS 33.536 'Security aspects of 3GPP support for advanced Vehicle-to-Everything (V2X) services' SA WG3 Rel-16 Block approved Approved
6.10 SP-200380 DRAFT TR Approval TR 33.836 'Study on Security Aspects of 3GPP support for Advanced V2X Services' SA WG3 Rel-16 Block approved Approved
6.10 SP-200381 DRAFT TS Approval TS 33.535 'Authentication and key management for applications based on 3GPP credentials in the 5G System (5GS)' SA WG3 Rel-16 Block approved Approved
6.10 SP-200382 DRAFT TR Approval TR 33.813 'Study on security aspects of network slicing enhancement' SA WG3 Rel-16 Block approved Approved
6.10 SP-200383 DRAFT TS Approval TS 33.434 'Service Enabler Architecture Layer (SEAL); Security aspects for Verticals' SA WG3 Rel-16 Block approved Approved
6.10 SP-200384 DRAFT TR Approval TR 33.855 'Study on security aspects of the 5G Service Based Architecture (SBA)' SA WG3 Rel-16 Block approved Approved
6.10 SP-200332 DRAFT TR Approval Presentation of TR 23.744 v2.0.0 for approval: Study into location enhancements for mission critical services SA WG6 Rel-17 Block approved. NOTE: This is a Release 17 TR which was allocated as Rel-16 due to a Work Plan error. Approved
6.10 SP-200404 DRAFT TS Approval Presentation of Specification to TSG SA: TS 26.511, Version 2.0.0 SA WG4 Rel-16 Block approved Approved
6.10 SP-200474 DRAFT TS Approval TS 28.307 Telecommunication management; Quality of Experience (QoE) measurement collection Integration Reference Point (IRP); Requirements SA WG5 Rel-16 Block approved Approved
6.10 SP-200475 DRAFT TS Approval TS 28.308 Telecommunication management; Quality of Experience (QoE) measurement collection Integration Reference Point (IRP); Information Service (IS) SA WG5 Rel-16 Block approved Approved
6.10 SP-200476 DRAFT TS Approval TS 28.405 Telecommunication management; Quality of Experience (QoE) measurement collection; Control and configuration SA WG5 Rel-16 Block approved Approved
6.10 SP-200477 DRAFT TS Approval TS 28.406 Telecommunication management; Quality of Experience (QoE) measurement collection; Information definition and transport SA WG5 Rel-16 Block approved Approved
6.10 SP-200478 DRAFT TS Approval TS 28.535 Management and orchestration; Management Services for Communication Service Assurance; Requirements SA WG5 Rel-16 Block approved Approved
6.10 SP-200479 DRAFT TS Approval TS 28.536 Management and orchestration; Management Services for Communication Service Assurance; Stage 2 and stage 3 SA WG5 Rel-16 Block approved Approved
7 - - - Release Planning - - Docs:=0 -
7.1 - - - General Release Planning issues - - Docs:=1 -
7.1 SP-200541 DISCUSSION Approval Voting and Elections in 3GPP Electronic Meetings TSG SA Chairman, TSG CT Chairman, TSG RAN Chairman Approved in CC#1 Approved
7.2 - - - Issues related to Release 16 and earlier planning (nothing expected here) - - Docs:=0 -
7.3 - - - Release 17 Planning (schedule, prioritization, etc.) - - Docs:=0 -
7.4 - - - Release 18 Planning (schedule, prioritization, etc.) - - Docs:=0 -
Block 5 - - - Block5: All CR-Packs in agenda items 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 and 18 for which no unresolved comments or unresolved revisions have been received by Thursday July 2 12:00 UTC will be makred approved on Thursday July 2 15:00 UTC. - - Docs:=0 -
8 - - - Rel-8 CRs - - Docs:=1 -
8 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=1 -
8 SP-200488 CR PACK Approval Rel-8 CRs on TEI SA WG5 Block approved Approved
9 - - - Rel-9 CRs - - Docs:=0 -
10 - - - Rel-10 CRs - - Docs:=0 -
11 - - - Rel-11 CRs - - Docs:=0 -
12 - - - Rel-12 CRs - - Docs:=3 -
12 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=3 -
12 SP-200387 CR PACK Approval CRs to Update the test vectors, Corrections of algorithmic description,EVS Fixed-Point Source Code and ch-aw-recv specification [EVS codec] SA WG4 26.444 CR0035 was withdrawn. CRs reissued in CR Packs SP-200386, SP-200396 and SP-200585 Revised
12 SP-200585 CR PACK Approval CRs to Update the test vectors [EVS codec] SA WG4 Reissue of 15 CRs from CR Pack SP-200387. 26.442 CR0037R1 was withdrawn as there is no Rel-16 TS for this mirror CR. All CRs except 26.442 CR0037R1 were Block approved. Partially approved Partially approved
12 SP-200487 CR PACK Approval Rel-12 CRs on TEI SA WG5 Block approved Approved
13 - - - Rel-13 CRs - - Docs:=1 -
13 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=1 -
13 SP-200360 CR PACK Approval Rel-13 CRs on Security of MCPTT SA WG3 Block approved Approved
14 - - - Rel-14 CRs - - Docs:=0 -
15 - - - Rel-15 CRs - - Docs:=24 -
15 SP-200529 CR Approval 23.502 CR2278R2 (Rel-15, 'F'): Correction on Deregistration procedures for SMS over NAS Nokia, Nokia Shanghai Bell Rel-15 Revision of S2-2003288 (23.502 CR2278R1) in CR Pack SP-200420. CC#3: For further discussion. Noted at CC#4 Wanqiang (Huawei) give some technical comments and request for revision or we just approve the original CR/discuss the other detailed stuff during August SA2 meeting.
Alessio(Nokia) provides comments
Shabnam (Ericsson) provides comments and draft revision
Alessio(Nokia) provides revision SP-200529_Rev1
Wanqiang(Huawei) provides further comments, and has different understanding regarding the deregistration handling.
Ericsson provides further comments, and questions if we have clear understanding to proceed with any of the revisions.		 Not pursued
15 SP-200420 CR PACK Approval CRs to 23.167, 23.501, 23.502 (5GS_Ph1, 5WWC, TEI15, Rel-15, Rel-16) SA WG2 Proposed revision of 23.502 CR2278R1 in SP-200529. CC#3: 23.502 CR2278R1 was postponed. All CRs, except 23.502 CR2278R1 in this CR Pack were approved. Partially approved Partially approved
15 SP-200530 DISCUSSION Decision SMS deregistration Nokia, Nokia Shanghai Bell Rel-16 CC#1: This is under discussion over e-mail. Noted at CC#3 Noted
15 SP-200598 CR Approval 33.501 CR0855 (Rel-15, 'F'): Clarification on SUPI definition Huawei, Hisilicon Rel-15 LATE DOC: Rx 29/06, 08:00. Response to the issue in SP-200548/549/550. CC#1: This can be handled on the Wed CC. Noted at CC#4 Haris (Qualcomm) comments that proposed CR revision does not solve the problem
Huawei replied if the encoding of SUPI type is not clear, then we fix that part. introducing two definition of SUPI is a bad idea.
Huawei provided SP-200598_Rev1 and SP-200599_Rev1
Huawei provided SP-200599_Rev2 for Rel-16 mirror CR to also include TR29.571.
Haris (Qualcomm) proposes options for way forward
Huawei replied Qualcomm' proposal of options for way forward and Huawei cannot agree a backward incompatible CR(as 0548,0549)/option2. As this issue can be solved by clarification instead of redefining the R15 specification. Huawei can only accept we based on option1(i.e. 0598rev1,0599rev2) for this meeting. If we cannot agree with option1, Huawei proposed to send LS to SA3 and CT4, and ask them to clarify encoding of SUPI.
Huawei proposes Rev2 for SP-200598
Huawei proposes SP-200598_Rev3 and Rev3 for SP-200599_Rev3.
Huawei replied Qualcomm's comment that we shall not mix the concept between SUPI and SUCI. They are for different purposes.		 Not pursued
15 SP-200599 CR Approval 33.501 CR0856 (Rel-16, 'A'): Clarification on SUPI definition Huawei, Hisilicon Rel-16 LATE DOC: Rx 29/06, 08:00. Noted at CC#4 Haris (Qualcomm) comments that proposed CR revision does not solve the problem
Huawei replied if the encoding of SUPI type is not clear, then we fix that part. introducing two definition of SUPI is a bad idea.
Huawei provided SP-200598_Rev1 and SP-200599_Rev1
Huawei provided SP-200599_Rev2 for Rel-16 mirror CR to also include TR29.571.
Huawei replied Qualcomm' proposal of options for way forward and Huawei cannot agree a backward incompatible CR(as 0548,0549)/option2. As this issue can be solved by clarification instead of redefining the R15 specification. Huawei can only accept we based on option1(i.e. 0598rev1,0599rev2) for this meeting. If we cannot agree with option1, Huawei proposed to send LS to SA3 and CT4, and ask them to clarify encoding of SUPI.
Huawei proposes Rev2 for SP-200598
Huawei proposes SP-200598_Rev3 and Rev3 for SP-200599_Rev3.		 Not pursued
15 SP-200548 DISCUSSION Agreement Clarification on the use of SUPI as the Identity in EAP-AKA' key derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, Ericsson, ZTE Rel-15 Noted at CC#4 Huawei: Current proposal brought a new definition of SUPI. And it is not a right way to solve the issue.
Nokia: In our opinion it is SA3's duty to specify how to derive EAP-AKA' keys. This is not something CT4 owns as suggested by Huawei. We suggest to put energy to resolve this issue during this plenary meeting to avoid any further delays on this Rel-15 issue.
SA3's responsibility is to define the content of the input of the key derivation. We defined the content is SUPI. SA3 did not define the format for IMSI or NAI. So it would be a little bit strange that SA3 define format of SUPI.
We are clear that what we need to decide is what SUPI type format we would like to use: digital string as 24.501 or character string as 29.571. for that I think CT has the best position to decide. I am ok if we can easily get conclusion which protocol we need use here but I guess it would be difficult also.
Curt (Charter) agrees that we should select one of the options (option 1 or 2) suggested by Qualcomm and 3GPP should not accept the other option that will create inter-operability issue in the ecosystem.
Haris (Qualcomm) proposes options for way forward
Samsung supports Option 1 proposed by Qualcomm and does not agree to leave the interportability issue unaddressed in Rel-15 and Rel-16. This inter-operability issue needs to be address in this SA plenary or in the upcoming SA3 meeting. We strongly support 0549 and 0550, as it is in-line with the specified usage of SUPI (c.f A.7.0)
Intel supports Qualcomm's proposal to agree either of the two options in this SA plenary.
Huawei proposes options for way forward.
Haris (Qualcomm) comments on Huawei proposal
Huawei replied on Qualcomm's comments
Deutsche Telekom agrees that there needs to be only one option approved to avoid interoperability problems, regardless which option is taken.
Intel comments on the way forward.
Jinguo(ZTE) supports option 2 in Haris' wording
Miikka (Nokia) comments way forward
Huawei replied Qualcomm' proposal of options for way forward and sustained objection of a backward incompatible CR(as 0548,0549)/option2. As this issue can be solved by clarification instead of redefining the R15 specification. Huawei can only accept option1 for this meeting. If we cannot agree with option1, Huawei proposed to send LS to SA3 and CT4, and ask them to clarify encoding of SUPI.
In our understanding the crux of the debate is whether Annex F.3 will be clarified by stating explicitly in 33.501 what value the 'Identity' can take or whether this should be done by referring to other specifications. Proposing a way forward.
Huawei is ok to take Option E1 as Intel proposed it is also a correction and solve the issue.
Haris (Qualcomm) proposes revision
Miikka (Nokia) re-iterates urgency to resolve this issue during this meeting as this is FASMO and may prevent UEs to access 5GS.
Ericsson agree that we have to make a decision in this plenary meeting. SA3 meeting had a large group of companies supporting the QC way forward so Ericsson support that to resolve the urgent Rel-15 CR.
Huawei provide SP-200614 for discussion on the options of SUPI issue.
Saso (Intel) comments on the revision
Jinguo(ZTE) provides more comments and supports option 2 from Qualcomm.
Huawei replied to ZTE's comment
Samsung agrees we must choose either option 1 or 2 at this meeting. Samsung prefers option 2.
Haris (Qualcomm) provides 0550 (rev2) according to comments
Saso (Intel) comments on 0550_rev1 (rel.16)
Haris (Qualcomm) provides 0549_rev2 (rel.15) and 0550_rev1 (rel.16)
Krisztian (Apple) supports to make a decision on this topic in SA#88-e and proposes to choose 0549_rev2 and 0550_rev2.		 Noted
15 SP-200549 CR Approval 33.501 CR0761R2 (Rel-15, 'F'): Clarification on the use of SUPI as the Identity in EAP-AKA' key derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, ZTE, Ericsson, Samsung Rel-15 Revision of S3-201272 (not pursued at SA3#99-e). CC#4: SP-200549_Rev2 was Approved. MCC will clean up changes on changes. Revised to SP-200629. Huawei: Current proposal brought a new definition of SUPI. And it is not a right way to solve the issue.
Nokia: In our opinion it is SA3's duty to specify how to derive EAP-AKA' keys. This is not something CT4 owns as suggested by Huawei. We suggest to put energy to resolve this issue during this plenary meeting to avoid any further delays on this Rel-15 issue.
SA3's responsibility is to define the content of the input of the key derivation. We defined the content is SUPI. SA3 did not define the format for IMSI or NAI. So it would be a little bit strange that SA3 define format of SUPI.
We are clear that what we need to decide is what SUPI type format we would like to use: digital string as 24.501 or character string as 29.571. for that I think CT has the best position to decide. I am ok if we can easily get conclusion which protocol we need use here but I guess it would be difficult also.
Haris (Qualcomm) proposes options for way forward
Curt (Charter) agrees that we should select one of the options (option 1 or 2) suggested by Qualcomm and 3GPP should not accept the other option that will create inter-operability issue in the ecosystem.
Samsung supports Option 1 proposed by Qualcomm and does not agree to leave the interportability issue unaddressed in Rel-15 and Rel-16. This inter-operability issue needs to be address in this SA plenary or in the upcoming SA3 meeting. We strongly support 0549 and 0550, as it is in-line with the specified usage of SUPI (c.f A.7.0)
Intel supports Qualcomm's proposal to agree either of the two options in this SA plenary.
Huawei proposes options for way forward.
Haris (Qualcomm) comments on Huawei proposal
Huawei replied on Qualcomm's comments
Deutsche Telekom agrees that there needs to be only one option approved to avoid interoperability problems, regardless which option is taken.
Intel comments on the way forward.
Miikka (Nokia) comments way forward
Huawei replied Qualcomm' proposal of options for way forward and sustained objection of a backward incompatible CR(as 0548,0549)/option2. As this issue can be solved by clarification instead of redefining the R15 specification. Huawei can only accept option1 for this meeting. If we cannot agree with option1, Huawei proposed to send LS to SA3 and CT4, and ask them to clarify encoding of SUPI.
In our understanding the crux of the debate is whether Annex F.3 will be clarified by stating explicitly in 33.501 what value the 'Identity' can take or whether this should be done by referring to other specifications. Proposing a way forward.
Huawei is ok to take Option E1 as Intel proposed it is also a correction and solve the issue.
Haris (Qualcomm) proposes revision
Miikka (Nokia) re-iterates urgency to resolve this issue during this meeting as this is FASMO and may prevent UEs to access 5GS.
Ericsson agree that we have to make a decision in this plenary meeting. SA3 meeting had a large group of companies supporting the QC way forward so Ericsson support that to resolve the urgent Rel-15 CR.
Huawei provide SP-200614 for discussion on the options of SUPI issue.
Saso (Intel) comments on the revision
Huawei replied to ZTE's comment
Samsung agrees we must choose either option 1 or 2 at this meeting. Samsung prefers option 2.
Haris (Qualcomm) provides 0549_rev2 (rel.15) and 0550_rev1 (rel.16)
Saso (Intel) comments on 0550_rev1 (rel.16)
Haris (Qualcomm) provides 0550 (rev2) according to comments
Krisztian (Apple) supports to make a decision on this topic in SA#88-e and proposes to choose 0549_rev2 and 0550_rev2.		 Revised
15 SP-200629 CR Approval 33.501 CR0761R3 (Rel-15, 'F'): Clarification on the use of SUPI as the Identity in EAP-AKA' key derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, ZTE, Ericsson, Samsung Rel-15 Revision of SP-200549_Rev2. This CR was approved Approved
15 SP-200550 CR Approval 33.501 CR0762R2 (Rel-16, 'A'): Clarification on the use of SUPI as the Identity in EAP-AKA' key derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, ZTE, Ericsson, Samsung Rel-16 Revision of S3-201273 (not pursued at SA3#99-e). CC#4: SP-200550_Rev2 was Approved. Revised to SP-200630. Huawei: Current proposal brought a new definition of SUPI. And it is not a right way to solve the issue.
Nokia: In our opinion it is SA3's duty to specify how to derive EAP-AKA' keys. This is not something CT4 owns as suggested by Huawei. We suggest to put energy to resolve this issue during this plenary meeting to avoid any further delays on this Rel-15 issue.
SA3's responsibility is to define the content of the input of the key derivation. We defined the content is SUPI. SA3 did not define the format for IMSI or NAI. So it would be a little bit strange that SA3 define format of SUPI.
We are clear that what we need to decide is what SUPI type format we would like to use: digital string as 24.501 or character string as 29.571. for that I think CT has the best position to decide. I am ok if we can easily get conclusion which protocol we need use here but I guess it would be difficult also.
Haris (Qualcomm) proposes options for way forward
Curt (Charter) agrees that we should select one of the options (option 1 or 2) suggested by Qualcomm and 3GPP should not accept the other option that will create inter-operability issue in the ecosystem.
Samsung supports Option 1 proposed by Qualcomm and does not agree to leave the interportability issue unaddressed in Rel-15 and Rel-16. This inter-operability issue needs to be address in this SA plenary or in the upcoming SA3 meeting. We strongly support 0549 and 0550, as it is in-line with the specified usage of SUPI (c.f A.7.0)
Intel supports Qualcomm's proposal to agree either of the two options in this SA plenary.
Huawei proposes options for way forward.
Haris (Qualcomm) comments on Huawei proposal
Huawei replied on Qualcomm's comments
Deutsche Telekom agrees that there needs to be only one option approved to avoid interoperability problems, regardless which option is taken.
Intel comments on the way forward.
Miikka (Nokia) comments way forward
Jinguo(ZTE) supports option 2 in Haris' wording
Huawei replied Qualcomm' proposal of options for way forward and sustained objection of a backward incompatible CR(as 0548,0549)/option2. As this issue can be solved by clarification instead of redefining the R15 specification. Huawei can only accept option1 for this meeting. If we cannot agree with option1, Huawei proposed to send LS to SA3 and CT4, and ask them to clarify encoding of SUPI.
In our understanding the crux of the debate is whether Annex F.3 will be clarified by stating explicitly in 33.501 what value the 'Identity' can take or whether this should be done by referring to other specifications. Proposing a way forward.
Huawei is ok to take Option E1 as Intel proposed it is also a correction and solve the issue.
Haris (Qualcomm) proposes revision
Miikka (Nokia) re-iterates urgency to resolve this issue during this meeting as this is FASMO and may prevent UEs to access 5GS.
Ericsson agree that we have to make a decision in this plenary meeting. SA3 meeting had a large group of companies supporting the QC way forward so Ericsson support that to resolve the urgent Rel-15 CR.
Huawei provide SP-200614 for discussion on the options of SUPI issue.
Saso (Intel) comments on the revision
Huawei replied to ZTE's comment
Samsung agrees we must choose either option 1 or 2 at this meeting. Samsung prefers option 2.
Haris (Qualcomm) provides 0549_rev2 (rel.15) and 0550_rev1 (rel.16)
Saso (Intel) comments on 0550_rev1 (rel.16)
Haris (Qualcomm) provides 0550 (rev2) according to comments
Krisztian (Apple) supports to make a decision on this topic in SA#88-e and proposes to choose 0549_rev2 and 0550_rev2.		 Revised
15 SP-200630 CR Approval 33.501 CR0762R3 (Rel-16, 'A'): Clarification on the use of SUPI as the Identity in EAP-AKA' key derivation Qualcomm Incorporated, Nokia, Nokia Shanghai Bell, ZTE, Ericsson, Samsung Rel-16 Revision of SP-200550_Rev2. This CR was approved Approved
15 SP-200614 DISCUSSION Decision Combined options for EAP-AKA’ SUPI issue Huawei, Hisilicon Left for further discussion at CC#3. A working agreement will be declared to go with Option 2. Noted at CC#4 MCC have allocated SP-200614 for presentation to CC#3.
 Noted
15 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=13 -
15 SP-200421 CR PACK Approval CRs to 23.401 (NB_IOTenh-Core, CIoT_Ext, Rel-15, Rel-16) SA WG2 Block approved Approved
15 SP-200357 CR PACK Approval Rel-15 CRs on Security Assurance Specification for eNB network product class SA WG3 Block approved Approved
15 SP-200361 CR PACK Approval Rel-15 CRs on MC Security Enhancements SA WG3 Block approved Approved
15 SP-200370 CR PACK Approval Rel-15 CRs on Security aspects of 5G System - Phase 1 SA WG3 Block approved Approved
15 SP-200390 CR PACK Approval CRs to Correction on Partial File Handling [eDASH,TEI15] SA WG4 Block approved Approved
15 SP-200486 CR PACK Approval Rel-15 CRs on TEI SA WG5 Block approved Approved
15 SP-200491 CR PACK Approval Rel-15 CRs on Network Resource Model (NRM) for 5G networks and network slicing SA WG5 Block approved Approved
15 SP-200492 CR PACK Approval Rel-15 CRs on Performance Assurance for 5G networks including network slicing SA WG5 Block approved Approved
15 SP-200498 CR PACK Approval Rel-15 CRs on Provisioning of network slicing for 5G networks and services SA WG5 Block approved Approved
15 SP-200499 CR PACK Approval Rel-15 CRs on Management and orchestration of 5G networks and network slicing SA WG5 Block approved Approved
15 SP-200501 CR PACK Approval Rel-15 CRs on Fault Supervision for 5G networks and network slicing SA WG5 Block approved Approved
15 SP-200504 CR PACK Approval Rel-15 CRs on REST Solution Sets (normative work) SA WG5 Block approved Approved
15 SP-200510 CR PACK Approval Rel-15 CRs on Service Based Interface for 5G Charging SA WG5 Block approved Approved
16 - - - Rel-16 CRs - - Docs:=0 -
16.1 - - - SA WG1 Rel-16 CRs - - Docs:=4 -
16.1 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=4 -
16.1 SP-200560 CR PACK Approval SA WG1 CRs on MONASTERY2 SA WG1 Rel-16 Block approved Approved
16.1 SP-200561 CR PACK Approval SA WG1 CRs on SMARTER_Ph2 SA WG1 Rel-16 Block approved Approved
16.1 SP-200562 CR PACK Approval SA WG1 CRs on cyberCAV SA WG1 Rel-16 Block approved Approved
16.1 SP-200563 CR PACK Approval SA WG1 CRs on TEI16 SA WG1 Rel-16 Block approved Approved
16.2 - - - SA WG2 Rel-16 CRs - - Docs:=37 -
16.2 SP-200516 CR Approval 23.502 CR2317R1 (Rel-16, 'F'): Clarification on Registration with AMF re-allocation ZTE Rel-16 Revision of S2-2003814 (23.502 CR2317, noted at S2#139-e). CC#1: Ericsson asked for more time to review this new CR. Postponed at CC#3 Haris (Qualcomm) suggests this CR to be discussed in SA2
Jinguo(ZTE) response to Haris and provide rev1.
Shabnam (Ericsson) supports Qualcomm, this CR to be discussed in SA2 first		 Postponed
16.2 SP-200515 CR Approval 23.501 CR2230R2 (Rel-16, 'F'): Spliting port management information into port- and bridge-specific information Intel, Samsung, Nokia, Nokia Shanghai Bell, Ericsson, NTT DOCOMO, vivo, ZTE, Qualcomm Incorporated Rel-16 Revision of S2-2003260 (23.501 CR2230R1) in CR Pack SP-200438. Approved at CC#1 Approved
16.2 SP-200438 CR PACK Approval CRs to 23.501 (Vertical_LAN, Rel-16) SA WG2 Proposed revision of 23.501 CR2230R1 in SP-200515. CC#1: All CRs except 23.501 CR2230R1 were approved Partially approved
16.2 SP-200527 CR Approval 23.502 CR2219R2 (Rel-16, 'F'): Update PDU Session release when Control Plane Only indication is not applicable Intel, OPPO, Nokia, Nokia Shanghai Bell, Interdigital Rel-16 Revision of S2-2003462 (23.502 CR2219R1) in CR Pack SP-200422. Source to TSG incorrect. CC#1: SP-200527_rev1 was approved. Revised to SP-200609. Alessio(Nokia): this should be used as basis for discussion as the uploaded CRs in SP-200527 and SP200528 have received further offline comments (some editorial and some related to covering aspects from another approved SA2 CR on release of PDU sessions when S-NSSAI is no longer available)
Alessio(Nokia): provides SP-200527r01		 Revised
16.2 SP-200609 CR Approval 23.502 CR2219R3 (Rel-16, 'F'): Update PDU Session release when Control Plane Only indication is not applicable Intel, OPPO, Nokia, Nokia Shanghai Bell, Interdigital Rel-16 Revision of SP-200527_rev1. This CR was Approved Approved
16.2 SP-200528 CR Approval 23.501 CR2361R2 (Rel-16, 'F'): PDU Session release when Control Plane Only indication is not available Interdigital Inc., Nokia, Nokia Shanghai Bell Rel-16 Revision of S2-2003463 (23.501 CR2361R1) in CR Pack SP-200422. Source to TSG incorrect. Approved at CC#1. Revised to SP-200610. Alessio(Nokia): provides SP-200528r01
Alessio(Nokia): this should be used as basis for discussion as the uploaded CRs in SP-200527 and SP200528 have received further offline comments (some editorial and some related to covering aspects from another approved SA2 CR on release of PDU sessions when S-NSSAI is no longer available)		 Revised
16.2 SP-200610 CR Approval 23.501 CR2361R3 (Rel-16, 'F'): PDU Session release when Control Plane Only indication is not available Interdigital Inc., Nokia, Nokia Shanghai Bell Rel-16 Revision of SP-200528_Rev1. This CR was approved Approved
16.2 SP-200422 CR PACK Approval CRs to 23.273, 23.501, 23.502, 23.503 (5G_CIoT, Rel-16) SA WG2 Proposed revision of 23.502 CR2219R1 in SP-200527 and 23.501 CR2361R1 in SP-200528. CC#1: All CRs except 23.502 CR2219R1 and 23.501 CR2361R1 were approved. Partially approved
16.2 SP-200589 CR Approval 23.503 CR0472R1 (Rel-16, 'F'): Update about Alternative QoS Profile Huawei, HiSilicon, China Mobile, Telecom Italia, British Telecom, KPN, Orange, Vodafone, China Unicom Rel-16 Proposed replacement of 23.503 CR0472 in CR Pack SP-200425. Noted at CC#4 Huawei replies to Qualcomm's questions.
Huawei asks technical questions following the discussion in the GTM call.
Haris (Qualcomm) objects to SP-200588, SP-200589
Johannes (Deutsche Telekom AG) objects to SP-200588, SP-200589 as this would need to be re-aligned with RAN working groups and the changes are late for inclusion in Rel16, especially in RAN.
Nokia: Nokia objects to SP-200588, SP-200589.
Ericsson: Ericsson objects to SP-200588, SP-200589 and proposed to approve original submitted CRs from SA2.
LaeYoung (LGE) proposes to NOTE SP-200588 and SP-200589, and to approve original submitted CRs from SA2. We don't think the LS SP-200590 is needed.
Jinguo(ZTE) proposes to NOTE SP-200588 and SP-200589, and to approve original submitted CRs from SA2. We don't think the LS SP-200590 is needed.
Vodafone: Vodafone finds it unreasonable that major vendors have systematically blocked functionality (proposed as part of V2X work) to enable handover to work properly. Vehicles clearly move between cells!! As a compromise way forward, it is suggested that SA request SA2 and RAN 3 to address the handover topic under TEI-17.
Huawei replies to comments by ZTE, LGE, E///, Nokia, DT and QC.
If SP-200588/ SP-200589 cannot be approved then Telecom Italia supports the compromise offered by Huawei to send out a LS, as in SP-200590_rev1, to task SA2 to study the need for adding ARP and MDBV in the AQP.
Huawei provides LS out S2-200590_rev2
Vodafone is OK with S2-200590_rev2 but fear that it will be blocked by other companies. As a potential compromise and way forward Vodafone propose that 'TSG-SA request that the problem of GBR flows being released when a congested site is encountered is resolved under TEI-17 (or R17 V2X) in SA2 and RAN 3'. Vodafone request comments on this way forward.
LaeYoung (LGE) provides an updated version of LS Out SP-200590 in the Drafts folder while taking the WF suggestion by Chris (Vodafone) into account.
Dario (Huawei) replies to Qualcomm and LGE.
Ericsson provides LS revision in rev2_Ericsson, proposes to approve Rel-16 CRs submitted by SA2 aligned with RAN3.
Dario (Huawei) replies to Ericsson and provides LS rev3
Ericsson comments that as the discussion and problem statement indicates, RAN needs to do their part first before SA2 spends more time on this.
Siemens provides LS rev4 in the Drafts folder. The LS was edited for readability.
Nokia provides comment and a proposal to move on.
Dario (Huawei) provides LS rev5
Huawei provides LS out rev6 (based on rev2_E/// with minor editorial changes) and rev7 (cleaned version of rev6)		 Not pursued
16.2 SP-200425 CR PACK Approval CRs to 23.501, 23.502, 23.503 (5G_URLLC, Rel-16) SA WG2 Proposed revision of 23.503 CR0487 in SP-200589. Approved at CC#4 Approved
16.2 SP-200586 DISCUSSION Agreement Discussion of SA WG2 CR on PDU session establishment with no S-NSSAI Samsung R&D Institute UK Rel-16 Suggests not approving 23.502 CR2203R1 in SP-200551. Noted at CC#4 Susana (Vodafone) proposes to take rev2 of CR 2203r1 in SP-200551, submitted by Samsung, to address this discussion. There would be no need then to return CR 2203r1 to SA2
Alessio (Nokia) Nokia requests Vodafone AND Samsung that for a revision to be considered at SA#88 of the SA2 agreed CRs an explanation is required. There has been NO explanation why the very clear text is proposed to be removed.
Andy (Samsung) responds to Nokia, repeating the explanation already provided.
Alessio(Nokia) clarifies the reason why the first explanation was not satisfactory and reason why we asked for a reason again: At SA we should fix technically incorrect text, not implement wording preferences. So the question was: is there a technical issue in the existing text?
Tricci (ZTE) support Nokia's comment to keep SA2's CR as-is.
Susana (Vodafone) clarifies that the wording in the original CR has raised concerns as it may enable error cases to proceed (e.g. in case of a wrong S-NSSAI as the only entry in the current Allowed NSSAI or not allowing the DNN requested). For operators, it is important to facilitate testing of specifications and avoid potential errors be hidden by poor text. It is Vodafone understanding that the revised CR does not change the technical/functional behavior intended by the authors of the original CR.
Patrice (Huawei) wonders how the proposed draft revision can be considered clearer.
alessio(Nokia) Fully supports Huawei.
Susana (Vodafone) comments
Krisztian (Apple) supports Huawei's comments and suggests to approve TS 23.502 CR 2203r1 as agreed in SA2.
Alessio(Nokia) Notes Vodafone is not bringing to the table a real issue (i.e. there is no issue to be solved, the SA2 CR is correct)
Tricci (ZTE) supports Patrice (Huawei) and Alessio (Nokia) technical justification.
Susana (Vodafone) proposes to hold the discussion in the stage 3 group (CT1) and formalise alignment in SA2 once resolved. 3GPP shall produce quality specifications, not to base the behaviour of the network in faith.
Andy (Samsung) explains the real issue that is created by the CR.
Alessio(Nokia) Samsung is incorrect
Tricci (ZTE) support Nokia's understandings which are according to today TS 23.501 specification.
Patrice (Huawei) corrects the understanding of Andy (Samsung).
Haris (Qualcomm) support views from Nokia and ZTE
Andy (Samsung) responds to Patrice (Huawei) to Stage 3 descriptions of the situation.
Ericsson support views from Nokia, Huawei and ZTE and others that original CR submitted by SA2 is correct and proposes to approve the CR.
Alessio(Nokia) clarifies all is ok. But really why are we now discussing the stage 3 as the quoted text is not contradicting at all the SA2 CR nor it is related to the content of the SA2 CR as the SA2 CR is about the network side and this stage 3 text is about the UE side. Looks like the discussion is going off on a tangent now.
Andy (Samsung) points out that all is not OK because the text says 'Any missing information in the UE local configuration needed to build the PDU session establishment request can be the appropriate corresponding component from the default URSP rule with the 'match-all' traffic descriptor'
China Mobile also support to keep SA2's CR as-is		 Noted
16.2 SP-200607 CR Approval 23.401 CR3602R2 (Rel-16, 'B'): Alignment CR for DAPS HO Qualcomm Incorporated Rel-16 Proposed revision of 23401 CR3602r1 in CR Pack SP-200551. This CR was approved. 23401 CR3602r1 in SP-200551 should be noted. This CR was approved at CC#4 Haris (Qualcomm): proposes revision SP-200607 Approved
16.2 SP-200613 CR Approval 23.502 CR2203R2 (Rel-16, 'F'): Clarification on PDU session establishment without S-NSSAI indication Samsung Rel-16 Proposed revision of 23502 CR2203r1 in CR Pack SP-200551. Noted at CC#4 Not pursued
16.2 SP-200426 CR PACK Approval CRs to 23.401, 23.501, 23.502, 23.503 (5GS_Ph1, TEI16, Rel-16) SA WG2 CRs resissued in SP-200551 Revised
16.2 SP-200551 CR PACK Approval CRs to 23.401, 23.501, 23.502, 23.503 (5GS_Ph1, TEI16, Rel-16) SA WG2 Update of SP-200426 to correct some WI Codes to add TEI16. SP-200586 suggests not approving 23.502 CR2203R1. Proposed revision of 23401 CR3602r1 in SP-200607. Proposed revision of 23502 CR2203r1 in SP-200613. Partially approved Haris (Qualcomm): this TS 23.401 contains inappropriate 5GS terms (NG-RAN instead of eNodeB, AMF instead of MME)
MCC allocated a new document for revision of 23401 CR3602r1 in SP-200607
Andy (Samsung): Revision proposed based on suggestion on SA2 discussions email list.
Alessio(Nokia): can Andy clarify what is not clear in text that is removed :' If there is only one S-NSSAI in the Allowed NSSAI, this S-NSSAI shall be used. If there is more than one S-NSSAI in the Allowed NSSAI,...'
Andy (Samsung): Response to Nokia to clarify why the text is removed.
Andy (Samsung): The intended revision proposed based on suggestion on SA2 discussions email list.
Alessio(Nokia): not satisfied with reason provided.		 Partially approved
16.2 SP-200588 CR Approval 23.501 CR2370R2 (Rel-16, 'F'): Alignment on Alternative QoS Profile Huawei, HiSilicon, China Mobile, Telecom Italia, British Telecom, KPN, Orange, Vodafone, China Unicom Rel-16 Proposed replacement of 23.501 CR2370R1 in CR Pack SP-200434. Noted at CC#4 Huawei replies to Qualcomm's questions.
Huawei asks technical questions following the discussion in the GTM call.
Haris (Qualcomm) objects to SP-200588, SP-200589
Johannes (Deutsche Telekom AG) objects to SP-200588, SP-200589 as this would need to be re-aligned with RAN working groups and the changes are late for inclusion in Rel16, especially in RAN.
Nokia: Nokia objects to SP-200588, SP-200589.
Ericsson: Ericsson objects to SP-200588, SP-200589 and proposed to approve original submitted CRs from SA2.
LaeYoung (LGE) proposes to NOTE SP-200588 and SP-200589, and to approve original submitted CRs from SA2. We don't think the LS SP-200590 is needed.
Jinguo(ZTE) proposes to NOTE SP-200588 and SP-200589, and to approve original submitted CRs from SA2. We don't think the LS SP-200590 is needed.
Vodafone: Vodafone finds it unreasonable that major vendors have systematically blocked functionality (proposed as part of V2X work) to enable handover to work properly. Vehicles clearly move between cells!! As a compromise way forward, it is suggested that SA request SA2 and RAN 3 to address the handover topic under TEI-17.
Huawei replies to comments by ZTE, LGE, E///, Nokia, DT and QC.
If SP-200588/ SP-200589 cannot be approved then Telecom Italia supports the compromise offered by Huawei to send out a LS, as in SP-200590_rev1, to task SA2 to study the need for adding ARP and MDBV in the AQP.
Huawei provides LS out S2-200590_rev2
Vodafone is OK with S2-200590_rev2 but fear that it will be blocked by other companies. As a potential compromise and way forward Vodafone propose that 'TSG-SA request that the problem of GBR flows being released when a congested site is encountered is resolved under TEI-17 (or R17 V2X) in SA2 and RAN 3'. Vodafone request comments on this way forward.
LaeYoung (LGE) provides an updated version of LS Out SP-200590 in the Drafts folder while taking the WF suggestion by Chris (Vodafone) into account.
Dario (Huawei) replies to Qualcomm and LGE.
Ericsson provides LS revision in rev2_Ericsson, proposes to approve Rel-16 CRs submitted by SA2 aligned with RAN3.
Dario (Huawei) replies to Ericsson and provides LS rev3
Ericsson comments that as the discussion and problem statement indicates, RAN needs to do their part first before SA2 spends more time on this.
Siemens provides LS rev4 in the Drafts folder. The LS was edited for readability.
Nokia provides comment and a proposal to move on.
Dario (Huawei) provides LS rev5
Huawei provides LS out rev6 (based on rev2_E/// with minor editorial changes) and rev7 (cleaned version of rev6)		 Not pursued
16.2 SP-200434 CR PACK Approval CRs to 23.285, 23.287, 23.501, 23.502, 23.503 (eV2XARC, Rel-16) SA WG2 Proposed revision of 23.501 CR2370R1 in SP-200588. Approved at CC#4 Approved
16.2 SP-200594 CR Approval 23.503 CR0451R2 (Rel-16, 'F'): URSP info provision for xBDT Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, ZTE Rel-16 Proposed revision of 23.503 CR0451R1 in CR Pack SP-200440. Approved at CC#1 Approved
16.2 SP-200440 CR PACK Approval CRs to 23.502, 23.503 (xBDT, Rel-16) SA WG2 Proposed revision of 23.503 CR0451R1 in SP-200594. CC#1: All CRs except 23.503 CR0451R1 were approved. Partially approved
16.2 SP-200587 DISCUSSION Approval Discussion on way forward for content of Alternative QoS Profiles Huawei, HiSilicon, China Mobile, Telecom Italia, British Telecom, KPN, Orange Vodafone, China Unicom Rel-16 Noted at CC#4 Huawei replies to Qualcomm's questions.
Huawei asks technical questions following the discussion in the GTM call.
Huawei proposes LS out SP-200590_rev1
Jinguo(ZTE) proposes to NOTE SP-200588 and SP-200589, and to approve original submitted CRs from SA2. We don't think the LS SP-200590 is needed.
LaeYoung (LGE) proposes to NOTE SP-200588 and SP-200589, and to approve original submitted CRs from SA2. We don't think the LS SP-200590 is needed.
Ericsson: Ericsson objects to SP-200588, SP-200589 and proposed to approve original submitted CRs from SA2.
Nokia: Nokia objects to SP-200588, SP-200589.
Johannes (Deutsche Telekom AG) objects to SP-200588, SP-200589 as this would need to be re-aligned with RAN working groups and the changes are late for inclusion in Rel16, especially in RAN.
Haris (Qualcomm) objects to SP-200588, SP-200589
Vodafone: Vodafone finds it unreasonable that major vendors have systematically blocked functionality (proposed as part of V2X work) to enable handover to work properly. Vehicles clearly move between cells!! As a compromise way forward, it is suggested that SA request SA2 and RAN 3 to address the handover topic under TEI-17.
Huawei replies to comments by ZTE, LGE, E///, Nokia, DT and QC.
If SP-200588/ SP-200589 cannot be approved then Telecom Italia supports the compromise offered by Huawei to send out a LS, as in SP-200590_rev1, to task SA2 to study the need for adding ARP and MDBV in the AQP.
Huawei provides LS out S2-200590_rev2
LaeYoung (LGE) provides an updated version of LS Out SP-200590 in the Drafts folder while taking the WF suggestion by Chris (Vodafone) into account.
Vodafone is OK with S2-200590_rev2 but fear that it will be blocked by other companies. As a potential compromise and way forward Vodafone propose that 'TSG-SA request that the problem of GBR flows being released when a congested site is encountered is resolved under TEI-17 (or R17 V2X) in SA2 and RAN 3'. Vodafone request comments on this way forward.
Dario (Huawei) replies to Qualcomm and LGE.
Chris (Vodafone): that updated version of LS Out SP-200590 in the Drafts folder from LGE is a good way to document my WF suggestion.
Dario (Huawei) replies to Qualcomm.
Ericsson provides LS revision in rev2_Ericsson, proposes to approve Rel-16 CRs submitted by SA2 aligned with RAN3.
Dario (Huawei) replies to Ericsson and provides LS rev3
Ericsson comments that as the discussion and problem statement indicates, RAN needs to do their part first before SA2 spends more time on this.
Siemens provides LS rev4 in the Drafts folder. The LS was edited for readability.
Nokia provides comment and a proposal to move on.
Dario (Huawei) provides LS rev5
Huawei provides LS out rev6 (based on rev2_E/// with minor editorial changes) and rev7 (cleaned version of rev6)		 Noted
16.2 SP-200590 LS OUT Approval [DRAFT] LS on Alternative QoS Profile Huawei Rel-16 Companies were asked to provide clear proposals for this to be discussed in CC#4. CC#4: SP-200590_Rev10 was approved. Revised to SP-200631. Huawei replies to Qualcomm's questions.
Huawei asks technical questions following the discussion in the GTM call.
Haris (Qualcomm) objects to SP-200588, SP-200589
Johannes (Deutsche Telekom AG) objects to SP-200588, SP-200589 as this would need to be re-aligned with RAN working groups and the changes are late for inclusion in Rel16, especially in RAN.
Nokia: Nokia objects to SP-200588, SP-200589.
Ericsson: Ericsson objects to SP-200588, SP-200589 and proposed to approve original submitted CRs from SA2.
LaeYoung (LGE) proposes to NOTE SP-200588 and SP-200589, and to approve original submitted CRs from SA2. We don't think the LS SP-200590 is needed.
Jinguo(ZTE) proposes to NOTE SP-200588 and SP-200589, and to approve original submitted CRs from SA2. We don't think the LS SP-200590 is needed.
Vodafone: Vodafone finds it unreasonable that major vendors have systematically blocked functionality (proposed as part of V2X work) to enable handover to work properly. Vehicles clearly move between cells!! As a compromise way forward, it is suggested that SA request SA2 and RAN 3 to address the handover topic under TEI-17.
Huawei replies to comments by ZTE, LGE, E///, Nokia, DT and QC.
If SP-200588/ SP-200589 cannot be approved then Telecom Italia supports the compromise offered by Huawei to send out a LS, as in SP-200590_rev1, to task SA2 to study the need for adding ARP and MDBV in the AQP.
Huawei provides LS out S2-200590_rev2
Vodafone is OK with S2-200590_rev2 but fear that it will be blocked by other companies. As a potential compromise and way forward Vodafone propose that 'TSG-SA request that the problem of GBR flows being released when a congested site is encountered is resolved under TEI-17 (or R17 V2X) in SA2 and RAN 3'. Vodafone request comments on this way forward.
LaeYoung (LGE) provides an updated version of LS Out SP-200590 in the Drafts folder while taking the WF suggestion by Chris (Vodafone) into account.
Dario (Huawei) replies to Qualcomm and LGE.
Ericsson provides LS revision in rev2_Ericsson, proposes to approve Rel-16 CRs submitted by SA2 aligned with RAN3.
Dario (Huawei) replies to Ericsson and provides LS rev3
Ericsson comments that as the discussion and problem statement indicates, RAN needs to do their part first before SA2 spends more time on this.
Siemens provides LS rev4 in the Drafts folder. The LS was edited for readability.
Nokia provides comment and a proposal to move on.
Dario (Huawei) provides LS rev5
Huawei provides LS out rev6 (based on rev2_E/// with minor editorial changes) and rev7 (cleaned version of rev6)		 Revised
16.2 SP-200631 LS OUT Approval LS on HO to congested cells TSG SA Rel-16 Revision of SP-200590_Rev10. Approved Approved
16.2 SP-200435 CR PACK Approval CR to 23.282 (IABARC, Rel-16) SA WG2 Conditional on RAN WG2/RAN WG3 response to LS in SP-200325. Approved at CC#3 Approved
16.2 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=14 -
16.2 SP-200423 CR PACK Approval CRs to 23.273, 23.502 (5G_eLCS, Rel-16) SA WG2 23.273 CR0118 is withdrawn, as 23.273 CR0126 in CR Pack SP-200422 relaces it. All CRs except 23.273 CR0118 were Block approved. Partially approved Partially approved
16.2 SP-200424 CR PACK Approval CRs to 23.501, 23.502 (5G_eSBA, Rel-16) SA WG2 Block approved Approved
16.2 SP-200427 CR PACK Approval CRs to 23.316, 23.501, 23.502, 23.503 (5WWC, Rel-16) SA WG2 Block approved Approved
16.2 SP-200428 CR PACK Approval CRs to 23.501, 23.502, 23.503 (ATSSS, Rel-16) SA WG2 Block approved Approved
16.2 SP-200429 CR PACK Approval CRs to 23.501, 23.502, 23.503 (CUPS, TEI16, Rel-16) SA WG2 Block approved Approved
16.2 SP-200430 CR PACK Approval CR to 23.501 (eIMS5G_SBA, Rel-16) SA WG2 Block approved Approved
16.2 SP-200431 CR PACK Approval CRs to 23.228, 23.502, 23.503 (eNA, Rel-16) SA WG2 Block approved Approved
16.2 SP-200432 CR PACK Approval CRs to 23.501, 23.502 (eNS, Rel-16) SA WG2 Block approved Approved
16.2 SP-200433 CR PACK Approval CRs to 23.501, 23.502 (ETSUN, Rel-16) SA WG2 Block approved Approved
16.2 SP-200436 CR PACK Approval CRs to 23.401, 23.501, 23.502, 23.682 (RACS, Rel-16) SA WG2 Block approved Approved
16.2 SP-200437 CR PACK Approval CRs to 23.501, 23.502 (UDICOM, Rel-16) SA WG2 Block approved Approved
16.2 SP-200439 CR PACK Approval CRs to 23.502, 23.503 (Vertical_LAN, Rel-16) SA WG2 Block approved Approved
16.2 SP-200441 CR PACK Approval CRs to 23.167, 23.237, 23.401, 23.501, 23.502, 23.503 (TEI16, Rel-16) SA WG2 CRs reissued in SP-200552 Revised
16.2 SP-200552 CR PACK Approval CRs to 23.167, 23.237, 23.401, 23.501, 23.502, 23.503 (TEI16, Rel-16) SA WG2 Update of SP-200441 to add CIoT WI Code for TEI16 CRs Block approved Approved
16.3 - - - SA WG3 and SA WG3 LI Rel-16 CRs - - Docs:=16 -
16.3 SP-200553 CR Approval 33.501 CR0853 (Rel-16, 'B'): CR for network slice specific authentication and authorization clauses Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, Ericsson, Hewlett-Packard Enterprise, China Mobile, CATT, Inter Digital Rel-16 Source to TSG incorrect. Approved at CC#1 Approved
16.3 SP-200584 CR Approval 33.501 CR0854 (Rel-16, 'B'): Token-based authorization in indirect communication scenarios CableLabs, Mavenir, Nokia, Nokia Shanghai Bell, Ericsson, Huawei, Hisilicon Rel-16 Source to TSG incorrect. Approved at CC#1 Approved
16.3 SP-200365 CR PACK Approval Rel-16 CRs on Security for enhancements to the Service Based 5G System Architecture SA WG3 CC#3: Removed from block approval. 33.501 CR0000 was accidently inserted into the CR Pack and was not approved. Approved Approved
16.3 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=13 -
16.3 SP-200356 CR PACK Approval Rel-16 CRs on TEI SA WG3 Block approved. 33.102 CR0380R1 was a CR to a different TS and was not pursued. This CR pack was therefore partially approved Partially approved
16.3 SP-200358 CR PACK Approval Rel-16 CRs on Security Assurance Specification for 5G SA WG3 Block approved Approved
16.3 SP-200359 CR PACK Approval Rel-16 CRs on Security aspects of eCAPIF SA WG3 Block approved Approved
16.3 SP-200362 CR PACK Approval Rel-16 CRs on Mission Critical Services Security Enhancements SA WG3 Block approved Approved
16.3 SP-200363 CR PACK Approval Rel-16 CRs on 3GPP profiles for cryptographic algorithms and security protocols SA WG3 Block approved Approved
16.3 SP-200364 CR PACK Approval Rel-16 CRs on Security Aspects of eV2XARC SA WG3 Block approved Approved
16.3 SP-200366 CR PACK Approval Rel-16 CRs on Security of 5G_CIoT SA WG3 Block approved Approved
16.3 SP-200368 CR PACK Approval Rel-16 CRs on Security for IAB SA WG3 Block approved Approved
16.3 SP-200369 CR PACK Approval Rel-16 CRs on Authentication and key management for applications based on 3GPP credential in 5G SA WG3 Block approved Approved
16.3 SP-200371 CR PACK Approval Rel-16 CRs on User Plane Gateway Function for Inter-PLMN Security SA WG3 Block approved Approved
16.3 SP-200372 CR PACK Approval Rel-16 CRs on Security of 5WWC SA WG3 Block approved Approved
16.3 SP-200373 CR PACK Approval Rel-16 CRs on Security of 5G_eLCS SA WG3 Block approved Approved
16.3 SP-200407 CR PACK Approval Rel-16 CRs on Lawful Interception SA WG3-LI Rel-16 Block approved Approved
16.4 - - - SA WG4 Rel-16 CRs - - Docs:=12 -
16.4 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=12 -
16.4 SP-200388 CR PACK Approval CRs for consolidated changes to 26.501 [5GMSA] SA WG4 Block approved Approved
16.4 SP-200389 CR PACK Approval CR to Adding Support for Remote Control [E_FLUS] SA WG4 Block approved Approved
16.4 SP-200391 CR PACK Approval CR to Corrections to EVS Alternative Fixed-Point Source Code [EVS_codec, Alt_FX_EVS] SA WG4 Block approved Approved
16.4 SP-200392 CR PACK Approval CRs to QoE Measurement Collection [QOED] SA WG4 26.114 CR0499 needed replacing by it's revision and was withdrawn. Revised in SP-200595 Revised
16.4 SP-200595 CR PACK Approval CRs to QoE Measurement Collection [QOED] SA WG4 Revision of SP-200392 Block approved Approved
16.4 SP-200393 CR PACK Approval CRs to Service Announcement API for enTV [MC_XMB,TEI16] SA WG4 Block approved Approved
16.4 SP-200394 CR PACK Approval CR to Correction of 3gpp-qos-hint examples [5G_MEDIA_MTSI_EXT] SA WG4 Block approved Approved
16.4 SP-200396 CR PACK Approval CRs to Corrections of ch-aw-recv specification [EVS codec] SA WG4 Block approved Approved
16.4 SP-200397 CR PACK Approval CRs to TS 26.114 and 26.346 [TEI16] SA WG4 Block approved Approved
16.4 SP-200402 CR PACK Approval CRs to Remove H.263 and MPEG-4 Visual from 3GPP Services [RM_H263_MP4V] SA WG4 Rel-16 Postponed at CC#3 Postponed
16.4 SP-200386 CR PACK Approval CRs to Corrections of algorithmic description [EVS codec] SA WG4 Block approved Approved
16.4 SP-200597 CR PACK Approval CR Adding Media Feature Tag for IMS Data Channel [5G_MEDIA_MTSI_ext] SA WG4 LATE DOC: Rx 26/06, 13:00. Late uploading due to an inadvertent administrative error Block approved Approved
16.5 - - - SA WG5 Rel-16 CRs - - Docs:=30 -
16.5 SP-200522 CR Approval 32.291 CR0221R2 (Rel-16, 'F'): Add the Retransmission Indicator in Open API Huawei Rel-16 Revision of S5-202420 (32.291 CR0221R1) in CR Pack SP-200484. Source to TSG incorrect. Approved at CC#1 Approved
16.5 SP-200484 CR PACK Approval Rel-16 CRs on TEI batch 1 SA WG5 Proposed revision of 32.291 CR0221R1 in SP-200522. CC#1: All CRs except 32.291 CR0221R1 were approved Partially approved
16.5 SP-200542 CR Approval 28.623 CR0094 (Rel-16, 'F'): Correction of YANG Solution for S5-203199 Ericsson Hungary Ltd Rel-16 WITHDRAWN Withdrawn
16.5 SP-200596 CR Approval 28.623 CR0085R1 (Rel-16, 'F'): Update Nrm YANG Ericsson Hungary Ltd Rel-16 Revision of 28.623 CR0085 in CR Pack SP-200490. Approved at CC#1 Approved
16.5 SP-200495 CR PACK Approval Rel-16 CRs on Charging Access of ATSSS SA WG5 32.255 CR0207R1 was withdrawn from this CR Pack by SA WG5. CC#1: All CRs except 28.623 CR0085 were approved. Partially approved
16.5 SP-200523 CR Approval 28.532 CR0134 (Rel-16, 'F'): Convert JSON schema to YAML file for perfromance threshold monitoring service Huawei Rel-16 Source to TSG incorrect. CC#1: SP-200523_rev1 was approved. Revised to SP-200611. Zoulan(Huawei): The 'Source to WG' and 'Source to TSG' need update. Revised
16.5 SP-200611 CR Approval 28.532 CR0134R1 (Rel-16, 'F'): Convert JSON schema to YAML file for perfromance threshold monitoring service Huawei Rel-16 Revision of SP-200523_Rev1. This CR was approved Approved
16.5 SP-200543 CR Approval 28.541 CR0320 (Rel-16, 'F'): Update Clause 4.2.1.2 Inheritance UML diagram Huawei Rel-16 Source to TSG incorrect. CC#1: SP-200543_rev1 was approved. Revised to SP-200612. Zoulan(Huawei):
The 'Source to WG' and 'Source to TSG' need update. The title of the CR needs to be aligned.
Zoulan(Huawei):
The 'Source to WG' ,'Source to TSG' and 'WI code' need update. The title of the CR needs to be aligned.		 Revised
16.5 SP-200612 CR Approval 28.541 CR0320R1 (Rel-16, 'F'): Update Clause 4.2.1.2 Inheritance UML diagram Huawei Rel-16 Revision of SP-200543. This CR was approved Approved
16.5 SP-200603 CR Approval 28.541 CR0261R1 (Rel-16, 'B'): Rel-16 CR 28.541 Add IOC for control of QoS monitoring per QoS flow per UE Intel Rel-16 LATE DOC: Rx 30/06, 07:20. Proposed revision of 28.541 CR0261 in CR pack SP-200489. Approved at CC#1 Approved
16.5 SP-200604 CR Approval 28.541 CR0262R1 (Rel-16, 'B'): Rel-16 CR 28.541 Add IOC for control of GTP-U path QoS monitoring Intel Rel-16 LATE DOC: Rx 30/06, 07:20. Proposed revision of 28.541 CR0262 in CR pack SP-200489. Approved at CC#1 Approved
16.5 SP-200489 CR PACK Approval Rel-16 CRs on NRM enhancements batch 1 SA WG5 28.541 CR0284R1 and 28.623 CR0046 are submitted in SP-200490 and are withdrawn from this CR Pack. Proposed revision of 28.541 CR0261 in SP-200603. Proposed revision of 28.541 CR0262 in SP-200604. This CR Pack was partially approved. Partially approved
16.5 SP-200605 CR Approval 28.541 CR0286R2 (Rel-16, 'B'): Rel-16 CR 28.541 Add IOC for configurable 5QIs Intel Rel-16 LATE DOC: Rx 30/06, 07:20. Proposed revision of 28.541 CR0286 in CR pack SP-200490. Approved at CC#1 Approved
16.5 SP-200490 CR PACK Approval Rel-16 CRs on NRM enhancements batch 2 SA WG5 Proposed revision of 28.623 CR0085 in SP-200596. Proposed revision of 28.541 CR0286 in SP-200605. CC#1: All CRs except 28.623 CR0085 and 28.541 CR0286 were approved Partially approved
16.5 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=16 -
16.5 SP-200483 CR PACK Approval Rel-16 CRs on Streaming trace reporting SA WG5 Rel-16 Block approved Approved
16.5 SP-200485 CR PACK Approval Rel-16 CRs on TEI batch 2 SA WG5 Block approved Approved
16.5 SP-200493 CR PACK Approval Rel-16 CRs on Self-Organizing Networks (SON) for 5G networks SA WG5 Block approved Approved
16.5 SP-200494 CR PACK Approval Rel-16 CRs on Management of QoE measurement collection SA WG5 Block approved Approved
16.5 SP-200496 CR PACK Approval Rel-16 CRs on Energy efficiency of 5G SA WG5 Block approved Approved
16.5 SP-200497 CR PACK Approval Rel-16 CRs on Enhancement of 3GPP management system for multiple tenant environment support SA WG5 Block approved Approved
16.5 SP-200500 CR PACK Approval Rel-16 CRs on Integration of ONAP and 3GPP 5G management framework SA WG5 Block approved Approved
16.5 SP-200502 CR PACK Approval Rel-16 CRs on Enhancement of performance assurance for 5G networks including network slicing batch 1 SA WG5 28.552 CR0203 should be WI Cod NETSLICE-ADPM5G. This will be corrected in 3GU Block approved Approved
16.5 SP-200503 CR PACK Approval Rel-16 CRs on Enhancement of performance assurance for 5G networks including network slicing batch 2 SA WG5 Block approved Approved
16.5 SP-200505 CR PACK Approval Rel-16 CRs on Charging Aspect for 5WWC SA WG5 Block approved Approved
16.5 SP-200506 CR PACK Approval Rel-16 CRs on Charging Enhancement of 5GC interworking with EPC SA WG5 Block approved Approved
16.5 SP-200507 CR PACK Approval Rel-16 CRs on Charging aspects of ETSUN SA WG5 Block approved Approved
16.5 SP-200508 CR PACK Approval Rel-16 CRs on CHF-controlled quota management SA WG5 Block approved Approved
16.5 SP-200509 CR PACK Approval Rel-16 CRs on Charging AMF in 5G System Architecture Phase 1 SA WG5 Block approved Approved
16.5 SP-200511 CR PACK Approval Rel-16 CRs on Network Slice Performance and Analytics Charging in 5G System SA WG5 Block approved Approved
16.5 SP-200512 CR PACK Approval Rel-16 CRs on Management of MDT in 5G SA WG5 Block approved Approved
16.6 - - - SA WG6 Rel-16 CRs - - Docs:=3 -
16.6 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=3 -
16.6 SP-200337 CR PACK Approval Rel-16 CRs to TS 23.222 for eCAPIF SA WG6 Block approved Approved
16.6 SP-200338 CR PACK Approval Rel-16 CRs to TS 23.434 for SEAL SA WG6 Block approved Approved
16.6 SP-200339 CR PACK Approval Rel-16 CRs to TS 23.379 for MONASTERY2 SA WG6 Block approved Approved
17 - - - Rel-17 CRs (block approval if not otherwise requested) - - Docs:=0 -
17.1 - - - SA WG1 Rel-17 CRs - - Docs:=8 -
17.1 SP-200593 CR Approval 22.125 CR0028R3 (Rel-17, 'F'): Clarification of the definition of a UAS Qualcomm Rel-17 Proposed replacement of 22.125 CR0028R2 in CR Pack SP-200564. Postponed at CC#2 Suresh Chitturi (SA6 Chair): QC CR in SP-200593 attempts to bring consistency to SA1 CR (SP-200564) and the related approved pCR (S6-200824) in SA6 UASAPP study, where the text in the definition and Annex are consistent. Postponed
17.1 SP-200564 CR PACK Approval SA WG1 CRs on EAV SA WG1 Rel-17 Proposed replacement CR in SP-200593. CC#2: Postponed at CC#2 Postponed
17.1 SP-200513 CR Approval 21.905 CR0120 (Rel-17, 'F'): UICC definition alignment THALES Rel-17 Source to TSG incorrect. Also submitted in SP-200570. WITHDRAWN. Withdrawn
17.1 SP-200570 CR Approval 21.905 CR0121 (Rel-17, 'F'): UICC definition alignment Thales Rel-17 Source to TSG incorrect. Approved at CC#1 Approved
17.1 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=4 -
17.1 SP-200565 CR PACK Approval SA WG1 CRs on AVPROD SA WG1 Rel-17 Block approved Approved
17.1 SP-200567 CR PACK Approval SA WG1 CRs on eCAV SA WG1 Rel-17 Block approved Approved
17.1 SP-200568 CR PACK Approval SA WG1 CRs on CMED SA WG1 Block approved Approved
17.1 SP-200569 CR PACK Approval SA WG1 CRs on TEI17 SA WG1 Rel-17 Block approved Approved
17.2 - - - SA WG2 Rel-17 CRs - - Docs:=1 -
17.2 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=1 -
17.2 SP-200442 CR PACK Approval CRs to 23.737 (FS_5GSAT_ARCH, Rel-17) SA WG2 Block approved Approved
17.3 - - - SA WG3 and SA WG3 LI Rel-17 CRs - - Docs:=0 -
17.3 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=0 -
17.4 - - - SA WG4 Rel-17 CRs - - Docs:=0 -
17.4 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=0 -
17.5 - - - SA WG5 Rel-17 CRs - - Docs:=0 -
17.5 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=0 -
17.6 - - - SA WG6 Rel-17 CRs - - Docs:=3 -
17.6 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=3 -
17.6 SP-200340 CR PACK Approval Rel-17 CRs to TS 23.280, TS 23.281 and TS 23.379 for eMONASTERY2 SA WG6 Block approved Approved
17.6 SP-200341 CR PACK Approval Rel-17 CRs to TS 23.282 for eMCData3 SA WG6 Block approved Approved
17.6 SP-200342 CR PACK Approval Rel-17 CRs to TS 23.280 and TS 23.379 for enh3MCPTT SA WG6 Block approved Approved
18 - - - CR’s related to Study Items (block approval if not otherwise requested) - - Docs:=3 -
18 - - - Block 5: For block approval - Thursday July 2, 15:00 UTC - - Docs:=3 -
18 SP-200374 CR PACK Approval Rel-16 CRs on Study on Security for 5GS Enhanced support of Vertical and LAN Services SA WG3 Block approved Approved
18 SP-200375 CR PACK Approval Rel-16 CRs on Study on authentication and key management for applications based on 3GPP credential in 5G SA WG3 Block approved Approved
18 SP-200566 CR PACK Approval SA WG1 CRs on FS_eCAV SA WG1 Rel-17 Block approved Approved
Block 6 - - - All items in agenda items 19 (Project Mgmt and TSG SA ownd Specs) and 20 (AOB) and their sub-agenda items will be marked approved/noted/endorsed on Thursday July 2 15:00 UTC if no other requests were received. - - Docs:=0 -
19 - - - Project Management & TSG SA owned specifications - - Docs:=0 -
19.1 - - - Review of the work plan - - Docs:=12 -
19.1 SP-200606 WORK PLAN Information Work Plan review at TSG SA#88e Work Plan Manager LATE DOC: Noted Noted
19.1 - - - Block 6: For block approval - Thursday July 2, 15:00 UTC - - Docs:=11 -
19.1 SP-200408 CR Approval 33.203 CR0250 (Rel-13, 'F'): Draft-ietf-tram-turn-third-party-authz has been published as RFC7635 Orange Rel-13 Block approved Approved
19.1 SP-200409 CR Approval 33.203 CR0251 (Rel-14, 'A'): Draft-ietf-tram-turn-third-party-authz has been published as RFC7635 Orange Rel-14 Block approved Approved
19.1 SP-200410 CR Approval 33.203 CR0252 (Rel-15, 'A'): Draft-ietf-tram-turn-third-party-authz has been published as RFC7635 Orange Rel-15 Block approved Approved
19.1 SP-200411 CR Approval 32.322 CR0010 (Rel-8, 'F'): Draft-ietf-ippm-twamp has been published as RFC5357 Orange Rel-8 Block approved Approved
19.1 SP-200412 CR Approval 32.322 CR0011 (Rel-9, 'A'): Draft-ietf-ippm-twamp has been published as RFC5357 Orange Rel-9 Block approved Approved
19.1 SP-200413 CR Approval 32.322 CR0012 (Rel-10, 'A'): Draft-ietf-ippm-twamp has been published as RFC5357 Orange Rel-10 Block approved Approved
19.1 SP-200414 CR Approval 32.322 CR0013 (Rel-11, 'A'): Draft-ietf-ippm-twamp has been published as RFC5357 Orange Rel-11 Block approved Approved
19.1 SP-200415 CR Approval 32.322 CR0014 (Rel-12, 'A'): Draft-ietf-ippm-twamp has been published as RFC5357 Orange Rel-12 Block approved Approved
19.1 SP-200416 CR Approval 32.322 CR0015 (Rel-13, 'A'): Draft-ietf-ippm-twamp has been published as RFC5357 Orange Rel-13 Block approved Approved
19.1 SP-200417 CR Approval 32.322 CR0016 (Rel-14, 'A'): Draft-ietf-ippm-twamp has been published as RFC5357 Orange Rel-14 Block approved Approved
19.1 SP-200418 CR Approval 32.322 CR0017 (Rel-15, 'A'): Draft-ietf-ippm-twamp has been published as RFC5357 Orange Rel-15 Block approved Approved
19.2 - - - Specification Status - - Docs:=0 -
19.2 - - - Block 6: For block endorsement - Thursday July 2, 15:00 UTC - - Docs:=0 -
19.3 - - - Work Item Summaries for TR 21.91x (to be block approved) - - Docs:=12 -
19.3 - - - Block 6: For block endorsement - Thursday July 2, 15:00 UTC - - Docs:=12 -
19.3 SP-200343 WI SUMMARY Endorsement Work Item Summary for Enhancements of Public Warning System (ePWS) SyncTechno Inc. (Rapporteur) Rel-16 Block Endorsed Endorsed
19.3 SP-200344 WI SUMMARY Endorsement Work Item Summary for Maritime Communication Services over 3GPP System (MARCOM) SyncTechno Inc. (Rapporteur) Rel-16 Block Endorsed Endorsed
19.3 SP-200403 WI SUMMARY Endorsement Summary for WI ANTeM HEAD acoustics GmbH Rel-16 Block Endorsed Endorsed
19.3 SP-200520 WI SUMMARY Approval Summary for WI KPI reporting ZTE Corporation Rel-16 Block Endorsed Endorsed
19.3 SP-200524 WI SUMMARY Endorsement Add Telecom management section to TR 21.916 SA WG5 Vice Chairman (Huawei), SA WG5 Chairman, SA WG5 Vice Chairman (Nokia) Rel-16 Block Endorsed Endorsed
19.3 SP-200525 WI SUMMARY Endorsement Add WI summary of Charging Aspect for 5WWC to TR 21.916 Huawei Tech.(UK) Co., Ltd Rel-16 Block Endorsed Endorsed
19.3 SP-200526 WI SUMMARY Endorsement Add WI summary of management enhancement for tenant environment support to TR 21.916 Huawei Tech.(UK) Co., Ltd Rel-16 Block Endorsed Endorsed
19.3 SP-200531 WI SUMMARY Endorsement Summary for WI Methodology for 5G management specifications Ericsson LM Block Endorsed Endorsed
19.3 SP-200532 WI SUMMARY Endorsement Summary for WI Closed loop SLS Assurance Ericsson LM Block Endorsed Endorsed
19.3 SP-200534 WI SUMMARY Endorsement Summary for the SBMA trace and Streaming trace work items Nokia Rel-16 Block Endorsed Endorsed
19.3 SP-200535 WI SUMMARY Approval Work Item Summary for 5G management capabilities Orange Spain Rel-16 Block Endorsed Endorsed
19.3 SP-200544 WI SUMMARY Endorsement WI_summary_MA5SLA China Mobile Com. Corporation Rel-16 Block Endorsed Endorsed
19.4 - - - Improvements to working methods & CRs against 3GPP TSG SA owned Specifications - - Docs:=0 -
19.4 - - - Block 6: For block noting - Thursday July 2, 15:00 UTC - - Docs:=0 -
19.5 - - - MCC Status Report - - Docs:=1 -
19.5 - - - Block 6: For block noting - Thursday July 2, 15:00 UTC - - Docs:=1 -
19.5 SP-200449 REPORT Information Support Team report MCC Noted at CC#4 Noted
19.6 - - - Future Meeting schedule - - Docs:=0 -
19.6 - - - Block 6: For block approve/note/endorse - Thursday July 2, 15:00 UTC - - Docs:=0 -
20 - - - Any Other Business - - Docs:=1 -
20 - - - Block 6: For block noting - Thursday July 2, 15:00 UTC - - Docs:=1 -
20 SP-200579 REPORT Information ISO SC29 (JPEG/MPEG) reorganization Beijing Xiaomi Mobile Software This was presented and noted in CC#3 Noted
21 - - - Close of Meeting - - Docs:=0 -
99 - - - WITHDRAWN ITEMS - - Docs:=7 -
99 SP-200555 CR Approval 22.125 CR0032 (Rel-17, 'F'): Revised SA WG1 CR-TS 22.125 on UAS definition Qualcomm CDMA Technologies Rel-17 Should be withdrawn and a new CR allocate as a revision of S1-202268 WITHDRAWN Withdrawn
99 SP-200556 P-CR Approval 23.755: Updated SA WG6 pCR-TR 23.755 on UAS definition Qualcomm CDMA Technologies Rel-16 WITHDRAWN Withdrawn
99 SP-200419 REPORT Presentation SA WG2 Status report to TSG SA SA WG2 Chairman WITHDRAWN Withdrawn
99 SP-200405 DRAFT TS Approval 5G Media Streaming Protocols [5GMS] SA WG4 Rel-16 WITHDRAWN Withdrawn
99 SP-200395 CR PACK Approval CRs to Corrections on network slicing [5GMSA] SA WG4 WITHDRAWN Withdrawn
99 SP-200345 SID NEW Approval New SID on Study on Ranging-based Services. Xiaomi Rel-18 WITHDRAWN Withdrawn
99 SP-200443 SID REVISED Approval Change of rapporteur on SID 'Study on architecture aspects for using satellite access in 5G' SA WG2 Rel-17 WITHDRAWN Withdrawn
Created:      END OF LIST
OPEN documents: 0
Parallel Agreed: 0
Approved/Endorsed: 206
Replied to LSs: 0
Noted: 69
Merged: 0
For e-mail approval: 0
Postponed: 5
Withdrawn: 11
Total documents: 333