(57)【要約】【課題】本発明はＩＰネットワークとマルチメディア携帯端末網との接続点に設けられたマルチメディアゲートウェイにおける音声・動画調整方式に関し，ＩＰネットワークからの音声と動画を６４Ｋｂｐｓの速度の一定周期のフレームで多重化して伝送する場合に音声と動画を最適なレートに調整することを目的とする。【解決手段】多重化処理部は多重化データを生成する制御を行うスケジューラと各固定長内の音声レートと動画レートの組み合わせのデータを格納する多重化テーブルを備える。携帯端末への送信用に音声レートを最低レートとし残りの容量を動画とオーバヘッド用とするよう多重化テーブルを設定し，スケジューラは，多重化テーブルの音声レートのデータと動画レートを使用して多重化データを生成するよう構成する。【選択図】図１
2006074555.tif 000002
【特許請求の範囲】
【請求項１】
音声・動画の送受信が可能な携帯端末が収容されたマルチメディア携帯端末網とマルチメディア配信サーバが接続されたＩＰネットワークとの接続点に設けられ，配信サーバからのＩＰ対応の音声パケットと画像パケットを終端して音声信号をマルチメディア携帯端末網のＡＭＲ（適応可変レート）の音声データに変換し，画像パケットを終端して動画データを取り出して，音声データと動画データ及びオーバヘッドを６４Ｋｂｐｓの速度で固定長の多重化データに組み立てて前記マルチメディア携帯端末網に一定周期で出力する多重化処理部を備えたマルチメディアゲートウェイにおける音声・動画調整方式において，
前記多重化処理部は多重化データを生成する制御を行うスケジューラと，前記各固定長内の音声レートと動画レートの組み合わせが格納された多重化テーブルとを備え，
各携帯端末への送信用に前記多重化テーブルに音声レートを最低レートとし残りの容量を動画とオーバヘッド用とするよう多重化テーブルに設定し，
前記スケジューラは，前記多重化テーブルの前記音声レートのデータと前記動画レートを使用して多重化データを生成することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【請求項２】
請求項１において，
前記多重化処理部に生成された多重化データを格納する多重化データ格納部の空き領域を検出する手段を備え，
前記空き領域を検出する手段により空き領域を検出すると，前記スケジューラは前記マルチメディア携帯端末網のＡＭＲの音声データに変換する手段に対して，前記最低レートの音声レートを前記空き領域を満たす分だけ増大させるよう制御することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【請求項３】
請求項１において，
音声受信特性や受信環境条件に応じて特定の音声レートを保持する必要がある携帯端末について，該携帯端末のチャネル別に多重化テーブルに前記特定の音声レートを設定し，
前記スケジューラは，前記一定間隔毎に動画を多重する際に前記多重化テーブルの該当チャネルに設定された音声レートにより調整することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【請求項４】
請求項１において，
配信サーバからのＩＰ対応の画像パケットを終端した動画データを保持するチャネル対応の動画バッファを備え，各チャネルに対応して多重化変更閾値を設定した多重化変更閾値保持部を設け，
前記スケジューラは，各チャネルの動画レートが増大して対応して設定された前記多重化変更閾値を越えたことを検出すると，アダプテーションレイヤのオプションのオーバヘッドを少なくして動画のレートを増加させることを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【請求項５】
請求項１において，
前記多重化処理部に，音声の品質評価用のデータを発生する音声評価用データ発生部を設け，
前記スケジューラは，音声データと動画データ及びオーバヘッドを組み立てる際に，前記多重化データを出力する前記一定周期の複数回に一回の割合で前記音声評価用データ発生部のデータを多重化して出力し，
前記スケジューラは，前記携帯端末側から前記音声評価用データを用いた音声評価の結果を受け取ると，その音声評価の結果に応じて携帯端末への前記多重化データの音声レートを調整することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，ＩＰネットワークと６４Ｋｂｐｓベースの３Ｇ−３２４Ｍ（３ＧＰＰ）上で音声／動画の送受信が可能なマルチメディア携帯端末網との接続地点に設けられたマルチメディアゲートウエイにおける音声・動画調整方式に関する。
【背景技術】
【０００２】
近年，携帯電話技術の進歩により，従来型の音声主体である第２世代の携帯通信から，音声と動画を融合させた第３世代の通信へと移行が進んでいる。中でも，第３世代（３Ｇ）の移動体通信システムの標準化プロジェクトによる標準規格として，Ｗ−ＣＤＭＡ（Wideband Code Division Multiple Access :広帯域符号分割多重接続) を採用したキャリアは，３ＧＰＰ（３rd Generation Partnership Project)に準拠し，３ＧＰＰ規格で制定されたオーディオビジュアル通信の規格として３Ｇ−３２４Ｍという規格が採用されている。その３Ｇ−３２４Ｍの規格では，映像データはＭＰＥＧ−４（Moving Picture Experts Group：国際標準化機構ＩＳＯが定めた低速回線用の符号化技術と高度な動画フォーマットに対応する符号化方式）またはＨ．２６３（ＩＴＵ−Ｔが勧告した, 低い伝送速度のテレビ会議やテレビ電話のための映像の圧縮符号化方式）が用いられ，音声データはＡＭＲ（Adaptive Multi Rate ：適応型多レート方式）の符号化方式が採用されている。
【０００３】
３ＧＰＰを利用したマルチメディア通信は，６４Ｋｂｐｓという限られた帯域内で音声と動画を多重することにより通信が可能なため，より効率的なマルチメディア通信の技術として脚光を浴びている。
【０００４】
更に，近年のＩＰ網の爆発的普及により，安価なＩＰネットワークを利用したマルチメディア通信も盛んであり，これらＩＰ網と３Ｇ−３２４Ｍを利用した携帯網とを接続したマルチメディアサービスも普及の兆しをみせてきている。ところが，ＩＰ網と３Ｇ−３２４Ｍを用いた携帯通信網との接続で問題となるのが，ＩＰ網側の６４ＫｂｐｓのＧ．７１１（ITU-T の音声符号化方式の勧告の一つで，ＰＣＭ方式により音声を８ＫＨｚでサンプリングし，各サンプルを８ビットで表し，６４Ｋｂｐｓの伝送速度を実現する方式）に変換された音声とＭＰＥＧ４またはＨ．２６３により符号化された動画を，音声品質・画質の高いレベルを維持しつつ，どのようにして６４Ｋｂｐｓの３Ｇ−３２４Ｍに多重化するかという点である。
【０００５】
一般に，３Ｇ−３２４Ｍ上では，音声については圧縮された音声符号化方式であるＡＭＲを，動画についてはＭＰＥＧ４又はＨ．２６３を用いるのが一般的である。ＡＭＲは複数のレートからなる可変符号化方式であるため，３Ｇ−３２４Ｍの最大レートである６４Ｋｂｐｓ内に音声と動画を多重するためには，音声が最低レート時には動画レートを大きく，音声が最高レート時には動画レートを小さくするという，音声と動画の質が相反することになる。
【０００６】
このように従来方式では，６４Ｋｂｐｓという限られた音声・動画のレートをあらかじめ決められたレートで設定していたため，一方を高くすれば他方が低くなるという弊害が発生していた。
【０００７】
図１３は従来のマルチメディアゲートウェイを含むシステムの構成を示す。図中，８０はマルチメディア携帯端末，８１は３Ｇ−３２４Ｍ又はＨ２６３を用いた符号化方式により音声・動画の伝送を行うマルチメディア携帯端末網，８２はマルチメディア携帯端末網８１とＩＰネットワークとの間に設けられ，２つのネットワークの端末またはサーバ間でマルチメディアの情報を相互に伝送するマルチメディアゲートウェイ，８３はＳＩＰ（Session Initiation Protocol:ＩＰネットワーク上でセッションを開始，編集，終了するためのシグナリングプロトコルの処理を行うサーバ）やＭＥＧＡＣＯ（Media Gateway Control:メディアゲートウェイを制御するプロトコルの処理を行う装置) を制御してＩＰネットワーク上で音声，映像の呼制御を行うコール・エージェント（ＣＡ:Call Agent)，８４はＩＰ（Internet Protocol)による通信を行うＩＰネットワーク，８５はＩＰネットワークに接続されて音声，動画等のマルチメディアの情報を配信するマルチメディア配信サーバである。
【０００８】
図１３に示すように，マルチメディア携帯端末８０は音声だけでなく動画を双方向に送受信する機能を備え，マルチメディア携帯端末網８１に収容されたマルチメディア携帯端末８０同士は３Ｇ−３２４Ｍの規格により音声，映像による相互通信が行われる。また，マルチメディア携帯端末８０に対してＩＰネットワーク８４に接続されたマルチメディア配信サーバ８５からマルチメディア情報である音声と動画を配信するサービスが実現されている。その場合，マルチメディア配信サーバ８５からは音声と動画の情報が，音声パケット８５ａと動画パケット８５ｂという分離した形態でＩＰネットワーク８４に送信される。音声パケット８５ａは，ＩＰ／ＵＤＰ（IPの上位のUser Datagram Protocolで相手先アプリケーション情報を含む) ／ＲＴＰ（Realtime Transport Protocol ：実時間伝送プロトコル) ／Ｇ．７１１( 音声を８ＫＨｚでサンプリングしてディジタル化した６４Ｋｂｐｓの信号に対応した符号化方式）のプロトコル及び符号化方式に対応したパケットである。動画パケット８５ｂは，ＩＰ／ＵＤＰ／ＲＴＰのプロトコルを使用する点は音声と共通（ヘッダ中に音声と画像を識別する情報が含まれる）であるが，符号化方式としてＭＰＥＧ４またはＨ２６３が使用される。これらの音声と動画のパケットはＩＰネットワーク８４の同じルートを交互に通ってマルチメディアゲートウェイ８２に入力する。
【０００９】
図１４は本発明の対象となるマルチメディアゲートウェイの構成を示す。図１４にはＩＰ網からマルチメディア端末へ送信する下り方向の信号を伝送する機構と，マルチメディア端末からＩＰ網へ送信する上り方向の信号を伝送する機構とがある。図中，下り方向の機構の８２０ａはＩＰ網からのＩＰ／ＵＤＰ／ＲＴＰ／Ｇ．７１１に対応する音声パケットを終端する音声パケット終端部，８２０ｂはＩＰ網からの動画パケットを終端する動画パケット終端部，８２１ａ，８２１ｂはそれぞれ音声データ，動画データのジッタバッファ，８２２は音声のＣＯＤＥＣ処理部，８２３は音声バッファ，８２４は音声バッファ８２３の音声データとジッタバッファ８２１ｂの動画データを多重化して３Ｇ−３２４Ｍ規格（６４Ｋｂｐｓ）のフレームに変換する３Ｇ−３２４Ｍ処理部である。上り側の機構である８２５はマルチメディア端末からの音声，動画を含むフレームを終端して分離する３Ｇ−３２４Ｍ終端部，８２６ａはＨ．２４５（エンド・ツウ・エンドの通信制御のプロトコル）による呼制御情報を処理するＨ．２４５処理部，８２６ｂは音声データを抽出する音声抽出部，８２６ｃは動画データを抽出する動画抽出部，８２７は呼制御情報を受け取ってＭＥＧＡＣＯを用いたＣＡ（図１３の８３）との通信による呼制御を行うＣＰＵ，８２８は３Ｇ−３２４Ｍ側の音声データ（ＡＭＲの符号化）を受け取って，Ｇ．７１１の符号化の信号に変換するＣＯＤＥＣ，８２９はＣＯＤＥＣ８２８からの音声データと動画抽出部８２６ｃから動画データを入力して，ＩＰ／ＵＤＰ／ＲＴＰ／Ｇ．７１１の規格による音声（ＲＴＰ）パケットとＩＰ／ＵＤＰ／ＲＴＰ／ＭＰＥＧ４またはＨ．２６３の規格による動画（ＲＴＰ）パケットとに分割して，送出するＩＰパケット化部である。
【００１０】
マルチメディア携帯端末網（図１３の８１）から入力される６４Ｋｂｐｓの３Ｇ−３２４Ｍデータは，３Ｇ−３２４Ｍ終端部８２５で，音声（ＡＭＲ）８２６ｂ，動画（ＭＰＥＧ４又はＨ．２６３）８２６ｃ，データ（Ｈ．２４５対応の呼制御データ）８２６ａに分離され，音声はコーデック８２８でＡＭＲの圧縮符号からＧ．７１１の圧縮符号に変換され，データ（Ｈ．２４５）は，ＮＳＲＰ（Numbered Simple Retransmission Protocol:番号付け再送手順プロトコル) 及びＣＣＳＲＬ(Control Channel Segmentaion and Reassembly Layer:制御チャネルセグメント化と組立レイヤ）が終端された後，ＣＰＵ８２７に転送され，ＣＰＵはＭＥＧＡＣＯからの制御内容と連携して，Ｈ．２４５のネゴシエーションを行う。Ｇ．７１１に変換された音声はＩＰパケット化部８２９でＲＴＰパケット化（ＩＰ／ＵＤＰ／ＲＴＰ化）された後，ＩＰネットワーク上に転送される。また，動画については，コーデック処理されずそのままの形でＩＰパケット化部８２９でＲＴＰパケット化（ＩＰ／ＵＤＰ／ＲＴＰ化）されてＩＰネットワーク上に転送される。
【００１１】
一方，マルチメディア配信サーバ８５から配信された音声と動画は，音声がＧ．７１１で符号化され，動画はＭＰＥＧ４またはＨ．２６３により符号化され，それぞれパケットとしてＩＰネットワーク８４を伝送され，図１４に示すマルチメディアゲートウェイのＩＰ／ＵＤＰ／ＲＴＰ終端部８２０ａ，８２０ｂで終端し，それぞれＩＰ／ＵＤＰ／ＲＴＰのプロトコルのヘッダが取り除かれ，揺らぎを吸収するため音声と動画の符号化データはジッタバッファ８２１ａ，８２１ｂに格納され，ＭＰＥＧ４（またはＨ．２６３）の動画の符号化データは３Ｇ−３２４Ｍ処理部８２４へ入力され，音声についてはＧ．７１１の符号化データがＣＯＤＥＣ処理部８２２において決められたＡＭＲレートでＡＭＲ符号化されて音声バッファ８２３に格納され，その出力が３Ｇ−３２４Ｍ処理部８２４へ入力される。３Ｇ−３２４Ｍ処理部８２４は音声バッファ８２３のＡＭＲの音声データとＭＰＥＧ４の動画データ及びＣＰＵ８２７からのデータ（呼制御データ）とを合成（多重）し，６４Ｋｂｐｓのレートに対応するビット数を持つフレーム構成の多重化データ（ＭＵＸ−ＰＤＵ：Multiplex Protocol Data Unit) を生成してマルチメディア携帯端末網８１を介してマルチメディア携帯端末８０に送信される。従来は，情報の送信側から相手側に対して音声と動画と制御情報（H.245)のデータ量のレート（配分量）が設定された多重化テーブルを予め送信しておき，送信側での多重化に合わせて受信側での分離処理が多重化テーブルを用いて行うことができるようになっている。
【００１２】
下り方向の伝送の場合は，マルチメディアゲートウェイ（３Ｇ−３２４Ｍ処理部）からマルチメディア携帯端末へ多重化テーブルが送られ，上りの場合は，マルチメディア携帯端末からマルチメディアゲートウェイに多重化テーブルが送られる。この時，多重化テーブルは６４Ｋｂｐｓという限られた範囲内で，音声と動画のレートが予め決められたレートで設定されている。
【００１３】
従来技術としてインターネット網及び携帯電話網を介して動画，静止画，音声等の多重化して符号化ビットストリームを送信する手段と，各符号化データを１つのシーンとして合成・再生するためのシーン記述を送信する手段とを備え，符号化ビットストリーム送信手段のストリームとシーン記述送信手段のシーン記述とは異なる伝送路または異なるタイミングで送信するマルチメディア情報送信装置の技術がある（特許文献１参照）。また，動画像をＭＰＥＧ４規格で送受信する機能と地上波ディジタル放送を受信する機能を備えた携帯電話機の技術が知られている（特許文献２参照）。
【特許文献１】特開２００３−２９９０４４号公報
【特許文献２】特開２００３−１５３１１１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
上記特許文献１の技術は多重化した符号化ビットストリームとシーン記述を送信する技術であり，特許文献２はＭＰＥＧ４の画像の送受信と地上波ディジタル放送の受信機能を備える携帯電話機の技術であり，音声・動画のレートを固定の帯域（６４Ｋｂｐｓ）内で効率的に制御することを示唆するものではない。
【００１５】
そして，上記図１３，図１４に説明した従来方式では，６４Ｋｂｐｓ内に音声・動画を多重する必要があり，双方とも高い品質で多重することが難しいという問題がある。
【００１６】
また，動画，音声のレートがゲートウェイに接続される端末全てに対して予め決められた多重化テーブルにより一定に設定され，状況に応じて変化させるには音声，動画の状況を検出しアルゴリズムに基づいて比率を算出してテーブルを変更するための通知を行うという一連の処理を常時繰り返す必要がありそのための負荷が多大になるため，各携帯端末毎の特性や，携帯端末側の環境に対応することができず，携帯端末によっては接続性（機種によっては一部のレートにしか対応できないので接続できない）に問題が生じてしまう。
【００１７】
また，配信サーバから出力される動画はあくまで最大レートであり，平均レートがこれを大幅に下回る場合は，回線リソースを有効に活用していないことになる。例えば，動画の出力レートを５０Ｋｂｐｓに設定した場合，可能な音声出力レートは３Ｇ−３２４Ｍのオーバヘッド（管理用ビット等）を考慮し，４．７５Ｋｂｐｓとなるが，動画の出力レートは最大値を示す値であり，実際の平均レートは４０Ｋｂｐｓ程度ということになると考えられる。この場合，１０Ｋｂｐｓに相当するデータが無駄になってしまい，非効率的である。
【００１８】
更に，配信サーバから予め決められた一定の音声・動画レートを配信サーバから垂れ流すのみであるため，携帯端末側での受信状況を認識する手段及びそれをフィードバックする手段がなく，音声，画像品質の安定性を確保することができない。携帯端末側での受信状況を確認する方法がなく音質，画質の安定性を確保できない。
【００１９】
この問題に対し，マルチメディア配信サーバまたはマルチメディアゲートウェイ上の各チャネル毎に動画のトランスレータ（変換器）を設けて，トランスレータで動画レートを可変に調整することで音声レートを自在に出力することが可能であるが，処理能力が重い動画トランスレータを実装することは，チャネル密度の低下，装置の肥大化，装置価格の上昇を招くことになる。
【００２０】
本発明はマルチメディア携帯端末網に対応するＧ−３２４Ｍの音声と動画の多重化データ（ＭＵＸ−ＰＤＵ）の動画レートを最大限に割り当てることで動画の品質を維持し，多重化データの動画のレートに余裕が生まれるとその分を音声の品質に割り当てることができる等により限られたデータ量で音声・動画を適切なレートに調整することができるマルチメディアゲートウェイにおける音声・動画調整方式を提供することを目的とする。
【課題を解決するための手段】
【００２１】
図１は本発明の原理構成を示す。この原理構成には，マルチメディアゲートウェイにおいて，ＩＰネットワーク（図１３の８４）からのマルチメディア情報（図１３のマルチメディア配信サーバ８５等からの情報）として音声パケットと動画パケットを受け取ってマルチメディア携帯端末網の携帯端末へ送信する下り方向の３Ｇ−３２４Ｍの多重化データを発生する多重化処理部の構成だけを示し，上り方向の信号を発生するための構成や，呼制御のための構成は図示省略されている。図中，１ａはマルチメディアゲートウェイの中に設けられＩＰネットワークからマルチメディア携帯端末網への下り方向のマルチメディア信号を３Ｇ−３２４Ｍへ多重化する多重化処理部，１０は多重化データ格納部，１１はスケジューラ，１１ａは多重化テーブルの初期設定手段，１１ｂは動画レートを監視する監視手段，１１ｃは多重処理手段，１２は多重化テーブル，２ａは終端部，２ｂはジッタバッファ，２ｃはコーデック（ＣＯＤＥＣ）処理部，２ｄは音声バッファ，３ａは終端部，３ｂはジッタバッファである。
【００２２】
多重化処理部１ａのスケジューラ１１は，初期設定手段１１ａにおいて接続が行われたマルチメディア携帯端末（図１３の８０）へ送信するマルチメディア情報の音声と動画のレートとして，音声を最低レート（例えば４．７Ｋｂｐｓに対応するバイト数）とし，動画のレートを最大（例えば，５０Ｋｂｐｓに対応するバイト数）とし，残りをオーバヘッド（保守管理用）に割り当てた多重化パターンを多重化テーブル１２の当該携帯端末の通信に割り当てられたチャネルに対して設定する。ＩＰネットワーク（図１３の８４）から入力するＩＰ／ＵＤＰ／ＲＴＰ／Ｇ．７１１の音声パケットは終端部２ａで終端し，ＲＴＰに対応したフレームのヘッダが除かれてＧ．７１１により符号化された音声データがジッタバッファ２ｂを通ってコーデック処理部２ｃに供給される。コーデック処理部２ｃはスケジューラ１１の制御を受けて，多重化テーブル１２に従ってＧ．７１１の符号をＡＭＲの符号（最低レートによる）に変換し，音声バッファ２ｄに格納される。また，ＩＰネットワークからの動画パケットは終端部３ａで終端し，ヘッダを除いたＭＰＥＧ４のデータはジッタバッファ３ｂに格納される。
【００２３】
スケジューラ１１の多重処理手段１１ｃは携帯端末の通信に割り当てられたチャネルに対して設定された音声，動画のレートを多重化テーブル１２を参照し，音声については最低レートであることを識別し，音声バッファ２ｄのデータをコーデック処理部２ｃで最低レートのＡＭＲ符号に変換した後スケジューラにより多重化データ格納部１０に転送し，ジッタバッファ３ｂに格納された動画データ（ＭＰＥＧ４）を多重化テーブル１２に設定されたレートに対応するデータ長に変換して多重化データ格納部１０に格納する。また，オーバヘッドのデータは予め設定された一定長を多重化データ格納部１０に設定する。なお，多重化データのフレーム長を一定とすると６４Ｋｂｐｓに対応した固定のデータ量になる。
【００２４】
最初に設定したレート（音声の符号データを最低レートに設定）による通信を行うことで，動画の品質を最大限に維持することができる。このようにして運用している時，スケジューラ１１の監視手段１１ｂが多重化データ格納部１０の動画データ１０ｂのデータ長を監視し，空きが生じると（動画データの量が最大レートに対応する領域より少ないと），空いた量を検出して多重処理手段１１ｃに通知する。多重処理手段１１ｃは通知された空きの量に対応して音声の符号化レートを増大させて，変換を行う（多重化テーブル１２には予め音声符号化レートを増大させたパターンも登録してあるため設定のパターン番号を変更する）。この後，多重処理手段１１ｃは監視手段１１ｂにより動画データの量が増大すると，音声の符号化レートを減少させるよう制御を行う。
【００２５】
なお，音声・動画のレートについて上記の説明では音声を最低レートにしたが，最低レートに設定せずに，各携帯端末のチャネル毎に最適な音声レートを多重化テーブル１２に設定するようにしてもよい。
【００２６】
更に，動画バッファに閾値を設定することにより閾値を越えた場合により多重化密度の高い多重化テーブルを選択するか，ヘッダのオーバヘッド（保守，管理）を少なくして動画のレートを上げることで，音声・動画とも可能な範囲内で高いレートを維持しつつ，３Ｇ−３２４Ｍ回線上に多重化データを出力することができる。
【００２７】
また，音声・動画を多重化する時，音声評価用と画像評価用のデータを多重して，これらの評価結果を携帯端末からフィードバックすることで高いレベルの音質・画質を維持するようにしてもよい。
【発明の効果】
【００２８】
本発明の原理及び実施例１により，マルチメディアゲートウェイにおいて，音声・動画レートの音声を最低レートにして動画レートを最大にすることで画像の品質を一定レベル以上に維持することができる。
【００２９】
また，後述する実施例２の構成によれば，動画レートを監視することにより多重化データの空きリソースを有効に使い，ＡＭＲレートを上げることにより音質を上げることが可能となる。また，後述する実施例３によりチャネル別に送出する音声レートを管理するテーブルを保持することにより端末毎に適切な音声レートを送出することが可能となる。
【００３０】
また，後述する実施例４によれば，動画バッファに閾値を設け，閾値越えした場合は，更に多重化レートの大きい多重化テーブルを選択するか，または多重化データ（ＭＵＸ−ＰＤＵ）のアダプテーションレイヤ（ＡＬ）ヘッダのオプションを無くすことによりヘッダオーバヘッドを減少させて多重化効率を高め，音声・動画とも可能な範囲内での高いレートを維持しつつ，６４Ｋｂｐｓの３Ｇ−３２４Ｍ上に多重化することが可能となる。
【００３１】
更に，後述する実施例５による多重を行う際，音声評価用データを多重化し，この評価結果を携帯端末からフィードバックすることによりマルチメディアゲートウェイで音声レートを適切な値に設定することが可能となる。また，実施例６により音声評価用データの他に画像評価用データも多重化して携帯端末に送信することで，その評価結果を携帯端末から配信サーバまでフィードバックすることで配信サーバから適切な画像レートで動画データを送出させるようにして，高いレベルの音質・画質を維持することが可能となる。
【発明を実施するための最良の形態】
【００３２】
図２は実施例１の構成を示す。図２の実施例１には，マルチメディアゲートウェイ内のＩＰネットワークからマルチメディア携帯端末網の携帯端末へマルチメディア情報（音声と動画）を伝送する方向（下り方向）の構成だけを示し，上り方向については図示省略されている（上り方向の伝送は従来と同じ）。図２において，１はマルチメディアゲートウェイであり，上記図１に示す多重化処理部１ａ（符号１０〜１２により構成）はこのマルチメディアゲートウェイ１内に含まれる。図１の１０〜１２，２ａ〜２ｄ，３ａ，３ｂの各符号は上記図１に示す原理構成の同一符号の各部と同じ名称であり，説明を省略する。
【００３３】
図２の多重化データ格納部１０は，１フレーム分の３Ｇ−３２４Ｍに対応する多重化データ（ＭＵＸ−ＰＤＵ:Multiplex Protocol Data Unit)を格納する容量を備えるが，図２には時間的経過を含む２つのフレームのＭＵＸ−ＰＤＵ（多重化データ）を示す。各ＭＵＸ−ＰＤＵ（多重化データ）内の１０ａはＡＭＲにより圧縮された音声データ，１０ｂはＭＰＥＧ４またはＨ．２６３（以下の説明ではＭＰＥＧ４とする）により圧縮された動画データを示し，この実施例１では，音声データと動画データとで構成する１フレームは，２０ｍｓの長さであり，６４Ｋｂｐｓの伝送速度であるから，１フレームは１６０Ｂ（バイト）で構成し，３Ｇ−３２４Ｍの音声データ（ＡＭＲの圧縮符号）と動画データ（ＭＰＥＧ４）及び一定長のオーバヘッド（保守管理データ）とを合わせたデータである。スケジューラ１１は音声の圧縮データＧ．７１１をコーデック処理部２ｃにおいて多重化テーブル１２に設定されたレートでＡＭＲ符号に変換させるよう制御を行う。
【００３４】
多重化テーブル１２には，各番号（多重化テーブル番号という）に対応して音声レートと動画レートを変化させて各組み合わせが設定されており，スケジューラ１１はマルチメディア情報を送信する際に，フレーム（ＭＵＸ−ＰＤＵ）のヘッダ（図示省略）の中に多重化テーブル番号（ＭＣという）を設定して送信する。この多重化テーブル番号は，携帯端末で受信されると，携帯端末にもスケジューラ１１の多重化テーブル１２と同様のテーブルを備えており，スケジューラ１１から送られてきたフレームのヘッダから多重化テーブル番号を取り出して，音声レートと動画レートを識別して多重化データを音声と動画のデータに分離して復号する。
【００３５】
この実施例１では，予め多重化テーブル１２に音声レートを最低速度である４．７５Ｋｂｐｓに対応するレート（１３バイト／フレームに相当）とすると，１フレーム全体（１６０バイト）の残りの１４７バイトの内，ＭＵＸ−ＰＤＵ（多重化データ）のレイヤ及びＡＬ（アダプテーションレイヤ）のオーバヘッドを除いた分が配置可能な動画レートになる。オーバヘッドのサイズは，時々の多重化パターンによって異なるが，２０ｍｓ間隔中にアダプテーションレイヤ２である音声とアダプテーションレイヤ３である動画が個別の多重化データ（ＭＵＸ−ＰＤＵ）で配置されるとすると，１８バイトとなる。この場合，配置可能な動画サイズは，残りの分である５１．６Ｋｂｐｓを配置（ほぼ１２９バイト／フレームに相当）して多重化テーブル番号を設定して，送信相手の携帯端末にそのテーブル番号（番号に対応した音声と画像のレートを含む）を通知して，携帯端末の多重化テーブルに設定させる。このように音声のＡＭＲ符号化データとして最低レートを選択することで，動画の画質レベルを高く保持するようにした。
【００３６】
図３は実施例１の処理フローであり，この処理はスケジューラ１１において実行される。スケジューラは，２０ｍｓの固定周期毎に先頭（音声データ）であるか判定し（図３のＳ１），先頭であるとＡＭＲデータを音声バッファ（図２の２ｄ）から出力し，多重化データ（ＭＵＸ−ＰＤＵ）の先頭に配置する（図３のＳ２）。次にジッタバッファ（図２の３ｂ）から動画データを出力し，多重化データ（ＭＵＸ−ＰＤＵ）のＡＭＲデータの次に配置して（図３のＳ３），処理を終了する。なお，図３のフローではオーバヘッドの配置について省略されているが，各フレームのＭＵＸ−ＰＤＵにオーバヘッドが配置されることはいうまでもない。
【００３７】
上記実施例１では，比較的簡単に音声・動画を与えられたレートで多重化可能であるが，任意の形に各レートを変更し，音質と画質とも最良のレベルに維持することはできないが，これに対処するために以下に実施例２〜実施例７の構成を説明する。
【００３８】
図４は実施例２の構成を示す。図中，１，１０〜１２，２ａ〜２ｄ，３ａ，３ｂの各符号は上記図２に示す実施例１の構成の同一符号の各部と同じ名称であり，説明を省略する。１００はスケジューラ１１におけるフレームのイメージング処理を示す。
【００３９】
この実施例２では，動画のデータ量を確認して，固定の割り当て領域に空きがあることを確認すると，その空き領域に対応するレートを音声のレートを上げるために割り当てるように，コーデック処理部２ｃ（図４）を制御する。
【００４０】
図４ではスケジューラ１１は，実際に多重化データ格納部１０上にマッピングする前に，次のようなイメージング処理を行う。まず，音声レートを最低レートの４．７５ＫｂｐｓでＭＵＸ−ＰＤＵ上に２０ｍｓの固定間隔でマッピングする。オーバヘッドを除いた残りを動画で配置するが，その際に動画バッファの残サイズを確認し，残サイズが次固定間隔以降でも均等に配置されるサイズを残し，該当固定間隔内に動画を配置する。この時，固定間隔に未だに空き領域がある時は，スケジューラ１１は，空き領域を満たす分だけ音声レートを上げるようコーデック処理部２ｃを制御する。なお，空き領域が全く無い時は，コーデック処理部２ｃの変換レートは４．７５Ｋｂｐｓのままとなる。
【００４１】
音声はコーデック処理部２ｃにおいて，空き領域を埋めるレートに変換された後，動画バッファから取り出された動画データと共に多重化データ格納部１０の実際のＭＵＸ−ＰＤＵに配置される。図４の例では，イメージング処理１００のフレーム１の空き領域に対応するＡＭＲの変換レートは７．９５Ｋｂｐｓとなり，イメージング処理１００のフレーム２の空き領域に対応するＡＭＲの変換レートは５．９０Ｋｂｐｓとなっている。
【００４２】
動画データは通常，配信サーバから最大（ＭＡＸ）値の設定レートで送信されるため，平均的には最大値を下回り，またバースト性も考慮すると，ＡＭＲを最低レートで考えた場合，空き領域は必ず発生する。
【００４３】
図５は実施例２の処理フローである。スケジューリング処理において，まず２０ｍｓの固定周期毎に先頭（音声データ）であるか判定し（図５のＳ１），先頭であるとＡＭＲデータを音声バッファから出力し，多重化データ（ＭＵＸ−ＰＤＵ）の先頭に配置し（同Ｓ２），次にジッタバッファ（図４の３ｂ）から動画データを出力し，多重化データ（ＭＵＸ−ＰＤＵ）のＡＭＲデータの次に配置する（図５のＳ３）。次にＭＵＸ−ＰＤＵに空き領域が有るか判別し（図５のＳ４），無ければ処理を終了するが，有る場合は空き領域分，ＡＭＲデータを高レートで再符号化し（図５のＳ５），ＡＭＲを先頭に再配置し，動画をＡＭＲの次位置に配置する（同Ｓ６）。なお，ＡＭＲデータを高レートで再符号化する処理は，コーデック処理部２ｃにおいて実行させる。
【００４４】
以上のように実施例２により，ＭＵＸ−ＰＤＵ内の空きリソースを有効に使い音声レートを上げることにより音声品質を上昇させることが可能で，その結果，この実施例２により同じ多重化レートにもかかわらず，音声品質のレベルを向上させることができる。
【００４５】
図６は実施例３の構成を示す。図中，１，１１，１２，２ａ〜２ｄ，３ａ，３ｂの各符号は上記図２，図４に示す実施例１，実施例２の同一符号の各部と同じ名称であり，説明を省略する。この実施例３で設けられた２０はコーデック処理部２ｃで使用するチャネル別管理テーブルであり，各チャネル別にそのチャネルを使用する携帯端末へ送出する音声レートを管理するチャネル別管理テーブルである。また，１０−０，１０−１，……は多重化データ格納部１０（図２，図４に示す）がチャネル０，チャネル１，……に対応して変化する状態を表し，データの多重化処理は各チャネル０，１，２，……について時分割処理を行う。
【００４６】
チャネル別管理テーブル２０は，予めチャネル毎に設定された回線情報や，携帯端末からの初期設定時におけるネゴシエーション結果に基づき保持される。
【００４７】
この実施例３では，ＩＰ／ＵＤＰ／ＲＴＰ終端部２ａで終端した音声パケットは，ジッタバッファ２ｂを介してコーデック処理部２ｃにおいて，チャネル別管理テーブル２０の内容に基づきチャネルに対応して設定されたレートに変換された後，音声バッファ２ｄに蓄積される。その後，スケジューラによりチャネル毎に最適な多重化テーブルが選択され，各チャネルの多重化データ１０−０，１０−１，……としてマッピングされる。
【００４８】
図７は実施例３の処理フローである。スケジューラは，２０ｍｓの固定周期毎に先頭（音声データ）であるか判定し（図７のＳ１），先頭であるとコーデック処理部に対し各チャネル別管理テーブルを参照し，コーデック変換を実行させ（同Ｓ２），変換により得られたＡＭＲデータを音声バッファから出力し，多重化データ（ＭＵＸ−ＰＤＵ）の先頭に配置する（同Ｓ３）。次にジッタバッファ（図６の３ｂ）から動画を出力し，ＭＵＸ−ＰＤＵのＡＭＲの次に配置して（図７のＳ４），終了する。
【００４９】
この実施例３により，従来まではマルチメディアゲートウェイと接続される携帯端末の全てに一定の音声レートが送出されていたのに対して，携帯端末毎に適切な音声レートを送出することが可能となる。これにより，音声レートに関する携帯端末固有の接続性の問題からクリアされる。
【００５０】
図８は実施例４の構成を示す。図中，１，１０〜１２，２ａ〜２ｄ，３ａ，３ｂ及び１０−０，１０−１，２０の各符号は上記図６に示す実施例３の同一符号の各部と同じ名称であり，説明を省略する。この実施例４で設けられた３０は動画用のジッタバッファ３ｂ内に設けられたチャネル毎の個別の動画バッファを表し，３１は各チャネル別に動画レートが増大して多重化テーブルを変更させる境界となる動画レートの閾値を保持する多重化変更閾値保持部，３２は前記の多重化変更閾値を越えて多重化テーブルを変更した後，動画レートが低下して元の多重化テーブルに戻させる境界となる動画レートの閾値を保持する解除閾値保持部である。
【００５１】
この実施例４では上記実施例３（図６）と同様にチャネル別管理テーブル２０を備え，各チャネル別に音声レートと動画レートの組み合わせに対応する多重化テーブル番号が設定されており，ジッタバッファ３ｂ内の各チャネルに対応した個別の動画バッファ３０に対し，多重化変更閾値（動画バッファ３０の特定のレートに対応する位置を表す値）を多重化変更閾値保持部３１に，解除閾値（動画バッファ３０の変更閾値より低いレートに対応する位置を表す値）を解除閾値保持部３２に設定しておく。
【００５２】
スケジューラ１１はチャネル別管理テーブル２０に従ってチャネル毎に音声レートを決定し，多重化されるが，音声レートの残りのレートで動画の多重化を行おうとしても，動画のレート（データ量）が増大して残りのレートに収まらない場合，例えば，音声レートが最大の１２．２Ｋｂｐｓにもかかわらず，動画レートが最大の５０．４Ｋｂｐｓであった場合は，動画の残バッファ（出力できないデータ）が増大して，当該チャネルに対応して多重化変更閾値保持部３１の閾値を越えてしまう。この時，スケジューラ１１は，多重化テーブルの選択を通常よりも多重化レートの高い設定に変更することにより６４Ｋｂｐｓ内におさめようとする。しかし，多重化テーブルの変更のみでは依然として個別の動画バッファ３０の閾値を越える場合，例えば，上記音声レートが１２．２Ｋｂｐｓに対し，動画レートが５０．４Ｋｂｐｓの場合等には，更にスケジューラ１１が，音声データと動画データを多重化する場合にはアダプテーションレイヤのヘッダや，シリアル番号，誤りチェック用のデータ等が付加されているが，これらのデータはオプションにより選択することができる。この実施例４では，多重化変更閾値保持部３１の閾値を越えた場合にこのオプションのオーバヘッドを極力少なくして，動画レートを増加させるようにした。具体的には，上記音声・動画レートで示すと，４０ｍｓ＝３２０バイト間隔中に，音声・動画ともアダプテーションレイヤ２（ＡＬ２）及びＭＵＸ−ＰＤＵのオプションヘッダ無しで多重化すると，ヘッダオーバヘッドは１６０バイト中３バイトとなり，５０．４Ｋｂｐｓの動画がおさまることになる。
【００５３】
個別バッファの閾値越えが解除されたことが，動画バッファ３０のデータ量が解除閾値保持部３２に設定して閾値を下回ったことで検出される。この場合，スケジューラ１１はアダプテーションレイヤ２（ＡＬ２）及びＭＵＸ−ＰＤＵのヘッダを通常に戻し，また場合によっては多重化テーブルの設定も通常に戻す。これによりヘッダのオプションを復活し，多重化のレートを低くすることにより，エラーの発生・検出頻度を通常レベルまで維持することが可能となる。
【００５４】
図９は実施例４の処理フローである。スケジューラは，２０ｍｓの固定周期毎に先頭（音声データ）であるか判定し（図９のＳ１），先頭であると動画バッファが閾値（多重化変更閾値保持部３１の閾値）を越えたか判別する（同Ｓ２）。越えない場合は，動画バッファは閾値解除の条件を満たす（解除閾値保持部３２の閾値を下回る）かを判別し（図９のＳ３），満たすと多重化を効率化した状態を，多重化テーブルを戻し，オプションヘッダを復活して，元に戻す（同Ｓ４）。ステップＳ２において動画バッファが閾値を越えたと判断されると，最適な多重化テーブルを選択し，オプションヘッダの削除をすることによりＭＵＸ−ＰＤＵ多重化効率を増加させ（図９のＳ５），ＭＵＸ−ＰＤＵを生成する（同Ｓ６）。
【００５５】
図１０は実施例５の構成を示す。図中，１，１０〜１２，２ａ〜２ｄ，３ａ，３ｂの各符号は上記図２，図４，図６，図８の各実施例１〜４の同一符号の各部と同じ名称であり，説明を省略する。１３は多重化データ格納部１０に設定されて送信先である携帯端末に送られる音声評価用データを格納する音声評価用データ発生部，１４は携帯端末から送信された（上り方向の）３Ｇ−３２４Ｍの信号を終端する３Ｇ−３２４Ｍ終端部，１５はフィードバック結果解析部，１６は呼制御データをＭＥＧＡＣＯを介して送受信し呼処理を行うＣＰＵである。
【００５６】
この実施例５ではスケジューラ１１が音声の品質評価用の予め決められたデータをリアルタイムの音声・動画データの通信中に付加して送信して，携帯端末において評価した結果を受け取って，フィードバックされた評価結果に従ってコーデック処理部２ｃにおける音声レートの調整を行う。この実施例５の音声評価にはＩＴＵ−Ｔ（国際電気通信連合電気通信標準化部門）が勧告したＰＳＱＭ（Perceptual Speech Quality Measure)という方式を用いる。この方式は，テストに用いる音声のサンプルとネットワークを経由して届いた受信側の音声を比較し，サンプルに対する受信側音声の劣化具合を数値化する。
【００５７】
図１０において，スケジューラ１１は，音声をＡＭＲ最低レートの４．７５Ｋｂｐｓで２０ｍｓの固定間隔で配置し，残りの領域（オーバヘッドの分は別）を動画データと音声評価用の予め決められた音声評価用データ（テストに用いる音声のサンプル）を音声評価用データ発生部１３から配置する。本来は動画データを配置すればよい領域に対し，音声評価用データ分を多重するため，動画レートが幾分少なくなるが，全ての固定間隔内に音声評価用データを多重する必要はなく，ある一定周期ｔ１（ｔ１＝２０ｍｓ×ｎ）の間隔で多重するので，動画への影響は極めて少ない。音声評価データ（音声のサンプル）は，相手側の携帯端末において受信すると，受信した音声評価データと予め保存している音声のサンプルとを比較する音声評価アルゴリズムにより評価を行って，評価結果を上り方向のマルチメディア情報のアダプテーションレイヤ２（ＡＬ２）等のインチャネルによりマルチメディアゲートウェイに送出する。
【００５８】
マルチメディアゲートウェイの３Ｇ−３２４Ｍ終端部１４により評価結果を抽出して，フィードバック結果解析部１５によりフィードバック結果を解析し，音声レートの上げ下げが必要であればその旨をコーデック処理部２ｃに通知する。コーデック処理部２ｃはフィードバック結果解析部１５からの解析結果に従いＡＭＲの音声レートの上げ下げを行う。この時，音声レートを上げた（音声データ量を増やす）ことにより動画データに影響を与える場合があるが，多重化テーブルを用いて動画データの量を減らすようにするか，上記の実施例４（図８，図９）の動画バッファに対して閾値により制御する方法を用いることにより対処することもできる。
【００５９】
図１１は実施例５の処理フローである。この処理フローは，携帯端末からのフィードバックを受け取った状態で，スケジューラはフィードバック結果は前回の音声評価値より悪いか判別し（図１１のＳ１），悪くない場合はコーデック処理部に対して，ＡＭＲ圧縮レートを上げる（高圧縮する）よう指示し（同Ｓ２），悪い場合はコーデック処理部に対し，ＡＭＲの圧縮レートを下げる（低圧縮する）よう指示する（同Ｓ３）。この低圧縮の指示に応じて音声レートによって動画レートが圧迫された（動画データの領域が減少した）場合は動画バッファ制御（上記図８，図９に示す実施例４に示す制御）を併用する（図１１のＳ４）。但し，ステップＳ４の動画バッファ制御は実施例４の処理によらないで，単に多重化テーブルの番号を動画レートを下げた組み合わせの番号に変更することで対応することもできる。
【００６０】
図１２は実施例６の構成を示す。図中，１，１０〜１６，２ａ〜２ｄ，３ａ，３ｂの各符号は上記図１０に示す実施例５の同一符号の各部と同じ名称であり，説明を省略する。１７は画像評価用データ発生部，１８は画像フィードバック解析部，４はＳＩＰ（Session Initiation Protocol)サーバである。
【００６１】
この実施例６は，上記実施例５（図１０，図１１）で使用した音声評価用の予め決められたデータに加えて，更に予め決められた画像評価用データを多重して携帯端末に送信する。この実施例６の画像評価は，マーカ埋め込み型絶対評価方式を使用する。この方法では，評価対象の原画像に不可視信号（マーカ）を埋め込み，受信側でそのマーカ信号の劣化を元に画質推定を行う。これにより，受信側は評価対象の比較元となる画像を必要としない絶対評価を行うことが可能となる。
【００６２】
画像評価用データ発生部１７からはある一定周期ｔ２（ｔ２＝２０ｍｓ×ｍ）の間隔で多重する。音声評価用データ発生部１３からの音声評価用データとは独立して送ることができる。相手側の携帯端末は，音声評価用データを用いて音声評価を行うと同時に，画像評価用データを用いて画像評価を行い，その結果を音声評価結果とは別のアダプテーションレイヤ２（ＡＬ２）等でマルチメディアゲートウェイに対してフィードバックする。マルチメディアゲートウェイは３Ｇ−３２４Ｍ終端部１４で画像評価のフィードバック結果を動画データと分離して，画像フィードバック解析部１８で内容を解析し，フィードバック結果に従った画像レートの上げ下げ情報をＣＰＵ１６に供給する。この情報はＣＰＵ１６からＭＥＧＡＣＯのプロトコルにのせてＳＩＰサーバ４に転送し，ＳＩＰサーバ４からマルチメディア配信サーバ（図１３の８５）へ評価情報がフィードバックされることにより，配信サーバは適切な画像レートに変換して再送信する。
【００６３】
この実施例６により，音声データのみならず動画についても，携帯端末側での実際の評価結果をフィードバックすることにより，高いレベルの音質・画質を維持して送信することができる。
【００６４】
（付記１）  音声・動画の送受信が可能な携帯端末が収容されたマルチメディア携帯端末網とマルチメディア配信サーバが接続されたＩＰネットワークとの接続点に設けられ，配信サーバからのＩＰ対応の音声パケットと画像パケットを終端して音声信号をマルチメディア携帯端末網のＡＭＲ（適応可変レート）の音声データに変換し，画像パケットを終端して動画データを取り出して，音声データと動画データ及びオーバヘッドを６４Ｋｂｐｓの速度で固定長の多重化データに組み立てて前記マルチメディア携帯端末網に一定周期で出力する多重化処理部を備えたマルチメディアゲートウェイにおける音声・動画調整方式において，前記多重化処理部は多重化データを生成する制御を行うスケジューラと，前記各固定長内の音声レートと動画レートの組み合わせが格納された多重化テーブルとを備え，各携帯端末への送信用に前記多重化テーブルに音声レートを最低レートとし残りの容量を動画とオーバヘッド用とするよう多重化テーブルに設定し，前記スケジューラは，前記多重化テーブルの前記音声レートのデータと前記動画レートを使用して多重化データを生成することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【００６５】
（付記２）  付記１において，前記多重化処理部に生成された多重化データを格納する多重化データ格納部の空き領域を検出する手段を備え，前記空き領域を検出する手段により空き領域を検出すると，前記スケジューラは前記マルチメディア携帯端末網のＡＭＲの音声データに変換する手段に対して，前記最低レートの音声レートを前記空き領域を満たす分だけ増大させるよう制御することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【００６６】
（付記３）  付記１において，音声受信特性や受信環境条件に応じて特定の音声レートを保持する必要がある携帯端末について，該携帯端末のチャネル別に多重化テーブルに前記特定の音声レートを設定し，前記スケジューラは，前記一定間隔毎に動画を多重する際に前記多重化テーブルの該当チャネルに設定された音声レートにより調整することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【００６７】
（付記４）  付記１において，配信サーバからのＩＰ対応の画像パケットを終端した動画データを保持するチャネル対応の動画バッファを備え，各チャネルに対応して多重化変更閾値を設定した多重化変更閾値保持部を設け，前記スケジューラは，各チャネルの動画レートが増大して対応して設定された前記多重化変更閾値を越えたことを検出すると，アダプテーションレイヤのオプションのオーバヘッドを少なくして動画のレートを増加させることを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【００６８】
（付記５）  付記４において，配信サーバからのＩＰ対応の画像パケットを終端した動画データを保持するチャネル対応の動画バッファに対応して解除閾値が設定された解除閾値保持部を備え，前記スケジューラは，前記チャネル対応の動画バッファの画像レートが前記多重化変更閾値を越えた後，画像レートが低下して前記解除閾値より下がると，アダプテーションレイヤのオーバヘッドを通常に戻すことを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【００６９】
（付記６）  付記１または付記４の何れかにおいて，前記多重化処理部に，音声の品質評価用のデータを発生する音声評価用データ発生部を設け，前記スケジューラは，音声データと動画データ及びオーバヘッドを組み立てる際に，前記多重化データを出力する前記一定周期の複数回に一回の割合で前記音声評価用データ発生部のデータを多重化して出力し，前記スケジューラは，前記携帯端末側から前記音声評価用データを用いた音声評価の結果を受け取ると，その音声評価の結果に応じて携帯端末への前記多重化データの音声レートを調整することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【００７０】
（付記７）  付記６において，前記多重化処理部に，画像評価用データを発生する画像評価用データ発生部を設け，前記スケジューラは，動画データを組み立てる際に，前記多重化データを出力する前記一定周期の複数回に一回の割合で前記画像評価用データ発生部のデータを多重化して出力し，前記スケジューラは，前記携帯端末側から前記画像評価用データを用いた画像評価の結果の情報を受け取ると，前記画像評価の結果情報をＩＰネットワークとマルチメディアゲートウェイとの間で呼制御情報を転送する経路を介してＩＰネットワークに接続した前記マルチメディア配信サーバに伝送し，前記マルチメディア配信サーバは前記画像評価の結果に従って，画像レートを調整してＩＰネットワークへ送信することを特徴とするマルチメディアゲートウェイにおける音声・動画調整方式。
【図面の簡単な説明】
【００７１】
【図１】本発明の原理構成を示す図である。
【図２】実施例１の構成を示す図である。
【図３】実施例１の処理フローを示す図である。
【図４】実施例２の構成を示す図である。
【図５】実施例２の処理フローを示す図である。
【図６】実施例３の構成を示す図である。
【図７】実施例３の処理フローを示す図である。
【図８】実施例４の構成を示す図である。
【図９】実施例４の処理フローを示す図である。
【図１０】実施例５の構成を示す図である。
【図１１】実施例５の処理フローを示す図である。
【図１２】実施例６の構成を示す図である。
【図１３】従来のマルチメディアゲートウェイを含むシステムの構成を示す図である。
【図１４】本発明の対象となるマルチメディアゲートウェイの構成を示す図である。
【符号の説明】
【００７２】
１ａ        多重化処理部
１０        多重化データ格納部
１１        スケジューラ
１１ａ      初期設定手段
１１ｂ      監視手段
１１ｃ      多重処理手段
１２        多重化テーブル
２ａ        終端部
２ｂ        ジッタバッファ
２ｃ        コーデック（ＣＯＤＥＣ）処理部
２ｄ        音声バッファ
３ａ        終端部
３ｂ        ジッタバッファ
【図１】
2006074555.tif 000003
【図２】
2006074555.tif 000004
【図３】
2006074555.tif 000005
【図４】
2006074555.tif 000006
【図５】
2006074555.tif 000007
【図６】
2006074555.tif 000008
【図７】
2006074555.tif 000009
【図８】
2006074555.tif 000010
【図９】
2006074555.tif 000011
【図１０】
2006074555.tif 000012
【図１１】
2006074555.tif 000013
【図１２】
2006074555.tif 000014
【図１３】
2006074555.tif 000015
【図１４】
2006074555.tif 000016