LTE_Tech_Ov_Sec05_091009_v01

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

1/67

Informa Telecoms & Media

LTE Procedures

LTE PROCEDURES

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

2/67

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

3/67


LTE Procedures

LTE PROCEDURES

LTE/SAE PROCEDURES 4

LTE Connection States 6Network Attachment 8

System Information Broadcast 10

System Information Block Scheduling 12

PLMN and Cell Selection 14

Cell Reselection 16

IDLE Mode Location Management in LTE 18

Multiple Tracking Areas 20

Connected Mode Mobility 22

Measurements for Handover 24

Measurement Scenarios 26Random Access Procedure 28

Contention Based Random Access 30

Non-Contention Based Random Access 32

Establishing RRC Connections 34

Registration Procedure 36

Registration Procedure 38

EMM State Machine 40

Service Request and Initial Bearer Establishment 42

ESM State Machine 44

Bearer Modification with Bearer QoS Update 46INTER-WORKING WITH 3GPP NETWORKS 54

E-UTRAN to UTRAN Iu Mode Inter RAT HO,

Preparation Phase 54

E-UTRAN to UTRAN Iu Mode Inter RAT HO,

Execution Phase 58

SUPPORT FOR NON-3GPP ACCESSES 62

Non-3GPP Access Network Architecture 64

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

4/67

4

LTE Procedures


The procedures may be categorised as follows;

IDLE mode mobility, including:

System Information

Paging

Cell selection/reselection

TA updates

CONNECTED mode mobility, including:

Radio connection handover

EPC context handover

Measurements and reporting

Registration procedures, including:

RRC connections

EPC registrations

Session Management, including:

EPS Bearer establishment

QoS negotiation

LTE/SAE PROCEDURES

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

5/67

5Informa Telecoms & Media

Fig. 1 LTE Procedures

IDLE mode mobility, including

System Information

Paging

Cell selection/reselection

TA updates

CONNECTED mode mobility, including

Radio connection handover

EPC context handover

Measurements and reporting

Network Attachment, including

RRC connections

EPC registrations

Session Management, including

EPS Bearer establishment

Security

QoS negotiation

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

6/67

6

LTE Procedures


LTE Connection States

In order to effectively manage the connection status of the UE for packet based services there

are two state machines in the UE, IDLE and CONNECTED mode. The diagram opposite takes

into account the network architecture related to the connectivity status of the UE.

Packets based services do not require permanent physical connections allocated for the duration

of the packet session (unlike circuit switched connections) therefore the connectivity of the UE

is driven by the two state machines in the UE, RRC level connectivity and MM level mobility.

When the mobile is considered to be LTE_DETACHED the EPC has no knowledge of the

location of the user and there are no ongoing connections. No communication context exists,

the only information related to the UE and the related subscription resides in the HSS function

of the EPC. The UE may be considered powered down whilst the MM state machine is in the

DETACHED state.

On attachment to the EPC the MM state machine is considered ACTIVE or IDLE depending

on the current activity of the signalling or data connections. Once registered in the system the

UE may establish EPS bearers in order to transfer data and whilst the EPS bearer remains

connected the UE may become LTE_IDLE if no activity takes place for a period of time.

The UE will therefore move between LTE_ACTIVE and LTE_IDLE modes on a regular and frequent

basis depending on the characteristics of the data flow, QoS assignment and network capacity.

Whilst the MM state machine is moving between its states the RRC state machine will be

correspondingly transitioning between IDLE and CONNECTED states. When ever there is

a requirement from the upper layer or a paging message is received by the UE it will transitionto CONNECTED state whilst the upper layer information (signalling or data) is transmitted.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

7/67

EMM

RRC

S1

NAS Procedures (EMM, ESM)

LTE_Detached,LTE_Active,

LTE_Idle

RRC_Idle,RRC_Connected

eNB

UE SGW


Fig. 2 MM and RRC Mobility/Connection States

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

8/67

8

LTE Procedures


Network Attachment

Before any other service or procedure can be carried out the UE must attach and register its

presence in the network, this applies to home network and roaming scenarios. Attachment is

usually carried out when the UE is powered up, the process relies on many other mechanisms

within the network for successful attachment.

The diagram opposite shows the high level functions required for network attachment.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

9/67

System Information

System Information

System Information

System Information

NetworkAcquisition

PLMNSelection

RRCConnection

NASRegistration

Radio Ch ScanningSynchronisation

Cell Selection

Random Access

Random Access Response

RRC Connection Request

RRC Connection Response

Random Access


UE EPC

RRC_Idle (time out)

EMM_Registered

RRC_Connected

PLMN Selected


Fig. 3 Procedures Related to Network Attachment

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

10/67

10

LTE Procedures


System Information Broadcast

There are 3 main parts to the system information broadcast procedures.

First of all the most critical information is transmitted with high frequency in the MasterInformation Block (MIB) this includes:

Downlink System Bandwidth

Number of Transmit Antennas

PHICH Configuration

System Frame Number (SFN)

The MIB is transmitted every 40mS on the BCCH mapped to the BCH transport channel.

Secondly, less urgent information can be transmitted on the BBCH and mapped to the

DL SCH. This information is contained within System Information Block (SIB) 1. This can

be other wise referred to as a Scheduling Unit 1 (SU-1) and amongst other information

it contains scheduling information about the other SIBs that may be transmitted. This

message is transmitted every 80mS.

Scheduling information i.e. the periodicity of the other Scheduling Units (other than SU-1);

One or more PLMN identities (up to 6);

Tracking Area Code;

Cell identity;

One bit for cell barring common for all sharing PLMNs;

One bit for cell reserved for operator use per sharing PLMN (up to 6);

One bit for cell reservation extension common for all sharing PLMNs;

One bit for CSG indication;

Value_tag (Common for all SUs);

SIB mapping information i.e. indication in which SU the SIB is included (FFS).

Finally, other SIBs containing information relating to the system and the behaviour of the

UE in the system. There are 7additional SIBs that are transmitted according to the schedule

transmitted by SIB-1 or SU-1.

SIB2 Access class and access related parameters

SIB3 Cell selection and Measurement parameters

SIB4 Serving cell frequency parameters including neighbour cell black lists

SIB5 Inter-carrier parameters, thresholds, inter-frequency black lists

SIB6 UTRA cell reselection parameters, thresholds, quality levels, transmit powers

SIB7 GERAN cell selection parameters,, NCELL lists, NCC permitted

SIB8 CDMA Cell selection Parameters, selection thresholds, NCELL lists

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

11/67


Fig. 4 System Information Blocks

Master Information BlockDownlink System Bandwidth

Number of Transmit Antennas

PHICH Configuration

System Frame Number (SFN)

System Information Block 1Scheduling information

SIB mapping information

One or more PLMN identities (up to 6);

Tracking Area Code;

Cell identity;

One bit for cell barring common

One bit for cell reserved for operator use

One bit for cell reservation extension

One bit for CSG indication;

Value Tag

System Information Blocks 2 -8SIB2 Access class and access related parameters

SIB3 Cell selection and Measurement parameters

SIB4 Serving cell frequency parameters includingneighbour cell black lists

SIB5 Inter-carrier parameters, thresholds, inter-frequencyblack lists

SIB6 UTRA cell reselection parameters, thresholds,quality levels, transmit powers

