RRC Connection Request Direction: UE => E-UTRAN Signalling Radio Bearer: SRB0 RLC Mode: TM Logical Channel: CCCH

Transport Channel: UL-SCH

RRC CONNECTION REQUEST message is used to request the E-UTRAN for the establishment of an RRC connection. It is sent as part of the Random Access procedure. It is transferred using SRB0on the Common Control Channel (CCCH) because neither SRB1 nor a Dedicated Control Channel (DCCH) has been setup at this point. IEs in RRC CONNECTION REQUEST message are given below:

ue-Identity (Initial UE-Identity): This IE is included to facilitate contention resolution by lower layers. It can be either S-TMSI (40-bits) or a bit string of randomValue (40-bits). If the upper layers provide S-TMSI, then S-TMSI is used as the ue-Identity; else a random value in the range of 0 240-1 is drawn and used as the ue-Identity. Upper layers provide the S-TMSI if the UE is registered in the TA of the current cell establishmentCause:The main cause values and the corresponding NAS procedure whichtriggers the RRC connection establishment are presented below: emergency: This corresponds to NAS Procedure MO-CS fallback Emergency call mt-Access: Corresponding NAS procedures areService Request (paging response for PS domain) or Extended Service Request(MT-CS fallback) mo-Signalling: Corresponding NAS procedures are Attach, Detach, and TAU mo-Data: Corresponding NAS Procedures areService Request and Extended Service Request

RRC Connection Setup

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB0 RLC Mode: TM Logical Channel: CCCH Transport Channel: DL-SCH The RRC CONNECTION SETUP message is used to establish SRB1. It contains configuration information for SRB1. This allows subsequent signaling to use the DCCH logical channel. The configuration for SRB1 can be a specific configuration or the default configuration. The RRC CONNECTION SETUP message may also contain configuration for PUSCH, PUCCH, PDSCH channels and information regarding uplink power control, CQI reporting, the SRS, antenna configuration and scheduling requests

RRC Connection Setup Complete

Direction: UE => E-UTRAN Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: UL-SCH

The RRC CONNECTION SETUP COMPLETE message is used to confirm the successful completion of an RRC connection establishment. Some of the IEs in this message are explained below: selectedPLMN-Identity: This IE points to a PLMN-Id in the plmn-IdentityList of SIB1. The IE plmn-IdentityList is transmitted in SIB1 when the cell belong to more than one PLMN.The value of this IE equals to 1 if the 1st PLMN is selected from the plmn-IdentityList included in SIB1, 2 if the 2nd PLMN is selected from the plmn-IdentityList included in SIB1 and so on

registeredMME: This IE is optional, and is included when available. This is the identity of the MME with which the UE is (previously) registered with. If upper layers provide the 'Registered MME', then the IE registeredMME is set as follows: If the PLMN identity of the 'Registered MME' is different from the PLMN selected by the upper layers (selectedPLMN-Identity) then include the plmnIdentity in the registeredMME and set the mmegi and the mmecto the value received from upper layers dedicatedInfoNAS: This IE includes the initial NAS message from the UE

RRC Connection Reject

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB0 RLC Mode: TM Logical Channel: CCCH Transport Channel: DL-SCH The RRC CONNECTION REJECT message is used to reject the RRC connection establishment. This message includes the IE waitTime which can be in the range from 0 to 16 seconds. Optionally, the NW can include the IE extendedWaitTime for the purpose of Delay Tolerant access requests Upon receiving the RRC CONNECTION REJECT message, the UE should start timer T302, with the timer value set to waitTime. The UE is not allowed to send another RRCConnectionRequest for mobile originating calls, mobile originating signalling, mobile terminating access and mobile originating CS fallback on the same cell on which RRC CONNECTION REJECT is received until the expiry of T302 The following differences are noted as compared to UMTS RRC CONNECTION REJECT: 1. There is no RejectionCause in the case of LTE 2. RedirectionInfo which is used to redirect the UE to another frequency/RAT is not present in the case of LTE 3. LTE requires the higher layers to initiate new RRC CONNECTION REJECT after receiving RRC CONNECTION REJECT, where as in the case of UMTS, the procedure is repeated for N300 times

RRC: Security Mode Command

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: DL-SCH The SECURITY MODE COMMAND message is used to command the UE for the activation of AS security. EUTRAN always initiates this procedure prior to the establishment of Signalling Radio Bearer2 (SRB2) and Data Radio Bearers (DRBs). AS security comprises of the integrity protection of RRC signalling (SRBs) as well as the ciphering of RRC signalling (SRBs) and user plane data (DRBs). The integrity protection algorithm is common for signalling radio bearers SRB1 and SRB2. The ciphering algorithm is common for all radio bearers (i.e. SRB1, SRB2 and DRBs). Neither integrity protection nor ciphering applies for SRB0. The eNodeB sends integrity protected SECURITY MODE COMMAND message to the UE. The UE shall derive KeNB and KRRCint which is associated with integrity protection algorithm indicated in the SECURITY MODE COMMAND. Then, UE verifies the Integrity of the received SECURITY MODE COMMAND by checking the Message Authentication Code (MAC) in the SECURITY MODE COMMAND message. If the SECURITY MODE COMMANDmessage fails the integrity protection check, then the UE sends SECURITY MODE FAILURE to the eNodeB. If the SECURITY MODE COMMAND passes the integrity protection check, then the UE shall derive the encryption keys KRRCenc key and the KUPenc keys associated with the ciphering algorithm indicated in theSECURITY MODE COMMAND. The UE shall apply integrity protection using the indicated algorithm (EIA) and the integrity key, KRRCintimmediately, i.e. integrity protection shall be applied to all subsequent messages received and sent by the UE, including the SECURITY MODE COMPLETE message. The UE shall apply ciphering using the indicated algorithm (EEA), KRRCenc key and the KUPenc key after completing the procedure, i.e. ciphering shall be applied to all subsequent messages received and sent by the UE, except for the SECURITY MODE COMPLETE message which is sent un-ciphered.

RRC: Security Mode Complete

Direction: UE => E-UTRAN Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: UL-SCH The SECURITY MODE COMPLETE message is used to confirm the successful completion of a SECURITY MODE COMMAND.

The UE shall send SECURITY MODE COMPLETE message integrity protected but un-ciphered. i.e., the UE doesnt start ciphering in the uplink before it has sent the SECURITY MODE COMPLETE message to the eNodeB

RRC: Security Mode Failure

Direction: UE => E-UTRAN Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: UL-SCH The SECURITY MODE FAILURE message is used to indicate an unsuccessful completion of a SECURITY MODE COMMAND. i.e., if the SECURITY MODE COMMAND message fails the integrity protection check, then the UE sends SECURITY MODE FAILURE to the eNodeB Upon sending this message, the UE shall continue using the configuration used prior to the reception of theSECURITY MODE COMMAND message, i.e. neither applies integrity protection nor ciphering

UE Capability Enquiry
Direction: E-UTRAN => UE Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: DL-SCH The UE CAPABILITY ENQUIRY message is used to request the transfer of UE radio access capabilities forEUTRA as well as for other RATs (UTRA, GERAN-CS, GERAN-PS, and CDMA2000) As the UEs AS capability may contain several RATs capabilities, the information can be rather very large. To reduce the overhead in the air interface during transition from RRC_IDLE mode to RRC_CONNECTED mode, MME stores UE's AS capability and provides it to eNodeB during initial UE context setup over S1 interface. In case if the MME doesnt have the valid UE's AS capability, the MME does not provide UE's AS capability to theeNodeB. The eNobeB has to acquire UE's AS capability from UE using UE CAPABILITY ENQUIRY. NOTE: Change of the UE's GERAN UE radio capabilities in RRC_IDLE is supported by use of TRACKING AREA UPDATE This message contains only one IE as shown below; ue-CapabilityRequest: List of the RATs for which the UE is requested to transfer the UE radio access capabilities i.e. E-UTRA, UTRA, GERAN-CS, GERAN-PS, CDMA2000

UE Capability Information Direction: UE => E-UTRAN Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: UL-SCH
The UE CAPABILITY INFORMATION message is used to transfer of UE radio access capabilities requested by the E-UTRAN in UE CAPABILITY ENQUIRY. ueCapabilityRAT-Container is the container for the UE capabilities of the indicated RAT. The encoding is defined in the specification of each RAT. For E-UTRA, the encoding of UE capabilities is defined in the IE UE-EUTRA-Capability which is explained below
Some important parameters in UE-EUTRA-Capability IE are given below: accessStratumRelease: Set to Rel8, Rel9, Rel10 and so on (based on the UEs release) maxNumberROHC-ContextSessions: Set to the maximum number of concurrently active ROHC contexts supported by the UE. cs2 corresponds with 2 (context sessions), cs4 corresponds with 4 and so on ue-Category: As per Rel10, the possible values are 1 to 8 (Ref: TS 36.306) ue-TxAntennaSelectionSupported: TRUE indicates that the UE is capable of supporting UE transmit antenna selection as described in TS 36.213 halfDuplex: If halfDuplex is set to true, only half duplex operation is supported for the band, otherwise full duplex operation is supported. This entry is present in each of the supported bands bandListEUTRA: One entry corresponding to each supported E-UTRA band listed in the same order as insupportedBandListEUTRA interFreqBandList: One entry corresponding to each supported E-UTRA band listed in the same order as insupportedBandListEUTRA interFreqNeedForGaps: Indicates need for measurement gaps when operating on the E-UTRA band given by the entry in bandListEUTRA and measuring on the E-UTRA band given by the entry in interFreqBandList interRAT-BandList: One entry corresponding to each supported band of another RAT listed in the same order as in the interRAT-Parameters interRAT-NeedForGaps: Indicates need for DL measurement gaps when operating on the E-UTRA band given by the entry in bandListEUTRA and measuring on the inter-RAT band given by the entry in the interRAT-BandList SupportedBandUTRA-FDD: UTRA band as defined in TS 25.101 SupportedBandGERAN: GERAN band as defined in TS 45.005

