System Information Block Type 1

Direction: E-UTRAN => UE

Signalling Radio Bearer: N/A

RLC Mode: TM

Logical Channel: BCCH

Transport Channel: DL-SCH

SystemInformationBlockType1 (SIB1) contains information relevant when

evaluating if a UE is allowed to access a cell. Also, it supplies the UE with the

scheduling of other system information. SIBs other than SIB1 are carried in

SystemInformation (SI) messages and mapping of SIBs to SI messages is flexibly

configurable by schedulingInfoList included in SIB1

SIB1 uses a fixed schedule with a periodicity of 80ms and repetitions made

within 80ms. The first transmission of SIB1 is scheduled in subframe #5 of radio

frames for which the SFNmod8 = 0, and repetitions are scheduled in subframe #5 of all

other radio frames for which SFNmod2 = 0

SIB1 contains cell access related information (e.g. a PLMN identity list, tracking

area code, cell identity, etc.), information for cell selection (e.g. minimum required

Rx level in the cell and offset), p-Max, frequency band indicator, scheduling

information, TDD configuration, SI-window length and system information value tag

etc...

Upon receiving the SIB1 message the UE shall check the IE freqBandIndicator.

The UE shall consider the cell as barred if the frequency band indicated in the

freqBandIndicator is not part of the frequency bands supported by the UE

Some of the IEs in SystemInformationBlockType1 message:

PLMN-IdentityList: List of PLMN identities. The first listed PLMN-Identity is the

primary PLMN

TrackingAreaCode: A trackingAreaCode that is common for all the PLMNs listed

Cellidentity: Identity of the cell

CellBarred: 'barred’ means the cell is barred

IntraFreqReselection: Used to control cell reselection to intra-frequency cells when

the highest ranked cell is barred, or treated as barred by the UE

CSG-Indication: If this IE is set to TRUE the UE is only allowed to access the cell if the

CSG identity matches an entry in the CSG whitelist that the UE has stored

p-Max: Maximum power value applicable for the cell. If this IE is absent, then the UE

applies the maximum power according to the UE capability

freqBandIndicator: Operating frequency band of the cell as defined in TS 36.101

[Table 5.5-1].

si-Periodicity: Periodicity of the SI-message in radio frames, such that rf8 denotes 8

radio frames, rf16 denotes 16 radio frames, and so on

sib-MappingInfo: List of the SIBs mapped to this SystemInformation message. There is

no mapping information of SIB2; it is always present in the first SystemInformation

message listed in the schedulingInfoList list.

si-WindowLength: Common SI scheduling window for all SIs. Unit in milliseconds,

where ms1 denotes 1 millisecond, ms2 denotes 2 milliseconds and so on

systemInfoValueTag: Common for all SIBs other than MIB, SIB1, SIB10, SIB11 and

SIB12. Change of MIB and SIB1 is detected by acquisition of the corresponding message

csg-Identity: Identity of the Closed Subscriber Group within the primary PLMN the cell

belongs to. This field is present in a CSG cell

ims-EmergencySupport: Indicates whether the cell supports IMS emergency bearer

services for UEs in limited service mode. If absent, IMS emergency call is not

supported by the network in the cell for UEs in limited service mode

System Information Block Type 2

Direction: E-UTRAN => UE

Signalling Radio Bearer: N/A

RLC Mode: TM

Logical Channel: BCCH

Transport Channel: DL-SCH

SystemInformationBlockType2 (SIB2) contains radio resource configuration

information that is common for all UEs. It contains access barring information, radio

resource configuration of common and shared channels, timers and constants which

are used by UEs, uplink power control information etc.

SIB2 is not specifically included in the scheduling information in SIB1 but it is

always mapped to the SI message that corresponds to the first entry in the list of SI

messages in schedulingInfoList in SIB1

SIB2 also gives information about the uplink carrier frequency and the uplink

channel bandwidth in terms of number of Resource Blocks

Some of the IEs in SystemInformationBlockType2:

UL-CarrierFreq: If this IE is absent (for FDD), the UL-Carrier Frequency value should

be determined from the default TX-RX frequency separation defined in TS

36.101 [Table 5.7.3-1]. For TDD, this parameter is absent and it is equal to the

downlink frequency

UL-Bandwidth: Transmission bandwidth configuration, NRB, in uplink. The

value n6 corresponds to 6 resource blocks, n15 to 15 resource blocks and so on. If this

parameter is absent for FDD then the uplink bandwidth is equal to the downlink

bandwidth. For TDD this parameter is absent and it is equal to the downlink

bandwidth

defaultPagingCycle: Default paging cycle value rf32 corresponds to 32 radio

