girl什么意思LTE 切换信令流程

2021年1月19日发(作者：token是什么意思)


Handover
1 Intra-E-UTRAN handover
1.1 X2-based handover
1.1.1 General
These procedures are used to hand over a UE from a source eNodeB to a target eNodeB using the X2
reference point. In these procedures the MME is unchanged. Two procedures are defined depending on
whether the Serving GW is unchanged or is relocated. In addition to the X2 reference point between the
source and target eNodeB, the procedures rely on the presence of S1-MME reference point between the
MME and the source eNodeB as well as between the MME and the target eNodeB.
The handover preparation and execution phases are performed as specified in TS 36.300 [5]. If emergency
bearer services are ongoing for the UE handover to the target eNodeB is performed independent of the
Handover Restriction List. The MME checks, as part of the Tracking Area Update in the execution phase,
if the handover is to a restricted area and if so MME releases the non-emergency bearers as specified in
clause 5.10.3.
If the serving PLMN changes during X2-based handover, the source eNodeB shall indicate to the target
eNodeB (in the Handover Restriction List) the PLMN selected to be the new Serving PLMN.
When the UE receives the handover command it will remove any EPS bearers for which it did not receive
the corresponding EPS radio bearers in the target cell. As part of handover execution, downlink and
optionally also uplink packets are forwarded from the source eNodeB to the target eNodeB. When the UE
has arrived to the target eNodeB, downlink data forwarded from the source eNodeB can be sent to it.
Uplink data from the UE can be delivered via the (source) Serving GW to the PDN GW or optionally
forwarded from the source eNodeB to the target eNodeB. Only the handover completion phase is affected
by a potential change of the Serving GW, the handover preparation and execution phases are identical.
If the MME receives a rejection to a NAS procedure (e.g. dedicated bearer
establishment/modification/release; location reporting control; NAS message transfer; etc.) from the
eNodeB with an indication that an X2 handover is in progress (see TS 36.300 [5]), the MME shall
reattempt the same NAS procedure either when the handover is complete or the handover is deemed to
have failed, except in case of Serving GW relocation. The failure is known by expiry of the timer guarding
the NAS procedure.
If during the handover procedure the MME detects that the Serving GW needs be relocated, the MME shall
reject any PDN GW initiated EPS bearer(s) request received since handover procedure started and shall
include an indication that the request has been temporarily rejected due to handover procedure in progress.
The rejection is forwarded by the Serving GW to the PDN GW, with the same indication.
Upon reception of a rejection for an EPS bearer(s) PDN GW initiated procedure with an indication that the
request has been temporarily rejected due to handover procedure in progress, the PDN GW start a locally
configured guard timer. The PDN GW shall re- attempt, up to a pre-configured number of times, when
either it detects that the handover is completed or has failed using message reception or at expiry of the
guard timer.
If the MME receives a rejection to a UE Context Modification Request message with a CS Fallback
indicator from the eNodeB with an indication that an X2 handover is in progress, the MME shall resend a
UE Context Modification Request message with CS Fallback indicator to the target eNodeB when the
handover is complete or to the source eNB when the handover is deemed to have failed.
1.1.2
X2-based handover without Serving GW relocation
This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the
MME is unchanged and decides that the Serving GW is also unchanged. The presence of IP connectivity
between the Serving GW and the source eNodeB, as well as between the Serving GW and the target
eNodeB is assumed.

UE
Source
eNodeB
Target
eNodeB
Downlink and uplink data
Handover preparation
Handover execution
Forwarding of data
Handover completion


MME
Serving
GW
PDN GW
Downlink data
Uplink data
1 Path Switch Request
2 Modify Bearer Request
3a Modify Bearer Request
3b Modify Bearer Response
Downlink data
4 Modify Bearer Response
(A)

5. End marker
5. End marker
6 Path Switch Request Ack
7 Release Resource
8. Tracking Area Update procedure

Figure 1.1.2-1: X2-based handover without Serving GW relocation
NOTE 1:
For a PMIP-based S5/S8, procedure steps (A) are defined in TS 23.402 [2].
1.
The target eNodeB sends a Path Switch Request message to MME to inform that the UE has
changed cell, including the TAI+ECGI of the target cell and the list of EPS bearers to be switched.
If the target cell is a CSG cell , the target eNodeB includes the CSG ID of the target cell in Path
Switch Request message. If the target cell is in hybrid mode, it includes the CSG ID of the target
cell and CSG Access Mode set to
determines the CSG membership based on the CSG ID and CSG Access Mode received from the
target MME updates the User CSG information based on the CSG ID and CSG Access
Mode received from the target eNodeB and CSG membership if one of the parameters has changed.
NOTE 2:
X2 handover between HeNBs is possible when the handover is between closed/hybrid access
HeNBs having the same CSG ID or when the target HeNB is an open access HeNB.

The MME determines that the Serving GW can continue to serve the UE
2.
The MME sends a Modify Bearer Request (eNodeB address(es) and TEIDs for downlink user plane
for the accepted EPS bearers, ISR Activated) message per PDN connection to the Serving GW for
each PDN connection where the default bearer has been accepted by the target eNodeB. If the PDN
GW requested UE's location info, the MME also includes the User Location Information IE in this
message. If the UE Time Zone has changed, the MME includes the UE Time Zone IE in this
message. If the Serving Network has changed, the MME includes the new Serving Network IE in
this message. If ISR was activated before this procedure, MME should maintain ISR. The UE is
informed about the ISR status in the Tracking Area Update procedure. If the Serving GW supports
Modify Access Bearers Request procedure and if there is no need for the SGW to send the signalling
to the PGW, the MME may send Modify Access Bearers Request (eNodeB address(es) and TEIDs
for downlink user plane for the accepted EPS bearers, ISR Activated) per UE to the Serving GW to
optimize the signalling.


If the PDN GW requested UE's User CSG information (determined from the UE context), the MME
includes the User CSG Information IE in this message if the User CSG Information has changed.
The MME uses the list of EPS bearers to be switched, received in step 1, to determine whether any
dedicated EPS bearers in the UE context have not been accepted by the target eNodeB. The MME
releases the non- accepted dedicated bearers by triggering the bearer release procedure as specified in
clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW
drops the DL packet and does not send a Downlink Data Notification to the MME.
If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are
multiple PDN connections active, the MME shall consider all bearers of that PDN connection as
failed and release that PDN connection by triggering the MME requested PDN disconnection
procedure specified in clause 5.10.3.
If none of the default EPS bearers have been accepted by the target eNodeB or there is a LIPA PDN
connection that has not been released, the MME shall act as specified in step 6.


3.
If the Serving GW has received the User Location Information IE and/or the UE Time Zone IE
and/or the Serving Network IE and/or User CSG Information IE from the MME in step 2 the
Serving GW informs the PDN GW(s) about this information that e.g. can be used for charging, by
sending the message Modify Bearer Request (Serving GW Address and TEID, User Location
Information IE and/or UE Time Zone IE and/or Serving Network IE and/or User CSG Information
IE) per PDN connection to the PDN GW(s) concerned. The Serving GW shall return a Modify
Bearer Response (Serving GW address and TEID for uplink traffic) message to the MME as a
response to a Modify Bearer Request message, or a Modify Access Bearers Response (Serving GW
address and TEID for uplink traffic) as a response to a Modify Access Bearers Request message. If
the Serving GW cannot serve the MME Request in the Modify Access Bearers Request message
without S5/S8 signalling or without corresponding Gxc signalling when PMIP is used over the
S5/S8 interface, it shall respond to the MME with indicating that the modifications are not limited to
S1-U bearers, and the MME shall repeat its request using Modify Bearer Request message per PDN
connection.
4.
The Serving GW starts sending downlink packets to the target eNodeB using the newly received
address and TEIDs. A Modify Bearer Response message is sent back to the MME.
5.
In order to assist the reordering function in the target eNodeB, the Serving GW shall send one or
more
TS 36.300 [5], clause 10.1.2.2.
6.
The MME confirms the Path Switch Request message with the Path Switch Request Ack message.
If the UE-AMBR is changed, e.g. all the EPS bearers which are associated to the same APN are
rejected in the target eNodeB, the MME shall provide the updated value of UE-AMBR to the target
eNodeB in the Path Switch Request Ack message.

