マルチクラスタPCRFでのLWRを使用したE911の効率的なベアラ管理

はじめに

このドキュメントでは、LWRおよびUDC VMを使用したE911コールなどの緊急コールの効率的なベアラ処理について説明し、優先順位付けされたセットアップ、信頼性、およびネットワークリソースの使用の最適化を保証します。

アーキテクチャ概要

E911緊急コールでは、コール品質とネットワーク可用性を保証するために、ベアラ管理の優先順位付けが要求されます。このソリューションでは、Lightweight Replication(LWR)およびUser Data Cache(UDC)VMを利用します。LWRは内部でレプリケーションにKafka DBを使用します。Kafkaは、複数のPCRFクラスタ間で高速レプリケーションを提供し、緊急コール時の協調的なベアラ制御を可能にします。

この機能により、PCRFは、接続されたAPNの数、通知ステータス、中間状態（アップデートやベアラーリリースなど）などの加入者情報を共有できます。

LWRクラスタコンポーネント

• Zookeeper:コントローラを選択し、コントローラが1つのみであることを確認し、クラッシュした場合は新しいコントローラを選択するために使用されます。クラスタのメンバーシップ(ブローカが有効でクラスタの一部となっている)を管理し、トピックの構成（存在するトピック、各トピックに含まれるパーティションの数、レプリカの場所、優先されるリーダー、各トピックに設定されている構成の上書き）を管理します。

• ブローカ：LWRは、ホスト上で実行されているメッセージキューであるブローカサービスを使用します。 Kafkaブローカーは生産者からメッセージを受け取り、一意のオフセットでキー設定されたディスクに保存します。消費者はトピック、パーティション、オフセットでメッセージを取得でき、Zookeeperを使用して直接または間接的に情報を共有することでKafkaクラスタを作成できます。
• MirrorMaker:Kafka MirrorMakerは、Kafkaクラスタ間でデータをミラーリングするために使用されます。これにより、あるデータセンターから別のデータセンターにデータのレプリカを作成できます。複数のミラーリングプロセスを同時に実行して、スループットと耐障害性を向上させることができます。

PCRF:LWR領域とトピックの設定

実稼働環境では、PCRFを西、南東、北東などの複数の領域にグループ化できます。各リージョンには、LWRを介して相互接続された約5 ～ 6個のPCRFノードがあります。PCRFは、サブスクライバに対してイベントが発生するたびに、LWRのデータを書き込みまたは更新します。これらのイベントの例を次に示します。

• ネットワークへの接続

• サービス/ベアラの作成
• ネットワークから切断

プラグインの設定

「cluster-udc」の下に、「lwr client plugin」の設定が追加されました。これには以下が含まれます。

• リージョン名：このPCRFが属するリージョンの名前。
• Front End Id:PCRFのフロントエンドID。この値は、UDC設定で使用されている既存のフロントエンドIDの値と同じである必要があります。
• Front End Id in Regions：そのリージョン内のすべてのPCRFのフロントエンドId。
• トピック表：ゾーキーパーとブローカにマップされているトピック名のリスト。ローカルなトピックとローカルでないトピックを示します。このテーブルには、3つのリージョントピックがすべて設定されている必要があります。ローカルトピックはtrueに設定する必要があります。残りの2つのトピックは、ローカルトピックの場合はfalseに設定します。

プラグイン設定：LWRクライアントプラグイン設定

LWRサービスオプション

LWR書き込みをサポートする新しいサービスオプションが追加されました。このサービス構成をUDCサービスで使用する必要があります。

LWRサービスオプションは、どのトピックデータを書き込むかを選択するトピック名と、LWRに書き込む属性のリストを使用します。トピック名は、フロントエンドIDに基づいてCRDテーブルから選択する必要があります。

サービスオプション：LWR

CRDの変更 – Lwr-Apn-Mapping

次の表は、LWRへの属性(lwrpcrferab)の書き込みの制御と、E911ベアラ管理に対してベアラを解放するかどうかの制御を提供します。

検索テーブルグループ> CRD: Lwr-Apn-Mapping

UDCは、'enable_lwr_write'がtrueの場合にのみ、'lwrpcrferab'属性をLWRに書き込みます。これにより、運用チームはAPNに対するLWR書き込みを有効にすることができます。たとえば、最初、LWR書き込みは一部のテストAPNに対してのみ有効で、他のすべてのAPNに対しては無効でした。これにより、運用チームはLWRの機能とレプリケーションが正しく機能していることを確認できます。

同様に、「bearer_release」がtrueの場合、PCRFのみがそのAPNベアラーをSOSコール受信時に解放できます。APNに対して「bearer_release」がfalseの場合、E911ベアラー管理はそのAPNに対してキックインできません。

