TDoc list

Tdoc List

2016-11-19 01:16

Agenda	Topic	TDoc	Title	Source	Type	For	Avail	Treated	Decision	Wdrn	Replaced-by	Replaces
1	Opening of the meeting (Monday 9:00)
2	Reminder
2.1	IPR declaration
2.2	Statement of antitrust compliance
2.3	Responsible IT behavior
2.4	Additional reminder
3	Approval of the Agenda	R3‑162650	RAN3-94 meeting agenda	MCC	agenda	Approval	Yes	YesEricsson: minimize come backs on Thu night which will be available just on Fri RAN3 chair: if really no choice you can send out the Tdoc via the reflector	approved	No
4	Approval of the minutes from previous meetings	R3‑162651	Draft RAN3-93 Bis meeting report	MCC	report	Approval	Yes	Yes	revised	No	R3‑163078
		R3‑163078	Draft RAN3-93 Bis meeting report	MCC	report	Approval	Yes	Yes	revised	No	R3‑163083	R3‑162651
		R3‑163083	RAN3-93 Bis meeting report	MCC	report	Approval	No	Yes	approved	No		R3‑163078
5	Documents for immediate consideration
6	Organizational topics
7	General, protocol principles and issue
8	Incoming LSs
8.1	New Incoming LSs	R3‑163059	LS on UE demodulation performance enhancement indicator for SFN scenarios (To: 3GPP RAN2, CC: 3GPP RAN3)	3GPP RAN4, Huawei	LS in		Yes	Yesconclusion: no LS answer to RAN4	noted	No
8.2	Left over LSs/ pending actions
8.3	Progress on Security for LWIP	R3‑162805	Changes needed to enable LWIP over Xw	Nokia, Alcatel-Lucent Shanghai Bell	discussion		Yes	Yesproposed to agree that the Xw shall provide support for LWIP, too Intel: we have different views on this, have an own Tdoc in R3-162783	noted	No
		R3‑162783	Enhanced LWIP network interface	Intel Corporation, Qualcomm Incorporated, Mediatek Inc., China Telecom	discussion	Decision	Yes	Yesmoved from AI 14 to AI 8.3 Proposal 1: The interface to be defined for eLWIP shall be terminated at the LWIP-SeGW. Proposal 2: based on the observations above illustrating numerous differences in LWA and LWIP user plane, it is proposed to define separate user plane interfaces, i.e. not to re-use Xw for eLWIP. Proposal 3: based on considerations similar to the ones elaborated on for user plane, we propose to define separate control plane interfaces and protocols for LWA and LWIP, which allow all possible LWA and LWIP deployment options. Nokia: LS is forcing us to change the architecture Intel: does not agree, LS does not request an architecture change RAN3 chair: discuss this over the coffee break (Wed morning) after offline discussion: Nokia: WI not implementable or 2 different options Ericsson: reuse Xw (Nokia) or develop a new interface (Intel/Qualcomm) are the 2 options; maybe reusing Xw but adding a new procedure could be a compromise Intel: is not really a compromise RAN3 chair: show of hands: who prefers to reuse Xw : 7 companies, who prefers new interface: 4 companies; can we take a working assumption to reuse Xw? Intel: no, would violate WI description (LWIP architecture shall not be changed) Nokia: architecture is changed due to SA2 LS and not via the WI RAN3 chair: we confirmed already: no interface to security gateway ATT: would really get this problem solved, both solutions will work, supports Xw extension RAN3 chair: so can we extend Xw? Qualcomm: these are independent interfaces, we did not reuse X2 for Xw etc. RAN3 chair: we could bring two sets of CRs to RAN #75; understood that LS was considered to be higher priority conclusion: further offline discussion needed in order to converge (ATT)	noted	No
		R3‑162967	Extending XwAP for eLWIP	Ericsson LM	discussion		Yes	YesProposal 1: All information required to be exchanged between the eNB and the LWIP-SeGW is UE-associated and is orthogonal to existing information currently exchanged for LWA. Proposal 2: No non-UE-associated information seems to be strictly needed for LWIP; this would be true also in case a new interface was to be specified for LWIP. Proposal 3: The current WT-Initiated WT Modification procedure can be used to e.g. request a change of UP TNL address from the WT. Proposal 4: In case the WT supports LWA only, LWIP only, or both and, the current Xw Setup can be reused without changes. Proposal 5: RAN3 should discuss the options for Xw Setup and agree on the most suitable way forward. Proposal 6: In case no BSSIDs were signaled at Xw Setup, WT resource status reporting cannot be used; however, this is an issue also with current LWA. Proposal 7: Reuse the current WT Release procedures for LWIP. Proposal 8: In case the WT supports LWA but not LWIP, it shall fail LWIP Addition Preparation; in case the WT supports LWIP but not LWA, it shall fail WT Addition Preparation. Proposal 9: If the WT supports both LWA and LWIP and it receives an LWIP ADDITION REQUEST message concerning a UE for which LWA is ongoing, it shall fail that procedure, and vice versa. Proposal 10: Discuss and agree the CRs in [5] and [6]. Intel: Xw setup can be reused is contradicting other parts of the proposal Intel: currently each AP supports LWIP REL-13, this will not be the case in REL-14 Nokia: but this is affecting measurements only Broadcom: there is no REL-14 LWIP requirements Intel: measurements and flow control of the WID is not affecting APs? Nokia: flow control is terminated somewhere else but not in AP, only measurements are to be looked at	noted	No
		R3‑162968	Supporting LWIP with XwAP - New Procedure Descriptions	Ericsson LM	draftCR		Yes	YesIntel: is a tiny portion only, their is practically no solution Nokia: aspects of our R3-162806 can cover missing parts Intel: one pipe only, everything is hidden in this pipe Nokia: single IPsec tunnel contains multiple bearers, separate eRABs would be possible and more future proof Broadcom: traffic differentiation was heavily discussed in SA2 and is not RAN3 focus	revised	No	R3‑163146
		R3‑163146	Supporting LWIP with XwAP - New Procedure Descriptions	Nokia, Ericsson LM	draftCR	-	Yes	Yes	postponed	No		R3‑162968
		R3‑162972	LWIP Addition and Modification	Ericsson LM	CR	Agreement	Yes	YesEricsson: CR has an error so focus on addition for the moment	revised	No	R3‑163147
		R3‑163147	LWIP Addition and Modification	Ericsson LM	CR	Agreement	Yes	Yes	postponed	No		R3‑162972
		R3‑162806	Enabling LWIP support over Xw	Nokia, Alcatel-Lucent Shanghai Bell	draftCR		Yes	Yesaspects can be considered in a revision of R3-162968 (if needed)	withdrawn	Yes
		R3‑162807	Enabling LWIP support over Xw	Nokia, Alcatel-Lucent Shanghai Bell	draftCR		Yes	Yes	withdrawn	Yes
		R3‑162808	Enabling LWIP support over Xw	Nokia, Alcatel-Lucent Shanghai Bell	draftCR		Yes	YesRAN3 chair: fits to Ericsson's CRs? Nokia: yes	revised	No	R3‑163148
		R3‑163148	Enabling LWIP support over Xw	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	-	Yes	YesRAN3 chair: for next meeting supporting companies should co-sign the CRs	postponed	No		R3‑162808
		R3‑162809	Enabling LWIP support over Xw	Nokia, Alcatel-Lucent Shanghai Bell	draftCR		Yes	YesRAN3 chair: fits to Ericsson's CRs? Nokia: yes	revised	No	R3‑163149
		R3‑163149	Enabling LWIP support over Xw	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	-	Yes	Yes	postponed	No		R3‑162809
		R3‑163150	Review of solution Enabling LWIP support over Xw	Intel Corporation, Qualcomm Incorporated, Mediatek Inc., China Telecom, Brocade	discussion	discussion	Yes	YesEricsson: why saying same thing twice in 1 and 6? Intel: clear stage 2 spec needed Broadcom: first 3 points: do we discuss instances of the protocol or the protocol? Intel: IPSec remains IPSec ATT: some APs are under operator control and some not Intel: some cases where control is limited Nokia: point 2: eNB must know all SSIDs Intel: eNB must know this Nokia: so REL-13 does not work? interprets Intel's answers as in REL-13 it does not work and in REL-14 it may work with Intel solution Intel: less OM burden for our solution Broadcom: point 4: quantitative assumption which is not qualified Intel: in REL-13 Broadcome was worried about LWA per bearer flow control is difficult to introduce RAN3 chair: Xw proponents have to update their CRs for next RAN3 meeting and should also have a response to this document	noted	No
		R3‑163031	eLWIP: Xs stage-2 proposal for TS 36.300	Intel Corporation, Qualcomm Incorporated	draftCR	Decision	Yes	Yesmoved from AI 14 to AI 8.3; MCC: wrong Tdoc type discussion in Tdoc request Broadcom: joint inputs in SA2/SA3 about traffic separation via IPsec tunnel Nokia: where is the measurement procedure? Qualcomm: not yet included Nokia: but inconsistent to UP CRs Intel: separate specs is cleaner, so that we see which identifier apply to which case Broadcom: IPsec is IP level protocol, no impact on WLAN IP Qualcomm: AP IDs need to be on the table	revised	No	R3‑163151
		R3‑163151	eLWIP: Xs stage-2 proposal for TS 36.300	Intel Corporation, Qualcomm Incorporated	draftCR	Decision	Yes	Yes	postponed	No		R3‑163031
		R3‑162784	eLWIP: Xs user plane protocol	Intel Corporation, Qualcomm Incorporated	discussion	Decision	Yes	Yesmoved from AI 14 to AI 8.3	revised	No	R3‑163152
		R3‑163152	eLWIP: Xs user plane protocol	Intel Corporation, Qualcomm Incorporated	discussion	Decision	Yes	Yes	postponed	No		R3‑162784
		R3‑162785	eLWIP: Xs data transport	Intel Corporation, Qualcomm Incorporated	discussion	Decision	Yes	Yesmoved from AI 14 to AI 8.3	revised	No	R3‑163153
		R3‑163153	eLWIP: Xs data transport	Intel Corporation, Qualcomm Incorporated	discussion	Decision	Yes	Yes	postponed	No		R3‑162785
		R3‑163032	eLWIP: Xs Application Protocol	Intel Corporation, Qualcomm Incorporated	discussion	Decision	Yes	Yesmoved from AI 14 to AI 8.3	revised	No	R3‑163154
		R3‑163154	eLWIP: Xs Application Protocol	Intel Corporation, Qualcomm Incorporated	discussion	Decision	Yes	Yes	postponed	No		R3‑163032
		R3‑163001	Information transfer between eNB, WT and UE for LWIP	Ericsson	discussion		Yes	Yes	not treated	No
		R3‑163155	Review of solution new Xs interface for eLWIP	Nokia	discussion	discussion	Yes	YesRAN3 chair: for both review papers (R3-163155, R3-163150) separate technical concerns regarding the CRs from general concerns as we may have to send 2 sets of CRs to RAN #75 in case offline discussion from ATT (to come to one joint input) does not converge Intel: why do the interface have so big problems? Ericsson: from same node to same node Broadcom: 2 different protocol stacks for the same interface Nokia: for LWA and LWIP procedures to be used were listed RAN3 chair: Xs proponents have to update their CRs for next RAN3 meeting and should also have a response to this document	noted	No
		R3‑163156	Way forward on WI LTE_WLAN_eLWIP-Core	Nokia	discussion	discussion	Yes	YesIntel: would like to see it before it is submitted Intel: show of hands was rather equal conclusion: remove sentence about show of hands	revised	No	R3‑163258
		R3‑163258	Way forward on WI LTE_WLAN_eLWIP-Core	Nokia	discussion	discussion	No	Yes	noted	No		R3‑163156
9	Corrections to Rel-13 or earlier releases
9.1	3G
9.2	LTE	R3‑162749	Introduction of solution to solve CSFB setup delay problem	Samsung, China Telecom, Nokia, Alcatel-Lucent Shanghai Bell, Deutsche Telekom, ZTE, CMCC	draftCR	Approval	Yes	YesCATT: in UE context wording should be changed? to radio link failure indication? Samsung: no, is related to UE context Ericsson: it was unclear last time already what is intended to be achieved with this draft CR; suggests some rewording at least: "whether to trigger HO procedure depends on a number of factors, e.g. ..." RAN3 chair: would the rewording be acceptable for Samsung? Samsung: ok Nokia: should it not be in normative text? Ericsson: no, since we are describing rather an implementation Samsung: previous text is in the same context Ericsson: but the next text was not agreed, so the compromise was a note conclusion: note will be reworded; "When triggering the HO preparation procedure the previously serving eNB may take into account a number of factors, e.g. ..."	revised	No	R3‑163084
		R3‑163084	Introduction of solution to solve CSFB setup delay problem	Samsung, China Telecom, Nokia, Alcatel-Lucent Shanghai Bell, Deutsche Telekom, ZTE, CMCC	draftCR	Approval	Yes	Yesconclusion: draftCR will be provided to RAN2 via MCC so that RAN2 can agree the CR and submit it to RAN #74	endorsed	No	R3‑163089	R3‑162749
		R3‑163089	Introduction of solution to solve CSFB setup delay problem	Samsung, China Telecom, Nokia, Alcatel-Lucent Shanghai Bell, Deutsche Telekom, ZTE, CMCC	draftCR	Approval	Yes	No	available	No		R3‑163084
		R3‑162775	Target cell selection for eMTC UEs	Nokia, Alcatel-Lucent Shanghai Bell	discussion		Yes	Yes	noted	No
		R3‑162776	Target cell selection for low complexity UEs and UEs in enhanced coverage	Nokia, Alcatel-Lucent Shanghai Bell, AT&T, Samsung, LG Electronics Inc., Qualcomm Incorporated	CR	Agreement	Yes	YesMCC: LTE_MTCe2_L1-Core was a REL-13 WI; Huawei: all data can be configured via O&M, self-learning can work but we have an O&M solution that works Nokia: there is not one O&M, there are multiple and how to deal with this problem if the O&M situation is not that straight forward? Ericsson: O&M is of course possible, will be difficult to agree on something in the discussion paper but we should definitely not rule out an O&M solution; how often will such an information change? if not less than 12 hours you can probably live with this situation RAN3 chair: so what do we do with the CRs? Nokia: understands O&M may be possible but tedious so can we still have something in addition? AT&T: suggests to have more operator support and come back at the end of the week Ericsson: has nothing against the CR but we need to make sure that this does not rule O&M Huawei: REL needs to be discussed and how do we cover that O&M is possible Ericsson: Protocol IE ID is 180 conclusion: O&M approach is possible, REL-14 is preferred, text in the revised CR can be discussed further offline	rejected	No		R3‑162600
		R3‑162777	Target cell selection for low complexity UEs and UEs in enhanced coverage	Nokia, Alcatel-Lucent Shanghai Bell, AT&T, Samsung, LG Electronics Inc., Qualcomm Incorporated	CR	Agreement	Yes	YesMCC: LTE_MTCe2_L1-Core was a REL-13 WI	revised	No	R3‑163085	R3‑162601
		R3‑163085	Target cell selection for low complexity UEs and UEs in enhanced coverage	Nokia, Alcatel-Lucent Shanghai Bell, AT&T, Samsung, LG Electronics Inc., Qualcomm Incorporated	CR	Agreement	Yes	Yes	agreed	No		R3‑162777
		R3‑162836	Resolving ambiguity of counting procedures when receiving eMBMS on SCell or non-serving cell	Qualcomm Incorporated	discussion	Decision	Yes	YesMCC: MBMS_LTE_enh-Core was a REL-10 WI	noted	No
		R3‑162837	Resolving ambiguous counting responses	Qualcomm Incorporated	draftCR	Approval	Yes	YesMCC: MBMS_LTE_enh-Core was a REL-10 WI; wrong WI code on CR cover; cat.A CR missing; Ericsson: had a hard time to understand this problem; why would I count UEs that are outside of the MBSFN area? Qualcomm: different set of counting areas; UE is listening to a service of a different eNB but UE will still respond to a counting request in the serving cell and this is what we need to solve; Nokia: option 2a: why does it not work? Qualcomm: if more than one counting process is going on and the eNB does not know this Ericsson: thinks we are trying to address a corner case; and we are trying to shift the burden here to the eNB; Qualcomm: does not agree this is a corner case, it is supported by the system and so we need to look at the implications; burden on eNB is not increased much; RAN3 chair: counting is not accurate anyway and we try to improve it here so we have to see the pain vs. gain for this change; RAN3 chair: also REL needs to be discussed (maybe just for REL-14) conclusion: further offline discussion needed to convince other companies, can come back to it	postponed	No
		R3‑163226	Summary of Counting offline discussion	Qualcomm	discussion	discussion	Yes	YesRAN3 chair: no CRs this meeting? Qualcomm: yes, intended to bring them at the next meeting Huawei, Ericsson: want to check further conclusion: discuss offline until next meeting	noted	No
		R3‑162838	Resolving ambiguous counting responses	Qualcomm Incorporated	CR	Agreement	Yes	NoMCC: MBMS_LTE_enh-Core was a REL-10 WI; wrong WI code on CR cover	available	No
		R3‑162933	Correction of eDRX Information	Nokia, Alcatel-Lucent Shanghai Bell, Qualcomm, Huawei, NTT Docomo Inc	discussion	Decision	Yes	Yes	noted	No
		R3‑162934	Correction of eDRX Information	Nokia, Alcatel-Lucent Shanghai Bell, Qualcomm, Huawei, NTT Docomo Inc	draftCR	Approval	Yes	YesNEC: mentioned last time that there can be the case that IMSI is used for paging and restoration needed in core network Nokia: MME will include IMSI without eDRX configuration; NEC: worried that it may exclude other cases RAN3 chair: how do you reach the UE which is in DRX? Ericsson: this was mentioned in the LS, this means UE needs to be active to connect the network; NEC: that may take months Nokia: agrees with Ericsson, this was mentioned in a RAN2 document Ericsson: network vendors/operators know that this is a problem RAN3 chair: a good implementation will backup the MME configuration, particulary for eDRX Nokia: has no problem to send an LS NEC: we can check offline first with CT1/CT4; rewording? conclusion: MME restoration case to be checked with CT (Nokia), only IMSI available?	revised	No	R3‑163194
		R3‑163206	Correction of eDRX Information	Nokia	CR	discussion	Yes	YesNokia: without the CR this would also not be aligned with CT4 Ericsson: would UE listen to S-TMSI or just to IMSI? Nokia: some implementation may only use IMSI based paging Ericsson: but then it should be possible to include paging identity Ericsson: SA3 may be worried to see so many IMSI in clear text on the air interface NEC: no problem due to MME restoration Ericsson: SA3 may answer that this is an MME optimisation and security is more important Ericsson: can confirm that the CR is technically correct, restoration procedure exists already for a longer time NEC: if REL-13 using UE ID and CR is only for REL-14 and using S-TMSI then we will have a backward compatibility issue; so suggests REL-13 & REL-14 CR Ericsson: suggests to check this until next meeting conclusion: postponed until next RAN3 meeting	postponed	No
		R3‑163207	Correction of eDRX Information	Nokia	CR	discussion	Yes	Yes	postponed	No
		R3‑163208	LS on eDRX Configuration and restoration (to: CT4; cc: -; contact: Nokia)	Nokia	LS out	Approval	Yes	Yes	postponed	No
		R3‑163194	Correction of eDRX Information	Nokia, Alcatel-Lucent Shanghai Bell, Qualcomm, Huawei, NTT Docomo Inc	draftCR	Approval	Yes	YesNokia: MME can not do an IMSI based paging if it does not have S-TMSI conclusion: endorsed by RAN3, to be sent to RAN2 for agreement	endorsed	No		R3‑162934
		R3‑162935	Correction of eDRX Information	Nokia, Alcatel-Lucent Shanghai Bell, Qualcomm, Huawei, NTT Docomo Inc	draftCR	Approval	Yes	Yesconclusion: MME restoration case to be checked with CT (Nokia)	revised	No	R3‑163195
		R3‑163195	Correction of eDRX Information	Nokia, Alcatel-Lucent Shanghai Bell, Qualcomm, Huawei, NTT Docomo Inc	draftCR	Approval	Yes	Yesconclusion: endorsed by RAN3, to be sent to RAN2 for agreement	endorsed	No		R3‑162935
		R3‑163225	Way forward on eDRX	Nokia	discussion	discussion	Yes	YesProposal 1: In case MME initiates the paging procedure with eDRX configuration it shall include the S-TMSI in the PAGING message Proposal 2: RAN2 recent eDRX CR makes RAN3 specifications not compliant with CT4 specifications and requirements if RAN3 does not add the S-TMSI in an IMSI-bsed PAGING message. Proposal 3: RAN3 to select one of the two options above and agree the corresponding CRs. Ericsson: had not time to look at this last minute way forward Nokia: we discussed it by email RAN3 chair: is there an urgency for this feature? conclusion: proposal 1 is agreed and reflected in stage 2 CRs R3-163194 and R3-163195	noted	No
10	Study on Next Generation New Radio Access Technology (RAN1-led) SI	R3‑163040	Update to NGMN Description of Network Slicing Concept (To: 3GPP TSG SA WG2, 3GPP TSG SA WG5, TSG RAN3, ETSI NFV, CC: 3GPP TSG SA, 3GPP SA1, 3GPP TSG RAN)	NGMN, Orange	LS in		Yes	Yesconclusion: no LS answer to NGMN	noted	No
		R3‑163041	NGMN Paper on Edge Computing (To: 3GPP TSG SA WG2, CC: 3GPP TSG SA, 3GPP SA1, 3GPP TSG RAN, 3GPP RAN3, ETSI ISG MEC, Broadband Forum, Wireless Broadband Alliance, IEEE LAN/MAN)	NGMN, Orange	LS in		Yes	Yesconclusion: no LS answer to NGMN	noted	No
		R3‑163044	Liaison about ETSI ISG NGP (Next Generation protocols) (To: 3GPP TSG-SA, 3GPP TSG-RAN, 3GPP TSG-CT, 3GPP SA1, 3GPP SA2, 3GPP RAN3 )	ETSI ISG NGP, Huawei	LS in		Yes	YesRAN3 chair: assumes no action for RAN3 at the moment conclusion: no LS answer to ETSI ISG NGP	noted	No
		R3‑163056	LS on RAN2 agreements for NR DL-based mobility and Cell definition (To: 3GPP RAN1, CC: 3GPP RAN3, 3GPP RAN4)	3GPP RAN2, Ericsson	LS in		Yes	Yesconclusion: no LS answer to RAN2	noted	No
		R3‑163062	LS on migration from LTE/EPC including Option 3 to NextGen System (To: 3GPP RAN2, 3GPP RAN3, 3GPP TSG RAN, CC: 3GPP TSG SA, 3GPP TSG CT)	3GPP SA2, Qualcomm	LS in		Yes	YesRAN3 chair: we will take this into accout conclusion: no LS answer to SA2	noted	No
		R3‑163063	LS on NextGen QoS interim agreements (To: 3GPP RAN2, 3GPP RAN3, CC: 3GPP RAN1)	3GPP SA2, Intel	LS in		Yes	Yesconclusion: no LS answer to SA2	noted	No
		R3‑163064	LS on ""Next Generation"" Security Requirements (To: 3GPP SA2, 3GPP SA3 , CC: 3GPP TSG SA, 3GPP TSG CT, 3GPP TSG RAN, 3GPP RAN3)	3GPP SA3-LI, BT Group	LS in		Yes	Yespresented by RAN3 chairman conclusion: no LS answer to SA3-LI	noted	No
		R3‑163127	Reply LS to R2-167313 on RAN2 agreements for NR DL-based mobility and cell definition (R1-1613348; to: RAN2; cc: RAN3, RAN4; contact: Samsung)	RAN1	LS in	discussion	Yes	Yesconclusion: no LS answer to RAN1	noted	No
		R3‑163216	Way forward on FS_NR_newRAT	NTT DOCOMO	discussion	discussion	Yes	No	available	No