SIB7 GERAN cell selection parameters,, NCELL lists,NCC permitted

SIB8 CDMA Cell selection Parameters, selectionthresholds, NCELL lists

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

12/67

12

LTE Procedures


System Information Block Scheduling

SIB1 contains the schedule of SIB transmission. It indicates how often the system information

will be transmitted and which system information blocks will be transmitted.

It is possible that the some of the system information will change over time. The change

of information must be indicated to the UE. This may be done by changing the scheduling

information transmitted by SIB1. The paging messages may also carry a change indication,

relieving the need for the UE to schedule SIB decodes whilst performing DRX.

The information received y the UE is considered valid for a period of 6 hours, after which the

information will have to be updated.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

13/67

Master Information Block

SIB 1 Scheduling and SIB Mapping

SIB2

SIB3

SIB5

SIB2

SIB4

SIB7

SIB8

MIB 40mSSIB1 80mS

SchedulingUnit 1

320mS

SchedulingUnit 2

1280mS

UE EPC


Fig. 5 System Information Scheduling

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

14/67

14

LTE Procedures


PLMN and Cell Selection

PLMN Selection is the process where the UE finds ands selects a suitable PLMN. This process

is driven by the subscribed PLMN identity stored on the UICC (SIM card). The UE will first

search for the home PLMN, where the home PLMN is not available the UE will search and find

available PLMNs and rank them in order of priority. The ranking may be driven by preferred

PLMN lists or purely on the basis of best cell, this consideration may include access

technology type (E-UTRAN, UMTS, GERAN etc), signal strength and quality.

Once the PLMN has been selected the UE must make selection of cell on which to camp and

make the initial registration to the system. The initial cell selection process is determined from

UE measurements and cell selection criteria broadcast in the System Information Block. Cells

may be ranked into;

Acceptable Cells; limited services available, cell not barred, cell selection criteria fulfilled

Suitable Cell; normal service, part of a registered or permitted PLMN, not barred, cell selection

criteria fulfilled.

Cells are considered barred or reserved if the access class in the SIB2 is set to indicate barring

or access reserved only for certain access classes.

The UE will select the cell that is fulfils the cell selection criteria and is ranked highest in the list

of available cells. The cell selection may be driven by a stored list or by a new scan.

The minimum criteria for cell selection is;

Srxlev > 0Where Srxlev is

Srxlev = Qrxlevmeas (Qrxlevmin Qrxlevminoffset) Pcompensation

Qrxlevmeas signal level measured in the cell

Qrxlevmin minimum require signal level required in the cell

Qrxlevminoffset an offset used when searching for a higher priority PLMN, usually when

camped on a VPLMN

Pcompensation currently under study

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

15/67

Cell selection based on; Initial cell selection

Stored list

Srxlev [a f] =Qrxlevmeas[a f] (Qrxlevmin [a f] Qrxlevminoffset) Pcompensation

Qrxlevmeas[a f] Srxlev > 0

a

d

c

b

e

f


Fig. 6 Cell Selection

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

16/67

16

LTE Procedures


Cell Reselection

After initial cell selection the UE will then being to consider cell reselection (and periodically

PLMN reselection if the current PLMN selected is not the HPLMN).

There is no particular need to provide the UE with a list of neighbour cell (NCL) in LTE since the

UE will scan and find available cell autonomously, however there are occasions where the NCL

may be provided i.e. where the system wishes to specify particular cell reselection parameters

for intra and inter cell reselections.

In general intra-frequency (intra-LTE) reselection is based on a ranking process where a ranking

value (R) is calculated for the current serving cell and for the suitable neighbour cells. When a

neighbour cell is ranked higher that the serving cell for a time that exceeds the Treselection

parameter and the current serving cell has been selected for more than 1 second, the UE will

selected the new cell. The UE may also take into account thresholds that consider the speed of

the mobile. In high mobility scenarios it may not be desirable to have the mobile select particular

cells, in this case the reselection calculation may apply certain speed related offsets and

hysteresis parameters.

The ranking of cells is given by;

Rs = Qmeas,s + Qhysts

Rn = Qmeas,n Qoffset

Where

Qmeas is the value of Srxlev measured by the UE

Qhysts and Qoffset are cell reselection paramaters broadcast in the System Info Blocks

Cell reselection will take place when;

Rn > Rs > Treselection

Cell reselection may be further complicated by interRAT processes. The UE will prioritise

cells based on the RAT and apply different reselection timers and offsets according to the

parameters sent in the system information blocks.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

17/67

Cell reselection occurs;

Rn> Rs for time> Treselection

Treselection and Qhystmay be scaled dependant on the UE mobility State, i.e. High, Medium

Rs= Qmeas,s+ QhystsRn= Qmeas,n Qoffset

Rs

Rs

Rs


Fig. 7 Cell Reselection

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

18/67

18

LTE Procedures


IDLE Mode Location Management in LTE

Location management is important in cellular mobile systems. The level of mobility

management control depends on the current level of connection the UE has with the network.

If the UE is RRC_CONNECTED then the radio access network has a cell level resolution of

the location of the UE, the current cell is updated as the mobile moves from cell to cell during

the handover procedure.

However when the UE is in and IDLE state the radio access network has no information about

the location of the mobile. This information is retained by the serving gateway and mobility

management entities. For IDLE mode UEs the resolution of location information is also much

less detailed than CONNECTED UEs.

The EPC only records the location of the UE on the basis of a Tracking Area (TA). The tracking

area is a defined group of radio cells, much like the Location or Routing Areas of 2.5G networks.

The size of the TA is dependant on the expected level of IDLE mode UEs in any particular area,

the dimensioning goal would be to reduce the amount of TA update signalling seen in any area

and to balance this against the amount of paging load required, generally speaking larger TA

will reduce the amount of update signalling but may increase the required paging load across

the TA. The actual size of the TA will be a matter of system optimisation.

There are 3 opportunities for the UE to perform TA updates with the EPC.

At initial registration

When the UE move to a different TA

Periodically

The periodic update is useful for purging the core network of UEs which are no longer within

network coverage or the device battery has failed.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

19/67

TA4

TA8TA2

TA1

TA3

TA5 TA7

TA6


Fig. 8 IDLE Mode Mobility

Location Updating

At initial registration

When the UE move to a different TA

Periodically

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

20/67

20

LTE Procedures


Multiple Tracking Areas

A new feature to location management in LTE is the ability for the UE to be registered in

multiple TA. The EPC will signal to the mobile a list of TAs associated with the TA it is currently

registered. The UE may then move between these TAs with out the need for updates to take

place. The list may be updated by the EPC when the mobile performs its periodic TA update.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

21/67

TA4

TA8TA2

TA1

TA3

TA5 TA7

TA6


Fig. 9 Tracking Area and Multiple Tracking Area Registration

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

22/67

22

LTE Procedures


Connected Mode Mobility

When the mobile is in RRC_CONNECTED state the mobility of the UE is governed by the

E-UTRAN. The eNodeB compares the potential handover targets based on the measurement

reports provided by the UE. Ultimately it is the serving eNodeB that selects the target cell and

determines when the handover should take place.

At the radio level the handover is relatively simple in that the UE will receive a handover

command indicating the new target cell resources and after switch over will confirm the

handover by passing a protected token back to the new eNodeB in a confirmation message.