カスタム参照データテーブル： Lwr-Apn-Mapping

トピックルックアップ

このCRDテーブルは、フロントエンドIDに基づいてトピック名を導出するために使用されます。この情報は、PCRFが設定されている特定のトピックに接続するためにLWRサービスオプションで使用されます。

カスタム参照データテーブル：トピック参照

主要な概念とデータフロー

属性の複製

• 主に複製される属性は、E911に関連するベアラステートをエンコードする「lwrpcrferab」です。

• PCRFはこの属性をUDCに書き込み、UDCはLWRを介して伝搬します。

• LWRはサイト間で属性を複製し、ローカルUDCとPCRFを更新して同期ベアラ状態を維持します。

ドメインとサービスの更新

• 新しいドメインは、UDCおよびLDAPを介したSOS APN属性管理をサポートします。

• 現在、既存のSOSドメインは「lwrpcrferab」属性を使用しています。

• ベアラリリースを許可するためにSOSコール受け入れを遅延させる。

• SOSコール中の新規ベアラ/セッション要求の拒否

• SOSコールの開始時にIMSおよびMCPTTベアラを解放します。

• SOSコール中にベアラを一時停止し、後で復元します。

前提

• LWRの書き込み有効化は、段階的な導入とテストを可能にするためにAPNごとに制御されます。

• PCRFは、「lwrpcrferab」属性を新しいセッション要求に対してのみ書き込みます。また、属性がすでに存在する場合は、過剰な書き込みを防ぎます。

• SOSコール受け入れのデフォルトの遅延（たとえば600ミリ秒）により、PCRFは緊急コールを確立する前に優先度の低いベアラを解放できます。

• 古い属性ガードタイマーにより、古くなったSOSセッションまたは属性をタイムリーにクリーンアップできます。

コールフロー

• データAPNの「attach」をPGWに送信してから、PGWがCCR-IをPCRF Aに送信し、正常な応答を受信します。
• ホットスポットAPNの「attach」をPGWに送信してから、PGWがCCR-IをPCRF Aに送信し、正常な応答を受信します。
• 「緊急コール」をPGWに送信してから、PGWがCCR-IをPCRF Bに送信し、正常な応答を受信します。
• PCRFは、「lwrpcrferab」という属性を更新し、そのステージを「Start」、その優先度を「1」に設定します。 これは、緊急コール処理の開始を示す可能性が高く、最も高い優先順位を割り当てます。
• PCRFはこの更新された「lwrpcrferab」属性をUDCに書き込みます。
• その後、UDCは「lwrpcrferab」属性をLWRに書き込みます。一貫性と可用性を確保するために、「lwrpcrferab」属性はLWRクラスタ内のすべてのノードとリージョンに複製されます。
• PCRFマルチクラスタ内の各ノードは、複製された属性情報を使用してローカルUDCおよびPCRFインスタンスを更新します。
• その後、PCRFは優先順位の低いベアラを解放します。このような優先順位の低いサービスの例としては、ホットスポット、IMSビデオ、IPMEなどがあります。このアクションにより、ネットワークリソースが高優先度の緊急コール用に解放されます。
• SOS CCA-Iメッセージには遅延が設定されています（デフォルトは600ミリ秒）。これは、続行する前にリソースの割り当てまたは同期を確認するためです。
• 最後に、ホットスポットなどの特定のAPNに対する新しいベアラまたはセッション要求を拒否し、新しい低優先順位接続を防止することで、緊急コールの優先順位をさらに高めます。
• SOSコールを削除するためにGWからCCR-Tが送信されると、PCRFはデータAPNの新しいベアラ作成要求を受け入れます。

利点と影響

• 高可用性と拡張性：KafkaベースのLWRは、複数のデータセンター間でリアルタイムのレプリケーションと耐障害性を確保します。

• プライオリティ処理：緊急コール中に、プライオリティの低いベアラを動的に解放したり、一時停止したりできます。

• 運用制御：APNごとに段階的な機能有効化と詳細なベアラ管理をサポートします。

• 緊急コール品質の向上：効率的なベアラリソース管理により、信頼性の高いE911コールセットアップおよびメンテナンスがサポートされます。

結論

LWRを使用したベアラ管理ソリューションは、E911コール中のLTEベアラの優先順位付けと管理を行うための、堅牢でスケーラブルかつ効率的なメカニズムを提供します。Kafkaベースのレプリケーションと同期された属性管理を活用することで、高可用性、運用の柔軟性、緊急コールの信頼性の向上を実現します。