JP5351170B2 - 無線パケットネットワークにおける効率的なマルチメディア伝達のための方法および構成 - Google Patents

Description

様々な用途に無線ネットワークが使用される。従来、主な用途は、回路交換ネットワークによって伝達される音声であった。以来、ネットワークは回路交換データおよびパケット交換データを伝達するものへと適応してきた。高速ネットワークにより、映像電話がいずれ利用可能となろう。

このような枠組みでは、環境にサービスを合わせる機能は、限られた量しか存在しない。例えば、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：グローバルシステムフォーモバイルコミュニケーションズ）ネットワークおよびＷＣＤＭＡ（Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ：広帯域符号分割多元アクセス）ネットワークは、音声用にＡＭＲ（Ａｄａｐｔｉｖｅ Ｍｕｌｔｉ−Ｒａｔｅ：適応マルチレート）ボコーダを使用する。ＡＭＲボコーダは、チャネル条件を変化させることでソースレートの変化を容易にし、知覚パフォーマンスを最良にできるものである。ＡＭＲでは、受信条件が変化し、別のボコーダレートが好ましいということを、遠くのボコーダへ信号送信する手段が存在する。

典型的に、このようなネットワークでは、あるボコーダが移動装置にあり、別のボコーダがネットワークにおけるトランスコーダ部またはメディアゲートウェイにある。メディアゲートウェイは、他のネットワークで伝送可能な形態に、エンコードした音声を変換する。このように、移動装置とメディアゲートウェイとの間にレートの変化が生じる。一般に、無線リンクの品質の情報は基地局と移動装置とでしか入手可能ではなく、この情報はボコーダへ信号送信しなければならない。ボコーダは移動装置でローカルに使用可能なものであるか、あるいはメディアゲートウェイの場合にはリモートノードである。ＧＳＭネットワークでは、ＡＭＲパケット内の帯域内信号送信を使用して、リモートエンドのボコーダへ所望のボコーダレートを信号送信する。このように、個々の無線リンクの条件に応じて、ボコーダレートを調節することができる。ＷＣＤＭＡネットワークでは、帯域外信号送信を使用して、所望のボコーダレートを信号送信する。これについては、特に回路ベースの音声送信に適用可能である。

無線ネットワークはパケット交換構成へ徐々に切り換えられており、トレンドは、全てのアプリケーションデータについてパケット交換を使用して伝達する方向である。例えば、初期的な音声電話伝達手段として、ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ＩＰ：ボイスオーバＩＰ）が考えられている。映像、音声、その他のマルチメディアアプリケーションを含む他のほとんどのアプリケーションも、パケットネットワークを介して伝達されるであろう。このようなアプリケーションのリアルタイムソース情報は、典型的に、ソースにおいて各パケットにタイムスタンプとシーケンス番号とを添付するＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ：リアルタイムプロトコル）を使用して送信される。ＲＴＰパケットは、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ：ユーザデータグラムプロトコル）とＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：インターネットプロトコル）とを使用して送信される。宛先では、受信部がタイムスタンプ情報を使用して、正しい相対時間にパケットを再生することができる。加えて、タイムスタンプを使用して、パケットがその宛先への道すがら、その有用性を失ってしまったかどうか判定することも可能である。失われたパケットや複製したパケットを追跡するには、シーケンス番号を使用する。ＲＴＰプロトコルは、ソースと受信部との間でオペレーションを行うものである。受信部で解読不可能なフォーマットで情報を送信するソースもあろう。すると、メディアゲートウェイがこれを受信部が理解するフォーマットへ変換する。このようなオペレーションについては、セッションのセットアップの間に交渉される。この場合、ＲＴＰプロトコルがメディアゲートウェイと受信部との間でオペレーションを行うものである。

