JP5792138B2

JP5792138B2 - メディアサーバ、処理割当・割込振分方法、処理割当方法及び割込振分方法

Info

Publication number: JP5792138B2
Application number: JP2012208137A
Authority: JP
Inventors: 明伊集院; 和久石谷
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2012-09-21
Filing date: 2012-09-21
Publication date: 2015-10-07
Anticipated expiration: 2032-09-21
Also published as: JP2014064173A

Description

本発明は、メディアサーバで実行される各処理をＣＰＵに割り当てる技術に関する。

音楽や映像等のメディアデータを扱うコンピュータとしてメディアサーバがある。メディアサーバは、内部に記憶されたメディアデータをメディアストリームとしてユーザが使用するユーザ端末に送信することにより、そのユーザに対してメディアサービスを提供する。

このメディアサーバは、一般にユーザ端末との間において、呼（メディアサービスに係る呼）を制御する呼制御信号を送受信する際にはＳＩＰ（Session Initiation Protocol）を使用し、メディアデータそのものを含むメディア処理信号を送受信する際にはＲＴＰ（Real-time Transport Protocol）を使用する。

特にＲＴＰは、メディア通信の品質が劣化するのを防止するため、決められた時間間隔でそのパケットを送信することが要求されている。例えば、音声コーデックとして利用される「Ｇ．７１１ μ−Ｌａｗ」の音声データの場合、通常、２０ｍｓの時間間隔でＲＴＰパケットを順次送信している。

また、今日では、メディアサービスに係るチャネルの単価を低減するため、同時に多くの呼接続を受付可能であるメディアサーバを汎用性の高いプラットフォームで実現することが要求されている。

そのような各要求に対しては、例えば、汎用ＯＳ（Operating System）であるＬｉｎｕｘ（登録商標）等を採用した汎用プラットフォームによって実現可能である。Ｌｉｎｕｘカーネルでは、プロセススケジューリングの中で最も優先度の高いリアルタイムプロセスを用意しており（非特許文献１参照）、ＲＴＰパケットの送信処理をそのプロセスに割り当てることができる。これにより、ＲＴＰパケット送信処理のリアルタイム性を確保しつつ、メディアサーバのチャネル単価を下げることも可能となる。

ここで、メディアサーバのＲＴＰパケット送信処理をリアルタイムプロセスに割り当てた場合のプロセス遷移例を図６に示す。図６は、呼（１）〜呼（４）の呼接続をメディアサーバで同時に受け付けた場合について例示している。

メディアサーバは、呼（１）〜呼（４）の呼接続について、「ＲＴＰパケット送信（ｎ回目）」、「ＲＴＰパケット送信（ｎ＋１回目）」で示すように、連続してＲＴＰパケットを送信するため、ＲＴＰパケット送信処理をリアルタイムプロセスに割り当てて実行する。

高橋浩和、外２名、「Ｌｉｎｕｘカーネル２．６解読室」、ソフトバンククリエイティブ株式会社、第３版、２００７年、ｐ．４３

しかし、ＲＴＰパケット送信処理をリアルタイムプロセスに割り当てた場合であっても、その送信時において、それよりも優先度の低いタイムシェアリングプロセスへの切り替え処理や、ハードウェア割り込み処理（ハードウェアによる強制的な他処理）が発生する可能性がある。

そして、ＲＴＰパケットの送信処理中にそれによるプロセスの中断が発生すると、ＲＴＰパケットの送信処理に要した実際の送信時間と理想的な送信時間とに時間差（送信ジッタ時間）が生じ、その送信ジッタ時間が想定される許容値よりも大きくなる可能性があった。

従って、汎用プラットフォームを採用したメディアサーバで同時に受け付け可能な呼接続数を大きくするには、ＲＴＰパケット送信処理を実行しているプロセスの中断の発生を防止し、送信ジッタ時間を小さくすることが必要であった。

本発明は、上記事情を鑑みてなされたものであり、ＲＴＰパケット送信処理を行うプロセスの中断の発生を防止し、ＲＴＰパケット送信時に生じる送信ジッタ時間を小さくすることを課題とする。

