JP4764429B2

JP4764429B2 - Ａｍｒペイロードフォーマットを使用したｉｐベースシステムの音声品質を向上させるためのシステムと方法

Info

Publication number: JP4764429B2
Application number: JP2007546629A
Authority: JP
Inventors: コール，ゲーリー，アール．
Original assignee: ソニーエリクソンモバイルコミュニケーションズ，エービー
Priority date: 2004-12-21
Filing date: 2005-06-20
Publication date: 2011-09-07
Anticipated expiration: 2025-06-20
Also published as: EP1829318B1; DE602005005087T2; MX2007007113A; US7830920B2; EP1829318A1; JP2008524921A; BRPI0518326A2; CN101065946A; US20060133276A1; DE602005005087D1; CN101065946B; WO2006068659A1

Description

背景
ボイス・オーバーＩＰ（ＶｏＩＰ）は、パーソナルコンピュータおよび通信事業関連分野で着実に普及している。技術が進歩するにつれて、同様のサービスをセルラー装置において行うことが可能になった。重要な技術課題は、低減された帯域幅と、デスクトップＰＣと比較し著しく小さい処理パワーとに対処するために、該サービスをいかに適合させるかである。プッシュ・トゥ・トーク・オーバー・セルラー（ＰｏＣ：Ｐｕｓｈ−ｔｏ−ｔａｌｋ−ｏｖｅｒ−ｃｅｌｌｕｌａｒ）は、移動体装置の半二重ＶｏＩＰシステムを定義する。無線データ通信ネットワークのパケット交換機能を使用することにより、このサービスは、個人移動無線（ＰＭＲ：ｐｒｉｖａｔｅｍｏｂｉｌｅｒａｄｉｏ）などの従来の双方向無線システムとは違って、地理的に制限されない。

ＰｏＣを成功させるためには、ハンドセットとネットワークの性能を最適にしなければならない。性能に影響を及ぼすいかなる遅延も、同サービスの成否の差をもたらし得る。

ＰｏＣの音声品質は、セルラーシステム上で利用可能なＧＰＲＳ／ＥＧＰＲＳ帯域幅により制限される。音声データは、ユーザー・データグラム・プロトコル（ＵＤＰ）確認無しトランスポートプロトコルに加えリアルタイムトランスポートプロトコル（ＲＴＰ）でパッケージ化された適応マルチレート（ＡＭＲ：ＡｄａｐｔｉｖｅＭｕｌｔｉ−Ｒａｔｅ）符号を使用したＰｏＣシステムを介して、送信される。その結果、損失パケットは決して再送信されない。

ＰＴＴは、音声データのバッファリングを最小に抑えて通話バーストの開始から再生開始までの待ち時間を低減するリアルタイムアプリケーションである。遅延したパケットをシステムが廃棄できるように、各ＲＴＰパケットにはタイムスタンプが押され、これにより通話バーストが無制限に増大するのを回避する。

ジッタを減らすためにバッファリングし、順番がバラバラで受信されたパケットを修正するためにパケット再順序付けを行うことにより、ＡＭＲ・ＲＴＰパケットのダウンリンクストリームを改善する様々な技術が、今日、導き出されている。しかしながら、アップリンク（送信側）における制限された帯域幅は、ダウンリンクにおいて修正不可能な損失パケットを引き起こすということが示されている。この帯域幅制限は、輻輳（congestion）により、または最小限のデータリソースを有するシステムにより、引き起こされ得る。現在、アップリンクにおいて帯域幅を低減する唯一のメカニズムは、ＡＭＲの符号化レートを変更することである。この手法のみでは、ＧＰＲＳリンク上の最小限の帯域幅に起因する損失パケットを回避するのに、十分な帯域幅低減を提供することはできない。制限された帯域幅による問題は、最低４．７５ｋｂのＡＭＲ符号化レートの使用中に観察されている。

必要とされるのは、ＡＭＲペイロードフォーマットを使用したＰｏＣまたは他の会話型サービスＩＰベースアプリケーション（conversational service IP based application）において、アップリンク帯域幅をさらに節約するシステムおよび／または方法である。

要約
適応マルチレート（ＡＭＲ）ペイロードフォーマットを使用したインターネットプロトコル（ＩＰ）べ−スシステムの音声品質を向上させるためのシステム、方法、コンピュータプログラムを提示する。

