3GPP TSG RAN WG1 NR Ad-Hoc#2
`
`R1-1710596
`
`Qingdao, P.R. China 27th – 30th June 2017
`
`Agenda Item:
`
`5.1.2.2.2
`
`Source:
`
`Title:
`
`Lenovo, Motorola Mobility
`
`Discussion of beam recovery procedure
`
`Document for:
`
`Discussion
`
`1
`
`Introduction
`
`An important feature of 5G NR is beam management[1]. To manage and maintain effective beam link pairs, recovery
`from beam failures is needed. A UE may initiate the beam recovery process by sending beam failure recovery request
`to gNB. In RAN1#88bis, it was concluded that UE beam failure recovery includes beam failure detection, new
`candidate beam identification, beam failure recovery request, and gNB response to UE beam failure recovery request
`and UE monitoring [2]:
`
`Agreements:
`
`•
`
`•
`
`• UE Beam failure recovery mechanism includes the following aspects
`– Beam failure detection
`– New candidate beam identification
`– Beam failure recovery request transmission
`– UE monitors gNB response for beam failure recovery request
`Beam failure detection
`– UE monitors beam failure detection RS to assess if a beam failure trigger condition has been met
`– Beam failure detection RS at least includes periodic CSI-RS for beam management
`SS-block within the serving cell can be considered, if SS-block is also used in beam
`•
`management as well
`FFS: Trigger condition for declaring beam failure
`–
`• New candidate beam identification
`– UE monitors beam identification RS to find a new candidate beam
`– Beam identification RS includes
`Periodic CSI-RS for beam management, if it is configured by NW
`•
`Periodic CSI-RS and SS-blocks within the serving cell, if SS-block is also used in beam
`management as well
`Beam failure recovery request transmission
`Information carried by beam failure recovery request includes at least one followings
`–
`Explicit/implicit information about identifying UE and new gNB TX beam information
`•
`Explicit/implicit information about identifying UE and whether or not new candidate
`beam exists
`FFS:
`
`•
`
`•
`
`•
`
`•
`
`•
`
`Information indicating UE beam failure
`• Additional information, e.g., new beam quality
`– Down-selection between the following options for beam failure recovery request transmission
`PRACH
`•
`PUCCH
`PRACH-like (e.g.,different parameter for preamble sequence from PRACH)
`•
`– Beam failure recovery request resource/signal may be additionally used for scheduling request
`• UE monitors a control channel search space to receive gNB response for beam failure recovery request
`FFS: the control channel search space can be same or different from the current control channel
`–
`search space associated with serving BPLs
`FFS: UE further reaction if gNB does not receive beam failure recovery request transmission
`
`–
`
`Samsung Exhibit 1006, Page 1 of 5
`
`

`

`In RAN1#89 meeting, it was further confirmed to use both PRACH and PUCCH for beam failure recovery request
`[3]:
`
`Agreements:
`
`•
`
`•
`
`•
`
`Support the following channel(s) for beam failure recovery request transmission:
`– Non-contention based channel based on PRACH, which uses a resource orthogonal to resources of
`other PRACH transmissions, at least for the FDM case
`FFS other ways of achieving orthogonality, e.g., CDM/TDM with other PRACH resources
`•
`FFS whether or not have different sequence and/or format than those of PRACH for other
`purposes
`• Note: this does not prevent PRACH design optimization attempt for beam failure recovery
`request transmission from other agenda item
`FFS: Retransmission behavior on this PRACH resource is similar to regular RACH
`procedure
`– Support using PUCCH for beam failure recovery request transmission
`FFS whether PUCCH is with beam sweeping or not
`•
`• Note: this may or may not impact PUCCH design
`– FFS Contention-based PRACH resources as supplement to contention-free beam failure recovery
`resources
`From traditional RACH resource pool
`•
`4-step RACH procedure is used
`•
`• Note: contention-based PRACH resources is used e.g., if a new candidate beam does not
`have resources for contention-free PRACH-like transmission
`– FFS whether a UE is semi-statically configured to use one of them or both, if both, whether or not
`support dynamic selection of one of the channel(s) by a UE if the UE is configured with both
`
`
`
`Agreements:
`
`• To receive gNB response for beam failure recovery request, a UE monitors NR PDCCH with the assumption
`that the corresponding PDCCH DM-RS is spatial QCL’ed with RS of the UE-identified candidate beam(s)
`– FFS whether the candidate beam(s) is identified from a preconfigured set or not
`– Detection of a gNB’s response for beam failure recovery request during a time window is supported
`FFS the time window is configured or pre-determined
`•
`FFS the number of monitoring occasions within the time window
`FFS the size/location of the time window
`If there is no response detected within the window, the UE may perform re-tx of the
`request
`
`•
`
`•
`
`•
`
`–
`
`FFS details
`•
`If not detected after a certain number of transmission(s), UE notifies higher layer entities
`FFS the number of transmission(s) or possibly further in combination with or solely
`•
`determined by a timer
`
`
`
`In this contribution we provide our view on further details of beam failure recovery request.
`
`
`
` 2
`
` Discussion
`
`A UE can be configured with PRACH resources for reporting beam failure to gNB and initiate beam recovery process.
`Based on the agreement in the last meeting, this PRACH resource can be configured for beam recovery request only
`and orthogonal to other PRACH transmissions. FDM, TDM and/or CDM can be used to guarantee orthogonality.
`There are multiple reasons that UEs, in both RRC_IDLE mode and RRC_CONNECT mode, require to transmit in
`PRACH resources. From the system point of view, a UE may access the PRACH channel for the following reasons:
`
`For IDLE mode UE:
`-
`Initial access from RRC_IDLE;
`- On-demand SI request transmission
`
`For INACTIVE mode UE:
`- On-demand SI request transmission
`- Transition from RRC_INACTIVE to RRC_CONNECTED
`
`Samsung Exhibit 1006, Page 2 of 5
`
`