請求項１記載のメディアサーバは、複数のＣＰＵを備えたメディアサーバにおいて、音声、画像、又は映像を記録したメディアデータを記憶しておくデータ記憶手段と、前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを送信するパケット送信手段と、前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記ＲＴＰパケットを送信する送信処理を前記送信用ＣＰＵに割り当て、前記メディアサーバで実行される当該送信処理以外の全ての処理を前記受信用ＣＰＵに割り当てる処理割当手段と、前記メディアサーバで発生したハードウェア割り込み処理を前記受信用ＣＰＵに通知する割込振分手段と、を有することを特徴とする。

本発明によれば、ＲＴＰパケットを送信する送信処理を送信用ＣＰＵに割り当て、メディアサーバで実行される当該送信処理以外の全ての処理を受信用ＣＰＵに割り当て、更に、メディアサーバで発生したハードウェア割り込み処理を受信用ＣＰＵに通知するため、ＲＴＰパケットの送信処理のみを特定のＣＰＵで実行できることから、ＲＴＰパケット送信処理を行うプロセスの中断の発生を防止し、ＲＴＰパケット送信時に生じる送信ジッタ時間を小さくすることができる。

請求項２記載のメディアサーバは、複数のＣＰＵを備えたメディアサーバにおいて、音声、画像、又は映像を記録したメディアデータを記憶しておくデータ記憶手段と、前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを送信するパケット送信手段と、前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記ＲＴＰパケットを送信する送信処理を前記送信用ＣＰＵに割り当て、前記メディアサーバで実行される当該送信処理以外の全ての処理を前記受信用ＣＰＵに割り当てる処理割当手段と、を有することを特徴とする。

本発明によれば、ＲＴＰパケットを送信する送信処理を送信用ＣＰＵに割り当て、メディアサーバで実行される当該送信処理以外の全ての処理を受信用ＣＰＵに割り当てるため、ＲＴＰパケットの送信処理のみを特定のＣＰＵで実行できることから、ＲＴＰパケット送信処理を行うプロセスの中断の発生を防止し、ＲＴＰパケット送信時に生じる送信ジッタ時間を小さくすることができる。

請求項３記載のメディアサーバは、複数のＣＰＵを備えたメディアサーバにおいて、音声、画像、又は映像を記録したメディアデータを記憶しておくデータ記憶手段と、前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを送信するパケット送信手段と、前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記ＲＴＰパケットを送信する送信処理を前記送信用ＣＰＵに割り当てる処理割当手段と、前記メディアサーバで発生したハードウェア割り込み処理を前記受信用ＣＰＵに通知する割込振分手段と、を有することを特徴とする。

本発明によれば、ＲＴＰパケットを送信する送信処理を送信用ＣＰＵに割り当て、メディアサーバで発生したハードウェア割り込み処理を受信用ＣＰＵに通知するため、ＲＴＰパケットの送信処理のみを特定のＣＰＵで実行できることから、ＲＴＰパケット送信処理を行うプロセスの中断の発生を防止し、ＲＴＰパケット送信時に生じる送信ジッタ時間を小さくすることができる。

請求項４記載の処理割当・割込振分方法は、複数のＣＰＵを備えたメディアサーバで行う処理割当・割込振分方法において、音声、画像、又は映像を記録したメディアデータをデータ記憶手段に記憶しておくステップと、前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記メディアデータを送信する送信処理を送信用ＣＰＵに割り当て、前記メディアサーバで実行される当該送信処理以外の全ての処理を前記受信用ＣＰＵに割り当てるステップと、前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを前記送信用ＣＰＵにより送信するステップと、前記メディアサーバで発生したハードウェア割り込み処理を前記受信用ＣＰＵに通知するステップと、を有することを特徴とする。

請求項５記載の処理割当方法は、複数のＣＰＵを備えたメディアサーバで行う処理割当方法において、音声、画像、又は映像を記録したメディアデータをデータ記憶手段に記憶しておくステップと、前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記メディアデータを送信する送信処理を前記送信用ＣＰＵに割り当て、前記メディアサーバで実行される当該送信処理以外の全ての処理を前記受信用ＣＰＵに割り当てるステップと、前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを前記送信用ＣＰＵにより送信するステップと、を有することを特徴とする。

