JP2016151872A - リソース選択方法およびリソース選択装置 - Google Patents

Abstract

【課題】メディア信号のコーデックの変換処理に割り当てるリソースを最適化すること。【解決手段】通信中継部１０は、異なる通信網に接続された端末４０Ａ，４０Ｂ間で伝送されるメディア信号のコーデックを変換する必要がある場合、コーデックの変換処理に要する処理負荷を推定し、処理負荷に基づいて変換処理を行う処理リソースを選択する。処理リソースは、仮想サーバ上の仮想リソースと専用サーバ上の物理リソースとが選択可能である。通信中継部１０は、変換前後におけるコーデックの組み合わせが所定の組み合わせの場合には物理リソースを処理リソースとして選択し、所定の組み合わせ以外の場合には仮想リソースを処理リソースとして選択する。【選択図】図２

Description

本発明は、所定の信号処理を実行する処理リソースを選択するリソース選択方法およびリソース選択装置に関する。

近年、ネットワーク機器の仮想化による通信網の仮想化が検討されている（例えば、非特許文献１参照）。すなわち、従来はネットワーク機能ごとに専用の装置を配置して構成している通信網を、汎用サーバ群によるクラウドシステムや汎用転送機器による転送ネットワークを用いて構成する技術が検討されている。
仮想化された通信網では、仮想化されたインスタンス間で物理リソースが共有されることとなり、インスタンスごとの使用リソース分配の最適化がなされると考えられる。

有満秀浩、他６名、「ネットワーク仮想化に向けた技術開発の現状」、ＮＴＴ技術ジャーナル、日本電信電話株式会社、２０１４年５月、Ｖｏｌ２６、Ｎｏ５、６〜９頁

上記ネットワーク機器の一つとして、通信網の境界に設置されるセッションボーダーコントローラ（Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ：ＳＢＣ）がある。
近年、セッションボーダーコントローラは、ＩＰＸ（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｅｔ Ｅｘｃｈａｎｇｅ）のようなＩＰ相互接続網の他、ユニファイドコミュニケーション（ＵＣ：Ｕｎｉｆｉｅｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）やＷｅｂサービス（ＮＷ−ＡＰＩ、ＷｅｂＲＴＣ等）といった様々な市中アプリケーションを活用し、キャリア網の付加価値を向上させる取り組みに利用されている。
例えば、ユニファイドコミュニケーションにおけるＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）はベンダ独自の仕様が多く、接続難易度が高い。このため、セッションボーダーコントローラを使用して差分を経済的に吸収し、接続性を担保している。

セッションボーダーコントローラの機能としては、ＳＩＰ信号の差分吸収処理や、音声や動画等のメディア信号のコーデックの変換処理などがある。このうちコーデックの変換処理は、ＳＩＰ信号の差分吸収処理と比較して処理負荷が大きく、専用のＣＰＵを用いるほど処理性能を必要とする場合がある。
コーデックの変換処理に割り当てられた処理リソースの処理性能が不足する場合、変換処理に要する時間が長くなり、音声通信やビデオ通信のようなリアルタイム通信では通信遅延や品質劣化が生じる可能性がある。

また、同一装置で複数のコーデック変換を実行する場合には、装置の処理特性を考慮する必要がある。一般的にＣプレーン（コントロールプレーン）の信号処理に比べて、Ｕプレーン（ユーザプレーン）の特にコーデック変換処理は重いので、処理速度の向上のために専用のＣＰＵを用いたり、メモリ上にコーデック変換のパターンを記憶させて、同一のコーデック変換のパターンを連続して処理したほうが性能がよくなる。このため、コーデック変換ごとの処理機能部（処理リソース）の割り当てが必要となる。さらに、専用のＣＰＵを用いる装置は、汎用サーバを使用できる仮想化リソースに比べ高価であるため、汎用サーバを用いて仮想化する経済的メリットも大きい。
すなわち、コーデックの変換処理に対する処理リソースの割り当ては、仮想化通信網における課題となり得る。

本発明は、このような事情に鑑みなされたものであり、セッションボーダーコントローラの仮想化に際して、メディア信号のコーデックの変換処理に割り当てるリソースを最適化することを目的とする。

上述の目的を達成するため、請求項１に記載の発明は、異なる通信網に接続された端末間で伝送されるメディア信号のコーデックを変換する必要があるか否かを判定する変換判定工程と、前記コーデックの変換が必要と判定された場合、前記コーデックの変換処理に要する処理負荷を推定し、前記処理負荷に基づいて前記変換処理を行う処理リソースを選択する処理リソース選択工程と、を含むことを特徴とするリソース選択方法とした。

