Tech-invite  3GPPspace  IETF RFCs  SIP
index  N  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.003  Word version:  18.2.0

Top   Top   Up   Prev   Next
1…   2…   2.8…   3…   4…   5…   6…   7…   8…   9…   10…   11   12…   13…   14…   15…   16…   17…   18…   19…   19.4…   19.5…   20…   21…   22…   23…   24…   25…   26…   27…   28…   28.3.2.2…   28.3.2.2.6…   28.3.2.3…   28.4…   28.7…   28.8…   29…   A…   B…   C…   D   E… 
19.4 Identifiers for Domain Name System procedures  19.4.1 Introduction  19.4.2 Fully Qualified Domain Names (FQDNs)  19.4.3 Service and Protocol service names for 3GPP 
...

 

19.4  Identifiers for Domain Name System procedures  p. 79

19.4.1  Introduction  p. 79

This clause describes Domain Name System (DNS) related identifiers used by the procedures specified in TS 29.303.
The DNS identifiers for APNs for legacy systems (as defined in clause 9), RAIs (as defined in clause C.1, GSNs (as defined in clause C.2) and RNCs (as defined in clause C.3) in the present document use the top level domain ".gprs" and have a similar purpose and function as those described below. These clauses are still valid and DNS records based on these and the below types of identifiers are expected to coexist in an operator's network for the purpose of backwards compatibility and interworking with legacy networks.
The APN as defined in clause 9 is used also in EPC to identify the access network to be used for a specific PDN connection or PDP Context. In addition, the APN Network Identifier (APN-NI) part of the APN as defined in clause 9.1.1 of the present document may be used to access a service associated with a PDN-GW or GGSN. This is achieved by defining an APN which in addition to being usable to select a PDN-GW or GGSN is locally interpreted by the PDN-GW or GGSN as a request for a specific service.
For DNS procedures defined in TS 29.303, an APN-FQDN derived from a given APN is used instead of the APN itself as defined in clause 19.4.2.2. For all other purposes, including communication between EPC nodes and to the UE, the APN format defined in clause 9 is used. In order to support backwards compatibility with existing GPRS/PS roaming using the Gn/Gp interfaces, the APN as specified in clause 9 of the present document may also be used for the DNS procedures as defined in TS 23.060.
Up

19.4.2  Fully Qualified Domain Names (FQDNs)  p. 80

19.4.2.1  General  p. 80

The encoding of any identifier used as part of a Fully Qualifed Domain Name (FQDN) shall follow the Name Syntax defined in RFC 2181, RFC 1035 and RFC 1123. An FQDN consists of one or more labels. Each label is coded as a one octet length field followed by that number of octets coded as 8 bit ASCII characters. Following RFC 1035 the labels shall consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following RFC 1123, the label shall begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not significant. Identifiers are not terminated by a length byte of zero.
For the purpose of presentation, identifiers are usually displayed as a string in which the labels are separated by dots (e.g. "Label1.­Label2.­Label3").
Up

19.4.2.2  Access Point Name FQDN (APN-FQDN)  p. 80

19.4.2.2.1  Structure  p. 80
The Access Point Name FQDN (APN-FQDN) is derived from an APN as follows. The APN consists of an APN Network Identifier (APN-NI) and an APN Operator Identifier (APN-OI), which are as defined in clause 9.1.1 and 9.1.2 of the present document.
If an APN is constructed using the default APN-OI, the APN-FQDN shall be obtained from the APN by inserting the labels "apn.epc." between the APN-NI and the default APN - OI, and by replacing the label ".gprs" at the end of the default APN-OI with the labels ".3gppnetwork.­org".
EXAMPLE1:
For an APN of internet.­mnc015.­mcc234.­gprs, the derived APN-FQDN is internet.­apn.­epc.­mnc015.­mcc234.­3gppnetwork.­org
If an APN is constructed using the APN-OI Replacement field (as defined in TS 23.060 and TS 23.401), the APN-FQDN shall be obtained from the APN by inserting the labels "apn.epc." between the label "mnc<MNC>" and its preceding label, and by replacing the label ".gprs" at the end of the APN-OI Replacement field with the labels ".3gppnetwork.­org".
EXAMPLE 2:
If an APN-OI Replacement field is province1.­mnc015.­mcc234.­gprs and an APN-NI is internet, the derived APN-FQDN is internet.­province1.­apn.­epc.­mnc015.­mcc234.­3gppnetwork.­org
Up
19.4.2.2.2  Void
19.4.2.2.3  Void
19.4.2.2.4  Void

19.4.2.3  Tracking Area Identity (TAI)  p. 81

The Tracking Area Identity (TAI) consists of a Mobile Country Code (MCC), Mobile Network Code (MNC), and Tracking Area Code (TAC). It is composed as shown in Figure 19.4.2.3.1.
Reproduction of 3GPP TS 23.003, Fig. 19.4.2.3.1: Structure of the Tracking Area Identity (TAI)
Figure 19.4.2.3.1: Structure of the Tracking Area Identity (TAI)
Up
The TAI is composed of the following elements:
  • Mobile Country Code (MCC) identifies the country in which the PLMN is located. The value of the MCC is the same as the three digit MCC contained in the IMSI;
  • Mobile Network Code (MNC) is a code identifying the PLMN in that country. The value of the MNC is the same as the two or three digit MNC contained in the IMSI;
  • Tracking Area Code (TAC) is a fixed length code (of 2 octets) identifying a Tracking Area within a PLMN. This part of the tracking area identification shall be coded using a full hexadecimal representation. The following are reserved hexadecimal values of the TAC:
    • 0000, and
    • FFFE.
A subdomain name can be derived from the TAI. This shall be done by adding the label "tac" to the beginning of the Home Network Realm/Domain (see clause 19.2) and encoding the TAC as a sub-domain. This is called the TAI FQDN..
The TAI FQDN shall be constructed as follows:
tac-lb<TAC-low-byte>.­tac-hb<TAC-high-byte>.­tac.­epc.­mnc<MNC>.­mcc<MCC>.3gppnetwork.­org
The TAC is a 16-bit integer. The <TAC-high-byte> is the hexadecimal string of the most significant byte in the TAC and the <TAC-low-byte > is the hexadecimal string of the least significant byte. If there are less than 2 significant digits in <TAC-high-byte> or <TAC-low-byte >, "0" digit(s) shall be inserted at the left side to fill the 2 digit coding.
Up

19.4.2.4  Mobility Management Entity (MME)  p. 81

A Mobility Management Entity (MME) within an operator's network is identified using a MME Group ID (MMEGI), and an MME Code (MMEC).
A subdomain name shall be derived from the MNC and MCC by adding the label "mme" to the beginning of the Home Network Realm/Domain (see clause 19.2).
The MME node FQDN shall be constructed as:
mmec<MMEC>.­mmegi<MMEGI>.­mme.­epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
Where <MMEC> and <MMEGI> are the hexadecimal strings of the MMEC and MMEGI.
An MME pool FQDN shall be constructed as:
mmegi<MMEGI>.­mme.­epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
If there are less than 2 significant digits in <MMEC>, "0" digit(s) shall be inserted at the left side to fill the 2 digit coding. If there are less than 4 significant digits in <MMEGI>, "0" digit(s) shall be inserted at the left side to fill the 4 digit coding.
Up

19.4.2.5  Routing Area Identity (RAI) - EPC  p. 82

The Routing Area Identity (RAI) consists of a RAC, LAC, MNC and MCC.
A subdomain name for use by core network nodes based on RAI shall be derived from the MNC and MCC by adding the label "rac" to the beginning of the Home Network Realm/Domain (see clause 19.2).
The RAI FQDN shall be constructed as:
rac<RAC>.­lac<LAC>.­rac.­epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
<RAC> and <LAC> shall be Hex coded digits representing the LAC and RAC codes respectively.
If there are less than 4 significant digits in <RAC> or <LAC>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding.
Up

19.4.2.6  Serving GPRS Support Node (SGSN) within SGSN pool  p. 82

A specific SGSN within an operator's network is identified using the RAI FQDN (clause 19.4.2.5) and the Network Resource Identifier (NRI) (see TS 23.236). Such an identifier can be used by a target MME or SGSN node to connect to the source SGSN node.
The SGSN FQDN shall be constructed as:
nri-sgsn<NRI>.­rac<RAC>.­lac<LAC>.­rac.­epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
<NRI> shall be Hex coded digits representing the NRI code of the SGSN.
If there are less than 4 significant digits in < NRI>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding. Coding for other fields is the same as in Clause 19.4.2.5.
When a target MME constructs the FQDN of the source SGSN in the case of SGSN pooling, it should derive the NRI from the 8-bit MME Code received in the GUTI from the UE. However, if the length of the NRI, e.g., X, which is configured in the MME is less than 8 bits, then the MME should use only the most significant X bits of the MME Code as the NRI within the SGSN FQDN.
Up

19.4.2.7  Target RNC-ID for U-TRAN  p. 82

In the special case of a UTRAN target RNC a possible SGSN that can control that RNC can be identified by RNC-ID. This identifier can be used for SRNS relocation with a U-TRAN target RNC.
A subdomain name for use by core network nodes based on RNC-ID shall be derived from the MNC and MCC by adding the label "rnc" to the beginning of the Home Network Realm/Domain (see clause 19.2).
The RNC FQDN shall be constructed as:
rnc<RNC>.rnc.­epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
<RNC> shall be Hex coded digits representing the RNC-ID code of the RNC.
If there are less than 4 significant digits in <RNC>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding.
Up

19.4.2.8  DNS subdomain for operator usage in EPC  p. 83

The EPC nodes DNS subdomain (DNS zone) shall be derived from the MNC and MCC by adding the label "node" to the beginning of the Home Network Realm/Domain (see clause 19.2) and shall be constructed as:
node.epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
This DNS subdomain is formally placed into the operator's control. 3GPP shall never take this DNS subdomain back or any zone cut/subdomain within it for any purpose. As a result the operator can safely provision any DNS records it chooses under this subdomain without concern about future 3GPP standards encroaching on the DNS names within this zone.
Up

19.4.2.9  ePDG FQDN and Visited Country FQDN for non-emergency bearer services  p. 83

19.4.2.9.1  General |R13|  p. 83
The ePDG Fully Qualified Domain Name (ePDG FQDN), for non-emergency bearers services, shall be constructed using one of the following formats, as specified in clause 4.5.4 of TS 23.402:
  • Operator Identifier based ePDG FQDN;
  • Tracking/Location Area Identity based ePDG FQDN;
  • the ePDG FQDN configured in the UE by the HPLMN.
The Visited Country FQDN is used by a roaming UE to determine whether the visited country mandates the selection of an ePDG in this country (see clause 4.5.4.5 of TS 23.402). The Visited Country FQDN shall be constructed as specified in clause 19.4.2.9.4. The Replacement field used in DNS-based Discovery of regulatory requirements shall be constructed as specified in clause 19.4.2.9.5.
Up
19.4.2.9.2  Operator Identifier based ePDG FQDN |R13|  p. 83
The ePDG Fully Qualified Domain Name (ePDG FQDN) contains an Operator Identifier that shall uniquely identify the PLMN where the ePDG is located. The ePDG FQDN is composed of seven labels. The last three labels shall be "pub.3gppnetwork.org". The third and fourth labels together shall uniquely identify the PLMN. The first two labels shall be "epdg.epc". The ePDG FQDN shall be constructed as follows:
"epdg.epc.mnc<MNC>.­mcc<MCC>.­pub.­3gppnetwork.­org"
In the roaming case, the UE can utilise the services of the VPLMN or the HPLMN (see TS 23.402 and TS 24.302). In this case, the Operator Identifier based ePDG FQDN shall be constructed as described above, but using the MNC and MCC of the VPLMN or the HPLMN.
In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the "epdg.epc. mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" format of the Operator Identifier based ePDG FQDN shall be:
  • <MNC> = 3 digits
  • <MCC> = 3 digits
If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the ePDG FQDN.
As an example, the Operator Identifier based ePDG FQDN for MCC 345 and MNC 12 is coded in the DNS as:
  • "epdg.epc.mnc012.­mcc345.­pub.­3gppnetwork.­org".
Up
19.4.2.9.3  Tracking/Location Area Identity based ePDG FQDN |R13|  p. 84
The Tracking/Location Area Identity based ePDG FQDN is used to support location based ePDG selection within a PLMN.
There are two Tracking Area Identity based ePDG FQDNs defined: one based on a TAI with a 2 octet TAC and a 5GS one based on a 3 octet TAC.
1)
The Tracking Area Identity based ePDG FQDN using a 2 octet TAC and the Location Area Identity based ePDG FQDN shall be constructed respectively as:
"tac-lb<TAC-low-byte>.­tac-hb<TAC-high-byte>.­tac.­epdg.­epc.­mnc<MNC>.­mcc<MCC>.pub.­3gppnetwork.­org"
and
"lac<LAC>.epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org"
where
  • the <MNC> and <MCC> shall identify the PLMN where the ePDG is located and shall be encoded as
    • <MNC> = 3 digits
    • <MCC> = 3 digits
      If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the ePDG FQDN.
  • the <TAC>, together with the <MCC> and <MNC> shall identify the Tracking Area Identity the UE is located in.
    The TAC is a 16-bit integer. The <TAC-high-byte> is the hexadecimal string of the most significant byte in the TAC and the <TAC-low-byte > is the hexadecimal string of the least significant byte. If there are less than 2 significant digits in <TAC-high-byte> or <TAC-low-byte >, "0" digit(s) shall be inserted at the left side to fill the 2 digit coding;
  • the <LAC>, together with the <MCC> and <MNC> shall identify the Location Area Identity the UE is located in.
    The <LAC> shall be hexadecimal coded digits representing the LAC; if there are less than 4 significant digits in <LAC>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit coding;