The handover process is a more complicated affair when the architecture of the network is

taken in to account. The goal for handover is to ensure that the switchover between resources

on different cell is rapid and, importantly, no data is lost in the process. Ensuring that no

information is lost requires that data packets destined for the UE are buffered I the network

and forwarded to the target eNodeB during the handover process.

The handover sequence opposite assumes that the X2 interface is present. The process begins

with a decision by the serving eNodeB to handover the UE to the target eNodeB. The handover

decision is based on UL measurement reports that the UE has provided. The reports contain

frequency, signal strength and RAT (Radio Access Technology) information. The actual decision

algorithm is generally left up to the equipment vendors, however the reason for handover will

be based on thresholds related to signal strength and signal quality. The actual decision may

be more complex when inter-RAT handovers are considered.

The handover request message sent to the target eNodeB contains an indication of theresources required for the new UE. The target eNodeB allocates all the required resources,

prepares the RRC handover command and passes it back to the serving eNodeB in the

handover request acknowledge. The serving eNodeB then begins to forward all unacknowledged

RLC buffered data to the target eNodeB and issues the handover command to the UE.

The handover confirm message is sent by the UE to the new eNodeB. The new eNodeB

initiates the path switch process which informs the MME that there is a new route to the UE.

The MME will update the context data relating to the UE and begin to re-route any new packet

to the new eNodeB.

The eNodeB will begin to forward the buffered RLC data to the UE when the handover confirmmessage is received. The sequence numbers in at the RLC layer and PDCP layers should

ensure that no data is missing, out of sequence or duplicated.

In the case where the X2 interface is not supported the serving eNodeB will make the handover

request via the MME.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

23/67

Handover Request

Forward Un-Ack RLC PDUs

Path Switch Request

Update Bearer Request

Update Bearer Response

Path Switch Request Ack

Release Resources

Handover Confirm

Handover Command

Handover Request Ack[RRC Handover Command]

Preparation

Execution

UE MME

Serving GWeNB PDN GWeNB

S5S11S1X2

S1

Handover

decision

Release

resources

Radio resource

allocation


Fig. 10 RRC_CONNECTED mode Mobility (Handover) with X2 Interface

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

24/67

24

LTE Procedures


Measurements for Handover

In IDLE mode the UE will follow the directions found in the System Information Broadcasts

on either the BCCH or DCCH.

In CONNECTED mode the UE will follow the measurement configuration specified by RRC

during the allocation of radio resources. The measurement process depends on a number

of aspects.

UE capability

DRX settings

intra-frequency or inter-frequency measurements

inter-RAT measurements

The duration of frequency of the measurements and the periodicity of the reporting is all

determined by the RRC. The actual numeric details are still being studied.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

25/67


Fig. 11 Measurement Dependencies

Measurement DependenciesUE capability

DRX settings

Intra-frequency or inter-frequency

measurements

Intra-RAT or inter-RAT measurements

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

26/67

26

LTE Procedures


Measurement Scenarios

There are a number of scenarios that need to be considered that encompass the UE

capability and scheduling requirements in respect of taking neighbour cell measurements.

these are dependant on whether the frequencies being measured are considered

intra-frequency or inter-frequency.

Intra-frequency measurements are measurements taken on neighbour cells that operate

on the same frequency as the serving cell.

Inter-frequency measurements are measurements taken on neighbour cells that operate

on a different frequency than the serving cell. It is likely that the UE will require measurement

gaps in order to take measurements of this type.

Whether a measurement is non gap assisted or gap assisted depends on the UEs

capability and current operating frequency. The UE determines whether a particular cellmeasurement needs to be performed in a transmission/reception gap and the scheduler

needs to know whether gaps are needed: (from TS 36.300).

Same carrier frequency and cell bandwidths (Scenario A): an intra-frequency scenario;

not measurement gap assisted.

Same carrier frequency, bandwidth of the target cell smaller than the bandwidth of the

current cell (Scenario B): an intra-frequency scenario; not measurement gap assisted.

Same carrier frequency, bandwidth of the target cell larger than the bandwidth of the

current cell (Scenario C): an intra-frequency scenario; not measurement gap assisted.

Different carrier frequencies, bandwidth of the target cell smaller than the bandwidth

of the current cell and bandwidth of the target cell within bandwidth of the current

cell (Scenario D): an inter-frequency scenario; measurement gap-assisted scenario.

Different carrier frequencies, bandwidth of the target cell larger than the bandwidth

of the current cell and bandwidth of the current cell within bandwidth of the target

cell (Scenario E): an inter-frequency scenario; measurement gap-assisted scenario.

Different carrier frequencies and non-overlapping bandwidth; (scenario F): an inter-

frequency scenario; measurement gap-assisted scenario.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

27/67

Scenario Ashown offset for clarity

Scenario B Scenario C

Scenario D

Current cell

Scenario E Scenario F

Target cell


Fig. 12 Intra and Inter Frequency Measurement Scenarios

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

28/67

28

LTE Procedures


Random Access Procedure

Random Access (RA) is the procedure used by the UE to move from an RRC_IDLE state

to RRC_CONNECTED state. The following 5 events use the RA procedure;

Initial access from RRC_IDLE;

Initial access after radio link failure;

Handover requiring random access procedure;

DL data arrival during RRC_CONNECTED requiring random access procedure;

UL data arrival during RRC_CONNECTED requiring random access procedure;

The RA process may also be;

Contention based

Non-Contention Based

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

29/67


Fig. 13 Random Access Events

Random Access ProceduresInitial access from RRC_IDLE

Initial access after radio link failure

Handover requiring random access

procedure

DL data arrival during RC_CONNECTED

requiring random access procedure

UL data arrival during RRC_CONNECTED

requiring random access procedure

Random Access TypesContention Based

Non- Contention Based

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

30/67

30

LTE Procedures


Contention Based Random Access

Contention based random access is a 4 step procedure that begins with UE transmitting a

Random Access preamble. The random access preamble is a 5bit random value chosen by

the UE. The RA preamble will be selected from a group of preamble that are not reserved for

non-contented access.

The RA response is returned to the UE and addressed to the RA-RNTI (unambiguously identifies

which time-frequency resource was utilized by the UE to transmit the Random Access preamble).

The RAPID (RA Preamble Identifier) identifies the preamble chosen by the UE. The response also

contains a temporary C-RNTI which will be upgraded to a permanent C-RNTI after successful

contention resolution. Uplink time alignment information, in 0.5S increments is present in the

response as well as an initial UL grant indicting when the next scheduled UL transmission should

take place as well as the maximum size of the UL transmission, for the UE to signal the next

stage of the RRC sequence, i.e. RRC bandwidth request, answer to paging etc.

The first scheduled transmission will pass information from the UE to the eNodeB, the nature

of the information depends on the reason for the RA procedure;

Initial access

RRC Connection Request from RRC layer via CCCH

NAS UE Identifier

RLC TM

After Radiolink Failure

RRC Connection Re-Establishment Request via CCCH

RLC TM

After Handover

Ciphered and integrity protected RRC Handover Confirm via DCCH

C-RNTI

Finally any contention in the channel will be resolved by the network returning a Contention

Resolution message containing the C-RNTI. This message promotes the temporary C-RNTI

to a permanent identity which will be used to identify the UE as long as the RRC_CONNECTED

