CSI Framework is one of the most complicated structure and process in NR. I have posted three separate notes with different aspect of this topic. I thought I need to write a page which can consolidate the three separate notes and this page is the one.

Before any of the machinery, it helps to be clear about the problem being solved, because it is a simple one. A gNB transmitting downlink has no direct way of knowing what the channel looks like from where the UE is standing. Only the UE can see that.

So the network sends something known, and asks. It places reference signals in the resource grid and tells the UE where they are. Then it says what to measure and when to answer, and the UE reports back. Everything on this page is one of those four things.

The awkward part is that 3GPP did not build one procedure for this. It built a construction kit. Resources, sets of resources, configurations that point at sets, and reports that point at configurations, each layer separately configurable. That is where the complexity comes from. It is also why one framework covers beam management, tracking loops and closed loop MIMO without needing three designs.

• Where to Start ? How to Move forward ?
• Overall Structure of the CSI Framework
• How the RRC Objects Point at Each Other
• What the UE Actually Reports
• Periodic, Semi-Persistent and Aperiodic
• Measuring Interference

Where to Start ? How to Move forward ?

If you have arrived here wanting a reading order rather than a reference, this section is the one to follow. The rest of the page is the map.

What makes it super difficult to understand 5G CSI Framework is due to its extreme flexibility. Actually flexibility itself would not make things difficult of understanding, but in most cases 'flexibility' tend to make configuration very complicated. It is this Complexity to give us hard time to understand 5G CSI. Unfortunately, there is no way to make the 'complexity' simple. What I am trying to do in this section is to give the readers some tips on how to break down the framework and how to tackle each of those broken-down components and move on. This is just based on my personal experience, it may or may not apply to you. Just my two cents.

Following is where I started and how to move forward.

• i) Understand the meaning of < 38.211-Table 7.4.1.5.3-1: CSI-RS locations within a slot > to the point where you can visualize the table onto NR resource grid. (This note on CSI-RS would help you with this)
• ii) Learn how to convert the CSI RS on Resource Grid (the outcome of the step i) to RRC Configuration
• iii) With the practice of step i) and ii), try to configure CSI-RS for TRS before you move further. You may need some study and practice on step [1] and [2] in Overall CSI Framework Structure. I am recommending this because this configuration would not require ReportConfig
• iv) Understand the meaning of this table <Type 1 Single Panel : Based on 38.214 v15.3-Table 5.2.2.2.1-2: Supported configurations of (N1,N2) and (O1,O2)> and learn how to visualize it.  (This note would help you with this)
• v) Learn how to convert the visualized structure (the outcome of step iv) into RRC message. (This note would help you with this)
• vi) [This is optional] If you are interested in more details on the configuration of the antenna panel (e.g, Mathematical structure of each pannel structure), check on this, this, this and this.
• vii) Once you get familiar with all the steps mentioned above, check if you can configure by yourself (or at least understand) a full RRC parameters for a CSI report (You have to go through step [1] , [2] and [3] in Overall CSI Framework Structure.
• viii) Once you got familiar with steps mentioned above, move forward to multi-pannel and codebook type II.
• ix) If you want to see how the various CSI configurations are tested and get some working protocol log, check out this (Amarisoft TechAcademy)

Overall Structure of the CSI Framework

Five steps, and the first three all belong to the network configuring things before anything is measured at all. Only step four involves the UE doing any work, and step five is the network acting on what came back.

Overall procedure for CSI-RS operation can be described as follows and I put the link for the notes which lead you to the details of each step.  

Two things about that sequence are worth saying out loud, because they are easy to miss when the steps are listed neatly.

• Steps 1 to 3 are pure configuration and can all arrive in a single RRC message. Nothing has been measured, nothing has been reported, and the UE has done nothing except store what it was told.
• Step 5 is not specified anywhere. What the network does with a CSI report is entirely up to the scheduler. The standard defines what the UE must send and how, and then stops. Two vendors receiving identical reports may behave completely differently, and both are compliant.

The rest of this page fills in the parts the table above points at but does not explain. What the objects in steps 1 to 3 actually are, what comes back in step 4, and when any of it is allowed to happen.

How the RRC Objects Point at Each Other

The five steps above are the procedure. This is the data structure underneath it, and I found the framework much easier once I had drawn this out once.

One thing to fix in your head before looking. These objects are not nested inside each other in the RRC message. They all sit as flat lists inside CSI-MeasConfig, and the relationships are identifiers, not containment. A CSI-ReportConfig does not hold a resource config. It holds its number.

That distinction is what makes the framework flexible and also what makes it hard to read in a log. One resource set can be referenced by several resource configs. One resource config can be referenced by several report configs. Nothing is owned by anything.

Here is what each level actually decides.

What the UE Actually Reports

Step 4 in the table above says the UE performs the measurement and reports the result. This is what is actually in that report, and I find it the reassuring part of the topic. The list is much shorter than the configuration machinery suggests.

The combinations are not free. The reportQuantity field in CSI-ReportConfig is a choice with a fixed list. You pick one whole combination rather than assembling your own.

Reading that list top to bottom is a decent way to see the framework's range. The same CSI-ReportConfig structure covers a tracking loop that reports nothing, a beam sweep that reports one number, and a full rank adaptive MIMO report.

Periodic, Semi-Persistent and Aperiodic

Two separate settings in the framework use these three words, and I have watched that cause a lot of confusion, including my own. They are not the same setting.

• resourceType in CSI-ResourceConfig says how the reference signal is transmitted.
• reportConfigType in CSI-ReportConfig says how the report comes back.

They are configured independently, but they are not independent. A report cannot be more persistent than the thing it measures, which gives the table its diagonal shape.

Where the report travels follows from the same choice, and it is worth knowing before you go looking for one in a log.

• A periodic report always goes on PUCCH, and the config carries a pucch-CSI-ResourceList to say which resource.
• A semi-persistent report can go on either, and the two cases are separate branches in the ASN.1, semiPersistentOnPUCCH and semiPersistentOnPUSCH.
• An aperiodic report always goes on PUSCH. It was asked for by a DCI, so an uplink grant already exists to carry it.

The practical shape of a real configuration usually follows from that. Periodic reporting keeps a coarse picture alive at low cost. An aperiodic report gets triggered when the scheduler is about to do something that depends on the answer.

Measuring Interference

CQI is a statement about signal quality, and quality needs two numbers. How strong the wanted signal is, and how much everything else is getting in the way. The framework measures those separately, on different resources.

That is why CSI-ReportConfig has three pointers rather than one. The channel comes from resourcesForChannelMeasurement, and interference comes from one of the other two.

• CSI-IM is a resource where nothing is transmitted, deliberately. The UE measures the received power in those REs, and whatever it finds there is by definition not from this cell. Interference and noise, measured directly.
• nzp-CSI-RS-ResourcesForInterference takes the opposite approach. A real signal is transmitted, and the UE is told to treat it as interference. This is how a network estimates what a UE would suffer if it were paired with another user on the same resources.

The second one only makes sense for multi user MIMO, and that is exactly what it exists for. The network is asking a hypothetical question. If I put somebody else on this beam, what CQI would you report then ?

Both pointers are optional in the ASN.1. A report configured with neither still works, and the UE falls back on measuring interference wherever it can. That is one reason CQI from different implementations is not always comparable.