If some EPS bearers have not been switched successfully in the core network, the MME shall
indicate in the Path Switch Request Ack message which bearers failed to be established (see more
detail in TS 36.413 [36]) and for dedicated bearers initiate the bearer release procedure as specified
in clause 5.4.4.2 to release the core network resources of the failed dedicated EPS bearers. The
target eNodeB shall delete the corresponding bearer contexts when it is informed that bearers have
not been established in the core network.
If none of the default EPS bearers have been switched successfully in the core network or if they
have not been accepted by the target eNodeB or the LIPA PDN connection has not been released,
the MME shall send a Path Switch Request Failure message (see more detail in TS 36.413 [36]) to
the target eNodeB. The MME performs explicit detach of the UE as described in the MME initiated
detach procedure of clause 5.3.8.3.

7.
By sending Release Resource the target eNodeB informs success of the handover to source eNodeB
and triggers the release of resources. This step is specified in TS 36.300 [5].
8.
The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause

the Tracking Area Update Request, the MME should maintain ISR by indicating ISR Activated in
the Tracking Area Update Accept message.
NOTE 3:
It is only a subset of the TA update procedure that is performed by the MME, since the UE is
in ECM- CONNECTED state and the MME is not changed.
1.1.3
X2-based handover with Serving GW relocation
This procedure is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the
MME is unchanged and the MME decides that the Serving GW is to be relocated. The presence of IP
connectivity between the source Serving GW and the source eNodeB, between the source Serving GW and
the target eNodeB, and between the target Serving GW and target eNodeB is assumed. (If there is no IP
connectivity between target eNodeB and source Serving GW, it is assumed that the S1-based handover
procedure in clause 1.2 shall be used instead.)

UE

Source

eNodeB

Target

eNodeB

Downlink and uplink data

MME

Source

Target

Serving GW

Serving GW

PDN GW

Handover preparation

Handover execution

Forwarding of data

Handover completion

Downlink data

Uplink data

1. Path Switch Request

2. Create Session Request

4. Create Session Response

Downlink data

5. Path Switch Request Ack

Uplink data

3a. Modify Bearer Request

(A)

3b. Modify Bearer Response

6. Release Resource

7a. Delete Session Request

(B)

7b. Delete Session Response

8. Tracking Area Update procedure

Figure 1.1.3-1: X2-based handover with Serving GW relocation
NOTE 1:
For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2].
1.
The target eNodeB sends a Path Switch Request message to MME to inform that the UE has
changed cell, including the ECGI of the target cell and the list of EPS bearers to be switched. If the
target cell is a CSG cell , the target eNodeB includes the CSG ID of the target cell in Path Switch
Request message. If the target cell is in hybrid mode, it includes the CSG ID of the target cell and
CSG Access Mode set to
CSG membership based on the CSG ID and CSG Access Mode received from the target
MME updates the User CSG information based on the CSG ID and CSG Access Mode
received from the target eNodeB and CSG membership if one of the parameters has changed.
NOTE 2:
X2 handover between HeNBs is possible when the handover is between closed/hybrid access
HeNBs having the same CSG ID or when the target HeNB is an open access HeNB.

The MME determines that the Serving GW is relocated and selects a new Serving GW according to
clause 4.3.8.2 on
NOTE 3:
The MME knows the S-GW Service Area with a TA granularity.
2.
The MME sends a Create Session Request (bearer context(s) with PDN GW addresses and TEIDs
(for GTP-based S5/S8) or GRE keys (for PMIP- based S5/S8) at the PDN GW(s) for uplink traffic,
eNodeB address(es) and TEIDs for downlink user plane for the accepted EPS bearers, the Protocol
Type over S5/S8, Serving Network, UE Time Zone) message per PDN connection to the target
Serving GW for each PDN connection where the default bearer has been accepted by the target
eNodeB. The target Serving GW allocates the S-GW addresses and TEIDs for the uplink traffic on
S1_U reference point (one TEID per bearer). The Protocol Type over S5/S8 is provided to Serving
GW which protocol should be used over S5/S8 interface. If the PDN GW requested UE's location
info, the MME also includes the User Location Information IE in this message. If the PDN GW
requested UE's User CSG information (determined from the UE context), the MME includes the
User CSG Information IE in this message if the User CSG Information has changed.

The MME uses the list of EPS bearers to be switched, received in step 1, to determine whether any
dedicated EPS bearers in the UE context have not been accepted by the target eNodeB. The MME
releases the non-accepted dedicated bearers by triggering the bearer release procedure as specified in
clause 5.4.4.2 via target Serving GW. If the Serving GW receives a DL packet for a non-accepted
bearer, the Serving GW drops the DL packet and does not send a Downlink Data Notification to the
MME.
If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are
multiple PDN connections active, the MME shall consider all bearers of that PDN connection as
failed and release that PDN connection by triggering the MME requested PDN disconnection
procedure specified in clause 5.10.3 via source Serving GW.
If none of the default EPS bearers have been accepted by the target eNodeB or there is a LIPA PDN
connection that has not been released, the MME shall act as specified in step 5.


