直径プロトコルでの Credit-Control-Application と Ro アプリケーションの違いを知っている人はいますか? Mobicents の直径スタックでの実装は、ほぼ同じです。
対応する RFC および 3GPP ドキュメント内を検索しましたが、オンライン課金プロセスに使用する必要があるものを見つけることができませんでした。
直径プロトコルでの Credit-Control-Application と Ro アプリケーションの違いを知っている人はいますか? Mobicents の直径スタックでの実装は、ほぼ同じです。
対応する RFC および 3GPP ドキュメント内を検索しましたが、オンライン課金プロセスに使用する必要があるものを見つけることができませんでした。
簡単に言えば、IETF はプロトコルを指定し、3GPP は非常に特殊なコンテキストでプロトコルを使用する方法を指定します。3GPP では、参照ポイント (または「インターフェース」) を指定する際に、追加の要件または推奨事項が用意されている場合がありますが、通常、これは IETF RFC に違反することなく行われます (そうでない場合、競合は解決のために IETF に連絡する必要があります)。
上記は通常、IETF で指定されたプロトコルと 3GPP での対応する使用法との関係のほとんどを説明しています。
Diameter アプリケーションの場合、3GPP は、追加のアプリケーション ID、AVP、および情報要素 (IE) を他の 3GPP インターフェイスから AVP にマップする方法を定義して、IETF RFC を拡張することもあります。
次に、Credit-control Diameter アプリケーションと Ro インターフェイスについて説明します。前者はRFC 4006で定義され、後者は3GPP TS 32.299で定義されています。私は 3GPP 仕様を詳しく調べたわけではありませんが、いくつかの違いを見つけるのはそれほど難しくありません。たとえば、Ro インターフェイスの Credit-Control-Request (CCR) メッセージは、32.299 の表 6.4.2 で指摘されているように、Requested-Service-Unit AVP およびその他のいくつかを使用しません。ただし、CCR メッセージには、29.212 で定義されているグループ AVP である QoS-Information が含まれる場合があり、これは Ro 固有です。32.299 の表 6.4.3 では、Credit-Control-Answer メッセージについて同様の説明があり、ドキュメントで説明されているその他の違いに注意してください。
Mobicents に関しては、私はその実装の経験はありませんが、オープンソースのバージョンが 3GPP 仕様に完全に準拠しておらず、追加機能の一部が省略されていることは驚くことではありません。