As examples,
  • the Tracking Area Identity based ePDG FQDN for the TAC H'0B21, MCC 345 and MNC 12 is coded in the DNS as:
    "tac-lb21.­tac-hb0b.­tac.­epdg.­epc.­mnc012.­mcc345.­pub.­3gppnetwork.­org"
  • the Location Area Identity based ePDG FQDN for the LAC H'0B21, MCC 345 and MNC 12 is coded in the DNS as:
    "lac0b21.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org"
2)
The 5GS Tracking Area Identity based ePDG FQDN using a 3 octet TAC shall be constructed respectively as:
"tac-lb<TAC-low-byte>.­tac-mb<TAC-middle-byte>.­tac-hb<TAC-high-byte>.­5gstac.­epdg.­epc.­mnc<MNC>.­mcc<MCC>.­pub.­3gppnetwork.­org"
where
  • the <MNC> and <MCC> shall identify the PLMN where the ePDG is located and shall be encoded as
    • <MNC> = 3 digits
    • <MCC> = 3 digits
      If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the ePDG FQDN.
  • the <TAC>, together with the <MCC> and <MNC> shall identify the 5GS Tracking Area Identity the UE is located in.
    The 5GS TAC is a 24-bit integer. The <TAC-high-byte> is the hexadecimal string of the most significant byte in the TAC and the <TAC-low-byte > is the hexadecimal string of the least significant byte. If there are less than 2 significant digits in <TAC-low-byte>, <TAC-middle-byte> or <TAC-high-byte >, "0" digit(s) shall be inserted at the left side to fill the 2 digits coding;
