7 Procedures for NF Discovery in 5G System

29.3033GPPDomain Name System ProceduresRelease 17Stage 3TS

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

7.1 General

The discovery of NFs in the 5G System is supported by the NRF (see 3GPP TS 23.501 [28] and 3GPP TS 23.502 [29]), except for the following scenarios for which DNS procedures are defined:

– AMF discovery and selection by MME, for EPS interworking with the 5G System using the N26 interface (see clauses 4.3.3.4, 4.3.3.8, 5.4 and 5.4A); and

– AMF discovery by 5G-AN (see clause 7.2).

7.2 Procedure for AMF Discovery by 5G-AN

The 5G-AN selects an AMF Set and an AMF from the AMF set as specified in clause 6.3.5 of 3GPP TS 23.501 [28].

NOTE 1: The 5G-AN (NG-RAN and N3IWF) is responsible for initiating the SCTP connectivity and setting up the NG-C association with the AMF. This requires the 5G-AN to first obtain the AMF’s IP address(es).

In the 5G System, AMFs may be added or removed dynamically for scalability or planned maintenance. The DNS procedure specified in this clause may be used by the 5G-AN to discover the AMFs available in an AMF Set.

NOTE 2: The 5G-AN might obtain the information about the available AMFs via alternative means, e.g. OAM.

The AMFs available within an AMF Set should be provisioned within NAPTR records in the DNS, under the AMF Set FQDN (as defined in clause 28.3.2.7 of 3GPP TS 23.003 [4]), with the Service Parameters "x-3gpp-amf:x-n2".

The 5G-AN may discover the AMFs available within an AMF Set by:

– constructing the AMF Set FQDN, as defined in clause 28.3.2.7 of 3GPP TS 23.003 [4], identifying the AMF Set of the AMFs to be discovered; and

– initiating an S-NAPTR procedure, with the Application-Unique String set to that AMF Set FQDN, and with the "Service Parameters" set to "x-3gpp-amf:x-n2".

The S-NAPTR procedure outputs a list of host names (AMFs) each with a service, protocol, port and a list of IPv4 and IPv6 addresses. See further details and examples in Annexes B, C and F.

Annex A (Informative):
Examples

A.1 Introduction

This annex includes examples of the DNS provisioning needed for EPC node discovery and selection procedures. Examples are not exhaustive either in scope or in content but are intended to be sufficient to illustrate the general techniques and some of the more important use cases.

A.2 Preconditions

The following are general comments applying to all examples provided here.

a) DNS master file format follows IETF RFC 1035 [3] clause 5. The reader is reminded that in that format the character ":" is used for comments, "$" is used for directives, and enclosing parenthesis ( ) combine lines.

b) Examples are built from smaller files and merged with the $INCLUDE directive. This is to allow each file to be documented in a separate clause and to allow reuse of files in some of the examples.

c) Only one operator’s network is used in all examples using MCC=311 (United States) and MNC=990 (currently an unassigned MNC value). All DNS records presented here are within the zone cut epc.mnc990.mcc311.3gppnetwork.org.

d) Since the fully qualified domain names here are relatively long to avoid line wrapping and to save space in the examples we use the standard $ORIGIN directive
$ORIGIN epc.mnc990.mcc311.3gppnetwork.org.
Hence any domain names in the file that are not fully qualified (i.e. does not end with a period) would have epc.mnc990.mcc311.3gppnetwork.org. appended to them to form the fully qualified value. In the descriptive text in this Annex we use the same convention.

e) When a printout is provided, it is from an actual printout of the "dig" command (from the BIND distribution) but with all values of the string .epc.mnc990.mcc311.3gppnetwork.org. replaced with .$ORIGIN in order to keep the output on one line when possible. Note the "+tcp" option is used in the "dig" command to avoid truncating large DNS responses in the examples.

f) Files provided here have been tested with a recent version of BIND and are presented here unmodified. In the examples the BIND server was set as authoritative only with default settings to make the configuration self contained. In a real network a recursive server is likely to be used as an intermediary and/or multiple authoritative servers.

g) The time to live (TTL) in the examples are all set to 1 hour = 3600 seconds by using the $TTL directive from IETF RFC 2308 [15].

h) IPv4 addresses in the examples are from the IPv4 example documentation address space of 192.0.2.0/24 of IETF RFC 3330 [16] and IPv6 addresses are from the IPv6 documentation address space of IETF RFC 3849 [17] . These are by no means representative and are used solely for example purposes.

i) Since A/AAAA records are well known we only provide A/AAAA records for the simpler examples and do not document every A and AAAA lookup in detail.

A.3 Collocated Simple LTE Example

A.3.1 Network description

This is a fairly complete example of an operator network with the following properties.

1) Network only has LTE access with only interworking with LTE access. There is no support for Gn/Gp and no support for S3/S4.

2) Network does not support PMIPv6 for S5 but does allow very limited roaming use of S8 PMIPv6. This is a policy that is extremely unlikely to be used by a real operator and is used only for illustrative purposes.

3) There are two combined PGW/SGW nodes and two standalone MME nodes.

4) Any load balancing between nodes of the same functional type is on a strict bias. Hence, SRV records are not needed.

5) Operator desires the flattest DNS structure possible due to desire to minimize the number of DNS queries. The use of NATPR with flag "" is therefore not used by operator policy. This is feasable since the network is small.

6) Due to 4) and 5) only NAPTR records with flag "a" are used by the operator in this example.

7) One MME pool area.

8) One SGW service area.

9) Operator desires that S1-U link cost is minimized (i.e. SGW closest to eNodeB is used)

10) Operator does not care about distance or transport costs between SGW and PGW beyond the collocation for S5. Hence it does not use "topon" naming.

11) Small number of APNs

Other than item 2) this set of conditions might fit a green field operator or government agency deploying LTE for use on laptop computers or high end hand held devices for internet access. This represents one of the simpler networks possible while still being non-trivial.

Very large networks would tend to use MME pool areas and SGW service areas and NAPTR empty flag records. How complex the structure in DNS is employed between the initial NAPTR entry point and the final A/AAAA record set(s) is solely the operator’s choice so long as the S-NAPTR requirements are met.

Additional comments on this example are in each clause as needed. Also commented out DNS records are often included in the sample files to illustrate how additional interface types would be added.

A. 3.2 Master file for "Collocated Simple LTE Example"

The master file for this example will be CS_EX.txt and has following content.

$ORIGIN epc.mnc990.mcc311.3gppnetwork.org.

;