本方法は、標準ＲＴＰ・ＡＭＲフレームパッキング手順にさらなる知能レベルを与える。ネットワークの輻輳を示すネットワークバッファがその閾値を超えた場合、現在のＲＴＰパケット内にＡＭＲフレームに代わってデータ無しフレーム（ＮＯＤＡＴＡｆｒａｍｅ）を挿入すべきかどうかを判断する。ネットワーク状態が過度に輻輳している場合、データ無しフレームを現在のＲＴＰパケットに挿入する。本処理は、受信ＡＭＲフレーム毎に繰り返される。本処理は、データ無しフレームでＡＭＲフレームを置換することに先立って、ＡＭＲ符号化レートが可能な最低の符号化レート（lowest possible coding rate）に設定されていることをまず確認する。置換パターンは、データ無しフレームのクラスタ化を回避するために、ＲＴＰパケット全体にわたって拡散される。本処理は、また、置換に好適な候補となるであろう比較的低エネルギー値のＡＭＲフレームを選び出すことができる。

詳細な説明
ここで説明される技術は、ＡＭＲペイロードフォーマットまたはＡＭＲフレームを束ねる任意のプロトコルを使用した、任意の会話型サービスＩＰベースアプリケーションに適用可能である。さらに、本発明は、輻輳期間中の帯域幅を節約するために、移動端末またはアプリケーションサーバにおいて実施することができる。本検討では、例示的な実施形態としてプッシュ・トゥ・トーク・オーバー・セルラー（ＰｏＣ）を用いて、本発明の概念を説明するための根拠を与える。さらに、本発明は、会話型サービスＩＰベースアプリケーションの受信側ではなく伝送側又は送信側の帯域幅節約に取り組む。

本発明は、ＲＴＰパケット内の良好なデータフレームをデータ無しフレームで置換することにより、アップリンクにおける帯域幅をさらに低減することを提案する。この手法は、損失ＡＭＲ・ＲＴＰパケット数を低減することにより、音声品質を巧みに（gracefully）低下させる手段を提供する。

ＧＰＲＳの輻輳中に送信されるＲＴＰパケットサイズを低減するために、本発明は、携帯電話内のＧＰＲＳモジュールからのフィードバックを利用する。

ＲＴＰパケットは、ＰＴＴ通話バースト中に移動端末内の音声サブシステムから一定レートで生成される。このレートが、ＧＰＲＳネットワークにわたってパケットを送信できるレートを超えると、パケットはバッファリングされる。その検査をしないと、バッファは無制限に増大し、最終的に損失パケットを生じることになるであろう。データをバッファリングすることは、また、送信を遅らせる影響がある。タイムスタンプがＲＴＰパケットに挿入されているので、かなりの遅延があれば、受信側で当該パケットを廃棄させ、通話バーストが伸びないようにすることができる。本発明は、良好なＡＭＲフレームの一部をデータ無しフレームで置換することにより、バッファリングされるパケットのサイズを低減させる。この技術は、システムがＡＭＲ符号化レートを最小４．７５ｋｂのレートに戻した後に、使用されるであろう。この技術は、全パケットではなくデータの一部を捨てることにより、バッファリングされるパケットを圧縮し、音声データの完全性を維持する。

図１は、標準的なＰｏＣ操作で使用されるアップリンク側の一般的なデータフローを例示する図である。上述のように、本発明は、移動端末またはＰｏＣサーバーにおいて実行することができる。したがって、図１の参照番号１００は移動端末またはＰｏＣサーバーのいずれかを表すことができる。説明の残りは、説明を簡単にするためにＰｏＣサーバー１００の用語を採用する。

音声データは、マイクロホン１１０へのアナログ入力として始まる。ディジタル信号プロセッサ（ＤＳＰ）１２０は、２０ミリ秒毎に１フレームのレートでアナログ音声データをディジタル化されたＡＭＲフレームに変換する。次に、ＡＭＲフレームはプッシュ・トゥ・トーク（ＰＴＴ）クライアント１３０にルーティングされる。ＰＴＴクライアント１３０は、１〜２０個の範囲の任意数のＡＭＲフレームを単独ＲＴＰ・ＡＭＲペイロードパケットに束ねる。次に、ＡＭＲフレームペイロードを含むＲＴＰパケットは、ＩＰスタック１５０にルーティングされる。この時点で、帯域幅が利用可能になると、ＧＰＲＳ／ＥＧＰＲＳスタックは、ＩＰスタック１５０からＩＰパケットをフェッチする。帯域幅が利用可能な場合、ＩＰパケットはアンテナ１７０を介しＧＰＲＳ／ＥＧＰＲＳネットワーク１６０を経由して送信される。帯域幅が利用可能でない場合、ＩＰパケットはＧＰＲＳネットワークモジュール１６０内にバッファされる。バッファが大きくなり過ぎると、パケットは失われる。

