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. 

SRVCC Failure

What happens when SRVCC fails at the NW side?
How UE is notified about it and the action it should take?

Notification Procedure (ESM Procedure)
The network can use the notification procedure to inform the UE about events which are relevant for the upper layer which is using an EPS bearer context or has requested a procedure transaction.
If the UE has indicated that it supports the notification procedure, the network may initiate the procedure at any time while a PDN connection exists or a procedure transaction is ongoing.

When the UE receives a NOTIFICATION message, the ESM protocol entity in the UE shall provide the notification indicator to the upper layer.
The notification indicator can have the following value:
#1: SRVCC handover cancelled, IMS session re-establishment required.

The following abnormal case can be identified:
a) Lower layer indication of non-delivered NAS PDU due to handover
If the NOTIFICATION message could not be delivered due to an intra MME handover, then upon successful completion of the intra MME handover the MME shall re-transmit the NOTIFICATION message. If a failure of the handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME shall re-transmit the NOTIFICATION message.

Cell Acquisition - Camping On LTE

Now to initiate a registration UE do need to aquire MIB and SIB1 and SIB2, which in technical term we say as Initial Acquisition - in order to do so UE need to sync it self with NW by synchronizing FRAME and SLOT wise by reading PSS and SSS.

During Initial Acquisitaion , we often say PLMN selection and Cell serach and some time confused between this two.
Just to clear the confusiion if we remeber that SIB1 carried PLMN and to read or acquire PLMN e actually need SIB1 and to get SIB1 we need to perform cell search.



PSS-> Synchronization Signals
Use fullness-
1. Sub Frame
2. Slot
3. Symbol Synchronization
Above 3 in the time domain,
4. Identify center of the channel bandwidth
Above in the frequency domain.
5. Deduce Physical Cell ID (PCI) 1 of 3

Location-
FDD- Central 62 sub-carrier , last symbol of sub-frame 0(sub-frame 0) and 10(sub-frame 5)
TDD- Central 62 sub-carrier , 3rd symbol of time slot 2(sub-frame 1) and time slot 12 (sub-frame 6)


SSS->
Usefullness-
1. Deduce Physical Cell ID Group (PCI Group) 1 of 168
So combined with PSS this helps to determine the PCI.
Location-
FDD- Central 62 sub-carrier , Second last symbol of sub-frame 0(sub-frame 0) and 10(sub-frame 5)
TDD- Central 62 sub-carrier , last symbol of time slot 1(sub-frame 0) and time slot 11 (sub-frame 5)

PSS/SSS in FDD

PSS/SSS in TDD

PSS/SSS Overhead as signalling in FDD

C-RS-> Cell Specific RS
1. Channel Estimation

for correct demodulation of down-link channel , UE required channel estimation. For which we need C-RS. This are known cell-specific reference symbols.

MIB-> Master Information Block

MasterInformationBlock ::= SEQUENCE {
dl-Bandwidth ENUMERATED {
n6, n15, n25, n50, n75, n100},
phich-Config PHICH-Config,
systemFrameNumber BIT STRING (SIZE (8)),
spare BIT STRING (SIZE (10))
}

SIB1-> System information Block 1


SystemInformationBlockType1 ::= SEQUENCE {
cellAccessRelatedInfo SEQUENCE {
plmn-IdentityList PLMN-IdentityList,
trackingAreaCode TrackingAreaCode,
cellIdentity CellIdentity,
cellBarred ENUMERATED {barred, notBarred},
intraFreqReselection ENUMERATED {allowed, notAllowed},
csg-Indication BOOLEAN,
csg-Identity CSG-Identity OPTIONAL -- Need OR
},
cellSelectionInfo SEQUENCE {
q-RxLevMin Q-RxLevMin,
q-RxLevMinOffset INTEGER (1..8) OPTIONAL -- Need OP
},
p-Max P-Max OPTIONAL, -- Need OP
freqBandIndicator FreqBandIndicator,
schedulingInfoList SchedulingInfoList,
tdd-Config TDD-Config OPTIONAL, -- Cond TDD
si-WindowLength ENUMERATED {
ms1, ms2, ms5, ms10, ms15, ms20,
ms40},
systemInfoValueTag INTEGER (0..31),
nonCriticalExtension SystemInformationBlockType1-v890-IEs OPTIONAL
}

PLMN-IdentityInfo ::= SEQUENCE {
plmn-Identity PLMN-Identity,
cellReservedForOperatorUse ENUMERATED {reserved, notReserved}
}