RRC Connection Reconfiguration

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: DL-SCH

RRC CONNECTION RECONFIGURATION message is the command to modify an RRC connection. The purpose of this procedure is, To establish/modify/release Radio Bearers To perform Handover To setup/modify/release Measurements To add/modify/release SCells Dedicated NAS Information might also be transferred from eNodeB to UE Differences with 3G system's radio resource configuration procedure: In LTE, RRC CONNECTION RECONFIGURATION is the only message used to perform all logical, transport, and physical channel configurations where as in case UMTS, there exists Transport Channel, Physical Channel and Radio Bearer Reconfiguration messages In LTE, RRC CONNECTION RECONFIGURATION can also be used to send NASdedicated signalling to the UE to reduce the latency whereas this option is not available in 3G LTE has only one RRC connected mode state (RRC_CONNECTED), so it has only one Temporary Radio Network Temporary Identity (RNTI) i.e. C-RNTI In 3G, MEASUREMENT CONTROL is used to setup/modify/release measurements where as in LTE, RRCCONNECTION RECONFIGURATION message is the only message for this purpose E-UTRAN includes the mobilityControlInfo (Handover) only when AS-security has been activated, andSRB2 with at least one DRB are setup but not suspended. The establishment of RBs (other than SRB1, which is established during RRC connection establishment) is included only when AS-security has been activated If the UE is unable to comply with (part of) the configuration included in the RRC CONNECTIONRECONFIGURATION message, the UE shall continue using the configuration used prior to the reception of RRCCONNECTION RECONFIGURATION message. If the security has not been activated, UE should leaveRRC_CONNECTED state, else, UE initiates the connection re-establishment procedure which is used to resumeSRB1 operation and to reactivate security

RRC Connection Reconfiguration Complete

Direction: UE => E-UTRAN Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: UL-SCH

The RRC CONNECTION RECONFIGURATION COMPLETE message is used to confirm the successful completion of an RRC CONNECTION RECONFIGURATION

RRC Connection Reestablishment Request

The purpose of RRC CONNECTION RE-ESTABLISHMENT procedure is to re-establish the RRC connection, which involves the resumption of SRB1 operation and the re-activation of security (without changing algorithms). The UE shall only initiate this procedure when AS security has been activated. The connection re-establishment succeeds only if the concerned cell is prepared i.e. has a valid UE context. In case E-UTRAN accepts the re-establishment, SRB1 operation resumes while the operation of other radio bearers remains suspended. If AS security has not been activated, the UE doesnt initiate this procedure, instead, it moves to RRC_IDLE directly The UE initiates the RRC CONNECTION RE-ESTABLISHMENT procedure when one of the following conditions is met: Upon detecting radio link failure; or Upon handover failure; or Upon mobility from E-UTRA failure; or Upon integrity check failure indication from lower layers; or Upon an RRC CONNECTION RECONFIGURATION failure

RRC Connection Reestablishment Request Message

Direction: UE => E-UTRAN Signalling Radio Bearer: SRB0 RLC Mode: TM

Logical Channel: CCCH Transport Channel: UL-SCH IEs in RRC CONNECTION REESTABLISHMENT REQUEST message are given below: ue-Identity: UE identity is included to retrieve UE context and to facilitate contention resolution by lower layers. The UE Identity shall be set as follows: 1. Set the C-RNTI to the C-RNTI used in the source PCell (In case of handover and mobility from E-UTRA failure) or used in the PCell in which the trigger for the re-establishment occurred (other cases); 2. Set the physCellId to the physical cell identity of the source PCell (handover and mobility from E-UTRA failure) or of the PCell in which the trigger for the re-establishment occurred (other cases); 3. Set the shortMAC-I to the 16 least significant bits of the calculated MAC-I reestablishmentCause: This IE indicates the failure cause that triggered the re-establishment procedure and shall be set as follows: 1. If the re-establishment procedure was initiated due to reconfiguration failure (the UE is unable to comply with the reconfiguration sent in RRC CONNECTION RECONFIGURATION), then set thereestablishmentCause to the value 'reconfigurationFailure'; 2. If the re-establishment procedure was initiated due to handover failure (intra-LTE handover failure or inter-RAT mobility from EUTRA failure) then, set the reestablishmentCause to the value 'handoverFailure' 3. Set the reestablishmentCause to the value 'otherFailure' if the re-establishment procedure was triggered due other causes than indicated in cases 1 and 2

RRC Connection Reestablishment

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB0 RLC Mode: TM Logical Channel: CCCH Transport Channel: DL-SCH The purpose of this procedure is to re-establish the RRC connection, which involves the resumption ofSRB1, the re-activation of security and the configuration of only the PCell The RRC CONNECTION REESTABLISHMENT message is used to resolve contention and to re-establishSRB1. Since this message is used to resume SRB1, it is similar to RRCCONNECTION SETUP See RRC CONNECTION REESTABLISHMENT REQUEST for more information on RRC Reestablishment procedure

RRC Connection Reestablishment Complete

Direction: UE => E-UTRAN Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: UL-SCH The RRC CONNECTION REESTABLISHMENT COMPLETE message is used to confirm the successful completion of anRRC connection reestablishment After receiving RRC CONNECTION REESTABLISHMENT message, the SRB1 operation is resumed. The RRC CONNECTION REESTABLISHMENT COMPLETE message and all the subsequent messages are (sent) ciphered and integrity protected using previously configured (respective) algorithms and newly derived keys KRRCenc andKRRCint respectively.

RRC Connection Reestablishment Reject

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB0 RLC Mode: TM Logical Channel: CCCH Transport Channel: DL-SCH The RRC CONNECTION REESTABLISHMENT REJECT message is used to indicate the rejection of an RRC CONNECTION REESTABLISHMENT REQUEST. Upon receiving the RRC CONNECTION REESTABLISHMENT REJECT message, the UE shall leave RRC_CONNECTED state with release cause 'RRC connection failure'

Mobility from E-UTRA Command

E-UTRAN initiates the 'mobility from E-UTRA' procedure to a UE in RRC_CONNECTED state. TheeNodeB sends MOBILITY FROM EUTRA COMMAND possibly in response to a 'Measurement Report' message from the UE or in response to reception of 'CS fallback indication' for the UE from MME. This procedure is initiated only when AS-security has been activated. The purpose of this procedure is to move a UE from E-UTRAN to a cell using another RAT, e.g. GERAN,UTRA or CDMA2000 systems. The mobility from E-UTRA procedure covers the following types of mobility: Handover, i.e. the MOBILITY FROM EUTRA COMMAND message includes radio resources that have been allocated for the UE in the target cell Cell Change Order, i.e. the MOBILITY FROM EUTRA COMMAND message may include information facilitating access of and/or connection establishment in the target cell, e.g. system information. Cell change order is applicable only to GERAN Enhanced CS fallback to CDMA2000 1xRTT, i.e. the MOBILITY FROM EUTRA COMMAND message includes radio resources that have been allocated for the UE in the target cell MOBILITY FROM EUTRA COMMAND message

1. 2.

3.

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: DL-SCH Some of the IEs in MOBILITY FROM EUTRA COMMAND message are described below: cs-FallbackIndicator: Indicates if the CS Fallback procedure to UTRAN or GERAN is triggered Purpose: Indicates which type of mobility procedure the UE is requested to perform (Handover, CCO, eCSFBetc) TargetRAT-Type: This IE indicates the target RAT type (utra, geran, cdma2000-1XRTT, cdma2000-HRPD) TargetRAT-MessageContainer: This field contains a message specified in another standard, as indicated by the targetRAT-Type. It carries information about the target cell identifier(s) and radio parameters relevant for the target RAT. This means that the actual handover command message is built by the target RAT and is sent to the source eNodeB. The source eNodB includes this actual handover command in the MOBILITY FROM EUTRA COMMAND CarrierFreq: Contains the carrier frequency of the target GERAN cell SystemInfoListGERAN: If the IE purpose is CCO and if this field is not present, the UE has to acquire SI/PSI from the GERAN cell Mobility from E-UTRA failure Either of the following condition is treated as Mobility from E-UTRA failure T304 expiry (mobility from E-UTRA failure) If the UE does not succeed in establishing the connection to the target RAT If the UE is unable to comply with (part of) the configuration included in theMobilityFromEUTRACommand message If there is a protocol error in the inter RAT information included in the MobilityFromEUTRACommandmessage, causing the UE to fail the procedure according to the specifications applicable for the target RAT If the criteria for Mobility from E-UTRA failure is met,then the UE should stop T304, if running and act as below: If the cs-FallbackIndicator in the MobilityFromEUTRACommand message was set to 'TRUE', indicate to upper layers that the CS Fallback procedure has failed Revert back to the configuration used in the source cell, excluding the configuration configured by thephysicalConfigDedicated, mac-MainConfig and sps-Config Initiate the connection re-establishment procedure

Measurement Report
Direction: UE => E-UTRAN Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: UL-SCH The UE reports measurement information in accordance with the measurement configuration as provided by EUTRAN. E-UTRAN provides the measurement configuration applicable for a UE in RRC_CONNECTED by means of dedicated signalling, i.e. using the RRC CONNECTION RECONFIGURATION message The UE can be requested to perform the following types of measurements:

Intra-frequency measurements: Measurements at the downlink carrier frequency (ies) of the serving cell(s). Inter-frequency measurements: Measurements at frequencies that differ from any of the downlink carrier frequency (ies) of the serving cell(s). Inter-RAT measurements of UTRA frequencies or of GERAN frequencies or of CDMA2000 HRPD orCDMA2000 1xRTT frequencies

UL Information Transfer
Direction: UE => E-UTRAN Signalling Radio Bearer: SRB1 or SRB2 RLC Mode: AM Logical Channel: DCCH Transport Channel: UL-SCH A UE in RRC_CONNECTED state initiates the UL INFORMATION TRANSFER whenever there is a need to transfer NAS or non-3GPP dedicated information, except at RRC connection establishment in which case the NAS information is piggybacked to the RRC CONNECTION SETUP COMPLETE message The UL INFORMATION TRANSFER procedure is almost similar to UPLINK DIRECT TRANSFER procedure in 3G-RNC Either SRB2 or SRB1 (only if SRB2 not established yet) is used for this purpose. If SRB2 is suspended, the UE does not send this message until SRB2 is resumed. When CDMA2000 information has to be transferred, the UE shall initiate the procedure only if SRB2 is established

The IE dedicatedInfoType shall carry dedicatedInfoNAS or dedicatedInfoCDMA2000-1XRTT (in case ofCDMA2000 1XRTT information) or dedicatedInfoCDMA2000-HRPD (in case of CDMA2000 HRPD information)

DL Information Transfer
Direction: E-UTRAN => UE Signalling Radio Bearer: SRB2 or SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: DL-SCH E-UTRAN initiates the DL information transfer procedure whenever there is a need to transfer NAS or non3GPP dedicated information. E-UTRAN initiates the DL information transfer procedure by sending the DL INFORMATION TRANSFER message Either SRB2 or SRB1 (only if SRB2 not established yet) is used. If SRB2 is suspended, E-UTRAN does not send this message until SRB2 is resumed DL INFORMATION TRANSFER procedure is almost similar to DOWNLINK DIRECT TRANSFER procedure in 3G-RNC The IE dedicatedInfoType shall carry dedicatedInfoNAS or dedicatedInfoCDMA2000-1XRTT (in case ofCDMA2000 1XRTT information) or dedicatedInfoCDMA2000-HRPD (in case of CDMA2000 HRPD information)

RRC Connection Release

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: DL-SCH The RRC CONNECTION RELEASE message is used to command the release of an RRC connection. E-UTRAN initiates the RRC connection release procedure to an UE in RRC_CONNECTED state The RRC CONNECTION RELEASE procedure with redirection information can also be used for CS-fallbackto GERAN or UTRAN The RRC CONNECTION RELEASE procedure can also be used for MME load balancing. If an MME feels overloaded, it can simply move the calls to other MME in the MME pool. The source MME releases the S1 connections of the UE towards the eNodeB asking the UE to perform a load balancing TAU. Then the eNodeBsends RRC CONNECTION RELEASE message to the UE with cause load balancing TAU required'. After receiving this message, the UE initiates Tracking Area Updating procedure which is redirected to another MME The eNodeB may provide a cell reselection priority for each frequency, by means of separate lists for each RAT (including E-UTRA) in the RRC CONNECTION RELEASE message There is no RRC CONNECTION RELEASE COMPLETE message defined in LTE. So, UE leaves RRC_CONNECTED state without transmitting RRC CONNECTION RELEASE COMPLETE message Some of the IEs in RRC CONNECTION RELEASE message ReleaseCause: The IE releaseCause is used to indicates the reason for releasing the RRC Connection(Ex:- loadBalancingTAUrequired, cs-FallbackHighPriority, or other) RedirectedCarrierInfo: The redirectedCarrierInfo indicates a carrier frequency which is used to redirect the UE to an E-UTRA or an inter-RAT carrier frequency IdleModeMobilityControlInfo: This IE provides dedicated cell reselection priorities. FreqPriorityListX: Provides a cell reselection priority for each frequency, by means of separate lists for each RAT (including E-UTRA) SystemInformation: Container for system information of the GERAN cell. Each OCTET STRING in SystemInfoListGERAN contains one complete System Information (SI) message as defined in TS 44.018 cellInfoList: Used to provide system information of one or more cells on the redirected inter-RAT carrier frequency. The system information can be used if, upon redirection, the UE selects an inter-RAT cell indicated by the physCellId and carrierFreq (GERAN) or by the physCellId (other RATs). utra-BCCH-Container: Contains System Information Container message as defined in TS 25.331

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 onePagingRecord 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 thesystemInfoModification 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 theueIdentity included in the PagingRecord matches one of the UE identities allocated by upper layers, the ueIdentity 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

Master Information Block

Direction: E-UTRAN => UE Signalling Radio Bearer: N/A RLC Mode: TM Logical Channel: BCCH Transport Channel: BCH The MASTER INFORMATION BLOCK (MIB) includes a limited number of most essential and most frequently transmitted parameters that are needed to acquire other information from the cell. The MIB is transmitted onBCH while all other SYSTEM INFORMATION messages are transmitted on DL-SCH As MIB is the most important information block, it is transmitted more frequently with a fixed scheduling. The MIB uses a periodicity of 40ms and repetitions made within 40ms. The first transmission of the MIB is scheduled in subframe #0 of radio frames for which the SFNmod4 = 0, and repetitions are scheduled in subframe #0 of all other radio frames The MIB contains DL bandwidth of the cell, PHICH configuration and the System Frame Number (SFN) IEs in the MASTER INFORMATION BLOCK message dl-Bandwidth: Transmission bandwidth configuration, nRB in downlink. The value n6 corresponds to 6 resource blocks, n15 to 15 resource blocks and so on. Possible values are n6, n15, n25, n50, n75, and n100. Table1 below gives the corresponding mapping to the actual channel bandwidth (Reference: 3GPP TS 36.101) systemFrameNumber: Defines the 8 most significant bits of the SFN phich-Config: This IE is used to specify the PHICH configuration

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 byschedulingInfoList 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

System Information Block Type 3 Direction: E-UTRAN => UE Signalling Radio Bearer: N/A RLC Mode: TM Logical Channel: BCCH Transport Channel: DL-SCH
The SystemInformationBlockType3 (SIB3) contains cell re-selection information common for intra-frequency, inter-frequency and/or inter-RAT cell re-selection (i.e. applicable for more than one type of cell re-selection but not necessarily all) SIB3 also contains cell reselection priority information for the concerned carrier frequency or a set of frequencies System Information Block Type 4 Direction: E-UTRAN => UE Signalling Radio Bearer: N/A RLC Mode: TM Logical Channel: BCCH Transport Channel: DL-SCH The SystemInformationBlockType4 (SIB4) contains intra-frequency neighboring cell information for intra-LTE intra-frequency cell reselection, such as neighbor cell list, and black listed Cell list

System Information Block Type 5

Direction: E-UTRAN => UE Signalling Radio Bearer: N/A RLC Mode: TM Logical Channel: BCCH Transport Channel: DL-SCH The SystemInformationBlockType5 (SIB5) contains neighbor cell related information for inter-frequency cell-reselection i.e. the information about neighbor EUTRA frequencies SIB5 includes neighbor cell list, carrier frequency, cell reselection priority, threshold used by the UE when reselecting a higher/lower priority frequency than the current serving frequency etc. It also contains a list of blacklisted inter-frequency neighbouring cells

Attach Request

The UE includes ATTACH REQUEST (initial-NAS) message within RRC CONNECTION SETUP COMPLETE message. The IE dedicatedInfoNAS in RRC CONNECTION SETUP COMPLETEincludes 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 IMEIshall 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)

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 REQUESTmessage 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

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

Attach Complete
The ATTACH COMPLETE message is sent by the UE to the network in response to anATTACH ACCEPT message When the UE receives the ATTACH ACCEPT message combined with the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, it shall forward the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to the ESM sublayer. Once the ESM sublayer indicates that the default EPS bearer context has been activated, the UE shall

send an ATTACH COMPLETE message together with an ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPTmessage contained in the ESM message container IE to the network If the ACTIVATE DEFAULT BEARER CONTEXT REQUEST message combined with theATTACH ACCEPT is not accepted by the UE due to failure in the UE's ESM sublayer, then the UE shall not send ATTACH COMPLETE message. Instead, it shall initiate the detach procedure by sending a DETACH REQUEST message to the network. Further UE's behavior is implementation specific

Tracking Area Update Request

The TRACKING AREA UPDATING (TAU) procedure is always initiated by the UE and is used for (some of) the following purposes: Normal TAU: When the UE enters a tracking area that is not in the list of tracking areas that the UE previously registered in the MME Combined TAU: When a UE operating in 'CS/PS mode 1' or 'CS/PS mode 2' enters a tracking area that is not in the list of tracking areas that the UE previously registered in the MME Periodic TAU: Upon the expiry of timer T3412, periodic TAU procedure is initiated to periodically notify the availability of the UE to the network IMSI attach for non-EPS services when the UE is attached for EPS services. This procedure is used by a UE in 'CS/PS mode 1' or 'CS/PS mode 2' of operation In various cases of inter-system change from Iu mode to S1 mode or from A/Gb mode to S1 mode or from S101 mode to S1 mode MME load balancing: When the UE receives RRC CONNECTION RELEASE message with cause load balancing TAU required', it initiates TAU procedure To update certain UE specific parameters in the network (ex:- when the UE changes the UE network capability information or the MS network capability information or the UE specific DRX parameter etc...) The UE initiates the TAU procedure by sending TRACKING AREA UPDATE REQUESTmessage. The IEs (some of them are explained below) in this message

