データの自動圧縮

著者らは特許

G06F9/54 - プログラム間通信
H04L1 - 受信情報中の誤りを検出または防止するための配置
H04L12/18 - 放送または会議のためのもの

の所有者の特許 JP2016528591:

アルカテル−ルーセント

 

本出願は、少なくとも2つの処理ノード(1)を備えるシステムであって、ノード(1)が、実行環境(2)および処理コンポーネント(3)を備え、各実行環境(2)が、処理コンポーネント(3)の発信ポートおよび異なる処理コンポーネント(3)の着信ポートの間に通信チャネル(4)を確立するための手段を含み、通信チャネル(4)がノード(1)の境界を横断するかを判定し、通信チャネル(4)を経由して転送されるデータの符号化/復号が必要かを決定するように構成された、システムに関する。

 

 

本文書は、特にアプリケーションの分散処理の文脈において、データが符号化された様式で転送されるかを自動的に決定する制御ユニットおよびシステムに関する。
近年、データ、コンピュータプログラムおよびアプリケーションは益々、ネットワーク中心のデータセンター(「クラウド」)において格納され実行されるようになっている。しかしながら、特に、クラウドにおけるメディアデータの分散リアルタイム処理の技術分野において、帯域幅およびエンドツーエンド遅延制約のために、リアルタイムメディアの処理は、ネットワークリンクを横断した伝送データに関する敏感さを特に必要とする。
サービス型プラットフォーム(PaaS:Platform−as−a−Service)手法において、ネットワークの異なる部分に配置された処理ノード上に分離可能なソフトウェアコンポーネントから構成されるアプリケーションを自動的に配布する機能が提供される。共有データの局所性を利用して伝送ネットワーク内のトラフィックを最小化し、処理ノードのリソース利用を最適化し、ネットワーク内のユーザ一の位置に近い遅延に敏感なタスクを処理することでユーザ体験を改良するために、この配布は利用される。クラウドベースの処理環境において、別個の処理ノード上で実行される別々のソフトウェアタスクの間の異なるデータ伝送シナリオが適用され得る。典型的なシナリオは、エンドデバイスへの、およびエンドデバイスからネットワークの向こう側のメディア処理ノードへのメディアデータ伝送、単一のデータセンター内の処理ノード間のメディアデータ伝送、および異なるデータセンター内に配置された処理ノード間のメディアデータ伝送である。
サービスプラットフォーム上の分散処理から利益を得る典型的なアプリケーションシナリオは、たとえばビデオチャットである。ビデオチャットのシナリオでは、たとえば、人々のグループが、仮想の共有されたビデオ環境/ビデオチャットルームに参加する。各個人は、自身のカメラのビデオデータをクラウドにストリーミングする。ビデオチャットサービスは、そのような共有環境内に集まっているユーザの全てのメディアストリームを結合し、各参加者に対する仮想ルームの個人用ビューを生成する(すなわち、処理する)。したがって、仮想ルーム内の各個人は、全ての(他の)参加者の個人用のレンダリングされたビューを受信する。
ビデオチャットなどのアプリケーションが、クラウド内の異なる処理ノードを横断して実行される別個の処理部分(すなわち、処理コンポーネント)に分割できると仮定される。典型的なシナリオは、以下を含む:
− データ発生源の近くに位置する処理リソース上に配置されることが好ましい、カメラ信号の前処理、たとえば背景減算、顔または行動検出、たとえば「誰が話しているか」の機能。
− 仮想カメラのパン/チルトおよびズーム要素を選択することで高解像度を有する現実のカメラの信号から抽出されるべきビデオの特定の部分を決定するためのユーザのインタラクションにより制御されるモジュール。
− 全ての参加者に対して「遅延の中心」に配置されることが好ましい、クラウド内の処理リソース上のチャットルーム内の人々の異なるビデオ信号の全てをマージさせるビデオ混合機能。
− エンドユーザの対話型ジェスチャまたは他の手段などにより制御される、このユーザの近くに配置された処理リソース上に配置されることが好ましい、個人視点レンダリング。
たとえば、ビデオチャットアプリケーション内の処理部分は、背景抽出とすることができる。この部分は、色変換、実際のフレームの背景モデルとの比較、背景モデルの統計的更新、前景マスク生成などの別個のタスクを行ういくつかの処理コンポーネントから構築および構成されることがある。
たとえばプラットフォームシナリオでは、コンポーネントは、送信コンポーネントの出力ポートを1つまたは複数の受信コンポーネントの入力ポートに接続するメッセージパッシングインターフェースを介して通信することができる。開発者は、自身のアプリケーションの実行インスタンスを、そのアプリケーションを構成する異なる処理要素から構成される動的サービス論理グラフを編成することで、作成し維持することができる。
グラフの操作には、コンポーネントの作成、修正または除去、および動的な方式でコンポーネント間の接続の確立または解放が含まれる。開発者の視点からは、プラットフォームは単一の仮想処理リソースのように振る舞い、前述のように物理的な基盤リソース上へ適切にアプリケーションの異なるコンポーネントを配備するのはプラットフォームの仕事である。
典型的には、特定のタスクごとに必要な処理能力は、異なるメディアパラメータに依存する。パラメータは、画像解像度、フレームレート、参加者数などとすることができる。さらに、所望の機能を実行するのに必要なリソースの数は、リソース能力と、(すぐに変動し得る)個々の処理ノードの現在の負荷状況とに依存することがある。
したがって、どのようにアプリケーションの異なるコンポーネントが、異なる処理ノードを横断して最も効率良く配布されるかをアプリケーション開発者が予測することは一般的には困難である。プラットフォームのみが必要な情報を有するので、リソース上のサービス実行時に出現するリソースボトルネックを、このリソース上で現在実行中のいくつかの処理部分/コンポーネントを現在あまり利用されていない他のリソースへ再配布することにより解消する方法を決定するのはプラットフォームの仕事である。
しかしながら、ビデオチャットサービスなどのビデオアプリケーションのコンポーネントを配布するための根本的な問題は、多数のメディア処理コンポーネントが主に一連の画素値(すなわち、単一のビデオフレーム)に作用するので、コンポーネント間で交換されるデータの量が大量であることである。このように、コンポーネントは通常、画素値の完全なフレーム、すなわち非圧縮のビデオフレーム(生データ)をその出力ポートに送信する。これにより、生の「ビデオ」トラフィックが、異なる処理ノードを接続するネットワーク上で伝送、すなわち交換される必要があるので、アプリケーションコンポーネントを異なる処理ノードにわたって分割することが困難となり、したがって、ネットワークの輻輳をもたらすことがある。したがって、異なる処理リソース上で実行されるコンポーネント間で交換されるメディアデータは、有意義な方法で圧縮される必要がある。
開発時のサービスグラフの開発者は、どのようにプラットフォームがサービス実行時に異なるサービスコンポーネントを処理リソースにわたって分割することになるかを知らないので、必要に応じて通信経路内に圧縮(すなわち、符号化/復号)を自動的に含むプラットフォーム機能が必要である。
本文書は、特に、ネットワーク中心のデータセンターにおいて互いに接続された処理ノードなどの前記処理ノードのうちの少なくとも2つを有するシステムにおいて使用可能な制御ユニット、システムおよび方法を提供する技術的問題に対処する。制御ユニット、システムおよび方法により、データの符号化および復号が必要かを自動的に決定し、送信および受信コンポーネントの間のデータ依存圧縮メカニズムを動的にインスタンス化することが可能となる。
ヘッダおよび転送されるデータ(ペイロード)を備え、外部ネットワークインターフェースを通過する、メッセージのデータ形式を分析することで、本明細書に記載の態様は、送信機側にデータ形式依存エンコーダを挿入することと、圧縮形式(すなわちデータ形式)を示す制御メッセージを受信機側に送信することと、圧縮器のインスタンスを用いて各後続のメッセージを動的に圧縮することとを可能にする。さらに、メッセージで転送されるデータは、遠隔側で復号することができ、復号後に受信コンポーネントに配信することができる。
これら全てがそのようなサービスの開発者に透過的に実行できることに留意されたいが、その理由は、コンポーネントが同一または別個のリソース上で実行される場合にサービス論理フローからは注意が払われる必要がないためである。メディア圧縮は、基本となるプラットフォームにより自律的に、および必要な場合にのみ、コンポーネントの通信経路に含まれる。
さらに、逆の部分もカバーされていることに留意されたい。異なるリソース上で以前に動作していた2つのコンポーネントが何らかの理由でサービス実行時に同一のリソース上に配置された場合に、以前に外部であった通信経路は内部になるので、メディア符号化および復号機能はプラットフォームにより通信経路から自動的に除去されることになる。
したがって、本明細書で提示された制御ユニットおよびシステムは、通信チャネルを介して接続されたコンポーネントが、データが受信されたのはローカルのコンポーネントからか遠隔のコンポーネントからかの違いに気付かず、同時に、ネットワークリンク上のデータレートが低減されるという技術的利点を有する。したがって、圧縮方式全体が開発者から隠されており、開発者はコンポーネントのみに注意を払い、コンポーネントは、それらの接続内で圧縮が生じたことに気付かない。
具体的には、本文書は、詳細にはコンポーネント間の通信チャネルが何らかの理由でノード内部の通信チャネルの代わりに外部伝送ネットワークを使用することを検出することで、送信および受信コンポーネントの間のデータ依存圧縮メカニズムを動的にインスタンス化することができる、特にネットワーク中心のデータセンター、すなわちクラウド環境のための制御ユニット、自律システムおよび方法を提供する。
一態様によれば、制御ユニットは、2つの処理ノードの間の通信チャネルが処理ノードの境界を横断するかを判定するように構成することができる。通信チャネルが処理ノードのうちの1つの境界を横断する場合に、制御ユニットは、通信チャネルを経由して転送されるデータの符号化/復号が必要かを決定するようにさらに構成することができる。制御ユニットは、たとえば送信処理ノードまたは受信処理ノードなどの処理ノードの一部とすることができる。あるいは、またはこれに加えて、制御ユニットは、異なるデータセンターに配置された異なる処理ノードを備えるシステムの別個のエンティティにより提供することができる。
さらなる態様によれば、ネットワークにより接続された少なくとも2つの処理ノードを備え得るシステムが提供される。各ノードは、実行環境および少なくとも1つの処理コンポーネントを備えることができる。各実行環境は、データを送信するコンポーネントの発信ポートを、データを受信するコンポーネントの着信ポートに、通信チャネルを介して接続するための手段を含むことができる。システム、好ましくはシステムの制御ユニットは、上述のように、通信チャネルがノードの境界を横断するかを判定するように構成することができる。さらにシステム、好ましくはシステムの制御ユニットは、通信チャネルがノードの境界を横断する場合に、通信チャネルを経由して転送されるデータの符号化/復号が必要かを決定するように構成することができる。
ノードの境界の横断は、通信チャネルが外部伝送ネットワーク、たとえばローカルエリアネットワーク(LAN)またはワイドエリアネットワーク(WAN)を使用する場合に、検出することができる。たとえば、ノードが、プロセッサ、記憶手段およびネットワークインターフェースを備えるユニットである場合に、外部伝送ネットワークは、ノードを、より具体的にはノードのネットワークインターフェースを互いに接続するネットワークであると定義することができる。ノードの境界の横断は、ネットワークリンクの横断と定義することができる。ノードの境界の横断は、ネットワークプロトコル、たとえばRTP、UDP、TCP、IPが通信チャネルを経由してデータを送信するために使用される場合に検出できることが好ましい。たとえば、ある処理コンポーネントがあるネットワークノード上で動作し、最初のコンポーネントと通信する他の処理コンポーネントが他のネットワークノード上で動作する場合に、ネットワーク境界は横断される。
以下、「システム」という用語が「プラットフォーム」という単語と交換できることに留意されたい。「データ」という用語は、システムの部分/ノード/コンポーネントの間で交換/転送される情報を示すことができる。「メッセージ」という用語は、メッセージのヘッダと、送信すべきデータ(ペイロード)とを実質的に意味する。
「符号化/復号」という用語は、符号化および/または復号を示す。具体的には、メッセージ/データがそこから送信される一方の側において、データが符号化(圧縮)され、他方側すなわち受信側において、データが復号されることを意味する符号化および復号を示す。
以下では、第1のコンポーネントがデータを送信するコンポーネント、すなわち「送信コンポーネント」であること、また、第2のコンポーネントがデータを受信するコンポーネント、すなわち「受信コンポーネント」であることが仮定されることになる。
しかしながら、システムが3つ以上のノードおよび3つ以上のコンポーネントを備えることができることに留意されたい。さらに、複数の異なる通信チャネルを、2つ以上のノード間に確立することができる。具体的には、送信コンポーネントは、1つまたは複数の通信チャネルを介して少なくとも1つの受信コンポーネントに接続されるように構成することができる。
「受信ノード」および「送信ノード」という用語は、受信/送信コンポーネントを備えるノードを示す。ノードという用語は、少なくとも1つのプロセッサと、少なくとも1つの記憶デバイスと、少なくとも1つのネットワークアダプタとを好ましくは備えるコンピューティングリソースまたはホストを示すことができる。言い換えれば、ノードは、ネットワークにおいて他のノードと接続された完全に動作可能なスタンドアローンの処理ユニットであることが好ましい。
さらなる態様によれば、送信コンポーネントは、1つまたは複数の通信チャネルを介して少なくとも1つの受信コンポーネントに接続されるように構成することができる。(1つまたは複数の)コンポーネントの間に1つまたは複数の通信チャネルを確立することで、アプリケーションコンポーネントを柔軟に配布することができる。
さらに、システムは、各確立された通信チャネルに関する情報を含むテーブルを備えることができる。前記情報は、各通信チャネルに対して、その通信チャネルの送信コンポーネントおよび受信コンポーネントのポートを含むことができる。さらに、前記情報は、受信コンポーネントが送信コンポーネントと異なるノード内に配置されている場合に識別子を含むことができる。識別子は、遠隔の受信ノードのネットワーク位置を識別することができる。テーブルは、特定の(専用の)処理ノード内に配置し格納することができ、場合によりローカルコピーが各処理ノードで利用可能であることが好ましい。さらに、各処理ノードは、たとえば前記ノード上で動作する処理コンポーネントに関する情報のみを含む、テーブルの部分的なコピーを有することができる。
テーブルにより、概観を維持することができ、および、複数のコンポーネント間の接続に関して最も関連性が高い情報に素早くアクセスすることが可能となる。識別子は、ノードの境界の横断の判定が、より素早くより少ないコンピューティングリソースを用いて実行できることを支援する。
システム、特に、対応する送信コンポーネントをホストする制御ユニットおよび/または実行環境は、前記テーブル内の検索操作により通信チャネルがノードの境界を横断するかを検出するように構成することができる。検索操作は、コンポーネントが移動されたこと、すなわち処理コンポーネントの再割当を示すことができ、または、遠隔ホスト上のコンポーネントとの接続の作成を示すことができるエントリが設定されているかを検出するように構成することができる。エントリは、前記テーブルに設定される第1のフラグなどとすることができる。あるいは、またはこれに加えて、検索操作は、受信コンポーネントのノードの位置を発見するために前記識別子を読み出すように構成することができる。検索操作により、通信チャネルがノードの境界を通過するかの判定が、ほぼ即時に、コンピューティングリソースを使用し過ぎることなく実行できるようになる。
さらに、たとえば、通信チャネルが2つのコンポーネントの間に確立されているときに、送信および/または受信コンポーネントがその後あるノードから他のノードへ移動された場合に、システム、特に実行環境は、前記テーブル内の前記情報に前記エントリを追加するようにさらに構成することができる。エントリはコンポーネント移動を明示することができ、これにより、通信チャネル、特に既存の通信チャネルがノードの境界を横断するかをより素早く判定できるようにする。
さらに、システムは、転送されるデータが所定のサイズを超過した場合に符号化/復号が必要であると決定することができ得る。具体的には、送信または受信側でのデータストリームのサイズまたはボリューム(ネットワークインターフェース容量)、および/または、物理ネットワークチャネルの容量制限が、関心の対象である。典型的には、ビデオ関連データまたは高音質音声データが、符号化/復号要件をトリガする。
システムは、転送されるデータが所定のデータ形式を有する場合に、すなわちデータタイプの形式に基づいて、符号化/復号が必要であると決定することができ得る。所定のデータ形式は、たとえばメディア形式を含むことができる。これは、システムが、一般的にはメディアデータ、たとえば画像データ形式、音声データ形式、および/またはビデオデータ形式を有するデータが、あるノードから遠隔ノードへ転送される場合に、符号化された/復号するように構成することができることを意味する。
さらに、データが、フレーム単位で送信されるビデオデータである場合に、符号化/復号が必要である場合がある。コンポーネントが画素値の完全なフレーム、すなわち非圧縮ビデオフレーム(生データ)をその出力ポートに送信する場合、大量のデータがコンポーネント間で通信チャネルを介して交換される。これにより、アプリケーションコンポーネントを異なる処理ノードにわたって分割することが困難になる場合がある。しかしながら、本明細書に記載のデータの自動圧縮によって、ビデオフレームの送信も可能となるので、ビデオデータアプリケーションのコンポーネントの自動配布が可能となる。
システムは、送信および受信ノードの一方または両方が所定の作業負荷で動作する場合に符号化/復号が必要であると決定することができ得る。これは、ノードが既に高い作業負荷で動作しているときに、符号化/復号に関する追加の作業負荷が、ノードのうちの少なくとも1つのノードの過負荷をもたらすことになる場合に、符号化/符号化が初期化されないケースを含むことができる。
一態様によれば、送信処理ノードは、少なくとも1つの実行環境と、少なくとも1つの処理コンポーネントと、通信チャネルを経由してデータを送信するために受信処理ノードと通信チャネルを介して接続可能な少なくとも1つの発信ポートとを備えることができる。実行環境は、通信チャネルを確立するように構成することができる。受信処理ノードは、制御ユニットを備えることができる。さらに、送信処理ノードは、符号化が必要であると決定された場合に、エンコーダをインスタンス化し、インスタンス化されたエンコーダのタイプに関して受信処理ノードに知らせるように構成することができる。さらに、受信処理ノードは、少なくとも1つの処理コンポーネントと、通信チャネルを経由してデータを受信するために送信ノードと通信チャネルを介して接続可能な少なくとも1つの着信ポートとを備えることができる。送信処理ノードは、制御ユニットを備えることができる。受信処理ノードは、符号化が必要であると決定された場合に、送信処理ノードにおいてインスタンス化されたエンコーダのタイプに関する情報に基づいて、デコーダをインスタンス化するようにさらに構成することができる。
さらに、実行環境および少なくとも1つの処理コンポーネントを備え得る(処理)ノードを提供することができる。実行環境は、データを送信するコンポーネントの発信ポートを、異なるノードに配置され得るデータを受信するコンポーネントの着信ポートと、通信チャネルを介して接続するための手段を含むことができる。ノード(たとえば、ノードの制御ユニット)は、通信チャネルがノードの境界を横断するかを判定するように構成することができる。さらに、ノードは、通信チャネルがノードの境界を横断する場合に、外部通信チャネル、たとえばノードを接続する通信ネットワーク上のトラフィックを削減するために、通信チャネルを経由して転送されるデータの符号化/復号が必要であるかを決定するように構成することができる。
ノードは、さらなる処理ノードを備えるネットワークの一部とすることができる。ノードは、ネットワーク内で互いに接続することができる。上記で説明されたノードの利点は、データが符号化された様式で通信チャネルを経由して転送されるべきであるかをノードが自動的に決定できることである。たとえば、ノードが、少なくとも1つのプロセッサ、少なくとも1つの記憶手段、およびネットワークインターフェースを有するユニットであると仮定すると、ノードは、通信チャネルが前記インターフェースを介して前記ユニットの外部に接続する場合に、通信チャネルが前記ノードの境界を横断すると判定することができる。言い換えれば、ノードは、通信チャネルが前記ノードのネットワークインターフェースを異なるノードの異なるネットワークインターフェースに接続する場合に、前記ノードの境界が横断されると判定することができる。ノードは、通信チャネルを経由して送信されるデータのタイプが特定のタイプ、たとえば音声、画像またはビデオデータなどのメディアデータタイプである場合に、符号化が必要であるとさらに決定することができる。
上記のシステムの機能および態様を各ノードに組み込むことができることに留意されたい。たとえば、通信チャネルがノードの境界を横断するか、および符号化/復号が必要であるかの決定は、送信または受信ノードの一方、特にその実行環境により実行することができる。テーブルは、ノードの機能により取り扱うことができ、検索操作は、送信ノードなどの機能により実行することができる。あるいは、ネットワーク全体の制御インスタンスを、これらの機能を実装するために提供することができる。
さらに、システムは、各(処理)コンポーネントが個別に/別々にノードにより処理可能となるように、ノードにわたってアプリケーションの処理コンポーネントを自動的に配布できるアプリケーション配布機能を備えることができる。典型的なアプリケーションは、たとえばビデオチャット、音声チャット、ビデオストリーミングなどのマルチメディアアプリケーションの処理に関連する。
したがって、システムは、ネットワークリンクの横断(すなわち、2つのコンポーネント間の処理ノード外部通信)が検出された際に随時、サービスコンポーネント間でビデオデータまたは任意の他のメディアデータなどのデータを伝送する通信チャネルのデータストリームにおいて、動的に圧縮機能をインスタンス化し含められるようにすると有利である。
たとえば、プラットフォーム、たとえばマルチメディアコンテンツクラウドにおいて、アプリケーション開発者は、いつメッセージが2つのコンポーネント間に確立された通信チャネル上のネットワークリンクを横断するかを知らず、その理由は、コンポーネント配置決定がプラットフォームにより実行時に動的に実行されるためである。提案されたシステムでは、処理ノード境界(すなわち、外部ネットワークインターフェースまたはネットワークリンク)が通信チャネルにより通過され、および/または、予想データサイズまたはデータレートがネットワークリンクに過負荷を導入し得る場合に随時、実行環境は圧縮機能をインスタンス化する(すなわち、送信コンポーネントをホストするリソース上のエンコーダ、および受信コンポーネントをホストするリソース上のデコーダをインスタンス化する)。
そのような場合、実施形態によれば、実行環境は、基本コーデック(コーダおよびデコーダ)形式を決定し、メッセージパッシングインターフェースの一部として送信側のエンコーダおよび受信側のデコーダを自動的にインスタンス化する。たとえば、プラットフォームシナリオでは、コンポーネントは、送信コンポーネントの出力ポートを1つまたは複数の受信コンポーネントの入力ポートに接続するメッセージパッシングインターフェースを介して通信することができる。コーデックのインスタンス化は、たとえば、ローカルコンポーネントおよび遠隔コンポーネントの間の新しい通信チャネルが確立された場合、または、プラットフォームリソース管理アルゴリズムがコンポーネントの1つを他の処理リソース/ノードに移動させることを決定した際に既存のローカル接続が遠隔接続となった場合に、生じることがある。
コーデック形式は、受信コンポーネントの着信ポートまたは送信コンポーネントの出力ポートのメッセージタイプ、2つのコンポーネント間のデータ交換に使用される論理リンクの特定の(アプリケーション開発者による所定の)プロパティまたは接続に沿って通過するメッセージのタイプにより、決定することができる。
接続、すなわち通信チャネルを横断したメッセージを送信した時に、プラットフォーム機能は、データをエンコーダに渡して圧縮し、外部ネットワーク上で標準的なネットワークプロトコル(たとえばRTP、UDP、TCP、IP)を用いて送信し、遠隔側で復号し、最後に受信コンポーネントに元の非圧縮形式で渡す。データの伝送は、アプリケーションの分散処理を容易化するために行われる。アプリケーションのコンポーネントの処理は、ネットワークにおいて互いに接続された処理ノードにより行われる。
さらなる態様は、システム内のデータ通信のための方法に関する。システムは、少なくとも2つのノードを有することができる。ノードは、実行環境および処理コンポーネントを有することができる。実行環境は、データを送信可能な処理コンポーネントの発信/アウトバウンドポートをデータを受信可能な処理コンポーネントの着信ポートと通信チャネルを介して接続するための手段を含むことができる。方法は、通信チャネルがノードの境界を横断するかを判定するステップを備えることができる。これは、送信ノードおよび受信ノードの間の通信チャネルを確立した時などに、行うことができる。さらに、方法は、特にノードの境界が横断されると判定された場合に、通信チャネルを経由して転送されるデータの符号化/復号が必要であるかを決定することを備えることができる。方法は、符号化/復号が必要であると決定された場合に、送信コンポーネントのノード内のエンコーダと、受信コンポーネントのノード内のデコーダとを初期化することを備えることができる。方法は、転送されるデータを送信コンポーネントからエンコーダに提供し、エンコーダ内でデータを符号化することをさらに含むことができる。符号化されたデータを通信チャネルを経由して受信ノードに送信することができる。
この方法には、アプリケーションを分散的に処理する、すなわちアプリケーションが相異なる処理ノードにより処理されるシステムなどに生じるデータトラフィックを柔軟に削減できるように、通信チャネルを経由して送信されるデータを自動的に符号化/復号できるという利点がある。
さらに、エンコーダが送信コンポーネントのノード内でインスタンス化された後に、インスタンス化されたエンコーダのタイプに関する情報を含み得る制御メッセージ(情報)が、送信コンポーネントのノードの実行環境などから受信コンポーネントのノードの実行環境などに送信することができる。デコーダは、制御メッセージに含まれる情報に基づいてインスタンス化されることができる。デコーダをインスタンス化した時に、転送されるデータを送信ノードから受信ノードへ通信チャネルを経由して送信できることが好ましい。あるいは、制御情報を、転送されるデータと共に送信することができ、たとえば、転送されるデータを、送信側で適用される符号化/圧縮機能に関する制御情報も含むメッセージ内で送信することができる。制御情報および転送されるデータを1つのメッセージ内で送信することで、ネットワークトラフィックをさらに削減することができる。
したがって、コーデックをインスタンス化するための、および、ノード境界を横断する通信チャネルを経由してデータを送信するためのいくつかの代替の選択肢が存在する。エンコーダが送信側でインスタンス化された後に、制御メッセージを受信ノードに送信することができる。制御メッセージは、エンコーダタイプなどに関する情報を受信側に提出して、対応するデコーダをインスタンス化できるようにする。さらなる選択肢は、エンコーダをインスタンス化でき、転送されるデータを送信側で符号化できることでもよい。この選択肢によれば、続いて、符号化されたデータを含むメッセージであって、たとえばメッセージのヘッダ部分に符号化/圧縮に関する制御情報を含むメッセージを、受信側に転送することができる。したがって、制御情報および転送されるデータの両方は、同時に受信側に到着する。デコーダは、転送された符号化されたデータを復号する前に、メッセージ内の制御メッセージに従ってインスタンス化されることができる。さらに別の選択肢は、通信チャネルを確立した時などに、通信チャネルに対して固定的にインスタンス化され得る所定のコーデックを使用することでもよい。所定のコーデックは、通信チャネルを経由してメッセージ/データを送信する前に、インスタンス化されることができる。たとえば固定的に設定された符号化/復号が、通信チャネルを経由して転送される全てのデータに対して使用されるものとする場合に、所定のコーデックをインスタンス化する選択肢が好ましいことがある。
第2のフラグを転送されるデータに付加することができ、これは、データが圧縮されたデータである場合に、たとえば第2のフラグをデータメッセージのヘッダに設定することで行われる。これは、復号が必要であることを受信コンポーネントのノードに示して復号が必要であることを受信側で素早く検出できるようにするために、行うことができる。さらに、第2のフラグは、送信側のエンコーダにより使用された符号化タイプ形式を受信側に示すために使用することもできる。
方法は、送信側のエンコーダおよび受信側のデコーダが、通信チャネルの確立時に、および通信チャネルを経由してデータを送信する前に、インスタンス化されることを備えることができる。さらに、符号化/復号のタイプは、予想されるデータタイプ、たとえば音声データまたはビデオデータ、および/または通信チャネルを経由して転送されるデータのサイズに基づいて、通信チャネルに対して固定的に事前設定することができる。したがって、開発者は、特定の通信チャネルに対して、前記通信チャネルを経由して送信されるものとするデータなどに関する自身の知識に基づいて、好適なコーデック形式を設定することができる。たとえば、開発者は、ビデオデータのみが転送されると予想して、ビデオコーデックを指定することがある。このようにして、高速なセットアップ時間を達成することができる。
まとめると、アプリケーション開発者が詳細なコンポーネント制御に取り組む必要がなく、さらに高い柔軟性がアプリケーション設計に与えられることが、本明細書で提示された態様の利点である。利用可能なリソース上でのコンポーネントの最適なインスタンス化を発見する責任があるのはプラットフォームであり、サービスの開発者ではない。これにより、開発者は、サービス実行時に変化することさえある、リソース上へのコンポーネントの配置にもはや注意を払う必要がないので、分散クラウド中心メディアサービスを構築するための開発労力が削減される。
上記で概説された態様が、プロセッサを備えるデータ処理装置において実施可能であることに留意されたい。コンピュータメモリに記憶されたコンピュータプログラム命令は、プロセッサにより実行された場合に、態様を実施することができる。以下では、添付の図面を参照して実施形態がさらに説明される。
分散処理コンポーネントの一例の図である。 パイプライン指向メディアフレームワークの一例の図である。 開示されたシステムの主要な概念の図である。 アプリケーションの自動的に配布された処理コンポーネントの一例の図である。
実施形態が、配布可能なビデオおよび他のマルチメディアアプリケーションをホストするクラウドサーバ、エンドデバイスたとえば携帯電話、ビデオおよびマルチメディアコンテンツを記録または表示可能なネットワークカメラおよび他のエンティティ、実際の規格に準拠したネットワークデバイスと提案された符号化形式を組み込んだプラットフォームサービスとの間の接続点として機能するインターネットゲートウェイにおいて技術的に実装可能であることに留意されたい。
プロプライエタリなクラウド環境への提案された解決方法の基本的な組み込みは、標準化なしで可能なはずであるが、同様の問題が、モバイル端末が計算負荷が高いビデオ処理タスクをネットワーク中心のクラウド環境にオフロードする場合の環境などで当てはまるので、ITU/ISO(MPEG)による潜在的な採用はあり得る。
クラウドベースの処理環境において、特に、別個の処理ノード上で実行される別々のソフトウェアタスクの間の以下のデータ伝送シナリオが適用され得る。1)エンドデバイス(たとえばカメラ、ディスプレイ、スマートフォン)への、およびエンドデバイスから公衆インターネットなどのネットワークの向こう側のメディア処理ノードへのメディアデータ伝送。2)単一のデータセンター内の処理ノード間のメディアデータ伝送。メディア処理は計算が複雑(すなわち高度な処理)であるためにメディア処理タスクが単一の処理ノードから外へ簡単に拡大(scale)するので、このセットアップは行われる。3)たとえばネットワーク内でリソースを伝送して全体のリソース消費を最適化し、たとえばユーザがいる場所の近くに処理を配置してマンマシンインタラクションに関する遅延を制限するために、異なるデータセンター内に配置された処理ノード間のメディアデータ伝送。
本実施形態が、特にケース2)および3)に対処し、エンドデバイスおよびクラウドノードの間の伝送の制御が、たとえばデバイス上で専用のソフトウェアを実行する能力を有することで提供されると仮定したケース1)もカバーすることをここでは留意されたい。
たとえば、サービスプラットフォーム上の分散処理から利益を得る典型的なアプリケーションシナリオは、たとえばビデオチャットである。ビデオチャットのシナリオでは、たとえば、人々のグループが、仮想の共有されたビデオ環境/ビデオチャットルームに参加する。各個人は、自身のカメラのビデオデータをクラウドにストリーミングする。ビデオチャットサービスは、そのような共有環境内に集まっているユーザの全てのメディアストリームを結合し、各参加者に対する仮想ルームの個人用ビューを生成する(すなわち、処理する)。したがって、仮想ルーム内の各個人は、他の参加者の個人用のレンダリングされたビューを受信する。
図1および図2は、コーデック(コーダ(符号化)5およびデコーダ(復号)6)を含む分散コンピューティングノード1への処理コンポーネント3の可能な配布を表す例である。具体的には、図1では、たとえばビデオチャットアプリケーションに関して、どのようにサービス論理およびリソースが、論理的に依存した機能に分割できるかが示されている。可能な配備では、図示されたサービス論理ブロックの各々は、最終的に異なるリソースになり得る。
図2に、パイプライン指向メディアフレームワークを、独立したパイプラインの例示的な詳細と共に示し、各パイプラインは、データ受信機およびエンコーダ/デコーダコンポーネントを、可能な転送ポイントにおいてそれぞれ有している。図2は、具体的には、たとえばカメラ処理、仮想パン/チルト/ズーム、背景抽出、ビデオ混合、および個人用ビューレンダリングなどのコンポーネントなどの異なるアプリケーションタスクを含むサービス論理インスタンス化を示す。
図3に、実施形態によるシステム(プラットフォーム)の主要な設計を示す。好ましい実施形態では、IPベースのインターネット、イーサネット(登録商標)などのネットワークにより接続された少なくとも2つの処理ノード1が、システムに含まれる。システムにより処理されるものとするアプリケーションの処理コンポーネント3は、たとえば、図3の2つの図示のノード1に配布される。言い換えれば、アプリケーションは、複数の部分、たとえば処理コンポーネントまたはサブアプリケーションに分割される。アプリケーション配布機能は、システムのノード1、ここではたとえば、第1のノード1aおよび第2のノード1bに、コンポーネント3を配布する。ノード1の間のデータ交換は、通信チャネル4により可能となる。データ伝送は、たとえば、あるノードから他のノードへメッセージを渡すことで実行されることが好ましい。メッセージは、ヘッダと、ペイロードすなわち送信されるデータとを備えることができる。
より具体的には、メディア処理コンポーネント3をインスタンス化し、修正し、削除するために、各ノード1上で分散処理プラットフォームが実行される。処理コンポーネント(コンポーネント)3は、前記異なるコンポーネント3に分割されるアプリケーションの処理部分である。各コンポーネント3は、プラットフォーム全体で一意の識別子を有する。
たとえば、ビデオチャットアプリケーションは、カメラ信号の前処理、たとえば背景減算、顔または行動検出、たとえば「誰が話しているか」の機能、ユーザが高解像度であり得る現実のカメラのビデオ信号の中を仮想カメラのパン、チルトおよびズーム要素を制御して移動できるようにして低解像度であり得る個人用ビューを生成する対話型モジュール、などのコンポーネントに分割することができる。さらに、コンポーネントは、(全ての参加者に対して「遅延の中心」に配置されることが好ましい)クラウド内の処理リソース上のチャットルーム内の人々の異なるビデオ信号をマージさせるビデオ混合機能、および、エンドユーザの対話型ジェスチャにより制御される、(このユーザの近くに配置された処理リソース上に配置されることが好ましい)個人視点レンダリングとすることができる。
図3は、具体的には、各ノード1が実行環境2を有することを示す。実行環境2は、少なくとも2つのコンポーネント3を、第1のコンポーネント3aの発信すなわちアウトバウンドポートと第2のコンポーネント3bの着信ポートとの間に通信チャネル4をインスタンス化することで接続する手段を有する。そのような接続4は、サービス論理データフローを確立し、ノード上で動作するコンポーネント3の全ての通信チャネル4を記述したテーブルを維持することで、分散された方法で実現することができる。
実施形態では、2つのコンポーネント3の間の新しい接続が、テーブルにエントリを追加することでインスタンス化される。エントリは、どの後続のコンポーネント3が、送信コンポーネント3の発信ポートにより送信される転送データ(たとえばメディアストリーム)の受信コンポーネント3(およびそのポート)であるかを示す。前記テーブルは、プラットフォームにより制御することができる。
さらに、受信コンポーネントが遠隔ノード1に配置されている場合、これは通信チャネル4がノード境界を横断することを意味するが、プラットフォームは、遠隔ホスト(ノード)の識別子を、これはIPアドレスであり得るが、テーブルエントリに追加する。
図3はさらに、2つの可能なシナリオを示す。第1のシナリオは、図3の上部に示されており、ここではアプリケーションの2つのコンポーネント3が両方とも同一のノード1に配置されることが示されている。したがって、実行環境2は、エンコーダ5および/またはデコーダ6をインスタンス化することなく、2つのコンポーネント3の間にローカルな通信チャネル4をインスタンス化する。つまり、送信コンポーネント3aから受信コンポーネント3bに転送されるデータ(ペイロード)は、通信チャネル4を経由して符号化されずに送信されることが好ましい。これにより、コンピューティングリソースが維持される。たとえばヘッダとデータであるメッセージの受け渡しは、メモリ参照により実行することができる。
図3の下部に、受信コンポーネント3bがノード1b内に配置され、ノード1bが、送信コンポーネント3aを含む他のノード1aに対して遠隔で配置されることが図示されている。したがって、通信チャネル4を経由したデータ転送は、たとえばネットワークプロトコルを必要とする。2つのコンポーネント3を遠隔配置する理由は、たとえば、プラットフォームが最初にコンポーネント3を異なるノード1上に配置したこと、または、受信コンポーネント3bが処理中に、あるノード1から他のノード1に移動されたことであり得る。通信チャネル4が確立された後にコンポーネント3を遠隔ノード1に移動させる一例が、図3の上部に示されている。受信コンポーネント3a、3bの再配置は、「コンポーネント移動」の矢印で示されている。
一般的に、送信コンポーネント3aから受信コンポーネント3bへデータが転送されるものとする場合、送信コンポーネント3aは、メッセージタイプ、ペイロード、および、転送されるデータの送信ポートを指定するプラットフォーム機能を呼び出す。
続いて、受信機コンポーネント3bの識別子およびそのポートが、テーブルに対する検索操作を用いて検索される。検索操作は、転送されるメッセージの1つまたは複数の受信者が遠隔ホストに配置されているかを決定するように構成される。メッセージの受信機が送信機と同じホストに配置されている場合、メッセージはノード内部のキューに格納され、最後に対象受信コンポーネントに配信される。メッセージの受信機が遠隔ホストに配置されている場合、メッセージは送信され、遠隔ノード上のキューに格納され、最後に受信コンポーネントメッセージハンドラに渡される。このとき、送信機のポートインデックスは、受信機のポートインデックスと置換され、2つのコンポーネント3が完全に切り離される。したがって、送信コンポーネント3aは、対応するエンドポイント、すなわちメッセージの受信機が配置されている場所を知らず、その理由は、両方のコンポーネント間の唯一のつながりが、実行環境などにより操作されコンポーネント自体がアクセスできないことがあるテーブルに格納された情報により実現されるためである。
プラットフォーム(たとえば、(図3に示されていない)システムの制御ユニット)は、検索操作から、コンポーネント3の間の接続/通信チャネル4がネットワークリンク(2つのノード1の間の境界)を横断するかを認識する。さらに、具体的にはメッセージタイプまたはペイロードサイズを分析することで、データレートによってネットワークリンクの輻輳が生じ得るかを決定することができる。自動圧縮のこの態様は、以下で、特に図3の下部に関してさらに説明される。
最初に、対応するコンポーネント3が遠隔地の処理リソース上で既にインスタンス化されているために接続が確立される場合、または、たとえば負荷分散もしくは他の性能上の理由で、プラットフォームがコンポーネント3を他の処理ノード1に移動させると決定した場合(たとえば図3参照)に、接続が外部となり得ることにさらに留意されたい。
一態様によれば、2つのコンポーネント3の間の通信チャネル4の作成の後、または遠隔ノード1へのコンポーネント3の移動(「コンポーネント移動」)の後に、それぞれのテーブルエントリに関連付けられた第1のフラグが設定される。次のメッセージが通信チャネル4を介して送信され、導入された第1のフラグが設定されている場合、プラットフォームは、メッセージヘッダを解析して、メッセージタイプを決定し、ネットワークへの潜在的な負荷を決定し、対応するメッセージタイプに対する適切なエンコーダを決定するようにする。メッセージヘッダの解析は、具体的には、以下の例示的なシナリオで実行される:通信チャネル4は、同一のノード1上に配置された2つのコンポーネント3の間に既に確立されている。そして、2つのコンポーネント3のうちの少なくとも1つが遠隔ノード1に移動され、第1のフラグがコンポーネント移動を示すために設定される。次のメッセージが通信チャネル4を経由して送信される前に、システムは、設定された第1のフラグにより、通信チャネル4がノード1の境界を通過すること、および、ペイロードデータの符号化が必要となり得ることを検出する。
メッセージが、圧縮モジュールが存在する特定のタイプのものであり、および/または、データが特性のサイズを有する場合に、プラットフォーム(たとえば、システムの制御ユニット)は、符号化/復号が通信チャネル4に対して必要であると決定することができる。さらに、通信チャネル4により接続された2つのノード1のうちの1つ、または2つのノード1のうちの少なくとも1つが特定の作業負荷で動作する場合に、符号化/復号が必要であると決定することができる。
具体的な例は、データがメディアデータ、たとえばビデオまたは音声形式データである場合に、システム(たとえば、システムの制御ユニット)が常にコーデックを初期化することでもよい。
符号化/復号が必要な場合に、および、好ましくはコーデックが転送されるデータのタイプに関して利用可能である場合に、対応するエンコーダ5が初期化され、コーデックをインスタンス化する1つの選択肢に従って、対応するデコーダ6が受信コンポーネント3をホストする遠隔リソース(ノード)1上で通信チャネル4に関して初期化される必要があることを示す制御メッセージが、受信ノード3に送信される。そして、転送される(ペイロード)データは、送信コンポーネント3からエンコーダ5に渡され、符号化される。続いて、符号化されたデータは、エンコーダ5から遠隔側に送信される。転送されるデータを備えるメッセージは、転送データが圧縮されることを示す第2のフラグをさらに備えることができる。受信コンポーネント3を含むノード1において、着信/転送データが符号化されているかを確認することができ、データが符号化されている場合、デコーダ6がインスタンス化され、デコーダ6は、データを復号した後、復号されたデータを受信コンポーネント3に転送する。可能なコーデックは、MPEG−1、MPEG−4、VPS、H.264、H.265、MELP、SILKなどを含むことができる。
上記により、転送されるデータを受信コンポーネント3に適切に渡すために元のデータタイプを維持することができる。たとえば、処理コンポーネントの間のデータ交換用に用いられる元のメッセージタイプのメッセージは、符号化され、それぞれのノードの実行環境の間で交換される新しいメッセージ内にカプセル化される。受信ノードの実行環境は、このメッセージを受信し、含まれている符号化された元のペイロードデータをデコーダへ渡し、元のメッセージタイプのメッセージを生成して受信コンポーネントに転送する。したがって、データ(メッセージ)符号化/復号操作は、処理コンポーネントにとって透過的である。任意選択で、必要なデコーダ6に関する情報を含み、デコーダ6をインスタンス化する必要性を示す制御情報を、符号化された転送されるデータをさらに含むメッセージに挿入することができる。これにより、エンコーダ6が正しく初期化されることを保証するための処理ノード1の間の追加の通信、たとえば別個の制御メッセージの送信などを要求しないようにすることができる。
さらなる態様によれば、エンコーダ5およびデコーダ6は、遠隔接続が確立された場合に(最初のメッセージが送信される前であっても)、初期化される。これを行うことができるのは、アプリケーション開発者が圧縮形式の性質について事前に知っており、これが接続作成システムコールによって示される場合か、または、コンポーネントの形式的記述が、予想されるメッセージタイプおよびトラフィックレートを決定するために分析される場合である。たとえば、ビデオデータのみが特定の通信チャネルを経由して転送されるので、ビデオコーデックたとえばMPEG−4、VP8、H.264またはH.265がこの特定の通信チャネルに関して初期化されるかもしれないことをアプリケーション開発者が予想する、または知っていることがある。結果として、コーデックをインスタンス化するいくつかの代替の選択肢が、本明細書で開示されており、これらは上記でより詳細に説明されている。
図4に、たとえばビデオチャットサービスなどの配備されたアプリケーションの結果を示し、これは、アプリケーションの最適化された分割およびデータの自動符号化、すなわち、上記で説明されたように、データを異なるノード1の間で自動的に符号化して交換できることによって、プラットフォームの極力少数のリソースを使用する。たとえば、図4は、ビデオチャットアプリケーションのパン/チルト/ズーム(PTZ)コンポーネント3が、2つの異なるノード1’、1’’に配布されていることを示す。2つのノードのうちの一方1’は、複雑なコーデックたとえばH.264と、低解像度たとえばVGAとを有するビデオデータを処理する。他方のノード1’’は、高解像度たとえば720pと、単純なコーデックたとえばMP4Vとを有するビデオデータに対するPTZを処理する。両方のPTZ処理ノード1’、1’’は、さらなる別のノード1’’上に配置された背景抽出(BG:background extraction)コンポーネントとの通信チャネル4を確立することができる。さらに、図4の両方のPTZ処理ノード1’、1’’は、通信チャネル4を介して個人用ビュー(PV:personal view)レンダリングを処理するノードにデータを送信することもできる。図4のこの例では、ノード1’’’’は高解像度PVレンダリングを処理するために使用され、さらなるノード1’’’’’は低解像度PVレンダリングを処理するために使用される。低解像度PVレンダリングは多くのコンピューティングリソースを要求しないので、プラットフォームは、図4のこの例では、低解像度PVレンダリングと同一のノード1’’’’’上にビデオ混合コンポーネント3を配置するように決定している。まとめると、図4は、自動的に配布されたビデオチャットアプリケーションの一例を示している。処理コンポーネント3の間のデータ転送は、通信チャネル4を介して実行することができる。たとえば、PTZ処理ノード1’、1’’およびBG処理ノード1’’’の間の、または、PTZ処理ノード1’、1’’およびPVレンダリング処理ノード1’’’’、1’’’’’の間の通信チャネル4について図4に示されるように、通信チャネル4がノード1の境界を通過する場合、システムは、データトラフィックを削減するためにコーデックを自動的にインスタンス化することができる。
まとめると、提案されたノード、システムおよび方法は、分散(クラウドベースの)実行環境におけるメディアアプリケーションの柔軟な配備を可能にする。アプリケーション開発者は、リソース制約を覚えておく必要がなく、サービス論理のみを管理することができる。これは、クラウドが仮想的に単一のリソースとなることを意味する。提案方法およびこの方法を実装するシステムを適用することにより、より粒度の粗い手法、たとえば仮想マシン、またはアプリケーション開発者によって導入される専用のサービスコンポーネントすらを配備することによって実現される手法などに比べて、さらにいっそう効率的にコンピューティングリソースの間でアプリケーションのサービス論理をプラットフォームが分割できるようになるので、全体のリソース利用を改善することができる。これは、既存の解決方法に比べて約30−40%のより高い利用率を実現すると考えられる。サービスおよびアプリケーション開発が簡単化され、その結果、基本となるクラウドプラットフォームが広く採用されることになる。
上記では特定の実施形態により実行される特定の順序の動作を説明しているが、代替的実施形態が、異なる順序で動作を実行する、特定の動作を組み合わせる、特定の動作を重複させるなどしてもよいので、そのような順序が例示的であることは理解されたい。所与の実施形態への本明細書における言及は、記載の実施形態が特定の機能、構造または特徴を含み得ることを示すが、全ての実施形態が特定の機能、構造または特徴を必ずしも含まないことがある。
記述および図面が提案方法およびシステムの原理を例示するものにすぎないことに留意されたい。したがって、本明細書には明示的に説明または図示されていないが、様々な構成を当業者が考案できるであろうことは理解されよう。さらに、本明細書に列挙された全ての例は、主に、提案方法およびシステムの原理と、発明者により当技術の発展に捧げられた概念とを理解する際に読者を補助する教育上の目的のためのものにすぎないことが明らかに意図されており、そのような具体的に列挙された例および条件に限定されないものと解釈されたい。さらに、原理、態様、および実施形態、ならびにこれらの具体例を列挙した本明細書の全ての記述は、それらの均等物を含むものとする。
さらに、様々な上述の方法のステップおよび記載のシステムのコンポーネントが、プログラムされたコンピュータにより実施可能であることに留意されたい。本明細書では、いくつかの実施形態はまた、機械可読またはコンピュータ可読であり機械実行可能またはコンピュータ実行可能な命令のプログラムを符号化するものであって、前記命令が前記上述の方法のステップの一部または全部を実施する、デジタルデータ記憶媒体などのプログラム記憶デバイスを含むものとする。プログラム記憶デバイスは、たとえば、デジタルメモリ、磁気記憶媒体たとえば磁気ディスクおよび磁気テープ、ハードドライブ、または光学的可読デジタルデータ記憶媒体とすることができる。実施形態はまた、上述の方法の前記ステップを実施するようにプログラムされたコンピュータを含むものとする。
加えて、本特許文書に記載の様々な要素の機能を、専用ハードウェア、ならびに適切なソフトウェアと関連してソフトウェアを実行可能なハードウェアを用いて提供できることに留意されたい。これらの機能は、プロセッサにより提供する場合、単一の専用プロセッサ、単一の共有プロセッサ、または一部が共有され得る複数の個別プロセッサにより提供することができる。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行可能なハードウェアを排他的に指すように解釈されるべきではなく、暗黙的に、限定はしないが、デジタル信号プロセッサ(DSP)ハードウェア、ネットワークプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ソフトウェアを記憶するための読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、および不揮発性記憶装置を含むことができる。他のハードウェアも、従来型および/またはカスタム型にかかわらず、同様に含むことができる。
最後に、本明細書の任意のブロック図が概念図を表すことは理解されたい。同様に、任意のフローチャート、流れ図、状態遷移図、疑似コードなどが、実質的にコンピュータ可読媒体に表現可能であって、したがってコンピュータまたはプロセッサにより、そのようなコンピュータまたはプロセッサが明示的に示されていようといまいと、実行可能である様々な処理を表すことは理解されよう。



  1. 制御ユニットであって、
    2つの処理ノード(1)の間の通信チャネル(4)が処理ノード(1)の境界を横断するかを判定するように構成され、通信チャネル(4)が処理ノード(1)のうちの1つの境界を横断する場合に、通信チャネル(4)を経由して転送されるデータの符号化および/または復号が必要かを決定するようにさらに構成された、制御ユニット。

  2. 少なくとも2つの処理ノード(1)を備えるシステムであって、
    ノード(1)が、実行環境(2)および処理コンポーネント(3)を備え、
    各実行環境(2)が、処理コンポーネント(3)の発信ポートおよび異なる処理コンポーネント(3)の着信ポートの間に通信チャネル(4)を確立するための手段を含み、
    請求項1に記載の制御ユニットをさらに備える、
    システム。

  3. 各確立された通信チャネル(4)に関する情報を含むテーブルをさらに備え、
    前記情報が、各通信チャネル(4)に対して、送信コンポーネント(3)および受信コンポーネント(3)のポートを含み、前記情報が、受信コンポーネント(3)が送信コンポーネント(3)と異なるノード(1)内に配置されている場合に識別子をさらに含み、
    識別子が、受信ノード(1)のネットワーク位置を識別する、
    請求項2に記載のシステム。

  4. 前記テーブル内の検索操作により通信チャネル(4)がノード(1)の境界を横断するかを検出するように構成され、
    検索操作が、コンポーネント(3)の再割当を示すエントリが前記テーブルに設定されているかを検出し、および/または、受信コンポーネント(3)のノード(1)の位置を発見するために前記識別子を読み出すように構成された、
    請求項2または3に記載のシステム。

  5. 転送されるデータが所定のサイズを超過した場合に符号化/復号が必要であると決定するようにさらに構成された、請求項2から4の少なくとも1つに記載のシステム。

  6. 転送されるデータが所定のデータタイプを有する場合に符号化/復号が必要であると決定するようにさらに構成され、所定のデータタイプが、好ましくはメディアデータタイプ、たとえば画像データ、音声データ、ビデオデータである、請求項2から5の少なくとも1つに記載のシステム。

  7. 送信および受信ノード(1)の一方または両方が所定の作業負荷で動作する場合に符号化/復号が必要であると決定するようにさらに構成された、請求項2から6の少なくとも1つに記載のシステム。

  8. ノード(1)にわたってアプリケーションの処理コンポーネント(3)を自動的に配布するアプリケーション配布機能をさらに備える、請求項2から7の少なくとも1つに記載のシステム。

  9. 送信処理ノード(1)であって、
    少なくとも1つの実行環境(2)と、
    少なくとも1つの処理コンポーネント(3)と、
    通信チャネル(4)を経由してデータを送信するために受信処理ノード(1)と通信チャネル(4)を介して接続可能な少なくとも1つの発信ポートと
    を備え、
    実行環境(2)が、通信チャネル(4)を確立するように構成され、
    請求項1に記載の制御ユニットを備え、
    符号化が必要であると決定された場合に、エンコーダ(5)をインスタンス化し、インスタンス化されたエンコーダ(5)のタイプに関して受信処理ノード(1)に知らせるように構成された、送信処理ノード。

  10. 受信処理ノード(1)であって、
    少なくとも1つの処理コンポーネント(3)と、
    通信チャネル(4)を経由してデータを受信するために送信処理ノード(1)と通信チャネル(4)を介して接続可能な少なくとも1つの着信ポートと
    を備え、
    請求項1に記載の制御ユニットを備え、
    符号化が必要であると決定された場合に、送信処理ノード(1)においてインスタンス化されたエンコーダ(5)のタイプに関しての情報に基づいて、デコーダ(6)をインスタンス化するように構成された、受信処理ノード。

  11. 少なくとも2つのノード(1)を有するシステム内のデータ通信のための方法であって、
    各ノード(1)が、実行環境(2)および処理コンポーネント(3)を有し、
    各実行環境(2)が、データを送信する処理コンポーネント(3)の発信ポートをデータを受信する処理コンポーネント(3)の着信ポートと通信チャネル(4)を介して接続するための手段を含み、
    通信チャネル(4)がノード(1)の境界を横断するかを判定するステップと、
    ノード(1)の境界が横断されると判定された場合に、通信チャネル(4)を経由して転送されるデータの符号化/復号が必要であるかを決定するステップと、
    符号化/復号が必要であると決定された場合に、送信コンポーネント(3)のノード内のエンコーダ(5)と、受信コンポーネント(3)のノード内のデコーダ(6)とを初期化するステップと、
    転送されるデータを送信コンポーネント(3)からエンコーダ(5)に提供し、エンコーダ(5)内でデータを符号化するステップと、
    符号化されたデータを通信チャネル(4)を経由して受信ノードに送信するステップと
    を備える、方法。

  12. エンコーダ(5)が送信コンポーネント(3)のノードによりインスタンス化された後に、インスタンス化されたエンコーダ(5)のタイプに関する制御情報を含むメッセージが、送信コンポーネント(3)のノードの実行環境(2)から受信コンポーネント(3)のノードの実行環境(2)に送信され、
    デコーダ(6)が、メッセージに含まれる前記制御情報に基づいてインスタンス化される、
    請求項11に記載の方法。

  13. 転送されるデータが、デコーダ(6)をインスタンス化した時に、送信ノードから受信ノード(3)へ通信チャネル(4)を経由して送信される、請求項12に記載の方法。

  14. 転送されるデータが、制御情報も含むメッセージ内で送信される、請求項12に記載の方法。

  15. 送信側のエンコーダ(5)および受信側のデコーダ(6)が、通信チャネル(4)の確立と同時に、および通信チャネル(4)を経由してデータを送信する前に、インスタンス化される、請求項11から14の少なくとも1つに記載の方法。

 

 

