DIAMETER based interfaces in EPC, UMTS and IMS

Recently I've seen question regarding on which interface in LTE or UMTS the DIAMETER protocol is used.

Basically DIAMETER is an Authentication, Authorization & Accounting (AAA)  protocol. That is why any of you will see DIAMETER used for these functions.

                    S6a - Authentication, more in TS 29.272
                    Gy - Prepaid charging, more in TS 23.203, TS 32.299;
                    Gz - Postpaid charging;
                    Gx - QoS/Policy, more in TS 29.211, TS 29.212;
                    Rf - Charging, more in TS 32.299;
                    Ro - Charging, more in TS 32.299;
                    Rx - QoS/Policy, more in TS 29.214;
                    S6d - Authentication;
                    S9 - QoS/Policy;
                    Sh - Subscriber Profile;
                    Cx - Subscriber Profile;
                    e2 - Location.
But also few others specific to IMS


                    Dh - used by AS to find the HSS holding the User Profile in multi-HSS environment;
                    Dx - used by I-CSCF or S-CSCF to find a correct HSS in a multi-HSS environment;
                    Gq - to exchange policy decisions-related information between P-CSCF and PDF;

If you are working on the UE side then the DIAMETER is transparent. Although you could see some DIAMETER protocol reference while working with VoLTE over IMS.

Evolved Packet Core（EPC）におけるDNS

ホームネットワークドメイン

ホームネットワークドメインは、 'epc.mnc <mnc-val> .mcc <mcc-val> .3gppnetwork.org'という形式になります。

<mnc-val>と<mcc-val>は3桁です。 PLMのMNCが2桁の場合、最初にゼロを追加しなければならない。
いくつかの例のオペレータのホームネットワークドメインは次のようになります。
epc.mnc456.mcc123.3gppnetworks.org
IMSIのホームネットワークドメイン名は、最初の5桁または6桁（2桁または3桁のmncが使用されているかどうかに応じて）を取得し、ドメイン名を形成するために派生したMNCおよびMNC値を使用し、 ドメイン名の冒頭に。
たとえば、IMSI 1234560123456789には、MSIN 0123456789と、ホームネットワークドメイン名epc.mnc456.mcc123.3gppnetworks.orgがあります。



次の例は、APN-FQDNの構成を示しています。
APN FQDN = internet.apn.epc.mnc015.mcc234.3gppnetwork.org

これは、
APNネットワーク識別子（APN-NI） - 基本的に、それはUEの観点から見たAPN名です。
APN-NI =インターネット
APNオペレータ識別子（APN-OI） - DNS構成の観点から、APNレベルと等しいかそれより低いレベル
APN-FQDNからAPN（-NI）を削除したときに残りの部分だけを残します。
APN-OI = .apc.mnc015.mcc234.3gppnetwork。
APNネットワーク識別子（APN-NI） - 基本的にUEの観点からはAPN名です。
APN-NI =インターネット
DNSを設定するときはいつでも、これがあなたがやっているEPC配備のオペレーターが使用するものであれ、ドットを忘れてはいけません。 彼らは大変怖いです。



コレーションとトーボン/トーキョフ

多くの状況では、配置されていないノードではなく、配置されたノードを選択することが望ましいです。

DNSクライアントがノードのうちの1つがトポロジー的に近い（または同じ「距離」）比較を実行できるようにするこの機能/要件のために、3GPP標準は「標準ノード名」を提案しました。
3GPP標準によれば、ホスト名は、
<'topon' | 'topoff'>。<単一ラベルインタフェース名>。<canonical-node-name>
例
topon.s5.sgw.north.site-xxx - >正規のホスト名= sgw.north.site-xxx
場所：
第1のラベルは、「トポン」または「トップオフ」のいずれかであり、配置されたトポロジー的に近いノード選択が優先されるかどうかを示す。 toponとtopoffの両方は、<single-label-interface-name>を比較でスキップしてcanonical-node-nameを取得することを示します。 tooffとは対照的に、Topoffは、選択がトポロジに基づいている場合、それらのエントリを無視すべきであることを示します。 toponとtopoffの両方をトポロジとコロケーションgw選択モードで使用できます。
<Single-label-interface-name>は、インターフェイスタイプを識別するラベルです（例：s5、s8 ...）。このラベルは考慮されておらず（toponに先行して）、正規のノード名のみが比較されます。
ノードは、厳密に1つの標準ノード名を持つものとする。ホスト名FQDNを比較してノードが実際に同じかどうかを調べる場合、ホスト名FQDNの最初の2つのラベルは無視されます。
最初のラベルとして 'topon'を持つ正規のホスト名を使用する場合、DNSクライアントが適切な決定を下せるように、ノードのこのようなトポロジカルな親密性を反映するために階層構造の正規のノード名を使用することが重要です。
共通接尾辞のラベルの数が多いほど、ノードが近くにあることを示します。言い換えれば、トポロジー的に最も近い2つのノードがそれぞれの正規のノード名で最長一致する接尾辞を持つノードであるように、ノード名構造が選択されていると仮定する。


