07_RA41237EN06GLA1_InterRAT Technology and Mobility

RA41237EN06GLA1

Inter-RAT/Technology Mobility

1

RA41237EN06GLA1


2

RA41237EN06GLA1


4

RA41237EN06GLA1


5

3GPP TS 36.304 — UE procedures in idle mode

3GPP TS 23.216 — Single Radio Voice Call Continuity (SRVCC)

3GPP TS 23.272 — Switched Fallback in EPS

3GPP TS 23.401 — GPRS enhancements for E-UTRAN access

3GPP TS 23.402 — Architecture enhancements for non-3GPP accesses

3GPP TS 36.214 — Physical layer – Measurements

3GPP TS 36.331 — Radio Resource Control

RA41237EN06GLA1


6

Simply put, inter-technology mobility is the ability to support movement of a device between differing radio access network types. There are many variations of this definition. In particular, the LTE standards body, 3GPP, defines two:

• Inter-RAT (Radio Access Technology) mobility, which refers to mobility between LTE and earlier 3GPP technologies

• Inter-Technology mobility which refers to mobility between LTE and non-3GPP technologies

Inter-technology mobility can be supported in a variety of ways. The most basic form of inter-technology mobility can be provided by a multi-technology device without any inter-technology support from the operator’s network(s). In this case, the user or the device selects which technology to use and initiates access to that technology. For many applications this is unacceptable as the user would have to re establish the data session from the original RAT to the new one. Therefore procedures have been defined for 3GPP and non-3GPP mobility to provide a seamless transfer of a data session. A fundamental user requirement for LTE deployments is that users expect the new network to provide not only exciting new services but also to support all the services from the legacy network. Also, operators want to leverage their existing coverage and existing investments in applications and services to support their broadband subscribers. Inter-technology mobility is an important tool for meeting these needs.

RA41237EN06GLA1


7

RA41237EN06GLA1


8








RA41237EN06GLA1


9

E-UTRA states and inter RAT mobility procedures, 3GPP

The following figure not only provides an overview of the RRC states in E-UTRA, but also illustrates the mobility support between E-UTRAN, UTRAN and GERAN.

UTRA States

In the UTRA_Idle state the UE has no uplink connection with the NodeB and can only decode system information and respond to paging messages. If data needs to be transmitted in both directions, the state will either change to CELL_DCH or CELL_FACH. CELL_DCH means the resources allocated are dedicated to one UE. However another state exists if the UE is utilizing HSPA. Namely CELL_DCH with HS. In this state the UE is using a HSPA channel and is sharing a code with other UEs. If the UE is in CELL_FACH state it means the UE is using common channels to transfer data. This state is used when only small amounts of data need to be transferred. If no data is transferred for a period of time then the UE will transition into CELL_PCH state. In this state the UE maintains a logical connection with the NodeB i.e. a C-RNTI for the UE is stored. If data needs to be transferred a relatively short connection setup time is needed. However if the UE reselects to another cell a Cell Update procedure is required to update the C-RNTI for the new cell. To do this the UE must transition to CELL_FACH or CELL_DCH to pass the necessary signaling. If a high number of reselections takes place within a defined time period the UE will transition to URA_PCH. A URA is a group of cells that are configured in the RNC database to reduce the amount of signaling needed due to a high number of cell reselections triggering Cell Update procedures.

RA41237EN06GLA1


10








RA41237EN06GLA1


11

Bearer(s) have been established between the UE and source eNodeB and GTP tunnel(s) between the source eNodeB, S-GW and P-GW. The stages of the preparation phase are listed below:

1. The source eNodeB has initiated a handover based on, for example the delivery of an event and/or measurement report(s) from the UE and has targeted an Inter-RAT 3G neighbor cell within the same PLMN.

2. The source eNodeB sends a Handover Required message to the source MME to request the CN to establish resources in the target RNC, target SGSN and the S-GW.

3. The source MME determines that the handover is Inter-RAT to 3G and initiates a handover resource allocation procedure by sending a Forward Relocation Request.

4. The target SGSN determines whether the S-GW needs to be relocated (PLMN change is an example for this). In this example S-GW change is not needed. The target SGSN requests the target RNC to establish radio network resources (RABs) by sending the Relocation Request.

