5 Procedures for EPC Node Discovery and Selection

29.3033GPPDomain Name System ProceduresRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Procedures for Discovering and Selecting a PGW

5.1.1 Discovering a PGW for a 3GPP Access

5.1.1.1 General

The procedures here give a list of possible PGWs and their interfaces that serve a particular APN. This is very similar to the existing function that resolves the GGSN IP address based on an APN.

NOTE 1: The RAI/RNC-ID FQDN is used in addition to the APN FQDN when selecting the GGSN for SIPTO above RAN enabled APN. See clause 5.6.

However, the Release-8 behaviour includes more functionality than pre-Release-8 systems since the PGW now can support more than one protocol and there is sometimes a desire to have the PGW and SGW collocated or topologically close to each other (with respect to the network topology), if possible. New DNS records are required to distinguish between different protocols and interfaces and assist in the more complicated selections.

The operator shall provision the authoritative DNS server(s) responsible for the APN‑FQDN, including all derivatives used by the operator in the APN‑OI replacement field (as defined in 3GPP TS 23.060 [18] and 3GPP TS 23.401 [11])with NAPTR records for the given APN-FQDN and corresponding PGWs under the APN-FQDN.

See clause 19.4.2.2 of 3GPP TS 23.003 [4].

The above format is used in DNS for use in DNS queries by S4-SGSN and MME to networks with DNS provisioned to Release-8. A Release-8 SGSN only supporting Gn/Gp may also optionally use this procedure.

The DNS records provisioned at that location are NAPTR records and include all S5/S8 and Gn/Gp interfaces for PGW, GGSN, and collocated PGW/GGSN that are intended to be used for that APN.

When PGW-C/SMFs are deployed in a PGW-C/SMF set, as an operator option, one separate NAPTR DNS record may be provisioned for the PGW-C/SMF Set under the APN records of each APN supported by the PGW-C/SMF set (see example in Annex A.3.5); if so, in this DNS record, the NAPTR flag shall be set to "", and NAPTR "replacement" shall be set to the PGW Set FQDN as specified in clause 19.4.2.13 of 3GPP TS 23.003 [4]. An MME supporting the Restoration of PDN connections after a PGW-C/SMF Change procedure as specified in 3GPP TS 23.007 [31] shall be able to select a PGW-C/SMF from this PGW-C/SMF Set identified by the PGW Set FQDN as specified in clause 5.1.4.

NOTE 2: The provisioning of the above DNS record is not necessary to support restoring the PDN connections after a PGW-C/SMF change. This provisioning can allow an MME to select a PGW pertaining to a PGW-C/SMF set for a given APN during the initial PDN connection establishment.

The pre-Release-8 format APN as specified in clause 9.1 of 3GPP TS 23.003 [4] is still used in pre-Release-8 SGSN DNS queries and continues to be used as a fallback in Release-8 SGSN for discovering Gn/Gp interfaces.

The DNS records provisioned at that location are A and/or AAAA records but only for the Gn/Gp interfaces of a standalone GGSN or collocated PGW/GGSN.

The APN-FQDN is derived from the APN where the APN is typically in the legacy format of "<APN‑NI>.mnc<MNC>.mcc<MCC>.gprs" as specified in clause 9.1of 3GPP TS 23.003 [4].

NOTE 3: The APN-FQDN is used for DNS query purposes in Release-8. It does not imply a change in the use or format of the APN in other protocols, nodes or UE/MS. The APN-FQDN and the APN use independent formats but are related as below for DNS usage by the MME and S4-SGSN.

The APN received by the EPC node discovery function for 3GPP accesses, is always of the form of an APN-NI part and operator part. It is the output from Annex A of 3GPP TS 23.060 [18], which is exactly three labels with last label "gprs".

If the APN is constructed using the default APN-OI or using the APN-OI Replacement field (as defined in 3GPP TS 23.060 [18] and 3GPP TS 23.401 [11]), then the APN-FQDN shall be obtained from the APN as specified in clause 19.4.2.2.1 of 3GPP TS 23.003 [4], otherwise the APN is considered to be invalid and cannot be used.

In Annex A of 3GPP TS 23.060 [18] the SDL diagram refers to a "DNS interrogation" succeeding or failing which is the only DNS interaction. This is clarified as follows:

For the procedures defined in the present document the APN-FQDN shall be used in the S-NAPTR with a NAPTR query (see later clauses for details). If the S-NAPTR procedure succeeds the "DNS interrogation" succeeds. If the S-NAPTR procedure fails to find a PGW or collocated PGW/GGSN then the "DNS interrogation" fails.

For the legacy procedures defined in Annex A of 3GPP TS 23.060 [18] the unmodified APN shall be used in the DNS A query and DNS AAAA query. If either query succeeds, the "DNS interrogation" succeeds. If the A and AAAA queries both fail then the "DNS interrogation" fails.

The nodes responsible for the PGW selection (i.e. the MME or S4-SGSN) shall apply the additions specified in clause 4A, if GTP-C load control is supported and enabled.

5.1.1.2 Discovering a PGW or collocated PGW/GGSN for a 3GPP Access – S8/Gp roaming case existing PDN

This clause covers the case where the SGW or S4-SGSN is in the visiting network, the SGW is already pre-selected by having at least one existing PDN connection and a UE attempts to create a new PDN connection for a different APN to be selected in the home network.

Operators shall provision NAPTR records for each APN-FQDN that allows roaming with at least "Service Parameters" of

"x-3gpp-pgw:x-s8-gtp", "x-3gpp-pgw:x-s8-pmip", "x-3gpp-ggsn:x-gp", "x-3gpp-pgw:x-gp"

for each such supported interface of that type.

The S-NAPTR procedure, employed by the MME or S4-SGSN, to discover all S8interfaces shall use "Service Parameters" of

"x-3gpp-pgw:x-s8-gtp", "x-3gpp-pgw:x-s8-pmip""

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and set the Application-Unique String to the APN FQDN as defined in clause 19.4.2.2 of 3GPP TS 23.003 [4]. The "Service Parameter" of "x-3gpp-pgw:x-gp" shall be included if the MME or S4-SGSN wishes to potentially bias towards a collocated PGW/GGSN.

Additional requirements to support DCN are specified in clause 5.8.

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of candidate IPv4 and IPv6 addresses. This is a "candidate" list of PGW or collocated PGW/GGSN for that APN (see Annex C.2 for an informative description of a candidate list and Annex B for the S-NAPTR procedure).

The above procedure shall be used by the MME or S4-SGSN to select the PGW or collocated PGW/GGSN.

NOTE 1: When an LTE capable terminal is in GERAN/UTRAN access, the S4-SGSN might wish to preferentially select a node with both Gp and S8 (i.e. a co-located PGW/GGSN) based on an operator policy. A preference for a co-located PGW/GGSN may also exist in an LTE access based on operator policy. The MME, or Release-8 SGSN, may find co-located PGW/GGSN nodes by searching the APN "candidate" list for interfaces with the same canonical node name in a Gp interface host name and S8 interface host name.

The PGW and SGW cannot be collocated in this case since the SGW and PGW are in different operator networks. Furthermore, topological matching by DNS host names shall not be done since the host names are under different operators’ administrative control.

The Service Parameter of "x-3gpp-pgw:x-gp" denotes a collocated Release 8 GGSN function on a PGW. A PGW with a collocated Release 8 GGSN function may be preferred subject to operator policies. If that is the case the collocated PGW/GGSN nodes should be moved to the front of the candidate list but otherwise retaining the same relative order. The interfaces from the candidate list that are not S8 based shall be removed. The PGW S8 interfaces are tried in order from the candidate list.

NOTE 2: Contrary to the non-roaming case, in the roaming case the domain name of the SGW interface selected does not influence the PGW selection.

In the above procedure after the PGW has been contacted, the selected PGW node name, selected IP address, port (if non standard) and selected protocol type (GTPv2 vs. PMIP) shall be stored in the MME or S4-SGSN so it can be accessed on a PDN basis.

NOTE 3: In this release of 3GPP only standard ports are used.

3GPP TS 23.401 [11] currently indicates only one of PMIP or GTPv2 will be used based on roaming agreements so the above query would actually not require both gtp and pmip. The operator could use the order field in the NAPTR records to accomplish an optional fallback to the other protocol type.

Use cases where a SGW needs to be selected are covered in clause 5.2. However, since Gn/Gp access bypasses SGW selection completely both for subsequent PDP context activations and initial attach we note that special case here.

If the UE is in GERAN or UTRAN access and the Release 8 SGSN supports Gp, but not S4, the procedure above is modified as follows. The "Service Parameters" shall be

"x-3gpp-pgw:x-gp" , "x-3gpp-ggsn:x-gp"

Additional requirements to support DCN are specified in clause 5.8.

If an LTE capable mobile is in GERAN/UTRAN access a PGW with a collocated PGW/GGSN function may be preferred subject to operator policies. If that is the case the PGW/GGSN nodes should be moved to the front of the candidate list but otherwise retaining the same relative order. The rest of the procedure is the same as above.

If the APN record does not exist at the .3gppnetwork.org domain and the UE is in GERAN or UTRAN access and the Release 8 SGSN supports Gp then the pre Release-8 DNS procedures shall apply for the APN lookup by the Release 8 SGSN (i.e. APN lookup by A/AAAA records in the domain .gprs).

5.1.1.3 Discovering a PGW or collocated PGW/GGSN for a 3GPP Access – S5/Gn intra-operator existing PDN

Operators shall provision NAPTR records for each APN-FQDN for use within their network with at least "Service Parameters" of

"x-3gpp-pgw:x-s5-gtp", "x-3gpp-pgw:x-s5-pmip", "x-3gpp-ggsn:x-gn", "x-3gpp-pgw:x-gn"

for each such supported interface of that type.

Assuming the SGW is already pre-selected by having an existing PDN connection and a UE attempts to create a new PDN connection for a different APN in the user’s home network, then the MME or S4-SGSN shall perform the following procedure:

The S-NAPTR procedure, employed by the MME or S4-SGSN to discover S5 interfaces shall use "Service Parameters" of

"x-3gpp-pgw:x-s5-gtp", "x-3gpp-pgw:x-s5-pmip"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and set the Application-Unique String to the APN FQDN as defined in clause 19.4.2.2 of 3GPP TS 23.003 [4]. The "Service Parameter" of "x-3gpp-pgw:x-gn" shall be included if the MME or S4-SGSN wishes to potentially bias towards a collocated PGW/GGSN.

Additional requirements to support DCN are specified in clause 5.8.

Collocation and topological ordering between the PGW and SGW applies in this case.

If the existing SGW hostname has "topoff" then the candidate list of PGW shall be used in the order given to try to contact a PGW, after moving any colocated SGW/PGW to the front of the candidate list while maintaining relative order within that set.

The Service Parameter of "x-3gpp-pgw:x-gn" denotes a collocated Release 8 GGSN function on a PGW. A PGW with a collocated Release 8 GGSN function may be preferred subject to operator policies. If that is the case the collocated PGW/GGSN nodes should be moved to the front of the candidate list but otherwise retaining the same relative order. The interfaces from the candidate list that are not S5 based shall be removed. The PGW S5 interfaces are tried in order from the candidate list..

