3GPP TSG RAN1 RAN2 / RAN2 contributions RAN2 2 1 LTE/LTE-Advanced MTC Relay Relay Rel-10 L2 measurement MTC Extended Access Barring (EAB) RAN ov

Size: px

Start display at page:

Download "3GPP TSG RAN1 RAN2 / RAN2 contributions RAN2 2 1 LTE/LTE-Advanced MTC Relay Relay Rel-10 L2 measurement MTC Extended Access Barring (EAB) RAN ov"

浓饭芒
7 years ago
Views:

1 3GPP TSG RAN WG2 #75 Mamadou Kone /

2 3GPP TSG RAN1 RAN2 / RAN2 contributions RAN2 2 1 LTE/LTE-Advanced MTC Relay Relay Rel-10 L2 measurement MTC Extended Access Barring (EAB) RAN overload RAN2 Chairman / Vice-chairmen Ericsson Chairman Huawei UMTS session LG LTE session 3GPP LTE-Advanced 3GPP ITU-R IMT-Advanced LTE-Advanced ITU-R Stage 3 3GPP RAN LTE-Advanced Release 10 2

3 LTE-Advanced Release 11 3GPP LTE-Advanced 3GPP LTE LTE Stage 3 PHY Layer MAC RLC PDCP RRC release 10 release 11 release 10 3

5 3GPP TSG RAN2 #75 Meeting LTE-A Carrier aggregation CA enhancement Relay eicic LPP MTC eicic MDT 22 Aug - 26 Aug 2011 Hotel Athenaeum InterContinental (Athens, Greece) RAN2 (22 Aug - 26 Aug 2011): Indicative Main room Time-schedule Mon 09:00 -> [2],[3],[4] Tue 08:30 -> Rel-89 [5] Rel-10 [6] UMTS room [8 non-tdd] [8, 9.7 TDD only] Wed 8:30 -> CAenh[7.1] DivData[7.2] [9.2] [9.4] [9.5] [9.7 non-tdd] [9.8] [10.1] Thu 8:30 -> MBMS [7.3] eicic [7.5] Indev [7.7] NBP[7.4] [10.2] [10.3] [10.6] After Lunch: 5

6 Fri 8:30 -> Fri: lunch -> until 5pm Hetnet mob[7.8] Hetnet mob[7.8] Left-overs, Comebacks, [12][13][14] Comebacks [10.4] [10.5] [10.7] Comebacks [14] if time allows 6

7 1. Opening of the meeting 2. General 3. Incoming liaisons 4. UMTS/LTE joint session 4.1 LTE Release 9 and earlier releases 4.2 Release Release LTE Release 9 and earlier releases 6. LTE Release WI: Carrier aggregation (RP ), UL-MIMO, edl-mimo Stage-2 / Stage-3 Common Stage-3 Control Plane Stage-3 User Plane 6.2 WI: Relays (RP ) 6.3 WI: MBMS enhancements (RP ) 6.4 WI: Minimisation of Drive Test (RP ) 6.5 WI: eicic (RP ) 6.6 WI: TEI WI: Other LTE Rel-10 WIs 6.8 Other LTE Rel-10 topics 7. LTE Release WI: CA enhancements (RP ) 7.2 WI: Enhancements for diverse data applications (RP ) 7.3 WI: Service continuity improvements/location info for MBMS (RP ) 7.4 WI: Network-Based positioning Support for LTE (RP ) 7.5 WI: Further Enhanced Non CA-based ICIC for LTE (RP ) 7.6 WI: Other Rel-11 WIs 7.7 SI: In-device coexistence interference avoidance (RP ) 7.8 SI: Hetnet mobility enhancements (RP ) 7.9 SI: RAN improvements for Machine Type Comm (SI: RP ) 7.10 SI: Other Rel-11 Sis 8. UTRA Release 9 and earlier releases 9. UTRA Release WI: LCR TDD MC-HSUPA (RP ) 9.2 WI: 4C-HSDPA (RP ) 9.3 WI: RF pattern matching in UMTS (RP ) 9.4 WI: Minimisation of Drive Test (RP ) 9.5 WI: ANR for UTRA (RP ) 7