mode remains.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

31/67

Random Access Preamble


Scheduled Transmission

Contention Resolution

[5 bit randomnumber]

[Timing Advance,UL Grant,

Temp C-RNTI,RAPID, addressed

to RA-RNTI]

[RRC ConnectionRequest, RRC

Re-EstablishmentRequest,

RRC HandoverConfirm;

NAS Message(TA Update,

Service RequestAttach), C-RNTI]

[C-RNTI]

CCCH,DCCH

DL-SCH

RACH

UE EPC


Fig. 14 Contention Based Random Access

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

32/67

32

LTE Procedures


Non-Contention Based Random Access

This procedure is used when the eNodeB already has a reference for the requesting

terminal. It is applicable for cases of downlink transmission resumption when the UE

is in the RRC_CONNECTED state and for inter-eNodeB handover cases. At some point

in previous transactions the UE will have been allocated a contention free preamble which

does not belong to the random access preambles broadcast on the BCH. This is likely to

have been allocated to the UE during handover procedure or during data transfer.

The UE will then perform UL random access on the RACH and wait for a response on the

DL SCH. As before the random access response contains the timing alignment, UL grant,

RAPID and also timing alignment for DL data arrival.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

33/67

RA Preamble Assignment[Handover,

DL Tx Resume,AssignedPreamble]

DCCH

Random Access Preamble [AssignedPreamble]RACH


[Timing Advance,UL Grant,

C-RNTI, RAPID,addressedto RA-RNTI]

DL-SCH

UE EPC


Fig. 15 Non-Contention Based Random Access

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

34/67

34

LTE Procedures


Establishing RRC Connections

In order that signalling or data can be transmitted UL or DL an RRC connection must exist.

This procedure is used to establish a signalling radio bearer (SRB), SRB1 and to optionally

convey NAS signalling to the EPC.

Once SRB1 has been established SRB2 will be setup to convey other lower priority signalling

and to initiate the security procedures across the air interface. SRB2 will also be used to setup

and negotiate Data RB (DRB) in the user plane.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

35/67

RRC Connection Request [followingRA Response,

C-RNTI]

RRC_IDLE

RRC Connection Setup[SRB1

Establishment,RR Config,RLC Setup,]

RRC Connection Setup Complete [PLMN Identity,MME Identity NAS

Dedicated info]

UE EPC

RRC_CONNECTED

Establish SRB2, DRB,Security Mode


Fig. 16 RRC Connection Setup

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

36/67

36

LTE Procedures


Registration Procedure

The registration procedure allows the mobile to identify itself to the network and to register

for services supported by the network and the users subscription. It serves as a valuable

network entry procedure allowing security procedures to be initiated and the initial bearer

to be established.

4 main purposes are served by the registration procedure;

Mutual user-EPC authentication

Allocation of a NAS temporary identity to protect the IMSI

User location registration (TA registration) to support paging

Establishment of the default or initial bearer, supporting always on connectivity for

certain services

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

37/67


Fig. 17 Main Reasons for the Registration Process

Registration PurposeMutual user-EPC authentication

Allocation of a NAS temporary identity

to protect the IMSI

User location registration (TA registration)

to support paging

Establishment of the default or initial

bearer, supporting always on connectivity

for certain services

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

38/67

38

LTE Procedures


Registration Procedure

The registration procedure begins with the UE establishing an RRC connection (1) followed

by the Attach Request (2) which is forwarded to the MME. The user identity may be the IMSI

or a previously allocated S-TMSI. The S-TMSI can be used to locate subscriber information

stored in the last registered MME, prompting the forwarding of user MM context data, security

information and other subscription related information. Once the MME has recovered some

subscriber details it can begin the security process (3), namely AKA (Authentication Key

Agreement), AKA procedure is very similar to that used in UMTS, i.e. random challenge is

used to generate a unique response and additional keys that are used to generate cipher

keys. The MME then recovers the subscriber data from the HSS (Home Subscriber Server)

and updates the location of the user in the HSS (4).

The MME then coordinates the establishment of the initial bearer with the Serving Gateway

and PDN Gateway. The EMM Attach Accept message is piggybacked in the RB EstablishmentRequest message and the response is similarly embedded in the RD Establishment Response (5).

The completion of this procedure has opened up a user plane radio bearer allowing upper layer

applications to make use of the connection to register for user level services, e.g. sign in to a

mail server, sign on to a IM server, register on a SIP server to allow incoming calls.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

39/67

Attach Request (IMSI, S-TMSI)

Update Location (IMSI)

Insert Subscriber Data

Insert Subscriber Data AckUpdate Location Ack

Create Bearer Request

Create Bearer Response

Attach Accept (new S-TMSI)

RB Est Req (Attach Accept)

RB Est Res (Attach Complete)

Attach Complete

1

2

3

4

5

UE

MMEHSS

Serving GWeNB PDN GW

S6

SGiS5S1 S11

Random accessprocedure

Authentication(AKA)


Fig. 18 Registration Procedure

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

40/67

40

LTE Procedures


EMM State Machine

The diagram opposite shows in detail the 8 possible states for the Evolved Mobility Management

(EMM) state machine.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

41/67

EnableS1 mode

Network init. DETACH requestedLocal DETACH

DisableS1 mode

ATTACHrequested

ATTACHaccepted

