In LTE, MIB, SIB1, SIB2 is mandated to be transmitted for any cells. Since many of the SIB are transmitted, it should be transmitted in such a way that the location (subframe) where a SIB is transmitted should not be the same subframe where another SIB is transmitted.

• Fixed Schedules : MIB and SIB1
• Scheduling the Other SIBs
• What the Current Release Says
• Examples
• Reference

Fixed Schedules : MIB and SIB1

Two of the broadcast messages keep a schedule the UE can work out before it has read anything at all. The MIB and SIB1 sit on fixed timing, and their positions follow from the frame number alone. Everything further down this page depends on those two arriving first.

Overall SIB Scheduling concept is as follows. As you see

i) MIB is transmitted at a fixed cycles (every 4 frames starting from SFN 0)

ii) SIB1 is also transmitted at the fixed cycles (every 8 frames starting from SFN 0).

iii) All other SIB are being transmitted at the cycles specified by SIB scheduling information elements in SIB1

• Four columns stand side by side, one per message, with the frame number running down the left from SFN 0 to SFN 19. The headings read MIB (fixed schedule), SIB1 (fixed schedule), SIB2 (determined by SIB1) and SIBN (Determined by SIB1).
• The MIB column carries a block at every frame. The darker blocks labelled original sit at SFN 0, 4, 8, 12 and 16, and the brace marked Same as original covers the three frames after each of them.
• The SIB1 column carries blocks on even frames only. Its darker original blocks sit at SFN 0, 8 and 16, and its brace reads Same as original but different RV.
• The two right hand columns are drawn as bare timelines with no blocks on them at all. That emptiness is the point of the picture. Their headings say the timing is determined by SIB1, so nothing can be placed until SIB1 has been read.

You may notice that LTE SIB1 is very similar to WCDMA MIB.

Especially at initial test case development, you have to be very careful about item iii). If you set this value incorrectly, all the other SIBs will not be decoded by UE. It means, even though all the SIB is being transmitted UE would be trying to decode them at the wrong timing. And as a result, UE would not recognize the cell and show "No Service" message.

According to 36.331 section 5.2.1.2, the MIB scheduling is as follows :

The MIB uses a fixed schedule with a periodicity of 40 ms and repetitions made within 40 ms. The first transmission of the MIB is scheduled in subframe #0 of radio frames for which the SFN mod 4 = 0, and repetitions are scheduled in subframe #0 of all other radio frames.

According to 36.331 section 6.2.2 Message definitions - MasterInformationBlock field descriptions, the System Frame Number in MIB is specified as follows :

Defines the 8 most significant bits of the SFN. As indicated in TS 36.211 [21, 6.6.1], the 2 least significant bits of the SFN are acquired implicitly in the P-BCH decoding, i.e. timing of 40ms P-BCH TTI indicates 2 least significant bits(within 40ms P-BCH TTI, the first radio frame: 00, the second radio frame: 01, the third radio frame: 10, the last radio frame: 11). One value applies for all serving cells (the associated functionality is common i.e. not performed independently for each cell).

According to 36.331 section 5.2.1.2, the SIB1 scheduling is as follows :

The SystemInformationBlockType1 uses a fixed schedule with a periodicity of 80 ms and repetitions made within 80 ms.The first transmission of SystemInformationBlockType1 is scheduled in subframe #5 of radio frames for which the SFNmod 8 = 0, and repetitions are scheduled in subframe #5 of all other radio frames for which SFN mod 2 = 0.

This means that even though SIB1 periodicity is 80 ms, different copies (Redudancy version : RV) of the SIB1 is transmitted every 20ms. Meaning that at L3 you will see the SIB1 every 80 ms, but at PHY layer you will see it every 20ms. For the detailed RV assignment for each transmission, refer to 36.321 section 5.3.1 (the last part of the section).

Following log (from Amarisoft) clearly shows the SIB1 transmission as described above. Check SFN.subframe timing and RV index.

• The columns read ENB, UE ID, Cell, SFN, RNTI, Info and Message. The first two rows are an S1AP setup response and an RRC row on BCCH carrying SIB1.
• Red rings mark four PDSCH rows. Their SFN values read 0.5, 2.5, 4.5 and 6.5, so each one sits in subframe 5 of an even frame and they are 20 ms apart.
• The same rings mark the rv_idx field on those four rows. It reads 0, then 2, then 3, then 1, so no two of the four repeat a redundancy version.
• The rows the rings leave out carry a different transport block size, tb_len=32 against tb_len=18 on the ringed rows, so those rows are not the same message.

36.321 clause 5.3.1 sets k equal to (SFN/2) modulo 4 for the dedicated broadcast HARQ process. The four SIB1 transmissions inside one 80 ms period therefore land on four different values of k. The log above is that rule, in four rows.

Scheduling the Other SIBs

