WF on PBCH Coverage Enhancement

Slides:



Advertisements
Similar presentations
Way forward for LTE DL 4Rx AP SI on RF
Advertisements

Way Forward Proposals for Inter-band CA Consisting of B41
WF on design of physical downlink control channel for MTC CATT, Alcatel Lucent, Alcatel Lucent Shanghai Bell, Ericsson, ETRI, InterDigital, MediaTek, NTT.
Way forward on eIMTA signaling to support up to 32 component carriers
WF on DL LBT Scheme for DRS
3GPP TSG RAN WG1 # R1-15xxxx Fukuoka, Japan 25th – 29th May 2015
[Qualcomm, Ericsson, Nokia Networks, Huawei,…]
WF on CQI Table for eMTC ZTE, Sony, Nokia, Ericsson, Samsung… R GPP TSG RAN WG1 #83 Anaheim, USA, 15th – 22nd November, 2015 Agenda item
WF on Support of EBF/FD-MIMO Features in TM9
WF on MCOT and CWS for LBT priority classes
WF on Regulation and MCOT
WF on SIB1bis Transmission
WF on LAA DL Multi-Channel LBT
Proposal for NB-IoT single-tone only UE
WF on UE capability signaling for FD-MIMO Class B LG Electronics, Intel Coorporation, NTT DOCOMO, Qualcomm 3GPP TSG RAN WG1 Meeting #84 R St Julian’s,
Clarification of the scope of the study on latency reduction techniques for LTE 3GPP TSG RAN Meeting #71RP-16xxxx Göteborg, Sweden, March , 2016.
WF on MCOT limit Signaling and Modifying LBT type Ericsson, … 3GPP TSG RAN WG1 #85 R1-16xxxx Nanjing, China 23 rd – 27 th May 2016 Agenda item:
3GPP TSG RAN WG2 meeting #92 Nanjing, China 23-27, May 2016 R
WF on Supporting different Numerologies in a NR carrier LG Electronics, [Huawei, HiSilicon, Panasonic], 3GPP TSG RAN WG1 Meeting #85R Nanjing,
Offline discussion on remaining details on RRM measurements
WF on Bandwidth Part for DL common channel
WF on RA-RNTI design 3GPP TSG RAN WG1 Meeting NR#3 R1-171xxxx
3GPP TSG-RAN WG4 Meeting NR#3 Nagoya, Japan, 18 – 21 Sep, 2017
Offline Discussion on remaining details about RACH Procedure
Draft WF on single Tx switched UL
3GPP TSG-RAN WG4 Meeting #84bis
Initial workplan on NR spectrum
WF on NPUSCH scrambling for Rel-14 NB-IoT
WF on pre-DFT PT-RS pattern for DFTsOFDM
WF on single Tx switched UL
ITU-R Ad-Hoc Contact person
RACH configuration ZTE, Sanechips R1-171xxxx
3GPP RAN1 #90 meeting summary on LAA Enhancements
WF on Beam Indication for Beam Management
WF on NB-IoT Radio Link Monitoring Performance Test Procedure
WF on measurement capability and measurement gap for NR
Way forward on emissions scaling
Way forward on UE EIS Spherical Coverage and Beam Correspondence
3GPP TSG RAN WG1 Meeting #90bis
R : SRS Enhancements for LTE-A
WF on remaining open items for allowing 1Tx transmission in LTE-NR DC
WF on Beam failure recovery
WF on SS Block Index Reporting through RACH Procedure
Way forward on cell identification in NR
Discussion on TB-ack/CBG-Nack for initial transmissions
Intel Corporation, Apple
Proposal for defining requirement of LTE BHH TRP/TRS
3GPP TSG RAN Meeting #67 Shanghai, China, 9 – 12 March, 2015
Samsung, KT Corp., NTT DOCOMO, Verizon, [ZTE], [CATT], [Intel]
WF on beam reporting CATT, Intel R1-17xxxxx
WF on Beam-Related Indication
WF on CSI timing offset for PUSCH
Shanghai, China, April 11-15, 2011 Source: Qualcomm Incorporated
WF on Radio Link Monitoring in NR
Motorola Mobility, Lenovo, …
WF on UE mandatory channel bandwidth for NR bands
Evaluation Model for LTE-Advanced
WF for 4Rx CA 256QAM(1/2 layer) and 3/4 layers tests in Rel-14
Motivation for WI on "LTE-based V2X Services"
Way Forward on Coexistence Evaluation Methodologies for LAA
WF on LTE-NR DC with UL coexistence
Nortel Corporate Presentation
WF on UL Beam Management
WF on UL Beam Management
WF on CB-group based retransmission
Explanation of draft TP IP Radio Network Development Department
WF on Phase discontinuity issue in intra-band EN-DC with 1-PA
WF on LTE-NR Coexistence
3GPP RAN1 status on NR-Unlicensed
Presentation transcript:

WF on PBCH Coverage Enhancement 3GPP TSG RAN WG1 #80 Athens, Greece, February 9-13, 2015 Agenda item 7.2.1.2.3 R1-15xxxx WF on PBCH Coverage Enhancement Huawei, HiSilicon, Ericsson, InterDigital

Rel-13 background Many Rel-12 agreements were adopted into Rel-13 at RAN1#79 See R1-15400 for full list This includes the existing options for PBCH repetition burst design and configuration (see next slide) These have been discussed in several meetings, and some further progress is needed

PBCH repetition options Agreements: Agree that we only select ONE of the following options that define the repetition burst within the 40ms PBCH cycle: Option 1: Repetition in SF#0 Option 2: Repetition in SF#0 + repetition in SF#5 in odd frames. Option 3: Repetition in SF#0 + repetition in 1 other sub-frame in all frames Option 4: Repetition in SF#0 + repetition in 3 other sub-frames in all frames FFS until the next meeting which REs should be excluded for PBCH repetition Agree that “user data and MIB repetition are assumed not to be sent in the same PRBs.” Agree that we shall only select ONE of the options below for configuration of transmission across 40ms cycles: Option A: Always send repetition in every 40ms cycle. Option B: Dynamic on/off of repetitions on a per 40x ms cycle basis. Option C: Repetition based on pattern(s) across a given number of cycles.

Principles Minimize PBCH acquisition time Balance UE power saving and DL resource usage PBCH acquisition is not the main part of cell acquisition power consumption NW should not be required to always send PBCH repetitions eNB can decide when the PBCH repetition is transmitted.

Proposals Narrow down the options for PBCH coverage enh as follows: Agree that we only select ONE of the following options that define the repetition burst within the 40ms PBCH cycle: Option 1: Repetition in SF#0 Option 2: Repetition in SF#0 + repetition in SF#5 in odd frames. Option 3: Repetition in SF#0 + repetition in 1 other sub-frame in all frames Option 4: Repetition in SF#0 + repetition in 3 other sub-frames in all frames FFS until RAN1#80bis which REs should be excluded for PBCH repetition Agree that “user data and MIB repetition are assumed not to be sent in the same PRBs.” Agree that we shall only select ONE of the options below for configuration of transmission across 40ms cycles: Option A: Always send repetition in every 40ms cycle. Option B: Dynamic on/off of repetitions on a per 40x ms cycle basis. Option C: Repetition based on pattern(s) across a given number of cycles. Choose between Option 3 and Option 4 in RAN1#80bis Choose between Option B and Option C in RAN1#80bis