DETACH requested(not power off

DETACH acceptedLower layer failure

ATTACH rejectedNetwork init. DETACH requested

Lower layer failure

EMM-NULL

TAU acceptedTAU failed

TAU rejected(#13, #15)

TAUrequested

TAUrejected

EMM-TRACKING-AREA-UPDATING-

INITIATED

EMM-DEREGISTERED

EMM-REGISTERED

Any state

DETACHrequested(power off)

SRinitiated

SR acceptedSR failed

EMM-SERVICEREQUEST

INITIATED

EMM-REGISTERED

INITIATED

EMM-DEREGISTERED

INITIATED


Fig. 19 Detailed State Transitions for EMM Machine

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

42/67

42

LTE Procedures


Service Request and Initial Bearer Establishment

The sequence shown opposite describes a slightly dif ferent scenario for the establishment of

the radio bearers. This sequence is likely to happen when a UE returns to RRC_CONNECTED

from a time out IDLE period. The triggering of the random preamble may be the result of data

from upper layers requesting transmission from the UE or the result of DL data triggering a

paging request from the EPC. In either case the EPS bearer that was established at registration

or established during previous service requests is maintained in the EPC and only requires

re-connection.

In this sequence, once the security procedures are complete the MME begins the process

of re-establishing existing default and dedicated bearers by sending the Initial Context

Setup Request to the eNodeB. The eNodeB will then create a UE context which is used

for scheduling data transfer UL and DL to the UE.

Once the RB has been established across the radio interface the MME then updates the

context data at the Serving GW. The Serving GW does not need to exchange signalling with

the PDN GW, since the PDN GW has maintained the EPS bearer context whilst the UE was

in the IDLE state.

It should be noted that as well as setting up resources across the radio interface the procedures

described here will also trigger resource management across the other interfaces of the EPC.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

43/67

Preamble

Response

Contention Resolution

RRC Connection Re-Config

RRC Connection Re-Config Complete

Initial Context Setup Req [EPS Bearer QoS]

RB Est Req

RB Est Res

Initial Context Setup Complete

Update Bearer Request

Update Bearer Response

RRC Connection Req (Service Request)

Initial UE Message (Service Request)

UE

MMEHSS

Serving GWeNB PDN GW

S6

SGiS5S1 S11

Authentication(AKA)

Application Level Signalling (SIP/SPD) with IMS

Dedicated Bearer Establishment [QoS, IP Address, APN]


Fig. 20 Service Request and Initial Bearer Establishment

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

44/67

44

LTE Procedures


ESM State Machine

The diagram opposite shows in detail the possible state transitions for the Evolved Session

Management (EMS) state machine. The messaging exchanged between the peer EMS will

depending on the current state of the machine.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

45/67

ModifyEPSbearer

contextrequest

PDN connectivityreject or

bearer resourceallocation reject

ModifyEPSbearer

c

ontextaccept/reject

Activ

atedefa

ultEPS

bea

rer

contex

treje

ctor

Activ

ated

edica

tedEPS

bea

rer

contex

treje

ct

Activate

defaultEPSbearer

contextacceptor

ActivatededicatedEPSbearer

contextaccept

DeactivateEPSbearer

contextaccept

Activ

ated

efault

EPS

bea

rer

contex

treq

uest

or

Activ

ated

edica

tedEP

Sbe

arer

contex

treq

uest

Deac

tivateE

PSbea

rer

contex

treq

uest

Deac

tivateE

PSbea

rer

contex

treje

ct

Bearer contextinactive

Bearer contextactive

Bearer contextmodify pending

Bearer contextactive pending

Bearer contextinactive pending


Fig. 21 Detailed State Transitions for ESM Machine

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

46/67

46

LTE Procedures


Bearer Modification with Bearer QoS Update

PDN GW initiated bearer modification with bearer QoS update

With the UE in active mode this procedure is used when one or more of the EPS Bearer QoS

parameters GBR, MBR or ARP are modified. It is also used if the QCI of the default EPS bearer

is modified due to the HSS Initiated Subscribed.QoS Modification procedure.

If dynamic PCC is deployed, the PCRF sends a PCC decision provision message to the PDN

GW, however If dynamic PCC is not deployed, the PDN GW may apply local QoS policy.

The PDN GW uses this QoS policy to determine if the authorized QoS of a service data flow has

changed or if it should be aggregated to or removed from an active bearer. It will then generate

the TFT and update the EPS Bearer QoS to match the traffic flow aggregate. It will then send

the Update Bearer Request message to the S-GW.

The S-GW sends the Update Bearer Request message to the MME. If the UE is in ECM IDLEstate the MME will trigger the Network Triggered Service Request. In that case the following steps

may be combined into Network Triggered Service Request procedure or be performed standalone.

The MME then sends the Bearer Modify Request (EPS Bearer Identity, EPS Bearer QoS, Session

Management Request, UE AMBR) message to the eNodeB.

The eNodeB maps the modified EPS Bearer QoS to the Radio Bearer QoS and signals a RRC

Connection Reconfiguration message to the UE. The UE stores the QoS Negotiated, Radio

Priority, Packet Flow Id, received in the Session Management Request, for use when accessing

via GERAN or UTRAN. It uses the uplink packet filter (UL TFT) to determine the mapping of

traffic flows to the radio bearer.

The UE acknowledges the radio bearer modification to the eNodeB with a RRC Connection

Reconfiguration Complete message. The eNodeB acknowledges the bearer modification to

the MME with a Bearer Modify Response message indicating if the requested EPS Bearer

QoS could be allocated or not.

The UE NAS layer builds a Session Management Response including EPS Bearer Identity.

The UE then sends a Direct Transfer (Session Management Response) message to the eNodeB

which then sends an Uplink NAS Transport message to the MME.

On reception of the Bearer Modify Response and Session Management Response messagethe MME acknowledges the bearer modification to the S-GW by sending an Update Bearer

Response message which acknowledges the bearer modification to the PDN GW by sending

an Update Bearer Response message.

If the Bearer modification procedure was triggered by a PCC Decision Provision message,

the PDN GW informs the PCRF if the requested PCC decision could be enforced by sending

a Provision Ack message allowing the completion of the PCRF-Initiated IP CAN Session

Modification procedure.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

47/67

3. Update BearerRequest

4. Bearer ModifyRequest/Session

ManagementRequest

5. RRC ConnectionReconguration

6. RRC ConnectionReconguration

Complete7. Bearer Modify

Response

10. Update BearerResponse

11. Update BearerResponse 12. PCRF Initiated

IP CAN SessionModication, end

9. SessionManagement

Response

8. Direct transfer

2. Update BearerRequest

(A)

(B)

1. PCRF InitiatedIP CAN Session

Modication, begin

UE PCRFPDNGW

ServingGW

MMEeNodeB


Fig. 22 PDN GW Initiated Bearer Modification with Bearer QoS Update

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

48/67

48

LTE Procedures


HSS Initiated Subscribed QoS Modification with modified QCI and/or ARP parameters

The HSS sends an Insert Subscriber Data message to the MME which includes EPS

subscribed QoS (QCI, ARP) and the subscribed UE-AMBR and APN AMBR.

If the subscribed UE-AMBR has been modified, the MME calculates a new UE-AMBR value

as and may then signal a modified UE-AMBR value to the eNodeB by using S1-AP UE Context

Modification Procedure.

If the UE-AMBR is the only parameter that has been modified, the HSS Initiated Subscribed

QoS Modification Procedure ends on completion of the UE Context Modification Procedure.

If the QCI, ARP and/or the subscribed APN-AMBR have been modified the MME sends the

Update Bearer Request message to the S-GW. The EPS Bearer QoS contains the EPS

subscribed QoS profile to be updated.

The Serving GW sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS,APN AMBR) message to the PDN GW which informs the PCRF about the bearer QoS update

which sends the updated PCC decision to the PDN GW.

The PDN GW sends the Update Bearer Request message to the Serving GW.

If the QCI and/or ARP parameter(s) have been modified the Serving GW sends the Update

Bearer Request message to the MME which will build a Session Management Request

including the PTI, EPS Bearer QoS parameters (excluding ARP), TFT, APN AMBR and EPS

Bearer Identity. If the UE has UTRAN or GERAN capabilities, the MME uses the EPS Bearer

QoS information to derive the corresponding PDP context parameters QoS Negotiated,

Radio Priority and Packet Flow Id and includes them in the Session Management Request.

If the UE indicated in the UE Network Capability that it does not support BSS packet flow

procedures, then the MME Packet Flow Id is not included. If the APN AMBR has changed

the MME may update the UE AMBR if appropriate.

The MME will then send the Bearer Modify Request message to the eNodeB which maps

the modified EPS Bearer QoS to the Radio Bearer QoS and then signals a RRC Connection

Reconfiguration message to the UE.

The UE stores the QoS Negotiated, Radio Priority, Packet Flow Id, received in the Session

Management Request, to use when accessing via GERAN or UTRAN and acknowledges theradio bearer modification to the eNodeB with a RRC Connection Reconfiguration Complete

message. A Bearer Modify Response (EPS Bearer Identity) message is then sent to the MME

to indicate if the requested EPS Bearer QoS could be allocated or not.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

49/67


Update BearerRequest


Update Bearer

Request


Bearer ModifyRequest/Session

ManagementRequestRRC

ConnectionReconfiguration

RRC ConnectionReconfiguration

CompleteBearer Modify

Response

Direct Transfer SessionManagement

ResponseUpdate Bearer

Request

PCEF InitiatedIP-CAN SessionModification

Update BearerResponse

Provision Ack

UE Ctxt Update

UE HSSPCRFPDNGW

ServingGW

MMEeNodeB


Fig. 23 HSS Initiated Subscribed QoS Modification with Modified QCIand/or ARP Parameters

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

50/67

50

LTE Procedures


The UE NAS layer builds a Session Management Response including EPS Bearer Identity and

sends a Direct Transfer (Session Management Response) message to the eNodeB that sends

an Uplink NAS Transport (Session Management Response) message to the MME.

Once the MME has received the Bearer Modify Response and Session Management Response

message it will send an Update Bearer Response (EPS Bearer Identity) message to the S-GW

to acknowledge the bearer modification.

The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update

Bearer Response (EPS Bearer Identity) message. The PDN GW then sends a Provision Ack

message to the PCRF to inform it that the requested PCC decision was enforced or not.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

51/67




Update Bearer

Request


Bearer ModifyRequest/Session

ManagementRequestRRC

ConnectionReconfiguration

RRC ConnectionReconfiguration

CompleteBearer Modify

Response

Direct Transfer SessionManagement

ResponseUpdate Bearer

Request

PCEF InitiatedIP-CAN SessionModification


Provision Ack

UE Ctxt Update

UE HSSPCRFPDNGW

ServingGW

MMEeNodeB


Fig. 23 HSS Initiated Subscribed QoS Modification with Modified QCIand/or ARP Parameters

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

52/67

52

LTE Procedures


HSS Initiated Subscribed QoS Modification without Modified QCI and/or ARP Parameters

The HSS sends an Insert Subscriber Data message to the MME which includes EPS

subscribed QoS (QCI, ARP) and the subscribed UE-AMBR and APN AMBR.

If the subscribed UE-AMBR has been modified, the MME calculates a new UE-AMBR value

as and may then signal a modified UE-AMBR value to the eNodeB by using S1-AP UE Context

Modification Procedure.

If the UE-AMBR is the only parameter that has been modified, the HSS Initiated Subscribed

QoS Modification Procedure ends on completion of the UE Context Modification Procedure.

If the QCI, ARP and/or the subscribed APN-AMBR have been modified the MME sends the

Update Bearer Request message to the S-GW. The EPS Bearer QoS contains the EPS

subscribed QoS profile to be updated.

The Serving GW sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS,APN AMBR) message to the PDN GW which informs the PCRF about the bearer QoS update