また、請求項６に記載の発明は、異なる通信網に接続された端末間で伝送されるメディア信号のコーデックを変換する必要があるか否かを判定する変換判定手段と、前記コーデックの変換が必要と判定された場合、前記コーデックの変換処理に要する処理負荷を推定し、前記処理負荷に基づいて前記変換処理を行う処理リソースを選択する処理リソース選択手段と、を備えることを特徴とするリソース選択装置とした。

このようにすることで、コーデックの変換処理に見合う処理性能を備えた処理リソースを選択することができ、コーデック変換処理の遅延に起因するメディア信号の通信遅延や品質劣化が生じる可能性を低減することができる。

また、請求項２に記載の発明は、前記処理リソース選択工程において、前記処理負荷の推定を、変換前後における前記コーデックの組み合わせに基づいて行う、ことを特徴とするリソース選択方法とした。

このようにすることで、コーデック変換の処理負荷を容易に推定することができ、迅速に処理リソースを選択することができる。

また、請求項３に記載の発明は、前記処理リソースは、仮想サーバ上の仮想リソースと物理サーバ上の物理リソースとが選択可能であり、変換前後における前記コーデックの組み合わせが所定の組み合わせの場合には前記物理リソースを前記処理リソースとして選択し、前記所定の組み合わせ以外の場合には前記仮想リソースを前記処理リソースとして選択する、ことを特徴とするリソース選択方法とした。

このようにすることで、処理負荷が高いコーデックの組み合わせの場合にはコーデック処理専用の物理リソースを選択し、処理負荷が低いコーデックの組み合わせの場合には汎用の処理リソースを用いることができ、コーデック変換処理を効率的に実行することができる。

また、請求項４に記載の発明は、前記メディア信号の発信側端末から前記処理リソースに前記メディア信号を送信するよう制御する送信先制御工程をさらに含む、ことを特徴とするリソース選択方法とした。

このようにすることで、選択した処理リソースに対して発信側端末から直接メディア信号を送信することができ、メディア信号を効率的に伝送することができる。

また、請求項５に記載の発明は、前記端末はＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）端末であり、前記変換判定工程では、前記ＳＩＰ端末間のセッション開始時に送受信されるＳＩＰ信号から前記コーデックの変換の要否を判定し、前記送信先制御工程では、前記ＳＩＰ信号に記載された前記メディア信号の送信先を前記処理リソースに書き換える、ことを特徴とするリソース選択方法とした。

このようにすることで、メディア信号が発信側端末から送信される前にメディア信号の送信先となる処理リソースを決定することができ、メディア信号を効率的に伝送することができる。

本発明によれば、セッションボーダーコントローラの仮想化に際して、相対的に処理負荷が高いメディア信号のコーデックの変換処理に割り当てるリソースを最適化することができる。

実施の形態にかかる通信中継部が適用されるネットワークの構成を模式的に示す説明図である。 異なる通信網に接続された端末間の通信経路を模式的に示す説明図である。 ＳＩＰ信号のフォーマットの一例を示す説明図である。 通信中継部の機能的構成を示すブロック図である。 コーデックの組み合わせの一例を示す説明図である。 送信先パターンの一例を示す説明図である。 通信中継部における処理手順を示すフローチャートである。

以下に添付図面を参照して、本発明にかかるリソース選択方法およびリソース選択装置の好適な実施の形態を詳細に説明する。
本実施の形態では、異なる通信網を接続する通信中継部１０（図２，図４参照）に対して、本発明にかかるリソース選択方法を適用してリソース選択装置として機能させる場合について説明する。

（実施の形態）
図１は、実施の形態にかかる通信中継部１０が適用されるネットワーク２０の構成を模式的に示す説明図である。
ネットワーク２０は、仮想化されたネットワークシステムであり、汎用サーバ２０２で構成されるクラウドシステムＣおよび汎用転送機器２０４で構成される転送ネットワークＮによって構成される。
クラウドシステムＣでは、従来専用のハードウェアを用いて実現されているネットワーク機能がソフトウェア化され、汎用サーバ２０２上で動作されることにより、ネットワーク２０における制御機能およびサービス機能を実現する。すなわち、従来はネットワーク機器に一体化されていた制御機能と転送機能を分離し、制御機能をソフトウェア化して汎用サーバ２０２で構成されるクラウドシステムＣに集約している。
転送ネットワークＮは、相互に接続された汎用転送機器２０４によって構成される。上述のように制御機能はクラウドシステムＣに集約されているため、汎用転送機器２０４は汎用スイッチなどのように、指定された転送先にデータを転送する機能を有する機器であればよい。

