How many BWP defined from gNB to UE?

Small correction here as well.

Let’s have example

  • CORESET duration 3
  • Searchspace duration is mostly set to 1 unless channel BW is very small.
  • And monitoring symbol set as 11000000000000
    So first searchspace is for first symbol, and second search space is for 2nd and 3rd symbol.

And with CORESET duration = 3 we can set 10010000000000 kind of configuration but only in case of URLLC.

Here is actual configuration of one of larget SA operator.

Where CORESET duration is 2.

And there are 2 PDCCH occasion within CORESET.

1st bit 1st symbol, and 2nd bit 2nd symbol.

How many RBs are they using for CORESET?

Yes looks reasonable.

Even I tried below.

Tried to set 11000000000000 but showing invalid config with search space duration 4, monitoring offset to 2,control resource duration set to 3, monitoring slot periodicity 10, SCS 30 kHz.

Is there any specific rule for monitoring symbols in slot?

48

PDCCH configuration is most complicated one.

Follow vendor guideline document.

I think there is some confusion here, please correct me if I am wrong.

The number of PDCCH to be monitored is always defined by the CORESET duration.

My interpretation for the log attached here is as follows:

If the CORESET duration is set to 2 and the parameter monitoringSymbolsWithinSlot is ‘11000000 000000’, then the UE will consider 2 search spaces in a slot.

For the 1st search space the UE will monitor symbol indices 0 and 1, whereas for the 2nd search space the UE will monitor symbol indices 1 and 2.

Here the two search spaces are partially colliding because the symbol duration is 2.

I.e. 16 CCEs total.

Adding some snippets from spec for clarity:

48 RBs for CORESET means 8 CCEs

Is it part of MIB message?

But there are 2 PDCCH symbols.

So 8*2.

Ohh yes, my bad…

1 Like

As per 2nd paragraph, we are actually using 3 symbols of CORESET the.

But CORESET duration is 2 only. No valid right?

PDCCH cannot go beyond CORESET duration.

No. It is part of ControlResourceSet IE, which can be indicated by the gNB through SIB1.

My understanding is, CORESET duration basically tells about the number of PDCCH symbols.

At a time a UE is looking only for 2 symbols corresponding to the CORESET duration and the monitoringSymbolsInSlot parameter lets the UE know as to which symbol(s) should it treat as first symbol(s) of PDCCH for a given CORESET duration.

Can you send a few more log snippets capturing the controlResourceSet IE and searchSpace IE?

Also, is it possible to collect gNB PHY / FAPI logs to see how many PDCCH symbols are being send and with what configurations?

I mean DMRS type A position IE part of MIB.

The CORESET duration of 3 symbols only permitted if the DMRS type A position IE set to 3.

I was thinking on this.

Let me check with experts to make it clear.

No unfortunately logs cannot be shared.

Hey, here CORESET duration must be 1, please check.

I have also observed same searchspace configuration with CORESET duration-1.

Here this CORESET-4 whose duration is 1 is being used in search space id:13 for type ue-specific:

Search space duration is missing. Any reason here?

It define number of slot for search space related to common or UE specific.

If it is absent than need to consider 1 slot.

This Search space defined for UE specific.

Refer spec 38.331:

Yes, in this case CORESET duration was 1.

So what I understand there are basically 3 configurations normally we see in the network:

  1. CORESET duration 1 + Monitoring symbols within Slot 10000000000000 : Only 1 symbol is used for PDCCH i.e. Symbol 0.
  2. CORESET duration 1 + Monitoring symbols within Slot 11000000000000 : Only 1 symbol is used for PDCCH but it can be either Symbol 0 or Symbol 1
  3. CORESET duration 2 + Monitoring symbols within Slot 10000000000000 : 2 Symbols are used for PDCCH i.e. Symbol 0 and Symbol 1.

Please correct me if I am wrong…