which sends the updated PCC decision to the PDN GW.

The PDN GW sends the Update Bearer Request message to the Serving GW.

If neither the QCI nor ARP are modified, however the APN-AMBR has been updated, the

Serving GW sends the Update Bearer Request (PTI, EPS Bearer Identity, APN-AMBR, TFT)

message to the MME.

The MME builds a Session Management Request message including the TFT, APN-AMBR

and EPS Bearer Identity. The MME then sends a Downlink NAS Transport (SessionManagement Configuration) message to the eNodeB. If the APN AMBR has changed, the

MME may also update the UE AMBR.

The Direct Transfer (Session Management Request) message is sent to UE which uses the

uplink packet filter (UL TFT) to determine the mapping of traffic flows to the radio bearer and

stores the modified APN-AMBR value.

The UE NAS layer builds a Session Management Response including EPS Bearer Identity.

The UE then sends a Direct Transfer (Session Management Response) message to the

eNodeB which responds by sending Uplink NAS Transport (Session Management Response)

message to the MME. An Update Bearer Response (EPS Bearer Identity) message is sentto acknowledge the bearer modification.

The Serving GW acknowledges the bearer modification to the PDN GW by sending an Update

Bearer Response (EPS Bearer Identity) message. The PDN GW then sends a Provision Ack

message to the PCRF to inform it that the requested PCC decision was enforced or not.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

53/67




Update Bearer

Request


Downlink NASTransport

Direct Transfer

Uplink NASTransport

Direct Transfer


PCEF InitiatedIP-CAN SessionModication


Provision Ack

UE HSSPCRFPDNGW

ServingGW

MMEeNodeB

UE Ctxt Update


Fig. 24 HSS Initiated Subscribed QoS Modification without Modified QCIand/or ARP Parameters

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

54/67

54

LTE Procedures


E-UTRAN to UTRAN Iu Mode Inter RAT HO, Preparation Phase

Preparation Phase

The source eNodeB initiates a handover by sending a Handover Required message to the

MME to request resources on the target RNC, SGSN and the Serving Gateway are established.

The Bearers Requesting Data Forwarding List contains the list of bearers for which the source

eNodeB has decided that data forwarding is necessary.

The EPS bearers are mapped to PDP contexts by the MME. These are then sent in a prioritised

order with the most important being sent first. The MME initiates the handover allocation

procedure by sending a forward relocation request message to the target SGSN. This will

determine if the S-GW is relocated, if it is the target SGSN will select the S-GW on Serving

GW selection function and send a create PDP context to the target S-GW which will allocate

the local resources and return a Create PDP Context Response message to the target SGSN.

The target SGSN requests the target RNC to establish the radio network resources (RABs) by

sending the message Relocation Request. The target SGSN will not request resources for

which the Activity Status Indicator within a PDP Context indicates that no active radio bearer

exist on the source side for that PDP Context.

The Transport Layer Address is the S-GW Address for user plane (in case Direct Tunnel

is used) or the SGSN Address for user plane (in case Direct Tunnel is not used), and the Iu

Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data in Serving

GW or SGSN respectively.

Ciphering and integrity protection keys are sent to the target RNC to allow data transferto continue in the new RAT/mode target cell without requiring a new AKA procedure.

The target RNC allocates the resources and returns the applicable parameters to the

target SGSN in the Relocation Request Acknowledge. The target RNC is now able to receive

downlink GTP PDUs from the S-GW, or Target SGSN in case Direct Tunnel is not used.

Each RAB is defined by a Transport Layer Address, for user data this is the target RNC

Address, and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint

Identifier for user data.

If Indirect Forwarding and relocation of Serving GW applies the target SGSN sends a CreatePDP Context Request message to the target Serving GW.

The target Serving GW returns a Create PDP Context Response (Cause, Serving GW DL

TEID(s)) message to the target SGSN.

INTER-WORKING WITH 3GPP NETWORKS

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

55/67

Handover Required

Create PDP Context Request

Create PDP Context Response

Relocation Request

Relocation RequestAcknowledge





ForwardRelocationResponse

ForwardRelocationRequest

UE HSSPDNGW

TargetServing

GW

ServingGW

TargetSGSN

SourceMME

TargetRNC

SourceeNodeB

Uplink and Downlink User Plane PDUs

Handover Initiation


Fig. 25 E-UTRAN to UTRAN Iu Mode Inter RAT HO, Preparation Phase

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

56/67

56

LTE Procedures


The target SGSN sends the Forward Relocation Response to the source MME. Serving GW

change indication indicates a new Serving GW has been selected.

The IE Address(es) and TEID(s) for User Traffic Data Forwarding defines the destination