As examples,
  • the 5GS Tracking Area Identity based ePDG FQDN for the 5GS TAC H'0B1A21, MCC 345 and MNC 12 is coded in the DNS as:
    "tac-lb21.­tac-mb1a.­tac-hb0b.­5gstac.­epdg.­epc.­mnc012.­mcc345.­pub.­3gppnetwork.­org"
Up
19.4.2.9.4  Visited Country FQDN |R13|  p. 85
The Visited Country FQDN, used by a roaming UE to determine whether the visited country mandates the selection of an ePDG in this country, shall be constructed as described below.
The Visited Country FQDN shall contain a MCC that uniquely identifies the country in which the UE is located.
The Visited Country FQDN is composed of seven labels. The last three labels shall be "pub.3gppnetwork.org". The fourth label shall be "visited-country". The third label shall uniquely identify the MCC of the visited country. The first and second labels shall be "epdg.epc". The Visited Country FQDN shall be constructed as follows:
"epdg.epc.mcc<MCC>.visited-country.pub.3gppnetwork.org"
The <MCC> coding used in this FQDN shall be:
  • <MCC> = 3 digits
As an example, the Visited Country FQDN for MCC 345 is coded in the DNS as:
  • "epdg.­epc.­mcc345.­visited-country.­pub.­3gppnetwork.­org".
