Decoding SFN

This one is interesting piece of puzzle.
Normally the puzzle is MIB contains 8 bit info about SFN, then how does UE decode the 10 bit SFN out of 8 bit information.

Let's have a look at the MIB contain's first.

MIB:

• 3 bits for system bandwidth
• 3 bits for PHICH information,
  • 1 bit to indicate normal or extended PHICH
  • 2 bit to indicate the PHICH Ng value
• 8 bits for system frame number
• 10 bits are reserved for future use

If we look carefully then apart from 8bit SFN other information are fixed and will not change over the time.
Only SFN can change here over time.
Which means in every 40ms of MIB transmission the content of the MIB will differ and that is mainly due to 8bit SFN number.

For an example...
SFN changes every 10 ms as frame is of 10ms.

0000 0000 00    ---->> 1st frame at 0th to1ms (Original MIB)
0000 0000 01    ---->> 2nd frame at  10th ms (First copy of MIB)
0000 0000 10    ---->> 3rd frame at 20th ms (Second copy of MIB)
0000 0000 11    ---->> 4th frame at 30th ms (Third copy of MIB)
0000 0001 00    ---->> 5th frame at 40th ms (Original MIB)
0000 0001 01    ---->> 6th frame at 50th ms (First copy of MIB)
0000 0001 10    ---->> 7th frame at 60th ms (Second copy of MIB)
0000 0001 11    ---->> 8th frame at 70th ms (Third copy of MIB)

Now in MIB we receive the 8bit info except the last to bit.
MIB re-transmission has been designed carefully at every 10ms.
Which means after every 40 ms the content of MIB changes.

If UE syncs at second frame on the above example , UE will keep an check on the last bit received from MIB SFN number. Once it changes which is in 5th frame on the above example UE understand that the last two bit is 00 now. 
The decoded frame shall be then 0000 0001 00 

The longest time shall be taken by UE is 40 ms to sync. This happens when UE sync at the very first transmission of the MIB or the original MIB. UE shall wait for the next changed MIB content to realise the last two bit which will be happening in another 40 ms.

The shortest time shall be taken by UE is 10 ms to sync. This happens when UE sync at the third copy of the MIB. UE shall wait for the next changed MIB content to realise the last two bit which will be changing in another 10 ms.
 

RRC state Machine in 5G 38.331

A UE is either in RRC_CONNECTED state or in RRC_INACTIVE state when an RRC connection has been established. If this is not the case, i.e. no RRC connection is established, the UE is in RRC_IDLE state.


- RRC_IDLE: 
- A UE specific DRX may be configured by upper layers;
- UE controlled mobility based on network configuration;
- The UE:
             - Monitors a Paging channel;
             - Performs neighbouring cell measurements and cell (re-)selection; - Acquires system information

- RRC_INACTIVE:
- A UE specific DRX may be configured by upper layers or by RRC layer;
- UE controlled mobility based on network configuration;
- The UE stores the AS context;
- The UE:
            - Monitors a Paging channel; - Performs neighbouring cell measurements and cell (re-)selection;
           - Performs RAN-based notification area updates when moving outside the RAN-based notification area;

- RRC_CONNECTED:
- The UE stores the AS context;
- Transfer of unicast data to/from UE;
- At lower layers, the UE may be configured with a UE specific DRX;
- For UEs supporting CA, use of one or more SCells, aggregated with the SpCell, for increased bandwidth;
- For UEs supporting DC, use of one SCG, aggregated with the MCG, for increased bandwidth;
- Network controlled mobility within NR and to/from E-UTRAN;
- The UE:
             - Monitors a Paging channel;
             - Monitors control channels associated with the shared data channel to determine if data is scheduled for it;
             - Provides channel quality and feedback information;
             - Performs neighbouring cell measurements and measurement reporting;
             - Acquires system information.

Cause in LTE

RRC Connection Establishment Cause:
1. emergency
2. highPriorityAccess
3. mt-Access
4. mo-Signalling
5. mo-Data
6. delayTolerantAccess-v1020
7. spare2
8. spare1

RRC Connection Re-Establishment Cause:
1. reconfigurationFailure,
2. handoverFailure,
3. otherFailure,
4. spare1

RRC Connection Release Cause: 
        1. LoadBalancingTAURequired
2.  'other'
3. 'CS Fallback High Priority'
4. Normal