10.1	General	R3‑162846	Questions to SA2 on Local Breakout	ZTE Corporation	discussion		No	No	withdrawn	Yes
		R3‑162859	Liaison out on NR for inter-WG dependent topics	NTT DOCOMO INC.	LS out	Approval	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request conclusion: included 3 LSout will be revised in R3-163103, R3-163104, R3-163105 (for review until Wed)	revised	No
		R3‑163103	[DRAFT[ LS on SA2 dependent issues for RAN3 study on New Radio (to: SA2; cc: RAN2; contact: NTT DOCOMO)	NTT DOCOMO	LS out	Approval	Yes	YesRAN3 chair: will come back on Wed Nokia: to Q4: single radio/single attach was decided in SA2, do we need this question?	revised	No	R3‑163159
		R3‑163159	LS on SA2 dependent issues for RAN3 study on New Radio (to: SA2; cc: RAN2; contact: NTT DOCOMO)	RAN3	LS out	Approval	Yes	YesLS was sent out on Wed of RAN3 #94	approved	No		R3‑163103
		R3‑163104	DRAFT LS on Network slicing and QoS for New Radio (to: SA2, RAN2; cc: -; contact: Ericsson)	Ericsson	LS out	Approval	Yes	YesRAN3 chair: will come back on Wed NEC: not all slices are alignable in all nodes, so suggests to keep question 2 and reply to it CMCC: question 9 was removed? Nokia: supports NEC, we should rather ask more than less questions RAN3 chair: who has a problem with question 2? Nokia: since it only Ericsson has the problem with question 2 but the majority want to have clarification, we should restore the question Nokia: Why were Q18 and Q19 removed? NEC: a lot of questions were removed, we wanted to reword but now the questions are removed conclusion: Q2 will be restored, further offline discussion needed	revised	No	R3‑163160
		R3‑163160	DRAFT LS on Network slicing and QoS for New Radio (to: SA2, RAN2; cc: -; contact: Ericsson)	Ericsson	LS out	Approval	Yes	YesHuawei: Q10 is for RAN2 or SA2? Ericsson: Q10 was for SA2 Samsung: Q5 is for SA2 and RAN2? Ericsson: Q4 is for SA2 CATT: Where is the ffs related to Q3? conclusion: Q4/5/10 for SA2; remove "section 8 has the following ffs" RAN3 chair: will ask for joint session for Jan. with RAN2/SA2	revised	No	R3‑163166	R3‑163104
		R3‑163166	LS on Network slicing and QoS for New Radio (to: SA2, RAN2; cc: -; contact: Ericsson)	RAN3	LS out	Approval	Yes	Yesrevised as it still says "Draft" in the title	revised	No	R3‑163167	R3‑163160
		R3‑163167	LS on Network slicing and QoS for New Radio (to: SA2, RAN2; cc: -; contact: Ericsson)	RAN3	LS out	Approval	Yes	YesLS was sent out on Wed of RAN3 #94	approved	No		R3‑163166
		R3‑163105	[DRAFT LS on RAN2 dependent issues for RAN3 study on New Radio (to: RAN2, SA2; cc: -; contact: Qualcomm)	Qualcomm	LS out	Approval	Yes	YesRAN3 chair: will come back on Wed; question on idle mode mobility will be for SA2 Samsung: Q9: b./c. not yet decided in RAN3 so should be questions Ericsson: we wait for input on light connection and 5G and we can indicate this Nokia: "inactive state" is used in 4G and 5G RAN3 chair: but what core network in 5G means by inactive state is completely different from light connected Huawei: we could address the question 9 just to RAN2 Huawei: Did we ask Q4 already in the LS from NTT DOCOMO? RAN3 chair: seems yes, but on purpose, so leave question only for RAN2 Samsung: but it says dependent on SA2 so we can remove Q4 RAN3 chair: ok, remove Q4 CATT: want to remove "RAN3 has captured multi-connectivity in section 6.1 of TR 38.801 v0.6.1." above Q8 as it is misleading RAN3 chair: ok, remove it	revised	No	R3‑163161
		R3‑163161	LS on RAN2 dependent issues for RAN3 study on New Radio (to: RAN2, SA2; cc: -; contact: Qualcomm)	RAN3	LS out	Approval	Yes	YesLS was sent out on Wed of RAN3 #94	approved	No		R3‑163105
10.1.1	RAN3 TR 38.801	R3‑163034	Update of TR 38.801 (v061) on Study on New Radio Access Technology: Radio Access Architecture and Interfaces	NTT DOCOMO INC.	draft TR	Agreement	Yes	YesNTT DOCOMO: some cleanups compared to v0.6.0 conclusion: was agreed at the beginning of RAN3 #94 and later revised to include agreements of RAN3 #94	revised	No	R3‑163178
		R3‑163178	Update of TR 38.801 (v0.7.0) on Study on New Radio Access Technology: Radio Access Architecture and Interfaces	NTT DOCOMO INC.	draft TR	Agreement	No	No	reserved	No		R3‑163034
		R3‑162739	Mobility scenarios cleaning up	Samsung	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Ericsson: splitting mobility into 2 in eNB and gNB while procedures are the same is not needed (in fig.); paper mixes editorial and non-editorial changes RAN3 chair: will be difficult to solve this now, we anyway conclusion: revised to leave 10.2.1.1 unchanged	revised	No	R3‑163106
		R3‑163106	Mobility scenarios cleaning up	Samsung	pCR	Decision	Yes	Yes	agreed	No		R3‑162739
		R3‑162820	Corrections to TR 38.801	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Ericsson: section 5.5: 5G RAN/new RAN instead of shared RAN? Then 7.2.3 needs to be updated as well Nokia: we just used RAN there Ericsson: wherever "RAN" in 7.2.3 we should say "new RAN" conclusion: revised to review wording in the whole TR	revised	No	R3‑163107
		R3‑163107	Corrections to TR 38.801	Nokia, Alcatel-Lucent Shanghai Bell	pCR	-	Yes	Yes	agreed	No		R3‑162820
10.1.2	Objectives, Requirements and deployment scenarios	R3‑162843	Clarification on URLLC Requirement	ZTE Corporation	pCR		Yes	YesMCC: wrong Tdoc type in Tdoc request RAN3 chair: we need to focus on the architecture, it is more for RAN to clarify the delay requirements	rejected	No
10.2	Overall New RAN Architecture
10.2.1	RAN-CN functional split	R3‑162742	Correction for Multi-connectivity Function	Samsung	pCR	Decision	Yes	YesMCC: wrong Tdoc type in Tdoc request Nokia: this change is not needed as it is currently correct in the TR CATT: supports Nokia view Samsung: whether to extend dual connectivity to multiple connectivity is not yet decided in RAN2 RAN3 chair: agrees but we have multiple open issues pending RAN2 so we do not document all of these points Huawei: for multiple connectivity we will probably have a different approach than for dual connectivity Samsung: tight interworking is only in options ... ZTE: supports Samsung Ericsson: if everything is unclear for multi-connectivity then we can remove the whole multi-connectivity bullet and leave just the editor's note Nokia: would object to this as multi-connectivity is definitely considered by RAN2 Ericsson: is there a definition of multi-connectivity in the RAN2 TR already? RAN3 chair: it was clarified that dual connectiviy is covered by tight interworking Ericsson: should we capture multi-connectivity as a question in our LSs to RAN2? RAN3 chair: yes conclusion: revised in R3-163108 to have an editor's note that multi-connectivity is pending to RAN2 and remove the bullet "This function provides ..."; capture a question on multi-connectivity in LSout R3-163105	revised	No	R3‑163108
		R3‑163108	Correction for Multi-connectivity Function	Samsung	pCR	Decision	Yes	Yes	agreed	No		R3‑162742
		R3‑162778	Considerations on RAN functions	CATT,China Telecom	discussion	Decision	Yes	Yesmoved from AI 10.2.2 to AI 10.2.1 RAN3 chair: asks CATT to check with Qualcomm regarding the question that will be added to LSout R3-163105; relation to CU/DU is still open	noted	No
		R3‑162973	Scenarios for inter-RAT mobility	Ericsson	discussion		Yes	Yesmoved from AI 10.2.2 to AI 10.2.1 Proposal1: it is proposed to use the following terminology: Inter RAT handover: handover between LTE and NR with no changes of CN, i.e. intra NGCN Inter System handover: handover with a change of CN, namely between an EPC and a NGCN Proposal 2 Inter system handovers are suboptimal from a latency and complexity point of view and they are very signalling intensive. They imply high impacts on the LTE-EPC and the NGCN-NR systems. If the impacts are considered acceptable, inter system handovers may be supported in the NGCN -> EPC direction. RAN3 chair: what about proposal 1? Samsung: does not like this change, we need to inter RAT with CN change as well Ericsson: we need to clarify the terminology as it is confusing CATT: supports Samsung, inter-RAT handover with and without CN change is clear Qualcomm: supports inter-system handover but does not like the inter-RAT handover definition as it does not cover CN change Qualcomm: so you can have inter-RAT and inter-system? Ericsson: yes conclusion: terminology	noted	No
		R3‑162974	Scenarios for inter-RAT mobility	Ericsson	pCR		Yes	Yesmoved from AI 10.2.2 to AI 10.2.1 Nokia: is a resubmission of last meeting, we disagree with the changes (as explained last time) RAN3 chair: we have received an SA2 LS on this Nokia: yes, but these are interim agreements Samsung: as SA2 will make further progress this meeting we better wait with a RAN3 pCR conclusion: revised in R3-163109 to fix inter-RAT/system terminology, no change to CN mobility direction (pending to SA2)	revised	No	R3‑163109
		R3‑163109	Scenarios for inter-RAT mobility	Ericsson	pCR	-	Yes	Yes	agreed	No		R3‑162974
		R3‑162988	Inter-System and intra-system inter-RAT mobility	Ericsson	pCR		Yes	YesEricsson: R3-162988 is related to the terminology discussion moved from AI 10.6.2.2 to AI 10.2.1 Samsung: not in line with SA2 Ericsson: does not agree with Samsung, sees no relation RAN3 chair: at the moment we talk about RAN3 terminology MCC: pCRs should not use a CR cover sheet conclusion: aspects of R3-162988 may be merged into R3-163109 (discuss offline)	merged	No
10.2.2	RAN functions description	R3‑162845	Mobility scenarios for “inactive state”	ZTE Corporation	pCR		Yes	YesIntel: we agreed at last meeting that this Tdoc is pending on light connection RAN3 chair: fixed light connection and mobility input from RAN2 needed	postponed	No
		R3‑163029	NR inactive state principles - UE ID	Qualcomm Incorporated	discussion	Decision	Yes	YesProposal 1: A RAN controlled UE identity is used to identify a given UE in the RAN notification area. Proposal 2: The RAN node anchoring the NG-C/NG-U connection for the UE manages and assigns the UE identity. Proposal 3: RAN based RNTI shall be contained as UE-ID for RAN Notification Message. Proposal 4: The UE ID in context fetch and RRC_INACTIVE to RRC_CONNECTED transition shall be same as the RAN based RNTI in RAN based Notification Message. Proposal 5: Notification occasion (NR equivalent of LTE PO/PF) for RRC_INACTIVE is calculated in the same way as the one for NR RRC_IDLE to provide the same level of performance. Proposal 6: RAN can define RAN based Notification specific DRX cycle value for a RRC_INACTIVE state UE and configure it to UE by dedicated signalling. Proposal 7: gNB includes IMSI mod X and RRC_INACTIVE state DRX parameters in the RAN based notification message in Xn. RAN3 chair: also pending on light connection, inputs from other WGs needed or everything can change again; we have to complete light connection in REL-14 Qualcomm: assumes light connection is for REL-15 RAN3 chair: not at the moment, you are free to bring this up in RAN	postponed	No
		R3‑163030	NR inactive state principles - notification area	Qualcomm Incorporated	discussion	Decision	Yes	Yes	postponed	No
		R3‑162948	Paging and Mobility in Inactive State	Nokia, Alcatel-Lucent Shanghai Bell	discussion	Decision	Yes	Yesmoved from AI 10.6.2.1 to AI 10.2.2 Nokia: does not think that 5G solution need to be aligned 100% with REL-14 light connection work, it will be similar but not identical Mediatek: it is a pity that we tightly couple the 5G study to light connection work RAN3 chair: the other condition was that we need RAN2 input Mediatek: there was quite some progress in RAN2	postponed	No
10.2.3	Others
10.3	RAN architecture and interfaces
10.3.1	General	R3‑162821	Architecture of New RAN	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	YesMCC: wrong Tdoc type in Tdoc request IAESI: only distributed coordination and not centralized coordination is shown RAN3 chair: does not think that this is the intention here, it is more: Do we need to split gNB in muliple nodes? IAESI: then "New RAN architecture" title does not fit RAN3 chair: there is an activity in TSG RAN to rename terminology after offline discussion in Tue morning coffee break: Nokia: we could agree the Nokia pCR and have further discussion about Ericsson pCR Deutsche Telekom: supports to take Nokia's pCR as a basis Ericsson: since Nokia proposal does not have a combined node, we cannot accept it as a baseline Telecom Italia: considers combined node as a specific implementation of the general architecture conclusion: aspects of R3-162821 will be merged into R3-163110	merged	No	R3‑163110
		R3‑162975	New RAN architecture	Ericsson	pCR		Yes	Yesmoved from AI 10.3 to AI 10.3.1 Nokia: we try to understand benefits of combined node; so far does not see it as a priority Ericsson: is a possible node, we should not restrict to have such a node, does not agree that this is an optimisation RAN3 chair: we use "eLTE/gNB" is several places and ngNB seems to take up this aspect IAESI: thinks the proposal is good as it simplifies the architecture but we still need to consider centralized and distributed unit Ericsson: does not see that this node is contradicting or in conflict with CU/DU discussion RAN3 chair: CU/DU discussion will come on Wed under another agenda item NEC: logical nodes have an ID, is a single ID planned? Ericsson: there was a Deutsche Telekom at RAN in the past discussing UE connectivity where separate, so it is less that ngNB = gNB +eLTE eNB but that ngNB is supporting both; ID is more stage 3 and can be discussed later; Samsung: you are hiding eNB/gNB from the UE which will not work RAN3 chair: does think that it is hiding, whether we talk about an eNB, a gNB, and eLTE NB is rather a question of supported functions Ericsson: has not yet seen technical arguments against such an architecture conclusion: further offline discussion needed (led by Ericsson), R3-162975 will revised in R3-163110 merging also aspects of R3-162821	revised	No	R3‑163110
		R3‑163110	New RAN architecture	Ericsson	pCR	-	Yes	YesZTE: has some concerns RAN3 chair: there is anyway an editor's note so we need to come back to this text	agreed	No		R3‑162975
		R3‑162741	Impacts for one logical node of co-sited (e)LTE eNB and gNB	Samsung	discussion	Decision	Yes	YesProposal1: Leave the co-sited case as the deployment implementation and not to specify the one logical node for the co-sited case.	noted	No
		R3‑163074	Response to R3-162741	Ericsson	response	Approval	Yes	Yes	noted	No
		R3‑162880	Further consideration on non-standalone E-UTRA architecture	CMCC	discussion	Decision	Yes	Yes	not treated	No
		R3‑162901	Functions and protocols of eLTE eNB connecting to NGC	Huawei	discussion	Decision	Yes	Yes	not treated	No
		R3‑163028	Functions and Mobility Scenarios for eLTE eNB	China Telecommunications	discussion		Yes	Yes	not treated	No
10.3.2	RAN-CN interface	R3‑162941	Management and Configuration of SCTP/IP over NG2 interface	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Approval	Yes	Yesconclusion: revsed in R3-16 to have just a list of requirements/issues (not going into stage3 description)	revised	No	R3‑163111
		R3‑163111	Management and Configuration of SCTP/IP over NG2 interface	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Approval	Yes	Yesconclusion: remove "and the processing VMs", NG2 => NG-C, remove Virtual Machine (VM)	revised	No	R3‑163248	R3‑162941
		R3‑163248	Management and Configuration of SCTP/IP over NG2 interface	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Approval	No	Yesconclusion: agreed unseen	agreed	No		R3‑163111
		R3‑163076	Response to R3-162941	Ericsson	response	Approval	Yes	YesProposal 1: RAN3 is invited to discuss the observations made in section 2.1 on the expected traffic load in 5G networks. Proposal 2: We propose to either conclude that multiple SCTP associations per NG-C interface instance are not necessary or to further analyse requirements and look into more details for the proposed scheme. Nokia: observation 5: we have one useless limitation in LTE today that we can get rid of Ericsson: breaking 10000 associations? one association per node relation only; this is an implementation issue Nokia: but the standard is limiting this RAN3 chair: SCTP is usually handled at stage 3 phase; we need a list to be addressed later in the WI phase (pooling, ...) without going already into stage 3 NEC: more detailed analysis from Nokia for next meeting would be useful RAN3 chair: is just looking for a list of aspects here	noted	No
		R3‑162978	Discussion on NG procedures	Ericsson	discussion		Yes	YesProposal: It is proposed to agree to the description of procedures in Section 2 and to remove the FFSs for those procedures in TR38.801 Samsung: we should consult RAN2 RAN3 chair: keeping ffs in main text and put ffs for this text Samsung: the text is too detailed, we have an own Tdoc Ericsson: we tried to be as non-binding as possible, we need to clarify what this procedure is for and has no problem to add an editor's note "pending on RAN2" ZTE: text is too detailed Nokia: there is some text that we cannot agree to, Samsung paper is very good, some need to be ffs: initial UE message, UE context release request, path switch RAN3 chair: but path switch is part of handover which is already ffs	noted	No	R3‑163112
		R3‑162979	TP on NG procedures	Ericsson	pCR		Yes	Yes	revised	No	R3‑163112
		R3‑163112	Discussion on NG procedures	Ericsson	discussion	-	Yes	Yesincludes aspects of R3-162738 as well	agreed	No		R3‑162979
		R3‑162738	NG interface procedures analysis	Samsung	pCR	Approval	Yes	YesRAN3 chair: can we capture in R3-163112 that there are different alternatives for PDU session? Samsung: ok but would also be good to capture the table conclusion: different alternatives for PDU session will be captured in TR	merged	No
		R3‑162906	NG-U Protocol Oblivious Encapsulation Design	Huawei	discussion	Decision	Yes	YesNokia: support the document but has still some questions, gNB needs to support on user plane all protocols? why is this simpler? Just signalling code point would be easier Ericsson: ffs whether it is feasible for RAN to read/write into a tunneling header; there was also an ffs from NTT DOCOMO on flexibility	revised	No	R3‑163113
		R3‑163113	NG-U Protocol Oblivious Encapsulation Design	Huawei	pCR	Decision	Yes	Yes	agreed	No		R3‑162906
		R3‑162826	Granularity of NG-U Tunnel	Qualcomm Incorporated	pCR	Decision	Yes	Yesmoved from AI 10.5 to AI 10.3.2 Ericsson: also PU session marking covered in encapsulation header? Nokia: paper is not acceptable for us Huawei: same view RAN3 chair: we will fix the ffs another time when we have more information from SA2	rejected	No
		R3‑162904	User Plane Protocol of NG/Xn	Huawei	pCR	Decision	Yes	YesMCC: wrong Tdoc type in Tdoc request Ericsson: "when receiving a PDU" is confusing, what does it have to do with DL PDU?	rejected	No
		R3‑162940	Key characteristics of NG-U protocol stack options	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Decision	Yes	YesMCC: wrong Tdoc type in Tdoc request Ericsson: a bit biased, for GTPU you claim it cannot be adapted but for others you can?; protocol multiplexer field is also not clear NEC: intended for informative annex of the TR? RAN3 chair: agrees	revised	No	R3‑163114
		R3‑163114	Key characteristics of NG-U protocol stack options	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Decision	Yes	Yes	agreed	No		R3‑162940
		R3‑162858	UP protocol stack over NG	Samsung	pCR	Decision	Yes	Yesconclusion: working assumption that GTP-U is used as protocol for NG-U; will be captured in a revised pCR	revised	No	R3‑163115
		R3‑163115	UP protocol stack over NG	Samsung	pCR	Decision	Yes	Yes	agreed	No		R3‑162858
		R3‑162980	Support of legacy UEs in the 5G System framework	Ericsson	discussion		Yes	Yes	noted	No
		R3‑162981	pCR related to the Support of legacy UEs in the 5G System frameworkt paper	Ericsson	pCR		Yes	YesNokia: we rejected this proposal already last time, we see not need a problem for a gNB to support 20 connections instead of 10, anm MME supports 1000s of SCTP connections today Ericsson: 32 or 64 SCTP connections were considered in the past Nokia: but Ericsson always doubted the SCTP limitation Samsung: too early to have such a description, also EPC as part of the NG core is not in line with current SA2 assumption; Ericsson: different logical nodes but one interface NTT DOCOMO: we see some value in what Ericsson is saying in terms of testing and support the Ericsson CMCC: why does NG core needs to support S1 functions? Deutsche Telecom: actual pCR does not talk about SCTP, what needs to be changed in the pCR that Nokia would accept it Nokia: many legacy information that would not be used (disclaimers would be needed everywhere), it would also limit the development of new NG functions Ericsson: no constraints on NG development Deutsche Telecom: how to realize the Ericsson proposal? referencing? Ericsson: referencing is one possible approach Ericsson: proposal is also addressing virtualization, an operator would not open 2 data centers Vodafone: but they could run on different virtual machines China Unicom: does not support the Ericsson proposal Nokia: a 5G UE will use one set of procedures and a 4G UE will use a independent set of procedures so there is no need to combine this Samsung: EPC is not considered in SA2 virtualization discussion Deutsche Telekom: maybe we should leave out the virtualization discussion here (as it is not really relevant), is option 3 supported? Ericsson: yes Qualcomm: we have a neutral position so far, will S1 be supported over this interface as well? Ericsson: normal S1 would always be supported Nokia: but this will not work with S1flex Ericsson: only one SCTP association and then different procedures can be used RAN3 chair: we can try to revise the pCR and see on Friday where we are Nokia: 2 companies said maybe and many companies had a concern so wondering why we need to revise the proposal	revised	No	R3‑163116
		R3‑163116	pCR related to the Support of legacy UEs in the 5G System frameworkt paper	Ericsson	pCR	-	No	YesRAN3 chair: topic has to be continued in the future	withdrawn	Yes		R3‑162981
		R3‑162932	Multi link Transport network	THALES	pCR		Yes	Yesmoved from AI 10.1.2 to AI 10.3.2 Huawei: already some limitations visible for long latency and multiple links? Thales: not yet Nokia: RAN3 has agreed to specify no transport networks RAN3 chair: satellite telecommunication industry is interested to reuse 3GPP specs, suggests that we check with RAN and RAN1 chair whether this is possible; currently there are no requirements for this in the RAN TR; RAN3 chair will report this situation to RAN #74 NEC: satellite for fronthaul or backhaul? It seems fronthaul is considered here; Thales: would like that interfaces for 5G can also cope with long latencies that we have; RAN3 chair: user plane, control plane and NAS are considered? Thales: yes; satelliite backhaul but also that 5G protocols could be considered via satellite; Ericsson: transport jitter and transport error rate could be considered; RAN3 chair: text is based on fronthaul but not for NG-U Intel: we can still consider text in the right section, but error rates are already considered Huawei: check whether this is covered in RAN TR? RAN3 chair: only air-ground communication is considered IAESI: CES had an input for 38.913 RAN3 chair: ok, maybe we need to double-check Huawei: satellite communication seems to be in but in the low priority list so not in phase 1 Thales: satellite in backhaul: we would prefer that NG-2, NG-3 over satellite could be supported in phase 1; Huawei: so far not aware of limits to use satellite as backhaul NEC: S1/S2 already on satellite link? RAN3 chair: suggests that pCR can be considered next time (pCR was for backhaul but in fronthaul section and Ericsson commented that it could be for fronthaul) conclusion: RAN3 chair will report to RAN #74 that satellite industry is interested in 5G for satellite (satellite as physical layer for NG (NG-C, NG-U, TNL)) and we can see the discussion there then	postponed	No
		R3‑162850	Further update on the NG-C interface	ZTE Corporation	discussion		Yes	YesZTE: is about NG procedures RAN3 chair: can be continued next meeting	noted	No
		R3‑162905	Need for Efficient Session Configuration	Huawei	discussion	Decision	Yes	YesRAN3 chair: can be continued next meeting	noted	No
		R3‑162976	On the NG-U and Xn-U protocol stack	Ericsson	discussion		Yes	Yes	noted	No
		R3‑162977	UP stack for NG and Xn interface	Ericsson	pCR		Yes	Yes	postponed	No
10.3.3	RAN internal interface	R3‑162822	Additional functions of the Xn interface	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	YesProposal 1: Capture interference coordination as a function of the Xn interface. Proposal 2: Capture self-optimization as a function of the Xn interface. Proposal 3: Capture UE context retrieval as a function of the Xn interface. LG: load management? Nokia: so far enough we capture just two and can add others later Huawei: should we not wait for RAN2 for this (depending on inactive mode and mobility)? Ericsson: many ffs for inactive but it is quite clear that we will need UE context retrieval so fine to add it Qualcomm: has an input on interference coordination using RRM coordination as measurement request need to be included as well IAESI: supports Nokia's text proposal ZTE: if we add UE context retrieval then we should add ffs; interference coordination depends on progress in RAN1, SON functionality is not yet clear LG: interference coordination: load management should be added, SON is a common feature RAN3 chair: any doubt that we will have UE context retrieval, interference coordination, SON? details can of course be fixed later; load balancing and RRM may be more tricky as we have no load and QoS definition so far; any concern to agree the pCR as it is? Huawei: would like to discuss the phrasing offline first conclusion: revised in R3-163117 to have some generic bullets	revised	No	R3‑163117
		R3‑163117	Additional functions of the Xn interface	Nokia, Alcatel-Lucent Shanghai Bell	pCR	-	Yes	Yes	agreed	No		R3‑162822
		R3‑162830	RRM Coordination over Xn	Qualcomm Incorporated	pCR	Decision	Yes	YesQualcomm: is related to R3-162822 interference coordination part conclusion: can be considered in the offline discussion for R3-163117 in order to merge acceptable text of R3-162830 there	merged	No
		R3‑162677	Further consideration on RAN internal interface Xn	LG Electronics Inc.	discussion		Yes	YesProposal 1): To capture the additional functionalities for Xn interface listed above into TR 38.801. Proposal 2): To capture the Xn procedure above into TR 38.801. Proposal 3): To capture Text Proposal in [3] into TR 38.801.	noted	No
		R3‑162678	Text Proposal for RAN internal interface Xn	LG Electronics Inc.	pCR		Yes	YesRAN3 chair: paging and mobility failure can be put on hold as idle mode mobility is on hold ZTE: energy saving text is very detailed already RAN3 chair: so no functions will be added so far LG: procedures were from last time ZTE: depending on tight interworking topic RAN3 chair: so just a reference to tight interworking section Nokia: interface management procedures can be accepted from this pCR conclusion: capture interface management procedures, additional reference to tight interworking can be further discussed	revised	No	R3‑163118
		R3‑163118	Text Proposal for RAN internal interface Xn	LG Electronics Inc.	pCR	-	Yes	Yes	agreed	No		R3‑162678
		R3‑162780	Consideration on Xn interface procedures	CATT,China Telecom	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Nokia: under function: dual connectivity is renamed here as tight interworking conclusion: pCR is not agreed but change regarding dual connectivity can be discussed further	rejected	No
		R3‑162831	Xn Interface Procedures	Qualcomm Incorporated	pCR	Decision	Yes	Yes	rejected	No
		R3‑162844	Discussion on Xn interface	ZTE Corporation	pCR		Yes	Yes	rejected	No
		R3‑162903	Procedures Analysis for the Xn Interface	Huawei	pCR	Decision	Yes	Yes	rejected	No
		R3‑162982	Xn interface procedures	Ericsson	discussion		Yes	Yes	noted	No
		R3‑162983	pCR on Xn interface procedures	Ericsson	pCR		Yes	Yes	rejected	No
		R3‑162703	Consideration on Tight Interworking with Xx Interface	ZTE Corporation	discussion		Yes	YesProposal 1: To clarify whether the LTE eNB, which does not support NGC, is allowed to be aggregated by means of split bearer with Master gNB via Xx interface. Proposal 2: To discuss and confirm that the Xx interface is not applicable for Deployment Option 4/4a and 7/7a, i.e. only Xn interface is applicable for Deployment Option 4/4a and 7/7a.	noted	No
		R3‑162829	Xn Interface In Centralized RAN Deployment	Qualcomm Incorporated	pCR	Decision	Yes	YesRAN3 chair: split gNB in CU/DU is not yet decided so no need to discuss this at the moment	postponed	No
		R3‑162857	UP protocol stack over Xn	Samsung	discussion	Decision	Yes	YesZTE: separate chapter needed? RAN3 chair: no support for this conclusion: working assumption: GTP is used as protocol for Xn-U	revised	No	R3‑163119
		R3‑163119	UP protocol stack over Xn	Samsung	discussion	Decision	Yes	Yes	agreed	No		R3‑162857