図２は、本発明の概念を実施するための論理フローを例示するフローチャートである。ＡＭＲフォーマット化されたＲＴＰパケットは、１〜２０個の範囲の任意数のＡＭＲフレームを含む。移動端末は、音声ＣＯＤＥＣからＡＭＲフレームを収集する（２０５）。通常状態では、ＡＭＲフレームは、セッションネゴーシエーションされたパラメータに基づいてＲＴＰパケットにパッキングされ、送信される。本発明では、パッキングアルゴリズムが、いずれかのフレームをデータ無しフレームで置換すべきかどうかを判断するであろう。第１段階は、ＧＰＲＳバッファリング閾値に達したかどうかを検査することである（２１０）。ＧＰＲＳバッファになお余裕があれば、ＡＭＲフレームはＲＴＰパケットに挿入される（２１５）。ＲＴＰパケットは一杯になっているかどうかを検査される（２２０）。一杯であれば、ＲＴＰパケットは送信される（２２５）。未だ一杯でなければ、別のＡＭＲフレームを得るために制御は元に戻る（２０５）。

ＧＰＲＳバッファ閾値に達したか超えた場合、ＡＭＲコーデックレートが可能な最低速度に設定されているかどうかを調べる検査が行われる（２３０）。そうでなければ、最低ＡＭＲコーデックレート（４．７５ｋｂｐｓ）にリセットされ（２３５）、バッファ閾値は再検査される（２１０）。しかしながら、ＧＰＲＳバッファが一杯で、かつ、ＡＭＲコーデックレートが可能な限り低い場合、現在のＡＭＲフレームを間引くべきかどうかの判断を行なう（２４０）。本アルゴリズムがＡＭＲフレームを間引かないことを決定した場合、ＡＭＲフレームはＲＴＰパケットにそのまま挿入される（２１５）。現在のＡＭＲフレームが間引かれる場合、データ無しフレームは、ＲＴＰパケット内の良好なＡＭＲフレームに置き換わり（２４５）、帯域幅への負担を緩和するデータ圧縮をもたらす。ＲＴＰパケットは一杯となっているかどうかを検査され（２２０）、もしそうならば、ＲＴＰパケットは送信される（２２５）。そうでなければ、別のＡＭＲフレームが取得され（２０５）、上記処理が繰り返される。

本アルゴリズムは、生成されたレートでＩＰパケットがＲＦリンクを経由して送信されているかどうかを判断するために、ＧＰＲＳ（ネットワーク）モジュールを監視する。ＧＰＲＳモジュールは、送信前にデータを格納するバッファを含む。該バッファの設計は、バッファが一杯になり始めたときにＰＴＴモジュールに通知するメカニズムを提供する。通常状態では、バッファは一杯にならないはずであるが、輻輳状態では、バッファは一杯になる。ＰＴＴモジュールは、この通知を用いて、どのようにＡＭＲフレームをＲＴＰパケット内にパッキングするかを制御する。ＧＰＲＳモジュールからの通知メカニズムは、ＰＴＴモジュールがネットワークの輻輳に基づいてパケット置換を増やすか減らすことができるように、バッファのステータスをＰＴＴモジュールに提供する。通常状態では、フレームの置換は発生しない。最悪ケースの状況では、パケット全体がデータ無しフレームで一杯になる。

データ無しフレームはＡＭＲデータを含んでいないので、各フレーム置換は、最小でフレームサイズを１２対１に縮小することができる。パッキングアルゴリズムは、データ無しフレームのクラスタ化を回避して音声への影響を低減するために、良好なＡＭＲフレームのデータ無しフレームによる置換を拡散させようと努力する。

図３は、本発明の間引き処理を実施する方法をさらに例示するフローチャートである。アルゴリズムを拡張することにより、最小の音声エネルギーを有するフレームを識別して、音声への影響をさらに低減する置換を行う。間引き判断処理では、ＡＭＲフレームのエネルギーレベルを判断するであろう（３１０）。それが閾値未満であれば（３２０）、データ無しフレームで置換するための好都合な候補である。エネルギーレベルが閾値より大きい場合（３２０）、ＡＭＲフレームを置換するための第２の判断は、他の要素に基づいて行なうことができる（３３０）。この考えは、まず、すべての低エネルギーＡＭＲフレームを間引くことである。

図４に、ＡＭＲフレーム置換無しの発信元におけるサンプルＲＴＰパケットを例示する。この例は、それぞれが、１０個のＡＭＲフレームと、全部で３０個のデータフレームに対するパケットヘッダとを含む３つのＲＴＰパケットを示す。