クラウドシステムＣ上には、ネットワーク２０を制御するアプリケーションとしてネットワークコントローラ２２が設けられている。
ネットワークコントローラ２２は、複数の汎用サーバ２０２としてクラウドシステムＣ内に配置されるコンピューティングリソースと、転送ネットワークＮを構成するネットワークリソース（汎用転送機器２０４）の両方を管理、制御する。
ネットワークコントローラ２２は、ネットワーク２０全体のリソースの割当て状況を管理、制御するオーケストレータと、汎用転送機器２０４を制御する転送側コントローラから構成される。

オーケストレータは、ネットワーク２０上で提供されるサービスごとの需要の変動や、サービス事業者からのリソース割当ての要求に応じて、動的にリソースの配分を変更するなどの制御を実施する。
転送側コントローラは、オーケストレータから指示を受けて汎用転送機器２０４で構成される転送ネットワークＮを制御する。ネットワークコントローラ２２と転送ネットワークＮとの間のインターフェースやプロトコル規定はＳｏｕｔｈｂｏｕｎｄ ＡＰＩと呼ばれ、ＯｐｅｎＦｌｏｗなどを適用することができる。

また、ネットワーク２０には、汎用サーバ２０２により実現される仮想サーバ３０およびメディア信号のコーデック変換処理を専門に行う専用サーバ３５が接続されている。仮想サーバ３０および専用サーバ３５は、クラウドシステムＣの一部を構成するものであってもよい。
後述するように通信中継部１０（リソース選択装置）は、コーデック変換処理部１２を実現するリソースを、仮想サーバ３０の仮想リソースとするか、専用サーバ３５の物理リソースとするかを選択する機能を有する。

本実施の形態では、ネットワーク２０に接続された端末４０Ａ，４０Ｂ間の通信を例にして説明する。
本実施の形態では、端末４０Ａ，４０ＢはＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）端末であり、ＳＩＰ信号を用いてセッションを開始させた後、音声データや動画データ、テキストデータなどのメディア信号を相互に伝送してリアルタイム通信を行うものとする。以下、端末４０Ａを発信側（ユーザーエージェント・クライアント）、端末４０Ｂを着信側（ユーザーエージェント・サーバ）とする。

図２は、端末４０Ａ，４０Ｂ間の通信経路を模式的に示す説明図である。
図２では、端末４０Ａと端末４０Ｂとは異なる通信網（通信網Ａおよび通信網Ｂ）に接続している。
通信中継部１０（リソース選択装置）は、異なる通信網（通信網Ａおよび通信網Ｂ）にそれぞれ接続された端末４０Ａ，４０Ｂ間の通信を通信網の境界で中継する。
異なる通信網とは、例えば異なるキャリアがそれぞれ運用するＩＰ電話サービス網同士や、中小規模のエンタープライズが運用する社内網同士、ユニファイドコミュニケーションサービスの相互接続などが挙げられる。

通信中継部１０は、従来のセッションボーダーコントローラに対応する機能部である。セッションボーダーコントローラは、主に以下のような機能を有する。
下記機能のうち、コーデック変換機能については、後述するコーデック変換処理部１２によって実行される。
１．コーデック変換機能
Ｕプレーン（ユーザプレーン、メディア信号をやり取りする機能群）データのコーデックをあわせるために、コーデック変換を実施する機能。
２．ＳＩＰ差分吸収機能
ＲＦＣ３２６１等で規定されるＳＩＰプロトコルの範囲で通信網同士を相互に疎通させるために差分を吸収する機能。すなわち、通信網間でＳＩＰ信号のヘッダ部などに差分が生じた場合に、これを補完する。
３．トポロジハイディング機能
通信網内のネットワーク構成、例えばＩＰアドレスやポート番号などを通信網外に対して隠蔽する機能。
４．ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御機能
通信網間で異なるパケットの優先度（ＤＳＣＰ：Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ）等をあわせる機能。
５．ピンホール制御機能
Ｃプレーン（コントロールプレーン、後述するＳＩＰ信号をやり取りする機能群）で選択された条件でＵプレーンデータを入出力させるためにＵプレーンのポートの開け閉めを行う機能。

通信中継部１０は、通信網Ａおよび通信網Ｂ以外の他の通信網と接続されていてもよい。通信中継部１０は、それぞれの通信網に対して方路ごとのシナリオを設定している。シナリオとは、通信網への入方向および出方向ごとのルール、ＳＩＰヘッダの取扱いルール、各ヘッダのパラメータの取扱いや操作を定義したルール、などによって構成される。具体的には、例えば図６に示す送信先パターン６０２、設定用プロトコル６０４、設定用アドレス６０６、設定用ポート番号６０８、送信先アドレス６１０、送信先ポート番号６１２などを含んでいる。