tunnelling endpoint for data forwarding in target system, and it is set as follows.

Direct forwarding

If Direct Forwarding is applicable, then the IE Address (es) and TEID(s) for User Traffic Data

Forwarding contains the DL GTP-U tunnel endpoint parameters to the Target RNC

Indirect forwarding

If Indirect Forwarding is applicable when Direct Tunnel is used the IE Address(es) and TEID(s)

for User Traffic Data Forwarding contains the DL GTP-U tunnel endpoint parameters to the

Target RNC or the Target Serving GW for Serving GW re-location.

If Indirect Forwarding is applicable when Direct Tunnel is not used the IE Address(es) andTEID(s) for User Traffic Data Forwarding contains the DL GTP-U tunnel endpoint parameters

to the Target SGSN or the Target Serving GW in case of Serving-GW re-location.

If the Direct Forwarding is not applicable, the Source MME sends the message Create Bearer

Request (Cause, Address(es) and TEID(s) for Data Forwarding, EPS Bearer ID(s)) to the Serving

GW used for indirect packet forwarding. The Cause indicates that the bearer(s) are subject to

data forwarding.

Indirect forwarding may be performed via a Serving GW which is different from the Serving

GW used as the anchor point for the UE.

The Serving GW returns the forwarding parameters by sending the message Create Bearer

Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding).

If the Serving GW doesnt support data forwarding, an appropriate cause value is returned

and the S-GW Address and TEID(s) are not included in the message.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

57/67

Handover Required



Relocation Request

Relocation RequestAcknowledge





ForwardRelocationResponse

ForwardRelocationRequest

UE HSSPDNGW

TargetServing

GW

ServingGW

TargetSGSN

SourceMME

TargetRNC

SourceeNodeB


Handover Initiation


Fig. 25 E-UTRAN to UTRAN Iu Mode Inter RAT HO, Preparation Phase

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

58/67

58

LTE Procedures


E-UTRAN to UTRAN Iu Mode Inter RAT HO, Execution Phase

The source eNodeB continues to receive downlink and uplink user plane PDUs. And the source

MME completes the preparation phase towards the source eNodeB by sending the Handover

Command. The source eNodeB initiates data forwarding for bearers specified in the Bearers

Subject to Data Forwarding List either directly to the target RNC or via the Serving GW. This

is decided by the source MME and/or target SGSN in the preparation phase.

The source eNodeB will command the UE to handover to the target access network via the

message HO from E-UTRAN Command. On receipt of this the UE associates its bearer IDs

to the respective RABs based on the relation with the NSAPI and suspends the uplink

transmission of the user plane data.

The eNodeB informs the source MME which then informs the target SGSN of the delivery order

parameters in the Forward SRNS Context. The Target SGSN forwards this to the Target RNC.

The UE moves to the target UTRAN Iu (3G) system and executes the handover according to

the parameters provided. The UE may resume the user data transfer only for those NSAPIs for

which there are radio resources allocated in the target RNC.

When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target

RNC sends the Relocation Complete message to the target SGSN indicating the completion

of the relocation from the source E-UTRAN to the RNC.

Once this message is received the target SGSN is ready to receive data from the target RNC.

Each uplink N-PDU received by the target SGSN is forwarded directly to the Serving GW.

The target SGSN informs the source MME by sending the Forward Relocation Complete

message which will respond with an acknowledgement. A timer is started in the MME to

supervise when resources in the Source eNodeB and Source Serving GW (for Serving GW

relocation) may be released.

When the timer expires and ISR Activated is not indicated by the target SGSN the source MME

releases all the bearer resources used by the UE. If S-GW change is indicated and the timer

expires the source MME deletes the EPS bearer resources by sending Delete Bearer Request

messages to the Serving GW. This indicates to the old S-GW that the S-GW changes and the

old S-GW should not initiate a delete procedure towards the PDN GW.

The target SGSN completes the Handover procedure by informing the S-GW (for S-GW

relocation this will be the Target Serving GW) that the target SGSN is now responsible for all

the PDP Context in the Update PDP Context Request message. If a PDP context is going to

be released the SGSN triggers the PDP context deactivation procedure.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

59/67

Uplink and Downlink User Plane PDUs (via Target SGSN in case Direct Tunnel is not used)

Update PDPContext Response

UTRAN lu Access Procedures

Sending ofuplink data

possible

Forward SRNS Context


Forward SRNS Context Ack

Handover toUTRAN Complete

Handover CommandHO fromE-UTRANCommand

Forward SRNSContext

Forward SRNSContext Ack

Forward RelocationComplete

Forward RelocationComplete Acknowledge

UE HSSPDNGW

TargetServing

GW

ServingGW

TargetSGSN

SourceMME

TargetRNC

SourceeNodeB


Delete Bearer Request

Release Resources

Delete Bearer Response

Downlink User Plane PDUs

Via Target SGSN in case Direct Tunnel is not used

Relocation Complete

Update PDP

Context Request

Only if Direct Forwarding is applicable



Routing Area Update procedure


Fig. 26 E-UTRAN to UTRAN Iu Mode Inter RAT HO, Execution Phase

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

60/67

60

LTE Procedures


The S-GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN

GW(s) the change of for example for Serving GW relocation or the RAT type that e.g. can be

used for charging, by sending the Update Bearer Request message. The PDN GW must

acknowledge the request with a Update Bearer Response. If PCC infrastructure is used, thePDN GW informs the PCRF about the change of, for example, the RAT type.

The S-GW acknowledges the user planes switch to the target SGSN via the Update PDP Context

Response. At this stage the user plane path is established for all PDP contexts between the UE,

target RNC, target SGSN in case Direct Tunnel is not used, Serving GW and PDN GW.

When the UE recognises that its current Routing Area is not registered with the network, or when

the UEs update status of the P-TMSI is update-needed, the UE initiates a Routeing Area Update

procedure with the target SGSN informing it that it is located in a new routing area. The target

SGSN performs only a subset of the RAU procedure; specifically it excludes the context transfer

procedures between source MME and target SGSN.

When the timer in the MME expires it will send a Release Resources message to the Source

eNodeB. The Source eNodeB releases its resources related to the UE.

If the source MME received the Serving GW change indication in the Forward Relocation Response

message and the timer expires, it deletes the EPS bearer resources by sending the Delete Bearer

Request (Cause, TEID) messages to the Source Serving GW. The Source Serving GW acknowledges

with Delete Bearer Response (TEID) messages.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

61/67

Uplink and Downlink User Plane PDUs (via Target SGSN in case Direct Tunnel is not used)

Update PDPContext Response

UTRAN lu Access Procedures

Sending ofuplink data

possible



Forward SRNS Context Ack

Handover toUTRAN Complete

Handover CommandHO fromE-UTRANCommand

Forward SRNSContext

Forward SRNSContext Ack

Forward RelocationComplete

Forward RelocationComplete Acknowledge

UE HSSPDNGW

TargetServing

GW

ServingGW

TargetSGSN

SourceMME

TargetRNC

SourceeNodeB


Delete Bearer Request

Release Resources

Delete Bearer Response

Downlink User Plane PDUs

Via Target SGSN in case Direct Tunnel is not used

Relocation Complete

Update PDP

Context Request

Only if Direct Forwarding is applicable



Routing Area Update procedure