3.
The target Serving GW assigns addresses and TEIDs (one per bearer) for downlink traffic from the
PDN GW. The Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. It sends a
Modify Bearer Request (Serving GW addresses for user plane and TEID(s), Serving Network)
message per PDN connection to the PDN GW(s). The S-GW also includes User Location
Information IE and/or UE Time Zone IE and/or User CSG Information IE if it is present in step 2.
The PDN GW updates its context field and returns a Modify Bearer Response (Charging Id,
MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored
in its UE context. The PDN GW starts sending downlink packets to the target GW using the newly
received address and TEIDs. These downlink packets will use the new downlink path via the target
Serving GW to the target eNodeB. The Serving GW shall allocate TEIDs for the failed bearers and
inform to the MME.
4.
The target Serving GW sends a Create Session Response (Serving GW addresses and uplink
TEID(s) for user plane) message back to the target MME. The MME starts a timer, to be used in
step 7.
5.
The MME confirms the Path Switch Request message with the Path Switch Request Ack (Serving
GW addresses and uplink TEID(s) for user plane) message. If the UE-AMBR is changed, e.g. all the
EPS bearers which are associated to the same APN are rejected in the target eNodeB, the MME
shall provide the updated value of UE- AMBR to the target eNodeB in the Path Switch Request Ack
message. The target eNodeB starts using the new Serving GW address(es) and TEID(s) for
forwarding subsequent uplink packets.

If some EPS bearers have not been switched successfully in the core network, the MME shall
indicate in the Path Switch Request Ack message which bearers failed to be established (see more
detail in TS 36.413 [36]) and for dedicated bearers initiate the bearer release procedure as specified
in clause 5.4.4.2 to release the core network resources of the failed dedicated EPS bearers. The
target eNodeB shall delete the corresponding bearer contexts when it is informed that bearers have
not been established in the core network.

If none of the default EPS bearers have been switched successfully in the core network or if they
have not been accepted by the target eNodeB or the LIPA PDN connection has not been released,
the MME shall send a Path Switch Request Failure message (see more detail in TS 36.413 [36]) to
the target eNodeB. The MME performs explicit detach of the UE as described in the MME initiated
detach procedure of clause 5.3.8.3.
6.
By sending Release Resource the target eNodeB informs success of the handover to source eNodeB
and triggers the release of resources. This step is specified in TS 36.300 [5].
7.
When the timer has expired after step 4, the source MME releases the bearer(s) in the source
Serving GW by sending a Delete Session Request message (Cause, Operation Indication). The
operation Indication flag is not set, that indicates to the Source Serving GW that the Source Serving
GW shall not initiate a delete procedure towards the PDN GW. The Source Serving GW
acknowledges with Delete Session Response messages. If ISR has been activated before this
procedure, the cause indicates to the Source S-GW that the Source S-GW shall delete the bearer
resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node.
8.
The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause

NOTE 4:
It is only a subset of the TA update procedure that is performed by the MME, since the UE is
in ECM-CONNECTED state. The UE is informed about the ISR status in the Tracking Area
Update procedure.
1.2
1.2.1
S1-based handover
General
The S1-based handover procedure is used when the X2-based handover cannot be used. The source
eNodeB initiates a handover by sending Handover Required message over the S1-MME reference point.
This procedure may relocate the MME and/or the Serving GW. The source MME selects the target MME.
The MME should not be relocated during inter-eNodeB handover unless the UE leaves the MME Pool
Area where the UE is served. The MME (target MME for MME relocation) determines if the Serving GW
needs to be relocated. If the Serving GW needs to be relocated the MME selects the target Serving GW, as
specified in clause 4.3.8.2 on Serving GW selection function.
The source eNodeB decides which of the EPS bearers are subject for forwarding of downlink and
optionally also uplink data packets from the source eNodeB to the target eNodeB. The EPC does not
change the decisions taken by the RAN node. Packet forwarding can take place either directly from the
source eNodeB to the target eNodeB, or indirectly from the source eNodeB to the target eNodeB via the
source and target Serving GWs (or if the Serving GW is not relocated, only the single Serving GW).
The availability of a direct forwarding path is determined in the source eNodeB and indicated to the source
MME. If X2 connectivity is available between the source and target eNodeBs, a direct forwarding path is
available.
If a direct forwarding path is not available, indirect forwarding may be used. The source MME uses the
indication from the source eNodeB to determine whether to apply indirect forwarding. The source MME
indicates to the target MME whether indirect forwarding should apply. Based on this indication, the target
MME determines whether it applies indirect forwarding.
If the MME receives a rejection to an S1 interface procedure (e.g. dedicated bearer
establishment/modification/release; location reporting control; NAS message transfer; etc.) from the
eNodeB with an indication that an S1 handover is in progress (see TS 36.300 [5]), the MME shall reattempt
the same S1 interface procedure when either the handover is complete or is deemed to have failed if the
MME is still the serving MME, except in case of Serving GW relocation.
In order to minimise the number of procedures rejected by the eNodeB, the MME should pause non-
handover related S1 interface procedures (e.g. downlink NAS message transfer, E-RAB
Setup/Modify/Release, etc.) while a handover is ongoing (i.e. from the time that a Handover Required has
been received until either the Handover procedure has succeeded (Handover Notify) or failed (Handover
Failure)) and continue them once the Handover procedure has completed if the MME is still the serving
MME, except in case of Serving GW relocation.
If during the handover procedure the MME detects that the Serving GW or/and the MME needs be
relocated, the MME shall reject any PDN GW initiated EPS bearer(s) request received since handover
procedure started and shall include an indication that the request has been temporarily rejected due to
handover procedure in progress. The rejection is forwarded by the Serving GW to the PDN GW, with the
same indication.
Upon reception of a rejection for an EPS bearer(s) PDN GW initiated procedure with an indication that the
request has been temporarily rejected due to handover procedure in progress, the PDN GW start a locally
configured guard timer. The PDN GW shall re- attempt, up to a pre-configured number of times, when
either it detects that the handover is completed or has failed using message reception or at expiry of the
guard timer.
If emergency bearer services are ongoing for the UE, handover to the target eNodeB is performed
independent of the Handover Restriction List. The MME checks, as part of the Tracking Area Update in the
execution phase, if the handover is to a restricted area and if so MME releases the non- emergency bearers
as specified in clause 5.10.3.
If the MME receives a rejection to a UE Context modification Request message with a CS Fallback
indication from the eNodeB with an indication that an S1 handover is in progress, the MME shall resend a
UE Context Modification Request message with CS Fallback indicator to the target eNodeB when either
the handover is complete or to the source eNodeB when the handover is deemed to have failed if the MME
is still the serving MME.
For inter-PLMN handover to a CSG cell, based on operator's configuration the source MME may allow the
handover by validating the CSG membership of the UE in the target CSG cell using the CSG-ID list of the
registered PLMN-ID. Otherwise, the source MME shall reject the handover due to no CSG membership
information of the target PLMN-ID.
1.2.2
S1-based handover, normal
This procedure describes the S1-based handover in the normal case, clause 1.2.3 describes it when the
procedure is rejected by the target eNodeB or the target MME and clause 1.2.4 describes when the
procedure is canceled by the source eNodeB.

UE
Source
eNodeB
Source
Target
Target
MME
MME
eNodeB
Downlink User Plane data
Source
Serving GW
Target Serving
GW
PDN GW
HSS
1. Decision to trigger a
relocation via S1
2. Handover Required
3. Forward Relocation Request
4. Create Session Request
4a. Create Session Response
5. Handover Request
5a. Handover Request Acknowledge

6. Create Indirect Data Forwarding Tunnel Request
6a. Create Indirect Data Forwarding Tunnel Response
7. Forward Relocation Response
.
8. Create Indirect Data Forwarding Tunnel Request
8a. Create Indirect Data Forwarding Tunnel Response
9. Handover Command

9a. Handover Command
10. eNB Status Transfer
10a. Forward Access Context Notification
10b. Forward Access Context Acknowledge
10c. eNB Status Transfer
11a. Only for Direct forwarding of data
11b. Only for Indirect forwarding of data
Detach from old cell and
synchronize to new cell
12. Handover Confirm

Downlink data

Uplink User Plane data
13. Handover Notify
14. Forward Relocation Complete Notification
14b. Forward Relocation Complete Acknowledge

15. Modify Bearer Request
16. Modify Bearer Request
17. Modify Bearer Response

Downlink User Plane data
18. Tracking Area Update procedure
19c. Delete Session Request
(B)

19b. UE Context Release Complete
19d. Delete Session Response
20a. Delete Indirect Data Forwarding Tunnel Request
20b. Delete Indirect Data Forwarding Tunnel Response
21a. Delete Indirect Data Forwarding Tunnel Request
21b. Delete Indirect Data Forwarding Tunnel Response
19a. UE Context Release Command
(A)

16a. Modify Bearer Response

Figure 1.2.2-1: S1-based handover
NOTE 1:
For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Steps 16
and 16a concern GTP based S5/S8.
NOTE 2:
If the Serving GW is not relocated, the box
as the target Serving GW.
1.
The source eNodeB decides to initiate an S1-based handover to the target eNodeB. This can be
triggered e.g. by no X2 connectivity to the target eNodeB, or by an error indication from the target
eNodeB after an unsuccessful X2-based handover, or by dynamic information learnt by the source
eNodeB.
2.
The source eNodeB sends Handover Required (Direct Forwarding Path Availability, Source to
Target transparent container, target eNodeB Identity, CSG ID, CSG access mode, target TAI, S1AP
Cause) to the source MME. The source eNodeB indicates which bearers are subject to data
forwarding. Direct Forwarding Path Availability indicates whether direct forwarding is available
from the source eNodeB to the target eNodeB. This indication from source eNodeB can be based on
e.g. the presence of X2. The target TAI is sent to MME to facilitate the selection of a suitable target
MME. When the target cell is a CSG cell or a hybrid cell, the source eNodeB shall include the CSG
ID of the target cell. If the target cell is a hybrid cell, the CSG access mode shall be indicated.
3.
The source MME selects the target MME as described in clause 4.3.8.3 on
Function
(MME UE context, Source to Target transparent container, RAN Cause, target eNodeB Identity,
CSG ID, CSG Membership Indication, target TAI, MS Info Change Reporting Action (if available),
CSG Information Reporting Action (if available), UE Time Zone, Direct Forwarding Flag, Serving
Network) message to the target MME. The target TAI is sent to the target MME to help it to
determine whether S-GW relocation is needed (and, if needed, aid SGW selection). The old Serving
Network is sent to target MME to support the target MME to resolve if Serving Network is changed.
In network sharing scenarios Serving Network denotes the serving core network.

The source MME shall perform access control by checking the UE's CSG subscription when CSG
ID is provided by the source eNodeB. If there is no subscription data for this CSG ID or the CSG
subscription is expired, and the target cell is a CSG cell, the source MME shall reject the handover
with an appropriate cause.
The MME UE context includes IMSI, ME Identity, UE security context, UE Network Capability,
AMBR, Selected CN operator ID, APN restriction, Serving GW address and TEID for control
signalling, and EPS Bearer context(s).
An EPS Bearer context includes the PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE
keys (for PMIP-based S5/S8) at the PDN GW(s) for uplink traffic, APN, Serving GW addresses and
TEIDs for uplink traffic, and TI.
RAN Cause indicates the S1AP Cause as received from source eNodeB.
The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a
CSG or hybrid cell. When the target cell is a hybrid cell, the CSG Membership Indication indicating
whether the UE is a CSG member shall be included in the Forward Relocation Request message.
The Direct Forwarding Flag indicates if direct forwarding is applied, or if indirect forwarding is
going to be set up by the source side.






The target MME shall determine the Maximum APN restriction based on the APN Restriction of
each bearer context in the Forward Relocation Request, and shall subsequently store the new
Maximum APN restriction value.
If the UE receives only emergency services and the UE is UICCless, IMSI can not be included in the
MME UE context in Forward Relocation Request message. For emergency attached UEs, if the
IMSI cannot be authenticated, then the IMSI shall be marked as unauthenticated. Also, in this case,
security parameters are included only if available.

4.
If the MME has been relocated, the target MME verifies whether the source Serving GW can
continue to serve the UE. If not, it selects a new Serving GW as described in clause 4.3.8.2 on

this Serving GW re-selection.


If the source Serving GW continues to serve the UE, no message is sent in this step. In this case, the
target Serving GW is identical to the source Serving GW.
If a new Serving GW is selected, the target MME sends a Create Session Request (bearer context(s)
with PDN GW addresses and TEIDs (for GTP-based S5/S8) or GRE keys (for PMIP-based S5/S8)
at the PDN GW(s) for uplink traffic, Serving Network, UE Time Zone) message per PDN
connection to the target Serving GW. The target Serving GW allocates the S-GW addresses and
TEIDs for the uplink traffic on S1_U reference point (one TEID per bearer). The target Serving GW
sends a Create Session Response (Serving GW addresses and uplink TEID(s) for user plane)
message back to the target MME.
5.
The Target MME sends Handover Request (EPS Bearers to Setup, AMBR, S1AP Cause, Source to
Target transparent container, CSG ID, CSG Membership Indication, Handover Restriction List)
message to the target eNodeB. This message creates the UE context in the target eNodeB, including
information about the bearers, and the security context. For each EPS Bearer, the Bearers to Setup
includes Serving GW address and uplink TEID for user plane, and EPS Bearer QoS. If the direct
forwarding flag indicates unavailability of direct forwarding and the target MME knows that there is
no indirect data forwarding connectivity between source and target, the Bearers to Setup shall
include
sent if available in the Target MME; it is described in clause 4.3.5.7



S1AP Cause indicates the RAN Cause as received from source MME.
The Target MME shall include the CSG ID and CSG Membership Indication when provided by the
source MME in the Forward Relocation Request message.
The target eNodeB sends a Handover Request Acknowledge (EPS Bearer Setup list, EPS Bearers
failed to setup list Target to Source transparent container) message to the target MME. The EPS
Bearer Setup list includes a list of addresses and TEIDs allocated at the target eNodeB for downlink
traffic on S1-U reference point (one TEID per bearer) and addresses and TEIDs for receiving
forwarded data if necessary. If the UE-AMBR is changed, e.g. all the EPS bearers which are
associated to the same APN are rejected in the target eNodeB, the MME shall recalculate the new
UE-AMBR and signal the modified UE-AMBR value to the target eNodeB.
If none of the default EPS bearers have been accepted by the target eNodeB, the target MME shall
reject the handover as specified in clause 1.2.3.
If the target cell is a CSG cell, the target eNodeB shall verify the CSG ID provided by the target
MME, and reject the handover with an appropriate cause if it does not match the CSG ID for the
target cell. If the target eNodeB is in hybrid mode, it may use the CSG Membership Indication to
perform differentiated treatment for CSG and non-CSG members.


6.
If indirect forwarding applies and the Serving GW is relocated, the target MME sets up forwarding
parameters by sending Create Indirect Data Forwarding Tunnel Request (target eNodeB addresses
and TEIDs for forwarding) to the Serving GW. The Serving GW sends a Create Indirect Data
Forwarding Tunnel Response (target Serving GW addresses and TEIDs for forwarding) to the target
MME. If the Serving GW is not relocated, indirect forwarding may be set up in step 8 below.

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW
used as the anchor point for the UE.
7.
If the MME has been relocated, the target MME sends a Forward Relocation Response (Cause,
Target to Source transparent container, Serving GW change indication, EPS Bearer Setup List,
Addresses and TEIDs) message to the source MME. For indirect forwarding, this message includes
Serving GW Address and TEIDs for indirect forwarding (source or target). Serving GW change
indication indicates a new Serving GW has been selected.
8.
If indirect forwarding applies, the source MME sends Create Indirect Data Forwarding Tunnel
Request (addresses and TEIDs for forwarding) to the Serving GW. If the Serving GW is relocated it
includes the tunnel identifier to the target serving GW.


The Serving GW responds with a Create Indirect Data Forwarding Tunnel Response (Serving GW
addresses and TEIDs for forwarding) message to the source MME.
Indirect forwarding may be performed via a Serving GW which is different from the Serving GW
used as the anchor point for the UE.
9.
The source MME sends a Handover Command (Target to Source transparent container, Bearers
subject to forwarding, Bearers to Release) message to the source eNodeB. The Bearers subject to
forwarding includes list of addresses and TEIDs allocated for forwarding. The Bearers to Release
includes the list of bearers to be released.
9a. The Handover Command is constructed using the Target to Source transparent container and is sent
to the UE. Upon reception of this message the UE will remove any EPS bearers for which it did not
receive the corresponding EPS radio bearers in the target cell.
10. The source eNodeB sends the eNodeB Status Transfer message to the target eNodeB via the
MME(s) to convey the PDCP and HFN status of the E-RABs for which PDCP status preservation
applies, as specified in TS 36.300 [5]. The source eNodeB may omit sending this message if none of
the E-RABs of the UE shall be treated with PDCP status preservation.

If there is an MME relocation the source MME sends this information to the target MME via the
Forward Access Context Notification message which the target MME acknowledges. The source
MME or, if the MME is relocated, the target MME, sends the information to the target eNodeB via
the eNodeB Status Transfer message.
11. The source eNodeB should start forwarding of downlink data from the source eNodeB towards the
target eNodeB for bearers subject to data forwarding. This may be either direct (step 11a) or indirect
forwarding (step 11b).
12. After the UE has successfully synchronized to the target cell, it sends a Handover Confirm message
to the target eNodeB. Downlink packets forwarded from the source eNodeB can be sent to the UE.
Also, uplink packets can be sent from the UE, which are forwarded to the target Serving GW and on
to the PDN GW.
13. The target eNodeB sends a Handover Notify (TAI+ECGI) message to the target MME.
14. If the MME has been relocated, the target MME sends a Forward Relocation Complete Notification
() message to the source MME. The source MME in response sends a Forward Relocation Complete
Acknowledge () message to the target MME. Regardless if MME has been relocated or not, a timer
in source MME is started to supervise when resources in Source eNodeB and if the Serving GW is
relocated, also resources in Source Serving GW shall be released.

Upon receipt of the Forward Relocation Complete Acknowledge message the target MME starts a
timer if the target MME allocated S-GW resources for indirect forwarding.
15. The MME sends a Modify Bearer Request (eNodeB address and TEID allocated at the target
eNodeB for downlink traffic on S1-U for the accepted EPS bearers, ISR Activated) message to the
target Serving GW for each PDN connection, including the PDN connections that need to be
released. If the PDN GW requested UE's location and/or User CSG information (determined from
the UE context), the MME also includes the User Location Information IE and/or User CSG
Information IE in this message. If the UE Time Zone has changed, the MME includes the UE Time
Zone IE in this message. If Serving GW is not relocated but the Serving Network has changed or if
the MME has not received any old Serving Network information from the old MME, the MME
includes the Serving Network IE in this message. For the case that neither MME nor S-GW
changed, if ISR was activated before this procedure MME should maintain ISR. The UE is informed
about the ISR status in the Tracking Area Update procedure. If the Serving GW supports Modify
Access Bearers Request procedure and if there is no need for the SGW to send the signalling to the
PGW, the MME may send Modify Access Bearers Request (eNodeB address and TEID allocated at
the target eNodeB for downlink traffic on S1 U for the accepted EPS bearers, ISR Activated) per UE
to the Serving GW to optimize the signalling.