Up
19.4.2.9.5  Replacement field used in DNS-based Discovery of regulatory requirements |R13|  p. 85
If the visited country mandates the selection of an ePDG in this country (see clause 4.5.4.5 of TS 23.402), the NAPTR record(s) associated to the Visited Country FQDN shall be provisioned with the replacement field containing the identity of the PLMN(s) in the visited country which may be used for ePDG selection.
The replacement field shall take the form of an Operator Identifier based ePDG FQDN as specified in clause 19.4.2.9.2.
For countries with multiple MCC, the NAPTR records returned by the DNS may contain a different MCC than the MCC indicated in the Visited Country FQDN.
As an example, the NAPTR records associated to the Visited Country FQDN for MCC 345, and for MNC 012, 013 and 014, are provisioned in the DNS as:
epdg.epc.mcc345.visited-country.pub.3gppnetwork.org 
; IN NAPTR order
;              pref.
;                  flag
;                     service
;                        regexp
;                          replacement
  IN NAPTR 100 999 "" ""   epdg.epc.mnc012.mcc345.pub.3gppnetwork.org
  IN NAPTR 100 999 "" ""   epdg.epc.mnc013.mcc345.pub.3gppnetwork.org
  IN NAPTR 100 999 "" ""   epdg.epc.mnc014.mcc345.pub.3gppnetwork.org
