To make NR work, it should be guaranteed that both UE and NW support NR capability. That's is, NW should know whether the UE support NR capability and UE should know whether the NW support NR capability.

There is a well known mechanism for NW to figure out whether the UE is capable of NR or not. It is through UE capability enquiry and information mechanism.

Then, How can UE figure out whether the NW support NR or not, especially for NSA?

UE can figure it out by checking a specific SIB2 (LTE SIB2) IE called upperLayerIndication. I know... it doesn't sound clear what exactly it mean. Practically it mean that the NW support ENDC capability if LTE SIB2 set upperLayerIndication-r15 to true. It implies that there is a NR cell colocated to the LTE Cell. The IE : upperLayerIndication would indicate some other things (e.g, other than the existence of colocated NR cell) in future release, but at least in ENDC environment this IE indicates the existance of colocated NR Cell.

Following is an example of SIB2 indicating 5G (NSA) supportability.

  message c1: systemInformation: {
    criticalExtensions systemInformation-r8: {
      sib-TypeAndInfo {
        sib2: {
          .....
          plmn-InfoList-r15 {
            {
              upperLayerIndication-r15 true
            }
          }
        },

For further details, refer to R2-1801529.

• Where does the indication live ?
• What does the specification actually say ?
• Why does SIB26a exist ?
• When is it forwarded and when is it withdrawn ?
• RRC Parameters
• Reference

Where does the indication live ?

One thing is worth settling before the field itself. Every system information block on this page is an LTE one, defined in 36.331 rather than 38.331. That is not an oversight of the topic. EN-DC is anchored on LTE, so it is the LTE cell that has to tell the UE that 5G is available. NR RRC never carries this indication at all.

The log above shows the field two levels deeper than most people expect. It is not a plain member of SIB2. It sits inside plmn-InfoList-r15, which arrived as a Release 15 extension group, and that nesting carries a meaning worth reading off before anything else.

The indication is per PLMN, not per cell. A cell that broadcasts several PLMN identities can offer EN-DC on some of them and not on others, and one entry of plmn-InfoList-r15 exists for each. The UE reads the entry for the PLMN it has selected and ignores the rest.

The list carries no PLMN identities of its own. That is the part most often missed. Entries are matched by position against the PLMN list in SIB1. The first entry belongs to the first PLMN in SIB1, the second to the second, and so on. A list that is out of step with SIB1 therefore points every UE at the wrong operator without any field looking wrong.

The list is short, because maxPLMN-r11 is 6. A cell can describe at most six PLMNs this way.

• The field is per PLMN : one entry of plmn-InfoList-r15 exists for each PLMN, and the UE reads only the entry for the PLMN it selected.
• Entries are positional : the list holds no identities, so it is matched against the SIB1 PLMN list by order alone.
• PLMN-Info-r15 holds one optional field : upperLayerIndication-r15 is the whole of it, and its absence is as meaningful as its presence.
• These are LTE SIBs : SIB2 and SIB26a are defined in 36.331, and searching 38.331 for either of them returns nothing.

What does the specification actually say ?

The field name is doing very little work, and the specification is honest about that. The field description in 36.331 is one sentence long, and it says only that this is an indication to be provided to upper layers. Nothing about NR, nothing about EN-DC, and nothing about a colocated cell.

The meaning is written down somewhere else entirely. It appears as a NOTE in the clause on receiving SIB2. The NOTE reads that upperLayerIndication is an indication to upper layers that the UE has entered a coverage area that offers 5G capabilities.

That explains why the name is vague. RRC does not act on this field at all. It forwards it, and what happens next is a decision taken above RRC. The 5G indicator on a handset display is the visible result, and it is produced by the upper layers rather than by the modem.

The consequence is worth stating plainly. A cell setting this field is not promising that a session will use NR, only that the area offers 5G capability. Coverage, UE capability and configuration all still have to agree afterwards.

• RRC forwards it and does nothing else : the field description says only that it is an indication to be provided to upper layers.
• The meaning lives in a NOTE : the UE has entered a coverage area that offers 5G capabilities, which is broader than the presence of one NR cell.
• The 5G indicator is an upper layer decision : what a handset displays follows from this field, and the specification never mentions a display.

Why does SIB26a exist ?

The Release 15 field has one obvious weakness. It is a single flag, so a cell either claims 5G capability for a PLMN or it does not. A UE that supports none of the NR bands deployed there is told the same thing as a UE that supports all of them. Release 16 addressed that under the upperLayerIndication enhancements work item.

The answer was a new LTE system information block. SystemInformationBlockType26a carries two things. The first is bandListENDC-r16, a list of the NR bands that can be configured as an SCG with this serving cell. The second is plmn-InfoList-r16, which gives each PLMN a bitmap selecting from that list. The constant maxBandsENDC-r16 is 10, so the shared band list holds at most ten entries and each per PLMN bitmap is ten bits wide.

That is the whole block. 36.331 describes it in one sentence, as containing an NR bands list which can be used for EN-DC operation with the serving cell. Its only other member is a late non critical extension. A system information block that exists to qualify one flag in another system information block is unusual.

Being a separate block rather than a field has a cost. SIB26a has to be scheduled and acquired like any other, so an operator that does not broadcast it leaves every UE on the Release 15 behaviour. Both paths in Figure 1 therefore remain in use in real networks, and a Release 16 UE cannot assume the newer rules apply.

Two rules then change the behaviour, and both are easy to miss. The first is that SIB26a takes over. When it is present, the UE does not use the SIB2 field at all. The second is that forwarding became conditional on the UE. The indication is forwarded only when the band list includes something the UE can use for EN-DC on this serving cell. Otherwise the UE is told the field is absent.

One shortcut is built in for the simple deployment. If plmn-InfoList-r16 has size zero, every band in bandListENDC applies to every PLMN listed in SIB1. An operator with a uniform deployment therefore does not have to write a bitmap per PLMN.

Figure 1 puts the whole decision in one place.

Figure 1. The two eras side by side. Release 15 asks only whether the field is present for the selected PLMN, while Release 16 asks whether this particular UE could use the bands on offer.

• The first test is which era applies. SIB26a present means the Release 16 rules, and its absence means the Release 15 rules.
• The two paths do not merge. When SIB26a is present the SIB2 field is not consulted, so the same cell can be read two ways by two UEs of different releases.
• Both of the left hand exits end in the same place, and that place is not a rejection. The UE tells its upper layers that the field is absent, which is a different statement from the field being false.

• Release 16 made the indication UE specific : two UEs on the same cell and the same PLMN can now get different answers. The band list is checked against what each UE supports.
• SIB26a overrides SIB2 : when SIB26a is present the SIB2 field is not used, so reading only SIB2 in a Release 16 network gives the wrong answer.
• The band list is shared and the bitmap is per PLMN : bandListENDC-r16 holds up to ten bands, and each PLMN selects from it with a ten bit mask.
• An empty plmn-InfoList-r16 means all bands for all PLMNs : size zero is a deliberate shortcut, not a missing configuration.
• SIB26a exists only for this : both of its fields serve upperLayerIndication forwarding, and 36.331 describes the whole block in one sentence.

When is it forwarded and when is it withdrawn ?

The indication is not a one time event at power on. 36.331 names three separate moments where the UE forwards it or withdraws it, and a log that only covers the first will look as though the indication never changes.

The first is receiving SIB2, on cell selection and reselection. The second is receiving SIB26a, which supersedes the first. The third is different in kind. Whenever a procedure configures the UE for EN-DC, the UE forwards upperLayerIndication as if it had received the field from SIB2. Whenever a procedure leaves the UE without EN-DC, it indicates the absence of the field instead.

That third case is why an indicator can appear and disappear without the UE moving. Releasing the secondary cell group withdraws the indication, and configuring it again restores it, all on the same LTE cell with the same system information.

• Three moments, not one : SIB2 reception, SIB26a reception, and any procedure that configures or releases EN-DC.
• Configuration overrides broadcast : a UE actually configured for EN-DC forwards the indication as if SIB2 had carried it, whatever SIB2 said.
• Withdrawal is explicit : losing EN-DC makes the UE indicate the absence of the field, so upper layers are told to stop rather than left to time out.

RRC Parameters

Three listings cover the whole mechanism. The first shows where the Release 15 field attaches to SIB2, the second is the field itself, and the third is everything Release 16 added. All of them are small, which is a fair reflection of how little is actually signalled here.

Following is based on 36.331 v19.3.0 (Release 19)

SystemInformationBlockType2 ::=     SEQUENCE {
    ...                                                                     -- the original members and the earlier extension groups are not related to this note
    [[
    plmn-InfoList-r15                   PLMN-InfoList-r15                   OPTIONAL    -- Need OP
    ]],
    ...                                                                     -- later extension groups continue
}

The extension group shows that this is Release 15 work added to a Release 8 message. The field could not be added to SIB2 directly, so it arrived inside a list that did not exist before.

Following is based on 36.331 v19.3.0 (Release 19)

PLMN-InfoList-r15 ::=               SEQUENCE (SIZE (1..maxPLMN-r11)) OF PLMN-Info-r15

PLMN-Info-r15 ::=                   SEQUENCE {
    upperLayerIndication-r15            ENUMERATED {true}                       OPTIONAL    -- Need OR
}

maxPLMN-r11                             INTEGER ::= 6       -- Maximum number of PLMNs

Note the type. It is ENUMERATED {true} and it is optional, so the field has two states rather than three. It is either present with the value true, or it is not there. There is no way to broadcast a false, and that is why the specification talks about indicating the absence of the field rather than indicating a negative.

Following is based on 36.331 v19.3.0 (Release 19)

SystemInformationBlockType26a-r16 ::= SEQUENCE {
    plmn-InfoList-r16                   PLMN-InfoList-r16,
    bandListENDC-r16                    BandListENDC-r16,
    lateNonCriticalExtension            OCTET STRING                            OPTIONAL,
    ...
}

BandListENDC-r16 ::=                SEQUENCE (SIZE (1.. maxBandsENDC-r16)) OF FreqBandIndicatorNR-r15

PLMN-InfoList-r16 ::=               SEQUENCE (SIZE (0..maxPLMN-r11)) OF PLMN-Info-r16

PLMN-Info-r16 ::=                   SEQUENCE {
    nr-BandList-r16                     BIT STRING (SIZE(maxBandsENDC-r16))     OPTIONAL    -- Need OR
}

maxBandsENDC-r16                        INTEGER ::= 10      -- Maximum number of NR bands from across all the PLMNs

The field nr-BandList-r16 is a BIT STRING rather than a list of band numbers, and that is the detail that matters. It is a mask into bandListENDC-r16, so the bands are written once for the cell and each PLMN selects from them. Reading the bitmap without the band list beside it gives nothing.

The block has three members and only two of them carry anything.

36.331 gives the bitmap encoding exactly, and it is worth having in front of you when decoding one. Bit N is set to 1 if the current serving cell supports EN-DC operation with the N-th NR band in bandListENDC. Bits with no corresponding band in bandListENDC are set to 0. Bit 1 of the bitmap is the leading bit of the bit string.

The per PLMN matching carries a trap that the Release 15 list does not. The order is taken across a combined list, not across one field. 36.331 builds it by concatenating plmn-IdentityList-r14 onto the original plmn-IdentityList, both from SIB1, and plmn-InfoList-r16 has to hold the same number of entries in that same order. A cell that carries both lists and counts only the original one lines every entry up against the wrong operator.

Scheduling is ordinary. The value sibType26a-v1610 belongs to the SIB-Type enumeration, and SIB-MappingInfo is a list of SIB-Type, so SIB26a is mapped into an SI message exactly like any other system information block. Nothing about it is broadcast on a special path.

• Bit 1 is the leading bit : the bitmap is read left to right against bandListENDC, and bits with no band behind them are set to 0.
• The PLMN order comes from two SIB1 fields, not one : plmn-IdentityList-r14 is concatenated onto plmn-IdentityList, and plmn-InfoList-r16 must match that combined order entry for entry.
• SIB26a is scheduled like any other SIB : sibType26a-v1610 sits in the SIB-Type enumeration that SIB-MappingInfo uses, so it costs an ordinary SI message slot.

• The field cannot say no : ENUMERATED {true} with OPTIONAL gives presence or absence, and never a broadcast false.
• Two lists have to be read together : nr-BandList-r16 is a mask, and bandListENDC-r16 is what it indexes.
• Both lists are positional against SIB1 : plmn-InfoList-r15 and plmn-InfoList-r16 are matched to PLMNs by order, so an off by one error is silent.

Reference

• 36.331 v19.3.0 : E-UTRA - Radio Resource Control (RRC) protocol specification. Clauses 5.2.2.7 and 5.2.2.33, and the SIB2 and SIB26a information elements.