If the existing SGW hostname has "topon" the two candidate lists shall be used in the procedure in Annex C.4 with the PGW as "A" and the SGW as "B". Annex C.4 results in a list of PGW to try in order.

Once a PGW is successfully contacted the selected PGW host name, PGW IP address used, port (if non-standard) and selected protocol type (GTP vs PMIP) shall be stored in the MME or S4-SGSN so it can be accessed on a PDN basis.

NOTE 1: In this release of 3GPP only standard ports are used.

Use cases where a SGW needs to be selected are covered in clause 5.2 and clause 5.3. However, since Gn/Gp access bypasses SGW selection completely both for subsequent PDP context activations and initial attach we note that special case here.

If the UE is in GERAN or UTRAN access and the Release 8 SGSN supports Gn, but not S4, the procedure above is modified as follows. The "Service Parameters" shall be

"x-3gpp-pgw:x-gn" , "x-3gpp-ggsn:x-gn"

Additional requirements to support DCN are specified in clause 5.8.

NOTE 2: When the SGSN supports Gn selects the GGSN or collocated PGW/GGSN for SIPTO above RAN enabled APN, in addition to the APN FQDN, the S-NAPTR procedure use the "Service Parameters" of "x-3gpp-pgw:x-gn" , "x-3gpp-ggsn:x-gn", and set the Application-Unique String to the RAI FQDN as specified in clause 5.5.2 or the RNC-ID FQDN as specified in clause 19.4.2.7 of 3GPP TS 23.003 [4] . See clause 5.6.

If an LTE capable mobile is in GERAN/UTRAN access a PGW with a collocated PGW/GGSN function may be preferred subject to operator policies. A preference for a co-located PGW/GGSN may also exist in an LTE access based on operator policy. The MME, or Release-8 SGSN, may find co-located PGW/GGSN nodes by searching the APN "candidate" list for interfaces with the same canonical node name in a Gn interface host name and S5 interface host name. If that is the case the PGW/GGSN nodes should be moved to the front of the candidate list but otherwise retaining the same relative order. The rest of the procedure is the same as above.

If the APN record does not exist at the .3gppnetwork.org domain and the UE is in GERAN or UTRAN access and the Release 8 SGSN supports Gn then the pre Release-8 DNS procedures shall apply for the APN lookup by the Release 8 SGSN (i.e. APN lookup by A/AAAA records in the domain .gprs).

Those procedures apply also to the case of roaming with local breakout when subscription data and network policy allow selection of a PGW from the VPLMN (see e.g. clause 4.2.2 in 3GPP TS 23.401 [11]).

5.1.1.4 Discovering a PGW, collocated PGW/GGSN or GGSN for a 3GPP Access – S5/Gn intra-operator initial attach

During the initial attach and PDN connection creation using a 3GPP access both a PGW and an SGW need to be selected by an MME and will also be used by a S4-SGSN in PDP context creation. The discovery and selection procedures for cases employing a SGW are the same as for the PGW and the SGW discovery and selection procedure described in clause 5.3.

The discovery and selection procedures for a Release-8 SGSN selecting a Gn interface for PDP context creation are in clause 5.1.1.3.

5.1.2 Discovering a PGW for a non-3GPP Access with Network Based Mobility Management

5.1.2.1 Discovering a PGW for a non-3GPP Access – S2a/S2b initial attach for roaming and non-roaming

The MAG functionality or TWAN within the trusted non-3GPP IP access or the e-PDG shall use the S-NAPTR procedure with "Service Parameters" of

"x-3gpp-pgw:x-s2a-pmip", "x-3gpp-pgw:x-s2b-pmip", "x-3gpp-pgw:x-s2a-mipv4","x-3gpp-pgw:x-s2b-gtp",
"x-3gpp-pgw:x-s2a-gtp"

and the APN-FQDN as the Application-Unique String.

<APN-NI>.apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

See clause 19.4.2.2 of 3GPP TS 23.003 [4].

Additional requirements to support DCN are specified in clause 5.8.

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This is a "candidate" list of PGW for that APN (see Annex B for S-NAPTR procedure and see Annex C.2 for an informative description of a candidate list).

There is no requirement for selection for a collocated PGW/SGW in this procedure. In the above procedure, the selected PGW node name, port and selected type (PMIPv6, MIPv4 or GTP) shall be stored in the MAG functionality, TWAN or the ePDG so it can be accessed on a PDN basis.

The nodes responsible for the PGW selection (i.e. the TWAN or ePDG) shall apply the additions specified in clause 4A, if GTP-C load control is supported and enabled.

5.1.2.2 Discovering a PGW for a non-3GPP Access – S2a/S2b initial attach and chained PMIP-based S8-S2a/S2b

The MAG functionality within the trusted non-3GPP IP access or the e-PDG shall use the S-NAPTR procedure with the "Service Parameters" of

"x-3gpp-pgw:x-s2a-pmip", "x-3gpp-pgw:x-s2b-pmip"

and the APN-FQDN as the Application-Unique String.

<APN-NI>.apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

See clause 19.4.2.2 of 3GPP TS 23.003 [4].

The MAG selects a PGW based on the protocol type (GTP v/s PMIPv6) supported over the S5/ S8 interface based on information received over STa and SWm interfaces.

The PGW and SGW cannot be collocated in this case since the SGW and PGW are in different operator networks.

The DNS records in the order returned are then used to contact the PGW node.

The nodes responsible for the PGW selection (i.e. the TWAN or ePDG) shall apply the additions specified in clause 4A, if GTP-C load control is supported and enabled.

5.1.3 Discovering a PGW for a non-3GPP Access with DSMIPv6

5.1.3.1 Discovering a PGW for a non-3GPP Access – S2c initial attach

This clause covers the case where the IP address of the Home Agent (HA) functionality of a particular PGW needs to be discovered from the FQDN of the PGW. This query may be sent from a trusted access gateway or from an ePDG. The trusted access gateway or ePDG shall use the S-NAPTR procedure with "Service Parameters" of

"x-3gpp-pgw:x-s2c-dsmip"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the FQDN of the specific PGW.

The nodes responsible for the PGW selection (i.e. the TWAN or ePDG) shall apply the additions specified in clause 4A, if GTP-C load control is supported and enabled.

5.1.4 Discovering a PGW-C/SMF in a PGW-C/SMF Set

The DNS procedure specified in this clause shall be used by an MME to select an alternative PGW-C/SMF from a PGW-C/SMF Set during an MME triggered Restoration of a PDN connection after an PGW-C/SMF change, as specified in clause 31 of 3GPP TS 23.007 [31], if the MME did not receive Alternative PGW-C/SMF IP Addresses from the PGW for the PDN connection. Operators shall provision NAPTR records under the PGW Set FQDN (as defined in clause 19.2.4.13 of 3GPP TS 23.003 [4]) with at least "Service Parameters" of

"x-3gpp-pgw:x-s5-gtp", "x-3gpp-pgw:x-s8-gtp"

for each PGW-C/SMF within the PGW-C/SMF Set,

The MME shall discover the PGW-C/SMFs available within a PGW-C/SMF Set by initiating an S-NAPTR procedure, with the Application-Unique String set to the PGW Set FQDN, and with the "Service Parameters" set to e.g. "x-3gpp-pgw:x-s5-gtp" or "x-3gpp-pgw:x-s8-gtp".

The PGW Set FQDN shall be the PGW Set FQDN last received (over S5/S8 and S11 interfaces) from the PGW for the PDN connection.

The S-NAPTR procedure outputs a list of host names (PGWs) each with a service, protocol, port and a list of IPv4 and IPv6 addresses pertaining to the PGW-C/SMF set. See further details and examples in Annexes B, C and G.

5.2 Procedures for Discovering and Selecting a SGW

5.2.1 General

These procedures are employed when an SGW needs to be selected by an EPC core node and a PGW has already been selected. In particular for the tracking area update procedure with SGW change.

The SGW is selected based on the target cell where the UE has moved into. The MME has the new target eNodeB cell ID (eCID)/target eNodeB-ID and TAI available . The MME shall construct the TAI FQDN as defined in clause 19.4.2.3 of 3GPP TS 23.003 [4] and the MME shall construct the eNodeB-ID FQDN as defined in clause 19.4.2.10 of 3GPP TS 23.003 [4].

The selected SGW shall serve the UE’s TAI and/or eNodeB-ID. During the attach/TAU/Handover procedure the MME receives the TAI value and eNodeB-ID which is derived from the ECGI or received from the source MME/SGSN. The MME shall contruct the TAI FQDN as defined in clause 19.4.2.3 of 3GPP TS 23.003 [4] and eNodeB-ID FQDN as defined in clause 19.4.2.10 of 3GPP TS 23.003 [4].

Operators shall provision, for each TAI/eNodeB-ID value in their network, NAPTR records under the TAI/eNodeB-ID FQDN corresponding to each valid SGW interfaces from the following "Service Parameters"

"x-3gpp-sgw:x-s8-gtp", "x-3gpp-sgw:x-s8-pmip", "x-3gpp-sgw:x-s5-gtp", "x-3gpp-sgw:x-s5-pmip"

where additional "Service Parameters" may be included optionally.

Additional requirements to support DCN are specified in clause 5.8.

For each RAI/RNC-ID value that is served by a S4-SGSN the same records would be provisioned under the RAI FQDN (see clause 5.5.2 for the RAI FQDN) or the RNC-ID FQDN (see clause 19.4.2.7 of 3GPP TS 23.003 [4] for the RNC-ID FQDN).

The S-NAPTR procedure employed by an MME for finding a candidate set of SGW nodes shall use the TAI FQDN/eNodeB-ID FQDN as the Application-Unique String.

For the purposes of this document the NAPTR record-set at that location will be called the TAI/eNodeB-ID NAPTR record-set.

The MME selects the S11 interface of the SGW from the SGW’s canonical node record (see clause 4.3.3) if it is not obtained from the TAI/eNodeB-ID records.

NOTE: If an operator does not use the "a" and "s" flags in the TAI/eNodeB-ID NAPTR records (i.e. they use the "" flag) and they are using SGW service areas it is strongly recommended that the TAI/eNodeB-ID NAPTR records point directly to NAPTR records representing the SGW service areas. This is to facilitate possible future use in the SGW Load Re-balancing procedure.

For the case of an S4-SGSN making the SGW selection the RAI FQDN (see clause 5.5.2) or the RNC-ID FQDN (see clause 19.4.2.7 of 3GPP TS 23.003 [4] for the RNC-ID FQDN ) is used instead of the TAI FQDN or the eNodeB-ID FQDN to select the SGW but is otherwise the same as the MME handling TAU. The S4-SGSN selects the S4 interface of the SGW from the SGW’s canonical node record (see clause 4.3.3) if it is not obtained from the RAI/RNC-ID records.

S-GW selection when SGW that acts as a local anchor for non-3GPP access in the case of S8-S2a/b chained roaming is outside the scope of this specification.

The nodes responsible for the SGW selection (i.e. the MME or S4-SGSN) shall apply the additions specified in clause 4A, if GTP-C load control is supported and enabled.

5.2.2 SGW Selection during TAU or RAU with SGW change – 3GPP roaming case

