[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

RRC Messages on LTE

SN	RRC Message	SRB	RLC SAP	Logical Channel	Direction	Desc
1	Paging	N/A	TM	PCCH	E-UTRAN to UE	The Pagingmessage is used for the notification of one or more UEs.
2	MasterInformationBlock	N/A	TM	BCCH	E-UTRAN to UE	The MasterInformationBlock includes the system information transmitted on BCH.
3	SystemInformationBlockType1	N/A	TM	BCCH	E-UTRAN to UE	SystemInformationBlockType1contains information relevant when evaluating if a UE is allowed to access a cell and defines the scheduling of other system information.
4	SystemInformation	N/A	TM	BCCH	E-UTRAN to UE	The SystemInformationmessage is used to convey one or more SystemInformation Blocks. All the SIBs included are transmitted with the same periodicity.
5	RRCConnectionRequest	SRB0	TM	CCCH	UE to E-UTRAN	The RRCConnectionRequestmessage is used to request the establishment of an RRC connection.
6	RRCConnectionSetup	SRB0	TM	CCCH	E-UTRAN to UE	The RRCConnectionSetupmessage is used to establish SRB1.
7	RRCConnectionSetupComplete	SRB1	AM	DCCH	UE to E-UTRAN	The RRCConnectionSetupCompletemessage is used to confirm the successful completion of an RRC connection establishment.
8	RRCConnectionReject	SRB0	TM	CCCH	E-UTRAN to UE	The RRCConnectionRejectmessage is used to reject the RRC connection establishment.
9	RRCConnectionRelease	SRB1	AM	DCCH	E-UTRAN to UE	The RRCConnectionReleasemessage is used to command the release of an RRC connection.
10	RRCConnectionReject	SRB0	TM	CCCH	E-UTRAN to UE	The RRCConnectionRejectmessage is used to reject the RRC connection establishment.
11	RRCConnectionReconfiguration	SRB1	AM	DCCH	E-UTRAN to UE	The RRCConnectionReconfigurationmessage is the command to modify an RRC connection. It may convey  information for measurement configuration, mobility control, radio resource configuration (including RBs, MAC main configuration and physical channel configuration) including any associated dedicated NASinformation and security configuration.
12	RRCConnectionReconfigurationComplete	SRB1	AM	DCCH	UE to E-UTRAN	The RRCConnectionReconfigurationCompletemessage is used to confirm the successful completion of an RRC connection reconfiguration.
13	RRCConnectionReestablishment	SRB0	TM	CCCH	E-UTRAN to UE	The RRCConnectionReestablishmentmessage is used to re-establish SRB1.
14	RRCConnectionReestablishmentRequest	SRB0	TM	CCCH	UE to E-UTRAN	The RRCConnectionReestablishmentRequestmessage is used to request the reestablishment of an RRC connection.
15	RRCConnectionReestablishmentComplete	SRB1	AM	DCCH	UE to E-UTRAN	The RRCConnectionReestablishmentCompletemessage is used to confirm the successful completion of an RRC connection reestablishment.
16	RRCConnectionReestablishmentReject	SRB0	TM	CCCH	E-UTRAN to UE	The RRCConnectionReestablishmentReject message is used to indicate the rejection of an RRC connection reestablishment request.
17	SecurityModeCommand	SRB1	AM	DCCH	E-UTRAN to UE	The SecurityModeCommandmessage is used to command the activation of AS security.
18	SecurityModeComplete	SRB1	AM	DCCH	UE to E-UTRAN	The SecurityModeCompletemessage is used to confirm the successful completion of a security mode command.
19	SecurityModeFailure	SRB1	AM	DCCH	UE to E-UTRAN	The SecurityModeFailuremessage is used to indicate an unsuccessful completion of a security mode command.
20	UECapabilityEnquiry	SRB1	AM	DCCH	E-UTRAN to UE	The UECapabilityEnquirymessage is used to request the transfer of UE radio access capabilities for E-UTRA as well as for other RATs.
21	UECapabilityInformation	SRB1	AM	DCCH	UE to E-UTRAN	The UECapabilityInformationmessage is used to transfer of UE radio access capabilities requested by the E-UTRAN.
22	UEInformationRequest	SRB1	AM	DCCH	E-UTRAN to UE	The UEInformationRequestis the command used by E-UTRAN to retrieve information from the UE.
23	UEInformationResponse	SRB1	AM	DCCH	UE to E-UTRAN	The UEInformationResponse message is used by the UE to transfer the information requested by the E-UTRAN.

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.

RB RE Speed

Resource Element:
Covered by 1 sub carrier and one symbol period i.e 1 Symbol

Resource Block:
Covered by 12 Subcarriers and 6 or 7 symbols(Based on Cyclic prefix)

We can calculate the capacity if we know the Bandwidth allocated,Modulation scheme used and Cyclic Prefix type.
Consider 
Bandwidth Allocated = 5MHz
Modulation Scheme = QPSK(2 its per symbol)
Cyclic prefix used = Normal Cyclic Prefix (7 symbols in a slot)

Capacity = No of bits transferred in a sub frame / Duration of the Subframe(i.e 1milli sec)

Calculation No of Bits transferred in a Subframe

Total number of Resource block in a slot = Bandwidth / (Each subcarrier bandwidth * no of subcarriers in a Resource Block) 
Bandwidth = 5Mhz
Each sub carrier width = 15Khz
No of sub carriers in a Resource Block = 12 (As 12 Subcarrier is 1 Resource block )

Calculation of total no of resource blocks in 5MHz Bandwidth

so Resource block in one slot = 5 Mhz / (15 KHz *12 ) = 27.77 (But used RBs will be 25 for 5MHz bandwidth)
so Total Resource block in one subframe = 2 * Resource blocks in a slot = 50 RBs

Calculation of total no of symbols/Resource Elements in 5MHz Bandwidth
Total no of symbols / Resource Elements = 50 * no of symbols(REs) in a Resource block
No of symbols(REs) in a resource block = 12 subcarrier * 7 symbols = 84 symbols(REs)
Total symbols(REs ) in 50 Resource blocks = 50 * 84 = 4200 Resource Elements.

****Calculation of total no of bits sent in 5MHz Bandwidth in one subframe ****

In one symbol we can send no of bits at a time which depends on the modulation scheme (like BPSK,QPSK ,64QAM
BPSK - 1 bit,QPSK - 2 bit ,64 QAM - 6bits in a Symbol/ Resource elements
We will consider QPSK Scheme so in one symbol 2bits we can send.
So 1 Symbol = 2 bits.

So total no of Bits sent in a subframe = 2 * 4200 = 8400 bits.

So capacity = 8400 / 1ms = 8.4 MBPS

So capacity in 5MHz Bandwidth with QPSK Modulation with normal cyclic Prefix is 8.4MBPS.

if Modulation scheme is BPSK, 1 bits in a symbol = 1 * 4200 / 1ms = 4.2 MBPS
if Modulation scheme is 64QAM , 6 bits in a symbol = 6 * 4200 / 1ms = 25.2 MBPS.