請求項６記載の割込振分方法は、複数のＣＰＵを備えたメディアサーバで行う割込振分方法において、音声、画像、又は映像を記録したメディアデータをデータ記憶手段に記憶しておくステップと、前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記メディアデータを送信する送信処理を送信用ＣＰＵに割り当てるステップと、前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを前記送信用ＣＰＵにより送信するステップと、前記メディアサーバで発生したハードウェア割り込み処理を前記受信用ＣＰＵに通知するステップと、を有することを特徴とする。

本発明によれば、ＲＴＰパケット送信処理を行うプロセスの中断の発生を防止し、ＲＴＰパケット送信時に生じる送信ジッタ時間を小さくすることができる。

メディアサービス提供システムの全体構成図である。メディアサーバの機能説明図である。プロセス・スレッド処理割当動作のフローチャートである。ハードウェア割込振分動作のフローチャートである。メディアサーバにおける処理動作のシーケンスである。メディアサーバにおけるプロセス遷移例の説明図である。

以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。

図１は、メディアサービス提供システムの全体構成を示す図である。メディアサービス提供システムは、メディアサービスを提供するメディアサーバ１と、そのメディアサービスを受ける複数のユーザ端末３と、メディアサーバ１を保守する保守端末５とで主に構成される。但し、保守端末５は、本メディアサービス提供システムにおいて必須の構成要素ではなく、不在の場合もあり、保守を行う際に追加される追加的な構成要素である。

メディアサーバ１は、ユーザ端末３から送信された呼（メディアサービスに係る呼）を接続する呼接続要求に基づいてメディアストリームを送受信するサーバであり、複数のスレッドを並列に処理可能なマルチコアＣＰＵを搭載したコンピュータとＬｉｎｕｘ等の汎用ＯＳとによって構築される。

また、自機内に複数のインタフェース装置を備え、第１のインタフェース装置１６ａを通じて第１の通信ネットワーク７ａを介しユーザ端末３に通信可能に接続され、第２のインタフェース装置１６ｂを通じて第２の通信ネットワーク７ｂを介し保守端末５に通信可能に接続されている。

尚、第１，第２のインタフェース装置１６ａ，１６ｂとしては、例えば、ＬＡＮポート等を備えたＮＩＣ（Network Interface Card）であり、第１，第２の通信ネットワーク７ａ，７ｂとしては、例えば、インターネット、携帯電話網、公衆回線網である。

また、メディアサーバ１を構築しているコンピュータの仕様に応じてそのインタフェース装置を増加又は減少可能であり、第２のインタフェース装置１６ｂを具備せず、第２の通信ネットワーク７ｂが不在の場合、メディアサーバ１は、第１のインタフェース装置１６ａ及び第１の通信ネットワーク７ａを介して保守端末１と通信することも可能である。

次に、メディアサーバ１の機能について説明する。メディアサーバ１は、メディアサービスを提供する際に必要な基本機能を備え、具体的には、呼制御機能部１１ａと、ＲＴＰパケット送信機能部１１ｂと、ＲＴＰパケット受信機能部１１ｃとにより実現される。

呼制御機能部１１ａは、上記呼を制御するための呼制御スレッド（スレッド生成機能部１３により生成。後述する全てのスレッドについても同様。）に基づいて、ユーザ端末３との間で確立される呼接続を制御する機能を有している。更に、その呼接続が確立した場合には、ＲＴＰパケット送信機能部１１ｂに対して、ユーザ端末３へＲＴＰパケットを送信するＲＴＰパケット送信開始指示を送信する機能を有している。

ＲＴＰパケット送信機能部１１ｂは、ＲＴＰパケットを送信するためのＲＴＰパケット送信スレッドに基づいて、呼制御機能部１１ａから送信されたＲＴＰパケット送信開始指示に従い、メモリ等のデータ記憶部１７に蓄積されている音声や映像等（音声、画像、映像のうちいずれも可）の再生用メディアファイルを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットをユーザ端末３に送信する機能を有している。

ＲＴＰパケット受信機能部１１ｃは、ＲＴＰパケットを受信するためのＲＴＰパケット受信スレッドに基づいて、ユーザ端末３から送信されたＲＴＰパケットを受信する機能を有している。更に、ユーザ端末３からメディア情報が送信され、それに基づいて呼制御を行う場合には、呼制御機能部１１に対して呼制御に必要な情報（例えば、ＤＴＭＦ（Dual Tone Multiple Frequency）によるコールフロー制御情報等）を通知する機能を有している。