include EPS update type, NAS key set identifier, Old GUTI, GPRS ciphering key sequence number, Old P-TMSI signature, Additional GUTI, UE network capability, Last visited registered TAI, DRX parameter, UE radio capability information update needed, EPS bearer context status, MS network capability, Old location area identification, Supported Codecs, Additional update type, Voice domain preference and UE's usage setting, Device properties etc In the IE EPS update type the first 3 bits (LSBs) shall be used to indicate update type (ex:- TA updating or combined TA/LA updating or combined TA/LA updating with IMSI attach or periodic updating). Additionally, if a UE has uplink user data pending when it initiates the TAU procedure or uplink signalling not related to the TAU procedure, it may also set an "active" flag (bit4) in this IE to indicate the request to establish the user plane to the network and to keep the NAS signalling connection after the completion of the TAU procedure The IE Old GUTI shall be handled as follows: UEs supporting A/Gb mode or Iu mode or both: If TIN = "P-TMSI" and the UE holds a valid P-TMSI and RAI, the UE shall map the P-TMSI and RAI into the Old GUTI IE, and include Old GUTI type IE with GUTI type set to "mapped GUTI". Additionally, if the UE holds a valid GUTI, then it shall be indicated in the IE Additional GUTI If TIN = GUTI or RAT-related TMSI and the UE holds a valid GUTI, the UE shall indicate the GUTI in the Old GUTI IE, and include Old GUTI type IE with GUTI type set to "native GUTI" UEs not supporting A/Gb mode or Iu mode: The UE shall include a valid GUTI in the Old GUTI IE. In addition, the UE shall include Old GUTI type IE with GUTI type set to "native GUTI" The IE Additional Update Type provides additional information about the type of request for a TAU 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) The purpose of the Device properties IE is to indicate if the MS is configured for NAS signalling low priority. The network uses the Device properties IE for corenetwork congestion handling and for charging purposes. This IE can indicate MS is not configured for NAS signalling low priority or MS is configured for NAS signalling low priority

GUTI

The Globally Unique Temporary UE Identity (GUTI) provides an unambiguous identification of the UE that does not reveal the UE or the user's permanent identity in the EPS The GUTI also allows the identification of the MME and the network. It can be used by the network and the UE to establish the UE's identity during signalling between them in the EPS. The GUTI has two main components as explained below: one that uniquely identifies the MME which allocated the GUTI (GUMMEI) one that uniquely identifies the UE within the MME that allocated the GUTI (M-TMSI)
The MME allocates GUTI by initiating GUTI reallocation procedure or it can also be implicitly reallocated during attach or tracking area updating procedures. Normally, the GUTI reallocation will take place in conjunction with another mobility management procedure, e.g. as part of tracking area updating

Globally Unique MME Identifier (GUMMEI) shall be constructed from the MCC, MNC and MME Identifier (MMEI). The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME Code (MMEC). The structure of the GUTI is illustrated in the figure below

Authentication Request The purpose of the EPS authentication and key agreement (AKA) procedure is to provide mutual
authentication between the user and the network and to agree on a key KASME

The EPS AKA procedure is always initiated and controlled by the network. However, the UE can
reject the EPS authentication challenge sent by the network. The UE shall proceed with an EPS authentication challenge only if an USIM is present

 When a NAS signalling connection exists, the network can initiate an authentication procedure at
any time. The network initiates the authentication procedure by sending an AUTHENTICATION REQUEST message to the UE

The MME sends unciphered AUTHENTICATION REQUEST message to the UE which includes a random
number RAND and an authentication parameter AUTN. Now the UEs job is to compute the authentication response parameter RES and send it back to the MME in AUTHENTICATION RESPONSE message

The value of RES is computed by the USIM using RAND, AUTN and the secret key K which is
stored in the USIM.

The IE Authentication parameter RAND (EPS challenge) will carry the RAND of length 128-bits. It
provides the MS with a non-predictable number to be used to calculate the authentication response parameter RES

The IE Authentication parameter AUTN (EPS challenge) will carry the AUTN of length 128-bits. It
provides the MS with a means of authenticating the network. The AUTN consists of (SQN xor AK)|| AMF||MAC = 48 + 16 + 64 = 128-bits. In the AUTHENTICATION REQUEST example below,AUTN value =
6e323b36c46c5555a3df0e6e323b6391 which means that,

SQN xor AK = 6e323b36c46c AMF: 5555 MAC: a3df0e6e323b6391 Abbreviations: AMF Authentication Management Field AK Anonymity Key ASME Access Security Management Entity AUTN Authentication Token MAC Message Authentication Code RAND RANDom number SQN Sequence Number
Reference: 3GPP TS 24.301

Authentication Response
The UE processes the authentication challenge data received in AUTHENTICATION
REQUESTmessage (RAND and AUTN) and responds with an AUTHENTICATION RESPONSE message in order to
deliver a calculated authentication response RES to the network

In an EPS authentication challenge, the response calculated in the USIM (RES) is minimum 4 octets
and may be up to 16 octets in length. The RES is included in the IE Authentication response parameter in the AUTHENTICATION RESPONSE message

Upon receipt of an AUTHENTICATION RESPONSE message the MME compares the received RES value with the XRES (Expected Response) value. If RES == XRES, then the network considers that the UE has successfully authenticated itself to the network If the AUTHENTICATION RESPONSE returned by the UE is not valid (RES != XRES), the network response depends upon the type of identity used by the UE in the initial NAS message (if GUTI was used or IMSI was used) as explained below: If the GUTI was used, the network should initiate an identification procedure. If the IMSI given by the UE during the identification procedure differs from the IMSI the network had associated with the GUTI, the authentication should be restarted with the correct parameters. Otherwise, if the IMSI provided by the UE is the same as the IMSI stored in the network (i.e.authentication has really failed), the network should sends AUTHENTICATION REJECTmessage to the UE If the IMSI was used for identification in the initial NAS message, or the network decides not to initiate the identification procedure after an unsuccessful authentication procedure, the network should send an AUTHENTICATION REJECT message to the UE

Reference: 3GPP TS 24.301

Authentication Reject

Upon receipt of an AUTHENTICATION RESPONSE message the MME compares the received RESvalue with the XRES (Expected Response) value. If RES == XRES, then the network considers that the UE has successfully authenticated itself to the network If the AUTHENTICATION RESPONSE returned by the UE is not valid i.e. RES != XRES, then the network response depends upon the type of identity used by the UE in the initial NAS message as explained below:

If the GUTI was used, the network should initiate an identification procedure to obtain IMSI from the UE. If the IMSI given by the UE during the identification procedure differs from the IMSI the network had associated with the GUTI, the authentication should be restarted with the correct parameters. Otherwise, if the IMSI provided by the UE is the same as the IMSI stored in the network (i.e. authentication has really failed), the network should sendsAUTHENTICATION REJECT message to the UE If the IMSI was used for identification in the initial NAS message, or the network decides not to initiate the identification procedure after an unsuccessful authentication procedure, the network should send an AUTHENTICATION REJECT message to the UE Upon receipt of an AUTHENTICATION REJECT message, the UE shall abort any EMM signalling procedure and enter state EMM-DEREGISTERED. Also, the UE shall set the update status to EU3 ROAMING NOT ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSIASME. The USIM shall be considered as invalid until switching off the UE or the UICC containing the USIM is removed Additionally, If A/Gb or Iu mode is supported by the UE, it shall handle MM/GMM states and parameters as explained in 3GPP TS 24.008 section 4.7.4.5

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: theAUTN 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

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

b) Non-EPS authentication unacceptable: If the UE finds that the "separation bit" in the AMFfield
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 resynchronization token AUTS provided by the USIM. By using this AUTS the network starts resynchronization 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 resynchronization 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

NAS: Security Mode Command The purpose of the NAS security mode control procedure is to take an EPS security context into
use, and initialize and start NAS signalling security between the UE and the MME. The MME starts this procedure by sending SECURITY MODE COMMAND message

The MME may send a SECURITY MODE COMMAND in order to change the NAS security algorithms for a current EPS security context already in use The MME shall send the SECURITY MODE COMMAND message unciphered, but shall integrity protect the message with the NAS integrity key based on KASME or mapped K'ASME indicated by theeKSI included in the message

The MME shall set the security header type of the message to "integrity protected with new EPS
security context" since this message is only integrity protected but not ciphered

The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to NAS, RRC and UP (user plane) ciphering etc...) The MME shall include the replayed nonceUE if the UE included it in initial L3 message to the network Also, the MME shall send the selected NAS ciphering and integrity algorithms and the NAS Key Set Identifier (eKSI) in the SECURITY MODE COMMAND message The MME shall include both the nonceMME and the nonceUE when creating a mapped EPS security context during inter-system change from A/Gb mode to S1 mode or Iu mode to S1 mode in EMMIDLE mode Additionally, the MME may request the UE to send its IMEISV in the SECURITY MODE COMPLETEmessage The UE shall derive KNASenc and KNASint keys from the key KASME/K'ASME and the received EPS encryption and
integrity algorithms (respectively)

Reference: 3GPP TS 24.301

Request

The identification procedure is used by the network to request a particular UE to provide specific identification parameters, e.g. IMSI, IMEI etc The network initiates the identification procedure by sending an IDENTITY REQUEST message to the UE. The type of the identity is requested in the IE Identity Type 2 The MME can send an IDENTITY REQUEST message to an UE at any time while the UE is in EMMCONNECTED mode and the UE shall be ready to respond to an IDENTITY REQUEST message at any time whilst in EMM-CONNECTED mode

