3GPP TSG CT WG1 Meeting#123-e	C1-202005

Electronic meeting, 16-24 April 2020

Meeting documents by agenda item Meeting: Meeting #123-e Electronic meeting 16 - 24 April 2020 All indicated times are CEST
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 acti ities 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-202048	3GPP TSG CT1#123-e – agenda for Tdoc allocation	CT1 chairman	agenda	Noted Revision of C1-202000
C1-202001	3GPP TSG CT1#123-e – agenda after Tdoc allocation deadline	CT1 chairman	agenda	Noted
C1-202002	3GPP TSG CT1#123-e – agenda with proposed LS-actions	CT1 chairman	agenda	Noted
C1-202003	3GPP TSG CT1#123-e – agenda at start of meeting	CT1 chairman	agenda	Noted
C1-202004	3GPP TSG CT1#123-e – agenda Thursday (23rd April) evening	CT1 chairman	agenda	Noted
C1-202005	3GPP TSG CT1#123-e – agenda at end of meeting	CT1 chairman	agenda
C1-202006	draft C1-122e report	MCC	report	Noted
Hightest number 2598
Agenda Start of e-meeting: Thursday 16th April 09:00 CEST Comment Free Time Thursday 23rd April 12:00-16:00 CEST Last revision upload: Thursday 23th April 16:00 CEST Last comments: Friday 24th April 16:00 CEST Chairman’s report of the meeting: Monday 27th April 12:00 CEST 1 Opening 2 Agenda and Reports 3 work organization 4 incoming LS Rel-15: 15.1.1 all work items () 15.1.2 all work items (2) 15.1.3 all work items (11+3) Rel-16: Agenda Items from 16.2 16.2.2 SINE_5G (1) 16.2.3 SAES16 (all aspects) (5) 16.2.4 5GProtoc16 (all aspects) (104) 16.2.5 ATSSS (19) 16.2.6 eNS (44) 16.2.7.x vertical-LAN (74) 16.2.8 5G_CIoT (41) 16.2.9 5WWC (12) 16.2.11 5G_eLCS (2) 16.2.14 RACS (1) 16.2.15 5G_SRVCC (3) 16.2.16 xBDT (0) 16.2.17 IAB-CT (0) 16.2.18 5GS_OTAF (0) 16.2.19 5G_URLLC (0) 16.2.21 Rel-16 non-IMS issues (27) 16.2.1 ePWS (1) 16.2.10 PARLOS (3) 16.2.12 V2XAPP (18) 16.2.13 eV2XARC (50) 16.2.20 SEAL (44) Agenda Items from 16.3 16.3.1 MCCI_CT (1) 16.3.2 MCProtoc16 (14) 16.3.5 MCSMI_CT (0) 16.3.6 eMCDATA2 (16) 16.3.10 MONASTERY2 (8) 16.3.12 enh2MCPTT-CT (0) 16.3.3 MuD (2) 16.3.4 IMSProtoc16 (1) 16.3.7 E2E_DELAY (0) 16.3.8 VBCLTE (0) 16.3.11 eIMS5G_SBA (2) 16.3.13 eIMSVideo (3) 16.3.14 IMS/MC TEI16 (8) 18 outgoing LS
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	Electronic Meeting
20 – 24 April	CT1#123	Cancelled
16 – 24 April	CT1#123-e	Electronic Meeting
25 – 29 May	CT1#124	F2fF cancelled
02 – 10 June	CT1#124-e	Electronic Meeting
29 June – 1 July. 2020	CT plenary #88-e	Electronic Meeting
13 – 17 July	CT1-Potential Ad-Hoc	cancelled
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 #92	Japan
Work Plan and other adm. issues	Tdoc	Title	Source	Spec / doctype	Result & comments
C1-202007	CT1#123-e Electronic Meeting – Process and Scope	CT1 chairman	other	Noted
C1-202051	work plan	MCC	Work Plan	Noted
C1-202055	Decision making during CT1#123e – electronic show of hands	CT1 chairman	other	Noted
Input Liaison statements	Tdoc	Title	Source	To / CC	Result & comments
C1-202033	Specification of NAS COUNT for 5G (FSAG Doc 78_002)	GSMA FSAG	To	Noted Related CR in C1-202089
C1-202034	Mandatory User Plane Integrity for 5G (FSAG Doc 79_002)	GSMA FSAG	To	Noted Wait for SA to conclude
C1-202035	LS Reply on QoS mapping procedure for FLUS (C3-201460)	CT3	Cc	Noted
C1-202036	LS on Proposal to transfer the study on service-based support for SMS in 5GC to CT WGs (CP-193301)	TSG CT	Cc	Postponed Rel-17
C1-202037	LS on MO exception data (C4-201003)	CT4	Cc	Noted
C1-202038	SMS and UDM (C4-201045)	CT4	To	Noted Wait on next steps from SA2 on 23.501
C1-202039	LS on the Usage of Version ID (C4-2011218)	CT4	Cc	Noted
C1-202040	Reply LS on Further clarifications on GLI/GCI and Line ID/ HFC_Identifier (C4-201220)	CT4	Cc	Noted
C1-202041	LS on subscribe/notify for 5G Steering of Roaming (C4-201221)	CT4	To	Proposed tbd Reply LS in C1-202067 and C1-202151 Related CRs in C1-202068, C1-202069, C1-202152
C1-202042	Clarification on encryption requirements for AGF interfaces (N1, N2, N3) [WWC] (LIAISE-382)	Broadband Forum	To	Noted No action required from CT1
C1-202043	LS on RRC establishment cause value in EPS voice fallback from NR to E-UTRAN (R2-1916530)	RAN2	To	Noted Related CR C1-202269
C1-202044	Reply LS on Rel-16 NB-IoT enhancements (R2-2001815)	RAN2	To	Noted CT1 questions on values for UE specific DRX cycle in NB-IoT in C1-201024 are not answered, no consensus in RAN2 Related with incoming LS in C1-202049 Related CRs in C1-202084 and C1-202384
C1-202045	LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs (R2-2002417)	RAN2	To	Proposed Noted Reply LS in C1-202012, C1-202103, C1-202180, C1-202240, C1-202359 Disc paper C1-202102, C1-202239, C1-202493, C1-202499, Related CR C1-202397, C1-202015
C1-202047	Reply LS on assistance indication for WUS (R3-201397)	RAN3	Cc	Noted Related with incoming LS in C1-202058
C1-202049	Reply LS on Rel-16 NB-IoT enhancements (R3-201417)	RAN3	To	Noted Related with incoming LS in C1-202044 Related CRs in C1-202084 and C1-202384
C1-202050	LS on Questions on onboarding requirements (S1-201087)	SA1	Cc	Postponed Rel-17
C1-202052	LS on PLMN selection solutions for satellite access (S2-1912551)	SA2	To	Postponed Rel-17
C1-202053	Reply LS on clarification on the requirement for steering of roaming (S2-1912764)	SA2	To	Noted CR in CP-200094 already approved in last plenary
C1-202054	Reply LS on Dual-registration requirements for EHPLMNs (S2-2001130)	SA2	To	Proposed tbd related CR in C1-202136 Is a reply LS available?
C1-202056	LS on GSMA NG.116 Attribute Area of service and impact on PLMN selection (S2-2001726)	SA2	To	Postponed Rel-17 Related with incoming LS in C1-202065
C1-202057	Questions on onboarding requirements (S2-2001729)	SA2	Cc	Postponed Rel-17
C1-202058	Reply LS on assistance indication for WUS (S2-2001732)	SA2	To	Noted Related with incoming LS in C1-202047 CRs in C1-202466 and C1-202467
C1-202059	Reply LS on IANA assigned values for mission critical (S3-194603)	SA3	To	Postponed Reply LS needed, seems not available
C1-202060	Reply LS to LS on native 5G NAS security context activation (S3-200529)	SA3	To	Noted CR in C1-202594
C1-202061	Reply on QoE Measurement Collection (S4-200241)	SA4	To	Postponed Are CRs available? Reply LS needed, seems not availalble
C1-202062	LS on RTP/RTCP Verification (S4-200340)	SA4	To	Postponed Reply LS needed, seems not available
C1-202063	Reply LS to Transfer the study on service-based support for SMS in 5GC to CT WGs (SP-191362)	TSG SA	To	Postponed Rel-17
C1-202064	Reply LS on support for eCall over NR (SP-200287)	TSG SA	To	Noted CRs available in C1-202081 and C1-202358
C1-202065	LS reply to SA2 on PLMN Selection (5GJA12_115r3)	GSMA 5G Joint-Activity (5GJA)	To	Postponed Rel-17 Related with Incoming LS in C1-202056 No action from CT1 required
C1-202591	Reply LS on QoS mapping procedure (S4-200690)	SA4	Noted Wait for CT3 to clarify "a=3gpp-qos-hint" usage Do we have CRs or DISC paper to the meeting?
C1-202597	LS on Concurrent Broadcasting for CMAS (R3-197749)	RAN3	To	Noted Reply LS in C1-202232 and C1-202564 Disc paper in C1-202231 and C1-202565 Revision of C1-202046 _________________________________________ 2046 had incomplete tdoc number on the cover sheet
C1-202602	LS on status of 5WWC work (LIAISE-390)	Broadband Forum	Postponed
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	Title	Source	Tdoc info	Result & comments
Rel-15 Mission Critical work items and issues: eMCVideo-CT eMCDATA-CT enhMCPTT-CT MCProtoc15 MONASTERY MBMS_MCservices	Jörgen	All work items complete Enhancements to Mission Critical Video – CT aspects Enhancements for Mission Critical Data – CT aspects Enhancements for Mission Critical Push-to-Talk – CT aspects Protocol enhancements for Mission Critical Services sion Critical Push-to-Talk – CT aspects Mobile Communication System for Railways MBMS usage for mission critical communication services
Rel-15 IMS work items and issues 5GS_Ph1-IMSo5G eCNAM-CT FS_PC_VBC (CT3) IMSProtoc9 bSRVCC_MT eSPECTRE PC_VBC (CT3) TEI15 (IMS)	Jörgen	All work items complete IMS impact due to 5GS IP-CAN CT aspects of Enhanced Calling Name Service Study on Policy and Charging for Volume Based Charging IMS Stage-3 IETF Protocol Alignment for Rel-15 SRVCC for terminating call in pre-alerting phase Enhancements to Call spoofing functionality Policy and Charging for Volume Based Charging
C1-202584	Reference update for PASSporT Extension for Diverted Calls	Orange / Mariusz	CR 6416 24.229 Rel-15
C1-202585	Reference update for PASSporT Extension for Diverted Calls	Orange / Mariusz	CR 6417 24.229 Rel-16
Rel-15 non-IMS/non-MC work items and issues 5GS_Ph1-CT EDCE5-CT ProSe_WLAN_DD_Stage3 VoWLAN-CT PS_DATA_OFF2-CT LTE_LIGHT_CON-CT AT_CIoT-Ext SAES6 INOBEAR-CT TEI15	Peter	All work items complete CT aspects on 5G System - Phase 1 EPC enhancements to support 5G New Radio via Dual Connectivity Inclusion of WLAN direct discovery technologies as an alternative for ProSe direct discovery Complementary Features for Voice services over WLAN PS Data Off Phase 2 CT aspects of signalling reduction to enable light connection for LTE AT Commands for CIoT-Ext Stage-3 SAE Protocol Development for Rel-15 Increasing the number of EPS bearers Other Rel-15 non-IMS topics
C1-202032	Remove the duplicated cause value for announce request procedure not accepted by the ProSe Function	CATT	CR 0328 24.334 Rel-15	Current Status: Postponed Frederic, Thu, 11:06 Coversheet, category wrong, source to TSG wrong Lena, Thu, 16:41 Either start the change from Rel-13 or Rel-16 only Sung, THU, 16:13 No FASMO Bao, Thu, 19:07 Answering Frederic Answering Sung Answering Lena Sung, Thu, 19:23 Explaining this is not FASMO Bao, Thu, 19:37 Is open for other delegates opnions Lena, Thu, 22:35 Prefers TEI16, i.e. only Rel-16 Christian, Fri, 15:02 CAT D, to go to Rel-16
C1-202096	Correct EPS SRVCC support indication when registering with 5GS	BlackBerry Uk Ltd.	CR 1642 24.501 Rel-15	Withdrawn Following ConfCall Revision of C1-198013 Alternative to C1-202133 (is Rel-16 only) Ivo, Thu, 11:52 need to impact UEs and 5GS core network entities with EPS SRVCC aspects CR requires a UE not support a feature to perform an action related to the feature - not a good approach. no need of the CR, there is another alternative Lena, Thu, 16:41 This is not FASMO For Rel-16 prefers C1-202133 Ivo, Tue, 00:55 No need to impact ue and 5gs CN, no need for the CR Oppo, Tue, 04:09 Not needed
C1-202097	Correct EPS SRVCC support indication when registering with 5GS	BlackBerry Uk Ltd.	CR 1643 24.501 Rel-16	Withdrawn Following ConfCall Revision of C1-198014 Alternative to C1-202133 (is Rel-16 only) Ivo, Thu, 11:53 Same comments as for 2096 Lena, Thu, 16:41 prefer Ericsson’s competing proposal without UE impact in C1-202133. John-Luc, Mon, 18:49 SA2 will follow stage-3
C1-202227	Adding Unstructured type(non-IP) to encoding of UE policy part type URSP(R15)	China Telecom Corporation Ltd.	CR 0074 24.526 Rel-15	Current Status Postponed Ivo, Thu, 11:58 No FASMO not clear why the traffic descriptor component value field needs to contain two values Lena, Thu, 16:41 Not needed. Roozbeh, Fri, 22:45 CR is incorrect
C1-202231	CWMI use in PWS	Ericsson / Mikael	discussion Rel-15	Noted Lazaros, Thu, 15:01 Ok with the DISC in principle, needs clarification on one case Mikael, Mon, 11:14 Acks Lazaros, a Note can be needed, which release to start with
C1-202360	Remove SUPI in the form of NSI from stage 2(in R15)	China Telecom / Michelle	CR 2127 24.501 Rel-15	Current Status Postponed Ivo, Thu, 11:53 Not essential, not aligned with stage-2 Lena, Thu, 16:41 Not aligned with stage-2 Can not agree with the CR Sung, Thu, 16:49 Not FASMO, objects Christian, Fri, 16:12 Comments, no need to update NAS spec Michelle, Tue, 17:08 Q for clarification
C1-202361	Remove SUPI in the form of NSI from stage 2(in R15)	China Telecommunications	CR 0127 24.502 Rel-15	Ivo, Thu, 11:53 not aligned with 23.501 Rel-15 which enables NSI as a SUPI type Lena, Thu, 16:41 Not aligned with stage-2 Can not agree with the CR Sung, Thu, 16:51 NSI is valid option in Rel-16, object the CR Christian, Fri, 16:12 Comments, no need to update NAS spec
C1-202507	Registration at PLMN change at PLMN-SEARCH substate	MediaTek Inc.	CR 2189 24.501 Rel-15	Postponed Kaj, Thu, 14:32 Questionable that this is essential, would need rewording Sung, Thu, 17:03 This is not FASMO Osamah, Thu, 19:06 do not think this is FASMO to be included in Rel15 spec Christian, Fri, 15:41 is not of FASMO nature. Hence, we cannot agree to roll back to Rel-15 Marko, Mon, 12:04 Explaining, main reason is RAN5
C1-202561	handling of ePWS message	Samsung/ Kyungjoo Grace Suh	CR 0216 23.041 Rel-15	Not pursued Based on email form Grace Frederic, Thu, 11:37 ePWS is a Rel-16 work item, use “Rel-15” instead of “Rel 15”, 2563 seems a mirror so has to be in same agenda item Lena, Thu, 16:41 Rel-15 CR under Rel-16 work item, title is about ePWS, but CR is about concurrent warning message, text adds no value Grace, Fri, 14:00 Still needs to decide whether to go to rel-15 or rel-16 Grace, Fri, 14:17 Will make a revision so that this is only Rel-16 change
C1-202565	Discussion for concurrent broadcast for CMAS	Samsung/ Kyungjoo Grace Suh	discussion 23.041 Rel-15	Noted
C1-202831	Correct N3AN node selection due to LI	BlackBerry Uk Ltd.	CR 0119 24.502 Rel-15	Revision of C1-202672 Amer, Fri, 07:00 This is not a FASMO, not agree John-Luc, Fri, Not agreeing -------------------------------------------------------------- Revision of C1-202092 Amer, Wed, 06:46 Maintains his position, not correcting a FASMO Ivo, Wed, 12:10 Having comments John-Luc, Wed, 16:14 Explaining Ivo John-Luc, Wed, 20:28 Rev Ivo, Wed, 23:28 Suggest rewording Lazaros, 00:41 Open aspect John-Luc, THi, 00:47 Fine to remove problem that Lazaros mentioned _________________________________________ Frederic, Thu, 09:08 Clauses affected missing Ivo, Thu, 11:46 Seems not essential, some of the changes are not needed, some are incorrect Joy, Thu, 11:49 Not all changes are FASMO, changes to 7.2.4.4.2 and 7.2.4.4.2 are OK to be kept Amer, Thu, 19:33 This is not FASMO John-Luc, Thu, 20:21 This is FASMO, bypassing LI for all visiting UEs Roozbeh, Thu, 21:05 Requests a change Christian, Fri, 15:02 Acknowledges there is a problem, number of comments on how to address this Amer, Fri, 18:24 UE will follow the procedures in 24.302 to select ePDG. John-Luc, Fri, 22:22 Uploads a rev to the inbox Roozbeh, Fri, 22:24 Huge number of comments, not convinced it is FASMO John-Luc, Fri, 22:36 To Roozbeh, hinting at this rev Lazaros, Mon, 09:57 Two ways to solve this … John-Luc, Mon, 17:45 Answering, providing a rev Lazaros, Mon, 19:43 Withdraws one comment Ivo, Tue, 00:50 Hints at errors in v3 and asking for CT4 status John-Luc, Tue, 01:49 CT4 CR withdrand, discussin way forward
C1-202832	Correct N3AN node selection due to LI	BlackBerry Uk Ltd.	CR 0120 24.502 Rel-16	Revision of C1-202673 Amer, Fri, 07:24 Maintains his position, CR is not needed John-Luc, Friday Not agreeing _________________________________________ Revision of C1-202093 John-Luc, Wed, 20:28 rev _________________________________________ Ivo, Thu, 11:46 Some of the changes are not needed, some are incorrect Joy, Thu, 11:49 Some of the changes are not needed Amer, Thu, 19:38 changes proposed in the CR are not needed because….. John-Luc, Thu, 20:28 Explains why this is needed, … UE supporting ePDG and N3IWF will not use relevant procedures in 24.302 Amer, Fri, 18:23 Not agreeing with John-Luc, Fri, 19:32 Commenting to Amer Lazaros, Fri, 19:49 Cr is NBC, many other comments John-Luc, Fri, 20:19 Commenting to Lazaros Roozbeh, Fri, 22:24 Huge number of comments, John-Luc, Mon, 17:45 Answering, providing a rev
C1-202786	Remove USE_TRANSPORT_MODE in response	ZTE / Joy	CR 0124 24.502 Rel-15	Revision of C1-202291 _________________________________________ Christian, Fri, 15:22 Agrees this is an issue, cover sheet needs to be updated, wants to co-signe Joy, Tue, 17:43 Asks Christian one aspect Joy, Wed, 17:16 On backward comp approacheds
C1-202787	Remove USE_TRANSPORT_MODE in response	ZTE / Joy	CR 0125 24.502 Rel-16	Revision of C1-202292 _________________________________________ Christian, Fri, 15:22 Agrees this is an issue, cover sheet needs to be updated, wants to co-signe Joy, Tue, 17:43 Asks Christian one aspect
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-202166	Revised WID on CT aspects of eV2XARC	Huawei, HiSilicon /Christian	WID revised Rel-16	Revision of CP-200291 Rae, Wed, 11:10 Oppo to be added Adding new co-signers in the next meeting
C1-202570	Updated WID MONASTERY2	Nokia, Nokia Shanghai Bell	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-202424	5G_CIoT WI workplan	Qualcomm Incorporated / Amer	Work Plan Rel-16	Noted
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
C1-202814	handling of ePWS message	Samsung/ Kyungjoo Grace Suh	CR 0217 23.041 Rel-16	Revision of C1-202563 To be shifted to TEI16 Lena, Thu, 07:16 OK Lazaros, thu, 08:35 Ok Discussion ongoing, ban proposal on the cr fine for mikael and peterS Grace accepting the proposal Lazaros FIne _________________________________________ Revision is
SINE_5G	Peter – Main	Signalling Improvements for Network Efficiency in 5GS 100%
C1-202581	Handling of PDU session authentication	Samsung / Kyungjoo Grace Suh	CR 2210 24.501 Rel-16	Postponed Ivo, Thu, 11:58 Normative text in NOTE, NOTE does not reflect normative behaviour Frederic, Thu, 12:01 SHALL in a NOTE Sung, Thu, 18:46 Echoes Ivo, disagrees with the idea of the Note Amer, Thu, 19:43 Intent of CR seems ok, but revision is needed Grace, Fri, 14:38 Acks
SAES16 WIs	Peter – Main	Stage-3 SAE protocol pevelopment for Rel-16 100%
SAES16	Peter – Main	General Stage-3 SAE protocol development
C1-202519	Correction to Handling of #35	MediaTek Inc.	CR 3369 24.301 Rel-16
C1-202127	Consistent usage of "tracking area updating procedure"	Samsung Electronics Polska	CR 3341 24.301 Rel-16	Shifted from 16.2.21
C1-202690	Correction to Handling of #31	MediaTek Inc.	CR 3368 24.301 Rel-16	Revision of C1-202517 _________________________________________ Lin, Fri, 05:31 CR is ok but minor rewording needed
C1-202688	Correction of EMM initiated TAU procedure in EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM	MediaTek Inc.	CR 3366 24.301 Rel-16	Revision of C1-202515 _________________________________________ Ricky, Thu, 12:35 Ok with the intent, wants to see two bullets Lin, Fri, 05:17 Prefers Ricky’s wording with some changes
C1-202689	Correction to Handling of MO CSFB Emergency call in EMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM	MediaTek Inc.	CR 3367 24.301 Rel-16	Revision of C1-202516 Lin, fine _________________________________________ Lin, Fri, 05:26 Questions, seems already covered in the spec Behrouz, Sat, 00:48 WI Code should be “SAES16-CSFB”
C1-202824	Error handling of precedence value conflict	MediaTek Inc. / JJ	CR 3372 24.301 Rel-16	Revision of C1-202542 _________________________________________ Osama, Thu, 00:12 Requests changes to the CR Lin, Fri, 09:09 Agrees there is an issue, different proposal JJ, Fri, 15:50 Acks the comments, provides rev Osama, Fri, 22:34 Rev looks OK Lin, Tue, 09:28 fine
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
C1-202527	UE initiating service request over non-3GPP access after stopping T3346	SHARP	CR 2201 24.501 Rel-16	Merged into 2324 Based on request form author, Fri, 04:45 Joy, Thu, 11:53 Changes are covered by C1-202324, which is more complete Amer, Thu, 19:54 Needs clarification, isn’t 24.501 already covering this? Sung, Thu, 23:11 Should be merged with C1-202324 Yoko, Fri, 04:45 Fine to merge into revision of C1-202324
C1-202530	Discussion on S-NSSAI based congestion control	MediaTek Inc., Qualcomm Incoporated. / JJ	discussion Rel-16	Noted Fei, Thu, 12.15 UE solution only, prefers UE-QC1, no need to impact the network Ivo, Thu, 12:47 Preference for UE-QC1 Sung, Fri, 00:54 Prefers UE-QC1, keep current behavior Yudai, Fri, 07:03 prefer UE-QC1 and UE-CQ2 solutions Jj, Fri, 07:52 Explaining things to Yudai Lin, Sat, 07:11 Prefer MTK-1 Rae, Mon, 05:58 We prefer UE-MTK1 Yudai, Wed, 09:15 UE-QC1 solution or UE-CQ2 Yanchao, Wed, 12:44 prefer the UE-MTK1 Krisztian, THu prefer UE-MTK1
C1-202534	Discussion on support of QoS rules/QoS flow descriptions with the length of two octets	MediaTek Inc. / JJ	discussion Rel-16	Noted Fei, Thu, 12:17 In general, we would support the idea that the indicator is sent when the UE is in the S1 mode. can also be sent in the Modify bearer response or the activate dedicated bearer context response message Ivo, Thu, 12:48 Prefers alt-1 or alt-2, as alt-3 rquires additional message Rae Alt-2 is preferred since Alt-3 will cause additional signaling when UE moves to EPS. Osama, Fri, 17:46 Alt-2 Sung, Fri, 18:32 Not convinced with the argument against Alt-1 in the Disc JJ, Sat, 07:03 Answering Sung Yanchao, Sat, 12:46 Question for clarification Jj, Mon, 05:51 Explaining, MTK supports Alt-2 Vishnu, Tue, 08:46 Alt-2 STATUS Alt#1 (1): Ericsson Alt#2 (5): Ericsson, Oppo, Qualcomm, Huawei, MediaTek Alt#3 (1): ZTE
C1-202535	Indicate support of ePCO length of two octets parameter when establishing the PDU session – Alt#2	MediaTek Inc. / JJ	CR 2204 24.501 Rel-16
C1-202536	Indicate support of ePCO length of two octets parameter in the bearer resource modification procedure – Alt#3	MediaTek Inc. / JJ	CR 3371 24.301 Rel-16	Withdrawn Based on request from Author, wed, 07:34
C1-202541	Correction to the URSP coding	MediaTek Inc., ZTE / JJ	CR 0068 24.526 Rel-16	Postponed Based on request from author, Wed, 12:51 Revision of C1-198970 Ivo, Thu 12:49 Long list of comments Lena, Thu, 16:41 Some comments, some rewording Roozbeh, Fri, 04:28 Capitization JJ, Mon, 09:53 Providing rev Lazaros, Mon, 13:28 Fine, but some changes needed JJ, Mon, 13:37 Fine with Lazaros changes Ivo, mon, 13.30 revision is non-backward compatible
C1-202016	Manual CAG selection	Ericsson / Ivo	CR 0501 23.122 Rel-16	Withdrawn Not available on time Revision of C1-200732
C1-202017	Correction for SoR-AF	Ericsson / Ivo	CR 0481 23.122 Rel-16	Revision of C1ah-200189 Ivo, Mon, 2017 Discusson on the correct rev counter Mariusz, Mon, 15:07 Fine to keep it as is
C1-202068	SoR in HPLMN after registration	Orange, Ericsson / Mariusz	CR 0508 23.122 Rel-16	Releated CR in C1-202152
C1-202071	Reference correction in URSP encoding	Orange / Mariusz	CR 0071 24.526 Rel-16
C1-202074	Correction to figure	one2many B.V.	CR 0212 23.041 Rel-16
C1-202075	Corrections to references	one2many B.V.	CR 0213 23.041 Rel-16
C1-202089	Clarification of NAS COUNT handling in 5G	Vodafone GmbH	CR 2036 24.501 Rel-16	Current Status Agreed Fei, Thu, 12:22 Does not agree with the proposal, for this specific SN value, we would prefer not to specify whether to increment the overflow count by one or not. I am thinking that the AMF should trigger the primary authentication procedure. Yang, Thu, 13:22 Explains his handling of the overflow counter, and that AMF trigger the primary authentication is already in the spe Marko, Fri, 09:34 Asking for calrificaiton Fei, Tue, 13:26 fine
C1-202101	Clarification on DL only match-all packet filter	Qualcomm Incorporated / Lena	CR 2037 24.501 Rel-16	Current Status Agreed Vishnu, Fri, 16:10 We don’t think this CR is needed Lena, Tue, 01:44 Explaining that this has been seen in the field, clarification needed Vishnu Tue, 14:50 Still not convinced Lena, Tue, 16:25 Why not clarificying this? Vishnu, Wed, 11:45 Can live with it, withdraws bjectin
C1-202110	Adding Unstructured type(non-IP) to encoding of UE policy part type URSP	China Telecom Corporation Ltd.	CR 0072 24.526 Rel-16	Current Status Postponed Ivo, Thu, 12:02 not clear why the traffic descriptor component value field needs to contain two values Lena, Thu, 16:41 Not needed Roozbeh, Thu 22:46 Not needed Roozbeh, Sat, 05:49 Not needed, more arguments Shuzhen, Mon, 11:08 Asking for some clarification Roozbeh, Mon, 17:55 Nothing is needed Lena, Tue, 05:51 Not needed
C1-202128	Correction of the handling of timer TG	Apple, Qualcomm Incorporated, T-Mobile USA	CR 0513 23.122 Rel-16
C1-202129	Correction of the handling of 5GMM cause #27	Apple, Qualcomm Incorporated, T-Mobile USA	CR 2047 24.501 Rel-16
C1-202136	Dual-registration requirements for EHPLMNs	Intel, Qualcomm Incorporated / Vivek	CR 1974 24.501 Rel-16	Revision of C1-200620
C1-202146	Additional abnormal case handling for NOTIFICATION message	Samsung/Anikethan	CR 1791 24.501 Rel-16	Current Status Postponed Revision of C1ah-200199 Kaj, Thu, 14:55 No need for new IE, solution in 2044 is good enough Osamah, Thu, 18:16 Editrorial Yanchao, Fri, 05:52 Same as Kaj Vishnu, Fir, 16:42 rare case and to solve this we don’t need to do so much changes Sung, Fri, 17:58 Supports Vishnu Ani, Sat, 13:48 Defending his proposal Vishnu, Sun, 11:35 There is no problem to be solved Ani, Sun, 12:38 discussing
C1-202153	Correcting the case when the AMF does not need to provide SOR-info to the UE	DOCOMO Communications Lab.	CR 0516 23.122 Rel-16	Postponed Based on email form the author Ivo, Thu, 12:09 Explanation … Thus, we see no need of this CR. The baseline is correct. Marius, Fri, 10:56 Similar as ivo Ban, Sat, 10:59 Providing a rev Ivo, Mon, 12:53 CR does not work Ivo, Mon, 13:03 More agruments
C1-202158	Adding new IMSDoPS indication bits in “EPS network feature support” IE for network to indicate support for “IMS Data over PS” services	MediaTek Inc., Apple	CR 2054 24.501 Rel-16	Current Status Postponed Ivo, Thu, 12:10 Missing stage-2 requirement, without stage-2 this should be solved on IMS layer Lena, Thu, 17:52 Indicator on NAS level only needed for voice, not for data, CR is not needed Sung, Fri. 00:11 Same as Ivo and Lena, without stage-2 this can not be done Bill, Sat, 09:01 No need for this flag Lena, Thu, 02:20 Can not agree the CR
C1-202201	Clarification of the figure of registration procedure	vivo	CR 2072 24.501 Rel-16	Kaj, Thu, 14:59 An “e.g.“ is missing Yanchao, Mon, 05:27 Clarifying Kaj, Mon, 14:01 fine
C1-202219	UAC for MO-IMS registration related signalling EN resolution	NTT DOCOMO INC.	CR 6413 24.229 Rel-16	Revision of C1-200684
C1-202228	Possible KSI types in EPS	Ericsson / Mikael	CR 2076 24.501 Rel-16	Withdrawn
C1-202229	Possible KSI types in EPS	Ericsson / Mikael	CR 3346 24.301 Rel-16
C1-202254	No available S-NSSAIs at handover with emergency PDU session established	Ericsson /kaj	discussion Rel-16	Noted
C1-202272	Correct parameters included by AMF during inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode	Qualcomm Incorporated	CR 2095 24.501 Rel-16
C1-202275	Remove invalid cases in error handling for QoS rule operation and TFT operation	Qualcomm Incorporated	CR 2096 24.501 Rel-16
C1-202276	Clarify PAP/CHAP usage in PCO for 5GS	Qualcomm Incorporated	CR 3215 24.008 Rel-16	Postponed Based on request from author, tue, 18:03 Lin, Sat, 06:57 Interesting, but we should ask SA2/SA3 whether to use PAP/CHAP and postpone the CR Osama, Sat, 21:21 If LS, then some input on the content JJ, Mon, 11:01 Guidance from SA2/SA3 useful
C1-202277	Add handling for UE configured to use timer T3245 in 5GS via 3GPP access	Qualcomm Incorporated	CR 2097 24.501 Rel-16	Withdrawn
C1-202325	Initiate 3GPP access associated notification procedure over non-3GPP access	Huawei, HiSilicon / Cristina	CR 2105 24.501 Rel-16	Withdrawn Based on request from author, Tue, 04:23 Kaj, Thu, 15:30 CR is not needed Amer, Thu, 19:56 Agrees with Kaj Cristina, Fri, 05:17 Does not agree with Kaj and Amer Yanchao, Fri, 05:57 Same as Amer and Kaj Cristina, Fri, 06:11 Does not agree with yanchao Yanchao, Fri, 06:43 Explains to Cristina Ani, Mon, 08:32 CR is not needed Cristina, Mon, 11:08 Commenting Ani, Mon, 12:57 No change needed
C1-202331	Consider PDU session type IE set by UE in IP address allocation	Huawei, HiSilicon / Cristina	CR 2110 24.501 Rel-16
C1-202339	Add MFBR as mandatory parameter in GBR QoS flow	Huawei, HiSilicon / Cristina	CR 2116 24.501 Rel-16	Withdrawn
C1-202341	Add MFBR as mandatory parameter in GBR QoS flow	Huawei, HiSilicon / Cristina	CR 2117 24.501 Rel-16	Withdrawn
C1-202342	Fixing a reference in the service request procedure	BEIJING SAMSUNG TELECOM R&D	CR 2118 24.501 Rel-16	Osamah, Thu, 18:45 Needs to be CAT D Mahmoud, Thu, 19:18 Thinks it is CAT F, happy to chang to CAT D if others see this similar Roozbeh, Sat, 18:58 Tends to agree with Mahmoud, can go with the group Osama, Sat, 21:54 This is a typo Roozbeh, Sun, 20:46 CAT F
C1-202343	Add MFBR as mandatory parameter in GBR QoS flow	Huawei, HiSilicon / Cristina	CR 2119 24.501 Rel-16	Withdrawn
C1-202347	Correcting length of extended emergency number list IE	Huawei, HiSilicon / Cristina	CR 3352 24.301 Rel-16
C1-202358	Support for eCall over IMS over NR	Huawei, HiSilicon / Cristina	CR 0521 23.122 Rel-16	Postponed Request form author, Mon11:14 Ivo, Thu, 12:16 UE in eCall only mode is allowed to select a PLMN in NG-RAN when the PLMN does NOT advertise support for eCall over, why? Some further problem Lena, Thu, 22:50 CR is technically wrong (NG-RAN does not support CS) Sung, Fri, 02:02 CR is not including any specification change needed to support eCall in IMS over NR (with 5G Core), requested by TSG-SA
C1-202375	Initial NAS message protection on inter-system change from EPS to 5GS	Samsung/Kundan	CR 2136 24.501 Rel-16	Current Status Postponed Amer, Thu, 20:11 Why is this 24.501 and not 24.301? Fei, Fri, 04:24 Does not undertand the intention of the CR Kundan, Fri, 06:32 Explaining to Amer Sung, Sat, 18:03 CR is not needed Kundan, Mon, 08:32 Explaining to Fei/Sung Kundan, Mon, 08:47 Explaining to Fei Fei, Mon, 08.54 CR is not needed
C1-202376	Handling of MCS data in various 5GMM states	Samsung	CR 1415 24.501 Rel-16	Withdrawn Revision of C1-194530 Ivo, Thu, 12:16 Registration procedure for MCS not defined, PDU session for MCS is a regular PDU session from NAS perspective Lena, Thu, 16:40 Can not agree to the CR, no SA1 requirement, no definition of PDU session related to MCS Sung, Fri, 18:16 Echos Lena and Ivo
C1-202377	No messages without integrity protection processed after security activation	Nokia, Nokia Shanghai Bell	CR 2137 24.501 Rel-16	Not pursued Andrew, Thu, 12:08 Summery of changes should be improved Amer, Thu, 20:20 seems OK to us, but the note with the proposed changes could be improved Sung, Thu, 23:32 Ok with comments, provides new version Lin, Fri, 10:01 Not convinced anything is needed Sung, Sun, 01:28 Not agreeing with Lin Lin, Tue, 04:56 Ongoing Mikael, Tue, 17:01 Same as Lin, this is not needed
C1-202378	Clarification on the AMF behaviour after security activation in case of integrity check failure	Nokia, Nokia Shanghai Bell	CR 2138 24.501 Rel-16	Postponed Requested by author Fei, Fri, 04:34 CR is not needed Lin, Fri, 10:04 Does not see conflict that needs to be solved Sung, Sun, 01:36 Explaining Lin, Tue, 04:56 ongoing Mikael, Tue, 17:37 Similar as Lin, not needed
C1-202379	Discarding a SECURITY MODE COMMAND message which fails integrity check	Nokia, Nokia Shanghai Bell	CR 2139 24.501 Rel-16	Postponed Amer, Thu, 20:26 CR is not needed, creates a problem Lin, Fri, 10:14 CR is wrong and not needed. Sung, Sun, 01:50 Explaining Ani, Sun, 13:24 Asking Sung, how there will be a NAS counter desynchronization by sending an SMC reject Lin, Tue, 04:56 Ongoing disc with Sung Ani, Tue, 06:40 Same as lin and Amer Sung, Wed, 03:56 Explaining to AN Ani, Wed, 05:00 Commenting Fei, Wed, 05:22 The CR is NOT needed Lin, Wed, 07:20 On same page as Ani
C1-202380	Initiation of ESFB by a UE in the state 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE	Nokia, Nokia Shanghai Bell	CR 2140 24.501 Rel-16	Postponed Ivo, Thu, 12:18 not backward compatible since Rel-15 AMF will consider such registration procedure as initial registration, not convinced yet tha the CR is needed Lin, Fri, 10:10 Not inline with SA2, non backward compatible Sung, Sun, 02:39 Rev which is backward compatible, explaining Lena, Sun, 22:42 this should be discussed in SA2 first Rae, Mon, 05:46 SA2 first Fei, Mon, 09:56 Concerned Lin, Tue, 05:15 There is still an NBC issue, concerns Sung, Wed, 01:41 Rev Lin, Wed, 07:27 Questions Fei, Wed, 08:01 New IE not needed Sung, Wed, 14:48 New rev Lena, Thu, 05:17 Not convinced Fei, Thu, 05:43 Not needed Ivo, Thu, 08:53 Not agreeing Fei, Thu, 09:10 Not clear Lin, NOT CONVINCED
C1-202381	No emergency session transfer after ESFB	Nokia, Nokia Shanghai Bell	CR 2141 24.501 Rel-16
C1-202394	PDU session release for an inactive UE with RAN paging failure	Nokia, Nokia Shanghai Bell	CR 1833 24.501 Rel-16	Current Status Postponed Revision of C1ah-200089 Ivo, Thu, 12:18 SMF does not receive PDU SESSION RESOURCE RELEASE RESPONSE , goes only to AMF Roozbeh, Fri, 02:59 Cover page to be updated Lind, Fri, 09:51 we do not see anything need to be done in CT1 for this. Sung, Fri, 19:43 Provides a rev Ivo, Mon, 14:08 New comment Lin, Tue, 05:33 This is not NAS, why add it? Sung, Wed, 03:37 Defending, should an LS be sent? Lin, Wed, 08:51 This is all CN internal, why do anything in CT1 Ivo, Wed 09:10 Arguing Sung, Wed, 23:38 Prposes an LS and provides some justification Ivo, Thu, 00:24 Does not agree with Sung
C1-202417	Handling of correction to UE configuration update procedure conditions for re-registration	LG Electronics France	CR 2160 24.501 Rel-16	Withdrawn Not available on time
C1-202418	Correction to conditions for including the S-NSSAI(s) from default NSSAI in the requested NSSAI	Qualcomm Incorporated / Amer	CR 2161 24.501 Rel-16	Frederic, Thu, 09:08 Clauses affected missing
C1-202420	Definition of current PLMN and serving PLMN	Qualcomm Incorporated / Amer	CR 2163 24.501 Rel-16	Postponed Based on request from author, Tue, 15:49 Frederic, Thu, 09:08 Clauses affected missing Ivo, Thu, 12:19 Commenting on used terms “current PLMN” “registered PLMN”, asks for single term, cover sheet Vishnu, Fri, 18:49 do not prefer to have these new definitions in 24.501
C1-202436	Discussion on the selected EPS NAS security algorithms	BEIJING SAMSUNG TELECOM R&D	discussion	Noted Andrew, Thu, 11:59 Has the proposal in C1-202436 been discussed and endorsed by SA3? Are there supporting requirements in the SA3 specifications to support the change? Mahmoud, Thu, 16:45 Explaining that the proposal does not need to be discussed in SA3, asking for specific comment against the proposal Fei, Fri, 04:41 Fine in principle, additional cases needed Andrew, Fri, 14:41 Does not like if, if the group agrees, andrew can live with it Mikael, Fri, 23:15 Similar as Andrew, will discuss internally and come back Mahmou, Fri, 23:39 Fine to wait for further comments Mahmoud, Mon, 17:40 Fine with Fei’s comment Mikael, Tue, 16:14 Needs SA3 analysis first, request the CR postponed and await SA3 outcom
C1-202437	Condition for setting the Selected EPS NAS algorithm IE to NULL	BEIJING SAMSUNG TELECOM R&D	CR 2171 24.501 Rel-16
C1-202477	Correction on UE behaviour for service area restriction	Huawei, HiSilicon/Lin	CR 1823 24.501 Rel-16	Revision of C1ah-200161
C1-202480	Service reject for emergency EPS fallback	Huawei, HiSilicon/Lin	CR 3359 24.301 Rel-16	Withdrawn Used CR number against 24.301 although targeted for 24.501
C1-202481	Handling of mapped EPS bearer contexts	Huawei, HiSilicon/Lin	CR 3360 24.301 Rel-16	Withdrawn Used CR number against 24.301 although targeted for 24.501
C1-202482	Integrity check interworking in 5GMM-CONNECTED mode	Huawei, HiSilicon/Lin	CR 3361 24.301 Rel-16	Withdrawn Used CR number against 24.301 although targeted for 24.501
C1-202483	Correction on LADN DNN based congestion control	Huawei, HiSilicon/Lin	CR 3362 24.301 Rel-16	Withdrawn Used CR number against 24.301 although targeted for 24.501
C1-202504	MRU failed due to RRC signalling connection release in restricted service area	MediaTek Inc.	CR 2186 24.501 Rel-16	Postponed Based on request form author, tue, 12:16 Osama, Thu, 21:34 concern with the idea of moving to not updated state. Kaj, Fri, 06:51 Fine but should state 5GMM cause #28 Marko, Fri, 09:58 Explains the problem to Osama, fine with kaj comment Osama, Fri, 16:40 Still commenting Sung, Fri, 23:18 Some wording fixes
C1-202509	Correction to 5G-GUTI handling when received at REGISTRATION ACCEPT	MediaTek Inc.	CR 2191 24.501 Rel-16	Postponed Osama, Thu, 19:12 Text unclear Sung, Fri, 22:43 Neutral on the CR, but needs an “if any”
C1-202510	Correcting that 5G NAS integrity key is one of the input parameters for integrity protection algorithm	MediaTek Inc.	CR 2192 24.501 Rel-16
C1-202518	Correction to Handling of #31	MediaTek Inc.	CR 2194 24.501 Rel-16
C1-202523	De-registration before initial registration for Emergency Services	MediaTek Inc.	CR 2197 24.501 Rel-16
C1-202525	Handling of rejected NSSAI for the current RA when the RA includes the TAI belonging to EPLMN	SHARP	CR 2199 24.501 Rel-16	Withdrawn Based on request form Author, Wed, 09:17 Kaj, Fri, 07:00 proposed changes are not needed as already covered by 4.6.1 Yoko, Fri, 08:34 Explaining why this is needed Osama, Fri, 18:50 Same as Kaj Vishnu, Fri, 18:23 Change is confusing Yoko, Mon, 04:26 Explaining Vishnu, Mon, 10:58 Does not agree wit the CR
C1-202526	Correction to deletion of Allowed NSSAI	Huawei, HiSilicon / Vishnu	CR 2200 24.501 Rel-16	Ani, Sun, 13:12 Existing text enough, CR not needed Vishnu, Mon, 20:58 Explaining Ani, Tue, 03:47 Commenting to Vishnu Vishnu, Tue, Coomenting Ani, Wed, 03:34 Can live with this, would prefer existing spec. NOT CLEAR so far Ani, thu, 04:20 CR is ok
C1-202583	Security handling	Samsung/ Kyungjo Grace Suh	CR 2211 24.501 Rel-16	Withdrawn
C1-202634	Add handling for parameter set to “value is not used” in 5GS	Qualcomm Incorporated	CR 2093 24.501 Rel-16	Revision of C1-202268 _________________________________________ Ivo, Thu, 12:14 semantic of "release/version" is not clear. Can we use solely "version"? Sung, Fri, 00:22 Prefers “release” Osama, Sun, 16:28 Checking if “release” is ok Ivo, Mon, 13:22 Release is fine Sung, Wed, 01:59 OK
C1-202635	Add handling for UE configured to use timer T3245 in 5GS via 3GPP access	Qualcomm Incorporated	CR 1803 24.501 Rel-16	Revision of C1-202278 _________________________________________ Revision of C1ah-200178 Ivo, Thu, 12:14 NOTE in 24.501 subclause 10.2 needs to be updated as well Osama, Fri, 21:01 Acks Ivo Osama, Fri, 16:47 Providing rev in Inbox Vishnu, Mon, 13:23 Fine Ivo, Mon, 13:28 Some “colors” in the accepted version, wants to co-sign Sung, Wed, 02:00 Co-sign
C1-202607	OTAF renamed to SP-AF	Orange / Mariusz	CR 0510 23.122 Rel-16	Revision of C1-202070 _________________________________________ Ivo, Thu, 12:03 Use 5GS_OTAF as work item code Lena, Thu, 16:41 Untick ME box Mariusz, Fri, 11:12 Provides rev Ivo, Fri, 11:51 Fine with rev, wants to co-sign Len, Thu, 01:56 Fine with draft
C1-202680	UAC exception for emergency	MediaTek Inc.	CR 2184 24.501 Rel-16	Revision of C1-202501 Roozbeh, Tue, 00:43 Fine Ivo, Wed, 13:20 fine _________________________________________ Ivo, Thu, 12:23 Editorials Roozbeh, Fri, 03:20 Editorials
C1-202683	Correction to criteria to enter 5GMM-REGISTERED.UPDATE-NEEDED substate after resumption failure	MediaTek Inc.	CR 2187 24.501 Rel-16	Revision of C1-202505 Roozbeh, Wed, 01:30 Fine Ivo, Wed, 23:48 Fine Sung, FINE Ivo, Thu, 12:25 Ivo challenging the proposal Roozbeh, Fri, 03:25 Bulleting to be changed Sung, Fri, 20:07 no need for the CR. Marko, Tue, 13:20 Will change some parts
C1-202697	Unify terms network-initiated and network-requested	Huawei, HiSilicon / Cristina	CR 2103 24.501 Rel-16	Revision of C1-202295 Osamah, Thu, 18:41 Needs to be CAT D Cristina, Fri, 04:20 Will change category Roozbeh, Sun 20:51 Wants to keep CAT F Cristina, Mon, 10:53 Explaining on categories Roozbeh, Mon, 17:56 CAT F Crisitna, Tue, 01:54 Wants to keep CAT F
C1-202698	Add MFBR as mandatory parameter in GBR QoS flow	Huawei, HiSilicon / Cristina	CR 2120 24.501 Rel-16	Revision of C1-202344 Osama, Wed, 21:39 fine Osama, Fri, 02:38 GBR ok, non-GBR to be rewritten Cristina, Fi, 12:20 Asking from Osama Osama, Fri, 20:07 Suggestion looks good, is it “or” or “and” Cristina, Sat, 05:09 Acks Osama
C1-202684	T3346 handling when the UE is registered to different PLMNs over 3GPP and non-3GPP	MediaTek Inc.	CR 2190 24.501 Rel-16	Revision of C1-202508 Sung can live with this Kaj, Fri, 11:01 Requests this to be postponed Kaj, Thu, 17:09 Not needed, already covered Vishnu, Thu, 17:19 Not needed Amer, Thu, 20:30 New text could be a NOTE Behrouz, Thu, 23:50 I am perfectly OK with this CR. Sung, Fri, 23:41 CR not needed Amer, Sat, 04:47 Keep text minimal Kaj, Wed, 10:54 Fine
C1-202599	Subscription management in PWS-IWF	one2many B.V.	CR 0214 23.041 Rel-16	Revision of C1-202076 Frederic, Thu, 09:08 Clauses affected missing
C1-202623	Removal of Duplicate Service Operation Details	one2many	CR 0207 23.041 Rel-16	Revision of C1-202073 Revision of C1-200308 Ban, Sat, 13:27 Providing comments Lazaros, Mon, 19:54 Comments PeterS, Tue, 11.10 Offers an proposal Lazaros, Tue, 11:26 ok
C1-202793	Modification of exchanges between SOR-AF and UDM	Orange, Ericsson / Mariusz	CR 0509 23.122 Rel-16	Revision of C1-202069 Ivo: Fine Releated CR in C1-202152 Ban, Sat, 09:26 Answering on 2151 LSout, thinks this CR needs to be postponed Ban, Sat, 13:12 alignment of procedures in stage-2 and stage-3 needed Mariusz, Tue, 15:50 Can the CR stay unchanged? Ban, Tue, 20:48 Some comments against the CR Mariusz, Wed ,11:43 New rev Ban, Wed, 11:55 fine
C1-202812	Restricting handling of cause #9 to the access on which it was received	Samsung/Anikethan	CR 1792 24.501 Rel-16	Revision of C1-202149 Revision of C1ah-200031 Osamah, Thu, 18:17 Asks for clarification Ani, Fri, 05:56 Explaining to Osama Osama, Fri, 18:15 More con than pro, can live with it, tick ME box on the cover sheet Ani, Sat, 02:26 Acks to Osama, wants to get a bit more info
C1-202815	Specify UE azaros for NOTIFICATION message for additional state/sub-states	Samsung/Anikethan	CR 2051 24.501 Rel-16	Revision of C1-202145 Osamah, Thu, 18:15 Editorial Vishnu, Fri, 16:38 Bullet b) causes inconsistency Ani, Sat, 15:45 Provides a rev Osama, Sat, 20:29 Rev looks fine Vishnu, Sun, 21:37 Fine with the rev
C1-202687	Correction to Handling of T3521 timer	MediaTek Inc.	CR 2193 24.501 Rel-16	Revision of C1-202514 Roozbeh, Fri, 03:38 Just a NOTE might be better Kaj, Fri, 06:25 Fine with the proposal, some rewording Kaj, Fri, 06:34 Asks to disregard his previous email Kaj, Fri, 06:36 Fine with the proposal, some rewording Marko, Tue, 20:04 Will revise
C1-202652	Clarification on URSP in EPS	ZTE / Joy	CR 0073 24.526 Rel-16	Revision of C1-202144 Ivo, Thu, 12:05 Requires some clarification Lena, Thu, 16:41 ok but it should be moved to the xBDT WI (AI 16.2.16). Joy, Fri, 05:34 To Ivo, explaining, is it ok? Joy, Fri, 06:47 This is xBDT and 5Gprotoc16 Lena, Tue, 03:31 xBDT firt, no problem to list TEI16 Joy, Tue, 04:33 In addition to xBDT, wants 5Gprotoc16 Lena, Tue, 06:32 fine
C1-202752	PS Data Off status report for non-3GPP access	LG Electronics, Ericsson / SangMin	CR 2102 24.501 Rel-16	Revision of C1-202289 Partially overlaps with C1-202120 Joy, Thu, 11:44 Newly introduced condition is not correct, new NOTE not complete Roozbeh, Fri, 00:11 Update cover page, requests changes Roozbeh, Sat, 20:44 Resending the comment, correct Ai SangMin, Tue, 10:33 Commenting Roozbeh, Tue, 21:11 Fine with new proposal, i.e SanMin will revise this CR SangMin, Wed, 10:44 Rev Roozbeh, wed, 19:21 fine
C1-202861	Missing QoS flow description parameters for GBR QoS flows in 5GSM and ESM coordination	Huawei, HiSilicon / Cristina	CR 2122 24.501 Rel-16	Revision of C1-202651 Osama, thu, 03:45 Commenting Cristina, Thu, 06:59 Does not agree with Osama Revision of C1-202349 Osama, Tue, 23:52 Editorials Osam, Wed, 02:00 Comments and proposals for additions Cristina, Wed, 05:58 questions Ivo, Thu, 12:15 Wrong formatting Osamah, Thu, 18:53 Please revise the CR and check the conditions again if applied to EPS ESM procedure and rewrite UE behavior to use EPS ESM procedures defined in TS 24.301 Cristina, Fri, 07:09 Fine with comments, rev to come later
C1-202868	Correcting order in which connections/sessions are transferred if there is an emergency call	BlackBerry Uk Ltd.	CR 1782 24.501 Rel-16	Revision of C1-202670 Lena, Thu, 07:06 Fine Vishnu, Thu, FINE Revision of C1-202098 Revision of C1-200115 Lena, Thu, 16:41 no need to specify in which order the UE transfers PDU sessions John-Luc, Thu, 17:22 Explaining that CR has evolved and why it is needed Vishnu, Fri, 15:47 not OK with the CR. John-Luc, Tue, 16:42 Explaining the case Vishnu, Tue, 17:14 Remove the Note John-Luc, Tue, 18:42 Takes out the Note Fine provides rev Lena, thu, 0324 Can’t agree
C1-202843	No available S-NSSAIs and emergency PDU session at handover	Ericsson /kaj	CR 2088 24.501 Rel-16	Postponed Revision of C1-202255 NOT ON THE SERVER Roozbeh, Thu, 23:53 Is in general agreement, some rewording needed, asks a question Fei, Fri, 04:05 Clarification fine, capability indication not needed Sung, Sat, 00:06 Commenting what he sees is needed, minimal Osama, Sat, 02:49 Asking questions Ani, Sat, 04:27 Same as Sung Lena, Sun, 20:39 Agrees with Sung, Ani Kaj, Mon, 22:47 Explaining the approach, why 5GMM capability is needed Sung, Wed, 02:12 Not agreeing with Kaj Sung, Wed.21:03 Not agreeing with Kaj Kaj, Wed, 22:20 Arguing Sung, wed, 22:23 Not agreeing Kaj, wed, 22:50 Not agreeing, Ongoing Ani, thinks that existing text covers this
C1-202873	Clarification on use of operator-defined access categories	Qualcomm Incorporated, Ericsson, Nokia, Nokia Shanghai Bell / Lena	CR 1795 24.501 Rel-16	Revision of C1-202100 _________________________________________ Revision of C1ah-200149 Vishnu, Sat, 11:10 Requires changes in the CR Lena, Tue, 07:01 Provides rev Vishnu, Tue, 13:54 Fine Lena, Wed, 01:00 Additional rev to capture some more Vishnu, Wed, 09:30 fine
C1-202705	Allowed SSC mode for association between an application and a PDU session	OPPO / Rae	CR 0075 24.526 Rel-16	Revision of C1-202491 _________________________________________ Joy, Thu, 12:01 Reason for change not correct, existing bullet va) incorrect Ivo, Thu, 12:22 Summary of changes seem incorrect Lena, Thu, 16:40 CR has a point, needs rewording Roozbeh, Fri, 03:07 Original text works, if there is a need for a change then this needs rewording Rai, Fri 04:58 Explaining here cse Joy, Fri, 09:07 This is not correct Joy, Fri, 10:47 Now agrees, proposes some rewording Roozbeh, Sun, 02:44 Providing wording Rae, Mon, 03:41 Discussing Roozbeh, Tue, 00:42 Some comments Rae, tue, 04:12 Explaining Roozbeh, Tue, 18:27 Still some change Rae, Wed, 04:20 Similar understanding as Roozbeh Roozbeh, Wed, 05:39 There is a need for some mandatory wording Roozbeh, 05:41 Is it only me having concerns? Lena, Thu, 05:36 Not agreeing with Roozbeh proposal Roozbeh fine with latest proposal from lena
C1-202706	Handling of unallowed SSC mode	OPPO / Rae	CR 2183 24.501 Rel-16	Revision of C1-202492 Roozbhe fine ________________ Joy, Thu, 11:58 Same purpose as 2280 and is incoplete, pls see comments on 2280 Lena, Thu, 16:40 CR has a point, but requires rewording Roozbeh, Fri, 03:07 Original text works, if there is a need for a change then this needs rewording Rae, Fri, 04:50 Not convinced with Lena rewording Lena, Tue, 02:48 Fine with Rae explanation, found some more issues, if they are folved then it should be fine Rae, Tue, 04:19 New rev Roozbehm Tue, 22:22 New suggestion Rae, Wed, 04:37 Similar understanding as roozbeh Roozbeh, Wed, 05:45 Some proposal Lena, Thu, 02:49 Cover sheet Rae, Thu, 04:07 Not agreeing with Roozbeh Roozbeh OK Lena OK
C1-202890	Additional condition to start T3540	Samsung/Anikethan	CR 2050 24.501 Rel-16	Revision of C1-202811 Vishnu: FINE _________________________________________ Revision of C1-202141 Marko, Thu, 08:01 This is a corner case, i.e. “May” Ani. Thu 08:22 New rev Mark, Thu, 08:37 fine Osamah, Thu,18:14 Wording to be improved Yanchao, Fri, 05:49 why start T3450 for this case? Previous discussion taken out Ani, Tue, 19:32 Rev Osama, Tue, 20:42 Not ok with all changes Vishnu, Tue, 21:36 Only the last change, with that Huawei co-signs Ani, Wed, 05:15 New rev Maoki, Wed, 10:58 Fine with the CR, beef up Cover Sheet Kaj, Wed, 13:42 New questions Ani, Wed, 14:46 Answers Kaj, Wed, 15:56 Questions Ani, Wed, 16:27 Explaining Kaj, Wed, 17:33 Asking Osama, Wed, 19:35 Editorials Ani, Wed, 20:04 Answering kaj Kaj, Thu, 00:18 Does not agree Kaj, Thu, 08:20 Fine
C1-202874	Additional QoS error handling related to mapped EBI	Qualcomm Incorporated / Lena	CR 2101 24.501 Rel-16	Revision of C1-202285 ______________________________ ___________ Ivo, Thu, 12:15 … the check should not be dependent on QoS flow description being associated with the EPS bearer Discussion not shown, lena<>JJ JJ, OK
C1-202893	Initial registration for initiating emergency PDU session	Huawei, HiSilicon / Cristina	CR 2121 24.501 Rel-16	Revision of C1-202858 Sung FINE _________________________________________ Revision of C1-202348 Ivo, Thu, 09:54 comments Ivo, Thu, 12:15 Broken styles, some of the new bullets are already covered by existing bulltets Sung, Fri, 01:20 Asks why adding T3502 and T3511 is needed Cristian, Fri, 06:27 Will provide a revision Sung, Sat, 00:40 question on the registration type Cristina, Sat, 05:29 Answering Sung Lena, Sun, 22:31 Some things not clear, cover page update needed Cristina, Mon, 04:21 Explaining Ivo, Mon, 13:48 Challenging the CR Cristian, Tue, 02:42 Explaining Ivo, Tue, 12:38 Additional wording Cristina, Tue, 12:59 Additional change needed? Ivo, Wed, 13:12 clarifying
C1-202783	Editorial corrections	Ericsson / Mikael	CR 2074 24.501 Rel-16	Revision of C1-202218 _________________________________________ Roozbeh, Thu, 23:13 Editorial on the cover page Mikael, Fri, 07:40 Asks roozbeh to use correct subject line
C1-202820	Unsupported 5QI values	MediaTek Inc. / JJ	CR 0686 27.007 Rel-16	Revision of C1-202537 _________________________________________ Osama, Fri, 02:33 Why is there difference btw +CGEQOS and +C5GQOS JJ, Fri, 05:12 Provides revision in INBOX Atle, Fri, 07:54 Agrees with the rev in INBOX Osama, Fri, 19:32 Rev looks good
C1-202897	storage of counters for UE in PLMN	vivo	CR 2071 24.501 Rel-16	Revision of C1-202713 Revision of C1-202200 _________________________________________ Osamah, Thu, 22:01 Not extremely important to repeat DoS related counters in Annex C Yanchao, Mon, 10:23 Provides a rev Osama, Mon, 16:14 Further comments Yanchao, Tue, 08:59 Provides a rev Osama, Tue, 16:18 Further comments Yanchao, Wed, 13:29 Asking forn Osama Osama, wed:20:39 Still an issue with shall to may Yang, Wed, 08:42 Shall
C1-202821	Addition of 5GSM cause #59	MediaTek Inc. / JJ	CR 2205 24.501 Rel-16	Revision of C1-202538 _________________________________________ Ivo, Thu, 12:49 Not convinced that #59 is really needed Roozbeh, Fri, 04:24 questions for clarification JJ, Fri, 14:27 Provides a rev Ivo, Mon, 14:25 Not convinced Jj, Tue, 09:31 Commenting Sung, Wed, 04:05 UE behavriou needed JJ, Wed, 12:37 New rev Ivo, Wed, 13:39 Asking for a NOTE Jj, Wed, 14:11 Can do the Note Ivo, Wed, 19:10 Co-signs
C1-202902	Correcting the parameter "RAT type" for SOR-AF	DOCOMO Communications Lab.	CR 0515 23.122 Rel-16	Postponed Revision of C1-202152 _________________________________________ Releated CRs in C1-202068, C1-202069 Ivo, Thu, 12:08 Explanation ….Thus, we see no need of this CR. Ban Ivo, Tue, 14:28 providing "access technology" is not acceptable. Mariusz, Tue, 16:33 Sung, Wed, 14:54 negative Ban, Providing a rev Marius ongoing Marius FINE Ivo, Thu, 11:26 Ericsson sees no benefit in UDM performing the access technology derivation from RAT type on SOR-AF's behalf. Ban not agreeing with Ivo Ivo not agreeing it Ban not agreeing Ivo DOES NOT agree
C1-202889	Handling of allowed NSSAI when the RA includes the TAI belonging to EPLMN	SHARP	CR 2198 24.501 Rel-16	Revision of C1-202524 _________________________________________ Osama, Fri ,18:55 Commenting, asing for changes Yoko, Tue, 08:24 Asking for clarification form Osama Kaj, Tue, 15:58 Comments Yoki, Wed, 05:05 Rev Osama, Wed ,21:30 Issues, prefers short sentence and a ref Yoko, thu, 02:24 New rev
C1-202696	UE behaviour when the UE receives the rejected NSSAI for the current RA in the registration reject message and the RA is not stored	SHARP	CR 2202 24.501 Rel-16	Revision of C1-202528 ______________________________ Roozbeh, Fri, 04:08 Is an implementation issue Krisztian, 05:40 Why don’t we align the behavior in 5.5.1.2.5 with the behavior in 5.4.4.3 Yoko, Fri, 06:45 Not agreeing with Roozbeh Yoko, Fri, 07:52 Explains to Krisztian why it is needed Osama, Fri, 16:00 Not convinced Vishnu, Fri, 18:31 Commenting, not right solution Krisztian, Fri, 21:05 Further comments Ani, Sat, 04:35 Same as Osama Roozbeh, Sat, 22:30 Wants clarification Roozbeh, Sun, 01:19 I am not convinced if there is any needed text Yoka, Mon, 07:37 Providing some wording Ani, Tue, 04:44 Some proposals Yoko, Tue, 08:24 Providing a rev Ani, Tue, 19:52 Fine, co-sign Ani, Tue, 20:05 Update cover sheet Vishnua, Tue, 23:02 Can not agree this CR Yoko, Wed, 02:31 Rev Ani, Wed, 03:30 Defending the CR Vishnu, Wed, 08:57 More clarification needed Ani, Wed, 09:04 Is Vishnu OK Vishnu, wed, 09:28 Not convinced, but will not object Yoko, Wed, 10:30 New rev Kaj, Wed, 11:23 New comment Ani, Wed, 11:41 To Vishnu Ani; wed, 12:29 Explaining to Kaj
C1-202615	Applicable URSP is not optional for a UE	Motorola Mobility, Lenovo	CR 2098 24.501 Rel-16	Reviion of C1-202280 Lena, fri, 00:01 Not full correct, agrees, that you will bring a revision to the May meeting to address this issue Roozbeh acks that this will be resolved JJ is fine with this assumption ------------------------------------------- Joy, Thu, 11:57 Text needs to be more precise, Lena, Thu, 16:41 Requires rewording Rae, Fri, 11:47 Comments Roozbeh, Sun, 19:31 Providing rev in Inbox Maoki, Mon ,09:18 More to consider Roozbeh, Tue, 02:24 Explaining Rae, Tue, 04:15 Some comments on the rev Joy, Tue, 05:45 Generally fine, editorial Jj, Tue, 07:36 Agreeing with Rae Roozbeh, Tue, 20:56 New rev Maoki, Wed, 06:44 Withdraws comment, fine Rae, Wed, 11:26 More needed JJ, Wed, 19:11 More comments Roozbeh, Wed, 19:12 New rev Roozbeh, Thu, 00:39 Explanation Len, Thu, 02:13 Not ok with the rev Roozbeh, Thu, 03:21 Not clear what lena comment is JJ, Thu, 04:31 Comments Lena, Thu, 05:01 More comments Roozbeh New rev Lena, Thu, 06:32 Still issues Roozbhe, thu Ongoing w Lena, Thu, 07.22 Explaining Roozbeh, Thu, 07:40 Discussing New REV
C1-202801	Corrections on the abnormal cases of registration procedure for initial registration	Huawei, HiSilicon/Lin	CR 1379 24.501 Rel-16	Revision of C1-202476 _________________________________________ Revision of C1-199032 Kaj, Thu, 16:32 Fine, some rewording Osama, Fri, 16:18 Commenting Lin, Sat, 08:33 Provides rev Osama, Sun 20:07 Further questions Lin, Tue, 12:01 Rev Osama, Tue, 22:26 Q for clarification Lin, Wed, 11:03 Answering Osama Osama, Wed, 16:20 Not convinced Lin, Thu, 03:12 Asking for clear advice what is to be changed from Osama Osama, Thu, 03:21 Provides wording Lin, thu, 08:33 New rev
C1-202802	Single-registration mode without N26	Huawei, HiSilicon/Lin	CR 2182 24.501 Rel-16	Revision of C1-202478 Lena, Thu, 16.41 Some parts are ok, some changes are not OK Sung, Fri, 22:29 Same as Lena Lin, Mon, 12:21 Providing a rev Sung, Wed, 01.58 Ok either way Lin, Wed, 11:09 Explaining Lena, Thu, 02:31 Not ok with some of the changes Lin, Thu, 05:03 Discussion with Lena Lena, Thu, 06:41 Explaining Fei, Thu, 08:46 Condition update Lena, Thu, 08:59 Does not work
C1-202803	Single-registration mode without N26	Huawei, HiSilicon/Lin	CR 3358 24.301 Rel-16	Revision of C1-202479 _________________________________________ Lena, Thu, 16:40 perform TAU differently depending upon whether there is N26. This is not ok, further issue with security context Sung, Fri, 22:34 Same as Lena Lin, Sat, 09:10 Provides a rev, but asks to send an LS to SA3 Sung, sun, 02:45 Fine with the rev, fine with sending LS Lena, thu, 02:04 Fine with rev, fine with sending LS
C1-202805	Service reject for emergency EPS fallback	Huawei, HiSilicon/Lin	CR 2213 24.501 Rel-16	Postponed Revision of C1-202592 Lena, Fri, 00:35 Cannot agree Sung, Fri, 01:01 Has concerns _________________________________________ Ivo, Thu, 12:51 Do not see this as mandatory AMF action, not convinced that this is really quicker Sung, Fri, 20:39 Decision criteria not known in the network Lena, Sun, 22:52 Not in favour of this change Lin, Wed, 11:49 Providing a rev Sung, Wed, 14:04 Asking questions Lin, Thu, 05:20 answering
C1-202806	Handling of mapped EPS bearer contexts	Huawei, HiSilicon/Lin	CR 2214 24.501 Rel-16	Revision of C1-202593 _______________________ __________________ Ivo, Thu: 12:51 “message” is missing Lin, Sat, 05:15 Will be done in rev
C1-202807	Integrity check interworking in 5GMM-CONNECTED mode	Huawei, HiSilicon/Lin	CR 2215 24.501 Rel-16	Revision of C1-202594 _________________________________________ Amer, Thu, 20:28 Check the CN box on cover sheet Fei, Fri, 04:51 Note to be enhanced Lin, Sat, 05:27 Asking Fei to clarify, acks Amer Fei, Tue, 08:31 Proposal Lin, Tue, 12:22 rev Fei FINE
C1-202808	Correction on LADN DNN based congestion control	Huawei, HiSilicon/Lin	CR 2216 24.501 Rel-16	Revision of C1-202595 _________________________________________ Ivo, Thu, 12:51 Many conditions are missing Osamah, Thu, 19:02 Changes to clause 6.x not needed, additional comments Lin, Sat, 09:23 Rev in Inbox Osama, Tue, 23:44 Some comments Lin, Wed, 11:55 New rev Osama, Wed, 16:26 Looks good Ivo, Thu, FINE
C1-202709	NW triggered SR over N3GPP under MM congestion control	OPPO / Rae	CR 2104 24.501 Rel-16	Revision of C1-202324 Amer FINE ________________________ _________________ Joy, Thu, 11:53 the changes should be applicable only when the UE is regsitered with the same PLMN over 3GPP access and non-3GPP access, this is missing in the CR Rae, Thu, 12:56 Explaining her approach Kaj, Thu, 15:05 Requires changes Sung, Thu, 23:10 Needs improvement, agrees with some of Kaj’s proposals Roozbeh, Fri, 01:00 Update cover sheet, some improvement needed Amer, Sat, 04:41 Answering ot Sung Ani, Mon, 08:11 Comments Kaj, Mon, 13:48 Comments, Chend, Mon, 17:52 Defending Chen; Tue, 16:58 Providing a rev Amer, Wed, 07:27 Changes need to go to different clause Yoko, Wed, 09:07 Fine Kaj, Wed, 14:09 improvements Chen, Wed, 17:44 New rev Roozbeh, Wed, 20:26 Fine Amer, Thu 01:54 Which aspect of the CR is new? Ani, Thu, 06:22 Fine, some suggestions Chen, NEW REV Ani FINE
C1-202921	Notification over non-3GPP access when UE is deregistered over 3GPP access	Ericsson /kaj	CR 2082 24.501 Rel-16	Revision of C1-202244 Ani, Fri, 03:56 We DO NOT agree to this solution _________________________________________ Roozbeh, Thu, 23:24 Cover page needs improvement, existing text has a spelling error Rae, Fri, 12:12 Not clear this can happen Vishnau, Fri, 16:46 This does not solve the problem Sung, Fri, 17:58 Supports Vishnu Ani, Sat, 22:49 Does not solve problem, supported C1-202146
C1-202682	MRU after SR for ESFB aborted	MediaTek Inc.	CR 2185 24.501 Rel-16	Revision of C1-202503 _________________________________________ Kristzian, Fri, 06:17 Couple of comments Sung, Sat, 00:29 First change ok, second change not needed Krisztian, Mon, 23:05 Can support second change Marko, Tue, 08:59 Acks Sung, Wed, 20:47 Taking back one comment, i.e. second change can go forward, first??
C1-202747	No allowed NSSAI associated with a registration area	vivo	CR 2061 24.501 Rel-16	Withdrawn Revision of C1-202175 _________________________________________ Kaj, Thu, 14:39 Does not see that the proposal makes it clearer Yanchao, fri 06:14 Explaining why the CR is good
C1-202931	Attach request message for N1 mode	Nokia, Nokia Shanghai Bell, Ericsson	CR 3150 24.301 Rel-16	Revision of C1-202391 _________________________________________ Revision of C1ah-200180
C1-202928	Indication that the emergency services fallback attempt failed	Nokia, Nokia Shanghai Bell	CR 2142 24.501 Rel-16	Revision of C1-202382 ________________________ _________________ Lin, Fri, 10:41 current text is not so accurate but better to modify the existing text Sung, Fri, 16:48 Asking form Lin Lin, Tue, 05:20 Commenting Sung, Wed, 02:36 Rev Lin, Wed, 08:19 fine
C1-202929	Inclusion of ATTACH REQUEST message in REGISTRATION REQUEST message during initial registration when 5G-GUTI mapped from 4G-GUTI is used	Nokia, Nokia Shanghai Bell, Ericsson, Qualcomm Incorporated	CR 0793 24.501 Rel-16	Revision of C1-202390 _________________________________________ Revision of C1ah-200179 Roozbeh, Fri, 02:54 “or” instead of “and” Fei, Fri, 04:39 asks a question Lin, Fri, 10:34 Ok in principle, requests some changes Sung, Tue, 23:04 Provides a rev Roozbeh, Wed, 01:44 Some more change Fei, Wed, 04:27 More is needed Lin, Wed, 08:36 Fine Fei, Wed, 09:07 Discussing Sung, Wed, 14:07 Discussing with Fei Sung, Wed, 22:56 Ongoing with Fei Fei, Thu, 08:12 Can live with it
C1-202932	Paging with two valid 5G-GUTIs	Nokia, Nokia Shanghai Bell	CR 1841 24.501 Rel-16	Revision of C1-202392 _________________________________________ Revision of C1ah-200213 Kai, Thu, 15:35 Fine, some comments Sung, Fri, 21:45 Provides rev
C1-202600	Addition of Test Flag	one2many B.V.	CR 0215 23.041 Rel-16	Postponed Revision of C1-202203 _________________________________________ Current Status Postponed RAN3 LS not received Frederic, Thu, 09:08 Clauses affected missing Lazaros, Thu, 17:03 Wait for RAN3 discussion to conclude Commenting the content of the CR PeterS, Thu, 20:46 Agrees to wait for RAN3, is happy to work on improving the text Lazaros, Tue, 18:24 Wait for the RAN3 LS PeterS, Tue, 10:45 Commenting
5Gprotoc16-non3GPP	Peter – Main	Stage-3 5GS NAS protocol development related to non-3GPP access
C1-202279	Add handling for UE configured to use timer T3245 in 5GS for non-3GPP access	Qualcomm Incorporated	CR 0121 24.502 Rel-16
C1-202907	Extending congestion notification to capture ePDG overload	Nokia, Nokia Shanghai Bell, Charter Communications	CR 0718 24.302 Rel-16	Revision of C1-202578 Amer Fine _________________________________________ Ivo, Thu, 12:52 Does not see a need for the CR Amer, Thu, 20:32 Same as Ivo, not needed Roozbeh, Sat, 00:13 CR is not needed Lazaros, Thu, 11:55 NEW REV
C1-202903	Extending congestion notification to capture N3IWF or TNGF overload	Nokia, Nokia Shanghai Bell, Charter Communications	CR 0130 24.502 Rel-16	Revision of C1-202579 _________________________________________ Joy, Thu, 12:02 not appropriate to use this private error type”CONGESTION” to reflect the congestion status in N3IWF itself. Roozbeh, Fri, 23:20 Not sure about Joy’s comment, solution is simpler than the RFC Roozbeh, Sat: 00:08 Taking back previous comment, CR is NOT needed Lazaros, Tue, 22:57 Explaining Roozbeh, Wed, 16:12 Not convinced this is needed Lazaros, Wed, 17:12 Explaining Roozbeh, Thu, 02:09 Explaining Lazaros, Thu, 11:25 Discussing Joy can live with it
C1-202901	Enable N3IWF to initiate TCP connection establishment upon failure	Nokia, Nokia Shanghai Bell	CR 0131 24.502 Rel-16	Revision of C1-202580 _________________________________________ Ivo, Thu, 12:52 Is misleading Roozbeh, Fri, 04:39 Proposes changes Lazraros, Thu, 01:33 Rev Roozbeh, Thu, 02:37 New suggestions Ivo, Thu, 10:05 Commenting Lazaros providing a rev
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#88 for approval? Show of hands, 16.04./17.04. Support for C1-202019 (Ericsson) 24 Support for C1-202266 (Apple) 14
C1-202009	EPS interworking of MA PDU session of 5G-RG when N26 is not supported	Ericsson / Ivo	CR 2027 24.501 Rel-16
C1-202142	Correction on network steering functionalities information	ZTE / Joy	pCR 24.193 Rel-16
C1-202266	ATSSS Performance Measurement Function Protocols and Procedures	Apple, Deutsche Telekom, Charter Communications, Ruckus, Commscope	pCR 24.193 Rel-16	Not Pursued Based on outcome of show of hands and confirmed in confcall and email from Krisztian Revision of C1-200655 Ivo, Thu, 12:52 Prefers Ericsson solution
C1-202294	Discussion on handling of clause 5.2 in TS 24.193	ZTE / Joy	discussion Rel-16	Noted Roozbeh, Thu, 20:54 Looking for related CR, some improval for 4.12 Atle, Thu, 22:54 Good paper, provides some proposals Peter See result from ConfCall#3
C1-202371	Clarification of UE azarosi on receiving ATSSS support indicator	SHARP	CR 2133 24.501 Rel-16	Postponed Based on request from author, Wed, 08:58 Joy, Thu, 11:45 change in this CR is not needed. It has been specified in clause 5.2.5 of 24.193 already. Atle, Thu, 23:01 Not needed Mikael, Fri, 16:55 Not needed
C1-202533	Correction to the steering modes	MediaTek Inc. / JJ	pCR 24.193 Rel-16	Roozbeh, Thu, 22:13 Not convinced new text is needed JJ, Fri, 13:36 Explaining to Roozbeh Roozbeh, Sat, 20:01 CR is fine
C1-202575	PMF protocol alternatives analysis	Nokia, Nokia Shanghai Bell	discussion Rel-16	Noted Roozbeh, Thu, 22:31 Some comments Krisztian, Fri, 07:19 comments Lazaros, Fri, 11:51 answers
C1-202576	Minor clarification for ATSSS-LL support	Nokia, Nokia Shanghai Bell	CR 2209 24.501 Rel-16	Withdrawn
C1-202577	Clarification on MAI	Nokia, Nokia Shanghai Bell	pCR 24.193 Rel-16	Withdrawn
C1-202582	Service Request for Multiple access PDU session	Samsung / Kyungjoo Grace Suh	pCR 24.193 Rel-16	Postponed Roozbeh, Thu, 22:35 Asks for rewording Lena, Fri, 05:14 Where is the stage-2 Lazaros, Fri, 12:16 do not see the need for the CR
C1-202622	Comparison of solutions for performance measurement function (PMF) protocol	Ericsson / Ivo	discussion Rel-16	Noted Revision of C1-202021 Revision of C1-200313 Roozbeh, Thu, 19:36 Long explanation on security aspects, Lenovo and Motorola Mobility will stay neutral in the selection of the protocol Krisztian, Fri, 07:49 Does not agree Lazaros, Fri, 11:55 Comments Ivo, Fri, 16:46 Long explanation
C1-202650	Editorial fix in 9.11.4	Apple	CR 2169 24.501 Rel-16	Revision of C1-202431 Lena, Fri, 05:17 CR is fine, should be CAT F
C1-202679	Performance management function protocol	Ericsson / Ivo	pCR 24.193 Rel-16	Revision of C1-202621 Revision of C1-202019 Mariusz, tue, 18:08 Abbreviation to be sorted out Revision of C1-200314 Kristzian, Tue, 07:48 This is to confirm that Apple has no objection to proceed with C1-202019.
C1-202695	EPS interworking of MA PDU session of 5G-RG when N26 is supported	Ericsson / Ivo	CR 2029 24.501 Rel-16	Revision of C1-202031 Roozbeh, Thu, 20:08 Requests some changes Ivo, Mon, 11:16 Providing rev in the Inbox Roozbeh, Mon, 18:39 Fine with the rev
C1-202642	Clarification of SMF and UE azarosi in 5GS to EPS mobility without N26 interface	SHARP	pCR 24.193 Rel-16	Revision of C1-202372 Joy, Thu, 11:45 Some of new text is not needed, transfer procedure incorrect, rest ok Roozbeh, Thu, 21:42 Not sure that the CR is needed Yudai, Fri, 09:41 Provides a rev in response to Roozbeh Mikael, Fri, 16:44 Is the added text needed in 24.193? Roozbeh, Sat, 19:53 Rev is fine Yudai, Tue, 06:55 Provides rev Mikael, Tue, 13:38 works
C1-202701	Applicability of PS data off to MA PDU	OPPO / Rae	CR 2042 24.501 Rel-16	Revision of C1-202120 Partially overlaps with C1-202289 Joy, Thu, 11:44 Newly introduced Note is not sufficient Roozbeh, Thu, 20:30 Improve cover page, rewording needed for new text Atle, Thu, 22:27 New and existing text are repetititve, can this be combined? Mikael,Fri, 16:24 Same view as roozbeh, atle, sentences to be combined Rae, Mon, 05:37 All comments on board, rev in Inbox Atle, Mon, 08:39 Fine with the rev, not super happy with some words, can live with it Rae, Wed, 03:41 New rev, many things taken out Mikael, Wed, 08:33 good
C1-202661	Correction on EPS interworking	ZTE / Joy	pCR 24.193 Rel-16	Revision of C1-202143 Roozbhe, Thu, 20:38 Needs rewording Joy, Fri, 08:19 Explaining why this is needed Roozbeh, Fri, 18:25 Further commenting Joy, Sat, 09:15 Fine with Roozbeh proposal, rev in Inbox Roozbeh, Sat, 18:11 CR is fine
C1-202816	Handlings of MA PDU session when deregistration from an access	MediaTek Inc. / JJ	CR 2203 24.501 Rel-16	Revision of C1-202531 _________________________________________ Atle, Thu, 23:08 Asking for clarification JJ, Fri, 11:31 Answering to Atle, is this sufficient? Atle, Fri, 12:51 Fine with explanation, doc needs to be revised accordingly JJ, Mon, 11:19 Providing the rev Atle, Tue, 01:10 Fine with the rev
C1-202818	Considering allowed NSSAI when requesting MA PDU session upgrade	MediaTek Inc. / JJ	pCR 24.193 Rel-16	Revision of C1-202532 _________________________________________ Osama, Thu, 22:07 Update cover page, add a NOTE Atle, Thu, 23:05 Not convinced that this is correct JJ, Fri, 13:17 Providing rev Roozbeh, Sat, 20:12 Rev looks fine Atle, Mon, 08:42 Rev is fine
eNS	Peter – Main	CT aspects on enhancement of network slicing
C1-202114	Adding the referenced subclause 4.6.2.2 for the UE stored Pending NSSAI.	China Telecom Corporation Ltd.	CR 2041 24.501 Rel-16	Current Status merged into 2473 Amer, Fri, 20:17 New bullete needs revision, should have been made against 2113, no open comment against 2114 Fei, Thu, 11:01 Asks that this is revised into 2473 and its revisions Lin, Thu, agrees with Fei
C1-202123	Allowed NSSAI was formed from contents of the requested NSSAI and all default S-NSSAI(s) require network slice-specific authentication and authorisation	Samsung Electronics Polska	discussion	Noted EN#11 & Task #4 See also C1-202123, 2124,2243, 2252
C1-202124	All default S-NSSAI(s) require network slice-specific authentication and authorisation (solution 1)	Samsung Electronics Polska	CR 2045 24.501 Rel-16	Current Status Postponed EN#11 & Task #4 See also C1-202123, 2124,2243, 2252 Sunhee, Fri, 10:25 Conflicts with 2253, prefers to wati for conclusion in the SA2 discusion Yanchao, Fri, 16:41 prefer to use the Ericson’s solution in C1-202252 Kaj, Sun, 22:47 2252 is the way to go, depends a bit on SA2 Roozbeh, Mon, 19:19 Prefers 2252
C1-202134	Stopping of T3346 after receiving the NSSA Command message	BEIJING SAMSUNG TELECOM R&D	CR 2049 24.501 Rel-16
C1-202150	Inclusion of Rejected NSSAI in Registration reject with cause #62	Samsung/Anikethan	CR 2052 24.501 Rel-16	Current Status Postponed Fei, Fri, 04:57 Including rejected NSSAI is optional Ani, Sat, 22:11 Defending his CR Atle, Sun, 10:43 Wants to co-sign Kaj, Sun, 23:10 Seems the CR is not needed Ani, Mon, 06:15 Answering Fei, Kaj Fei, Tue, 08:44 We made decision this is optional Kaj, Tue, 08:47 Concerns Ane, Tue, 11:52 Rev Kaj, Tue, 12:18 Commenting it can be out of synch Ani, Tue, 12:34 Asking back
C1-202172	Discussion paper on the impact of non-standard S-NSSAI mapping to NSSAA and NSSAI storage	China Mobile	discussion 24.501 Rel-16	Noted Ani, Sat, 23.25 Acks the use case, number of comments Xu, Sun 17:45 Discussing Fei, Mon, 05:35 Use cases are valid, two approaches Ani, Tue, 04:34 Option-2 Xu, tue, 07:04 Asking whether to further study this and find a backward compatible solution Ani, Tue, 07:45 Will provide comments n the CR in 2173 soon Kaj, Tue, 08:02 Comments Fei, Tue, 08:47 only address the rejected NSSAI for the failed NSSAA at this emeeting Kaj, Tue, 09:37 More comments Ani, Wed, 04:30 Too many changes Xu, Wed, 17:29 Providing the rev
C1-202224	T3540 is not started if the Registration Accept includes a pending NSSAI	BEIJING SAMSUNG TELECOM R&D	CR 2075 24.501 Rel-16	Amer, Sun, 09:48 Q for clarification, seem to go against existing EN Mahmoud, Mon, 05:35 Long email Amer, Wed, 08:04 Some comments Mahmoud, Wed, 17:05 Answering Amer, Thu, 02:07 OK with the CR
C1-202241	Fixing typo related to eNS	BEIJING SAMSUNG TELECOM R&D	CR 2080 24.501 Rel-16
C1-202243	All default S-NSSAI(s) require network slice-specific authentication and authorisation (solution 2B)	Samsung Electronics Polska	CR 2081 24.501 Rel-16	Current Status Postponed EN#11 & Task #4 See also C1-202123, 2124,2243, 2252 Kaj, Sun, 22:47 2252 is the way to go, depends a bit on SA2 Roozbeh, Mon, 21:15 Do not agree
C1-202246	S-NSSAI in rejected NSSAI for the failed or revoked NSSAA not to be requested	Ericsson /kaj	CR 2083 24.501 Rel-16	Withdrawn
C1-202250	Request S-NSSAI pending the NW slice-specific authentication and authorization	Ericsson /kaj	CR 2004 24.501 Rel-16	Current Status Postponed Revision of C1-200724 Task#3, See also C1-202250, 2472, 2473 Yanchao, Thu, 12:54 Issue with change in 4.6.2.4, editorial in 5.5.3.1.2 Mahmoud, Thu, 22:36 Detailed comments, prefers C1-202473 from Huawei as baseline, both CRs could be merged Atle, Fri, 13:10 Fine in general, needs different approach Kaj, Fri, 16:28 Answering the comments Mahmoud, Fri, 17:33 Commenting Kaj, Mon, 09:39 Answering Atle Lin, Mon, 09:50 Could be merged with 2473, many comments Kaj, Mon, 12:07 Commenting, seems he is willing to merge Atle, Mon, 14:46 Answering Kaj, accepts to wait for other groups Atle, Tue, 02:39 Asking if this is going to be merged to 2473 Atle, Wed, 00:34 Not happy to link discussion to a SA2 CR whith unknown status, focus on exsiting requirements Lin, Wed, 04:27 Explaining to Kaj
C1-202252	S-NSSAIs always selected from allowed NSSAI by AMF	Ericsson /kaj	CR 2086 24.501 Rel-16	Current Status postponed EN#11 & Task #4 See also C1-202123, 2124,2243, 2252 Sunhee, Fri, 11:40 Conflicts with C1-202124, prefers to wait for SA2 Ricky, Fri, 13:52 Samsung cannot agree to CR C1-202252 Kaj, Mon, 09:51 I think we have to wait for the outcome from SA2 meeting before progressing Ricky, Mon, 14:03 agree that we have to wait until SA2 progresses this issue
C1-202330	Abnormal case about missing EAP result for NSSAA	China Mobile	CR 2109 24.501 Rel-16	Withdrawn Not available on time
C1-202332	Work Plan for eNS in CT1	ZTE	Work Plan Rel-16	Noted
C1-202340	Deleting Editors note regarding indefinite wait at the UE for NSSAA completion	ZTE	CR 1912 24.501 Rel-16	Postponed Request from author Revision of C1-201051 EN#1 & Task #2 Kundan, Tue, 16:05 Wants this to be postponed
C1-202345	Discussion on re-initiation of NSSAA	BEIJING SAMSUNG TELECOM R&D	discussion	Noted EN#10 & Task#1 See also C1-202170, 2345, 2351, 2352 Kaj, Wed, 00:06 Describing a third option Fei, Wed, 08:24 Option 3 seems to mean Do nothing in the spec Kaj, Wed, 08:53 Yes Mahmoud, Wed, 16:52 Do nothing not acceptable Kaj, Thu, 00:04 arguing
C1-202346	EPS selection when the UE is deregistered due to NSSAA failure	Samsung/Kundan	CR 1950 24.501 Rel-16	Current Status Postponed Revision of C1-200572 Yanchao, Thu, 13:37 Ok in principle, but more changes are needed Kundan, Thu, 14:37 Ok with Yanchao’s comments Fei, Fri, 08:28 as commented in the last meeting, the CR is not needed Roozbeh, Mon, 21:43 Same as Fei Kund, Tue, 09:27 Defending
C1-202351	Re-initiation of NSSAA (solution #1)	BEIJING SAMSUNG TELECOM R&D	CR 2124 24.501 Rel-16	EN#10 & Task#1 See also C1-202170, 2345, 2351, 2352. Mahmoud, Mon, 05:41 This is more efficient than #2 Kaj, Mon, 07:38 Current solution preferred, CR not needed Vishnu, Mon, 10:22 support Solution #1. (i.e CR C1-202351) Roozbeh, Man, 20:11 sending the pending NSSAI to the UE during the reNSSAA … not needed Mahmoud, Mon, 20:23 Not clear with Roozbeh’s statement, seems not aligned with his previous input to the discussion Sung, Tue, 05:58 Supports, but needs some rewording Sunhee, Tue, 09:53 Comments Roozbeh, Tue, 16:45 Asking for clarification from Mahmoud Mahmoud, Tue, 17:43 Answering Roozbeh Roozbeh, Tue, 18:26 Concept is fine, however, can it be “may”
C1-202352	Re-initiation of NSSAA (solution #2)	BEIJING SAMSUNG TELECOM R&D	CR 2125 24.501 Rel-16	Current Status Postponed EN#10 & Task#1 See also C1-202170, 2345, 2351, 2352 Amer, Sun, 18:39 prefer this CR versus C1-202351 Kaj, Mon, 07:38 Current solution preferred, CR not needed Roozbeh, Mon, 20:23 Not needed Mahmound, Mon, 20:46 Answering to Roozbehm this is about new requests Mahmoud, Mon, 20:47 Anserign Kaj, Tsuyoshi, Tue, 01:42 Commenting Kaj, case is to be considered
C1-202383	Clarification to NSSAA procedure	Samsung/Kundan	CR 2143 24.501 Rel-16	Current Status Postponed Kaj, Fri, 10:41 don’t see that the proposed should be in the NAS specification. Kundan, Fri, 12:08 Sees no issue with capturing this in CT1 spec Kaj, Fri, 16:47 SA2 needs to do this first Kundan, Mon, 11:45 Generic sub-clause 4.6.2.4 fits Kaj, Mon, 14:20 This is a stage-2 group decision Tsuyoshi, Tue, 01:59 SA2 first
C1-202430	Release PDU sessions due to revocation from AAA server , re-auth failure	LG Electronics France	CR 2168 24.501 Rel-16	Current Status Postponed Yanchao, Thu, 13:42 PDU session release via explicit NAS signaling is not needed for this case Fei, Fri, 08:30 Same as yanchao Sunhee, Fri, 09:36 Explains that this is inline with SA2 Kaj, Fri, 11:22 not convinced that a new 5GSM cause value is needed Ricky, Fri, 18:12 Same view as Yanchao and Fei Fei, Sat, 07:59 Releasing without NAS sig is inline with stage-2 Sunhee, 12:11 Thinks that explicit NAS sig is needed, this goes to Ricky and Fei Sunhee, Sun, 13:13 NAS sig is needed, to Kaj Amer, Sun, 19:13 Wrong wording Roozbeh, Mon, 01:07 CR is not needed Lin, Mon, 09:08 same view as Yanchao, Fei and Ricky. Sunhee, Mon ,09:40 Taking Amer comment on board, rev in Inbox Sunhee, Mon, 12:05 will not insist my CR.
C1-202454	Updating NSSAI status in AMF	NEC	CR 1990 24.501 Rel-16	Postponed Requested by the author Revision of C1-200691 Overlaps with C1-202111 Kaj, Fri, 10:57 don’t see that NAS spec is the correct document to capture this Lin, Mon, 08:54 Change is not aligned with the cover page Tsuyoshi, Tue, 03:41 Want to see outcome of CT4 first before making any progress Lin, Tue, 09:23 Ct1 and ct4 can do this separately Kaj, Tue, 11:15 Let’s wait for CT4 Tsuyoshi, wed, 07:06 No need to wait for CT4, 2 questions Lin, Wed ,10:06 Answering tsuysohsi Tsuyoshi Thu, 03:54 Some questins from Lin Lin, Thu, 10:55 What is the purpose of the CR?ß
C1-202472	Discussion on including pending S-NSSAI(s) in the requested NSSAI	Huawei, HiSilicon/Lin	discussion Rel-16	Noted Task#3 See also C1-202250, 2472, 2473
C1-202475	Term on rejected NSSAI for the failed or revoked NSSAA	Huawei, HiSilicon/Lin	CR 2181 24.501 Rel-16
C1-202543	Clarification to NW slice-specific re-authentication and re-authorization	Ericsson /kaj	CR 2206 24.501 Rel-16	Postponed Lin, Mon, 08:32 CR is not needed, covered in the spec Kaj, mon, 10:33 Not convinced by the arguments Roozbeh, Mon,22:16 Change does not make sense Tsuyoshi, Tue, 01:26 Why is AMF description needed for this specific case Lin, Tue, 09:41 Does not agree on all aspects Kaj, Tue, 11:32 Ack Lin paritally Kaj Tue, 11:58 Answering Tsuyoshi, Wed, 06:36 Still has questions Lin, Wed, 10:24 Comments Kaj, Wed, 11:05 Unclear comments Tsuyoshi, Thu, 05:44 Can not agree Kaj, Thu, 10:00 Does not agree Tsuyoshi, Thu, 10:46 Not agreeing
C1-202587	Update Handing EAP Result for NSSAA	China Mobile	CR 2212 24.501 Rel-16	Withdrawn Not available on time
C1-202589	eNS – way forward for indefinite wait for NSSAA	InterDigital / Atle	Discussion	Noted EN#1 & Task #2 Atle, Tue, 13:04 This is just to secure alignment, paper will be noted
C1-202603	Updating descriptions of NS for NSSAA	China Mobile	CR 2058 24.501 Rel-16	Revision of C1-202171 Roozbeh, thu, 23:41 I cannot agree Ricky, Thu, 14:51 do not believe that this CR is required Xu, Fri, 07:34 Explains why it is needed, also announces a revision Suhnee, Fri, 11:50 Some rewording Ricky, Fri, 13:17 respectively I disagree with Xu Xu, Fri, 16:14 Acks Sunhee comments Xu, Fri, 16:01 Acks ricky, new reve Ricky, Fri 17:31 Fine, more changes needed Xu, Sun, 10:06 Checking with Roozbeh there might be clashes with 2282, acks Ricky Kaj, Sun, 11:26 Incomplete CR, does not see this is needed Xu, Sun, 12:37 Hinting at rev, explaining to Kaj Roozeh, Mon, 16:50 Further comments Roozbeh, Mon, 22:46 Further comments Kaj, Tue, 09:19 comenting Roozbeh, Tue, 23:15 Not clear what he proposes Xu, Wed ,13:16 Commenting Roozbeh, Wed, 18:53 New update Ricky, Wed, 19:59 Not agreeing with roozbeh Roozbeh, Wed, 21:03 answerign
C1-202627	Updating Rejeted NSSAI IE for failed NSSAA case in roaming scenerios	China Mobile	CR 2108 24.501 Rel-16	Revision of C1-202329 Kaj, thu, 11:54 Cover page, Note is needed Kaj, Fr, 09:53 Fine with the CR Amer, Sun, 18:06 New text to go to procedural subclauses Xu, Tue, 05:19 Provides a rev
C1-202629	Missing condition for inclusion of “NSSAA to be performed” indicatory	Samsung Electronics Polska	CR 2043 24.501 Rel-16	Revision of C1-202121 Kaj, Sun ,10:56 Comments on bullet a) Ricky, Mon, 19:01 Provides rev Kaj, Tue, 08:22 Commenting
C1-202678	Clarify that NSSAA can occur during periodic registration or mobility updating for NB-N1 mode UEs	BEIJING SAMSUNG TELECOM R&D	CR 2079 24.501 Rel-16	Revision of C1-202234 Kaj, Fri, 14:18 CR is not needed Mahmoud, Fri, 16:33 Explaining the case Kaj, Tue, 10:18 Further issues Mahmoud, Tue, 20:23 Rev Kaj, Wed, 09:15 Can this really happen?? Mahmoud, Wed, 15:36 Answering Kaj, Thu, 00:41 Use case not valid Mahmoud, Thu, 01:18 Not agreeing Kaj, Thu, 01:38 Use case not valid Mahmoud, Thu, 01:59 “Kaj is not answering the questin” Fei, Thu, 04.22 Confirming the use case Mahmoud, Thu,06:05 “Baseline of the spec support his view” Kaj, Thu, 10:15 Fine with Fei, The issue I have is the understanding of what such by AMF changed allowed NSSAI may inlcude. And that I have explained below and with that I don’t see the changes proposed are applicable based on that a S-NSSAI subject to re-NSSAA will still be in allowed NSSAAI and not be inlcuded in pending NSSAI. Mahmoud, Thu, 10:49 Does not agree with Kaj
C1-202702	The handling of N1 SM information during re-authentication and re-authorization for an S-NSSAI	China Mobile	CR 2057 24.501 Rel-16	Revision of C1-202170 Sung, Fri, 06:25 OBJECTS EN#10 & Task#1 See also C1-202170, 2345, 2351, 2352. Kaj, Sun, 11:16 CR should not be agreed Amer, Sun, 18:35 Q for clarification Roozbeh, Mon, 20:46 comments Xu, Tue, 10:10 Does not agree with Kaj Kaj, Tue, 11:38 Commenting Xu, Tue, 12:41 Answering Roozbeh
C1-202669	NSSAA for UEs that roam across 5GS VPLMNs	BEIJING SAMSUNG TELECOM R&D	CR 2090 24.501 Rel-16	Postponed Revision of C1-202259 Amer, OK Kaj, Thu, 11:41 NOT OK with the Cr Mahmoud, Thu, 12:02 Not happy with this late comment, seems not correct to him Kaj, Thu, 14:49 Can accept this CR, may come back Karj, Friday, 11:24 Requests this to be postponed Amer, Sun, 17:48 Some modification to the text Mahmoud, Mon, 05.56 Asking for clarification from Amer Kaj, Mon, 07:50 Change in 5.4.4.3 is and 5.5.1.3.4 not applicable. Mahmoud, Mon, 15:29 Answering Mahmour, Tue, 19:32 Providing rev Amer, Wed, 08:18 New proposal Mahmoud, Wed, 15:50 New proposal Amer, Thu, 02:20 Fine with latest draft
C1-202827	Exception to initiate the service request procedure during NSSAA when there is no allowed NSSAI	BEIJING SAMSUNG TELECOM R&D	CR 2089 24.501 Rel-16	Revision of C1-202257 Fei, Fri, 05:20 Update on condition needed for SMS Mahmoud, Fri, 05:46 Clarifies for Fei Fei, Fri, 08:46 Very confused by the condition Mahmound, Fri, 20:30 Providing a rev, is that ok for Fei? Amer, Sun 09:44 Q for clarification Fei, Tue 08:52 Fine Kaj, Tue, 10:40 SMS in ServiceRequest violates stage-2 Fei, Tue, 11:54 Hinting at decision from last meeting Kaj, Tue, 14:17 Last time we sent an LS to SA2, should we now ask for their blessing Mahmoud, Tue, 15:16 Is ok to send LS, but wants to know what is agreeabel Mahmoud, Tue, 17:31 Answering Amer Amer, Wed, 08:08 fine
C1-202833	NSSAA in an SNPN	Nokia, Nokia Shanghai Bell	CR 2135 24.501 Rel-16	Revision of C1-202374 Yanchao, Thu, 13:37 usage of ‘RSNPN’ and ’SNPN’ should be aligned Lin, Mon, 08:51 With comment form Yanchao, could live with the CR, also not big issue to be solved
C1-202784	Missing condition at registration reject due to no available slices	Ericsson /kaj	CR 2091 24.501 Rel-16	Current Status Postponed Revision of C1-202261 Lin, Thu, 09:04 Kaj, Agrees with Lin, new rev will come Ricky, Thu, 12:05 Cover sheet, and wording improvement Lin, Mon 07:28 Additional typo Kaj, Mon ,10:18 Fine Kaj, Wed, 11.33 New rev Ricky, Wed, 13:00 Some minor comments
C1-202813	S-NSSAI in rejected NSSAI for the failed or revoked NSSAA not to be requested	Ericsson /kaj	CR 1734 24.501 Rel-16	Revision of C1-202247 Revision of C1-198417 Ricky, Thu, 13:46 Agrees with the concept, some changes are missing in #62 in some subclauses, cover sheet needs improvement, wants to co-sign Roozbeh, 20:34 Is this really needed? Kaj, Wed, 15:46 New rev Roozbeh is fine
C1-202825	Alignment of UE actions of rejected NSSAI for the failed or revoked NSSAA	Ericsson /kaj	CR 2084 24.501 Rel-16	Revision of C1-202248 Lin, FINE Lin, Mon, 10:02 Improves wording Roozbeh, Mon, 21:20 Wording changes Kaj, Wed, 16:45 Acks Roozbeh
C1-202872	Update description on whether UE indicate supporting NSSAA	China Telecom Corporation Ltd.	CR 2039 24.501 Rel-16	Revision of C1-202792 2792 marked withdrawn, so it is a rev of 2112 _________________________________________ Revision of C1-202112 Fei, Wed, 12:13 Editorials Ricky, Wed, 12:53 Coversheet, cat f, consequences if not approved Ricky, Thu, 18:49 Long explanation, CR is not neccssary Kaj, Fri, 11:00 CR is not needed Amer, Fri, 20:11 Untick ME, tick CN Shuzehn, thu, 08:24 New rev
C1-202778	Pending NSSAI update for the configured NSSAI in the CUC message	China Telecom Corporation Ltd.	CR 2040 24.501 Rel-16	Revision of C1-202113 _________________________________________ Shuzhen, Sun, 03:00 Provides a rev, highlighting that Amer comment on 2114 is to be made again 2113 Amer, Wed, 07:47 Fine with the rev
C1-202628	Updating requirements of NSSAA for roaming scenerios	China Mobile	CR 2059 24.501 Rel-16	Revision of C1-202173 _________________________________________ Ani, thu, 05:56 Commenting, same as in the disc paper, just some parts are needed Shuzhen, thu, 09:51 Agreeing with arni, new rev New rev Fei, minor comment, wants to co-sig Ani FINE
C1-202776	Clarification on the rejected S-NSSAI included in requested NSSAI in registration procedure.	China Telecom Corporation Ltd.	CR 2053 24.501 Rel-16	Revision of C1-202157 _____________________ Ricky, Thu, 12.26 Concept not correct, prefers the proposal as in C1-202247 Shuzhen, Sun, 03:48 Discussing with Ricky Kaj, Sun, 11:09 CR not needed Ricky, Sun, 18:22 With rev of 2247, this CR is not needed Shuzhen, Mon, 08:44 Agrees C1-202157 is not needed Lin, Mon, 08:43 Keep on discussing, proposing a NOTE Ricky, Mon, 1228 updating the Note Lin, Mon, 14:56 Leaving it to Shuzhen what to do Ricky, Mon, 15:20 Leaving it to Shuzehn Kaj, ute, 08:58 Comments/thoughts
C1-202774	Clarification S-NSSAI status in AMF for NSSAA	China Telecom Corporation Ltd.	CR 2038 24.501 Rel-16	Revision of C1-202111 _________________________________________ Overlaps with C1-202454 Lin, Mon, 08:57 CR is fine, some changes, wants to co-sign Ricky, Mon, 13:09 Supports Lin Lin, Mon, 16:28 Provides proposal for wording Ricky, Mon, 16:49 Futher refining Lin, Mon, 16:54 Likes the text from Ricky Tsuyoshi, Mon, 16:54 Hints at some CT4 work Kaj, Mon, 23:26 Clarifying that Tsuyohsi’s comment does not require CT1 work Tsuyoshi, Tue, 00:56 Would be ok to have it in NAS spec, but needs to be aligned between WGs Atle, Tue 03:04 Some wording discussion Fei, Tue, 03:18 To Tsyuoshi, just use reference to CT4 spec Shuzehn, Tue, 07:26 Rev Kaj, Tue, 08:37 Is this the latest rev Shezehn, Tue, 09:51 Yes this is latest rever Ricky, Tue, 13:31 Some changes needed Lin, Wed, 03:41 Some improvements Shuzehn, Wed, 05:48 rev
C1-202608	AMF triggers PDU session release	Samsung Electronics Polska	CR 2044 24.501 Rel-16	Revision of C1-202122 _________________________________________ Kaj, Fri, 11:34 Fine with the CR needs rewording Sunhee, Fri, 11:43 Fine in general, some rewording Ricky, Fri, 12:51 Provides rev Yanchao, Fri, 16:36 CT1 has agreed that the local release of PDU session is enough in last meeting, no need to initiate the PDU session release procedure. Ricky, Fri, 17:14 Agrees with Yanchao, new rev Sunhee, Mon, 10:20 Follows majority Kaj, Tue, 08:25 Explicit NAS sig applies Ricyk, Tue, 12:16 Not agreeing with kaj Kaj, Tue, 12:27 Not agreeing with ricky Ricky, Tue, 17:28 Different view, asking for other companies position Roozbeh, Tue, 23:06 Not clear Ricky, Wed, 11:47 Explaining to Roozbeh Roozbeh, Wed ,16:14 No issue with this cr
C1-202871	Inclusion of pending S-NSSAI(s) in the requested NSSAI	Huawei, HiSilicon, China Telecom/Lin	CR 2180 24.501 Rel-16	Revision of C1-202800 Revision of C1-202473 _________________________________________ Task#3, See also C1-202250, 2472, 2473 Mahmoud, Fri, 05:44 generally fine with the paper however it still requires some improvements, wants co-signing Lin, Fri, 12:49 Provides a rev Mahmoud, Fri, 17:16 Still has comments Lin, Sat, 03:59 Answering Mahmoud Fei, Sat 04:38 Providing his view , Lin, Sat, 08:17 Either “add-on” or “replace”, no mixure Mahmoud, Sat, 21:54 Agrees with Lin, Atle, Sun, 11:05 Ok with some changes, objecting to some others Lin, Mon, 04:07 Not agreeing with Atle Fei, Mon, 04:29 Agrees with Lin Kaj, Mon, 07.33 1 ok, 2 partly, 3 comments Lin, Mon, 09:43 Rev2, to Mahmound Fei, Mon, 09:42 Access agnostic pending NSSAI, need to be areful Lin, Mon, 09:58 Providing rev2, asking Kaj, whether 2250 can be merged into this Tsuyoshi, Mon, 11:19 Question Atle, Mon, 15:16 Commenting Mahmoud, Mon, 15:43 Answering Atle Tsuyoshi, Mon, 16:03 Q for clarification Mahoumd, Mon, 16:36 answering Tsuyoshi, Mon, 16:46 Fine with Mahmoud reply Atle, Tue, 02:39 Not agreeing with Mahmoud Mahmoud, Tue, 05:17 ongoing disc with Atle Sung, Tue, 0813 Comments on rev2 Lin, Tue, 10:45 commenting Lin, Tue, 10:59 Commenting Kaj, Tue, 11:06 Concern, hinting at S2-2002850 Lin, Tue, 11:18 Providing a rev Fei, Tue, 11:40 comments Atel, Tue, 11:55 Comments Atel, Tue, 12:21 Commenting Atle, Wed, 00:51 this point in the release, I am not willing to agree stage-3 changes that break stage-2. Wait for SA2 Kaj, Wed, 09:18 Ok with Lins latest explanation, merging with might be possible Lin, Thu, 04:52 To atle, has taken all Task#3 things out, is it fine? Lin, Thu, 08:53 New rev Mahmoud, Thu, 09:06 OK Atle, Thu, 10:17 Comments Lin, new Rev Atle FINE with REV3
C1-202881	Handling of Pending S-NSSAI	Samsung/Kundan	CR 2144 24.501 Rel-16	Revision of C1-202385 ------------------------------------------------ Frederic, Thu, 09:08 Clauses affected missing Vishnu, Sun, 15:15 Fine, some editorials Vishnu, Sun, 16:17 Fine Kundan, Thu, 07:29 New rev Vishnu, thu, 08:19 Almost ok KundanThu, 08:45 rev
C1-202918	Network-requested PDU session release due to failed or revoked NSSAA	Motorola Mobility, Lenovo	CR 2099 24.501 Rel-16	Revision of C1-202618 Xu, Fri, 12:03 Object the CR _________________________________________ Revision of C1-202282 Shuzhen, Thu, 15:27 Does not agree with current wording _________________________________________ Yanchao, Thu, 13:25 Changes in 5.4.4.3 are not needed Ricky, Thu, 16:07 Additional changes to subclause 4.6.2.4 are needed Sunhee, Fri, 11:55 Similar to 2430, there is an additional cause code needed Roozbeh, Sun, 23.25 Discussing and providing a rev, is it OK? Roozbeh, Sun, 23:57 Acks that this is similar to 2430, 2282 attempts to adjust existing text Amer, Mon, 05:04 Comments Lin, Mon, 09:06 last change given in sub 5.4.4.3 is not needed Ricky, Mon, 11:58 Fine with theCR, but interaction with 2603 is to be solved Roozbeh, Mon, 23:21 Provides a rev Lin, Tue, 04:28 Fine with the rev Xu, Wed, 11:43 Number of comments Roozbeh, Wed, 21:03 Rev Xu, Thu, 03:49 Rewording Roozbeh, Thu, 06:43 New rev
Vertical_LAN	Peter – Main	CT aspects of 5GS enhanced support of vertical and LAN services
Stand-alone NPN
C1-202350	TSN working domain terminology	Huawei, HiSilicon / Cristina	CR 2123 24.501 Rel-16	Postponed Postponed Lena, Thu, 17:59 Some rewording needed, overlaps with Nokia’s C1-202435 Cristina, Fri, 05:32 Will provide revision Sung, Mon, 03:48 Changes in subclause 4.15.2.2 are incorrect Cristina, Mon, 05.07 Explaining Sung, Mon, 05:18 Does not agree Sung, Mon, 05:54 disagree with changing subclause 4.15.2.2 Sung, Mon, 14:57 Some clarification in SA2 is needed Lena, Tue, 05:37 ok to not have to changes in subclause 4.15.2.2 Cristina, Tue, 05:47 Wants to postponed and wait for SA2 Sung, Tue, 07:28 OK with postponing both C1-202350 and C1-202435, wants to go on with 2433
C1-202353	TSN working domain terminology	Huawei, HiSilicon / Cristina	CR 0001 24.535 Rel-16	Merged into C1-202433 and its revisions Based on request from author Ivo, Thu, 13:39 overlaps with C1-202433 Lena, Thus, 18:01 Some rewording overlaps with C1-202433 Sung, Mon, 03:23 Prefers 2433 Cristina, Tue, 05:47 Wants to postponed and wait for SA2 Sung, OK with postponing both C1-202350 and C1-202435, wants to go on with 2433 Sung, Tue, 15:03 2353 to be merged into 2433
C1-202354	Trigger for Initial Registration procedure	Samsung/Kundan	CR 2126 24.501 Rel-16	Current Status Postponed Ivo, Thu, 12:54 Change seems unnecessary Vishnu, Thu, 17:09 Can be useful, needs fixes Lena, Thu, 23:07 Fine with the CR, editorial Yanchao, Fri, 06:28 Changes seems unnecessary Marko, Fri, 15:19 CR is not needed Sung, Mon, 03:27 Support Ivo, Yanchao, Fei, and Marko, not needed
C1-202365	DISC Configuring UE to enable manual CAG selection procedure	Samsung	discussion Rel-16	Withdrawn Not available on time
C1-202395	Work plan for Vertical_LAN	Nokia, Nokia Shanghai Bell	discussion Rel-16	Noted
C1-202020	Configured N3IWF identity for SNPN access via PLMN	Ericsson / Ivo	CR 0507 23.122 Rel-16	Withdrawn Not available on time
C1-202087	Correction in UE azarosi 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	Revision of C1-200970 Ivo, Thu, 12:57 Enables an attacker by sending just *one* fake reject message to temporarily prevent the UE from getting any service using the subscription information indicated in an entry of “list of subscriber data Sung, Sun, 22:59 Requests this to be put on ConfCall Lin, Mon, 10:53 Supports the CR Sung, Wed, 01:04 Additional explanation Ivo, Wed, 19:20 Wants a statement in the report, Ericsson sees a danger in C1-202086 (and its revision) enabling an attacker to temporarily prevent the UE from getting services from the selected SNPN by attacker sending a single fake reject message. Then he can accept the CR
C1-202131	Correction of the UE requirements for expiry of T3247	Apple	CR 2048 24.501 Rel-16	Withdrawn Request from author Sung, Mon, 05:50 CR’s scope is a part of that of C1-202402.
C1-202193	update of the counter for SNPN	vivo	CR 2064 24.501 Rel-16
C1-202194	temporarily and permanently forbidden SNPNs lists per access type	vivo	CR 2065 24.501 Rel-16
C1-202197	5GMM cause value #74 in an SNPN with a globally-unique SNPN identity	vivo	CR 2068 24.501 Rel-16
C1-202366	Condition for access to SNPN	SHARP	CR 2129 24.501 Rel-16	Merged in to C1-202399 and or 2469 Based on request form author Frederic, Thu, 09:08 Clauses affected missing Lena, Thu, 23:39 Rewording needed, overlaps with Intel’s C1-202399 and Huawei’s C1-202469
C1-202389	Clarification to SNPN to SNPN selection procedure	Samsung/Kundan	CR 2146 24.501 Rel-16	Withdrawn Not available on time
C1-202393	figures 1, 2a, 2b, 3 and table 2 not applicable in SNPN	Intel /Thomas	CR 0524 23.122 Rel-16
C1-202620	Subscription update in case of SNPN	Intel /Thomas	CR 2147 24.501 Rel-16	Revision of C1-202396 Merged into C1-202412 and its revisions Ivo, Thu, 13:00 Unclear wording Sung, Sun, 23:35 scope of the CR is a subset of C1-202412 Thomas, Mon, 14:9 2396 has changes which are not covered in C1-202412 Sung, Mon, 17:50 Agrees to Thomas that there is need for aligning Thomas, Tue, 21:23 Offers that this is merged into revision of 2412
C1-202406	Handling of a UE not allowed to access SNPN services via a PLMN by subscription with 5GMM cause value #72	Nokia, Nokia Shanghai Bell	CR 2151 24.501 Rel-16
C1-202411	5GMM CC in an SNPN	Nokia, Nokia Shanghai Bell	CR 2155 24.501 Rel-16	Not Pursued Requested by author Lin, Wed, 09:50 Not needed
C1-202428	correction to network selection in case of multiple subscribed SNPNs	Intel /Thomas	CR 2167 24.501 Rel-16	Withdrawn
C1-202506	5GS forbidden tracking areas for roaming for SNPN	MediaTek Inc.	CR 2188 24.501 Rel-16	Postponed Ivo, Thu, 13:05 need to keep “for the current SNPN” Lena, Fri, 00:02 No need for two lists
C1-202522	Correct “theregistration”	MediaTek Inc.	CR 2196 24.501 Rel-16
C1-202777	correction to network selection in case of multiple subscribed SNPNs	Intel /Thomas	CR 0528 23.122 Rel-16	Revision of C1-202432 Ivo, Thu, 13:05 CR seems not needed Thomas, Thu, 14:50 Explaining his CR Lena, Thu, 23:46 New NOTE not aligned with stage-2, current text seem sufficient. Provides rewording in case something is done in 23.122 Ivo, Fri, 13:15 Still has problems Thomas, Fri, 14:51 Explaining to Ivo Vishnu, Mon, 10:18 New NOTE not needed Thomas, Mon, 16:16 Providing a draft Ivo, Mon, 21:24 More changes Lin, Tue, 09:14 Fine Thomas, Tue, 10:10 Updated rev Ivo, Tue, 13:40 Wants to co-sign Lena, Thu, 02:41 fined
C1-202606	non-3GPP access not supported in SNPN	Intel /Thomas	CR 2148 24.501 Rel-16	Merged into C1-202469 Revision of C1-202399 Ivo, Thu, 13:00 Editorials Lena, Thu, 23:29 Needs rewording, CR overlaps with SHARP’s C1-202366 and Huawei’s C1-202469. Yudai, Fri, 07:39 Would like to merge his CR in 2366 into the Intel CR Thomas, Fri, 10:26 Will update according to Lena, fine to merge with the sharp CR – draft in the INBOX Ivo, Fri, 11:58 Not clear Sung, Mon, 00:20 Prefers C1-202469 Lin, Mon, 10:13 Still things unclear, 2469 would solve it Thomas, Mon, 15:42 Some clarification Ivo, Mon, 20:52 Further comments Lin, Tue, 05:38 Wording needs to improve Thomas, Wed, 10:40 New rev Thomas, Wed, 10:54 Wants to merge this into 2469
C1-202710	5G GUTI of SNPN	vivo	CR 2067 24.501 Rel-16	Revision of C1-202196 Lin, Mon, 11:04 CR is fine, more text needed Yanchao, Mon, 14:57 Providing rev Lin, Mon, 16:34 Fine
C1-202841	Configured HRNN for SNPN selection	Ericsson / Ivo	CR 0505 23.122 Rel-16	Merged into C1-202855 Revision of C1-202013 Lena, Thu, 23:33 Not inline with SA2, also the EN hinting at open aspects in RAN2 not correct Ivo, Fri, 10:32 This is not ruled out in SA2, happy to address the En, has a revision Vishnu, Fri, 14:58 We don’t support this CR as this is against the current SA2 requirement Chen, Fri, 16:46 At very least has a dependency ot SA2 CR Sung, mon, 01:51 We would like to postpone both C1-202013 and C1-202407, as there are papers to SA2 Ivo, Mon, 09:07 Provides a rev, with a dependency to SA2 CR Sung, Mon, 17:36 Revising Ivo proposal Ivo, Mon, 20:27 Split from Sung confusing, wants complete solution in this CR Sung, Mon, 20:38 Wants to keep the not sa2 dependant parts in a separater CR Ivo, Mon, 22:30 New rev Vishnu, Tue, 23:14 Prefers Sug CR, Ivo, Wed, 10:38 Some condition then can merge this to Sung’s Cr Lena FINE
C1-202852	MICO in an SNPN	Nokia, Nokia Shanghai Bell	CR 2154 24.501 Rel-16	Revision of C1-202410 Has to be shifted to 5Gprotoc16 Lin can this be shifted into the cleanup CR Lin, Wed, 09:50 Not needed Sung, Thu, 01:12 C1-202410 became a Cat. D CR on 5GProtoc16
C1-202853	NB-IoT not applicable for SNPN	Nokia, Nokia Shanghai Bell	CR 2149 24.501 Rel-16	Revision of C1-202401 Lin, Wed, 01:38 Fine, sent from Sung Lin, Mon, 11:13 CR is fine, some rewording Sung, Mon, 17:46 Rev Lin, Tue, 05:39 Fine
C1-202854	UE in the 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE substate operating in SNPN access mode	Nokia, Nokia Shanghai Bell	CR 2157 24.501 Rel-16	Revision of C1-202413 Ivo, Thu, 13:04 Not clear why bullet d) is changed Sung, Mon, 02:25 Does not understand Ivo’s comment Lin, Mon, 11:15 CR is fine, come typo Ivo, Mon, 14:44 Explaiing Sung, Mon, 18:10 Agrees and provides a rev Ivo, Mon, 21.08 Fine, wants to co-sign Lin, Tue, 06:18 Rev is fine
C1-202855	Human readable network name for SNPN	Nokia, Nokia Shanghai Bell	CR 0527 23.122 Rel-16	Revision of C1-202407 Ivo, Thu, 13:01 given that roaming is not specified, HRNN can be configured in the UE without loosing any functionality and the precious broadcast resources can be saved. This needs to be enabled too. See C1-202013 Sung, mon, 01:51 We would like to postpone both C1-202013 and C1-202407, as there are papers to SA2 Sung, Mon, 17:37 New rev Ivo, Tue, 22:36 Comments on the rev Ivo, Wed, 10:38 Some condition then can merge 2013 into this Cr Sung, Thu, 01:57 All comments on board Ivo OK
C1-202856	Routing indicator update in an SNPN	Nokia, Nokia Shanghai Bell	CR 2158 24.501 Rel-16	Revision of C1-202414 Ivo, Thu, 13:04 Why is the feature optional Sung, Mon, 02:30 Provides a rev Ivo, Mon, 21:12 Commenting Sung, Wed, 13:49 New rev Ivo, fine, cosign
C1-202859	Management of forbidden SNPNs list upon receipt of a non-integrity protected reject message	Nokia, Nokia Shanghai Bell	CR 0511 23.122 Rel-16	Revision of C1-202086 Ivo, Thu, 12:57 enables an attacker by sending just *one* fake reject message to temporarily prevent the UE from getting any service using the subscription information indicated in an entry of “list of subscriber data Osama, Thu, 17:58 Can be done, but changes are not enough Sung, Sun, 23:15 Discussing Osama, Mon, 00:34 long email Sung, Mon, 04:29 Providing a rev Lin, Mon, 10:46 Comments on the rev Osama, Mon, 16:30 Comments on the rev Sung, Mon, 18:25 New rev Osama, Mon, 20:40 Fine with the rev Lin, Mon, 03:30 Fine with the rev Ivo, Wed, 19:20 Wants a statement in the report, Ericsson sees a danger in C1-202086 (and its revision) enabling an attacker to temporarily prevent the UE from getting services from the selected SNPN by attacker sending a single fake reject message. Then he can accept the CR
C1-202869	5GMM cause value #13 not supporting roaming for SNPN	vivo	CR 2069 24.501 Rel-16	Revision of C1-202712 _________________________________________ Revision of C1-202198 Ivo, Thu, 12:59 - not aligned with 23.122 subclause 4.9.3.0 which expects usage of #13 in SNPN - we do not object the change but would like to agree both CRs at the same time Sung, Sun, 23:19 Now I am against erasing all the text regarding #13/SNPN Yanchao, Mon, 05:37 Modifies the CR Lin, Mon, 11:07 Seem fine with the revision Sung, Mon, 17:38 Fine with the rev Ivo, Mon, 20:45 Some rewording Yanchao, Tue 10:07 Provides rev Ivo, Tue, 13:36 More is needed Lin, Wed, 04:02 Comments Yanchao, Wed, 12:27 New rev Sung, Wed, 13:52 Fine Ivo, wed, 14:20 Ok Lin FINE
C1-202895	storage of counters for UE in SNPN	vivo	CR 2066 24.501 Rel-16	Revision of C1-202711 Revision of C1-202195 _________________________________________ Lena, Tue, 03:18 Not needed to list DoS counters in Annex C Yanchao, Tue, 09:03 Acks, provides rev Lena, Thu, 02:54 Some changes
C1-202896	Correction of the handling of timer TG for SNPNs	Apple	CR 0514 23.122 Rel-16	Current Status Postponed Revision of C1-202130 Lin, Thu, 14:32 Does not agree with new term “SNPN-specific N1 mode attempt counters” _________________________________________
C1-202609	Definition of registered SNPN	Intel /Thomas	CR 2060 24.501 Rel-16	Revision of C1-202174 _________________________________________ Lena, Thu, 23:35 cannot agree to have “via a PLMN non-3GPP access” in the definition, provides rewording Thomas, Fri, 18:37 Providing a rev Sung, Mon, 03:54 Using a ref to 23.122 Lin, Mon, 11:01 Same as Sung Thomas, Tue, 12:06 Does not agree Lin, Wed, 03:53 Need changes Thomas, Wed, 11:47 Defending Sung, Wed, 13:44 Seems fine Thomas, Wed, 19:21 New rev Sung, Thu, 02:34 Fine Line, THi, 0559 Fine, minor editorial
C1-202799	Non-3GPP access for PLMN and SNPN	Huawei, HiSilicon/Lin	CR 2177 24.501 Rel-16	Revision of C1-202469 _________________________________________ Ivo, Thu, 13:05 Prefer C1-202399 Lena, Thu, 25:59 Not based on latest version of the spec Lin, Fri, 11:20 Provides rev, wants to check with Thomas whether they can merge Ivo, Fri, 12:07 Comments Lin, Sat, 07:28 Provides a rev Ivo, Mon, 21:28 Still not convinced Lin, Tue, 10:31 New rev Ivo, Tue, 13:44 Nearly ok, some more Lin, Wed, 10:38 New rev Lena, Wed, 02:01 Rewording needed Lin, Thu, 04:14 Rev Lena ok with latest rev
C1-202922	Introduction of SNPN-specific N1 mode attempt counters	Nokia, Nokia Shanghai Bell	CR 2011 24.501 Rel-16	Current Status Postponed Revision of C1-202402 Lin, can not accept _________________________ ________________ Revision of C1-201032 Lin, Mon, 11:00 Coments Sung, mon, 15:32 Does not agree with Lin Lin, Tue, 06:04 Defends his position Sung, Tue, 06:36 Why to have same counter for different behaviour Lin, Wed, 09:10 Commenting Sung, Wed, 13:40 Commenting Robert, Wed, 17:01 Commenting, both approaches would work, Osama, Thu, 02:54 Some input Sung, Thu, 03:13 Asking lin whether he can live with rev Lin, thu, 10:37 No to 2 counters Apple wants to co-sign Lin DOES NOT AGREE
C1-202915	5GSM back-off mechanisms in an SNPN	Nokia, Nokia Shanghai Bell	CR 2156 24.501 Rel-16	Revision of C1-202412 _________________________________________ Ivo, Thu, 13:03 not clear in stage-2 whether LADN is in or out of scope for SNPN, EN is needed Sung, Mon, 00:12 Provides rev Ivo, Mon, 21:06 Fine, wants to co-sign Lin, Wed, 09:50 Comments Sung, Thu, 00:54 Rev Lin, Thu, 10:40 comments
C1-202857	3GPP PS data off in an SNPN	Nokia, Nokia Shanghai Bell	CR 2159 24.501 Rel-16	Revision of C1-202415 _________________________________________ Ivo, Thu, 13:04 Info on severl SNPN not available in 31.102 not 24.368, at least an EN is needed Lena, Thu, 23:41 31.102 and 24.368 CRs needed, does Nokia plan to bring them? Sung, Mon, 02:38 Asking for more input form Lena and Ivo Ivo, Mon, 21:19 Supports updating 24.368 Lena, Tue, 05:25 Agrees with Ivo, just update the MO and use if for both cases Sung, Wed, 13:45 Only MO Ivo, Wed, 15:16 Only 24.501 this meeting is fine Sung, thu, 02:08 Rev Lena, Thu, 06:18 Rev fine, mo change in next meeting is fine Ivo FINE
C1-202920	Service area restrictions in an SNPN	Nokia, Nokia Shanghai Bell	CR 2153 24.501 Rel-16	Revision of C1-202664 _________________________________________ Revision of C1-202409 Lin, merge this into a rev of 2408, keep changes minimal Lin can live with it Ivo, Thu, 13:01 Confusing wording Sung, Mon, 02:23 Providing a rev Ivo, Mon, 20:54 Fine, wants to co-sign Sung, Thu, 01:03 New rev
C1-202923	Miscellaneous clean-up for SNPN	Nokia, Nokia Shanghai Bell	CR 2152 24.501 Rel-16	Revision of C1-202408 _________________________________________ Lin, Mon, 04:30 Need to discuss the approach taken for documenting this, copying in or delta Applies for C1-202409_C1-202410_C1-202411_C1-202412 Sung, Mon, 05:23 Wants to know which clauses are not impacted Lin, Mon, 05:48 …. Are functions for PLMN and naturally can be supported by SNPN Sung, Mon, 05:56 Not clear what is requested from Lin Lin, Tue, 06:15 Examples Sung, Tue, 06:32 accepting Lin, Wed, 09:50 Comments Sung, Thu, 00:40 Rev Lin, Thu, minor change needed
Public network integrated NPN
C1-202008	CAG-ID not provided to lower layers during NAS signalling connection establishment	Ericsson / Ivo	CR 1880 24.501 Rel-16	Revision of C1-200937
C1-202014	Configured HRNN for CAG selection	Ericsson / Ivo	CR 0506 23.122 Rel-16	Merged in to C1-202845 Lena, Fri, 00:04 Not aligned with stage-2, EN not aligned with RAN2 Ban, Fri, 10:09 Not aligned with stage-2 Vishnu, Fri, 15:08 do not support this CR as this is not aligned with the current SA2 requirement Chen, Fri, 16:46 At very least has a dependency ot SA2 CR Kundan, Sat, 22:23 Not aligned with SA2, but Ivo has a point Ivo, Mon, 09:34 LS to SA2 fine, not SA1, provides a rev Kund, Mon, 15:26 Sounds fine Sung, Mon, 21:15 No need to touch the EN Ivo, Mon, 22:00 Agree both CRs in CT1 , and only one gets approved (2014, 2256). Peter, Tue, 07:25 Agreeing both CRs is not good Ivo, Tue, 10:34 Prefers to wait for next CT1 meeting Lena, Tue, 06:21 Prefers to progress 2256 Ivo, Wed, 10:31 Ok to go with one tdoc, wants to see 2256
C1-202091	CAG information list provided to lower layers after manual CAG selection	Ericsson / Ivo	CR 0512 23.122 Rel-16	Withdrawn DISCUSSION before Tue, 18:00 taken out, please see previous version of agenda Lena, Yanchao, Vishnu, Robert, Chen against the proposal Discussion ongoing, no conclusion Robert, Tue, 21:40 Cr is not acceptable Ivo, Tue, 21:51 Discussing with Robert Robert, Wed, 10:24 Long email being against this
C1-202102	Discussion on RAN2’s questions on CAG in LS R2-2002417	Qualcomm Incorporated / Lena	discussion Rel-16	Noted Ivo, Thu, 13:05 Proposed answer to Q 1.3 is not correct
C1-202199	Clarification of the cause of start of T3550	Vivo	CR 2070 24.501 Rel-16
C1-202239	Discussion on reply LS to RAN2 manual CAG selection	Huawei, HiSilicon/Vishnu	discussion 23.122 Rel-16	Noted Ivo, Thu, 13:07 should be answered, 1.2 partly ok, not OK with 1.3 Vishnu, Thu, 15:16 Answer to ivo Ivo, Fir, 13:38 Commenting Vishnu, Fri, 14:50 Answering to Ivo
C1-202242	Discussion on protecting CAG list against man in middle attack	Huawei, HiSilicon/ Vishnu	discussion 24.501 Rel-16	Noted Ivo, Thu, 13:10 To be raised in SA2 first, has a simpler solution Lena, Fri, 00:26 Seems to assume fake base station can connect to legit nw? seems there is no problem to be solved Kundan, Sat, 19:37 Bullet e) to go to SA3, highlighting to SA3 TR33.809 Vishnu, Mon, 20:39 Long list of comments Sung, Tue, 01:50 Should be discussed in SA2 as well Vishnu, 13:49 Not agreeing with Sung Kundan, wed, 17:46 Sa3 first Vishnu, Wed, 17:53 Ongoing Kundan, Wed, 19:07 Sung, Thu, 03:43 Ongoing with Vishnu
C1-202249	Protection of Allowed CAG list against man in middle attack	Huawei, HiSilicon / Vishnu	CR 2085 24.501 Rel-16	Postponed Ivo, Thu, 13:10 To be raised in SA2 first, has a simpler solution Lena, Fri, 00:28 CR not needed see comment on 2242 Sung, Mon, 21:03 To be raised in SA2 first
C1-202251	Discussion on including CAG Information list in reject messages	Huawei, HiSilicon / Vishnu	discussion 24.501 Rel-16	Noted Lena, Fri, 00:59 There is ongoing discsussionin SA2, prefers to wait for the outcome
C1-202258	Indication to user about allowed CAG IDs for manual CAG selection	Huawei, HiSilicon / Vishnu	CR 0519 23.122 Rel-16	Merged into merged to revision of C1-202398. Based on request form author, tue, 08:59 Ivo, Thu, 13:30 Not happy with the condition in the second new sentence Lena, Fri, 01:04 OK with the CR, hard to read, overlaps with Nokia’s C1-202398, preference for Nokia’s CR Kundan, Sat, 21:04 Fine with intent, rewording
C1-202470	No CAG in non-3GPP access	Huawei, HiSilicon/Lin	CR 2178 24.501 Rel-16
C1-202471	Correction on 5GMM #27 for CAG	Huawei, HiSilicon/Lin	CR 2179 24.501 Rel-16	Kundan, Sat, 21:55 Fine with parts, other changes to be corrected Sung, Tue, 01:42 Support the CR as is Lin, Tue, 10:36 Explaining to Kundan Kundan, wed, 17:41 fine
C1-202493	Discussion to RAN2 LS R2-2002417	Ericsson / Ivo	discussion Rel-16	Withdrawn Lena, Fri, 01:26 Fine with 1.1, 1.2, 2.1, 2.2, NOT ok with with 1.3
C1-202499	Discussion paper – Considerations for CAG ID in Unified Access Control	Chengdu OPPO Mobile Com. Corp.	discussion Rel-16	Noted Ivo, Thu, 13:37 There is no stage-1 requirement, CT1 needs to wait for any stage-1 requirement Lena, Fri, 01:28 Wait for SA1 before discussion in CT1 Chen, Fri, 11:34 Explaining why there is no need to wait for SA1
C1-202588	CAG Information in Registration Reject	InterDigital, Samsung / Atle	CR 1886 24.501 Rel-16	Merged into C1-202253 Ivo, Thu, 13:39 Long explanation of his concerns, would like to wait with aany solution in CT1 until SA2 concludes on S2-2002843 Lena, Fri, 01:29 wait for the outcome of the SA2 discussion Atle, Tue, 01:15 Fine to wait for the outcome of SA2 Kunden, Wed, 21:29 SA2 seems to have agreed with this Sung, thu, 03:47 Discussing with Kundan Kundan, Thu, 07:50 Not agreeing Atle, Thu, 08:44 Merge this into 2253
C1-202355	Clarification to Manual CAG selection procedure	Samsung/Kundan	CR 0520 23.122 Rel-16	Current status postponed Frederic, Thu, 09:08 Clauses affected missing Lena, Thu, 23:09 we cannot agree to this CR Vishnu, Fri, 14:28 not OK with this CR Kundan, Fri, 14:51 Answering to Lena, asking for some clarificaiotn Sung, Tue, 01:24 Does not see the step 2) as described by Kundan Kundan ongoing replies
C1-202357	Discussion paper on RAN2 LS regarding Manual CAG and URC for PNI-NPN	Samsung	discussion Rel-16	Noted Ivo, Thu, 13:31 Does not agree with the answer to 1.3
C1-202362	Sending CAG information list	Samsung/Kundan	CR 2128 24.501 Rel-16	Current Status Postponed Frederic, Thu, 09:08 Clauses affected missing Ivo, Thu, 13:34 Not ok with the solution, would be ok with sending LS to SA2 asking for a solution Lena, Thu, 23:19 Not inline with stage-2, if this is needed, then stage-2 is to be changed first Ban, Fri, 09:16 Does not agree with the CR Kundan Can accept to first send an LS to SA2 Ivo, Mon, 22:28 Sung, Mon, 23:40 With the LS, asks this to be postponed
C1-202363	Sending CAG information list	Samsun/Kundan	CR 0522 23.122 Rel-16	Current Status Postponed Frederic, Thu, 09:08 Clauses affected missing Ivo, Thu, 13:35 Not ok with the solution, would be ok with sending LS to SA2 asking for a solution Lena, Thu, 23:19 Not inline with stage-2, if this is needed, then stage-2 is to be changed first Ban, Fri, 09:16 Does not agree with the CR Kundan, Sun, 17:21 Defending the scenarios Ban, Mon, 14:40 Supports sending an LS Sung, Mon, 23:40 With LS, Requesting the CR to be postponed
C1-202364	Handling of a CAG UE at non supporting AMF	Samsung/Kundan	CR 1964 24.501 Rel-16	Current Status Postponed Revision of C1-200589 Ivo, Thu, 13:35 Requires AMF not supporting CAG to be CAG specific. Comment how roaming is to be solved Kundan, Thu, 14:45 Does not agree with Ivo Lena, Thu, 23:23 Does not make sense, CR requires the AMF to do something that the AMF does not support CR needs to be rejected Yanchao, Fri, 06:30 Same as Ivo and Lena DoCoMo, Fri, 08:55 Use case is not correct Ivo, Mon, 22:19 Does not work in all cases Sung, Tue, 00:56 same view as Ban, Yanchao, Lena Kundan, Tue, 07:44 Wants to send LS to SA2, this is a valid use cse,
C1-202368	Configuring UE to enable manual CAG selection procedure (24.501)	Samsung/Kundan	CR 2131 24.501 Rel-16	Withdrawn Ivo, Thu, 13:35 Solution has a problem with VPLMN Lena, Thu, 23:26 proposal in the CR does not work as well as a SIB indicator Kundan, Mon, 12.07 Answers Lena Ban, Mon, 12:47 Negative Sung, Tue, 00:04 Same as lena and Ivo Lena, Tue, 06.06 Not aligned with stage-2
C1-202370	Configuring UE to enable manual CAG selection procedure (23.122)	Samsung/Kundan	CR 0523 23.122 Rel-16	Curent Status Postponed Frederic, Thu, 09:08 Clauses affected missing Ivo, Thu, 13:35 Solution has a problem with VPLMN Lena, Thu, 23:26 proposal in the CR does not work as well as a SIB indicator Sung, Tue, 00:04 Same as lena and Ivo
C1-202495	Correction to Manual CAG selection procedure	Samsung/Kundan	CR 0529 23.122 Rel-16
C1-202840	Providing configured HRNN for CAG selection	Ericsson / Ivo	CR 2009 24.501 Rel-16	Revision of C1-202015 Revision of C1-200733 Lena, Fri, 00:13 Not aligned with stage-2, EN not aligned with latest status in RAN2 Ban, Fri, 10:09 Not aligned with stage-2 Ivo, Mon, 09:44 Providing rev, with dependency on SA2 CR
C1-202845	Handling of HRNN information in a CAG cell	Huawei, HiSilicon / Vishnu	CR 0518 23.122 Rel-16	Revision of C1-202256 Ivo, Thu, 13:29 Prefers procedure as described in C1-202014 Lena, Fri, 01:02 Fine with the CR, correct editorials Ban, Fri, 09:50 Fine with the CR Kundan, Sat, 20:48 Fine with intent, but changes are needed Vishnu, Tue, 09:29 Providing a rev Ivo, Tue, 21:19 Wants something like in 2014 in this CR, has some proposed wording Vishnu, Tue, 21:59 Offers a way forward with an EN Ivo, Tue, 22:46 Highlighting technical concern Vishnu, Tue, 21:59 Will take the concern on board Provides rev at 14:19 Ivo, Wed, 14:55 NOTE0 and clauses affected Ivo is OK
C1-202737	Correction on no suitable cell	Vivo	CR 0517 23.122 Rel-16	Revision of C1-202179 _________________________________________ Ivo, Thu, 13:05 limited service state should apply also in situation when the user selects a PLMN and CAG-ID in manual selection and the UE happens to camp on a non-CAG cell of the PLMN Yanchao, Mon, 11:00 Questions to Ivo Ivo, Mon, 21:42 More changes Yanchao, Tue, 15:11 Ivo’s proposal is unclear Ivo, Wed, 14:47 Explaining Yanchao, Wed, 16:44 Ok, rev Ivo, Wed, 20:15 good
C1-202886	Provision of CAG information list in reject messages	Huawei, HiSilicon/ Vishnu	CR 2087 24.501 Rel-16	Revision of C1-202253 _________________________________________ Ivo, Thu, 13:28 Long explanation, prefers to wait until SA2 has concluded on S2-2002843. Vishnu, Thu, 16:50 Explaining that sending CAG information list IE to the UE in the REJECT messages is the more optimized solution than using CUC procedure Lena, Fri, 00:59 There is ongoing discsussionin SA2, prefers to wait for the outcome Ivo, Fri, 13:41 Disagrees with Vishn Kundan, sat, 19:53 Supports the contribution, ID and Samsung have same concept Kunden, Sat, 20:25 Answering Ivo Ivo, Mon, 21:51 Wait for S2 Ivo, Thu, 08:03 Sa2 allows this Kund, Thu, 08:08 Same nfo Lena, Thu, 08:31 Same infor Ivo, Thu, 08:32 Comment on the ct1 CR Vishnu Thu, 08:50 Modification Vishnu, Thu, 09:02 New rev Ivo is fine
C1-202924	CAG selection is optional in the manual network selection mode	Nokia, Nokia Shanghai Bell	CR 0526 23.122 Rel-16	Revision of C1-202405 -------------------------------------------- Ivo, Thu, 13:37 First change not needed Vishnu, Fri, 14:12 Some changes on the second change Sung, Tue, 01:01 Discussing way forward Ivo, wed, 20:18 Asks for a draft rev to see how this looks like Sung, Thu, 03:52 Rev Kundan, Thu, 04:30 Not ok Sung, Thu, 04:35 New rev Kundan, Thu, 04:41 Not agreeing Sung, Thu, 04:53 Ongoing Kundan, Thu, 05:43 Not agreeing with some parts Ivo, Lena, Vishnu (co-sign) Agree with Sung
C1-202912	Selected CAG-ID from the NAS layer to the AS layer	Nokia, Nokia Shanghai Bell, vivo, Qualcomm Incorporated, Samsung, Huawei, HiSilicon	CR 0525 23.122 Rel-16	Revision of C1-202397 _________________________________________ Ivo, Thu, 13:36 providing the manually selected CAG-ID using separate element has issues Kundan, Sat, 21:15 Despite co-signing, some rewording needed Sung, Tue, 02:13 To Ivo ,separate element v. allowed CAG list manipulation should be discussed in a separate thread, explaining some things to Ivo Sung, Wed, 16:24 Providing rev Ivo, Thu, 00:00 This goes in the right direction, modification Sung, Thu, 03:59 Fine with Ivo’s proposal, new rev Robert, Thu, 11:27 Slight rewording to the rev Vishnu agrees with Robert Ivo OK
C1-202862	Manual CAG selection	Nokia, Nokia Shanghai Bel	CR 0499 23.122 Rel-16	Revision of C1-202398 Vishnu, no objectin, fix it in May Kundan wants to tick RAN box, fix it in next meeting _________________________________________ Revision of C1-201052 Ivo, Thu, 13:36 EN hard to read, bullet b) unclear Lena, Fri, 01:13 Fine with the CR, requests some rewording Yanchao, Fri, 06:35 Comments Kundan, Sat, 21:39 Comments, need to discuss this on Monday Sung, Mon, 21:44 Provides a rev Ivo, Mon, 22:35 Fine Vishnu, Tue, 09:03 One thing is missing in the rev Robert, Tue, 11:22 Slight rewording Ban, Tue, 12:50 Support Robert, wants to co-sign Ivo, Tue, 12:51 Support Robert, wants to co-sign Kundan, wed, 17:33 Provding the changes he wants to see Sung, Thu, 02:15 Not agreeing with Kundan Lena, thu, 02:46 Fine, minor editorial Sung, Thu, 03:00 New rev Vishnu, thu, 08:28 Almost ok
Time sensitive communication
C1-202192	Abbreviation correction	vivo	CR 0002 24.519 Rel-16
C1-202429	IEEE Std 802.1Qbv-2016 rolled into IEEE Std 802.1Q-2018	Nokia, Nokia Shanghai Bell	CR 0003 24.519 Rel-16
C1-202435	TSN working domain	Nokia, Nokia Shanghai Bell	CR 2170 24.501 Rel-16	Postponed Ivo, Thu, 13:39 C1-202350 is more complete Lena, Fri, 01:33 CR is ok, overlaps with C1-202350, - Additional changes to subclause 4.15.2.2 are missing (they are covered in Huawei’s C1-202350) Sung, Mon, 03:49 Providing rationale Cristina, Tue, 05:47 Wants to postponed and wait for SA2 OK with postponing both C1-202350 and C1-202435, wants to go on with 2433
C1-202714	Correction of the abnormal case in NW-TT-initiated Ethernet port management procedure	vivo	CR 0001 24.519 Rel-16	Revision of C1-202191 Lena, Fri, 01:30 Fine, but remove unmodified clauses from CR Yanchao, Mon, 10:15 Providing rev Lena, Thu, 02:22 Fine with the rev
C1-202860	TSN working domain	Nokia, Nokia Shanghai Bell	CR 0002 24.535 Rel-16	Revision of C1-202433 Crsitina: Fine Ivo, Thu, 13:40 Overlaps with C1-202353 Lena, Fri, 01:32 fine with the CR but it overlaps C1-202353 Sung, Mon, 03:50 Defending Cristina, Tue, 05:47 Wants to postponed and wait for SA2 OK with postponing both C1-202350 and C1-202435, wants to go on with 2433
5G_CioT	Peter – Main	CT aspects of Cellular IoT support and evolution for the 5G System
C1-202078	Discussion on the mandatory Integrity protection maximum data rate field for UEs that support control plane only	Samsung	discussion Rel-16	Noted Amer, Fri, 03:36 If anything, then a NOTE related to AMF Mahmoud, Fri, 04:16 Explaining to Amer Amer, Fri, 17:31 Meant SMF not Amf Mahmoud, Fri, 17:49 Commenting to Amer Amer, Fri, 19:33 Commenting, could see a NOTE Mahmoud, Fri, 19:47 Disc goes on Mikael, Fri, 23:57 Comments and suggestions Amer, Sat, 06:08 Reacting to Mikael, no need to impact Ue Mikael, Sat, 10:45 Requires UE action Amer, Sat, 14:17 Integrity protection maximum data rate IE Is a mandatory IE, Note in table, Mahmoud, Sat, 22:41 discussing Behourz, Sun, 01:18 Seconds Mahmoud Amer, Sun, 08:46 CR is a solution looking for a problem, hard to justify it for Rel-16 Lin, Mon, 05:42 Supports the solution Mikael, Mon, 07:55 Support the solution Fei, Mon, 08:24 Support the solution Amer, Mon, 20:36 Solution is not clean, if no one else has problems, will not object
C1-202079	Integrity protection data rate for UEs that don’t support N3 data transfer	Samsung	CR 2031 24.501 Rel-16
C1-202082	Addition of Control Plane Service Request in the abnormal cases for service request procedure	InterDigital Communications	CR 2032 24.501 Rel-16
C1-202085	Correcting a wrong reference	InterDigital Communications	CR 2035 24.501 Rel-16
C1-202176	Correction of SGC	vivo	CR 2062 24.501 Rel-16
C1-202202	subclause of Negotiated WUS assistance information	vivo	CR 2073 24.501 Rel-16	Merged into C1-202465 and revisions Based on request from Yanchao, mon, 05:19 Lin, Sat, 11:53 Agrees there is something to be done, asks whether this can be merged into C1-202465
th	C1-202245	CioT user data container in CPSR message not forwarded	Ericsson /kaj	CR 1743 24.501 Rel-16	Merged into C1-202779 Revision of C1-200675 ________________________________ C1-202169, C1-202337, C1-202461 Amer, Fri, 03:49 Prefers approach with Service Reject (like in 2169 and 2461) Behrouz, Fri, 05:49 Comments Kaj, Fri, 12:05 Answering Amer Amer, Fri, 17:29 Highlights he switched a vs b, Prefers approach with Service Accept (like in 2245 and 2237) Amer, Fri, 17:29 Highlights he switched a vs b, Prefers approach with Service Accept (like in 2245 and 2237) Behrouz, Fri, 18:15 Support Ericsson Lin, Sat, 10:35 Number of comments, routing failure to be treated as abnormal case
C1-202367	Correction on terminology for the Control plane CioT 5GS optimization	SHARP	CR 2130 24.501 Rel-16
C1-202387	Discussion on errors on QoS parameter operations in NB-IoT	BEIJING SAMSUNG TELECOM R&D	discussion	Noted
C1-202403	Discussion on integrity check failure on the Control Plane Service Request message for WB-N1 mode UEs	BEIJING SAMSUNG TELECOM R&D	discussion	Noted
C1-202419	Corrections to CR#1907	Qualcomm Incorporated / Amer	CR 2162 24.501 Rel-16	Overlaps with C1-202465 Lin, Sat, 12:32 Offers to take all changes on board in 2465 Amer, Sat, 13:47 Fine to merge Some offline discussion, the CR is kept yellow
C1-202460	Discussion on routing failure of CPSR	Huawei, HiSilicon, China Mobile/Lin	discussion Rel-16	Noted
C1-202461	Routing failure handling of CPSR	Huawei, HiSilicon, China Mobile/Lin	CR 2172 24.501 Rel-16	Merged into C1-202337 Based on request form author, Wed, 06:16 C1-202169, C1-202245, C1-202337 Amer, Fri, 03:49 Prefers approach with Service Reject (like in 2169 and 2461) Kaj, Fri, 07:29 preference is to use SERVICE ACCEPT message and solution in C1-202245. Lin, Fri, 10:58 Explaining the his solution Amer, Fri, 17:29 Highlights he switched a vs b, Prefers approach with Service Accept (like in 2245 and 2237)
C1-202462	Acknowledgement of truncated 5G-S-TMSI configuration	Huawei, HiSilicon/Lin	CR 2173 24.501 Rel-16
C1-202463	NAS-MAC calculation for RRC connection reestablishment for NB-IoT CP optimisation	Huawei, HiSilicon/Lin	CR 2174 24.501 Rel-16
C1-202464	Removal of Editor’s Note for CP congestion control	Huawei, HiSilicon/Lin	CR 2175 24.501 Rel-16
C1-202614	QoS error checks for UEs in NB-N1 mode	BEIJING SAMSUNG TELECOM R&D	CR 2145 24.501 Rel-16	Revision of C1-202388 Ivo, Thu, 16:25 Issue with new bullet 5) Mahmoud, Thu, 16:53 Explaining the logic, asking if Ivo is ok Ivo, Fri, 11:20 Not yet OK, provides wording Mahmoud, Fri, 15:58 Offers new wording Ivo, Fri 16:13 Fine, wants to co-sign
C1-202626	Retransmission of a CPSR message after integrity check failure at the AMF	BEIJING SAMSUNG TELECOM R&D	CR 2150 24.501 Rel-16	Revision of C1-202404 Amer, Fri, 18:18 Commenting, provides new text Mikael, Mon, 10:39 Supports Amer proposal Mahmoud, Mon, 21:06 Provides rev Amer, Tue, 03:01 Rev looks fine Mikeal, Tue, 12:21 Looks good
C1-202662	UE specific DRX for NB-S1 mode	Vodafone GmbH	CR 3353 24.301 Rel-16	Revision of C1-202384 Amer, Tue, 17:24 OK Lin, Wed, 08:22 good Amer, Fri, 04:49 Fine in principle, some changes needed Behrouz, Fri, 06:10 Type 1 IE, “K-“ cannot be used as IEI. Yang, Fri, 07:18 Agrees with Behrouz, will revise Yang, Fri, 07:22 Will take comments form Amer on board Lin, Fri, 08:20 prefer to keep the full range value in the CT1 CR and then put an EN to indicate RAN2 dependency Yang, Fri, 08:27 The EN is already there Yang, Fri, 09:56 Provides a rev in the Inbox, once this is a new TDOC number, it will have TEI16, needs to be shifted to TEI16 agenda item Amer, Fri, 17:43 Further comments, with revised text Lin, Sat, 11:03 Does not prefer the new text from Amer Amer, Mon, 05:14 RAN2 has not agreed on values, CT1 should not do either Yang, Mon, 08:38 and 11:34 Provding a rev Lin, Tue, 05:25 Fine with the rev
C1-202674	Correct handling of receiving EMM cause #31 in EPS	Qualcomm Incorporated	CR 3349 24.301 Rel-16	Revision of C1-202270 Lin: FINE Lin, Mon, 07:20 please check whether alternative in CR C1-198212 for 4G and C1-198211 for 5G could be a way forward Osama, Mon, 19:59 comments Lin, Tue, 04:08 Not convinced that new counter is needed in 4G Sung, Tue, 06:53 Seems ok with a revision?? Lin, Wed, 05:29 Fine
C1-202676	Correct UE azarosi for receiving 5GMM cause #31 in 5GS	Qualcomm Incorporated	CR 2094 24.501 Rel-16	Revision of C1-202271 LIN: FINE Lin, Mon, 07:20 please check whether alternative in CR C1-198212 for 4G and C1-198211 for 5G could be a way forward Osama, Mon, 19:59 Comments Lin, Tue, 04:08 Can live with this, overlap with 2373 to be sorted out Sung, Tue, 06:53 Seems ok with a revision?? Lin, Wed, 05:29 Fine, minor editorial
C1-202749	Adding new abnormal cases on the network side for CPSR	China Mobile, InterDigital	CR 2056 24.501 Rel-16	Revision of C1-202169 Overlaps with C1-202245, C1-202337, C1-202461 Amer, Fri, 03:49 Prefers approach with Service Reject (like in 2245 and 2237) Behrouz, Fri, 05:49 Asking Amer for clarification (should be resolved as Amer corrected initial statements) Kaj, Fri, 09:46 Some questions, merge needed with 2461, if this goes forward Amer, Fri, 17:29 Highlights he switched a vs b, Prefers approach with Service Accept (like in 2245 and 2237) Behrouz, Fir, 18:37 Explaining to Kaj Lin, Tue, 14:53 Ansering Behrouz
C1-202735	Emergency PDU sesseion established after WUS negotiation	vivo	CR 2063 24.501 Rel-16	Revision of C1-202177 Lin, Fri, 03:56 Fine in principle, needs some changes, wants to co-sign Amer, Fri, 04:11 does not belong in the NAS specs, could be done by a note. Yanchao, Fri, 11.22 Answering Lin, Sat, 11:48 Withdraws the earlier comment, wants co-sign Amer, Sat, 15:20 T oYanchao: I see your point but I would prefer to not repeat clear mistakes. However, if you feel strongly about keeping the existing text, I will not object. Yanchao, Mon, 10:40 Rev with Huawei as support Lin, Mon, 16:32 fine Amer, Wed, 07:07 Not happy, will not obect
C1-202836	Non-integrity protected REGISTRATION REJECT message including 5GMM cause #31 or #76	Nokia, Nokia Shanghai Bell	CR 2134 24.501 Rel-16	Revision of C1-202373 Osama, Tue, 05:27 Asking whether 2271 could be way forward instead of this cr Sung: needs to be shifted to 16.2.7.2. Lin, Wed, 05:33 Asking on a detail
C1-202699	Handling of PDU session and PDN connection associated with Control plane only indication in case of N26 based interworking procedures	SHARP	CR 2132 24.501 Rel-16	Revision of C1-202369 Lin Fine Lin, Mon, 05:05 Fine in principle, more needed Yudai, Tue, 05:46 Provides a rev Lin, wed, 06:19 Wording issue Yudai, Wed, 08:30 New rev
C1-202775	Connection Resumption for Notification	ZTE, vivo	CR 2113 24.501 Rel-16	Revision of C1-202336 Lin: Fine Lin, Sat, 12:33 Number of comments Fei, Tue, 09:49 Rev Lin, Wed, 06:00 Fine, editorial Fei, Wed, 09:49 New rev
C1-202779	CioT user or small data container in CPSR message not forwarded	ZTE	CR 2114 24.501 Rel-16	Revision of C1-202337 Lin FINE C1-202169, C1-202245, C1-202461 earlier disc of Amer, Behrouz, Kaj, Lin captured in previous agenda Fei, Tue, 03.44 Lin, Wed, 06:16 Some more comments Behrouz, Wed, 06:47 OK with the CR, curious why ID is a co-signer Amer, Wed, 08:36 Looking for an anwer to his question Fei, Wed, 08:58 Has already answered 03:27 Kaj; wed, 10:07 One Nate and then Ericsosn co-signs Fei, Wed, 10:20 Ericsosn added in latest rev Behrouz, Wed, 15:36 Note from Kaj ok Amer, Wed, 16:17 Can not agree the CR in its current form Fei, Wed, 17:24 Answering the third time to Amer Amer, thu, 02:56 The CR looks good
C1-202782	Clarification on the UE behaviour when receiving T3448	ZTE	CR 2112 24.501 Rel-16	Revision of C1-202335 Lin, Sat, 12:04 Some change needed, bullet c) not Amer, Sat, 15:10 Not clear why timer is stopped, bullet c) is needed Lin, Tue, 04:36 Commenting to Amer Fei, Tue, 13:19 Providing rev Fei, Wed, 03:49 New rev Lin, Wed, 05:49 Fine for rev2
C1-202878	Initial APN rate control parameters	Qualcomm Incorporated / Amer	CR 3216 24.008 Rel-16	Revision of C1-202422 _________________________________________ Lin, Sat, 10:19 Cover page issue Amer, Sat, 16:06 Acks Lin
C1-202880	Signalling of EPS APN rate control parameters during PDU session establishment	Qualcomm Incorporated / Amer	CR 2164 24.501 Rel-16	Revision of C1-202423 _________________________________________ Lin, Sat, 10:21 Number of comments Amer, Sat, 16:39 Provides rev Lin, Tue, 08:51 Updates Amer, Wed, 09:15 Rev Lin, Wed, 09:57 Some changes fine, others not
C1-202882	Ethernet header compression for CP CioT – 5GMM aspects	Qualcomm Incorporated / Amer	CR 2165 24.501 Rel-16	Revision of C1-202425 _________________________________________ Kaj, Fri, 10:14 Cover sheet Amer, Sat, 05:52 Acks Kaj
C1-202888	Ethernet header compression for CP CioT – 5GSM aspects	Qualcomm Incorporated / Amer	CR 2166 24.501 Rel-16	Revision of C1-202426 _________________________________________ Mahmoud, Sat, 01:03 Questions Amer, Sat, 05:45 Ansering Mahmoud Lin, Sat, 11:33 Issues with the proposed IE encoding provides a proposal Amer, Sat, 16:02 Provides a rev in Inbox Mahmoud, Sat, 21:41 Interworking aspects not covered Amer, Sun, 00:25 EPS does not support Ethernet header comp, no need for interworking Kaj, Mon, 15:37 Minor edit Mahmoud, Mon, 15:46 Missing aspect in the Cr Amer, Tue, 03:14 Explaining Lin, Tue, 09:12 Fine in general, some mistakes Mahmoud, Wed, 00:17 Comments Amer, Wed, 10:03 Acks the point, discussing Mahmoud, Wed, 16:02 Discussing Amer, Thu, 05.12 New rev Mahmoud, Thu Looks good Amer providing some outlook to next meetng and additional work Mahmoud wants to see an EN
C1-202692	Correction to handling of T3447 timer	MediaTek Inc.	CR 2195 24.501 Rel-16	Revision of C1-202521 _________________________________________ Lin, Mon, 05:55 Change is needed, rewording
C1-202892	Generic UE configuration update trigger for registration and EC Restriction change	Ericsson / Mikael	CR 2077 24.501 Rel-16	Revision of C1-202230 _________________________________________ Overlaps with C1-202077 Amer, Fri, 04:53 Proposes changes Behrouz, Fri, 06:37 Different proposal for the IE than Amer Mikael, Fri, 11:03 Needs to think more and will provide a proposal Lin, Sat, 11:23 This looks very similar to C1-202077 now Mikael, Mon, 10:29 Wants a bit, will update according comments Lin, Tue, 05:42 More proosals Mikael, Tue, 07:43 Happy to make approach for merging Mikael, Tue, 10:51 Provides the rev Mahmoud, Tue, 20:57 Generally fine, some minors, wants co-sign Mikael, Wed, 08:05 New rev Lin, fine wants to co-sign, minor edit on the cover page Mikael, will fix this
C1-202904	Indication of change in the use of enhanced coverage	Samsung, InterDigital, Huawei, HiSilicon	CR 2030 24.501 Rel-16	Revision of C1-202648 Amer FINE _________________________________________ Revision of C1-202077 Mikael, Thu, 09:31 Some comments Mahmoud, Thu, 09:35 Explains to mikael Mikael, thu, 10:50 Fine, can revise in the future, if needed Overlaps with C1-202230 Amer, Sat, 14:30 New text leaves some aspects undefined Mahmoud, Sat, 21:38 Asking for wording Amer, Sun, 00:02 Proposal Mikael, Mon, 10:10 Comments, suggests to merge with 2230 Mahmoud, Mon, 22:10 Provides wording Amer, Tue, 03:33 Text works, some more suggestion Mahmoud, Tue, 05:46 Fine to merge some parts into 2230, wants to wait for Hua and ID Behrouz, Tue, 05:56 Fine to merge, co-sign the other paper Amer, Thu, 02:25 Suggestions Mahmound, Thu, 06:51 fine
C1-202866	PDU session release due to CP only revocation	OPPO / Rae	CR 2107 24.501 Rel-16	Revision of C1-202707 __------------------------------------------------ Revision of C1-202328 Amer, Thu, 02:30 Untick ME Amer, Fri, 04:44 Question for clarification Kaj, Fri, 10:06 New cause not needed Lin, Sat, 11:58 Same as kaj, use #39 Rae, Tue, 07:13 Rev Lin; Wed, 05:42 Proposals Kaj, Wed, 09:54 Fine, also lin’s proposals Amer, Thu, 02:30 Untick ME box
C1-202795	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-202459 _________________________________________ Revision of C1-200893 Behrouz, Fri, 06:48 Main comment: As I azarosio, this is a resubmission of the CR. Not much has changed since last time and our position is still that the gain (3 octets) does not justify defining a Non-standard NAS message Amer, Sun, 22:58 Qualcomm is neutral From the WI rapporteur point of view, I intend to remove this task from the 5G CioT work plan after this meeting. In other words, the WI will be considered complete regardless of the outcome of this discussion (4 meetings no result) Sung, Tue, 06:48 Support positin of wid rapporteur Behrouz, Tue, 06:55 Support positin of wid rapporteur Lin, Wed, 10:33 Asking for technical postion from Sung Sung, Wed, 14:40 Negative Vivek, Wed, 18:20 Negative Lin, Thu, 03:54 Providing a rev Behourz, Thu ,04:12 Fine with the rev Sung, Thu, 04:37 Works Lin ok with Behrouz
C1-202796	Correction on WUS assistance	Huawei, HiSilicon/Lin	CR 2176 24.501 Rel-16	Revision of C1-202465 ----------------------------------------- Overlaps with C1-202419 Mikael, Mon, 09:39 Hinting at a case that seems not covered Lin, Mon, 16:46 Answers to Mikael Mikael, Tue, 09:11 Still concerns Lin, Tue, 10:14 Acks mikael Mikael, Tue, 11:31 Mostly ok, some correction Lin, Wed, 10:34 New rev to ack Mikael Mikael, Wed, 12:46 Fine, co-signing Lin, Thu, 04:03 done
C1-202926	DRX parameters for NB-IoT	InterDigital Communications	CR 2034 24.501 Rel-16	Revision of C1-202865 _________________________________________ Revision of C1-202671 Lin: 2865, below “5GS” should be “NB-N1 mode Revision of C1-202619 Revision of C1-202611 Amer, Mon, 04:51 CR looks good Lin, Mon, 16:15 For the time being fine Behrouz, Mon, 17:34 Fine with Lin email Amer, Tue, 03:22 define all the code points for the relevant IE ASAP Revision of C1-202084 Lin, Thu, 05:29 Specify the full range, like Amer Amer, Thu, 03:06 CR looks good, can you update cover page and a referenc to stage-2 Lin, Sat,10:58 Provides detailed comments in the Inbox Behrouz, Sat, 20:52 We need to decide whether to not define anything or define the full range
C1-202734	Avoid repeated redirection for NB-IoT	OPPO / Rae	CR 2106 24.501 Rel-16	Postponed Revision of C1-202326 Amer, Fri, 04:41 proposed text should be converted into a note. Kaj, Fri, 09:54 Conflicts with existing statements Ban, Fri, 12:43 Same as Kaj Rae, 08:45 Proposing some text Rae, Thu, 04:32 Providing a rev to address Amer comment Marko, Thu, 09:05 Not a proper solution Rae, thu, 10:20 New rev Marko still don’t think this is right solution
5WWC	Peter – Main	CT aspects on wireless and wireline convergence for the 5G system architecture
C1-202168	ANDSP is not supported by 5G-RG and W-AGF	ZTE / Joy	CR 2055 24.501 Rel-16
C1-202207	Work plan for the CT1 part of 5WWC	Huswei, HiSilicon /Christian	discussion Rel-16	Noted Ivo, Thu, 13:42 Some things missing, some not needed
C1-202486	Discussion on 3GPP based access authentication for untrusted non-3GPP access to 5GCN	Ericsson, BlackBerry UK Ltd., Motorola Mobility, Lenovo / Ivo	discussion Rel-16	Noted Lena, Sun, 00:03 Not specific to 5WWC, rather 5Gprotoc16, not inline with SA3 decission, why would CT1 give a security requirement to SA3? Andrew, Wed, 10:36 First in SA3 Ivo, Wed, 10:55 There is no Cr,
C1-202571	EAP details for N5GC	Nokia, Nokia Shanghai Bell	CR 2207 24.501 Rel-16	Withdrawn
C1-202572	Corrections on N5GC SUPI SUCI	Nokia, Nokia Shanghai Bell	CR 0128 24.502 Rel-16	Withdrawn
C1-202573	NAS impacts supporting IPTV	Nokia, Nokia Shanghai Bell	CR 2208 24.501 Rel-16	Withdrawn
C1-202574	Support IPTV via wireline access	Nokia, Nokia Shanghai Bell	CR 0129 24.502 Rel-16	Withdrawn
C1-202694	Secondary authentication and W-AGF acting on behalf of N5GC	Ericsson / Ivo	CR 2028 24.501 Rel-16	Revision of C1-202018 Roozbeh, Thu 18:37 Add “device” Ivo, Fri, 09:33 Fine with comments, rev in Inbox
C1-202653	Error type on failure of reserving QoS resources over non-3GPP access	ZTE / Joy	CR 0126 24.502 Rel-16	Revision of C1-202293 Frederic, Thu, 09:08 Clauses affected missing Roozbeh, Thu, 20:49 Rewording and editorials Joay, fri, 08:58 Acknowledging roozbeh comments Roozbeh, Fri, 20:04 Found a new problem with the CR Joy, Sat, 04:24 Providing answers to Roozbeh Roozbeh, Sat, 05:06 Answers to Joy Joy, Sat, 12:02 Provides rev Roozbeh, Sat, 18:09 More proposals Joy, Mon, 13:00 New rev Roozbeh, Tue, 02:41 Fine, type editorial Joy, Tue, 10:14 Will fix
C1-202612	Inclusion of requested NSSAI in AN parameters	Motorola Mobility, Lenovo	CR 0122 24.502 Rel-16	Revision of C1-202284 _________________________________________ Ivo, Thu, 13:42 Wants ot co-sign Roozbeh, Sun, 19:32 Rev in Inbox Ivo, Mon, 22:42 fine
C1-202613	Inclusion of NSSAI in AN Parameters for non-3GPP access	Motorola Mobility, Lenovo	CR 2100 24.501 Rel-16	Revision of C1-202283 Ivo, Fri, 12:11 CR is NOT OK _________________________________________ Ivo, Thu, 13:44 Wants to co-sign Roozbeh, Sun, 19:32 Rev in Inbox Ivo, Mon, 22:41 Looks fine Roozbeh, Wed, 18:37 Some suggetions Larzaros suggestion, taken on board by Roozbeh, Thu, 00:08 Ivo, Thu, 00:18 NOT OK Roozbeh, Thu, 00:48 New rev Lazaros, Thu, 01:09 Minor improvements Roozbeh, thu, 02:56 drafting
C1-202636	Removal of editor’s notes	Motorola Mobility, Lenovo	CR 0123 24.502 Rel-16	Revision of C1-202290 _________________________________________ Ivo, Thu, 13:42 Last EN can’t be removed without specification work Roozbeh, Sun, 21:53 Questions to Ivo Ivo, Mon, 22:48 Explaining why EN can’t be removed Roozbeh, Tue, 03:11 Providing new rev Roozbeh, Wed, 19:30 Highlighting the new rev, can ivo live with it Ivo, Wed, 20:25 Nearly ok Roozbeh REV
PARLOS	Lena – Breakout	CT aspects of System enhancements for Provision of Access to Restricted Local Operator Services by Unauthenticated UEs 100%
C1-202125	Miscellaneous editorial corrections	Samsung Electronics Polska	CR 2046 24.501 Rel-16	Withdrawn
C1-202601	Miscellaneous editorial corrections	Samsung Electronics Polska	CR 3340 24.301 Rel-16	Current Status: Agreed Revision of C1-202126 ------------------------------------------ Ivo, Thursday, 11:55 - "Attached for access to RLOS" definition: "requessted" -> "requested"
C1-202879	Clarify UE behaviour for reject cause #9 and #10 received when attached for RLOS	Samsung/Anikethan	CR 3342 24.301 Rel-16	Current Status: Agreed Revision of C1-202147 ------------------------------------------------ Lena, Friday, 01:52 The changes for TAU reject seem ok but the text does not read well. I suggest instead “Then if the UE is in the same selected PLMN where the last tracking area updating procedure was attempted, the tracking area updating procedure was rejected with an EMM cause value other than #9, #10 and #40, and timer T3346 is not running, the UE shall:” For the service reject, changes for causes #10 and 40 seem ok but same wording comment applies. About cause #9, according to subclause 4.4.4.3, the network will reject a service request with cause #9 if the UE is not attached for access to RLOS: “If a SERVICE REQUEST, EXTENDED SERVICE REQUEST or CONTROL PLANE SERVICE REQUEST message fails the integrity check and the UE has only PDN connections for non-emergency bearer services established and the PDN connections are not for RLOS, the MME shall send the SERVICE REJECT message with EMM cause #9 "UE identity cannot be derived by the network" and keep the EMM-context and EPS security context unchanged.” So changes for cause #9 for the service reject case do not seem justified Anikethan, Saturday, 19:51 -> I think the text proposed in the CR is more clear since it brings out the association between attempt and reject. A comma separated text would end up opening up an interpretation of both these conditions being separate (OR sort of condition). That is how we read many comma separated text formulations in the specification -> I think the text proposed in the CR is more clear since it brings out the association between attempt and reject. A comma separated text would end up opening up an interpretation of both these conditions being separate (OR sort of condition). That is how we read many comma separated text formulations in the specification Lena, Wednesday, 23:22 I can live with keeping handling of cause #9 for the service reject. But I cannot accept the current wording as it is hard to understand. I propose to use bulleted lists instead. Anikethan, Thursday, 7:07 I am fine with the suggested changes, a draft revision is available. Lena, Thursday, 7:24 I am OK with the draft revision.
5G_eLCS (CT4)	Peter – Main	CT aspects of Enhancement to the 5GC LoCation Services
C1-202548	Adding Location Privacy Setting operation	CATT	CR 0001 24.571 Rel-16	Lena, 23:52 More changes needed, want to see a complete solution Scott, Wed, 18:55 Lena, Thu, 05:41 Thanks for the info. Given you intent to submit the CR to TS 24.080 at the CT4 May meeting, we are OK with C1-202548.
C1-202549	Addition of new AT command for 5G Location Services testing	CATT	CR 0689 27.007 Rel-16	Postponed Revision not provided in 3GU Atle, Fri, 08:27 Many comments Lena, Sun, 23:49 <plane> parameter should be removed Scott, Wed, 20:11 Replying with draft Lena, Thu, 07:14 Ok with the draft Atle, Thu, 11.11 Comments Atle Thue11:44 Fine with the rev
C1-202562	Supplementary LCS Service Operations	CATT	draftCR 24.080 Rel-16	Withdrawn 24.080 is a CT4 spec
V2XAPP	Lena – Breakout	CT aspects of V2XAPP Is TS 24.486 sufficiently stable to be sent to CT#88 for approval
C1-202206	Work plan for the CT1 part of V2XAPP	Huawei, HiSilicon /Christian	discussion Rel-16	Current Status: Noted
C1-202208	Latest reference version of draft TS 24.486	Huawei, HiSilicon /Christian	draft TS 24.486 Rel-16	Current Status: Noted
C1-202212	Miscellaneous corrections	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Current Status: Agreed
C1-202458	Application unique IDs for the VAE layer	Huawei , HiSilicon /Christian	pCR 24.486 Rel-16	Current Status: Agreed
C1-202489	Network monitoring by the V2X UE procedure	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Withdrawn
C1-202546	Structure and data semantics for V2X application resource management procedure	Huawei, HiSilicon / Chen	pCR 24.486 Rel-16	Current Status: Agreed
C1-202728	XML scheme declaration for V2XAPP	Huawei, HiSilicon / Chen	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202544 ------------------------------------------------- Sapan, Friday, 17:00 Editor’s note should not be removed as actual XML schema is not provided yet. Chen, Saturday, 3:12 OK with me. The complete xml scheme will be provided next meeting. The draft revision with the editor’s note unremoved is now available. Sapan, Sunday, 19:13 I am fine with the draft revision.
C1-202729	V2X application resource management procedure	Huawei, HiSilicon / Chen	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202545 ----------------------------------------------------- Sapan, Friday, 17:07 1) Two references has same number: IETF RFC 4825 [12] (used in clause 6.8.1) and IETF RFC 2616 [12] (used in clause 6.8.2). Please correct it. 2) Also, RFC 4825 is for XCAP operations. Does VAE supports XCAP operations? 3) In clause 6.8.2- clear how server will authorize the sender? Please clarify. Chen, Saturday, 10:54 -> OK -> After some further thinking of the authorization, the step with the reference is removed to be aligned with other procedures -> The VAE layer is over SEAL layer, and clause 5 and stage 2 of TS 23.286 clause 9.1 indicates that the VAE capabilities (VAE client and VAE server) utilizes identity management service procedures (e.g. authentication and authorization of UEs) of SEAL to support V2X services. Therefore, to be aligned with other procedures, the authorization steps were removed A draft revision is available. Sapan, Monday, 11:21 I am ok with the draft revision.
C1-202762	V2X USD provisioning	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202213 --------------------------------------------- Sapan, Friday, 15:33 1) In clause 7.2.3 – step a) – “the identity of theVAE-C” is used. As per my understanding – such identify is not defined. Which identify we are referring here? 2) Also for client to listen and accept HTTP connection – notification channel needs to be created. Christian, Tuesday, 17:29 To answer your comment 2) on notification channel. I wrote my CR based on stage 2, i.e. TS 23.286. the VAE server sends a request to the VAE client (V2X USD announcement). As we know, HTTP is a stateless protocol with request-response mechanism, and therefore there is not notification channel for HTTP (polling?). Christian, Wednesday, 10:42 I have produced a draft revision which addresses Sapan’s comment 1). Sapan, Wednesday, 21:34 Thanks for addressing comment 1). About 2), – I do understand that the proposal in this CR is based on SA6 specification only. My comment was – for VAE server to send HTTP request to VAE client, VAE server should act as HTTP client to initiate the HTTP connection and VAE client should act as HTTP server to accept the connection. Is this understanding correct? If yes, we need to mention this in the specification (may be in different CR). Christian, Thursday, 11:36 To accommodate comment 2), I have produced a new draft revision. Sapan, Thursday, 12:01 I am OK with the draft revision.
C1-202763	PC5 parameters provisioning	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202214 ------------------------------------------------ Sapan, Friday, 15:38 1) In clause 7.3.3 – step a) – “the identity of theVAE-C” is used. As per my understanding – such identify is not defined. Which identify we are referring here? 2) Also for client to listen and accept HTTP connection – notification channel needs to be created. Christian, Tuesday, 17:24 To answer your comment 2 on notification channel. I wrote my CR based on stage 2, i.e. TS 23.286. the VAE server sends a request to the VAE client. As we know, HTTP is a stateless protocol with request-response mechanism, and therefore there is not notification channel for HTTP (polling?). Christian, Wednesday, 10:42 I have produced a draft revision which addresses Sapan’s comment 1). Sapan, Wednesday, 21:33 Thanks for addressing comment 1). About 2), – I do understand that the proposal in this CR is based on SA6 specification only. My comment was – for VAE server to send HTTP request to VAE client, VAE server should act as HTTP client to initiate the HTTP connection and VAE client should act as HTTP server to accept the connection. Is this understanding correct? If yes, we need to mention this in the specification (may be in different CR). Christian, Thursday, 11:36 To accommodate comment 2), I have produced a new draft revision. Sapan, Thursday, 11:48 I am OK with the draft revision.
C1-202764	Structure and data semantics for V2X USD provisioning	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202215 ------------------------------------------------- Sapan, Friday, 16:05 1) In clause 8.5 – multiple references are used but not added in clause 2. 2) In clause 8.5 – “<frequency> is n optional element encoded as specified in 3GPP TS 29.468 [r29468].” => should be “an”. Christian, Tuesday, 15:36 A draft revision is available. Sapan, Wednesday, 21:14 I am OK with the draft revision.
C1-202765	Structure and data semantics for PC5 parameters provisioning	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202216 -------------------------------------------------- Sapan, Friday, 4:55 1) In clause 8.3 multiple new elements are defined but their data semantics are not defined in clause 8.5 (for ex: <authorized-when-not-served-by-E-UTRAN>, <radio-parameters-content>, <geographical-identifier>, etc) 2) In clause 8.5 – new references are used. Need to add references in reference clause 2. Christian, Tuesday, 15:55 A draft revision is available. Sapan, Wednesday, 21:16 I am OK with the draft revision.
C1-202766	MIME types	Huawei, HiSilicon /Christian	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202490 ---------------------------------------------- Sapan, Friday, 16:49 1) Clause 6.5.2.4 is defined twice – please correct the numbers. 2) In clause 6.2.1 - There is an extra ‘-‘ => VAE—info. Please remove it. Mikael, Tuesday, 14:14 Clause 6.7 is not included in the pCR but would need corresponding changes. I have 6.7 included in my C1-202238 and could do the changes, but I think it would be better to include in your C1-202490 to have all related corrections in the same paper. Christian, Tuesday, 15:08 I agree that it is better to keep the changes in C1-202490, so I’m revising the CR and add clause 6.7 to do the corresponding changes so all corrections are included in the same document. I will indicate when the revision is available on the 3GPP server. Christian, Tuesday, 15:26 A draft revision addressing Sapan and Mikael’s comments is available. Sapan, Wednesday, 9:42 I am fine with the draft revision. Mikael, Wednesday, 10:36 Draft revision looks good.
C1-202788	V2X UE registration procedure corrections	Ericsson / Mikael	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202235 ------------------------------------------------- Sapan, Friday, 16:41 Please revert correction related to MIME type as those corrections are already done in CR C1-202490 – which is proper. Mikael, Monday, 10:57 The MIME type alignments were included as current spec included the more specific types. We do however fully support and prefer the proposal to be more generic as in C1-202490. I will update my CRs accordingly. Mikael, Tuesday, 14:33 A draft revision is available. Sapan, Wednesday, 7:39 I am fine with the draft revision. Christian, Wednesday, 11:59 I am ok with the draft revision. I would like to co-sign it. Mikael, Wednesday, 12:23 I will add Huawei and HiSilicon as co-signers.
C1-202789	V2X UE de-registration procedure corrections	Ericsson / Mikael	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202236 ---------------------------------------------------- Sapan, Friday, 16:41 Please revert correction related to MIME type as those corrections are already done in CR C1-202490 – which is proper. Mikael, Monday, 10:57 The MIME type alignments were included as current spec included the more specific types. We do however fully support and prefer the proposal to be more generic as in C1-202490. I will update my CRs accordingly. Mikael, Tuesday, 14:33 A draft revision is available. Sapan, Wednesday, 7:39 I am fine with the draft revision. Christian, Wednesday, 11:59 I am ok with the draft revision. I would like to co-sign it. Mikael, Wednesday, 12:23 I will add Huawei and HiSilicon as co-signers.
C1-202790	V2X service discovery procedure corrections	Ericsson / Mikael	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202237 --------------------------------------------------- Sapan, Friday, 16:41 Please revert correction related to MIME type as those corrections are already done in CR C1-202490 – which is proper. In clause 6.6.2 – an element <service-discovery-data> is used but in clause 8.3 a <service-discovery-info> is defined. Please make is consistent. Mikael, Monday, 10:57 The MIME type alignments were included as current spec included the more specific types. We do however fully support and prefer the proposal to be more generic as in C1-202490. I will update my CRs accordingly. On elements in C1-202237, I do not fully understand your comment. In 6.6.2 both <service-discovery-info> and <service-discovery-data> are used. The <service-discovery-data> element may be included in a <service-discovery-info> element. This is reflected in 8.3: The <service-discovery-info> element shall include a <result> element and may include a <service-discovery-data> element. There is no definition of <service-discovery-data> in 8.3. Is that what you want to add? Sapan, Monday, 13:09 Yes, I was referring definition of <service-discovery-data> element only. Mikael, Tuesday, 14:33 A draft revision is available. Sapan, Wednesday, 7:39 I am fine with the draft revision. Christian, Wednesday, 11:59 I am ok with the draft revision. I would like to co-sign it. Mikael, Wednesday, 12:23 I will add Huawei and HiSilicon as co-signers.
C1-202791	V2X service continuity procedure corrections	Ericsson / Mikael	pCR 24.486 Rel-16	Current Status: Agreed Revision of C1-202238 ----------------------------------------------------- Sapan, Friday, 16:41 Please revert correction related to MIME type as those corrections are already done in CR C1-202490 – which is proper. Mikael, Monday, 10:57 The MIME type alignments were included as current spec included the more specific types. We do however fully support and prefer the proposal to be more generic as in C1-202490. I will update my CRs accordingly. Mikael, Tuesday, 14:33 A draft revision is available. Sapan, Wednesday, 7:39 I am fine with the draft revision. Christian, Wednesday, 11:59 I am ok with the draft revision. I would like to co-sign it. Mikael, Wednesday, 12:23 I will add Huawei and HiSilicon as co-signers.
eV2XARC	Lena – Breakout	CT aspects of eV2XARC
C1-202022	Incorrect reference	Ericsson / Ivo	CR 0001 24.587 Rel-16	Current Status: Agreed
C1-202105	NR PC5 unicast security policy provisioning	Qualcomm Incorporated / Lena	CR 0003 24.587 Rel-16	Current status: Postponed Christian, Monday, 8:41 the term defined under 3.1 is “NR-PC5”. Can you replace “NR PC5” then?; the text of the new bullet item “vi)” seems to imply that there are several policies but each entry in the list should provide one security policy so what about “vi) one or more geographical areas where the security policy entry applies”?; and with those changes we would like to co-sign the CR as we support it. Christian, Monday, 14:23 we agree that SA3 CRs have been agreed adding that, quote of TS 33.536 under clause 5.3.3.1.4.2.1: Security policy for PC5 link shall be provisioned for NR PC5 V2X communication as well. However, there are two editor’s notes and a NOTE under clause 5.3.3.1.4.2.3 on “Security policy handling” which I have now paid attention since they are not shown on the cover sheet of the CT1 CRs, quote: The list of V2X services, e.g. PSIDs or ITS-AIDs of the V2X applications, with Geographical Area(s) and their security policy which indicates the following: • Signalling integrity protection: REQUIRED/PREFERRED/OFF • Signalling confidentiality protection: REQUIRED/PREFERRED/OFF • User plane integrity protection: REQUIRED/PREFERRED/OFF • User plane confidentiality protection: REQUIRED/PREFERRED/OFF NOTE 1: No integrity protection on signalling traffic enables services that do not require security, e.g. emergency services. Editor’s note: Whether policy is OFF or NOT NEEDED is FFS Editor’s note: The security policy handling related part needs to be clearly defined. It is FFS that how the initiating UE and the receiving UE deal with the security policy, e.g., whether to accept the communication or not with their security policy and local policy in our understanding, the security requirements regarding security policy provisioning and handling are not crystal clear yet. This is obvious looking at the stage 2 specification on security (TS 33.536) which version is v1.0.0 so not approved yet and discussions and CRs are still ongoing. Now, I have found p-CRs from several companies (including Huawei) proposing to modify those initially added requirements to the draft version of TS 33.536 for example, updating the security policies and how they are handling, challenging NOTE1, and resolving the editor’s notes in different ways. Furthermore, I see that there are also discussion about (at least one related CR) this week in SA2 (#138E) on the impacts to the architecture and procedures because of the draft version 1.0.0 of TS 33.536; since the situation in both SA3 and SA2 is not crystal clear yet, TS 33.536 is not stable enough and CT1 are meeting in May, I would like to postpone the two CRs in C1-202105 and 2106 till the dust settles in both SA3 and SA2 so we know exactly what we need to do at stage 3 level in CT1. Andrew H, Monday, 15:09 Agree with Christian, It would probably be a good idea to postpone these CRs until it is clear what decisions have been taken by SA3. Lena, Tuesday, 9:00 The good news is that SA3 has made some agreements on UE security policy last week, and my understanding is that this should enable us to make progress at this meeting without necessarily waiting for the May meeting. Specifically: About (1) The Editor’s note stating “The security policy handling …” is no longer in the latest version of TS 33.536 (v0.3.0, available in S3-200528) The Editor’s note stating “Whether policy is OFF or NOT NEEDED is FFS” has been removed by S3-200690 agreed in SA3 last week (SA3 decided to change “OFF” to “NOT NEEDED”) About (2) Several agreements in SA3 on UE security policy were made last week and our understanding is that C1-202105 and C1-202106 are inline with these agreement. We are not aware of any open items regarding the UE security policy parameters provisioning and their values. If there are any issues which are still unclear, it would be very beneficial if you could point at what these are. Then we could consider addressing them with Editor’s notes. About (3) C1-202105 and C1-202106 are not about what the UE does with the UE security policy, but about what parameters are in the policy and how they are encoded. I believe the SA3 aspects for these are finalized (the last remaining open item was this “OFF” vs “NOT NEED” question which was settled last week as mentioned above). So I do not really what will change between now and the May meeting, and my preference would be to proceed with the CRs. In light of the above, I have prepared the following draft revisions with the following changes: Updated reason for change with latest SA3 agreement Changed “NR PC5” to “NR-PC5” Changed “where the policies apply” to “where the NR-PC5 unicast security policy applies” Christian, Wednesday, 14:57 Agree that progress was achieved but the thing is that I have checked TS 33.536 v1.0.0 (yes, which is v.0.3.0 sent for information) together with a number of p-CRs submitted and discussed last SA3 meeting (#98-bis-e) which challenge requirements under clause 5.3.3.1.4.2 on “Security policy” (e.g., S3-20072, S3-200790). The p-CR from us was noted so the discussions seem to be continued next meeting. There are further discussion this week at the SA2 meeting also on security policy and its impacts on architecture as you may be aware of. I am sorry but it seems that the requirements are not carved in stone on security policy yet. Furthermore, not only does security policy impact the UE but also the PCF, all this also might need to be checked with CT3 experts too. I believe that it is sensible for us, stage 3 (CT1), to wait for stable requirements and the group will benefit on waiting for the next meeting. Lena, Wednesday, 16:37 Thanks for your additional feedback. I checked again with my SA3 colleague and the p-CR from Huawei proposing to mandate security for the PC5 unicast link was noted in SA3 last week because there was no support for the proposal. There is no expectation that the discussion will continue in SA3 next meeting, and the requirements on security policy provisioning remain in TS 33.536. Hence C1-202105 & C1-202106 are fully aligned with the current SA3 requirements. Based on the above, I don’t think anything will change between now and May. That said, since SA3 meets well ahead of CT1 (SA3#99e takes place May 11-15), I can reluctantly accept to postpone C1-202105 & C1-202106 to see if anything changes in SA3 during their May meeting. To enable C1-202104 to progress, I will update the draft revision of C1-202104 to remove items related to UE signaling security policy and replace them by Editor’s notes. Christian, Thursday, 11:48 I do appreciate that we wait-and-see for stage 2 completing and stabilizing their work before we make a decision in our next meeting. Do not doubt that as rapporteur of the work, we support to complete this remaining work by the next CT plenary.
C1-202106	NR PC5 unicast security policy provisioning	Qualcomm Incorporated / Lena	CR 0001 24.588 Rel-16	Current status: Postponed Ivo, Friday, 15:39 We need to specify how the UE treats the spare values Christian, Monday, 8:50 we support the CR as the related one in C1-202105 but as we add the “NR-PC5”, which is defined by TS 24.587, this has to be indicated under clause 3.1; with that change we would like to co-sign the CR so that the NR-PC5 unicast link security policies can be provisioned to the UE by means of TS 24.588 so that the stage 2 requirements on security are added to stage 3 by CT1. Christian, Monday, 14:23 we agree that SA3 CRs have been agreed adding that, quote of TS 33.536 under clause 5.3.3.1.4.2.1: Security policy for PC5 link shall be provisioned for NR PC5 V2X communication as well. However, there are two editor’s notes and a NOTE under clause 5.3.3.1.4.2.3 on “Security policy handling” which I have now paid attention since they are not shown on the cover sheet of the CT1 CRs, quote: The list of V2X services, e.g. PSIDs or ITS-AIDs of the V2X applications, with Geographical Area(s) and their security policy which indicates the following: • Signalling integrity protection: REQUIRED/PREFERRED/OFF • Signalling confidentiality protection: REQUIRED/PREFERRED/OFF • User plane integrity protection: REQUIRED/PREFERRED/OFF • User plane confidentiality protection: REQUIRED/PREFERRED/OFF NOTE 1: No integrity protection on signalling traffic enables services that do not require security, e.g. emergency services. Editor’s note: Whether policy is OFF or NOT NEEDED is FFS Editor’s note: The security policy handling related part needs to be clearly defined. It is FFS that how the initiating UE and the receiving UE deal with the security policy, e.g., whether to accept the communication or not with their security policy and local policy in our understanding, the security requirements regarding security policy provisioning and handling are not crystal clear yet. This is obvious looking at the stage 2 specification on security (TS 33.536) which version is v1.0.0 so not approved yet and discussions and CRs are still ongoing. Now, I have found p-CRs from several companies (including Huawei) proposing to modify those initially added requirements to the draft version of TS 33.536 for example, updating the security policies and how they are handling, challenging NOTE1, and resolving the editor’s notes in different ways. Furthermore, I see that there are also discussion about (at least one related CR) this week in SA2 (#138E) on the impacts to the architecture and procedures because of the draft version 1.0.0 of TS 33.536; since the situation in both SA3 and SA2 is not crystal clear yet, TS 33.536 is not stable enough and CT1 are meeting in May, I would like to postpone the two CRs in C1-202105 and 2106 till the dust settles in both SA3 and SA2 so we know exactly what we need to do at stage 3 level in CT1. Lena, Tuesday, 9:00 The good news is that SA3 has made some agreements on UE security policy last week, and my understanding is that this should enable us to make progress at this meeting without necessarily waiting for the May meeting. Specifically: About (1) The Editor’s note stating “The security policy handling …” is no longer in the latest version of TS 33.536 (v0.3.0, available in S3-200528) The Editor’s note stating “Whether policy is OFF or NOT NEEDED is FFS” has been removed by S3-200690 agreed in SA3 last week (SA3 decided to change “OFF” to “NOT NEEDED”) About (2) Several agreements in SA3 on UE security policy were made last week and our understanding is that C1-202105 and C1-202106 are inline with these agreement. We are not aware of any open items regarding the UE security policy parameters provisioning and their values. If there are any issues which are still unclear, it would be very beneficial if you could point at what these are. Then we could consider addressing them with Editor’s notes. About (3) C1-202105 and C1-202106 are not about what the UE does with the UE security policy, but about what parameters are in the policy and how they are encoded. I believe the SA3 aspects for these are finalized (the last remaining open item was this “OFF” vs “NOT NEED” question which was settled last week as mentioned above). So I do not really what will change between now and the May meeting, and my preference would be to proceed with the CRs. In light of the above, I have prepared the following draft revisions with the following changes: Updated reason for change with latest SA3 agreement Added reference to definition of NR-PC5 in TS 24.587 in subclause 3.1 Changed “NR PC5” to “NR-PC5” Changed “off” to “not required” for security policy code points Added a description of how the UE handle spare values Lena, Tuesday, 9:02 I have taken onboard Ivo’s comments in a draft revision. Christian, Wednesday, 14:57 Agree that progress was achieved but the thing is that I have checked TS 33.536 v1.0.0 (yes, which is v.0.3.0 sent for information) together with a number of p-CRs submitted and discussed last SA3 meeting (#98-bis-e) which challenge requirements under clause 5.3.3.1.4.2 on “Security policy” (e.g., S3-20072, S3-200790). The p-CR from us was noted so the discussions seem to be continued next meeting. There are further discussion this week at the SA2 meeting also on security policy and its impacts on architecture as you may be aware of. I am sorry but it seems that the requirements are not carved in stone on security policy yet. Furthermore, not only does security policy impact the UE but also the PCF, all this also might need to be checked with CT3 experts too. I believe that it is sensible for us, stage 3 (CT1), to wait for stable requirements and the group will benefit on waiting for the next meeting. Lena, Wednesday, 16:37 Thanks for your additional feedback. I checked again with my SA3 colleague and the p-CR from Huawei proposing to mandate security for the PC5 unicast link was noted in SA3 last week because there was no support for the proposal. There is no expectation that the discussion will continue in SA3 next meeting, and the requirements on security policy provisioning remain in TS 33.536. Hence C1-202105 & C1-202106 are fully aligned with the current SA3 requirements. Based on the above, I don’t think anything will change between now and May. That said, since SA3 meets well ahead of CT1 (SA3#99e takes place May 11-15), I can reluctantly accept to postpone C1-202105 & C1-202106 to see if anything changes in SA3 during their May meeting. To enable C1-202104 to progress, I will update the draft revision of C1-202104 to remove items related to UE signaling security policy and replace them by Editor’s notes. Ivo, Wednesday, 20:27 Draft revision looks ok and Ericsson would like to co-sign. Christian, Thursday, 11:48 I do appreciate that we wait-and-see for stage 2 completing and stabilizing their work before we make a decision in our next meeting. Do not doubt that as rapporteur of the work, we support to complete this remaining work by the next CT plenary.
C1-202109	Introducing new messages for the Link Identifier Update procedure	InterDigital Communications	CR 0006 24.587 Rel-16	Current Status: Merged into C1-202186 and its revisions Tdoc was not available on time Lena, Friday, 2:34 Subclauses to describe when optional IEs are included are missing in clause 7 The corresponding procedure in subclause 6.1.2.5 needs to be updated to align with the actual message contents. For instance, subclause 6.1.2.5.2 says the UE shall include “the new security information” in the DIRECT LINK IDENTIFIER UPDATE REQUEST message. It should be replaced with “the MSB of KNRP-sess ID” The LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACCEPT message should not be optional, according to TS 33.536 subclause 5.3.3.2.2, the target UE shall include them. The LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACK message should not be optional, according to TS 33.536 subclause 5.3.3.2.2, the initiating UE shall include them The definition of the DIRECT LINK IDENTIFIER UPDATE REJECT message is missing Subclause 8.4.1 also needs to be modified Overlaps with vivo’s C1-202186 Overlaps with CATT’s C1-202547 Behrouz, Friday, 3:01 Answers to Lena’s comments in red: Subclauses to describe when optional IEs are included are missing in clause 7 [BA: I left them out on purpose as w are awaiting agreements in SA2] The corresponding procedure in subclause 6.1.2.5 needs to be updated to align with the actual message contents. For instance, subclause 6.1.2.5.2 says the UE shall include “the new security information” in the DIRECT LINK IDENTIFIER UPDATE REQUEST message. It should be replaced with “the MSB of KNRP-sess ID” [BA: I know, but those are all defined in my other CR, 2596] The LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACCEPT message should not be optional, according to TS 33.536 subclause 5.3.3.2.2, the target UE shall include them. [BA: In fact, I wanted to make it Mandatory, but the ongoing discussions in SA2 seem to make it optional!] The LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACK message should not be optional, according to TS 33.536 subclause 5.3.3.2.2, the initiating UE shall include them [BA: Same comment as above] The definition of the DIRECT LINK IDENTIFIER UPDATE REJECT message is missing [BA: See below] Subclause 8.4.1 also needs to be modified [BA: CATT’s CR has it so we can import that from there] Overlaps with vivo’s C1-202186 [BA: Yes, and it seems that Yanchao has defined the Reject message, so we will probably merge at some point. However, there are issues with other messages in her CR. Therefore, I prefer to just incorporate the Reject message from her CR into my revision] Overlaps with CATT’s C1-202547 [BA: Yes, but I have spotted several issues with CATT’s CR and will soon send out my comments!] Yanchao, Saturday, 10:58 The encoding of layer-2 ID is missing The definition of the DIRECT LINK IDENTIFIER UPDATE REJECT message is missing The PC5 signalling message types for the Link Identifier Update procedure are missing in clause 8.4.1 What is the reason for adding the following IEs in the link identifier update accept message New Source Layer 2 ID New Source user info New Source Link local IPv6 address And this paper conflicts with C1-202186 from vivo, which captures more aspects. Behrouz, Saturday, 21:00 Some of Yanchao’s comments are covered by my answers to Lena. The reject message from Yanchao’s CR can be incorporated in my CR. Behrouz, Tuesday, 2:48 I am ok to merge this CR into C1-202186 and co-sign the revision.
C1-202116	L2 ID of target UE used in the direct link establishment request	OPPO / Rae	CR 0008 24.587 Rel-16	Current status: Postponed Ivo, Thursday, 13:54 - "follwoing" - 6.1.2.2.2 - linkage between bullet 2) and bullets i) and ii) is not clear. Yanchao, Thursday, 16:09 What is the difference between C-2) and “known via prior V2X communication” in C-1? Lena, Friday, 2:39 Typo in 6.1.2.2.2: “follwoing" In 6.1.2.2.2, I don’t understand the combination of the condition “if the application layer provides the target UE's application layer ID and the link layer identifier for the target UE is valid” followed by bullet i) and ii). This needs to be clarified. In 6.1.2.2.2, “does not expire” should probably be “has not expired” The stage 2 requirement “When unicast Layer-2 ID is used, the Target User Info shall be included in the Direct Communication Request message” quoted in the CR coversheet is not covered in the changes I don’t think the text added in 6.1.2.2.4 adds any value. If the purpose is to mention that the pair of L2 ID for the link can be changed, I suggest just adding “until the pair of layer-2 IDs is changed during a PC5 unicast link identifier update procedure as specified in subclause 6.1.2.5” after “This pair of layer-2 IDs shall be associated with a PC5 unicast link context”. Rae, Monday, 5:24 I took all comments on board in a draft revision. Ivo, Monday, 23:00 my comment: - 6.1.2.2.2 - linkage between bullet 2) and bullets i) and ii) is not clear. is still not fully addressed. The revision now refers to "valid" without it being used anywhere. 2) the link layer identifier for the target UE is available to the initiating UE (e.g. via prior V2X communication, or obtained from the application layer). The link layer identifier for the target UE is considered as valid: i) if the link layer identifier for the target UE is also provided from the upper layers; or ii) if the validity timer of the link layer identifier for the target UE has not expired; is the intention to state the following? 2) a valid link layer identifier for the target UE is available to the initiating UE (e.g. via prior V2X communication, or obtained from the application layer). The link layer identifier for the target UE is considered as valid: i) if the link layer identifier for the target UE is also provided from the upper layers; or ii) if the validity timer of the link layer identifier for the target UE has not expired; and use "valid" also in later text? After the DIRECT LINK ESTABLISHMENT REQUEST message is generated, the initiating UE shall pass this message to the lower layers for transmission along with the initiating UE's Layer 2 ID for unicast communication and either the destination layer 2 ID used for unicast initial signaling or the valid target UE's destination layer 2 ID, and start timer T5000. The UE shall not send a new DIRECT LINK ESTABLISHMENT REQUEST message to the same target UE identified by the same application layer ID while timer T5000 is running. Chen, Tuesday, 4:31 There is no need to add a valid timer for the destination layer 2 ID. If the destination layer 2 ID is not valid, the direct communication would not be established and it is difficult to get the validity timer of the link layer identifier for the UE. And it conflicts the clause 6.1.2.5 PC5 unicast link identifier update procedure, the Layer 2 ID can be changed at any time based on the application layer. There are confusions between c)1) and c)2): The current specification statement “the link layer identifier for the unicast initial signaling (i.e. destination layer 2 ID used for unicast initial signaling) is available to the initiating UE (e.g. pre-configured, obtained as specified in clause 5.2.3 or known via prior V2X communication)” has included what the bullet c)2) states “the link layer identifier for the target UE is available to the initiating UE (e.g. via prior V2X communication, or obtained from the application layer)”. And in my understanding, “available” means the link layer identifier is already valid at least the initiating UE supposed. There is no need to add the words in this bullet c) : may include the target user info set to the target UE’s application layer ID if received from upper layers or shall include the the target user info set to the target UE’s application layer ID if received from upper layers and the link layer identifier for the target UE is used; please see C1-202316 About the last changes, I do share the same view with Lena that I don’t think the text added in 6.1.2.2.4 adds any value even if adding the words Lena suggested, which should not appear in the link establishment procedure. Rae, Tuesday, 5:16 About Chen’s comments: I think checking the L2 ID is valid or not by the initiating UE is useful under the case that “the link layer identifier for the target UE is available to the initiating UE (e.g. via prior V2X communication”. In the case, it is possible that the stored L2 ID has been abandoned or not valid in the perspective of the target UE while the initiating UE has no idea. If the initiating UE still uses the invalid L2 ID, the link establishment will fail. In my understanding, this also align with the intention of designing the PC5 unicast link identifier update procedure. And maybe the timer of updating L2 ID can be reused here. In addition, checking the L2 ID does not conflict with the PC5 unicast link identifier update procedure because this checking happens when UE wants to establish a new PC5 link with the same target UE. in my understanding, “available” just means the L2 ID is stored in the initiating UE while “valid” means the L2 ID can be used OK to not touch this bullet. for this change, I do not have a strong position. I just think the existing “onward” will give a view that L2 ID will not change. But if people think the change is not needed. I can live with not touching this subclause. Rae, Tuesday, 5:30 I will take Ivo’s suggestions on board. Chen, Tuesday, 6:04 - It is very difficult to get the validity timer of the layer 2 ID for the UE due to the privacy policy, and there is even no validity timer of the Layer-2 ID, according to clause 6.1.2.5.2.the upper layer can change the layer 2 ID at any time, quote: - There is not this validity timer in TS 23.287. - More comments inline. Rae, Tuesday, 8:55 I agree that if the L2 ID for target UE is not valid, the initiating UE will delete this L2 ID. But I think the issue is still there if the storage of the L2 ID on peer UEs does not match, which results the initiating UE cannot receive the response from the target UE and the establishment will be delayed. So I propose an FFS: Editor's note: how long the initiating UE stores the link layer identifier for target UE obtained via prior V2X communication is FFS. In my understanding, the existing L2 ID is associated with the unicast initial signaling and may associated with V2X service(s), but not with a specific UE. For the green highlighted part, the cases that the initiating UE gets the L2 ID for target UE is different from the cases for the existing LS ID. So the green highlighted is needed. If you still think it is confused, some suggested wording is very welcomed. Chen, Tuesday, 9:19 The Main problem is, adding the validity timer will destroy the privacy of the target UE, since stage 2 states the Layer 2 ID shall be changed over time so that the UE cannot be tracked. And there is no requirement for the validity timer in Stage 2. destination layer 2 ID used for unicast initial signaling has included the link layer identifier for the target UE. Rae, Tuesday, 9:52 For getting the L2 ID via prior communication, please note not for the existing communication, it is useful to specify how long the initiating UE stores the L2 ID. It does not destroy the privacy of the target UE and not impact the link identifier update procedure. Every time the initiating UE gets the new L2 ID, the timer will be reset. After the link is released and a new link is to be established, the target UE following the privacy may have deleted the L2 ID. In this case, the initiating UE cannot find the target UE when it still uses the stored L2 ID. It depends on how to understand “destination layer 2 ID used for unicast initial signaling”. I think there is no harm to make things (i.e. two kinds of L2 IDs) clear. This also aligns with stage 2. Chen, Tuesday, 10:05 Initiating UE can find the target UE during the valid time even if the unicast link is not needed. And the validity timer should not be added because there is no requirement in stage 2. TS 23.287 states explicitly on the destination layer 2 ID used for unicast initial signaling, quote clause 5.6.1.4: The initial signalling for the establishment of the PC5 unicast link may use the known Layer-2 ID of the communication peer, or a default destination Layer-2 ID associated with the V2X service type (e.g. PSID/ITS-AID) configured for PC5 unicast link establishment, as specified in clause 5.1.2.1 Lena, Wednesday, 23:37 The draft revision you provided addressed my comments, but I have the same concerns as Chen about the introduction of this link layer identifier validity timer. I would be ok with an Editor’s note instead. Chen, Thursday, 3:12 I would NOT be OK even if with an editor’s note. Rae, Thursday, 3:48 I think Xiaoguang also thinks that there is no need touching the existing “destination layer 2 ID used for unicast initial signaling” since it already covers the case using the L2 ID of target UE. If people also think same, I will postpone this CR.
C1-202159	Introducing NR PC5 functionality for EPC	LG Electronics / SangMin	discussion Rel-16	Current Status: Noted
C1-202165	Update to the V2X policies regarding RAN parameters	LG Electronics / SangMin	CR 0003 24.588 Rel-16	Current Status: Agreed
C1-202190	Requirements for groupcast over PC5	vivo	CR 0022 24.587 Rel-16	Current Status: Merged into C1-202119 and its revision Ivo, Thursday, 18:06 It would be more logical to have each parameter on a separate bullet, i.e. split bullet 2 to two bullets Lena, Friday, 3:08 This CR overlaps with OPPO’s C1-202119. Yanchao, Monday, 5:43 We are fine to merge C1-202190 into C1-202119.
C1-202205	Work plan for the CT1 part of eV2XARC	Huawei, HiSilicon /Christian	discussion Rel-16	Current Status: Noted
C1-202416	Discussion on maximum nbr of PC5 unicast links	Huawei, HiSilicon / Vishnu	discussion 24.587 Rel-16	Current Status: Noted
C1-202434	PC5 QoS flow establishment during the PC5 unicast link establishment procedure	Huawei, HiSIlicon / Vishnu	CR 0030 24.587 Rel-16	Current Status: Merged into C1-202745 and its revisions Ivo, Thursday, 18:07 6.1.2.2.4 - bullet c) iv contains full stop (instead of semicolon) before "and" - why is creation of the PC5 QoS flow(s) optional? Shouldn't it be mandatory on a condition as in the 1st quote in the reason for change? Lena, Friday, 4:30 This CR overlaps with vivo’s C1-202188 which puts the text in a different subclause. I prefer vivo’s version as it does not mix matching of QoS flows with the signalling procedure between the UEs. Yanchao, Saturday, 11:10 Same opinion as Lena. The change here is the general description for creating PC5 QoS flows which can be applied after the completion of many other procedures, such as link establishment and modification. It would be better to use a separate subclause. Also please see the following detailed comments: clause 6.1.2.2.4, for the bullet d), the PC5 unicast link ID as one of parameters to lower layers is missing clause 6.1.2.2.4, for the bullet d), PQFI->PQFI(s) Vishnu, Tuesday, 10:39 We agree in principle (about PC5 QoS flow establishment) to this CR but we have some concerns. We understand that we have such a common sub clause in 23.287 for the QoS flow establishment, but when we come to stage 3, we need to define each procedure and the PCQ QoS flow establishment is not the same for each. So we don’t think a common sub clause can be used. Eg: As proposed in our CR, for the link establishment procedure, the QoS flow establishment is part of the link establishment. Target UE and destination UE exchange the QoS parameters and then establish the QoS flow when they are successful. For the Link modification procedure , if the service data or request don’t have a matching PQFI, then the Flow is created. So in the new sub clause you added, when we say “if service data or request” it is more applicable for the link modification procedure and cannot be directly referred to in the link establishment procedure. Another reason is that in the new sub clause it says: “If there is no PC5 QoS rules for the existing PC5 QoS flow(s) matching the service data or request, the UE derives PC5 QoS parameters based on the V2X application requirements provided by the upper layers (if available) and the V2X service type (e.g. PSID or ITS-AID) according to the PC5 QoS mapping rules defined in clause 5.2.3 and perform the following:” This is not correct, because if there is no unicast link existing, then the UE needs to establish a unicast link first and then PC5 QoS flow. So we believe that we will have to change this sub clause for each link procedure. Considering this , we like to keep C1-202434 to clarify PC5 QoS flow establishment during direct link establishment procedure. Yanchao, Tuesday, 17:09 To Vishnu: we believe the matching of QoS flows and the PC5 signalling procedure should be specified separately, which will construct a TS with clear logic and structure. Secondly, I don’t agree with what you said “when we say “if service data or request” it is more applicable for the link modification procedure and cannot be directly referred to in the link establishment procedure.” It doesn’t make sense. It is a general scenario describing there is service data or request from upper layer. 3rd, the UE can create a PC5 QoS flow via either the PC5 link modification procedure or the PC5 link establishment procedure, which procedure to choose depends on where the PC5 link that the UE needs exists or not. 4th, the following statement is not correct, and you have an misunderstanding here. “If there is no PC5 QoS rules for the existing PC5 QoS flow(s)”, the UE may choose to establish a new PC5 unicast link, or the UE may choose to create an PC5 QoS flow in the existing PC5 unicast link. That is exactly the reason why the match of QoS flows should be specified as a generic subclause. There we think C1-202434 is not needed. Vishnu, Tuesday, 17:40 To Yanchao: we are not against you CR, but with the current wordings in the subclause it will be difficult to refer it from various procedures. As a way forward, we like to propose to you: You update the new subclause as suggested below, then QoS flow match (if needed) can be done in the respective procedures. Then we can use this subclause in our CR. 6.1.2.X PC5 QoS flow match and establishment over PC5 unicast link When service data or request from the upper layers is received, the UE determines if there is any existing PC5 QoS flow(s) matching the service data or request, i.e. based on the PC5 QoS rules for the existing PC5 QoS flow(s). If there is no PC5 QoS rules for the existing PC5 QoS flow(s) matching the service data or request, the UE derives PC5 QoS parameters based on the V2X application requirements provided by the upper layers (if available) and the V2X service type (e.g. PSID or ITS-AID) according to the PC5 QoS mapping rules defined in clause 5.2.3 and perform the following: Yanchao, Wednesday, 11:25 The change only describes the initiating UE’s behavior. The target UE could also use the established PC5 link and PC5 QoS flows to transmit V2X service data. (By the way, this is another reason why a generic subclause is more approapirate) Bullet a) and bullet b) is about constructing a PC5 unicast link context, which has already been cover by our paper in C1-202181(2181 covers both the initiating UE and the target UE); Bullet c) is about setting up a PC5 QoS rule, which has been covered about our paper in C1-202188 in bullet a-3) Bullet d) is about passing parameters to lower layer, however : the “source layer-2 ID and the destination layer-2 ID” has already been covered by Lena’s paper in C1-202104, see “After the DIRECT LINK ESTABLISHMENT ACCEPT message is generated, the initiating UE shall pass this message to the lower layers for transmission along with the initiating UE's layer 2 ID for unicast communication, the target UE's layer 2 ID for unicast communication and an indication that the PC5 signalling message is protected” the PQFI and the PC5 QoS parameters is has already been covered by our paper in C1-202181 (2181 covers both the initiating UE and the target UE) Therefore I think C1-202434 can be merged into C1-202181/ C1-202104. Vishnu, Wednesday, 12:46 To Yanchao: we are fine to merge our CR into yours. What about my comments on editing the text in your CR? Yanchao, Wednesday, 13:21 I am a little confused about Vishnu’s comment. The last paragraph of the change in C1-202188 described the UE behavior when UE found a match between the existing PC5 QoS flow and the service data or request. So I don’t understand why you propose to delete the text? Vishnu, Wednesday, 14:49 Looks like you have a misunderstanding about what our CR is doing. Our CR intends to clarify that the QoS Flows can be established as part of the Unicast link establishment procedure without doing a QoS flow match based on incoming request/data one more time. So in the new subclause the QoS flow matching is not needed. Otherwise it gives a feeling that after the unicast link is established , the QoS flow is established with additional request/data from upper layer. This is not the intention of our CR. If you cannot agree to this, I am afraid, we cannot agree to your CR and to the merging. Yanchao, Wednesday, 14:59 How about this: I split the change in my CR into two subclause: One subclause is “PC5 QoS flow match” One subclause is “PC5 QoS flow establishment over PC5 unicast link” Vishnu, Wednesday, 15:12 That is fine with us and use the subclause “PC5 QoS flow establishment over PC5 unicast link” for our changes.
C1-202438	Resolution of editor's note under 5.2.3	Huawei, HiSilicon /Christian	CR 0031 24.587 Rel-16	Current Status: Agreed
C1-202439	Resolution of editor's note under 6.1.2.5.2	Huawei, HiSilicon /Christian	CR 0032 24.587 Rel-16	Current Status: Agreed
C1-202453	Miscellaneous corrections	Huawei, HiSilicon /Christian	CR 0033 24.587 Rel-16	Current Status: Agreed
C1-202547	Direct link identifier update procedure messages definition and IEs coding	CATT	CR 0038 24.587 Rel-16	Current Status: Merged into C1-202186 and its revisions. Ivo, Thuesday, 18:07 "SL-DestinationIdentity clause 6.3.5 of 3GPP TS 38.331 [11]" - IMO, SL-DestinationIdentity defined in clause 6.3.5 of 3GPP TS 38.331 [11] is not a IE according to 24.007. IMO, it would be better to define a type-3 IE with V format in 24.587, with value containing SL-DestinationIdentity according to clause 6.3.5 of 3GPP TS 38.331 [11]. it would be clearer definition from 24.007 point of view. Lena, Friday, 4:35 Overlaps with InterDigital’s C1-202109 and vivo’s C1-202 Is missing subclauses describing when optional IEs are included in clause 7 The security information should not be TBD, SA3 has already agreed that the initiating UE sends the new MSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE REQUEST message, that the target UE sends back the MSB of KNRP-sess ID and the LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACCEPT message, and that the initiating UE sends the LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER ACK message, see TS 33.536 subclause 5.3.3.2.2 except when referring to the new IE, “Layer-2 ID” should be “layer-2 ID” to be consistent with the changes proposed in Huawei’s C1-202453 Behrouz, Friday, 4:58 High level comment: This CR should be merged with vivo’s 2186 and our 2109 For the Request message The names of several IEs are wrong; also Security info should be LSB as defined in SA3 For the New Layer-2 ID, you cannot refer to 38.331 in the Type/Reference column For the Accept message Several IEs are missing The new target security info should be the MSB The word “UE” in New Target UE info should be “user” Same comment as above for Type/Reference column For the ACK message The word “Acknowledgment” should change to “ack” in 7.3.Z All IEs after the Sequence Number should be “Optional” (awaiting ongoing SA2 discussions and decisions) Security Info should be LSB Address/Prefix should be removed from the last IE Yanchao, Saturday, 11:03 in table 7.3.x.1.1, I prefer to define our own NAS IE for Layer 2 ID, not just refer to RAN specs for a NAS IE coding . in Table 7.3.x.1.1, the presence of New initiating UE info should be O in Table 7.3.y.1.1, the presence of New target UE Layer 2 ID and New target UE security information should be O in Table 7.3.z.1.1, the presence of New target UE Layer 2 ID and New target UE security information should be O no definition of the DIRECT LINK IDENTIFIER UPDATE REJECT message
C1-202639	Add the missing figure for UE-requested V2X policy provisioning procedure	OPPO / Rae	CR 0007 24.587 Rel-16	Current Status: Agreed Revision of C1-202115 Ivo, Tuesday, 13:52 I am ok with C1-202639. If you revise it again, could you please add Ericsson as co-signer? Lena, Wednesday, 23:25 I am OK with C1-202639. ------------------------------------------------------------- Ivo, Thursday, 13:54 The figure needs to be referenced from the text - e.g. "(see example in figure xxxxx)" Lena, Friday, 2:36 The changes in the CR are ok but the CR should be Cat F, not Cat D. Rae, Monday, 5:21 I have taken comments from both Ivo and Lena on board in a draft revision. Ivo, Monday, 22:53 I suggest to add the reference to the figure in "In order to initiate the UE-requested V2X policy provisioning procedure, the UE shall create a UE POLICY PROVISIONING REQUEST message (see example in figure 5.3.2.2.1)." rather than to the bullet d). Reason: this sentence is start of the procedure. Chen, Tuesday, 3:51 In the Summary of change of the cover page, “In” -> “in” Rae, Tuesday, 4:26 I will reflect all the comments in a revision of this CR.
C1-202704	Non-standadized QoS characteristics over PC5-S	OPPO / Rae	CR 0009 24.587 Rel-16	Current Status: Agreed Revision of C1-202117 Lena, Thursday, 1:08 I am OK with C1-202704. ------------------------------------------------ SangMin, Friday, 5:27 Intent of the CR is okay, but Default averaging window (0DH, newly added) and Averaging window (06H, existing) seem redundant, so default averaging window seems not needed to be added. I also think that some spare values would be beneficial. Also what is the reason for removing the following text? The network shall consider all other values not explicitly defined in this version of the protocol as unsupported. Lena, Sunday, 20:05 For the Resource type and Default priority level, it would be beneficial to make some of the unused code points spare, instead of making them all reserved (just in case new Resource types or Default priority levels are defined in future releases). Rae, Monday, 4:07 @Lena I will change “Reserved” to “Spare” except the value "00000000”. @Sangmin I will remove the “Default averaging window”. For the removed sentence, since the parameters are transmitted over PC5-S, then there is no “network”. After a second thinking, how about changing “network” to “UE”? Chen, Tuesday, 4:49 In principle, it aligns with the PC5 QoS characteristics defined by TS 23.287 so it is needed. But I do not understand the removal of "The network shall consider all other values not explicitly defined in this version of the protocol as unsupported". Rae, Tuesday, 4:53 For the removed sentence, since the parameters are transmitted over PC5-S, then there is no “network”. After a second thinking, how about changing “network” to “UE”? Rae, Wednesday, 4:10 A draft revision is available. Changes: Change “Reserved” to “Spare” except the value "00000000” Remove default averaging window; "The network UE shall consider all other values not explicitly defined in this version of the protocol as unsupported". Change the value of new parameters to align with the revision of C1-202118 where some values are removed. SangMin, Wednesday, 5:24 This revision addresses my previous comment on averaging window. And also not I understand the reason for removing texts, and I agree to replace “network” to “UE”. SO I’m okay with this draft revision.
C1-202708	Group size and menber ID from application layer for groupcast	OPPO / Rae	CR 0011 24.587 Rel-16	Current Status: Agreed Revision of C1-202119 --------------------------------------------------- Ivo, Thursday, 16:39 - "optianl" -> "optional" - "optianlly" -> "optionally " - "whichi" -> "which" Lena, Friday, 2:47 Stage 2 says “NOTE: The mechanism for converting the V2X application layer provided group identifier to the destination Layer-2 ID is defined in Stage 3” but subclause 6.1.4.2.1.2 does not address that. It says “if group identifier information is provided and there is no context for the group identifier information, then UE shall use the destination layer-2 ID as specified in clause 6.1.4.2.1” but there is not text in subclause 6.1.4.2.1 (subclause 6.1.4.2.1 is just a header for subclauses 6.1.4.2.1.1 and 6.2.4.2.1.2). How does the UE determine the destination layer 2 ID if there is no context for the group identifier information? Typo in 6.1.4.2.1.1: “optianlly” Typo in 6.1.4.2.1.2: “optianl” Overlaps with vivo’s C1-202190 Chen, Friday, 9:55 “the request from the upper layers may include” overlaps with “which is optionally provided in the request from upper layers” in the sub-bullet; Rae, Monday, 5:33 I took all comments on board in a draft revision. For the first comment from Lena, for the case “if group identifier information is provided and there is no context for the group identifier information”, I think the v2x service identifier with L2 ID mapping rule should be used. Lena, Wednesday, 23:55 I have the following issue with the draft revision: the UE just uses the destination layer-2 ID corresponding to the V2X service identifier, even if group identifier info is provided, which does not seem right. It is also not aligned with stage 2 which says: “OTE: The mechanism for converting the V2X application layer provided group identifier to the destination Layer-2 ID is defined in Stage 3”. So the expectation is that in stage 3, we will define some way for the UE to derive a destination layer-2 ID based on the group identifier information. This is current missing from stage 3. To resolve this, I propose to delete bullet 3) and replace it by the following Editor’s note: “Editor’s note: If group identifier information is provided and there is no context for the group identifier information, how the UE determines the destination layer-2 ID based on the group identifier information is FFS.” Rae, Thursday, 3:25 For the case in bullet 3), for now, I think UE has no choice but to use the L2 ID associated with a v2x service if there is no group identifier related context. But I am fine to remove this bullet and add the EN if people are also OK, as touching bullet 3) is not the intention of this CR. This CR aims to add the missing Group size and member ID. Another option is that we leave the bullet 3) as it is and the interested companies send a CR to the next meeting. Lena, Thursday, 4:44 My preference is to remove bullet 3) and add the EN. Rae, Thursday 11:12 In the uploaded version of the revision, I have added the EN.
C1-202730	Corection for the target user info in the DIRECT LINK ESTABLISHMENT REQUEST message	Huawei, HiSilicon / Chen	CR 0025 24.587 Rel-16	Current Status: Agreed Revision of C1-202316 ------------------------------------------------ Lena, Friday, 3:11 Subclause 7.3.1.2 also needs to be modified in a similar way. Chen, Friday Thanks Lena for your feedback. The draft revision with the modified subclause7.3.1.2 is available in the drafts folder. Lena, Wednesday, 23:12 I am OK with the draft revision.
C1-202731	Correction for the IP address configuration IE in the DIRECT LINK ESTABLISHMENT ACCEPT message	Huawei, HiSilicon / Chen	CR 0026 24.587 Rel-16	Current Status: Agreed Revision of C1-202317 ------------------------------------------------- Ivo, Thursday, 13:55 The conditions in the bullets are not opposite and in some situation, this might result into impossibility to select a value. Please remove "only" in c) 1). Chen, Friday, 5:33 Thanks Ivo for your advice. I agree with you that the “only” should be removed. Please see the draft revision in the drafts folder. Ivo, Friday, 2:11 I am ok with the draft revision and Ericsson would like to co-sign.
C1-202732	Correction for the link local IPv6 address IE in the DIRECT LINK ESTABLISHMENT ACCEPT message	Huawei, HiSilicon / Chen	CR 0027 24.587 Rel-16	Current Status: Agreed Revision of C1-202318 ---------------------------------------------------
C1-202739	Handling of link modification accept	vivo	CR 0014 24.587 Rel-16	Current Status: Agreed Revision of C1-202182 --------------------------------------------- Chen, Tuesday, 8:31 It is true that NAS needs to pass some information to AS when sending messages but I fail to understand why new paragraphs are added under clause 6.1.2.3.3. A new sentence needs to be added to the existing paragraph saying "The target UE shall provide the <xx> to lower layers". Having said that, I do not understand why the PC5 unicast link identifier(s) needs to be provided during PC5 unicast link modification procedure to lower layers as there is procedure for it defined, i.e., PC5 unicast link identifier update procedure. Also, note that in that procedure already are requirements of passing information to AS. Yanchao, Tuesday, 15:48 I can’t understand Chen’s comment. The paper is for PC5 link modification accept procedure, what he refers to is a different procedure. The PC5 QoS parameters are changed via the PC5 link modification accept procedure, shouldn’t the UE provide the added or modified PQFI(s) and corresponding PC5 QoS parameters to the lower layer. Please note that it is the PQFI(s) and corresponding PC5 QoS parameters provided to the lower layer, “provide xx along with PC5 link identifier” is just to identify which PC5 link that xx is related to. Chen, Wednesday, 4:25 I suggest to be aligned with TS 23.287, using “PC5 Link Identifier” with the first letter capitalized. Yanchao, Wednesday, 5:54 I check TS24.587, “PC5 link identifier” is used in subclause 6.1.2.9 without the first letter capitalized. Also please check Huawei’s paper C1-202453, wherein it changes “Layer-2 ID” to “layer-2 ID”. Chen, Wednesday, 6:06 OK with me. Please make sure these words aligned in all your related contributions, e.g., C1-202181, C1-202188, and etc.
C1-202741	Updates to link release procedure	vivo	CR 0016 24.587 Rel-16	Current Status: Agreed Revision of C1-202184 Lena, Thursday, 0:35 I am OK with C1-202741. -------------------------------------------------- Lena, Friday, 2:58 “Proposed” is not ok in “lack of resources for proposed link” since in this case the link is already established. I suggest changing it to “lack of resources for PC5 unicast link”. Yanchao, Tuesday, 5:59 The name of cause#5 is updated to “lack of resources for PC5 unicast link” in 6.1.2.4.2. The name of cause#5 is aligned in the table 8.4.9.1: PC5 signalling protocol cause information element as well. (new change in this revision) We also plan to submit a paper to align the name of cause#5 used in other procedures in next meeting. A draft revision is available.
C1-202742	Correction of the timers of link identifier update procedure	vivo	CR 0017 24.587 Rel-16	Current Status: Agreed Revision of C1-202185 Lena, Thursday, 0:42 I am OK with C1-202742. ---------------------------------------------- Lena, Friday, 3:01 We are fine with changes in the CR, but it would be good to take this opportunity to correct the style of second bullet d) in 6.1.2.5.2. Yanchao, Tuesday, 6:03 I fixed the style of the bullet, a draft revision is available.
C1-202743	Encoding of link identifier update messages and parameters	vivo	CR 0018 24.587 Rel-16	Current Status: Agreed Revision of C1-202186 --------------------------------------------------- Lena, Friday, 3:03 Overlaps with InterDigital’s C1-202109 Overlaps with CATT’s C1-202537 Is more complete than C1-202109 since its includes the DIRECT LINK IDENTIFIER UPDATE REJECT message, and the changes to subclause 8.4.1 Is missing subclauses describing when optional IEs are included in subclause 7 The security information should not be TBD, SA3 has already agreed that the initiating UE sends the new MSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE REQUEST message, that the target UE sends back the MSB of KNRP-sess ID and the LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACCEPT message, and that the initiating UE sends the LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER ACK message, see TS 33.536 subclause 5.3.3.2.2 except when referring to the new IE, “Layer-2 ID” should be “layer-2 ID” to be consistent with the changes proposed in Huawei’s C1-202453 Behrouz, Friday, 3:58 At a high level, I think we should merge your CR with my 2109 In the Request Message: Security Establishment Info should be “MSB…” [See 2109] IP Address Configuration is not needed In the Accept Message: Security Establishment Info: Which one is this? The MSB is Mandatory and the LSB is Optional in this message Layer-2 ID: Is this Source or Target? Target should be Mandatory! IP Address Configuration is not needed Link Local IPv6 address: There should be 2 of these; Source and Target In the Ack message Security Info should be the LSB Layer-2 ID should be Target IP Address Configuration is not needed Yanchao, Monday, 17:12 A draft revision is available with the following changes: Add missing subclauses describing when optional IEs are included in subclause 7； Add The security information IEs; Correct “Layer-2 ID” to “layer-2 ID” where needed; Delete IP Address Configuration, based on Behrouz’s comments About Behrouz’s comments I did not take onboard: I cannot agree to merge my CR in C1-202109 I don’t agree that the target layer-2 ID should be mandatory, I think the Target is optional based on current SA2 agreement I don't understand why the source IP is needed in the accept message only one layer 2-ID is included in each message(request, accept, ACK), it belongs to the UE who send the message, hence no need to mention “target” or “source” Behrouz, Tuesday, 2:48 When two CRs overlap (or 3 in this case), it is very customary to merge them. Unlike others, I do not have a very strong preference on “who merges with whom”. What matters is to complete the work and try to finalize the specification. Therefore, hoping that you are OK with this approach, I can merge my CR with yours and co-sign yours. As for certain IEs whether they should be optional or mandatory, this is what Lena commented on your (and my) CR: “The security information should not be TBD, SA3 has already agreed that the initiating UE sends the new MSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE REQUEST message, that the target UE sends back the MSB of KNRP-sess ID and the LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACCEPT message, and that the initiating UE sends the LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER ACK message, see TS 33.536 subclause 5.3.3.2.2” The LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACCEPT message should not be optional, according to TS 33.536 subclause 5.3.3.2.2, the target UE shall include them. The LSB of KNRP-sess ID in the DIRECT LINK IDENTIFIER UPDATE ACK message should not be optional, according to TS 33.536 subclause 5.3.3.2.2, the initiating UE shall include them So, do you still believe they should be optional? I guess, we will have to wait 1-2 days to decide exactly what IEs should be there in both Accept and ACK messages. Meanwhile, for the IEs that are optional, but are supposed to be included according to the procedure, I don’t think it is a good idea to say e.g. “This IE is included when the target UE decides to change its identifiers based on the privacy configuration…”. Instead, we should say something like “The UE shall include IE this to change its identifiers …” In 7.3.C: Change “acknowledgement” to “ack” I don’t think it is a good idea to use “initiating” and “target” UE in the message definition. Please use the same terminology as you have done for the Request and Accept messages. Yanchao, Tuesday, 16:23 -> Thank you -> My bad, fixed in draft revision Agree, I chose to use the wording “This IE is included when the target UE changes its layer-2 ID.” 4-a) OK 4-b) your question made me re-think this procedure: The initiating UE send its ID and info in the request message; The target UE respond with the ACCEPT message with the target UE’s ID and info; The initiating UE can just send an ‘empty’ ACK message for acknowledgement, why include any ID or info here in ACK message, they already shared information needed in the REQUEST message and ACCEPT message. So I updated the definition for the ACK message. A draft revision is available. Lena, Tuesday, 19:44 Regarding the new definition of the ACK message, it is not aligned with the latest version of TS 33.536 (v0.3.0, available in S3-200528): per TS 33.536 subclause 5.3.3.2.2, the ACK message includes both the LSB of K_NRP-sess ID and the target UE’s new layer-2 ID. So the target’s UE new layer-2 ID needs to be kept in the message. Yanchao, Wednesday, 10:27 Yes in TS 33.536 figure 5.3.3.2.2-1, the ACK message includes both the LSB of K_NRP-sess ID and the target UE’s new layer-2 ID. But the step 3 only describes the UE_1 shall send the Link Identifier Update Ack message to UE_2 including the LSB of KNRP-sess ID, not mention anything about the target UE’s new layer-2 ID. So my question is what is the purpose of including target UE’s new layer-2 ID in the Ack message? I will gather people’s opinion on the definition of the ACK message and will follow what most people want. Lena, Thursday, 7:57 My understanding is that the UE_1 replays the UE’s new Layer-2 ID in the ACK so UE_2 can check that the data has not been altered (just like UE_1 replays the MSBs of K_NRP-sess ID received from UE_2 in the ACK). Yanchao, Thursday, 10:25 An updated draft revision is available. Lena, Thursday, 10:39 I have the following comments: There is a comment in table 7.3.b.1.1 which will need to be removed before submission The IEs defined in C1-202104 (now revised to C1-202875) are LSBs of KNRP-sess ID and MSBs of KNRP-sess ID, not LSB of KNRP-sess ID and MSB of KNRP-sess ID. I think having an “s” is clearer, but I won’t argue over it at this point in the meeting. If you prefer to not add an “s” that is fine, we can have an interesting discussion in May on MSB/LSB vs MSBs/LSBs and then we harmonize the spec based on the outcome
C1-202744	Handling of link identifier update not accept	vivo	CR 0019 24.587 Rel-16	Current Status: Agreed Revision of C1-202187 Lena, Thursday, 0:46 I am OK with C1-202744. ------------------------------------------- Ivo, Thursday, 18:06 - NOTE 2 without NOTE 1. - "For other reasons that causing the failure of link establishment, " -> "For other reasons that cause the failure of link establishment, " or "For other reasons causing the failure of link establishment, " Lena, Friday, 3:04 “Layer 2 ID” should be “layer-2 ID” to be consistent with the changes proposed in Huawei’s C1-202453 NOTE 2 should be NOTE (only one note) “For other reasons that causing” should be “For other reasons causing Chen, Friday, 10:00 In “For other reasons that causing the failure of link establishment, the target UE shall send a DIRECT LINK ESTABLISHMENT REJECT message with PC5 signalling protocol cause value #111 "protocol error, unspecified", DIRECT LINK ESTABLISHMENT REJECT should be DIRECT LINK IDENTIFIER UPDATE REJECT Yanchao, Tuesday, 6:12 I have taken the comments onboard, a draft revision is available.
C1-202745	Handling of PC5 unicast QoS flow match and establishment	vivo	CR 0020 24.587 Rel-16	Current Status: Agreed Revision of C1-202188 Vishnu, Thursday, 11:32 I am OK with C1-202745. ---------------------------------------------------- Ivo, Thursday, 18:06 - bullet c: "UE" -> "the UE" - shouldn't the text be normative? If informative, it is not required to be implemented. Lena, Friday, 3:06 “and perform the following” -> “and performs the following” “with following operations” -> “by performing the following operations” “set up a new PC5 QoS rule, the PC5 QoS rule contains” -> “create a new PC5 QoS rule which contains” “to lower layers” -> “to the lower layers” “.” at the end of bullet a-4-iv) should be an “;’. “.” at the end of bullet b) should be “; and” In bullet c), “UE uses” -> “the UE uses” In bullet c), “the new created PC5 QoS flow as bullet a)” -> “the new PC5 QoS flow created as described in bullet a)” In bullet c), “as bullet b)” -> “as described in bullet b)” Overlaps with Huawei’s C1-202434. I have a preference for this CR as it does not mix matching of QoS flows with the signalling procedure between the UEs. Yanchao, Monday, 16:41 I took onboard all of Ivo and Lena’s comments in a draft revision. Ivo, Monday, 23:10 Nearly ok - "The UE" should be "the UE" in bullet c). Vishnu, Tuesday, 10:25 We agree in principle (about PC5 QoS flow establishment) to this CR but we have some concerns. We understand that we have such a common sub clause in 23.287 for the QoS flow establishment, but when we come to stage 3, we need to define each procedure and the PCQ QoS flow establishment is not the same for each. So we don’t think a common sub clause can be used. Eg: As proposed in our CR, for the link establishment procedure, the QoS flow establishment is part of the link establishment. Target UE and destination UE exchange the QoS parameters and then establish the QoS flow when they are successful. For the Link modification procedure , if the service data or request don’t have a matching PQFI, then the Flow is created. So in the new sub clause you added, when we say “if service data or request” it is more applicable for the link modification procedure and cannot be directly referred to in the link establishment procedure. Another reason is that in the new sub clause it says: “If there is no PC5 QoS rules for the existing PC5 QoS flow(s) matching the service data or request, the UE derives PC5 QoS parameters based on the V2X application requirements provided by the upper layers (if available) and the V2X service type (e.g. PSID or ITS-AID) according to the PC5 QoS mapping rules defined in clause 5.2.3 and perform the following:” This is not correct, because if there is no unicast link existing, then the UE needs to establish a unicast link first and then PC5 QoS flow. So we believe that we will have to change this sub clause for each link procedure. Considering this , we like to keep C1-202434 to clarify PC5 QoS flow establishment during direct link establishment procedure. Yanchao, Tuesday, 16:39 A draft revision is available with “The UE" changed to "the UE" in bullet c). Yanchao, Tuesday, 17:07 To Vishnu: we believe the matching of QoS flows and the PC5 signalling procedure should be specified separately, which will construct a TS with clear logic and structure. Secondly, I don’t agree with what you said “when we say “if service data or request” it is more applicable for the link modification procedure and cannot be directly referred to in the link establishment procedure.” It doesn’t make sense. It is a general scenario describing there is service data or request from upper layer. 3rd, the UE can create a PC5 QoS flow via either the PC5 link modification procedure or the PC5 link establishment procedure, which procedure to choose depends on where the PC5 link that the UE needs exists or not. 4th, the following statement is not correct, and you have an misunderstanding here. “If there is no PC5 QoS rules for the existing PC5 QoS flow(s)”, the UE may choose to establish a new PC5 unicast link, or the UE may choose to create an PC5 QoS flow in the existing PC5 unicast link. That is exactly the reason why the match of QoS flows should be specified as a generic subclause. Yanchao, Wednesday, 16:28 A draft revision is available. Vishnu, Wednesday, 17:06 The revision has not captured our CR well. We need to add the following statement as last paragraph to 6.1.2.2.3 If the target UE accepts the PC5 unicast link establishment request, then the target UE may establish the negotiated PC5 QoS flow(s) as specified in 6.1.2.X. Also we need to add the following statement as last paragraph in 6.1.2.2.4 In addition, the initiating UE may establish the negotiated PC5 QoS flow(s) as specified in 6.1.2.X Ivo, Wednesday, 20:38 Draft revision looks OK and Ericsson would like to cosign. Lena, Thursday, 0:24 The draft revision looks good except that “.” And the end of bullet a-3-iv) should be “; and”. Vishnu, Thursday, 10:20 Could Yanchao answer my comments? Yanchao, Thursday, 10:21 A draft revision is available. Vishnu, Thursday, 10:37 Almost OK. Please remove ‘and perform the PC5 QoS flow match over PC5 unicast link as specified in clause 6.1.2.Y’ from 6.1.2.2.3 and 6.1.2.2.4. Reason is that the UE can establish QoS flows based on negotiated QoS parameters without further QoS flow match. Ivo, Thursday, 10:48 My comments were addressed.
C1-202748	Introducing V2X communications over NR PC5 in EPC	LG Electronics / SangMin	CR 0024 24.386 Rel-16	Current Status: Agreed Revision of C1-202160 Vishnu, Thursday, 13:29 We are fine with C1-202748. If possible Huawei, HiSilicon would like to co-sign it. ------------------------------------------------- Lena, Friday, 2:49 About the terminology, TS 24.587 defined “NR-PC5” but also uses “NR based PC5”, while TS 23.287 uses “NR PC5”. To be consistent it would be good to use what is defined in TS 24.587 ie “NR-PC5” Typo in clause 1: “speicifies” In clause 1, rather than adding a paragraph below the bulleted list, why not just modify the existing bullet on PC5, as in “for V2X communication among the UEs (over the LTE PC5 interface and over the NR PC5 interface)”? In 5.2.4, “and” the end of bullet j) should be deleted and the “.” at the end of bullet h) should be replaced by a “;” In 5.2.4 bullet l), “for a V2X communication” should be “for V2X communication” SangMin, Monday, 10:00 -> OK -> OK -> OK -> the last comment seems to be on bullet k). Anyhow, I fixed all the editorial errors on bullets in 5.2.4. -> OK A draft revision is available. SangMin, Wednesday, 10:33 Updated draft revision is available. Changes: - Proposed to use the terminology "NR-PC5" for the consistency - In clause 1, modified existing bullets for specifying the scope of NR-PC5 instead of adding new paragraph. - Bullet 7) in clause 5.2.4 is aligned with the change proposed in CR0012 against TS 24.587. - Fixed vaious editorial errors Lena, Wednesday, 23:58 I am OK with the draft revision.
C1-202756	V2X MO update for V2X over NR PC5	LG Electronics / SangMin	CR 0021 24.385 Rel-16	Current Status: Agreed Revision of C1-202161 Vishnu, Thursday, 13:21 Could you add Huawei, HiSilicon as co-signers? ----------------------------------------------- Lena, Friday, 2:50 The DDF needs to be updated. About the terminology, TS 24.587 defined “NR-PC5” but also uses “NR based PC5”, while TS 23.287 uses “NR PC5”. To be consistent it would be good to use what is defined in TS 24.587 ie “NR-PC5” Rae, Friday, 7:59 I Suggest changing “UnicastDestinationLayer2ID”->“UnicastInitialSignallingDestinationLayer2ID”to avoid misunderstanding SangMin, Friday, 11:26 To Lena: regarding the DDF, the ddfclient tool didn’t work so I could not finish the xml coding in time. If if it is okay, I would like to submit the ddf update in the next meeting, based on the agreements of each nodes in this meeting. At least it should be clear on each parameters, nodes and their hierarchy in order to avoid re-writing the code.  Regarding the wording issue, I think “NR-PC5” seems to be a good way forward. So I’ll update all related papers with the terminology “NR-PC5” in the revisions (I’ll provide the draft after gathering some more comments). SangMin, Friday, 11:28 To Rae: changing the name of the node is okay for us. I’ll update it in the revision Lena, Saturday, 0:24 SangMin’s proposal to address my comments is ok. SangMin, Monday, 10:32 A draft revision is available taking all comments from Rae and lena onboard.
C1-202757	Indicating support of V2X over NR-PC5	LG Electronics / SangMin	CR 3344 24.301 Rel-16	Current Status: Agreed Revision of C1-202162 Vishnu, Thursday, 13:30 As Chen indicated we are fine with the CR. If possible Huawei, HiSilicon would like to co-sign it. --------------------------------------------- Lena, Friday, 2:51 About the terminology, TS 24.587 defined “NR-PC5” but also uses “NR based PC5”, while TS 23.287 uses “NR PC5”. To be consistent it would be good to use what is defined in TS 24.587 ie “NR-PC5”. SangMin, Monday, 10:38 I’m fine with using “NR-PC5” for consistency. A draft revision is available. Chen, Tuesday, 8:45 There seems to be confusion between the new added V2X NR-PC5 and the current V2X PC5. In my understanding, V2X PC5 is general and includes E-UTRAN PC5 and NR PC5. SangMin, Tuesday, 8:58 Changing an existing terminology “V2X PC5” to “E-UTRAN PC5” or “LTE PC5” would bring more confusion since it has been there since Rel-13. How about adding a definition for “V2X PC5” saying such as “V2X PC5 in this specification only refers V2X communication over LTE-PC5 interface,” or similar things? SangMin, Wednesday, 10:27 A draft revision is available. Change: cleaned up the use of “NR-PC5” terminology. clarified the condition of indicating “V2X PC5 bit” by adding “E-UTRA-“ to the condition and the descriptions of values. As I said changing the name of the bit is not desirable so the name of the bit is still “V2X PC5 bit”. Lena, Thursday, 0:01 I am OK with the draft revision. Chen, Thursday, 5:04 I am OK with the draft revision.
C1-202758	Clarifications on configuration parameters for the PC5 QoS profile	LG Electronics / SangMin	CR 0012 24.587 Rel-16	Current Status: Agreed Revision of C1-202163 Vishnu, Thursday, 13:31 We are fine with C1-202758. If possible Huawei, HiSilicon would like to co-sign it. ------------------------------------------------- Yanchao, Thursday, 16:12 The following change is strange, should the default value be used as last? v) the PC5 QoS profile can contain the priority level, the averaging window, and/or the maximum data burst volume if the default value for the corresponding parameter is not used Ivo, Thursday, 18:05 Bullet 7) - NOT OK to add "e.g." in "an AS configuration, e.g. a list of SLRB mapping rules" - adding "e.g." is OK for stage-2 but 24.587 is a stage-3 specification and we need to be precise what the AS configuration consists of. Lena, Friday, 2:55 The text in bullet v) of 5.2.3 seems ok as it is, the change is not needed. SangMin, Tuesday, 8:05 I’m not sure if I understand Yanchao’s concerns correctly. You are right that the default value should be used at last but it depends on the NW policy. If the NW decided to use the default value, these parameter values will not be included in this PC5 QoS profile. If the NW decided not to use them, then the values will be included. So the condition “if the default value for the corresponding parameter is not used” indicates when the NW should include these values. I hope this answers to your concerns. SangMin, Tuesday, 8:07 Ivo are you okay if I update the change bullet 7 using “including” instead of “e.g.”? 7) an AS configuration, including a list of SLRB mapping rules applicable when the UE is not served by E-UTRA and is not served by NR. Each SLRB mapping rule contains a PC5 QoS profile and an SLRB. The PC5 QoS profile contains the following parameters: SangMin, Tuesday, 8:17 To Lena: 1) about the first and second changes in the reason for change (regarding PC5 Link Aggregated Bit Rates and Range), there is no limitation described in TS 24.587 that these parameters should be only used in specific communication mode. Clause 5.2.3 is the only place where range and PC5 Link Aggregated Bit Rates is mentioned. So if we don’t describe any limitation in stage 3, the readers will assume that these parameters can be used regardless of the communication mode. 2) about the third change, as I responded to Yanchao, this is a condition to include these parameters in PC5 QoS profile by the network, so without this, stage 3 will be incomplete. 3) currently the AS configuration only has “SLRB mapping rules”, so the change might not be needed as is. However, SA2 updated the terminology for future use, so I guess using more generic name where other AS parameter than SLRB rule can be added in the future would be more beneficial and futureproof Ivo, Tuesday, 8:57 Yes, this would address my comments. Christian, Tuesday, 17:11 Can you please consider converting the new text you propose to add, quote “, which is only used for unicast mode communications over PC5” to a NOTE? Lena, Tuesday, 22:45 I only commented on the last change in the CR (to bullet v)). I have no problem with the other changes in the CR. About the change to bullet v), I basically see no difference between the existing text, and what you are proposing, plus I think the existing text is clearer. It already says that if the PC5 QoS profile does not contain a value for certain parameters, the default value is used. What more is needed? SangMin, Wednesday, 8:55 To Christian: OK to convert the quoted text into a NOTE, i.e. NOTE: PC5 Link Aggregated Bit Rate is only used for unicast mode communications over PC5 SangMin, Wednesday, 9:09 To Lena: I still believe that current text is not clear. However since you (and also Yanchao) are not so happy about the proposed change in bullet v), I can live without the change. So I will remove the change. A draft revision is available.
C1-202760	Clarifications on the V2X policies regarding QoS	LG Electronics / SangMin	CR 0002 24.588 Rel-16	Current Status: Agreed Revision of C1-202164 Vishnu, Thursday, 13:32 We are fine with C1-202760. If possible Huawei, HiSilicon would like to co-sign it. ------------------------------------------------ Ivo, Thursday, 18:05 Not aligned with C1-202163 which still refers to "SLRB mapping rules". Either keep "SLRB mapping rules" here or align C1-202163 to refer to "AS configuration mapping rules" SangMin, Tuesday, 8:21 To Ivo: if C1-202163 cannot survive, then I have to revert the “SLRB” related changes and only an editorial fix will remain. But anyhow I’ll align the terminologies in two CRs in the revision. Sang Min, Wednesday, 9:35 I found the reason for the inconsistency in terminology. I see 2 options: 1) reverting changes on “SLRB mapping rule” from this CR and leaving it as is, or 2) changing the structure of SLRB mapping rules to be nested in new intermediate clause for “AS configuration”. Which one is preferred? Ivo, Wednesday, 23:52 Technically, both of the below is possible. The 2nd option is better aligned with the last revision of C1-202164. SangMin, Thursday, 8:10 A draft revision is available. I reverted original changes, and added new “AS configuration” parameter instead of SLRB mapping rules in the config. parameter for PC5. SLRB mapping rules parameter is nested in AS configuration. Also I updated octet number accordingly. Also the CR in C1-202756 (was C1-202161) on NAS MO will be updated aligning with this CR. Ivo, Thursday, 10:16 I am OK with the draft revision and Ericsson would like to co-sign.
C1-202767	Correction to the privacy timer	Huawei, HiSilicon /Christian	CR 0024 24.587 Rel-16	Current Status: Agreed Revision of C1-202226 ----------------------------------------------- Yanchao, Thursday, 16:21 Two while in the change in the table: “Upon T5020 expiration while while” Lena, Friday, 3:10 The CR is fine except for “while while” in table 10.4.1. Christian, Tuesday, 14:40 A draft revision addressing the comments is available. Lena, Thursday, 0:56 I am OK with the draft revision.
C1-202768	Resolution of editor's note under 6.1.2.3.6	Huawei, HiSilicon /Christian	CR 0034 24.587 Rel-16	Current Status: Open Questions Is Ivo OK with C1-202768? Revision of C1-202455 ---------------------------------------------- Ivo, Thursday, 13:55 For good interoperability, the handling should not be implementation specific. Lena, Friday, 4:32 typo (“initiaing”) “during the initiating UE-requested PC5 unicast link modification procedure” should be “during the PC5 unicast link modification procedure” (there is no “UE-requested PC5 unicast link modification procedure”) Christian, Tuesday, 10:40 A draft revision is available. About Ivo’s comment, I believe that there is some misunderstanding about what the proposal actually is. Please, note that this is a very rare abnormal case (race condition) and the proposal is in fact not left to implementation but it is solved, i.e. “the initiating UE shall abort the PC5 unicast link modification procedure”. What we propose to leave to implementation is “the following handling” and we provide an example of what the UE could do but all depends on the current situation in the UE after the procedure is aborted Ivo, Wednesday, 20:47 If I understand the CR correctly, the added case is for situation when both UEs initiate DIRECT LINK MODIFICATION REQUEST at the same time. In such case, both UEs abort the procedure and are supposed to perform implementation dependent handling, e.g. wait for implementation dependent time. What will happen when both UEs select the same implementation dependent time? Wouldn't the problem occur again? it would be more logical if one of the UE waits longer time than the other. Christian, Thursday, 11:41 I am not sure what the problem is actually or what behaviour you would like to have instead. The implementation dependent time is random as any implementation can choose a different one, if they finally the very same procedure is (re-)started. Furthermore, different initiating UE can decide to do differently than (re-)start the procedure as that would depend on the current situation in the UE after the abortion of the procedure. Additionally, the very same description exists for other NAS protocols and I have not heard of resulting in problems.
C1-202769	Resolution of the editor's note under 6.1.2.5.7.2	Huawei, HiSilicon /Christian	CR 0035 24.587 Rel-16	Current Status: Open Questions Is Ivo OK with C1-202769? Revision of C1-202456 ------------------------------------------- Ivo, Thursday, 13:55 For good interoperability, the handling should not be implementation specific. Lena, Friday, 4:33 Coversheet needs update as it refers to link modification procedure but the abnormal case handling is added for the link identifier update procedure “procedure procedure” in 6.1.2.5.7.1 “initiaing” in 6.1.2.5.7.1 “a new PC5 unicast link update procedure” should be “a new PC5 unicast link identifier update procedure” Christian, Tuesday, 14:22 A draft revision is available. About Ivo’s comments, I believe that there is some misunderstanding about what the proposal actually is. Please, note that this is a very rare abnormal case (race condition) and the proposal is in fact not left to implementation but it is solved, i.e. “the initiating UE shall abort the PC5 unicast link identifier update procedure”. What we propose to leave to implementation is “the following handling” and we provide an example of what the initiating UE could do but all depends on the current situation in the initiating UE after the procedure is aborted. Ivo, Wednesday, 20:48 If I understand the CR correctly, the added case is for situation when both UEs initiate DIRECT LINK IDENTIFIER UPDATE REQUEST at the same time. In such case, both UEs abort the procedure and are supposed to perform implementation dependent handling, e.g. wait for implementation dependent time. What will happen when both UEs select the same implementation dependent time? Wouldn't the problem occur again? it would be more logical if one of the UE waits longer time than the other. Lena, Thursday, 0:55 I am OK with the draft revision. Christian, Thursday, 11:43 I am not sure what the problem is actually or what behaviour you would like to have instead. The implementation dependent time is random as any implementation can choose a different one, if they finally the very same procedure is (re-)started. Furthermore, different initiating UE can decide to do differently than (re-)start the procedure as that would depend on the current situation in the UE after the abortion of the procedure. Additionally, the very same description exists for other NAS protocols and I have not heard of resulting in problems.
C1-202773	Timer values for timers of PC5 unicast link management procedures	Huawei, HiSilicon /Christian	CR 0023 24.587 Rel-16	Current Status: Agreed Revision of C1-202598 ------------------------------------------------------ Revision of C1-202225 Lena, Monday, 0:49 We are ok with setting the timer values to 5 sec for timers other than T5005. Regarding T5005, 2 hrs as default (which is the same as the default TCP keep-alive timer) seems too long for a dynamic environment such as V2X. Would it be possible to set it to something in the order of minutes, for instance 10 min? Christian, Wednesday, 10:42 We agree that T5005 should be set in the order of minutes for V2X. A draft revision is available. Lena, Thursday, 0:58 I am OK with the draft revision.
C1-202780	T3540 for service request for V2X communications	ZTE	CR 2111 24.501 Rel-16	Current Status: Agreed Revision of C1-202333 Lena, Wednesday, 23:14 I am OK with C1-202780. ----------------------------------------- Rae, Friday, 9:08 Service type “signaling” seems more appropriate under the case that UE only wants to get resources for PC5 from RAN without pending UL data. Fei, Friday, 11:14 I am fine to change the service type to "signalling" for this case. Fei, Saturday, 9:11 A draft revision is available. The changes are: 1) service type is changed from data to signalling. 2) the summary of change is also updated. Lena, Sunday, 20:08 Having the service request type set to “signalling” rather than “data” makes more sense since no DBR will be set up.
C1-202838	Additional transport over Uu for V2X messages of V2X services identified by V2X service identifiers	Ericsson / Ivo	CR 0023 24.386 Rel-16	Current Status: Open Questions Is Christian ok with C1-202838? Revision of C1-202010 ------------------------------------------------ Christian, Monday, 8:41 the cover sheet has some issue; the reason for change indicates, quote “**A method** for uplink and downlink transport of V2X messages over TCP and unicast downlink transport of V2X messages over UDP are specified”. The CR should not introduce any new **method** but should align with stage 2 requirements (TS 23.285). Hope you agree. we agree with the need of changes to TS 24.386 but again those have to be aligned with stage 2 which just add the support for TCP/IP packet to the existing UDP/IP. The reason for change indicates, quote “Furthermore, given that V2X communication over Uu in 5GS in TS 24.587 specified unicast downlink transport over UDP too, *it is proposed to also enable unicast downlink transport over UDP in TS 24.386.*". But TS 24.386 already states in clause 4.1 "can use unicast transport (in uplink, downlink or both of them)". I am confused. I also fail to see the mandatory distinction of UDP port for uplink and downlink in stage 2 spec (TS 23.285) being added in Rel-16. Additionally, implementations based on TS 24.386 already work well for UDP for uplink and downlink traffic. We do wonder whether you considered backwards compatibility when defining the new method for UDP port handling. Now, you would say that TS 24.587 the mandatory distinction exists. True, but this first of all this is for 5GS and not EPS but now more important, it seems not to be backed up in stage 2 (TS 23.287). We fail to find the requirement for the mandatory distinction of UDP ports for uplink or downlink so we might have gone too far in TS 24.587 with the **method** and this needs to be rethought. In short, initially, only the updates backed up by stage 2 (i.e., TS 23.285) are acceptable to us, i.e., support of TCP/IP packet. Ivo, Tuesday, 0:40 I can work on the cover page You raise several aspects above. Regarding downlink V2X communication over Uu using UDP, transporting a V2X message of a V2X service identified by a V2X service identifier: - In 24.386, the downlink V2X communication over Uu using UDP for such V2X messages is specified solely using MBMS bearer (see 24.386 subclause 6.2.4 last paragraph). I.e. there is no downlink V2X communication over Uu using UDP using unicast bearers for such V2X messages. - In 24.587, there is no MBMS yet. Thus, we agreed that downlink V2X communication over Uu using UDP for such V2X messages can use unicast bearers. Else, we would only have uplink transport and no downlink transport, for such V2X messages. - given that the UE can move between EPS and 5GS, the CR proposes to specify the downlink V2X communication over Uu using UDP using unicast bearers for such V2X messages also in 24.386, in the same way as specified in 24.587. As the same functionality would be defined both in EPS and 5GS, the same transport for such V2X messages would be used in EPS and 5GS. In 24.386, the text you quoted above is true only for V2X message of a V2X service *NOT* identified by a V2X service identifier, where the application in the UE just uses regular IP routing. The port is different in uplink and downlink V2X communication over Uu using UDP, transporting a V2X message of a V2X service identified by a V2X service identifier: - to ensure backward compatibility with uplink V2X communication over Uu using UDP for such V2X messages, a specified in 24.386. - to enable the V2X application server to distinguish uplink V2X messages from the UE and UE's requests for reception of downlink V2X messages, of such V2X service. - to inform the UE whether the V2X application server supports the added downlink V2X communication over Uu using UDP using unicast bearers. I indeed considered the backward compatibity - if the UE is NOT configured with the UDP port for downlink transport for a V2X service identified by a V2X service identifier, then the UE does not use the procedures for downlink V2X communication over Uu using UDP using unicast bearers for V2X messages of the V2X service identified by the V2X service identifier. Does this address your comment? The port is different in uplink and downlink V2X communication over Uu using UDP, transporting a V2X message of a V2X service identified by a V2X service identifier, due to the reasons identified in the previous answer. Disadvantage of the above is that the UE will need to adjust its behaviour in Uu depending whether the UE is in EPS or in 5GS. However, if you insist that you only want to focus on TCP, then this is of course possible. Christian, Tuesday, 16:51 I fail to see justification in your comments for the proposed new method of introducing mandatory separation and support of UDP ports for downlink and uplink in V2X for EPS; can you please share the requirements at stage 2 level to back your proposal to TS 24.386 and 24.385 (in C1-202010 and 2011)? As I already said in my initial e-mail, yes, they were added to TS 24.587 (V2X for 5GS) but again can you share the stage 2 requirements also for 5GS? I may miss something but I cannot find them. I believe that all this of mandatory separation of UDP ports for downlink and uplink needs to be re-considered actually. Again, in my view, a single UDP port can be used for both uplink and downlink. I still don’t understand why the 3GPP-based UE implementation has to be limited and be forced to have separate UDP ports. This actually has an impact on the upper layers. Frankly, we seem to have gone too far about the Uu data transmission in TS 24.587 in specifying a number of details, for example, mandatory UDP ports for downlink and uplink as in our view, the need of defining all this should lie on upper layers which are out-of-scope of 3GPP (e.g., WAVE in North America, GeoNetworking protocol for the EU –ETSI-, DSMP protocol for China, whatever protocol used in India, etc). The 3GPP-based UE implementation should follow the way used by upper layers on how to configure the use of UDP and TCP port(s). CT1 should not introduce duplication or conflictive requirements actually. Again, please your CRs should align with stage 2, i.e., support of TCP/IP packet. Nothing else. Ivo, Tuesday, 19:53 A draft revision is available. Main changes: - downlink transport of V2X messages over UDP was removed from the scope of the CR. - related configuration parameters were also removed from the scope of the CR.
C1-202839	Configuration parameters for additional transport over Uu for V2X messages of V2X services identified by V2X service identifiers	Ericsson / Ivo	CR 0020 24.385 Rel-16	Current Status: Open Questions Is Christian ok with C1-202839? Revision of C1-202011 ---------------------------------------------- Christian, Monday, 8:41 The CR should not introduce any new **method** but should align with stage 2 requirements (TS 23.285); we agree with the need of changes to TS 24.385 but again those have to be aligned with stage 2 which just add the support for TCP/IP packet to the existing UDP/IP; we do wonder whether you considered backwards compatibility when defining the new method for UDP port handling. Note that you take the existing MO leaf for the UDP port (UDPPort) and change the meaning of it; initially, only the updates backed up by TS 23.285 are acceptable to us, i.e., support of TCP/IP packet. Ivo, Tuesday, 0:43 The comments above are similar to those raised against C1-202010. I have provided answers to them in the other mail threat. Let's conclude on C1-202010 first. I will update C1-202011 based on the conclusions of C1-202010. Ivo, Tuesday, 19:53 A draft revision is available. Main changes: - downlink transport of V2X messages over UDP was removed from the scope of the CR. - related configuration parameters were also removed from the scope of the CR.
C1-202842	Correction on conditions to initiate a PC5 unciast link establishment procedure	Huawei, HiSilicon / Vishnu	CR 0036 24.587 Rel-16	Current Status: Agreed Revision of C1-202457 -------------------------------------------------- Ivo, Thursday, 13:55 The sentence does not seem to be an English sentence. Not clear what "are" in "are not identical" relates to. Vishnu, Sunday, 12:09 Agree that the ‘are’ does not make sense. How about the following modification: "e) there is no existing PC5 unicast link for the pair of peer application layer IDs, or there is an existing PC5 unicast link for the pair of peer application layer IDs and the network layer protocol of the existing PC5 unicast link is not identical to the network layer protocol required by the upper layer in the initiating UE for this V2X service." Ivo, Monday, 23:14 Proposed text seems OK. Vishnu, Tuesday, 10:47 A draft revision is available. Frederic, Tuesday, 12:42 Could you please restore the styles in your revision? Everything is in “normal”. Vishnu, Tuesday, 14:37 An updated draft revision fixing the styles is available. Ivo, Wednesday, 20:49 I am OK with the draft revision. Please add Ericsson as co-signer.
C1-202844	Packet filter for PC5 QoS flows	Huawei, HiSilicon / Vishnu	CR 0037 24.587 Rel-16	Current Status: Agreed Revision of C1-202485 ---------------------------------------------- Ivo, Thursday, 18:07 "The IP packet filter set is defined in TS 23.501 [X] clause 5.7.6.2." - it would be more appropriate to refer to stage-3 specification. Vishnu, Sunday, 13:01 IP packet filter set is defined in 23.501 5.7.6.2. Not sure the contents of IP packet filter set is in the scope of stage-3. If you know any stage-3 specification with this definition, kindly let us know. Lena, Monday, 0:54 Regarding the proposal on the contents of the V2X packet filter: We are ok with all proposed components except the TC field of GeoNetworking Common header: filtering based on this field would require deep inspection of the packet at the UE since the UE would first need to determine that this is the GeoNeworking format in the non-IP header, and then the UE would need to read into the GeoNetworking headers – which may still have a few variants in realization. Also, there is no stable implementable specification for the GeoNetworking yet. So we would prefer not to have this component in Rel-16. Ivo, Monday, 23:18 24.501 Figure 9.11.4.13.4 Packet filter contents field specifies packet filter in a QoS rule. Vishnu, Tuesday, 11:04 To Lena: we have a different view on the Geonetworking TC field. The protocol format of the non-IP header is fixed when the UE can locate itself (e.g. GeoNetWorking in Europe, WAVE in USA and DSMP in China), and the request from upper layer to transfer a packet also indicates to UE’s 3GPP layer in which protocol format this packet is, thus no specific procedure to determine the protocol format. It is specified in SA2 that if V2X Application Requirements is provided by the V2X application layer, the UE determines the QoS parameters for the V2X services based on the V2X Application Requirements and the V2X service type (e.g. PSID or ITS-AID). When GeoNetworking is used, TC field is where the application layer provides the V2X Application Requirements, thus it is a must-do for UE to read into the GeoNetworking headers to get the TC field, and then the UE can determine the QoS parameters for the packet or V2X services. If the UE cannot or does not read into the GeoNetworking headers, then the UE will fail to meet the application layer’s requirements and SA2’s design. Also in our understanding, the GeoNetworking is the most stable Non-IP type specification for V2X, if GeoNetworking Vishnu, Tuesday, 11:10 To Ivo: 24.501 Figure 9.11.4.13.4 specifies a QoS rule and packet filter set is only a parameter in it. It could be confusing to use it as a reference to IP packet filter set. But if you insist, we can change the reference to the stage-3 QoS rule figure. Vishnu Wednesday, 17:25 A draft revision addressing Ivo’s comment is available. @Lena, will you be ok with the Geonetworking TC field based on below explanation? Ivo, Wednesday, 20:59 Can we state: “The IP packet filter set is defined as content of the packet filter contents field specified in 3GPP TS 24.501 [6] figure 9.11.4.13.4 and table 9.11.4.13.1.”? Vishnu, Wednesday, 22:29 A draft revision addressing Ivo’s comment is available. Ivo, Wednesday, 22:36 Nearly OK. There should be hard spaces after "figure" and after "table". With those changes, Ericsson would like to cosign. Lena, Thursday, 1:44 Regarding your point that when GeoNetworking is used, TC field is where the application layer provides the V2X Application Requirements, so the UE must read that field, that is not necessarily true: implementations where the modem passes this field to the application layer and gets back the QoS parameters from the application are possible. However by including this field in the V2X filter components, you force the modem to read that field and we are not ok with that. So we can’t agree with the CR if it contains the GeoNetworking TC field as a mandatory filter component that the UE has to support. Vishnu, Thursday, 9:12 A draft revision is available. Changes: Reference changed as proposed by Ivo. Removed Geonetworking field from PF. Lena, Thursday, 9:39 I have the following comments on the draft revision: The mention of the Geo networking TC field needs to be removed from the Reason for change in the coversheet The reference to ETSI EN 302 636-4-1 v1.4.1 is no longer needed Vishnu, Thursday, 10:00 A draft revision addressing Lena’s comments is available. Lena, Thursday, 10:02 I am OK with the draft revision. Ivo, Thursday, 10:52 Draft revision is OK and Ericsson would like to co-sign.
C1-202867	Remove FFS on GFBR and MFBR for UL and DL	OPPO / Rae	CR 0010 24.587 Rel-16	Current Status: Agreed Revision of C1-202703 Rae: change in revision consists of changing the NOTE to “The GFBR and MFBR apply to both directions of the PC5 unicast link”. ----------------------------------------------- Revision of C1-202118 Lena, Wednesday, 23:43 In the NOTE, “The GFBR and MFBR apply to both uplink and downlink” does not make sense because there is no uplink or downlink for PC5. I suggest instead “The GFBR and MFBR apply to both directions of the PC5 link”. Rae, Thursday, 3:32 Thanks for the suggested wording. I propose to change it a little to “The GFBR and MFBR apply to both directions of the PC5 unicast link”. Whether it is OK for you? Lena, Thursday, 4:44 Yes, it is OK for me. --------------------------------------------------- Ivo, Thursday, 13:54 Sending the same value twice is waste of radio resources. Lena, Friday, 2:43 We don’t think it makes sense to keep two values ie one value for UL and one value for DL, given that this is PC5 (no UL/DL, only SL). One singe value is sufficient. Rae, Monday, 5:26 I have no strong view on whether use GFBR and MFBR for UL and DL separately. If the majority agree to use one value for both UL and DL, I am also OK. A draft revision is available. Ivo, Monday, 23:03 Nearly OK: the reason for change needs to be aligned with the changes. Please add Ericsson as co-signer. Chen, Tuesday, 4:54 Cover sheet not good enough as the reason for change fails to quote the stage 2 requirements which are in fact crystal clear, quote "For PC5 communication, the same GFBR and MFBR are used for both directions.". Then, the removal of the editor's notes only is not sufficient. Either we have only one code point for GFBR and another one for MFBR or we keep two for each (uplink and downlink) BUT it has to be specified that the value of uplink and downlink shall be the same in this version of the protocol. Rae, Tuesday, 5:26 A draft revision addressing Chen’s comments is available. I will also update the change. Chen, Thursday, 5:30 I’m OK with adding the stage 2 requirements in the coversheet in next revision.
C1-202875	PC5 unicast link security establishment	Qualcomm Incorporated / Lena	CR 0002 24.587 Rel-16	Current Status: Agreed Revision of C1-202104 ----------------------------------------------- Yanchao, Thursday, 15:55 In 6.1.2.6.3, “the initiating UE” should be “the target UE” a) during a PC5 unicast link establishment procedure, the initiating UE shall pass an indication to the lower layers that the PC5 signalling message is for security establishment; and b) during a PC5 unicast link re-keying procedure, the initiating UE shall pass an indication to the lower layers that the PC5 signalling message is protected. In 6.1.2.6.5, “the initiating UE” should be “the target UE” a) during a PC5 unicast link establishment procedure, the initiating UE shall pass an indication to the lower layers that the PC5 signalling message is for security establishment; and b) during a PC5 unicast link re-keying procedure, the initiating UE shall pass an indication to the lower layers that the PC5 signalling message is protected Sanpan, Thursday, 16:01 The terms (5G-EA and 5G-IA) defined in clause 3.1 doesn’t look like definitions. You can add them in clause 3.2 and the text after the abbreviation can be moved to clause 8.4.c as NOTE. In clause 6.1.2.6.2 – in step a) 1) - For precondition related to DIRECT LINK ESTABLISHMENT REQUEST message seems not proper. – the precondition should be “if KNRP ID is not included in the DIRECT LINK ESTABLISHMENT REQUEST message, the target UE does not have an existing KNRP for the KNRP ID included in DIRECT LINK ESTABLISHMENT REQUEST message or the target UE wishes to derive a new KNRP” (Same condition added in clause 6.1.2.2.3). In clause 6.1.2.6.2 – in step b) - For precondition related to DIRECT LINK REKEYING REQUEST – ReAuth flag needs to be checked. In clause 6.1.2.6.2 – “The target UE shall start timer T5aaa” -> it should be initiator UE. In clause 6.1.2.6.5 – “ the initiating UE shall pass an indication to the lower layers” -> it should be target UE (2 instances) In clause 6.1.2.6.5 – “The target UE shall abort the ongoing procedure” – I do not see abort procedure defined anywhere? What should be done to abort the procedure? In clause 6.1.2.6.6.1 – Same comment as above for aborting procedure In clause 6.1.2.7.1 – “The PC5 unicast link security mode control procedure is used to establish a security association between two UEs during …..” (Terminology used from clause 5.3.3.1.4.3 of TS 33.536) In clause 6.1.2.7.3 – steps to “derive KNRP-sess from KNRP” and “derive NRPEK and NRPIK from KNRP-sess” should be move after step e) – as we need to derive keys only after checking whether message can be accepted or not. In clause 6.1.2.7.5 – if DIRECT LINK SECURITY MODE COMMAND message is rejected due to cause specified in step d) of clause 6.1.2.7.3 OR step e) of clause 6.1.2.7.3 – then what will be values of PC5 signalling protocol cause IE value? Table 8.4.1.1 and in Table 8.4.9.1– Why 9 bits are used? Rae, Friday, 7:44 The indication from PC5-S to AS layer to indicate whether PC-S message is protected or not is not necessary, with the following reasons: RAN2 has determined the value of LCIDs corresponding to the different PC5-S message. I copy the table from the agreed RAN2 CR R2-2001969 as below. The new indication cannot be handled in the existing AS layer, which will impact AS layer e.g. a new layer such as SDAP should be added. Actually the same mechanism is also in ProSe without the proposed indication and there is no issue. Fei, Friday, 10:45 The term 5G-EA and 5G-IA can be referred to 24.501. In the subclause 8.4.g, the EEA/EIA should be changed to 5G-EA/IA; I have a question, why the the Knrp ID is defined for 32 bits. I have not found clear statement that the Knrp id should be 32bits. And since the Knrp_sess id is 16bits, whether 16 bits are sufficient for the Knrp id. Lena, Monday, 3:08 To Yanchao: I have uploaded a draft revision with the following changes (also incorporated comments from other companies): Referred to the definition of 5G-EA and 5G-IA in TS 24.501 rather than adding the same definition in TS 24.587, and removed the addition of the reference to TS 33.501 which as a result is no longer needed Replaced “initiating UE” by “target UE” in 2 places in 6.1.2.3 Replaced initiating UE” by “target UE” in 2 places in 6.1.2.5 In clause 6.1.2.6.2, for the preconditions related to the case when the authentication procedure is triggered by a direct link establishment procedure, added a condition that “the KNRP ID is not included in the DIRECT LINK ESTABLISHMENT REQUEST message or the initiating UE does not have an existing KNRP for the KNRP ID included in DIRECT LINK ESTABLISHMENT REQUEST message or the initiating UE wishes to derive a new KNRP, derive a new KNRP” In clause 6.1.2.6.2, for the preconditions related to the case when the authentication procedure is triggered by a direct link re-keying procedure, added a condition that the DIRECT LINK REKEYING REQUEST message includes a Re-authentication indication Replaced “target UE” by “initiating UE” in 6.1.2.6.2 Changed “to establish a security association between two UEs" to “to establish security between two UEs” during In subclause 6.1.2.7.1 In clause 6.1.2.7.5, clarified that if DIRECT LINK SECURITY MODE COMMAND message is rejected due to cause specified in step d) of clause 6.1.2.7.3 orstep e) of clause 6.1.2.7.3, the UE shall use PC5 signalling protocol cause #d "UE PC5 unicast signalling security policy mismatch" in the SECURITY MODE REJECT message Fixed the number of bits used from 9 to 8 in 8.4.1.1 and 8.4.9.1 In subclause 8.4.g, changed EEA/EIA to 5G-EA/IA Lena, Monday, 3:09 To Sapan: -> They are actually defined in TS 24.501. Fei suggested just referring to the definitions in TS 24.501, which is what I have done in the draft revision -> OK -> OK -> OK -> OK -> Aborting the procedure means no longer pursing it, no longer sending any related signalling and cleaning up all related timers. We have this terminology also in TS 24.008, TS 24.301 and TS 24.501, without any specific definition of what aborting the procedure means, and I see no need to start defining it now. -> See 6) -> OK -> No because the first check to see whether the message can be accepted it to check the integrity protection of the message, which requires NRPIK -> The UE shall use PC5 signalling protocol cause #d "UE PC5 unicast signalling security policy mismatch" in the SECURITY MODE REJECT message, I have clarified this in the revision -> That was a mistake, thanks for pointing it out. I have fixed it in the draft revision Lena, Monday, 3:12 To Fei: I agree with your suggestion to refer to TS 24.501, and I also agree with the comment about changing EEA/EIA to 5G-EA/IA. I have taken both comments onboard, as well as comments from Yanchao and Sapan in a draft revision available. Regarding the length of KNRP ID, although TS 33.536 does not explicitly define the length of KNRP ID (probably an oversight), the rationale section of S3-200501 explains that the security for the PC5 unicast link “is based on the ProSe text [2] and the conclusion of the TR but includes at least the following changes: (…) Renaming the KD (…) to KNRP”. For ProSe, KD ID is 32 bits long, so I have used the same length. If some companies think this value is not appropriate, we can always send an LS to SA3 to ask them how long it should be. Sapan, Monday, 8:17 Thanks for considering my comments and taking it on board. While reviewing the draft revision, I found few more issues and here are the comments: In clause 6.1.2.6.3 – after step b), please mention about deriving KNRP as follows - “Upon sending the DIRECT LINK AUTHENTICATION RESPONSE message, the target UE shall derive a new KNRP as specified in 3GPP TS 33.536 [yy]. “ In clause 6.1.2.6.4 – please add below text at end of the first paragraph. “and derive a new KNRP as specified in 3GPP TS 33.536 [yy]” In clause 6.1.2.7.3 – reference number for TS 33.536 is used as [x] => it should be [yy] as specified in reference clause 2. I am fine with changes done for previous comments. Lena, Monday, 23:44 To Sapan: -> Adding this statement would not be correct, because it might take several authentication procedures (ie several authentication request/response exchanges) to derive the K_NRP depending on the authentication method used, see TS 33.536 subclause 5.3.3.1.3.2. Also, some authentication methods might require some info in the DIRECT SECURITY MODE COMMAND message to complete the K_NPR derivation (see in TS 33.536 figure 5.3.3.1.3.2-1 that the Direct Security Mode Command message optionally includes a Key establishment info IE) . So we can have text saying the UE derives the new K_NRP only in the security mode control procedure, not in the authentication procedure -> Same as above Thanks for pointing this out, I have fixed it in v2 of the draft revision Lena, Tuesday, 7:28 To Rae: I do think this indication from the V2X layer to the AS layer of whether a PC5 signalling message is unprotected, for security establishment, or protected, would be useful. We already have in the spec a lot of info passed from the V2X layer to the AS (destination layer-2ID, etc). Yes it can be handled in implementation, but having it in the spec makes the interactions between the layers easier to understanding in my view. That said, if I am the only who think the indication is useful, I am ok to remove it. I would be interest to hear other companies’ view. Sapan, Tuesday, 7:43 -> ok -> I agree that there could be multiple authentication request/response exchanges occur but I would like to add clarification on exactly when a new KNRP has been derived by the initiating UE. So, my proposal is to add below text in clause 6.1.2.6.4: “Upon completion of final link authentication request/response exchange, the initiating UE shall derive KNRP as specified in 3GPP TS 33.536 [yy].” -> Thanks Fei, Tuesday, 13:34 Thanks for your clarification. I am fine with the length of Kd ID and the revision is Ok to me. Christian, Tuesday, 16:18 We would like to proceed with the CR but we believe that some parts of the proposal are still under discussion at stage 2 level and we would like to propose some updates: under clause 6.1.2.2.2, we would like to remove bullet item g) from now and replace it by an editor’s note, for example, whether the PC5 unicast signaling security policy is needed to be included is FFS waiting for SA3 conclusion; also under clause 6.1.2.2.2, we do not see need of indication of inter-layer interaction about providing an indication to lower layers about the PC5 signalling message is unprotected. Firstly, it seems not settled whether the PC5 signalling would be sent unprotected for signalling in the end (wait for SA3 conclusion). Even if so, there is no need of this interaction defined in TS 24.334 (in ProSe) where your proposal seems to be based on; under clause 6.1.2.7.1, the proposal removes both editor’s note given the impression that all is fixed by SA3 but this is not understanding as discussions are ongoing there; under clause 6.1.2.7.2, we think that at this moment in time we should not add the text quote: The initiating UE shall select security algorithms in accordance with its UE PC5 unicast signalling security policy and the target UE’s PC5 unicast signalling security policy. If the PC5 unicast link security mode control procedure was triggered during a PC5 unicast link establishment procedure, the initiating UE shall not select the null integrity protection algorithm if the initiating UE or the target UE’s PC5 unicast signalling integrity protection policy is set to "signalling integrity protection required". in our understanding there are still SA3 discussion on this aspect. Editor’s note; also under clause 6.1.2.7.2, similarly as above, we would like to remove the bullet item 7. Editor’s note instead, if necessary; under clause 6.1.2.7.3, we would like to remove bullet items c and d, and add an editor’s notes instead; under clause 6.1.2.7.5, 8.4.9, we would like not add yet the proposed new value “#d UE PC5 unicast signalling security policy mismatch“; under clause 7.3.1.1, 7.3.d.1, 7.3.e.1, we would like not to add the UE PC5 unicast signalling security policy IE so new 8.4.d and 8.4.k are not acceptable to us yet; Lena, Wednesday, 2:23 To Christian: a. -> UE signalling security policy is in SA3 spec. ongoing discussions abou UE user plane security policy, ok to remove that one b. -> ok c. -> reverted deletion of EN on user plane security policy, kept removal of the other one d. -> CR is aligned with SA3 spec e. -> CR is aligned with SA3 spec f. -> CR is aligned with SA3 spec g. -> ok to moreve items related to user plane security policy A draft revision is available. Lena, Wednesday, 2:53 To Sapan: Regarding “I would like to add clarification on exactly when a new KNRP has been derived by the initiating UE”, it is actually not possible to put a statement on exactly when the UE does this in the PC5 unicast link authentication procedure because it will depend on the authentication method in use: how many times the procedure itself is performed to derive a new K_NRP depends on the authentication method in use. Also depending on the method in use, the derivation of K_NRP might be performed in successive steps. So I would prefer to only list the fact that K_NRP has been derived as pre-condition for the start of the security mode control procedure, without specifying exactly when the initiating UE has derived K_NRP (since it can’t be pin-pointed). A draft revision is available, addressing also comments from Christian and Rae. Lena, Wednesday, 2:55 To Rae: I have removed the iindication from UE to AS layer of whether a PC5-signalling message is unprotected, for security establishment or protected. A draft revision is available. Sapan, Wednesday, 10:34 I completely agree with you on the fact that link authentication procedure may run multiple times depending on the authentication method used. But in TS 33.536 - clause 5.3.3.1.3.2 – it is clearly mentioned that KNRP shall be calculated after step#2 and before UE_2 sends Direct Security Mode Command message. So here is my new proposal: If Qualcomm do not want to add normative text in clause 6.1.2.6.4, then Can you add NOTE in clause 6.1.2.6.4 to specify that initiating UE derives KNRP during link authentication procedure at any time depending on authentication method use? Yanchao, Wednesday, 10:35 I have checked with my RAN2 colleague, our view on “whether the indication from UE to AS layer of whether a PC5-signalling message is unprotected is needed or not” is needed. AS layer cannot tell whether the a PC5-signalling message is unprotected based on existing information, therefore an explicit indication is needed from upper layer by AS layer. Lena, Wednesday, 22:27 To Yanchao: thanks for taking the time to checking on this and for your feedback. I agree that some indication is needed from the V2X layer to the AS. But since this is internal to the UE, it is true that strictly speaking this can be handled in UE implementation. Given that 2 companies (Huawei, OPPO) prefer to leave this up to implementation, in the interest of progress have removed this indication from the updated draft revision. I hope this is an acceptable way forward for you. Lena, Wednesday, 22:48 An updated draft revision is available. I have added a NOTE in 6.1.6.2.4 as requested by Sapan, and I have removed all mentions of UE security policy and replaced them by Editor’s notes as requested by Christian. Ivo, Wednesday, 22:56 In one place, there is "MSB" while other places use "MSBs". Is that intentional? Lena, Wednesday, 23:07 No, it was not intentional, thanks for pointing it out. I have changed that one instance of “MSB” to “MSBs” in an updated draft revision. Sapan, Wednesday, 23:07 I am OK with the proposed tex for the NOTE. Christian, Thursday, 11:49 Thanks for considering our comments. The CR is fine by me.
C1-202876	PC5 unicast link re-keying procedure	Qualcomm Incorporated / Lena	CR 0004 24.587 Rel-16	Current Status: Agreed Revision of C1-202107 ----------------------------------------------- Ivo, Thursday, 13:54 We need to specify how the UE treats the spare values. Yanchao, Thursday, 15:58 Is it possible that the target UE does not accept the PC5 unicast link re-keying procedure? Sapan, Thursday, 16:30 In clause 6.1.2.x.2 – Need to add below NOTE. (Similar NOTE added in C1-202104) “In order to ensure successful PC5 unicast link re-keying, T5ccc should be set to a value larger than the sum of T5aaa and T5bbb” Table 8.4.1.1 – 9 bits are used. Fei, Friday, 11:00 My preference would be that the target UE sends the Rekey response using the existing security context before triggering the re-authentication procedure. After sending the rekey response to the initial UE, the target UE will trigger the authentication procedure as in the CR 2104. Ivo, Friday, 15:43 I withdraw my comment on this document, it was related to C1-202106. Lena, Tuesday, 7:42 To Fei: the reason for having the Rekeying response is so that the initiating UE can consider the procedure complete. If you send it before authentication and security mod control are performed then you do not know whether the rekeying of the link will actually succeed. Hence we would prefer to keep the Rekeying response at the end of the procedure (as was done for ProSe in TS 24.334). Lena, Tuesday, 7:43 To Yanchao: I do not think the target UE has the option of not accepting the PC5 unicast link re-keying procedure. Note that for ProSe in TS 24.334, there is also no way for the target UE to reject the rekeying request. Lena, Tuesday, 7:51 To Sapan: I have taken your comments onboard in a draft revision. Sapan, Tuesday, 8:13 I am fine with the draft revision. Fei, Tuesday, 8:16 Thanks for your clarification. I am fine with the CR.
C1-202877	Adding general subclause on security of PC5 signalling messages	Qualcomm Incorporated / Lena	CR 0005 24.587 Rel-16	Current Status: Agreed Revision of C1-202108 ------------------------------------------------- Ivo, Friday, 3:51 Please do not use "and/or" Christian, Monday, 16:06 we support the CR in order to have a general clause on PC5 unicast security into TS 24.587 in a similar way as TS 24.501 or TS 24.301 (i.e., a clause on “NAS security” exists); there are a number of aspects which seems not to be crystal clear at stage 2 as there are p-CRs tabled at the last meeting and the specification is not approved yet (TS 33.536). Hence, we would like to propose some updates and clarify some questions from my side: I would like to remove the word “possible” in front of “integrity protection and ciphering of PC5 user-plane data” and add an editor’s note instead till this is settled in SA3; I would like to remove the NOTE under clause 6.1.2.1a.1 at this moment in time and see how all this ends up in stage 2. Also, in my view, I find strange that at least integrity protection is not used by default; I would like to know how many security contexts can exist in the UE, e.g., clause 6.1.2.1a.2 reads “[..] PC5 unicast security contextS” but the text under the clause is not clear to me. When checking the draft version of TS 33.536, I am unsure how many PC5 unicast security contexts you think of. I see that the initiating UE can establish different PC5 unicast security contexts for each peer UEs during the PC5 unicast link establishment procedure but that is not clear in your proposal and get further confused by the use of “current” later one. If needed, and editor’s note could be added; and I fail to see the concept of “current” PC5 unicast security context at stage 2 level (draft TS 33.536). The introduction of the concept of “current” PC5 unicast security context seems to imply that there is also “non-current” one or? Though existing in EPS and 5GS for NAS security in TS 24.301 and 24.501, I fail to see those two concepts at stage 2 level at this moment in time. Editor’s notes or clarification? Lena, Wednesday, 5:22 Due to comments from Christian, the NOTE with this “and/or” is gone. I have also made the following additional changes based on his comments: Removed “possible” in front of “integrity protection and ciphering of PC5 user-plane data” and added an Editor’s note instead Updated wording to remove the use of “current” to avoid giving the impression that the UE maintains multiple security contexts a given PC5 unicast link (there is only one, except for a short time during the re-keying procedure) A draft revision is available. Lena, Wednesday, 5:32 A draft revision addressing Christian’s comments is available. Christian, Thursday, 11:55 I am OK with the draft revision.
C1-202908	Handling of link establishment accept	vivo	CR 0013 24.587 Rel-16	Current Status: Agreed Revision of C1-202738 ------------------------------------------------- Revision of C1-202181 Ivo, Wednesday, 20:34 C1-202738 look ok. If you happen to make a revision, can you please indicate Ericsson as cosigner? Lena, Thursday, 1:26 I am OK with C1-202738. --------------------------------------- Ivo, Thursday, 18:05 - 6.1.2.2.3 - storage of this assigned layer-2 ID and the source layer 2 ID used in the transport of this message provided by the lower layers in the PC5 unicast link context, should be normative. - 6.1.2.2.4 - the source layer-2 ID and the destination Layer-2 ID used in the transport of this message provided by the lower layers, should be normative. Lena, Friday, 2:54 Some overlap with the changes in C1-202140 in subclause 6.1.2.2.3 The changes to 6.1.2.2.3 in the CR miss mentioning that the UE passes the DIRECT LINK ESTABSLISHMENT ACCEPT message to the lower layers for transmission (which is covered in C1-202140, see “After the DIRECT LINK ESTABLISHMENT ACCEPT message is generated, the initiating UE shall pass this message to the lower layers for transmission along with the initiating UE's layer 2 ID for unicast communication, the target UE's layer 2 ID for unicast communication and an indication that the PC5 signalling message is protected”) The changes in 6.1.2.2.3 have the UE pass the source and destination L2 ID to the lower layers “after sending the DIRECT LINK ESTABSLISHMENT ACCEPT message”. This is not ok, the lower layers need this info along with the message itself, to be able to send it In 6.1.2.2.4, “After receiving the DIRECT LINK ESTABLISHMENT ACCEPT message, the target UE” should be “After receiving the DIRECT LINK ESTABLISHMENT ACCEPT message, the initiating UE” Bullet c) in 6.1.2.2.4 is not needed, the source and destination layer 2 ID pair is already known to the lower layers from the time the initiating UE send the DIRECT LINK AUTHENICATION RESPONSE message or the DIRECT LINK SECURITY MODE COMPLETE message. Behrouz, Friday, 3:44 Please see my comments below. The Green text is from your CR and the Blue is my comment. 6.1.2.2.3 PC5 unicast link establishment procedure accepted by the target UE Upon receipt of a DIRECT LINK ESTABLISHMENT REQUEST message, if the target UE accepts this request, it [Change to “the target UE”] shall uniquely assign a PC5 unicast link identifier, create a PC5 unicast link context [What are these two?] and assign a layer-2 ID for this PC5 unicast link. Then the target UE stores this assigned layer-2 ID and the source layer 2 ID used in the transport of this message provided by the lower layers in the PC5 unicast link context. This pair of layer-2 IDs is associated with a PC5 unicast link context. Yanchao, Tuesday, 4:58 I have changed “the UE does xx” to “the UE shall do” based on Ivo’s comments. A draft revision is available. Yanchao, Tuesday, 5:03 I have taken onboard Lena’s comments. A draft revision is available. Chen, Tuesday, 5:19 The CR should be Cat B, not F. In the Summary of change, wording "accpets" -> "accepts"; In clause 6.1.2.2.3, the title has indicated the target UE accepts this request, therefore there is no need to add the sentence "if the target UE accepts this request"; As clause 6.1.2.5 described the unicast link identifier for unicast, which conceptually conflicts with the unicast link identifier proposed by the CR; The current specification has already the indication in clause 6.1.2.2.4 "with a PC5 unicast link context"; In TS23.287 clause 6.3.3.1 bullet 5, there are no PQFI(s) and its corresponding PC5 QoS parameters from the V2X layer to the AS layer in the PC5 unicast link establishment procedure, quote: The V2X layer of the UE that established PC5 unicast link passes the PC5 Link Identifier assigned for the unicast link and the PC5 unicast link related information down to the AS layer. The PC5 unicast link related information includes Layer-2 ID information (i.e. source Layer-2 ID and destination Layer-2 ID). This enables the AS layer to maintain the PC5 Link Identifier together with the PC5 unicast link related information. It seems to conflict with existing requirements under thePC5 unicast link identifier update procedure (i.e., .PC5 unicast link identifier update procedure (6.1.2.5.4) where is stated, quote Yanchao, Tuesday, 15:25 A draft revision with the following changes is available: it is changed to “the target UE”,done; “PC5 unicast link context” is changed to “PC5 link context” Yanchao, Tuesday, 15:35 To Chen: a draft revision is available. I did not take onboard the following comments: I don’t agree CR should be Cat B, this CR just propose correction to existing procedure, not add a new feature About “no need to add the sentence "if the target UE accepts this request";”, that is the common for stage 3 specification. If you check TS24.587 and TS24.501, you will find dozens of instances in the accept subclause, which specifies”if the UE/NW accepts…… , the UE/NW shall do About “no PQFI(s) and its corresponding PC5 QoS parameters from the V2X layer to the AS layer in the PC5 unicast link establishment procedure”, see requirements in 23.287 About “conflict with existing requirements under thePC5 unicast link identifier update procedure”, there is no conflict, the paper propose changes to the PC5 unicast link establishment procedure, not the PC5 unicast link establishment [should be identifier update instead?] procedure Behrouz, Tuesday, 15:42 The revision looks ok and InterDigital would like to co-sign.
C1-202913	ENs resolving in modification pocedure	vivo	CR 0015 24.587 Rel-16	Current Status: Agreed Revision of C1-202909 ----------------------------------------- Revision of C1-202898 Frederic, Thursday, 11:56 This CR was revised 2 times: to C1-202898 (rev 2) and to C1-202909 (rev 3). The author marked 2909 as withdrawn, leaving 2898 as open. I would have preferred to have the opposite done, i.e. withdraw 2898 so that the highest revision is kept. Therefore I would like to have 2898 revised (it will become rev 4). ----------------------------------------- Revision of C1-202740 ------------------------------------------- Revision of C1-202183 Ivo, Wednesday, 20:37 C1-202740 look ok. If you happen to make a revision, can you please indicate Ericsson as cosigner? Lena, Thursday, 0:28 C1-202740 adds “#5 lack of resources for proposed link” in 6.1.2.3.5, which is not aligned with what is proposed in C1-202741 (#5 ack of resources for PC5 unicast link). Is it possible to revise C1-202740 to align? ----------------------------------------------- Ivo, Thursday, 18:06 - "For other reasons that causing the failure of link modification." -> "For other reasons that cause the failure of link modification." or "For other reasons causing the failure of link modification." - there should be some minimum value for the timer T (else the UE might set it to zero which voids the requirement on not attempting to start PC5 unicast link modification with the same target UE) Lena, Friday, 2:56 In 6.1.2.3.5, “For other reasons that causing” should be “For other reasons causing” In 6.2.1.3.5, I don’t think “If the PC5 signalling protocol cause value in the DIRECT LINK MODIFICATION REJECT message is #X "required service not allowed" or #5 "lack of resources for proposed link", then the initiating UE shall not attempt to start PC5 unicast link modification with the same target UE at least for a time period T” is justified. The restriction should be limited to the same kind of modification, as in “If the PC5 signalling protocol cause value in the DIRECT LINK MODIFICATION REJECT message is #X "required service not allowed" or #5 "lack of resources for proposed link", then the initiating UE shall not initiate a PC5 unicast link modification procedure with the target UE to add or remove the same V2X service, or to add, modify or remove the same PC5 QoS flow(s) at least for a time period T” Rae, Friday, 8:43 How the target UE can determine which service is allowed or not? There is no such configuration in 5.2.3. Yanchao, Tuesday, 5:36 I have taken Ivo’s comments onboard, for the second comment, I added “The length of time period T is not less than 30 minutes.” in the note. A draft revision is available. Yanchao, Tuesday, 5:49 All of Lena’s comments have been taken on board. For the second one, I added “to add the same V2X service, or to add or modify the same PC5 QoS flow(s)”, because I think the UE can’t reject a request to remove a V2X service or a PC5 QoS flow. A draft revision is available. Yanchao, Tuesday, 5:52 To Rae: Our understanding is the V2X service is not allowed if there is no corresponding service authorisation provisioning for this V2X service. Please see the draft revision. Rae, Tuesday, 8:08 I understand Yanchao used the same wording as in TS 24.334. But the configuration for V2X is different from ProSe and there is no such “service authorisation provisioning”. Meanwhile I found there is also such word under the subclause 6.1.2.2.5. In my understanding “service authorisation provisioning” should be changed to “Configuration parameters for V2X communication over PC5” and the subclause 5.2.3 is referred. Chen, Tuesday, 8:37 Glad to see that editor's notes are resolved but I do not agree with just removing the one about multiple modification operation under clause 6.1.2.3.2. TS 23.287 indicates that the UE can establish multiple PC5 unicast links so it is natural that the UE could also modify multiple PC5 unicast links. Yanchao, Tuesday, 15:55 I have taken Rae’s comments onboard in a draft revision. Yanchao, Tuesday, 15:58 To Chen: I think you have a misunderstanding here, the PC5 unicast link modification procedure is used to modify one existing PC5 unicast link. If the UE want to modify multiple PC5 unicast links, the UE has to initiate multiple the PC5 unicast link modification procedures, one procedure for one PC5 unicast link.
C1-202914	Handling of PC5 broadcast QoS flow match and establishment	vivo	CR 0021 24.587 Rel-16	Current Status: Agreed Revision of C1-202910 ------------------------------------------------- Revision of C1-202900 -------------------------------------------------- Revision of C1-202899 --------------------------------------------------- Revision of C1-202746 ------------------------------------------------------ Revision of C1-202189 Ivo, Wednesday, 20:40 C1-202746 is OK and Ericsson would like to co-sign. Lena, Thursday, 0:51 The bulleted list has the following issue: “and” at the end of bullets b) and c-3) need to be removed. --------------------------------------- Ivo, Thursday, 18:06 - "there is no existing PC5 QoS rules" -> "there is no existing PC5 QoS rule" - shouldnt bullet d) and its sub-bullets be normative? - bullet 3): "UE" -> "the UE" Lena, Friday, 3:09 “.” at the end of bullet c-3) should be “;” “and perform the following” -> “and performs the following” “with following operations” -> “by performing the following operations” “set up a new PC5 QoS rule, the PC5 QoS rule contains” -> “create a new PC5 QoS rule which contains” “to lower layers” -> “to the lower layers” “a precedence value.” Should be “a precedence value; and” “source and destination layer-2 IDs.” Should be “source and destination layer-2 IDs;” “.” at the end of bullets d-2) should be an “;’. “.” at the end of bullets d-3) should be an “; and”. “.” at the end of bullet b) should be “; and” In bullet d-3), “UE uses” -> “the UE uses” In bullet d-3), “the new created PC5 QoS flow as bullet a)” -> “the new PC5 QoS flow created as described in bullet 1)” In bullet d-3), “as bullet 2)” -> “as described in bullet 2)” Yanchao, Tuesday, 6:37 I took onboard Lena’s comment in a draft revision. I also added ‘and’ at the end of bullet d-2); Not sure why “.” at the end of bullet b) should be “; and”. But if so, should I add ‘and’ at end of bullet c)?
C1-202919	Maximum number of NR PC5 unicast links for a UE	Huawei, HiSilicon / Vishnu	CR 0029 24.587 Rel-16	Current Status: Agreed Revision of C1-202848 ------------------------------------------------------- Revision of C1-202427 SangMin, Thursday, 12:19 I can live with C1-202848. Ivo, Thursday, 12:39 I am OK with this version. Could you please add Ericsson as co-signer? ------------------------------------------------------ Ivo, Thursday, 13:55 6.1.2.2.5 - superfluous "or" and inconsistent usage of "due to ". Rae, Friday, 7:37 Based on the discussion paper related to this CR, the reason why V2X layer limits the number of unicast links is to follow the limitation over Uu interface. However, PC5 is different because: For PC5, the number of DRB is per PC5 link, not shared by all the links of one UE; In RAN2, it is determined that the 5-bits link identifier is included in the RRC signaling for UE requesting PC5 resources to RAN. This is already a limitation actually. Whether it is necessary to do the limitation duplicated in V2X layer and AS layer. Vishnu, Sunday, 11:49 To Ivo: I will fix it. To Rae: the main reason is not to follow the limitation in Uu interface. Main reason is that we need hardware storage for ( Eg: storing the security keys) which is limited in the UE. Why we quoted comparison to Uu interface is as an example. E.g we have limited the number of QoS rules in the UE before because of storage limitation of storing packet filters. So in CT1, we have taken care of such situations where the resources in the UE is limited. Rae, Monday, 11:16 I still want to have response to the following comment: In RAN2, it is determined that the 5-bits link identifier is included in the RRC signaling for UE requesting PC5 resources to RAN. This is already a limitation actually. Whether it is necessary to do the limitation duplicated in V2X layer and AS layer. Vishnu, Monday, 15:17 When we define the bit size of IDs it will always be a higher number due to backward compatibility issues. It will be very difficult to change it in the future otherwise. What we are trying to define here on NAS level considering the storage aspect of the security keys and also packet filters. In reality most of the V2X communication will be done by group cast and broad cast, only 2-3 unicast links will be there at a time. So 8 is a reasonable number. It can also be changed in NAS spec without backward compatibility issues. So we hope you can support this. Rae, Tuesday, 9:57 Thanks for the clarification. It is OK for me. Vishnu, Tuesday, 10:34 A draft revision is available. Lena, Tuesday, 23:07 This limitation to 8 simultaneous link seems arbitrary. Our view is that the maximum number of links supported by a UE should be left to UE implementation. If a UE has reached its maximum number of supported links, it can always reject new requests for direct link establishment from other UEs. Ivo, Wednesday, 20:42 The draft revision addresses my comments. Could you add Ericsson as co-signer? SangMin, Thursday, 9:24 We also have same view as expressed by Lena that the maximum number of links should be left to UE implementation. So this CR is not needed. Vishnu, Thursday, 9:57 The reason why we want to specify an upper limit is that unlike other scenarios where we set the max limit as implementation specific (eg PDU session , packet filter etc), there is an ID defined in NAS specification ( eg: 4 bits ) and so there is already an implicit Max number and then we have a UE defined implementation specific max number. But for PC5 unicast link we don’t have that yet kind of ‘id defined’ in NAS specifications. So we think its good to have a recommended upper limit. So we will change the normative text to implementation specific number as you proposed and add a Note, with recommended maximum number as 8. Will that be acceptable for you ? Lena, Thursday, 10:01 Yes, that would be acceptable. Vishnu, Thursday, 10:16 A draft revision is available. Lena, Thursday, 10:20 Would it be possible to change the text in the NOTE to the following? NOTE: The recommended maximum number of established NR PC5 unicasts link is 8. Vishnu, Thursday, 10:24 A draft revision with the NOTE updated as requested is available. Lena, Thursday, 10:31 I am OK with the draft revision. Vishnu, Thursday, 12:12 Can SangMin also confirm he is ok with the draft revision?
C1-202930	Defining new parameters needed for the Link Identifier Update procedure	InterDigital Communications	CR 0028 24.587 Rel-16	Current Status: Agreed Revision of C1-202870 Friday, Christian, 10:02 Requests text to be added to the final report, “Huawei and HiSilicon prefer the first version of the proposal (in C1-202870) as it is to us the way to go to solve the identified issue. We can reluctantly accept C1-202930 for now but we believe that further changes are required in CT1 specifications to achieve consistency and provide clear description of the proposal. We also believe that SA3 would need to be informed so that their related specification is also aligned to avoid different interpretation for readers of the specifications” Behrouz, Thursday, 15:40 C1-202870 was revised to C1-202930 changing MSB to MSBs and LSB to LSBs. However, I would like to point out that I noted inconsistency in the comments received vs actions done as well as the fact that we have now created inconsistency between SA3 spec and our spec. I only did this to make progress as my personal opinion is that we are making a mistake here going against definitions that have been there, and used, in our own spec as well as SA3’s spec!! Christian, Thursday, 15:57 In my view, everyone has brought up a number of valid points.However, I personally believe that we should keep the way we have specified in CT1 till now and which is actually aligned with the SA3 specification.Note that we are dealing with the understanding of how implementers need to encode the bits. Hence, we have to be careful in order not to allow different interpretations.I am afraid that if not, first of all implementers will ask what the difference is or changing now from MSB to the plural form and the misalignment with security in stage 3. As rapporteur of TS 24.587, I would like to keep consistency if possible. Secondly, implementers can get different understandings which can lead to different implementations. This would lead to undesirable effects in interoperability and testing. Overall, as us, CT1 delegates and writers of the standard seem to have not the very same understanding. ------------------------------------------- Revision of C1-202596 Ivo, Thursday, 11:00 C1-202870 still contains "MSB" and "LSB". However, values of those IEs contains more than 1 bit. Thus, IMO, it would be more appropriate to use "MSBs" and "LSBs". I understand that the intention is to align with EPS ProSE, but eV2XARC is being documented separately. ------------------------------------------ Revision of C1-202327 Ivo, Thursday, 18:07 "MSB" and "LSB" indicate a single bit. Is it intentional? Behrouz, Thursday, 19:59 SA3 has defined both of them as “bytes” and not bits. Ivo, Friday, 11:07 I cannot find such statement in 33.536 - there is no "byte" in 33.536. 33.526 refers to 21.905 for abbreviations and 21.905 defines MSB and LSB as follows: LSB Least Significant Bit MSB Most Significant Bit Or do I miss anything? Furthermore, at least in CT1, we normally use "octet" rather than "byte" so if SA3 really meant most/least significant byte, "most/least significant octet" would be more appropriate in CT1. Behrouz, Friday, 19:41 I was trying to mimic the same terminology as used in 24.334 (ProSe spec). Here is what I “actually” meant: From 24.334 an MSB of KD-sess ID IE set to the most significant 8 bits of the KD-sess ID; and the LSB of KD-sess ID IE set to indicate the least significant 8-bits of KD-sess ID Yanchao, Saturday, 10:53 In clause 6.1.2.5.3, deleting ‘UE decides to change its identifier’ is not aligned with TS 23.287. The first change also means target UE needs to check whether the privacy configuration requires privacy protection Clause 6.1.2.5.3, for the bullet f), why add the source UE’s new layer 2 ID in the link identifier update accept message? Clause 6.1.2.5.3, same question as above, for the bullet g) why add the source UE’s new application layer ID in the link identifier update accept message? Clause 6.1.2.5.3, the added bullet h) is coverd by the existing bullet c) Clause 6.1.2.5.4，the existing “shall” is correct. Ivo, Monday, 23:22 If the field is meant to keep 8 bits then the field should be called "MSBs of KD-sess ID" / "LSBs of KD-sess ID". If it just kept singular, it is very confusing. Behrouz, Tuesday, 0:48 We could add the “s” but just for me to understand; how come it was not deemed “confusing” when it was defined in 24.334 for ProSe? All we need to do is defining the LSB and MSB as the “8 bits…” in the beginning of the spec. Ivo, Tuesday, 9:03 I do not know why it was not confusing in 24.334 for ProSe. Likely, it was not detected. Behrouz, Tuesday, 16:28 Do you plan on changing the Prose spec as well? May I remind you that 24.334 was specified in Rel-12 and up to now nobody has shown any issues whatsoever with these definitions that have been used in that spec. These two MSB/LSB were defined in the body of 24.334 and will also be defined the same way in 24.587, so why is this a major problem now? Ivo, Wednesday, 21:00 We start with a new spec and we should be consistent on the terminology. Behrouz, Wednesday, 21:53 That’s exactly my point. There is no need to get stuck with a definition in 21.905, which has nothing to do with this spec. As I suggested earlier, all we need to do is that we will define LSB and MSB in 24.587 “exactly as it was done in 24.334” and there has not been any confusion. As far as I know, the implementers will follow the Stage 3 spec and definitions there (and not a Stage 1 spec). Behrouz, Thursday, 1:31 To Yanchao: -> this text is being modified in SA2 ->Please check TS 33.536 ->UE identifiers as received in request needs ->to be sent back in accept ->Ok ->Already addressed in C1-202596
RACS (CT4 lead)	Peter – Main	CT aspects of optimizations on UE radio capability signalling 100%
C1-202693	RACS parameters in generic UE configuration procedure	Ericsson / Mikael	CR 2078 24.501 Rel-16	Revision of C1-202233 Lena, thu, 04:53 Fine Lena, Fri, 01:43 Fine with the CR, needs an additional “either” Mikael, Fri, 08:01 Acks Lena, will come with rev
5G_SRVCC (CT4 lead)	Peter – Main	CT aspects of single radio voice continuity from 5GS to 3G 100%
C1-202094	Introduce support for 5G SRVCC support indication when registering with EPS	BlackBerry Uk Ltd.	CR 3213 24.008 Rel-16	Withdrawn Following ConfCall Alternative to C1-202133 Ivo, Thu 13:43 No need for this CR, impact on EPS to be avoided Lena, Fri, 05:21 prefer E solution with no UE impact, C1-202133.
C1-202095	Introduce support for 5G SRVCC support indication when registering with EPS	BlackBerry Uk Ltd.	CR 3290 24.301 Rel-16	Withdrawn Following ConfCall Revision of C1-198012 Alternative to C1-202133 Ivo, Thu 13:43 No need for this CR, impact on EPS to be avoided Lena, Fri, 05:21 prefer E solution with no UE impact, C1-202133
C1-202638	Initial Registration after 5G-SRVCC	ZTE, China Unicom	CR 2115 24.501 Rel-16	Revision of C1-202529 Revision of C1-202338 Ivo, Thu, 13:43 Minor editorial Fei, Sat, 09:14 Provides the rev in Inbox Ivo, Mon, 23:26 Editorial Fei, Tue, 05:10 Acks Ivo
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
SEAL	Lena – Breakout	CT aspects of Service Enabler Architecture Layer for Verticals Is TS 24.548 sufficiently stable to be sent to CT#88 for approval?
C1-202137	Updates to User Authentication Client (SIM-C) procedure	Intel / Vivek	CR 0001 24.547 Rel-16	Current Status: Agreed
C1-202138	Updates to User Authentication Server (SIM-S) procedure	Intel / Vivek	CR 0002 24.547 Rel-16	Current Status: Agreed
C1-202209	Latest reference version of draft TS 24.548	Huawei, HiSilicon /Christian	draft TS 24.548 Rel-16	Current Status: Noted
C1-202297	Updates to structure and data semantics for request for unicast resource at VAL service communication establishment procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed
C1-202299	Structure and data semantics for request for modification of unicast resources procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Sapan, Friday, 10:31 New elements defined in this pCR i.e. <modification> and <modification-result> elements, are exactly same as elements defined in another pCR C1-202297 (<request> and <request-result> elements) I do not see need to define new elements in this pCR. We can reuse elements defined in C1-202297 by adding request type within <request> element. Chen. Saturday, 11:13 This p-CR just followed the requirements of stage 2 of TS 23.434 clause 14.3.2.6, clause 14.3.2.7, clause 14.3.2.8 and clause 14.3.2.9. And as described in TS 23.434 clause 14.3.3.2, there are differences between the request for unicast resources procedure and the request for modification of unicast procedure. Sapan, Monday, 11:27 Thanks for the clarification, I am ok with the changes.
C1-202301	Structure and data semantics for network resource adaptation procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed
C1-202305	Use of pre-established MBMS bearers procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed
C1-202312	MBMS bearer event notification procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed
C1-202313	Switching between MBMS bearer bearer and unicast bearer procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed
C1-202314	Resolution of editor's note on application unique ID	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed
C1-202319	IANA registration template of SEAL location management	Huawei, HiSilicon / Chen	CR 0001 24.545 Rel-16	Current Status: Agreed
C1-202320	Removal of editor’s note on MIME types	Huawei, HiSilicon / Chen	CR 0002 24.545 Rel-16	Current Status: Agreed
C1-202321	Resolution of editor's note on application unique ID	Huawei, HiSilicon / Chen	CR 0003 24.545 Rel-16	Current Status: Agreed
C1-202322	Structure and data semantics for query list of users based on location procedure	Huawei, HiSilicon / Chen	CR 0004 24.545 Rel-16	Current Status: Agreed
C1-202440	Create SIP based subscription for SLM	Samsung, Huawei, HiSilicon / Sapan	CR 0006 24.545 Rel-16	Current status: Postponed Sapan, Wednesday, 19:55 All SIP based subscription procedures proposed in CRs (C1-202440, C1-202441, C1-202442, C1-202443, C1-202444, C1-202445, C1-202446) are postponed.
C1-202441	Modify SIP based subscription for SLM	Samsung / Sapan	CR 0007 24.545 Rel-16	Current status: Postponed Frederic, Thursday, 12:54 Incorrect clauses affected: 6.2.6.1.1.1 (NEW) should be 6.2.6.1.1.2 (NEW) Sapan, Monday, 14:04 A draft revision is available. Sapan, Wednesday, 19:55 All SIP based subscription procedures proposed in CRs (C1-202440, C1-202441, C1-202442, C1-202443, C1-202444, C1-202445, C1-202446) are postponed.
C1-202442	Delete SIP based subscription for SLM	Samsung / Sapan	CR 0008 24.545 Rel-16	Current status: Postponed Sapan, Wednesday, 19:55 All SIP based subscription procedures proposed in CRs (C1-202440, C1-202441, C1-202442, C1-202443, C1-202444, C1-202445, C1-202446) are postponed.
C1-202443	Handling of abnormal cases for SIP based subscription in SLM	Samsung / Sapan	CR 0009 24.545 Rel-16	Current status: Postponed Sapan, Wednesday, 19:55 All SIP based subscription procedures proposed in CRs (C1-202440, C1-202441, C1-202442, C1-202443, C1-202444, C1-202445, C1-202446) are postponed.
C1-202444	Message Formats for location management subscription	Samsung / Sapan	CR 0010 24.545 Rel-16	Current status: Postponed Sapan, Wednesday, 19:55 All SIP based subscription procedures proposed in CRs (C1-202440, C1-202441, C1-202442, C1-202443, C1-202444, C1-202445, C1-202446) are postponed.
C1-202445	Timers used in location management	Samsung / Sapan	CR 0011 24.545 Rel-16	Current status: Postponed Sapan, Wednesday, 19:55 All SIP based subscription procedures proposed in CRs (C1-202440, C1-202441, C1-202442, C1-202443, C1-202444, C1-202445, C1-202446) are postponed.
C1-202446	Annex for registering ICSI and MIME for SLM	Samsung / Sapan	CR 0012 24.545 Rel-16	Current status: Postponed Sapan, Wednesday, 19:55 All SIP based subscription procedures proposed in CRs (C1-202440, C1-202441, C1-202442, C1-202443, C1-202444, C1-202445, C1-202446) are postponed.
C1-202447	SIP based subscribe/notify procedures for SEAL group management	Samsung / Sapan	CR 0001 24.544 Rel-16	Current Status: Agreed
C1-202449	Indication from SGM-S to SGM-C about group join required	Samsung / Sapan	CR 0003 24.544 Rel-16	Current Status: Agreed
C1-202450	SIP based subscribe/notify procedures for configuration management	Samsung / Sapan	CR 0001 24.546 Rel-16	Current Status: Agreed
C1-202715	Updates to request for unicast resource at VAL service communication establishment procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202296 ------------------------------------------- Sapan, Thursday, 21:32 The only concern with me for this CR is that – server is sending HTTP 200 OK, only after receiving SIP 200 OK. I believe server should not wait till SIP based procedures are completed. Server can send HTTP 200 OK if HTTP POST request from VAL server is authorized. And once resources are reserved (i.e. SIP 200 OK is received) – server can send another HTTP message to notify about the success. Chen, Friday, 5:33 I understand Sapan’s concern, but it needs SA6’s requirement. This p-CR just followed the procedure description of TS 23.434 clause 14.3.3.2.1.2. Sapan, Friday, 8:45 I do understand that the contribution is based on SA6 specification. The problem here is that the SIP procedure can take longer time to respond (at times more than 32 seconds) and I do not think HTTP client can wait for such long time. My proposal is: - On receiving HTTP POST request, the server will sends HTTP 202 Accepted as intermediate response and once SIP procedure is completed, the server will send actual response in form of new HTTP message (for this client should have opened notification channel); Chen, Saturday, 9:47 Thanks for your explanation. In my understanding, It is the VAL server not the client that requests for unicast resources; It is only the 3GPP system that provides the unicast resources and the VAL server needs the unicast resources ASAP. If HTTP 202 response message is sent, the connection between the VAL server and the SNRM-S might be dropped; HTTP is a stateless protocol with request-response mechanism. If HTTP 202 response message is sent, the VAL server should do polling (long polling or periodic polling?). In my point of view, the 32s is not long for the persistent connection, which could ensure the VAL server can get the resources ASAP. With the above consideration, it’s better to keep the current status and align with TS 23.434. Sapan, Monday, 10:04 I understand that Huawei do not want to send HTTP 202 Accepted response to VAL server due to reasons mentioned in your below email, but I will atleast prefer to add clarification in VAL serve side procedure about terminating the connection. I propose to add following NOTE as compromise solution in VAL server side procedure: NOTE 1: Before terminating connection due to no response from SRM-S, the VAL server allows sufficient time for SRN-S to reserve resources and respond. It is up to implementation to decide how long the VAL server waits for receiving response. I hope you can agree to add above NOTE. Chen, Monday, 11:12 The NOTE is OK with me. The draft revision with the NOTE and wording fixed is now available. Sapan, Monday, 13:33 I am OK with the draft revision.
C1-202716	Request for modification of unicast resources procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202298 ------------------------------------------------ Sapan, Friday, 9:00 In clause 6.2.2.3.1, step b) – How server determines whether bearer modification is required or not? In clause 6.2.2.3.1, step b) 3) i) – the value “failure” is not giving enough information to VAL server. The <modification-result> element can also be used to provide reason for the failure. My suggestion is to change the value to “Modification not required” – to indicate VAL server about the actual result. Same concern as described in previous CR - HTTP 200 OK is sent after receiving SIP 200 OK. Chen, Saturday, 11:28 -> In my understanding, the decision mechanism is NRM-S implementation specific -> The p-CR just followed the requirement of stage 2 of TS 23.434, clause 14.3.2.9 -> Please see my replies on C1-202296 Sapan, Monday, 13:43 I am fine with reply for comment 1) and 2). For comment 3) – can you add similar NOTE as we decided to add in C1-202296. Chen, Tuesday, 11:07 I’m OK with the NOTE added and the draft revision is available. Frederic, Tuesday, 12:46 The pCR introduces two subclauses 6.2.2.3.1. While this can be fixed at the implementation, it would be better to have it corrected now. Chen, Wednesday, 3:39 Thanks Frederic, it is fixed now and I have also fixed clauses affected. Sapan, Wednesday, 7:34 I am fine with the NOTE added in draft revision.
C1-202717	Network resource adaptation procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202300 --------------------------------------------- Sapan, Friday, 9:45 In clause 6.2.2.4.1 – “In order to request request unicast resources or modify already……” – The word “request” is written twice. In clause 6.2.2.4.1 – At end of Step d) 1) ii) A) – it should be “or” instead of “and”. In clause 6.2.2.4.2 – same concern as previous CRs – HTTP 200 OK is sent after SIP 200 OK. Chen, Friday, 10:44 -> OK -> OK -> In the adaptation procedure, the NRM server interacts with 3GPP system using HTTP as described in TS 29.514/TS 29.214. The HTTP 200 OK is sent after HTTP 200 OK. Let me know your thinking. Sapan, Friday, 11:17 For 3), Ok. I am fine with explanation as it is HTTP based procedure. Chen, Saturday, 9:53 Thanks for your feedback, a draft revision is available. Sapan, Monday, 11:03 I am ok with the draft revision.
C1-202718	Structure and data semantics for MBMS bearer announcement over MBMS bearer procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202302 --------------------------------------------- Sapan, Friday, 11:54 All 5 pCRs (C1-202302, C1-202304, C1-202306, C1-202309, C1-202311) defines new clause 7.3.3 “MBMSInfo document” (for data structure) and 7.5.3 “MBMSInfo document” (for data semantics). Also, each pCRs define <mbms-info> as root element in the document with different child elements. It is difficult to understand how all pCRs will be implemented in the specification. I request to merge all pCRs and define both clauses 7.3.3 and 7.5.3 only once with all required child elements in it – this will help us to understand exactly how clause 7.3.3 and clause 7.5.3 will be implemented in specification. I do not understand <monitoring-state> element. Can you please clarify its usage? What is the meaning of value “monitoring” for the client when it receives this from server? In clause 7.5.3 - Step h) mentions about element <mcptt-mbms-rohc> - It should be < announcement-acknowlegement> element. Change possible values for <unicast-status> element to “required” and “not-required”. In clause 7.5.3 – Step a) – all references are used with soft space – change it to hard space Chen, Saturday, 8:57 Acturally, the new clause 7.3.3 and clause 7.5.3 has only one “header” repectively. Every pCR is corresponding to the related procedures as we did before in other SEAL Ts. Therefore, I merged these overlapped headers into revised C1-202302 and keep only child elements in other pCRs. I will coordinate with the rapporteur Christian to implement these pCRs according to the sequence of procedures (i.e. the apearance sequence of the elements). -> As replied to C1-202210, the monitoring state is used to control if the client is actively monitoring the MBMS bearer quality or not. Therefore, the “monitoring” means the client start to monitor the MBMS bearer quality, and “not-monitoring” means the client stops monitoring the MBMS bearer quality. And this is updated in the draft revision -> OK -> As replied to C1-202210, if the <unicast-status> element is present, the client shall include the <unicast-listening-status> element in the MBMS listening status report message. And this is updated in the draft revision -> ok A draft revision is available. Sapan, Monday, 9:40 Although you have merged all headers in to revised C1-202302 but new clauses are still defined in other pCRs. I will prefer to have everything merged to have single description of new clauses. But with your proposed approach, the clarity is improved to some extent and I understand your intention to break into different pCRs due to separate procedures and so as a compromise I am fine with your proposed approach. To align with your description, I request you to remove “ing” from the value as shown below. - The value “monitoring” indicates that the SNRM-C shall monitor the MBMS bearer quality; and - The value “not-monitoring” indicates that the SNRM-C shall not monitor the MBMS bearer quality; Also: Kindly change the values of <monitoring-state> as specified in above comment – “monitor” and “not-monitor”. Can you add possible values for <unicast-status> to “required” and “not-required” In step j) – element <mcptt-mbms-rohc> is used – it should be <seal-mbms-rohc>. Chen, Monday, 11:02 I am ok with Sapan’s additional comments except the following: about adding possible values for <unicast-status> to “required” and “not-required”, there is a little difference between the <monitoring-state> and the <unicast-status>. <monitoring-state> is to control the client to monitor or not to monitor no matter what is the client doing. But <unicast-status> is to report a unicast listening status that already exists. Therefore, from my side, the presence of the <unicast-status> is enough to indicate the listening status of the unicast bearer is requested and aligned with the TS 23.434. A draft revision is available. Sapan, Monday, 13:04 I am OK with the draft revision.
C1-202719	Updates to MBMS bearer quality detection procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202303 -------------------------------------------------- Sapan, Friday, 12:47 In clause 6.2.3.4.1 – NOTEs are not in proper style. Need to add condition in step a) 5) – if MBMS announcement message contained <unicast-status> with value “required”, shall may include an <unicast-listening-status> element set to "listening" or "not-listening" indicating the unicast listening status. Chen, Saturday, 3:35 Both comments are OK with me. The second point I revised in the following: If the <unicast-status> element is present in the MBMS announcement message, shall… The draft revision is available. Sapan, Sunday, 19:18 I am fine with the draft revision.
C1-202720	Structure and data semantics for MBMS bearer quality detection procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202304 ------------------------------------------------ Sapan, Friday, 11:54 All 5 pCRs (C1-202302, C1-202304, C1-202306, C1-202309, C1-202311) defines new clause 7.3.3 “MBMSInfo document” (for data structure) and 7.5.3 “MBMSInfo document” (for data semantics). Also, each pCRs define <mbms-info> as root element in the document with different child elements. It is difficult to understand how all pCRs will be implemented in the specification. I request to merge all pCRs and define both clauses 7.3.3 and 7.5.3 only once with all required child elements in it – this will help us to understand exactly how clause 7.3.3 and clause 7.5.3 will be implemented in specification. In clause 7.5.3 – Step b) – all references are used with soft space – change it to hard space Chen, Saturday, 8:57 Acturally, the new clause 7.3.3 and clause 7.5.3 has only one “header” repectively. Every pCR is corresponding to the related procedures as we did before in other SEAL Ts. Therefore, I merged these overlapped headers into revised C1-202302 and keep only child elements in other pCRs. I will coordinate with the rapporteur Christian to implement these pCRs according to the sequence of procedures (i.e. the apearance sequence of the elements). Ok for the comment on clause 7.5.3. A draft revision is available. Sapan, Monday, 9:40 Although you have merged all headers in to revised C1-202302 but new clauses are still defined in other pCRs. I will prefer to have everything merged to have single description of new clauses. But with your proposed approach, the clarity is improved to some extent and I understand your intention to break into different pCRs due to separate procedures and so as a compromise I am fine with your proposed approach. I am ok with the draft revision.
C1-202721	Structure and data semantics for use of pre-established MBMS bearers procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202306 ------------------------------------------------ Sapan, Friday, 11:54 All 5 pCRs (C1-202302, C1-202304, C1-202306, C1-202309, C1-202311) defines new clause 7.3.3 “MBMSInfo document” (for data structure) and 7.5.3 “MBMSInfo document” (for data semantics). Also, each pCRs define <mbms-info> as root element in the document with different child elements. It is difficult to understand how all pCRs will be implemented in the specification. I request to merge all pCRs and define both clauses 7.3.3 and 7.5.3 only once with all required child elements in it – this will help us to understand exactly how clause 7.3.3 and clause 7.5.3 will be implemented in specification. In clause 7.5.3 – Under <mbms-bearers> element – In Step b) – all references are used with soft space – change it to hard space. Chen, Saturday, 8:57 Acturally, the new clause 7.3.3 and clause 7.5.3 has only one “header” repectively. Every pCR is corresponding to the related procedures as we did before in other SEAL Ts. Therefore, I merged these overlapped headers into revised C1-202302 and keep only child elements in other pCRs. I will coordinate with the rapporteur Christian to implement these pCRs according to the sequence of procedures (i.e. the apearance sequence of the elements). Ok for the comment on clause 7.5.3. A draft revision is available. Sapan, Monday, 9:40 Although you have merged all headers in to revised C1-202302 but new clauses are still defined in other pCRs. I will prefer to have everything merged to have single description of new clauses. But with your proposed approach, the clarity is improved to some extent and I understand your intention to break into different pCRs due to separate procedures and so as a compromise I am fine with your proposed approach. I am ok with the draft revision.
C1-202722	Use of dynamic MBMS bearers procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202307 --------------------------------------------------- Sapan, Friday, 13:06 Following 3 statements refer to same procedure (clause 6.2.3.2.2 ) to perform difference tasks – please check if reference to the procedure are correct or not. In clause 6.2.3.X.2 - send an MBMS bearer announcement message as described in clause 6.2.3.2.2 towards the SNRM-C In clause 6.2.3.X.2 - shall send an MBMS bearers response message as decribed in clause 6.2.3.2.2 towards the VAL server In clause 6.2.3.X.3 - an MBMS bearer listening status report as described in clause 6.2.3.2.2 towards the SNRM-S Chen, Saturday, 5:19 Thanks for pointing this out. I checked and the last clause 6.2.3.2.2 should be 6.2.3.2.3. The draft revision is now available. Sapan, Sunday, 20:00 I am fine with the draft revision
C1-202723	Service continuity in MBMS scenarios procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202308 -------------------------------------------- Sapan, Friday, 13:26 In clause 6.2.2.4.2 – step c) “shall send the HTTP POST request towards the SNRM-S according to IETF RFC 2616 [r2616].” => It should be towards VAL server. Chen, Saturday, 5:05 Thanks for pointing this out. The draft revision is now available. Sapan, Sunday, 19:29 I am fine with the draft revision.
C1-202724	Structure and data semantics for service continuity in MBMS scenarios procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202309 -------------------------------------------- Sapan, Friday, 11:54 All 5 pCRs (C1-202302, C1-202304, C1-202306, C1-202309, C1-202311) defines new clause 7.3.3 “MBMSInfo document” (for data structure) and 7.5.3 “MBMSInfo document” (for data semantics). Also, each pCRs define <mbms-info> as root element in the document with different child elements. It is difficult to understand how all pCRs will be implemented in the specification. I request to merge all pCRs and define both clauses 7.3.3 and 7.5.3 only once with all required child elements in it – this will help us to understand exactly how clause 7.3.3 and clause 7.5.3 will be implemented in specification. Chen, Saturday, 8:57 Acturally, the new clause 7.3.3 and clause 7.5.3 has only one “header” repectively. Every pCR is corresponding to the related procedures as we did before in other SEAL Ts. Therefore, I merged these overlapped headers into revised C1-202302 and keep only child elements in other pCRs. I will coordinate with the rapporteur Christian to implement these pCRs according to the sequence of procedures (i.e. the apearance sequence of the elements). A draft revision is available. Sapan, Monday, 9:40 Although you have merged all headers in to revised C1-202302 but new clauses are still defined in other pCRs. I will prefer to have everything merged to have single description of new clauses. But with your proposed approach, the clarity is improved to some extent and I understand your intention to break into different pCRs due to separate procedures and so as a compromise I am fine with your proposed approach. I am ok with the draft revision.
C1-202725	MBMS suspension notification procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202310 ---------------------------------------------- Sapan, Friday, 2:36 1) Clause 6.2.3.6.2 – Need to do proper heading style 2) Client needs to send HTP response back to server before generating HTTP POST request. Chen, Saturday, 4:58 Both comments are accepted. The draft revision is available. Note that Client sends an HTTP 204 response back to server before generating HTTP POST request. Sapan, Sunday, 19:26 Minor editorial correction required – kindly use hardspace while referring to IETF RFC 2616 [r2616]. Other than that, I am fine with the draft revision. Chen, Tuesday, 11:20 Thanks for pointing this out. All the related space will be changed to hard space in the final revision.
C1-202726	Structure and data semantics for MBMS suspension notification procedure	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202311 ------------------------------------------------- Sapan, Friday, 11:54 All 5 pCRs (C1-202302, C1-202304, C1-202306, C1-202309, C1-202311) defines new clause 7.3.3 “MBMSInfo document” (for data structure) and 7.5.3 “MBMSInfo document” (for data semantics). Also, each pCRs define <mbms-info> as root element in the document with different child elements. It is difficult to understand how all pCRs will be implemented in the specification. I request to merge all pCRs and define both clauses 7.3.3 and 7.5.3 only once with all required child elements in it – this will help us to understand exactly how clause 7.3.3 and clause 7.5.3 will be implemented in specification. In clause 7.5.2 - <suspension-reporting-client-subset> - It is not clear how subset of clients will be specified. Chen, Saturday, 8:57 Acturally, the new clause 7.3.3 and clause 7.5.3 has only one “header” repectively. Every pCR is corresponding to the related procedures as we did before in other SEAL Ts. Therefore, I merged these overlapped headers into revised C1-202302 and keep only child elements in other pCRs. I will coordinate with the rapporteur Christian to implement these pCRs according to the sequence of procedures (i.e. the apearance sequence of the elements). About clause 7.5.2, the subset is further specified using one or more <NRM-client-id> elements. A draft revision is available. Sapan, Monday, 9:40 Although you have merged all headers in to revised C1-202302 but new clauses are still defined in other pCRs. I will prefer to have everything merged to have single description of new clauses. But with your proposed approach, the clarity is improved to some extent and I understand your intention to break into different pCRs due to separate procedures and so as a compromise I am fine with your proposed approach. I am ok with the draft revision.
C1-202727	XML scheme declaration for SEAL network resource management	Huawei, HiSilicon / Chen	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202315 ---------------------------------------------- Sapan, Friday, 15:09 Adding schema for 3rd document also (may be in next meeting?). Chen, Saturday, 3:05 OK with me. Yes, for the 3rd document I will think it further and the complete xml scheme will be provided next meeting. The draft revision with the editor’s note unremoved is now available. Sapan, Sunday, 19:12 I am fine with the draft revision.
C1-202733	XML scheme declaration for SEAL location management	Huawei, HiSilicon / Chen	CR 0005 24.545 Rel-16	Current Status: Agreed Revision of C1-202323 ---------------------------------------------- Sapan, Friday, 15:21 Editor’s note should not be removed as actual schema is not provided yet. Chen, Saturday, 2:54 OK with me. The complete xml scheme will be provided next meeting. The draft revision with the editor’s note unremoved is now available. Sapan, Sunday, 19:06 I am fine with the draft revision.
C1-202770	Wrong implementation of agreed p-CR C1-200881	Huawei, HiSilicon /Christian	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202210 ------------------------------------------------- Sapan, Thursday, 21:02 I am fine with the contribution but some clarifications are required. Also, I have some minor comments to improve clarity for the procedures. In clause 6.2.3.3.2.1, Server may add <monitoring-state> element in announcement message to client. How client will interpret this element? What is the meaning of "monitoring" value for client and also meaning of "not-monitoring" value for client – when it receives announcement message including <monitoring-state> element? In clause 6.2.3.3.2.1, Server may add <unicast-status> element in announcement message to client. How client will interpret value in this element? Rename clause 6.2.3.3.2.1 to “Generate announcement message” In clause 6.2.3.3.2.1.1 – Need to add reference to clause 6.2.3.3.2.1 to construct application/vnd.3gpp.seal-mbms-usage-info +xml MIME body. In clause 6.2.3.3.2.1.2 – Need to add reference to clause 6.2.3.3.2.1 to construct application/vnd.3gpp.seal-mbms-usage-info +xml MIME body. Chen, Saturday, 2:54 -> As TS 23.434 states, the monitoring state is used to control if the client is actively monitoring the MBMS bearer quality or not. Therefore, the “monitoring” means the client start to monitor the MBMS bearer quality, and “not-monitoring” means the client stops monitoring the MBMS bearer quality. The further description is added in the client procedure. And this will be further detailed in the revision of C1-202302 “Structure and data semantics for MBMS bearer announcement over MBMS bearer procedure”. -> If the <unicast-status> element is present, the client shall include the <unicast-listening-status> element in the MBMS listening status report message. The further description is added in the client procedure. And this will be further detailed in the revision of C1-202302 “Structure and data semantics for MBMS bearer announcement over MBMS bearer procedure”. -> OK -> OK, add the words ”according to clause 6.2.3.3.2.1”. -> OK, add the words ”according to clause 6.2.3.3.2.1”. A corresponding draft revision is available. Sapan, Sunday, 19:03 I am fine with provided changes – make sure to use hardspace while referencing clause 6.2.3.3.2.1. Also, regarding comment 1) and 2), I will check your revision C1-202302 and let you know if I have any comment or not.
C1-202772	Wrong implementation of agreed p-CR C1-200882	Huawei, HiSilicon /Christian	pCR 24.548 Rel-16	Current Status: Agreed Revision of C1-202211 ----------------------------------------------- Sapan, Thursday, 21:09 On cover sheet, Specification number and Agenda item is wrong. In clause 6.2.3.4.1.1 and in clause 6.2.3.4.1.2- Need to add reference to clause 6.2.3.4.1 to construct application/vnd.3gpp.seal-mbms-usage-info +xml MIME body Chen, Saturday, 2:54 Ok with both comments. A draft revision is available. Sapan, Sunday, 18:58 I am fine with the draft revision.
C1-202809	Removal of Editor’s notes	Samsung / Sapan	CR 0002 24.544 Rel-16	Current status: Agreed Revision of C1-202448 ---------------------------------------- Chen, Friday, 9:40 In the Reason of change, TS 33.434 states that access tokens shall be communicated from the SIM-C to VAL resource servers, not SGM-C/SCM-C. Therefore, the reason of change needs to be enhanced Sapan, Monday, 16:32 Although the annex describes about SIM-C, the general description of SEAL service authorization (in clause 6.2.2) and authorization framework (in clause 6.2.5) clearly mention that each SEAL client shall present access-token to SEAL server for authorization. I will update the reason for change accordingly. A draft revision is available. Chen, Tuesday, 11:00 I’m fine with the revision. As we discussed before, the header will be changed in SEAL location management in next meeting too.
C1-202810	Removal of Editor’s notes.	Samsung / Sapan	CR 0002 24.546 Rel-16	Current status: Agreed Revision of C1-202451 --------------------------------------------------- Chen, Friday, 9:40 In the Reason of change, TS 33.434 states that access tokens shall be communicated from the SIM-C to VAL resource servers, not SGM-C/SCM-C. Therefore, the reason of change needs to be enhanced Sapan, Monday, 16:32 Although the annex describes about SIM-C, the general description of SEAL service authorization (in clause 6.2.2) and authorization framework (in clause 6.2.5) clearly mention that each SEAL client shall present access-token to SEAL server for authorization. I will update the reason for change accordingly. A draft revision is available. Chen, Tuesday, 11:00 I’m fine with the revision. As we discussed before, the header will be changed in SEAL location management in next meeting too.
C1-202828	Updates to Token Exchange Client (SIM-C) procedure	Intel / Vivek	CR 0003 24.547 Rel-16	Current status: Agreed Revision of C1-202139 Vivek, Wednesday, 18:09 The Editor’s Note remains, and the cover sheet has been updated suitably to reflect this. ------------------------------------------------ Sapan, Monday, 14:49 I believe editor’s note should not be removed as token exchange procedure is not yet defined in SA3. Either we go ahead with this contribution by keeping editor’s note OR alternatively we may also postpone the contribution and we can align the procedure with SA3 once it is available in SA3 specification. I am fine with both options.
C1-202829	Updates to Token Exchange Server (SIM-S) procedure	Intel / Vivek	CR 0004 24.547 Rel-16	Current status: Agreed Revision of C1-202140 Vivek, Wednesday, 18:10 The Editor’s Note remains, and the cover sheet has been updated suitably to reflect this. ------------------------------------------------ Chen, Thursday, 13:40 The editor’s note should be deleted too. Sapan, Monday, 14:43 I think Editor’s note should not be removed. As I understand, this contribution is trying to align procedure with other user authentication procedure (in C1-202138). But the token exchange procedure is not defined in SA3 yet. I am fine with changes but I prefer not to remove Editor’s note. Either we go ahead with this contribution by keeping editor’s note OR alternatively we may also postpone the contribution and we can align the procedure with SA3 once it is available in SA3 specification. I am fine with both options. Chen, Wednesday, 11:23 I agree with you that the Editor’s note should not be removed. Therefore, @Vivek, the Summary of change should be corrected too.
Other Rel-16 non-IMS issues	Peter – Main	Other Rel-16 non-IMS topics
C1-202083	Correction of certain erroneous Information Element Identifiers	InterDigital Communications	CR 2033 24.501 Rel-16	Ivo, Thu, 13:44 Change in Table 8.2.6.1.1 seems unnecessary Behrouz, Thu, 19:46 Explains why he wants to keep Type 1 IE Ivo, Fri, 11:35 We may run out of Type 1, could use Type 2 where possible Behrouz, Sat, 02:27 Not keen on using Type 2, none was used in 301 Amer, Sat, 04:30 Not convinced by Behrouz argument on Type 2 Behrouz, Sat, 06:25 Commenting Amer, Sat, 13:57 Commenting to Behrouz Behrouz, Sat, 20:47 Discussing how to continue type 2 IE Ivo, Mon, 23:41 Explaining why type 2 IE would be beneficial Behrouz, Tue, 06:49 ongoing Ivo, Tue, 09:32 Ongoing Chrsitian, Wed, 17:32 We are in favour of C1-202083 as it stands. Ivo, Thu, 11:05 Nobody else has a problem, withdraws his comment Amer, Friday OK
C1-202148	SMS timer extension for the MS using CP CioT 5GS optimization	NTT DOCOMO	CR 0066 24.011 Rel-16
C1-202265	Considerations for AML over SMS in roaming scenarios	Apple	discussion Rel-16	Noted Revision of C1-200606 Osama, Thu, 21:14 First we need SA1 requirements
C1-202273	Remove invalid cases in error handling for TFT operation	Qualcomm Incorporated	CR 3214 24.008 Rel-16
C1-202274	Remove invalid cases in error handling for TFT operation in EPS	Qualcomm Incorporated	CR 3350 24.301 Rel-16
C1-202421	Definition of current PLMN and serving PLMN	Qualcomm Incorporated / Amer	CR 3354 24.301 Rel-16	Current Status Postponed Frederic, Thu, 09:08 Clauses affected missing Ivo, Thu, 13:45 Issues wih term “current PLMN”, requrests clarification Sung, Tue, 22:16 comments
C1-202467	WUS assistance for TAU	Huawei, HiSilicon/Lin	CR 3356 24.301 Rel-16
C1-202512	Correction to Handling of T3321 timer	MediaTek Inc.	CR 3217 24.008 Rel-16
C1-202633	Add handling for parameter set to “value is not used” in EPS	Qualcomm Incorporated	CR 3348 24.301 Rel-16	Revision of C1-202267 Lin, Thu, 03:22 Some change seems unacceptable Osama, Thu, 04:43 Does ot agree Lin suggests a NOTE Ivo, Thu, 13:44 semantic of “release/version” is not clear, want to use solely “version” Osama, Tue, 03:01 Goes with releases, provides rev Ivo, OK co-sign
C1-202700	RPDU transfer for 5GS using Control Plane CioT Optimization	NTT DOCOMO INC.	CR 0067 24.011 Rel-16	Revision of C1-202217 Kaj, Thu, 13:52 Don’t tick CN box, not CAT F Maoki, Fri, 11:41 Acks
C1-202781	Clarification on the UE behaviour when receiving T3448	ZTE	CR 3351 24.301 Rel-16	Revision of C1-202334 Osama, Fri, 22:20 Number of comments Lin, Sat, 12:12 Number of comments Fei, Tue, 13:21 Rev Osama, Tue, 17:08 Can live with the rev Lin, Wed, 05:51 fine
C1-202685	Reset of PLMN-specific attempt counter	MediaTek Inc.	CR 3364 24.301 Rel-16	Revision of C1-202511 Ivo, Wed, 12:39 Reason for change incorret Ivo, Fr, 10:54 To Marko, JJ If you confirm there is a problem and it will fixed in May meeting, then I am OK to agree the CR. If you explain that I am wrong, then I am happy to agree the CR. If there is no answer, the comment would imply postponing of the CR. Marko, Fr, 11:00 Acks the problem, will bring a CR to May meeting Ivo, Thu, 11:58 Reasons for change has issue, resetting counters seem strange Osama, Thu, 19:26 On Counter reset during power OFF -> against established principles in LTE, ok to do something when USIM is removed Sung, Thu, 21:56 Aligned with Osama, provides text Lin, Fri, 04:59 Modifies the text from Sung
C1-202736	Emergency PDN connection established after WUS negotiation	vivo	CR 3345 24.301 Rel-16	Revision of C1-202178 Lin, Fri, 03:56 Fine in principle, needs some changes, wants to co-sign Yanchao, Fri, 11:22 Asking Lin Lin, Sat, 11:48 Withdraws the earlier comment, wants co-sign Amer, Sat, 15:20 T oYanchao: I see your point but I would prefer to not repeat clear mistakes. However, if you feel strongly about keeping the existing text, I will not object. Yanchao, Mon, 10:40 Rev with Huawei as support Lin, Mon, 16:32 fine Amer, Wed, 07:07 Not happy, will not obect
C1-202686	Correction to Handling of T3421 timer	MediaTek Inc.	CR 3365 24.301 Rel-16	Revision of C1-202513 Frederic, Thu, 09:08 Clauses affected missing Osama, Thu, 19:36 Something wrong with case i)
C1-202830	Allow lower layer to change RRC establishment cause during voice EPS fallback	Qualcomm Incorporated, Ericsson	CR 3316 24.301 Rel-16	Current Status postponed Lin, Fri, 10:03 Asking this to be postponed Revision of C1-202269 Sung, Wed, 20:52 Fine Lin, Thu, 09:52 Reduc the content Osama, thu, discussing Revision of C1ah-200048 Lin, Fri, 07:14 Has a problem with the Note Osama, Fri, 07:24 Explaining when the use cas ein the note happens Marko, Fri, 11:04 Seconds Lin Osama, Fri, 17:14 Explaining Lin, Tue, 03:58 commenting Osama, Tue, 07:20 Asking whether he should beef up cover sheet Osama, Tue,21:11 Looks for progress, needs preference on which way to go Sung, Tue, 22:09 Prefers first option Osama, Wed, 01:51 Rev Lin, Wed, 05:23 Commenting Osama, Wed, 07:01 Explaiing Marko, Thu, 06:30 Perhaps a Note Osama, Thu, 06:54 Not happy with late comment
C1-202850	TA change during Authentication procedure in EMM-CONNECTED mode	Apple	CR 3347 24.301 Rel-16	Revision of C1-202263 Osama, Fri,07:58 should be POSTPONED Lin Postponed ------------------------------------ Lin, Fri, 07:18 Challenging the scenario Osam<>Krisztian disc only shown on previous agenda Lin, Tue, 03:46 CR not needed, covered Osama, Tue, 03:51 I won’t object if you change the CRs to be NW only impacting CRs Krisztian, Wed, 01:52 Explaining to Lin Krisztian, Wed, 02:01 To Osama, this is serious concern, rev sama, Wed, 02:39 Not convinced, should be discussed in SA3, LS to SA3 could be a way forward Lin, Wed, 05:06 Not agreeing with Krisztian Krisztian, Wed, 08:27 Ongoing Krisztian, Wed, 08:33 To Osama, SA3 not needed Osama, Wed, 20:22 Has issues Krisztian, Thu, 07:09 Not agreeing with Osama Lin, Thu, 09:29 Comments, if that are taken on board, he can live with it, 2850 requires rev
C1-202851	TA change during Authentication procedure in 5GMM-CONNECTED mode	Apple	CR 2092 24.501 Rel-16	Revision of C1-202264 Osama, Fri,07:58 should be POSTPONED Lin, Postponed _________________________________________ Lin, Fri, 07:18 Challenging the scenario Osam<>Krisztian disc only shown on previous agenda Lin, Tue, 03:46 CR not needed, covered Osama, Tue, 03:51 I won’t object if you change the CRs to be NW only impacting CRs Krisztian, Wed, 01:52 Explaining to Lin Krisztian, Wed, 02:01 To Osama, this is serious concern, rev sama, Wed, 02:39 Not convinced, should be discussed in SA3, LS to SA3 could be a way forward Lin, Wed, 05:06 Not agreeing with Krisztian Krisztian, Wed, 08:27 Ongoing Krisztian, Wed, 08:33 To Osama, SA3 not needed Osama, Wed, 20:22 Has issues Krisztian, Thu, 07:09 Not agreeing with Osama Lin, Thu, 09:29 Comments, if that are taken on board, he can live with it Lin, Thu, 09:29 Comments, if that are taken on board, he can live with it, 2851 requires rev
C1-202691	Correction to handling of T3447 timer	MediaTek Inc.	CR 3370 24.301 Rel-16	Revision of C1-202520 _________________________________________ Frederic, Thu, 09:08 Clauses affected missing Kaj, Thu, 13:57 1st change, we prefer to keep it on a NAS level Lin, Fri, 05:08 Don’t touch bullet 1, not force MME to look into RRC cause in a NAS procedure Sung, Tue, 22:01 Prefers wording from Lin Marko, Wed, 13:04 Ok to change wording Kaj, Wed, 16:07 Questions Marko, wed, 16:34 Not convinced by last kaj proposal Lin, thu 11:02 Prefers simpler one
C1-202906	Clarification for the use of enhanced coverage in EPS	Samsung, Huawei, HiSilicon, InterDigital	CR 3339 24.301 Rel-16	Revision of C1-202645 Amer: OK ____________________ _____________________ Revision of C1-202088 Osama, Sat, 02:49 Some questions Mahmoud, Mon, 23:10 Asking for specific comments Osama, Mon, 23:36 Hinting at discussion of C1-202077 Mahmoud, Tue, 06:37 Will revise this doc, asking for specific comments Amer, Wed, comments Mahmoud, Thu, 06:28 Takes amer on board
C1-202822	New AT command for linking packet filters +CGLNKPF	MediaTek Inc. / JJ	CR 0687 27.007 Rel-16	Revision of C1-202539 _________________________________________ Frederic, Thu, 13:02 Incorrect tdoc template, wrong tdoc number on the cover page JJ, Fri, 15:04 Acks the cover sheet problem Atle, Mon, 13:40 Comments JJ, Mon, 14:13 Providing a rev JJ, Mon, 17:17 New rev Atle, Tue, 00:32 fine
C1-202804	Correction on retry restriction for ESM#66	Huawei, HiSilicon/Lin	CR 3363 24.301 Rel-16	Revision of C1-202484 _________________________________________ Osamah, Thu, 21.19 Proposed deletion is not correct and discussion in the cover sheet is not correct either Lin, Tue, 12:14 Does not agree with Osama Osama, Tue, 16:43 Not agreeing Lin, Wed, 11:15 Defending Osama, Wed, 20:58 FINE with the CR
C1-202798	Retry restriction for NB-IoT UEs due to out of tariff package	Huawei, HiSilicon/Lin	CR 3357 24.301 Rel-16	Revision of C1-202468 _________________________________________ Osamah, Thu, 18:58 Untick UE box Lin, Fri, 11:01 Acks Lin, thi 04:07 Rev
C1-202797	WUS assistance for emergency	Huawei, HiSilicon/Lin	CR 3355 24.301 Rel-16	Revision of C1-202466 _________________________________________ Lin, Tue, 10:25 Provides a rev to cover discusson of the 5G cr
C1-202823	New AT command for deleting packet filters +CGDELPF	MediaTek Inc. / JJ	CR 0688 27.007 Rel-16	Revision of C1-202540 _________________________________________ Frederic, Thu, 13:02 Incorrect tdoc template, wrong tdoc number on the cover page JJ, Fri, 15:04 Acks the cover sheet problem Atle, Mon, 13:40 comments JJ, Mon, 17:22 New rev Atle, Tue, 01:02 More questions JJ, Tue, 10:37 Rev Atle, Tue, 14:24 fine
C1-202681	NAS Message Container 2 for LPP/LCS messages	MediaTek Inc., Qualcomm Incorporated	CR 3308 24.301 Rel-16	Postponed Revision of C1-202502 _________________________________________ Revision of C1-198902 Kaj, Thu, 14:11 Not in favour to add this for EPS Lin, Fri, 04:47 in principle, we also do not support to have it in legacy EPS Marko, Tue, 09:44 There is a requirement in stage-2 Lin, Wed, 10:14 Comments Marko, Wed, 16:40 Fine with lin comment Kaj, Wed, 17:42 NOT ok Lin, Thu, 10:58 Should not do this
Wis for IMS	Jörgen – Breakout
MCCI_CT	Mission Critical Communication Interworking with Land Mobile Radio Systems 100%
C1-202610	Editorial corrections	Sepura Ltd, Hytera Communications Corp	CR 0001 29.582 Rel-16	Revision of C1-202286 _________________________________________ Jörgen (Thu 19:48): Tick the CN box. Kit (Tue 16:54), Jörgen (Tue 17:11) Done, no further comments
MCProtoc16	Jörgen – Breakout	Protocol enhancements for Mission Critical Services for Rel-16 100%
C1-202555	Corrections to step reference in terminating controlling function	Samsung	CR 0560 24.379 Rel-16	Mike (Fri 22:44): OK
C1-202556	Corrections to step reference in create a group regroup using preconfigured group	Samsung	CR 0561 24.379 Rel-16	Mike (Fri 22:44): OK
C1-202557	Corrected the client origination procedure subclause text of 11.1.6.2.1.1	Samsung	CR 0562 24.379 Rel-16	Mike (Fri 22:44): OK
C1-202558	Allow an emergency and immenit peril calls during max simultaneous sessions	Samsung	CR 0563 24.379 Rel-16
C1-202630	Check regroup ID	FirstNet / Mike	CR 0553 24.379 Rel-16	Revision of C1-202220
C1-202631	Clarification of 11.1.6.2.1.2	FirstNet / Mike	CR 0554 24.379 Rel-16	Revision of C1-202221
C1-202632	Update affiliation definition to support preconfigured regroups	FirstNet / Mike	CR 0555 24.379 Rel-16	Revision of C1-202222 _________________________________________ Jörgen (Thu 21:03): Unclear definition. Mike (Thu 23:12), Francois (Fri 12:00), Mike (Fri 15:54), Francois (Fri 17:10), Kiran (Fri (17:40): Discussion on affiliation definition. Mike (Fri 19:08) Jörgen (Sat 18:44) Conclusion seems to be that simplified definition is to be provided by Mike. Francois (Tue 12:16): Fine with the revision
C1-202656	Check for MCPTT ID bindng and validity period of existing binding	Samsung	CR 0557 24.379 Rel-16	Revision of C1-202552 _________________________________________ Francois (Fri 12:44): Some missing steps Kiran (Fri 13:47): Acknowledges. Kiran (Tue 09:23), Francois (Tue 12:22): revision in drafts folder, Francois agree.
C1-202657	Corrections to location sharing during call setup	Samsung	CR 0558 24.379 Rel-16	Revision of C1-202553 _________________________________________ Jörgen (Thu 21:12): Some editorials and styles guidelines. Kiran (Fri 10:55): Checking understanding. Jörgen (Sun 15:43), Kiran (Mon 11:15), Mike (Mon: 15:07), Kiran (Mon 15:18), Jörgen (Mon 17:10): Seems to have converged on the wording. Kiran (Tue 09:23): revision in drafts folder
C1-202658	Corrections to current talker location in ambient call	Samsung	CR 0559 24.379 Rel-16	Revision of C1-202554 _________________________________________ Jörgen (Thu 21:16): Is note same as bullet b). Some editorial. Kiran (Fri 11:23): Checking understanding Mike (Fri 16:28): Further comment. Jörgen (Mon 15:03), Kiran (Mon 15:03): Seems converging on the wording. Further comments awaited. Kiran (Tue 09:25): revision in drafts folder
C1-202659	Authentication of the MIKEY-SAKKE I_Message validation in pre-established session	Samsung	CR 0230 24.380 Rel-16	Postponed Revision of C1-202559 _________________________________________ Jörgen (Thu 21:19): Should Reason Code field be updated instead? Kiran (Fri 11:41): Prefer Warning text. Jörgen (Sun 16:11): Not convinced, not clear which text to insert. Kiran (Mon 13:21): Text messages and the mechanism exist. Mike (Mon 15:37): Text is likely of minor value, but should continue to use it unless good reason. Kiran (Tue 09:35): revision in drafts folder. Jörgen (Tue 17:04), Still not convinced, should be Cat B, which code to provide is no specific enough. Francois (Tue 17:24): Agree to not use text from 24.379. Prefer reason code. Why warning added to Disconnect message, it is not used.
C1-202660	Talker location sharing in remote ambient call	Samsung	CR 0231 24.380 Rel-16	Revision of C1-202560 _________________________________________ Jörgen (Thu 21:21): Some clarifications needed. Kiran (Fri 12:36): Checking understanding. Jörgen (Sun 16:37), Kiran (Mon 13:53): Seems converging, await further comments before revising. Kiran (Tue 09:40): revision in drafts folder. Jörgen (Tue 18:15), remaining editorial Kiran (Wed 09:30) Ack, will be fixed. Seems to have converged.
C1-202834	Authorisation validation for first-to-answer call origination requesting user using pre-established session	Samsung	CR 0556 24.379 Rel-16	Revision of C1-202655 _________________________________________ Revision of C1-202551 _________________________________________ Francois (Fri 12:29, 17:15), Kiran (Fri 13:14): Discussion if this should be done in other places. Jörgen (Thu 21:10): Validation misplaced Kiran (Fri 08:39): Ack, and proposes alternatives Mike (Fri 16:23): States a preference Jörgen (Sun 17:44), Mike (Mon 05:49), Kiran Mon (08:42): Different text proposals. Seems to have converged. Kiran (Tue 09:10), Francois (Tue 12:19), Jörgen (Tue 13:11): revision in drafts folder. Francois and Jörgen are fine. Mike Tue and Kiran Wed agree on a further editorial
MuD	Jörgen – Breakout	Multi-device and multi-identity 100%
C1-202494	Text for empty headings	Ericsson /Jörgen	CR 0001 24.174 Rel-16
C1-202586	Reference update for PASSporT Extension for Diverted Calls	Orange / Mariusz	CR 0002 24.174 Rel-16
IMSProtoc16	Jörgen – Breakout	IMS Stage-3 IETF Protocol Alignment for Rel-16 100%
C1-202167	Adding the definition and criteria for availability of IMS Data Services	MediaTek Inc., Apple	CR 6415 24.229 Rel-16	Postponed Based on authors request, friday Frederic (Thursday 13:13): Styles corrupted, mark which clauses are new, remove and in bullet 1) and 2) of B.3.1.2B and U.3.1.2B. Simon (Thu 18:03): Not needed. References previous discussions. See the mail. Jörgen (Thu 21:33): Indicate dependency to NAS contribution. Data off might need stage 1, some other details. Rohit (Fri 06:17, 07:38): Useful for RCS, data should be separated from voice. Will indicate dependency and fix issues in update. Can stage 1 be added later? Takayuki (Fri 09:22): Is IMS data services defined somewhere? Bill (Sat 8:53): See no need. Rohit (Mon 03:12): Further motivations why this is necessary. Simon (Mon 19:00), Rohit (Tue 11:30): Further discussion and no conclusion yet. Simon (Wed 05:40), Rohit (Wed 11:33), Yoshihiro (Wed 12:49): No convergence between Simon and Rohit. Yoshir asking about stage1/stage2 requirements.
MCSMI_CT	Jörgen – Breakout	Mission Critical system migration and interconnection
eMCData2	Jörgen – Breakout	CT aspects of Enhancements to Functional architecture and information flows for Mission Critical Data
C1-202637	Deposit an object	AT&T	CR 0118 24.282 Rel-16	Revision of C1-202023 _________________________________________ Frederic (Thu 14:23): Cover sheet issues: - Wrong rev counter: should have been ‘-‘. This also applies to several CRs of this set: C1-202024, 2026, 2027, 2028, 2029, 2030 Jörgen (Fri 15:43): Some editorials, question on configuration. Shahram (Fri 16:48, Fri 17:34): Responses Shahram (Sat 05:35): Typo in previous mail Jörgen (Sun 16:53): Any MO in 24.483? Shahram (Mon 09:22): This is the server that is configured. Should MO clauses reference RCC.14? Jörgen (Mon 19:01): Clarification of previous comments. Shahram (Tue 09:26): [draft] C1-202637 was C1-202023.docx is now available in inbox/drafts.
C1-202640	Create a subscription to notifications	AT&T	CR 0119 24.282 Rel-16	Revision of C1-202024 _________________________________________ Jörgen (Mon 11:43): Bullets 1) and 2 should be merged. Shahram (Tue 09:27): [draft] C1-202640 was C1-202024.docx is now available in inbox/drafts.
C1-202641	Delete a subscription to notifications	AT&T	CR 0120 24.282 Rel-16	Revision of C1-202025 _________________________________________ Shahram (Tue 09:28): [draft] C1-202641 was C1-202025.docx is now available in inbox/drafts.
C1-202643	Update a subscription to notifications	AT&T	CR 0121 24.282 Rel-16	Revision of C1-202026 _________________________________________ Jörgen (Mon 11:45): and/or in first bullet to be avoided. Shahram (Mon 12:35): Text proposed. Shahram (Tue 09:28): [draft] C1-202643 was C1-202026.docx is now available in inbox/drafts.
C1-202646	Synchronization notification	AT&T	CR 0122 24.282 Rel-16	Revision of C1-202027 _________________________________________ Frederic (Thu 14:26): Some comments: - As already indicated, wrong rev counter on cover sheet - Discrepancy between clauses affected, which specify 21.2.16 and the actual changes, which use .X - No need to number the new note Shahram (Fri 19:26), Jörgen (Sun 17:13), Shahram (Mon 10:15), Jörgen (11:15): Some further discussion of style in text. Shahram (Tue 09:29): [draft] C1-202646 was C1-202027.docx is now available in inbox/drafts.
C1-202647	Search-based Synchronization	AT&T	CR 0123 24.282 Rel-16	Revision of C1-202028 Jörgen (Mon 12:58): Two minor editorials: There are curly quotes and recepectivelyrespectively. Shahram (Tue 09:29): [draft] C1-202647 was C1-202028.docx is now available in inbox/drafts.
C1-202649	List folder	AT&T	CR 0124 24.282 Rel-16	Revision of C1-202029 _________________________________________ Shahram (Tue 09:30): [draft] C1-202649 was C1-202029.docx is now available in inbox/drafts.
C1-202677	Typo fixes	AT&T	CR 0125 24.282 Rel-16	Revision of C1-202030 _________________________________________ Frederic (Thu 14:17): Cover sheet issues: - Wrong rev counter: should have been ‘-‘ - Source to TSG should be C1.
C1-202750	Configuration of resource priority for MCData emergency	AT&T / Val	CR 0137 24.484 Rel-16	Revision of C1-202386 _________________________________________ Kiran (Thu 12:25): 1) New elements shall be added to AddExt elements. 2) The schema shouldn't be changed in my understanding. 3) Update the MCPTT reference with MCData as it is for MCData service. Val (Sun 04:21, Sun 20:59): draft rev1 C1-202386 available in drafts folder. Mike (Mon 18:20), Kiran (Tue 16:42): Fine with the revision.
C1-202751	Auxiliary procedures in support of Emergency Alerts for MCData	AT&T / Val	CR 0130 24.282 Rel-16	Revision of C1-202288 _________________________________________ Kiran (Thu 12:25): The subclause 6.3.7.1.1 shall be added once we include the emergency flows for the MCData sub functionalities such as SDS and FD. As both the sub-services has session and non-session based flows and requires careful considerations. Val (Sun 06:36, Mon 08:42): Editor's note added, draft_rev1_C1-202288_24282CR130_AuxProcEmrgAlrt_MCData.doc in draft folder. Kiran (Tue 15:33): Fine with revision.
C1-202754	Handling of MCData Emergency Alerts at the MCData controlling server	AT&T / Val	CR 0129 24.282 Rel-16	Revision of C1-202287 Kiran (Thu 12:45): The 'emergency-ind' handling procedures may be added later once we bring the communication related procedures. - In subclause 16.2.3.2, Which covers the indication 'emergency-ind' shall be removed. We should cover only for the emergency alert functionalities as per the CR. Val (Sun 06:25, Mon 07:55): Prefer keeping the functions, will add editor's notes, uploaded draft_rev1_C1-202287_24282CR129_EmrgAlrt_MCData_cntrlingSrvr.doc to drafts folder. Kiran (Tue 15:42): Fine with revision.
C1-202755	Handling of MCData Emergency Alerts at the MCData participating servers	AT&T / Val	CR 0128 24.282 Rel-16	Revision of C1-202281 _________________________________________ Kiran (Thu 12:45): The 'emergency-ind' handling procedures may be added later once we bring the communication related procedures. In subclause 16.2.2.2, The step 1) which covers the indication 'emergency-ind' shall be removed. We should cover only for the emergency alert functionalities as per the CR. Francois (Fri 15:04, 17:21), Mike (16:15): Further discussion on applicability of the note. Val (Sun 02:38, Sun 06:20, Mon 06:46): Some responses, and draft_rev1_C1-202281_24282CR128_EmrgAlrt_MCData_participSrvr.doc uploaded in the drafts folder. Francois Tue (12:24), Kiran (14:08, 15:45): Fine with the revision
C1-202761	Emergency Alerts for MCData – client procedures	AT&T / Val	CR 0127 24.282 Rel-16	Revision of C1-202262 _________________________________________ Kiran (Thu 12:44): 1) The 'emergency-ind' and 'MCData emergency group communication state' handling procedures may be added later once we bring the communication related procedures. 2) The steps 2) c), 3) and 4) in subclause 16.2.1.3, shall not be included as there are no relevant procedures are available. As per the CR, we should cover only for the emergency alert functionalities. 3) In subclause 6.2.1.1, the indication 'emergency-ind' shall be removed from the description. Val (Sun 04:40, Mon (06:12): Response to Kiran's points. Will use editor's notes. Uploaded draft_rev1_C1-202262_24282CR127_EmrgAlrt_MCData_client.doc in the drafts folder Val (Tue 09:33), Kiran (Tue 14:07, Tue 15:32): Rev 2 of draft, Kiran OK with way forward and rev 2. Draft: draft_rev2_Obsoletes_rev1_C1-202262_24282CR127_EmrgAlrt_MCData_client.doc
C1-202771	Support for MCData emergency alert and communications	AT&T / Val	CR 0126 24.282 Rel-16	Revision of C1-202260 _________________________________________ Kiran (Thu 12:27): Some thoughts on this CR, and mostly apply to similar CRs: We should cover for the emergency alert functionalities as of today as we have other supporting CRs for the emergency alert functionalities. The subclause related to communication shall be added once we include the emergency flows for the MCData sub functionalities such as SDS and FD. As both the sub-services has session and non-session based flows and requires careful considerations. Val (Sun 04:28, Sun 22:15): Response to Kirans comment, draft uploaded in drafts folder. Jörgen (Mon 13:24): Align affiliation with Mike's 2222, schema not BW compatible. Mike (Mon 18:28), Val (Tue 09:10), KiranTue (13:58, 15:32): Common understanding of definition and adding Editor's Notes. Abhishek (Tue 18:58): Define MCData emergency alert and MCData emergency communication.
C1-202794	Fix minor issues in MCData pre-etsblished session	Samsung / Sapan	CR 0131 24.282 Rel-16	Revision of C1-202452 Sapan (Mon 20:44): Offline comments to improve cover sheet. Draft revision in: https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_123e/inbox/drafts/C1-202452_eMCData2_Minor_Fixes_in_Pre-established_session_draft_rev_v1.zip
C1-202835	Corrections to file upload-download procedure as per stage 2 architecture changes	Samsung	CR 0133 24.282 Rel-16	Revision of C1-202654 _________________________________________ Revision of C1-202550 _________________________________________ Kiran (Tue 09:51): draft available with CR# in EN. Jörgen (Tue 11:25), Kit (Tue 11:42): Is the granularity of MCData client structure needed? Kiran (Tue 17:18): It is more exact and is used in other places. Prefer to agree and come back with new CR if needed. Mike (Wed 17:02), Kiran (Wed 17:48): Further discussion on client terminology.
E2E_DELAY (CT4)	Jörgen – Breakout	CT Aspects of Media Handling for RAN Delay Budget Reporting in MTSI 100%
VBCLTE (CT3 lead)	Jörgen – Breakout	Volume Based Charging Aspects for VoLTE CT
ISAT-MO-WITHDRAW	Jörgen – Breakout	Withdrawal of TS 24.323 from Rel-11, Rel-12, Rel-13 No CRs needed, listed for the sake of completeness 100%
MONASTERY2	Jörgen – Breakout	Mobile Communication System for Railways Phase 2
C1-202566	Work plan for the CT1 part of MONASTERY2	Nokia, Nokia Shanghai Bell	discussion Rel-16	Noted
C1-202567	Sub/Notify FA resolution analysis	Nokia, Nokia Shanghai Bell	discussion Rel-16	Noted Francois (Fri 16:40): Disagrees with comments on cons with SUBSCRIBE/NOTIFY.
C1-202569	Update service configuration to support limiting the number of authorized clients per MCPTT user	Nokia, Nokia Shanghai Bell	CR 0139 24.484 Rel-16	Postponed Kirin (Thursday 11:09): Harmonize the wordings from stage 2 to avoid the confusion. For e.g 'if the number of simultaneous service authorizations for that MCPTT user " Francois (Fri 17:00): Should be user profile? Lazaros (Tue 13:22), Francois (13:50), Kiran (16:27), Lazaros (17:26), Francois (17:54): Kiran fine with handling of his comments. Francois wants LS to SA1 (ccSA6) to ask if a parameter is in service configuration or user profile. LS proposed to be sent to SA1, cc SA6.
C1-202883	IPConnectivity extension to include IP Information	Kontron Transportation France	CR 0067 24.483 Rel-16	Revision of C1-202496 _________________________________________ Jörgen (Fri 18:38): Nodenode in the table cells. Leaf nodes should have a format other than "node" Peter B (Tue 09:56): uploaded revision, also off-line comments: https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_123e/inbox/drafts/C1-202496-24483-CR0067%20IP%20Connectivity%20Extension%20to%20include%20IP%20Information-rev1.docx Jörgen (17:15): Minor editorial Nodenode in the table cells.
C1-202884	IPConnectivity extension to include IP Information	Kontron Transportation France	CR 0138 24.484 Rel-16	Revision of C1-202497 _________________________________________ Kiran (Thursday 11:30): -The section 10.3.2.3, the type="IPInformationListEntryType" should be appended with 'mcdataup:' Result: type="mcdataup:IPInformationListEntryType" -The structure in 10.3.2.1 should expand the IPInformation element with all the sub-elements. Pedro (Thu 18:51) Francois (Friday 15:57) Jörgen (Fri 16:33): Further comments, see the mails. Pedro will help Peter in revising. Peter (Tue 10:01): draft uploaded Francois (Tue 12:02): Minor typo Kiran (Tue 16:21): Seems fine, MinOccurs and MaxOccurs can be harmonized Jörgen (Tue 17:27): Minor editorial, or can be comma.
C1-202885	IPConnectivity extension to include IP Information	Kontron Transportation France	CR 0132 24.282 Rel-16	Revision of C1-202498 _________________________________________ Kiran (Thursday 11:31): 1) Cover page: Reason for change: Needs re-wording as it doesn't provide the information of using pre-defined IP information of the user from user profile configuration can be used for IP connectivity. 2) The proposed text can be re-worded by removing 'Depending on implementation' from the beginning of text and retaining the remaining portion of the text. 3) It's not clear whether the IP information is used in the INVITE request while setting up or determine the MC ID based on the IP information present in the user configuration by comparing with IP connectivity resolved to target. Jörgen (Fri 16:42): Some further questions Peter (Tue 10:01): draft uploaded Kiran (Tue 16:05): Change back to 24.484 Peter (Tue 17:23), Jörgen (Tue 17:47): OK to change back. Peter (Tue 20:49) will use 24.484.
C1-202905	Resolution of called functional alias in first-to-answer calls	Nokia, Nokia Shanghai Bell	CR 0564 24.379 Rel-16	Postponed Revision of C1-202568 Francois: reservation Dom: reservation _________________________________________ Kiran (Thursday 11:09): - In subclause 11.1.1.4.2, step 12) a) can be reworded from "by generating a SIP INVITE request as specified in subclause 9A.2.2.2.x;" to "by performing actions as specified in subclause 9A.2.2.2.x;". - In subclause 9A.2.2.2.x, There is no end quote for 'Upon receipt of a "'. - In subclause 9A.2.2.2.x, the heading can be reworded from "Functional alias resolution from MCPTT server owning functional alias procedure" to either "Sending functional alias resolution request towards MCPTT server owning the functional alias procedure" or "Receiving functional alias resolution request from MCPTT client procedure". - In subclause 9A.2.2.3.x, the heading can be reworded from "Functional alias resolution procedure" to "Receiving functional alias resolution request procedure". - In subclause 9A.2.2.2.x, the new INVITE request has been generated and sent to the MCPTT server owning the Functional alias, on receiving the response there is no procedure defined to respond back to the request which is received. - In subclause 11.1.1.4.2, step 12) b) can be reworded based on above point and shouldn't refer to 9A.2.2.3.x. Shall refer to same entity handling request and response - In subclause 9A.2.2.3.x, step 2) a) and b) of the response will have duplicate copy of data. We need to somehow manage to have one copy of data. Francois (Fri 16:53): Security issues with MCPTT ID, <mcptt-request-uri> element does not support a list.
eIMS5G_SBA	Jörgen – Breakout	CT aspects of SBA interactions between IMS and 5GC
C1-202066	No impact from SBA on main body	Nokia, Nokia Shanghai Bell, Ericsson	CR 6408 24.229 Rel-16	Revision of C1-200353
C1-202675	Support scenario where the SCC AS sends a request to the HSS to retrieve the SRVCC data for the UE	BlackBerry UK Ltd.	CR 1299 24.237 Rel-16	Merged into C1-202837 and its revisions Revision of C1-202099 _________________________________________ Ivo (Thursday 13:47):- the 5G SRVCC should be indicated using "ue5GSrvccCapability". - UDM is unaware of UE's capability for SRVCC from E-UTRAN to GERAN/UTRAN as the UE only indicates this capability in EPS. John-Luc (Thursday 17:45): Whether or not the UDM knows this capability is not relevant in this CR. Please note that Nhss_imsSubscriberDataManagement Service API is between the SCC AS and HSS, per subclause 4.1 of 29.562. TS 29.526 actually specifies an attribute by the name “ueSrvccCapabilities”, which is an array of capabilities Ivo (Friday 14:44): the comments still stand: - UDM is unaware of UE's capability for SRVCC from E-UTRAN to GERAN/UTRAN as the UE only indicates this capability in EPS. John-Luc (Friday 14:47): How does the comment apply to the CR? The behavior specified in the CR is based on informati0on received from the HSS, not from the UDM. Ivo (Tue 01:10, 11:15), John-Luc (Tue 02:03, 16:16): Continued discussion. After todays conf call now discussion on merging.
enh2MCPTT-CT	Jörgen – Breakout	Enhancements for Mission Critical Push-to-Talk CT aspects 100%
eIMSVideo	Jörgen – Breakout	Video enhancement of IMS CAT/CRS/announcement services
C1-202817	Restrictions of providing video announcement	China Telecom,Huawei,China Unicom,HiSilicon / Michelle	CR 0076 24.628 Rel-16	Revision of C1-202356 _________________________________________ Yoshihiro (Mon 16:17): This is too restrictive. Proposes a Note. Jörgen (Mon 22:59): Is this a real or theoretical problem? Michelle (Tue 08:10), Jörgen (Tue 14:00), Helen (14:34), Jörgen (16:15), Michelle (Tue 16:15): Some further discussion. Note proposal by Jörgen Yoshihiro (Tue 16:29): Fine with Jörgen's text.
C1-202863	Use preconditions for CRS when terminating UE supports precondition	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0063 24.183 Rel-16	Revision of C1-202605 _________________________________________ Revision of C1-202156 _________________________________________ Simon (Thu 18:32): Statement that UE indicates Support for precondition in 18x without receiving support indication in INVITE breaks 24.229. Jörgen (Thu 21:56): Agree on the 18x issue, somewhat problematic to offer new media in UPDATE as the user cannot indicate consent and resources most likely not available. Helen (Fri 11:51): Don't want to add precondition in INVITE. Can AS use precondition anyway based on local policy? Simon (Sat 00:36) Not possible according to 24.229. Helen (Sat 11:38), Jörgen (Sun 23:05), Simon (Mon 05:13), Helen (Mon 05:17): Some further description on principles. Seems to start converging. Simon (Mon 20:17), Jörgen (Mon23:13), Helen (Tue 04:25): Some comments on precondition to term side, new draft uploaded: draft 2605 Jörgen (Tue 15:04): Answers to questions
C1-202891	Use preconditions for CAT when originating UE supports precondition	Huawei,China Telecom,China Unicom,HiSilicon /Hongxia	CR 0119 24.182 Rel-16	Revision of C1-202604 _________________________________________ Revision of C1-202155 _________________________________________ Jörgen (Thu 21:46) NOTE: No Tdocnumber in Subject line: Text needs more work, some wording proposals. Helen (Fri 10:54): Agree to some comments, som responses on others. Yoshihiro (Fri 16:47): The change from "the originating UE requires" to "if the AS sends an 18x…" seems to change the meaning Helen (Sat 04:18), Yoshihiro (Mon 16:02): Continued discussion. One of the issues is how optional use of preconditions is for CAT media if preconditions is negotiated end to end. Jörgen (Mon 23:48): Issues with current text. Hiroshi: (Tue 04:10): issuse with can or may, partly cover sheet. Helen: Tue 11:29): checking wording of one paragraph.
Other Rel-16 IMS & MC issues	Jörgen – Breakout	Other Rel-16 IMS topics
C1-202072	Correction in CRS interactions with CDIV	Orange / Mariusz	CR 0062 24.183 Rel-16
C1-202080	UE must not render local tones in case of call is being forwarded or call is queued	Qualcomm Incorporated	CR 0075 24.628 Rel-16
C1-202081	NG eCall support over NR connected to the 5GC	Qualcomm Incorporated	CR 6414 24.229 Rel-16
C1-202132	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
C1-202759	Correction in IMS_Registration_handling policy about how UE should deregister	MediaTek Inc.	CR 6404 24.229 Rel-16	C1-202090 was proived on time and has been reviewed. C1-202590 was revised before submission and not provided. This document is considered a revision of C1-202090. Revision of C1-202590 _________________________________________ Not provided on time Revision of C1-202090 Revision of C1-199028
C1-202837	SRVCC from E-UTRAN to GERAN/UTRAN when IMS voice call is initiated in 5GS	Ericsson / Ivo	CR 1298 24.237 Rel-16	Revision of C1-202133 _________________________________________ Revision of C1-200941 Alternative to C1-202094 – C1-202097 John-Luc (Thu 19:32): Overlap with C1-202099, may need changes. Several comments, see the mail: -misuse of g.3gpp.accesstype -no rel-15 support -diverges from Rel-10 principles -missing use case at SCC AS -a condition in D.3.3 is included but not defined. Ivo (Fri 14:39): General disagreement with John-Luc. The reader is referred to the mail, this margin is too small. John-Luc (Fri 22:50), Ivo (Mon 10:14), John-Luc (Mon 15:06). Further comments on the conditions, still clash with C1-202099. Latest draft revision in https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_123e/inbox/drafts/C1-20iaea-was-C1-202133-was-C1-200941-was-C1-200674-v01.zip
C1-202887	Correction on rendering local tones	Ericsson /Jörgen	CR 0077 24.628 Rel-16	Postponed Revision of C1-202500
C1-202917	Editorial clean-up	Ericsson /Jörgen	CR 0064 24.183 Rel-16	Revision of C1-202785 _________________________________________ Revision of C1-202488 _________________________________________ Helen (Thu 13:54): Why not use GW model for CRS? "The media types can be…": With this change, it seems not cover audio CRS in video call. 4.3.1.2 and 4.3.1.3: The network needs to support AS actions, so different requirements. maybe there is a typo in the change of 4.3.1.3, “originating” should be ” terminating” Mariusz (Thu 14:27): 4.5.5.3.6: Remove comment, insert space in are-INVITE. Jörgen (Thu 22:15): Agree with Mariusz. Response to Helen. Helen (Fri 22:15) Jörgen (FriI (17:29): Ongoing discussion, mainly of the applicability of gateway model towards terminating user. Helen (Sat 11:56), Jörgen (Sun 23:16), Helen (Mon 05:07), Rohit (Mon 05:27): Further discussion on terminology, clarifying viewpoints.
Release 17 work items	Tdoc	NOT PART OF THIS MEETING
Output Liaison Statements	Tdoc	Title	Prepared by	To/CC	Result & comment
C1-202012	Reply LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	Ericsson / Ivo	LS out Rel-16	Withdrawn Reply to incoming LS in C1-202045 Lena, Mon, 00:23 1.1, 1.2,2.1,2.2 OK, 1.3 NOT ok
C1-202103	Reply LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	Qualcomm Incorporated / Lena	LS out Rel-16	Merged into C1-202240 Chairman, based on confcall#1 Reply to incoming LS in C1-202045 Ivo, Thu, 13:49 Answer to Q 1.3 not OK
C1-202151	LS on subscribe/notify for 5G Steering of Roaming	DOCOMO Communications Lab.	LS out Rel-16	Merged into C1-202067 Chairman, based on conf call Reply to incoming LS in C1-202041 Ivo, Thu, 13:51 Prefers mechanism as in C1-202069, hence, prefers LS in C1-202067 Ivo, Mon, 12:37 commenting
C1-202180	[draft] Reply LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	vivo	LS out Rel-16	Merged into C1-202240 Chairman, based on confcall#1 Reply to incoming LS in C1-202045 Ivo, Thu, 13:52 to be provided by SA2, 1.2 inonsitent, 1.3 not OK Lena, Mon, 00:27 outside CT1, disagrees wih 1.2, 1.3 and 2.2 OK Yanchao, Mon, 11:58 Asking for info from Lena
C1-202204	LS on PWS Test Flag	one2many B.V.	LS out Rel-16	Postponed We have not seen the incoming LS
C1-202474	LS on handling pending NSSAI during ongoing NSSAA	Huawei, HiSilicon/Lin	LS out Rel-16	Postponed Lin wanted this to be postponed in ConfCall#3 Related to C1-202472 (discussion paper) and C1-202473 (CR). Roozbeh, Mon, 22.07 Not convinced it is needed, would not object Atle, Tue, 02:39 Do not agree to send the LS at least not in its current form Sung, Tue, 07:31 Asking from atle info on SA2 docs Atle, Tue, 10:04 Gives a tdoc number Kaj, Tue, 13:53 If sa2 gets agreed, then no need to send the LS Atle, Tue, 14:14 Sa2 conclucion to be seen Atle, Wed, 00:15 Does not agree to this LS Lin, Wed, 04:53 If SA2 cr gets agreed, then LS is not needed Atle, Wed, 07:46 Against sending the LS
C1-202564	Reply LS on concurrent Broadcasting for CMAS	Samsung/ Kyungjoo Grace Suh	LS out Rel-15	Merged into C1-202232 and its revisions Chairman, based onconfcall#1 Reply to incoming LS in C1-202046/C1-202597 Lena, Mon, 00:30 Prefers the LS out in 2232
C1-202359	LS response on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	Samsung/Kundan	LS out Rel-16	Merged into C1-202240 Chairman, based on confcall#1 Shifted from 16.2.7.1 Reply to incoming LS in C1-202045 Ivo, Thu, 13:32 Does not agree with answer to 1.3
C1-202617	LS on manipulation of CAG Information element by a VPLMN	Kundan	To: Sa2, Cc Sa3	New Ivo, Mon, 22:28 Comments Sung, Mon, 23:39 Commenting Kundan, Tue, 06:12 Fine with Ivo Kundan, Tue, 06:37 Providing rev Ban, Tue, 11.23 Comments Kundan, Tue, 13:26 Answering Sung Tue, 15:47 Why would CT1 care about amf<>udm Kundan, Tue, 16:59 Further to Sung Sung, Tue, 17:52 Does not agree Kundan, Wed, 06:41 Rev, only one question remains Sung, Wed, 18:15 Fine, some minor comments Kundan, thu, 05:47 Asking for comments on latest rev Ivo, Thu, 07:48 fine
C1-202663	Reply LS on Non-UE N2 Message Services Operations	PeterS	Revision of C1-202663 New Ban, Wed, 18:20 Good
C1-202666	LS on security context for 5GC to EPC mobility	Lin	Sung, Wed, 02:58 Comments on the rev New rev2 Sung, FINE Lena, Thu,05:25 comments
C1-202753	LS on handling registration procedure for CAG only UE at non supporting AMF	Kundan	Withdrawn New Draft of LS is available, related to 2363 In the ConfCall Ivo, Sung, Lena: no need for the LS Kundan, Wed, 18:16 Replying confcall comments Sung, Wed, 18:25 Commenting Lena, Thu, 05:52 No need to send an LS
C1-202826	LS on selected EPS NAS algorithms for unauthenticated emergency sessions in 5GS	Mahmoud	New Draft available
C1-202849	LS on PDU session release for UE in RRC INACTIVE state with NG-RAN paging failure	Sung	Postponed New Draft available Sung Lin discussing Ivo discussing Lin suggests new wording Sung and Lin discussing
C1-202911	LS on 3GPP based access authentication for untrusted non-3GPP access to 5GCN	Ericsson / Ivo	LS out Rel-16	Revision of C1-202487 Roozbeh: I think a better way is company contribution to SA2 John-Luc: support Andrew: support Lena: I see no reason why this should be triggered via CT1, : I object to this LS. Ivo: should be sent _________________________________________ Roozbeh, Thu, 21:57 SA2 in “To”, suggests rewording Lena, 00:03 Not specific to 5WWC, rather 5Gprotoc16, not inline with SA3 decission, why would CT1 give a security requirement to SA3? Ivo, Tue, 10:57 Comenting Roozbeh, Wed, 00:24 Ls not needed to SA3 John-Luc, Wed, 01:06 Some proposal regarding LI Lena, Wed, 06:27 Why is CT1 giving sec requirement to SA3ß Lazaros, Wed, 09:39 Not needed Roozbeh, Wed, 19:52 Same as azaros
C1-202668	Reply LS on 5G Steering of Roaming	Orange / Mariusz	LS out Rel-16	Revision of C1-202067 Reply to incoming LS in C1-202041 Ivo, Thu, 13:49 Don’t use ”may not”, if CR gets agreed, then solution to be described in the LS Ban, Sat, 13:12 Commenting, how to merge the two LSs Ivo, Mon, 12:27 Commenting Sung, Tue, 02:36 Highlighting Q3 to be answered, asking a question Ivo, Tue, 12:18 Commenting Mariusz, Tue, 12:59 Providing azarosion Ban, Tue, 13:20 Commenting Ivo, Tue, 14:26 providing “access technology” is not acceptable for Ericsson. Sung, Tue, 17:57 Now sees how access technology can be derived from RAT, asks for changes in the answer to Q3 Ban, Tue, 17:59 Further rcomments Mariusz, Tue, 18:50 Rev Sung, Tue, 19:02 Q3 not ok Ban, Tue, 20:19 Rev Sung, Tue, 21:30 Not convinced yet Ban, Wed, 09:44 Explaining Mariusz, Wed, 11:00 New rev Ban, Wed, 12:40 Looks good only Q1 and Q2 Sung, Wed, 15:07 We are against to providing RAT type, access technology, or access type to SOR-AF. Sung, Wed, 18:00 Non consensus on Q3 Ivo, Wed, 18:40 Now suggestion for Q3 Ban, Wed, 18:49 Not agreeing on Q3 Ivo, Wed, 18:55 Not agreeing on all parameters being optional Ongoing. … Marius New rev Ivo, Thu, 10:22 Rev is not ok
C1-202927	LS on manual CAG selection	Nokia, Nokia Shanghai Bell	LS out Rel-16	Revision of C1-202400 -------------------------- Revision of C1-201053 Ivo, Thu, 13:53 LS requires agreed CR to be, EN in LS to be updated based on outcome of CR Sung, thu, 03:21 New rev
C1-202846	Reply LS to RAN2 on Manual CAG selection	Huawei, HiSilicon / Vishnu	LS out Rel-16	Revision of C1-202240 _________________________________________ Shifted from 16.2.7.2 Reply to incoming LS in C1-202045 Ivo, Thu, 13:08 Answer to 1.1 not needed, 1.2 partly ok, 1.3 not oke Vishnu Tue, 11:16 New revision form Vishnu Lena, Wed, 06:32 Rev looks good Chen, Wed ,10:38 Some proposal on 2.2 Ban, Wed, 11:08 Overall good, some sympathy for chen request Ivo, Wed, 11:11 Some comments Vishnu, Wed, 12:40 Ongoing Robert, Wed 13:43 Answering Ivo Ivo, Wed 15:00 Ongoing Vishnu, with rev number
C1-202925	LS on the requirement that non-3GPP access node selection information includes an “any PLMN” entry	John-Luc	Postponed Revision of C1-202847 Amer: not completey happy, will not object of he is the only one Ivo, Friday, 10:29 Requests this to be postponed __________________________ Revision of C1-202665 _________________________________________ New Ivo, Wed, 12:20 No need to send the LS, is incorrect John-Luc, Wed, 14:55 Answering Confcall Ivo, amer, negative Lazaros LS not needed, CR seem to have a point Christian there is an FASMO, LS neutral Andrew, Wed, 22:49 Supports sending an LS John Luc, Wed, 00:00 Rev Lazaros, Thu, 00:29 No strong objection, i.e. can live with it Amer, Thu, 03:41 Sending LS is not the right approach
C1-202916	LS on Concurrent Broadcasting for CMAS	Ericsson / Mikael	LS out Rel-15	Revision of C1-202232 _________________________________________ Reply to incoming LS in C1-202046/C1-202597 Mikael, Wed, 15:19 Draft which has CR attached PeteS: looks fine Lazaros, fine, could live without the attachment, minor editorial
C1-202819	LS on limit the number of simultaneous log ins of an MCX	Nokia /Lazaros	LS out Rel-16	Endorsed by IMS BO
C1-202993	PAP/CHAP and other point-to-point parameters usage in 5GS	Osama	Revision of C1-202667 To addres the “e.g.” to be “i.e.” comment from Ivo Ivo is fine with the comment _________________________________________ New Rev available, Wed, 16:02 all comments on board Jj fine
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
C1-202135	Discussion on SRVCC and 5G-SRVCC NAS capabilities vs. IMS based solution	BlackBerry UK Limited	discussion Rel-15	Withdrawn Not available on time
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 23rd April 2020 16:00 CEST Last comments: Friday 24th April 2020 16:00 CEST Chairman Report of the meeting: Monday 27th April 2020