Tuesday, August 25, 2020

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.
 

Thursday, October 18, 2018

Identifiers in 5G


PEI                    Permanent Equipment Identifier
SUCI                Subscription Concealed Identifier
SUPI                Subscription Permanent Identifier
5G-GUTI         5G Globally Unique Temporary Identifier
5G-S-TMSI     5G S-Temporary Mobile Subscription Identifier
NCGI               NR Cell Global Identity
NCI                  NR Cell Identity
GUTI               Globally Unique Temporary UE Identity
GUAMI           Globally Unique AMF Identifier
TWAP             Trusted WLAN AAA Proxy
UUID              Universally Unique Identifier

Wednesday, August 8, 2018

How to inform a new TAI list to UE

The easiest way to include a new TAI list to UE is GUTI REALLOCATION COMMAND.

This Message includes a TAI list IE which is optional.
This message is sent by the network to the UE to reallocate a GUTI and optionally to provide a new TAI list.


GUTI Reallocation Command is a EMM common procedure.
Which needs a existing  NAS signalling connection to happen (Another mobility management procedure).

Access Class

It is not intended that access control be used under normal operating conditions.
The use of this facility allows the network operator to prevent overload of the access channel under critical conditions.

Under certain circumstances, it will be desirable to prevent UE users from making access attempts (including emergency call attempts) or responding to pages in specified areas of a PLMN. Such situations may arise during states of emergency, or where 1 of 2 or more co-located PLMNs has failed.

All UE's are member of one out of 10 access class - given randomly (0 to 9).
The population number is stored in the SIM/USIM.In addition, mobiles may be members of one or more out of 5 special categories (Access Classes 11 to 15), also held in the SIM/USIM.
These are allocated to specific high priority users as follows. (The enumeration is not meant as a priority sequence):

Class 15 - PLMN Staff;
-"- 14 - Emergency Services;
-"- 13 - Public Utilities (e.g. water/gas suppliers);
-"- 12 - Security Services;
-"- 11 - For PLMN Use.


EF_ACC 6F78 is the location in sim card for access class.
This is 2 byte.

Example:
Bellow specified  entry tells that sim card has only 15 as a Access Class (Which is wrong)
EF_ACC (6F78) to 0x80 (Byte 1), 0x00 (Byte 2) - only class 15 bit is set

Bellow specified  entry tells that sim card has 15 and 0 as  Access Class (Which is correct)
EF_ACC (6F78) to 0x80 (Byte 1), 0x01 (Byte 2) - class 15 and class 0 bit is set

link: http://www.qtc.jp/3GPP/Specs/22011-940.pdf

Tuesday, August 7, 2018

X2AP procedures

The X2 interface X2AP procedures are divided into two modules as follows:

1. X2AP Basic Mobility Procedures; 
2. X2AP Global Procedures; 

The X2AP Basic Mobility Procedures module contains procedures used to handle the UE mobility within E-UTRAN.

The Global Procedures module contains procedures that are not related to a specific UE. The procedures in this module are in contrast to the above module involving two peer eNBs

Thursday, August 2, 2018

PTI Procedure Transaction Identity

Procedure Transaction Identity: An identity which is dynamically allocated by the UE for the UE requested ESM procedures. The procedure transaction identity is released when the procedure is completed.

The EPS bearer identity and the procedure transaction identity are only used in messages with protocol discriminator EPS session management.


The PTI is been used to identify the transaction particular transaction.
2018 Mar 19  20:54:15.081  [97]  0xB0E3  LTE NAS ESM Plain OTA Outgoing Message  --  PDN connectivity request Msg
trans_id = 4 (0x4)
2018 Mar 19  20:54:15.168  [74]  0xB0E2  LTE NAS ESM Plain OTA Incoming Message  --  Activate default EPS bearer context request Msg
trans_id = 4 (0x4)
2018 Mar 19  20:54:15.170  [D9]  0xB0E3  LTE NAS ESM Plain OTA Outgoing Message  --  Activate default EPS bearer context accept Msg
trans_id = 0 (0x0)
This follows the figure 6.3.2.3 By sending trans_id as 0 the procedure will be ended.

LTE PDN CONNECTIVITY REQUEST message content


Request Type (9.9.4.14)
Based on 10.5.6.17 Request type of 24.008
The purpose of the Request type information element is to indicate whether the MS requests to establish a new
connectivity to a PDN or keep the connection(s) to which it has connected via non-3GPP access.
The Request type information element is also used to indicate that the MS is requesting connectivity to a PDN that
provides emergency bearer services.

Request Type Can be Initial , Handover or Emergency.
Handover will be set as request type when the PDN established over Wi-Fi needs to be continued over LTE.

Device Properties (9.9.2.0A)
Based on 10.5.7.8 in 3GPP TS 24.008
The purpose of the Device properties information element is to indicate if the MS is configured for NAS signalling low
priority. The network uses the Device properties information element for core-network congestion handling and for
charging purposes.

IMS voice call concurrency handling scenarios

SIM1 status
SIM2 event
SIM2 action
Active call on Wi-Fi (VoWiFi)
Receives IMS call (SIP INVITE) over Wi-Fi
Rejects call with 486 – Busy here
Active call on Wi-Fi (VoWiFi)
Receives IMS call (SIP INVITE) over LTE
Rejects call with 486 – Busy here
Active call on Wi-Fi (VoWiFi)
Receives SMS/MMS on either SIM1 or SIM2
SMS/MMS is accepted/received on corresponding SUB
Active call on Wi-Fi (VoWiFi)
Receives CSFB call over LTE on either SIM1 or SIM2
Drops CS page/call in LTE
Active call on Wi-Fi (VoWiFi)
Receives CS call on GSM/WCDMA on either SIM1 or SIM2
Drops CS page in GSM/WCDMA
Active call on LTE (VoLTE)
Receives IMS call (SIP INVITE) over Wi-Fi
Rejects call with 486 – Busy here

Friday, July 6, 2018

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.


Monday, March 12, 2018

SIB for Handovers


From
To
Mandatory SIB's
Optiional SIB's
LTE
LTE
SIB1 SIB2 SIB3
SIB4
LTE
LTE
SIB1 SIB2 SIB3 SIB5
SIB4
LTE
WCDMA
SIB1 SIB2 SIB3 SIB6
LTE
GERAN
SIB1 SIB2 SIB3 SIB7
LTE
HRPD
SIB1 SIB2 SIB3 SIB8