Identity

After receiving the IDENTITY REQUEST message the UE shall respond with an IDENTITY RESPONSEmessage to the network. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network If the network doesnt receive IDENTITY RESPONSE message before the expiry of T3470, it shall retransmit the IDENTITY REQUEST message and reset/restart the timer T3470. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3470, the network shall abort theidentification procedure and any ongoing EMM procedure

Reference: 3GPP TS 24.301

Identity Response

After receiving the IDENTITY REQUEST message, the UE shall send an IDENTITY RESPONSE message to the network. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network The UE shall include the requested identity in the IE Mobile Identity in the IDENTITY RESPONSEmessage If the UE cannot encode the requested identity in the IDENTITY RESPONSE message, e.g. because no valid USIM is available, then it shall encode the identity type as "no identity"
Reference: 3GPP TS 24.301

Service Request

The SERVICE REQUEST message is sent by the UE to the network to request the establishment of a NAS signalling connection and of the radio and S1 bearers

The UE shall send the SERVICE REQUEST message when:

a) The UE in EMM-IDLE mode receives a paging request with CN domain indicator set to "PS" from the network b) The UE, in EMM-IDLE mode, has pending user data to be sent c) The UE, in EMM-IDLE mode, has uplink signalling pending d) The UE, in EMM-IDLE mode, has uplink cdma2000 signalling pending to be transmitted over E-UTRAN e) The UE performs an inter-system change from S101 mode to S1 mode and has user data pending

For the above cases, if the UE is not configured for NAS signalling low priority, the UE initiates the service request procedure by sending a SERVICE REQUEST message to the MME For the above cases, if the UE is configured for NAS signalling low priority, but the network doesnt support EXTENEDED SERVICE REQUEST for packet services, the UE shall send SERVICE REQUEST message to the MME Upon receipt of the SERVICE REQUEST message, the MME may initiate the EMM common procedures e.g. the authentication procedure and security mode control procedure The UE shall treat that the service request procedure as successful, when the lower layers indicate that the user plane radio bearer is successfully set up The structure of SERVICE REQUEST message doesnt follow the structure of standard L3 message (see the example below) The IE KSI and sequence numbers purpose is to provide the network with the key set identifier(KSI) value of the current EPS security context and the short sequence number (5 LSBs of the NAS COUNT value) applicable for the message that includes this IE

The purpose of the Short MAC IE is to protect the integrity of a SERVICE REQUEST message. This field contains the 2 least significant octets of the MAC calculated for the SERVICE REQUESTmessage
Reference: 3GPP TS 24.301

Extended Service Request The EXTENEDED SERVICE REQUEST message is sent by the UE to the network to initiate a "CS
fallback or 1xCS fallback call" or respond to an "MT CS fallback or 1xCS fallback" request from the network

This message is also used if the UE wants to request the establishment of a NAS signalling connection (and of the radio and S1 bearers) for packet services and if the UE needs to provideadditional information that cannot be provided via a SERVICE REQUEST message

The UE shall send EXTENEDED SERVICE REQUEST message when:

a) The UE in EMM-IDLE mode receives a paging request with CN domain indicator set to "PS" from the network b) The UE, in EMM-IDLE mode, has pending user data to be sent c) The UE, in EMM-IDLE mode, has uplink signalling pending d) The UE in EMM-IDLE or EMM-CONNECTED mode is configured to use CS fallback and has a mobile originating CS fallback request from the upper layer e) The UE in EMM-IDLE mode is configured to use CS fallback and receives a paging request with CN domain indicator set to "CS", or the UE in EMM-CONNECTED mode is configured to use CS fallback and receives a CS SERVICE NOTIFICATION message f) The UE in EMM-IDLE or EMM-CONNECTED mode is configured to use 1xCS fallback and has a mobile originating 1xCS fallback request from the upper layer

g) The UE in EMM-CONNECTED mode is configured to use 1xCS fallback and accepts cdma2000signalling messages containing a 1xCS paging request received over E-UTRAN h) The UE, in EMM-IDLE mode, has uplink cdma2000 signalling pending to be transmitted over EUTRAN i) The UE, in EMM-IDLE or EMM-CONNECTED mode, is configured to use 1xCS fallback, acceptscdma2000 signalling messages containing a 1xCS paging request received over cdma20001xRTT, and the network supports dual Rx CSFB or provide CS fallback registration parameters The UE, in EMM-IDLE or EMM-CONNECTED mode, has uplink cdma2000 signalling pending to be transmitted over cdma2000 1xRTT, and the network supports dual Rx CSFB or provide CS fallback registration parameters NOTE: For cases a, b, c, h and k above, the EXTENEDED SERVICE REQUEST message is used only if the UE is configured for NAS signalling low priority and the network supports EXTENEDED SERVICE REQUEST for packet services. Otherwise, SERVICEREQUEST is used

j)

k) The UE performs an inter-system change from S101 mode to S1 mode and has user data pending

Upon receipt of the EXTENDED SERVICE REQUEST message, the MME may initiate the EMM common procedures e.g. the authentication procedure and security mode control procedure The Service type IE specifies the purpose of the service request procedure. This IE can indicate mobile originating CS fallback or 1xCS fallback or mobile terminating CS fallback or 1xCS fallback or mobile originating CS fallback emergency call or 1xCS fallback emergency call, or packet services via S1 The purpose of the CSFB response IE is to indicate whether the UE accepts or rejects a paging forCSFB. The IEs values could be either CS fallback rejected by the UE or CS fallback accepted by the UE (see example2 below) The IE EPS bearer context status shall be included if the UE wants to indicate the EPS bearer contexts that are active within the UE The UE shall include the IE Device properties if the UE is configured for NAS signalling low priority. The network uses this IE for core-network congestion handling and for charging purposes
Reference: 3GPP TS 24.301

NAS Level Congestion Control

When the network detects EMM signalling congestion, it may perform NAS level congestion control. The NAS level congestion control consists of general NAS level mobility management control andsubscribed APN based congestion control Under general overload conditions the network may reject mobility management signalling requests from UEs. The network should not reject requests for emergency bearer services and requests from high priority users

When general NAS level mobility management control is active, the network may prioritize
rejecting messages that has the NAS signalling low priority indicator before rejecting messages without the NAS signalling low priority indicator

When the NAS level congestion control is active in mobility management, the network may include a
value for the back-off timer (T3346) in the reject messages

If the UE enters a new PLMN which is not in the list of equivalent PLMNs, it shall stop
timer T3346when initiating mobility management procedures in the new PLMN

When subscribed APN based congestion control is active for a particular APN, the network may
reject attach request from UEs with a subscription to this APN

A UE configured for NAS signalling low priority indicates this by including the Device properties IE
in the appropriate NAS message and setting the low priority indicator to "MS is configured for NAS signalling low priority"

The UE shall set the low priority indicator to "MS is not configured for NAS signalling low priority"
for the following cases The UE has a PDN connection for emergency bearer services established or is establishing a PDN connection for emergency bearer services The UE is accessing the network with access class 11 15 The UE responds to paging

Service Reject

If the SERVICE REQUEST or EXTENDED SERVICE REQUEST cannot be accepted by the network, then the network shall send SERVICE REJECT message to the UE The MME shall specify an appropriate cause for rejecting the service request from the UE in the IEEMM cause When the EMM cause value is #39 "CS service temporarily not available", the MME shall include a value for timer T3442 in the SERVICE REJECT message (as shown in Example1 below). The UE shall not try to send an EXTENDED SERVICE REQUEST message for MO services to the network, except for MO CS fallback for emergency calls, until timer T3442 expires If the service request for MO services is rejected due to NAS Level Congestion Control, the network shall set the EMM cause value to #22 "congestion" and assign a back-off timer T3346
Reference: 3GPP TS 24.301

CS Service Notification
The CS SERVICE NOTIFICATION message is sent by the network to notify a UE in EMM-CONNECTED mode (i.e. NAS signalling connection is already established for the UE) about an incoming CS service (excluding SMS) over SGs
Note: SGs interface (between MME and MSC server) is used for the mobility management and paging procedures between EPS and CS domain

This is basically paging procedure for CS services (excluding SMS) for the UEs in EMM-CONNECTED mode This message may also include CS service related parameters e.g. Calling Line Identification, SS or LCS related parameters After receiving the CS SERVICE NOTIFICATION message, the UE may request upper layers input i.e. to accept or reject CS fallback before responding with an EXTENDED SERVICE REQUEST. The response is indicated in the CSFB response IE in the EXTENDED SERVICE REQUEST message The purpose of the Paging identity IE is to indicate the identity used for paging for non-EPS services. This identity could be either IMSI or TMSI If the network receives Calling Line Identification (CLI) via SGs, then it shall include it in the IE CLI The network shall send the IE SS Code if it was received via SGs. It contains information on the supplementary service transaction in the CS domain, which triggered the paging via SGs

The network shall send the IE LCS Indicator if it was received via SGs. It indicates that the paging was triggered by a terminating LCS request in the CS domain
Reference: 3GPP TS 24.301