The MME releases the non-accepted dedicated bearers by triggering the bearer release procedure as
specified in clause 5.4.4.2. If the Serving GW receives a DL packet for a non-accepted bearer, the
Serving GW drops the DL packet and does not send a Downlink Data Notification to the MME.
If the default bearer of a PDN connection has not been accepted by the target eNodeB and there are
other PDN connections active, the MME shall handle it in the same way as if all bearers of a PDN
connection have not been accepted. The MME releases these PDN connections by triggering the
MME requested PDN disconnection procedure specified in clause 5.10.3.
When the Modify Bearer Request does not indicate ISR Activated the Serving GW deletes any ISR
resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the
Serving GW reserved.


16. If the Serving GW is relocated, the target Serving GW assigns addresses and TEIDs (one per bearer)
for downlink traffic from the PDN GW. It sends a Modify Bearer Request (Serving GW addresses
for user plane and TEID(s), Serving Network) message per PDN connection to the PDN GW(s). The
S-GW also includes User Location Information IE and/or UE Time Zone IE and/or User CSG
Information IE if they are present in step 15. The Serving GW also includes Serving Network IE if it
is present in step 4 or step 15. The Serving GW allocates DL TEIDs on S5/S8 even for non-accepted
bearers. The PDN GW updates its context field and returns a Modify Bearer Response (Charging Id,
MSISDN) message to the target Serving GW. The MSISDN is included if the PDN GW has it stored
in its UE context. The PDN GW starts sending downlink packets to the target GW using the newly
received address and TEIDs. These downlink packets will use the new downlink path via the target
Serving GW to the target eNodeB.

