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 | - | |
0.1 | - | - | - | Executive Summary | - | - | 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-210001 | AGENDA | Approval | Agenda & Procedures & Time Schedule for TSG SA#91-e | TSG SA Chair | Proposed Action: Approved. This AGENDA was approved | Approved | ||
1.4 | SP-210224 | AGENDA | Information | SA#91-e GoToMeeting Sessions Agenda & Details | TSG SA Chair | Proposed Action: Noted. Noted | Noted | ||
1.5 | - | - | - | Report from previous SA meetings | - | - | Docs:=1 | - | |
1.5 | SP-210002 | REPORT | Approval | Draft report of TSG SA meeting #90E | TSG SA Secretary | Proposed Action: Approved. This REPORT was 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:=16 | - | |
2.1 | SP-210008 | LS In | Information | LS from IEEE 1588 WG: RE: Use of language in 3GPP Standards | IEEE 1588 WG (reply to 3GPP liaison inclusive language.) | CC#3: Left open. Noted | Noted | ||
2.1 | - | - | - | Block 1 (To note) | - | - | Docs:=15 | - | |
2.1 | SP-210004 | LS In | Information | LS from ITU-R WP5D: LIAISON STATEMENT TO EXTERNAL ORGANIZATIONS: Information on the completion of Recommendation ITU-R M.2150 on radio interface technologies for the terrestrial component of IMT-2020 | ITU-R WP5D (ITU-R WP 5D LS to EO on M.2150) | Proposed Action: Noted. Block Noted at CC#3 | Noted | ||
2.1 | SP-210005 | LS In | Information | LS from ETSI ISG IPE: Liaison about ETSI ISG IPE creation and interaction with other groups | ETSI ISG IPE (IPE(21)000020) | Proposed Action: Noted. Block Noted at CC#3 | Noted | ||
2.1 | SP-210007 | LS In | Information | LS from IETF: LS on port allocation for the W1 interface | IETF (LS_from_IETF) | Proposed Action: Noted. Block Noted at CC#3 | Noted | ||
2.1 | SP-210009 | LS In | Information | LS from ITU-T SG13: LS/o on Establishment of new Focus Group on Autonomous Networks | ITU-T SG13 (SG13-LS187.) | Proposed Action: Noted. Block Noted at CC#3 | Noted | ||
2.1 | SP-210011 | LS In | Information | LS from RAN WG2: LS reply on QoE Measurement Collection | RAN WG2 (R2-2102500) | Rel-17 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.1 | SP-210012 | LS In | Information | LS on DASH Specification Availability | SA WG4 (S4-210293) | Rel-16 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.1 | SP-210013 | LS In | Information | LS from SA WG5: Reply LS on network data analysis energy saving | SA WG5 (S5-211478) | Rel-17 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.1 | SP-210014 | LS In | Information | LS from SA WG6: Reply to LS on APIs in EDGEAPP | SA WG6 (S6-210330) | Rel-17 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.1 | SP-210015 | LS In | Information | LS from ITU-T JCA-IMT2020: LS/o on Invitation to update the information in the IMT2020 roadmap | TU-T JCA-IMT2020 (JCA-IMT2020-O-017) | Proposed Action: Noted. Block Noted at CC#3 | Noted | ||
2.1 | SP-210018 | LS In | Information | LS from CT WG4: LS on Information on the port number allocation solutions | CT WG4 (C4-211806) | Rel-17 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.1 | SP-210020 | LS In | Information | LS from SA WG2: Reply LS on making PSCell ID available at the SGW of EPC | SA WG2 (S2-2100248) | Rel-17 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.1 | SP-210022 | LS In | Information | LS from SA WG2: Reply to LS on New Whitepaper: Operator Platform Telco Edge proposal | SA WG2 (S2-2101060) | Rel-17 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.1 | SP-210023 | LS In | Information | LS from SA WG2: Reply LS on initiation of new work item Q.Sig_Req_ETS_IMS_roaming 'Signalling requirements for emergency telecommunication service in IMS roaming environment' | SA WG2 (S2-2101310) | Proposed Action: Noted. Block Noted at CC#3 | Noted | ||
2.1 | SP-210026 | LS In | Information | LS from SA WG5: LS to TM Forum on introduction of 3GPP Autonomous Network Levels | SA WG5 (S5-212390) | Rel-17 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.1 | SP-210027 | LS In | Information | LS from SA WG5: Reply LS on Progressing the Multi SDO Autonomous Network coordination | SA WG5 (S5-212310) | Rel-17 | Proposed Action: Noted. Block Noted at CC#3 | Noted | |
2.2 | - | - | - | Incoming LSs which need an outgoing LS | - | - | Docs:=16 | - | |
2.2 | - | - | - | LSs for action with proposed replies | - | - | Docs:=8 | - | |
2.2 | SP-210016 | LS In | Action | LS from MulteFire Alliance: LS on MulteFire PLMN-ID | MulteFire Alliance (MF LS to 3GPP 12-MAR-2021.pdf) | Response drafted in SP-210130. Final response in SP-210130_rev8. | (Rev8) Replied to | ||
2.2 | SP-210130 | LS OUT | Approval | [DRAFT] Reply LS on MulteFire PLMN-ID | Qualcomm | Rel-16 | Response to SP-210016. Rev8 was approved (to be revised to a new TD number by MCC). Revised to SP-210264. | Huawei provide a draft revision of the LS out. Haris (Qualcomm) provides r01 Nokia can accept a revision like the one in the draft folder. Haris (Qualcomm) provides rev2 Huawei commented that rev2 is not acceptable. MFA as a standard organization has created their own LTE-u specifications, and now it wants to use 5G NR for private networks for their own MFA PLMN-ID, it is essential to confirm MFA's intention to avoid standard fragmentation. Haris (Qualcomm) provides rev3 Huawei commented to rev 3, and insist to keep the confirmation that MFA usage of PLMN-ID would comply with 3GPP specification and further ask MFA to clarify the rules for usage of the PLMN-ID. Deutsche Telekom ask for a check, if the legal implications of MFA to use the 3GPP 5G NR specifications is clarified. If this needs more time it is proposed to postpone any reply LS. In addition, MFA is just asking for the use of 5G NR in private networks, therefore usage of SNPN terminology in the LS shall be avoided and needs rewording. Huawei clarified technically only SNPN can be used for MFA PLMN-ID. Deutsche Telekom is still of the opinion, that the LS response shall not explicitly use wording of SNPN or PNI-NPN, which was not asked for. Haris (Qualcomm) proposes rev4 and rev5 and asks companies to indicate preferences Nokia prefer rev 5 as it is easier to understand and directly replies the question from MFA. Xiaobao (Orange) proposes revisions on rev4 . Haris (Qualcomm) provides rev6 and responds to Xiaobao Xiaobao (Orange) proposes revisions on rev6 . Huawei replied to Orange and provide a compromise way on top of rev6. Nokia provides some suggestions Nokia: Actually Asking MFA to report what they do to 3GPP cannot result in any action in 3GPP so not sure why the action should include our request of feedback from MFA. Do we know what would we do with any further info from them? So I propose a further slimmed down text. TIM proposes rev7 Haris (Qualcomm) provides rev7 Nokia can live with rev 7 | Revised |
2.2 | SP-210264 | LS OUT | Approval | Reply LS on MulteFire PLMN-ID | TSG SA | Rel-16 | Revision of SP-210130_Rev8. This LS OUT was approved | Approved | |
2.2 | SP-210019 | LS In | Action | LS from SA WG1: LS on support of PWS over SNPN | SA WG1 (S1-210368) | Rel-17 | Response drafted in SP-210125 (Postponed). This was postponed. | Huawei has concerns with the LS reply, WID and CR proposed for this meeting. Deutsche Telekom supports the concerns raised by Huawei and proposes not to pursue the doc SP-210123 and SP-210124. Telecom Italia shares similar concerns as those raised by Deutsche Telekom and Huawei, and propose that SA asks SA1 not to pursue this work in Rel17 (relevant SP-210123 and SP-210124 should not be pursued as well in this meeting). Siemens shares similar concerns as Telecom Italia, Deutsche Telekom, and others. Siemens proposes to postpone this topic until Rel-18. SP-210123 and SP-210124 should either be converted into Rel-18 documents her at the plenary meeting or be submitted as Rel-18 contribution to the next SA1 meeting. Huawei maintains that we have concerns with adding a new feature to the frozen Rel-17 stage 1 to support PWS in SNPN. | Postponed |
2.2 | SP-210125 | LS OUT | Approval | [DRAFT] Reply LS on support of PWS over SNPN | Qualcomm Finland RFFE Oy | Rel-17 | Response to SP-210019. This was postponed. | Huawei has concerns with the LS reply, WID and CR proposed for this meeting. Deutsche Telekom supports the concerns raised by Huawei and proposes not to pursue the doc SP-210123 and SP-210124. Telecom Italia shares similar concerns as those raised by Deutsche Telekom and Huawei, and propose that SA asks SA1 not to pursue this work in Rel17 (relevant SP-210123 and SP-210124 should not be pursued as well in this meeting). Siemens shares similar concerns as Telecom Italia, Deutsche Telekom, and others. Siemens proposes to postpone this topic until Rel-18. SP-210123 and SP-210124 should either be converted into Rel-18 documents her at the plenary meeting or be submitted as Rel-18 contribution to the next SA1 meeting. Huawei maintains that we have concerns with adding a new feature to the frozen Rel-17 stage 1 to support PWS in SNPN. | Postponed |
2.2 | SP-210021 | LS In | Information | LS from SA WG2: Reply LS from ATIS IoT Group: Request that a standardised SST value for this S-NEST new Slice Service Type (SST) | SA WG2 (S2-2101051) | Rel-17 | Related to discussion paper SP-210237. A response LS was drafted in SP-210254. This LS was postponed. | Postponed | |
2.2 | SP-210237 | DISCUSSION | Decision | Discussion on the missing context to the newly introduced HMTC SST | Deutsche Telekom | This was noted. | Noted | ||
2.2 | SP-210254 | LS OUT | Approval | [DRAFT] LS on SST Values | Deutsche Telekom | Created at CC#3. Response to SP-210021. This LS OUT was noted and the incoming LS in SP-210021 was postponed. | Deutsche Telekom provides the draft LS reply on SST values in the inbox/drafts folder for further consideration Huawei prefers that we task SA1, not SA2, for the handling of such requests in the future, and that SA2 just keeps documenting the values as this has been done since Rel-15. Alessio (nokia) points out we need to fill a documentation gap for ALL the Standardized SSTs so the task for SA2 should be generic. Huawei cannot accept that this work is being shifted from SA1 to SA2. Nokia repeats standardized SST definition is in the remit of SA2. KDDI supports Nokia's understanding wrt SST definition in the 3GPP specs. LGE supports SA2's responsibility on SST. Deutsche Telekom clarifies that the document SP-210237 highlighted some missing parts in the specification for completeness and proposes to consider common agreements for future handling of requests and definitions of SSTs and respective SST values. A revision1 of SP-210254 is provided in the inbox/drafts. Sherry(Xiaomi) shares the view that SA2 is responsible for standardizing SST, and SA1 is responsible for identifying service requirements related with the potential new standardized SST value. Nokia tanks Deutsche Telekom for the effort. We believe a simpler text like the one in the draft folder here below would be the way forward: we want in a nutshell proper documentation and how this is done we should leave to SA2 to decide (and discuss) as we cannot do that here for them. Deutsche Telekom does not concur that the proposed simpler text is addressing the issues raised by SP-210237. It may be the solution for the proper documentation for the newly introduced SST, but does not address the issue, that this is to be avoided for future use. Hence, the proposed deletions do not reflect the intentions of Deutsche Telekom, and we would like to keep the Rev2 text with the changes from Xiaomi. Huawei provdes a draft rev 4. We do not accept that SA2 would have now to review performance requirements, as it is the work of SA1. We should on the contrary reaffirm that SA1 should be the WG discussing new requests for these potential slice types, and that SA2 focuses on the maintaining the SST values as they have been since Rel-15. Huawei lists some parameters of these NEST attributes, and would object that SA2 has to start discussing such requirements. Nokia does not expect 3GPP to validate the NESTs, nor any update of their content over time, and would object that SA2 and SA1 would start debating the GSMA NESTs and control their evolution remotely. | Noted | |
2.2 | - | - | - | LSs for action with no proposed replies | - | - | Docs:=8 | - | |
2.2 | SP-210003 | LS In | Action | LS from ATIS IoT Group: Request that a standardised SST value for this S-NEST new Slice Service Type (SST) be added to TS 23.501 | ATIS IoT Group (IoT_CAT_Liaison_Letter_to_SA_and_SA2) | Proposed Action: Noted. Noted | Noted | ||
2.2 | SP-210006 | LS In | Action | LS from IEEE 802.1 Working Group: Liaison response to LS SP-201142 on Use of Inclusive Language in 3GPP specifications | IEEE 802.1 Working Group (Liaison-response-inclusive-language-0221) | CC#3: Left open. Noted | Noted | ||
2.2 | SP-210010 | LS In | Action | LS from RAN WG2: Reply LS on Use of Inclusive Language in 3GPP | RAN WG2 (R2-2101986) | Rel-17 | CC#3: Left open. Noted | Noted | |
2.2 | SP-210017 | LS In | Action | LS from CT WG4: LS on migration from ETSI forge to 3GPP forge | CT WG4 (C4-211513) | Rel-16 | Proposed Action: Noted. Noted | Noted | |
2.2 | SP-210025 | LS In | Action | LS from SA WG5: LS on OpenAPI guidelines | SA WG5 (S5-212312) | Rel-16 | Proposed Action: Noted. Noted | Noted | |
2.2 | SP-210024 | LS In | Action | LS from ITU-R WP5D: LIASION STATEMENT TO RELEVANT EXTERNAL ORGANIZATIONS ON TIMING OF UPDATES TO IMT-2020 RECOMMENDATION ITU-R M.2150 AND IMT-ADVANCED RECOMMENDATION ITU-R M.2012 AFTER YEAR 2021 | ITU-R WP5D (R19-WP5D-210301-TD-0313!!MSW-E) | Proposed Action: Noted. Noted | Noted | ||
2.2 | SP-210028 | LS In | Endorsement | LS from TSG RAN: Draft Letter to ITU in reply to RP-210731 = ITU_R_WP5D_TEMP_313 on timing of updates to IMT-2020 Recommendation ITU-R M.2150 and IMT-Advanced Recommendation ITU-R M.2012 after year 2021 | TSG RAN (RP-210783) | For review and forwarding to PCG. This was endorsed and will be forwarded to the PCG. | Endorsed | ||
2.2 | SP-210029 | LS In | Endorsement | LS from TSG RAN: DRAFT Letter to ITU on the completion of the submission of LTE-Advanced toward Revision 5 of Rec. ITU-R M.2012 | TSG RAN (RP-210787) | For review and forwarding to PCG. This was endorsed and will be forwarded to the PCG. | Endorsed | ||
3 | - | - | - | Items for early consideration | - | - | Docs:=0 | - | |
3.1 | - | - | - | Elections | - | - | Docs:=1 | - | |
3.1 | SP-210186 | OTHER | Information | TSG elections during TSG#91e: User guide | MCC | Proposed Action: Noted. Noted | Noted | ||
3.2 | - | - | - | Challenges to working agreements (Must have been previously requested) | - | - | Docs:=0 | - | |
3.3 | - | - | - | Issues highlighted for early treatment (Please contact the chair in advance) | - | - | Docs:=0 | - | |
3.4 | - | - | - | Discussion papers on work in Rel-15 and earlier | - | - | Docs:=0 | - | |
3.5 | - | - | - | Discussion papers on work in Rel-16 | - | - | Docs:=0 | - | |
3.6 | - | - | - | Discussion papers on work in Rel-17 | - | - | Docs:=9 | - | |
3.6 | SP-210185 | DISCUSSION | Discussion | U2N and U2U relay for ProSe in 5G | OPPO | Rel-17 | Noted | Deng Qiang (CATT) provides rev1 based on RAN progress. Haris (Qualcomm) comments on rev1 and ask to add reference to the RAN SL Relay WID (when it will be approved) in clause 2.3 and a NOTE to indicate that certain objectives have dependencies to the progress of the corresponding work of RAN Guillaume (MediaTek): We agree with Haris (Qualcomm) on the need to refer to RAN WI in due course. We could add a general statement at the end of the WI similar to MUSIM: Work will be done in collaboration with RAN2, RAN3, SA3 and SA5 Sherry (Xiaomi) asked whether to include L2&L3 U2N coexistence in Objective 7. Deng Qiang (CATT) provides rev2 by adding reference to the RAN SL Relay WID (UID to be added when approved) in clause 2.3 and texts clarifying dependencies on other WGs (Work will be done in collaboration with RAN2, RAN3, SA3 and SA5 WGs). Deng Qiang (CATT) replies to Sherry (Xiaomi) | Noted |
3.6 | SP-210122 | DISCUSSION | Agreement | Rel-17 5G_ProSe: Way Forward on Sidelink Relays | MediaTek Inc., Apple, China Unicom, China Telecom, Convida Wireless, Futurewei, Huawei, HiSilicon, Interdigital, KPN, Lenovo, Philips, Sony, TNO, Xiaomi, ZTE | Rel-17 | Moved from 5.3. Noted | Deng Qiang (CATT) provides rev1 based on RAN progress. Haris (Qualcomm) comments on rev1 and ask to add reference to the RAN SL Relay WID (when it will be approved) in clause 2.3 and a NOTE to indicate that certain objectives have dependencies to the progress of the corresponding work of RAN Guillaume (MediaTek): We agree with Haris (Qualcomm) on the need to refer to RAN WI in due course. We could add a general statement at the end of the WI similar to MUSIM: Work will be done in collaboration with RAN2, RAN3, SA3 and SA5 Sherry (Xiaomi) asked whether to include L2&L3 U2N coexistence in Objective 7. Deng Qiang (CATT) provides rev2 by adding reference to the RAN SL Relay WID (UID to be added when approved) in clause 2.3 and texts clarifying dependencies on other WGs (Work will be done in collaboration with RAN2, RAN3, SA3 and SA5 WGs). Deng Qiang (CATT) replies to Sherry (Xiaomi) | Noted |
3.6 | SP-210128 | DISCUSSION | Approval | Support for eCall over IMS over SNPN | Qualcomm Incorporated | Rel-17 | This was noted. | Deutsche Telekom does not agree with the assessment in the documents that eCall over IMS over SNPN is already required. SA1 did discuss this in the last meeting and did not conclude that there are requirements for this feature. Deutsche Telekom does not agree to the approval of the documents. Siemens is not convinced that eCall over IMS over SNPN is required. Siemens proposes to send an LS to 5GAA with a request for clarification and to postpone SP-210129 until the need for eCall in SNPN has been explained by 5GAA. TIM disagrees with the proposal in SP-210128 to proceed with the support of eCall over IMS over SNPN in rel.17, hence asks to not approve the liaison in SP-210129. Haris (Qualcomm) provides rev1 asking related question to 5GAA WG4 Siemens suggests to rephrase the last sentence in section 1 of SP-210128 to 'Given the statement quoted above TSG SA would like to ask 5GAA WG4 whether it is necessary to support eCall over IMS (NG-eCall) in SNPN and whether this needs to be part of release 17.' Deutsche Telekom supports the LS to 5GAA WG4 to clarify the requirement for eCall over IMS over SNPN Haris (Qualcomm) provides as rev2 the revision from TIM and indicates that QC is ok with either rev1 or rev2 | Noted |
3.6 | SP-210129 | LS OUT | Approval | [DRAFT] LS on the support for eCall over IMS over SNPN | Qualcomm | Rel-17 | CC#3: Presented and left open. SP-210129_rev2 was approved (to be revised to a new TD number by MCC). Revised to SP-210263. | Deutsche Telekom does not agree with the assessment in the documents that eCall over IMS over SNPN is already required. SA1 did discuss this in the last meeting and did not conclude that there are requirements for this feature. Deutsche Telekom does not agree to the approval of the documents. Siemens is not convinced that eCall over IMS over SNPN is required. Siemens proposes to send an LS to 5GAA with a request for clarification and to postpone SP-210129 until the need for eCall in SNPN has been explained by 5GAA. TIM disagrees with the proposal in SP-210128 to proceed with the support of eCall over IMS over SNPN in rel.17, hence asks to not approve the liaison in SP-210129. Haris (Qualcomm) provides rev1 asking related question to 5GAA WG4 Siemens suggests to rephrase the last sentence in section 1 of SP-210128 to 'Given the statement quoted above TSG SA would like to ask 5GAA WG4 whether it is necessary to support eCall over IMS (NG-eCall) in SNPN and whether this needs to be part of release 17.' Deutsche Telekom supports the LS to 5GAA WG4 to clarify the requirement for eCall over IMS over SNPN Haris (Qualcomm) provides as rev2 the revision from TIM and indicates that QC is ok with either rev1 or rev2 | Revised |
3.6 | SP-210263 | LS OUT | Approval | LS on the support for eCall over IMS over SNPN | TSG SA | Rel-17 | Revision of SP-210129_rev2. This LS OUT was approved | Approved | |
3.6 | SP-210192 | DISCUSSION | Agreement | Discussion for jitter measurement for FS_IIoT | China Mobile, Deutsche Telekom, Huawei, Hisilicon, ZTE, CATT, Futurewei | Rel-17 | CC#3: Presented and left open. Noted | China Mobile don't agree with Ericsson and Qualcomm's comments on CC#1. Provides clear evidence requirements from SA1 and GSMA. and suggest that SA endorse proposal 1 which is to solve the issue in normative phase by SA2 Siemens clarifies that the 'less than (+)(-)25% of transfer interval' figure in TS 22.104 only can be used for inferring end-to-end jitter requirements when making assumptions about the distribution of the end-to-end latency. Inferring a network jitter requirement from this figure would rest on even more assumptions. Haris (Qualcomm) indicates that we cannot agree with the proposals (proposal 1 or alternative proposal 2) in SP-210192 Ericsson agrees with the comments given by Qualcomm and Siemens and as such we cannot agree with the proposals (proposal 1 or alternative proposal 2) in SP-210192. | Noted |
3.6 | SP-210193 | CR | Approval | 21.900 CR0067 (Rel-16, 'F'): Migration from ETSI forge to 3GPP forge | Huawei | Rel-16 | Moved from 5.2. CC#3: Left open until TSG CT closes. This CR was approved | Approved | |
3.6 | SP-210225 | DISCUSSION | Approval | Discussion on the subscription of SM PCF registration & deregistration to the BSF | China Mobile | Rel-17 | Left open for e-mail discussion. Noted | Ericsson requests clarification on this document status as it is seeking approval for Rel-17, since it is not related to TEI17_DCAMP WI and SA2 has not discussed the technical aspects of the work and no new Rel-17 work is expected to be approved. Tao (CMCC) thanks Ericsson initiate the thread and appreciate the offline discussion. CMCC agree to NOTE this proposal. Suggest to keep minutes in Chair Notes that: 'offline discussion will be done among interest companies and technical proposal shall be proposed to SA2 when the understand is stable and proper agenda such as R17 maintenance opening'. Nokia requests clarifications on the suggestion from CMCC on text for Chair's notes. Since 3GPP is company contribution driven, we cannot really say that a 'technical proposal shall be proposed to SA2'. Also ask if the intention is to possibly bring corrections to Rel-17 to address the scenario as highlighted in SP-210225. Tao (CMCC) clarifies and simplified the proposal for Chair Notes as 'SA expect technical discussion is needed and shall be in SA2 under proper agenda such as R17 maintenance'. | Noted |
3.6 | SP-210233 | DISCUSSION | Approval | Keeping R17 on track in a changing world | Vodafone | Rel-17 | Noted | Request for clarification Please clarify the meaning of the sentence 'Converting Q4 2021 and Q1 and Q2 2022 working group meetings into emeetings would then result in the loss of about 1.5 meetings.' | Noted |
3.7 | - | - | - | Discussion papers on work in Rel-18 and later | - | - | Docs:=0 | - | |
4 | - | - | - | Reporting from SA Working Groups, other TSGs, and Others | - | - | Docs:=0 | - | |
4.1 | - | - | - | SA WG1 reporting | - | - | Docs:=3 | - | |
4.1 | SP-210218 | TOR | Approval | Terms of Reference (ToR) for SA WG1 | SA WG1 | Rev4 was approved (to be revised to a new TD number by MCC). Revised to SP-210268. | Revision request (editorial) Replace the phrase 'access independent manner' in SP-210218 (SA1 ToR) with 'access-independent manner'. Request for clarification Please clarify the meaning of the sentence 'Converting Q4 2021 and Q1 and Q2 2022 working group meetings into emeetings would then result in the loss of about 1.5 meetings.' Gerald (Matrixx) suggest the additional refinement on charging service requirements. New revision of SP-210218 (SP-210218_Rev1) is available in the server where the editorial changes suggested by Siemens have been taken into account. SP-210218_Rev1 also takes into account the change suggested by Matrixx. Nokia proposes to remove text that is summarizing some working methods and normal WG tasks that are common to all groups. The ToR should not capture these aspects. Gerald (Matrixx) respectful disagree with the provided view and suggest an improved wording. Lionel (Orange) is fine with the proposed wording. SA Chair proposes to give guidance to SA WGs to actively highlight to TSG SA whenever they got requirements from external groups or develop requirements on their own. | Revised | |
4.1 | SP-210268 | TOR | Approval | Terms of Reference (ToR) for SA WG1 | SA WG1 | Revision of SP-210218_Rev4. This TOR was approved | Approved | ||
4.1 | - | - | - | Block 3 (to note) | - | - | Docs:=1 | - | |
4.1 | SP-210195 | REPORT | Presentation | SA WG1 Report to TSG SA#91e | SA WG1 Chair | Noted | Regarding the SA1 report, a new version can be found in SP-210195_rev1 which includes some minor editorial changes. | Noted | |
4.2 | - | - | - | SA WG2 reporting | - | - | Docs:=4 | - | |
4.2 | SP-210214 | DISCUSSION | Decision | Discussion on Terms of Reference (ToR) for 3GPP SA WG2 | Deutsche Telekom | Noted | Noted | ||
4.2 | SP-210187 | TOR | Approval | Terms of Reference (ToR) for SA WG2 | SA WG2 | Rev2 was approved (to be revised to a new TD number by MCC). Revised to SP-210266. | Revision request (editorial) 1. Rectify the punctuation in the phrase '(e.g. Security. Codecs, Management, Orchestration, Charging, Application layer etc.).' ['Security. Codecs' unclear; the period is probably a typo] 2. Change 'Service based architecture' to 'Service-based architecture' Puneet (SA2 Chair) provides rev1, and addresses comments. Lionel (CT chair) is fine with updated version. Deutsche Telekom welcomes the efforts on providing rev1, but still sees some essential parts from SP-210214 not incorporated. We cannot agree to the ToRs as proposed in the rev1 as this still does not take into account that the 3GPP is following a stage process consisting of stage1, stage2 and stage3. Within 3GPP, SA1 is responsible for definition of stage 1 service requirements. Hence, also external groups like oneM2M or GSMA shall be directed to and interact with SA1 to define the corresponding service requirements for 3GPP to be lateron reflected in the downstream groups. Deutsche Telekom strongly dis-encourages that working groups are taking on-board service requirements from external bodies bypassing SA1 for whatever reason. This needs to be clearly reflected in the ToRs. Furthermore, we like to maintain our concerns on the providing a non-exhaustive list as a definition of 'scope of responsibilities'. We are still of the opinion that the ToR should describe the full scope of responsibilities of the WG in an unambiguous manner, which is not possible with a non-exhaustive list. SA Chair proposes to give guidance to SA WGs to actively highlight to TSG SA whenever they got requirements from external groups or develop requirements on their own. Lionel (CT chair) proposes to approve the latest version of the SA2 ToR with an indication that further clarifications might be still required in the Scope of Responsibilities but there are left for further discussion in WG. Haris (Qualcomm) proposes to approve rev1 SA2 Chair comments that all information is available in the SID/WID document and there is no need for any additional process overhead. SA2 Chair responds to comments from Deutsche Telekom. Deutsche Telekom welcomes the initiative by the SA chair to give guidance to the SA WGs, however this could be avoided by clear definition of ToRs of the WGs and a clear confirmation of the stage1-2-3 process as agreed by the 3rd generation partnership project. Therefore we proposed an update of the ToRs to reflect these issues. Deutsche Telekom still raises concerns that the current Scope of Responsibilities is not clear enough and contains a non-exhaustive list, which does not reflect the purpose of Terms of Reference. It is proposed to take into account the proposal in SP-210214 for a clear stage approach and clear definitions of the sections Overview and Scope of Responsibility. Nokia suggests a few possible changes to rev1. Ericsson support CT chairs view on the scope of the update of ToRs, and also support approval of rev 1. Lionel (CT chair) insists in the fact that if there are some aspects to clarify in the current Scope of Responsibilities that cannot be immediately fixed, it is something that can be further discussed in the WG but it should not preclude to approve a stable version at this plenary. A new version can be submitted at any time if required. All the CT and RAN WG ToR will be available after this plenary (CT ToR available since CT#90), all of them following now the same template, providing a common look&feel of the WG info provided on the website. It would be good to have all the SA ToR also approved at this plenary.. SA2 Chair provides rev2 If we only mention SA1 in the ToR then this might lead to unnecessary restrictions. We can avoid uncoordinated behavior by demanding SA coordination on external requirements. We should also have general rules for all groups. Suresh Chitturi (SA6 Chair) thinks the general direction of the SA chair guidance seems reasonable but requests that it should not create a burden to the WGs. And also continues to believe that we should not be too restrictive in the ToR. | Revised | |
4.2 | SP-210266 | TOR | Approval | Terms of Reference (ToR) for SA WG2 | SA WG2 | Revision of SP-210187_Rev2. This TOR was approved | Approved | ||
4.2 | - | - | - | Block 3 (to note) | - | - | Docs:=1 | - | |
4.2 | SP-210052 | REPORT | Presentation | SA WG2 Chair status report | SA WG2 Chair | Noted | Noted | ||
4.3 | - | - | - | SA WG3 reporting | - | - | Docs:=2 | - | |
4.3 | - | - | - | Block 3 (to note) | - | - | Docs:=2 | - | |
4.3 | SP-210104 | REPORT | Presentation | SA WG3 Status report | SA WG3 Chair | SP-210104_rev1 was noted (to be revised to a new TD number by MCC). Revised to SP-210261. | Revision request (editorial) Change the third table row on slide 6 from 'Normative work on Lawful Interception Rel-16' to 'Normative work on Lawful Interception Rel-17' Revision request SA3 chair provides a revision to correct summary table and include a missing slide on the user consent study. | Revised | |
4.3 | SP-210261 | REPORT | Presentation | SA WG3 Status report | SA WG3 Chair | Revision of SP-210104_rev1. Noted | Noted | ||
4.4 | - | - | - | SA WG4 reporting | - | - | Docs:=2 | - | |
4.4 | - | - | - | Block 3 (to note) | - | - | Docs:=2 | - | |
4.4 | SP-210033 | REPORT | Presentation | SA WG4 report to SA Plenary | SA WG4 Chair | Revised to SP-210240. | Revised | ||
4.4 | SP-210240 | REPORT | Presentation | SA WG4 report to SA Plenary | SA WG4 Chair | Revision of SP-210033. Noted | Noted | ||
4.5 | - | - | - | SA WG5 reporting | - | - | Docs:=2 | - | |
4.5 | - | - | - | Block 3 (to note) | - | - | Docs:=2 | - | |
4.5 | SP-210188 | REPORT | Presentation | SA WG5 Status report | SA WG5 Chair | Revised to SP-210238. | Revised | ||
4.5 | SP-210238 | REPORT | Presentation | SA WG5 Status report | SA WG5 Chair | Revision of SP-210188. Noted | Noted | ||
4.6 | - | - | - | SA WG6 reporting | - | - | Docs:=4 | - | |
4.6 | SP-210191 | TOR | Approval | SA6 ToR Update Revision | Deutsche Telekom AG | This was noted. | Noted | ||
4.6 | SP-210172 | TOR | Approval | Terms of Reference (ToR) for SA WG6 | SA WG6 | Revision of SP-200927. Rev3 was approved (to be revised to a new TD number by MCC). Revised to SP-210265. | SA Chair proposes to give guidance to SA WGs to actively highlight to TSG SA whenever they got requirements from external groups or develop requirements on their own. SA2 Chair comments that all information is available in the SID/WID document and there is no need for any additional process overhead. Deutsche Telekom welcomes the initiative by the SA chair to give guidance to the SA WGs, however this could be avoided by clear definition of ToRs of the WGs and a clear confirmation of the stage1-2-3 process as agreed by the 3rd generation partnership project. Therefore we proposed an update of the ToRs to reflect these issues. SA6 Chair (Suresh Chitturi) proposes a revision to SP-210172 (SA6 ToR) to align with the language in SA2 ToR, including the aspect of taking SA1 requirements as input to the work. If we only mention SA1 in the ToR then this might lead to unnecessary restrictions. We can avoid uncoordinated behavior by demanding SA coordination on external requirements. We should also have general rules for all groups. Ericsson supports approval of rev 1. Huawei (Niranth) suggests enhancements to the SA6 ToR Rev 1 provided by SA6 Chair in line with SA2 ToR. SA6 Chair (Suresh Chitturi) provides rev2 of SP-210172 (SA6 ToR) incorporating comments from Lionel (CT Chair) and HW. SA6 Chair indicates that Rev3 is the latest version since Rev2 is the version from HW. Maurice is requested to remove Rev2 from the Revisions folder to avoid this confusion! Suresh Chitturi (SA6 Chair) thinks the general direction of the SA chair guidance seems reasonable but requests that it should not create a burden to the WGs. And also continues to believe that we should not be too restrictive in the ToR. | Revised | |
4.6 | SP-210265 | TOR | Approval | Terms of Reference (ToR) for SA WG6 | SA WG6 | Revision of SP-210172_Rev3. This TOR was approved | Approved | ||
4.6 | - | - | - | Block 3 (to note) | - | - | Docs:=1 | - | |
4.6 | SP-210171 | REPORT | Presentation | SA WG6 status report to TSG SA#91 | SA WG6 Chair | Noted | Noted | ||
4.7 | - | - | - | TSG RAN reporting and RAN ITU-R Ad Hoc Matters | - | - | Docs:=1 | - | |
4.7 | SP-210259 | REPORT | Presentation | Status Report of TSG RAN#91-e | TSG RAN Chair | ||||
4.8 | - | - | - | TSG CT reporting | - | - | Docs:=3 | - | |
4.8 | SP-210258 | REPORT | Presentation | Status report of TSG CT#91-e | TSG CT Chair | ||||
4.8 | SP-210257 | REPORT | Information | Draft report of TSG CT#91-e | TSG CT Secretary (MCC) | ||||
4.8 | SP-210256 | REPORT | Presentation | IETF Status report | TSG CT Chair | ||||
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 and Issues | - | - | Docs:=0 | - | |
5.3 | - | - | - | Rel-17 Focus Areas Status Reports and Issues | - | - | Docs:=0 | - | |
5.4 | - | - | - | Input to Joint TSG RAN/TSG 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.2 | - | - | - | Revised Release 16 and earlier Study Item Descriptions and Work Item Descriptions | - | - | Docs:=0 | - | |
6.3 | - | - | - | New Release 17 Study Item Descriptions | - | - | Docs:=12 | - | |
6.3 | SP-210189 | DISCUSSION | Decision | Discussion on new SID for Network Slice Capability Exposure | Deutsche Telekom | Rel-17 | Noted | Noted | |
6.3 | SP-210190 | SID NEW | Approval | Revision proposal New SID Study on Network Slice Capability Exposure for Application Layer Enablement | Deutsche Telekom AG | Rel-17 | Proposed update to SP-210177. Rev8 was approved (to be revised to a new TD number by MCC). Revised to SP-210267. | China Mobile provides revision based on offline discussion with DT. China Mobile update and provide rev3, the correct file upload format. Deutsche Telekom thanks for the efforts of China Mobile and provides rev4 to keep the SA5 work items listed in section 2.3 and agrees with the rest of the changes from China Mobile. Deutsche Telekom provided rev4 on the server. Nokia thanks for the efforts of China Mobile and DT and provides rev5 in the draft folder to improve the SA5 work items listed in section 2.3 and a slight improvement of one of the objective text, so that this can be taken into account for the next revision CMCC thanks Nokia and DT efforts and is ok with both rev4 and rev5. Huawei thanks CMCC, DT and Nokia for the inputs on this SID and we agree with Rev5 draft provided by Nokia with a minor change to the objective to bring overall alignment. Deutsche Telekom comments that the rev5 from Nokia is fine in chapter 2.3 and 3., but the changes in the chapter 4 on objectives is too generic. To cope with the WID intention the addition of area of 'network slice capability exposure' would be needed for bullet 2 as it is done in bullet 1 and 3, which then brings the text very close to the already existing text in bullet1. Hence it is proposed to either delete the bullet 2 as proposed in rev6, or take the rev4 as proposed. Rev6 is uploaded in inbox/drafts. Deutsche Telekom does not support the proposal from Huawei to add 'management' to the bullet 2. Susana (Vodafone) agrees with DT to not adding 'management' in the bullet 2 and provides rev7 to clarify the first bullet of the objectives. Nokia is ok with the draft 7. CMCC is ok with draft rev7. | Revised |
6.3 | SP-210267 | SID NEW | Approval | Revision proposal New SID Study on Network Slice Capability Exposure for Application Layer Enablement | Deutsche Telekom AG | Rel-17 | Revision of SP-210190_Rev8. This SID NEW was approved | Approved | |
6.3 | SP-210177 | SID NEW | Approval | New SID Study on Network Slice Capability Exposure for Application Layer Enablement | SA WG6 | Proposed update in SP-210190. This was considered as revised to SP-210190. | Revised | ||
6.3 | SP-210121 | SID NEW | Approval | New SID on Non-seamless WLAN Offload in 5GC using 3GPP credentials | AT&T, Nokia, Nokia Shanghai Bell, Interdigital, Broadcom, Ericsson, Samsung, Apple, Verizon, T-Mobile, Qualcomm, Intel, Cablelabs, Charter Communications | Rev4 was approved (to be revised to a new TD number by MCC). Revised to SP-210262. | Huawei objects to the company-proposed SID for SA3 on NSWO. Saso (Intel) points to Patrice (Huawei) that the main objective of the SID is to maintain privacy of subscription identifier, which is not supported today with the EPS NSWO paradigm. Haris (Qualcomm) provides response to comments from Huawei and supports the approval of the SID Apostolis (Lenovo) provides rev1 and co-signs the SID proposal. John-Luc (BlackBerry) would like to co-sign and support the SID proposal. Huawei indicates that the statements from the supporting companies are contradicting the statements in the company proposed SID. AT&T responds to Huawei. Pls see detailed responses inline below Vodafone objects to the company-proposed SID for SA3 on NSWO in this meeting. Nokia provides revision 2 of the SID proposal, on top of revision1 from Lenovo. Deutsche Telekom supports the objection from Vodafone to the company-proposed SID for SA3 on NSWO in this meeting. AT&T responds to Vodafone and DT comments. Apple supports this SID, and clarifies that the scope of the work is within SA3's remit. Should any SA2 impact be identified, SA2 can be informed. Vodafone withdraws its objection to this document on condition that the following statement is entered into the minutes: 'Vodafone is concerned that the SA3 workload is too high and has repeatedly raised this issue over the last 8 meetings. SA3 already has over 20 active SIDs and many WIDs and Vodafone expects that each of these SIDs are likely to become at least 1 WID in the R17 timeframe. Vodafone however recognises that prioritising SIDs based on the order they are presented to meetings may not be the optimal method to choose which SIDs are prioritised. Vodafone strongly urges SA and SA3 to assess the workload of SA3 and adjust the priorities accordingly.' Spreadtrum(Chunhui Zhu) shares the concerns from VDF that the SA3 workload should be considered seriously, and provides a way forward for the SID, i.e. Mini WID+CR(s). Spreadtrum(Chunhui Zhu) shares the concerns from VDF&DT that the SA3 workload should be considered seriously, and provides a way forward for the SID, i.e. Mini WID+CR(s). AT&T responds to Spreadstrum Huawei maintains that reconsidering the additional architectural option for NSWO for 5GC requires SA2 discussion and approval before the security details can be discussed in SA3. AT&T clarifies that 5G core has a security architecture that is maintained by SA3 (TS 33.501: Security architecture and procedures for 5G system). There is text in the study to indicate SA2 involvement. A more constructive feedback would be to suggest improvement in that text. Hewlett Packard Enterprise supports this SID and would like to be added as a supporting company. Saso (Intel) agrees with comments from Haris and provides additional comments. Rev3 is now in revisions folder with HPE added to supporting companies and fixing the name Blackberry -> Blackberry UK Ltd. Deutsche Telekom withdraws the objection. We recognize the urgency for some networks for this feature, although we echo the concerns raised by Vodafone about the workload in SA3 and support the requested added text to the minutes. KPN agrees with the SID but has shares the concerns raised by Deutsche Telekom and Vodafone. Huawei maintains their objection against SP-210121 and its revisions rev1~rev3, however for the sake of compromise and for the good spirit of 3GPP, proposes to revise the study item to be an actual study item, and tightens the SA2 scrutiny over the proposed solutions. Intel makes a minor suggestion. Huawei is OK with the change of 5GC to 5GS. | Revised | |
6.3 | SP-210262 | SID NEW | Approval | New SID on Non Seamless WLAN Offload in 5GC using 3GPP credentials | AT&T, Nokia, Nokia Shanghai Bell, Interdigital, Broadcom, Ericsson, Samsung, Apple, Verizon, T-Mobile, Qualcomm, Intel, Cablelabs, Charter Communications, Lenovo, Motorola Mobility, BlackBerry UK Ltd., HPE | Revision of SP-210121_rev4. This SID NEW was approved | Approved | ||
6.3 | - | - | - | Block 4 (to approve) | - | - | Docs:=6 | - | |
6.3 | SP-210106 | SID NEW | Approval | Study on enhanced security for network slicing Phase 2 | SA WG3 | Block Approved | Approved | ||
6.3 | SP-210041 | SID NEW | Approval | New SI on Media Production over 5G NPNs [FS_5G_4_AVProd] (UID: 910001) | SA WG4 | Revised to SP-210241. | Revised | ||
6.3 | SP-210241 | SID NEW | Approval | New SI on Media Production over 5G NPNs [FS_5G_4_AVProd] (UID: 910001) | SA WG4 Chair | Revision of SP-210041. Block Approved | Approved | ||
6.3 | SP-210131 | SID NEW | Approval | New SID on network slice management capability exposure | SA WG5 | Block Approved | Approved | ||
6.3 | SP-210133 | SID NEW | Approval | New SID on continuous integration continuous delivery support for 3GPP NFs | SA WG5 | Block Approved | Approved | ||
6.3 | SP-210136 | SID NEW | Approval | Study on Enhancement of service based management architecture | SA WG5 | Block Approved | Approved | ||
6.4 | - | - | - | New Release 17 Work Item Descriptions | - | - | Docs:=11 | - | |
6.4 | SP-210123 | WID NEW | Approval | Mini-WID on PWS over NPN | Qualcomm Finland RFFE Oy | Rel-17 | Presented with CR in SP-210124 (SA WG1 responsibility). This was postponed. | Huawei has concerns with the LS reply, WID and CR proposed for this meeting. Deutsche Telekom supports the concerns raised by Huawei and proposes not to pursue the doc SP-210123 and SP-210124. Telecom Italia shares similar concerns as those raised by Deutsche Telekom and Huawei, and propose that SA asks SA1 not to pursue this work in Rel17 (relevant SP-210123 and SP-210124 should not be pursued as well in this meeting). Siemens shares similar concerns as Telecom Italia, Deutsche Telekom, and others. Siemens proposes to postpone this topic until Rel-18. SP-210123 and SP-210124 should either be converted into Rel-18 documents her at the plenary meeting or be submitted as Rel-18 contribution to the next SA1 meeting. Huawei maintains that we have concerns with adding a new feature to the frozen Rel-17 stage 1 to support PWS in SNPN. | Postponed |
6.4 | SP-210124 | CR | Approval | 22.261 CR0504 (Rel-17, 'B'): 22261CR_Requirement on PWS over NPN | Qualcomm Finland RFFE Oy | Rel-17 | CR Related to new WID in SP-210123. This was postponed. | Huawei has concerns with the LS reply, WID and CR proposed for this meeting. Deutsche Telekom supports the concerns raised by Huawei and proposes not to pursue the doc SP-210123 and SP-210124. Telecom Italia shares similar concerns as those raised by Deutsche Telekom and Huawei, and propose that SA asks SA1 not to pursue this work in Rel17 (relevant SP-210123 and SP-210124 should not be pursued as well in this meeting). Siemens shares similar concerns as Telecom Italia, Deutsche Telekom, and others. Siemens proposes to postpone this topic until Rel-18. SP-210123 and SP-210124 should either be converted into Rel-18 documents her at the plenary meeting or be submitted as Rel-18 contribution to the next SA1 meeting. Huawei maintains that we have concerns with adding a new feature to the frozen Rel-17 stage 1 to support PWS in SNPN. | Postponed |
6.4 | SP-210049 | DISCUSSION | Discussion | Discussion on new WID Plug and Connect | Orange, AT&T, Deutsche Telekom, Telecom Italia, Telefonica, Verizon UK | Moved from 3.3. Noted | Noted | ||
6.4 | SP-210050 | WID NEW | Approval | WID for Generic Plug and Connect | Orange, AT&T, Deutsche Telekom, Telecom Italia, Telefonica, Verizon UK | Proposed update to SP-210134. rev2 approved (to be revised to a new TD number by MCC). Revised to SP-210260. | Huawei objects to the company proposed WID revision in SP-210050. Orange clarifies intention and thinks SA5 should be able to discuss contributions related to O-RAN. Huawei replies to Orange, understands the intention and the motivation to clarify the situation, but still cannot agree to the proposal at this meeting until such clarification has completed. Orange agrees such process should start and would like to clarify if Huawei would be ok that SA5 discuss any technical contributions (even if they relates to some O-RAN work). Nokia raises concerns with just adding 'open source' but removing reference to ONAP and O-RAN. Orange uploaded SP-210050_rev1 to the server, updating also title, acronym and supporting companies Haris (Qualcomm) expresses concerns on rev1 and proposes alternative wording for the last objective Spreadtrum(Chunhui Zhu) provides an editorial suggestion. Deutsche Telekom welcomes the efforts from Qualcomm and Huawei and proposes alternative wording to rev1 and proposes some text to be clearly added to the meeting minutes on the way forward for contributions and legal aspects. Orange supports the proposed wording from Deutsche Telekom and statement to be captured in the minutes, and provides rev2. Haris (Qualcomm) proposes alternative wording for the objective Huawei is OK with the original agreed WID in SP-210134, and can accept SP-210050 rev 1 and rev 2. We would not like to see any exceptional guidance provided to SA5, at most a reminder regarding duties for submitting contributions. We do not believe it would be useful to send back this discussion to SA5. Telefonica is supportive of Deutsche Telekom's proposal regarding an alternative wording to rev1 and some text to be clearly added to the meeting minutes on the way forward for contributions and legal aspects. Deutsche Telekom sees a lot of benefits to keep the 'e.g.' in the wording and not to singular focus on one Open Source Project. As indicated there are activities ongoing to include also other OS Projects, and they may be then in the scope of SA5 as well, once the procedural issues are solved. TIM expresses support to DT and their proposed text 'Strive for harmonization with relevant standardization groups and open source projects (e.g. ONAP)' Orange supports keeping rev2 and propose alternative text for the minutes. Huawei proposes more changes to the text, has concerns with introducing preferential treatment for certain content. Orange is ok with Huawei text proposal for the minutes. Deutsche Telekom thanks Huawei for the text proposal and likes to support it to be kept in the minutes. | Revised | |
6.4 | SP-210260 | WID NEW | Approval | WID for Generic Plug and Connect | Orange, AT&T, Deutsche Telekom, Telecom Italia, Telefonica, Verizon UK | Revision of SP-210050_rev2. This WID NEW was approved | Approved | ||
6.4 | SP-210134 | WID NEW | Approval | New WID on Plug and connect support for management of Network Functions | SA WG5 | Proposed update in SP-210050. Considered revised into SP-210050 | Revised | ||
6.4 | - | - | - | Block 4 (to approve) | - | - | Docs:=5 | - | |
6.4 | SP-210090 | WID NEW | Approval | New WID: Architecture enhancements for 3GPP support of advanced V2X services - Phase 2 | SA WG2 | Block Approved | Approved | ||
6.4 | SP-210105 | WID NEW | Approval | User Plane Integrity Protection for LTE | SA WG3 | Block Approved | Approved | ||
6.4 | SP-210107 | WID NEW | Approval | New WID on enhancements of 3GPP profiles for cryptographic algorithms and security protocols | SA WG3 | Block Approved | Approved | ||
6.4 | SP-210132 | WID NEW | Approval | New WID Enhancements of Management Data Analytics Service | SA WG5 | Block Approved | Approved | ||
6.4 | SP-210135 | WID NEW | Approval | New WID on File Management | SA WG5 | Block Approved | Approved | ||
6.5 | - | - | - | Revised Release 17 Study Item and Work Item Descriptions | - | - | Docs:=18 | - | |
6.5 | SP-210184 | WID REVISED | Approval | Revised WID on System enhancement for Proximity based Services in 5GS | CATT | Revision of SP-201132. Updated to 'WID REVISED' by MCC. | Deng Qiang (CATT) provides rev1 based on RAN progress. Haris (Qualcomm) comments on rev1 and ask to add reference to the RAN SL Relay WID (when it will be approved) in clause 2.3 and a NOTE to indicate that certain objectives have dependencies to the progress of the corresponding work of RAN Guillaume (MediaTek): We agree with Haris (Qualcomm) on the need to refer to RAN WI in due course. We could add a general statement at the end of the WI similar to MUSIM: Work will be done in collaboration with RAN2, RAN3, SA3 and SA5 Sherry (Xiaomi) asked whether to include L2&L3 U2N coexistence in Objective 7. Deng Qiang (CATT) provides rev2 by adding reference to the RAN SL Relay WID (UID to be added when approved) in clause 2.3 and texts clarifying dependencies on other WGs (Work will be done in collaboration with RAN2, RAN3, SA3 and SA5 WGs). Deng Qiang (CATT) replies to Sherry (Xiaomi) | OPEN | |
6.5 | SP-210194 | WID REVISED | Approval | Revised WID on Enablers for Network Automation for 5G - phase 2 | vivo | Rel-17 | Revision of SP-201133. This WID REVISED was approved | Approved | |
6.5 | SP-210219 | DISCUSSION | Agreement | Discussion on requirements for Rel-17 MCOver5GS | CBN, Airbus, CATT, Huawei, ZTE,TD-Tech | Rel-17 | Noted | Noted | |
6.5 | SP-210220 | WID REVISED | Approval | Revised WID on Mission Critical Services over 5GS | CBN, Airbus, Huawei, CATT, ZTE, TD-Tech | Rel-17 | Revision of SP-200833. This was left for e-mail discussion until CC#6. Noted | CBN try to understand the reason of one objection during yesterday CC regarding the update to include the MCover5GMBS. ZTE has similar understanding with CBN. and proposes to approve this WID revision. Motorola Solutions objects to the company proposed WID update in SP-210220, Revised WID on Mission Critical Services over 5GS. This revision from CBN was discussed at length within SA6 (across more than one meeting), and it was concluded that - Focus area 2 would be worked on beginning in Release 18. Because focus area 2's (5G MBS) normative specification will not be available in time for SA6's evaluation within the stage 2 freeze, SA6 determined that attempting to force this work into Rel-17 would only lead to incorrect specification and missed impacts since the architectural impacts relevant to MC services are still being worked out in RAN and SA. | Noted |
6.5 | SP-210221 | DISCUSSION | Discussion | On Updating the WID for eNS_Ph2 | Nokia, Nokia Shanghai Bell, ZTE, Convida Wireless, NEC, Telecom Italia, CMCC, Verizon UK ltd, Vodafone, Deutsche Telekom, Apple, Qualcomm, Lenovo | Rel-17 | Moved from 3.6. Noted | Noted | |
6.5 | SP-210222 | WID REVISED | Approval | Updated eNS_Ph2 WID | Nokia, Nokia Shanghai Bell, ZTE, Convida Wireless, NEC, Telecom Italia, CMCC, Verizon UK ltd, Vodafone, Deutsche Telekom, Apple, Qualcomm, Lenovo | Rel-17 | Moved from 3.6. SP-210222_rev3 was approved. (To be revised by MCC to a new TD number). Revised to SP-210269. | Huawei objects to the company proposed WID update in SP-210222. Nokia replies and wants to discuss more before issuing any revision Huawei is a bit puzzled by the message and is not clear where we can go from there, probably nowhere. Nokia replies the work objective is to serve the GSMA attributes support and this should remain the focus. Ericsson has some concerns with and objections to the current wording of new objective in the updated eNS_Ph2 WID. LGE does not object to have an objective on KI#6. However, we prefer to have it based on the consensus in SA2. Jinguo(ZTE) supports the wording from Krister(Ericsson) and provides comments Nokia provides rev1 While this is not my preferred outcome, Huawei will probably join ZTE and Ericsson and accept a revision with the text provided by Ericsson as a way to continue the discussion on KI#6. Huawei objects to the original company proposed updated WID, and to r01, which does not implement Ericsson's proposal properly. Expects the author to provide a new revision with the text properly implemented. Nokia stresses that the comment by Ericsson was: 'there is also a need to handle not only 'supporting UE' but also non-supporting UE, i.e. the word supporting should be removed.' This is exactly what we have implemented in the revision rev1 . However we can remove also the last bit of text without impacting the understanding of the way forward based on the above comment. Hence we can certainly provide r02 that is not changing the meaning from what is in r01. Huawei asks Nokia to please submit a revision according to Ericsson's proposal. r02 is still not acceptable. Ericsson asks Nokia to please provide a revision with the wording as seemed to be agreeable to all, i.e. 'Define a subscription-based mechanism ensuring that a UE is only allowed to be registered with compatible Network Slices.' Nokia provides r03 this does not change the intent of the change requested by Ericsson from first revision that is : ' On the actual WID, we have issues with the wording as there is also a need to handle not only 'supporting UE' but also non-supporting UE, i.e. the word supporting should be removed. Basically the sentence can be simplified as follows:' Susana (Vodafone) confirms support to revision r03 provided by Nokia Krisztian (Apple) supports rev3 provided by Nokia. Gerald (Matrixx) confirms the support with small adjustments provided in r04. | Revised |
6.5 | SP-210269 | WID REVISED | Approval | Updated eNS_Ph2 WID | Nokia, Nokia Shanghai Bell, ZTE, Convida Wireless, NEC, Telecom Italia, CMCC, Verizon UK ltd, Vodafone, Deutsche Telekom, Apple, Qualcomm, Lenovo | Rel-17 | Revision of SP-210222_Rev3. This WID REVISED was approved | Approved | |
6.5 | SP-210093 | WID REVISED | Approval | Revised WID: Enhancement of Network Slicing Phase 2 | SA WG2 | Rel-17 | Moved from 3.6. Revision of SP-200976. Noted | Noted | |
6.5 | SP-210236 | WID REVISED | Approval | Revised WID on Support of Uncrewed Aerial Systems Connectivity, Identification, and Tracking | Qualcomm | Rel-17 | Revision of SP-200979. SP-210236_rev1 approved (to be revised by MCC to a new TD number). Revised to SP-210270. | Haris (Qualcomm) provides rev1 of the revised WID that also corrects the TS number and name | Revised |
6.5 | SP-210270 | WID REVISED | Approval | Revised WID on Support of Uncrewed Aerial Systems Connectivity, Identification, and Tracking | Qualcomm | Rel-17 | Revision of SP-210236_Rev1. This WID REVISED was approved | Approved | |
6.5 | - | - | - | Block 4 (to approve) | - | - | Docs:=8 | - | |
6.5 | SP-210091 | WID REVISED | Approval | Revised WID: Study on system enablers for multi-SIM devices | SA WG2 | Rel-17 | Revision of SP-200978. Block Approved | Approved | |
6.5 | SP-210092 | WID REVISED | Approval | Revised WID: Enhanced support of Non-Public Networks | SA WG2 | Rel-17 | Revision of SP-200980. Block Approved | Approved | |
6.5 | SP-210094 | WID REVISED | Approval | Revised WID: Support of Enhanced Industrial IIoT | SA WG2 | Rel-17 | Revision of SP-200973. Block Approved | Approved | |
6.5 | SP-210095 | WID REVISED | Approval | Revised WID: Revision of the TEI17_NIESGU WID | SA WG2 | Rel-17 | Revision of SP-200457. Block Approved | Approved | |
6.5 | SP-210042 | SID REVISED | Approval | Proposed revision of the Feasibility Study on Multicast Architecture Enhancement for 5G Media Streaming (WI: FS_5GMS_Multicast) | SA WG4 | Rel-17 | Block Approved | Approved | |
6.5 | SP-210043 | SID REVISED | Approval | Proposed Updates to the Typical Traffic Characteristics for XR Services and other Media (SI: FS_XRTraffic) | SA WG4 | Rel-17 | Block Approved | Approved | |
6.5 | SP-210137 | WID REVISED | Approval | Revised WID on Enhancement on Management Aspects of 5G Service-Level Agreement | SA WG5 | Rel-17 | Block Approved | Approved | |
6.5 | SP-210138 | WID REVISED | Approval | Revised WID on Discovery of management services in 5G | SA WG5 | Rel-17 | Block Approved | Approved | |
6.6 | - | - | - | New Release 18 Study Item Descriptions | - | - | Docs:=0 | - | |
6.7 | - | - | - | New Release 18 Work Item Descriptions | - | - | Docs:=5 | - | |
6.7 | SP-210212 | WID NEW | Approval | New WID on Study on Ranging-based Services (Ranging) | SA WG1 | Rel-18 | This WID NEW was approved | Ki-Dong (LG Electronics) provides a comment and proposes a change of the completion date on the WID on Ranging-based Services (0212) to SA#93 (or to SA#94). Observation on the stage-1 Study progress shows that (1) it has a progress of 85% (2) the TR has been received 'for information'. This means that a substantial portion of Study should still be worked on in Q2. This being mentioned, it is not reasonable to set Work completion date to Q2. The SA1 chair shares his view about the planning for the Ranging study and the corresponding normative work: it can be reasonable to anticipate a completion of both aspects (study + normative) at the next SA1 meeting. He explains why. | Approved |
6.7 | - | - | - | Block 4 (to approve) | - | - | Docs:=4 | - | |
6.7 | SP-210210 | WID NEW | Approval | New WID on Enhanced Access to and Support of Network Slice (EASNS) | SA WG1 | Rel-18 | Block Approved | Approved | |
6.7 | SP-210211 | WID NEW | Approval | New WID on 5G Timing Resiliency System (5TRS) | SA WG1 | Rel-18 | Block Approved | Approved | |
6.7 | SP-210213 | WID NEW | Approval | New WID on Data Integrity in 5G (DI_5G) | SA WG1 | Rel-18 | Block Approved | Approved | |
6.7 | SP-210216 | WID NEW | Approval | New WID on Low Power High Accuracy Positioning for industrial IoT scenarios (LPHAP) | SA WG1 | Rel-18 | Block Approved | Approved | |
6.8 | - | - | - | Revised Release 18 Study Item Descriptions and Work Item Descriptions | - | - | Docs:=2 | - | |
6.8 | - | - | - | Block 4 (to approve) | - | - | Docs:=2 | - | |
6.8 | SP-210202 | SID REVISED | Approval | SID update for FS_5GET (Guidelines for Extra-territorial 5G Systems) | SA WG1 | Rel-18 | Block Approved | Approved | |
6.8 | SP-210209 | SID REVISED | Approval | SID update for FS_TACMM (Study on supporting tactile and multi-modality communication services in 5GS) | SA WG1 | Rel-18 | Block Approved | Approved | |
6.9 | - | - | - | Specifications for Information | - | - | Docs:=11 | - | |
6.9 | - | - | - | Block 4 (to note) | - | - | Docs:=11 | - | |
6.9 | SP-210103 | DRAFT TR | Information | TR 33.845 'Study on storage and transport of 5G Core (5GC) security parameters for Authentication Credential Repository Processing Function (ARPF) authentication' | SA WG3 | Rel-17 | Noted | Noted | |
6.9 | SP-210044 | DRAFT TR | Information | 5G Media Streaming Extensions for Edge Processing (Draft Technical Report) [26.803] (FS_EMSA) | SA WG4 | Rel-17 | Revised in SP-210234 | Revised | |
6.9 | SP-210234 | DRAFT TR | Information | 5G Media Streaming Extensions for Edge Processing (Draft Technical Report) [26.803] (FS_EMSA) | SA WG4 | Rel-17 | Revision of SP-210044. Noted | Noted | |
6.9 | SP-210051 | DRAFT TR | Information | 5G Video Codec Characteristics | SA WG4 | Rel-17 | Noted | Noted | |
6.9 | SP-210176 | DRAFT TS | Information | Presentation of TS 23.289 v1.0.0 for information | SA WG6 | Rel-17 | Noted | Noted | |
6.9 | SP-210201 | DRAFT TR | Information | TR 22.874 v.1.0.0 for information (FS_AMMT, Study on AI/ML Model Transfer in 5GS) | SA WG1 | Rel-18 | Noted | Noted | |
6.9 | SP-210205 | DRAFT TR | Information | TR 22.867 v.1.0.0 for information (FS_5GSEI, Study on 5G Smart Energy and Infrastructure) | SA WG1 | Rel-18 | Noted | Noted | |
6.9 | SP-210206 | DRAFT TR | Information | TR 22.855 v.1.0.0 for information (FS_Ranging, Study on Ranging-based Services) | SA WG1 | Rel-18 | Noted | Noted | |
6.9 | SP-210207 | DRAFT TR | Information | TR 22.858 v.1.0.0 for information (FS_Resident, Study of Enhancements for Residential 5G) | SA WG1 | Rel-18 | Noted | Noted | |
6.9 | SP-210208 | DRAFT TR | Information | TR 22.859 v.1.0.0 for information (FS_PIN, Study on Personal IoT Networks) | SA WG1 | Rel-18 | Noted | Noted | |
6.9 | SP-210239 | DRAFT TR | Information | Presentation of TR 26.802 '5G Multimedia Streaming (5GMS); Multicast architecture' for Information | SA WG4 | Rel-17 | Noted | Noted | |
6.10 | - | - | - | Specifications for Approval / for Information and Approval | - | - | Docs:=16 | - | |
6.10 | SP-210226 | DISCUSSION | Decision | Concerns with SA6 Working Agreement on SBI interactions within EDGEAPP | Huawei Technologies, HiSilicon, China Telecom, CATT, China Unicom | Rel-17 | Concerns over SP-210175. See also SP-210253. Noted | SA6 Chair (Suresh Chitturi) provides comments to SP-201226 to clarify the proceedings in SA6 that led to the approval of pCR in S6-201730 as a working agreement, and responses to other concerns. Huawei would like the discussion to stay on track of the misleading architecture diagram, which is the topic of this contribution. Huawei provides clarifications to the technical views provided by SA6 Chair on the pCR S6-210730 approved as a Working Agreement in SA6. Samsung clarifies that the new architecture representation is complete and does not leave room for assumptions or misinterpretations. Mike (Convida Wireless) comments that they agree with Samsung that the new architecture representation is complete and does not leave room for assumptions or misinterpretations. Jinguo(ZTE) provides more background information and share the view with Huawei that the conclusion in S6-210730 is premature. Huawei disagrees with the views from Samsung and Convida Wireless that the EDGEAPP SBA representation is technically correct and unambiguous. Jinguo(ZTE) correct some statements. Apple supports the SA6 working agreement and suggests that if companies are unhappy with the working agreement, this can be challenged as per the 3GPP WP. Samsung clarifies that S6-210730 was approved after due considerations and is not premature at all. Intel shares the view that the approval of S6-210730 is not premature. Intel thinks that it is up to SA6 Chairman discretion to declare a WA based on his assessment of the situation in the working group. Mike (Convida Wireless) replies to Huawei. SA2 Chair clarifies that the requirement for quorum doesn't apply if Working Agreement results in a formal vote. | Noted |
6.10 | SP-210253 | DISCUSSION | Discussion | SA WG6 Working Agreement on SBI interactions within EDGEAPP | AT&T, Deutsche Telekom, SKT, T-Mobile, Verizon, Apple, Convida, Ericsson, FirstNet, Intel, InterDigital, Lenovo, Motorola Mobility, Nokia, Nokia Shanghai Bell, Qualcomm, Samsung, Sony | Rel-17 | Related to SP-210226. Noted | Huawei proposes this discussion paper to be noted, as the discussion took place as part of SP-210226 and its conclusion will be taken on SP-210175. | Noted |
6.10 | SP-210175 | DRAFT TS | Approval | Presentation of TS 23.558 v2.0.0 for approval | SA WG6 | Rel-17 | Concerns raised in SP-210226. Discussion over Working Agreement in SP-210253. Noted | Huawei objects to the approval of TS 23.558 with an architecture diagram that shows the UE able to consume CN NF services, see SP-210226 for details. Samsung explains that the current version of TS 23.558 already addresses Huawei's techincal concern, and there is no confusion as such. Huawei clarifies that Samsung's explanations do not match the architecture diagram that is being proposed for TS 23.558, and make my point. Saso (Intel) seeks clarification from Patrice (Huawei). Haris (Qualcomm) comments that Qualcomm cannot agree to open the TS and start changing the content. The TS can be approved as is or sent back to SA6 changing the version number as defined in TR 21.900 Huawei answers to Intel and indicates, that due to the objection from Qualcomm for seeking resolution at SA plenary, the only option left is to send back the TS to SA6 for further work in the next meeting cycle. As stage 2 is not freezed yet, this would not require any formal exception. Huawei confirms their objection to the approval of TS 23.558 v2.0.0 at this plenary, and requests to 'send it back' to SA6 for further work on the proposed architecture diagram. Saso (Intel) makes a proposal to approve 23.558 with addition of an Editor's note. Susana (Vodafone) objects to approval of TS 23.558 Samsung clarifies that the new architecture diagram conforms to both, the details in TS 23.558 and any of the SA2 work. Samsung disagrees with Vodafone's assessment and seeks clarification. Ericsson comments on approval or not of TS 23.558 and that SA6 needs to handle the likely challenge of the WA in the next SA6 meeting. CATT slightly prefer to not approve TS 23.558 and suggest SA6 resolve this technical dispute by involving CT1/SA2/SA3 at WG level. Biao(China Telecom) shares the same view with Vodafone and suggests to send the TS back to SA6. Futurewei agrees that approval of TS 23.558 can wait till next meeting. Nokia's preference is to approve TS 23.558 in this meeting. Amendments, corrections can always be brought to TSs which have already been approved, this is business as usual. China Unicom supports the proposal of sending TS 23.558 v2.0.0 back to SA6 for further clarification. ZTE agrees that approval of TS 23.558 can wait till next meeting. Spreadtrum(Chunhui Zhu) supports to postpone the approval of TS 23.558 v2.0.0 to next SA meeting. Suresh Chitturi (SA6 Chair) provides clarifications on architecture figure concerns cited in pCR S6-210730 included in the TS 23.558 v2.0.0 for approval, the importance of TS approval in SA#91-e, and additional information from previous SA6 discussions including the reference to S6-202263 which contains the agreed working assumption in SA6. Apple supports the approval of TS 23.558 in this meeting. The SA6 WA is a separate consideration, and we should avoid mixing / linking them together. As pointed out by others, not approving TS 23.558 does not remove the content related to the WA. InterDigital comments on approval or not of TS 23.558 and that SA6 needs to handle the possible challenge of the WA in the upcoming SA6 meeting. Haris (Qualcomm) comments that approval of a TS or TR by TSG should only be seen as project management related step Huawei confirms that TSG SA is not a rubberstamping group as some are claiming, and that the contention regarding the TS should be resolved in SA6 before it is approved by TSG SA. Convida Wireless supports approval of TS 23.558 at this meeting. FirstNet supports the approval of TS 23.558 in this meeting. Sony supports the approval of TS 23.558 at SA#91-e since it is decoupled from any actions that may need to be taken if WA#39 is challenged. The WA, if challenged, shall be handled at the next SA6 meeting. | Noted |
6.10 | - | - | - | Block 4 (to approve) | - | - | Docs:=13 | - | |
6.10 | SP-210096 | DRAFT TR | Approval | Presentation of 23.776: 'Study on architecture enhancements for 3GPP support of advanced Vehicle-to-Everything (V2X) services; Phase 2' for approval | SA WG2 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210097 | DRAFT TR | Approval | Presentation of 23.700-07: 'Study on enhanced support of Non-Public Networks (NPN)' for approval | SA WG2 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210098 | DRAFT TR | Approval | Presentation of 23.757: 'Study on architectural enhancements for 5G multicast-broadcast services' for approval | SA WG2 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210099 | DRAFT TR | Approval | Presentation of 23.700-93: 'Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture; Phase 2' for approval | SA WG2 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210100 | DRAFT TR | Approval | Presentation of 23.700-40: 'Study on enhancement of network slicing; Phase 2' for approval | SA WG2 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210101 | DRAFT TR | Approval | Presentation of 23.752: 'Study on system enhancement for Proximity based Services (ProSe) in the 5G System (5GS' for approval | SA WG2 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210102 | DRAFT TR | Approval | Presentation of 23.700-20: 'Study on enhanced support of Industrial Internet of Things (IIoT) in the 5G System (5GS)' for approval | SA WG2 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210139 | DRAFT TR | Approval | TR 28.809 'Study on enhancement of management data analytics' | SA WG5 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210140 | DRAFT TR | Approval | TR 28.808 'Study on management and orchestration aspects of integrated satellite components in a 5G network' | SA WG5 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210173 | DRAFT TR | Approval | Presentation of TR 23.700-24 v2.0.0 for approval | SA WG6 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210174 | DRAFT TR | Approval | Presentation of TR 23.755 v2.0.0 for approval | SA WG6 | Rel-17 | Block Approved | Approved | |
6.10 | SP-210203 | DRAFT TR | Approval | TR 22.835 v.1.0.0 for one-step approval (FS_EASNS, Enhanced Access to and Support of Network Slice) | SA WG1 | Rel-18 | Block Approved | Approved | |
6.10 | SP-210204 | DRAFT TR | Approval | TR 22.878 v.1.0.0 for one-step-approval (FS_5TRS, Study on 5G Timing Resiliency System) | SA WG1 | Rel-18 | Block Approved | Approved | |
7 | - | - | - | Release Planning | - | - | Docs:=0 | - | |
7.1 | - | - | - | General Release Planning issues | - | - | Docs:=0 | - | |
7.2 | - | - | - | Issues related to Release 16 and earlier planning (nothing expected here) | - | - | Docs:=0 | - | |
7.3 | - | - | - | Release 17 Planning (schedule, prioritization, etc.) | - | - | Docs:=0 | - | |
7.4 | - | - | - | Release 18 Planning (schedule, prioritization, etc.) | - | - | Docs:=0 | - | |
8 | - | - | - | Rel-8 CRs | - | - | Docs:=0 | - | |
9 | - | - | - | Rel-9 CRs | - | - | Docs:=0 | - | |
10 | - | - | - | Rel-10 CRs | - | - | Docs:=0 | - | |
11 | - | - | - | Rel-11 CRs | - | - | Docs:=1 | - | |
11 | SP-210169 | CR PACK | Approval | Rel-11 CRs on OAM | SA WG5 | This CR PACK was approved | Approved | ||
12 | - | - | - | Rel-12 CRs | - | - | Docs:=5 | - | |
12 | SP-210247 | CR | Approval | 33.328 CR0063 (Rel-12, 'F'): IETF references updates | Orange | Rel-12 | This CR was approved | Approved | |
12 | SP-210248 | CR | Approval | 33.328 CR0064 (Rel-13, 'A'): IETF references updates | Orange | Rel-13 | This CR was approved | Approved | |
12 | SP-210249 | CR | Approval | 33.328 CR0065 (Rel-14, 'A'): IETF references updates | Orange | Rel-14 | This CR was approved | Approved | |
12 | SP-210250 | CR | Approval | 33.328 CR0066 (Rel-15, 'A'): IETF references updates | Orange | Rel-15 | This CR was approved | Approved | |
12 | SP-210251 | CR | Approval | 33.328 CR0067 (Rel-16, 'A'): IETF references updates | Orange | Rel-16 | This CR was approved | Approved | |
13 | - | - | - | Rel-13 CRs | - | - | Docs:=0 | - | |
14 | - | - | - | Rel-14 CRs | - | - | Docs:=1 | - | |
14 | SP-210108 | CR PACK | Approval | Rel-14 CRs on Security of the Mission Critical Service | SA WG3 | This CR PACK was approved | Approved | ||
15 | - | - | - | Rel-15 CRs | - | - | Docs:=4 | - | |
15 | SP-210053 | CR PACK | Approval | CRs to 23.502, 23.503 (5GS_Ph1, Rel-15) | SA WG2 | This CR PACK was approved | Approved | ||
15 | SP-210113 | CR PACK | Approval | Rel-15 CRs on Security aspects of 5G System - Phase 1 | SA WG3 | This CR PACK was approved | Approved | ||
15 | SP-210145 | CR PACK | Approval | Rel-15 CRs on TEI | SA WG5 | This CR PACK was approved | Approved | ||
15 | SP-210154 | CR PACK | Approval | Rel-15 CRs on Network Resource Model (NRM) for 5G networks and network slicing | SA WG5 | This CR PACK was approved | Approved | ||
16 | - | - | - | Rel-16 CRs | - | - | Docs:=0 | - | |
16.1 | - | - | - | SA WG1 Rel-16 CRs | - | - | Docs:=2 | - | |
16.1 | - | - | - | Block 5 (to approve) | - | - | Docs:=2 | - | |
16.1 | SP-210197 | CR PACK | Approval | UAV related CRs (starting from Rel-16) | SA WG1 | Block Approved | Approved | ||
16.1 | SP-210198 | CR PACK | Approval | Network slice related CRs (from Rel-16) | SA WG1 | Block Approved | Approved | ||
16.2 | - | - | - | SA WG2 Rel-16 CRs | - | - | Docs:=13 | - | |
16.2 | - | - | - | Block 5 (to approve) | - | - | Docs:=13 | - | |
16.2 | SP-210054 | CR PACK | Approval | CRs to 23.501 (Vertical_LAN, Rel-16) | SA WG2 | Block Approved | Approved | ||
16.2 | SP-210055 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503, 23.682 (5G_CIoT, Rel-16) | SA WG2 | Block Approved | Approved | ||
16.2 | SP-210056 | CR PACK | Approval | CRs to 23.273, 23.502 (5G_eLCS, Rel-16) | SA WG2 | Block Approved | Approved | ||
16.2 | SP-210057 | CR PACK | Approval | CR to 23.502 (5G_eSBA, Rel-16) | SA WG2 | Block Approved | Approved | ||
16.2 | SP-210242 | CR PACK | Approval | CRs to 23.501 (5G_URLLC, Rel-16) | SA WG2 | Revision of SP-210058. Block Approved | Approved | ||
16.2 | SP-210243 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 (5GS_Ph1, Rel-16) | SA WG2 | Revision of SP-210059. Block Approved | Approved | ||
16.2 | SP-210244 | CR PACK | Approval | CRs to 23.501, 23.502 (5WWC, Rel-16) | SA WG2 | Revision of SP-210060. Block Approved | Approved | ||
16.2 | SP-210245 | CR PACK | Approval | CRs to 23.501, 23.502 (ATSSS, Rel-16) | SA WG2 | Revision of SP-210061. Block Approved | Approved | ||
16.2 | SP-210246 | CR PACK | Approval | CRs to 23.288 (eNA, Rel-16) | SA WG2 | Revision of SP-210062. Block Approved | Approved | ||
16.2 | SP-210075 | CR PACK | Approval | CRs to 23.502 (eNS, Rel-16) | SA WG2 | Block Approved | Approved | ||
16.2 | SP-210080 | CR PACK | Approval | CRs to 23.401, 23.501 (RACS, Rel-16) | SA WG2 | Block Approved | Approved | ||
16.2 | SP-210081 | CR PACK | Approval | CRs to 23.501 (TEI16, Rel-16) | SA WG2 | Block Approved | Approved | ||
16.2 | SP-210082 | CR PACK | Approval | CRs to 23.401, 23.502, 23.503, 23.682 (TEI16, Rel-16) | SA WG2 | Block Approved | Approved | ||
16.3 | - | - | - | SA WG3 and SA3 LI Rel-16 CRs | - | - | Docs:=8 | - | |
16.3 | - | - | - | Block 5 (to approve) | - | - | Docs:=8 | - | |
16.3 | SP-210031 | CR PACK | Approval | Rel-16 CRs on Lawful Interception | SA WG3-LI | Rel-16 | Block Approved | Approved | |
16.3 | SP-210109 | CR PACK | Approval | Rel-16 CRs on TEI | SA WG3 | Block Approved | Approved | ||
16.3 | SP-210111 | CR PACK | Approval | Rel-16 CRs on Security for 5G_eSBA | SA WG3 | Block Approved | Approved | ||
16.3 | SP-210112 | CR PACK | Approval | Rel-16 CRs on Security aspects of SEAL | SA WG3 | Block Approved | Approved | ||
16.3 | SP-210114 | CR PACK | Approval | Rel-16 CRs on Security of security of the Wireless and Wireline Convergence for the 5G system architecture | SA WG3 | Block Approved | Approved | ||
16.3 | SP-210115 | CR PACK | Approval | Rel-16 CRs on Security of 5G_CIoT | SA WG3 | Block Approved | Approved | ||
16.3 | SP-210117 | CR PACK | Approval | Rel-16 CRs on Security Assurance Specification for 5G | SA WG3 | Block Approved | Approved | ||
16.3 | SP-210119 | CR PACK | Approval | Rel-16 CRs on Security Aspects of eV2XARC | SA WG3 | Block Approved | Approved | ||
16.4 | - | - | - | SA WG4 Rel-16 CRs | - | - | Docs:=7 | - | |
16.4 | SP-210039 | CR PACK | Approval | CRs on Aggregated essential corrections & openAPI implementation for 5GMS3 [26.511 & 26.512] (WI: 5GMS3) | SA WG4 | An issue was reported with 26.512 CR0008R1. 26.512 CR0008R1 was not marked as merged. The other CRs in this CR Pack were approved | The SA4 chair explained that 26.512 CR0008R1 from CR pack in Tdoc SP-210039 should not be approved because it was merged into 26.512 CR0007R2. | Partially approved | |
16.4 | - | - | - | Block 5 (to approve) | - | - | Docs:=6 | - | |
16.4 | SP-210034 | CR PACK | Approval | CR on corrections to Main USD Schema [26.346] (WI: TEI16) | SA WG4 | Block Approved | Approved | ||
16.4 | SP-210035 | CR PACK | Approval | CRs on IETF Reference Update for QOSE2EMTSI & MMCMH [26.114] (WI: 5G_MEDIA_MTSI_ext,QOSE2EMTSI,MMCMH) | SA WG4 | Block Approved | Approved | ||
16.4 | SP-210036 | CR PACK | Approval | CRs on Updates on IETF References for IMS Telepresence [26.223] (WI: IMS_TELEP_S4) | SA WG4 | Block Approved | Approved | ||
16.4 | SP-210037 | CR PACK | Approval | CR on Clarifications and corrections (Rel-16) to 5GMSA [26.501] (WI: 5GMSA) | SA WG4 | Block Approved | Approved | ||
16.4 | SP-210038 | CR PACK | Approval | CRs on the 8K VR 360 Video over 5GMS [26.511 & 26.118] (WI: 8K_VR_5G) | SA WG4 | Block Approved | Approved | ||
16.4 | SP-210040 | CR PACK | Approval | CR on Video Support for ITT4RT [26.114] (WI: ITT4RT) | SA WG4 | Block Approved | Approved | ||
16.5 | - | - | - | SA WG5 Rel-16 CRs | - | - | Docs:=13 | - | |
16.5 | - | - | - | Block 5 (to approve) | - | - | Docs:=13 | - | |
16.5 | SP-210143 | CR PACK | Approval | Rel-16 CRs on Energy efficiency of 5G | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210146 | CR PACK | Approval | Rel-16 CRs on TEI Batch 1 | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210147 | CR PACK | Approval | Rel-16 CRs on TEI Batch 2 | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210150 | CR PACK | Approval | Rel-16 CRs on Enhancement of performance assurance for 5G networks including network slicing | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210151 | CR PACK | Approval | Rel-16 CRs on Closed loop SLS Assurance | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210153 | CR PACK | Approval | Rel-16 CRs on NRM enhancements | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210158 | CR PACK | Approval | Rel-16 CRs on Network Slice Management Charging in 5G System | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210159 | CR PACK | Approval | Rel-16 CRs on Network Exposure Charging in 5G System Architecture | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210160 | CR PACK | Approval | Rel-16 CRs on Charging aspects of ETSUN | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210162 | CR PACK | Approval | Rel-16 CRs on Charging Enhancement of 5GC interworking with EPC | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210163 | CR PACK | Approval | Rel-16 CRs on Charging AMF in 5G System Architecture Phase 1 | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210166 | CR PACK | Approval | Rel-16 CRs on Service Based Interface for 5G Charging | SA WG5 | Block Approved | Approved | ||
16.5 | SP-210168 | CR PACK | Approval | Rel-16 CRs on Management of MDT in 5G | SA WG5 | Block Approved | Approved | ||
16.6 | - | - | - | SA WG6 Rel-16 CRs | - | - | Docs:=0 | - | |
17 | - | - | - | Rel-17 CRs | - | - | Docs:=0 | - | |
17.1 | - | - | - | SA WG1 Rel-17 CRs | - | - | Docs:=3 | - | |
17.1 | SP-210200 | CR PACK | Approval | Rel-17: SA1's Non-inclusive language replacement | SA WG1 | Removed from block approval. Nokia questions 22.827 CR0002. 22.827 CR0002 was postponed and other CRs in this CR Pack were approved. (CR Pack partially approved). | Nokia provides comments on CR 0002 on TR 22.827, in relation with incoming LSs in SP-210006 and SP-210008. SA1 chairman is ok with holding the CR but believes the decision must be taken by the SA plenary because maybe there could be other CRs affected SA Chair proposes to keep current way of working, as agreed at last plenary meeting. Rapporteurs should cooperate to avoid problems within 3GPP. External issues should be handled according to guidance from LS from last meeting. Orange clarifies the changes to be applied for inclusive language in 3GPP specifications from Release 17 onward. Nokia understands the issue raised by VF is whether non-inclusive language replacement should be done already in Rel-16 to avoid having the changes visible only in 2022, since some specifications may not be available for Rel-17 before 2022. This is a different issue than putting on hold a Rel-17 CR because of changes possibly not aligned with what IEEE 1588 may decide to do in the future in terms of non-inclusive language replacement in their specifications. Puneet (SA2 Chair) comments SA1 chair supports SA2 chair comments. | Partially approved | |
17.1 | - | - | - | Block 5 (to approve) | - | - | Docs:=2 | - | |
17.1 | SP-210196 | CR PACK | Approval | ProSe related CRs (starting Rel-13) | SA WG1 | Block Approved | Approved | ||
17.1 | SP-210199 | CR PACK | Approval | Rel-17: TEI 17 | SA WG1 | Block Approved | Approved | ||
17.2 | - | - | - | SA WG2 Rel-17 CRs | - | - | Docs:=26 | - | |
17.2 | SP-210066 | CR PACK | Approval | CR to 23.501 (5MBS, Rel-17) | SA WG2 | NOTE: Some Companies believe this should be specified in 23.247 instead and may object to this CR. Noted (23.501 CR2613 marked as postponed) | LaeYoung (LGE) proposes NOT to approve this CR because SA2 needs more time to discuss which TS (TS 23.247 or TS 23.501) is appropriate to capture MB-SMF discovery/selection. Nokia supports the proposal from LGE to not approve the CR in SP-210066. Let's take proper discussion in next SA2 meeting about where to document the MB-SMF discovery and selection principles. Ericsson supports LGE proposal to not approve the CR, as discussed between interested companies and indicated in SA2 email exploder. | Noted | |
17.2 | SP-210170 | CR PACK | Approval | CR to 23.501 (TEI17, 5GS_Ph1, Rel-17) | SA WG2 | NOTE: Motorola raised an issue on this CR and asked for it to be removed from potential block approval. CT WG1 CR has dependency on this CR. This CR (and CR Pack) was postponed.. | Lenovo requests the CR in SP-210170 to not be approved and to reconsider it in SA2. Broadcom supports the concerns raised by Lenovo regarding the CR in SP-210170 and requests this CR NOT to be approved. BlackBerry disagrees with Lenovo's concerns. Moreover, Lenovo's proposal in practice doesn't solve the problem addressed in the CR. BlackBerry askes Lenovo to consider the points mentioned below. In addition, nothing prevents Motorola from submitting the proposal to the next SA2 meeting, even when SP-210170 is approved. | Postponed | |
17.2 | SP-210065 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 (5GSAT_ARCH, Rel-17) | SA WG2 | Removed from block approval. Deutsche Telekom questions 23.501 CR2547R1 introducing 5.x.y, but there is no 5.x. 23.501 CR2547R1 revised in SP-210255. The remaining CRs in this Pack were approved | Deutsche Telekom likes to highlight, that the CR 2547 to TS 23.501 Network selection for NR satellite access seems to be not implementable. The CR introduces a new subsection 5.x.y, whereas the chapter 5.x is not defined. Hence, Deutsche Telekom would like to understand the naming and definition of chapter 5.x. If this is currently not specified, it is proposed not to approved the CR and send it back to SA2. Nokia's provides SP-210255 which contains revision of CR 2547 from CR pack SP-210065. Nokia's provides SP-210255_rev1 as per CC#5 discussions. | Partially approved | |
17.2 | SP-210255 | CR | Approval | 23.501 CR2547R2 (Rel-17, 'B'): Network selection for NR satellite access | Nokia | Rel-17 | Created at CC#4. rev1 approved (to be revised to a new TD number by MCC). Revised to SP-210271. | Revised | |
17.2 | SP-210271 | CR | Approval | 23.501 CR2547R3 (Rel-17, 'B'): Network selection for NR satellite access | Nokia | Rel-17 | Revision of SP-210255_Rev1. This CR was approved | Approved | |
17.2 | - | - | - | Block 5 (to approve) | - | - | Docs:=21 | - | |
17.2 | SP-210063 | CR PACK | Approval | CRs to 23.032, 23.273 (5G_eLCS_ph2, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210064 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 (5G_ProSe, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210067 | CR PACK | Approval | CR to 23.501 (AKMA, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210068 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 (ATSSS_Ph2, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210069 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 (eEDGE_5GC, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210070 | CR PACK | Approval | CRs to 23.288 (eNA_Ph2, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210071 | CR PACK | Approval | CRs to 23.288 (eNA_Ph2, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210072 | CR PACK | Approval | CRs to 23.288, 23.501 (eNA_Ph2, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210073 | CR PACK | Approval | CRs to 23.502, 23.503 (eNA_Ph2, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210074 | CR PACK | Approval | CRs to 23.501, 23.503 (eNPN, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210076 | CR PACK | Approval | CR to 23.502 (ETSUN, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210077 | CR PACK | Approval | CR to 23.501 (eV2XARC, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210078 | CR PACK | Approval | CR to 23.501 (IABARC, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210079 | CR PACK | Approval | CR to 23.502 (LTE_eMTC5-Core, NB_IOTenh3-Core, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210083 | CR PACK | Approval | CRs to 23.501, 23.502 (eNS_Ph2, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210084 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 (IIoT, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210085 | CR PACK | Approval | CRs to 23.203, 23.401, 23.501, 23.502, 23.503 (MPS2, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210086 | CR PACK | Approval | CRs to 23.228, 23.401, 23.501, 23.502 (MUSIM, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210087 | CR PACK | Approval | CRs to 23.002, 23.401, 23.402, 23.501, 23.502, 23.737, 23.754 (TEI17, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210088 | CR PACK | Approval | CRs to 23.167, 23.228, 23.501, 23.502, 23.503 (TEI17_XXX, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.2 | SP-210089 | CR PACK | Approval | CRs to 23.501, 23.503 (5G_AIS, Rel-17) | SA WG2 | Block Approved | Approved | ||
17.3 | - | - | - | SA WG3 and SA WG3 LI Rel-17 CRs | - | - | Docs:=4 | - | |
17.3 | - | - | - | Block 5 (to approve) | - | - | Docs:=4 | - | |
17.3 | SP-210032 | CR PACK | Approval | Rel-17 CRs on Lawful Interception | SA WG3-LI | Rel-17 | Block Approved | Approved | |
17.3 | SP-210116 | CR PACK | Approval | Rel-17 CRs on Enhancements to User Plane Integrity Protection Support in 5GS | SA WG3 | Block Approved | Approved | ||
17.3 | SP-210118 | CR PACK | Approval | Rel-17 CRs on Authentication and key management for applications based on 3GPP credential in 5G | SA WG3 | Block Approved | Approved | ||
17.3 | SP-210120 | CR PACK | Approval | Rel-17 CRs on eSCAS_5G for Non-3GPP InterWorking Function | SA WG3 | Block Approved | Approved | ||
17.4 | - | - | - | SA WG4 Rel-17 CRs | - | - | Docs:=0 | - | |
17.5 | - | - | - | SA WG5 Rel-17 CRs | - | - | Docs:=12 | - | |
17.5 | - | - | - | Block 5 (to approve) | - | - | Docs:=12 | - | |
17.5 | SP-210141 | CR PACK | Approval | Rel-17 CRs on Management Aspects of 5G Network Sharing | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210142 | CR PACK | Approval | Rel-17 CRs on Enhancements on EE for 5G networks | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210144 | CR PACK | Approval | Rel-17 CRs on Enhancement on Management Aspects of 5G Service-Level Agreement | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210149 | CR PACK | Approval | Rel-17 CRs on TEI | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210152 | CR PACK | Approval | Rel-17 CRs on Discovery of management services in 5G | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210155 | CR PACK | Approval | Rel-17 CRs on Additional NRM features | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210156 | CR PACK | Approval | Rel-17 CRs on Enhancements of 5G performance measurements and KPIs | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210157 | CR PACK | Approval | Rel-17 CRs on Enhancement of Handover Optimization | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210161 | CR PACK | Approval | Rel-17 CRs on Charging enhancement for URLLC | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210164 | CR PACK | Approval | Rel-17 CRs on IMS Charging in 5G System Architecture | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210165 | CR PACK | Approval | Rel-17 CRs on N40 Interface Enhancements to Support GERAN and UTRAN | SA WG5 | Block Approved | Approved | ||
17.5 | SP-210167 | CR PACK | Approval | Rel-17 CRs on Management of MDT enhancement in 5G | SA WG5 | Block Approved | Approved | ||
17.6 | - | - | - | SA WG6 Rel-17 CRs | - | - | Docs:=6 | - | |
17.6 | - | - | - | Block 5 (to approve) | - | - | Docs:=6 | - | |
17.6 | SP-210178 | CR PACK | Approval | Rel-17 CRs to TS23282 for eMCData3 | SA WG6 | Block Approved | Approved | ||
17.6 | SP-210179 | CR PACK | Approval | Rel-17 CR to TS23379 eMONASTERY2 | SA WG6 | Block Approved | Approved | ||
17.6 | SP-210180 | CR PACK | Approval | Rel-17 CRs to TS23280 and TS23379 for enh3MCPTT | SA WG6 | Block Approved | Approved | ||
17.6 | SP-210181 | CR PACK | Approval | Rel-17 CRs TS23434 for eSEAL | SA WG6 | Block Approved | Approved | ||
17.6 | SP-210182 | CR PACK | Approval | Rel-17 CRs TS23286 for eV2XAPP | SA WG6 | Block Approved | Approved | ||
17.6 | SP-210183 | CR PACK | Approval | Rel-17 CR TS23222 for TEI17 | SA WG6 | Block Approved | Approved | ||
18 | - | - | - | Rel-18 CRs | - | - | Docs:=0 | - | |
18.1 | - | - | - | SA WG1 Rel-18 CRs | - | - | Docs:=3 | - | |
18.1 | - | - | - | Block 5 (to approve) | - | - | Docs:=3 | - | |
18.1 | SP-210215 | CR PACK | Approval | CR on DI_5G | SA WG1 | Rel-18 | Block Approved | Approved | |
18.1 | SP-210223 | CR PACK | Approval | Stage 1 CRs on FS_eFRMCS | SA WG1 | Block Approved | Approved | ||
18.1 | SP-210217 | CR PACK | Approval | CR on LPHAP | SA WG1 | Rel-18 | Block Approved | Approved | |
18.2 | - | - | - | SA WG2 Rel-18 CRs | - | - | Docs:=0 | - | |
18.3 | - | - | - | SA WG3 and SA WG3 LI Rel-18 CRs | - | - | Docs:=0 | - | |
18.4 | - | - | - | SA WG4 Rel-18 CRs | - | - | Docs:=0 | - | |
18.5 | - | - | - | SA WG5 Rel-18 CRs | - | - | Docs:=0 | - | |
18.6 | - | - | - | SA WG6 Rel-18 CRs | - | - | Docs:=0 | - | |
19 | - | - | - | CR’s related to Study Items | - | - | Docs:=0 | - | |
20 | - | - | - | Project Management and TSG SA owned specifications | - | - | Docs:=0 | - | |
20.1 | - | - | - | General project management issues | - | - | Docs:=8 | - | |
20.1 | SP-210127 | DISCUSSION | Endorsement | Post-COVID meeting planning | Deutsche Telekom, Telecom Italia | Noted | Noted | ||
20.1 | SP-210126 | DISCUSSION | Discussion | Considerations on tracking of stage-1 requirements | Qualcomm | Noted | Siemens proposes to discuss SP-210126, SP-210227, and SP-210228 in the same email thread. Nokia provides comments on the proposal in SP-210126, based on examples of WIDs available at SA#91 as well as WIDs approved by CT#91. We suggest to use existing WID/SID template to keep track of parent stage 1 WIDs and make sure this is consistently used by WGs. We also suggest a possible amendment to WID/SID template to allow stage 3 downstream groups to reference both stage 2 parent WID and stage 1 parent WID, to ensure stage 1 parent WID is also listed in stage 3 WIDs. Samsung suggests that several objects in the proposal in SP-210227 can be met only by active participation: new procedures will not suffice. Samsung supports the initiative in SP-210126 to clearly state in WIDs where requirements are stated and notes that many requirements cross releases. Further work can be done to present the state of work by MCC. Siemens thanks Nokia for their proposal. Siemens also points out that an analysis of their approach yields the same result as for SP-210126 (for the analysis of the SP-210126 see SP-210228). Intel is of the opinion that the existing tools summarized in slides 6 and 7 of SP-210126 are sufficient for requirement tracking. Intel supports the proposal in SP-210126. Ericsson supports the proposal in SP-210126 as a reasonable and practical solution. Siemens asks for clarification of the difference between Nokia's proposal and the proposal in SP-210126. Siemens thanks vivo for the proposed solutions for requirements tracking. For reasons similar to those laid out in SP-210228, Siemens favours vivo's proposals over other proposal made at this plenary meeting. Nokia clarifies the proposal is aligned with proposal in SP-210126, but we suggest to possibly amend the WID template to make it clear that, for stage 3 SID/WID, not only the Stage 2 parent SID/WID is needed but also the Stage 1 SID/WID, if available and if relevant. Siemens thanks Nokia for the provided explanation. Siemens asks Qualcomm for clarification of the delta of their proposal in SP-210126 in respect to existing procedure. Siemens uploaded revision one of the discussion paper SP-210228. | Noted | |
20.1 | SP-210227 | DISCUSSION | Endorsement | Verticals' requirement concerning down-stream groups | Siemens, Daimler, EBU, Novamint, Philips, Sennheiser, Volkswagen AG | Rel-17 | This was noted. | Siemens proposes to discuss SP-210126, SP-210227, and SP-210228 in the same email thread. Nokia provides comments on the proposal in SP-210126, based on examples of WIDs available at SA#91 as well as WIDs approved by CT#91. We suggest to use existing WID/SID template to keep track of parent stage 1 WIDs and make sure this is consistently used by WGs. We also suggest a possible amendment to WID/SID template to allow stage 3 downstream groups to reference both stage 2 parent WID and stage 1 parent WID, to ensure stage 1 parent WID is also listed in stage 3 WIDs. Samsung suggests that several objects in the proposal in SP-210227 can be met only by active participation: new procedures will not suffice. Samsung supports the initiative in SP-210126 to clearly state in WIDs where requirements are stated and notes that many requirements cross releases. Further work can be done to present the state of work by MCC. Siemens thanks Nokia for their proposal. Siemens also points out that an analysis of their approach yields the same result as for SP-210126 (for the analysis of the SP-210126 see SP-210228). Intel is of the opinion that the existing tools summarized in slides 6 and 7 of SP-210126 are sufficient for requirement tracking. Intel supports the proposal in SP-210126. Ericsson supports the proposal in SP-210126 as a reasonable and practical solution. Siemens asks for clarification of the difference between Nokia's proposal and the proposal in SP-210126. Siemens thanks vivo for the proposed solutions for requirements tracking. For reasons similar to those laid out in SP-210228, Siemens favours vivo's proposals over other proposal made at this plenary meeting. Nokia clarifies the proposal is aligned with proposal in SP-210126, but we suggest to possibly amend the WID template to make it clear that, for stage 3 SID/WID, not only the Stage 2 parent SID/WID is needed but also the Stage 1 SID/WID, if available and if relevant. Siemens thanks Nokia for the provided explanation. Siemens asks Qualcomm for clarification of the delta of their proposal in SP-210126 in respect to existing procedure. Siemens uploaded revision one of the discussion paper SP-210228. | Noted |
20.1 | SP-210228 | DISCUSSION | Presentation | Assessment of proposals concerning the tracking of SA1 requirements in Stage-2 studies and work items | Siemens AG, Philips | Rel-17 | Noted | Siemens proposes to discuss SP-210126, SP-210227, and SP-210228 in the same email thread. Nokia provides comments on the proposal in SP-210126, based on examples of WIDs available at SA#91 as well as WIDs approved by CT#91. We suggest to use existing WID/SID template to keep track of parent stage 1 WIDs and make sure this is consistently used by WGs. We also suggest a possible amendment to WID/SID template to allow stage 3 downstream groups to reference both stage 2 parent WID and stage 1 parent WID, to ensure stage 1 parent WID is also listed in stage 3 WIDs. Samsung suggests that several objects in the proposal in SP-210227 can be met only by active participation: new procedures will not suffice. Samsung supports the initiative in SP-210126 to clearly state in WIDs where requirements are stated and notes that many requirements cross releases. Further work can be done to present the state of work by MCC. Siemens thanks Nokia for their proposal. Siemens also points out that an analysis of their approach yields the same result as for SP-210126 (for the analysis of the SP-210126 see SP-210228). Intel is of the opinion that the existing tools summarized in slides 6 and 7 of SP-210126 are sufficient for requirement tracking. Intel supports the proposal in SP-210126. Ericsson supports the proposal in SP-210126 as a reasonable and practical solution. Siemens asks for clarification of the difference between Nokia's proposal and the proposal in SP-210126. Siemens thanks vivo for the proposed solutions for requirements tracking. For reasons similar to those laid out in SP-210228, Siemens favours vivo's proposals over other proposal made at this plenary meeting. Nokia clarifies the proposal is aligned with proposal in SP-210126, but we suggest to possibly amend the WID template to make it clear that, for stage 3 SID/WID, not only the Stage 2 parent SID/WID is needed but also the Stage 1 SID/WID, if available and if relevant. Siemens thanks Nokia for the provided explanation. Siemens asks Qualcomm for clarification of the delta of their proposal in SP-210126 in respect to existing procedure. Siemens uploaded revision one of the discussion paper SP-210228. | Noted |
20.1 | SP-210229 | DISCUSSION | Endorsement | Enumeration of TS 22.104 and TS 22.261: a bird's eye perspective | Siemens, Daimler, Volkswagen AG, Novamint, BMWi, Philips, Sennheiser, ETRI, EBU, Bosch | Rel-17 | Revision of SP-201101. This was postponed. | Postponed | |
20.1 | SP-210230 | CR | Approval | 22.261 CR0493R1 (Rel-17, 'D'): Quality improvement - enumeration of requirements in TS 22.261 (Rel-17; this CR does not introduce any technical change) | Siemens, Daimler, Volkswagen AG, Novamint, BMWi, Philips, Sennheiser, ETRI, EBU, Bosch | Rel-17 | Revision of SP-201102. This CR was postponed. | Postponed | |
20.1 | SP-210231 | CR | Approval | 22.261 CR0494R1 (Rel-18, 'A'): Quality improvement - enumeration of requirements in TS 22.261 (Rel-18; this CR does not introduce any technical change) | Siemens, Daimler, Volkswagen AG, Novamint, BMWi, Philips, Sennheiser, ETRI, EBU, Bosch | Rel-18 | Revision of SP-201103. This CR was postponed. | Postponed | |
20.1 | SP-210232 | CR | Approval | 22.104 CR0061R1 (Rel-17, 'D'): Quality improvement - enumeration of requirements in TS 22.104 (Rel-17; this CR does not introduce any technical change) | Siemens, Daimler, Volkswagen AG, Novamint, BMWi, Philips, Sennheiser, ETRI, EBU, Bosch | Rel-17 | Revision of SP-201104. This CR was postponed. | Postponed | |
20.2 | - | - | - | E-Meeting Procedures (TSG SA, SA WGs) | - | - | Docs:=0 | - | |
20.3 | - | - | - | Review of the work plan | - | - | Docs:=1 | - | |
20.3 | SP-210252 | WORK PLAN | Presentation | Work Plan review at TSG#91E | Work Plan Coordinator (MCC) | ||||
20.4 | - | - | - | Specification Status | - | - | Docs:=0 | - | |
20.5 | - | - | - | Work Item Summaries for TR 21.91x | - | - | Docs:=0 | - | |
20.6 | - | - | - | Improvements to working methods and CRs against TSG SA owned Specifications | - | - | Docs:=3 | - | |
20.6 | SP-210046 | CR | Approval | 21.801 CR0057 (Rel-17, 'F'): Permitted software tools update | MCC Specifications manager | Rel-17 | This CR was approved | Approved | |
20.6 | SP-210047 | CR | Approval | 21.900 CR0065 (Rel-17, 'F'): Addition of xx.7xx number series for internal TRs | MCC Specifications manager | Rel-17 | This CR was approved | Approved | |
20.6 | SP-210048 | CR | Approval | 21.900 CR0066 (Rel-16, 'F'): Eliminate contents of Rel-16 and substitute with pointer to Rel-17 | MCC Specifications manager | Rel-16 | This CR was approved | Approved | |
20.7 | - | - | - | MCC Status Report | - | - | Docs:=1 | - | |
20.7 | SP-210235 | REPORT | Presentation | MCC Support Team report | MCC | ||||
20.8 | - | - | - | Future Meeting schedule | - | - | Docs:=0 | - | |
21 | - | - | - | Any Other Business | - | - | Docs:=0 | - | |
22 | - | - | - | Close of Meeting | - | - | Docs:=0 | - | |
99 | - | - | - | WITHDRAW ITEMS | - | - | Docs:=9 | - | |
99 | SP-210030 | LS In | Information | Reserved for incoming LS | MCC () | WITHDRAWN | Withdrawn | ||
99 | SP-210110 | CR PACK | Approval | Rel-17 CRs on TEI | SA WG3 | WITHDRAWN | Withdrawn | ||
99 | SP-210045 | DRAFT TR | Information | TR 26.803 on 5G Media Streaming Extensions for Edge Processing | Qualcomm Incorporated | Rel-17 | WITHDRAWN | Withdrawn | |
99 | SP-210148 | CR PACK | Approval | Rel-16 CRs on TEI Batch 3 | SA WG5 | WITHDRAWN | Withdrawn | ||
99 | SP-210058 | CR PACK | Approval | CRs to 23.501 (5G_URLLC, Rel-16) | SA WG2 | Incorrect content: Reissued SP-210242. WITHDRAWN | Withdrawn | ||
99 | SP-210059 | CR PACK | Approval | CRs to 23.501, 23.502, 23.503 (5GS_Ph1, Rel-16) | SA WG2 | Incorrect content: Reissued SP-210243. WITHDRAWN | Withdrawn | ||
99 | SP-210060 | CR PACK | Approval | CRs to 23.501, 23.502 (5WWC, Rel-16) | SA WG2 | Incorrect content: Reissued SP-210244. WITHDRAWN | Withdrawn | ||
99 | SP-210061 | CR PACK | Approval | CRs to 23.501, 23.502 (ATSSS, Rel-16) | SA WG2 | Incorrect content: Reissued SP-210245. WITHDRAWN | Withdrawn | ||
99 | SP-210062 | CR PACK | Approval | CRs to 23.288 (eNA, Rel-16) | SA WG2 | Incorrect content: Reissued SP-210246. WITHDRAWN | Withdrawn |