Up

19.4.2.9A  ePDG FQDN for emergency bearer services |R13|  p. 86

19.4.2.9A.1  General  p. 86
The ePDG FQDN used for the selection of an ePDG supporting emergency bearer services shall be constructed using one of the following formats, as specified in clause 4.5.4a of TS 23.402 and TS 24.302:
  • an Operator Identifier based Emergency ePDG FQDN;
  • a Tracking/Location Area Identity based Emergency ePDG FQDN;
  • an Emergency ePDG FQDN configured in the UE by the HPLMN, which may have a different format than the one specified in the following clause.
The Visited Country Emergency FQDN is used by a roaming UE, in the context of an emergency session, to determine whether the visited country mandates the selection of an ePDG in this country. The Visited Country Emergency FQDN shall be constructed as specified in clause 19.4.2.9A.4. The Replacement field used in DNS-based Discovery of regulatory requirements shall be constructed as specified in clause 19.4.2.9A.5.
The Visited Country Emergency Numbers FQDN is used by a roaming UE to determine the list of emergency numbers and related emergency service types in the the visited country.
Up
19.4.2.9A.2  Operator Identifier based Emergency ePDG FQDN  p. 86
The Operator Identifier based Emergency ePDG FQDN shall be constructed as specified for the Operator Identifier based ePDG FQDN in clause 19.4.2.9.2, with the addition of the label "sos" before the labels "epdg.epc". The Emergency ePDG FQDN shall be constructed as follows:
"sos.epdg.­epc.­mnc<MNC>.­mcc<MCC>.­pub.­3gppnetwork.­org"
As an example, the Operator Identifier based Emergency ePDG FQDN for MCC 345 and MNC 12 is coded in the DNS as:
  • "sos.epdg.­epc.­mnc012.­mcc345.­pub.­3gppnetwork.­org".