例
コロケーションおよびトポロジ選択モードを使用するように設定されたネットワークの例：
オペレーターに「北」と「南」と呼ばれる2つのサイトがあることを前提にしましょう。
各サイトには、5つの結合されたS-GW / PDN-GWノードがあります。
「北」サイトは、これらの結合されたS-GWおよびPDN-GWノードをnode01-node05とし、「南」サイトはS-GWおよびPDN-GWノードをnode06-node10と組み合わせている。

接続手順中、MMEは、PGWとSGWの選択で説明したように、PGWとSGWの両方のS-NAPTRルックアップを実行し、ゲートウェイペアのリストをソートします。

全体的および最終的な優先順位は、以下の手順に従って実行されます。

1.共同設置
MMEは、ゲートウェイ名の分析から始まります。同じ標準ノード名を持つゲートウェイは、以下のFQDNのnode01.north.op.comなど、同じ結合SGW / PGWノードに配置されます。
topon.sgw.node01.north.epc.mnc <MNC> .mcc <MCC> .3gppnetwork.org
+
topon.pgw.node01.north.epc.mnc <MNC> .mcc <MCC> .3gppnetwork.org
したがって、これらの配置されたゲートウェイのペアには、最も高い優先順位が与えられます。

注：ローミングシナリオでは、S8インターフェイスが選択されている場合、SGWとPGWは異なるPLMNに配置されているため、コロケーションは不可能です
トポロジカル距離（トポンの場合）
MMEは、ゲートウェイ名がトポロジカルなノード構造を反映しているかどうかを判断し続けます。ラベル「topon」を含むゲートウェイ名は、トポロジカル構造の存在を示します。例えば：
topon.sgw.node01.epc.mnc <MNC> .mcc <MCC> .3gppnetwork.org
+
topon.pgw.node05.epc.mnc <MNC> .mcc <MCC> .3gppnetwork.org
ペアは、正規のノード名で最も長い一致部分でソートされます。

3. DNS優先順位（NAPTRおよびSRVレコード）
ラベルtopoffは、トポロジ構造が存在しないことを意味するため、DNSから受信した優先順位に従います。
リストは、可能なすべてのペアの組み合わせで構成されます。たとえば、10個のSGWと10個のPGWの場合、100個の可能なペアがあります。

EPCで使用されるDNSレコードタイプ

DNS A＆AAAAの記録
レコード（または「アドレスレコード」）はIPv4アドレスを返します。 これは、ホスト名をIPv4アドレスにマップするために最も一般的に使用されます。 あるいは、サブネットマスクのために一部のアプリケーションでも使用されます。
AAAAレコードはIPv6アドレスを返します。 これはホスト名をホストのIPv6アドレスにマップするのに最も一般的に使用されます。

Aレコードの例：
topon.nodes.pgw.be.epc IN A 212.183.156.177
topon.nodes.pgw.ms.epc IN A 212.183.156.179
IN =インターネット、A = Aレコード。

AAAAレコードの例：
topon.nodes.pgw.be.epc IN AAAA 2600：1800：5 :: 10
topon.nodes.pgw.ms.epc IN AAAA 2600：1800：5 :: 20
IN =インターネット、AAAA = AAAAレコード。

DNS SRVの記録
サービスの場所（DNS SRV）を指定するDNSリソースレコード（RR）。クライアントは、特定のドメインの特定のサービス/プロトコルを要求し、利用可能なサーバーの名前を取得することができます。