5. The target RNC allocates the resources and returns the applicable parameters to the target SGSN in the message Relocation Request Acknowledge. The target RNC shall be prepared to receive downlink GTP PDUs from the S-GW, or target SGSN in case direct tunnel is not used, for the accepted RABs.

6. The target SGSN sends the message Forward Relocation Response to the source MME.

RA41237EN06GLA1


12

The source eNodeB continues to receive downlink and uplink user plane PDUs. The stages of the execution phase are listed below:

1. The source MME completes the preparation phase towards the source eNodeB by sending the message Handover Command.

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 setup in the preparation phase. The UE will associates the bearer IDs to the respective RABs based on the relation with the Network Service Access Point Identifier (NSAPI) and will suspend uplink transmission of user plane data.

3. The UE moves to the target UTRAN Iu (3G) system and executes the handover according to the parameters provided in the message in step 2. The procedure is the same as for intra-system 3G

4. When the new source RNC-ID + S-RNTI are successfully exchanged with the UE, the target RNC will 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, if direct forwarding isn't used.

RA41237EN06GLA1


13

5. The target SGSN knows that the UE has arrived at the target side and the target SGSN informs the source MME by sending the Forward Relocation Complete Notification (ISR Activated, S-GW change) message. A timer in source MME is started to supervise when resources in Source eNodeB and Source S-GW (for S-GW relocation) shall be released.