Up
19.4.2.9A.3  Tracking/Location Area Identity based Emergency ePDG FQDN |R14|  p. 86
There are two Tracking Area Identity based Emergency ePDG FQDNs defined: one based on a TAI with a 2 octet TAC and a 5GS one based on a 3 octet TAC.
1)
The Tracking Area Identity based Emergency ePDG FQDN using a 2 octet TAC and the Location Area Identity based Emergency ePDG FQDN shall be constructed as specified for the Tracking Area Identity based ePDG FQDN and the Location Area Identity based ePDG FQDN in clause 19.4.2.9.3, with the addition of the label "sos" before the labels "epdg.epc".
The Tracking Area Identity based Emergency ePDG FQDN and the Location Area Identity based Emergency ePDG FQDN shall be constructed as follows:
"tac-lb<TAC-low-byte>.­tac-hb<TAC-high-byte>.­tac.­sos.­epdg.­epc.­mnc<MNC>.­mcc<MCC>.­pub.­3gppnetwork.­org"
and
"lac<LAC>.­sos.­epdg.­epc.­mnc<MNC>.­mcc<MCC>.­pub.­3gppnetwork.­org"
As examples,
  • the Tracking Area Identity based Emergency ePDG FQDN for the TAC H'0B21, MCC 345 and MNC 12 is coded in the DNS as:
    " tac-lb21.­tac-hb0b.­tac.­sos.­epdg.­epc.­mnc012.­mcc345.­pub.­3gppnetwork.­org"
  • the Location Area Identity based Emergency ePDG FQDN for the LAC H'0B21, MCC 345 and MNC 12 is coded in the DNS as:
    " lac0b21.sos.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org"
2)
The 5GS Tracking Area Identity based Emergency ePDG FQDN using a 3 octet TAC shall be constructed as specified for the 5GS Tracking Area Identity based ePDG FQDN in clause 19.4.2.9.3, with the addition of the label "sos" before the labels "epdg.epc".
The 5GS Tracking Area Identity based Emergency ePDG FQDN shall be constructed as follows:
"tac-lb<TAC-low-byte>.­tac-mb<TAC-middle-byte>.­tac-hb<TAC-high-byte>.­5gstac.­sos.­epdg.­epc.­mnc<MNC>.­mcc<MCC>.­pub.­3gppnetwork.org"
As examples,
  • the 5GS Tracking Area Identity based Emergency ePDG FQDN for the 5GS TAC H'0B1A21, MCC 345 and MNC 12 is coded in the DNS as:
    "tac-lb21.tac-mb1a.­tac-hb0b.­5gstac.­sos.­epdg.­epc.­mnc012.­mcc345.­pub.­3gppnetwork.­org"
Up
19.4.2.9A.4  Visited Country Emergency FQDN |R14|  p. 87
The Visited Country Emergency FQDN shall be constructed as specified for the Visited Country FQDN in clause 19.4.2.9.4, with the addition of the label "sos" before the labels "epdg.epc".
The Visited Country Emergency FQDN shall be constructed as follows:
"sos.­epdg.­epc.­mcc<MCC>.­visited-country.­pub.­3gppnetwork.­org"
As an example, the Visited Country Emergency FQDN for MCC 345 is coded in the DNS as:
  • "sos.­epdg.­epc.­mcc345.­visited-country.­pub.­3gppnetwork.­org".
Up
19.4.2.9A.5  Replacement field used in DNS-based Discovery of regulatory requirements for emergency services |R14|  p. 87
The requirements specified in clause 19.4.2.9.5 for the Replacement field used in DNS-based Discovery of regulatory requirements shall apply with the following modification.
The replacement field shall take the form of an Operator Identifier based Emergency ePDG FQDN as specified in clause 19.4.2.9A.2.
As an example, the NAPTR records associated to the Visited Country FQDN for MCC 345, and for MNC 012, 013 and 014, are provisioned in the DNS as:
sos.epdg.epc.mcc345.visited-country.pub.3gppnetwork.org 
; IN NAPTR order
;              pref.
;                  flag
;                     service
;                        regexp
;                          replacement
  IN NAPTR 100 999 "" ""   sos.epdg.epc.mnc012.mcc345.pub.3gppnetwork.org
  IN NAPTR 100 999 "" ""   sos.epdg.epc.mnc013.mcc345.pub.3gppnetwork.org
  IN NAPTR 100 999 "" ""   sos.epdg.epc.mnc014.mcc345.pub.3gppnetwork.org