$TTL 3600 ; 1 hour – this directive is defined in IETF RFC 2308 not RFC 1035

;

$INCLUDE SOA_DB.txt

;

$INCLUDE CS_MME_DB.txt

;

$INCLUDE CS_SGW_PGW_NODE_DB.txt

;

$INCLUDE CS_TAI_DB.txt

;

$INCLUDE CS_APN_DB.txt

;

; End of file

The included files are detailed in following clauses.

A. 3.3 SOA and NS records

The SOA and NS records need to exist for any DNS zone. Our example will use the following file with name SOA_DB.txt whose content is:

; SOA and NS glue records

; Note @, ns1, ns2 are relative to $ORIGIN

;

@ 1D IN SOA @ administrator.example.com. (

2008122401 ; serial

1H ; refresh

15 ; retry

1w ; expire

1h ; minimum – note this parameter

; is used for negative caching

; see RFC 2308 chapter 4

)

IN NS ns1

IN NS ns2

;

; Glue records for the two DNS servers

ns1 IN A 192.0.2.247

ns2 IN A 192.0.2.248

; End of file

A. 3.4 MME file for "Collocated Simple LTE Example"

The MME S10 record lookup by GUTI is probably the simplest example of the NAPTR records and is the simplest introduction to the S-NAPTR procedure as well.

A NAPTR record is required to be provisioned at mmec<MMEC>.mmegi<MMEGI>.mme (see clause 4.3.3.4 of this TS). This is used for GUTI based lookup of the old or source MME. Specifically, the target MME takes the UE’s old GUTI value and derives the old MME’s DNS name. The goal of the target MME is usually to be able to do a context transfer of the old MME’s data (or similar action). MME to MME communication is done over S10. Hence, S10 is critical for the GUTI record in an LTE only network.

The mmec<MMEC>.mmegi<MMEGI>.mme is also the natural place for the MME canonical node record set. For this example we place the MME canonical node records and the required record for GUTI based lookup at the same location both for simplicity and better DNS caching.

For this example we have two MMEs with MMEC codes of 1 and 2 respectively and both in the same MME pool (MMEGI = 8000 hexadecimal).

The file containing the MME records for this example will be CS_MME_DB.txt and has following NAPTR record content.

;

; This is the GUTI related record and the MME node record

; The operator has decided to use the 3GPP name as the canononical node name of the MME

; rather than having two records (the 3GPP one and an operator defined value)

;

mmec01.mmegi8001.mme (

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec01.mmegi8001.mme )

IN NAPTR 200 999 "a" "x-3gpp-mme:x-s11" "" topoff.eth3.mmec01.mmegi8001.mme

; IN NAPTR 300 999 "a" "x-3gpp-mme:x-s3" "" topoff.eth5.mmec01.mmegi8001.mme

; IN NAPTR 400 999 "a" "x-3gpp-mme:x-gn" "" topoff.eth6.mmec01.mmegi8001.mme

; IN NAPTR 500 999 "a" "x-3gpp-mme:x-s1-mme" "" topoff.eth7.mmec01.mmegi8001.mme

; This particular operator only supports LTE access in their accesses etc.

; So the S3 record is commented out above. If the operator wants the MME to be used with S3/S4

; SGSN nodes then the record would have to be included.

; The Gn/Gp interface is commented out for same reason. This operator does not support it.

; If the operator wants the MME to be used for Gn/Gp SGSN interworking

; then the record would have to be included.

;

; Reminder: Canonical node name records must be complete.

; However, "x-3gpp-mme:x-s1-mme" is an exception.

; While S1-MME interface must be physically present and used in a MME

; it is explicitly optional for an operator to provision in this release of 3GPP

;. So it too is commented out

; NAPTR order plays no major role in this particular example since the MME node is already

; selected in GUTI case and as a canonical node name. In most cases the interface type

;(S10 vs S11 etc) is functionally determined so the NAPTR order is rarely used in this record set

; If the S3 and Gn records were not commented out the S10 is preferred over S3 over Gn

; I.e. a combined MME/SGSN could communicate to the MME above using any of the three protocols

; at context transfer.

; So the operator is stating that S10 is preferred over S3 over Gn

;

; Of course if the MME had multiple S10 interfaces

; the operator could provision more than one S10 record with different orders

; perhaps to select S10 IPv6 over S10 IPv4

; We have the same type of records for the other MME (same comments would apply)

;

mmec02.mmegi8001.mme (

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec02.mmegi8001.mme )

IN NAPTR 200 999 "a" "x-3gpp-mme:x-s11" "" topoff.eth3.mmec02.mmegi8001.mme

; IN NAPTR 300 999 "a" "x-3gpp-mme:x-s3" "" topoff.eth5.mmec02.mmegi8001.mme

; IN NAPTR 400 999 "a" "x-3gpp-mme:x-gn" "" topoff.eth6.mmec02.mmegi8001.mme

; IN NAPTR 500 999 "a" "x-3gpp-mme:x-s1-mme" "" topoff.eth7.mmec02.mmegi8001.mme

;

; All MME IP addresses for both MME

;

topoff.eth1.mmec01.mmegi8001.mme IN A 192.0.2.11

IN A 192.0.2.12

IN AAAA 2001:db8:0:0:0:0:0:0

IN AAAA 2001:db8:0:1:0:0:0:0

topoff.eth3.mmec01.mmegi8001.mme IN A 192.0.2.13

IN A 192.0.2.14

IN AAAA 2001:db8:0:2:0:0:0:0

IN AAAA 2001:db8:0:3:0:0:0:0

topoff.eth1.mmec02.mmegi8001.mme IN A 192.0.2.17

IN A 192.0.2.18

IN AAAA 2001:db8:0:6:0:0:0:0

IN AAAA 2001:db8:0:7:0:0:0:0

topoff.eth3.mmec02.mmegi8001.mme IN A 192.0.2.19

IN A 192.0.2.110

IN AAAA 2001:db8:0:8:0:0:0:0

IN AAAA 2001:db8:0:9:0:0:0:0

; end of file

The partially qualified MME host names are topoff.eth1.mmec01.mmegi8001., topoff.eth3.mmec02.mmegi8001.mme and similar. The (partially qualified) canonical node names are mmec01.mmegi8001.mme and mmec02.mmegi8001.mme (obtained by stripping off the first two labels of the host names).

The fully qualified MME node names are the relatively long

mmec01.mmegi8001.mme.epc.mnc990.mcc311.3gppnetwork.org.

and

mmec02.mmegi8001.mme.epc.mnc990.mcc311.3gppnetwork.org.