ＩＰの枠組みでは、限られた量のリンク能力の適応は、限られた量しか可能ではない。多くのソースは、リンクの平均品質に適したフォーマットにデータをエンコードする。これについては、しばしば、リンク能力（例えば１２８ｋｂｐｓや１Ｍｂｐｓなど）についての受信部に対するクエリによって行われる。あるいは、リンクを鳴らしてデータ能力に関するフィードバックを得ることによって、自動的に行うことも可能である。しかしながら、この方法は、品質が動的に変動し得るリンクには適していない。無線リンクの品質は、フェードのスピードで変動し、またトラフィックレベルが変動するとともに変動し得るものである。このような場合、フィードバック提供における遅延は、効率的なリンク適応が不可能なほど大きくなることがある。パケット交換無線ネットワークにおいて、最適送信フォーマット（ボコーダレートなど）は、瞬間無線チャネル品質や、トラフィック付加や再送スキーム（ハイブリッドＡＲＱなど）のような他の要因を考慮しなければならない。この情報のほとんどが基地局でしか入手可能ではなく、リモートソースコーダでは入手可能ではない。これら全てのパラメータの情報をリモートソースコーダへ適切に送信して、コーダが瞬間条件に対応できるようにするには、目下大きな技術的問題がある。

上述のおおきな技術的問題を克服するため、いわゆるＭパイプ（Ｍ−ｐｉｐｅ）プロジェクトが目下計画されている。Ｍパイププロジェクトでは、条件に局所的に適応可能な拡張可能エンコーディングを作成する新たなメディアコーデックを開発しようとしており、このようなエンコーディングの拡張可能な性質をネットワークノードへ伝えるために使用可能な信号送信機構の開発中である。不都合なことに、このプロジェクトは、拡張可能なメディアを作成しない既存のメディアコーデックを使用することができない。

ＤＶＢ−ＴやＤＶＢ−Ｈなどのシステムにおいて、階層的（ｐｒｏｇｒｅｓｓｉｖｅ）で拡張可能なエンコーディングが使用される。ここでは、階層変調スキーム（例えば１６ＱＡＭやＱＰＳＫ）を使用して、無線条件が異なるユーザへ、忠実度が異なるソースデータを伝える。このようなオペレーションは、主にブロードキャスト送信のためのものであって、ある特定のユーザに適応するという概念は、これらのシステムにおいては考慮されない。

バラチャンドラン（Ｂａｌａｃｈａｎｄｒａｎ）ならびにラメシュ（Ｒａｍｅｓｈ）に対する米国特許第７１，１９４，０００号において、ソースデータの階層的エンコーディングが、データの重要性に基づいてパケットに割り当てられた様々な性質を有する複数のパケットでエンコードされる方法が記載されている。スケジューリング機能は、優先度が低いパケットをドロップすることが可能であるが、いくらかの忠実度レベルでマルチメディア情報を与えるには十分なソースデータを伝達することが可能である。不都合なことに、この方法では、粗いレベルでしか無線条件に対する適応ができない。

所望されるは、かかる詳細なフィードバックを必要とせずに、最良の送信用フォーマットを選択する方法およびシステムである。

本発明は、条件が急速に変動する無線環境において効率的にマルチメディアデータを伝達可能とする方法を提供する。本発明は、本発明の方法の実施を容易にする、機能が拡張されたネットワーク構造とネットワークノードとのシステムを提供する。効率的なマルチメディアデータ伝達は、ＩＰネットワークにおいて使用されるトランスポートプロトコル（例えばＴＣＰ、ＵＤＰ、インターネットプロトコル（ＩＰ）など）に修正を行わず、ＲＴＰのペイロードフォーマットに小さな修正を行って達成される。加えて、本発明は、ＩＰに基づくネットワークにおいて使用される従来のプロトコルを使用することによって、ネットワークにおける信号送信機能の機構を提供する。

本発明は、マルチメディアパケットの複数のバージョンを基地局へ送信し、無線チャネルおよびトラフィック特性に基づいて、基地局は、任意の時間に移動局へ送信するのに適切なバージョンを選択し、瞬間条件へソース送信を改善する。これについては、インターネットプロトコル（ＩＰ）ネットワークによるマルチメディア送信に使用されるＲＴＰに関して行われる。第１実施形態では、複数のバージョンが同一のＲＴＰパケットで基地局へ送信され、ふさわしくないバージョンを基地局が取り除く。第２実施形態では、多くのフィールドのパケットヘッダに同一の情報を有する基地局は複数のＲＴＰパケットを受信し、これらの中で、移動局への送信に適切な１つを選択し、残りは放棄する。