Up
19.4.2.9A.6  Country based Emergency Numbers FQDN |R14|  p. 87
The Country based Emergency Numbers FQDN shall be constructed as specified for the Visited Country Emergency FQDN in clause 19.4.2.9A.4, but with replacing the label "epdg" by the label "en".
The Country based Emergency Numbers FQDN shall be constructed as follows:
"sos.en.epc.mcc<MCC>.visited-country.pub.3gppnetwork.org"
As an example, the Country based Emergency Numbers FQDN for MCC 345 is coded in the DNS as:
  • "sos.en.epc.­mcc345.­visited-country.­pub.­3gppnetwork.­org".
Up
19.4.2.9A.7  Replacement field used in DNS-based Discovery of Emergency Numbers |R14|  p. 88
The NAPTR record(s) associated to the Country based Emergency Numbers FQDN shall be provisioned with the replacement field containing the emergency numbers and related emergency service types.
The replacement field shall take the following form and include both an emergency number and at least one emergency service type:
<emergency-type>.­<emergency-number>.­sos.­en.­epc.­mcc<MCC>.­visited-country.­pub.­3gppnetwork.­org
The <emergency-number> and <emergency-type> shall follow the syntax defined in Table 19.4.2.9A.7-1. The <emergency-number> shall consist of a single label. The <emergency-type> shall consist of at least one label.
Table 19.4.2.9A.7-1: Syntax of emergency number and emergency type
emergency-number = DIGIT*DIGIT ; at least one DIGIT
emergency-type = "sos" *("." sub-label)
sub-label = let-dig [ *61let-dig-hyp let-dig ]
let-dig-hyp = let-dig / "-"
let-dig = ALPHA / DIGIT
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
As an example, the NAPTR records associated to the Country based Emergency Numbers FQDN for MCC 345 are provisioned in the DNS as:
sos.en.­epc.­mcc345.­visited-country.­pub.­3gppnetwork.­org 
; IN NAPTR order
;              pref.
;                  flag
;                     service
;                        regexp
;                          replacement
  IN NAPTR 100 999 "" ""   sos.ambulance.15.sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org
  IN NAPTR 100 999 "" ""   sos.police.17.sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org
  IN NAPTR 100 999 "" ""   sos.fire.18.sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org
  IN NAPTR 100 999 "" ""   sos.marine.196.sos.en.epc.mcc345.visited-country.pub.3gppnetwork.org
Up

19.4.2.10  Global eNodeB-ID for eNodeB |R10|  p. 88

The Global eNodeB-ID is used to identify eNodeBs globally which is composed of the concatenation of MCC, MNC and the eNodeBID. The MCC and MNC are the same as included in the E-UTRAN Cell Global Identifier (ECGI) (see clause 19.6).
A subdomain name shall be derived from the MNC and MCC by adding the label "enb" to the beginning of the Home Network Realm/Domain (see clause 19.2).
The Global eNodeB-ID FQDN shall be constructed as:
enb<eNodeB-ID>.­enb.­epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
The <eNodeB-ID> shall be coded using a full hexadecimal representation. If there are less than 4 significant digits in < eNodeB-ID>, "0" digit(s) shall be inserted at the left side to fill the 4 digit coding.
Up

19.4.2.11  Local Home Network identifier |R12|  p. 88

The Local Home Network identifier uniquely identifies a local home network. For the definition of a local home network see TS 23.060 and TS 23.401.
A subdomain name shall be derived from the MNC and MCC from the visited network by adding the label "lhn" to the beginning of the Home Network Realm/Domain (see clause 19.2).
The Local Home Network-ID FQDN shall be constructed as:
lhn< LHN name >.­lhn.­epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
The <LHN-name> length and content is an operator choice. The labels shall follow the rules specified in clause 19.4.2.1.
Up

19.4.2.12  UCMF |R16|  p. 89

The UCMF FQDN shall be constructed as:
ucmf.epc.­mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
Where <mcc> and <mnc> are taken from the serving network identity.

19.4.2.13  PGW Set FQDN |R17|  p. 89

