Max number of DL PDSCH layers for MU-MIMO spatial multiplexing in a cell with high traffic

[RFSpecialist]

Hello all,
What is the maximum number of DL PDSCH layers for MU-MIMO spatial multiplexing that you have encountered in a cell with highest traffic?
In theory it should be up to 16 layers for 32T32R AAUs and 64T64R AAUs (vendor dependant this value of 16).
But I doubt it is ever possible to achieve this level of 16 layers with only 32 elements of AAU because it means each layer would need to be generated by 2 AAU elements that means little gain so users would all have to be very close to AAU.
This max DL PDSCH layers parameter is vendor dependant (max value to be set is 16) and can have a value like 2,4,6,8,12,14 or 16.
It helps a lot to increase capacity of the cell in 5G and so users throughput in MU-MIMO scenario.

Then again: what is the maximum value you have seen on the cell with highest traffic as per counters of DL PDSCH layers?

[Jobosco]

Already saw 16 Layers in M-MIMO 64T64R (TD-LTE), but the probability on happening depends a lot of users distribution in the cell (different angles v/h) for SDMA (Spatial Division Multiple Access), SRS available in the cell and if despite of SRS, the algorithm for the weighted matrix beams support GoB (Grid of Beams) as well (both combined SRS+GoB). The penetration of 16 Layers increased when traffic was high.

Another issue to achieve 16 is the efficiency, more layers will result in less efficiency per beam and MCS will drop a lot if users are not close to the Base Station.

Backing to the question, obviously less amount of antenna means less beams. In theory with 64T you should be able to go up to 32 beams and some vendor are currently advertising 24 DL Layers, but realistically penetration would be really low and don’t worth the feature investment. Now, from 8 DL to 16 DL you can expect 20% gain in capacity (I saw that during testing).

Trial in 2017
Band 38 with 20MHz - 64T64R
Avg tput > 120 Mbps (peak 189 Mbps)
RRC connected > 200
Avg DL Layers > 11 (peak 16)

Performance reached 3x gain compared to 8T8R.

[RFSpecialist]

Thanks, was it a live trial? It is hard to meet the condition of more than 200 RRC users connected in 5G in 2017… You probably saw 16 layers recently, not in 2017. Was it in live network or trial again?

Also I don’t understand why gain from 8DL to 16DL is just 20%. It all depends on users location, as close as possible to gNodeB or not. With 8DL layers users can be more distanced from the gNodeB compared to 16layers requirement that would require users really close to gNodeB so we are not comparing apples to apples.

Don’t know which vendor advertised 24 DL layers. The gain for each beamforming of those 24 layers would be really low and would not worth the feature investment unless it increases the AAUs elements from 64 to 128/256/512. I doubt somebody would replace the AAUs just for this. There is no buy-back in this business.

Thank you.

[Jobosco]

It was a live trial in a commercial fixed wireless network running 4G TDD-LTE.
The Base station at time had more than a thousand commercial users, over 200 RRC connected users only in a single cell of 20MHz.

I saw 16 DL layers in 21017 in TDD-LTE, not 5G (in that moment, something called 4.9G or RL13/14).
In different cell the gain from 8DL to 16DL ranged from 20% (High loaded cell) to 40%. Agreed with the sentence about user distribution, but this is not something that we control since user distribution in a cell is a stochastic process, in fact the performance gap will vary a lot from cell to cell. Now keep in mind that allocation is per PRB based, so not all resources will be transmitted in 16DL layers or 8DL layers. Is a distribution.

The curves below is from the trial, so practical measurements.

Performance x Nº DL Layers

Cell Performance Comparison

MUBF Layers Distribution at Busy hour

Note* Less than 0.5% has achieved 16DL. Today with 256AE’s instead of 128AE’s (my case above) is more easy to achieve 16DLs in 64T64R.

I can’t say vendor or operator.

[RFSpecialist]

Nice graphs, thanks for sharing all this info.