8 9.6 WI: Interfrequency detected set measurements (RP ) 9.7 WI: TEI UTRA Release WI: Further enhancements to CELL_FACH (RP ) 10.2 WI: 8C-HSDPA (RP ) 10.3 WI: Other Rel-11 WIs 10.4 SI: HSDPA multi-point transmission (RP ) 10.5 SI: UL MIMO (RP ) 10.6 SI: RAN improvements for Machine Type Comm (SI: RP ) 10.7 SI: Other Rel-11 SIs 11. Outgoing LS and discussions for UTRA 12. Left-overs 13. Outgoing LS and output to other groups for LTE/joint 14. Any other business 15. Closing of the meeting 1. Machine Type Communication (MTC) MTC (Rel-10 WI RP ) (Rel-11 SI RP ) Agenda item: WI: RAN mechanisms to avoid CN overload due to MTC (RP ) enb RRCConnectionRelease extendedwaittime UE UE UMTS UE PS CS RRCConnectionRelease UE ASN.1 RAN2 8

9 RRCConnectionRelease domain indicator RAN2 1. RRCConnectionRelease RRCConnectionRequest domain indicator ( R NSN) 2. ( R Huawei) 3. PS CS enb SignallingConnectionRelease extendedwaittime cn-domainidentity UE ( R CATT) 2 3 enb 1 Agreements: 1) If the timer is included in the connection release, it will apply to the domain indicated in the connection request. 2) No need to forward information on domain from connection request in SRNS relocation, since assumption is that this connection release will typically be used quickly after connection request (in case of after SRNS relocation, network will have to use SCR to address a specific domain). R : CN Domain for ewaittime Nokia Siemens Networks, Nokia Corporation CR UMTS UE RRC CONNRECTION REQUEST delay tolerant access ewaittime RRC CONNECTION RELEASE UE ewaittime NAS layer CS 9

10 PS EPC QC connection release request indication error free NSN RAN2 agreement CR R : Clarification of supporting delay tolerant access CATT CR LTE RRC extendedwaittime delay tolerant access "support delay tolerant access" Agenda item: SI: RAN improvements for Machine Type communication (RP ) RAN#52 RAN improvements for Machine Type communication SI 2011 "RAN overload handling" joint UMTS/LTE scenario related contributions, generic solutions,... agenda item LTE specific solutions agenda item 7.9 UMTS specific solutions agenda item 10.6 agenda item joint UMTS/LTE RAN improvement R : Text proposal for TR to conclude the study on RAN overload control 10

11 Huawei, HiSilicon TP QualComm review "without the need to introduce any new access classes" ZTE SA1 AC QualComm QualComm EAB MTC devices AC DT AC FFS whether we can avoid duplicating all EAB information to limit the overhead on broadcast TR v1.0.0 RAN group Extended Access Barring (EAB) EAB RAN overload MTC UE ( )EAB EAB AS NAS EAB PLMN RAN EAB RAN2 #73b (Extended Access Barring EAB) BCCH EAB RAN2 EAB 11

12 1. UE EAB ( AC11-15) EAB UE EAB ( AC0-9) EAB 2. UE EAB EAB UE EAB 3. EAB (Access Class Barring ACB) 4. AS NAS EAB 5. EAB 6. EAB EAB 7. EAB 1 2 SA1 CT1 RAN2 LS ( R ) SA1 CT1 3 6 RAN2 Rel-10 RAN2 EAB PLMN-specific Agreements: 0: RAN2 assumes that somehow per RRC connection establishment, AS will know whether to apply EAB or not - this is a requirement if EAB is applied in AS, otherwise it is not needed. 12

13 3: If access is not barred by EAB then UE shall be subject to the legacy ACB. 4: In the case of multiple core networks sharing the same access network, EAB information can be PLMN specific. FFS whether we can avoid duplicating all EAB information to limit the overhead on broadcast. 4 : R : Disc R : EAB Handling in AS or NAS Nokia Siemens Networks, Nokia Corporation EAB model in UE LG Electronics Inc. Disc AS NAS EAB AS EAB NAS EAB UE PLMN EAB AS NAS EAB AS SIB EAB NAS ZTE LG NAS EAB Nokia CATT Vodafone Huawei STE AS GERAN AS EAB RATs RAN2 AS EAB Agreements: 1) EAB will be executed at AS layer UMTS LTE EAB UMTS ACB 1 bit 2. UMTS LTE EAB LTE ACB (establishmentcause) barring factor barring 13

