インタフェースとそのプロトコルスタック
主要なネットワーク要素に精通した後、これら要素間のインタフェースをよりよく知る時期が来ています。
インタフェースは、MME、SGWおよびPGWが他のネットワーク要素(例えば、HSSまたはPCRF)と協働することを可能にする。
それらのそれぞれは、3GPP.orgによって記述された標準化された方法で構築されています。 ここに記述されている各インタフェースは、23.401 3GPP.orgのドキュメントから取られています。
ドキュメンテーションは(時には)必要以上に大きくなることを覚えておいてください。インタフェースのすべての側面についてはここでは説明しません。
ユーザーがローミングしていない状況を大きく把握できます。
上記の図は4Gインタフェースのみを示しており、2Gおよび3Gの追加インタフェースはTS 23.060に記載されています。
私が以前に書いたように、サービングゲートウェイ(SGW)とPDNゲートウェイ(PGW)を1つのシャーシに入れることができます。
ローミングを伴うシナリオでは、アーキテクチャの標準がそれを扱う2つの方法を記述しています。
2つのローミングシナリオ:
S8インターフェイスによってトラフィックがホームネットワークからUEにルーティングされる場合、
ホームオペレーターのアプリケーション機能のみでローカルブレークアウトがあり、ビジターのオペレーターのアプリケーション機能とは別の場所にあります。
そのことを念頭に置いて、今度は、関数とプロトコルスタックをインターフェイスすることで、まっすぐに進むことができます。
情報フローは、2つのグループに分けられます.1つはコントロールプレーンで、もう1つはユーザープレーンです。
制御プレーンは、ユーザプレーン機能の制御とサポートのためのプロトコルで構成されています。
E-UTRANへの接続およびE-UTRANへの接続など、E-UTRAネットワークアクセス接続を制御する。
確立されたネットワークアクセス接続の属性(例えば、IPアドレスの起動)を制御するステップと、
ユーザの移動性をサポートするために、確立されたネットワーク接続のルーティング経路を制御するステップと、 そして
変化するユーザの要求を満たすためにネットワーク資源の割り当てを制御する。
Control Plane interfaces:
コントロールプレーンインターフェイス:
eNodeBとMMEとの間のS1-MMEインタフェース。
E-UTRANとMMEとの間の制御プレーンプロトコルの基準点。
場所:
S1-AP(S1アプリケーションプロトコル):eNodeBとMMEとの間のアプリケーション層プロトコル。
SCTP(ストリーム制御伝送プロトコル):このプロトコルは、MMEとeNodeBとの間のシグナリングメッセージの配信を保証する(S1)。 SCTPはRFC 4960で定義されています
SGSNとMMEとの間のS3インタフェース。
それは、アイドル状態および/またはアクティブ状態における、インター3GPPアクセスネットワークモビリティのためのユーザおよびベアラ情報交換を可能にする。
場所:
GTP-C(制御プレーンのGPRSトンネリングプロトコル):このプロトコルは、SGSNとMMEとの間のシグナリングメッセージをトンネリングする
UDP(ユーザデータグラムプロトコル):このプロトコルシグナリングメッセージ。 UDPはRFC 768で定義されています。
SGSNとSGWとの間のS4インタフェース。
これは、GPRSコアとサービングGWの3GPPアンカー機能との間の関連する制御およびモビリティサポートを提供する。 さらに、Direct Tunnelが確立されていない場合は、ユーザプレーンのトンネリングが提供されます。
場所:
GTP-C(上記):このプロトコルは、SGSNとSGWとの間のシグナリングメッセージをトンネリングする。
UDP:このプロトコルはシグナリングメッセージを転送します。 UDPはRFC 768で定義されています。
SGWとPGWとの間のS5またはS8インタフェース。
S5:サービングGWとPDN GWとの間のユーザプレーントンネリングおよびトンネル管理を提供する。 これは、UEの移動性に起因するサービングGW再配置、およびサービングGWが、必要なPDN接続のために配置されていないPDN GWに接続する必要がある場合に使用される。
S8:VPLMN(在圏PLMN)内のサービングGWとHPLMN(ホームPLMN)内のPDN GWとの間にユーザおよび制御プレーンを提供するPLMN間基準点。 S8は、S5のインターPLMN変形である。
これらの2つのインタフェースの違いは、S5が1つのネットワークエンティティ(ローミングシナリオなし)で使用され、S8が、ユーザがホームPLMNにいるVisiting PLMNを接続するために使用されていることです。
場所:
GTP-C:このプロトコルは、SGWとPGWとの間のシグナリングメッセージをトンネリングする。
UDP:このプロトコルは、SGWとPGWとの間のシグナリングメッセージを転送する。 UDPはRFC 768で定義されています。
S10インタフェースをMMEと他のMMEとの間に含む。
MME再配置(例えば、ハンドオーバー)およびMMEからMMEへの情報転送のためのMME間の参照点。
場所:
GTP-C:このプロトコルは、MME間のシグナリングメッセージをトンネリングする。
UDP:このプロトコルは、MME間でシグナリングメッセージを転送する。 UDPはRFC 768で定義されています。
S11インタフェースをMMEとSGWとの間に設ける。
MMEとサービングGWとの間の参照点。
場所:
GTP-C:このプロトコルは、MMEとSGWとの間のシグナリングメッセージをトンネリングする。
UDP:このプロトコルは、MMEとSGWとの間でシグナリングメッセージを転送する。 UDPはRFC 768で定義されています。
S6aはMMEとHSSとの間のインタフェースである。
MMEとHSSとの間の進化したシステム(AAAインタフェース)へのユーザアクセスを認証/許可するための加入および認証データの転送を可能にする。
場所:
直径:このプロトコルは、MMEとHSSとの間の進化したシステムへのユーザアクセスを認証/認可するための加入および認証データの転送をサポートする(S6a)。 直径はRFC 3588で定義されています。
SCTP:このプロトコルはシグナリングメッセージを転送します。 SCTPはRFC 4960で定義されています。
MMEとEIRとの間のS13インターフェース。
それはUEEIRを可能にする。
場所:
直径:このプロトコルは、MMEとEIRとの間のUE識別検査手順をサポートする(S13)。 直径はRFC 3588で定義されています。
SCTP:このプロトコルはシグナリングメッセージを転送します。 SCTPはRFC 4960で定義されています。
CBCとeNodeBの間のSBcインタフェース。
警告メッセージ配信および制御機能のためのCBCとMME間の参照ポイント。
セルブロードキャストセンター(CBC)は、日本向けに作成された地震津波警報システム(ETWS)の特別要求事項の解決策であった。 これは、制御プレーン内のUEとMMEとの間の既存のインタフェースを利用する。 さらに、MMEはSBcインターフェイスを介してCBCに接続されます。 LTE / 4Gでは、SBCインターフェイスは完全に標準化されており、SCTPに基づいています。
場所:
SBc-AP(SBcアプリケーションプロトコル):CBCとMMEとの間のアプリケーション層プロトコル。 このプロトコルは、警告メッセージの転送をサポートしています。
S1-AP(S1アプリケーションプロトコル):eNodeBとMMEとの間のアプリケーション層プロトコル。
SCTP:このプロトコルは、MMEとeNodeB(S1)との間のシグナリングメッセージの配信を保証する。 SCTPはRFC 4960で定義されています。
ユーザプレーンインタフェース:
eNodeBとSGWとの間のS1-Uインタフェース。
ハンドオーバ中のベアラユーザプレーントンネリング及びeNodeB間パス切り替え毎のE-UTRANとサービングGWとの間の参照点。
場所:
GTP-U(ユーザプレーン用のGPRSトンネリングプロトコル):このプロトコルは、eNodeBとSGWとの間のユーザデータをトンネリングする。
UDP:このプロトコルはユーザーデータを転送します。 UDPはRFC 768で定義されています。
S4インターフェイスは、2GアクセスのUEとPGWの間にあります。
S4インターフェイスは、UEと3GアクセスおよびPGWを接続するためにも使用されています。
これは、GPRSコアとサービングGWの3GPPアンカー機能との間の関連する制御およびモビリティサポートを提供する。 さらに、Direct Tunnelが確立されていない場合は、ユーザプレーンのトンネリングが提供されます。
場所:
GTP U:このプロトコルは、SGSNとS GW間、およびバックボーンネットワーク内のS GWとP GWとの間のユーザデータをトンネリングする。 GTPはすべてのエンドユーザのIPパケットをカプセル化しなければならない。
UDP / IP:ユーザデータと制御シグナリングのルーティングに使用されるバックボーンネットワークプロトコルです。
UmおよびGbインタフェースに関するプロトコルは、TS 23.060に記述されています。
3GネットワークとPGWとの間のUE-S12インタフェース。
直接トンネルが確立されたときのユーザプレーントンネリングのためのUTRANとサービングGWとの間の参照ポイント。 これは、SGSNとUTRANとの間、またはSGSNとGGSNとの間で定義されたGTP-Uプロトコルを使用するIu-u / Gn-u基準点に基づく。 S12の使用法はオペレータ構成オプションです。
場所:
GTP U:このプロトコルは、UTRANとS GWとの間、およびバックボーンネットワーク内のS GWとP GWとの間のユーザデータをトンネリングする。 GTPはすべてのエンドユーザIPパケットをカプセル化しなければならない
UDP / IP:ユーザデータと制御シグナリングのルーティングに使用されるバックボーンネットワークプロトコルです。
Uuインタフェースのプロトコルについては、TS 23.060を参照してください。
SGSNは、図18に示すように、ユーザプレーントンネル確立を制御し、UTRANとS GWとの間に直接トンネルを確立する。
JAPAN CODE TIP
We share the knowledge about code C/C++/Assembly/Java and Telecom,Network Security
Saturday, October 20, 2018
Periodic Tracking Area Update (TAU) - T3412 timer
Periodic TAU
周期的トラッキングエリア更新は、UEのネットワークへの利用可能性を定期的に通知するために使用される。 この手順は、定期的なトラッキングエリア更新タイマ(タイマT3412)によってUEにおいて制御される。 タイマT3412の値は、ATTACH ACCEPTメッセージでネットワークによってUEに送信され、TRACKING AREA UPDATE ACCEPTメッセージで送信することができる。 UEは、新しい値が受信されるまで、UEに割り当てられたトラッキングエリアのリストのすべてのトラッキングエリアにこの値を適用しなければならない。
No Periodic TAU case
ATTACH ACCEPTまたはTRACKING AREA UPDATE ACCEPTでUEによって受信されたタイマT3412が、タイマが非アクティブである、またはタイマ値がゼロであるという指示を含む場合、タイマT3412は非アクティブ化され、UEは周期的なトラッキングエリア更新手順を実行してはならない。
この部分は、Rel 8と比較してSpecの小さな変更です。これはMachine to Machine(M2M)通信が全体的により多くの部分を占めるからです。 他に何が(定期的な)TAUを辞める理由になるのでしょうか?
Timer's behavior
タイマーT3412は、UEがEMM-CONNECTEDモードからEMM-IDLEモードに移行するときにリセットされ、その初期値で開始される。 タイマーT3412は、UEがEMM-CONNECTEDモードまたはEMM-DEREGISTERED状態に入ると停止する。
Emergency bearers
UEが緊急ベアラサービスのために接続され、タイマーT3412が満了する場合、UEは周期的なトラッキングエリア更新手順を開始してはならず、ネットワークからローカルに切り離すものとする。
UEが緊急ベアラーサービスのために接続されておらず、タイマーT3412が満了すると、周期的トラッキングエリア更新手順が開始され、タイマーは次の開始のための初期値に設定される。
UEが緊急ベアラサービスのために接続されておらず、タイマが満了したときにEMM-REGISTERED.NORMAL-SERVICE以外の状態にある場合、定期的なトラッキングエリア更新手順は、UEがEMM-REGISTERED.NORMAL-SERVICEに戻るまで延期される。
Attached to EPS and non-EPS
UEがEPSおよび非EPSサービスの両方に接続されていて、UEがEMM-REGISTERED.NO-CELL-AVAILABLE状態にあるときにタイマT3412が満了するかタイマT3423が満了する場合、UEは統合トラッキングエリア更新手順を開始する UEがEMM-REGISTERED.NORMAL-SERVICE状態に復帰したときに、「結合されたTA / LA更新とIMSIアタッチ」を示す。
仮に..?
UEが緊急ベアラサービスのために接続されていない場合、移動可能タイマーはT3412より長くなければならない。この場合、デフォルトでは、移動可能タイマーはT3412よりも4分長い。 ISRがアクティブ化されていない場合、モバイル到達可能タイマーの満了時のネットワーク動作はネットワークに依存するが、通常、ネットワークは第1の満了時にUEへのページングメッセージの送信を停止し、他の適切なアクションをとることができる。
UEが緊急ベアラサービスのために接続されている場合、MMEは、T3412に等しい値を有するモバイル到達可能タイマを設定しなければならない。移動可能なタイマーが満了すると、MMEはUEを局所的に切り離す。
MMEがUEのためのNASシグナリング接続を解放するとき、モバイル到達可能タイマはリセットされ、その初期値で開始されなければならない。モバイル到達可能タイマーは、NASシグナリング接続がUEに対して確立されたときに停止されなければならない。
モバイル到達可能タイマーが終了すると、ネットワークは暗黙のデタッチタイマーを開始する。暗黙のデタッチタイマの値はネットワークに依存します。 ISRがアクティブになっている場合、暗黙のデタッチタイマーのデフォルト値はT3423より4分長くなります。 UEがネットワークに接続する前に暗黙のデタッチタイマーが終了すると、ネットワークは暗黙的にUEを切り離す。
暗黙のデタッチタイマは、NASシグナリング接続がUEに対して確立されたときに停止されなければならない。
周期的トラッキングエリア更新は、UEのネットワークへの利用可能性を定期的に通知するために使用される。 この手順は、定期的なトラッキングエリア更新タイマ(タイマT3412)によってUEにおいて制御される。 タイマT3412の値は、ATTACH ACCEPTメッセージでネットワークによってUEに送信され、TRACKING AREA UPDATE ACCEPTメッセージで送信することができる。 UEは、新しい値が受信されるまで、UEに割り当てられたトラッキングエリアのリストのすべてのトラッキングエリアにこの値を適用しなければならない。
No Periodic TAU case
ATTACH ACCEPTまたはTRACKING AREA UPDATE ACCEPTでUEによって受信されたタイマT3412が、タイマが非アクティブである、またはタイマ値がゼロであるという指示を含む場合、タイマT3412は非アクティブ化され、UEは周期的なトラッキングエリア更新手順を実行してはならない。
この部分は、Rel 8と比較してSpecの小さな変更です。これはMachine to Machine(M2M)通信が全体的により多くの部分を占めるからです。 他に何が(定期的な)TAUを辞める理由になるのでしょうか?
Timer's behavior
タイマーT3412は、UEがEMM-CONNECTEDモードからEMM-IDLEモードに移行するときにリセットされ、その初期値で開始される。 タイマーT3412は、UEがEMM-CONNECTEDモードまたはEMM-DEREGISTERED状態に入ると停止する。
Emergency bearers
UEが緊急ベアラサービスのために接続され、タイマーT3412が満了する場合、UEは周期的なトラッキングエリア更新手順を開始してはならず、ネットワークからローカルに切り離すものとする。
UEが緊急ベアラーサービスのために接続されておらず、タイマーT3412が満了すると、周期的トラッキングエリア更新手順が開始され、タイマーは次の開始のための初期値に設定される。
UEが緊急ベアラサービスのために接続されておらず、タイマが満了したときにEMM-REGISTERED.NORMAL-SERVICE以外の状態にある場合、定期的なトラッキングエリア更新手順は、UEがEMM-REGISTERED.NORMAL-SERVICEに戻るまで延期される。
Attached to EPS and non-EPS
UEがEPSおよび非EPSサービスの両方に接続されていて、UEがEMM-REGISTERED.NO-CELL-AVAILABLE状態にあるときにタイマT3412が満了するかタイマT3423が満了する場合、UEは統合トラッキングエリア更新手順を開始する UEがEMM-REGISTERED.NORMAL-SERVICE状態に復帰したときに、「結合されたTA / LA更新とIMSIアタッチ」を示す。
仮に..?
UEが緊急ベアラサービスのために接続されていない場合、移動可能タイマーはT3412より長くなければならない。この場合、デフォルトでは、移動可能タイマーはT3412よりも4分長い。 ISRがアクティブ化されていない場合、モバイル到達可能タイマーの満了時のネットワーク動作はネットワークに依存するが、通常、ネットワークは第1の満了時にUEへのページングメッセージの送信を停止し、他の適切なアクションをとることができる。
UEが緊急ベアラサービスのために接続されている場合、MMEは、T3412に等しい値を有するモバイル到達可能タイマを設定しなければならない。移動可能なタイマーが満了すると、MMEはUEを局所的に切り離す。
MMEがUEのためのNASシグナリング接続を解放するとき、モバイル到達可能タイマはリセットされ、その初期値で開始されなければならない。モバイル到達可能タイマーは、NASシグナリング接続がUEに対して確立されたときに停止されなければならない。
モバイル到達可能タイマーが終了すると、ネットワークは暗黙のデタッチタイマーを開始する。暗黙のデタッチタイマの値はネットワークに依存します。 ISRがアクティブになっている場合、暗黙のデタッチタイマーのデフォルト値はT3423より4分長くなります。 UEがネットワークに接続する前に暗黙のデタッチタイマーが終了すると、ネットワークは暗黙的にUEを切り離す。
暗黙のデタッチタイマは、NASシグナリング接続がUEに対して確立されたときに停止されなければならない。
無料 のPUBLIC DNSサーバー
ルータまたはコンピュータがDHCP経由でインターネットに接続している場合、ISPは自動的にDNSサーバを割り当てますが、それらを使用する必要はありません。
以下は、割り当てられたDNSサーバの代わりに使用できる無料のDNSサーバです.GoogleとOpenDNSのような、最も信頼性の高いものがあります。
ヒント:プライマリDNSサーバーは優先DNSサーバーと呼ばれることもあり、セカンダリDNSサーバーは代替DNSサーバーと呼ばれることもあります。 プライマリDNSサーバーとセカンダリDNSサーバーは、混在して別のレイヤーの冗長性を提供することができます。
一般に、DNSサーバは、DNSサーバアドレス、インターネットDNSサーバ、インターネットサーバ、DNS IPアドレスなど、あらゆる種類の名前と呼ばれます。
異なるDNSサーバーを使用する理由
あなたのISPによって割り当てられたDNSサーバを変更したいかもしれない理由の1つは、現在使用しているDNSサーバに問題があると思われる場合です。 DNSサーバーの問題をテストする簡単な方法は、WebサイトのIPアドレスをブラウザに入力することです。名前ではなくIPアドレスでWebサイトにアクセスできる場合は、DNSサーバーに問題がある可能性があります。
DNSサーバーを変更するもう1つの理由は、より優れたサービスを探している場合です。多くの人々は、ISPによって管理されているDNSサーバが低速であり、全体的なブラウジングの経験が遅くなることに腹を立てています。
さらに、サードパーティのDNSサーバを使用する理由として、Webアクティビティのロギングを防ぎ、特定のWebサイトのブロックを回避することが一般的になります。
ただし、すべてのDNSサーバーがトラフィックログを回避するわけではありません。それがあなたの後ろのものなら、あなたが使いたいものかどうかを知るためにサーバーに関するすべての詳細を必ず読んでください。
各サービスの詳細については、上の表のリンクに従ってください。
最後に、混乱があった場合、無料のDNSサーバは無料のインターネットアクセスを提供しません!アクセスのためにISPに接続する必要があります。覚えにくいIPアドレスではなく人が判読できる名前でWebサイトにアクセスできるように、DNSサーバーはIPアドレスとドメイン名を変換するだけです。
以下は、割り当てられたDNSサーバの代わりに使用できる無料のDNSサーバです.GoogleとOpenDNSのような、最も信頼性の高いものがあります。
Free & Public DNS Servers (Valid October 2018)
Provider | Primary DNS Server | Secondary DNS Server |
---|---|---|
Level31 | 209.244.0.3 | 209.244.0.4 |
Verisign2 | 64.6.64.6 | 64.6.65.6 |
Google3 | 8.8.8.8 | 8.8.4.4 |
Quad94 | 9.9.9.9 | 149.112.112.112 |
DNS.WATCH5 | 84.200.69.80 | 84.200.70.40 |
Comodo Secure DNS | 8.26.56.26 | 8.20.247.20 |
OpenDNS Home6 | 208.67.222.222 | 208.67.220.220 |
Norton ConnectSafe7 | 199.85.126.10 | 199.85.127.10 |
GreenTeamDNS8 | 81.218.119.11 | 209.88.198.133 |
SafeDNS9 | 195.46.39.39 | 195.46.39.40 |
OpenNIC10 | 69.195.152.204 | 23.94.60.240 |
SmartViper | 208.76.50.50 | 208.76.51.51 |
Dyn | 216.146.35.35 | 216.146.36.36 |
FreeDNS11 | 37.235.1.174 | 37.235.1.177 |
Alternate DNS12 | 198.101.242.72 | 23.253.163.53 |
Yandex.DNS13 | 77.88.8.8 | 77.88.8.1 |
UncensoredDNS14 | 91.239.100.100 | 89.233.43.71 |
Hurricane Electric15 | 74.82.42.42 | |
puntCAT16 | 109.69.8.51 | |
Neustar17 | 156.154.70.1 | 156.154.71.1 |
Cloudflare18 | 1.1.1.1 | 1.0.0.1 |
Fourth Estate19 | 45.77.165.194 | |
CleanBrowsing20 | 185.228.168.9 | 185.228.169.9 |
ヒント:プライマリDNSサーバーは優先DNSサーバーと呼ばれることもあり、セカンダリDNSサーバーは代替DNSサーバーと呼ばれることもあります。 プライマリDNSサーバーとセカンダリDNSサーバーは、混在して別のレイヤーの冗長性を提供することができます。
一般に、DNSサーバは、DNSサーバアドレス、インターネットDNSサーバ、インターネットサーバ、DNS IPアドレスなど、あらゆる種類の名前と呼ばれます。
異なるDNSサーバーを使用する理由
あなたのISPによって割り当てられたDNSサーバを変更したいかもしれない理由の1つは、現在使用しているDNSサーバに問題があると思われる場合です。 DNSサーバーの問題をテストする簡単な方法は、WebサイトのIPアドレスをブラウザに入力することです。名前ではなくIPアドレスでWebサイトにアクセスできる場合は、DNSサーバーに問題がある可能性があります。
DNSサーバーを変更するもう1つの理由は、より優れたサービスを探している場合です。多くの人々は、ISPによって管理されているDNSサーバが低速であり、全体的なブラウジングの経験が遅くなることに腹を立てています。
さらに、サードパーティのDNSサーバを使用する理由として、Webアクティビティのロギングを防ぎ、特定のWebサイトのブロックを回避することが一般的になります。
ただし、すべてのDNSサーバーがトラフィックログを回避するわけではありません。それがあなたの後ろのものなら、あなたが使いたいものかどうかを知るためにサーバーに関するすべての詳細を必ず読んでください。
各サービスの詳細については、上の表のリンクに従ってください。
最後に、混乱があった場合、無料のDNSサーバは無料のインターネットアクセスを提供しません!アクセスのためにISPに接続する必要があります。覚えにくいIPアドレスではなく人が判読できる名前でWebサイトにアクセスできるように、DNSサーバーはIPアドレスとドメイン名を変換するだけです。
MME の選択方法 - MME 選択手順
前回からはしばらく時間がかかりましたが、ここに行きます。 MME / SGW / PGWノードを選択する方法、またはLTEがMME / SGW / PGWノードを選択する方法については、何度もこのサイトにアクセスしている人がいました。 以下が明確になることを願っています。
各LTEネットワークでは、ネットワーク内のPDN-GW、SGW、MME、SGSN、およびHSSの動的ピア選択を処理するために、インターネットドメインネームシステム(DNS)が広く使用されています。 我々は統計的なassingsを使用することができますが、ちょっと、ちょっと! 私を信じて、DNSが適切に処理されるとはるかに簡単です。
数日後、私は、以下に述べるポイントについてDNS設定の詳細をカバーしようとします。
EPSノードは、次のユースケースのEPSノードの選択のためにDNSクエリメッセージを内部DNS(iDNS)に送信します。
各LTEネットワークでは、ネットワーク内のPDN-GW、SGW、MME、SGSN、およびHSSの動的ピア選択を処理するために、インターネットドメインネームシステム(DNS)が広く使用されています。 我々は統計的なassingsを使用することができますが、ちょっと、ちょっと! 私を信じて、DNSが適切に処理されるとはるかに簡単です。
数日後、私は、以下に述べるポイントについてDNS設定の詳細をカバーしようとします。
EPSノードは、次のユースケースのEPSノードの選択のためにDNSクエリメッセージを内部DNS(iDNS)に送信します。
- UE Attachの一部として、eNBは、そのUEに提供すべきMMEのアドレスについて、TAIを使用してiDNSサーバに問い合わせる。
- UEがアタッチしている間、MMEはiDNSサーバに問い合わせて、要求された(加入した)PDN接続(APN)が位置するPDN-GW(パケットデータネットワークゲートウェイ、PGW)を選択する。選択は、UEがネットワークに接続するとき、MMEに提供される情報に基づくことができる。
- PGW選択に続いて、MMEは、TACを使用してUEにサービスするために利用可能なSGWを選択するようにDNSサーバに問い合わせるが、これは、ほとんどの場合、ネットワークトポロジおよびネットワーク内のUEの位置に基づいており、 。
- SGSNは、LTEと3G / 2Gハンドオーバ中にLAC、およびRAC(UEから受信した旧GUTIから取得)を使用して旧MMEを解決するためにDNSサーバに照会します。
- MMEは、3G / 2GからLTEへのハンドオーバ中にNRI、LAC、およびRAC(UEから受信したP-TMSIから取得)を使用して旧SGSNを解決するようDNSサーバに問い合わせます。
- 接続中、MMEは、Diameterプロキシ/エッジエージェントに対してHSSピアサービスおよびインターフェイスアソシエーションをサポートするように設定されています。これらは、Diameterプロキシに向かうMME内の静的構成であり、Diameterプロキシを選択するためにMMEによってDNSクエリが開始されません。
今日では、MME Selectionを参照しているのは約2人であり、SGW、PGW、SGSN、HSSの選択をカバーすると、上記のリストは数倍多くコピーされます。
DNSインターフェイス
DNSインターフェイスは3GPP標準化されたインターフェイス経由ではなく、eNB、MME、SGSN、およびDiameter ProxyはEPSのDNSサーバに接続されています(IP接続)。通常、EPCネットワーク内でEPSノードは、GnインタフェースまたはO&Mインタフェースを介してDNSサーバにアクセスします。
MMEの選択
Ref。ポイント1に、LTEネットワークへのアタッチ中のMME選択:
eNodeBは、ネットワークトポロジおよびネットワーク内のUEの位置に基づいて、UEにサービスするために利用可能なMMEを選択し、最良のMMEが選択されるようにする。 MMEが変更される確率を低減する。
UE Attachの一部として、eNBはMMEのアドレスのTAIを使用してDNSサーバに照会します。通常、DNSはクエリに応答して選択するMMEのプールを持ちます。
TAI FQDNの形式は次のように構成されています。
tac-lb <TAC-low-byte> .tac-hb <TAC-highバイト> .tac.epc.mnc <MNC> .mcc <MCC> .3gppnetwork.org
DNSは、eNBがMMEを選択できる複数のMMEアドレス(候補セット)を提供することができる。
Ref。ポイント4まで、SGSN選択LTE-> 2 / 3Gハンドオーバ:
SGSNは、LTEから3G / 2Gへのハンドオーバ中に古いMMEを識別するためにDNSサーバに照会します。 UEから受信した古いGUTIを使用します。
旧MMEとGn / GpのみをサポートするRelease-8 SGSNとの連絡が必要な手順があります。主なユースケースは、ハンドオーバ中のコンテキスト転送です。 eutRANからプレリリース-8 UTRAN / GERANにUEが移動すると、UEはGUTIに基づいて導出されたP-TMSIを提供する。その結果、ソースMMEは、Release-8より前のSGSNノードのPre-Release-8 SGSNのように見えます。
古いGUTIに基づいてMMEのすべてのGnおよびGpインターフェイスを見つけるためのRelease 8 Gn / Gp-SGSNについては、「x-3gpp-mme:x-gn」の「Service Parameter」を使用し、「x-3gpp -mme:x-gp "と入力します。
リリース前の互換性オペレータは、ソースSGSNがRelease-8より前であるかどうかにかかわらず、対応するGn / GpインターフェイスのA / AAAAレコードを引き続きプロビジョニングします。 Gn / Gpインターフェイスは、 ".gprs"と ".3gppnetwork.org"トップレベルドメインの両方に重複してプロビジョニングされます。
メインLTEパケットコア要素の機能 - MME、SGW、PGW
私が書くことを始めなければならないとき、私は私の最初のLTEのような問題が何であるかを理解するために、私の頭蓋骨の背中を深く見ています。そしてあなたは何を知っていますか?私は覚えていない。
だから、何かを始める最良の方法は、最初から始めることです(書く)。
LTEネットワークの3つの主要なパケットコア要素を詳しく見てみましょう。
MME - モビリティ管理エンティティ
MMEは、LTEアクセスネットワークの主要な制御ノードです。それは、再送信を含むトラッキングおよびページング手順、およびユーザ装置(UE)のアイドルモードについても責任がある。 MMEは、ベアラの起動にも関与し、その非アクティブ化手順は、そのタスクへの初期アタッチ中のUEのためのSGWの選択およびコアネットワーク(CN)ノードの再配置を含むイントラハンドオーバの発生時にも属する。
MMEは、HSSに向かってユーザを認証する役割を担い、ユーザがローミング中であれば、MMEはユーザのホームHSSへのS6aインタフェースを終了する。すべてのNon Access Stratum(NAS)シグナリングはMMEポイントで終了し、MMEポイントは一時UE ID(GUTI)の生成と割り当ても担当します。その役割の中には、公衆陸上移動ネットワーク(PLMN)への認可UEであり、存在する場合にはUEローミング制限を実施することもある。 MMEは、NASシグナリングの暗号化と完全性保護の終了ポイントでもあります。シグナリングの合法的傍受(LI)は、MMEエンティティによってもサポートされる可能性があります。また、S3インタフェース(SGSNからMMEへ)によるLTEと2G / 3Gネットワーク間のモビリティのための制御プレーン機能を提供します。
23.401 3GPPの文書によると、上記の機能はリストとして記載されている。
MME機能は次のとおりです。
だから、何かを始める最良の方法は、最初から始めることです(書く)。
LTEネットワークの3つの主要なパケットコア要素を詳しく見てみましょう。
MME - モビリティ管理エンティティ
MMEは、LTEアクセスネットワークの主要な制御ノードです。それは、再送信を含むトラッキングおよびページング手順、およびユーザ装置(UE)のアイドルモードについても責任がある。 MMEは、ベアラの起動にも関与し、その非アクティブ化手順は、そのタスクへの初期アタッチ中のUEのためのSGWの選択およびコアネットワーク(CN)ノードの再配置を含むイントラハンドオーバの発生時にも属する。
MMEは、HSSに向かってユーザを認証する役割を担い、ユーザがローミング中であれば、MMEはユーザのホームHSSへのS6aインタフェースを終了する。すべてのNon Access Stratum(NAS)シグナリングはMMEポイントで終了し、MMEポイントは一時UE ID(GUTI)の生成と割り当ても担当します。その役割の中には、公衆陸上移動ネットワーク(PLMN)への認可UEであり、存在する場合にはUEローミング制限を実施することもある。 MMEは、NASシグナリングの暗号化と完全性保護の終了ポイントでもあります。シグナリングの合法的傍受(LI)は、MMEエンティティによってもサポートされる可能性があります。また、S3インタフェース(SGSNからMMEへ)によるLTEと2G / 3Gネットワーク間のモビリティのための制御プレーン機能を提供します。
23.401 3GPPの文書によると、上記の機能はリストとして記載されている。
MME機能は次のとおりです。
- NASシグナリング
- NASシグナリングセキュリティ。
- 3GPPアクセスネットワーク間の移動性のためのインターCNノードシグナリング(S3終了)。
- ECM-IDLE状態におけるUE到達能力(ページング再送信の制御および実行を含む)。
- 追跡エリアリスト管理;
- UE位置(例えば、TAI)から時間帯へのマッピングと、移動性に関連するUE時間帯変化のシグナリングと、
- PDN GWおよびサービングGW選択;
- MME変更を伴うハンドオーバのためのMME選択;
- 2Gまたは3G 3GPPアクセスネットワークへのハンドオーバのためのSGSN選択;
- ローミング(ホームHSSに向かってS6a)。
- 認証;
- 認可;
- 専用ベアラ確立を含むベアラ管理機能;
- シグナリングトラフィックの合法的傍受。
- 警告メッセージ転送機能(適切なeNodeBの選択を含む)。
- UE Reach能力手続き。
MMEは、モビリティの場合のみ、UEトリガサービスリクエスト、PDN切断、およびUEデタッチの場合にのみ、UEタイムゾーンの変更を通知するものとする。 UE時間帯が変更されたかどうかをMMEが判断できない場合(例えば、UE時間帯がMME再配置中に古いMMEによって送信されない)、MMEはUE時間帯の変更を通知してはならない。 規制された義務化された時間変更(例えば、夏時間や夏時間の変更)によって引き起こされるUEタイムゾーンの変更は、MMEが実際の変更のためにシグナリング手順を開始するように誘発してはならない。 代わりに、MMEはtheUEの次のモビリティイベントまたはサービスリクエスト手順を待ってから、これらの手順を使用してPDN GWのUEタイムゾーン情報を更新しなければならない。
SGW - サービングゲートウェイ
サービングGWは、E-UTARNへのインタフェースを終端するゲートウェイです。 EPSに関連付けられた各UEについて、所与の時点において、単一のサービングGWが存在する。
SGWは、隣接するeNodeBとのハンドオーバを担当し、ユーザプレーンにわたるすべてのパケットに関するデータ転送も担当する。 その職務には、2G / 3Gなどの他のネットワークへのモビリティインターフェイスに注意を払っています。 SGWは、アイドル状態の間にUEに関連するコンテキスト情報を監視し維持しており、UEのデータをダウンリンク方向に到着したときにページング要求を生成する。 (たとえば、誰かの呼び出し)。 SGWはまた、LIの場合にユーザトラフィックの複製を担当する。
23.401 3GPPの文書によると、SGWはリストとして機能する。
SGWの機能は次のとおりです。
- eNodeB間ハンドオーバのためのローカルモビリティアンカーポイント;
- 特に、eNodeBにおける並べ替え機能を補助するために、eNodeB間およびRAT間ハンドオーバ中に経路を切り替えた直後に、ソースeNodeB、ソースSGSNまたはソースRNCに1つまたは複数の「エンドマーカー」を送信すること。
- 3GPP間モビリティのためのモビリティアンカーリング(S4の終了と2G / 3GシステムとPDN GW間のトラフィックの中継)。
- ECM-IDLEモードのダウンリンクパケットバッファリングおよびネットワークトリガサービス要求手順の開始。
- 合法的傍受;
- パケットのルーティングと転送;
- 上りリンクおよび下りリンクにおけるトランスポートレベルのパケットマーキング。 関連するEPSベアラのQCIに基づいて、DiffServコードポイントを設定するステップと、
- オペレーター間課金の会計処理。 GTPベースのS5 / S8の場合、Serving GWは、UEとベアラごとにアカウンティングデータを生成します。
- 課金原則およびTS 32.240に規定されている基準点に基づいてOFCSを接続する
PDN GW - パケットデータネットワークゲートウェイ
PGWは、SGiインタフェースをPDNに終端するゲートウェイです。 UEが複数のPDNにアクセスしている場合、そのUEには複数のPGWが存在する可能性がありますが、同時にS5 / S8接続とGn / Gp接続の混在はサポートされません。
PGWは、3GPP技術と非3GPP技術との間のモビリティの「アンカー」としての役割を果たす。 PGWは、UEに対するトラフィックの入口または出口点であることによって、UEから外部PDNへの接続性を提供する。 PGWは、ポリシー施行、ユーザのパケットフィルタリング、課金サポート、およびLIを管理します。
WiMAX、CDMA 1X、EvDOなど、非3GPP技術を使用することが可能です。
PGWは、23.401の3GPP文書に従ってリストとして機能する。
PGW関数には次のものがあります。
- ユーザごとのパケットフィルタリング(例えば、ディープパケット検査)。
- 合法的傍受;
- UEのIPアドレス割り当て。
- 上りリンクおよび下りリンクにおけるトランスポートレベルのパケットマーキング。関連するEPSベアラのQCIに基づいて、DiffServコードポイントを設定するステップと、
- オペレータ間課金の会計処理。
- TS 23.203に定義されたULおよびDLサービスレベル課金(例えば、PCRFによって定義されたSDFに基づいて、またはローカルポリシーによって定義されたディープパケットインスペクションに基づいて)。
- 課金原則およびTS 32.240 [51]に規定されている基準点を通じたOFCSのインターフェース。
- TS 23.203 [6]に定義されているULおよびDLサービスレベルゲート制御。
- TS 23.203 [6]で定義されている(例えば、SDFごとのレートポリシング/シェーピングによる)ULおよびDLサービスレベルレート実施。
- APN-AMBRに基づくULおよびDLレート実施(例えば、非GBR QCIに関連付けられた同じAPNのすべてのSDFのトラフィック集約に対するレートポリシング/シェーピングによる)。
- 同じGBR QCI(例えば、レートポリシング/シェーピングによる)を有するSDFの集合体の蓄積されたMBRに基づくDLレート施行;
- DHCPv4(サーバーとクライアント)とDHCPv6(クライアントとサーバー)の機能。
- このバージョンの仕様では、ネットワークはPPPベアラタイプをサポートしていません。 GGSNのプレリリース8のPPP機能は、PDN GWに実装することができます。
- パケットスクリーニング。
- さらに、PDN GWには、GTPベースのS5 / S8の次の機能が含まれています。
- TS 23.203 [6]に定義されるULおよびDLベアラバインディング。
- TS 23.203 [6]に定義されたULベアラバインディング検証。
- RFC4861 [32]で定義されているような機能。
- UEおよびベアラごとの課金。
PGWは、E-UTRAN、GERANまたはUTRANのいずれかを使用して、GERAN / UTRANのみのUEおよびE-UTRAN可能なUEの両方にPDN接続を提供する。 PGWは、S5 / S8インタフェース上でのみE-UTRANを使用するE-UTRAN対応UEにPDN接続を提供する。
あなたがそれを好きだと思います。 躊躇しないでください、コメントしてください。
あなたは文法の間違い、間違った単語の綴りを見つけました。あるいは内容が間違っているかもしれません、私に教えてください。
Location:
Japan
Gx interface - between PCRF and PCEF
Gx参照ポイントは、ポリシー制御と課金ルール機能(PCRF-Policy Control and Charging Rules Function)とポリシーと課金実施機能(PCEF-Charging Enforcement Function)の間にあります。 Gx基準点は、PCRFからPCEFへのポリシーおよび課金制御(PCC)規則のプロビジョニングおよび除去、およびPCEFからPCRFへのトラフィック面イベントの送信に使用されます。 Gx基準点は、アプリケーションに関連するAVPを適用することによって、充電制御、ポリシー制御、またはその両方に使用することができる。
あなたが知っているように、大きな絵から始めるのは常に良いことです。 さあ。
PCC(ポリシーと課金管理)
ああ、IP CANベアラでは、定義された容量、遅延、ビット誤り率などのIP伝送経路を意味することに注意してください。詳細は、3GPP TS 21.905を参照してください。
IP-CANセッションには、1つまたは複数のIP-CANベアラが組み込まれています。 IP-CANセッションごとに複数のIP-CANベアラをサポートするのは、IP-CAN専用です。関連するUE IPv4アドレスおよび/またはIPv6プレフィックスが割り当てられ、IPネットワークにアナウンスされる限り、IP-CANセッションが存在する。
以下に示すテキストが必要になります。
ポリシーと課金制御ルールの定義
PCCルールの目的は以下のとおりです。
サービスデータフローに属するパケットを検出する
PCCルール内のサービスデータフローフィルタは、ダウンリンクIP CANベアラの選択に使用されます
PCCルール内のサービスデータフローフィルタは、アップリンクIPフローが正しいIP CANベアラで転送されることを強制するために使用されます
サービスデータフローが原因であることを特定する
サービスデータフローに適用可能な課金パラメータを提供する
サービスデータフローのポリシー制御を提供する
PCEF規則の優先順位の順にPCC規則のサービスデータフローフィルタに対して受信パケットを評価することによって、PCEF(ポリシーおよび課金実施機能)は受信パケットごとにPCC規則を選択する。パケットがサービスデータフローフィルタと一致すると、そのパケットのパケットマッチングプロセスが完了し、そのフィルタのPCCルールが適用されます。
PCC(Policy and Charging Control)には2種類の種類があります。
動的PCCルール。 Gxインターフェイスを介してPCRFによってPCEFに動的にプロビジョニングされます。これらのPCCルールは、事前定義されるか、またはPCRF内で動的に生成される。動的なPCCルールはいつでもインストール、変更、削除できます。
定義済みのPCCルール。 PCEFであらかじめ設定されています。定義済みのPCCルールは、いつでもPCRFによってアクティブ化または非アクティブ化できます。 PCEF内の予め定義されたPCC規則は、PCRFがGxインタフェースを介して動的にPCC規則のセットを起動できるようにグループ化することができる。
PCCルールは以下のもので構成されます。
ルール名 - PCEFとPCRFとの間の通信におけるPCCルールを参照するために使用される
サービス識別子 - サービスデータフローが関係するサービスまたはサービスコンポーネントを識別するために使用される
サービスデータフローフィルタは、ルールが適用されるトラフィックを選択するために使用されます。動的かつ事前定義されたPCC規則のために、ワイルドカードによるサービスデータフローフィルタを定義することが可能でなければならない
優先順位
ゲート状態 - サービスデータフローフィルタによって検出されたサービスデータフローが、アップリンクおよび/またはダウンリンク方向で通過(状態オープン)または廃棄(状態クローズ)されるかどうかを示す
QoSパラメータ - サービスデータフローのための許可されたQoSクラスを意味するQoSクラス識別子(QCI)、アップリンクおよびダウンリンクのための割り当ておよび保持優先度(ARP)および許可ビットレート
課金キー(rating group) - オンライン課金とオフライン課金のインタフェースを使用するかどうか、オフラインで何を計量するか、PCEFはどのレベルでルールに関連する使用を報告するかなどを定義する。
他の充電パラメータ
監視キー - 事前定義されたPCCルールまたは動的PCCルールによって制御されるサービスデータフローの使用監視制御に使用される監視制御インスタンスを識別する
私が以前に密かに言及したように、私たちは
ポリシーおよび課金管理(PCC)ルールの操作
動的PCCルールの場合:
インストール:まだプロビジョニングされていないPCCルールをプロビジョニングする
変更:既にインストールされているPCCルールを変更する
削除:既にインストールされているPCCルールを削除する
定義済みのPCCの場合:
アクティベーション:PCCルールをアクティブにする
非アクティブ化:PCCルールを禁止する
機能要素
PCRF
PCRF-Policy Control and Charging Rules Function(ポリシー制御および課金規則機能)は、ポリシー制御決定およびフローに基づく課金制御機能を包含する機能要素である。 PCRFは、サービスデータフロー検出、ゲーティング、QoS、およびフローベースの課金(与信管理を除く)をPCEFに対してネットワーク制御します。 PCRFは、アプリケーション機能(AF)からのセッションおよび媒体関連情報を明らかにし、交通面イベントのAF-Application Function に通知する。
PCRFはGxインタフェースを介してPCEFにPCC規則を提供する。
PCRF PCCルール決定は、以下の1つまたは複数に基づいてもよい。
Rxインターフェースを介してアプリケーション機能(AF)から得られる情報、例えば、セッション、メディアおよび加入者関連情報
Gxインターフェースを介してPCEFから取得された情報。 IP CANベアラ属性、要求タイプおよび加入者関連情報
SPインターフェースを介してSPRから得られる情報、例えば、加入者およびサービス関連のデータ
Gxxインタフェース経由でBBERFから取得した情報
独自のPCRF事前設定済みの情報
PCEF(ポリシーおよび課金実施機能)からの情報が、PCRFに知られているサービスデータフローフィルタと一致しないトラフィックマッピング情報を含む場合、PCRFはUEにPCRFに知られていない拡張QoS foサービスを要求することを可能にする。 PCRFは、このトラフィックマッピング情報を、サービスデータフローフィルタとして、対応する許可されたPCCルールに追加しなければならない。 PCRFは、欠落したフィルタパラメータをワイルドカードすることができる。
PCRFはRxインタフェースを介してAFにイベントを報告しなければならない。
PCRFは、PCRFの方針の決定に従って、PCC管理下にある各サービスデータフローの処理に関するPCC規則の使用を通してPCEFに通知しなければならない。 PCRFは、IP CANセッションに適用されるベアラ制御モードを選択し、それをGxインタフェースを介してPCEFに提供しなければならない。
AFF(Application Function)シグナリングベアラ通知の失効に加入すると、PCRFは、AFシグナリングIPフローに対応するPCC規則に関連するリソースの損失をPCRFに通知するようにPCEFに要求しなければならない。これは、これが依頼されていない以前は
PCEF
PCEF(Policy and Charging Enforcement Function)は、ポリシー施行とフォローベース課金機能を含む機能要素です。この機能エンティティはゲートウェイ(PGW)にあります。ゲートウェイおよびそのQoSでのユーザプレーントラフィック処理を制御し、サービスデータの検出およびカウントだけでなく、オンラインおよびオフラインの課金処理を提供します。
ポリシー制御下にあるサービスデータフローの場合、対応するゲートが開いている場合に限り、PCEFはサービスデータフローがゲートウェイを通過できるようにする。
課金制御中のサービスデータフローの場合、PCEFは、対応するアクティブなPCCルールが存在する場合にのみ、サービスデータフローがゲートウェイを通過することを許可し、オンライン課金の場合、OCSは、課金キー(ルールベース)。 PCEFは、信用再認可手順の過程で、サービスデータフローがゲートウェイを通過するようにすることができる。
PCRFによって要求された場合、PCEFは関連するサービスデータフローの状態が変化したときにPCRFに報告しなければならない。この手順は、AFシグナリングトラフィック専用のIP CANベアラを監視するために使用できます。
Gxインターフェイス経由のプロシージャ
PCCルールの要求とプロビジョニング
設定されているフィールドの詳細については、TS 29.212パラグラフ4.5.1を参照してください。
PCRFは、Gxインタフェースを介してPCEFに適用されるPCC規則を指示しなければならない。 これは次のいずれかの手順を使用している可能性があります。
PULL手続き(PCEFが要請するプロビジョニング):PCEFによってPCC規則が要求されたことに応じて、PCRFはPCC規則をCCA(Credit Control Answer)に規定し、
1.事象トリガ事象が発生すると、PCEFは事象トリガパラメータをPCRFに運び、PCC規則を送達することを要求するクレジット制御要求(この例ではCCR-I、「Initial_Request」なので)メッセージを送る
2. PCRFは、イベントトリガに応じてPCCルール(旧PCCルール)を更新するかどうかを判断し、CCFにクレジットコントロール応答(CCA-I)メッセージを返す。 PCC規則が更新を必要とする場合、更新されたCCA-U(CCR-UおよびCCA-Uはクレジット制御要求/応答Update_Requestを保持する)メッセージは更新されたPCC規則(すなわち、新しいPCC規則)を運び、PCRFは古いPCCルールと新しいPCCのルール。
CCAメッセージを受信した後、PCEFはPCC規則を実行する。返されたCCAメッセージが新しいPCCルールを運ぶ場合、PCEFは新しいPCCルールを実行する。返されたCCAメッセージに新しいPCCルールがない場合、PCEFは古いPCCルールを実行します。 PCEFがPCC規則をうまく実行しないと、PCEFは新しいCCRメッセージを送信する。
PUSH手順(非請求プロビジョニング):PCRFは、PCEFからの要求を得ずにPCC規則をプロビジョニングすることを決定することができる。 Rxインタフェースを介してPCRFに提供される情報に応じて、またはPCRF内の内部トリガに応答して、 PCFからの要求なしにPCC規則をプロビジョニングするために、PCRFは、これらのPCC規則をRAR(再認証要求)メッセージに含めるものとする。このRA要求によってCCR / CCA(信用管理要求/与信管理応答)メッセージはトリガされません。
1.イベントトリガイベントが発生すると、PCRFはPCC規則を更新し、再認証要求(RAR)メッセージをPCEFに送信する。 RARメッセージは新しいPCCルールを持ち、PCRFは古いPCCルールを保存しません。
2. PCEFは、RARメッセージを通じて配信された新しいPCC規則を実行します。実行の完了後、PCEFはPCRFに再認証回答(RAA)メッセージを送信する。
PCEFからの要請または要請がない場合、PCRFは、0個以上のPCC規則を規定しなければならない。 PCRFは、以下の手段の1つによって、単一のPCC規則に対する操作を実行することができる。
PCEFで事前に定義されているPCCルールを有効または無効にするには、PCRFはこのPCCルールへの参照をCharging-Rule-Name AVPにプロビジョニングし、Charging-Rule-Install AVPまたはCharging -Rule- AVPを削除します。
PCRF提供のPCCルールをインストールまたは変更するために、PCRFは、対応する課金ルール定義AVPを課金ルールインストールAVP内にプロビジョニングしなければならない。
PCRFによって以前にプロビジョニングされたPCCルールを削除するには、PCRFは、このPCCルールの名前を、チャージングルール削除AVP内のチャージングルール名AVPの値としてプロビジョニングするものとする。
特定のアクセスに対して、PCRFがベアラバインディングを実行する場合、PCRFは、以前にインストールまたは起動されたPCCルールを1つのIP CANベアラから別のIP CANベアラに移動することができる。詳細は、TS 29.212の附属書Aを参照のこと。
あなたが知っているように、大きな絵から始めるのは常に良いことです。 さあ。
PCC(ポリシーと課金管理)
ああ、IP CANベアラでは、定義された容量、遅延、ビット誤り率などのIP伝送経路を意味することに注意してください。詳細は、3GPP TS 21.905を参照してください。
IP-CANセッションには、1つまたは複数のIP-CANベアラが組み込まれています。 IP-CANセッションごとに複数のIP-CANベアラをサポートするのは、IP-CAN専用です。関連するUE IPv4アドレスおよび/またはIPv6プレフィックスが割り当てられ、IPネットワークにアナウンスされる限り、IP-CANセッションが存在する。
以下に示すテキストが必要になります。
ポリシーと課金制御ルールの定義
PCCルールの目的は以下のとおりです。
サービスデータフローに属するパケットを検出する
PCCルール内のサービスデータフローフィルタは、ダウンリンクIP CANベアラの選択に使用されます
PCCルール内のサービスデータフローフィルタは、アップリンクIPフローが正しいIP CANベアラで転送されることを強制するために使用されます
サービスデータフローが原因であることを特定する
サービスデータフローに適用可能な課金パラメータを提供する
サービスデータフローのポリシー制御を提供する
PCEF規則の優先順位の順にPCC規則のサービスデータフローフィルタに対して受信パケットを評価することによって、PCEF(ポリシーおよび課金実施機能)は受信パケットごとにPCC規則を選択する。パケットがサービスデータフローフィルタと一致すると、そのパケットのパケットマッチングプロセスが完了し、そのフィルタのPCCルールが適用されます。
PCC(Policy and Charging Control)には2種類の種類があります。
動的PCCルール。 Gxインターフェイスを介してPCRFによってPCEFに動的にプロビジョニングされます。これらのPCCルールは、事前定義されるか、またはPCRF内で動的に生成される。動的なPCCルールはいつでもインストール、変更、削除できます。
定義済みのPCCルール。 PCEFであらかじめ設定されています。定義済みのPCCルールは、いつでもPCRFによってアクティブ化または非アクティブ化できます。 PCEF内の予め定義されたPCC規則は、PCRFがGxインタフェースを介して動的にPCC規則のセットを起動できるようにグループ化することができる。
PCCルールは以下のもので構成されます。
ルール名 - PCEFとPCRFとの間の通信におけるPCCルールを参照するために使用される
サービス識別子 - サービスデータフローが関係するサービスまたはサービスコンポーネントを識別するために使用される
サービスデータフローフィルタは、ルールが適用されるトラフィックを選択するために使用されます。動的かつ事前定義されたPCC規則のために、ワイルドカードによるサービスデータフローフィルタを定義することが可能でなければならない
優先順位
ゲート状態 - サービスデータフローフィルタによって検出されたサービスデータフローが、アップリンクおよび/またはダウンリンク方向で通過(状態オープン)または廃棄(状態クローズ)されるかどうかを示す
QoSパラメータ - サービスデータフローのための許可されたQoSクラスを意味するQoSクラス識別子(QCI)、アップリンクおよびダウンリンクのための割り当ておよび保持優先度(ARP)および許可ビットレート
課金キー(rating group) - オンライン課金とオフライン課金のインタフェースを使用するかどうか、オフラインで何を計量するか、PCEFはどのレベルでルールに関連する使用を報告するかなどを定義する。
他の充電パラメータ
監視キー - 事前定義されたPCCルールまたは動的PCCルールによって制御されるサービスデータフローの使用監視制御に使用される監視制御インスタンスを識別する
私が以前に密かに言及したように、私たちは
ポリシーおよび課金管理(PCC)ルールの操作
動的PCCルールの場合:
インストール:まだプロビジョニングされていないPCCルールをプロビジョニングする
変更:既にインストールされているPCCルールを変更する
削除:既にインストールされているPCCルールを削除する
定義済みのPCCの場合:
アクティベーション:PCCルールをアクティブにする
非アクティブ化:PCCルールを禁止する
機能要素
PCRF
PCRF-Policy Control and Charging Rules Function(ポリシー制御および課金規則機能)は、ポリシー制御決定およびフローに基づく課金制御機能を包含する機能要素である。 PCRFは、サービスデータフロー検出、ゲーティング、QoS、およびフローベースの課金(与信管理を除く)をPCEFに対してネットワーク制御します。 PCRFは、アプリケーション機能(AF)からのセッションおよび媒体関連情報を明らかにし、交通面イベントのAF-Application Function に通知する。
PCRFはGxインタフェースを介してPCEFにPCC規則を提供する。
PCRF PCCルール決定は、以下の1つまたは複数に基づいてもよい。
Rxインターフェースを介してアプリケーション機能(AF)から得られる情報、例えば、セッション、メディアおよび加入者関連情報
Gxインターフェースを介してPCEFから取得された情報。 IP CANベアラ属性、要求タイプおよび加入者関連情報
SPインターフェースを介してSPRから得られる情報、例えば、加入者およびサービス関連のデータ
Gxxインタフェース経由でBBERFから取得した情報
独自のPCRF事前設定済みの情報
PCEF(ポリシーおよび課金実施機能)からの情報が、PCRFに知られているサービスデータフローフィルタと一致しないトラフィックマッピング情報を含む場合、PCRFはUEにPCRFに知られていない拡張QoS foサービスを要求することを可能にする。 PCRFは、このトラフィックマッピング情報を、サービスデータフローフィルタとして、対応する許可されたPCCルールに追加しなければならない。 PCRFは、欠落したフィルタパラメータをワイルドカードすることができる。
PCRFはRxインタフェースを介してAFにイベントを報告しなければならない。
PCRFは、PCRFの方針の決定に従って、PCC管理下にある各サービスデータフローの処理に関するPCC規則の使用を通してPCEFに通知しなければならない。 PCRFは、IP CANセッションに適用されるベアラ制御モードを選択し、それをGxインタフェースを介してPCEFに提供しなければならない。
AFF(Application Function)シグナリングベアラ通知の失効に加入すると、PCRFは、AFシグナリングIPフローに対応するPCC規則に関連するリソースの損失をPCRFに通知するようにPCEFに要求しなければならない。これは、これが依頼されていない以前は
PCEF
PCEF(Policy and Charging Enforcement Function)は、ポリシー施行とフォローベース課金機能を含む機能要素です。この機能エンティティはゲートウェイ(PGW)にあります。ゲートウェイおよびそのQoSでのユーザプレーントラフィック処理を制御し、サービスデータの検出およびカウントだけでなく、オンラインおよびオフラインの課金処理を提供します。
ポリシー制御下にあるサービスデータフローの場合、対応するゲートが開いている場合に限り、PCEFはサービスデータフローがゲートウェイを通過できるようにする。
課金制御中のサービスデータフローの場合、PCEFは、対応するアクティブなPCCルールが存在する場合にのみ、サービスデータフローがゲートウェイを通過することを許可し、オンライン課金の場合、OCSは、課金キー(ルールベース)。 PCEFは、信用再認可手順の過程で、サービスデータフローがゲートウェイを通過するようにすることができる。
PCRFによって要求された場合、PCEFは関連するサービスデータフローの状態が変化したときにPCRFに報告しなければならない。この手順は、AFシグナリングトラフィック専用のIP CANベアラを監視するために使用できます。
Gxインターフェイス経由のプロシージャ
PCCルールの要求とプロビジョニング
設定されているフィールドの詳細については、TS 29.212パラグラフ4.5.1を参照してください。
PCRFは、Gxインタフェースを介してPCEFに適用されるPCC規則を指示しなければならない。 これは次のいずれかの手順を使用している可能性があります。
PULL手続き(PCEFが要請するプロビジョニング):PCEFによってPCC規則が要求されたことに応じて、PCRFはPCC規則をCCA(Credit Control Answer)に規定し、
1.事象トリガ事象が発生すると、PCEFは事象トリガパラメータをPCRFに運び、PCC規則を送達することを要求するクレジット制御要求(この例ではCCR-I、「Initial_Request」なので)メッセージを送る
2. PCRFは、イベントトリガに応じてPCCルール(旧PCCルール)を更新するかどうかを判断し、CCFにクレジットコントロール応答(CCA-I)メッセージを返す。 PCC規則が更新を必要とする場合、更新されたCCA-U(CCR-UおよびCCA-Uはクレジット制御要求/応答Update_Requestを保持する)メッセージは更新されたPCC規則(すなわち、新しいPCC規則)を運び、PCRFは古いPCCルールと新しいPCCのルール。
CCAメッセージを受信した後、PCEFはPCC規則を実行する。返されたCCAメッセージが新しいPCCルールを運ぶ場合、PCEFは新しいPCCルールを実行する。返されたCCAメッセージに新しいPCCルールがない場合、PCEFは古いPCCルールを実行します。 PCEFがPCC規則をうまく実行しないと、PCEFは新しいCCRメッセージを送信する。
PUSH手順(非請求プロビジョニング):PCRFは、PCEFからの要求を得ずにPCC規則をプロビジョニングすることを決定することができる。 Rxインタフェースを介してPCRFに提供される情報に応じて、またはPCRF内の内部トリガに応答して、 PCFからの要求なしにPCC規則をプロビジョニングするために、PCRFは、これらのPCC規則をRAR(再認証要求)メッセージに含めるものとする。このRA要求によってCCR / CCA(信用管理要求/与信管理応答)メッセージはトリガされません。
1.イベントトリガイベントが発生すると、PCRFはPCC規則を更新し、再認証要求(RAR)メッセージをPCEFに送信する。 RARメッセージは新しいPCCルールを持ち、PCRFは古いPCCルールを保存しません。
2. PCEFは、RARメッセージを通じて配信された新しいPCC規則を実行します。実行の完了後、PCEFはPCRFに再認証回答(RAA)メッセージを送信する。
PCEFからの要請または要請がない場合、PCRFは、0個以上のPCC規則を規定しなければならない。 PCRFは、以下の手段の1つによって、単一のPCC規則に対する操作を実行することができる。
PCEFで事前に定義されているPCCルールを有効または無効にするには、PCRFはこのPCCルールへの参照をCharging-Rule-Name AVPにプロビジョニングし、Charging-Rule-Install AVPまたはCharging -Rule- AVPを削除します。
PCRF提供のPCCルールをインストールまたは変更するために、PCRFは、対応する課金ルール定義AVPを課金ルールインストールAVP内にプロビジョニングしなければならない。
PCRFによって以前にプロビジョニングされたPCCルールを削除するには、PCRFは、このPCCルールの名前を、チャージングルール削除AVP内のチャージングルール名AVPの値としてプロビジョニングするものとする。
特定のアクセスに対して、PCRFがベアラバインディングを実行する場合、PCRFは、以前にインストールまたは起動されたPCCルールを1つのIP CANベアラから別のIP CANベアラに移動することができる。詳細は、TS 29.212の附属書Aを参照のこと。
Location:
Japan
Gy interface - between OCS and PCEF
前回はDiameterベースのPCCルールフロー、PCEFとPCRF関数の簡単な説明、Policy Charging and Control(PCC)そのものなど、Gxインターフェーストピックをカバーしようとしました。 私が先ほど触れたすべてのことをここで見つけることができます。 ほとんどの記事は前述の情報に基づいています。 私は必要に応じてすべてのセクションへのリンクを張ります。
Gyはオンラインチャージシステム(OCS)とPCEFの間にあります。 ほとんどの場合、PCEFはPDN GW(Packed Data Network Gateway)または短いPGWに基づいています。
Gyインターフェースは、サービスデータフローに基づく課金のためのオンライン与信管理を可能にする。
いつものように、今日はかなり高いレベルの抽象的な人物で始めるのも良い方法です。 だから..お楽しみください。
基本的な構造は、オンラインクライアント(CTFによって表されるOCS)がリソース割り当てを要求し、与信管理情報をオンライン課金システム(OCS)に報告するメカニズムに従います。 前述のように、異なる課金シナリオに基づいて課金することができます。
Diameter OCSの基本原則
オンライン与信管理アプリケーション要件
オンライン課金の場合、IETF Diameter Credit Controlアプリケーションで定義された基本機能が使用されます。 基本的な構造は、オンラインクライアント(CTF)がリソースの割り当てを要求し、与信管理情報をOCS(オンライン課金システム)に報告するメカニズムに従います。
オンラインクライアントは、RFC 4006で記述されている「クライアント、イベントベース」および/または「クライアント、セッションベース」のステートマシンを実装します。
私。 クライアントが即時イベント課金(IEC)を申請すると、クライアント、イベントベースのステートマシンが使用され、クライアントが3GPPで定義されているユニット予約(ECUR)でイベントチャージを適用すると、 最初と最後の質問に対する "CLIENT、SESSION BASED"状態機械。
Validity-Time AVPとTime "Tcc"の使用と値は、与信管理サーバー(OCS)の単独の制御下にあり、OCSのオペレータ構成によって決定されます。
Gyインタフェースによる処理
オンライン課金(OCS)の場合、追加のAVPはDiameterプロトコルで定義されました。
オンライン課金のためのユーザークレジットの制御に関する3つのケースが区別されます。
Immediate Event Charging (IEC)
Event Charging with Unit Reservation (ECUR)
Session Charging with Unit Reservation (SCUR)
Immediate Event Charging(IEC)の場合、イベントの与信管理プロセスは、特定の与信管理イベントに対して与信管理要求(CCR)とともに送信される対応するCC要求タイプEVENT_REQUESTによって制御されます。
ユニット予約(ECUR)によるイベント課金の場合、所与の与信管理イベントに対する課金のためにCCリクエストタイプのINITIAL / TERMINATION_REQUESTが使用されるが、サービスデリバリの前に予約が行われ、成功 配達。
ユニット予約(ECUR)を伴うセッション課金は、CC要求タイプの初期/更新および終了要求を要求する。
ネットワーク要素は、CCRイベントメッセージが生成されるIEC、またはCCRの初期値および終了を使用するECURを適用することができる。 IECまたはECURを適用するかどうかの決定は、サービスおよび/またはオペレータの方針に基づいています。
Immediate Event Charging (IEC)
図2は、イベントベースの直接振り込み処理を実行するためにGyインタフェース上で必要とされるトランザクションを示す。 代わりに、サービス/コンテンツ配信の前にダイレクト退会操作を実行してもよい。 ネットワーク要素は、このシナリオが使用されたときに、要求されたサービスの実行が成功していることを保証する必要があります。
図2 IEC直接借り換えオペレーション
ネットワーク要素は、サービス要求を受信する。
ステップ2.ネットワーク要素は、サービス実行の前に直接引き落としを実行する。ネットワーク要素(DCCAクライアントとして機能する)は、CC-Request-Type AVPをEVENT_REQUESTに設定したクレジット制御要求(CCR)を送信して、サービス固有の情報をOCS(DCCAサーバとして機能する)に通知します。要求アクションAVP(RA)はDIRECT_DEBITINGに設定されます。既知の場合、ネットワーク要素は、要求メッセージ内に要求サービス単位AVP(RSU)(通貨単位または非通貨単位)を含むことができる。
ステップ3.クレジット制御要求メッセージを送信すると、ネットワーク要素は、通信監督タイマ「Tx」を開始する。クレジット・コントロール・アンサー(CCA)メッセージを受信すると、ネットワーク要素はタイマーTxを停止する。
ステップ4. OCSは、関連するサービス課金パラメータを決定する。
ステップ5:OCSは、CC-Request-Type AVPをEVENT_REQUESTに設定したCredit-Control-Answerメッセージをネットワーク要素に返して、サービスの実行を許可する
(サービスのコストを示す認可サービスユニットAVP(GSU)および場合によってはコスト情報AVP(CI)は、クレジット制御応答メッセージに含まれる)。
クレジット・コントロール・アンサー・メッセージは、それに応じてネットワーク要素によってチェックされなければならず、要求されたサービスはサービス提供と同時に制御される。払い戻し情報AVPは、REFUND-ACCOUNTメカニズム中に送信されるために、Credit-Control-Answerメッセージに含めることができます。下記のシナリオを参照してください。
ステップ6.サービスが提供されています。
注:上記のメカニズムを使用してCHECK_BALANCEとPRICE_ENQUIRYも実行することができます。
払い戻しの目的で取引を見てみましょう。
直接引き落とし操作が実行されます。
ステップ1直接借り方操作によって前に課金されたサービスは、最終的に不成功に終わったことが証明されます。
ステップ2.結果として、ネットワーク要素は、関連する払い戻しを実行するために、直接振替操作を実行する。ネットワーク要素(DCCAクライアントとして機能する)は、CC-Request-Type AVPをEVENT_REQUESTに設定したクレジット制御要求(CCR)を送信して、サービス固有の情報をOCS(DCCAサーバとして機能する)に通知します。要求アクションAVP(RA)は払い戻しアカウントに設定されています。以前のIEC CCAで受信された場合、ネットワーク要素にはRefund-Information AVPが含まれます。
ステップ3.クレジット制御要求メッセージを送信すると、ネットワーク要素は、通信監督タイマ「Tx」を開始する(RFC4006 [402])。クレジット・コントロール・アンサー(CCA)メッセージを受信すると、ネットワーク要素はタイマーTxを停止する。
ステップ4. OCSは、CCRに含まれるAVPを読み取り、それに応じて払い戻しを実行する。
ステップ5. OCSは、CC-Request-Type AVPをEVENT_REQUESTに設定したCredit-Control-Answerメッセージと関連する結果コードを返す。
私はフローシーケンスの図を描く方法を変えましたが、UEはそれほど重要ではないので、私はそれを行いました。だから次の図のこの記事から、あなたは別の存在としてUEを見つけることができません。それを覚えておいてください。
さらにもう1つのこと..図1には何かがありません。図2のように、ステップ2から始まり、ステップ5の後で終了する「直接債権処理」のような追加のフレームが必要です。私はそれを固定するのに疲れている。私を許してください。
Event Charging with Unit Reservation (ECUR)
図4は、ECURを実行するためにGyインタフェース上で必要とされるトランザクションを示す。 ECURは、イベント課金が個別のリザーブアクションとコミットアクションを必要とする場合に使用されます。
図4.セッションベースの与信管理のためのECUR
ネットワーク要素は、サービス要求を受信する。サービス要求は、ユーザまたは他のネットワーク要素によって開始されてもよい。
ステップ2.ネットワーク要素は、いくつかのユニット(金銭的または非貨幣単位)に対して予約単位操作を実行するために、CCI要求タイプのAVPをINITIAL_REQUESTに設定したクレジット制御要求(CCR)をOCSに送信する。知られている場合、ネットワーク要素は、要求メッセージに要求サービス単位(RSU)AVP(通貨単位または非通貨単位)を含むことができる。
ステップ3:サービスコスト情報がOCSによって受信されない場合、OCSは、評価機能に格付け要求を発行することによって受信されたサービス固有情報に従って、所望のサービスの価格を決定する。要求にサービスのコストが含まれている場合、OCSは指定された金額を直接予約します。与信残高が十分な場合、OCSはユーザーアカウントから対応する金額を予約します。
ステップ4.予約が行われると、OCSはCC-Request-TypeがINITIAL_REQUESTに設定されたクレジット・コントロール・アンサー(CCA)メッセージをネットワーク要素に返して、サービス実行を許可するコスト - サービスのコストを示す情報および残高AVPは、与信管理 - 応答メッセージに含まれる)。 OCSは、値フィールドを非ゼロ値に設定した有効時間(VT)AVPを返すことができる。 OCSは、低残高表示AVPにおいて、加入者口座残高がこの口座の所定の閾値未満に落ちたことを示すことができる。
ステップ5コンテンツ/サービス配信が開始され、予約されたユニットが同時に制御される。
ステップ6.コンテンツ/サービス配信が完了すると、ネットワーク要素はCC-Request-Type AVPを設定したCCRをTERMINATION_REQUESTに送信して、有効な与信管理セッションを終了し、使用ユニットを報告する。
ステップ7. OCSは、アカウントから使用された金額を控除します。該当する場合は、未使用の予約済みユニットが解放されます。
ステップ8:OCSは、TERMINATION_REQUESTを示すCC-Request-Type AVP(おそらく、サービスの累積コストを示すコスト情報AVPおよびクレジット制御に残存AVPが含まれるCCAメッセージを送信することによって、CCRメッセージの受信を確認する - 応答メッセージ)。
注:このシナリオは、上記の図に示されていない対応するタイマー(有効期限タイマーなど)によって管理されています。
Session Charging with Unit Reservation (SCUR)
ネットワーク要素は、セッション開始を受信する。セッション開始は、ユーザまたは他のネットワーク要素のいずれかによって行われてもよい。
ステップ2.ネットワーク要素は、いくつかのユニット(金銭的または非貨幣単位)に対して予約単位操作を実行するために、CCI要求タイプのAVPをINITIAL_REQUESTに設定したクレジット制御要求(CCR)をOCSに送信する。知られている場合、ネットワーク要素は、要求メッセージに要求サービス単位(RSU)AVP(通貨単位または非通貨単位)を含むことができる。
ステップ3:サービスコスト情報がOCSによって受信されない場合、OCSは、評価機能に格付け要求を発行することによって受信されたサービス固有情報に従って、所望のサービスの価格を決定する。要求にサービスのコストが含まれている場合、OCSは指定された金額を直接予約します。与信残高が十分な場合、OCSはユーザーアカウントから対応する金額を予約します。
ステップ4.予約が行われると、OCSはCC-Request-TypeがINITIAL_REQUESTに設定されたクレジット・コントロール・アンサー(CCA)メッセージをネットワーク要素に返して、サービス実行を許可するコスト - サービスのコストを示す情報および残高AVPは、与信管理 - 応答メッセージに含まれる)。 OCSは、値フィールドを非ゼロ値に設定した有効時間(VT)AVPを返すことができる。 OCSは、低残高表示AVPにおいて、加入者口座残高がこの口座の所定の閾値を下回ったことを示すことができる。
ステップ5コンテンツ/サービス配信が開始され、予約されたユニットが同時に制御される。
ステップ6.セッション配信中に、デビットユニットおよびその後の予約ユニット動作を実行するために、ネットワーク要素は、CC-Request-Type AVPをUPDATE_REQUESTに設定したCCRを送信し、使用ユニットを報告し、追加ユニットをそれぞれ要求する。 UPDATE_REQUESTに設定されたCC-Request-Type AVPを有するCCRメッセージは、有効期間内にクレジット管理アプリケーションの要求または有効時間が経過した場合に、INITIAL_REQUESTとTERMINATION_REQUESTとの間でネットワーク要素によって送信されなければならない。既知の場合、ネットワーク要素は、要求メッセージに要求サービス単位AVP(通貨単位または非通貨単位)を含むことができる。使用済みサービスユニット(USU)AVPは、ユーザのアカウントと予約されたユニットの両方からユニットを控除するために、CCRメッセージ内で補完される。
ステップ7. OCSは、アカウントから使用された金額を控除します。サービスコスト情報がOCSによって受信されない場合、OCSは、評価機能に格付け要求を発行することによって受信されたサービス固有情報に従って、所望のサービスの価格を決定する。要求にサービスのコストが含まれている場合、OCSは指定された金額を直接予約します。与信残高が十分な場合、OCSはユーザーアカウントから対応する金額を予約します。
ステップ8:控除および予約が完了すると、OCSは、コンテンツ/サービス配信を継続するために、CC要素(CC-Request-Type)がUPDATE_REQUESTに設定されたCredit-Control-Answerメッセージをネットワーク要素に返すService-Unit(GSU)AVP、およびサービスの累積コストを示すコスト情報(CI)AVPおよび残存残高AVPは、Credit-Control-Answerメッセージに含まれる)。 OCSは、CCAメッセージに最終承認単位を示す最終単位表示(FUI)AVPを含めることができる。 OCSは、低残高表示AVPにおいて、加入者口座残高がこの口座の所定の閾値を下回ったことを示すことができる。
ステップ9.セッション配信が継続され、予約されたユニットが同時に制御される。
ステップ10.セッションはネットワーク要素で終了する。
ステップ11.ネットワーク要素は、CC-Request-Type AVPを設定したCCRをTERMINATION_REQUESTに設定して、有効な与信管理セッションを終了し、使用されたユニットを報告する。
ステップ12. OCSは、アカウントから使用された金額を差し引く。該当する場合は、未使用の予約済みユニットが解放されます。
ステップ13. OCSは、TERMINATION_REQUESTを示すCC-Request-Type AVP(おそらく、サービスの累積コストを示すコスト情報AVPおよびクレジット・コントロールに残存AVPが含まれるCCAメッセージを送信することによって、CCRメッセージの受信を確認する - 応答メッセージ)。
注:このシナリオは、上記の図に示されていない対応するタイマー(有効時間タイマーなど)によって管理されます。
Gyはオンラインチャージシステム(OCS)とPCEFの間にあります。 ほとんどの場合、PCEFはPDN GW(Packed Data Network Gateway)または短いPGWに基づいています。
Gyインターフェースは、サービスデータフローに基づく課金のためのオンライン与信管理を可能にする。
いつものように、今日はかなり高いレベルの抽象的な人物で始めるのも良い方法です。 だから..お楽しみください。
基本的な構造は、オンラインクライアント(CTFによって表されるOCS)がリソース割り当てを要求し、与信管理情報をオンライン課金システム(OCS)に報告するメカニズムに従います。 前述のように、異なる課金シナリオに基づいて課金することができます。
Diameter OCSの基本原則
オンライン与信管理アプリケーション要件
オンライン課金の場合、IETF Diameter Credit Controlアプリケーションで定義された基本機能が使用されます。 基本的な構造は、オンラインクライアント(CTF)がリソースの割り当てを要求し、与信管理情報をOCS(オンライン課金システム)に報告するメカニズムに従います。
オンラインクライアントは、RFC 4006で記述されている「クライアント、イベントベース」および/または「クライアント、セッションベース」のステートマシンを実装します。
私。 クライアントが即時イベント課金(IEC)を申請すると、クライアント、イベントベースのステートマシンが使用され、クライアントが3GPPで定義されているユニット予約(ECUR)でイベントチャージを適用すると、 最初と最後の質問に対する "CLIENT、SESSION BASED"状態機械。
Validity-Time AVPとTime "Tcc"の使用と値は、与信管理サーバー(OCS)の単独の制御下にあり、OCSのオペレータ構成によって決定されます。
Gyインタフェースによる処理
オンライン課金(OCS)の場合、追加のAVPはDiameterプロトコルで定義されました。
オンライン課金のためのユーザークレジットの制御に関する3つのケースが区別されます。
Immediate Event Charging (IEC)
Event Charging with Unit Reservation (ECUR)
Session Charging with Unit Reservation (SCUR)
Immediate Event Charging(IEC)の場合、イベントの与信管理プロセスは、特定の与信管理イベントに対して与信管理要求(CCR)とともに送信される対応するCC要求タイプEVENT_REQUESTによって制御されます。
ユニット予約(ECUR)によるイベント課金の場合、所与の与信管理イベントに対する課金のためにCCリクエストタイプのINITIAL / TERMINATION_REQUESTが使用されるが、サービスデリバリの前に予約が行われ、成功 配達。
ユニット予約(ECUR)を伴うセッション課金は、CC要求タイプの初期/更新および終了要求を要求する。
ネットワーク要素は、CCRイベントメッセージが生成されるIEC、またはCCRの初期値および終了を使用するECURを適用することができる。 IECまたはECURを適用するかどうかの決定は、サービスおよび/またはオペレータの方針に基づいています。
Immediate Event Charging (IEC)
図2は、イベントベースの直接振り込み処理を実行するためにGyインタフェース上で必要とされるトランザクションを示す。 代わりに、サービス/コンテンツ配信の前にダイレクト退会操作を実行してもよい。 ネットワーク要素は、このシナリオが使用されたときに、要求されたサービスの実行が成功していることを保証する必要があります。
図2 IEC直接借り換えオペレーション
ネットワーク要素は、サービス要求を受信する。
ステップ2.ネットワーク要素は、サービス実行の前に直接引き落としを実行する。ネットワーク要素(DCCAクライアントとして機能する)は、CC-Request-Type AVPをEVENT_REQUESTに設定したクレジット制御要求(CCR)を送信して、サービス固有の情報をOCS(DCCAサーバとして機能する)に通知します。要求アクションAVP(RA)はDIRECT_DEBITINGに設定されます。既知の場合、ネットワーク要素は、要求メッセージ内に要求サービス単位AVP(RSU)(通貨単位または非通貨単位)を含むことができる。
ステップ3.クレジット制御要求メッセージを送信すると、ネットワーク要素は、通信監督タイマ「Tx」を開始する。クレジット・コントロール・アンサー(CCA)メッセージを受信すると、ネットワーク要素はタイマーTxを停止する。
ステップ4. OCSは、関連するサービス課金パラメータを決定する。
ステップ5:OCSは、CC-Request-Type AVPをEVENT_REQUESTに設定したCredit-Control-Answerメッセージをネットワーク要素に返して、サービスの実行を許可する
(サービスのコストを示す認可サービスユニットAVP(GSU)および場合によってはコスト情報AVP(CI)は、クレジット制御応答メッセージに含まれる)。
クレジット・コントロール・アンサー・メッセージは、それに応じてネットワーク要素によってチェックされなければならず、要求されたサービスはサービス提供と同時に制御される。払い戻し情報AVPは、REFUND-ACCOUNTメカニズム中に送信されるために、Credit-Control-Answerメッセージに含めることができます。下記のシナリオを参照してください。
ステップ6.サービスが提供されています。
注:上記のメカニズムを使用してCHECK_BALANCEとPRICE_ENQUIRYも実行することができます。
払い戻しの目的で取引を見てみましょう。
直接引き落とし操作が実行されます。
ステップ1直接借り方操作によって前に課金されたサービスは、最終的に不成功に終わったことが証明されます。
ステップ2.結果として、ネットワーク要素は、関連する払い戻しを実行するために、直接振替操作を実行する。ネットワーク要素(DCCAクライアントとして機能する)は、CC-Request-Type AVPをEVENT_REQUESTに設定したクレジット制御要求(CCR)を送信して、サービス固有の情報をOCS(DCCAサーバとして機能する)に通知します。要求アクションAVP(RA)は払い戻しアカウントに設定されています。以前のIEC CCAで受信された場合、ネットワーク要素にはRefund-Information AVPが含まれます。
ステップ3.クレジット制御要求メッセージを送信すると、ネットワーク要素は、通信監督タイマ「Tx」を開始する(RFC4006 [402])。クレジット・コントロール・アンサー(CCA)メッセージを受信すると、ネットワーク要素はタイマーTxを停止する。
ステップ4. OCSは、CCRに含まれるAVPを読み取り、それに応じて払い戻しを実行する。
ステップ5. OCSは、CC-Request-Type AVPをEVENT_REQUESTに設定したCredit-Control-Answerメッセージと関連する結果コードを返す。
私はフローシーケンスの図を描く方法を変えましたが、UEはそれほど重要ではないので、私はそれを行いました。だから次の図のこの記事から、あなたは別の存在としてUEを見つけることができません。それを覚えておいてください。
さらにもう1つのこと..図1には何かがありません。図2のように、ステップ2から始まり、ステップ5の後で終了する「直接債権処理」のような追加のフレームが必要です。私はそれを固定するのに疲れている。私を許してください。
Event Charging with Unit Reservation (ECUR)
図4は、ECURを実行するためにGyインタフェース上で必要とされるトランザクションを示す。 ECURは、イベント課金が個別のリザーブアクションとコミットアクションを必要とする場合に使用されます。
図4.セッションベースの与信管理のためのECUR
ネットワーク要素は、サービス要求を受信する。サービス要求は、ユーザまたは他のネットワーク要素によって開始されてもよい。
ステップ2.ネットワーク要素は、いくつかのユニット(金銭的または非貨幣単位)に対して予約単位操作を実行するために、CCI要求タイプのAVPをINITIAL_REQUESTに設定したクレジット制御要求(CCR)をOCSに送信する。知られている場合、ネットワーク要素は、要求メッセージに要求サービス単位(RSU)AVP(通貨単位または非通貨単位)を含むことができる。
ステップ3:サービスコスト情報がOCSによって受信されない場合、OCSは、評価機能に格付け要求を発行することによって受信されたサービス固有情報に従って、所望のサービスの価格を決定する。要求にサービスのコストが含まれている場合、OCSは指定された金額を直接予約します。与信残高が十分な場合、OCSはユーザーアカウントから対応する金額を予約します。
ステップ4.予約が行われると、OCSはCC-Request-TypeがINITIAL_REQUESTに設定されたクレジット・コントロール・アンサー(CCA)メッセージをネットワーク要素に返して、サービス実行を許可するコスト - サービスのコストを示す情報および残高AVPは、与信管理 - 応答メッセージに含まれる)。 OCSは、値フィールドを非ゼロ値に設定した有効時間(VT)AVPを返すことができる。 OCSは、低残高表示AVPにおいて、加入者口座残高がこの口座の所定の閾値未満に落ちたことを示すことができる。
ステップ5コンテンツ/サービス配信が開始され、予約されたユニットが同時に制御される。
ステップ6.コンテンツ/サービス配信が完了すると、ネットワーク要素はCC-Request-Type AVPを設定したCCRをTERMINATION_REQUESTに送信して、有効な与信管理セッションを終了し、使用ユニットを報告する。
ステップ7. OCSは、アカウントから使用された金額を控除します。該当する場合は、未使用の予約済みユニットが解放されます。
ステップ8:OCSは、TERMINATION_REQUESTを示すCC-Request-Type AVP(おそらく、サービスの累積コストを示すコスト情報AVPおよびクレジット制御に残存AVPが含まれるCCAメッセージを送信することによって、CCRメッセージの受信を確認する - 応答メッセージ)。
注:このシナリオは、上記の図に示されていない対応するタイマー(有効期限タイマーなど)によって管理されています。
Session Charging with Unit Reservation (SCUR)
ネットワーク要素は、セッション開始を受信する。セッション開始は、ユーザまたは他のネットワーク要素のいずれかによって行われてもよい。
ステップ2.ネットワーク要素は、いくつかのユニット(金銭的または非貨幣単位)に対して予約単位操作を実行するために、CCI要求タイプのAVPをINITIAL_REQUESTに設定したクレジット制御要求(CCR)をOCSに送信する。知られている場合、ネットワーク要素は、要求メッセージに要求サービス単位(RSU)AVP(通貨単位または非通貨単位)を含むことができる。
ステップ3:サービスコスト情報がOCSによって受信されない場合、OCSは、評価機能に格付け要求を発行することによって受信されたサービス固有情報に従って、所望のサービスの価格を決定する。要求にサービスのコストが含まれている場合、OCSは指定された金額を直接予約します。与信残高が十分な場合、OCSはユーザーアカウントから対応する金額を予約します。
ステップ4.予約が行われると、OCSはCC-Request-TypeがINITIAL_REQUESTに設定されたクレジット・コントロール・アンサー(CCA)メッセージをネットワーク要素に返して、サービス実行を許可するコスト - サービスのコストを示す情報および残高AVPは、与信管理 - 応答メッセージに含まれる)。 OCSは、値フィールドを非ゼロ値に設定した有効時間(VT)AVPを返すことができる。 OCSは、低残高表示AVPにおいて、加入者口座残高がこの口座の所定の閾値を下回ったことを示すことができる。
ステップ5コンテンツ/サービス配信が開始され、予約されたユニットが同時に制御される。
ステップ6.セッション配信中に、デビットユニットおよびその後の予約ユニット動作を実行するために、ネットワーク要素は、CC-Request-Type AVPをUPDATE_REQUESTに設定したCCRを送信し、使用ユニットを報告し、追加ユニットをそれぞれ要求する。 UPDATE_REQUESTに設定されたCC-Request-Type AVPを有するCCRメッセージは、有効期間内にクレジット管理アプリケーションの要求または有効時間が経過した場合に、INITIAL_REQUESTとTERMINATION_REQUESTとの間でネットワーク要素によって送信されなければならない。既知の場合、ネットワーク要素は、要求メッセージに要求サービス単位AVP(通貨単位または非通貨単位)を含むことができる。使用済みサービスユニット(USU)AVPは、ユーザのアカウントと予約されたユニットの両方からユニットを控除するために、CCRメッセージ内で補完される。
ステップ7. OCSは、アカウントから使用された金額を控除します。サービスコスト情報がOCSによって受信されない場合、OCSは、評価機能に格付け要求を発行することによって受信されたサービス固有情報に従って、所望のサービスの価格を決定する。要求にサービスのコストが含まれている場合、OCSは指定された金額を直接予約します。与信残高が十分な場合、OCSはユーザーアカウントから対応する金額を予約します。
ステップ8:控除および予約が完了すると、OCSは、コンテンツ/サービス配信を継続するために、CC要素(CC-Request-Type)がUPDATE_REQUESTに設定されたCredit-Control-Answerメッセージをネットワーク要素に返すService-Unit(GSU)AVP、およびサービスの累積コストを示すコスト情報(CI)AVPおよび残存残高AVPは、Credit-Control-Answerメッセージに含まれる)。 OCSは、CCAメッセージに最終承認単位を示す最終単位表示(FUI)AVPを含めることができる。 OCSは、低残高表示AVPにおいて、加入者口座残高がこの口座の所定の閾値を下回ったことを示すことができる。
ステップ9.セッション配信が継続され、予約されたユニットが同時に制御される。
ステップ10.セッションはネットワーク要素で終了する。
ステップ11.ネットワーク要素は、CC-Request-Type AVPを設定したCCRをTERMINATION_REQUESTに設定して、有効な与信管理セッションを終了し、使用されたユニットを報告する。
ステップ12. OCSは、アカウントから使用された金額を差し引く。該当する場合は、未使用の予約済みユニットが解放されます。
ステップ13. OCSは、TERMINATION_REQUESTを示すCC-Request-Type AVP(おそらく、サービスの累積コストを示すコスト情報AVPおよびクレジット・コントロールに残存AVPが含まれるCCAメッセージを送信することによって、CCRメッセージの受信を確認する - 応答メッセージ)。
注:このシナリオは、上記の図に示されていない対応するタイマー(有効時間タイマーなど)によって管理されます。
Subscribe to:
Posts (Atom)
Interfaces and their protocol stacks
インタフェースとそのプロトコルスタック 主要なネットワーク要素に精通した後、これら要素間のインタフェースをよりよく知る時期が来ています。 インタフェースは、MME、SGWおよびPGWが他のネットワーク要素(例えば、HSSまたはPCRF)と協働することを可能にする。 それらの...
-
モバイル加入者の識別 一般情報 ユニークな国際モバイル加入者アイデンティティ(IMSI)は、各(GSM、UMTS、およびEPS)システム内の各モバイル加入者に割り当てられるものとする。加入者識別機密性サービスをサポートするために、VLR、SGSNおよびMMEは、訪問移動加入...
-
Periodic TAU 周期的トラッキングエリア更新は、UEのネットワークへの利用可能性を定期的に通知するために使用される。 この手順は、定期的なトラッキングエリア更新タイマ(タイマT3412)によってUEにおいて制御される。 タイマT3412の値は、ATTACH ACCEP...
-
EPSモビリティ管理(EMM)状態は、モビリティ管理手順に起因するモビリティ管理状態を記述する。 アタッチおよびトラッキングエリアの更新手順。 仕様に記載されている2つのEMM状態があります。 EMM-DEREGISTERED EMM-REGISTERED EPS接続管...