SchedulingInfoList ::= SEQUENCE (SIZE (1..maxSI-Message)) OF SchedulingInfo
SchedulingInfo ::= SEQUENCE {
si-Periodicity ENUMERATED {
rf8, rf16, rf32, rf64, rf128, rf256, rf512},
sib-MappingInfo SIB-MappingInfo
}
SIB-MappingInfo ::= SEQUENCE (SIZE (0..maxSIB-1)) OF SIB-Type
SIB-Type ::= ENUMERATED {
sibType3, sibType4, sibType5, sibType6,
sibType7, sibType8, sibType9, sibType10,
sibType11, sibType12-v920, sibType13-v920, spare5,
spare4, spare3, spare2, spare1, ...}
CellSelectionInfo-v920 ::= SEQUENCE {
q-QualMin-r9 Q-QualMin-r9,
q-QualMinOffset-r9 INTEGER (1..8) OPTIONAL -- Need OP
}


SIB2-> System Information Block 2

[LTE] [NAS] Attach Attempt Counter - Reset

An attach attempt counter is used to limit the number of subsequently rejected attach attempts. The attach attempt counter shall be incremented as specified in subclause 5.5.1.2.6. Depending on the value of the attach attempt counter, specific actions shall be performed. The attach attempt counter shall be reset when:

- the UE is powered on;
- a USIM is inserted;
- an attach or combined attach procedure is successfully completed;
- a GPRS attach or combined GPRS attach procedure is successfully completed in A/Gb or Iu mode;
- a combined attach procedure is completed for EPS services only with cause #2, #16, #17, #18 or #22;
- an attach or combined attach procedure is rejected with cause #11, #12, #13, #14, #15, #25 or #35:
- a network initiated detach procedure is completed with cause #11, #12, #13, #14, #15 or #25; or
- a new PLMN is selected.

Additionally the attach attempt counter shall be reset when the UE is in substate EMMDEREGISTERED.ATTEMPTING-TO-ATTACH and:

- a new tracking area is entered;
- timer T3402 expires; or
- timer T3346 is started.

Attach Procedure 23.401 V 13.6.1

Local IP Access (LIPA) function

The LIPA function enables an IP capable UE connected via a HeNB to access other IP capable entities in the same residential/enterprise IP network without the user plane traversing the mobile operator's network except HeNB subsystem.

The Local IP Access is achieved using a Local GW (L-GW) colocated with the HeNB.

LIPA is established by the UE requesting a new PDN connection to an APN for which LIPA is permitted, and the network selecting the Local GW associated with the HeNB and enabling a direct user plane path between the Local GW and the HeNB. The HeNB supporting the LIPA function includes the Local GW address to the MME in every INITIAL UE MESSAGE and every UPLINK NAS TRANSPORT control message as specified in TS 36.413 [36].

  NOTE 1: The protocol option (i.e. GTP or PMIP) supported on the S5 interface between Local GW and S-GW is configured on the MME.

For this release of the specification no interface between the L-GW and the PCRF is specified and there is no support for Dedicated bearers on the PDN connection used for Local IP Access. The Local GW (L-GW) shall reject any UE requested bearer resource modification.

The direct user plane path between the HeNB and the collocated L-GW is enabled with a Correlation ID parameter that is associated with the default EPS bearer on a PDN connection used for Local IP Access. Upon establishment of the default EPS bearer the MME sets the Correlation ID equal to the PDN GW TEID (GTP-based S5) or the PDN GW GRE key (PMIP-based S5). The Correlation ID is then signalled by the MME to the HeNB as part of E-RAB establishment and is stored in the E-RAB context in the HeNB. The Correlation ID is used in the HeNB for matching the radio bearers with the direct user plane path connections from the collocated L-GW.

If the UE is roaming and if the HSS indicates LIPA roaming allowed for this UE in this VPLMN, then the VPLMN (i.e. MME) may provide LIPA for this UE. Furthermore, in the absence of any LIPA information for the requested APN from the HSS, the VPLMN (i.e MME) shall not provide LIPA. The VPLMN address allowed flag is not considered when establishing a LIPA PDN connection.

LIPA is supported for APNs that are valid only when the UE is connected to a specific CSG. LIPA is also supported for "conditional" APNs that can be authorized to LIPA service when the UE is using specific CSG. APNs marked as "LIPA prohibited" or without a LIPA permission indication cannot be used for LIPA.

