PGW and SGW Selection by MME Mechanism on the ASR

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 APN FQDN APN Lookup for Simple LTE (PGW Candidate List) SGW Selection TAI FQDN 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 Straightforward NAPTR (S NAPTR) 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 S NAPTR procedure for the PGW is either x 3gpp pgw:x s5 gtp or x 3gpp pgw:x s5 pmip. 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 Name FQDN (APN FQDN) value in the network. The NAPTR records are formed from these service parameters and all of the S5/S8 interfaces: x 3gpp pgw:x s8 gtp x 3gpp pgw:x s8 pmip x 3gpp pgw:x s5 gtp x 3gpp pgw:x s5 pmip The APN FQDN is used in DNS queries by the MME and is derived from an APN. The DNS and S NAPTR 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. APN FQDN 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 <APN NI> APN OI mnc<mnc>.mcc<mcc> The APN FQDN is obtained from the APN via insertion of the label apn.epc. between the APN NI and the default APN OI, and via a replacement of the label.gprs at the end of the default APN OI with the labels.3gppnetwork.org. For example, with an APN of internet.mnc015.mcc234.gprs, the derived APN FQDN is internet.apn.epc.mnc015.mcc234.3gppnetwork.org. This format is used by the MME in DNS queries to networks with DNS provisioned to Release 8. 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 APN FQDN format, as described in the sub clause 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 APN FQDN. 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 APN FQDN 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) OI 1 (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 non roaming LTE UE indicates it want to use APN NI 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 S NAPTR procedure with Application Unique String = imstv2.apn.$origin and desired services x 3gpp pgw:x s5 gtp and x 3gpp pgw:x s5 pmip. MME starts with Application Unique String = imstv2.apn.$origin and the desired services x 3gpp pgw:x s5 gtp and x 3gpp pgw:x s5 pmip 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" "x 3gpp pgw:x s8 pmip" "" topoff.vip2.gw01.node.$origin. imstv2.apn.$origin. 3600 IN NAPTR 100 999 "a" "x 3gpp pgw:x s5 gtp:x s8 gtp" "" topoff.vip1.gw21.node.$origin. imstv2.apn.$origin. 3600 IN NAPTR 200 999 "a" "x 3gpp pgw:x s5 gtp:x s8 gtp" "" topoff.vip1.gw01.node.$origin. imstv2.apn.$origin. 3600 IN NAPTR 500 999 "a" "x 3gpp pgw:x s8 pmip" "" topoff.vip2.gw21.node.$origin. End Response from DNS server MME retains only NAPTR records with matching services x 3gpp pgw:x s5 gtp and x 3gpp pgw:x s5 pmip yielding: NAPTR record set replacement service flag order preference topoff.vip1.gw21.node.$origin x 3gpp pgw:x s5 gtp:x s8 gtp "a" 100 999 topoff.vip1.gw01.node.$origin x 3gpp pgw:x s5 gtp:x s8 gtp "a" 200 999 MME node sorts NAPTR by RFC 3958 yielding NAPTR record set replacement service flag order preference topoff.vip1.gw21.node.$origin x 3gpp pgw:x s5 gtp:x s8 gtp "a" 100 999 topoff.vip1.gw01.node.$origin x 3gpp pgw:x s5 gtp:x s8 gtp "a" 200 999 MME Stores records since they are flag "a" topoff.vip1.gw21.node.$origin services of x 3gpp pgw:x s5 gtp topoff.vip1.gw01.node.$origin services of x 3gpp pgw:x s5 gtp MME now has final candidate list (A and AAAA lookup is deferred for our hand example) topoff.vip1.gw21.node.$origin services of x 3gpp pgw:x s5 gtp topoff.vip1.gw01.node.$origin services of x 3gpp pgw:x s5 gtp 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 x 3gpp pgw:x s5 gtp, {192.0.2.115,192.0.2.116}, { 2001:db8:0:e::,2001:db8:0:f::} ) (topoff.vip1.gw01.node.$origin,services of x 3gpp pgw:x s5 gtp, {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 Identity FQDN (TAI FQDN) for each TAI value in the network. The NAPTR records are formed from these service parameters and all of the S5/S8 interfaces: x 3gpp sgw:x s8 gtp x 3gpp sgw:x s8 pmip x 3gpp sgw:x s5 gtp x 3gpp sgw:x s5 pmip The TAI FQDN is used in DNS queries by the MME. The S NAPTR 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) TAI FQDN The MME constructs the TAI FQDN as defined in sub clause 19.4.2.3 of the 3GPP TS 23.003. The TAI FQDN is constructed in this format: tac lb<tac low byte>.tac hb<tac high byte>.tac.epc.mnc<mnc>.mcc<mcc>. 3gppnetwork.org The Tracking Area Code (TAC) is a 16 bit integer. The <TAC high byte> is the hexadecimal string of the most significant byte in the TAC, and the <TAC low byte> 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 non roaming LTE UE performs and initial attach and indicates it want to use a APN NI (an APN in this operator's network). The MME knows it does not need to use S8 since it is a non roaming 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 S NAPTR procedure with Application Unique String = tac lb11.tac hb40.tac.$origin and desired services x 3gpp sgw:x s11,x 3gpp sgw:x s5 gtp, x 3gpp sgw:x s5 pmip. NOTE 2: This particular MME vendor looks for the x s11 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 tac lb11.tac hb40.tac.$origin Start Response from DNS server ;; QUESTION SECTION:

;tac lb11.tac hb40.tac.$origin. IN NAPTR ;; ANSWER SECTION: tac lb11.tac hb40.tac.$origin. 3600 IN NAPTR 400 999 "a" "x 3gpp sgw:x s8 pmip" "" topoff.eth9.gw01.node.$origin. tac lb11.tac hb40.tac.$origin. 3600 IN NAPTR 500 999 "a" "x 3gpp mme:x s10" "" topoff.eth1.mmec02.mmegi8001.mme.$origin. tac lb11.tac hb40.tac.$origin. 3600 IN NAPTR 600 999 "a" "x 3gpp mme:x s10" "" topoff.eth1.mmec01.mmegi8001.mme.$origin. tac lb11.tac hb40.tac.$origin. 3600 IN NAPTR 100 999 "a" "x 3gpp sgw:x s5 gtp:x s8 gtp" "" topoff.eth4.gw21.node.$origin. tac lb11.tac hb40.tac.$origin. 3600 IN NAPTR 200 999 "a" "x 3gpp sgw:x s5 gtp:x s8 gtp" "" topoff.eth4.gw01.node.$origin. tac lb11.tac hb40.tac.$origin. 3600 IN NAPTR 300 999 "a" "x 3gpp sgw:x s8 pmip" "" topoff.eth9.gw21.node.$origin. End Response from DNS server MME retains only the NAPTR with matching services x 3gpp sgw:x s11,x 3gpp sgw:x s5 gtp, and x 3gpp sgw:x s5 pmip yielding NAPTR record set replacement service flag order preference topoff.eth4.gw01.node.$origin x 3gpp sgw:x s5 gtp:x s8 gtp "a" 200 999 topoff.eth4.gw21.node.$origin x 3gpp sgw:x s5 gtp:x s8 gtp "a" 100 999 Note the x s8 gtp 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 x 3gpp sgw:x s5 gtp:x s8 gtp "a" 100 999 topoff.eth4.gw01.node.$origin x 3gpp sgw:x s5 gtp:x s8 gtp "a" 200 999 MME Stores topoff.eth4.gw21.node.$origin services of x 3gpp sgw:x s5 gtp topoff.eth4.gw01.node.$origin services of x 3gpp sgw:x s5 gtp MME now has candidate list topoff.eth4.gw21.node.$origin services of x 3gpp sgw:x s5 gtp topoff.eth4.gw01.node.$origin services of x 3gpp sgw:x s5 gtp 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(config call control profile lmn)# plmn protocol plmnid mcc <> mnc <> { [s5 protocol <[pmip gtp] >] [s8 protocol <[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(config call control profile lmn)# dns pgw context <name> [ctxt]asr5000(config call control profile lmn)# dns sgw context <name> MME Service Here is the relevant configuration for the MME service: [ctxt]asr5000(config mme service)#dns pgw [context <name>] [ctxt]asr5000(config mme service)#dns sgw [context <name>] Sample DNS Client Configuration Here is a sample DNS client configuration on the ASR5x00: #(config ctx)# ip name servers 192.20.20.1 192.20.20.3 #(config ctx)# dns client xyz bind address 192.20.20.2 port 6011 resolver retransmission interval 3 resolver number of retries 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 round robin answers The DNS resolution procedure for the S/P GW 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(config call control profile lmn)# gw selection [ 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 non collocated 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 domain lookup ip name servers <ip address of the Linux machine (it should be running bind)> dns client dns bind address 192.80.10.2 round robin answers exit mme service <mmesvc> dns pgw dns service dns context ingress dns sgw dns service dns context ingress exit Useful Troubleshooting Commands You can use these commands in order to troubleshoot the MME mechanism: #dns client query client name dns query type NAPTR query name <starent.com.apn.epc.mncxxx.mccxxx.3gppnetwork.org> #show dns client <dns1> statistics #show dns client cache client <> Related Information TS 29.303

Technical Support & Documentation Cisco Systems Updated: Jun 18, 2015 Document ID: 119015