A PGW Set Identifier is a globally unique identifier of a set of equivalent and interchangeable PGWs from a given network that provides distribution, redundancy and scalability.
A PGW Set Identifier shall be constructed from the MCC, MNC and a Set ID.
The PGW Set FQDN shall be constructed as follows:
set<Set Id>.­pgwset.­epc.mnc<MNC>.­mcc<MCC>.­3gppnetwork.­org
where
  • <MNC> = 3 digits
  • <MCC> = 3 digits
  • If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding of MNC in the PGW Set FQDN.
  • <Set Id> is the string representing a PGW Set within the PLMN, chosen by the operator, that shall consist of alphabetic characters (A-Z and a-z), digits (0-9) and/or the hyphen (-) and that shall end with either an alphabetic character or a digit, where the case of alphabetic characters is not significant (i.e. two PGW Set IDs with the same characters but using different lower and upper cases identify the same PGW Set).
EXAMPLE:
"set12.­pgwset.­epc.­mnc012.­mcc345.­3gppnetwork.­org" (for the PGW set from MCC 345, MNC 12 and Set ID "12")
Up

19.4.3  Service and Protocol service names for 3GPP  p. 89

A list of standardized "service-parms" names is required to identify a "service" as defined in Section 6.5 of RFC 3958.
The following table defines the names to be used in the procedures specified in TS 29.303:
Description Section 6.5 of RFC 3958 'app-service' name Section 6.5 of RFC 3958 'app-protocol' name
PGW and interface types supported by the PGWx-3gpp-pgwx-s5-gtp, x-s5-pmip, x-s8-gtp , x-s8-pmip, x-s2a-pmip, x-s2a-mipv4, x-s2a-gtp, x-s2b-pmip, x-s2b-gtp, x-s2c-dsmip, x-gn, x-gp
See NOTE.
SGW and interface types supported by the SGWx-3gpp-sgwx-s5-gtp, x-s5-pmip, x-s8-gtp, x-s8-pmip, x-s11, x-s12, x-s4, x-s1-u, x-s2a-pmip, x-s2b-pmip
See NOTE.
GGSNx-3gpp-ggsnx-gn, x-gp
See NOTE.
SGSNx-3gpp-sgsnx-gn, x-gp, x-s4, x-s3, x-s16, x-sv, x-nqprime
See NOTE.
MME and interface types supported by the MMEx-3gpp-mmex-s10, x-s11, x-s3, x-s6a, x-s1-mme, x-gn, x-gp, x-sv, x-nq
See NOTE.
MSC Serverx-3gpp-mscx-sv
UP functionx-3gpp-upfx-sxa, x-sxb, x-sxc, x-n4, x-n4mb
See NOTE.
AMFx-3gpp-amfx-n2 x-n26
See NOTE.
UCMFx-3gpp-ucmfx-urcmp x-n55
NOTE:
When using Dedicated Core Networks, the character string "+ue-<ue usage type>" shall be appended to the 'app-protocol' name, for the interfaces applicable to Dedicated Core Networks, where "<ue usage type>" contains one or more UE usage type values. See TS 29.303, TS 29.272 and TS 29.273.
Example:
x-s5-gtp+ue-<ue usage type>
If multiple UE usage type values are embedded in the "+ue-<ue usage type>", they shall be separated by the symbol ".", e.g. "+ue-1.3.4.20" as specified in RFC 3958.
To select a network node with a particular network capability needed, the character string "+nc-<network capability>" shall be appended to the 'app-protocol' name, where <network capability> contains one or more network capability of the node. See TS 29.303.
Example:
x-s5-gtp+nc-<network capability>
If multiple network capability of the node are embedded in the "+nc-<network capability>", they shall be separated by the symbol ".", e.g. "+nc-nr.smf", as specified in RFC 3958.
To select a network node with a particular network capability needed within a certain Dedicated Core Networks, the character string "+nc-<network capability>" and "+ue-<ue usage type>" shall be appended to the 'app-protocol' name, where <ue usage type> contains one or more UE usage type values and the
Example:
x-s5-gtp+nc-<network capability>+ue-<ue usage type> or x-s5-gtp+ue-<ue usage type>+nc-<network capability>
Up

Up   Top   ToC