10.3.4	Others	R3‑162902	Network selection and access control framework for eLTE	Huawei	discussion	Decision	Yes	YesProposal 1: To let the UE knows the network type, the eLTE eNB could broadcast its network type, i.e. whether eLTE eNB or LTE eNB. Proposal 1 bis: eLTE eNB give CN preference to the UE to assist UE to select an appropriate network. Proposal 2: eLTE eNB needs to perform NAS routing function and forward the NAS message to the selected CN. Proposal 3: Consider CN specific ACB for eLTE for CN load balancing. Nokia: proposal 1 was already agreed, no need to indicate preference as in proposal 1bis	noted	No
		R3‑162931	Consideration of RAN impacts on migration	LG Electronics Inc.	discussion		Yes	YesProposal): To take the information above into account on the potential RAN impacts for migration path from LTE/EPC including Option 3 to NG System. Nokia: more a RAN2 topic but why capability needs to be indicated?	noted	No
10.4	Realization of Network Slicing	R3‑162828	Slice Isolation in RAN	Qualcomm Incorporated	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request	postponed	No
		R3‑162955	Resource Management between Slices	Huawei	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request	agreed	No
		R3‑162954	Key principles for Support of Network Slicing in RAN	Huawei	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request	revised	No	R3‑163221
		R3‑163221	Key principles for Support of Network Slicing in RAN	Huawei	pCR	-	Yes	Yes	agreed	No		R3‑162954
		R3‑162944	Slice Availability and impact on Mobility	Nokia, Alcatel-Lucent Shanghai Bell	discussion	Decision	Yes	YesNEC: why removing first paragraph; ok if you take out interfrequency Nokia: we have solved the open poiint that's why the text is removed	revised	No	R3‑163222
		R3‑163222	Slice Availability and impact on Mobility	Nokia, Alcatel-Lucent Shanghai Bell	discussion	Decision	Yes	Yes	agreed	No		R3‑162944
		R3‑162984	Availability of Network Slices	Ericsson	discussion		Yes	Yes	noted	No
		R3‑162985	TP on Availability of Network Slices	Ericsson	pCR		Yes	YesNokia: 2nd and 3rd sentence are ok conclusion: 2nd and 3rd sentence to be included in R3-162944	merged	No
		R3‑162675	Discussion on support of network slicing in RAN	LG Electronics Inc.	discussion	Decision	Yes	No	available	No
		R3‑162676	Text proposal on RAN selection of CN entity	LG Electronics Inc.	pCR	Approval	Yes	No	available	No
		R3‑162723	Some Clarification for NW Slicing	ZTE Corporation	discussion		Yes	No	available	No
		R3‑162731	Some Issues with NW Slicing in Multiple Connectivity Contexts	ZTE Corporation	discussion		Yes	No	available	No
		R3‑162732	TP for NW Slicing in Multiple Connectivity Contexts	ZTE Corporation	pCR		Yes	NoMCC: wrong Tdoc type discussion in Tdoc request	available	No
		R3‑162782	Align with SA2 on RAN selection of CN entity	CATT,China Telecom	discussion		Yes	No	available	No
		R3‑162827	Slice selection in NG Flex	Qualcomm Incorporated	discussion	Decision	Yes	No	available	No
		R3‑162894	Question to SA2 and RAN2 on Network Slicing	NEC	discussion	Decision	Yes	No	available	No
		R3‑162942	Correction of RAN Selection of CN Entity	Nokia, Alcatel-Lucent Shanghai Bell	discussion	Decision	Yes	No	available	No
		R3‑162943	Correction of Selection of RAN part of Network Slice	Nokia, Alcatel-Lucent Shanghai Bell	discussion	Decision	Yes	No	available	No
		R3‑162956	RAN Support of Slice Availability	Huawei	discussion		Yes	No	available	No
10.5	QoS	R3‑162986	Analysis of interim Agreements for QoS and PDU Session Management	Ericsson	discussion		Yes	Yes	noted	Yes
		R3‑162987	pCR related to the QoS and PDU Session Management paper	Ericsson	pCR		Yes	YesIntel: what is QoS rule index? Ericsson: pointer to QoS rules Intel: should rather be a profile index; what is default QoS rule? Nokia: no QoS rule index needed Ericsson: we can work on this to Nokia, Samsung, ZTE: too early to have fig. 9.1-1 Huawei: supports to have a figure RAN3 chair: let's have the figure with an ffs	revised	No	R3‑163215
		R3‑163215	pCR related to the QoS and PDU Session Management paper	Ericsson	pCR	-	Yes	YesZTE: an SA2 agreement not in line with text RAN3 chair: can add an ffs conclusion: ffs will be added after one sentence; future alignment with SA2 to be checked	revised	No	R3‑163249	R3‑162987
		R3‑163249	pCR related to the QoS and PDU Session Management paper	Ericsson	pCR	-	Yes	Yesconclusion: agreed unseen	agreed	No		R3‑163215
		R3‑162771	Consideration on principles for QoS in RAN	LG Electronics Inc.	discussion		Yes	YesLG: already covered by discussion of Ericsson Tdoc	not treated	No
		R3‑162772	TP for consideration on principles for QoS in RAN	LG Electronics Inc.	pCR		Yes	YesLG: already covered by discussion of Ericsson Tdoc	not treated	No
		R3‑162797	NR QoS considerations	Intel Corporation	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request conclusion: aspects will be merged into R3-163215	merged	No
		R3‑162744	NR QOS model for UL and DL	Samsung	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Samsung: Ericsson explained signalling part, we explained user plane part	rejected	No
		R3‑162958	QoS considerations in Handover procedure	Huawei	discussion		Yes	YesProposal 1: Discuss how to allow for DRB mapping flexibility.	noted	No
		R3‑162969	QoS and bearer for DC between LTE and NR	NTT DOCOMO INC.	discussion		Yes	YesProposal 1: To confirm the understanding that: - For the DC architecture(s) that connects to NextGen Core (case 1 and 3), the Flow Based QoS framework is applied. - For the DC architecture that connects to EPC (case 2), LTE QoS framework (i.e., bearer based QoS) is applied. Proposal 2: In the DC architecture connecting to EPC, the NR gNB supports the LTE DC functionalities and procedures. Proposal 3: In the DC architecture connecting to EPC, the NR gNB applies LTE QoS framework towards the EPC, LTE eNB and UE: - LTE DC procedures (e.g., SeNB addition, etc.) are applied when adding NR gNB as secondary eNB, in which necessary QoS service (i.e., bearer) are configured. - E-RAB (and concerning S1-U bearer) is established between EPC and NR gNB for SCG split bearer option according to LTE specification - X2-U is established between LTE eNB and NR gNB for split bearer option according to LTE specification - DRB is established between NR gNB and UE according to SCG bearer option or split bearer option as specified LTE	noted	No
		R3‑162970	Text Proposal to TR 38.801 on Dual Connectivity between LTE and NR via EPC	NTT DOCOMO INC.	pCR		Yes	Yes	revised	No	R3‑163217
		R3‑163217	Text Proposal to TR 38.801 on Dual Connectivity between LTE and NR via EPC	NTT DOCOMO INC.	pCR	-	Yes	Yesconclusion: agreed unseen	agreed	No		R3‑162970
		R3‑162860	Principles and key issues for Qos	CATT,China Telecom	discussion		Yes	Yes	not treated	No
		R3‑162825	Flow QoS Principles	Qualcomm Incorporated	discussion	Decision	Yes	Yes	not treated	No
		R3‑162851	Update on the key QoS principles in RAN3	ZTE Corporation	discussion		Yes	Yes	not treated	No
		R3‑162861	QoS impact on PDU session management procedure	CATT, China Telecom	discussion		Yes	Yes	not treated	No
		R3‑162945	Detailed description of QoS framework in RAN	Nokia, Alcatel-Lucent Shanghai Bell	discussion	Decision	Yes	Yes	not treated	No
		R3‑162957	The QoS procedures in RAN3	Huawei	discussion		Yes	Yes	not treated	No
		R3‑162971	Text Proposal to TR 38.801 on Dual Connectivity between LTE and NR via EPC	NTT DOCOMO INC.	pCR		No	No	withdrawn	Yes
10.6	Radio access network procedures
10.6.1	Tight Interworking between New RAT and LTE	R3‑162681	Open issues on tight interworking between new RAT and LTE	LG Electronics Inc.	discussion		Yes	YesProposal 1): Similar to Option 3/3a, it is suggested to capture basic radio protocol architectures for option 4/4a and 7/7a with editorial note on NR part pending to RAN2. Proposal 2): To take, “the procedures and protocols over Xn interface for Option 7/7a should be the same as Option 4/4a, as a working assumption in RAN3. Proposal 3): To capture the evaluation matrix and contents on the evaluation of SCG Split bearer. Proposal 4): To capture Text Proposal in [3] into TR 38.801.	noted	No
		R3‑162682	TP on tight interworking between new RAT and LTE	LG Electronics Inc.	pCR		Yes	YesNokia: fine with first change, but remove use case and Xn backhaul Ericsson: there is only a single MAC (this is wrong in all figures)	revised	No	R3‑163120
		R3‑163120	TP on tight interworking between new RAT and LTE	LG Electronics Inc.	pCR	-	Yes	Yes	agreed	No		R3‑162682
		R3‑162708	Tight interworking procedures for Option 3/3a	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	YesRAN3 chair: home Node B concept can not be included like this Nokia: can be kept ffs Qualcomm: should we ask RAN4 regarding cell list? RAN3 chair: check offline Huawei: let's remove home Node B aspects for the moment	revised	No	R3‑163121
		R3‑163121	Tight interworking procedures for Option 3/3a	Nokia, Alcatel-Lucent Shanghai Bell	pCR	-	Yes	Yes	agreed	No		R3‑162708
		R3‑162929	Further justifications on Xx interface	Huawei	pCR	Approval	Yes	Yes	not treated	No
		R3‑162704	Consideration on SCG Split Bearer with Option 4a and 7a	ZTE Corporation	discussion		Yes	Yes	not treated	No
		R3‑162706	Further Consideration on Xn Procedures for NR/LTE Tight-Interworking	ZTE Corporation	discussion		Yes	Yes	not treated	No
		R3‑162743	Tight interworking between new RAN node	Samsung	discussion	Decision	Yes	Yes	not treated	No
		R3‑162781	Consideration on CP procedures for LTE and NR interworking	CATT,China Telecom	discussion		Yes	Yes	not treated	No
		R3‑162824	Network Identifiers Analysis	Qualcomm Incorporated	discussion	Decision	Yes	Yes	not treated	No
		R3‑162926	User plane design details for LTE-NR tight interworking	Huawei	discussion	Decision	Yes	Yes	not treated	No
		R3‑162927	Further comparison on user plane architecture options for LTE-NR tight interworking	Huawei	discussion	Decision	Yes	Yes	not treated	No
		R3‑162928	LTE-NR tight interworking CP procedure	Huawei	pCR	Approval	Yes	Yes	not treated	No
		R3‑162930	Possible RAN3 impacts on UE capability coordination	Huawei	pCR	Approval	Yes	Yes	not treated	No
10.6.2	New RAN operation
10.6.2.1	Mobility without CN type change	R3‑162679	Consideration on inter gNB mobility without CN type change	LG Electronics Inc.	discussion		Yes	YesEricsson: editor's note misleading as we define this ourself	noted	No
		R3‑162680	Text Proposal on inter gNB mobility without CN type change	LG Electronics Inc.	pCR		Yes	Yes	rejected	No
		R3‑162892	Inter gNBs Mobility without CN type change	NEC	discussion	Decision	Yes	Yes	not treated	No
		R3‑162893	Inter gNBs Mobility without CN type change	NEC	pCR	Decision	Yes	Yesconclusion: single sentence to refer to 36.300	revised	No	R3‑163168
		R3‑163168	Inter gNBs Mobility without CN type change	NEC	pCR	Decision	Yes	Yesconclusion: agreed, rapporteur will add "TS" in front of 36.300, add eLTE eNB as well	agreed	No		R3‑162893
		R3‑162947	Solutions for intra New-RAN Handover	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request conclusion: ffs need to be checked with SA2	revised	No	R3‑163169
		R3‑163169	Solutions for intra New-RAN Handover	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Decision	Yes	Yes	revised	No	R3‑163250	R3‑162947
		R3‑163250	Solutions for intra New-RAN Handover	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Decision	No	Yesconclusion: agreen unseen	agreed	No		R3‑163169
		R3‑162952	Procedure of inter-RAT handover without CN change	Huawei	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request conclusion: merged into R3-163168	merged	No
		R3‑162733	TP for Inter-gNB Multiple Connectivity Operation	ZTE Corporation	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request RAN3 chair: multiple connectivity definition is pending to RAN2 LS response	postponed	No
		R3‑162823	Network based and UE based mobility	Qualcomm Incorporated	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request RAN3 chair: is context fetch a mobility function? Qualcomm seems to consider it as a handover RAN3 chair: is it in connected mode only? Qualcomm: yes conclusion: pending on RAN2 clarification on mobility	postponed	No
		R3‑162849	Discussion on Mobility without CN type change	ZTE Corporation	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request RAN3 chair: RRC is not RAN3 topic	rejected	No
		R3‑163066	RAN location Tracking in RRC Inactive	MediaTek Inc.	discussion		Yes	Yes	not treated	No
10.6.2.2	Mobility with CN type change	R3‑162740	Mobility with CN type change	Samsung	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Nokia: only second one is agreed at the moment; why should we capture text about alternatives that are under discussion in SA2 Ericsson: is not even sure about the 2nd one RAN3 chair: can we wait until SA2 has agreement Samsung: wants to check with SA2 and come back later this week Nokia: is fine to capture the 2nd conclusion: pending to SA2	postponed	No
		R3‑162953	Procedure of inter-RAT handover with CN change	Huawei	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request conclusion: pending to SA2	postponed	No
		R3‑162798	Interworking between EPC and NGC	Intel Corporation	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request moved from AI 10.6.1 to AI 10.6.2.2 Nokia: it's the same topic that we discussed before RAN3 chair: we never copy text from other specs into our specs as this would cause maintenance effort if the copied text changes in the spec from others	revised	No	R3‑163170
		R3‑163170	Interworking between EPC and NGC	Intel Corporation	pCR	Decision	Yes	Yes	agreed	No		R3‑162798
		R3‑162848	Discussion on Mobility with CN type change	ZTE Corporation	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request; RAN3 chair: single radio single attach was agreed in SA2? Nokia: yes, in one direction Ericsson: why are we now copying from SA2 TR? conclusion: change is reflecting SA2 agreement but no need to capture it in RAN3 TR	rejected	No
10.6.3	Others	R3‑162779	TP on scenarios for mobility	CATT,China Telecom	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request; moved from AI 10.6.2 to AI 10.6.3 CATT: is already covered	not treated	No
		R3‑162946	Text Proposal for Session Modification Function	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request; moved from AI 10.6.2 to AI 10.6.3 Ericsson: procedures only applicable for gNB but also applicable on eLTE eNB Ericsson: e/gNB should be used in call flows Nokia: but eNB is for 4G Nokia: suggesting editor's note how we handle preemption case in 5G: gNB triggered PDU session release is ffs	revised	No	R3‑163171
		R3‑163171	Text Proposal for Session Modification Function	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Decision	Yes	Yes	revised	No	R3‑163251	R3‑162946
		R3‑163251	Text Proposal for Session Modification Function	Nokia, Alcatel-Lucent Shanghai Bell	pCR	Decision	No	Yesconclusion: agreed unseen	agreed	No		R3‑163171
		R3‑163026	Consideration on session release and modification	LG Electronics Inc.	discussion		Yes	Yesmoved from AI 10.6.2 to AI 10.6.3 LG: already covered	not treated	No
		R3‑162951	Procedure of initial access	Huawei	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Samsung: the call flow is from 36.300 RAN3 chair: reference to 36.300 possible and initial UE message is still ffs Ericsson: NAS PDU transport better term than initial UE message Samsung: 36.300 part is just the starting point NTT DOCOMO: supports to have 36.300 baseliine conclusion: limited figure/high level call flow and editor's note to clarify open issues	revised	No	R3‑163172
		R3‑163172	Procedure of initial access	Huawei	pCR	-	Yes	YesEricsson: NG CP? Huawei: should be NG-C conclusion: NGC=>NG-C in figure, update first sentence	revised	No	R3‑163252	R3‑162951
		R3‑163252	Procedure of initial access	Huawei	pCR	-	Yes	Yes	agreed	No		R3‑163172
		R3‑162705	Further Consideration on New RAN Aggregation Scenarios due to CU-DU Split	ZTE Corporation	discussion		Yes	Yes	postponed	No