The transmission cycles for other SIBs are determined by schedulingInfoList in SIB1 as shown in the following example (This example is the case where SIB2 and 3 are being transmitted).

< schedulingInfoList inside a decoded SIB1 > capture. Field values come from a live capture, not from the specification.

        +-schedulingInfoList ::= SEQUENCE OF SIZE(1..maxSI-Message[32]) [2]
        | +-SchedulingInfo ::= SEQUENCE
        | | +-si-Periodicity ::= ENUMERATED [rf16]
        | | +-sib-MappingInfo ::= SEQUENCE OF SIZE(0..maxSIB-1[31]) [0]
        | +-SchedulingInfo ::= SEQUENCE
        |   +-si-Periodicity ::= ENUMERATED [rf32]
        |   +-sib-MappingInfo ::= SEQUENCE OF SIZE(0..maxSIB-1[31]) [1]
        |     +-SIB-Type ::= ENUMERATED [sibType3]
        +-tdd-Config ::= SEQUENCE OPTIONAL:Omit
        +-si-WindowLength ::= ENUMERATED [ms20]

One thing you would notice that sib-MappingInfo IE in the first node is not specified, but the first entity of schedulingInfoList should always be for SIB2 as specified in the 36.331 as follows (See 36.331 SystemInformationBlockType1 field description).

List of the SIBs mapped to this SystemInformation message.There is no mapping information of SIB2; it is always present in the first SystemInformation message listed in the schedulingInfoList list.

Understanding overall cycle in the unit of Subframe number is pretty straightforward to understand. But understanding exactly at which subframe a SIB should be transmitted is not that straightforward as you might think. It is related to 'si-WindowLength'. si-WindowLength tells that a SIB should be transmitted somewhere within the window length starting at the SFN specified by si-Periodicity. But this parameter does not specify the exact subframe number for the transmission.

The subframe for a specific SIB transmission is determined by a algorithm defined in 36.331 5.2.3 Acquisition of an SI message as follows.

When acquiring an SI message, the UE shall:

1> determine the start of the SI-window for the concerned SI message as follows:

    2> for the concerned SI message, determine the number n which corresponds to the order of entry

         in the list of SI messages configured by schedulingInfoList in SystemInformationBlockType1;

    2> determine the integer value x = (n 1)*w, where w is the si-WindowLength;

    2> the SI-window starts at the subframe #a, where a = x mod 10, in the radio frame for which SFN mod T =

FLOOR(x/10), where T is the si-Periodicity of the concerned SI message;

NOTE: E-UTRAN should configure an SI-window of 1 ms only if all SIs are scheduled before subframe #5 in

radio frames for which SFN mod 2 = 0.

 

1> receive DL-SCH using the SI-RNTI from the start of the SI-window and continue until the end of the SI-window

whose absolute length in time is given by si-WindowLength, or until the SI message was received, excluding the

following subframes:

     2> subframe #5 in radio frames for which SFN mod 2 = 0;

     2> any MBSFN subframes;

     2> any uplink subframes in TDD;

1> if the SI message was not received by the end of the SI-window, repeat reception at the next SI-window occasion

for the concerned SI message;

What the Current Release Says

The algorithm quoted above comes from an earlier release, and the arithmetic inside it still holds. What has grown is the list that n counts through. A reader comparing the quote against a current download will find more text than is reproduced here, so the part that moved is worth naming.

36.331 v19.3.0 keeps the three lines that carry the work. The integer x is still (n − 1) multiplied by w. The window still starts at subframe a = x mod 10. The frame is still the one where SFN mod T = FLOOR(x/10).

The list feeding n is the part that changed. The current clause counts n through the concatenated list of SI messages configured by schedulingInfoList, by schedulingInfoListExt when that is present, and by posSchedulingInfoList. T is now the si-Periodicity or the posSI-Periodicity of the message concerned.

A second branch also appeared that the quote predates. An SI message configured by posSchedulingInfoList with si-posOffset configured takes a different route to the window start, and the clause now nests to three levels rather than two.

Telling which branch a given cell takes needs nothing beyond its own SIB1. A decode showing schedulingInfoList alone, with no schedulingInfoListExt and no posSchedulingInfoList beside it, is a cell on the first branch. The capture in Example 2 below has exactly that shape.

None of that disturbs the worked example further down. A cell broadcasting a single SI message from schedulingInfoList alone takes the first branch, and the first branch is the arithmetic the quote already gives.

• The formula did not change and the list did : positioning system information and an extension list now share the numbering that n walks through.
• A cell with one ordinary SI message is unaffected : it takes the first branch, which is the case the quote above describes.

Examples

Two captures follow, taken with different tools on different networks. Reading them against the rules above is the quickest way to find out whether the rules were understood. The second one carries enough detail to run the SI window algorithm through by hand, and the section under it does exactly that.

Example 1 : SIB Transmitted and Captured by Amarisoft System