For the roaming case the type of protocol (PMIP vs. GTP) is chosen based on a roaming agreement according to 3GPP TS 23.401 [11]. The MME shall therefore use the S-NAPTR procedure with "Service Parameters" of

"x-3gpp-sgw:x-s8-gtp" or "x-3gpp-sgw:x-s8-pmip"

Additional requirements to support DCN are specified in clause 5.8.(based on whetherGTP v2 or PMIPv6 is used for the current PDN connection)

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and possibly restricted based ona roaming agreement to use only GTPv2 or PMIPv6 and set the Application-Unique String to the TAI FQDN as defined in clause 19.4.2.3 of 3GPP TS 23.003 [4] or the eNodeB-ID FQDN as defined in clause 19.4.2.10 of 3GPP TS 23.003 [4].

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This is a "candidate" list of SGW for that TAI/eNodeB-ID (see Annex B for S-NAPTR procedure and see Annex C.2 for an informative description of a candidate list).

If the first choice protocol (PMIP or GTPv2) fails the second choice MAY be tried subject to the operators’ roaming agreements.

Neither collocation of PGW and SGW nor topological ordering rules apply in this case.

The present clause to this point implicitly assumes only one PDN connection is currently employed by a UE which may not be the case with multiple PDN connections for the same UE. All PDN connections after the TAU must be on the same SGW since there is only one SGW at a time for a UE.

If an existing PDN for the UE is PMIPv6 S8 and some existing PDN for the UE is GTPv2 S8 then a SGW supporting both protocols is required. If that occurs and there are no such SGW then the PDN connections with the least important retention (from the ARP value) would have to be dropped until a list of viable SGW of one protocol meeting the retention policies is found. If there are non viable SGW they are removed from the original SGW candidate list. After this point the SGW candidate list order is used in the same way as it was in the case of only one PDN connection.

Once an SGW is successfully contacted the selected SGW host name, selected SGW IP address, selected port (if non-standard) and selected protocol type (GTPv2 vs. PMIP – which is unchanged here) shall be stored in the MME so it can be accessed on a PDN basis.

NOTE 1: In this release of 3GPP only standard ports are used.

For the case of an S4-SGSN making the SGW selection the RAI FQDN (see clause 5.5.2) or the RNC-ID FQDN (see clause 19.4.2.7 of 3GPP TS 23.003 [4] for the RNC-ID FQDN) is used instead of the TAI/eNodeB-ID FQDN to select the SGW but is otherwise the same as the MME handling TAU. The S4-SGSN selects the S4 interface of the SGW from the SGW’s canonical node record (see clause 4.3.3) if it is not obtained from the RAI/RNC-ID records.

NOTE 2: A SGW will need to be selected at a handover attach from another access type. The SGW selection method is the same as presented here since there are existing PDN connections (typically PMIPv6 for non-3GPP accesses).

5.2.3 SGW Selection during TAU or RAU with SGW change – non-roaming case

This differs from the 3GPP roaming case in 5.2.2 primarily in that the PGW and the SGW are in the same network. Hence, there is a need to be able of selecting a SGW collocated with the PGW or a topologically close SGW. The current PGW’s node name should previously have been stored in the MME or S4-SGSN when the default bearer was established or transported from the old MME to the new MME, and is therefore available for comparison.

For the non-roaming case the S-NAPTR procedure shall be initiated with "Service Parameters" of

"x-3gpp-sgw:x-s5-gtp" and/or "x-3gpp-sgw:x-s5-pmip"

Additional requirements to support DCN are specified in clause 5.8.(based on whether GTPv2 or PMIPv6 is used for the current PDN connection)

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and set the Application-Unique String to the TAI FQDN as defined in clause 19.4.2.3 of 3GPP TS 23.003 [4]. The Application-Unique-String may be set to the eNodeB-ID FQDN as defined in clause 19.4.2.10 of 3GPP TS 23.003 [4] as an operator specific deployment option.

Collocation of PGW and SGW and topological ordering rules both apply in this case.If the existing PGW hostname for the PDN has "topoff" then the "candidate" list of SGW would be used in the order given to try to contact a SGW after moving the PGW with the same SGW node name to the front of the list keeping relative order.

If the existing PGW hostname has "topon" the two candidate lists shall be used in the procedure in Annex C.4 with the SGW as "A" and the PGW as "B". Annex C.4 results in a list of SGW to try in order.

The present clause to this point implicitly assumes only one PDN connection is currently employed by a UE which may not be the case with multiple PDN connections for the same UE.

If an existing PDN for the UE is PMIPv6 S5 and some existing PDN for the UE is GTPv2 S5 then a SGW supporting both protocols is required. If that occurs and there are no such SGW then the PDN connections with the least important retention (from the ARP value) would have to be dropped until a list of viable SGW of one protocol meeting the retention policies is found. If there are non viable SGW they are removed from the original SGW candidate list. After this point the SGW candidate list order is used in the same way as it was in the case of only one PDN connection.

After this point it is a matter of operator policy or vendor implementation which PDN or PDNs (and hence their corresponding PGW canonical node names) are used for selecting the corresponding best SGW interface.

NOTE 1: One possible option would be as follows. First try to maximize the number of PDN connections that are on PGW colocated on the same viable SGW. If there are no collocated choices the PGW giving the closest topological match to any viable SGW are used. If they are all equal then SGW ordering from the SGW candidate list is used. This approach would be very similar, but not identical, to passing the list of PGW being used as list "B" and the SGW candidate list with only viable SGW as list "A’ in the procedure in Annex C.4

Once an SGW is successfully contacted the selected SGW host name, SGW IP address used, port (if non-standard) and selected type (GTP vs PMIP) shall be stored in the MME so it can be accessed on a PDN basis.

NOTE 2: In this release of 3GPP only standard ports are used.

For the case of an S4-SGSN making the SGW selection the RAI FQDN (see clause 5.5.2) is used or as an operator deployment option the Application-Unique-String may be set to the RNC-ID FQDN as defined in clause 19.4.2.7 of 3GPP TS 23.003 [4] instead of the TAI/eNodeB-ID FQDN to select the SGW but is otherwise the same as the MME handling for TAU. The S4-SGSN selects the S4 interface of the SGW from the SGW’s canonical node record (see clause 4.3.3) if it is not obtained from the RAI or RNC-ID records.

NOTE 3: A SGW will need to be selected at a handover attach from another access type. The SGW selection method is the same as presented here since there are existing PDN connections (typically PMIPv6 for non-3GPP accesses).

NOTE 4: eNodeB-ID and RNC-ID FQDN are only employed by Release 10 or onwards MME/SGSNs for SGW selection.

5.2.4 SGW Selection during non-3GPP handover to 3GPP access

The SGW selection is similar with other cases. For the non-roaming case, there is a need of selecting a SGW collocated with the PGW or a topologically close SGW. The current PGW’s node name should previously have been stored in the HSS and would be sent to the MME during the access authentication procedure and is therefore available for comparison.

The S-NAPTR procedure for SGW Selection is same as clause 5.2.2 for roaming case, and is same as clause 5.2.3 for non-roaming case.

5.3 Procedures for Discovering and Selecting a PGW and SGW

This scenario applies to the UE initial attach and PDP context activation cases, where the MME or S4-SGSN has not yet assigned a PGW or a SGW to the UE. During the attach procedures, the MME shall select the SGW and the PGW as described below. During the UTRAN/GERAN PDP context activation procedure, the S4-SGSN shall select the SGW and the PGW as described below.

NOTE 1: The procedure specified in this clause is not applied for the LGW selection for LIPA service or for SIPTO at the local network with LGW collocated with (H)(e)NB. The MME/S4 SGSN uses the LGW address proposed by the (H)(e)NB in the S1-AP/RANAP message as specified in 3GPP TS 36.413 [19] and 3GPP TS 25.413 [12] to select the appropriate LGW for LIPA service or for SIPTO at the local network with LGW collocated with (H)(e)NB.

For SIPTO at the local network with stand-alone GW, the SGW shall be selected based on the < LHN name> provided by the (H)(e)NodeB during the attach or SIPTO at local network PDN connection creation. The MME shall construct the Local Home Network-ID FQDN defined in clause 19.4.2.11 of 3GPP TS 23.003 [4].

The selected SGW shall serve the UE’s TAI/eNodeB-ID. During the attach procedure the MME receives the TAI value and eNodeB-ID which is derived from the ECGI. The S-NAPTR procedure to obtain a list of "candidate" SGW shall be used with "Service Parameters" of

"x-3gpp-sgw:x-s5-gtp", "x-3gpp-sgw:x-s5-pmip"

Additional requirements to support DCN are specified in clause 5.8.as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and set the Application-Unique String set to the TAI FQDN as defined in clause 19.4.2.3 of 3GPP TS 23.003 [4] or as an operator specific deployment option the Application-Unique-String may be set to the eNodeB-ID FQDN as defined in clause 19.4.2.10 of 3GPP TS 23.003 [4]. For SIPTO at the Local Network with stand-alone GW the Local Home Network ID as defined in clause 19.4.2.11 of 3GPP TS 23.003 [4] shall be used to select the SGW.

The S-NAPTR procedure logically outputs a list of host names each coupled with a service, a protocol, a port, and a list of IPv4 and IPv6 addresses. This is the "candidate" list of SGWs for a specific TAI/eNodeB-ID (see Annex B for S-NAPTR procedure and see Annex C.2 for an informativedescription of the candidate list).

The list of "candidate" PGW is obtained as follows:

The S-NAPTR procedure to get the list of "candidate" PGW shall use "Service Parameters" of

"x-3gpp-pgw:x-s5-gtp", "x-3gpp-pgw:x-s5-pmip", "x-3gpp-pgw:x-gn"

Additional requirements to support DCN are specified in clause 5.8.

as defined in clause 19.4.3 of 3GPP TS 23.003 [4], and the Application-Unique String set to the APN FQDN as defined in clause 19.4.2.2 of 3GPP TS 23.003 [4].

The S-NAPTR procedure logically outputs a list of host names each coupled with a service, a protocol, a port, and a list of IPv4 and IPv6 addresses. This is the "candidate" list of PGWs for a specific APN (see Annex C.2 for a detailed description of a candidate list).

The two candidate lists shall be used in the procedure described in Annex C.4 with the SGW as an "A" node type and the PGW as a "B" node type in the procedure.

The procedure described in Annex C.4 results in a selection of a SGW and a PGW along with the protocol, the IP address and the port. In the case of a failure to contact the SGW or the PGW, the required gateway reselection procedures are described in Annex C.4.

The MME selects the S11 interface of the SGW from the SGW’s canonical node record (see clause 4.3.3) if it is not obtained from the TAI records.

NOTE 2: The MME (S4-SGSN) send a GTPv2 Create Session Request to the SGW respectively over S11 or S4 with the IPv4/IPv6 address of the PGW. After the SGW has been successfully contacted over S11 or S4, the SGW can try to contact the PGW over S5/S8.

Once the SGW has successfully been contacted, the selected SGW host name, the used SGW IP address, the port number and the selected protocol type shall be stored in the MME or S4-SGSN per PDN.

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 shall be stored in the MME or S4-SGSN per PDN.