14 time 3. UMTS LTE EAB ACB 1 NSN NTT DCM LG DT Vodafone RATs GERAN EAB 1 bit UMTS LTE EAB GERAN 1 3 Huawei ZTE Intel CATT Samsung LTE 1 bit UMTS UMTS LTE Qualcomm Ericsson RAN2 Agreements: 1) UMTS: EAB will be 1 bit per AC 2) LTE: EAB will either be 1 bit per AC solution, or a solution conform LTE ACB i.e. probability factor and barring time. Note: In general further solutions/mechanisms can always be discussed/proposed based on consensus. 7 EAB 4 (1) LTE (2) UE EAB (3) LTE ETWS (4) RAR Indication EAB 7 14

15 (Rel-11 SI RP ) TR ( R ) EAB TR Extended Access Barring EAB enforcement will be implemented in the UE AS layer and interwork with legacy Access Class Barring, it should ensure that the corresponding requirement specified in [11] section could be satisfied. To ensure that the network can react fast enough to prevent overload in critical scenarios, different alternatives for EAB information update and acquisition could be considered. EAB Is one UE always yes/no configured for EAB? R : Handling of UE with Special ACs configured with EAB Vodafone Disc EAB UE access class R : Further discussion on EAB requirements Huawei, HiSilicon Disc UE config to EAB delay tolerant device MTC Access class 0~9 R : Further discussion on EAB for RAN overload handling Intel Corporation Disc 1) delay tolerant device low priority, 2)EAB AS, 3) EAB SSAC SSAC apply ACB 4) EAB info change 15

16 modification period Is EAB handled at AS or NAS? R : Disc EAB Handling in AS or NAS Nokia Siemens Networks, Nokia Corporation EAB AS NAS layer EAB AS R : EAB model in UE LG Electronics Inc. Disc EAB NAS UE SIB EAB info EAB info NAS Contents of EAB: R : Is EAB Mechanism Sufficient for RAN Overload Control? CATT Disc EAB access delay delay R : Consideration of EAB Institute for Information Industry (III), Coiler Corporation Disc EAB LTE ACB R : EAB content and other related issues Nokia Siemens Networks, Nokia Corporation Disc EAB UMTS ACB R : Integrated Slotted Access with EAB for MTC Alcatel-Lucent, Alcatel-Lucent Shanghai Bell Disc 16

17 slotted access EAB R : EAB for MTC traffic Alcatel-Lucent Disc EAB UMTS ACB R : Ltd. Disc Implementing Enhanced Access Barring in UMTS and LTE Renesas Mobile Europe EAB LTE ACB SSAC R : General consideration of EAB in LTE Huawei, HiSilicon Disc UE EAB R : General consideration of EAB in UMTS Huawei, HiSilicon Disc EAB AS access class EAB PLMN sharing: R : Applicability of EAB in a Shared Network Environment Vodafone Disc PLMN sharing EAB information PLMN specific R : Impact to EAB Considering Network Sharing CATT Disc PLMN sharing EAB information PLMN specific Speed of change: R : EAB content and other related issues Nokia Siemens Networks, Nokia Corporation Disc EAB R : Discussion on mechanisms for EAB information update and acquisition ITRI 17

18 Disc EAB SIB R : Considerations for EAB ZTE Disc EAB R : Detailed description for EAB solutions Samsung Disc EAB SIB paging message EAB R : Further discussion onâ EAB enhancement ITRIDisc UE EAB backoff access network Other mechanisms: R : Discussion on RAN overload solution LG Electronics Inc. Disc RAR extended backoff R : Overview for RACH enhancement Samsung Disc pre-backoff RAN overload R : Way forward for pull based approach LG Electronics Inc. Disc pull based approach RAN overloadd R : Is EAB enough to control RACH overload? LG Electronics Inc. Disc EAB RACH overload 18

19 2. WI: Relays (RP ) R : Addition of L2 measurements for Data Loss for RNs Nokia Siemens Networks, Nokia Corporation, Huawei, Ericsson, ST-Ericsson CR SA5 RAN2 S Packet loss rate enb UEs enb RNs CATT NSN CR R R : Correction on PUCCH configuration for Un interface CATT CR RAN1 PUCCH RAN2 PUCCH Relay PUCCH HARQ ACK RAN2 RAN1 CR R : Clarification on RN mobility HTC CR Relay DeNB Relay Relay DeNB 19