Patent trol of patentswamp
類似の特許
データフィード(14)のソースによる再送信を必要としないデータフィードからブロードキャストされたデータユニットを管理することが、ネットワーク(12)の第1のノードにおいて、複数のデータユニットを含むデータフィードの少なくとも一部を受信することと、ネットワークの第2のノードにおいて、データフィードの少なくとも一部を受信することと、第1のノードにおいてデータフィードの受信の中断を判定することと、中断の前に第1のノードによって受信された最後のデータユニットと中断の後に第1のノードによって受信された最初のデータユニットとの間に広がるデータの欠落(504)の範囲を特定することと、第2のノードによって保存された結果(510)に対する要求を第1のノードから送信すること(506)であって、第2のノードによって保存された結果がデータの欠落に対応する、送信することとを含む。
ネットワーク要素(ne)が、会議のためのダイジェストログを格納するように構成されたメモリと、neに関連した複数のうちの第1の参加者からの第1のメッセージを受信するように構成された受信機であって、この第1のメッセージは第1の参加者の署名プロファイルを含む受信機と、受信機とメモリに連結され、第1のメッセージに応じてダイジェストログの第1の更新を実行することによって会議の状態を追跡するように構成されたプロセッサと、プロセッサに連結され、会議にサービスを提供する複数のうちの第1のサービスプロキシに第2のメッセージを送信するように構成された送信機であって、この第2のメッセージは更新されたダイジェストログを示す送信機とを備えている。
ワイヤレス通信のための方法、装置、およびコンピュータプログラム製品が提供される。装置は、関心のあるファイルがサービス内で送信されることを決定し、関心のあるファイルをダウンロードできないことを決定し、ファイル配信イベントの終わりに対応する時間に関心のあるファイルの修復手順をトリガし、時間は、ブロードキャストされたスケジュール記述に含まれる1つまたは複数の情報要素から導出される。
試験事例管理プラットフォームと、「チャット・クランチャ」と、コンタクト・センタ・マネージャと、チャット・クラシファイアと、デスクトップ自動化エンジンとからなる、柔軟性があり、スケーラブルな自動化されたチャット・ベースのコンタクト・センタ試験のためのシステム、ならびにコンタクト・センタのチャット・ベースの対話環境の自動化された試験のため、及び試験結果の報告のためにそのようなシステムを使用するための方法。
本開示は、概して、モバイルネットワークにおける複数のパケットサービスの再開に関する。デバイス、方法、及び/又はシステムは、ユーザ機器を用いて、第1の無線アクセスネットワークとの通信から第2の無線アクセスネットワークとの通信へ切り替えることと、ユーザ機器のプロセッサを用いて、第1の無線アクセスネットワークとの複数のパケットサービスを開始すべくユーザ機器のレジスタを設定することと、ユーザ機器を用いて、第1の無線アクセスネットワークのコアネットワークノードに、第1の無線アクセスネットワークとの通信を少なくとも部分的にレジスタに基づいて再開する要求を送信することとを具備し得る。
ネットワークノード、方法、およびコンピュータプログラム製品が開示される。ワイヤレス通信ネットワークノードの方法は、無線アクセスノードがユーザ機器との通信をサポートできるようにするためのコンテキストの提供要求を、無線アクセスノードから受信することと、ユーザ機器が使用するためにコンテキスト識別子が割り当てられているかを決定し、割り当てられていない場合、ユーザ機器に関するコンテキストの提供要求で使用するためにコンテキスト識別子を割り当てることと、コンテキストをコンテキスト識別子と共に無線アクセスノードに提供することとを備える。このようにして、ワイヤレス通信ネットワーク内の各コンテキストを、特定のユーザ機器に関連付けることができ、これにより、これらのコンテキストが、後で最小限の労力でネットワークにより簡単に識別可能となる。
ネットワーク環境に適応的に対応できる方法及び装置が提供される。上記方法及び装置は、MMT標準の構造で表現されるコンテンツを転送するMMTパケットを処理するスイッチ又はルータのネットワークプロセスでメディアトランスポート(MMT)パケットのフォワーディングのためのパケットディスクリプタを含む。ブロードキャスティングシステムにおけるキュー管理方法は、ムービングピクチャーエクスパーツグループ(MPEG)メディアトランスポート(MMT)パケットを受信するステップと、MMTパケットのヘッダーを取得するステップと、MMTパケットのヘッダーに含まれたビットレートのタイプ値に従ってMMTパケットをキューイングするステップとを含む。
コンテンツは、ブロードキャストネットワークを通じて通信される情報の量を減らし、通信によって消費されるネットワーク帯域幅の量を減らし、通信される個々のオブジェクトに対する厳密なタイミング要件を満たし、各受信機デバイスがその受信機デバイスの過剰な量のバッテリーまたは処理リソースを消費することなくコンテンツを受信し、復号し、レンダリングすることを可能にする方式で、コンテンツを通信するように構成されるコンポーネントを介して、ブロードキャストチャンネルを通じて、かつ/またはブロードキャストネットワークを介して受信機デバイスに配信され得る。
会議システムでの往復待ち時間測定のための外部機能が、提供される。通信システムでの往復待ち時間測定のための外部機能は、コンテンツイベントを生成し、コンテンツイベントを含んだ受信コンテンツストリーム内のコンテンツイベントを検出し、コンテンツイベントの生成と関連付けられた第1の時刻、およびコンテンツイベントの検出と関連付けられた第2の時刻を決定し、第2の時刻と第1の時刻との差に基づき、往復待ち時間を算出する機能を、含み得る。コンテンツイベントは、視覚イベントまたは聴覚イベントであってもよい。これらの機能は、1つまたは複数のモジュールまたは要素を用いて、実装され得る。コンピューティングデバイスが、コンテンツイベントを生成して検出するために、そして、往復待ち時間を算出するために、用いられ得る。モジュールまたは要素の他の様々な配置が、機能を提供するために用いられ得る。
メッセージ認証をもつマルチキャスト・ワイヤレスローカルエリアネットワーク・メッセージのためのシステム、方法、およびデバイスが本明細書に含まれている。本方法は、複数のワイヤレスデバイスの各々のためのメッセージ完全性検査値を決定することを含む。本方法は、ワイヤレスローカルエリアネットワーク上で複数のデバイスの各々にマルチキャストパケットを送信することをさらに含み、マルチキャストパケットが、複数のデバイスの各々の指示と、複数のデバイスの各々のためのメッセージ完全性検査値とを含む。
To top