For the case of an S4-SGSN making the selection the RAI FQDN is used, or as an operator deployment option the Application-Unique-String may be set to the RNC-ID FQDN as defined in clause 19.4.2.7 of 3GPP TS 23.003 [4] instead of the TAI FQDN/eNodeB-ID FQDN to select the SGW but is otherwise the same as an MME doing the selection. The S4-SGSN selects the S4 interface of the SGW from the SGW’s canonical node record (see clause 4.3.3) if it is not obtained from the RAI or RNC-ID records.

The nodes responsible for the SGW and PGW selection (i.e. the MME or S4-SGSN) shall apply the additions specified in clause 4A, if GTP-C load control is supported and enabled.

5.4 Procedures for Discovering and Selecting an MME

These procedures can be used as part of:

– the ‘Inter eNodeB handover with MME relocation’ procedure to select an MME;

– the RAN Information Management (RIM) procedure to select an MME;

– UTRAN/GERAN to E-UTRAN SRVCC procedure to select an MME as specified in 3GPP TS 23.216 [20];

– IMSI and APN Information retrieval procedure for RAN User Plane Congestion mitigation to select an MME as specified in clause 5.9.3 of 3GPP TS 23.401[11];

– NAS Message Redirection procedure to retrieve the MMEGI identifying the DCN serving a particular UE usage type as specified in 3GPP TS 23.401[11];

– 5GS to EPS handover using N26 interface to select an MME, as specified in clause 4.11.1.2.1 of 3GPP TS 23.502 [29]; or

– EPS to 5GS handover using N26 interface to select an AMF, as specified in clause 4.11.1.2.2 of 3GPP TS 23.502 [29].

In the ‘Inter eNodeB handover with MME relocation’ procedure, the ‘UTRAN Iu mode to E-UTRAN Inter RAT handover’ procedure, the ‘GERAN A/Gb mode to E-UTRAN Inter RAT handover’ procedure, the ‘UTRAN/GERAN to E-UTRAN SRVCC’ procedure, the 5GS to EPS handover using N26 interface, the MME is selected based on the target cell where the UE is expected to move into. The MME has the new target eNodeB cell ID (eCID) and TAI available. The TAI includes the TAC, the MNC and the MCC.

In the EPS to 5GS handover using N26 interface procedure, the AMF is selected based on the target 5GS TAI received from the source eNB. The 5GS TAI includes the 5GS TAC, the MNC and the MCC.

In the ‘IMSI and APN Information retrieval’ procedure, the MME is selected based on the TAI of the cell or eNodeB that is congested in the user plane. The RCAF has the congested eNodeB cell ID (eCID) and TAI available. The TAI includes the TAC, the MNC and the MCC.

The S-NAPTR procedure for finding a candidate set of MME nodes for a target TAI is always started at the TAI FQDN as defined in clause 19.4.2.3 of 3GPP TS 23.003 [4]. The S-NAPTR procedure performed at the source MME/S4-SGSN/AMF for finding a candidate set of target MME nodes is started with at least the "Service Parameters" of

"x-3gpp-mme:x-s10"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4].

The S-NAPTR procedure for finding a candidate set of AMFs for a target 5GS TAI shall be started at the 5GS TAI FQDN as defined in clause 28.3.2.6 of 3GPP TS 23.003 [4]. The S-NAPTR procedure performed at the source MME for finding a candidate set of target AMF nodes is started with at least the "Service Parameters" of

"x-3gpp-mme:x-s10"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4].

Additional requirements to support DCN are specified in clause 5.8.

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This is a "candidate" list of MMEs (or AMFs) for that TAI (or 5GS TAI) (see Annex C.2 for a more detailed description of a candidate list).

Topological closeness shall not be used for the MME selection so the MME candidate list would be used in the order given to try to contact a MME.

NOTE 1: The source MME/S4-SGSN may wish to preferentially select a target MME that is co-located with a SGSN function based on an operator policy. The S-NAPTR procedure using the canonical node name (clause 4.3.3) may be used to find any co-located SGSN interfaces in the candidate list. Optionally an operator may provision NAPTR records with "x-3gpp-sgsn:x-gn" and/or "x-3gpp-sgsn:x-s4" at the TAI FQDN to allow an MME to directly get a candidate list for the co-located SGSN and hence for the source MME to match node names from the hostnames in the two candidate lists.

NOTE 2: If an operator does not use the "a" and "s" flags in the TAI NAPTR records (i.e. they use the "" flag) it is strongly recommended that the TAI NAPTR records point directly to NAPTR records at mmegi<MMEGI>.mme.epc.mnc<mnc>. mcc<mcc>.3gppnetwork.org (i.e. an MME pool )

NOTE 3: The above procedures for discovering and selecting an AMF are identical to the procedures specified for discovering and selecting an MME but using a 5GS TAI FQDN instead of a TAI FQDN; they can be used by MMEs not upgraded to support the procedure specified in clause 5.4A, during an EPS to 5GS handover using N26 interface. In this case, AMFs are provisioned in DNS as MMEs, following the mapping rules specified for EPS interworking with 5GS in clause 2.10.2 of 3GPP TS 23.003 [4].

For an S4-SGSN making the selection the "Service Parameter" of "x-3gpp-mme:x-s3" shall be employed instead of "x‑3gpp-mme:x-s10".

Additional requirements to support DCN are specified in clause 5.8.

For an MSC making the selection the "Service Parameter" of "x-3gpp-mme:x-sv" shall be employed instead of "x‑3gpp-mme:x-s10".

For an RCAF making the selection of an MME the "Service Parameter" of "x-3gpp-mme:x-nq" shall be employed.

An SGSN supporting only Gn/Gp may also optionally use this procedure with "Service Parameter" of "x-3gpp-mme:x-gn" in the ‘3G Gn/Gp SGSN to MME Combined Hard Handover and SRNS Relocation’ procedure as specified in Annex D.3.4 of 3GPP TS 23.401 [11] .

Additional requirements to support DCN are specified in clause 5.8.

NOTE 4: The SGSN supporting only Gn/Gp need map the eNodeB id to the RNC id to avoid updating the Target ID IE in the GTPv1 Forward Relocation Request message.

For the case when a UE is moving from a pre-Release-8 UTRAN/GERAN to an MME the pre‑Release‑8 source node will not be able to use the .3ggpnetwork.org based records. As a result the MME being selected looks like a pre-Release‑8 SGSN to a pre-Release-8 node performing a selection. For pre-Release 8 compatibility, operators would continue to provision A/AAAA records as per Annex C.1 of 3GPP TS 23.003 [4] for the corresponding MME Gn/Gp interfaces under the RNC-ID corresponding to the mapped targed ID value (see clause D.3.4 of 3GPP TS 23.401 [11] and clause 5.5.3 of the present document).

In the RAN Information Management (RIM) procedure, the MME is selected based on the Target eNodeB Identifier specifed by source RAN node.

5.4A Procedures for Discovering and Selecting an AMF with N26 interface

These procedures can be used as part of:

– EPS to 5GS handover using N26 interface to select an AMF, as specified in clause 4.11.1.2.2 of 3GPP TS 23.502 [29].

In the EPS to 5GS handover using N26 interface procedure, the AMF is selected based on the target 5GS TAI received from the source eNB. The 5GS TAI includes the 5GS TAC, the MNC and the MCC.

"x-3gpp-amf:x-n26"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4].

Additional requirements to support DCN are specified in clause 5.8.

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This is a "candidate" list of AMFs for that 5GS TAI (see Annex C.2 for a more detailed description of a candidate list).

5.4B Procedures for Discovering and Selecting an MME_SRVCC

These procedures can be used as part of:

– 5G-SRVCC from NG-RAN to UTRAN procedure to select an MME_SRVCC, as specified in clause 6.5 of 3GPP TS 23.216 [20].

In the 5G-SRVCC from NG-RAN to UTRAN procedure, the MME_SRVCC is selected based on the Target ID received from the source NG-RAN. The Target ID includes the Target RNC ID.

The S-NAPTR procedure for finding a candidate set of MME_SRVCCs for a Target RNC ID shall be started at the Target RNC ID for UTRAN FQDN as defined in clause 19.4.2.7 of 3GPP TS 23.003 [4]. The S-NAPTR procedure performed at the source AMF for finding a candidate set of target MME_SRVCC nodes is started with at least the "Service Parameters" of

"x-3gpp-mme:x-s10"

as defined in clause 19.4.3 of 3GPP TS 23.003 [4].

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This is a "candidate" list of MME_SRVCCs for that Target RNC ID (see Annex C.2 for a more detailed description of a candidate list).

5.5 Procedures for Discovering and Selecting an SGSN

5.5.1 General

These procedures are employed:

– when a target SGSN that serves the target cell or RNC needs to be initially selected by an EPC core node or Release-8 SGSN or an MSC. It explicitly does not cover selection of an SGSN by a RNC or BSS;

– as part of the UTRAN/GERAN to UTRAN (HSPA) SRVCC procedure to select an SGSN as specified in 3GPP TS 23.216 [20]; or

– for APN Information retrieval procedure for RAN User Plane Congestion mitigation to select an SGSN as specified in clause 6.17 of 3GPP TS 23.060[18].

– NAS Message Redirection procedure to retrieve Null-NRI or the SGSN Group ID identifying the DCN serving a particular UE usage type as specified in 3GPP TS 23.401[11].

Clause 4.3.3.5 "Services of an SGSN from a P-TMSI" specifies how a target MME/S4-SGSN discovers the IP address of the source SGSN during Idle Mode Mobility from GERAN /UTRAN.

EPC core nodes, i.e. the MME and the S4-SGSN employ the procedures below during the SRNS relocation procedure and the RAN Information Management (RIM) procedure. A Release‑8 SGSN supporting only Gn/Gp may also optionally use this procedure. An MSC supporting UTRAN/GERAN to UTRAN (HSPA) SRVCC procedure to select an SGSN may also use this procedure as specified in 3GPP TS 23.216 [20].

The SGSN is selected based on information in the Target ID (see 3GPP TS 23.003 [4] and 3GPP TS 25.413 [12]). For PS GERAN the Target ID has the global cell ID including PLMN and for U-TRAN the Target ID has RAC, RNC-ID and PLMN.

For the Fallback to GTPv1 scenario as specified in 3GPP TS 29.274 [23] clause 7.10, the new SGSN/MME shall send the related GTPv1 request message with the peer SGSN IP address on the Gn/Gp interface after receiving the GTPv2 response message with Cause "Fallback to GTPv1". The new MME/SGSN shall make another DNS query to obtain the peer SGSN IP address on the Gn/Gp interface if that address is not available. The A/AAAA query shall be used to obtain the peer SGSN IP address on the Gn/Gp interface.

5.5.2 SGSN initial target selection based on RAI (UTRAN target/GERAN Iu mode target/GERAN Gb mode target)

In both U-TRAN and GERAN cases the target RAC, LAC, MNC, and MCC are available from the information in the Target ID. This selection is done by an MME or Release-8 SGSN during SRNS relocation procedures and the RAN Information Management (RIM) procedures.

The S-NAPTR procedure for an MME/SGSN finding a candidate set of SGSN services and interfaces serving the target Routing Area is started with "Service Parameters" of

