3GPP TSG-SA WG1 Meeting #90e

Electronic Meeting, 18-22 May 2020

tdoc list SA1#90e draft list

For the hyperlinks to work:

1) unzip this tdoc list on your PC and place the .doc file in the folder you wish (let's call it ...\meeting_x)

2) place all the zipped tdocs in the subfolder ...\meeting_x\tdocs

3) you might have to refresh the fields. To do this, select all (CTL+A) and press F9.

Sort by "order" (specifying a sort by "text" and not "number") to list the tdocs by agenda items.

Order	Ag.Item	Tdoc #	Source	Title	Type	Spec	CR#	r	cat	Version in	Rel	WI	Summary	Discussion	Conclusion	Rev numb
1.1	S1-202000	Chair	Draft agenda for SA1#90	agenda	reserved
1.1	S1-202001	Chair	2nd Draft agenda for SA1#90	agenda	reserved
1.1	S1-202002	Chair	Agenda for SA1#90 with tdoc allocation	agenda	reserved
2	S1-202003	Chair	SA1-related topics at SA#86	report	Noted
2	S1-202004	Chair	SA1-related topics at SA#87	report	Noted
2	S1-202005	MCC	Draft minutes of SA1#88e	report	Revised	S1-202006
2	S1-202006	MCC	Minutes of SA1#88e	report	Approved
2	S1-202007	MCC	Draft minutes of SA1#89e	report	Revised	S1-202008
2	S1-202008	MCC	Minutes of SA1#89e	report	Approved
2	S1-202009	MCC	Workplan presentation for SA1#90	Work Plan	Noted
2	S1-202010	MCC	TR 21.916 on Rel-16 Summary	21.916	0.5.0	Rel-16	TEI16	withdrawn
1	3.01	S1-202021	R2-1916345	LS on CMAS/ETWS and emergency services for SNPNs	LS in	Postponed from previous meeting. Was S1-201006. Question 1) Whether CMAS/ETWS needs to be supported by SNPNs? Question 2) Whether a UE in SNPN Access Mode without a suitable SNPN serving cell needs to be able to receive CMAS/ETWS notifications in limited service state from (a) a non-suitable SNPN cell or (b) a non SNPN cell?	available
2	3.01	S1-202024	S2-2001400	Reply LS on CMAS/ETWS and emergency services for SNPNs	LS in	Postponed from previous meeting. Was S1-201012	noted
3	3.01	S1-202084	Nokia, Nokia Shanghai Bell	Reply LS on CMAS/ETWS and emergency services for SNPNs	LS out	Revised	S1-202190
3r	3.01	S1-202190	Nokia, Nokia Shanghai Bell	Reply LS on CMAS/ETWS and emergency services for SNPNs	LS out	Replaces S1-202084 Both Nokia and Qualcomm propose (different) answers.	See 2089 on the same topic.	Revised	S1-202220
3rr	3.01	S1-202220	Nokia, Nokia Shanghai Bell	Reply LS to RAN2, SA2 (cc CT1) on CMAS/ETWS and emergency services for SNPNs	LS out	Replaces S1-202190	Agreed
4	3.01	S1-202089	Qualcomm Incorporated	Draft reply LS on CMAS/ETWS for SNPN	LS out	Rel-16	KPN clarified that this is not specified in Rel-16 but can be specified later on. This should be made clearer in the LS.	Noted
1	3.02	S1-202025	S2-2001726	LS on GSMA NG.116 Attribute Area of service and impact on PLMN selection	LS in	Postponed from previous meeting. Was S1-201013	Noted
2	3.02	S1-202086	Nokia, Nokia Shanghai Bell	reply LS on GSMA NG.116 Attribute Area of service and impact on PLMN	LS out	Revised	S1-202221
2r	3.02	S1-202221	Nokia, Nokia Shanghai Bell	reply LS to SA2, CT1, RAN2, RAN3, GSMA 5GJA, GSMA WAS on GSMA NG.116 Attribute Area of service and impact on PLMN	LS out	Replaces S1-202086 After consideration, SA1 determined a need to study how to efficiently give UEs access to needed network slices. SA1 has agreed to the attached SID to study use cases and generate potential requirements for Rel-18.	"Needed" to be changed in "required"	Revised	S1-202263
2rr	3.02	S1-202263	Nokia, Nokia Shanghai Bell	reply LS to SA2, CT1, RAN2, RAN3, GSMA 5GJA, GSMA WAS on GSMA NG.116 Attribute Area of service and impact on PLMN	LS out	Replaces S1-202221	Agreed.
1	3.03	S1-202026	S2-2001728	LS on 5GC assisted cell selection for accessing network slice	LS in	Postponed from previous meeting. Was S1-201014. One of the requirements documented in GSMA 5GJA NG.116 is to define the Radio Spectrum (clause 3.4.21) supported by the network slice. Specific frequency bands can be used to access a specific network slice(s). As part of the FS_eNS_Ph2 study, the combined use of the spectrum bands and the network slices as a possible tool for operators to offer the service isolation/management while allowing the maximum use of the 5G spectrum bands was proposed. The attached document (S2-2001467) provided further details on the key issue for such use case. SA2 requests SA1, RAN2 and RAN3 colleagues to examine the attached use case and to provide any feedback.	Proposed answers in 2097 (ZTE) and 2132 (Samsung), merged in 2191.	noted
2	3.03	S1-202072	R3-202558	Response to 5GC assisted cell selection for accessing network slice	LS in	RAN3's answer to 2026.	Noted
3	3.03	S1-202097	ZTE Corporation	Draft Reply LS on 5GC assisted cell selection for accessing network slice	LS out	ZTE and Samsung proposed answers are merged in 2191.	Revised	S1-202191
3r	3.03	S1-202191	ZTE Corporation	Draft Reply LS on 5GC assisted cell selection for accessing network slice	LS out	Replaces S1-202097. SA1 thanks SA2 for their LS on 5GC assisted cell selection for accessing network slice (S1-201014/S2-2001728). SA2 asks SA1 for feedback on the use case provided in S2-2001467. From stage 1 perspective, it is required. SA1 also would like to direct SA2 to requirements in TS 22.261 clause 6.1 where SA1 has defined that Network Slices can be further customised for operators to provide the optimal functionality of a complete network. Hence, an operator is always allowed to define specific capabilities and deployment configuration in network slices, this includes dedicated specific radio frequency to specific network slices.	Merging of ZTE and Samsung proposal. Ericsson and Apple mentioned that this is not the latest version proposed by e-mail.	Revised	S1-202193
3rr	3.03	S1-202193	ZTE Corporation	Draft Reply LS on 5GC assisted cell selection for accessing network slice	LS out	Replaces S1-202191 (equals 2097r2_E+Samsung.zip)	The text is still not agreeable and needs further off-line work (KPN not supporting the use case, wording issues, etc.)	Revised	S1-202222
3rrr	3.03	S1-202222	ZTE Corporation	Draft Reply LS to SA2 (cc RAN2, RAN3) on 5GC assisted cell selection for accessing network slice	LS out	Replaces S1-202193. SA1 would like to direct SA2 to a related requirement in TS 22.261 clause 6.1, SA1 has defined that Network Slices can be further customised for operators to provide the optimal functionality of a complete network. Hence, an operator is always allowed to define specific capabilities and deployment configuration in network slices, this includes dedicated specific radio frequency to specific network slices.	Revised	S1-202264
3rrrr	3.03	S1-202264	ZTE Corporation	Draft Reply LS to SA2 (cc RAN2, RAN3) on 5GC assisted cell selection for accessing network slice	LS out	Replaces S1-202222	Agreed.
4	3.03	S1-202132	Samsung Electronics GmbH	[DRAFT] LS on 5GC assisted cell selection for accessing network slice	LS out	Rel-17	Replies to SA2 that FS_eNS_Ph2 KI#7 is fine to pursue.	ZTE and Samsung proposed answers are merged in 2191.	noted
5	3.03	S1-202130	Samsung Electronics GmbH, AT&T	CR22.261v17.1.0 Operators dedicate resources for network slices	CR	22.261	0434	1	F	17.2.0	Rel-17	TEI17	Adds radio aspects managed by operators to achieve network slice objectives. Actual work item code used: TEI17, SMARTER.	available
1	3.04	S1-202036	R2-2002417	LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS in	Question 2.1; TO: SA1: Is there a requirement to enable PNI-NPN (CAG ID) specific access control in cells that are shared among PNI-NPNs belonging to the same PLMN? Question 2.2; TO: CT1, SA1: If there is a requirement to enable PNI-NPN (CAG ID) specific access control in cells that are shared among PNI-NPNs belonging to the same PLMN, then is it sufficient to broadcast the Unified Access Control (UAC) parameters per PLMN (assuming that using the operator-defined access categories with access category criteria type set to the S-NSSAI used for PNI-NPN is sufficient to provide CAG specific UAC) or there is need to enable the broadcast of CAG ID specific configuration of UAC parameters?	See CT1 answer in 2070. Proposed SA1's answer in 2188, 2159 and 2068.	Noted
10	3.04	S1-202159	Nanjing Ericsson Panda Com Ltd	Discussion paper related to Reply-LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	discussion	Rel-16	available
11	3.04	S1-202068	China Mobile Com. Corporation	Clarification on Manual CAG selection	CR	22.261	0444	F	17.2.0	Rel-17	NG_RAN_PRN-Core	noted
2	3.04	S1-202070	C1-202846	Reply LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS in	available
3	3.04	S1-202047	OPPO	[DRAFT] Reply LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS out	Rel-16	Revised	S1-202188
5	3.04	S1-202188	OPPO	[DRAFT] Reply LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS out	Rel-16	Replaces S1-202047. Answer to 2.1: SA1 currently does not have a requirement to enable PNI-NPN (CAG ID) specific access control in cells that are shared among PNI-NPNs belonging to the same PLMN. SA1 has discussed this issue and agreed to clarify that a new requirement to enable PNI-NPN (CAG ID) specific access control in cells that are shared among PNI-NPNs belonging to the same PLMN is needed. Answer to 2.2: From SA1’s point of view, there is a requirement to enable PNI-NPN (CAG ID) specific access control in cells that are shared among PNI-NPNs belonging to the same PLMN. SA1 believes that solutions for addressing this requirement is required and should be identified by CT1.	2194 is to be used as a basis for future revisions.	Noted.
6	3.04	S1-202065	China Mobile Com. Corporation	Reply LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS out	Revised	S1-202194
6r	3.04	S1-202194	China Mobile Com. Corporation	Reply LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS out	Replaces S1-202065(r1). A 2.1: SA1 currently does not have a specific requirement to enable PNI-NPN specific access control in cells that are shared among PNI-NPNs belonging to the same PLMN. SA1 agreed a CR to clarify NPN requirements in TS 22.261, by explicitly adding the requirement: “The 5G system shall support a mechanism for a PLMN to control the access of a UE in a specific geographic area (e.g. a cell or a group of cells) shared among non-public networks hosted by the same PLMN.” A2.2: SA1 thinks there is need to enable the broadcast of CAG ID specific configuration of UAC parameters. The reason is that the non-public networks hosted by the same PLMN may have different UAC configuration.	See companion CR in 2067. For Vodafone, there is still a need to clarify the wording ,e.g. for " The 5G system shall support a mechanism for a PLMN to control the access of a UE in a specific geographic area (e.g. a cell or a group of cells) shared among non-public networks hosted by the same PLMN.” This is the version to be used for future revision.	Revised	S1-202223
6rr	3.04	S1-202223	China Mobile Com. Corporation	Reply LS to RAN2 (cc CT1, SA2, RAN3) on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS out	Replaces S1-202194. A.2.1: SA1 currently does not have a specific requirement to enable PNI-NPN specific access control in cells that are shared among PNI-NPNs belonging to the same PLMN. A2.2: Since the answer to Q2.1 is no, answer to Q2.2 is not needed.	Nokia noticed that some terms are not SA1 terms but they are not objecting.	Revised	S1-202265
6rrr	3.04	S1-202265	China Mobile Com. Corporation	Reply LS to RAN2 (cc CT1, SA2, RAN3) on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS out	Replaces S1-202223	Agreed.
7	3.04	S1-202067	China Mobile Com. Corporation	Clarification on Manual CAG selection	CR	22.261	0443	F	17.2.0	Rel-17	NG_RAN_PRN-Core	noted
8	3.04	S1-202090	Qualcomm Incorporated	Draft reply LS on CAG ID and UAC	LS out	Rel-16	Covered by other answers. 2194 is to be used as a basis for future revisions.	Noted
9	3.04	S1-202113	Ericsson	Reply to LS on Manual CAG ID selection and granularity of UAC parameters for PNI-NPNs	LS out	Rel-16	Covered by other answers. Ericsson supports China Mobile's proposal. Also Deutsche Telekom. 2194 is to be used as a basis for future revisions.	Noted.
9r	3.04	S1-202151	Ericsson	Time synchronization budget for the 5G system	CR	22.832	0025	F	17.1.0	Rel-17	FS_eCAV	Linked to S1-202113	Revised	S1-202195
9rr	3.04	S1-202195	Ericsson	Time synchronization budget for the 5G system	CR	22.832	0025	1	F	17.1.0	Rel-17	FS_eCAV	Replaces S1-202151.	900 ns is agreed as a value
1	3.05	S1-202033	C1-200994	LS on the applicability of LADN in an SNPN	LS in	CT1 would like to ask SA2 to provide guidance on whether an SNPN can provide LADN service as well. Question. Can LADN service be provided by an SNPN?	Copied to SA1 but there is still a proposed answer in 2040.	Noted.
2	3.05	S1-202040	LG Electronics Polska	Reply LS on the applicability of LADN in an SNPN	LS out	Regarding the question raised by the LS, i.e. Can LADN service be provided by an SNPN?: (Alt.1) Answer 1: There is no requirement. I.e., there is no need to support LADN for SNPN. SNPN itself is available in some specific geographical region. The purpose of LADN overlaps the purpose of a SNPN deployment. (Alt.2) Answer 1: There is no need to restrict the use of LADN by SNPN. Though the purpose overlaps and complexity increases, because support of LADN is optional, use of LADN in SNPN should not be precluded.	Different alternatives are supported by different companies, no consensus. Vodafone propose not to answer, this is Stage 2 and 3's terminology, nothing for SA1. KPN share this view, who added that the 2 alternatives have in comment that there is no requirement. This can be the answer – if any answer at all. Deutsche Telekom supports Alternative 1. They propose to introduce a definition to "LAD". Sheinheiser and BBC supports altrenative 2. LG agrees not to answer, at least not at this stage (maybe after CT1 has answered).	Noted.
3	3.05	S1-202041	LG Electronics Polska	correction on the applicability of LADN in an SNPN	CR	22.261	0440	F	16.11.0	Rel-16	Vertical_LAN	related to incoming LS S1-202033	noted
1	3.06	S1-202069	C1-202819	LS on limiting the number of simultaneous log ins of an MCX user	LS in	available
2	3.06	S1-202060	Nokia Solutions & Networks (I)	Reply LS on limiting the number of simultaneous log ins of an MCX user	LS out	Rel-16	MONASTERY2	From operational perspective the limit of simultaneous logins has to allow to be set differently on a per MCX User basis to cater for different operational needs. The MCX Administrator might limit certain MCX Users to a low number of simultaneous logins down to just one, while others might be allowed to login on a higher number of MCX UEs.	Revised	S1-202224
2r	3.06	S1-202224	Nokia Solutions & Networks (I)	Reply LS on limiting the number of simultaneous log ins of an MCX user	LS out	Rel-16	MONASTERY2	Replaces S1-202060	Revised	S1-202262
2rr	3.06	S1-202262	Nokia Solutions & Networks (I)	Reply LS on limiting the number of simultaneous log ins of an MCX user	LS out	Rel-16	MONASTERY2	Replaces S1-202224	Revised	S1-202271
2rrr	3.06	S1-202271	Nokia Solutions & Networks (I)	Reply LS to CT (cc SA6) on limiting the number of simultaneous log ins of an MCX user	LS out	Rel-16	MONASTERY2	Replaces S1-202262. Does requirement [R-5.10-001a] of 3GPP TS 22.280 require that a different limit can be applied to each MCX User? SA1 have discussed the issue and the answer is No.	CR to be attached to the LS.	Revised	S1-202280
2rrrr	3.06	S1-202280	Nokia Solutions & Networks (I)	Reply LS to CT (cc SA6) on limiting the number of simultaneous log ins of an MCX user	LS out	Rel-16	MONASTERY2	Replaces S1-202271
3	3.06	S1-202061	Nokia Solutions & Networks (I)	Clarification on the maximum number limit of simultaneous log ins of an MCX user	CR	22.280	0139	F	16.7.0	Rel-16	MONASTERY2	While implementing the login mechanism CT1 spotted an ambiguity on how to interpret the maximum number of simultaneous logins specified in 22.280 [R-5.10-001a]. This CR clarifies that the limit is on a per MCX User basis and thus might be different from MCX User to MCX User	available
4	3.06	S1-202062	Nokia Solutions & Networks (I)	Clarification on the maximum number limit of simultaneous log ins of an MCX user	CR	22.280	0140	A	17.2.0	Rel-17	MONASTERY2	While implementing the login mechanism CT1 spotted an ambiguity on how to interpret the maximum number of simultaneous logins specified in 22.280 [R-5.10-001a]. This CR clarifies that the limit is on a per MCX User basis and thus might be different from MCX User to MCX User	Revised	S1-202234
4r	3.06	S1-202234	Nokia Solutions & Networks (I)	Clarification on the maximum number limit of simultaneous log ins of an MCX user	CR	22.280	0140	1	A	17.2.0	Rel-17	MONASTERY2	Replaces S1-202062	Revised	S1-202272
4rr	3.06	S1-202272	Nokia Solutions & Networks (I)	Clarification on the maximum number limit of simultaneous log ins of an MCX user	CR	22.280	0140	2	A	17.2.0	Rel-17	MONASTERY2	Replaces S1-202234	For FirstNet, the new requirement should be as a new bullet, not by changing an existing one.	Revised	S1-202279
4rrr	3.06	S1-202279	Nokia Solutions & Networks (I)	Clarification on the maximum number limit of simultaneous log ins of an MCX user	CR	22.280	0140	3	A	17.2.0	Rel-17	MONASTERY2	Replaces S1-202272	Rel-16 version in 2289
1	3.07	S1-202073	S2-2003216	Reply LS on Questions on onboarding requirements	LS in	Q2)SA2 would like to verify with SA1 whether the above-quoted requirement applies to PNI-NPN, which is the NPN “hosted by a PLMN” as described in TS 22.261 clause 6.25.1, or not, and what would be the corresponding use cases. Q3) If SA1 confirm the above-quoted requirement applies to PNI-NPN in Q2, SA2 have further Q3 as below.	Deutsche Telekom clarified that there were ambiguities in a first version of the SA2's LS, and these ambiguities were later solved, hence the odd format of this LS. Proposed answers in 2087, 2088 and 2109/2200.	noted
2	3.07	S1-202087	Nokia, Nokia Shanghai Bell	reply LS on Questions on onboarding requirements	LS out	Nokia supports other proposed answers and can withdraw theirs.	Noted
3	3.07	S1-202088	Qualcomm Incorporated	Draft reply LS on NPN onboarding requirements	LS out	Rel-17	Qc proposes to answer: "2 and 3: there is no requirement"	Open
4	3.07	S1-202109	China Mobile Com. Corporation	[DRAFT] Reply LS on Questions on onboarding requirements	LS out	Revised	S1-202200
4r	3.07	S1-202200	China Mobile Com. Corporation	[DRAFT] Reply LS on Questions on onboarding requirements	LS out	Replaces S1-202109. It is proposed to answer: A2 from SA1) Since PNI-NPN is a type of NPN, the above-quoted requirement applies to PNI-NPN. A3 from SA1) Yes, the case when 3rdparty identities and credentials are provisioned to be used for secondary authentication is a service requirement for onboarding and remote provisioning.	Huawei, Futurewei, Ericsson, ZTE and Nokia support the China Mobile's proposal. LG supports Qualcomm's answer. For Ericsson and KPN, there is a misunderstanding from LG and Qualcomm, as underlined by e-mail. Qualcomm and Vodafone would like some indication on where in SA1 documentation there are use case and/or requirement on secondary authentication. E-mail discussions to be continued.	Revised	S1-202225
4rr	3.07	S1-202225	China Mobile Com. Corporation	[DRAFT] Reply LS to SA2 (cc SA, CT1, SA3, CT6) on Questions on onboarding requirements	LS out	Replaces S1-202200. A2 from SA1) Since PNI-NPN is a type of NPN, the above-quoted requirement applies to PNI-NPN. A3 from SA1) Yes, the case when 3rdparty identities and credentials are provisioned to be used for secondary authentication is a service requirement for onboarding and remote provisioning.	For Qualcomm and LG, there is no text on the permanent answer, and propose to have a more permanent solution defined by SA1 (e.g. with a CR to the requirements) before answering. For KPN, there will be no better text in a short future, so this version of the LS is good enough. For Ericsson, this is quite late on the last day to object, repeating the arguments from the beginning of the meeting. They also think that there will be no more requirement on this. For Nokia too, there will be no more requirements on NPN. 27 companies are in favour of sending the LS whereas 3 are not in favour, so the LS is to be sent. [official objections can be minuted until Monday]	Revised	S1-202266
4rrr	3.07	S1-202266	China Mobile Com. Corporation	[DRAFT] Reply LS to SA2 (cc SA, CT1, SA3, CT6) on Questions on onboarding requirements	LS out	Replaces S1-202225	Agreed.
1	3.08	S1-202075	S6-200544	LS on Clarification of the definition of a UAS	LS in	available
2	3.08	S1-202059	InterDigital, Tencent	Reply to LS on Clarification of the definition of a UAS	LS out	Rel-17	Revised	S1-202226
2r	3.08	S1-202226	InterDigital, Tencent	Reply to LS to SA2, SA6 on Clarification of the definition of a UAS	LS out	Rel-17	Replaces S1-202059	Revised	S1-202267
2rr	3.08	S1-202267	InterDigital, Tencent	Reply to LS to SA2, SA6 on Clarification of the definition of a UAS	LS out	Rel-17	Replaces S1-202226	Agreed.
3	3.08	S1-202057	InterDigital, Tencent	Discussion on clarification on the definition of UAS	discussion	Rel-17	noted
4	3.08	S1-202058	InterDigital, Tencent	Clarification of the definition of a UAS	CR	22.125	0028	F	17.1.0	Rel-17	ID_UAS	Revised	S1-202227
4r	3.08	S1-202227	InterDigital, Tencent	Clarification of the definition of a UAS	CR	22.125	0028	1	F	17.1.0	Rel-17	ID_UAS	Replaces S1-202058. The CR clarifies the relationship between UAV and UAV controller.	Not clear if there can be several controllers, this can be clarified.	Revised	S1-202268
4rr	3.08	S1-202268	InterDigital, Tencent	Clarification of the definition of a UAS	CR	22.125	0028	2	F	17.1.0	Rel-17	ID_UAS	Replaces S1-202227
5	3.08	S1-202117	Airbus	Clarification to the definition of UAS, new requirements and numbering of requirements	CR	22.125	0029	F	17.1.0	Rel-17	TEI17	In response to the incoming LS S6-200544, clarifications, corrections and new requirements are proposed. In addition, numbering of non-numbered requirements and editorial corrections.	available
1	3.09	S1-202076	S6-200580	LS on requirement for 5GMSG in broadcast scenario	LS in	SA6 wonders if the requirement [R-5.5.2-002] applies to all UE types, i.e. UE B, UE C and UE D as defined in TS 22.262 or only to UE types that support the broadcast message.	Propsoed to be answered in 2169.	noted
2	3.09	S1-202169	One2many	Reply to LS to SA6 on 5GMSG in broadcast scenario	LS out	The MSGin5G Service for MIoT needs to support broadcast message delivery in order to handle massive communications efficiently with a latency less than [500] ms as specified in requirement [R-5.5.2-001]. This requirement cannot be achieved with point-to-point message delivery. Therefore, the requirement applies to UEs that support the broadcast message.	Revised	S1-202269
2r	3.09	S1-202269	One2many	Reply to LS to SA6 on 5GMSG in broadcast scenario	LS out	Replaces S1-202169	Agreed.
1	3.10	S1-202077	S6-200620	LS on Clarification of requirements for UAS application enablement	LS in	SA6 asks SA1 to kindly guide SA6 on the requirements for some use cases on UAS application enablement and also the necessity to explicitly refer to application-aware parameters. SA6 asks SA1 to update their specification if necessary.	Proposed answers in 2138, 2154	noted
2	3.10	S1-202138	Deutsche Telekom AG	reply LS on Clarification of requirements for UAS application enablement	LS out	Rel-17	reply LS on Clarification of requirements for UAS application enablement. Some use cases for initial authorization to operate are proposed, extracted from TR 22.825. SA6 discussions on potential key issues described are outside the scope of the service requirements for UAS support in 3GPP.	Revised	S1-202228
2r	3.10	S1-202228	Deutsche Telekom AG	reply LS to SA6 (cc SA2) on Clarification of requirements for UAS application enablement	LS out	Rel-17	Replaces S1-202138	Revised as per comments by e-mail.	Revised	S1-202270
2rr	3.10	S1-202270	Deutsche Telekom AG	reply LS to SA6 (cc SA2) on Clarification of requirements for UAS application enablement	LS out	Rel-17	Replaces S1-202228	Agreed.
3	3.10	S1-202137	Deutsche Telekom AG	Discussion on SA6 LS Clarification of requirements for UAS	CR	22.125	Rel-17	ID_UAS	Discussion paper gives clarification on SA1 requirements on UAS remote Identification	noted
4	3.10	S1-202154	InterDigital	Reply to LS on Clarification of requirements for UAS application enablement	LS out	Rel-17	InterDigital also think it is out of scope, but some clarifications might be introduced.	An alignment of the 2 docs is possible since they are quite aligned. Propsoed answer to be based on 2138.	Noted
5	3.10	S1-202152	InterDigital	Discussion on clarification of requirements for UAS application enablement	discussion	Rel-17	Noted.
6	3.10	S1-202153	InterDigital	Clarification of requirements for UAS application enablement	CR	22.125	0031	F	17.1.0	Rel-17	ID_UAS	InterDigital can "live with no CR".	Noted.
7	3.10	S1-202119	Airbus	Clarifications to Requirements for Remote Identification of UAS	CR	22.125	0030	F	17.1.0	Rel-17	TEI17	In response to the incoming LS S6-200620, clarifications to requirements on clause 5.1 are necessary.	Airbus can also "live with no CR". For Nokia and Futurewei, it might still be usefull to introduce some further clarifications in the requirements, but this can be done at a future meeting.	Noted.
1	3.11	S1-202166	R2- 2003941	LS on UAC applicability to IABs	RAN2 made the following agreement for IAB WI: "IAB-MTs are not under UAC control." The agreement means that IAB-MT, being part of an IAB node which is a network node, does not perform access barring check for its access attempts to a cell. RAN2 thinks that SA1/CT1 should be aware of this agreement as it might have some impact on their specifications.
2	3.11	S1-202162	Nokia, Nokia Shanghai Bell	reply LS on UAC applicability to IABs	LS out	SA1 thanks RAN2 for the LS noted in the header. In concurrence with the RAN2 agreement that IAB-MTs are not under UAC control, SA1 has agreed the attached CR.	This is referring to the CR in 2163.	Revised	S1-202229
2r	3.11	S1-202229	Nokia, Nokia Shanghai Bell	reply LS to RAN2, CT1 (cc RAN3, SA2) on UAC applicability to IABs	LS out	Replaces S1-202162	Qualcomm, ZTE and LG agree with the LS but want a different wording and/or more time for the CR (in 2170). For Ericsson, this cannot be postponed to Rel-17 since the CR is an alignment for Rel-16. The CR is just to align Stage 1 to Stage 3. Ericsson disagree with LG's view that this is "only for UE implementation". For Qualcomm, the only problem is about the wording of the note. They have no problem if the note proposed in the CR uses the same wording as the one in RAN2's LS. A consensus is found by the note stating: "IAB-MT are not subject to unified access control".	Revised	S1-202274
2rr	3.11	S1-202274	Nokia, Nokia Shanghai Bell	reply LS to RAN2, CT1 (cc RAN3, SA2) on UAC applicability to IABs	LS out	Replaces S1-202229
3	3.11	S1-202163	Nokia, Nokia Shanghai Bell	UAC enhancement for IAB	CR	22.261	0448	F	16.11.0	Rel-16	SMARTER_Ph2	The CR adds an Access Identity for a UE configured for IAB to avoid barring while enabling UAC procedures to set the appropriate RRC establishement cause.	This was commented to be coming too late for Rel-16.	noted
4	3.11	S1-202164	Nokia, Nokia Shanghai Bell	UAC enhancement for IAB	CR	22.261	0449	A	17.2.0	Rel-17	SMARTER_Ph2	Noted
5	3.11	S1-202170	Ericsson	Clarify that IAB does not follow UAC	CR	22.261	0450	F	16.11.0	Rel-16	SMARTER_Ph2	The CR adds a note saying that "IAB Nodes are not subject to unified access control". This is seen by Ericsson as an alignment to Rel-16 in RAN.	This is another way to take into account the LS from RAN2 in 2166, which is more in line with what they are expecting, according to Ericsson. They point out that it is late to provide a Rel-16 CR. Qualcomm and Vodafone support the Ericsson's view: there is no need to introduce a new Access Identity number, the note is sufficient. Also Samsung, underlying that it is too late to add requirements for Rel-16. LG and Futurewei prefer the Nokia's approach, considering the evolution of the work in RAN in Rel-17. They see it more future-proof. See comments in 2229.	Revised	S1-202273
5r	3.11	S1-202273	Ericsson	Clarify that IAB does not follow UAC	CR	22.261	0450	1	F	16.11.0	Rel-16	SMARTER_Ph2	Replaces S1-202170
6	3.11	S1-202171	Ericsson	Clarify that IAB does not follow UAC	CR	22.261	0451	A	17.2.0	Rel-17	SMARTER_Ph2	Mirror CR of 2170.	Noted
7	3.11	S1-202168	Qualcomm	Proposed answer to S1-202166/ R2- 2003941 on UAC applicability to IABs	Withdrawn
1	3.12	S1-202165	R2-2003870	Reply LS on manual CAG selection	RAN2 respectfully asks SA1 whether the indication that the PLMN allows a user to manually select a CAG-ID supported by the CAG cell but outside the UE’s allowed CAG list is per PLMN or per CAG ID.	Proposed answer in 2167, 2178
2	3.12	S1-202071	C1-202927	LS on manual CAG selection	LS in	available
3	3.12	S1-202167	Qualcomm	Proposed answer to S1-202165/ R2-2003870 on manual CAG selection	Proposed answer: SA1 would like to clarify that current relevant requirement (copied below, from TS 22.261) is based on the assumption that the control/indication is per PLMN, i.e. applies to “any” NPN hosted by the PLMN. The 5G system shall support a mechanism for a PLMN to control whether a user of a UE can manually select a non-public network hosted by this PLMN that the UE is not authorized to select automatically.	Fro Qualcomm, this should be closed for Rel-16. For Rel-17, discussions should be possible. For Nokia, this should be clarified as early as Rel-16. For KPN, for Rel-17 for sure, it should be on a pre non-public network basis. As for Rel-16, it depends on the progress of the other groups: better if it can be included, but not necessary. Ericsson supports the Qualcomm's view. KPN proposes a compromise, saying that the aim is to have it for Rel-17. This is acceptable by Qualcomm. For Vodafone, they would prefer to have it in Rel-16, but it is acceptable to have it only in Rel-17. For Nokia, this is acceptable too. Ericsson and Qualcomm do not agree to have the Rel-17 CR agreed yet though. For Vodafone, the Rel-17 Nokia's CR is actually a correction, since the other groups did not follow the SA1 requirement, probably because of lack of clarity of the CR. It is agreed not to have it for Rel-16 but further discussions are requested for having it or not for Rel-17. The LS answer should be based on the Qualcomm's proposal in 2167.	Revised	S1-202230
3r	3.12	S1-202230	Qualcomm	Proposed answer to S1-202165/ R2-2003870 to RAN2, CT1 (cc SA2, RAN3) on manual CAG selection	LS out	Replaces S1-202167. SA1 has discussed about the following existing SA1 Rel-16 requirement (from TS 22.261): The 5G system shall support a mechanism for a PLMN to control whether a user of a UE can manually select a non-public network hosted by this PLMN that the UE is not authorized to select automatically. and agreed that, for Rel-16, it should be interpreted as if the indication allowing to manually select a CAG-ID supported by the CAG cell but outside the UE’s allowed CAG list, is per PLMN.	Consensus on the following changes: "Per CAG-ID" instead of "per-PLMN" and deletion of the last sentence. With these changes and further re-wording to be made off-line, there is an agreement to send the LS.	Revised	S1-202277
3rr	3.12	S1-202277	Qualcomm	Proposed answer to S1-202165/ R2-2003870 to RAN2, CT1 (cc SA2, RAN3) on manual CAG selection	LS out	Replaces S1-202230	Agreed.
4	3.12	S1-202178	Nokia	Reply LS on manual CAG selection	Proposed to clarify RAN2's concern with the CR in 2179.	Noted
5	3.12	S1-202179	Nokia	Manual Selection clarification	CR	22.261	0452	F	16.11.0	Rel-16	SMARTER_Ph2	A requirement is clarified to state that the control of manual selection is done on a per non-public network basis.	Noted
6	3.12	S1-202180	Nokia	Manual Selection clarification	CR	22.261	0453	A	17.2.0	Rel-17	SMARTER_Ph2	Noted
1	3.13	S1-202022	S2-1912417	Reply LS on SUCI computation from an NSI	LS in	Postponed from previous meeting. Was S1-201009	available
10	3.13	S1-202037	R3-201372	Reply LS on QoS monitoring for URLLC	LS in	CC:	available
11	3.13	S1-202038	SP-200287	Reply LS on support for eCall over NR	LS in	CC:	available
12	3.13	S1-202074	S2-2003308	Reply LS on support for eCall over NR	LS in	available
13	3.13	S1-202035	R2-2001815	Reply LS on Rel-16 NB-IoT enhancements	LS in	TO:	withdrawn
2	3.13	S1-202027	S3-194548	Reply LS on SUCI computation from an NSI	LS in	Postponed from previous meeting. Was S1-201016	available
3	3.13	S1-202023	S2-2001398	LS reply on NPN network sharing	LS in	Postponed from previous meeting. Was S1-201011	available
4	3.13	S1-202028	S5-197805	LS on NPN network sharing	LS in	Postponed from previous meeting. Was S1-201017	available
5	3.13	S1-202029	S5-197853	LS on analysis of GSMA GST attributes	LS in	Postponed from previous meeting. Was S1-201018	available
6	3.13	S1-202030	ITU T FGVM-LS014	LS on technical reports on use cases and requirements as well as architecture for vehicular multimedia	LS in	Postponed from previous meeting. Was S1-201021	available
7	3.13	S1-202031	SP-191379	Reply LS to extend the scope of eV2X	LS in	Postponed from previous meeting. Was S1-201022	available
8	3.13	S1-202032	5GJA12_115r3	LS reply to SA2 on PLMN Selection	LS in	TO:	available
9	3.13	S1-202034	TCCA	LS on Generic Slice Template with Public Safety Feedback	LS in	CC:	available
03	4	S1-202085	Nokia, Nokia Shanghai Bell	Use Case for FS_EANS: Roaming Access to NS	discussion	noted
10	4	S1-202063	China Mobile Com. Corporation	New SID on Study on supporting tactile Internet in 5GS	SID new	Rel-18	The objective of this study item is to investigate new use cases and service requirements for supporting tactile network in 5G network.	Sony explained that CAV is on the same topic and is not mentioned here. For Intel and BBC, this is strongly linked to the proposal on haptics. For Qualcomm and Intel, the bullet on codec is covered by SA4. For Nokia and several other companies, the gap analysis is missing: at least part of what is proposed here -if not everything- is already covered in 3GPP.	Revised	S1-202249
10r	4	S1-202249	China Mobile Com. Corporation	New SID on Study on supporting tactile Internet in 5GS (FS_TIin5GS)	SID new	Rel-18	Replaces S1-202063	No rev marks shown. Potential revisions to come later.	Revised	S1-202283
10rr	4	S1-202283	China Mobile Com. Corporation	New SID on Study on supporting tactile Internet in 5GS (FS_TIin5GS)	SID new	Rel-18	Replaces S1-202249	For drafting session.
11	4	S1-202079	Union Inter. Chemins de Fer	Motivation for Rel-18 SID proposal on Study on Off-Network for Rail	discussion	Rel-18	Presentation slides for the SID in the next document.	noted
12	4	S1-202078	Union Inter. Chemins de Fer	New SID on Study on Off-Network for Rail	SID new	Rel-18	The objectives of this study are: - Collect all Off-Network use cases from TR 22.889 into a single TR in order to refine them, - Remove the similar Off-Network use cases from TR 22.889 (e.g. On-Network use cases only), - If needed, study new use cases for FRMCS to support Off-Network	As a co-author, Nokia explained that this is to clarify in 3GPP documentation what is really needed in terms of "Off-Net" by the railway industry, "22.889" is internal, so KPN wondered if it is not "22.989" which is meant. This is indeed the intention (to be external). FirstNet supports it. Vodafone and Novamint wondered if other verticals can be used than railways. The UIC said it is meant for Railways. About " UIC will promote the use of Off-Network to replace Direct Mode.", it is clarified that this is referring to the terminology.	Revised	S1-202244
12r	4	S1-202244	Union Inter. Chemins de Fer	New SID on Study on Off-Network for Rail	SID new	Rel-18	Replaces S1-202078
13	4	S1-202082	Nokia, Nokia Shanghai Bell	Feasibility Study on 5G Timing Resiliency System (FS_5TRS)	discussion	Presentation slides for the SID in the next document.	Noted
14	4	S1-202083	Nokia, Nokia Shanghai Bell, NTT DoCoMo, AT&T, KPN	SID: Feasibility Study on 5G Timing Resiliency System (FS_5TRS)	SID new	The objective of this study item is to identify additional potential requirements on the 5G system to support time-synchronization services in public and vertical domains, including the ability to act as a backup for GNSS timing services. Specific use cases will be provided to motivate the additional potential requirements.	T-Mobile supports this SID. Huawei has the following quations: For the first bullet: Integration with fiber should be clarified. For the 2nd bullet: "the same performance" should be clarified For the 3rd bullet: it should be clarified it is the timing and not the positionnning.	Revised	S1-202241
14r	4	S1-202241	Nokia, Nokia Shanghai Bell, NTT DoCoMo, AT&T, KPN	SID: Feasibility Study on 5G Timing Resiliency System (FS_5TRS)	SID new	Replaces S1-202083	Intel also support	Revised	S1-202281
14rr	4	S1-202281	Nokia, Nokia Shanghai Bell, NTT DoCoMo, AT&T, KPN	SID: Feasibility Study on 5G Timing Resiliency System (FS_5TRS)	SID new	Replaces S1-202241
15	4	S1-202091	Xiaomi	Multi-modality Interaction	discussion	Presentation slides for the SID in the next document.	noted
16	4	S1-202092	Xiaomi	New SID_Study on the Support for Multi-modality Interaction	SID new	The objective is to study use cases and potential service requirements for multi-modality (Inputs may come from one UE or multiple UEs while outputs may go to one UE or multiple UEs) communication. It includes but is not limited to: - Studying the use cases and potential service and performance requirements for multi-modality. - Gap analysis on performance requirements for multi-modality	For Huawei and Sony, this can be combined with the China Mobile's WID. Sony wonders if this is an enabler or a service by itself. For Intel, "data fusion" and "multi-dimensional" aspects are the 2 points to be investigated. For Nokia, here again the gap analysis is missing. There is some interest and some points to be clarified. The merging with China Mobile's SID should be investigated/	Revised	S1-202251
16r	4	S1-202251	Xiaomi	New SID_Study on the Support for Multi-modality Interaction (FS_SMI)	SID new	Replaces S1-202092	Nokia reminded that this can be merged with another SID (on "Tactile"), but Xiaomi explained that there was no agreement to proceed with the merging. Nokia underlined that this might lead to work organisation issue, if this ends up with overlapping requirements. Sony supports Nokia's view. Same for InterDigital, who also like to combine them. InterDigital supports this WID.	Revised	S1-202286
16rr	4	S1-202286	Xiaomi	New SID_Study on the Support for Multi-modality Interaction (FS_SMI)	SID new	Replaces S1-202251
17	4	S1-202094	Qualcomm Incorporated	Motivations for Study on Network as a Service	discussion	Rel-18	Presentation slides for the SID in the next document.	Noted
18	4	S1-202093	Qualcomm Incorporated	New SID: Study on Network as a Service	SID new	Rel-18	The objectives of this study are: • Study use cases for enhanced 5G system support of a NaaS network providing users/devices access to specific services, offered by the NaaS network operator, other mobile operator(s) or 3rd party provider(s). • Investigate potential new service requirements, • Gap analysis between potential new requirements and existing requirements and functionalities supported by 3GPP, e.g. VIAPA, NPN, slicing, QoS, etc.	Intel has no concerns with the proposal but several suggestions for improvements that they will send by e-mail. Different cases can be considered, e.g. no PLMN coverage, etc. For Ericsson and Nokia, the difference to what is going to be in Rel-17 (e.g. in AVPROD context) and what new is proposed for Rel-18 has to be clarified. Qualcomm answered that a possible outcome of the gap analysis is that nothing new is needed. For Nokia, this cannot be answered until the Reel-17 work is more stable in other groups.	Revised	S1-202243
18r	4	S1-202243	Qualcomm Incorporated	New SID: Study on Network as a Service	SID new	Rel-18	Replaces S1-202093
19	4	S1-202096	Qualcomm Incorporated	Motivations for Study on Vehicle Relays	discussion	Rel-18	Presentation slides for the SID in the next document.	noted
2	4	S1-202108	LG Electronics Polska	DP on Study on Enhanced Access to Network Slice	discussion	PPT slide for GoToMeeting, related to S1-202042	available
20	4	S1-202095	Qualcomm Incorporated	New SID: Study on Vehicle Relays	SID new	Rel-18	The aim of this work is to study use cases and potential new service requirements for 5G system support of vehicle-mounted relays (on board base stations) using NR and 5GC.	For Huawei, several cases of Relays have already been investigated by SA1, which could apply to this SID. They wonder if all the use cases are not covered already. This is to be discussed off-line. For TenCent, the case where the vehicle is moving has to be covered. FirstNet supports since there are use cases for public safety. Sharp also supports.	Revised	S1-202205
20r	4	S1-202205	Qualcomm Incorporated	New SID: Study on Vehicle Relays (FS_VMR)	SID new	Rel-18	Replaces S1-202095. More supporting companies, some clarifications.	CATT has concerns (or at least needs clarifications) on the 3 bullets in the Objective. The vehicles can be ground-vehicles or even e.g. UAV. CATT also want to add the Security aspects.	Revised	S1-202247
20rr	4	S1-202247	Qualcomm Incorporated	New SID: Study on Vehicle Relays (FS_VMR)	SID new	Rel-18	Replaces S1-202205
21	4	S1-202099	NTT DOCOMO INC.	Presentation for a proposed new Study on Subscriber-aware Northbound API access	discussion	Rel-18	Presentation for a proposed new Study on Subscriber-aware Northbound API access	noted
22	4	S1-202100	NTT DOCOMO INC.	New WID on Study on Subscriber-aware Northbound API access	SID new	Rel-18	The objective of this study is to examine use cases and potential requirements on Subscriber-aware Northbound API access, in particular including the following aspects. - Authorization and a corresponding authentication for invocation of the northbound API via an AF by a subscriber; - Related logging and charging aspects.	Samsung supports the idea of this SID and finds it interesting with respect to CAPIF. For Futurewei, some wording is too SA2-oriented and has to be changed. For Nokia and Futurwei, the wording has to be improved for clarity. Deutsche Telekom underlined that this is related to the SA6 CAPIF work. It is not clear for them why the UE also has to support this mechanism. KPN wonders if a study is needed and this is not the matter of a simple CR. To be further discussed by e-mail.	noted
23	4	S1-202102	Intel	Feasibility Study on Support for Service Function Chaining in 5G System (FS_SFCin5GS)	discussion	Rel-18	This slide is for the presentation of a new SID: FS_SFCin5GS.	noted
24	4	S1-202101	Intel	SID: Feasibility Study on Support for Service Function Chaining in 5G System (FS_SFCin5GS)	SID new	Rel-18	It is proposed a new SID to support service function chaining in 5GS. The aim of this work is to study use cases and potential new service requirements in support of service function chaining in 5G system.	The exact objective of this Work Item remains unclear to Huawei. Discussions will continue over the e-mail reflector.	Revised	S1-202252
24r	4	S1-202252	Intel	SID: Feasibility Study on Support for Service Function Chaining in 5G System (FS_SFCin5GS)	SID new	Rel-18	Replaces S1-202101	"Impacts" could be changed to "no"	Revised	S1-202285
24rr	4	S1-202285	Intel	SID: Feasibility Study on Support for Service Function Chaining in 5G System (FS_SFCin5GS)	SID new	Rel-18	Replaces S1-202252
25	4	S1-202106	LG Electronics Inc.	DP: Feasibility Study on 5G Support for Service-Oriented Robots with Service-Level Human Interactions	discussion	Rel-18	Presentation material for WID: Feasibility Study on 5G Support for Service-Oriented Robots with Service-Level Human Interactions	Revised	S1-202187
25r	4	S1-202187	LG Electronics Inc.	DP: Feasibility Study on 5G Support for Service-Oriented Robots with Service-Level Human Interactions	discussion	Rel-18	Replaces S1-202106	noted
26	4	S1-202105	LG Electronics Inc.	WID: Feasibility Study on 5G Support for Service-Oriented Robots with Service-Level Human Interactions	SID new	Rel-18	Feasibility Study on 5G Support for Service-Oriented Robots with Service-Level Human Interactions	Revised	S1-202186
26r	4	S1-202186	LG Electronics Inc.	WID: Feasibility Study on 5G Support for Service-Oriented Robots with Service-Level Human Interactions	SID new	Rel-18	Replaces S1-202105. The objective of this study is to identify use cases and the related potential service requirements for 5G system support for communications between service-oriented robots with human interactions	For Nokia, there is yet again a problem of gap analysis: they do not see what is missing in the 5G system to control robots, besides maybe the multi-customers part. For Huawei, there is also some previous studies in previous Releases which should cover all the needs. Also with respect to new KPIs for connectivity: it is not clear if anything new is needed. For Sony, this could be merged with the new proposed SID on multi-modality. For Deutsche Telekom, the multi-identity aspects have to be clarified and checked against what is available. LG clarified that not everything can be done at the application level: e.g. there might be some impacts on the system's security aspects. Discussions to be continued over e-mail.	Revised	S1-202253
26rr	4	S1-202253	LG Electronics Inc.	WID: Feasibility Study on 5G Support for Service-Oriented Robots with Service-Level Human Interactions	SID new	Rel-18	Replaces S1-202186	Revised	S1-202288
26rrr	4	S1-202288	LG Electronics Inc.	WID: Feasibility Study on 5G Support for Service-Oriented Robots with Service-Level Human Interactions	SID new	Rel-18	Replaces S1-202253
27	4	S1-202110	CATT, China Telecom, InterDigital	New Study on enhancing 5G system over satellite	SID new	The objectives of this study are: - Studying use cases for enhancing 5G system over satellite e.g. considering satellite backhaul and inter-satellite link - Studying use cases for new service and enhancement based on 5G system over satellite - Investigating potential new requirements, - Gap analysis between potential new requirements and existing requirements and functionalities for satellite of 5G already defined by 3GPP.	Sony, Nokia, Novamint and Thales could not clearly see what is proposed on top of what has been defined already. For T-Mobile, the difference is that this SID might be on Serving the backhaul rather than the previous work was on serving the end-user, but this is their guest. For the BBC, all the previous work was on a basic service when this is about proposing an advanced satellite service. CATT clarified that this is indeed for improvements in services. To be continued by e-mail.	Revised	S1-202242
27r	4	S1-202242	CATT, China Telecom, InterDigital	New Study on enhancing 5G system over satellite	SID new	Replaces S1-202110	Revised	S1-202278
27rr	4	S1-202278	CATT, China Telecom, InterDigital	Study on enhancing 5G system with satellite backhaul (FS_e5GSATB)	SID new	Replaces S1-202242	Name of some companies to be changed	Revised	S1-202291
27rrr	4	S1-202291	CATT, China Telecom, InterDigital	Study on enhancing 5G system with satellite backhaul (FS_e5GSATB)	SID new	Replaces S1-202278
28	4	S1-202111	HiSilicon Technologies Co. Ltd	New SID on enhancements for multimedia service in 5GS	SID new	Rel-18	withdrawn
29	4	S1-202115	China Telecomunication Corp.	Motivation for R18 5G enables Smart Grid SID	discussion	Presentation for the SID in 2114.	noted
30	4	S1-202123	Samsung Electronics GmbH	Smart Grid Study Considerations	discussion	A 3 slide presentation that lays out a rationale, objectives and areas to develop for the Smart Grid Study. The intent is to support the Smart Grid study, emphasizing promising aspects.	Added arguments to support the SID in 2114, on why it is important to specify for aspects to SmartGrid. Some aspects are specific: Smart Grid services, e.g. IEC standards, generally do not assume a particular transport. Requirements are e.g. Bandwidth, Latency, Availability, Security. Deployment criteria (whether to invest in one particular technology or another) include Service Lifetime (is it feasible to deploy a terminal for 40 years?), Coverage (ubiquity), Electromagnetic Applicability (e.g. Penetration, ability to operate in high EM environments) Some additional criteria arise due to operational manageability – e.g. the ability to configure and monitor the real (achieved & up to date) availability of virtual network topologies.	presented
31	4	S1-202114	China Telecomunication Corp.	Study on the 5G Smart Energy and Infrastructure	SID new	The aim of this work is to study use cases and potential new service requirements for 5G system to support smart grid, including: To investigate potential new 5G system service requirements and KPIs to support emerging Smart Grid services required defined in other bodies, e.g. IEC. To investigate 5G service requirements and KPI to support Smart Grid applications in specific phase or across multiple phases: e.g. on-demand power supply, distributed power supply system, distribution automation, higher accuracy power load measurement and control, metrology automation, etc. gap analysis on between potential new requirements and existing requirements and functionalities for smart grid communications supported by 3GPP specs TS22.104/125/261 etc.	For Novamint, there is a huge opportunity for 3GPP here, but 3GPP cannot disappoint this industry. For Huawei, there is no need to reinvent things which already exist. For Samsung and Nokia, the objectives have to be made more specific and narrower. Nokia also underlined that the demand has to come from the industry (UTC, EPRI, etc.) and not spontaneously defined by 3GPP.	Revised	S1-202204
31r	4	S1-202204	China Telecom, China Southern Power Grid, CEPRI-China, OMESH, Huawei, ZTE, CATT, Fudan, Spreadtrum, Samsung	Study on the 5G Smart Energy and Infrastructure (FS_5GSEI)	SID new	Rel-18	Replaces S1-202114r2	For Qualcomm, this is going in the good direction but some work is still needed on the KPIs to mention or not in the WID. Also the dates seem very late. Telefonica, Novamint, Orange, Thales, Sony and Futurewei also support. Deutsche Telekom mentions that the "impacts of the Work Item" do not seem to be updated in none of the proposed new WIDs. For Samsung and Huawei, the dates should be empty until the dates for Rel-18 freeze is known for Stage 1.	Revised	S1-202240
31rr	4	S1-202240	China Telecom, China Southern Power Grid, CEPRI-China, OMESH, Huawei, ZTE, CATT, Fudan, Spreadtrum, Samsung	Study on the 5G Smart Energy and Infrastructure (FS_5GSEI)	SID new	Rel-18	Replaces S1-202204	Revised	S1-202276
31rrr	4	S1-202276	China Telecom, China Southern Power Grid, CEPRI-China, OMESH, Huawei, ZTE, CATT, Fudan, Spreadtrum, Samsung	Study on the 5G Smart Energy and Infrastructure (FS_5GSEI)	SID new	Rel-18	Replaces S1-202240
32	4	S1-202122	Beijing Xiaomi Mobile Software	Study on Ranging-based services	discussion	Rel-18	Presentation for the SID in 2116.	Noted
33	4	S1-202116	Beijing Xiaomi Mobile Software	New Study on Ranging-based Services	SID new	Rel-18	Ranging-based applications utilize the distance and angle between two devices to interact with, control or locate a specific device. The objective of this study item is to study the use cases and potential service requirements for ranging. Aspects to be studied include: - Identify Use cases and potential requirements to allow ranging. - Gap analysis with existing mechanisms to enable ranging.	For Sony and Nokia, this has commonalities with other proposed SIDs on positioning presented at this meeting. Also here, what is expected from the system should be clarified. To be further discussed by e-mail.	Revised	S1-202255
33r	4	S1-202255	Beijing Xiaomi Mobile Software	New Study on Ranging-based Services	SID new	Rel-18	Replaces S1-202116
34	4	S1-202120	Huawei	motivation for new SID on enhancement for multimedia services	discussion	Rel-18	Presentation for the SID in 2121.	Noted
35	4	S1-202121	Huawei	New SID on enhancements for multimedia serivices	SID new	Rel-18	The objective of this SID includes: - Studying the use cases for providing better QoE for various type of consumer-oriented multimedia services (e.g., live and on-demand video streams, Augment Reality (AR) / Virtual Reality (VR) service) in 5GS, in particular, to study how 5GS could cooperate with typical and mostly used mechanisms in multimedia application layer (e.g., DASH, Playback buffer management and FOV/edge rendering) to increase the network capacity and also improve QoE of these multimedia services. - Identifying potential performance and service requirements based on above use cases. Note: This study will not cover those use cases discussed in AVPROD/VIAPA.	BBC has already commented off-line that this is to be clarified with respect to what optimisations are needed on the Network layer versus what is needed from the application layer. For Sony, there is ongoing SA4 on this topic. For Xiaomi, all the part of the coding is for SA4. Also, most of what is proposed here can already be done, e.g. with MPEG4 capabilities. What is actually proposed to be specified should be clarified. Intel has the same concerns and explains there is a new SA4 study related to this. Same for Nokia: no work needed in SA1.	Revised	S1-202206
35r	4	S1-202206	Huawei	New SID on enhancements for multimedia services in 5GS (FS_en_MMS)	SID new	Rel-18	Replaces S1-202121. The Objective is rewritten as: The objective of this SID is to study the use cases and identify additional potential requirements for enhanced support of multimedia services, including: • Enhancements on efficient network transmission for multimedia services (e.g., traffic burst pattern awareness, QoS enhancement) • Enhancement on user plane path selection and switching (e.g., computation power/capacity awareness)	For Nokia, there is synergy with Intel's proposal, in particular on the 2nd bullet. Qualcomm sees this 2nd bullet has something new, this has to be discussed. About the 1st bullet: Sony and Intel remindethat all the communications are encrypted, so they wonder how this is compatible with the proposal. About 2nd bullet: this has interactions with SA4 work, according to Intel. Interdigital also has concerns with the modifications on the user plane (2nd bullet).	Revised	S1-202250
35rr	4	S1-202250	Huawei	New SID on enhancements for multimedia services in 5GS (FS_en_MMS)	SID new	Rel-18	Replaces S1-202206	Revised	S1-202275
35rrr	4	S1-202275	Huawei	New SID on enhancements for multimedia services in 5GS (FS_en_MMS)	SID new	Rel-18	Replaces S1-202250
4	4	S1-202042	LG Electronics Polska	WID on Study on Enhanced Access to Network Slice	SID new	For Samsung, it should be made clearer that these are improvements of existing mechanisms and not new mechanisms. There is an SA2-related SID that should be mentioned here. No disagreement, to be further worked upon.	Revised	S1-202209
43	4	S1-202142	China Telecom	Motivation for New SID on Holographic-Type Communication Service	discussion	Rel-18	Presentation for the SID in 2140.	noted
44	4	S1-202139	China Telecom	New SID on Holographic-Type Communication Service	SID new	Rel-18	withdrawn
44	4	S1-202140	China Telecom	New SID on Holographic-Type Communication Service	SID new	Rel-18	The objective of this study item is to identify new use cases, potential service requirements for supporting holographic-type communication services in 3GPP network, including: - Use cases of holographic-type Communication service, including: • Holographic-type communication service with different hologram technology; • Holographic-type communication service with multiple concurrent streams; • Holograms transmission strategy adjustment based on awareness of network status, etc. - Service performance and KPI requirements for holographic-type Communication service, e.g. latency, bandwidth, multi-dimensional synchronization, support for concurrent flows, etc. - Gap analysis between the identified requirements and existing 5GS requirements or functionalities.	This has also possible overlaps with other new SIDs, according to Intel.	Revised	S1-202254
44r	4	S1-202254	China Telecom	New SID on Holographic-Type Communication Service	SID new	Rel-18	Replaces S1-202140
45	4	S1-202143	KPN	Presentation for new SID for Study on Enhancements for Residential 5G	discussion	Rel-18	Presentation for the SID in 2141	noted
46	4	S1-202141	KPN	New SID on Enhancements for Residential 5G	SID new	Rel-18	This is a new Rel-18 study item description for a study on enhancements for residential 5G. The objective of this study is to identify use cases, provide a gap analysis and define potential requirements in the following three areas. • Enhancements for Wireline Wireless Convergence • Enhancements for fixed LAN - 5G LAN integration • Enhancements for indoor small basestations:	T-Mobile US support this Study. Identification of devices beyond the gateway should also be investigated, according to Deutsche Telekom, which is also supporting. For Nokia, there is a possibility to merge with the SID on "Personal IoT" (vivo). They would like to see a different approach compared to what happened with Femtocell some years ago. If/how the concept of "indoor base stations" is applicable is for further study.	Revised	S1-202192
46r	4	S1-202192	KPN	New SID on Enhancements for Residential 5G	SID new	Rel-18	Replaces S1-202141
47	4	S1-202144	vivo Mobile Communication Co.,	Personal IoT Networks	discussion	Rel-18	Discussion paper to support SID on same topic.	Noted
48	4	S1-202161	vivo Mobile Communication Co.,	Personal IoT Networks Slides	discussion	Rel-18	Slide deck per chairs request for new SID.	Noted
49	4	S1-202145	vivo Mobile Communication Ltd, China Telecom, Qualcomm Incorporated, Convida Wireless	New WID on Study of Personal IoT Networks	SID new	Rel-18	This study is aiming at new use cases and service requirements to enhance 5GS support of Personal IoT networks, including a set of IOT devices communicating between themselves and with a smartphone using ProSe direct communication; the personal IOT network is connected to 5GC, either using Prose indirect communication or other macro network connectivity (e.g. local RAN entities/gateways). The objectives include: - Study use cases related to 5GS support of Personal IoT networks and potential new requirements - Gap analysis between the identified requirements and what is already defined by existing 3GPP requirements, e.g. related to PNM, NB-IoT and eMTC, NPN, REFEC etc.	Deutsche Telekom, although not against the principles, have concerns with the wording of the objectives. For Huawei, the concern is with the "interworking" part, which has to be clarified. Sony reminded that the wearables were already studied in Rel-17, in particular in RAN. This has to be considered if not already done. For Nokia too, several aspects seem to be already covered. For FirstNet, there might be commonalities with REFEC (multi-hops). Discussions to be continued by e-mail.	Revised	S1-202233
49r	4	S1-202233	vivo Mobile Communication Ltd, China Telecom, Qualcomm Incorporated, Convida Wireless	New WID on Study of Personal IoT Networks (FS_PIN)	SID new	Rel-18	Replaces S1-202145	Revised	S1-202287
49rr	4	S1-202287	vivo Mobile Communication Ltd, China Telecom, Qualcomm Incorporated, Convida Wireless	New WID on Study of Personal IoT Networks (FS_PIN)	SID new	Rel-18	Replaces S1-202233
4r	4	S1-202209	LG Electronics Polska	WID on Study on Enhanced Access to Network Slice	SID new	Replaces S1-202042	Revised	S1-202284
4rr	4	S1-202284	LG Electronics Polska	WID on Study on Enhanced Access to Network Slice	SID new	Replaces S1-202209	For drafting session.
5	4	S1-202051	Spreadtrum Communications	Motivation for R18 Smart Logistics Management SID proposal	discussion	Rel-18	Motivation for R18 Smart Logistics Management SID proposal	Noted
6	4	S1-202052	Spreadtrum Communications	New WID on Study on supporting of the smart logistics management	SID new	Rel-18	New WID on Study on supporting of the smart logistics management The objectives include a Study on use cases related to smart logistic management services and deduce potential requirements for 3GPP systems for IoT devices with limited power supply are on/in the transported and delivered package:	For Sony, the additional value of this proposal (compared to what already exists) is not clear. Same concern for Qualcomm and Nokia. No precise wording is used, like "higher accuracy", etc.	Revised	S1-202246
6r	4	S1-202246	Spreadtrum Communications	New WID on Study on supporting of the smart logistics management	SID new	Rel-18	Replaces S1-202052	Revised	S1-202282
6rr	4	S1-202282	Spreadtrum Communications	New WID on Study on supporting of the smart logistics management	SID new	Rel-18	Replaces S1-202246
7	4	S1-202053	Spreadtrum Communications	Motivation for R18 SID proposal of Blockchain for mobile communication system	discussion	Rel-18	Motivation for R18 SID proposal of Blockchain for mobile communication system. Presentation slides for the SID in the next document.	Noted
8	4	S1-202054	Spreadtrum Communications	New WID on Study on Blockchain for mobile communication system	SID new	Rel-18	New WID on Study on Blockchain for mobile communication system. The objectives include following aspects: 1. Studying the use cases, potential service and performance/KPI requirements to support the communication aspect of blockchain applications. 2. Studying the blockchain functionality and the benefits to 3GPP network for integrating some beneficial blockchain functionality into 3GPP network to improve the mobile communication system. 3. Studying the security requirement of Blockchain for mobile communication system. 4. Analysis gaps between the identified requirement and the functionality already provided by 3GPP	Logistics is a first use case, but it is intended to get other ones e.g. finances. For Sony, this is quite interesting, but think that this can be done at the application level. 3GPP-related lacks should be underlined. Nokia, AT&T, vivo have the same concern. Vivo and Deutsche Telekom explained that SA6 and GSMA have a similar working topic. Relationships between all these groups should be clarified. Telefonica explained that there is also an ETSI ISG group called "BVL" working on the same topic. There is some interest but 3GPP work should be clarified.	Revised	S1-202248
8r	4	S1-202248	Spreadtrum Communications	New WID on Study on Blockchain for mobile communication system	SID new	Rel-18	Replaces S1-202054
9	4	S1-202064	China Mobile Com. Corporation	Motivation for R18 SID proposal on tactile internet in 5GS	discussion	Rel-18	Presentation slides for the SID in the next document.	noted
99	4	S1-202126	Huawei, Huawei Device	Motivation for R18 enhanced Network controlled interactive service	discussion	Rel-18	Postponed
99	4	S1-202127	Huawei, Huawei Device	New WID on enhancements for network controlled interactive service (eNCIS)	WID new	Rel-18	Document postponed	Postponed
99	4	S1-202129	Huawei,Huawei Device	Complemetary requirements for consumed tethered VR headset services	CR	22.261	0447	B	17.2.0	Rel-18	DUMMY	Postponed
99	4	S1-202131	Samsung Electronics GmbH	Smart Grid and Mobile Telecommunication Opportunities	discussion	A study in Smart Grid and telecommunications in SA1 could lead to useful results, as this sector has specific needs that are today only partially served by existing 3GPP standards.	Replaced by 2123	withdrawn
5.1	S1-202048	VODAFONE Group Plc	Discussion on generic 5G requirements for VIAPA	discussion	available
1	5.1	S1-202049	VODAFONE Group Plc	On the generic 5G requirements for VIAPA	CR	22.263	0003	D	17.0.0	Rel-17	AVPROD	The CR moves the requirements in TS 22.263 clause 5.1 to the related clauses in TS 22.261.	Agreed.
2	5.1	S1-202050	VODAFONE Group Plc	Addition of generic 5G requirements for VIAPA	CR	22.261	0442	D	17.2.0	Rel-17	AVPROD	Revised	S1-202196
2R	5.1	S1-202196	VODAFONE Group Plc	Addition of generic 5G requirements for VIAPA	CR	22.261	0442	1	D	17.2.0	Rel-17	AVPROD	Replaces S1-202050. The CR moves the requirements in TS 22.263 clause 5.1 to the related clauses.	Agreed.
3	5.1.1	S1-202043	LG Electronics Polska	Correction on PER requirement	CR	22.263	0002	F	17.0.0	Rel-17	AVPROD	More discussions until next meeting.	Noted
4	5.1.1	S1-202103	Tencent	Clarification on Definition of Media Clock and Uncompressed Video	CR	22.263	0004	D	17.0.0	Rel-17	AVPROD	The CR: removes brankets in definiton of Media Clock removes RTP protocol from definition of Uncompressed Video	BBC and Futurewei have concerns to remove this. BBC clarifies that RTP payload indeed applies to uncompressed video. CR number missing on cover page.	Revised	S1-202256
4r	5.1.1	S1-202256	Tencent	Clarification on Definition of Media Clock and Uncompressed Video	CR	22.263	0004	1	D	17.0.0	Rel-17	AVPROD	Replaces S1-202103
5	5.1.1	S1-202112	Tencent	Clarification on packet error per hour	CR	22.263	0005	D	17.0.0	Rel-17	AVPROD	The CR proposes editorial changes and further clarifies the packet error per hour v.s. packet error rate (PER.)	Mbit/s to be corrected. CR number missing on cover page. It should not be category D. More discussions needed.	Revised	S1-202257
5r	5.1.1	S1-202257	Tencent	Clarification on packet error per hour	CR	22.263	0005	1	D	17.0.0	Rel-17	AVPROD	Replaces S1-202112
5.2.1	S1-202155	Siemens	Positioning value for further study and editorial changes	CR	22.832	0026	D	17.1.0	Rel-17	FS_eCAV	Clarification of several positioning ffs values and editorial changes.	Revised	S1-202176
1	5.2.1	S1-202133	Siemens	Use Case for Determination of 5G Time Synchronization Budget	discussion	Rel-17	Slideset with Use Cases for Determination of 5G Time Synchronization Budget for discussion	Revised	S1-202172
10	5.2.1	S1-202176	Siemens, Fraunhofer	Positioning value for further study and editorial changes	CR	22.832	0026	1	D	17.1.0	Rel-17	FS_eCAV	Replaces S1-202155	Changes on changes	Revised	S1-202203
10r	5.2.1	S1-202203	Siemens, Fraunhofer	Positioning value for further study and editorial changes	CR	22.832	0026	2	D	17.1.0	Rel-17	FS_eCAV	Replaces S1-202176
1r	5.2.1	S1-202172	Siemens	Use Case for Determination of 5G Time Synchronization Budget	discussion	Rel-17	Replaces S1-202133. 5GS Time Sync Budget needs to provide some flexibility for non-3GPP network parts wrt number of hops (e.g. internal wired network of manufacturing robots, path from sync master to NW-TT). Many industrial use cases have constraints from the application and the operational technology, that require more hops as the at least required, minimalistic two hops (in each non-3GPP network part). With installation guidelines in place that limit the number of hops for an optimized network layout of the non-3GPP network, this sync budget level is sufficient. 800 ns is the proposed value for the 5GS time synchronization budget requirement.	Siemens has in mind 900 ns for end-to-end, with 800 ns for the network.	Noted.
2	5.2.1	S1-202134	Siemens	Update Use Case for 5G Time Synchronization Budget in integrated 5G/TSN networks	CR	22.832	0024	C	17.1.0	Rel-17	FS_eCAV	Added specific use case scenarios (e.g. manufacturing robots) with relevant detail that allow the derivation of a useful 5G time synchronization budget. A table with three useful levels for the 5G time synchronization budget has been derived.	Revised	S1-202173
2r	5.2.1	S1-202173	Siemens	Update Use Case for 5G Time Synchronization Budget in integrated 5G/TSN networks	CR	22.832	0024	1	C	17.1.0	Rel-17	FS_eCAV	Replaces S1-202134	Revised	S1-202201
2rr	5.2.1	S1-202201	Siemens	Update Use Case for 5G Time Synchronization Budget in integrated 5G/TSN networks	CR	22.832	0024	2	C	17.1.0	Rel-17	FS_eCAV	Replaces S1-202173. The CR adds specific use case scenarios (e.g. manufacturing robots) with relevant detail that allow the derivation of a useful 5G time synchronization budget. A table with three useful levels for the 5G time synchronization budget has been derived.	For Nokia, it is too late to add this information in the TR, even as an Annex. Additionnal work should be in another study for a later Release. For Ericsson, such a precision is too high and does not correspond to any practical use. Siemens explained that off-set printing might be such a case, Withdrawn, confusion with numbers.	Revised	S1-202235
2rrr	5.2.1	S1-202235	Siemens	Update Use Case for 5G Time Synchronization Budget in integrated 5G/TSN networks	CR	22.832	0024	3	C	17.1.0	Rel-17	FS_eCAV	Replaces S1-202201
6	5.2.1	S1-202104	Tencent	Alignment and Correction to Change History	CR	22.832	0022	D	17.1.0	Rel-17	FS_eCAV	Revised	S1-202258
6r	5.2.1	S1-202258	Tencent	Alignment and Correction to Change History	CR	22.832	0022	1	D	17.1.0	Rel-17	FS_eCAV	Replaces S1-202104
7	5.2.1	S1-202107	CATT	Delete the editor’s note in 5.14.6	CR	22.832	0023	F	17.1.0	Rel-17	FS_eCAV	The CR deletes the editor’s note of 5.14.6.	Agreed
8	5.2.1	S1-202156	Siemens	Miscellaneous values for further study	CR	22.832	0027	C	17.1.0	Rel-17	FS_eCAV	Clarification of several miscellaneous ffs values and editorial corrections.	Agreed.
9	5.2.1	S1-202157	Siemens	22.832 Miscellaneous editorial corrections	CR	22.832	0028	D	17.1.0	Rel-17	FS_eCAV	Miscellaneous editorial corrections for TR 22.832.	Agreed
5.2.2	S1-202135	Siemens	Update Time Synchronization Budget Requirement for 5G System	CR	22.104	0042	A	17.2.0	Rel-17	eCAV	Based on relevant use case scenarios for time synchronization in integrated 5G/TSN networks, different levels of the 5G time synchronization budget requirement are given in 5.6.2.	Revised	S1-202174
5.2.2	S1-202136	Siemens	Update Time Synchronization Budget Requirement for 5G System	CR	22.104	0043	C	16.4.0	Rel-16	eCAV	Based on relevant use case scenarios for time synchronization in integrated 5G/TSN networks, different levels of the 5G time synchronization budget requirement are given in 5.6.2.	Revised	S1-202175
5.2.2	S1-202148	Ericsson, Nokia, Nokia Shanghai Bell, Orange, Verizon, Vodafone	Time synchronization budget for the 5G system	discussion	This contribution proposes a resolution of the open question on the time synchronization budget for the 5G system.	Revised	S1-202185
5.2.2	S1-202149	Ericsson, Nokia, Nokia Shanghai Bell, Orange, Verizon, Vodafone	Clock synchronicity budget for the 5G system	CR	22.104	0046	F	16.4.0	Rel-16	eCAV	available
5.2.2	S1-202150	Ericsson, Nokia, Nokia Shanghai Bell, Orange, Verizon, Vodafone	Clock synchronicity budget for the 5G system	CR	22.104	0047	A	17.2.0	Rel-17	eCAV	available
5.2.2	S1-202158	Siemens	22.104 Miscellaneous values for further study	CR	22.104	0048	C	17.2.0	Rel-17	eCAV	Clarification of several miscellaneous ffs values and editorial corrections in TS 22.104.	Revised	S1-202177
5.2.2	S1-202174	Siemens	Update Time Synchronization Budget Requirement for 5G System	CR	22.104	0042	1	A	17.2.0	Rel-17	eCAV	Replaces S1-202135
5.2.2	S1-202175	Siemens	Update Time Synchronization Budget Requirement for 5G System	CR	22.104	0043	1	C	16.4.0	Rel-16	eCAV	Replaces S1-202136
5.2.2	S1-202185	Ericsson, Nokia, Nokia Shanghai Bell, Orange, Verizon, Vodafone	Time synchronization budget for the 5G system	discussion	Replaces S1-202148	Discussed together with 2172.	Noted.
1	5.2.2	S1-202066	VODAFONE Group Plc	Discussion on Communication Service Availability and Communication Service Reliability – take 2	discussion	Revised	S1-202197
1r	5.2.2	S1-202197	VODAFONE Group Plc	Discussion on Communication Service Availability and Communication Service Reliability – take 2	discussion	Replaces S1-202066.	Noted.
2	5.2.2	S1-202080	VODAFONE Group Plc	Clarifications to communication service performance requirements	CR	22.104	0040	F	16.4.0	Rel-16	eCAV	Revised	S1-202198
2r	5.2.2	S1-202198	VODAFONE Group Plc	Clarifications to communication service performance requirements	CR	22.104	0040	1	F	16.4.0	Rel-16	eCAV	Replaces S1-202080. The CR clarifies whether the communication service performance requirements are for individual logical communication links or for the whole system.	Revised	S1-202260
2rr	5.2.2	S1-202260	VODAFONE Group Plc	Clarifications to communication service performance requirements	CR	22.104	0040	2	F	16.4.0	Rel-16	eCAV	Replaces S1-202198(r3)
3	5.2.2	S1-202081	VODAFONE Group Plc	Clarifications to communication service performance requirements	CR	22.104	0041	A	17.2.0	Rel-17	eCAV	Revised	S1-202199
3r	5.2.2	S1-202199	VODAFONE Group Plc	Clarifications to communication service performance requirements	CR	22.104	0041	1	A	17.2.0	Rel-17	eCAV	Replaces S1-202081	Revised	S1-202261
3rr	5.2.2	S1-202261	VODAFONE Group Plc	Clarifications to communication service performance requirements	CR	22.104	0041	2	A	17.2.0	Rel-17	eCAV	Replaces S1-202199(r3)
3rrr	5.2.2	S1-202289	Nokia Solutions & Networks (I)	Clarification on the maximum number limit of simultaneous log ins of an MCX user	CR	22.280	Rel-16	MONASTERY2	Rel-16 version of 2279
44	5.2.2	S1-202146	Ericsson, Orange, Vodafone	Correcting description of communication service status in Clause C.3	CR	22.104	0044	F	16.4.0	Rel-16	eCAV	The CR clarifies several aspects of Communication service availability in Annex C.3	WI code to be changed	Revised	S1-202231
44r	5.2.2	S1-202231	Ericsson, Orange, Vodafone	Correcting description of communication service status in Clause C.3	CR	22.104	0044	1	F	16.4.0	Rel-16	eCAV	Replaces S1-202146
45	5.2.2	S1-202147	Ericsson, Orange, Vodafone	Correcting description of communication service status in Clause C.3	CR	22.104	0045	A	17.2.0	Rel-17	eCAV	Revised	S1-202232
45r	5.2.2	S1-202232	Ericsson, Orange, Vodafone	Correcting description of communication service status in Clause C.3	CR	22.104	0045	1	A	17.2.0	Rel-17	eCAV	Replaces S1-202147
46	5.2.2	S1-202184	Siemens	Miscellaneous values for further study	CR	22.104	0051	F	16.4.0	Rel-16	eCAV	Mirrored in S1-202177. The CR clarifies several miscellaneous ffs values and editorial corrections.	Agreed
46r	5.2.2	S1-202177	Siemens	Miscellaneous values for further study	CR	22.104	0048	1	A	17.2.0	Rel-17	eCAV	Replaces S1-202158	Mirror of S1-202177. Should not be cat A since this is not an exact mirror	Open
47	5.2.2	S1-202160	Siemens	22.104 Miscellaneous editorial corrections	CR	22.104	0049	D	17.2.0	Rel-17	eCAV	Miscellaneous editorial corrections in TS 22.104.	Agreed.
5.3	S1-202098	NTT DOCOMO INC.	Discussion on 4G sunset	other	For information on discussion on 4G sunset. It is proposed to gather immediate responses, if any, during this meeting and discuss in detail the way forward in the next SA1 meeting in August.	available
5.3	S1-202128	TNO, Thales, CATT	Performance requirements for satellite access	CR	22.261	0428	3	B	17.2.0	Rel-17	TEI17	Revised	S1-202259
5.3	S1-202182	b<>com	Update description for medical application in section 4.4	CR	22.263	0007	F	17.0.0	Rel-17	CMED
5.3	S1-202183	b<>com	Correction of service performance requirements in tables of annex A.6	CR	22.104	0050	F	17.2.0	Rel-17	CMED
5.3	S1-202189	Nokia Networks	Study on Future Railway Mobile Communication System	SID revised	Rel-15	FS_FRMCS	Replaces S1-202039	Wrong header	Revised	S1-202245
r	5.3	S1-202245	Nokia Networks	Study on Future Railway Mobile Communication System	SID revised	Rel-15	FS_FRMCS	Replaces S1-202189
1	5.3	S1-202039	Nokia Networks	Study on Future Railway Mobile Communication System	SID revised	Rel-15	FS_FRMCS	TR 22.889 is considered as a reference document for Railways. UIC FRMCS project is still ongoing with active working groups dealing with functional and non-functional requirements which could ask for amendments to TR 22.889. UIC would like to consider such technical report as external 3GPP document by revising TR 22.889 to TR 22.989.	Revised	S1-202189
1	5.3	S1-202045	THALES	Embedded UICC correction of reference to 22.101	CR	22.101	0566	F	17.1.0	Rel-17	TEI17	- Clarified that the UICC can be removable or embedded - Clarified that UICC can be a eUICC according to GSMA RSP (independently from its form factor) - Moved the reference to GSMA RSP specifications to the informative references section; - Corrected to the right GSMA RSP specifications (SGP.01 and SGP.21) Reference number is corrected	Revised to S1-202055	S1-202055
10	5.3	S1-202181	b<>com	Correction of CMED KPIs tables	CR	22.263	0006	F	17.0.0	Rel-17	CMED
1r	5.3	S1-202055	THALES	Correction of UICC definition and references	CR	22.101	0566	1	F	17.1.0	Rel-17	TEI17	- Clarified UICC definition in sec 11.a - Corrected the GSMA RSP references in sec.2 and 13.2	open
2	5.3	S1-202046	THALES	UICC alignment to support Multi-USIM services, Draft CR to 21.905	21.905	F	16.0.0	Rel-17	TEI17	Change the UICC definition to allow removable and non-removable UICC use cases.	revised	S1-202056
2r	5.3	S1-202056	THALES	UICC definition alignment	21.905	F	16.0.0	Rel-17	TEI17	Clarify the UICC definition to include removable and non-removable options	TR 21.905 is handled by SA plenary directly, hence no CR number here. To be presented to SA as company contribution, saying that this is "endorsed by SA1"	open
r	5.3	S1-202259	TNO, Thales, CATT	Performance requirements for satellite access	CR	22.261	0428	4	B	17.2.0	Rel-17	TEI17	Replaces S1-202128
6	S1-202124	China Telecom	Private network alignment of TS 22.261	CR	22.261	0445	F	16.11.0	Rel-16	SMARTER_Ph2	Noted
6	S1-202125	China Telecomunication Corp.	Private network alignment of TS 22.261	CR	22.261	0446	F	17.2.0	Rel-17	SMARTER_Ph2	Noted
1	6	S1-202044	LG Electronics Polska	correction to access control for NB-IoT	CR	22.261	0441	F	16.11.0	Rel-16	5G_CIoT	Revised	S1-202202
1r	6	S1-202202	LG Electronics Polska	correction to access control for NB-IoT	CR	22.261	0441	1	F	16.11.0	Rel-16	5G_CIoT	Replaces S1-202044. It is clarfied that - only UE which is authorized to use ‘exception data’ can use AC 10. - AC 10 is used only in NB-IoT cell.	Qualcomm is still investigating on this one. Wrong WI Code.	Revised	S1-202207
1rr	6	S1-202207	LG Electronics Polska	correction to access control for NB-IoT	CR	22.261	0441	2	F	16.11.0	Rel-16	5G_CIoT	Replaces S1-202202. Mirror in S1-202208
1rrr	6	S1-202208	LG Electronics Polska	correction to access control for NB-IoT	CR	22.261	0454	A	17	Rel-17	5G_CIoT	Mirror of S1-202207
41	6	S1-202118	Siemens	Urgent correction of message size in use case modular, flexible production area	CR	22.804	0015	F	16.2.0	Rel-16	FS_CAV	Changed erronous 25 kbyte (supposed to be 0.25 kbyte) to 256 byte	Agreed
99	S1-202210
99	S1-202211
99	S1-202212
99	S1-202213
99	S1-202214
99	S1-202215
99	S1-202216
99	S1-202217
99	S1-202218
99	S1-202236
99	S1-202237
99	S1-202238
99	S1-202239
99	S1-202290	Jose
99	S1-202292
99	S1-202293
99	S1-202294
99	S1-202295
99	S1-202296
99	S1-202297
99	S1-202298
99	S1-202299
99	S1-202011	Chair	Reserved	other	reserved
99	S1-202012	Chair	Reserved	other	reserved
99	S1-202013	Chair	Reserved	other	reserved
99	S1-202014	Chair	Reserved	other	reserved
99	S1-202015	Chair	Reserved	other	reserved
99	S1-202016	Chair	Reserved	other	reserved
99	S1-202017	Chair	Reserved	other	reserved
99	S1-202018	Chair	Reserved	other	reserved
99	S1-202019	Chair	Reserved	other	reserved
99	S1-202020	Chair	Reserved	other	reserved
99	S1-202219