10.7	RAN logical architecture for NR
10.7.1	Functional split between central and distributed unit(s)	R3‑162866	Further considerations on traffic aggregation	Huawei	pCR	Endorsement	Yes	YesRAN3 chair: analysis is based on LTE protocol stack as we do not know how 5G protocol stack looks like Ericsson: with option 3 DU is enough, with other options DU + part of CU is needed ATT: already a certain amount of centralization is happening in LTE Nokia: unclear how tight interworking and option 2 would work RAN3 chair: tight interworking is a separate discussion; Nokia: if we go for option 2 there is no tight interworking? ATT: for us it is not acceptable to include this pCR conclusion: relation between option 2 and DC (dual connectivity) to be clarified	revised	No	R3‑163173
		R3‑163173	Further considerations on traffic aggregation	Huawei	pCR	Endorsement	Yes	Yes	agreed	No		R3‑162866
		R3‑162791	Alignment between high functional split and DC	Intel Corporation	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion Tdoc request Nokia: wants to add an editor's note: not clear how to support option 2 and tight interworking Huawei: but then we will need to add this everywhere NTT DOCOMO: for option 2 it is almost agreed that Dual Connectivity is the baseline	rejected	No
		R3‑162793	TP on alignment between high functional split and DC	Intel Corporation	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request	not treated	No
		R3‑162661	RRC signaling between CU and DU	LG Electronics Inc.	discussion		Yes	YesProposal 1: RRC signalling between the CU and the DU should be considered. Proposal 2: In order to carry the RRC message through the interface between the CU and the DU, SRB and DRB setup should be considered. Proposal 3: It is proposed to agree the TP [2] for TR 38.801.	noted	No
		R3‑162662	TP for RRC signaling between CU and DU	LG Electronics Inc.	pCR		Yes	Yesconclusion: how to transfer RRC message needs to be clarified	revised	No	R3‑163174
		R3‑163174	TP for RRC signaling between CU and DU	LG Electronics Inc.	pCR	-	Yes	Yes	agreed	No		R3‑162662
		R3‑162852	Clarification on CU-DU split options	ZTE Corporation	discussion		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request ATT: objects removal of sentence in 11.1.1 CMCC: this proposal is not working	rejected	No
		R3‑162989	Possible realisation of Option 2	Ericsson	discussion		Yes	Yes	noted	No
		R3‑162990	TP on possible realisation of Option 2	Ericsson	pCR		Yes	YesNTT DOCOMO: is changing CP/UP separation from LTE? Ericsson: here we talk about entire protocols RAN3 chair: so different ways to split RRC and user plane Samsung: why different stacks for option 2 (CP/UP)? Ericsson: stack is the same NTT DOCOMO: is not an alternative but one way to realize option 2 RAN3 chair: Tdoc is about how to handle CP and UP part of the PDCP Nokia: what is the relation to CP/UP separation? what is the benefit of the proposal? Deutsche Telekom: we need to focus on the interface between CU and DU	revised	No	R3‑163175
		R3‑163175	TP on possible realisation of Option 2	Ericsson	pCR	-	Yes	YesNokia: this version is not acceptable for us, either new separate option or leaving for implementation Huawei: no option 2 anymore but just option 2-1 and option 2-2? RAN3 chair: yes CATT: for 2-2: UP/CP separation and CU/DU split? Ericsson: not really	revised	No	R3‑163253	R3‑162990
		R3‑163253	TP on possible realisation of Option 2	Ericsson	pCR	-	Yes	No	available	No		R3‑163175
		R3‑162696	Additional Benefit Considerations for Option 3-1	AT&T	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Huawei: L2 mobility should be done in MAC or lower	revised	No	R3‑163176
		R3‑163176	Additional Benefit Considerations for Option 3-1	AT&T	pCR	Decision	Yes	Yes	agreed	No		R3‑162696
		R3‑162729	Clarification on Option 3-1	Nokia, Alcatel-Lucent Shanghai Bell, KT, CATT	pCR		Yes	YesHuawei: better wait for RAN2, in LTE there are 2 types of segmentation? Ericsson: paper brings to RAN3 a discussion that is ongoing in RAN2 RAN3 chair: do both segmentations exist today in LTE? NTT DOCOMO: not in the spec ATT: supports the proposal RAN3 chair: we base discussion on LTE protocol stack and not on what is currently discussed in RAN2 Nokia: if we remove realtime? Ericsson: segmentation is one process that is happening in one place conclusion: can come back on Friday if there is a proposal that can be agreed Finally concluded that this pCR is depending on RAN2.	postponed	No
		R3‑162773	Further consideration on Option 3-1	LG Electronics Inc.	discussion		Yes	YesProposal 1: Whether single SN for PDCP and RLC in Option 3-1 needs to be considered or not is pending to RAN2 progress. Proposal 2: It is proposed to agree the TP [4] for TR 38.801.	noted	No
		R3‑162774	TP for further consideration on Option 3-1	LG Electronics Inc.	pCR		Yes	Yesconclusion: remove sentence instead of ffs	revised	No	R3‑163177
		R3‑163177	TP for further consideration on Option 3-1	LG Electronics Inc.	pCR	-	Yes	Yes	agreed	No		R3‑162774
		R3‑162847	Further Considerations on Split Option 3	ZTE Corporation	discussion		Yes	Yes	noted	No
		R3‑162862	Clarification on function split option 3-1	CATT, China Telecom	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Ericsson: we do not agree with this analysis, centralized may cause more retransmissions	rejected	No
		R3‑162863	Considerations on RAN function split between CU and DU	CATT,China Telecom	pCR		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Huawei: is a summary not really an analysis and NTT DOCOMO has such a table already CATT: our table includes many more aspects ZTE: no retransmission backhaul considered for option 3	rejected	No
		R3‑162865	Further considerations on Option3	Huawei	pCR	Endorsement	Yes	Yesconclusion: removal of ffs is agreed (other change is identical with a proposal already covered in LG pCR)	agreed	No
		R3‑162881	Clarification for flow control buffer of option3-2	CMCC	pCR	Decision	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request Ericsson: proposal goes a bit into implementations	rejected	No
		R3‑162882	Transmission robustness of option3-2	CMCC	discussion		Yes	YesMCC: wrong Tdoc type discussion in Tdoc request	noted	No
		R3‑162991	Analysis of Option 3	Ericsson	discussion		Yes	Yes	noted	No
		R3‑162992	TP on Analysis of Option 3	Ericsson	pCR		Yes	YesCATT: pCR not acceptable for us, does not agree to listed drawbacks Huawei: supports the Ericsson proposal Ericsson: from UMTS to LTE we went from centralized ARQ and now we are doubting that this was the right approach? IAESI: this would then be also a disadvantage for other options Ericsson: at least benefits should be acceptable ATT: the may should be enough Ericsson: last one has no "may" Nokia: why should it be "ffs"? conclusion: add "may" and remove "ffs", do not remove sentences	revised	No	R3‑163179
		R3‑163179	TP on Analysis of Option 3	Ericsson	pCR	-	Yes	Yes	agreed	No		R3‑162992
		R3‑162686	Definition of split option 4	Interdigital Asia LLC	pCR	Approval	Yes	Yes	agreed	No
		R3‑162841	CU-DU split: Summary table	NTT DOCOMO INC.	pCR	Approval	Yes	YesEricsson: we should clarify this is not for comparison purposes as the table is not exhaustive NTT DOCOMO: is internal TR conclusion: high-level summary should not be for evaluation purposes in note	revised	No	R3‑163180
		R3‑163180	CU-DU split: Summary table	NTT DOCOMO INC.	pCR	Approval	Yes	Yes	agreed	No		R3‑162841
		R3‑162792	Further consideration on CU-DU split granularity	Intel Corporation	discussion	Decision	Yes	Yes	noted	No
		R3‑163038	TP on CU-DU split granularity	Intel Corporation (UK) Ltd	pCR		Yes	YesMCC: based on wrong TR version 0.6.1 instead of 0.6.0? ATT: has a problem with note 1 change	rejected	No
		R3‑162890	Function split options selection	NEC	discussion	Decision	Yes	Yes	noted	No
		R3‑162891	Function split options selection	NEC	pCR	Decision	Yes	YesATT: problem with editor's note on higher layer split, too early for us NTT DOCOMO: are we going to specify everything? Ericsson: filter out option 8 is not acceptable for us, what about option 6 (IEEE) & 7 (CIPRI)? Huawei: too early to say that we will select one higher and one lower layer option Verizon: "at least one higher and one lower layer split" would be possible Deutsche Telekom: we should at least be able to say how many options we want to standardize ZTE: do we need to downselect already in SI phase? Why one on lower and on higher layer and not not only one? conclusion: postponed - operators are requested to indicate preferred split and number of options for next time - consequences of functional split in terms of specification should be checked	postponed	No
		R3‑163213	CU-DU spit option selection and interface specification	NTT DOCOMO, INC., AT&T, CMCC, KT, SK Telecom, Deutsche Telekom, Telecom Italia, Verizon, KPN, Fujitsu, NEC, Nokia, CATT	pCR	discussion	Yes	YesZTE: what is M-plane? NTT DOCOMO: Management plane Huawei: not only the specification but additional aspects need to be considered (impact etc.) RAN3 chair: tends to agree but we can start from specification aspects Deutsche Telekom: this is an example of downselection that should be appreciated so we should not add option 8 again Telecom Italia: is there any operator who is interested in option 8? ATT: we could indicate: there is high operator interest in option 6 & 7 and not in option 8 NTT DOCOMO: can keep the pCR as a working assumption Ericsson: why was option 5 ruled out? NTT DOCOMO: will be a complex option Ericsson: option 5 was discussed in Comp and we added a lot of features China Unicom: supports NTT DOCOMO Fujitsu: who supports option 5 Telecom Italia: what does "focus on" mean? RAN3 chair: that we prioritize conclusion: pCR is revised to have editor's note: RAN3 should focus on option 2 and/or 3 for higher layer split options and focus on other than option 8 for lower layer split options. But specification aspects should be assessed before actually deciding. plus the new section 11.1.3.X with its editor's note NEC/vendors to provide a pCRto next meeting to explain why option 8 should not be considered	revised	No	R3‑163214
		R3‑163214	CU-DU spit option selection and interface specification	NTT DOCOMO	pCR	discussion	Yes	Yes	agreed	No		R3‑163213
		R3‑162728	Flexibility of RAN functional split	Nokia, Alcatel-Lucent Shanghai Bell, KT	pCR		Yes	No	available	No
		R3‑162730	Interface specification and general principles for Option 3-1	Nokia, Alcatel-Lucent Shanghai Bell, KT, CATT	pCR		Yes	No	available	No
		R3‑162840	CU-DU spit option selection and interface specification	NTT DOCOMO, INC., Deutsche Telekom, KT, SK Telecom, Fujitsu, CMCC, Telecom Italia, Orange	pCR	Approval	Yes	No	available	No
		R3‑163039	CU-DU spit option selection and interface specification	NTT DOCOMO, INC., Fujitsu, CMCC, KT, SK Telecom, Deutsche Telekom, Orange, Telecom Italia, Verizon	pCR	Approval	Yes	YesMCC: based on wrong TR version 0.6.1 instead of 0.6.0?	revised	No	R3‑163163
		R3‑163163	CU-DU spit option selection and interface specification	NTT DOCOMO, INC., Fujitsu, CMCC, KT, SK Telecom, Deutsche Telekom, Orange, Telecom Italia, Verizon, KPN	pCR	Approval	Yes	No	available	No		R3‑163039
		R3‑162854	RAN functional split considerations and preferences	Verizon	discussion	Decision	Yes	Yes	revised	No	R3‑163093
		R3‑163093	RAN functional split considerations and preferences	Verizon	discussion	Decision	Yes	No	available	No		R3‑162854
		R3‑162842	CU-DU interface: U-plane aspects	NTT DOCOMO INC.	pCR	Approval	Yes	No	available	No
10.7.2	UP-CP Separation	R3‑162687	Centralized RRM and Scheduling	Interdigital Asia LLC	pCR		Yes	Yesmoved from AI 10.7.1 to AI 10.7.2 conclusion: agreed with replacing fronthaul by transport	agreed	No
		R3‑162799	Benefits of hierarchical centralized control architecture	IAESI, Thales, Fairspectrum	discussion	Decision	Yes	Yes	noted	No
		R3‑162802	TP for hierarchical CP architecture	IAESI, Thales, Fairspectrum	pCR		Yes	YesEricsson: everything connected with everything; comparison of fig.1 and fig.2 not possible RAN3 chair: touching LTE architecture is out-of-scope of the SI	rejected	No
		R3‑162800	Functional benefits of Central Coordination	IAESI,Thales, Fairspectrum	discussion	Decision	Yes	Yes	noted	No
		R3‑162804	TP on benefits of the hierarchical Central Coordination	IAESI, Thales, Fairspectrum	pCR		Yes	YesATT: we support this pCR RAN3 chair: is a new logical node in NR, clarify the central unit and architecture	rejected	No
10.7.3	Realization of RAN Network Functions
10.7.4	Others
10.8	SON
10.9	Wireless Relay
10.10	Migration towards RAN for NR	R3‑162993	Observations on migration paths	Ericsson	discussion		Yes	YesRAN3 chair: we have to provide a view to RAN regarding the architecture	noted	No
		R3‑162994	Observations on migration paths	Ericsson	pCR		Yes	YesRAN3 chair: option 3/3a came from RAN Telecom Italia: option 3/3a as highest prio for NR is not acceptable for us NTT DOCOMO: NSA is translating to option 3/3a and from timeline 3/3a is already prioritized Huawei: we have already prioritized 3/3a Samsung: options should be discussed at RAN and we cannot agree to prioritize option 3/3a Deutsche Telekom: finds the paper reasonable conclusion: discussion is to be continued	postponed	No