"x-3gpp-sgsn:x-gn", "x-3gpp-sgsn:x-gp", "x-3gpp-sgsn:x-s3","x-3gpp-sgsn:x-nqprime"

Additional requirements to support DCN are specified in clause 5.8.

as defined in 3GPP TS 23.003 [4] and setting the Application-Unique String to the RAI FQDN based on RAC, LAC, MNC, MCC as defined in 3GPP TS 23.003 [4] clause 19.4.2.5:

rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>. mcc<MCC>.3gppnetwork.org

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This is a "candidate" list of SGSN for that RAI (see Annex B for S-NAPTR procedure and see Annex C.2 for a more informative description of a candidate list).

NOTE 1: In the SRNS relocation procedure, for an MME making the selection there is an existing PDN connection (and hence an existing SGW) so the S3 interfaces would logically be preferred over the Gn/Gp interfaces to keep the existing PDN connection. However, if there is a colocated PGW/GGSN being employed with the 3GPP TS 23.401 [11] Annex D procedures then the Gn/Gp interfaces on the target SGSN can also be valid. Operators should prioritize the DNS records according to their preference.

For an S4-SGSN making the selection the "Service Parameter" of "x-3gpp-sgsn:x-s16" shall be employed instead of "x-3gpp-sgsn:x-s3".

Additional requirements to support DCN are specified in clause 5.8.

For an MSC making the selection the "Service Parameter" of "x-3gpp-sgsn:x-sv" shall be employed instead of "x‑3gpp-sgsn:x-s3".

For an RCAF making the selection of an SGSN the "Service Parameter" of "x-3gpp-sgsn:x-nqprime" shall be employed.

A Release 8 SGSN supporting only Gn/Gp may also optionally use this procedure with "Service Parameters" of "x‑3gpp-sgsn:x-gn" and "x-3gpp-sgsn:x-gp".

Additional requirements to support DCN are specified in clause 5.8.

Operators shall provision, for each RAI value in their network, NAPTR records under the RAI FQDN corresponding to each valid SGSN interfaces from at least the following "Service Parameters"

"x-3gpp-sgsn:x-gn", "x-3gpp-sgsn:x-gp", "x-3gpp-sgsn:x-s3","x-3gpp-sgsn:x-s16", "x-3gpp-sgsn:x-nqprime"

Additional requirements to support DCN are specified in clause 5.8.

where NAPTR records for additional "Service Parameters" may be included optionally.

NOTE 2: The NAPTR record at the RAI FQDN can be provisioned to correspond to only the default SGSN node(s) in the SGSN pool(s) serving that RAI. The default SGSN after the DNS procedure exits would be contacted with GTP, the default SGSN then selects the actual SGSN within that SGSN pool. This results in all relocation requests being handled by the default SGSN nodes. If the operator’s goal is to avoid load on the default SGSN nodes then the records provisioned at the RAI FQDN should instead include the entire set of SGSN in all SGSN pools that service that RAI. The S-NAPTR procedure would then return each SGSN in the SGSN pool based on the provisioned DNS weights and priority.

NOTE 3: The NAPTR record at the RAI FQDN for the service parameter of "x-3gpp-sgsn:x-nqprime" is provisioned with the entire set of SGSN in all SGSN pools that are serving that RAI.

NOTE 4: The SGSN(s) closest to the geographical region covered by the RAI can be biased by provisioning the DNS records with higher priority or weights.

3GPP does not require that collocation and "topon" naming is applicable in SGSN selection.

NOTE 5: Service parameters are limited to those supported by the node doing the search.

NOTE 6: SGW records will also be provisioned under the RAI FQDN see clause 5.2

In the SRNS relocation procedure, for the case when a UE is moving from a pre-Release-8 UTRAN/GERAN to a Release-8 target SGSN the pre‑Release‑8 source node will not be able to use the .3ggpnetwork.org based records. As a result the Release 8 SGSN (or MME) being selected looks like a pre-Release 8 SGSN to a pre-Release-8 node performing a selection. For pre-Release 8 compatibility operators would continue to provision A/AAAA records as per Annex C.1 of 3GPP TS 23.003 [4] for the corresponding Gn/Gp interfaces regardless of whether the SGSN is pre-Release-8 or not. Vendors shall support pre-Release 8 DNS procedures on Release 8 SGSN.

In the RAN Information Management (RIM) procedure, the SGSN is selected based on the RAI specifed by source RAN node.

5.5.3 SGSN initial target selection based on RNC-ID (UTRAN target/GERAN Iu mode target)

NOTE 1: In the SRNS relocation procedure, the finer granularity this procedure allows only applies to UTRAN/GERAN Iu mode and only when different RNC-IDs have the same RAI values.

This procedure is used for a UTRAN/GERAN Iu mode target in the SRNS relocation procedure and the RAN Information Management (RIM) procedure.

In UTRAN/GERAN Iu mode case the target RNC-ID, MNC, and MCC are available from the information in the Target ID.

The S-NAPTR procedure for an MME/S4- SGSN finding a candidate set of SGSN services and interfaces serving the target RNC is started with "Service Parameters" of

"x-3gpp-sgsn:x-gn", "x-3gpp-sgsn:x-gp", "x-3gpp-sgsn:x-s3"

Additional requirements to support DCN are specified in clause 5.8.

as defined in 3GPP TS 23.003 [4] and setting the Application-Unique String to the RNC-ID FQDN based on RNC‑ID,MNC,MCC as defined in 3GPP TS 23.003 [4] clause 19.4.2. 5.

The S-NAPTR procedure logically outputs a list of host names each with a service, protocol, port and a list of IPv4 and IPv6 addresses. This is a "candidate" list of SGSN for that RNC-ID (see Annex B for S-NAPTR procedure and see Annex C.2 for a more informative description of a candidate list).

NOTE 2: In the SRNS relocation procedure, for an MME making the selection there is an existing PDN connection (and hence an existing SGW) so the S3 interfaces would logically be preferred over the Gn/Gp interfaces to keep the existing PDN connection. However, if there is a colocated PGW/GGSN being employed with the 3GPP TS 23.401 [11] Annex D procedures then the Gn/Gp interfaces on the target SGSN can also be valid. Operators should prioritize the DNS records accordingly.

For an S4-SGSN making the selection the "Service Parameter" of "x-3gpp-sgsn:x-s16" shall be employed instead of "x‑3gpp-sgsn:x-s3".

Additional requirements to support DCN are specified in clause 5.8.

For an MSC making the selection the "Service Parameter" of "x-3gpp-sgsn:x-sv" shall be employed instead of "x‑3gpp-sgsn:x-s3".

A Release 8 SGSN supporting only Gn/Gp may also optionally use this procedure with "Service Parameters" of "x‑3gpp-sgsn:x-gn" and "x-3gpp-sgsn:x-gp". Additional requirements to support DCN are specified in clause 5.8. If there are no NAPTR records at that RNC-ID then the RAI based lookup in clause 5.5.2 shall be used as a fallback.

Operators using this feature shall provision, for each RNC-ID value in their network, NAPTR records under the RNC-ID FQDN corresponding to each valid SGSN interfaces from the following "Service Parameters"

"x-3gpp-sgsn:x-gn", "x-3gpp-sgsn:x-gp", "x-3gpp-sgsn:x-s3", "x-3gpp-sgsn:x-s16",

Additional requirements to support DCN are specified in clause 5.8.

where NAPTR records for additional "Service Parameters" may be included optionally.

Operators not using this feature shall not provision the RNC-ID records.

NOTE 3: The NAPTR record at the RNC-ID FQDN can be provisioned to correspond to only the default SGSN node(s) in the SGSN pool(s) serving that RNC. The default SGSN after the DNS procedure exits would be contacted with GTP, the default SGSN then selects the actual SGSN within that SGSN pool. This results in all relocation requests being handled by the default SGSN nodes. If the operator’s goal is to avoid load on the default SGSN nodes then the records provisioned at the RNC-ID FQDN should instead include the entire set of SGSN in all SGSN pools that service that RNC. The S-NAPTR procedure would then return each SGSN in the SGSN pool based on the provisioned DNS weights and priority.

NOTE 4: The SGSN(s) closest to the geographical region serving the RNC can be biased by provisioning the DNS records with higher priority or weights.

3GPP does not require that collocation and "topon" naming is applicable in SGSN selection.

NOTE 5: Service parameters are limited to those supported by the node doing the search.

In the SRNS relocation procedure, for the case when a UE is moving from a pre-Release-8 UTRAN/GERAN to a Release-8 target SGSN the pre‑Release‑8 source node will not be able to use the .3ggpnetwork.org based records. As a result the target Release‑8 SGSN (or MME) looks like a pre‑Release‑8 SGSN to a pre-Release‑8 source node. For pre-Release 8 compatibility operators would continue to provision A/AAAA records as per Annex C.3 of 3GPP TS 23.003 [4] for the corresponding Gn/Gp interfaces regardless of whether the target SGSN is pre‑Release‑8 or not. Vendors shall support pre-Release 8 DNS procedures on Release 8 SGSN.

In the RAN Information Management (RIM) procedure, the SGSN is selected based on the RNC-ID specifed by source RAN node.

5.5.4 Void

5.6 GW Selection for SIPTO

5.6.1 SIPTO above RAN

DNS procedures defined in the clause 5 in this specification also apply for the GW selection for SIPTO service.

The S-NAPTR based selection of the SGW (based on TAI, eNodeB-ID, RAI, or RNC-ID) gives the shortest user plane path from the UE to the SGW from the S-NAPTR ordering. Topological naming should be employed (as specified in clause 4.3.2) to find the shortest user plane path from the SGW to the PGW based on the topological closeness. With this approach, the MME or SGSN can select an SGW and PGW to achieve the shortest user plane path to the UE for a SIPTO enabled APN.

The S-NAPTR based selection of the GGSN gives the shortest user plane path from the UE to the GGSN from the S-NAPTR ordering. When the network supports Direct Tunnel, separate S-NAPTR procedures should be used, with APN FQDN and then with RAI FQDN or RNC-ID FQDN, to retrieve a list of candidates respectively, the common one from the S-NAPTR ordering should be selected.

5.6.2 SIPTO at the local network with LGW collocated with the (H)(e)NB

The LGW shall reside in the local network and be collocated with the (H)(e)NB. The MME/SGSN shall use the LGW address proposed by the (H)(e)NB in the S1-AP/RANAP message, instead of selecting the PGW via DNS interrogation as specified in clause 5.

The SGW shall remain in the mobile operator’s core network, i.e. collocation of the SGW and LGW is not applicable.

DNS procedures defined in the clause 5 in this specification apply for the SGW selection (i.e. based on TAI, eNodeB-ID, RAI, or RNC-ID).

Editor’s Note: procedures for Gn SGSN are FFS.

5.6.3 SIPTO at the local network with stand-alone GW (LGW collocated with SGW)

The stand-alone GW shall reside in the local network and be collocated with the SGW.

DNS procedures defined in the clause 5 in this specification also apply for the GW selection for SIPTO service with the following additions.

