SGSN Serving Radio Network Subsystem Relocation

This chapter describes the SGSN Serving Radio Network Subsystem Relocation (SRNS) feature.

Feature Description

The SRNS relocation feature facilitates connected mode inter-RAT handovers between UTRAN (3G) networks or between UTRAN and EUTRAN (LTE) networks. The advantage of this feature is that the radio bearer establishment occurs before the actual handover at the target.

The Gn/Gp SGSN and S4-SGSN support inter- and intra-SGSN SRNS relocation to enable:

  • Handovers of an MS from one RNC to another RNC
  • Handovers of an MS from one RNC to an eNodeb

The S4-SGSN supports the optional setup of indirect data forwarding tunnels (IDFT) between the eNodeB and the RNC via the SGW during connected mode handovers. This allows the S4-SGSN to support connected mode handovers between the UTRAN and E-UTRAN networks across the S3 interface. IDFT is not supported on the SGSN across the Gn interface.

The SRNS Relocation feature is included with the base SGSN license. It does not require an additional feature license.

Relationships to Other Features

This section describes how the SRNS Relocation feature relates to other SGSN features.

  • For an SGSN operating via the Gn/Gp interfaces, a 3G service (sgsn-service) must be configured and enabled before SRNS Relocation can be configured.
  • For an S4-SGSN, both a 3G service (sgsn-service) and S4-SGSN support (egtp-service) must be configured before SRNS Relocation can be configured.
  • If operators are using non-standard LAC ranges, then a network-global-mme-id-mgmt-db must be configured and associated with the sgsn-service.

For detailed instructions on configuring the above, refer to the appropriate chapters in this guide.

How it Works

SRNS Relocation on the SGSN (Gn/Gp)

On the Gn/Gp SGSN, the SRNS relocation feature is triggered by subscribers (MS/UE) moving from one RNS to another. If the originating RNS and destination RNS are connected to the same SGSN but are in different routing areas, the behavior triggers an intra-SGSN Routing Area Update (RAU). If the RNSs are connected to different SGSNs, the relocation is followed by an inter-SGSN RAU.

The following table describes the interface selection logic for the various types of SRNS relocation that can occur when the interface used for a subscriber is Gn for PDP contexts. Note that the Gn/Gp SGSN SRNS relocation selection logic is applicable in the following instances:

  • An S4-SGSN is configured (both the S4 license and EGTP service are available), but a given subscriber uses the Gn interface for PDP contexts.
  • Only the Gn/Gp interfaces are utilized on the SGSN. S4 support is not configured.
Table 1. Interface Selection Logic for SRNS Relocation on the SGSN Gn/Gp

SI.No

RNC Release Compliance

Target Type Sent in Rel. Req.

LAC Configured as MME Group ID

LAC MSB Set

Peer Type

DNS Query Type

Interface IP Provided by DNS

Interface Chosen

1

R8+

eNodeB

Not Applicable

Irrelevant

MME

When the Gn interface is used, the system maps the eNB ID to the RNC ID as follows: The MSB 12 bits of the 20 bit eNB ID is mapped to RNC ID. DSN A query with RNC ID FQDN is sent and Gn address is selected.

Gn

Gn

2

R8+

RNC

Not Applicable

Irrelevant

SGSN

DNS A Query with RNC ID FQDN

Gn

Gn

3

Pre R8

RNC

Irrelevant

Irrelevant

It is not important to a Gn SGSN if the peer is an MME or an SGSN. For a Gn SGSN, a peer MME is treated just like an SGSN

DNS A Query with RNC ID FQDN

Gn

Gn

SGSN (Gn/Gp) SRNS Relocation Call Flow Diagrams

This section provides call flow diagrams and process descriptions for the following SGSN Gn/Gp SRNS Relocation scenarios:

  • Inter-SGSN (Gn/Gp) SRNS Relocation Call Flow
  • Intra-SGSN (Gn/Gp) SRNS Relocation Call Flow

The Inter-SGSN (Gn/Gp) SRNS Relocation procedure is illustrated in the following diagram.

Figure 1. Inter-SGSN Gn/Gp SRNS Relocation Call Flow
Table 2. Inter-SGSN (Gn/Gp) SRNS Relocation Process Description
Step Description

1

The source SRNC decides to perform/initiate SRNS relocation.

2

The source SRNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to target RNC transparent container) to the old SGSN.

3

The old SGSN determines from the Target ID that an inter-SGSN SRNS relocation is required. A DNS A query is performed for the target RNC ID FQDN to obtain the target SGSN IP address. The old SGSN then sends a Forward Relocation Request to the new SGSN.

4

The new SGSN sends a Relocation Request message to the new RNC. At this point, radio access bearers have been established.

5

The new RNC sends a Relocation Request Response message to the new SGSN.

6

When resources for the transmission of user data between the new RNC and the new SGSN have been allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message (Cause, RANAP Cause, and RAB Setup Information) is sent from the new SGSN to the old SGSN.

7

The old SGSN continues the relocation of SRNS by sending a Relocation Command message to the old RNC. The old SGSN sends the RAB setup information received in the Forward Relocation Response in a Relocation Command to the old RNC. This enables the old RNC to establish a data path with new RNC so that it can forward the data packets.

8

The old SRNC may, according to the QoS profile, begin the forwarding of data for the RABs to be subject for data forwarding.

9

Before sending the Relocation Commit the uplink and downlink data transfer in the source, the SRNC shall be suspended for RABs, which require a delivery order. The source RNC starts the data-forwarding timer. When the old SRNC is ready, the old SRNC triggers the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to the new RNC over the Iur interface.