メディアサーバ１は、このような基本機能以外に、自機の処理動作等を保守・監視する監視機能部１２や、その他の目的のための複数の機能部（不図示）を備えている。その監視機能部１２は、自機を保守・監視するための保守・監視スレッドに基づいて、保守端末４から送信された監視要求を受信し、その応答を監視応答として送信する。

以上説明した各機能は、実際にはプログラムによるプロセス（プログラムの実行単位。１つ以上のスレッドを含む。）によって実行される。例えば、呼制御機能部１１ａが行う呼制御機能は呼制御プロセスによって実行される。

そこで、本実施の形態では、呼制御機能部１１ａにより行う呼制御機能と、ＲＴＰパケット送信機能部１１ｂにより行うＲＴＰパケット送信機能と、ＲＴＰパケット受信機能部１１ｃにより行うＲＴＰパケット受信機能とをそれぞれ実行する各プロセスを総称してメディアサーバ用プロセスといい、そのような基本機能以外の全ての機能（保守・監視機能等）を実行するプロセスをその他プロセスという。

ここで、メディアサーバ１は、メディアサーバ用プロセス内のＲＴＰパケット送信処理を前述したように例えばリアルタイムプロセスに割り当てて実行する。しかし、上記課題欄で既説したように、そのように最も優先度の高いプロセスに割り当てた場合であっても、優先度の低いプロセスへの切り替え処理やハードウェア割り込み処理により、ＲＴＰパケットの送信処理に中断が発生し、その際に生じた送信ジッタ時間が許容値よりも大きくなる可能性がある。

そこで、本実施の形態では、メディアサーバ１は、これまで説明した各機能部１１ａ〜１１ｃ，１２，１３，１７以外に、コア割当機能部１４及び割込振分機能部１５を更に備えている。以下、図２を参照しながら、それら追加された各機能部１４，１５の機能及びその効果について説明する。

コア割当機能部１４は、メディアサーバ１のコンピュータに搭載されている複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、メディアサーバ用プロセスのうち、ＲＴＰパケット送信スレッドを送信用ＣＰＵに割り当て、それ以外のスレッド及びプロセス（呼制御スレッド及びそのプロセス、ＲＴＰパケット受信スレッド及びそのプロセス）を受信用ＣＰＵに割り当てる機能（以下、機能Ａ）を有している（図２の符号Ａ参照）。尚、スレッドとは、ＣＰＵ利用の実行単位をいう。

これにより、ＲＴＰパケットの送信処理のみを特定のＣＰＵで実行でき、それ以外の全ての処理を当該特定のＣＰＵから排除できることから、ＲＴＰパケット送信スレッドがメディアサーバ用プロセス内の他のスレッドやプロセスに切り替わることを防止することができる。

また、コア割当機能部１４は、その他プロセスに含まれるスレッドやそのプロセスを上記受信用ＣＰＵに割り当てる機能（以下、機能Ｂ）を更に有している（図２の符号Ｂ参照）。

これにより、メディアサービスの提供に不要な全ての処理が受信用ＣＰＵで実行されることから、ＲＴＰパケット送信スレッドがその他プロセス内のスレッドやそのプロセスに切り替わることを防止することができる。

割込振分機能部１５は、第１，第２のインタフェース装置１６ａ，１６ｂやその他コンピュータ内の任意の装置等、メディアデータ内で発生した全てのハードウェア割り込み処理を受信用ＣＰＵに通知する機能を有している（図２の符号Ｃ参照）。

これにより、ハードウェア割り込み処理が受信用ＣＰＵで実行されることから、ＲＴＰパケットの送信処理がハードウェア割り込み処理によって中断されることを防止することができる。

以上より、このような機能を有するコア割当機能部１４及び割込振分機能部１５を更に備えたことにより、結果的に、ＲＴＰパケット送信処理を行うプロセスの中断の発生を防止し、ＲＴＰパケット送信時に生じる送信ジッタ時間を小さくすることが可能となる。