If the Serving GW is not relocated, but has received the User Location Information IE and/or UE
Time Zone IE and/or User CSG Information IE and/or Serving Network IE from the MME in
step 15, the Serving GW shall inform the PDN GW(s) about these information that e.g. can be used
for charging, by sending the message Modify Bearer Request (User Location Information IE, UE
Time Zone IE, User CSG Information IE, Serving Network IE) to the PDN GW(s) concerned. A
Modify Bearer Response message is sent back to the Serving GW.
If the Serving GW is not relocated and it has not received User Location Information IE nor UE
Time Zone IE nor User CSG Information IE nor Serving Network IE from the MME in step 15, no
message is sent in this step and downlink packets from the Serving-GW are immediately sent on to
the target eNodeB.

17. The Serving GW shall return a Modify Bearer Response (Serving GW address and TEID for uplink
traffic) message to the MME as a response to a Modify Bearer Request message, or a Modify
Access Bearers Response (Serving GW address and TEID for uplink traffic) as a response to a
Modify Access Bearers Request message. If the Serving GW cannot serve the MME Request in the
Modify Access Bearers Request message without S5/S8 signalling or without corresponding Gxc
signalling when PMIP is used over the S5/S8 interface, it shall respond to the MME with indicating
that the modifications are not limited to S1-U bearers, and the MME shall repeat its request using
Modify Bearer Request message per PDN connection.

If the Serving GW does not change, the Serving GW shall send one or more
on the old path immediately after switching the path in order to assist the reordering function in the
target eNodeB.
18. The UE initiates a Tracking Area Update procedure when one of the conditions listed in clause


The target MME knows that it is a Handover procedure that has been performed for this UE as it
received the bearer context(s) by handover messages and therefore the target MME performs only a
subset of the TA update procedure, specifically it excludes the context transfer procedures between
source MME and target MME.
19. When the timer started in step 14 expires the source MME sends a UE Context Release Command ()
message to the source eNodeB. The source eNodeB releases its resources related to the UE and
responds with a UE Context Release Complete () message. When the timer started in step 14 expires
and if the source MME received the Serving GW change indication in the Forward Relocation
Response message, it deletes the EPS bearer resources by sending Delete Session Request (Cause,
LBI, Operation Indication) messages to the Source Serving GW. The operation Indication flag is not
set, that indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete
procedure towards the PDN GW. The Source Serving GW acknowledges with Delete Session
Response () messages. If ISR has been activated before this procedure, the cause indicates to the
Source S-GW that the Source S-GW shall delete the bearer resources on the other old CN node by
sending Delete Bearer Request message(s) to that CN node.
20. If indirect forwarding was used then the expiry of the timer at source MME started at step 14
triggers the source MME to send a Delete Indirect Data Forwarding Tunnel Request message to the
S-GW to release the temporary resources used for indirect forwarding that were allocated at step 8.
21. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at
target MME started at step 14 triggers the target MME to send a Delete Indirect Data Forwarding
Tunnel Request message to the target S-GW to release temporary resources used for indirect
forwarding that were allocated at step 6.
1.2.3
S1-based handover, Reject
The Target eNodeB rejects the use of the Handover procedure if none of the requested bearers in the
Handover Request message could be established. In this case no UE context is established in the target
MME/eNodeB and no resources are allocated. Further, the Target MME rejects the handover request and
clears all resource in Target eNodeB and Target MME if the Target eNodeB accepts the handover request
but none of the default EPS bearers gets resources allocated. In both cases, the UE remains in the Source
eNodeB/MME.

UE
Source
eNodeB
Source
Target
MME
eNodeB
Downlink User Plane data
Target
MME
Source
Serving GW
Target Serving
GW
PDN GW
HSS
1. Decision to trigger a
relocation via S1
2. Handover Required
3. Forward Relocation Request
4. Create Session Request
4a. Create Session Response

5.
H
andover
Request
6a. Handover Failure
6b. Handover Request Acknowledge
7. Delete Session Request
.
7a. Delete Session Response
8. Forward Relocation Response (Reject)
9. Handover Preparation Failure