本実施の形態では、通信中継部１０およびＳＩＰサーバ２１２はクラウドシステムＣ上のアプリケーションとして実現される。
また、コーデック変換処理部１２は、通信中継部１０によって選択された仮想サーバ３０または専用サーバ３５によって実現される。

端末４０Ａ，４０Ｂ間の接続はＳＩＰサーバ２１２（２１２Ａ，２１２Ｂ）を介して行う。図２では、端末４０Ａ，４０Ｂは、それぞれエッジルータ２１４（２１４Ａ，２１４Ｂ）を介してＳＩＰサーバ２１２と接続されている。また、ＳＩＰサーバ２１２（２１２Ａ，２１２Ｂ）は、それぞれの通信網の境界において通信中継部１０と接続している。この経路がＣプレーンである。
なお、図２では１つの通信網に２台のＳＩＰサーバ２１２を図示しているが、ＳＩＰサーバ２１２の設置数は任意である。

端末４０Ａ，４０Ｂ間の接続についてより詳細に説明すると、ユーザエージェントである端末４０Ａ，４０Ｂは、それぞれ起動時に自端末の識別情報やＩＰアドレスを含んだ登録メッセージを、ＳＩＰサーバ２１２へ送信する。ＳＩＰサーバ２１２は、端末４０Ａ，４０Ｂの登録情報をデータベースに記録する。
端末４０Ａが端末４０Ｂに対して音声通話等の発信を行う場合、端末４０Ｂの識別情報を指定した発信メッセージ（ＩＮＶＩＴＥメッセージ）を含むＳＩＰ信号を、ＳＩＰサーバ２１２へ送信する。

ＳＩＰサーバ２１２は、データベースの情報を検索して、指定された識別情報に対応するＩＰアドレスへ発信メッセージを転送する。なお、端末４０Ａ−端末４０Ｂ間に複数のＳＩＰサーバ２１２がある場合、ＳＩＰサーバ２１２間で順次発信メッセージを転送する。
また、通信網Ａと通信網Ｂとの境界では、通信中継部１０が上記ＳＩＰ差分吸収機能によって適宜ＳＩＰ信号の差分を補完する。
発信メッセージを受信した端末４０Ｂは応答メッセージをＳＩＰサーバ２１２へ返し、ＳＩＰサーバ２１２はその応答メッセージを端末４０Ａに転送する。
一連の流れによって、端末４０Ａおよび端末４０Ｂはメッセージ中に含まれていた相手のＩＰアドレスを知ることができる。
このような接続処理の後、端末４０Ａ，４０ＢはＳＩＰサーバ２１２を介さずに、Ｕプレーンを介してメディア信号を直接送り合う。

図３は、ＳＩＰ信号のフォーマットの一例を示す説明図である。
ＳＩＰ信号は、スタートラインとヘッダ情報、空白行を挟んだボディ部に分けられている。ヘッダ情報には、発信側の端末４０Ａを識別する識別子ｓｉｐ：ａｌｉｃｅ＠ａｔｌａｎｔａ．ｃｏｍ、着信側の端末４０Ｂを識別する識別子ｓｉｐ：ｂｏｂ＠ｂｉｌｏｘｉ．ｃｏｍ、メッセージの種類（ＩＮＶＩＴＥ）などが記載される。

また、ボディ部には、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）と呼ばれる記述構文を使い、音声などのメディアストリーミングのＩＰアドレスや圧縮形式といったセッション情報が記載される。
特に、ボディ部の下段から３行目以下（ｃ行、ｍ行、ａ行：符号２０１）については、以下の情報が記載されている。
ｃ行：コネクション情報、自分が受け取りたいメディアのアドレスとポート番号が記載される。
ｍ行：メディア種別
より詳細には以下の情報が記載される。ｍ行は複数行設定可能である。
ｍ＝＜メディア種別＞＜ポート番号＞＜トランスポートプロトコル＞＜メディアフォーマット＞＜０＝ Ｇ．７１１ ｕ−Ｌａｗ、１８＝Ｇ．７２９＞
ａ行：メディア属性（図３ではＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）の属性）
より詳細には以下の情報が記載される。ａ行は複数行設定可能である。
ａ＝ｒｔｐｍａｐ＜ペイロードタイプ＞＜コーデック＞＜サンプリングレート＞

端末４０Ａ，４０Ｂ間の通信開始時には、図３のようなＳＩＰ信号を用いて使用するコーデック等のネゴシエーションを行う。これは、各端末４０Ａ，４０Ｂの仕様や、端末４０Ａ，４０Ｂがそれぞれ接続する通信網の仕様によって、疎通可能なコーデックや帯域などの条件が異なるためである。
発信側の端末４０Ａは、ＩＮＶＩＴＥメッセージに今回の通信で使用するコーデックを指定する。着信側の端末４０Ｂは、指定されたコーデックが使用可能であればＯＫの応答を返す。また、指定されたコーデックが使用できない場合はエラー応答を返す。