6. The target SGSN will now complete the handover procedure by informing the S-GW (for S-GW relocation this will be the Target S-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. The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context deactivation procedure. If the S-GW receives a DL packet for a non-accepted bearer, the S-GW drops the DL packet and does not send a Downlink Data Notification to the SGSN.

7. The S-GW (for S-GW relocation this will be the Target S-GW) may inform the P-GW(s) the change of for example for S-GW relocation or the RAT type that e.g. can be used for charging, by sending the message Modify Bearer Request. The P-GW must acknowledge the request with the message Modify Bearer Response. In the case of S-GW relocation, the P-GW updates its context field and returns a Modify Bearer Response message to the S-GW. The MSISDN is included if the P-GW has it stored in its UE context. If PCC infrastructure is used, the P-GW informs the PCRF about the change of, for example, the RAT type.

RA41237EN06GLA1


14

8. The S-GW (for S-GW relocation this will be the Target S-GW) acknowledges the user plane switch to the target SGSN via the message Modify Bearer Response. At this stage the user plane path is established for all EPS Bearer contexts between the UE, target RNC or target SGSN in case Direct Tunnel is not used, S-GW (for S-GW relocation this will be the Target S-GW) and P-GW. If the S-GW does not change, the S-GW shall send one or more "end marker" packets on the old path immediately after switching the path.

9. When the UE recognizes that its current Routing Area is not registered with the network, or when the UE's TIN indicates "GUTI", the UE initiates a Routing Area Update procedure with the target 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.

10. When the timer started at step 5 expires, the source MME sends a Release Resources message to the Source eNodeB. The Source eNodeB releases its resources related to the UE.

RA41237EN06GLA1


15








RA41237EN06GLA1


16

Bearer(s) have been established between the UE and source eNodeB and GTP tunnel(s) between the source eNodeB, S-GW and P-GW. The stages of the preparation phase are listed:

1. The source eNodeB has initiated a handover based on, for example the delivery of an event and/or measurement report(s) from the UE and has targeted an Inter-RAT 2G neighbor cell within the same PLMN.

2. The source eNodeB sends a Handover Required message to the source MME to request the CN to establish resources in the target BSS, target SGSN and the S-GW.

3. The source MME determines that the handover is Inter-RAT to 3G and initiates a handover resource allocation procedure by sending a Forward Relocation Request.

4. The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates the EPS Bearer contexts which cannot be established. The Target SGSN requests the Target BSS to establish the necessary resources (PFCs) by sending the message PS Handover Request.

5. The Target BSS allocates the requested resources and returns the applicable parameters to the Target SGSN in the message PS Handover Request Acknowledge. Upon sending the PS Handover Request Acknowledge message the target BSS is prepared to receive downlink Logical Link Control (LLC) PDUs from the target SGSN for the accepted Packet Flow Contexts (PFCs).

6. The target SGSN sends the message Forward Relocation Response to the source MME.

RA41237EN06GLA1


17

The source eNodeB continues to receive downlink and uplink user plane PDUs. The stages of the execution phase are listed in numbered order and relate to the figure:

1. The source MME completes the preparation phase towards the source eNodeB by sending the message Handover Command.

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 setup in the preparation phase. The UE will associates the bearer IDs to the respective RABs based on the relation with the Network Service Access Point Identifier (NSAPI) and will suspend uplink transmission of user plane data.

3. The UE moves to the target GERAN A/Gb (2G) system and executes the handover according to the parameters provided in the message in step 2. The procedure is the same as for intra-system 2G PS handover with the additional function of association of the received PFI and existing bearer id related to the particular NSAPI.

4. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 3, the UE processes the NAS container and then sends one XID response message to the target SGSN via target BSS. The UE sends this message immediately after receiving the Packet Physical Information message containing the timing advance or, in the synchronized network case, immediately if the PS Handover Access message is not required to be sent. The UE may resume the user data transfer only for those NSAPIs for which there are radio resources allocated in the target BSS.

RA41237EN06GLA1


18

5. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the UE to the Target BSS, the Target BSS informs the Target SGSN by sending the message PS Handover Complete.

6. The Target BSS also relays the message XID Response to the Target SGSN. Note, the message in step 5 and 6 may arrive in any order in the Target SGSN.

7. The target SGSN knows that the UE has arrived at the target side and the target SGSN informs the source MME by sending the Forward Relocation Complete Notification message. A timer in source MME is started to supervise when resources in Source eNodeB and Source S-GW (for S-GW relocation) shall be released.

8. The target SGSN will now complete the Handover procedure by informing the S-GW (for S-GW relocation this will be the Target S-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. The SGSN releases the non-accepted EPS Bearer contexts by triggering the Bearer Context deactivation procedure. If the S-GW receives a DL packet for a non-accepted bearer, the S-GW drops the DL packet and does not send a Downlink Data Notification to the SGSN.

RA41237EN06GLA1


19

9. The S-GW (for S-GW relocation this will be the Target S-GW) may inform the P-GW(s) of the change: for example S-GW relocation or the RAT type that can be used for charging, by sending the message Modify Bearer Request. The P-GW must acknowledge the request with the message Modify Bearer Response. In the case of S-GW relocation, the P-GW updates its context field and returns a Modify Bearer Response message to the S-GW. The MSISDN is included if the P-GW has it stored in its UE context. If PCC infrastructure is used, the P-GW informs the PCRF about the change of, for example, the RAT type.

10. The S-GW (for S-GW relocation this will be the Target S-GW) acknowledges the user plane switch to the target SGSN via the message Modify Bearer Response. At this stage the user plane path is established for all EPS Bearer contexts between the UE, target RNC or target SGSN in case Direct Tunnel is not used, S-GW (for S-GW relocation this will be the Target S-GW) and P-GW. If the S-GW does not change, the S-GW shall send one or more "end marker" packets on the old path immediately after switching the path.

11. If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in the HO from E-UTRAN Command message, then on receipt of the PS Handover Complete the Target SGSN initiates an LLC/SNDCP XID negotiation for each LLC Service Access Point Identifier (SAPI) used in LLC Asynchronous Disconnect Mode (ADM). In this case if the Target SGSN wants to use the default XID parameters, it shall send an empty XID Command. If the Target SGSN indicated 'Reset to the old XID parameters' in the NAS container, no further XID negotiation is required for LLC SAPIs used in LLC ADM only.

RA41237EN06GLA1


20

12. The Target SGSN (re-)establishes LLC Asynchronous Balanced Mode (ABM) for the EPS Bearer contexts which use acknowledged information transfer. During the exchange of Set Asynchronous Balanced Mode (SABM) and Unnumbered Acknowledgement (UA) the SGSN will perform LLC/Sub-Network Dependant Convergence Protocol SNDCP XID negotiation.

13. After the UE has finished the reconfiguration procedure the UE shall initiate the Routing Area Update procedure.

14. When the timer started at step 7 expires, the source MME sends a Release Resources message to the source eNodeB. The Source eNodeB releases its resources related to the UE.

RA41237EN06GLA1


21








RA41237EN06GLA1


22

The operator configurable measurements events A2 and A1 are used to start and stop

IRAT measurements.

The UE capabilities are considered for the IRAT measurements, e.g. support measurement

gap and support of frequency of target cells.

The target cells for the IRAT measurements are operator configurable. Blacklisting of

target cells is supported as well. An ANR functionality might be applied optionally.

The event B2 is used for the IRAT measurements.

The measurement configuration as source cell thresholds (RSRP), target cell thresholds

(RSCP, EcN0), hysteresis, time to trigger and speed dependent scaling are operator

configurable.

Handover preparation

The eNB initiates a handover after receiving a measurement report form the UE by

sending a S1AP:HANDOVER REQUIRED message to the MME.

The eNB takes the first target cell indicated by the UE measurements for the handover.

The MME responds to this with a S1AP:HANDOVER COMMAND message indicating

that the resources at the target have been reserved.

Handover execution

The Flexi Multiradio BTS sends after this a RRC:MobilityfromEUTRAcommand

message to the UE, which forces to the to a TD-SCDMA cell.

The eNB performs handover retries to other targets

RA41237EN06GLA1


23

1. The handover performance for the inter-RAT case should be no worse than that for the intra-RAT case.

2. Inter RAT HO is controlled by the source access system. Hence the source system need to prepare the target system accordingly.

3. Inter RAT HO is a backwards HO procedure; this means that the resources at the target system are prepared before the actual handover takes place.

4. Forwarding of user data can be performed to avoid data loss (not currently required for inter RAT handover). PDCP is reset on handover from LTE to TD-SCDMA.

5. The source eNB is responsible for deciding which bearers require data forwarding and informing the MME. (not currently required for inter RAT handover)

6. The eNB transfers the UE Radio Capability context to the target UTRAN in a transparent container via the EPC.

7. Data forwarding may be direct from eNB to RNC or indirect via the EPC. The eNB will indicate to the MME whether direct forwarding is possible; the MME will take this into account when deciding which form is used; the MME manages the creation of the forwarding tunnels and provides the addresses to the source eNB. (not currently required for inter RAT handover)

8. The MME is responsible for specifying the bearers to be setup in the target UTRAN; it does this using its own context and must perform the mapping from E-RAB to PDP contexts and any mapping between E-RAB QoS parameters and Pre-Release 8 PDP QoS parameters.

9. The MME is responsible for transferring the security context to the target access UTRAN. The Radio Aspects that the RNC has setup in the preparation phase are transferred to the source eNB in a transparent container which is delivered to the UE in the MOBILITY FROM 22 EUTRA COMMAND.

10. The handover procedure does not require any UE to CN signaling in order for data to start to flow in the target system.

RA41237EN06GLA1


24








RA41237EN06GLA1


25

The entities shown in the figure must be enabled to support CS Fallback. The additional functionality needed is described in the following sections.

UE

The CS fallback capable UE supports access to E-UTRAN/EPC as well as access to the CS-domain over GERAN and/or UTRAN. It supports the following additional functions:

• Combined procedures for EPS/IMSI attach, update and detach.

• CS fallback and SMS procedures for using CS domain services.

MME

The CS fallback enabled MME supports the following additional functions:

• Deriving a VLR number and LAI from the GUTI received from the UE or from a default LAI.

• Maintaining of SGs association towards MSC/VLR for EPS/IMSI attached UE.

• Initiating IMSI detach at EPS detach.

• Initiating paging procedure towards the eNodeB when the MSC pages the UE for CS services.

• Supporting SMS procedures.

• Rejecting CS Fallback call request.

RA41237EN06GLA1


26

MSC

The CS fallback enabled MSC supports the following additional functions:

• Maintaining SGs association towards MME for EPS/IMSI attached UE.

• Supporting SMS procedures.

E-UTRAN

The CS fallback enabled E-UTRAN supports the following additional functions:

• Forwarding paging request and SMS to the UE.

• Directing the UE to the target CS capable cell

Mobility Management

The CS fallback in EPS is realized by using the SGs interface mechanism between the MSC Server and the MME. Mobility management includes:

• Attach procedure

• Detach procedures:

– UE Initiated

– MME Initiated

– HSS Initiated

• TA/LA Update procedures

– Combined TA/LA Update procedure

– Periodic TA and LA Update procedure.

RA41237EN06GLA1


27

The attach procedure for the CS fallback in EPS is realized based on the combined GPRS/IMSI Attach procedure utilizing the Gs interface. This is specified in TS 23.060.

1. The UE initiates the attach procedure by the transmission of an Attach Request message to the MME. The Attach Type indicates that the UE requests a combined EPS/IMSI attach and informs the network that the UE is capable and configured to use CS fallback.

2. The EPS Attach start procedure is performed as specified in a previous module.

3. The VLR shall be updated according to the combined GPRS/IMSI Attach procedure if the Attach Request message includes an Attach Type indicating that the UE requests a combined EPS/IMSI attach. The MME allocates a default LAI, which is configured on the MME and may take into account the current TAI and/or E-CGI. The MME derives a VLR number based on the allocated LAI and IMSI hash function. The MME starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data message from the HSS in step 2. This operation marks the MS as EPS-attached in the VLR.

4. The MME sends a Location Update Request (new LAI, IMSI, MME address, Location Update Type) message to the VLR. MME address is an IP address.

5. The VLR creates an association with the MME by storing MME address.

6. The VLR performs Location Updating procedure in CS domain.

7. The VLR responds with Location Update Accept (VLR TMSI) to the MME.

8. The EPS Attach end procedure is performed as specified in a previously

RA41237EN06GLA1


28

This flow may be executed when the eNodeB knows that both the UE and the network support PS HO, in the normal case.

1a. The UE sends an Extended Service Request for mobile originating CS fallback to MME. Extended Service Request message is encapsulated in RRC and S1-AP messages.

1b. The MME sends an S1-AP UE Context Modification Request (CS Fallback Indicator, LAI) message to eNodeB.

1c. The eNodeB shall reply with S1-AP UE Context Modification Response message.

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN cell to which PS handover will be performed.

3a. The eNodeB triggers PS handover to a GERAN/UTRAN neighbor cell by sending a Handover Required message to the MME

3b. If the target RAT is GERAN and the UE has entered Dedicated Mode, the UE starts the Suspend procedure unless both the UE and the Target cell support DTM in which case TBF re-establishment may be performed.

3c. A Gn/Gp-SGSN that receives the Suspend message from the UE follows the Suspend procedure

RA41237EN06GLA1


29

4a. If the LA of the new cell is different from the one stored in the UE, the UE shall initiate a Location Area Update or a Combined RA/LA Update procedure as follows:

- if the network is operating in NMO-I (Network Modes of Operation), the UE may initiate a separate Location Area Update before initiating the RAU procedure instead of a Combined RA/LA Update procedure (to speed up the CSFB procedure); or

if the network is operating in NMO-II or NMO-III, the UE shall initiate a Location Area Update before initiating the RAU procedure required for PS handover.

4b. The UE sends a CM Service Request to the MSC. The UE shall indicate to the MSC that this is an originating call establishment as a result of CSFB by including the "CSMO" flag.

5. The UE initiates the CS call establishment procedure and the UE shall include the CSMO flag in the CM Service Request to the MSC.

6. The UE performs any remaining steps of the inter-RAT handover from E-UTRAN to UTRAN or GERAN.

RA41237EN06GLA1


30

1a. The UE sends an Extended Service Request for mobile originating CS fallback to the MME. Extended Service Request message is encapsulated in RRC and S1-AP messages. The UE only transmits this request if it is attached to CS domain (with a combined EPS/IMSI Attach)

1b. The MME sends an S1-AP UE Context Modification Request (CS Fallback Indicator, LAI) message to eNodeB.

1c. The eNodeB shall reply with S1-AP UE Context Modification Response message.

2. The eNodeB may optionally solicit a measurement report from the UE to determine the target GERAN/UTRAN cell to which the redirection procedure will be performed.

The network performs one of steps 3a or 3b or 3c.

3a. If the UE and network support inter-RAT cell change order to GERAN and the target cell is GERAN 3b. If the UE or the network does not support inter-RAT PS handover from E-UTRAN to GERAN/UTRAN nor inter-RAT cell change order to GERAN or the network does not wish to use these procedures 3c. If the UE and network support "RRC connection release with redirection and Multi Cell System Information to GERAN/UTRAN“: requests and is assigned a dedicated channel where it sends a SABM

4. The eNodeB sends an S1-AP UE Context Release Request message to the MME. If the target cell is GERAN and either the target cell or the UE does not support DTM the message includes an indication that the UE is not available for the PS service.

RA41237EN06GLA1


31

5. The MME releases the UE Context in the eNodeB as well as all eNodeB related information in the S-GW

The UE performs one of steps 6a or 6b or 6c and THEN performs step 6d.

6a. (Step 6a is performed if step 3a, Cell Change Order to GERAN, was performed)

6b. (Step 6b is performed if step 3b, RRC release with redirection, was performed).

6c. (Step 6c is performed if step 3c, RRC connection release with redirection and Multi Cell System Information, was performed).

6d. When the UE arrives at the target cell, if target RAT is UTRAN: The UE establishes the radio signaling connection by sending an RRC Initial Direct Transfer message

7. If the target RAT is GERAN and DTM is not supported, the UE starts the Suspend.

8. If the S1-AP UE Context Release Request message, received from the eNodeB in step 4, indicates that the UE is not available for the PS service in the target cell, the MME deactivates GBR bearers towards S-GW and PGW(s) by initiating MME-initiated Dedicated Bearer Deactivation procedure and RAI included in the Suspend Request message.

9. The UE continues with the MO call setup procedure with sending CM Service Request. The UE shall indicate to the MSC that this is an originating call establishment as a result of CSFB by including the "CSMO" flag.

RA41237EN06GLA1


32

10. The UE initiates the CS call establishment procedure and the UE shall include the CSMO flag in the CM Service Request to the MSC.

11. After the CS voice call is terminated and if the UE is in GERAN and PS services are suspended, then the UE shall resume PS services.

RA41237EN06GLA1


33

Once CS service ends in CS domain, existing mechanisms can be used to move the UE to E-UTRAN, no specific CS Fallback mechanisms are needed.

When the UE moves to E-UTRAN, if the EPS service was suspended during the CS service, it is resumed according to the procedure shown.

1. The UE sends a TAU Request message, to the MME.

2. If the UE context in the MME indicates that UE is in suspended status, the MME informs the S-GW and PGW(s) to re-activate the EPS bearers for the UE.

If the procedure triggered by the NAS message in step 1 activates Modify Bearer Request message to the S-GW, this message should be used as an implicit resume. The S-GW is aware of the suspend state of the bearers and shall forward the Modify Bearer request to the P-GW. The P-GW and S-GW shall clear the suspend state and confirm with Modify Bearer response to the MME.

3. The NAS message is processed accordingly

RA41237EN06GLA1


34








RA41237EN06GLA1


35

After handover completion, UE performs RAU to established the PS bearers (which could not be established together with the CS-handover) via the Iu-PS

RA41237EN06GLA1


36

After HO data on going from SGSN to PGW and vice versa

VoIP connection is handed over to UTRAN CS while other PS bearers are simultaneously handed over to UTRAN PS

RA41237EN06GLA1


37

UE runs out of LTE coverage, GSM measurements are activated and SRVCC to GSM is triggered (in the same way as for eNACC to GSM).

eNodeB initiates S1-HO towards GSM indicating SRVCC for CS only and sets indication “ PS Service Not Available“

CS-Handover (incl. SRVCC) towards GSM is executed. MME suspends PS services

UE is served in GERAN connected via CS domain only

VoIP connection is handed over to GSM CS but other PS bearers are suspended and they could be resumed only after performing Routing Area Update – after the CS call end!

RA41237EN06GLA1


38

UE is served in GERAN connected via CS domain only (no suspension of PS by MME)

PS bearers are established again after performing Routing Area Update – during the CS call (with the help of DTM mode)

RA41237EN06GLA1


39

07_RA41237EN06GLA1_InterRAT Technology and Mobility

Documents

Transcript of 07_RA41237EN06GLA1_InterRAT Technology and Mobility