PGW and SGW Selection by MME Mechanism on

the ASR
Document ID: 119015
Contributed by Krishna Kishore DV, Cisco TAC Engineer.
Jun 18, 2015

Contents
Introduction
Resource Records
A and AAAA
NAPTR
SRV
PGW Selection
APNFQDN
APN Lookup for Simple LTE (PGW Candidate List)
SGW Selection
TAIFQDN
TAI Lookup for Simple LTE (SGW Candidate List)
ASR5x00 Configurations
S5/S8 Protocol
DNS
CC Profile
MME Service
Sample DNS Client Configuration
GW Selection Criteria
Additional Configurations
Useful Troubleshooting Commands

Related Information

Introduction
This document describes the way in which the Mobility Management Entity (MME) mechanism is used in
order to select Packet Gateways (PGWs) and Serving Gateway (SGWs), and how it is implemented on the
Cisco 5x00 Series Aggregated Service Router (ASR5x00).

Resource Records
This section describes the various resource records that are used by the MME.

A and AAAA
The A resource record is used in order to define the Internet Protocol Version 4 (IPv4) host addresses that
correspond to the Fully Qualified Domain Name (FQDN) of the host. The AAAA resource record is used in
order to define the Internet Protocol Version 6 (IPv6) host addresses that correspond to the FQDN of the host.

Here is an example:
example.example.com

1500 IN A 1.1.1.1

NAPTR
The Name Authority Pointer (NAPTR) resource record and is a powerful tool that allows Domain Name
System (DNS) to be used in order to look up services for a wide variety of resource names that are not in the
Domain Name (DN) syntax.

The StraightforwardNAPTR (SNAPTR) procedure is used for the resolution of a DN, application service
name, or application protocol dynamically in order to target the server and port via both NAPTR and Service
(SRV).

Here is an example:

starent.apn.epc.mnc012.mcc345.3gpp.org

order pref flags