which are obtained by appending the value of $ORIGIN to the partially qualified MME node names. As stated before we will use the partially qualified names in this Annex to avoid this visual clutter and for typographical reasons.

Note that hostnames such as topoff.eth1.mmec01.mmegi8001.mme intentionally give back the node name mmec01.mmegi8001.mme so this record set is both for GUTI lookup and MME canonical node name lookup (and it is self consistent).

For the purposes of GUTI lookup the S10 record is sufficient for LTE only access and LTE only interworking. As stated in the comments above, S3 would be added for S4-SGSN support and the Gn/Gp records for Gn/Gp SGSN support.

For the purposes of being a canonical node record the S10 and S11 MME records are included (and they are mandatory to provision in the canonical node record of the MME).

NOTE 1: The rule for canonical node records is to always include all services that are allowed to be used on a node and are defined in 3GPP TS 23.003 [4] clause 19.4.3 for that node. Node records are meant to be complete. We have an exception here since x-3gpp-mme:x-s1-mme is explicitly optional in this release of 3GPP.

A. 3.5 APN file for "Collocated Simple LTE Example"

Reminder, the format of the APN FQDN is standardized by 3GPP TS 23.003 [4] clause 19.4.2.2 and is of form <APN-NI>.apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Service names are in 3GPP TS 23.003 [4] clause 19.4.3

There are two APN-NI in this network "imsTV1", and "imsTV2".

The file containing the APN records for this example will be CS_APN_DB.txt and has following content.

;

imsTV1.apn (

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw01.nodes )

IN NAPTR 200 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw21.nodes

; IN NAPTR 300 999 "a" "x-3gpp-pgw:x-gn:x-gp" "" topoff.vip3.gw01.nodes

; IN NAPTR 400 999 "a" "x-3gpp-pgw:x-gn:x-gp" "" topoff.vip3.gw21.nodes

IN NAPTR 500 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw01.nodes

IN NAPTR 600 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw21.nodes

IN NAPTR 700 999 "" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" set12.pgwset

; The MME can derive the NAPTR DNS record for a PGW Set based on the second label pgwset.

; Operator has imsTV1.apn using gw01.nodes when possible. Possibly one IMS core and video server

; are closer to gw01.nodes than gw21.nodes

;

; Operator only allows PMIPv6 for roaming type scenarios and only as a last choice

; The operator does not support Gn/Gp so those records are commented out

imsTV2.apn (

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 200 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw01.nodes )

IN NAPTR 100 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw21.nodes

; IN NAPTR 400 999 "a" "x-3gpp-pgw:x-gn:x-gp" "" topoff.vip3.gw01.nodes

; IN NAPTR 300 999 "a" "x-3gpp-pgw:x-gn:x-gp" "" topoff.vip3.gw21.nodes

IN NAPTR 600 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw01.nodes

IN NAPTR 500 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw21.nodes

;

; This is almost the same as imsTV1.

; However, NAPTR order values for a particular interface type are reverse in comparision

; to imsTV1.apn

;

; Operator has imsTV2.apn using gw21.nodes when possible.

; Obviously more APN would exist for a real operator

;

; end of file

If collocation were not a consideration then the APN-NI "imsTV1" causes topoff.vip1.gw01.nodes to be selected and the APN-NI "imsTV2" causes topoff.vip1.gw21.nodes to be selected. This is because in the corresponding record set the order 100 record is taken before the order 200 record in the S-NAPTR. In case of failure of a PGW then the other PGW can be used (the record with order 200). If there is deliberate bias to a specific PGW is solely the concern of this operator, the S-NAPTR procedure simply honors this.

However, collocation is a consideration (topological checks are not relevant here since all records use topoff).

The (partially qualified) PGW node names are gw01.nodes and gw21.nodes (obtained by stripping off the first two labels of the partially qualified host names topoff.vip1.gw01.nodes, topoff.vip1.gw21.nodes and so on).

A. 3.6 PGW/SGW node file for "Collocated Simple LTE Example"

The file containing the PGW/SGW canonical node name records (and A/AAAA records for the PGW/SGW nodes) for this example will be CS_SGW_PGW_NODE_DB.txt and has following content.

; Node records for the combined PGW/SGW

gw01.nodes (

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 200 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw01.nodes )

IN NAPTR 400 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw01.nodes

; IN NAPTR 500 999 "a" "x-3gpp-pgw:x-gn:x-gp" "" topoff.vip3.gw01.nodes

; Above record is commented out since this operator does not support Release 8 Gn/Gp functions

; Would have to be included otherwise

;

; Above are PGW records.

; Note this operator does NOT support PMIP for S5

; Following are SGW records

IN NAPTR 100 999 "a" "x-3gpp-sgw:x-s11" "" topoff.eth1.gw01.nodes

IN NAPTR 300 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw01.nodes

IN NAPTR 600 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw01.nodes

; IN NAPTR 700 999 "a" "x-3gpp-sgw:x-s4" "" topoff.eth6.gw01.nodes

; IN NAPTR 710 999 "a" "x-3gpp-sgw:x-s12" "" topoff.eth6.gw01.nodes

; IN NAPTR 800 999 "a" "x-3gpp-sgw:x-gn:x-gp" "" topoff.eth8.gw01.nodes

; Above records are commented out since this operator does not support any SGSN variant

; or UTRAN support. The operator is pure LTE in this example

; Above records would be included if the SGWs were able to be used with the corresponding

; SGSN function (or direct tunnel function)

;

; Reminder: Canonical node records must be complete.

;

; Exception, "x-3gpp-sgw:x-s1-u" records could be listed but are purely optional for an operator to provision

; in this release of 3GPP.

; NAPTR order plays no real role in this particular example (except for S8)

; Reasons for this example are:

; This is the PGW/SGW canonical node record so there is no node selection based from the record

; The interface type is functionally determined in most use cases using this record set except S5/S8

; This operator does NOT support PMIP for S5 and there is only one S5-GTP record.

; So order is not important except for S8.

; For S8 the operator does places PMIP with highest order just to be sure that GTP based S8 will be

; used first when possible even at re-selection of an S8 interface on the SGW or PGW as per this

; particular operators policy

; This is of course subject to the roaming agreements this operator has.

; Same record for the other combined PGW/SGW

gw21.nodes (

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 200 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw21.nodes )

IN NAPTR 400 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw21.nodes

; IN NAPTR 500 999 "a" "x-3gpp-pgw:x-gn:x-gp" "" topoff.vip3.gw21.nodes

