Problem with FDD band n28 - 15 kHz

FredNys commented 6 months ago

Issue Description

UE not decoding SIB1 when using default config for FDD band n28 with SCS 15 kHz

Setup Details

Tested on B210 and Comba n28 7.2 Cat A radio

Expected Behavior

UE shall detect cell by decoding SIB1. QXDM logs are showing decoding of MIB and PCCH by failing to decoding PDSCH/SIB1. This is confirmed by cell scanner (Matlab Cell search/SIB1, or free5GRAN) where the search space on the grid for the PDSCH containing SIB1 shall be extended by a factor 100.

Actual Behaviour

UE failed to decode SIB1

Steps to reproduce the problem

Using B210:

cell_cfg: dl_arfcn: 154000 # ARFCN of the downlink carrier (center frequency). band: 28 # The NR band. channel_bandwidth_MHz: 20 # Bandwith in MHz. Number of PRBs will be automatically derived. common_scs: 15 # Subcarrier spacing in kHz used for data. plmn: "00101" # PLMN broadcasted by the gNB. tac: 7 # Tracking area code (needs to match the core configuration). pci: 1 # Physical cell ID. nof_antennas_dl: 1 # Downlink number of antennas. nof_antennas_ul: 1 # Uplink number of anntennas. prach: prach_config_index: 7 # PRACH configuration index. prach_root_sequence_index: 1 # PRACH root sequence index. zero_correlation_zone: 0 # Zero correlation zone. prach_frequency_start: 0 # Offset in PRBs of lowest PRACH transmission occasion in frequency domain respective to PRB 0. pdsch: mcs_table: qam256

Additional Information

[Any additional information, configuration or data that might be necessary to reproduce the issue]

05-17.01-06-40-123.txt monitoring_slots.pdf

ismagom commented 6 months ago

Could you share the full config file please?

FredNys commented 6 months ago

Full config file

gnb_rf_b200_fdd_n28_20mhz.yml.zip

carlo-gal commented 6 months ago

Hi @FredNys,

If the UE is not able to detect/decode the SIB1 after receiving the MIB, chances are that the MIB config is wrong.

I have tested the UE attachment using AmariUE, over ZMQ and it works fine. However, I see that the MIB sent by the GNB and received by the AmariUE has a different configuration compared to what I can see from the UE logs you sent.

This is the MIB the GNB is sending. mib_pcap

As you can see from the picture, the pdcch-ConfigSIB1 that is needed to decode the SIB1 is:

      pdcch-ConfigSIB1 
      {
        controlResourceSetZero 2,
        searchSpaceZero 0
      },

Now, if we look at your UE logs, we see

    608 Interpreted PDU:
    609 
    610 value BCCH-BCH-Message ::= 
    611 {
    612   message mib : 
    613     {
    614       systemFrameNumber '000000'B,
    615       subCarrierSpacingCommon scs15or60,
    616       ssb-SubcarrierOffset 0,
    617       dmrs-TypeA-Position pos2,
    618       pdcch-ConfigSIB1 
    619       {
    620         controlResourceSetZero 0,
    621         searchSpaceZero 0
    622       },
    623       cellBarred barred,
    624       intraFreqReselection allowed,
    625       spare '0'B
    626     }
    627 }

Note that the code controlResourceSetZero here is 0, which is different from the value what we send in the MIB1.

However, if you look at the lines above, still in your logs, we see pdcch-ConfigSIB1 = 32

    540 1980 Jan  6  23:11:43.069  [CC]  0xB96D  NR5G ML1 Searcher ACQ Config And Response
    541 Subscription ID = 1
    542 Misc ID         = 0
    543 Major.Minor Version = 2. 4
    544 Trans Id = 0
    545 Num Raster = 4
    546 Raster List
    547    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    548    |   |          |          |          |                      |      |Cell Detect List                                                                                   |
    549    |   |          |          |          |                      |      |       |MIB                                                                             |          |
    550    |   |          |          |          |                      |Num   |       |      |     |Half  |           |          |PDCCH |DMRS    |SSB       |Subcarrier|          |
    551    |   |          |          |          |                      |Cell  |Phy    |      |SSB  |Frame |Intra Freq |Cell      |Config|TypeA   |SubCarrier|Spacing   |          |
    552    |#  |Band      |ARFCN     |SCS       |Status                |Detect|Cell Id|SFN   |Index|Number|Reselection|Barred    |Sib1  |Position|Offset    |Common    |RSRP      |
    553    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    554    |  0|    BAND28|    152430| SSB_15KHZ|             E_FAILURE|     0|       |      |     |      |           |          |      |        |          |          |          |
    555    |  1|    BAND28|    152450| SSB_15KHZ|             E_FAILURE|     0|       |      |     |      |           |          |      |        |          |          |          |
    556    |  2|    BAND28|    152650| SSB_15KHZ|             E_SUCCESS|     1|      1|   981|    0|     0|          1|NOT_BARRED|    32|    POS2|         6|     SCS15|    -78.73|
    557    |  3|    BAND28|    152670| SSB_15KHZ|             E_FAILURE|     0|       |      |     |      |           |          |      |        |          |          |          |