10

The target RNC sends a Relocation Detect message to the new SGSN when the relocation execution trigger is received.

11

The new RNC sends a RAN Mobility Information message. This message contains UE information elements and CN information elements.

12

When the new SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNCID + S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC initiates the Relocation Complete procedure by sending the Relocation Complete message to the new SGSN.

13

The old SGSN sends a Forward Relocation Complete message.

14

The old SGSN sends a Forward Relocation Acknowledgement to the new SGSN. to signal to the new SGSN the completion of the SRNS relocation procedure.

15

Upon receipt of the Relocation Complete message, the CN switches the user plane from the old RNC to the new SRNC. The new SGSN sends Update PDP Context Request messages to the GGSN.

16

The GGSN sends Update PDP Context Response messages to the new SGSN.

17

The old SGSN sends an Iu Release Command message to the old RNC.

18

The old RNC sends an Iu Release Complete message to the old SGSN.

19

After the MS has finished the RNTI reallocation procedure, and if the new Routing Area Identification is different from the old one, the MS initiates the Routing Area Update procedure.

The intra-SGSN Gn/Gp SRNS Relocation procedure is illustrated in the following figure.

Figure 2. Intra-SGSN Gn/Gp SRNS Relocation Call Flow
Table 3. Intra-SGSN (Gn/Gp) SRNS Relocation Process Description
Step Description

1

The source SRNC decides to perform/initiate SRNS relocation.

2

The old RNC sends a Relocation Required message to the SGSN.

3

The SGSN sends a Relocation Request message to the new RNC. At this point, radio access bearers have been established.

4

The new RNC sends a Relocation Request Acknowledgement message to the SGSN.

5

The SGSN sends a Relocation Command to the old RNC and the UE is detached from the old RNC and attached to the new RNC.

6

The old SRNC may, according to the QoS profile, begin the forwarding of data for the RABs to be subject for data forwarding.

7

Before sending the Relocation Commit the uplink and downlink data transfer in the source, the SRNC shall be suspended for RABs, which require a delivery order. The source RNC starts the data-forwarding timer. When the old SRNC is ready, the old SRNC triggers the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to the new RNC over the Iur interface.

8

The new RNC sends a RAN Mobility Information message. This message contains UE information elements and CN information elements.

9

When the new SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNCID + S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC initiates the Relocation Complete procedure by sending the Relocation Commit message to the new SGSN.

10

The new RNC sends a Relocation Detect message to the SGSN.

11

The SGSN sends a Relocation Complete message to the new RNC.

12

If Direct Tunnel was established during intra-SGSN SRNS relocation, the SGSN sends Update PDP Context Request messages to the GGSN.

13

If Direct Tunnel was established during intra-SGSN SRNS relocation, the SGSN sends Update PDP Context Response messages to the GGSN.

14

The SGSN sends an Iu Release Command to the old RNC.

15

The old RNC releases the Iu connection and sends a Release Complete message to the SGSN.

16

After the MS has finished the RNTI reallocation procedure, and if the new Routing Area Identification is different from the old one, the MS initiates the Routing Area Update procedure.

SRNS Relocation on the S4-SGSN

On the S4-SGSN, the SRNS relocation feature is triggered by subscribers (MS/UE) moving between an eNodeB and an RNC or between two RNCs.

If the originating and destination nodes are connected to the same S4-SGSN but are in different routing areas, the behavior triggers an intra-SGSN Routing Area Update (RAU).

If the nodes are connected to different S4-SGSNs, the relocation is followed by an inter-SGSN RAU. This RAU occurs over a RANAP direct transfer. As a result, it does not trigger Context Request/Context Response/Context Ack procedures with the old SGSN/MME. These procedures are otherwise performed during a normal SGSN RAU.

The GTPv2 protocol is used for SRNS relocation between two RNCs and between an eNodeB and an RNC.

In addition to supporting Inter-SGSN SRNS relocation across the Gn interface, the S4-SGSN supports SRNS relocation for the following scenarios across the S3 (S4-SGSN to MME) and S16 (S4-SGSN to S4-SGSN) interfaces:

  • Inter-SGSN SRNS relocation over the S16 interface
  • UTRAN-to-E-UTRAN connected mode Inter-RAT handover over the S3 interface
  • E-UTRAN-to-UTRAN connected mode Inter-RAT handover over the S3 interface

As part of the SRNS relocation feature implementation on the S4-SGSN, the SGSN application also supports the gtpv2 (egtp) protocol for:

  • Inter-SGSN SRNS relocations over the S16 interface
  • MME - SGSN SRNS relocations over the S3 interface

S4-SGSN SRNS relocation interface selection logic is based on the following assumptions:

  • If the egtp-service is configured, it is assumed the network is EPC capable and therefore must require a DNS SNAPTR.
  • If the egtp-service is configured on the S4-SGSN, then for outbound SRNS relocation, the system always performs a DNS SNAPTR as follows:
    • x-S16 if the peer detected is another S4-GSN, or x-S3 if the peer detected is an MME (based on whether the target is an eNodeB/the MSB of the target LAC being 1, or, if a local MME group ID is configured).
    • x-gn if a local configuration for a peer SGSN or MME exists with a Gn address, or, if DNS SNAPTR returned a GN address.

If both DNS queries fail, the system rejects the SRNS relocation.

The following table describes the interface selection logic for the various types of SRNS relocation that can occur when the interface used for a subscriber is S4 for PDP contexts.
Table 4. Interface Selection Logic for S4-SGSN SRNS Relocation

SI.No

RNC Release Compliance

Target Type Sent in Relocation Request

LAC Configured as MME Group ID

LAC MSB Set

Peer Type

Type of DNS Query

Interface IP Provided by DNS

Interface Chosen

1

R8+

eNodeB

n/a

n/a

MME

DNS SNAPTR w/ service type x-3gpp-mme:x-s3 and TAC FQDN

S3

S3

2

R8+

eNodeB

n/a

n/a

MME

DNS SNAPTR w/ service type x-3gpp-mme:x-s3 and TAC FQDN

Gn

When a TAC FQDN is used to query the MME address the system expects that the MME supports S3 interface. If this is the case, the S3 interface is chosen. If DNS returns a Gn address, then the system rejects the Relocation, and sends a Relocation Preparation Failure to the source RNC.

3

R8+

RNC

n/a

n/a

SGSN

DNS SNAPTR w/ service type x-3gpp-sgsn:x-s16 and RNC ID FQDN

S16

S16

4

R8+

RNC

n/a

n/a

SGSN

DNS SNAPTR w/ service type x-3gpp-sgsn:x-s16 and RNC ID FQDN

Gn

Gn

5

Pre R8

RNC (A pre R8 RNC cannot send eNB as the target type. Currently, operators configure eNB ID to RNC ID mapping in such these pre R8 RNCs so that the SGSN receives an RNC ID that is actually mapped from the eNB ID)

Yes

Irrelevant

MME

DNS SNAPTR w/ service type x-3gpp-mme:x-s3 and MME GI + MME Code FQDN

S3

S3

6

Pre R8

RNC

Yes

Irrelevant

MME

DNS SNAPTR w/ service type x-3gpp-mme:x-s3 and MME GI + MME Code FQDN

Gn

Gn

7

Pre R8

RNC

No

Yes

MME

DNS SNAPTR w/ service type x-3gpp-mme:x-s3 and MME GI + MME Code FQDN

S3

S3

8

Pre R8

RNC

No

Yes

MME

DNS SNAPTR w/ service type x-3gpp-mme:x-s3 and MME GI + MME Code FQDN

Gn

Gn

9

Pre R8

RNC

No

No

SGSN

DNS SNAPTR w/ service type x-3gpp-sgsn:x-s16 and RNC ID FQDN

S16

S16

10

Pre R8

RNC

No

No

SGSN

DNS SNAPTR w/ service type x-3gpp-sgsn:x-s16 and RNC ID FQDN

Gn

Gn

IDFT Support During Connected Mode Handovers

The S4-SGSN supports the setup of indirect data forwarding tunnels (IDFT) between the eNodeB and the RNC via the SGW during connected mode handovers.

Once enabled, IDFT is employed under the following conditions:

  • If the SGSN is the old node:
    • The target node to which the connected mode handover is initiated should be an eNodeB (i.e., the SGSN performs the handover to the MME).
    • The enb-direct-data-forward CLI setting is not configured as the source RNC configuration (in RNC Configuration Mode).
  • If the SGSN is the new node:
    • The source node from which connected mode handover is initiated is an eNodeB (i.e., the MME is performing a handover to the SGSN).
    • The enb-direct-data-forward setting is not configured in the source RNC configuration (in RNC Configuration Mode).
    • The source MME indicated that it does not support direct forwarding via a Forward Relocation Request.

Important

If the target SGSN did not relocate to a new SGW, IDFT setup does not apply at the SGSN. The target SGSN sets up an indirect data forwarding tunnel with the SGW only if the SGW is relocated. If the SGW is not relocated, then it is the source MME that sets up the indirect data forwarding tunnel between source the eNodeB and target RNC through the SGW.

The following diagram illustrates the interface selection logic for S4-SGSN connected mode handovers.

Figure 3. Interface Selection Logic for S4-SGSN SRNS Connected Mode Handovers


S4-SGSN SRNS Relocation Call Flow Diagrams

This section provides call flow diagrams for the following S4-SGSN SRNS relocation scenarios:

  • Inter-S4-SGSN SRNS Relocation without SGW Relocation
  • Inter-S4-SGSN Relocation with SGW Relocation
  • Intra-S4-SGSN SRNS Relocation without SGW Relocation
  • Inter-S4-SGSN Relocation with SGW Relocation
  • S4-SGSN E-UTRAN to UTRAN Connected Mode Handover without SGW Relocation
  • S4-SGSN UTRAN to E-UTRAN Connected Mode Handover with SGW Relocation Call Flow
  • S4-SGSN Inter-SGSN SRNS Relocation with Hard Handover and SGW Relocation
Figure 4. S4 Inter-SGSN SRNS Relocation without SGW Relocation Call Flow


Table 5. Inter-S4-SGSN SRNS Relocation without SGW Relocation Process Description
Step Description

1

The decision is made to perform SRNS relocation.

2

The old RNC sends a Relocation Required message to the old SGSN.

3

The old SGSN sends a Forward Relocation Request to the new SGSN.

4

The new SGSN performs SGW selection, but does not select a new SGW, as the subscriber is anchored at the same SGW as it was previously.

5

The new SGSN sends a Relocation Request message to the new RNC. At this point, Radio Access Bearers are established.

6

The new RNC sends a Relocation Request Acknowledgment to the new SGSN.

7

The new SGSN sends a Forward Relocation Response to the old SGSN. In this message, the old SGSN sends the RAB context information of the new RNC, which was obtained from the Relocation Request Ack message.

8

The old SGSN sends a Relocation Command to the old RNC. The old SGSN sends the new RNC RAB context information to the old RNC in the Relocation Command message so that old RNC can forward packets to the new RNC.

9

The old SRNC may, according to the QoS profile, begin the forwarding of data for the RABs to be subject for data forwarding.

10

Before sending the Relocation Commit the uplink and downlink data transfer in the source, the SRNC shall be suspended for RABs, which require a delivery order. The source RNC starts the data-forwarding timer. When the old SRNC is ready, the old SRNC triggers the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to the new RNC over the Iur interface.

11

The new RNC sends a Relocation Detect message to the new SGSN.

12

The new RNC sends a RAN Mobility Information message. This message contains UE information elements and CN information elements.

13

When the new SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNCID + S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC initiates the Relocation Complete procedure by sending the Relocation Commit message to the new SGSN.

14

The new RNC sends a Relocation Complete message to the new SGSN.

15

The new SGSN sends a Forward Relocation Notification Complete message to the old SGSN.

16

The new SGSN sends a Forward Relocation Complete Ack message to the old SGSN.

17

The new SGSN sends a Modify Bearer Request to the SGW.

18

The SGW sends a Modify Bearer Response to the new SGSN.

19

The old SGSN sends an Iu Release Command message to the old RNC.

20

The old RNC sends an Iu Release Complete message to the old SGSN.

21

After the MS has finished the RNTI reallocation procedure, and if the new Routing Area Identification is different from the old one, the MS initiates the Routing Area Update procedure.

Figure 5. Inter-S4-SGSN Relocation with SGW Relocation
Table 6. Inter-S4-SGSN Relocation with SGW Relocation Process Description
Step Description

1

The decision is made to perform SRNS relocation.

2

The old RNC informs the old SGSN that relocation is required by sending a Relocation Required message.

3

The old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request message to the new SGSN.

4

The new SGSN performs SGW selection.

5

The new SGSN sends a Create Session Request to the new SGW with Indication Flags - Operations Indication bit = 0. The new SGW will not send a Modify Bearer Request to the PGW at this time.

6

The new SGW sends a Create Session Response to the new SGSN.

7

The new SGSN sends a Relocation Request to the new RNC. At this point radio access bearers are set up between the new RNC and the new SGSN.

8

The new RNC sends a Relocation Request Acknowledge message to the new SGSN.

9

The new SGSN sends a Forward Relocation Response message to the old SGSN. In this message, the old SGSN sends the RAB context information of the new RNC, which was obtained from Relocation Request Acknowledge message.

10

The old SGSN sends a Relocation Command to the old RNC. The old SGSN sends the new RNC RAB context information to the old RNC in the Relocation Command so that the old RNC can forward packets to the new RNC.

11

The old SRNC may, according to the QoS profile, begin the forwarding of data for the RABs to be subject for data forwarding.

12

Before sending the Relocation Commit the uplink and downlink data transfer in the source, the SRNC shall be suspended for RABs, which require a delivery order. The source RNC starts the data-forwarding timer. When the old SRNC is ready, the old SRNC triggers the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to the new RNC over the Iur interface.

13

The new RNC sends a Relocation Detect message to the new SGSN.

14

The new RNC sends a RAN Mobility Information message. This message contains UE information elements and CN information elements.

15

When the new SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNCID + S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC initiates the Relocation Complete procedure by sending the Relocation Commit message to the new SGSN.

16

The new RNC sends a Relocation Complete message to the new SGSN.

17

The new SGSN sends a Forward Relocation Complete Notification message to the old SGSN.

18

The old SGSN sends a Forward Relocation Complete Ack message to the new SGSN.

19

The new SGSN sends a Modify Bearer Request message to the new SGW.

20

The SGW sends a Modify Bearer Request message to the PGW.

21

The PGW sends a Modify Bearer Response to the new SGW.

22

The SGW sends a Modify Bearer Response to the new SGSN.

23

The old SGSN sends a Delete Session Request to the old SGW.

24

The old SGW sends a Delete Session Response to the old SGSN.

25

The old SGSN sends an Iu Release Command message to the old RNC.

26

The old RNC sends an Iu Release Complete message to the old SGSN.

27

After the MS has finished the RNTI reallocation procedure, and if the new Routing Area Identification is different from the old one, the MS initiates the Routing Area Update procedure.

Figure 6. Intra-S4-SGSN SRNS Relocation without SGW Relocation
Table 7. Intra-S4-SGSN SRNS Relocation without SGW Relocation Process Description
Step Description

1

The decision is made to perform SRNS relocation.

2

The old RNC sends a Relocation Required message to the SGSN.

3

The SGSN performs SGW selection, but does not select a new SGW, as the subscriber is anchored at the same SGW as it was previously.

4

The SGSN sends a Relocation Request message to the new RNC. At this point, radio access bearers have been established.

5

The new RNC sends a Relocation Request Acknowledgment message to the SGSN.

6

The SGSN sends a Relocation Command to the old RNC and the UE is detached from the old RNC and attached to the new RNC.

7

The old SRNC may, according to the QoS profile, begin the forwarding of data for the RABs to be subject for data forwarding.

8

Before sending the Relocation Commit the uplink and downlink data transfer in the source, the SRNC shall be suspended for RABs, which require a delivery order. The source RNC starts the data-forwarding timer. When the old SRNC is ready, the old SRNC triggers the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to the new RNC over the Iur interface.

9

The new RNC sends a RAN Mobility Information message. This message contains UE information elements and CN information elements.

10

When the new SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNCID + S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC initiates the Relocation Complete procedure by sending the Relocation Commit message to the new SGSN.

11

The new RNC sends a Relocation Detect message to the SGSN.

12

The SGSN sends a Relocation Complete message to the new RNC.

13

The SGSN sends an Iu Release Command to the old RNC.

14

The old RNC releases the Iu connection and sends a Release Complete message to the SGSN.

15

After the MS has finished the RNTI reallocation procedure, and if the new Routing Area Identification is different from the old one, the MS initiates the Routing Area Update procedure.

Figure 7. Intra-S4-SGSN Relocation with SGW Relocation


Table 8. Intra-S4-SGSN Relocation with SGW Relocation Process Description
Step Description

1

The decision is made to perform SRNS relocation.

2

The old RNC sends a Relocation Required message to the SGSN.

3

The SGSN selects a new SGW for the UE.

4

The SGSN sends a Create Session Request to the new SGW with Indication Flags - Operations Indication bit=0. The new SGW does not send a Modify Beater Request to the PGW at this time.

5

The new SGW sends a Create Session Response to the SGSN.

6

The SGSN sends a Relocation Request to the new RNC. At this point, radio access bearers have been established.

7

The new RNC sends a Relocation Request Acknowledge message to the SGSN.

8

The SGSN sends a Relocation Command to the old RNC.

9

The new RNC sends a RAN Mobility Information message. This message contains UE information elements and CN information elements.

10

When the new SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNCID + S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC initiates the Relocation Complete procedure by sending the Relocation Commit message to the new SGSN.

11

The new RNC sends a RAN Mobility Information message. This message contains UE information elements and CN information elements.

12

When the new SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNCID + S-RNTI are successfully exchanged with the MS by the radio protocols, the target SRNC initiates the Relocation Complete procedure by sending the Relocation Commit message to the new SGSN.

13

The new RNC sends a Relocation Detect message to the SGSN.

14

The new RNC sends a Relocation Complete message to the SGSN.

15

The SGSN sends a Modify Bearer Request message to the new SGW.

16

The new SGW sends a Modify Bearer Request to the PGW.

17

The PGW sends a Modify Bearer Response to the new SGW.

18

The new SGW sends a Modify Bearer Response to the SGSN.

19

The SGSN sends a Delete Session Request to the old SGW.

20

The old SGW sends a Delete Session Response to the SGSN.

21

The SGSN sends an Iu Release Command to the old RNC.

22

The old RNC sends an Iu Release Complete message to the SGSN.

23

After the MS has finished the RNTI reallocation procedure, and if the new Routing Area Identification is different from the old one, the MS initiates the Routing Area Update procedure.

Figure 8. S4-SGSN E-UTRAN to UTRAN Connected Mode Handover without SGW Relocation Call Flow


Table 9. S4-SGSN E-UTRAN to UTRAN Connected Mode Handover without SGW Relocation Process Description
Step Description

1

The eNodeB determines that relocation is required and sends a Relocation Required message to the old MME.

2

The old MME sends a Forward Relocation Request message to the new SGSN.

3

The new SGSN performs SGW selection for the UE.

4

The new SGSN sends a Relocation Request message to the new RNC. At this time, radio access bearers are established.

5

The new RNC sends a Relocation Request Ack message to the new SGSN.

6

The new SGSN sends a Forward Relocation Response to the old MME.

7

The old MME sends a Create Indirect Data Forwarding Tunnel Request message to the SGW (if IDFT is configured on the SGSN and MME).

8

The SGW sends a Create Indirect Data Forwarding Tunnel Response message to the old MME (if IDFT is configured on the SGSN and MME).

9

The old MME sends a Handover Command message to the eNodeB.

10

Downlink packets are sent from the SGW to the eNodeB.

11

Downlink packets are sent from the eNodeB to the SGW via Indirect Data Forwarding Tunnel (if IDFT is configured on the new SGSN and the old MME). Downlink packets then are sent from the SGW to the new SGSN, and finally, from the new SGSN to the new RNC.

12

The new RNC sends a Relocation Detect message to the new SGSN.

13

The new RNC sends a Relocation Complete message to the new SGSN.

14

The new SGSN sends a Forward Relocation Complete Notification message to the old MME.

15

The old MME sends a Forward Relocation Complete Ack message to the new SGSN.

16

The new SGSN sends a Modify Bearer Request message to the SGW.

17

The new SGW sends a Modify Bearer Request message to the PGW.

18

The PGW sends a Modify Bearer Response message to the SGW.

19

The new SGW sends a Modify Bearer Response message to the new SGSN.

20

After timer expiry, the old MME sends a Delete IDFT Tunnel Request to the SGW and deletes the IDFT tunnel.

Figure 9. S4-SGSN UTRAN to E-UTRAN Connected Mode Handover with SGW Relocation Call Flow


Table 10. S4-SGSN UTRAN to E-UTRAN Connected Mode Handover with SGW Relocation Process Description
Step Description

1

The old RNC determines that relocation is required for a UE and sends a Relocation Required message to the old SGSN.

2

The old SGSN sends a Forward Relocation Request message to the new MME.

3

The new MME performs the selection of a new SGW.

4

The new MME sends a Create Session Request message to the new SGW.

5

The new SGW sends a Create Session Response to the new MME.

6

The new MME sends a Handover Request message to the eNobeB. At this point radio access bearers are established.

7

The eNodeB sends a Handover Request Ack message to the new MME.

8

The MME sends an Indirect Data Forwarding Tunnel Request to the new SGW.

9

The new SGW sends an Indirect Data Forwarding Tunnel Response to the new MME. The new SGW sends the SGW DL data forwarding TEID to the MME in this message.

10

The new MME sends a Forward Relocation Response message to the old SGSN. The new MME forwards the SGW DL data forwarding TEID received in step 9 to the old SGSN in this message.

11

The old SGSN sends a Create IDFT Request to the old SGW. The old SGSN sends the SGW DL data forwarding TEID received in step 10 to the old SGW in this request. This enables the old SGW to setup an indirect forwarding path towards the new SGW.

12

The old SGW sends a Create IDFT Response to the old SGSN. The old SGW sends the SGW DL data forwarding TEID to the SGSN in this message. The SGSN will forward the re-forwarded downlink packets back to the old SGW to this TEID.

13

The old SGSN sends a Relocation Command to the old RNC. Downlink packets are then routed through the architecture in the following manner:
  • PGW to old SGW
  • Old SGW to old SGSN
  • Old SGSN to old RNC
  • Old RNC to old SGSN
  • Old SGSN to old SGW
  • Old SGW to new SGW
  • New SGW to eNodeB

14

The eNodeB sends a Handover Complete message to the new MME.

15

The new MME sends a Forward Relocation Complete message to the old SGSN.

16

The old SGSN sends a Forward Relocation Complete Notification message to the new MME.

17

The new MME sends a Modify Bearer Request to the new SGW.

18

The new SGW sends a Modify Bearer Request to the PGW.

19

The PGW sends a Modify Bearer Response to the new SGW.

20

The new SGW sends a Modify Bearer Response to the new MME.

21

After timer expiry, the old SGSN sends a Delete Session Request to the old SGW.

22

The old SGW sends a Delete Session Response to the old SGSN.

23

The old SGSN also sends a Delete IDFT Request to the old SGW.

24

Similar to the timer started at the old SGSN, the new MME also would have started a timer to guard the holding of the IDFT tunnel created there. Upon expiry of this timer, the new MME sends a Delete IDFT Request to the new SGW.

Figure 10. S4-SGSN Inter-SGSN Hard Handover and SGW Relocation (Part 1)


Figure 11. S4-SGSN Inter-SGSN Relocation with Hard Handover and SGW Relocation (Part 2)


Table 11. S4-SGSN Inter-SGSN Hard Handover with SGW Relocation Process Description
Step Description

1

The decision is made to initiate relocation.

2

The source RNC sends a Relocation Required message to the target RNC.

3

The old SGSN selects the new SGSN and sends a Forward Relocation Request message to the new SGSN.

4

The new SGSN sends a Create Session Request message to the new SGW.

5

The new SGW sends a Create Session Response back to the new SGSN.

6

The new SGSN sends a Relocation Request message to the new RNC.

7

The new RNC sends a Relocation Request Acknowledgment back to the new SGSN.

8

The new SGSN sends a Forward Relocation Response message to the old SGSN.

9

The old SGSN sends a Relocation Command to the old RNC.

10

The old RNC sends the RRC message 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.

11

The old RNC sends a Forward SRNS Context message to the old SGSN.

12

The old SGSN sends a Forward Access Context Notification message to the new SGSN.

13

The new SGSN sends a Forward Access Context Acknowledge message to the old SGSN

14

The new SGSN sends a Forward SRNS Context message to the new RNC. At this point, the UE detaches from the old RNC and attaches to the new RNC.

15

The source RNC should start direct forwarding of downlink data from the source RNC towards the target RNC for bearers subject to data forwarding.

16

The UE sends an RRC message to the new RNC. Downlink packets forwarded from the old RNC can be sent to the UE. In addition, uplink packets can be sent from the UE, which are forwarded to the new SGW and then on to the PGW.

17

The new RNC sends a Relocation Complete message to the new SGSN.

18

The new SGSN then ends a Forward Relocation Complete Notification message to the old SGSN.

19

The old SGSN sends a Forward Relocation Complete Acknowledgement message to the new SGSN.

20

The new SGSN sends a Modify Bearer Request message to the new SGW for each PDN connection.

21

The new SGW sends a Modify Bearer Request message to the PGW.

22

The PGW sends a Modify Bearer Response message to the new SGW.

23

The new SGW sends a Modify Bearer Response message to the new SGSN. The PGW begins sending downlink packets to the new SGW, which in turn sends them to the new RNC, and then to the UE.

24

The UE initiates a Routing Area Update procedure. This RAU occurs on a RANAP Direct Transfer and therefore does not involve a Context transfer with the peer SGSN.

25

The old SGSN sends a Delete Session Request to the old SGW.

26

The old SGSN sends an Iu Release Command to the old RNC.

27

The old RNC then sends a Iu Release Complete message to the old SGSN.

28

The old SGW sends a Delete Session Response message to the old SGSN.

Standards Compliance

The SGSN SRNS Relocation feature complies with the following standards:

  • SGSN Gn/Gp SRNS Relocation: 3GPP TS 23.060 V8.10.0 (2010-09): 3rd Generation Partnership Project Technical Specification Group Services and System Aspects General Packet Radio Service (GPRS) Service description Stage 2 (Release 8)
  • S4-SGSN (S3/S16) SRNS Relocation: 3GPP TS 23.060 V9.8.0 (2011-03): 3rd Generation Partnership Project Technical Specification Group Services and System Aspects General Packet Radio Service (GPRS) Service description Stage 2 (Release 9)
  • MME to 3G SGSN Hard Handover and Relocation: LTE General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (3GPP TS 23.401 version 9.8.0 Release 9)

Configuring SRNS Relocation on the SGSN

This section provides examples of how to configure the SRNS relocation feature on the SGSN. An optional configuration example is also provided for enabling IDFT.

Configuring the SRNS Relocation Feature

Configuring the SRNS Relocation feature includes creating a call-control-profile and then enabling intra- and/or inter-SGSN SRNS relocation via the Command Line Interface (CLI). 

config 
 call-control-profile cc-profile name 
 srns-intra all failure-code integer 
 srns-inter all failure-code integer 
 end 
config 
      context context_name 
            iups-service iups_service_name 
                  inter-rnc-procedures source-rnc-as-target

Notes:

  • cc-profile-name is the name assigned to this call-control-profile
  • srns-intra all enables intra-SGSN SRNS relocations for all location areas.
  • srns-inter all enables inter-SGSN SRNS relocations for all location areas.
  • failure-code integer specifies the failure code that applies to SRNS relocations.
  • Optionally, operators can use the restrict and allow keywords to identify specific location areas where SRNS relocation will, or will not, occur. For detailed information on these optional keywords, refer to the Command Line Reference.
  • inter-rnc-procedures source-rnc-as-target : Optional. Configures the SGSN to support SRNS relocation for those scenarios where the source RNC is behaving as the target RNC. The default is not to allow SRNS relocation in those scenarios.

Enabling IDFT (Optional, S4-SGSN Only)

To enable support of IDFT between the eNodeB and a specified RNC via the SGW during connected mode handovers on the S4-SGSN: 

config 
 context context_name 
 iups-service iups_service_name 
 rnc id rnc_id 
 no enb-direct-data-forward 
 end

Where:

  • no enb-direct-data-forward enables the setup of IDFT between the eNodeB and the RNC via the SGW for connected mode inter RAT handovers. If IDFT is enabled, the SGSN/MME will send the IDFT request towards the SGW.
  • To disable IDFT, enter the enb-direct-data-forward command.

Verifying the SRNS Feature Configuration

This section describes how to verify that SRNS feature configuration.

The following commands provide information on how the SRNS relocation feature is configured: 

show call-control-profile full all 
show call-control-profile full name cc-profile-name

The output of these commands includes the complete SRNS configuration for the specified Call Control Profile. For example: 

show call-control-profile name cc-profile-name 
...      ...      ... 
SRNS Intra All                                              :  Allow 
SRNS Intra All Failure Code                    : 10 
SRNS Inter All                                              : Allow 
SRNS Inter All Failure Code                    : 15 
...      ...      ...

The following command provides information on how IDFT is configured: 

show iups-service name service_name

The output of this command indicates whether IDFT is enabled or disabled for the RNC configuration. If the E-Node Direct Data Forwarding setting reads "Disabled," then IDFT is enabled. If it reads "Enabled," then IDFT is disabled. 

show iups-service name service-name 
..      ..      .. 
Available RNC: 
..      ..      .. 
 E-NodeB Direct Data Forwarding        : Disabled 
..      ..      ..

Monitoring and Troubleshooting SRNS Relocation

This section provides information that assists operators in monitoring and troubleshooting the SRSN Relocation feature.

SRNS Bulk Statistics

The following statistics are included in the SGSN Schema in support of the SRNS Relocation feature. For detailed descriptions of these bulk statistics, refer to the Statistics and Counters Reference.

