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メッセージの受信を確認する - 応答メッセージ）。
注：このシナリオは、上記の図に示されていない対応するタイマー（有効時間タイマーなど）によって管理されます。
No comments:
Post a Comment