携帯電話加入者の交渉の修正について

私たちは皆、携帯電話での交渉を記録できると聞きました...この問題に関するいくつかの計算/考えを以下に示します。



特定のオペレーターのすべての加入者のすべてのコールを記録および保存するシステムを構築するのは現実的ですか？



GSM標準モバイルネットワーク機器を使用すると、特定の加入者または数十人の加入者の通話を録音および聞くことができます。 この事実から、一定期間の加入者のすべての会話を記録および保存するために、オペレーターが同様の機能を使用すると広範囲に及ぶ結論がしばしば出されます。 加入者が特別なサービスの細心の注意の対象になった場合、オペレーターは、要求に応じて、ほぼ6か月前に会話の録音を提供できると言います。





本当ですか？



計算のために、ロシア最大のオペレーターの1つのネットワーク上のコール数に関する公開データを取得できます。 このオペレーターは、1か月あたり平均134分の音声トラフィックを消費する5150万人のサブスクライバーにサービスを提供しています。ほとんどの場合、発信コールのみです。



したがって、1か月間のすべての加入者の通話の合計時間は次のようになります。



5,150万x 134分= 69億分



携帯電話で処理してデジタル化した後、GSMネットワークの音声信号は、 9.6 Kbpsの速度でデジタルストリームの形式で送信されます。 したがって、追加の処理を行わない場合、1か月のすべてのサブスクライバーコールにはかなりの量の情報が含まれます。



69億分x 60秒x 9.6 Kb / s /（8 b / b）= 514 B = 500 TB



これで、次のようなシステムを構築および保守することがどれほど難しい（そして費用がかかる）かを考えることができます。



1.特定のネットワーク内のすべての加入者の発着信を記録します。

2.十分に高速ですか。

3.会話を簡単に見つけることができます（たとえば、発信者IDと日付で）。

4.少なくとも3か月間、情報を保存できます。

5.サプライヤのスイッチング機器で動作します。

6.信号および音声チャネル、スイッチのプロセッサ、およびその他のネットワーク機器に大きな追加の負荷をかけないため、ネットワークが通話を処理する能力に影響を与えません。

7.十分な信頼性-たとえば、会話の少なくとも99％を記録します。

8.十分に安全-特別な許可を得ていない人（例えば、検察官の制裁）への機密情報の漏洩を許可しません。



これから何が続きます：



1.すべての会話が記録されます=>システムは、加入者がモバイルであることを恐れてはなりません。 つまり、会話中に加入者がベースステーション間を移動したり、別のスイッチのサービスエリアに移動したり、コールをリダイレクトしたり、会議で結合したり、同時に複数のコールに応答したりできることを考慮する必要があります。

2.システムは十分に高速に動作します=>ストレージへの録音の前に実行される音声の後処理は、オンザフライで動作できるはずです。

3.記録されたものを見つける機能=>システムには、電話番号とSIMカードの変更を考慮に入れるために、インデックス/検索エンジンを装備し、加入者に関する基本データを保存するシステムと統合する必要があります。 完了したコールのデータは、大幅な遅延なしにシステムに表示されるはずです。

4. 3か月間記録されたストレージ=>上記の計算に基づいて、少なくとも1,500 TBのディスク容量が必要です（音声信号の後処理を使用しない場合）。

5.さまざまなメーカーのソリューションとの互換性=>指定されたインターフェイスが必要です。これは、スイッチング機器のすべての主要メーカーで利用できることが保証されています。

6.著しい負荷なし=>音声をMP3に圧縮するなど、タスクに特徴のないスイッチやチャネル機器にコールプロセッサをロードしないでください。

7.信頼性=>通信チャネル、電源、ハードドライブには冗長性が必要です。

8.セキュリティ=>記録された情報にアクセスするための集中管理および制御メカニズムが必要です。



モバイル加入者の動きを認識し、それらに適切に応答するには、システムをスイッチに接続する必要があります（ベースステーションコントローラーなどではありません）。これは、加入者のモビリティに関連するすべての機能を担当するスイッチであるためです。 5000万人の加入者にサービスを提供できるネットワークには、約50の平均スイッチが含まれます。



ここで、各MSCの近くに配置することでシステムを分散させることができるかどうかを確認します。情報を一次蓄積するためのリポジトリだけでなく、よりインテリジェントなもの（たとえば、指定されたすべての要件を直ちに満たすノード）を配置します



最初に、サブスクライバAからサブスクライバBへのコールをサービスするいくつかの可能なシナリオの1つを想像してください。



シナリオ1 ：コール全体で、サブスクライバAはスイッチXのサービスエリアにあり、サブスクライバBはスイッチYのサービスエリアにあります。この場合、選択した任意のスイッチで会話を録音できます。 両方のスイッチで記録が実行されると、結果として完全に同一の2つのレコードが取得され、中央リポジトリに保存する前に、そのうちの1つを捨てることができます。



シナリオ2 ：コール全体で、サブスクライバAはスイッチXのサービスエリアにあり、サブスクライバBはスイッチYのサービスエリアにありますが、コールは中間スイッチZを通過します。シナリオは、レコードの同一コピーがあることを除いて、前のシナリオと非常に似ています3つあります。