以下のセクションでは、図面に示す実施形態例を参照しながら、本発明を説明する。

図１は、本発明による、マルチメディアを伝送する移動ネットワークの構成を示す。 図２は、本発明の実施形態において使用されるＲＴＰパケットの図である。 図３は、本発明の方法の第１実施形態を示したフローチャートである。 図４は、本発明の方法の第２実施形態を示したフローチャートである。 図５は、送信移動局由来のメディアを示した本発明の一態様である。 図６は、メディアゲートウェイでトランスコード（つまり、１つの（通常）エンコーディング‐デコーディングではなく、トランスコーディングは２つのエンコーディング‐デコーディングステージを使用する）され、１または複数のＲＴＰパケットにカプセル化されている元のメディアを示した本発明の一態様である。 図７は、基地局で受信され、処理されているエンコード化メディアのいくつかのバージョンを示しており、１つのバーションが受信移動局へ送信されている本発明の一態様である。

図１は、本発明による、マルチメディアを伝送する移動ネットワーク１００の構造を示している。ここに見られるように、移動局１０１がエアインタフェース１０３を介して基地局１０２と通信する。基地局１０２は、バックボーンネットワーク１０４に接続されている。バックボーンネットワーク１０４は、移動局１０１、無線アクセスネットワーク、メディアゲートウェイ（図示せず）、そして別の端末またはサーバ１０５の間の通信を可能にする。多くの状況において、端末またはサーバ１０５は、移動局１０１が理解可能なマルチメディア情報を生成することができる。このような場合、端末またはサーバ１０５は、ＲＴＰパケットにマルチメディア情報をカプセル化する機能を行うことも可能である。ＲＴＰパケットは、ＵＤＰなどのプロトコルを使用してＩＰネットワークによって伝送することができる。他の状況においては、メディアゲートウェイ１０６が、端末またはサーバ１０５から受信した信号を、移動局１０１が理解可能なフォーマットに変換する。この場合、メディアゲートウェイ１０６または関連ノードは、ＲＴＰパケットへのマルチメディア情報のカプセル化を行うことができる。

図２に見られるように、ＲＴＰパケット２００は、ヘッダ情報とペイロード情報とからなる。ヘッダ情報は、ペイロードタイプフィールドとシーケンス番号とタイムスタンプとを含む。ペイロードタイプフィールドは、マルチメディア情報のタイプと、使用されるマルチメディアコーデックとを識別する。例えば、ペイロードタイプは、ＡＭＲコーデックが使用されたと示すかもしれない。シーケンス番号は、受信部が使用して、パケットを配列し、失われたパケットの情報を得る。タイムスタンプは、マルチメディア情報を再生する必要がある相対時間の情報を、受信部におけるマルチメディア再生装置に与える。私用される特定ＡＭＲコーディングレートは、ＲＴＰヘッダの部分ではなく、ＲＴＰペイロードの最初の数ビットで信号送信される。ペイロードの残りは、エンコードされたスピーチビットを含む。ペイロードサイズはＡＭＲコーディングレートに応じて変化するということが了解されよう。

図１を再度参照すると、多くのＩＰネットワークにおいて、基地局１０２（または関連ゲートウェイ１０６）が、プロトコルスタックの収束（ｃｏｎｖｅｒｇｅｎｃｅ）サブレイヤの一部としての多くのトランスポートプロトコルに対して、プロトコルヘッダ圧縮の機能を行っている。特に、基地局１０２は、冗長な情報、予測可能な情報、不変の情報を削除することによって、ＲＴＰ／ＵＤＰ／ＩＰヘッダの圧縮を行うことができる。このようなヘッダ圧縮スキームの１つであるＲＯＨＣ（ｒｏｂｕｓｔ ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ：強固ヘッダ圧縮）が、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ：インターネットエンジニアリングタスクフォース）ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ：リクエストフォーコメンツ）３０９５に定義されており、その強固性から無線ＩＰネットワークにおいて広く使用されることを期待されている。基地局１０２はＲＴＰパケットのヘッダを解析して、かかる圧縮を行うということが了解されよう。