20 Relay Relay System Information handover Relay DeNB CR Relay handover DeNB RIM RN Mobility Rel-10 NTT DoCoMo Huawei NSN ALU Relay handover handover HTC CR 3. Multiple Timing Advance (TA) Multiple timing advance Timing advance timer (TAT) RACH procedure Timing advance (TA) group reconfiguration TAT UL asynchronous SRS TA group : A. TAT per UE B. TAT per TA group : R : Single TAT for multiple TA Ericsson, ST-Ericsson Disc R : TAT Operation in LTE R11 CA InterDigital Communications Disc Ericsson TAT UE UL enb 20

21 UL CC enb UL CC TA group TAT TA group UL CC TAT TA group TAT TA group TAT cell TAT TAT TAT UE PCell TAG TA timer UE Rel-10 release PUCCH/SRS : SCell SRS configuration release FFS Agreements: 1a) Will go for solution with one TAT per TAG 1b) Will enable usage of separate values for the different TAG's 2: When the TAT associated with Pcell expires, all TAT's are considered expired i.e. and the UE follows the R10 behavior, i.e. the UE flushes all HARQ buffers, clears any configured assignments/grants, and RRC releases PUCCH/SRS for all configured serving cells. 4: When the TAT associated with an Scell TAG expires, - SRS transmissions in Scell TAG shall be stopped (FFS if SRS configuration is released) - CQI/PMI/RI reporting configuration for the SCells is maintained. - MAC flushes all uplink HARQ buffers for the concerned SCells. RACH procedure RACH : R : Parallel RACH Alcatel-Lucent, Alcatel-Lucent Shanghai Bell 21

22 Disc RACH contention based RA UE : Agreement: => Agree the UE does not need to support execution of 2 parallel RACH procedures in parallel. R : RACH issues for supporting multiple TAs Huawei, HiSilicon Disc (QC) SCell trigger RACH procedure SCell (enb) Huawei UE RA UE UL data load balance Agreements: => The UE does not initiate a RA procedure on a SCell in case of new UL data. If serious problems are found, we can reconsider. RA procedure Msg. 2 R : Random Access procedure for multiple TA Panasonic Disc R : Location of Msg2 for RACH on SCell Huawei, HiSilicon Disc R : Contention based RACH for SCellAlcatel-Lucent, Alcatel-Lucent Shanghai Bell Disc contention based RA cross carrier scheduling cross carrier scheduling 22

23 contention based RA : 1) RACH on Scell with no reliable PDCCH on that Scell (hetnet): => Most companies seem to think this should be supported 2) Contention based RACH: => Majority of companies seem to think this is not so essential, but should maybe not exclude this now.? Msg.2 discussion discussion cross carrier scheduling contention based RA Msg.2 RACH procedure issue R : RACH Procedure for SCell TA InterDigitalCommunications UE PCell RACH procedure PCell RACH PDCCH SCell RACH SCell RACH procedure PDCCH serving cell(pcell or any SCell) RACH procedure UE SCell RACH procedure UE activated SCell Radio Link Monitoring(RLM) SCell ( RLM ) SCell 23

24 RACH procedure NTT DOCOMO TA group Change TA group TA group TA enb UE enb UL CC TA group R : Group management for multiple TA Ericsson, ST-Ericsson Disc R : TA Group Management Huawei, HiSilicon Disc R : Comparison of Uplink Time Alignment Synchronization methods for SCell TA groups Panasonic UE DL CC UL CC TA UE enb NB TA group member Rel-10 Pcell TA group Rel-10 TA group TA group Scell TA group enb UL transmission SRS UL CC TA group UE Agreements: 1) We need to support TAG change except for Pcell. 2) So far no strong need identified for additional assistance information from UE. Discussion can continue. 24

25 4. PHR reporting Inter digital Rel-11 PHR reporting R : Inter-band and RRH PHR InterDigital Communications Rel-10 intra-band carrier aggregation (enb) Pcmax,c(configured maximum output power for the cell) UE Pcmax(configured maximum output power for the UE) UE PHR enb Pcmax Rel-11 inter-band carrier aggregation band (power reduction) MPR A-MPR P-MPR band intra-band carrier aggregation carrier component MPR A-MPR P-MPR MPRc=MPR Rel-11 enb Pcmax,c UE Pcmax UE enb Pcmax,c Pcmax UE enb UE Pcmax enb UE inter digital Rel-11 PHR Pcmax PHR inter-band uplink PHR Pcmax inter digital Pcmax PHR 5. Release 10 Change Requests: CR : R : Discussion on L2 Re-establishment Order (co-source with New Postcom) R : CR regarding the L2 Re-establishment Order (co-source with New Postom) 25