シナリオ3 ：会話の開始時、サブスクライバAはスイッチXのカバレッジエリアにあり、サブスクライバBはスイッチYのカバレッジエリアにあり、会話中に移動します：サブスクライバAはスイッチTのカバレッジエリアに行き、サブスクライバはスイッチSのカバレッジエリアに行きます。この場合、会話の完全な録音はパーツから組み立てる必要があります。 全部で4つの部分があり、それらから4つの可能な方法でレコードの2つの完全なコピーを組み立てることができます。



通話中に両方のサブスクライバーが会議および通話保留サービスを使用でき、さらに複数の中間スイッチがある場合（さらに、サブスクライバーの移動中に変更される場合がある）が光栄である場合、一般的なケースでは、完全に収集することが明らかになります会話録音では、異なるソースからのデータの相関の問題を解決する必要があります。 同様の作業は、相互運用者課金システムによって行われます。そのアーキテクチャは、架空のグローバルリスニングシステムの設計の出発点として使用できます。 次の2つのオプションから選択する必要があります。



*何らかの種類の共通の中央ストレージに蓄積されたすべてのデータを収集し、そこで処理を実行します。 これにより、処理と保守が簡素化されますが、処理センターでかなりの処理能力が必要になります。

*コールに関するメタデータのみ（誰、誰、いつコールしたか）を中央リポジトリで収集し、それらを関連付けて、どのスイッチからの通話のどの部分が会話の完全な記録を提供するかを理解します。 会話の録音自体を配布できます。 相関結果は、分散リポジトリから特定の会話の一部を抽出するために使用されます。 このアプローチは、システムの特定の各ノードの計算能力の要件を削減しますが、その複雑さを大幅に増加させ、メンテナンスと「フロート状態を維持」を複雑にします。



さらなる計算のために、セキュリティと保守の容易さの観点から、情報を1つの中央の場所に保存して処理する方が良いと仮定します。 しかし、最初に、データをそこに配信する必要があります。



簡単にするために、スイッチの負荷は均等かつ継続的に分散されると想定しています。 したがって、500 Tbのコールが50台のスイッチに分配され、各スイッチには1か月あたり10 Tbの音声トラフィックがあります。 この量の情報を取得するには、帯域幅チャネルが必要です。



10 * 10244 /（3600秒* 24時間* 30日）* 8ビットのバイト

= 4241943 bps

= 32メガビット/秒



合計で、50のそのようなチャネルを推定に記録します。



さらに、データストレージの適切な品質を確保するために、故障したメディアの交換に使用するメディアの少なくとも5％の量のスペアメディアが必要です。



何台のハードドライブが必要ですか？ 500 GBの3000ウィンチェスターから6000（前処理なしですべてを記述し、すべての会話を2回記録する場合-発信者と受信者に対して）。 したがって、毎年同じハードドライブが150〜300台供給されます。



さらに、インデックス可能なストレージ内の非常に多くのハードドライブを、何らかの種類のユーザーアクセスインターフェイスと組み合わせる必要があります。 ストレージは、すべてのスイッチからの会話の中断のない記録（1600メガビット/秒の速度）、移動中の検索インデックスの更新、および記録された会話の検索と取得のためのリクエストの処理を保証する必要があります。



このようなリポジトリの可能なアーキテクチャの詳細については掘り下げません。 これまでにカウントしたすべてを簡単にリストしましょう。



*メディア：各500 GBの3000-6000ハードドライブ、または音声圧縮が8 kbps mp3の場合は3倍（おおよそ）ハードドライブが少ない-GSMコーデックは既に音声を圧縮しているため、より大きなゲインは達成できません。 当然、「保存された」ハードドライブの代わりに、圧縮を実行するプロセッサを追加する必要があります。

* 32 mbpsで50の通信チャネルを構築するためのインフラストラクチャ。

*リポジトリとその機能（インデックス作成、必要なレコードの検索、古いレコードの検索と削除、サブスクライバー管理システムとの統合）へのインターフェイスを提供するサーバー。

*すべての機器の電源と環境制御。

*機器用のサーバールームに配置します。

*システム全体の運用のためのインフラストラクチャ（スタッフ、倉庫、物流など）



技術的にはこれらすべてが実行可能であることは明らかです。 唯一の問題は経済的実現可能性です。



こうした「贅沢」にお金を払うのは、そのような投資に見返りがないという理由だけで、彼がそれについて執inに尋ねられたからです。 私の知る限り、事業者にそのような「サービス」の提供を義務付ける法律はどこにも存在しないため、州または法執行機関からの「永続的な要求」についてのみ話すことができますが、それ以上は何もしません。



どの事業者が、従業員のみの努力によってこの規模のソリューションを構築および維持するのに十分な現地の技術的専門知識を持っているでしょうか？ これが非常にシンプルで費用対効果が高いと思われる場合は、大規模な通信事業者が独自の請求、財務、ERPシステムを完全に作成していない理由を考えてください。



こうしたシステムを独自に開発できない事業者向けのターンキーソリューションのサプライヤーとメーカーはどこにありますか？ 最終的に、実生活のリスニングシステムに関する情報は7つのアザラシの背後にある秘密ではありません。これを確信するには、インターネットで「SORM」または「合法的傍受」というキーワードを検索するだけで十分です。



これらの質問に自分で答えることで、携帯電話ですべての会話を記録するシステムを作成できるかどうかを自分で決めることができます。