10.11	Interworking with non-3GPP systems
10.12	Others
11	Voice and Video Enhancement for LTE (RAN2-led) WI	R3‑163051	LS to SA4 on RAN-assisted codec adaptation solution (To: 3GPP SA4, CC: 3GPP RAN3)	3GPP RAN2, Huawei	LS in		Yes	YesRAN3 chair: let's see reply from SA4 in R3-163065 conclusion: no LS answer to RAN2	noted	No
		R3‑163065	Reply LS on RAN-Assisted Codec Adaptation (To: 3GPP RAN2, Cc: 3GPP RAN3, 3GPP SA2, 3GPP TSG RAN)	3GPP SA4, Intel	LS in		Yes	Yesconclusion: no LS answer to SA4	noted	No
		R3‑162819	Correction of handling of GBR bearer in the MME	Nokia, Alcatel-Lucent Shanghai Bell, Huawei	draftCR		Yes	Yesconclusion: TR 36.750 is a RAN2 TR and draft CR will be provided to RAN2 for agreement via MCC	endorsed	No
		R3‑162875	Support of Redirection for VoLTE	Huawei	CR	Agreement	Yes	YesEricsson: first sentence is not needed, alignment with Nokia's R3-162819	revised	No	R3‑163086	R3‑162507
		R3‑163086	Support of Redirection for VoLTE	Huawei	CR	Agreement	Yes	YesRAN3 chair: we will see on Fri whether we will agree or just endorse the CR (depending on whether WI can be completed in Dec. 16 or not) conclusion: endorsed as baseline CR and will not be sent to RAN #74 as WI is not yet complete	endorsed	No		R3‑162875
		R3‑162876	[Draft] LS on support of redirection for VoLTE	Huawei	LS out	Approval	Yes	YesEricsson: some rewording needed, align with CRs, keep GBR bearer, is an optimisation and not a signalling enhancement Nokia: can we send the LS if CR is not yet agreed? Ericsson: was not planning to talk about a CR but rather about the solution that we have agreed	revised	No	R3‑163087
		R3‑163087	[Draft] LS on support of redirection for VoLTE	Huawei	LS out	Approval	Yes	Yes	revised	No	R3‑163231	R3‑162876
		R3‑163231	[LS on support of redirection for VoLTE (to: SA2; cc: RAN2; contact: Huawei)	Huawei	LS out	Approval	Yes	Yesconclusion: revised as it still says "Draft" in the title	revised	No	R3‑163247	R3‑163087
		R3‑163247	[LS on support of redirection for VoLTE (to: SA2; cc: RAN2; contact: Huawei)	Huawei	LS out	Approval	Yes	Yes	approved	No		R3‑163231
12	LTE-based V2X Services (RAN1-led) WI	R3‑163050	Response LS on Multiple TMGIs for support of small and variable MBMS areas. (To: 3GPP RAN3, CC: 3GPP SA2)	3GPP RAN2, Nokia	LS in		Yes	Yesconclusion: no LS answer to RAN2	noted	No
		R3‑163079	Reply LS to S2-164927 on QoS requirements for V2X (S1-163425; to: SA2, RAN2, CT1; cc: RAN1, RAN3; contact: Qualcomm)	SA1, Qualcomm	LS in	discussion	Yes	Yesconclusion: no LS answer to SA1	noted	No
		R3‑163068	CB: # 1_Report_V2X: Chairman's notes for the session on LTE-based V2X Services	Ericsson	report	Approval	Yes	Yes	endorsed	No
12.1	SC-PTM and MBSFN architecture	R3‑162663	Introduction of localized MBMS deployment for V2X	LG Electronics Inc., CATT, Huawei	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR and later revised to include latest agreements	revised	No	R3‑163233	R3‑162509
		R3‑163233	Introduction of localized MBMS deployment for V2X	LG Electronics Inc., CATT, Huawei	draftCR	Endorsement	Yes	Yesconclusion: endorsed as new baseline CR unseen, will not be submitted to RAN2	endorsed	No		R3‑162663
		R3‑162711	Introduction of localized MBMS deployment for V2X	LG Electronics Inc.	draftCR	Endorsement	No	Yes	withdrawn	Yes		R3‑162509
		R3‑162659	Introduction of new period values for V2X	LG Electronics Inc.	discussion		Yes	Yes	noted	No
		R3‑162660	Introduction of new period values for V2X	LG Electronics Inc.	CR	Agreement	Yes	YesHuawei: how can MME know that this is for V2X service? our assumption is that MCE will know that this is for V2X CATT: thinks it could be used for other services ZTE: can be used also for other services Huawei: we need to decide how MCE will know that this is V2X service Nokia: MCH Scheduling Period and MCH Scheduling Period Extended should be ignored Nokia: RAN2 did not yet agree their CR, so a part should be ffs session chair: do we add it to the baseline CR or do we wait for RAN2 decision? conclusion: extend existing MCH Scheduling Period Extended IE (depending on RAN2), correct typo	revised	No	R3‑163182
		R3‑163182	Introduction of new period values for V2X	LG Electronics Inc.	CR	Endorsement	Yes	YesEricsson: includes changes on changes Nokia: there is also an ASN.1 issue	revised	No		R3‑162660
		R3‑163232	Support of small and variable MBMS areas for V2X	LG Electronics Inc.	CR	Endorsement	Yes	Yesconclusion: endorsed unseen as baseline CR and CR will not be provided to RAN2	endorsed	No		R3‑163182
		R3‑162665	Support of small and variable MBMS areas for V2X	LG Electronics Inc.	discussion		Yes	Yes	noted	No
		R3‑162667	Support of small and variable MBMS areas for V2X	LG Electronics Inc.	draftCR		Yes	YesHuawei: what is multiple TMGI needs to be explained CATT: agrees with Huawei, in our CR we add some more wording in R3-162698 Nokia: whether single or multiple TMGI to be used is rather an SA2 CR LG: we agreed this text before session chair: agrees with LG ZTE: supports Nokia view session chair: since this is a deployment option we should not have too much text here	revised	No	R3‑163184
		R3‑163184	Support of small and variable MBMS areas for V2X	LG Electronics Inc.	draftCR	-	Yes	YesEricsson: localized deployment scenarios documented (not specified) is preferred LG: prefers to update this next time conclusion: "specified" can be changed to "documented" next time (if needed); will be included in baseline CR (revision of R3-162663 in R3-163233)	agreed	No		R3‑162667
		R3‑162697	Discussion on support of small and variable areas for V2X	CATT	discussion	Decision	Yes	Yes	not treated	No
		R3‑162698	Support of small and variable areas for V2X	CATT	draftCR	Approval	Yes	Yesconclusion: offline discussion, remaining aspects of R3-162698 will be merged into R3-163184	merged	No
		R3‑162883	Support of multiple operators for V2X	CMCC, CATT	discussion	Decision	Yes	Yesmoved from AI 12.3 to AI 12.1 Proposal 1: The usage scenario 2 should be de-prioritized. Proposal 2: RAN3 is requested to discuss whether to send LS to SA2 to check if the usage scenario is valid. Observation 3: No standard impact to RAN3 to support usage scenario 3. Proposal 3: RAN3 is request to discuss and agree to capture the usage scenario 1 and 3 into stage 2 to support multiple operators. Proposal 4: RAN3 is kindly asked to agree the attached CR [4] to capture the usage scenario 1 and 3.	noted	No
		R3‑162884	Support of multiple operators for V2X	CMCC, CATT	draftCR	Agreement	Yes	Yesmoved from AI 12.3 to AI 12.1 Nokia: we agreed in the past that this is pending on other WGs ZTE: supports to capture text in the spec but scenario 2 is not very clear; scenarion1 and 3 coming from SA2? Nokia: scenario 2 is depending on WG ZTE: if from SA2 this also involves inter-PLMN operation session chair: we said in the past that inter-PLMN operation depends on other WGs, what has changed? Qualcomm: no requirements from SA2 to do scenario 2 CMCC: we wanted to make some progress instead of just waiting for SA2 ZTE: supports to send an LS to SA2 to check whether conclusion: scenario 1 is regular network sharing, scenario 2 depends on SA2, suggests to contact SA2 delegates avoiding an LS (SA2 is free to send an LS to RAN3 to clarify/request)	postponed	No
12.2	Authorization	R3‑162671	Authorization for Pedestrian UE over S1	LG Electronics Inc., Huawei, CATT, ZTE	CR	Agreement	Yes	Yesconclusion: endorsed as baseline CR	endorsed	No		R3‑162510
		R3‑162674	Authorization for Pedestrian UE over X2	LG Electronics Inc., Huawei, CATT, ZTE	CR	Agreement	Yes	Yesconclusion: endorsed as baseline CR in the first place and afterwards revised to include new agreements	revised	No	R3‑163185	R3‑162511
		R3‑163185	Authorization for Pedestrian UE over X2	LG Electronics Inc., Huawei, CATT, ZTE	CR	Agreement	Yes	Yeswill include R3-162699 conclusion: endorsed as baseline CR and will not be provided to RAN	endorsed	No		R3‑162674
		R3‑162664	Adding V2X Services Authorized IE to RETRIEVE UE CONTEXT RESPONSE massage	Nokia, Alcatel-Lucent Shanghai Bell	other		Yes	Yes	rejected	No
		R3‑162699	V2X Authorization via RETRIEVE UE CONTEXT RESPONSE	CATT	CR	Agreement	Yes	Yesconclusion: will be merged in baseline CR R3-162674	agreed	No
12.3	UE-PC5-AMBR	R3‑162719	Introduction of UE PC5 AMBR over S1	CATT, ZTE, Huiawei	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR	endorsed	No		R3‑162571
		R3‑162720	Introduction of UE-PC5-AMBR	Huawei, CATT	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR	endorsed	No		R3‑162572
		R3‑163186	Way forward on V2X	LG Electronics	discussion	discussion	Yes	Yessummary of agreements and open isssues after RAN3 #94	endorsed	No
12.4	Others
13	Multi-Carrier Enhancements for UMTS (RAN2-led) WI	R3‑162721	Introduction of MC configuration	Huawei	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR and later revised to add new agreements	revised	No	R3‑163187	R3‑162582
		R3‑163187	Introduction of MC configuration	Huawei	CR	Agreement	Yes	Yes	agreed	No		R3‑162721
		R3‑162722	Introduction of MC configuration	Huawei	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR and later revised to add new agreements	revised	No	R3‑163188	R3‑162583
		R3‑163188	Introduction of MC configuration	Huawei	CR	Agreement	Yes	Yes	agreed	No		R3‑162722
		R3‑162910	Configuration impacts of Dual Cell E-DCH operation enhancements	Huawei	discussion		Yes	YesProposal 1: It is proposed RAN3 to agree remove the FFS for RRC configuration IEs and add an “Additional E-DCH Maximum Set of E-DPDCHs” IE in the baseline CRs. Proposal 2: It is proposed RAN3 to agree remove the new DTX information in the baseline CRs. Ericsson: not so keen to align with RAN2 naming, in RAN3 specs we have dual band and dual cell; maybe we need to align our RAN3 terminology first before we simply align here with RAN2 Huawei: no strong view if we have a better name Ericsson: for all new IEs we can avoid "additional" Ericsson: having as optional IE Nokia: we are fine with both Huawei proposals Ericsson: to proposal 2: 10ms TTI in mixed configuration to be checked Huawei: agrees that there can be some ambiguity when removing new DTX information, e,g, abnormal case to be checked Ericsson: we have a Tdoc to this in R3-162995 vice-chair: let's see R3-162995 Ericsson: dual cell means same band in RAN3 (RAN3 is having also dual band to indicate different frequencies) Huawei: is this defined anywhere? RAN2 uses "dual cell" but this can mean different frequencies conclusion: naming to be clarified to have it consistent in RAN3 and aligned with RAN2	noted	No
		R3‑162995	Addition of the abnormal case for the introduction of Multi-carrier Enhancement	Ericsson	discussion		Yes	YesProposal 1: RAN3 to discuss and agree on the new abnormal condition, refer to [4], [5]. conclusion: we will an abnormal condition (wording to be discussed offline and can be directly included in the 2 baseline CRs)	noted	No
		R3‑162996	Addition of the abnormal case for the introduction of Multi-carrier Enhancement	Ericsson	CR	Agreement	Yes	Yes	not treated	No
		R3‑162997	Addition of the abnormal case for the introduction of Multi-carrier Enhancement	Ericsson	CR	Agreement	Yes	Yes	not treated	No
		R3‑162911	Introduction of Dual Cell E-DCH operation enhancements configuration	Huawei	other		Yes	YesNokia: + should be changed into "and" Huawei: we can align this, also 25.300 needs alignment? conclusion: agreed with the understanding that - the prefix "additional" can be removed - the "dual cell" naming - replacing + by and will be fixed in baseline CR	agreed	No
		R3‑162912	Introduction of Dual Cell E-DCH operation enhancements configuration	Huawei	other		Yes	Yesconclusion: agreed with the understanding that - the prefix "additional" can be removed - the "dual cell" naming - replacing + by and will be fixed in baseline CR	agreed	No
		R3‑162913	Enhanced TTI switching of Dual Cell E-DCH operation enhancements	Huawei	discussion		Yes	YesProposal 1: It is proposed RAN3 to agree to introduce a new indication for the RNC to request the Node B forwarding filtered UPH value on the secondary frequency reported from UE. Proposal 2: It is proposed RAN3 to agree to introduce the new IE for UPH value on secondary frequency. Ericsson: proposal 1: no additional indication needed Nokia: supports Ericsson Ericsson: for proposal 2 we have an alternative in R3-162998	noted	No
		R3‑162998	Introduction of fast TTI switching in Multi-carrier Enhancements	Ericsson	discussion		Yes	YesProposal 1: It is proposed that RAN3 to discuss and agree on using the legacy UPH Filtering reporting to support the fast TTI switching in Multi-carrier enhancements feature. Only semantic modification is needed. Huawei: new IE (R3-162913) or reintegrating existing IE (R3-162998) is the question, still some concern whether reintegration is possible Ericsson: does not think that the reintegration is problematic vice-chair: heard from offline discussion that Nokia supports R3-162998, as the target is to complete the WI by end of this year, is there a way forward? Nokia: Ericsson solution is simpler but may have one problem (2 UL messages to inform RNC ... ping-pong case) Ericsson: in both we have one filtering report in one message so it applies to both proposals Nokia: then we will need a third solution Ericsson: but this would mean 2 filtering reports in 1 message but 90% of the time UE would send just 1 report; RAN1 has not clarified how many reports, we would prefer 1 report per message only Nokia: 2 reports will avoid ping-pong case (for 10+10, 10+2, 2+10) vice-chair: we could go with 1 report so far and if there is a problem we can still correct this (ASN.1 freeze is in March17) otherwise we may have problems to agree the CRs this week Huawei: requests some more offline discussion Ericsson: RAN1 and RAN2 have already finished so we should be able to find a compromise vice-chair: do we know at least whether we start the discussion from Huawei or Ericsson CR? Nokia: Huawei and Ericsson proposals are still on option 1, we would still discuss option 2 in the offline discussion Huawei: option 2 is not necessary conclusion: offline discussion to decide with approach will be taken, result will be covered in baseline CRs	noted	No
		R3‑162914	Introduction of enhanced TTI switching of Dual Cell E-DCH operation enhancements	Huawei	CR	Agreement	Yes	Yes	not treated	No
		R3‑162915	Introduction of enhanced TTI switching of Dual Cell E-DCH operation enhancements	Huawei	CR	Agreement	Yes	Yes	not treated	No
		R3‑162999	Introduction of fast TTI switching in Multi-carrier Enhancements	Ericsson	CR	Agreement	Yes	Yes	not treated	No
		R3‑163000	Introduction of fast TTI switching in Multi-carrier Enhancements	Ericsson	CR	Agreement	Yes	Yes	not treated	No
		R3‑163069	CB: # 2_Report_Mce: Chairman's notes for the session on Multi-Carrier Enhancements for UMTS	Vice Chairman	report	Approval	Yes	YesWI will be completed at RAN #74	endorsed	No
		R3‑163126	LS on RAN1 progress on MC enhancements (R1-1613208; to: RAN2, RAN3; cc: -; contact: Huawei)	RAN1	LS in	discussion	Yes	Yesconclusion: no LS answer to RAN1	noted	No
14	New Work Item on Enhanced LTE WLAN Radio Level Integration with IPsec Tunnel (eLWIP) WI	R3‑162707	WLAN Measurement Framework for eLWIP	Telekom Research & Development Sdn. Bhd.	discussion		Yes	YesProposal 1: Improving the WLAN measurement framework for LWIP should be based on WLAN measurement delivery from LWIP-SeGW to eNB due to periodic WLAN measurement putting burden on LTE air interface. Proposal 2: Utilize the LWIP tunnel and reuse the LWIPEP protocol to deliver the WLAN measurement shall be considered to deliver the WLAN measurement from LWIP-SeGW to eNB. Ericsson: unclear how this is planned to be used, throughput measurements not done in gateway Telekom Research: should be done in UE Nokia: reporting UE measurements via WLAN is completely new; RAN3 chair: is it part of the WI scope? Nokia: this is a grey zone, at least it is not part of the 2 CR sets under AI 8.3 Ericsson: is rather a RAN2 than a RAN3 issue conclusion: may discuss offline and bring CRs next time if RAN3 is impacted	noted	No
15	eMBMS enhancements in LTE (RAN1-led) WI	R3‑163002	Different PLMN IDs and Enhanced TV Services	Ericsson	discussion		Yes	Yes	noted	No
		R3‑163003	PLMN ID Check and Enhanced TV Services	Ericsson	draftCR		Yes	YesHuawei: CR could be misleading Ericsson: if you do this check, it can still work but then it's up to configuration Qualcomm: when we got LS from SA2, this was discussed; we said currently there is no restriction and so there is problem; has no problem with the CR but the change is not really needed; RAN3 chair: can we rephrase the text in a positive way as we usually do not specify what we do not do; Ericsson: it seems there is consensus that there is no need to check and we can discuss the wording Ericsson: for enhanced TB services and we can turn the 2 sentences into notes conclusion: we will have a note, exact text can be discussed offline	revised	No	R3‑163088
		R3‑163088	PLMN ID Check and Enhanced TV Services	Ericsson	draftCR	-	Yes	Yesconclusion: endorsed as baseline CR and will not be provided to RAN2	endorsed	No		R3‑163003
16	DTX/DRX enhancements in CELL_FACH (RAN2-led) WI	R3‑162710	Introduction of DRX enhancements	HuaWei Technologies Co., Ltd	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR and later revised to add new agreements	revised	No	R3‑163197	R3‑162385
		R3‑163197	Introduction of DRX enhancements	HuaWei Technologies Co., Ltd	CR	Agreement	Yes	Yes	agreed	No		R3‑162710
		R3‑162724	Introduction of DRX enhancements	Huawei	draftCR	Endorsement	Yes	Yes	revised	No	R3‑163181	R3‑162584
		R3‑163181	Introduction of DRX enhancements	Huawei	draftCR	Endorsement	Yes	Yesvice-chair: includes in principle R3-163005 changes with some rewording conclusion: offline discussion to address: - name of new IE - details of abnormal conditions (a long the lines of R3-163005) - semantics descriptions (HS-SCCS or HS-DSCX)	revised	No	R3‑163196
		R3‑163196	Introduction of DRX enhancements	Huawei, Ericsson	CR	Agreement	Yes	Yes	revised	No	R3‑163240	R3‑163181
		R3‑163240	Introduction of DRX enhancements	Huawei, Ericsson	CR	Agreement	Yes	Yes	agreed	No		R3‑163196
		R3‑163004	DTX/DRX enhancements in CELL_FACH	Ericsson	discussion		Yes	YesProposal 1: RAN3 to agree to implement the configuration of the Rel 14 DRX/DTX scheme in Physical Shared Channel Reconfiguration procedure.	noted	No
		R3‑163005	DTX/DRX enhancements in CELL_FACH	Ericsson	CR	Agreement	Yes	Yesconclusion: not agreed, see R3-163181 instead	rejected	No
		R3‑162907	DRX enhancements in CELL_FACH	Huawei	discussion		Yes	Yes	noted	No
		R3‑162908	Introduction of DRX enhancements	Huawei	other		Yes	Yes	revised	No	R3‑163183
		R3‑163183	Introduction of DRX enhancements	Huawei	other	-	Yes	YesEricsson: would like to check a bit more vice-chair: only change compared to the baseline CR is one sentence? Huawei: yes	agreed	No		R3‑162908
		R3‑163070	CB: # 3_Report_DTXDRX: Chairman's notes for the session on DTX/DRX enhancements in CELL_FACH	Vice Chairman	report	Approval	Yes	No	available	No
17	Flexible eNB-ID and Cell-ID in E-UTRAN WI	R3‑162714	Introduction of New types of eNB ID	Huawei, China Telecom	draftCR	Endorsement	Yes	YesHuawei: no change RAN3 vice-chair: if we get an LS this week and a CR can be agreed, then will make this a CR Ericsson: we had the agreement to put the SIZE for bitstring conclusion: for new IEs they will be introduced with SIZE	endorsed	No		R3‑162564
		R3‑162715	Introduction of New types of eNB ID	Huawei, China Telecom	draftCR	Endorsement	Yes	YesHuawei: no change RAN3 vice-chair: if we get an LS this week and a CR can be agreed, then will make this a CR Nokia: Why did you use "SIZE"? Huawei: there was an agreement in the past for bitstring in tabulars RAN3 vice-chair: it seems at the moment we are not yet consistent in the spec conclusion: for new IEs they will be introduced with SIZE	endorsed	No		R3‑162565
		R3‑162716	Introduction of New types of eNB ID	Huawei, China Telecom	draftCR	Endorsement	Yes	YesHuawei: no change RAN3 vice-chair: if we get an LS this week and a CR can be agreed, then will make this a CR Nokia: ASN.1 has an extra comma which needs to be removed conclusion: for new IEs they will be introduced with SIZE and comma in ASN.1	revised	No	R3‑163101	R3‑162566
		R3‑163101	Introduction of New types of eNB ID	Huawei, China Telecom	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR	endorsed	No		R3‑162716
		R3‑162717	Introduction of New types of eNB ID	Huawei, China Telecom	draftCR	Endorsement	Yes	YesHuawei: no change RAN3 vice-chair: if we get an LS this week and a CR can be agreed, then will make this a CR conclusion: for new IEs they will be introduced with SIZE	endorsed	No		R3‑162567
		R3‑162718	Introduction of New types of eNB ID	Huawei, China Telecom	draftCR	Endorsement	Yes	Yesconclusion: for new IEs they will be introduced with SIZE	endorsed	No		R3‑162568
		R3‑162713	Introduction of New types of eNB ID	Huawei, China Telecom	draftCR	Endorsement	Yes	YesNokia: some note numbering needed Ericsson: question whether we will need stage 2 at all because the note applies to all procedures touching eNB ID Nokia: eNB ID is received from the UE in an ambiguous way so it makes sense to have this note; in other places it is not by configuration, it is explicitly mentioned Finally Huawei and Nokia were fine without adding the note conclusion: no need for a stage 2 CR but it is common understanding that the eNB may differentiate the macro eNB ID by configuration	rejected	No		R3‑162563
		R3‑163006	Remove impact on LTE stage 2 from Flexible eNB-ID and Cell-ID WI	Ericsson	discussion		Yes	Yes	noted	No
		R3‑163102	Way forward on fexible eNB ID	Huawei	discussion	discussion	Yes	Yesconclusion: endorsed, RAN3 is waiting for LS feedback from SA5 before closing the WI	endorsed	No
		R3‑163071	CB: # 4_Report_FNBID: Chairman's notes for the session on Flexible eNB-ID and Cell-ID in E-UTRAN	Vice Chairman	report	Approval	Yes	Yes	endorsed	No
		R3‑163239	Reply LS to R3-162637 on Flexible eNB-ID and Cell-ID in E-UTRAN (S5-166410; to: RAN3; cc: CT1, CT4, RAN2, RAN6, SA2; contact: Ericsson)	SA5	LS in	discussion	Yes	YesRAN3 chair: assumes that this will be further discussed at next RAN3 meeting conclusion: no LS answer to SA5	noted	No
18	Other WI/SIs with impact on RAN3
18.1	Rapporteur SID summarize
18.2	Band completion	R3‑162801	Introduction of band 48	Nokia	CR	Agreement	Yes	Yessee R3-163132 instead	withdrawn	Yes
		R3‑162803	Introduction of band 48	Nokia	CR	Agreement	Yes	Yessee R3-163133 instead	withdrawn	Yes
		R3‑163132	Introduction of band 48	RAN4 (Nokia)	CR	discussion	Yes	Yes	agreed	No
		R3‑163133	Introduction of band 48	RAN4 (Nokia)	CR	discussion	Yes	NoEricsson: 25.466 is RAN3 business only and should have not been submitted to RAN4 MCC: ok, will make sure that RAN4 informed as well	available	No
18.3	Other
19	Further Enhancements to LTE Device to Device, UE to Network Relays for IoT and Wearables (RAN2-led) SI	R3‑163007	Service Continuity and Mobility	Ericsson	discussion		Yes	No	available	No
20	Further Mobility enhancement in LTE (RAN2-led) WI	R3‑163055	LS on RAN2 agreements for mobility enhancement (To: 3GPP RAN3, CC: 3GPP RAN1, 3GPP RAN4)	3GPP RAN2, Intel	LS in		Yes	Yesmoved from AI 8.1 to AI 20 Ericsson: source makes a decision and indicates this on X2 IP level to target? Nokia: no, RAN2 suggests to include this in RRC container for handover; Ericsson: what does the target do with it? Nokia: target copies it in the handover command; the indicator that trggers make before break conclusion: no LS answer to RAN2 so far	replied to	No
		R3‑163164	Draft Reply R2-167312 = R3-163055 on RAN2 agreements for mobility enhancement (to: RAN2, cc: RAN1, RAN4; contact: ZTE)	ZTE	LS out	Approval	Yes	YesSamsung: prefers a working assumption: MeNB decides to activate MBB solution and the MeNB informs the SeNBb by adding an IE in SeNB Release Request message RAN3 chair: we have no stage 3 agreed so we can postpone the LS; we should have an agreement first before writing an LSout and not the other way around	revised	No	R3‑163255
		R3‑163255	Draft Reply R2-167312 = R3-163055 on RAN2 agreements for mobility enhancement (to: RAN2, cc: RAN1, RAN4; contact: ZTE)	ZTE	LS out	Approval	No	No	reserved	No		R3‑163164
		R3‑162652	Further RAN3 actions for make-before-break	Nokia, Alcatel-Lucent Shanghai Bell	discussion		Yes	YesProposal 1: If the new procedure proposed by RAN2 is agreed by RAN3, avoid any reference to handover success. Proposal 2: Standardize the new X2 signaling proposed by RAN2 only if data forwarding option 2 is agreed by RAN3. Proposal 3: Mbb activation to be based on signaling using X2AP IEs. Proposal 4: Standardize mbb HO activation based on option 2.	noted	No
		R3‑162653	Activation of make-before-break HO	Nokia, Alcatel-Lucent Shanghai Bell	CR	Agreement	Yes	YesRAN3 chair: need for IE in acknowledgement can be checked further Ericsson: reference to stage 2 description? RAN2 has a stage 2 baseline CR? Nokia: yes, is in line with what we saw in LS Ericsson: but from a source point of view? Nokia: eNB should continue to transmit data Ericsson: source would continue to send RAN3 chair: it seems stage 3 CR does not mandate a behaviour Samsung: source eNB and UE should have synchronized behaviour RAN3 chair: is an optimization, do we want to consider it? ZTE: problems with dual connectivity Nokia: Samsung had a related input RAN3 chair: so let's have a look at R3-162747 then Nokia: we could merge into R3-163162 conclusion: aspect will be merged into R3-163162	merged	No
		R3‑162747	Make before break solution in SeNB change scenario	Samsung	discussion	Decision	Yes	YesProposal 1: It is proposed to agree that the MeNB decide to activate Make before break solution for SeNB change procedure. Proposal 2: It is proposed to include makeBeforeBreak indication to SeNB Release Request message.	noted	No
		R3‑162748	Support SeNB change for "Maintain source eNB connection solution"	Samsung	CR	Agreement	Yes	YesHuawei: why do you want to keep SENB? Samsung: for split bearer you do not need it but you need it for another case ZTE: RAN2 has already analysed such a scenario so we do not wait further RAN3 chair: we have one solution that works without RAN3 impact and we have now 2 optimisation proposals (R3-162653, R3-162748) Samsung: is not an optimisation RAN3 chair: why do you want to still send data to the UE? ZTE: we agree with Samsung proposal Huawei: there is no agreement in RAN2 about the same proposal, WI is RAN2 led ZTE: we proposed something similar, supported a number of operators Huawei: is a rather a RAN2 issue Samsung: spec impact is in RAN3 NEC: so this is just for SCG-BR? conclusion: offline discussion, also ASN.1 needed, dependency with RAN2 to be checked	revised	No	R3‑163162
		R3‑163162	Support SeNB change for "Maintain source eNB connection solution"	Samsung	CR	Agreement	Yes	Yeswill include aspects of R3-162653 RAN3 chair: no stage 2 CR exists so far Intel: M-eNB or s-ENB makes the decision? Samsung: M-eNB	postponed	No		R3‑162748
		R3‑162654	Impacts of data forwarding option 2	Nokia, Alcatel-Lucent Shanghai Bell	discussion		Yes	YesEricsson: not sure why this is needed in SN transfer message? conclusion: rely on implementation is possible; can discuss further and come back, attempt for option 2 stage 2/3 CRs	noted	No
		R3‑162745	Data forwarding options for the make-before-break LTE mobility enhancement	Samsung	discussion	Decision	Yes	Yes	noted	No
		R3‑162746	Introduction of "Maintain source eNB connection solution"	Samsung	CR	Agreement	Yes	YesRAN3 chair: default is option 1, it seems option 2 is not understood conclusion: Nokia can try to come up with some CRs on option 2	rejected	No
		R3‑162734	Impacts on RAN3 by Down-selected ME Solutions	ZTE, China Telecom, China Unicom	discussion		Yes	Yes	revised	No	R3‑163090
		R3‑163090	Impacts on RAN3 by Down-selected ME Solutions	ZTE, China Telecom, China Unicom	discussion	-	Yes	No	available	No		R3‑162734
		R3‑162735	Draft ME Stage2	ZTE, China Telecom, China Unicom	draftCR		Yes	Yes	revised	No	R3‑163091
		R3‑163091	Draft ME Stage2	ZTE, China Telecom, China Unicom	draftCR	-	Yes	YesEricsson: is this to be discussed in RAN2, there is another RAN2 stage 2 CR? ZTE: yes Nokia: if we go for option 2 then we should go for a simpler option RAN3 chair: ZTE proposal seems to be a 2nd proposal compared to the Nokia/Samsung approach, any chance to merge? ZTE: our CRs cover also handover Ericsson: latest stage 2 from RAN2 includes also data forwarding and we should check this RAN3 chair: rapporteur should provide the stage 2 from RAN2 for information to next RAN3 meeting Ericsson: we have 2 data frowarding options, how do we continue with this? Nokia: ZTE CR should just cover option 1 Samsung: RAN2 rapporteurs will leave data forwarding discussion to RAN3, so we should agree a stage 2 data forwarding CR and provide it to RAN2 for agreement Nokia: has a stage 2 CR in R3-163223 ZTE: from rapporteur's point of view we are disappointed that we cannot agree Ericsson: would like to see a full set of CRs and there is no need to rush ZTE: would like to have at least a baseline CR for stage 2	postponed	No		R3‑162735
		R3‑163223	Enable simultaneous radio transmission and data forwarding for Make-Before-Break handover	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	discussion	Yes	YesEricsson: sending without freezing? Nokia: yes, have also a stage 3 CR for this Ericsson: wondering whether this is a good solution, trying to squeeze out milliseconds out of the handover but not having concrete time steps RAN3 chair: we will not complete the WI this time so we can take this as starting point for next time	postponed	No
		R3‑163224	Enable simultaneous radio transmission and data forwarding for Make-Before-Break handover	Nokia, Alcatel-Lucent Shanghai Bell	other	discussion	Yes	YesRAN3 chair: we will not complete the WI this time so we can take this as starting point for next time	postponed	No
		R3‑162736	Draft ME Stage3	ZTE, China Telecom, China Unicom	draftCR		Yes	Yes	revised	No	R3‑163092
		R3‑163092	Draft ME Stage3	ZTE, China Telecom, China Unicom	draftCR	-	Yes	No	available	No		R3‑162736
		R3‑163245	Way forward on mobility enhancements for LTE	ZTE	discussion	discussion	Yes	Yes	revised	No	R3‑163256
		R3‑163256	Way forward on mobility enhancements for LTE	ZTE	discussion	discussion	No	No	reserved	No		R3‑163245
21	Signalling reduction to enable light connection for LTE (RAN2-led) WI	R3‑163043	Reply LS on the progress and questions for the light connection (To: 3GPP RAN2, Cc: 3GPP SA2, 3GPP RAN3)	3GPP CT1, Huawei	LS in		Yes	Yesconclusion: no LS answer to CT1	noted	No
		R3‑163052	LS on S-TMSI in RAN paging (To:3GPP SA3, Cc: 3GPP RAN3, 3GPP CT1)	3GPP RAN2, Ericsson	LS in		Yes	Yesconclusion: no LS answer to RAN2	noted	No
		R3‑163057	LS on The progress and questions for the light connection (To: 3GPP RAN3, 3GPP CT1, CC: 3GPP SA2)	3GPP RAN2, Huawei, Intel	LS in		Yes	Yes	replied to	No
		R3‑163122	Reply to: LS on The progress and questions for the light connection (to: RAN2; cc: CT1, SA2; contact: Huawei)	Huawei, Intel	LS out	Approval	Yes	YesRAN3 chair: do we send or withdraw the LS (because we got already an LSin that RAN2 acknowlegde this)? Nokia: has some editorials Huawei: we can fix editorials	revised	No	R3‑163237
		R3‑163237	Reply to R2-167314 on The progress and questions for the light connection (to: RAN2; cc: CT1, SA2; contact: Huawei)	RAN3	LS out	Approval	Yes	Yes	approved	No		R3‑163122
		R3‑163080	Reply LSto R3-162642 on Light Connected UE (S3-162087; to: RAN3; cc: RAN2; contact: Intel)	SA3, Intel	LS in	discussion	Yes	YesNokia: SA3 acknowledges that both options are possible RAN3 chair: but option 2 is already there but for option 1 we would need to get back to SA3 conclusion: no LS answer to SA3 so far	noted	No
		R3‑163082	Reply LS to R2-167293 on S-TMSI in RAN paging (S3-162123; to: RAN2; cc: RAN3, CT1; contact: Ericsson)	RAN2, Ericsson	LS in	discussion	Yes	Yesconclusion: no LS answer to RAN2	noted	No
		R3‑163203	LS on The progress for the light connection (R2-168955; to: RAN3, CT1; cc: -; contact: Huawei)	RAN2	LS in	discussion	Yes	Yesconclusion: no LS answer to RAN2	noted	No
21.1	Stage 2 and Stage 3	R3‑162756	Consideration of Light connection open issues	Huawei, China Unicom	discussion	Decision	Yes	YesNokia: agrees that open isssues 7 and 9 do not contradict each other RAN3 chair: we have 2 sets of CRs and we should have a look at them quickly before we handle the proposals of R3-162756 one by one Intel: on X2 most of both CR sets are aligned, on stage 2 there are 2 aspects which are not aligned Open Issue 1: Paging Area of the UE in light connection RAN3 chair: list of cells, list of TAs Nokia: also list of paging areas, instead of N cells you define a paging areas (cell broadcast the paging area) Ericsson: RAN2 has not taken into account the paging optimisation in last REL conclusion: open issue 1 to be decided by RAN2 Open Issue 2: X2 context fetch supporting CATT: indicator is not necessary conclusion: - add Data forwarding indication in RETRIEVE UE CONTEXT RESPONSE message: is ffs - introduce a new class2 message to carry forwarding GTP Tunnel info from the new eNB to the old eNB: iis agreed Open Issue 3: Content of X2 PAGING message conclusion: align IE in both inputs Open Issue 4: UE connects and no X2 available Samsung: has a Tdoc related to this in R3-162754, has preference for option 3 (legacy recovery case) RAN3 chair: so 2 choices: release or S1 fetch Ericsson: with release we would not optimize RAN3 chair: Nokia/Huawei: S1 context fetch but different approach than Ericsson Ericsson: if we do not progress on this one, then we do not need light connection China Unicom, Qualcomm: support to have S1 context fetch RAN3 chair: can we have a working assumption on S1 context fetch? Samsung: would prefer to wait with this decision, failure case always happens, confirmation from other groups missing (CT1/SA2) Ericsson: unclear where the SA2 impact is? RAN3 chair: R3-162760 is the Huawei approach for S1 context fetch conclusion: further offline discussion (Huawei) whether we can have a working assumption on S1 context fetch (X2 not available) Open Issue 5: eNB handling of unreachable UE in case of RAN paging failure conclusion: offline discussion (Intel) Open Issue 6: Which node to decide the suspension Nokia: we can open our R3-162938 or wait for RAN2/SA2 feedback conclusion: offline discussion (Qualcomm) Open Issue 7: How to support CP signalling in Light connection conclusion: Ericsson will provide a way forward in R3-163134 Open Issue 8: Possible Legacy functionality impact needs to be discussed if confirmed conclusion: MME is not aware when UE moves to light connectivity	noted	No
		R3‑162936	Introduction to Stage 2 and Scenarios in Light Connected mode	Nokia, Alcatel-Lucent Shanghai Bell, Huawei	discussion	Decision	Yes	No	available	No
		R3‑162937	Introduction of Light Connected State	Nokia, Alcatel-Lucent Shanghai Bell, Huawei, China Telecom, China Unicom	draftCR	Approval	Yes	YesIntel: S1 context fetch: Huawei position? Nokia: no figure, Huawei is based on existing procedure, other procedure is the new procedure Ericsson: found the proposal confusing, in our stage 2 is what is the addition compared to the existing stage 2 Nokia: benefit of this Tdoc is that it gives the full picture Intel: you have a disclaimer that RAN2 aspects will be later removed, so we have to make it concise Samsung: new anchor introduced that is at the end not used? Nokia: yes, do we need anchor eNB? RAN3 chair: mobility anchor is in MME and I questioned last time whether it is needed in RAN Ericsson: we can live with serving NEC: found "anchor" terminology in LS Intel: was in " " in RAN2 and intended to not consider this later Qualcomm: S1 interface impact may lead CT1 to start work which could endanger completion in REL-14 RAN3 chair: does not see CT impact Ericsson: we had such a case in REL-12 where there was also no impact on the architecture and there was just an alignment Nokia: S1 retrieve option has impact on SA2 conclusion: revised to remove anchor concept, update agreement, check for light connection part	revised	No	R3‑163123
		R3‑163123	Introduction of Light Connected State	Nokia, Alcatel-Lucent Shanghai Bell, Huawei, China Telecom, China Unicom	draftCR	Approval	Yes	Yes	postponed	No		R3‑162937
		R3‑162757	Introduction of light connection in X2AP	Huawei, Nokia, China Telecom, China Unicom	CR	Agreement	Yes	YesRAN3 chair: anchor concept to be removed Intel: retrieve context does not include list of IEs and NAS PDU Huawei: we can add it with ffs	revised	No	R3‑163124	R3‑162560
		R3‑163124	Introduction of light connection in X2AP	Huawei, Nokia, China Telecom, China Unicom	CR	Agreement	Yes	Yes	revised	No	R3‑163243	R3‑162757
		R3‑163243	Introduction of light connection in X2AP	Huawei, Nokia, China Telecom, China Unicom	CR	Agreement	Yes	Yes	postponed	No		R3‑163124
		R3‑162758	Introduction of light connection in S1AP	Huawei, Nokia, China Telecom,China Unicom	CR	Agreement	Yes	YesRAN3 chair: anchor concept to be removed	revised	No	R3‑163125	R3‑162161
		R3‑163125	Introduction of light connection in S1AP	Huawei, Nokia, China Telecom,China Unicom	CR	Agreement	Yes	Yes	revised	No	R3‑163244	R3‑162758
		R3‑163244	Introduction of light connection in S1AP	Huawei, Nokia, China Telecom,China Unicom	CR	Agreement	Yes	Yes	postponed	No		R3‑163125
		R3‑162959	Introduction of the light connected mode	Ericsson	draftCR	Endorsement	Yes	YesNokia: a lot of effort in ASN.1 Ericsson: we are optimising signalling, there is nothing wrong with it	revised	No	R3‑163128	R3‑162556
		R3‑163128	Introduction of the light connected mode	Ericsson	draftCR	Endorsement	Yes	Yes	postponed	No		R3‑162959
		R3‑162960	Introduction of the light connected mode	Ericsson	CR	Endorsement	Yes	YesNokia: strange to add S1 message for nothing RAN3 chair: paging information still to be added	revised	No	R3‑163129	R3‑162557
		R3‑163129	Introduction of the light connected mode	Ericsson	CR	Endorsement	Yes	Yes	postponed	No		R3‑162960
		R3‑162961	Introduction of the light connected mode	Ericsson	CR	Endorsement	Yes	YesNokia: list of TAIs should be optional in paging message	revised	No	R3‑163130	R3‑162558
		R3‑163130	Introduction of the light connected mode	Ericsson	CR	Endorsement	Yes	Yes	postponed	No		R3‑162961
		R3‑163035	Introduction of the light connection over S1	Samsung	CR	Agreement	Yes	YesNokia: we have 2 sets of CRs and we have to see what we add on top from Samsung Samsung: S1 part can be based on Huawei CRs Ericsson: prefers to take the Ericsson CRs as a basis RAN3 chair: home eNB not supported in this REL? conclusion: light connection for home eNB is not supported in REL-14 should be captured in stage 2	rejected	No
		R3‑163036	Introduction of the light connection over X2	Samsung	CR	Agreement	Yes	Yes	rejected	No
		R3‑163008	Analysis of RRC configured RAN paging area concepts	Ericsson	discussion		Yes	YesProposal: Exclude the approach to define explicit RAN Paging Areas from the concepts discussed for the Rel-14 WI on “Signalling reduction to enable light connection for LTE”. Nokia: Tdoc is confusing, a paging optimisation based on UE movements	noted	No
		R3‑163013	Issues with a cell list as UE specific paging area	Ericsson	discussion		Yes	Yes	noted	No
		R3‑162835	Context Fetch and Mobility	Qualcomm Incorporated	discussion	Decision	Yes	Yes	noted	No
		R3‑163009	Light Connection – forwarding of user data and control plane data on X2 and S1	Ericsson	discussion		Yes	No	available	No
		R3‑162939	Paging Identities used in Light Connected mode	Nokia, Alcatel-Lucent Shanghai Bell	discussion	Decision	Yes	No	available	No
		R3‑162752	Discussion on RAN initiated paging	Samsung	discussion	Decision	Yes	No	available	No
		R3‑162832	RAN Paging	Qualcomm Incorporated	discussion	Decision	Yes	No	available	No
		R3‑162759	S1 Context fetch for Light Connection	Huawei	discussion	Decision	Yes	No	available	No
		R3‑162760	Introduction of S1 context fetch	Huawei, China Unicom	CR	Agreement	Yes	NoEricsson: what would be the trigger? no failure message? Huawei: maybe we need to provide a failure indication	available	No
		R3‑163011	Analysis of eNB impacts while introducing a RAN paging area	Ericsson	discussion		Yes	No	available	No
		R3‑162753	Discussion on CP and existing functionalities	Samsung	discussion	Decision	Yes	Nomoved from AI 21.2 to AI 21.1	available	No
		R3‑162796	Mitigation of impacts to legacy functionalities from light connection	Intel Corporation	discussion	Decision	Yes	Nomoved from AI 21.2 to AI 21.1	available	No
		R3‑162938	Suspension Options for mobility out of RAN Paging Area	Nokia, Alcatel-Lucent Shanghai Bell	discussion	Decision	Yes	Yes	noted	No
		R3‑163010	On Suspending the UE a la Rel-13 upon the old eNB’s behalf	Ericsson	discussion		Yes	No	available	No
		R3‑162834	CN Impact Analysis	Qualcomm Incorporated	discussion	Decision	Yes	No	available	No
		R3‑162795	Stage-2: Support of Light connection	Intel Corporation	draftCR	Approval	Yes	No	available	No
		R3‑162833	Light Connection Model Analysis	Qualcomm Incorporated	discussion	Decision	Yes	No	available	No
		R3‑162895	CN Assisted Paging Fallback: How to make it work?	NEC	discussion	Decision	Yes	No	available	No
		R3‑163134	Way forward on control plane signalling procedure	Ericsson	discussion	discussion	No	No	reserved	No
		R3‑163135	Way forward on light connnection	Huawei	discussion	discussion	Yes	YesEricsson: offline discussion assumes that Huawei is providing such a way forward RAN3 chair: next time please provide a separate Tdoc X2 paging message: work has to continue (some progress made, details tbd) S1 context fetch function: no agreement so far to have it RAN paging failure down selection: 3 options, no conclusion so far Which node to suspend: in 1 CR set (Huawei/Nokia) easy to introduce (option 3, recommendation to the target, target takes decision) and 1 CR which does not need a recommendation and target decides (Ericsson)	noted	No
		R3‑163238	Way forward on agreements and open issues for light connection	Huawei	discussion	discussion	No	No	reserved	No
21.2	Further functionality	R3‑162694	Discussion on UE context fetch for lightly connected UE	LG Electronics Inc.	discussion		Yes	No	available	No
		R3‑162695	Discussion on open issues for lightly connected UE	LG Electronics Inc.	discussion		Yes	No	available	No
		R3‑162702	Discussion on open issues for LC	CATT	discussion	Decision	Yes	NoMCC: wrong REL in Tdoc request	available	No
		R3‑162754	Discussion on X2 absent	Samsung	discussion	Decision	Yes	Yes	noted	No
		R3‑162755	Suspend/Release in case UE requests to connect without data activity	Samsung	discussion	Decision	Yes	No	available	No
		R3‑163012	Maintaining paging assistance data during mobility and over idle-active transitions	Ericsson	discussion		Yes	No	available	No
21.3	Others	R3‑162794	Support of Light connection procedure	Intel Corporation	discussion	Decision	Yes	No	available	No
22	Further Indoor Positioning enhancements for UTRA and LTE (RAN2-led) WI	R3‑163046	LS on Multipath RSTD reporting and CRS usage together with PRS (To: 3GPP RAN2, CC: 3GPP RAN3, 3GPP RAN4)	3GPP RAN1, Ericsson, Intel	LS in		Yes	Yesconclusion: no LS answer to RAN1	noted	No
		R3‑162683	Reusing Available WLAN Measurements to Enhance E-CID	Ericsson	CR	Agreement	Yes	YesRAN3 chair: no overlap with R3-163190? Ericsson: no overlap	agreed	No		R3‑162092
		R3‑162693	Reusing Available WLAN Measurements to Enhance E-CID	Ericsson	draftCR	Endorsement	No	Yes	withdrawn	Yes		R3‑162092
		R3‑162692	Reusing Available WLAN Measurements as E-CID Assistance Data	Ericsson	draftCR	Endorsement	Yes	Yesconclusion: endorsed and will be sent to RAN2 for agreement	endorsed	No		R3‑162585
		R3‑162839	Introduction of Transmission Points for OTDOA in Shared Cell-ID Scenario and PRS based Terrestrial Beacon Systems	Qualcomm Incorporated	CR	Agreement	Yes	YesHuawei: MBSFN CP length? also CRS CP length should be sent (may be different) Ericsson: what are you using it for? Huawei: as additional assistence info for the UE Qualcomm: MBSFN subframce configuration should be sent not MBSFN CP length, would want to wait for RAN1 LS Huawei: LS will come tomorrow Ericsson: supports to wait for the LS Ericsson: redefining cells? Qualcomm: yes, is already there for TPs Nokia: number of DL frames and additional DL frames? Qualcomm: you should use one (legacy IE) or the other (new IE) Nokia: some explanation about the usage would be useful, e.g. in the request message	revised	No	R3‑163190
		R3‑163190	Introduction of Transmission Points for OTDOA in Shared Cell-ID Scenario and PRS based Terrestrial Beacon Systems	Qualcomm Incorporated	CR	Agreement	Yes	YesQualcomm: we have not yet officially received MSFN subframe related LS Huawei: we do not expect a change RAN3 chair: can we agree the CR already now? Ericsson: has seen a draft of the LS, RAN1 did not consider LPP implications but there is nothing we could do about it conclusion: agreed under the assumption that we will receive a corresponding RAN1 LS	agreed	No		R3‑162839
		R3‑162962	OTDOA Enhancements for Same-PCI Issue and Multiple TPs	Ericsson	CR	Endorsement	Yes	Yesalternative to R3-162839	rejected	No		R3‑162441
		R3‑162949	Discussion on the CSI-RSRP reporting for E-CID enhancements	Huawei	discussion		Yes	Yes	not treated	No
		R3‑162950	Introduction of CSI-RSRP for ECID enhancements	Huawei	CR	Agreement	Yes	Yes	not treated	No
		R3‑163014	Extending the Cell Portion ID Range	Ericsson	discussion		Yes	YesProposal 1: The cell portion range should be extended to be scalable to the new range of TP ID. Proposal 2: Discuss and agree the provided CR. Proposal 3: Given that Cell Portion IDs are also present in TS 29.171, RAN3 should also discuss and agree an LS to CT4 so they may update their specification if necessary.	noted	No
		R3‑163015	Cell Portion ID Extension	Ericsson	other		Yes	Yesvice-chair: since it is decoupled from the baseline CR we can have a separate CR for this	revised	No	R3‑163191
		R3‑163191	Cell Portion ID Extension	Ericsson	CR	-	Yes	Yesconclusion: agreed unseen	agreed	No		R3‑163015
		R3‑163016	[DRAFT] LS on Cell Portion ID Extension (to: CT4; cc: RAN1, RAN4; contact: Ericsson)	Ericsson	LS out	Approval	Yes	Yesconclusion: contents accepted, attachments to be added and updated	revised	No	R3‑163192
		R3‑163192	LS on Cell Portion ID Extension (to: CT4; cc: RAN1, RAN4; contact: Ericsson)	RAN3	LS out	Approval	Yes	YesLS was sent out on Thu of RAN3 #94	approved	No		R3‑163016
		R3‑163025	Incomplete further indoor positioning enhancements objectives	NextNav	discussion	Decision	Yes	YesProposal 1: RAN3 formally agree and recommend a way forward for Bluetooth and UMTS objectives and impacted specifications as currently outlined in the approved WI for Further Indoor Positioning enhancements for UTRA and LTE. One of the following options should be recommended for incomplete aspects of the WI: 1. Extend the WI to seek additional Time Units allocated for upcoming RAN WG meetings to address the Bluetooth and UMTS objectives. 2. Remove the UMTS and Bluetooth objectives from the WI that have not been completed and postpone those objectives indefinitely. 3. Move the Bluetooth and UMTS aspects from the existing WI that have not been completed to a new work item. a. Release 14 WI b. Release 15 WI vice-chair: since there hasn't been any input, companies are not interested in these aspects, and since we plan to send CRs to RAN for approval, it would be rather option 2 conclusion: no concerns were raised in RAN3 to revise the WID and to remove Bluetooth and UMTS objectives (proposal 2); status report to RAN will clarify this and also RAN3 chair will include this in his report	noted	No
		R3‑163072	CB: # 5_Report_iPos: Chairman's notes for the session on Further Indoor Positioning enhancements for UTRA and LTE	Vice Chairman	report	Approval	Yes	Yesvice-chair (Ericsson): intention is to revise the WID and to complete the WI at RAN #74 conclusion: assuming RAN3 will receive the pending RAN1 LS and WID will be revised as planned, the WI can be completed from RAN3 point of view	endorsed	No
		R3‑163246	LS on agreement on OTDOA enhancement in RAN1#87 (R1-1613755; to: RAN2, RAN3; cc: -; contact: Intel)	RAN1	LS in	discussion	Yes	Yesconclusion: no LS answer to RAN1, WI can be completed	noted	No
23	Enhanced LTE-WLAN Aggregation (LWA) (RAN2-led) WI
23.1	ANR
23.2	Information collection and feedback	R3‑163033	Introducing UE throughput indication	Qualcomm Incorporated, Intel Corporation, Xiaomi, IAESI, NEC, China Telecom	discussion	Decision	Yes	Yeswrong Tdoc type discussion in Tdoc request Ericsson: metric defined by class but who defines it? WT? Qualcomm: yes but not mandated Ericsson: configuration will have to be consistent Huawei: RAN2 is asking IEEE about accuracy, any answer to this already? Intel: since when are we using accuracy on network interfaces? we have no spec covering accuracy Ericsson: we have to take it into accouint Telecom Malaysia: for DL and UL? we refer to estimated throughput, easier for AP to calculate, UL could be considered in RAN2 Telecom Malaysia: we asked for DL and UL in the LS Qualcomm: can adapt to other metrics as well but yes we focus on DL Huawei: we should align with RAN2 Intel: will Huawei support it if we adapt to RAN2? RAN3 chair: style to be corrected, we will not send CRs to RAN from this meeting MCC: please use the proper Tdoc type, discussion Tdoc with CR cover is not acceptable Nokia: evenly distributed per UE in one access class but reported differently? Huawei: there is no need to take the exact IEEE definition, we can extend this a bit Broadcom: CR does not address the concerns we raised last meeting, it is still not UE based, report per SSID and per access class enough when reported from network Qualcomm: WT knows the RABs RAN3 chair: but if a UE has multiple RABs?	noted	No
23.3	Mobility optimization
23.3.1	Handover without WT change	R3‑162689	Inter-eNB mobility with LWA active	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR	endorsed	No		R3‑162552
		R3‑162688	Clarification that the Xw UE ID is unique within relevant node	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	YesCATT: WT UE X2AP ID is wrong Nokia: correct, should say Xw	revised	No	R3‑163136	R3‑162087
		R3‑163136	Clarification that the Xw UE ID is unique within relevant node	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR RAN3 chair: at RAN3 in Feb. we will need CRs	endorsed	No		R3‑162688
		R3‑162684	X2AP Support for Inter-eNB Mobility without WT Change	Ericsson, Nokia, Alcatel-Lucent Shanghai Bell, Intel, Ruckus, Qualcomm	CR	Endorsement	Yes	YesBrocade: Ruckus Wireless is now Brocade	revised	No	R3‑163137	R3‑162643
		R3‑163137	X2AP Support for Inter-eNB Mobility without WT Change	Ericsson, Nokia, Alcatel-Lucent Shanghai Bell, Intel, Ruckus, Qualcomm	CR	Endorsement	Yes	Yesconclusion: endorsed unseen as baseline CR, CR will not be sent to RAN #74	endorsed	No		R3‑162684
		R3‑162685	XwAP Support for Inter-eNB Mobility without WT Change	Ericsson, Intel	CR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR and afterwards revised	revised	No	R3‑163139	R3‑162640
		R3‑163139	XwAP Support for Inter-eNB Mobility without WT Change	Ericsson, Intel	CR	Endorsement	Yes	Yes	endorsed	No		R3‑162685
		R3‑162690	XwAP Support for Inter-eNB Mobility without WT Change	Ericsson, Intel	draftCR	Endorsement	No	Yes	withdrawn	Yes		R3‑162640
		R3‑162691	X2AP Support for Inter-eNB Mobility without WT Change	Ericsson, Nokia, Alcatel-Lucent Shanghai Bell, Intel, Ruckus, Qualcomm	draftCR	Endorsement	No	Yes	withdrawn	Yes		R3‑162643
		R3‑162810	Inter-eNB mobility with LWA active	Nokia, Alcatel-Lucent Shanghai Bell	other		Yes	YesNokia: we need to check whether it is fine from RAN3 side, it depends on RAN2 at the end conclusion: will come back on Fri	revised	No	R3‑163200
		R3‑163200	Inter-eNB mobility with LWA active	Nokia, Alcatel-Lucent Shanghai Bell	other	-	Yes	YesQualcomm: still a slight problem with step 12 conclusion: can check until next meeting	postponed	No		R3‑162810
		R3‑162864	UE Identity for mobility enhancement	Huawei	other		Yes	YesEricsson: we have the opposite opinion and have a Tdoc on this, if you ignore the WLAN MAC address it would be simpler Huawei: Ericsson agrees with observation 2 but has a different proposal Ericsson: observation 1 and 2 are contradicting each other CATT: WLAN MAC address should not change, but when it changes? Huawei: wrong MAC address Nokia: this is putting a requirement on the UE to not change the MAC address conclusion: change of baseline CR to 36.463 is not agreed (see R3-163017 conclusion instead)	rejected	No
		R3‑163017	Ignoring the UE WLAN MAC Address at Handover	Ericsson	discussion		Yes	YesProposal 1: Unless additional arguments are presented in favor of Option 2 (leaving WT behavior unspecified), it seems safer for RAN3 to go for Option 1 (ignore the UE WLAN MAC address if the WT XwAP UE ID is received in the WT ADDITION REQUEST message). Intel: from RAN2 perspective WLAN MAC address should not change Huwei: we could remove abnormal condition Ericsson: since we don't ignore it, we need to take into account the changed MAC address Huawei: rather suggest to reject it Nokia: is fine that new MAC address is used conclusion: noted, will cover the change in a revision of R3-162685 in R3-163139	noted	No
		R3‑163138	Ignoring the UE WLAN MAC Address at Handover	Ericsson	other	-	No	Yes	withdrawn	Yes		R3‑163017
23.3.2	Others	R3‑162750	LTE handover while keeping LWA: PDCP related security aspects	Samsung	discussion	Decision	Yes	Yesmoved from AI 23.3.1 to AI 23.3.2 Ericsson: discussion should take place in RAN2	noted	No
23.4	UL transmissions	R3‑162712	Introduction of WLAN band indication	Intel Corporation (UK) Ltd	draftCR	Endorsement	Yes	Yesconclusion: endorsed as basleine CR	endorsed	No		R3‑162553
		R3‑162727	Enabling uplink data bearers	Nokia Networks	draftCR	Endorsement	Yes	YesEricsson: text is a bit akward and should be modified Nokia: can correct this in the future conclusion: endorsed as baseline CR and afterwards revised	revised	No	R3‑163143	R3‑162622
		R3‑163143	Enabling uplink data bearers	Nokia Networks	draftCR	Endorsement	Yes	Yesincludes changes of R3-162818 conclusion: endorsed as baseline CR	endorsed	No		R3‑162727
		R3‑162726	Enabling uplink data bearers	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR and afterwards revised	revised	No	R3‑163141	R3‑162621
		R3‑163141	Enabling uplink data bearers	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	Yeswill include change of R3-162816 conclusion: endorsed as baseline CR	endorsed	No		R3‑162726
		R3‑162709	Enabling uplink data bearers	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR and revised later	revised	No	R3‑163142	R3‑162188
		R3‑163142	Enabling uplink data bearers	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR	endorsed	No		R3‑162709
		R3‑162725	Uplink bearer identification	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	Yesconclusion: endorsed as baseline CR and afterwards revised	revised	No	R3‑163140	R3‑162620
		R3‑163140	Uplink bearer identification	Nokia, Alcatel-Lucent Shanghai Bell	draftCR	Endorsement	Yes	Yeswill include change of R3-162815 conclusion: endorsed as baseline CRs	endorsed	No		R3‑162725
		R3‑162701	Discussion on routing of uplink packets	CATT	discussion	Decision	Yes	YesNokia: wrong assumption in proposal 1	noted	No
		R3‑162814	UL tunnel identification: further considerations	Nokia, Alcatel-Lucent Shanghai Bell	discussion		Yes	Yesproposals: 1) It is not necessary to enable or force the WT to inform the eNB about the method selected for the UL data transfer. 2) It is not necessary to enable flow control (delivery feedback) related to the UL data flow. 3) Instead of appending UL data to the delivery status messages, the DL data transfer PDU should be enabled for UL, too.	noted	No
		R3‑162815	Uplink bearer identification	Nokia, Alcatel-Lucent Shanghai Bell	other		Yes	YesCATT: "if DRB ID is present ...", if not included then UL transmission is not supported? Qualcomm: there is an editorial conclusion: change of baseline CR R3-162725 is agreed (editorial can be fixed as well)	agreed	No
		R3‑162816	Enabling uplink data bearers	Nokia, Alcatel-Lucent Shanghai Bell	other		Yes	Yesconclusion: change of baseline CR R3-162726 is agreed	agreed	No
		R3‑162817	Enabling uplink data bearers	Nokia, Alcatel-Lucent Shanghai Bell	other		Yes	YesEricsson: are we allowed to rename existing PDUs? Nokia: does not affect anything but just the text Huawei: why do we need the UL performance? Nokia: will need further discussion conclusion: R3-162817 is not accepted to change the baseline CR, offline discussion will be needed and potential change will then directly lead to a revision of the baseline CR R3-162709	rejected	No
		R3‑162818	Enabling uplink data bearers	Nokia, Alcatel-Lucent Shanghai Bell	other		Yes	YesRAN3 chair: we need to reword it? Nokia: there was a comment from Huawei	agreed	No
		R3‑162700	Discussion on QoS mapping for UL	CATT	discussion	Decision	Yes	YesProposal 1: the QCI-AC mapping should be statically or semi-statically, it’s not needed to do the mapping dynamically. Proposal 2: OAM is the most preferred solution due to its easy and no standard impact. Proposal 3: Static QCI-AC mapping could be provided to eNB via WT Configuration Update or Xw Setup Response. Ericsson: UE needs a default behaviour if it does not get the mapping	noted	No
		R3‑162751	QoS Mapping Transfer for UL transmission	Samsung	discussion	Decision	Yes	Yes	noted	No
		R3‑162786	UL QoS mapping for eLWA	Intel Corporation	discussion	Decision	Yes	YesIntel: information of RAN2 is not self-contained RAN3 chair: so we cannot take the container? Ericsson: sees no problem with the container Nokia: there seems to be a slight preference for dynamic; Intel indicates that transparent container has no advantage RAN3 chair: if there is no change of the information, then we send it in a transparent container; Nokia: but as this is very little information we do not need a big container for it Ericsson: if it is not a transparent container then we need to have a description what to do with the data in the eNB; Qualcomm: tends to say that a (big) container is not needed RAN3 chair: who wants a container (Broadcom, Ericsson, Samsung) and who does not (Brocade, Nokia, Intel, Qualcomm, CATT, Telecom Malaysia ....) so majority seems to not have a container	noted	No
		R3‑162787	WLAN QoS mapping in UL – first option	Intel Corporation	CR	Agreement	Yes	YesEricsson: the reason for not having a big container was to have only small amount of infoirmation, so we want to see the "2 bits". Nokia: see our proposal in R3-162812	rejected	No
		R3‑162811	Access Categories for LWA uplink bearers	Nokia, Alcatel-Lucent Shanghai Bell	discussion		Yes	Yes	noted	No
		R3‑162812	Access Category information for uplink LWA bearers	Nokia, Alcatel-Lucent Shanghai Bell	other		Yes	Yesconclusion: Tdoc is not agreed but agreed that "WLAN QoS mapping in UL is provided via signalling i.e. a few bits" (open whether abnormal condition is needed, depends on RAN2) and this will be captured in R3-163140	rejected	No
		R3‑163018	Uplink QoS Handling	Ericsson	discussion		Yes	Yes	not treated	No
		R3‑162788	UL routing for eLWA	Intel Corporation	discussion	Decision	Yes	YesProposal 1: once RAN2 agrees on the overall solution of the UL routing, we propose RAN3 to discuss how to enhance Xw signalling to convey the MAC address (to be used by the UE to populate the Address 3 field in the IEEE 802.11 MAC header) information to the eNB (to be sent to the UE). Ericsson: does it not contradict the concept of mobility set? Broadcom: UE is sending via WLAN AP to WT and is sending multiple addresses Telecom Malaysia: up to 6 MAC addresses taken into account? Intel: not applicable to meshed networks but need to check furher RAN3 chair: pending to RAN2	noted	No
		R3‑162813	Access Category information for uplink LWA bearers	Nokia, Alcatel-Lucent Shanghai Bell	other		Yes	Yesconclusion: Tdoc is not accepted to be included in baseline CR but the QoS mapping agreement will also be covered in the baseline CR R3-163143	rejected	No