LTE Attach Type in Attach Request:
EPS attach type value (octet 1)
Bits
3 2 1
0 0 1 EPS attach
0 1 0 combined EPS/IMSI attach
1 1 0 EPS emergency attach
1 1 1 reserved
All other values are unused and shall be interpreted as "EPS attach", if received by the
network.
Bit 4 of octet 1 is spare and shall be coded as zero.

LTE Attach Result in Attach Accept:
EPS attach result value (octet 1)
Bits
3 2 1
0 0 1 EPS only
0 1 0 combined EPS/IMSI attach
All other values are reserved.
Bit 4 of octet 1 is spare and shall be coded as zero.

Additional update type value (AUTV) (octet 1)
       Bit
       1
       0 No additional information. If received it shall be interpreted as request for combined
attach or combined tracking area updating.
       1 SMS only
Bits 4 to 2 of octet 1 are spare and shall be all coded as zero.

Additional update result value (octet 1)
       Bits
       2 1
       0 0 no additional information
       0 1 CS Fallback not preferred
       1 0 SMS only
       1 1 reserved
Bits 4 and 3 of octet 1 are spare and shall all be coded as zero.


Tracking area update request Type:
EPS update type value (octet 1, bit 1 to 3)
Bits
3 2 1
0 0 0 TA updating
0 0 1 combined TA/LA updating
0 1 0 combined TA/LA updating with IMSI attach
0 1 1 periodic updating
1 0 0 unused; shall be interpreted as "TA updating", if received by the network.
1 0 1 unused; shall be interpreted as "TA updating", if received by the network.
All other values are reserved.
"Active" flag (octet 1, bit 4)
Bit
4
0 No bearer establishment requested
1 Bearer establishment requested

Tracking area update accept Result Type: 
EPS update result value (octet 1, bit 1 to 3)
Bits
3 2 1
0 0 0 TA updated
0 0 1 combined TA/LA updated
1 0 0 TA updated and ISR activated (NOTE)
1 0 1 combined TA/LA updated and ISR activated (NOTE)
All other values are reserved.
Bit 4 of octet 1 is spare and shall be coded as zero.

NOTE: Values "TA updated and ISR activated" and "combined TA/LA updated and
ISR activated" are used only for a UE supporting also A/Gb or Iu mode.


Type Of Detach: 
Type of detach (octet 1)
In the UE to network direction:
Bits
3 2 1
0 0 1 EPS detach
0 1 0 IMSI detach
0 1 1 combined EPS/IMSI detach
1 1 0 reserved
1 1 1 reserved
All other values are interpreted as "combined EPS/IMSI detach" in this version of the
protocol.
In the network to UE direction:
Bits
3 2 1
0 0 1 re-attach required
0 1 0 re-attach not required
0 1 1 IMSI detach
1 1 0 reserved
1 1 1 reserved
All other values are interpreted as "re-attach not required" in this version of the
protocol.
Switch off (octet 1)
In the UE to network direction:
Bit
4
0 normal detach
1 switch off
In the network to UE direction bit 4 is spare. The network shall set this bit to zero.



PDN type value (octet 1)
       Bits
       3 2 1
       0 0 1 IPv4
       0 1 0 IPv6
       0 1 1 IPv4v6
       1 0 0 unused; shall be interpreted as "IPv6" if received by the network
All other values are reserved.
Bit 4 of octet 1 is spare and shall be coded as zero.

NEED ON/OR/OP in RRC

Abbreviation Meaning

Cond conditionTag (Used in downlink only) 
Conditionally present An information element for which the need is specified by means of conditions. For each conditionTag, the need is specified in a tabular form following the ASN.1 segment. In case, according to the conditions, a field is not present, the UE takes no action and where applicable shall continue to use the existing value (and/ or the associated functionality) unless explicitly stated otherwise in the description of the field itself.

Need OP (Used in downlink only)
 Optionally present An information element that is optional to signal. For downlink messages, the UE is not required to take any special action on absence of the IE beyond what is specified in the procedural text or the field description table following the ASN.1 segment. The UE behaviour on absence should be captured either in the procedural text or in the field description.

Need ON (Used in downlink only) 
Optionally present, No action An information element that is optional to signal. If the message is received by the UE, and in case the information element is absent, the UE takes no action and where applicable shall continue to use the existing value (and/ or the associated functionality).

Need OR (Used in downlink only)
 Optionally present, Release An information element that is optional to signal. If the message is received by the UE, and in case the information element is absent, the UE shall discontinue/ stop using/ delete any existing value (and/ or the associated functionality).