尚、コア割当機能部１４による送信用ＣＰＵと受信用ＣＰＵへのＣＰＵの割り当て方法については、例えば、３個以上のスレッドを並列に処理可能なマルチコアＣＰＵを備えたコンピュータを用いた場合、送信用ＣＰＵ及び受信用ＣＰＵとしてそれぞれ２個以上のＣＰＵを割り当てるようにしてもよい。図２では、ＣＰＵ１〜ＣＰＵ８のうち、ＣＰＵ１・ＣＰＵ２を送信用ＣＰＵとして割り当て、ＣＰＵ３〜ＣＰＵ８を受信用ＣＰＵとして割り当てている。

次に、このようなメディアサーバ１で行うプロセス・スレッド処理割当方法及びハードウェア割込振分方法について説明する。ここでは、Ｌｉｎｕｘで既に提供されている以下のような機能を用いるものとする。

（Ｌｉｎｕｘの機能：ｃｇｒｅｄ）
ｃｇｒｕｌｅｓ．ｃｏｎｆファイル内にセットされたパラメータセットに従って、該当のプロセスを指定されたｃｇｒｏｕｐに移動するデーモンである。

（Ｌｉｎｕｘの機能：ｃｇｒｏｕｐ）
プロセスのグループ単位でリソースを割り当ててポリシー制御するカーネル機能である。該当グループのタスク（ｔａｓｋ）に指定されたプロセスが走行するＣＰＵをｃｐｕｓｅｔ．ｃｐｕｓコマンドで指定することができる。

（Ｌｉｎｕｘの機能：ｓｃｈｅｄ＿ｓｅｔａｆｆｉｎｉｔｙ）
スレッドのＣＰＵアフィニティマスクを設定するシステムコールである。プロセス内において当該システムコールを用いてスレッドを呼び出すことにより、スレッドを特定のＣＰＵで走行させることができる。

（Ｌｉｎｕｘの機能：ｉｒｑｂａｌａｎｃｅ）
マルチコアＣＰＵ環境下において、ハードウェア割り込み処理を指定のＣＰＵに分散させるカーネル機能である。ｓｍｐ＿ａｆｆｉｎｉｔｙにＣＰＵのマスク値を記載することにより、ハードウェア割り込み処理を行うＣＰＵを指定することができる。

最初に、図３を参照しながら、プロセス・スレッド処理割当方法について説明する。まず、メディアサーバ１を構築しているコンピュータが、メディアサーバ用プロセスを生成し、更にその他プロセスとして例えば保守・監視プロセス及びＯＳプロセスを生成する（ステップＳ１０１）。

次に、メディアサーバ１のコア割当機能部１４は、ＯＳプロセス以外のプロセスについては、ｃｇｒｅｄを用いて、ｃｇｒｕｌｅｓ．ｃｏｎｆファイル内にセットされたパラメータセットに従い、メディアサーバ用プロセスをｃｇｒｏｕｐＡにセットし、その他プロセス（保守・監視プロセス）をｃｇｒｏｕｐＢにセットする（ステップＳ１０２）。

尚、ｃｇｒｕｌｅｓ．ｃｏｎｆファイルには、メディアサーバ用プロセスのプロセス名がＡとしてセットされ、その他プロセスのプロセス名がＢとしてセットされているものとする。

一方、ＯＳプロセスについては、コンピュータ上で動作しているプロセス監視アプリケーションによる監視処理により当該ＯＳプロセスの生成が検出された際に、そのＯＳプロセスをｃｇｒｏｕｐＢにセットする（ステップＳ１０３）。

次に、コア割当機能部１４は、ｃｇｒｏｕｐのｃｐｕｓｅｔ．ｃｐｕｓコマンドを用いて、ｃｇｒｏｕｐＡを送信用ＣＰＵ及び受信用ＣＰＵに割り当て、ｃｇｒｏｐｕＢを受信用ＣＰＵに割り当てる（ステップＳ１０４）。

次に、コア割当機能部１４は、ｃｇｒｏｕｐＡについては、ｓｃｈｅｄ＿ｓｅｔａｆｆｉｎｉｔｙのシステムコールを用いて、ＲＴＰパケット送信スレッドのみを送信用ＣＰＵに割り当て当該送信用ＣＰＵにより起動・走行させ、それ以外のスレッド（呼制御スレッド、ＲＴＰパケット受信スレッド）を受信用ＣＰＵに割り当て当該受信用ＣＰＵにより起動・走行させる（ステップＳ１０５）。

