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:
|
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.” |
| 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:=0 | - | |
| 1.3 | - | - | - | IPR & Antitrust reminders | - | - | Docs:=0 | - | |
| 1.4 | - | - | - | Approval of Agenda | - | - | Docs:=2 | - | |
| 1.4 | SP-200632 | AGENDA | Approval | Agenda & Procedures & Time Schedule for TSG SA#88-e | TSG SA Chairman | Approved | Approved | ||
| 1.4 | SP-200855 | AGENDA | Approval | SA#89-e GoToMeetings Agenda | TSG SA Chairman | Noted | Noted | ||
| 1.5 | - | - | - | Report from previous SA meetings | - | - | Docs:=1 | - | |
| 1.5 | SP-200633 | REPORT | Approval | Draft report of TSG SA meeting #88E | TSG SA Secretary | Approved | Approved | ||
| 1.6 | - | - | - | Reports from TSG SA ad-hoc meetings and workshops | - | - | Docs:=0 | - | |
| 2 | - | - | - | Liaisons Statements | - | - | Docs:=0 | - | |
| 2.1 | - | - | - | Incoming LSs - proposed to note | - | - | Docs:=12 | - | |
| 2.1 | - | - | - | Block 1: For Block Noting - Tuesday 15:00 UTC | - | - | Docs:=12 | - | |
| 2.1 | SP-200635 | LS In | Information | LS from ITU-R WP 5D: LIAISON STATEMENT TO RIT/SRIT PROPONENTS ON THE COMPLETION AND CONCLUSIONS OF STEPS 5 TO 7 OF THE IMT-2020 PROCESS FOR THE FIRST RELEASE OF NEW RECOMMENDATION ITU-R M.[IMT-2020.SPECS] | ITU-R WP 5D (5D_TD_159R1) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200636 | LS In | Information | LS from ITU-R WP5D: LIAISON STATEMENT TO TRANSPOSING ORGANIZATIONS ON THE COMPLETION OF STEP 8 OF IMT-2020 PROCESS FOR THE FIRST RELEASE OF NEW RECOMMENDATION ITU-R M.[IMT-2020.SPECS] | ITU-R WP5D (5D_TD_163R1e_IMT-2020.) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200637 | LS In | Information | LS from ETSI ISG E4P: Request for information exchange | ETSI ISG E4P (E4P(20)000_022) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200639 | LS In | Information | LS from TM Forum Autonomous Networks: Introduction of TM Forum Autonomous Network project and Coordination Proposal | TM Forum Autonomous Networks (Liaison AN results ETSI GSMA 3GPPv2) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200640 | LS In | Information | LS from IETF: Re: LS on need for Multi-Path QUIC for ATSSS | IETF (LS_from_IETF) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200641 | LS In | Information | LS from IETF DRIP: Drone Remote ID Protocol Working Group (DRIP) | IETF DRIP (LSs_from_IETF_9June2020) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200642 | LS In | Information | LS from ITU-R WP5A: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS ON ITS Connected Automated Vehicles (CAV) | ITU-R WP5A (5A_TEMP_29_R1) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200643 | LS In | Information | LS from TSG RAN: Reply LS to RP-200030 on relevant 3GPP Specs for PC5 Sidelink | TSG RAN (RP-201285) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200644 | LS In | Information | LS from TSG RAN: Reply LS to GSMA_5GSI_28_Doc003 = RP-193053 on 5G indicator enhancement | TSG RAN (RP-201358) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200645 | LS In | Information | LS from ITU-T SG13: LS/o on information about consent of Machine Learning related ITU-T Recommendation Y.3176 | ITU-T SG13 (SG13-LS160) | CC#1: This was block noted Block 1 | Noted | ||
| 2.1 | SP-200649 | LS In | Information | LS from CT WG4: LS on AUSF/UDM discovery based on SUCI information | CT WG4 (C4-204337) | Rel-17 | CC#1: This was block noted Block 1 | Tao (China Mobile) ask for SA discussion on proper way forward in stage 2 so that stage 3 can start. | Noted |
| 2.1 | SP-200653 | LS In | Information | LS from SA WG5: LS reply to LS on M.resm-AI “Requirements for energy saving management of 5G RAN system with AI” | SA WG5 (S5-204516) | Rel-17 | CC#1: This was block noted Block 1 | Noted | |
| 2.2 | - | - | - | Incoming LSs which need an outgoing LS | - | - | Docs:=21 | - | |
| 2.2 | - | - | - | LSs with related documents/replies | - | - | Docs:=13 | - | |
| 2.2 | SP-200652 | LS In | Action | LS from SA WG2: LS on RAN impact of FS_5MBS Study | SA WG2 (S2-2006044) | Rel-17 | Response drafted in SP-200810. Final response in SP-200884 | Replied to | |
| 2.2 | SP-200809 | DISCUSSION | Endorsement | Discussion on support for broadcast in Rel-17 MBS | Huawei, HiSilicon | Rel-17 | Noted | Noted | |
| 2.2 | SP-200810 | LS OUT | Approval | [DRAFT] Reply LS on RAN impact of FS_5MBS Study | Huawei [SA] | Rel-17 | Response to SP-200652. SP 200810_Rev2 was approved. (To be revised into a new TD number by MCC). Revised to SP-200884. | Haris (Qualcomm) proposes that SA conveys the message to SA2 that for NR broadcast SA2 needs to spend more time to document more solutions Wanqiang (Huawei) give the feedback on QC proposal and make further update. Andy (Samsung) comments on rev2, provides rev3. | Revised |
| 2.2 | SP-200884 | LS OUT | Approval | Reply LS on RAN impact of FS_5MBS Study | TSG SA | Rel-17 | Revision of SP-200810_Rev2. Approved | Approved | |
| 2.2 | SP-200871 | LS In | Action | LS from TSG RAN: Reply LS on RAN impact of FS_5MBS Study | TSG RAN (RP-202086) | Rel-17 | Related to incoming LS in SP-200652. CC#4: This LS was noted. | Noted | |
| 2.2 | SP-200634 | LS In | Action | LS from IALA: Liaison Note to TSG SA - Request for information | IALA (C71-11.5.1) | Postponed SP-200310 from SA#88E. Response drafted in SP-200655. Final response in SP-200877 | Replied to | ||
| 2.2 | SP-200655 | LS OUT | Approval | [DRAFT] Reply LS on request for information from IALA | SyncTechno Inc. | Response to SP-200634. MCC will need to revise to remove 'draft'. Revised to SP-200877. | Revised | ||
| 2.2 | SP-200877 | LS OUT | Approval | Reply LS on request for information from IALA | TSG SA | Revision of SP-200655. Approved | Approved | ||
| 2.2 | SP-200654 | LS In | Action | LS from CT WG1: LS on the stage 2 aspects of MINT | CT WG1 (C1-205332) | Rel-17 | Response drafted in SP-200775. Final response in SP-200880 | Replied to | |
| 2.2 | SP-200774 | DISCUSSION | Endorsement | Discussion on the WI MINT | LG Electronics | Rel-17 | Noted | Noted | |
| 2.2 | SP-200775 | LS OUT | Approval | [DRAFT] Reply LS on the stage 2 aspects of MINT | LG Electronics | Rel-17 | Response to SP-200654. CC#1: A revision will be provided based on the comments received. SP 200775_rev3 was approved. (This will be cleaned up and revised into a new TD number by MCC). Revised to SP-200880. | Chia-Lin (MediaTek) still think SA2 should be involved from the study phase Hyunsook (LGE) initiates discussion for the revision of SP-200775, and provides rev1. Guillaume (MediaTek) can agree moving forward as proposed Hyunsook (LGE) provides comments. Chris (Vodafone) believes that it will be OK for CT (1) to open a SID on this topic provided that the study includes the topics of protecting non-failed PLMNs and recovering PLMNs from signalling overload. Once the STUDY is completed, 3GPP should then decide on how to proceed with any normative work. Hyunsook (LGE) think Chris's suggestion is same to CT1 approach. CT1 LS already describes a study phase, and as usual CT1 business, CT1 will have normative work based on study results. Chris (Vodafone): it is OK for CT(1) to commence a SID but NOT to include a normative work in it. The SID needs to include at least: a) How one PLMN failure does not lead to signalling overload in other PLMNs; and b) how to avoid 'returning UEs' overloading the PLMN that had earlier failed. Chris (Vodafone): it is OK for CT(1) to commence a SID but NOT to include a normative work in it. The SID needs to include at least: a) How one PLMN failure does not lead to signalling overload in other PLMNs; and b) how to avoid 'returning UEs' overloading the PLMN that had earlier failed. Hyunsook (LGE) think Chris's suggestion is same to CT1 approach. CT1 LS already describes a study phase, and as usual CT1 business, CT1 will have normative work based on study results. | Revised |
| 2.2 | SP-200880 | LS OUT | Approval | Reply LS on the stage 2 aspects of MINT | TSG SA | Rel-17 | Revision of SP-200775_Rev3. Approved | Approved | |
| 2.2 | SP-200814 | DISCUSSION | Decision | The Importance of Maintaining Broadcast Services in Rel-17 NR MBS | CBN, ABS, ABP, China Telecom, China Unicom, IRT, Reliance Jio | Rel-17 | Noted | Noted | |
| 2.2 | - | - | - | Block 2: For Block Noting - Wednesday 15:00 UTC | - | - | Docs:=8 | - | |
| 2.2 | SP-200638 | LS In | Action | LS from ITU-T JCA-IMT2020: LS on Invitation to update the information in the IMT2020 roadmap | ITU-T JCA-IMT2020 (JCA-IMT2020-O-015-R1_LS08) | Response drafted in SP-200856. Final response in SP-200887 | Replied to | ||
| 2.2 | SP-200856 | LS OUT | Approval | [DRAFT] Reply to LS on Invitation to update the information in the IMT2020 roadmap | Samsung | Created at meeting. Response to SP-200638. MCC will need to revise to remove 'draft'. Revised to SP-200887. | Revised | ||
| 2.2 | SP-200887 | LS OUT | Approval | Reply to LS on Invitation to update the information in the IMT2020 roadmap | TSG SA | Revision of SP-200856. Approved | Approved | ||
| 2.2 | SP-200646 | LS In | Action | LS from TM Forum: TM Forum implementation experiences 3GPP NRM Models | TM Forum (Liaison 3GPP SA5 TM Forum SID and NRM Models) | CC#2: This was Block Noted Block 2 | Noted | ||
| 2.2 | SP-200647 | LS In | Action | LS from SA WG2: LS on mandatory support of full rate user plane integrity protection for 5G | SA WG2 (S2-2006181) | Rel-16 | CC#2: This was Block Noted Block 2 | Noted | |
| 2.2 | SP-200648 | LS In | Action | LS on mandatory support of full rate user plane integrity protection for 5G | CT WG1 (C1-205392) | Rel-16 | CC#2: This was Block Noted Block 2 | Noted | |
| 2.2 | SP-200650 | LS In | Action | LS from RAN WG2: Response LS to TSG SA on mandatory support of full rate user plane integrity protection for 5G | RAN WG2 (R2-2008643) | Rel-16 | CC#2: This was Block Noted Block 2 | Noted | |
| 2.2 | SP-200651 | LS In | Action | LS from RAN WG3: Reply LS on mandatory support of full rate user plane integrity protection for 5G | RAN WG3 (R3-205653) | Rel-16 | CC#2: This was Block Noted Block 2 | Noted | |
| 3 | - | - | - | Items for discussion and early consideration | - | - | Docs:=0 | - | |
| 3.1 | - | - | - | Challenges to working agreements (Must have been previously requested) | - | - | Docs:=0 | - | |
| 3.2 | - | - | - | Issues highlighted for early treatment (Please contact the chairman in advance) | - | - | Docs:=0 | - | |
| 3.3 | - | - | - | Discussion papers on work in Rel-15 and earlier | - | - | Docs:=0 | - | |
| 3.4 | - | - | - | Discussion papers on work in Rel-16 | - | - | Docs:=4 | - | |
| 3.4 | SP-200795 | DISCUSSION | Approval | On 5G GUTI reallocation for CIoT | Qualcomm Incorporated | Rel-16 | Noted | Noted | |
| 3.4 | SP-200796 | LS OUT | Approval | [DRAFT] LS On 5G GUTI reallocation for CIoT | Qualcomm Korea | Rel-16 | CC#1: This LS was left for further consideration over e-mail. CC#3: This was left for further off-line discussion. CC#4: SP-200796_Rev1 was approved. Revised to SP-200883. | Haris (Qualcomm) starts email discussion Krister (Ericsson) states that me the option 1 is a special case of option 2. As said I see that the frequency of refresh of a temporary identifier is decided by the network operator. The operator may then configure AMF so option 1 is the behavior. That can be the correct behavior for normal UEs as there is a risk of an attack of tracking a UE, which is a privacy concern for the user. There may be other IoT devices which does not have the same strict privacy requirement, and as such could benefit from a less often refresh of GUTI. The gain would be in signaling optimizations. Wanqiang (Huawei) comment that option 2 brings extra complexity and makes the system unmanageable. It is not a reasonable approach to move forward. Johannes (Deutsche Telekom) supports option1 and supports the text in the LS as is. DT ranks the privacy and security issues as higher priority than optimizations. Exception to the existing procedures shall not be granted. Lars (Sony) comment that option 1 will bring extra complexity and new triggers for AMF to perform UCU. And ask a question on the privacy issue. Krister (Ericsson) comments that there is has only been a discussion here about privcay related to tracking a UE moving. No other security related issues identified. Johannes (Deutsche Telekom) clarifies that option1 reflects the specified solution of 5GS and option2 is the request for exceptional hanlding of certain UEs in 5GS Lars (Sony) option1 goes beyond the existing procedures. Haris (Qualcomm) provides response to Wangqiang Erik/Andy (Samsung) supports option 1, as there is privacy threat. Hucheng(CATT) supports option1, but thinks, if understanding is correct, the wording of option 1 could be enhanced: 'Option 1: Allocation of a new 5G-GUTI temporary identifier to the UE in IDLE mode in response to paging in 5G is mandatory and shall apply in all cases including all CIoT optimisations' From the clarifying question(s) I (Chris, Vodafone) asked in the Tuesday web call, I understand that the options are actually: Option 1: the standards shall enable GUTI reallocation at every Mobile Terminating RRC connection establishment. Option 2: the standard prevents GUTI reallocation at every Mobile Terminating RRC connection establishment. In which case Vodafone prefers option 1. Haris (Qualcomm) observes that there is preference to go with Option 1 and suggests companies to propose comments to the wording Orange supports Option 1. While Option 2 may give operators the flexibility of managing the (signalling) optimization which can be of significance for CIoT devices/applications without temporary GUTI allocated each time paging is performed, it may introduce some extra complexity, if, e.g. the exception should be given by HPLMN and/or VPLMN in roaming, when and for what CIoT devices/applications should be given the exception, even if it is configurable. This may adversely affect the optimization intended by Option 2. In addition, SA3 has already clearly defined in TS33.501 from Release 15 that the mandatory allocation by AMF of a new 5G-GUTI temporary identifier to the UE in response to a Paging message as a security and privacy protection enhancement of 5G. Option 2 would cause some mis-alignment and even contradictions with the SA3 specifications and open up more discussions/work in SA2, SA3 and CT1 at least about to dynamically configure GUTI for those that requires enhanced security for some CIoT devices/applications vs those that may have less security constraints. This may adversely affect achievable optimization after all. Saad (Interdigital). Interdigital also preferers option 1. Wanqiang (Huawei) provides further comments regarding the update from Ericsson and propose to stick to the original text in SP-200796. Krister (Ericsson) provides update of the text in option 1. Option 1: Upon receiving a temporary identifier (S-TMSI or I-RNTI) sent by a UE in response to a paging message, it is mandatory for the network to re-allocate the used temporary identifier that was sent in the response message from the UE. This requirement is valid for any type of UE. Haris (Qualcomm) provides response to Chris(Vodafone) Lars (Sony) provides further comments on the privacy issue. Krister (Ericsson) asks Wanqiang to explain the loose comment which missed to explain 'track the link'. Ericsson can not agree the original text of QC as it is not covering the 3rd case that I describe below. Wanqiang (Huawei) provides response and ask further question. Lars (Sony) We support Krister's alternative option 1 wording. Haris (Qualcomm) comments that the thread is for the approval of original or potentially revised text in SP-200796 and the text in SP-200795 is not going to be further modified since the paper is already noted Krister (Ericsson) provides provide revision to the draft LS in rev1. (Samsung) provides details on the privacy threat. Clarifies that temporary identifiers (S-TMSI and/or I-RNTI) that were used in the paging message and sent by a UE in response to a paging message should be re-allocated. Re-allocation of I-RNTI is mandated by TS 33.501, similarly 5G-GUTI needs to be reallocated. Lars (Sony) we support rev1 of the LS. Patrice (Huawei) proposes to produce a slide with the statement for working agreement based on the original proposal. Haris (Qualcomm) agrees with the proposal from Patrice and produces first draft Krister (Ericsson) provides response giving an explanation how the failure case also will be handled including a S-TMSI reallocation taking place. Ericsson clear see that that the text proved by Ericsson in LS response rev1 covers mandatory re-allocation requirement needed to handle the privacy issue of tracking threat. Wanqiang(Huawei) supports the draft from Haris and provides a small update. Lars(Sony) The ppt is only a copy of the original LS and serves no additional purpose than the original version of the LS. Krister (Ericsson) Dear all, This discussion we are having in SA plenary #89-e is to protect privacy threat through tracking of a CIoT UE. In Rel-16 we have two solutions fully specified including ASN.1 coding. The Control Plane CIoT solution as well as the User Plane CIoT solution. As shown with reasonable logical evidence in the mails sent by Ericsson and SONY to SA public mail reflector show that the UP CIoT solution has higher protection against tracking of a UE, since there is no one-to-one correlation between the temporary Identifier sent by the network and the paging response sent by the UE. It has also been showed that procedures are specified for the Network to re-allocate the 5G-GUTI (S-TMSI) as frequent as network finds appropriate (similar to legacy specifications) are also specified. It has also been shown and proposed as a new requirement to clarify in TS 33.501: Upon receiving a temporary identifier (S-TMSI or I-RNTI) sent by a UE in response to a paging message, it is mandatory for the network to re-allocate the used temporary identifier that was sent in the response message from the UE. This requirement is valid for any type of UE. This text will also fully answer the question from CT1 in the LS to SA3 (S3-2000615/C1-200967) Furthermore, It has also been shown that current procedures of the RCC resume failure will lead to release of RRC connection and that NAS level procedures will follow on. It is then required to re-allocate the 5G-GUTI as already required and specified. It has also been seen that two of the main companies behind the UP CIoT solutions are providing all these evidence. Still the companies with main interest in the CP CIoT Solution are putting unjustified demand on the UP CIoT solution. This without any detailed analysis presented that is showing that the protection level against a tracking attack of the UE is less compared to a CP CIoT UE. On the contrary, the protection level against tracking is higher than for the CP CIoT solution. Going back to any text in mails on SA3 mailing list and tdocs over the last three SA3 meetings, it is clear that this weeks SA plenary discussion on this subject is more detailed on both describing possible attack scenario as well as on how the currently Rel-16 procedures for the UP CIoT are specified and expected to work. Therefore, I finds it unfair and unjustified for companies, with little interest in UP CIoT solution, to go for a working agreement on these grounds presented in SP-200870. I would rather task SA3 to make a detailed analysis of the potential tracking attack scenarios that shows any evidence. Furthermore that CT1 clarifies where it may be unclear in specifications if determined necessary. Our analysis of specifications are that procedures cross interfaces are in place to handle this properly but as always behavior description can be more clear in particular related to failure cases. BR / Krister Krister (Ericsson) thanks Lars for the analysis. After going through a mails and tdoc over the last 3 SA3 meeting it is clear that the analysis of both the attack scenarios and analysis of the current Rel-16 specifications has been in more details in SA#89-e than what has been in done in SA3. Clearly SA3 needs to do their job here in upcoming meetings. | Revised |
| 3.4 | SP-200883 | LS OUT | Approval | LS on 5G GUTI re-allocation | TSG SA | Rel-16 | Revision of SP-200796_Rev1. Approved | Approved | |
| 3.4 | SP-200870 | DISCUSSION | Approval | Presentation on 5G GUTI reallocation | Qualcomm Incorporated | Endorsed. A working Agreement will be created based on this proposal | Endorsed | ||
| 3.5 | - | - | - | Discussion papers on work in Rel-17 | - | - | Docs:=0 | - | |
| 3.6 | - | - | - | Discussion papers on work in Rel-18 and later | - | - | Docs:=0 | - | |
| 4 | - | - | - | Reporting from SA Working Groups, other TSGs, and Others | - | - | Docs:=0 | - | |
| 4 | - | - | - | All reports in agenda item 4 (Reporting) and its sub-agenda items will get a max 5 minute slot on the GTM call on Wednesday for presenting issues which need plenary decision | - | - | Docs:=0 | - | |
| 4.1 | - | - | - | SA WG1 reporting | - | - | Docs:=1 | - | |
| 4.1 | - | - | - | Block 3: For Block Noting - Wednesday 15:00 UTC | - | - | Docs:=1 | - | |
| 4.1 | SP-200778 | REPORT | Presentation | SA WG1 Report to TSG SA#89e | SA WG1 Chairman | The SA WG1 Chairman presented rev1 of the report. Noted Block 3 | New revision uploaded where slide 8 incorporates all the latest information about future SA1 meetings. Sherry (Xiaomi) requests for clarification about the timeline for R18 new SIDs proposal. Wenruo (Huawei) commented that Rel-18 stage1 timeline should keep open before R-17 timeline is stabilized. It is clear the freeze date of R18 stage 1 should not be earlier than Sept. 2021. With that, it is too early to close the door for any new R18 SID proposal in SA1 in the coming SA1 meeting. Saso (Intel) supports Wenruo's view that the door for new R18 SID proposals in SA1 should remain open at least in Q4. If SA1 is in overload situation, then prioritization exercise should take place. Ming (CATT) supports Wenruo's view and think the door for new R18 SID proposals in SA1 should remain open. If necessary, prioritization exercise on approved Rel-18 SA1 SID should take place either within SA1 or at SA plenary. Tony (Futurewei) supports the view expressed by Huawei, Intel, and CATT regarding the Rel-18 timeline (i.e., kept open till Rel-17 timeline is decided), allowing new Rel-18 proposal till then, and doing prioritization exercise of SA1 SID/WIDs if needed. Tao Sun (China Mobile) share the same view as the previous companies that it is too early to put new SIDs into R19 with the situation that even R17 timeline not fully settled down with likely 6 months delay. We suggest not close the door of R18 stage 1 study in this stage and prioritization within SA1 can be done if considered needed. Telefonica supports the previous statement by China Mobile | Noted | |
| 4.2 | - | - | - | SA WG2 reporting | - | - | Docs:=1 | - | |
| 4.2 | - | - | - | Block 3: For Block Noting - Wednesday 15:00 UTC | - | - | Docs:=1 | - | |
| 4.2 | SP-200670 | REPORT | Presentation | SA WG2 Report to TSG SA | SA WG2 Chairman | Noted Block 3 | Noted | ||
| 4.3 | - | - | - | SA WG3 reporting | - | - | Docs:=1 | - | |
| 4.3 | - | - | - | Block 3: For Block Noting - Wednesday 15:00 UTC | - | - | Docs:=1 | - | |
| 4.3 | SP-200669 | REPORT | Presentation | SA WG3 Status report | SA WG3 Chairman | Noted Block 3 | Noted | ||
| 4.4 | - | - | - | SA WG4 reporting | - | - | Docs:=1 | - | |
| 4.4 | - | - | - | Block 3: For Block Noting - Wednesday 15:00 UTC | - | - | Docs:=1 | - | |
| 4.4 | SP-200658 | REPORT | Presentation | SA WG4 Chairman's Report | 3GPP SA4 | Noted Block 3 | Noted | ||
| 4.5 | - | - | - | SA WG5 reporting | - | - | Docs:=1 | - | |
| 4.5 | - | - | - | Block 3: For Block Noting - Wednesday 15:00 UTC | - | - | Docs:=1 | - | |
| 4.5 | SP-200805 | REPORT | SA WG5 Status Report to SA#89-e | SA WG5 Chairman | Noted Block 3 | Noted | |||
| 4.6 | - | - | - | SA WG6 reporting | - | - | Docs:=1 | - | |
| 4.6 | - | - | - | Block 3: For Block Noting - Wednesday 15:00 UTC | - | - | Docs:=1 | - | |
| 4.6 | SP-200825 | REPORT | Presentation | SA WG6 status report to TSG SA#89 | SA WG6 Chairman | Noted Block 3 | Noted | ||
| 4.7 | - | - | - | TSG RAN reporting and RAN ITU-R Ad Hoc Matters | - | - | Docs:=15 | - | |
| 4.7 | SP-200863 | LS In | Information | LS from TSG RAN: Draft Letter to ITU - Response LS on 3GPP’s activities related to WRC-19 Resolutions | TSG RAN (RP-202054) | To be noted. CC#4: This LS was noted. | Noted | ||
| 4.7 | SP-200866 | LS In | Action | LS from TSG RAN: DRAFT LTI - answer to ITU-R WP5A LS on CONNECTED AUTOMATED VEHICLES (CAV) | TSG RAN (RP-202057) | For endorsement and creating an LS to the PCG. CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200875 | Endorsed | ||
| 4.7 | SP-200875 | LS OUT | Approval | LS to PCG: DRAFT LTI - answer to ITU-R WP5A LS on CONNECTED AUTOMATED VEHICLES (CAV) | TSG SA | Approved at CC#4 | Approved | ||
| 4.7 | SP-200864 | LS In | Action | LS from TSG RAN: DRAFT LTI - answer to ITU-R WP5D LS on DEVEOPMENT OF DRAFT NEW RPORT ITU-R.M[IMT.C-V2X] – APPLICATION OF THE TERRESTRIAL COMPONENT OF IMT FOR CELLULAR-V2X | TSG RAN (RP-202055) | For endorsement and creating an LS to the PCG. CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200873 | Endorsed | ||
| 4.7 | SP-200873 | LS OUT | Approval | LS to PCG: DRAFT LTI - answer to ITU-R WP5D LS on DEVEOPMENT OF DRAFT NEW RPORT ITU-R.M[IMT.C-V2X] – APPLICATION OF THE TERRESTRIAL COMPONENT OF IMT FOR CELLULAR-V2X | TSG SA | Approved at CC#4 | Approved | ||
| 4.7 | SP-200865 | LS In | Action | LS from TSG RAN: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on update submission for LTE-Advanced towards Revision 5 of Recommendation ITU-R M.2012 | TSG RAN (RP-202056) | For endorsement and creating an LS to the PCG. CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200874 | Endorsed | ||
| 4.7 | SP-200874 | LS OUT | Approval | LS to PCG: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on update submission for LTE-Advanced towards Revision 5 of Recommendation ITU-R M.2012 | TSG SA | Approved at CC#4 | Approved | ||
| 4.7 | SP-200867 | LS In | Action | LS from TSG RAN: Draft Letter to ITU in answer to LS to RIT/SRIT Proponents on the completion and conclusions of steps 5 to 7 of the IMT-2020 process for the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] | TSG RAN (RP-202058) | For endorsement and creating an LS to the PCG. CC#4: This was endorsed and a LS OUT to PCG was created by MCC in SP-200876 | Endorsed | ||
| 4.7 | SP-200876 | LS OUT | Approval | LS to PCG: Draft Letter to ITU in answer to LS to RIT/SRIT Proponents on the completion and conclusions of steps 5 to 7 of the IMT-2020 process for the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] | TSG SA | Approved at CC#4 | Approved | ||
| 4.7 | SP-200890 | REPORT | Presentation | Chairmans Report of TSG RAN#89-e | TSG RAN Chairman | CC#5: Noted | Noted | ||
| 4.7 | - | - | - | Block 3: For Block Noting - Wednesday 15:00 UTC | - | - | Docs:=5 | - | |
| 4.7 | SP-200779 | LS In | Information | LS from TSG RAN ITU AH: Draft Letter to ITU - Response LS on 3GPP's activities related to WRC-19 Resolutions | TSG RAN ITU AH (RT-200037) | For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 To: 3GPP PCG, CC: TSG SA. This was block noted at CC#2 Block 3 | Noted | ||
| 4.7 | SP-200780 | LS In | Information | LS from TSG RAN ITU AH: DRAFT LTI - answer to ITU-R WP5A LS on CONNECTED AUTOMATED VEHICLES (CAV) | TSG RAN ITU AH (RT-200039) | For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 to: 3GPP TSG SA in: 3GPP TSG SA feedback LS before: September 18, 2020 to: 3GPP PCG. This was block noted at CC#2 Block 3 | Noted | ||
| 4.7 | SP-200781 | LS In | Information | LS from TSG RAN ITU AH: DRAFT LTI - answer to ITU-R WP5D LS on DEVEOPMENT OF DRAFT NEW RPORT ITU-R.M[IMT.C-V2X] - APPLICATION OF THE TERRESTRIAL COMPONENT OF IMT FOR CELLULAR-V2X | TSG RAN ITU AH (RT-200040) | For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 to: 3GPP TSG SA in: 3GPP TSG SA feedback LS before: September 18, 2020 to: 3GPP PCG. This was block noted at CC#2 Block 3 | Noted | ||
| 4.7 | SP-200782 | LS In | Information | LS from TSG RAN ITU AH: Draft Letter to ITU in reply to ITU_R_WP5D_TEMP_39 = RP-200037 on update submission for LTE-Advanced towards Revision 5 of Recommendation ITU-R M.2012 | TSG RAN ITU AH (RT-200041) | For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 to: 3GPP SA in: 3GPP TSG SA feedback LS before: September 18, 2020 to: 3GPP PCG. This was block noted at CC#2 Block 3 | Noted | ||
| 4.7 | SP-200783 | LS In | Information | LS from TSG RAN ITU AH: Draft Letter to ITU in answer to LS to RIT/SRIT Proponents on the completion and conclusions of steps 5 to 7 of the IMT-2020 process for the first release of new Recommendation ITU-R M.[IMT-2020.SPECS] | TSG RAN ITU AH (RT-200042) | For 3GPP review: in: 3GPP TSG RAN feedback LS before: September 17, 2020 to: 3GPP SA in: 3GPP TSG SA feedback LS before: September 18, 2020 to: 3GPP PCG. This was block noted at CC#2 Block 3 | Noted | ||
| 4.8 | - | - | - | TSG CT reporting | - | - | Docs:=4 | - | |
| 4.8 | SP-200861 | LS In | Action | LS from TSG CT: LS on information of stage 3 aspects for AKMA | TSG CT (CP-202255) | Rel-17 | SA WG3 and SA WG1 will work on CRs that will propose to shift AKMA SA WG3 to Rel-17. Additional changes for separate discussions. Proposal to change BB to Feature for discussion in SA WG3. Noted | Noted | |
| 4.8 | SP-200858 | REPORT | Presentation | Status report of TSG CT#89-e | TSG CT Chairman | Noted | Noted | ||
| 4.8 | SP-200859 | REPORT | Information | Draft report of TSG CT#89-e | TSG CT Secretary (MCC) | Noted | Noted | ||
| 4.8 | SP-200860 | REPORT | Presentation | IETF Status report | TSG CT Chairman | Noted | Noted | ||
| 4.9 | - | - | - | Reports from external bodies | - | - | Docs:=0 | - | |
| 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 | - | |
| 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:=0 | - | |
| 6.1 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=2 | - | |
| 6.2 | - | - | - | Revised Release 16 and earlier Study Item Descriptions and Work Item Descriptions | - | - | Docs:=3 | - | |
| 6.2 | SP-200656 | WID REVISED | Approval | Revised WID on the normative aspects of User Plane Integrity Protection for NR. | Vodafone | Rel-17 | Approved. The 3GPP Work Plan will need to be updated to indicate Rel-16 for UPIP_SEC. | Approved | |
| 6.2 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=2 | - | |
| 6.2 | SP-200763 | WID REVISED | Approval | Revised WID Self-Organizing Networks (SON) for 5G networks. | SA WG5 | Rel-16 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.2 | SP-200770 | WID REVISED | Approval | Revised WID on Discovery of management services in 5G. | SA WG5 | Rel-16 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.3 | - | - | - | New Release 17 Study Item Descriptions | - | - | Docs:=11 | - | |
| 6.3 | SP-200812 | SID NEW | Approval | New Study on User Consent for 3GPP services | Huawei, Hisilicon, China Unicom, CAICT, CATT | Rel-17 | CC#1: SP 200812_r01 was approved (to be revised by MCC). Revised to SP-200885. | Haris (Qualcomm) comments that we can accept approving this SID only with ME box ticked to NO Wenruo (Huawei) provide rev1 to cover Apple and Qualcomm's comment. Request for revision. Apple suggests to add a note in the objectives: Note: Even where solutions exist to obtain user consent, collection and exposure of user sensitive data should be minimised and only be allowed where critical to the operation of the related feature Request for revision. Apple suggests to add a note in the objectives: Note: Even where solutions exist to obtain user consent, collection and exposure of user sensitive data should be minimised and only be allowed where critical to the operation of the related feature | Revised |
| 6.3 | SP-200885 | SID NEW | Approval | New Study on User Consent for 3GPP services | Huawei, HiSilicon, China Unicom, CAICT, CATT | Rel-17 | Revision of SP-200812_Rev1. Approved | Approved | |
| 6.3 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=9 | - | |
| 6.3 | SP-200717 | SID NEW | Approval | New SID on security aspects of the 5GMSG Service. | SA WG3 | CC#2: SP 200717_rev1 was approved. Revised to SP-200878. | Request for Revision. SA6 Chair (Suresh Chitturi) requests the revision of SA3 SID in SP-200717, to align the terminology with SA6 work on MSGin5G service. The changes are fine and were confirmed offline by the rapporteur. Rev1 based on the proposed changes is available in the Revisions folder. | Revised | |
| 6.3 | SP-200878 | SID NEW | Approval | New SID on security aspects of the MSGin5G Service | SA WG3 | Revision of SP-200717_Rev1. Approved | Approved | ||
| 6.3 | SP-200721 | SID NEW | Approval | New study on the security of AMF re-allocation. | SA WG3 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.3 | SP-200722 | SID NEW | Approval | New SID on security aspects of enablers for Network Automation (eNA) for the 5G System (5GS) Phase 2. | SA WG3 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.3 | SP-200765 | SID NEW | Approval | New SID on YANG PUSH. | SA WG5 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.3 | SP-200767 | SID NEW | Approval | New SID on charging aspects of Enhanced Proximity-based Services in 5GC. | SA WG5 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.3 | SP-200771 | SID NEW | Approval | Study on charging aspects of 5GS CIoT. | SA WG5 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.3 | SP-200764 | SID NEW | Approval | New SID on the access control for management service. | SA WG5 | Revised to SP-200853 | Revised | ||
| 6.3 | SP-200853 | SID NEW | Approval | New SID on the access control for management service. | SA WG5 | Revision of SP-200764. Change of 'Other related Work Items and dependencies' as suggested by the Work Plan Manager. This was Block approved in CC#3 Block 4 | Approved | ||
| 6.4 | - | - | - | New Release 17 Work Item Descriptions | - | - | Docs:=12 | - | |
| 6.4 | SP-200718 | WID NEW | Approval | New WID on mission critical security enhancements phase 2. | SA WG3 | CC#3: SP-200718_rev2 was approved. (To be revised into a new TD number by MCC). Revised to SP-200879. | AT&T supports approval of 'New WID on mission critical security enhancements phase 2' in SP-200718. 'Airbus' supports approval of 'New WID on mission critical security enhancements phase 2' in SP-200718 The WID has been revised to correct and extend the list of supporting companies. 'Erillisverkot' supports approval of 'New WID on mission critical security enhancements phase 2' in SP-200718 FirstNet supports approval of 'New WID on mission critical security enhancements phase 2' in SP-200718 The WID has been further revised to extend the list of supporting companies. | Revised | |
| 6.4 | SP-200879 | WID NEW | Approval | New WID on mission critical security enhancements phase 2 | SA WG3 | Revision of SP-200718_Rev2. Approved | Approved | ||
| 6.4 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=10 | - | |
| 6.4 | SP-200667 | WID NEW | Approval | New Work Item on 'Operation Points for 8K VR 360 Video over 5G'. | Intel, NHK, Ericsson LM, AT&T, Qualcomm Incorporated, Dolby Laboratories Inc., Beijing Xiaomi Electronics, Tencent, Huawei Technologies Co Ltd. | Rel-17 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.4 | SP-200719 | WID NEW | Approval | New WID on UPIP support in 5GS. | SA WG3 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.4 | SP-200720 | WID NEW | Approval | New WID on Security Assurance Specification for Network Slice-Specific Authentication and Authorization Function (NSSAAF). | SA WG3 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.4 | SP-200768 | WID NEW | Approval | New WID on N40 Interface Enhancements to Support GERAN and UTRAN. | SA WG5 | Revised to SP-200854 | Revised | ||
| 6.4 | SP-200854 | WID NEW | Approval | New WID on N40 Interface Enhancements to Support GERAN and UTRAN. | SA WG5 | Revision of SP-200768. Alignment of acronym with SA WG2's acronym TEI17_NIESGU. This was Block approved in CC#3 Block 4 | Gerald (Matrixx) suggest the revision on parent WID (2.2) and other WID (2.3) to cover the correct allocation. The SA5 chair does not support the suggestion from Gerald (Matrixx) which suggests the revision on parent WID (2.2) and other WID (2.3) to 'cover the correct allocation'. We switched to having full SA5 features instead of inserting our work items into other groups' features some years ago. The features are gathered by acronym together in the work plan so no need to use the BB structure here. Gerald (Matrixx) is asking MCC to resolve the observation on different handling on WIDs in the 3GPP work plan. | Approved | |
| 6.4 | SP-200769 | WID NEW | Approval | New work item on charging enhancement for URLLC. | SA WG5 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.4 | SP-200772 | CR PACK | Approval | Rel-17 CRs on Mission critical security enhancements phase 2 | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 6.4 | SP-200831 | WID NEW | Approval | New WID for enhanced application layer support for V2X services. | SA WG6 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.4 | SP-200832 | WID NEW | Approval | New WID Application Architecture for MSGin5G Service. | SA WG6 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.4 | SP-200833 | WID NEW | Approval | New WID Mission Critical Services over 5GS. | SA WG6 | This was Block approved in CC#3 Block 4 | Approved | ||
| 6.5 | - | - | - | Revised Release 17 Study Item and Work Item Descriptions | - | - | Docs:=7 | - | |
| 6.5 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=7 | - | |
| 6.5 | SP-200690 | SID REVISED | Approval | Revised SID: Architectural enhancements for 5G multicast-broadcast services. | SA WG2 | Rel-17 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.5 | SP-200766 | SID NEW | Approval | New SID on network slice management enhancement to include security aspects. | SA WG5 | This was Block approved in CC#3. CC#4: WGs to avoid agreeing to multiple rapporteurs for WIDs and SIDs. Block 4 | Approved | ||
| 6.5 | SP-200834 | WID REVISED | Approval | Revised WID on Architecture for enabling Edge Applications . | SA WG6 | Rel-17 | CC#2: SP 200834_rev1 was approved. Revised to SP-200886. | Gerald (Matrixx) requests the revision to cover charging management aspects. Suresh Chitturi (SA6 Chair): SP-200834_Rev1 is provided with the help of Rapporteur, taking into account the feedback from Gerald (Matrixx). In addition to Charging aspects from SA5, study on Edge management aspects from SA5 and security enhancements for Edge from SA3 have also been included in the clause 2.3 Other related work-items. Gerald (Matrixx) is fine with the revision. | Revised |
| 6.5 | SP-200886 | WID REVISED | Approval | Revised WID on Architecture for enabling Edge Applications . | SA WG6 | Rel-17 | Revision of SP-200834_Rev1. Approved | Approved | |
| 6.5 | SP-200835 | SID REVISED | Approval | Revised SID Study on support of the 5GMSG Service. | SA WG6 | Rel-17 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.5 | SP-200836 | SID REVISED | Approval | Revised SID Study on application layer support for . Factories of the Future in 5G network . | SA WG6 | Rel-17 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.5 | SP-200837 | SID REVISED | Approval | Revised SID Study on Mission Critical services support over 5G System. | SA WG6 | Rel-17 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.6 | - | - | - | New Release 18 Study Item Descriptions | - | - | Docs:=4 | - | |
| 6.6 | SP-200821 | Discussion | Discussion | Study on Support _x00B_for Service Function Chaining in 5G System (FS_SFCin5GS) | Intel, Deutsche Telekom AG, Tencent, Telefónica, Affirmed Network, AT&T, Sandvine, Convida Wireless, InterDigital, KPN, Verizon UK Ltd., KDDI, Vodafone, Telecom Italia, Cisco, b<>com, Spirent Communications | Rel-18 | Noted | Noted | |
| 6.6 | SP-200822 | SID NEW | Approval | New SID on Study on Support for Service Function Chaining in 5G System. | Intel Corporation, Deutsche Telekom AG, Tencent, Telefónica, Affirmed Network, AT&T, Sandvine, Convida Wireless, InterDigital, KPN, Verizon UK Ltd., KDDI, Vodafone, Telecom Italia, Cisco, b<>com, Spirent Communications | Rel-18 | CC#1: This was left for further consideration over e-mail. CC#3: This issue will be handled further in SA WG1. Saso will provide a WID proposal for discussion on Friday. CC#4: Postoned | Saso (Intel) initiates discussion thread on SP-200822. Nokia has concerns with approving a SID on this topic as we believe that the best course of action would be to ask companies to propose a WID and related CRs in Q4 with the delta requirements that are not yet captured in TS 22.261 ( also by inheritance of those in TS 22.101 clause 30). Patrice (Huawei) provides concerns, and proposes that discussion continues further in WGs before we can approve something (for minutiae: objects to the original paper). Adrian (vivo) asks a question for clarification. Krister (Ericsson) has the same view as expressed by Huawei. In addition pointing out that the 22.261 has the requirement that , the 5G system shall support all EPS capabilities (e.g. from TSs 22.011, 22.101, 22.278, 22.185, 22.071, 22.115, 22.153, 22.173, 22.468), In SA1 we are with term 5G System including SA2 N6-LAN as part of 5G System. Saso (Intel) replies to comments. Seeks clarification from SA1 Chairman. Saso (Intel) provides SP-200822rev1. Adrian (vivo) suggest to move completion date to June 2021. Saso (Intel) prefers keeping the completion date to Mar 2021. Haris (Qualcomm) comments on ticking the ME and AN boxes to NO Saso (Intel) provides rev2 with ME impact changed to 'No'. Patrice (Huawei) manages to propose a draft revision (in the drafts folder) that could be something we could work with in such a short notice. Saso (Intel) provides rev4. | Postponed |
| 6.6 | SP-200798 | SID NEW | Approval | New SID: Study on vehicle-mounted relays (FS_VMR). | SA WG1 | CC#3: China Mobile withdrew their objection. Approved | Tao (China Mobile) objects to SP-200798 and all its revisions. The SID is related with RAN on-going R17 work. In view of potential delay of R17, we believe neither it is right time nor need a study. With the understanding that requirement gap can be identified in study phase, as clearly stated in this SID, Tao Sun (China Mobile) recall the objection. China Mobile expect the same chance and raise the concern that R18 stage 1 Study proposal cannot move forward after 6 month effort with two companies' claim of insufficient gap analysis even contributors provided discussion paper, online and offline clarifications, long list of supporting companies, merge multiple proposals as requested. | Approved | |
| 6.6 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 6.6 | SP-200799 | SID NEW | Approval | New SID: Study on 5G Networks Providing Access to Localized Services (FS_PALS). | SA WG1 | Rel-18 | CC#3: China Mobile withdrew their objection. Approved | Tao (China Mobile) objects to SP-200799 and all its revisions. The SID shall justified why current VIAPA, NPN, slicing, QoS, edge computing cannot meet the requirement. With the understanding that requirement gap can be identified in study phase, as clearly stated in this SID, Tao Sun (China Mobile) recall the objection. China Mobile expect the same chance and raise the concern that R18 stage 1 Study proposal cannot move forward after 6 month effort with two companies' claim of insufficient gap analysis even contributors provided discussion paper, online and offline clarifications, long list of supporting companies, merge multiple proposals as requested. | Approved |
| 6.7 | - | - | - | New Release 18 Work Item Descriptions | - | - | Docs:=1 | - | |
| 6.7 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 6.7 | SP-200797 | WID NEW | Approval | New WID on Subscriber-aware Northbound API access (SNA). | SA WG1 (from S1-203296) | Rel-18 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.8 | - | - | - | Revised Release 18 Study Item Descriptions and Work Item Descriptions | - | - | Docs:=0 | - | |
| 6.8 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 6.9 | - | - | - | Specifications for Information | - | - | Docs:=15 | - | |
| 6.9 | SP-200762 | DRAFT TS | Approval | Draft TS 28.555 'Network policy management for 5G mobile networks; Stage 1' | SA WG5 | Rel-17 | Revised in SP-200820 | Revised | |
| 6.9 | SP-200820 | DRAFT TS | Information | Draft TS 28.555 'Network policy management for 5G mobile networks; Stage 1' | SA WG5 | Rel-17 | Revision of SP-200762. Noted | Noted | |
| 6.9 | - | - | - | Block 4: For Block Noting - Thursday 15:00 UTC | - | - | Docs:=13 | - | |
| 6.9 | SP-200691 | DRAFT TR | Information | Presentation of TR 23.748 for information to TSG SA (FS_enh_EC) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200692 | DRAFT TR | Information | Presentation of TR 23.700-20 for information to TSG SA (FS_IIoT) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200693 | DRAFT TR | Information | Presentation of TR 23.761 for information to TSG SA (FS_MUSIM) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200694 | DRAFT TR | Information | Presentation of TR 23.700-91 for Information to TSG SA (FS_eNA_Ph2) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200695 | DRAFT TR | Information | Presentation of presentation of TR 23.700-07 for information to TSG SA (FS_eNPN) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200696 | DRAFT TR | Information | Presentation of TR 23.757 for information to TSG SA (FS_5MBS) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200698 | DRAFT TR | Information | Presentation of TR 23.700-40 to TSG SA for information (FS_eNS_Ph2) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200699 | DRAFT TR | Information | Presentation of TR 23.700-93 to TSG SA for information (FS_ATSSS_Ph2) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200700 | DRAFT TR | Information | Presentation of TR 23.754 for information to TSG SA (FS_ID_UAS_SA2) | SA WG2 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200755 | DRAFT TR | Information | Draft TR 28.809 'Study on enhancement of management data analytics' | SA WG5 | Rel-16 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200828 | DRAFT TS | Information | Presentation of TS 23.558 v1.0.0 for information | SA WG6 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200829 | DRAFT TR | Information | Presentation of TR 23.745 v1.0.0 for information | SA WG6 | Rel-16 | This was block noted in CC#3 Block 4 | Noted | |
| 6.9 | SP-200830 | DRAFT TR | Information | Presentation of TR 23.700-24 v1.0.0 for information | SA WG6 | Rel-17 | This was block noted in CC#3 Block 4 | Noted | |
| 6.10 | - | - | - | Specifications for Approval / for Information and Approval | - | - | Docs:=9 | - | |
| 6.10 | - | - | - | Block 4: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=9 | - | |
| 6.10 | SP-200666 | DRAFT TS | Approval | Draft TS 26.512: 5G Media Streaming (5GMS); Protocols | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.10 | SP-200756 | DRAFT TR | Approval | Draft TR 28.812 'Study on scenarios for Intent driven management services for mobile networks' | SA WG5 | Rel-17 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.10 | SP-200757 | DRAFT TS | Approval | Draft TS 28.309 'Management of Quality of Experience (QoE) measurement collection Integration Reference Point (IRP); Solution Set (SS) definitions' | SA WG5 | Rel-16 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.10 | SP-200758 | DRAFT TS | Approval | Draft TS 28.313 'Study on new aspects of Energy Efficiency (EE) for 5G' | SA WG5 | Rel-16 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.10 | SP-200759 | DRAFT TR | Approval | Draft TR 28.810 'Study on concept, requirements and solutions for levels of autonomous network' | SA WG5 | Rel-16 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.10 | SP-200760 | DRAFT TS | Approval | Draft TS 28.201 'Network slice performance and analytics charging in the 5G System (5GS); Stage 2' | SA WG5 | Rel-16 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.10 | SP-200761 | DRAFT TS | Approval | Draft TS 28.202 'Network slice management charging in the 5G System (5GS); Stage 2' | SA WG5 | Rel-16 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.10 | SP-200826 | DRAFT TS | Approval | Presentation of TS 23.180 v2.0.0 for approval | SA WG6 | Rel-17 | This was Block approved in CC#3 Block 4 | Approved | |
| 6.10 | SP-200827 | DRAFT TR | Approval | Presentation of TR 23.764 v2.0.0 for approval | SA WG6 | Rel-17 | This was Block approved in CC#3 Block 4 | Approved | |
| 7 | - | - | - | Release Planning | - | - | Docs:=0 | - | |
| 7.1 | - | - | - | General Release Planning issues | - | - | Docs:=2 | - | |
| 7.1 | SP-200815 | DISCUSSION | Information | 3GPP Meeting Planning H1/2021 | TSG SA Chairman | Noted | Noted | ||
| 7.1 | SP-200819 | DISCUSSION | Endorsement | Thoughts about enumerating SA WG1 requirements | Siemens, Philips | Rel-18 | CC#3: TSG SA Chairman will start a moderated TSG SA e-mail discussion on the enumeration issue until the next TSG SA meeting. This was then noted. | LG Electronics indicates the facts that it is beneficial to have requirements enumerated in some specifications, if not all, and that the idea of enumeration can be made 'Recommended Practice' within a WG, which means that if enumeration of some requirements of a certain TR or TS is considered needed, it can be done in that particular WG but it does not have to be enforced. Generalization of this idea of enumeration may require careful consideration and examination as maintenance of them, if happens, is a different story requiring different dimension of complexity compared to the benefit it seems to bring in. No discussion for 21.801 is necessary. LG Electronics proposes the following sentence to be added to the revision of SP-200819 for endorsement. The enumeration of requirements of a TR/TS is recommended on a need basis but is not necessarily required for all TR/TS's. The requirement numbers go with the TR/TS version, which mean they might be different in a different version of the TR/TS, i.e., changed, deleted, or replaced along with how an existing requirement is destined to be in the next version of TR/TS during the casual course of work, including changes by technical (p)CRs and/or maintenance CRs. Adrian (vivo) asks LG what do they mean 'on a need basis?' In response to NCSC's comment, LG provides the following: The enumeration of requirements of a TR/TS is recommended on a need basis but is not necessarily required for all TR/TS's. The requirement numbers go with the TR/TS version, and are recommended not to change drastically in order to keep the ease of reference unless there are relevant reasons (e.g., deletion, merge, relocation, etc.) which mean they might be different in a different version of the TR/TS, i.e., changed, deleted, or replaced along with how an existing requirement is destined to be in the next version of TR/TS during the casual course of work, including changes by technical (p)CRs and/or maintenance CRs. Haris (Qualcomm) would like to see first a CR to TR 21.801 before agreeing on this idea of enumerating SA1 requirements endorsed officially. Recommends to have some email discussion e.g. moderated by someone, that will discuss all aspects mentioned below and we can come to some smooth discussion in SA#90e. Tony (Futurewei) would like to support the enumeration of the requirements in stage-1 specifications with the understanding that procedures for doing so will be captured/specified officially. Ki-Dong (LGE) raises comments on what Puneet (SA2 Chairman) responded to Adrian(Vivo) to clarify that we do not need both mappings (e.g., b/w CPR and PR, CPR and UC) but one mapping table between CPRs and PRs is enough for traceability purposes as long as PRs come with clause numbers. Puneet (SA2 Chairman) responds to Adrian(Vivo). Adrian (vivo) support the enumeration of the requirements in stage-1 specifications and asks Puneet a question for clarification. Puneet (SA2 Chairman) support the enumeration of the requirements in stage-1 specifications. Proposes further enhancements. Ericsson wants to point out that it should not be any tracking process between SA1 TRs and TSs. The reason is that potential requirements are just potential and important that there is a freedom to change requirements in normative work, even beyond recognition. As we work consensus based that should be the principle. Siemens agrees with Ericson that there should not be any tracking process between SA1 TRs and TSs and points out that SP-200819 does not stipulate such process. Siemens also thinks that a change to a 21 document, for instance TR 21.801, is needed before requirement enumeration in Stage-1 specifications can become officially endorsed by SA. Siemens also agrees with Qualcomm that a pertinent CR should be discussed on the email reflector before presenting it at SA#90-e. Johannes (Deutsche Telekom) does see a heavy overcomplication of introducing the need for requirements numbering and objects to endorsing a guidance before this is discussed in more details, potentially ending up in a CR to the drafting rules in TR 21.801. Siemens uploaded SP-200819rev01 to the Revisions folder. Changes made: added Daimler and Sennheiser as source; included a sentence in clause 3.1, stating that the requirements in technical specifications do not track potential and consolidated potential requirements in technical reports. Huawei support to develop a mechanism to better trace the requirements in stage-1. This is beneficial not only for verticals but also for coordination between SA1 and other WGs. We would also like to see a CR capturing the details in 21.801 and we can have an offline email discussion on it, and target to provide the concrete mechanism in next plenary. Whether we implement it to all the specifications in SA1 can also be discussed once the mechanism is clear. ZTE prefers to stick to existing drafting rule and does not support the enumerating of requirement. Philips responds to ZTE and DT. Jinguo response to Philips and is fine if the enumerating requirement is only applied to SA1. Johannes (Duetsche Telekom) asks for clarification on the proposal from SA1 chair: currently we have SA1 CRs submitted to this plenary even for Rel16 specs to implement the enumeration of requirements before we have concluded on a way forward. Do we postpone these CRs for a treatment in SA#90-e? | Noted |
| 7.2 | - | - | - | Issues related to Release 16 and earlier planning (nothing expected here) | - | - | Docs:=0 | - | |
| 7.3 | - | - | - | Release 17 Planning (schedule, prioritization, etc.) | - | - | Docs:=4 | - | |
| 7.3 | SP-200800 | DISCUSSION | Approval | On Release 17 Schedule | Qualcomm Incorporated | Rel-17 | Noted | Haris (Qualcomm) comments on the rel.17 timescales discussion Puneet (SA2 Chairman) provides a proposal on SA guidance on Rel-17 timelines Haris (Qualcomm) comments on the proposal Adrian (vivo) comments on the rel.17 timescales discussion Tony (Futurewei) comments on the proposal. Puneet (SA2 Chairman) provides a response. Adrian (vivo) provides an updated proposal on SA guidance on Rel-17 timelines LaeYoung (LGE) asks some questions for clarification. Miikka (Nokia) provides an updated proposal on SA guidance on Rel-17 timelines Andy (Samsung) provides an updated proposal on SA guidance on Rel-17 timelines. Jianhua(OPPO) would like to clarify clearly SA2 can have exceptions for Items or KIs which has dependency with other WGs progress if they can not be concluded in December,2020. Haris (Qualcomm) also supports the modified text from Miikka Krister (Ericsson) supports to be clear on what is expected by December completion of study items and new WIDs. Adrian (vivo) asks a question for clarification on the modification made by LaeYoung. Tricci (ZTE) asks for clarification for new wordings from LaeYoung. LaeYoung (LGE) answers to Q from Tricci (ZTE) and Adrian (vivo). Tony (Futurewei) comments on latest proposed text. Puneet (SA2 Chairman) provides the updated text. LaeYoung (LGE) can support the latest proposed text by Puneet (SA2 Chair). Tony (Futurewei) supports the latest proposed text by Puneet. Yusuke (KDDI) would like to support the latest proposed text by Puneet. Adrian (vivo) would like to support the latest proposed text by Puneet. Ming (CATT) would like to support the latest proposed text by Puneet. Tricci (ZTE) would like to support the latest proposed text by Puneet. Krister (Ericsson) would like to support the latest proposed text by Puneet. Johannes (Deutsche Telekom) supports the CT chair to also list CT in the action as there is also stage2 work to be finalized in time. Addition of text is proposed. Krisztian (Apple) supports the below proposed text by Puneet. Puneet (SA2 Chairman) provides draft LS OUT in the revision folder. Puneet (SA2 Chairman) provides r01 in the revision folder. Puneet (SA2 Chairman) provides r02 in the revision folder. | Noted |
| 7.3 | SP-200811 | DISCUSSION | Agreement | Discussion on Rel-17 Schedule | Huawei, HiSilicon | Rel-17 | Noted | Haris (Qualcomm) comments on the rel.17 timescales discussion Puneet (SA2 Chairman) provides a proposal on SA guidance on Rel-17 timelines Haris (Qualcomm) comments on the proposal Adrian (vivo) comments on the rel.17 timescales discussion Tony (Futurewei) comments on the proposal. Puneet (SA2 Chairman) provides a response. Adrian (vivo) provides an updated proposal on SA guidance on Rel-17 timelines LaeYoung (LGE) asks some questions for clarification. Miikka (Nokia) provides an updated proposal on SA guidance on Rel-17 timelines Andy (Samsung) provides an updated proposal on SA guidance on Rel-17 timelines. Jianhua(OPPO) would like to clarify clearly SA2 can have exceptions for Items or KIs which has dependency with other WGs progress if they can not be concluded in December,2020. Haris (Qualcomm) also supports the modified text from Miikka Krister (Ericsson) supports to be clear on what is expected by December completion of study items and new WIDs. Adrian (vivo) asks a question for clarification on the modification made by LaeYoung. Tricci (ZTE) asks for clarification for new wordings from LaeYoung. LaeYoung (LGE) answers to Q from Tricci (ZTE) and Adrian (vivo). Tony (Futurewei) comments on latest proposed text. Puneet (SA2 Chairman) provides the updated text. LaeYoung (LGE) can support the latest proposed text by Puneet (SA2 Chair). Tony (Futurewei) supports the latest proposed text by Puneet. Yusuke (KDDI) would like to support the latest proposed text by Puneet. Adrian (vivo) would like to support the latest proposed text by Puneet. Ming (CATT) would like to support the latest proposed text by Puneet. Tricci (ZTE) would like to support the latest proposed text by Puneet. Krister (Ericsson) would like to support the latest proposed text by Puneet. Johannes (Deutsche Telekom) supports the CT chair to also list CT in the action as there is also stage2 work to be finalized in time. Addition of text is proposed. Krisztian (Apple) supports the below proposed text by Puneet. | Noted |
| 7.3 | SP-200862 | LS OUT | Approval | [DRAFT] LS on R17 schedule | TSG SA | CC#3: A corrected version was provided in the revisions folder as SP-200862_rev1. CC#4: SP-200862_Rev2 approved. Revised to SP-200888. | Revised | ||
| 7.3 | SP-200888 | LS OUT | Approval | LS on Rel-17 schedule | TSG SA | Revision of SP-200862_Rev2. Approved | Approved | ||
| 7.4 | - | - | - | Release 18 Planning (schedule, prioritization, etc.) | - | - | Docs:=0 | - | |
| 8 | - | - | - | Rel-8 CRs | - | - | Docs:=0 | - | |
| 8 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 9 | - | - | - | Rel-9 CRs | - | - | Docs:=0 | - | |
| 9 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 10 | - | - | - | Rel-10 CRs | - | - | Docs:=1 | - | |
| 10 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 10 | SP-200728 | CR PACK | Approval | Rel-10 CRs on TEI | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 11 | - | - | - | Rel-11 CRs | - | - | Docs:=1 | - | |
| 11 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 11 | SP-200727 | CR PACK | Approval | Rel-11 CRs on TEI | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 12 | - | - | - | Rel-12 CRs | - | - | Docs:=1 | - | |
| 12 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 12 | SP-200726 | CR PACK | Approval | Rel-12 CRs on TEI | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 13 | - | - | - | Rel-13 CRs | - | - | Docs:=1 | - | |
| 13 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 13 | SP-200714 | CR PACK | Approval | Rel-13 CRs on Enhancements to WEBRTC interoperability | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 14 | - | - | - | Rel-14 CRs | - | - | Docs:=0 | - | |
| 14 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 15 | - | - | - | Rel-15 CRs | - | - | Docs:=12 | - | |
| 15 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=12 | - | |
| 15 | SP-200671 | CR PACK | Approval | CRs to 23.501, 23.502 on 5GS_Ph1 (Rel-15, Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200672 | CR PACK | Approval | CRs to 23.401 on NB_IOTenh-Core, CIoT_ext (Rel-15, Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200702 | CR PACK | Approval | Rel-15 CRs on Security Assurance Specification for eNB network product class | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200709 | CR PACK | Approval | Rel-15 CRs on Security aspects of 5G System - Phase 1 batch 1 | SA WG3 | This was Block approved in CC#3 Block 5 | CR 00908 33501 belonging to the CR pack SP-200709 belongs to the wrong specification and hence it should be removed from the pack. The previous comment was made against the wrong document: CR 00908 33501 in CR pack SP-200706 and not SP-200709 belongs to the wrong specification and hence it should be removed from the pack. | Approved | |
| 15 | SP-200725 | CR PACK | Approval | Rel-15 CRs on TEI | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200730 | CR PACK | Approval | Rel-15 CRs on Network Resource Model (NRM) for 5G networks and network slicing | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200731 | CR PACK | Approval | Rel-15 CRs on Performance Assurance for 5G networks including network slicing | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200735 | CR PACK | Approval | Rel-15 CRs on Provisioning of network slicing for 5G networks and services | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200736 | CR PACK | Approval | Rel-15 CRs on Management and orchestration of 5G networks and network slicing | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200742 | CR PACK | Approval | Rel-15 CRs on Service Based Interface for 5G Charging | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200773 | CR PACK | Approval | Rel-15 CRs on Security aspects of 5G System - Phase 1 Batch 2 | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 15 | SP-200806 | CR PACK | Approval | Rel-15 CRs on Lawful Interception | SA WG3-LI | Rel-15 | This was Block approved in CC#3 Block 5 | Approved | |
| 16 | - | - | - | Rel-16 CRs | - | - | Docs:=2 | - | |
| 16 | SP-200657 | CR | Approval | 21.900 CR0064 (Rel-16, 'C'): CR to TR 21.900 on Relaxation of mini-WID requirement for Cat.B/C TEI CRs | NEC on behalf of TSG RAN | Rel-16 | Same as draft CR proposed by TSG RAN in SP-200868. CC#4: Postponed | Saso (Intel) recommends approving the CR in SP-200657. Johannes (Deutsche Telekom) comments on the missing/vague justification of the CR. Hans (NEC) added several examples of how RAN is providing transparency. Saso (Intel) comments. Xiaobao (Orange ) asks for the clarification of 'an alternative process' and questions if the propose change should be applied to the description of TEI. Hans (NEC) responded to the SA Chairman's point on desirability of common procedures between the TSGs, agreeing in principle, but indicating that this also requires a consensus across the TSGs in advance of introducing such procedures and that the mini-WID procedure had been introduced before such consensus could be achieved. Andy (Samsung) comments. Alessio(nokia) expresses concerns on approving the CR in SP-200657 Xiaobao (Orange ) asks for the clarification of 'an alternative process' and questions if the propose change should be applied to the description of TEI. | Postponed |
| 16 | SP-200868 | LS In | Action | LS from TSG RAN: LS on Relaxation of mini-WID requirement for Cat.B/C TEI CRs | TSG RAN (RP-202001) | Rel-16 | Attached CR is the same change as in SP-200657. CC#4: This LS was postponed. | Saso (Intel) recommends approving the CR in SP-200657. Johannes (Deutsche Telekom) comments on the missing/vague justification of the CR. Hans (NEC) added several examples of how RAN is providing transparency. Saso (Intel) comments. Xiaobao (Orange ) asks for the clarification of 'an alternative process' and questions if the propose change should be applied to the description of TEI. Hans (NEC) responded to the SA Chairman's point on desirability of common procedures between the TSGs, agreeing in principle, but indicating that this also requires a consensus across the TSGs in advance of introducing such procedures and that the mini-WID procedure had been introduced before such consensus could be achieved. Andy (Samsung) comments. Alessio(nokia) expresses concerns on approving the CR in SP-200657 Xiaobao (Orange ) asks for the clarification of 'an alternative process' and questions if the propose change should be applied to the description of TEI. | Postponed |
| 16.1 | - | - | - | SA WG1 Rel-16 CRs | - | - | Docs:=15 | - | |
| 16.1 | SP-200790 | CR PACK | Approval | Stage 1 CRs on eCAV | SA WG1 | CC#4: 22.261 CR0462R2 revised in SP-200869. 22.104 0053r1 and 22.261 0465r1 were postponed. The other CRs in this CR pack were approved | The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1 LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed/corrected. Haris (Qualcomm) comments that this CR pack relates to the discussion of enumeration of requirements in SP-200819 and wants to flag it up for discussion | Partially approved | |
| 16.1 | SP-200869 | CR | Approval | 22.261 CR0462R3 (Rel-17, 'D'): Quality improvement of TS 22.261 (R17) – editorial modifications | Siemens | Rel-17 | Revision of 22.261 CR0462R2 from CR Pack SP-200790. CC#4: SP-200869_Rev3 was approved. Revised to SP-200889. | Revised | |
| 16.1 | SP-200889 | CR | Approval | 22.261 CR0462R4 (Rel-17, 'D'): Quality improvement of TS 22.261 (R17) – editorial modifications | Siemens | Rel-17 | Revision of SP-200869. Approved | Approved | |
| 16.1 | SP-200784 | CR PACK | Approval | Stage 1 CRs on cyberCAV | SA WG1 | CC#3: 22.104 CR0054r1 and 22.261 CR0464 removed from the pack for further discussion (postponed). The other CRs in this CR Pack were approved. (This CR Pack was partially approved). | Partially approved | ||
| 16.1 | SP-200791 | CR PACK | Approval | Stage 1 CRs on ID_UAS | SA WG1 | CC#3: SP-200791_Rev1 was approved. (To be revised by MCC to provide a new TD number). Revised to SP-200881. | The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1 LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed/corrected. | Revised | |
| 16.1 | SP-200881 | CR | Approval | 22.125 CR0028R6 (Rel-17, 'F'): Stage 1 CRs on ID_UAS | SA WG1 | Revision of 22.125 CR0028R5 in SP-200791_Rev1. Approved | Approved | ||
| 16.1 | SP-200793 | CR PACK | Approval | Stage 1 CRs FS_FRMCS3 | SA WG1 | CC#3: SP-200793_Rev1 was approved. (To be revised by MCC to provide a new TD number). Revised to SP-200882. | The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1 LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed/corrected. | Revised | |
| 16.1 | SP-200882 | CR | Approval | 22.889 CR0169R3 (Rel-17, 'F'): Stage 1 CRs FS_FRMCS3 | SA WG1 | Revision of 22.889 CR0169R2 in SP-200793_Rev1. Approved | Approved | ||
| 16.1 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=7 | - | |
| 16.1 | SP-200785 | CR PACK | Approval | Stage 1 CRs on REAR | SA WG1 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.1 | SP-200786 | CR PACK | Approval | Stage 1 CRs on MARCOM | SA WG1 | This was Block approved in CC#3 Block 5 | Ki-Dong (LG Electronics) provides the following comments on 22119_CR0004r1 (of SP-200786): (1) CR0003r1 has minor leftovers cause by the first round of revision, to correct: In the main text, some references are no longer existent, i.e., [36], [37]. (2) FYI - the 2nd requirement of clause 7.1.2 was agreed to be removed by anther CR (maintenance CR, 22119_CR0003r1, LGE). This collision doesn't seem to be a problem at all as long as the maintenance can override the other. | Approved | |
| 16.1 | SP-200787 | CR PACK | Approval | Stage 1 CRs on 5GSAT | SA WG1 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.1 | SP-200788 | CR PACK | Approval | Stage 1 CRs on UIA | SA WG1 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.1 | SP-200789 | CR PACK | Approval | Stage 1 CRs on TEI16 | SA WG1 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.1 | SP-200792 | CR PACK | Approval | Stage 1 CRs on AVPROD | SA WG1 | This was Block approved in CC#3 Block 5 | The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1 LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed/corrected. | Approved | |
| 16.1 | SP-200794 | CR PACK | Approval | Stage 1 CRs on TEI17 | SA WG1 | This was Block approved in CC#3 Block 5 | The tdocs SP-200790 to SP-200794 were submitted under agenda item 16.1 but include SA1 CRs against Rel-17 specs. Therefore they are shifted to Agenda Item 17.1 LG Electronics raises hands for minor admin stuff: (1) SP-200791 is an R17 CR but is using an R16 WI code (not a mirror from R16) (2) SP-200793 is using an R16 WI code (FS_FRMCS2 is not for R17). These may be addressed/corrected. | Approved | |
| 16.2 | - | - | - | SA WG2 Rel-16 CRs | - | - | Docs:=18 | - | |
| 16.2 | SP-200685 | CR PACK | Approval | CRs to 23.401, 23.502 on RACS (Rel-16) | SA WG2 | Company proposed revision of 23.501 CR2383R1 in SP-200802. CC#1: 23.501 CR2383R1 was considered as revised and other CRs in this CR pack were approved. | Partially approved | ||
| 16.2 | SP-200802 | CR | Approval | 23.501 CR2383R2 (Rel-16, 'F'): Signalling of UE Radio Capability ID in Registration procedure | Qualcomm Incorporated | Rel-16 | Revision of S2-2006493 (23.501 CR2383R1) in CR Pack SP-200685. CC#1: Vodafone supported this CR. This CR was approved. This CR was agreed | Approved | |
| 16.2 | SP-200688 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 on Vertical_LAN (Rel-16) | SA WG2 | CC#1: 23.501 CR2448R1 was reported needing further work and was postponed. All other CRs in this CR pack were approved. | Haris (Qualcomm) objects to 23501 CR2448r1 (S2-2005899) from this CR pack | Partially approved | |
| 16.2 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=15 | - | |
| 16.2 | SP-200673 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 on 5G_CIoT (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200674 | CR PACK | Approval | CRs to 23.501, 23.502 on 5G_eSBA (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200675 | CR PACK | Approval | CR to 23.501 on 5G_URLLC (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200676 | CR PACK | Approval | CRs to 23.316, 23.502 on 5WWC (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200677 | CR PACK | Approval | CR to 23.501 on ATSSS (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200678 | CR PACK | Approval | CRs to 23.228, 23.501 on eIMS5G_SBA (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200679 | CR PACK | Approval | CRs to 23.228, 23.502, 23.503 on eNA (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200680 | CR PACK | Approval | CRs to 23.502 on eNS (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200681 | CR PACK | Approval | CRs to 23.502 on ETSUN (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200682 | CR PACK | Approval | CRs to 23.285, 23.287, 23.502, 23.503 on eV2XARC (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200683 | CR PACK | Approval | CR to 23.501 on IABARC (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200684 | CR PACK | Approval | CR to 23.401 on PARLOS (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200686 | CR PACK | Approval | CRs to 23.214, 23.501, 23.502, 23.682 on TEI16 (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200687 | CR PACK | Approval | CR to 23.501 on UDICOM (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.2 | SP-200689 | CR PACK | Approval | CR to 23.502 on xBDT (Rel-16) | SA WG2 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.3 | - | - | - | SA WG3 and SA WG3 LI Rel-16 CRs | - | - | Docs:=11 | - | |
| 16.3 | SP-200706 | CR PACK | Approval | Rel-16 CRs on Security for enhancements to the Service Based 5G System Architecture | SA WG3 | 33.501 CR0908R1 should be a CR to 33.310, so should be rejected. Replacement CR to 33.310 provided in SP-200857. 33.501 CR0908R1 was rejected. Al other CRs in this CR Pack were approved | CR 00908 33501 in CR pack SP-200706 belongs to the wrong specification and hence it should be removed from the pack. | Partially approved | |
| 16.3 | SP-200857 | CR | Approval | 33.310 CR0112 (Rel-16, 'F'): Making NF instance id in SBA certificate profile mandatory to support | Nokia | Rel-16 | Incorrect TS was specified in the SA WG3 TD request. New CR allocated at TSG SA#89-e. CC#3: This CR was approved. | Approved | |
| 16.3 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=9 | - | |
| 16.3 | SP-200701 | CR PACK | Approval | Rel-16 CRs on TEI | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.3 | SP-200703 | CR PACK | Approval | Rel-16 CRs on Security Assurance Specification for 5G | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.3 | SP-200705 | CR PACK | Approval | Rel-16 CRs on Security Aspects of eV2XARC | SA WG3 | CC#1: 33.536 CR0002 was reported needing further work and was postponed. All other CRs in this CR pack were approved. | CR 33.536 0002 S3-201609 should have been revised to include the changes agreed during the SA3 meeting. The version included in this pack is not the one agreed by the group and hence must be withdrawn. | Partially approved | |
| 16.3 | SP-200707 | CR PACK | Approval | Rel-16 CRs on Security for IAB | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.3 | SP-200708 | CR PACK | Approval | Rel-16 CRs on Authentication and key management for applications based on 3GPP credential in 5G | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.3 | SP-200710 | CR PACK | Approval | Rel-16 CRs on User Plane Gateway Function for Inter-PLMN Security | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.3 | SP-200715 | CR PACK | Approval | Rel-16 CRs on Security aspects of SEAL | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.3 | SP-200716 | CR PACK | Approval | Rel-16 CRs on Security aspects of Enhanced Network Slicing | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.3 | SP-200807 | CR PACK | Approval | Rel-16 CRs on Lawful Interception | SA WG3-LI | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | - | - | - | SA WG4 Rel-16 CRs | - | - | Docs:=9 | - | |
| 16.4 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=9 | - | |
| 16.4 | SP-200659 | CR PACK | Approval | CRs to TS 26.116 | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | SP-200660 | CR PACK | Approval | CRs to TS 26.223 | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | SP-200661 | CR PACK | Approval | CRs to TS 26.234 | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | SP-200662 | CR PACK | Approval | CRs to TS 26.238 | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | SP-200663 | CR PACK | Approval | CRs to TS 26.501 | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | SP-200664 | CR PACK | Approval | CRs to TS 26.511 | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | SP-200665 | CR PACK | Approval | CRs to TS 26.114 | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | SP-200668 | CR PACK | Approval | CR to 26.247 | SA WG4 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.4 | SP-200804 | CR PACK | Approval | CRs to RM_H263_MP4V (postponed from SA#88-e) | SA WG4 | Rel-16 | These CRs were postponed from SA#88-e. This was Block approved in CC#3 Block 5 | Approved | |
| 16.5 | - | - | - | SA WG5 Rel-16 CRs | - | - | Docs:=20 | - | |
| 16.5 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=20 | - | |
| 16.5 | SP-200723 | CR PACK | Approval | Rel-16 CRs on Streaming trace reporting | SA WG5 | Rel-16 | This was Block approved in CC#3 Block 5 | Approved | |
| 16.5 | SP-200724 | CR PACK | Approval | Rel-16 CRs on TEI | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200729 | CR PACK | Approval | Rel-16 CRs on NRM enhancements | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200732 | CR PACK | Approval | Rel-16 CRs on Self-Organizing Networks (SON) for 5G networks | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200733 | CR PACK | Approval | Rel-16 CRs on Charging Access of ATSSS | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200734 | CR PACK | Approval | Rel-16 CRs on Energy efficiency of 5G | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200737 | CR PACK | Approval | Rel-16 CRs on Integration of ONAP and 3GPP 5G management framework | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200738 | CR PACK | Approval | Rel-16 CRs on Enhancement of performance assurance for 5G networks including network slicing batch 1 | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200740 | CR PACK | Approval | Rel-16 CRs on Charging Enhancement of 5GC interworking with EPC | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200741 | CR PACK | Approval | Rel-16 CRs on CHF-controlled quota management | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200743 | CR PACK | Approval | Rel-16 CRs on Network Slice Performance and Analytics Charging in 5G System | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200744 | CR PACK | Approval | Rel-16 CRs on Management of MDT in 5G | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200745 | CR PACK | Approval | Rel-16 CRs on Network Slice Management Charging in 5G System | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200750 | CR PACK | Approval | Rel-16 CRs on Closed loop SLS Assurance | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200751 | CR PACK | Approval | Rel-16 CRs on KPI reporting | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200753 | CR PACK | Approval | Rel-16 CRs on Trace Management in the context of Services Based Management Architecture | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200754 | CR PACK | Approval | Rel-16 CRs on Management Aspects of 5G Service-Level Agreement | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200813 | CR PACK | Approval | REl-16 CRs on TEI batch 2 | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200816 | CR PACK | Approval | Rel-16 CRs on Charging Aspects for 5WWC | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.5 | SP-200817 | CR PACK | Approval | REl-16 CRs on Nchf Online and Offline charging services | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.6 | - | - | - | SA WG6 Rel-16 CRs | - | - | Docs:=5 | - | |
| 16.6 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=5 | - | |
| 16.6 | SP-200838 | CR PACK | Approval | Rel-16 CRs to TS 23.283 for eMCCI | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.6 | SP-200839 | CR PACK | Approval | Rel-16 CRs to TS 23.282 for eMCData2 | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.6 | SP-200840 | CR PACK | Approval | Rel-16 CRs to TS 23.222 for eCAPIF | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.6 | SP-200841 | CR PACK | Approval | Rel-16 CRs to TS 23.434 for SEAL | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 16.6 | SP-200842 | CR PACK | Approval | Rel-16 CRs to TS 23.286 for V2XAPP | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17 | - | - | - | Rel-17 CRs (block approval if not otherwise requested) | - | - | Docs:=0 | - | |
| 17.1 | - | - | - | SA WG1 Rel-17 CRs | - | - | Docs:=0 | - | |
| 17.1 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=4 | - | |
| 17.2 | - | - | - | SA WG2 Rel-17 CRs | - | - | Docs:=0 | - | |
| 17.2 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 17.3 | - | - | - | SA WG3 and SA WG3 LI Rel-17 CRs | - | - | Docs:=0 | - | |
| 17.3 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 17.4 | - | - | - | SA WG4 Rel-17 CRs | - | - | Docs:=0 | - | |
| 17.4 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 17.5 | - | - | - | SA WG5 Rel-17 CRs | - | - | Docs:=5 | - | |
| 17.5 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=5 | - | |
| 17.5 | SP-200746 | CR PACK | Approval | Rel-17 CRs on Management of MDT enhancement in 5G | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.5 | SP-200747 | CR PACK | Approval | Rel-17 CRs on Enhancements of 5G performance measurements and KPIs | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.5 | SP-200748 | CR PACK | Approval | Rel-17 CRs on Additional NRM features | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.5 | SP-200749 | CR PACK | Approval | Rel-17 CRs on Enhancement on Management Aspects of 5G Service-Level Agreement | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.5 | SP-200752 | CR PACK | Approval | Rel-17 CRs on Enhancements of Self-Organizing Networks (SON) for 5G networks | SA WG5 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.6 | - | - | - | SA WG6 Rel-17 CRs | - | - | Docs:=5 | - | |
| 17.6 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=5 | - | |
| 17.6 | SP-200843 | CR PACK | Approval | Rel-17 CRs to TS 23.280, TS 23.281, TS 23.282 and TS 23.379 for eMONASTERY2 | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.6 | SP-200844 | CR PACK | Approval | Rel-17 CRs to TS 23.280 and TS 23.379 for enh3MCPTT | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.6 | SP-200845 | CR PACK | Approval | Rel-17 CRs to TS 23.282 for eMCData3 | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.6 | SP-200846 | CR PACK | Approval | Rel-17 CRs to TS 23.281 and TS 23.283 for TEI17 | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 17.6 | SP-200847 | CR PACK | Approval | Rel-17 CR to TR 23.744 for FS_enhMCLoc | SA WG6 | This was Block approved in CC#3 Block 5 | Approved | ||
| 18 | - | - | - | Rel-18 CRs | - | - | Docs:=0 | - | |
| 18.1 | - | - | - | SA WG1 Rel-18 CRs | - | - | Docs:=1 | - | |
| 18.1 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=1 | - | |
| 18.1 | SP-200818 | CR PACK | Approval | Stage 1 CRs on SNA | SA WG1 | Rel-18 | This was Block approved in CC#3 Block 5 | Approved | |
| 18.2 | - | - | - | SA WG2 Rel-18 CRs | - | - | Docs:=0 | - | |
| 18.2 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 18.3 | - | - | - | SA WG3 and SA WG3 LI Rel-18 CRs | - | - | Docs:=0 | - | |
| 18.3 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 18.4 | - | - | - | SA WG4 Rel-18 CRs | - | - | Docs:=0 | - | |
| 18.4 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 18.5 | - | - | - | SA WG5 Rel-18 CRs | - | - | Docs:=0 | - | |
| 18.5 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 18.6 | - | - | - | SA WG6 Rel-18 CRs | - | - | Docs:=0 | - | |
| 18.6 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 19 | - | - | - | CRs related to Study Items | - | - | Docs:=3 | - | |
| 19 | - | - | - | Block 5: For Block Approval - Thursday 15:00 UTC | - | - | Docs:=3 | - | |
| 19 | SP-200711 | CR PACK | Approval | Rel-16 CRs for Study on Security Aspects of 3GPP support for Advanced V2X Services | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 19 | SP-200712 | CR PACK | Approval | Rel-16 CRs onStudy on Security Aspects of the 5G Service Based Architecture | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 19 | SP-200713 | CR PACK | Approval | Rel-16 CRs on Study on evolution of Cellular IoT security for the 5G System | SA WG3 | This was Block approved in CC#3 Block 5 | Approved | ||
| 20 | - | - | - | Project Management & TSG SA owned specifications | - | - | Docs:=0 | - | |
| 20.1 | - | - | - | Review of the work plan | - | - | Docs:=2 | - | |
| 20.1 | SP-200850 | DISCUSSION | Agreement | A Feature is like a worm: don't cut it | 3GPP Work Plan Coordinator | CC#3: Postponed | SA Chair disagrees with the paper, as it holds implications which might work negatively in progressing the work of 3GPP. The proposal from the SA Chair is to investigate features, which are only partially complete, on a case-by-case basis. This can be done as only very few such features appear in the end of the release. Johannes (Deutsche Telekom) raises the point that SA1 is performing in each release a clean-up of requirements, which did not conclude in stage2 and stage3, e.g. just refer to documents SP-200785 (REAR), SP-200788 (UIA) and SP-200787 (5GSAT). DT concurs with the assessment of the conclusion in SP-200850 to have a full operational system per Release. So the general aim of 3GPP should be to have self-contained releases with functionable features. Exception sheets are sommonly used to conclude past the freeze date. MCC clarifies that SP-200850 is not meant to open a debate but to remind delegates of a 3GPP basic principle: see 3GPP Working Procedures TR 21.900 sections 4.0B and 4. The principle of not cutting a Feature onto different Releases has been emphasized on several occasions, e.g. in SP-120387 (co-signed by the former SA1 and SA chairs), and it is the usual way of working in SA1, where the (elements of the) Stage 1 of the Features not completed in time for a given Release are removed from the documentation of this Release (see SP-200785, SP-200788 or SP-200789 just for TSG#89e), while retained in the documentation of the next Release. Whatever the approach, it has to be consistent across all 3GPP WGs and TSGs. If this approach is not valid anymore, the Work Procedures should be amended. Telefonica strongly disagrees with this paper. It goes against the independency of the work already developed in previous stages and it gives higher decision powers to the working groups (and therefore the companies) working on later stages The SA5 chair supports the objection (on the contribution's original contents) and comments from the SA chair and SA3-LI chair. Orange stated the Workplan and the Release roadmap is based on the principle that stage 1, stage 2 and stage 3 for a given feature are completed at the release date freeze. We can agree decide to allow exception to complete the work but it also assumed that features will be shift to the next release if not possible to complete in a given time. As long as 3GPP will rely on the notion of 'Release', the principles given in SP-200850 should be used as guidance, even if it is always possible to agree on a specific handling for a given feature. The SA2 chair supports the objections and disagrees with the conclusions of the paper. SA6 Chair (Suresh) agrees with points made by Georg (SA Chair) and Lionel (CT Chair), but prefers to defer any guidance to SA#90-e and continue this discussion offline with interested parties. Telefonica still disagrees with v1 since it does not solve the issues pointed out by our previous comment Upon providing SP-200850rev2, the MCC Work Plan manager (Alain) clarified that this document is not meant to modify anything in the 3GPP Working Procedures. On the contrary: it is meant to remind to all delegates the current, long-standing, 3GPP principles and check how they can be followed even better than now. This document can be further improved, as e.g. to include the CT Chair's comments. | Postponed | |
| 20.1 | SP-200823 | WORK PLAN | Presentation | Work Plan review at TSG#89 | Work Plan Coordinator (MCC) | CC#4: SP-200823_Rev2 was provided to take comments into account. Noted | Noted | ||
| 20.1 | - | - | - | Block 6: For Block Endorsement - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 20.2 | - | - | - | Specification Status | - | - | Docs:=0 | - | |
| 20.2 | - | - | - | Block 6: For Block Endorsement - Thursday 15:00 UTC | - | - | Docs:=0 | - | |
| 20.3 | - | - | - | Work Item Summaries for TR 21.91x | - | - | Docs:=10 | - | |
| 20.3 | - | - | - | Block 6: For Block Endorsement - Thursday 15:00 UTC | - | - | Docs:=10 | - | |
| 20.3 | SP-200776 | WI SUMMARY | Endorsement | Work Item Summary for 5G_eSBA | China Mobile | Rel-16 | This was Block endorsed in CC#3 Block 6 | Endorsed | |
| 20.3 | SP-200777 | WI SUMMARY | Endorsement | Work Item Summary for Rel-16 UDICOM | Nokia Korea | Rel-16 | This was Block endorsed in CC#3 Block 6 | Endorsed | |
| 20.3 | SP-200801 | WI SUMMARY | Endorsement | Summary for Work Item on 'Removal of H.263 and MPEG-4 Visual from 3GPP Services' | Qualcomm Incorporated | Rel-16 | This was Block endorsed in CC#3 Block 6 | Endorsed | |
| 20.3 | SP-200808 | WI SUMMARY | Endorsement | Work Item Summary for Rel-16 eIMS5G_SBA | T-Mobile USA Inc. | Rel-16 | This was Block endorsed in CC#3 Block 6 | Endorsed | |
| 20.3 | SP-200848 | WI SUMMARY | Endorsement | Work item Summary for 5GMS3 | Sony (Rapporteur) | Rel-16 | This was Block endorsed in CC#3 Block 6 | Endorsed | |
| 20.3 | SP-200849 | WI SUMMARY | Endorsement | Work item Summary for Enhancement of performance assurance for 5G | Intel (Rapporteur) | Rel-16 | This was Block endorsed in CC#3 Block 6 | Endorsed | |
| 20.3 | SP-200851 | WI SUMMARY | Endorsement | Work Item Summary for Rel-16 eCAPIF | Samsung | Rel-16 | This was Block endorsed in CC#3 Block 6 | Endorsed | |
| 20.3 | SP-200852 | WI SUMMARY | Endorsement | Work Item Summary for Rel-16 SEAL | Samsung | Rel-16 | This was Block endorsed in CC#3 Block 6 | Endorsed | |
| 20.3 | SP-200824 | DRAFT TR | Information | TR 21.916 v.0.6.0 on Rel-16 Summary | Work Plan Coordinator (MCC) | Rel-16 | This was Block noted in CC#3 Block 6 | Noted | |
| 20.3 | SP-200872 | WI SUMMARY | Endorsement | Work Item Summary for QOED | Ericsson | Rel-16 | Late submission. CC#4: This WI Summary was endorsed. | Endorsed | |
| 20.4 | - | - | - | Improvements to working methods & CRs against 3GPP TSG SA owned Specifications | - | - | Docs:=0 | - | |
| 20.5 | - | - | - | MCC Status Report | - | - | Docs:=1 | - | |
| 20.5 | SP-200803 | REPORT | Information | Support Team report | MCC | CC#4: Noted | Noted | ||
| 20.6 | - | - | - | Future Meeting schedule | - | - | Docs:=0 | - | |
| 21 | - | - | - | Any Other Business | - | - | Docs:=0 | - | |
| 22 | - | - | - | Close of Meeting | - | - | Docs:=0 | - | |
| 99 | - | - | - | WITHDRAWN ITEMS | - | - | Docs:=3 | - | |
| 99 | SP-200704 | CR PACK | Approval | Rel-16 CRs on Mission Critical Services Security Enhancements | SA WG3 | WITHDRAWN | Withdrawn | ||
| 99 | SP-200697 | DRAFT TR | Information | Cover page of TR 23.754 for information to TSG SA (FS_ID_UAS_SA2) | SA WG2 | Rel-17 | Repeated allocation. WITHDRAWN | Withdrawn |