本発明では、同一のマルチメディア情報の複数のバージョンが生成される。アップリンクでは、大概、移動局１０１はソース情報を生成し、チャネル条件の知識へのアクセスも有しており、したがって適切なバージョンに対応したソース情報を効果的に生成することができる。また、移動局１０１は、様々なＡＭＲコーディングレートで音声用の複数のＡＭＲエンコード化パケットを生成するが、単一のＲＴＰパケットを使用して無線チャネルの目下の条件に最も適した１つのみを送信することができる。このように、マルチメディア情報の送信は、アップリンクについては簡単に改善することができる。一般に、基地局は、何らかの形で移動局の送信によって経験された移動局チャネル条件の知識を有している。このような情報に基づいて、多くの無線システムにおける基地局は、移動局に送信リソースを割り当てる。リソースを適切に割り当てることによって、基地局は、移動局に特定の送信フォーマットを使用させることができる。あるいは、基地局は、移動局に特定の送信フォーマットを使用するよう命令することも可能である。

ダウンリンクでは、問題はより複雑である。同一のマルチメディア情報の複数のバージョン（時にはエンコーディングという）は、端末またはサーバ１０５で生成することができるし、あるいはメディアゲートウェイ１０６やネットワークにおけるトランスコーディング機能でも生成することが可能である。これらの同一のマルチメディア情報の複数のバーションは、単一のＲＴＰパケットで送信することもできれば、複数のＲＴＰパケットで送信することもできる。

図３は、本発明の第１実施形態の方法のフローチャート３００を提供する。ここに見られるように、ステップ３０１において、ソースまたはメディアゲートウェイは、同一のＲＴＰパケットに同一のソース情報の様々なバージョンを使用して複数のソースサブパケットを、パケット内に様々なバージョンがいくつあるかを示すサブヘッダと、その長さとともに埋め込む。ステップ３０２において（代替の実施形態では、ステップ３０２はステップ３０１の前に発生することもある）、移動局は、そのチャネル条件に関する情報を基地局にフィードバックする。基地局は、ネットワークにおけるロードレベルなどの他の要因へのアクセスも有している。ステップ３０３において、基地局は、ステップ３０２において移動局から受信した情報に基づいて、ステップ３０４において移動局へ転送する前に、送信するのに適切なサブパケットを選択し、ＲＴＰパケットから他のサブパケットとサブヘッダとを取り除く。ＩＥＴＦ ＲＦＣ ２１９８「RTP Payload for Redundant Audio Data（冗長な音声データに対するＲＴＰペイロード）」に記載のものから修正したペイロードフォーマットを、複数のエンコーディングが同一のＲＴＰパケットに含まれる実施形態例として使用することができる。ＩＥＴＦ ＲＦＣ２１９８は、冗長なデータを有してパケット損失を防止するために、現マルチメディアフレームおよび以前のマルチメディアフレームのペイロードデータを送信する方法を説明している。しかしながら、ＩＥＴＦ ＲＦＣ ２１９８においては、タイムスタンプオフセットが、以前のフレームの２次データで送信される。