図５に、現在のネットワーク輻輳状態に起因していくつかのＡＭＲフレームが取り除かれた発信元におけるサンプルＲＴＰパケットを例示する。図４と比較して、各ＲＴＰパケットは、１０個ではなく７個のＡＭＲフレームを含む。さらに、間引かれた（missing）または置換されたＡＭＲフレームは、間引フレームのクラスタ化を回避するために一定の分布にわたって拡散されている。

図６では、送付先における、置換されないＡＭＲフレームと置換されたＡＭＲフレームのＲＴＰパケットを比較する。左側の列は、発信元において実行されたフレーム置換無しのＡＭＲフレームの受信ＲＴＰパケットを表す。この例では、発信元ＲＴＰパケットは図４に示されたものである。しかしながら、ネットワークは輻輳し、かつ、ＩＰスタックは過剰にバッファされ、その結果、送付先においてＲＴＰパケットの１つが損失した。これは、ＡＭＲフレーム１１〜２０が存在すべき場所のデータ無しフレームとして示される。全ＲＴＰパケットの損失は、顕著でかなり望ましくない影響を音声品質に与える。

図６の右の列は、発信元において実行されたフレーム置換を有するＡＭＲフレームの受信ＲＴＰパケットを表す。この例では、発信元ＲＴＰパケットは図５に示したものである。ネットワークは輻輳していたため、発信元は、データ無しフレームでいくつかのＡＭＲフレームを置換した。この置換は、比較的均一な分布でＲＴＰパケット全体にわたり拡散された。したがって、実際は、同じ数のＡＭＲフレームが失われたが、ＲＴＰパケットまるごとは失われなかった。各ＲＴＰパケットは、２〜３個のフレーム損失を若干被るが、全体の音声品質は急激または突然に悪化せず、会話は比較的正常に続けることができる。

様々なコンピュータプログラム命令形式のコンピュータープログラムコードを、本発明の実施形態の実行に関与する処理の少なくとも一部を実施するために使用することができるということに留意されたい。このようなコンピュータープログラムコードは、媒体に格納されたコンピュータプログラム命令のすべてまたは一部を含むコンピュータプログラム製品によって提供することができる。媒体は固定されていても取り外し可能であってもよい。このような媒体は固定記憶媒体であってもよいが、同時に、簡単に取り外し可能な光または磁気ディスク、またはテープであってよい。本コンピュータプログラム命令は、コンピュータプラットフォーム、命令実行システム、あるいはバスまたはネットワークを介して相互接続されるこれらシステムの集合のうち任意のタイプにより実行されるコンピュータープログラムコードを含む、格納する、通信する、伝達する、または運ぶことができる任意の媒体上に存在することができる。このようなコンピュータ可読媒体は、限定するものではないが、例えば、電子、磁気、光、電磁気、赤外線、または半導体のシステムまたは装置であってよい。

本発明のすべてまたは一部を実施するコンピュータプログラム命令は、また、インターネットなどのネットワーク上で検索されるストリーム情報で具現化されてもよい。コードは、例えば光走査を介して電子的に取り込み、次に、コンパイルされインタープリートされるか、そうでなければ好適なやり方で処理されるので、コンピュータ利用可能またはコンピュータ可読媒体は、コンピュータープログラムコードが印刷される紙または別の好適な媒体であってもよいことに留意されたい。

本発明の特定の実施例がここに開示された。本発明は他の環境において他のアプリケーションを有してもよいということを当業者は容易に認識するであろう。実際、多くの実施形態と実施方法が可能である。特許請求範囲は、本発明の範囲を上述の特定の実施形態に限定することを意図するものでは決してない。なお、「するための手段」というすべての記述は、要素と請求項の「手段プラス機能」解釈を喚起することを意図しており、一方、具体的に「するための手段」という記述を使用しないすべての要素は、請求項がそれ以外に「手段」という言葉を含んでも、「手段プラス機能」として解釈されるように意図するものではない。

図面の簡単な説明
標準的なＰｏＣ操作で使用される一般的なアップリンク側データフローを例示する図である。本発明の概念を実施するための論理フローを例示するフローチャートである。本発明の間引き処理をさらに例示するフローチャートである。発信元におけるＡＭＲフレーム置換無しサンプルＲＴＰパケットを例示する。いくつかのＡＭＲフレームがデータ無しフレームで置換された発信元におけるサンプルＲＴＰパケットを例示する。送付先における、置換されないＡＭＲフレームと置換されたＡＭＲフレームのＲＴＰパケットを比較する。