; Above are PGW records.

; Following are SGW records

IN NAPTR 100 999 "a" "x-3gpp-sgw:x-s11" "" topoff.eth1.gw21.nodes

IN NAPTR 300 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw21.nodes

IN NAPTR 600 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw21.nodes

; IN NAPTR 700 999 "a" "x-3gpp-sgw:x-s4" "" topoff.eth6.gw21.nodes

; IN NAPTR 710 999 "a" "x-3gpp-sgw:x-s12" "" topoff.eth6.gw21.nodes

; IN NAPTR 800 999 "a" "x-3gpp-sgw:x-gn:x-gp" "" topoff.eth8.gw21.nodes

; A/AAAA records

;

; IP addresses for gw01

;

topoff.vip1.gw01.nodes IN A 192.0.2.113

IN A 192.0.2.114

IN AAAA 2001:db8:0:c:0:0:0:0

IN AAAA 2001:db8:0:d:0:0:0:0

topoff.vip2.gw01.nodes IN A 192.0.2.143

IN A 192.0.2.144

IN AAAA 2001:db8:0:2a:0:0:0:0

IN AAAA 2001:db8:0:2b:0:0:0:0

topoff.eth1.gw01.nodes IN A 192.0.2.129

IN A 192.0.2.130

IN AAAA 2001:db8:0:1c:0:0:0:0

IN AAAA 2001:db8:0:1d:0:0:0:0

topoff.eth4.gw01.nodes IN A 192.0.2.131

IN A 192.0.2.132

IN AAAA 2001:db8:0:1e:0:0:0:0

IN AAAA 2001:db8:0:1f:0:0:0:0

topoff.eth9.gw01.nodes IN A 192.0.2.133

IN A 192.0.2.134

IN AAAA 2001:db8:0:20:0:0:0:0

IN AAAA 2001:db8:0:21:0:0:0:0

; IP addresses for gw21

;

topoff.vip1.gw21.nodes IN A 192.0.2.115

IN A 192.0.2.116

IN AAAA 2001:db8:0:e:0:0:0:0

IN AAAA 2001:db8:0:f:0:0:0:0

topoff.vip2.gw21.nodes IN A 192.0.2.135

IN A 192.0.2.136

IN AAAA 2001:db8:0:22:0:0:0:0

IN AAAA 2001:db8:0:23:0:0:0:0

topoff.eth1.gw21.nodes IN A 192.0.2.137

IN A 192.0.2.138

IN AAAA 2001:db8:0:24:0:0:0:0

IN AAAA 2001:db8:0:25:0:0:0:0

topoff.eth4.gw21.nodes IN A 192.0.2.139

IN A 192.0.2.140

IN AAAA 2001:db8:0:26:0:0:0:0

IN AAAA 2001:db8:0:27:0:0:0:0

topoff.eth9.gw21.nodes IN A 192.0.2.141

IN A 192.0.2.142

IN AAAA 2001:db8:0:28:0:0:0:0

IN AAAA 2001:db8:0:29:0:0:0:0

;end of file

The above records are essentially standalone records representing the PGW/SGW node and its interfaces. An operator would normally define the records when a new node is brought into service and would only modify it when new IP interfaces or services are added to that particular node.

The fact both record types are here under the same name is a result of the PGW/SGW being collocated and having the same canonical node name.

NOTE: The rule for node records is to always include all services that are allowed to be used on a node and are defined in 3GPP TS 23.003 [4] clause 19.4.3 for that node. Node records are meant to be complete.

The lack of a record in a canonical node name record set is just as important as the records that are there. The commented out records in the example would be included for supporting S4-SGSN and/or Gn/Gp interfaces. Their absence states that the node does not support the function.

A. 3.7 TAI/TAC file for "Collocated Simple LTE Example"

The format of the TAI/TAC name is standardized by 3GPP 23.003 [4] clause 19.4.2.3 and is of form tac‑lb<TAC‑low‑byte>.tac‑hb<TAC-high-byte>.tac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org and service names are in 3GPP 23.003 [4] clause 19.4.3.

The file containing the TAI/TAC records for this example will be SIMPLE_TAI_DB.txt and has following content.

; All TAC codes for one region

*.tac-hb01.tac (

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 100 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw01.nodes )

IN NAPTR 200 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw21.nodes

IN NAPTR 300 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw01.nodes

IN NAPTR 400 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw21.nodes

; Above records are needed for SGW selection in initial attach of a UE (or TAU or handover attach)

;

IN NAPTR 500 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec01.mmegi8001.mme

IN NAPTR 600 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec02.mmegi8001.mme

; Above two records are needed for target MME selection by source MME

;

; IN NAPTR 700 999 "a" "x-3gpp-sgw:x-s11" "" topoff.eth1.gw01.nodes )

; IN NAPTR 800 999 "a" "x-3gpp-sgw:x-s11" "" topoff.eth1.gw21.nodes

; Above two S11 records are purely optional for an operator to provision and are only

; an optimizaton when included so they are commented out for this example

; IN NAPTR 900 999 "a" "x-3gpp-sgw:x-s4" "" topoff.eth6.gw01.nodes )

; IN NAPTR 1000 999 "a" "x-3gpp-sgw:x-s4" "" topoff.eth6.gw21.nodes

; This operator does not support S3/S4 so they are commented out for this example

; Above two S4 records are purely optional for an operator to provision even if S3/S4 is supported

; Note relative value of NAPTR order is important between the S5/S8 records,

; relative value of NAPTR order is important between the S10 records,

; relative value of NAPTR order is important between the S11 records

; but is not really important between different interface types used here

; (i.e. the MME selection procedure does not look for an SGW interface)

;

; This operators policy is PMIPv6 is used only as last choice

; and only for S8 they don’t allow S5 PMIPv6 at all

; All TAC codes for another region

*.tac-hb40.tac (

; IN NAPTR order pref. flag service regexp replacement

IN NAPTR 200 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw01.nodes )

IN NAPTR 100 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw21.nodes

IN NAPTR 400 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw01.nodes

IN NAPTR 300 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw21.nodes

;

IN NAPTR 600 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec01.mmegi8001.mme

IN NAPTR 500 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec02.mmegi8001.mme

;

; IN NAPTR 800 999 "a" "x-3gpp-sgw:x-s11" "" topoff.eth1.gw01.nodes )

; IN NAPTR 700 999 "a" "x-3gpp-sgw:x-s11" "" topoff.eth1.gw21.nodes

; IN NAPTR 1000 999 "a" "x-3gpp-sgw:x-s4" "" topoff.eth6.gw01.nodes )