The MME/SGSN shall use the Local (H)(e)NB Network ID provided by the (H)(e)NB in the S1-AP/RANAP message to discover the SGW via the DNS. The S-NAPTR based selection of the SGW (based on the Local (H)(e)NB Network ID) gives the shortest user plane path from the UE to the SGW from the S-NAPTR ordering. Topological naming should be employed (as specified in clause 4.3.2) to find collocated SGW and LGW.

NOTE: Based on operator policy, the MME/SGSN can select a local SGW (based on the Local (H)(e)NB Network ID) at UE attachment to the (H)eNB regardless of whether a SIPTO at the local network PDN connection is established or not (see TS 23.401 clause 4.3.15.2).

5.6.4 SIPTO for eHRPD

For the support of the SIPTO service for eHRPD access, topological naming should be employed (as specified in clause 4.3.2) to find the shortest user plane path from the HSGW to the PGW based on the topological closeness. With this approach, the HSGW can select a PGW to achieve the shortest userplane to the UE for a SIPTO enabled APN. Details related to SIPTO support for eHRPD access are specified in 3GPP2 X.S0057 [24] and 3GPP TS 23.402 [25].

5.7 Procedures for Discovering and Selecting an MSC Server

5.7.1 General

These procedures are employed when a target MSC Server that serves the target cell or RNC needs to be initially selected by an EPC core node or Release-8 SGSN for the SRVCC operation. It explicitly does not cover selection of an MSC Server by a RAN node nor the selection of an MSC server at an SRNS relocation.

EPC core nodes, i.e. the MME and the S4-SGSN employ the procedures below during the PS-to-CS relocation procedure for the SRVCC operation. A Release‑8 SGSN supporting only Gn/Gp may also optionally use this procedure.

The MSC server enhanced for SRVCC is selected based on information received in the Target ID from the source E-UTRAN or UTRAN (see 3GPP TS 23.003 [4], 3GPP TS 25.413 [12] and 3GPP TS 36.413 [21]).

5.7.2 Selection of the MSC server enhanced for SRVCC based on target RAI (UTRAN / GERAN Iu & A/Gb mode target)

In SRVCC operations towards UTRAN and GERAN, the target MCC, MNC, LAC and optionally the RAC are available from the information in the Target ID.

The S-NAPTR procedure for an MME/SGSN finding the MSC Sv service and interfaces serving the target Routing Area is started with "Service Parameters" of

"x-3gpp-msc:x-sv"

as defined in 3GPP TS 23.003 [4] and setting the Application-Unique String to the RAI FQDN based on RAC, LAC, MNC, MCC as defined in 3GPP TS 23.003 [4] clause 19.4.2.5:

rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>. mcc<MCC>.3gppnetwork.org

The MME/SGSN shall set the RAC to a default value, e.g. hexadecimal value ‘FF’, if it is not available from the information in the Target ID.

A Release 8 SGSN supporting only Gn/Gp may also optionally use this procedure with "Service Parameters" of "x‑3gpp-msc:x-sv".

Operators shall provision, for each RAI value in their network, NAPTR records under the RAI FQDN corresponding to each valid MSC interfaces from at least the following "Service Parameters"

"x-3gpp-msc:x-sv",

where NAPTR records for additional "Service Parameters" may be included optionally.

NOTE 1: The NAPTR record at the RAI FQDN can be provisioned to correspond to only the default MSC server node(s) in the MSC pool(s) serving that RAI. The default MSC Server would be contacted with GTP, the default MSC server then selects the actual MSC Server within that MSC Server pool. This results in all SRVCC PS to CS service requests being handled by the default MSC Server nodes. If the operator’s goal is to avoid load on the default MSC Server nodes then the records provisioned at the RAI FQDN should instead include the entire set of MSC Servers in all MSC Server pools that service that RAI. The S-NAPTR procedure would then return each MSC Server in the MSC Server pool based on the provisioned DNS weights and priority.

NOTE 2: The MSC Server closest to the geographical region covered by the RAI can be biased by provisioning the DNS records with higher priority or weights.

3GPP does not require that collocation and "topon" naming is applicable in MSC Server selection.

NOTE 3: Service parameters are limited to those supported by the node doing the search.

NOTE 4: SGW records will also be provisioned under the RAI FQDN see clause 5.2

5.8 Procedures to support Dedicated Core Networks

5.8.1 General

These procedures shall be employed in PLMNs deploying DCNs for:

– discovering and selecting an SGW, PGW or GGSN in a DCN serving a particular UE usage type;

– retrieving the MMEGI or Null-NRI/SGSN Group ID to identify the DCN serving a particular UE usage type and to determine whether to perform a NAS Message Redirection procedure (see clause 5.19.1 of 3GPP TS 23.401 [11]);

– discovering and selecting a target MME or SGSN serving a particular UE usage type during a handover procedure with a MME or SGSN change.

DNS procedures to support DCNs shall be supported as specified in the rest of the specification, with the additions specified in the following clauses.

The UE usage type used during DNS procedure shall be the one mapped from the UE Usage Type received from the HSS as part of the subscription, based on the serving network operator configured policies and the UE related context information available at the serving network, e.g. information about roaming.

5.8.2 SGW, PGW and GGSN Selection Procedure

The S-NAPTR procedure employed to discover and select an SGW, PGW or GGSN in a DCN shall use the Application-Unique String set to the FQDN specified in the rest of this specification, e.g. with the APN-FQDN for PGW selection or with the TAI/eNodeB-ID/RAI/RNC-ID FQDN for SGW selection, and use the enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type for which the discovery and selection procedure is performed.

For example, the MME or S4-SGSN shall discover all GTP based S8 interfaces using "Service Parameters" of

"x-3gpp-pgw:x-s8-gtp+ue-<ue usage type>"

The S-NAPTR procedure shall logically output a candidate list of SGWs, PGWs or GGSNs serving at least the requested UE usage type, according to the general principles specified in clause 4.3.3.2.1 and Annex B.3. If no candidate SGW, PGW or GGSN is found for the requested UE usage type, possibly also after using local configuration, the procedure shall be performed with Service Parameters without the "+ue-<ue usage type>" appended to the ‘app-protocol’ name.

NOTE 1: This is required to discover and select an SGW, PGW or GGSN when no dedicated SGW, PGW or GGSN is configured for a particular UE usage type and FQDN.

As an exception to the above requirement if no candidate SGW, PGW or GGSN is found for the requested UE usage type for the selection of an SGW, PGW or GGSN in the same PLMN, the MME/SGSN, TWAN or ePDG may decide not to perform an S-NAPTR procedure with Service Parameters without the "+ue-<ue usage type>" appended to the ‘app-protocol’ name if so configured by operator policies and abort the selection procedure.

NOTE 2: This can avoid selecting an SGW, PGW or GGSN not intended to support specific UE usage type.

Annex A.4 provides examples of DNS provisioning for SGW and PGW discovery and selection procedures in a DCN, and examples of procedures for discovery and selection of SGW/PGW.

5.8.3 MMEGI and Null-NRI/SGSN Group ID Retrieval Procedure

To retrieve the MMEGI identifying the DCN serving a particular UE usage type, the S-NAPTR procedure shall use the Application-Unique String set to the TAI FQDN as defined in clause 19.4.2.3 of 3GPP TS 23.003 [4] and use the enhanced service parameters as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type for which the discovery and selection procedure is performed. The MME shall discover the MMEGI for a particular UE usage type by using the "Service Parameters" of

"x-3gpp-mme:x-s10+ue-<ue usage type>"

To retrieve the Null-NRI/SGSN Group ID identifying the DCN serving a particular UE usage type, the S-NAPTR procedure shall use the Application-Unique String set to the RAI FQDN as defined in clause 19.4.2.5 of 3GPP TS 23.003 [4] and use the enhanced service parameters as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type for which the discovery and selection procedure is performed. Gn/Gp SGSN shall discover the Null-NRI/SGSN Group ID for a particular UE usage type by using "Service Parameters" of

"x-3gpp-sgsn:x-gn+ue-<ue usage type>"

S4-SGSN shall discover the Null-NRI/SGSN Group ID for a particular UE usage type by using "Service Parameters" of

"x-3gpp-sgsn:x-s16+ue-<ue usage type>"

Operators shall provision corresponding NAPTR records for these FQDNs, with enhanced "Service Parameters" appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type(s) for which the record applies. The MMEGI or Null-NRI/SGSN Group ID shall be provisioned in the host name of these records. The MMEGI or Null-NRI/SGSN Group ID shall be retrieved from the host name.

The NAPTR records associated to the TAI FQDN shall be provisioned with a host name in the replacement part, as specified in 4.3.2, having the canonical-node-name start as:

mmec<MMEC>.mmegi<MMEGI>

The NAPTR records associated to the RAI FQDN shall be provisioned with a host name in the replacement part, as specified in 4.3.2, having the canonical-node-name start as:

nri-sgsn<NRI>.null-nri<Null-NRI>

The NAPTR records associated to the RAI FQDN shall be provisioned with a host name in the replacement part, as specified in 4.3.2, having the canonical-node-name start as:

nri-sgsn<NRI>.sgsngi<SGSN Group ID>

<Null-NRI>and <SGSN Group ID>shall be Hex coded digits representing the Null-NRI code of the SGSNs and SGSN Group ID respectively (see 3GPP TS 25.413 [12]). If there are less than 4 significant digits in <Null-NRI> and <SGSN Group ID>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding respectively. Coding for other fields is the same as specified in 3GPP TS 23.003 [4].

NOTE 1: Annex A provides examples of the MMEGI and Null-NRI/SGSN Group ID retrieval procedures.

5.8.4 MME and SGSN Selection Procedure

The S-NAPTR procedure employed to discover and select an MME or SGSN serving a particular UE usage type, during a handover procedure with a MME or SGSN change, shall use the Application-Unique String set to the FQDN specified in the rest of this specification, e.g. with the TAI-FQDN for MME selection or with an RAI or RNC-ID FQDN for SGSN selection, and use the enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type for which the discovery and selection procedure is performed.

For example, the procedure for an MME to find a candidate set of target MMEs makes use of the "Service Parameters" of:

"x-3gpp-mme:x-s10+ue-<ue usage type>"

and the procedure for an MME to find a candidate set of target SGSNs makes use of the "Service Parameters" of:

"x-3gpp-sgsn:x-s3+ue-<ue usage type>"

The S-NAPTR procedure shall logically output a candidate list of MMEs and SGSNs serving at least the requested UE usage type, according to the general principles specified in clause 4.3.3.2.1 and Annex B.3. If no candidate MME or SGSN is found for the requested UE usage type, possibly also after using local configuration, the procedure shall be performed with Service Parameters without the "+ue-<ue usage type>" appended to the ‘app-protocol’ name.

NOTE 1: This is required to discover and select an MME or SGSN when no dedicated MME or SGSN is configured for a particular UE usage type and FQDN.

As an exception to the above requirement if no candidate MME or SGSN is found for the requested UE usage type for the selection of an MME or SGSN in the same PLMN, the MME/SGSN may decide not to perform an S-NAPTR procedure with Service Parameters without the "+ue-<ue usage type>" appended to the ‘app-protocol’ name if so configured by operator policies and abort the selection procedure.

