9.2.1 Selection procedure at a glance

Let us first illustrate a simplified Initial Attach procedure where an MME, Serving GW and PDN GW need to be selected for the user. The actual message flows for Initial Attach are shown in Chapter 12 but in the flow chart shown in Figure 9.2.1.1, we only show the order of events on a high level.

3GPP systems including EPS provide connectivity towards multiple PDNs with independent and unique IP connection for each PDN (see Section 6.2 for more details). Each PDN connection established for a new APN requires an additional PDN GW selection process in the MME. In somewhat simplified terms, the DNS is used to store the mapping between APN and PDN GWs. Since for each user (i.e. UE) there can only be a single Serving GW at any given time in the network, selection of the additional PDN GW must use the current Serving GW information as part of its input data for this selection process. With an APN-FQDN created from the APN as the first query parameter to the DNS procedures, the MME will receive a list of candidate PDN GWs. Based on whether the GW collocation is preferred or not, the MME uses the Serving GW already selected as the next criterion in the selection process. When collocation is desired, the MME selects the PDN GW collocated with the already selected Serving GW, if possible. When collocation is not set, then the protocol used on the S5/S8 (interface (GTP or PMIP) as well as other preference criteria set by the SRV and NAPTR records in the DNS system may provide the next selection criterion. Otherwise MME may select a random PDN GW from the candidates list.

Until now, we have focused on the selection process for the case when a user establishes connectivity in the EPS network. In addition to that, during the mobility procedure such as during handover between 3GPP accesses (for more details, see Section 6.4), an MME or SGSN may need to be changed (e.g. in case of MME pool change) and in such a case, the current serving MME needs to select a new candidate MME to transfer the session to. This selection is performed by the serving node and is based on the Tracking Area Identity (TAI) Fully Qualified Domain Names (FQDN), where the TAI is from the target Cell ID that the target eNB has provided to the serving MME. In case of SGSN selection, either the Routing Area ID of the GERAN or UTRAN is used or, in case of UTRAN, the RNC ID can be used in the same way as the TAI to construct the FQDN to find the right SGSN (pool) with the Rel-8 SGSNs. Note that in case of pre-Rel-8 SGSN, existing selection mechanism must be maintained (see TS29.303, [29.303] for more details) which is simpler and do not necessarily mandate DNS usage.

In the case of Serving GW relocation, which should be a rare procedure and only occur if the Serving GW service area changes, the MME uses the TAI as well as the protocol supported on the S5/S8 reference point (GTPv2 or PMIPv6) in its DNS query to get the appropriate candidate Serving GW list.

Note that the MME is responsible for keeping track of all relevant information for Serving GW as well as each PDN GW per PDN basis, this includes host name, IP address, selected port (if not according to standard) and selected protocol type. The MME needs to be configured with the variant of protocol that is used over the S5/S8 reference point. To support roaming cases, the MME is configured on a per HPLMN basis with the S8 protocol variant (PMIPv6 or GTP).

The HSS may also be provisioned with a specific PDN GW IP address and/or FQDN per APN basis and MME will have this information available during Initial Attach procedure and then this input shall be used to select the P-GW for that user. In particular, to support handovers between 3GPP and non-3GPP accesses where the same PDN GW as was used in source access needs to be allocated in target access, the HSS contains information about the currently used PDN GW. This PDN GW information is provided to the node performing PDN GW selection (e.g. MME for E-UTRAN).

9.2.2 Use of DNS infrastructure

Before going into the details of the individual node selection, it is important to understand the 3GPP structure and requirements on the DNS and its usage. The GPRS system as well as the IP Multimedia Subsystem (IMS) in 3GPP has used DNS extensively, including DNS NAPTR and SRV records developed within the IETF. The EPS continues this and expands DNS usage to include node selection.

The DNS parameters and procedures for EPS are specified in 3GPP TS 23.003, [23.003] and TS 29.303. These specifications, and the DNS related IETF RFCs such as RFC 2181, [RFC 2181], RFC 1035, [RFC 1035], RFC 3958, [RFC 3958] and RFC 2606, [RFC 2606] can be consulted for further details.

Note that the use of DNS infrastructure in order to discover the nodes is not mandatory as operators may choose to use O&M functions and other provisioning methods to achieve the selection process. Use of DNS and its supporting services definitely improves the selection process as various criteria can be used an input to the process and also makes it easy and flexible for inter-operator operations.

In EPS, the DNS is used to store information on mapping between APN, protocol (GTP or PMIP) and PDN GW, as well as mapping between TAI and Serving GW. The DNS can also be configured so that the DNS records provide information on collocated nodes as well as topological/geographical closeness between different nodes. In order to utilize the DNS infrastructure as well as IP-networks, rules are defined for how to construct the FQDN used for DNS procedures. While GGSN selection in GPRS systems use only address (A/AAAA) records in DNS, the EPS DNS procedures support also SRV and NAPTR records and are able to provide the more powerful features already mentioned above, e.g. to support collocated nodes and topological closeness . In particular the Straightforward-NAPTR (S-NAPTR) procedure is used, with a suitable FQDN as input, to retrieve a candidate list of host names and corresponding service (e.g. protocol), port and IPv4/IPv6 addresses. For more detailed information on S-NAPTR, see RFC 3958, [3958] and TS 29.303, [29.303]. Below we briefly describe some of the definitions and rules that are needed for the selection functions.

9.2.3 MME selection

MME selection function is located in the eNB only. The architecture supports multiple eNBs connected to multiple MMEs as well as Serving GWs.

When an UE attempts to attach to E-UTRAN (see Session Management section in Chapter 6 for details), it provides the eNB with parameters; that is, GUTI, (see Section 6.6 on Identities for more details) that would facilitate selection of the appropriate MME based on how the GUTI is constructed. eNB is also informed of the load status of the MMEs within a pool (see Pool information in, Section 6.7) via S1-AP signalling and thus able to provide additional information to the eNBs connected to the MME pool. This allows for efficient selection of MME within a pool and also allows triggers towards the UE (using Tracking Area Update or S1 Release procedures) to reconnect to a different MME within a pool when required. The process of MME selection is designed to be efficient from the UE movement point of view and have been developed to reduce MME change when serving within certain operating boundaries.

The eNB is responsible for the selection of an appropriate MME at UE attachment when no routing to an MME can be determined from the information provided by the UE.

It is important to understand how MME would be represented in the operators’ IP network, in this case how the FQDN for the MME or MME Pool would be constructed, since identifying the correct MME for an UE is dependant on it.

An MME within an operator’s network is identified using an MME Group ID (MMEGI), and an MME Code (MMEC), which is then made available to the eNB via GUTI and/or other parameters that identify the UE in the network (see Identifiers, Section 6.6.).

A sub-domain name is derived from the MNC and MCC by adding the label ‘mme’ to the beginning of the Home Network Realm/Domain.

The MME node FQDN is constructed as:

An MME pool FQDN is constructed as:

When an MME or SGSN is selecting another MME the TAI FQDN is used towards the DNS to find the appropriate MME (in a pool) and then the information is analysed using A/AAAA queries to get the actual MME address details.

The TAI consists of a TAC, MNC and MCC.

A sub-domain name is derived from the MNC and MCC by adding the label ‘tac’ to the beginning of the Home Network Realm/Domain.

The TAI FQDN is constructed as:

9.2.4 SGSN selection function for EPS

As described in the overview section, the SGSN selection in case of EPS is relevant for Inter-Radio-Access-Technology Handover (Inter-RAT HO) within 3GPP access. In such case, the serving node is responsible to select the target SGSN using either RAI or RNC-ID (in case of UTRAN access only).

A specific SGSN within an operator’s network is identified using the RAI FQDN and the Network Resource Identifier (NRI) which uniquely identifies the core network assigned to the terminal. This identifier can be used by a target MME or SGSN node to connect to the source SGSN node.

The SGSN FQDN is constructed as:

9.2.5 GW selection overview

GW Selection includes the Serving GW as well as PDN GW selection process which is performed by the MME. Compared to GPRS, selection of Serving GWs and PDN GWs have become more complex. It is very tightly coupled to the various protocol choices on certain reference points (e.g. S5/S8) as well as certain network configuration such as Local Breakout, in addition to maintaining existing GPRS GGSN selection function parameters like APN.

A related aspect is GW selection by an SGSN that support both Gn/Gp and S4 interfaces and thus may select between GGSN and PDN GW. In this case it is possible for the SGSN to use the information on whether the UE supports E-UTRAN or not (as indicated in the UE capability information sent by the UE) as input to select either a GGSN or a Serving GW and PDN GW. UEs not supporting E-UTRAN may, for example, be allocated a GGSN while UEs supporting E-UTRAN would need to be handled by a PDN GW in order to allow a potential handover to E-UTRAN.

9.2.6 PDN GW selection function

In case of 3GPP access, the PDN GW selection function is located in the MME and SGSN, whereas for non-3GPP access the PDN GW selection function is located depending on the protocol used in the appropriate reference points (i.e. S2a, S2b and S2c).

1. For PMIPv6, it is the MAG functional entity that performs the selection function (an example of such case is the 3GPP2 HSGW entity which is also known as Access Gateway in a generic manner in 3GPP specifications).

2. For MIPv4 FA mode on S2a, the entity requesting the PDN GW is the entity that plays the role of the FA.

3. For DSMIPv6, the UE needs to be provided with an appropriate PDN GW address (to be used as Home Agent address for DSMIPv6). Different methods are available in EPS. When connecting over an access supporting transfer of Protocol Configurations Options (PCO), the PDN GW address may be returned to the UE in such a PCO field. When connecting towards an ePDG, the PDN GW address may be returned to the UE in the IKEv2 signalling with ePDG. If none of these methods are available, then the UE may use DHCP mechanisms or querying a DNS server based on the PDN information (using APN) may be used to select the PDN GW.

The PDN GW selection function uses subscriber information provided by the HSS and possibly additional criteria. The PDN subscription contexts provided contains information such as the APN(s) the user has subscribed to and (for roaming cases) whether this APN(s) is allowed to be connected to using a PDN GW located in the VPLMN, or if the user has to connect via a PDN GW located in the HPLMN.

In the case of non-3GPP accesses using PMIPv6 or MIPv4, the PDN Gateway selection function interacts with the 3GPP AAA Server or 3GPP AAA Proxy and uses subscriber information provided by the HSS to the 3GPP AAA Server. To support separate PDN GW addresses at a PDN GW for different mobility protocols (PMIP, MIPv4 or GTP), the PDN GW Selection function takes mobility protocol type into account when deriving PDN GW address by using the Domain Name Service function, in a similar way as is done by the MME/SGSN.

In case of 3GPP access, the PDN GW selection function interacts with HSS to retrieve subscriber information and uses information such as whether the Serving GW and PDN GW must be collocated; the topological/geographical closeness (described in TS 29.303, [29.303]) and protocol option on the S5/S8 (GTP or PMIP, note that a GW selected may also support both protocols).

Note that collocation of Serving GW and PDN GW is not part of the 3GPP standards specifications for non-3GPP accesses since the use of Serving GW for non-3GPP access is only relevant to a specific case known as Chained S2a/S2b-S8. This chained scenario is not further described in this book. Interested readers should refer to TS 23.402, [23.402] for more details.

In the case a static PDN GW is configured by the operator to be used for that user, the PDN GW is selected by either having the APN configured to map to a given PDN GW (i.e. the APN resolves to a single PDN GW only), or the PDN GW identity provided by the HSS explicitly shows the use of static PDN GW.

The APN may also be provided by the UE. In this case, this UE-provided APN is used to derive the APN-FQDN as long as the subscription allows for it.

If the user is roaming and the HSS provides a PDN subscription context that allows for allocation of a PDN GW from the visited PLMN for this APN, the PDN GW selection function selects a PDN GW from the visited PLMN. If a visited PDN GW cannot be found or if the subscription does not allow for allocation of a PDN GW from the visited PLMN, then the APN is used to select a PDN GW from the HPLMN.

If the UE is requesting a connection to an existing PDN via the same APN, the selection function must select the same PDN GW as it used previously to establish the PDN connection to this APN.

To support the PDN GW selection using the S-NAPTR procedures, the authoritative DNS server responsible for the ‘apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org’ domain must provision NAPTR records for the given APN and corresponding PDN GWs under the APN-FQDN:

Some example S-NAPTR procedures are included here for illustration purposes. For detailed information on 3GPP usage of various IETF specifications and their adaptation for 3GPP network usage, TS 29.303, [29.303] is an excellent source. For 3GPP access:

When non-roaming, the Initial attach the S-NAPTR procedure to get the list of ‘candidate’ PDNGW shall use ‘Service Parameters’ of:

When roaming, the Serving GW is in the VPLMN and if the APN to be selected is in the HPLMN, then the selection function for the S-NAPTR procedure shall use ‘Service Parameters’ of:

When non-roaming and additional PDN connection is to be established, the Serving GW is already selected (i.e. the UE has an existing PDN connection), and the selection function shall use the S-NAPTR procedure ‘Service Parameters’:

For non-3GPP access:

When PMIP is used for Initial attach and both roaming and non-roaming cases, the selection function shall use the S-NAPTR procedure with ‘Service Parameters’ of:

The additional information is received from 3GPP AAA server/Proxy regarding the appropriate protocol is used over S8 (i.e. GTP vs. PMIP).

9.2.7 Serving GW selection function

In case of 3GPP access, the Serving GW is a mandatory node, whereas in case of non-3GPP access the Serving GW is used only is special case of chained scenario. This chained scenario is not further described in this book. Please refer to TS 23.402 [23.404] if interested to learn more about this feature.

The Serving GW selection function selects an available Serving GW to serve an UE. The selection is based on network topology, that is, the selected Serving GW serves the UE’s location (derived from the TAI) and in case of overlapping Serving GW service areas, the selection may prefer Serving GWs with service areas that reduce the probability of changing the Serving GW as the UE moves around the network.

Due to the possibility of using either GTP or PMIPv6 over the S5 and S8 interfaces as well as possible multiple PDN connections involving HPLMN and VPLMN (in this case the VPLMN provides the network configuration required for Local Breakout where the PDN GW in the VPLMN needs to be selected) when roaming, Serving GWs may need to support both protocols for a single UE connected to different PDNs. This may, for example, be needed in case a UE has two PDN connections, one with PDN GW in Visited PLMN and one with PDN GW allocated in the Home PLMN. In this case PMIPv6 may be used on S5 between the Serving GW and the PDN GW in the Visited PLMN, but GTP could be used for the other PDN connection with PDN GW in the Home PLMN.

Again we show a few examples of S-NAPTR procedures. The detailed information can be found in TS 29.303. For 3GPP accesses:

When non-roaming and TAU procedure requires S-GW change, the S-GW selection function shall use the S-NAPTR procedure with the TAI FQDN to get the list of ‘candidate’ SGW ‘Service Parameters’ of

When roaming, the SGW selection is needed due to TAU procedure in the VPLMN, then the selection function for the S-NAPTR procedure shall use the TAI FQDN and ‘Service Parameters’ of

and make use of the operator’s preference for the roaming protocol (GTP/PMIP).

When non-roaming and additional PDN connection, the SGW is already selected (i.e. the UE has an existing PDN connection), the selection function shall use the S-NAPTR procedure with the APN-FQDN and ‘Service Parameters’ of

For non-3GPP access when the Serving GW acts as a local mobility anchor for non-3GPP access S8-S2a/b chained roaming, Serving GW selection is not specified and thus may be left to the vendor-specific implementation choice of a operator’s networks.

9.2.8 Handover (non-3GPP access) and PDN GW selection

Once the selection of PDN GW has occurred, the PDN Gateway identity is registered in the HSS so that it can be provided to the target access in case of an inter-access handover. The PDN GW identity registered in HSS can be either an IP address or a FQDN. Registering the PDN GW IP address is suitable in case the PDN GW only has a single IP address or can use the same IP address for all the mobility protocols it supports (or if it only supports one mobility protocol). Registering the FQDN is more flexible in the sense that it allows PDN GW to use multiple IP addresses depending on mobility protocol. So if a UE hands over from one access where PMIPv6 is used to another access where GTP is used, the PDN GW selection function could use the FQDN to derive different PDN GW IP addresses depending on mobility protocol.

In case the terminal activated the PDN connection in a non-3GPP access, it is the PDN GW that registers the PDN GW identity and its association with a UE and the APN in the HSS. For 3GPP access types, the MME/SGSN updates the HSS with the selected PDN GW identity. Once registered in the HSS, the HSS (possibly via 3GPP AAA Server or Proxy) can then provide the association of the PDN Gateway identity and the related APN for the UE later on. It can be noted that the PDN GW information is provided to target access only in case mobility is performed using a network based mobility protocols in the target access (PMIP and GTP). For handover to a non-3GPP access using DSMIPv6, it is instead the UE that knows the address of the PDN GW (Home Agent).

When the UE is moving between 3GPP and non-3GPP accesses, PDN Gateway selection information for the subscribed PDNs the UE has not yet connected to is returned to the target access system like during Initial Attach. For the PDNs the UE has already connected to, the PDN GW information is transferred as below:

1. If a UE hands over to a non-3GPP access using PMIPv6 in target access and it already has assigned PDN Gateway(s) due to a previous attach in a 3GPP access, the HSS provides the PDN GW identity for each of the already allocated PDN Gateway(s) with the corresponding PDN information to the 3GPP AAA server. The AAA server forwards the information to the PDN GW selection function in the target access.

2. If a UE hands over to a 3GPP access and it already has an assigned PDN Gateway(s) due to a previous attach in a non-3GPP access, the HSS provides the PDN GW identity for each of the already allocated PDN Gateway(s) with the corresponding PDN information to the MME.