In the previous two posts on 5G NR massive MIMO, a.k.a. beam forming, I’ve gone into the basic principles of what it can be used for in practice and how antennas for beam forming will look like. Great background information from Keysight and Ericsson respectively. The next question I then had was how mobile device and the network communicate with each other to adapt downlink transmission in mobility situations.
To start with the specs to find out how this is done is quite tricky, one really needs to know what to look for. Fortunately, there are a number of public sources that give an intro of how 5G NR beam control works in practice which makes the exercise a bit easier. The first document I came across is an article in a recent issue of the NTT DoCoMo technical journal and the second one is the beamforming section in “5G for the Connected World” by Chandramouli et. al.. So this is how I understand beamforming control to work on a high level today:
In practice, beamforming control can be done with several mechanisms. The first are so called Synchronization Signal Blocks (SSBs) that are broadcast on a regular basis. Each beam, of which there can be up to 8 in a 5G NR cell below 6 GHz, has its own SSB. All SSBs are broadcast with the same signal strength but in different directions. This means that a mobile device receives the SSBs with different signal strengths. When connecting to the network, a device signals to the network which of the SSBs is received best. During RRC connection establishment it does this by using a Random Access Channel request opportunity that is linked to a particular SSB. This way, the network knows which beam to use to communicate with a particular mobile device in the downlink direction.
Once a radio bearer exists the network then has to keep track of the device so that it can switch a device to another beam when it moves out of the coverage area of the initial beam. Also, it can narrow the beam to a particular device to further improve the signal strength during transmissions to that device by sending Channel State Information Reference Signals (CSI-RS) and asking the device to report back on how these were received.
Keeping track can be done in two ways: The first and perhaps simpler way is to configure the mobile device via an RRCReconfiguration message to do beam reporting on the MAC layer and let the network know how to pre-code/focus the signal energy by telling it which one it should select from a standardized codebook. In other words, it is the mobile’s job to measure the incoming signals and then give the network a hint on how to change the beam.
The second option for the network is to instruct a mobile device to send periodic Sounding Reference Signals (SRS) in the uplink direction. The gNB knows how the SRS transmissions should look like, compares them to what is actually received and then adapts the beam accordingly. Quite a number of different options that can be used in practice.
In any case, RRC messaging is only used to activate beam control for RRC connected state. Once configured, the actual reporting in the uplink direction and commands in the downlink direction are done on the MAC layer, there is no further RRC messaging. (Note: The mechanism looks similar to me as that used for LTE Carrier Aggregation control. Carrier Aggregation is also configured via RRC messaging, but activation and deactivation of secondary cells is done on the MAC layer). This obviously has the advantage that feedback can be given and processed very quickly.
In case things go wrong and a mobile device loses beam connectivity it can start a ‘beam failure recovery procedure’. This is done by indicating a new SSB number during a RACH procedure.
It should be noted at this point that beam measurement results can also be included in RRC measurement reports. However, this is not for beam level mobility management but rather when there is a need for inter-cell mobility. Note that unlike in LTE networks today, there are now two types of mobility management: Beam level mobility handled on the MAC layer and cell level mobility handled on the RRC layer.
So this is my current understanding of beam management. If you have further things to contribute, please consider leaving a comment.