3GPP TSG-SA WG1 Meeting #71

Belgrade, Serbia, 17-21 August 2015

tdoc list SA1#71 draft END OF MEETING _ MINUTES ORDER

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	Spec	CR#	cat	Version in	Rel	WI	Summary	Discussion	Conclusion
010000	1	Zag_item	Zag_item	1 Opening of the meeting	Zag_item
010001	1	S1-152000	Chair	Draft agenda for SA1#71	Revised to S1-152001.
010002	1	S1-152001	Chair	Draft Schedule and Agenda with document allocation for SA1#71	Revised to S1-152002.
010003	1	S1-152002	Chair	Final Schedule and Agenda with document allocation for SA1#71	The newly elected chair, Mr. Toon Norp (KPN), welcomed all the delegates to SA1#71 in Belgrade, Serbia, and wished them a fruitful meeting. He noted the record number of documents and asked them to be quick when presenting	Agreed.
010100	1.1	Zag_item	Zag_item	1.1 Agenda and scheduling	Zag_item
010200	1.2	Zag_item	Zag_item	1.2 IPR, antitrust and competition laws	Zag_item
010300	1.3	Zag_item	Zag_item	1.3 Previous SA1 meeting report	Zag_item
010301	1.3	S1-152004	ETSI	Draft minutes of SA1#70	No last minute comment.	Editorially revised to S1-152005
010301,2	1.3	S1-152005	ETSI	Minutes of SA1#70	Approved.
010400	1.4	Zag_item	Zag_item	1.4 Information for delegates	Zag_item
010500	1.5	Zag_item	Zag_item	1.5 Information for rapporteurs	Zag_item
010600	1.6	Zag_item	Zag_item	1.6 Working agreements	Zag_item
020000	2	Zag_item	Zag_item	2 Issues for early consideration	Zag_item
030000	3	Zag_item	Zag_item	3 Reports and action items	Zag_item
030001	3	S1-152003	Chair	SA1-related topics at SA#68	All the material submitted by SA1 to the plenary was approved.	At least SMARTER will not be finished by March 2016, so either an exception is needed or the complete Stage1 freezing date needs to be pushed back. For Nokia Networks and NEC, March is definitely not realistic, not only for SMARTER but e.g. also for V2X. The completion date for Stage 1 Rel-14 is unchanged, i.e. "not before March 2016".	Noted.
040000	4	Zag_item	Zag_item	4 Liaison Statements (including related contributions)	Zag_item
040001	4	S1-152329	S2-152691	Set of Rel-13 features for the Support of Emergency sessions over WLAN	LS in	SA2 asks SA1, GSMA NG and WBA to take the into account a set of conclusion on SA2's now completed normative work on the Rel-13 Support of Emergency services over WLAN access to EPC (SEW1 Work Item).	This supersedes S1-152370. RIM mention some latest development which might not be included in this version of the LS. The CR in S1-152138 is proposed to be attached to the answer. Qualcomm wonder why a CR introduce "FFS" into a frozen release.	Proposed answer in S1-152269.
040001,2	4	S1-152370	S1-151236/ S1-150172 (Verizon) RILTE #42 Doc 121	LS to 3GPP on IMS Emergency Session over WLAN	LS in
040001,3	4	S1-152138	Alcatel-Lucent, Sprint	Support of Emergency sessions over WLAN	22.101	0502	Revised to S1-152403
040001,3r	4	S1-152403	Alcatel-Lucent, Sprint	Support of Emergency sessions over WLAN	22.101	0502r1	F	13.5.0	Rel-13	TEI-13	Revision of S1-152138. A set of current operating limitations for the basic support of Emergency session over WLAN are added to Rel 13.	The cover page has to be	Revised to S1-152751
040001,3rr	4	S1-152751	Alcatel-Lucent, Sprint	Support of Emergency sessions over WLAN	22.101	0502r2	F	13.5.0	Rel-13	TEI-13	Revision of S1-152403	Agreed.
040002	4	S1-152269	Alcatel-Lucent	Reply LS on Set of Rel-13 features for the Support of Emergency sessions over WLAN	LS draft	Revised to S1-152404
040002	4	S1-152312	C1-152413	LS on handling of uncategorised applications in ACDC	LS in	CT1 asks SA1 to confirm two ACDC related requirements apply or not to the handling of uncategorised applications.	See CR in S1-152402.	Proposed answer in S1-152150
040002,2	4	S1-152402	LG Electronics, NTT DOCOMO, Intel	Handling of uncategorized ACDC applications	22.011	0217	F	13.2.0	Rel-13	ACDC-ST1	Revision of S1-152151. This CR is proposed to solve some mismatch and unclear statements which are blocking points for stage-3 work. The 2 following clarifications are made: - “Applications on a UE that are not assigned to any ACDC category shall be treated by the UE as part of the lowest ACDC category broadcast by the serving network.” - “If the serving network broadcasts more ACDC categories than the UE's configuration, the UE shall use barring information for the matching ACDC category…”; “If the serving network broadcasts barring information for fewer ACDC categories than the UE's configuration, the UE shall use barring information for the matching ACDC category and …”	Revised to S1-152405
040002,2r	4	S1-152405	LG Electronics, NTT DOCOMO, Intel	Handling of uncategorized ACDC applications	22.011	0217r1	F	13.2.0	Rel-13	ACDC	Revision of S1-152402.	Agreed.
040002r	4	S1-152404	Alcatel-Lucent	Reply LS to SA2, GSMA RILTE (cc SA, GSMA NG, WBA) on Set of Rel-13 features for the Support of Emergency sessions over WLAN	LS draft	Revision of S1-152269	CR to be attached.	Revised to S1-152752
040002rr	4	S1-152752	SA1	Reply LS to SA2, GSMA RILTE (cc SA, GSMA NG, WBA) on Set of Rel-13 features for the Support of Emergency sessions over WLAN	LS out	Revision of S1-152404	Agreed.
040003	4	S1-152150	LG Electronics France	Reply LS on ACDC requirements	LS draft	The proposed LS is to show to CT1 the CR proposing to solve the issues mentioned by CT1 (S1-152405).	Revised to S1-152406
040003r	4	S1-152406	SA1	Reply LS to CT1 (cc RAN2) on ACDC requirements	LS out	Revision of S1-152150. The new version of the CR is added.	Agreed.
040004	4	S1-152319	R2-152839	Reply LS on ACDC requirements	LS in	RAN2 asks some clarifications regarding the stage 1 requirements and to provide feedback to the open aspect addressed.	There is no agreement that something else is needed at SA1.	Postponed.
040005	6	S1-152351	Intel, LG Electronics Inc.	Corrections of ACDC Requirements	22.011	0216r1	F	13.2.0	Rel-13	ACDC	Revision of S1-152107 This CR addresses the unclarities and open points pointed out by RAN2 with respect to the SA1's ACDC requirements.	This needs more support and is sent to offline discussion. The change over change are seen confusing.	Revised to S1-152407
040005r	6	S1-152407	Intel, LG Electronics Inc.	Corrections of ACDC Requirements	22.011	0216r2	F	13.2.0	Rel-13	ACDC	Revision of S1-152351	More time is needed before it can be concluded.	Withdrawn
040006	4	S1-152154	Intel	Draft Reply LS on ACDC requirements	LS draft	Proposed answer to S1-152319. This is to show the proposed CR in S1-152351/2407 to try to solve the identified issues.	Revised to S1-152408
040006r	4	S1-152408	Intel	Draft Reply LS on ACDC requirements	LS draft	Revision of S1-152154	Withdrawn
040101	4	S1-152331	S3-151524	Reply LS on public safety discovery	LS in	SA3 ask a set of questions to different groups. For SA1, the main questions are: Q1: SA3 would like to ask SA1 whether there is a requirement for Group Member Discovery? And Q3: Do such groups for Group Member Discovery need to be the same as a group for one-to-many communications? If not, is this an expectation?	See related docs in S1-152398 and proposed answer in S1-152382.	Proposed answer in S1-152382
040102	4	S1-152398	Intel	Discussion on Clarification on ProSe Public Safety Discovery	Revision of S1-152152. In response to the incoming LS from SA3 (S3-151524/S1-152331) this contribution proposes to clarify the Stage 1 requirements for Public Safety discovery. It is proposed to clarify in TS 22.278 that the four following situations are possible: - Restricted Group Member discovery (or “Restricted Public Safety user discovery”) - Open Group Member discovery (or “Open Public Safety user discovery”) - Restricted UE-to-Network Relay discovery, and - Open UE-to-Network Relay discovery.	See S1-152382 proposing another approach.
040103	4	S1-152298	Qualcomm Incorporated	Reply LS: Group Member Discovery / S2-151813	LS draft	Reply LS advising that ProSe Stage 1 has no concept of Group Member Discovery, but that the Restricted Discovery mechanism using Group Membership as a parameter may be a solution to the problem statement	Revised to S1-152382
040103r	4	S1-152382	Qualcomm Incorporated	Reply LS: Group Member Discovery / S2-151813	LS draft	Revision of S1-152298	For Qualcomm, the tool is already in place, there is no need to introduce any specific behaviour. The US Department of Commerce, Alcatel-Lucent, Huawei and Nokia Networks share Qualcomm's view. For Nokia Networks, this is an application layer functionality. For NEC, the current mechanisms are enough, but some extra clarifications might be added to the spec if needed. So Qualcomm's approach is preferred, but there is a need to rephrase the proposed answer. S1-152317, S1-152296, S1-152297, S1-152310 and S1-152328 are noted.	Revised to S1-152409
040103r	4	S1-152409	Qualcomm Incorporated	LS to SA2 and SA3 on S3-151524 on public safety discovery	LS draft	Revision of S1-152382	Clean-up needed.	Revised to S1-152747
040103rr	4	S1-152747	SA1	LS to SA2 and SA3 on S3-151524 on public safety discovery	LS out	Revision of S1-152409	Agreed.
040104	4	S1-152317	R2-151789	LS on ProSe Priorities	LS in	Copied SA1.	Noted.
040106	4	S1-152310	C1-151597	LS on network feature support for ProSe Discovery	LS in	Copied to SA1.	Noted.
040107	4	S1-152328	S2-152064	Reply LS on network feature support for ProSe Discovery	LS in	Copied to SA1.	Noted.
040108	4	S1-152326	S2-151810	LS reply on ProSe Priorities	LS in	SA2 ask a number of questions to RAN2, SA6 and SA1on ProSe Priorities.	See proposed answer in S1-152296.
040108,2	4	S1-152296	Qualcomm Incorporated	Reply LS: Priorities for ProSe Comms / S2-151810	LS draft	Reply LS advising that ProSe stage 1 does not currently define priority level requirements, but advising that an attached CR introduces a requirement for the support of 8 priority levels. This is a proposed answer to S1-152326.	Revised to S1-152411
040108,2r	4	S1-152411	Qualcomm Incorporated	Reply LS to SA2, RAN2, SA6 (cc RAN2) on Priorities for ProSe Comms / S2-151810	LS draft	Revision of S1-152296	Clean-up needed.	Revised to S1-152748
040108,2rr	4	S1-152748	SA1	Reply LS to SA2, RAN2, SA6 (cc RAN2) on Priorities for ProSe Comms / S2-151810	LS out	Revision of S1-152411	Agreed.
040108,4	4	S1-152297	Qualcomm Incorporated	ProSe Priority support	22.278	0220	F	13.2.0	Rel-13	eProSe-ext	CR introducing a Release 13 requirement for ProSe to support at least 8 levels of priority	This is too Stage 2-oriented for Alcatel-Lucent, even if they do not disagree. Ericsson wonder why it is written "at least 8" and if "8" would not be clearer. Also for Nokia Networks, "at least 8" is confusing. Qualcomm thinks it is useful but do not object removing the "at least". To be continued off-line.	Revised to S1-152410
040108,4r	4	S1-152410	Qualcomm Incorporated	ProSe Priority support	22.278	0220r1	F	13.2.0	Rel-13	eProSe-ext	Revision of S1-152297	Withdrawn, covered by the LS in S1-152748.
040201	4	S1-152324	S2-151423	LS on proposed method of restricting access to IOPS cells	LS in	SA2 ask SA1 and RAN2 if it is acceptable: a) that in order to select and access an IOPS cell, public safety UEs must be configured with Access Class 11 or 15; and b) that a cell in IOPS mode shall always broadcast the SystemInformationBlockType1 message with the cellReservedForOperatorUse IE set to "reserved" for the dedicated IOPS PLMN.	Proposed answer in S1-152173.
040202	4	S1-152173	Applied Communication Sciences	Response LS on proposed method of restricting access to IOPS cells	LS draft	Proposed answer to S1-152324. It is proposed to answer to consider including in the IOPS specification clarification statements that: 1. The proposed IOPS solution assumes that Public Safety applications and commercial applications are supported on separate RAN spectrums. 2. Use of Access class 11 or 15 for IOPS is subject to regional/national regulatory requirements and operator policy. 3. Whereas the IOPS solution, as currently identified, illustrates one potential mechanism for supporting IOPS mode of operation, other mechanisms (e.g., use of the Access Class Barring feature) may also be considered.	The Police of the Netherlands wonder if this would work in a roaming context. Some rewording will be done offline.	Revised to S1-152442
040202r	4	S1-152442	Applied Communication Sciences	Response LS to RAN2 (cc Ran2, CT1) on proposed method of restricting access to IOPS cells	LS draft	Revision of S1-152173	Editorial clean-up needed.	Revised to S1-152678
040202rr	4	S1-152678	Applied Communication Sciences	Response LS to SA2 (cc Ran2, CT1) on proposed method of restricting access to IOPS cells	LS out	Revision of S1-152442	Add SA3 in copy.	Revised to S1-152750
040202rrr	4	S1-152750	Applied Communication Sciences	Response LS to SA2 (cc Ran2, CT1) on proposed method of restricting access to IOPS cells	LS out	Revision of S1-152678	Agreed.
040203	4	S1-152318	R2-152783	Response LS on proposed method of restricting access to IOPS cells	LS in	Copied to SA1.	Noted.
040204	4	S1-152311	C1-152403	LS on proposed method of restricting access to IOPS cells	LS in	Copied to SA1.	Noted.
040301	4	S1-152314	EMTEL(15)000021r2	STF489 LS to 3GPP on Total Conversation for Emergency Communications	LS in	SA1, SA2, CT1, and CT3 are requested to note the ongoing work of STF 489 and to consider whether any changes might be required to their specifications in order to support Total Conversation for emergency communications. In particular, STF 489 would be pleased to receive guidance to SC EMTEL #34, relating to the inclusion of assisting services in Total Conversation emergency sessions.	Noted.
040301	4	S1-152472	C6-150294	Reply LS on Specific network availability	LS in	Noted.
040302	4	S1-152313	EMTEL(15)000019r2	STF489 LS to 3GPP SA1 on Real-Time Text versus GTT	LS in	This is an LS from STF489 to 3GPP SA1, showing conflicting terms GTT and Real-Time Text and proposing changes in TS 22.101 to amend the situation and lead implementers to read the most appropriate specification for implementation.	A 3GPP Member has to provide the corresponding CR. Qualcomm is volunteering for this.	Postponed to next meeting.
040401	4	S1-152316	R1-153555	Reply LS on public safety discovery from SA3	LS in	Noted.
040401	4	S1-152321	RiLTE 46_118	LS to 3GPP SA1 on Data Off Requirements	LS in	SA1 is asked to propose a set of requirements for “long terms solution” of Data Off functionality and liaise with NG as needed and upon completion of the work.	The chair underlined that a WID should be proposed to support this work. Orange fully support this proposal.	Postponed.
040402	4	S1-152320	R3-151316	LS on RAN Sharing Enhancements for LTE	LS in	Noted.
040402	4	S1-152325	S2-151431	Reply LS on IMS Emergency Session over WLAN	LS in	Noted.
040405	4	S1-152327	S2-151813	LS reply on Public Safety discovery	LS in	Noted.
040408	4	S1-152397	Intel	CR on Clarification on ProSe Public Safety Discovery	22.278	0219r2	Revision of S1-152350	Noted
040501	4	S1-152330	S3-151499	Reply LS on end-to-end WebRTC-IMS security	LS in	This is an SA3's answer to tell that when using hop-by-hop encryption, the security solution for end-to-access-edge (e2ae) security described in TS 33.328 applies.	Noted.
040601	4	S1-152315	ITU-R 1A/TEMP/100	LS on Report ITU-R SM.[SMART_GRID] on the Smart Grid project	LS in	Noted without presentation.
040602	4	S1-152322	S2-151382	Response to Reply LS on Security Framework for Cellular IoT	LS in	Noted without presentation.
040603	4	S1-152323	S2-151395	Reply LS on ePDG selection	LS in	Noted without presentation.
040604	4	S1-152332	S3i150153	Reply to LS on VoLTE Roaming Architecture GSMA	LS in	Noted without presentation.
040605	4	S1-152333	WTSC-2015-00104R001	LS on VoLTE Roaming architecture	LS in	Noted without presentation.
050000	5	Zag_item	Zag_item	5 New Study and Work Items (including related contributions)	Zag_item
050001	5	S1-152309	China Unicom, ZTE, CATR, Intel, Huawei, CATT	Proposed WID for Enhancements to User Location Reporting Support	WID	Revision of S1-152239. This WID is to enhance the User Location Reporting capabilities. The requirements introduced in TR 22.899 could be taken as a basis for the development of the normative requirements, which includes the following aspects: - Cell-level location reporting at pre-configured time points - Ability to determine which users with common pre-defined characteristics are covered by a defined cell or cells - Location reporting based on the specific area for a certain service offered to a subscriber - Location reporting for non-critical location services under congestion situation	Some delegates have concern about the phrasing, but the idea is globally supported. However, when presenting the CR, some companies have difficulties to understand the relationship/differences with LCS (see discussions related to the CR).	Revised to S1-152445
050001r	5	S1-152445	China Unicom, ZTE, CATR, Intel, Huawei, CATT	Proposed WID for Enhancements to User Location Reporting Support	WID	Revision of S1-152309	Confusion with numbers (2445 and 2455)	Revised to S1-152680
050001rr	5	S1-152680	China Unicom, ZTE, CATR, Intel, Huawei, CATT	Proposed WID for Enhancements to User Location Reporting Support	WID	Revision of S1-152445	The corresponding study should be mentioned.	Revised to S1-152735
050001rrr	5	S1-152735	China Unicom, ZTE, CATR, Intel, Huawei, CATT	Proposed WID for Enhancements to User Location Reporting Support	WID	Revision of S1-152680	Agreed.
050002	5	S1-152240	China Unicom, CATR	Requirements for enhancements on User Location Reporting Support	22.101	0503r1	B	14.0.0	Rel-14	eULRS	This CR is related to the newly proposed WID in S1-152309. It adds the requirements for enhancements on user location reporting capabilities.	Some requirements are quite obvious and can be removed (e.g. "the signalling shall be minimized"). The styles are not correct in this CR. Nokia Networks and Alcatel-Lucent wonder if this is not a duplication of the LCS service, provided in a different way. Or at least, the differences and interactions should be clarified. As long as this fundamental problem is not clarified, this is not agreeable.	Revised to S1-152446
050002r	5	S1-152446	China Unicom, CATR	Requirements for enhancements on User Location Reporting Support (was Proposed WID for Enhancements to User Location Reporting Support)	22.101	0503r2	B	14.0.0	Rel-14	eULRS	Revision of S1-152240	Noted.
050102	5	S1-152258	LG Electronics Inc.	WID proposal – Normative Work proposal for LTE support for V2X services	WID	The objective of this Normative Work is to specify service requirements for: - V2V: covering LTE-based communication between vehicles. - V2P: covering LTE-based communication between a vehicle and a device carried by an individual (e.g. handheld terminal carried by a pedestrian, cyclist, driver or passenger). - V2I/N: covering LTE-based communication between a vehicle and a roadside unit. A roadside unit (RSU) is a transportation infrastructure entity (e.g. an entity transmitting speed notifications).	For Nokia Networks, some more work is needed on the current V2X before next steps can be envisaged. This is also Intel's and Qualcomm's view. A revision number is given in case the discussions can progress significantly during the week.	Revised to S1-152447
050102r	5	S1-152447	LG Electronics Inc.	WID proposal – Normative Work proposal for LTE support for V2X services	WID	Revision of S1-152258	This was further edited while projecting.	Revised to S1-152738
050102rr	5	S1-152738	LG Electronics Inc.	WID proposal – Normative Work proposal for LTE support for V2X services	WID	Revision of S1-152447	Agreed.
050201	5	S1-152299	Qualcomm Incorporated	New Study on Secondary Access LTE Networks	WID	This is a proposal for a new Study item to investigate use cases and requirements for self-contained Secondary Access LTE (SALTE) Network deployments. This includes e.g. studies on: - Identification of scenarios & use cases - Self-contained SALTE network deployments with reduced core network capabilities - Traffic offloading onto SALTE networks on control of the HPLMN	It has to be clarified if this applies to unlicensed versus licensed spectrum cases. Vodafone propose to have a dedicated e-mail discussion to further progress this topic. About licensed/unlicensed, Qualcomm replied that it is market per market dependant. Further clarifications will be developed when discussing by e-mail.The main SA1 reflector will be used, using the tag [SOLTE].	Revised to S1-152454
050201r	5	S1-152454	Qualcomm Incorporated	New Study on Study on Indoor LTE Networks (ILTEN)	WID	Revision of S1-152299. It is no more SALTE but ILTEN.	It should be FS_ILTEN. Some more justifications are needed before it can be agreed.	Noted.
050202	5	S1-152300	Qualcomm Incorporated	Discussion paper	A discussion paper supporting the SALTE SID proposal	This provides more explanations on the need for the new SID.	Noted.
050203	5	S1-152301	Qualcomm Incorporated	Use cases	A set of use cases for the SALTE Study item proposal	Withdrawn.
060000	6	Zag_item	Zag_item	6 Rel-13 and earlier contributions	Zag_item
070000	7	Zag_item	Zag_item	7 Rel-14 Work Item contributions	Zag_item
070100	7.1	Zag_item	Zag_item	7.1 MPS_Mods: Multimedia Priority Service (MPS) Modifications [SP-150043]	Zag_item
070101	7.1	S1-152174	Applied Communication Sciences, OEC, AT&T, Alcatel-Lucent	MPS exemption from load rebalancing	22.153	0022	F	14.0.0	Rel-14	MPS_mods	The Stage 1 requirement is corrected to also provide an exemption from load rebalancing, and to align with existing Stage 2 specifications.	Agreed.
070102	7.1	S1-152175	Applied Communication Sciences, OEC, AT&T, Alcatel-Lucent	Passing of priority information across network boundaries	22.153	0023	C	14.0.0	Rel-14	MPS_mods	Deletion of the note in Section 5.3 and inclusion of a new requirements for non-MPS capable networks to transparently pass priority information.	Nokia Networks stressed out that, for a network not supporting MPS, the MPS specification 22.153 does not apply.	Noted.
070103	7.1	S1-152176	Applied Communication Sciences, OEC, AT&T, Alactel-Lucent	MPS priority during initial Attach	22.153	0024	F	14.0.0	Rel-14	MPS_mods	This CR clarifies that MPS priority treatments are provided by the 3GPP network prior to access to subscription related information in the 3GPP network.	The wording has to be changed ("3GPP network" to be changed to "3GPP system" as to include the USIM).	Revised to S1-152455
070103r	7.1	S1-152455	Applied Communication Sciences, OEC, AT&T, Alactel-Lucent	MPS priority during initial Attach	22.153	0024r1	F	14.0.0	Rel-14	MPS_mods	Revision of S1-152176	Confusion with numbers (2445 and 2455)	Revised to S1-152679
070103rr	7.1	S1-152679	Applied Communication Sciences, OEC, AT&T, Alactel-Lucent	MPS priority during initial Attach	22.153	0024r2	F	14.0.0	Rel-14	MPS_mods	Revision of S1-152455	Revision on revision to be deleted.	Revised to S1-152681
070103rrr	7.1	S1-152681	Applied Communication Sciences, OEC, AT&T, Alactel-Lucent	MPS priority during initial Attach	22.153	0024r3	F	14.0.0	Rel-14	MPS_mods	Revision of S1-152679	Agreed.
070200	7.2	Zag_item	Zag_item	7.2 ELIOT: Enhancing Location Capabilities for Indoor and Outdoor Emergency Communications [SP-150044]	Zag_item
070201	7.2	S1-152065	Sprint	Addition of civic location reporting for Emergency Services	22.071	0082	B	14.0.0	Rel-14	ELIOT	Provide civic location reporting for Emergency Services to meet US FCC regulation for location accuracy improvement. One element of the regulations requires the ability to report a dispatchable location which is a civic location of the UE allowing first responders to be dispatched to the UE's current location.	There is an "FFS" proposed to be introduced in a stable specification. Either the sentence has to be removed or the CR can be postponed until this is solved. The list is misleading: not all the points have to be supported by all the terminals (Galileo, Beidou, etc). This should be clarified.	Revised to S1-152449
070201r	7.2	S1-152449	Sprint	Addition of civic location reporting for Emergency Services	22.071	0082r1	B	14.0.0	Rel-14	ELIOT	Revision of S1-152065	The note is to be corrected.	Revised to S1-152739
070201rr	7.2	S1-152739	Sprint	Addition of civic location reporting for Emergency Services	22.071	0082r2	B	14.0.0	Rel-14	ELIOT	Revision of S1-152449	Agreed.
070300	7.3	Zag_item	Zag_item	7.3 Control of Applications when Third party Servicers encounter difficulties [SP-150273]	Zag_item
070301	7.3	S1-152082	KDDI, Qualcomm, Intel, China Telecom, Nokia Networks, TeliaSonera AB, NEC	Enhancements for control of traffic from UE-based applications toward associated server	22.011	0215	B	13.2.0	Rel-14	CATS	This CR adds requirements for controling traffic from UE-based applications to the affected application(s) on the third party server(s) or the third party server itself while not affecting other traffic	This is an outcome of the CATS study. There is a problem with the cover page ("other spec affected"). "no" should be ticked.	Revised to S1-152456
070301r	7.3	S1-152456	KDDI, Qualcomm, Intel, China Telecom, Nokia Networks, TeliaSonera AB, NEC	Enhancements for control of traffic from UE-based applications toward associated server	22.011	0215r1	B	13.2.0	Rel-14	CATS	Revision of S1-152082	Agreed.
070302	7.3	S1-152083	KDDI, Qualcomm, Intel, China Telecom, Nokia Networks, TeliaSonera AB, NEC	Enhancements for control of traffic from UE-based applications toward associated server	22.101	0501	B	14.0.0	Rel-14	680002	This CR adds requirements for controling traffic from UE-based applications to the affected application(s) on the third party server(s) or the third party server itself while not affecting other traffic	Same comment on other specs. The WI code should be the acronym and not the number ("CATS" instead of the UID).	Revised to S1-152457
070302r	7.3	S1-152457	KDDI, Qualcomm, Intel, China Telecom, Nokia Networks, TeliaSonera AB, NEC	Enhancements for control of traffic from UE-based applications toward associated server	22.101	0501r1	B	14.0.0	Rel-14	CATS	Revision of S1-152083	Agreed.
070400	7.4	Zag_item	Zag_item	7.4 Other Rel-14 contributions	Zag_item
080000	8	Zag_item	Zag_item	8 Study Item contributions	Zag_item
080100	8.1	Zag_item	Zag_item	8.1 FS Smarter: New Services and Markets Technology Enablers [SP-150142]	Zag_item
080101	8.1	S1-152205	Orange	Presentation of 5G Security and Authentications issues	Orange proposes the following requirements for 5G security and authentication: - The subscriber’s identity together with the credentials allowing the access to a given network shall be stored in only a dedicated physical secured and tamper resistant entity controlled and managed by mobile operator. - This physical entity must be certifiable	Intel wondered if the embedded UICC is also supported. Orange's view is that embedded UICC ("eUICC") might be also supported. For Vodafone, the wording used in these slides is too strong and seem to forbid the eUICC, since e.g. the words "SIM card" are used. For NEC, the basic requirement is that the user ID is secured. The way it is secured (dedicated card or not) is already a solution to this requirement. For Telefónica, security is a global topic that has to be addressed for 5G. The "card" (or not) is only one aspect of it. What is required for a "phone" might be different from what is required from a small sensor. For Orange, the security cannot be lower than the one of previous generations.	Noted. See S1-152206.
080101	8.1.1	Zag_item	Zag_item	8.1.1 FS_SMARTER drafting session information	Zag_item
080101,2	8.1	S1-152206	Orange	General 5G Security, Identity and Authentication requirements	Based on proposals in the discussion paper S1-152205, this contribution proposes the following requirements: the <5G Network> needs to keep supporting the existing way how mobile operators control and manage subscriber’s identity and the credentials.	See other contributions on this topic. A revision number is offered, hoping that it will be compatible with the view of the "other camp".	Revised to S1-152467
080101,2r	8.1	S1-152467	Orange	General 5G Security, Identity and Authentication requirements	Revision of S1-152206	Noted.
080102	8.1	S1-152106	Intel Corporation (UK) Ltd	Use Case on SMARTER Meters	This use case enables the remote provisioning and management of an Embedded UICC (eUICC) for IoT devices that are not easily reachable.	See also S1-152149 on the same topic.	S1-152106, S1-152149 and S1-152146 in S1-152468.
080103	8.1	S1-152149	NEC EUROPE LTD	SMARTER Use Case for IoT Device roaming	This paper presents a generic use case where an IoT device manufacturer sells his devices worldwide (=IoT device roaming). The device is “blank”, it contains no credentials of a IoT service provider nor of a cellular network operator. When the IoT device is switched on the first time it needs to be registered with a IoT service provider and get authenticated with some 3GPP network. This use case involves a phase, in which the “blank” device can communicate – encrypted but unauthenticated – with its manufacturer to receive necessary information.	See also S1-152146 on the same topic.	S1-152106, S1-152149 and S1-152146 in S1-152468.
080105	8.1	S1-152468	NEC, Qualcomm, Alcatel-Lucent, Intel, Huawei	SMARTER Use Case for IoT Device initialization	Merging of S1-152106, S1-152149 and S1-152146.	Revised to S1-152691
080105r	8.1	S1-152691	NEC, Qualcomm, Alcatel-Lucent, Intel, Huawei, MediaTek	SMARTER Use Case for IoT Device initialization	Revision of S1-152468. Merging of S1-152106, S1-152149 and S1-152146. The requirement now reads: "The 3GPP System shall support a secure mechanism (e.g. a factory installed certificate) that enables a device (e.g. IoT device) that has not been provided with a 3GPP subscription to establish access to a 3GPP network. The 3GPP network shall support a secure mechanism to remotely provide the unauthenticated device with a particular 3GPP subscription and other, third party provided, device configuration credentials."	For Gemalto, this is describing solutions rather than requirements, e.g. on the certificate. For Ericsson and NEC, Gemalto is too focussed on current solutions, and this is more generic. Gemalto pointed out that this use case is already covered by GSMA and work should not be duplicated between the two fora. At least Orange, Gemalto, TeliaSonera have concerned with this proposal. No consensus. 15 companies are in favour to put it in with an editor note stating that more work is needed. The 3 companies above are not in favour of having it at all. TeliaSonera do not maintain their objection and one more company is in favour, so it turned to be 16 against 2. So the text will go in the TR with an editor's note to state that this is not stable. Orange and Gemalto maintain their objection. For Gemalto, this text is proposed for first time to SA1. This is not NEC's view. The 3GPP Working Agreement was pointed out and the corresponding process was read out of the Working Procedure, but the chair decided to go for the solution of including the controversial text adding a note.	Revised to S1-152729
080105rr	8.1	S1-152729	NEC, Qualcomm, Alcatel-Lucent, Intel, Huawei, MediaTek	SMARTER Use Case for IoT Device initialization	Revision of S1-152691	Agreed.
080110	8.1	S1-152147	Alcatel-Lucent	FS_SMARTER: Security key update	This contribution describes a scenario for enhanced security measures in IoT. Along with the other new capabilities expected in a 5G system such as lightweight provisioning, connectionless access, infrequent access, etc., new opportunities for fraud with IoT UEs are sure to be encountered. In order to protect UEs and the network, it would be desireable to be able to periodically, or when fraud is detected, update the security keys for a UE. This use case proposes requirements for such a security enhancement.	Revised to S1-152469
080110r	8.1	S1-152469	Alcatel-Lucent	FS_SMARTER: Security key update	Revision of S1-152147. The requirements now read: "The 3GPP System shall support a secure mechanism to update subscription security for an IoT device. UE shall support a mechanism to generate a new security key in response to a request from the network."	For Gemalto, this is again a solution and not requirements. "security key" to be replaced by "security credentials" since it is more generic. They wonder if this does not cover the point in S1-152729. The chair does not want to reopen the discussion on this other document. Slightly edited while projecting.	Revised to S1-152730
080110rr	8.1	S1-152730	Alcatel-Lucent	FS_SMARTER: Security key update	Revision of S1-152469	Was agreed but off-line request for revision by Telecom Italia. Sustained objection from Orange, who proposed S1-152749.	Agreed. Revised to S1-152749
080110rrr	8.1	S1-152749	Alcatel-Lucent	FS_SMARTER: Security key update	Revision of S1-152730	Objection from Orange.	Noted.
080111	8.1	S1-152274	Qualcomm Incorporated	SMARTER: Use case for access from less trusted networks	This is a proposed use case and requirements for mobile subscriber identity privacy: "In order to protect user privacy and access across less trusted networks, the UE may use a temporary identifier for attach. The home network shall be able to associate the temporary identifier to the IMSI."	The difference with the current mechanism is that the TMSI is used already from the first attach (no need to use the IMSI). The SA3 chair explained that the IMIS is now sent because there is no knowledge of any other identity, so the mechanism of how the TMSI can be associated with the IMSI has to be clarified.	Revised to S1-152470
080111r	8.1	S1-152470	Qualcomm Incorporated	SMARTER: Use case for access from less trusted networks	Revision of S1-152274. References to TMSI/IMSI have been removed and the requirements are now: "In order to protect user privacy and access across less trusted networks, the UE may use an identifier that hides its long term subscription identity for initial attach. The home network shall be able to associate this identifier to the long term subscription identity."	This was also further edited while projecting. More edited needed offline.	Revised to S1-152731
080111rr	8.1	S1-152731	Qualcomm Incorporated	SMARTER: Use case for access from less trusted networks	Revision of S1-152470	Revised to S1-152753
080111rrr	8.1	S1-152753	Qualcomm Incorporated	SMARTER: Use case for access from less trusted networks	Revision of S1-152731	Sustained objection from Orange.	Agreed.
080131	8.1	S1-152073	ZTE Corporation	Proposal for cooperative communication use case for SMARTER	This contribution presents one cooperative communication among UEs use case.	Revised to S1-152394
080131	8.1	S1-152077	Intel Corporation (UK) Ltd	Use Case on SMARTER Service Continuity	Revised to S1-152400
080131r	8.1	S1-152394	ZTE Corporation	Proposal for cooperative communication use case for SMARTER	Revision of S1-152073	Revised to S1-152412
080131r	8.1	S1-152400	Intel Corporation (UK) Ltd	Use Case on SMARTER Service Continuity	Revision of S1-152077	Revised to S1-152464
080131rr	8.1	S1-152412	ZTE Corporation, China Unicom	Proposal for cooperative communication use case for SMARTER	Revision of S1-152394	Noted.
080131rr	8.1	S1-152464	Intel Corporation (UK) Ltd	Use Case on SMARTER Service Continuity	Revision of S1-152400	Revised to S1-152473
080131rrr	8.1	S1-152473	Intel Corporation (UK) Ltd	Use Case on SMARTER Service Continuity	Revision of S1-152464	Revised to S1-152484
080131rrrr	8.1	S1-152484	Intel Corporation (UK) Ltd	Use Case on SMARTER Service Continuity	Revision of S1-152473	Revised to S1-152693
080131rrrrr	8.1	S1-152693	Intel Corporation (UK) Ltd	Use Case on SMARTER Service Continuity	Revision of S1-152484	Agreed.
080132	8.1	S1-152401	Intel Corporation (UK) Ltd	SMARTER Use case for Bio-connectivity	Revision of S1-152076	Revised to S1-152413
080132r	8.1	S1-152413	Intel Corporation (UK) Ltd	SMARTER Use case for Bio-connectivity	Revision of S1-152401	Agreed.
080134	8.1	S1-152112	Huawei Device Co., Ltd	SMARTER Use Case for Wearable Device Communication	Revised to S1-152385
080134r	8.1	S1-152385	Huawei Device Co., Ltd	SMARTER Use Case for Wearable Device Communication	Revision of S1-152112	Revised to S1-152414
080134rr	8.1	S1-152414	Huawei, Hisilicon, SKT, CATT, China Unicom, China Telecom, ETRI, ZTE, China Mobile, ITRI, NEC, KPN, Sony, LGE	SMARTER Use Case for Wearable Device Communication	Revision of S1-152385	For Orange, the "independent Identity" for the IMSI is a vague concept: the IMSI is a subscriber identifier and nothing else. The QoS requirement was edited. It was further edited while projecting.	Revised to S1-152706
080134rrr	8.1	S1-152706	Huawei, Hisilicon, SKT, CATT, China Unicom, China Telecom, ETRI, ZTE, China Mobile, ITRI, NEC, KPN, Sony, LGE	SMARTER Use Case for Wearable Device Communication	Revision of S1-152414	Agreed.
080135	8.1	S1-152075	Intel Corporation (UK) Ltd	SMARTER Use Case on Best Connection per Traffic Type	This use case allows for different traffic types (from different applications or services) from the same device to be routed via different RAN nodes, based on operator policy and application requirements.	Revised to S1-152415
080135	8.1	S1-152177	China Telecom, ZTE Corporation	Proposal for ultra short range wearable devices use case for SMARTER	Merged with S1-152385 in S1-152414.
080135r	8.1	S1-152415	Intel Corporation (UK) Ltd	SMARTER Use Case on Best Connection per Traffic Type	Revision of S1-152075	The figure is not editable.	Revised to S1-152707
080135rr	8.1	S1-152707	Intel Corporation (UK) Ltd	SMARTER Use Case on Best Connection per Traffic Type	Revision of S1-152415	Agreed.
080136	8.1	S1-152100	HUAWEI TECHNOLOGIES Co. Ltd.	SMARTER use case for 3GPP / Non-3GPP access network integration	22.891	Revised to S1-152416
080136r	8.1	S1-152416	Huawei, Deutsche Telekom, KPN, Telefonica, TeliaSonera, Vodafone	SMARTER use case for 3GPP / Non-3GPP access network integration	22.891	Revision of S1-152100	Edited while projecting.	Revised to S1-152709
080136rr	8.1	S1-152709	Huawei, Deutsche Telekom, KPN, Telefonica, TeliaSonera, Vodafone	SMARTER use case for 3GPP / Non-3GPP access network integration	22.891	Revision of S1-152416	Agreed.
080137	8.1	S1-152129	Telefonica Europe plc	SMARTER Use Case on Concurrent Multi-Access	Revised to S1-152155
080137b	8.1	S1-152155	Telefonica Europe plc	SMARTER Use Case on Concurrent Multi-Access	Revision of S1-152129	Revised to S1-152474
080137r	8.1	S1-152474	NTT DOCOMO, NEC	Multiple RAT connectivity and RAT selection	Revision of S1-152155	Agreed.
080141	8.1	S1-152335	Rapporteur / Session Chair	FS_SMARTER drafting report	Agreed.
080142	8.1	S1-152081	ZTE Corporation	Update the coexistence with legacy systems	It is proposed to update the use case of coexistence with legacy systems.	Revised to S1-152396
080142	8.1	S1-152109	Nokia Networks Oy	General cleanup of TR 22.891	Revised to S1-152499
080142	8.1	S1-152334	Rapporteur / Session Chair	FS_SMARTER drafting agenda	Noted.
080142r	8.1	S1-152396	ZTE Corporation	Update the coexistence with legacy systems	Revision of S1-152081	Revised to S1-152492
080142r	8.1	S1-152499	Nokia Networks Oy	General cleanup of TR 22.891	Revision of S1-152109	Agreed.
080142rr	8.1	S1-152492	ZTE Corporation	Update the coexistence with legacy systems	Revision of S1-152396	Revised to S1-152694
080142rrr	8.1	S1-152694	ZTE Corporation, China Unicom, Intel Corporation	Update the coexistence with legacy systems	Revision of S1-152492	Cisco still has the same objections.	Noted.
080143	8.1	S1-152121	Nokia Networks Oy	SMARTER Latency	Noted.
080144r	8.1	S1-152677	Huawei	Clarification for latency signification	Revision of S1-152191	Only the transmission delay is meant, not the processing time. This should be clarified.	Revised to S1-152728
080144rr	8.1	S1-152728	Huawei	Clarification for latency signification	Revision of S1-152677	Agreed.
080145	8.1	S1-152276	Qualcomm Incorporated	SMARTER: Radio Interface Technology definition	This paper proposes a definition for the term Radio Interface Technology (RIT).	Agreed.
080146	8.1	S1-152087	HUAWEI TECHNOLOGIES Co. Ltd., Telecom Italia	Directions for SMARTER requirements	22.891	Not handled
080148	8.1	S1-152210	Nokia Networks	Use case categorisation	Not handled
080152	8.1	S1-152241	ITRI	Mobile broadband service anytime and anywhere with seamless wide-area coverage	Revised to S1-152451
080152r	8.1	S1-152451	ITRI	Mobile broadband service anytime and anywhere with seamless wide-area coverage	Revision of S1-152241	Revised to S1-152417
080152rr	8.1	S1-152417	ITRI	Mobile broadband service anytime and anywhere with seamless wide-area coverage	Revision of S1-152451	Agreed.
080153	8.1	S1-152224	Vodafone	SMARTER: Higher User Mobility use cases	Revised to S1-152418
080153r	8.1	S1-152418	Vodafone	SMARTER: Higher User Mobility use cases	Revision of S1-152224	Agreed.
080154	8.1	S1-152185	LG Electronics	connectivity everywhere	This paper discusses the expanded coverage in the future networking	Revised to S1-152419
080154r	8.1	S1-152419	LG Electronics	connectivity everywhere	Revision of S1-152185	Revised to S1-152711
080154rr	8.1	S1-152711	LG Electronics	connectivity everywhere	Revision of S1-152419	Revised to S1-152754
080154rrr	8.1	S1-152754	LG Electronics	connectivity everywhere	Revision of S1-152711	Agreed.
080155	8.1	S1-152187	LG Electronics	Diversified point of connectivity	this paper discusses various way how connectivity is provided in the future	Not handled.
080156	8.1	S1-152245	Huawei	Moving Ambulance and Bio-connectivity	Not handled.
080157	8.1	S1-152157	KDDI	Service Provision for Non-subscribed Users in Emergency Case	Revised to S1-152498
080157r	8.1	S1-152498	KDDI	Temporary Service for Users of Other Operators in Emergency Case	Revision of S1-152157. The requirements have been rephrased in: "- 3GPP system shall be able to support temporary service for users of other operators as temporary users in emergency case by serving operator policy. - 3GPP system shall be able to support defining the limited set of necessary communication services and acceptable terminal features for temporary users by serving operator policy. - 3GPP system shall maintain an appropriate level of communications security for temporary service."	This is agreeable as such but should be further edited at some point for clarifications, for MediaTek and Orange. "subject to national regulation" still to be added.	Revised to S1-152732
080157rr	8.1	S1-152732	KDDI	Temporary Service for Users of Other Operators in Emergency Case	Revision of S1-152498	Agreed.
080158	8.1	S1-152202	China Mobile	SMARTER use case for mobile enterprise	Not handled.
080159	8.1	S1-152229	Huawei	Cross-Domain Resource Management and QoS Guarantee	Revised to S1-152444
080159r	8.1	S1-152444	Huawei	Cross-Domain Resource Management and QoS Guarantee	Revision of S1-152229	Not handled
080160	8.1	S1-152246	Huawei	On-demand deployment of physical access network infrastructure	Not handled.
080161	8.1	S1-152280	Qualcomm Incorporated	SMARTER: Use case for multiple services with different subscriptions	Abstract: This paper proposes introductory use cases to support multiple services with different credentials.	Not handled.
080162	8.1	S1-152303	ETRI	eMVNO Service using Open Radio Access Platform	Not handled.
080164	8.1	S1-152214	Nokia Networks	Proposed new FS_SMARTER use case on Phased approach	Not handled.
080171a	8.1	S1-152192	Huawei	Improvement of Network Capabilities to support Vehicular	Revised to S1-152386
080171ar	8.1	S1-152386	Huawei	Improvement of Network Capabilities to support Vehicular	Revised to S1-152421
080171arr	8.1	S1-152421	Huawei, Sony	Improvement of Network Capabilities to support Vehicular	Revision of S1-152386	Some text on what needs further works to be changed into Editor's notes. LG considers that this is already covered by the high mobility use cases. It relates also to S1-152708. For the Rapporteur, at this stage, all use cases can be added, then the grouping of similar ones will be done at a later phase.	Revised to S1-152734
080171arrr	8.1	S1-152734	Huawei, Sony	Improvement of Network Capabilities to support Vehicular	Revision of S1-152421	Agreed.
080171b	8.1	S1-152194	Huawei	Use case for connected vehicles	Revised to S1-152422
080171br	8.1	S1-152422	Huawei	Use case for connected vehicles	Revision of S1-152194	Revised to S1-152708
080171brr	8.1	S1-152708	Huawei , CATT, Qualcomm, LG Electronics	Use case for connected vehicles	Revision of S1-152422	Agreed.
080171c	8.1	S1-152200	CATT	Use case for automatic driving	Revised to S1-152423
080171cr	8.1	S1-152423	CATT	Use case for automatic driving	Revision of S1-152200	withdrawn
080171d	8.1	S1-152223	GM Onstar Europe	Use case on Autonomous Drive	Noted.
080171e	8.1	S1-152251	Huawei	Cooperative Lane Merging (CLM)	Withdrawn
080171f	8.1	S1-152252	Huawei	Cooperative Longitudinal & Lateral Control for Collision Avoidance (CoLCA)	Noted.
080171g	8.1	S1-152253	Huawei	Cooperative Short Distance Platooning (CoSdP)	Not handled.
080171h	8.1	S1-152254	Huawei	See-Through for assisted Overtaking (STOk)	Not handled.
080171i	8.1	S1-152275	Qualcomm Incorporated	SMARTER: Use case for Automotive: Automated Cooperative Driving	Abstract: Use case for Automotive Cooperative Driving Automation	Not handled.
080176a	8.1	S1-152074	ZTE Corporation	update the network slicing use case in SMARTER	This contribution proposes to update the network slicing use case in SMARTER TR.	Revised to S1-152395
080176ar	8.1	S1-152395	ZTE Corporation	update the network slicing use case in SMARTER	Revision of S1-152074	Revised to S1-152424
080176arr	8.1	S1-152424	ZTE Corporation	update the network slicing use case in SMARTER	Revision of S1-152395	Revised to S1-152712
080176arrr	8.1	S1-152712	ZTE Corporation	update the network slicing use case in SMARTER	Revision of S1-152424	Agreed.
080176b	8.1	S1-152090	HUAWEI TECHNOLOGIES Co. Ltd.	Identify minimum applications’ functions needed for slice	22.891	Noted.
080176c	8.1	S1-152092	HUAWEI, Telecom Italia, NTTDOCOMO	Clarify the need for slices to be scalable	22.891	Revised to S1-152425
080176cr	8.1	S1-152425	HUAWEI, Telecom Italia, NTTDOCOMO	Clarify the need for slices to be scalable	22.891	Revision of S1-152092	Revised to S1-152713
080176crr	8.1	S1-152713	HUAWEI, Telecom Italia, NTTDOCOMO	Clarify the need for slices to be scalable	22.891	Revision of S1-152425	Agreed.
080176d	8.1	S1-152095	HUAWEI TECHNOLOGIES Co. Ltd.	Clarify network slicing shall consider multiple applications in a UE	22.891	Revised to S1-152426
080176dr	8.1	S1-152426	HUAWEI TECHNOLOGIES Co. Ltd.	Clarify network slicing shall consider multiple applications in a UE	22.891	Revision of S1-152095	Withdrawn.
080176e	8.1	S1-152156	NTT DOCOMO	Network slicing – service/traffic dependent selection	Revised to S1-152427
080176ea	8.1	S1-152199	CATT	SMARTER the requirement of UE obtaining services from different network slices simultaneously	Noted.
080176eb	8.1	S1-152226	Huawei	Coordination of network slices	Revised to S1-152443
080176ebr	8.1	S1-152443	Huawei	Coordination of network slices	Revision of S1-152226	Revised to S1-152429
080176ec	8.1	S1-152227	Huawei, NEC	Cross-Domain Resource Management for network slicing	Not handled.
080176er	8.1	S1-152427	NTT DOCOMO	Network slicing – service/traffic dependent selection	Revision of S1-152156	Revised to S1-152428
080176err	8.1	S1-152428	NTT DOCOMO	Network slicing – service/traffic dependent selection	Revision of S1-152427	Agreed.
080176f	8.1	S1-152228	Huawei	Categories of Network Slices	Revised to S1-152430
080176fr	8.1	S1-152430	Huawei	Categories of Network Slices	Revision of S1-152228	Withdrawn
080176g	8.1	S1-152103	Cisco	Mobility on demand	Revised to S1-152420
080176gr	8.1	S1-152420	Cisco	Mobility on demand	Revision of S1-152103	Revised to S1-152431
080176grr	8.1	S1-152431	Cisco	Mobility on demand	Revision of S1-152420	Agreed.
080176h	8.1	S1-152091	HUAWEI TECHNOLOGIES Co. Ltd.	Mobility as a service	22.891	Revised to S1-152432
080176hr	8.1	S1-152432	HUAWEI TECHNOLOGIES Co. Ltd.	Mobility as a service	22.891	Revision of S1-152091	Merged into S1-152431.
080176i	8.1	S1-152093	Huawei, Telecom Italia	Context awareness and automatic network	22.891	Revised to S1-152433
080176ir	8.1	S1-152433	Huawei, Telecom Italia	Context awareness and automatic network	22.891	Revision of S1-152093	Revised to S1-152714
080176irr	8.1	S1-152714	Huawei, Telecom Italia	Context awareness and automatic network	22.891	Revision of S1-152433	Agreed.
080176j	8.1	S1-152078	Intel Corporation (UK) Ltd	Use Case on SMARTER Device Profile	Revised to S1-152399
080176jr	8.1	S1-152399	Intel Corporation (UK) Ltd	Use Case on SMARTER Device Profile	Revision of S1-152078	Noted.
080176k	8.1	S1-152279	Qualcomm Incorporated	SMARTER: Use case for multiple services with dedicated core networks	Abstract: This paper proposes use cases for multiple simultaneous core network sessions support.	Revised to S1-152434
080176kr	8.1	S1-152434	Qualcomm Incorporated	SMARTER: Use case for multiple services with dedicated core networks	Revision of S1-152279	Withdrawn.
080181a	8.1	S1-152102	HUAWEI TECHNOLOGIES Co. Ltd.	Clarification of flexible traffic routing during communication	22.891	Revised to S1-152435
080181b	8.1	S1-152104	Cisco Systems Belgium	Correction of use case on flexible application traffic routing	Merged in S1-152435
080181br	8.1	S1-152435	Cisco Systems Belgium	Correction of use case on flexible application traffic routing	22.891	Revision of S1-152104	Agreed.
080181c	8.1	S1-152099	HUAWEI TECHNOLOGIES Co. Ltd.	New use case for In-network CDN	22.891	Revised to S1-152436
080181cr	8.1	S1-152436	HUAWEI TECHNOLOGIES Co. Ltd.	New use case for In-network CDN	22.891	Revision of S1-152099	Revised to S1-152715
080181crr	8.1	S1-152715	HUAWEI TECHNOLOGIES Co. Ltd.	New use case for In-network CDN	22.891	Revision of S1-152436	Revised to S1-152755
080181crrr	8.1	S1-152755	HUAWEI TECHNOLOGIES Co. Ltd.	New use case for In-network CDN	22.891	Revision of S1-152715	Agreed.
080181d	8.1	S1-152096	HUAWEI TECHNOLOGIES Co. Ltd.	New use case for local server support	22.891	Revised to S1-152437
080181dr	8.1	S1-152437	HUAWEI TECHNOLOGIES Co. Ltd.	New use case for local server support	22.891	Revision of S1-152096	Revised to S1-152717
080181drr	8.1	S1-152717	HUAWEI TECHNOLOGIES Co. Ltd.	New use case for local server support	22.891	Revision of S1-152437	Revised to S1-152756
080181drrr	8.1	S1-152756	HUAWEI TECHNOLOGIES Co. Ltd.	New use case for local server support	22.891	Revision of S1-152717	Agreed.
080181e	8.1	S1-152098	HUAWEI TECHNOLOGIES Co. Ltd.	Mobility coordination support for local access to application	22.891	Merged S1-152096.	Revised to S1-152437
080181f	8.1	S1-152131	Telefonica Europe plc	SMARTER Use Case on ICN Based Content Retrieval	Agreed.
080181g	8.1	S1-152134	Telefonica Europe plc	SMARTER Use Case on Wireless Briefcase	Revised to S1-152438
080181gr	8.1	S1-152438	Telefonica Europe plc	SMARTER Use Case on Wireless Briefcase	Revision of S1-152134	Revised to S1-152716
080181grr	8.1	S1-152716	Telefonica Europe plc	SMARTER Use Case on Wireless Briefcase	Revision of S1-152438	Agreed.
080186a	8.1	S1-152141	Alcatel-Lucent	5G SENSOR DEVICES: UNDERLYING PRINCIPLES FOR POTENTIAL SERVICE AND OPERATIONAL REQUIREMENTS	Noted.
080186b	8.1	S1-152108	Nokia Networks Oy	Proposed new FS_SMARTER use case on Sports and Fitness	Revised to S1-152439
080186br	8.1	S1-152439	KPN, Sony, Nokia Networks	Proposed new FS_SMARTER use case on Sports and Fitness	Revision of S1-152108	The 2nd part should be shown as a note.	Revised to S1-152733
080186brr	8.1	S1-152733	KPN, Sony, Nokia Networks	Proposed new FS_SMARTER use case on Sports and Fitness	Revision of S1-152439	Agreed.
080186c	8.1	S1-152118	Sony Europe Limited	SMARTER Use Case on Sports and Fitness Wearables	Merged with S1-152108 in S1-152439.
080186d	8.1	S1-152190	Huawei, China Mobile, China Telecom, CATR, CATT	Massive connections for constrained cellular internet of things (CIoT)	Revised to S1-152475
080186dr	8.1	S1-152475	Huawei, China Mobile, China Telecom, CATR, CATT	Massive connections for constrained cellular internet of things (CIoT)	Revision of S1-152190	Revised to S1-152718
080186drr	8.1	S1-152718	Huawei, China Mobile, China Telecom, CATR, CATT	Massive connections for constrained cellular internet of things (CIoT)	Revision of S1-152475	Agreed.
080186e	8.1	S1-152230	KPN	SMARTER Use Case on Mass M2M and device identification	Merged in S1-152439.
080186f	8.1	S1-152144	Alcatel-Lucent	FS_SMARTER: Use case update for wide area sensor monitoring	Revised to S1-152475
080186g	8.1	S1-152145	Alcatel-Lucent	FS_SMARTER: Use case for variable data sensor	Merged with S1-152148 to S1-152305	Revised to S1-152305
080186gr	8.1	S1-152305	Alcatel-Lucent	FS_SMARTER: Use case for variable data sensor	Revision of S1-152145	Revised to S1-152471
080186grr	8.1	S1-152471	Alcatel-Lucent	FS_SMARTER: Use case for variable data sensor	Revised to S1-152476
080186grrr	8.1	S1-152476	Alcatel-Lucent	FS_SMARTER: Use case for variable data sensor	Revision of S1-152471	Agreed.
080186h	8.1	S1-152148	INTERDIGITAL COMMUNICATIONS	FS_SMARTER: Use case for devices with highly variable traffic	Merged with 2145 in S1-152305.
080186i	8.1	S1-152250	Huawei	Clarify latency requirement for sensors over different access types	Revised to S1-152477
080186ir	8.1	S1-152477	Huawei	Clarify latency requirement for sensors over different access types	Revision of S1-152250	For Alcatel-Lucent, this is still outside the scope of 3GPP.	Revised to S1-152719
080186irr	8.1	S1-152719	Huawei	Clarify latency requirement for sensors over different access types	Revision of S1-152477	Agreed.
080186j	8.1	S1-152130	Telefonica Europe plc	SMARTER Use Case on Domestic Home Monitoring	Revised to S1-152478
080186jr	8.1	S1-152478	Telefonica Europe plc	SMARTER Use Case on Domestic Home Monitoring	Revision of S1-152130	The requirements have been rewritten. The source has been changed to show only 3GPP Members.	Agreed.
080186k	8.1	S1-152132	Telefonica Europe plc	SMARTER Use Case on IoT Emergency Reporting	Revised to S1-152476
080186k	8.1	S1-152142	Alcatel-Lucent	FS_SMARTER: Use case for low mobility devices	Revised to S1-152479
080186kr	8.1	S1-152479	Alcatel-Lucent	FS_SMARTER: Use case for low mobility devices	Revision of S1-152142	Revised to S1-152686
080186krr	8.1	S1-152686	Alcatel-Lucent	FS_SMARTER: Use case for low mobility devices	Revision of S1-152479	Revised to S1-152720
080186krrr	8.1	S1-152720	Alcatel-Lucent	FS_SMARTER: Use case for low mobility devices	Revision of S1-152686	Agreed.
080186l	8.1	S1-152143	Alcatel-Lucent	FS_SMARTER: Use case for materials and inventory management and location tracking	Merged with S1-152193 in S1-152453	Revised to S1-152453
080186lr	8.1	S1-152453	Alcatel-Lucent, Huawei	FS_SMARTER: Use case for materials and inventory management and location tracking	Merging of S1-152143 and S1-152193.	Revised to S1-152481
080186lrr	8.1	S1-152481	Alcatel-Lucent, Huawei	FS_SMARTER: Use case for materials and inventory management and location tracking	Revision of S1-152453	Revised to S1-152721
080186lrrr	8.1	S1-152721	Alcatel-Lucent, Huawei	FS_SMARTER: Use case for materials and inventory management and location tracking	Revision of S1-152481	Agreed.
080186m	8.1	S1-152193	Huawei	Use case for shipment tracking	Merged with S1-152143 in S1-152453
080186n	8.1	S1-152196	China Mobile	use case for Cloud Robotics	Agreed.
080186o	8.1	S1-152281	Qualcomm Incorporated	SMARTER: Use case on Industrial Factory Automation	Abstract: Use case on Industrial Factory Automation	Revised to S1-152480
080186or	8.1	S1-152480	Qualcomm Incorporated	SMARTER: Use case on Industrial Factory Automation	Revision of S1-152281	Agreed.
080186p	8.1	S1-152282	Qualcomm Incorporated	SMARTER: Use case on Industrial Process Automation	Abstract: Use case on Industrial Process Automation	Revised to S1-152482
080186pr	8.1	S1-152482	Qualcomm Incorporated	SMARTER: Use case on Industrial Process Automation	Revision of S1-152282	Agreed.
080191a	8.1	S1-152101	Huawei, Deutsche Telekom	Update requirement of Ultra Reliable Communication use case	22.891	Agreed.
080191b	8.1	S1-152120	ORANGE	Provision of essential services for very low-ARPU areas	Revised to S1-152448
080191b	8.1	S1-152204	China Mobile	Updated SMARTER use case for on demand networking	Revised to S1-152483
080191br	8.1	S1-152448	ORANGE	Provision of essential services for very low-ARPU areas	Revision of S1-152120	Agreed.
080191br	8.1	S1-152483	China Mobile	Updated SMARTER use case for on demand networking	Revision of S1-152204	Agreed.
080191c	8.1	S1-152133	Telefonica Europe plc	SMARTER Use Case on Meta-Data Network Context Enablement	Withdrawn.
080191d	8.1	S1-152186	LG Electronics	Context Awared Networking	This paper discuss smart networking by extensive use of context information	Not handled.
080191e	8.1	S1-152203	China Mobile	SMARTER use case for network capability exposure	Revised to S1-152440
080191er	8.1	S1-152440	China Mobile	SMARTER use case for network capability exposure	Revision of S1-152203	Agreed.
080191f	8.1	S1-152213	Nokia Networks	Proposed new FS_SMARTER use case on Low-delay speech coding	Revised to S1-152485
080191f	8.1	S1-152232	China Unicom	Use case on user friendly network service provision	Merged with S1-152203 in S1-152440.	Revised to S1-152440.
080191fr	8.1	S1-152485	Nokia Networks	Proposed new FS_SMARTER use case on Low-delay speech coding	Revision of S1-152213	Agreed.
080191g	8.1	S1-152233	China Unicom	Use case on network enhancements to support scalability and automation	Revised to S1-152486
080191gr	8.1	S1-152486	China Unicom	Use case on network enhancements to support scalability and automation	Revision of S1-152233	Agreed.
080191h	8.1	S1-152242	ITRI	Network sharing for multi-tenant scenario	Revised to S1-152306
080191hr	8.1	S1-152306	ITRI	Network sharing for multi-tenant scenario	Revision of S1-152242	Noted.
080191i	8.1	S1-152277	Qualcomm Incorporated	SMARTER: Use Case for Wireless Self-Backhauling	This paper proposes a use case for wireless self-backhauling.	Revised to S1-152487
080191ir	8.1	S1-152487	Qualcomm Incorporated	SMARTER: Use Case for Wireless Self-Backhauling	Revision of S1-152277	Agreed.
080191j	8.1	S1-152135	Telefonica Europe plc	SMARTER Use Case on Vehicular Internet and Infotainment	Revised to S1-152488
080191j	8.1	S1-152195	China Mobile	additional requirement of Connectivity for drones use case	Agreed.
080191jr	8.1	S1-152488	Telefonica Europe plc	SMARTER Use Case on Vehicular Internet and Infotainment	Revision of S1-152135	Agreed.
080191k	8.1	S1-152283	Qualcomm Incorporated	SMARTER: Modifications to use case for Connectivity for Drones	Abstract: Modifications to the use case for Connectivity for Drones	Revised to S1-152489
080191kr	8.1	S1-152489	Qualcomm Incorporated	SMARTER: Modifications to use case for Connectivity for Drones	Revision of S1-152283	Revised to S1-152722
080191krr	8.1	S1-152722	Qualcomm Incorporated	SMARTER: Modifications to use case for Connectivity for Drones	Revision of S1-152489	Agreed.
080191l	8.1	S1-152278	Qualcomm Incorporated	SMARTER: Use case for Local UAV Collaboration	Abstract: Use case for Local UAV Collaboration	Revised to S1-152491
080191l	8.1	S1-152284	Qualcomm Incorporated	SMARTER: Modifications to use case for UAV Remote Control	Abstract: Modifications to use case for UAV Remote Control	Revised to S1-152490
080191lr	8.1	S1-152490	Qualcomm Incorporated	SMARTER: Modifications to use case for UAV Remote Control	Revision of S1-152284	Revised to S1-152723
080191lr	8.1	S1-152491	Qualcomm Incorporated	SMARTER: Use case for Local UAV Collaboration	Revision of S1-152278	Agreed.
080191lrr	8.1	S1-152723	Qualcomm Incorporated	SMARTER: Modifications to use case for UAV Remote Control	Revision of S1-152490	Agreed.
080196a	8.1	S1-152056	SoftBank Corp.	Support for RAN Sharing	Agreed.
080196b	8.1	S1-152216	Nokia Networks	Clarifications to coexistence with legacy systems	Agreed.
080196c	8.1	S1-152215	Nokia Networks	Proposed correction on seamless handover vs. service continuity	Withdrawn.
080197a	8.1	S1-152119	Sony Europe Limited	SMARTER Use Case on 4K/8K Video Streaming	Revised to S1-152421
080197b	8.1	S1-152067	ZTE Corporation	Proposal for enhanced mobile broadband for high accuracy positioning use case	This contribution presents a high accuracy positioning use case for enhanced mobile broadband scenario	Merged with S1-152304 into S1-152383
080197c	8.1	S1-152383	ZTE Corporation, ETRI	Enhanced mobile broadband for high accuracy positioning use case	Merging of S1-152067 and S1-152304	Revised to S1-152494
080197cr	8.1	S1-152494	ZTE Corporation, ETRI	Enhanced mobile broadband for high accuracy positioning use case	Revision of S1-152383	Revised to S1-152724
080197crr	8.1	S1-152724	ZTE Corporation, ETRI	Enhanced mobile broadband for high accuracy positioning use case	Revision of S1-152494	Agreed.
080197d	8.1	S1-152212	Nokia Networks	Proposed new FS_SMARTER use case on Fast positioning	Merged into S1-152494.
080197e	8.1	S1-152304	ETRI	Use Case of Enhanced Positioning Service	Merged with S1-152067 into S1-152383
080197f	8.1	S1-152128	Telefonica Europe plc	SMARTER Use Case on Broadcasting Support	Revised to S1-152495
080197fr	8.1	S1-152495	Telefonica Europe plc	SMARTER Use Case on Broadcasting Support	Revision of S1-152128	"mobile" to be replaced by "UE" in all this series. "Potential Requirements" to be replaced by "Service Requirements".	Revised to S1-152725
080197frr	8.1	S1-152725	Telefonica Europe plc	SMARTER Use Case on Broadcasting Support	Revision of S1-152495	Agreed.
080197g	8.1	S1-152127	Telefonica Europe plc	SMARTER Use Case on Ad-Hoc Broadcasting	Revised to S1-152496
080197gr	8.1	S1-152496	Telefonica Europe plc	SMARTER Use Case on Ad-Hoc Broadcasting	Revision of S1-152127	Same comments.	Revised to S1-152726
080197grr	8.1	S1-152726	Telefonica Europe plc	SMARTER Use Case on Ad-Hoc Broadcasting	Revision of S1-152496	Agreed.
080197h	8.1	S1-152189	KT Corp.	SMARTER Use Case: Green Radio	Revised to S1-152497
080197hr	8.1	S1-152497	KT Corp.	SMARTER Use Case: Green Radio	Revision of S1-152189	Revised to S1-152727
080197hrr	8.1	S1-152727	KT Corp.	SMARTER Use Case: Green Radio	Revision of S1-152497	Agreed.
080197i	8.1	S1-152052	Deutsche Telekom	Connectivity Transparency Use Case	22.891	Withdrawn
080197j	8.1	S1-152247	Huawei	Seamless multi-operator mobility	Withdrawn
080197k	8.1	S1-152248	Huawei	New Emerging Services and Service Variety	Withdrawn
080197l	8.1	S1-152249	Huawei	Managing network resources according to diverse user preferences	Withdrawn
080198	8.1	S1-152211	Nokia Networks	Proposed new FS_SMARTER use case on SMS and MMS Interworking	Revised to S1-152493
080198	8.1	S1-152336	Rapporteur	TR22.891 v0.2.0 to include agreements at this meeting	This will be provided by e-mail.	Agreed to be sent for information to SA.
080198,2	8.1	S1-152737	Rapporteur	Cover Page for TR22.891 on SMARTER	Agreed.
080198r	8.1	S1-152493	Nokia Networks	Proposed new FS_SMARTER use case on SMS and MMS Interworking	Revision of S1-152211	Withdrawn
080200	8.2	Zag_item	Zag_item	8.2 FS_MCVideo: Mission Critical Video Over LTE [SP-150048]	Zag_item
080251	8.2	S1-152500	Rapporteur/Session chair	FS_MCVideo drafting agenda	Noted.
080251	8.2	S1-152501	Rapporteur/Session chair	FS_MCVideo drafting report	Agreed.
080252	8.2	S1-152018	Ministry of Interior, France	Introduction and scope for MCVideo	Revised to S1-152503
080252	8.2	S1-152053	U.S. Department of Commerce	MCVideo Group Communication after Emergency Alert Use Case 5.2	This contribution proposes modifications to MCVideo Group Communication after Emergency Alert use case 5.2 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Revised to S1-152514
080252r	8.2	S1-152503	Ministry of Interior, France	Introduction and scope for MCVideo	Revision of S1-152018	Agreed.
080252r	8.2	S1-152514	U.S. Department of Commerce	MCVideo Group Communication after Emergency Alert Use Case 5.2	Revision of S1-152053	Agreed.
080253	8.2	S1-152047	U.S. Department of Commerce	Definitions for FS_MCVideo: Study on Mission Critical Video over LTE	This contribution proposes to add definitions into clause 3.1 of the draft TR 22.879 FS_MCVideo: Feasibility Study on Mission Critical Video over LTE for Release 14.	Not handled.
080253	8.2	S1-152054	U.S. Department of Commerce	MCVideo Car Bombing Incident Use Case 5.3	This contribution proposes modifications to MCVideo Car Bombing Incident use case 5.3 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Revised to S1-152515
080253r	8.2	S1-152515	U.S. Department of Commerce	MCVideo Car Bombing Incident Use Case 5.3	Revision of S1-152054	Agreed.
080254	8.2	S1-152055	U.S. Department of Commerce	MCVideo Remote Monitoring of a Road Traffic Stop Use Case 5.4	This contribution proposes modifications to MCVideo Remote Monitoring of a Road Tradffic Stop use case 5.4 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Revised to S1-152516
080254	8.2	S1-152059	U.S. Department of Commerce	MCVideo Pursuit Scenario Use Case 5.5	This contribution proposes modifications to MCVideo Pursuit Scenario use case 5.5 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Agreed.
080254r	8.2	S1-152516	U.S. Department of Commerce	MCVideo Remote Monitoring of a Road Traffic Stop Use Case 5.4	Revision of S1-152055	Agreed.
080255	8.2	S1-152060	U.S. Department of Commerce	MCVideo Hostage Incident Use Case 5.6	This contribution proposes modifications to MCVideo Hostage Incident use case 5.6 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Agreed.
080256	8.2	S1-152061	U.S. Department of Commerce	MCVideo Train Crash and Fire Use Case 5.7	This contribution proposes modifications to MCVideo Train Crash and Fire use case 5.7 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Revised to S1-152517
080256r	8.2	S1-152517	U.S. Department of Commerce	MCVideo Train Crash and Fire Use Case 5.7	Revision of S1-152061	Agreed.
080257	8.2	S1-152062	U.S. Department of Commerce	MCVideo Real Time Video Use Case 5.8	This contribution proposes modifications to MCVideo Real Time Video use case 5.8 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Agreed.
080258	8.2	S1-152063	U.S. Department of Commerce	Real Time Video with Late Entry Use Case 5.9	This contribution proposes modifications to Real Time Video with Late Entry use case 5.9 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Agreed.
080258	8.2	S1-152064	U.S. Department of Commerce	MCVideo Investigation of Police Officers Use Case 5.10	This contribution proposes modifications to MCVideo Investigation of Police Officers use case 5.10 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Agreed.
080259	8.2	S1-152066	U.S. Department of Commerce	Off-Network MCVideo Chemical Spill and Fire Use Case 6.1	This contribution proposes modifications to Off-Network MCVideo Chemical Spill and Fire use case 6.1 and associated requirements for clarification in the FS_MCVideo draft TR 22.879 for Release 14.	Agreed.
080260	8.2	S1-152013	Ministry of Interior, France	Automatic remote video management	Revised to S1-152504
080260r	8.2	S1-152504	Ministry of Interior, France	Automatic remote video management	Revision of S1-152013	Agreed.
080261	8.2	S1-152029	Ministry of Interior, France	Video transmission from a robot	Revised to S1-152505
080261r	8.2	S1-152505	Ministry of Interior, France	Video transmission from a robot	Revision of S1-152029	The rapporteur will put all values in the TR between square brackets, implying that they need further checking.	Revised to S1-152519
080261rr	8.2	S1-152519	Ministry of Interior, France	Video transmission from a robot	Revision of S1-152505	Agreed.
080264	8.2	S1-152045	U.S. Department of Commerce	MCVideo User Selection Capabilities Use Case	This contribution proposes to add an MCVideo User Selection Capabilities use case and associated requirements in the FS_MCVideo draft TR 22.879 for Release 14.	Revised to S1-152506
080264r	8.2	S1-152506	U.S. Department of Commerce	MCVideo User Selection Capabilities Use Case	Revision of S1-152045	Agreed.
080265	8.2	S1-152231	KPN	Use case on Mission Critical Video	Revised to S1-152507
080265r	8.2	S1-152507	KPN	Use case on Mission Critical Video	Revision of S1-152231	Agreed.
080266	8.2	S1-152270	Motorola Solutions	MCVideo Camera Discovery Use Case	This contribution proposes to add an MCVideo Camera Discovery use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Revised to S1-152508
080266r	8.2	S1-152508	Motorola Solutions	MCVideo Camera Discovery Use Case	Revision of S1-152270	Agreed.
080268	8.2	S1-152007	U.S. Department of Commerce	MCVideo User Profile Use Case	This contribution proposes to add an MCVideo User Proflie use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.
080269	8.2	S1-152038	U.S. Department of Commerce	Off-Network MCVideo User Profile Use Case	This contribution proposes to add an Off-Network MCVideo User Proflie use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080270	8.2	S1-152010	U.S. Department of Commerce	MCVideo Plane Crash and Fire Use Case	This contribution proposes to add an MCVideo Plane Crash and Fire use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080271	8.2	S1-152039	U.S. Department of Commerce	MCVideo Use of Multiple UEs Use Case	This contribution proposes to add an MCVideo Use of Multiple UEs use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080272	8.2	S1-152011	U.S. Department of Commerce	MCVideo Group Transmit Request and Grant Use Case	This contribution proposes to add an MCVideo Group Transmit Request and Grant use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080273	8.2	S1-152012	U.S. Department of Commerce	MCVideo Group Transmit Termination Use Case	This contribution proposes to add an MCVideo Group Transmit Termination use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080274	8.2	S1-152035	U.S. Department of Commerce	MCVideo Group Transmit Request Queued Use Case	This contribution proposes to add an MCVideo Group Transmit Request Queued use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080275	8.2	S1-152036	U.S. Department of Commerce	Off-Network MCVideo Group Transmit Request and Grant Use Case	This contribution proposes to add an Off-Network MCVideo Group Tranmsit Request and Grant use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080276	8.2	S1-152037	U.S. Department of Commerce	Off-Network MCVideo Group Transmit Termination Use Case	This contribution proposes to add an Off-Network MCVideo Group Transmit Termination use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080277	8.2	S1-152040	U.S. Department of Commerce	Off-Network MCVideo Emergency Alert Use Case	This contribution proposes to add an Off-Network MCVideo Emergency Alert use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080278	8.2	S1-152041	U.S. Department of Commerce	Off-Network MCVideo Emergency Group Communication Use Case	This contribution proposes to add an Off-Network MCVideo Emergency Group Communication use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080279	8.2	S1-152042	U.S. Department of Commerce	MCVideo Priority and Pre-emption Use Case	This contribution proposes to add an MCVideo Priority and Pre-emption use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080280	8.2	S1-152043	U.S. Department of Commerce	Off-Network MCVideo Priority and Pre-emption Use Case	This contribution proposes to add an Off-Network MCVideo Priority and Pre-emption use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080281	8.2	S1-152044	U.S. Department of Commerce	MCVideo Override Use Case	This contribution proposes to add an MCVideo Override use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Not handled.
080282	8.2	S1-152057	Harris Corporation	Video UE-to-Network Relay Use Case	This use case illustrates a situation where video from an off-network device is relayed to an on-network device and subsequentially pushed to another on-network device. This contribution is a resubmittal of S1-151086.	Agreed.
080283	8.2	S1-152058	Harris Corporation	MCVideo UE-to-Network Relay to UE-to-UE Relay Service Continuity Use Case	This use case illustrates a situation where an on-network device that is receiving video from an off-network user via a UE-to-Network relay transitions to a UE-to-UE relay and maintains video communications with the off-network user. This contribution is a resubmittal of S1-151086.	Revised to S1-152509
080283	8.2	S1-152243	NEC	Real time Video forwarding via D2D Relaying	Revised to S1-152510
080283r	8.2	S1-152509	Harris Corporation	MCVideo UE-to-Network Relay to UE-to-UE Relay Service Continuity Use Case	Revision of S1-152058	Agreed.
080283r	8.2	S1-152510	NEC	Real time Video forwarding via D2D Relaying	Revision of S1-152243	Agreed.
080284	8.2	S1-152244	NEC	Real time Video forwarding via direct D2D connection	Revised to S1-152511
080284r	8.2	S1-152511	NEC	Real time Video forwarding via direct D2D connection	Revision of S1-152244	Edited while projecting.	Revised to S1-152520
080284rr	8.2	S1-152520	NEC	Real time Video forwarding via direct D2D connection	Revision of S1-152511	Agreed.
080285	8.2	S1-152267	Harris	MCVideo UE-to-UE Relay to ProSe Communications Service Continuity Use Case	This use case illustrates a situation where an off-network device that is receiving video from an off-network user via a UE-to-UE relay transitions to ProSe Communications and maintains video communications with the off-network user. This contribution is a resubmit of S1-151086.	Revised to S1-152512
080285r	8.2	S1-152512	Harris	MCVideo UE-to-UE Relay to ProSe Communications Service Continuity Use Case	Revision of S1-152267	Agreed.
080286	8.2	S1-152268	Harris	MCVideo Network to ProSe Communications Service Continuity Use Case	This use case illustrates a situation where a device on the network that is receiving video from an off-network user via a UE-to-Network relay transitions to ProSe Communications and maintains video communications with the off-network user. This contribution is a resubmit of S1-151086.	Revised to S1-152513
080286r	8.2	S1-152513	Harris	MCVideo Network to ProSe Communications Service Continuity Use Case	Revision of S1-152268	Agreed.
080287	8.2	S1-152008	U.S. Department of Commerce	MCVideo Car Crash Use Case	This contribution proposes to add an MCVideo Car Crash use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.	Revised to S1-152518
080287r	8.2	S1-152518	U.S. Department of Commerce	MCVideo Car Crash Use Case	Revision of S1-152008	Agreed.
080288	8.2	S1-152051	U.S. Department of Commerce	MCVideo Discussion Paper on VQiPS Generalized Use Classes	This contribution provides a discussion paper on the Generalized Use Classes (GUC’s) developed by the Video Quality in Public Safety (VQiPS) working group to classify public safety video content..	Noted.
080289	8.2	S1-152273	Qualcomm Incorporated	MC Group Video Share Use Case	Describes a new use case for mission critical communications using video and multiple audio streams.	Not handled.
080299	8.2	S1-152502	Reserved MC_Video	Not used.
080299	8.2	S1-152521	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152522	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152523	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152524	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152525	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152526	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152527	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152528	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152529	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152530	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152531	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152532	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152533	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152534	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152535	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152536	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152537	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152538	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152539	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152540	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152541	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152542	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152543	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152544	Not used	Reserved MC_Video	Not used
080299	8.2	S1-152545	Not used	Reserved MC_Video	Not used
080300	8.3	Zag_item	Zag_item	8.3 FS_MCDATA: Mission Critical Data Communications [SP-150049]	Zag_item
080301	8.3.1	Zag_item	Zag_item	8.3.1 Joint FS_MCVoice + FS_MCData contributions	Zag_item
080302	8.3.2	Zag_item	Zag_item	8.3.2 FS_MCVideo + FS_MCData drafting session information	Zag_item
080351	8.3	S1-152338	Rapporteur / Session Chair	FS_MCVideo + FS_MCData drafting report	Agreed.
080352	8.3	S1-152337	Rapporteur / Session Chair	FS_MCVideo + FS_MCData drafting agenda	Noted.
080353	8.3	S1-152017	Ministry of Interior, France	Introduction and scope for MCDATA	Revised to S1-152546
080353r	8.3	S1-152546	Ministry of Interior, France	Introduction and scope for MCDATA	Revision of S1-152017	Agreed.
080354	8.3	S1-152070	KPN	Use case for situational awareness	22.880	080355r	8.3	Revised to S1-152547
080354r	8.3	S1-152547	KPN	Use case for situational awareness	22.880	Revision of S1-152070	Agreed.
080355	8.3	S1-152027	Ministry of Interior, France	Sending a multimedia message to agroup	Revised to S1-152547
080356	8.3	S1-152028	Ministry of Interior, France	Sending a multimedia message to another user	Revised to S1-152548
080356r	8.3	S1-152548	Ministry of Interior, France	Sending a multimedia message to another user	Revision of S1-152028	Agreed.
080357	8.3	S1-152021	Ministry of Interior, France	Managing data group communications	Revised to S1-152549
080357r	8.3	S1-152549	Ministry of Interior, France	Managing data group communications	Revision of S1-152021	Revised to S1-152676
080357rr	8.3	S1-152676	Ministry of Interior, France	Managing data group communications	Revision of S1-152549	Agreed.
080358	8.3	S1-152022	Ministry of Interior, France	Managing one to one data communications	Revised to S1-152550
080358r	8.3	S1-152550	Ministry of Interior, France	Managing one to one data communications	Revision of S1-152022	Agreed.
080359	8.3	S1-152023	Ministry of Interior, France	Message acknowledgement for group communications	Revised to S1-152551
080359r	8.3	S1-152551	Ministry of Interior, France	Message acknowledgement for group communications	Revision of S1-152023	Agreed.
080360	8.3	S1-152024	Ministry of Interior, France	Message acknowledgement for one to one communications	Revised to S1-152552
080360r	8.3	S1-152552	Ministry of Interior, France	Message acknowledgement for one to one communications	Revision of S1-152024	Agreed.
080361	8.3	S1-152071	TNO	Use case on remote control	22.880	Revision of S1-152027	This an use case for mission critical data on remote control. This document is an update of S1-151214 which was not handled in the Los Cabos #70 meeting,	Revised to S1-152555
080361r	8.3	S1-152555	TNO	Use case on remote control	22.880	Revision of S1-152027	Revision of S1-152071	Agreed.
080363	8.3	S1-152072	TNO	Use case on command/control centre	22.880	This an use case for mission critical data on command/control centre. This document is a revision of S1-151216 which was not handled in the Los Cabos SA#70 meeting.	Revised to S1-152556
080363r	8.3	S1-152556	TNO	Use case on command/control centre	22.880	Revision of S1-152072	Agreed.
080364	8.3	S1-152025	Ministry of Interior, France	Robot remote control	Revised to S1-152557
080364r	8.3	S1-152557	Ministry of Interior, France	Robot remote control	Revision of S1-152025	Agreed.
080365	8.3	S1-152026	Ministry of Interior, France	Robots identifications	Revised to S1-152558
080365r	8.3	S1-152558	Ministry of Interior, France	Robots identifications	Revision of S1-152026	Agreed.
080366	8.3	S1-152014	Ministry of Interior, France	Database enquiries and internet searches	Revised to S1-152559
080366r	8.3	S1-152559	Ministry of Interior, France	Database enquiries and internet searches	Revision of S1-152014	Agreed.
080367	8.3	S1-152015	Ministry of Interior, France	Event manager synchronization	Revised to S1-152560
080367r	8.3	S1-152560	Ministry of Interior, France	Event manager synchronization	Revision of S1-152015	Agreed.
080368	8.3	S1-152033	MINISTERE DE L'INTERIEUR	MCDATA rejected and queued calls	Revised to S1-152561
080368r	8.3	S1-152561	MINISTERE DE L'INTERIEUR	MCDATA rejected and queued calls	Revision of S1-152033	Agreed.
080369	8.3	S1-152197	China Mobile	use case for first aid	Revised to S1-152553
080369r	8.3	S1-152553	China Mobile	use case for first aid	Revision of S1-152197	Agreed.
080370	8.3	S1-152198	China Mobile	use case for location sharing	Revised to S1-152554
080370r	8.3	S1-152554	China Mobile	use case for location sharing	Revision of S1-152198	Agreed.
080371	8.2	S1-152016	Ministry of Interior, France	Interactions and priority management	Revised to S1-152564
080371	8.3	S1-152034	MINISTERE DE L'INTERIEUR	Priority allocation	Revised to S1-152565
080371r	8.2	S1-152564	Ministry of Interior, France	Interactions and priority management	Revision of S1-152016	Agreed.
080371r	8.3	S1-152565	MINISTERE DE L'INTERIEUR	Priority allocation	Revision of S1-152034	Agreed.
080373	8.2	S1-152030	Ministry of Interior, France	Seamless mobility and load balancing needs	Revised to S1-152568
080373r	8.2	S1-152568	Ministry of Interior, France	Seamless mobility and load balancing needs	Revision of S1-152030	The figure is not editable.	Revised to S1-152571
080373rr	8.2	S1-152571	Ministry of Interior, France	Seamless mobility and load balancing needs	Revision of S1-152568	Agreed.
080374	8.2	S1-152031	Ministry of Interior, France	Mobility use case	Revised to S1-152566
080374r	8.2	S1-152566	Ministry of Interior, France	Mobility use case	Revision of S1-152031	Agreed.
080375	8.3	S1-152032	Ministry of Interior, France	Mobility use case	Revised to S1-152567
080375r	8.3	S1-152567	Ministry of Interior, France	Mobility use case	Revision of S1-152032	Agreed.
080376	8.2	S1-152020	Ministry of Interior, France	IOPS use case	Agreed.
080377	8.3	S1-152019	Ministry of Interior, France	IOPS use case	Revised to S1-152570
080377r	8.3	S1-152570	Ministry of Interior, France	IOPS use case	Revision of S1-152019	Agreed.
080378	8.2	S1-152159	Huawei, TD-Tech	MCVideo Emergency Alert	Revised to S1-152562
080378r	8.2	S1-152562	Huawei, TD-Tech	MCVideo Emergency Alert	Revision of S1-152159	Agreed.
080379	8.3	S1-152161	Huawei, TD-Tech	MCData Emergency Alert	Revised to S1-152563
080379r	8.3	S1-152563	Huawei, TD-Tech	MCData Emergency Alert	Revision of S1-152161	Agreed.
080380	8.2	S1-152158	Huawei, TD-Tech	MCVideo Emergency Group Call	Agreed.
080381	8.3	S1-152160	Huawei, TD-Tech	MCData Emergency Group Call	Revised to S1-152569
080381r	8.3	S1-152569	Huawei, TD-Tech	MCData Emergency Group Call	Revision of S1-152160	Agreed.
080388	8.3	S1-152339	Rapporteur	TR22.879 (FS_MCVideo) v0.2.0 to include agreements at this meeting	TR	This version includes the material agreed at SA1#71.	Cover page in S1-152572.	Agreed to send for information to SA.
080388r	8.3	S1-152572	Rapporteur	Cover page for TR22.879 (FS_MCVideo) v0.2.0 to include agreements at this meeting	TR	TR in S1-152339	Agreed to be sent to SA.
080389	8.3	S1-152340	Rapporteur	TR22.880 (FS_MCData) v0.2.0 to include agreements at this meeting	TR	This version includes the material agreed at SA1#71.	Cover page in S1-152573	Agreed to be sent for information to SA.
080389r	8.3	S1-152573	Rapporteur	Cover page for TR22.880 (FS_MCData) v0.2.0 to include agreements at this meeting	TR	TR in S1-152340	Agreed to be sent to SA.
080399	8.3	S1-152574	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152575	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152576	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152577	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152578	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152579	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152580	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152581	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152582	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152583	Not used	Reserved MC_Data	Not used
080399	8.3	S1-152584	Not used	Reserved MC_Data	Not used
080400	8.4	Zag_item	Zag_item	8.4 FS_V2XLTE: LTE support for V2X services [SP-150051]	Zag_item
080401	8.4	S1-152178	LG Electronics	Consideration on V2X spectrum	This document is a resubmission of a document that was not handled in San José del Cabo (S1-151101) This paper discusses various option of spectrum allocation for V2X	This is a good analysis but might come too early, in Qualcomm's view. They indeed notice that the services are not clearly identified yet. See other contributions on the same topic.	S1-152178, S1-152170, S1-152376 and parts of S1-152124 are merged into S1-152465.
080401	8.4.1	Zag_item	Zag_item	8.4.1 FS_V2XLTE drafting session information	Zag_item
080402	8.4	S1-152170	Huawei	Clarification of V2X spectrum usage and its impacts with other services	This contribution proposes to clarify the spectrum usage of V2V service and the impacts of V2V to other services. The following is proposed: The 3GPP network should ensure there is no interference from other supported services in the same radio resources (e.g. dedicated spectrum for V2V). If V2V application co-exists in spectrum shared with other 3GPP-defined applications, V2V message transfer should be prioritized over other non-critical services in the resource allocation process. The V2V communication should support multi-carrier capability to guarantee inter-MNO connectivity, system extensibility and backward compatibility.	See also S1-152376 on this topic.	S1-152178, S1-152170, S1-152376 and parts of S1-152124 are merged into S1-152465.
080403	8.4	S1-152376	Qualcomm Incorporated, ZTE	Considerations on Spectrum	Revision of S1-152291	S1-152178, S1-152170, S1-152376 and parts of S1-152124 are merged into S1-152465.
080404	8.4	S1-152124	Nokia Networks	Considerations on Interoperability of V2X	This paper discusses interoperability aspects of V2X resulting from multioperator deployments and international roaming, spectrum issues and gives some requirements a 3GPP V2X solution should fulfil.	S1-152178, S1-152170, S1-152376 and parts of S1-152124 are merged into S1-152465.
080405	8.4	S1-152465	LG Electronics Inc.	Consideration on V2X Spectrum	Merging of S1-152178, S1-152170, S1-152376 and parts of S1-152124.	Revised to S1-152742
080405r	8.4	S1-152742	Rapporteur, LG Electronics Inc., Huawei, Qualcomm Incorporated, Nokia Networks	Considerations on V2X Spectrum Usage Scenarios	Revision of S1-152465	This was further edited while projecting.	Revised to S1-152744
080405rr	8.4	S1-152744	Rapporteur, LG Electronics Inc., Huawei, Qualcomm Incorporated, Nokia Networks	Considerations on V2X Spectrum Usage Scenarios	Revision of S1-152742	Agreed.
080407	8.4	S1-152377	Qualcomm Incorporated, ZTE	Considerations on Coverage	Revision of S1-152292. Resubmission of S1-151189 from SA1#70. This contribution proposes some considerations on coverage for V2X services	See also S1-152209 on the same topic.	Merged with S1-152377 in S1-152466.
080408	8.4	S1-152209	Huawei	Consideration on supporting V2X in coverage in priority	This contribution proposes to consider in-coverage as a baseline operating scenario due to world-spreading LTE coverage and it	Merged with S1-152377 in S1-152466.
080409	8.4	S1-152466	Qualcomm Incorporated, ZTE, Huawei	Considerations on Coverage	Merging of S1-152377 and S1-152209.	Agreed.
080451	8.4	S1-152342	Rapporteur / Session Chair	FS_V2XLTE drafting report	Agreed.
080452	S1-152341	Rapporteur / Session Chair	FS_V2XLTE drafting agenda	Noted.
080453	8.4	S1-152264	Rapporteur	V2X Potential Requirements section – consolidation	Revised to S1-152450
080455	8.4	S1-152450	Rapporteur	Consolidation plan for Potential Requirements section	Revision of S1-152264	Not handled.
080456	8.4	S1-152259	Rapporteur	V2X Introduction section	Revised to S1-152585
080456r	8.4	S1-152585	Rapporteur	V2X Introduction section	Revision of S1-152259	Agreed.
080457	8.4	S1-152261	Rapporteur	V2X Overview section – modification and addition of V2I and V2P	Revised to S1-152586
080457r	8.4	S1-152586	Rapporteur	V2X Overview section – modification and addition of V2I and V2P	Revision of S1-152261	Revised to S1-152609
080457rr	8.4	S1-152609	Rapporteur	V2X Overview section – modification and addition of V2I and V2P	Revision of S1-152586	Revised to S1-152743
080457rrr	8.4	S1-152743	Rapporteur	V2X Overview section – modification and addition of V2I and V2P	Revision of S1-152609	Revised to S1-152757
080457rrrr	8.4	S1-152757	Rapporteur	V2X Overview section – modification and addition of V2I and V2P	Revision of S1-152743	Agreed.
080458	8.4	S1-152262	Rapporteur	V2X Use Case section – editorial	Revised to S1-152587
080458r	8.4	S1-152587	Rapporteur	V2X Use Case section – editorial	Revision of S1-152262	Agreed.
080459	8.4	S1-152272	ETRI	Proposed editorial changes for TR 22.885	Revised to S1-152588
080459r	8.4	S1-152588	ETRI	Proposed editorial changes for TR 22.885	Revision of S1-152272	Agreed.
080460	8.4	S1-152260	Rapporteur	V2X Definition section with new or refined terminology	Revised to S1-152589
080460r	8.4	S1-152589	Rapporteur	V2X Definition section with new or refined terminology	Revision of S1-152260	Agreed.
080462	8.4	S1-152068	ZTE Corporation	RSU definition update	This contribution update the definition of RSU which can be in or out of coverage	Revised to S1-152392
080462r	8.4	S1-152392	ZTE Corporation	RSU definition update	Revision of S1-152068	Noted.
080463	8.4	S1-152069	ZTE Corporation	Definition of V2X capable UE	This contribution is to give the definition of V2X capable UE	Revised to S1-152393
080463r	8.4	S1-152393	ZTE Corporation	Definition of V2X capable UE	Revision of S1-152069	Noted.
080464	8.4	S1-152225	Vodafone	Discussion on latency requirements for V2X services	Noted.
080467	8.4	S1-152295	Qualcomm Incorporated	Deployment scenarios for V2X communication	Abstract: This paper presents different V2X deployment scenarios and analyzes the corresponding requirements. It is proposed to document the scenarios in the TR 22.885.	Revised to S1-152378
080467r	8.4	S1-152378	Qualcomm Incorporated	Deployment scenarios for V2X communication	Revision of S1-152295	Not handled.
080468	8.4	S1-152183	LG Electronics	V2X consideration on inter PLMNs countries	V2X uses cases for inter PLMN and inter country scenario	Not handled.
080469	8.4	S1-152171	Huawei	Clarification on MNO Authorization for V2X	Not handled.
080470	8.4	S1-152169	Huawei	Clarification on the difference of V2I and V2N	Revised to S1-152384
080470r	8.4	S1-152384	Huawei	Clarification on the difference of V2I and V2N	Revision of S1-152169	Revised to S1-152590
080470rr	8.4	S1-152590	Huawei	Clarification on the difference of V2I and V2N	Revision of S1-152384	Revised to S1-152613
080470rrr	8.4	S1-152613	Huawei	Clarification on the difference of V2I and V2N	Revision of S1-152590	Agreed.
080471	8.4	S1-152256	ETRI	Additional requirements for V2I unicast communication	Revised to S1-152592
080471r	8.4	S1-152592	ETRI	Additional requirements for V2I unicast communication	Revision of S1-152256	Agreed.
080473	8.4	S1-152255	ETRI	Pre-crash Sensing Warning updates for V2V unicast communication	Noted.
080474	8.4	S1-152265	LG Electronics Inc.	Addition of an OOC requirement to V2P warning to pedestrian Use Case	Noted.
080475	8.4	S1-152266	LG Electronics Inc.	Addition of an OOC requirement to V2P warning to vehicle Use Case	Noted.
080476	8.4	S1-152271	ETRI	Updates to curve speed warning	Revised to S1-152593
080476r	8.4	S1-152593	ETRI	Updates to curve speed warning	Revision of S1-152271	Revised to S1-152611
080476rr	8.4	S1-152611	ETRI	Updates to curve speed warning	Revision of S1-152593	Agreed
080478	8.4	S1-152182	LG Electronics	V2X by UE type RSU	This paper discusses what is expected from UE type RSU	Revised to S1-152594
080478r	8.4	S1-152594	LG Electronics	V2X by UE type RSU	Revision of S1-152182	Revised to S1-152612
080478rr	8.4	S1-152612	LG Electronics	V2X by UE type RSU	Revision of S1-152594	Agreed.
080480	8.4	S1-152167	Huawei	Vehicle density requirement for V2X service	Revised to S1-152595
080480r	8.4	S1-152595	Huawei	Vehicle density requirement for V2X service	Revision of S1-152167	Agreed.
080481	8.4	S1-152125	Nokia Networks	Considerations on Vehicle density for V2X	Revised to S1-152595
080481r	8.4	S1-152168	Huawei	Clarification on delay requirement of V2I RSU relay use case	Revision of S1-152125	Agreed.
080482	8.4	S1-152165	Huawei	Clarify typical V2V message sizes are between 50-110 bytes without security overhead	Revised to S1-152603
080482r	8.4	S1-152603	Huawei	Clarify typical V2V message sizes are between 50-110 bytes without security overhead	Revision of S1-152165	Revised to S1-152614
080482rr	8.4	S1-152614	Huawei, Qualcomm Incorporated	Clarify typical V2V message sizes are between 50-110 bytes without security overhead	Revision of S1-152603	Revised to S1-152710
080482rrr	8.4	S1-152710	Huawei, Qualcomm Inc.	Clarify typical V2V message sizes are between 50-110 bytes without security overhead	Revision of S1-152614	Agreed.
080483	8.4	S1-152166	Huawei	Complete [TBD] V2I values for curve speed warning	Revised to S1-152172
080483r	8.4	S1-152172	Huawei	Complete [TBD] V2I values for curve speed warning	Revision of S1-152166	Revised to S1-152605
080483rr	8.4	S1-152605	Huawei	Complete [TBD] V2I values for curve speed warning	Revision of S1-152172	Revised to S1-152615
080483rrr	8.4	S1-152615	Huawei	Complete [TBD] V2I values for curve speed warning	Revision of S1-152605	Agreed.
080484	8.4	S1-152217	GM Onstar Europe	V2X – 5.2 Control Loss Warning	Revised to S1-152388
080484r	8.4	S1-152388	GM Onstar Europe	V2X – 5.2 Control Loss Warning	Revision of S1-152217	Noted.
080485	8.4	S1-152218	GM Onstar Europe	V2X – 5.3. V2V Use case for emergency vehicle warning	Revised to S1-152389
080485r	8.4	S1-152389	GM Onstar Europe	V2X – 5.3. V2V Use case for emergency vehicle warning	Revision of S1-152218	Revised to S1-152606
080485rr	8.4	S1-152606	GM Onstar Europe	V2X – 5.3. V2V Use case for emergency vehicle warning	Revision of S1-152389	Agreed.
080486	8.4	S1-152219	GM Onstar Europe	V2X – 5.5 Cooperative Adaptive Cruise Control	Revised to S1-152390
080486r	8.4	S1-152390	GM Onstar Europe	V2X – 5.5 Cooperative Adaptive Cruise Control	Revision of S1-152219	Not handled.
080487	8.4	S1-152220	GM Onstar Europe	V2X – 5.15 V2I / V2N Traffic Flow Optimisation	Not handled.
080487	8.4	S1-152607	Qualcomm Incorporated, ZTE?, GM Onstar	Modifications to Annex A of TR 22.885	Revision of S1-152604	Revised to S1-152616
080487r	8.4	S1-152616	Qualcomm Incorporated, ZTE?, GM Onstar	Modifications to Annex A of TR 22.885	Revision of S1-152607	Agreed.
080488	8.4	S1-152221	GM Onstar Europe	V2X – 5.18 Vulnerable Road User (VRU) Safety	Revised to S1-152391
080488r	8.4	S1-152391	GM Onstar Europe	V2X – 5.18 Vulnerable Road User (VRU) Safety	Revision of S1-152221	Not handled.
080489	8.4	S1-152263	LG Electronics Inc.	V2X Use Case section –missing values	Not handled.
080490	8.4	S1-152122	CATT	Clarifying the definition of range and reliability in V2V requirements	Not handled.
080491	8.4	S1-152123	CATT	Adding a typical freeway velocity scenario in Table A.1	Revised to S1-152452
080491	8.4	S1-152610	Alcatel-Lucent	FS_V2XLTE: Roaming support	Revision of S1-152608	Agreed
080491r	8.4	S1-152452	CATT	Adding a typical freeway velocity scenario in Table A.1	Revision of S1-152123	Not handled.
080492	8.4	S1-152222	GM Onstar Europe	V2X – Appendix A	Revised to S1-152604
080492r	8.4	S1-152604	GM Onstar Europe	V2X – Appendix A	Revision of S1-152222	Was revised to S1-152608 but confusion with numbers.	Revised to S1-152607
080493	8.4	S1-152290	Qualcomm Incorporated	Modification of table in Annex A	Abstract: This contribution proposes modifications to Annex A of TR 22.885 to bring it in line with (a) agreement on reaching sufficient reliability by Time To Collision of 4 seconds, (b) seperation between single-shot radio reliability and cumulative application-layer reliability, (c) elaboration of various scenarios & parameters.	Revised to S1-152379
080493r	8.4	S1-152379	Qualcomm Incorporated	Modification of table in Annex A	Revision of S1-152290	Merged into S1-152604
080495a	8.4	S1-152180	LG Electronics	Security for V2X	This document list consideration point for security	Not handled.
080495b	8.4	S1-152293	Qualcomm Incorporated	Security framework for V2X communication	Abstract: This paper evaluates the suitability of LTE security and ProSe security for V2X use. It is further proposed that the security of the WAVE/DSRC be adopted for V2X	Revised to S1-152380
080495br	8.4	S1-152380	Qualcomm Incorporated	Security framework for V2X communication	Revision of S1-152293	Not handled.
080495c	8.4	S1-152294	Qualcomm Incorporated	New Use Case: Privacy use case for V2X communication	Abstract: This paper describes what privacy looks like in the V2X scenarios, and proposes to document it in the TR 22.885.	Revised to S1-152381
080495cr	8.4	S1-152381	Qualcomm Incorporated	New Use Case: Privacy use case for V2X communication	Revision of S1-152294	Not handled.
080496a	8.4	S1-152117	Sony Europe Limited	V2X Use Case on "V2P Enhanced Tethering"	Revised to S1-152596
080496ar	8.4	S1-152596	Sony Europe Limited	V2X Use Case on "V2P Enhanced Tethering"	Revision of S1-152117	Withdrawn.
080496b	8.4	S1-152079	Intel Corporation (UK) Ltd	Use Case for MNO Configuration of V2X Message Transmission Characteristics	This use case allows for the eNB-implemented RSU to change the V2X cooperative message transmission characteristics of UEs in order to improve radio resource utilization.	Noted.
080496c	8.4	S1-152110	TNO	Use case X1 VRU Road Safety via VRU to Vehicle communication	Revised to S1-152597
080496cr	8.4	S1-152597	TNO	Use case X1 VRU Road Safety via VRU to Vehicle communication	Revision of S1-152110	Problem uploading the doc.	Revised to S1-152690
080496crr	8.4	S1-152690	TNO, VTT	Use case X1 VRU Road Safety via VRU to Vehicle communication	Revision of S1-152597	Revised to S1-152695
080496crrr	8.4	S1-152695	TNO	Use case X1 VRU Road Safety via VRU to Vehicle communication	Revision of S1-152690	Agreed.
080496d	8.4	S1-152111	TNO	Use Case X2 VRU Road Safety with VRU to RSU communication	Not handled.
080496e	8.4	S1-152113	TNO	Use case X3 Informing VRUs on traffic light status	Not handled.
080496f	8.4	S1-152114	TNO	Use case X4 VRU Road Safety via VRU beacons	Not handled.
080496g	8.4	S1-152115	TNO	Use Case X5: Intersection Safety via Vehicle to Infrastructure communication (V2I)	Revised to S1-152598
080496gr	8.4	S1-152598	TNO, VTT	Use Case X5: Intersection Safety via Vehicle to Infrastructure communication (V2I)	Revision of S1-152115	Some changes were performed while projecting. Non-3GPP members should not be listed as source.	Revised to S1-152696
080496grr	8.4	S1-152696	TNO	Use Case X5: Intersection Safety via Vehicle to Infrastructure communication (V2I)	Revision of S1-152598	Revised to S1-152740
080496grrr	8.4	S1-152740	TNO	Use Case X5: Intersection Safety via Vehicle to Infrastructure communication (V2I)	Revision of S1-152696	Agreed.
080496h	8.4	S1-152116	TNO	Use Case X6 Road Hazard Warning on Human Presence on the Road	Not handled.
080496i	8.4	S1-152140	Alcatel-Lucent	FS_V2XLTE: Mixed Use Traffic Management	Revised to S1-152591
080496ir	8.4	S1-152591	Alcatel-Lucent	FS_V2XLTE: Mixed Use Traffic Management	Revision of S1-152140	"V2X" changed to "3GPP".	Revised to S1-152697
080496irr	8.4	S1-152697	Alcatel-Lucent	FS_V2XLTE: Mixed Use Traffic Management	Revision of S1-152591	Agreed.
080496j	8.4	S1-152126	Nokia Networks	Enhancing Positional Precision for traffic particpiants	Revised to S1-152599
080496jr	8.4	S1-152599	Nokia Networks	Enhancing Positional Precision for traffic participants	Revision of S1-152126. The derived potential requirements are:"A UE supporting V2X Services should derive its location with the highest available accuracy (i.e. using the most accurate tools available to the UE) The 3GPP Network should make available any supported positional accuracy improvement techniques in a resource efficient way to a subscribed UE supporting V2X Services"	Revisions are not shown on purpose because there were too many changes. For LG, this should belong to the application layer. For Qualcomm, this is more than just an application problem: e.g. OTDOA might have to be enabled when available. Some clarifications have to be introduced about 3GPP versus non-3GPP applications.	Revised to S1-152698
080496jrr	8.4	S1-152698	Nokia Networks	Enhancing Positional Precision for traffic participants	Revision of S1-152599	Revised to S1-152741
080496jrrr	8.4	S1-152741	Nokia Networks	Enhancing Positional Precision for traffic participants	Revision of S1-152698	Agreed.
080496k	8.4	S1-152179	LG Electronics	Mobility management for V2X	New uses case for V2X, discusses mobility support for vehicles	Revised to S1-152600
080496kr	8.4	S1-152600	LG Electronics	Mobility management for V2X	Revision of S1-152179. This new section is added: "6.x Consideration on mobility If all UEs supporting V2X are managed in connected mode, this will lead to huge burden in mobility management (e.g. amount of signaling, context relocation, etc.) If this is the case, it should be considered whether means to enhance mobility management is needed."	For future meetings, it would be nicer to keep the revision marks so delegates not attending the V2X session can see how the text was modified. For Ericsson, this section is just a statement not in SA1 field. For Huawei, this statement is not a requirement and is a bit awkward. For NEC, this is just stating to SA2 to do properly their job, so it might not be needed. No consensus.	Revised to S1-152699
080496krr	8.4	S1-152699	LG Electronics	Mobility management for V2X	Revision of S1-152600	Agreed.
080496l	8.4	S1-152181	LG Electronics	Use of V2X with other applications	This paper discusses how to support QoS for non-V2X	Noted.
080496m	8.4	S1-152184	LG Electronics	V2X Minimum QoS	This paper discusses principle on how to handle congestion and emergency vehicles	Revised to S1-152601
080496mr	8.4	S1-152601	LG Electronics	V2X Minimum QoS	Revision of S1-152184	"for special UEs" is too vague. This can be refined by a note. "specific types of UE" would be better.	Revised to S1-152700
080496mrr	8.4	S1-152700	LG Electronics	V2X Minimum QoS	Revision of S1-152601	Agreed.
080496n	8.4	S1-152188	KT Corp, LG Electronics Inc.	V2X Use Case: Public Transportation Control System	Revised to S1-152602
080496nr	8.4	S1-152602	KT Corp, LG Electronics Inc.	V2X Use Case: Public Transportation Control System	Revision of S1-152188	Revised to S1-152701
080496nrr	8.4	S1-152701	KT Corp, LG Electronics Inc.	V2X Use Case: Public Transportation Control System	Revision of S1-152602	Withdrawn.
080497	8.4	S1-152343	Rapporteur	TR22.885 v0.3.0 to include agreements at this meeting	TR	This version includes the material agreed at SA1#71.	CP in S1-152760	Agreed to be sent to SA for information.
080497r	8.4	S1-152760	Rapporteur	TR22.885 v0.3.0 to include agreements at this meeting	TR	Revision of S1-152343	For e-mail approval.
080500	8.5	Zag_item	Zag_item	8.5 FS_EnTV: 3GPP Enhancement for TV Video service [SP-150052]	Zag_item
080501	8.5.1	Zag_item	Zag_item	8.5.1 FS_EnTV drafting session information	Zag_item
080511r	8.5	S1-152687	Qualcomm Incorporated, Nokia Networks, Rodgers, Ericsson, one2many, Expway	FS_EnTV: eMBMS sharing	Revision of S1-152655	Agreed.
080512rrr	8.5	S1-152688	Qualcomm Incorporated	FS_EnTV: eMBMS Spectral efficiency	Revision of S1-152657	Some typos to be corrected.	Revised to S1-152702
080512rrrr	8.5	S1-152702	Qualcomm Incorporated	FS_EnTV: eMBMS Spectral efficiency	Revision of S1-152688	Agreed.
080551	8.5	S1-152345	Rapporteur / Session Chair	FS_EnTV drafting report	Agreed.
080552	S1-152344	Rapporteur / Session Chair	FS_EnTV drafting agenda	Noted.
080553	8.5	S1-152285	Qualcomm Incorporated	FS_EnTV: eMBMS sharing	Abstract: Resubmission of S1-151197 from SA1#70. This contribution proposes a use case for enabling the sharing of eMBMS	Revised to S1-152371
080553	8.5	S1-152287	Qualcomm Incorporated	FS_EnTV: eMBMS Spectral efficiency	Abstract: Resubmission of S1-151199 from SA1#70. This contribution proposes a use case for improving spectral efficiency of eMBMS	Revised to S1-152372
080553r	8.5	S1-152371	Qualcomm Incorporated	FS_EnTV: eMBMS sharing	Revision of S1-152285	Revised to S1-152655
080553r	8.5	S1-152372	Qualcomm Incorporated	FS_EnTV: eMBMS Spectral efficiency	Revision of S1-152287	Revised to S1-152657
080553rr	8.5	S1-152655	Qualcomm Incorporated	FS_EnTV: eMBMS sharing	Revision of S1-152371	Revised to S1-152687
080553rr	8.5	S1-152657	Qualcomm Incorporated	FS_EnTV: eMBMS Spectral efficiency	Revision of S1-152372	Revised to S1-152688
080555	8.5	S1-152046	Nokia Networks	Flexible capacity allocation	This paper proposes a use case to flexibly allocate resources dedicated to the LTE based TV service to either unicast or broadcast distribution of TV programs.	Revised to S1-152656
080556	8.5	S1-152085	EBU	Flexible capacity allocation for TV services	This paper proposes a use case to flexibly allocate resources for TV services on LTE networks either in unicast or broadcast mode.	Revised to S1-152656
080556r	8.5	S1-152656	EBU	Flexible capacity allocation for TV services	Revision of S1-152085	Revised to S1-152703
080556rr	8.5	S1-152703	EBU	Flexible capacity allocation for TV services	Revision of S1-152656	Agreed.
080557	8.5	S1-152089	EBU	Standalone eMBMS Network	This paper proposes a use case to accommodate the operation of a LTE network using a given spectrum range for eMBMS downlink only.	Revised to S1-152658
080557r	8.5	S1-152658	EBU	Standalone eMBMS Network	Revision of S1-152089	Revised to S1-152704
080557rr	8.5	S1-152704	EBU	Standalone eMBMS Network	Revision of S1-152658	Agreed.
080558	8.5	S1-152048	Nokia Networks	Access to and charging of TV programs and privacy of reception	This paper proposes a use case on Access to and Charging of TV programs and Privacy of Reception	Revised to S1-152659
080558r	8.5	S1-152659	Nokia Networks	Access to and charging of TV programs and privacy of reception	Revision of S1-152048	Agreed.
080561	8.5	S1-152286	Qualcomm Incorporated	FS_EnTV: eMBMS Coverage enhancement	Abstract: Resubmission of S1-151198 from SA1#70. This contribution proposes a use case for improving spectral efficiency of eMBMS	Revised to S1-152373
080561r	8.5	S1-152373	Qualcomm Incorporated	FS_EnTV: eMBMS Coverage enhancement	Revision of S1-152286	Revised to S1-152660
080561rr	8.5	S1-152660	Qualcomm Incorporated	FS_EnTV: eMBMS Coverage enhancement	Revision of S1-152373	Revised to S1-152692
080561rrr	8.5	S1-152692	Qualcomm Incorporated	FS_EnTV: eMBMS Coverage enhancement	Revision of S1-152660	Agreed.
080562	8.5	S1-152049	Nokia Networks	Wide area coverage and moving receivers	This paper proposes a use case to accommodate wide area coverage and (fast) moving receivers scenarios	Revised to S1-152307
080562	8.5	S1-152084	EBU	Coverage for TV services	This paper proposes a use case to accomodate coverage requirements for TV services.	Included in S1-152661.
080562r	8.5	S1-152307	Nokia Networks	Wide area coverage and moving receivers	Revision of S1-152049	Revised to S1-152661
080562rr	8.5	S1-152661	Nokia Networks	Wide area coverage and moving receivers	Revision of S1-152307	Agreed.
080563	8.5	S1-152086	EBU	Highly flexible network topology	This paper proposes a use case to accomodate wide area coverage by a highly flexible network topology consisting of HTHP and LTLP parts.	Included in S1-152661.
080564	8.5	S1-152164	Huawei	coverage on-demand support	Revised to S1-152662
080564r	8.5	S1-152662	Huawei	coverage on-demand support	Revision of S1-152164	Agreed.
080571	8.5	S1-152050	Nokia Networks	General LTE based TV service	This paper proposes a general use case to describe functionality not fitting to other more specialised use cases.	Revised to S1-152308
080571r	8.5	S1-152308	Nokia Networks	General LTE based TV service	Revision of S1-152050	Revised to S1-152663
080571rr	8.5	S1-152663	Nokia Networks	General LTE based TV service	Revision of S1-152308	Agreed.
080573	8.5	S1-152088	EBU	Receive-Only Mode for TV services	This paper proposes a use case that enables a receive-only mode for TV services.	Noted.
080574	8.5	S1-152094	EBU	TV Services on LTE Networks	This paper proposes a general TV service use case.	Noted.
080575	8.5	S1-152097	EBU	Types of TV programmes on LTE networks	This paper proposes a use case by specifying the types of TV programmes which can be part of TV services on LTE networks.	Noted.
080576	8.5	S1-152289	Qualcomm Incorporated, Nokia Networks	FS_EnTV: New Use Case: Service Layer Function and Codec Support	Abstract: This contribution proposes a use case for extending the MBMS service layer to cover service and regulatory support for codecs and functions relevant to TV services	Revised to S1-152374
080576r	8.5	S1-152374	Qualcomm Incorporated, Nokia Networks	FS_EnTV: New Use Case: Service Layer Function and Codec Support	Revision of S1-152289	Agreed.
080581	8.5	S1-152162	Huawei	openness for streaming content delivery	Agreed.
080582	8.5	S1-152163	Huawei	hybrid transport	Revised to S1-152664
080582r	8.5	S1-152664	Huawei	hybrid transport	Revision of S1-152163	Agreed.
080583	8.5	S1-152288	Qualcomm Incorporated	FS_EnTV: New Use Case: Decoupled eMBMS content, service, and transport	Abstract: This contribution proposes a use case for enabling the usage of the MBMS transport with service layer aspects being provided by the third paty.	Revised to S1-152375
080583r	8.5	S1-152375	Qualcomm Incorporated	FS_EnTV: New Use Case: Decoupled eMBMS content, service, and transport	Revision of S1-152288	Revised to S1-152665
080583rr	8.5	S1-152665	Qualcomm Incorporated	FS_EnTV: New Use Case: Decoupled eMBMS content, service, and transport	Revision of S1-152375	Revised to S1-152689
080583rrr	8.5	S1-152689	Qualcomm Incorporated	FS_EnTV: New Use Case: Decoupled eMBMS content, service, and transport	Revision of S1-152665	Revised to S1-152705
080583rrrr	8.5	S1-152705	Qualcomm Incorporated	FS_EnTV: New Use Case: Decoupled eMBMS content, service, and transport	Revision of S1-152689	Agreed.
080584	8.5	S1-152207	Ericsson, Qualcomm Incorporated	Simultaneous use of any LTE services from one cell and TV service from another non-colocated cell	Revised to S1-152675
080584r	8.5	S1-152675	Ericsson, Qualcomm Incorporated	Simultaneous use of any LTE services from one cell and TV service from another non-colocated cell	Revision of S1-152207	Revised to S1-152666
080584rr	8.5	S1-152666	Ericsson, Qualcomm Incorporated	Simultaneous use of any LTE services from one cell and TV service from another non-colocated cell	Revision of S1-152675	Agreed.
080585	8.5	S1-152208	Ericsson, Qualcomm Incorporated	Simultaneous use of any LTE services from one network and TV service from another network	Revised to S1-152667
080585r	8.5	S1-152667	Ericsson, Qualcomm Incorporated	Simultaneous use of any LTE services from one network and TV service from another network	Revision of S1-152208	Agreed
080597,2	8.5	S1-152346	Rapporteur	TR22.816 v0.2.0 on EnTV to include agreements at this meeting	TR	CP in S1-152736	Agreed to be sent to SA for information.
080597,2	8.5	S1-152736	Rapporteur	Cover Page for TR22.816	TR	TR in S1-152346	Agreed to be sent to SA for information.
080599	S1-152668	Not allocated	Reserved enTV	Not allocated
080599	S1-152669	Not allocated	Reserved enTV	Not allocated
080599	S1-152670	Not allocated	Reserved enTV	Not allocated
080599	S1-152671	Not allocated	Reserved enTV	Not allocated
080599	S1-152672	Not allocated	Reserved enTV	Not allocated
080599	S1-152673	Not allocated	Reserved enTV	Not allocated
080599	S1-152674	Not allocated	Reserved enTV	Not allocated
080600	8.6	Zag_item	Zag_item	8.6 FS_PPEPO_LTE: Paging Policy Enhancements and Procedure Optimizations in LTE [SP-150053]	Zag_item
080601	8.6	S1-152137	Alcatel-Lucent, Cisco	Scope clarification of PPEPO_LTE TR 22.838	This P-CR modifies the Scope of 22.838 by taking into account that paging policy algorithms are out of SA1 scope.	Agreed.
080602	8.6	S1-152105	Cisco, Alcatel-Lucent	Clarifications for use case on paging policy differentiation based on user’s active area	This P-CR clarifies failure scenario aspects of the use case on paging policy differentiation based on user’s active area and additionally suggests an alternative solution-agnostic wording.	To be discussed off-line with China Unicom.	Revised to S1-152459
080602r	8.6	S1-152459	Cisco, Alcatel-Lucent	Clarifications for use case on paging policy differentiation based on user’s active area	Revision of S1-152105	Agreed.
080603	8.6	S1-152136	Alcatel-Lucent, Cisco	Clarifications for use case on paging policy differentiation based on application characteristics	This P-CR clarifies the use of application characteristics known to and trusted by the serving network as the basis for differentiating the paging policy.	Revised to S1-152460
080603r	8.6	S1-152460	Alcatel-Lucent, Cisco	Clarifications for use case on paging policy differentiation based on application characteristics	Revision of S1-152136	Agreed.
080604	8.6	S1-152234	China Unicom	Use case on paging policy differentiation based on user’s priority	This contribution proposes a new use case on paging policy differentiation based on user’s priority for TR 22.838.	Some off-line discussion between China Unicom and Cisco are encouraged. A number is pre-allocated in case an agreement can be found.	Revised to S1-152461
080604r	8.6	S1-152461	China Unicom	Use case on paging policy differentiation based on subscriber’s priority per application	Revision of S1-152234	Noted.
080605	8.6	S1-152235	China Unicom	Use case on paging policy differentiation based on QoS information	This paper describes a use case where the QOS information can be used by the network in optimizing paging procedures.	The APN information can be used.	Noted.
080606	8.6	S1-152236	China Unicom	Use case on paging policy differentiation based on APN	This contribution proposes a new use case on paging policy differentiation based on APN for TR 22.838.	Same comment on the APN.	Noted.
080607	8.6	S1-152237	China Unicom	Considerations on Congestion for PPEPO_LTE	Considerations on congestion are added.	The first paragraph can be rewritten since non controversial. The 2nd is not to be kept.	Revised to S1-152462
080607r	8.6	S1-152462	China Unicom	Considerations on Congestion for PPEPO_LTE	Revision of S1-152237	Revised to S1-152683
080607rr	8.6	S1-152683	China Unicom	Considerations on Congestion for PPEPO_LTE	Revision of S1-152462	Agreed.
080608	8.6	S1-152238	China Unicom	Considerations on Charging for PPEPO_LTE	This PCR adds that "There may be impact on charging aspects to the person or the third party who needs to prioritize its paging messages in order to reduce the service latency and guarantee the user’s experience. "	For Nokia Networks, this is not correctly written, and the performance characteristics should be addressed rather than charging.	Revised to S1-152463
080608r	8.6	S1-152463	China Unicom	Considerations on Charging for PPEPO_LTE	Revision of S1-152238	Edited while projecting.	Revised to S1-152684
080608rr	8.6	S1-152684	China Unicom	Considerations on Charging for PPEPO_LTE	Revision of S1-152463	Agreed.
080621	8.6	S1-152347	Rapporteur	TR22.838 v0.2.0 to include agreements at this meeting	TR	This version includes the material agreed at SA1#71.	Agreed to be send for information to SA.
080623	8.6	S1-152685	Rapporteur (China Unicom)	Cover page for TR 22.838	TR	Agreed to be sent to SA for information.
080700	8.7	Zag_item	Zag_item	8.7 FS_eFMSS: Enhancement to FMSS for Rel 14 [SP-150280]	Zag_item
080701	8.7	S1-152441	China Mobile	eFMSS use case for supporting third party owned (S)Gi-LAN service	22.808	0001	B	13.0.0	Rel-14	FS_eFMSS	Revision of S1-152201. A new use case and potential requirements are added to TR22.808 to state that eFMSS can support third party owned (S)Gi-LAN service.	Commercial companies such as "YouTube" should not be mentioned. "charging to the user traffic" should be replaced by "accounting". "The 3GPP core network shall be able to support to define and change the traffic steering policies (…)": the wording is not correct. The format of the figures is not editable.	Revised to S1-152458
080701r	8.7	S1-152458	China Mobile, Huawei	eFMSS use case for supporting third party owned (S)Gi-LAN service	22.808	0001r1	B	13.0.0	Rel-14	FS_eFMSS	Revision of S1-152441	Some clean-up needed. Commercial companies should not be mentioned. Some rephrasing should be done.	Revised to S1-152682
080701rr	8.7	S1-152682	China Mobile, Huawei	eFMSS use case for supporting third party owned (S)Gi-LAN service	22.808	0001r2	B	13.0.0	Rel-14	FS_eFMSS	Revision of S1-152458	Agreed.
080800	8.8	Zag_item	Zag_item	8.8 Other Study Item contributions	Zag_item
090000	9	Zag_item	Zag_item	9 Work planning contributions	Zag_item
090100	9.1	Zag_item	Zag_item	9.1 Work Plan	Zag_item
090101	9.1	S1-152006	ETSI	Extract of the 3GPP Work Plan for SA1#71	Noted.
090200	9.2	Zag_item	Zag_item	9.2 Work Item/Study Item status update	Zag_item
090201	9.2	S1-152352	Rapporteur (Applied Communication Sciences)	MPS_Mods status update	This WI has been approved at SP#65 Approved WID is in tdoc SP-150043. Work/Study Item Completion: 40%. Target completion date in WID: 06/2016 SP#72	Noted.
090202	9.2	S1-152353	Rapporteur (Sprint)	ELIOT status update	WI has been approved at SP#67 Approved WID is in tdoc SP-150044. Work/Study Item Completion: 80% Target completion date in WID: 12/2015 SP#70	Noted.
090203	9.2	S1-152354	Rapporteur (KDDI)	CATS status update	WI has been approved at SP#68 Approved WID is in tdoc SP-150273 Work/Study Item Completion: 100%	Noted.
090204	9.2	S1-152355	Rapporteur (Vodafone)	FS_SMARTER status update	WI has been approved at SP#67 Approved SID is in TDoc SP-150142 Phase 1, Step 3 in SID, complete TR 22.891 60% Phase 1, Step 5 in SID, completion of subsequent TRs 0% Expected date to send TR 22.891 to SA plenary: For information: SA#69 (09/2015) For approval: SA#70 (12/2015)	Noted.
090205	9.2	S1-152356	Rapporteur (French MoI)	FS_MCVideo status update	WI has been approved at SP#67 Approved WID is in tdoc SP-150048. Study Item Completion: 80% Draft TR 22.879 Completion: 80% Target completion date in WID: 11/2015 SP#70	The completion rate is 70%.	Revised to S1-152758
090205r	9.2	S1-152758	Rapporteur (French MoI)	FS_MCVideo status update	Revision of S1-152356	Noted.
090206	9.2	S1-152357	Rapporteur (French MoI)	FS_MCData status update	WI has been approved at SP#67 Approved WID is in tdoc SP-150049. Work/Study Item Completion: 90% Draft TR 22.880 Completion: 90% Target completion date: For information: SA1#71 (08/2015) For approval: SA1#xx (11/2015)	Noted.
090207	9.2	S1-152358	Rapporteur (LG Electronics)	FS_V2XLTE status update	WI has been approved at SP#67 Approved WID is in tdoc SP-150051 . Work/Study Item Completion: 90% Draft <TS/TR> 22.885 Completion: 90% Expected date to send <TR/TS> to SA plenary: For information: SA1#71 (08/2015) For approval: SA1#72 (11/2015)	Completion to be changed to 75% since several contributions could not be handled.	Revised to S1-152759
090207r	9.2	S1-152759	Rapporteur (LG Electronics)	FS_V2XLTE status update	Revision of S1-152358	Agreed.
090208	9.2	S1-152359	Rapporteur (Huawei)	FS_EnTV status update	WI has been approved at SP#66 Approved WID is in tdoc SP-150052 Work/Study Item Completion: 75% Draft <TS/TR> 22.816 Completion: 75% completion date in WID: <12/2015> SP#70	Noted.
090209	9.2	S1-152360	Rapporteur (China Unicom)	FS_PPEPO_LTE status update	WI has been approved at SP#67 Approved WID is in tdoc SP- 150053 Study Item Completion: 60% Draft TR 22.838 Completion: 60% Expected date to send TR to SA plenary: For information: SA1#71 (08/2015) For approval: SA1#72 (11/2015)	Noted.
090210	9.2	S1-152361	Rapporteur (China Mobile)	FS_eFMSS status update	WI has been approved at SP#68 Approved WID is in tdoc SP-151280. Work/Study Item Completion: 70% Target completion date in WID: <12/2015> SP#70	Noted.
090211	9.2	S1-152745	Rapporteur	Status Update for Enhancements to User Location Reporting Support	This is a new WI. Target completion date in WID: 12/2015 SP#70	Noted.
090212	9.2	S1-152746	Rapporteur	Status Update for LTE support for V2X services	This is a new WI. Target completion date in WID: <03/2016> SA#71	Noted.
090300	9.3	Zag_item	Zag_item	9.3 SA1 process improvements/updates	Zag_item
090400	9.4	Zag_item	Zag_item	9.4 Others	Zag_item
-1	8.1	S1-152076	Intel Corporation (UK) Ltd	SMARTER Use case for Bio-connectivity	Revised to S1-152401
-1	6	S1-152107	Intel Corporation (UK) Ltd	Corrections of ACDC Requirements	22.011	Revised to S1-152351
-1	8.4	S1-152139	Alcatel-Lucent	FS_V2XLTE: Roaming support	Was revised to S1-152607 but confusion with numbers.	Revised to S1-152608
-1	4	S1-152151	LG Electronics France	Handling of uncategorized ACDC applications	22.011	0217	Revised to S1-152402
-1	4	S1-152152	Intel	Discussion on Clarification on ProSe Public Safety Discovery	Revised to S1-152398
-1	4	S1-152153	Intel	CR on Clarification on ProSe Public Safety Discovery	22.278	0219	Revised to S1-152350
-1	8.7	S1-152201	China Mobile	eFMSS use case for supporting third party owned (S)Gi-LAN services	Revised to S1-152441
-1	5	S1-152239	China Unicom, ZTE, CATR	Proposed WID for Enhancements to User Location Reporting Support	WID	Revised to S1-152309
-1	5	S1-152257	LG Electronics Inc.	V2X SID Status and Plan for the Next	Revised to S1-152387
-1	8.4	S1-152291	Qualcomm Incorporated	Considerations on Spectrum	Abstract: Resubmission of S1-151187 from SA1#70. This contribution proposes some considerations on the use of spectrum for V2X services	Revised to S1-152376
-1	8.4	S1-152292	Qualcomm Incorporated	Considerations on Coverage	Abstract: Resubmission of S1-151189 from SA1#70. This contribution proposes some considerations on coverage for V2X services	Revised to S1-152377
-1	4	S1-152350	Intel	CR on Clarification on ProSe Public Safety Discovery	22.278	0219r1	Revision of S1-152153	Revised to S1-152397
-1	8.4	S1-152608	Alcatel-Lucent	FS_V2XLTE: Roaming support	Revision of S1-152139	Revised to S1-152610
100000	10	Zag_item	Zag_item	10 Next meetings	Zag_item
100100	10.1	Zag_item	Zag_item	10.1 Calendar	Zag_item
110000	11	Zag_item	Zag_item	11 Any other business	Zag_item
120000	12	Zag_item	Zag_item	12 Close	Zag_item
999999	S1-152429	Reserved Mark	Withdrawn
999999	8.4	S1-152617	Not used	Reserved V2X	Not used
999999	8.4	S1-152618	Not used	Reserved V2X	Not used
999999	8.4	S1-152619	Not used	Reserved V2X	Not used
999999	8.4	S1-152620	Not used	Reserved V2X	Not used
999999	8.4	S1-152621	Not used	Reserved V2X	Not used
999999	8.4	S1-152622	Not used	Reserved V2X	Not used
999999	8.4	S1-152623	Not used	Reserved V2X	Not used
999999	8.4	S1-152624	Not used	Reserved V2X	Not used
999999	8.4	S1-152625	Not used	Reserved V2X	Not used
999999	8.4	S1-152626	Not used	Reserved V2X	Not used
999999	8.4	S1-152627	Not used	Reserved V2X	Not used
999999	8.4	S1-152628	Not used	Reserved V2X	Not used
999999	8.4	S1-152629	Not used	Reserved V2X	Not used
999999	8.4	S1-152630	Not used	Reserved V2X	Not used
999999	8.4	S1-152631	Not used	Reserved V2X	Not used
999999	8.4	S1-152632	Not used	Reserved V2X	Not used
999999	8.4	S1-152633	Not used	Reserved V2X	Not used
999999	8.4	S1-152634	Not used	Reserved V2X	Not used
999999	8.4	S1-152635	Not used	Reserved V2X	Not used
999999	8.4	S1-152636	Not used	Reserved V2X	Not used
999999	8.4	S1-152637	Not used	Reserved V2X	Not used
999999	8.4	S1-152638	Not used	Reserved V2X	Not used
999999	8.4	S1-152639	Not used	Reserved V2X	Not used
999999	8.4	S1-152640	Not used	Reserved V2X	Not used
999999	8.4	S1-152641	Not used	Reserved V2X	Not used
999999	8.4	S1-152642	Not used	Reserved V2X	Not used
999999	8.4	S1-152643	Not used	Reserved V2X	Not used
999999	8.4	S1-152644	Not used	Reserved V2X	Not used
999999	8.4	S1-152645	Not used	Reserved V2X	Not used
999999	8.4	S1-152646	Not used	Reserved V2X	Not used
999999	8.4	S1-152647	Not used	Reserved V2X	Not used
999999	8.4	S1-152648	Not used	Reserved V2X	Not used
999999	8.4	S1-152649	Not used	Reserved V2X	Not used
999999	8.4	S1-152650	Not used	Reserved V2X	Not used
999999	8.4	S1-152651	Not used	Reserved V2X	Not used
999999	8.4	S1-152652	Not used	Reserved V2X	Not used
999999	8.4	S1-152653	Not used	Reserved V2X	Not used
999999	8.4	S1-152654	Not used	Reserved V2X	Not used
8.2	S1-152009	U.S. Department of Commerce	Off-Network MCVideo Collapsed Parking Garage Use Case	This contribution proposes to add an Off-Network MCVideo Collapsed Parking Garage use case and associated requirements into the FS_MCVideo draft TR 22.879 for Release 14.
7.4	S1-152080	Intel Corporation (UK) Ltd	Corrections of ACDC Requirements	22.011	Withdrawn
8.1	S1-152146	Alcatel-Lucent	FS_SMARTER: Dynamic Subscription generation	This contribution describes a scenario for IoT support in a 5G network. When an IoT UE is manufactured it may not be known where the UE will be deployed, on what network, etc. All that may be known is that the UE will use the 3GPP technology. In such cases, a UE may have a factory installed certificate which the UE can provide to a network on first access for mutual authentication and to initiate the dynamic subscription generation. At that time, additional information will be exchanged with the network to create a subscription and establish service for the UE.	The chair wondered if there is a possible convergence between the view expressed e.g. by Orange with the one expressed e.g. by Alcatel-Lucent and NEC. For Vodafone, this contribution addresses "the network" or "the access network", but it is not clear which (access) network is referred to. For Intel, their view of proposing an embedded UICC is already a compromise position. For Orange, the Intel's approach is premature. Orange clarified that their requirements are compatible with both the embedded UICC and with the physical, separate UICC card. For Ericsson, eUICC should already be on the market. The security requirements should be provided by SA3. For Microsoft, subscription management seem to be excluded from the Orange's proposal. For Vodafone, there will be a full range of use cases, from a proper terminal to a small sensor, and several authentication mechanisms might have to be defined. All these documents have to be discussed together, and if any common conclusion can be extracted, then it has to be submitted to SA1. Otherwise, it will have to be concluded that there is no conclusion from SA1 on this topic at this time. For the SA3 chairman, if some operator's requirement is to keep the UICC, then it has to be stated clearly. If the requirement is something different, then it also has to be stated clearly.	S1-152106, S1-152149 and S1-152146 in S1-152468.
S1-152191	Huawei	Clarification for latency signification	Revision of S1-152144	Revised to S1-152677
8.4	S1-152302	LG Electronics Inc.	V2X service and application
S1-152348	Not used	Reserved Toon	Not used
S1-152349	Not used	Reserved Toon	Not used
S1-152362	Reserved Toon	Not used
S1-152363	Reserved Toon	Not used
S1-152364	Reserved Toon	Not used
S1-152365	Reserved Toon	Not used
S1-152366	Reserved Toon	Not used
S1-152367	Reserved Toon	Not used
S1-152368	Reserved Toon	Not used
S1-152369	Reserved Toon	Not used
S1-152387	LG Electronics Inc.	V2X SID Status and Plan for the Next	Revision of S1-152119	Revision of S1-152257. This is a presentation of the status of the V2X WID and a plan for the next steps.	The WID is in S1-152258.