なお、本実施の形態では、端末４０Ａ，４０Ｂ間で共通に使用できるコーデックがない場合でも、通信中継部１０のコーデック変換機能により変換をおこなって伝送することが可能である。
接続処理後のメディア信号は、ＳＩＰサーバ２１２を介さない経路、すなわちエッジルータ２１４（２１４Ａ，２１４Ｂ）、コアルータ２１６（２１６Ａ，２１６Ｂ）、およびコーデック変換処理部１２を介する経路で伝送される。この経路がＵプレーンである。

図４は、通信中継部１０の機能的構成を示すブロック図である。
通信中継部１０は、変換判定部１０２（変換判定手段）、処理リソース選択部１０４（処理リソース選択手段）、送信先制御部１０６、制御信号出力部１０８によって構成される。
変換判定部１０２は、端末４０Ａ，４０Ｂ間で伝送されるメディア信号のコーデックを変換する必要があるか否かを判定する。
変換判定部１０２は、端末４０Ａ，４０Ｂ間のセッション開始時に送受信されるＳＩＰ信号からコーデックの変換の要否を判定する。すなわち、ＳＩＰ信号を参照し、端末４０Ａおよび４０Ｂでそれぞれ使用可能なコーデックに一致するものがある場合にはコーデックを変換する必要がないと判定し、一致するコーデックがない場合にはコーデックを変換する必要があると判定する。

なお、それぞれの通信網（通信網Ａ、通信網Ｂ）において、端末４０Ａ，４０Ｂの種別や通信網の条件によって対応可能なコーデックが複数あり、今回利用するコーデックは端末４０Ａ，４０Ｂ間のネゴシエーションによって選択する。すなわち、特定の通信網間においても複数のコーデックの変換パターン（変換前後の組み合わせ）を取り得る。よって、複数の変換パターンの中からいずれの変換パターンを適用するか選択する必要がある。
また、ネゴシエーション時に端末間または通信網で許容できる複数のメディアが指定されることがある。これは、ネゴシエーションの結果、より適切なコーデックを選択できるようにするためであり、コーデック変換を伴う場合にも最も高品質な通信が行えるようコーデックを選択する。通信網間においても複数のコーデックの変換パターン（変換前後の組み合わせ）を取り得る。

処理リソース選択部１０４は、メディア信号のコーデックの変換が必要と判定された場合、コーデックの変換処理に要する処理負荷を推定し、処理負荷に基づいて変換処理を行う処理リソースを選択する。このとき、処理リソース選択部１０４は、例えば変換前後におけるコーデックの組み合わせに基づいて処理負荷を推定する。
上述のように、処理リソースとしては、仮想サーバ３０上の仮想リソースと物理サーバ（専用サーバ３５）上の物理リソースとが選択可能である。
処理リソース選択部１０４は、変換前後におけるコーデックの組み合わせが所定の組み合わせの場合には物理リソースを処理リソースとして選択し、所定の組み合わせ以外の場合には仮想リソースを処理リソースとして選択する。ここで、所定の組み合わせとは、処理負荷が特に大きいコーデック変換の組み合わせである。

図５は、コーデックの組み合わせの一例を示す説明図である。
図５の表５０には、変換前のコーデック５０２、変換後のコーデック５０４、およびこれらの組み合わせに対応するメディア信号の送信先パターン５０６が示されている。
１行目の組み合わせは、Ｇ．７１１ ａ−Ｌａｗでコーデックされていたメディア信号をＧ．７１１ ｕ−Ｌａｗに変換するものである。この場合の送信先パターン（図６参照）はＡが指定されている。
２行目の組み合わせは、Ｇ．７１１ ｕ−Ｌａｗでコーデックされていたメディア信号をＧ．７１１ ａ−Ｌａｗに変換するものである。この場合の送信先パターンもＡが指定されている。
３行目の組み合わせは、Ｇ．７１１ ｕ−Ｌａｗでコーデックされていたメディア信号をＡＭＲ−ＷＢに変換するものである。この場合の送信先パターンはＢが指定されている。
４行目の組み合わせは、ＡＭＲ−ＷＢでコーデックされていたメディア信号をＧ．７１１ ｕ−Ｌａｗに変換するものである。この場合の送信先パターンもＢが指定されている。
５行目の組み合わせは、コーデック変換の必要がない場合であり、この場合の送信先パターンはＣが指定されている。

