▶ アリス エンタープライジズ リミティド ライアビリティ カンパニーの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-01-29
(54)【発明の名称】仮想化コアソースのためのＩＰＤＲ通信システム
(51)【国際特許分類】
H04L 43/04 20220101AFI20240122BHJP
【ＦＩ】
H04L43/04
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023540510
(86)(22)【出願日】2022-01-20
(85)【翻訳文提出日】2023-06-30
(86)【国際出願番号】 US2022013196
(87)【国際公開番号】W WO2022159631
(87)【国際公開日】2022-07-28
(31)【優先権主張番号】63/139,941
(32)【優先日】2021-01-21
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】521311654
【氏名又は名称】アリス エンタープライジズ リミティド ライアビリティ カンパニー
(74)【代理人】
【識別番号】100099759
【弁理士】
【氏名又は名称】青木 篤
(74)【代理人】
【識別番号】100123582
【弁理士】
【氏名又は名称】三橋 真二
(74)【代理人】
【識別番号】100092624
【弁理士】
【氏名又は名称】鶴田 準一
(74)【代理人】
【識別番号】100114018
【弁理士】
【氏名又は名称】南山 知広
(74)【代理人】
【識別番号】100153729
【弁理士】
【氏名又は名称】森本 有一
(74)【代理人】
【識別番号】100151459
【弁理士】
【氏名又は名称】中村 健一
(72)【発明者】
【氏名】ロバート マガルディ
(72)【発明者】
【氏名】カルティク ラジャリンガリ
(72)【発明者】
【氏名】マーク ベイズマン
(72)【発明者】
【氏名】サンタナ チャリ
(72)【発明者】
【氏名】ティモシー ディロン
(57)【要約】
システムは、ｖＣｏｒｅ及びＩＰＤＲデータを受信するためのメッセージングシステムを含む。メッセージングシステムからのＩＰＤＲデータは、ＩＰＤＲエクスポータによってＩＰＤＲコレクタに伝送される。
【特許請求の範囲】
【請求項1】
インターネットプロトコル詳細記録データ取得システムであって、（ａ）受信したデータを複数の第一の顧客デバイス用の同軸ケーブルに提供するのに好適なアナログデータに変換するリモートファイバノードを含む伝送ネットワークを通して前記複数の第一の顧客デバイスに接続されているヘッドエンドであって、前記ヘッドエンドが、その各々がそれぞれのプロセッサを含む少なくとも一つのサーバを含む、ヘッドエンドと、
（ｂ）前記ヘッドエンドの前記サーバのうちの一つにインスタンス化された、前記伝送ネットワークを通して前記複数の第一の顧客デバイスにデータプレーンサービスを提供するように構成された第一のｖＣｏｒｅと、
（ｃ）インターネットプロトコル詳細記録に好適なデータをメッセージングサービスに提供する、前記第一のｖＣｏｒｅと、
（ｄ）前記データを前記メッセージングサービスから受信し、インターネットプロトコル詳細記録データをインターネットプロトコル詳細記録コレクタに提供する、インターネットプロトコル詳細記録エクスポータと、を備える、インターネットプロトコル詳細記録データ取得システム。
【請求項2】
前記インターネットプロトコル詳細記録データが、データオブジェクトである、請求項１に記載のシステム。
【請求項3】
前記メッセージングサービスが、ストリーム処理サービスである、請求項１に記載のシステム。
【請求項4】
前記メッセージングサービスが、異なるタイプのデータを一緒に異なるトピックにグループ化する、請求項１に記載のシステム。
【請求項5】
前記トピックのうちの少なくとも二つが、重複しないタイプのデータを有する、請求項４に記載のシステム。
【請求項6】
前記インターネットプロトコル詳細記録エクスポータが、ＩＰＤＲ／ＳＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎに準拠するデータを提供する、請求項１に記載のシステム。
【請求項7】
前記インターネットプロトコル詳細記録コレクタが、前記第一のｖＣｏｒｅに信号送信し、インターネットプロトコル詳細記録に好適なデータを提供する、請求項１に記載のシステム。
【請求項8】
前記信号が、ＳＮＭＰプロトコルに基づく、請求項７に記載のシステム。
【請求項9】
インターネットプロトコル詳細記録データ取得システムであって、（ａ）受信したデータを複数の第一の顧客デバイス用の同軸ケーブルに提供するのに好適なアナログデータに変換するリモートファイバノードを含む伝送ネットワークを通して前記複数の第一の顧客デバイスにデータサービスを提供する、仮想化ケーブルモデル終端システム（ＣＭＴＳ）であって、前記ヘッドエンドが、そのそれぞれがそれぞれのプロセッサを含む少なくとも一つのサーバを含む、仮想化ケーブルモデル終端システム（ＣＭＴＳ）と、
（ｂ）前記ヘッドエンドの前記サーバのうちの一つにインスタンス化された、前記伝送ネットワークを通して前記複数の第一の顧客デバイスにデータプレーンサービスを提供するように構成された第一の仮想化ケーブルモデム終端システムと、
（ｃ）インターネットプロトコル詳細記録に好適なデータをメッセージングサービスに提供する、前記第一の仮想化ケーブルモデム終端システムと、
（ｄ）前記データを前記メッセージングサービスから受信し、インターネットプロトコル詳細記録データをインターネットプロトコル詳細記録コレクタに提供する、インターネットプロトコル詳細記録エクスポータと、を備える、インターネットプロトコル詳細記録データ取得システム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、２０２１年１月２１日に出願された米国仮特許出願第６３／１３９，９４１号の利益を主張する。
本出願は、２０２１年１月２１日に出願された米国仮特許出願第６３／１３９，９４１号の利益を主張する。
【0002】
本出願の主題は、ｖＣｏｒｅのためのＩＰＤＲ通信システムに関する。
【背景技術】
【0003】
ケーブルテレビジョン（ＣＡＴＶ）サービスは、一般的に「ヘッドエンド」と称される、中央配信ユニットから大勢の顧客（例えば、加入者）にコンテンツを提供し、ヘッドエンドは、関連するコンポーネント（ノード、増幅器、及びタップ）を含む、ハイブリッドファイバ同軸（ＨＦＣ）ケーブルプラントを含む、アクセスネットワークを通して、この中央配信ユニットからその顧客にコンテンツのチャネルを分配する。しかしながら、現代のケーブルテレビジョン（ＣＡＴＶ）サービスネットワークは、テレビチャネル及び音楽チャネルなどのメディアコンテンツを顧客に提供するだけでなく、インターネットサービス、ビデオオンデマンド、ＶｏＩＰなどの電話サービス、ホームオートメーション／セキュリティなどのデジタル通信サービスのホストも提供する。これらのデジタル通信サービスは、順次、ヘッドエンドからダウンストリーム方向に、ＨＦＣを通して、典型的にはブランチネットワークを形成しながら、顧客への通信を要求するだけでなく、アップストリーム方向に、典型的にはＨＦＣネットワークを通して、加入者からヘッドエンドへの通信も要求する。
【0004】
この目的のために、ＣＡＴＶヘッドエンドは、従来、ケーブルインターネット、ボイスオーバーインターネットプロトコルなどの高速データサービスをケーブル顧客に提供するために使用される別個のケーブルモデム終端システム（ＣＭＴＳ）、並びにブロードキャストビデオ及びビデオオンデマンド（ＶＯＤ）などのビデオサービスを提供するために使用されるビデオヘッドエンドシステムを含んでいた。典型的には、ＣＭＴＳは、インターネットから着信するトラフィックを、イーサネットインターフェースを通して、ＣＭＴＳを通して、次いで、ケーブル会社のハイブリッドファイバ同軸（ＨＦＣ）システムに接続されているＲＦインターフェース上にルーティング（又はブリッジ）することができるように、イーサネットインターフェース（又は他のより伝統的な高速データインターフェース）並びに無線周波数（ＲＦ）インターフェースの両方を含むであろう。ダウンストリームトラフィックが、ＣＭＴＳから顧客の家庭内のケーブルモデム及び／又はセットトップボックスに配信される一方で、アップストリームトラフィックは、顧客の家庭内のケーブルモデム及び／又はセットトップボックスからＣＭＴＳに配信される。ビデオヘッドエンドシステムは、同様に、セットトップ、ビデオ復号化カード付きＴＶ、又は着信暗号化ビデオサービスを復調及び復号化することが可能な他のデバイスのいずれかにビデオを提供する。多くの現代のＣＡＴＶシステムは、ＣＭＴＳの機能を、統合ＣＭＴＳ（例えば、統合集中型ケーブルアクセスプラットフォーム（ＣＣＡＰ））と一般的に称される単一のプラットフォーム内のビデオ配信システム（例えば、ＥｄｇｅＱＡＭ－直交振幅変調）と組み合わせており、ビデオサービスが、作成され、Ｉ－ＣＣＡＰに提供され、次いで、Ｉ－ＣＣＡＰがビデオを適切な周波数上にＱＡＭ変調する。分散ＣＭＴＳ（例えば、分散集中型ケーブルアクセスプラットフォーム）と一般的に称される更に他の現代のＣＡＴＶシステムには、従来の統合ＣＣＡＰの物理層（ＰＨＹ）をネットワークのファイバノードにプッシュすることによってそれを再配置するリモートＰＨＹ（又はＲ－ＰＨＹ）が含まれ得る（Ｒ－ＭＡＣ ＰＨＹは、ＭＡＣ及びＰＨＹの両方をネットワークのノードに再配置する）。したがって、ＣＣＡＰプラットフォーム内のコアが、上位層処理を実施する一方で、リモートノード内のＲ－ＰＨＹデバイスは、コアから送信されたダウンストリームデータを、無線周波数上でケーブルモデム及び／又はセットトップボックスに伝送されるようにデジタルからアナログに変換し、ケーブルモデム及び／又はセットトップボックスから送信されたアップストリーム無線周波数データを、コアに光学的に伝送されるようにアナログからデジタル形式に変換する。
【図面の簡単な説明】
【0005】
本発明をより良く理解するために、またどのように本発明が実施され得るかを示すために、ここで、一例として、以下の添付図面を参照する。
【発明を実施するための形態】
【0006】
図１を参照すると、統合ＣＭＴＳシステム（例えば、統合集中型ケーブルアクセスプラットフォーム（ＣＣＡＰ））１００は、典型的にはパケット化されたデータの形態でインターネット（又は他のネットワーク）上で送信及び受信されるデータ１１０を含み得る。統合ＣＭＴＳ１００はまた、典型的にはオペレータビデオアグリゲーションシステムからパケット化されたデータの形態でダウンストリームビデオ１２０を受信し得る。一例として、ブロードキャストビデオは、典型的には衛星配信システムから取得され、ＣＣＡＰ又はビデオヘッドエンドシステムを通した加入者への配信のために前処理される。統合ＣＭＴＳ１００は、受信されたデータ１１０及びダウンストリームビデオ１２０を受信及び処理する。ＣＭＴＳ１３０は、増幅器及びスプリッタなどの他のデバイスを含み得るＲＦ分配ネットワークを通して、ダウンストリームデータ１４０及びダウンストリームビデオ１５０を顧客のケーブルモデム及び／又はセットトップボックス１６０に伝送し得る。ＣＭＴＳ１３０は、増幅器及びスプリッタなどの他のデバイスを含み得るネットワークを通して、顧客のケーブルモデム及び／又はセットトップボックス１６０からアップストリームデータ１７０を受信し得る。ＣＭＴＳ１３０は、その所望の能力を達成するために、複数のデバイスを含んでもよい。
【0007】
図２を参照すると、増加する帯域幅の需要、統合ＣＭＴＳのための限定された設備空間、及び電力消費の考慮事項の結果として、分散ケーブルモデム終端システム（Ｄ－ＣＭＴＳ）２００（例えば、分散集中型ケーブルアクセスプラットフォーム（ＣＣＡＰ））を含むことが望ましい。一般に、ＣＭＴＳが、データサービスに焦点を合わせている一方で、ＣＣＡＰは、ブロードキャストビデオサービスを更に含む。Ｄ－ＣＭＴＳ２００は、ネットワークパケット化データを使用して、Ｉ－ＣＭＴＳ１００の機能の一部をファイバノードなどの遠隔場所にダウンストリームに分配する。例示的Ｄ－ＣＭＴＳ２００は、リモートＰＨＹアーキテクチャを含んでもよく、リモートＰＨＹ（Ｒ－ＰＨＹ）は、好ましくは、ファイバ及び同軸の接合部に位置する光学ノードデバイスである。一般に、Ｒ－ＰＨＹは、多くの場合、システムの一部のＰＨＹ層を含む。Ｄ－ＣＭＴＳ２００は、典型的にはパケット化されたデータの形態でインターネット（又は他のネットワーク）上で送信及び受信されるデータ２１０を含む、Ｄ－ＣＭＴＳ２３０（例えば、コア）を含んでもよい。Ｄ－ＣＭＴＳ２００はまた、典型的にはオペレータビデオアグリゲーションシステムからパケット化されたデータの形態でダウンストリームビデオ２２０を受信し得る。Ｄ－ＣＭＴＳ２３０は、受信されたデータ２１０及びダウンストリームビデオ２２０を受信及び処理する。リモートファイバノード２８０は、好ましくは、リモートＰＨＹデバイス２９０を含む。リモートＰＨＹデバイス２９０は、増幅器及びスプリッタなどの他のデバイスを含み得るネットワークを通して、ダウンストリームデータ２４０及びダウンストリームビデオ２５０を顧客のケーブルモデム及び／又はセットトップボックス２６０に伝送し得る。リモートＰＨＹデバイス２９０は、増幅器及びスプリッタなどの他のデバイスを含み得るネットワークを通して、顧客のケーブルモデム及び／又はセットトップボックス２６０からアップストリームデータ２７０を受信し得る。リモートＰＨＹデバイス２９０は、その所望の能力を達成するために、複数のデバイスを含んでもよい。リモートＰＨＹデバイス２９０は、主に、ダウンストリームＱＡＭ変調器、アップストリームＱＡＭ復調器などのＰＨＹ関連回路を、ネットワークパケット化データを使用してＤ－ＣＭＴＳ２３０に接続する疑似ワイヤ論理とともに含む。リモートＰＨＹデバイス２９０及びＤ－ＣＭＴＳ２３０は、ダウンストリームデータ、ダウンストリームビデオ、及びアップストリームデータ２９５などのデータ及び／又はビデオ相互接続を含み得る。いくつかの実施形態では、ビデオトラフィックは、リモート物理デバイスに直接進み、それによって、Ｄ－ＣＭＴＳ２３０を迂回し得ることに留意されたい。場合によっては、リモートＰＨＹ及び／又はリモートＭＡＣ ＰＨＹ機能が、ヘッドエンドにおいて提供され得る。
【0008】
一例として、リモートＰＨＹデバイス２９０は、ダウンストリームＤＯＣＳＩＳ（すなわち、Ｄａｔａ Ｏｖｅｒ Ｃａｂｌｅ Ｓｅｒｖｉｃｅ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）データ（例えば、各々が参照によりそれらの全体で本明細書に組み込まれる、ＤＯＣＳＩＳ １．０、１．１、２．０、３．０、３．１、及び４．０）、ビデオデータ、Ｄ－ＣＭＴＳ２３０から受信された帯域外信号を、ＲＦ又はアナログ光学系上の伝送のためにアナログに変換し得る。一例として、リモートＰＨＹデバイス２９０は、アップストリームＤＯＣＳＩＳ、及びＲＦ又は線形光学系などのアナログ媒体から受信された帯域外信号を、Ｄ－ＣＭＴＳ２３０への送信のためにデジタルに変換し得る。観察され得るように、特定の構成に応じて、Ｒ－ＰＨＹは、ＤＯＣＳＩＳ ＭＡＣ及び／又はＰＨＹ層の全て又は一部をファイバノードまで移動させ得る。
【0009】
Ｉ－ＣＭＴＳデバイスは、通常、一連のスロットを含む単一のシャーシで構成されるカスタムビルドのハードウェアデバイスであり、その各々が、プロセッサ、メモリ、及びそれら上でサポートされるその他のコンピューティング及びネットワーキング機能を持つそれぞれのラインカードを受け取る。ラインカードの各々には、同じハードウェア構成、処理能力、及びソフトウェアが含まれる。ラインカードの各々は、ＭＡＣ及びＰＨＹ機能を含むＩ－ＣＭＴＳデバイスの機能を実行する。システムは、追加の顧客をサポートするよう拡張されるにつれ、追加のラインカードがシステムに含まれて、システムの処理能力を拡張する。残念なことに、特定のネットワークの需要を満たすために、リアルタイムでラインカードの数を動的に拡大することは問題である。
【0010】
マイクロプロセッサベースの商用オフザシェルフ（ＣＯＴＳ）サーバプラットフォームの計算能力は増加しており、一方、このようなシステムの費用は時間の経過とともに減少している。こうしたシステムを用いて、コンピューティングシステムは、所望の場合、一つ以上のＣＯＴＳサーバを使用して仮想化され、操作されてもよく、概して、本明細書では仮想マシンと称される。ＣＯＴＳサーバ及び／又は仮想マシン上で動作するコンテナ技術を使用して、ＣＯＴＳサーバは、単一のオペレーティングシステムのみで動作し得る。次に、仮想化アプリケーションの各々は、ソフトウェアコンテナを使用して分離されてもよく、その結果、仮想化アプリケーションは、同じマシン上で動作している他の仮想化アプリケーションを見ず、認識しない場合がある。典型的には、各ＣＯＴＳサーバは、オペレーティングシステムソフトウェアを実行する関連するメモリ及びネットワーキング能力を有する、一つ以上のＩｎｔｅｌ／ＡＭＤプロセッサ（又は他の処理デバイス）を含む。典型的には、ＣＯＴＳサーバは、フレームワーク及びオペレーティングシステムを含み、ここで、ユーザアプリケーションは、このようなフレームワーク上で実行され、オペレーティングシステムは、実際のオペレーティングシステムから離れて抽象化される。各仮想マシンは、ＣＯＴＳサーバ上で動作する一つ以上のソフトウェアアプリケーションとしてインスタンス化され、運用されてもよい。複数のソフトウェアコンテナは、インスタンス化され、同じＣＯＴＳサーバ及び／又は同じ仮想マシン上で動作されてもよい。複数のＣＯＴＳサーバは、典型的には、一つ以上のデータセンタに含まれ、その各々が互いに通信している。複数のＣＯＴＳサーバは、地理的冗長性を提供するために、異なる地理的領域に位置し得る。一部の実施形態では、コンテナは仮想マシンと同じ機能を含んでもよく、又はその逆でもよい。いくつかの実施形態では、一般にポッドと呼ばれるコンテナ化構成要素のグループ化は、仮想マシンの形態であってもよい。
【0011】
いくつかの実施形態では、ＣＯＴＳサーバは、典型的には、その上にドライバ及びコンテナオーケストレーションシステムの一部とともにオペレーティングシステムを含む「ベアメタル」サーバであってもよい。次いで、コンテナオーケストレーションシステムによって管理されている間に、一つ以上のコンテナが「ベアメタル」サーバに追加される。本明細書に記載されるコンテナオーケストレーションシステムは、同様に、所望に応じて、仮想マシンオーケストレーションシステムとして実行されても、また称されてもよい。いくつかの実施形態では、「ベアメタル」サーバは、ドライバ及びンテナオーケストレーションシステムとともにオペレーティングシステム上で実行されるコンテナで使用されてもよい。いくつかの実施形態では、仮想マシンは、ＣＯＴＳサーバから省略されてもよい。
【0012】
ラインカード及び／又はリモートＰＨＹデバイスに含まれる選択されたソフトウェアプロセスは、ソフトウェアコンテナを含み、ＣＯＴＳサーバ上で実行され、「アクティブ」及び「バックアップ」ソフトウェアプロセスの両方を含む、「ベアメタル」サーバ及び／又は仮想マシン上で実行されてもよい。こうした「ベアメタル」サーバ及び／又は仮想マシンによって提供される機能は、例えば、ルーティングインターネットパケットプロビジョニングを含むパケット処理、疑似ワイヤを介して動作するレイヤー２仮想プライベートネットワーキング、及びマルチプロトコルラベルスイッチングルーティングなどの、より高いレベルの機能を含み得る。こうした「ベアメタル」サーバ及び／又は仮想マシンによって提供される機能は、例えば、ＤＯＣＳＩＳ ＭＡＣ及びカプセル化、チャネルプロビジョニング、サービスフロー管理、サービス品質及びレート制限、スケジューリング、及び暗号化などのＤＯＣＳＩＳ機能を含み得る。こうした「ベアメタル」サーバ及び／又は仮想マシンによって提供される機能は、例えば、ＥＱＡＭ及びＭＰＥＧ処理などのビデオ処理を含み得る。
【0013】
ＣＯＴＳサーバ及び／又は仮想マシン及び／又はソフトウェアコンテナの各々は、異なるハードウェアプロファイル及び／又はフレームワークを含み得る。例えば、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はソフトウェアコンテナの各々は、異なるプロセッサタイプ、プロセッサ当たりの異なる処理コア数、各プロセッサタイプについての異なるメモリ量、処理コア当たりの異なるメモリ量、異なる暗号化機能、利用可能なオフプロセッサメモリの異なる量、異なるメモリ帯域幅（ＤＤＲ）速度、イーサネットカードなどの、ネットワークインターフェースの多様なタイプ及び能力で実行され得る。このように、異なるＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はソフトウェアコンテナは、特定のハードウェアに応じて異なる、異なる処理能力を有し得る。ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はソフトウェアコンテナの各々は、異なるソフトウェアプロファイルを含み得る。例えば、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はソフトウェアコンテナの各々は、異なるソフトウェアオペレーティングシステム及び／又はそれを実行する他のサービスを含んでもよく、概して本明細書ではフレームワークと称される。このように、異なるＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はソフトウェアコンテナは、特定のソフトウェアプロファイルに応じて変化する異なるソフトウェア処理能力を有し得る。
【0014】
図３を参照すると、データ処理及びネットワークを介したデータの転送のために、ハードウェア及び／又はソフトウェアのアーキテクチャは、複数の異なるプレーンの形態で構成されてもよく、その各々が、異なる機能のセットを実行する。関連する部分では、層状アーキテクチャは、管理プレーン３００、制御プレーン３１０、データプレーン３２０、及びスイッチファブリック３３０などの異なるプレーンを含み得、データのパケットの送受信を実施することができる。
【0015】
例えば、管理プレーン３００は、概して、ユーザ相互作用、又はそうでなければ実行される一般的なソフトウェアアプリケーションとみなされ得る。管理プレーンは通常、ネットワークスタックのすべての層及びシステムの他の部分に提供される管理及び構成を構成、監視、及び提供する。
【0016】
例えば、制御プレーン３１０は、多くの場合、システム構成、管理、及びルーティングテーブル情報及び転送情報の交換を含む、スイッチング機能に対するコンポーネントである。典型的には、ルーティングテーブル情報の交換は比較的まれに実施される。制御プレーン３１０の経路コントローラは、トポロジー情報を他のスイッチと交換し、ルーティングプロトコルに基づいてルーティングテーブルを構築する。制御プレーンはまた、フォワーディングエンジン用のフォワーディングテーブルを作成してもよい。概して、制御プレーンは、トラフィックがどこに送信されるかを決定する層として考えられ得る。制御機能は、到着する個々のパケットごとに実行されないため、厳密な速度制約を持たない傾向がある。
【0017】
例えば、データプレーン３２０は、スイッチング用のパケットヘッダを解析し、サービス品質、フィルタリング、媒体アクセス制御、カプセル化、及び／又はキューイングを管理する。一般的な問題として、データプレーンはデータトラフィックを伝送するが、これはケーブル分配ネットワークの場合に相当し得る。概して、データプレーンは、スイッチファブリックを通して、制御プレーンロジックに従って、選択された宛先への経路に沿って、トラフィックを次のホップに主に転送する層として考えられ得る。データプレーンは、到着する個々のパケットごとに機能を実行するため、速度の制約が厳しい傾向がある。
【0018】
例えば、スイッチファブリック３３０は、一つ以上のネットワークスイッチを介してネットワークノードを相互接続するネットワークトポロジーを提供する。
【0019】
システムが、追加の顧客をサポートするように拡張するにつれ、追加のＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はソフトウェアコンテナがシステムに含まれ、システム全体の処理能力が拡張される。処理の冗長性を提供するために、障害イベントの検出時に「アクティブ」プロセスと交換される「バックアップ」として割り当てられている、一つ以上の追加のＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はソフトウェアコンテナが含まれ得る。ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はソフトウェアコンテナ上のデータプレーン３２０のスケーリングは、動的に変動する処理要件をサービスするために、データパケットの十分な高速処理及びデータパケットの送信に十分な帯域幅を確保して、そうでなければ失われないようにする方法で実施されなければならない。
【0020】
データプレーン、特に、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ上のリモートＰＨＹ機能の一部を仮想化することが望ましい。このようにして、ケーブル分配システム用のＭＡＣコアは、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ上で実行され得る。本明細書で参照することにより、仮想リモートＰＨＹ ＭＡＣコアは、本明細書ではｖＣｏｒｅインスタンスと称され得る。
【0021】
図４を参照すると、概してコンテナ４１０と称される、ソフトウェアをパッケージで配信するために、オペレーティングシステムレベルの仮想化を使用するサービスとしてプラットフォームを組み込むことが望ましい。コンテナの各々は互いに分離され、独自のソフトウェア、ライブラリ、及び構成ファイルをバンドルする。コンテナは、画定されたチャネルを使用して互いに通信してもよい。一般的な事柄として、一つ以上のアプリケーション及びその依存性は、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン上で実行できる仮想コンテナにパックされ得る。このコンテナ化は、オンプレミスのＣＯＴＳサーバ、「ベアメタル」サーバ、パブリッククラウドＣＯＴＳサーバ、プライベートクラウドＣＯＴＳサーバ、又はその他の方法でアプリケーションを実行する際の柔軟性とポータビリティを向上させる。各コンテナが比較的軽量である場合、単一のＣＯＴＳサーバ及び／又は「ベアメタル」サーバ、及び／又はＣＯＴＳサーバ及び／又は「ベアメタル」サーバ上で動作する仮想マシンは、複数のコンテナを同時に実行し得る。さらに、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ、及び／又は仮想マシン及び／又はコンテナは、ケーブル分配システム内で分配されてもよい。
【0022】
ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシンは、一つ以上のＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシンにわたって、コンテナ４１０のアプリケーション展開、スケーリング、及び管理を自動化するためのコンテナオーケストレーションシステム４２０を含み得る。コンテナオーケストレーションシステム４２０を実行するコンピューティングデバイスは、データプレーンアプリケーションのためのコンテナを提供するコンピューティングデバイスと分離していることが好ましい。理解されるように、図４に図示した仮想マシンでは、ＣＯＴＳ Ｂなどが、省略され得る。アプリケーションの展開、スケーリング、及びコンテナの管理は、複数のＣＯＴＳサーバなど、複数のホストにわたるクラスタを含み得る。コンテナの展開、維持、及びスケーリングは、例えば、異なるプロセッサタイプ、プロセッサ当たりの異なる処理コア数、各プロセッサタイプについての異なるメモリ量、処理コア当たりの異なるメモリ量、利用可能なオフプロセッサメモリの異なる量、異なるメモリ帯域幅（ＤＤＲ）速度、異なるフレームワーク、及び／又はイーサネットカードなどの、ネットワークインターフェースの多様なタイプ及び能力などの、基礎となるシステム能力の特徴に基づき得る。さらにコンテナオーケストレーションシステム４２０が、特定のプロセッサタイプ、選択されたプロセッサ数（例えば、１つ以上）、選択されたプロセッサ当たりの特定の数の処理コア、各プロセッサタイプについて選択されたメモリ量、処理コア当たりの選択されたメモリ量、利用可能なオフプロセッサメモリの選択された量、選択されたフレームワーク、及び／又はイーサネットカードなどの、ネットワークインターフェースの選択された量及び／又はタイプなどの、基礎となるシステム能力の異なる量を割り当ててもよい。コンテナオーケストレーションシステム４２０についての対応するエージェントは、各ＣＯＴＳサーバ（例えば、ＣＯＴＳ Ａ及び／又はＣＯＴＳ Ｂ）に含まれ得る。
【0023】
コンテナオーケストレーションシステム４２０は、概してポッド４３０と呼ばれる、コンテナ化された構成要素のグループ化を含み得る。ポッドは、同じＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は同じ仮想マシン上に共存する一つ以上のコンテナから構成され、コンテナは、同じＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は同じ仮想マシンのリソースを共有することができる。各ポッド４３０は、クラスタ内で固有のポッドＩＰアドレスが好ましくは割り当てられ、これにより、アプリケーションは競合のリスクなしにポートを使用できる。ポッド４３０内では、コンテナの各々は、ローカルホスト又は他のアドレッシングサービスに基づいて互いに参照してもよいが、一つのポッド内のコンテナは、別のポッド内の別のコンテナを直接アドレッシングする方法を有さないことが好ましく、そのため、ポッドのＩＰアドレス又は他のアドレッシングサービスを使用することが好ましい。
【0024】
従来のＤ－ＣＭＴＳ ＲＰＨＹコアは、データパケットの転送タイミングの確保など、望ましい性能特性を達成するために、ソフトウェア及びハードウェアの両方を含む専用構築型アプライアンスとして実装されてもよい。専用構築型アプライアンスは、その特性が固定されているため、自動導入や自動スケーリングには対応していない。専用構築型アプライアンスとは対照的に、ｖＣｏｒｅインスタンスは、Ｌｉｎｕｘ（登録商標）などのオペレーティングシステム上のＣＯＴＳサーバ及び／又は「ベアメタル」サーバ上で動作するソフトウェアに実装されることが好ましい。ｖＣｏｒｅインスタンスは、ライフサイクル管理、柔軟なスケーリング、健全性監視、テレメトリなどの自動化技法を容易に促進するような方法で実装されることが好ましい。残念なことに、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ上でｖＣｏｒｅインスタンスを実行すると、主にデータプレーンコンポーネントに関連するいくつかの課題が生じる傾向がある。主な課題の一つは、ケーブルデータ配信環境のリアルタイム特性を達成するために、タイムリーかつ効果的な方法でデータがネットワークに確実に提供されるようにすることである。ケーブルデータ配信環境は、データパケット配信のタイミングに対するリアルタイム制約を含み、これは典型的なウェブベースの環境又はデータベース環境には存在しない。
【0025】
各ｖＣｏｒｅインスタンスは、好ましくは、コンテナ内に実装され、各コンテナのサイズ（例えば、スケール、メモリ、ＣＰＵ、割り当てなど）は、特定のｖＣｏｒｅインスタンスに割り当てられるサーバハードウェア及びソフトウェアリソースの量に変換される。各特定のｖＣｏｒｅインスタンスに割り当てられるサーバハードウェア及びソフトウェアリソースの量は、好ましくは、ｖＣｏｒｅインスタンスが容易にＲＰＨＹ ＭＡＣ Ｃｏｒｅサービスを提供できる顧客（例えば、サービスグループ）のグループ数及び／又は顧客数の関数である。例えば、限られた量のサーバハードウェア及びソフトウェアリソースが、限られた数の顧客及び／又は顧客のグループを有する特定のｖＣｏｒｅインスタンスに割り当てられてもよい。例えば、実質的な量のサーバハードウェアおｙ補備ソフトウェアリソースが、実質的な顧客のグループ及び／又は顧客の数を有する特定のｖＣｏｒｅインスタンスに割り当てられてもよい。例えば、選択されたサーバハードウェアリソースは、各ｖＣｏｒｅインスタンスが専用かつ予測可能な量のサーバハードウェアリソースを持つように、重複しない方法で異なるｖＣｏｒｅインスタンス間に割り当てられることが好ましい。例えば、選択されたソフトウェアリソースは、各ｖＣｏｒｅインスタンスが専用かつ予測可能な量のソフトウェアリソースを有するように、重複しない方法で異なるｖＣｏｒｅインスタンス間に割り当てられることが好ましい。一例として、単一のｖＣｏｒｅは、４つのコンテナ、すなわち、（１）ｖＣｏｒｅ管理コンテナ、（２）データプレーンコンテナ、（３）制御プレーンコンテナ、及び（４）ｖＣｏｒｅ初期化コンテナを含むＫｕｂｅｒｎｅｔｅｓポッドであってもよい。
【0026】
例えば、各ｖＣｏｒｅインスタンス（Ｃｃ）に割り当てられることが好ましいＣＰＵコアの数は、そのｖＣｏｒｅインスタンスを通して接続されるＵＳＳＧ（アップストリームサービスグループ－顧客モデム及び／又はセットトップボックスのグループ）の合計、及びＤＳＳＧ（ダウンストリームサービスグループ－顧客モデム及び／又はセットトップボックスのグループ）の合計（ＤＳｓｇ）の関数であってもよい。これは、ｖＣｏｒｅ：Ｃｃ＝ｆ１（ＵＳｓｇ，ＤＳｓｇ）として表され得る。同様に、その他のハードウェア及び／又はソフトウェアの特性を、所望に応じて割り当ててもよい。
【0027】
例えば、各ｖＣｏｒｅインスタンス（Ｃｂｗ）に割り当てられるネットワーク容量は、そのｖＣｏｒｅインスタンスに接続された総ＵＳＳＧ（アップストリームサービスグループ－顧客モデム及び／又はセットトップボックスのグループ）（ＵＳｓｇ）及び総ＤＳＳＧ（ダウンストリームサービスグループ－顧客モデム及び／又はセットトップボックスのグループ）（ＤＳｓｇ）の関数であってもよい。これは、Ｃｂｗ＝ｆ２（ＵＳｓｇ，ＤＳｓｇ）として表され得る。同様に、その他のハードウェア及び／又はソフトウェアの特性を、所望に応じて割り当ててもよい。
【0028】
ｖＣｏｒｅインスタンスのスケーリングは、特定のセットのリモート物理デバイス及び／又はサービスグループ（例えば、ケーブル顧客のセット）及び／又はケーブル顧客に対応するように適切にサイズ調整された、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン上のコンテナ内にｖＣｏｒｅインスタンスを自動的に作成及び導入する機能を指し得る。ｖＣｏｒｅインスタンスのスケーリングは、いくつかの場合、変更された特定のセットのリモート物理デバイス及び／又はサービスグループ（例えば、ケーブル顧客のセット）及び／又はケーブル顧客に対応するように適切なサイズにされた、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン上のＰＯＤ内に既存のｖＣｏｒｅインスタンスのハードウェア及び／又はソフトウェアの特性を自動的に変更する能力を含み得る。
【0029】
リソース割り当てマネージャ４７０は、適切な量のハードウェア及びソフトウェアを、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバリソースを、それぞれの特定のｖＣｏｒｅインスタンス（例えば、ＣＰＵコア、及び／又はメモリ、及び／又はネットワーク容量）に割り当てるか、又は再割り当てし得る。こうしたＣＯＴＳサーバ及び／又は「ベアメタル」サーバハードウェア及びソフトウェアリソースの量は、各ｖＣｏｒｅインスタンスに割り当てられるか、又は再配分される、そのスケールの機能であり、また様々な他のリソース配分などの他の機能であってもよい。リソース割り当てマネージャ４７０に対応するエージェントは、各ＣＯＴＳサーバ（例えば、ＣＯＴＳ Ａ、ＣＯＴＳ Ｂ）に含まれ得る。
【0030】
ｖＣｏｒｅインスタンスは、データパケット及びデータプレーンの他の機能の転送のためのデータプレーンソフトウェアを含む。データプレーンソフトウェアは、データプレーン用のデータパケットを管理するために使用される、データプレーンライブラリ及びネットワークインターフェースコントローラ（ＮＩＣ）ドライバのセットを含み得る。好ましくは、データプレーンソフトウェアは、典型的なネットワーク処理ソフトウェアのようなカーネル空間とは対照的に、ユーザ空間で動作するため、オペレーティングシステムカーネル及びコンテナ管理ネットワークドライバ及びプラグインを使用しない。例えば、データプレーンソフトウェアは、キューマネージャ、バッファマネージャ、メモリマネージャ、及び／又はパケット処理のためのパケットフレームワークを含み得る。データプレーンソフトウェアは、カーネルから分離されたＣＰＵコアを使用してもよく、すなわち、オペレーティングシステムがスケジュール設定したプロセスがこれらの分離されたＣＰＵコア上で実行されていないことを意味する。データプレーンソフトウェアとオペレーティングシステムソフトウェアとの間のＣＰＵコアの分離は、オペレーティングシステムソフトウェアによって実行されるタスクが、データパケットを適時に処理しているデータプレーンソフトウェアに干渉しないことを保証する。さらに、データプレーンソフトウェアとオペレーティングシステムソフトウェアとの間のＣＰＵコアの分離により、同じ物理中央処理ユニットの同じ物理中央処理ユニットを、異なるコアであっても使用することが可能になる。加えて、他のハードウェア及び／又はソフトウェア能力は、同様に、例えば、選択されたプロセッサ（例えば、１つ以上）、選択されたプロセッサ当たりの特定の数の処理コア、各プロセッサタイプについて選択されたメモリ量、処理コア当たりの選択されたメモリ量、利用可能なオフプロセッサメモリの選択された量、選択されたフレームワーク、及び／又は選択された量及び／又はネットワークインターフェースなどに、分離されてもよい。
【0031】
また、各ｖＣｏｒｅインスタンスには、他のｖＣｏｒｅインスタンス及びオペレーティングシステムソフトウェアとは別に、専用のネットワーク帯域幅機能を持つことが望ましい。ｖＣｏｒｅインスタンスに専用のネットワーク帯域幅を提供するために、物理ネットワークインターフェースカードは、複数の異なるソフトウェアアプリケーションが、それぞれが利用可能な帯域幅保証量を有する同じネットワークインターフェースカードを利用することができるように、仮想化されてもよい。ネットワークインターフェースカードは、単一のルート入出力仮想化技術（ＳＲ－ＩＯＶ）を使用して仮想化されることが好ましい。ＳＲ－ＩＯＶは、ＮＩＣの物理機能（例えば、ＰＦ）を一つ以上の仮想機能（ＶＦ）に分割する。ＰＦとＶＦの能力は概して異なる。概して、ＰＦはキュー、説明、オフロード、ハードウェアロック、ハードウェアリンク制御などをサポートする。概して、ＶＦは、キュー及び記述子に基づくネットワーキング機能をサポートする。
【0032】
ｖＣｏｒｅインスタンスの自動作成、展開、及び削除は、コンテナオーケストレーションシステム４２０によって行われてもよい。
【0033】
図５を参照すると、ｖＣｏｒｅインスタンス５３０は、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ５００上で動作し、通常は同じハブ内に位置する、統合相互接続ネットワークを介して接続される一つ以上のリモート物理デバイス用のリモートＰＨＹ ＭＡＣコアとして機能することができる。ｖＣｏｒｅインスタンス５３０は、データプレーンソフトウェア５３２を含み得る。ｖＣｏｒｅインスタンス５３０の各々は、概してＰＯＤと呼ばれる。ＣＯＴＳサーバ５００は、インターネット５６０、ネットワーキングスイッチ５７０のセットと、リモート物理デバイス５８０、及び顧客５９０と通信してもよい。その上で動作するｖＣｏｒｅインスタンスを含むＣＯＴＳサーバ及び／又は「ベアメタル」サーバは、通常、以下の特徴のうちの一つ以上を有する比較的高性能のサーバである。
【0034】
ハードウェア：
【0035】
少なくとも一つの管理ＮＩＣ５１０は、通常、別の管理ネットワーク５１２に接続される。管理ＮＩＣ５１０は主に、データトラックも管理し得る、サーバアプリケーションのオーケストレーション及び管理のために使用される。
【0036】
好ましくは、データパケットのハードウェアタイムスタンプ機能のために、ＳＲ－ＩＯＶ及びＰＴＰ（ＩＥＥＥ １５８８）５２２とともに、少なくとも二つの（冗長性のための）データプレーンＮＩＣ５１４（すなわち、データプレーン物理ネットワークインターフェース）が含まれる。データプレーンＮＩＣ５１４は、リモート物理デバイス及び顧客のモデムへの接続性を提供する、及び／又はこうしたリモート物理デバイスの背後にあるセットトップボックス／消費者施設設備を提供するために使用される。ｖＣｏｒｅインスタンス５３０はそれぞれ、データプレーンＮＩＣ５１４のそれぞれに対する仮想機能５３４ネットワークインターフェースを含み得る。
【0037】
さらに、ハードウェアは、ＤＥＳ暗号化用の専用デバイスを含んでもよい。
【0038】
ソフトウェア：
【0039】
ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ上のオペレーティングシステムは、Ｕｂｕｎｔｕ、ＲｅｄｈａｔなどのＬＩＮＵＸ（登録商標） ＯＳであることが好ましい。
【0040】
ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシンは、コンテナソフトウェアを含む。
【0041】
ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はその他のサーバは、少なくとも、コンテナオーケストレーションシステムの一部を含む。
【0042】
ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はその他のサーバは、少なくとも部分的に、例えば、ＣＰＵコア、メモリ、ＶＦ、ＭＡＣアドレスなどを含む、ｖＣｏｒｅインスタンスについてのソフトウェア及び／又はハードウェアリソースのサーバ割り当てを管理する、リソース割り当てマネージャ（ＲＡＭ）５２０を含む。ＲＡＭ５２０はまた、ＯＳ構成、ドライバサポートなど、診断及び健全性監視を含む、サーバ構成を提供し得る。ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又はその他のサーバは、少なくとも部分的に、ｖＣｏｒｅ（例えば、コンテナ及び／又はポッド）の管理を管理するオーケストレーションアプリケーション５４０を含み得る。
【0043】
ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又はその他のサーバは、システム全体のグランドマスタークロックに基づいて、ＣＯＴＳサーバ及び／又は「ベアメタル」サーバ及び／又は仮想マシン及び／又はｖＣｏｒｅインスタンス５２０のシステムクロックを同期化するＰＴＰアプリケーション５２２を実行し得る。精度向上のために、ＰＴＰアプリケーション５２２は、好ましくは、ハードウェアのタイムスタンピング及びＮＩＣ５１４上に存在する正確なハードウェアクロックに基づく。
【0044】
コンテナの初期化及びリソースの割り当ては、分散された様式で行われてもよい。初期ｖＣｏｒｅ初期化５８２を使用して、インスタンス化ｖＣｏｒｅのデフォルト設定を実行するか、又はそうでなければ実行させてもよい。ｖＣｏｒｅオーケストレーション５８４は、特定のｖＣｏｒｅに対するリソースの割り当てとともに、インスタンス化ｖＣｏｒｅの管理を実施するか、又はそうでなければ実行させるのに使用され得る。このように、初期のｖＣｏｒｅ初期化５８２とｖＣｏｒｅオーケストレーション５８４は、協力して、ｖＣｏｒｅのインスタンス化、ｖＣｏｒｅへのリソースの割り当て、リソース化されたインスタンス化ｖＣｏｒｅの管理を行う。初期ｖＣｏｒｅ初期化５８２は、好ましくは、サーバ上のオーケストレーションアプリケーション５４０とともに動作して、デフォルトのｖＣｏｒｅをインスタンス化することが好ましい。ｖＣｏｒｅオーケストレーション５８４は、好ましくは、サーバ上のオーケストレーションアプリケーション５４０と併せて動作し、ｖＣｏｒｅのオーケストレーションを実行する。ｖＣｏｒｅオーケストレーション５８４は、好ましくは、ＲＡＭ５２０と併せて動作して、ｖＣｏｒｅのリコースを割り当てる。
【0045】
前述したように、ｖＣｏｒｅインスタンスを含むＣＯＴＳサーバは、少なくとも部分的にＲＡＭ５２０によって管理されるリソースの割り当てを有する。ＣＯＴＳサーバ起動段階の間、ＲＡＭは、複数のリソースプール（ＣＰＵコア、データプレーンネットワークＶＦ、暗号化ＶＦなど）を作成し、その後、ＲＡＭは、コンテナオーケストレーションシステム５４０によって要求された場合に、各プールからのリソースをｖＣｏｒｅ ＰＯＤに割り当てるか、又はリースすることができる。さらに、ＲＡＭ５２０は、所望に応じて専用ハードウェアに選択的にオフロードされ得るデータ暗号化及び復号化を管理してもよい。
【0046】
ＲＡＭ５２０は、リソースの割り当て及び解放に使用され得、またリソースの可用性及び割り当て状態を決定するためにも使用され得るＲＥＳＴ ＡＰＩを含んでもよい。ＲＡＭ５２０はまた、リソースプールの状態を定期的に、耐久性のあるメモリ内キー値データベースキャッシュにチェックポイントし、ＣＯＴＳサーバがクラッシュした場合にそのキャッシュデータを使用し得る。インメモリキー値データベースキャッシュは、容易にランダムなアクセスに適しておらず、ＣＯＴＳサーバがクラッシュした場合にデータをメモリに再構築するのにより好適であることが好ましい。
【0047】
ｖＣｏｒｅインスタンス構成は典型的には、少なくとも二つの部分で構成される。第一の部分は、ＲＰＨＹ ＭＡＣ Ｃｏｒｅ構成であってもよい。ＲＰＨＹ ＭＡＣ Ｃｏｒｅ構成には、例えば、ＤＯＣＳＩＳ、ＲＦ、ＲＰＤ、ｃａｂｌｅ－ｍａｃ、ＩＰアドレス指定、ルーティングなどが含まれる。第二の部分は、データプレーン構成５３２であってもよい。データプレーン構成５３２、特にＲＰＨＹ ＭＡＣ Ｃｏｒｅデバイス構成のための仮想化データプレーンには、例えば、データプレーン５３２によって使用されるＣＰＵ Ｃｏｒｅ Ｉｄ、データプレーン４３２によって使用されるデータプレーンネットワークＶＦアドレス、インターフェースのＭＡＣアドレス、暗号化オフロード、メモリ割り当てなどに使用される暗号化ＶＦアドレスが含まれる。多くの実施形態では、ＲＰＨＹ ＭＡＣ Ｃｏｒｅ構成は、実際の構成の前に、複数のシステムオペレータによって提供される。データプレーン５３２のｖＣｏｒｅインスタンスは、初期化フェーズ中にｖＣｏｒｅインスタンス自体によってＲＡＭ５２０から受信したリソース情報に基づいて判定され得る。一般的な問題として、ｖＣｏｒｅはＭＡＣ層機能を実行することが好ましい。
【0048】
前述のように、ｖＣｏｒｅは、一般に、公衆インターネットと消費者施設設備との間でデータパケットをルーティングするデータプレーン機能を含むＣＭＴＳコアのソフトウェア実装である。ＣＭＴＳサービスを提供するｖＣｏｒｅの能力は、典型的にはＣＯＴＳサーバである基礎となるハードウェアの能力の機能である。データセンタ内に維持されるこうしたＣＯＴＳサーバは、典型的には一つ以上のプロセッサを含み、その各々は通常、統合された複数のコア（例えば、４、８、１６、２０個又はそれ以上）を含む。概して、各プロセッサの各コアは、独自の命令パイプライン、デコーダ、スタック、及び利用可能なメモリを有するという点で、独自のコンピューティングシステムとみなされ得る。より小さな並列処理チャンクへと分解可能なソフトウェアプログラムは、独立した処理チャンクをマルチコアプロセッサの異なるコアにスケジュールし、少なくとも部分的に並列して独立した処理チャンクを実行することによって実質的に高速化され得る。例えば、１０個の独立した機能のセットを１０個のコア上に分割することができ、各機能の完了に等しく時間がかかる場合、１０個の独立した機能のすべてを単一のコアプロセッサの単一のコア、又はマルチコアプロセッサの単一のコアで実行するよりも、概して１０倍速く実行される。したがって、ソフトウェアプログラムをサブプロフラムに分解し、サブプログラムをプロセッサの複数のコアで同時に実行するようスケジュールすることにより、処理が高速化され、プロセッサ内のすべてのコアを考慮した場合に、一秒間により多くの命令を実行するという点でハードウェアの効率が向上する。
【0049】
ｖＣｏｒｅについて、多くの場合、データパケットの性能スループットを最大化するために、リアルタイムデータプレーンパケット処理などの選択的計算集約型演算のためにコアのうちの少なくとも一つをリザーブすることが望ましい。
【0050】
一つ以上のサービスグループのセットにとって必要である可能性があるコンピューティングリソースに応じて、効果的かつ適時の処理を提供するために、ｖＣｏｒｅに十分なコンピューティングリソースを提供することが望ましい。一例として、ｖＣｏｒｅに割り当てるコア及び／又はｖＮＩＣ帯域幅が少な過ぎるとリソースの提供が不足し、顧客へのサービスの品質低下を結果としてもたらす。また、一つ以上のサービスグループのセットにとって必要である可能性があるコンピューティングリソースに応じて、効果的かつ適時の処理を提供するために、過剰なコンピューティングリソースがないｖＣｏｒｅを提供することが望ましい。一例として、あまりにも多くのコアを割り当てる及び／又はあまりにも多くのｖＮＩＣ帯域幅をｖＣｏｒｅにリザーブすると、ＣＯＴＳサーバハードウェア全体が効率的に利用されず、ＣＯＴＳサーバに未使用の能力が残ることになる。ｖＣｏｒｅに対する一つ以上のコア及び／又はｖＮＩＣ帯域幅の適切な選択が望ましい。さらに、適切なリソースを割り当てるために、ｖＣｏｒｅを効率的に配設及び構成することが望ましい。
【0051】
図６を参照すると、ｖＣｏｒｅ７００の各々は、インターネットプロトコル詳細記録（すなわち、ＩＰＤＲ）ストリーミングプロトコルを使用して、ネットワーク上で生成されたデータトラフィック統計を収集及び記録する。ＩＰＤＲプロトコルは、ＤＯＣＳＩＳプロトコルと統合されたサービスである。ｖＣｏｒｅは、顧客ベースでインターネットプロトコルベースのサービス使用についての情報を収集する。このようにして、ＩＰＤＲデータは、ｖＣｏｒｅ内のすべてのフロー、及びネットワーク上の各顧客デバイス（例えば、ケーブルモデム）についての消費使用情報についての情報を含有し得る。観察されるように、ＩＰＤＲデータは、顧客に関連する情報を含み得る。ＩＰＤＲデータは、ビジネス用途を促進する課金及び請求など、様々な異なるタイプのデータを含み得る。ＩＰＤＲデータはまた、ネットワーク容量、顧客使用、プロアクティブネットワーク保守、ダウンストリームデータ使用、アップストリームデータ使用、顧客識別、ｖＣｏｒｅ識別、ｖＣｏｒｅ構成、ｖＣｏｒｅ使用、顧客構成などに関するネットワーク情報を含み得る。他のタイプのＩＰＤＲデータは、例えば、ｖＣｏｒｅ名、システムアップタイム、ｖＣｏｒｅシステムアップタイム、ｖＣｏｒｅ ＩＰｖ４アドレス、ｖＣｏｒｅ ＩＰｖ６アドレス、ケーブルモデムｍａｃアドレス、ケーブルモデムＩＰｖ４アドレス、ケーブルモデムＩＰｖ６アドレス、サービスバージョンのケーブルモデム品質、ケーブルモデム登録ステータス値、ケーブルモデム最終登録時間などを含み得る。各ｖＣｏｒｅによって収集されたＩＰＤＲデータは、それぞれのＩＰＤＲエクスポータ７１０によって中央に位置するＩＰＤＲコレクタ７２０に伝送される。ＩＰＤＲコレクタ７２０は、それぞれのＩＰＤＲエクスポータ７１０から周期的に更新を受信する。一例として、ＩＰＤＲスキーマタイプは、イベントによりトリガされる（例えば、ケーブルモデムがリセットされる）とき、及びＩＰＤＲコレクタがデータを要求する（例えば、アドホック）ときに、時間（例えば、１５分ごと）に基づいて収集されてもよい。このようにして、ネットワーク特性、ｖＣｏｒｅ特性、顧客特性、及びネットワーク、ｖＣｏｒｅ、及び顧客のデータ使用に関する実質的な量のデータが収集される。ＩＰＤＲエクスポータ７１０は、顧客ベースでデータを取り込み、ネットワークを経由して、受信したデータを周期的に収集して非同期的に報告するＩＰＤＲコレクタ７２０に伝送されるＩＰＤＲデータ（例えば、データオブジェクト）を生成する。数百のｖＣｏｒｅなどの実質的な数のｖＣｏｒｅを用いることにより、実質的な数のＴＣＰ／ＩＰ接続がもたらされ、これは、ＩＰＤＲコレクタ７２０にとって負担になり得る。また、ＩＰＤＲエクスポータは、ｖＣｏｒｅをホストする対応するサーバ上に、容易に入手可能ではない場合がある計算リソースを必要とする傾向がある。更に、それぞれのＩＰＤＲエクスポータのＩＰアドレスの割り当てを含む、それぞれのｖＣｏｒｅに対する実質的な数のＩＰＤＲエクスポータの管理及び構成は負担になる。
【0052】
図７を参照すると、図６のアーキテクチャに関連付けられた制限を低減するためには、ＩＰＤＲデータの周期的な収集のためにＩＰＤＲデータをＩＰＤＲコレクタに提供するために、ｖＣｏｒｅの各々に対してＩＰＤＲエクスポータを使用しないことが望ましい。それぞれのｖＣｏｒｅが個別のＩＰＤＲエクスポータとして作用するのではなく、それぞれのｖＣｏｒｅ８００の各々は、ＩＰＤＲデータ８１０のデータをメッセージングサービス８２０に提供する。
【0053】
メッセージングサービス８２０は、リアルタイムデータフィードに好適なストリーム処理サービスであることが好ましい。メッセージングサービスは、メッセージを一緒に「トピック」８２２としてグループ化する「メッセージセット」抽象化を使用する、バイナリＴＣＰベースのプロトコルを使用することが好ましい。トピック８２２は、異なるタイプのデータを異なるグループへとグループ化することを促進する。一例として、アップストリームｖＣｏｒｅデータは、「ｕｓＵｔｉｌＳｔａｔｓ」に一致するアップストリーム統計内に提供され得る。一例として、ダウンストリームｖＣｏｒｅは、「ｄｓＵｔｉｌＳｔａｔｓ」に一致するダウンストリーム統計内に提供され得る。一例として、ケーブルモデムＩＰｖ６アドレスデータは、「ＣＰＥ」のトピック内に提供されてもよい。また、選択された異なるデータが、単一のトピックへと一緒にグループ化されてもよい。このようにして、ＩＰＤＲデータのすべてが、トピックのうちの一つに選択的に提供される。また、それぞれのｖＣｏｒｅの各々は、それらのそれぞれのＩＰＤＲデータを同じ方法でトピックの同じセットに提供する。したがって、メッセージングサービスの各トピックは、ｖＣｏｒｅのすべてからのそのトピックに対するＩＰＤＲデータのすべてを有し得る。好ましくは、それぞれのトピックに含まれるデータセットは、互いに異なることが好ましい。メッセージングサービスは、Ａｐａｃｈｅ Ｋａｆｋａなどの任意の好適な技法を使用して実装され得る。Ａｐａｃｈｅ Ｔｈｒｉｆｔを使用して、サポートされる各記録タイプに対するメッセージングサービスに置かれるデータを定義してもよく、各記録タイプは、別個のメッセージトピックを使用する。
【0054】
ＩＰＤＲサービス８３０は、トピック８２２の各々内のデータを消費し、それにより、メッセージングサービス８２０からデータを除去する。これにより、ＩＰＤＲサービス８３０は、メッセージングサービス８２０から、組織化された方法でｖＣｏｒｅ８００の各々からのＩＰＤＲデータ８１０のすべてを受信する。
【0055】
ＩＰＤＲエクスポータ８４０は、ＩＰＤＲサービス８３０からデータを受信し、インターネットプロトコル詳細記録（すなわち、ＩＰＤＲ）ストリーミングプロトコルに含まれる単一のストリームの形態でＩＰＤＲデータを提供する。ＩＰＤＲエクスポータ８４０は、インターネットプロトコル詳細記録（すなわち、ＩＰＤＲ）ストリーミングプロトコルをネットワーク８６０にわたってＩＰＤＲコレクタ８５０に提供するように構成される。ＩＰＤＲコレクタ８５０は、ＩＰＤＲエクスポータ８４０から、複数のｖＣｏｒｅからのデータを受信するための単一の相互接続を含む。ＩＰＤＲストリーミングプロトコルは、その全体が参照により本明細書に援用される、ＩＰＤＲ／ＳＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（２００４）に準拠することが好ましい。ＩＰＤＲエクスポータ８４０は、ＩＰＤＲセッションの各タイプに対するセッションを維持するため、及びデータをＩＰＤＲコレクタ８５０に送信するためのＩＰＤＲコレクタ８５０への接続を担う。このように、ＩＰＤＲコレクタ８５０の視点からのシステムの構成は、単一のＩＰＤＲエクスポータ８４０を含むように見える一方で、同時に、相当数のｖＣｏｒｅをサポートし、それが相当数の顧客をサポートしているように見える。ＩＰＤＲサービス８３０及びＩＰＤＲエクスポータ８４０サービスは、所望に応じて、別個のサービスである、又は組み合わせられ得る。
【0056】
ＩＰＤＲエクスポータ８４０は、呼び出し顧客に対して安全、均一、及びステートレスな方法でＡＰＩを露出する、レストフルサービス（例えば、ＲＥＳＴ ＡＰＩ－ＲＥｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）を含む。ＲＥＳＴ ＡＰＩは、ＩＰＤＲセッションタイプ、ＩＰＤＲエクスポータ、ならびにＩＰＤＲコレクタを提供するために使用され得る。また、ＡＰＩは、（１）実行しているＩＰＤＲエクスポータを有効化又は無効化する、（２）ＩＰＤＲコレクタを提供、及び有効化又は無効化する、（３）ＩＰＤＲエクスポータを、ＩＰＤＲコレクタへの接続のアクセプタ又はイニシエータとして提供する、（４）選択されたＩＰＤＲセッションのタイプを、好ましくは、トピックと一致させて有効化又は無効化する、（５）ＩＰＤＲセッションタイプについて、どのＩＰＤＲコレクタがアクティブであるかについての情報を取得する、及び（６）ＩＰＤＲエクスポータサービス統計を取得するために、ユーザインターフェースに統合されてもよい。好ましくは、ＩＰＤＲエクスポータは、ＲＥＳＴ ＡＰＩを提供するネットワーククラウドベースのサービスを使用することによって、ｖＣｏｒｅのＩＰＤＲデータ収集の管理を提供する。
【0057】
別の実施形態では、ＩＰＤＲエクスポータ及びＩＰＤＲコレクタは、メッセージングサービスからデータを直接読み取り、その後の分析に利用できるようにするサービスと置き換えられてもよい。
【0058】
アグリゲーションのジョブ一部は、ＩＰＤＲコレクタへのアクティブセッションの量を制御することである。各ＩＰＤＲ記録タイプは、ＩＰＤＲコレクタに対する単一のセッションである。ＤＯＣＳＩＳ ＩＰＤＲでは、各記録タイプは、関連付けられたＩＰＤＲセッションＩＤを有する。ＩＰＤＲエクスポータサービスは、この挙動を維持する。ＩＰＤＲデータをストリーミングするとき、プロトコルは、「ＩＰＤＲ開始」メッセージを使用し、その後多くのＩＰＤＲデータパケットが続き、「ＩＰＤＲ停止」メッセージで終了する。多くのｖＣｏｒｅが含まれるため、データアグリゲーションの結果として、同じＩＰＤＲデータタイプに対していくつかの開始及び停止メッセージが存在し得る。例えば、ＩＰＤＲ時間ベースのデータの収集は、数百のｖＣｏｒｅ間でずれてもよい。ｖＣｏｒｅがメッセージングシステムに書き込むとすぐ、ＩＰＤＲサービスがデータを消費し、ＩＰＤＲエクスポータがデータを送信し得る。ＩＰＤＲコレクタは、ＩＰＤＲメッセージ内のｖＣｏｒｅホスト名を使用するなど、任意の好適な方法で複数のｖＣｏｒｅ間の識別を処理し得る。
【0059】
ＩＰＤＲサービス及びＩＰＤＲエクスポータは、イベント又は時間ベースのＩＰＤＲデータを異なって処理する必要はなく、各ｖＣｏｒｅは、時間ベース及びイベントベースのＩＰＤＲデータを収集し、データをメッセージングシステムに置くことに留意されたい。
【0060】
ＩＰＤＲコレクタは、本明細書において概してアドホックと呼ばれる専用タイプのＩＰＤＲ収集を含んでもよく、ＩＰＤＲコレクタは、それぞれのｖＣｏｒｅから専用ＩＰＤＲタイプについてのＩＰＤＲデータを要求する。アドホックＩＰＤＲ要求は、任意の好適な方法で処理され得る。アドホックＩＰＤＲ要求を処理する一つの方法は、ＩＰＤＲコレクタが、専用ＩＰＤＲ記録タイプに対して一つ以上のｖＣｏｒｅにメッセージ送信することである。これに応答して、上述したように、ｖＣｏｒｅがアドホックメッセージタイプにデータを書き込み、次いでデータが処理されてＩＰＤＲコレクタに提供される。アドホックを処理する別の方法は、ＩＰＤＲコレクタが、ｖＣｏｒｅに対するＳＮＭＰ（又は他の技法）ベースの要求を使用して要求されたＩＰＤＲ記録タイプデータを収集することである。ＩＰＤＲ記録タイプデータが生成され、メッセージングシステムとは別個の方法で、ＩＰＤＲコレクタへとストリームアウトされる。
【0061】
更に、前述の実施形態の各々における各機能ブロック又は様々な特徴は、典型的には集積回路又は複数の集積回路である回路によって実装又は実行され得る。本明細書に記載される機能を実行するように設計された回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け若しくは一般用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、又は他のプログラマブル論理デバイス、ディスクリートゲート若しくはトランジスタ論理、又はディスクリートハードウェアコンポーネント、又はそれらの組み合わせを含み得る。汎用プロセッサは、マイクロプロセッサであり得るか、又は代替的に、プロセッサは、従来のプロセッサ、コントローラ、マイクロコントローラ、若しくは状態機械であり得る。上記に記載される汎用プロセッサ若しくは各回路は、デジタル回路によって構成され得るか、又はアナログ回路によって構成され得る。更に、半導体技術の進歩により、現時点で複数の集積回路に取って代わる集積回路にする技術が出現すると、この技術による集積回路も使用することができる。
【0062】
本発明は、記載されている特定の実施形態に限定されず、添付の特許請求の範囲に定義される本発明の範囲から逸脱することなく、同等の教義、又はその文字通りの範囲を超えて法的強制力のある特許請求の範囲を拡大する任意の他の原則を含む、優越的法の原則に従って解釈されるように、変更がそれに行われ得ることが理解されるであろう。文脈がそうでないと示さない限り、要素の実例の数に対する特許請求の範囲の参照は、それが一つの実例への参照であろうと、又は複数の実例への参照であろうと、少なくとも要素の実例の所定の数を必要とするが、記載されているよりも多くのその要素の実例を有する特許請求の範囲の構造又は方法の範囲から除外することを意図するものではない。特許請求の範囲において使用される場合、用語「含む」又はその派生語は、特許請求される構造又は方法における他の要素又はステップの存在を除外することを意図するものではない非排他的な意味で使用される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【国際調査報告】