; IN NAPTR 900 999 "a" "x-3gpp-sgw:x-s4" "" topoff.eth6.gw21.nodes

; For the example the TAC values *.tac-hb40.tac are on other side of network than the *.tac-hb01.tac

; Relative order reverses in comparison to since those TAI are closer to the other set of nodes

; end of file

SGW records are here since TAI is used to select the SGW in the initial attach procedure (and TAU with SGW change). The MME record is here for the the ‘Inter eNodeB handover with MME relocation’ procedure where a target MME must be selected by the source MME.

Wild cards are used in this example to simplify provisioning assuming that the operator picks tac codes with the same high byte for each eNodeB that are equivalent in terms of prioritization. Otherwise each TAC code needs to be provisioned individually in DNS requiring a small amount of additional repetitive provisioning as each set of TAC codes is added to a network.

From above SGW records we see only GTP based S5 so there is no PMIPv6 S5 support for the SGWs. The operator insists on GTP based S5 i.e. when one of their PGW is used and the UE is in their network (the operator does let roamers use another operators PMIPv6 PGW though). The S5/S8 SGW interfaces with (partially qualified) canonical node name gw01.nodes is used when possible for tac codes with high byte of 01 hex and the S5/S8 SGW interfaces with (partially qualified) canonical node name gw21.nodes is used when possible for tac codes with high byte of 40 hex. This follows from the NAPTR order 100 record being used before the order 200 record in the corresponding record set. This is the general mechanism an operator can use to steer the SGW selection based on which TAI the user initially attaches to (or during TAU with SGW service change). So an operator trying to minimize S1-U link costs would set the order to the smallest value for the SGW with the least cost S1-U link(s) to the eNodeB(s) serving that TAI and use higher order for the TAI corresponding to the more expensive links.

The gw01.nodes and gw21.nodes are the collocated PGW/SGW canonical node names the operator chooses. These were defined in the file CS_SGW_PGW_NODE_DB.txt.

The TAI records are not intended to determine the SGW S11 interface directly but only the candidate list SGW S5/S8 interfaces with node names. S11 interface lookup can be done from the SGW canonical node name (see records in CS_SGW_PGW_NODE_DB.txt ) so inclusion of S11 here is not strictly needed.

A. 3.8 MME lookup based on GUTI for "Simple LTE Example"

Here we "manually" execute the S-NAPTR procedure using the standard "dig" command for finding the source MME at the target MME (for example in a TAU procedure) to illustrate the procedure and show how the DNS records work in practice.

The target MME receives the LTE UE’s old GUTI. The target MME extracts the MNC, MCC, MMEC and MMEGI values. In this example the UE is in a cell where the MME selected by the RAN is assumed to be MMEC=1 and MMEGI=8000 hexadecimal. The MME creates the Application Unique String mmec01.mmegi8001.mme.$ORIGIN (see clause 4.3.3.4 of this TS)

NOTE: Reminder $ORIGIN is epc.mnc990.mcc311.3gppnetwork.org. and is employed here simply to keep the length of the example text manageable.

The target MME starts the S-NAPTR with Application Unique String = mmec01.mmegi8001.mme.$ORIGIN and desired services x-3gpp-mme:x-s10 since it is trying to contact the old MME to do a context transfer.

Here we emulate the same action manually with the dig command.

——— Command to DNS server———-

command: dig @192.0.2.247 +tcp NAPTR mmec01.mmegi8001.mme.$ORIGIN

———Start Response from DNS server———-

; <<>> DiG 9.5.0-P2-W2 <<>> @192.0.2.247 +tcp NAPTR mmec01.mmegi8001.mme.$ORIGIN

; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1399

;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 10

;; WARNING: recursion requested but not available

;; QUESTION CLAUSE:

;mmec01.mmegi8001.mme.$ORIGIN. IN NAPTR

;; ANSWER CLAUSE:

mmec01.mmegi8001.mme.$ORIGIN. 3600 IN NAPTR 100 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN.

mmec01.mmegi8001.mme.$ORIGIN. 3600 IN NAPTR 200 999 "a" "x-3gpp-mme:x-s11" "" topoff.eth3.mmec01.mmegi8001.mme.$ORIGIN.

;; AUTHORITY CLAUSE:

$ORIGIN. 3600 IN NS ns1.$ORIGIN.

$ORIGIN. 3600 IN NS ns2.$ORIGIN.

;; ADDITIONAL CLAUSE:

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.12

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.11

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8::

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8:0:1::

topoff.eth3.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.14

topoff.eth3.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.13

topoff.eth3.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8:0:2::

topoff.eth3.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8:0:3::

ns1.$ORIGIN. 3600 IN A 192.0.2.247

ns2.$ORIGIN. 3600 IN A 192.0.2.248

;; Query time: 15 msec

;; SERVER: 192.0.2.247#53(192.0.2.247)

;; WHEN: Wed Jan 21 16:30:20 2009

;; MSG SIZE rcvd: 524

———End Response from DNS server———-

MME retains only NAPTR with matching services matching x-3gpp-mme:x-s10 yielding

NAPTR record set

replacement service flag order preference

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN x-3gpp-mme:x-s10 "a" 100 999

MME node sorts the NAPTR records by RFC 3958 rules. Obviously since this is a list of only one record it yields the same list back again unchanged.

Since the record is the terminal ("a") flag we have the host name (and canonical node name inside it).

Formally the A/AAAA record lookup can be performed at this point or it can be deferred until a later step.

The MME can store the important content now

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN services of x-3gpp-mme:x-s10

Because there is only one match the MME now has the final candidate list (except for IP addresses).

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN services of x-3gpp-mme:x-s10

Note the needed A/AAAA records for topoff.eth1.mmec01.mmegi8001.mme are already present in the additional record clause of the response.

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.12

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.11

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8::

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8:0:1::

If the records had not been available in the additional record clause of the response then the MME would have had to done the A/AAAA record lookups directly. Emulated by dig command they would have been

command: dig @192.0.2.247 +tcp A topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN

and

command: dig @192.0.2.247 +tcp AAAA topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN

command: dig @192.0.2.247 +tcp ANY topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN

Regardless of the source of the A and AAAA records, the order of the A records shall be randomly shuffled by the MME. The same shall be done for the AAAA records. (For our "manual" example it will be a coin flip as to which of the two records is first).

The MME now has a candidate list (very short here) with the needed IPv4 and IPv6 addresses. I.e.:

(topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN, services of x-3gpp-mme:x-s10, {192.0.2.12,192.0.2.11}, { 2001:db8::, 2001:db8:0:1:: } )

The target MME then can use the IPv4 (or IPv6) addresses to contact the source MME over S10 to get the UE’s context information from the old MME.

When an operator uses only NAPTR flag "a" records the S-NAPTR procedure will only require one NAPTR lookup from the Application Unique String in all cases greatly streamlining the DNS lookups. Also assuming a modern DNS server where the NAPTR and A/AAAA records in the same DNS server the needed A/AAAA records are likely to be in the additional record clause (as the above real output shows).

However, the needed A/AAAA records would NOT have been present even in this small example if the DNS resolver (dig here) had not used TCP transport (or EDNS0 for UDP) since the packet size of the response in this example was 524 bytes which exceeds the 512 byte limit for using UDP transport without EDNS0.

A. 3.9 APN lookup for "Simple LTE Example" (i.e. PGW candidate list)

Assume a non-roaming LTE UE indicates it want to use APN-NI string "imsTV2" to the MME in our example network at initial attach.

NOTE 1: Reminder $ORIGIN is epc.mnc990.mcc311.3gppnetwork.org. and is employed here simply to keep the length of the example text manageable

The MME starts the S-NAPTR procedure with Application Unique String = imsTV2.apn.$ORIGIN and desired services x-3gpp-pgw:x-s5-gtp and x-3gpp-pgw:x-s5-pmip.

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

MME starts with Application Unique String = imsTV2.apn.$ORIGIN and the desired services x-3gpp-pgw:x-s5-gtp and x-3gpp-pgw:x-s5-pmip

——— Command to DNS server———-

command: dig @192.0.2.247 +tcp NAPTR imsTV2.apn.$ORIGIN

———Start Response from DNS server———-

; <<>> DiG 9.5.0-P2-W2 <<>> @192.0.2.247 +tcp NAPTR imsTV2.apn.$ORIGIN

; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1796

;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 18

;; WARNING: recursion requested but not available

;; QUESTION CLAUSE:

;imsTV2.apn.$ORIGIN. IN NAPTR

;; ANSWER CLAUSE:

imsTV2.apn.$ORIGIN. 3600 IN NAPTR 600 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw01.node.$ORIGIN.

imsTV2.apn.$ORIGIN. 3600 IN NAPTR 100 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw21.node.$ORIGIN.

imsTV2.apn.$ORIGIN. 3600 IN NAPTR 200 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw01.node.$ORIGIN.

imsTV2.apn.$ORIGIN. 3600 IN NAPTR 500 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw21.node.$ORIGIN.

;; AUTHORITY CLAUSE:

$ORIGIN. 3600 IN NS ns2.$ORIGIN.

$ORIGIN. 3600 IN NS ns1.$ORIGIN.

;; ADDITIONAL CLAUSE:

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

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

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

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

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

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

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

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

topoff.vip2.gw21.node.$ORIGIN. 3600 IN A 192.0.2.136

topoff.vip2.gw21.node.$ORIGIN. 3600 IN A 192.0.2.135

topoff.vip2.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:22::

topoff.vip2.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:23::

topoff.vip2.gw01.node.$ORIGIN. 3600 IN A 192.0.2.144

topoff.vip2.gw01.node.$ORIGIN. 3600 IN A 192.0.2.143

topoff.vip2.gw01.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:2a::

topoff.vip2.gw01.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:2b::

ns1.$ORIGIN. 3600 IN A 192.0.2.247

ns2.$ORIGIN. 3600 IN A 192.0.2.248

;; Query time: 0 msec

;; SERVER: 192.0.2.247#53(192.0.2.247)

;; WHEN: Wed Jan 21 19:21:14 2009

;; MSG SIZE rcvd: 890

———End Response from DNS server———-

MME retains only NAPTR records with matching services x-3gpp-pgw:x-s5-gtp and

x-3gpp-pgw:x-s5-pmip yielding:

NAPTR record set

replacement service flag order preference

topoff.vip1.gw21.node.$ORIGIN x-3gpp-pgw:x-s5-gtp:x-s8-gtp "a" 100 999

topoff.vip1.gw01.node.$ORIGIN x-3gpp-pgw:x-s5-gtp:x-s8-gtp "a" 200 999

; Note the x-s8-gtp are not really included but are kept here to allow the

; reader to see which NAPTR record was kept from the DNS response.

; The DNS server "luckily" returns this in sorted order but the MME must sort it .

; The DNS server is not responsible for sorting but the DNS resolver (i.e. the MME)

MME node sorts NAPTR by RFC 3958 yielding

NAPTR record set

replacement service flag order preference

topoff.vip1.gw21.node.$ORIGIN x-3gpp-pgw:x-s5-gtp:x-s8-gtp "a" 100 999

topoff.vip1.gw01.node.$ORIGIN x-3gpp-pgw:x-s5-gtp:x-s8-gtp "a" 200 999

MME Stores records since they are flag "a"

topoff.vip1.gw21.node.$ORIGIN services of x-3gpp-pgw:x-s5-gtp

topoff.vip1.gw01.node.$ORIGIN services of x-3gpp-pgw:x-s5-gtp

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

topoff.vip1.gw21.node.$ORIGIN services of x-3gpp-pgw:x-s5-gtp

topoff.vip1.gw01.node.$ORIGIN services of x-3gpp-pgw:x-s5-gtp

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

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

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

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

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

and

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

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

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

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

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

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

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

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

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

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

(topoff.vip1.gw21.node.$ORIGIN ,services of x-3gpp-pgw:x-s5-gtp , {192.0.2.115,192.0.2.116}, { 2001:db8:0:e::,2001:db8:0:f::} )