Detach Request (UE initiated) The UE shall initiate the detach procedure when:
the UE is switched off - the USIM is removed from the UE the EPS capability of the UE is disabled (detach for EPS services only) the UE in CS/PS mode 1 or CS/PS mode 2 of operation wishes to detach for both EPS services and non-EPS services or for non-EPS services only via a combined detach procedure etc... The UE initiates the detach procedure by sending a DETACH REQUEST message The Detach type IE included in this message indicates the type of detach. 4-bits are used for this purpose. 3-bits (LSBs) indicate whether the detach is for EPS detach or IMSI detach or Combined EPS/IMSI detach. Bit-4 indicates if it is normal detach or switch off If the UE has a valid GUTI, the UE shall set the EPS mobile identity IE as GUTI. If the UE does not have a valid GUTI, then it shall populate the EPS mobile identity IE with its IMSI. If the UE has neither a valid GUTI nor a valid IMSI (with no USIM or invalid USIM), then the UE shall populate the EPS mobile identity IE with its IMEI If the UE is to be switched off, the UE shall try for a period of 5 seconds to send theDETACH REQUEST message. During this period, the UE may be switched off as soon as the DETACH REQUEST message has been sent When the DETACH REQUEST message is received by the network, with the Detach typeIE set to switch off, the network shall not send a DETACH ACCEPT message to the UE

When the DETACH REQUEST message is received by the network, with the Detach typeIE set to normal detach, the network shall send a DETACH ACCEPT message to the UE If the Detach type IE set to normal detach and if the UE doesnt receive DETACH ACCEPT message before the timer T3421 is expired, it shall re-transmit the DETACH REQUEST message. Upon the 5th expiry of T3421 timer, the UE shall perform local detach The network and the UE shall deactivate the EPS bearer context(s) locally without peer-to-peer signalling between the UE and the MME
Reference: 3GPP TS 24.301

Detach Request (Network Initiated) The detach procedure is either initiated by the UE or by the network. The network initiates the detach procedure:
- To detach the UE for EPS services or non-EPS services or both To disconnect the UE from the last PDN to which it is connected To inform the UE to re-attach to the network and re-establish all PDN connections

If the MME performs a local detach (i.e. no explicit signalling), it will inform the UE with an EMM message (e.g. SERVICE REJECT or TRACKING AREA UPDATE REJECT) with EMM cause #10 "implicitly detached" only when the UE initiates any EMM procedure If the detach procedure for EPS services is performed, then all the active EPS bearer context(s) are deactivated locally without peer-to-peer signalling between the UE and the MME The MME initiates the detach procedure by sending a DETACH REQUEST message to the UE The Detach type IE included in this message indicates the type of detach. 4-bits are used for this purpose. 3-bits (LSBs) indicate whether re-attach required or re-attach not required or IMSI detach. Bit-4 is always set to zero for network initiated detach If the detach type IE indicates that "re-attach required", the UE shall deactivate all the active EPS bearer context(s) locally and then send a DETACH ACCEPT message to the network. Furthermore, the UE shall, initiate attach or combined attach procedure. The UE should also re-establish any previously established PDN connections (user interaction is necessary in some cases when the UE cannot re-activate the EPS bearer(s) automatically) If the detach type indicates "IMSI detach", then the UE shall not deactivate any of the EPS bearer context(s). The UE shall send a DETACH ACCEPT message to the network and re-attach to non-EPS services by sending TRACKING AREA UPDATE REQUEST message with EPS update type IE indicating "combined TA/LA updating with IMSI attach" The network may include an EMM cause IE to specify the reason for the detach. If thedetach type indicates "IMSI detach" or "re-attach required", then the UE shall ignore theEMM cause IE if received For UE initiated Detach procedure, check my earlier post here
Reference 3GPP TS 24.301

Detach Accept The DETACH ACCEPT message is sent either by the network or the UE to indicate that the detach procedure has been completed
In the case of an UE initiated DETACH REQUEST , with the Detach type IE set to switch off, the network shall not send a DETACH ACCEPT message to the UE If the network receives a DETACH REQUEST , with the Detach type IE set to normal detach, the network shall send a DETACH ACCEPT message to the UE In the case of network initiated DETACH REQUEST, the UE shall send DETACH ACCEPTmessage, to indicate the successful completion of the detach procedure
Reference 3GPP TS 24.301

Transport of NAS messages The purpose of the transport of NAS messages procedure is to carry SMS messages in anencapsulated form between the MME and the UE
The procedure may be initiated by the UE or the network and can only be used when the UE is attached for EPS services and IMSI attached for non-EPS services and is in EMM-CONNECTED mode In the UE initiated case, upon request from the SMS entity to send an SMS message, the EMM entity in the UE initiates the procedure by sending an UPLINK NAS TRANSPORTmessage including the SMS message in the NAS message container IE The network initiates this procedure by sending a DOWNLINK NAS TRANSPORT message which contains the actual SMS message in the NAS message container IE

The IE NAS message container is used to encapsulate the SMS messages transferred between the UE and the network. This IE can contain SMS messages such as CP-DATA, CP-ACK, or CP-ERROR Activate Default EPS Bearer Context Request The purpose of the default bearer context activation procedure is to establish a default EPS bearer context between the UE and the EPC. The default EPS bearer context activation procedure is initiated by the network as a response to the PDN CONNECTIVITY REQUEST message from the UE. The default bearer is a non-Guaranteed Bit Rate (GBR) bearer. A dedicated bearer can be either a GBR or a non-GBR bearer. The default bearer remains established throughout the lifetime of the PDN connection to provide the UE with IP connectivity to the PDN The default bearer context activation procedure can be part of the Attach procedure, and if the attach procedure fails, the UE shall consider that the default bearer activation has implicitly failed Once the UE is successfully attached, the UE can request the MME to set up connections to additional PDNs. For each additional connection, the MME will activate a separate default EPS bearer context The MME shall initiate the default bearer context activation procedure by sending anACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message 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 When the default bearer is activated as the response to a stand-alone PDN CONNECTIVITY REQUEST message apart from the attach procedure, the MME shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message alone, and start the timer T3485 The MME shall assign and include an EPS bearer identity in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message. The MME shall retrieve the PTI (Procedure Transaction Identity) from the PDN CONNECTIVITY REQUEST message and include it in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message Typical IEs in ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message include EPS bearer identity, Procedure transaction identity (PTI), EPS QoS, Access point name (APN), PDN address, Negotiated QoS, Negotiated LLC SAPI, Packet flow Identifier, APN-AMBR (APN aggregate maximum bit rate), ESM cause, and Protocol configuration options etc The network shall include the IE ESM cause, if the network allocated a PDN address of a PDN type which is different from the PDN type requested by the UE Reference 3GPP TS 24.301

Activate

Default EPS Bearer Context Accept After receiving the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, the UE shall stop timer T3396 if it is running for the APN indicated in the message and send anACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message. The UE should check the Procedure transaction identity (PTI) in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to identify the UE requested PDN connectivity procedure to which this default bearer context activation is related. When the default bearer is activated as part of the attach procedure, the UE shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message together with ATTACH COMPLETE message. When the default bearer is activated in response to the stand-alone PDN CONNECTIVITY REQUEST message, the UE shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPTmessage alone. The UE shall include EPS bearer identity and Procedure transaction identity IEs in theACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message The IE Protocol configuration options is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the network Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message, the MME shall stop the timer T3485, if the timer is running
Reference 3GPP TS 24.301

Activate Dedicated EPS Bearer Context Request The purpose of the dedicated EPS bearer context activation procedure is to establish an EPS bearer context with a specific QoS and TFT between the UE and the EPC.

A PDN connection consists of one Default EPS bearer and, depending on the service for which the connection is used, a number of dedicated EPS bearers.
FYI.., a default EPS bearer is established during the Attach or Standalone PDN Connectivity procedure. Any additional EPS bearer that is established for the same PDN connection is referred to as a dedicated EPS bearer. Dedicated EPS bearers are activated and deactivated depending on the service used but the default bearer remains established throughout the lifetime of the PDN connection. The network decides if dedicated bearers need to be setup or not and what QoS settings should be applied for the dedicated bearers.

The dedicated EPS bearer can be either guaranteed bit rate (GBR) or nonGBR. The dedicated EPS bearer context activation procedure is initiated by the NW, but may be requested by the UE by means of the UE requested bearer resource allocation/modification procedure. This procedure can be part of the attach procedure or be initiated together with theDefault EPS bearer context activation procedure when the UE initiates a stand-alone PDN connectivity procedure. If the attach procedure or the Default EPS bearer context activation procedure fails, then the UE shall consider that the dedicated bearer activation has implicitly failed. The MME shall initiate the dedicated bearer context activation procedure by sending anACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message and start the timer T3485 The MME allocates and includes the EPS Bearer Identity in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message. The MME shall include the EPS bearer identity of the associated default bearer as theLinked EPS Bearer Identity in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUESTmessage. If this procedure was initiated by a UE requested bearer resource allocation/modification procedure, the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message shall contain the Procedure Transaction Identity (PTI) value received by the MME from the UE The other IEs in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST include EPS QoS, Traffic Flow Template (TFT), Transaction Id, Negotiated QoS, Negotiated LLC SAPI, Radio Priority, Packet flow Id, Protocol configuration options etc Reference 3GPP TS 24.301

Activate Dedicated EPS Bearer Context Reject The UE may reject the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST from the MME by sending an ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message. The ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message shall include the EPS Bearer Identity and an ESM Cause value indicating the reason for rejecting the dedicated EPS bearer context activation request. The ACTIVATE DEDICATED EPS BEARER CONTEXT REJECT message contains an ESM cause that typically indicates one of the following values:
#26: insufficient resources #31: request rejected, unspecified #41: semantic error in the TFT operation #42: syntactical error in the TFT operation #43: invalid EPS bearer identity #44: semantic error(s) in packet filter(s) #45: syntactical error(s) in packet filter(s) or #95 111: protocol errors

After receiving the ACTIVATE DEDICATED EPS BEARER CONTEXT

REJECT message, the MME shall stop the timer T3485 and abort the dedicated EPS bearer context activation procedure Reference 3GPP TS 24.301

Activate Dedicated EPS Bearer Context Accept The ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT message is sent by the UE to the network to acknowledge the activation of a dedicated EPS bearer context associated with the same PDN address (es) and APN as an already active EPS bearer context Upon receipt of the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message, the UE shall stop timer T3396, if it is running for the APN associated with the PDN connection and check the received TFT before taking it into use.

The linked EPS Bearer Identity included in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message indicates to the UE to which default bearer, IP address and PDN the dedicated bearer is linked. The UE shall include EPS bearer identity and Procedure transaction identity IEs in theACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT message. The IE Protocol configuration options is included in the message when the UE wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the network Upon receipt of the Activate Dedicated EPS Bearer Context Accept message, the MME shall stop the timer T3485 Reference 3GPP TS 24.301

PDN Connectivity Request The PDN connectivity procedure is used by the UE to request the setup of a default EPS bearer to a PDN. The UE requests connectivity to a PDN by sending a PDN CONNECTIVITY REQUEST message to the network. If this request is accepted by the network, then it initiates the establishment of a default EPS bearer context activation procedure. This procedure is used either to establish the first default bearer (PDN CONNECTIVITY REQUEST is sent along with initial attach message), or to establish subsequent default bearers to additional PDNs (a stand-alone PDN CONNECTIVITY REQUEST is sent by the UE). If the UE is in EMM-IDLE mode, the Service Request procedure is performed before the PDN Connectivity procedure can be initiated. If there is already a PDN connection for emergency bearer services established, the UE shall not request an additional PDN connection for emergency bearer services. A UE attached for emergency bearer services shall not request a PDN connection to any other PDN. When the PDN CONNECTIVITY REQUEST message is sent together with an ATTACH REQUESTmessage, the UE shall not include the APN. When requesting connectivity to an additional PDN, the UE shall include the
requested APN (in the stand-alone PDN CONNECTIVITY REQUEST) except for emergency bearer services

 The UE may set the ESM information transfer flag in the PDN

CONNECTIVITY REQUESTmessage to indicate that it has ESM information, i.e. protocol configuration options, or APN, or both, that needs to be transferred to the MME after the NAS signalling security has been activated If the ESM information transfer flag is set in PDN CONNECTIVITY REQUEST message, the MME initiates (after NAS sigalling security is activated) the ESM information requestprocedure in which the UE can provide the MME with protocol configuration options or APN or both. If the UE wishes to connect to a PDN using default APN, it need not include the APN in theAccess Point Name IE in the ESM INFORMATION RESPONSE or PDN CONNECTIVITY REQUEST(stand-alone) message. The only exceptional case is, if the connectivity to a PDN using the default APN requires PAP/CHAP, then the UE should include the APN in the Access point name IE The UE shall set the Request Type IE to "initial request" when the UE is establishing a new PDN connectivity to a PDN in an attach procedure or in a stand-alone PDN connectivity procedure. The UE shall set the Request Type IE to "emergency" when the UE is requesting a new PDN connectivity for emergency bearer services. The Request Type IE is set to "handover" when the connectivity to a PDN is established upon handover from a non-3GPP access network and the UE was connected to that PDN before the handover to the 3GPP access network The other IEs in the PDN CONNECTIVITY REQUEST message include EPS Bearer Identity, Procedure Transaction Identity, PDN Type, and Device Properties etc If the UE includes ESM information transfer flag in the PDN CONNECTIVITY REQUESTmessage, the MME waits for completion of the ESM information request procedure before proceeding with the PDN connectivity procedure. The MME then checks if connectivity with the requested PDN can be established. If requested APN is not included in the PDN CONNECTIVITY REQUEST or the ESM INFORMATION RESPONSE message and the request type is different from "emergency", the MME shall use the default APN as the requested APN. If the request type is "emergency", the MME shall use the APN configured for emergency bearer services Reference 3GPP TS 24.301

Connectivity Reject If the PDN CONNECTIVITY REQUEST cannot be accepted by the network, then the MME shall send a PDN CONNECTIVITY REJECT message to the UE.

PDN

The PDN CONNECTIVITY REJECT message shall contain the Procedure

Transaction Identity (PTI) which should match the PTI value in the PDN CONNECTIVITY REQUEST sent by UE reason for rejecting the UE requested PDN connectivity. #8: operator determined barring #26: insufficient resources #27: missing or unknown APN

Also, this message shall contain an ESM cause value which indicates the The ESM cause IE typically indicates one of the following ESM cause values:

#28: unknown PDN type #29: user authentication failed #30: request rejected by Serving GW or PDN GW #31: request rejected, unspecified #32: service option not supported #33: requested service option not subscribed #34: service option temporarily out of order #35: PTI already in use #38: network failure #50: PDN type IPv4 only allowed #51: PDN type IPv6 only allowed #53: ESM information not received #54: PDN connection does not exist #55: multiple PDN connections for a given APN not allowed #95 111: protocol errors #112: APN restriction value incompatible with active EPS bearer context.

If the ESM cause value is #26 "insufficient resources" or #27 "missing or

unknown APN", the network may include a value for timer T3396 in the PDN CONNECTIVITY REJECT message. In such a case, the UE should take different actions depending on the timer value and reject cause. Refer to section 6.5.1.4 in the 3GPP TS 24.301 for detailed information
Reference 3GPP TS 24.301

PDN Disconnect Request The purpose of the PDN Disconnect procedure is for a UE to request the network to disconnect from one PDN.

The UE can initiate this procedure to disconnect from any PDN as long as it is
connected to at least one other PDN.

Successful completion of this procedure means that, all EPS bearer contexts
established towards this PDN, including the default EPS bearer context, are released. the UE has the connection), the UE should not use PDN disconnect procedure. Instead, it shall use detach procedure

In order to disconnect from the last PDN (the one and the only PDN to which

 In order to request PDN disconnection from a PDN, the UE shall send a PDN
DISCONNECT REQUEST message to the MME and start the timer T3492.

In this message, The UE shall set the value of Linked EPS Bearer

Identity IE as the EPS Bearer Identity of default bearer associated with the PDN for which UE is sending the disconnect request. it shall send theDEACTIVATE EPS BEARER CONTEXT REQUEST message including the linked EPS bearer identity of the default bearer associated with the PDN to disconnect from. UE, the MME shall send a PDN DISCONNECT REJECT message to the UE which shall contain the PTI and anESM cause IE indicating the cause for the rejection DISCONNECT REJECT message, the UE shall stop the timer T3492

If the network accepts the PDN DISCONNECT REQUEST sent by the UE, then

If the network doesnt accept the PDN DISCONNECT REQUEST sent by the

Upon receipt of the DEACTIVATE EPS BEARER CONTEXT REQUEST or PDN If there is no response received for the PDN DISCONNECT REQUEST before
the expiry of the timer T3492, the UE shall resend the PDN DISCONNECT REQUEST and shall reset and restart timer T3492. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3492, the UE shall abort the procedure and deactivate all EPS bearer contexts for this PDN connection locally without peer-to-peer signalling between the UE and the MME
Reference 3GPP TS 24.301

Deactivate EPS Bearer Context Request The purpose of the EPS bearer context deactivation procedure is to deactivate an EPS bearer context or disconnect from a PDN by deactivating all EPS bearer contexts to that PDN.

This procedure is initiated by the network, and it may be triggered by the UE

by means of the Bearer Resource Modification or PDN Disconnect procedure.

 If a NAS signalling connection exists when the MME initiates this procedure,

then the MME shall initiate the EPS bearer context deactivation procedure by sending a DEACTIVATE EPS BEARER CONTEXT REQUEST message to the UE and start the timer T3495. procedure, then the ESM entity in the MME shall locally deactivate the EPS bearer context towards the UE without any peer-to-peer ESM signalling between the MME and the UE. cause typically indicating one of the following: #8: operator determined barring #36: regular deactivation #38: network failure #39: reactivation requested or #112: APN restriction value incompatible with active EPS bearer context

If there no NAS signalling connection exists when the MME initiates this

The DEACTIVATE EPS BEARER CONTEXT REQUEST message contains an ESM

If the deactivation is triggered by a UE initiated bearer resource modification

or PDN disconnect procedure, the DEACTIVATE EPS BEARER CONTEXT REQUEST message shall contain the PTI value received from the UE in the corresponding message.

When the MME wants to deactivate all EPS bearer contexts to a PDN and

thus disconnect the UE from the PDN, the MME shall include the EPS Bearer Identity of the default bearer associated to the PDN in the DEACTIVATE EPS BEARER CONTEXT REQUEST message. CONTEXT REQUESTbefore the expiry of the timer T3495, the MME shall resend this message and shall reset and restart T3495. This retransmission is repeated four times, i.e. on the fifth expiry of T3495, the MME shall abort the procedure and deactivate the EPS bearer context locally without any peer-topeer ESM signalling between the MME and the UE. network wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the UE.
Reference 3GPP TS 24.301

If the MME doesnt receive a response for DEACTIVATE EPS BEARER

The IE Protocol Configuration Options is included in the message if the

Deactivate EPS Bearer Context Accept The UE after receiving the DEACTIVATE EPS BEARER CONTEXT REQUEST message, shall delete the EPS bearer context identified by the EPS bearer identity.

If the EPS bearer identity indicated in the DEACTIVATE EPS BEARER

CONTEXT REQUEST is that of the default bearer to a PDN, the UE shall delete all EPS bearer contexts associated to the PDN. to the MME with the DEACTIVATE EPS BEARER CONTEXT ACCEPT message. connection active and that is for emergency bearer services, then the UE shall consider itself attached for emergency bearer services only include Procedure Transaction Identity (PTI) as received in the DEACTIVATE EPS BEARER CONTEXT REQUESTmessage include, EPS bearer identity and Protocol configuration options
Reference 3GPP TS 24.301

After deactivating the identified EPS bearer context (s), the UE shall respond If due to the EPS bearer context deactivation, there is only one PDN

In the DEACTIVATE EPS BEARER CONTEXT ACCEPT message, the UE shall Other IEs in the DEACTIVATE EPS BEARER CONTEXT ACCEPT message

Bearer Resource Allocation Request The purpose of the UE requested bearer resource allocation procedure is (for an UE) to request an allocation of bearer resources for a traffic flow aggregate.

The UE requests a specific QoS demand (QCI) and optionally sends a

context activation procedure or an EPS bearer context modification procedure.

Guaranteed Bit Rate (GBR) requirement for a new traffic flow aggregate.

If accepted by the network, this procedure invokes a dedicated EPS bearer

 If there is a PDN connection for emergency bearer services established, the

UE shall not request additional bearer resources for this PDN connection. ALLOCATION REQUESTmessage to the MME and starts the timer T3480. EPS bearer identity of the default EPS bearer associated with the requested bearer resource. "Create new TFT".

The UE initiates this procedure by sending a BEARER RESOURCE

The UE shall include the IE Linked EPS bearer identity and set it as the

The UE shall set the TFT operation code in the Traffic flow aggregate IE to In the Required traffic flow QoS IE, the UE shall indicate a QCI (QoS Class
Identifier) and, if the UE also includes a GBR, the additional GBR required for the traffic flow aggregate. MME shall send either an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST or MODIFY EPS BEARER CONTEXT REQUEST message with a PTI value received in the BEARER RESOURCE ALLOCATION REQUEST message.

If the bearer resource allocation request is accepted by the network, the

If the UE doesnt receive response to the BEARER RESOURCE ALLOCATION

REQUESTmessage before the expiry of the timer T3480, the UE shall resend this message and reset/restart T3480. This retransmission is repeated four times, i.e. on the fifth expiry of T3480, the UE shall abort the procedure, release the PTI allocated for this activation. RESOURCE ALLOCATION REQUEST message if the UE wishes to transmit (protocol) data (e.g. configuration parameters, error codes or messages/events) to the network. configured for NAS signalling low priority
Reference 3GPP TS 24.301

The Protocol Configuration Options IE is included in the BEARER

The UE shall include the IE Device Properties in this message if the UE is

Bearer Resource Allocation Reject If the bearer resource allocation request cannot be accepted by the network, then the MME sends a BEARER RESOURCE ALLOCATION REJECT message to the UE.

The BEARER RESOURCE ALLOCATION REJECT message shall contain

the Procedure Transaction Identity (PTI) which is equal to the PTI value in the BEARER RESOURCE ALLOCATION REQUEST received from the UE for rejecting the UE requested bearer resource allocation.

This message shall also contain an ESM Cause value indicating the reason The UE, after receiving the BEARER RESOURCE ALLOCATION
REJECT message, shall stop the timer T3480 and release the traffic flow aggregate description associated to the received PTI value include a value for timer T3396 value IE in the BEARER RESOURCE ALLOCATION REJECT message. Depending on the timer value, the UE shall take different actions as explained in 6.5.3.4 in 3GPP TS 24.301
Reference 3GPP TS 24.301

If the ESM cause value is #26 "insufficient resources", the network may

Bearer Resource Modification Request The purpose of the UE requested bearer resource modification procedure is for a UE to request a modification or release of bearer resources for a traffic flow aggregate or modification of a traffic flow aggregate by replacing or adding packet filters.

When requesting a modification of bearer resources for a traffic flow

aggregate or a modification of a traffic flow aggregate, the UE can modify the existing GBR. context activation, an EPS bearer context modification, or an EPS bearer context deactivationprocedure. UE shall not request a modification of bearer resources for this PDN connection.

If the network accepts this procedure, it invokes a dedicated EPS bearer

If there is a PDN connection for emergency bearer services established, the

 In order to request the modification of bearer resources for one traffic flow
aggregate, the UE shall send a BEARER RESOURCE MODIFICATION REQUEST message to the MME

The UE shall include the EPS bearer identity of the EPS bearer associated
with the traffic flow aggregate in the EPS bearer identity for packet filter IE.

To request a change of the GBR without changing the packet filter(s), the UE

shall set the TFT operation code in the Traffic flow aggregate IE to "no TFT operation" and include the packet filter identifier(s) to which the change of the GBR applies in the Packet filter identifier parameter in the parameters list. the Required traffic flow QoS IE.

The UE shall indicate the new GBR requested for the EPS bearer context in To request a modification of a traffic flow aggregate, the UE shall set the TFT
operation code in the Traffic flow aggregate IE to "Replace packet filters in existing TFT" or "Add packet filters to existing TFT".

If the TFT operation code is set to "Add packet filters to existing TFT", the UE
shall include the existing packet filter identifier(s) to which the newly added packet filter(s) is linked in the parameters list. code in the Traffic flow aggregate IE to "Delete packet filters from existing TFT". the current QCI value of the EPS bearer context.

To request a release of bearer resources, the UE shall set the TFT operation If the UE includes the Required Traffic Flow QoS IE, the UE shall set the QCI to If the bearer resource modification requested is accepted by the network,
the MME shall send ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST, MODIFY EPS BEARER CONTEXT REQUEST or DEACTIVATE EPS BEARER CONTEXT REQUEST message with a PTI which matches the value used for the BEARER RESOURCE MODIFICATION REQUEST message. network, the MME shall send a BEARER RESOURCE MODIFICATION REJECT message to the UE.
Reference 3GPP TS 24.301

If the bearer resource modification requested cannot be accepted by the

Bearer Resource Modification Reject If the network cannot accept the bearer resource modification requested by the UE, then the MME shall send a BEARER RESOURCE MODIFICATION REJECT message to the UE.

 The BEARER RESOURCE MODIFICATION REJECT message shall contain

the Procedure Transaction Identity (PTI) which should match the PTI value received in the BEARER RESOURCE MODIFICATION REQUEST. reason for rejecting the UE requested bearer resource modification.

Also, this message shall contain an ESM cause value which indicates the If the bearer resource modification requested is for an established LIPA PDN
connection, then the network shall reply with a BEARER RESOURCE MODIFICATION REJECT message with ESM cause #60 "bearer handling not supported".

If the ESM cause value is #26 "insufficient resources", the network may

include a value for timer T3396 value IE in this message. In such a case, the UE should take different actions depending on the timer value as specified in section 6.5.4.4 in 3GPP TS 24.301. UE shall stop the timer T3481 and release the traffic flow aggregate description associated to the PTI value.

After receiving the BEARER RESOURCE MODIFICATION REJECT message, the If the ESM cause included in the reject message is #43 "invalid EPS bearer

identity", the UE locally deactivates the EPS bearer context(s) without peerto-peer ESM signalling.
Reference 3GPP TS 24.301

RRC Connection Release

Direction: E-UTRAN => UE Signalling Radio Bearer: SRB1 RLC Mode: AM Logical Channel: DCCH Transport Channel: DL-SCH The RRC CONNECTION RELEASE message is used to command the release of an RRC connection. E-UTRAN initiates the RRC connection release procedure to an UE in RRC_CONNECTED state

The RRC CONNECTION RELEASE procedure with redirection information can also be used for CS-fallbackto GERAN or UTRAN The RRC CONNECTION RELEASE procedure can also be used for MME load balancing. If an MME feels overloaded, it can simply move the calls to other MME in the MME pool. The source MME releases the S1 connections of the UE towards the eNodeB asking the UE to perform a load balancing TAU. Then the eNodeBsends RRC CONNECTION RELEASE message to the UE with cause load balancing TAU required'. After receiving this message, the UE initiates Tracking Area Updating procedure which is redirected to another MME The eNodeB may provide a cell reselection priority for each frequency, by means of separate lists for each RAT (including E-UTRA) in the RRC CONNECTION RELEASE message There is no RRC CONNECTION RELEASE COMPLETE message defined in LTE. So, UE leaves RRC_CONNECTED state without transmitting RRC CONNECTION RELEASE COMPLETE message Some of the IEs in RRC CONNECTION RELEASE message ReleaseCause: The IE releaseCause is used to indicates the reason for releasing the RRC Connection(Ex:- loadBalancingTAUrequired, cs-FallbackHighPriority, or other) RedirectedCarrierInfo: The redirectedCarrierInfo indicates a carrier frequency which is used to redirect the UE to an E-UTRA or an inter-RAT carrier frequency IdleModeMobilityControlInfo: This IE provides dedicated cell reselection priorities. FreqPriorityListX: Provides a cell reselection priority for each frequency, by means of separate lists for each RAT (including E-UTRA) SystemInformation: Container for system information of the GERAN cell. Each OCTET STRING in SystemInfoListGERAN contains one complete System Information (SI) message as defined in TS 44.018 cellInfoList: Used to provide system information of one or more cells on the redirected inter-RAT carrier frequency. The system information can be used if, upon redirection, the UE selects an inter-RAT cell indicated by the physCellId and carrierFreq (GERAN) or by the physCellId (other RATs). utra-BCCH-Container: Contains System Information Container message as defined in TS 25.331
Reference: 3GPP TS 36.331