Figure 1.2.3-1: S1-based handover, Reject
NOTE 1:
Steps 3, 4, 7 and 8 are performed if the MME is relocated.
NOTE 2:
If the MME is not relocated Steps 5 and 6 are performed by the source MME and, in the
description below, the source MME acts as the target MME.
1-5.
Steps 1 to 5 in the flow are identical to steps 1-5 in clause 1.2.2.
6a. If the Target eNodeB fails to allocate any resources for any of the requested EPS bearers it sends a
Handover Failure (Cause) message to the Target MME. The Target MME clears any reserved
resources for this UE in the target MME.
6b. If the Target MME receives a Handover Request Acknowledge message from the Target eNodeB
but none of the default EPS bearers are in the EPS Bearer Setup list IE, the Target MME clears any
reserved resources for this UE in both the Target MME and the Target eNodeB.
7.
This step is only performed for Serving GW relocation, i.e. if steps 4/4a have been performed. The
Target MME deletes the EPS bearer resources by sending Delete Session Request (Cause) messages
to the Target Serving GW. The Target Serving GW acknowledges with Delete Session Response
(Cause) messages.
8.
The Target MME sends the Forward Relocation Response (Cause) message to the Source MME.
9.
When the Source MME receives the Forward Relocation Response message, it sends a Handover
Preparation Failure (Cause) message to the Source eNodeB.
1.2.4
S1-based handover, Cancel
Instead of completing the handover procedure, the source eNodeB may at any time during the handover
procedure, up to the time when a handover command message is sent to the UE cancel the handover.
The MME shall cancel the handover resources as defined in clause 2.5.1 for case the source RAN is
eNodeB.
2
2.0
Inter RAT handover
General
During Inter RAT handover indirect forwarding may apply for the dowlink data forwarding performed as
part of the handover. From its configuration data the MME knows whether indirect forwarding applies and
it allocates a dowlink data forwarding path on a Serving GWs for indirect forwarding. From its
configuration data the S4 SGSN knows whether indirect forwarding applies and it allocates dowlink data
forwarding paths on Serving GWs for indirect forwarding. It is configured on MME and S4 SGSN whether
indirect dowlink data forwarding does not apply, applies always or applies only for inter PLMN inter RAT
handovers.
For inter-PLMN handover to a CSG cell, based on operator's configuration the source MME/S4-SGSN
may allow the handover by validating the CSG membership of the UE in the target CSG cell using the
CSG-ID list of the registered PLMN-ID. Otherwise, the source MME/S4-SGSN shall reject the handover
due to no CSG membership information of the target PLMN- ID
2.1
2.1.1
Pre-conditions:
-
E-UTRAN to UTRAN Iu mode Inter RAT handover
General
The UE is in ECM-CONNECTED state (E-UTRAN mode).
If emergency bearer services are ongoing for an UE, handover to the target RNC is performed independent
of the Handover Restriction List. The SGSN checks, as part of the Routing Area Update in the execution
phase, if the handover is to a restricted area and if so SGSN deactivate the non-emergency PDP context as
specified in TS 23.060 [7], clause 9.2.4.2.
2.1.2


UE

Source

eNodeB

Preparation phase
Target RNC

Source MME

Source

Target

Target SGSN

Serving GW

Serving GW

PDN GW

HSS

Uplink and Downlink
User Plane PDUs




1. Handover Initiation



2.
H

andover
Required



3. Forward Relocation Request

4. Create Session Request

4a. Create Session Response

5. Relocation
Request



5a. Relocation

Request Acknowledge

6. Create Indirect Data Forwarding Tunnel Request

6a. Create Indirect Data Forwarding Tunnel Response



7. Forward Relocation Response


reate Indirect Data Forwarding Tunnel Request

8
.


C

reate Indirect Data Forwarding Tunnel Response

8
a

.
C

Figure 2.1.2-1: E-UTRAN to UTRAN Iu mode Inter RAT HO, preparation phase
1.
The source eNodeB decides to initiate an Inter-RAT handover to the target access network, UTRAN
Iu mode. At this point both uplink and downlink user data is transmitted via the following: Bearer(s)
between UE and source eNodeB, GTP tunnel(s) between source eNodeB, Serving GW and PDN
GW.

If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS
handover to a UTRAN cell that is not IMS voice capable.
NOTE 1:
The process leading to the handover decision is outside of the scope of this specification.
2.
The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, CSG ID,
CSG access mode, Source to Target Transparent Container) message to the source MME to request
the CN to establish resources in the target RNC, target SGSN and the Serving GW. The bearers that
will be subject to data forwarding (if any) are identified by the target SGSN in a later step (see
step 7 below). When the target cell is a CSG cell or a hybrid cell, the source eNodeB shall include
the CSG ID of the target cell. If the target cell is a hybrid cell, the CSG access mode shall be
indicated.
3.
The source MME determines from the 'Target RNC Identifier' IE that the type of handover is IRAT
Handover to UTRAN Iu mode. The Source MME initiates the Handover resource allocation
procedure by sending a Forward Relocation Request (IMSI, Target Identification, CSG ID, CSG
Membership Indication, MM Context, PDN Connections, MME Tunnel Endpoint Identifier for
Control Plane, MME Address for Control plane, Source to Target Transparent Container, RAN
Cause, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if
available), UE Time Zone, ISR Supported, Serving Network) message to the target SGSN. The
information ISR Supported is indicated if the source MME and associated Serving GW are capable
to activate ISR for the UE. When ISR is activated the message should be sent to the SGSN that
maintains ISR for the UE when this SGSN is serving the target identified by the Target
Identification. This message includes all PDN Connections active in the source system and for each
PDN Connection includes the associated APN, the address and the uplink Tunnel endpoint
parameters of the Serving GW for control plane, and a list of EPS Bearer Contexts. RAN Cause
indicates the S1AP Cause as received from source eNodeB. The old Serving Network is sent to
target MME to support the target MME to resolve if Serving Network is changed.

The source MME shall perform access control by checking the UE's CSG subscription when CSG
ID is provided by the source eNodeB. If there is no subscription data for this CSG ID or the CSG
subscription is expired, and the target cell is a CSG cell, the source MME shall reject the handover
with an appropriate cause.
The source MME includes the CSG ID in the Forward Relocation Request when the target cell is a
CSG cell or hybrid cell. When the target cell is a hybrid cell, the CSG Membership Indication
indicating whether the UE is a CSG member shall be included in the Forward Relocation Request
message.
The target SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS
parameter values of an EPS bearer to the Release 99 QoS parameter values of a bearer context as
defined in Annex E
Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN.
The MM context contains security related information, e.g. supported ciphering algorithms as
described in TS 29.274 [43]. Handling of security keys is described in TS 33.401 [41].
The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of
each bearer context in the Forward Relocation Request, and shall subsequently store the new
Maximum APN restriction value.





4.
The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the
Serving GW is to be relocated, the target SGSN selects the target Serving GW as described under
clause 4.3.8.2 on
(IMSI, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, PDN
GW address(es) for user plane, PDN GW UL TEID(s) for user plane, PDN GW address(es) for
control plane, and PDN GW TEID(s) for control plane, the Protocol Type over S5/S8, Serving
Network) per PDN connection to the target Serving GW. The Protocol Type over S5/S8 is provided
to Serving GW which protocol should be used over S5/S8 interface.

The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN
deactivates, as provided in step 7 of the execution phase, the EPS Bearer contexts which cannot be
established.
4a. The target Serving GW allocates its local resources and returns a Create Session Response (Serving
GW address(es) for user plane, Serving GW UL TEID(s) for user plane, Serving GW Address for
control plane, Serving GW TEID for control plane) message to the target SGSN.
5.
The target SGSN requests the target RNC to establish the radio network resources (RABs) by
sending the message Relocation Request (UE Identifier, Cause, CN Domain Indicator, Integrity
protection information (i.e. IK and allowed Integrity Protection algorithms), Encryption information
(i.e. CK and allowed Ciphering algorithms), RAB to be setup list, CSG ID, CSG Membership
Indication, Source RNC to Target RNC Transparent Container, Service Handover related
information). If the Access Restriction is present in the MM context, the Service Handover related
information shall be included by the target SGSN for the Relocation Request message in order for
RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access
Restriction.