which corresponds to

      pdcch-ConfigSIB1 
      {
        controlResourceSetZero 2,
        searchSpaceZero 0
      },

Another mismatch between the logs you sent is the cellBarred, which appears to be barred in the interpreted PDU and notBarred in the table.

I don't know how to read your logs, so could you maybe explain the reason for these mismatches?

Once I know which is the correct MIB that is decoded from your UE, we can move on and investigate the reason why the SIB1 doesn't get detected/decoded.

In addition to this, could you please provide the following information?

F1AP pcaps. You can enable with these commands in the gnb config file.
```
pcap:  
f1ap_enable: true
f1ap_filename: file_name
```
srsran commit you are using for your test.
Can you clarify whether the UE fails to decode the PDCCH for SIB1 or if, instead, it decodes the PDCCH, but it fails to decode the related PDSCH? I can't see that from the logs you provided. Also, could send us any relevant logs or any info that can help us infer that?
Did you try different bands other than n28? Did it work in that case?
Did you try different UEs with the same band and parameters you listed? Did it work?
If you DID NOT try other UEs, any chance you could do that?

FredNys commented 6 months ago

I’ll look into the details when I am back from travelling but the simplest test is to use a Quectel connected to a B210, same config using n3 band vs n28 band. With n3 band, the Quectel module connects without problems, with n28 no connection.

herlesupreeth commented 6 months ago

simplest test is to use a Quectel connected to a B210, same config using n3 band vs n28 band. With n3 band, the Quectel module connects without problems, with n28 no connection.

I dont think its a good test since band 28 may not be supported by that modem. One can only know whether a modem supports a particular band or not by looking at the UE's ueCapabilityInformation exchanged between UE and the network.

When you are back from traveling, please post a mac pcap when you attempt to connect that modem to band 3. Then, we can take a look whether the UE supports band 28 or not

FredNys commented 6 months ago

I checked UE Capabilities reported by UE and it supports band 28. I just upgraded to the latest build on the main branch and it seems that now it is working for B210. I need to do further testing then switch back to Comba radio.

FredNys commented 6 months ago

After retesting with latest commit, no issues anymore. Not sure if it is related to commit or recabling of setup.

carlo-gal commented 6 months ago

Hi @FredNys,

Thanks for reporting this. Just one last question. Can you confirm that you were able to attach the Quectel to the Comba 7.2 Cat A radio on n28?

FredNys commented 6 months ago

No attach yet, but SIB1 decoded, RACH triggered, now I need to work on UL IOT.

On 28 May 2024, at 15:37, carlo-gal @.***> wrote:

Hi @FredNys https://github.com/FredNys,

Thanks for reporting this. Just one last question. Can you confirm that you were able to attach the Quectel to the Comba 7.2 Cat A radio on n28?

— Reply to this email directly, view it on GitHub https://github.com/srsran/srsRAN_Project/issues/621#issuecomment-2135240477, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVCZUVB2ZN6PWHBGCHEVDADZESCBNAVCNFSM6AAAAABH32LTYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVGI2DANBXG4. You are receiving this because you were mentioned.

FredNys commented 6 months ago

Why are you generating PRACH request with startSym=1? I am getting this mismatch (I know there is also a SFN mismatch):

2024-05-29T09:31:42.498021 [OFH     ] [I] Dropped received Open Fronthaul User-Plane PRACH packet as no data was expected for slot '112.7', **symbol '0'** and eAxC '4'
2024-05-29T09:31:42.515153 [OFH     ] [D] Registering PRACH context entry for slot '115.7' and sector#0
2024-05-29T09:31:42.515153 [OFH     ] [W] Missed incoming User-Plane PRACH messages for slot '111.7' and sector#0
2024-05-29T09:31:42.515154 [OFH     ] [D] Packing a type 3 PRACH Control-Plane message for slot '115.7' and eAxC '4'
2024-05-29T09:31:42.515156 [OFH     ] [D] Generated a PRACH request for slot '115.7': numSymbols=0, **startSym=1**, start_re=0, scs=15kHz, prach_scs=1.25kHz, nof_rb=72, timeOffset=3168, freqOffset=-15264

carlo-gal commented 6 months ago

Could you send us the GNB configuration you used? Also, could you provide the following?

MAC log, best if debug, if not, info will do
PHY in info.
OFH, as you have shown above

sauka commented 6 months ago

Hi @FredNys ,

For the PRACH C-Plane in OFH we rely on timeOffset parameter while setting cpLength to 0. In this case timeOffset points to the start of PRACH preamble and startSymbolId is defined as follows:

startSymbolId is the start of the latest symbol timing that starts right at or before the reception of the earliest IQ sample in time domain (after PRACH cyclic prefix) that is specific to the earliest PRACH repetition referenced by the message

Here is an example from O-RAN.WG4.CUS.0-R003 for Format 0 you are using in your config:

wei-lou commented 5 months ago

Hi @FredNys and all, any further update on this issue? I encounter very similar issue with n71 oRU. UE decoded MIB/SIB1 and registration performed but failed at MGS2 due timer expiration. RU never sent anything to DU consequently never received anything from DU to response to the RACH MSG1.

srsran / srsRAN_Project