3GPP TSG CT WG1 Meeting#122	C1-200203

Electronic meeting, 20-28 February 2020

Meeting documents by agenda item Meeting: Meeting #122-e Electronic meeting 20 - 28 February 2020 All indicated times are CET
Cyan background means allocated but not available.	Yellow background means available but not yet treated document.	Green background means this document was agreed at a revious meeting in this plenary cycle.	White background means that the document has been handled in the meeting and a decision has been made.
Additional Colour coding for Tdocs in the 1st row
Late Papers
Easy and uncontroversial papers – can be presented within 2 minutes
Papers for common sessions
Low Priority
Agenda item	Agenda item title	Tdoc	Title	Source	Spec	Result
Opening & welcome	Tdoc	Title	Source	Spec	Result
IPR Policy Reminder to Individual Members and the persons making the technical proposals about their obligations under their respective Organizational Partners IPR Policy: I draw your attention to your obligations under the 3GPP Partner Organizations' IPR policies. Every Individual Member organization is obliged to declare to the Partner Organization or Organizations of which it is a member any IPR owned by the Individual Member or any other organization which is or is likely to become essential to the work of 3GPP.
Antitrust & Competition I also draw your attention to the fact that 3GPP activities are subject to all applicable antitrust and competition laws and that compliance with said laws is therefore required of any participant of this TSG/WG meeting including the Chairman and Vice Chairman. In case of question I recommend that you contact your legal counsel. The leadership shall conduct the present meeting with impartiality and in the interests of 3GPP. Furthermore, I would like to remind you that timely submission of work items in advance of TSG/WG meetings is important to allow for full and fair consideration of such matters.
Usage if WiFi During 3GPP meetings, IT support staff have noticed an increasing amount of RF pollution from private, ad hoc, wireless networks (Wi-Fi Direct, hot-spots hosted on mobile phones, …), and this gives rise to reduced throughput capability of the 3GPP WLAN. I would like to remind delegates to disable all such non-3GPP Wi-Fi networks while they are in the meeting rooms or adjacent areas. This will allow the quality of connection to the 3GPP Wi-Fi network which delegates have a right to expect.
Statement Regarding Engagement with Companies Added to the U.S. Export Administration Regulations (EAR) Entity List in 3GPP Activities 1. Public Information is Not Subject to EAR 3GPP is an open platform where all contributions (including technology protected or not by patent) made by the different Individual Members under the membership of each respective Organizational Partner are publicly available. Indeed, contributions by all and any Individual Members are uploaded to a public file server when received and then the documents are effectively in the public domain. In addition, since membership of email distribution lists is open to all, documents and emails distributed by that means are considered to be publicly available. As a result, information contained in 3GPP contributions, documents, and emails distributed at 3GPP meetings or by 3GPP email distribution lists, because it is made available to the public without restrictions upon its further dissemination, is not subject to the export restrictions of the EAR. Meeting minutes are maintained for 3GPP meetings. Such meeting minutes for 3GPP meetings are made available to the public without restrictions upon its further dissemination. As a result, information, including information conveyed orally, contained in 3GPP meetings is not subject to the export restriction of the EAR; this would include information conveyed during side meetings that may occur during the main meetings, if these meetings are open to any participants and the results of all said meetings are publicly available without restrictions upon their further dissemination. 2. Non-Public Information Non-public information refers to the information not contained or not intended to be contained in 3GPP contributions, documents or emails. Such non-public information may be disclosed during informal meetings, exchanges, discussions or any form of other communication outside the 3GPP meetings and email distribution lists, and may be subject to the EAR. 3. Other Information Certain encryption software controlled under the International Traffic in Arms Regulations (ITAR), even if publicly available, may still be subject to US export controls other than the EAR. 4. Conduct of Meetings The situation should be considered as "business as usual" during all the meetings called by 3GPP. 5. Responsibility of Individual Members It should be remembered that contributions, meetings, exchanges, discussions or any form of other communication in or outside the 3GPP meetings are of the accountability, integrity and the responsibility of each Individual Member. In addition, Individual Members remain responsible for ensuring their compliance with all applicable export control regulations, including but not limited to EAR. Individual Members with questions regarding the impact of laws and regulations on their participation in 3GPP should contact their companies’ legal counsels.
Please remember: - to perform the electronic registration before end-of-meeting - to wear your badge
Agenda & Reports	Tdoc	Title	Source	Doctype	Result & comments
C1-200275	3GPP TSG CT1#122 – agenda after Tdoc allocation deadline	CT1 chairman	agenda	Revision of C1-200200
C1-200201	3GPP TSG CT1#122 – agenda after Tdoc allocation deadline	CT1 chairman	agenda
C1-200202	3GPP TSG CT1#122 – agenda with proposed LS-actions	CT1 chairman	agenda
C1-200203	3GPP TSG CT1#122 – agenda at start of meeting	CT1 chairman	agenda
C1-200204	3GPP TSG CT1#122 – agenda Thursday (27th Feb) evening	CT1 chairman	agenda
C1-200205	3GPP TSG CT1#122 – agenda at end of meeting	CT1 chairman	agenda
C1-200307	draft C1-121 meeting report	MCC	report
Highest number shown in the 0775
Agenda 1 Opening 2 Agenda and Reports 3 work organization 4 incoming LS Rel-16 Rel-16: 16.1.x Work items (4) 16.2.3 SAES16 (all aspects) (0) only revisions of CRs agreed in CT1#121bis-e and disc papers supporting LSs 16.2.4 5GProtoc16 (all aspects) (5) only revisions of CRs agreed in CT1#121bis-e and disc papers supporting LSs 16.2.21 Rel-16 non-IMS issues (0) only revisions of CRs agreed in CT1#121bis-e and disc papers supporting LSs Agenda Items from 16.2 16.2.2 SINE_5G (4) 16.2.5 ATSSS (28) 16.2.6 eNS (51) 16.2.7.x vertical-LAN (79) 16.2.8 5G_CIoT (44) 16.2.9 5WWC (25) 16.2.11 5G_eLCS (2) 16.2.14 RACS (16) 16.2.15 5G_SRVCC (2) 16.2.16 xBDT (0) 16.2.17 IAB-CT (0) 16.2.18 5GS_OTAF (0) 16.2.19 5G_URLLC (2) 16.2.20 SEAL (51) 16.2.1 ePWS (5) 16.2.10 PARLOS (7) 16.2.12 V2XAPP (13) 16.2.13 eV2XARC (35) Agenda Items from 16.3 16.3.1 MCCI_CT (7) 16.3.2 MCProtoc16 (5) 16.3.5 MCSMI_CT (0) 16.3.6 eMCDATA2 (19) 16.3.10 MONASTERY2 (8) 16.3.12 enh2MCPTT-CT (9) 16.3.3 MuD (15) 16.3.4 IMSProtoc16 (3) 16.3.7 E2E_DELAY (0) 16.3.8 VBCLTE (0) 16.3.11 eIMS5G_SBA (1) 16.3.13 eIMSVideo (8) 16.3.14 IMS/MC TEI16 (3) 18 outgoing LS Rel-16
Work organisation	Tdoc	Title	Source	To / CC	Result & comments
Meeting schedule
CT1 and CT plenary meeting dates.
Date	Meeting	Venue
13 – 17 January	CT1-Potential Ad-Hoc	cancelled
16 – 22 January	CT1#121bis-e	Electronic Meeting
24 – 28 February	CT1#122	cancelled
20 – 28 February	CT1#122-e	Electronic Meeting
16 – 17 March 2020	CT plenary #87	Jeju, Korea
20 – 24 April	CT1#123	Dubrovnik, Croatia
25 – 29 May	CT1#124	Dalian, China
15 – 16 June 2020	CT plenary #88	Malmö, Sweden
13 – 17 July	CT1-Potential Ad-Hoc	TBD
24 – 28 August	CT1#125	US
14 – 15 September 2020	CT plenary #89	Funchal, Madeira
12 – 16 October	CT1#126	India
16 – 20 November	CT1#127	US
7 – 8 December 2020	CT plenary #90	NAF
25 – 29 January 2021	CT1#127bis	tbd
01- 05 March 2021	CT1#128	tbd
22 – 23 March 2021	CT plenary #91	US
19 – 23 April 2021	CT1#129	tbd
24 – 28 May 2021	CT1#130	tbd
14 – 15 June 2021	CT plenary #91	Japan
Work Plan and other adm. issues	Tdoc	Title	Source	Spec / doctype	Result & comments
C1-200306	work plan	MCC	Work Plan
C1-200312	CT1#122-e Electronic Meeting – Process and Scope	CT1 chairman	other
Input Liaison statements	Tdoc	Title	Source	To / CC	Result & comments
C1-200206	LS on usage of IMSI during 3GPP based authentication (C4-195574)	CT4	Cc	Proposed Noted
C1-200207	LS on user identity when 5G-AKA or EAP AKA’ is used for SNPN (C6-190468)	CT6	To	Proposed Noted SA3 reply in C1-200255
C1-200208	LS on Proposal to transfer the study on service-based support for SMS in 5GC to CT WGs (CP-193301)	TSG CT	Cc	Postponed LS pertains to Rel-17
C1-200209	Reply LS to Transfer the study on service-based support for SMS in 5GC to CT WGs (SP-191362)	TSG SA	Cc	Postponed LS pertains to Rel-17
C1-200210	Response to 3GPP S2-1910806 and S2-1912767 on Line ID (LIAISE-353)	Broadband Forum	To	Proposed Noted SA2 has already handled the incoming LS
C1-200211	General Status of Work (LIAISE-363à	Broadband Forum	To	Proposed tbd Reply needed Proposed LS out in C1-200309
C1-200212	LS on Testing and Certification of 3GPP Mission Critical features A GCF-TCCA Joint Approach to Develop and Manage MC Certification (	TCCA	Cc	Proposed Noted
C1-200213	Reply LS on QoE Measurement Collection (R2-1916328)	RAN2	Cc	Proposed Noted
C1-200214	Reply LS on NID structure and length (R2-1916344)	RAN2	Cc	Proposed Noted Related CR in C1-200334
C1-200215	CMAS/ETWS and emergency services for SNPNs (R2-1916345)	RAN2	Cc	Proposed Noted
C1-200216	Reply LS on Sending CAG ID in NAS layer (R2-1916349)	RAN2	Cc	Proposed Noted Related DP in C1-200335 and CR in C1-200337
C1-200217	Reply LS on Mobile-terminated Early Data Transmission (R2-1916368)	RAN2	To	Proposed tbd Proposed LS out in C1-200707 CR in C1-200368
C1-200218	Reply LS on assistance indication for WUS (R2-1916440)	RAN2	To	Proposed Noted Seems no reply needed
C1-200219	Reply LS on PC5S and PC5 RRC unicast message protection (R2-1916461)	RAN2	Cc	Proposed Noted
C1-200220	LS on dependencies on AS design for mobility management aspects of NTN in 5GS (R2-1916470)	RAN2	Cc	Proposed Noted C1-200220 from RAN2 and C1-200269 from RAN3 are both replies to the same LS from SA2 (S2-1910786)
C1-200221	LS on RRC establishment cause value in EPS voice fallback from NR to E-UTRAN (R2-1916530)	RAN2	To	Proposed tbd TEI16, potentially changes to 24.301 needed Proposed LS out in C1-200710
C1-200222	LS on inter-RAT HO from SA to EN-DC (R2-1916600)	RAN2	Cc	Proposed Noted
C1-200223	LS on LS on system level design assumptions for satellite in 5GS (R2-1916620)	RAN2	Cc	Proposed Noted C1-200223 from RAN2 and C1-200269 from RAN3 are both replies to the same LS from SA2 (S2-1910787)
C1-200224	Reply LS on extended NAS timers for CE in 5GS (R2-1916623)	RAN2	To	Proposed tbd Proposed LS out in C1-200717 Related CRs in C1-200383 - C1-200384
C1-200225	Reply LS on Sending CAG ID in NAS layer (R3-197591)	RAN3	Cc	Proposed Noted Related DP in C1-200335 and CR in C1-200337
C1-200226	LS on Concurrent Broadcasting for CMAS (R3-197749)	RAN3	To	Postponed LS pertains to Rel-15 Proposed LS out in C1-200764
C1-200227	Reply LS on UAC for NB-IOT (S1-193592)	SA1	Cc	Proposed Noted Is related at least to CRs in C1-200397, C1-200421, C1-200677
C1-200228	Reply LS on enhanced access control for IMS signalling (S1-193595)	SA1	To	Proposed Noted No action in the LS
C1-200229	Reply LS on NSI requirements (S1-193596)	SA1	Cc	Proposed Noted
C1-200230	Reply LS on LS on PC5S and PC5 RRC unicast message protection (S2-1912002)	SA2	Cc	Proposed Noted Related CR in C1-200349
C1-200231	Reply LS on Enquiries on eV2XARC (S2-1912018)	SA2	To	Proposed Noted Related pCR in C1-200391 Related CR in C1-200349
C1-200232	Reply LS on SUCI computation from an NSI (S2-1912417)	SA2	To	Proposed Noted Are CRs available to this meeting?
C1-200233	LS on PLMN selection solutions for satellite access (S2-1912551)	SA2	To	Postponed LS pertains to Rel-17 (FS_5GSAT_ARCH) although header of the LS incorrectly indicates Rel-16
C1-200234	Reply LS on applicability of the notification procedure in SNPNs (S2-1912601)	SA2	To	Proposed tbd Proposed LS out in C1-200718 Related CRs in C1-200504, C1-200505, C1-200333
C1-200235	LS on support of Control Plane CIoT 5GS Optimisation (S2-1912609)	SA2	To	Proposed Noted Are CRs available to this meeting?
C1-200236	Reply LS on sending CAG ID during resume procedure (S2-1912731)	SA2	To	Proposed Noted No action for CT1
C1-200237	Reply LS on Rel-16 NB-IoT enhancements (S2-1912763)	SA2	To	Proposed tbd Reply Needed Proposed LS out in C1-200499 Proposed LS out in C1-200416 Discussion paper in C1-200498 DP in C1-200417
C1-200238	Reply LS on clarification on the requirement for steering of roaming (S2-1912764)	SA2	To	Proposed Postponed CRs in CT1 likely needed, agenda item not in scope of this meeting
C1-200239	LS on the support for ECN in 5GS (S2-1912765)	SA2	Cc	Proposed Noted
C1-200240	Reply LS on "set of configuration parameters" in the precedence of the V2X configuration parameters (S2-2000970)	SA2	To	Proposed Noted Related pCR in C1-200625
C1-200241	Reply LS on PC5 unicast and groupcast security protection (S2-2000971)	SA2	To	Proposed Noted Related CR in C1-200349
C1-200242	Reply LS on Response LS on SL RLM/RLF (S2-2000973)	SA2	To	Proposed Noted Related CR in C1-200350
C1-200243	Reply LS on configured NSSAI handling (S2-2001110)	SA2	To	Proposed tbd Proposed LS out in C1-200718 No action for CT1 identified
C1-200244	Reply LS on Dual-registration requirements for EHPLMNs (S2-2001130)	SA2	To	Proposed Postponed CT1 CRs seem needed, potentially a reply LS
C1-200245	LS on MA PDU establishment when the VPLMN does not support ATSSS (S2-2001148)	SA2	To	Proposed Noted Are CRs available to this meeting?
C1-200246	Reply LS on gPTP message delivery to DS-TT (S2-2001150)	SA2	To	Proposed Noted Related CR in C1-200339
C1-200247	Reply LS on 5G-S-TMSI Truncation Procedure (S2-2001248)	SA2	To	Proposed Noted C1-200500 (discussion paper) and C1-200501 (related CR)
C1-200248	Reply LS on congestion during RLOS access (S2-2001335)	SA2	To	Proposed Noted No action seems required
C1-200249	LS on Non-UE N2 Message Services Operations (S2-2001340)	SA2	To	Proposed tbd Proposed LS out in C1-200721
C1-200250	Reply LS on CMAS/ETWS and emergency services for SNPNs (S2-2001400)	SA2	Cc	Proposed Noted
C1-200251	Reply LS on assistance indication for WUS (S2-2001578)	SA2	To	Withdrawn
C1-200252	LS on Sending CAG ID (S2-2001616)	SA2	To	Proposed tbd Reply Needed Proposed LS out in C1-200310 Related CRs in C1-200311, C1-200467, C1-200337 (seem to contain the same solution) Related DP in C1-200335
C1-200253	LS on PC5S and PC5 RRC unicast message protection (S3-193802)	SA3	To	Proposed Noted Proposed LS out in C1-200545 Related CR in C1-200349
C1-200254	Reply LS to LS on usage of IMSI during 3GPP based authentication (S3-194454)	SA3	Cc	Proposed Noted Reply from SA3 to CT4 (C1-200206)
C1-200255	Reply LS on SUCI computation from an NSI (S3-194455)	SA3	To	Proposed tbd Reply Needed Proposed LS out in C1-200395
C1-200256	Reply LS to SA2 on 5G-S-TMSI Truncation Procedure (S3-194482)	SA3	Cc	Proposed Noted
C1-200257	Reply LS on SUCI computation from an NSI (S3-194548)	SA3	To	Proposed Noted Are CRs available to this meeting?
C1-200258	Reply LS on Sending CAG ID in NAS layer (S3-194559)	SA3	Cc	Proposed Noted
C1-200259	Reply LS on IANA assigned values for mission critical (S3-194603)	SA3	To	Proposed Postponed Reply LS is needed, not provided to the meeting, SA6 meets in May, i.e. after next CT1 meeting
C1-200260	LS to CT1 on 3rd ETSI MCX Remote Plugtest (S3-194611)	SA3	To	Proposed Noted
C1-200261	LS on Reply on QoE Measurement Collection (S5-197543)	SA5	Cc	Proposed Noted
C1-200262	Reply LS on how the IWF obtains key material for interworking group and private communications (S6-192194)	SA6	To	Proposed Noted Are CRs available to this meeting?
C1-200263	Reply LS (S6-192023) on clarifications regarding SEAL services (S6-192318)	SA6	Cc	Proposed Noted
C1-200264	Reply LS on Unicast resource management with SIP core (S6-200163)	SA6	To	Proposed Noted related CR iC1-200616
C1-200265	LS on API additions to SEAL and V2XAPP (S6-200270)	SA6	To	Proposed Noted No CT1 CRs seem available to this meeting, commented that none are needed
C1-200266	Reply LS on Enquiries for supporting vertical applications (S6-200337)	SA6	To	Proposed Noted Related CRs in C1-200562, C1-200563, C1-200554,C1-200552, C1-200553, C1-200608 and C1-200610
C1-200267	Reply LS on clarifications regarding V2XAPP services (S6-192385)	SA6	Cc	Proposed Noted
C1-200268	LS on missing cause code mapping (C3-195374)	CT3	Cc	Proposed Noted
C1-200269	Reply LS on LS on dependencies on AS design for mobility management aspects of NTN in 5GS / LS on system level design assumptions for satellite in 5GS (R3-197699)	RAN3	Cc	Proposed Noted C1-200220 from RAN2 and C1-200269 from RAN3 are both replies to the same LS from SA2 (S2-1910786) C1-200223 from RAN2 and C1-200269 from RAN3 are both replies to the same LS from SA2 (S2-1910787)
C1-200270	Reply on QoE Measurement Collection (S4-200241)	SA4	To	Proposed Postponed Reply LS is needed, not provided to the meeting
C1-200271	Reply LS on Support for ECN in 5GS (S4-200298)	SA4	Cc	Proposed Noted
C1-200272	LS on GSMA NG.116 Attribute Area of service and impact on PLMN selection (S2-2001726)	SA2	To	Postponed LS pertains to Rel-17 (FS_eNS_Ph2 )
C1-200273	Questions on onboarding requirements (S2-2001729)	SA2	Cc	Postponed LS pertains to Rel-17 (FS_eNPN)
C1-200274	Reply LS on assistance indication for WUS (S2-2001732)	SA2	To	Proposed Postponed SA2 asks CT WG1 group to take the above answers into account and update their specifications accordingly, if required. Any CRs for WUS in EPC were treated under SAES in previous meeting
C1-200319	Specification of NAS COUNT for 5G (FSAG Doc 78_002)	GSMA FSAG	To	Proposed Postponed CRs to 24.501 may be needed Reply LS may be needed
C1-200356	General status of WWC work (LIAISE-376)	Broadband Forum	LS in	Proposed Noted
void	Release 5 is closed
void	Release 6 is closed
void	Release 7 is closed
Release 8 work items	Tdoc	NOT PART OF THIS MEETING
Release 9 work items	Tdoc	NOT PART OF THIS MEETING
Release 10 work items	Tdoc	NOT PART OF THIS MEETING
Release 11 work items	Tdoc	NOT PART OF THIS MEETING
Release 12 work items	Tdoc	NOT PART OF THIS MEETING
Release 13 work items	Tdoc	NOT PART OF THIS MEETING
Release 14 work items	Tdoc	NOT PART OF THIS MEETING
Release 15 work items	Tdoc	NOT PART OF THIS MEETING
Release 16 work items	Tdoc	Title	Source	Tdoc info	Result & comments
Tdocs on Work Items	Papers related to Rel-16 Work Items
Work Item Descriptions	Peter - Main	New and revised Work Item Descritpions
C1-200296	Stage-3 5GS NAS protocol development	Ericsson / Ivo	WID revised Rel-16	Revision of CP-183087
C1-200348	Revised WID on CT aspects of optimisations on UE radio capability signalling	Qualcomm Incorporated / Lena	WID revised Rel-16
C1-200423	Revised WID on CT aspects of Cellular IoT support and evolution for the 5G System	Qualcomm Incorporated / Amer	WID revised Rel-16
C1-200472	Revised WID on Multi-device and multi-identity	Ericsson /Jörgen	WID revised Rel-16
CRs and Discussion Documents related to new or revised Work Items	Peter - Main	CRs and Disc papers related to new Work Items
Status of other Work Items	Peter - Main	Status information on other relevant Rel-16 Work Items
C1-200422	5G_CIoT WI workplan	Qualcomm Incorporated / Amer	Work Plan Rel-16
Release 16 documents for information	Peter - Main	Miscellaneous documents provided for information
WIs for common and SAE/5G	WIs mainly targeted for common sessions or the SAE/5G breakout
ePWS	Lena – Main	CT aspects of enhancements of Public Warning System TR 23.735 is sent to CT#85 for approval
C1-200442	CR 23.041#0208 Addition of message identifiers for UEs with no user interface	SyncTechno Inc.	CR 0208 23.041 Rel-16
C1-200443	CR 23.041#0209 Support of a stored language-independent content referenced by a warning message	SyncTechno Inc.	CR 0209 23.041 Rel-16
C1-200444	CR 23.041#0210 Example of Unicode based symbols as the language independent contents mapping to disasters in NOTE	SyncTechno Inc.	CR 0210 23.041 Rel-16
C1-200446	Workplan for ePWS-CT aspects	SyncTechno Inc.	Work Plan Rel-16
C1-200765	handling of ePWS message	Samsung /Grace	CR 0211 23.041 Rel-16	The CR seems to be related to incoming LS in C1-200226. The incoming LS pertains to Rel-15, and is not part of work item ePWS.
C1-200769	discussion for concurrent broadcast for CMAS	Samsung R&D Institute UK	discussion 23.041 Rel-16	Withdrawn
C1-200770	discussion for concurrent broadcast for CMAS	Samsung R&D Institute UK	discussion 23.041 Rel-16	Withdrawn
C1-200771	discussion for concurrent broadcast for CMAS	Samsung /Grace	discussion 23.041 Rel-16	Postponed Document was LATE
SINE_5G	Peter – Main	Signalling Improvements for Network Efficiency in 5GS
C1-200513	Work plan for SINE_5G	Huawei, HiSilicon/Lin	discussion Rel-16	Revision of C1-198222
C1-200514	No retry in 4G for PDU session type related 5GSM causes	Huawei, HiSilicon/Lin	CR 1943 24.501 Rel-16
C1-200547	Correction on UE retry restriction on EPLMN	China Telecom, Huawei, HiSilicon	CR 1944 24.501 Rel-16
C1-200768	handling of PDU session authentication	Samsung/Grace	CR 2026 24.501 Rel-16
SAES16 WIs	Peter – Main	Stage-3 SAE protocol pevelopment for Rel-16
SAES16	Peter – Main	General Stage-3 SAE protocol development Only revision of agreed CRs from the ad-hoc meeting and DISC paper supporting LS possible
C1ah-200120	Correcting reference to 5GSM procedures	Ericsson / Mikael	CR 1858 24.501 Rel-16	Agreed
C1ah-200123	+CGEV amendment for indicating IP address/type change	MediaTek Inc. / JJ	CR 0681 27.007 Rel-16	Agreed Revision of C1ah-200091
SAES16-CSFB	Peter – Main	Stage-3 SAE protocol development related to Circuit Switched Fall Back
SAES16-non3GPP	Peter – Main	Stage-3 SAE protocol development related to non-3GPP access
5GProtoc16 WIs	Peter – Main	Stage-3 5GS NAS protocol development for Rel-16
5GProtoc16	General Stage-3 5GS NAS protocol development Only revision of agreed CRs from the ad-hoc meeting and DISC paper supporting LS possible
C1ah-200023	Correction for AUTHENTICATION REJECT handling	Ericsson / Ivo	CR 1785 24.501 Rel-16	Agreed
C1ah-200032	Correct “ANSDP”	Intel	CR 1793 24.501 Rel-16	Agreed
C1ah-200037	Correction to RAT's that can be scanned after E-UTRAN disable due to no voice service	Samsung/Anikethan	CR 0482 23.122 Rel-16	Agreed
C1ah-200043	Emergency service missing condition for performing registration update	Intel / Thomas	CR 0483 23.122 Rel-16	Agreed
C1ah-200044	Listing of 5GMM parameters for EMM cause #12 handling	HiSilicon, HiSilicon / Vishnu	CR 3315 24.301 Rel-16	Agreed
C1ah-200047	Declare syntactical error when both MFBR uplink and MFBR downlink equal zero	Qualcomm Incorporated	CR 1804 24.501 Rel-16	Agreed
C1ah-200059	Correction on NAS transparent container for 5G-4G interworking	Huawei, HiSilicon/Lin	CR 1811 24.501 Rel-16	Agreed
C1ah-200062	Trigger for stopping timer T3511	Huawei, HiSilicon/Lin	CR 1813 24.501 Rel-16	Agreed
C1ah-200063	Correction on T3502 for deactivated value	Huawei, HiSilicon/Lin	CR 1814 24.501 Rel-16	Agreed
C1ah-200066	EMM cause #22 for resetting registration attempt counter	Huawei, HiSilicon/Lin	CR 3322 24.301 Rel-16	Agreed
C1ah-200067	Consistent use of additional 5G security information IE	Huawei, HiSilicon/Lin	CR 1816 24.501 Rel-16	Agreed
C1ah-200069	Correction on N26 interface indicator	Huawei, HiSilicon/Lin	CR 3323 24.301 Rel-16	Agreed
C1ah-200070	Correction on reference of TS 36.304	Huawei, HiSilicon/Lin	CR 1818 24.501 Rel-16	Agreed
C1ah-200072	Inclusion of 5GSM cause in PDU session release request	Huawei, HiSilicon/Lin	CR 1820 24.501 Rel-16	Agreed
C1ah-200073	PDU session establishment reject with 5GSM #29	Huawei, HiSilicon/Lin	CR 1821 24.501 Rel-16	Agreed
C1ah-200079	Acknowledgement of UCU procedure	vivo / Yanchao	CR 1826 24.501 Rel-16	Agreed
C1ah-200100	Correction in handling of persistent PDU session during the mobility registration update	Nokia, Nokia Shanghai Bell	CR 1842 24.501 Rel-16	Agreed
C1ah-200099	Procedures for an ETWS/CMAS-capable UE in NG-RAN	Nokia, Nokia Shanghai Bell	CR 0205 23.041 Rel-16	Agreed
C1ah-200101	NAS signalling spelling correction	Ericsson / Mikael	CR 1843 24.501 Rel-16	Agreed
C1ah-200105	Correction to IEI values	Huawei, HiSilicon /Christian	CR 1846 24.501 Rel-16	Agreed
C1ah-200107	Correction to UCU procedure abnormal cases on NW side for a new TAI list	Ericsson /kaj	CR 1848 24.501 Rel-16	Agreed
C1ah-200113	Correction to the Mapped NSSAI IE	Huawei, HiSilicon /Christian	CR 1854 24.501 Rel-16	Agreed
C1ah-200118	Correction to AT+CLADN string type	MediaTek Inc. / Marko	CR 0682 27.007 Rel-16	Agreed
C1ah-200124	S-NSSAI value associated with the BO timer applied for all PLMNs	MediaTek Inc., Qualcomm Incorporated, Huawei, HiSilicon / JJ	CR 1839 24.501 Rel-16	Agreed Revision of C1ah-200096
C1ah-200127	Correcting styles	BlackBerry UK Ltd.	CR 3313 24.301 Rel-16	Agreed Revision of C1ah-200014 This is now a TEI16 change
C1ah-200129	Abnormal case for service request procedure	ZTE	CR 1797 24.501 Rel-16	Agreed Revision of C1ah-200038
C1ah-200131	S-NSSAI as a mandatory parameter for interworking with 5GS	MediaTek Inc. / JJ	CR 1836 24.501 Rel-16	Agreed Revision of C1ah-200093
C1ah-200137	Service Request for PS Data Off	ZTE	CR 1799 24.501 Rel-16	Agreed Revision of C1ah-200040
C1ah-200139	Usage of SoR-AF function	Nokia, Nokia Shanghai Bell /Jennifer	CR 0486 23.122 Rel-16	Agreed Revision of C1ah-200081
C1ah-200140	Update bullet index to include all NAS transport cases	Nokia, Nokia Shanghai Bell /Jennifer	CR 1827 24.501 Rel-16	Agreed Revision of C1ah-200082
C1ah-200141	Correction to 5GMM cause IE	Huawei, HiSilicon /Christian	CR 1847 24.501 Rel-16	Agreed Revision of C1ah-200106
C1ah-200145	Correction to the retransmission timer for the network slice-specific EAP message reliable transport procedure	Huawei, HiSilicon /Christian	CR 1852 24.501 Rel-16	Agreed Revision of C1ah-200111
C1ah-200147	Handling of unsupported SSC mode	Qualcomm Incorporated / Lena	CR 1794 24.501 Rel-16	Agreed Revision of C1ah-200033 Author indicated a revision for Sophia meeting to fix some unlcarity
C1ah-200148	Matching of SSC mode for association between an application and an existing PDU session	Qualcomm Incorporated / Lena	CR 0069 24.526 Rel-16	Agreed Revision of C1ah-200034
C1ah-200151	Clarification of forbidden PLMN list	vivo	CR 0484 23.122 Rel-16	Agreed Revision of C1ah-200053
C1ah-200154	Correction to sending of EPS NAS message container in Registration Request message	Samsung/Anikethan	CR 1789 24.501 Rel-16	Agreed Revision of C1ah-200028
C1ah-200155	Editorial correction of an input parameter for 5G NAS message integrity protection	Samsung/Anikethan	CR 1786 24.501 Rel-16	Agreed Revision of C1ah-200025
C1ah-200156	Inclusion of PDU session reactivation result error cause IE	Huawei, HiSilicon/Lin	CR 1810 24.501 Rel-16	Agreed Revision of C1ah-200056
C1ah-200157	Deletion of the rejected NSSAI for the current registration area	Huawei, HiSilicon/Lin	CR 1812 24.501 Rel-16	Agreed Revision of C1ah-200061
C1ah-200158	5GMM cause #22 for resetting registration attempt counter	Huawei, HiSilicon/Lin	CR 1815 24.501 Rel-16	Agreed Revision of C1ah-200065 Author indicated a revision for Sophia to fix a minor aspect
C1ah-200159	Inclusion of 5GSM cause in PDU session modification request	Huawei, HiSilicon/Lin	CR 1819 24.501 Rel-16	Agreed Revision of C1ah-200071
C1ah-200160	Correction on QoS rule/QoS flow synchronization	Huawei, HiSilicon/Lin	CR 1822 24.501 Rel-16	Agreed Revision of C1ah-20000074 MCC is asked to fix the missing semicolon between “session” and “and” as shown below the SMF decides to continue to use the previous configuration of the PDU session and
C1ah-200166	UE handling of invalid QoS flow description	MediaTek Inc. / JJ	CR 1835 24.501 Rel-16	Agreed Revision of C1ah-200092
C1ah-200167	UE handling of multiple QoS errors in EPS	MediaTek Inc., Qualcomm Incorporated, Ericsson / JJ	CR 1838 24.501 Rel-16	Agreed Revision of C1ah-200095
C1ah-200168	Optional IE description for release assistance indication IE	MediaTek Inc. / JJ	CR 1837 24.501 Rel-16	Agreed Revision of C1ah-200094
C1ah-200171	Correction on NAS COUNT handling for intra-N1 handover	Huawei, HiSilicon/Lin	CR 1824 24.501 Rel-16	Agreed Revision of C1ah-200077
C1ah-200172	Correction on Uplink data status IE coding	Huawei, HiSilicon/Lin	CR 1825 24.501 Rel-16	Agreed Revision of C1ah-200078 Lin, Monday, 16:01
C1ah-200175	Correction on payload container of type SMS	Nokia, Nokia Shanghai Bell	CR 1828 24.501 Rel-16	Agreed Revision of C1ah-200083
C1ah-200177	Correcting reference to NAS transparent container IE during S1 mode to N1 mode in 5GMM-CONNECTED mode	Qualcomm Incorporated	CR 1805 24.501 Rel-16	Agreed Revision of C1ah-200049
C1ah-200181	Corrections on 5GMM cause #91 "DNN not supported or not subscribed in the slice"	Nokia, Nokia Shanghai Bell	CR 1834 24.501 Rel-16	Agreed Revision of C1ah-200090
C1ah-200187	Handling multiple QoS errors during a PDU session establishment procedure	Qualcomm Incorporated, MediaTek Inc. / Amer	CR 1807 24.501 Rel-16	Agreed Revision of C1ah-200051
C1ah-200190	Correction on N26 interface indicator	Huawei, HiSilicon/Lin	CR 1817 24.501 Rel-16	Agreed Revision of C1ah-200068
C1ah-200191	Abnormal case for UL NAS TRANSPORT	ZTE	CR 1800 24.501 Rel-16	Agreed Revision of C1ah-200041
C1ah-200192	Mapped EPS bearer contexts deletion	ZTE	CR 1798 24.501 Rel-16	Agreed Revision of C1ah-200130 _________________________________________ Revision of C1ah-200039
C1ah-200196	Corrections on UE-initiated NAS transport procedure initiation	Nokia, Nokia Shanghai Bell	CR 1829 24.501 Rel-16	Agreed Revision of C1ah-200176 _________________________________________ Revision of C1ah-200084
C1ah-200201	Abnormal case handling for 5GMM cause value #90 along with a PDU SESSION MODIFICATION REQUEST message	Nokia, Nokia Shanghai Bell	CR 1840 24.501 Rel-16	Agreed Revision of C1ah-200097
C1ah-200203	Service area restrictons, condition for UE out of allowed tracking area list and RA is missing	Ericsson /kaj	CR 1853 24.501 Rel-16	Agreed There was a late request for a revision, some editorial Revision of C1ah-200170 _________________________________________ Revision of C1ah-200112
C1ah-200205	Reject non-emergency PDU session request attempt while registered for emergency services	Ericsson /kaj	CR 1845 24.501 Rel-16	Agreed Revision of C1ah-200104 There was a reservation to raise concerns to this CR in February i.e., to not sending it for CT plenary for approval. Potential issues: make the reason for change (scenario) clearer so implementers would understand the scenario when they need to implement this. to (re-)consider updating the proposal by using a reject cause different than #90 to the UE.
C1ah-200208	Correcting unimplementable condition regarding N26 interworking support detection	BlackBerry UK Ltd., Nokia, Nokia Shanghai Bell	CR 1781 24.501 Rel-16	Agreed Revision of C1ah-200183 _________________________________________ Revision of C1ah-200086
C1ah-200211	Maintain Selected EPS NAS security algorithms during N1 mode to N1 mode handover	Huawei, HiSilicon/Cristina	CR 1784 24.501 Rel-16	Agreed Revision of C1ah-200197 _________________________________________ Revision of C1ah-200019
C1ah-200212	Correction to handling of a PDU session for emergency service at SOR	MediaTek Inc. / Marko	CR 0488 23.122 Rel-16	Agreed Revision of C1ah-200204 _________________________________________ Revision of C1ah-200202 _________________________________________ Revision of C1ah-200169 _________________________________________ Revision of C1ah-200116
C1-200332	Handling of unsupported SSC mode	Qualcomm Incorporated / Lena	CR 1794 24.501 Rel-16	Revision of C1ah-200147
C1-200515	Deletion of the rejected NSSAI for the current registration area	Huawei, HiSilicon/Lin	CR 1812 24.501 Rel-16	Revision of C1ah-200157
C1-200620	Dual-registration requirements for EHPLMNs	Intel, Qualcomm Incorporated / Vivek	CR 1974 24.501 Rel-16	Postponed NEW CR for this WID, out of scope of the meeting
C1-200680	Reject non-emergency PDU session request attempt while registered for emergency services	Ericsson /kaj	CR 1845 24.501 Rel-16	Revision of C1ah-200205
C1-200719	Corrections in specifying reasons for errors	Nokia, Nokia Shanghai Bell	CR 1834 24.501 Rel-16	Revision of C1ah-200181
C1-200631	S-NSSAI as a mandatory parameter to support interworking with 5GS	MediaTek Inc., Ericsson / JJ	CR 1836 24.501 Rel-16	Revision of C1ah-200131
C1-200678	Service area restrictions, case missing for when UE is out of allowed tracking area list and RA	Ericsson /kaj	CR 1853 24.501 Rel-16	Revision of C1ah-200203 Moved from 16.2.8
5GProtoc16-non3GPP	Peter – Main	Stage-3 5GS NAS protocol development related to non-3GPP access
ATSSS	Peter – Main	CT aspects of Access Traffic Steering, Switch and Splitting support in 5G system Is TS 24.193 sufficiently stable to be sent to CT#87-e for approval?
C1-200286	ATSSS PCO parameters for 5G-RG	Ericsson / Ivo	CR 3211 24.008 Rel-16
C1-200287	Contents of ATSSS PCO parameters for 5G-RG	Ericsson / Ivo	pCR 24.193 Rel-16
C1-200288	Procedures for establishment of a PDN connection in EPS as a user-plane resource of a MA PDU session	Ericsson / Ivo	pCR 24.193 Rel-16
C1-200289	PDU session ID usage when the UE is a 5G-RG and requests establishment of a PDN connection in EPS as a user-plane resource of a MA PDU session	Ericsson / Ivo	CR 3326 24.301 Rel-16
C1-200299	5GSM capabilities for MA PDU session	Motorola Mobility, Lenovo	CR 1860 24.501 Rel-16	Revision of C1-200001 C1-200299 and C1-200565 are competing
C1-200301	MA PDU session is not supported	Motorola Mobility, Lenovo	CR 1862 24.501 Rel-16	Withdrawn Revision of C1-200004
C1-200303	MA PDU session is not supported	Motorola Mobility, Lenovo	CR 1862 24.501 Rel-16	Revision of C1-200004
C1-200313	Comparison of solutions for performance measurement function (PMF) protocol	Ericsson / Ivo	discussion Rel-16
C1-200314	Performance management function protocol	Ericsson / Ivo	pCR 24.193 Rel-16	Revision of C1-200110 Alternative to C1-200655
C1-200396	MA PDU session and one set of QoS parameters	Ericsson / Ivo	CR 1896 24.501 Rel-16
C1-200317	MA-PDU session activation in Restricted Service Area	InterDigital / Atle	pCR 24.193 Rel-16	Revision of C1-200112
C1-200404	Minor Correction to ATSSS container IE desciption	China Mobile	CR 1903 24.501 Rel-16
C1-200406	Minor Correction to Traffic descriptor component type identifier of ATSSS rules	China Mobile	pCR 24.193 Rel-16
C1-200413	Removing editor's note	Motorola Mobility, Lenovo	pCR 24.193 Rel-16	Partially overlapping with C1-200459
C1-200414	MA PDU session is not supported	Motorola Mobility France S.A.S	pCR 24.193 Rel-16
C1-200456	Discussion on handling of clause 5.2 of TS 24.193	ZTE / Joy	discussion Rel-16	Related to CRs in C1-200457, C1-200458 and C1-200459, describes two alternatives
C1-200457	Move the content of clause 5.2 out of TS 24.193	ZTE / Joy	pCR 24.193 Rel-16	Alternative 1 described in C1-200456
C1-200458	Introduction of multi-access PDU connectivity service	ZTE / Joy	CR 1920 24.501 Rel-16	Alternative 1 described in C1-200456
C1-200459	Remove editor's notes	ZTE / Joy	pCR 24.193 Rel-16	Alternative 2 described in C1-200456 Partially overlapping with C1-200413
C1-200460	Clarification on link-specific address/prefix	ZTE / Joy	pCR 24.193 Rel-16
C1-200461	Clarification on multi-homing and UL-CL funtionalities in MA PDU Session	ZTE / Joy	pCR 24.193 Rel-16
C1-200565	ATSSS Non-MPTCP traffic support	Apple	CR 1948 24.501 Rel-16	C1-200299 and C1-200565 are competing
C1-200567	ATSSS Non-MPTCP traffic support	Apple	pCR 24.193 Rel-16
C1-200627	Considering allowed NSSAI when establishing MA PDU session	MediaTek Inc., ZTE / JJ	CR 1976 24.501 Rel-16
C1-200628	UE Handling upon receipt of PDU session release command	MediaTek Inc. / JJ	CR 1977 24.501 Rel-16
C1-200629	Correction of release of user-plane resources	MediaTek Inc. / JJ	pCR 24.193 Rel-16
C1-200630	Correction of "a different PLMN"	MediaTek Inc. / JJ	pCR 24.193 Rel-16
C1-200655	ATSSS Performance Measurement Function Protocols and Procedures	Apple, Deutsche Telekom, Charter Communications	pCR 24.193 Rel-16	Revision of C1-199051 Alternative to C1-200314
C1-200747	service request for multiple access PDU session	Samsung /Grace	pCR 24.193 Rel-16
C1-200760	ATSSS 5GSM capability indication	Nokia, Nokia Shanghai Bell	CR 2024 24.501 Rel-16	Withdrawn LATE
eNS	Peter – Main	CT aspects on enhancement of network slicing
C1-200318	Cleanups of the Pending NSSAI	InterDigital / Atle	CR 1869 24.501 Rel-16	Revision of C1-200113
C1-200320	Alignment of error codes with 3GPP TS 24.501	InterDigital / Atle	CR 0683 27.007 Rel-16	Revision of C1-200315
C1-200352	Handling of S-NSSAIs in the pending NSSAI	LG Electronics / Sunhee	CR 1889 24.501 Rel-16	See also C1-200318 & 0405 & 0579 Covers the change in C1-200702. Covers the change in C1-200401. Covers the change in C1-200690
C1-200392	Clarification on HPLMN S-NSSAI	LG Electronics / Sunhee Kim	CR 1893 24.501 Rel-16	See also C1-200432. Different proposals.
C1-200393	Adding NSSAA result indication into Network slicing indication IE of the CONFIGURATION UPDATE COMMAND message	China Telecommunications	CR 1894 24.501 Rel-16
C1-200394	Adding NSSAA failed or revoked to 5GSM and 5GMM cause IE	China Telecommunications	CR 1895 24.501 Rel-16
C1-200399	Update to registration procedure due to eNS	vivo / Yanchao	CR 1899 24.501 Rel-16
C1-200401	Definition of Rejected NSSAI due to the failed and revorked NSSAA	vivo / Yanchao	CR 1901 24.501 Rel-16	Covered by C1-200352.
C1-200354	Correcting condition for Network Slice-Specific Authentication and Authorization	Samsung Electronics Polska / Ricky	CR 1890 24.501 Rel-16	Covered by C1-200697
C1-200405	Updating requirements and descriptions of NS for NSSAA	China Mobile	CR 1904 24.501 Rel-16	See also C1-200352
C1-200407	Clarification of T35xx timer during Network slice-specific authentication and authorization procedure	LG Electronics / Sunhee Kim	CR 1905 24.501 Rel-16	Covered by C1-200432
C1-200415	Network-requested PDU session release due no longer available S-NSSAI	Motorola Mobility, Lenovo, China Mobile	CR 1906 24.501 Rel-16	See also C1-200395, 0704, 0695 Three different proposals in C1-200704,0695 and C1-200415
C1-200428	Work Plan for eNS in CT1	ZTE	Work Plan Rel-16
C1-200429	Deleting Editors note regarding indefinite wait at the UE for NSSAA completion	ZTE	CR 1912 24.501 Rel-16	See also C1-200494. Different proposals. Related to the outgoing LS in C1-200434
C1-200430	UE behaviour for other causes in the rejected NSSAI during deregistration procedure	ZTE	CR 1913 24.501 Rel-16
C1-200431	Pending NSSAI update for the configured NSSAI in the CUC message	ZTE	CR 1914 24.501 Rel-16
C1-200432	Cleanup for NSSAA message and coding	ZTE	CR 1915 24.501 Rel-16	See also C1-200392. Also covers the changes in C1-200407
C1-200433	Rejected NSSAI during the initial registration procedure	ZTE	CR 1916 24.501 Rel-16
C1-200462	Name of the rejected NSSAI cause values	vivo	CR 1921 24.501 Rel-16
C1-200494	Prevention of indefinite wait for completion of the network slice-specific authentication and authorization procedure	InterDigital / Atle	CR 1929 24.501 Rel-16	See also C1-200429.
C1-200509	Requested NSSAI creation from configured NSSAI excluding pending NSSA	Huawei, HiSilicon/Lin	CR 1939 24.501 Rel-16	See also C1-200724
C1-200510	Remove mobility restriction after NSSAA	Huawei, HiSilicon/Lin	CR 1940 24.501 Rel-16	See also C1-200602
C1-200511	ENs resolution for revoked or failed NSSAA	Huawei, HiSilicon/Lin	CR 1941 24.501 Rel-16	See also C1-200683, C1-200694
C1-200512	Consistent name for NSSAA	Huawei, HiSilicon/Lin	CR 1942 24.501 Rel-16
C1-200572	EPS selection when the UE is deregistered due to NSSAA failure	Samsung/Kundan	CR 1950 24.501 Rel-16
C1-200574	Handling of NSSAA at non suppoting AMF	Samsung/Kundan	CR 1951 24.501 Rel-16
C1-200575	PDN connection establishment and NSSAA	Samsung/Kundan	CR 1952 24.501 Rel-16
C1-200576	NSSAA revocation function	Samsung/Kundan	CR 1953 24.501 Rel-16
C1-200577	Intersystem selection procedure when all allowed S-NSSAI are subject to NSSAA	Samsung/Kundan	CR 1954 24.501 Rel-16
C1-200579	Correction related the rejected NSSAI due to the failed or revoked NSSAA	SHARP	CR 1955 24.501 Rel-16	See also C1-200352.
C1-200582	Correction UE behaviour when the UE recives the pending NSSAI	SHARP	CR 1958 24.501 Rel-16
C1-200584	Correction related the rejected NSSAI	SHARP	CR 1960 24.501 Rel-16
C1-200601	Discussion on eNS	BEIJING SAMSUNG TELECOM R&D	discussion
C1-200602	Removal of the use of Service area list IE during NSSAA	BEIJING SAMSUNG TELECOM R&D	CR 1971 24.501 Rel-16	Related to DP C1-200601 See also C1-200510.
C1-200604	Re-initiation of NSSAA for a registered UE	BEIJING SAMSUNG TELECOM R&D	CR 1972 24.501 Rel-16
C1-200605	Additional triggers for deletion of pending S-NSSAI	Samsung/Anikethan	CR 1973 24.501 Rel-16
C1-200683	NW slice authentication and authorization failure and revocation	Ericsson /kaj	CR 1533 24.501 Rel-16	Revision of C1-198772 Partly overlaps with C1-200511
C1-200689	No default S-NSSAI	Nokia, Nokia Shanghai Bell	CR 1988 24.501 Rel-16
C1-200690	Missing NSSAI storage for rejected NSSAI due to the failed or revoked network slice-specific authentication and authorization	NEC	CR 1989 24.501 Rel-16	Covered by C1-200352
C1-200691	Updating NSSAI status in AMF	NEC	CR 1990 24.501 Rel-16
C1-200692	AMF updates the UE NSSAI storage after network slice-specific authentication and authorization is completed	NEC	CR 1991 24.501 Rel-16
C1-200693	NSSAI status in AMF	NEC	CR 1992 24.501 Rel-16
C1-200694	NSSAI storage at UE – pending NSSAI	NEC	CR 1993 24.501 Rel-16	See also 0511, 0683
C1-200695	Release of PDU sessions due to revocation from AAA server or re-auth failure	NEC	CR 1994 24.501 Rel-16	See also C1-200415 & 0704 Three different proposals in C1-200704,0695 and C1-200415
C1-200696	Clarification on the S-NSSAI not subject to NSSAA included in allowed NSSAI	Nokia, Nokia Shanghai Bell	CR 1995 24.501 Rel-16
C1-200697	Subscribed S-NSSAI marked as default and NSSAA	Nokia, Nokia Shanghai Bell	CR 1996 24.501 Rel-16	Covers the change in C1-200354
C1-200698	Additional conditions to the presence in the subscribed S-NSSAIs	Nokia, Nokia Shanghai Bell	CR 1997 24.501 Rel-16
C1-200702	Definition of pending NSSAI	Nokia, Nokia Shanghai Bell	CR 1999 24.501 Rel-16	Covered by C1-200352.
C1-200703	Emergency PDU session handling after NSSAA failure	Nokia, Nokia Shanghai Bell	CR 2000 24.501 Rel-16
C1-200704	Release of a PDU session due to failure/revocation in NSSAA	Nokia, Nokia Shanghai Bell	CR 2001 24.501 Rel-16	See also C1-200415 & 0695 Three different proposals in C1-200704,0695 and C1-200415
C1-200724	Request S-NSSAI pending the NW slice-specific authentication and authorization	Ericsson /kaj	CR 2004 24.501 Rel-16	See also C1-200509
Vertical_LAN	Peter – Main	CT aspects of 5GS enhanced support of vertical and LAN services TS 24.534 has been withdrawn Is TS 24.535 sufficiently stable to be sent to CT#87-e for approval Is TS 24.519 sufficiently stable to be sent to CT#87-e for approval?
Stand-alone NPN
C1-200762	Work plan for CT aspects of Vertical_LAN	Nokia, Nokia Shanghai Bell	discussion Rel-16
C1-200767	Work plan for CT aspects of Vertical_LAN	Nokia, Nokia Shanghai Bell	discussion Rel-16	Revision of C1-200762
C1-200466	Correction to Limited service state for SNPN	Huawei, HiSilicon / Vishnu	CR 0492 23.122 Rel-16
C1-200551	UE receives CAG information in SNPN access mode	Huawei, HiSilicon/Cristina	CR 1946 24.501 Rel-16
C1-200587	Correlation of SNPN entry stored in ME and USIM	Samsung/Kundan	CR 1963 24.501 Rel-16
C1-200591	Modification of the allowed CAG list	Samsung/Kundan	CR 1965 24.501 Rel-16	Postponed Document was LATE
C1-200599	Handlig of PLMN specific NID	Samsung/Kundan	CR 1969 24.501 Rel-16
C1-200333	Removal of Editor’s note on the use of the NOTIFICATION message in SNPNs	Qualcomm Incorporated / Lena	CR 1882 24.501 Rel-16
C1-200334	Updating length of NID	Qualcomm Incorporated, Ericsson, Nokia, Nokia Shanghai Bell / Lena	CR 0115 24.502 Rel-16
C1-200464	Clarification of forbidden TAI lists for SNPN	vivo	CR 1923 24.501 Rel-16
C1-200469	Clarify that access to RLOS is not supported in SNPN	Huawei, HiSilicon / Vishnu	CR 0494 23.122 Rel-16
C1-200470	Clarification of the rejected NSSAI cause value	vivo	CR 1926 24.501 Rel-16
C1-200504	Correction on 5GMM cause #74/#75 for no touching non-3GPP access	Huawei, HiSilicon/Lin	CR 1935 24.501 Rel-16
C1-200505	5GMM cause #72 not used in SNPN	Huawei, HiSilicon/Lin	CR 1936 24.501 Rel-16
C1-200506	Correction on term “non-3GPP access” used in SNPN	Huawei, HiSilicon/Lin	CR 1937 24.501 Rel-16
C1-200507	Correction on term “shared network” definition for SNPN	Huawei, HiSilicon/Lin	CR 0497 23.122 Rel-16
C1-200600	Handling of LADN infotmation when the UE operating in SNPN access mode	SHARP	CR 1970 24.501 Rel-16
C1-200681	Update SNPN key differences	Intel / Thomas	CR 1985 24.501 Rel-16
C1-200686	UE identifier for SNPN	Nokia, Nokia Shanghai Bell, Qualcomm Incorporated, Vodafone, Charter Communications, NTT DOCOMO, Ericsson	CR 0498 23.122 Rel-16
C1-200735	Correction in UE ehaviour upon receipt of 5GMM cause value #74 or #75 via a non-integrity protected NAS message	Nokia, Nokia Shanghai Bell	CR 2010 24.501 Rel-16
C1-200736	List of SNPNs for which the N1 mode capability was disabled	Nokia, Nokia Shanghai Bell	CR 0502 23.122 Rel-16
C1-200737	Introduction of SNPN-specific N1 mode attempt counters	Nokia, Nokia Shanghai Bell	CR 2011 24.501 Rel-16
C1-200738	N1 mode capability disabling and re-enabling for SNPN	Nokia, Nokia Shanghai Bell	CR 2012 24.501 Rel-16
C1-200739	#72 applicable and #31 not applicable in an SNPN	Nokia, Nokia Shanghai Bell	CR 2013 24.501 Rel-16
C1-200740	T3245 in an SNPN	Nokia, Nokia Shanghai Bell	CR 2014 24.501 Rel-16
C1-200741	Validity of the USIM for an SNPN and for a specific access type	Nokia, Nokia Shanghai Bell	CR 2015 24.501 Rel-16
C1-200742	Handling of 5GMM cause values #62 in an SNPN	Nokia, Nokia Shanghai Bell	CR 2016 24.501 Rel-16
C1-200743	No mandate to support default configured NSSAI or network slicing indication	Nokia, Nokia Shanghai Bell	CR 2017 24.501 Rel-16
C1-200744	SNN coding	Nokia, Nokia Shanghai Bell	CR 2018 24.501 Rel-16
C1-200745	5GMM cause value #74 in an SNPN with a globally-unique SNPN identity	Nokia, Nokia Shanghai Bell	CR 2019 24.501 Rel-16
C1-200746	Display of the human readable name of an SNPN	Nokia, Nokia Shanghai Bell	CR 0503 23.122 Rel-16
Public network integrated NPN
C1-200291	CAG information list storage	Ericsson / Ivo	CR 1879 24.501 Rel-16
C1-200311	CAG-ID not provided to lower layers during NAS signalling connection establishment	Ericsson / Ivo	CR 1880 24.501 Rel-16
C1-200316	CAG Information in Registration Reject	InterDigital / Atle	CR 1868 24.501 Rel-16	Revision of C1-200111
C1-200335	Signalling of CAG-ID	Qualcomm Incorporated / Lena	discussion Rel-16
C1-200336	Clarification to manual CAG selection	Qualcomm Incorporated / Lena	CR 0489 23.122 Rel-16
C1-200337	Removal of the requirement for NAS to pass the selected CAG-ID to the lower layers	Qualcomm Incorporated / Lena	CR 1883 24.501 Rel-16
C1-200398	“CAG information list” preventing selection of any available and allowable PLMN	Ericsson / Ivo	CR 1898 24.501 Rel-16
C1-200403	Clarification on CAG selection	Intel / Thomas	CR 0490 23.122 Rel-16
C1-200338	Including CAG information list in REGISTRATION ACCEPT message	Qualcomm Incorporated / Lena	CR 1884 24.501 Rel-16
C1-200451	Discussion on limited service on CAG cell	Huawei, HiSilicon/Vishnu	discussion 23.122 Rel-16
C1-200452	Limited service state on CAG cell	Huawei, HiSilicon / Vishnu	CR 0491 23.122 Rel-16
C1-200465	Deletion of all CAG IDs of a CAG cell for 5GMM cause #76	Huawei, HiSilicon / Vishnu	CR 1924 24.501 Rel-16
C1-200467	Removal of the indication of CAG-ID for N1 NAS signalling connection	Huawei, HiSilicon / Vishnu	CR 1925 24.501 Rel-16
C1-200468	Presentation of PLMN with non-CAG cells for manual selection	Huawei, HiSilicon / Vishnu	CR 0493 23.122 Rel-16
C1-200471	Removal of term CAG access control	Huawei, HiSilicon / Vishnu	CR 1927 24.501 Rel-16
C1-200508	Reset the registration attempt counter for #76 in service reject	Huawei, HiSilicon/Lin	CR 1938 24.501 Rel-16
C1-200516	Updates for Manual CAG selection	Huawei, HiSilicon / Vishnu	CR 1554 24.501 Rel-16	Revision of C1-198992 Seem to conflict with C1-200701
C1-200517	Configuration for the presentation of CAG cells for manual CAG selection	Huawei, HiSilicon / Vishnu	CR 0471 23.122 Rel-16	Revision of C1-199010
C1-200549	Clarification on Public Network Integrated NPN in TS 24.501	China Telecom	CR 1945 24.501 Rel-16
C1-200578	Discussion on requirement of sending CAG ID by UE	Samsung/Kundan	discussion 24.501 Rel-16
C1-200581	Handling of manual CAG selection procedure	Samsung/Kundan	CR 1957 24.501 Rel-16
C1-200586	CAG only UE and Manual PLMN selection	Samsung/Kundan	CR 1962 24.501 Rel-16
C1-200589	Handling of a CAG UE at non supporting AMF	Samsung/Kundan	CR 1964 24.501 Rel-16
C1-200688	CAG information towards the lower layers for paging	Nokia, Nokia Shanghai Bell	CR 1567 24.501 Rel-16	Revision of C1-196737
C1-200700	Manual CAG selection	Nokia, Nokia Shanghai Bell	CR 0499 23.122 Rel-16
C1-200701	Triggering mobility registration update due to manual CAG selection	Nokia, Nokia Shanghai Bell	CR 1998 24.501 Rel-16	Seem to conflict with C1-200516
C1-200728	Rejection of non-emergency PDU session establishment with 5GMM cause #76	Nokia, Nokia Shanghai Bell	CR 2007 24.501 Rel-16
C1-200729	Handling of a UE with an emergency PDU session in terms of CAG	Nokia, Nokia Shanghai Bell	CR 2008 24.501 Rel-16
C1-200730	Determination of CAG cell	Nokia, Nokia Shanghai Bell	CR 0500 23.122 Rel-16
C1-200731	Discussion to manual CAG selection	Ericsson / Ivo	discussion Rel-16
C1-200732	Manual CAG selection	Ericsson / Ivo	CR 0501 23.122 Rel-16
C1-200733	Manual CAG selection – providing HRNN	Ericsson / Ivo	CR 2009 24.501 Rel-16
Time sensitive communication
C1-200329	Support for per-stream filtering and policing	Intel / Thomas	other Rel-16
C1-200330	Support for traffic forwarding	Intel, Nokia, Nokia Shanghai Bell	other Rel-16
C1-200331	Additional LLDP parameters	Intel / Thomas	other Rel-16
C1-200339	Update of text on time synchronization	Qualcomm Incorporated / Lena	CR 1885 24.501 Rel-16
C1-200411	Port management corrections	Intel / Thomas	other Rel-16
C1-200493	Definition alignment for UE-DS-TT residence time	vivo	CR 1928 24.501 Rel-16
C1-200564	Establish PDU session to transfer port management information containers	Huawei, HiSilicon/Cristina	CR 1947 24.501 Rel-16	CRs in C1-200685, C1-200290, C1-200564 conflict
C1-200566	Correction on port management message direction	Huawei, HiSilicon/Cristina	pCR 24.519 Rel-16
C1-200570	Add PSFP parameters	Huawei, HiSilicon/Cristina	pCR 24.519 Rel-16
C1-200571	Correction for the wrongly implemented CR1963r1	Huawei, HiSilicon/Cristina	CR 1949 24.501 Rel-16
C1-200573	Exchange port management information container through N4 Session Level Reporting procedure	Huawei, HiSilicon/Cristina	pCR 24.519 Rel-16
C1-200687	Port management IE format and length updates	Intel / Thomas	other Rel-16
C1-200706	Resolving editor’s notes on reliable transmission	Nokia, Nokia Shanghai Bell	pCR 24.519 Rel-16
C1-200708	Duplicated Ethernet port parameters in case of validation and generation of LLDP frames processed centrally at NW-TT	Nokia, Nokia Shanghai Bell	pCR 24.519 Rel-16
C1-200734	Clarification on calculation of the residence time spent within the 5G system	Intel / Thomas	pCR 24.535 Rel-16
5G_CioT	Peter – Main	CT aspects of Cellular IoT support and evolution for the 5G System
C1-200298	Update of Reading coverage enhancement status +CRCES for Connection to 5G Core Network	BlackBerry UK Limited	CR 0684 27.007 Rel-16	Revision of C1-200116
C1-200328	Removal of EN and additional abnormal case for cause #31	Samsung/Anikethan	CR 1881 24.501 Rel-16
C1-200351	Removal of EN and additional abnormal case for cause #31	Samsung/Anikethan	CR 3330 24.301 Rel-16
C1-200368	Addition of MT-EDT support indication	Ericsson, Qualcomm Incorporated, OPPO / Mikael	CR 3332 24.301 Rel-16
C1-200383	Resolve Editor´s Notes on NB-N1 mode extended NAS timers for CE	Ericsson / Mikael	CR 1891 24.501 Rel-16
C1-200384	Resolve Editor´s Notes on WB-N1 mode extended NAS timers for CE	Ericsson / Mikael	CR 1892 24.501 Rel-16
C1-200397	“MO exception data” access category	Ericsson / Ivo	CR 1897 24.501 Rel-16	C1-200397, C1-200421 and C1-200677 overlap, all related to incoming LS in C1-200227
C1-200355	Applicability of UE specific DRX Parameter for NB-S1 mode Indicator	Vodafone GmbH	CR 3331 24.301 Rel-16	C1-200355, C1-200417, C1-200498 overlapping, All related to the incoming LS in C1-200237
C1-200400	Stop T3565 upon connection resumption	vivo / Yanchao	CR 1900 24.501 Rel-16	Corrected agenda
C1-200417	Support for UE specific DRX for NB-S1 mode	Qualcomm Incorporated, Ericsson / Amer	discussion Rel-16	C1-200355, C1-200417, C1-200498 overlapping, All related to the incoming LS in C1-200237
C1-200418	Support for the signalling of the capability for receiving WUS assistance information	Qualcomm Incorporated / Amer	CR 1907 24.501 Rel-16
C1-200419	Handling of user-plane resources for NB-IoT UEs having at least two PDU sessions	Qualcomm Incorporated, Ericsson / Amer	CR 1672 24.501 Rel-16	Revision of C1-198585 C1-200419 and C1-200497 overlap
C1-200420	5GSM congestion timers apply to data transfer over control plane	Qualcomm Incorporated / Amer	CR 1908 24.501 Rel-16
C1-200421	Definition of a new access category for MO exception data	Qualcomm Incorporated / Amer	CR 1909 24.501 Rel-16	C1-200397, C1-200421 and C1-200677 overlap, all related to incoming LS in C1-200227
C1-200424	Update of +CNMPSD for NR	BlackBerry UK Ltd.	CR 0685 27.007 Rel-16
C1-200435	UE behaviour when T3447 running	ZTE	CR 1917 24.501 Rel-16
C1-200495	Enhancement on CPSR for CIoT CP data transport	Huawei, HiSilicon, Vodafone, ZTE, China Mobile, China Telecom, CATT/Lin	CR 1701 24.501 Rel-16	Revision of C1-198581
C1-200496	Ciphering and deciphering handling of CPSR message	Huawei, HiSilicon/Lin	CR 1930 24.501 Rel-16
C1-200497	UE-requested user-plane resources release in NB-N1 mode	Huawei, HiSilicon/Lin	CR 1931 24.501 Rel-16	C1-200419 and C1-200497 overlap
C1-200498	NAS evaluation on options for UE specific DRX for NB-IoT	Huawei, HiSilicon/Lin	discussion Rel-16	C1-200355, C1-200417, C1-200498 overlapping, All related to the incoming LS in C1-200237
C1-200500	Discussion on truncated 5G-S-TMSI over NAS	Huawei, HiSilicon/Lin	discussion Rel-16
C1-200501	Truncated 5G-S-TMSI over NAS	Huawei, HiSilicon/Lin	CR 1932 24.501 Rel-16
C1-200502	AMF behavior on stop T3448	Huawei, HiSilicon/Lin	CR 1933 24.501 Rel-16
C1-200503	No SMS in payload container IE in CPSR message	Huawei, HiSilicon/Lin	CR 1934 24.501 Rel-16
C1-200580	Stopping of T3513 after connection resume for user plane CIoT 5GS optimization	Samsung/Mahmoud	CR 1956 24.501 Rel-16
C1-200583	5G-GUTI reallocation after resume from 5GMM-IDLE mode with suspend indication due to paging	Samsung/Mahmoud	CR 1959 24.501 Rel-16
C1-200585	Adding an editor’s note for suspend indication due to user plane CIoT 5GS optimization	Samsung/Mahmoud	CR 1961 24.501 Rel-16
C1-200588	Ambiguity in the suspend indication from lower layers to the NAS	Samsung/Mahmoud	discussion 24.501 Rel-16
C1-200592	Recovery from fallback for UEs using CP CIoT optimization	Samsung/Mahmoud	CR 1966 24.501 Rel-16
C1-200593	Service area restrictions for UEs using CIoT 5GS optimization	Samsung/Mahmoud	CR 1967 24.501 Rel-16
C1-200594	Adding reference to TS 24.501 for exception data reporting	Samsung/Mahmoud	CR 0047 24.368 Rel-16
C1-200618	Value range of UE specific DRX in NB-S1 mode	Vodafone GmbH	CR 3212 24.008 Rel-16
C1-200626	Indication of change in the use of enhanced coverage	BEIJING SAMSUNG TELECOM R&D	CR 1975 24.501 Rel-16
C1-200658	Correction to UL CIoT user data container not routable or not allowed to be routed	Ericsson /kaj	CR 1978 24.501 Rel-16
C1-200661	Single downlink data only indication and release of NAS signalling connection	Ericsson /kaj	CR 1979 24.501 Rel-16
C1-200663	PDU session status with control plane service request message	Ericsson /KAJ	CR 1980 24.501 Rel-16
C1-200666	Service gap control timer corrections	Ericsson /kaj	CR 3335 24.301 Rel-16
C1-200669	Service gap control, correction when to start service gap control timer in UE and NW	Ericsson /kaj	CR 1981 24.501 Rel-16
C1-200672	Clarification of control plane service request message options	Ericsson /kaj	CR 1982 24.501 Rel-16
C1-200675	CIoT user data container in CPSR message not forwarded	Ericsson /kaj	CR 1743 24.501 Rel-16	Revision of C1-198950
C1-200677	UAC updates for NB-IoT to include "MO exception data"	DOCOMO Communications Lab.	CR 1983 24.501 Rel-16	C1-200397, C1-200421 and C1-200677 overlap, all related to incoming LS in C1-200227
C1-200679	Clarification on the use of exception data reporting	DOCOMO Communications Lab.	CR 1984 24.501 Rel-16
C1-200682	MO exception data for NB-IoT in 5G	DOCOMO Communications Lab., Ericsson	CR 1986 24.501 Rel-16	Withdrawn CR was withdrawn as it used a CR number requested for 24.501 instead of 24.368
C1-200773	MO exception data for NB-IoT in 5G	DOCOMO Communications Lab., Ericsson	CR 0048 24.368 Rel-16	CR was originally provided as C1-200682, on time, new CR number was needed for 24.368
5WWC	Peter – Main	CT aspects on wireless and wireline convergence for the 5G system architecture
C1-200276	Secondary authentication and W-AGF acting on behalf of FN-RG	Ericsson / Ivo	CR 1689 24.501 Rel-16	Revision of C1-198161
C1-200277	EAP-5G handling and transport of NAS messages for wireline access	Ericsson / Ivo	CR 0110 24.502 Rel-16	Revision of C1-198159
C1-200278	SUCI used by W-AGF acting on behalf of FN-RG	Ericsson / Ivo	CR 1870 24.501 Rel-16	Conflict with C1-200754 in subclause 5.3.2
C1-200279	Resolving editor's note on W-AGF acting on behalf of FN-RG not using the "null integrity protection algorithm" 5G-IA0	Ericsson / Ivo	CR 1871 24.501 Rel-16
C1-200280	Resolving editor's note on service area restrictions in case of FN-BRG	Ericsson / Ivo	CR 1872 24.501 Rel-16
C1-200281	Resolving editor's note in forbidden wireline access area	Ericsson / Ivo	CR 1873 24.501 Rel-16
C1-200282	Wireline 5G access network and wireline 5G access	Ericsson / Ivo	CR 1874 24.501 Rel-16
C1-200283	PEI clean up	Ericsson / Ivo	CR 1875 24.501 Rel-16
C1-200284	Alignment for stop of enforcement of mobility restrictions in 5G-RG and W-AGF acting on behalf of FN-CRG	Ericsson / Ivo	CR 1876 24.501 Rel-16
C1-200285	Introduction of GCI and GLI	Ericsson / Ivo	CR 1877 24.501 Rel-16
C1-200297	Removal of editor notes	BlackBery UK Ltd. Motorola Mobility, Lenovo	CR 0114 24.502 Rel-16	Revision of C1-200114
C1-200300	Additional QoS Information in an untrusted non-3GPP network	Motorola Mobility, Lenovo	CR 0111 24.502 Rel-16	Revision of C1-200002
C1-200302	Removal of editor's notes for N5CW device	Motorola Mobility, Lenovo	CR 0112 24.502 Rel-16	Revision of C1-200005
C1-200304	Removal of an editor's note	Motorola Mobility, Lenovo, BlackBerry UK Ltd.	CR 0113 24.502 Rel-16	Revision of C1-200006
C1-200305	PDU session handling for N5CW device	Motorola Mobility, Lenovo	CR 1641 24.501 Rel-16	Revision of C1-200007
C1-200425	Correct reference	BlackBerry UK Ltd.	CR 6410 24.229 Rel-16
C1-200426	Enabling mobility with (emergency) sessions/connections between the (trusted) non-3GPP access network connected to the 5GCN and the E-UTRAN	BlackBerry UK Ltd.	CR 1910 24.501 Rel-16
C1-200454	ACS information via DHCP	ZTE / Joy	CR 1919 24.501 Rel-16
C1-200455	LADN service does not apply for RG connected to 5GC via wireline access	ZTE / Joy	CR 0070 24.526 Rel-16
C1-200518	Work plan for the CT1 part of 5WWC	Huawei, HiSilicon /Christian	discussion Rel-16
C1-200754	Registration of N5GC devices via wireline access	Nokia, Nokia Shanghai Bell,Charter Communications	CR 2020 24.501 Rel-16	Conflict with C1-200278 in subclause 5.3.2
C1-200755	Support of authentication and registration of N5GC devices via wireline access	Nokia, Nokia Shanghai Bell,Charter Communications	CR 0116 24.502 Rel-16
C1-200756	Corrections on EUI-64 as PEI	Nokia, Nokia Shanghai Bell	CR 2021 24.501 Rel-16
C1-200757	Corrections on N5CW support	Nokia, Nokia Shanghai Bell	CR 2022 24.501 Rel-16
C1-200758	Supporting IPTV NAS impacts	Nokia, Nokia Shanghai Bell	CR 2023 24.501 Rel-16	Withdrawn LATE
C1-200759	Supporting IPTV via wireline access	Nokia, Nokia Shanghai Bell	CR 0117 24.502 Rel-16	Withdrawn LATE
C1-200761	SUPI and SUCI for legacy wireline access	Nokia, Nokia Shanghai Bell	CR 0118 24.502 Rel-16
PARLOS	Lena – Breakout	CT aspects of System enhancements for Provision of Access to Restricted Local Operator Services by Unauthenticated UEs
C1-200322	Factoring in T3346 during access to RLOS	Samsung R&D Institute India	CR 3327 24.301 Rel-16
C1-200476	Support of restriction on access to RLOS	Nokia, Nokia Shanghai Bell /Jennifer	CR 3333 24.301 Rel-16
C1-200477	Support of restriction on access to RLOS	Nokia, Nokia Shanghai Bell /Jennifer	CR 0495 23.122 Rel-16
C1-200478	NAS configuration on access to RLOS	Nokia, Nokia Shanghai Bell /Jennifer	CR 0046 24.368 Rel-16
C1-200479	Authentication and security handling for RLOS	Nokia, Nokia Shanghai Bell /Jennifer	CR 3334 24.301 Rel-16
C1-200480	Manual network selection procedure for access to RLOS	Nokia, Nokia Shanghai Bell /Jennifer	CR 0496 23.122 Rel-16
C1-200748	Detach before RLOS and Emergency Attach	MediaTek / Marko	CR 3338 24.301 Rel-16
C1-200763	De-registration before initial registration for RLOS and Emergency	MediaTek / Marko	CR 2025 24.501 Rel-16	Withdrawn
5G_eLCS (CT4)	Peter – Main	CT aspects of Enhancement to the 5GC LoCation Services Is TS 24.571 sufficiently stable to be sent to CT#87-e for approval
C1-200568	Adding UE initiated LCS service operations	CATT/Scott	pCR 24.571 Rel-16
C1-200569	LCS messages and coding	CATT/Scott	pCR 24.571 Rel-16
V2XAPP	Lena – Breakout	CT aspects of V2XAPP Is TS 24.486 sufficiently stable to be sent to CT#87-e for information and/or approval
C1-200519	Work plan for the CT1 part of V2XAPP	Huawei, HiSilicon /Christian	discussion Rel-16
C1-200522	Latest reference version of draft TS 24.486	Huawei, HiSilicon /Christian	draft TS 24.486 Rel-16
C1-200528	Application level location tracking procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200529	V2X message delivery procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200530	V2X service discovery procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200532	V2X sevice continuity procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200533	General on provisioning of parameters	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200534	V2X USD provisioning	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Withdrawn
C1-200535	PC5 parameters provisioning	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Withdrawn
C1-200619	Structure and data semantics for application level location tracking procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200621	Structure and data semantics for V2X message delivery procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200622	Structure and data semantics for V2X service discovery procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200623	Structure and data semantics for V2X UE registration procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
C1-200624	Structure and data semantics for V2X UE de-registration procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16
eV2XARC	Lena – Breakout	CT aspects of eV2XARC Is TS 24.587 sufficiently stable to be sent to CT#87-e for approval? Is TS 24.588 sufficiently stable to be sent to CT#87-e for approval?
C1-200292	UE policies for V2X communication over PC5	Ericsson / Ivo	pCR 24.588 Rel-16	CRs C1-200391, C1-200389, C1-200388, C1-200386 influence coding in CR C1-200292
C1-200293	Updates of configuration parameters for V2X communication over Uu	Ericsson / Ivo	pCR 24.587 Rel-16
C1-200294	V2X communication over Uu	Ericsson / Ivo	pCR 24.587 Rel-16
C1-200295	UE policies for V2X communication over Uu	Ericsson / Ivo	pCR 24.588 Rel-16
C1-200321	Precedence order between V2X configuration parameters	LG Electronics	pCR 24.587 Rel-16	Withdrawn Revision of C1-198404
C1-200324	Direct link establishment procedure update based on SA3 LS	OPPO / Rae	pCR 24.587 Rel-16
C1-200325	Remove the FFS on non-IP	OPPO / Rae	pCR 24.587 Rel-16
C1-200326	Decoding on V2X service ID and application ID	OPPO / Rae	pCR 24.587 Rel-16
C1-200327	Keep alive procedure	OPPO / Rae	pCR 24.587 Rel-16
C1-200349	Security establishment for PC5 unicast link	Qualcomm Incorporated / Lena	pCR 24.587 Rel-16
C1-200385	Adding abnormal case on the network side	Huawei, HiSilicon / Chen	pCR 24.587 Rel-16
C1-200386	Correction for the list of the V2X services authorized for PPPR over V2X PC5 in E-UTRA	Huawei, HiSilicon / Chen	pCR 24.587 Rel-16	CRs C1-200391, C1-200389, C1-200388, C1-200386 influence coding in CR C1-200292
C1-200387	Correction for the list of V2X service identifier to PDU session parameters mapping rules over V2X Uu	Huawei, HiSilicon / Chen	pCR 24.587 Rel-16
C1-200388	Correction for the list of V2X service identifier to Tx profiles mapping rules over V2X PC5	Huawei, HiSilicon / Chen	pCR 24.587 Rel-16	CRs C1-200391, C1-200389, C1-200388, C1-200386 influence coding in CR C1-200292
C1-200389	Correction for the list of V2X service identifier to V2X E-UTRA frequency mapping rules over V2X PC5	Huawei, HiSilicon / Chen	pCR 24.587 Rel-16	CRs C1-200391, C1-200389, C1-200388, C1-200386 influence coding in CR C1-200292
C1-200390	Resolution of the editor's note on details about PC5 unicast link establishment procedure not accepted by the target UE	Huawei, HiSilicon / Chen	pCR 24.587 Rel-16
C1-200391	Resolution of the editor's note on validity timer	Huawei, HiSilicon / Chen	pCR 24.587 Rel-16	C1-200391, C1-200389, C1-200388, C1-200386 influence coding in CR C1-200292
C1-200350	PC5 unicast link keep-alive procedure	Qualcomm Incorporated / Lena	pCR 24.587 Rel-16
C1-200437	PC5 unicast link release procedure	vivo	pCR 24.587 Rel-16
C1-200438	Encoding of direct link release messages and parameters	vivo	pCR 24.587 Rel-16
C1-200439	PC5 unicast link identifier update procedure	vivo	pCR 24.587 Rel-16
C1-200440	Updates to the link modification procedure	vivo	pCR 24.587 Rel-16
C1-200441	Encoding of direct link modification messages and parameters	vivo	pCR 24.587 Rel-16
C1-200520	Work plan for the CT1 part of eV2XARC	Huawei, HiSilicon /Christian	discussion Rel-16
C1-200521	Latest reference version of draft TS 24.587	Huawei, HiSilicon /Christian	draft TS 24.587 Rel-16
C1-200525	Resolution of the editor's notes on precedence of V2X configuration parameters	Huawei, HiSilicon /Christian	pCR 24.587 Rel-16
C1-200536	Operations for broadcast mode and groupcast mode communication over PC5	Huawei, HiSilicon /Christian	pCR 24.587 Rel-16
C1-200537	Data transmission over PC5 unicast link	Huawei, HiSilicon /Christian	pCR 24.587 Rel-16
C1-200538	Introduction of “PC5 Unicast Link Identifier Update Procedure”	InterDigital Communications	pCR 24.587 Rel-16
C1-200595	Triggering service request procedure for V2X communication over PC5 interface	LG Electronics / SangMin	CR 1968 24.501 Rel-16
C1-200596	Discussion on multiple V2X services during the direct link establishment procedure	LG Electronics / SangMin	discussion Rel-16
C1-200597	Multiple V2X service identifiers in DIRECT LINK ESTABLISHMENT REQUEST message	LG Electronics / SangMin	pCR 24.587 Rel-16
C1-200598	Association between V2X service id and PC5 QoS flow description	LG Electronics / SangMin	pCR 24.587 Rel-16
C1-200603	Latest reference version of draft TS 24.588	LG Electronics / SangMin	draft TS 24.588 Rel-16
C1-200632	PC5 unicast link keep-alive procedure – additions to C1-200350	Apple	pCR 24.587 Rel-16
C1-200652	Clean-up for TS 24.588	LG Electronics / SangMin	pCR 24.588 Rel-16
RACS (CT4 lead)	Peter – Main	CT aspects of optimizations on UE radio capability signaling
C1-200340	RACS CT work plan	Qualcomm Incorporated / Lena	discussion Rel-16
C1-200341	Proposed way forward on remaining CT1 items for RACS	Qualcomm Incorporated / Lena	discussion Rel-16
C1-200342	UE radio capability ID assignment via GUTI reallocation procedure	Qualcomm Incorporated / Lena	CR 3328 24.301 Rel-16
C1-200343	Finalizing provisioning of manufacturer-assigned UE radio capability IDs at the UE	Qualcomm Incorporated / Lena	CR 0045 24.368 Rel-16
C1-200344	Removal of Editor’s note on applicability of RACS to SNPNs	Qualcomm Incorporated / Lena	CR 1886 24.501 Rel-16
C1-200345	Finalizing the encoding of the UE radio capability ID	Qualcomm Incorporated / Lena	CR 1887 24.501 Rel-16	Delete the same Editor’s note as C1-200723, plus contains more changes
C1-200346	UE radio capability ID deletion upon Version ID change	Qualcomm Incorporated / Lena	CR 1888 24.501 Rel-16
C1-200402	RACS not apply for non-3GPP access	vivo / Yanchao	CR 1902 24.501 Rel-16	Overlaps with C1-200725 which covers more changes.
C1-200347	UE radio capability ID deletion upon Version ID change	Qualcomm Incorporated / Lena	CR 3329 24.301 Rel-16
C1-200463	Clarification of the cause of start of T3550	vivo	CR 1922 24.501 Rel-16
C1-200720	UE behaviour upon receipt of a UE radio capability ID deletion indication	Nokia, Nokia Shanghai Bell	CR 2002 24.501 Rel-16
C1-200722	UE behaviour upon receipt of a UE radio capability ID deletion indication	Nokia, Nokia Shanghai Bell	CR 3336 24.301 Rel-16
C1-200723	Format of the UE radio capability ID	Nokia, Nokia Shanghai Bell	CR 2003 24.501 Rel-16	CR deletes an Editor’s note which is also deleted by C1-200345
C1-200725	RACS not applicable for non-3GPP access	Nokia, Nokia Shanghai Bell	CR 2005 24.501 Rel-16	Overlaps with C1-200402. Covers more required changes but missed the change to subclause 4.7.2 which is included in C1-200402.
C1-200726	UE radio capability information storage not needed for RACS	Nokia, Nokia Shanghai Bell	CR 2006 24.501 Rel-16
C1-200727	UE radio capability information storage not needed for RACS	Nokia, Nokia Shanghai Bell	CR 3337 24.301 Rel-16
5G_SRVCC (CT4 lead)	Peter – Main	CT aspects of single radio voice continuity from 5GS to 3G
C1-200427	Use registration message to inform the network when the SRVCC information changes	BlackBerry UK Ltd.	CR 1911 24.501 Rel-16
C1-200436	PDU session release at the UE side	ZTE, China Unicom, Ericsson	CR 1918 24.501 Rel-16
xBDT (CT3 lead)	Peter – Main	CT aspects on 5GS Transfer of Policies for Background Data 100%
IAB-CT (CT4 lead)	Peter – Main	CT aspects of support for integrated access and backhaul (IAB) CT1 no longer affected by this work item
5GS_OTAF (CT4 lead)	Peter – Main	5GS Enhanced support of OTA mechanism for UICC configuration parameter update
5G_URLLC (CT4 lead)	Peter – Main	CT aspects of CT Aspects of 5G URLLC
C1-200290	Always-On PDU session and URLLC	Ericsson / Ivo	CR 1878 24.501 Rel-16	CRs in C1-200685, C1-200290, C1-200564 conflict
C1-200685	Setting the Always-on PDU session indication IE in the PDU SESSION ESTABLISHMENT ACCEPT message	Nokia, Nokia Shanghai Bell	CR 1987 24.501 Rel-16	CRs in C1-200685, C1-200290, C1-200564 conflict
SEAL	Lena – Breakout	CT aspects of Service Enabler Architecture Layer for Verticals Is TS 24.544 sufficiently stable to be sent to CT#87-e for approval? Is TS 24.545 sufficiently stable to be sent to CT#87-e for information and/or approval? Is TS 24.546 sufficiently stable to be sent to CT#87-e for approval? Is TS 24.547 sufficiently stable to be sent to CT#87-e for approval? Is TS 24.548 sufficiently stable to be sent to CT#87-e for information and/or approval?
C1-200449	Obtain list of users based on location	Samsung / Sapan	pCR 24.545 Rel-16
C1-200450	Annex to describes the functionality expected from the HTTP entities	Samsung, Intel / Sapan	pCR 24.547 Rel-16
C1-200523	Latest reference version of draft TS 24.545	Huawei, HiSilicon /Christian	draft TS 24.545 Rel-16
C1-200524	Latest reference version of draft TS 24.548	Huawei, HiSilicon /Christian	draft TS 24.548 Rel-16
C1-200526	Off-network procedures for SEAL location management	Huawei, HiSilicon /Christian	pCR 24.545 Rel-16
C1-200527	Off-network procedures for SEAL network resource management	Huawei, HiSilicon /Christian	pCR 24.548 Rel-16
C1-200552	Fetching location reporting configuration	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16	Merged into C1-20774
C1-200553	Structure and data semantics for fetching location reporting configuration	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16	Merged into C1-20774
C1-200554	On-demand location reporting procedure	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16
C1-200555	Structure and data semantics for on-demand location reporting procedure	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16
C1-200556	Location reporting event-triggered configuration cancel procedure	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16
C1-200557	Location information subscription procedure	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16
C1-200558	Structure and data semantics for location information subscription procedure	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16
C1-200559	Event-triggered location information notification procedure	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16
C1-200560	Structure and data semantics for Event-triggered location information notification procedure	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16
C1-200561	On-demand usage of location information procedure	Huawei, HiSilicon / Chen	pCR 24.545 Rel-16
C1-200562	MBMS bearer announcement over MBMS bearer procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16
C1-200563	MBMS bearer quality detection procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16
C1-200607	Latest draft version of TS 24.547 ver 1.0.0	Intel / Vivek	pCR 24.547 Rel-16
C1-200609	Updates to Client User Authentication Procedure	Intel / Vivek	pCR 24.547 Rel-16
C1-200611	Updates to Server User Authentication Procedure	Intel / Vivek	pCR 24.547 Rel-16
C1-200612	Updates to Client Token Exchange Procedure	Intel / Vivek	pCR 24.547 Rel-16
C1-200613	Updates to Server Token Exchange Procedure	Intel / Vivek	pCR 24.547 Rel-16
C1-200614	Off Network Procedures for Identity Management	Intel / Vivek	pCR 24.547 Rel-16
C1-200615	Resolution of editor's note under clause 6.2.2.2.1	Huawei, HiSilicon /Christian	pCR 24.548 Rel-16
C1-200616	Resolution of editor's note under 6.2.2.2.3	Huawei, HiSilicon /Christian	pCR 24.548 Rel-16
C1-200617	General on unicast resource management	Huawei, HiSilicon /Christian	pCR 24.548 Rel-16
C1-200633	Adding access token in proper header of HTTP request from client	Samsung / Sapan	pCR 24.544 Rel-16
C1-200634	XML schema for SEAL group document and update coding	Samsung / Sapan	pCR 24.544 Rel-16
C1-200635	Updating client side procedures based on XML schema	Samsung / Sapan	pCR 24.544 Rel-16
C1-200636	Location based group creation procedure	Samsung / Sapan	pCR 24.544 Rel-16	See also: C1-200449
C1-200637	Parameters for group event subscription and notification	Samsung / Sapan	pCR 24.544 Rel-16
C1-200638	Procedures for management of group events subscription	Samsung / Sapan	pCR 24.544 Rel-16	Related to C1-200637
C1-200639	Procedures to notify group events	Samsung / Sapan	pCR 24.544 Rel-16	Related to C1-200637
C1-200640	Removal of clause for security parameter	Samsung / Sapan	pCR 24.544 Rel-16
C1-200641	Group announcement and join procedure	Samsung / Sapan	pCR 24.544 Rel-16
C1-200642	Group member leave procedure	Samsung / Sapan	pCR 24.544 Rel-16
C1-200643	Removal of editor’s note for off-network	Samsung / Sapan	pCR 24.544 Rel-16
C1-200644	Update references	Samsung / Sapan	pCR 24.544 Rel-16
C1-200645	XML schema for VAL user profile document and update of coding	Samsung / Sapan	pCR 24.546 Rel-16
C1-200646	XML schema and coding for VAL UE configuration document	Samsung / Sapan	pCR 24.546 Rel-16
C1-200647	Management of configuration event subscription	Samsung / Sapan	pCR 24.546 Rel-16	Related to C1-200649
C1-200648	Procedure to notify configuration management event	Samsung / Sapan	pCR 24.546 Rel-16	Related to C1-200649
C1-200649	Parameters for configuration event subscription and notification	Samsung / Sapan	pCR 24.546 Rel-16
C1-200650	Corrections in procedures	Samsung / Sapan	pCR 24.546 Rel-16
C1-200651	Removal of editor’s note for off-network	Samsung / Sapan	pCR 24.546 Rel-16
C1-200660	Latest draft version of TS 24.544 ver 1.0.0	Samsung / Sapan	pCR 24.544 Rel-16
C1-200662	Latest draft version of TS 24.546 ver 1.0.0	Samsung / Sapan	pCR 24.546 Rel-16
C1-200676	Workplan for SEAL	Samsung / Sapan	Work Plan
C1-20774	Update to Event-triggered location reporting procedure	Huawei, HiSilicon /Christian	pCR 24.545 Rel-16	Revision of C1-200608
C1-200775	Update to structure and data semantics for event-triggered location reporting procedure	Huawei, HiSilicon /Christian	pCR 24.545 Rel-16	Revision of C1-200610
Other Rel-16 non-IMS issues	Peter – Main	Other Rel-16 non-IMS topics Only revision of agreed CRs from the ad-hoc meeting and DISC paper supporting LS
C1ah-200024	Correction for misalignment of 23.041 with 23.007 and 23.527	Ericsson, one2many / Ivo	CR 0204 23.041 Rel-16	Agreed
C1ah-200064	Correction on T3402 for deactivated value	Huawei, HiSilicon/Lin	CR 3321 24.301 Rel-16	Agreed
C1ah-200186	Correcting reference	BlackBerry UK Ltd.	CR 0128 24.007 Rel-16	Agreed Revision of C1ah-200136 _________________________________________ Revision of C1ah-200134 _________________________________________ Revision of C1ah-200010
C1ah-200207	Correcting active flag and signalling active flag wording	BlackBerry UK Ltd.	CR 3314 24.301 Rel-16	Agreed Revision of C1ah-200193 _________________________________________ Revision of C1ah-200185 _________________________________________ Revision of C1ah-200128 _________________________________________ Revision of C1ah-200015
C1ah-200209	Correct UE behavior when maximum number of active EPS bearer contexts is reached and the upper layers request more DRBs	BlackBerry UK Limited	CR 3317 24.301 Rel-16	Agreed Revision of C1ah-200184 _________________________________________ Revision of C1ah-200125 _________________________________________ Revision of C1ah-200052
C1-200308	Removal of Duplicate Service Operation Details	Cisco Systems Belgium	CR 0207 23.041 Rel-16	Postponed New CR under TEI16, out of scope for this meeting
C1-200606	Considerations for AML over SMS in roaming scenarios	Apple	discussion Rel-16	Postponed New input DISC on TEI16, out of scope of this meeting
WIs for IMS	Joergen – Breakout
MCCI_CT	Mission Critical Communication Interworking with Land Mobile Radio Systems Is TS 29.582 sufficiently stable to be sent to CT#87-e for approval?
C1-200369	Remove editor's note – clause 4.1	FirstNet / Mike	pCR 29.582 Rel-16	Current status agreed
C1-200370	Remove editor's note – clause 4.2.2	FirstNet / Mike	pCR 29.582 Rel-16	Current status agreed
C1-200371	Remove editor's note – clause 6.3.2.1	FirstNet / Mike	pCR 29.582 Rel-16	Current status agreed
C1-200912	Non-3GPP Message for Data interworking	Sepura, Hytera Communications Corp.	pCR 29.582 Rel-16	Current status agreed Revision of C1-200366 _________________________________________ Jörgen (Friday 14:47): A few comments: The new annex Y is to a large extent a copy of 24.282 annex D. Why not just reference annex D and specify the extensions? X.1.1 bullet 6): Is this going to MC service users? Or is it going to a user homed in the IWF? Kit (Friday 15:14): Mike has also raised the first point. There is no change to the body text to the XML schema from 24.282 . The only change to the detail of the 24.282 annex D text is in the semantics & extension sections of the usage of AnyExt to carry the Interworking Security Data Message. I wasn’t sure from the Reno discussion as to whether this was do-able. Happy to simplify by referring to the existing 24.282 schema A resulting question – do we actually need an IANA registration if we can refer to 24.282, re-use the XML schema and only change the semantics & extension description X.1.1 bullet 6) – this is a message generated by the IWF towards MC service users. [In reality, IWF will be triggered to generate it by some unspecified Key Management activity on the LMR side]
C1-200913	SDS media plane message handling by IWF	Sepura, Hytera Communications Corp.	pCR 29.582 Rel-16	Current status agreed Revision of C1-200367 _________________________________________ Jörgen (Friday 14:50): In 9.2.3 it is stated that SDS over media plane is not supported. So what do we need clause 16 for? If we need it, isn't it better to just state "no media plane procedures specified"? Kit (Friday 15:03): That would be OK. As François, I think, pointed out in Reno, there will be an eventual need to support it for the reasons given in the introduction, so I believe that leaving clause 16 in as a placeholder is useful. Clause 16 could just become "no media plane procedures specified in the present document.", with no 16.1 etc.
C1-200946	Remove editor's note – clause 6.6.2	FirstNet / Mike	pCR 29.582 Rel-16	Current status agreed Revision of C1-200372 _________________________________________ Jörgen (Friday 14:59): Why not remove "in the present document"? I think it only confuses the reader, as we don't talk about the document but about the IWF. Mike (Friday 16:59): Good comment. I will remove those words in a revision.
C1-200948	Remove editor's note – clause 8.3.2.8	FirstNet / Mike	pCR 29.582 Rel-16	Current status agreed Revision of C1-200373 _________________________________________ Jörgen (Friday 14:59): "Not supported" is not a response code I know about, which response code is intended? Mike (Friday 17:04): The simplest solution is just deletion of the EN and not include a new NOTE. Would that be acceptable?
MCProtoc16	Joergen – Breakout	Protocol enhancements for Mission Critical Services for Rel-16
C1-200357	Correcting SIP related terminology	Ericsson / Nevenka	CR 0543 24.379 Rel-16	Current status agreed
C1-200358	Correcting SIP related terminology	Ericsson / Nevenka	CR 0089 24.281 Rel-16	Current status agreed
C1-200359	Correcting SIP related terminology	Ericsson / Nevenka	CR 0099 24.282 Rel-16	Current status agreed
C1-200805	Corrections to TDC2 and TDC3 timer handling	Samsung	CR 0116 24.282 Rel-16	Current status agreed Revision of C1-200715 _________________________________________ Jörgen (Monday 11:29): Is this CR related to eMCData2, or should do you need to change to MCProtoc16? Kiran (Monday 16:07): No issues, we can change to MCProtoc16. Please note that - I took the new revision (tDoc no: C1-200805) with change in WI code from eMCData2 to MCProtoc16. I will upload the revision by tomorrow.
C1-200838	FEC encoding by the BM-SC	ENENSYS	CR 0068 24.581 Rel-16	Current status agreed Revision of C1-200709 _________________________________________ Sapan (Thursday 15:50):In TS 24.581 - clause 4.2.3.3.1 already contains the similar text which has been proposed in this contribution: "The participating MCVideo function can apply forward error correction to the media packets before transmitting them over MBMS, or it can ask the BM-SC to apply forward error correction application as described in 3GPP TS 23.280 [12]." Not able to understand why we need to mention similar text again in clause 10.4.1? Mike (Thursday 18:25): I agree with Sapan. Based on his comment below, perhaps a revision of this CR could simply delete the note. Christophe (Monday 17:11) Thanks Sapan, Mike for pointing that out. I will submit the suggested revision (just delete the note) if there is no additional comments.
C1-200952	Check for controlling function identity in 10.1.1.3.1.1	FirstNet / Mike	CR 0547 24.379 Rel-16	Current status agreed Revision of C1-200377 _________________________________________ Jörgen (Monday 14:10): I think the WI should be MCProtoc16
C1-200954	Correct clause reference in 11.1.1.3.1.2	FirstNet / Mike	CR 0549 24.379 Rel-16	Current status agreed Revision of C1-200379 _________________________________________ Jörgen (Monday 14:10 and 14:31):I think the WI should be MCProtoc16 Aside from the previously mentioned WI issue, I think even for this kind of changes F is better than D as Cat. Mike (Monday 22:22): Agree – cat F used. WID changed to MCProtoc16 per other correspondence.
C1-200955	Correct reference in 8.3.2.6	FirstNet / Mike	CR 0100 24.282 Rel-16	Current status agreed Revision of C1-200381
C1-201006	Update on Plugtest Reported Issues	FirstNet / Mike	discussion Rel-16	Noted Revision of C1-200382 _________________________________________
MuD	Joergen – Breakout	Multi-device and multi-identity Is TS 24.174 sufficiently stable to be sent to CT#87-e for approval? Is Ts 24.175 management object sufficiently stable to be sent to CT#87-e for approval?
C1-200360	Update of OMA references	Ericsson / Nevenka	pCR 24.174 Rel-16	Current status agreed
C1-200361	Adding interactions with "Multi-Device" and "Multi-Identity" services	Ericsson / Nevenka	CR 0188 24.604 Rel-16	Current status agreed Bill acknowledged after discussion with Nevenka Thursday.
C1-200362	Adding interactions with "Multi-Device" and "Multi-Identity" services	Ericsson / Nevenka	CR 0028 24.605 Rel-16	Current status agreed
C1-200364	Adding interactions with "Multi-Device" and "Multi-Identity" services	Ericsson / Nevenka	CR 0039 24.629 Rel-16	Current status agreed
C1-200654	Call log handling, Additional-Identity	Ericsson /Jörgen	pCR 24.174 Rel-16	Current status agreed Mariusz (Thursday 12:53): So just to confirm that I’m ok with C1-200654. Mariusz (Tuesday 16:48): In 4.5.3.1 for user A and in 4.5.3.6 for user B respectively, we see this sentences proposed to be added: If the served user in the "From/To" field is an identity not registered by the UE, the UE shall deduce that the call was originated using the Additional-Identity header field. So a question for clarification, if my understanding of the intention of this pCR is correct: There are two devices of users A1 and A1 in multi-device case sharing the registered identity A, So there is a call log for this identity A, and both A1 and A2 are subscribed to this call log. If any of them (let’s say A1) is allowed to use identity C for a call (so in Additional-Identity header field), the AS-A will add the entry in the call log of identity A, but in which it will put in the “From” filed the identity C instead of A. After, the call log for identity A is synchronized among A1 and A2 Respectively in the user B side… So by the end, on both A1 and A2, it will be possible to see the call log entry for an outgoing call made with identity C (even if again the identity C is not being registered. Is this understanding correct and following the intention leading to the proposed changes in this pCR?
C1-200656	Conf indication completion	Ericsson /Jörgen	pCR 24.174 Rel-16	Current status agreed
C1-200810	Adding interactions with "Multi-Device" and "Multi-Identity" services	Ericsson / Nevenka	CR 0075 24.615 Rel-16	Current status agreed Revision of C1-200363 _________________________________________ Mariusz (Friday 15:59): Since a term of user B is needed without defining it here, a reference to 24.174 is needed to be added. Nevenka (Monday 11:41): I would like to clarify that this CR refers to user B as defined in TS 24.615, clause 3.1: User B: User B is the user who reacts to the communication waiting at subscriber B. User B is the served user for the communication waiting service. And not to user B as defined in 24.174. Mariusz (Monday 14:17): ou’re right, I didn’t noticed that. Then I’m ok with this CR. Upendra (Monday 14:31): The cover page should select the proposed change affects for UE also as it is terminal based call waiting using UDUB. If there is a revision please do the changes. Nevenka (Monday 19:07)
C1-200947	MuD MiD and CAT interactions	Orange / Mariusz	pCR 24.174 Rel-16	Current status agreed Revision of C1-200665 _________________________________________ Jörgen (Friday 15:44): This follows the general principle that the services are handled by the AS serving the borrowed identity, but is this reasonable in this case? At least for the originating network, I think that user A owns its user interface. So if user A has a setting that its own CAT overrides the CAT of the terminating side then this will override any CAT. For CDIV it is an operator option to select which to play. So essentially I think that for user B there is no impact. So for originating side no impact is better to state. In any case the MiD/MuD does not need to do anything for CAT to work, so I think "no impact" is correct.
C1-200950	MuD MiD and CRS interactions	Orange / Mariusz	pCR 24.174 Rel-16	Current status agreed Revision of C1-200667 _________________________________________ Jörgen (Friday 16:08): Similar comments as for CAT. I think user B owns it interface and then the easiest is that the same settings as for CDIV apply, see 24.183 4.6.7.1 (which I suspect has an error "also not"-->"also"). So my preference is to state in 24.174 that there is no impact, and in 24.183 have similar text as for CDIV.
C1-200951	CAT interactsions with MuD and MiD	Orange / Mariusz	CR 0118 24.182 Rel-16	Current status agreed Revision of C1-200668
C1-200953	CRS interactsions with MuD and MiD	Orange / Mariusz	CR 0061 24.183 Rel-16	Current status agreed Revision of C1-200670
C1-200961	Management object correction, MuD	Ericsson /Jörgen	pCR 24.175 Rel-16	Merged into C1-201011 Revision of C1-200657 _________________________________________ Jörgen (Friday 15:34): This pCR clashes with Orange C1-200664. It is also incomplete as clause 5 needs to be included to reflect the changes in the figure. Mariusz (Tuesday 15:03): Anyway, regarding the C1-200657 itself, I believe that “?” are not needed in both leafs “SharedIdentity” and “DelegatedIdentity”. The occurrence “One” should be enough in these cases, because there is “*” in the nodes “<X> *”, meaning “ZeroOrMore”. So if any of these is not needed, the node at the <X> level will simply not exist. And also it seems that there are some corrections in Annex A needed, since In both “<X>*” nodes the Description and DFTitle should be aligned (parameters vs. settings consequently) Occurrence should be “ZeroOrMore” not “OneOrMore”
C1-201030	MO for MuD and MiD correction	Orange / Mariusz	pCR 24.175 Rel-16	Current status agreed Revision of C1-201011 _________________________________________ Revision of C1-200664 _________________________________________ Jörgen (Friday 15:37): As stated in previous mail, this pCR collides with 0657. My comments on this one: I don't think "Activated" should be part of an MO. This parameter is something the user is able to change, and there is no way to do that using the MO. So I prefer keeping this object to inform the UE that there are identities it can use. I am not convinced that Call log URI can be used for the shared identity without a change in the call log for authenticating and authorizing the user. It will require changes to the call log function to enable it to be reached from someone else than the native identity it is serving. My view is that you can only access the call log using your native identity, but you receive information related to the identities use, clarified in C1-100654. Mariusz (Tuesday 14:45): Regarding the „Activated” leaf, I’m ok to not include it in both the cases of Shared Identity and Delegated User, and to have it up to the configuration. The draft revision doc is available in draft folder here: https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_122e/Inbox/Drafts/C-200xxx_C1-200664%20MO%20for%20MuD%20and%20MiD%20correction.doc The document describes a case where an identity Virtual A can be registered by several UEs. That is the need for having a URI so these call logs can be synchronized. Jörgen (Tuesday 17:34): I thought that we at some point concluded that the UE does not keep two different registrations? At least we removed them from the now removed annex. I wanted to keep multi-device and multi-identity trees somewhat separated in case there are different extensions in the future. I will do updates of my contribution and then we can discuss further. I suspect that it is not easy to use different identities than the native identity to reach the call log. So the outstanding question there is if anything is needed to be able to access a call log from another identity.
C1-201046	Clarifications of identity definitions and activation procedures	Ericsson /Jörgen	pCR 24.174 Rel-16	Current status agreed Mariusz confirmed Thursday 15:39 Revision of C1-200959 _________________________________________ Revision of C1-200653 _________________________________________ Mariusz (Friday 16:19): It seems a bit not clear to have it like this, that “Identity C can be an external alternative identity, a virtual identity or a non-native identity.”. Whereas in definition of non-native identity we have “The non-native identity may be an alternative identity, external alternative identity or a virtual identity.”. One thing is that identities C and D can be as well alternative identity. The definitions of identities C and D are in fact similar to the definition of non-native identity, and to me identities C and D are the subset of non-native identities of users A and B, with the differentiator that these are not registered by user. An alternative proposal could be to just say that: identity C: identity C is a non-native identity that can be used by user A and is not registered by user A and respectively for identity D? Moreover, 2nd change of pCR to clause 4.5.2 is not indicated in cover page. A proposal for extending the text as follows: The user of MiD service decides which of its identities are active and can be used for incoming and outgoing calls by changing the "Activated" attribute in the <Shared-identity> or <Delagated-user> elements in the service configuration data.
IMSProtoc16	Joergen – Breakout	IMS Stage-3 IETF Protocol Alignment for Rel-16
C1-200659	Correction of P-Associated-URI handling	Ericsson /Jörgen	CR 6412 24.229 Rel-16	Current status agreed
C1-200684	UAC for MO-IMS registration related signalling EN resolution	NTT DOCOMO INC.	CR 6413 24.229 Rel-16	Postponed Out of scope for this meeting. Please use 5GProtoc16.
C1-200963	Location information; mid-call access change	Ericsson, Deutsche Telekom /Jörgen	CR 6411 24.229 Rel-16	Current status questioned Sung, Yue, Mariusz, Hiroshi Revision of C1-200625 _________________________________________ Yue (Wed 18:31 (too early) confirmed Friday): 1. Is the latest location information contained in the PANI header field of the MESSAGE request? 2. If there is another AS (acting as B2BUA) triggered before the AS expected to receive the MESSAGE, then the P-CSCF and the concerned AS may see different ICID, in that case how does the AS correlate the MESSAGE and the ongoing session? Sung (Thursday 17:31): Please let me ask some questions on the paper: Is there a related stage 2 requirement? On the procedure, would the MESSAGE be sent only to one AS or to multiple ASes? Our understanding is that VPLMN change would not be reported via Rx. So, is the use case related to S8HR mentioned in the cover sheet valid? What do you think about including PVNI header field in the MESSAGE request? On the frequency of the MESSAGE transmission, can this flood the network? Would change to WLAN be covered? Mariusz (Friday 15:26): In addition: What exactly should be understood “determines that the UE has changed location”? It seems not fully clear based on what P-CSCF determines that. Why not to refer exactly to the new clause 5.2.x in the sentence added in clause 4.1; Second dot not needed in 7.9A.X: Examples of typical use: A network entity indicating support for mid-call updates. A downstream network entity performs the update.. Hiroshi (Monday 03:54): May I ask clarification on the use case, is it intended to provide different retails charging depending on each access and per RAT type? As Mariusz pointed out in his first bullet, determination based on location change as described clause 5.2.x could be misleading. Just to understand the condition of the support, if retail charging is influenced based on this new indicator, is it the assumption that operators have to upgrade all P-CSCF, or unexpected charging may occur? Jörgen response sent Wednesday 19:20
MCSMI_CT	Joergen – Breakout	Mission Critical system migration and interconnection
eMCData2	Joergen – Breakout	CT aspects of Enhancements to Functional architecture and information flows for Mission Critical Data
C1-200766	File distribution over MBMS - signalling control	ENENSYS	CR 0093 24.282 Rel-16	Postponed Document was LATE Revision of C1-198542
C1-200798	Key download procedrue for MCData	Samsung / Sapan	CR 0102 24.282 Rel-16	Current status agreed Revision of C1-200447 _________________________________________ Mike (Thu 20:15): There is a small editorial fix needed for C1-200447 (inherited from TS 24.379 and needing to eventually be fixed there also): 7.3.7 Sending a CSK key download message If confidentiality protection is enabled as specified in subclause 6.5.2.3.1, and if the participating MCData function received a Client Server Key (CSK) within a SIP REGISTER request for service authorisation or SIP PUBLISH request for service authorisation, the participating MCData function may decide to update the CSK. In this case, the participating MCData function shall perform a key download procedure for the CSK. The participating MCData function: 1) shall generate ana SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6]; Val (Sunday 23:42): 1) Of the 3 references to RFC 4567 in section 7.2.5, two have the reference id [45] and one has the wrong ref id [47]. 2) RFC 3428 and RFC 3481 have the same reference id [6]. At least one of them must be wrong/ 3) An occurrence of "an SIP", should be "a SIP" 4) There is a somewhat awkward mention of "a third-party SIP REGISTER". It is unclear if it is the SIP REGISTER received for service authorization and mentioned earlier. (what if the SIP PUBLISH is received instead?). Jörgen (Monday 10:06): In addition to Val's editorials: 4.7: 24.379 uses "end-to-end" with hyphen. No capital letters is needed. At least I use this kind of string for searching, so I hope we can keep them consistent. 7.3.7: "and" missing (don't copy errors from 24.379). 7.2.5: "and" missing between bullets i) and ii), and between bullets 1) and 2). I agree that the "a third-party SIP REGISTER" sounds strange. Maybe "the third-party SIP REGISTER" is better. Sapan (Monday 10:57): A new revision has been taken (new tdoc number: C1-200798). The draft revised document (after taking care of all comments) is also available in below link: https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_122e/Inbox/Drafts/C1-200798_was_0447_MCData_Key_Download_draft_v1.zip
C1-200800	Move the stored object to destination folder	Samsung Electronics Co., Ltd	CR 0113 24.282 Rel-16	Current status agreed Revision of C1-200705
C1-200801	Included absolute URI associated with the media storage function of MCData content server	Samsung	CR 0066 24.483 Rel-16	Current status agreed Revision of C1-200712
C1-200802	Included absolute URI associated with the media storage function of MCData content server	Samsung	CR 0135 24.484 Rel-16	Current status agreed Revision of C1-200713 Jörgen (Monday 10:56): An editorial: First change, move the "and" from g)iii) to h). This schema change seems not backwards compatible as the new element will not be understood by old equipment. Further, the schema is not aligned with the coding as the new element does not contain an <entry> element. I think both comments can be resolved by using the anyExt element. Kiran (Monday 15:51): Agreed and happy to include in the revision.
C1-200803	Accessing the absolute URI associated with the media storage function	Samsung	CR 0115 24.282 Rel-16	Current status agreed Mike confirmed Wednesday 17:48 Revision of C1-200714 Jörgen (Monday 10:56): A question on this CR. If a release-16 UE is in a rel-15 network, will it then be configured with the Content Server URI? If not, doesn't it need to be able to support the discovery process? So a condition would be needed that the discover function is used if it cannot find the MO. Kiran (Monday 12:55): As per our understanding, In any deployments the server should be able to serve the clients which are less than or equivalent to the server version. Below mentioned deployment scenario is not expected to happen. Mike (Monday 14:45): The text “MCDataContentServerURI> element, of the MCPTT user profile document” should not have a comma after “element”. It appears twice. Mike (Monday 14:59): If a Rel-15 client expects to find the content server as part of the MCData server, then an MCData server that it serving both Rel-15 and Rel-16 clients would need to be configured with the content server as somehow an integral part of the MCData server – otherwise, I don’t see how a Rel-15 client could manage to find the content server. And if the content server is truly external to the MCData server (and it needs to be possible), then there is no guarantee that the MCData server will know where the content server for a particular client is. Specifically, consider a mutual aid case where the MCData client is coming from another domain and is attached to a group that is in the visited domain. That visited MCData server cannot be expected to know where the user’s content server is. Moreover, there is no guarantee that the visited MCData server will be capable of handling both Rel-15 and Rel-16 clients. So, whatever mechanism is used, it needs to be backward compatible. Kiran (Tuesday 08:45, 09:04): Agree on all the comments and I shall incorporate the changes in new revision (tdoc: C1-200803). The MCData server shall be backward compatible, means it supports both the discovery procedure and pre-configuration. The Rel-16 onwards client shall use the pre-configuration, as the discovery of the content server will yield the same address always and which is known to the client via pre-configuration upfront. The Rel-15 and below clients follows the discovery procedure to determine the content server. As the pre-configuration is applicable from Rel-16 onwards. The content server is always known to the MCData server for the serving users and the content server is local to the users. Could you please provide more insight on below comment. “Specifically, consider a mutual aid case where the MCData client is coming from another domain and is attached to a group that is in the visited domain. That visited MCData server cannot be expected to know where the user’s content server is. Moreover, there is no guarantee that the visited MCData server will be capable of handling both Rel-15 and Rel-16 clients.”
C1-200804	Upload the objects to the MCData message store	Samsung, AT&T	CR 0114 24.282 Rel-16	Current status agreed Revision of C1-200711
C1-200806	The pre-establshed session modification for MCData	Samsung	CR 0117 24.282 Rel-16	Current status agreed Revision of C1-200716 _________________________________________ Jörgen (Monday 11:36): The summary of change indicates editor's notes are removed. I don't see any removed ENs. Please either remove the statement or introduce the subclauses containing the ENs in the contribution. Since you need a revision the word "implementation" has a strange spelling on cover page. The heading levels are incorrect (you use the levels from 24.379). and the first heading is 8.3.4, not 18.3.4. Kiran (Monday 16:10): I took the new revision (tDoc no: C1-200806) with review changes incorporated. Kiran (Tuesday 08:43): Agree on all the comments and I shall incorporate the changes in new revision (tdoc: C1-200806).
C1-200846	Retrieval of stored object	AT&T, Samsung	CR 0103 24.282 Rel-16	Current status agreed Revision of C1-200544 _________________________________________ Revision of C1-200448
C1-200848	Add Message Store Client subclause	AT&T, Samsung	CR 0107 24.282 Rel-16	Current status agreed Revision of C1-200531 _________________________________________ Val (Monday 7:46): For each of 0531, 0539-0544, 0548, 0550, 0705, 0711, 0714: 1) For back tracebility to Stage 2, on the front page, under either Reason for Change or Summary of Change, please indicate the sections in 23.282 (e.g. 7.13.3.1.x or 7.5.2.1.x) which represents the Stage 2 for each of the CRs 2) Search each CR for "clarification;" and if found, replace with "clarifications:" where appropriate (i.e. add a "s" and change the semicolon to colon). In 0540, search for "is be" and replace with "is to be" In 0711, there are list items 1), 2) and 4). What happened to 3) ? In 0714, there are at least 4 occurrences of "MCPTT". Should they be "MCData"? Val (Tuesday 01:07): Change title "X.X General" to "X.1 General" and add an Editor's node stating that text will be added in that section. Change title "X.X MCData message store functions and client procedures" to "X.2 MCData message store functions and client procedures"
C1-200856	Delete Stored Object(s) in MCData message store	AT&T, Samsung	CR 0106 24.282 Rel-16	Current status agreed Revision of C1-200475 Mike( Thu 19:16): I believe that the set of CRs on the Message Store procedures in Agenda Item 16.3.6 need some work before acceptance. I have privately sent a previous version of this list of concerns to the authors before the start of this e-meeting. I hope that all of us who are concerned with MCData can assist in either determining that these concerns are not valid, or find ways to improve the CRs in this agenda item to resolve them. There are no checks to make sure that the source files/folders are permitted to the MCData client. There are no checks to make sure that the destination folder is permitted to the MCData client. The stage 2 indicates that the MCData server can also place content into the Message Store. There will be a need to carry the MCData ID on the PUT request to the Message Store Function – that is not currently evident. As a corollary, if the Message Store Function needs to return an error to the MCData server, the MCData server procedures must be able to handle those errors. Based on the above, there is also a question of the destination of any content inserted into the Message Store by the MCData server – it would seem that a default location(s) should be specified. If the MCData server attempts to use a different location, permission for storing into that location should be checked relative to the MCData ID. It can be foreseen that the MCData server could be storing content into the Message Store that is both “sent to” and “sent by” the MCData user. This would imply the need to require that content sent by a different MCData user appear in only a specified “inbox” type of folder, with a record of the MCData user that sent it and a timestamp. This implies further that the MCData server must be able to indicate the MCData ID of the sender, as well as the MCData ID of the MCData user that will “own” that content once it is stored. It would also seem reasonable that an SDS message that the user sends and indicates a copy should be saved would be stored by the MCData server in a “sent” type of folder as a default. In addition, there are a number of editorial issues that we can sort out, once these more important questions are answered. I also may not have caught all of the technical issues (or may have some misunderstandings of some of these). Your technical review of these CRs is needed – and once we have reached conclusions on changes to be made, we need to be ready to assist the authors, so that appropriate revisions of these CRs can be agreed by the end of this e-meeting. Shahram (Thu 22:41): Looking at your list below, I wonder if your listed concerns are mainly around the interactions between MCData Server and MCData Store (MCDATA-8) whereas all the uploaded CRs (e.g. C1-200544) are about interactions between a message store client and the MCData Store (MCDATA-7). Please see TS 23.282, Subclause 7.13 “Operations on MCData message store” for the operations which the uploaded CRs are trying to cover. For example: C1-200544 is addressing TS 23.282 operations “MCData retrieve a stored object request” & response as specified in Subclauses 7.13.3.1.1 & 7.13.3.1.2 respectively. Regarding authorization concern – In order to allow the message store client access the end-user’s message store area (e.g. source or destination folders/files), the message store client would need to obtain in advance, the end-user’s consent which would then need to be present as an OAuth access token in the authorization header of the HTTP request (as stated in Note 1 in the CRs). Regarding MCData ID- The end-user’s identity (MCData ID) is also included in the OAuth access token and also the end-user’s identity (i.e. called {boxId} in OMA NMS) is part of the HTTP RequestURI in referenced OMA NMS spec. So, every RESTful operation invoked by the message store client onto a user’s message store area (over MCDATA-7), contains the identity of the end-user and the consent of the end-user (owning the given message store area). I hope the above clarification is of help in crossing out some (hopefully most) of your listed concerns. Lastly, in future meetings we intend to bring in CRs which will address the MCData Server to the MCData Store (MCDATA-8) interactions. Mike (Thu 00:19): It is my hope that the MCData-7 (client to message store function) and MCData-8 (MCData server to MSF) interfaces are the same protocol. The same HTTP PUT/GET/POST/DELETE/… will be seen by the MSF. When the HTTP message arrives from the MCData server, the MSF should know that it is communicating with the MCData server and will retrieve some information about who the actual client is, the client whose message store is the target for the PUT. If you believe that the MCData-7 and MCData-8 interfaces are different, then it means that Short Data Service (SDS) messages cannot be stored in Rel-16 by the MCData server. The client will have to receive them and then send them to the MSF on its own – a waste of network resources as each such message traverses the radio an extra time. It also means that SDS messages that arrive while the user is unregistered to the MCData server will have to be queued in some other location than the MSF. My comments assume a common protocol that can be used by both the client and the MCData server to communicate – in a client role – with the MSF. If you believe in that model, then my comments and concerns apply. If you believe in some other model, please let me know what it is. Shahram (Fri =2:53MCData-8 & MCData-7 interfaces reuse the same OMA RESTful API. However, the Operations over MCData-8 would be limited to “POST ../objects” for depositing objects into MCData store vs all sorts of objects/folder operations supported over MCData-7. Operations over MCData-8 i/f would be authorized by OAuth “client-credential” flow which ensures that MCData server is authenticated/identified and has the authority to make message deposits into the MCData message store for any end-user (i.e. OAuth access token used by MCData server has a scope value allowing access to the entire MCData message store). On the other hand, the end-user is identified to the MCData message store through the requestURI’s {boxId} parameter which is sent by the MCData server over “POST ../objects” operation towards the MCData message store. See example below where {boxId}= tel:+19585550100 (i.e. MCData ID) identifying a particular user’s message box for depositing a message. POST /exampleAPI/nms/v1/MCDataStore/tel%3A%2B19585550100/objects Jörgen (Fri 14:42): I have a few editorials that can be considered in a future revision: General comment: At least some statements that the message store client uses HTTP over TLS don't need to be repeated, so I think some information can go into a general section for message store. Maybe some text could be added to 0531 and removed from all other contributions? Good to mark the Editor's Notes with WI and CR#. Looks like the sentence after the first EN is incorrectly formatted, should be "Normal" style. "a HTTP" appears twice. Curly quotes should be changed to straight quotes. I think "as describe" should be "as described". Shahram: Thanks for your comments. Good idea to put the repeated statements from the CRs into the general section of TDoc 0531 only once. The CR revisions will take care of your comments.
C1-200858	Update Object(s) in MCData message store	AT&T, Samsung	CR 0105 24.282 Rel-16	Current status agreed Revision of C1-200550 Revision of C1-200474
C1-200860	Search for Objects in MCData message store	AT&T, Samsung	CR 0104 24.282 Rel-16	Current status agreed Revision of C1-200548 Revision of C1-200473
C1-200863	Copy stored object(s) and-or folder(s)	AT&T, Samsung	CR 0108 24.282 Rel-16	Current status question Francois to confirm Revision of C1-200539 _________________________________________ Francois (Fri 10:51): I have the following additional comments on this CR, and most apply similarly to all similar CRs: The first paragraph and NOTE for both the Client and the Server clauses are generic for all procedures and should be put in a General clause rather than being repeated in the exact same way in each clause (all message store procedures CRs). Second paragraph is missing some words after “using” (To copy object(s) and/or folder(s) to a destination folder in message store using, the message store client…) NOTE 2 should be in active form rather than passive form. And why is it in a NOTE and not part of the previous paragraph that states what shall be done by the client when the response is received ? Is that part optional ? Also in NOTE 2, reference to 5.2.3.13 of the OMA spec (which the type definition for TargetSourceRef if I am not mistaken) does not seem to be needed, it may be implied by 5.4.4 clause of the OMA spec but not on its own. Also 5.4.4 just gives the high level view of the procedure, and I don’t see what other processing it implies, that the client, or the server should follow. If it is a better refenrece than 6.18.x, then why not use this one (5.4.4)
C1-200864	Creating new folder	AT&T, Samsung	CR 0109 24.282 Rel-16	Current status agreed Revision of C1-200540
C1-200866	Delete folder	AT&T, Samsung	CR 0110 24.282 Rel-16	Current status agreed Revision of C1-200541
C1-200867	Move object(s) and folder(s)	AT&T, Samsung	CR 0111 24.282 Rel-16	Current status agreed Revision of C1-200542
C1-200869	Search for Folders in MCData message store	AT&T, Samsung	CR 0112 24.282 Rel-16	Current status agreed Revision of C1-200543
E2E_DELAY (CT4)	Joergen – Breakout	CT Aspects of Media Handling for RAN Delay Budget Reporting in MTSI 100%
VBCLTE (CT3 lead)	Joergen – Breakout	Volume Based Charging Aspects for VoLTE CT
ISAT-MO-WITHDRAW	Joergen – Breakout	Withdrawal of TS 24.323 from Rel-11, Rel-12, Rel-13 No CRs needed, listed for the sake of completeness 100%
MONASTERY2	Joergen – Breakout	Mobile Communication System for Railways Phase 2
C1-200409	Automatic group affiliation and deaffiliation based on location or functional alias	Kontron Transportation, Nokia, Nokia Shanghai Bell	CR 0064 24.483 Rel-16	Current status agreed Jörgen (Mon12:04): Can you just explain what are the criteria for setting the status parameter to "optional" or "required"? Peter B (Mon 16:26): Provided list of leaves with details of which are mandatory or not. This list indicates that a revision may be needed. Revision of C1-198847 Jörgen (Monday 20:44) Child leaves can be required for an optional parent if parent does not make sense without its children, see OMA-TS-DM_TND-V1_3-20160524-A Peter (Tuesday 11:42) and Jörgen (Tuesday 14:01) seem to be in agreement.
C1-200410	Automatic group affiliation and deaffiliation based on location or functional alias	Kontron TransportationS, Nokia, Nokia Shanghai Bell	CR 0541 24.379 Rel-16	Current status agreed Revision of C1-198803
C1-200749	Work plan for the CT1 part of MONASTERY2	Nokia, Nokia Shanghai Bell	discussion Rel-16	Noted
C1-200750	Analysis of options for FA resolution	Nokia, Nokia Shanghai Bell	discussion Rel-16	Noted Francois (Friday 11:33): I have the following comment on the discussion paper about Functional Alias resolution for call routing: I believe that It can only be resolved on demand. How would a server know it will need information for a given alias ? Even if once it has received the information, it is cached locally, the on demand resolution is needed in first place. And then it is enough. Caching the information locally would just require processing for storing and updating the information, with possibly any future use of that information (nothing guaranties that the same FA will ever be used again in the future). Moreover, FA resolution is needed for first to answer call which is not time critical (because there is no risk to loose the beginning of the conversation as it is the case for a chat group call set up for instance), so taking few ms to resolve the FA is not an issue. If needed implementation can improve the process beyond the standard (with appropriate IT set up) So I suggest that a solution that fetches the FA data when needed (SUBSCRIBE with Expires=0) is the best thing to do.
C1-200752	Update service configuration to support limiting the number of authorized clients per MCPTT user	Nokia, Nokia Shanghai Bell	CR 0136 24.484 Rel-16	Postponed Document was LATE
C1-200886	Automatic group affiliation and deaffiliation based on location or functional alias	Kontron Transportation, Nokia, Nokia Shanghai Bell	CR 0132 24.484 Rel-16	Current status agreed Revision of C1-200408 Jörgen (Mon11:46) Mix of editorial and other comments: 8.3.2.1: "and" needed to connect e)i) and e)ii) and to connect f) and g) (the "and" you deleted but not reintroduced. Please remove the space before ">" in new elements. I am happy if you also fix the existing such errors. The XML schema is not valid (not even well formed), some end tags for complexType and sequence don't match. Hard spaces missing after subclause and in references. The Data Semantics change does not match the XML schema. For example, the <ListOfLocationCriteria> name is different from <xs:element name="LocationCriteriaList", and Speed is not part of EnterSpecificArea, but has to be under an anyExt. Please check. Revision of C1-198846 Peter (Tuesday 11:33): thanks for your comments, I have included all of them, and uploaded a draft draft-C1-20xxxx-was-200408.zip in the draft folder.
C1-200982	Support of functional alias in first-to-answer calls	Nokia, Nokia Shanghai Bell	CR 0551 24.379 Rel-16	Current status agreed Revision of C1-200751 _________________________________________ Francois (Friday 11:53): In 11.1.1.2.1.1 in step 10, how can IDs and FAs be distinguished should be indicated here. It is only described in step 15 so the reader here wonders how ID and FA are distinguished. A NOTE can be added for instance, not to modify the steps ordering. The word “calling” in <calling functional alias> is ambiguous, as usually it refers to the calling party, not to the called party (even if here it is the action of calling, not the state of being the caller) Better wording would help (e.g. something like <FA addressing> ?) In 11.1.1.4.1 – Step 3a applies only to First to answer call. And in that case there shall be one INVITE for each MCPTT ID who has activated the called functional alias. The proposed wording is misleading as it looks like an expand/copy of the list of all targeted MCPTT ID in one outgoing INVITE, and not in individual INVITEs. To be consistent with Step 4, the proposed step 3a should rather be a Step 4a, that copies each MCPTT ID associated with the FA to the request-uri of on SIP INVITE (multiple outgoing INVITEs) In 11.1.1.4.1, the NOTE 2 after Step 3a (-> 4a) ?) should rather be an Editor’s Note. The procedure will not work without that being specified. In F.1.3. SEMANTIC, the <calling functional alias> is only compatible with First to answer call and default value is “false”.. Add a paragraph to indicate that if omitted, it means that IDs are used (like the statements about broadcast, emergency-ind, etc…)
C1-201022	IP Connectivity	Kontron Transportation	CR 0101 24.282 Rel-16	Current status agreed Revision of C1-200412 _________________________________________ Francois (Friday 11:25): I have the following comments on the CR introducing IP connectivity procedures : In 2.1.1 - I think resources shall be allocated (non GBR resources, but with its own priority and parameters so that it does not interfere with SIP signalling on the default bearer) = > Port shall not be zero Media plane procedures shall be added, which are essentially forwarding after whatever check is needed (size, time,…) so in 20.3.1 / processing the 200 OK step 9, the routing or transmission control are needed => SHALL interact (and 20.3.2 step 8, 20.4.1 step 1 and 20.4.2 step 9) An editor’s note shall also be added in 24.582 to indicate that media plane procedures for IP connectivity shall be added and are FFS. I think that without its own bearer parameters and without the hop by hop routing and control procedures, the feature does not deliver what it is aimed for. Jörgen (Monday 12:04): In addition a number of comments from me: 4.1: Why IP Data, not just only Data? a IP->an IP. hard space after clause Please do not use capital letters for Participating and Controlling in text. 20.1.1: "wants to" is stranged for a client. decides to? Please do not use "it" in normative statements, better to state explicitly which entity is required to perform the action.. offer/anser is somewhat unclear. Better to state offer or answer as applicable. The note is missing "It" in the beginning? 20.1.2: To me this is hard to read. Isn't it better to separate the participating function actions and the controlling function actions? It has to be clear which function performs the action. 20.2.1: First sentence lacks a subject. Possibly "the MCData client" is missing before the shall. Why is 480 used? The text "transmission failed" is not consistent with the cause "480". Failure-Cause in 24.229 has a media bearer lost indication. 20.2.2: Some formatting issues, a B2 that should be B1<TAB>at end of 1) and a B1 that should be Normal after bullet 10).
C1-201056	Update service authorization procedures to support limiting the number of authorized clients per MCPTT user	Nokia, Nokia Shanghai Bell	CR 0552 24.379 Rel-16	Current status agreed Revision of C1-200983 _________________________________________ Revision of C1-200753 _________________________________________ Jörgen (Mon 13:44): I think the text in bullet 2a is strange. You start with checking if the number of simultaneous authorizations is equal to and element, and then "has been reached" is coming which looks strange to me.
eIMS5G_SBA	Joergen – Breakout	CT aspects of SBA interactions between IMS and 5GC
C1-200353	No impact from SBA on main body	Nokia, Nokia Shanghai Bell, Ericsson	CR 6408 24.229 Rel-16	Current status question Yue to confirm Yue (Wed 18:23, confirmed Fri 02:22 this is for the meeting): IMO, the main body of 24.229 needs some update: EXAMPLE 1: "If the S-CSCF receives a Diameter result code of DIAMETER_UNABLE_TO_COMPLY as defined in 3GPP TS 29.228 [14], the S-CSCF supports S-CSCF restoration procedures, and the Request-URI of the request does not match an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031 [69], then the S-CSCF shall...." what is the equivalent condition when N70 interface is used? EXAMPLE 2: When defining extension to Reason header field, we have protocol /= "EMM" / "ESM" / "S1AP-RNL" / "S1AP-TL" / "S1AP-NAS" / "S1AP-MISC" / "S1AP-PROT" / "DIAMETER" / "IKEV2" / "RELEASE_CAUSE" / "FAILURE_CAUSE" If my understanding is correct, the "DIAMETER" is used when certain Diameter cause value is mapped into some SIP cause value, then how about HTTP? Peter L (Friday 13:11): On comment 1: this is likely one of those cases where 24.229 went too much into DIAMETER details and now we are stuck. IMHO, the following text in the annex covers what is needed “While the main body of the present document only describes usage of Diameter Rx and Cx and Sh reference points, the usage of the equivalent SBA services is a valid option.” Yue response (Friday 14:26): This text does not provide detailed enough information. There is description on N70 is equivalent to Cx interface, however I still don't know what is the equivalent HTTP error (maybe plus application error) to DIAMETER_UNABLE_TO_COMPLY in this specific case. Peter L response to above (Friday 16:32): let me check the progress of the N70 and see whether I can address your concern. On comment2: this is about the values that are provided to P-CSCF from Rx, defined in 29.274 subclause 8.103. It is actually to indicate errors that happened on the access network protocol. IIRC, then DIAMETER is used in some WLAN case. I would assume that N5 supports the same values as Rx, and assume that there is no impact on P-CSCF, N5 would report DIAMETER for the same use cases as if there is Rx. I am not aware that we need HTTP. Yue response (Friday 14:26): Well, I may need education. I am not aware that N5 interface can report DIAMETER casue code, could you please indicate me where it is specified? Peter L response to above (Friday 16:32): the DIAMETER cause code is used for some trusted wlan /TWAN case. In case this use case is supported by 5GC, then N5 needs to support reporting it, if the use case is not supported, then there is no need for it
enh2MCPTT-CT	Joergen – Breakout	Enhancements for Mission Critical Push-to-Talk CT aspects
C1-200375	Ambiguity of location information in 6.3.2.1.4	FirstNet / Mike	CR 0545 24.379 Rel-16	Withdrawn Jörgen (Monday 14:10): Is the new note needed, I think it is clear from the context. I think the WI should be MCProtoc16
C1-200376	Calling party location	FirstNet / Mike	CR 0546 24.379 Rel-16	Withdrawn Jörgen (Monday 14:10): Why is bullet 14) deleted? I didn't see this in the reasons for change. Should there be a condition instead in the bullet? Otherwise the reason for change or summary of changes can say somthing. In the bullet 15) where new text is added. Isn't the new text a new separate bullet? I think this document is not this WI. Reason for change indicates it is essential, and then it is out of scope for this meeting, or if not essential it is IMSProtoc16.
C1-200956	Check for groups that are already regrouped	FirstNet / Mike	CR 0548 24.379 Rel-16	Current status agreed Confirmed Wednesday 10:50 by Francois Revision of C1-200378 Francois (Fri 12:12): Step 2 indicates that the NCF shall determine if the constituent group has already been regrouped. Stage 2 has identified that “regrouped” is a dynamic data of the group. Should steps be added in the regrouping procedure at (non-)controling server to store that information ? If a group has been regrouped, then it does not only affect this procedure, but also the call set up procedures (at CF) to prevent a call set up on a (constituent) group that has been regrouped, as per stage 2 procedures. And if it is a chat group, does it mean that the session shall be torn down ?
C1-200949	Affiliation in a regroup	FirstNet / Mike	CR 0544 24.379 Rel-16	Current status question Francois to confirm Revision of C1-200374 Francois (Fri 12:05): I have the following comments on the CR on affiliation to a constituent group : Clause 16.2.4.3 should be referenced from the controlling procedure that manages affiliation to the group (9.x.x). In that procedure 9.x.x procedure, it should be checked if the group is regrouped from the dynamic data associated to the group (to be added as per comment to C1-200378). + Step 1 : why a “separate” list ? Clause 16.3.2.4 Step 3, there should be at least a NOTE to indicate that if the user has already been notified (as per the data stored in step 4), then the notification can be omitted, to avoid a quadratic effect when multiple users are affiliating one by one to a group that has been regrouped (n individual affiliations would imply n(n+1)/2 notifications – could lead to very large number) De-affiliation should also be considered ? Jörgen (Mon 13:49): First change, hard space needed after clause, and this is 24.379 so clausesubclause.. Should 4) state group regroup both times? I don't find the procedures referenced in 4). Which 9.2 procedures are referenced. Need to be more specific. I don't think the note is needed, but the procedure that the stored parameters are used need to be specified. As it stands it seems optional to store the paraemters but then optional to use that information. There are spaces between NOTE and ":" which should be removed. 16.2.4.3: text says "preconfigured regroup", while heading says "preconfigured group". Heading in 16.2.2.4 says "regroup",, while 16.2.4.3 says "group regroup". Bullet 7): Remove "for this participating MCPTT function as". Bullet 8): Create how? Which element does it take? 16.3.2.4: Undelete "and" after 3)g). Same comment as above on 9.2 procedures. Mike (Monday 18:27): @ François: Since referencing 16.2.4.3 from the controlling procedure would not, as far as I can see, affect the outcome of the procedure, I believe that we can leave the addition of that reference to a later meeting. Regarding the use of “separate” – I have deleted that word in the revision I am preparing. Modifications also as commented by Jörgen. Regarding the PF using stored information to avoid notification to a client that is already aware of the user regroup, I have modified step 3 to: 3) for each MCPTT ID contained in the <users-for-regroup> element of the application/vnd.3gpp.mcptt-regroup+xml MIME body, if the terminating participating MCPTT function is aware from stored information that the MCPTT client has not previously been notified of the creation of the user regroup: Jörgen (Monday 21:55): OK with the changes. Minor correction agreed
C1-200977	Missing client procedures for preconfigured regroup	FirstNet / Mike	CR 0550 24.379 Rel-16	Current status agreed Revision of C1-200957 Revision of C1-200380 Francois (Fri 12:25): I use this contribution as a reference to express comments related to the regrouping procedures in general, as I think some some pieces of puzzle are missing to deliver a fully actionable specification : What if the regrouped group is a chat group ? When is the join done, and which entity triggers the session set up ? How are users aware of the template group ? Are template groups (identified as such by a parameter in the group document as per stage 2) defined with a list of users, that would trigger the mechanism for distributing the information (group would be listed in the user profiles and client would get the group document of the template at each users’ UE) ? That group document is needed at the Clients to get the key to be used by the regrouped group (this was the reason for changing the procedure) Or are those groups declared without any member, and then what is the mechanism for making potential users aware of that template group (and of the group key…) ? As per current procedures, the CF is checking the group document of the target group at call set up. But for the Regroup there is no group document created. Should that step be added in the procedures 16.2.3.1 ? What members are declared for that regroup? New document should be a copy of the template document + some special parameters ? Or shall the test be reworded to say that it does not apply to a regroup (but how does the CF knows that it is a regroup if there is no group document ?) Even if it is stated that uniqueness of the (temporary) regroup ID is done at the originating client, it could be good to have a test in the servers that there is no conflict (e.g. at the controlling server when creating the group document if so) Media plane procedures shall be added to reject a PTT request on a constituent group and send back a notification (as per stage 2, where the group call request is a PTT request if the group is a chat group) Maybe we should add editor’s notes in different places of 24.379 and 24.380 not to let people believe that the feature is fully available. This is something that could be done as CRs to the Plenary if needed. Sorry for bringing those considerations late in the process, but better late than never, in order to have good quality specifications. Mike (Friday 16:45): These are all good questions. We probably need to begin working toward an understanding and CRs for the April CT1 meeting. If any of your comments affect directly the CRs in this e-meeting, could you please point them out and offer suggested changes? Francois (Monday 10:00): No there is no direct impact to the CRs proposed for this e-meeting; Proposed changes are OK for me, I just wanted to express my opinion that more changes are needed and that the specification as it will be after this e-meeting does not work. If we think this is something that should be shown in the specification, then we will need additional CRS to include editor’s note in several places, what could be done as a contribution for the plenary. Jörgen (Monday 10:09): If you want editor's notes in the contributions, it is better to add them now rather than providing company contributions to plenary. Francois (Monday 10:53): Mike will address at least one the below comment in a revision of another CR (the absence of group document for a Regroup). Thinking twice, a NOTE in this terminating client procedure, and in the originating client procedure, indicating what is the expected client behavior (considering itself as affiliated with the regroup, replace call to the constituent group by call to the regroup, join now if the regroup is a chat group) could simply resolve the question about the regroup being a chat group.
eIMSVideo	Joergen – Breakout	Video enhancement of IMS CAT/CRS/announcement services
C1-200481	Work plan for eIMSVideo	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	discussion Rel-16	Noted
C1-200487	Work plan for eIMSVideo	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	discussion Rel-16	Withdrawn
C1-200488	Use precondition only for CAT when network disables precondition	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0116 24.182 Rel-16	Withdrawn
C1-200489	Use precondition for CAT when originating UE and network both support precondtion	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0117 24.182 Rel-16	Withdrawn
C1-200490	Use precondition for CRS when network disables precondition	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0059 24.183 Rel-16	Withdrawn
C1-200491	Use precondition for CRS when terminating UE supports or requires precondition	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0060 24.183 Rel-16	Withdrawn
C1-200492	Providing video announcement at the same time with audio conversation	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0073 24.628 Rel-16	Withdrawn
C1-200787	Use precondition only for CAT when network disables precondition	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0114 24.182 Rel-16	Postponed Revision of C1-200482 _________________________________________ Jörgen (Friday 16:36): The header field needs to be defined in 24.229, provided that we go that way. Also the profile tables need to be updated. Somewhere the inclusion of the header field needs to be specified. 24.229 I believe, but it depends on where this is to be performed. [Hongxia]: Yeah, it’s better to define the header in 24.229. I will do this when we can make sure this header is needed We have not in 3GPP specified anywhere how the network disables the use of preconditions, but it seems assumed that this is performed by the P-CSCF or S-CSCF, is this correct? This is somewhat problematic as it means that the P/S-CSCF needs not remove precondition option tag in subsequent requests and responses. So then these nodes need to understand part of the service logic. It may be better to modify the Supported header and the SDP in an AS. I think this point requires further discussion. [Hongxia]: In GSMA IR.65, it specified: “As stated in GSMA PRD IR.92 [28], the network has the option of disabling SIP preconditions. This means that any network involved in the interconnection or roaming path has that option. In that case, the considered network shall disable SIP preconditions by removing both the precondition option-tag from the SIP Supported header and the related SDP media attributes.” No doubt “any network” includes “P-CSCF”, and in practical , we really identified some networks disable the precondition by P-CSCF. And considering the relative position of P-CSCF in IMS, P-CSCF is the most possible entity which can disable precondition. So I took the P-CSCF for example in the signalling flow part, you know , the call flow is informative. More , because I do not want to make the call flow too complex, so I put P-CSCF and S-CSCF together on the call flow. If the P-CSCF allows precondition for CAT, it may identify the CAT related request or response by only detecting whether the SDP includes “g.3gpp.cat” , its complexity is similar with detecting the “precondition” in the Supported header. And it’s not possible to use precondition for CAT if we only modify the Supported header and the SDP in an AS. If the network disabled precondition totally , the AS has no way to use precondition for CAT. By removing the SDP and replacing that with a header field you break in principle the information chain that the preconditions mechanism relies on, i.e. the AS cannot know the status of the UE. [Hongxia]: Sorry, I do not understand “removing the SDP” you mentioned, I did not say removing the SDP. I just mean the network removes “precondition” option-tag from the SDP (as specified in GSMA IR.65), and insert a new header field. As specified in my new NOTE, the network element insert the new header when it removes the “precondition” option-tag from Supported header. It imply that the network insert the new header only when the originating UE supports precondition. The changed INVITE request will be sent from the network element to AS. So that the AS can know that the originating UE supports precondition and the network allows precondition only for CAT, when the AS detecting there is the new header in the INVITE request. To me it seems to be a simpler solution to just configure the AS to include the precondition option tag and SDP parameters when it adds the video media line. If the UE understands preconditions it will use it. If the UE does not it will be ignored. [Hongxia]: As mentioned above, if the network disabled precondition totally , the AS has no way to use precondition for CAT, because the “precondition” option-tag in any request/response will be removed by network. A question for the UE vendors: Is the UE able to use preconditions in the UPDATE if the network did not respond with preconditions in the reliable 183? If so I still don't think the header field is needed. [Hongxia]: Sorry, I want to give the information I have. We identified some UEs support. But I think whether the header field is needed, when the network disables precondition, is not decided by the precondition capability of UE. The bottleneck is the network. Hongxia/Helen (Friday 20:52): **Comments pasted in the above** Hiroshi (Monday 02:21): Regarding the new “Precondition-Enable header” that needs to be supported/included by P-CSCF, S-CSCF, (or any other?), I think it is better to avoid specifying only the AS behavior (in TS 24.182) where we are not clear on how the header will be provided, so I would appreciate if both are considered together. So would the CR to TS 24.229 be part of this meeting’s CR? Hongxia/Helen (Monday 04:25): I think you prefer that I define the actions of both P-CSCF and AS , so that the things around the new header is more clear. I think it’s a good idea. @Jorgen, may I add the sub clause 4.5.5.x for actions of P-CSCF or other IMS entities in 24.182? GSMA IR.65 specifies that the entity which disables SIP preconditions removes both the precondition option-tag from the SIP Supported header and the related SDP media attributes. GSMA does not specify which entity, so can be P-CSCF or other entity. Take P-CSCF for example, if P-CSCF is set that it can supports precondition only for CAT, after it receives the initial INVITE request, the actions of P-CSCF and other entity include: P-CSCF will removes “precondition” option-tag from the Supported header as IR.65, and it needs to insert the new header , then it forwards the INVITE request towards CAT AS. The other entities between the P-CSCF and the AS need not do anything to the new header. The AS send an UPDATE request using precondition towards originating UE , “g.3gpp.cat” is included in the SDP offer. The other entities between the P-CSCF and the AS forwards the UPDATE request towards the P-CSCF. P-CSCF receives the UPDATE request, and it founds there is “g.3gpp.cat” in the SDP offer, so it will not removes the precondition related parameters in the UPDATE request. You can see the above highlighted actions need to be supported by P-CSCF or other potential entity if they support preconditions only for CAT but not for general communication. Hiroshi (Monday 05:28): Yes, if it is going to be P-CSCF that takes care of inserting the new header, then I would prefer that we define it as such in the spec. I do not prefer to leave the ambiguity of which entity can insert the header, even if multiple entities can potentially delete the support of (general) precondition. It seems you have P-CSCF as the assumption Hongxia/Helen (Monday 04:25): I think P-CSCF is the most possible entity, until now, we Huawei only found P-CSCF disables precondition in some operators’ network. If we can make sure only P-CSCF can disables precondition or we 3GPP only allow P-CSCF to disable precondition, I would like to replace “the network element” with “P-CSCF”. It’s good if GSMA IR.65 can specify clearly which entity can disables precondition. Yoshihiro (Monday 15:38): I think the CSCFs does not remove the option-tag. 3GPP TS 24.229 clause 5.1.5A specifies "Precondition disabling policy". IMS networks use the Precondition_disabling_policy MO (specified in 3GPP TS 24.167, 3GPP TS 31.102, 3GPP TS 31.103) to disabling precondition mechanism. So my understanding is that, if the IMS network disables precondition mechanism, the UE turns off the capability. Hongxia/Helen (Monday 16:30): based on my understanding of 24.229/24.267/IR.92, I think the precondition_disabling_policy is only used for the UE to disable precondition. However whether the UE disables precondition is not the scenario we discussed. And I cannot find the network entity may use precondition_disabling_policy to disable precondition. In practical, the scenario "P-CSCF disables precondition by removing precondition option tag" and "UE support and does not disable preconditon" really exist. IR.65 also talks about network based disabling of preconditions. How do you understand the "network" in IR65? Jörgen (Tuesday 13:00): GSMA IR.65 focuses on network and interconnect. To avoid ambiguity they specified that both the precondition tag in the supported header and the SDP parameters related to precondition. They cannot specify how this is done or in which node without support from 3GPP. So either we do it as part of the protocol or it goes to SA2 if we think this is architecture. IR.92 has a statement that how to disable preconditions in the network is out of scope. They have a configuration option to configure the UEs. That is an alternative to have a node remove these parameters. But that relies on UE support and you only configure your own subscribers. The P-CSCF is service agnostic and hence we have not specified any service specific actions. In particular P-CSCF actions are out of scope for any of the service specifications. So all P-CSCF changes go into 24.229. So P-CSCF subclauses are out of scope of 24.182. From Ericsson's perspective, the P-CSCF is not the best place to disable preconditions. There are too many service specific actions for the general precondition handling. We prefer having all that logic in an AS. And in your solution I am not happy that the P-CSCF does not remove parameters because of specific services. For the preconditions handling, I don't see a need to inform the AS what the network supports. The AS is part of the network and the AS can have configuration parameters to know if the network supports preconditions for a particular service. For the node disabling the preconditions there is no real difference. That node will need to allow these precondition messages irrespective if a header was introduced or not. So this means that the AS can based on configuration use preconditions for these video lines.
C1-200788	Use precondition for CRS when network disables precondition	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0057 24.183 Rel-16	Postponed. Revision of C1-200484 Hiroshi (Monday 2:29): I have similar comment/question that I expressed for C1-200482 (one for CAT) on this CR as well, i.e. the clarification on the condition of which IMS entity and on the condition of the new header needs to be included. Jörgen (Monday 15:53): If the UE receives a request without precondition in the Supported header field it is no point for the UE to indicate that this is supported in the response, so I think that point has a UE impact. In responses the server part uses Require to indicate it wants to use preconditions. So I don't think the network will see any Supported: preconditions. As for the CAT, I don't think we need the header field. The CRS AS can be configured to use preconditions for adding a media line. The network needs to allow that, as for the case with the header field. If the UE does not support preconditions it will ignore this information. Hongxia/Helen (Tuesday 09:53): For the Supported header you commented, in 24.229, there is no description that the UE cannot reply a 18x response with “Supported:precondition” when the INIVTE request does not use precondition. So I think it’s possible and not disallowed by 24.229 . Yeah, the AS may add a media line at any time, but if the AS always send an request which cannot be supported by the network or UE, it will be a treat to the stability of the call procedure, and many ineffective request will be exist, so the solution without the new header is not an safety and efficiency solution. It’s best that the AS use precondition to send the UPDATE request when the AS can make sure the network and the UE both support precondition. You know the new header has two meanings: one is tell the AS that the network supports precondition, the other is to tell the AS that the UE supports precondition. Upendra (Wednesday 15:39): As mentioned in my comments for C1-200485- In step-4, if MT UE receives INVITE without preconditions, the MT UE will disbale preconditions. At step-20, UPDATE procedure is modifying the preconditions after 18x message, MT UE behvaior is to reject or per UE implementation. Theis behavior should be defined in 24.229 similar to section 5.1.4.A2 for session modification request, after 2xx, UE will reject the UPDATE with 420 (Bad Extension)
C1-201045	Use precondition for CAT when originating UE and network both support precondtion	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0115 24.182 Rel-16	Current status Question Jörgen to confirm Revision of C1-200908 _________________________________________ Revision of C1-200483 Jörgen (Monday 15:27): The use case is easy as the AS can do almost whatever. I don't think we need a call flow as the other call flow for adding video is very similar. Basically the UPDATE offer works regardless of what is used on the base call. But for preconditions I think the Require header is needed. Would be good to say something about what the SDP parameters should contain. I think that the precondition should be mentioned in the context of adding the video media line. The exact text might be dependent on how we handle the non-supported case. I don't think that you need to mention the SDP content parameter in the context of preconditions. That should already be there in the description of adding the video stream. Hongxia/Helen (Tuesday 10:51): Ok, I can remove the call flow from this CR. Did you suggest the AS includes Require:precondition in the UPDATE request? I don’t think Require shall be added, use Supported:precondition is enough. And you suggested to specify that the SDP parameters should contain…… . what information do you suggest to add ? You also suggested that the precondition should be mentioned in the context of adding the video media line, and you say “g.3gpp.cat” needn’t be added because it already there in the description of adding video stream, but I can’t find “the context of adding the video media line” or “the description of adding video stream” you mentioned in current spec. Could you help me find it? Thanks! I think all existed “g.3gpp.cat” is not duplicate with this CR.
C1-201047	Use precondition for CRS when terminating UE supports or requires precondition	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0058 24.183 Rel-16	Current status question Upendra to confirm Revision of C1-200911 Revision of C1-200485 Jörgen (Monday 16:23): Is this CR needed? If the UE uses precondition it works as normal. As before, I don't think a UE responds with preconditions in the Supported header field if the UE does not receive such header field. And then the response would be in the Require header field. Small update to some of the many existing call flows could be possible. And gateway model does not exist for CRS. There can only be one dialog on the receiving side so the wording "gateway model" should not be in 24.183. Hongxia/Helen (Tuesday 10:25): Same response with 200484: For the Supported header you commented, in 24.229, there is no description that the UE cannot reply a 18x response with “Supported:precondition” when the INIVTE request does not use precondition. So I think it’s possible and not disallowed by 24.229 . About the call flow, you know no call flow exists for the CRS using gateway model. So we has nowhere to do small update you mentioned. Sorry, I don’t understand why you say “gateway model does not exist for CRS, There can only be one dialog on the receiving side so the wording "gateway model" should not be in 24.183.”, there is already “UE Actions for gateway model” and “AS Actions for Gateway model” for CRS in 24.183. I will appreciate if you say on this comment more clearly.
C1-201048	Providing video announcement at the same time with audio conversation	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0072 24.628 Rel-16	Current status question Jörgen and Yoshihiro to confirm Revision of C1-200910 _________________________________________ Revision of C1-200486 Jörgen (Monday 16:39): This somehow redefines the term announcement, a totally parallel media stream is not really an announcement. I expect announcement to be something short and specific. Maybe we can find a better term? 4.2.3: I guess the intention is to add a media stream during session set-up? "at the same time" is very unclear to me. But the text possibly needs something more to say that this new stream is using a different media type. 4.7.2.9.1: This is subclause is about announcement during an established connection, and that means after 200 (OK), so this function should be somewhere else. And I think this needs to be formulated differently. I think it could be sufficient to state that the AS can add a media stream with a type different than any existing media types following the offer/answer mechansim. A.2: The call flows should not be added. Second call flow is wrong as re-INVITE cannot be sent before the INVITE transaction is finished. There is a difference in user experience between UPDATE and re-INVITE and that is that if re-INVITE is used the user is usually given a chance to reject the offer. If UPDATE is used there is no such chance. Hongxia/Helen (Tuesday 08:33):Why the announcement cannot be played parallel with the conversation? Why you doubt it’s not really an announcement only by when it is used? I do not think it's a good idea to give the announcement more business level limitation. How short and specific the announcement is business level things. And I did not mean the announcement must be played to all over the conversation. I also did not mean only a long announcement can be played parallel with the conversation. 4.2.3:Not only different media type. You know from audio conversation to video conversation , it’s a case of different media type. But Here, the audio conversation media is between UEs, but the added video announcement media is from the AS/MRF to the UE. Anyhow, I will think how to change this part to avoid using “at the same time” 4.7.2.9.1:announcement during an established connection” means announcement is played during announcement during an established connection. It does not say we cannot prepare to play before the connection is established. As my proposal , announcement is also played during an established connection and is not played before the connection is established. “AS can add a media stream with a type different than any existing media types” is not enough. If current CR text is right, I think there is no need to change to another saying. It’s better to check which place is not right or reasonable. A.2: Thanks for point out the error in the second call flow and the explanation on re-INVITE and UPDATE. But I cannot understand why do you object any call flow? What’s rule of adding call flows? If I did not give call flow here, I guess maybe you think the text is not clear. Although the call flow is not necessary, I think the call flow is helpful for understanding the normative text accurately. At least, I think the first call flow is needed.
C1-201057	Condition of providing video announcement	China Telecom,Huawei, China Unicom, HiSilicon	CR 0074 24.628 Rel-16	Current status question Jörgen, Yoshihiro and Upendra to confirm Revision of C1-200995 Revision of C1-200546 Jörgen (Monday 16:39): I don't think we should state negative requirements like this. So better to say something that "the AS shall only provide video announcement (or some better term) if... As the first sentence in 4.7.2.9 state that procedures apply to both originating and terminating UE only one paragraph is needed. Then I think you can use the term "served UE". I assume the conditions are that SDP is not in the negotiated SDP and there is a video media feature tag present. Unrelated to the subject of your CR, it would be good if you add a heading 4.7.2.9.0 General. You don't need to, but the current text is a hanging paragraph. Michelle Li (Tuesday 16:52) Only one paragraph is complex. Positive requirement will be used. Heading for General will be added. Upendra (Wednesday 13:13): The changes submit in this CR – C1-200546 contradicts with C1-200486, section A.2.x where video announcements are added for only audio in SDP on both originating and terminating UEs. AS only needs to check video feature-tag from MO/MT UEs, no need to check video content in SDP offer/answer. Michelle Li (Wednesday 15:06): Some old UE maybe have no video feature-tag but still have video capability, which we should take them into account.
Other Rel-16 IMS & MC issues	Joergen – Breakout	Other Rel-16 IMS topics
C1-200365	SDP profile update to support FLUS	Ericsson / Nevenka	CR 6409 24.229 Rel-16	Current status agreed
C1-200772	Correction in IMS_Registration_handling policy about how UE should deregister	MediaTek Inc.	CR 6404 24.229 Rel-16	Postponed Document was late
C1-200779	Correct reference	BlackBerry UK Ltd.	CR 6410 24.229 Rel-16	Current status agreed Revision of C1-200425 Work item has changed to TEI16 _________________________________________ Ivo, Thursday, 17:10 the CR fixes errors created in Rel-15. The CR does not seem be related to 5WWC. The CR should have been submitted for 5GS_Ph1-CT or 5GProtoc16, which are out of scope of the e-meeting, or for IMS TEI16. John-Luc, Friday, 16:08 Agrees that this is not 5WWC, would go for IMS TEI16
C1-200940	Discussion on SRVCC from E-UTRAN to GERAN/UTRAN when IMS voice call is initiated in 5GS	Ericsson / Ivo	discussion Rel-16	Noted Revision of C1-200940 See comments on 674
C1-200941	SRVCC from E-UTRAN to GERAN/UTRAN when IMS voice call is initiated in 5GS	Ericsson / Ivo	CR 1298 24.237 Rel-16	Current status question John-Luc, Christian, Robert to confirm Revision of C1-200674 Christian (Monday 16:04): There are discussions ongoing during the SA2 e-meeting on this topic of how to handle SRVCC from 5GS to EPS, and we would like to propose to postpone the CT1 discussion till the architectural discussion is settled in SA2. However, we are fine to discuss during this e-meeting the details of the CT1 proposal as proposed by Ericsson to collect comments. Ivo (Monday 16:24): I am unaware of any discussions ongoing during the SA2 e-meeting on this topic of how to handle SRVCC from 5GS to EPS. can you please point me to any SA2 TDocs? Thank you. Christian (Monday 16:33): Please, check at least S2-2001973, S2-2001974 from us. The SA2 CRs from us do not focus on the IMS part but the general signalling part but anyhow there is need to analyze the impacts of each other if agreed, and anyhow it is recommended from my side that we wait for stage 2 (SA2) first so we, CT1, are on the safe side. Ivo (Monday 17:12): S2-2001973 and S2-2001974 seem to describe how the MME communicates with eNode during inter-system change from N1 mode to S1 mode. C1-200673 and C1-200674 describe how the ATCF is informed by SCC AS about possible PS to CS SRVCC, when the UE is in 5GS. Can you please clarify linkage of those discussions? Christian (Monday 17:33): You have the answer to your questions in my emails Robert (Monday 14:43): 1) We are not in favour of leaving it up to “network implementation” to find out whether a UE is supporting SRVCC or not. In our view, both networks and UEs would benefit from clear criteria. - Just imagine that we find out that for our UEs in certain networks SRVCC does not work in the scenario under discussion, but in other networks it is working perfectly well. Should we then argue with the network vendor that he has chosen the wrong network-specific implementation? So we would prefer to have a list of clear criteria. (I also don’t think that the scenario under discussion should be considered a ‘rare corner case’. This may be the case for some networks; but in others it could be a quite common case: if an EPS network is using SRVCC today, it will probably continue doing so after NR has been deployed. If then the network or the UE does not support VoNR, there will be many cases of EPS fallback - where the UE initiates the signalling for the IMS call via NR before it is handed over to EPS. And for any such call, if there is a subsequent SRVCC handover to 2G/3G, we will run into the issue.) 2) I have a question regarding the proposed NOTE 2 in subclause 6.3.2: > NOTE 2: A UE supporting the PS to CS SRVCC is an SC UE. Presence of the g.3gpp.accesstype media feature tag in a Contact header field of the SIP REGISTER request that created the binding indicates that the UE is an SC UE. Apparently, here the intention is to give such a criterion in the form of note, but are you sure that the 2nd sentence is correct? In my view it should rather read: > A UE that is an SC UE includes the g.3gpp.accesstype media feature tag in a Contact header field of the SIP REGISTER request. which is basically a repetition of the requirement in 6.2.2, General: > The SC UE shall include the g.3gpp.accesstype media feature tag as described in clause B.3 of 3GPP TS 24.292 [4] in the Contact header field of the SIP REGISTER request. The g.3gpp.accesstype media feature tag is defined in TS 24.292, annex B.3, and according to 24.292, subclause 6.2, it primarily indicates that “ICS is enabled for the UE”. (Especially, if in a SIP REGISTER request it is combined with a g.3gpp.ics media feature tag set to “principal” as shown in the signalling flows in 24.237, annex A.3.) 3) It is our understanding that you want to collect comments, but that a final decision between the proposal in C1-200674 and the proposal in C1ah-200012 (or some third proposal) will be taken at a meeting where both proposals can be tabled and discussed at the same meeting. John-Luc (Monday 21:23): BlackBerry requests that C1-200674 is postponed. As pointed out, a competing (and complete) solution exists which could not be submitted to this meeting. A detailed comment: It is unclear what the purpose is of the new NOTE 2. According to 5.2 in 24.237, an SC UE can, dependent on the desired functionality, implement only one of the following 24.237 procedures: procedures in subclauses 6A.2, subclause 7.2, subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2, subclause 12.2, subclause 13.2 or subclause 20.1. This means: An SC UE could be a UE that supports receiving some operator policy via OMA Device Management (3GPP TS 24.216) only, i.e. no SRVCC. An SC UE could be a UE that supports PS-PS access transfer only. An SC UE could even be using ICS. Neither has to support SRVCC! Thus, instead of “the SCC AS determines using implementation specific means that the PS to CS SRVCC is possible” the SCC AS has no way of determining whether PS to CS SRVCC is possible for any UE. As a consequence the operator has to either assume all UEs support PS to CS SRVCC or none of them do. I.e. the operator supporting SRVCC needs to increase capacity in order to anchor all sessions in the SCC AS/ATCF/ATGW. For any operator that depends on the UE PS to CS SRVCC capability, this is an incompatible change. While the HSS will provide a correct “UE PS to CS SRVCC capability” value for UEs that have attached via EPS, when the same UE initially registers via 5GS, the “UE PS to CS SRVCC capability” value provided by the HSS will be incorrect. When the same UE subsequently transfers from 5GS to EPS, the SCC AS isn’t triggered to check with the HSS whether the “UE PS to CS SRVCC capability” value has changed at the HSS (due to the UE having performed TAU with the EPS). Hence, SRVCC will continue to fail for these operators and UEs. The proposal essentially makes things “implementation-specific” and adds an obscure NOTE. And it doesn’t work. Ivo (Monday 21:46): A UE supporting SRVCC needs to both register and establish an IMS voice call. I.e. the UE needs to perform 24.237 6.2 and 7.2 and 8.2, in addition to 12.2. 24.237 6.2 states: ----------------- The SC UE shall include the g.3gpp.accesstype media feature tag as described in clause B.3 of 3GPP TS 24.292 [4] in the Contact header field of the SIP REGISTER request. ----------------- This is also reconfirmed in GSMA IR.92 which states: ----------------- If the UE is a Session Continuity UE (SC-UE) (e.g. due to support of SR-VCC as described in Annex A.3), then the UE must include the g.3gpp.accesstype media feature tag as specified in section 6.2.2 of Release 11 of 3GPP TS 24.237 [16]. ----------------- I.e. SRVCC UE includes the g.3gpp.accesstype media feature tag in REGISTER request. In C1-200674, when the g.3gpp.accesstype media feature tag is included in REGISTER request, SCC AS can provides SRVCC information to ATCF. In this solution, ATGW will get SRVCC information for every SRVCC UE and this ensures that SRVCC handover will be performed correctly. This solution works with Rel-15 5GS network (both in VPLMN and HPLMN), with Rel-15 UEs, and with Rel-15 ATGW. There might be other possible solution ensuring the above and that's why the CR states "implementation specific means that the PS to CS SRVCC is possible", with the above given as one possible solution. Regarding whether other UEs can provide the g.3gpp.accesstype media feature tag in REGISTER request too. In theory, this is possible and the DISC paper stated so. In reality, we are not aware of deployments of such UEs. If such UE is anyway deployed, the services will continue being used as normally, the only effect is anchoring of the call in ATGW. Anchoring of unnecessary call in ATGW is a small cost in comparison to your solution which precludes SRVCC handover from E-UTRA to GERAN/UTRAN of a IMS voice call which was originally established by Rel-15 UE in Rel-15 5GS network and then moved to EPS using inter-system change from N1 mode to S1. Robert (Tuesday 10:22): 1) > In C1-200674, when the g.3gpp.accesstype media feature tag is included in REGISTER request, SCC AS can provides SRVCC information to ATCF. If that is the intention, can we please have this stated in a more normative way, as a requirement? 2) > Regarding whether other UEs can provide the g.3gpp.accesstype media feature tag in REGISTER request too. In theory, this is possible and the DISC paper stated so. In reality, we are not aware of deployments of such UEs. The DISC paper contains the same - wrong - claim that 'every UE sending a g.3gpp.accesstype media feature tag is an SC UE': <snip> The implementation specific means can consist of e.g. the SCC AS using UE's SRVCC capability received previously and stored in the SCC AS or the SCC AS analyzing IMS signalling sent by the UE. In the latter, the SCC AS can decide that SRVCC is possible e.g. if the g.3gpp.accesstype media feature tag is included in the Contact header field of the REGISTER request, as g.3gpp.accesstype media feature tag indicates that the UE is an SC UE and a UE supporting PS to CS SRVCC is an SC UE. NOTE: All SC UEs are a super set of all UEs supporting PS to CS SRVCC. I.e. a UE supporting PS to CS SRVCC is an SC UE but not all SC UEs support PS to CS SRVCC. E.g. an SC UE that does not support PS to CS SRVCC and supports PS to CS DRVCC or inter-UE-transfer can exist. If the SCC AS provides the SRVCC information to the ATCF for such a UE, IMS voice calls of such UE would be anchored in an ATGW unnecessarily. <snap> So can we please have the Note in the CR corrected? - Even if - for the time being - there is no implementation of an ISC UE which is not also an SC UE, in my view your statement is confusing the reader.
Release 17 work items	Tdoc	NOT PART OF THIS MEETING
Output Liaison Statements	Tdoc	Title	Prepared by	To/CC	Result & comment
C1-200309	Reply LS on General Status of Work	Ericsson / Ivo	LS out Rel-16
C1-200310	Reply LS on sending CAG ID	Ericsson / Ivo	LS out Rel-16
C1-200395	Reply LS on SUCI computation from an NSI	Ericsson / Ivo	LS out Rel-16
C1-200434	LS on secure that a UE does not wait indefinitely for completion of NSSAA procedure	ZTE	LS out Rel-16
C1-200499	Reply LS on Rel-16 NB-IoT enhancements	Huawei, HiSilicon/Lin	LS out Rel-16	C1-200416 and C1-200499 compete
C1-200545	Reply LS on PC5S and PC5 RRC unicast message protection	OPPO / Rae	LS out Rel-16
C1-200590	LS on suspend indication to the NAS	Samsung/Mahmoud	LS out Rel-16
C1-200699	LS on manual CAG selection	Nokia, Nokia Shanghai Bell	LS out Rel-16
C1-200707	Reply LS on Mobile-terminated Early Data Transmission	Ericsson / Mikael	LS out Rel-16
C1-200710	Reply LS on RRC establishment cause value in EPS voice fallback from NR to E-UTRAN	Nokia, Nokia Shanghai Bell	LS out Rel-16
C1-200717	Reply LS on extended NAS timers for CE in 5GS	Ericsson / Mikael	LS out Rel-16
C1-200718	Reply LS on configured NSSAI handling	Nokia, Nokia Shanghai Bell	LS out Rel-16
C1-200721	Reply LS on Non-UE N2 Message Services Operations	Ericsson / Mikael	LS out Rel-16
C1-200764	reply LS for concurrent broadcast for CMAS	Samsung /Grace	LS out Rel-16	Proposed Postponed The related incoming LS in C1-200226 is Rel-15 and hence not in scope of this meeting. Consequently any Reply LS is not in scope of the meeting either (although header of this LS lists Rel-16)
C1-200323	Response to LS on Non-UE N2 Message Services Operations	Cisco Systems Belgium	LS out Rel-16	Withdrawn Moved from 16.2.21
C1-200416	LS on UE specific DRX for NB-S1 mode	Qualcomm Incorporated / Amer	LS out Rel-16	Moved from 16.2.8 C1-200416 and C1-200499 compete
C1-200445	[Draft] LS on Unicode symbol numbers representing disasters	SyncTechno Inc.	LS out Rel-16	Moved from 16.2.1
C1-200453	LS on limited service state for CAG cell	Huawei, HiSilicon / Vishnu	LS out Rel-16	Moved from 16.2.7.1
C1-200671	Response to LS on Sending CAG ID	Samsung/Kundan	LS out Rel-16	Moved from 16.7.1 LATE
Late and misplaced documents	Tdoc	Title Prioritization of documents within this category will be done during the meeting. Some tdocs are left in the main agenda item, although they are late (e.g. papers reporting IETF progress, which are usually more up to date the later they are submitted)	Source	Tdoc info	Result & comments Late documents and documents which were submitted with erroneous or incomplete information
A.O.B.	Tdoc	Title	Source	Tdoc info	Result & comments
Closing Friday by 16:00 at the latest	Did you mark your attendance to this meeting?	Any meeting document which is not mentioned in this report or with no recorded decision shall be interpreted as "reserved", i.e. not defined and shall be ignored if received
Last upload of revisions: Thursday 27th February 2020 16:00 CET Last comments: Friday 28th February 2020 16:00 CET Chairman Report of the meeting: Monday 2nd March 2020