MME shall release a LIPA PDN connection to an APN if it detects that the UE's LIPA CSG authorization data for this APN has changed and the LIPA PDN connection is no longer allowed in the current cell.

As mobility of the LIPA PDN connection is not supported in this release of the specification, the LIPA PDN connection shall be released when the UE moves away from H(e)NB. Before starting the handover procedure towards the target RAN, the H(e)NB shall request using an intra-node signalling the collocated L-GW to release the LIPA PDN connection. The H(e)NB determines that the UE has a LIPA PDN connection from the presence of the Correlation ID in the UE (E-)RAB context. The L-GW shall then initiate and complete the release of the LIPA PDN connection using the PDN GW initiated bearer deactivation procedure as per clause 5.4.4.1 or GGSN initiated PDP context deactivation procedure as specified in TS 23.060 [7]. The H(e)NB shall not proceed with the handover preparation procedure towards the target RAN until the UE's (E-)RAB context is clear for the Correlation ID.

At the handover, the source MME checks whether the LIPA PDN connection has been released. If it has not been released:

-and the handover is the S1-based handover or the Inter-RAT handover, the source MME shall reject the handover
-and the handover is X2-based handover, the MME shall send a Path Switch Request Failure message (see more detail in TS 36.413 [36]) to the target HeNB. The MME performs explicit detach of the UE as described in the MME initiated detach procedure of clause 5.3.8.3.

NOTE 2: The direct signalling (implementation dependent) from the H(e)NB to the L-GW is only possible since mobility of the LIPA PDN connection is not supported in this release.

During idle state mobility events, the MME/SGSN shall deactivate the LIPA PDN connection when it detects that the UE has moved away from the HeNB.


Ref: http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/13.06.01_60/ts_123401v130601p.pdf

Selected IP Traffic Offload (SIPTO)

The SIPTO function enables an operator to offload certain types of traffic at a network node close to that UE's point of attachment to the access network.

SIPTO above RAN can be achieved by selecting a set of GWs (S-GW and P-GW) that is geographically/topologically close to a UE's point of attachment.

SIPTO above RAN corresponds to a traffic offload through a P-GW located in the mobile operator's core network.

SIPTO applies to both the non-roaming case and, provided appropriate roaming agreements are in place between the operators, to the roaming case.

Offload of traffic for a UE is available for UTRAN and E-UTRAN accesses only. When the UE enters to UTRAN/EUTRAN from another type of access network (e.g., from GERAN), it is the responsibility of the new SGSN/MME to decide whether to perform deactivation with reactivation request for a given PDN connection, depending on SIPTO permissions for the relevant APN.

Realization for SIPTO above RAN relies on the same architecture models and principles as for local breakout described in clause 4.2.

In order to select a set of appropriate GW (S-GW and P-GW) based on geographical/topological proximity to UE, the GW selection function specified in TS 29.303 [61] uses the UE's current location information.

In order for the operator to allow/prohibit SIPTO on per user and per APN basis, subscription data in the HSS is configured to indicate to the MME if offload is allowed or prohibited. If the SIPTO permissions information from the HSS conflicts with MME's configuration for that UE, then SIPTO is not used.

If HSS indicates VPLMN address not allowed, then VPLMN (i.e. MME) shall not provide SIPTO.

In the absence of any SIPTO permissions indication from the HSS the VPLMN (i.e MME) shall not provide SIPTO.

The MME may be configured on a per APN basis as to whether or not to use SIPTO (e.g. to handle the case where the HSS is not configured with SIPTO information for the UE).

For SIPTO above RAN, as a result of UE mobility (e.g. detected by the MME at TAU or SGSN at RAU or movement from GERAN), the target MME may wish to redirect a PDN connection towards a different GW that is more appropriate for the UE's current location, e.g. MME may know whether the UE's new location is served by the same GW as the old one. When the MME decides upon the need for GW relocation, the MME deactivates the impacted PDN connections indicating "reactivation requested" as specified in clause 5.10.3. If all of the PDN connections for the UE need to be relocated, the MME may initiate the "explicit detach with reattach required" procedure as specified in clause 5.3.8.3.

NOTE: If either of the above procedures for GW relocation are initiated while the UE has active applications, it may cause disruption of services that are affected if the IP address changes.

 
Ref: http://www.etsi.org/deliver/etsi_ts/123400_123499/123401/13.06.01_60/ts_123401v130601p.pdf