26 discussion & CR RRC PDCP & RLC ZTE & New Postcom RRC SPEC requirement sub-clause RRC, PDCP & RLC coordination PDCP CR noted R : Clarification regarding speed dependent reselection parameters CR no strong support noted ( UMTS SPEC SPEC ) R : CR regarding SRB1 resuming during RRC connection re-establishment CR SRB1 resuming security response message offline discussion spec 26

27 CR noted. R Miscellaneous corrections to stage should shall Normal RRC signalling in E-UTRA procedures are enhanced to support this RRC signalling in E-UTRA is enhanced to support the reporting of detailed location information logged MDT RRC_IDLE For UE in RRC_IDLE idle state Logged MDT procedures as described in apply. Logged MDT measurements retrieval is carriedare sent on Signalling Radio Bearer SRB2 in RRC_CONNECTED state UTRA Idle For UEs in UTRA Idle mode Logged MDT procedures as described in apply. Logged MDT measurements retrieval is carriedare sent on Signalling Radio Bearer SRB4 in RRC Connected mode logged MDT immediate MDT UTRA RRC Connected In CELL_PCH and URA_PCH states UE supports Logged MDT as described in In CELL_DCH state UE supports Immediate MDT as described in In CELL_FACH state MDT is not supported in the current release. 27