一方、ｃｇｒｏｕｐＢについては、当該ｃｇｒｏｕｐＢにセットされたその他プロセス（保守・監視プロセス、ＯＳプロセス）を受信用ＣＰＵに割り当て当該受信用ＣＰＵにより起動・走行させる（ステップＳ１０６）。

以上より、コア割当機能部１４の機能Ａについては、ステップＳ１０２（ｃｇｒｅｄのｃｇｒｕｌｅｓ．ｃｏｎｆファイルを用いてメディアサーバ用プロセスをｃｇｒｏｕｐＡに割り当てる処理）と、ステップＳ１０４（ｃｇｒｏｕｐのｃｐｕｓｅｔ．ｃｐｕｓコマンドを用いて送信用ＣＰＵと受信用ＣＰＵとの両方をｃｇｒｏｕｐＡに割り当てる処理）と、ステップＳ１０５（ｓｃｈｅｄ＿ｓｅｔａｆｆｉｎｉｔｙを用いてＲＴＰパケット送信スレッドのみを送信用ＣＰＵに割り当てて走行させると共に、それ以外のスレッド（呼制御スレッド、ＲＴＰパケット受信スレッド）を受信用ＣＰＵに割り当てて走行させる処理）とにより、実現することができる。

また、コア割当機能部１４の機能Ｂについては、ステップＳ１０２（メディアサーバ用プロセス以外のプロセスのうちＯＳプロセスでないものについては、ｃｇｒｅｄのｃｇｒｕｌｅｓ．ｃｏｎｆファイルを用いてｃｇｒｏｕｐＢに割り当てる処理）と、ステップＳ１０３（ＯＳプロセスについては、プロセス監視アプリケーションによって検出され次第当該ｃｇｒｏｕｐＢに割り当てる処理）と、ステップＳ１０４（ｃｇｒｏｕｐのｃｐｕｓｅｔ．ｃｐｕｓコマンドを用いて受信用ＣＰＵをｃｇｒｏｕｐＢに割り当てる処理）と、ステップＳ１０６（ｃｇｒｏｕｐＢのその他プロセスを受信用ＣＰＵで走行させる処理）とにより、実現することができる。

次に、図４を参照しながら、ハードウェア割込振分方法について説明する。これについては、割込振分機能部１５が、ｉｒｑｂａｌａｎｃｅを用いて、ｓｍｐ＿ａｆｆｉｎｉｔｙで送信用ＣＰＵのマスク値を０に指定すると共に、受信用ＣＰＵのマスク値を１に指定しておき（ステップＳ２０１）、ハードウェア割り込み処理が発生した場合には、その割り込み処理をマスク値が１のＣＰＵ（受信用ＣＰＵ）に通知して実行させる（ステップＳ２０２）。これにより、前述した割込振分機能部１５の機能を実現することができる。

次に、図５を参照しながら、メディアサーバ１による呼接続の処理動作について説明する。まず、コア割当機能部１４により、メディアサーバ用プロセス内のＲＴＰパケット送信スレッドのみが送信用ＣＰＵに割り当てられ、それ以外の全てのスレッド及び全てのプロセスが受信用ＣＰＵに割り当てられて、それぞれ実行される（ステップＳ３０１）。

また、そのステップＳ３０１と併行して、割込振分機能部１５により、送信用ＣＰＵに対するマスク値が０に設定され、受信用ＣＰＵに対するマスク値が１に設定される（ステップＳ３０２）。

次に、ユーザ端末３からメディアサービスに係る呼接続要求信号が送信されると、メディアサーバ１は第１のインタフェース装置１６ａで受信し、割込振分機能部１５により、その呼接続要求信号に係るハードウェア割り込み処理はマスク値が１の受信用ＣＰＵに通知され、その信号は当該受信用ＣＰＵに送信される（ステップＳ３０３）。

次に、その受信用ＣＰＵで動作する呼制御スレッドにより、その新たに接続要求された呼についての接続可否が判定され、その判定結果を含む呼接続可否応答信号が要求元のユーザ端末３に送信される（ステップＳ３０４）。以下、呼接続可否の判定結果は接続可とする。