2000 IN NAPTR 100 10 "s" "SGW:PMIP" ( ; service

"" ; regexp

pmip.example.com. ; replacement

SRV
The SRV resource record uses a pool of servers for a single domain with static load balancing to each server
in order to move services from host to host and in order to designate some hosts as primary servers for a
service from a pool of hosts.

Here is an example:

pmip.example.com

Pref Weight Port Target

1500 IN SRV 10 0 10000 example.example.com.

PGW Selection
This image illustrates the PGW selection by the MME for the initial Attach message and the additional Public
Data Network (PDN) connection:
During the initial Attach and PDN connection creation with 3rd Generation Partnership Project (3GPP)
access, both a PGW and an SGW must be selected by the MME.

The service parameter that is used in the SNAPTR procedure for the PGW is either x3gpppgw:xs5gtp
or x3gpppgw:xs5pmip.

You must provision the authoritative DNS server that is responsible for the
apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org domain with NAPTR records for each Access Point
NameFQDN (APNFQDN) value in the network. The NAPTR records are formed from these service
parameters and all of the S5/S8 interfaces:

x3gpppgw:xs8gtp

x3gpppgw:xs8pmip

x3gpppgw:xs5gtp

x3gpppgw:xs5pmip

The APNFQDN is used in DNS queries by the MME and is derived from an APN. The DNS and SNAPTR
procedures logically output a list of host names that are each coupled with a service, a protocol, a port, and a
list of IPv4 and/or IPv6 addresses. This is the candidate list of the PGWs for a specific APN. This candidate
list is passed through the selection logic in order to choose a specific PGW. The selection logic can use
parameters such as:

Load (locally deduced)

Order, preference, and weight (DNS provided)

Collocation with the SGW (learned from DNS responses)

Topological closeness

Note: Once the PGW has successfully been contacted, the selected PGW host name, the used PGW IP
address, the port number, and the selected protocol type is stored in the MME per PDN.

APNFQDN
The APN is received by the Evolved Packet Core (EPC) node discovery function for 3GPP accesses and has
two parts: the APN Network Identifier (NI) and the APN Operator Identifier (OI).
Here is an example:

APN NI <APNNI>
APN OI mnc<MNC>.mcc<MCC>

The APNFQDN is obtained from the APN via insertion of the label apn.epc. between the APNNI and the
default APNOI, and via a replacement of the label .gprs at the end of the default APNOI with the labels
.3gppnetwork.org.

For example, with an APN of internet.mnc015.mcc234.gprs, the derived APNFQDN is

internet.apn.epc.mnc015.mcc234.3gppnetwork.org.

This format is used by the MME in DNS queries to networks with DNS provisioned to Release8. The DNS
records that are provisioned at this location are NAPTR records and include all of the S5/S8 interfaces for
PGW and the collocated PGWs/SGWs that are intended to be used for that APN.

There are exactly three labels, and the last label is gprs. The APN is transformed to the APNFQDN format,
as described in the subclause 19.4.2.2.3 of the 3GPP Technical Specifications (TS) 23.003 [2]:

If the APN has the last three labels matching the pattern "mnc<MNC>.mcc<MCC>.gprs",
where <MNC> and <MNC> are each composed of 3 decimal digits, then the last 3 labels of
the APN shall be replaced by "apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" to form
the APNFQDN.

Else if the User Equipment(UE)/Mobile Station(MS) is in the home network and the APN
string has as last label "gprs", then last label "gprs" in the APN string shall be replaced by
"apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" to form the APNFQDN where the
Mobile Network Code(MNC) and Mobile Country Code(MCC) values are the values of the
home network. This use case occurs if the Home Public Land Mobile Network(HPLMN)
OI1 (derived from the APN OI Replacement field in the subscriber's profile) does not
conform to the pattern "mnc<MNC>.mcc<MCC>.gprs".

Otherwise the APN is invalid and cannot be used for a Release 8 APN usage.

APN Lookup for Simple LTE (PGW Candidate List)

Here is an example of an APN lookup for a simple Long Term Evolution (LTE) scenario from TS 29.303:

Assume a nonroaming LTE UE indicates it want to use APNNI string "imsTV2" to the
MME in our example network at initial attach.

NOTE 1: Reminder $ORIGIN is epc.mnc990.mcc311.3gppnetwork.org. and is employed

here simply to keep the length of the example text manageable

The MME starts the SNAPTR procedure with Application Unique String =
imsTV2.apn.$ORIGIN and desired services x3gpppgw:xs5gtp and
x3gpppgw:xs5pmip.

MME starts with Application Unique String = imsTV2.apn.$ORIGIN and the desired services
x3gpppgw:xs5gtp and x3gpppgw:xs5pmip

Command to DNS server

## dig @192.0.2.247 +tcp NAPTR imsTV2.apn.$ORIGIN

Start Response from DNS server

;; QUESTION SECTION:

;imsTV2.apn.$ORIGIN. IN NAPTR

;; ANSWER SECTION:

imsTV2.apn.$ORIGIN. 3600 IN NAPTR 600 999 "a" "x3gpppgw:xs8pmip" ""

topoff.vip2.gw01.node.$ORIGIN.

imsTV2.apn.$ORIGIN. 3600 IN NAPTR 100 999 "a" "x3gpppgw:xs5gtp:xs8gtp"

"" topoff.vip1.gw21.node.$ORIGIN.

imsTV2.apn.$ORIGIN. 3600 IN NAPTR 200 999 "a" "x3gpppgw:xs5gtp:xs8gtp"

"" topoff.vip1.gw01.node.$ORIGIN.

imsTV2.apn.$ORIGIN. 3600 IN NAPTR 500 999 "a" "x3gpppgw:xs8pmip" ""

topoff.vip2.gw21.node.$ORIGIN.

End Response from DNS server

MME retains only NAPTR records with matching services x3gpppgw:xs5gtp and
x3gpppgw:xs5pmip yielding:

NAPTR record set

replacement service flag order preference

topoff.vip1.gw21.node.$ORIGIN x3gpppgw:xs5gtp:xs8gtp "a" 100 999

topoff.vip1.gw01.node.$ORIGIN x3gpppgw:xs5gtp:xs8gtp "a" 200 999

MME node sorts NAPTR by RFC 3958 yielding

NAPTR record set

replacement service flag order preference

topoff.vip1.gw21.node.$ORIGIN x3gpppgw:xs5gtp:xs8gtp "a" 100 999

topoff.vip1.gw01.node.$ORIGIN x3gpppgw:xs5gtp:xs8gtp "a" 200 999

MME Stores records since they are flag "a"

topoff.vip1.gw21.node.$ORIGIN services of x3gpppgw:xs5gtp

topoff.vip1.gw01.node.$ORIGIN services of x3gpppgw:xs5gtp

MME now has final candidate list (A and AAAA lookup is deferred for our hand example)

topoff.vip1.gw21.node.$ORIGIN services of x3gpppgw:xs5gtp

topoff.vip1.gw01.node.$ORIGIN services of x3gpppgw:xs5gtp

The needed A/AAAA records were included with additional records. I.e.

topoff.vip1.gw21.node.$ORIGIN. 3600 IN A 192.0.2.116

topoff.vip1.gw21.node.$ORIGIN. 3600 IN A 192.0.2.115

topoff.vip1.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:e::

 topoff.vip1.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:f::

and

topoff.vip1.gw01.node.$ORIGIN. 3600 IN A 192.0.2.114

topoff.vip1.gw01.node.$ORIGIN. 3600 IN A 192.0.2.113

topoff.vip1.gw01.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:c::

topoff.vip1.gw01.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:d::

IF the A and AAAA records were not available in the Additional Record section (or a DNS
cache) the MME would do the A/AAAA lookups. Which emulating with manual commands
would look like:

dig @192.0.2.247 +tcp A topoff.vip1.gw21.node.$ORIGIN

dig @192.0.2.247 +tcp AAAA topoff.vip1.gw21.node.$ORIGIN

dig @192.0.2.247 +tcp A topoff.vip1.gw01.node.$ORIGIN

dig @192.0.2.247 +tcp AAAA topoff.vip1.gw01.node.$ORIGIN

We can form the full candidate list now (after random shuffling the A and AAAA records) to
get

(topoff.vip1.gw21.node.$ORIGIN ,services of x3gpppgw:xs5gtp ,

{192.0.2.115,192.0.2.116}, { 2001:db8:0:e::,2001:db8:0:f::} )

(topoff.vip1.gw01.node.$ORIGIN ,services of x3gpppgw:xs5gtp ,

{192.0.2.114,192.0.2.113}, { 2001:db8:0:c::, 2001:db8:0:d::)

SGW Selection
The SGW selection function selects an available SGW to serve a UE. The selection is based on the network
topology. The selected SGW serves the UE location, and when there are SGW service areas that overlap, the
selection might prefer the SGWs with service areas that reduce the probability of an SGW change.

The SGW selection uses the Tracking Area Identity (TAI), which provides information about the location of
the UE attachment to the Radio Access Network (RAN). You should provision the authoritative DNS server
that is responsible for the NAPTR records under the Tracking Area IdentityFQDN (TAIFQDN) for each
TAI value in the network. The NAPTR records are formed from these service parameters and all of the S5/S8
interfaces:

x3gppsgw:xs8gtp

x3gppsgw:xs8pmip

x3gppsgw:xs5gtp

x3gppsgw:xs5pmip

The TAIFQDN is used in DNS queries by the MME. The SNAPTR procedures, described in later sections,
logically outputs a list of host names, each of which are coupled with a service, a protocol, a port, and a list of
IPv4 and/or IPv6 addresses. This is the candidate list of SGWs for a specific APN. This candidate list is
passed through the selection logic in order to choose a specific SGW. The selection logic can use parameters
such as:

TAI coverage

Load (locally deduced)

Order, preference, and weight (DNS provided)

Collocation with PGW (learned from DNS responses)

Topology (PGW Node name)

TAIFQDN
The MME constructs the TAIFQDN as defined in sub clause 19.4.2.3 of the 3GPP TS 23.003. The
TAIFQDN is constructed in this format:

taclb<TAClowbyte>.tachb<TAChighbyte>.tac.epc.mnc<MNC>.mcc<MCC>. 3gppnetwork.org

The Tracking Area Code (TAC) is a 16 bit integer. The <TAChighbyte> is the hexadecimal string of the
most significant byte in the TAC, and the <TAClowbyte> is the hexadecimal string of the least significant
byte.

TAI Lookup for Simple LTE (SGW Candidate List)

Here is an example of the TAI lookup for a Simple LTE scenario from TS 29.303:

Assume a nonroaming LTE UE performs and initial attach and indicates it want to use a
APNNI (an APN in this operator's network). The MME knows it does not need to use S8
since it is a nonroaming UE and must be local APN so S5 is used.

NOTE 1: Reminder $ORIGIN is epc.mnc990.mcc311.3gppnetwork.org. and is employed

here simply to keep the length of the example text manageable.

The MME has the TAI value where the UE has attached. We assume the low byte of the TAC
is hex 11 and the high byte is hex 40.

The MME starts the SNAPTR procedure with Application Unique String =
taclb11.tachb40.tac.$ORIGIN and desired services
x3gppsgw:xs11,x3gppsgw:xs5gtp, x3gppsgw:xs5pmip.

NOTE 2: This particular MME vendor looks for the xs11 values, which is only an optional
optimization. This will not have any benefit in this example since the operator chose not to
provision them.

Here we emulate the same action the MME would do manually with the "dig" command.

Command to DNS server

## dig @192.0.2.247 +tcp NAPTR taclb11.tachb40.tac.$ORIGIN

Start Response from DNS server

;; QUESTION SECTION:
;taclb11.tachb40.tac.$ORIGIN. IN NAPTR

;; ANSWER SECTION:

taclb11.tachb40.tac.$ORIGIN. 3600 IN NAPTR 400 999 "a" "x3gppsgw:xs8pmip"

"" topoff.eth9.gw01.node.$ORIGIN.

taclb11.tachb40.tac.$ORIGIN. 3600 IN NAPTR 500 999 "a" "x3gppmme:xs10" ""

topoff.eth1.mmec02.mmegi8001.mme.$ORIGIN.

taclb11.tachb40.tac.$ORIGIN. 3600 IN NAPTR 600 999 "a" "x3gppmme:xs10" ""

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN.

taclb11.tachb40.tac.$ORIGIN. 3600 IN NAPTR 100 999 "a"

"x3gppsgw:xs5gtp:xs8gtp" "" topoff.eth4.gw21.node.$ORIGIN.

taclb11.tachb40.tac.$ORIGIN. 3600 IN NAPTR 200 999 "a"

"x3gppsgw:xs5gtp:xs8gtp" "" topoff.eth4.gw01.node.$ORIGIN.

taclb11.tachb40.tac.$ORIGIN. 3600 IN NAPTR 300 999 "a"

"x3gppsgw:xs8pmip" "" topoff.eth9.gw21.node.$ORIGIN.

End Response from DNS server

MME retains only the NAPTR with matching services

x3gppsgw:xs11,x3gppsgw:xs5gtp, and x3gppsgw:xs5pmip yielding

NAPTR record set

replacement service flag order preference

topoff.eth4.gw01.node.$ORIGIN x3gppsgw:xs5gtp:xs8gtp "a" 200 999

topoff.eth4.gw21.node.$ORIGIN x3gppsgw:xs5gtp:xs8gtp "a" 100 999

Note the xs8gtp are not really included but are kept here to allow the reader to see which
NAPTR record was kept from the DNS response.

MME node sorts the NAPTR records by RFC 3958 yielding

NAPTR record set

replacement service flag order preference

topoff.eth4.gw21.node.$ORIGIN x3gppsgw:xs5gtp:xs8gtp "a" 100 999

topoff.eth4.gw01.node.$ORIGIN x3gppsgw:xs5gtp:xs8gtp "a" 200 999

MME Stores

topoff.eth4.gw21.node.$ORIGIN services of x3gppsgw:xs5gtp

topoff.eth4.gw01.node.$ORIGIN services of x3gppsgw:xs5gtp

MME now has candidate list

topoff.eth4.gw21.node.$ORIGIN services of x3gppsgw:xs5gtp

topoff.eth4.gw01.node.$ORIGIN services of x3gppsgw:xs5gtp

Again the A/AAAA records were available in the additional record section.
 topoff.eth4.gw21.node.$ORIGIN. 3600 IN A 192.0.2.140

topoff.eth4.gw21.node.$ORIGIN. 3600 IN A 192.0.2.139

topoff.eth4.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:26::

topoff.eth4.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:27::

and

topoff.eth4.gw01.node.$ORIGIN. 3600 IN A 192.0.2.132

topoff.eth4.gw01.node.$ORIGIN. 3600 IN A 192.0.2.131

topoff.eth4.gw01.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:1e::

topoff.eth4.gw01.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:1f::

From the candidate list that results, an SGW is chosen based on a combination of these criteria:

Maximum TA coverage

Geographic proximity

Load balancing

Combined PGW/SGW functionality

Protocols that are supported

ASR5x00 Configurations
This section describes the relevant configurations for the ASR5x00.

S5/S8 Protocol
The S5 and S8 protocols should be configurable for the MME on a per HPLMN basis. This is used in order to
shortlist the resource records that are returned by the DNS server. Only the PGWs that support the configured
protocol are considered in the Gateway (GW) selection. The configuration is placed under the Call Control
(CC) profile that is associated with the operator policy.

Here is an example:

[ingress]asr5000(configcallcontrolprofilelmn)# plmnprotocol plmnid mcc <> mnc <>

{ [s5protocol <[pmip | gtp] >] | [s8protocol <[pmip | gtp]>] }

DNS
The system allows one DNS client service to be configured per context. The DNS client service to be used for
the FQDN resolution is named under the CC profile and/or the MME service separately for the PGW and the
SGW. In the CC profile, the context name is mandatory, as the CC profile is not attached to any context. In
the MME service, the context name is optional. If no name is specified, the context of the MME service is
used for the DNS service.
CC Profile
Here is the relevant configuration for the CC profile:

[ctxt]asr5000(configcallcontrolprofilelmn)# dnspgw context <name>

[ctxt]asr5000(configcallcontrolprofilelmn)# dnssgw context <name>

MME Service
Here is the relevant configuration for the MME service:

[ctxt]asr5000(configmmeservice)#dns pgw [context <name>]

[ctxt]asr5000(configmmeservice)#dns sgw [context <name>]

Sample DNS Client Configuration

Here is a sample DNS client configuration on the ASR5x00:

#(configctx)# ip nameservers 192.20.20.1 192.20.20.3

#(configctx)# dnsclient xyz

bind address 192.20.20.2 port 6011

resolver retransmissioninterval 3

resolver numberofretries 2

cache ttl positive 86400

cache ttl negative 60

cache size central 50000

cache size local 1000

cache algorithm central FIFO

cache algorithm local LRU

no roundrobinanswers

The DNS resolution procedure for the S/PGW is invoked only when the CLI information that is shown in the
previous example is enabled. Otherwise, the static address that is configured in the MME service is used.

Additionally, if the DNS resolution fails, then the static address that is configured in the MME service is used.

GW Selection Criteria
This configuration is placed under the CC profile that is associated with the operator policy. It decides the
selection algorithms that are used in order to eventually select a PGW/SGW from the resource records that are
returned by the DNS. Only one of the criteria can be configured at a time.

Here is an example:

[ctxt]asr5000(configcallcontrolprofilelmn)# gwselection [ topology |

collocation | pgw < weight > | sgw <weight> ]
Here are some important considerations when collocation is the selection criterion:

Collocation should be configured for both the PGW and the SGW selection in order for collocation to
function properly.

Collocation is given the highest priority. In other words, even if the degree of labels that match
between a noncollocated PGW/SGW pair might be higher than a collocated pair, the collocated pair
is selected.

Host names with both topon and topoff labels are considered in collocation.

Collocation implicitly means topology match. If a collocated PGW/SGW node cannot be found, then
the topologically closest nodes are chosen next.

Note: Dependent upon the operator requirements, this approach might change in the future in order to separate
the collocation and topology match criteria.

Additional Configurations
Here are some additional configurations that you must implement on the ASR5x00:

context ingress

ip domainlookup

ip nameservers <ip address of the Linux machine (it should be running bind)>

dnsclient dns

bind address 192.80.10.2

roundrobinanswers

exit

mmeservice <mmesvc>

dns pgw dnsservice dns context ingress

dns sgw dnsservice dns context ingress

exit

Useful Troubleshooting Commands

You can use these commands in order to troubleshoot the MME mechanism:

#dnsclient query clientname dns querytype NAPTR queryname

<starent.com.apn.epc.mncxxx.mccxxx.3gppnetwork.org>

#show dnsclient <dns1> statistics

#show dnsclient cache client <>

Related Information
TS 29.303
 Technical Support & Documentation Cisco Systems

Updated: Jun 18, 2015 Document ID: 119015