NOTE 2: This can avoid selecting an MME or SGSN not intended to support specific UE usage types.

Annex A.4 provides examples of DNS provisioning for MME discovery and selection procedures in a DCN.

5.8.5 AMF Selection Procedure

The S-NAPTR procedure employed to discover and select an AMF serving a particular UE usage type, during a EPS to 5GS handover using N26 interface procedure, shall use the Application-Unique String set to the FQDN specified in the rest of this specification, e.g. with the 5GS TAI-FQDN for AMF selection, and use the enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type for which the discovery and selection procedure is performed.

For example, the procedure for an MME to find a candidate set of target AMFs with N26 interface makes use of the "Service Parameters" of:

"x-3gpp-amf:x-n26+ue-<ue usage type>"

The S-NAPTR procedure shall logically output a candidate list of AMFs serving at least the requested UE usage type, according to the general principles specified in clause 4.3.3.2.1 and Annex B.3. If no candidate AMF is found for the requested UE usage type, possibly also after using local configuration, the procedure shall be performed with Service Parameters without the "+ue-<ue usage type>" appended to the ‘app-protocol’ name.

NOTE 1: This is required to discover and select an AMF when no dedicated AMF is configured for a particular UE usage type and FQDN.

As an exception to the above requirement if no candidate AMF is found for the requested UE usage type for the selection of an AMF in the same PLMN, the MME may decide not to perform an S-NAPTR procedure with Service Parameters without the "+ue-<ue usage type>" appended to the ‘app-protocol’ name if so configured by operator policies and abort the selection procedure.

NOTE 2: This can avoid selecting an AMF not intended to support specific UE usage types.

5.9 Procedures to support Cellular Internet of Things

5.9.1 DCN based solution

When DCN is supported in the network, the node performing the selection function may use the DNS procedures enhanced for supporting DCNs as specified in clause 5.8, to select an EPC entity, e.g. an SGW or PGW, which supports CIoT by configuring a specific UE Usage Type(s) for CIoT.

For a MS requesting a PDN Connection of type "Non-IP", the S4-SGSN may use the DNS procedures enhanced for supporting DCNs as specified in clause 5.8, to select an EPC entity, e.g. an SGW or PGW, which supports this PDN Connection of type "Non-IP" by configuring a specific UE Usage Type.

For a MS requesting a PDP Context of type "Non-IP", the Gn/Gp-SGSN may use the DNS procedures enhanced for supporting DCNs as specified in clause 5.8, to select a GGSN which supports this PDP Context of type "Non-IP" by configuring a specific UE Usage Type.

5.9.2 Alternative solution

The SGSN shall use the DNS procedures specified in this specification for selecting a GGSN or PGW supporting the Non-IP PDN Type without any change. The GGSNs or PGWs configured in the DNS for an APN which can be used for a Non-IP PDN connection shall all support the Non-IP PDN type.

The MME shall use the DNS procedures specified in this specification for selecting a PGW optimised for CIoT without any change. The PGWs configured in the DNS for an APN which can be used for NB-IoT access or for a Non-IP PDN connection shall all support NB-IoT or the Non-IP PDN type respectively.

The MME or SGSN shall select an SGW optimised for CIoT, using the DNS procedures for selecting an SGW specified in clauses 5.2 and 5.3, but retaining then one SGW, from the candidate SGWs list, which is also known to support of CIoT. The MME or SGSN knows whether an SGW supports CIoT via the Notification of Supported features over the S11 or S4 interface (for the CIoT feature), as specified in 3GPP TS 29.274 [23].

A source MME or SGSN shall select a target MME or SGSN, during a handover procedure for a UE supporting some CIoT EPS Optimisations, using the DNS procedures for selecting an MME or SGSN during a handover procedure specified in clause 5.4 or 5.5, but retaining then one target MME or SGSN, from the candidate target MME or SGSN list, which is also known by local configuration to support at least one CIoT EPS optimisation. The selected target MME or SGSN may forward the Forward Relocation Request to another MME or SGSN in the target MME or SGSN pool, as specified in 3GPP TS 29.274 [23].

5.10 Procedures for Discovering and Selecting an SGW-U

These procedures shall be employed when an SGW-U needs to be selected by an SGW-C and the SGW-C supports the UP selection function based on DNS specified in Annex B.2.6 of 3GPP TS 29.244 [26].

Operators shall provision, for each TAI/eNodeB-ID/RAI/RNC-ID value in their network, NAPTR records under the TAI/eNodeB-ID/RAI/RNC-ID FQDN corresponding to each UP function serving as an SGW-U with the following "Service Parameters":

"x-3gpp-upf:x-sxa"

where additional "Service Parameters" may be included optionally.

When DCN is deployed, operators shall provision corresponding NAPTR records for these FQDNs, with enhanced "Service Parameters" appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type(s) for which the record applies:

"x-3gpp-upf:x-sxa+ue-<usage type>"

The SGW-C may select a specific SGW-U for UE supporting a particular network capability (see clause 5.x). Operators shall provision corresponding NAPTR records for these FQDNs, with enhanced "Service Parameters" appending the character string "+nc-<network-capability>" to the ‘app-protocol’ name as follows:

"x-3gpp-upf:x-sxa+nc-<network-capability>"

To discover and select an SGW-U, the SGW-C shall use S-NAPTR procedure with the "Service Parameters" of:

"x-3gpp-upf:x-sxa"

and the TAI/eNodeB-ID/RAI/RNC-ID FQDN as the Application-Unique String.See clause 19.4 of 3GPP TS 23.003 [4].

When DCN is deployed, the S-NAPTR procedure employed to discover and select an SGW-U shall use the Application-Unique String set to the TAI/eNodeB-ID/RAI/RNC-ID FQDN, and use the enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type for which the discovery and selection procedure is performed.

For example, the SGW-C shall discover a UP function capable to serve as a SGW-U using the "Service Parameters" of:

"x-3gpp-upf:x-sxa+ue-<ue usage type>"

The S-NAPTR procedure employed to discover and select an SGW-U shall use the Application-Unique String set to the TAI/eNodeB-ID/RAI/RNC-ID FQDN, and use the enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+nc-<network-capability>" to the ‘app-protocol’ name identifying specific SGW-U supporting a particular network capability.

For example, the SGW-C shall discover a UP function capable to serve as a SGW-U using the "Service Parameters" of:

"x-3gpp-upf:x-sxa+nc-<network-capability>"

5.11 Procedures for Discovering and Selecting PGW-U

These procedures shall be employed when a PGW-U needs to be selected by an PGW-C and the PGW-C supports the UP selection function based on DNS specified in Annex B.2.6 of 3GPP TS 29.244 [26].

Operators shall provision, for each APNs configured in their network, NAPTR records under the APN FQDN corresponding to each UP function serving as a PGW-U with the following "Service Parameters":

"x-3gpp-upf:x-sxb"

where additional "Service Parameters" may be included optionally. See clause 19.4.2.2 of 3GPP TS 23.003 [4].

"x-3gpp-upf:x-sxb+ue-<usage type>"

The PGW-C may select a specific PGW-U supporting a particular network capability (see clause 5.x). Operators shall provision corresponding NAPTR records for these FQDNs, with enhanced "Service Parameters" appending the character string "+nc-<network-capability>" to the ‘app-protocol’ name, the following record applies:

"x-3gpp-upf:x-sxb+nc-<network-capability>"

To discover and select a PGW-U, the PGW-C shall use S-NAPTR procedure with the "Service Parameters" of:

"x-3gpp-upf:x-sxb"

and the APN FQDN as the Application-Unique String.

When DCN is deployed, the S-NAPTR procedure employed to discover and select an PGW-U shall use the Application-Unique String set to the APN FQDN, and use the enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+ue-<ue usage type>" to the ‘app-protocol" name identifying the UE usage type for which the discovery and selection procedure is performed.

For example, the PGW-C shall discover a UP function capable to serve as a PGW-U using the "Service Parameters" of:

"x-3gpp-upf:x-sxb+ue-<ue usage type>".

The S-NAPTR procedure employed to discover and select an PGW-U shall use the Application-Unique String set to the APN FQDN, and use the enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+nc-<network-capability>" to the ‘app-protocol’ name identifying specific PGW-U supporting a particular network capability.

For example, the PGW-C shall discover a UP function capable to serve as a PGW-U using the "Service Parameters" of:

"x-3gpp-upf:x-sxb+nc-<network-capability>".

5.12 Procedures to select a node supporting a particular network capability

5.12.1 General principles

5.12.1.1 General

Operators may need to discover and select a network node supporting a particular network capability.

DNS procedures to select a node supporting a particular network capability shall be supported as specified in the rest of the specification, with the additions specified in clause 5.12. The following clauses also further define the specific network capabilities for which these procedures may be used.

Enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4] may be used to select a network node with a particular network capability, by appending the character string "+nc-<network capability>" to the ‘app-protocol’ name.

Operators shall provision corresponding NAPTR records for these FQDNs, with enhanced "Service Parameters" appending the character string "+nc-<network capability>" to the ‘app-protocol’ name identifying the network capability(s) for which the record applies.

The S-NAPTR procedure shall logically output a candidate list of network nodes supporting at least the requested network capability, according to the general principles specified in clause 4.3.3.2.1, Annex B.4. If no candidate network nodes are found for the requested network capability, possibly also after using local configuration, the procedure shall be performed with Service Parameters without the "+nc-<network capability>" appended to the ‘app-protocol’ name.

NOTE 1: This is required to discover and select a network node when no dedicated network node is configured for a particular network capability.

As an exception to the above requirement if no network node is found for the requested network capability for the selection of a network node in the same PLMN, e.g. the SGW and PGW in the same PLMN, the node performing the node selection may decide to not perform an S-NAPTR procedure with Service Parameters listed in the above requirement, if so configured by operator policies, and abort the selection procedure.

NOTE 2: This can avoid selecting a network node not supporting a particular network capability.

5.12.1.2 Selecting a node supporting a particular network capability within a Dedidated Core Network

When using Dedicated Core Networks, the selection of a node supporting a particular network capability may solely rely on the procedures specified for DCNs in clause 5.8, or combine the procedures specified in clauses 5.12 and 5.8 by using Enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4] to select a network node with a particular network capability within a particular DCN, by appending the character string "+nc-<network capability>" and "+ue-<ue-usage-type> to the ‘app-protocol’ name and provisioning NAPTR records accordingly.

For example, the MME or S4-SGSN shall discover all GTP based S5/S8 interfaces using "Service Parameters" of

"x-3gpp-pgw:x-s5-gtp+nc-<network capability>+ue-<ue-usage-type>", "x-3gpp-pgw:x-s8-gtp+nc-<network capability>+ ue-<ue-usage-type>"

"x-3gpp-pgw:x-s5-gtp+ue-<ue-usage-type>+nc-<network capability>", "x-3gpp-pgw:x-s8-gtp+ ue-<ue-usage-type>+nc-<network capability>"

NOTE: An ‘app-protocol’ name appears at most once in a NAPTR record. For instance, "x-3gpp-pgw:x-s5-gtp+nc-<network capability>: x-s5-gtp+ue-<ue usage type>" is not a valid NAPTR record.