Table 12. SRNS Relocation Feature Bulk Statistics
Bulk Statistics Supporting SRNS Relocation Feature
SRNS-ctxt-req-sent srns-ctx-deny-ip-up-failure
SRNS-ctxt-rsp-rcvd srns-ctx-deny-reloc-alloc-expiry
SRNS-ctxt-req-tmr-expired srns-ctx-deny-reloc-failure-target-system
SRNS-ctxt-total-pdp-acc srns-ctx-deny-invalid-rdb-id
SRNS-ctxt-total-pdp-rej srns-ctx-deny-no-remaining-rab
SRNS-data-fwd-cmd-sent srns-ctx-deny-interaction-with-other-proc
srns-ctx-deny-rab-preempt srns-ctx-deny-integrity-check-fail
srns-ctx-deny-reloc-overall-tmr-exp srns-ctx-deny-req-type-not-supported
srns-ctx-deny-reloc-prep-tmr-exp srns-ctx-deny-req-superseeded
srns-ctx-deny-reloc-complete-tmr-exp srns-ctx-deny-rel-due-to-ue-sig-con-rel
srns-ctx-deny-queuing-tmr-exp srns-ctx-deny-res-optimization-reloc
srns-ctx-deny-reloc-triggered srns-ctx-deny-req-info-unavail
srns-ctx-deny-unable-to-est-reloc srns-ctx-deny-reloc-due-to-radio-reason
srns-ctx-deny-unknown-target-rnc srns-ctx-deny-reloc-unsupport-target-sys
srns-ctx-deny-reloc-cancel srns-ctx-deny-directed-retry
srns-ctx-deny-reloc-success srns-ctx-deny-radio-con-with-ue-lost
srns-ctx-deny-cypher-algo-no-support srns-ctx-deny-rnc-unable-to-estab-all-rfcs
srns-ctx-deny-conflict-cypher-info srns-ctx-deny-deciphering-keys-unavail
srns-ctx-deny-failure-radio-if-proc srns-ctx-deny-dedicated-assist-data-unavail
srns-ctx-deny-rel-utran-reason srns-ctx-deny-reloc-target-not-allowed
srns-ctx-deny-utran-inactivity srns-ctx-deny-location-reporting-congestion
srns-ctx-deny-time-crit-relocation srns-ctx-deny-reduce-load-in-serving-cell
srns-ctx-deny-req-traffic-class-unavail srns-ctx-deny-no-radio-res-avail-target-cell
srns-ctx-deny-invalid-rab-param-val srns-ctx-deny-geran-iu-mode-failure
srns-ctx-deny-req-max-bit-rate-unavail srns-ctx-deny-access-restrict-shared-nwtk
srns-ctx-deny-req-max-bit-rate-dl-unavail srns-ctx-deny-in-reloc-nwt-support-puesbine
srns-ctx-deny-req-max-bit-rate-ul-unavail srns-ctx-deny-traffic-target-more-src-cell
srns-ctx-deny-req-gbr-unavail srns-ctx-deny-mbms-no-multicat-svc-for-ue
srns-ctx-deny-req-gbr-dl-unavail srns-ctx-deny-mbms-unknown-ue-id
srns-ctx-deny-req-gbr-ul-unavail srns-ctx-deny-mbms-sess-start-no-data-bearer
srns-ctx-deny-req-trans-delay-not-achieve srns-ctx-deny-mbms-superseed-nnsf
srns-ctx-deny-inval-rab-param-combo srns-ctx-deny-mbms-ue-linking-already-done
srns-ctx-deny-violation-for-sdu-param srns-ctx-deny-mbms-ue-delinking-failure
srns-ctx-deny-violation-traffic-hanlde-prio srns-ctx-deny-tmgi-unknown
srns-ctx-deny-violation-for-gbr srns-ctx-deny-ms-unspecified-failure
srns-ctx-deny-usr-plane-ver-unsupported srns-ctx-deny-no-response-from-rnc

Show Command Output Supporting the SRNS Relocation Feature

This section provides information regarding CLI show commands that provide output to support of the SRSN Relocation feature.

The following show commands are available in support of the SRNS Relocation feature on the SGSN and the S4-SGSN:

show s4-sgsn statistics all

show gmm-sm statistics

The following counters are included in the show gmm-sm statistics command output to support the SRNS Relocation feature. These statistics provide information on RAN application messages and the total number of attempted and successful SGSN Gn/Gp and S4-SGSN SRNS relocations. These totals are further subdivided by SRNS relocation type. Note that these statistics apply to the SGSN (Gn/Gp) and the S4-SGSN on the SGSN-RNC-UE interface side. For detailed descriptions of these statistics, refer to the Statistics and Counters Reference.
Table 13. GMM SM Statistics Supporting SRNS Relocation
GMM SM Statistics Supporting SRNS Relocation
RANAP Procedures

Relocation Required

Relocation Request

Relocation Failure

Relocation Cancel

Relocation Detect

Relocation Complete

Relocation Command

Relocation Request Ack

Relocation Prep Failure

Relocation Cancel Ack

3G-SRNS Stats

Attempted

Total SRNS

Intra-SGSN SRNS

Intra-SRNS UE involved

Intra-SRNS UE not involved

Inter-SGSN SRNS

Inter-SRNS UE involved (old SGSN)

Inter-SRNS UE not involved (old SGSN)

Inter-SGSN UE involved (new SGSN)

Inter-SGSN UE not involved (new SGSN)

Inter-SGSN UE involved (old SGSN with MME)

Inter-SGSN UE not involved (old SGSN with MME

Inter-SGSN UE involved (new SGSN with MME)

Inter-SGSN UE not involved (new SGSN with MME)

Successful

Total SRNS

Intra-SGSN SRNS

Intra-SRNS UE involved

Intra-SRNS UE not involved

Inter-SGSN SRNS

Inter-SRNS UE involved (old SGSN)

Inter-SRNS UE not involved (old SGSN)

Inter-SGSN UE involved (new SGSN)

Inter-SGSN UE not involved (new SGSN)

Inter-SGSN UE involved (old SGSN with MME)

Inter-SGSN UE not involved (old SGSN with MME

Inter-SGSN UE involved (new SGSN with MME)

Inter-SGSN UE not involved (new SGSN with MME)

The following counters are included in the show s4-sgsn statistics all command output in support of the SRNS Relocation feature. These statistics apply to the S4 interface network level. They provide information on the number and type of SRNS SGW relocations, SRNS procedure aborts, and IDFT packets and bytes sent to and from the SGW (if IDFT is enabled). For detailed descriptions of these statistics, refer to the Statistics and Counters Reference.
Table 14. Statistics Supporting S4-SGSN SRNS Relocation
Statistics Supporting SRNS Relocation on the S4-SGSN

SGW Relocations

3G Intra SGSN SRNS Relocation

3G Inter SGSN SRNS Relocation (S16)

MME-SGSN SRNS Relocation (S3)

Procedure Abort Statistics

3G Intra SRNS Abort Due to Total CSR Failure

3G New SGSN SRNS Abort Due to Total CSR Failure

GTPU Statistics

IDFT packets to SGW

IDFT packets from SGW

IDFT bytes to SGW

IDFT bytes from SGW