LTE Session Management

Technical Product Description

42/221 02-AXB 250 05/8 Uen NV

Copyright

© Ericsson AB 2009–2019. All rights reserved. No part of this document may be

reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use of this
document.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Contents

Contents

1 LTE Session Management Overview 1

1.1 End-User IP Addresses 2
1.2 QoS at Bearer Level 2
1.3 AMBR 3
1.4 Bearer TFT 3
1.5 MME Emergency Configuration Data 3
1.6 IMS APN Identification 4

2 PDN Connection Creation 5

2.1 PDN Connectivity Procedure during Attach 5
2.2 Standalone PDN Connectivity Procedure 6
2.2.1 Traffic Case 7
2.2.2 APN-Based Congestion Control 10

3 PGW and SGW Selection during PDN Connectivity Procedures 12

3.1 APN Resolving 14
3.2 Retrieve a Static PGW from the HSS 15
3.3 Retrieve PGWs from the IMSI-Based Gateway Selection
Profile 15
3.4 Retrieve PGWs from the SAPC over Smp 16
3.5 Retrieve PGWs from the Static PGW Selection Table 16
3.6 Retrieve PGWs Based on DNS Query with APN 17
3.6.1 DNS S-NAPTR Procedure for the PGW 17
3.6.2 DNS S-NAPTR Procedure for Combined PGW-Cs and SMFs 19
3.7 Sorting PGW Candidates 20
3.7.1 Optional Function for Sorting the PGW with the GTP-C Load
Information 21
3.8 Retrieving SGWs from the IMSI-Based Gateway Selection
Profile 22
3.9 Retrieving SGWs Based on IMSI Number Series and
Geographical Area 23
3.10 Retrieving SGWs from Static SGW Selection Table 24
3.11 Retrieving SGWs Based on DNS Query with TAI 25
3.11.1 DNS S-NAPTR Procedure for SGW 25
3.12 Sorting SGW Candidates 27
3.12.1 Optional Function for Sorting the SGW with the GTP-C Load
Information 27

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

LTE Session Management

3.13 Sorting PGW-SGW Pairs 28

3.13.1 Sorting Gateway Pairs Based on NR Capability 31
3.13.2 Sorting Gateway Pairs Based on the UE Usage Type 32
3.13.3 Sorting Gateway Pairs Based on the Blacklisting Status 32
3.13.4 Example of Sorting SGW-PGW Pairs in the 3GPP Sequence 32
3.13.5 Example of Sorting Gateway Pairs in the SGW-Prioritized
Sequence 33
3.14 Retrieving IP Addresses 34

4 Gateway Pair Fallback 36

5 Specific Gateway Selection during Mobility Procedures 38

5.1 IMSI-Based Gateway Selection 39
5.2 PGW Selection during Handover from Non-3GPP Networks to
LTE 39
5.3 SGW Selection for UEs with Connections to Multiple PGWs 40
5.3.1 Example with an Existing EMC PDN Connection 40
5.3.2 Example without an Existing EMC or IMS PDN Connection 41
5.3.3 Example without an EMC or IMS PDN Connection 41
5.4 PGW Reselection 42

6 PDN Disconnection 45
6.1 UE- or MME-Initiated PDN Disconnection 45
6.1.1 Traffic Case 45
6.2 PGW-Initiated PDN Disconnection 47
6.2.1 Traffic Case 48

7 HSS-Based P-CSCF Restoration 51

7.1 Basic Mechanism 51
7.2 Optional Extension 51
7.2.1 Limitation 52

8 Activation of Dedicated Bearers 53

8.1 PGW-Initiated Activation of Dedicated Bearers 53
8.1.1 Traffic Case 53
8.2 Dedicated Bearer Activation in Combination with the Default
Bearer Activation 54

9 Deactivation of Dedicated Bearers 57

9.1 PGW-Initiated Deactivation of Dedicated Bearers 57
9.1.1 Traffic Case 57
9.2 MME-Initiated Deactivation of Dedicated Bearers 59
9.2.1 Timer-Based Deactivation of GBR Bearers 59
9.2.2 Traffic Case 61
9.2.3 Traffic Case with NR Usage Data Reporting 62

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Contents

10 Modification of Bearers 65
10.1 PGW-Initiated Bearer Modification without Bearer QoS
Update 65
10.1.1 Traffic Case 65
10.2 PGW-Initiated Bearer Modification with Bearer QoS Update 66
10.2.1 Traffic Case 66
10.3 HSS-Initiated Subscribed QoS Modification 68
10.3.1 HSS-Initiated Subscribed UE-AMBR Modification 68
10.3.2 HSS-Initiated Subscribed APN-AMBR or Bearer Level QoS
Modification 69
10.4 QoS Modification in IRAT Mobility 71
10.4.1 Traffic Case 71
10.5 Establishing an S11-U Connection for Data over NAS 72
10.6 E-UTRAN Initiated E-RAB Modification Procedure 73

11 UE Requested Bearer Resource Modification 74

12 Forward RAN/NAS Cause Codes to the SGW 76

13 Operation and Maintenance 77

13.1 Parameters 77
13.2 Counters 77
13.3 Alarms and Events 78
13.4 Logs 78

14 Compliance 79

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

LTE Session Management

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 LTE Session Management Overview

1 LTE Session Management Overview

The EPS session management function of the MME establishes and handles the
connections between the UE and one or several PDNs.

A PDN connection consists of one default bearer and, depending on the service
for which the connection is used, several dedicated bearers. Each default or
dedicated bearer is assigned a payload tunnel between the UE and the PGW,
through the eNodeB and the SGW. A UE can have one or several PDNs.

UE eNodeB SGW PGW

PDN Connection
Dedicated bearer

Dedicated bearer PDN

Default bearer

Figure 1 Logical View of a PDN Connection

The default bearer remains established throughout the lifetime of the PDN
connection to provide the UE with IP connectivity to the PDN. The number of
dedicated bearers that are established can vary throughout the lifetime of the
connection. The information about the PDN connection is stored in the MME. This
information is used when connections or bearers are for instance, modified or
deactivated.

The default bearer is a non-GBR bearer. A dedicated bearer can be either a GBR
or a non-GBR bearer.

When the UE changes state from ECM-CONNECTED to ECM-IDLE, all radio

resources are released, but the information about the PDN connection remains
stored in the packet core. All radio resources are restored again when a network
or UE-initiated Service Request is received.

For a UE not supporting EMM-REGISTERED without PDN Connection to remain

in the EMM-REGISTERED state, at least one PDN connection must exist. When
the last PDN connection is removed, the UE is detached and moves to the EMM-
DEREGISTERED state.

For a UE supporting EMM-REGISTERED without PDN Connection, the UE can

stay in the EMM-REGISTERED state without any PDN connection.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 1

 LTE Session Management

For more information about the EMM and ECM states, see LTE Mobility
Management.

The EPS Session management function handles the following main procedures:

— PDN Connection Creation (default bearer activation)

— PDN Disconnection (default bearer deactivation)

— Activation of Dedicated Bearers

— Deactivation of Dedicated Bearers

— Modification of Bearers

— Network-Initiated Service Request

— S1 Release

For more information about the Mobility Management procedures that involve
Session Management, see LTE Mobility Management.

For compliance information about procedures and protocols, see Compliance on

page 79.

For information about session management in the S4-SGSN, see GSM and
WCDMA Session Management.

1.1 End-User IP Addresses

The MME supports static IP addresses retrieved from the HSS and dynamic IP
addresses from the PGW. The MME supports IPv4, IPv6, and IPv4v6 for end
users.

1.2 QoS at Bearer Level

Each GBR and non-GBR EPS bearer is controlled by the following bearer-level
QoS parameters:

QCI The QCI parameter is a scalar used as a reference to

access node-specific parameters that control bearer level
packet forwarding treatment. The treatment of the QCI is
configured in the eNodeB. Operator-specific QCI is
supported.

Evolved ARP The evolved ARP parameter decides whether a Bearer

Establishment or Modification Request can be accepted
or needs to be rejected if there are resource limitations. In
addition, the evolved ARP parameter can be used, for

2 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 LTE Session Management Overview

example, by the eNodeB to decide which bearer to drop

during exceptional resource limitations, for example, at
handover.

Each GBR bearer is also associated with the following bearer-level QoS
parameters:

GBR The GBR parameter determines the minimum bit rate

provided by a GBR bearer.

MBR The MBR parameter limits the bit rate provided by a GBR
bearer. For example, excess traffic can be discarded by a
rate shaping function. The MBR can be greater than or
equal to the GBR for a particular GBR bearer.

1.3 AMBR
The AMBR is described using the following parameters:

APN-AMBR The APN-AMBR is a subscription parameter stored for

each APN in the HSS. It limits the total bit rate that can
be expected across all non-GBR bearers and across all
PDN connections of the same APN. APN-AMBR can be
modified by the PGW through negotiation with the PCRF.

UE-AMBR Each UE in the EMM-REGISTERED with PDN connection

state is associated with an AMBR for the UE. This
parameter is limited by a subscription parameter stored in
the HSS. The UE-AMBR limits the aggregate bit rate that
can be expected across all non-GBR bearers of a UE. The
MME sets the UE-AMBR to the sum of the APN-AMBR of
all active APNs up to the value of the subscribed UE-
AMBR.

1.4 Bearer TFT

The bearer TFT is the set of all packet filters associated with a specific bearer. IP
packets are routed based on the information in the TFT. Packet filters are
optional for the default bearer and mandatory for the dedicated bearers. The TFT
is transparently transferred to the MME.

For more information, see SoC with 3GPP TS 23.401.

1.5 MME Emergency Configuration Data

Specific parameters can be defined for QoS and APN. For more information about
MME emergency configuration data, see Configuring MMTel Service.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 3

 LTE Session Management

1.6 IMS APN Identification

By default, APN ims (case-insensitive) is regarded as an IMS APN. In addition,
the SGSN-MME makes it possible for operators to configure an extra IMS APN list
by using the create_additional_ims_apn CLI command. If a PDN connection has
APN ims or an APN in the additional IMS APN list, the PDN connection is
regarded as an IMS PDN connection.

4 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PDN Connection Creation

2 PDN Connection Creation

A PDN connection is established through the PDN Connectivity procedure

contained in the Attach procedure or through the standalone PDN Connectivity
procedure. PDN connections are identified by the APN and PDN type. When
creating a PDN connection, a default bearer is activated providing the UE with IP
connectivity to the PDN. The initial QoS settings of the default bearer are
assigned by the network based on the subscription data of the UE. The PGW can
change the QoS settings during the creation of the default bearer.

The MME now supports sending a timestamp and maximum waiting time to the
SGW in the Create Session Request message. The timestamp is used by the
SGW or other network functions to ensure that the most recent PDN session is
not incorrectly overwritten. Together with the maximum waiting time, the
timestamp is also used by the SGW or other network functions to stop further
processing of Create Session Request messages which have already timed
out at the MME. This can be achieved by optionally setting the new
SendOriginationTimeStamp parameter to on and the new MaxWaitTimeOffset
parameter to 0 or a positive integer smaller than the value of
T3ResponseCreateSessionMs and T3ResponseCreateSessionMsS8,
respectively. However, this optional function is sensitive to the accuracy of the
network time and to the time synchronization between network elements. If time
synchronization between network elements or the accuracy of the network time
cannot be guaranteed, Ericsson recommends disabling this function by setting
the SendOriginationTimeStamp parameter to off.

Dedicated bearers can be activated during the PDN Connectivity procedure or

later. For more information, see Activation of Dedicated Bearers on page 53.

The Time Zones function sends the UE local time zone to the SGW, which enables
time-based charging in the SGW or PGW, or both. For more information about
the Time Zones function, refer to LTE Mobility Management.

For more information about dedicated bearer procedures, see PGW-Initiated

Activation of Dedicated Bearers on page 53 and PGW-Initiated Deactivation of
Dedicated Bearers on page 57.

2.1 PDN Connectivity Procedure during Attach

When the UE is not registered in the network, the UE sends an Attach Request
message to the MME to initiate the Attach procedure. If the Attach Request
message includes the PDN Connectivity Request message, the initial PDN
connection is created during the Attach procedure. Attach Request and PDN
Connectivity Request messages that indicate emergency are prioritized in
instances of resource limitation. For a UE that is emergency-attached, additional
PDN connections cannot be created. The Attach procedure establishes one PDN
connection. The setup of additional PDN connections can be performed when the
Attach procedure is completed.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 5

 LTE Session Management

For UEs not supporting EMM-REGISTERED without PDN Connection, the initial
PDN connection is established during the Attach procedure.

For UEs supporting EMM-REGISTERED without PDN Connection, the initial PDN
connection can be created through the Attach procedure or the Standalone PDN
Connectivity procedure.

For information about the Attach procedure, see LTE Mobility Management and
Inter-System Mobility Management.

2.2 Standalone PDN Connectivity Procedure

The Standalone PDN Connectivity procedure is used when the attached UE
requests to set up PDN connections over the SGi interface. This procedure is
described in Figure 2. For more information, see SoC with 3GPP TS 23.401. For a
UE with an emergency PDN connection, additional PDN connections cannot be
created.

One or several PDNs can be accessed by using the same PGW or different PGWs.
It is only possible to have one SGW per UE.

If the UE is in the ECM-IDLE state, the Service Request procedure or the Control
Plane Service Request procedure is performed before the PDN Connectivity
procedure can be initiated. The Service Request procedure is described in LTE
Mobility Management. The Control Plane Service Request procedure is described
in Massive IoT.

If the UE supports EMM-REGISTERED without PDN Connection and the PDN-

connection-restricted bit is set in the UE subscription data, the MME rejects
the PDN Connectivity Request message sent from the UE. However, the
emergency PDN connectivity is always handled in the normal way.

6 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PDN Connection Creation

2.2.1 Traffic Case

UE eNodeB MME SGW PGW HSS

1. PDN Connectivity Request

2. Create Session Request

3. Create Session Response

4.1 E-RAB Setup Request (Activate Default EPS Bearer Context Request)
/ Initial Context Setup Request (Activate Default EPS Bearer Context Request)

4.2 RRC Connection Reconfiguration (Activate Default EPS Bearer Context Request)

4.3 RRC Connection Reconfiguration Complete

4.4 E-RAB Setup Response

/ Initial Context Setup Response

4.5 Activate Default EPS Bearer Context Accept

4.6 Modify Bearer Request

4.7 Modify Bearer Response

4.1 Downlink NAS Transport

(Activate Default EPS Bearer Context Request)

4.2 Uplink NAS Transport

(Activate Default EPS Bearer Context Accept)

5. Notify Request

6. Notify Answer

7. GUTI Reallocation Command

8. GUTI Reallocation Complete

Figure 2 Standalone PDN Connectivity Procedure

The following steps describe the Standalone PDN Connectivity procedure:

1. The UE sends a PDN Connectivity Request message that can contain a

requested APN to the MME. The Request Type indicates 'initial request' or
'emergency' if the UE requests PDN connectivity. The Request Type indicates
'handover' or 'handover of emergency bearer services' if the UE has
previously been connected to a PDN connection over a non-3GPP access
type.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 7

 LTE Session Management

If the maximum number of bearers per UE is exceeded, the request is

rejected with the cause code MAXIMUM_NUMBER_OF_EPS_BEARERS_REACHED.
The maximum limit of allowed bearers per UE is configured using the
MaxBearersPerUe parameter.

If the PDN Type indicates 'non IP' in a PDN Connectivity Request

message and the APN is subscribed with the SCEF information, the MME sets
up the PDN connection to the SCEF. For more information, see Non-IP Data
Delivery over SCEF.

If the resolved APN matches the configured APN blacklist for the UE, the
PDN Connectivity Request is rejected with the ESM cause code #32 Service
option not supported.

2. The MME selects an SGW, if the request is to establish the first PDN
connection for the UE in the EMM-REGISTERED state without PDN
Connection.

The MME uses the subscription data to verify that the APN that is requested
by the UE is allowed and determines which PGW to contact. For more
information about APN resolving and PGW selection, see PGW and SGW
Selection during PDN Connectivity Procedures on page 12. The MME
allocates the identity bearer and sends a Create Session Request
message to the PGW through the SGW. The request message includes the
International Mobile Subscriber Identity (IMSI) of the UE, an APN, and QoS
parameters, and the TEID of the MME for signaling traffic.

If there is an emergency PDN connection with the request type 'emergency'

is setup, the MME emergency configuration data is used instead of the
subscription data. If an emergency PDN connection with the request type
'handover of emergency bearer services' is setup, for the non-roaming
authenticated UE, either the emergency PGW from the MME emergency
configuration data or the emergency PGW from HSS is used according to the
-ecvh EmergencyContinuityViaHss parameter in modify_plmn command.
For the roaming authenticated UE and the unauthenticated UE, the
emergency PGW from the MME emergency configuration data is used. When
the MME emergency configuration data is used, either the PGW is derived
from the DNS query on the emergency APN or the locally configured PGW is
used according to the -epsm EmergencyPgwSelectionMode parameter in
the modify_ims_emergency_service CLI command.

The MME can set the S11-U Tunnel flag and the Control Plane Only PDN
Connection Indication flag and include the S11-U MME F-TEID in the
Create Session Request message according to the MME local
configuration policies, the UE-preferred CIoT network behavior, and the UE-
supported CIoT network behavior. For more information, see Massive IoT.

If the APN configuration in subscription data for one PDN supports

interworking with 5GS, and a combined PGW-C and SMF is selected, then
the 5GC Not Restricted Indication (5GCNRI) and the 5GC Not
Restricted Support (5GCNRS) IEs are both included and set to 1 in
the Create Session Request message.

8 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PDN Connection Creation

3. The PGW creates an entry in the EPS bearer context table. After negotiating
with the PCRF, the PGW sends a Create Session Response message to
the MME through the SGW.

4. The subsequent procedure depends on whether the UE uses DoNAS.

If the UE does not use DoNAS, the following procedure applies:

a. If the Standalone PDN Connectivity procedure is to establish

additional PDN connections for the UE, the MME recalculates the UE-
AMBR and sends it to the eNodeB in an E-RAB Setup Request
message. The E-RAB Setup Request message contains the
Activate Default EPS Bearer Context Request message, the
TEID, and the address of the SGW for the user plane traffic. For more
information about how the UE-AMBR is calculated, see AMBR on
page 3.

If the Standalone PDN Connectivity procedure is to establish the first

PDN connection for the UE in the EMM-REGISTERED state without
PDN Connection, the MME sends an Initial Context Setup
Request message instead of an E-RAB Setup Request message.

A timer is started to supervise the setup of the Activate Default

EPS Bearer Context Request message. If the timer expires, the
Activate Default EPS Bearer Context Request message is
resent. If no answer is received after four retransmissions, the bearer
is marked as failed in the MME.
b. The eNodeB sends the Activate Default EPS Bearer Context
Request message to the UE in an RRC Connection Reconfiguration
message.
c. The UE answers by sending an RRC Connection Reconfiguration
Complete message to the eNodeB.

d. The eNodeB sends an E-RAB Setup Response message or an

Initial Context Setup Response message. The message
contains the TEID and the address of the eNodeB used for the user
plane traffic to the MME.
e. The UE sends the Activate Default EPS Bearer Context
Accept message containing the identity of the bearer to the MME
through the eNodeB.
f. Upon reception of the Activate Default EPS Bearer Context
Accept message, the timer is stopped and the MME sends a Modify
Bearer Request message to the SGW. The message contains the
identity of the bearer, the eNodeB address, and the TEID for the user
plane traffic.

If the Request Type is 'handover', the Modify Bearer Request

message is forwarded to the PGW, which replies with a Modify
Bearer Response message to the SGW.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 9

 LTE Session Management

g. The SGW acknowledges the request by sending the Modify Bearer

Response message containing the identity of the bearers to the MME.

If the UE uses DoNAS, the following procedure applies:

a. The MME sends a Downlink NAS Transport message to the UE

through the eNodeB. The Downlink NAS Transport message
contains the Activate Default EPS Bearer Context Request
sub-message, and the PDN Address IE in this sub-message is set as
IP/0.0.0.0.
b. The UE responds with an Uplink NAS Transport message. The
Uplink NAS Transport message contains the Activate Default
EPS Bearer Context Accept sub-message.

The MME can set the S11-U Tunnel flag and the Control Plane Only
PDN Connection Indication flag and include the S11-U MME F-TEID
in the Create Session Request message according to the MME
local configuration policies, the UE-preferred CIoT network behavior
and the UE-supported CIoT network behavior. For more information,
see Massive IoT.

5. If the UE has non-3GPP capability, and the PGW identity differs from the
one that the HSS indicated in the subscription data, the MME sends a Notify
Request message containing the PGW identity and the APN to the HSS. If
the PDN connection is for the emergency service, only the emergency PGW
identity is sent in the Notify Request message.

The MME can be configured to send fewer Notify Request messages to the
HSS. For more information, see Subscriber Data Management.

6. The HSS responds with a Notify Answer message to the MME.

7. If the request described in establishes the first SGi PDN connection for the
UE, and the TAI list changes as a result based on the selected SGW, the MME
sends the GUTI Reallocation Command message with an updated TAI list
to the UE.

8. The UE responds with a GUTI Reallocation Complete message to the

MME.

2.2.2 APN-Based Congestion Control

PGW-initiated APN-Based Congestion Control is an overload protection
mechanism used to protect the PGW. The mechanism is triggered by the PGW
and requires support in the MME. During congestion, the PGW responds with the
APN_CONGESTION cause code and a Back-Off Time IE in the Create Session
Response message for Attach and PDN Connectivity procedures sent to the MME.

When the MME receives the APN_CONGESTION cause code and a Back-Off Time
IE from the PGW, the MME performs the maximum number of fallback attempts
specified by the value of the GwMaxAttemptNumber parameter minus 1 to the

10 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PDN Connection Creation

PGWs in the gateway candidate list. If all the tried PGWs indicate APN
congestion and back-off time, the lowest back-off time value is sent to the UE.
During congestion, the MME stores the back-off time value included in the
Create Session Response message sent from the PGW for a specific APN.

The MME rejects the Attach or PDN Connectivity procedures without sending a
Create Session Request message, if all the PGWs indicate congestion and
have an active back-off timer for the specific APN.

Using the CongestedPgwSlipThroughRate parameter, it is possible to configure

the probability that the MME sends a Create Session Request message during
an Attach or a PDN Connectivity procedure to the congested PGW. This enables
the MME to detect if the situation is improved and to get an accurate back-off
time value.

The APN-Based Congestion Control mechanism is enabled by setting the

PgwInitApnCongestionSupport parameter. During congestion, if the parameter
is set to off, the MME ignores the Back-Off Time IE sent from the PGW.

The APN-Based Congestion Control mechanism does not affect UEs that are
MPS-classified in the subscription data or UEs that indicate emergency in the
Attach Request and PDN Connectivity Request messages.

For more information, see SoC with 3GPP TS 23.401.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 11

 LTE Session Management

3 PGW and SGW Selection during PDN

Connectivity Procedures

During PDN connectivity procedures, the MME selects a PGW and an SGW.
PGW Selection SGW Selection

First PDN Connectivity No

Procedure ?
APN Resolving
Yes

MME Pool Retrieving SGWs from IMSI-Based

Candidates exist
Gateway Selection Profile

Candidates not exist

Retrieving a Static PGW from HSS Candidates exist

imsi_and_ga_based_
Off
Candidates not exist sgw_selection
parameter

On
Retrieving PGWs from IMSI-Based
Candidates exist
Gatewa Selection Profile

ImsiGaBasedSgwSelection
Off
Candidates not exist parameter on IMSINS level

On
Retrieving PGWs
Candidates exist
from SAPC over Smp
Retrieving SGWs Based on
Candidates exist
IMSI Number Series and GA
Candidates not exist
Candidates not exist

static_gw_selection dns_prior_to_static_gw_selection static_gw_selection dns_prior_to_static_gw_selection

On Off On Off
parameter parameter parameter parameter

On On

Off Off
Retrieving PGWs Retrieving PGWs Retrieving SGWs Retrieving SGWs
Candidates exist Based on DNS from Static PGW Candidates exist Based on DNS from Static SGW
Query with APN Selection Table Query with TAI Selection Table
Retrieving PGWs Based on Retrieving SGWs Based on
Candidates not exist Candidates not exist Candidates exist Candidates not exist Candidates not exist Candidates exist
DNS Query with APN DNS Query with TAI

Retrieving PGWs Retrieving SGWs Retrieving SGWs Retrieving SGWs

from Static PGW Based on DNS from Static SGW Based on DNS
Selection Table Query with APN Selection Table Query with TAI

gtpc_network_load_control gtpc_network_load_control
and Off
and Off
GwSelectionWithGtpcLocadInfo GwSelectionWithGtpcLocadInfo
parameters parameters

On On

Sorting PGW Candidates with Sorting PGW Candidates

Sorting SGW Candidates with Sorting SGW Candidates
the GTP-C Load Information the GTP-C Load Information

Sorting PGW-SGW Pairs

Retrieving PGW and

SGW IP Addresses

PGW and SGW IP

Addresses Selected

Figure 3 PGW and SGW Selection during Attach and PDN Connectivity
Procedures

The PGW selection function of the MME allocates a PGW to provide PDN
connectivity for 3GPP access. The UE requests the APN and the subscriber
information provided by the HSS. An APN is a logical name referring to PDN
connections and the service to which the subscriber connects. The MME can also
use configured selection criteria when selecting the PGW.

The MME procedure for selecting a PGW is as follows:

1. The MME resolves the APN.

2. If it exists, the MME uses a static PGW in subscription data from the HSS.

12 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

3. If Retrieve PGWs from the IMSI-Based Gateway Selection Profile on page

15 is configured on the MME, the MME selects the PGW based on the IMSI
or IMSI number series.

4. If the optional Mobility-Based Policy feature is enabled, the PGW can be

retrieved over Smp.

5. If static PGW selection is enabled on the MME before a DNS query, the MME
selects a locally configured PGW.

6. Otherwise, the MME uses DNS queries to retrieve the PGW.

When establishing additional PDN connections using the PDN Connectivity

procedure, the MME selects the same PGW if the additional PDN connection uses
the same APN as for the existing PDN. Otherwise, the MME can select a new or
the same PGW using the procedure described in the previous list.

For IMS Emergency PDN, the emergency PGW selection mode can be configured
as local preferred or DNS preferred:
— If the emergency PGW selection mode is local preferred, the emergency PGW
lists from the MME emergency configuration data are used. In this mode, the
emergency PGW cannot be configured in the local static PGW table, but only
be configured in the emergency profile. When multiple PGWs have the same
priority in the emergency profile, the MME selects the PGW randomly.

— If the emergency PGW selection mode is DNS preferred, the PGW selection
based on the APN in the MME emergency configuration data is performed to
DNS.

If an IMS emergency PDN handed over from non-3GPP access is used for the
non-roaming authenticated UE, the emergency PGW from the MME emergency
configuration data, the emergency PGW from the DNS resource record, or the
emergency PGW from the HSS is used. For more information, see Configuring
MMTel Service.

The PGW is not changed during mobility procedures. However, DNS queries can
be performed to collect additional information related to existing PDN
connections.

The MME procedure for selecting an SGW is as follows:

1. If Retrieving SGWs from the IMSI-Based Gateway Selection Profile on page

22 is configured on the MME, the MME selects the SGW based on the IMSI
or IMSI number series.

2. If SGW Selection Based on IMSI Number Series and Geographical Area is

configured on the MME, the MME selects an SGW based on the IMSI number
series and TAI.

3. If static SGW selection is enabled on the MME before a DNS query, the MME
selects a locally configured SGW.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 13

 LTE Session Management

4. Otherwise, the MME uses DNS queries to select the SGW based on TAI.

When establishing additional PDN connections using the PDN connectivity

procedure, the SGW is not changed.

For the SGW Reselection procedure during mobility procedures, see section
Specific Gateway Selection during Mobility Procedures on page 38.

After the PGW and the SGW candidates are selected, the MME continues the
gateway selection procedure by sorting the gateway pairs and retrieving their IP
addresses.

PGW and SGW candidate selections are independent of each other until the
sorting of gateway pairs. Therefore, it is possible to use a different GW selection
method for each candidate. For example, the PGW selection can be based on
static configuration and the SGW selection can be based on the DNS query, or the
other way around. However, Ericsson recommends maintaining uniformity and
using the same selection method for the PGW and the SGW.

Note: The DECOR feature provides the possibility to select dedicated SGWs
and PGWs serving specific types of UEs. For more information, see
Dedicated Core Network.

The Gateway Selection for NR Usage feature provides the possibility to

select SGWs and PGWs supporting NR for UEs allowed to use NR as a
secondary RAT. For more information, see 5G EPC.

3.1 APN Resolving

An APN is a logical name referring to a PDN and the service to which the
subscriber connects.

The APN is constructed of two types of identifiers:

APN-NI The APN-NI is a mandatory part of the APN, which

defines the PDN connectivity and services requested by
the UE. An APN-NI corresponds to an internet domain
name to guarantee the uniqueness of APN-NIs between
PLMNs. The MME selects the APN-NI according to the UE
requested information, subscription data, and MME local
configuration.

APN-OI The APN-OI is the domain name of the operator. For a

home subscriber, the MME selects the APN-OI based on
the configured IMSI number series. For a roaming
subscriber, the APN-OI is based on the IMSI number
series configuration in the MME if the PDN is home
routed. For local breakout, the APN-OI is based on the
PLMN-ID of the current location of the UE.

14 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

For IMS Emergency Service, the APN-OI is the same as

the PLMN of the current serving network.

The purpose of APN resolving is to determine which APN name to use for a PDN
connection.

The APN resolving procedure is as follows:

— If the UE does not request an APN, the default APN in the subscription data
is used.

— If the UE requests an APN that matches an APN in the subscription data,

that APN is used.

— If the UE requests an IMS emergency service, the APN in the MME

emergency configuration data is used.

— If a DNS query fails or the UE requests an APN that does not match any APN
in the subscription data, the PDN connection is rejected.

If optional features, such as APN Conversion, APN Redirection, APN Resolution

Functional Extension, and APN-OI Replacement, are enabled, they can affect the
APN name used in the gateway selection during specific conditions. For more
information, see APN Resolve and Redirect for LTE Access.

For the Attach combined with PDN Connectivity Request procedure, if the
resolved APN matches the configured APN blacklist, the MME rejects the PDN
Connectivity Request and the Attach Procedure based on whether the UE
supports EMM-REGISTERED without PDN Connection. For more information, see
APN Resolve and Redirect for LTE Access.

After the formulation of the APN name, the MME uses the APN to select a PGW
during the configured IMSI-based or static PGW selection or to select a PGW
during DNS query with APN.

3.2 Retrieve a Static PGW from the HSS

When a PGW is predefined in the subscription data in the HSS for a particular
APN, it is called a static PGW. If a static PGW exists, it is used as the only PGW
candidate. The MME always uses the FQDN if it exists as a static PGW in the
gateway selection when sorting the gateway pairs, see Sorting PGW-SGW Pairs
on page 28. Before sorting the gateway pairs, the operator must select an SGW
and check whether Retrieving SGWs from the IMSI-Based Gateway Selection
Profile on page 22 is configured.

3.3 Retrieve PGWs from the IMSI-Based Gateway Selection

Profile
IMSI-based PGW selection enables operators to allocate specified UEs to the
specified PGW.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 15

 LTE Session Management

The SGSN-MME selects a PGW based on the IMSI or IMSI number series when
the IMSI-Based Gateway Selection function is enabled and the following
configurations are performed:

— An IMSI-Based Gateway Selection profile is configured for the IMSI or the

IMSI number series.

— A PGW list is specified in the profile.

— The PGW list is configured with APN and PGW combinations. Each APN and
PGW combination consists of an APN, a primary PGW, and optionally a
secondary PGW for the APN.

For a specific UE with IMSI, the MME uses the APN for PDN connection setup
and as the input to find a PGW from the configured PGW list. If the APN does not
match any configured specific APN and a wildcard APN is configured, then the
wildcard APN is used as the input to find a PGW from the configured PGW list.

IMSI-based PGW selection is applicable for roaming users that set up a PDN
connection with local breakout and for home users.

For more information about how to configure IMSI-based PGW selection, see
Configuring IMSI-Based Gateway Selection.

Note: IMSI-based PGW selection is applicable for the S4-SGSN and the MME.

3.4 Retrieve PGWs from the SAPC over Smp

If the Mobility-Based Policy feature is enabled, the Ericsson PCRF (SAPC) can
provide a list of PGWs over the Smp interface. The PGW information sent by the
SAPC can be the FQDN, the IP address, or both. The MME randomly selects one
PGW-FQDN in the list retrieved from the SAPC to be used in the gateway
selection when sorting the gateway pairs, see Sorting PGW-SGW Pairs on page
28. Before sorting the gateway pairs, the SGW must be selected, starting with
the Retrieving SGWs from the IMSI-Based Gateway Selection Profile on page
22.

For more information about PGW selection with the Mobility-Based Policy
feature, see Mobility-Based Policy.

3.5 Retrieve PGWs from the Static PGW Selection Table

When the node function static_gw_selection is enabled using the
modify_node_function CLI command, the SGSN-MME selects an appropriate
PGW from the configured gateway selection table.

The MME selects a PGW from the configured static PGW selection tables in the
MME when the APN table, the PGW selection table, and the PGW table are
configured.

16 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

The MME uses the APN as the input to find candidate PGWs from the static PGW
selection tables. When the Advanced 4G/5G Interworking feature, the Dedicated
Core Network feature, and the Gateway Selection for NR Usage feature are
enabled, the MME uses the SMF, the UUT, and the NR Capability as extra filters to
select a PGW from the candidate PGWs. For more information about PGW
selection using the SMF, the UUT, and the NR Capability, see Advanced 4G/5G
Interworking, Dedicated Core Network and 5G EPC. The APN-OI replacement
functionality can also be used in the static PGW selection. For more information
about APN-OI replacement, see APN Resolve and Redirect for LTE Access.

Static gateway selection can be used to select the PGW for a roaming user only if
the roaming user sets up a PDN connection with local breakout.

For information about configuring static gateway selection, see Configuring

Static Gateway Selection in MME.

The MME continues the gateway selection by using an internal FQDN based on
the configured PGW hostnames to sort the PGW candidates, see Sorting PGW
Candidates on page 20.

3.6 Retrieve PGWs Based on DNS Query with APN

The MME determines the PGW candidates by a DNS query based on APN
through a DNS S-NAPTR procedure.

The DNS query uses the resolved APN to find the PGW candidates, see DNS S-
NAPTR Procedure for the PGW on page 17. For more information about APN
resolving, see APN Resolving on page 14.

The S-NAPTR procedure results in a list of PGW candidates based on FQDNs.

The MME continues by sorting the PGW candidates, see Sorting PGW Candidates
on page 20.

3.6.1 DNS S-NAPTR Procedure for the PGW

The MME performs a DNS S-NAPTR procedure using the resolved APN to get a
list of PGW candidates. The S-NAPTR procedure uses the APN-NI and the APN-
OI in a DNS query. The result of the DNS query is then filtered with an applicable
subset of the services required for the PDN connection.

When one, or both, of the two features Dedicated Core Network and Gateway
Selection for NR Usage are activated, multiple DNS S-NAPTR procedures are
performed with additional filtering.

When the Gateway Selection for NR Usage feature is activated and the UE is
allowed to use NR as a secondary RAT, the following two S-NAPTR procedures
are performed:

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 17

 LTE Session Management

— The S-NAPTR procedure is performed to retrieve PGW candidates supporting

NR. For example, the filtering candidates include +nc-nr appended to the
protocol.

— The S-NAPTR procedure is performed to retrieve PGW candidates not

supporting NR. For example, the filtering candidates do not include +nc-nr
appended to the protocol.

The PGW candidates are sorted as described in section 4.12.1. For more
information about the Gateway Selection for NR Usage feature, see 5G EPC.

When the Dedicated Core Network feature is activated, the following two S-
NAPTR procedures are performed:

— The S-NAPTR procedure is performed to retrieve the PGW candidates

dedicated to the specific UUT. For example, the filtering candidates include
+ue-<uut> appended to the protocol.

— The S-NAPTR procedure is performed to retrieve the PGW candidates not

dedicated to any specific UUT. For example, the filtering candidates do not
include +ue-<uut> appended to the protocol.

The PGW candidates are sorted as described in section 4.12.2. For more
information about the Dedicated Core Network feature, see Dedicated Core
Network.

Note: When both features are activated and the UE is allowed to use NR as a
secondary RAT, an additional S-NAPTR procedure is performed. This
procedure retrieves the PGW candidates supporting NR which are
dedicated to the specific UUT. For example, the filtering candidates
include both +nc-nr and +ue-<uut> appended to the protocol. These
candidates have the highest priority when the PGW-SGW pairs are
sorted.

The services used depend on the applicable interface and protocol and are listed
as follows:

— x-s5-gtp

— x-s5-pmip

— x-s8-gtp

— x-s8-pmip

— x-gp

TheSGSN-MME determines if the S5 or the S8 interface is used between the

gateways. The S5 interface is applied for home subscribers and for roaming
subscribers for a local breakout. The S8 interface is applied for roaming
subscribers connected to their HPLMN. Depending on the configuration, the

18 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

SGSN-MME determines if the protocol GTP or PMIP is used between the

gateways.

For a roaming subscriber, if local breakout is allowed, the SGSN-MME selects a

PGW in the VPLMN. If the DNS procedure fails to locate a PGW for the APN, the
SGSN-MME selects a PGW in the HPLMN. For more information about the
optional feature Local Breakout Control, see APN Resolve and Redirect for LTE
Access.

3.6.2 DNS S-NAPTR Procedure for Combined PGW-Cs and SMFs

If the UE requests to establish a PDN connection to an APN, the MME determines
whether to select a combined PGW-C and SMF or a standalone PGW-C for the
UE in the following scenarios:
— For 4-5G interworking, the MME selects a combined PGW-C and SMF for a
UE if the UE supports N1 mode and has 5GS subscription from the HSS. The
N1 mode support indication of the UE is included in the UE Network
Capability IE.

— To prepare 5GC combined PGW-C and SMF nodes for 5GC network
deployment, the MME prioritizes to select a combined PGW-C and SMF node
for a UE that has 5GS subscription, regardless of the N1 mode capability.

Due to the flexible configuration in the MME per IMSI number series, the MME
provides four PGW selection strategies for LTE UEs, regardless of UE 5GS
subscription support or N1 capability. The four PGW selection strategies are as
followings:
— PGW only: Only select a standalone PGW

— SMF prioritized: Prioritize to select a combined PGW-C and SMF

— PGW prioritized: Prioritize to select a standalone PGW

— SMF ignored: Ignore the nc-smf service parameter in the gateway selection

In addition, the MME provides another strategy for the SGW relocation. In the
mobility with SGW relocation procedure, the MME only selects an SGW for the UE
and skips the SMF rule.

For the action configured to prioritize to select a combined PGW-C and SMF, the
MME prioritizes to select combined PGW-C and SMF nodes when establishing
PDN connections. The following two S-NAPTR procedures are performed:

— The S-NAPTR procedure is performed to retrieve the combined PGW-C and

SMF candidates by filtering candidates that include +nc-smf appended to
the protocol.

— The S-NAPTR procedure is performed to retrieve the PGW candidates by

filtering candidates that do not include +nc-smf appended to the protocol.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 19

 LTE Session Management

For more information about gateway selection order based on SMF rules, see
Gateway Selection Based on Service Parameters.

For more information about the S-NAPTR procedure, see DNS Description.

3.7 Sorting PGW Candidates

The DNS query with APN or other means of GW selection in the MME, such as
configured static PGW selection, results in a list of gateway candidates. The
gateways are listed using their FQDNs in the following format:

<"topon" | "topoff">.<single-label>.<canonical-node-name>

— <topon> indicates a topological structure. <topoff> indicates that a

topological structure is not used.

Note: If both the topon and topoff labels are missing in an FQDN, it is
assumed that a topological structure is not used (topoff).

— <single-label> indicates an interface on a node.

— <canonical-node-name> is the unique node name. Gateways with the same

canonical node name are colocated in the same node.

The sorting algorithm in the MME sorts the gateway candidates according the
following:

— If a configured static PGW exists, the MME sorts the candidate gateways
according to the gateway capacities.

— In IMSI-Based gateway selection procedure, the primary PGW is

preferentially selected and the secondary PGW is the backup for the primary
PGW. If the primary PGW cannot be reached, the secondary PGW is tried if it
is configured. If neither the primary nor the secondary PGW can be reached,
the PGW selection fails.

— If the SAPC provides a PGW list, the MME selects the gateway candidates
randomly.

— In PGW selection based on the DNS S-NAPTR procedure, the SGSN-MME

sorts the candidates using both Naming Authority Pointer (NAPTR) records
and Service (SRV) records. NAPTR and SRV records contain information
about the gateway addresses and their relative weight in the network. The
relative weight is related to load.

The SRV records from the DNS are sorted according to priority, lowest priority
first. Furthermore, each group of SRVs with equal priority is sorted according to
weight. For example, if record A has weight 20 and record B has weight 10,
record A is prioritized before B in 67% of the cases.

NAPTR records from the DNS are sorted according to order: lowest order first.
Also, each group of NAPTR records with the same order is sorted according to

20 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

weight, with the same algorithm as for SRVs. The difference is that the weight is
calculated out of the default base preference value of 65,535 in the algorithm.
For example, if record A has a preference value of 65,515 and record B has a
preference value of 65,525, the value 65,535 - 65,515 = 20 is used as relative
weight for A. The value 65,535 - 65,525 = 10 is used as relative weight for B. As a
result, A is prioritized before B in 67% of the cases.

Using the relative weight to sort the NAPTR and SRV records results in load
sharing between the supported PGWs.

3.7.1 Optional Function for Sorting the PGW with the GTP-C Load Information
The Gateway Selection with GTP-C Load Information function enables the MME
to select the PGW based on the GTP-C Load Control Information (LCI). This
function helps to achieve a balanced load network by using the dynamic load
information provided in the Load Control Information IE over the S11
interface.

Note: This feature is supported for the home subscribers and roaming
subscribers that are allowed by subscription data and local
configuration to use local breakout for all APNs. For the roaming users
with home routed traffic, the GTP-C Network Load Control function is
not applied.

This feature is activated based on local configuration per PLMN. For information
about the configuration of gateway selection based on the LCI, see Configuring
Session and Mobility Management.

When the Gateway Selection with GTP-C Load Information function is activated,
the MME takes into account the node level LCI received from the PDN GW in
addition to the weight factors received in the DNS S-NAPTR procedure to select
an appropriate PDN GW.

To ensure an efficient load control in the network, the MME updates the load
control information if the new received load metric has an increase or decrease
that is more than or equal to the configured value of
LoadControlInfoUpdateThreshold.

During the gateway selection procedure, the MME computes the dynamic weight
factor for the candidate gateways within the same order and priority in the SRV
records and uses the dynamic weight factor instead of the weight factor received
from the DNS server to sort the NAPTR and SRV records results in load sharing
among the supported PGWs. Considering the current available load and DNS
weight-factor of the target node as follows.

For NAPTR procedure, calculate the dynamic weight factor by the following
formula:

The dynamic weight factor = (100 – load-metric)% X (65535-NAPTR preference)

For SRV procedure, calculate the dynamic weight factor by the following formula:

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 21

 LTE Session Management

The dynamic weight factor = (100 – load-metric)% X SRV.weight

Note: If the load metric is not available, the MME considers the load metric as
0 for a candidate target node.

Example:

This assumes that the procedures specified in this document have 3 candidate
PGWs with the same relative order (e.g. with the same topological order) and the
following weights are received from the DNS and load metric reported via GTP-C
signalling:

— PGW1: DNS-weight-factor = 20, load-metric = 10%

— PGW2: DNS-weight-factor = 20, load-metric = 20%

— PGW3: DNS-weight-factor = 60, load-metric= 30%

Based on the formula above, the selecting node calculates the dynamic weight
factor for each candidate PGW:

— PGW1: dynamic weight factor= (100 – 10)% X 20 = 18

— PGW2: dynamic weight factor = (100 – 20)% X 20 = 16

— PGW3: dynamic weight factor = (100 – 30)% X 60 = 42

The MME supports the LCI IE in the below messages sent from the PGW:

— Create Session Response

— Create Bearer Request

— Modify Bearer Response

— Delete Bearer Request

— Delete Session Response

— Update Bearer Request

3.8 Retrieving SGWs from the IMSI-Based Gateway

Selection Profile
When the PGW candidates are selected, the SGSN-MME continues the procedure
with SGW selection. IMSI-based SGW selection enables operators to allocate
specified UEs to the specified SGW.

If the IMSI-Based Gateway Selection function is enabled and the following

configurations are performed, the SGSN-MME selects the SGW based on the
IMSI or IMSI number series:

22 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

— An IMSI-Based Gateway Selection profile is configured for the IMSI or the

IMSI number series.

— The primary SGW and optionally the secondary SGW are configured in the
profile.

IMSI-based SGW selection can be used for selecting the SGW for emergency UEs
if any IMSI exists.

Note: IMSI-based SGW selection is applicable for the S4-SGSN and the MME.

For information about how to configure IMSI-based SGW selection, see

Configuring IMSI-Based Gateway Selection.

The SGSN-MME continues the gateway selection procedure by sorting the PGW-
SGW pairs. For more details, see Sorting PGW-SGW Pairs on page 28.

For information about SGW selection during mobility procedures when IMSI-
based SGW selection is configured, see IMSI-Based Gateway Selection on page
39.

In cases of S11 path failure, SGW relocation can be triggered if the

gw_failure_restoration_lte or geo_redundant_pool parameter for the MME is set
to ACTIVATED. For information about procedures that can trigger SGW
relocation, see Gateway Restoration Procedures. During SGW relocation, the
SGSN-MME tries to reach a different SGW configured in the IMSI-Based
Gateway Selection profile when the selected SGW cannot be reached.

Note: The same rules apply in cases of S4 path failure if the

gw_failure_restoration_wcdma parameter for the S4-SGSN is set to
ACTIVATED.

When additional PDN connections are established using the PDN connectivity
procedure, the SGW is not changed.

3.9 Retrieving SGWs Based on IMSI Number Series and

Geographical Area
SGW Selection Based on IMSI Number Series and Geographical Area (GA)
enables the MME to select an appropriate SGW from the configured SGW
selection table.

The MME selects an SGW from the SGW table when the following configurations
are performed:

— The imsi_and_ga_based_sgw_selection parameter is set to on.

— A reference ID is configured and the ImsiGaBasedSgwSelection parameter is

enabled for the IMSI number series.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 23

 LTE Session Management

— In the SGW table, the SGW configuration entry with IMSINS reference ID list
is configured.

The MME uses the Tracking Area Identifier (TAI) and IMSI number series ID as
the input to find candidate SGWs from the static SGW selection table. When the
Dedicated Core Network feature and Gateway Selection for NR Usage feature,
are enabled, the MME uses UUT and NR Capability as the extra filter to select
SGW from the candidate SGWs. For more information about SGW selection using
UUT and NR Capability, see Dedicated Core Network and 5G EPC.

For information about how to configure the SGW selection based on IMSI
number series and Geographical Area, see Configure SGW Selection Based on
IMSI Number Series and Geographical Area for the MME.

3.10 Retrieving SGWs from Static SGW Selection Table

The static gateway selection function enables the SGSN-MME to select an
appropriate SGW from the configured gateway selection table.

The MME selects an SGW from the static SGW selection table when the following
configurations are performed:

— The static_gw_selection parameter is set to on.

— The SGW table is configured.

The MME uses the Tracking Area Identifier (TAI) as the input to find candidate
SGWs from the static SGW selection table. The MME selects the SGWs according
to the priorities or capacities configured in the static SGW selection table. If the
priority and capacity of an SGW are both configured, the MME selects the SGW
by the priority, and then by the capacity. For multiple SGWs have the same
priority, the MME selects the SGW randomly.

When the Dedicated Core Network feature and Gateway Selection for NR Usage
feature, are enabled, the MME uses UUT and NR Capability as the extra filter to
select SGW from the candidate SGWs For more information about SGW selection
using UUT and NR Capability, see Dedicated Core Network and 5G EPC.

For information about how to configure Static Gateway Selection, see

Configuring Static Gateway Selection in MME .

If the standalone PDN connectivity for the SGW candidates is already selected, at
additional PDN connections the current SGW is used as the only candidate.

The MME continues the gateway selection by using internal FQDNs based on the
configured SGW hostnames to sort the SGW candidates, see Sorting SGW
Candidates on page 27.

24 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

3.11 Retrieving SGWs Based on DNS Query with TAI

The MME determines the SGW candidates by a DNS query based on TAI through
a DNS S-NAPTR procedure. The DNS query uses the TAI that the MME receives
from the eNodeB to find the SGW candidates, see DNS S-NAPTR Procedure for
SGW on page 25. The S-NAPTR procedure results in a list of gateway
candidates based on FQDNs.

If the standalone PDN connectivity for the SGW candidates is already selected, at
additional PDN connections the current SGW is used as the only candidate.

The MME continues by sorting the SGW candidates, see Sorting SGW Candidates
on page 27.

3.11.1 DNS S-NAPTR Procedure for SGW

The MME performs a DNS S-NAPTR procedure using current TAI of the UE in a
DNS query to get a list of SGW candidates related to the S5/S8 interface.

The DNS query result is then filtered with an applicable subset of the services
required for the PDN connection. The services used depend on the applicable
interface and protocol, and are listed as follows:

— x-s5-gtp

— x-s5-pmip

— x-s8-gtp

— x-s8-pmip

When one, or both, of the two features Dedicated Core Network and Gateway
Selection for NR Usage are activated, multiple DNS S-NAPTR procedures are
performed with additional filtering.

When the Gateway Selection for NR Usage feature is activated and the UE is
allowed to use NR as secondary RAT, the following two S-NAPTR procedures are
performed.

— The S-NAPTR procedure is performed to retrieve the SGW candidates

supporting NR, for example, the filtering candidates include +nc-nr
appended to the protocol.

— The S-NAPTR procedure is performed to retrieve the SGW candidates not

supporting NR, for example, the filtering candidates do not include +nc-nr
appended to the protocol.

The SGW candidates are sorted as described in section 4.12.1. For more
information about the Gateway Selection for NR Usage feature, see 5G EPC.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 25

 LTE Session Management

When the Dedicated Core Network feature is activated, the following two S-
NAPTR procedures are performed.

— The S-NAPTR procedure is performed to retrieve the SGW candidates

dedicated to the specific UE Usage Type, for example, the filtering candidates
include +ue-N appended to the protocol.

— The S-NAPTR procedure is performed to retrieve the SGW candidates not

dedicated to any specific UE Usage Type, for example, the filtering
candidates do not include +ue-N appended to the protocol.

The SGW candidates are sorted as described in section 4.12.2. For more
information about the Dedicated Core Network feature, see Dedicated Core
Network.

Note: When both features are activated and the UE is allowed to use NR as a
secondary RAT, an additional S-NAPTR procedure is performed. This
procedure retrieves the SGW candidates supporting NR which are
dedicated to the specific UE Usage Type, for example, the filtering
candidates include both +nc-nr and +ue-N appended to the protocol.
These candidates have the highest priority when the PGW-SGW pairs
are sorted.

The services to be used are determined based on the protocol (GTP or PMIP) and
the interfaces used in the existing PDN connections. The interfaces that the SGW
candidates are required to support are determined based on the following cases:

The MME prefers an SGW supporting S5 interface in the following cases:

— For a home subscriber with only S5 PDN connections or no PDN connections.

— For a roaming subscriber with only S5 PDN connections or no PDN

connections, and the node function sgw_selection_based_on_all_apn_lbo is
active.

The MME prefers an SGW supporting both S5 and S8 in the following cases:
— For a home subscriber with at least one S8 PDN connection.

— For a roaming subscriber with at least one S8 PDN connection, or when the
node function sgw_selection_based_on_all_apn_lbo is not active.

If there is no SGW supporting S5 and S8 available, the MME prefers the following
cases:
— For home subscribers, the MME finds an SGW supporting S5 interface.

— For roaming subscribers, if the majority of the existing PDN connections are
using S8, the MME finds an SGW supporting S8 interface; otherwise, finds an
SGW supporting S5 interface.

For more information about the S-NAPTR procedure, see DNS Description.

26 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

3.12 Sorting SGW Candidates

The DNS query with TAI or other means of SGW selection in the MME, such as
configured static SGW selection, results in a list of gateway candidates. The
gateways are listed using their FQDN.

The sorting algorithm in the MME sorts the gateway candidates according the
following:

— In the IMSI-Based gateway selection procedure, the primary SGW is

preferentially selected and the secondary SGW is the backup for the primary
SGW. If the primary SGW cannot be reached, the secondary SGW is tried if it
is configured. If neither the primary nor the secondary SGW can be reached,
the SGW selection fails.

— If a configured static SGW exists, the MME sorts the candidate gateways
according to the gateway capacities and gateway priorities.

— In SGW selection based on the DNS query with TAI, the MME sorts the
candidates from the S-NAPTR procedure using both NAPTR records and SRV
records. NAPTR and SRV records contain information about the gateway
addresses and their relative weight in the network. The relative weight is
related to the load.

For information about SRV and NAPTR records sorting, see Sorting PGW
Candidates on page 20.

3.12.1 Optional Function for Sorting the SGW with the GTP-C Load Information
The Gateway Selection with GTP-C Load Information function enables the MME
to select the SGW based on the GTP-C LCI. This function helps to achieve a
balanced load network by using the dynamic load information provided in the
Load Control Information IE over the S11 interface.

Note: This feature is supported for home subscribers and roaming subscribers
whose subscription data and local configuration allow them to use local
breakout for all APNs. For roaming users with home routed traffic, the
GTP-C Network Load Control function is not applied.

This feature is activated based on the local configuration per PLMN. For
information about the configuration of gateway selection based on the LCI, see
Configuring Session and Mobility Management.

When the Gateway Selection with GTP-C Load Information function is activated,
the MME takes into account the node level LCI received from the SGW in addition
to the weight factors received in the DNS S-NAPTR procedure to select an
appropriate SGW.

To ensure an efficient load control in the network, the MME updates the load
control information if the new received load metric has an increase or decrease

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 27

 LTE Session Management

that is more than or equal to the configured value of

LoadControlInfoUpdateThreshold.

During the gateway selection procedure, the MME computes the dynamic weight
factor for the candidate gateways within the same order and priority in the SRV
records. The MME uses the dynamic weight factor instead of the weight factor
received from the DNS server to sort the NAPTR and SRV records results in the
load sharing among the supported SGWs. Considering the current available load
and DNS weight-factor of the target node as follows.

For the NAPTR procedure, the dynamic weight factor is calculated using the
following formula:

The dynamic weight factor = (100 – load-metric)% X (65535-NAPTR preference)

For the SRV procedure, the dynamic weight factor is calculated using the
following formula:

The dynamic weight factor = (100 – load-metric)% X SRV.weight

Note: If the load metric is not available, the MME considers the load metric as
0 for a candidate target node.

For an example of the dynamic weight factor for each candidate SGW, refer to
Optional Function for Sorting the PGW with the GTP-C Load Information on
page 21.

The MME supports the LCI IE in the below messages sent from the SGW:

— Create Session Response

— Create Bearer Request

— Modify Bearer Response

— Delete Bearer Request

— Delete Session Response

— Update Bearer Request

— Downlink Data Notification

— Release Access Bearers Response

— Modify Access Bearers Response

3.13 Sorting PGW-SGW Pairs

PGW-SGW pairs are sorted based on a sorted SGW candidate list and a PGW
candidate list. For more information about sorted SGW candidate lists and sorted

28 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

PGW candidate lists. For more information about sorted SGW candidate list and
sorted PGW candidate list, see Sorting SGW Candidates on page 27 and Sorting
PGW Candidates on page 20.

The MME builds all the possible gateway pairs by selecting SGWs from the sorted
SGW candidate list as the first node and then selecting PGWs from the sorted
PGW candidate list.

The following gateway pairs list shows all the possible gateway pairs based on a
sorted SGW candidate list with the SGW1 and the SGW2, and a sorted PGW
candidate list with the PGW1 and the PGW2:

— SGW1+PGW1

— SGW1+PGW2

— SGW2+PGW1

— SGW2+PGW2

When selecting gateways, the sgw_prioritized_gw_selection parameter controls

whether the MME gives top priority to the SGW order derived from either the DNS
query procedure or the gateway priority and capacity parameter from the static
SGW selection table.

If this parameter is set to off, the MME sorts the gateway pairs by the following
criteria in sequence as specified by 3GPP:

1. Colocation

Colocated gateway pairs have the highest priority. Gateways with the same
canonical node name are colocated in the same SGSN-MME, for example:

• topon.int.gw10.east.op.com + topon.pg.gw10.east.op.com

The MME analyzes the gateway names, and colocated gateway pairs are
allocated the highest priority.

Note: For static gateway selection, it is also possible to configure

colocated gateways in the PGW table using the GwType and
SgwName parameters. For information about the configuration of
static gateway selection, see Configuring Session and Mobility
Management.

2. Non-colocated gateway pairs with the topon label

If there are no more colocated gateway pairs, the MME considers non-
colocated gateway pairs with the topon label. Gateway pairs with the topon
label, for example, topon.int.gw10.east.op.com +
topon.pg.gw14.east.op.com, indicate the presence of a topological structure.

Non-colocated gateway pairs with the topon label are sorted by topological
closeness, which is indicated by the number of matching labels in the suffix

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 29

 LTE Session Management

of the canonical node name. A pair of SGW and PGW with more matching
labels in the suffix domain name is closer to each other than other gateway
pairs.

If two or more gateway pairs have the same SGW, they are arrayed in the
same order as the PGWs in the sorted PGW candidate list.

3. Non-colocated gateway pairs with at least one topoff label

If there are no more non-colocated gateway pairs with the topon label, the
MME considers non-colocated gateway pairs with at least one topoff label.

If two or more gateway pairs have the same SGW, they are arrayed in the
same order as the PGWs in the sorted PGW candidate list.

Note: — For static gateway selection, if there are no more colocated gateway
pairs, the MME considers non-colocated gateway pairs based on the
configured gateway priority and capacity. If two or more gateway
pairs have the same priority after sorting by the SGW order derived
according to the gateway priority and capacity, the MME sorts the
gateway pairs by the PGW order derived according to the gateway
capacities. The MME preferentially selects the gateway pair whose
PGW has a higher capacity. For more information about how the
MME sorts gateway candidates, see [unresolved external reference].

— Topological closeness and colocation are only applicable when the

SGW and PGW are located in the same PLMN. During a roaming
scenario, when the S8 interface is selected, colocation is not possible
because the SGW and PGW are located in different PLMNs.

— If a UE has PDN connections to multiple PGWs, the MME selects

new SGWs based on the PDN connection types. For more details,
see SGW Selection for UEs with Connections to Multiple PGWs on
page 40.

If the sgw_prioritized_gw_selection parameter is set to on, the sorting of

gateway pairs by colocation and topology is performed per SGW, not changing
the SGW order derived from either the DNS query procedure or the gateway
priority and capacity from static SGW selection table. The MME sorts gateway
pairs by the following criteria in sequence:

1. SGW order derived from either the DNS query procedure or the gateway
priority and capacity parameter from static SGW selection table.

The MME preferentially selects an SGW candidate with a higher priority

according to the SGW order derived from either the DNS query procedure or
the gateway priority and capacity parameter from the static SGW selection
table. If there are two or more PGW candidates, the MME sorts the gateway
pairs by the following criteria:

a. Colocation

30 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

The MME preferentially selects the PGW candidate that is colocated

with the SGW to form a pair.

Note: For static gateway selection, it is also possible to configure

colocated gateways in the PGW table using the GwType and
SgwName parameters. For information about the configuration
of static gateway selection, see Configuring Session and
Mobility Management.
b. Topological closeness

If no further PGW is colocated with the SGW, the MME preferentially

selects a PGW candidate with the topon label to pair with SGW. If there
are two or more PGW candidates with the topon label, the one with
more labels in common with the SGW is closer to the SGW and is
preferentially selected.

If two or more gateway pairs have the same priority after sorting by the
SGW order, they are arrayed in the same order as the PGWs in the sorted
PGW candidate list.

Note: — For static gateway selection, if there are no more colocated gateway
pairs, the MME considers non-colocated gateway pairs based on the
configured gateway priority and capacity. If two or more gateway
pairs have the same priority after sorting by the SGW order derived
according to the gateway priority and capacity, the MME sorts the
gateway pairs by the PGW order derived according to the gateway
capacities. The MME preferentially selects the gateway pair whose
PGW has a higher capacity. For more information about how the
MME sorts gateway candidates, see [unresolved external reference].

— Topological closeness and colocation are only applicable when the

SGW and the PGW are located in the same PLMN. During a roaming
scenario, when the S8 interface is selected, colocation is not possible
because the SGW and the PGW are located in different PLMNs.

For details about how to enable SGW-Prioritized Gateway Selection, see

Configuring Session and Mobility Management.

3.13.1 Sorting Gateway Pairs Based on NR Capability

If the Gateway Selection for NR Usage feature is activated, the MME sorts the
gateway pairs based on the NR capability. Gateway pairs supporting NR are
either prioritized or deprioritized based on the UE capability and other related
factors.

For more information, see 5G EPC.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 31

 LTE Session Management

3.13.2 Sorting Gateway Pairs Based on the UE Usage Type

If the Dedicated Core Network feature is activated, the MME sorts the gateway
pairs based on the UUT. Gateway pairs supporting a specific UUT are prioritized
over pairs that do not support any specific UUT.

For more information, see Dedicated Core Network.

3.13.3 Sorting Gateway Pairs Based on the Blacklisting Status

If the Gateway Blacklisting feature is enabled, the SGSN-MME sorts the SGWs
again according to their status. For more information, see Gateway Blacklisting.

3.13.4 Example of Sorting SGW-PGW Pairs in the 3GPP Sequence

In this example, there are four SGW candidates and two PGW candidates.

The following is the list of SGW candidates in descending order or priority:

1. topoff.int.gw1.east.op.com

2. topon.int.gw2.east.op.com

3. topon.int.gw3.west.op.com

4. topoff.int.gw4.west.op.com

The following is the list of PGW candidates in descending order of priority:

1. topon.pg.gw1.east.op.com

2. topon.pg.gw2.east.op.com

The following are all possible gateway pair combinations:

1. topoff.int.gw1.east.op.com + topon.pg.gw1.east.op.com

2. topoff.int.gw1.east.op.com + topon.pg.gw2.east.op.com

3. topon.int.gw2.east.op.com + topon.pg.gw1.east.op.com

4. topon.int.gw2.east.op.com + topon.pg.gw2.east.op.com

5. topon.int.gw3.east.op.com + topon.pg.gw1.east.op.com

6. topon.int.gw3.east.op.com + topon.pg.gw2.east.op.com

7. topoff.int.gw4.east.op.com + topon.pg.gw1.east.op.com

8. topoff.int.gw4.east.op.com + topon.pg.gw2.east.op.com

32 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

If the sgw_prioritized_gw_selection parameter is set to off, the gateway

pairs are sorted using the following logic:

1. Colocated gateway pairs are prioritized over non-colocated gateway pairs.

2. Among the non-colocated gateways, gateway pairs with the topon label are
prioritized over gateway pairs with at least one topoff label.

3. Topological closeness is applied between the gateway pairs to determine

priority. The gateway topon.int.gw2.east.op.com is prioritized over
topon.int.gw3.west.op.com because it is topologically closer to both the PGW
candidates topon.pg.gw1.east.op.com and topon.pg.gw2.east.op.com.

4. DNS priority is then used to determine the order among gateway pairs with
the same priority. For example, among the gateway pairs in steps 4 and 5,
and the gateway pairs in steps 6, 7, and 8 in the list of gateway pairs in the
following list.

The gateway pairs are sorted as follows:

1. topoff.int.gw1.east.op.com + topon.pg.gw1.east.op.com (colocated gateway

pair)

2. topon.int.gw2.east.op.com + topon.pg.gw2.east.op.com (colocated gateway

pair)

3. topon.int.gw2.east.op.com + topon.pg.gw1.east.op.com (non-colocated

gateway pair with the topon label with three matching labels)

4. topon.int.gw3.west.op.com + topon.pg.gw1.east.op.com (non-colocated

gateway pair with the topon label with two matching labels)

5. topon.int.gw3.west.op.com + topon.pg.gw2.east.op.com (non-colocated

gateway pair with the topon label with two matching labels)

6. topoff.int.gw1.east.op.com + topon.pg.gw2.east.op.com (non-colocated

gateway pair with the topoff label)

7. topoff.int.gw4.west.op.com + topon.pg.gw1.east.op.com (non-colocated

gateway pair with the topoff label)

8. topoff.int.gw4.west.op.com + topon.pg.gw2.east.op.com (non-colocated

gateway pair with the topoff label)

3.13.5 Example of Sorting Gateway Pairs in the SGW-Prioritized Sequence

In this example, there are two SGW candidates and two PGW candidates.

The following is the list of SGW candidates in descending order of priority:

1. topon.int.gw14.east.op.com

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 33

 LTE Session Management

2. topon.int.gw10.east.op.com

The following is the list of PGW candidates in descending order of priority:

1. topon.pg.gw19.west.op.com

2. topon.pg.gw10.east.op.com

The following are all possible gateway pair combinations:

1. topon.int.gw14.east.op.com + topon.pg.gw19.west.op.com

2. topon.int.gw14.east.op.com + topon.pg.gw10.east.op.com

3. topon.int.gw10.east.op.com + topon.pg.gw19.west.op.com

4. topon.int.gw10.east.op.com + topon.pg.gw10.east.op.com

If the sgw_prioritized_gw_selection parameter is set to on, the MME sorts the

gateway pairs in the SGW-prioritized sequence as follows:

1. topon.int.gw14.east.op.com + topon.pg.gw10.east.op.com (SGW order and

topological closeness)

2. topon.int.gw14.east.op.com + topon.pg.gw19.west.op.com (SGW order)

3. topon.int.gw10.east.op.com + topon.pg.gw10.east.op.com (colocated

gateway pair)

4. topon.int.gw10.east.op.com + topon.pg.gw19.west.op.com

In contrast, if the sgw_prioritized_gw_selection parameter is set to off, the MME

sorts the gateway pairs in the sequence specified by 3GPP as follows:

1. topon.int.gw10.east.op.com + topon.pg.gw10.east.op.com (colocated

gateway pair)

2. topon.int.gw14.east.op.com + topon.pg.gw10.east.op.com (non-colocated

gateway pair with the topon label with three matching labels)

3. topon.int.gw14.east.op.com + topon.pg.gw19.west.op.com (non-colocated

gateway pair with the topon label with two matching labels, SGW order)

4. topon.int.gw10.east.op.com + topon.pg.gw19.west.op.com

3.14 Retrieving IP Addresses

The SGW hostname retrieved in the first DNS query with TAI using the S-NAPTR
procedure relates to the S5 and S8 interfaces. Optionally, the NAPTR query
response can also include information about the S11 and the S4 interfaces. If the

34 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PGW and SGW Selection during PDN Connectivity Procedures

hostname related to the S11 interface is not provided in the response, the SGSN-
MME performs an S-NAPTR procedure using the canonical node name of the
SGW and the following filter:

— x-3gpp-sgw:x-s11

The MME uses the FQDNs of the gateway pair to retrieve IP for the SGW and the
PGW.

To retrieve the SGW IP, if only IPv4 or IPv6 is configured for the S11 interface,
the MME sends a type A or a type AAAA query to the DNS. If both IPv4 and IPv6
are configured for the S11 interface, the MME sends both type A and type AAAA
queries to the DNS.

If the MME receives both an IPv4 and an IPv6 address for the SGW, the IPv6 is
prioritized over the IPv4 address. Thus if the MME supports IPv6, the MME uses
the received IPv6 address to set up a PDN connection.

To retrieve the PGW IP, the MME sends both type A and type AAAA queries to the
DNS.

If the MME receives both an IPv4 and an IPv6 address for the PGW, the MME
includes both addresses in the request for a PDN connection sent to the SGW.

If an SGW does not support the same IP version as the MME, all gateway pairs
that include that SGW are discarded from the list and the MME retrieves the IP
addresses of the next gateway pair in the list.

For an example and more detailed information about the DNS procedures to find
the SGW and the PGW, see DNS Description.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 35

 LTE Session Management

4 Gateway Pair Fallback

If a PDN connection setup fails because of the selected gateway pair, the MME
does the following to try to establish a PDN connection:

1. The MME discards the problematic gateway pairs from the gateway pair
candidate list as follows:
• If the MME does not receive a response from the SGW, the MME discards
the gateway pairs containing that SGW from the candidate list and
proceeds with .

• If the MME receives a rejection from the SGW or the PGW, the MME
discards the gateway pairs containing the rejecting gateway from the
candidate list.

The SGW or the PGW rejects a PDN connection setup attempt by the
MME with a GTPV2 cause code indicating a particular node-related
problem. The MME only proceeds with when the PDN connection setup
attempt is rejected with one of the GTPV2 cause codes configured
through the GwPairFallbackCauseList parameter. The following cause
codes are allowed for this parameter:
— 72: System Failure

— 73: No Resources available

— 78: Missing or unknown APN

— 83: Preferred PDN type not supported

— 84: All dynamic addresses are occupied

— 86: Protocol type not supported

— 91: No memory available

— 94: Request Rejected (Reason not specified)

— 100: Remote peer not responding

— 113: APN Congestion

— 120: GTP-C Entity Congestion

Note: The default value of this parameter is

72,73,78,83,84,86,91,100,113,120.

For more information on this parameter, see GTPv2 (CLI).

36 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Gateway Pair Fallback

For information on how to configure this parameter, see Configuring

Session and Mobility Management.

2. The MME selects the next gateway pair in the gateway pair candidate list.

3. The MME tries to establish a PDN connection with the newly selected
gateway pair.

Note: The MME limits the fallback attempts to the value specified by the
GwMaxAttemptNumber parameter minus 1 . When the limit is reached,
the MME considers the PDN connection setup to have failed.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 37

 LTE Session Management

5 Specific Gateway Selection during Mobility

Procedures

During mobility procedures, the SGW selection procedure can be triggered to find
the candidate SGW list. If the old SGW is included in this candidate list, the old
SGW continues to serve the UE. A new SGW is selected if the old SGW is not able
to serve the UE. During mobility procedures, the PGW is not changed.

SGW selection or reselection is triggered during mobility in the following

procedures:

— TAU procedures. For more information, see LTE Mobility Management and
Inter-System Mobility Management.

— S1- and X2-Based Handover procedures. For more information, see LTE
Mobility Management.

— IRAT PS Handover procedures between LTE and WCDMA. For more

information, see Inter-System Mobility Management.

— Handover from non-3GPP networks to LTE. For more information, see Inter-
System Mobility Management.

Note: SGW selection is also performed during the PDN connectivity procedure
for UEs in EMM-REGISTERED without PDN Connection.

The SGW selection or reselection procedure for finding the SGW candidates is
performed as follows:

1. If IMSI-based SGW selection is configured, the MME selects an SGW based

on the IMSI-Based Gateway Selection Profile. For more information, see
Retrieving SGWs from the IMSI-Based Gateway Selection Profile on page
22. If no IMSI-Based Selection Profile is available, the MME selects an SGW
based on IMSI number series and geographical area. For more information,
see Retrieving SGWs Based on IMSI Number Series and Geographical Area
on page 23.

2. If static SGW selection is configured, the MME selects an SGW from the SGW
selection table. For more information, see Retrieving SGWs from Static SGW
Selection Table on page 24.

3. If neither IMSI-based SGW selection nor static SGW selection is configured,

the MME determines the SGW candidates by a DNS query with TAI. For more
information, see Retrieving SGWs Based on DNS Query with TAI on page 25.

38 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Specific Gateway Selection during Mobility Procedures

5.1 IMSI-Based Gateway Selection

If IMSI-based SGW selection is used, the SGSN-MME checks whether the
configured primary or secondary SGW is the same as the old SGW during
interSGSN-MME and inter-System mobility procedures.

If the configured primary or secondary SGW is the same as the old SGW, the
same SGW is selected. If neither the primary SGW nor the secondary SGW is the
same as the old SGW, the SGW is changed to the primary SGW, or to the
secondary SGW if this SGW is configured when the primary SGW cannot be
reached.

If an SGW is selected for a UE by using IMSI-Based Gateway Selection, the

SGSN-MME does not perform SGW reselection during intra-SGSN-MME mobility
procedures unless SGW relocation is triggered when gw_failure_restoration_lte,
geo_redundant_pool, or gw_failure_restoration_wcdma are set to activated.

5.2 PGW Selection during Handover from Non-3GPP

Networks to LTE
During the handover from non-3GPP networks to LTE procedure, the Update
Location Answer message received from the HSS includes the PGW identity.
The PGW identity can be one either the FQDN or the IP address, or both.

Note: For a wildcard APN, the MME fetches the PGW identity from the
Specific-APN-Info IE. For other APNs, the MME fetches the PGW
identity from the MIP6-Agent-Info IE.

For non-roaming authenticated UE handover of emergency bearer

services from non-3GPP access, the MME fetches the emergency PGW
identity from the Emergency-Info IE.

Table 1 shows how the MME selects a PGW based on the PGW identity. For more
information, see PGW and SGW Selection during PDN Connectivity Procedures
on page 12.

Table 1 PGW Selection Based on PGW Identity

PGW Identity PGW Selection
FQDN The MME performs a DNS query using the FQDN
to get the PGW IP address.
IP address The MME uses the IP address for the PGW
without performing a DNS query.
FQDN and IP address The MME first performs a DNS query using the
FQDN to get the PGW IP address. If no PGW is
selected by using the FQDN, the MME uses the IP
address for the PGW.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 39

 LTE Session Management

5.3 SGW Selection for UEs with Connections to Multiple

PGWs
If a UE has PDN connections to multiple PGWs and the
sgw_prioritized_gw_selection parameter is set to off, the MME sorts and selects
SGWs as follows:

1. If there is an EMC PDN connection, the SGW with the highest priority toward
EMC PDN PGW is selected.

2. If no EMC PDN connection exists, or all SGWs have the same priority toward
the EMC PDN PGW and an IMS PDN connection exists, the SGW with the
highest priority toward the IMS PDN PGW is selected.

3. If no EMC PDN connection or IMS PDN connection exists, or all SGWs have
the same priority toward the EMC PDN PGWs and IMS PDN PGWs
respectively, then the SGWs are prioritized toward all non-EMC and non-IMS
PDN PGWs in the following manner:

a. If there are SGWs that are colocated with non-EMC PDN PGWs and
non-IMS PDN PGWs, the colocated SGWs are prioritized by the number
of PDN connections supported by the PGW. The SGW colocated with the
PGW supporting the most PDN connections is prioritized over other
SGWs.
b. If there are non-colocated SGWs for which topology applies, the SGWs
are prioritized by their topological closeness to the PGWs.
c. If there are gateway pairs that are non-colocated, or if topology does
not apply, or some SGWs still have the same priority after colocation and
topological sorting, the SGW order derived from the DNS query
procedure is used to sort the SGWs.

If the sgw_prioritized_gw_selection parameter is set to on, the MME sorts and

selects SGWs first by the SGW order derived from the DNS query procedure, and
then by Gateway Blacklisting, if any.

5.3.1 Example with an Existing EMC PDN Connection

Table 2 Active APNs with an EMC APN

Active APNs Current PGW FQDN
Internet APN topon.pgw.a.northwest.west.op.com
WAP APN topon.pgw.b.southwest.west.op.com
EMC APN topon.pgw.east.op.com

40 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Specific Gateway Selection during Mobility Procedures

Table 3 SGW Candidates with Assigned Priority Values

EMC Priority
SGW Candidate List Colocated Matching Matching Labels SGW Selected
Label in the Node
Name
topon.sgw.northwest.west No 2 op.com Selected at second
.op.com attempt (if the first SGW
on the list is not
available)
topon.sgw.b.east.op.com No 3 east.op.com Selected at first attempt

5.3.2 Example without an Existing EMC or IMS PDN Connection

Table 4 Active APNs without an EMC or IMS APN

Active APNs Current PGW FQDN
Internet APN topon.pgw.a.northwest.west.op.com
WAP APN topon.pgw.b.southwest.west.op.com

Table 5 SGW Candidates with Assigned Priority Values

All-PDN Priority
EMC APN IMS APN Colocatio Number Matching
SGW Candidate List Exists Exists n of Labels in the SGW Selected
Matching Node Name
Labels
topon.sgw.northw No No No 4 northwest.wes Selected at first
est.west.op.com t.op.com attempt
topon.sgw.b.east.o No No No 2 op.com Selected at
p.com second attempt
(if the first SGW
on the list is not
available)

5.3.3 Example without an EMC or IMS PDN Connection

Table 6 Active APNs without an EMC or IMS APN

Active APNs Current PGW FQDN
Internet APN
topoff.pgw.northwest.west.op.com
WAP APN
Data APN topoff.pgw.east.op.com

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 41

 LTE Session Management

Table 7 SGW Candidates with Assigned Priority Values

Colocation Based on All PDNs
EMC APN IMS APN Colocatio Colocated Number
SGW Candidate List Exists Exists n PGW of PDN SGW Selected
Connectio
ns
topoff.sgw.northw No No Yes topoff.pgw.n 2 Selected at first
est.west.op.com orthwest.we attempt
st.op.com
topoff.sgw.east.op. No No Yes topoff.pgw.e 1 Selected at second
com ast.op.com attempt (if the first
SGW on the list is
not available)

5.4 PGW Reselection

When a UE with specified APNs moves to a new MME in another region within
one PLMN, the new MME can reselect a PGW to ensure the service quality, and
for charging purposes. PGW reselection can be performed after the MME
completes any of the following mobility procedures:

— Inter-MME TAU

— Inter-MME Handover

— Gn/Gp-SGSN to MME TAU

— IRAT Handover from WCDMA to LTE over Gn

— MME moves

— UE Restoration using the Geographically Redundant Pool feature

— 5GS to EPS TAU or Handover

PGW reselection can be enabled using the pgw_reselection parameter for the
PDNs configured in the APN list. For information about how to configure the
PGW Reselection function, see Configuring Session and Mobility Management.

Note: PGW reselection is not supported during a smooth pool move.

For IMS Emergency Service, PGW reselection is not performed.

For each PDN in the specified APNs, the new MME compares the PGW used in
the old area with the PGW candidates list result of the Gateway Selection
function in the new MME area based on the FQDN or the IP address. The
comparison type depends on the information that the new MME receives from
the old Gn/Gp-SGSN or the old MME, and on the information that the new MME
receives based on the Gateway Selection function.

The new MME performs the comparison in the following way:

42 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Specific Gateway Selection during Mobility Procedures

— FQDN comparison is always preferred when the FQDN is available, even if

the currently used IP address is also received from the old side. The FQDN is
either received from the old side or derived from the initial IP address in the
Ericsson private extension from the old Gn/Gp SGSN by DNS query.

— IP address comparison is performed when only the currently used IP address

is available from the old Gn/Gp-SGSN or the old MME, and the
pgw_reselection_with_ip_comparison function is enabled.

The result of the comparison can be either of the following:

— If the PGW used in the old area does not match any member of the PGW
candidates list, PGW reselection is performed. The PGW used in the old area
for the PDN is indicated by its FQDN or IP address. For information about the
Gateway Selection function, see PGW and SGW Selection during PDN
Connectivity Procedures on page 12.

— If the PGW used in the old area matches one member of the PGW candidates
list, and there are PGWs with different priorities created according to the
configuration of one of the following rules, the MME also checks the
pgw_reselection_for_prioritized_one node function to decide whether
to reselect a prioritized PGW:
— The SMF rule is configured as smf_prioritized or pgw_prioritized.

— The NR rule is configured as nr_prioritizednr_prioritized_homo or

non_nr_prioritized.

— The UUT rule is configured as uut_prioritized.

If the node function is set to its default value on, the MME reselects a
prioritized PGW. If the node function is set to off, the PDN established in the
less prioritized PGW is not deactivated. This triggers fewer PDN
deactivations and activations, and minimizes session interruptions.

If the Gateway Selection for NR Usage feature is enabled, the new MME takes
into account the NR network capability when constructing the PGW candidates
list. For example. based on the NR rule configuration, the new MME can reselect
an NR-capable PGW when the PGW in use does not support NR and there is at
least one NR-capable PGW in the PGW candidates list. For more information, see
5G EPC.

If the Dedicated Core Network feature is enabled, the new MME takes into
account the UUT rule when constructing the PGW candidates list. For example,
based on the UUT rule configuration, the new MME can reselect a PGW that
supports the currently used UUT of the UE. For more information, see Dedicated
Core Network.

If the Advanced 4G/5G Interworking feature is enabled, the new MME takes into
account the SMF network capability when constructing the PGW candidates list.
For example, based on the SMF rule configuration, the new MME can reselect a
combined PGW-C and SMF. For more information, see Advanced 4G/5G
Interworking.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 43

 LTE Session Management

If PGW reselection is needed, the new MME performs the following actions:

— If there is a bearer with QCI=1 in the PDN, which is assumed to be a voice

bearer, the MME marks the PDN connection with to be deactivated. When
the voice call ends and the voice bearer is deactivated, the MME deactivates
the PDN connection with the cause code reactivation requested.

— If there is no bearer with QCI=1 in the PDN, the MME immediately

deactivates the PDN connection with the cause code reactivation
requested.

For a UE not supporting EMM-REGISTERED without PDN Connection, if all the

PDN connections of the UE are to be deactivated, the MME directly detaches the
UE with the detach type re-attach required, instead of deactivating each PDN
connection one by one.

The MME then reselects a PGW for the PDNs when the UE reactivates the PDN
connections or reattaches to the network.

44 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PDN Disconnection

6 PDN Disconnection

A PDN connection is deactivated through the PDN Disconnection procedure.

For a UE supporting EMM-REGISTERED without PDN Connection, the UE stays

in the EMM-REGISTERED state after the deactivation of the last PDN
connection.

6.1 UE- or MME-Initiated PDN Disconnection

The UE- or MME-Initiated PDN Disconnection procedure allows the UE or the
MME to initiate a disconnection from a PDN. During the disconnection procedure,
both the default bearer and the dedicated bearers of the PDN are deleted.

When the MME initiates a PDN disconnection from the last PDN connection, the
MME-initiated Detach procedure is performed if the UE does not support EMM-
REGISTERED without PDN Connection. For more information about this, see LTE
Mobility Management.

For a UE not supporting EMM-REGISTERED without PDN Connection, when the

UE requests a PDN disconnection from the last PDN connection, the request is
rejected by the MME. The UE is not allowed to send a PDN Disconnection
Request message from the last PDN connection. Instead, the Detach message is
used.

For a UE supporting EMM-REGISTERED without PDN Connection, the UE is

allowed to send a PDN Disconnection Request message from the last PDN
connection, and the UE stays in the EMM-REGISTERED state when the last PDN
connection is removed.

If an attached UE is disconnected from all PDN connections except for the

emergency PDN connection, the UE becomes emergency-attached.

6.1.1 Traffic Case

The UE- or MME-initiated PDN Disconnection procedure is shown in Figure 4.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 45

 LTE Session Management

UE eNodeB MME SGW PGW

1. PDN Disconnect Request

2. Delete Session Request

3. Delete Session Response

4.1 E-RAB Release Command (Deactivate EPS Bearer Context Request)

4.2 RRC Connection Reconfiguration (Deactivate EPS Bearer Context Request)

4.3 RRC Connection Reconfiguration Complete

4.4 E-RAB Release Response

4.5 Deactivate EPS Bearer Context Accept

4.1 Downlink NAS Transport

(Deactivate EPS Bearer Context Request)

4.2 Uplink NAS Transport

(Deactivate EPS Bearer Context Accept)

Figure 4 UE- or MME-Initiated PDN Disconnection

The following steps describe the PDN Disconnection procedure:

1. If the disconnection is initiated by the UE, the UE initiates the procedure by

sending a PDN Disconnect Request message to the MME. The message
contains information about which default bearer is associated with the PDN
connection being disconnected.

If the PDN indicated in a PDN Disconnect Request message is a PDN

connection to the SCEF, the MME disconnects this PDN connection. For more
information, see Non-IP Data Delivery over SCEF.

2. The MME sends a Delete Session Request message to the PGW through
the SGW. This message contains information about the default bearer that
belongs to the PDN connection that is to be deleted.

If the NR Usage Data Reporting feature is activated and if the the UE is NR-
capable and not restricted from using NR, step 2 is executed after step 4 to
allow the MME to include the reports described in step 4.4 in the Delete
Session Request message.

3. The PGW acknowledges the request by sending a Delete Session

Response message to the MME through the SGW, and informs the PCRF if it
is applied in the network.

46 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PDN Disconnection

is skipped when the UE is in the ECM-IDLE state. The PDN connection

information is synchronized between the UE and the network at the next
ECM-IDLE to ECM-CONNECTED transition in for example the Service
Request or the TAU procedure.

4. The subsequent procedure depends on whether the UE uses DoNAS.

If the UE does not use DoNAS, the following procedure is performed:

1. The MME initiates the deactivation of all bearers associated with the PDN
connection to the eNodeB by sending the E-RAB Release Command
message to the eNodeB. This message contains the Deactivate EPS
Bearer Context Request message for the default bearer. In this step,
the MME recalculates the UE-AMBR and provides it in the message to the
eNodeB. For more information about how the AMBR is calculated, see
AMBR on page 3.

A timer supervises the response of the Deactivate EPS Bearer

Context Request message. If the timer expires, the Deactivate EPS
Bearer Context Request message is resent. If no answer is received
after four retransmissions, the bearer is marked as failed in the MME, but
is still deactivated.

2. The eNodeB releases the corresponding bearers and sends the

Deactivate EPS Bearer Context Request message to the UE in an
RRC Connection Reconfiguration message.

3. The UE releases all resources corresponding to the PDN connection and

acknowledges this by sending the RRC Connection Reconfiguration
Complete message to the eNodeB.

4. The eNodeB sends an E-RAB Release Response message to the MME to

acknowledge the release. The eNodeB can include the Secondary RAT
Usage Report list IE.

5. The UE sends a Deactivate EPS Bearer Context Accept message

containing the identity of the deactivated default bearer through the
eNodeB to the MME.

If the UE uses DoNAS, the following procedure is performed:

1. The MME sends a Downlink NAS Transport message to the UE. The
Downlink NAS Transport message contains the Deactivate EPS
Bearer Context Request message.

2. The UE responds to the MME with an Uplink NAS Transport message.

The Uplink NAS Transport message contains the Deactivate EPS
Bearer Context Accept message.

6.2 PGW-Initiated PDN Disconnection

The PGW-initiated PDN Disconnection procedure is performed when the network
requests disconnection of a PDN connection, provided the connection is not the

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 47

 LTE Session Management

last one. When the last PDN connection is to be removed, the MME-Initiated
Detach procedure is executed if the UE does not support EMM-REGISTERED
without PDN Connection. For more information, see LTE Mobility Management.

If an attached UE is disconnected from all PDN connections except for the

emergency PDN connection, the UE becomes emergency-attached.

6.2.1 Traffic Case

The PGW-Initiated PDN Disconnection procedure is shown in Figure 5.

UE eNodeB MME SGW PGW

1. Delete Bearer Request

2. Paging

3 a. E-RAB Release Command

(Deactivate EPS Bearer Context Request)

3 b. RRC Connection Reconfiguration

(Deactivate EPS Bearer Context Request)

3 c. RRC Connection Reconfiguration Complete

3 d. E-RAB Release Response

3 e. Deactivate EPS Bearer Context Accept

3 a. Downlink NAS Transport

(Deactivate EPS Bearer Context Request)

3 b. Uplink NAS Transport

(Deactivate EPS Bearer Context Accept)

4. Delete Bearer Response

Figure 5 PGW-Initiated PDN Disconnection Procedure

The following steps describe the PGW-Initiated PDN Disconnection procedure:

1. The PDN Disconnection procedure is initiated by the PCRF through the PGW.
The PGW sends the Delete Bearer Request message through the SGW to
the MME to deactivate the selected PDN connection identified by the LBI.
When the last PDN connection that belongs to a UE is released, and the UE
does not support EMM-REGISTERED without PDN Connection, the MME
starts an MME-Initiated Detach procedure without signaling the SGW. For
more information, see LTE Mobility Management.

48 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 PDN Disconnection

If the Delete Bearer Request message from the PGW does not include
reactivation requested, and the UE is in the ECM-IDLE state, and are
skipped.

2. If the UE is in the ECM-IDLE state, and the Delete Bearer Request

message from the PGW includes reactivation requested, the MME
initiates the Paging procedure. This procedure moves the UE to the ECM-
CONNECTED state.

3. The subsequent procedure depends on whether the UE uses DoNAS.

If the UE does not use DoNAS, the following procedure is performed:

a. The MME initiates the deactivation of all bearers associated with the
PDN connection to the eNodeB by sending the E-RAB Release
Command message to the eNodeB. This message contains the
Deactivate EPS Bearer Context Request message for the
default bearer. In this step, the MME recalculates the UE-AMBR and
provides it in the message to the eNodeB. For more information
about how the AMBR is calculated, see AMBR on page 3.

If the Delete Bearer Request message received from the SGW

includes GTPv2 cause code 'PDN reconnection to this APN
disallowed', the Deactivate EPS Bearer Context Request
message includes the ESM Cause IE. This is set according to the
value of the CcDeactBearerReqByPgwInitPdnDisc parameter.

If the Delete Bearer Request message received from the SGW

includes the cause code reactivation requested, the Deactivate
EPS Bearer Context Request message includes the ESM Cause IE
which is set to reactivation requested.

A timer is started to supervise the setup of the Deactivate EPS

Bearer Context Request message. If the timer expires, the
Deactivate EPS Bearer Context Request message is resent. If
no answer is received after four retransmissions, the bearer is marked
as failed in the MME, but is still deactivated.
b. The eNodeB releases the corresponding bearers, and sends an RRC
Connection Reconfiguration message containing the Deactivate
EPS Bearer Context Request message to the UE.

c. The UE releases the bearers, and acknowledges this by sending the

RRC Connection Reconfiguration Complete message to the
eNodeB.
d. The eNodeB sends an E-RAB Release Response message to the
MME as an acknowledgment of the deactivation. If the NR Usage
Data Reporting feature is activated, the Secondary RAT usage
report list IE can be included if a bearer using NR is deleted.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 49

 LTE Session Management

e. The UE sends a Deactivate EPS Bearer Context Accept

message, containing the identity of the deactivated bearer to the
MME through the eNodeB.

If the UE uses DoNAS, the following procedure is performed:

a. The MME sends a Downlink NAS Transport message to the UE. The
Downlink NAS Transport message contains the Deactivate EPS
Bearer Context Request message.

b. The UE responds to the MME with an Uplink NAS Transport

message. The Uplink NAS Transport message contains the
Deactivate EPS Bearer Context Accept message.

4. The MME deletes the bearer context related to the deactivated EPS bearer,
and acknowledges the bearer deactivation to the PGW by sending a Delete
Bearer Response message containing the default Bearer Identity. The
message is sent through the SGW to the PGW.

The MME can include the Secondary RAT usage data report IE, if
received in step 3.4.

50 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 HSS-Based P-CSCF Restoration

7 HSS-Based P-CSCF Restoration

The HSS-Based P-CSCF Restoration function triggers a UE initial registration by

a terminating call upon P-CSCF system failure or service interruption. The
function provides a quick mechanism for the UE to regain services on a per-user
and per-terminating-request basis.

The HSS-Based P-CSCF Restoration function is applicable for UEs with an IMS
PDN connection. For information about IMS PDN connections, see IMS APN
Identification on page 4.

When the MME receives the Insert Subscriber Data Request message from
the HSS indicating P-CSCF Restoration, the MME checks if the HSS-based P-
CSCF Restoration function is enabled. The subsequent MME behavior is based on
the configuration of the HssBasedPcscfRestoration parameter.

7.1 Basic Mechanism

If the HssBasedPcscfRestoration parameter is set to basic, the MME performs
the following actions:

— If the UE is in the ECM-CONNECTED state, the MME deactivates the IMS

PDN connection to the UE with the NAS cause code reactivation
requested, and deletes the PDN toward the SGW or the PGW. If the IMS
PDN is the last PDN, the MME directly detaches the UE with the detach type
re-attach required.

— If the UE is in the ECM-IDLE state, the MME pages the UE and performs the
preceding operation when the UE becomes ECM_CONNECTED.

If the MME fails to notify the UE of the IMS PDN deactivation with
reactivation requested, the MME keeps the IMS PDN instead of deleting
it. The kept IMS PDN is deactivated with reactivation requested at the
next UE activity, or the next P-CSCF Restoration with successful paging. As a
result, the PDN disconnection or detach is triggered.

When the UE reactivates the IMS PDN or reattaches to the network, the UE
selects a new P-CSCF.

7.2 Optional Extension

If the HssBasedPcscfRestoration parameter is set to optionalS5, and the UE
has an IMS PDN connected to the PGW over the S5 interface, the MME sends the
Modify Bearer Request message indicating P-CSCF Restoration to the PGW
through the SGW.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 51

 LTE Session Management

Note: If the UE is in the ECM-IDLE state, the MME first pages the UE. In this
case, the P-CSCF Restoration indication is sent in the Modify Bearer
Request message during the Paging Response procedure.

— If the UE indicates P-CSCF Restoration Supported to the PGW, the PGW

initiates the Bearer Modification procedure by sending the Update Bearer
Request message to the MME. The Update Bearer Request message
includes a list of available P-CSCF addresses in the PCO IE.

For information about the PGW-Initiated Bearer Modification procedure, see

Modification of Bearers on page 65.

When the UE receives the Modify EPS Bearer Context Request message
from the MME with a list of available P-CSCF addresses in the PCO IE, the
UE selects an available P-CSCF from the list and performs a new initial IMS
registration.

— If the UE does not indicate P-CSCF Restoration Supported to the PGW,

the PGW initiates the PDN Disconnection procedure with reactivation
requested to the MME.

For information about the PGW-Initiated PDN Disconnection procedure, see

PGW-Initiated PDN Disconnection on page 47.

After the IMS PDN is released, the UE selects a new P-CSCF when the UE
reactivates the IMS PDN or reattaches to the network.

If the HssBasedPcscfRestoration parameter is set to optionalS5, and the UE

has an IMS PDN connected to the PGW over the S8 interface, the MME performs
a fallback to the basic mechanism.

7.2.1 Limitation
The optional extension function requires support in the S-CSCF and the HSS and
has the following additional limitations:

— Optional extension is only applicable for UE IMS PDNs connected to the

PGW over the S5 interface.

— If the MME is configured to support optional extension, all SGWs connected

to the MME and all PGWs connected over the S5 interface must support
optional extension.

52 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Activation of Dedicated Bearers

8 Activation of Dedicated Bearers

A default bearer is established during the Attach or Standalone PDN Connectivity

procedure. During the procedure, the UE is given an IP address and packet data
resources to communicate with a PDN. Any additional bearer that is established
for the same PDN connection is referred to as a dedicated bearer. Dedicated
bearers are activated and deactivated depending on the service used. The
network decides if dedicated bearers need to be set up and what QoS settings
must be applied for the dedicated bearer in question.

The possibility to establish dedicated bearers is provided by a licensed feature.

The MME checks for a valid license each time a Create Bearer Request
message is received from the PGW. If the feature license is not activated, only a
default bearer can be established. For more information about the licensed
feature, see Features and Functions Management.

8.1 PGW-Initiated Activation of Dedicated Bearers

8.1.1 Traffic Case

The Activation of Dedicated Bearers procedure is shown in Figure 6 and
described as follows:

UE eNodeB MME SGW PGW

1. Create Bearer Request

2. Paging and Service Request Procedures

3. E-RAB Setup Request / Activate Dedicated EPS Bearer Context Request

4. RRC Connection Reconfiguration / Activate Dedicated EPS Bearer Context Request

5. RRC Connection Reconfiguration Complete

6. E-RAB Setup Response

7. Activate Dedicated EPS Bearer Context Accept

8. Create Bearer Response

Figure 6 Activation of Dedicated Bearers

The following steps describe the Activation of Dedicated Bearers procedure:

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 53

 LTE Session Management

1. The Activation of Dedicated Bearers procedure is initiated by the PCRF

through the PGW. The PGW sends the Create Bearer Request message
through the SGW to the MME to activate the selected dedicated bearers.
MME supports multiple bearer setup in the same Create Bearer Request
message.

If the maximum number of bearers per UE is exceeded, the request is

rejected with cause code SYSTEM_FAILURE. The maximum limit of allowed
bearers per UE is configured using the MaxBearersPerUe parameter.

2. If the UE is in the ECM-IDLE state, the MME initiates the Paging procedure
which is followed by the Service Request procedure. These procedures are
further described in LTE Mobility Management.

3. The MME selects an EPS Bearer Identity and sends an E-RAB Setup
Request message containing the EPS Bearer Identity to the eNodeB. The E-
RAB Setup Request message contains one Activate Dedicated EPS
Bearer Context Request message for each bearer to be set up.

A timer is started to supervise the response of the Activate Dedicated EPS

Bearer Context Request message. If the timer expires, the Activate
Dedicated EPS Bearer Context Request message is resent. If no
response is received after four retransmissions, the bearer is marked as failed
in the MME.

4. The eNodeB sends an RRC Connection Reconfiguration message

containing the Activate Dedicated EPS Bearer Context Request
message that includes the EPS Bearer Identity.

5. The UE answers by sending an RRC Connection Reconfiguration

Complete message to the eNodeB.

6. The eNodeB acknowledges the bearer activation by sending the MME an E-

RAB Setup Response message, which contains the EPS Bearer Identity,
TEID, and the address of the eNodeB used for the user plane traffic.

7. The UE sends the Activate Dedicated EPS Bearer Context Accept

message which contains the identity of the bearer to the MME through the
eNodeB.

8. Upon reception of the E-RAB Setup Response message in and one

Activate Dedicated EPS Bearer Context Accept message for each
bearer in , the MME acknowledges the bearer activation by sending a Create
Bearer Response message to the PGW through the SGW.

8.2 Dedicated Bearer Activation in Combination with the

Default Bearer Activation
The PGW can initiate activation of dedicated bearers during the Attach and PDN
Connectivity procedures. When this is done, the SGW piggybacks the Create

54 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Activation of Dedicated Bearers

Bearer Request message to the Create Session Response message. The

SGW only sends piggybacked messages to the SGSN-MME if the flag for
Piggybacking Supported is set in the Create Session Request message sent
from the MME to the SGW.

The following flows only describe the parts related to dedicated bearer
activation. The complete Attach procedure flow is described in LTE Mobility
Management. The complete PDN Connectivity procedure flow is described in
Traffic Case on page 7.

UE eNodeB MME SGW PGW

1. Create Session Response

(Create Bearer Request)

2. Initial Context Setup Request (containing:

Attach Accept (Activate Default EPS Bearer Context Request
Activate Dedicated EPS Bearer Context Request)

3. Initial Context Setup Response

4. Attach Complete (Activate Default EPS Bearer Context Accept)

5. Activate Dedicated EPS Bearer Context Accept

6. Create Bearer Response

(Modify Bearer Request)

7. Create Bearer Response

8. Modify Bearer Response

Figure 7 Dedicated Bearer Activation During the Attach Procedure

1. The SGW sends the Create Bearer Request message piggybacked to the
Create Session Response message, after initiation from the PGW.

If the maximum number of bearers per UE is exceeded, the request is

rejected with the cause code SYSTEM_FAILURE. The maximum limit of
allowed bearers per UE is configured using the MaxBearersPerUe parameter.

2. The MME sends the Initial Context Setup Request message, including
the Activate Default EPS Bearer Context Request message and the
Activate Dedicated EPS Bearer Context Request message, to the
eNodeB which forwards it to the UE.

3. The eNodeB sends the Initial Context Setup Response message to the
MME, as in the normal Attach procedure.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 55

 LTE Session Management

4. The UE sends the Attach Complete message, including the Activate

Default EPS Bearer Context Accept message, to the MME through the
eNodeB, as in the normal Attach procedure.

5. The UE sends the Activate Dedicated EPS Bearer Context Accept

message, which contains the identity of the bearer, to the MME through the
eNodeB.

6. The MME sends the Create Bearer Response message with the Modify
Bearer Request message piggybacked to it.

7. The SGW sends the Create Bearer Response message to the PGW.

8. The SGW sends the Modify Bearer Response message to the MME.

56 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Deactivation of Dedicated Bearers

9 Deactivation of Dedicated Bearers

Dedicated bearers are activated and deactivated depending on the service used.
The network decides whether dedicated bearers need to be deactivated.

9.1 PGW-Initiated Deactivation of Dedicated Bearers

This section describes the PGW-initiated Deactivation of Dedicated Bearers
procedure.

Note: If the dedicated bearer is with QCI =1, and the PDN connection is
marked as to be reactivated because of PGW reselection, the MME
initiates the PDN deactivation with the cause code reactivation
requested, instead of deactivating the dedicated bearer.

9.1.1 Traffic Case

The PGW-initiated Deactivation of Dedicated Bearers procedure is shown in
Figure 8 and described as follows:

UE eNodeB MME SGW PGW

1. Delete Bearer Request

2. Paging

3. E-RAB Release Command / Deactivate EPS Bearer Context Request

4. RRC Connection Reconfiguration / Deactivate EPS Bearer Context Request

5. RRC Connection Reconfiguration Complete

6. E-RAB Release Response

7. Deactivate EPS Bearer Context Accept

8. Delete Bearer Response

Figure 8 PGW-Initiated Deactivation of Dedicated Bearers

The following steps describe the PGW-initiated deactivation of dedicated

bearers:

1. The Deactivation of Dedicated Bearers procedure is initiated by the PCRF

through the PGW. The PGW sends the Delete Bearer Request message
through the SGW to the MME to deactivate the selected dedicated bearers.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 57

 LTE Session Management

If the Delete Bearer Request message from the PGW does not include
reactivation requested, and the UE is in the ECM-IDLE state, to are
skipped.

2. If the UE is in the ECM-IDLE state, and the Delete Bearer Request

message from the PGW includes reactivation requested, the MME
initiates the Paging procedure. This procedure moves the UE to the ECM-
CONNECTED state. For more information, see LTE Mobility Management.

3. The MME initiates the deactivation of bearers by sending the E-RAB

Release Command message to the eNodeB. This message contains one
Deactivate EPS Bearer Context Request message. As a result, if there
are additional bearers that must be deactivated, one Downlink NAS
transport message containing the Deactivate EPS Bearer Context
Request message is sent for each of these bearers.

A timer is started to supervise the response of the Deactivate EPS Bearer

Context Request message. If the timer expires, the Deactivate EPS
Bearer Context Request message is resent. If no answer is received after
four retransmissions, the bearer is marked as failed in the MME, but is still
deactivated.

4. The eNodeB releases the corresponding bearers and sends an RRC

Connection Reconfiguration message containing the Deactivate EPS
Bearer Context Request message to the UE.

5. The UE releases the bearers and acknowledges this by sending the RRC
Connection Reconfiguration Complete message to the eNodeB.

6. The eNodeB sends an E-RAB Release Response message to the MME to

acknowledge the release.

If the NR Usage Data Reporting feature is activated, the Secondary RAT

usage report list IE can be included if data is received.

7. The UE sends a Deactivate EPS Bearer Context Accept message

containing the identity of the deactivated bearer, through the eNodeB to the
MME. One Deactivate EPS Bearer Context Accept message is sent for
each deactivated bearer.

8. The MME deletes the bearer context related to the deactivated EPS bearer,
and acknowledges the bearer deactivation by sending a Delete Bearer
Response message containing the EPS bearer identities to the PGW through
the SGW.

The MME can include the Secondary RAT usage data report IE, if
received in step 6.

58 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Deactivation of Dedicated Bearers

9.2 MME-Initiated Deactivation of Dedicated Bearers

The MME-initiated Deactivation of Dedicated Bearers procedure is triggered by
the following actions:

— A release request, that is an E-RAB Release Indication message, is received

from the eNodeB.

— The target eNodeB could not set up all dedicated bearers during the S1-
Based Handover procedure.

— The target eNodeB has not setup all dedicated bearers during the X2-Based
Handover procedure.

— The eNodeB could not set up all dedicated bearers during the Service
Request procedure.

— A failure message is received from the SGW during the Service Request
procedure.

— A bearer mismatch occurs in the EPS Bearer Status IE in the TAU procedure.

— The conversion between the PDP contexts and the EPS Bearers fail.

In addition, the following actions apply specifically to GBR-dedicated

bearers:

— E-UTRAN requests an S1 release owing to a cause other than user inactivity,

such as, a lost radio connection with the UE.

— No response is received from the UE for the Paging Request.

— If the active EPS GBR bearers with 0 MBR are received from an old SGSN in
an inter-system change procedure.

— A bearer modification failed in the E-RAB Modification Indication procedure.

The Handover, TAU, and Service Request procedures are described in LTE
Mobility Management.

The mapping between PDP contexts and EPS Bearers is described in Inter-
System Mobility Management.

9.2.1 Timer-Based Deactivation of GBR Bearers

For a GBR bearer, if the MME receives the UE Context Release Request
message from the eNodeB with an S1AP cause code, which is configured in the
MME by the S1RelCauseDelayGbrBearerDeact parameter, the MME preserves the
GBR bearers based on configuration of the S1TimerGbrBearerDeactivation timer.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 59

 LTE Session Management

If a UE returns to the network before the S1TimerGbrBearerDeactivation timer

expires, the MME does not deactivate the GBR bearers. This prevents bearer
reestablishment.

When the timer expires, the MME handles the GBR bearers according to the
following:

— If there is no ongoing paging for the UE, the MME initiates deactivation of
the GBR bearers.

— If there is ongoing paging for the UE, the MME keeps the GBR bearers if the
paging is successful, and deletes the GBR bearers if the paging fails.

The return of UEs is triggered by Service Requests, TAU requests, Context

Requests, or SGSN Context Requests.

For information about how to configure the S1TimerGbrBearerDeactivation

timer, see Configuring Session and Mobility Management.

Any of the following S1AP cause codes can be configured for Timer-Based
Deactivation of GBR Bearers:

— RADIO_CONNECTION_WITH_UE_LOST

— All Radio Network Layer category-related cause codes except the normal
S1AP cause codes that are described in the following list

— All cause codes except the normal S1AP cause codes that are described in
the following list

The following five cause codes are considered as normal S1AP cause codes, and
are not applicable for Timer-Based Deactivation of GBR Bearers:

— USER_INACTIVITY

— INTER_RAT_REDIRECTION

— CS_FALLBACK_TRIGGERED

— UE_NOT_AVAILABLE_FOR_PS_SERVICE

— REDIRECTION_TOWARDS_1XRTT

For example, when RADIO_CONNECTION_WITH_UE_LOST is configured for Timer-

Based Deactivation of GBR Bearers, the MME starts the
S1TimerGbrBearerDeactivation timer when the MME receives the UE Context
Release Request message with the RADIO_CONNECTION_WITH_UE_LOST cause
code. While the timer is running, if the UE returns to the radio coverage and sends
the Service Request or the TAU Request message and the message is received
by the MME, the timer is stopped and the E-RAB is set up for the preserved GBR
bearer. The ebm_para_statistics.pl toolbox script can show the percentage of

60 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Deactivation of Dedicated Bearers

UEs reconnecting to the network within the specified time period with preserved
bearers. For more information about the toolbox script, see Toolbox Description.

When receiving the Downlink Data Notification message during the running
of the timer, the MME behaves differently.

— When the PageUeDDNTimerBasedGbrDeact parameter is set to

defaultbearer, either of the following occurs:

• If the EPS bearer identities in the Downlink Data Notification

message contain default bearers, the MME stops the timer and starts the
Paging procedure.

• If all the bearers indicated by the EPS bearer identities in the Downlink
Data Notification message are dedicated bearers or the message
does not contain any EPS bearer identity, the MME keeps the timer
running and does not start the Paging procedure.

— When the PageUeDDNTimerBasedGbrDeact parameter is set to allbearers,

the MME stops the timer and starts the Paging, regardless of whether the
downlink payload is from the default bearer or the dedicated bearer.

9.2.2 Traffic Case

The MME-initiated Deactivation of Dedicated Bearers procedure is initiated by
the MME sending the Delete Bearer Command message to the PGW through the
SGW.

eNodeB MME SGW PGW

1. E-RAB Release
Indication
2. Delete Bearer
Command
3. Delete Bearer
Command

4. Delete Bearer
Request
5. Delete Bearer
Request

6. Delete Bearer
Response
7. Delete Bearer
Response

compulsory communication
conditional or optional communication

Figure 9 MME-Initiated Deactivation of Dedicated Bearers

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 61

 LTE Session Management

1. The eNodeB sends an E-RAB Release Indication message to the MME.

Note: For more information on triggers, see MME-Initiated Deactivation of

Dedicated Bearers on page 59.

2. The MME sends a Delete Bearer Command message per PDN connection to
the SGW to deactivate the selected dedicated bearers.

3. The SGW sends a Delete Bearer Command message per PDN connection to
the PGW.

4. The PGW sends a Delete Bearer Request message to the SGW to

deactivate the selected dedicated bearers.

5. The SGW forwards this Delete Bearer Request message to the MME.

6. The MME deletes the bearer context related to the deactivated PDN
connection, and acknowledges the deactivation by sending a Delete
Bearer Response message containing the EPS bearer identities to the PGW
through the SGW.

7. The SGW deletes the bearer context related to the deactivated PDN
connection, and acknowledges the deactivation by sending a Delete
Bearer Response message containing the EPS bearer identities to the PGW.

9.2.3 Traffic Case with NR Usage Data Reporting

The MME-initiated Deactivation of Dedicated Bearers procedure with NR Usage
Data Reporting activated, is shown in Figure 10 and described as follows:

62 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Deactivation of Dedicated Bearers

UE eNodeB MME SGW PGW

Radio Bearer Release

1. E-RAB Release
Indication
2. Delete Bearer
Command
3. Delete Bearer
Command

4. Delete Bearer
Request
5. Delete Bearer
Request

6. Delete Bearer
Response
7. Delete Bearer
Response

compulsory communication
conditional or optional communication

Figure 10 MME-Initiated Deactivation of Dedicated Bearers with NR Usage

Data Procedure

1. The eNodeB sends an E-RAB Release Indication message to the MME.

If the NR Usage Data Reporting feature is activated, the Secondary RAT

usage report list IE can be included if data is received.

Note: For more information on triggers, see MME-Initiated Deactivation of

Dedicated Bearers on page 59.

2. The MME sends a Delete Bearer Command message per PDN connection to
the SGW to deactivate the selected dedicated bearers.

The Secondary RAT usage data IE is included if received from the eNodeB.

3. The SGW sends a Delete Bearer Command message per PDN connection to
the PGW. The SGW includes the Secondary RAT usage data IE in this
message if it was received in the previous message and if the PGW is the
intended receiver.

4. The PGW sends a Delete Bearer Request message to the SGW to

deactivate the selected dedicated bearers.

5. The SGW forwards this Delete Bearer Request message to the MME.

6. The MME deletes the bearer context related to the deactivated PDN
connection, and acknowledges the deactivation by sending a Delete
Bearer Response message containing the EPS bearer identities to the PGW
through the SGW.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 63

 LTE Session Management

7. The SGW deletes the bearer context related to the deactivated PDN
connection, and acknowledges the deactivation by sending a Delete
Bearer Response message containing the EPS bearer identities to the PGW.

64 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Modification of Bearers

10 Modification of Bearers

The network decides whether dedicated bearers need to be modified. Since the
APN-AMBR can be changed because of the PGW-initiated Bearer Modification
procedure, the UE-AMBR can also need to be changed. The UE-AMBR is set by
the MME to the sum of the APN-AMBR of all active APNs up to the value of the
subscribed UE-AMBR.

10.1 PGW-Initiated Bearer Modification without Bearer QoS

Update
The PGW-initiated Bearer Modification without Bearer QoS Update procedure is
used to update the TFT for an active default or dedicated bearer, or to modify the
APN-AMBR. The TFT and the AMBR is further described in AMBR on page 3, and
Bearer TFT on page 3.

Figure 11 shows the two possible traffic cases to follow depending on whether
the UE is in the ECM-IDLE or the ECM-CONNECTED state.

10.1.1 Traffic Case

The PGW-initiated Bearer Modification without Bearer QoS Update procedure is
shown in Figure 11 and described as follows:

UE eNodeB MME SGW PGW

1. Update Bearer Request

2. Paging and Service Request Procedures

3. UE Context Modification Request

4. UE Context Modification Response

5. Modify EPS Bearer Context Request

6. Modify EPS Bearer Context Accept

7. Update Bearer Response

Figure 11 PGW-Initiated Modification of Dedicated or Default Bearers

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 65

 LTE Session Management

The following steps describe the PGW-initiated modification of dedicated or

default bearers:

1. The modification of dedicated or default bearers is initiated by the PCRF

through the PGW. The PGW generates the TFT and sends the Update
Bearer Request message containing the EPS Bearer Identity, the APN-
AMBR, and the TFT to the MME through the SGW. The Update Bearer
Request can contain several updated bearers.

2. If the UE is in ECM-IDLE state, the MME initiates the Paging procedure,

followed by the Service Request procedure. These procedures are further
described inLTE Mobility Management.

If the UE is in ECM-CONNECTED state, continue to .

3. If the UE-AMBR is changed, the MME sends the UE Context Modification

Request message containing the UE-AMBR to the eNodeB.

4. The eNodeB responds with the UE Context Modification Response

message.

5. The MME sends a Modify EPS Bearer Context Request message, which
contains the EPS Bearer ID, the TFT, and the APN-AMBR, to the UE through
the eNodeB. This step is repeated for each bearer to be modified.

6. The UE responds to the MME with a Modify EPS Bearer Context Accept
message, which contains the EPS Bearer ID, through the eNodeB to the
MME. This step is repeated for each bearer to be modified.

7. Upon reception of the Modify EPS Bearer Context Accept message, the
MME acknowledges the bearer modification by sending the PGW an Update
Bearer Response message containing the EPS Bearer ID through the SGW.
The PGW can also inform the PCRF of the bearer modification.

10.2 PGW-Initiated Bearer Modification with Bearer QoS

Update
The PGW-Initiated Bearer Modification with Bearer QoS Update procedure is
used to modify the bearer level QoS parameters or TFT for an active default or
dedicated bearer. It is also used to modify the APN-AMBR. The bearer level QoS
parameters, the AMBR, and the TFT are further described in QoS at Bearer Level
on page 2, AMBR on page 3, and Bearer TFT on page 3 respectively.

10.2.1 Traffic Case

Figure 12 shows two possible traffic cases when the UE is in the ECM-
CONNECTED or the ECM-IDLE state.

The PGW-initiated Bearer Modification with Bearer QoS Update procedure is

shown in Figure 12 and described as follows:

66 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Modification of Bearers

UE eNodeB MME SGW PGW

1. Update Bearer Request

2. Paging and Service Request Procedures

3. E-RAB Modify Request /

Modify EPS Bearer Context Request

4. RRC Connection Reconfiguration /

Modify EPS Bearer Context Request

5. RRC Connection Reconfiguration Complete

6. E-RAB Modify Response

7. Direct Transfer /
Modify EPS Bearer Context Accept
8. Uplink NAS Transport /
Modify EPS Bearer Context Accept

9. Update Bearer Response

Figure 12 PGW-Initiated Modification of Dedicated or Default Bearers with QoS

Update

1. The modification of dedicated or default bearers is initiated by the PCRF

through the PGW. The PGW generates the TFT and updates the bearer level
QoS. The PGW sends the Update Bearer Request message containing the
EPS Bearer Identity, the bearer level QoS, the APN-AMBR, and the TFT to
the MME through the SGW.

Note: If the UE is in the ECM-IDLE state and only the ARP is modified in
the Update Bearer Request message, the UE and eNodeB are not be
notified, the MME sends the Update Bearer Response message to
the SGW directly.

2. If the UE is in the ECM-IDLE state, the MME initiates the Paging procedure
followed by the Service Request procedure, where the MME uses the old QoS.
These procedures are further described in LTE Mobility Management.

3. The MME sends the E-RAB Modify Request message to the eNodeB
containing the EPS Bearer Identity, the bearer level QoS, Modify EPS
Bearer Context Request message, and the UE-AMBR, if it is changed. The
Modify EPS Bearer Context Request message contains the EPS Bearer
Identity, the bearer level QoS, the APN-AMBR, and the TFT.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 67

 LTE Session Management

A timer is started to supervise the setup of the Modify EPS Bearer

Context Request message. If the timer expires, the Modify EPS Bearer
Context Request message is resent. If no answer is received after four
retransmissions, the bearer is marked failed in the MME.

4. The eNodeB maps the modified bearer level QoS to the Radio Bearer QoS. It
sends an RRC Connection Reconfiguration message containing the
Radio Bearer QoS, the Modify EPS Bearer Context Request, and the EPS
Bearer Identity to the UE.

5. The UE acknowledges the radio bearer modification to the eNodeB with an

RRC Connection Reconfiguration Complete message.

6. The eNodeB acknowledges the bearer modification to the MME with an E-

RAB Modify Response message. With this message, the eNodeB indicates
whether the requested bearer level QoS could be allocated or not.

7. The UE sends a Direct Transfer message containing the Modify EPS Bearer
Context Accept message to the eNodeB. The Modify EPS Bearer
Context Accept message includes the EPS Bearer Identity.

8. The eNodeB sends an Uplink NAS Transport message including the

Modify EPS Bearer Context Accept message to the MME. With this
message, the eNodeB and UE indicate the requested bearer level QoS could
be allocated.

9. Upon reception of the E-RAB Modify Response message in and the Uplink
NAS Transport message in , the MME acknowledges the bearer modification
to the SGW by sending an Update Bearer Response message. The SGW
forwards this message to the PGW that informs the PCRF.

10.3 HSS-Initiated Subscribed QoS Modification

The subscription data contains QoS profile, RAT/Frequency Selection Priority
(RFSP), APN-AMBR, and UE-AMBR information. Any QoS-related data change in
the subscription data can result in QoS modifications of the active PDN
connections.

10.3.1 HSS-Initiated Subscribed UE-AMBR Modification

The MME supports HSS-initiated subscriber QoS modifications with UE-AMBR
being modified. The UE-AMBR is further described in AMBR on page 3

10.3.1.1 Traffic Case

The HSS-initiated Subscribed QoS Modification procedure is shown in Figure 13

and described as follows. The traffic case applies to UEs in either the ECM-IDLE
or the ECM-CONNECTED state.

68 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Modification of Bearers

UE eNodeB MME SGW PGW HSS

1. Insert Subscriber Data

2. Insert Subscriber Data Ack

3. UE Context Modification Request

4. UE Context Modification Response

Figure 13 HSS-Initiated Subscribed UE-AMBR Modification

The following steps describe the HSS-initiated Subscribed UE-AMBR

Modification procedure:

1. The HSS sends an Insert Subscriber Data Request message to the

MME. The message contains the modified subscription data.

2. The MME stores the updated subscription data and sends an Insert
Subscriber Data Answer message to the HSS. If the subscribed UE-AMBR
is modified, the MME calculates a new UE-AMBR value.

If the UE is in the ECM-IDLE state, the new UE-AMBR is stored for later use.

3. If the UE is in the ECM-CONNECED state and the newly calculated UE-

AMBR is changed compared to the previous value, the MME signals the
modified UE-AMBR value to the eNodeB by sending a UE Context
Modification Request message to the eNodeB.

Note: If the subscribed RFSP is changed for the home subscriber, the new
RFSP is sent to the eNodeB within the same UE Context
Modification Request message.

4. The eNodeB responds with the UE Context Modification Response

message to the MME.

10.3.2 HSS-Initiated Subscribed APN-AMBR or Bearer Level QoS Modification

The MME supports HSS-initiated subscribed APN-AMBR or bearer level QoS
modifications, or both. The subscribed UE-AMBR and RFSP can be updated
together or individually. The following case is valid only when there is a related
active PDN connection with the modified QoS profile or APN-AMBR, and the
SendMbcAtHssQosMod parameter is set to on.

If the subscribed QoS profile changes in the MME when the UE is suspended
during the CSFB procedure, the HSS-initiated Subscribed APN-AMBR or Bearer
Level QoS Modification procedure is performed after the UE returns to the E-
UTRAN and resumes.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 69

 LTE Session Management

10.3.2.1 Traffic Case

The HSS-initiated Subscribed APN-AMBR or Bearer Level QoS Modification

procedure is shown in Figure 14 and described as follows. The traffic case applies
to UEs in either the ECM-IDLE or the ECM-CONNECTED state.

UE eNodeB MME SGW PGW HSS

1. Insert Subscriber Data Request

2. Insert Subscriber Data Answer

3. Modify Bearer Command

4. Update Bearer Request

5. Paging and Service Request Procedures

6. Bearer Modification with QoS Update Procedure

Figure 14 HSS-Initiated Subscribed APN-AMBR or Bearer Level QoS

Modification

The following steps describe the HSS-initiated Subscribed APN-AMBR or Bearer

Level QoS Modification procedure:

1. If the APN-AMBR or bearer level QoS in the HSS is modified, the HSS sends
an Insert Subscriber Data Request message to the MME. This message
contains the modified APN-AMBR or bearer level QoS.

2. The MME sends an Insert Subscriber Data Answer message to the HSS.

3. The MME sends a Modify Bearer Command message for each PDN
connection to the PGW through the SGW. This message includes the APN-
AMBR and bearer level QoS.

4. The PGW sends the Update Bearer Request message containing the APN-
AMBR or bearer level QoS to the MME through the SGW.

5. If the UE is in the ECM-IDLE state, the MME initiates the Paging procedure
followed by the Service Request procedure which is further described in LTE
Mobility Management.

70 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Modification of Bearers

6. The MME continues the bearer modification with the QoS update procedure,
which is described in Traffic Case on page 66.

10.4 QoS Modification in IRAT Mobility

The QoS Modification in IRAT Mobility procedure can be triggered by the IRAT
TAU from GSM or WCDMA to LTE and the IRAT Handover from WCDMA to LTE
procedures if one of the following conditions is met:

— The SendMbcAtIratMobility parameter is set to on by using the

modify_imsins CLI command. No PGW-initiated bearer QoS modification is
performed before the TAU procedure is completed.

— The SendMbcAtIratMobility parameter is set to unconditionally by

using the modify_imsins CLI command.

The IRAT TAU from GSM or WCDMA to LTE and IRAT Handover from WCDMA to
LTE procedures are described in Inter-System Mobility Management.

Additionally, the QoS modification can also be triggered by inter-MME TAU and
inter-MME handover from an MME not supporting NR to an MME supporting NR
if all of the following conditions are met:

— The SendMbcAtIratMobility parameter is set to on or unconditionally by

using the modify_imsins.

— The length of the Extended Access Restriction is not received from the old
MME and the value of the APN-AMBR in use is less than 4.29G.

— The value of the APN-AMBR contained in the Extended-Max-Requested-

BW-UL IE or the Extended-Max-Requested-BW-DL IE received from the HSS
and the local policies allow bit rates higher than 4.29G.

10.4.1 Traffic Case

The QoS Modification in IRAT Mobility procedure is shown in Figure 15 and
described as follows. The traffic case applies to UEs in either the ECM-IDLE or
the ECM-CONNECTED state.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 71

 LTE Session Management

UE eNodeB MME SGW PGW HSS

TAU Procedure

1. Modify Bearer Command

2. Update Bearer Request

3. Paging and Service Request Procedures

4. Bearer Modification with QoS Update Procedure

Figure 15 QoS Modification in IRAT Mobility

The following steps describe the QoS Modification in IRAT Mobility procedure:

1. The MME sends a Modify Bearer Command message for each PDN
connection to the PGW through the SGW. This message includes the updated
QoS information.

2. The PGW sends the Update Bearer Request message containing the APN-
AMBR and bearer level QoS to the MME through the SGW.

3. If the UE is in the ECM-IDLE state, the MME initiates the Paging procedure
followed by the Service Request procedure which is further described in LTE
Mobility Management.

4. The MME continues the bearer modification with QoS update procedure,
which is described in Traffic Case on page 66.

10.5 Establishing an S11-U Connection for Data over NAS

Before enabling DoNAS, create the IP service for S11-GTP-U. For instructions on
creating an IP service, see Configuring IP-Based Interfaces. For more information
about the licensed feature Data over NAS, see Massive IoT.

If the UE and the MME use DoNAS, the MME establishes a GTP-U tunnel to
transfer the user data between the MME and the SGW over the S11-U interface.

The MME establishes a GTP-U tunnel by including an S11-GTP-U F-TEID either

in the Create Session Request or in the Modify Bearer Request message
sent to the SGW.

72 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Modification of Bearers

However, if the S11USupportInGW parameter is set to off, the MME tunnels the
user data over the S11-U interface in an S1-U eNodeB F-TEID IE instead. The
MME then includes an S1-GTP-U F-TEID in the Modify Bearer Request
message sent to the SGW.

The SGW acknowledges the request by including an SGW GTP-U F-TEID either
in the Create Session Response or in the Modify Bearer Response message
sent to the MME.

10.6 E-UTRAN Initiated E-RAB Modification Procedure

The E-RAB Modification Indication procedure is triggered by a master eNodeB
and transfers bearer contexts to and from a secondary gNodeB.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 73

 LTE Session Management

11 UE Requested Bearer Resource Modification

The UE Requested Bearer Resource Modification procedure is shown in Figure 16

and described as follows:

UE eNodeB MME SGW PGW

1. Bearer Resource Modification Request

2. Bearer Resource Command

3. Bearer Resource Command

4. The PGW initicates one of the following procedures:

Procedure 1 PGW-Initiated Deactivation of Dedicated Bearers
Procedure 2 PGW-Initiated Bearer Modification with Bearer QoS Update
Procedure 3 PGW-Initiated Bearer Modification without Bearer QoS Update
Procedure 4 PGW-Initiated Activation of Dedicated Bearers

compulsory communication
optional communication

Figure 16 UE Requested Bearer Resource Modification procedure

1. The UE sends an Request Bearer Resource Modification message to

the MME.

2. After receiving the Request Bearer Resource Modification message

from the UE, the MME sends a Bearer Resource Command message to the
SGW.

3. After receiving the Bearer Resource Command message from the MME, the
SGW sends a Bearer Resource Command message to the PGW.

4. The PGW initiates one of the following procedures:

— Procedure 1: Deactivation of Dedicated Bearers

— Procedure 2: Bearer Modification with Bearer QoS Update

— Procedure 3: Bearer Modification without Bearer QoS Update

— Procedure 4: Activation of Dedicated Bearers

For Procedure 1, see the section PGW-Initiated Deactivation of Dedicated

Bearers on page 57.

74 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 UE Requested Bearer Resource Modification

For Procedure 2, see the section PGW-Initiated Bearer Modification with Bearer
QoS Update on page 66.

For Procedure 3, see the section PGW-Initiated Bearer Modification without

Bearer QoS Update on page 65.

For Procedure 4, see the section PGW-Initiated Activation of Dedicated Bearers

on page 53.

Note: — This procedure only supports the Bearer Resource Modification for
S1-U PDN connection.

— For the Update Bearer and Create Bearer procedures triggered by

the UE-Initiated Bearer Resource Modification Request
message, the Update Bearer Request message or the Create
Bearer Request message sent by the PGW is not allowed to
downgrade the MBR or GBR.

For the Update Bearer procedure triggered by the UE-Initiated

Bearer Resource Modification Request message, QCI changed
for bearer is not allowed.

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 75

 LTE Session Management

12 Forward RAN/NAS Cause Codes to the SGW

The MME can include a RAN/NAS cause code in the RAN/NAS Release Cause IE
in the messages sent to the SGW if the following conditions are fulfilled:

— The RAN Cause Codes in the CDR feature is activated.

— The RanNasCauseCodesInStandardIe parameter is set to true.

— The RAN/NAS cause code is available.

Table 8 lists the messages and the scenarios where the MME can forward the
RAN/NAS cause code to the SGW.

Table 8 Messages and Scenarios Where RAN or NAS Cause Codes Are
Forwarded to the SGW
Messages Scenarios
Delete Session Request MME-Initiated Detach
HSS-Initiated Detach
MME-Initiated PDN Disconnection
Delete Bearer Command MME-Initiated Dedicated Bearer
Deactivation(1)
Delete Bearer Response The MME receives a PGW-initiated
Bearer Deactivation Request while
waiting for GBR deactivation triggered
by an S1 Release.
Create Bearer Response A failing PGW-initiated Dedicated
Bearer Activation
Update Bearer Response A failing PGW-initiated Bearer
Modification
(1) When the S1TimerGbrBearerDeactivation timer is running in an S1 release, an interfering
procedure stops the S1 release and the S1TimerGbrBearerDeactivation timer. If the interfering
procedure triggers a Paging procedure and the paging fails because of time-out, the GBR
Bearer Deletion procedure is triggered and the S1AP cause code for the S1 release is forwarded
in the GBR Bearer Deletion procedure.

76 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Operation and Maintenance

13 Operation and Maintenance

13.1 Parameters
To display the configuration classes and parameters related to LTE Session
Management, use the get_config_area CLI command for the following
configuration areas:

— GwFailureRestoration

— GwBlacklisting

— ImsiBasedGwSelection

— InterfaceS11

— InterfaceS1MME

— PgwReselection

— QualityOfService

— StaticGwSelection

— StaticSgsnMmeSelection

13.2 Counters
The following counters and PmGroups are valid for LTE Session Management:

— SGSN-MME_GTP_Interface

— SGSN-MME_GTPControlPlane

— SGSN-MME_GTPUserPlane

— SGSN-MME_GTPUserPlane_E

— SGSN-MME_Session_DiscardedMessages_G

— SGSN-MME_Session_HO

— SGSN-MME_Session_SM_E

— SGSN-MME_Session_SM_E_ARP

— SGSN-MME_Session_SM_E_QCI

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 77

 LTE Session Management

13.3 Alarms and Events

The following alarms and events are valid for LTE Session Management:

— gtpMMEPathFailure

— gtpMscPathFailure

— gtpMscPathFailure

— pgwRestarted

— sgwRestarted

13.4 Logs
The Session Event Log is valid for LTE Session Management.

For descriptions of the log file, refer to Operation and Maintenance Description
and Session Event Log.

78 42/221 02-AXB 250 05/8 Uen NV | 2021-04-29

 Compliance

14 Compliance

For compliance information about 3GPP interfaces, see:

— SoC with 3GPP TS 23.203

— SoC with 3GPP TS 23.401

— SoC with 3GPP TS 24.301

— SoC with 3GPP TS 29.272

— SoC with 3GPP TS 29.274

— SoC with 3GPP TS 36.413

42/221 02-AXB 250 05/8 Uen NV | 2021-04-29 79