4G/LTE - Frame Numbers

 

 

 

Subframe Number, SFN and HFN

 

In any communication, one of the most important requirement would be that the transmitter and reiver operate at the same tempo, more technically speaking that the transmitter and reciever should operates in synchronized mode.

Speaking in laymen's terminology, the transmitter and reciever has it's own clock and they have to synchronize the clock before the communication starts.

What kind of clock they have in LTE ? Like our analog wrist clock, LTE clock has two arms. One arm ticks every 10 ms and the other arm ticks every 1 ms. Again as in the wrist clock, each of ticks has specific numbers and the numbers has a certain range.

In LTE, the arm ticking in 10 ms interval has numbers between 0 and 1023 and these numbers are called SFN (System Frame Number) and the other arm ticking in 1 ms interval has numbers between 0 and 9, and this number is called subframe number. When subframe number hits the max value (i.e, 9), it goes back to 0 and SFN number get increased by 1. When SFN number hits the max value (i.e 1023), it goes back to 0.

UE and eNB need to maintain the synchnronization on subframe number and SFN during the whole communication period.

Based on Subframe and SFN definition, you may notice that the longest time span for the timing synchronization without resetting to 0 is 1023 SFN. It is 1024 x 10 ms, which is 10240 ms (=10240 subframe = 10.24 sec). Most of timing related parameters (e.g, Idle mode DRX, Connected Mode DRX, BSR Report period etc) are configured within this max timiing value.

However, as LTE evolves, especially as LTE tries to cover MTC or IoT related features it turned out that this max time span is not big enough to schedule all the timing related parameters (e.g, eDRX, PSM configuration). To support this kind of new requirement, LTE has introduced another timer(clock) called HFN (Hyper Frame Number or Hyper SFN). HFN is a timer at the next level to SFN. HFN ranges between 0 and 1023 and the value increases by 1 when SFN reaches 1023 and reset to 0.

Let's put the three counters side by side first. Then we look at how the UE learns each one, and at eDRX paging, which is the feature that made the HFN necessary.

Summary of Timers

The table below puts the three counters in one place. Each row is one hand of the clock, with the signal that sets it and the time it covers before it wraps. Read the last two columns as the span of all the hands up to that row, not of that row alone.

 

Name

Range

Synchronization Method

Max Time in ms

Max Tim in sec

subframe

0~9

PSS/SSS

10

 

SFN

0~1023

MIB(PBCH)r

10,240

10.24

HFN

0~1023

SIB1

10,485,760

10485.76

(=2.91 hour)

 

Each span is the span above it multiplied by the range of the new counter. Ten subframes of 1 ms make one 10 ms radio frame. The 1024 SFN values stretch this to 10.24 s, and the 1024 HFN values stretch it again to 10485.76 s, a little under 3 hours.

Inside that span, the absolute radio frame number is H-SFN x 1024 + SFN. 36.331 v19.3.0 uses exactly this sum for some periodic boundaries. For example, the SC-MCCH modification period of a BL UE or a UE in CE starts where (H-SFN x 1024 + SFN) mod sc-mcch-ModificationPeriod-BR = 0, if SIB1-BR carries hyperSFN.

  • Each counter multiplies the span of the counter before it : 10 ms, then 10.24 s, then 10485.76 s.
  • Each counter has its own source : PSS/SSS for the subframe, the MIB on PBCH for the SFN, and SIB1 for the HFN.
  • The full frame count is H-SFN x 1024 + SFN : 36.331 uses this sum when a period is longer than one SFN cycle.

How to Synchronize these timers between UE and eNB ?

Before the transmitter (eNode B) and the reciever (UE) in LTE start communicating each of other they have to set these two clock arms to be the same number and this synchronization happens during cell search and timing synch process. In short, they synchronize the tempo (exact time the arm ticks) by cell search and timing sync and UE get SFN sync from MIB which carries SFN number in it. How UE can get synchronized for HFN ? It can synchronize the HFN based on HFN value in SIB1.

Subframe Synchronization : This is done by detecting synchronization signal (PSS and SSS). As you would know of, PSS and SSS is located in subframe 0 and 5 in legacy LTE and LTE BL/CE (LTE-NB Synchronization signal (NPSS and NSSS) is different from legacy LTE and LTE BL/CE). In legacy LTE and LTE BL/CE, if UE detects PSS/SSS it is considered that the subframe is subframe 0 or 5. Then how UE can figure out whether it is subframe 0 or 5. The answer lines in the contents of SSS. You would notice from Symbol Generation of SSS section that the SSS sequence data is different between subframe 0 and 5.

The subframe 0 and 5 rule holds for FDD, that is frame structure type 1, where 36.211 v19.3.0 maps PSS to the last OFDM symbol of slots 0 and 10. For frame structure type 2, TDD, 36.211 maps PSS to the third OFDM symbol of subframes 1 and 6 instead. The SSS stays in subframes 0 and 5, so the SSS sequence still tells subframe 0 from subframe 5 in both cases.

SFN Synchronization : SFN Synchronization is done by PBCH (MIB). eNB transmit SFN value at every PBCH and UE can synchronize its SFN number from this value.

 

 