frames, rf64 corresponds to 64 radio frames and so on

modificationPeriodCoeff: Actual modification period, expressed in number of radio

frames= modificationPeriodCoeff * defaultPagingCycle.The value n2 corresponds

to value 2, n4 corresponds to value 4, and so on

p-Max: Maximum power to be used in the target cell. If this IE is absent then the UE

applies the maximum power according to the UE capability

UL-CyclicPrefixLength: The value len1 corresponds to normal cyclic

prefix and len2 corresponds to extended cyclic prefix

RadioResourceConfigCommonSIB: The IE RadioResourceConfigCommonSIB is used to

specify common radio resource configurations e.g., the random access parameters

and the static physical layer parameters

Attach Request

The UE includes ATTACH REQUEST (initial-NAS) message within RRC CONNECTION

SETUP COMPLETE message. The IE dedicatedInfoNAS in RRC CONNECTION SETUP

COMPLETE includes this initial-NAS message

The IEs (some of them are explained below) in ATTACH REQUEST message include

EPS attach type, EPS mobile identity, UE network capability, ESM message container, Old

P-TMSI signature, Additional GUTI, Last visited registered TAI, DRX parameter, Old

location area identification, Additional update type, Voice domain preference and UE's

usage setting etc…

The IE EPS Attach Type indicates the purpose of the attach procedure. The value

can be EPS attach (to attach for EPS services only) or combined EPS/IMSI attach (to

attach for both EPS and non-EPS services) or EPS emergency attach (to attach for

emergency bearer services)

The IE EPS Mobile Identity can be GUTI, IMSI or IMEI. The UE shall include GUTI if

it holds a valid GUTI (either native GUTI or mapped GUTI). If there is no valid GUTI

available, the UE shall include the IMSI as EPS Mobile Identity IE. If the UE is attaching for

emergency bearer services and does not hold a valid GUTI, P-TMSI or IMSI as described

above, the IMEI shall be included in the EPS mobile identity IE

The purpose of the ESM message container IE is to enable piggybacked transfer of

