As we have experienced in previous technology, at the initial stage of technology band/frequency allocation is done in such a way that there is no overlapping frequency between any two different bands. But as time goes on and demand for new band increases, we start seeing some inevitable situation where some of bands overlapping.

MFBI lets one cell say that its carrier belongs to more than one band at the same time. The cell keeps its own band in freqBandIndicator and lists the overlapping bands in multiBandInfoList. A UE that supports any of those bands can then treat the cell as its own. This page covers which bands overlap, how the network signals the extra bands, how the UE reports that it understands them, and what that means in practice.

Followings are the topics to be covered in this page.

• List of Overlapping Bands
• How Network inform UE of the Multiband Supportability
• How UE informs NW of its capability on MFBI ?
• What is the meaning of MFBI to a UE and Network ?
  • Case 1
  • Case 2
• Reference

List of Overlapping Bands

As a result of this general trend, now we have following overlapping cases and it is highly likely that this table would get extended as time goes on.

< 36.307 V11.9.0 Table A-1: Overlapping bands (multi-band environments) for each E-UTRA band >

36.307 V11.9.0 Table A-1. Each row lists the bands whose frequency range overlaps the band in the first column. The table covers bands up to 41, as they stood in Release 11.

The table above is from Release 11, and the band list has grown a lot since then. The table below compares the current band edges in 36.101 v20.0.0 Table 5.5-1. It lists every pair of bands whose uplink and downlink ranges both overlap and that use the same duplex mode. Bands 6 and 23 are left out, because 36.101 marks them as not applicable.

The Release 11 rows are all still there, and later bands have joined most groups. Band 66 extends band 4 and band 10 up to 2200 MHz, band 65 extends band 1, and band 85 overlaps bands 12 and 17. A frequency overlap is only the starting point, though. The operator still has to decide which bands to list for each cell, and 36.307 Annex A remains the reference for the combinations the specification recognizes.

• 36.307 Table A-1 is the Release 11 view : bands up to 41.
• 36.101 v20.0.0 adds many overlaps : for example 4, 10 and 66, or 12, 17 and 85.
• An overlap needs both UL and DL : and the same duplex mode.

How Network inform UE of the Multiband Supportability

Another trend that we have seen in previous technology (e.g, WCDMA) shows that we tend to introduce new Information Elements in various SIBs (in case of WCDMA, we added BandIndicator in SIB5). In LTE, we had freqBandIndicator in SIB1 from day 1, with MFBI we need to have additional information elements. This new/additional information is carried by a couple of different SIBs as follows. In LTE, the additional IE is added to SIB1,2,5 and in WCDMA it is added to SIB19. Here goes one example of SIB1,2,5 showing the new IE (I will add SIB 19 part later)

The captures below show one cell that uses band 4 as its own band and band 10 as its extra band. Each SIB carries the new field in a late non-critical extension, v8h0, so a Release 8 UE simply skips it.

SIB1 with freqBandIndicator = 4. The SystemInformationBlockType1-v8h0-IEs extension carries multiBandInfoList with one entry, band 10.

SIB2. The multiBandInfoList here holds additionalSpectrumEmission values, one for each band in the SIB1 list. The highlighted value is 10.

SIB5. InterFreqCarrierFreqInfo-v8h0 gives the extra band 10 for an inter-frequency carrier, so the UE can use it for cell reselection.

The same field name means two different things. In SIB1 and SIB5 the list holds band numbers. In SIB2 it holds additionalSpectrumEmission values, because the emission requirement depends on the band the UE finally selects. The SIB definitions below are the current ones.

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

SystemInformationBlockType1-v8h0-IEs ::=    SEQUENCE {
    multiBandInfoList                   MultiBandInfoList       OPTIONAL,   -- Need OR
    nonCriticalExtension                SystemInformationBlockType1-v9e0-IEs    OPTIONAL
}

SystemInformationBlockType1-v9e0-IEs ::= SEQUENCE {
    freqBandIndicator-v9e0              FreqBandIndicator-v9e0      OPTIONAL,   -- Cond FBI-max
    multiBandInfoList-v9e0              MultiBandInfoList-v9e0      OPTIONAL,   -- Cond mFBI-max
    nonCriticalExtension                SystemInformationBlockType1-v10j0-IEs   OPTIONAL
}

SystemInformationBlockType1-v1250-IEs ::=   SEQUENCE {
    cellAccessRelatedInfo-v1250                 SEQUENCE {
        category0Allowed-r12                        ENUMERATED {true}       OPTIONAL    -- Need OP
    },
    cellSelectionInfo-v1250                 CellSelectionInfo-v1250     OPTIONAL,   -- Cond RSRQ2
    freqBandIndicatorPriority-r12           ENUMERATED {true}           OPTIONAL,   -- Cond mFBI
    nonCriticalExtension            SystemInformationBlockType1-v1310-IEs   OPTIONAL
}

MultiBandInfoList ::=   SEQUENCE (SIZE (1..maxMultiBands)) OF FreqBandIndicator

MultiBandInfoList-v9e0 ::=  SEQUENCE (SIZE (1..maxMultiBands)) OF MultiBandInfo-v9e0

MultiBandInfo-v9e0 ::=      SEQUENCE {
    freqBandIndicator-v9e0              FreqBandIndicator-v9e0      OPTIONAL    -- Need OP
}

FreqBandIndicator ::=                   INTEGER (1..maxFBI)

FreqBandIndicator-v9e0 ::=              INTEGER (maxFBI-Plus1..maxFBI2)

FreqBandIndicator only runs from 1 to 64, which is maxFBI. For a band above 64, such as band 66, E-UTRAN sets the original field to 64 and puts the real band in freqBandIndicator-v9e0 or multiBandInfoList-v9e0, whose range runs from 65 to 256. The -v9e0 list has the same number of entries, in the same order, as the list without suffix. A UE that does not understand the extension reads 64 as a band it does not support.

The UE picks the band in a fixed order. If it supports the band in freqBandIndicator, it uses that band. Otherwise it uses the first band in multiBandInfoList that it supports. Release 12 added freqBandIndicatorPriority-r12: when it is present and the UE supports it, the UE tries the multiBandInfoList bands first, in the listed order, and uses freqBandIndicator only as a last resort. The list holds at most 8 bands, which is maxMultiBands.

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

SystemInformationBlockType2-v8h0-IEs ::=    SEQUENCE {
    multiBandInfoList               SEQUENCE (SIZE (1..maxMultiBands)) OF AdditionalSpectrumEmission    OPTIONAL,   -- Need OR
    nonCriticalExtension            SystemInformationBlockType2-v9e0-IEs    OPTIONAL
}

SystemInformationBlockType5-v8h0-IEs ::=    SEQUENCE {
    interFreqCarrierFreqList-v8h0 SEQUENCE (SIZE (1..maxFreq)) OF InterFreqCarrierFreqInfo-v8h0             OPTIONAL,   -- Need OP
    nonCriticalExtension            SystemInformationBlockType5-v9e0-IEs                            OPTIONAL
}

InterFreqCarrierFreqInfo-v8h0 ::=       SEQUENCE {
    multiBandInfoList                   MultiBandInfoList               OPTIONAL    -- Need OR
}

• SIB1 and SIB5 carry band numbers : SIB2 carries additionalSpectrumEmission per band.
• Bands above 64 use the -v9e0 fields : the original field is set to maxFBI = 64.
• freqBandIndicator is used first : unless freqBandIndicatorPriority-r12 reverses the order.

How UE informs NW of its capability on MFBI ?

Since MFBI should be supported on both UE and NW, both NW and UE should know about the capability of their counter part about this capabilililty. As described above, NW can inform UE of MFBI capability (requirement) on NW side.. then how UE can network knows of its MFBI capability ? As usuall, UE informs NW of this via UE capability information message. More specifically, by the following FGI bit in UE Capability Information message.

<36.331- Table B.1-1: Definitions of feature group indicators >

36.331 Table B.1-1, FGI bit 31. The UE comprehends multiBandInfoList, ignores the band fields in RRC_CONNECTED, and understands the EARFCNs of all bands that overlap its own. The definition is unchanged in v19.3.0.

I put a couple of examples of this setting in UE Capability Information message decoded by Wireshark (3GPP decoder)

Captured UE Capability Information, decoded by Wireshark. Values are from the capture, not the specification.

featureGroupIndicators: 7fcffeb2
.... ..1. = Indicator 31: Mechanisms defined for cells broadcasting multi band information - Supported

Captured UE Capability Information, decoded by Wireshark. Values are from the capture, not the specification.

featureGroupIndicators-r9: 7fcffeb2
.... .0.. = Indicator 30: Handover between FDD and TDD - Not supported

The two captures show the same value, 7fcffeb2. FGI bits are numbered from 1 at the leftmost bit, so bit 31 is the second bit from the right. The last hex digit 2 is 0010 in binary, which sets bit 31 and clears bits 30 and 32. That matches the decoder: multi-band cells supported, and FDD-TDD handover not supported.

The last part of the definition matters most in practice. A UE that sets bit 31 must understand the EARFCN of every band that overlaps a band it supports, in the earliest 36.101 version that includes all its bands. So a band 4 UE must accept a band 10 EARFCN in a measurement or handover command, even though it does not list band 10. Later releases added related capabilities as well, for example multiBandInfoReport-r13 for reporting multi-band information in a CGI report.

• FGI bit 31 : the UE supports multi-band cells.
• 7fcffeb2 sets bit 31 : the last hex digit 2 is 0010.
• EARFCNs of overlapping bands : the UE must understand them too.

What is the meaning of MFBI to a UE and Network ?

How a Network inform UEs of the multiple band support is pretty straightforward as explained above. Now you may have more practical question. What is the motivation of this trick ? Why we need this trick ? What is the meaning of MFBI to a UE and Network ?

If you are interested in more business side motivation, read the reference [1].

If you want to figure out the practical means out of technical perspective, let's read a couple of lines in the specification.

36.331 - 5.2.2.7 describes as follows.

- if the frequency band indicated in the freqBandIndicator is part of the frequency bands supported by the UE and it is not a downlink only band; or

- if the UE supports multiBandInfoList, and if one or more of the frequency bands indicated in the multiBandInfoList are part of the frequency bands supported by the UE and they are not downlink only bands:

• forward the cellIdentity and trackingAreaCode to upper layers; => This implies 'Proceed to initiate Cell Selection Process'.

The quoted text is the Release 11 version of clause 5.2.2.7. In 36.331 v19.3.0 the same condition also accepts freqBandIndicatorAerial and multiBandInfoListAerial for aerial UEs. The clause also has a branch in front of it: in RRC_CONNECTED, a UE that sets FGI bit 31 disregards freqBandIndicator and multiBandInfoList and simply forwards the cell identity and tracking area code. So the band check only gates cell selection and reselection in idle mode.

Rewriting this in a very simple way, we can say 'a UE can select only those cells, the frequencyband of which is listed in freqBandIndicator or multiBandInfoList even though there are other cells within the same frequency range'.

OK.. I think I understand this, but still not so clear to me what is the implication of this in business point of view (or subscriber's point of view.  Take a look at following imaginary cases and hopefully it would give you some practical insight.

Case 1

The two cases below use bands 4 and 10, which overlap in both uplink and downlink. The only thing that changes between them is whether SIB1 carries multiBandInfoList, so the effect of that one field is easy to see.

Let's suppose we have two operators and two UEs configured as follows.

Operator A :  freqBandIndicator = 4,  multiBandInfoList = Omit in SIB1

Operator B :  freqBandIndicator = 10,  multiBandInfoList = Omit in SIB1

UE A : Support Band 4 only

UE B : Support Band 10 only

In this case, even though the two cells are in the same frequency (at least overlapping frequency) and in terms of hardware implementation both UE A and B are capable of selecting to (camping on to) operator A and operator B. However, due to SIB1 configuration, UE A can camp on only to Operator A and UE B can camp on only to Operator B.

Now Operator A aquired Operator B (or made a business agreement of sharing their network and allowing the subscribers to any operator. However in this case there is no way to allow UE B to select to operator A or to allow UE A to select to operator B according to the procedure defined in 3GPP spec mentioned above.

This issue can be solved in < Case 2 >

Case 2

Each operator now lists the other band in multiBandInfoList, and the UEs stay the same. Each UE still has to support multiBandInfoList, which it reports with FGI bit 31, for the extra entry to count.

Let's suppose we have two operators and two UEs configured as follows.

Operator A :  freqBandIndicator = 4,  multiBandInfoList.freqBandIndicator = 10  in SIB1

Operator B :  freqBandIndicator = 10,  multiBandInfoList.freqBandIndicator = 4  in SIB1

UE A : Support Band 4 only

UE B : Support Band 10 only

In this case, UE A can camp on either to Operator A or Operator B, and UE B can camp on either to Operator A or Operator B unless it is blocked by other higher layer process.

So in Case 2 either UE can camp on either cell. UE A reads band 10 in freqBandIndicator of the Operator B cell, does not support it, and finds band 4 in multiBandInfoList. UE B does the same in the other direction. Both operators therefore serve both groups of subscribers after the acquisition, without changing the carrier or the UEs.

• Without multiBandInfoList : each UE is locked to the cells of its own band.
• With multiBandInfoList : each UE selects any cell that lists a band it supports.
• In RRC_CONNECTED : a UE with FGI bit 31 ignores the band fields.

Reference

[1] AT&T revamp of LTE network will help customers switch to small carriers

[2] 3GPP TS 36.331 v19.3.0 - clause 5.2.2.7, SystemInformationBlockType1, FreqBandIndicator, MultiBandInfoList and Table B.1-1

[3] 3GPP TS 36.101 v20.0.0 - Table 5.5-1, E-UTRA operating bands

[4] 3GPP TS 36.307 - Annex A, Overlapping bands