(topoff.vip1.gw01.node.$ORIGIN ,services of x-3gpp-pgw:x-s5-gtp , {192.0.2.114,192.0.2.113}, { 2001:db8:0:c::, 2001:db8:0:d::)

The fact that the node topoff.vip1.gw21.node.$ORIGIN comes first is a direct result of the two different NAPTR order values.

NOTE 2: This is the last example in this Annex with A and AAAA lookups and IP addresses explicitly included in the candidate list. This detail is left for the reader for the remaining clauses.

For the initial attach case the candidate list of SGW has to be formally found to handle the collocated PGW and SGW case. The SGW candidate list is found in the next clause.

NOTE 3: If this DNS procedure was being used for an additional PDN connection for a UE with an existing SGW rather than a first attach, then the MME would check to see if the current SGW node name matches any of the PGW node names in the above list (gw01.node.$ORIGIN and gw21.node.$ORIGIN) to try to pick a collocated PGW on the current SGW. The canonical node name record of the current SGW can be used by the MME to find all S5/S8 SGW interfaces on the current PGW. This is a smaller example of what follows so we do not detail it further.

A. 3.10 TAI lookup for "Simple LTE Example" (i.e. SGW candidate list)

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

NOTE 1: Reminder $ORIGIN is epc.mnc990.mcc311.3gppnetwork.org. and is employed here simply to keep the length of the example text manageable.

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

The MME starts the S-NAPTR procedure with Application Unique String = tac-lb11.tac-hb40.tac.$ORIGIN and desired services x-3gpp-sgw:x-s11,x-3gpp-sgw:x-s5-gtp, x-3gpp-sgw:x-s5-pmip.

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

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

MME starts with Application Unique String = tac-lb11.tac-hb40.tac.$ORIGIN

desired services x-3gpp-sgw:x-s11,x-3gpp-sgw:x-s5-gtp,x-3gpp-sgw:x-s5-pmip

——— Command to DNS server———-

command: dig @192.0.2.247 +tcp NAPTR tac-lb11.tac-hb40.tac.$ORIGIN

———Start Response from DNS server———-

; <<>> DiG 9.5.0-P2-W2 <<>> @192.0.2.247 +tcp NAPTR tac-lb11.tac-hb40.tac.$ORIGIN

; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 622

;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 26

;; WARNING: recursion requested but not available

;; QUESTION CLAUSE:

;tac-lb11.tac-hb40.tac.$ORIGIN. IN NAPTR

;; ANSWER CLAUSE:

tac-lb11.tac-hb40.tac.$ORIGIN. 3600 IN NAPTR 400 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw01.node.$ORIGIN.

tac-lb11.tac-hb40.tac.$ORIGIN. 3600 IN NAPTR 500 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec02.mmegi8001.mme.$ORIGIN.

tac-lb11.tac-hb40.tac.$ORIGIN. 3600 IN NAPTR 600 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN.

tac-lb11.tac-hb40.tac.$ORIGIN. 3600 IN NAPTR 100 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw21.node.$ORIGIN.

tac-lb11.tac-hb40.tac.$ORIGIN. 3600 IN NAPTR 200 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw01.node.$ORIGIN.

tac-lb11.tac-hb40.tac.$ORIGIN. 3600 IN NAPTR 300 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw21.node.$ORIGIN.

;; AUTHORITY CLAUSE:

$ORIGIN. 3600 IN NS ns2.$ORIGIN.

$ORIGIN. 3600 IN NS ns1.$ORIGIN.

;; ADDITIONAL CLAUSE:

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

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

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

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

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

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

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

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

topoff.eth9.gw21.node.$ORIGIN. 3600 IN A 192.0.2.142

topoff.eth9.gw21.node.$ORIGIN. 3600 IN A 192.0.2.141

topoff.eth9.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:28::

topoff.eth9.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:29::

topoff.eth9.gw01.node.$ORIGIN. 3600 IN A 192.0.2.134

topoff.eth9.gw01.node.$ORIGIN. 3600 IN A 192.0.2.133

topoff.eth9.gw01.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:20::

topoff.eth9.gw01.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:21::

topoff.eth1.mmec02.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.18

topoff.eth1.mmec02.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.17

topoff.eth1.mmec02.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8:0:6::

topoff.eth1.mmec02.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8:0:7::

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.12

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN A 192.0.2.11

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8::

topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN. 3600 IN AAAA 2001:db8:0:1::

ns1.$ORIGIN. 3600 IN A 192.0.2.247

ns2.$ORIGIN. 3600 IN A 192.0.2.248

;; Query time: 0 msec

;; SERVER: 192.0.2.247#53(192.0.2.247)

;; WHEN: Wed Jan 21 19:33:00 2009

;; MSG SIZE rcvd: 1285

———End Response from DNS server———-

MME retains only the NAPTR with matching services x-3gpp-sgw:x-s11,x-3gpp-sgw:x-s5-gtp,

and x-3gpp-sgw:x-s5-pmip yielding

NAPTR record set

replacement service flag order preference

topoff.eth4.gw01.node.$ORIGIN x-3gpp-sgw:x-s5-gtp:x-s8-gtp "a" 200 999

topoff.eth4.gw21.node.$ORIGIN x-3gpp-sgw:x-s5-gtp:x-s8-gtp "a" 100 999

; Note the x-s8-gtp are not really included but are kept here to allow the

; reader to see which NAPTR record was kept from the DNS response.

MME node sorts the NAPTR records by RFC 3958 yielding

NAPTR record set

replacement service flag order preference

topoff.eth4.gw21.node.$ORIGIN x-3gpp-sgw:x-s5-gtp:x-s8-gtp "a" 100 999

topoff.eth4.gw01.node.$ORIGIN x-3gpp-sgw:x-s5-gtp:x-s8-gtp "a" 200 999

MME Stores

topoff.eth4.gw21.node.$ORIGIN services of x-3gpp-sgw:x-s5-gtp

topoff.eth4.gw01.node.$ORIGIN services of x-3gpp-sgw:x-s5-gtp

MME now has candidate list

topoff.eth4.gw21.node.$ORIGIN services of x-3gpp-sgw:x-s5-gtp

topoff.eth4.gw01.node.$ORIGIN services of x-3gpp-sgw:x-s5-gtp

Again the A/AAAA records were available in the additional record clause.

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

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

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

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

and

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

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

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

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

NOTE: The size of the response was 1285 bytes and indicates why EDNS0 or TCP transport should be used for S-NAPTR when feasible. Most of the data in the Additional Record Clause would not have been available if only 512 bytes had been sent.

A. 3.11 Finding the collocated SGW and PGW together

IP addresses are not included here for readability.

We are now in a position to look at both the SGW candidate list and PGW candidate list at the same time.

From A.3.9 we had the PGW candidate list for the APN-NI "imsTV2" was

topoff.vip1.gw21.node.$ORIGIN services of x-3gpp-pgw:x-s5-gtp

topoff.vip1.gw01.node.$ORIGIN services of x-3gpp-pgw:x-s5-gtp

From A.3.10 we had the SGW candidate list for TAI where low byte ofTAC is hex 11 and the high byte is hex 40 was

topoff.eth4.gw21.node.$ORIGIN services of x-3gpp-sgw:x-s5-gtp

topoff.eth4.gw01.node.$ORIGIN services of x-3gpp-sgw:x-s5-gtp

We only have GTPv2 so the protocols match.

Both nodes gw21.node.$ORIGIN and gw01.node.$ORIGIN are collocated.

Hence, moving the collocated nodes to the front of both lists leaves them unchanged.

The procedure requires we use the SGW ordering to select the SGW first.

Hence, the SGW interface to try first is topoff.eth4.gw21.node.$ORIGIN

That is node gw21.node.$ORIGIN.

That means the PGW record that is collocated is:

topoff.vip1.gw21.node.$ORIGIN services of x-3gpp-pgw:x-s5-gtp

which is the first PGW interface to try.

NOTE: It is an "accident" that this is the same order as the APN-NI "imsTV2" gave back. If APN-NI had been "imsTV1" the order would have been reversed in the PGW candidate list and it would NOT have been first. Again the collocation ordering takes precedence.

The MME would use the IP addresses from the records (not shown) for the S11 Create Session Request attempt.

Assuming it succeeds we would not need to try any other PGW or SGW records.

The MME needs the S11 interface so it can physically send the Create Session Request to the SGW. That is covered in the next clause.

A. 3.12 S11 lookup by SGW canonical node name

Assume an SGW has been picked with canonical node name of gw21.node.$ORIGIN

The MME starts with Application Unique String = gw21.node.$ORIGIN obtained from the SGW selection with.desired services x-3gpp-sgw:x-s11

——— Command to DNS server———-

command: dig @192.0.2.247 +tcp NAPTR gw21.node.$ORIGIN

———Start Response from DNS server———-

; <<>> DiG 9.5.0-P2-W2 <<>> @192.0.2.247 +tcp NAPTR gw21.node.$ORIGIN

; (1 server found)

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23

;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 22

;; WARNING: recursion requested but not available

;; QUESTION CLAUSE:

;gw21.node.$ORIGIN. IN NAPTR

;; ANSWER CLAUSE:

gw21.node.$ORIGIN. 3600 IN NAPTR 600 999 "a" "x-3gpp-sgw:x-s8-pmip" "" topoff.eth9.gw21.node.$ORIGIN.

gw21.node.$ORIGIN. 3600 IN NAPTR 100 999 "a" "x-3gpp-sgw:x-s11" "" topoff.eth1.gw21.node.$ORIGIN.

gw21.node.$ORIGIN. 3600 IN NAPTR 200 999 "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp" "" topoff.vip1.gw21.node.$ORIGIN.

gw21.node.$ORIGIN. 3600 IN NAPTR 300 999 "a" "x-3gpp-sgw:x-s5-gtp:x-s8-gtp" "" topoff.eth4.gw21.node.$ORIGIN.

gw21.node.$ORIGIN. 3600 IN NAPTR 400 999 "a" "x-3gpp-pgw:x-s8-pmip" "" topoff.vip2.gw21.node.$ORIGIN.

;; AUTHORITY CLAUSE:

$ORIGIN. 3600 IN NS ns2.$ORIGIN.

$ORIGIN. 3600 IN NS ns1.$ORIGIN.

;; ADDITIONAL CLAUSE:

topoff.eth1.gw21.node.$ORIGIN. 3600 IN A 192.0.2.138

topoff.eth1.gw21.node.$ORIGIN. 3600 IN A 192.0.2.137

topoff.eth1.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:24::

topoff.eth1.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:25::

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

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

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

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

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

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

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

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

topoff.vip2.gw21.node.$ORIGIN. 3600 IN A 192.0.2.136

topoff.vip2.gw21.node.$ORIGIN. 3600 IN A 192.0.2.135

topoff.vip2.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:22::

topoff.vip2.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:23::

topoff.eth9.gw21.node.$ORIGIN. 3600 IN A 192.0.2.141

topoff.eth9.gw21.node.$ORIGIN. 3600 IN A 192.0.2.142

topoff.eth9.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:29::

topoff.eth9.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:28::

ns1.$ORIGIN. 3600 IN A 192.0.2.247

ns2.$ORIGIN. 3600 IN A 192.0.2.248

;; Query time: 0 msec

;; SERVER: 192.0.2.247#53(192.0.2.247)

;; WHEN: Wed Jan 21 19:45:36 2009

;; MSG SIZE rcvd: 1072

———End Response from DNS server———-

MME retains only the NAPTR records with matching service x-3gpp-sgw:x-s11 yielding

NAPTR record set

replacement service flag order preference

topoff.eth1.gw21.node.$ORIGIN x-3gpp-sgw:x-s11 "a" 100 999

MME node sorts NAPTR by RFC 3958 (trivially here) yielding

NAPTR record set

replacement service flag order preference

topoff.eth1.gw21.node.$ORIGIN x-3gpp-sgw:x-s11 "a" 100 999

MME Stores

topoff.eth1.gw21.node.$ORIGIN services of x-3gpp-sgw:x-s11

MME now has candidate list

topoff.eth1.gw21.node.$ORIGIN services of x-3gpp-sgw:x-s11

Again the needed A and AAAA records are in the additional record clause

topoff.eth1.gw21.node.$ORIGIN. 3600 IN A 192.0.2.138

topoff.eth1.gw21.node.$ORIGIN. 3600 IN A 192.0.2.137

topoff.eth1.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:24::

topoff.eth1.gw21.node.$ORIGIN. 3600 IN AAAA 2001:db8:0:25::

A. 3.13 TAI lookup for "Colocation Simple LTE Example" (i.e. MME candidate list)

This type of lookup is done for the "Inter eNodeB handover with MME relocation" procedure where the old MME selects the target MME in a new TAI.

The service is x-3gpp-mme:x-s10 again.

Since this also starts with the TAI NAPTR lookup we have the same type of record set as the SGW selection from TAI clause (see A.3.10) and to not waste space the same TAC value will be used.

The only difference from that clause starts with which NAPTR records match.

From the Answer clause these are:

;; ANSWER CLAUSE:

tac-lb11.tac-hb40.tac.$ORIGIN. 3600 IN NAPTR 500 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec02.mmegi8001.mme.$ORIGIN.

tac-lb11.tac-hb40.tac.$ORIGIN. 3600 IN NAPTR 600 999 "a" "x-3gpp-mme:x-s10" "" topoff.eth1.mmec01.mmegi8001.mme.$ORIGIN.

Which are already in order. The NAPTR order of 500 is less than NAPTR order of 600.

So S10 interfaces in order are:

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

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

and the needed A/AAAA records from the Additional clause in the DNS response in clause A.3.10 are: