Controllable beam management accuracy

Abstract

In one aspect there is provided a process for beam management. In some embodiments, the process includes: a TRP classifying a data session between the TRP and a UE into one of at least two classifications; and the TRP selecting a beam management procedure for managing one or more BPLs between the TRP and the UE based on the classification into which the data session is classified.

Claims

1. A method for beam management, the method comprising: a transmission point classifying a data session between the transmission point and a user equipment (UE) into one of at least two classifications, the at least two classifications including a long data session and a short data session; and the transmission point selecting a beam management procedure for managing one or more beam pair links between the transmission point and the UE based on the classification into which the data session is classified.

2. The method of claim 1, wherein the transmission point classifies the data session based on i) transmit buffer status information indicating a status of one or more of a DL transmit buffer and an UL transmit buffer and/or ii) information received from the UE.

3. The method of claim 2, wherein the transmission point classifies the data session based on the information received from the UE.

4. The method of claim 3, wherein the information received from the UE indicates indirectly that that data session is a long data session.

5. The method of claim 3, wherein the information received from the UE explicitly requests extended beam management.

6. The method of claim 2, wherein the transmission point classifies the data session based on the transmit buffer status information.

7. The method of claim 6, wherein: the transmit buffer status information indicates an amount of data in one or both of: the DL transmit buffer waiting for transmission to the UE, and the UL transmit buffer waiting for transmission to the transmission point; the transmission point classifies the data session as a short data session if the amount of data is less than a first threshold; and the transmission point classifies the data session as a long data session if the amount of data is greater than a second threshold.

8. The method of claim 6, wherein the transmit buffer status information indicates a total amount of data in a DL transmit buffer waiting for transmission to the UE and an UL transmit buffer waiting for transmission to the transmission point combined, the transmission point classifies the data session as a short data session if the total amount of data is less than a first threshold, and the transmission point classifies the data session as a long data session if the total amount of data is greater than a second threshold.

9. The method of claim 1, further comprising: before classifying the data session, the transmission point selecting a first transmit, TX, spatial filtering configuration to use to communicate data to the UE.

10. The method of claim 9, wherein selecting the beam management procedure comprises determining whether to use a second TX spatial filtering configuration for communicating data to the UE.

11. The method of claim 10, wherein the transmission point determines to use the second TX spatial filtering configuration as a result of classifying the data session as a long data session, and after determining to use the second TX spatial filtering configuration, the transmission point selects the second TX spatial filtering configuration.

12. A method for beam management, the method comprising: a transmission point (TRP) selecting a first transmit (TX) spatial filtering configuration for use in transmitting data to a user equipment (UE) as part of a data session with the UE; the transmission point determining whether the data session with the UE should be classified as a long data session; and as a result of determining that the data session with the UE should be classified as a long data session, establishing a second TX spatial filtering configuration for the UE.

13. The method of claim 12, wherein establishing the second TX spatial filtering configuration for the UE comprises defining a time schedule for transmitting physical downlink control channel transmissions using the first and second TX spatial filtering configurations.

14. The method of claim 13, further comprising the transmission point transmitting to the UE scheduling information regarding the defined time schedule.

15. The method of claim 14, wherein the scheduling information indicates a slot in which a transmission point may transmit control information to the UE using the second TX spatial filtering configuration.

16. The method of claim 12, wherein determining whether the data session with the UE should be classified as a long data session comprises obtaining transmit buffer status information, the obtained transmit buffer status information indicates an amount of data in one or both of: a DL transmit buffer waiting for transmission to the UE, and an UL transmit buffer waiting for transmission to the transmission point, and the transmission point determines that the data session should be classified as a long data session as a result of determining that the amount of data is greater than a threshold.

17. The method of claim 12, wherein the transmission point determines that the data session with the UE should be classified as a long data session as a result of receiving certain information from the UE.

18. The method of claim 17, wherein the information received from the UE indicates indirectly that that data session is a long data session.

19. The method of claim 18, wherein the information received from the UE explicitly requests extended beam management.

20. A transmission point (TRP), the transmission point comprising: a transmitter; a receiver; and a data processing system comprising one or more processors, wherein the transmission point is configured to perform operations comprising: selecting a first transmit (TX) spatial filtering configuration for use in transmitting data to a user equipment (UE), as part of a data session with the UE; determine whether the data session with the UE should be classified as a long data session; and as a result of determining that the data session with the UE should be classified as a long data session, establish a second TX spatial filtering configuration for the UE.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

(2) FIGS. 1A, 1B and 1C illustrate the use of active and monitored BPLs for communications between a TRP and a UE.

(3) FIG. 2 is a flow chart illustrating a process according to one embodiment.

(4) FIG. 3 is a flow chart illustrating a process according to one embodiment.

(5) FIG. 4 is a block diagram of TRP according to some embodiments.

DETAILED DESCRIPTION

(6) As mentioned above, the maintenance of a monitored BPL is important for robust communication in the case that the active BPL becomes blocked (i.e., the BPL experiences a BPLF), either by an object that moves into the active BPL path or an object behind which the UE moves and becomes shadowed. To recover from a BPLF on the active BPL, the TRP and UE should switch together to the monitored BPL. This process is illustrated in FIGS. 1A, 1B and 1C.

(7) In FIG. 1A, there is shown a TRP 150 (e.g., a base station) using one active BPL for UE 101 to transmit data to the UE 101 (e.g., control signaling and/or user data) and further using one monitored (backup) BPL for the UE 101. While FIGS. 1A, 1B, and 1C illustrate a single TRP communicating with the UE, in other embodiments two or more TRPs may be communicating with the TRP, wherein one of the TRPs uses the active BPL to communicate with the UE and another of the TRPs uses the monitored BPL to communicate with the UE. The active BPL comprises active TRP TX beam 102 and the corresponding active UE RX beam 106, and the monitored BPL comprises the monitored TRP TX beam 104 and the corresponding monitored UE RX beam 108. As used herein a beam is a spatial filtering configuration, such as, for example, antenna weights. Hence, a TX beam may be referred to as a TX spatial filtering configuration.

(8) In FIG. 1B there is shown an object 190 that is blocking the active BPL, thereby causing the UE to detect a BPLF with respect to the active BPL (i.e., the active TRP TX beam/active UE RX beam pair). A problem arises in that the TRP cannot switch to the monitored BPL since the UE is still monitoring the UE RX beam 106 corresponding to the active TX beam 102 as the UE is unaware of the blocking. Moreover, the TRP may also be unware of the blocking situation.

(9) To restore the connection between the TRP and the UE, the TRP can use the monitored BPL as the active BPL for the UE, as illustrated in FIG. 1C. However, to efficiently perform this beam switching, the TRP must first signal to the UE that it will start using the monitored BPL as the active BPL, otherwise the UE will not know which UE RX beam to use during reception (i.e., RX beam 106 or RX beam 108). This is problematic because the active BPL, which is used for control signaling, is blocked and has poor or non-existing channel quality. If the blocking happens slowly, there may be time to perform this signaling before the signal degrades too much. There is a risk that the blocking will happen too quickly such that the TRP does not have time to signal a “beam switch” (a.k.a., “BPL switch”) to the UE, and in this case the UE will continue to use the RX beam 106 corresponding to the TX beam 102 that is now blocked.

(10) As noted in the summary section above, the process of establishing and maintaining a primary (active) BPL and a secondary (monitored) BPL for robustness purposes takes some time. In today's networks, however, the traffic profile is such that a very large fraction of data sessions are short in duration. Consequently, there is often not enough time to build in robustness and data throughput optimizations for the control or data channels, respectively. For those data sessions that are long enough, however, it is highly desirable to support such mechanisms to create a good user experience.

(11) Accordingly, embodiments disclosed herein use a baseline beam management procedure for short data sessions and an extended beam management procedure that adds robustness and throughput optimization for longer data sessions. As discussed above, a data session can be characterized as short or long based on an uplink feedback from the terminal to the network. Such feedback may for instance consist of buffer status information. Such feedback may alternatively be a dedicated signal from the terminal. In one embodiment, the dedicated signal indicates a request for extended beam management. In another embodiment, the dedicated signal indicates indirectly that that data session is long, for example, by an indication of the service type, e.g., in a connection setup procedure. Service type, for example, could correspond to fie download/upload, high rate video session, etc. Hence, in some embodiments, the uplink feedback, such as the BSRs, are used by the TRP to classify a data session (e.g., determine whether the data session is long or short), and then based on this classification of the data session, invoke either the baseline or extended beam management procedures

(12) The baseline procedure provides a coarse level of accuracy. The baseline procedure is appropriate for short data sessions where, for example, a UE spends very little time in the RRC_CONNECTED state. The baseline procedure aims to quickly find a suitable (coarse, “good enough”) beam pair link (BPL), deliver the data in one or only a few transmission opportunities, and then go back to IDLE or RRC_INACTIVE. In the baseline procedure, the focus is on quick, opportunistic data delivery rather than on robustness and throughput optimization. In today's networks, the traffic profile is such that a large fraction of data sessions are short. Hence, it is envisioned that the baseline procedure is used in most cases.

(13) The extended procedure provides an enhanced level of accuracy, and is appropriate for longer data sessions where, for example, user experience in terms of link retainability and integrity (performance) is important. In this case, the UE spends more time in the RRC_CONNECTED state, allowing the network to build in robustness and data throughput optimizations for both the control and data channels before the UE goes back to IDLE or RRC_INACTIVE state.

(14) Embodiments provide an approach to seamlessly determine whether the baseline or extended procedure should be invoked. This decision is based on knowledge of the transmit buffer status in either or both of the DL or UL. In the DL, the transmit data buffer status is directly observable by the TRP. In the UL, the TRP determines the transmit data buffer status indirectly through buffer status reports (BSR) which are transmitted from the UE to the TRP once the UE is in CONNECTED state.