The MIB capture above shows why the SFN sentence needs one addition. The field systemFrameNumber has only 8 bits, and 36.331 v19.3.0 defines it as the 8 most significant bits of the SFN. The UE gets the 2 least significant bits from the PBCH itself. One MIB is carried over a 40 ms PBCH TTI of four radio frames, and 36.211 restarts the PBCH scrambling in each radio frame with SFN mod 4 = 0. When the UE decodes the PBCH, the position of the frame inside that 40 ms TTI gives the last 2 bits. The first frame is 00, and the last frame is 11. So the capture value 00000000 stands for SFN 0, 1, 2 or 3, depending on which of the four frames the UE decoded.

The capture also shows five spare bits after schedulingInfoSIB1-BR-r13. The current MIB below has used four of them since then, for systemInfoUnchanged-BR-r15 and partEARFCN-r17. The capture is left as it was recorded.

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

MasterInformationBlock ::=          SEQUENCE {
    dl-Bandwidth                        ENUMERATED {
                                            n6, n15, n25, n50, n75, n100},
    phich-Config                        PHICH-Config,
    systemFrameNumber                   BIT STRING (SIZE (8)),
    schedulingInfoSIB1-BR-r13           INTEGER (0..31),
    systemInfoUnchanged-BR-r15          BOOLEAN,
    partEARFCN-r17                  CHOICE {
        spare                           BIT STRING (SIZE (2)),
        earfcn-LSB                      BIT STRING (SIZE (2))
    },
    spare                               BIT STRING (SIZE (1))
}

HFN Synchronization : HFN Synchronization is done by hyperSFN IE in SIB1. eNB can transmit hyperSFN in every SIB1 and UE can synchronize its HFN from this number.

 

 

In the SIB1-BR capture above, hyperSFN-r13 sits in SystemInformationBlockType1-v1310-IEs. It is a BIT STRING of 10 bits, optional with Need OR, and 36.331 describes it as a hyper SFN which increments by one when the SFN wraps around. The same extension carries eDRX-Allowed-r13, which is true in the capture. NB-IoT splits the same counter in two. MasterInformationBlock-NB carries hyperSFN-LSB-r13, the 2 least significant bits, and SystemInformationBlockType1-NB carries hyperSFN-MSB-r13, the 8 most significant bits.

  • The MIB carries only 8 of the 10 SFN bits : the 40 ms PBCH TTI gives the 2 least significant bits.
  • PSS moves in TDD : it is in subframes 1 and 6, while SSS stays in subframes 0 and 5.
  • hyperSFN is optional : it is a 10-bit BIT STRING with Need OR, so a SIB1 can leave it out.
  • NB-IoT splits the HFN : 2 bits in MIB-NB and 8 bits in SIB1-NB.

Why does eDRX paging need the HFN ?

The introduction said that LTE added the HFN for features such as eDRX. Let's see where it enters the paging rule. A UE with a long eDRX cycle must know which 10.24 s hyperframe carries its paging, and the SFN alone cannot name one.

36.304 v19.2.0 clause 7.3 defines the Paging Hyperframe, PH, as the H-SFN that satisfies H-SFN mod TeDRX,H = UE_IDH mod TeDRX,H. Here TeDRX,H is the eDRX cycle in hyperframes, from 1 to 256, or from 2 to 1024 for NB-IoT. UE_IDH is the 10 most significant bits of the Hashed ID when the UE monitors P-RNTI on PDCCH or MPDCCH, and the 12 most significant bits on NPDCCH. The Hashed ID is a 32-bit FCS over the bits of the S-TMSI.

Inside the PH, the UE monitors paging only within a Paging Time Window, PTW. The window starts at SFN = 256 x ieDRX, where ieDRX = floor(UE_IDH / TeDRX,H) mod 4. It ends at SFN = (PTW_start + L x 100 - 1) mod 1024, where L is the window length in seconds, configured by upper layers. So the H-SFN selects the hyperframe, and the SFN selects the window inside it.

With the longest cycle of 256 hyperframes, the UE checks for paging once every 256 x 10.24 s, which is about 43.7 minutes. This is also why the cell has to broadcast its support. Except for NB-IoT, the UE may operate in eDRX only if upper layers configure it and the cell indicates eDRX support in system information.

  • The PH is chosen by H-SFN : H-SFN mod TeDRX,H = UE_IDH mod TeDRX,H.
  • The PTW is chosen by SFN : it starts at one of four positions, 256 frames apart, inside the PH.
  • The longest LTE eDRX cycle is about 43.7 minutes : 256 hyperframes of 10.24 s each.

Reference

  • TS 36.211 v19.3.0 - E-UTRA physical channels and modulation, PBCH scrambling and PSS/SSS mapping
  • TS 36.331 v19.3.0 - E-UTRA RRC, MasterInformationBlock, hyperSFN and the NB-IoT MIB and SIB1
  • TS 36.304 v19.2.0 - E-UTRA UE procedures in idle mode, clause 7.3 paging in extended DRX