`

`
`For CONNECTED mode UE:
`- RRC Connection Re-establishment procedure;
`- Handover;
`- DL data arrival during RRC_CONNECTED requiring random access procedure, e.g. when UL
`synchronisation status is "non-synchronised";
`- UL data arrival during RRC_CONNECTED requiring random access procedure, e.g. when UL
`synchronisation status is "non-synchronised" or there are no PUCCH resources for SR available.
`- Beam recovery request transmission
`
`
`
`Because IDLE mode UE and INACATIVE mode UEs do not have UL synchronization with the gNB, they are subject
`to larger timing offset at the gNB receiver and may require longer CP and guard time. For CONNECTED mode UEs
`synchronized to gNB, they do not need longer CP or guard time. A shorter PRACH format similar to LTE PRACH
`preamble format 0 may be used. Therefore the best PRACH configuration or preamble format may be different for
`RRC_IDLE UE and RRC_CONNECTED UE requesting beam recovery. To reduce the PRACH resource overhead, it
`is best that the PRACH used by RRC_CONNECTED UE for beam failure recovery request do not share the same
`time and frequency resource with the PRACH used by RRC_IDLE or RRC_INACTIVE UE, so each type of UEs can
`transmit with the their respective best PRACH formats.
`
`Proposal 1: Separate frequency and time resources are configured for PRACH for beam failure recovery
`for RRC_CONNECTED UEs and PRACH for RRC_IDLE UEs.
`
`A separate PRACH resource or resource pools may be assigned for beam recovery request transmission. In the current
`agreement, non-contention based PRACH channel is defined as PRACH that uses a resource orthogonal to resources
`of other PRACH transmissions. If the number of RRC_CONNECTED UEs is large, there may not be enough
`resources to configure each UE a dedicated contention-free PRACH resource for beam recovery. In order to allow
`flexibility for resource allocation and flexibility for gNB implementation, both dedicated PRACH and shared PRACH
`should be supported. The gNB may assign time and frequency resources to accommodate all the needs for
`RRC_CONNECTED UEs, while assigning either dedicated preambles to individual UEs, or a pool of PRACH
`sequences to multiple UEs, for transmission of beam failure recovery request. In the latter case, a UE may choose a
`PRACH sequence from the configured sequence pool to transmit its request. Although contention may take place in
`this case, it is only contending for the attention of the gNB with other RRC_CONNECTED UEs making the same
`request. Because the beam failure and recovery process is independent between different UEs, we do not expect heavy
`collision with reasonable configuration of PRACH resources. Combining dedicated and shared preambles for UE
`beam failure recovery request allows gNB the flexibility to allocate the amount of dedicated or shared sequences
`based on the number of RRC_CONNECTED UEs and their perceived mobility and channel condition.
`
`Proposal 2: A RRC_CONNECTED may be either configured a dedicated preamble, or a pool of
`preambles, for transmission of beam failure recovery request, in configured time and frequency resources.
`
`To further reduce the contention on the beam recovery request PRACH, gNB may further limit the access of to the
`PRACH resource if a UE is able to transmit using the shared PRACH resource pool only if it is explicitly enabled. The
`gNB can monitor the beam link quality to a UE through the beam management process (P1 or P2), and use MAC CE
`enable the UE’s access through the configured shared PRACH resource pool when the quality of the beam link pair
`degrades close to the beam failure threshold. It is up to gNB to enable or disable the access to shared resource pool.
`Additional information can be found in our companion RAN2 contribution [??].
`
`Proposal 3: UE’s access to the shared PRACH resource pool to request beam failure recovery can be
`further controlled by gNB through MAC CE.
`
`We cannot assume a UE always has a PRACH resource, dedicated or shared, configured for its beam failure recovery
`request. For example, a beam failure may occur before the gNB configures this preamble or preamble pools for the
`UE. As a back, a UE should be able to transmit its beam failure recovery request through a PRACH resource
`configured for other purposes whenever available. In this case, if it transmits a beam failure recovery request and
`receives a RAR from the gNB, the UE may signal the beam failure recovery details to the gNB in Message 3.
`
`Proposal 4: If the PRACH sequence for beam failure recovery request is not configured, a
`RRC_CONNECTED UE making beam recovery request may access through other PRACH resources.
`
`Besides PRACH, PUCCH can also be used to transmit beam failure recovery request. When a UE has a good
`candidate beam that it can transmit with, it can transmit its beam recovery request through PUCCH more reliably and
`also with less latency than the 4 step PRACH process. In this case, PUCCH should be given higher priority than
`PRACH. However, due to the time-sensitive nature of the beam failure recovery request, it is important that the
`
`Samsung Exhibit 1006, Page 3 of 5
`
`