例えば、送信先パターンＡが割り当てられているＧ．７１１ ａ−ＬａｗからＧ．７１１ ｕ−Ｌａｗへの変換は、送信先パターンＢが割り当てられているＡＭＲ−ＷＢからＧ．７１１ ｕ−Ｌａｗへの変換に比べて処理負荷が小さい。
すなわち、変換前後のコーデックにおけるサンプリングレートや帯域幅が同じであるなど、コーデックの方式が近い場合（Ｇ．７１１ ａ−ＬａｗとＧ．７１１ ｕ−Ｌａｗなど）には、相対的に処理負荷が小さくなる。一方で、Ｇ．７１１ ｕ−ＬａｗとＡＭＲ−ＷＢとの変換などは処理負荷が大きくなる。

処理リソース選択部１０４は、コーデック変換処理の処理負荷が小さい場合（例えば送信先パターンＡ）やコーデック変換が不要な場合（例えばパターンＣ）には、仮想サーバ３０上の処理リソースをコーデック変換処理部１２として選択する。
このとき、処理負荷の大きさに基づいてコーデック変換処理部１２として割り当てるリソース量を変更してもよい。
また、Ｇ．７１１ ｕ−ＬａｗとＡＭＲ−ＷＢの変換など処理負荷が特に大きい場合（例えば送信先パターンＢ）には、専用サーバ３５の物理リソース（専用のＣＰＵやメモリなど、特定のコーデック変換処理を専門に行うリソース）をコーデック変換処理部１２として選択して、通信遅延や品質劣化などが生じないようにする。

なお、いずれかの通信網において、メディア変更やメディア追加がＳＩＰ信号で指定された場合には、メディア信号のコーデック変換の組み合わせの選択を再度実施する。この際、いずれかの通信網の変更によりコーデック変換が必要なくなることもある。また、これによりメディア信号が変更前と異なる経路を経由することがありうる。

図６は、送信先パターンの内容の一例を示す説明図である。
図６の表６０には、送信先パターン６０２、設定用プロトコル６０４、設定用アドレス６０６、設定用ポート番号６０８、送信先アドレス６１０、送信先ポート番号６１２が示されている。
送信先パターン６０２は、図５の送信先パターン５０６に対応する。
設定用プロトコル６０４は、処理リソースに対してメディア信号を送信する際に用いるプロトコルである。
設定用プロトコル６０４が選択されると、発信側の端末４０は予め備えているプロトコルスタックを利用して処理リソースへ送信する。

設定プロトコルとしては、ＳＤＮ（Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋ）で用いられるＯｐｅｎＦｌｏｗやＮＦＶ（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎｓ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）などを用いることができる。これらのプロトコルを用いることによって、仮想化されたネットワーク２０において、パケットの受信側端末のアドレスとポート番号をネットワークコントローラ２２に設定することで、所望の処理リソースを経由して受信側の端末４０Ｂに送信することができる。
実際には、仮想化ネットワークでは、通信網の入口となる装置に流入パケットを判別する判別手段を設けて流入パケットを監視し、流入パケットがメディア信号の場合にコーデック変換処理部１２として選択された処理リソースへと誘導する。
誘導にはＭＰＬＳ（Ｍｕｌｔｉ Ｐｒｏｔｏｃｏｌ Ｌａｂｅｌ Ｓｗｉｔｃｈｉｎｇ）のパスやＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）、タグＶＬＡＮ（Ｖｉｒｔｕａｌ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などが用いられる。

設定用アドレス６０６には、汎用転送機器２０４がネットワークコントローラ２２との接続に用いるインターフェースに割り振られたＩＰアドレスが指定される。設定用ポート番号６０８には、汎用転送機器２０４がネットワークコントローラ２２からの制御信号を受信する際の受信ポートが指定される。
送信先アドレス６１０には、コーデック変換処理部１２として選択された処理リソースのＩＰアドレスが指定される。送信先ポート番号６１２には、コーデック変換処理部１２として選択された処理リソースでのメディア信号の受信ポートが指定される。

なお、コーデック変換処理部１２として選択された処理リソースとの間にＮＡＰＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｐｏｒｔ Ｔｒａｎｓｌａｔｉｏｎ）装置が中継している場合には、送信先アドレス６１０および送信先ポート番号６１２としてＮＡＰＴ装置の手前にある機器を指定する必要がある。

複数のコーデック変換パターンを同一の処理リソース（装置）で実施する場合は、当該複数のコーデック変換パターンに対して同じ送信先パターンを設定すればよい。
また、その場合に、処理リソース側の都合でそれぞれのコーデック変換パターンに用いるコーデック変換処理の手順が異なる場合には、それぞれのコーデック変換パターンに対して異なる設定用ポート番号６０８を指定する必要がある。