an ESM message within an EMM message (This may contain IEs for example, EPS bearer

identity, procedure transaction identity, PDN connectivity request, PDN type, Request

type, ESM information transfer flag, EIT (ESM information transfer), Protocol

Configuration Options (Configuration Protocol, DNS Server Address Request etc..)

The IE Additional Update Type provides additional information about the type of

request for a combined attach procedure. Bit1 value 0 means that there is “no additional

information” and 1 means that “SMS only”

Voice domain preference and UE's usage setting IE shall be included if the UE

supports CS fallback and SMS over SGs, or if the UE is configured to support IMS voice, but

does not support 1xCS fallback. This IE provides the network with the UE's usage setting

and the voice domain preference for E-UTRAN. Refer to 3GPP TS 24.008,

section 10.5.5.28 for detailed information

The IE Last Visited Registered TAI shall be included if the UE holds a valid last

visited registered Tracking Area Identity (TAI)

Reference: 3GPP TS 24.301 and 3GPP TS 24.008

Attach Request

The UE includes ATTACH REQUEST (initial-NAS) message within RRC CONNECTION

SETUP COMPLETE message. The IE dedicatedInfoNAS in RRC CONNECTION SETUP

COMPLETE includes this initial-NAS message

The IEs (some of them are explained below) in ATTACH REQUEST message include

EPS attach type, EPS mobile identity, UE network capability, ESM message container, Old

P-TMSI signature, Additional GUTI, Last visited registered TAI, DRX parameter, Old

location area identification, Additional update type, Voice domain preference and UE's

usage setting etc…

The IE EPS Attach Type indicates the purpose of the attach procedure. The value

can be EPS attach (to attach for EPS services only) or combined EPS/IMSI attach (to

attach for both EPS and non-EPS services) or EPS emergency attach (to attach for

emergency bearer services)

The IE EPS Mobile Identity can be GUTI, IMSI or IMEI. The UE shall include GUTI if

it holds a valid GUTI (either native GUTI or mapped GUTI). If there is no valid GUTI

available, the UE shall include the IMSI as EPS Mobile Identity IE. If the UE is attaching for

emergency bearer services and does not hold a valid GUTI, P-TMSI or IMSI as described

above, the IMEI shall be included in the EPS mobile identity IE

The purpose of the ESM message container IE is to enable piggybacked transfer of

an ESM message within an EMM message (This may contain IEs for example, EPS bearer

identity, procedure transaction identity, PDN connectivity request, PDN type, Request

type, ESM information transfer flag, EIT (ESM information transfer), Protocol

Configuration Options (Configuration Protocol, DNS Server Address Request etc..)

The IE Additional Update Type provides additional information about the type of

request for a combined attach procedure. Bit1 value 0 means that there is “no additional

information” and 1 means that “SMS only”

Voice domain preference and UE's usage setting IE shall be included if the UE

supports CS fallback and SMS over SGs, or if the UE is configured to support IMS voice, but

does not support 1xCS fallback. This IE provides the network with the UE's usage setting

and the voice domain preference for E-UTRAN. Refer to 3GPP TS 24.008,

section 10.5.5.28 for detailed information

The IE Last Visited Registered TAI shall be included if the UE holds a valid last

visited registered Tracking Area Identity (TAI)

Reference: 3GPP TS 24.301 and 3GPP TS 24.008

Example: Attach Request Message

http://4.bp.blogspot.com/-2udfZXoltu0/Tsg6CeiWU-I/AAAAAAAADVY/e4TVKghJMhs/s1600/AttachRequest.png

Attach Accept

The ATTACH ACCEPT message is sent by the network to the UE to indicate that the

corresponding ATTACH REQUEST has been accepted. Typically, the ATTACH ACCEPT

message is piggy-backed on RRC CONNECTION RECONFIGURATION message

The result of the EPS attach is indicated in the IE EPS Attach Result. The result

can be either “EPS only” or “combined EPS/IMSI attach”. The result "combined EPS/IMSI

attach" indicates that the attach request for EPS and non-EPS services, or for EPS services

and "SMS only" have been successful. The result "EPS only" indicates that the attach

request for EPS services (only) has been successful but attach for non-EPS services or "SMS

only" (if requested by the UE in the ATTACH REQUEST) has failed

When the default bearer is activated as part of the attach procedure, the MME

shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message together with

ATTACH ACCEPT message. The IE ESM Message Container is used for this purpose. The

network may also initiate the activation of dedicated bearers towards the UE by invoking

the dedicated EPS bearer context activation procedure

The GUTI Reallocation may be part of the attach procedure. If the ATTACH

REQUEST message includes the IMSI or IMEI, or if the MME considers the GUTI provided by

the UE is invalid, or if the GUTI provided by the UE was assigned by another MME, the

MME shall allocate a new GUTI to the UE. The MME shall include in the ATTACH ACCEPT

message the new assigned GUTI together with the assigned TAI list

The IE TAI List indicates a list of tracking areas for which the UE doesn't need to

perform a tracking area updating procedure when entered one of these TAs (in the list).

The TAIs in a TAI list assigned by an MME to a UE belongs to the same MME area

The MME includes EMM Cause IE when IMSI attach for non-EPS services is not

successful during a combined EPS/IMSI attach procedure

The purpose of the EPS network feature support IE is to indicate whether certain

features are supported by the network. It can indicate the following features whether

supported or not: IMS voice over PS session indicator (IMS VoPS), Emergency bearer

services indicator (EMC BS), Location services indicator in EPC (EPC-LCS), Location

services indicator in CS (CS-LCS), Support of EXTENDED SERVICE REQUEST for packet

services (ESRPS)

The purpose of the Additional update result IE is to provide additional

information about the result of a combined attach procedure. 00-no additional

information; 01-CS Fallback not preferred; 10-SMS only; 11-reserved

Reference: 3GPP TS 24.301

Example: ATTACH ACCEPT Message

http://4.bp.blogspot.com/-_q5pW_CMi9E/TskAO8zZeNI/AAAAAAAADWE/wgt7AC_vM4Y/s1600/Attach+Accept.png

Attach Reject

If the UE initiated ATTACH REQUEST cannot be accepted by the network, the MME

shall send an ATTACH REJECT message to the UE including an appropriate EMM cause

value

If the attach procedure fails due to a Default EPS bearer Setup Failure or an ESM

procedure failure or operator determined barring is applied on Default EPS Bearer

Context Activation during attach procedure, the MME shall combine the ATTACH REJECT

message with a PDN CONNECTIVITY REJECT message contained in the ESM Message

Container IE. In this case the EMM Cause value in the ATTACH REJECT message shall be

set to #19 "ESM failure"

If the attach request is rejected due to NAS level congestion control, the network

shall set the EMM cause value to #22 "congestion" and optionally assigns a back-off timer

T3346

Reference: 3GPP TS 24.301

Example: ATTACH REJECT Message

http://4.bp.blogspot.com/-G7-uD8AI9rA/Tskl82wT9bI/AAAAAAAADWM/Q-PUsFHtL_g/s1600/ATTACH+REJECT.PNG

Authentication Failure

In an EPS authentication challenge, the UE shall check the authenticity of the core network by

means of the AUTN parameter received in the AUTHENTICATION REQUEST message. This enables

the UE to detect a false network. The UE shall send AUTHENTICATION FAILURE message to

indicate the EPS authentication failure

As explained in the post AUTHENTICATION REQUEST, the AUTN parameter is formed by SQN, AK,

AMF, and MAC. There could be 3 possible causes for the authentication failure as explained below:

a) MAC code failure: If the UE finds that the MAC code supplied by the core network in the AUTN

parameter is invalid, then the UE shall send an AUTHENTICATION FAILURE message to the

network, with the EMM cause #20 "MAC failure". The network may initiate an identification

procedure to obtain the IMSI from the UE or may also decides to terminate the authentication

procedure

b) Non-EPS authentication unacceptable: If the UE finds that the "separation bit" in the AMF field of