28 6. MBMS Service Continuity R :Summary of Discussion [74#34] - LTE: Rel-11 MBMS Huawei (Rapporteur) Report Rapporteur Discussion Discussion non-camping cell MBMS Frequency Indicator 22 RRC 28

29 RRC_CONNECTED 20 Discussion Agreements: General: 3a: MBMS can be provided on more than one frequency. 3b: While an MBMS service is being received, the mechanisms introduced for service continuity target an MBMS service provided in the same frequency/same MBSFN area in neighbouring cells. 4: MBMS frequencies may not apply for whole PLMN and may change from one geographic area to another. 5: The UE is provided with necessary information to inform it about which services are provided on neighbour cells of MBMS frequency. - we will ignore in Rel-11 the case that the network would not be able to provide this information (bad luck) FFS if this is also relevant for connected IDLE: 1: Support of MBMS reception in a non-camping cell is left to UE implementation. 2: The UE which is interested to receive MBMS service(s) makes the MBMS frequency highest priority when it intends to receive the MBMS service and a session is already available or about to start via MBSFN. - FFS how the UE becomes aware of this. CONN: 7: For RRC connected mode UEs, some change to RRC signalling procedures is introduced for the network to provide continuity of MBMS services during handover 8a: UE informs the network that he wants to receive MBMS. R :MBMS enhancements for REL-1 (2), Connected Samsung Samsung RRC_CONNECTED 29

30 (overload) RRC_CONNECTED UE MBMS unicast Agreements: 2 It is up to the UE/ user to decide which service it prioritises i.e. a UE could prioritise MBMS over unicast 3 The objective of the REL-11 service continuity enhancements is to introduce mechanisms that enable the UE to indicate one MBMS frequency it wants to receive UE RRC_CONNECTED Agreements: 1 Adopt the "network control option" as the basic architecture for the handling of (MBMS) i.e. network is informed about the UE's interest in MBMS by the UE, and then the network tries to ensure that the UE is able to receive MBMS (and unicast services). 2 The UE provides MBMS interest information at the level of a frequency (rather than of an individual service). Other info is FFS. 5 Introduce a new message, the MBMSInterestIndication message, by which the UE indicates its interest in MBMS frequency reception 7 The UE sends the concerned message whenever the interest changes w.r.t. the signalled information - FFS if we can limit signalling further R :eMBMS Service Continuity and UE capability Qualcomm Incorporated (Qualcomm) 30

31 PCell Agreements: 1 Reuse the existing SupportedBandCombination IE to derive MBMS related reception capabilities: I.e. if the network wants to ensure the UE is able to receive MBMS and unicast bearers, it has to ensure that all unicast frequencies and the MBMS frequency are indicated as on supported combination in the SupportedBandCombination signalling. FFS whether we need additional UE signalling to indicate it supports MBMS reception in only Pcell, or in all frequencies of a bandcombination. 7. Hetnet mobility enhancements Hetnet mobility Agreements: 0: TR should clearly indicate that HOF and RLF definitions are different from RRC 0': Add the purpose of the calibration clearly in the TR e.g. explaining that in certain cases simulation assumption are simplified to enable calibration 1: For the purpose of RLF monitoring, the basic L1 processing configurations should be: L1 sample rate is once every 10ms, thel1 samples are filtered by a linear filter with a sliding window of 200ms. 2 When a UE detected a HO failure in state 2, the UE will be removed from the simulation 3: For the purpose of PDCCH failure monitoring in state 2, the L1 sample rate is once every 10ms, the L1 samples are filtered by a linear filter with a sliding window of 200ms. 4: For the purpose of PDCCH failure monitoring in state 3: the L1 sample rate should be at least two samples during the 40ms (handover execution time) and averaged over 40ms. The following proposal are carried over from the discussion: 5: For calibration only, companies should use a hotspot simulation circle size of 200 m in diameter for the ISD=500 m case. For the case of ISD = 1732 m, the circle size is FFS. 6: Adopt Number of RLFs per UE per second as the metric for logging the RLFs. 7: Adopt Ping-pong rate = (number of ping-pongs)/(total number of successful handovers excl. handover failures) [where: a ping-pong is defined in TR v0.1.0] 8: Macro-to-macro handover functions should be simulated, but logging the macro-to-macro handover related metrics is not required. Companies are allowed to log the macro-to-macro handover metrics. However, the macro-to-macro handover results shall be logged separately from the macro/pico results, and the macro-to-macro handovers shall not be included into the total number of handovers for macro/pico HO failure rate calculation. 9: Add the clarification on the correlation distance: NOTE: this is the distance where correlation is 0.5 (not 1/e as defined in TR B ). 10: At the mean time, whenever there is a handover failure, the time of state should not be logged. For the case of handover failure time-of-stay is not defined currently and is FFS. 11: Log the RLF in state 3 is not needed 31

32 MTC Study item: RAN improvements for Machine Type communication RAN2 TR v1.0.0 RAN#53 EAB EAB EAB CATT EAB overload EAB 30 access delay delay MTC RAN2 SA1 PLMN RAN EAB PLMN EAB Broadcast UE PLMN EAB RAN MTC MTC MTC AS NAS 32

33 Relay L2 L2 Relay Rel-10 Relay RAN Plenary Rel-10 Multiple TA CR (Change Request) CR CR spec CR noted agreed SPEC CR CR LTE RAN2#75 RAN2 MBMS CA discussion [75#20] LTE: Capture agreements on Rel-11 Carrier Aggregation enhancements [Nokia] - Capture agreements on Carrier Aggregation enhancements (multiple timing advance) in CR to

34 => Intended output: Technically endorsed CR to in R (will not be submitted to RAN) [75#22] LTE: Capture agreements on Rel-11 MBMS [Huawei] - Capture agreements on MBMS Service Continuity in CR to => Intended output: Technically endorsed CR to in R (will not be submitted to RAN) [75#33] LTE: Carrier Aggregation scenarios and resulting requirements [NTT DCM] - Discuss deployment scenarios and based on that answer need for cross carrier Msg2 and contention based access - Try to reduce the number of possible solutions. => Intended output: discussion report to RAN#76 [75#35] LTE: MBMS Service Continuity [Huawei] - What to broadcast in assistance information? Rely on ESG for session timing and linking MBMS service to MBSFN service area id? Or broadcast a list of starting/ongoing sessions in other frequencies? - Who takes the initiative to release the EPS bearers (and unicast bearers) in case of congestion on the MBMS layer? Would it concern all unicast bearers or only GBR bearers? How is the bearer re-established after congestion? => Intended output: discussion report to RAN#76. RAN2#75bis discussion LTE RAN2#75 work item 3GPP RAN2 Rel-11 34

2

1 2 3 4 PHY (RAN1) LTE/LTE-A 6.3 Enhanced Downlink Multiple Antenna Transmission 6.3.1 CSI RS 6.4 Uplink Multiple Antenna Transmission 6.4.1 Transmission modes and Signalling requirements for SU-MIMO 6.5