For each RAB requested to be established, RABs To Be Setup shall contain information such as
RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The RAB ID
information element contains the NSAPI value, and the RAB parameters information element gives
the QoS profile. The Transport Layer Address is the Serving GW Address for user plane (if Direct
Tunnel is used) or the SGSN Address for user plane (if 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 transfer to continue
in the new RAT/mode target cell without requiring a new AKA (Authentication and Key
Agreement) procedure. Information that is required to be sent to the UE (either in the Relocation
Command message or after the handover completion message) from RRC in the target RNC shall be
included in the RRC message sent from the target RNC to the UE via the transparent container.
More details are described in TS 33.401 [41].
The Target SGSN shall include the CSG ID and CSG Membership Indication when provided by the
source MME in the Forward Relocation Request message.
In the target RNC radio and Iu user plane resources are reserved for the accepted RABs. Cause
indicates the RAN Cause as received from source MME. The Source RNC to Target RNC
Transparent Container includes the value from the Source to Target Transparent Container received
from the source eNodeB.
If the target cell is a CSG cell, the target RNC shall verify the CSG ID provided by the target SGSN,
and reject the handover with an appropriate cause if it does not match the CSG ID for the target cell.
If the target cell is in hybrid mode, the target RNC may use the CSG Membership Indication to
perform differentiated treatment for CSG and non-CSG members.




5a. The target RNC allocates the resources and returns the applicable parameters to the target SGSN in
the message Relocation Request Acknowledge (Target RNC to Source RNC Transparent Container,
RABs setup list, RABs failed to setup list).

Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared to
receive downlink GTP PDUs from the Serving GW, or Target SGSN if Direct Tunnel is not used,
for the accepted RABs.
Each RABs setup list is defined by a Transport Layer Address, which is the target RNC Address for
user data, and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint
Identifier for user data.
Any EPS Bearer contexts for which a RAB was not established are maintained in the target SGSN
and the UE. These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM
procedures upon the completion of the routing area update (RAU) procedure.


6.
If 'Indirect Forwarding' and relocation of Serving GW apply and Direct Tunnel is used the target
SGSN sends a Create Indirect Data Forwarding Tunnel Request message (Target RNC Address and
TEID(s) for DL data forwarding) to the Serving GW. If 'Indirect Forwarding' and relocation of
Serving GW apply and Direct Tunnel is not used, then the target SGSN sends a Create Indirect Data
Forwarding Tunnel Request message (SGSN Address and TEID(s) for DL data forwarding) to the
Serving GW.

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW
used as the anchor point for the UE.
6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW
Address(es) and Serving GW DL TEID(s) for data forwarding) message to the target SGSN.
7.
The target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint
Identifier for Control Plane, SGSN Address for Control Plane, Target to Source Transparent
Container, Cause, RAB Setup Information, Additional RAB Setup Information, Address(es) and
TEID(s) for User Traffic Data Forwarding, Serving GW change indication) to the source MME.
Serving GW change indication indicates a new Serving GW has been selected. The Target to Source
Transparent Container contains the value from the Target RNC to Source RNC Transparent
Container received from the target RNC.

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:
-
If 'Direct Forwarding' applies, or if 'Indirect Forwarding' and no relocation of Serving GW apply
and Direct Tunnel is used, then the IE 'Address(es) and TEID(s) for User Traffic Data
Forwarding' contains the addresses and GTP-U tunnel endpoint parameters to the Target RNC
received in step 5a.
-
If 'Indirect Forwarding' and relocation of Serving GW apply, then the IE 'Address(es) and
TEID(s) for User Traffic Data Forwarding' contains the addresses and DL GTP-U tunnel
endpoint parameters to the Serving GW received in step 6. This is independent from using Direct
Tunnel or not.
-
If 'Indirect Forwarding' applies and Direct Tunnel is not used and relocation of Serving GW does
not apply, then the IE 'Address(es) and TEID(s) for User Traffic Data Forwarding' contains the
DL GTP-U tunnel endpoint parameters to the Target SGSN.
8.
If
Forwarding Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)),
EPS Bearer ID(s)) to the Serving GW used for indirect 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.
8a. The Serving GW returns the forwarding parameters by sending the message Create Indirect Data
Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding).
If the Serving GW doesn't support data forwarding, an appropriate cause value shall be returned and
the Serving GW Address(es) and TEID(s) will not be included in the message.
2.1.3

UE

Source

eNodeB

Execution phase
Target RNC

Source MME

Target

Source

Target SGSN

Serving GW

Serving GW

PDN GW

HSS

Uplink and Downlink User Plane PDUs

1. Handover Command

2. HO from E-UTRAN Command

-




4. UTRAN Iu Access Procedures
4a. Handover to UTRAN Complete

Sending of
uplink data
possible

Downlink User Plane PDUs

If Direct Forwarding applies

Via Target SGSN in case Direct Tunnel is not used

5. Relocation Complete

6. Forward Relocation Complete Notification

6a. Forward Relocation Complete Acknowledge

7. Modify Bearer Request

If Indirect Forwarding applies.

For Serving GW relocation Steps 7, 8 and 9,
and the following User Plane path, will be
handled by Target Serving GW
(A)

8. Modify Bearer Request

8a. Modify Bearer Response

9. Modify Bearer Response

Uplink and Downlink User Plane PDUs (Via Target SGSN if Direct Tunnel is not used)

10. Routeing Area Update procedure
11. Delete Session Request

11b. Release Resources

11a. Delete Session Response

(B)

12. Delete Indirect Data Forwarding Tunnel Request

12a. Delete Indirect Data Forwarding Tunnel Response

13. Delete Indirect Data Forwarding Tunnel Request

13a. Delete Indirect Data Forwarding Tunnel Response


Figure 2.1.3-1: E-UTRAN to UTRAN Iu mode Inter RAT HO, execution phase
NOTE:
For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B)
shows PCRF interaction in the case of PMIP-based S5/S8. Steps 8 and 8a concern GTP based
S5/S8

The source eNodeB continues to receive downlink and uplink user plane PDUs.
1.
The source MME completes the preparation phase towards source eNodeB by sending the message
Handover Command (Target to Source Transparent Container, E-RABs to Release List, Bearers
Subject to Data Forwarding List). The
in the message and it shall be a list of 'Address(es) and TEID(s) for user traffic data forwarding'
received from target side in the preparation phase (Step 7 of the preparation phase) when 'Direct
Forwarding' applies, or the parameters received in Step 8a of the preparation phase when 'Indirect
Forwarding' applies.

The source eNodeB initiates data forwarding for bearers specified in the
Forwarding List
Serving GW if so decided by source MME and or/ target SGSN in the preparation phase.
2.
The source eNodeB will give a command to the UE to handover to the target access network via the
message HO from E-UTRAN Command. This message includes a transparent container including
radio aspect parameters that the target RNC has set-up in the preparation phase. The details of this
E-UTRAN specific signalling are described in TS 36.300 [5].

Upon the reception of the HO from E-UTRAN Command message containing the Handover
Command message, the UE shall associate its bearer IDs to the respective RABs based on the
relation with the NSAPI and shall suspend the uplink transmission of the user plane data.
3.
Void.
4.
The UE moves to the target UTRAN Iu (3G) system and executes the handover according to the
parameters provided in the message delivered in step 2. The procedure is the same as in step 6 and 8
in clause 5.2.2.2 in TS 43.129 [8] with the additional function of association of the received RABs
and existing Bearer Id related to the particular NSAPI.

The UE may resume the user data transfer only for those NSAPIs for which there are radio resources
allocated in the target RNC.
5.
When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target RNC
shall send the Relocation Complete message to the target SGSN. The purpose of the Relocation
Complete procedure is to indicate by the target RNC the completion of the relocation from the
source E-UTRAN to the RNC. After the reception of the Relocation Complete message the target
SGSN shall be prepared to receive data from the target RNC. Each uplink N-PDU received by the
target SGSN is forwarded directly to the Serving GW.
6.
Then the target SGSN knows that the UE has arrived to the target side and target SGSN informs the
source MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving
GW change) message. If indicated, ISR Activated indicates to the source MME that it shall maintain
the UE's context and that it shall activate ISR, which is only possible when the S-GW is not
changed. The source MME will also acknowledge that information. A timer in source MME is
started to supervise when resources in Source eNodeB and Source Serving GW (for Serving GW
relocation) shall be released.

