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

LTE Channel Mapping Along with Messages

Uplink

Message

1. PRACH

3. MSG3

5. MSG 5

User Data

Layer

Channel

Preamble

Onwards

RLC

Logical Channel

CCCH

DCCH

DCCH

DTCH

MAC

MAC

Transport Channel

RACH

UL-SCH

PHY

UCI

PHY

Physical Channel

PRACH

PU-SCH

PUCCH

Downlink

MIB

SIB

Paging

2. RACH

4. MSG4

6. MSG6

User Data

Layer

Response

Onwards

RLC

BCCH

BCCH

PCCH

CCCH

DCCH

DCCH

DTCH

MCCH

MTCH

MAC

MAC

BCH

DL-SCH

PCH

DL-SCH

MCH

PHY

DCI

CFI

HI

PHY

PBCH

PD-SCH

PDCCH

PCFICH

PHICH

PMCH

Measurement Report - Event

Spec: 36.331 5.5.4

Measurement Report Events in LTE



1. Measurement objects:
2. Reporting configurations:
3. Measurement identities:
4. Quantity configurations:
5. Measurement gaps:

Taken from: http://www.sharetechnote.com/html/Handbook_LTE_MultiCell_Measurement_LTE.html




Event A1 (Serving becomes better than threshold)

Event A2 (Serving becomes worse than threshold)

Event A3 (Neighbour becomes offset better than PCell/ PSCell)

Event A4 (Neighbour becomes better than threshold)

Event A5 (PCell/ PSCell becomes worse than threshold1 and neighbour
becomes better than threshold2)

Event A6 (Neighbour becomes offset better than SCell)

Event B1 (Inter RAT neighbour becomes better than threshold)

Event B2 (PCell becomes worse than threshold1 and inter RAT neighbour
becomes better than threshold2)

Event C1 (CSI-RS resource becomes better than threshold)
Event C2 (CSI-RS resource becomes offset better than reference CSI-RS
resource)


Reference: http://www.slideshare.net/allabout4g/lte-measurement-events-5524613

SINR CQI RSRP RSSI RSRQ

SINR - Signal to Interference plus Noise Ratio

Signal to Interference plus Noise Ratio (SINR) is measured by UE on Resource Block (RB) basis.
UE computes SINR on each RB, converts it to CQI and reports it to eNodeB where it is used to select the most suitable MCS for user data transmission in particular RB. SINR value defines the MCS to be used for a RB i.e. the number of bits per modulation symbol to be sent i.e. throughput to be achieved for that particular RB as well as the number of RBs to be allocated by eNodeB to user. SINR can be defined as the ratio of the signal power to the summation of the average interference power from the other cells and the background noise.


CQI - Channel Quality Indicator

CQI is a quantized and scaled version of the experienced SINR. The process of adapting MCS depending on current channel conditions is termed as Link Adaptation. If the SINR is good, higher order MCS (e.g. 64QAM) can be selected implying that more bits per modulation symbol can be transmitted and higher throughput can be achieved. If the SINR is poor, lower order MCS (i.e. QPSK) should be selected implying fewer bits per symbol are transmitted which in turn results in lower throughput.


RSRP - Received Signal Received Power

Reference Signal Received Power (RSRP) is a cell-specific signal strength related metric that is used as an input for cell resection and handover decisions. For a particular cell, RSRP is defined as the average power (in Watts) of the Resource Elements (REs) that carry cell-specific Reference Signals (RSs) within the considered bandwidth.
RSRP measurement, normally expressed in dBm, is utilized mainly to make ranking among different candidate cells in accordance with their signal strength. Generally, the reference signals on the first antenna port are used to determine RSRP, however, the reference signals sent on the second port can also be used in addition to the RSs on the first port if UE can detect that they are being transmitted



RSRQ - .Reference Signal  Received Quality

Reference Signal Received Quality (RSRQ) measurement is a cell-specific signal quality metric. Similar to the RSRP measurement, this metric is used mainly to provide ranking among different candidate cells in accordance with their signal quality. This metric can be employed as an input in making cell reselection and handover decisions in scenarios (for example) in which the RSRP measurements are not sufficient to make reliable cell-reselection/handover decisions.
It is defined as
RSRQ = ( N.RSRP )/(LTE Carrier RSSI )
where, N is the number of Resource Blocks (RBs) of the LTE carrier Received Signal Strength Indicator (RSSI) measurement bandwidth.



RSSI - Received Signal Strength Indicator

Received Signal Strength Indicator (RSSI) is the linear average of the total received power observed only in OFDM symbols carrying reference symbols by UE from all sources, including co-channel non-serving and serving cells, adjacent channel interference and thermal noise, within the measurement bandwidth over N RBs. RSSI is used as an input to compute the LTE RSRQ measurement discussed above.


Reference- http://airccse.org/journal/jwmn/7415ijwmn09.pdf