Claims

適応マルチレート（ＡＭＲ）ペイロードフォーマットを使用したインターネットプロトコル（ＩＰ）べ−スシステムの音声品質を向上させる方法であって、
ＡＭＲフレームを取得する工程（２０５）と、
輻輳したネットワーク状態の結果として、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットのバッファが閾値容量に達したかどうかを判断する工程（２１０）と、
前記バッファがまだ前記閾値容量に達していない場合、ＲＴＰパケット内に前記ＡＭＲフレームを挿入する工程（２１５）と、
前記バッファが前記閾値容量に到達した場合、現在のネットワーク輻輳状態に基づいて現在のＲＴＰパケット内にデータ無しフレームを挿入するタイミングを判断する工程（２４０）と、
ネットワーク状態が所定の輻輳を示した場合、現在のＲＴＰパケット内にデータ無しフレームを挿入する工程（２４５）と、
前記ＲＴＰパケットが一杯になっているか検査する工程（２２０）と、
一杯であれば、前記ＲＴＰパケットを送信する工程と、
一杯でなければ、別のＡＭＲフレームを取得する工程と、
を含む方法。
前記ＡＭＲフレームをデータ無しフレームで置換し、現在のＲＴＰパケットに挿入する（２４５）前に、ＡＭＲ符号化レートが可能な最低設定値に設定されているかどうかを判断する工程（２３０）と、そして、前記ＡＭＲ符号化レートが可能な最低設定値に設定されていないならば、
前記ＡＭＲ符号化レートを可能な最低設定値に再設定する工程（２３５）と、をさらに含む、請求項１に記載の方法。
データ無しフレームのクラスタ化を回避するために、前記置換されたデータ無しフレームを前記ＲＴＰパケット全体にわたって拡散する工程をさらに含む、請求項２に記載の方法。
規定されたエネルギーレベルを下回るＡＭＲフレームを識別する工程（３２０）と、
ＡＭＲフレーム置換が必要になれば、閾値より大きなエネルギーレベルを有するＡＭＲフレームに先立って、前記規定されたエネルギーレベル未満のＡＭＲフレームを置換する工程（２４５）と、をさらに含む、請求項３に記載の方法。
適応マルチレート（ＡＭＲ）ペイロードフォーマットを使用したインターネットプロトコル（ＩＰ）べ−スシステムの音声品質を向上させるシステムであって、
ＡＭＲフレームを取得するための手段（２０５）と、
輻輳したネットワーク状態の結果として、リアルタイムトランスポートプロトコル（ＲＴＰ）パケットのバッファが閾値容量に達したかどうかを判断するための手段（２１０）と、
前記バッファがまだ前記閾値容量に達していない場合、前記ＲＴＰパケット内に前記ＡＭＲフレームを挿入するための手段（２１５）と、
前記バッファが前記閾値容量に到達した場合、現在のネットワーク輻輳状態に基づいて現在のＲＴＰパケット内にデータ無しフレームを挿入するタイミングを判断するための手段（２４０）と、
ネットワーク状態が所定の輻輳を示した場合、現在のＲＴＰパケット内にデータ無しフレームを挿入するための手段（２４５）と、
前記ＲＴＰパケットが一杯になっているか検査するための手段（２２０）と、
一杯であれば、前記ＲＴＰパケットを送信し、一杯でなければ、別のＡＭＲフレームを取得するように制御するための手段と、
を含むシステム。
前記ＡＭＲフレームをデータ無しフレームで置換し、現在のＲＴＰパケットに挿入する前に、ＡＭＲ符号化レートが可能な最低設定値に設定されているかどうかを判断する（２３０）ための手段（２４５）と、そして、前記ＡＭＲ符号化レートが可能な最低設定値に設定されていないならば、
前記ＡＭＲ符号化レートを可能な最低設定値に再設定するための手段（２３５）と、をさらに含む、請求項５に記載のシステム。
データ無しフレームのクラスタ化を回避するために、前記置換されたデータ無しフレームを前記ＲＴＰパケット全体にわたって拡散するための手段をさらに含む、請求項６に記載のシステム。
規定されたエネルギーレベル未満のＡＭＲフレームを識別するための手段（３２０）と、
ＡＭＲフレーム置換が必要になれば、閾値より大きなエネルギーレベルを有するＡＭＲフレームに先立って、前記規定されたエネルギーレベル未満のＡＭＲフレームを置換するための手段（２４５）と、をさらに含む、請求項７に記載のシステム。