(15) Typically, the baseline procedure is used as a starting point. Then, once the TRP determines that a data session will be long based on, for example, UL buffer status, DL buffer status, and/or a dedicated UL feedback signal from the UE, the TRP decides whether or not the extended procedure should be invoked. In another embodiment, the TRP takes into account other factors in its decision to invoke the extended procedure. Such other factors could include estimates of the path gain to the UE. In the case of large path gain (low loss), the extended procedure may not be needed. Another factor could include estimates of the UE mobility. For a high speed UE, establishing and maintaining multiple beam pair links may be difficult. Furthermore, potential blockage events may not last long, hence the extra robustness from having a secondary (monitored) BPL may not be as important compared to lower speed UEs where blockage events can last for a relatively long time.

(16) In the following two sub-sections, illustrative examples of the baseline and extended procedures are provided for context.

(17) A. The Baseline Procedure Beam Management Procedure

(18) The baseline procedure beam management procedure is characterized by the establishment of a single beam-pair link (BPL) to be used for both control (PDCCH and PUCCH) and data transmission (PDSCH and PUSCH). A BPL consists of the link between the TRP and a UE considering a particular TRP TX beam and UE RX beam. The establishment procedure is transparent to the UE in the sense that no explicit downlink signaling is used to inform the UE of what TRP TX beam is used or what UE RX beam should be used. Hence, this is the case of operation without downlink indication as agreed in 3GPP. To enable this, the TRP periodically transmits a sweep of multiple beamformed CSI-RS resources. TRP TX beam selection is accomplished through CSI-RS Resource Indicator (CRI) feedback from the UE, similar to “Class B, K>1” operation in LTE. The feedback also includes CSI (RI/PMI/CQI) to allow direct scheduling of the UE. Alternatively, only a CSI-RSRP feedback can be configured as the feedback from the sweep, which can be used for rudimentary, coarse link adaptation.

(19) An illustrative sequence of steps in the baseline procedure is as follows:

(20) Step 1:

(21) The TRP configures the UE to measure and report on multiple (K) beamformed periodic CSI-RS resources when the UE transitions from IDLE to CONNECTED, or when the UE hands over to a new cell. For example, the different resources correspond to different TRP TX beams that cover the whole service area for the TRP. In LTE, this configuration occurs in the RRC Connection Setup procedure (part of Msg4) or the RRC Connection Reconfiguration procedure as part of a handover. Covering the whole service area in a periodic beam sweep is efficient for the case of moderate to high load where there are a sufficient number of UEs undergoing state changes and/or handover. At low load, it could be more efficient (in terms of resource utilization) to rely on aperiodic CSI-RS transmission on a UE specific basis. In this case, if the TRP has some rough a priori knowledge of user location, e.g., a coarse beam direction obtained during the RACH procedure, then the beamformed CSI-RS resources could be constrained to cover a local area around the coarse beam direction; however, this is transparent to the UE.

(22) Step 2:

(23) The UE determines an initial UE RX beam without dedicated network (NW) assistance. Unless the UE has some a priori knowledge of a suitable beam direction, it will need to use a wide (sector covering) beam. Hence the system must be dimensioned to ensure sufficient PDCCH coverage even if the UE is not using RX beamforming.

(24) Step 3:

(25) Depending on the configuration, the UE reports CRI indicating the best TRP TX beam in combination with CSI(RI/PMI/CQI) for that beam, or RSRP for multiple of the K beams. The UE will likely need to use a wide (sector covering) TX beam for transmission of the CSI report, e.g., over PUCCH. Likewise, the TRP will most likely need to use a wide RX beam for reception of the CSI report. Hence, in some embodiments, the system is dimensioned to ensure sufficient PUCCH coverage even without UE TX and TRP RX beamforming.

(26) Step 4:

(27) The TRP selects a TX beam based on the UE report and uses that TX beam for both PDCCH and PDSCH transmissions for the UE taking into account the reported CSI. No explicit DL signaling is necessary to indicate the selected TRP TX beam. In addition, the TRP may use the same beam direction for future reception of PUCCH/PUSCH as long as TX/RX correspondence holds at the TRP.

(28) Step 5:

(29) The TRP determines the expected duration of the data session through its observability of DL/UL buffer status. Since much of the DL/UL traffic consists of short data sessions, it may often happen that all data has been delivered in one or at most a few time slots. If so, then the baseline procedure as described above is all that is necessary for a given UE. For longer data sessions, but not long enough to invoke the extended procedure described in the next section, it may be beneficial to refine the TRP TX and/or UE RX beams.

(30) Accordingly, in addition to the above steps, there could be further steps related to refinement of the BPL. These further steps may include:

(31) Step 6a:

(32) The TRP triggers a UE RX beam sweep based on configuring one or more aperiodic (UE specific) beamformed CSI-RS resources. For example, if the CSI-RS resources are drawn from an RRC configured pool, the pre-configuration may be performed at the same time as initial connection setup (described above). Then, the needed CSI-RS resources for this step could be dynamically allocated from the pool when needed. The beamformed CSI-RS resources are constrained to cover a local area around the previously used TRP TX beam. In this procedure, each CSI-RS beam is fixed for some number of time units while the UE tries different RX beams.

(33) Step 6b:

(34) The UE feeds back CRI indicating the best TRP TX beam and simultaneously updates its own RX beam. The CRI report is accompanied by a CSI report corresponding to the refined BPL.

(35) Step 6c:

(36) The TRP updates its TX beam based on the CRI report from the UE (i.e., the TRP may select a new TRP TX beam for us transmitting data to the UE). This refined BPL is used for the remaining PDCCH/PDSCH transmissions in the data session.

(37) B. The Extended Procedure Beam Management Procedure

(38) The extended procedure beam management procedure is intended for long data sessions where there is time to build in extra robustness for PDCCH transmission and optimize PDSCH transmissions. The extended procedure is characterized by establishment of at least a second BPL to be used for PDCCH robustness purposes (the extended procedure is described in U.S. provisional patent application No. 62/417,633, which is attached hereto as Appendix B). The first BPL is referred to as the “active BPL,” and the second (backup) one as the “monitored BPL.” The purpose of having two BPLs is for recovery from sudden blocking events that can occur at mmW frequencies. The UE, in some embodiments, periodically searches for PDCCH transmissions on the monitored BPL with a relatively low duty cycle, e.g., 1 in 10 slots. The periodicity is agreed between TRP and UE such that the LIE knows to switch its RX beam to search for the PDCCH on the monitored BPL during the appropriate slot. In this way, if the active BPL is blocked, PDCCH still gets through. This can be detected at the TRP, and if the blockage continues, the TRP can switch BPLs such that the monitored BPL becomes the new active BPL. Maintaining two BPLs and possibly switching between them requires the use of a BPL identifier, or tag, for the TRP to indicate to the UE which BPL is updated on an ongoing basis. Hence, this is the case of operation with downlink indication as in the above agreement.

(39) An illustrative sequence of steps in the extended procedure is as follows:

(40) Step 1:

(41) The TRP triggers a refinement of the first (active) BPL using the same procedure as in Step 6 above for the baseline procedure, except that when the CSI measurement is triggered, the TRP also transmits an identifier to the UE, e.g., 2 bits, which is used to indicate which BPL is being updated. For example, the 2-bit identifier could be set to ‘00’ which is reserved for the active BPL.

(42) Step 2:

(43) The UE stores (remembers) the refined RX beam setting according to the identifier for the active BPL.

(44) Step 3:

(45) The TRP triggers the establishment of a second (monitored) BPL using, for example, the same procedure as in Step 6 above, except that it avoids using the same TRP TX beam as the active BPL. Furthermore, it may configure a beam sweep over a wider area than that used to refine the active BPL in order to discover a new link. Along with the CSI measurement trigger, the TRP transmits a 2-bit identifier with value set, e.g., to ‘01’ to indicate that the TRP TX beam and UE RX beam is being updated for the monitored link.

(46) Step 4:

(47) The UE stores (remembers) the RX beam setting according to the identifier for the monitored BPL. The UE then switches back to the RX beam used for the active BPL for reception of the next PDCCH transmission.

(48) Step 5:

(49) On an “as needed” basis, the TRP triggers further refinements/updates of both the active and monitored BPLs using the same process as above.

(50) Step 6:

(51) The UE searches for PDCCH transmissions most of the time on the active BPL. With a lower duty cycle (agreed between TRP and UE), the UE searches for PDCCH transmissions on the monitored BPL. In the case that the active BPL becomes blocked, PDCCH transmission may still be received by the UE as long as the monitored BPL does not suffer a similar blocking.

(52) Step 6a:

(53) If the active BPL remains blocked, the TRP may trigger a switch of the BPLs such that the monitored BPL becomes the new active BPL. The UE responds by switching its RX beams such that the PDCCH is monitored most often on the new active BPL and less frequently on the new monitored BPL.

(54) Step 6b:

(55) The TRP may then trigger an update of the monitored BPL to find a better (unblocked) link.

(56) Step 7:

(57) If both BPLs become blocked (catastrophic condition) then the UE may declare a radio link failure and initiate an RRC Connection Re-establishment procedure as in LTE. This process is UE initiated through a RACH attempt to the previous or a new cell. Once re-connected, the beam management process starts again with the baseline procedure and moves to the extended procedure if still needed.

(58) Step 8:

(59) In addition to establishing active/monitored links for PDCCH robustness, the TRP may establish a 2nd active BPL, not to be used for PDCCH transmissions, using a different identifier value, e.g., ‘11.’ The additional active link may be used for optimizing PDSCH performance. For example, higher rank transmission could be supported for D-MIMO or multi-panel transmission. Since the establishment of BPLs may take some time, this optimization is intended for longer data sessions, thus fits better in the extended, rather than baseline procedure.

(60) FIG. 2 is a flow chart illustrating a process 200, according to some embodiments. Process 200 may begin in step 202 in which the TRP classifies a data session between the TRP and a UE into one of at least two classifications. In step 204, the TRP selects a beam management procedure for managing one or more BPLs between the TRP and the UE based on the classification into which the data session is classified (e.g., the TRP transitions to the extended procedure if data session is classified as being long). In some embodiments, in step 202, the TRP classifies the data session based on i) transmit buffer status information indicating a status of one or more of a DL transmit buffer and an UL transmit buffer and/or ii) an UL signal from the UE (e.g., an UL signal from the UE that indicates indirectly that that data session is long, for example, by an indication of the service type or an UL signal from the UE that explicitly requests extended beam management).

(61) FIG. 3 is a flow chart illustrating a process 300, according to some embodiments. Process 300 may begin in step 302 in which the TRP selects a TRP TX beam for use in transmitting data to the UE as part of a data session with the UE. In step 304, the TRP determines whether the data session with the UE should be classified as a long data session in the same manner as described above with reference to step 202.

(62) If the TRP determines that the data session with the UE should be classified as a long data session, then the process proceeds to step 306, otherwise it proceeds to step 308. In step 306, as a result of determining that the data session should be classified as a long data session, the TRP establishes a monitored TRP TX beam (a monitored BPL) for the UE. In some embodiments, establishing a monitored BPL for the UE comprises the TRP defining a time schedule for how to time multiplex PDCCH transmissions between the active TRP TX beam (e.g., the TRP TX beam selected in step 302) and the monitored BPL and signals this info to the UE; the TRP then transmits the PDCCH using the active and monitored BPLs according to the time schedule. More specifically, for example, in step 306 the TRP performs process 700 (see FIG. 7 of the 62/417,633).

(63) In step 308, the TRP continues using a baseline beam management procedure for the UE.

(64) In one embodiment, the transmit buffer status information indicates an amount of data in the a DL transmit buffer waiting for transmission to the UE, and the TRP classifies the data session into a first classification (e.g., a “short” data session classification) if the amount of data is less than a first threshold and the TRP classifies the data session into a second classification (e.g., a “long” data session classification) if the amount of data is greater than a second threshold.

(65) In another embodiment, the transmit buffer status information indicates an amount of data in the a UL transmit buffer waiting for transmission from the UE to the TRP, and the TRP classifies the data session into the first classification if the amount of data is less than a first threshold and the TRP classifies the data session into the second classification if the amount of data is greater than a second threshold.

(66) In another embodiment, the transmit buffer status information indicates an the total amount of data in the DL transmit buffer and the UL transmit buffer combined, and the TRP classifies the data session into the first classification if the amount of data is less than a first threshold and the TRP classifies the data session into the second classification if the amount of data is greater than a second threshold.