SRVレコードの例：
; SRVレコード
; _Service._proto.Name TTLクラスSRVプライオリティウェイトポートターゲット
; SGWのSRVレコード
; xBEとxMSに2つのPGWが存在するので、将来のノードを説明するために各サイトに複数のAレコードがあります。
topon.nodes.sgw.be.epc IN SRV 1 100 2123 node1.sgw.be.epc.mnc01.mcc234.3gppnetwork.org。
; topon.nodes.sgw.be.epc IN SRV 1 100 2123 node2.sgw.be.epc.mnc01.mcc234.3gppnetwork.org。
topon.nodes.sgw.ms.epc IN SRV 1 100 2123 node1.sgw.ms.epc.mnc01.mcc234.3gppnetwork.org。
; topon.nodes.sgw.ms.epc IN SRV 1 100 2123 node2.sgw.ms.epc.mnc01.mcc234.3gppnetwork.org。

SRVレコードは、次のフィールドで構成されます。
Priority - （上記の例では1）、クライアントは到達可能な最も低い番号の優先順位でターゲットホストに接続を試みる必要があります。優先順位が同じターゲットホストは、重みフィールドで定義された順序で試行する必要があります。
重み - （上記の例では100）は、同じ優先順位を持つエントリの相対的な重みを指定します。より大きな重みは、選択される確率が比例して高くなければならない。ウェイトが0のターゲットはバックアップに対応します。
Port - （上の例では2123 [GTP]）は、レコードで指定されたシンボリックサービスに割り当てられたポート番号です。
システムは、同じ優先順位を持つRRのすべての重みの合計を計算する必要があります。次に、0と計算された合計の間の乱数を選択します。このランダム値に関連付けられたターゲットを選択します。

DNS NAPTRの記録
ネーム・オーソリティ・ポインタ（NAPTR）リソース・レコードは、多種多様なリソース名に対するルックアップ・サービスを指定します。既存の文字列に適用すると、NAPTRは新しいドメインラベルまたはURIを生成します。
EPCでは正規表現が空のS-NAPTRというバリエーションを使用します。直接的なNAPTR（S-NAPTR）は、特定のサービスをDNSエントリに追加するために使用されます。この結果、DNSサーバーはサービスプロトコル固有のエントリでクエリに返信することができます。 S-NAPTRレコードは、特にPOP3プロトコルおよびIMAP4プロトコル用に別個のS-NAPTRレコードを持つことができるメール読取りアプリケーションでは一般的です。
S-NAPTRを使用する場合、DNSクエリは必要な 'service：protocol'を示していません。 DNSサーバは要求されたすべてのS-NAPTRを提供し、DNSクライアントは所望の「サービス：プロトコル」にしか合致しないものを考慮する。

NAPTRレコードの例
wap.operator.com.apn.epc.mnc01.mcc234.3gppnetwork.org。 IN NAPTR 1 5 "a" "x-3gpp-pgw：x-gn" "" topon.nodes.pgw.be.epc.mnc01.mcc234.3gppnetwork.org。

NAPTRレコードは、次のフィールドで構成されます。
Order - （上記の例では1）クライアントは、到達可能な最も低い番号の順序でターゲットホストに接続を試みる必要があります。同じ順序のターゲットホストは、プリファレンスフィールドで定義された順序で試行する必要があります。 DNSクライアントは、オーダーの値が高いNAPTRは考慮しないでください。
Preference - （上記の例では5）は、等しいオーダーのNAPTRの処理方法を指定します。低い数値は高い数値の前に処理されています。クライアントは、好ましいプロトコルまたはサービスを理解していないなどの理由がある場合、より高い優先度値で記録を見ることができる。
OrderとPreferenceの重要な違いは、一度一致が見つかると、クライアントは異なる順序のレコードを考慮してはならないが、同じOrderで異なるプリファレンスを処理する可能性があるということです。
言い換えれば、優先度は、権限の観点からは同じだが単純なロードバランシングの観点からは考慮されないルールに重みを付けるために使用されます。
Flags - （上記の例ではa）は、レコードの書き換えと解釈の側面を制御します。他のフラグはNAPTRで許可されていますが、S-NAPTRでは "S"、 "A"または ""のみが許可されています。
「S」フラグは、次のルックアップがSRVレコードのためのものでなければならないことを意味する。
"A"フラグは、次のルックアップがA、AAAAレコードのいずれかでなければならないことを意味する。
 空のフラグ ""は、より多くのNAPTR RRルックアップが実行されることを意味する。