If no candidate network nodes are found for the requested network capability and UE usage type, possibly also after using local configuration, the procedure shall be performed with Service Parameters:

– without the "+nc-<network capability>" appended to the ‘app-protocol’ name;

– without the "+ue-<ue-usage-type>" appended to the ‘app-protocol’ name;

– without the "+nc-<network capability>" nor the "+ue-<ue-usage-type>" appended to the ‘app-protocol’ name.

As an exception to the above requirement if no network node is found for the requested network capability and UE usage type for the selection of a network node in the same PLMN, e.g. the SGW and PGW in the same PLMN, the node performing the node selection may decide to not perform an S-NAPTR procedure with Service Parameters listed in the above requirement, if so configured by operator policies, and abort the selection procedure.

5.12.1.3 Selecting an SGW or PGW supporting a particular network capability

The S-NAPTR procedure employed to discover and select an SGW and PGW supporting a particular network capability shall use the Application-Unique String set to the FQDN specified in the rest of this specification, e.g. with the APN-FQDN for PGW selection or with the TAI/eNodeB-ID/RAI/RNC-ID FQDN for SGW selection, and use the enhanced "Service Parameters" as specified in clause 19.4.3 of 3GPP TS 23.003 [4], i.e. appending the character string "+nc-<network capability>" to the ‘app-protocol’ name.

For example, the MME or S4-SGSN shall discover all GTP based S5/S8 interfaces using "Service Parameters" of

"x-3gpp-pgw:x-s5-gtp+nc-<network capability>", "x-3gpp-pgw:x-s8-gtp+nc-<network capability>"

Operators shall provision corresponding NAPTR records for these FQDNs, with enhanced "Service Parameters" appending the character string "+nc-<network capability>" to the ‘app-protocol’ name.

The S-NAPTR procedure shall logically output a candidate list of SGWs or PGWs supporting the requested network capability. If no candidate SGW and PGW is found, possibly also after using local configuration, the procedure shall be performed with Service Parameters without the "+nc-<network capability>" appended to the ‘app-protocol’ name.

NOTE 1: This is required to discover and select an SGW or PGW when no dedicated SGW or PGW is configured to support the requested network capability.

As an exception to the above requirement if no candidate SGW or PGW is found to support the requested network capability for the selection of an SGW or PGW in the same PLMN, the MME or S4-SGSN may decide not to perform an S-NAPTR procedure with Service Parameters without the "+nc-<network capability>" appended to the ‘app-protocol’ name if so configured by operator policies and abort the selection procedure.

NOTE 2: This can avoid selecting an SGW or PGW not supporting the requested network capability.

5.12.2 Procedures to support Dual Connectivity with NR

5.12.2.1 General

An MME or SGSN may select specific SGWs and PGWs for UEs supporting dual connectivity with NR and not restricted to use NR by user subscription (see "NR as Secondary RAT Not Allowed" bit within Access Restriction Data as specified in TS 29.272 [27]) or local operator policy, e.g. due to requirements of higher bitrates, data usage reporting over the secondary RAT, etc. A UE signals its support for dual connectivity with NR to the MME and SGSN in NAS signalling. The specific SGWs and PGWs may be combined SGW/PGW functions.

DNS procedures to support Dual Connectivity with NR shall be supported as specified in clause 5.12.1, with the following additions:

– the <network-capability> shall be set to "nr".

For example, the MME or S4-SGSN shall discover all GTP based S5/S8 interfaces using "Service Parameters" of "x-3gpp-pgw:x-s5-gtp+nc-nr", "x-3gpp-pgw:x-s8-gtp+nc-nr"

– this network capability may apply to:

– the ‘app-service’ names "x-3gpp-sgw", "x-3gpp-pgw";

– the ‘app-protocol’ names: "x-s5-gtp", "x-s8-gtp", "x-s11".

5.12.3 Procedures to support interworking with 5GC

5.12.3.1 General

5GS interworking procedures with EPC rely on selecting a combined PGW-C/SMF and PGW-U/UPF during the PDN connection establishment (see clause 4.11 of 3GPP TS 23.501 [28]).

5.12.3.2 PGW-C/SMF selection

An MME and an ePDG shall select a combined PGW-C/SMF for PDN connections that may be subject to mobility to 5GS, e.g. for UEs supporting N1 mode and not restricted to interworking with 5GS by user subscription (see "5GC" bit within Core-Network-Restrictions AVP and Interworking-5GS-Indicator AVP specified in 3GPP TS 29.272 [27] and 3GPP TS 29.273 [30]). A UE signals its support for 5GC NAS to the MME in NAS signalling and to the ePDG in IKEv2 signalling.

An MME and an ePDG should also select a combined PGW-C/SMF, if possible, for PDN connections of UEs not supporting N1 mode that are not restricted to access the 5GC by user subscription (see "5GC" bit within Core-Network-Restrictions AVP and Interworking-5GS-Indicator AVP specified in 3GPP TS 29.272 [27] and 3GPP TS 29.273 [30]).

A PDN connection of a subscription restricted from accessing the 5GC or without 5GS interworking subscribed for the APN is not subject to mobility to 5GS and may be connected to a PGW, a PGW-C or a combined PGW-C/SMF; when PGW-C (or PGW) and combined PGW-C/SMF are available for election, the preference order may be based on operator’s policy in the MME or ePDG.

DNS procedures to select a combined PGW-C/SMF shall be supported as specified in clause 5.12.1, with the following additions:

– the <network-capability> shall be set to "smf".

For example, the MME shall discover all GTP based S5/S8 interfaces using "Service Parameters" of "x-3gpp-pgw:x-s5-gtp+nc-smf", "x-3gpp-pgw:x-s8-gtp+nc-smf" and the ePDG shall discover all GTP based S2b interfaces using "Service Parameters" of "x-3gpp-pgw:x-s2b-gtp+nc-smf".

– this network capability may apply to:

– the ‘app-service’ name "x-3gpp-pgw";

– the ‘app-protocol’ names: "x-s5-gtp", "x-s8-gtp", "x-s2b-gtp".

5.12.3.3 PGW-U/UPF selection

A PGW-C/SMF shall select a combined PGW-U/UPF for PDN connections that may be subject to mobility to 5GS and for PDN connections not subject to mobility to 5GS but that access the 5GC.

If the PGW-C/SMF supports the UP function selection based on DNS procedures specified in Annex B.2.6 of 3GPP TS 29.244 [26], DNS procedures to select a combined PGW-U/UPF shall be supported as specified in clause 5.11 (for discovering and selecting a PGW-U), with the following additions:

– the app-service of x-3gpp-upf with app-protocol "x-n4" identifies a User Plane function supporting N4 capabilities;

– the app-service of x-3gpp-upf with app-protocols "x-sxb:x-n4" identifies a PGW-U supporting N4 capabilities (i.e. a combined PGW-U/UPF).

5.12.3.4 PGW-U/UPF/MB-UPF selection

A PGW-C/SMF/MB-SMF may select a combined PGW-U/UPF/MB-UPF for PDN connections that may be subject to mobility to 5GS and to be associated with MBS session.

If the PGW-C/SMF/MB-SMF supports the UP function selection using DNS procedures, DNS procedures to select a combined PGW-U/UPF/MB-UPF shall be supported as specified in clause 5.12.3.3 (for discovering and selecting a PGW-U/UPF), with the following additions:

– the app-service of x-3gpp-upf with app-protocol "x-n4mb" identifies a User Plane function supporting N4mb capabilities;

– the app-service of x-3gpp-upf with app-protocols "x-sxb:x-n4:x-n4mb" identifies a PGW-U/UPF supporting N4mb capabilities (i.e. a combined PGW-U/UPF/MB-UPF).

5.13 Procedures to support Ethernet PDN Connection in EPS

5.13.1 DCN based solution

When DCN is supported in the network, the MME may use the DNS procedures enhanced for supporting DCNs as specified in clause 5.8, to select an EPC entity, e.g. an SGW or a combined PGW-C/SMF, which supports Ethernet PDN connection by configuring to support a specific UE Usage Type(s).

5.13.2 Network Capability based solution

An MME may use the DNS procedure as specified in clause 5.12.1, to select an EPC entity, e.g. an SGW or a combined PGW-C/SMF which supports Ethernet PDN connection, with the following additions:

– the <network-capability> shall be set to "eth" for an SGW selection and shall be set to "smf.eth" for a combined PGW-C/PGW-U selection. (See also clause 5.12.3 and Annex B.4)

For example, the MME shall discover all GTP based S5/S8 interfaces using "Service Parameters" of "x-3gpp-pgw:x-s5-gtp+nc-smf.eth", "x-3gpp-pgw:x-s8-gtp+nc-smf.eth"

– this network capability may apply to:

– the ‘app-service’ names "x-3gpp-sgw", "x-3gpp-pgw";

– the ‘app-protocol’ names: "x-s5-gtp", "x-s8-gtp", "x-s11".

5.13.3 Alternative solutions

The MME may use the DNS procedures specified in this specification for selecting a combined PGW-C/SMF supporting Ethernet PDN connection without any change if all combined PGW-C/SMFs configured in the DNS for an APN support Ethernet PDN connection.

The MME may know whether an SGW supports Ethernet PDN connection via the Notification of Supported features over the S11 interface (for the ETH feature), as specified in 3GPP TS 29.274 [23].

5.14 Procedures for Discovering and Selecting a UCMF

These procedures shall be employed when a UCMF needs to be discovered and selected by MME.

Operators shall provision NAPTR records under UCMF FQDN corresponding to valid UCMF interfaces from the following "Service Parameters":

– "x-3gpp-ucmf:x-urcmp", "x-3gpp-ucmf:x-n55"

Where additional "Service Parameters" may be included optionally.

MMEs are expected to select a UCMF based on MME’s capability to support URCMP or N55 based signalling. If multiple UCMFs are deployed, implementation specific algorithms should be used to distribute load among available UCMFs.

3GPP does not require that collocation and "topon" naming is applicable in UCMF selection.

6 Procedures for OAM System Node Discovery

6.1 Procedures for Relay Node OAM System Discovery

6.1.1 General

These procedures may be employed when a relay node (see 3GPP TS 36.300 [22], clause 4.7) needs to discover its Operations and Maintainence (OAM) system. The relay nodes employ the procedures below during the startup procedure in order to discover the OAM system, from which it obtains its configuration and updated software.

The OAM system is selected based on the operator identitity and the type allocation code identifying the relay node vendor, and optionally the tracking area code (see 3GPP TS 23.003 [4]). This enables vendor-specific OAM systems for relay nodes.

6.1.2 OAM System Selection based on Type Allocation Code

In both UTRAN and E-UTRAN cases the operator identity in terms of MNC and MCC is available from the information in IMSI (see 3GPP TS 23.003 [4], clause 2.2). The type allocation code (IMEI-TAC) identifying the relay node vendor is available from IMEI or IMEISV (see 3GPP TS 23.003 [4], clause 6.2).

1) In relay node startup procedure, the relay node may use the vendor-specific relay node OAM system FQDN as it is defined in 3GPP TS 23.003 [4], clause 23.3.2.2, to discover its OAM system. Operator provisions A/AAAA record under 3GPP vendor-specific relay node OAM system FQDN.