JP3694241B2

JP3694241B2 - インターネットプロトコルを使用する遠隔通信のための方法および装置

Info

Publication number: JP3694241B2
Application number: JP2000619894A
Authority: JP
Inventors: ヤング，リン
Original assignee: ルーセントテクノロジーズインコーポレーテッド
Priority date: 1999-05-25
Filing date: 2000-04-07
Publication date: 2005-09-14
Anticipated expiration: 2020-04-07
Also published as: WO2000072549A2; DE69927243D1; JP2003500933A; AU3829300A; DE69927243T2; EP1056259A1; US20040095939A1; EP1496654A2; EP1056259B1; US6788675B1; EP1496654A3; EP1496654B1; WO2000072549A3; EP1641193A1; US7154881B2; WO2000072549A8

Description

【０００１】
（省略語）
本稿では、下記の省略語を頻繁に使用する。
ＰＳＴＮ：公衆交換電話網
ＴＣＰ：トランスポート制御プロトコル
ＵＤＰ：ユーザデータグラムプロトコル
ＲＴＰ：リアルタイムプロトコル
ＩＰ：インターネットプロトコル
ＶｏＩＰ：ボイスオーバＩＰ
ＣＤ：コンプレッサ／デコンプレッサ
ＣＤＭＡ：符号分割多重アクセス
ＭＡＣ：媒体アクセス制御
ＲＬＣ：無線リンク制御
ＧＳＭ：モバイル通信のためのグローバルシステム
ＧＰＲＳ：汎用パケット無線サービス
【０００２】
【発明の分野】
本発明は、インターネットプロトコルを使用する遠隔通信のための装置および方法に関し、特に、有利なデータ圧縮構成に関する。
【０００３】
パケット交換技術を働かせているワイヤレス遠隔通信ネットワークでは、インターネットを使用して音声サービスおよびデータサービスを提供できれば有利であるが、各パケットヘッダ中でリアルタイムトランスポートプロトコル（ＲＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）の合成ヘッダを伝送する必要性があることは欠点である。この３つのヘッダは、それぞれ、パケット当り２０バイト、８バイト、１２バイトであり、この４０バイトロードは、ＧＳＭＦＲとして知られる音声符号化システムにおける２０ミリ秒間２３バイトの音声ペイロードのほぼ２倍である。ワイヤレスリソース／帯域幅は、地上線構成よりも高価であることがよく知られており、より大きなヘッダロードのオーバーロードは、深刻な欠点である。
【０００４】
（従来技術の簡単な説明）
ＲＦＣ２５０８、ｆｔｐ：／／ｆｔｐ．ｉｓｉ．ｅｄｕ／ｉｎ−ｎｏｔｅｓ／ｒｆｃ２５０８．ｔｘｔの「ＣｏｍｐｒｅｓｓｉｎｇＩＰ／ＵＤＰ／ＲＴＰＨｅａｄｅｒｓｆｏｒＬｏｗ−ＳｐｅｅｄＳｅｒｉａｌＬｉｎｋｓ」に、ＳＣａｓｎｅｒおよびＶＪａｃｏｂｓｏｎが開示する１つの解決法は、ＲＴＰ／ＵＤＰ／ＩＰヘッダを圧縮することである。これらのヘッダを圧縮および圧縮解除するためのプロトコルが定義されて、２バイトから５バイトの縮減を実現することができる。ただし、その大きな欠点は、圧縮パケットが損失された場合、それを再伝送しなければならず、誤り回復機構が必要不可欠であり、したがって、品質を保つためには、往復時間が短くなければならないことである。さらに、無線ベアラ容量が回線音声サービス用に設計され、したがって、リンク層ＰＤＵサイズが音声ペイロードにマッチするように設計されている多くの無線ネットワークでは、さらに２〜５バイトを１つの媒体アクセス制御（ＭＡＣ）ブロックに入れることさえ困難であり、したがって、圧縮ヘッダを有する１つの音声フレームを２つのＭＡＣブロックで伝送しなければならない可能性があり、余計な無線リソースが必要となる、あるいは音声品質の損失がある可能性があり、さらに、ハンドオーバのため、ネットワーク内で圧縮／圧縮解除ポイントが変化する可能性がある。それには、圧縮状態を再確立することが必要となり、それには、まずＣＯＮＴＥＸＴ＿ＳＴＡＴＥメッセージを送信し、次にＦＵＬＬ＿ＨＥＡＤＥＲパケットを送信する必要がある。これは、遅延およびパケット損失を引き起こす。
【０００５】
ｈｔｔｐ：／／ｗｗｗ．ｍｂｏｎｅ．ｃｏｍ／ｌｉｓｔｓ／ｒｅｍ−ｃｏｎｆ．１９９６Ｑ１／０２５９．ｈｔｍｌの１９９６年２月のｒｅｍ−ｃｏｎメーリングリスト上に提示された、ＳＰｅｔｒａｃｋ、ＥｄＥｌｌｅｓｓｏｎのＰｒｅｌｉｍｉｎａｒｙＩＥＴＦ草稿、「ＦｒａｍｅｗｏｒｋｆｏｒＣｏｍｐｒｅｓｓｅｄＲＴＰ」では、１バイトの「タイムクリック」数を使用して、２つの時間関連フィールド（ＲＴＰ順序番号数およびタイムスタンプ）を圧縮できることが示唆され、また別個のＲＴＰセッション制御が、ヘッダの静的部分を帯域外でシグナリングすることが示唆されているが、どのようにこれを実現するかの詳細は示されていない。
【０００６】
（発明の概要）
本発明によれば、ボイスオーバインターネットプロトコルアプリケーション層と、リアルタイムプロトコル層、トランスポート制御プロトコル層、ユーザデータグラムプロトコル層、およびインターネットプロトコル層を含むインターネットプロトコルスタックとを含むパケット交換無線ネットワーク用のモバイル局であって、音声データを圧縮するコンプレッサ／デコンプレッサと、音声データおよびコールシグナリングデータを別々に異なるデータ形式で、モバイル局のリンク層とエアインターフェースに送信する手段とをさらに含むモバイル局が提供される。
【０００７】
一構成では、コンプレッサ／デコンプレッサは、リンク層（これは、エアインターフェース内の物理層の上にある）とＩＰ層の間に配置され、音声データとコールシグナリングデータの両方を受信する。
【０００８】
代替構成では、コンプレッサ／デコンプレッサは、エアインターフェースとＶｏＩＰアプリケーション層の間に配置され、音声データを受信する。
【０００９】
また、本発明によれば、上記に定義した複数のモバイル局と、圧縮音声データに関連する信号を受信するように構成されたコンプレッサ／デコンプレッサ手段がその中に存在する少なくとも１つのネットワーク要素とを含むパケット交換無線ネットワークが提供される。
【００１０】
さらに、本発明によれば、音声サービスを提供するためにパケット交換無線ネットワークを動作させる方法であって、コールシグナリングおよびその他のデータから音声データを分離することを含み、それによって、音声データを含む各パケットは、圧縮されたまたは除去されたＲＴＰ／ＵＤＰ／ＩＰヘッダを備えることができる方法が提供される。
【００１１】
さらに、本発明によれば、パケット交換ネットワークのためのヘッダを圧縮および圧縮解除する第１方法は、各圧縮ヘッダ内に、パケットペイロードのサンプリング時刻を表す周期的にリセットされるｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒを提供すること、および各サンプル持続時間ごとに１ずつｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒを増加させ、前記リセット周期をカウントして、リセット周期の前記カウントおよび受信したｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒから圧縮解除されたヘッダを提供するために順序番号数およびタイムスタンプを提供することを含む。
【００１２】
さらに、本発明によれば、パケット交換ネットワークのためにヘッダを圧縮および圧縮解除する第２方法は、合成ＲＴＰ／ＵＤＰ／ＩＰヘッダを除去し、ＲＬＣ／ＭＡＣペイロード内にデータを入れること、および内部クロックを使ってタイムスタンプ値を得ることにより受信パケットを圧縮解除し、連続パケットに対して１ずつ順序番号数を増加させることを含む。
【００１３】
また、本発明によれば、帯域外プロトコル上でコールセットアップ情報を利用することにより、パケット交換ネットワーク内でパケットヘッダの圧縮状態を確立する方法が提供される。
【００１４】
次に、添付の図面を参照し、例によって本発明を説明する。
（モバイル局およびモバイルネットワークの好ましい実施形態の説明）
図１では、ワイヤレスモバイル通信システム１０が、いくつかのモバイル局（ＭＳ）１２と、２つの要素、ＳＧＳＮ（サービス提供ＧＰＲＳサポートノード）２２およびＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）２４から成るパケットコアネットワーク（ＣＮ）２０にＲＮＣ（無線ネットワークコントローラ）１６を介して接続されたいくつかの基地トランシーバ局（ノードＢ）１４（１２、１４、１６はすべて、無線アクセスネットワークＲＡＮ１８内にある）とを含む。ＣＮは、ＩＰ／ＰＳＴＮゲートウェイ２６を介して、ＰＳＴＮ（公衆交換電話網）３０およびインターネット２８に接続される。
この図では、ネットワークアーキテクチャは、ＵＭＴＳ基準モデルに基づいている。
【００１５】
ネットワーク１０は、パケット交換モードで動作するものと想定する。音声サービスを実施する一方式は、ＶｏＩＰ技術を使用するものであり、そこでは、モバイル局１２からのＶｏＩＰアプリケーションが、汎用ＩＰアプリケーションとして扱われ、また符号化された音声が、ＲＴＰ／ＵＤＰ／ＩＰパケットに分解されて、エア、ＲＡＮ１８、およびＣＮ２０をを介してインターネット２８に、またはＩＰ／ＰＳＴＮゲートウェイ２６を介してＰＳＴＮ３０に伝送される。
【００１６】
モバイル局１２において、ＩＰベースのコールシグナリングおよびＶｏＩＰアプリケーションのグラフィカルユーザインターフェースが、通常のＩＰ端末上におけるのと同様に動作することができる。音声トラフィックは、下記により詳細に説明するとおり、そのＲＴＰ／ＵＤＰ／ＩＰヘッダ情報が圧縮または除去されたリンク層ペイロードとして送信される。
【００１７】
図２ａを参照すると、モバイル局６０からネットワークへのアップリンク方向が考慮されている。モバイル局内には、ＶｏＩＰアプリケーション層６８が存在し、そこからコールシグナリングデータがＴＣＰ層６６およびＵＤＰ／ＩＰ層６５に送信される。音声データはＲＴＰ／ＵＤＰ層６７およびＩＰ層６５に伝送される。
【００１８】
パケット中のコールシグナリングデータと音声データはともに、コンプレッサ６４に提供される。これは、合成ＲＴＰ／ＵＤＰ／ＩＰヘッダを圧縮するが、コールシグナリングデータは圧縮しない。２つの型のパケット６２、６３（圧縮および非圧縮）が、ＲＬＣ／ＭＡＣプロトコルに入れられ、エアインターフェース６１を通過する。
【００１９】
音声データおよびコールシグナリングデータを受信する（ダウンリンク方向）場合は、プロセスが逆になる。
【００２０】
図３ｂに示すモバイル７０に関する代替の構成では、コンプレッサ７４が、ＶｏＩＰアプリケーション７８に／から音声データ６３を送信／受信し、他方、コールシグナリングデータ６２は、通常のＩＰ層７５、７６を通過する。
どちらの構成でも、音声データとコールシグナリングデータは分離される。
【００２１】
図３は、システム全体を示す。図では、コンプレッサ６４を備えたモバイル６０が、エアインターフェース６１を介して順次、エアインターフェース６１とコアネットワーク８４の間でデータをトンネル伝送またはリレーする無線アクセスネットワーク（ＲＡＮ）８１に、またインターネットを介して任意のＩＰホスト８５に接続されたＣＮ８２内のデコンプレッサＣＤ８３に接続されている。
【００２２】
図２ａ、２ｂ、３に示す構成では、ＩＰ／ＵＤＰ／ＲＴＰヘッダ情報は、モバイル局６０からＣＮ８４内のＣＤ８３への経路などには使用されず、代りに、音声パケットを含むすべてのデータが、リレー／トンネル伝送されるものと想定する。パケットは、モバイル６０とＣＤ８３の間で順に送達されるものと想定する。さらに、圧縮（音声）パケットを通常の（非圧縮）パケットから区別することができる何らかの機構があり、この区別は、ＣＮ８４に到達するまで維持できるものと想定する。
【００２３】
前述の構成は、ＧＳＭなどのワイヤレス通信システムによって提供される回線交換音声サービスと同様のレベルの無線効率レベルを実現することができる。
エラー回復機構が全く必要ないことがさらなる利点であり、また圧縮解除に関するパケット間の依存関係が存在せず、したがって、パケット損失が圧縮ポイントの障害を引き起こすことがない。
【００２４】
ＶｏＩＰアプリケーション６８、７８は、通常のＩＰネットワークにアクセスしているかのように動作する。ただし、音声パケットは、ＭＳ６０からＣＮ８４に至るその行程の一部分では、別の方式で扱われる。また、もう一方のＩＰエンドポイント８５（ユーザ端末またはＩＰ／ＰＳＴＮゲートウェイ）から見ると、ＲＡＮ８１内の要素（ＭＳ６０、ノードＢ、およびＲＮＣ８０）は、エンドポイントとして一組で扱われる。というのは、音声フレーム（データ６３）は、ＣＤ８３でＲＴＰフレーム化される前に、比較的長い道程を移動する必要があるからである。
【００２５】
この構成の一般的利点は、圧縮ゲインがより高くリソースが節約されること、圧縮と圧縮解除の間の往復時間が長いときに、システムが動作すること、ＩＰベースのコールシグナリングの利点が保たれ得ることである。
【００２６】
（２つの好ましいアルゴリズムの説明）
ＩＰ／ＵＤＰ／ＲＴＰヘッダ用の、圧縮アルゴリズムが２つあり、その１つは、「ベストエフォート圧縮」と特徴付けることができ、もう１つは、「ゼロヘッダ圧縮」と特徴付けることができる。両方のアルゴリズムとも、ＭＳ６４とＣＮ８４の間では、ＩＰ／ＵＤＰ／ＲＴＰヘッダが使用されないことに基づくものである。
【００２７】
（第１の好ましいアルゴリズム）
その目的は、圧縮パケットの相互依存関係を断つことである。圧縮ヘッダ内で相対値を送信する（差分符号化により）代りに、Ｐｅｔｒａｃｋによって示唆されるとおり、絶対値（タイムクリック数）が送信される。圧縮ＲＴＰパケット間の相互関係が存在しないため、パケットの喪失によって、圧縮解除の動作を停止することはない。
【００２８】
− 圧縮ヘッダは、既知の構成での２〜５バイトであるのに対して、この第１アルゴリズムを使用すると、１バイトだけとすることができる。ＲＴＰヘッダ内の最も重要な情報である、２つの時間関連フィールド、つまりタイムスタンプおよび順序番号数を、保持する必要がある。前述のＰｅｔｒａｃｋの論文に指摘されるとおり、これらの２つのフィールドは、「タイムクリック数」（１バイト）で置き換えることができる。この数は、デコンプレッサが適切なタイムスタンプ（モバイル局６０におけるサンプリング時刻を反映する）および順序番号数を付ける助けとなる。この刊行物は、従来のタイムスタンプおよびＲＴＰ数の代りに、単一の１バイト「タイムクリック」数を各パケットとともに送信することを示唆している。ただし、前記刊行物には、どのようにタイムスタンプおよび順序番号数を回復するか、またはどのように帯域外圧縮状態を確立するかの開示は行われていない。
【００２９】
− 圧縮を必要とするＶｏＩＰセッションが端末ごとに１つだけ存在し、したがって、ＣＩＤ（コンテキストＩＤ）ビットは、必要ないものと想定される。ＲＴＰヘッダ内のＭビットは保存され、各圧縮パケットとともに伝送される。
【００３０】
圧縮状態、第１アルゴリズム
コール（２つのＲＴＰセッションから成る）を圧縮するため、圧縮状態は下記の情報を含む。各コールエンドごとに、ＩＰアドレス、２つのポート番号（発信用および着信用）、ＳＳＲＣ等。コールごとに、使用されるコーデックおよびそのパラメータ（例えば、サンプリング速度およびサンプル持続時間）。このコーデックは、両方向に関して同一であると想定する。（そうでなければ、別々に記憶する必要がある）
【００３１】
圧縮状態の確立は、コールシグナリングプロトコルと協働することができる、後述の帯域外プロトコルを使って行われる。このプロトコルはまた、ＣＤ間のハンドオーバの場合に、あるＣＤから別のＣＤに状態情報を移す助けにもなる。
【００３２】
圧縮プロセス、第１アルゴリズム
圧縮によって、タイムスタンプ、順序番号数、およびＭビットの３つのフィールドがほとんど無損失に保存される。１バイト（８ビット）が、圧縮ヘッダに使用される。第１ビットは、Ｍｂｉｔ用に使用され、他の７ビットは、パケット内に含まれる音声ペイロードのサンプリング時刻を表すｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒに使用される。これは、毎サンプル持続時間ごと、例えば、ＧＳＭ６．１０符号化の場合は、２０ミリ秒ごとに、１ずつ増加される。これは、パケットが実際には送出されないサイレント期間でも増加され続けることになる。
【００３３】
その情報が、圧縮を介して不正確になる可能性があるフィールドは下記のものである。
− ＩＰｖ４におけるパケットＩＤ。パケットＩＤフィールドは、常に１ずつ増加され、したがって、通信される必要はないものと想定される。パケット損失が検出されたとき、ＩＤ値は、それに応じて設定される。すべてのパケット損失が検出できるわけではないので、ＩＤ値は、不正確になる可能性がある。
【００３４】
− ＵＤＰチェックサムフィールド。チェックサムフィールドは、モバイル端末６０からは使用されない（０に設定される）。このフィールドは、ダウンリンク方向で使用される場合、ネットワーク内のＣＤによって０に設定される（この場合、このフィールドを必要とするアプリケーションに関する終端間エラー検出が使用不能にされる）。したがって、ＵＤＰチェックサムを使用するエラー修正は、使用不能にされる。
【００３５】
− ＲＴＰＣＳＲＣリスト。アップリンク方向では、ＣＳＲＣリストは、常に空でなければならない。ダウンリンク方向では、このリストは変更され得る（例えば、会議コールの場合）。２者間コールの場合、このリストは変更されない（空）。
【００３６】
− 順序番号数。モバイル局とＲＴＰプロキシの間でパケット損失があり、デコンプレッサがそれを検出できなかった場合、順序番号数は、ＲＴＰプロキシによって間違って回復される。これが、パケット損失レートの統計結果の精度に影響を与える可能性がある。
【００３７】
圧縮サービスにアクセスするモードが２つ存在する。１つは、ＶｏＩＰアプリケーションが、トランスポート層およびネットワーク層をバイパスして直接に（図３（ｂ）に示すとおり）アクセスする。明白な利点は効率であるが、アプリケーションの何らかの変更、またはトランスポート層ラップアップが必要となる可能性がある。コンプレッサに対するサービスアクセスプリミティブは、下記のとおりであることが可能である。
【００３８】
ｃｏｍｐｒｅｓｓ（Ｍ，ｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒ，ｖｏｉｃｅｐａｙｌｏａｄ）
これら３つのデータアイテムを備える圧縮ＲＴＰパケットを生成するのは簡単である。
【００３９】
あるいは、圧縮サービスは、ネットワーク層からトランスペアレントにアクセスすることが可能であり（図２（ａ）に示すとおり）、したがって、すべての上位層は圧縮について知られていないものである。この場合、上位層からパケットを受け取った時点で、送信元／宛先ＩＰおよびポート番号、ならびに送信元ＳＳＲＣの各フィールドも検査する。これら５つのフィールドは、ＲＴＰセッションを識別するものであり、圧縮状態テーブルに照らしてこれらのフィールドを検査することにより、そのパケットを圧縮するか（そのパケットが、その圧縮状態が既に確立されているＲＴＰパケットである場合）、それとも非ＲＴＰの通常パケットのように扱うかが決定される。そのパケットが、圧縮されるべきＲＴＰパケットである場合、タイムスタンプフィールドをタイムクリック−数にマップする。次に、前記サービスプリミティブを呼び出すことができる。
【００４０】
ダウンリンク方向では、ＵＤＰチェックサムを使用する場合（非ゼロ）、これは無視される。
【００４１】
圧縮ＲＴＰパケットは、生成された後、そのパケットが音声パケットであることを伝えるマーカとともにリンク層パケットに入れられる。その他の非圧縮パケットは、自らを一般データパケットとしてマーク付けするリンク層パケットに入れられることになる。
【００４２】
圧縮解除プロセス、第１アルゴリズム
時間関連ＲＴＰヘッダフィールドを除けば、その他のフィールドの回復は、ＲＦＣ２５０８と同様の手法を使用して圧縮状態から行われる。
【００４３】
タイムスタンプフィールドに関して、解決すべき大きな問題は、タイムクリック数のためのフィールドが７ビットしかないということである。１回の電話コール中に、クリックのカウントが続き、容易にラップアラウンドされる（周期的にリセットされる）可能性がある。サイレント期間中、コンプレッサによって送信されるパケットが存在しない場合、このサイレント期間中に経過した時間（いくつの周期が経過したかで見た）が検出されなければならない。
【００４４】
本発明による第１アルゴリズムでは、ＣＤ８４にあるコンピュータクロックを使用して周期がカウントされ、タイムクリック数を使用して、クロック読取り値を参照しながら、タイムスタンプフィールドが設定される。このクロックは、粗い細分性で動作することが可能である。例えば、最大ジッタがＴ／４未満であると想定して、クロックは、毎Ｔ／４周期ごとに１ずつ増加されることが可能である。この想定は、無難な想定であり、ここで、Ｔは、７ビットで表される周期の期間である。これはコーデックパラメータに応じて、通常、数秒間である。
【００４５】
次に、順序番号数に移ると、この番号は、通常、毎連続パケットごとに１ずつ増加される。この番号は、主に、パケット損失を反映させるのに使用する。本発明による第１アルゴリズムでは、タイムクリック数とＭビットの両方の増加を検査することにより、ヒューリスティックな方法を使用してパケット損失が検出される。タイムクリック数は、１以外の小さい数（例えば、２、３等）だけ増加されるが、Ｍビットは設定されていない場合には、何らかのパケット損失が存在する可能性が高い。この場合、順序番号数は、タイムクリック数の差だけ増加される。所定Ｍビットを搬送するパケットが失われた場合（この場合、サイレント期間であるため、タイムクリック数がより大きく増加するのが普通である）、順序番号数は、やはり１ずつ増加されるはずである。この状況が生じる確率は、極めて小さい。これが生じ、順序番号数が間違って増加された場合でも、他のＲＴＰエンドによって認識されるパケット損失レートの統計結果に与える影響はわずかである（いくつかより多いパケットが損失されたものと報告される）。
【００４６】
記号
ｓｄ：サンプル持続時間、この値、例えば、２０ミリ秒（各パケット内の音声）は、コールセットアップ手続きから導出されるはずである。
ｓｒ：サンプルレート、この値、例えば、８０００は、コールセットアップ手続きから導出されるはずである。
ｎｂ：タイムクリック数に使用するビット数
ＴＳｌａｓｔ：前のパケットに関するタイムスタンプ
ＴＳｔｈｉｓ：現行パケットに関するタイムスタンプ
ＷＴｌａｓｔ：前のパケットに関するウォールクロック読取り値
ＷＴｔｈｉｓ：現行パケットに関するウォールクロック読取り値
ＴＮｌａｓｔ：圧縮ヘッダ内の前のパケットのタイムクリック数
ＴＮｔｈｉｓ：圧縮ヘッダ内の現行パケットのタイムクリック数
ＳＮｌａｓｔ：前のパケットのＲＴＰ順序番号数
ＳＮｔｈｉｓＬ：現行パケットのＲＴＰ順序番号数
Ｔ：ｎｂビット（周期）を使用してサンプル持続時間（ｓｄ）単位で表される期間
Ｔ＝２^＊＊ｎｂ
Ｍ：圧縮ヘッダ内の「Ｍ」ビットの値
タイムスタンプおよび順序番号数を計算する：

