3GPP TSG-SA WG1 Meeting #69

Sanya, China, 2-6 February 2015

tdoc list SA1#69 draft END OF MEETING

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
040005,2	4	S1-150001	Deutsche Telekom/SA1	Reply LS to CT1 (Cc SA2) on eCall implementation in IMS	LS draft	It is proposed to answer: "There is no requirement yet on IMS based eCall".	Approved.
010101	1.1	S1-150002	SA1 Chairman	Draft agenda for SA1#69	Revised to S1-150007.
030101	3.1	S1-150003	SA1 Chairman	SA1-related topics at SA#66	Noted.
010301	1.3	S1-150004	ETSI MCC	Draft minutes of SA1#67bis on MCPTT and SA1#68	Revised to S1-150005.
010301,2	1.3	S1-150005	ETSI MCC	Minutes of SA1#67bis on MCPTT and SA1#68	Approved.
090101	9.1	S1-150006	ETSI MCC	Extract of the 3GPP Work Plan for SA1#69	Noted, info to be updated by the status update of SA1#69.
010101,2	1.1	S1-150007	SA1 Chairman	Draft Schedule and Agenda with document allocation for SA1#69	Revised to S1-150008.
010101,4	1.1	S1-150008	SA1 Chairman	Final Schedule and Agenda with document allocation for SA1#69	Approved.
050202	5.2	S1-150009	VODAFONE Group Plc	New study item on New Services and Markets Technology Enablers - SMARTER	WID	This is a proposal for the WID on 5G/SMARTER. The objective of this study is to develop high-level use cases and identify the related high-level potential requirements to enable 3GPP network operators to support the needs of new services and markets. 8 steps are proposed to reach this aim.	There is no foreseen completion date since this will be discussed at SA in March. For ATT and Nokia, either all use cases have to be kept or none, but filtering them should be avoided. For Qualcomm, explaining a new generation by just picking up 3 to 4 use cases is quite restrictive. About the timing, reaching Step 8 by say March 2016 is ambitious. For Nokia, even if the schedule is contribution driven, there should still be some initial time line proposed. They also mentioned that a step 0 could be added on market considerations, and that the NGMN paper also has to be considered. Alcatel-Lucent clarified that the MGMN document should be available before the end of this meeting. Also, the Chinese IMT-2020 document is available on the internet. For China Mobile, some use cases might be covered already by LTE, so classifying them as "5G" might be misleading. Telefónica revealed that the NGMN paper contains several use cases, to be considered by SA1. There is no disagreement to use whatever material is available. Some examples are mentioned in the WID (4G Americas). For KPN, the last 3 steps related to the normative work and should then not appear in this study WID. NEC wondered if 5G will support all present services such as SMS. There are contributions on this topic, e.g. from Qualcomm. The relationship between SA1's study and RAN's 5G study was questioned. It was noticed that, in the past, SA1's study was relatively ignored by RAN. The chair clarified that the only way for SA1's output to have an impact on RAN is that the companies present in SA1 and also present in RAN ensure that the SA1's outputs are not ignored. In summary: The last paragraph in the justification will have to be more accurate: all external sources will be mentioned, as their availability. In the objective, the examples will have to be deleted. The step once proposed to be added on identifying market segment is actually covered by the paragraph stating "It is desirable…" in the justification. A time-line can be proposed to some of the steps. In step 4, the Study items can be building blocks of the SMARTER study feature. About the timing of each steps: - It is reminded that March 2016 is the Rel-14 Stage 1 timeline. - Last 3 steps are informative. - end of Step 5 should be March 2016. The requirements relevant for RAN should be ready before RAN start their work. Once the study is finished, Nokia would like to see it submitted for consultation with some other groups, e.g. at least with SA2, before to start the normative work. Qualcomm explained that the RAN's Chair view is that the structural input is the IMT-2020 document, and related new frequencies attribution. - step3 should de done 6 months before step 5, so September 2015. - back to step 5: add "to consult with other WGs if necessary".	Revised to S1-150211
999999	7.2	S1-150010	Telefónica Europe plc	Update of Definitions	22.101	0495	This is an update of the Definitions to accommodate new section on GERAN UTRAN Sharing	Revised to S1-150035
070151	7.1	S1-150011	US Department of Commerce (David Cypher)	Replacement of Home and Visited by Primary and Partner	22.179	0001	F	13.0.1	Rel-13	MCPTT	Replace Home MCPTT system and Visited MCPTT system with Primary MCPTT System and Partner MCPTT System in 6.8.1 to be consistent with the naming in 6.18.	Agreed.
070152	7.1	S1-150012	US Department of Commerce (David Cypher)	Completion of application of S1-144278	22.179	0002	F	13.0.1	Rel-13	MCPTT	This CR deletes the duplicate requirements in 5.5.2 with requirements in 5.1.5 and delete third requirement	The deleted requirements should be marked as "void".	Revised to S1-150225
070153	7.1	S1-150013	US Department of Commerce (David Cypher)	Clarification of number and types of Private Calls	22.179	0003	F	13.0.1	Rel-13	MCPTT	This CR properly identifies the types of Private Calls and when used	The UK Home Office disagrees as it is since the meaning is changed.	Revised to S1-150226
070154	7.1	S1-150014	US Department of Commerce (David Cypher)	Correction of type of Private Calls supported in for both on and off the network use.	22.179	0004	F	13.0.1	Rel-13	MCPTT	This CR properly identifies that only requirements for Private Calls with Floor control are supported in both on and off the network operation and therefore included in clause 5.	The UK Home Office disagrees: some requirements are removed as they are said to be duplicated but they cannot find where they were duplicated. They support the Alcatel-Lucent's change in S1-150186 on the same section.	Merged with Alcatel-Lucent in S1-15231.
070155	7.1	S1-150015	US Department of Commerce (David Cypher)	Clarification of number and types of Private Calls	22.179	0005	F	13.0.1	Rel-13	MCPTT	This applies the missing requirements from S1-144570.	The title has to be revised. The original contribution seems to contain a mistake which has to be corrected.	Revised to S1-150228
070156	7.1	S1-150016	Alcatel-Lucent	Improper use of 'emergency'	22.179	0006	F	13.0.1	Rel-13	MCPTT	The term 'emergency' has been used inappropriately in a few places in the document. Each time it applies, "emergency" is replaced by "MCPTT emergency".	Agreed.
999999	7.1	S1-150017	Alcatel-Lucent, US Dept. Of Commerce	Correct use of MCPTT terminology	22.179	0007	Implementation of features could be different and potentially wasteful of radio resources."	Revised to S1-150185
070157	7.1	S1-150018	Alcatel-Lucent	Clarifying KPI requirement	22.179	0008	F	13.0.1	Rel-13	MCPTT	A requirement is modified to use 'shall'.	Revised to S1-150229
070158	7.1	S1-150019	Alcatel-Lucent, US Dept. Of Commerce	Wording correction	22.179	0009	D	13.0.1	Rel-13	MCPTT	It changes the phrase "alias associated alias(es)" to "associated User ID alias(es)".	Agreed.
999999	7.1	S1-150020	Alcatel-Lucent	Private Call	22.179	0010	Implementation of functions and features could be different."	Revised to S1-150186
070160	7.1	S1-150021	US Department of Commerce (Bruce Ward)	Change the title of TS 22.179 to align with MCPTT WID and agreed contribution S1-144232	22.179	0011	F	13.0.1	Rel-13	MCPTT	Change the title of TS 22.179 to align with MCPTT WID and agreed contribution S1-144232	Agreed.
070161	7.1	S1-150022	Alcatel-Lucent, US Dept. of Commerce	Changing Ues to UEs	22.179	0012	D	13.0.1	Rel-13	MCPTT	This CR changes occurrences of Ue to UE	Agreed.
070162	7.1	S1-150023	Alcatel-Lucent, US Dept. Of Commerce	Editorial clean ups	22.179	0013	D	13.0.1	Rel-13	MCPTT	A number of editorial changes are proposed.	Agreed.
070163	7.1	S1-150024	Alcatel-Lucent	Explanatory text in clause 5.6.3	22.179	0014	F	13.0.1	Rel-13	MCPTT	The first two paragraphs in clause 5.6.3 were mistakenly marked as requirements. They are explanatory text providing context for the requirements in the clause.	The Editor proposes to have a sub-section 5.3.1 separated from the other requirements in section 5.3.2. This is accepted. Motorola has concerns with the writing of the existing two first paragraphs. Nobody can understand them so there are proposed to be deleted. If not, they have to be re-written.	Revised to S1-150231
070164	7.1	S1-150025	US Department of Commerce (Bruce Ward)	Clarification of dedicated MCPTT Group type used for Imminent Peril Group call communication by MCPTT User	22.179	0015	F	13.0.1	Rel-13	MCPTT	This CR properly identifies the dedicated MCPTT Group type used for Imminent Peril Group call communication	Agreed.
070165	7.1	S1-150026	US Department of Commerce (Bruce Ward)	Replacement of personality management with user profile management	22.179	0016	F	13.0.1	Rel-13	MCPTT	This CR replaces the terms "personality management" (no longer used) with the terms "user profile management".	Typo in the title, to be corrected by MCC.	Agreed.
070166	7.1	S1-150027	US Department of Commerce (Bruce Ward)	Modify text in first sentence of third paragraph for clause 7.1 Off-Network Push-to-Talk overview.	22.179	0017	F	13.0.1	Rel-13	MCPTT	This CR corrects the third paragraph in 7.1. since the text which is not a sentence.	Agreed.
070167	7.1	S1-150028	US Department of Commerce (Bruce Ward)	Replacement of clause 5.14 title Audio/ video quality with Audio/ voice quality.	22.179	0018	F	13.0.1	Rel-13	MCPTT	Replace the title of TS 22.179 to be consistent with clause 10 of the MCPTT WID and agreed contribution S1-144232.	Agreed.
070168	7.1	S1-150029	US Department of Commerce (Bruce Ward)	Convert 2nd sentence of 5th requirement in clause 6.2.4 Call Termination into a new requirement	22.179	0019	F	13.0.1	Rel-13	MCPTT	It makes the 2nd sentence of 5th requirement in clause 6.2.4 Call Termination into a new requirement in TS 22.179. It also adds the new requirement as the last requirement.	For the UK Home Office, it would have been more logical to place the cut part of the sentence immediately after what used to precede it, but this will confuse the numbering. It was proposed to use the same numbering scheme as for sections, i.e. number this one "5a", but this is not agreeable. So it is numbered 7 but not put in sequence.	Revised to S1-150232
070169	7.1	S1-150030	US Department of Commerce (Bruce Ward)	Move three requirements from clause 6.1 General Administrative -groups and users into common clause 5.19 General Administrative -groups and users.	22.179	0020	F	13.0.1	Rel-13	MCPTT	The CR re-arranges the three requirements [R-6.1-003], [R-6.1-004] and [R-6.1-005] from clause 6.1 into common clause 5.19 General Administrative –groups and users since they are common to on- and off-network.	There are overlaps with S1-150092.	Revised to S1-150233
050331	5.3	S1-150031	III	V2X Use Case: ProSe-based toll collection	This proposed use case leads to the conclusion that the operator shall be able to authorize a Toll Collect System to charge the user who enables an application for Toll Collection in the vehicle over E-UTRA.	This deals with RSU. For Huawei, this is out of scope of V2X: this is simply a case where the UE receives some ProSe communication. For Qualcomm, this is within the scope of V2X, and it is even rather similar to other contributions on V2I. They see that the only new item brought by this contribution is that the RSU might be connected to the network by some internet connectivity. This can be rewritten to make this input clearer.	Revised to S1-150294
050378	5.3	S1-150032	III	V2X Use Case: ProSe-based V2P	This is a proposed use case on ProSe-based V2P, concluding that the impact of discovery on battery consumption could be critical and should be minimized at a level that is sufficient for the service and does not impact the user experience of using the device.	This is a "P2P" (person-to-person) use case, according to Qualcomm, and as such is not in the scope of the study. And the battery consumptions aspects in ProSe are covered already by ProSe.	Noted.
050342	5.3	S1-150033	III	V2X Use Case: Relative speed between ProSe-enabled UEs	A new Use Case is proposed for Relative speed between ProSe-enabled UEs	This is not seem to be a V2X topic by several companies.	Noted.
050379	5.3	S1-150034	III	V2X Use Case: “See Where I am” Use Case	A new Use Case is proposed for “See Where I am” concluding that all the members of a group (e.g. taxi drivers) can see all the other members of the same group.	Huawei, LG and Qualcomm have difficulties understanding this use case and its particularities. It seems to be out of scope of V2X. If needed, this contribution has to be rewritten at a future meeting to underline the V2X-specific aspects.	Noted.
070201	7.2	S1-150035	Telefónica	Update of Definitions	22.101	0495r1	D	13.4.0	Rel-13	GUSH	The CR updates the Definitions following the addition of text for GUSH	The definitions reflect a problem that, each time a new generation/system is introduced, several parts of text of different specifications need to be re-written to state to which generation(s) they apply. The category should be F and not D.	Revised to S1-150214
080101	8.1	S1-150036	Gemalto, Telecom Italia	APN provisioning based on UE bootstrap from UICC without an OMA DM-Server	Replace the title of clause 5.14 Audio/ video quality with the title Audio/ voice quality to be consistent with the requirements in this clause and the titles in clause 6.15.5 and clause 7.11.3 in TS 22.179:	Ericsson has concerns with changing the service flows: the user is now selecting the mobile operator. When this applies in a car context, the country is not necessarily known. Ericsson prefer the case when the M(V)NO is selected by the car manufacturer, as before. So the first change has to be deleted, the rest is agreeable.	Revised to S1-150257
040001	4	S1-150037	NGMN 5G Initiative Steering Committee	Second Liaison to 3GPP on NGMN’s 5G Initiative	LS in	LS from NGMN is to inform 3GPP about the key messages of the NGMN 5G White Paper due for publication in March. See related contributions in agenda item 5 on SMARTER.	Noted.
040002	4	S1-150038	SP-140884	LS on Establishment of new working group TSG SA WG6	LS in	New WG SA6 has been set up, ToR attached and some additional information on SA6 responsibilities in relation with other WGs such as SA1, SA2 and CT WGs.	Noted.
040003	4	S1-150039	RP-142312	LS on LTE based Vehicular Communication	LS in	RAN asks SA1 to prioritise development of V2V requirements and to share these with RAN by RAN#68 (June). See related contributions in agenda item 5.3 on V2X. Response required (propose to postpone to next meeting)	There is no requirement defined yet in this field. This might be the case at the next SA1 meeting. Telecom Italia and Huawei noticed that V2X priotisation is not considered at this stage. This can be done later on. The Chair clarified in written the following statement: When SA1 considers the V2V potential requirements are completed, the potential requirements will be sent to RAN, either by attaching the draft TR to the outgoing LS, or by copying the potential requirements into the LS.	Postponed to next meeting
040004	4	S1-150040	RILTE#42 Doc 105	LS on PIN based service activation	LS in	RILTE asks SA1 to consider PIN based activation for services in IMS and especially for VoLTE. Response required	There are documents on this at this meeting.	Noted, answer in S1-150220
040008	4	S1-150041	C4-142474	Reply LS on Maintenance of I-WLAN Solution	LS in	CT4 work for maintenance of I-WLAN solution is complete.	Noted without presentation.
040005	4	S1-150042	C1-145030	LS on eCall	LS in	CT1 asks if there are requirements for IMS based eCall and eCall using ICS	Proposed answer in S1-150001.
040009	4	S1-150043	C1-144650	Reply LS on personal data on USSD authenticator	LS in	CT1 has completed their work to support network-initiated USSD.	Noted without presentation.
040010	4	S1-150044	S5-145405	Reply LS on ProSe Lawful Interception – UICC based charging	LS in	Based on SA3 feedback, SA5 has noted in their TR 32.844 that recording of usage information cannot always be trusted.	Noted without presentation.
070101	7.1	S1-150045	SA1 Chairman	MCPTT core item selection procedure	This document clarifies how the MCPTT core item selection will be done for the SA1#69 meeting in Sanya. The main objective of this exercise is to select a number of MCPTT core "modules" that results in a viable deployable service.	The following 4 steps are proposed: Step 1: Use MCPTT WID bullets in clause 4 (Objective) as initial basis for grouping sub-clauses into "modules". Step 2: Clarify, update or split up modules defined Step 1, if necessary. Step 3: Add new modules to include items from TS 22.179 not covered by Steps 1 and 2. Step 4: Indicate dependency/functional mapping/interaction between modules. This is to avoid a core module having a dependency on a non-core module.	Noted. See corresponding proposal in S1-15046.
070102	7.1	S1-150046	U.S. Department of Commerce	Mapping of functional modules to TS 22.179 clauses	This contribution proposes functional modules for MCPTT and a mapping of these to the clauses of TS 22.179.	See S1-15061 on the same topic.	Noted
050101	5.1	S1-150047	MINISTERE DE L'INTERIEUR	Mission Critical Video over LTE	WID	The objective of the work item is to define use cases and requirements for mission critical video communications. These video communications will have to work on top of the bearer functionalities developed in GCSE and ProSe work item.	For Qualcomm, Video is a new topic, to be developed from scratch. This is different from the other work on MCPTT, which was just transposition of existing services on other systems. It would be justified to start with a study. Qualcomm anticipate the stage 3 work to be done in SA4. Most of the work seems to be on transcoding, in Qualcomm's views. For the French Ministry of Interior, the normal process should be followed, i.e. perform the study and take the conclusions after the study is completed. The U.S. Department of Commerce wonders if this WID will cover every video application or if there will be other application(s) not to be covered. They notice that it might be over ambitious to try to cover all video applications from the beginning, and the WID should be generic enough as to allow future, yet not anticipated, video application. The Ministère de l'Intérieur shares this view. Some formal aspects of the WID have to be corrected (tick boxes on the "impacted elements", etc.). NSN notice that they is no legacy aspects to support, and the application(s) can be developed outside 3GPP. For the Chair, it is still worth to make the study to check its conclusions. Qualcomm asked if the primary use will be Streaming rather than download. The Ministère envisages several possible cases, including streaming and downloading. For Qualcomm, the requirements are very different and the study should focus on one case only, preferably the streaming. The Ministère agrees with focussing on real time aspects, and the WID will be rewritten accordingly. Broadcasting can also be covered. Qualcomm notes that some synchronisation aspects (of the video with audio, data) should also be studied. The French Ministère agrees. Home Office and Telecom Italia support this WID, which is now a Study Item.	Revised to S1-150193
050105	5.1	S1-150048	MINISTERE DE L'INTERIEUR	Data group communications	WID	The objective of the work item is to define use cases and requirements for data communications for groups of users.	The intention is that there will be no new service requirement. There are some typos to be corrected. The appropriateness to state "IP-based" or not as well as potential relationship with eICBD will be discussed off-line.	Revised to S1-150197
070182	7.1	S1-150049	The Police of the Netherlands	MCPTT core modules proposal Police of the Netherlands	Taken into account for the compilation document on MCPTT modules in S1-15224.
080405	8.4	S1-150050	TeliaSonera AB	Consideration on CATS and Network Sharing	This document covers CATS and RAN Sharing. Specifically, could CATS be invoked independently (separate control per PLMN) or would it have to be set the same way for all Participating Operators?	Agreed.
999999	7.1	S1-150051	MINISTERE DE L'INTERIEUR	MCPTT core items, France	Revised to S1-150208
040004,5	5.4	S1-150052	ORANGE	Parental control feature for Outgoing Communication Barring	The definition of the Parental Control option for Outgoing communication barring is added in section 8.2.10.1 in MMTEl 22.173	Not needed, covered by S1-150177.	Noted.
040004,4	5.4	S1-150053	Orange	Parental Control option for OCB	22.173	0102	B	12.8.0	Rel-14	PC-OCB	The definition of the Parental Control option for Outgoing communication barring is added in section 8.2.10.1	This can be seen as a subset of S1-150171. The wording is proposed to be improved. The "super-user" in the cover page is not defined, but this cover page will not be carried over anyway since the proposed change will be included in S1-150192. For Nokia, this is already covered by S1-150192.	Open / Noted (included in S1-150192).
999999	5.3	S1-150054	LG Electronics	Proposed study on LTE-based V2X	Study Item proposal regarding LTE-based V2X for Rel-14	Revised to S1-150194
050332	5.3	S1-150055	LG Electronics	Proposed Skeleton for V2X TR	TR skeleton proposal for V2X SID	Some alignments with the new version of the WID are needed.	Revised to S1-150239
050334	5.3	S1-150056	LG Electronics	Definitions and abbreviations for V2X TR	Proposal on an initial set of definitions and abbreviations.	NEC propose to remove the definitions since the concepts are not yet stable. Qualcomm agree. So only the abbreviations have to be kept.	Revised to S1-150241
050333	5.3	S1-150057	LG Electronics	Proposed Text for Overview Section for V2X TR	Proposal for the Overview section of the new TR on V2X	The different types of V2X are introduced, as well as the data paths for V2X. For the data paths, some online editing was done as to make the section clearer.	Revised to S1-150240
050335	5.3	S1-150058	LG Electronics	V2V Use cases for Road Safety services	This paper proposes to capture V2V use cases and the related potential requirements in Technical Report on LTE-based V2X.	For Qualcomm, this is a combination of 2 use cases: lost of control and collision. They are quite different cases with different implied reactions. See S1-15117 on similar topic.	Noted/merged in the revisions of S1-15117 and S1-15118.
050371	5.3	S1-150059	LG Electronics	V2I Use case for Road safety services	A new use case is proposed for Road safety services via V2X-enabled eNB. This is a V2I (Vehicle to Infrastructure)’ scenario.	Qualcomm mentioned that this is the same as the RSU case: eNodeB can become RSUs via software update. Some rewording are proposed for some potential requirements.	Revised to S1-150292
050376	5.3	S1-150060	LG Electronics	V2P Use cases for Road Safety services	This paper proposes a use case for Pedestrian Collision Warning.	There is no consensus on this use case. See also S1-150119 on the same topic.	Noted.
070103	7.1	S1-150061	U.S. Department of Commerce	Mapping of MCPTT functional modules to TS 22.179 clauses –Proposed additions	On the basis of S1-150046, this contribution proposes to map additional subclauses from clause 5, 6 and 7 of 22.179 to several functional modules from the 17 functional modules provided by the MCPTT Rapporteur in completion of Steps 1, 2 and 3 of the 7 high level steps proposed by the SA1 Chair.	See S1-150088 on the same topic.
080403	8.4	S1-150062	Intel Corporation (UK) Ltd	P-CR to address Editor’s Note Regarding Implementation, Assumptions etc. in Potential Requirements in CATS TR 22.818	P-CR to address Editor’s Note Regarding Implementation, Assumptions etc. in Potential Requirements	See S1-150126 on the same topic.	Revised to S1-150272
070199	7.1	S1-150063	U.S. Department of Commerce	MCPTT core items	This contribution provides a set of MCPTT modules that contain mapped subclauses of 22.179 which are considered as MCPTT core items for Release 13.	Noted without presentation.
050403	5.4	S1-150064	China Telecommunications	New SID on Virtualized EPS	This is a new SID on the scenarios, use cases and requirements of virtualized EPS.	Withdrawn.
050107,2	5.1	S1-150065	SPRINT Corporation	Proposed new WID on Enhancing Location Capabilities for Indoor and Outdoor Emergency Communications (ELIOT)	WID	The objective of this work item is to revise and enhance the existing 3GPP requirements for emergency location services to incorporate enhanced indoor location capabilities for emergency calls using LTE.	The first bullet in the objective needs to be explained with an e.g. or an i.e. since "physical condition" is not clear as such. Vodafone noticed that, for the altitude aspect, there might be other means than barometric pressure, e.g. WLAN coverage can be used. Nokia noticed that the horizontal accuracy is mentioned to be about 50m, but for the vertical one, it should be a building's floor, which is about 3 meters. Also, about telling which flat it is, this would be hard to achieve from a 3GPP-system point of view: the 3GPP requirement should rather be on giving e.g. the geographic coordinates, then another system would provide the flat number.	Revised to S1-150199
050107	5.1	S1-150066	SPRINT Corporation	FAQ discussion for Emergency Location enhancement WID (ELIOT)	This discussion paper in the form of a Frequently Asked Questions (FAQ) provides the background on the new WID proposed in S1-150065.	The WID in S1-150065 is to enhance and extend the 3GPP location service requirements for emergency communication to address several trends affecting citizen to authority emergency communication (911)	Noted. See S1-150065.
050308	5.3	S1-150067	Samsung R&D Institute UK	New SID on Service Requirements for Vehicular Communication in 3GPP	WID	This document is a proposal for new Rel. 14 study item about 3GPP vehicular communication.	This is another version of the proposed WID on V2X.	Noted. See other proposals on the same topic.
050301	5.3	S1-150068	Samsung R&D Institute UK	New feature for vehicular communication in 3GPP	This document is a discussion material for S1-150067.	Revised before presentation.	Revised to S1-150195
050401	5.4	S1-150069	China Unicom	Discussion on potential enhancements on EPS towards Virtualized Network	This contribution serves to illustrate some potential needs of the study on 3GPP when the virtualization technology is introduced.	This is an introduction to S1-150206.	Noted.
999999	5.4	S1-150070	China Unicom, China Telecom, Telefonica, Huawei, ZTE, CATR, ITRI	New Study on Enhancements on EPS towards Virtualized Network	Revised to S1-150206
999999	8.3	S1-150071	China Unicom	Considerations on Congestion for eULRS	Revised to S1-150249
999999	8.3	S1-150072	China Unicom	Consolidated requirements for eULRS	Revised to S1-150251
080301	8.3	S1-150073	China Unicom	References	This PCR cleans up the reference clause 2.	Agreed.
999999	8.3	S1-150074	China Unicom	Definitions and abbreviations	Revised to S1-150250
050303	5.3	S1-150075	ITRI	Discussion on very High Mobility Networks & Scenarios	This presentation underlines that supporting a reliable communication and providing a good user experience on high speed rail system are a pressing problem to be solved. They suggest that a new study item might be needed to handle this problem, or at least this has to be covered in a use case of V2I and/or V2X communication e.g., High mobility aspects of V2X.	Qualcomm support the idea of high speed mobility, but think it is a different problem than V2X, which should rather focus on topics such as avoid collisions. NEC and Vodafone noticed that speeds higher than 350 km per hour are mentioned, which is the maximum speed supported by LTE, so wonder about the implications of this proposed WID. Huawei mentioned that RAN is also working on this subject. The following answers are proposed to the last 2 questions: is it part of V2X?-> No. Shall a new SID be started?-> No. Telefónica and Orange suggested that it could be a part of SMARTER..	Noted. RAN's results will have to be known and used to further work in this domain
999999	5.4	S1-150076	China Unicom, TeliaSonera, ZTE, CATR, ITRI	New Study on Paging Policy Enhancements and Procedure Optimizations in LTE	Revised to S1-150207
080406	8.4	S1-150077	KDDI, Qualcomm Incorporated, TeliaSonera AB, Intel	Consideration on Security	22.818	This pCR addresses consideration on security.	Nokia noticed that this sentence does not cover the case where the attack comes from inside the 3GPP network.	Revised to S1-150274
999999	8.4	S1-150078	KDDI, TeliaSonera AB, Intel	Considerations on Relationship Between CATS and other Existing Access Controls	22.818	Revised to S1-150254
080407	8.4	S1-150079	KDDI, TeliaSonera AB, Intel	Use case on relationship to Access Class 11-15	22.818	This pCR addresses a use case on relationship to Access Class 11-15.	Open to off-line discussions	Revised to S1-150278
080401	8.4	S1-150080	KDDI	FS_CATS TR Editorial Update: References	22.818	This pCR proposes editorial update of the reference section.	Agreed.
080402	8.4	S1-150081	KDDI	FS_CATS TR Editorial Update: Definitions and abbreviations	22.818	This pCR proposes editorial update of Definitions and Abbreviations.	The section should be 3.2.	Agreed.
080409	8.4	S1-150082	KDDI	Consolidated requirements	22.818	Noted.
999999	5.2	S1-150083	SK Telecom	SKT's 5G Core Network	Revised to S1-150196
999999	5.3	S1-150084	HUAWEI TECHNOLOGIES Co. Ltd.	V2X Services are already defined so 3GPP should define transport	Withdrawn
999999	5.3	S1-150085	HUAWEI TECHNOLOGIES Co. Ltd.	V2X Services are already defined so 3GPP should define transport	Withdrawn
999999	5.3	S1-150086	HUAWEI TECHNOLOGIES Co. Ltd.	V2X Services are already defined so 3GPP should define transport	Withdrawn
070170	7.1	S1-150087	Ericsson, Motorola Solutions	Charging for MCPTT usage	22.179	0021	F	13.0.1	Rel-13	MCPTT	It has been discovered that Rel-13 lacks charging requirements for MCPTT. This CR adds such requirements to TS 22.179.	The category should be changed from F to B. Some typos to be corrected ("identifies", "61" instead of "6", missing one carriage return). Telecom Italia support this CR. It was wondered if 22.115 would not have been a better place to put the charging requirements but it is preferred to keep them in 22.179. There is no consensus on item 5.	Revised to S1-150234
070104	7.1	S1-150088	Ericsson LM	Mapping of MCPTT functional modules to TS 22.179 clauses –Proposed changes	This is Ericsson's suggestion on how the modules and mapping should look like. A list is proposed to be used as modules in the MCPTT prioritization process.	Lines 6 and 10 in the Excel document: for the US Department of Commerce, you cannot choose one without choosing the other.	See also S1-150101 on the same topic.
070184	7.1	S1-150089	Ericsson LM	Ericsson's MCPTT core modules prioritization	This is Ericsson suggestion on how to prioritize the MCPTT core modules.	Taken into account for the compilation document on MCPTT modules in S1-15224.
050351	5.3	S1-150090	Ericsson LM	V2V ProSe requirements	The LS from RAN asked SA1 to either make V2V part of Rel-13 or to prioritize it as an early drop from the work in Rel-14. This contribution includes requirements for V2V based on ProSe.	For Alcatel-Lucent and Qualcomm, "V2V ProSe" is a new association of terms that should be avoided, This is seen as V2V material, and not ProSe one. For Qualcomm, it is essential to have inter-operator coordination on V2V: ot would be acceptable that a vehicle equipped with Orange cannot communicate with another one equipped with Vodafone. For Telecom Italia, all this material has clearly to go to Rel-14. The chair explained that the proposed solution by the SA chair is that requirements can be sent by LS to RAN, which will tell what is doable in Rel-13 (knowing that "nothing" is a possible answer).	Revised to S1-150247
080103	8.1	S1-150091	BlackBerry UK Limited	Updates to UICC based solutions for automotive cases	Changes are proposed to the UICC based solutions for automotive cases to consider a solution that avoids impacts to the UICC, ME and UICC-ME interface.	Vodafone support this contribution.	Revised to S1-150273
070169,2	7.1	S1-150092	Motorola Solutions	Reinstatement of MCPTT User Profile	22.179	0022	F	13.0.1	Rel-13	MCPTT-SA1	This CR adds the requirement for the MCPTT Administrator to be able to reinstate a suspended MCPTT User Profile	The requirement might be moved later, so MCC has to implement it wherever the requirement ended up being.	Agreed.
070171	7.1	S1-150093	Motorola Solutions	Fix improper multiple requirements	22.179	0023	F	13.0.1	Rel-13	MCPTT-SA1	R-6.1-007 contains two requirements the second one being an implementation issues	Agreed.
070172	7.1	S1-150094	Motorola Solutions	Remove implementation-specific requirement for default value	22.179	0024	F	13.0.1	Rel-13	MCPTT-SA1	The existence of a default value and the actual default value for the depth of queues is implementation or service specific and should not be mandated	Agreed.
080205	8.2	S1-150095	SPRINT Corporation	Discussions of UC_SPOOF requirements consolidation	Collection and analysis of the requirements in the TF	This is just a description document.	Noted.
080204	8.2	S1-150096	SPRINT Corporation	UC_SPOOF potential requirements	This contribution proposes the potential requirements to add based on the consolidated requirements discussion in S1-150095.	About "The user shall be able to notify the network, either before the call is answered, during the call, or after the call is completed," Nokia wonder if all UEs will have to have this capability and if so, it might be complex. Some other changes will be introduced by off-line discussions between Sprint and Nokia.	Revised to S1-150262
080202	8.2	S1-150097	SPRINT Corporation	UC_SPOOF considerations based on device capabilities	This contribution proposes adding text discussing how user control of spoof call detection is dependent on device capabilities.	Agreed.
080201	8.2	S1-150098	SPRINT Corporation	UC_SPOOF considerations based on spoofed call detection deployments	This contribution proposes adding text discussing how user control of spoof call detection may need to change as the adoption of spoofed call detection such as developed by "IETF stir" working group by operators increases.	Agreed.
080206	8.2	S1-150099	SPRINT Corporation	UC_SPOOF conclusions and recommendations	Proposed conclusion and recommendation for the TR. It is proposed to conclude that this study recommends that when a spoofed call detection mechanism is standardized by 3GPP, that the user control of spoofed call detection also be standardized for several aspects.	The document was available late, and this raises problems for some companies. Nokia noticed that the terminology does not seem to be the same as what is used in the rest of the TR.	Revised to S1-150263
080102	8.1	S1-150100	Intel Corporation (UK) Ltd	Optional support of DM bootstrap function and reliance on OMA DM client	It is proposed to replace the editor's note in 5.4 with a note to clarify that "the optional method of provisioning APNs through DM bootstrap depend on applications outside the modem, applications like the OMA DM client, supporting the access and use of the DM bootstrap file."	Soe rewording will be proposed.	Revised to S1-150258
070105	7.1	S1-150101	HOME OFFICE	Input to Discussion on Functional Blocks and Dependencies	This proposal is intended to provide input to the definition of functional blocks. This document builds on the work done by the US Dept of Commerce and Ericsson that were separately circulated on the reflector.	As Ericsson mentioned, there are about 600 requirements, so it is too many to go through them one by one in SA1. KPN pointed out that the classification is urgent. A first off-line discussion will take place on Monday noon to arrange the functional modules list.	Revised to S1-150221
070173	7.1	S1-150102	Home Office	CR to clarify requirements in 6.4.5	22.179	0025	F	13.0.1	Rel-13	MCPTT	In section 6.4.5 there are 2 requirements R-6.4.5-003 and R-6.4.5-006, which appear to be duplicates of R-6.4.5-001 and R-6.4.5-005, so they are proposed to be deleted.	There is no agreement on these requirements to be strictly equivalent.	Noted.
070174	7.1	S1-150103	Home Office	CR- to clarify requirements in 6.4.9 and 6.2.4.	22.179	0026	F	13.0.1	Rel-13	MCPTT	There are some duplicate requirements related to hang time in the 2 sections 6.4.9 and 6.2.4 and corrections that should be made.	Off-line discussions are needed before to reach an agreement.	Revised to S1-150236
070175	7.1	S1-150104	HOME OFFICE	CR to remove queuing from Off-Network Floor Control	22.179	0027	Requirement R-7.3.2-004 includes a requirement to allow queuing Off-Network this CR removes this, as it is deemed unnecessary.	Withdrawn
070176	7.1	S1-150105	Home Office	CR to clarify what call type refers to in 6.2.3.3.1	22.179	0028	F	13.0.1	Rel-13	MCPTT	The terminology ‘call types’ is replaced with ‘call/transmission priority’ and examples are included in brackets to indicate what is being referred to.	Revised to S1-150265
070177	7.1	S1-150106	Home Office	CR- Editorial Change to Private Call overview 5.6.1	22.179	0029	D	13.0.1	Rel-13	This is a minor editorial change to remove unnecessary text in 5.6.1	Already covered by other CRs.	Noted without presentation.
070178	7.1	S1-150107	US Department of Commerce (David Cypher)	Separation of supplementary service, callback, requirements	22.179	0030	D	13.0.1	Rel-13	MCPTT	Currently the call back feature is included in the Private Call General Requirements clause 6.7.1, but would more appropriately be part of its own clause.	Agreed.
050304	5.3	S1-150108	GM - OnStar	Automotive Use Cases for LTE-based V2X Study Item	This contribution provides several use cases for Vehicle-to-vehicle (V2V) vehicle-to-infrastructure (V2I), and other use cases that are related to connected vehicle in the LTE network.	Qualcomm support this paper. NSN wonder if the "relative positioning" is not already possible now. And here too, they have concern with the concept of eNodeB in the vehicles (section 1.4). Samsung and LG have concerns about the proposed latency. There are no requirements proposed yet for sections 1.2 and 1.4 but GM clarified that they would encourage delegates to bring some. These proposals can be brought as pCR when the TR is started.	Noted.
070199	7.1	S1-150109	QUALCOMM Incorporated	Media Recording and Media Mixing in Off-Network MCPTT Service	This paper proposes to categorise some of the requirements for Off-Network MCPTT service as non-core in order to simplify UE implementation and decrease time-to-market.	Noted.
050291	5.2	S1-150110	QUALCOMM Incorporated	SMARTER: Horizontal requirements for SMARTER	This paper proposes that in addition to developing use cases for the next generation system 3GPP SA1 should consider starting a TR to capture high level service requirements and capabilities.	This topic has been covered by other contributions.	Noted without presentation.
050292	5.2	S1-150111	QUALCOMM Incorporated	SMARTER: Use case for reliable communications	This paper proposes a use case for SMARTER related to reliable communications whereby a minimal level of reliability and latency is required to guarantee the user experience and/or enable the service initially.	Since the TR is not ready yet, these use cases will have to be presented again at next meeting.	Noted.
050293	5.2	S1-150112	QUALCOMM Incorporated	SMARTER: Use case for control-type services subscription management	This paper proposes use cases for SMARTER related to subscription management and provisioning of devices, specifically in a connected IoT industrial environment	Noted.
050294	5.2	S1-150113	QUALCOMM UK Ltd	SMARTER: Use case for extreme real-time communications	This paper proposes introductory use cases for extreme real-time communications	Noted.
050295	5.2	S1-150114	QUALCOMM Incorporated	SMARTER: Use Cases for a Multifaceted Network Edge	This paper proposes use cases for SMARTER leveraging a Multifaceted Network Edge. These use cases include wireless self-backhauling, vehicular networking, and support for heterogeneous IoT.	Noted.
050407	5.4	S1-150115	QUALCOMM Incorporated	Proposed study on eMBMS for Digital TV	WID	This paper proposes a new study item on the support of Digital TV Services on top of 3GPP eMBMS.	TeliaSonera support this WID. AT&T wondered about the relationships with RAN's Full-spectrum utilisation. Orange and Telecom Italia have concerns with this item, which seem to be consuming a lot of bandwidth for TV services, that can be provided by other means. Qualcomm propose to use the Huawei's WID as a basis, and introduce relevant parts of their WID into Huawei's one.	Noted, incorporated in S1-150215.
050406	5.4	S1-150116	QUALCOMM Incorporated	Discussion on eMBMS-based Digital TV Service	This paper proposes justification for starting a new study on Digital TV Services via eMBMS	This is rather in line with Huawei's proposal in S1-150151. The SID is in S1-150115. The "content provider" might be either the MNO, a TV broadcaster or whoever will provide content.	See actual WID in S1-150115.
050336	5.3	S1-150117	QUALCOMM Incorporated	V2X Use Case – Forward Collision Warning	The FCW use case is proposed: the Forward Collision Warning (FCW) application is intended to warn the driver in case of an impending rear-end collision with a vehicle ahead in traffic in the same lane and direction of travel. FCW is intended to help drivers in avoiding or mitigating rear-end vehicle collisions in the forward path of travel.	Qualcomm mentioned that they put intentionally several "TBD" to show the several areas where numbers are needed (speed, distance, etc.). "A V2V Service enabled entity" is a long name to designate a V2V entity. There is no consensus on the 7th proposed requirement, which can be deleted at this stage.	Revised to S1-150242
050337	5.3	S1-150118	QUALCOMM Incorporated	V2X Use Case – Control Loss Warning	The CLW use case is proposed: the Control Loss Warning (CLW) application enables a vehicle to broadcast a self-generated control loss event to surrounding vehicles. Upon receiving such event information, another vehicle determines the relevance of the event and provides a warning to the driver, if appropriate.	Here again, the wording was refined while projecting. About the hops and how many of them are possible, Qualcomm will bring a different contribution later on.	Revised to S1-150243
050377	5.3	S1-150119	QUALCOMM Incorporated	V2X Use Case –Vulnerable Road User Safety	This use case describes the scenario whereby a vehicular and a pedestrian both equipped with V2X capabilities detect each other’s presence and alert the driver and/or the pedestrian, if immanent threat is present. This capability extends the safety benefit of V2X to pedestrians and other vulnerable road users, e.g. bicyclists, wheelchairer, etc..	Same use case as S1-150060, for which there is no consensus (within or outside the scope of V2X?).	Noted.
050341	5.3	S1-150120	QUALCOMM Incorporated	V2X Use Case – Cooperative Adaptive Cruise Control and Platooning	This use case describes the scenario whereby a vehicular with V2X capability joins and dis-joins from a platoon of corporative-adaptive-cruise-control (CACC) vehicles. This is intended to provide convenience and safety benefits to participating vehicles and also has societal benefits to improve road congestion and fuel efficiency.	"platoon" refers to a series of vehicles locked together in speed. Qualcomm explained that two types of messages are needed: coordination and cruise control. It is pointed out that the 2nd proposed requirement is on the application layer. Telefónica wondered about the interface between the car and the device. For Qualcomm, this might be out of scope of 3GPP: the services will be proposed to the car manufacturers, who will have to use them. Qualcomm explained that CACC just takes care of the speed whereas platoon takes care of speed and space between cars. Vodafone wondered why not to simply call a platoon a "convoy". Qualcomm just reused some terminology from other groups.	Revised to S1-150246
050372	5.3	S1-150121	QUALCOMM Incorporated	V2X Use Case – Queue Warning	This use case illustrates a situation where a group of vehicles are queuing at a certain location, e.g. junction or car part entrance. The driver of an approaching car can be made aware of the situation using V2X capabilities, such that appropriate actions can be planned for a smoother ride.	This text has to be aligned to the one of the other contributions just approved. The different actors have to be presented is a clearer way.	Revised to S1-150293
050340	5.3	S1-150122	QUALCOMM Incorporated	V2X Use Case – Hazardous Road Condition	This use case describes a scenario wherein a hazardous condition is encountered on the road (e.g. ice, road water, strong winds) and a vehicle initiates an event-driven broadcast message to inform nearby cars of the hazard. This message may trigger other vehicles to identify that they are subject to the same hazard, and to rebroadcast this message.	For KPN, this type of messages need to be broadcast in a certain area. This is not necessarily V2X specific. For Qualcomm, this is a possible case of use of V2X. For Alcatel-Lucent, this is the same as the "stopped car" scenario. Qualcomm explained the difference to be the re-broadcast scenario, only here and not in the "stopped car" one. It is noted that if this is the application which takes care of re-broadcast, then there is nothing to do at 3GPP level. For Qualcomm, there are indeed several ways to support this functionality, including indeed the application, but another possibility is that the transport layers are aware of the need to re-transmit the message. For Huawei, the current wording implies that the decision is made at the application, so it has to be changed. The precise revisions, if any, have to be handled off-line.	Noted. Companies interested in re-broadcasting/relay are invited to contact Qualcomm before the next meeting.
050374	5.3	S1-150123	QUALCOMM Incorporated	V2X Use Case – Automated Parking System	This use case illustrates an application of V2X communication allowing a driver to reserve a parking space, be guided to it with an integrated navigation application, and make payment for the exact amount of time parked. Several related use cases can be constructed involving similar capabilities, e.g., finding a gas station and making payment for fuel; making seamless road tolling transaction.	Huawei supports this use case. The potential requirements were revised while projecting to fit with what has been agreed previously during this meeting.	Revised to S1-150295
050375	5.3	S1-150124	QUALCOMM Incorporated	V2X Use Case – Tethering via Vehicle	This use case describes the scenario whereby a vehicular passenger connects to the wireless network "proxied" via the vehicle. This provides power savings to the passenger’s UE and potentially increase quality depending upon vehicular & UE equipment.	"It shall be possible" to be changed by another wording. NEC and Telefónica have concerns about the usefulness of this use case. GM support the paper. Huawei think that this use case will not bring any new requirement. For Qualcomm, it is premature to have such a statement. For NSN, V2V should be limited to Control, safety and infotainment. This is not Qualcomm's view, where other significant items can also be covered. No consensus at this stage.	Noted.
060001	6	S1-150125	KPN	Alignment of ProSe communication charging data requirements	22.115	0075	F	12.2.0	Rel-12	ProSe	In SA1#68, there was a discussion on delayed charging data reporting for ProSe communication usage records. It was discussed in SA1 that the problem would be significantly reduced if both transmitted and received charging data was recorded. Now it turns out that SA5 has already included usage data recording for both transmitted and received data. To avoid future confusion in SA1, it is proposed to align the ProSe communication charging requirements with what has been implemented by SA5 in Release 12.	The "/" is unclear: is it "UE per group" or is it "UE or group": the second one is assumed, so this should be clarified. About "transmitted / received", it has to be clarified if it is two different fields and a combined one.	Revised to S1-150200
080404	8.4	S1-150126	QUALCOMM Incorporated	FS_CATS: Removal of Assumptions and Implementation Related Language	22.818	The proposed changes address Editor’s Notes in three use cases, which state: “Remove implementation and assumptions in requirements”.	Noted, covered by S1-150062.
999999	5.4	S1-150127	KPN	New WID on Enhancements for Infrastructure based Communication between Devices	WID	At the end of the FS_eICBD study, it was concluded in 22.807 that normative requirements should be generated. At the end of Release 13, however, there was no agreement to start a normative work item. We propose now to start the work in Release 14.	Revised to S1-150204
050416	5.4	S1-150128	KPN	Presentation on work item for enhancements for infrastructure based data communication between devices	This is a presentation to accompany the WID on Enhancements for Infrastructure based data Communication Between Devices	Noted.
080104	8.1	S1-150129	Ericsson	Text for conclusion section	Introduction of text to conclusion. The following conclusion is proposed for the TR on FS_MAPN: "The study has described several alternative solutions that fulfil the use-cases in the TR. The solutions that do not require any new standardization are recommended. "	Vodafone do not share this view. For them, several aspects have to standardised to support MAPN. Qualcomm support Ericsson's view: one single APN can support all the use cases expressed in the study. Telecom Italia support Vodafone's view, and propose to postpone the discussion to the next meeting since no card manufacturers could be present at this meeting. Telefónica also request for more time to have this reviewed internally. TeliaSonera is also of the opinion that this can be concluded next time. In the meantime, a very simple conclusion can be put.	Revised to S1-150260
050415	5.4	S1-150130	TNO	Infrastructure based data communication between devices	22.278	0216	This CR adds the requirements for Enhancements for Infrastructure based data Communication Between Devices.	Withdrawn
050413	5.4	S1-150131	KPN	MTC devices communicating with each other	22.368	0156	B	13.1.0	Rel-14	eICBD	22.368 currently states that MTC devices communicating directly with each other without an intermediate server is excluded. This CR proposes to lift this restriction with the introduction of Enhancements for Infrastructure based data Communication Between Devices.	For off-line discussion, see WID proposal in S1-15308.	Noted.
050414	5.4	S1-150132	KPN	Enhancements for infrastructure based data communication between devices	22.278	0217	B	13.2.0	Rel-14	eICBD	This CR adds the requirements for Enhancements for Infrastructure based data Communication Between Devices.	For off-line discussion, see WID proposal in S1-15308.	Noted.
999999	8.2	S1-150133	SPRINT Corporation	Editorial cleanup of TR 22.898	Editorial cleanup of 22.898	Revised to S1-150210
050409	5.4	S1-150134	China Telecom	Study on Enhancements to Domain selection for VoLTE	WID	This study is to provide details about the possible scenarios and use cases of VoLTE Domain selection between LTE and CDMA CS. It also aims at identifying potential solutions and optimization of the existing domain selection.	This is actually a Work Item and not a study, so several clean-up are needed (impacted specs, title of the WID, etc.). For Ericsson, if this is now an actual work item, then the objectives have to be made more explicit and cannot be open bullets. For Nokia, the 3rd bullet, if kept, should be the subject of another Work Item since it is rather different from the 1st and 2nd ones.	Revised to S1-150217
080408	8.4	S1-150135	China Telecom	Charging between CATS activation and deactivation	This contribution provide a use case to describe how to identified the traffic produced at CATS activation.	Some wording has to be clarified.	Revised to S1-150279
080105	8.1	S1-150136	Intel	On MAPN TR	Withdrawn.
050104	5.1	S1-150137	China Mobile	user case of PTT video	This doc proposes a use case of video transmission in MCPTT service for Mission Critical Video over LTE.	Having an audio mixer on the device is already difficult to handle. If a video component is added, this will become very challenging. Some simplifications have to be brought. As the other documents on video, this proposal has to be done in the form of a pCR to the new TR at the next meeting.	Noted.
050410	5.4	S1-150138	China Mobile, Huawei	Discussion on Flexible Mobile Service Steering (FMSS) for R14	This is a discussion paper to propose to a new WID for R14 FMSS to include topics such as Roaming for local breakout traffic flow, third party, charging issue based on VAS traffic amount, Service chain status, distributed Gi-LAN and service enabler aspects.	China Mobile might propose a corresponding WID at the next meeting.	Noted.
050411	5.4	S1-150139	China Mobile	New SID on Mobile CDN	WID	The objective is to study the scenarios and identify the requirements for mobile CDN to enable 3GPP network to support the CDN function and interwork with CDN function to reduce the bandwidth pressure and improve users’ experience.	There are now 4 supporting companies. For Cisco, this has impacts that need to be carefully study, e.g. on mobility. They wonder if this not fully part of the SMARTER work item.	Revised to S1-150289
999999	5.3	S1-150140	Huawei, Hisilicon	V2X Services are already defined	pCR	Revised to S1-150180
999999	5.3	S1-150141	Huawei, Hisilicon	V2V Use case for emergency vehicle warning	pCR	Revised to S1-150181
999999	5.3	S1-150142	Huawei, Hisilicon	V2V Use case for Emergency vehicle stop	pCR	Revised to S1-150182
999999	5.3	S1-150143	Huawei, Hisilicon	V2I Use case for Emergency vehicle stop	pCR	Revised to S1-150183
050354	5.3	S1-150144	Huawei, Hisilicon	V2I with Service RSU	other	This contribution clarifies that from 3GPP perspective, i.e. for the transport of V2X application service, the V2I service between vehicles and a “Services RSU” (like traffic lights RSU) is similar to V2V service between two vehicles.	Qualcomm and KPN are confused by the concepts of "Service RSU" and "Access RSU": in their view, this concept is not enough clarified in this contribution. Huawei clarified that the first type generates the data (e.g. traffic light, speed limit sign) whereas the second type provides access to internet. Still, for Qualcomm, there is no need for "Access RSU": the (e)NodeB/BTS are used directly, there is no need to go through whatever other type of unit. So in their view, the "Service RSU" is the "RSU" and there is no need to define the concept of "Access RSU". They propose the acronym of "V2N" for Vehicle to Network (for which there is no need for "Access RSU"). This view is accepted. About V2I and V2V being merged, this is agreeable.	Revised to S1-150256
999999	5.3	S1-150145	Huawei, HiSilicon	ProSe performance requirements to Support V2V/V2I Safety Service	22.278	0218	Revised to S1-150184
050102	5.1	S1-150146	Huawei, TD-Tech	MCPTT Video and Audio management Requirements	other	The document introduces how to manage different types and sources of Video/Audio.	This would be one of the use cases to be considered in the new Study Item on Video for MCPTT. For the US Department of Commerce, there are much more details to be found in this examples than just using the MCPTT group. This should be clarified when doing the related Study.	Noted.
050103	5.1	S1-150147	Huawei, TD-Tech	Requirements for See What I See	other	It is proposed to discuss the potential requirements abstracted from use case “see what I see” which is mentioned in GCSE TS22.468	To be revised at the next meeting, as to be included in the study on Video for MCPTT. For KPN, it is not the Dispatcher who broadcasts the video. This is rather the entire group.	Noted.
050104	5.1	S1-150148	Huawei, TD-Tech	Video Receiving Requirements	other	The following 2 requirements are proposed: "The MCPTT service shall provide a mechanism for a MCPTT user logging in multiple UEs to configure which MCPTT UE will receive certain type of media component." And "The MCPTT service shall provide a mechanism for a MCPTT user logging in multiple UEs to configure which MCPTT UE will present certain type of media component."	Same comment as for previous documents.	Noted.
050105	5.1	S1-150149	Huawei, TD-Tech	Video Transmitting Requirements	other	This contribution introduces the video broadcast by dispatcher to a MCPTT Group.	This is seen as very "dispatcher-centric" in Qualcomm's view: there is no need to go through it at all time.	Noted.
999999	7.1	S1-150150	Huawei, TD-Tech	Core Modules for MCPTT	other	Revised to S1-150304
050404	5.4	S1-150151	Huawei	Study on 3GPP Enhancement for Video	WID	The objective is to study scenarios and use cases and propose potential requirements for TV service enhancements in LTE.	To be merged with S1-150116 on the same topic.	Revised to S1-150215
050403	5.4	S1-150152	Huawei	3GPP enhancement for video discussion	other	This is a discussion paper that proposes to setup a new SI of video enhancement. The potential working aspects to be studied might include possible use cases and scenarios for video enhancement, including TV support, and then derive the potential service requirements.	The actual WID is in S1-150151.	Noted.
050309	5.3	S1-150153	ETRI	New Study Item Proposal: Feasibility Study on V2X over LTE	WID	This is another version of the proposed WID on V2X.	Noted. See other contributions on this topic.
050302	5.3	S1-150154	ETRI	Discussion on V2X over LTE	This presentation proposes to introduce a Study Item on use cases and identify potential service requirements needed for the 3GPP network to provide V2X.	In this proposal, some "moving BTS/eNB" can be used e.g. in buses. For NSN, this might confuse the UEs who will see several BTSs/ENBs and will not know which one to choose. Closed user groups might be the solution, according to Qualcomm, or there might be other solutions. For NSN, there are still other problems, e.g. the radio frequencies planning. The Chair reminded the analogy with eNodeB. GM supports this feature.	Noted.
050106	5.1	S1-150155	Applied Communication Sciences, OEC, AT&T, and Alcatel-Lucent	New WID for MPS Updates	WID	The objective is to update TS 22.153 (Multimedia Priority Service) as follows: 1. Alignment of the MPS Stage 1 requirements with Stage 2 & 3 capabilities 2. Inclusion of detailed MPS Stage 1 requirements for priority data and priority video communications, 3. Inclusion of detailed MPS Stage 1 requirements for end-to-end security protection of MPS communications:	To be discussed off-line with Nokia.	Revised to S1-150198
090201	9.2	S1-150156	Rapporteur (G&D)	FS_MAPN status update	Work/Study Item Completion: 90% Draft TR completion: 90 % Target completion date in WID: 03/2014 SA#63 Current target completion date: 06/2015 SA#68 Will target completion date be met? YES	M. Macchi will not come to SA1 anymore to a new Rapporteur is needed.	Noted.
090202	9.2	S1-150157	Rapporteur (Sprint)	FS_UC_SPOOF status update	Work/Study Item Completion: 100% Draft TR 22.898 Completion: 100%	Noted.
090213	9.2	S1-150158	Rapporteur (China Unicom)	Study on Enhancements to User Location Reporting Support (FS_eULRS) status update	Is this a new WI? No Study Item Completion: 90% Draft TR 22.899 Completion: 90% Target completion date in WID: <06/2015> SP#68	Noted.
090203	9.2	S1-150159	Rapporteur (KDDI)	FS_CATS status update	Work/Study Item Completion: 90% Draft TR 22.818 Completion: 90% Will target completion date be met? No If not, change target completion date to: 06/2015 SP#68 Expected date to send TR22.818 to SA plenary: For approval: SA1#68 (06/2015)	Noted.
999999	S1-150160	Chair's reserve	Chair's reserve
999999	S1-150161	Chair's reserve	Chair's reserve
999999	S1-150162	Chair's reserve	Chair's reserve
999999	S1-150163	Chair's reserve	Chair's reserve
999999	S1-150164	Chair's reserve	Chair's reserve
999999	S1-150165	Chair's reserve	Chair's reserve
999999	S1-150166	Chair's reserve	Chair's reserve
999999	S1-150167	Chair's reserve	Chair's reserve
999999	S1-150168	Chair's reserve	Chair's reserve
999999	S1-150169	Chair's reserve	Chair's reserve
999999	4	S1-150170	Ericsson	PIN based service activation for IMS Multimedia Telephony service	22.173	0103	B	12.8.0	Rel-14	TEI14	Revised to S1-150171
040004,2	4	S1-150171	Ericsson, Morpho Cards GmbH	Password based service activation for IMS Multimedia Telephony service	22.173	0103r1	B	12.8.0	Rel-14	Revision of S1-150170	It was commented on the SA1 reflector by some CT1 delegates if this is indeed "User authentication" or rather "subscriber authentication". For NEC, "user" is indeed correct. Agreement on the CR but the WI Code is missing.	Revised to S1-150192
040007	4	S1-150172	RILTE #43 Doc 121	LS to 3GPP on IMS Emergency Session over WLAN	LS in	RILTE asks if requirements for IMS Emergency Session support over WLAN can be considered by SA1.	For KPN, this depends on the country the call is originated from: in roaming situations, the emergency center of the home country might not be of great help. For NSN and Orange, this proposed requirement is valuable and has to be included in SA1 documentation.	Postponed to next meeting. The proposed answer in S1-150174, proposed WID in S1-150175 are withdrawn.
040006	4	S1-150173	RILTE#42 Doc 108	LS to 3GPP on erasing rule for a supplementary service	LS in	RILTE asks if it is mandatory for a UE to support the erasure of CDIV and CB supplementary services in IMS.	Proposed answer in S1-150176.
040007,4	4	S1-150174	Orange	Proposed reply LS on IMS Emergency Session over WLAN	LS draft	It is proposed to postpone this answer since other groups as SA2 are still working on this, and are not sure to keep it in Rel-13. SA plenary will be in a better position to answer, knowing the latest SA1 and SA2 results. SA1 is waiting the discussion on this topic based on the LS sent to SA Plenary and discussions on proposed WID in SA2 last week on the same topic. Orange pointed out that TS 22.234 (Requirements on 3GPP system to Wireless Local Area Network (WLAN) interworking) specifies the following: "5.1.6 Emergency calls Any attempt to make an emergency call shall be handled as defined in 3GPP TS 22.101[4]." Orange also pointed out that "TS 22.101 has the general requirements for Emergency calls in clause 10, with no restriction for WLAN. It is therefore clear that the stage-1 requirements for Emergency calls are the same for WLAN access as for 3GPP access". For the chair, TS 22.234 is not to be maintained. Intel agree that even though if does not directly imply to WLAN, this material can be reused to derive the WLAN-related requirements. There are IMS requirements for Emergency calls but not (yet) WLAN ones. KPN consider that it might be interesting to discuss this. Orange is invited to present a contribution to SA if they wish.	Withdrawn
040007,2	4	S1-150175	Orange	Proposed WID on IMS Emergency Session over WLAN	WID	Withdrawn
040006,2	S1-150176	T-Mobile/SA1	Proposed reply LS to GSMA RILTE (cc CT 1) on erasing rule for a supplementary service	LS out	Proposed answer to S1-150173. It is proposed to answer that "TS 22.173 defines the requirements for CDIV and CB in IMS, by reference to ETSI EN 300 200 for CDIV and to EN 301 082 and EN 301 084 for CB. All these specifications define erasure not to be applicable for the two mentioned supplementary services."	Approved.
999999	S1-150177	Ericsson	Proposed WID on Password-based service activation for IMS Multimedia Telephony service	WID	Revised to S1-150219
050305	5.3	S1-150178	NSN	Discussion of the V2X Study Items	This paper discusses the reasons why 3GPP technology is now considered for V2X, that the SID should not be limited to LTE but leave that to the work done under this SI, touches briefly on the different radio technology aspects for direct and infrastructure communication and clarifies the general communication scenarios to be mentioned in the SI. Finally it proposes to delete infotainment aspects from the SI.	The V2X SID is modified and the name is changed to "Study on Communication Aspects for Road Traffic Control and Safety, CAR_TCAS” in S1-150179. For Qualcomm: - 3GPP should focus on transport layer. ETSI ITS might not be acceptable to outside-ETSI countries. - agreed with not limited to LTE - infotainment: there will be implications on the system, so it cannot be ignored all together. - agreed on privacy aspects - most of it is covered by LGE SID. - also, Qualcomm propose not to change the name and keep "V2V". KPN also wish to keep the infotainment part. NEC support most of NSN's paper, but does not thing it should be limited to security aspects.	Noted. See all the other documents on the same topic.
050307	5.3	S1-150179	NSN	Study on Communication Aspects for Road Traffic Control and Safety (CAR_TCAS)	WID	This is a proposal to revise the V2X WID, as presented in S1-150178.	Noted, see other documents on this topic.
050310	5.3	S1-150180	Huawei, Hisilicon	V2X Services are already defined	pCR	Revision of S1-150140. This document clarifies the role of SA1 study considering that V2X application layer services (V2V, V2I…) are already defined in other SDO with their associated messages (CAM…). It adds these clarifications in scope, definition and Annex A sections of the TR for SA1 V2X study.	It is in particular stressed out that Europe ETSI ITS (Intelligent Transportation System) already provides V2X services descriptions and associated service messaging for travel safety needs. NEC wonder who will pay for the services mentioned e.g. in this document. Qualcomm pointed out that the ETSI ITS system designed has some particularities not shared with 3GPP, e.g. their system is based on another system not used in 3GPP.	Noted.
050338	5.3	S1-150181	Huawei, Hisilicon	V2V Use case for emergency vehicle warning	pCR	Revision of S1-150141. This contribution proposes a V2V use case to support emergency vehicle warning service (e.g., ambulances, fire engine…) used to provide information to surrounding vehicles to help the traffic.	In the 2nd proposed requirement, "minimum" frequency (of 10 messages per second) to be changed to "maximum". All references to ETSI spec can be deleted in the proposed requirement. A note is to be added to states that it has to be clearer clarified if the distances are between end-points or if there is infrastructure in between.	Revised to S1-150244
050339	5.3	S1-150182	Huawei, Hisilicon	V2V Use case for Emergency vehicle stop	pCR	Revision of S1-150142. This contribution describes a V2V use case to support emergency stop situation i.e. a stationary vehicle warning the other vehicles to avoid they collide.	Same comments as for S1-150181. For Qualcomm, the requirement here to transfer up to 3 Kbytes several times per seconds is different order of magnitude higher than what several delegations had in mind up to now. Square brackets are added to show that this are not stable numbers. Similarities were found with the Qualcomm's proposal, so they might tried to be merged off-line.	Revised to S1-150245
050353	5.3	S1-150183	Huawei, Hisilicon	V2I Use case for Emergency vehicle stop	pCR	Revision of S1-150143.	This will be further revised off-line.	Revised to S1-150255
050352	5.3	S1-150184	Huawei, HiSilicon	ProSe performance requirements to Support V2V/V2I Safety Service	22.278	0218r1	B	13.2.0	Rel-13	TEI13	Revision of S1-150145	To be further progressed at future meetings.	Noted.
070159	7.1	S1-150185	Alcatel-Lucent, US Dept. Of Commerce	Correct use of MCPTT terminology	22.179	0007r1	D	13.0.1	Rel-13	MCPTT	Revision of S1-150017. In a couple of instances, the terms defined in MCPTT have not been used when they should be.	Only the second change is to be kept (overlap for the first one).	Revised to S1-150230
070154,2	7.1	S1-150186	Alcatel-Lucent	Private Call	22.179	0010r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150020. The text in clause 5.6.1 regarding private calls with and without floor control is ambiguous regarding which are supported for both on and off network use.	Open	Included in S1-15342.
040101	4	S1-150187	S2-150664	LS on PLMN reselection for ProSe	LS in	SA2 asks CT1 and RAN2 to provide feedback on the issue and options identified by SA2 to resolve the scenario they present on PLMN reselection for ProSe..	Noted.
040102	4	S1-150188	S3-151162	LS on end-to-end WebRTC-IMS security	LS in	SA3 requests SA1 to provide feedback on the correct view to take on WebRTC security requirements contained in TS 22.228 and if applicable advise SA3 of any changes SA1 makes to TS 22.228 to amend or clarify SA1 requirements for WebRTC.	Hop-by-hop encryption might be OK in this case. For BT, it is not vulnerable in the middle but in the node, so this is what has to be solved. Vodafone mentioned that this is linked to the problem for the operators to support WebRTC LI. Also for Orange, the end-to-end encryption raises the concern of LI. So the SA1 agreement is on option 2 in the SA3's LS. The requirement needs to be clarified in TS 22.228.	Proposed answer in S1-150212 and related CR in S1-150213.
040103	4	S1-150189	S3-151198	Reply LS on Security Framework for Cellular IoT	LS in	SA3 asks SA1 and other groups to refine the requirements for Cellular IoT in certain cases related to security, in particular in roaming scenarios.	For KPN, it is too early to provide an answer, when the requirements have not yet been defined. BT explained that some countries do not allow encryption on the mobile network. For NEC, the problem is different to roaming in the classical sense: here, what is meant, is for devices to work in different countries, so it might be acceptable if a certain device does not work in a given country. For Vodafone, the security might be better for devices which are not intended to roam, and the security can be lower whenever needed, i.e. for devices which are intended to roam. TeliaSonera also think that more time is needed.	Postponed to next meeting.
040104	4	S1-150190	S3-151201	LS on work split for Study on Cellular IoT	LS in	SA3 is asking SA to give guidance on the work split for security in Cellular IoT between SA3, GERAN, GERAN2, SA1 and SA2.	Noted.
040105	4	S1-150191	S6-150100	LS on service continuity	LS in	SA6 asks SA1 to clarify whether MCPTT service continuity is implied and/or desirable for the following cases: - where MCPTT UE switches between EPC path and ProSe Communication path - where MCPTT UE, prior to automatically going off network, attempts to make use of a ProSe UE-to-Network Relay	The spec says that "interruption of the service has to be minimized". This was received late because SA6 was meeting just the week before, so more time was needed. For the Police of the Netherlands, this interruption has to be considered keeping in mind that it will be handled by an automated process. The overall view in SA1 is that the interruption shall be minimal, as stated in present requirements, but the intention is not to mandatorily have service continuity and that this interruption will be difficult to quantify. This is what should be answered.	Proposed answer in S1-150222
040004,2r	4	S1-150192	Ericsson, Morpho Cards GmbH	Password based service activation for IMS Multimedia Telephony service	22.173	0103r2	B	12.8.0	Rel-14	Revision of S1-150171	Related WID in S1-150177.	Revised to S1-150218
050101r	5.1	S1-150193	MINISTERE DE L'INTERIEUR	Mission Critical Video over LTE	WID	Revision of S1-150047	Revised to S1-150275
999999	5.3	S1-150194	LG Electronics	Proposed study on LTE-based V2X	Revision of S1-150054	Revised to S1-150202
050301,2	5.3	S1-150195	Samsung R&D Institute UK	New feature for vehicular communication in 3GPP	Revision of S1-150068. This discussion paper proposes a new Rel. 14 work item in SA1 to support vehicular communication.	See other docs on V2X.
050201	5.2	S1-150196	SK Telecom	SKT's 5G Core Network	Revision of S1-150083. This paper presents SK's initial views of different aspects of 5G: simplified architecture, innovative services, lower latency, more intelligent network, etc.	Noted.
050105r	5.1	S1-150197	MINISTERE DE L'INTERIEUR	Data group communications	WID	Revision of S1-150048	Revised to S1-150266
050106r	5.1	S1-150198	Applied Communication Sciences, OEC, AT&T, and Alcatel-Lucent	New WID for MPS Updates	WID	Revision of S1-150155	Revised to S1-150277
050107,2r	5.1	S1-150199	SPRINT Corporation	Proposed new WID on Enhancing Location Capabilities for Indoor and Outdoor Emergency Communications (ELIOT)	WID	Revision of S1-150065	Some typos to be corrected. About the "dispatchable address", Nokia commented that this is an aspect usually not handled by 3GPP.	Revised to S1-150299
060001r	6	S1-150200	KPN	Alignment of ProSe communication charging data requirements	22.115	0075r1	F	12.2.0	Rel-12	ProSe	Revision of S1-150125	Agreed.
060001rr	6	S1-150201	KPN	Alignment of ProSe communication charging data requirements	22.115	0075r1	F	12.2.0	Rel-12	ProSe	Mirror CR	Problem when uploading the file.	Revised to S1-150301
050331	5.3	S1-150202	LG Electronics	Proposed study on LTE-based V2X	WID	Revision of S1-150194. This is the proposal for the WID on Study on service aspects for LTE-based V2X ("FS_V2XLTE")	See all the documents concerning this WID. This document is to be used as a basis for the WID, including all the relevant comments resulting from the other documents on the same topic. This is to be done off-line.	Revised to S1-150209
070111	7.1	S1-150203	Ericsson, SA1 Chair, US Department of Commerce	Result of the drafting on MCPTT modules	The new version of the grouping is proposed. This is a result of offline discussions between all the interested companies.	Column C is the headers, Column D is for the individual requirements. See S1-150221 on the same topic. The documents to be considered are S1-150045, S1-150046, S1-150061, S1-150088, S1-150101 and S1-150203. Output in S1-150224.	Agreed to be used as a basis for the off-line discussion for MCPTT Core Items. Revised to S1-150237
050412	5.4	S1-150204	KPN	New WID on Enhancements for Infrastructure based Communication between Devices (eICBD)	WID	Revision of S1-150127. This WID, already seen at the previous meeting, is to provide the service requirements for: - Dynamic assignment/revocation of global IP addresses with access permissions - Setting up IP connections between two UEs via the infrastructure with or without use of a globally routable IP address; - Distribution of service discovery information within a group of UEs; and - Path optimization of an IP connection between two UEs.	There are still some instances of "routable IP address" that should be removed. See related CRs in S1-150131 and following.	Revised to S1-150267
070186	7.1	S1-150205	KPN	MCPTT Core Selection	Taken into account for the compilation document on MCPTT modules in S1-15224.
050402	5.4	S1-150206	China Unicom, China Telecom, Telefónica, Huawei, ZTE, CATR, ITRI, Intel, NSN, CHTTL	New Study on Enhancements on EPS towards Virtualized Network	WID	Revision of S1-150070. The objective is to study use cases for applications and network services, and propose potential requirements for new services obtained with introduction of network virtualization and for impacts on existing 3GPP services.	For Cisco and Telecom Italia, Virtualization is a deployment choice, not a matter for standardisation. For NSN, FMSS, UPCON, are examples of topics for which the same argument could have been used and were still developed in SA1. For NEC, there are requirements linked to virtualization and these could not be ignored. For Telecom Italia, the examples mentioned by NSN do have service implications. Here, the services are meant to be exactly the same with and without virtualization. For Fujitsu, this work is to be done in ETSI NFV. For Vodafone, ETSI NFV's attendance is mostly IT people, and there is a danger to loose some telco aspects, hence the interest to involve SA1 as to prevent this to happen. China Unicom clarified that their point with this WID is to clarify the 3GPP impacts, not to have all aspects of virtualization defined here.	Revised to S1-150248
050408	5.4	S1-150207	China Unicom, TeliaSonera, ZTE, CATR, ITRI	New Study on Paging Policy Enhancements and Procedure Optimizations in LTE	WID	Revision of S1-150076	NEC supports this WID. For Nokia, there might be overlap with some past work, in particular from SA2. For Cisco, there is no overlap with previous SA2 nor RAN work. The output will be in the 7xx series (now that all numbers in the 8xx series have been used).	Revised to S1-150216
999999	7.1	S1-150208	MINISTERE DE L'INTERIEUR	MCPTT core items, France	Revision of S1-150051	Mistake with the tdoc numbers.	Replaced by S1-150288
050331r	5.3	S1-150209	LG Electronics	Proposed study on LTE-based V2X	WID	Revision of S1-150202. The 3 cases to be studied are clarified to be V2V (between vehicles), V2P (between a vehicle and a user device carried by a pedestrian, cyclist, or other vulnerable road user) and V2I (between a vehicle and a roadside unit), all of this together being referred as V2X.	The section describing LTE in the Justification is seen useless in 3GPP and can be deleted. Some more clean-up was performed while projecting. About considering inputs from SDOs, Qualcomm think it is interesting to consider them but not to take them as a basis for the work. This idea is agreed so the corresponding paragraph (end of section 4) is rewritten. It was wondered if passengers are to be covered by this study. So far, it is not the case. This might be covered in a future revision of this WID.	Revised to S1-150238
080203	8.2	S1-150210	SPRINT Corporation	Editorial cleanup of TR 22.898	Revision of S1-150133. Several editorial clean-up changes are proposed for the FS_UC_SPOOF TR.	Agreed.
050202r	5.2	S1-150211	VODAFONE Group Plc	New study item on New Services and Markets Technology Enablers - SMARTER	WID	Revision of S1-150009. The WID has been refined off-line with all the supporting companies.	It was further edited while projecting. About the time line: for Vodafone, some targets have to be set, even if they have to be revised later on. In step 5, about consulting with the other WGs: this is not specific to this step so it can be removed. Nokia Networks to be added as supporting company, About vertical versus horizontal approach, NEC wonder if there should be several items, like "MTC smarter", "V2V smarter", etc. For Qualcomm, the SMARTER TS has to group all aspects. Ericsson is getting confused about the overall approach, where it seems that all future improvements are intended to be grouped into this "SMARTER" item. An iterative approach ("consolidation phase") might be needed to refine the work as a second phase. The anticipated completion dates are updated to 09/15 for information and 12/15 for approval.	Revised to S1-150253
040102,2	4	S1-150212	Alcatel-Lucent/SA1	Reply LS to SA3 (cc SA3-LI; SA2) on end-to-end WebRTC-IMS security	LS out	Proposed answer to S1-150188. It is proposed to answer that SA1 further considers that the language used in the requirements and supporting text allows the use of end to end (e2e) WebRTC security when LI regulations do not apply.	Nokia wonder if there is a company CR to clarify this point. Alcatel-Lucent answered that it is no the case. It should be the case for Nokia since the specification is not clear at present. The CR will be presented at a future meeting. Revision marks to be accepted before sending.	Approved. Revision marks to be accepted before sending.
040102,4	4	S1-150213	Orange	CR linked to S1-150188	22.228	0210	Withdrawn.
070201r	7.2	S1-150214	Telefónica	Update of Definitions	22.101	0495r2	F	13.4.0	Rel-13	GUSH	Revision of S1-150035	Agreed.
050404r	5.4	S1-150215	Huawei	Study on 3GPP Enhancement for Video	WID	Revision of S1-150151	Revised to S1-150305
050408r	5.4	S1-150216	China Unicom, TeliaSonera, ZTE, CATR, ITRI, CHTTL	New Study on Paging Policy Enhancements and Procedure Optimizations in LTE (PPEPO_LTE)	WID	Revision of S1-150207	The acronym should start with "FS_" since this is a study.	Revised to S1-150303
050409r	5.4	S1-150217	China Telecom	Study on Enhancements to Domain selection for VoLTE	WID	Revision of S1-150134	Revised to S1-150306
040004,2rr	4	S1-150218	Ericsson, Morpho Cards GmbH, Orange, Deutsche Telekom	Password based service activation for IMS Multimedia Telephony service	22.173	0103r3	B	12.8.0	Rel-14	PWDIMS	Revision of S1-150192	Agreed.
040004,4	5.4	S1-150219	Ericsson	Proposed WID on Password-based service activation for IMS Multimedia Telephony service (PWDIMS)	WID	Revision of S1-150177. The objective of this work item is to align the user behaviour, and add password based activation of supplementary services for the applicable IMS multimedia telephony supplementary services, with the relevant CS supplementary services as defined on TS 22.030	This is to align for IMS to what is available in the CS domain. See related CR in S1-150218. There will be definitely at least some Stage 3 aspects. An answer to the LS is proposed in S1-150220.	Agreed
040004,6	S1-150220	Ericsson	Proposed reply LS to GSMA RILTE (cc CT1) to S1-150040 on LS on PIN based service activation from GSMA RILTE	LS out	Proposed answer to S1-150040. GSMA Networks Group RILTE kindly requested 3GPP SA1 to consider PIN based activation also for services in IMS and especially for VoLTE. SA1 has agreed a change request to TS 22.173 to align the user behaviour, and add password based activation of supplementary services for the applicable IMS multimedia telephony supplementary services, with the relevant CS supplementary services as defined on TS 22.030, annex B.	Clean-up on the title to be performed when sending the LS (to avoid "LS on LS on"),	Approved.
070105r	7.1	S1-150221	HOME OFFICE	Input to Discussion on Functional Blocks and Dependencies	Revision of S1-150101. Some alignments with S1-150203 is attempted, but it is not exactly the same.	For Motorola, clear indications have to be provided on the impacts of putting MCPTT requirements in a column or the other one (i.e. core module or not) of the template in S1-150045. The Chair explained that a "core requirement" means that it is absolutely needed for the first release of MCPTT. Motorola wonder if Rel-13 will contain ONLY core aspects or might also contain some non-core topics, e.g. based on a vendor-operator agreement. The Chair explained that this full exercise is to help SA2 and avoid the situation which occurred some time ago for other subjects, where important features could not be deployed at all because all the essential aspects needed for the feature to work were not specified whereas some non-essential parts were defined. Back to the proposal, the one in S1-150203 from MCPTT Rapporteur has had more time to be reviewed by all delegates, and a consensus is almost reached. On the other hand, S1-150221 might be more precise but is lacking some reviews by other delegates. So S1-150203 is chosen as a basis for future work.	Companies are invited to align their views off-line.
040105r	4	S1-150222	S1/Intel	Proposed LS to SA6 on answer on service continuity	LS draft	Proposed answer to S1-150191	An off-line discussion took place to draft the answer to this LS. KPN commented that to go completely off network and then reconnect is challenging, but there might be some intermediate solutions where relays are used. This and other aspects will be continued off-line.	Revised to S1-150252
070187	7.1	S1-150223	UK Home office	MCPTT core items, UK	Taken into account for the compilation document on MCPTT modules in S1-15224.
070189	7.1	S1-150224	SA1 Chairman	Result of the drafting on MCPTT modules	This document highlights the results of MCPTT core module selection performed at SA1#69. It compiles the inputs for 8 organisations (4 governmental organisations, 2 operators and 2 vendors). One other organisation suggested requirements to be excluded from the core modules.	It is explained that the items at the top of the table can be seen as priority ones, whereas the ones at the bottom are lower priority for SA2 and SA6. It is also explained that the 2nd table is a copy of the 1st table where the items for which explicit rejection was expressed have been removed. The middle columns can be deleted from the 2nd column. In the 1st one, the column showing distinction between the types of organisations should be deleted for Motorola, since 3GPP Members should be treated as equals. Qualcomm agree in principle but for pragmatic reasons, this is valuable information in this case. E.g. "interworking with TETRA" is not supported by any government. For KPN, Telecom Italia and TeliaSonera, this is just a table with factual information, nothing else. And this is a piece of information, not a decision. The word "vote" is misleading and should be replaced by "input". Motorola reiterated that 3GPP should not make distinction between its Members and want this to be explicitly minuted. It was wondered if it would be appropriate to tell what company has voted for what, but this would make it too complex and all the information is available in the individual inputs.	Revised to S1-150328
070152r	7.1	S1-150225	US Department of Commerce (David Cypher)	Completion of application of S1-144278	22.179	0002r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150012	Agreed.
070153r	7.1	S1-150226	US Department of Commerce (David Cypher)	Clarification of number and types of Private Calls	22.179	0003r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150013	Agreed.
999999	S1-150227	Not allocated	Not allocated
070155r	7.1	S1-150228	US Department of Commerce	Completion of application of S1-144570	22.179	0005r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150015	Agreed.
070157r	7.1	S1-150229	Alcatel-Lucent	Clarifying KPI requirement	22.179	0008r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150018	Agreed.
070159r	7.1	S1-150230	Alcatel-Lucent, US Dept. Of Commerce	Correct use of MCPTT terminology	22.179	0007r2	D	13.0.1	Rel-13	MCPTT	Revision of S1-150185	Agreed.
070163r	7.1	S1-150231	Alcatel-Lucent, US Department of Commerce, UK HO	Correction of type of Private Calls supported in for both on and off the network use.	22.179	0014r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150024	The merging with the US Department of Commerce's contribution has been done, some other corrections performed.	Revised to S1-150342
070168r	7.1	S1-150232	US Department of Commerce (Bruce Ward)	Convert 2nd sentence of 5th requirement in clause 6.2.4 Call Termination into a new requirement	22.179	0019r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150029	Agreed.
070169r	7.1	S1-150233	US Department of Commerce (Bruce Ward)	Move two requirements from clause 6.1 General Administrative -groups and users into common clause 5.19 General Administrative -groups and users.	22.179	0020r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150030	The numbers should be indicated as "void" rather than deleted.	Revised to S1-150309
070170r	7.1	S1-150234	Ericsson, Motorola Solutions, Telecom Italia	Charging for MCPTT usage	22.179	0021r1	B	13.0.1	Rel-13	MCPTT	Revision of S1-150087	Agreed.
070188	7.1	S1-150235	Telecom Italia	MCPTT Core functions	Taken into account for the compilation document on MCPTT modules in S1-15224.
070174r	7.1	S1-150236	Home Office	CR- to clarify requirements in 6.4.9 and 6.2.4.	22.179	0026r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150103	The number of the Note 1 is missing. This will be added at CR implementation.	Agreed.
070111r	7.1	S1-150237	Ericsson	Mapping of MCPTT functional modules to TS 22.179 clauses –Proposed	Revision of S1-150203	Agreed.
050331rr	5.3	S1-150238	LG Electronics	Proposed study on LTE-based V2X	WID	Revision of S1-150209	One more supporting company.	Revised to S1-150259
050332r	5.3	S1-150239	LG Electronics	Proposed Skeleton for V2X TR	Revision of S1-150055	Agreed as a basis for future contributions.
050333r	5.3	S1-150240	LG Electronics	Proposed Text for Overview Section for V2X TR	Revision of S1-150057	Agreed.
050334r	5.3	S1-150241	LG Electronics	Definitions and abbreviations for V2X TR	Revision of S1-150056	Agreed.
050336r	5.3	S1-150242	QUALCOMM Incorporated, LG Electronics Inc	V2X Use Case – Forward Collision Warning	Revision of S1-150117. The merging of the two original contributions has been performed. The concept of "V2X-enabled Vehicular UE" is added and defined.	Ericsson prefers to simply call it a "UE": this will avoid to have to change all specifications. This "mistake" has been made for ProSe and MCPTT but should not be continued. Telecom Italia and the Chair support this view. Qualcomm does not disagree but still find that there is a need to distinguished the different types of UEs in some context: a "normal" handheld UE being carried in the pocket of a passenger is different from the "V2X-enabled Vehicular UE". For KPN, there is indeed a need to distinguish them. As a compromise, an editor's note is added to state that it is FFS if there is a need to introduce the concept of VUE (V2X-enabled Vehicular UE). Another editor's note is added to state that the anti-collision application is outside of 3GPP.	Revised to S1-150285
050337r	5.3	S1-150243	QUALCOMM Incorporated, LG Electronics Inc	V2X Use Case – Control Loss Warning	Revision of S1-150118	This is further edited while projecting. In points 3 to 6, "V2V Service" is not clearly defined and has to be replaced by something else. "E-UTRAN" is proposed, but this should work even when there is no network coverage. An editor's note is added to reflect this problem.	Revised to S1-150287
050338r	5.3	S1-150244	Huawei, Hisilicon	V2V Use case for emergency vehicle warning	pCR	Revision of S1-150181	There are still several TBD values to be provided at future meetings. For the relative speed between vehicle, the value Qualcomm has in mind about 200 km/h. They will bring contribution on this topic at the next meeting.	Agreed.
050339r	5.3	S1-150245	Huawei, Hisilicon	V2V Use case for Emergency vehicle stop	pCR	Revision of S1-150182	Agreed.
050341r	5.3	S1-150246	QUALCOMM Incorporated	V2X Use Case – Cooperative Adaptive Cruise Control and Platooning	Revision of S1-150120	This was edited while projecting for improvements.	Revised to S1-150330
050351r	5.3	S1-150247	Ericsson LM	V2V ProSe requirements	Revision of S1-150090	Revised to S1-150282
050402r	5.4	S1-150248	China Unicom, China Telecom, Telefonica, Huawei, ZTE, CATR, ITRI, Intel, Nokia Networks, CHTTL, III	New Study on Service Level Requirements for EPC in Virtualised Implementations (FS_SREVI)	WID	Revision of S1-150206	BT has a fundamental objection about the objective as presently written, which is against the NFV concept: NFV has to be transparent. Also for Cisco, the future networks will be a mix between virtual and non-virtual, so having service/requirements specific to one or the other would not make sense. China Unicom would like to launch the study to investigate if there would be service impacts or not. Also for Ericsson, this study is to check what the potential impacts are, so it should not be stopped. For some companies, this could be handle under the SMARTER work item. For Intel, this is just a study and there is no "pressure". For the chair, there is no consensus so this Study should just be "noted." China Unicom still wish to try in a revised version.	Revised to S1-150302
080303	8.3	S1-150249	China Unicom	Considerations on Congestion for eULRS	Revision of S1-150071. This pCR adds considerations on congestion in TR22.899.	For Cisco, the Core Network congestion is an unclear concept. It is explained to be an overload of the MME. "emergency service" has to be clarified: is it in the classical sense (use of PSAP, etc.) or is it meant "crisis call"? This is the later. Some other rewording should be performed for clarification. The first proposed requirement is not agreeable as such.	Revised to S1-150269
080302	8.3	S1-150250	China Unicom	Definitions and abbreviations	Revision of S1-150074. This pCR adds definitions and abbreviations in TR22.899 on Enhancements to User Location Reporting Support (eULRS.)	Agreed.
080304	8.3	S1-150251	China Unicom	Consolidated requirements for eULRS	Revision of S1-150072. This document provides consolidated potential requirements for TR 22.899	The 3rd requirement has to be reworded for clarification. Other changes to be provided off-line.	Revised to S1-150270
040105rr	4	S1-150252	S1/Intel	Proposed LS to SA6 (cc SA2) on answer on service continuity	LS draft	Revision of S1-150222. Proposed answer to LS S6-150100/S1-150191. Answers to the two SA6's questions are proposed: service continuity may not be possible. For private calls, service continuity is not required. Service continuity is desirable to the extent that service interruption is minimized.	Some rewording was performed while projecting, and the statement "For private calls, service continuity is not required" is deleted.	Revised to S1-150296
050202rr	5.2	S1-150253	VODAFONE Group Plc	New study item on New Services and Markets Technology Enablers - SMARTER	WID	Revision of S1-150211	BlackBerry is to be added as a supporting company.	Revised to S1-150300
080410	8.4	S1-150254	KDDI, TeliaSonera AB, Intel	Considerations on Relationship Between CATS and other Existing Access Controls	22.818	Revision of S1-150078. This pCR provides addresses consideration on relationship between FS_CATS and existing Access Controls.	Agreed.
050353r	5.3	S1-150255	Huawei, Hisilicon	V2I Use case for Emergency vehicle stop	pCR	Revision of S1-150183	Minor change added ("end-to-end" delay).	Revised to S1-150334
050354r	5.3	S1-150256	Huawei, Hisilicon	V2I with Service RSU	other	Revision of S1-150144	Qualcomm support the proposal but suggested some slight wording improvements while projecting.	Revised to S1-150335
080101r	8.1	S1-150257	Gemalto, Telecom Italia	APN provisioning based on UE bootstrap from UICC without an OMA DM-Server	Revision of S1-150036	Agreed.
080102r	8.1	S1-150258	Intel Corporation (UK) Ltd	Optional support of DM bootstrap function and reliance on OMA DM client	Revision of S1-150100	Agreed.
050331rrr	5.3	S1-150259	LG Electronics	Proposed study on LTE-based V2X	WID	Revision of S1-150238	Some more text from S1-150179 is proposed on the road authority aspects. Other aspects were edited while projecting.	Revised to S1-150284
080104r	8.1	S1-150260	Ericsson	Text for conclusion section	Revision of S1-150129	Was pre-Agreed but uploaded with wrong number.	Replaced by S1-150326
080106	S1-150261	Editor	TR 28.802	TR	This version includes the changes agreed at SA1#69.	Was pre-Agreed but uploaded with wrong number. It will not be presented for approval to SA at this stage (already presented for information previously).	Replaced by S1-150327
080204r	8.2	S1-150262	SPRINT Corporation	UC_SPOOF potential requirements	Revision of S1-150096	Agreed.
080206r	8.2	S1-150263	SPRINT Corporation	UC_SPOOF conclusions and recommendations	Revision of S1-150099	Agreed.
0802067	8.2	S1-150264	Editor	TR 22.898	TR	This version includes the changes agreed at SA1#69.	Agreed to be presented for approval.
070176r	7.1	S1-150265	Home Office	CR to clarify what call type refers to in 6.2.3.3.1	22.179	0028r1	F	13.0.1	Rel-13	MCPTT	Revision of S1-150105	Agreed.
050105rr	5.1	S1-150266	MINISTERE DE L'INTERIEUR	Data group communications	WID	Revision of S1-150197	Revised to S1-150276
050412r	5.4	S1-150267	KPN	New WID on Enhancements for Infrastructure based Communication between Devices (eICBD)	WID	Revision of S1-150204	No agreement as such. A new attempt is given by rewording the first bullet of the objective.	Revised to S1-150308
070185	7.1	S1-150268	Qualcomm	MCPTT specific non-Core functions	Taken into account for the compilation document on MCPTT modules in S1-15224.
080303r	8.3	S1-150269	China Unicom	Considerations on Congestion for eULRS	Revision of S1-150249	Agreed.
080304r	8.3	S1-150270	China Unicom	Consolidated requirements for eULRS	Revision of S1-150251	Agreed.
080305	8.3	S1-150271	Editor	TR 22.899 on Enhancements to User Location Reporting Support (eULRS.)	TR	This version includes the changes agreed at SA1#69.	Agreed to be presented for information.
080403r	8.4	S1-150272	Intel Corporation (UK) Ltd	P-CR to address Editor’s Note Regarding Implementation, Assumptions etc. in Potential Requirements in CATS TR 22.818	Revision of S1-150062. This pCR solves the editor’s notes that states: "Remove implementation and assumptions in requirements Inclusion of "MNO & 3rd Party agreement" in requirements needs further consideration".	Qualcomm supports this contribution. The terms "3GPP systems" and "3GPP networks" have to be aligned.	Revised to S1-150280
080103r	8.1	S1-150273	BlackBerry UK Limited	Updates to UICC based solutions for automotive cases	Revision of S1-150091	Agreed.
080406r	8.4	S1-150274	KDDI, Qualcomm Incorporated, TeliaSonera AB, Intel	Consideration on Security	22.818	Revision of S1-150077	Agreed.
050101rr	5.1	S1-150275	MINISTERE DE L'INTERIEUR	New Study on Mission Critical Video over LTE (FS_MCVideo)	WID	Revision of S1-150193. It is cleaned-up. The several fields of the objective are clarified.	The objective should be re-written to clarify it is a study. The Rapporteur contact has to be cleaned-up. For the US Department of Commerce, the handling of conflict/priority between video plus sound against video only has to be clarified. The French Ministry agrees but think that this will be covered in the actual study and does not have to be mentioned in the WID. The relationship with IOPS can also be clarified in Qualcomm's opinion: a bullet is added for "use of IOPS". The "data acknowledgement" can be deleted.	Revised to S1-150297
050105rrr	5.1	S1-150276	MINISTERE DE L'INTERIEUR	New study on Mission Critical Data Communications (FS_MCDATA)	WID	Revision of S1-150266. It is clarified that this is a study.	Same comment on the wording of the Objective. Motorola is also supporting. The clarification sentence below the time scale can be rephrased and moved to the end of the Objective section. Some typos to be corrected ("Complimentary", "defines", etc.).	Revised to S1-150298
050106rr	5.1	S1-150277	Applied Communication Sciences, OEC, AT&T, and Alcatel-Lucent	New WID for Multimedia Priority Service (MPS) Modifications (MPS_Mods)	WID	Revision of S1-150198.	"modifications" is an unusual term to refer to enhancements but there is no concern, so it is kept.	Agreed.
080407r	8.4	S1-150278	KDDI, TeliaSonera AB, Intel	Use case on relationship to Access Class 11-15	22.818	Revision of S1-150079	Agreed.
080408r	8.4	S1-150279	China Telecom	Charging between CATS activation and deactivation	Revision of S1-150135	Some rewording performed while projecting.	Revised to S1-150343
080403rr	8.4	S1-150280	Intel Corporation (UK) Ltd	P-CR to address Editor’s Note Regarding Implementation, Assumptions etc. in Potential Requirements in CATS TR 22.818	Revision of S1-150272	Agreed.
080410	8.4.	S1-150281	Editor	CATS TR 22.818	TR	This version includes the changes agreed at SA1#69.	Agreed as a basis for future contributions.
050351rr	5.3	S1-150282	Ericsson LM	V2V ProSe requirements	Revision of S1-150247.	The terms "road safety" have to be replaced by something clearer.	Revised to S1-150291
050202,9	S1-150283	Vodafone	Timeline from the SMARTER SID	There is no consensus to present such a document.	Withdrawn.
050331rrrr	5.3	S1-150284	LG Electronics	Proposed study on LTE-based V2X	WID	Revision of S1-150259	Ericsson added as supporting company.	Agreed.
050336rr	5.3	S1-150285	QUALCOMM Incorporated, LG Electronics Inc	V2X Use Case – Forward Collision Warning	Revision of S1-150242	Agreed.
050398	5.3	S1-150286	Editor	V2V TR 22.7xy	TR	This version includes the changes agreed at SA1#69.	It was proposed to send an LS to different groups (ETSI ITS, etc.) to inform them about the 3GPP progress on V2X, but this was judged premature since the Work Item has not been officially approved. As a way out, the SA1 chairman will propose in her report to next SA meeting to make this LS as coming from SA, once the Work Item has been officially approved.	Agreed as a basis for future contribution.
050337rr	5.3	S1-150287	QUALCOMM Incorporated, LG Electronics Inc	V2X Use Case – Control Loss Warning	Revision of S1-150243	Agreed.
070183	7.1	S1-150288	MINISTERE DE L'INTERIEUR	MCPTT core items, France	Revision of S1-150208. Clarifications have been made all over the WID, in particular to the "Objective" section.	Taken into account for the compilation document on MCPTT modules in S1-15224.
050411r	5.4	S1-150289	China Mobile, Huawei, China Telecom, ZTE Corporation, CATT, CATR, SK Telecom	New SID on Mobile CDN (FS_MCDN)	WID	Revision of S1-150139	There is no agreement as it is. This might be due to the wording, so a new attempt will be made with a different wording.	Revised to S1-150307
050421	5.4	S1-150290	China Mobile	Study on enhancement to FMSS for Rel 14 (FS_eFMSS)	WID	The objective is to study use cases and propose potential requirements to enhance flexible mobile service steering developed in Rel-13.	Submitted after the deadline.	Noted, more to be brought at next meeting.
050351rrr	5.3	S1-150291	Ericsson LM	V2V ProSe requirements	Revision of S1-150282	Edited while projecting	Revised to S1-150333
050371r	5.3	S1-150292	LG Electronics	V2I Use case for Road safety services	Revision of S1-150059	Some more off-line work is needed before approval.	Revised to S1-150336
050372r	5.3	S1-150293	QUALCOMM Incorporated	V2X Use Case – Queue Warning	Revision of S1-150121	Revised to S1-150331
050331r	5.3	S1-150294	III	V2X Use Case: ProSe-based toll collection	Revision of S1-150031	The requirement is still not clearly understood.	Noted.
050374r	5.3	S1-150295	QUALCOMM Incorporated	V2X Use Case – Automated Parking System	Revision of S1-150123	The conclusion is that unicast is important to V2I	Revised to S1-150338
040105rrr	4	S1-150296	S1/Intel	Proposed LS to SA6 (cc SA2) on answer on service continuity	LS out	Revision of S1-150252	Approved.
050101rrr	5.1	S1-150297	MINISTERE DE L'INTERIEUR	New Study on Mission Critical Video over LTE (FS_MCVideo)	WID	Revision of S1-150275	Agreed.
050105rrrr	5.1	S1-150298	MINISTERE DE L'INTERIEUR	New study on Mission Critical Data Communications (FS_MCDATA)	WID	Revision of S1-150276	Agreed.
050107,2rr	5.1	S1-150299	SPRINT Corporation	Proposed new WID on Enhancing Location Capabilities for Indoor and Outdoor Emergency Communications (ELIOT)	WID	Revision of S1-150199	Agreed.
050202rrr	5.2	S1-150300	VODAFONE Group Plc	New study item on New Services and Markets Technology Enablers - SMARTER	WID	Revision of S1-150253	Agreed.
060001rrr	6	S1-150301	KPN	Alignment of ProSe communication charging data requirements	22.115	0077	A	13.2.0	Rel-13	ProSe	Agreed.
050402rr	5.4	S1-150302	China Unicom, China Telecom, Telefonica, Huawei, ZTE, CATR, ITRI, Intel, Nokia Networks, CHTTL, III	New Study on Service Level Requirements for EPC in Virtualised Implementations (FS_SREVI)	WID	Revision of S1-150248	The companies objecting with the previous version still object with this version. This work might be done in the NFV group rather than 3GPP.	Noted.
050408rr	5.4	S1-150303	China Unicom, TeliaSonera, ZTE, CATR, ITRI, CHTTL	New Study on Paging Policy Enhancements and Procedure Optimizations in LTE (PPEPO_LTE)	WID	Revision of S1-150216	Agreed.
070181	7.1	S1-150304	Huawei, TD-Tech	Core Modules for MCPTT	other	Revision of S1-150150	Taken into account for the compilation document on MCPTT modules in S1-15224.
050404rr	5.4	S1-150305	Huawei, Qualcomm	Study on 3GPP Enhancement for TV service	WID	Revision of S1-150215	EMVS to be added, spelling of "Nokia Networks" to be corrected.	Revised to S1-150339
050409rr	5.4	S1-150306	China Telecom	Study on Enhancements to Domain selection for VoLTE	WID	Revision of S1-150217	Agreed.
050411rr	5.4	S1-150307	China Mobile, Huawei, China Telecom, ZTE Corporation, CATT, CATR, SK Telecom	New SID on Mobile CDN (FS_MCDN)	WID	Revision of S1-150289	Cisco's concerns have not been solved. Several companies are still objection (Cisco, Vodafone, etc.)	Noted.
050412rr	5.4	S1-150308	KPN	New WID on Enhancements for Infrastructure based Communication between Devices (eICBD)	WID	Revision of S1-150267	For Telecom Italia, it is not very clear was the intention is. Telecom Italia and Cisco have concerns, in particular with the sentence "provide support for existing service discovery frameworks via the infrastructure; and"	Noted.
070169rr	7.1	S1-150309	US Department of Commerce (Bruce Ward)	Move two requirements from clause 6.1 General Administrative -groups and users into common clause 5.19 General Administrative -groups and users.	22.179	0020r2	F	13.0.1	Rel-13	MCPTT	Revision of S1-150233	Agreed.
090204	9.2	S1-150310	Rapporteur (Ericsson)	Password based service activation for IMS Multimedia Telephony service - status update	Is this a new WI? Yes Work Item Completion: 100%	Noted.
090205	9.2	S1-150311	Rapporteur (French Ministry of Interior)	Mission Critical Video over LTE - status update	Is this a new WI? Yes Work/Study Item Completion: 0% Draft <TS/TR> 22.xxx Completion: 0% Expected date to send <TR/TS> to SA plenary: For information: SA1#71 (08/2015) For approval: SA1#72 (11/2015)	Noted.
090206	9.2	S1-150312	Rapporteur (French Ministry of Interior)	Data group communications - status update	Is this a new WI? Yes Work/Study Item Completion: 0% Draft <TS/TR> 22.xxx Completion: 0% Expected date to send <TR/TS> to SA plenary: For information: SA1#71 (08/2015) For approval: SA1#72 (11/2015)	Noted.
090207	9.2	S1-150313	Rapporteur (Applied Communication Sciences)	MPS Updates - status update	Is this a new WI? <y> Work/Study Item Completion: 0% Target completion date in WID: <06/2016> SP#72	Noted.
090208	9.2	S1-150314	Rapporteur (Sprint)	Enhancing Location Capabilities for Emergency Communication - status update	Is this a new WI? Y Work/Study Item Completion: 0% Target completion date in WID: 12/2015 SP#70	Noted.
090214	9.2	S1-150315	Rapporteur (Vodafone)	New Services and Markets Technology Enablers – SMARTER - status update	Is this a new SI? Yes Work/Study Item Completion: 0% Draft TR 22.xxx Completion: 0% Target completion date in SID (Phase 1): 03/2016 SP#71	Noted.
090209	9.2	S1-150316	Rapporteur (LGE)	Study on LTE support for V2X services - status update	Is this a new WI? <y> Work/Study Item Completion: 20% Draft <TS/TR> 22.7xx Completion: 20% Target completion date in WID: <12/2015> SP#70	40% progress is proposed. 25% is agreed as a compromise.	Noted.
090210	9.2	S1-150317	Rapporteur (Huawei)	3GPP Enhancement for Video - status update	Is this a new WI? Yes (even if No is reported) Work Item Completion: 0% Target completion date in WID: SP#70	This a new WI even if "No" is reported.	Noted.
090211	9.2	S1-150318	Rapporteur (China Unicom)	Paging Policy Enhancements and Procedure Optimizations in LTE - status update	s this a new WI? Yes Work/Study Item Completion: 0% Target completion date in WID: <12/2015> SP#70	Noted.
090212	9.2	S1-150319	Rapporteur (China Telecom)	Enhancements to Domain selection for VoLTE (eDSVCC) - status update	Is this a new WI? Y Work/Study Item Completion: 0% Target completion date in WID: 06/2015 SP#68	Noted.
999999	9.2	S1-150320	Not allocated.	Not allocated.
999999	9.2	S1-150321	Not allocated.	Not allocated.
999999	9.2	S1-150322	Not allocated.	Not allocated.
999999	9.2	S1-150323	Not allocated.	Not allocated.
999999	9.2	S1-150324	Not allocated.	Not allocated.
999999	9.2	S1-150325	Not allocated.	Not allocated.
080104rr	8.1	S1-150326	Ericsson	Text for conclusion section	Replaces S1-150260	Agreed.
080106r	S1-150327	Editor	TR 28.802	TR	Replaces S1-150261	0 byte file.	Revised to S1-150347
070189r	7.1	S1-150328	SA1 Chairman	Result of the drafting on MCPTT modules	Revision of S1-150224	The Chair's intention is to present this as an attachment to an LS to be sent to SA2, AS6 and SA plenary.	Agreed.
070190	7.1	S1-150329	SA1 Chairman	Proposed LS to SA2, SA6 and SA (cc SA3) on priority for MCPTT modules	LS draft	It is proposed to answer that, at SA1#69, interested organisations selected MCPTT modules they considered necessary in order to provide a viable deployable MCPTT service.	This was slightly edited while projecting.	Revised to S1-150340
050341rr	5.3	S1-150330	QUALCOMM Incorporated	V2X Use Case – Cooperative Adaptive Cruise Control and Platooning	Revision of S1-150246	Agreed.
050372rr	5.3	S1-150331	QUALCOMM Incorporated	V2X Use Case – Queue Warning	Revision of S1-150293	All comments made at the meeting and off-line have been included. For Alcatel-Lucent, the requirements 4 to 8 do not apply to 3GPP. Qualcomm agree (editing issue while re-wording them). One is missing when changing to the new wording. V2X should be V2I in one instance.	Revised to S1-150337
0802067,2	8.2	S1-150332	Editor	Cover Page for 22.898	TR	Agreed.
050351rrrr	5.3	S1-150333	Ericsson LM	V2V ProSe requirements	Revision of S1-150291	Agreed.
050353rr	5.3	S1-150334	Huawei, Hisilicon	V2I Use case for Emergency vehicle stop	pCR	Revision of S1-150255	Agreed.
050354rr	5.3	S1-150335	Huawei, Hisilicon	V2I with Service RSU	other	Revision of S1-150256	There is no agreement on the types of V2X.	Noted.
050371rr	5.3	S1-150336	LG Electronics	V2I Use case for Road safety services	Revision of S1-150292	It is needed to align the requirements with the use cases, with respect to V2I in particular. The terminology problem for the "V2X-enabled UEs" is still not solved. It is left as such at this point and will have to be solved later. The one referring to Mbps is covered by another one and should be deleted.	Revised to S1-150345
050372rrr	5.3	S1-150337	QUALCOMM Incorporated	V2X Use Case – Queue Warning	Revision of S1-150331	Was agreed.	Revised to S1-150341
050374rr	5.3	S1-150338	QUALCOMM Incorporated	V2X Use Case – Automated Parking System	Revision of S1-150295	The last requirement ("The V2I Service shall support integrity and confidentiality protection of the transmission.") is on the service, but there is no control of the service. So it should be deleted.	Revised to S1-150346
050404rrr	5.4	S1-150339	Huawei, Qualcomm	Study on 3GPP Enhancement for TV service	WID	Revision of S1-150305	Agreed.
070190r	7.1	S1-150340	SA1 Chairman/SA1	Proposed LS to SA2, SA6 (cc SA3, SA) on priority for MCPTT modules	LS out	Revision of S1-150329	Agreed.
050372rrrr	5.3	S1-150341	QUALCOMM Incorporated	V2X Use Case – Queue Warning	Revision of S1-150337	Agreed.
070163rr	7.1	S1-150342	Alcatel-Lucent, US Department of Commerce, UK HO	Correction of type of Private Calls supported in for both on and off the network use.	22.179	0014r2	F	13.0.1	Rel-13	MCPTT	Revision of S1-150231	Agreed.
080408rr	8.4	S1-150343	China Telecom	Charging between CATS activation and deactivation	Revision of S1-150279	Agreed.
080305,2	8.3	S1-150344	Editor	Cover Page for TR 22.899	TR	Since it is presented only for information, items left for future work have to be listed.	Revised to S1-150348
050371rrr	5.3	S1-150345	LG Electronics	V2I Use case for Road safety services	Revision of S1-150336	Agreed.
050374rrr	5.3	S1-150346	QUALCOMM Incorporated	V2X Use Case – Automated Parking System	Revision of S1-150338	Agreed.
080106rr	S1-150347	Editor	TR 28.802	TR	Revision of S1-150327	Agreed as a basis for future contributions. It will not be presented for approval to SA at this stage (already presented for information previously).
080305,2r	8.3	S1-150348	Editor	Cover Page for TR 22.899	TR	Revision of S1-150344	Agreed.
S1-150349
010000	1	zAgItem	1 Opening of the meeting	zAgItem
010100	1.1	zAgItem	1.1 Agenda and scheduling	zAgItem
010200	1.2	zAgItem	1.2 IPR, antitrust and competition laws	zAgItem
010300	1.3	zAgItem	1.3 Previous SA1 meeting report	zAgItem
010400	1.4	zAgItem	1.4 Information for delegates	zAgItem
010500	1.5	zAgItem	1.5 Information for rapporteurs	zAgItem
010600	1.6	zAgItem	1.6 Working agreements	zAgItem
020000	2	zAgItem	2 Issues for early consideration	zAgItem
030000	3	zAgItem	3 Reports and action items	zAgItem
030100	3.1	zAgItem	3.1 Report from SA	zAgItem
040000	4	zAgItem	4 Liaison Statements (including related contributions)	zAgItem
050000	5	zAgItem	5 New Study and Work Items (including related contributions)	zAgItem
050100	5.1	zAgItem	5.1 Public Safety, Critical communications and regulatory requirements	zAgItem
050200	5.2	zAgItem	5.2 SMARTER	zAgItem
050300	5.3	ZAgItem	5.3 Vehicular communications	zAgItem
050400	5.4	ZAgItem	5.4 Other topics	zAgItem
060000	6	ZAgItem	6 Rel-12 and earlier contributions	zAgItem
070000	7	ZAgItem	7 Rel-13 Work Item contribution	zAgItem
070100	7.1	ZAgItem	7.1 MCPTT: Mission Critical Push To Talk over LTE [SP-140864]	zAgItem
070200	7.2	ZAgItem	7.2 GUSH: GERAN UTRAN Sharing Enhancements [SP-140637]	zAgItem
070300	7.3	ZAgItem	7.3 Other Rel-13 contributions	zAgItem
080000	8	ZAgItem	8 Study Item contributions	zAgItem
080100	8.1	ZAgItem	8.1 FS_MAPN: Need for multiple APNs [SP-130416]	zAgItem
080200	8.2	ZAgItem	8.2 FS_UC_SPOOF: Service aspects for dealing with User Control over spoofed calls [SP-140074]	zAgItem
080300	8.3	ZAgItem	8.3 FS_eULRS: Enhancements to User Location Reporting Support [SP-140402]	zAgItem
080400	8.4	ZAgItem	8.4 FS_CATS: Control of Applications when Third party Servers encounter difficulties [SP-140246]	zAgItem
080500	8.5	ZAgItem	8.5 Other Study Item contributions	zAgItem
090000	9	ZAgItem	9 Work planning contributions	zAgItem
090100	9.1	ZAgItem	9.1 Work Plan	zAgItem
090200	9.2	ZAgItem	9.2 Work Item/Study Item status update	zAgItem
090300	9.3	ZAgItem	9.3 SA1 process improvements/updates	zAgItem
090400	9.4	ZAgItem	9.4 Others	zAgItem
100000	10	ZAgItem	10 Next meetings	zAgItem
100100	10.1	ZAgItem	10.1 Calendar	zAgItem
110000	11	ZAgItem	11 Any other business	zAgItem
120000	12	ZAgItem	12 Close	zAgItem
130000	13	ZAgItem	13 Withdrawn documents (admin purposes only)	zAgItem
140000	14	ZAgItem	14 Document numbers to be allocated (admin purposes only)	zAgItem

Proposal: February: SA1#73: 22-26 Feb 2016: agreed to change it to 1-5 Feb: OK, to take place in Japan