図４の説明に戻り、送信先制御部１０６は、メディア信号の発信側端末から処理リソース選択部１０４で選択された処理リソースにメディア信号を送信するよう制御する。
送信先制御部１０６は、着信側端末から発信側端末に返信されるＳＩＰ信号を送信用パターンに沿って編集する。例えば、メディア信号の送信先にコーデック変換処理部１２として選択された処理リソースのＩＰアドレスやポート番号を記載する。
コーデック変換処理部１２として仮想サーバ３０上の処理リソースが指定された場合、仮想サーバ３０のコントローラにメディア信号が流入すると、ＳＩＰ信号に基づいてコーデック変換処理部１２として選択された処理リソースで処理されることになる。
また、コーデック変換処理部１２として専用サーバ３５が指定された場合、ＳＩＰ信号から抽出されたメディア信号の送信先設定により、メディア信号がルーティングされる。この設定は、ＳＩＰ端末である端末４０Ａ，４０Ｂだけではなく、ＨＧＷ（Ｈｏｍｅ ＧａｔｅＷａｙ）やＳＩＰサーバ２１２とエッジルータ２１４によって実施される場合もある。

コーデック変換処理部１２の受信ポート設定は、ポート番号まで明示的に指定する場合もあるが、Ｍｅｇａｃｏプロトコル（Ｈ２４８．１）を用いている場合、ＭＧからＭＧＣに対して、ｌａｔｃｈ指定することによって、ソース情報を用いて通信することができる。Ｒｅｌａｔｃｈ指定されると、発信者のソースポート番号が変化したときに、あわせてポート番号を変更することができる。

制御信号出力部１０８は、コーデック変換処理部１２として選択された処理リソースに対して、メディア信号のコーデック変換処理を実行するよう制御信号を送信する。

図７は、通信中継部１０における処理手順を示すフローチャートである。
図７のフローチャートにおいて、通信中継部１０は、上流側のＳＩＰサーバ２１２からＳＩＰ信号を取得する（ステップＳ７００）。
通信中継部１０は、取得したＳＩＰ信号を参照して通信の方路が特定されているか否かを判断する（ステップＳ７０２）。
方路が特定されていない場合は（ステップＳ７０２：Ｎｏ）、通信中継部１０は、エラー応答を選択して（ステップＳ７０４）、エラー応答を記載したＳＩＰ信号を上流側のＳＩＰサーバ２１２へと送信する（ステップＳ７１８）。

一方、方路が特定されている場合（ステップＳ７０２：Ｙｅｓ）、通信中継部１０は、方路ごとのシナリオを取得して（ステップＳ７０６）、メディア信号のコーデック変換が必要か否かを判断する（ステップＳ７０８）。
メディア信号のコーデック変換が不要な場合は（ステップＳ７０８：Ｎｏ）、通信中継部１０は、メディア信号の送信先として送信先パターンＣを指定する（ステップＳ７１０）。送信先パターンＣは、仮想サーバ３０上の処理リソースを指定する。なお、送信先パターンを指定するとは、図６に示す各種の設定を反映させてＳＩＰ信号を書き換えることを指す。

また、メディア信号のコーデック変換が必要な場合（ステップＳ７０８：Ｙｅｓ）、通信中継部１０は、変換前後のコーデックが所定の組み合わせか否かを判断する（ステップＳ７１２）。ここで、所定の組み合わせとは、ＡＭＲ−ＷＢとＧ．７１１ ｕ−Ｌａｗとの間の変換など、予め指定された変換時の処理負荷が高いコーデックの組み合わせである。
変換前後のコーデックが所定の組み合わせの場合（ステップＳ７１２：Ｙｅｓ）、通信中継部１０は、送信先パターンＢを指定する（ステップＳ７１４）。送信先パターンＢは、専用サーバ３５上の処理リソースを指定するパターンである。
また、変換前後のコーデックが所定の組み合わせではない場合（ステップＳ７１２：Ｎｏ）、通信中継部１０は、送信先パターンＡを指定する（ステップＳ７１６）。送信先パターンＡは、仮想サーバ３０上の処理リソースを指定するパターンである。
その後、通信中継部１０は、指定した送信先パターンを反映したＳＩＰ信号を下流側のＳＩＰサーバ２１２へと送信して（ステップＳ７１８）、本フローチャートの処理を終了する。
なお、いずれかの通信網において、メディア変更やメディア追加がＳＩＰ信号で指定された場合には、通信中継部１０は、受信したＳＩＰ信号の指定に基づき、コーデック変換が必要か否かの判定処理、および、送信先パターンの選択処理をその都度実施する。よって、コーデック変換が必要なくなった場合等にも対応することができる。