【００４７】
（第２の好ましいアルゴリズム）
次に、ヘッダ圧縮のための第２アルゴリズムを説明する。ヘッダは、ゼロであることが可能である。
【００４８】
いくつかの場合、例えば、ＧＰＲＳ（汎用パケット無線システム、ＧＳＭシステムを介するオーバーレーパケットネットワーク）では、無線ベアラチャネルは、音声データとともに追加のヘッダ情報を加えることが困難なように設計されている。したがって、音声を「生の」形式（音声のみ）で伝送できるが、それでもＩＰ電話からの利点のほとんど（例えば、ＩＰベースコールシグナリングが、ＣＰＬ、ウェブベースのコール等を可能にする）を維持することが可能かどうか調べることにする。
【００４９】
この解決法の基本的着想は、図４ｂに示すとおり、モバイル局６０とＣＮ８４の間のパスが制御されたパケットネットワークを介する（例えば、フレームリレーまたはＡＴＭを介する）こと、また何らかのＱｏＳが提供されること（配列の誤りがなく、ジッタおよびパケット損失レートが小さく、このパス上で音声品質が低下しない）を考慮して、モバイル局とＣＰの間でＩＰ／ＵＤＰ／ＲＴＰヘッダを完全に除去し、ＲＴＰエージェントと呼ばれるボックスをＣＮ内のデコンプレッサとして使用することが可能である。
【００５０】
− この場合、ＲＴＰエージェント（アップリンク方向）は、ＩＰ／ＰＳＴＮゲートウェイと同様の役割を果す。アップリンク方向では、モバイル局からの音声フレームが、ＩＰ／ＵＤＰ／ＲＴＰヘッダなしに、ワイヤレスネットワーク内、例えば、ＧＳＭ内の回線モード音声と非常に近い方式で、ＲＴＰエージェントまで伝送され、このエージェントが、適切なヘッダを追加して、それらのフレームをＶｏＩＰネットワークに送り出す。ダウンリンク方向では、ＲＴＰエージェントは、ヘッダを取り除き、それらのフレームをモバイル局まで伝送する。
【００５１】
第２アルゴリズムを使用すると、ＩＰベースのコールシグナリングおよびサービス作成の利点が保持される。同時に、高無線リソース効率の利点が存在する。他方、モバイル端末は、ＲＴＰヘッダ情報を利用する何らかの機能、例えば、パケット損失レートおよびパケット遅延を知る機能を失う可能性があり、またそれに応じてプレイバッファを調整することができる。
【００５２】
第１アルゴリズムと第２アルゴリズムの間の大きな違いは、第２アルゴリズムを使用するとき、
− モバイル局上で、ＶｏＩＰアプリケーションが、ＲＴＰヘッダ内の任意の時間関連情報を使用する機会を失う。例えば、パケット損失を検出し、ジッタを計算すること。圧縮自体は、さらなるパケット損失やジッタを導入しないことに留意されたい。適切なＲＴＣＰパケットを生成するのは困難であるが、その代理でこのジョブを行うようにＲＴＰエージェントに求めることができる。
【００５３】
− コールのその他のＩＰエンドポイント（ユーザ端末またはゲートウェイ）から見れば、ＲＴＰエージェントによって検出される（また、順序番号数のフィールド内およびタイムスタンプのフィールド内に反映される）パケット損失は、第１アルゴリズムよりも正確さが劣る可能性がある。
【００５４】
第２アルゴリズム内のＣＤがＩＰ／ＵＤＰ／ＲＴＰヘッダを追加する（アップリンク）およびそれを取り除く（ダウンリンク）方式は、汎用ＩＰ／ＰＳＴＮ媒体ゲートウェイで使用される方式に似通っている。異なる点は、下記のとおりである。
【００５５】
− 汎用媒体ゲートウェイは、通常、２つのネットワークインターフェースを有する。１つは、ＰＳＴＮ用のものであり、もう１つは、パケットネットワーク（例えば、ＩＰ、ＡＴＭ）用のものである。このゲートウェイは、回線モードとパケットモードの間で媒体を変換する。ＲＴＰエージェントは、２つのネットワークインターフェースを有し、その両方とも、パケットネットワーク用のものである。
【００５６】
− 汎用媒体ゲートウェイでは、ＰＳＴＮ側から来る音声は連続的であり、その速度は一定である。この場合、音声フレームは、両方の側でパケットネットワークを介して伝送されるので、ゲートウェイは、より多くのこと、ＲＡＮ側からのパケットの着信間時間を調べることにより、正しい順序番号数およびタイムスタンプを付加するために、パケット損失を検出しようとする必要があり、モバイル端末に代わってＲＴＣＰパケットを送信することが必要となる可能性がある。
【００５７】
圧縮状態、第２アルゴリズム
これは、ＲＴＰプロキシ手法と同じである。
【００５８】
圧縮プロセス、第２アルゴリズム
圧縮プロセスは、非常に単純である。このプロセスは、単に、どのヘッダも取り除き、音声データだけをＲＬＣ／ＭＡＣメッセージに入れる。コンプレッサに対するサービスアクセスプリミティブは、下記のとおりであることが可能である。
【００５９】
ｃｏｍｐｒｅｓｓ（ｖｏｉｃｅｐａｙｌｏａｄ）
ＲＴＰプロキシ手法においてと同様に、端末での圧縮サービスは、ネットワーク層からトランスペアレントにアクセスすることができる。この場合、ネットワーク層からパケットを受信すると、このサービスは、送信元／宛先ＩＰのフィールドおよびポート番号、ならびに送信元ＳＳＲＣも検査する。これら５つのフィールドは、ＲＴＰセッションを識別するものであり、圧縮状態テーブルに照らしてこれらのフィールドを検査することにより、そのパケットを圧縮するか（そのパケットが、その圧縮状態が既に確立されているＲＴＰパケットである場合）、それとも非ＲＴＰの通常パケットのように扱うかを決定する。そのパケットが、圧縮されるべきＲＴＰパケットである場合、ヘッダを取り除き、前記サービスプリミティブを呼び出すことができる。
【００６０】
ダウンリンク方向では、ネットワーク内のＣＤが、各パケットを検査して、それが圧縮されるＲＴＰセッションに属するかどうか調べる。そうである場合、ＲＴＰ／ＵＤＰ／ＩＰヘッダが取り除かれ、音声データが、例えば、正しいモバイル端末を宛先とするトンネル伝送プロトコルのペイロードに入れられる。
【００６１】
圧縮解除プロセス、第２アルゴリズム
ネットワーク内のデコンプレッサ（ＣＤ８４）で、コンピュータクロックが使用される。第１アルゴリズムに関して大きな問題は、どのように時間関連フィールドを回復するかである。これを行う方式が２つ存在する。
【００６２】
（ａ）− デコンプレッサが、毎サンプリング持続期間（ＲＴＰパケットによって搬送される音声フレームによってカバーされる期間、例えば、これは、各ＲＴＰパケットがＧＳＭ６．１０音声フレームを搬送する場合、２０ミリ秒になる）の始めに、ＲＡＮから来る圧縮音声パケットが存在するかどうか検査する。「イエス」である場合、デコンプレッサは、そのパケット上にＩＰ／ＵＤＰ／ＲＴＰヘッダを追加する。デコンプレッサは、ジッタを平滑にするため、ＲＡＮから着信する音声パケット用の小さいバッファを維持する。
【００６３】
− デコンプレッサは、内部クロックからタイムスタンプ値（ＲＴＰで使用されるサンプリング時刻形式に変換された）を得る。順序番号数が、各パケットごとに１ずつ増加される。
【００６４】
（ｂ）− 別法では、デコンプレッサは、ＲＡＮ側に着信する各圧縮パケットの着信間時間を検査し、遅延の変動およびサイレント期間の可能性を考慮して、パケット損失が存在するかどうか推定する。この分析を行った後、着信したばかりのパケットが、前のパケットの連続音声パケットであると考えられる場合には、送信元においてと同様に、タイムスタンプが増加される（前のパケットのタイムスタンプ値の上に、使用する符号化スキームによって決定される定数値を加えて）。順序番号数が、前のパケットの順序番号数の上に１ずつ加えて増加される。パケット損失が推定される場合には、それに応じて、そのギャップを反映するように順序番号数およびタイムスタンプが増加されることになる。長いギャップが検出され、サイレント期間が推定される場合、順序番号数は、１ずつ増加されるが、タイムスタンプは、そのギャップを反映する必要がある。
【００６５】
パケット交換無線ネットワークに関連して第１の好ましいアルゴリズムおよび第２の好ましいアルゴリズムを説明してきたが、両方のアルゴリズムとも、下記の特徴が成立するその他の状況においても適用できる。
【００６６】
− モバイル局とＩＰネットワークの間の第１レッグは、ＩＰヘッダがそこでは使用されない２地点間接続である。
【００６７】
− 接続の第１レッグは、順序の整った送達および小さいジッタを保証する。上記に指摘したいくらかのヘッダの不正確さは、アプリケーションにとって許容可能である。
【００６８】
（圧縮状態の確立および再確立の好ましいプロセス）
いくつかの目的／機会で、圧縮状態確立プロセスが使用される。
− ＲＴＰセッションの始めに、圧縮および圧縮解除を開始するため、圧縮状態を確立する必要がある。
【００６９】
− ＣＤ間ハンドオーバが起きた場合、モバイル端末および／または古いＣＤから新しいＣＤに、圧縮状態を移す必要がある。
【００７０】
圧縮状態は、下記の情報を含む。両方のコールエンドに関するＩＰアドレスおよびＳＳＲＣ、２対のＲＴＰ（ＵＤＰ）ポート番号、ペイロードタイプ、サンプリング速度、サンプル持続時間等。
【００７１】
両方向に関する音声符号化は同一であると想定され、そうでなければ、それらは別々に記憶する必要がある。
【００７２】
圧縮状態の確立および再確立は、帯域外プロトコルを使用して行われる。このプロトコルを図５に示す。この図は、サードパーティ制御下のＶｏＩＰコール制御層９２に接続されたモバイル局コンプレッサ９０と、サービス提供ネットワークＣＤ９４および別のネットワークコンプレッサ９６と、ネットワークＣＤ９４とを示し、９６は、帯域外リンク９８によって直接に接続され、サードパーティ制御下のＶｏＩＰコール制御層１００および移動管理層１０２にも接続されている。
【００７３】
すべてのＣＤ９０、９４、９６は、実際には、コンプレッサ／デコンプレッサである。
【００７４】
モバイル局にあるＣＤ９０およびネットワーク内のＣＤ９４は、制御インターフェースを有する。両方のＣＤとも、既知のポート上で聴取し、サードパーティから圧縮を開始／停止する命令を受け入れ、状態情報を受け取る。通常、命令および情報は、ＭＳにある音声アプリケーションおよび／またはネットワーク内のシグナリングゲートウェイ（例えば、４．３２３ＧａｔｅｋｅｅｐｅｒまたはＳＩＰ（セッション開始プロトコルサーバ））から来る。（サービス提供ＣＤのＩＰアドレスは、シグナリングゲートウェイには知られているものと想定する。）
【００７５】
ＣＤとサードパーティ制御の間、または２つのＣＤ間で定義されるメッセージが６つ存在する（肯定応答メッセージを含めず）。
【００７６】
１．ＳＴＡＴＥ＿ＳＴＡＲＴ。このメッセージは、新しい圧縮セッションおよびその状態が確立されることを示す。このメッセージは、そのセッションに関与するＭＳの識別を含まなければならない。オプションとして、このメッセージは、圧縮状態情報をそこから抽出することができるように、完全な（未圧縮の）ＲＴＰパケットを含むことができる。
【００７７】
２．ＳＴＡＴＥ＿ＩＮＰＵＴ。このメッセージは、状態属性の値を提供または変更する。このメッセージは、（ａｔｔｒｉｂｕｔｅ＿ｎａｍｅ、値）対のリストを含む。
【００７８】
３．ＳＴＡＴＥ＿ＥＮＱＲＹおよびＳＴＡＴＥ＿ＥＮＱＲＹ＿ＲＰＬ。これら２つのメッセージを使用して状態情報を照会し、圧縮／圧縮解除タスクを実行する準備ができているかを知ることができる。
【００７９】
４．ＳＴＡＴＥ＿ＨＡＮＤＯＶＥＲ。このメッセージは、新しいＣＰに状態情報を送るように現行のサービス提供ＣＰに通知する、または前のサービス提供ＣＰから状態情報を獲得するように新しいサービス提供ＣＰに求める。このメッセージは、古いＣＰおよび新しいＣＰのＩＰアドレスおよび関与するＭＳの識別に関する情報を含む。
【００８０】
５．ＳＴＡＴＥ＿ＳＴＯＰ。このメッセージは、圧縮状態を削除する。圧縮は、必要なときに、コンプレッサ自体によっても削除され得る。
【００８１】
メッセージＳＴＡＴＥ＿ＩＮＰＵＴはまた、ＭＳにあるコンプレッサ９０とネットワーク内のＣＤ９４、９６の間で状態情報を交換するために使用される。したがって、一端で使用可能な情報が、このプロトコルを使うと、他の端でも使用可能になる。
【００８２】
メッセージＳＴＡＴＥ＿ＩＮＰＵＴおよびＳＴＡＴＥ＿ＥＮＱＲＹはまた、ハンドオーバの場合に、１つのＣＤから別のＣＤに状態情報を移動するのに使用される。上記に列挙した状態要素の他に、ローカルクロック読取り値などの何らかの追加情報も新しいＣＤに交換される。
【００８３】
いくつかの状況で、いくつかの属性に関する値をピックアップする、またはそのデフォルト値を使用することがコンプレッサに許されている。
【００８４】
このプロセスはまた、ＭＳおよびネットワーク内におけるＣＤ間の状態再確立をサポートする。これは、状態情報が一方の側で損傷または損失したときに必要である。ＣＤまたはＭＳにあるコンプレッサは、状態情報の不在または不完全性を検出すると、ＳＴＡＴＥ＿ＥＮＱＲＹを使用してもう一方の側から状態情報を得ることができる。
【００８５】
圧縮状態を確立または再確立する本発明のプロセスをパケット交換無線通信ネットワークに関連して説明してきたが、このプロセスは、ＶｏＩＰセッションやマルチメディアセッションなどの接続指向アプリケーションのためのどのような圧縮プロセスとしても使用することができる。
【００８６】
（２つの圧縮ポイント間のハンドオーバに関する２つの好ましいプロセス）ワイヤレスネットワーク内でＲＦＣ２５０８に提示される圧縮スキームを使用することの１つの問題は、移動性の影響である。ハンドオーバが起きたとき、サービス提供ＣＤが変更される可能性がある。したがって、ハンドオーバ前のＣＤ内に記憶された圧縮状態を新しいＣＤに移されなければならない、またはそこで再確立しなければならない。
【００８７】
この問題に対処する２つの代替手法が提案される。
第１に、２つのＣＤ間で何らかの通信を構成して、これらのＣＤが図６に示すとおり、圧縮状態を交換できるようにすることができる。この図では、コンプレッサ１０４を有するモバイル局が、ネットワーク内のサービス提供ＣＤ１０６からネットワーク内の新しいＣＤ１０８にハンドオーバされる。サービス提供ＣＤ１０６および新しいＣＤ１０８は、帯域外通信チャネル１１０を備えている。
【００８８】
１つの方式は、一群のＣＤ（これらは、ハンドオーバの後にサービス提供ＣＤになる潜在的可能性がある）の間で圧縮状態情報を共有し、ハンドオーバが起きたとき、必要な圧縮コンテキストが新しいＣＤ内で既に用意されているようにすることである。この方法のコストは、ＣＰＵ時間、および全く使用されない可能性があるコンテキストを受信／記憶するのに必要なメモリである。
【００８９】
別の方式は、ハンドオーバ中にコンタクト情報を交換することである。この手法を適用するには、ＣＤが変更されたときに圧縮状態情報の交換が起動され得るように、ハンドオーバ機構からの協力が必要である。
【００９０】
第３の方式は、ソフトハンドオーバ機能の使用をＣＤＭＡネットワーク内で利用可能にすることである。コンテキストの交換は、ソフトハンドオーバ期間中に実行することができる。この手法は、ソフトハンドオーバが起きたときに２つのＣＤが通知され得るように、無線ネットワークからの協力を必要とする。
【００９１】
新しいＣＤで圧縮解除プロセスを可能にするためには、圧縮状態情報の交換は、前のＣＤによる最後の圧縮解除されたＲＴＰパケット内にタイムスタンプ値および順序番号数値を含んでいなければならない。前のＣＤと新しいＣＤにある２つのコンピュータクロックは、同期されている必要はない。新しいＣＤは、ＲＴＰセッションハンドオーバの動作を開始したとき、それ自体のクロックを読み取り、その読取り値を最後のパケットに関するクロック読取り値として使用する。
【００９２】
第２に、ＵＭＴＳおよびＧＰＲＳの状況と同様に、バックボーンネットワークに向けてＣＮを離れる時点まで、ユーザＩＰは使用されない（ＢＳＳとＣＮの間でユーザパケットをトランスポートするのに、トンネル伝送プロトコルが使用される）。したがって、この機能を利用して、ＣＰをＣＮの端、例えば、ＧＧＳＮに置き、ＣＰがハンドオーバに対してトランスペアレントであるようにすることができる。詳細には、ＣＰをＣＮ内に移動させることにより、ＶｏＩＰサービスネットワークを利用することが必要なＣＰおよびＩＰ／ＰＳＴＮゲートウェイを統合することができる。この手法の欠点は、ネットワーク内のＣＰでパフォーマンスのボトルネックが生じる可能性があることである。
【００９３】
以上の開示を考慮すれば、当分野の技術者には、本発明のくつかの変更形態が容易に明白となろう。したがって、本発明の範囲は、本開示に照らして読まれる頭記の特許請求項の範囲から解釈すべきものである。
【図面の簡単な説明】
【図１】ＵＭＴＳモデルに基づくワイヤレスパケット交換ネットワークを示す図である。
【図２ａ】モバイルトランシーバの本発明の一実施形態を示す図である。
【図２ｂ】モバイルトランシーバの本発明の一実施形態を示す図である。
【図３】通信チャネル全体を示す図である。
【図４ａ】代替の圧縮アルゴリズムを示す図である。
【図４ｂ】代替の圧縮アルゴリズムを示す図である。
【図５】圧縮状態の確立または再確立を示す図である。
【図６】圧縮ポイント間ハンドオーバを示す図である。

