(57)【要約】【課題】無線通信システム上で伝送されるマルチメディアデータのヘッダ圧縮。【解決手段】無線通信チャネル上でのマルチメディアデータの転送を改善するための方法および装置が説明されている。これらの技術は、無線通信システムの物理層パケットサイズを決定すること、および圧縮ヘッダの最大サイズを決定することを含む。その後、情報単位をパーティションで区切る、ここでは、パーティションが符号化された後に符号化パーティションと圧縮ヘッダの総サイズが物理層パケットのサイズ以下であるようにパーティションのサイズが選択される。本技術は、様々なタイプの情報ユニット、例えばマルチメディアデータ、可変ビットレートデータストリーム、ビデオストリーム、ビデオ電話会議ストリーム、またはボイスオーバＩＰなど、に対して使用されることができる。本技術はまた、汎欧州デジタル移動電話方式（ＧＳＭ）、汎用パケット無線システム（ＧＰＲＳ）、拡張データＧＳＭ環境（ＥＤＧＥ）、またはＣＤＭＡに基づく標準規格、例えばＴＩＡ／ＥＩＡ−９５−Ｂ（ＩＳ−９５）、ＴＩＡ／ＥＩＡ−９８−Ｃ（ＩＳ−９８）、ＩＳ２０００、ＨＲＤＰ、ｃｄｍａ２０００、広帯域ＣＤＭＡ（ＷＣＤＭＡ）など、のような様々な無線インタフェースとともに使用されることもできる。【選択図】      図１１
2007537681.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システム上でデータを送信する方法であって：
前記無線通信システムの物理層パケットサイズを決定することと；
圧縮ヘッダの最大サイズを決定することと；そして
情報単位をパーティションで区切ることと、なお、ここでは、前記パーティションのサイズは、パーティションが符号化された後に前記符号化パーティションと前記圧縮ヘッダの総サイズが前記物理層パケットサイズ以下であるように選択される；
を含む方法。
【請求項２】
前記情報単位はマルチメディアデータを備える、請求項１記載の方法。
【請求項３】
前記情報単位はビデオデータを備える、請求項１記載の方法。
【請求項４】
前記ヘッダはロバストヘッダ圧縮技術に従って圧縮される、請求項１記載の方法。
【請求項５】
前記ヘッダはゼロバイトヘッダ圧縮技術に従って圧縮される、請求項１記載の方法。
【請求項６】
前記物理層パケットの前記サイズを決定することおよび前記圧縮ヘッダの前記最大サイズを決定することは、通信セッションにおけるパーティシパント間のネゴシエーションにより決定される、請求項１記載の方法。
【請求項７】
前記無線通信システムはＣＤＭＡシステムである、請求項１記載の方法。
【請求項８】
前記無線通信システムはＧＳＭシステムである、請求項１記載の方法。
【請求項９】
前記無線通信システムはＥＤＧＥシステムである、請求項１記載の方法。
【請求項１０】
前記無線通信システムはＧＰＲＳシステムである、請求項１記載の方法。
【請求項１１】
無線通信システム上でデータを送信する方法であって：
利用可能な通信チャネルの１セットの可能な物理層データパケットサイズを決定することと；
圧縮ヘッダの最大サイズを決定することと；そして
マルチメディアデータのフレームをパーティションに区切ることと、なお、ここでは、前記パーティションのサイズは、パーティションに圧縮ヘッダの前記最大サイズを加えた総サイズが前記可能なデータパケットサイズの１つと適合するように、選択される；そして
前記パーティションを符号化し、前記圧縮ヘッダを付加し、そして前記付加されたヘッダと共に前記符号化パーティションを送信することと；
を含む方法。
【請求項１２】
前記マルチメディアデータは可変ビットレートストリームである、請求項１１記載の方法。
【請求項１３】
前記マルチメディアデータはビデオストリームである、請求項１１記載の方法。
【請求項１４】
前記セットの可能な物理層データパケットサイズおよび前記圧縮ヘッダの前記最大サイズを決定することは、通信セッションにおけるパーティシパント間のネゴシエーションにより決定される、請求項１１記載の方法。
【請求項１５】
前記通信チャネルはＣＤＭＡチャネルである、請求項１１記載の方法。
【請求項１６】
前記通信チャネルはＧＳＭチャネルである、請求項１１記載の方法。
【請求項１７】
前記通信チャネルはＥＤＧＥチャネルである、請求項１１記載の方法。
【請求項１８】
前記通信チャネルはＧＰＲＳチャネルである、請求項１１記載の方法。
【請求項１９】
前記ヘッダはロバストヘッダ圧縮技術に従って圧縮される、請求項１１記載の方法。
【請求項２０】
前記ヘッダはゼロバイトヘッダ圧縮技術に従って圧縮される、請求項１１記載の方法。
【請求項２１】
利用可能な通信チャネルの可能なデータパケットサイズおよび圧縮ヘッダの最大サイズを決定するように構成されたプロセッサと；そして
マルチメディアデータをパーティションに区切るように構成され、前記パーティションを符号化し、前記圧縮ヘッダを付加する、エンコーダと、なお、ここでは、前記パーティションのサイズは、パーティションに圧縮ヘッダの前記最大サイズを加えた総サイズが前記可能なデータパケットサイズの１つと適合するように、選択される；そして
前記付加されたヘッダと共に前記パーティションを送信するように構成された送信機と；
を備えた無線通信デバイス。
【請求項２２】
前記マルチメディアデータはデータストリームである、請求項２１記載の無線通信デバイス。
【請求項２３】
前記マルチメディアデータはビデオストリームである、請求項２１記載の無線通信デバイス。
【請求項２４】
前記通信チャネルはＣＤＭＡチャネルである、請求項２１記載の無線通信デバイス。
【請求項２５】
前記通信チャネルはＧＳＭチャネルである、請求項２１記載の無線通信デバイス。
【請求項２６】
前記通信チャネルはＧＰＲＳチャネルである、請求項２１記載の無線通信デバイス。
【請求項２７】
前記通信チャネルはＥＤＧＥチャネルである、請求項２１記載の無線通信デバイス。
【請求項２８】
前記ヘッダはロバストヘッダ圧縮技術に従って圧縮される、請求項２１記載の無線通信デバイス。
【請求項２９】
前記ヘッダはゼロバイトヘッダ圧縮技術に従って圧縮される、請求項２１記載の無線通信デバイス。
【請求項３０】
データを符号化する方法を具現化するコンピュータ可読媒体であって、前記方法が：
無線通信システムの物理層パケットサイズを決定することと；
圧縮ヘッダの最大サイズを決定することと；そして
情報単位をパーティションで区切ることと、なお、ここでは、前記パーティションのサイズは、パーティションが符号化された後に前記符号化パーティションと前記圧縮ヘッダの総サイズが前記物理層パケットサイズ以下であるように選択される；
を含む、
コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（米国特許法１１９条のもとでの優先権の主張）
本特許出願は、本譲受人に譲渡され、参照してここに明示的に組み込まれる、２００４年５月１３日に出願された「ＣＤＭＡ物理層プロダクトによって搬送されるマルチメディアパケット(Multimedia Packets Carried by CDMA Physical Layer Products)」と題される米国特許仮出願第６０／５７１，６７３号の優先権を主張する。
【０００２】
（係属中関連特許出願の参照）
本特許出願は、次の同時継続中の米国特許出願に関連する：
同時に出願され、本譲受人に譲渡され、参照してここに全体として明示的に組み込まれる、アトーニードケット番号０３０１６６ＵＩの「通信チャネル上での情報配信(Delivery Of Information Over A Communication Channel)」；
同時に出願され、本譲受人に譲渡され、参照してここに全体として明示的に組み込まれる、アトーニードケット番号０３０１６６Ｕ２の「通信システムのチャネルへの情報の割り当てのための方法および装置(Method And Apparatus For Allocation Of Information To Channels Of A Communication System)」；そして
同時に出願され、本譲受人に譲渡され、参照してここに全体として明示的に組み込まれる、アトーニードケット番号０３０１６６Ｕ４の「無線通信システムにおける音声およびビデオデータの同期化(Synchronization Of Audio And Video Data In A Wireless Communication System)」。  
【０００３】
（分野）
本発明は、一般に、無線通信システム上でのストリームデータの配信に関し、より具体的には、無線通信システム上でのマルチメディアデータの伝送に関係する。
【背景技術】
【０００４】
（背景）
様々な通信ネットワーク上でのマルチメディアデータの配信の需要は、増加しつつある。例えば、消費者は、インターネット、ワイヤーラインおよびラジオのネットワークのような、様々な通信チャネル上でのストリームビデオの配信を望んでいる。マルチメディアデータは、異なるフォーマットおよびデータレートでありえる、そして、様々な通信ネットワークは、それぞれの通信チャネル上でのリアルタイムデータの伝送のために異なるメカニズムを使用する。
【０００５】
普通になった１つのタイプの通信ネットワークは、無線通信用の移動無線ネットワーク(mobile radio networks)である。無線通信システムは、多くのアプリケーションを有し、例えば、携帯電話、ページング、ワイヤレスローカルループ、携帯情報端末（ＰＤＡｓ）、インターネットテレフォニー、衛星通信のシステムを含んでいる。特に重要なアプリケーションは、モバイル加入者用の携帯電話システム(cellular telephone systems for mobile subscribers)である。ここで使用されているように、用語「携帯電話の(cellular)」システムは、携帯電話周波数および個人通信サービス（ＰＣＳ）周波数の両方を含む。
【０００６】
様々な無線インタフェース(over-the-air interface)は、周波数分割多元接続（ＦＤＭＡ）、時分割多元接続（ＴＤＭＡ）および符号分割多元接続（ＣＤＭＡ）を含むそのような携帯電話のために開発されている。
【０００７】
異なる国内標準規格および国際標準規格は、様々なエアインタフェース(air interface)をサポートするために確立されてきており、例えば、先進移動電話サービス(Advanced Mobile Phone Service)（ＡＭＰＳ）、汎欧州デジタル移動電話方式(Global System for Mobile)（ＧＳＭ）、汎用パケット無線システム(General Packet Radio Service)（ＧＰＲＳ）、拡張データＧＳＭ環境(Enhanced Data GSM Environment)（ＥＤＧＥ）、暫定標準規格９５（ＩＳ−９５）およびその派生、ＩＳ−９５Ａ、ＩＳ−９５Ｂ、ＡＮＳＩ  Ｊ−ＳＴＤ−００８（ここでは集合的にＩＳ−９５としばしば呼ばれる）、そして新生の高データレートシステム、例えば、ｃｄｍａ  ２０００、ユニバーサル移動体通信サービス(Universal Mobile Telecommunications Service)（ＵＭＴＳ）、広帯域ＣＤＭＡ(wideband CDMA)（ＷＣＤＭＡ）など、を含む。これらの標準規格は、米国電気通信工業会（ＴＩＡ）、第三世代パートナーシッププロジェクト（３ＧＰＰ）、欧州電気通信標準協会（ＥＴＳＩ）および他の良く知られた標準規格団体によって公布されている。
【０００８】
携帯電話ネットワークのような移動無線ネットワークのユーザ、または顧客は、無線通信リンク上でビデオ、マルチメディア、およびインターネットプロトコル（ＩＰ）のような、ストリーミングメディアを受信したいと思っている。例えば、顧客は、彼らの携帯電話あるいは他のポータブル無線通信デバイス上で、テレビ会議かテレビ放送のようなストリームビデオを受け取ることができることを望む。顧客が彼らの無線通信デバイスで受け取ることを望むデータのタイプの他の例は、マルチメディア  マルチキャスト／ブロードキャストおよびインターネットアクセスを含む。
【０００９】
ＩＰネットワーク上でリアルタイムデータを流すメカニズムを提供するプロトコルは、リアルタイムトランスポートプロトコル(the real-time transport protocol)（ＲＴＰ）である。ＲＴＰは、ＩＰネットワーク上で音声およびビデオのようなリアルタイムデータを送信するための柔軟なプロトコルである。無線通信デバイスにリアルタイムデータを流すためにＲＴＰを使用することは望ましい。
【００１０】
典型的には、ＲＴＰにおいては、ストリーミングデータはデータパケットに符号化されている。ＲＴＰデータパケットは、各パケットに付加された(appended)ルーティングおよびシーケンス情報(routing and sequencing information)を含んでいる。付加されたルーティングおよびシーケンス情報は、通常、ヘッダ(a header)と呼ばれる。制限された帯域幅のような、無線通信システムにおいて利用可能な限定されたリソースのために、送信されるデータの量を減らすことが望ましい。
【００１１】
このように、マルチメディアデータおよびＶｏＩＰのようなストリーミングデータの伝送の間に、無線通信システムにおいて送信されるデータの量を減らすことができる、技術および装置に対する技術的必要性がそれ故にある。
【発明の開示】
【００１２】
［要約］
ここに開示された実施形態は、上記に述べられた、無線通信チャネル上でマルチメディアデータストリームを送信するために必要とされるデータの量を減らす必要性に対応する。無線通信システム上でのリアルタイムトランスポートプロトコル（ＲＴＰ）データストリームの伝送におけるヘッダを減らす(reducing)あるいは除去する(eliminating)ための技術が説明される。これらの技術は、無線通信システムの物理層パケットサイズ(a physical layer packet size)を決定することそして圧縮ヘッダ(a compressed header)の最大サイズを決定すること、そしてそのあとに、情報単位(an information unit)をパーティションで区切ること(partitioning)を含み、ここでは、パーティションのサイズは、パーティションが符号化された後に符号化パーティション(the encoded partition)と圧縮ヘッダの総サイズ(the aggregate size)が物理層パケットサイズ以下であるように選択される。
【００１３】
無線通信システム上でマルチメディアデータを送信する別の技術は、通信セッションにおけるパーティシパント(participants in a communication session)間で物理層圧縮ヘッダサイズをネゴシエーションすること(negotiating)を含む。
【００１４】
更なる面は、無線通信チャネル上で送信されたマルチメディアデータに対しロバストヘッダ圧縮(robust header compression)またはゼロバイトヘッダ圧縮(zero byte header compression)の技術を使用することを含む。
【００１５】
上記技術は、様々なタイプのマルチメディアデータに使用されることができる。例えば、本技術は、可変ビットレートデータストリーム、ビデオストリーム、あるいはビデオテレビ会議ストリームと共に使用されることができる。
【００１６】
上記技術はまた、様々な無線インタフェース(over the air interfaces)と共に使用されることもできる。例えば、本技術は、汎欧州デジタル移動電話方式（ＧＳＭ）、汎用パケット無線システム（ＧＰＲＳ）、拡張データＧＳＭ環境（ＥＤＧＥ）、またはＣＤＭＡに基づく標準規格、例えばＴＩＡ／ＥＩＡ−９５−Ｂ（ＩＳ−９５）、ＴＩＡ／ＥＩＡ−９８−Ｃ（ＩＳ−９８）、ｃｄｍａ２０００、広帯域ＣＤＭＡ（ＷＣＤＭＡ）など、等とともに使用されることもできる。
【００１７】
本発明の他の特徴及び利点は、例によって本発明の面を示す、例示的な実施例の以下の説明によって明らかである。
【００１８】
［詳細な説明］
ここで使用されている用語「例示的な(exemplary)」は、「例(example)、実例(instance)、または例証(illustration)である」を意味している。「例示的な」としてここで説明されるどの実施形態も、他の実施形態より好ましいまたは有利であるとして必ずしも解釈されるべきではない。
【００１９】
ここで使用されている用語「ストリーミング(streaming)」は、対話型のユニキャストまたはブロードキャストアプリケーションにおける専用または共有チャネル上での本質的に連続するマルチメディアデータ、例えば、音声、スピーチまたはビデオ情報など、のリアルタイム配信(real time delivery)を意味する。ここで使用されるビデオ用のフレーズ「マルチメディアフレーム(multimedia frame)」は、デコーディング後に、ディスプレイデバイス上で表示される／描画されることができるビデオフレームを意味する。ビデオフレームはさらに、独立してデコード可能な単位(independently decodable units)に分割されることができる。ビデオ専門用語では、これらは「スライス(slices)」と呼ばれる。音声とスピーチの場合には、ここで使用される用語「マルチメディアフレーム」は、スピーチまたは音声が伝送およびレシーバでのデコーディングのために圧縮されるタイムウィンドウ(a time window)中の情報を意味する。ここで使用されるフレーズ「情報単位間隔(information unit interval)」は、上記に記述されたマルチメディアフレームの時間期間(the time duration)を表わす。例えば、ビデオの場合には、情報単位間隔は、１０フレーム／秒ビデオの場合に１００ミリセカンドである。更に、１例として、スピーチの場合には、情報単位間隔は、ｃｄｍａ２０００、ＧＳＭおよびＷＣＤＭＡにおいて、典型的に２０ミリセカンドである。この説明から、音声／スピーチフレームは通常、独立してデコード可能な単位に更には分割されず、そしてビデオフレームは、通常、独立してデコード可能なスライスに分割される、ということが明らかである。フレーズ「マルチメディアフレーム」、「情報単位間隔」、等が、ビデオ、音声およびスピーチのマルチメディアデータを参照するとき、コンテキストから明らかである。
【００２０】
本発明の一面は、データストリームが送信されるとき、無線通信システムにおいて送信されるデータの量を減らすことである。データのストリーミングの例は、マルチメディアデータ、例えば、ビデオ、テレビ会議、ブロードキャスト／マルチキャスト  サービス、インターネットプロトコル（ＩＰ）およびボイスオーバＩＰ（ＶｏＩＰ）など、を含む。
【００２１】
ここに記載の技術は、情報単位をパーティションで区切ること、それによって、複数のデータパケットを生成すること、に関係する。記載の技術は、上記の「係属中関連特許出願の参照」欄において参照された同時継続中の米国特許出願の中で説明される面(aspects)のいくつかを利用する。例えば、明示的ビットレート（ＥＢＲ）と称される技術が記載され、そこでは、エンコーダ(encoder)は、それがアプリケーション層情報単位を通信チャネルの物理層パケットサイズに符号化するように強制され得る。
【００２２】
注目されるように、ＲＴＰは、ストリームをパケットに符号化することによってデータを流すために使用されるメカニズムである。ＲＴＰにおいては、ルーティングおよびシーケンシング情報を含むヘッダは各パケットに付加される(appended)。本発明の一面は、ヘッダのサイズを減らすことであり、あるいはヘッダを完全に取り除くことである。このように、ＲＴＰパケットを送信する無線通信チャネル上で送信されるデータの量は減らされる。
【００２３】
図１は、本発明に従って構成された通信システム１００を示す。通信システム１００は、インフラストラクチャ(infrastructure)１０１、複数の無線通信デバイス(wireless communication devices)（ＷＣＤ）１０４および１０５、そして地上通信線通信装置(landline communication devices)１２２および１２４を含んでいる。ＷＣＤはまた移動局(mobile stations)（ＭＳ）あるいはモバイル(mobiles)と呼ばれるであろう。一般に、ＷＣＤは、移動可能か固定されている。地上通信線通信装置１２２および１２４は、ストリーミングデータのような、様々なタイプのマルチメディアデータを提供する、サービスをサービングノード(serving nodes)、あるいはコンテンツサーバを含むことができる。更に、ＭＳは、マルチメディアデータのようなストリーミングデータを送信することができる。
【００２４】
インフラストラクチャ１０１はまた、他のコンポーネント、例えば、基地局(base stations)１０２、基地局コントローラ(base station controllers)１０６、モバイル交換局(mobile switching centers)１０８、スイッチングネットワーク(a switching network)１２０および同様のもの、を含んでいるかもしれない。一実施形態においては、基地局１０２は、基地局コントローラ１０６と一体化され、そして、他の実施形態においては、基地局１０２と基地局コントローラ１０６は別々のコンポーネントである。異なるタイプのスイッチングネットワーク１２０、例えば、ＩＰネットワーク、あるいは公衆交換電話網（ＰＳＴＮ）が、通信システム１００において信号を送るために使用されてもよい。
【００２５】
用語「順方向リンク(forward link)」あるいは「ダウンリンク(downlink)」は、インフラストラクチャ１０１からＭＳまでの信号経路を指し、そして、用語「逆方向リンク(reverse link)」あるいは「アップリンク(up link)」は、ＭＳからインフラストラクチャまでの信号経路を指す。図１において示されるように、ＭＳ１０４および１０５は、順方向リンク上で信号１３２および１３６を受け取り、逆方向リンク上で信号１３４および１３８を送信する。一般に、ＭＳ１０４および１０５から送信される信号は、別の通信デバイス、例えば、別の遠隔ユニットなど、あるいは地上通信線通信装置１２２および１２４での受信を目的としており、ＩＰネットワークまたはスイッチングネットワーク１２０を通って送られる。例えば、もし開始ＷＣＤ(initiating WCD)１０４から送信された信号１３４が送信先ＭＳ(destination MS)１０５によって受け取られるように意図される場合、信号はインフラストラクチャ１０１を通して送られ、信号１３６が順方向リンク上で送信先ＭＳ１０５に送信される。同様に、インフラストラクチャ１０１中において開始された信号は、ＭＳ１０５にブロードキャストされるかもしれない。例えば、コンテンツプロバイダは、ストリーミングマルチメディアデータのようなマルチメディアデータを、ＭＳ１０５に送ってもよい。典型的には、ＭＳあるいは地上通信線通信装置のような通信デバイスは、信号のイニシエータ(initiator)と送信先の両方であるかもしれない。
【００２６】
ＭＳ１０４の例は、携帯電話、無線通信可能パーソナルコンピュータ、および携帯情報端末（ＰＤＡ）、そして他の無線デバイスを含む。通信システム１００は、１つ以上の無線標準規格をサポートするように設計されてもよい。例えば、標準規格は、汎欧州デジタル移動電話方式（ＧＳＭ）、汎用パケット無線システム（ＧＰＲＳ）、拡張されたデータＧＳＭ環境（ＥＤＧＥ）、ＴＩＡ／ＥＩＡ−９５−Ｂ（ＩＳ−９５）、ＴＩＡ／ＥＩＡ−９８−Ｃ（ＩＳ−９８）、ＩＳ２０００、ＨＲＰＤ、ｃｄｍａ２０００、広帯域ＣＤＭＡ他（ＷＣＤＭＡ）として呼ばれる標準規格、およびその他を含んでよい。
【００２７】
図２は、無線ネットワーク上でパケットデータを配信するための例示的なパケットデータネットワークおよび様々なエアインタフェースのオプションを図示するブロック図である。記述される技術は、図２において例示されるもののようなパケット交換データネットワークにおいてインプリメントされることができる。図２の例で示されるように、パケット交換データネットワークシステムは、無線チャネル２０２、複数の受信ノード(recipient nodes)あるいはＭＳ２０４、送信ノード(sending node)あるいはコンテンツサーバ２０６、サービングノード２０８、およびコントローラ２１０を含んでよい。送信ノード２０６は、インターネットのようなネットワーク２１２を介してサービングノード２０８に結合されることができる。
【００２８】
サービングノード２０８は、例えば、パケットデータサービングノード（ＰＤＳＮ）あるいはサービングＧＰＲＳサポートノード（ＳＧＳＮ）あるいはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）を含んでよい。サービングノード２０８は、送信ノード２０６からパケットデータを受け取り、コントローラ２１０に情報のパケットを供給できる。コントローラ２１０は、例えば、基地局コントローラ／パケット管理機能（ＢＳＣ／ＰＣＦ）あるいは無線ネットワークコントローラ(Radio Network Controller)（ＲＮＣ）を備えるかもしれない。一実施形態においては、コントローラ２１０は、無線アクセスネットワーク(Radio Access Network)（ＲＡＮ）上でサービングノード２０８と通信する。コントローラ２１０は、サービングノード２０８と通信し、そして、少なくとも1つの受信ノード２０４に無線チャネル２０２上で情報のパケットを送信する。
【００２９】
一実施形態においては、サービングノード２０８または送信ノード２０６、あるいは両方は、また、データストリームを符号化するためのエンコーダ、あるいはデータストリームをデコードするためのデコーダ、あるいは両方を含んでいるかもしれない。例えば、エンコーダは、ビデオストリームを符号化し、それによって、データの可変サイズのフレーム(variable-sized frames of data)を生成することができるであろう、また、デコーダは、データの可変サイズのフレームを受け取り、それらをデコードすることができるであろう。フレームが様々なサイズであるがビデオフレームレートが一定であるので、データの可変ビットレートストリームが生成される。同様に、ＭＳは、データストリームを符号化するためのエンコーダ、あるいは受信データストリームをデコードするためのデコーダ、あるいは両方を、含んでいるかもしれない。用語「コーデック(codec)」は、エンコーダとデコーダの組合せについて説明するために使用される。
【００３０】
図２に例示される一例では、マルチメディアデータのようなデータが、ネットワーク、またはインターネット２１２に接続されている送信ノード２０６から、受信ノード、またはＭＳ２０４に、サービングノード、またはパケットデータサービングノード（ＰＤＳＮ）２０６、およびコントローラ、または基地局コントローラ／パケット管理機能（ＢＳＣ／ＰＣＦ）２０８を経由して送られることができる。ＭＳ２０４とＢＳＣ／ＰＣＦ２１０の間の無線チャネル２０２インタフェースは、エアインタフェースであり、そして典型的に、シグナリング(signaling)とベアラ(bearer)ための多くのチャネル、あるいはペイロード(payload)、データを使用することができる。
【００３１】
エアインタフェース
エアインタフェース２０２は、多くの無線標準規格のうちのいずれに従っても操作し得る。例えば、標準規格は、汎欧州デジタル移動電話方式（ＧＳＭ）、汎用パケット無線システム（ＧＰＲＳ）、拡張されたデータＧＳＭ環境（ＥＤＧＥ）のような、ＴＤＭＡあるいはＦＤＭＡに基づく標準規格、あるいはＴＩＡ／ＥＩＡ−９５−Ｂ（ＩＳ−９５）、ＴＩＡ／ＥＩＡ−９８−Ｃ（ＩＳ−９８）、ＩＳ２０００、ＨＲＰＤ、ｃｄｍａ２０００、広帯域ＣＤＭＡ他（ＷＣＤＭＡ）のようなＣＤＭＡに基づく標準規格、およびその他、を含むことができる。
【００３２】
ＲＴＰパケット化
リアルタイムトランスポートプロトコル(The Real-Time Transport Protocol)（ＲＴＰ）は、マルチメディアデータのようなリアルタイムデータを送信するために開発されたプロトコルである。ＲＴＰは、ＩＰネットワーク上でリアルタイムデータを流すメカニズムを提供する柔軟なプロトコルである。「ＲＴＰ：リアルタイムアプリケーション用のトランスポートプロトコル(RTP:A Transport Protocol for Real-Time Applications)」（Ｈ．Ｓｃｈｕｌｚｒｉｎｎｅ［コロンビア大学］、Ｓ．Ｃａｓｎｅｒ［パケット設計］、Ｒ．Ｆｒｅｄｅｒｉｃｋ［ブルーコートシステムズ社(Blue Coat Systems Inc.)］、Ｖ．Ｊａｃｏｂｓｏｎ［パケット設計］、ＲＦＣ−３５５０標準規格案、インターネット エンジニアリング ステアリング グループ、２００３年７月、ＵＲＬ  ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃ／ｒｆｃ３５５０．ｈｔｍｌで入手可能）を参照。ストリーミングは、データを、それが安定した連続するストリームとして処理されることができるように、転送する技術を意味する。
【００３３】
特定のタイプのデータ、例えばビデオ、を流すためにＲＴＰを使用する方法の記述は、ＲＴＰプロファイル(RTP profile)と呼ばれる。ＲＴＰプロファイルにおいては、ソースエンコーダの出力はパケットにグループ化され、そして、ヘッダ情報がパケットに加えられる。
【００３４】
図３は、無線リンク上でマルチメディアデータ、例えばビデオデータあるいはＶｏＩＰなど、を送信するためにＲＴＰを使用する時に存在する様々なレベルのカプセル化(encapsulation)を例示するダイアグラムである。図３において示されるように、ペイロード(payload)３０２が生成される。例えば、ペイロードは、マルチメディアデータ、例えばビデオデータあるいはＶｏＩＰ、を流していることができる。ペイロード３０２は、ペイロード３０２に関係する追加情報を含んでいるＳｌｉｃｅ￣Ｈｅａｄｅｒ（ＳＨ）３０４によってプリペンドされる(pre-pended)ことができる。ＲＴＰプロトコルは、そのあと、ペイロードを１つあるいはいくつかのＲＴＰパケットにカプセル化し、ＲＴＰヘッダ３０６を付加する(append)。図３に例示される例においては、ペイロードは、「ＲＴＰ」によって示されるＲＴＰヘッダ３０６を備えた単一のＲＴＰパケットにカプセル化される。ユーザデータグラムプロトコル(User Datagram Protocol)（ＵＤＰ）ヘッダ３０８が、そのあと各ＲＴＰパケットに加えられ、送信元(source)ポートと送信先(destination)ポートを示している。インターネットプロトコル（ＩＰ）ヘッダ３１０が、そのあと、送信元ホストと送信先ホストのネットワークアドレスを示すために加えられる。例えば、一実施形態においては、ＲＴＰヘッダは１２バイトかもしれないし、ＵＤＰヘッダは２０バイトかもしれないし、またＩＰヘッダは８バイトかもしれないが、それによって、４０バイトのヘッダがペイロード３０２に付加される結果となる。無線通信システム上でＲＴＰを送信する時は、システムソースを節約する(conserve)ためにヘッダのサイズを減らすことが望ましい。
【００３５】
無線ネットワークに入ると同時に、ポイントツポイントプロトコル(point to point protocol)（ＰＰＰ）ヘッダ３１２が、パケットをビットの連続ストリームにシリアル化する(serialize)ためのフレーミング情報(framing information)を提供するために付け加えられる。無線リンクプロトコル、例えば、ｃｄｍａ２０００におけるＲＬＰあるいはＷ−ＣＤＭＡにおけるＲＬＣが、そのあと、ビットのストリームをＲＬＰパケット３１４に圧縮する(pack)。無線リンクプロトコルは、とりわけ、エアインタフェース上で送られるパケットの再伝送および再配列を可能にする。最後に、エアインタフェースＭＡＣ層が、１つ以上のＲＬＰパケット３１４をとり、それらをＭＵＸ層パケット３１６に圧縮し、そして、多重化ヘッダ(multiplexing header)（ＭＵＸ）３１８を加える。物理層パケットチャネルコーダ(physical layer packet channel coder)が、そのあと、デコーディングエラー(decoding errors)を検知するチェックサム(checksum)（ＣＲＣ）３２０、および物理層パケット３２５を形成する末尾部分(tail part)３２２を加える。
【００３６】
インターネット エンジニアリング ステアリング グループは、ＲＴＰによって搬送されるビデオのパケット化に関するガイドライン、あるいは規則、を提案した。「ＭＰＥＧ−４音声／視覚  ストリームのためのＲＴＰペイロードフォーマット(RTP Payload Format for MPEG-4 Audio/Visual Streams)」（Ｙ．Ｋｉｋｕｃｈｉ［東芝］、Ｔ．Ｎｏｍｕｒａ［ＮＥＣ］（Ｓ）．Ｆｕｋｕｎａｇａ［Ｏｋｉ］、Ｙ．Ｍａｔｓｕｉ［松下］、Ｈ．Ｋｉｍａｔａ［ＮＴＴ］、ＲＦＣ−３０１６標準規格提案、インターネット エンジニアリング ステアリング グループ、２０００年１１月、ＵＲＬ  ｗｗｗ：ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃｓ３０６０．ｈｔｍｌで入手可能）を参照。これらの規則は、ＭＰＥＧ−４に対応するが、同様のスキームもまた他のビデオコーデック(video codec)に適用する。ＲＦＣ３０１６は、パケット化に対し次の３つのオプションを定義する、なおここでは、ビデオオブジェクトプレーン(Video Object Planes)（ＶＯＰ）はＭＰＥＧ−４のビデオフレームを指す：
１．ＲＴＰパケット当たり１つのビデオフレームを圧縮すること(packing)：
「ＲＴＰタイムスタンプ(RTP timestamp)は、ＲＴＰパケットに含まれるＶＯＰのサンプリングインスタンス(sampling instance)を示す。無作為の、一定のオフセット(constant security)が、セキュリティ理由のために加えられる。」この場合、ＲＴＰタイムスタンプおよびＲＴＰシーケンス番号(RTP sequence number)がインクレメントされる。  
２．ＲＴＰパケット当たり複数のビデオフレームを圧縮すること：
「複数のＶＯＰ(multiple VOPs)が同じＲＴＰパケットの中で搬送される時、タイムスタンプは、ＲＴＰの中で搬送されたＶＯＰの内のＶＯＰ時間の中で最も早いもの(the earliest of the VOP times)を示す。ＶＯＰの残りのタイムスタンプ情報は、ＶＯＰヘッダ（ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ  ａｎｄ  ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ）におけるタイムスタンプフィールド分野から得られる。［．．．］この種のパケット化は、基礎をなすネットワークのビットレートが低い時に、ＲＴＰ／ＩＰヘッダのオーバーヘッドを節約するのに有効である。しかしながら、複数のビデオパケットが単一のＲＴＰパケットロスによって廃棄されるので、それはパケットロス障害許容力(packet-loss resiliency)を減少させるだろう。ＲＴＰパケットにおけるビデオパケットの最適の数およびＲＴＰパケットの長さは、基礎をなすネットワークのパケットロスレートおよびビットレートを考慮して決定されることができる。」この場合、ＲＴＰタイムスタンプは前方にジャンプ(jumps ahead)し、そして、ＲＴＰシーケンス番号がインクリメントされる。  
３．複数のＲＴＰパケット上で１つのビデオフレームをセグメント化すること(segmenting)：
「単一のビデオパケットは単一のＲＴＰパケットとして送られることが推奨される。ビデオパケットＳＨＯＵＬＤのサイズは、結果として生じるＲＴＰパケットがパス−ＭＴＵ(path-MTU)よりもより大きくないような方法で調節される。［．．．］基礎をなすネットワークのパケットロスレートが高い場合、この種のパケット化は推奨される。ＶＯＰヘッダを含んでいるＲＴＰパケットがパケットロスによって廃棄される時でさえ、他のＲＴＰパケットは、ビデオパケットヘッダの中のＨＥＣ（ヘッダ拡張コード）情報を使用することによりデコードされることができる。特別のＲＴＰヘッダフィールドは必要ではない。」この場合、ＲＴＰタイムスタンプは同じままであり、そして、ＲＴＰシーケンス番号がインクリメントされる。  
【００３７】
概して、エンコーダの「変動性(variability)」が明確であるので、ＲＴＰパケット化は、スピーチコーデック(speech codecs)あるいはボコーダ(vocoders)に対しては、より単純である。例えば、ｃｄｍａ２０００ボコーダでは、ペイロードサイズは、４つ（４）の可能なレート（例、フルレート、ハーフレート、４分の１レート、および８分の１レート）のうちの１つである。
【００３８】
マルチメディアデータストリームの伝送の間のヘッダ圧縮(Header Compression)
汎用ヘッダ圧縮サポート(Generic Header Compression Support)
【００３９】
所定の圧縮スキームの場合の圧縮ヘッダ(compressed header)のサイズは、とりわけ、ＲＴＰタイムスタンプおよびＲＴＰシーケンス番号の変化に依存する、なおここでは、ヘッダはＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダを含んでいる。エンコーダは、例えばビデオデータストリームのようなマルチメディアデータストリームから、データパケットを符号化する時点では、圧縮ヘッダの実際のサイズを知らない。圧縮ヘッダの実際のサイズは知られていないかもしれないが、ヘッダサイズに上限を設定することは可能である。例えば、セッションのセットアップの間に、ヘッダサイズの上限は、パラメータ、例えば、圧縮スキーム、ＵＤＰチェックサムオプション、および同様のものなど、に依存して確立されることができる。
【００４０】
一実施形態においては、１セットの可能なデータレート(a set of possible data rates)は、送信端末(sending terminal)、受信端末(receiving terminal)およびそれらの対応するＰＤＳＮの間で、ネゴシエーションされる(negotiated)ことができる。例えば、１セットの可能なデータレートは、送信ＭＳ、受信ＭＳおよびそれらの対応するＰＤＳＮの間で、ネゴシエーションされることができる。上記の「通信チャネル上での情報配信」と題された、同時に出願中の米国特許出願番号＿＿＿＿＿＿＿＿、に記載されているように、可能なデータレートの各々は、物理層パケットサイズに関連している。Ｓが、バイトで、ネゴシエーション後にエンコーダに利用可能なデータレートに対応する物理層パケットサイズのセット(the set of physical layer packet sizes)を表わすとすると、
【数１】
2007537681.tif 000003
【００４１】
そして
【数２】
2007537681.tif 000004
【００４２】
但し、
【数３】
2007537681.tif 000005
【００４３】
は、ペイロードに対し使用されることが出来る物理層パケット内のデータの最大量をバイトで表わす、そして
ｘ∈｛０，１，２，３，４｝但しｘの値は圧縮ヘッダサイズの上限をバイトで示し、そして、使用されるヘッダ圧縮スキームのタイプに依存する。例えば、更に下記に説明されるように、異なる圧縮スキームに対応する値は：
ｘ≡０  ゼロヘッダ圧縮に対応する、但し、ヘッダは完全に取り除かれる；
ｘ≡１または２  ＵＤＰチェックサム無しのロバストヘッダ圧縮（ＲＯＨＣ）に対応する；
ｘ≡３または４  ＵＤＰチェックサムを備えたＲＯＨＣゼロヘッダ圧縮に対応する。
【００４４】
一実施形態においては、セッションに関係するＭＳ、コンテンツサーバおよびＰＤＳＮは、セッションセットアップのセットアップ中にＳとｘに対する値をネゴシエーションする。ネゴシエーションは、セッション中の様々なデバイスにサポートされた符号化スキームと圧縮スキームのようなパラメータを考慮に入れるかもしれない。セッションの間に、データストリーム、例えばマルチメディアデータストリームなどは、エンコーダがサイズでＳ−ｘバイトのパケットを生成し、圧縮ヘッダ用に十分なスペースを残す、ようなサイズである部分にパーティションで区切られる(partitioned into portions)ことができる。例えば、もしビデオデータストリームがセッションの間に送信される場合は、ビデオスライスが符号化される時に符号化スライス(encoded slice)がＳ−ｘバイトでありそして圧縮ヘッダがサイズでｘバイトよりも大きくないように、ビデオフレームはパーティションに区切られるか、あるいは「スライスされる」。もし圧縮ヘッダのサイズがｘバイト未満である場合、そのときは、ヌル(null)バイトが含まれることができ、あるいは、生成されるデータパケットが所望されるサイズであるようにビデオスライスの符号化に割り当てられたデータの量は増やされることができる。
【００４５】
図４は、Ｓとｘに対する値のネゴシエーションの例を図示するフローダイアグラムである。フローはブロック４０２において始まり、ここでは、ＭＳがインフラストラクチャ中のデバイス、例えばＰＤＳＮに、どの圧縮スキームをＭＳがサポートするのかを通知する。更に、サポートされる圧縮スキームのうちの１つを別のもの以上にＭＳが好む(prefer)のかどうかを、ＭＳはＰＤＳＮに通知することができる。フローは、その後、ブロック４０４に進む。ブロック４０４では、ＰＳＤＮのようなインフラストラクチャデバイスが、ＭＳにサポートされた圧縮技術を、インフラストラクチャデバイスによってサポートされた圧縮技術と比較する。インフラストラクチャデバイスはまた、ＭＳのどんなプレファレンス(preference)も考慮に入れることができる。フローは、その後、ブロック４０６に進み、ここでは、インフラストラクチャデバイスは、セッションの間に使用する圧縮技術をＭＳに通知する。
【００４６】
図４において例示されたネゴシエーションの例として、ＭＳは、その好ましい順にＭＳがｘ＝０、３、そして１をサポートすると、ＰＤＳＮに通知してもよい。この例においては、ＰＤＳＮはｘ＝１（ＵＤＰチェックサム無しのＲＯＨＣ）をサポートしない。ＰＤＳＮは、その後、セッションに関係している(participating)第２のＰＤＳＮに、サポートされたオプション（ｘ＝０、３）を送ってもよい。第２のＰＤＳＮは、セッションにさらに関係する受信ＭＳがｘ＝０、１、２、３、および４をサポートでき、一方、第２のＰＤＳＮそれ自体はｘ＝０、１、および４をサポートできる、ということを知るかもしれない。セッションの全てのパーティシパントにサポートされるｘの唯一の値はｘ＝０であるので、セッションはｘに対し０の値を使用して確立されるであろう。
【００４７】
図５は、Ｓとｘに対する値のネゴシエーションの別の例を図示するフローダイアグラムである。フローはブロック５０２において始まり、ここでは、インフラストラクチャ中のデバイス、例えばＰＤＳＮが、どの圧縮スキームをインフラストラクチャデバイスがサポートするのかについてＭＳに通知する。更に、サポートされる圧縮スキームのうちの１つに対して別のもの以上にインフラストラクチャが有するどんなプリファランスも、インフラストラクチャデバイスはＭＳに通知することができる。フローは、その後、ブロック５０４に進む。ブロック５０４では、ＭＳは、ＭＳにサポートされた圧縮技術を、インフラストラクチャデバイスによってサポートされた圧縮技術と比較する。ＮＳはまた、インフラストラクチャデバイスのどんなプレファレンスも考慮に入れることができる。フローは、その後、ブロック５０６に進み、ここでは、ＭＳは、セッションの間に使用する圧縮技術をインフラストラクチャデバイスに通知する。
【００４８】
上記例の場合のプロトコルシーケンスの例が下記にリストされる：
・ＰＰＰインターネットプロトコルコントロールプロトコル(Internet Protocol Control Protocol)（ＩＰＣＰ）の間、モバイル(mobile)もＰＤＳＮも両方共、任意のプレファレンスに加え、互いにそれらのヘッダ圧縮能力(header compression capabilities)を示し、そして、モバイルとＰＤＳＮの両方にサポートされた、１セットの共通圧縮能力(a set of common compression capabilities)をネゴシエーションする(negotiate)。  
・モバイルは、どのヘッダ圧縮タイプが使用されるべきかを、従ってｘ値を決定する。  
・モバイルは、ｘ値のような情報、ビデオスライスサイズのようなデータパケットサイズ、等を、無線通信システム経由で、ＰＤＳＮと通信しているコンテンツサーバに伝える（例、セッション開始プロトコル(Session Description Protocol)（ＳＩＰ）あるいはリアルタイムストリーミングプロトコル（ＲＴＳＰ）、等におけるセッション記述プロトコル（ＳＤＰ）パラメータ））。  
・モバイルは、アドレス／ポート、ヘッダ圧縮タイプ、等のフロー情報を、３ＧＰＰ２−特定信号伝達経由でＰＤＳＮに伝える（すなわち、ＲＥＳｅｒＶａｔｉｏｎ（ＲＥＳＶ）メッセージ）。この情報は、アドレス／ポートによって識別されたこの特定のセッションフロー上で使用されるべきヘッダ圧縮タイプをＰＤＳＮが知ることを可能にする。  
【００４９】
ロバストヘッダ圧縮
ここで使用されるようなロバストヘッダ圧縮（ＲＯＨＣ）は、コンプレッサ(compressor)とデコンプレッサ(decompressor)の両方で状態情報（コンテキスト）を維持することによって、連続するパケット間のリダンダンシ(redundancies)を利用する、圧縮スキームに関連する。静的コンテキスト情報は、セッションの初めに、最初だけ送られる、一方、動的コンテキスは、続いて起こるデータパケットと共に送られる。圧縮されていないパケット(uncompressed packets)をデコンプレッサが正確に再生させるために、デコンプレッサの中のコンテキストは、圧縮中にコンプレッサによって使用されたコンテキストと同期をとられる必要がある。デコンプレッサとコンプレッサとの間のコンテキストの同期を維持するために開発されている技術は、インターネットエンジニアリングタスクフォースのＲＯＨＣワーキンググループ(the ROHC Working Group of the Internet Engineering Task Force)によって開発されたロバストヘッダ圧縮（ＲＯＨＣ）技術を含み、［例えば、インターネット  ＵＲＬ  ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３０９５．ｔｘｔ？ｎｕｍｂｅｒ＝３０９５での標準規格および草案を参照］、参照してここに全体として組み込まれる。
【００５０】
ＲＯＨＣを使用すれば、コンテキストがデコンプレッサで利用可能な時はほとんどのペイロードに対して１バイトヘッダがあり、コンテキストをデコンプレッサで確立することが必要な時は４４バイトヘッダがある。ＵＤＰチェックサムがイネーブルにされる時、圧縮ヘッダサイズは、コンテキストがデコンプレッサで利用可能な時、３バイトである。一実施形態においては、ＲＯＨＣが使用され、そして、コンテキストがデコンプレッサで利用可能な時は、ペイロードパケットサイズは、物理層パケットサイズより１バイト小さくなるように制限される。別の実施形態においては、イネーブルにされたＵＤＰチェックサムを備えたＲＯＨＣが使用され、そしてコンテキストがデコンプレッサで利用可能な時、ペイロードパケットサイズは、物理層パケットサイズより３バイト小さくなるように制限される。
【００５１】
ＲＯＨＣコンテキストが確立される必要がある時、ｃｄｍａ２０００の「ブランクおよびバースト」伝送特徴("blank and burst" transmission feature)が、例えば複数の通信チャネル上で使用されることができ、あるいは、更なるパケットが送られることができる。このようにして、ＲＯＨＣの使用が記述された技術と共に使われることができ、そしてそれによって、送信されるデータの量の減少をもたらす。「ブランクおよびバースト(blank and burst)」は、信号データ（この場合ＲＯＨＣコンテキスト情報）が音声データの代わりに送信されることを意味する。
【００５２】
ゼロバイトヘッダ圧縮
ユニバーサル移動体通信システム(Universal Mobile Telecommunications System)（ＵＭＴＳ）として知られている第３世代モバイル技術は、固定の、無線およびサテライトのシステムを通して世界のどこの無線デバイスにも音声およびビデオを配信できる。一般に、ＵＭＴＳコーデックペイロードサイズは適応マルチレート(Adaptive Multi-Rate)（ＡＭＲ）モードに基づいて固定される。複数のフレームにわたるＲＴＰオーバーヘッドを償却するために、次の方法の１つあるいは両方は使用されることが出来る：  
１．ヘッダ圧縮（例えばＲＯＨＣなど）
２．１つのＲＴＰパケットに複数のフレームをバンドルすること(bundling)
バンドリング(bundling)が使用される時、ＲＴＰタイムスタンプは、ＲＴＰパケットにおいて最も早いフレームのものである。  
【００５３】
ＩＰノードがレシーバ、あるいは「シンク」端末(“sink” terminal)と通信している時、もしタイムスタンプ情報が暗黙的に知られている場合は、ＲＴＰヘッダを再構築することは必要でないかもしれない。もしデコーダがフレームをコンスタントの知られたレートで受け取る場合は、デコーダは、更なるタイムスタンプ情報無しでサンプルを出力することが可能であり得る。例えば、もしデコーダが少なくとも１つのフレームを２０ｍｓごとに受け取る場合は、デコーダは、更なるタイムスタンプ情報無しでサンプルを２０ｍｓごとに出力できる。ブランクフレーム(blank frames)が、パケットロス(packet losses)の間に生成されるかもしれない。
【００５４】
図６は、無線通信システムにおけるゼロバイトヘッダ圧縮技術に基づくパケットデータ用のプロトコルスタック(protocol stack)を例示するダイアグラムである。図６において例示される例では、ＭＳ６０２は、インフラストラクチャにおけるホスト６０４からデータを受け取る。ホスト６０４では、コーデック６０６がデータパケットを符号化する。コーデックの出力は、データパケットに付加された、ＲＴＰ６０８、ＵＤＰ６１０およびＩＰヘッダ情報６１２を有している。ＰＤＳＮ６１４は、基地局／パケット制御機能のようなラジオ放送網(a Radio Network)６１６経由で、符号化されたデータパケットをＭＳ６０２に送る。データパケットがＭＳ６０２によって受け取られる時、データパケットは、メディアアクセス制御層６１８からコーデック６２０に送られる。ＭＳ６０２におけるコーデック６２０は受信されたパケットをデコードする。
【００５５】
上記に説明されたように、ＲＴＰパケット化で、複数のビデオフレームが１つのＲＴＰパケットに含まれている時、準拠するデコーダ(compliant decoder)が、ＲＴＰパケットにおいて引き続いておこるビデオフレームのｍｏｄｕｌｏ＿ｔｉｍｅｂａｓｅとｔｉｍｅ＿ｉｎｃｒｉｍｅｎｔのフィールドを使用して、このパケット中のフレームのタイミングを再現できることは示された。例えば、ＥＢＲを使用すると、もしｎビデオフレームがｎＴｍｓごとに配信されるＱｏＳ保証(QoS guarantee)がある場合（ここではＴは２つのビデオフレームの間の時間であり、Ｔ＝１０００／ｆｒａｍｅｓ＿ｐｅｒ＿ｓｅｃｏｎｄ）、ビデオデータの同期配信のためのメカニズムが確立され得る。このように、ＥＢＲアプローチは、スピーチ用のサービスオプション６０（Ｓ０６０）と同様に、ゼロバイトヘッダ圧縮を利用できる。０バイトヘッダ圧縮の使用は、送信されるｏデータ量を大幅に減らす(reduce)ことが出来る。例えば、ＣＤＭＡに基づいた無線通信システムでは、８ｘ（６４ｋｂｐｓストリーム）で動作する補足的チャネル（ＳＣＨ）の場合、この技術は、結果として、各１６０バイトに対し少なくとも４４バイトのヘッダ情報の減少、例えば、ビットレートにおいて約２７．５％の節約、をもたらす。
【００５６】
図７は、ＩＰヘッダオーバーヘッド対ビデオデータストリームのデータレートを例示するグラフである。垂直軸７０２は、合計ビットレートのパーセントとして正規化されたＲＴＰ／ＵＤＰ／ＩＰ／ＰＰＰオーバーヘッドを表わし、水平軸７０４はビデオストリーム用のビットレートを表わす。図７のカーブ７０６は、オーバーヘッドのサイズが縮小する(reduce)ときのデータ用の利用可能なビットレートにおける増加を示している。図７において示される例においては、４バイトの値が、ＰＰＰオーバーヘッド用に使用された。ＰＰＰオーバーヘッドに対する４の値は、ビデオデータのうちのいくらかがＰＰＰヘッダと間違われないようにエスケープコードが付加されるので、多分、ＰＰＰオーバーヘッドに対する実際の値を過小評価する。
【００５７】
図７において示されるように、オーバーヘッドに専用の合計ビットレートパーセンテージはビットレートが増加するにつれて減少するが、合計ビットレートのかなりの量がオーバーヘッドの伝送に専用であり得る。例えば、毎秒８８バイトのビットレートでは、ビットレートの合計の約２０％がオーバーヘッドの伝送に専用である。ＲＯＨＣおよび０バイトヘッダ圧縮のような技術を通してのヘッダ情報の除去あるいは減少は、オーバーヘッドの伝送にそうでなければ専用的であろうビットレートが、その代りに、ビデオ品質を改善するまたはシステム容量あるいは同様のものを増加させるために使用されることを可能にする。
【００５８】
図８は、ゼロバイトヘッダ技術が使用される時にマルチメディアデータをデコードする際に使用される例示的なコンポーネントを図示するブロック図である。図８において示されるように、チャネルデコーダ８０２は、マルチメディアデータストリームを構成するデータパケットを受け取るように、構成される(configured)。チャネルデコーダ８０２の出力は、ＲＬＰ再シーケンサ(RLP resequencer)８０４に接続される。ＲＬＰ再シーケンサ８０４は、チャネルパケットが各パケットのシーケンス番号に従って順番に並べられる再シーケンスバッファ(resequencing buffer)の中に、チャネルパケットを置く。マルチメディアデコーダ(multimedia decoder)８０８、例えばビデオデコーダは、再シーケンスバッファ８０６からデータパケットを検索し(retrieve)、そして個々のマルチメディアパケットをデコードする。マルチメディアパケットは、マルチメディアデコーダ８０８から出力され、そして、マルチメディアパケットが保存されるマルチメディアフレームバッファ(multimedia frame buffer)８１０の中に置かれる。マルチメディアプレイアウトデバイス(multimedia play out device)８１２は、デコードされたマルチメディアパケットをマルチメディアフレームバッファ８１０から検索する。マルチメディアプレイアウトデバイス８１２は、適切なマルチメディアプレゼンテーションデバイス８１４の中で、ユーザへのプレゼンテーション用のマルチメディアパケットをフォーマットする。例えば、もしマルチメディアデータがビデオデータである場合は、マルチメディアプレゼンテーションデバイス８１４はビデオディスプレであり得る。
【００５９】
図９は、図８で示されたマルチメディアデコーダ８０８において達成されることができるであろうゼロバイトヘッダ圧縮技術を使用する、マルチメディアデータストリームのデコード化の例を図示するフローチャートである。図９の例では、マルチメディアデータはビデオデータであり、そして、マルチメディアデコーダ８０８はビデオデコーダである。フローはブロック９０２において始まり、そこでは、ビデオデコーダが、シーケンスの中で次の(next in-sequence)データパケットあるいはスライスを再シーケンスバッファから検索する。フローはブロック９０４に進む。ブロック９０４では、データパケットは調べられ、そして、データパケットがスタートコード(start code)あるいは再同期マーカー(resync marker)を含んでいるかどうかが決定される。もしデータパケットがスタートコードを含み、ビデオストリーム中のビデオフレームのスタートを示している場合、そのときフローは、ブロック９０６に進む。ブロック９０６では、データパケットが調べられ、そして、フレームヘッダが読まれる。フレームヘッダは、タイミング情報を含むビデオフレーム全体に関する情報を含んでもよい。フローは、そのあと、ブロック９０８に進み、そこでは、ビデオフレームバッファの中の新しいフレームが開かれる。フローはそのあとブロック９１０に進む。
【００６０】
ブロック９０４に戻って、もしデータパケットが調べられ、そして、データパケットあるいはスライスが再同期マーカーを含んでいると決定される場合、フローはブロック９１２に進む。もしデータパケットが再同期マーカーを含んでいる場合、そのときデータパケットは、ビデオストリーム中のビデオフレームのスタートではないが、スライス(slice)またはマクロブロック(macroblock)とも呼ばれる、ビデオフレームの一部である。ブロック９１２では、データパケット、あるいはスライスまたはマクロブロック、のスライスヘッダ(slice header)が読まれる。フローはそのあとブロック９１０に進む。
【００６１】
ブロック９１０では、データパケット、あるいはスライスまたはマクロブロックがデコードされる。フローはそのあとブロック９１４に進み、そこでは、デコーディングエラー(decoding error)が発生したかどうかが判断される。例えば、デコードされたデータパケットに競合するシーケンス番号があることが、ブロック９１４の中で判断され得る。もしデコーディングエラーがあると判断された場合、ブロック９１４では肯定の結果となり、フローはブロック９１６に進む。ブロック９１６では、デコーディングエラーを含んでいるデータパケットあるいはスライスは、廃棄される。フローはそのあとブロック９１８に進み、そこでは、ストリームの中に更なるデータパケットがあるかどうかが判断される。
【００６２】
ブロック９１４に戻って、もしデコーディングエラーが無い場合、ブロック９１４では否定の結果となり、そのときは、フローはブロック９２０に進む。ブロック９２０では、符号化されたパケット、あるいはスライスが、オープンビデオフレームの中に挿入される。フローはそのあと、ブロック９２２に進み、そこでは、ストリームの中に更なるデータパケットがあるかどうかが判断される。
【００６３】
ブロック９２２において、もしストリーム中に更なるデータパケットが無いと判断される場合、ブロック９２２では否定の結果となり、フローはブロック９１８に進み、そこでは、ストリームの中に更なるパケットがあるかどうか判断される。ブロック９２２で、もしストリーム中にもっとパケットがあると判断される場合、ブロック９２２では肯定の結果となり、そのときフローはブロック９１０に進み、そしてパケットの次のマクロブロックがデコードされる。ブロック９１８に戻って、もしストリーム中に更なるデータパケットがあると判断される場合は、ブロック９１８では肯定の結果となり、フローはブロック９０２に進み、そして、シーケンスの中の次のパケットが検索される。もし、ブロック９１８において、ストリーム中に更なるデータパケットが無いと判断される場合、ブロック９１８では否定の結果となり、フローはブロック９２４に進みそしてストップする。
【００６４】
図１０は、マルチメディアプレイアウトデバイス８１２のための例示的な手続きを図示するフローダイアグラムである。図１０の例では、マルチメディアデータはビデオデータであり、そしてマルチメディアプレイアウトデバイス８１２はビデオプレイアウトデバイス(video play out device)である。フローはブロック１００２において始まり、そこでは、デコードされたビデオフレームがビデオデータのフレームレートでビデオフレームバッファから検索される。検索されるビデオフレームは、ビデオフレームバッファの中で最も古いフレームである。ビデオフレームの古さ(age)は、例えば、ビデオフレームのＲＴＰシーケンス番号、あるいはビデオフレームのタイムスタンプ、あるいは他の技術によって、判断され得る。フローはつぎにブロック１００４に進む。ブロック１００４では、検索されたフレームが調べられ、また、もし望まれれば、エラーコンシールメント(error concealment)が適用される。例えば、もしビデオフレーム中に、スライスの、見つからないパケット(missing packets)がある場合、あるいは、もしビデオフレーム全体が見つからない、あるいは他のタイプのエラーがある場合、エラーコンシールメント技術が適用され得る。
【００６５】
エラーコンシールメントは、例えば、現在のビデオフレーム中の破損されたスライスを取り替えるために前のビデオフレーム(previous video frame)からのパケットあるいはスライスをコピーすることを含む。エラーコンシールメントの別の例は、破損されたスライスの取替えスライスを生成するために近くのビデオスライス(neighboring video slices)からの情報を使用することである。例えば、近くのスライスからの情報は、例えば、破損されたスライスのための補間運動ベクトル(interpolation motion vectors)を決定するために使用されることができる。ビデオスライスにおけるエラーのコンシールメントのための他の技術もまたインプリメントされ得る。ブロック１００４のエラーコンシールメント技術もまた、ビデオデコーディングの一部として、例えば図９のフローダイアグラムの一部として、実行されることもできる。
【００６６】
フローはブロック１００４からブロック１００６に進む。ブロック１００６では、ビデオデータは表示される。例えば、ビデオデータは、携帯電話、ＰＤＡ、無線可能パーソナルコンピュータ、あるいは他の無線通信デバイスのような、無線通信デバイスの中のビデオディスプレ上に投影され得る。
【００６７】
図１１は、無線通信システム上でデータを送信するための例示的な手続きを図示するフローダイアグラムである。フローはブロック１１０２において始まる、ここでは、無線通信システムの物理層パケットサイズが決定される。例えば、物理層パケットサイズは、単一のサイズあるいは複数のサイズの１つであり得る。フローは、ブロック１１０４に進み、ここでは、圧縮ヘッダの最大サイズが決定される。フローはつぎにブロック１１０６に進む。ブロック１１０６では、情報単位がパーティションで区切られる。パーティションのサイズは、パーティションが符号化された後に符号化パーティションと圧縮ヘッダの合計のサイズ、あるいは総サイズが物理層パケットサイズ以下であるように選択される。
【００６８】
図１２は、本発明の例示的な実施形態に従って構成された、無線通信デバイス、あるいはＭＳのブロック図である。通信デバイス１２０２はネットワークインターフェイス１２０６、コーデック１２０８、ホストプロセッサ１２１０、メモリデバイス１２１２、プログラムプロダクト１２１４、およびユーザインターフェース１２１６を含んでいる。
【００６９】
インフラストラクチャからの信号は、ネットワークインターフェイス１１０６によって受け取られ、ホストプロセッサ１２１０に送られる。ホストプロセッサ１２１０は、信号を受け取り、そして、信号の内容によって適切なアクションで応答する。例えば、ホストプロセッサ１２１０は、マルチメディアデータストリーム、例えばビデオデータストリーム、の受信データパケットをデコードでき、あるいは、それは、デコーディングのためにコーデック１２０８に受信信号を送ることができる。別の実施形態においては、受信信号は、コーデック１２０８にネットワークインターフェイス１２０６から直接送られる。
【００７０】
ＭＳからの信号もまた、インフラストラクチャに、ホストプロセッサ１２０６、またはコーデック１２０８、あるいは両方から、ネットワークインターフェイス１２０６経由で送信されることができる。ホストプロセッサ１２１０はデータストリームを、ヘッダがデータパケットに付加された後にデータパケットと付加ヘッダの合計サイズが物理層パケットサイズに適合する(match)ようなサイズであるデータパケットに、パーティションで区切る(partition)ことができる。別の実施形態においては、コーデック１２０８はデータストリームを、ヘッダがデータパケットに付加された後にデータパケットと付加ヘッダの合計サイズが物理層パケットサイズに適合するようなサイズであるデータパケットに、パーティションで区切ることができる。両方の実施形態では、データパケットおよび付加ヘッダはそのあとネットワークインターフェイス１２０６に送られ、そしてインフラストラクチャに送信される。
【００７１】
一実施形態においては、ネットワークインターフェイス１２０６は、無線チャネル上でインフラストラクチャにインタフェースをとるトランシーバおよびアンテナかもしれない。別の実施形態においては、ネットワークインターフェイス１２０６は、地上通信線上でインフラストラクチャにインタフェースをとるために使用されるネットワークインタフェースカードかもしれない。
【００７２】
ホストプロセッサ１２１０およびコーデック１２０８の両方はメモリデバイス１２１２に接続される。メモリデバイス１２１２はＭＳの動作中にデータを保存するために使用されることができる。例えば、メモリデバイスは、再シーケンスバッファ、またはフレームバッファー、あるいは両方を含んでもよい。メモリデバイスはまた、ホストプロセッサ１２１０またはコーデック１２０８、あるいは両方によって実行されるプログラムコードを保存できる。例えば、ホストプロセッサ、コーデック、あるいは両方共、メモリデバイス１２１２に一時的に保存されるプログラミングインストラクションの制御の下で動作できる。ホストプロセッサ１２１０およびコーデック１２０８はまた、それら自体のプログラム記憶メモリを含むこともできる。プログラミングインストラクションが実行される時、ホストプロセッサ１２１０またはコーデック１２０８、あるいは両方が、それらの機能、例えば圧縮ヘッダを備えたマルチメディアストリームを符号化することおよびデコーディングすること、を実行する。このように、プログラミングステップ(programming steps)は、それぞれのホストプロセッサ１２１０およびコーデック１２０８の機能をインプリメントする(implement)ので、ホストプロセッサおよびコーデックは各々、望まれるように圧縮ヘッダを備えたコンテンツストリームを符号化するあるいはデコーディングする機能を実行するように作られることができる。プログラミングステップは、プログラムプロダクトリーダ(program product reader)１２１４から受け取られることができる。プログラムプロダクト１２１４は、ホストプロセッサ、コーデックあるいは両方による実行のために、プログラミングステップを、保存し、そしてメモリ１２１２に転送できる。
【００７３】
プログラムプロダクト１２１４は、交換可能な記憶装置を受け取るリーダ(reader)を含んでいるかもしれない。交換可能な記憶装置は、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭのような記憶装置に加えて、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、のような半導体メモリチップであってもよく、あるいは、コンピュータ可読のインストラクションを保存できる技術的に知られている任意の形式の記憶媒体であってよい。このように、本発明に従う動作に必要な処理ステップは、プログラムプロダクト上で具現化されることができる。図１２においては、ホストプロセッサが記憶媒体から情報を読み出し、そして記憶媒体に情報を書き込むことができるように、例示的な記憶媒体がホストプロセッサに結合されて示されている。あるいは、記憶媒体はホストプロセッサ１２１０と一体化されてもよい。
【００７４】
ユーザインターフェース１２１６は、ホストプロセッサ１２１０およびコーデック１２０８の両方に接続されている。例えば、ユーザインターフェース１２１６は、ユーザにマルチメディアデータを出力するために使用されるディスプレイおよびスピーカ含むことができる。
【００７５】
当業者は、実施形態に関連して記述された方法のステップは、本発明の範囲を逸脱することなく入れ替えられ得ることを認識するであろう。
【００７６】
当業者は、情報および信号は、様々な異なる技術および技法の任意のものを使用して表わされ得ることもまた理解するだろう。例えば、上記説明全体をとおして参照され得るデータ、インストラクション、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場またはあるいは磁性粒子、光場または光学粒子、またはそれらの任意の組み合わせ、によって表されることができる。
【００７７】
当業者は更に、ここで開示された実施形態に関連して説明された、種々の説明的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、あるいは両方の組み合わせとしてインプリメントされ得ることを認識するであろう。ハードウェアとソフトウェアのこの互換性を明瞭に説明するために、様々な例示的なコンポーネント、ブロック、モジュール、回路、およびステップが、概してそれらの機能性の点から上記に説明されている。それらの機能性が、ハードウェアあるいはソフトウェアとしてインプリメントされるかどうかは、システム全体に課される特定のアプリケーションおよび設計制約に依存する。熟練した熟練職人は、各特定のアプリケーションに対し様々な方法で記述された機能性をインプリメントするかもしれないが、しかし、そのようなインプリメンテーションの決定は、本発明の範囲から逸脱させるものとして解釈されるべきでない。
【００７８】
ここに開示された実施形態に関連して記述された様々な説明のための論理的なブロック、モジュール、および回路は、汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレー（ＦＰＧＡ）あるいは他のプログラマブル論理デバイス、ディスクリートゲートあるいはトランジスタ論理、ディスクリートハードウェア部品、あるいはここで説明された機能を実行するように設計されたこれらの任意の組み合わせを使ってインプリメントあるいは実行され得る。汎用プロセッサは、マイクロプロセッサであってもよい、しかし別の方法では、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、あるいは状態機械でもよい。プロセッサはまた、計算装置の組み合わせ、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと併用された１以上のマイクロプロセッサ、あるいは任意の他のそのようなコンフィギュレーション（configuration）としてインプリメントされてもよい。
【００７９】
ここに開示された実施形態に関連して記述された方法あるいはアルゴリズムのステップは、ハードウェアで直接に、プロセッサによって実行されるソフトウェアモジュールで、あるいは該２つの組合せで具現化され得る。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、あるいは技術的に知られている記憶媒体の任意の他の形態、に存在しうる。例示的な記憶媒体は、プロセッサが記憶媒体から情報を読み出しそして記憶媒体に情報を書き込めるように、プロセッサに結合される。別の方法では、記憶媒体はプロセッサに内蔵されてもよい。プロセッサと記憶媒体はＡＳＩＣに存在してもよい。ＡＳＩＣはユーザ端末の中に存在してもよい。別の方法では、プロセッサと記憶媒体は、ユーザ端末の中にディスクリート部品として存在してもよい。
【００８０】
開示された実施形態の以上の説明は、当業者の誰もが本発明を作りまたは使用するのを可能とするように提供されている。これらの実施形態の様々の変形は当業者には容易に明らかであり、そして、ここに定義された包括的な原理は本発明の精神或いは範囲を逸脱することなく他の実施形態に適用されることが出来る。従って、本発明は、ここで示された実施形態に限定されるように意図されてはおらず、ここに開示された原理及び新規な特徴と整合する最も広い範囲が与えられるべきものである。
【図面の簡単な説明】
【００８１】
【図１】図１は、本発明に従い構成された通信システム１００を示す。
【図２】図２は、無線ネットワーク上でパケットデータを配信するための例示的なパケットデータネットワークおよび様々なエアインタフェースのオプションを図示するブロック図である。
【図３】図３は、無線リンク上でマルチメディアデータを送信するためにＲＴＰを使用する時に存在する様々なレベルのカプセル化を例示するダイアグラムである。
【図４】図４は、データパケットおよび圧縮ヘッダのサイズに対する値のネゴシエーションの例を図示するフローダイアグラムである。
【図５】図５は、データパケットおよび圧縮ヘッダのサイズに対する値のネゴシエーションの別の例を図示するフローダイアグラムである。
【図６】図６は、無線通信システムにおけるゼロバイトヘッダ圧縮技術に基づくパケットデータ用のプロトコルスタックを例示するダイアグラムである。
【図７】図７は、ＩＰヘッダオーバーヘッド対ビデオデータストリームのデータレートを例示するグラフである。
【図８】図８は、ゼロバイトヘッダ技術が使用される時にマルチメディアデータをデコードする際に使用される例示的なコンポーネントを図示するブロック図である。
【図９】図９は、ゼロバイトヘッダ圧縮技術を使用するマルチメディアデータストリームのデコード化の例を図示するフローチャートである。
【図１０】図１０は、マルチメディアプレイアウトデバイスのための例示的な手続きを図示するフローダイアグラムである。
【図１１】図１１は、無線通信システム上でデータを送信するための例示的な手続きを図示するフローダイアグラムである。
【図１２】図１２は、本発明の例示的な実施形態に従って構成された、無線通信デバイス、あるいは移動局（ＭＳ）のブロック図である。
【図１】
2007537681.tif 000006
【図２】
2007537681.tif 000007
【図３】
2007537681.tif 000008
【図４】
2007537681.tif 000009
【図５】
2007537681.tif 000010
【図６】
2007537681.tif 000011
【図７】
2007537681.tif 000012
【図８】
2007537681.tif 000013
【図９】
2007537681.tif 000014
【図１０】
2007537681.tif 000015
【図１１】
2007537681.tif 000016
【図１２】
2007537681.tif 000017
【国際調査報告】
2007537681.tif 000018
2007537681.tif 000019