AUTN supplied by the core network is 0, then the UE shall send an AUTHENTICATION FAILURE

message to the network, with the EMM cause #26 "non-EPS authentication unacceptable". The

network may initiate an identification procedure to obtain the IMSI from the UE or may also

decides to terminate the authentication procedure

c) SQN failure: If the UE finds that the SQN (supplied by the core network in the AUTN parameter) is

out of range, then the UE shall send an AUTHENTICATION FAILURE message to the network, with

the EMM cause #21 "synch failure". In this message, the UE should also include a re-

synchronization token AUTS provided by the USIM. By using this AUTS the network starts re-

synchronization procedure. The re-synchronization procedure requires the MME to delete all

unused authentication vectors for that IMSI and obtain new vectors from the HSS. Once the re-

synchronization is complete, the network shall initiate a new authentication procedure. Upon

receipt of two consecutive AUTHENTICATION FAILURE messages from the UE with EMM cause #21

"synch failure", the network may terminate the authentication procedure by sending an

AUTHENTICATION REJECT message

The only important IE in the AUTHENTICATION FAILURE message is authentication failure

parameter which is sent if and only if the EMM cause is #21 "synch failure". It shall include the

response to the authentication challenge from the USIM, which is made up of the AUTS parameter

Reference: 3GPP TS 24.301

Example1: AUTHENTICATION FAILURE – Synch failure

Example2: AUTHENTICATION FAILURE – MAC failure

Paging

Direction: E-UTRAN => UE

Signalling Radio Bearer: N/A

RLC Mode: TM

Logical Channel: PCCH

Transport Channel: PCH

E-UTRAN initiates the paging procedure by transmitting a PAGING message at

the UE's paging occasion as specified in TS 36.304. E-UTRAN may address multiple UEs

within a PAGING message by including one PagingRecord for each UE

In LTE, there is only one type of PAGING where as in the case of 3G-system,

Paging Type1 and Paging Type2 are defined

The PAGING message may be used to inform UEs in RRC_IDLE and

RRC_CONNECTED about a system information change. If the UE receives a PAGING

message including the systemInfoModification IE, it knows that the system

information will change at the next modification period boundary. The UE, if the

systemInfoModification is included, should re-acquire the required system information

using the system information acquisition procedure

The PAGING message may also be used to inform ETWS (Earthquake and

Tsunami Warning System) capable UEs in RRC_IDLE and UEs in RRC_CONNECTED about

presence of an ETWS primary notification and/or ETWS secondary notification. An

ETWS capable UE should re-acquire SIB10/SIB11 immediately if the etws-Indication is

included in the PAGING message

The PAGING message may also be used to inform CMAS (Commercial Mobile

Alert System) capable UEs in RRC_IDLE and UEs in RRC_CONNECTED about presence of

one or more CMAS notifications. A CMAS capable UE should re-acquire SIB12

immediately if the cmas-Indication is included in the PAGING message

The UE in RRC_IDLE validates each of the PagingRecord, if any, included in the

PAGING message. If the ue-Identity included in the PagingRecord matches one of the

UE identities allocated by upper layers, the ue-Identity and the cn-Domain are

forwarded to the upper layers

IEs in PAGING message:

CN-Domain: Indicates the origin of paging (ps or cs)

UE-Identity: Provides the NAS identity of the UE that is being paged (S-TMSI or IMSI)

SystemInfoModification: If present, this IE indicates a BCCH modification other than

SIB10, SIB11 and SIB12

etws-Indication: If present, this IE indicates an ETWS primary notification and/or

ETWS secondary notification

cmas-Indication: If present, this IE indicates a CMAS notification

Example1: PAGING message with only one paging record

Example2: PAGING message with notification of BCCH modification

http://3.bp.blogspot.com/-83nd-OVMu6U/TrWGx93l9JI/AAAAAAAADSY/kWjw7KTW66Q/s1600/Paging_SystemInfoModification.PNG