以上説明したように、実施の形態にかかる通信中継部１０によれば、コーデックの変換処理に見合う処理性能を備えた処理リソースを選択することができ、コーデック変換処理の遅延に起因するメディア信号の通信遅延や品質劣化が生じる可能性を低減することができる。
また、本実施の形態では、ＳＩＰ端末に本発明を適用しており、メディア信号が発信側端末から送信される前にメディア信号の送信先となる処理リソースを決定することができ、メディア信号を効率的に伝送することができる。
さらに、本実施の形態にかかる通信中継部１０によれば、（１）処理リソースにより実現手段が異なり処理特性があること、（２）処理リソースの選択により、同一のコーデック変換のパターンを連続して処理するようにし効率を高めること、（３）専用のＣＰＵを用いる装置は、汎用サーバを使用できる仮想化リソースに比べ経済的に効果であること、のそれぞれを考慮して、コーデックの組み合わせごとに送信先パターンを設定し、処理リソースを選択することが可能となる。

なお、本実施の形態では、シグナリングプロトコルとしてＳＩＰを用いた場合について説明したが、これに限らず、例えばＸＭＰＰ（ｅＸｔｅｎｓｉｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｐｒｏｔｏｃｏｌ）を用いることができる。この場合、メディア信号の通信については、ＳＴＵＮ（Ｓｉｍｐｌｅ Ｔｒａｖｅｒｓａｌ ｏｆ ＵＤＰ ｔｈｒｏｕｇｈ ＮＡＴｓ）、ＩＣＥ（Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ）、ＴＵＲＮ（Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙ ＮＡＴ）などを利用して送信先アドレスやポート番号を交換することができる。ホームネットワークであれば、ＷＡＮ側のアドレスおよびポート番号が対応する。

１０ 通信中継部（リソース選択装置）
１０２ 変換判定部（変換判定手段）
１０４ 処理リソース選択部（処理リソース選択手段）
１０６ 送信先制御部
１０８ 制御信号出力部
１２ コーデック変換処理部
２０ ネットワーク
２０２ 汎用サーバ
２０４ 汎用転送機器
２１２ ＳＩＰサーバ
２１４ エッジルータ
２１６ コアルータ
２２ ネットワークコントローラ
３０ 仮想サーバ
３５ 専用サーバ
４０Ａ，４０Ｂ 端末
Ｃ クラウドシステム
Ｎ 転送ネットワーク

Claims (6)

1. 異なる通信網に接続された端末間で伝送されるメディア信号のコーデックを変換する必要があるか否かを判定する変換判定工程と、
   前記コーデックの変換が必要と判定された場合、前記コーデックの変換処理に要する処理負荷を推定し、前記処理負荷に基づいて前記変換処理を行う処理リソースを選択する処理リソース選択工程と、
   を含んだことを特徴とするリソース選択方法。
2. 前記処理リソース選択工程において、前記処理負荷の推定を、変換前後における前記コーデックの組み合わせに基づいて行う、
   ことを特徴とする請求項１に記載のリソース選択方法。
3. 前記処理リソースは、仮想サーバ上の仮想リソースと物理サーバ上の物理リソースとが選択可能であり、
   変換前後における前記コーデックの組み合わせが所定の組み合わせの場合には前記物理リソースを前記処理リソースとして選択し、前記所定の組み合わせ以外の場合には前記仮想リソースを前記処理リソースとして選択する、
   ことを特徴とする請求項２に記載のリソース選択方法。
4. 前記メディア信号の発信側端末から前記処理リソースに前記メディア信号を送信するよう制御する送信先制御工程をさらに含む、
   ことを特徴とする請求項１から３のいずれか１項に記載のリソース選択方法。
5. 前記端末はＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）端末であり、
   前記変換判定工程では、前記ＳＩＰ端末間のセッション開始時に送受信されるＳＩＰ信号から前記コーデックの変換の要否を判定し、
   前記送信先制御工程では、前記ＳＩＰ信号に記載された前記メディア信号の送信先を前記処理リソースに書き換える、
   ことを特徴とする請求項４に記載のリソース選択方法。
6. 異なる通信網に接続された端末間で伝送されるメディア信号のコーデックを変換する必要があるか否かを判定する変換判定手段と、
   前記コーデックの変換が必要と判定された場合、前記コーデックの変換処理に要する処理負荷を推定し、前記処理負荷に基づいて前記変換処理を行う処理リソースを選択する処理リソース選択手段と、
   を備えることを特徴とするリソース選択装置。

Images