その後、ユーザ端末３から呼接続完了信号が送信されると、ステップＳ３０３と同様に、第１のインタフェース装置１６ａで受信され、割込振分機能部１５により、その呼接続完了信号に係るハードウェア割り込み処理はマスク値が１の受信用ＣＰＵに通知され、その信号は当該受信用ＣＰＵに送信される（ステップＳ３０５）。

次に、呼制御スレッドにより、送信用ＣＰＵで動作するＲＴＰパケット送信スレッドに対して、ＲＴＰパケットをユーザ端末３に送信するためのＲＴＰパケット送信開始指示が送信される（ステップＳ３０６）。

次に、ＲＴＰパケット送信スレッドにより、データ記憶部１７から再生用メディアファイルが読み出され、ＲＴＰのプロトコル形式に変換したＲＴＰパケットが要求元のユーザ端末３に送信される（ステップＳ３０７）。

続いて、ユーザ端末３は呼接続完了信号の送信後にメディアサーバ１に対してＲＴＰパケットを送信することから、ステップＳ３０３と同様に、第１のインタフェース装置１６ａで受信され、割込振分機能部１５により、そのＲＴＰパケット送受信に係るハードウェア割り込み処理はマスク値が１の受信用ＣＰＵに通知され、そのＲＴＰパケットは当該受信用ＣＰＵに送信される（ステップＳ３０８）。

そして、その受信用ＣＰＵで動作するＲＴＰパケット受信スレッドにより、ユーザ端末３から送信されたＲＴＰパケットが受信される（ステップＳ３０９）。

最後に、ユーザ端末３から呼切断要求信号が送信されると、ステップＳ３０３と同様に、第１のインタフェース装置１６ａで受信され、割込振分機能部１５により、その呼切断要求信号に係るハードウェア割り込み処理はマスク値が１の受信用ＣＰＵに通知され、その信号は当該受信用ＣＰＵに送信される（ステップＳ３１０）。

その後、呼制御スレッドにより、ＲＴＰパケット送信スレッドに対して、ＲＴＰパケットの送信を停止するＲＴＰパケット送信停止指示が送信され（ステップＳ３１１）、ユーザ端末３に対して、現在確立されている呼を切断するための呼切断応答信号が送信される（ステップＳ３１２）。

一方、保守端末５からメディアサーバ１を監視するための監視要求信号が送信された場合には、メディアサーバ１は、第１のインタフェース装置１６ａではなく第２のインタフェース装置１６ｂで受信し、割込振分機能部１５により、その監視要求信号に係るハードウェア割り込み処理はマスク値が１の受信用ＣＰＵに通知され、その信号は当該受信用に送信される（ステップＳ４０１）。

以上より、本実施の形態によれば、メディアサーバ１のコンピュータに搭載されている複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、ＲＴＰパケット送信スレッドを送信用ＣＰＵに割り当て、それ以外の全てのスレッド及びプロセスを受信用ＣＰＵに割り当てるため、ＲＴＰパケット送信処理を行うプロセスの中断の発生を防止し、ＲＴＰパケット送信時に生じる送信ジッタ時間を小さくすることができる。

また、本実施の形態によれば、更に、メディアサーバ１で発生した全てのハードウェア割り込み処理を上記受信用ＣＰＵに通知するため、ＲＴＰパケット送信処理を行うプロセスの中断の発生をより確実に防止し、ＲＴＰパケット送信時に生じる送信ジッタ時間を更に小さくすることができる。

最後に、本実施の形態では、マルチコアＣＰＵを搭載したメディアサーバの例としてＬｉｎｕｘを用いた場合について説明したが、Ｌｉｎｕｘ以外であっても、本実施の形態で説明したコア割当機能１４や割込振分機能１５を備えた他のＯＳを用いても実現可能である。例えば、Ｗｉｎｄｏｗｓ（登録商標）であっても、「ＰｒｏｃｅｓｓｏｒＡｆｆｉｎｉｔｙ」や「Ｉｎｔｅｒｒｕｐｔ−ＡｆｆｉｎｉｔｙＰｏｌｉｃｙ」等の機能を用いることにより、同様に実現することができる。