(67) FIG. 4 is a block diagram of a TRP 150 according to some embodiments. As shown in FIG. 4, the TRP may comprise: a data processing system (DPS) 402, which may include one or more processors (P) 455 (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a transmitter 405 and a receiver 406 coupled to an antenna 422 for use in wirelessly communicating with a UE; a network interface 448 for use in connecting TRP 150 to a network 110 (e.g., an Internet Protocol (IP) network) so that TRP 150 can communicate with other devices connected to network 110, and local storage unit (a.k.a., “data storage system”) 408, which may include one or more non-volatile storage devices and/or one or more volatile storage devices (e.g., random access memory (RAM)). In embodiments where the TRP includes a general purpose microprocessor, a computer program product (CPP) 441 may be provided. CPP 441 includes a computer readable medium (CRM) 442 storing a computer program (CP) 443 comprising computer readable instructions (CRI) 444. CRM 442 may be a non-transitory computer readable medium, such as, but not limited, to magnetic media (e.g., a hard disk), optical media (e.g., a DVD), memory devices (e.g., random access memory), and the like. In some embodiments, the CRI 444 of computer program 443 is configured such that when executed by data processing system 402, the CRI causes the TRP to perform steps described above (e.g., steps described above with reference to the flow charts). In other embodiments, the TRP may be configured to perform steps described herein without the need for code. That is, for example, data processing system 402 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

(68) While various embodiments of the present disclosure are described herein (including the appendices), it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

(69) Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Abbreviations

(70) DL—Downlink

(71) UL—Uplink

(72) TRP—Transmission/Reception Point

(73) UE—User Equipment

(74) NW—Network

(75) BPL—Beam pair link

(76) BLF—Beam pair link failure

(77) BLM—Beam pair link monitoring

(78) BPS—Beam pair link switch

(79) RLM—radio link monitoring

(80) RLF—radio link failure

(81) PDCCH—Physical Downlink Control Channel

(82) PUCCH—Physical Uplink Control Channel

(83) PDSCH—Physical Downlink Shared Channel

(84) PUSCH—Physical Uplink Shared Channel

(85) RRC—Radio Resource Control

(86) CSI—Channel State Information

(87) CRS—Cell-specific Reference Signal

(88) CSI-RS—Channel State Information Reference Signal

(89) CRI—CSI-RS Resource Indicator

(90) RI—Rank Indicator

(91) PMI—Precoding Matrix Indicator

(92) CQI—Channel Quality Indicator

(93) RSRP—Reference signal received power

(94) RSRQ—Reference signal received quality

(95) gNB—NR base station

(96) BSR—Buffer Status Report

(97) Tx—Transmit

(98) Rx—Receive

(99) RACH—Random Access Channel

(100) MIMO—Multiple Input Multiple Output

(101) D-MIMO—Distributed-MIMO

APPENDIX

(102) The present application claims priority to U.S. provisional application No. 62/444,064, filed on Jan. 9, 2017, which included an Appendix A containing a contribution document. The relevant portion of that Appendix A is reproduced below:

(103) 1. Introduction

(104) In RAN1 #87, the following agreements were made in the area of beam management:

(105) TABLE-US-00001 Agreements: NR supports with and without a downlink indication to derive QCL assumption for assisting UE-side beamforming for downlink control channel reception FFS: details E.g., QCL assumption details E.g., indication signaling (e.g. DCI, MAC CE, RRC, etc.) E.g., beam-related indication for DL control and data channels Agreements: NR to provide robustness against beam pair link blocking Study mechanisms to achieve the above purpose E.g., by enabling PDCCH/PDSCH monitoring with N beams E.g., N = 1, 2, . . . E.g., TDM monitoring, simultaneous monitoring, etc. E.g., by enabling composite beams via e.g., SFBC and/or multi-stage control channel The examples are not intended to be exhaustive

(106) In this contribution, we provide an overview of beam management operation (L1/L2 procedure using CSI-RS) that continues the discussion in [1] from the last meeting and incorporating the above agreements. The intention is to provide context to Ericsson's proposals in other contributions.

(107) 2. Discussion

(108) In [1], an overview of beam management was given, and the notion of a “toolbox” of procedures was introduced to cover the wide range of deployment scenarios envisioned for NR. The beam management framework was discussed in the context of which procedures from the toolbox could be used to handle increasing levels of beam management accuracy making use of the P1, P2, and P3 procedures agreed previously in RAN1.

(109) While this contribution focuses on DL beam management, in a companion contribution [2], we discuss UL beam management using procedures U1, U2, and U3 based on configuration of multiple SRS resources at the UE. UL beam management may be required in addition to DL beam management in cases where Tx/Rx beam correspondence does not hold at the gNB and/or UE. If Tx/Rx correspondence does hold, UL beam management could be used as a replacement for DL beam management; however, this may depend on the deployment scenario.

(110) In this contribution, we elaborate on the DL beam management framework in [1]and introduce the notion of a “baseline” beam management procedure and an “extended” beam management procedure drawing on tools from the toolbox. Broadly speaking, the baseline procedure applies to a coarse level of accuracy and the extended procedure to an increased level of accuracy. The baseline procedure is appropriate for short data sessions where only a small amount of data is transmitted in downlink and/or uplink. The key in the baseline procedure is to quickly find a suitable (coarse, good enough) beam pair link, deliver the data in one or only a few transmission opportunities, and then go back to IDLE or RRC_INACTIVE. In the baseline, the focus is on quick, opportunistic data delivery rather than on robustness and throughput optimization. In today's networks, the traffic profile is such that a very large fraction of data sessions, e.g., 90%, are short. Hence it is envisioned that the baseline procedure is used in most cases.

(111) Observation 1: Most packets in today's network are small and appear bursty, which implies that some baseline beam management should be in place to handle these packets without extensive beam management procedures.

(112) In contrast, the extended procedure applies to an enhanced level of accuracy, and is appropriate for longer data sessions. In this case, the UE spends more time in the RRC_CONNECTED state, allowing the network to build in robustness and data throughput optimizations for both the control and data channels before the UE goes back to IDLE or RRC_INACTIVE. The division between short and long is not necessarily clear cut; however, the network has visibility on what procedures to invoke (baseline or extended), for example, using its knowledge of buffer states in both the DL and the UL. In the latter, the network is made aware of buffer state through regular buffer status reports once the UE is in connected mode.

(113) Relevant components of the baseline and extended beam management procedures are as follows.

(114) 2.1. Baseline Procedure

(115) The baseline procedure is characterized by the establishment of a single beam-pair link (BPL) to be used for both control (PDCCH and PUCCH) and data transmission (PDSCH and PUSCH). A BPL consists of the link between the gNB and a UE considering a particular gNB Tx beam and UE Rx beam. The establishment procedure is transparent to the UE in the sense that no explicit downlink signalling is used to inform the UE of what gNB Tx beam is used or what UE Rx beam should be used. Hence, this is the case of operation without downlink indication as in the above agreement.

(116) To enable this, the gNB transmits a sweep of multiple beamformed CSI-RS resources. The transmission can be aperiodic, semi-persistent, or periodic depending, for example, on the system load. gNB Tx beam selection is accomplished through CSI-RS Resource Indicator (CRI) feedback from the UE, similar to Class B, K>1 operation in LTE. The feedback also includes CSI (RI/PMI/CQI) to allow direct scheduling of the UE. Alternatively, only a CSI-RSRP feedback can be configured as the feedback from the sweep, when can be used for rudimentary, coarse link adaptation.

(117) The baseline procedure primarily consists of procedure P1, and optionally P2/P3 for moderate-length data sessions, i.e., sessions not long enough to warrant the extended procedure.

(118) An illustrative sequence of steps in the baseline procedure is as follows:

(119) Step 1:

(120) The gNB configures the UE to measure and report on multiple (K) beamformed periodic CSI-RS resources when the UE transitions from IDLE to CONNECTED, or when the UE hands over to a new cell. For example, the different resources correspond to different gNB Tx beams that cover the whole service area for the gNB. In LTE, this configuration occurs in the RRC Connection Setup procedure (part of Msg4) or the RRC Connection Reconfiguration procedure as part of a handover. Covering the whole service area in a semi-persistent/periodic beam sweep is efficient for the case of moderate to high load where there are a sufficient number of UEs undergoing state changes and/or handover. At low load, it could be more efficient (in terms of resource utilization) to rely on aperiodic CSI-RS transmission on a UE specific basis. In this case, if the gNB has some rough a priori knowledge of user location, e.g., a coarse beam direction obtained during the RACH procedure, then the beamformed CSI-RS resources could be constrained to cover a local area around the coarse beam direction; however, this is transparent to the UE.

(121) Step 2:

(122) The UE determines an initial UE Rx beam without dedicated NW assistance. Unless the UE has some a priori knowledge of a suitable beam direction, it will need to use a wide beam. Hence the system must be dimensioned to ensure sufficient PDCCH coverage even if the UE is not using Rx beamforming.

(123) Step 3:

(124) Depending on the configuration, the UE reports CRI indicating the best gNB Tx beam in combination with CSI (RI/PMI/CQI) for that beam, or RSRP for multiple of the K beams. The UE will likely need to use a wide beam for transmission of the CSI report, e.g., over PUCCH. Likewise, the gNB will most likely need to use a wide Rx beam for reception of the CSI report. Hence the system must be dimensioned to ensure sufficient PUCCH coverage even without UE Tx and gNB Rx beamforming.

(125) Step 4:

(126) The gNB updates it transmit beam based on the UE report and uses that beam for both PDCCH and PDSCH transmissions taking into account the reported CSI. No explicit DL signalling is necessary to indicate the updated gNB Tx beam. In addition, the gNB may use the same beam direction for future reception of PUCCH/PUSCH as long as Tx/Rx correspondence holds at the gNB.

(127) Step 5:

(128) The gNB determines the expected duration of the data session, for example, through its observability of DL/UL buffer status. Since much of the traffic consists of short data sessions, it may often happen that all data has been delivered in one or at most a few slots. If so, then the baseline procedure as described above is all that is necessary for a given UE. For longer data sessions, but not long enough to invoke the extended procedure described in the next section, it may be beneficial to refine the established beam pair link. If so, the BPL may be refined using procedures P2 and/or P3.

(129) Step 6:

(130) Optionally refine the BPL using P2 and/or P3:

(131) Step 6a

(132) The gNB triggers a UE Rx beam sweep based on configuring one or more aperiodic (UE specific) beamformed CSI-RS resources. For example, if the CSI-RS resources are drawn from an RRC configured pool, the pre-configuration may be performed at the same time as initial connection setup (described above). Then, the needed CSI-RS resources for this step could be dynamically allocated from the pool when needed. The beamformed CSI-RS resources are constrained to cover a local area around the previously used gNB Tx beam. In this procedure, each CSI-RS beam is fixed for some number of time units while the UE tries different Rx beams.

(133) Step 6b:

(134) The UE feeds back CRI indicating the best gNB Tx beam and simultaneously updates its own Rx beam. The CRI report is accompanied by a CSI report corresponding to the refined BPL.

(135) Step 6c:

(136) The gNB updates its Tx beam based on the CRI report from the UE. This refined BPL is used for the remaining PDCCH/PDSCH transmissions in the data session.

(137) 2.2 Extended Procedure

(138) The extended procedure is intended for long data sessions where there is time to build in extra robustness for PDCCH transmission and optimize PDSCH transmissions. The procedure is characterized by establishment of at least a second beam-pair link (BPL) to be used for PDCCH robustness purposes (see [3]). The first BPL is referred to as the “active BPL,” and the second (backup) one as the “monitored BPL.” The purpose of having two links is for recovery from sudden blocking events that can occur at mmW frequencies. The approach proposed in [3] is for the UE to periodically search for PDCCH transmissions on the monitored BPL with a relatively low duty cycle, e.g., 1 in 10 slots. The periodicity is agreed between gNB and UE such that the UE knows to switch its Rx beam to search for the PDCCH on the monitored BPL during the appropriate slot. In this way, if the active BPL is blocked, PDCCH still gets through. This can be detected at the gNB, and if the blockage continues, the gNB can switch BPLs such that the monitored BPL becomes the new active BPL. Maintaining two BPLs and possibly switching between them requires the use of a BPL identifier, or tag, for the gNB to indicate to the UE which BPL is updated on an ongoing basis. Hence, this is the case of operation with downlink indication as in the above agreement.

(139) Proposal: NR supports dynamic indication of an identifier to distinguish between two or more beam pair links maintained by the gNB/UE.

(140) An illustrative sequence of steps in the extended procedure is as follows:

(141) Step 1:

(142) The gNB triggers a refinement of the first (active) BPL using the same procedure as in Step 6 above (P2 and/or P3 procedures), except that when the CSI measurement is triggered, the gNB also transmits an identifier to the UE, e.g., 2 bits, which is used to indicate which BPL is being updated. For example, the 2-bit identifier could be set to ‘00’ which is reserved for the active BPL.

(143) Step 2:

(144) The UE stores (remembers) the refined Rx beam setting according to the identifier for the active BPL.

(145) Step 3:

(146) The gNB triggers the establishment of a second (monitored) BPL using the same procedure as in Step 6 above, except that it avoids using the same gNB Tx beam as the active BPL. Furthermore, it may configure a beam sweep over a wider area than that used to refine the active BPL in order to discover a new link. Along with the CSI measurement trigger, the gNB transmits a 2-bit identifier with value set, e.g., to ‘01’ to indicate that the gNB Tx beam and UE Rx beam is being updated for the monitored link.

(147) Step 4:

(148) The UE stores (remembers) the Rx beam setting according to the identifier for the monitored BPL. The UE then switches back to the Rx beam used for the active BPL for reception of the next PDCCH transmission.

(149) Step 5:

(150) On as “as needed” basis, the gNB triggers further refinements/updates of both the active and monitored BPLs using the same process as above.

(151) Step 6:

(152) The UE searches for PDCCH transmissions most of the time on the active BPL.

(153) With a lower duty cycle (agreed between gNB and UE), the UE searches for PDCCH transmissions on the monitored BPL for one or a few slots. In the case that the active BPL becomes blocked, PDCCH transmission may still be received by the UE as long as the monitored BPL does not suffer a similar blocking.

(154) Step 6a:

(155) If the active BPL remains blocked, the gNB may trigger a switch of the BPLs such that the monitored BPL becomes the new active BPL and transmit an indication to the UE at the next possible monitoring instance. The UE responds by switching its Rx beams such that the PDCCH is monitored most often on the new active BPL and less frequently on the new monitored BPL.

(156) Step 6a:

(157) The gNB may then trigger an update of the monitored BPL to find a better (unblocked) link.

(158) Step 7:

(159) If both BPLs become blocked (catastrophic condition) then the UE may declare a radio link failure and initiate an RRC Connection Re-establishment procedure as in LTE. This process is UE initiated through a RACH attempt to the previous or a new cell. Once re-connected, the beam management process starts again with the baseline procedure and moves to the extended procedure if still needed.

(160) Step 8:

(161) In addition to establishing active/monitored links for PDCCH robustness, the gNB may establish a 2.sup.nd active BPL, not to be used for PDCCH transmissions, using a different identifier value, e.g., ‘11.’ The additional active link may be used for optimizing PDSCH performance. For example, higher rank transmission could be supported for D-MIMO or multi-panel transmission. Since the establishment of BPLs may take some time, this optimization is intended for longer data sessions, thus fits better in the extended, rather than baseline procedure.

(162) 3. Conclusions

(163) In this contribution we made the following observation:

(164) Observation 1: Most packets in today's network are small and appear bursty, which implies that some baseline beam management should be in place to handle these packets without extensive beam management procedures.

(165) Based on the discussion in this contribution we propose the following:

(166) Proposal 1: NR supports dynamic indication of an identifier to distinguish between two or more beam pair links maintained by the gNB/UE.

REFERENCES

(167) [1] R1-1612345, “Beam management overview,” Ericsson, RAN1 #87, November 2016. [2] R1-1700749, “On UL beam management,” Ericsson, RAN1 #87ah-NR, January 2017. [3] R1-1700748, “On robust beam management,” Ericsson, RAN1 #87ah-NR, January 2017.