23.5	Others	R3‑162896	How a Source determines Connectivity to the Same WT in inter-eNB HO?	NEC	discussion	Decision	Yes	Yesmoved from AI 23.3.2 to AI 23.5 Proposal 1: by considering the Observations made, RAN3 is respectfully requested on either an X2-based or Xw-based Signalling Solution and agree the associated CRs.	noted	No
		R3‑162897	WT Notifying neighbour eNB information on Xw	NEC	CR	Agreement	Yes	Yesmoved from AI 23.3.2 to AI 23.5 Ericsson: configuration effort: 1000s of WTs are not connected to one eNB; does not agree with the proposal NEC: 1 or 2 WT connected to one eNB but 4096 APs are possible per WT; information not visible to UE; we prefer Xw mechanism; Nokia: proposal is not really needed but has some sympathy for it Intel: sees values in the proposal Ericsson: how can we have lived without this in the past? after some handovers you learn which eNB is connected to which WT NEC: self learning approach means that first attempts will fail Huawei: does not think that something is broken Broadcom: same view as Ericsson conclusion: CR is postponed, can discuss offline e.g. to see for an X2 approach otherwise next meeting; afterwards CR was revised	revised	No	R3‑163227
		R3‑163227	WT Notifying neighbour eNB information on Xw	NEC	CR	Agreement	Yes	Yes	revised	No	R3‑163234	R3‑162897
		R3‑163234	WT Notifying neighbour eNB information on Xw	NEC	CR	Agreement	Yes	YesEricsson: reservation that the functionality will not bring much benefit conclusion: endorsed as baseline CR	endorsed	No		R3‑163227
		R3‑162898	eNB Notifying neighbour WT information on X2	NEC	CR	Agreement	Yes	Yesmoved from AI 23.3.2 to AI 23.5 conclusion: CR is postponed, can discuss offline e.g. to see for an X2 approach otherwise next meeting; afterwards CR was revised	revised	No	R3‑163228
		R3‑163228	eNB Notifying neighbour WT information on X2	NEC	CR	Agreement	Yes	Yes	rejected	No		R3‑162898