`

`request is sent to the gNB as soon as possible. If the PRACH resource is available before the next PUCCH, UE should
`transmit the beam failure recovery request in PRACH. However, PUCCH can be used efficiently only if UE has a
`good candidate beam to send it. When a UE does not have a candidate beam, it needs to resort to beam sweeping to
`send the PUCCH. This is both time and resource consuming. Therefore no beam sweeping should be allowed for UE
`to transmit the beam recovery request through PUCCH.
`
`Proposal 5: A UE should transmit beam failure recovery request in the first available PUCCH or
`PRACH.
`
`Proposal 6: Beam sweeping is not used when UE transmits beam recovery request with PUCCH.
`
`When a UE transmits beam failure recovery request in a non-dedicated PRACH resource, due to potential collision
`with other PRACH transmitted in the same resource, there is no guarantee that it will be successful at the first attempt.
`Subsequent transmission in PUCCH should be allowed before it receives the corresponding Message 2 in the RAR
`window to enhance the reliability and to reduce the latency. But it receives Message 2 afterwards, it should respond to
`Message 2 and follow through the 4 step RACH process.
`
`Proposal 7: A UE can transmit additional beam failure recovery request through PUCCH after it first
`transmits using PRACH and before it receives the corresponding Message 2.
`
`After sending the beam recovery request, either through PRACH or PUCCH, the UE waits for response from the gNB.
`The procedure should be different depending on whether the request was sent in PRACH or PUCCH. For PRACH,
`the regular 4-step RACH procedure should be used, with the RAR window defined as in regular PRACH procedure.
`The duration of the RAR window can be configured differently than the other PRACH. If the request was sent in
`PUCCH, a separate time window should be used. The duration of the time window can be configured, and the UE can
`monitor the PDCCH response from gNB continuously in the time window.
`
`Proposal 8: If beam failure recovery request is sent in PRACH, RAR window should be used; if the beam
`failure recovery request is sent in PUCCH, a separate time window can be configured. For both cases, a UE
`should monitor PDCCH from gNB continuously in the time window.
`
`
`
`
`
`3 Conclusion
`
`We have analyzed the requirement for transmitting beam failure recovery request through PRACH and PUCCH,
`based on the properties of PRACH and PUCCH resources and transmission. Based on the analysis, we have made the
`following proposals:
`
`
`
`Proposal 1: CDM is not used between PRACH for beam failure recovery for RRC_CONNECTED UEs
`and PRACH for RRC_IDLE UEs.
`
`Proposal 2: A RRC_CONNECTED may be either configured a dedicated preamble, or a pool of
`preambles, for transmission of beam failure recovery request, in configured time and frequency resources.
`
`Proposal 3: UE’s access to the shared PRACH resource pool to request beam failure recovery can be
`further controlled by gNB through MAC CE.
`
`Proposal 4: If the PRACH sequence for beam failure recovery request is not configured, a
`RRC_CONNECTED UE making beam recovery request may access through other PRACH resources.
`
`Proposal 5: A UE should transmit beam failure recovery request in the first available PUCCH or
`PRACH.
`
`Proposal 6: Beam sweeping is not used when UE transmits beam recovery request with PUCCH.
`
`Proposal 7: A UE can transmit additional beam failure recovery request through PUCCH after it first
`transmits using PRACH and before it receives the corresponding Message 2.
`
`Proposal 8: If beam failure recovery request is sent in PRACH, RAR window should be used; if the beam
`failure recovery request is sent in PUCCH, a separate time window can be configured. For both cases, a UE
`should monitor PDCCH from gNB continuously in the time windoe.
`
`
`
`Samsung Exhibit 1006, Page 4 of 5
`
`

`

`References
`
`[1] 3GPP TR38.802, “Study on new radio (NR) access technology: physical layer aspects”.
`
`[2] Chairman’s notes, RAN1#88bis.
`
`[3] Chairman’s notes, RAN1#89.
`
`[4] RAN2-1706905, “Resource configuration for beam failure recovery request”, Lenovo, Motorola Mobility.
`
`
`
`
`
`Samsung Exhibit 1006, Page 5 of 5
`
`