When the timer expires and ISR Activated is not indicated by the target SGSN the source MME
releases all bearer resources of the UE. If Serving GW change is indicated and this timer expires the
source MME deletes the EPS bearer resources by sending Delete Session Request (Cause, Operation
Indication) messages to the Source Serving GW. The operation Indication flag is not set, that
indicates to the Source Serving GW that the Source Serving GW shall not initiate a delete procedure
towards the PDN GW. If ISR has been activated before this procedure, the cause indicates to the
Source S-GW that the Source S-GW shall delete the bearer resources on the other old CN node by
sending Delete Bearer Request message(s) to that CN node.

Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a
timer if the target SGSN allocated S-GW resources for indirect forwarding.
7.
The target SGSN will now complete the Handover procedure by informing the Serving GW (for
Serving GW relocation this will be the Target Serving GW) that the target SGSN is now responsible
for all the EPS Bearer Contexts the UE has established. This is performed in the message Modify
Bearer Request (SGSN Tunnel Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for
Control Plane, SGSN Address(es) and TEID(s) for User Traffic for the accepted EPS bearers (if
Direct Tunnel is not used) or RNC Address(es) and TEID(s) for User Traffic for the accepted EPS
bearers (if Direct Tunnel is used) and RAT type, ISR Activated) per PDN connection. If the PDN
GW requested UE's location and/or User CSG information (determined from the UE context), the
SGSN also includes the User Location Information IE and/or User CSG Information IE in this
message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this
message. If Serving GW is not relocated but the Serving Network has changed or if the SGSN has
not received any old Serving Network information from the old MME, the SGSN includes the new
Serving Network IE in this message. In network sharing scenarios Serving Network denotes the
serving core network. If indicated, the information ISR Activated indicates that ISR is activated,
which is only possible when the S-GW is not changed. When the Modify Bearer Request does not
indicate ISR Activated and S-GW is not changed,, the S-GW deletes any ISR resources by sending a
Delete Bearer Request to the other CN node that has bearer resources on the S-GW reserved.

The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context
deactivation procedure. If the Serving GW receives a DL packet for a non-accepted bearer, the
Serving GW drops the DL packet and does not send a Downlink Data Notification to the SGSN.
8.
The Serving 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 message Modify Bearer Request per PDN connection. The S-GW
also includes User Location Information IE and/or UE Time Zone IE and/or User CSG Information
IE if they are present in step 7. Serving Network should be included if it is received in step 7 or in
step 4 in clause 2.1.2. For Serving GW relocation, the Serving GW allocates DL TEIDs on S5/S8
even for non- accepted bearers. The PDN GW must acknowledge the request with the message
Modify Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context
field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.) message to the Serving
GW. The MSISDN is included if the PDN GW has it stored in its UE context.

If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the
RAT type.
9.
The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the
user plane switch to the target SGSN via the message Modify Bearer Response (Cause, Serving GW
Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, Protocol
Configuration Options). At this stage the user plane path is established for all EPS Bearer contexts
between the UE, target RNC, target SGSN if Direct Tunnel is not used, Serving GW (for Serving
GW relocation this will be the Target Serving GW) and PDN GW.

If the Serving GW does not change, the Serving GW shall send one or more
on the old path immediately after switching the path.
10. When the UE recognises that its current Routing Area is not registered with the network, or when
the UE's TIN indicates
SGSN informing it that the UE is located in a new routing area. It is RAN functionality to provide
the PMM-CONNECTED UE with Routing Area information.

The target SGSN knows that an IRAT Handover has been performed for this UE as it received the
bearer context(s) by handover messages and therefore the target SGSN performs only a subset of the
RAU procedure, specifically it excludes the context transfer procedures between source MME and
target SGSN.
11. When the timer started at step 6 expires, the source MME sends a Release Resources message to the
Source eNodeB. The Source eNodeB releases its resources related to the UE.

When the timer started in step 6 expires and if the source MME received the Serving GW change
indication in the Forward Relocation Response message, it deletes the EPS bearer resources by
sending Delete Session Request (Cause, Operation Indication) messages to the Source Serving GW.
The operation indication flag is not set, that indicates to the Source Serving GW that the Source
Serving GW shall not initiate a delete procedure towards the PDN GW. The Source Serving GW
acknowledges with Delete Session Response (Cause) messages. If ISR has been activated before
this procedure, the cause indicates to the Source S-GW that the Source S-GW shall delete the bearer
resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node.
12. If indirect forwarding was used then the expiry of the timer at source MME started at step 6 triggers
the source MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S-GW to
release the temporary resources used for indirect forwarding.
13. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at
target SGSN started at step 6 triggers the target SGSN to send a Delete Indirect Data Forwarding
Tunnel Request message to the target S-GW to release temporary resources used for indirect
forwarding.
2.1.4
E-UTRAN to UTRAN Iu mode Inter RAT handover Reject
The Target RNC may reject the use of the Handover procedure if none of the requested RABs in the
Relocation Request message could be established. In this case no UE context is established in the target
SGSN/RNC and no resources are allocated. The UE remains in the Source eNodeB/MME.


UE

Source

eNodeB

Target RNC

Source MME

Source

Target

Target SGSN

Serving GW

Serving GW

PDN GW

HSS

Uplink and Downlink
User Plane PDUs


1. Handover Initiation

2. Handover Required

3. Forward Relocation Request

4. Create Session Request

4a. Create Session Response

5. Relocation Request

6. Relocation Failure

7. Delete Session Request

7a. Delete Session Response

.8. Forward Relocation Response (Reject)

9. Handover Preparation Failure


Figure 2.1.4-1: E-UTRAN to UTRAN Iu mode Inter RAT HO reject
1.
The Step 1 to 5 in the flow are identical to the ones in clause 2.1.2.
6.
If the Target RNC fails to allocate any resources for any of the requested RABs it sends a
Relocation Failure (Cause) message to the Target SGSN. When the Target SGSN receives the
Relocation Failure message from Target RNC the Target SGSN clears any reserved resources for
this UE.
7.
This step is only performed for Serving GW relocation, i.e. if Steps 4/4a have been performed. The
Target SGSN deletes the EPS bearer resources by sending Delete Session Request (Cause) messages
to the Target Serving GW. The Target Serving GW acknowledges with Delete Session Response
(Cause) messages.
8.
The Target SGSN sends the Forward Relocation Response (Cause) message to the Source MME.
9.
When the Source MME receives the Forward Relocation Response message it send a Handover
Preparation Failure (Cause) message to the Source eNodeB.
2.2
2.2.1
UTRAN Iu mode to E-UTRAN Inter RAT handover
General
The UTRAN Iu mode to E-UTRAN Inter RAT handover procedure takes place when the network decides
to perform a handover. The decision to perform PS handover from UTRAN Iu mode to E-UTRAN is taken
by the network based on radio condition measurements reported by the UE to the UTRAN RNC.
If emergency bearer services are ongoing for the UE, the MME checks as part of the Tracking Area Update
in the execution phase, if the handover is to a restricted area and if so MME releases the non-emergency
bearers as specified in clause 5.10.3.
2.2.2


UE

Source

RNC

Preparation phase
Target

eNodeB

Source SGSN

Target MME

Serving GW

Target

Serving GW

PDN

GW

HSS

Uplink and Downlink

User Plane PDUs (via Source SGSN

in case Direct Tunnel

is

n
ot used)



1. Handover Initiation

2. Relocation Required

3. Forward Relocation Request

4. Create Session Request

4a. Create Session Response

5. Handover

Request



5a. Handover Request Acknowledge

6

.


C
reate

Indirect Data Forwarding Tunnel Request



6

a

.


C
reate

Indirect Data Forwarding Tunnel Response



7

.
Forward Relocation Response

.


C
reate

Indirect Data Forwarding Tunnel Request
8




8a.

Create

Indirect Data Forwarding Tunnel Response




Figure 2.2.2-1: UTRAN Iu mode to E-UTRAN Inter RAT HO, preparation phase