24	Study on HSPA and LTE Joint Operation SI	R3‑162925	TR 37.805, Study on HSPA and LTE Joint Operation, v1.3.0	China Unicom	draft TR	Agreement	Yes	YesEricsson: do we need to include RAN2 parts as well? Huawei: yes, they are discussing some ffs and we need to include this as well conclusion: was agreed as status before RAN3 #94 and then revised to include further agreements	revised	No	R3‑163199
		R3‑163199	TR 37.805, Study on HSPA and LTE Joint Operation, v1.4.0	China Unicom	draft TR	Agreement	No	Yesneeds to include also RAN2 changes China Unicom: RAN2 has agreed their pCR conclusion: email discussion (rapporteur: China Unicom) until Wed 23.11. noon CET to add last pCR from RAN2 and RAN3 agreed pCR(s) and to agree R3-163199 and to send the TR to RAN #74 for approval as v2.0.0	for email discussion	No		R3‑162925
		R3‑162909	TP editorial changes for joint operation	Huawei	pCR		Yes	YesEricsson: we are ok with this	agreed	No
		R3‑163073	CB: # 6_Report_JOP: Chairman's notes for the session on Study on HSPA and LTE Joint Operation SI	Vice Chairman	report	Approval	Yes	Yesconclusion: SI is considered completed with the agreement of the TR in R3-163199	endorsed	No
25	Quality of Experience (QoE) Measurement Collection for streaming services in UTRAN (RAN2-led) WI	R3‑163048	Reply LS on QoE reporting for streaming services (To: 3GPP SA4, CC: 3GPP RAN3, 3GPP SA5)	3GPP RAN2, Huawei	LS in		Yes	YesEricsson: Was this discussed in LTE session? RAN3 chair: this is UTRA only so expects that it was not discussed Huawei: RAN2 did not discuss this for LTE RAN3 chair: may come up for LTE as well conclusion: no LS answer to RAN2	noted	No
		R3‑162916	RAN3 impacts of QMC for streaming services	Huawei	discussion		Yes	Yes	noted	No
		R3‑162917	Introduction of QMC for streaming services	Huawei	CR	Agreement	Yes	YesNokia: several different options are discussed in RAN2, so we need to wait for agreements there Huawei: agrees with Nokia, WI is supposed to complete in March 2016 so we are bringing this up here already (in case RAN2 will conclude this week) RAN3 chair: so we can check the RAN2 status at the end of this week; MDT vs. new measurement has to be checked conclusion: will come back at the end of the week RAN3 chair: new measurement or container? Ericsson: would like to work on this until next meeting conclusion: CR is postponed	postponed	No
		R3‑162918	Introduction of QMC for streaming services	Huawei	CR	Agreement	Yes	Yesconclusion: will come back at the end of the week	postponed	No
		R3‑162919	Introduction of QMC for streaming services	Huawei	CR	Agreement	Yes	Yesconclusion: will come back at the end of the week	postponed	No
		R3‑162920	Introduction of QMC for streaming services	Huawei	CR	Agreement	Yes	Yesconclusion: will come back at the end of the week	postponed	No
		R3‑163236	LS on the progress of QoE Measurement Collection for Streaming (R2-168917; to RAN3, SA4, SA5, CT1; cc: -; contact: China Unicom)	RAN2	LS in	discussion	Yes	Yespresented by Huawei conclusion: no LS answer to RAN2	noted	No
26	NB-IoT enhancements (RAN1-led) WI	R3‑163042	Reply LS to NB-IOT NAS retransmission timers (To: 3GPP SA WG2, 3GPP RAN WG3, 3GPP RAN WG2 )	3GPP CT1, Huawei	LS in		Yes	YesRAN3 chair: no impact on RAN3 conclusion: no LS answer to CT1	noted	No
		R3‑163045	LS on collisions between SC-PTM and Paging in NB-IoT (To: 3GPP RAN2, 3GPP RAN3, 3GPP SA2 )	3GPP RAN1, Hisilicon	LS in		Yes	Yesconclusion: no LS answer to RAN1	noted	No
		R3‑163047	LS on coverage enhancement in SC-PTM for FeMTC and eNB-IoT (To: 3GPP RAN1, CC: 3GPP RAN3)	3GPP RAN2, Ericsson	LS in		Yes	Yesconclusion: no LS answer to RAN2	noted	No
		R3‑163049	Reply LS on overload control for CP CIoT EPS optimization (To: 3GPP SA2, 3GPP RAN3, CC: 3GPP CT1)	3GPP RAN2, NEC	LS in		Yes	YesNEC: discussion is ongoing in SA2 conclusion: no LS answer to RAN2	noted	No
		R3‑163053	Security aspects of RRC Connection Re-Establishment for NB-IoT (DoNAS) (To: 3GPP SA3, CC: 3GPP RAN3, 3GPP CT1)	3GPP RAN2, Vodafone	LS in		Yes	Yespresented by Ericsson conclusion: no LS answer to RAN2	noted	No
		R3‑163058	LS on mobility enhancements for eNB-IoT (To: 3GPP RAN3, 3GPP CT1, 3GPP SA2 )	3GPP RAN2, Huawei	LS in		Yes	YesHuawei: RAN2 is asking for some feedback RAN3 chair: is there an input on this? conclusion: Huawei will draft an LS reply in R3-163094	replied to	No
		R3‑163094	Draft reply to R2-163094 = R3-163094 on mobility enhancements for eNB-IoT (to: RAN2; cc: CT1, SA2; contact: Huawei)	Huawei	LS out	Approval	Yes	YesEricsson: 2nd part can be shortened MCC: which RAN2 LS are we answering is missing Nokia: there was a separate come back on 2nd question, how do we address it? They indicated a solution where we need to confirm.	revised	No	R3‑163158
		R3‑163158	Draft reply to R2-163094 = R3-163094 on mobility enhancements for eNB-IoT (to: RAN2; cc: CT1, SA2; contact: Huawei)	Huawei	LS out	Approval	Yes	Yes	revised	No	R3‑163165	R3‑163094
		R3‑163165	Reply to R2-163094 = R3-163094 on mobility enhancements for eNB-IoT (to: RAN2; cc: CT1, SA2; contact: Huawei)	RAN3	LS out	Approval	Yes	YesLS was sent out on Wed of RAN3 #94	approved	No		R3‑163158
		R3‑163061	LS on Handling of UE E-UTRAN capabilities when UE is camping on NB-IoT (To: 3GPP RAN2, 3GPP RAN3 )	3GPP SA2, Qualcomm	LS in		Yes	YesEricsson: checking the SA2 agreements/TR, we think this case cannot occur Qualcomm: also thought at the begining that most of it is covered but has some open issues RAN3 chair: we need to respond to question 2 conclusion: Qualcomm will draft a reply LS in R3-163095	replied to	No
		R3‑163095	Reply LS to S2-166285 = R3-163061 on Handling of UE E-UTRAN capabilities when UE is camping on NB-IoT (to: SA2, RAN2; cc: -; contact: Quaclomm)	Qualcomm	LS out	Approval	Yes	YesEricsson: not sure whether eNB cannot understand proper RRC container is strange conclusion: container aspect needs to be clarified	revised	No	R3‑163145
		R3‑163145	Reply LS to S2-166285 = R3-163061 on Handling of UE E-UTRAN capabilities when UE is camping on NB-IoT (to: SA2, RAN2; cc: -; contact: Quaclomm)	Qualcomm	LS out	Approval	Yes	Yes	revised	No	R3‑163157	R3‑163095
		R3‑163157	Reply LS to S2-166285 = R3-163061 on Handling of UE E-UTRAN capabilities when UE is camping on NB-IoT (to: SA2, RAN2; cc: -; contact: Quaclomm)	RAN3	LS out	Approval	Yes	YesLS was sent out on Wed of RAN3 #94	approved	No		R3‑163145
		R3‑163081	Reply LS to R2-167296 on Security aspects of RRC Connection Re-Establishment for NB-IoT (DoNAS) (S3-162088; to: RAN2; cc: RAN3,CT1; contact: Intel)	SA3, Intel	LS in	discussion	Yes	YesIntel: so far no RAN3 impact Ericsson: what will be the RAN2/RAN3 impact? Intel: SA3 will discuss and if S1 impact then RAN3 will be affected Ericsson: can RAN2/RAN3 work without having the SA3 security solution? Intel: thinks we could process in parallel Ericsson: context fetch possible but not integrity conclusion: no LS answer to SA3	noted	No
		R3‑163131	Reply LS to R2-167315 on mobility enhancements for eNB-IoT (C1-165313; to: RAN2, RAN3; cc: SA2; contact: Huawei)	CT1	LS in	discussion	Yes	Yeswhcih cause value shall be used for establishment? conclusion: Huawei will draft a reply LS	replied to	No
		R3‑163144	Reply LS to C1-165313 = R3-163131 on mobility enhancements for eNB-IoT (to: CT1; cc: RAN2, SA2; contact: Huawei)	Huawei	LS out	Approval	Yes	YesNokia: intention of new cause value? RAN3 chair: do we have an agreement about HO trigger? or should we postpone the LS NEC: "no mandate the usage" needs to be removed	revised	No	R3‑163230
		R3‑163230	Reply LS to C1-165313 = R3-163131 on mobility enhancements for eNB-IoT (to: CT1; cc: RAN2, SA2; contact: Huawei)	Huawei	LS out	Approval	No	YesHuawei: may come back on this next time	withdrawn	Yes		R3‑163144
		R3‑163254	LS on mobility enhancements for NB-IoT (R2-169115; to: RAN3, CT1; cc: SA2, SA3; contact: Huawei)	RAN2	LS in	discussion	Yes	YesEricsson: unclear what this LS actually means Huawei: we can continue mobility discussion and depending on SA3 Ericsson: suggests to ignore the LS as this is RAN3 business conclusion: no LS answer to RAN2	noted	No
