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

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. 

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

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.

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

RACH Procedure

RACH Procedure Flow

1. RRC Layer sends Access Req for RRC Connection Request/RRC Coonection Re-establishment Request to MAC and starts T300 timer
[020/008/012] OTA LOG 00:00:21.032 UL_CCCH / RRCConnectionRequestRadio Bearer ID: 0, Freq: 2050, SFN:0
[9504/0002] MSG 00:00:21.032 LTE MACCTRL Start Access Request for reason=0, RAID=2551
[9501/0002/0010] MSG 00:00:21.069 LTE RRC   T300 timer internally restarted with 400ms

2. MAC sends Start_RACH_Req to ML1
[9509/0001/0010] MSG 00:00:21.032 LTE ML1  ML1: LTE_CPHY_START_RACH_REQ rcvd

3. ML1 sends the first preamble and starts RA response timer
[0xB167] LOG 00:00:21.069 LTE Random Access Request (MSG1) ReportLength: 0032 
[9509/0002] MSG 00:00:21.073 LTE ML1 Processing LTE_CPHY_RA_TIMER_STARTED_IND

4. If MAC could decode RAR before ML1 RA timer expiry and send the same to ML1, ML1 will go ahead with MSG3 transmission
[9509/0002] MSG 00:00:21.073 LTE ML1 Processing LTE_CPHY_RA_TIMER_STARTED_IND
[0xB168] LOG 00:00:21.077 LTE Random Access Response (MSG2) ReportLength: 0012

5. If MAC could not give RA parameter request to ML1 before ML1 RA timer expiry, then ML1 sends RA timer expiry indication to MAC
6. Here MAC starts another RACH attempt (with another preamble sequence with increased preamble power); MAC repeats this procedure till it sends maximum number of preambles (MAX_RACH attempts)
7. If MAC reaches MAX_RACH attempts, i.e., maximum number of preambles reached, and still could not get RAR, then MAC sends Random Access Problem indication to RRC and continues RACHing
8. MAC will stop RACHing only when T300 expired in RRC and RRC sends Abort request

VOLTE VOIP IMS SIP CSFB

Often people are confused between VOLTE ,VOIP, IMS , SIP and CSFB.
To be clear between all this item lets explain them and understand one by one.
We will start with CSFB and then VOIP and then VOLTE and IMS.

CSFB - CSFB is CS Fall back.
             This was introduced at the very early stages of 4G/LTE to make CALL's as because LTE has
              been PS from the beginning and over PS LTE was not having any standard offerings for
              calls. Because of not having call support 3GPP standard decides to use to use CS over
              legacy network.
VOIP - Now VOIP is Voice Over IP. Frankly speaking there is no relation between VOIP and LTE.
             VOIP can be used over PS and it could be from 2G , 3G or LTE or may be Wi-Fi even over
             the LAN as well.
VOLTE - VOLTE is Voice Over LTE. The much talked feature of LTE without which LTE was not
                complete Conceptually it it Voice-Over-IP On LTE , but there is a lot more to it than just
                VOIP.
IMS - IMS is IP Multimedia Subsystem. This is a concept for an integrated network.
          This is not a protocol at all.
SIP - Session initiation protocol. This is an application layer protocol. This can establish modify and
         terminate multimedia session.


So in one line VOLTE is an VOIP over LTE which uses SIP protocol over IMS architecture.