１…メディアサーバ
３…ユーザ端末
５…保守端末
７ａ…第１の通信ネットワーク
７ｂ…第２の通信ネットワーク
１１ａ…呼制御機能部
１１ｂ…ＲＴＰパケット送信機能部
１１ｃ…ＲＴＰパケット受信機能部
１２…監視機能部
１３…スレッド生成機能部
１４…コア割当機能部
１５…割込振分機能部
１６ａ…第１のインタフェース装置
１６ｂ…第２のインタフェース装置
１７…データ記憶部
Ｓ１０１〜Ｓ１０６、Ｓ２０１〜Ｓ２０２、Ｓ３０１〜Ｓ３１２、Ｓ４０１…ステップ

Claims

複数のＣＰＵを備えたメディアサーバにおいて、
音声、画像、又は映像を記録したメディアデータを記憶しておくデータ記憶手段と、
前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを送信するパケット送信手段と、
前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記ＲＴＰパケットを送信する送信処理を前記送信用ＣＰＵに割り当て、前記メディアサーバで実行される当該送信処理以外の全ての処理を前記受信用ＣＰＵに割り当てる処理割当手段と、
前記メディアサーバで発生したハードウェア割り込み処理を前記受信用ＣＰＵに通知する割込振分手段と、
を有することを特徴とするメディアサーバ。
複数のＣＰＵを備えたメディアサーバにおいて、
音声、画像、又は映像を記録したメディアデータを記憶しておくデータ記憶手段と、
前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを送信するパケット送信手段と、
前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記ＲＴＰパケットを送信する送信処理を前記送信用ＣＰＵに割り当て、前記メディアサーバで実行される当該送信処理以外の全ての処理を前記受信用ＣＰＵに割り当てる処理割当手段と、
を有することを特徴とするメディアサーバ。
複数のＣＰＵを備えたメディアサーバにおいて、
音声、画像、又は映像を記録したメディアデータを記憶しておくデータ記憶手段と、
前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを送信するパケット送信手段と、
前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記ＲＴＰパケットを送信する送信処理を前記送信用ＣＰＵに割り当てる処理割当手段と、
前記メディアサーバで発生したハードウェア割り込み処理を前記受信用ＣＰＵに通知する割込振分手段と、
を有することを特徴とするメディアサーバ。
複数のＣＰＵを備えたメディアサーバで行う処理割当・割込振分方法において、
音声、画像、又は映像を記録したメディアデータをデータ記憶手段に記憶しておくステップと、
前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記メディアデータを送信する送信処理を前記送信用ＣＰＵに割り当て、前記メディアサーバで実行される当該送信処理以外の全ての処理を前記受信用ＣＰＵに割り当てるステップと、
前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを前記送信用ＣＰＵにより送信するステップと、
前記メディアサーバで発生したハードウェア割り込み処理を前記受信用ＣＰＵに通知するステップと、
を有することを特徴とする処理割当・割込振分方法。
複数のＣＰＵを備えたメディアサーバで行う処理割当方法において、
音声、画像、又は映像を記録したメディアデータをデータ記憶手段に記憶しておくステップと、
前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記メディアデータを送信する送信処理を前記送信用ＣＰＵに割り当て、前記メディアサーバで実行される当該送信処理以外の全ての処理を前記受信用ＣＰＵに割り当てるステップと、
前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを前記送信用ＣＰＵにより送信するステップと、
を有することを特徴とする処理割当方法。
複数のＣＰＵを備えたメディアサーバで行う割込振分方法において、
音声、画像、又は映像を記録したメディアデータをデータ記憶手段に記憶しておくステップと、
前記複数のＣＰＵを送信用ＣＰＵと受信用ＣＰＵとに分け、前記メディアデータを送信する送信処理を前記送信用ＣＰＵに割り当てるステップと、
前記データ記憶手段から前記メディアデータを読み出して、ＲＴＰのプロトコル形式に変換したＲＴＰパケットを前記送信用ＣＰＵにより送信するステップと、
前記メディアサーバで発生したハードウェア割り込み処理を前記受信用ＣＰＵに通知するステップと、
を有することを特徴とする割込振分方法。