26.1	Mobility	R3‑162761	Offline discussion summary of Mobility in NB-IoT enhancements	Huawei (Rapporteur)	discussion	Decision	Yes	YesProposal 1: use RLF indication + HO to support data forwarding for UP solution. Proposal 2: use RLF indication + HO + S1 NAS recovery (NAS Non Delivery indication from old eNB to MME+ DL NAS Transport from MME to new eNB) to support NAS PDU transmission for CP solution. Proposal 3: RAN3 to solve the mandatory IEs issue in S1/X2 HO and Path Switch procedures for CP solution.	noted	No
		R3‑163075	Response to R3-162761 - R3-162764	Ericsson	response	Approval	Yes	YesEricsson: response was written before we got SA3 LS, most of it can be just noted now; we should not abuse existing S1/X2 procedures for something that they were not written for RAN3 chair: objection to have a new procedure? Nokia: if we support this optimisation then we should minimize spec impact Ericsson: limiting spec impact is one thing but we should also look at implementation impacts RAN3 chair: so it seems we are between solution 1 and solution 5 but we anyway depend on what SA3 will decide Intel: we could send an LS	noted	No
		R3‑162762	Further consideration on mobility in NB-IoT enhancements	Huawei, China Unicom	discussion	Decision	Yes	YesRAN3 chair: there are a lot of flags to not introduce this and that; so is a new procedure really more impact? Nokia: only a few AIs which are relevant so this Tdoc could have been presented in a simpler way; Ericsson: we should wait for the SA3 solution before we take a decision in RAN3 RAN3 chair: but in how far is there RAN3 impact? Ericsson: most of the functions from handover is useless for this case so why should we go for it?	noted	No
		R3‑162763	Mobility support in NB-IoT enhancement in X2AP	Huawei	CR	Agreement	Yes	Yes	not treated	No
		R3‑162764	Mobility support in NB-IoT enhancement in S1AP	Huawei	CR	Agreement	Yes	Yes	not treated	No
		R3‑163218	Support of RLF with UE Context Retrieval for CP CIoT Optimisation	Ericsson	draftCR	discussion	Yes	YesRAN3 chair: is it a self-consistent solution or do we need to merge CRs? Ericsson: we have to select one CR set	postponed	No
		R3‑163219	Support of RLF with UE Context Retrieval for CP CIoT Optimisation	Ericsson	draftCR	discussion	Yes	Yes	postponed	No
		R3‑163220	Support of RLF with UE Context Retrieval for CP CIoT Optimisation	Ericsson	draftCR	discussion	Yes	Yes	postponed	No
		R3‑162853	The left issues on NB IOT mobility enhancement	ZTE Corporation	discussion		Yes	YesProposal 1: To support data forwarding, the existing “SN Status Transfer” message from old eNB to new eNB is needed. Proposal 2: To support autonomous connection suspension at UE side and eNB side respectively in the case of re-establishment failure. Proposal 3: Select Option1 to solve issue on handling mandatory IEs on UE context fetch from old eNB. Proposal 4: Select Option1 or Option2 solution to resume the UE context in the EPC and update the UE-associated logical S1-connection. CATT: proposal 2 is an enhancement? ZTE: yes, is an optimisation enhancement agreements of AI 26.1: for UP: use RLF indication + HO to support data forwarding for UP solution i.e. implementation solution for CP: no decision so far but 2 solutions: RLF indication + HO +S1 NAS recovery (NAS Non Delivery) indication from old eNB + DL NAS Transport to new eNB (CP-1) or X2 RLF indication + X2AP new message(s) (CP-2 new?) depending on SA3 solution conclusion: offline discussion to discuss the 2 CP solutions	noted	No
		R3‑163067	Feasibility of lossless mobility for the CP solution	MediaTek Inc.	discussion		Yes	Yeslate input; Proposal: Send a Reply LS to RAN2 and confirm that the lossless mobility solution by (re)transmissions in NAS, triggered by AS (as proposed by RAN2) is a feasible solution from eNB point of view. Nokia: was already discussed under the CP solutions Ericsson: lossless can be confirmed Qualcomm: we were more discussing DL here in RAN3 but Mediatek has a wider scope RAN3 chair: since we are depending on SA3 decisions (e.g. authentication of the UE) we will not send an LS from this meeting; there is still a need to clarify the 2 CP solutions Ericsson: if Mediatek needs a general comment on feasibility we could do this but we cannot reply on the actual solution Mediatek: would like to minute that from RAN3 point of view lossless mobility solution seems feasible for CP conclusion: from RAN3 point of view lossless mobility solution seems feasible for CP but solution itself needs to be decided (CP-1 or new procedure, both depend on SA3 decisions) Qualcomm: clarifies that we have no solution so far	noted	No
26.2	Positioning	R3‑162770	Positioning in NB-IoT enhancement	Huawei, China Unicom	discussion	Decision	Yes	YesEricsson: we still expect a RAN1 LS in order to progress	noted	No
26.3	Others	R3‑162737	Support of SC-PTM for NB-IoT	CATT	discussion	Decision	Yes	YesRAN3 chair: same comments apply as for eMTC (R3-162856)	noted	No
		R3‑162765	Coverage enhancement in NB-IoT enhancements	Huawei	discussion	Decision	Yes	Yes	noted	No
		R3‑162766	Introduction of Coverage Level Information in M2 interface	Huawei	CR	Agreement	Yes	Yes	rejected	No		R3‑162116
		R3‑162767	Introduction of Coverage Level Information in M3 interface	Huawei	CR	Agreement	Yes	YesMediatek: was deiscussed in RAN2 several times, in RAN2 it was concluded that we would not have this information in REL-14; BS may anyway already know distribution of UEs in the cell Ericsson: agrees with Mediatek and we have an LS from RAN2 that this will be autonomously handled by the eNB; so no signalling support needed RAN3 chair: Huawei can check offline whether we need to come back on this during this week	rejected	No		R3‑162117
		R3‑162768	NPRACH Configuration exchanging for NB-IoT enhancements	Huawei	discussion	Decision	Yes	YesProposal 1: Introduce PRACH configuration of the anchor carrier and non-anchor carriers in the Served Cell Information IE in X2AP specification. Proposal 2: endorse the CR in R3-162769 as baseline CR, the presents of some IEs are marked as FFSs pending to RAN2 discussion.	noted	No
		R3‑162769	Introduction of NPRACH configuration in X2AP	Huawei	CR	Agreement	Yes	YesZTE: why is this change needed? Huawei: avoiding collisions between neighbour cells Ericsson: agrees that we should not say "we have this in LTE so we will need it for NB-IOT" Mediatek: is this for interference management? Hauwei: yes, may be needed for interference management Ericsson: but if this does not change so often then O&M may be enough conclusion: needs further discussion, can come back next meeting	postponed	No		R3‑162119
		R3‑163096	Way forward on NB-IOT enhancements	Huawei	discussion	discussion	Yes	Yes3 CP solutions possible RAN3 chair: we use this sort of way forward as a status report and not introduce new proposals	noted	No
27	Network Assistance for Network Synchronisation SI	R3‑163060	LS response on Network Assistance for Network Synchronization in LTE (To: 3GPP TSG RAN, 3GPP RAN3, CC: 3GPP RAN1)	3GPP RAN4, Huawei	LS in		Yes	Yesconclusion: no LS answer to RAN4	noted	No
		R3‑162921	TR 36.898 v2.1.0 on Network Assistance for Network Synchronization	Huawei	draft TR	Agreement	Yes	YesMCC: wrong version 2.0.0 in Tdoc request conclusion: was agreed as status before RAN3 #94 and then revised to include further agreements of RAN3 #94	revised	No	R3‑163202
		R3‑163202	TR 36.898 v2.2.0 on Network Assistance for Network Synchronization	Huawei	draft TR	Agreement	No	Yesconclusion: email discussion until Wed 23.11 noon CET to include agreements of RAN3 #94 RAN3 chair: with this the SI can be completed at RAN #74 from RAN3 point of view	for email discussion	No		R3‑162921
		R3‑162922	Conclusion of the SI for Network Synchronization	Huawei	pCR		Yes	Yesconclusion: revised to indicate that solution 1 can not fulfill some evaluation criteria, reuse wording from LS on accuracy aspects	revised	No	R3‑163201
		R3‑163201	Conclusion of the SI for Network Synchronization	Huawei	pCR	-	Yes	YesNokia: fine with the contents, just Tdoc on cover is wrong Ericsson: agrees with the proposal	agreed	No		R3‑162922
		R3‑163077	Response to R3-162922 and R3-162923	Ericsson	response	Approval	Yes	YesProposal: It is proposed to specify in the conclusions of the SI on Network Based Synchronisation that Solution 1 does not fulfil the evaluation criteria established by the study and that RAN4 specify that the solution does not allow certain features to work. Huawei: we do not agree with this response Deutsche Telekom: we would still see to move this forward RAN3 chair: solution 1 is not full synchronisation solution but in some deployment conditions it works Ericsson: we are evaluating solution 1 based on the criterias we set up Nokia: solution 1 is a low cost solution but we support Deutsche Telekom Deutsche Telekom: has no problem to indicate that solution 1 has some constraints Huawei: we need to clarify which constraints but can work offline on some text	noted	No
		R3‑162923	Motivation for the new WI of Network Synchronization	Huawei	discussion		Yes	YesRAN3 chair: just for information here, will be handled in RAN if SI is completed	noted	No
		R3‑162924	New WID on Network Assistance for Network Synchronization	Huawei	WID new	Information	Yes	YesMCC: wrong Tdoc type discussion in Tdoc request RAN3 chair: just for information here, will be handled in RAN if SI is completed	noted	No
28	Study on Context Aware Service Delivery in RAN SI	R3‑163054	LS on RAN2 agreements on Context Aware Service Delivery SI (To: 3GPP RAN3 )	3GPP RAN2, Qualcomm	LS in		Yes	Yesconcluison: no LS answer to RAN2	noted	No
28.1	TR 36.933	R3‑162885	Editorial update v1.1.1 of Draft TR 36.933 on Study on Context Aware Service Delivery in RAN for LTE	CMCC	draft TR	Agreement	Yes	YesMCC: wrong version 1.1.0 in Tdoc request; moved from AI 28 to AI 28.1 conclusion: agreed as status before RAN3 #94, later revised to include agreements of RAN3 #94	revised	No	R3‑163210
		R3‑163210	Editorial update v1.2.0 of Draft TR 36.933 on Study on Context Aware Service Delivery in RAN for LTE	CMCC	draft TR	Agreement	No	Yesconclusion: email discussion until Wed 23.11. noon CET to include all agreements; TR will not be sent to RAN #74	for email discussion	No		R3‑162885
28.2	Issue and use case
28.3	Solution description	R3‑162669	Evaluation on the solutions for DASH optimization (Issue 3 – case 2)	Nokia, Alcatel-Lucent Shanghai Bell	discussion		Yes	Yes	noted	No
		R3‑162670	Text Proposal for Evaluation on the solutions for DASH optimization (Issue 3 – case 2)	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	YesQualcomm: we can capture solutions for evaluation part and discuss evaluation then next meeting	postponed	No
		R3‑162869	TP for the evaluation on the DASH optimization solution	Huawei, Qualcomm Incorporated, CMCC	pCR	Approval	Yes	Yes	revised	No	R3‑163193
		R3‑163193	TP for the evaluation on the DASH optimization solution	Huawei, Qualcomm Incorporated, CMCC	pCR	Approval	Yes	YesEricsson: UE provides extra info in step 1 to RAN? unclear how we compare solutions	revised	No	R3‑163204	R3‑162869
		R3‑163204	TP for the evaluation on the DASH optimization solution	Huawei, Qualcomm Incorporated, CMCC	pCR	Approval	Yes	Yes	agreed	No		R3‑163193
		R3‑163019	Solution proposal for DASH Optimisation	Ericsson	discussion		Yes	Yes	noted	No
		R3‑163020	Solution proposal for DASH Optimisation	Ericsson	pCR		Yes	Yes	revised	No	R3‑163205
		R3‑163205	Solution proposal for DASH Optimisation	Ericsson	pCR	-	Yes	YesQualcomm: the solution has several problems RAN3 chair: you can bring inputs next meeting to explain that it does not work or add ffs Ericsson: we can do the evaluation in the next meeting RAN3 chair: are we talking about drawbacks or does the solution not work at all Qualcomm: is just a component of SA4 work Ericsson: we also captured Huawei contribution RAN3 chair: we can add an editor's note that this is the RAN part of an SA4 solution Qualcomm: but we should only capture a solution that works but this is just part of it Qualcomm, Huawei: if we add this solution we need to be open to add also other solutions in the future conclusion: revised and add ffs where needed	revised	No	R3‑163241	R3‑163020
		R3‑163241	Solution proposal for DASH Optimisation	Ericsson	pCR	-	Yes	Yes	agreed	No		R3‑163205
		R3‑162790	Critical data discard on UL Video transmission	Intel Corporation	discussion	Decision	Yes	Yes	noted	No
		R3‑163037	TP to address solutions for issue 4	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesRAN3 chair: wrong Tdoc number on CR cover	revised	No	R3‑163209
		R3‑163209	TP to address solutions for issue 4	Intel Corporation (UK) Ltd	pCR	Approval	Yes	YesRAN3 chair: will report to RAN #74 that this SI is not completed	agreed	No		R3‑163037
		R3‑162867	Discussion on the solution of video optimization	Huawei	discussion	Decision	Yes	Yes	not treated	No
		R3‑162868	TP for the solution of video optimization	Huawei, CMCC	pCR	Approval	Yes	Yes	not treated	No
		R3‑162872	TP for Video object deadline-aware scheduling	QUALCOMM Incorporated, Huawei, CMCC	pCR	Approval	Yes	YesEricsson: proposal breaks principles, also RAN has to implement a full video player	postponed	No
		R3‑162672	Discussion on solutions for TCP optimization	Nokia, Alcatel-Lucent Shanghai Bell	discussion		Yes	Yes	not treated	No
		R3‑162673	Text Proposal for solutions to address issue 2	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	Yes	not treated	No
		R3‑162870	Discussion on the solution of TCP optimization	Huawei, Qualcomm Incorporated	discussion	Decision	Yes	Yes	not treated	No
		R3‑162871	TP for the solutions of TCP optimization	Huawei, Qualcomm Incorporated, CMCC,	pCR	Approval	Yes	Yes	not treated	No
		R3‑162873	Radio-aware TCP optimization	QUALCOMM Incorporated, Huawei	discussion	Decision	Yes	Yes	not treated	No
		R3‑162874	TP for radio-aware TCP optimization	QUALCOMM Incorporated, Huawei, CMCC	pCR	Approval	Yes	Yes	not treated	No
		R3‑162666	Discussion on solutions to address backhaul long latency issue	Nokia, Alcatel-Lucent Shanghai Bell, CMCC, Qualcomm Incorporated, NEC, ZTE	discussion		Yes	Yes	not treated	No
		R3‑162668	Text Proposal for solutions to address backhaul long latency issue	Nokia, Alcatel-Lucent Shanghai Bell, CMCC, Qualcomm Incorporated, NEC, ZTE	pCR		Yes	Yes	not treated	No
		R3‑162886	Solution to backhaul long latency issue	CMCC, Qualcomm Incorporated	discussion	Decision	Yes	Yes	not treated	No
		R3‑162887	TP for service information acquisition and UE assisted local cache	CMCC, Qualcomm Incorporated	pCR	Approval	Yes	Yes	revised	No	R3‑163198
		R3‑163198	TP for service information acquisition and UE assisted local cache	CMCC, Qualcomm Incorporated	pCR	Approval	Yes	Yes	agreed	No		R3‑162887
28.4	Others
29	Further enhanced MTC (RAN1-led) WI	R3‑162855	Support of SC-PTM for eMTC	CATT	discussion	Decision	No	No	withdrawn	Yes
		R3‑162856	Support of SC-PTM for eMTC	CATT	discussion	Decision	Yes	YesProposal 1: To support MCE to select SC-PTM for eMTC, MCE need to know eMTC activation status for each cell in the MBMS Cell List provided by MME, this could be done via OAM configuration. Nokia: How does MC know this is related to MTC? Ericsson: assumes from the WID that the services are preconfigured RAN3 chair: you broadcast something that cannot be used so waste of resources but not more harm; Nokia: configuration is in the core network so the situation is a bit different than the case we discussed Ericsson: you would have a magic TMGI (for eMTC) RAN3 chair: we are not debugging the core network Ericsson: agrees with RAN3 chair that there is no impact on core network RAN3: we rely on O&M that it tells the core network the right cells conclusion: proposal was not agreed	noted	No
30	Study on SON for eCoMP for LTE SI	R3‑162655	TR 36.742 v0.2.1 on Study on SON for eCoMP	Nokia, Alcatel-Lucent Shanghai Bell	draft TR	Agreement	Yes	Yes	agreed	No
		R3‑163027	Change in X2 TNL performances use-case and solution	Fujitsu	pCR	Decision	Yes	Yes	revised	No	R3‑163211
		R3‑163211	Change in X2 TNL performances use-case and solution	Fujitsu	pCR	Decision	Yes	Yes	revised	No	R3‑163242	R3‑163027
		R3‑163242	Change in X2 TNL performances use-case and solution	Fujitsu	pCR	Decision	Yes	Yes	agreed	No		R3‑163211
		R3‑162656	Solution for CA allocation taking into account X2 link characteristics	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	Yes	revised	No	R3‑163189
		R3‑163189	Solution for cooperation area allocation taking into account X2 link characteristics	Nokia, Alcatel-Lucent Shanghai Bell, Fujitsu	pCR	-	Yes	Yes	revised	No	R3‑163212	R3‑162656
		R3‑163212	Solution for cooperation area allocation taking into account X2 link characteristics	Nokia, Alcatel-Lucent Shanghai Bell, Fujitsu	pCR	-	Yes	Yes	agreed	No		R3‑163189
		R3‑162657	Use-case and solutions for CA allocation taking into account the spatial user distribution	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	Yes	not treated	No
		R3‑162658	Why do we need to optimize coordination areas?	Nokia, Alcatel-Lucent Shanghai Bell	pCR		Yes	Yes	not treated	No
		R3‑163257	TR 36.742 v0.3.0	Nokia	draft TR	discussion	No	Yesconclusion: email discussion until 23.11 noon CET; will not be sent to RAN #74, may be sent for 1-step approval to RAN #75	for email discussion	No
31	Corrections to Rel-14 and TEI14
31.1	3G
31.2	LTE.	R3‑162888	Paging reception in eDRX not allowed	NEC	discussion	Decision	Yes	YesMCC: LTE_extDRX-Core was a REL-13 WI	noted	No
		R3‑162889	Paging reception in eDRX not allowed	NEC	CR	Agreement	Yes	YesMCC: LTE_extDRX-Core was a REL-13 WI; wrong WI code on CR cover; wrong CR cat. or where is the REL-13 CR? Mediatek: MME would send this page too far ahead in time? or what is the problem? NEC: problem is that MME does not know that eNB does not allow eDRX Qualcomm: when we designed the feature the assumption was that support for eDRX would be rather homogeneous among tracking areas, if this is not the case then we need to maybe redesign the feature Ericsson: agrees with Qualcomm conclusion: offline to check whether clarification is needed at stage 2 Ericsson: 23.682 is the spec where it is already clarified	rejected	No
		R3‑162789	Enhnaced MME overload procedure	Intel Corporation, U.S. Cellular	discussion	Decision	Yes	Yes	noted	No
		R3‑162877	Enhancement for MME Overload Control	Huawei, U.S. Cellular	discussion	Decision	Yes	Yes	noted	No
		R3‑163235	Way forward on Enhancement for MME Overload Control	Huawei	discussion	discussion	Yes	YesProposed WF: Using NAS based solution to reject specific UE(s) accessing the network. conclusion: Using NAS based solution to reject specific UE(s) accessing the network is preferred	noted	No
		R3‑162878	Enhancement for MME Overload Control	Huawei, U.S. Cellular	draftCR	Approval	Yes	Yes	postponed	No
		R3‑162879	Enhancement for MME Overload Control	Huawei, U.S. Cellular	CR	Agreement	Yes	YesNEC: why 22048? is an unscalable solution Intel: we can monitor UE moves from idle to connected RAN3 chair: some type of UEs can be rejected based on some criteria with this Nokia: MME is not part of the UP so how can MME decide this (if never sent any data) Huawei: we took TCP as an example; we talk about overload on MME side Nokia: check with SA2; NAS timer solution was more sufficient conclusion: check use case (with US Cellular)	postponed	No		R3‑162312
		R3‑163024	eNB Overload handling for CP CIoT Optimisation	Ericsson	discussion		Yes	YesMCC: NB_IOT-Core was a REL-13 WI	noted	No
		R3‑163229	Way forward: eNB overload handling for CP CIoT Optimisation	Ericsson	discussion	discussion	Yes	Yes	noted	No
		R3‑162965	Introduction of an E-UTRAN triggered S1 Overload procedure	Ericsson	draftCR	Endorsement	Yes	NoMCC: NB_IOT-Core was a REL-13 WI conclusion: further offline discussion on scenario and also alternatives, will come back on Friday	available	No		R3‑162453
		R3‑162966	Introduction of an E-UTRAN triggered S1 Overload procedure	Ericsson	CR	Agreement	Yes	NoMCC: NB_IOT-Core was a REL-13 WI Huawei: there is no NAS and NAS+data Ericsson: we need a solution if control plane is abused for data transmission; Huawei: MME is in a better position to decide this Ericsson: but eNB is in a better position to evaluate this Nokia: is this a problem for NB-IOT or others? Ericsson: for all cases where CP can be used for data CATT: problem is maybe be bigger for MME than for eNB Ericsson: smart phones may misuse CP resources and then eNB should have a means to inform MME of this problem RAN3 chair: Huawei seems not be in favour of it and Samsung, Nokia, CATT require further discussion conclusion: further offline discussion on scenario and also alternatives, will come back on Friday	available	No		R3‑162411
		R3‑162899	Use of DCN-ID for better NNSF	NEC	discussion	Decision	Yes	Yes	noted	No
		R3‑162900	Adding DCN-ID to S1 Setup Response	NEC	CR	Agreement	Yes	NoNEC: to align with SA2 agreements	available	No
		R3‑163021	Introduction of eDECOR in RAN	Ericsson	discussion		Yes	Yes	noted	No
		R3‑163022	Introduction of eDECOR in RAN	Ericsson	CR	Agreement	Yes	YesMCC: eDecor is an SA2 REL-14 WI without corresponding RAN WI	revised	No	R3‑163097
		R3‑163097	Introduction of eDECOR in RAN	Ericsson	CR	Agreement	Yes	YesEricsson: could only be agreed with ffs Ericsson: encoding DCN-id is depending on CT4 Nokia: no CT1 RAN3 chair: do we expect an LS from CT1/CT4?	postponed	No		R3‑163022
		R3‑162963	Introduction of eDECOR in RAN	Ericsson	CR	Agreement	Yes	YesMCC: eDecor is an SA2 REL-14 WI without corresponding RAN WI;	revised	No	R3‑163098	R3‑162450
		R3‑163098	Introduction of eDECOR in RAN	Ericsson	CR	Agreement	Yes	Yes	postponed	No		R3‑162963
		R3‑163023	Introduction of eDECOR in RAN	Ericsson	draftCR		Yes	YesMCC: eDecor is an SA2 REL-14 WI without corresponding RAN WI	revised	No	R3‑163099
		R3‑163099	Introduction of eDECOR in RAN	Ericsson	draftCR	-	Yes	Yes	postponed	No		R3‑163023
		R3‑162964	Introduction of eDECOR in RAN	Ericsson	CR	Agreement	Yes	YesMCC: eDecor is an SA2 REL-14 WI without corresponding RAN WI; Nokia: TCN-ID is controversial in SA2, so too early to decide here NEC: Ericsson CRs not related to load balancing RAN3 chair: check with co-located WGs (SA2, CT), we will revise the Ericsson CRs and we may send CRs to RAN #74, if SA2 can not decide then this is a different issue but try to progress on this this week NEC: our CR is in line with SA2 so no further agreements needed conclusion: offline discussion until Fri	revised	No	R3‑163100	R3‑162451
		R3‑163100	Introduction of eDECOR in RAN	Ericsson	CR	Agreement	Yes	Yes	postponed	No		R3‑162964
32	Rel-13/Rel-14 Specification Review
32.1	Editorial
32.2	ASN.1
33	Any other business
34	Closing of the meeting (Friday 17:00)