Following is SIB transmission shown on Resource Map Display tool of Amarisoft. SIB scheduling in this example is as follows. The decode under this paragraph is the configuration the capture was taken with. The three pictures after it show the same cell from three angles: one run of frames at a time, a longer run stitched together, and the text log.

< SIB1 decoded by the Amarisoft system > capture. Field values come from a live capture, not from the specification.

{
  message c1: systemInformationBlockType1: {
    ....
    schedulingInfoList {
      {
        si-Periodicity rf16,
        sib-MappingInfo {
          sibType3
        }
      }
    },
    si-WindowLength ms40,
    systemInfoValueTag 8
  }
}

In this tool, you can easily scroll along time domain to get overall (panoramic) patterns.

• The vertical axis runs from 0 to 24 and counts resource blocks. The horizontal axis runs through subframes 0 to 9 for each of four radio frames, numbered 16, 17, 18 and 19 underneath, with timestamps 10 ms apart.
• The legend along the bottom gives a colour to PUSCH, PDSCH, PMCH, PUCCH and PRACH. Every block drawn here is the PDSCH colour.
• Subframe 0 carries a block in all four frames. Subframe 5 carries one in frames 16 and 18 and in neither of the odd frames, which is the SIB1 rule visible as a picture.
• Subframes 1 to 4 and 6 to 9 are empty across all four frames. The block at subframe 0 of frame 17 sits high in the resource block range while the others sit at the bottom. They are therefore not all the same allocation.

Following is what I captured multiple images from the RB map and put them in sequence to give you the image of overall SIB transmission pattern.

• Four strips are stacked, and each strip is a run of the resource map screenshots joined end to end. Reading left to right along a strip and then down to the next one follows the capture forward in time.
• The blue PDSCH blocks recur at a regular spacing all the way along, with a denser cluster at the left hand end of each strip.
• The individual axis labels are too small to read at this size, so the picture is worth reading for the pattern rather than for any single frame number. The log further down gives the numbers.

From the text log, you can confirm exact SFN.Subframe timing and Original/Retransmission (in case of SIB1)

This is the same log as the one further up the page, placed here beside the resource map so the two views of one capture sit together.

Example 2 : SIB Captured by Sanjole System 

Following is a SIBs captured from a live network. Go through the capture and check if it matches your understanding. The two pictures below come from the same capture. The first is the decoded SIB1 and the second is the message list that capture produced, and between them they carry every number the algorithm above needs.

The two pictures above can be checked against each other and against the algorithm quoted earlier. The decoded SIB1 gives one SI message with si-Periodicity rf8. Its sib-MappingInfo lists sibType3, sibType5 and sibType6, and si-WindowLength reads ms10.

Run the algorithm on those numbers. It is the first and only entry, so n is 1 and x is (1 − 1) multiplied by 10, which is 0. The window therefore starts at subframe a = 0 mod 10 = 0. The frames are those where SFN mod T = FLOOR(0/10) = 0, and T is 8 because si-Periodicity reads rf8.

The prediction is that the SI message appears in subframe 0 of every frame whose number divides by eight. The message list gives it at frames 112, 120, 128 and 136, and each of those divides by eight exactly.

One column of the list is worth a second look. The Name column reads SIB2,3,5,6 on those rows, while the decoded tree lists only sibType3, sibType5 and sibType6. The missing entry is the one the section above explains. SIB2 carries no mapping information because it is always in the first SI message.

The rest of the list confirms the fixed schedules as well. MIB appears at subframe 0 of every frame, and SIB1 appears at subframe 5 of the even frames only. The RNTI column reads 65535 on every SI row, which is the SI-RNTI the quoted clause tells the UE to receive on.

• The capture matches the algorithm exactly : one SI message with rf8 and ms10 predicts subframe 0 of frames divisible by eight, and the list gives 112, 120, 128 and 136.
• The name column shows SIB2 that the mapping list does not : SIB2 rides in the first SI message without a mapping entry, which is the rule stated further up this page.

Reference

Two specifications carry the rules quoted and worked through above. The clause numbers sit beside each claim so the wording can be checked rather than taken on trust.

• 36.331 - Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification, v19.3.0. Clause 5.2.1.2 carries the fixed schedules for the MIB and for SystemInformationBlockType1 quoted above. Clause 5.2.3 is the acquisition of an SI message, and the section on the current release compares it against the quote. The SystemInformationBlockType1 field descriptions carry the rule that SIB2 needs no mapping entry, and the MasterInformationBlock field descriptions carry the two implicit SFN bits.
• 36.321 - Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification, v19.3.0. The end of clause 5.3.1 sets k equal to (SFN/2) modulo 4 for the dedicated broadcast HARQ process, which is the redundancy version pattern the Amarisoft log above shows. Clause 5.3.1 was read in full; the rest of the specification was not.