Tdoc List
2023-11-10 15:02
Agenda | Topic | TDoc | Title | Source | Type | For | Avail | Treated | Decision | Wdrn | Replaced-by | Replaces |
---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Agenda and Meeting Objectives | S3‑234400 | Agenda | SA WG3 Chair | agenda | Yes |
Yes
| approved | No | |||
S3‑234402 | Process for SA3#113 | SA WG3 Chair | other | Yes |
Yes
| noted | No | |||||
S3‑234403 | Detail agenda planning for SA3#113 | SA WG3 Chair | other | Yes |
Yes
| revised | No | S3‑234985 | ||||
S3‑234985 | Detail agenda planning for SA3#113 | SA WG3 Chair | other | - | No |
No
| reserved | No | S3‑234403 | |||
2 | Meeting Reports | S3‑234401 | Report from SA3#112 | MCC | report | Yes |
Yes
| revised | No | S3‑234986 | ||
S3‑234986 | Report from SA3#112 | MCC | report | - | Yes |
YesIncorporating comments from Qualcomm.
| approved | No | S3‑234401 | |||
S3‑234405 | Report to SA3 from SA | SA WG3 Chair | report | Yes |
Yes
| noted | No | |||||
3 | Reports and Liaisons from other Groups | S3‑234978 | SAGE-23-02 Resynchronisation protection f5** for MILENAGE-128 and Tuak. | ETSI SAGE | LS in | Yes |
YesIt was queried whether this should be incorporated in a new specification or be part of an existing specification. This needed some moe time to be analised.
| postponed | No | |||
S3‑234471 | Reply LS on security for selective SCG activation | R2-2309268 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234979 | Reply LS on security for selective SCG activation | R2-2311618 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234437 | Reply LS on Security Solution for Selective SCG | Nokia, Nokia Shanghai Bell | LS out | Yes |
Yes
| revised | No | S3‑235051 | ||||
S3‑235051 | Reply LS on Security Solution for Selective SCG | Nokia, Nokia Shanghai Bell | LS out | - | Yes |
Yes
| approved | No | S3‑234437 | |||
S3‑234647 | Draft LS reply on security for selective SCG activation | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234649 | Update on the procedures of Security of Selective SCG Activation | Huawei, HiSilicon | other | Approval | Yes |
Yes
| noted | No | ||||
S3‑234441 | LS reply to S3-233786 and S3-234296 on the introduction of the domain ""ipxnetwork.org"" and clarifications of the Outsourced SEPP and Hosted SEPP deployment scenarios | GSMA | LS in | Yes |
Yes
| postponed | No | |||||
S3‑234693 | LS reply on SCPAC security | OPPO | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234442 | N32-f Lifetime and Reconnection | GSMA | LS in | Yes |
Yes
| noted | No | |||||
S3‑234443 | N32-f N32-c correlation | GSMA | LS in | Yes |
Yes
| noted | No | |||||
S3‑234444 | LS on Educational paper on N32 connection establishment for bilateral TLS | GSMA | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234861 | DP on Educational Paper N32 connection establishment for bilateral TLS | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| revised | No | S3‑235112 | |||
S3‑235112 | DP on Educational Paper N32 connection establishment for bilateral TLS | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | S3‑234861 | |||
S3‑234862 | LS-Reply on N32 connection establishment for bilateral TLS | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| revised | No | S3‑235068 | |||
S3‑235068 | LS-Reply on N32 connection establishment for bilateral TLS | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑234862 | |||
S3‑234445 | LS on Handling of SOR counter and the UE parameter update counter if stored in NVM | C1-232696 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234656 | Draft reply LS on NVM issue | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| merged | No | S3‑235053 | |||
S3‑234658 | Agenda and notes of conference call on the storage of UPU and SoR counters in NVM | Huawei, HiSilicon | other | Information | Yes |
Yes
| noted | No | ||||
S3‑234670 | Reply LS on Handling of SOR counter and the UE parameter update counter if stored in NVM | Apple | LS out | Approval | Yes |
Yes
| revised | No | S3‑235053 | |||
S3‑235053 | Reply LS on Handling of SOR counter and the UE parameter update counter if stored in NVM | Apple | LS out | Approval | Yes |
Yes
| approved | No | S3‑234670 | |||
S3‑234682 | Handling of SoR counter and UE parameter update counter in NVM | THALES | discussion | Approval | Yes |
Yes
| noted | No | ||||
S3‑234837 | Discussion paper on handling of SOR and UPU counter if stored in NVM | Samsung | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234446 | Reply LS on UPU enhancement | C1-235532 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234447 | Reply LS on Mitigation of Downgrade attacks | C1-236517 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234878 | LS reply for Reply LS on Mitigation of Downgrade attacks | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
YesEricsson: legacy equipment turned off so the network no longer offers 2G/3G service, it’s actually better this way.
| revised | No | S3‑234991 | |||
S3‑234906 | [Draft] Reply LS on supporting resource owner-aware northbound API access | Xiaomi communications | LS out | Approval | Yes |
Yes
| merged | No | S3‑235003 | |||
S3‑234991 | LS reply for Reply LS on Mitigation of Downgrade attacks | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑234878 | |||
S3‑234448 | LS on providing a new 5G-GUTI in the REGISTRATION REJECT message to the UE | C1-236521 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑235071 | Reply to: LS on providing a new 5G-GUTI in the REGISTRATION REJECT message to the UE | Nokia | LS out | approval | No |
Yes
| approved | No | ||||
S3‑234483 | LS on providing a new 5G-GUTI in the REGISTRATION REJECT message to the UE | S2-2311800 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234535 | Reply LS on providing a new 5G-GUTI in the REGISTRATION REJECT message to the UE | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234453 | LS on Retrieving keys for decryption of protected IEs for U2N relay | C1-234362 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234520 | Reply LS on Retrieving keys for decryption of protected IEs for U2N relay | InterDigital Finland Oy | LS out | Approval | Yes |
Yes
| merged | No | S3‑235098 | |||
S3‑234712 | Draft Reply LS on Retrieving keys for decryption of protected IEs for U2N relay | Qualcomm Incorporated | LS out | Approval | Yes |
Yes
| merged | No | S3‑235098 | |||
S3‑234729 | LS reply on LS on Retrieving keys for decryption of protected IEs for U2N relay | Ericsson | LS out | Approval | Yes |
Yes
| merged | No | S3‑235098 | |||
S3‑234904 | Reply LS on Retrieving keys for decryption of protected IEs for U2N relay | Beijing Xiaomi Mobile Software | LS out | Approval | Yes |
YesInterdigital: there are other proposals on the table. This solution opens up to attacks and is not efficient at all.
| revised | No | S3‑235098 | |||
S3‑235098 | Reply LS on Retrieving keys for decryption of protected IEs for U2N relay | Beijing Xiaomi Mobile Software | LS out | Approval | Yes |
Yes
| approved | No | S3‑234904 | |||
S3‑234454 | LS on security for 5G ProSe UE-to-network relay discovery | C1-237900 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234692 | LS reply on security for 5G ProSe UE-to-network relay discovery | OPPO | LS out | Approval | Yes |
Yes
| revised | No | S3‑234992 | |||
S3‑234992 | LS reply on security for 5G ProSe UE-to-network relay discovery | OPPO | LS out | Approval | Yes |
Yes
| approved | No | S3‑234692 | |||
S3‑234905 | Reply LS on Security for 5G ProSe UE-to-Network Relay Discovery | Beijing Xiaomi Mobile Software | LS out | Approval | Yes |
Yes
| merged | No | S3‑234992 | |||
S3‑234455 | LS on key and security materials used for Ranging_SL | C1-237928 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234760 | LS reply on key and security materials used for Ranging_SL | OPPO | LS out | Approval | Yes |
Yes
| merged | No | S3‑235075 | |||
S3‑234883 | [Draft] Reply LS on key and security materials used for Ranging_SL | Xiaomi Technology | LS out | Approval | Yes |
Yes
| revised | No | S3‑235075 | |||
S3‑235075 | [Draft] Reply LS on key and security materials used for Ranging_SL | Xiaomi Technology | LS out | Approval | Yes |
Yes
| approved | No | S3‑234883 | |||
S3‑234456 | LS on supporting resource owner-aware northbound API access | C3-234640 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234613 | LS-reply to CT3 on SNAAPPY | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| revised | No | S3‑235003 | |||
S3‑235003 | LS-reply to CT3 on SNAAPPY | Huawei, HiSilicon | LS out | Approval | No |
Yes
| approved | No | S3‑234613 | |||
S3‑234457 | LS on AKMA service restrictions in Rel-17 | C3-232563 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑234988 | Reply to: LS on AKMA service restrictions in Rel-17 | Nokia | LS out | approval | No |
Yes
| withdrawn | Yes | ||||
S3‑234531 | LS reply on AKMA service restrictions in Rel-17 | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234748 | [draft] LS on Draft Reply LS on AKMA service restrictions | China Mobile | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234840 | Reply LS on AKMA service restrictions in Rel-17 | NDRE, NTAC, PIDS, Security Service | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234458 | IETF HTTP RFCs obsoleted by RFCs 9110, 9111 and 9113 | C4-233513 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234659 | HTTP RFC obsoleted by IETF RFC 9110 | Huawei, HiSilicon | CR | Agreement | Yes |
YesIt was commented that there may be remaining specifications that are impacted by this. Companies were requested to check it out for the next meeting cycle.
It was asked if it was appropriate to replace the reference like this instead of voiding, but Nokia replied that this is the way CT4 had done it.
| agreed | No | ||||
S3‑234660 | HTTP RFC obsoleted by IETF RFC 9113 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234661 | HTTP RFCs obsoleted by IETF RFC 9110 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234662 | HTTP RFC obsoleted by IETF RFC 9113 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234459 | Reply LS on Authorization of NF service consumers for data access via DCCF | C4-233596 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234792 | Discussion on the authentication result removal operation | Ericsson | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234462 | LS on Authentication Result Removal | C4-224418 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234793 | Reply LS on Authentication Result Removal | Ericsson | LS out | Approval | Yes |
Yes
| revised | No | S3‑235099 | |||
S3‑235099 | Reply LS on Authentication Result Removal | Ericsson | LS out | Approval | Yes |
Yes
| approved | No | S3‑234793 | |||
S3‑234463 | LS on Removal of the uavAuthenticated IE from Create SM Context Request | C4-230790 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑234937 | Response LS to C4-230790 | Lenovo | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234478 | Reply LS on Clarification on Removal of the Indicator of UUAA result from AMF | S2-2309697 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑234610 | reply to CT4 on removal of uavAuthenticated IE | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234745 | [draft] Reply LS for C4-230790 on Removal of the uavAuthenticated IE from Create SM Context Request_LS | China Mobile | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234468 | LS on a Framework for Network Slices in Networks Built from IETF Technologies Submission | IETF | LS in | Yes |
Yes
| noted | No | |||||
S3‑234469 | LS on user consent for SON/MDT for NB-IoT UEs | R2-2309030 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234851 | LS reply for LS on user consent for SON/MDT for NB-IoT UEs | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| revised | No | S3‑235004 | |||
S3‑235004 | LS reply for LS on user consent for SON/MDT for NB-IoT UEs | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑234851 | |||
S3‑234473 | LS on Reporting of Relay UE C-RNTI and NCGI | R2- 2306693 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234836 | Draft_LS reply for R2- 2306693 on Reporting of Relay UE C-RNTI and NCGI | Samsung | LS out | Approval | Yes |
Yes
| merged | No | S3‑235005 | |||
S3‑234646 | Draft LS reply on Reporting of Relay UE C-RNTI and NCGI | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| revised | No | S3‑235005 | |||
S3‑235005 | Draft LS reply on Reporting of Relay UE C-RNTI and NCGI | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| approved | No | S3‑234646 | |||
S3‑234683 | LS reply on Reporting of Relay UE C-RNTI and NCGI | OPPO | LS out | Approval | Yes |
Yes
| merged | No | S3‑235005 | |||
S3‑234903 | Reply LS on Reporting of Relay UE C-RNTI and NCGI | Beijing Xiaomi Mobile Software | LS out | Approval | Yes |
Yes
| merged | No | S3‑235005 | |||
S3‑234476 | LS on Roaming Hub Requirements | S1-232654 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234500 | Reply LS on Roaming Hubs | SP-231203 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234866 | LS on PRINS security profiling | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
YesHuawei preferred to prepare a CR for the next meetng.
| revised | No | S3‑235067 | |||
S3‑235067 | LS on PRINS security profiling | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑234866 | |||
S3‑234461 | LS on modifications for PRINS middle box | C4-234666 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234477 | DNS over TLS (DoT) and DNS over HTTPS (DoH) | S2-2306210 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234780 | [Draft] Reply LS on DNS over TLS (DoT) and DNS over HTTPS (DoH) | Ericsson | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234948 | Reply LS on DNS over TLS (DoT) and DNS over HTTPS (DoH) | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
YesHuawei,Samsung and Qualcommsupported this approach.
| revised | No | S3‑235073 | |||
S3‑235073 | Reply LS on DNS over TLS (DoT) and DNS over HTTPS (DoH) | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑234948 | |||
S3‑234479 | Clarification related to reliable location | S2-2309698 | LS in | Yes |
Yes
| postponed | No | |||||
S3‑234547 | Reply LS on Clarification related to reliable location | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
YesNokia commented that there were new solutions proposed in SA2 for Rel-17. They proposed to just to refer to what is written currently in the SA3 specificaitons.
OPPO: we don’t agree with any UE-based solution.
| noted | No | ||||
S3‑234628 | Reply LS on Clarification related to reliable location | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234480 | Reply LS on LS on UE Ranging/SL Positioning privacy profile | S2-2309830 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234778 | [Draft] Reply LS on Clarification related to reliable location | Ericsson | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234813 | 3 - Reply LS on UE Ranging SL Positioning privacy profile | Philips International B.V. | LS out | Agreement | Yes |
Yes
| noted | No | ||||
S3‑234481 | Reply LS on Reply LS on security aspects for Ranging/Sidelink Positioning | S2-2310025 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234636 | Reply LS on security aspects for Ranging/Sidelink Positioning | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| merged | No | S3‑235078 | |||
S3‑234812 | 3 - Reply LS on security aspects for Ranging Sidelink Positioning | Philips International B.V. | LS out | Agreement | Yes |
Yes
| merged | No | S3‑235078 | |||
S3‑234894 | [Draft] Reply LS on security aspects for Ranging/Sidelink Positioning | Xiaomi Technology | LS out | Approval | Yes |
Yes
| revised | No | S3‑235078 | |||
S3‑235078 | Reply LS on security aspects for Ranging/Sidelink Positioning | Xiaomi Technology | LS out | Approval | Yes |
Yes
| approved | No | S3‑234894 | |||
S3‑234485 | Reply LS on NSWO support in SNPN using CH AAA server | S2-2311815 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234486 | LS on MSISDN exposure to trusted AF | S2-2311893 | LS in | Yes |
YesIt was decided to wait for GSMA's reply before acting on this.
| postponed | No | |||||
S3‑234771 | Reply LS on MSISDN exposure to trusted AF | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234783 | [Draft] Reply LS on LS on MSISDN exposure to trusted AF | Ericsson | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234488 | Non-Support of Ciphering Algorithm GEA2 | GCF | LS in | Yes |
Yes
| postponed | No | |||||
S3‑234962 | Prohibiting GEA1 and GEA2 in devices (Response to LS in S3-234488) | VODAFONE | discussion | Agreement | Yes |
Yes
| revised | No | S3‑234975 | |||
S3‑234963 | Prohibition of GEA1 and GEA2 due to security concerns | Vodafone | CR | Yes |
Yes
| revised | No | S3‑234993 | ||||
S3‑234993 | Prohibition of GEA1 and GEA2 due to security concerns | Vodafone | CR | - | Yes |
Yes
| agreed | No | S3‑234963 | |||
S3‑234964 | Prohibition of GEA1 and GEA2 due to security concerns | VODAFONE | CR | Approval | Yes |
Yes
| revised | No | S3‑234994 | |||
S3‑234994 | Prohibition of GEA1 and GEA2 due to security concerns | VODAFONE | CR | Approval | Yes |
Yes
| agreed | No | S3‑234964 | |||
S3‑234965 | Prohibition of GEA1 and GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| revised | No | S3‑234995 | |||
S3‑234995 | Prohibition of GEA1 and GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| agreed | No | S3‑234965 | |||
S3‑234966 | Prohibition of GEA1 and GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| revised | No | S3‑234996 | |||
S3‑234996 | Prohibition of GEA1 and GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| agreed | No | S3‑234966 | |||
S3‑234967 | Prohibition of GEA1 and GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| revised | No | S3‑234997 | |||
S3‑234997 | Prohibition of GEA1 and GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| agreed | No | S3‑234967 | |||
S3‑234969 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| revised | No | S3‑234998 | |||
S3‑234998 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| agreed | No | S3‑234969 | |||
S3‑234970 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| revised | No | S3‑234999 | |||
S3‑234999 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| agreed | No | S3‑234970 | |||
S3‑234971 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| revised | No | S3‑235000 | |||
S3‑235000 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| agreed | No | S3‑234971 | |||
S3‑234972 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| revised | No | S3‑235001 | |||
S3‑235001 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| agreed | No | S3‑234972 | |||
S3‑234974 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| revised | No | S3‑235002 | S3‑234968 | ||
S3‑234975 | Prohibiting GEA1 and GEA2 in devices (Response to LS in S3-234488) | VODAFONE | discussion | Agreement | Yes |
YesGSMA: it is sensible to do this, but we can't force manufacturers to implement specific versions of the specifications. Maybe this can be tied to handset testing work done in GSMA instead.
Ericsson: 21st December 2023 too early?
Qualcomm: by the time these CRs are implemented we already have passed this date.
Apple: we don’t mention dates
MCC agreed that there was no need to put any dates. The prohibition would apply as the specifications were published.
GSMA: consequences if not approved need to be better justified on the cover pages.
MCC commented that Rel-6 and Rel-7 were closed and making CRs for these releases was against 3GPP Working procedures. MCC also commented that the use of the word "prohibited" was more appropriate for regulators but not for standards. Wording such as "shall not be supported" would have been more appropriate. Since the word "prohibited" had been in the spec since very early releases MCC conceded to leave it as it is.
It was decided to agree on the CRs but MCC warned that SA would have to decide on the Rel-6 and Rel-7 issue.
| noted | No | S3‑234962 | |||
S3‑235002 | Prohibition of GEA2 due to security concerns | Vodafone | CR | Approval | Yes |
Yes
| agreed | No | S3‑234974 | |||
S3‑234489 | LS on LI for AKMA in roaming | s3i230421 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234987 | Reply to: LS on LI for AKMA in roaming | Nokia | LS out | approval | No |
Yes
| approved | No | ||||
S3‑234749 | Rely LS on LI for AKMA in roaming | China Mobile | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234846 | Response LS on LI for AKMA in roaming | NDRE, NTAC, PIDS, Security Service | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234493 | Security for AI ML management capabilities | S5-234776 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234849 | LS reply for Security for AI ML management capabilities | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| revised | No | S3‑235101 | |||
S3‑235101 | LS reply for Security for AI ML management capabilities | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑234849 | |||
S3‑234495 | LS on developing a security solution for PINAPP architecture | S6-233112 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234564 | DRAFT LS Reply on developing a security solution for PINAPP architecture | InterDigital Communications | LS out | Approval | Yes |
Yes
| revised | No | S3‑235074 | |||
S3‑235074 | LS Reply on developing a security solution for PINAPP architecture | InterDigital Communications | LS out | Approval | Yes |
Yes
| approved | No | S3‑234564 | |||
S3‑234565 | Discussion Paper on PINAPP Security Approach | InterDigital Communications | discussion | Endorsement | Yes |
YesHuawei: TLS is enough.
Mike (T-Mobile): CT groups don’t know what to do, that is the issue here.
| noted | No | ||||
S3‑234496 | LS to SA, SA3 and SA5 on potential collaboration between 3GPP SA3/SA5 and ETSI SAI ISG | ETSI ISG SAI | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234751 | Reply LS on potential collaboration between 3GPP SA3/SA5 and ETSI SAI ISG | China Mobile | LS out | Approval | Yes |
Yes
| merged | No | S3‑235007 | |||
S3‑234506 | DRAFT Reply LS on potential collaboration between 3GPP SA3 and ETSI | InterDigital Communications | LS out | Approval | Yes |
Yes
| revised | No | S3‑235007 | |||
S3‑235007 | Reply LS on potential collaboration between 3GPP SA3 and ETSI | InterDigital Communications | LS out | Approval | Yes |
Yes
| approved | No | S3‑234506 | |||
S3‑234497 | LS on the proposal for a new work item: Guidelines for increasing security of the AKA protocols in IMT-2020 and beyond | ITU-T | LS in | Yes |
YesGSMA: we need to respond before next ITU-SG17's meeting, otherwise it will be too late as they impact on GSMA and 3GPP's work (modified AKA protocol and countries implementing it causing a possible market fragmentation).
| replied to | No | |||||
S3‑235006 | Reply to: LS on the proposal for a new work item: Guidelines for increasing security of the AKA protocols in IMT-2020 and beyond | Huawei | LS out | approval | Yes |
Yes
| approved | No | ||||
S3‑234498 | LS on work progress on X.1818 (ex. X.5Gsec-ctrl) “Security controls for operation and maintenance of IMT-2020/5G network systems” | ITU-T | LS in | Yes |
Yes
| noted | No | |||||
S3‑234499 | LSOut Reply to 3GPP Reply LS on Authenticated Vulnerability Testing | ETSI ISG NFV | LS in | Yes |
Yes
| replied to | No | |||||
S3‑235008 | Reply to: LSOut Reply to 3GPP Reply LS on Authenticated Vulnerability Testing | Nokia | LS out | approval | Yes |
Yes
| approved | No | ||||
S3‑234507 | TCG progress - report from TCG rapporteur | InterDigital Communications | other | Information | Yes |
Yes1. TCG – Highlights
Publication of new or revised deliverables (incremental changes from the status reported at SA3#112)
• TCG Storage Component Class Registry v1.0 – public review September 2023
• TCG Registry of Reserved TPM 2.0 Handles & Localities v1.2 – public review September 2023
• TCG Storage Opal Family Feature Set: Datastore Tables v1.01 – public review August 2023
• TCG DICE Concise Evidence Binding for SPDM v 1.0 – public review August 2023
• TCG DICE Attestation Architecture v1.1 – public review August 2023
• TCG PC Client Platform Firmware Profile v1.06 – public review July 2023
• TCG Mobile Reference Architecture v2.0 – publication approved by TC July 2023
• TCG CPU to TPM Bus Protection for Passive Attacks v1.0 – public review July 2023
• TCG Storage App Note: Encrypting Drives with Key Per I/O SSC – public review July 2023
2. Meetings
• TCG Members Meeting Hybrid F2F (Tokyo, Japan) – 27-29 February 2024
• TCG Members Meeting Hybrid F2F (TBD Location) – June 2024
• MP WG meets every Monday at 10-11 ET
• TMS WG meets every Monday and Friday at 12-13 ET
CyRes WG meets every Wednesday at 11-12:30 ET
| noted | No | ||||
S3‑234467 | LS to 3GPP re Monitoring of Encrypted 5GS Signalling Traffic | GSMA | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234875 | Reply LS on Monitoring of Encrypted 5GS Signalling Traffic | Ericsson | LS out | Yes |
YesNokia: not an interoperability topic for 3GPP. It’s between the operator and hhoever is providing the product.
| revised | No | S3‑235009 | ||||
S3‑235009 | Reply LS on Monitoring of Encrypted 5GS Signalling Traffic | Ericsson | LS out | - | Yes |
Yes
| approved | No | S3‑234875 | |||
S3‑234475 | LS on QMC support in RRC_IDLE and RRC_INACTIVE | R3-234745 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234472 | Reply LS on QMC support in RRC_IDLE and RRC_INACTIVE | R2-2311409 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234852 | LS reply for LS on QMC support in RRC_IDLE and RRC_INACTIVE | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| revised | No | S3‑235102 | |||
S3‑235102 | LS reply for LS on QMC support in RRC_IDLE and RRC_INACTIVE | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| approved | No | S3‑234852 | |||
S3‑234482 | Reply LS on procedures for UE discovery for Ranging_SL | S2-2311767 | LS in | Yes |
Yes
| replied to | No | |||||
S3‑234716 | Draft Reply LS on procedures for UE discovery for Ranging_SL | Qualcomm Incorporated | LS out | Approval | Yes |
Yes
| merged | No | S3‑235075 | |||
S3‑234490 | Reply LS on Security Context Transfer between MBSF and MBSTF | S4-231485 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234440 | N32 Race conditions and recovery | GSMA | LS in | Yes |
Yes
| noted | No | |||||
S3‑234980 | Reply LS on N32 Race conditions and recovery | C4-234663 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234449 | LS on procedures for UE discovery for Ranging_SL | C1-236527 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234450 | LS on LPP message and supplementary service event report over a user plane connection between UE and LMF | C1-236562 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234451 | LS on Trigger for secure user plane establishment via user plane | C1-237891 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234452 | LS on 5G ProSe UE-to-UE relay discovery with security aspects | C1-237897 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234470 | Reply LS to SA2 on Sidelink positioning procedure | R2-2309119 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234474 | Reply LS on DTLS for SCTP next steps and request for input | R3-234497 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234484 | LS on the progress of 5WWC_Ph2 normative work | S2-2311801 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234491 | Reply to LS on 3GPP work on energy efficiency | S5-235778 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234492 | Reply LS on user consent of Non-public Network | S5-236928 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234494 | LS reply on Support of multiple UEs in Northbound APIs | S6-233104 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234487 | Reply LS on ProSe Secondary Authentication | S2-2307743 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234976 | LS to include Source and Destination Interface Type for Indirect DL Data Forwarding Tunnel related N4 requests | s3i230618 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234977 | LS on NAS Cause Value - Unspecified | s3i230621 | LS in | Yes |
Yes
| noted | No | |||||
S3‑234460 | Reply LS on N32 Race conditions and recovery | C4-234663 | LS in | Yes |
Yes
| withdrawn | Yes | |||||
S3‑234940 | Discussion on UUAA Determination | Lenovo | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234968 | Prohibition of GEA1 and GEA2 due to security concerns | VODAFONE | CR | Approval | Yes |
Yes
| revised | No | S3‑234974 | |||
S3‑234989 | Elaborated LS reply to S3-234350 on Roaming Hub requirements as applicable to the Modified PRINS solution | GSMA | LS in | discussion | Yes |
Yes
| postponed | No | ||||
S3‑234990 | Elaborated LS reply to S3-234350 on IPX Service Hub requirements as applicable to the Modified PRINS solution | GSMA | LS in | discussion | Yes |
Yes
| postponed | No | ||||
4 | Work areas |   | ||||||||||
4.1 | Maintenance (Rel-15/16/17/18) |   | ||||||||||
4.1.1 | Security Assurance | S3‑234407 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| revised | No | S3‑234408 | |
S3‑234408 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| withdrawn | Yes | S3‑234407 | |||
S3‑234409 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| withdrawn | Yes | ||||
S3‑234410 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| withdrawn | Yes | ||||
S3‑234411 | Clarification on SCAS Modal Text | T-Mobile USA Inc., Deutsche Telekom, ZTE Corporation, BSI, Nokia, Ericson, Huawei, Telus, MITRE Corporation | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑234412 | Clarification on SCAS Definitions and abbreviations | T-Mobile USA Inc.T-Mobile US, Deutsche Telekom, ZTE Corporation, BSI, Nokia, Ericson, Huawei, Telus, MITRE Corporation | CR | Approval | Yes |
Yes
| revised | No | S3‑235108 | |||
S3‑235108 | Clarification on SCAS Definitions and abbreviations | T-Mobile USA Inc.T-Mobile US, Deutsche Telekom, ZTE Corporation, BSI, Nokia, Ericson, Huawei, Telus, MITRE Corporation | CR | Approval | Yes |
Yes
| agreed | No | S3‑234412 | |||
S3‑234413 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| revised | No | S3‑234982 | |||
S3‑234982 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| agreed | No | S3‑234413 | |||
S3‑234414 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| revised | No | S3‑234983 | |||
S3‑234983 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| agreed | No | S3‑234414 | |||
S3‑234415 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| revised | No | S3‑234984 | |||
S3‑234984 | To replace RRC connection reconfiguration by RRC reconfiguration | ISSDU | CR | Approval | Yes |
Yes
| agreed | No | S3‑234415 | |||
S3‑234423 | Clarification of Test Cases in TS 33.117 | Deutsche Telekom AG, T-Mobile US, Telecom Italia Mobile, Telus,China Mobile,Ericsson, Huawei, Nokia, ZTE, BSI (Germany), MITRE Corporation | discussion | Decision | Yes |
YesEricsson clarified that this showed the changes in TS 33.117 that needed to be brought in future meetings.
GSMA asked to endorse this document and ask formally SA3 companies to resolve these issues by bringing CRs for the next meeting cycle if possible.
The Chair suggested to find volunteers to make that the job was done in time.
| endorsed | No | ||||
S3‑234435 | Basic Editorial Updates to TS 33.117 | ZTE Corporation, Deutsche Telekom, T-Mobile USA, BSI, Huawei, Nokia, Ericsson, Telus, MITRE Corporation | CR | Approval | Yes |
YesEricsson: in the threat references it is not mentioned what threat we are talking about, we are just putting the whole document TR 33.926.The clause should be added as well. About the requirement reference, it should be added some reference instead of something like "industry best practice".
GSMA: accept these changes, but we need to be more precise or we will get issues with the labs.
| agreed | No | ||||
S3‑234436 | Inconsistent use of terms | Nokia, Nokia Shanghai Bell | draftCR | Yes |
YesNokia commented that these changes came from the NESAS group.
MCC commented that this needed to be converted into a CR.
| approved | No | |||||
S3‑235049 | Inconsistent use of terms | Nokia, Nokia Shanghai Bell, Deutsche Telekom, T-mobile, ZTE, Ericsson, BSI, Huawei, TELUS, MITRE Corporation | CR | - | Yes |
Yes
| agreed | No | ||||
S3‑234438 | Specification mismatch is leading to inconsistent certification result | Nokia, Nokia Shanghai Bell | discussion | Yes |
Yes
| noted | No | |||||
S3‑234439 | Disclaimer for Indirect Communication | Nokia, Nokia Shanghai Bell | CR | Yes |
Yes
| revised | No | S3‑235050 | ||||
S3‑235050 | Disclaimer for Indirect Communication | Nokia, Nokia Shanghai Bell | CR | - | Yes |
Yes
| agreed | No | S3‑234439 | |||
S3‑234738 | Clarification EMS interface | China Mobile | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234739 | Correction for VNF package and VNF image integrity of clause 4.2.3.3.5.2 | China Mobile | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234842 | Correction of protocol in Expected format of evidence | BSI (DE) | CR | Approval | No |
Yes
| revised | No | S3‑234950 | |||
S3‑234844 | Added missing Test Name and Expected format of evidence | BSI (DE) | CR | Approval | No |
Yes
| revised | No | S3‑234952 | |||
S3‑234845 | Correction of IE and protocol | BSI (DE) | CR | No |
Yes
| revised | No | S3‑234951 | ||||
S3‑234847 | Added UDM threat reference for use of an invalid and uncompressed point in ECIES protection scheme for SUCI decryption | BSI (DE) | CR | Approval | No |
Yes
| revised | No | S3‑234953 | |||
S3‑234848 | Added UDM SCAS test cases for checking an invalid and uncompressed point in ECIES protection scheme for SUCI decryption | BSI (DE) | CR | Approval | No |
Yes
| revised | No | S3‑234954 | |||
S3‑234929 | Add UDM SCAS test case for checking the authentication verification of a synchronization failure message | BSI (DE) | CR | Approval | No |
Yes
| revised | No | S3‑234955 | |||
S3‑234930 | Add UDM threat reference for missing verification of synchronization failure messages. | BSI (DE) | CR | Agreement | No |
Yes
| revised | No | S3‑234956 | |||
S3‑234950 | Correction of protocol in Expected format of evidence | BSI (DE) | CR | Approval | Yes |
Yes
| agreed | No | S3‑234842 | |||
S3‑234951 | Correction of IE and protocol | BSI (DE) | CR | Yes |
Yes
| agreed | No | S3‑234845 | ||||
S3‑234952 | Added missing Test Name and Expected format of evidence | BSI (DE) | CR | Approval | Yes |
Yes
| agreed | No | S3‑234844 | |||
S3‑234953 | Added UDM threat reference for use of an invalid and uncompressed point in ECIES protection scheme for SUCI decryption | BSI (DE) | CR | Approval | Yes |
Yes
| agreed | No | S3‑234847 | |||
S3‑234954 | Added UDM SCAS test cases for checking an invalid and uncompressed point in ECIES protection scheme for SUCI decryption | BSI (DE) | CR | Approval | Yes |
Yes
| revised | No | S3‑235043 | S3‑234848 | ||
S3‑235043 | Added UDM SCAS test cases for checking an invalid and uncompressed point in ECIES protection scheme for SUCI decryption | BSI (DE) | CR | Approval | Yes |
Yes
| agreed | No | S3‑234954 | |||
S3‑234955 | Add UDM SCAS test case for checking the authentication verification of a synchronization failure message | BSI (DE) | CR | Approval | Yes |
Yes
| not pursued | No | S3‑234929 | |||
S3‑234956 | Add UDM threat reference for missing verification of synchronization failure messages. | BSI (DE) | CR | Approval | Yes |
Yes
| not pursued | No | S3‑234930 | |||
4.1.2 | Service Based Architecture | S3‑234718 | Use "visited PLMN" in the roaming description | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||
S3‑234719 | Use "visited PLMN" in the roaming description | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234720 | Validation of the parameters in the access token request in hierarchial NRF deployment | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234721 | Validation of the parameters in the access token request in roaming scenarios | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234722 | Validation of the parameters in the access token request in interconnect scenarios | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234723 | Use "visited PLMN" in the roaming description | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234917 | Correcting the UUID example in SBA certificates | Ericsson | CR | Yes |
Yes
| withdrawn | Yes | |||||
S3‑234918 | Non-critical X.509 subjectAltName and unique DN following RFC 5280 | Ericsson | CR | Yes |
Yes
| withdrawn | Yes | |||||
S3‑234919 | Correcting the UUID example in SBA certificates | Ericsson | CR | Yes |
Yes
| withdrawn | Yes | |||||
S3‑234921 | Non-critical X.509 subjectAltName and unique DN following RFC 5280 | Ericsson | CR | Yes |
Yes
| withdrawn | Yes | |||||
S3‑234922 | Correcting the UUID example in SBA certificates | Ericsson | CR | Yes |
Yes
| withdrawn | Yes | |||||
S3‑234924 | Non-critical X.509 subjectAltName and unique DN following RFC 5280 | Ericsson | CR | Yes |
Yes
| withdrawn | Yes | |||||
S3‑234928 | Correcting the UUID example in SBA certificates | Ericsson | CR | Yes |
Yes
| agreed | No | |||||
S3‑234931 | Correcting the UUID example in SBA certificates | Ericsson | CR | Yes |
Yes
| agreed | No | |||||
S3‑234935 | Correcting the UUID example in SBA certificates | Ericsson | CR | Yes |
Yes
| agreed | No | |||||
S3‑234943 | Non-critical X.509 subjectAltName and unique DN following RFC 5280 | Ericsson | CR | Yes |
Yes
| not pursued | No | |||||
S3‑234947 | Non-critical X.509 subjectAltName and unique DN following RFC 5280 | Ericsson | CR | Yes |
Yes
| not pursued | No | |||||
4.1.3 | Security Aspects of Proximity based services in 5GS ProSe | S3‑234511 | Key identification for decryption of protected IEs for UE-to-Network Relay | Philips International B.V. | CR | Approval | Yes |
Yes
| not pursued | No | ||
S3‑234521 | Retrieving keys for decryption of protected IEs in DCR for U2N relay | Interdigital | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234522 | Retrieving keys for decryption of protected IEs in DCR for U2N relay | Interdigital | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234728 | Retrieving keys for decryption of protected IEs for U2N relay | Ericsson, Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234732 | Retrieving keys for decryption of protected IEs for U2N relay | Ericsson, Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234698 | CR to TS33.503 Clarification on the use of 5GPKMF service operations Release 17 | CATT | CR | Approval | Yes |
Yes
| revised | No | S3‑235054 | |||
S3‑235054 | CR to TS33.503 Clarification on the use of 5GPKMF service operations Release 17 | CATT | CR | Approval | Yes |
Yes
| agreed | No | S3‑234698 | |||
S3‑234699 | CR to TS33.503 Clarification on the use of 5GPKMF service operations Release 18 (mirror) | CATT | CR | Approval | Yes |
Yes
| revised | No | S3‑235055 | |||
S3‑235055 | CR to TS33.503 Clarification on the use of 5GPKMF service operations Release 18 (mirror) | CATT | CR | Approval | Yes |
Yes
| agreed | No | S3‑234699 | |||
S3‑234509 | Security of 5G ProSe PC5 Communication – clarification | Philips International B.V. | CR | Approval | Yes |
YesEricsson, Qualcomm: the new sentence is not needed.
| revised | No | S3‑235066 | |||
S3‑235066 | Security of 5G ProSe PC5 Communication – clarification | Philips International B.V. | CR | Approval | Yes |
Yes
| agreed | No | S3‑234509 | |||
S3‑234700 | CR to TS33.503 Correction U2U Relay Communication | CATT | CR | Approval | Yes |
Yes
| revised | No | S3‑235010 | |||
S3‑235010 | CR to TS33.503 Correction U2U Relay Communication | CATT | CR | Approval | Yes |
Yes
| agreed | No | S3‑234700 | |||
S3‑234841 | Incorrect clause reference | OPPO | CR | Agreement | Yes |
Yes
| merged | No | S3‑235010 | |||
S3‑234897 | Clarification on UE-to-UE Relay coverage status in the U2U discovery model B procedure | Beijing Xiaomi Mobile Software | CR | Agreement | Yes |
YesQualcomm didn’t agree with the last sentence added.Ericsson agreed with this.
| merged | No | S3‑235010 | |||
S3‑234641 | Clairification and editorial changes to clause 6.6.3.3 | Huawei, HiSilicon | CR | Agreement | Yes |
YesInterdigital: reference is wrong.
| merged | No | S3‑235010 | |||
S3‑234731 | Corrections | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234512 | 4.1.3 - Clause 6.1.3.3 - Clarification DDS | Philips International B.V. | CR | Approval | Yes |
Yes
| revised | No | S3‑235056 | |||
S3‑235056 | 4.1.3 - Clause 6.1.3.3 - Clarification DDS | Philips International B.V. | CR | Approval | Yes |
Yes
| agreed | No | S3‑234512 | |||
S3‑234727 | CR to TS33.503 Clarification on the process of protecting U2U relay discovery message | CATT | CR | Approval | Yes |
YesQualcomm: not inline with what we have specified in SA2 and SA3.
| merged | No | S3‑235056 | |||
S3‑234896 | Clarification on protection on the direct discovery set in the U2U discovery | Beijing Xiaomi Mobile Software | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234642 | Clarification about key derivation in CP procedures and edtiorial changes R17 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234643 | Clarification about key derivation in CP procedures and edtiorial changes R18 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234710 | Rel17 ProSe: Updates on U2N relay security over control plane | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234839 | Hop-by-hop security policy | OPPO | CR | Agreement | Yes |
YesIt was clarified that this was for layer 3.
Qualcomm didn’t agree with adding this note.Ericsson felt also sceptic about this and didn’t agree.
| not pursued | No | ||||
S3‑234856 | 4.1.3 - Clause 6.1.3.3 - Clarification UE-to-UE Relay discovery key provisioning | Philips International B.V. | CR | Approval | Yes |
YesHuawei: this is not correct. Qualcomm didn’t support this either.
| not pursued | No | ||||
S3‑234942 | Rel18 ProSe: Updates on U2N relay security over control plane | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234714 | |||
S3‑234688 | Update clause 6.1.1, 6.6.1, 6.6.3.3 and 6.6.4.1 | OPPO, Xidian | CR | Agreement | Yes |
Yes
| revised | No | S3‑235011 | |||
S3‑234711 | Rel18 ProSe – Adding security for U2U Relay communication with integrated discovery | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑235011 | Update clause 6.1.1, 6.6.1, 6.6.3.3 and 6.6.4.1 | OPPO, Xidian | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234688 | |||
S3‑234843 | UE-to-UE Relay Communication with integrated discovery | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑234730 | |||
S3‑234895 | Add the general clause for UE-to-UE Relay Communication | Beijing Xiaomi Mobile Software | CR | Agreement | Yes |
Yes
| merged | No | S3‑235011 | |||
S3‑234923 | Update discovery key response of U2N discovery security procdure | Nokia, Nokia Shanghai Bell, Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑234855 | |||
S3‑235012 | Update discovery key response of U2N discovery security procdure | Nokia, Nokia Shanghai Bell, Ericsson | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234709 | Rel17 ProSe - Updates on U2N relay discovery key request procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234941 | Rel18 ProSe - Updates on U2N relay discovery key request procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑234713 | |||
S3‑235013 | Update discovery key response of U2N discovery security procdure | Nokia,Qualcomm Incorporated | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234898 | Clarification on the discovery security parameters in the U2N discovery | Beijing Xiaomi Mobile Software | CR | Agreement | Yes |
Yes
| merged | No | S3‑235012 | |||
S3‑234899 | Clarification on the discovery security parameters in the U2N discovery (mirror) | Beijing Xiaomi Mobile Software | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234510 | UTC-based Counter Reconciliation | Philips International B.V. | CR | Approval | Yes |
YesQualcomm: this is not a security requirement, and it's new.Philips replied that this was not new.
| not pursued | No | ||||
S3‑234713 | Rel18 ProSe - Updates on U2N relay discovery key request procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| revised | No | S3‑234941 | |||
S3‑234714 | Rel18 ProSe: Updates on U2N relay security over control plane | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| revised | No | S3‑234942 | |||
S3‑234730 | UE-to-UE Relay Communication with integrated discovery | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑234843 | |||
S3‑234855 | Update discovery key response of U2N discovery security procdure | Nokia, Nokia Shanghai Bell, Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑234923 | S3‑233614 | ||
S3‑235076 | Ls on uniqueness of Prose U2NRSC | Nokia | LS out | Approval | Yes |
Yes
| approved | No | ||||
4.1.4 | Mission Critical | S3‑234501 | [33.180] Clarification on SIP core access authentication | UK Home Office | CR | Agreement | Yes |
Yes
| agreed | No | S3‑233591 | |
S3‑234775 | [Draft] LS on authentication and authorization aspects in usage of MC Gateway UE | Ericsson | LS out | Approval | Yes |
YesNokia didn’t support this LS.
| noted | No | ||||
4.1.5 | Authentication and key management for applications based on 3GPP credential in 5G | S3‑234523 | Correction in UDM and GPSI related requirements | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235014 | |
S3‑235014 | Correction in UDM and GPSI related requirements | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| agreed | No | S3‑234523 | |||
S3‑234524 | Correction in UDM and GPSI related requirements | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235015 | |||
S3‑235015 | Correction in UDM and GPSI related requirements | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| agreed | No | S3‑234524 | |||
S3‑234525 | A-KID privacy related requirments | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234526 | A-KID privacy related requirments | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234527 | Editorial alignment | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235016 | |||
S3‑235016 | Existing AKMA procedure alignment | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| agreed | No | S3‑234527 | |||
S3‑234528 | Editorial alignment | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235017 | |||
S3‑235017 | Existing AKMA procedure alignment | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| agreed | No | S3‑234528 | |||
S3‑234529 | Discussion paper on AKMA service restriction in VPLMN | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234530 | AKMA service restriction in VPLMN | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesHuawei: not a security solution solved by SA3. Ericsson share the same view.
Nokia: AKMA is defined by SA3, nobody else will clarify this.
| not pursued | No | ||||
S3‑234532 | AKMA Service disable or withdrawn | Nokia, Nokia Shanghai Bell, ZTE, ChinaMobile | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234939 | Non-critical X.509 subjectAltName and unique DN following RFC 5280 | Ericsson | CR | Yes |
Yes
| not pursued | No | |||||
4.1.6 | Enhancements to User Plane Integrity Protection Support in 5GS |   | ||||||||||
4.1.7 | Security Aspects of Enhancements for 5G Multicast-Broadcast Services | S3‑234637 | Clarification about the NOTE in MOCN | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| not pursued | No | ||
S3‑234838 | 5MBS Annex W.4.2 | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑235106 | |||
S3‑235106 | 5MBS Annex W.4.2 | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234838 | |||
S3‑234850 | 5MBS Annex W.4.2 | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑235107 | |||
S3‑235107 | 5MBS Annex W.4.2 | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234850 | |||
4.1.8 | Security for enhanced support of Industrial IoT |   | ||||||||||
4.1.9 | Security Aspects of eNPN | S3‑234571 | NSWO support in SNPN using CH with AAA server | CableLabs, Charter Communications | CR | Agreement | Yes |
Yes
| revised | No | S3‑235077 | S3‑234290 |
S3‑235077 | NSWO support in SNPN using CH with AAA server | CableLabs, Charter Communications | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234571 | |||
S3‑234572 | Reply LS on NSWO support in SNPN using CH AAA server | CableLabs | LS out | Approval | Yes |
Yes
| revised | No | S3‑235109 | |||
S3‑235109 | Reply LS on NSWO support in SNPN using CH AAA server | CableLabs | LS out | Approval | Yes |
Yes
| approved | No | S3‑234572 | |||
S3‑234653 | Delete Editor's Note in trusted non-3GPP access | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234756 | Resolving EN about AN parameters | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234857 | Resolution of EN concerning the content of AN-parameters. | Nokia, Nokia Shanghai Bell | CR | Approval | Yes |
YesCableLabs: last change is not needed. Refer to IETF.
Nokia: we discussed it before; we don’t agree with the threat here.Some proprietary solution can take care of this. We don’t see a need for this.
Qualcomm: not convinced that there is a massive threat here.I need to see more details on how the network checks all these identities coming.
| not pursued | No | ||||
S3‑235083 | Resolution of EN concerning the content of AN-parameters. | Nokia, Nokia Shanghai Bell | CR | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑234626 | Discussion on security issue for NSWO | Huawei, HiSilicon | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑234627 | Security for NSWO support in SNPN | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234757 | Correction of CR implementation | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑235018 | |||
S3‑235018 | Correction of CR implementation | Ericsson,Nokia | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234757 | |||
S3‑234859 | Reintroduction of agreed changes not merged to TS 33.501 v 18.3.0 | Nokia, Nokia Shanghai Bell | CR | Approval | Yes |
Yes
| merged | No | S3‑235018 | |||
S3‑234758 | Editorial correction of CR implementation | Ericsson,Nokia | CR | Agreement | Yes |
YesAdding Nokia as co-source since the CR in 858 is a duplication.
| agreed | No | ||||
S3‑234858 | Editorial correction of incorrectly formatted text. | Nokia, Nokia Shanghai Bell | CR | Approval | Yes |
YesSame change as previous document.
| not pursued | No | ||||
4.1.10 | Security Aspects of Enhancement of Support for Edge Computing in 5GC | S3‑234562 | Adding conclusions for KI#2.6 | InterDigital, Inc. | draftCR | No |
Yes
| withdrawn | Yes | |||
S3‑234761 | CR of fixing references | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| revised | No | S3‑235019 | |||
S3‑235019 | CR of fixing references | Huawei, HiSilicon | CR | Approval | No |
Yes
| agreed | No | S3‑234761 | |||
S3‑234762 | CR of terms, abbreviations and symbols | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑234779 | Security of EAS discovery | Ericsson | CR | Agreement | Yes |
YesNokia: postpone this. We need time to study this more in SA2.
| not pursued | No | ||||
S3‑235061 | Security of EAS discovery | Ericsson | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234781 | 33.501 Rel-17 Correction: Reverting Annex P back to informative | Ericsson | CR | Agreement | Yes |
YesNokia didn’t agree with making this Annex normative again.There are other references to Annex P that may imply that this cannot be normative.There was other CR touching the same annex, so the decision was postponed until that CR was opened.
| not pursued | No | ||||
S3‑235062 | 33.501 Rel-17 Correction: Reverting Annex P back to informative | Ericsson | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234782 | 33.501 Rel-18 Correction: Reverting Annex P back to informative | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑235063 | 33.501 Rel-18 Correction: Reverting Annex P back to informative | Ericsson | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234788 | Correction on the GPSI verification | Ericsson | CR | Agreement | Yes |
YesNokia disagreed with the note.
| not pursued | No | ||||
S3‑234789 | Clarification on EDGE-10 interface to cover the ECS-ER security | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑235023 | |||
S3‑235023 | Clarification on EDGE-10 interface to cover the ECS-ER security | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234789 | |||
4.1.11 | Security aspects of Uncrewed Aerial Systems | S3‑234611 | Align UUAA with TS23.256 due to removal of uavAuthenticated IE | Huawei, HiSilicon | CR | Agreement | Yes |
YesQualcomm: this is aligned with the LS answer from SA2.They don’t support this in step 6 anymore.
Lenovo disagreed with Qualcomm.
| not pursued | No | ||
S3‑235024 | Align UUAA with TS23.256 due to removal of uavAuthenticated IE | Huawei, HiSilicon | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234612 | Align UUAA with TS23.256 due to removal of uavAuthenticated IE | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑235025 | Align UUAA with TS23.256 due to removal of uavAuthenticated IE | Huawei, HiSilicon | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234746 | Removal of the indicator of UUAA-MM result from AMF | CMCC | CR | Approval | Yes |
Yes
| merged | No | S3‑235024 | |||
S3‑234747 | Removal of the indicator of UUAA-MM result from AMF | CMCC | CR | Approval | Yes |
Yes
| merged | No | S3‑235025 | |||
S3‑234944 | Updates to Clause 5.2.1.1 | Lenovo | CR | Approval | Yes |
Yes
| merged | No | S3‑235025 | |||
S3‑234629 | Clarification related to reliable location | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234630 | Clarification related to reliable location | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234776 | R17-Clarification on reliable location information | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234777 | Rel18-Clarification on reliable location information | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234644 | Editorial changes and clarification about identity mapping R17 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234645 | Editorial changes and clarification about identity mapping R17 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234606 | Direct C2 security for unicast | Huawei, HiSilicon | CR | Agreement | Yes |
YesQualcomm didn’t agree with this CR.
Interdigital supported this CR.
| not pursued | No | ||||
S3‑234949 | Clarify the use of UUAA-MM for pairing authorisation | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234707 | |||
S3‑234707 | Clarify the use of UUAA-MM for pairing authorisation | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| revised | No | S3‑234949 | |||
4.1.12 | Security Aspects of Ranging Based Services and Sidelink Positioning | S3‑234584 | Update the abbreviations in 33.533 | ZTE | CR | Agreement | Yes |
Yes
| revised | No | S3‑235026 | |
S3‑235026 | Update the abbreviations in 33.533 | ZTE | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234584 | |||
S3‑234880 | Update to the Reference Points in Clause 4.2.2 | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234881 | Update to Common Security in Clause 5 | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234580 | Allocate FC Value for 33.533 | ZTE | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234581 | Update the FC Value in 33.533 | ZTE | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234715 | Rel18 SL positioning - Updates on UE discovery procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| merged | No | S3‑235027 | |||
S3‑234807 | Update clause 6.2.3 in TS 33.533 | OPPO | CR | Agreement | Yes |
Yes
| merged | No | S3‑235027 | |||
S3‑234882 | Add differences between Ranging discovery and ProSe discovery | Xiaomi | CR | Agreement | Yes |
Yes
| revised | No | S3‑235027 | |||
S3‑235027 | Add differences between Ranging discovery and ProSe discovery | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234882 | |||
S3‑234884 | Update to failure handling for authorization of UE role included in DCR | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234901 | Clarification on the Ranging/SL Positioning service exposure | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234885 | Update to AF authorization procedure for Ranging/SL positioning service exposure | Xiaomi | CR | Agreement | Yes |
Yes
| revised | No | S3‑235028 | |||
S3‑235028 | Update to AF authorization procedure for Ranging/SL positioning service exposure | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234885 | |||
S3‑234631 | Clarification on the authorization procedure of AF or 5GC NF | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234633 | Location_PrivacyCheck service from GMLC for UEs belonging to different PLMNs | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234900 | Clarification on the authorization for UEs belonging to different PLMNs | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234632 | Location_PrivacyCheck service from AMF | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234886 | Add privacy handing for Ranging/SL positioning service exposure through 5GC CP | Xiaomi | CR | Agreement | Yes |
Yes
| revised | No | S3‑235029 | |||
S3‑235029 | Add privacy handing for Ranging/SL positioning service exposure through 5GC CP | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234886 | |||
S3‑234888 | Update to authorization for Ranging/SL positioning service exposure through PC5 | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234733 | UE Privacy handling for service exposure through PC5 | Ericsson | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑234734 | UE Privacy handling for service exposure through PC5 | Ericsson | CR | Agreement | Yes |
Yes
| merged | No | S3‑235030 | |||
S3‑234887 | Add privacy handing for Ranging/SL positioning service exposure through PC5 | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑235030 | Add privacy handing for Ranging/SL positioning service exposure through PC5 | Xiaomi | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234516 | Clarification to 6.3.7 on discovery | Philips International B.V. | CR | Approval | Yes |
YesQualcomm and Ericsson didn’t understand the proposal.Check during the discovery, then after the discovery it is not necessary anymore.
Huawei: we think it is not necessary, but we are open to discussion.
| not pursued | No | ||||
S3‑234893 | Update to the procedure of UE privacy verification for UE-only operation | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234514 | Additions to enable secure network based SL positioning for UE without NAS connection | Philips International B.V. | CR | Approval | Yes |
YesQualcomm: this is a new procedure, Rel-18 s frozen.
Philips: we are answering to an SA2's concern.
Huawei: we need more time to discuss this.
| not pursued | No | ||||
S3‑234811 | 4.1.12 - Discussion on privacy of sharing location of Located UEs | Philips International B.V. | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234515 | Addition of Ranging/SL Positioning privacy profile | Philips International B.V. | CR | Approval | Yes |
YesEricsson had several issues with this contribution and proposed sending an LS to SA2 for furtherclarifications.
| not pursued | No | ||||
S3‑234582 | Remove the Note in clause 6.3.5 | ZTE | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234735 | UE Privacy handling for Ranging/SL positioning | Ericsson | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑234736 | UE Privacy profile for Ranging SL positioning | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234902 | Clarification on the UE Ranging/SL Positioning privacy profile | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234889 | Update to the title for unicast direct communication with long-term credential | Xiaomi | CR | Agreement | Yes |
Yes
| revised | No | S3‑235031 | |||
S3‑235031 | Update to the title for unicast direct communication with long-term credential | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234889 | |||
S3‑234717 | Rel18 SL positioning - Updates on unicast direct communication security | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234890 | Resolve the Editor's Note on SL Positioning service identifier | Xiaomi | CR | Agreement | Yes |
YesSame content as 717.
| not pursued | No | ||||
S3‑234891 | Update to unicast communication for SL positioning service provided by network | Xiaomi | CR | Agreement | Yes |
YesEricsson didn’t support this.
| not pursued | No | ||||
S3‑234892 | Unicast communication security supported by V2X UEs for SL positioning service provided by network | Xiaomi | CR | Agreement | Yes |
YesQualcomm and Ericsson didn’t support this.
| not pursued | No | ||||
S3‑234513 | 4.1.12 - Clause 6.4.4 - clarification | Philips International B.V. | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑234583 | Resolve the issue when SLPTK ID is about to wrap around | ZTE | CR | Agreement | Yes |
Yes
| revised | No | S3‑235079 | |||
S3‑235079 | Resolve the issue when SLPTK ID is about to wrap around | ZTE | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234583 | |||
4.1.13 | Security Aspects of eNA | S3‑234752 | EN resolving in TS33.501 X.2(R17) | China Mobile | CR | Agreement | Yes |
Yes
| merged | No | S3‑235034 | |
S3‑234753 | EN resolving in TS33.501 X.2(R18) | China Mobile | CR | Agreement | Yes |
Yes
| merged | No | S3‑235035 | |||
S3‑234560 | Conveying the CCA of the source NF service consumer | Nokia, Nokia Shanghai Bell, Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑235034 | |||
S3‑235034 | Conveying the CCA of the source NF service consumer | Nokia, Nokia Shanghai Bell, Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234560 | |||
S3‑234553 | Conveying the CCA of the source NF service consumer | Nokia, Nokia Shanghai Bell, Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑235035 | |||
S3‑235035 | Conveying the CCA of the source NF service consumer | Nokia, Nokia Shanghai Bell, Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234553 | |||
S3‑234554 | Adding service area for authorization in FL | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234665 | Updates to Federated Learning | Intel | draftCR | Yes |
Yes
| noted | No | |||||
S3‑234686 | Update Service Area in FL Authorization | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234687 | Discussion paper on Service Area in FL | Huawei, HiSilicon | discussion | Approval | Yes |
Yes
| noted | No | ||||
S3‑234555 | Removing EN in X.10 clause of TS 33.501 related to allowed NF consumers list | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235036 | |||
S3‑235036 | Removing EN in X.10 clause of TS 33.501 related to allowed NF consumers list | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234555 | |||
S3‑234816 | Resolution of one Editor's Note (Transaction ID) for Security for AI/ML model storage and sharing | Ericsson | CR | Agreement | Yes |
Yes
| merged | No | S3‑235036 | |||
S3‑234814 | Resolution of one EN (storage request update) in Security for AI/ML model storage and sharing | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234754 | Vendor ID EN resolving in TS33.501 X.10_Rel 17 | China mobile | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234755 | Vendor ID EN resolving in TS33.501 X.10_Rel 18 | China mobile | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234960 | Resolution of one Editor's Note (Interoperability ID) for Security for AI/ML model storage and sharing | Ericsson, Nokia, Nokia Shanghai Bell,China Mobile | CR | Agreement | Yes |
YesChina Mobile added as co-signer as 755 is identical.
| agreed | No | ||||
S3‑234815 | Update flow of Nnwdaf_MLModelProvision | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑235037 | |||
S3‑235037 | Update flow of Nnwdaf_MLModelProvision | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234815 | |||
S3‑234817 | Correction on allowed NFc list for model storage and sharing in indirect communication scenarios | Ericsson | CR | Agreement | Yes |
YesNokia couldn’t agree with this.Huawei couldn’t agree either with the statement on the SCP.
| not pursued | No | ||||
S3‑234818 | Clarify ADRF usage to be optional | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234819 | Authorization of Model Sharing with MTLF | Ericsson | CR | Agreement | Yes |
YesNokia: this came up in SA2 quite late. We still believe that this needs to be properly studied. There is a security issue but we need more time.
Huawei supported this with modifications in the note.
It was commented that this was not a correction. Given that it would bring a new security solution MCC advised to bring this to Rel-19.
| not pursued | No | ||||
S3‑234820 | LS on Model Sharing With MTLF | Ericsson | LS out | Approval | Yes |
Yes
| revised | No | S3‑235110 | |||
S3‑235110 | LS on Model Sharing With MTLF | Ericsson | LS out | Approval | No |
Yes
| approved | No | S3‑234820 | |||
S3‑234684 | Discussion paper on the DataSetTag | Huawei, HiSilicon | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑234685 | Procedure for secured and authorized AIML model data sharing | Huawei, HiSilicon | CR | Agreement | Yes |
YesNokia: threats are not evident here.
| not pursued | No | ||||
S3‑234664 | Updates to ML Model Storage and Sharing | Intel Corporation (UK) Ltd | draftCR | Yes |
Yes
| merged | No | S3‑235036 | ||||
S3‑234625 | Correction on protection of data and analytics exchange in roaming case | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234638 | withdrawn | Huawei, HiSilicon | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
4.1.14 | Modified PRINS for roaming service providers in 5G | S3‑234615 | Defining Roaming Hub | NTT DOCOMO, Vodafone | CR | Agreement | Yes |
Yes
| not pursued | No | ||
S3‑235070 | Defining Roaming Hub | NTT DOCOMO, Vodafone | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234764 | Editorial modifications on PRINS | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| agreed | No | ||||
S3‑234973 | Updating intermediary originated error message procedure | NTT DOCOMO, Vodafone | CR | Agreement | Yes |
Yes
| merged | No | S3‑235069 | S3‑234614 | ||
S3‑234694 | Resolving Editor's Note on N32 and/or SBA layers for Modified PRINS | Vodafone, Verizon, T-Mobile USA, NTT DOCOMO, Telefonica | CR | Approval | Yes |
Yes
| revised | No | S3‑235069 | |||
S3‑235069 | Resolving Editor's Note on N32 and/or SBA layers for Modified PRINS | Vodafone, Verizon, T-Mobile USA, NTT DOCOMO, Telefonica | CR | Approval | Yes |
Yes
| agreed | No | S3‑234694 | |||
S3‑234863 | SEPP requirement for error handling from Roaming Intermediaries | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| merged | No | S3‑235069 | |||
S3‑234767 | Editorial modifications on PRINS | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| merged | No | S3‑235069 | |||
S3‑234768 | Addressing ENs on reformattedData and N32-f context | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| merged | No | S3‑235069 | |||
S3‑234769 | Addressing EN on error message layers | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| merged | No | S3‑235069 | |||
S3‑234833 | Updating security procedure to enable Roaming Hubs | Samsung | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234770 | Deleting Note 3 in clause 5.9.3.2 | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑234826 | Correction of N32-f terminology | Ericsson | CR | Agreement | Yes |
Yes
| merged | No | S3‑235069 | |||
S3‑234864 | N32f and N32c correlation issue | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234865 | Security profiles for PRINS | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234556 | Discussion paper on data control by roaming hubs with modified PRINS | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234557 | LS on data control by Roaming Hubs with PRINS | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
YesNokia highlighted that GSMA has been asking for several times already. There was a lack of response to GSMA and SA2 on the need for roaming hub to control the PDU session. Telecom Italia supported Nokia and stated that SA3 needed to draft something to SA2 to let them aware of the problem.
Verizon: this has architecture impact and it’s out of scope of SA3.
| noted | No | ||||
S3‑234614 | Updating intermediary originated error message procedure | NTT DOCOMO | CR | Agreement | Yes |
Yes
| revised | No | S3‑234973 | |||
4.1.15 | All other maintenance topics (not listed above) | S3‑234868 | Detailed functional security model description for support of RNAA | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235104 | |
S3‑235104 | Detailed functional security model description for support of RNAA | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| agreed | No | S3‑234868 | |||
S3‑234907 | Clarification for CAPIF-8 | Xiaomi | CR | Agreement | Yes |
Yes
| revised | No | S3‑235111 | |||
S3‑235111 | Clarification for CAPIF-8 | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234907 | |||
S3‑234961 | Resolving stage 2 editor's notes | NTT DOCOMO | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑234945 | |||
S3‑234616 | Revocation procedures invoked by API invoker | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234617 | Revocation procedure invoked by resource owner client | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234910 | Update for authorization revocation procedure for RNAA | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234832 | Revocation procedure for RNAA | Samsung | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234911 | Resolve EN related to API invoker ID and GPSI | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234786 | Clarification on resource owner ID | Ericsson | CR | Agreement | Yes |
Yes
| revised | No | S3‑235059 | |||
S3‑235059 | Clarification on resource owner ID | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234786 | |||
S3‑234618 | Correction on authentication and authorization for RNAA | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| revised | No | S3‑235113 | |||
S3‑235113 | Correction on authentication and authorization for RNAA | Huawei, HiSilicon | CR | Agreement | No |
Yes
| agreed | No | S3‑234618 | |||
S3‑234619 | Security negotiation for RNAA | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| merged | No | S3‑235114 | |||
S3‑234620 | Access token profile for RNAA | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| revised | No | S3‑235115 | |||
S3‑235115 | Access token profile for RNAA | Huawei, HiSilicon | CR | Agreement | No |
Yes
| agreed | No | S3‑234620 | |||
S3‑234621 | Obtaining Tokens Procedure for RNAA | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| merged | No | S3‑235115 | |||
S3‑234622 | Refreshing Token for RNAA | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| merged | No | S3‑235115 | |||
S3‑234784 | Identification of RNAA token | Ericsson | CR | Agreement | Yes |
Yes
| merged | No | S3‑235113 | |||
S3‑235064 | Identification of RNAA token | Ericsson | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234908 | Resolve EN related to authorization flow | Xiaomi | CR | Agreement | Yes |
Yes
| revised | No | S3‑235114 | |||
S3‑235114 | Resolve EN related to authorization flow | Xiaomi | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234908 | |||
S3‑234790 | Optimization in the authorization code flow usage | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234785 | Optimizations for accessing own resources | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑235065 | Optimizations for accessing own resources | Ericsson | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234909 | Streamline the Editor's Notes for RNAA | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234787 | Clarification on the scope of the Rel-18 RNAA specification | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑235060 | Clarification on the scope of the Rel-18 RNAA specification | Ericsson | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234550 | Updates to the SBA certificate profile | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesHuawei: this is related to a draft, not a finished RFC.We can wait until it is finished, no rush.
Nokia: it is in a mature status, only editorial changes expected.
Nokia commented that they had received comments to improve this and that they would bring it back next meeting.
| not pursued | No | ||||
S3‑234639 | Update to Set up of initial trust | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234640 | Update to Validation of usage of X.509 certificate | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234652 | CR to update certificate lifecycle management | Huawei, HiSilicon | CR | Agreement | Yes |
YesNokia: this may be seen as mandatory to implement if it’s a normative clause.
Huawei: everything in this clause is a guideline for implementation.
| not pursued | No | ||||
S3‑234589 | A-KID update after UPU | ZTE | CR | Agreement | Yes |
YesEricsson didn’t agree with this CR.
| not pursued | No | ||||
S3‑234590 | Adding SUPI/GPSI as an option in KAF request message | ZTE Corporation | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234591 | Editorial corrections to TS 33.535 in R17 | ZTE Corporation | CR | Agreement | Yes |
Yes
| revised | No | S3‑235080 | |||
S3‑235080 | Editorial corrections to TS 33.535 in R17 | ZTE Corporation | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234591 | |||
S3‑234592 | Editorial corrections to TS 33.535 in R18 | ZTE Corporation | CR | Agreement | Yes |
Yes
| revised | No | S3‑235081 | |||
S3‑235081 | Editorial corrections to TS 33.535 in R18 | ZTE Corporation | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234592 | |||
S3‑234593 | Update AKMA key lifetimes | ZTE Corporation | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234594 | Update AKMA related UDM services | ZTE Corporation | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234595 | Adding indication to inform UE of A-KID refresh | ZTE Corporation | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234912 | Routing indicator update issue in the A-KID construction procedure Release 17 | Xiaomi | CR | Agreement | Yes |
YesHuawei didn’t agree with this contribution.
Qualcomm: this clarification is necessary.
| not pursued | No | ||||
S3‑234913 | Routing indicator update issue in the A-KID construction procedure Release 18 (mirror) | Xiaomi | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234599 | Dummy WID for R18 eNS | Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, LGE, Xiaomi, ZTE | WID new | Agreement | Yes |
Yes
| noted | No | ||||
S3‑234605 | NSSAA procedure update for multiple registration | Huawei, HiSilicon | CR | Agreement | Yes |
YesHuawei commented that the current specification was broken and requested the operators to check it out.
Ericsson commented that this was the 4th time that they saw this contribution and that they still didn’t agree.
The Chair commented that a Working Agreement could be necessary to put an end to it.
Ericsson commented that not pursuing this would be a solution and that the working agreement could be avoided.
Ericsson added this was a new feature and not a correction.
| not pursued | No | ||||
S3‑234600 | Home control for Network Slice Admission Control procedures | Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, LGE, Xiaomi, ZTE | CR | Agreement | Yes |
YesThe Chair commented that there was no exception for Rel-18 topics. Huawei wanted to include this content and recurring to a technical vote if necessary,
It was commented that stage 2 for Rel-18 was frozen already, so little chance to have this approved in Plenary. This was taken offline.
| not pursued | No | ||||
S3‑234596 | Reuse error code during home network triggered primary authentication procedure | ZTE | CR | Agreement | Yes |
YesHuawei: we don’t need to refer to CT4. This is not purely aligned with them either.Nokia supported this.
Nokia and Huawei agreed on the second change.
Ericsson: the second change may not be correctly placed.
| revised | No | S3‑235038 | |||
S3‑235038 | Reuse error code during home network triggered primary authentication procedure | ZTE | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234596 | |||
S3‑234597 | Clarify AMF responses in HONTRA procedure. | ZTE Corporation | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑235039 | Clarify AMF responses in HONTRA procedure. | ZTE Corporation | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234598 | HONTRA procedure corrections | ZTE Corporation | CR | Agreement | Yes |
Yes
| merged | No | S3‑235040 | |||
S3‑234655 | clarification for HONTRA procedure | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| revised | No | S3‑235040 | |||
S3‑235040 | clarification for HONTRA procedure | Huawei, HiSilicon | CR | Agreement | No |
Yes
| agreed | No | S3‑234655 | |||
S3‑234680 | Clarification on signalling overload in Home Network Triggered Authentication | LG Electronics | CR | Approval | Yes |
YesNokia: not convinced with the text.
Ericsson: not needed.
| not pursued | No | ||||
S3‑234794 | Implementation corrections | Ericsson | CR | Agreement | Yes |
Yes
| merged | No | S3‑235040 | |||
S3‑234795 | Clarifications of the AMF and UDM behaviour | Ericsson | CR | Agreement | Yes |
Yes
| merged | No | S3‑235039 | |||
S3‑234534 | Callback URI clarification and API correction | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesEricsson: not necessary.
Huawei: it needs rewording.
| merged | No | S3‑235040 | |||
S3‑235041 | Callback URI clarification and API correction | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234704 | Establishing IPsec SAs for IAB inter-CU topology adaptation and backhaul RLF recovery procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234772 | Guidance on mitigating privacy risk of variable length NAI based SUPIs | Ericsson, Qualcomm Incorporated | CR | Agreement | Yes |
YesMCC comment: dangerous to mention a study when introducing a CR, even if the change is not normative.
The NOTE should not have a recommendation, so better to have NOTE 0 as plain text instead.
| revised | No | S3‑235058 | |||
S3‑235058 | Guidance on mitigating privacy risk of variable length NAI based SUPIs | Ericsson, Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234772 | |||
S3‑234828 | [IAB][Rel-17] IAB inter-CU topology adaptation procedure | Samsung, Intel, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235032 | |||
S3‑235032 | [IAB][Rel-17] IAB inter-CU topology adaptation procedure | Samsung, Intel, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234828 | |||
S3‑234829 | [IAB][Rel-18] IAB inter-CU topology adaptation procedure | Samsung, Intel, Huawei, HiSilicon, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235033 | |||
S3‑235033 | [IAB][Rel-18] IAB inter-CU topology adaptation procedure | Samsung, Intel, Huawei, HiSilicon, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234829 | |||
S3‑234925 | Guidance on mitigating privacy risk of variable length NAI-based SUPIs | InterDigital Communications, Nokia | CR | Agreement | Yes |
YesMCC comment: dangerous to mention a study when introducing a CR, even if the change is not normative.
The NOTE should not have a recommendation, so better to have NOTE 0 as plain text instead.
| merged | No | S3‑235058 | S3‑234854 | ||
S3‑234933 | Establishing IPsec SAs for IAB inter-CU topology adaptation and backhaul RLF recovery procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑234703 | |||
S3‑234936 | Updating the FC values | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑234705 | |||
S3‑234938 | Updating the FC values | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| not pursued | No | S3‑234706 | |||
S3‑234538 | N3IWF procedure clarification | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234539 | N3IWF procedure clarification | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234540 | N3IWF procedure clarification | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234541 | N3IWF procedure clarification | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235082 | |||
S3‑235082 | N3IWF procedure clarification | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| agreed | No | S3‑234541 | |||
S3‑234577 | AUSF sends back MSK to W-AGF after successful EAP authentication | CableLabs | CR | Agreement | Yes |
YesNokia: is this a correction or a functional modification? Rel-18 is frozen.
Huawei: alignment with CT4 definitions, so it can be cat-F. Nokia wasn’t sure about this.
Huawei: this should be done in Rel-17 as well.
| revised | No | S3‑235048 | |||
S3‑235048 | AUSF sends back MSK to W-AGF after successful EAP authentication | CableLabs | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234577 | |||
S3‑234585 | Remove the EN on I.10.3.1 | ZTE | CR | Agreement | Yes |
Yes
| merged | No | S3‑235083 | |||
S3‑234545 | SOR UPU NVM issue | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234708 | Handling of SoR/UPU Counter stored in NVM | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| revised | No | S3‑235052 | S3‑233892 | ||
S3‑235052 | Handling of SoR/UPU Counter stored in NVM | Qualcomm Incorporated | CR | Agreement | No |
Yes
| agreed | No | S3‑234708 | |||
S3‑234419 | Correction in trusted non-3GPP access authentication | Lenovo | CR | Approval | Yes |
YesSame change in 4759.
| not pursued | No | ||||
S3‑234669 | CR on Security vulnerability fix for use of AES-GCM and AES-GMAC in 33.203 | Apple | CR | Approval | Yes |
YesHuawei: fine with the original proposal from Apple but this is different.
Nokia: issues with the first change.Huawei agreed that it wasn’t needed.
| not pursued | No | ||||
S3‑234879 | Correction of reference and related text | Orange | CR | Approval | Yes |
Yes
| revised | No | S3‑235020 | |||
S3‑235020 | Correction of reference and related text | Orange | CR | Approval | Yes |
Yes
| agreed | No | S3‑234879 | |||
S3‑234915 | Correction of reference and related text | Orange | CR | Approval | Yes |
Yes
| revised | No | S3‑235021 | |||
S3‑235021 | Correction of reference and related text | Orange | CR | Approval | Yes |
Yes
| agreed | No | S3‑234915 | |||
S3‑234916 | Correction of reference and related text | Orange UK | CR | Approval | Yes |
Yes
| revised | No | S3‑235022 | |||
S3‑235022 | Correction of reference and related text | Orange UK | CR | Approval | Yes |
Yes
| agreed | No | S3‑234916 | |||
S3‑234920 | Correction to Figure 16.4-1 | Ericsson | CR | Agreement | Yes |
YesEricsson: no change, it’s an editorial change because the figure is not visible in TS 33.501.
This had to be checked.
MCC commented that they could check this during CR implementation.
| not pursued | No | ||||
S3‑234927 | Correction to Figure 16.4-1 | Ericsson | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234542 | Discussion paper on security aspect of NF accessing the external AF services | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234543 | Framework for NF accessing the external AF data | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234544 | Framework for NF accessing the external AF data | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234575 | Replace reference to IETF draft-emu-eap-tls13 in annex B with RFC 9190 | CableLabs | CR | Agreement | Yes |
YesQualcomm: it's the same document, we don’t need to void the existing reference.
| revised | No | S3‑235042 | |||
S3‑235042 | Replace reference to IETF draft-emu-eap-tls13 in annex B with RFC 9190 | CableLabs | CR | Agreement | Yes |
Yes
| agreed | No | S3‑234575 | |||
S3‑234650 | Update the abbreviation list to include CPA and CPC R17 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234651 | Update the abbreviation list to include CPA and CPC R18 | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234766 | Authentication result removal | Huawei, HiSilicon | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑234957 | Add the case of a failed AUTS verification in the UDM/ARPF to the synchronization failure recovery of the Home Network | BSI (DE) | CR | Approval | Yes |
YesEricsson: privacy attack is not clear.
Nokia: fine with the text, the justification can be adjusted.
| not pursued | No | S3‑234932 | |||
S3‑234959 | Add the case of a failed AUTS verification in the HE/AuC to the re-synchronisation procedure | BSI (DE) | CR | Approval | Yes |
Yes
| not pursued | No | S3‑234958 | |||
S3‑234551 | Discussion paper on automated additions of root CAs certificates using CMP | Nokia, Nokia Shanghai Bell | discussion | Information | Yes |
Yes
| noted | No | ||||
S3‑234552 | Automated additions of root CAs certificates using CMP | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
YesMCC commented that this looked like a rel-19 change,there was no correction being made. It was commented that this was no addition of a feature or a functional modification.
Ericsson: no rush, let's postpone this.
Ericsson commented that this was considered as an expansion.
| not pursued | No | ||||
S3‑234566 | Rel-18 Work Item Exception for FS_PIN_Sec | InterDigital Communications | WI exception request | Approval | Yes |
YesMCC: we don’t need exception sheets for studies.
| noted | No | ||||
S3‑234587 | Update the clause 6.6.3.3 in 33.503 | ZTE | CR | Agreement | Yes |
YesHuawei didn’t agree with the changes in the first paragraph.Qualcomm supported this comment.
| merged | No | S3‑235010 | |||
S3‑234796 | Update UE terminating procedures for e2DCe | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234797 | Change of the abbreviation "DCMF to "MF" and related changes to the text and figures | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234798 | Add the abbreviation "IMS AS" | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234799 | Remove "DC Application Server" in Figure N.3.4-1 and add a NOTE | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234800 | Editorial changes to clause 7.2.5 | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234801 | Change the "P-CSCF(IMS AS)" to "IMS AS via the P-CSCF" | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234821 | Handling of 3gpp-Sbi-Originating-Network-Id header in the SNPN case | Ericsson, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234822 | Handling of 3gpp-Sbi-Originating-Network-Id header in the SNPN case | Ericsson, Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234823 | Discussion of the Verification of the serving network name by the AUSF | Ericsson | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234824 | Verification of the serving network name by the AUSF | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234825 | Verification of the serving network name by the AUSF | Ericsson | CR | Agreement | Yes |
Yes
| agreed | No | ||||
S3‑234433 | Evaluation of different options of security for selective SCG Activation. | Nokia, Nokia Shanghai Bell | discussion | Yes |
Yes
| noted | No | |||||
S3‑234434 | Security for Selective SCG Activation | Nokia, Nokia Shanghai Bell | draftCR | Yes |
Yes
| noted | No | |||||
S3‑234648 | draftCR on Securtiy of Selective SCG Activation | Huawei, HiSilicon, Qualcomm Incorporated, Ericsson, Nokia, Nokia Shanghai Bell, Samsung | draftCR | Approval | Yes |
Yes
| merged | No | S3‑235100 | |||
S3‑234666 | Updates to Security for Selective SCG Activation | Intel | draftCR | Yes |
Yes
| revised | No | S3‑235100 | ||||
S3‑235100 | Updates to Security for Selective SCG Activation | Intel | draftCR | - | Yes |
Yes
| approved | No | S3‑234666 | |||
S3‑234696 | Security for subsequent CPAC | OPPO | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234737 | Security for Subsequent Conditional PSCell Addition or Change | Ericsson | other | Approval | Yes |
Yes
| noted | No | ||||
S3‑234830 | Discussion paper on Selective SCG activation | Samsung | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234831 | Security for Selective SCG Activation | Samsung | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234420 | Discussion on UPU Header Security | Lenovo | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234421 | UPU Header Security | Lenovo | CR | Approval | Yes |
Yes
| not pursued | No | ||||
S3‑235047 | UPU Header Security | Lenovo | CR | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑234548 | Discussion paper of UPU implementation gaps | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234549 | Enhancement in UPU procedure to protect UPU header | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| merged | No | S3‑235047 | |||
S3‑234586 | Remove the 5G-GUTI in the Registration Reject message in clause 7.2.1 and 7A.2.1 | ZTE | CR | Agreement | Yes |
Yes
| merged | No | S3‑235045 | |||
S3‑234667 | Remove the 5G-GUTI in the Registration Reject message in clause 7.2.1 and 7A.2.1 | Intel | CR | Yes |
Yes
| merged | No | S3‑235045 | ||||
S3‑234654 | Update step 8 in AUN3 devices supporting 5G key hierarchy procedure | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234759 | Correction of Figure 7A.2.1-1 | Ericsson,Lenovo | CR | Agreement | Yes |
YesSame change in 4419. Lenovo added as a co-signer.
| agreed | No | ||||
S3‑234867 | Discussion SNAAPP-CAPIF RNAA authorization methods and related interfaces | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234536 | Removing GUTI from Registration Reject | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235045 | |||
S3‑235045 | Removing GUTI from Registration Reject | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| agreed | No | S3‑234536 | |||
S3‑234537 | NULL encryption clarification | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| revised | No | S3‑235046 | |||
S3‑235046 | NULL encryption clarification | Nokia, Nokia Shanghai Bell | CR | Agreement | No |
Yes
| agreed | No | S3‑234537 | |||
S3‑234561 | Guidance on mitigating privacy risk of variable length NAI-based SUPIs | InterDigital Communications, Nokia | CR | Agreement | Yes |
Yes
| revised | No | S3‑234854 | |||
S3‑234588 | Discussion on the AKMA context removal and A-KID update after UPU | ZTE Corporation | discussion | Discussion | No |
Yes
| withdrawn | Yes | ||||
S3‑234701 | Discussion on protecting header information in UPU | Qualcomm Incorporated | discussion | Discussion | Yes |
Yes
| noted | No | S3‑233869 | |||
S3‑234702 | Protection of UPU header | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| merged | No | S3‑235047 | S3‑233870 | ||
S3‑234703 | Establishing IPsec SAs for IAB inter-CU topology adaptation and backhaul RLF recovery procedure | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| revised | No | S3‑234933 | |||
S3‑234705 | Updating the FC values | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| revised | No | S3‑234936 | |||
S3‑234706 | Updating the FC values | Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| revised | No | S3‑234938 | |||
S3‑234724 | Guidance on mitigating privacy risk of variable length NAI based SUPIs | Ericsson, Qualcomm Incorporated | CR | Agreement | Yes |
Yes
| withdrawn | Yes | ||||
S3‑234854 | Guidance on mitigating privacy risk of variable length NAI-based SUPIs | InterDigital Communications, Nokia | CR | Agreement | Yes |
Yes
| revised | No | S3‑234925 | S3‑234561 | ||
S3‑234926 | Discussion paper on 33.122 updates and responses for reply-LS on SNAAPPY | Nokia, Nokia Shanghai Bell | discussion | Yes |
Yes
| noted | No | |||||
S3‑234932 | Add the case of a failed AUTS verification in the UDM/ARPF to the synchronization failure recovery of the Home Network | BSI (DE) | CR | Approval | No |
Yes
| revised | No | S3‑234957 | |||
S3‑234934 | Add the case of a failed AUTS verification in the HE/AuC to the re-synchronisation procedure | BSI (DE) | CR | Approval | No |
Yes
| revised | No | S3‑234958 | |||
S3‑234945 | resolving RNA stage 2 editor's notes | NTT DOCOMO INC. | CR | Agreement | Yes |
Yes
| revised | No | S3‑234961 | |||
S3‑234958 | Add the case of a failed AUTS verification in the HE/AuC to the re-synchronisation procedure | BSI (DE) | CR | Approval | Yes |
Yes
| revised | No | S3‑234959 | S3‑234934 | ||
4.2 | New WID on 5G Security Assurance Specification (SCAS) for the Unified Data Repository (UDR). |   | ||||||||||
4.3 | New WID on SCAS for Rel-18 features on existing functions. | S3‑234422 | Evidence correction for 33.117 | Huawei, HiSilicon, Deutsche Telecom, T-mobile, ZTE, Nokia, Ericsson, China Mobile, Federal Office for Information Security (BSI), TELUS, MITRE | CR | Agreement | Yes |
Yes
| agreed | No | ||
S3‑234519 | SCAS AUSF - Serving network management | Keysight Technologies UK Ltd | CR | Approval | Yes |
Yes
| not pursued | No | ||||
4.4 | New WID on 5G Security Assurance Specification (SCAS) for the Short Message Service Function (SMSF). | S3‑234674 | TS 33.529 Skeleton for Security Assurance Specification for Short Message Service Function (SMSF) | IIT Bombay | draft TS | Yes |
Yes
| agreed | No | |||
S3‑234675 | Scope of Security Assurance Specification for Short Message Service Function (SMSF) | IIT Bombay | pCR | Yes |
Yes
| approved | No | |||||
S3‑234676 | References of Security Assurance Specification for Short Message Service Function (SMSF) | IIT Bombay | pCR | Yes |
Yes
| approved | No | |||||
S3‑234808 | Definitions of terms, symbols and abbreviations of Security Assurance Specification for Short Message Service Function (SMSF) | IIT Bombay | pCR | Yes |
Yes
| approved | No | |||||
S3‑235044 | Draft TS 33.529 | IIT Bombay | draft TS | Approval | Yes |
Yes
| approved | No | ||||
4.5 | New WID on Addition of 256-bit security Algorithms. | S3‑234424 | Introduction of the Snow 5G 256-bits algorithm specification | Nokia, Nokia Shanghai Bell | draft TS | Yes |
YesNokia commented that this implied a change in what was planned in the WID.
Qualcomm was concerned on the decision about using the combined algorithm. The Chair clarified that this wasn’t for Rel-18 anyway and no decision had been made yet. Qualcomm thought that it might be better to go back and ask SAGE to separate the algorithms and have a new naming. They also pointed out the difficulty of discussing non public documents when comments needed to be made. The Chair commeanted that a call with SAGE could be arranged and take a new meeting cycle.
Qualcomm: the link to the ETSI website doesn’t work now because the algorithm is not approved. It was suggested to have it as an editor's note.
Nokia commented that SAGE replied that the algorithms couldn’t be split.They asked if it was possible to have a call with SAGE by the end of January, before the Athens meeting.
| noted | No | |||
S3‑234425 | Introduction of the Snow 5G 256-bits implementers’ test data | Nokia, Nokia Shanghai Bell | draft TS | Yes |
Yes
| noted | No | |||||
S3‑234426 | Introduction of the Snow 5G 256-bits design conformance test data | Nokia, Nokia Shanghai Bell | draft TS | Yes |
Yes
| noted | No | |||||
S3‑234427 | Introduction of the AES 256-bits algorithm specification | Nokia, Nokia Shanghai Bell | draft TS | Yes |
Yes
| noted | No | |||||
S3‑234428 | Introduction of the AES 256-bits implementers’ test data | Nokia, Nokia Shanghai Bell | draft TS | Yes |
Yes
| noted | No | |||||
S3‑234429 | Introduction of the AES 256-bits design conformance test data | Nokia, Nokia Shanghai Bell | draft TS | Yes |
Yes
| noted | No | |||||
S3‑234430 | Introduction of the ZUC based 256-bits algorithm specification | Nokia, Nokia Shanghai Bell | draft TS | Yes |
Yes
| noted | No | |||||
S3‑234431 | Introduction of the ZUC 256-bits implementers’ test data | Nokia, Nokia Shanghai Bell | draft TS | Yes |
Yes
| noted | No | |||||
S3‑234432 | Introduction of the ZUC 256-bits design conformance test data | Nokia, Nokia Shanghai Bell | draft TS | Yes |
Yes
| noted | No | |||||
5 | Rel-19 Studies |   | ||||||||||
6 | New Study/Work item proposals |   | ||||||||||
6.1 | Release/TU management | S3‑234568 | 5G PQC Planning and Threats | U.S. National Security Agency | discussion | Information | Yes |
YesDell commented that more use cases needed to be introduced.
Is the work done in other standards groups being considered? NSA replied that this was not a 3GPP problem only, so groups like IETF are also involved. GSMA is also looking at quantum for 5G threats.
| noted | No | ||
S3‑234827 | Input to Rel-19 prioritization and time planning | Ericsson | discussion | Discussion | Yes |
YesMotorola: security related to the work in other WGs is not here.
Ericsson: we always have to do that.
Huawei: we have concerns on the simplistic view of "we don’t know what RAN or SA is doing".
The Chair had a proposal in tdoc 853.
| noted | No | ||||
S3‑234853 | Rel-19 TU management | SA WG3 Chair | other | Discussion | Yes |
YesHuawei: concerned about not having a meeting in April. 2024 This is a big gap of 6 months not doing anything. We ended up being overwhelmed by waiting for progress from other groups, we need to be more proactive.
NTT-Docomo: harder to have many small WIDs than fewer bigger WIDs.
Lenovo: we need help from other WGs about the timeline of their work.
OPPO: anticipate the big items coming from SA2 and RAN.Have some additional adhocs, conference calls.
Nokia: endorse studies can be endorsed and sent to SA and RAN groups.
Qualcomm: not comfortable endorsing.
Interdigital: there is work that can be separately in separate streams (e.g. SCAS).
Apple: we need to evaluate whether the work started in other WGs needs security work.
| noted | No | ||||
6.2 | SID/WID proposals for SA3 prime topics | S3‑234416 | Discussions for Rel-19 Study on enablers for ZTS | Lenovo, Motorola Mobility | discussion | Discussion | Yes |
Yes
| noted | No | S3ah‑230011 | |
S3‑234417 | New SID on enablers for Zero Trust Security | Lenovo, Motorola Mobility, MITRE, Interdigital, Motorola Solutions, Charter Communications, Johns Hopkins University APL, Intel, US National Security Agency, Telefonica, NCSC, OTD_US, Deutsche Telekom, Keysight Technologies, Center for Internet Security, | SID new | Approval | Yes |
YesHuawei: WT3 is more about the next step, not key issues and solutions. This is not in scope of the study.There was no agreement in the previous study, so the outcome shouldn’t be referred here. We still have concerns about WT1, we believe that it will lead to the same discussions we had in the previous study.
John Hopkins: the outcome refers to the gap analysis we did in that study.
Ericsson: the objectives are not clear, it needs further work.
| revised | No | S3‑235089 | S3ah‑230012 | ||
S3‑235089 | New SID on enablers for Zero Trust Security | Lenovo, Motorola Mobility, MITRE, Interdigital, Motorola Solutions, Charter Communications, Johns Hopkins University APL, Intel, US National Security Agency, Telefonica, NCSC, OTD_US, Deutsche Telekom, Keysight Technologies, Center for Internet Security, | SID new | Approval | No |
Yes
| agreed | No | S3‑234417 | |||
S3‑234418 | Rel-19 eZTS Proposal_Oflline Call Minutes | Lenovo, Motorola Mobility | discussion | Information | Yes |
Yes
| noted | No | ||||
S3‑234502 | Study of ACME for Automated Certificate Management in SBA | Cisco Systems, Google, Mavenir, CableLabs, Charter Communications, AT&T, Microsoft, TELUS, DISH Network, Deutsche Telekom, Johns Hopkins University APL | SID new | Approval | Yes |
YesEricsson: Trust in Cloud native platforms should also be studied.
Google: yes, it's part of the study.
Nokia: impact of virtualization impact on certificate management is not being considered here. In addition, is it good to have a new protocol in Rel-19?
It was commented that life cycle management of certificates need to be considered.
Huawei: justification reads that this is the best alternative due to virtualization is a bit far fetched. Please remove this part.
AT&T: SBA will be here for many releases, no issue with having a new protocol for certificate management.
| revised | No | S3‑235090 | |||
S3‑235090 | Study of ACME for Automated Certificate Management in SBA | Cisco Systems, Google, Mavenir, CableLabs, Charter Communications, AT&T, Microsoft, TELUS, DISH Network, Deutsche Telekom, Johns Hopkins University APL | SID new | Approval | Yes |
Yes
| agreed | No | S3‑234502 | |||
S3‑234504 | Discussion on the Study on enabling 256-bits cryptographic algorithms | Nokia, Nokia Shanghai Bell | discussion | Yes |
YesHuawei: this can be done in parallel with the creation of the 256-bit specs. Coexistence of current algorithms and these algorithms will have to be studied.
GSMA: we have done this in 3GPP before. From 64 to 128 bits, without a massive study. Let's check what we did before. Focus on the symmetric 256-bit algorithms, not the asymmetric ones.
| noted | No | |||||
S3‑234505 | Study on Alternative Authentication without Access to a Centralized 5G Core | US Department of Homeland Security, The MITRE Corporation, Dell Technologies, AT&T, Apple, InterDigital, Cable Labs, Keysight Technologies | SID new | Approval | Yes |
YesORANGE: it describes a service that is not addressed in SA1. It should be first be treated in SA1 and SA2 firstly.
Huawei: this was discussed in IOPS back in 4G, but it has an architectural impact that is not in scope of SA3.
IDEMIA: mission critical networks, private networks are in scope? It needs to be clarified.
KPN: it should be studied in the context of IOPS, consider what has been done there. Thales supported this, adding that SA1 and SA2 should be involved first.
Lenovo: disaster roaming work in SA2 could be related.
Dell: these are solid requirements that are worth working on.
The Chair commented that these were new scenarios to be taken into account firstly in SA1, currently out of scope of SA3.
| noted | No | ||||
S3‑234517 | New SID on study on enabling a cryptographic algorithm transition to 256 bits | KDDI Corporation | SID new | Approval | Yes |
YesApple supported this SID. Maybe no impact on the RAN interface but on the products.
| revised | No | S3‑235091 | |||
S3‑235091 | New SID on study on enabling a cryptographic algorithm transition to 256 bits | KDDI Corporation | SID new | Approval | Yes |
Yes
| agreed | No | S3‑234517 | |||
S3‑234518 | Discussion paper on transition to 256-bit cryptographic algorithms | KDDI Corporation | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑234533 | New mini WID on AKMA service disabling | Nokia, Nokia Shanghai Bell, ZTE, ChinaMobile | WID new | Agreement | Yes |
Yes
| noted | No | ||||
S3‑234546 | Discussion on AKMA privacy issue | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
YesHuawei didn’t think this was correct.
| noted | No | ||||
S3‑234558 | Discussion paper on certificate bound access token in SBA OAuth framework | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
YesSupported by Ericsson.They proposed to add it to the SBA study.MITRE supported this as well.
It was agreed that this was acceptable and Nokia was invited to bring a concrete WID or proposal for the next meeting.
| noted | No | ||||
S3‑234563 | New SID on security enhancement for mobility over non-3GPP access to avoid full primary authentication | Nokia, Nokia Shanghai Bell, CableLabs, Charter Communications, Broadcom, Lenovo, Xiaomi, ChinaMobile, Google, ZTE, Apple Keysight Technologies, LGE, Rogers Communications, Philips International B.V., IIT Delhi, Intel Corporation (UK) Ltd | SID new | Approval | Yes |
YesORANGE: what is the delay described here? What’s the gain? The justification is not enough for me.
Qualcomm: lot of new scenarios. They didn’t see the need for this SID.
Lenovo supported the SID.
| revised | No | S3‑235105 | |||
S3‑235105 | New SID on security enhancement for mobility over non-3GPP access to avoid full primary authentication | Nokia, Nokia Shanghai Bell, CableLabs, Charter Communications, Broadcom, Lenovo, Xiaomi, ChinaMobile, Google, ZTE, Apple Keysight Technologies, LGE, Rogers Communications, Philips International B.V., IIT Delhi, Intel Corporation (UK) Ltd | SID new | Approval | No |
Yes
| agreed | No | S3‑234563 | |||
S3‑234567 | Discussion on R19 priorities | MITRE Corporation | discussion | Discussion | Yes |
Yes
| withdrawn | Yes | ||||
S3‑234981 | Discussion on R19 priorities | MITRE Corporation | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234569 | NIST Post Quantum Cryptography Update | NIST | discussion | Information | Yes |
Yes
| noted | No | ||||
S3‑234576 | Discussion paper supporting Rel-19 study on enablers for Zero Trust Security | Johns Hopkins University APL | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234578 | New SID on application login via IMS | China Telecom Corporation Ltd. | SID new | Agreement | Yes |
YesORANGE: you need to go to SA1 first.
Google supported this SID.
Nokia didn’t support it.
| noted | No | ||||
S3‑234579 | Discussion paper on application login via IMS | China Telecom Corporation Ltd. | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234601 | Discussions for R19 security enhancement of network slicing | Huawei, HiSilicon | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234602 | R19 SID on security enhancement of network slicng | Huawei, HiSilicon | SID new | Approval | Yes |
YesEricsson: this is not needed.
Google: clarification on how this will be used is needed.
Nokia: concerns on WT2.
| noted | No | ||||
S3‑234603 | Discussions for R19 UAS security | Huawei, HiSilicon | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234604 | R19 SID on UAS security enhancement | Huawei, HiSilicon | SID new | Approval | Yes |
Yes
| noted | No | ||||
S3‑234623 | Discussion on Mitigations on Bidding Down Attack | Huawei, HiSilicon, Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234624 | New study proposal on Mitigations on Bidding Down Attack | Huawei, HiSilicon, Nokia, Nokia Shanghai Bell | SID new | Approval | Yes |
YesCableLabs: there isn't much we can do about mittigating the bidding down attacks.
Nokia: restrict to decomission of 2G and 3G base stations, we have other comments but we support the study.
GSMA: in Rel-15 we decided to allow backwards compatibility with 3G. We deliberately chose to allow this, so I'm not convinced to come back to this. However, we think this must be avoided in 6G. Not much can be done in 5G but definitely something to avoid in 6G.
Apple: impact only on UE. We don’t need WT1.1 and WT1.2.
ORANGE: on the impact we usually write "don’t know".
| revised | No | S3‑235096 | |||
S3‑235096 | New study proposal on Mitigations on Bidding Down Attack | Huawei, HiSilicon, Nokia, Nokia Shanghai Bell | SID new | Approval | Yes |
Yes
| agreed | No | S3‑234624 | |||
S3‑234634 | Discussion on NEF–AF Exposure Security Enhancement | Huawei, HiSilicon | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234635 | New SID on 5G Security Enhancement for NEF | Huawei, HiSilicon | SID new | Approval | Yes |
YesEricsson: we support this because we had a similar proposal (tdoc 4774). We need clear definitions and clear assumptions.
Lenovo: objectives and justification need to be refined.
| noted | No | ||||
S3‑234657 | Discussion on key misalignment | Huawei, HiSilicon | discussion | Endorsement | Yes |
Yes
| noted | No | ||||
S3‑234668 | SERP-revised WID for R19 SERP | Apple | WID new | Approval | Yes |
YesQualcomm: we spent long time on this, we don’t agree.
Ericsson supported the WID.
| noted | No | ||||
S3‑234672 | SERP-Discussion paper on SERP feature summary | Apple | discussion | Information | Yes |
Yes
| noted | No | ||||
S3‑234673 | SERP-LS on security protection on RRCResumeRequest message | Apple | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234678 | New SID on Security Enhancements for URSP in Roaming Scenarios | Lenovo, Nokia, Nokia Shanghai Bell, Philips, Intel, Interdigital | SID new | Approval | Yes |
YesGoogle: is this a problem that the operators are facing? Not sure we are solving the problem of misbehaving VPLMNs.
NTT-Docomo: if we don’t trust the VPLMN we are in a much bigger problem that we are considering here.
| noted | No | ||||
S3‑234679 | New SID on Double Layer Security Optimization | Lenovo, BROADCOM CORPORATION, CableLabs, CATT, Charter Communications, Inc, China Mobile, CISCO, Deutsche Telekom, InterDigital, Inc., LG Electronics, Nokia, Tencent, vivo Mobile Communication Co., Xiaomi, ZTE Corporation | SID new | Approval | Yes |
YesWrong WID template used.
It was commented that this needed to have further analysis on the Impact on the UPF.
| noted | No | ||||
S3‑235092 | New SID on Double Layer Security Optimization | Lenovo, BROADCOM CORPORATION, CableLabs, CATT, Charter Communications, Inc, China Mobile, CISCO, Deutsche Telekom, InterDigital, Inc., LG Electronics, Nokia, Tencent, vivo Mobile Communication Co., Xiaomi, ZTE Corporation | SID new | Approval | No |
Yes
| noted | No | ||||
S3‑234689 | Discussion on the A-KID update after UPU | ZTE Corporation. | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234681 | New WID on Milenage-256 algorithm | THALES, Idemia, NIST, ORANGE, Nokia, Telecom Italia | WID new | Agreement | Yes |
YesEricsson: we believe that these specifications should be made publicly available, no license required.
Qualcomm: there may be some encryption here, not only authentication. Not clear that this should be made public.
| revised | No | S3‑235072 | |||
S3‑235072 | New WID on Milenage-256 algorithm | THALES, Idemia, NIST, ORANGE, Nokia, Telecom Italia | WID new | Agreement | Yes |
Yes
| agreed | No | S3‑234681 | |||
S3‑234690 | Study on privacy aspects of collection and sharing management data | Nokia, Nokia Shanghai Bell, IIT Delhi, Interdigital, Lenovo, AT&T, CMCC, Apple | SID new | Yes |
YesCOMCAST provided inputs for Nokia. They supported the SID.
Apple: not sure about impact on UICC.
Huawei: not clear enough. It may be purely OAM. The TU may not be enough for these topics. Not sure about the protection of the interfaces.
NTT-Docomo: super set of the radio identity privacy study? The number of TU doesn’t reflect the amount of work required for this. It’s very complex.
| noted | No | |||||
S3‑235093 | Study on privacy aspects of collection and sharing management data | Nokia, Nokia Shanghai Bell, IIT Delhi, Interdigital, Lenovo, AT&T, CMCC, Apple | SID new | - | No |
Yes
| withdrawn | Yes | ||||
S3‑234691 | New mini WID on AKMA identifier update | ZTE Corporation. | WID new | Approval | Yes |
Yes
| noted | No | ||||
S3‑234725 | New WID on 3GPP profiles for cryptographic algorithms and security protocols | Ericsson | WID new | Agreement | Yes |
YesCable Labs, Apple supported this WID.
Qualcomm: remove the last paragraph of the objectives.
Huawei: There is no rush for this. GBA not related to crypto maintenance, it can be dealt with a mini WID. This is a new feature. It would also be nice to see what is going to be changed. It looks like speculation now.
Deutsche Telekom supported this WID.
Ericsson commented that the CRs were brought in Berlin and it was asked to bring a WID.
NTT-Docomo supported having this as early as possible.
| revised | No | S3‑235094 | |||
S3‑235094 | New WID on 3GPP profiles for cryptographic algorithms and security protocols | Ericsson | WID new | Agreement | Yes |
YesNTT-Docomo: pleae bring CRs early because there is a lot of background to be done.
| agreed | No | S3‑234725 | |||
S3‑234726 | Study on enhanced Security Aspects of the 5G Service Based Architecture Phase 2 | Ericsson, Deutsche Telekom, Verizon, ZTE, China Telecom | SID new | Agreement | Yes |
YesCable Labs: we don’t need a study for this, it can be done with a WID and CRs.
Nokia: most of the text here is providing solutions, the study is not needed.
Huawei: we don’t mind having a study. Avoid reopening issues that were not agreed.
CableLabs: make it a WID, nthing to study here.
| noted | No | ||||
S3‑235097 | Study on enhanced Security Aspects of the 5G Service Based Architecture Phase 2 | Ericsson, Deutsche Telekom, Verizon, ZTE, China Telecom | SID new | Agreement | No |
Yes
| withdrawn | Yes | ||||
S3‑234740 | Discussion on Security Management Serives Study | China Mobile | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234741 | New SID on security management service | China Mobile | SID new | Approval | No |
Yes
| revised | No | S3‑234773 | |||
S3‑234742 | New SID on Study on security aspects of AIML enhancements | China Mobile | SID new | Approval | No |
Yes
| revised | No | S3‑234805 | |||
S3‑234743 | Discussion on security for XR | China Mobile | discussion | Discussion | No |
Yes
| revised | No | S3‑234791 | |||
S3‑234744 | New SID on security for XR services | China Mobile | SID new | Approval | No |
Yes
| revised | No | S3‑234804 | |||
S3‑234750 | New SID on security support for next generation real time communication services Phase 2 | China Mobile | SID new | Approval | No |
Yes
| revised | No | S3‑234806 | |||
S3‑234773 | New SID on security management service | China Mobile, ZTE, Nokia, Nokia Shanghai Bell, CATT, CableLabs, China Telecom | SID new | Approval | Yes |
YesAdrian (MITRE): a lot of overlap with topics like Zero Trust.
OPPO wanted to be added as supporting company.
NTT-Docomo: I don’t understand the outcome of this SID.
| noted | No | S3‑234741 | |||
S3‑234774 | New SID on NEF - AF Exposure security enhancements | Ericsson | SID new | Agreement | Yes |
Yes
| noted | No | ||||
S3‑234803 | Proposal for a living document for the Protection of the RRC Resume Request message | Ericsson, Apple | draftCR | Approval | Yes |
Yes
| noted | No | ||||
S3‑234873 | SID on Security considerations for 5G SA roaming | Nokia, Nokia Shanghai Bell | SID new | Agreement | Yes |
YesNTT-Docomo: address it as a one shot SID.
Verizon supported this SID.
Huawei: we can take this a bit later, we cannot commit to study this topic in this meeting.
Cable Labs: support hop by hop and end to end, they are not mutually esclusive.
| noted | No | ||||
S3‑234874 | SID on 5G Security Assurance Specification (SCAS) for the Cloud Native Products (CNP) | Ericsson | SID new | Agreement | Yes |
YesNokia found this very challenging.
Huawei didn’t agree with this SID.They wondered: can current specs be reused to test this product? Too broad, cloud native is not defined in 3GPP.
GSMA: ITU-T SG17 has started work on this, ISO will do so as well. 3GPP is taking the risk of missing something that will likely be mandatory in Europe.There is a gap that we keep failing to fill.
NTT-Docomo: in TS 33.117 we had opposition against issues like password use that proved to be useful. We need test cases for issues we see in actualy deployments.
| noted | No | ||||
S3‑234876 | discussion on resource isolation enforcement for application in 5G network | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| noted | No | S3ah‑230020 | |||
S3‑234877 | Study on resource isolation enforcement for application in 5G network | Nokia, Nokia Shanghai Bell, U.S. National Security Agency, NIST, CableLabs, China Telecommunications, Google | SID new | Agreement | Yes |
YesORANGE didn’t have the scope very clear.
| noted | No | S3ah‑230021 | |||
S3‑235095 | Study on resource isolation enforcement for application in 5G network | Nokia, Nokia Shanghai Bell, U.S. National Security Agency, NIST, CableLabs, China Telecommunications, Google | SID new | Agreement | Yes |
Yes
| withdrawn | Yes | ||||
6.3 | SID/WID proposals for feature security dependent on other WGs | S3‑234406 | New WID on mission critical security enhancements for release 19 | Motorola Solutions Germany | WID new | Agreement | Yes |
Yes
| revised | No | S3‑234946 | |
S3‑234503 | Modified PRINS for roaming service providers in 5G | Verizon UK Ltd | WID revised | Approval | Yes |
Yes
| agreed | No | SP‑231190 | |||
S3‑234508 | New SID on security aspects of Usage of User Identifiers in the 5G System | InterDigital Finland Oy | SID new | Approval | Yes |
Yes
| not treated | No | ||||
S3‑234559 | New SID on security aspects for Multi-Access | Nokia, Nokia Shanghai Bell, ZTE Corporation, China Telecom, OPPO, China Unicom, CATT, CableLabs, Lenovo | SID new | Information | Yes |
Yes
| not treated | No | ||||
S3‑234570 | Study on Security Aspects of 5G Satellite Access Phase 2 | CATT, Nokia, Xiaomi, CAICT, China Mobile, China Unicom, ZTE, Deutsche Telekom, Thales, China Telecommunications, Samsung, Sectra Communications | SID new | Approval | Yes |
YesEricsson: no satellite representatives in SA3, although they are present in other WGs like SA2 and RAN2. We need to requrest to them their participation since I don't see them in the supporting companies.
Spoofing, jamming still apply to satellite and should be included. If we study these things here, will the satellite stakeholders will implement our solutions to prevent those? Otherwise there will be much effort for something that will never see the daylight. The Chait was concerned that these new issues would utilise many more TU.
Interdigital: send an LS to SA2,RAN to ask for satellite stakeholders' assistance. Ericsson supported this.
| revised | No | S3‑235103 | |||
S3‑235103 | Study on Security Aspects of 5G Satellite Access Phase 2 | CATT, Nokia, Xiaomi, CAICT, China Mobile, China Unicom, ZTE, Deutsche Telekom, Thales, China Telecommunications, Samsung, Sectra Communications | SID new | Approval | Yes |
Yes
| agreed | No | S3‑234570 | |||
S3‑234573 | Discussion on security for PLMN hosting a NPN | China Telecommunications | discussion | Discussion | Yes |
Yes
| noted | No | ||||
S3‑234574 | New SID on security for PLMN hosting a NPN | China Telecommunications, CableLabs, ZTE, CATT, China Unicom, Apple, China Mobile, Oppo, Lenovo | SID new | Approval | Yes |
YesSamsung: this is considering the core network?
CableLabs: we are not considering the radio network.
MITRE: PLMN may be a threat to the private network as well. It should be looked at.
ORANGE: I don’t understand the justification and whether there are other WGs involved.
| revised | No | S3‑235087 | |||
S3‑235087 | New SID on security for PLMN hosting a NPN | China Telecommunications, CableLabs, ZTE, CATT, China Unicom, Apple, China Mobile, Oppo, Lenovo | SID new | Approval | Yes |
Yes
| agreed | No | S3‑234574 | |||
S3‑234663 | Discussion on Security Aspects on Ambient IoT Service | Huawei, HiSilicon | discussion | Approval | Yes |
Yes
| noted | No | ||||
S3‑234671 | New WID on MASSS security | Apple | SID new | Discussion | No |
Yes
| withdrawn | Yes | ||||
S3‑234677 | New SID on Security Aspects of Indirect Network Sharing | China Unicom | SID new | Approval | Yes |
YesEricsson: let SA2 the work and they will contact us if there is any help from SA3 needed.
MITRE: is there any rush to address this? It is being addressed there as TEI19 work.
| noted | No | ||||
S3‑234695 | New SID on Study on Security Aspects of Enhancement for Proximity Based Services in 5GS Phase 3 | CATT | SID new | Approval | Yes |
Yes
| noted | No | ||||
S3‑234697 | Discussion on security for LTM | OPPO | discussion | Discussion | Yes |
Yes
| not treated | No | ||||
S3‑234763 | New_SID_EdgeComputing | Huawei, HiSilicon | SID new | Approval | Yes |
Yes
| not treated | No | ||||
S3‑234765 | Dummy WID for Authentication result removal | Huawei, HiSilicon | WID new | Approval | Yes |
Yes
| noted | No | ||||
S3‑234791 | Discussion on security for XR | China Mobile | discussion | Discussion | Yes |
Yes
| noted | No | S3‑234743 | |||
S3‑234802 | New SID on the security support for the Next Generation Real Time Communication services Phase 2 | Ericsson | SID new | Agreement | Yes |
YesCabkeLabs: the first objective is not needed if we read the justification.
Huawei: we prefer the CMCC version.
MITRE: confused with the justification and objectives. Are we starting IMS 3rd party security from scratch? Ericsson agreed to change the justification to clarify that it wouldn’t be needed.
Nokia preferred Ericsson's version with an update on the justification.
| revised | No | S3‑235085 | |||
S3‑235085 | New SID on the security support for the Next Generation Real Time Communication services Phase 2 | Ericsson | SID new | Agreement | Yes |
Yes
| agreed | No | S3‑234802 | |||
S3‑234804 | New SID on security for XR services | China Mobile | SID new | Approval | Yes |
Yes
| noted | No | S3‑234744 | |||
S3‑234805 | New SID on Study on security aspects of AIML enhancements | China Mobile, Interdigital, AT&T, Apple, Xiaomi, Oppo, Lenovo, Philips, ZTE | SID new | Approval | Yes |
Yes
| not treated | No | S3‑234742 | |||
S3‑234806 | New SID on security support for next generation real time communication services Phase 2 | China Mobile | SID new | Approval | Yes |
Yes
| merged | No | S3‑235085 | S3‑234750 | ||
S3‑234809 | Discussion paper on security aspects of 5G support for Femto (HgNB) | Nokia, Nokia Shanghai Bell | discussion | Discussion | Yes |
Yes
| not treated | No | ||||
S3‑234810 | Study on Security Aspect of Ambient IoT Services in 5G | OPPO, Cable Labs, Apple, ZTE, Xiaomi, Verizon, Intel, T-Mobile USA, Philips International B.V., China Telecom, Lenovo, Xidian, BUPT, Vivo, China Unicom, Inter Digital, KPN, Huawei, HiSilicon, CATR, CATT, Samsung, China Mobile | SID new | Approval | Yes |
YesHuawei: SA3 is caught in negotiations between other WGs and it is creating a heavy burden for us.
The Chair commented that approving all SIDs and WIDs by March would delay the work in SA3, that's why it was being prioritised to have WIDs and SIDs that were approved already in other WGs.
NTT-Docomo: the TU may not be accurate; in case that there are massive changes in architecture in SA2 it would cause an increase of the work in SA3. Make it clear in SA the kind of impact we may have.
Huawei: this is a good example where SA3 wouldn’t want to be the bottleneck. We need to send the message to Plenary.
Qualcomm: we can start doing this now. MITRE supported Qualcomm.
NTT-Docomo: reserve an agenda item for next meeting to discuss this stuff.
Huawei asked to be minuted: "Huawei has concerns on postponing these studies which in our view will require considerable work. Based on the current schedule, by postponing the agreement on the topic we are delaying the work by half a year. "
| noted | No | ||||
S3‑235088 | Study on Security Aspect of Ambient IoT Services in 5G | OPPO, Cable Labs, Apple, ZTE, Xiaomi, Verizon, Intel, T-Mobile USA, Philips International B.V., China Telecom, Lenovo, Xidian, BUPT, Vivo, China Unicom, Inter Digital, KPN, Huawei, HiSilicon, CATR, CATT, Samsung, China Mobile | SID new | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑234834 | Discussion on study for security aspects of 5G Mobile Metaverse | Samsung | discussion | Discussion | Yes |
Yes
| not treated | No | ||||
S3‑234835 | New SID on security aspects of 5G Mobile Metaverse services | Samsung, Nokia, Nokia Shanghai Bell, Lenovo, OPPO | SID new | Approval | Yes |
YesInterdigital: remove WT1 as there is overlapping work in SA2.
NTT-Docomo: the TU estimation is not achievable, this is massive work.
Huawei: objectives related to SA6 are not clear.
Philips: we agree that this requires much more work than predicted in the TU here.
| noted | No | ||||
S3‑235086 | New SID on security aspects of 5G Mobile Metaverse services | Samsung, Nokia, Nokia Shanghai Bell, Lenovo, OPPO | SID new | Approval | No |
Yes
| withdrawn | Yes | ||||
S3‑234860 | New SID on 5GS enhancements for Energy Saving | Nokia, Nokia Shanghai Bell, Telecom Italia, OPPO | SID new | Approval | Yes |
YesHuawei: we did a study on the user consent already. We don’t understand the relation here.
Google: we don’t know at this point whether user consent will be an issue, we want to keep it here.
AT&T: we addressed user consent for the network, we don’t need to include it here.
NTT-Docomo: no urgency for this WID.
NTT-Docomo: user consent is a potential solution. We don’t want to exclude it.
Huawei: user consent is part of the privacy. It is in scope because it's part of the privacy. If the solution requires user consent there is nothing in the WID that prevents from writing that in the spec.
Google: user consent is not excluded, it needs to be evaluated. This was agreed to have it minuted as proposed by Google.
Ericsson: the first three objectives are not clear. What is the difference between them?
| revised | No | S3‑235084 | |||
S3‑235084 | New SID on 5GS enhancements for Energy Saving | Nokia, Nokia Shanghai Bell, Telecom Italia, OPPO | SID new | Approval | Yes |
Yes
| agreed | No | S3‑234860 | |||
S3‑234914 | New SID on security aspects of Integrated Sensing and Communication | Xiaomi, OPPO, China Telecom, Apple, ZTE, Lenovo, vivo, Cable Labs, Huawei, HiSilicon, Intel | SID new | Approval | Yes |
Yes
| noted | No | ||||
S3‑234946 | New WID on mission critical security enhancements for release 19 | Motorola Solutions Germany | WID new | Agreement | Yes |
Yes
| revised | No | S3‑235057 | S3‑234406 | ||
S3‑235057 | New WID on mission critical security enhancements for release 19 | Motorola Solutions Germany | WID new | Agreement | Yes |
YesAdding Nokia and Samsung.
| agreed | No | S3‑234946 | |||
7 | CVD and research | S3‑234464 | CVD-2023-0075 - Certificate validation on IMS access interface | GSMA | LS in | Yes |
YesPostponed to bring a CR to address this LS.
GSMA commented that there was an effort to involve researchers in the standardization work, and there may be a feeling that 3GPP is not interested in addressing these issues. Alex asked the SA3 delegates to take these CVDs seriously and address them properly.
| postponed | No | |||
S3‑234465 | Invalid Curve Attack on the 5G SUCI Privacy | GSMA | LS in | Yes |
YesAddressed in SCAS already.
| noted | No | |||||
S3‑234466 | CVD-2023-0069 - 5G Core Network Attacks | GSMA | LS in | Yes |
Yes
| postponed | No | |||||
S3‑234607 | reply to GSMA CVD (5G Core Network Attacks) | Huawei, HiSilicon | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234869 | LS-reply to CVD-2023-0069 - 5G Core Network Attacks | Nokia, Nokia Shanghai Bell | LS out | Approval | Yes |
Yes
| noted | No | ||||
S3‑234608 | Clarification on SBI service request procedures | Huawei, HiSilicon | CR | Agreement | Yes |
YesNokia had an alternate proposal in 4871.
| not pursued | No | ||||
S3‑234609 | Clarification on SBI service request procedures | Huawei, HiSilicon | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234870 | CVD-0069 Cross check on NF discovery request | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234871 | CVD-0069 Condition of including allowed sNSSAIs in access token | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
S3‑234872 | CVD-0069 Access token validity time | Nokia, Nokia Shanghai Bell | CR | Agreement | Yes |
Yes
| not pursued | No | ||||
8 | Any Other Business | S3‑234404 | SA3 meeting calendar | SA WG3 Chair | other | Yes |
YesProposed to have an adhoc meeting with decision power on SCAS in January. SCAS will still be in the agenda in the Athens meeting.
It was agreed to have the Adhoc meeting on SCAS for 22 - 26 January 2024.
Possibility of adhoc in June or July?
OPPO: have a f2f meeting in April Key issues are very hard to discuss electronically. NTT-Docomo supported that.
Nokia: emeeting in April for us. We can learn from experience and be more efficient.
Thales: we have learnt that emeetings don’t work. F2f meetings can be hybrid.
Interdigital: emeetings don’t work at all in some areas.F2F is the best way for making progress.
The Chair commented that he got feedback from other companies asking for not having more f2f meetings.
AT&T: make it an online wokrshop or whatever necessary to make progress.
Philips supported the emeeting for April.
The Chair noted the feedback.
| noted | No |