対照的に、本発明では、ＩＥＴＦ ＲＦＣ ２１９８のものと同一のペイロードフォーマットを使用して、複数のペイロードを同時に送信することが可能であるが、本発明ではタイムスタンプオフセットがゼロに設定される。基地局におけるパケットフィルタが、この混合パケットを解析し、ステップ３０３において、ダウンリンクで移動局へ送信するのに適切な種類を選択する。上記のように、基地局は、移動局からのそのチャネル条件に関するフィードバックと、場合によってはネットワークにおけるロードレベルなどの他の要因とに応じて、（適切なヘッダ圧縮の後に）移動局へ送信する複数のバージョンの適切なパケットを選択する。このように、基地局は、収束機能とスケジューリング機能とを組み合わせたオペレーションを行う。スケジューリングオペレーションを選択して、移動局へのリンクに関するエラーパフォーマンスを改善したり、サービス中のトラフィックのレベルを改善したり、この２つを適切に組み合わせて改善したりすることができる。本発明は、無線インターネットプロトコル（ＩＰ）ネットワークによるマルチメディア伝達を改善する方法を含み、当該方法は、マルチメディアパケットの複数のバージョンを生成するステップと、マルチメディアパケットの複数のバージョンを基地局へ送信するステップと、無線チャネル特性、ネットワーク特性、および／またはトラフィック特性などのオペレーティング条件に基づいて、ある時間に受信移動局へ送信するマルチメディアパケットの複数のバージョンの適切なバージョンを選択するステップとを有する。トラフィック特性は、ある特定の移動局へのストリームに影響を与える条件など、局所的な特性とすることができる。あるいは、セル内の全ユーザに影響を与えるある特定のセル内における局所的なもの、または１セル内の１０移動局への１０ＶｏＩＰストリームのような同一タイプのストリームについて局所的なものとすることもできる。一方、ネットワーク特性は、例えば、セルのグループのようにオペレータのシステムの大きな部分や、ある地域のネットワーク全体など、よりグローバルな規模を有しており、ルータとゲートウェイとにおける輻輳（ｃｏｎｇｅｓｔｉｏｎ）のような、無線チャネル特性もバックボーンネットワーク特性も含むであろう。

図４は、本発明の第２実施形態４００のフローチャートである。ここに見られるように、ステップ４０１において、ソース情報の様々なバージョン（例えばマルチメディア情報）が複数のＲＴＰパケットにおいて生成される。これら複数のパケットのＲＴＰヘッダにおけるペイロードタイプ情報、シーケンス番号情報、タイムスタンプ情報は全て同一であるが、ペイロードは異なる。ステップ４０２において、これらのパケットの全てが、ＵＤＰ／ＩＰを使用して基地局へ送信される。同一のＲＴＰシーケンス番号を有するパケットが複数あるが、これについては、ＩＰネットワークにおけるほとんどのルータおよびノードに対して透過的であり、ルータおよびノードがＲＴＰヘッダのレベルまでパケットを解析しないため、ＩＰネットワークは複数のパケットを転送するであろう。ＩＥＴＦ ＲＦＣ ３５５０に適合するＲＴＰオペレーションは、同一のシーケンス番号を有する複数のパケットの送信を明確に妨げるものではないが、従来、同一のシーケンス番号を有する複数のパケットの送信は一般的に予期されることがないものであろうということに留意されたい。

ＷｉＭＡＸやＷＣＤＭＡのＨＳＰＡ（Ｈｉｇｈ Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ：高速パケットアクセス）などの典型的な無線パケットネットワークでは、基地局内のパケットフィルタは、基地局によって適切に選択されたある時間ウィンドウ内に受信されたパケットのＲＴＰヘッダを解析する。同一のペイロードタイプ、シーケンス番号、タイムスタンプを有するが、異なる長さおよび／または異なるＡＭＲレート情報を有する複数のパケットを発見すると、パケットフィルタは、これらのパケットが同一のマルチメディア情報の複数のバージョンに対応していると認識する。ステップ４０４において、基地局は、ステップ４０３において移動局から受信した、そのチャネル条件に関するフィードバックと、場合によってはネットワークにおける輻輳レベルなどの他の要因とに応じて、（適切なヘッダ圧縮の後に）移動局に送信するのに適切なパケットを選択する。第１実施形態のように、基地局は、収束機能とスケジューリング機能とを組み合わせたオペレーションを行う。ＳＲＴＰ（Ｓｅｃｕｒｅ Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ：セキュアリアルタイムプロトコル）などのプロトコルを使用して、ＲＴＰペイロードが暗号化されると、基地局は、ペイロード内のＡＭＲレート情報を読むことができないことがあり、したがって、パケットの長さのみに基づいて決定を行うように構成されるであろう。ＲＴＰペイロードが暗号化されない場合、パケットフィルタは、ＡＭＲレート情報を読み出すことが可能であり、物理レイヤにて適切な送信スキーム（変調およびコーディングスキームなど）を選択することが可能である。明らかに、データパスにおけるパケットフィルタの加入は、端末間暗号化の欠如によって予測される。