Claims

パケット交換ネットワークのためのヘッダを圧縮および圧縮解除する方法であって、
各圧縮ヘッダ内に、パケットペイロードのサンプリング時刻を表す周期的にリセットされるｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒを提供するステップと、
各サンプル持続時間ごとに１ずつｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒを増加させ、前記リセット周期をカウントして、リセット周期の前記カウントおよび受信したｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒから、圧縮解除されたヘッダを提供するために順序番号数およびタイムスタンプを提供するステップとを含む方法。
各圧縮ヘッダ内にＭビットを含めるステップと、
Ｍビットが全く受信されなかったとき、Ｍビットが受信されなかったパケットと以前に受信したＭビットを有する最後のパケットとの間のｔｉｍｅｃｌｉｃｋ＿ｎｕｍｂｅｒの差だけ、圧縮解除されたヘッダのパケット順序番号数を増加させることにより、前記ヘッダを圧縮解除するステップとをさらに含む請求項１に記載の方法。
音声サービスを提供するためにパケット交換無線ネットワークを動作させる方法であって、
コールシグナリングデータおよびその他のデータから音声データを分離するステップと、
請求項１または２に記載の方法に従ってヘッダを圧縮および圧縮解除するステップとを含み、それによって、音声データを含む各パケットは、圧縮されたＲＴＰ／ＵＤＰ／ＩＰヘッダを備えることができる方法。
ＶｏＩＰアプリケーションに対する音声パケットは、ＩＰ層を通過せず、直接にリンク層ペイロードとして送信される請求項３に記載の方法。