Fig. 26 E-UTRAN to UTRAN Iu Mode Inter RAT HO, Execution Phase

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

62/67

62

LTE Procedures


The EPS is able to provide IP connectivity from a non-3GPP type of access using the Evolved

Packet Core.

In a non-roaming scenario it is the HPLMNs operator decision if a non-3GPP IP access network

is used as Trusted or Untrusted non-3GPP Access Network. In a roaming scenario, the HSS/3GPP

AAA Server in HPLMN decides if a non-3GPP IP access network is used as Trusted or Untrusted

non-3GPP Access Network. The HSS/3GPP AAA Server may take the VPLMNs policy and capability

returned from the 3GPP AAA Proxy or roaming agreement into account.

A trusted network is where the access network is controlled by the operator itself or by another entity

(local operator or service provider) which can be trusted due to the existence of mutual agreements.

An untrusted network is one where there are no agreements in place or where for example the

owner of a WLAN is able to offer 3GPP connectivity.

Whether a Non-3GPP IP access network is Trusted or Untrusted is not a characteristic of theaccess network.

When supporting multiple PDNs, the same trust relationship applies to all of the PDNs that the

UE connects to from a certain non-3GPP Access Network, so that it is not possible to access

one PDN using the non-3GPP access network as Trusted, while access to another PDN using

the same non-3GPP access network as Untrusted.

Terminal location management is under the responsibility of the WLAN Access as well as the

packet session signalling and does not need any support from 3GPP EPC nodes (aside from

the provision of 3GPP security credentials).

SUPPORT FOR NON-3GPP ACCESSES

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

63/67

SGi

S5

S11S6a

SWx

STa

S2a

Trusted

WLAN access

Non-3GPP network 3GPP network

S1-C S1-U

Rx

Gx

HSS ServingGW

PDNGW

MME

3GPP AAAserver

PCRF

IP/IMS

E-UTRAN

SWx

SWa

3GPP AAAserver

S5

S11

S1-C S1-U

ServingGW

MME

E-UTRAN

SGi

S2bSWn

Untrusted

WLAN access

Non-3GPP network 3GPP network

Rx

GxPDNGW

ePDN

PCRF

IP/IMS

HSS


Fig. 27 Trusted and Untrusted Non-3GPP Access Network Architecture

Trusted Network Architecture

Untrusted Network Architecture

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

64/67

64

LTE Procedures


Non-3GPP Access Network Architecture

There are a number of additional network nodes and interfaces required to support non-3GPP

access types. As the AAA (Authentication, Authorization and Accounting) mechanisms for

mutual authentication and access control are based on known IETF protocols only minor

software changes are required within the terminal equipment.

The 3GPP AAA Server acts as an inter-working unit between the 3GPP network and IETF

standard-driven WLAN networks enabling end-to-end authentication with WLAN terminals

using 3GPP credentials.

For Untrusted non-3GPP accesses the EPS, an external Packet Data Gateway (ePDG) is used.

The functionality of ePDG includes the following:

Allocation of a remote IP address as an IP address local to the ePDG which is used when

S2c is used;

Transportation of a remote IP address as an IP address specific to a PDN when S2b is used;

Routing of packets from/to PDN GW (and from/to Serving GW if it is used as local anchor in

VPLMN) to/from UE;

De-capsulation/Encapsulation of packets for IPSec and PMIP tunnels (the latter only if network

based mobility (S2b) is used);

Mobile Access Gateway (MAG) if network based mobility (S2b) is used;

Tunnel authentication and authorization (termination of IKEv2 signaling and relay via AAA

messages);

Local mobility anchor within Untrusted non-3GPP access networks using MOBIKE (if needed);

Transport level packet marking in the uplink;

Enforcement of QoS policies based on information received via AAA infrastructure;

Lawful Interception;

llocation of GRE key, which is used to encapsulate downlink traffic to the ePDG on the

PMIP-based S2b interface.

A UE connected to one or multiple PDN GWs uses a single ePDG. In case of handover between

ePDGs, the UE may be temporarily connected to two ePDGs.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

65/67

HPLMN

Non-3GPP

networks

PDNgateway

3GPPAAA server

3GPPaccess

Untrustednon-3GPPIP access

Trustednon-3GPPIP access

OperatorsIP services(e.g. IMS,PSS etc)

Servinggateway

HSS

PCRF

ePDG

UE

SWx

S6a

Gxc

GxRx

SGi

S6b

Gxb

Gxa

S2b

S2a

SWu

SWn

SWh

SWa

STa

S5


Fig. 28 Non-3GPP Access Network Architecture

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

66/67

66

LTE Procedures


To support non-3GPP accesses the EPS uses the following interfaces:

S2a: The S2a interface provides the user plane with related control and mobility support

between Trusted non-3GPP IP access and the PDN Gateway. S2a is based on Proxy Mobile

IPv6 (PMIP) and to support accesses that do not support PMIP or Mobile IPv4.

S2b: The S2b interface provides the user plane with related control and mobility support

between ePDG and the PDN Gateway. S2b is based on the Proxy Mobile IPv6 (PMIP).

S2c: The S2c interface provides the user plane with related control and mobility support

between UE and the PDN Gateway. It is implemented over Trusted and/or Untrusted non-

3GPP Access and/or 3GPP access and it is based on the DS-MIPv6 protocol.

S6b: The S6b interface is is the reference point between PDN Gateway and 3GPP AAA

server/proxy for mobility related authentication if needed.

Gxa: The Gxa interface provides transfer of (QoS) policy information from PCRF to the

Trusted non-3GPP accesses.

Gxc: The Gxc interface provides transfer of (QoS) policy information from PCRF to the

Serving Gateway.

PMIP-based S8: S8 is the roaming interface in case of roaming with home routed traffic.

It provides the user plane with related control between Gateways in the VPLMN and HPLMN.

SWa: The SWa interface connects the Untrusted non-3GPP IP Access with the 3GPP AAA

Server/Proxy for transport of access authentication, authorization and charging-related information.

STa: The STa interface is the equivalent of SWa for Trusted non-3GPP IP Accesses.

SWd: The SWa interface connects the 3GPP AAA Proxy to the 3GPP AAA Server.

SWm: The SWm interface is used for AAA signaling (transport of mobility parameters, tunnel

authentication and authorization data).SWn: The SWn interface is the reference point between the Untrusted non-3GPP IP Access

and the ePDG, is has the same functionality as Wn which is defined in TS 23.234 for

interworking between 3GPP systems and WLAN.

SWu: The SWu interface handles the support for IPSec tunnels between the UE and the ePDG.

SWx: The SWx interface is used for transport of authentication data between 3GPP AAA

Server and HSS.

5/27/2018 LTE_Tech_Ov_Sec05_091009_v01

67/67

HPLMN

Non-3GPP

networks

PDNgateway

3GPPAAA server

3GPPaccess

Untrustednon-3GPPIP access

Trustednon-3GPPIP access

OperatorsIP services(e.g. IMS,PSS etc)

Servinggateway

HSS

PCRF

ePDG

UE

SWx

S6a

Gxc

GxRx

SGi

S6b

Gxb

Gxa

S2b

S2a

SWu

SWn

SWh

SWa

STa

S5

Fig. 28 Non-3GPP Access Network Architecture

Documents

LTE_Tech_Ov_Sec05_091009_v01