本発明の別の態様では、寄与ソース情報はＲＴＰヘッダの一部として含まれることが可能であるため、ＲＴＰ内であり得るとして、異なる寄与ソースを使用するが、同一のタイムスタンプ情報を使用して、各ＡＭＲフォーマットが生成可能である。この実施形態では、パケットフィルタは、タイムスタンプは同一だが寄与ソース情報は異なる着信ＲＴＰパケットを検査し、このように、エアリンクによって送信するのに適切なソースフォーマットを選択する。パケットフィルタは、メディアリソース機能（ＭＲＦ：Ｍｅｄｉａ Ｒｅｓｏｕｒｃｅ Ｆｕｎｃｔｉｏｎ）の一部とすることができる。ＭＲＦの典型的な用途は、会議用のソースの混合を可能とすることである。本発明では、ＭＲＦを使用して、１または２以上の複数のソースを選択する。このような場合、同時に複数のソースの種類に対応したＲＴＰパケットは、大概、同一のタイムスタンプを有しているが、恐らくは異なるシーケンス番号と異なる寄与ソース番号とを有しており、ＩＥＴＦ ＲＦＣ ３５５０に記載のＲＴＰプロトコルのような許容可能なオペレーションの厳密なノルム内である。本発明と、ソースの様々な種類に対する様々な寄与ソースの用途とを組み合わせて、会議コールなどの特徴を可能とすることができる。このような場合、各リアルソースは、複数のバージョンについて、各リアルソースに関連する寄与ソース番号のサブセットを有するであろう。ＭＲＦにおけるパケットフィルタリングルールは、各リアルソースから、適切な寄与ソース番号を有する１パケットを選択するであろう。

本発明の別の実施形態では、端末、サーバ、メディアゲートウェイが、ＲＴＰ以下別のプロトコルヘッダやＲＴＰヘッダ拡張を使用して、同一のマルチメディア情報が別々のパケットでエンコードされていると基地局へ信号送信することも可能である。

さらに、移動体間のコールの場合に本発明を実施すると、（アップリンク上）第１移動局がそのチャネル条件に適したソース種類のみを送信するであろう。このような場合、メディアゲートウェイは、トランスコーディング機能を行い、複数のバージョンを生成することが可能であり、そして複数のバージョンは基地局におけるＭＲＦへ送信可能である。そして、基地局は、本発明によってダウンリンクで受信移動局へ送信するのに適切なバージョンを選択するであろう。このような場合、マルチメディアゲートウェイにおけるトランスコーディング機能は、送信移動体から受信されたものよりレートが低い種類のみを生成する構成とすることができる。

本発明は、映像電話の用途に実施することも可能である。この実施形態では、映像電話ソースが、コールに対応した映像および音声ストリームの複数のバージョンを有する構成とされる。このように、本発明は、チャネル品質、授与情報、輻輳に基づいて、映像および音声の種類の選択が可能である。本発明は、輻輳または無線チャネル品質が映像ストリームの連続を妨げる場合にさらに拡張することも可能である。このような場合、映像ストリームを選択的に削除することが可能であり、一方でいくつかの適当な種類の音声ストリームを送信するためにスケジューリングする。

本発明は、移動局ハンドオーバシナリオにおいて使用することも可能である。典型的に、ハンドオーバ後、移動局が無線チャネル条件を知り、送信を適切に合わせることが可能となるには、かなりの時間がかかる。本発明の方法を使用すると、新たな無線リンクへの送信フォーマットの最適化をより早く開始することができる。

ここで図５を参照すると、送信移動局からメディアが発信される本発明の態様５００が示されている。ここに見られるように、下のメディアは、複数のエンコーダ５０１Ａ、５０１Ｂ、５０１Ｃを使用して、様々なビットレート（パケットサイズ）で複数のバージョンにエンコードされる。様々なバージョンは、パケタイザ５０２を使用して、１または複数のＲＴＰパケットにカプセル化される。

図６は本発明の態様６００であり、元のメディアが、メディアゲートウェイにおいて複数のトランスコーダ６０１Ａ、６０１Ｂを使用してトランスコードされ、パケタイザ６０２を使用して１または複数のＲＴＰパケットにカプセル化されるのを示している。ここに見られるように、元のエンコード化メディアが受信され、メディアのいくつかの様々なエンコーディングバージョンにトランスコードされる。様々なバージョンは、様々なビットレートを使用し、様々なパケット／ペイロードサイズを生み出す。様々なバージョンは、１または複数のＲＴＰパケットにカプセル化される。

図７は本発明の態様７００であり、エンコード化メディアの複数のバージョンが基地局７０１において受信され、処理され、１つのバージョンが受信移動局７０２へ送信されているのを示している。ここに見られるように、エンコード化メディアの複数のバージョンが基地局によって受信される。基地局は、受信したパケットを解析し、エンコード化メディアの様々なバージョンを発見する。トラフィック特性および／または無線チャネル特性に基づいて、基地局は、どのバージョンを受信移動局へ送信するか選択する。

本発明の各実施形態では、行われる一機能は、１または２以上の種類が無線送信される前にソースの複数のバージョンを選択的に処理可能なパケットフィルタの例示である。パケットフィルタは、以下のような、あり得る１または複数の信号送信方法によって作動させる。

１．第１の方法は、無線送信の前にソースの専用処理が所望されるとコール処理機能に通知するＳＩＰ・ＩＮＦＯメッセージやＳＩＰ・ＮＯＴＩＦＹメッセージなどのコール制御技術の使用を含む。そして、この例ではＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：セッションイニシエーションプロトコル）を使用して実施されるコール制御機能は、無線ネットワークにおけるパケット処理機能を作動させる。例えば、パケット処理機能は、パケットフィルタとしても知られ、ＧＳＭ／ＥＤＧＥネットワークのＳＧＳＮにおいて、任意の２次ＰＤＰコンテキストに対して（任意でＰＦＩ（Ｐａｃｋｅｔ Ｆｌｏｗ Ｉｄｅｎｔｉｔｙ：パケットフローアイデンティティ）およびＰＦＣ（Ｐａｃｋｅｔ Ｆｌｏｗ Ｃｏｎｔｅｘｔ：パケットフローコンテキスト）を使用して）作動させることができる。あるいは、パケットフィルタは、特定の複数種類フォーマルに対して専用パケット処理機能を作動させるＭＡＣレイヤにおける分類ルールを変えることで、ＷｉＭＡＸなどのパケットネットワークでは基地局で作動させることも可能である。ＷＣＤＭＡネットワークにおいても、同様の構成で同一の目的を達成することが可能である。

２．第２の方法は、移動局に存在するサービスについての一意の知識を使用して、ある解く手の接続についてＱｏＳ特性の変更を要求することを含む。ＧＳＭ／ＥＤＧＥネットワークまたはＷＣＤＭＡネットワークでは、移動局は、ＭＯＤＩＦＹ ＰＤＰ ＣＯＮＴＥＸＴメッセージを送信して、任意のサービスについて特定パケットフィルタリング機能を作動させるであろう。ＷｉＭＡＸなどの異なる無線ネットワークでは、移動局は、基地局のＭＡＣレイヤにおける分類ルールの特性を変更して、特定の複数のバージョンフォーマットについて特定処理機能を作動させるであろう。

本発明の効果は以下のものを含む。

（１）瞬間無線ネットワークおよびエアインタフェース条件にマルチメディア送信を合わせることにより、マルチメディアエクスペリエンスをより良好なものにする。本発明は、ソースへの所望のコーデックでのフィードバックを可能とするスキームと併せて使用することも可能であることに留意されたい。典型的に、このようなフィードバックは遅く、平均よりもずっと後に送信されるが、ソースで使用されるマルチメディア情報のバージョンの数を制御するのに使用することが可能であり、そして基地局が使用して、瞬間条件に合わせることができる。

（２）本発明は、ＩＰネットワークで使用される既存のプロトコルを使用して行うことができる。結果として、本発明が与える既存のＩＰネットワーク構成要素へ影響は最小である。例えば、ネットワークにおけるルータは、ルータ機能を修正する必要なく、本発明のＩＰパケットを通過させるであろう。ＵＤＰ機構にも影響はない。

（３）端末、サーバ、メディアゲートウェイで、このような改善された送信を可能とするために、フィードバックは必要ない。

（４）ブロードキャスト／マルチキャストの適応が可能となる。例えば、使用可能な帯域幅（ユーザトラフィックにサービス後）を使用してブロードキャストマルチメディア情報を送信するブロードキャストスキームを考えることが可能であり、使用可能な帯域幅に合うソースフォーマットを使用して、ブロードキャスト機能をサポートすることができる。

当業者であれば認識するであろうが、本命最初において説明した革新的な概念は、広範囲の用途にわたって修正および変更を行うことが可能である。したがって、特許されたサブジェクトマターの範囲は、上述の特定の開示例のいずれにも限定されるべきではなく、その代わり添付の特許請求の範囲によって限定されるものである。

Claims (9)

1. 無線インターネットプロトコル（ＩＰ）ネットワークにおいて移動体間マルチメディアコールを可能とする方法であって、
   第１の移動局から第１の基地局へ、マルチメディアパケットの単一のバージョンを送信するステップと、
   前記第１の基地局からメディアゲートウェイへ、前記マルチメディアパケットを送信するステップと、
   前記メディアゲートウェイにおいて前記マルチメディアパケットの複数のバージョンを生成するステップと、
   第２の基地局へ、前記マルチメディアパケットの複数のバージョンを送信するステップであって、前記マルチメディアパケットの複数のバージョンは、単一のリアルタイムプロトコル（ＲＴＰ）パケットで送信される、前記送信するステップと、
   前記第２の基地局が、前記複数のバージョンから、第２の移動局へ送信するのに適切なバージョンを選択するステップを含み、
   前記選択するステップは、
   前記第２移動局から、マルチメディアコンテンツの受信性能に影響を与える、前記第２移動局のチャンネル特性を受信するステップと、
   前記第２基地局が、少なくとも前記第２移動局のチャンネル特性に基づいて、前記複数のバージョンから、第２の移動局へ送信するのに適切なバージョンを、選択するステップと、
   前記第２基地局が、前記単一のリアルタイムプロトコル（ＲＴＰ）パケットから他のバージョンを取り除き、選択された前記適切なバージョンのマルチメディアパケットを送信するステップを更に含む、方法。
2. 前記マルチメディアパケットの複数のバージョンは、サーバまたは端末で生成される、請求項１に記載の方法。
3. 前記マルチメディアパケットの複数のバージョンは、メディアゲートウェイのトランスコーディング機能において生成される、請求項１に記載の方法。
4. 前記第２の基地局においてパケットフィルタが、前記適切なバージョンを選択する作業を行う、請求項１に記載の方法。
5. 前記パケットフィルタは、コール処理機能へ、送信前にソースの専用処理が望まれることを通知するコール制御機能を使うように適合される、請求項４に記載の方法。
6. 前記パケットフィルタは、無線ＩＰネットワークにおいて、無線接続の品質特性（ＱｏＳ）の変更を要求するように適合される、請求項４に記載の方法。
   マルチメディアパケットの複数のバージョンは、同一のリアルタイムプロトコル（ＲＴＰ）パケットで送信される、請求項１に記載の方法。
7. 前記サブヘッダはタイムスタンプオフセットを特定する、請求項１に記載の方法。
8. 前記第２の基地局は、選択された前記適切なバージョンのマルチメディアパケットを送信する前にヘッダ圧縮を行う、請求項７に記載の方法。
9. ＩＥＴＦ ＲＦＣ ２１９８に従う前記ＲＴＰパケットフォーマットを使用して、サブパケットで前記マルチメディアパケットの複数のバージョンを送信し、前記サブパケット間にはタイムスタンプオフセットはゼロに設定される、請求項１に記載の方法。

Images