(57)【特許請求の範囲】
【請求項１】
データ・パケットをコンプレッサ（ＭＳ）からデコンプレッサ（ＳＧＳＮ）へ転送する方法であって、前記データ・パケットはヘッダ・データ・フィールドを有するヘッダを含み、データ転送中一定を維持する該ヘッダ・データ・フィールドのいくつかが該デコンプレッサ内に記憶され、
該データ伝送中に変化する１個以上のヘッダ・データ・フィールドに関する情報を含むデータ・パケットを該コンプレッサから伝送し、該デコンプレッサで受信し、
該記憶されたヘッダ・データ・フィールド、及び該データ転送中に変化する１個以上のヘッダ・データ・フィールドに関する受信された情報を用いて該ヘッダを復元する方法において、
圧縮シーケンスにおけるデータ・パケットを識別し、該ヘッダ・データ・フィールドの最下位ビットから第１の数のビットを取り出すことによって形成される該ヘッダ・データ・フィールドに対する圧縮値を該コンプレッサから伝送し該デコンプレッサで受信し、
受信された圧縮値を対応する圧縮シーケンスに関連付けるための情報であって、受信された圧縮値に応じて更新される情報を含むコンテキスト・データを該デコンプレッサ内に維持し、
該圧縮値を復元されたヘッダ・データ・フィールドにマッピングするために、該圧縮値と対応する圧縮シーケンスに関する情報を用いることを特徴とする方法。
【請求項２】
該圧縮シーケンスは、該圧縮値により与えられる分解能で互いから識別され得る連続するデータ・パケットの集合を含むことを特徴とする請求項１に記載の方法。
【請求項３】
該ヘッダはＲＴＰ／ＵＤＰ／ＩＰヘッダであり、該ヘッダ・データ・フィールドは、ＩＰ識別情報、ＲＴＰ一連番号、及びＲＴＰタイム・スタンプのうちの１つであることを特徴とする請求項１又は２に記載の方法。
【請求項４】
該コンテキスト・データは、少なくとも該データ・フィールドの最上位ビットから第２の数のビットを含むことを特徴とする請求項３に記載の方法。
【請求項５】
該コンプレッサ及び該デコンプレッサは、ＩＰパケット・データ・ネットワークに向うアクセス・ネットワークのネットワーク・エレメントであることを特徴とする請求項１に記載の方法。
【請求項６】
該コンプレッサ及び該デコンプレッサは、ＩＰパケット・データ・ネットワークに向う無線アクセス・ネットワークのネットワーク・エレメントであることを特徴とする請求項５に記載の方法。
【請求項７】
該コンプレッサと該デコンプレッサは、ＧＰＲＳをサポートする移動通信ネットワークのネットワーク・エレメントであることを特徴とする請求項６に記載の方法。
【請求項８】
圧縮及び解凍機能は、ＧＰＲＳのＳＮＤＣＰ層で実行されることを特徴とする請求項７に記載の方法。
【請求項９】
アクセス・ネットワーク・エレメント（ＭＳ）であって、
ヘッダ・データ・フィールドを有するヘッダを含むデータ・パケットをデコンプレッサ（ＳＧＳＮ）へ転送するための手段（１０１，１０３）と、
データ伝送中に一定を維持するヘッダ・データ・フィールドを伝送から除外することによって該ヘッダを圧縮するための手段（１０１，１０３）と、
データ伝送中に変化する１個以上のヘッダ・データ・フィールドに関する情報を含むデータ・パケットを該デコンプレッサへ送るための手段（１０１，１０３）を具備し、
圧縮シーケンス中のデータ・パケットの特定に関連し、該ヘッダ・データ・フィールドの最下位ビットから第１の数のビットを取り出すことによって形成される該ヘッダ・データ・フィールドに対する圧縮値を伝送するための手段（１０１，１０３）を具備することを特徴とするアクセス・ネットワーク・エレメント。
【請求項１０】
アクセス・ネットワーク・エレメント（ＭＳ）であって、
伝送されるパケット列におけるパケットの順序を示す序数を含むデータ・パケットを受信するための手段（１０１，１０３）と、
受信されたパケットの序数を以前に記憶された序数と比較するための手段（１０１，１０３）と、
受信されたパケットの序数と該比較用序数の差が予め定められた限界を越えることに対する応答として、エラー機能を開始する手段（１０１，１０３）と、
受信されたパケットの序数と該比較用序数の差が予め定められた限界より小さいことに対する応答として、ヘッダ圧縮アルゴリズムを開始する手段（１０１，１０３）と、
受信されたパケットの序数が該比較用序数より大きいことに対する応答として、その受信されたパケットの序数を該比較用序数として記憶する手段（１０１，１０３）を具備することを特徴とする請求項９に記載のアクセス・ネットワーク・エレメント。
【請求項１１】
ヘッダ・データ・フィールドを有するヘッダを含むデータ・パケットを受信する手段（１０１，１０３）と、
データ伝送中一定を維持するヘッダ・データ・フィールドを記憶する手段（１０１，１０２）と、
データ伝送中に変化する１個以上のヘッダ・データ・フィールドに関する情報を含む圧縮されているデータ・パケットを受信する手段（１０１，１０３）と、
記憶されているヘッダ・データ・フィールドと、データ伝送中に変化する１個以上のヘッダ・データ・フィールドに関する受信された情報を用いて、圧縮されているデータ・パケットを復元する手段（１０１）を含むアクセス・ネットワーク・エレメント（ＭＳ）であって、
データ・パケット内で、圧縮シーケンス中の該データ・パケットを識別し、該ヘッダ・データ・フィールドの最下位ビットから第１の数のビットである圧縮値を受信する手段（１０１，１０３）と、
受信された圧縮値を対応する圧縮シーケンスと関連付けるために受信された圧縮値に応じて更新される情報を含むコンテキスト・データを維持する手段（１０１，１０２）と、
圧縮値と対応する圧縮シーケンスについての情報を用いて、圧縮値を復元されているデータ・パケット中のヘッダ・データ・フィールドにマッピングする手段（１０１，１０２）を具備することを特徴とするアクセス・ネットワーク・エレメント。
【請求項１２】
該アクセス・ネットワーク・エレメントが、移動通信ネットワークの移動端末装置であることを特徴とする請求項９又は１１に記載のアクセス・ネットワーク・エレメント。
【請求項１３】
該アクセス・ネットワーク・エレメントは、ＧＰＲＳをサポートする移動通信ネットワークのＳＧＳＮであることを特徴とする請求項９又は１１に記載のアクセス・ネットワーク・エレメント。
【発明の詳細な説明】
【０００１】
本発明は、データ伝送に関し、特にヘッダ・データ・フィールドを有するヘッダを含むデータ・パケットをコンプレッサからデコンプレッサへ転送する方法であって、データ伝送中一定を維持するヘッダ・データ・フィールドのいくつかがデコンプレッサ中に記憶される方法に関する。この方法は、データ転送中に変化する１個以上のヘッダ・データ・フィールドに関する情報を含むデータ・パケットをコンプレッサから送信すると共にデコンプレッサで受信し、蓄積されているヘッダ・データ・フィールド及びデータ伝送中に変化する１個以上のヘッダ・データ・フィールドに関する受信された情報を用いてヘッダを解凍することを含む。本発明は、この発明された方法を実行するアクセス・ネットワーク・エレメントにも関する。
【０００２】
実時間サービスは、パケット交換ネットワークを介する音声、データ及びビデオの協力を可能にする技術の発展途上の組合せを構成する。パケット交換無線システムの標準化に従って、無線ネットワークをも経由する実時間サービスを設けることについての関心が増大している。実時間サービスでは、パケット伝送は数個のプロトコルを用いて実行される。これは大きなプロトコル・オーバーヘッドをもたらすと共に帯域幅の利用効率を悪くする原因となる。無線システムにおける伝送速度は限られているので、大きなヘッダを転送することは容量の浪費を意味する。
【０００３】
大きなヘッダの問題を克服するために、種々のヘッダ圧縮方式が導入されている。Ｓ．キャスナー及びＶ．ジャコブソンにより記された刊行物“低速シリアル・リンクのためのＩＰ／ＵＤＰ／ＲＴＰヘッダの圧縮”（Publication "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links" by S. Casner and V. Jacobson, Internet Engineering Task Force, INTERNET-DRAFT, draft-ietf-avt-crtp-05.txt, July 1998 )は、ヘッダのサイズを大幅に減少させることを可能にする効率的ヘッダ圧縮アルゴリズムを提示している。そこに提示されているヘッダ圧縮法は、ＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダ中のバイトの幾つかは接続期間中は一定を維持するという事実に基づいている。圧縮されていないヘッダを送信した後、それらのフィールドは、後続の圧縮されているヘッダから削除され得る。更に、そのサイズを低減するために変化するフィールドに対して差分符号法が使用される。ＲＴＰヘッダでは、パケット同士の差はほとんどの場合一定であり、従って二次差分はゼロである。コンプレッサとデコンプレッサの間で共有されるセッション状態における圧縮されていないヘッダと一次差分の両方を維持することにより、連続するパケット間の二次差分がゼロであることを示すことが主として必要である。コンプレッサ・インプリメンテーションが重複したセッション・コンテキストに対して状態を維持するかも知れないということも示唆されている。記憶されているセッション・コンテキストのテーブルに索引を付するために所定フィールドに対してハッシュ関数を使用し、圧縮されたパケットにセッション・コンテキスト識別子を含めることは、デコンプレッサが記憶されているセッション・コンテキストのテーブルに直接索引を付することを可能とするであろう。
【０００４】
実時間サービスは伝送遅延について厳しい制限を課すので、（例えば、ＩＰパケットの伝送に一般的に用いられる伝送制御プロトコルＴＣＰ中の）普通の再伝送手順は一般には使用できない。従って、実時間サービスにおけるリンクは、実際は単信方式リンクであると見なされるであろう。従来技術の参考文献では、単信方式リンクに対しては周期的リフレッシュ方式が提案されている。デコンプレッサがパケット・ストリーム中にエラーを検出する毎に、デコンプレッサはそのストリーム中の全てのパケットを破棄し、規則的に送信される圧縮されていないヘッダ（リフレッシュ・ヘッダ）が受信されるまでは解凍を再開しないであろう。これは、伝送エラー後は次のリフレッシュ・パケットまでの全てのパケットが失われるということを意味する。エラーが極くまれにしか生じない伝送リンクでは、これは伝送スループットに大きな影響を及ぼさない。いずれにしても、多数の伝送エラーが生じる危険が大きいリンクが含まれるときには、その効果は壊滅的である。無線伝送の場合は特にそうである。
【０００５】
ミカエルデガーマーク、マティアスエンガン、ブジョーンノージュレン及びステファンピンクにより記された刊行物“無線ネットワークのための低損失ＴＣＰ／ＩＰヘッダ圧縮”（Low-loss TCP/IP header compression for wireless networks" by Mikael Degermark, Mathias Engan, Bjorn Nordgren and Stephen Pink, Wireless Networks 3 (1997) 375-387, J. C. Balzer AG, Science Publishers）は、単信方式リンクと損失のあるリンクの問題が取り扱われているＵＤＰ／ＩＰ及びＴＣＰ／ＩＰプロトコルのためのヘッダ圧縮方法を提示している。その呈示されたシステムでは、コンプレッサは完全なヘッダと圧縮されたヘッダによっても搬送される小さい独自の数である圧縮識別子を伝送する。完全なヘッダはデコンプレッサにより圧縮状態として記憶される。圧縮されているヘッダ中の圧縮識別子は、解凍のために使用する適当な圧縮状態を調査するために使用される。矛盾した圧縮状態に起因する誤った解凍を避けるために、幾つかの別のメカニズムが導入される。圧縮状態の各バージョンは、圧縮状態をインストール又はリフレッシュするフル・ヘッダにより搬送され、それを使用して圧縮されるヘッダ内の番号によって表される世代と関連している。従ってデコンプレッサは、その世代を圧縮されているヘッダの世代と比較することにより、その圧縮状態が古くなった時を検出することができる。更に、完全なヘッダが失われたときにパケットを破棄する期間が長くなるのを避けると共に、なるべく高い圧縮率を得るために、コンプレッサは、完全なヘッダ同士間の短い間隔で動作を開始し、リフレッシュ間隔は定常状態リフレッシュ期間に達するまで（圧縮低速スタート）指数関数的に増大される。任意のヘッダ圧縮の適度なトレードオフも提案されている。
【０００６】
圧縮状態世代の使用は矛盾のある圧縮状態の検出を容易にするけれども、完全なヘッダが適切な圧縮状態をインストールするまでは、パケットはいずれにせよ失われる。圧縮低速スタートは、圧縮率と容認できる回復時間の適正なトレードオフを発見し易くするけれども、困難な伝送状態では、圧縮率はいずれにせよ妥協により定められ、ヘッダ圧縮の長所は減少する。
【０００７】
今、１つの方法及びこの方法を実行するネットワーク・エレメントが発明されて、それにより、これらの問題を回避し又はそれらの効果を減少させることができる。
【０００８】
本発明の第１の側面によれば、コンプレッサからデコンプレッサへデータ・パケットを転送する方法が提供され、データ・パケットはヘッダ・データ・フィールドを有するヘッダを包含し、データ転送中一定を維持するヘッダ・データ・フィールドのいくつかがデコンプレッサに記憶される。この方法は、データ転送中に変化する１つ以上のヘッダ・データ・フィールドについての情報を含むデータ・パケットをコンプレッサから伝送してデコンプレッサで受信し、記憶されているヘッダ・データ・フィールドと、データ転送中に変化する１つ以上のヘッダ・データ・フィールドに関する受信情報を用いてヘッダを解凍する。この方法は、ヘッダ・データ・フィールドに対する圧縮値をコンプレッサから伝送してデコンプレッサで受信し、圧縮値は圧縮シーケンスにおけるデータ・パケットを特定し、受信された圧縮値を対応する圧縮シーケンスに関連づけるための情報を含むコンテキスト・データをデコンプレッサ内に保持し、その情報は受信された圧縮値に応じて更新され、圧縮値を解凍されたヘッダ・データ・フィールドにマッピングするために、圧縮値と対応する圧縮シーケンスについての情報を使用することを特徴とする。
【０００９】
この発明の長所は、ネットワーク層パケット内の大部分のフィールドが、セッション全体を通じて一定のままであるという事実に基づく。このコンテキストにおいてネットワーク層とは、パケット・データ・ネットワーク・レベル・プロトコル層を指し、例えばＩＰ、ＵＤＰ及びＲＴＰプロトコルを指す。さらに、パケット毎に変化するフィールドにおける変化を予測できることが望ましい。その様なフィールドは、圧縮された形でデコンプレッサに送られる。予測された変化に関する先行知識に基づいて、デコンプレッサは、デコンプレッサで受信されたパケットからの情報で更新されるコンテキスト・データを生成して維持する。圧縮されたデータは、連続するデータ・パケットの集合、即ち圧縮シーケンスの中の解凍された値の変化に対して明瞭にマッピングする。コンテキスト・データにおいて、１つ以上の圧縮シーケンスについての情報が維持される。この情報は、受信された圧縮データを正しい圧縮シーケンスと関連づけるための手段を提供する。デコンプレッサに維持されている対応するコンテキスト・データと受信された圧縮データの使用は、セッション全体を通じてデコンプレッサ側の完全なパケット・データ・ヘッダ・フィールドに圧縮データが明瞭にマッピングされることを可能とする。デコンプレッサで維持されているコンテキスト・データのどの圧縮シーケンスとも正しく関連づけされ得ない情報を搬送するデータ・パケットは、コンプレッサ側で事前に取り除かれることが望ましい。
【００１０】
従来の解決策と比べると、本発明の方法による圧縮は、パケットの識別に関連する変化するフィールドも圧縮することができるので、増大される。なお、伝送誤りは個々のパケットの伝送のみに影響を及ぼし、１つのパケットの伝送における問題はその後のパケットには拡大しない。全ヘッダ情報のリフレッシュは、より長い間隔で行われるように設計することも可能であり、あるいは完全に停止することも可能である。
【００１１】
本発明の更なる側面が、独立請求項９，１３及び１５において提示されている。好ましい実施態様は従属請求項において提示されている。
【００１２】
本発明をよりよく理解し、どの様に実施するかを示すために、例として、添付図面が参照される。
【００１３】
ＩＴＵ−Ｔ音声符号器Ｇ．７２３．１、インターネット・プロトコル・バージョン４及びＥＴＳＩの一般パケット無線システム（ＧＰＲＳ）が使用される実施態様で本発明を説明するが、これらの各々は当業者に広く知られている。これらのシステムのすべてについて、良く似ている又は対応する手法が存在し、さらに発展しているということに注意するべきである。従って、保護の範囲は、次の記述に用いられるプロトコルの詳細には限定されない。ここで提示される方法は、固定ネットワークにも応用可能であるけれども、無線通信では問題はもっと目立つものであり、その様な構造がこの例で用いられる。
【００１４】
図１は、無線ＩＰ接続を介する１つの音声フレーム１０の伝送における異る層によるヘッダ・オーバーヘッドの累積を示す。斜線の付されたブロックはヘッダを表し、白いブロックはデータ・フレーム内のペイロードを表す。最初に、音声フレーム１０は実時間プロトコル（ＲＴＰ）パケット１１に封じ込まれ、ＲＴＰパケット１１はユーザ・データ・プロトコル（ＵＤＰ）パケット１２に挿入され、更にインターネット・プロトコル（ＩＰ）パケット１３に挿入される。ＩＰパケット１３は、更に、サブネットワーク・ディペンデント・コンバージェンス・プロトコル（ＳＮＤＣＰ）１４及びロジカル・リンク・コントロール・プロトコル（ＬＬＣ）を用いてＬＬＣブロック１５に封じ込まれ、ＬＬＣブロック１５は個別のヘッダを各々が含む適当な数のＲＬＣブロックに分割される。見ての通りに、累積したオーバーヘッドは非常に大きい。既にＩＰ層においてプロトコル・オーバーヘッドは４０バイトであり、Ｇ７２３．１符号器が使用されるときには帯域幅利用は約３３％である。無線リンクのプロトコル・ヘッダにより、一層多くのオーバーヘッドが生成されるので、事態はますます悪くなる。
【００１５】
この実施態様では、ヘッダの圧縮とヘッダの復元は、アクセス・ネットワークに特有のプロトコル層で、この場合にはＳＮＤＣＰ層で、実行される。図２は、ＧＰＲＳネットワークの機能エレメント及び関連するプロトコル構造の一部を示している。ＧＰＲＳは、２つのネットワーク・エレメント、即ちゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）とサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）により一般的ＧＳＭ構造に対して論理的に実現される。ＧＧＳＮは、ＧＰＲＳをサポートするＧＳＭネットワーク内の第１のパケット・データ・ネットワーク・アクセスポイントである。そのＰＤＰアドレス（例えばＩＰ又はＸ．２５であるパケット・データ・プロトコル）がＧＰＲＳ加入者を示すデータ・パケットは、ＧＧＳＮへルーティングされる。ＧＧＳＮは、データ・パケットを加入者の現在のアクセス・ノードＳＧＳＮへルーティングするために必要な情報を供給する。ＧＧＳＮは、ＧＳＭホーム・ロケーション・レジスタ（ＨＬＲ）から加入者の位置データを問い合わせてもよい。ＳＧＳＮは、移動局（ＭＳ）にサービスをするアクセス・ノードである。ＧＰＲＳ接続に対しては、データ・パケットをＧＧＳＮへルーティングするために、ＳＧＳＮはＭＳに向う移動性管理機能を確立するとともにパケット・データ・ネットワークに向うＰＤＰ機能を確立する。ＳＧＳＮ及びＧＧＳＮを同じ物理的ノードに統合することができ、それらを別々のノードに置くこともできる。
【００１６】
アクセス・ネットワークＳＮＤＣ機能は、いろいろな圧縮手法を通してＳＧＳＮ及びＭＳの間で最小量のデータを転送するサービスをネットワーク層に提供する。ＧＰＲＳは、セッションで使用されるべき圧縮アルゴリズムについてＭＳとＳＧＳＮが合意するために、サービス交渉と関連して実行される処理手順を供給する。発明された方法では、一定を維持すると仮定されるヘッダ部分は、ＳＮＤＣＰエンティティに記憶される。次に、ネットワーク層プロトコル・ヘッダの構造と内容とについてより詳しく検討する。
【００１７】
図３には、ネットワーク層ＲＴＰ、ＵＤＰ及びＩＰヘッダのフィールドが示されている。ＲＴＰを考察すると、フィールド３１０は、使用されるＲＴＰバージョンを示し、セッションの間変化しない。フィールド３１１は、パディング・ビットを含み、例えばアプリケーション層で暗号化アルゴリズムの目的のために、ヘッダの終わりに追加のパディングが含められない限りは変化しない。フィールド３１２は、固定されているヘッダの後にヘッダ拡張が続くか否かを示し、セッションの間変化しない。フィールド３１３は、例えば何人のユーザがペイロードに寄与しているのかを示す多重化の目的のために必要なＣＳＲＣカウントに対応する。多くの場合に、この値はセッション全体にわたって一定のままである。フィールド３１５は、ペイロードの種類を示し、１種類のデータについては一定である。一般に、寄与するソース及び同期化ソースは、エアー・インターフェースを介する伝送の全体にわたって一定であるので、フィールド３１８は一定のままである。
【００１８】
フィールド３１４は、例えば音声バーストの始まりやビデオ・フレームの中の最後のパケットなど、パケット・ストリーム中の重要な事象を指示するために随意的に使用されるマーカー・ビットを含んでいる。マーカー・ビット３１４が使用されるのであれば、それは圧縮されたヘッダで伝送されなければならない。一連番号を示すフィールド３１６と、タイム・スタンプを示すフィールド３１７とは、全てのＲＴＰパケットに対して変化するであろう。
【００１９】
ＵＤＰを考察すると、ソース・ポート番号を示すフィールド３２１と、宛先ポート番号を示すフィールド３２２は、同じアプリケーションに関連する異なるデータ・ストリームを分離するために使用される。例えば、ＲＴＰ層のデータ及び制御情報を異なるポートに向けることができる、即ち異なるペイロード種類は異なるＵＤＰポート対を使用することができる。これらのフィールドは、同じ種類のデータが伝送され続けている限りは、一定のままである。ＵＤＰパケットの長さを示すフィールド３２３は、その中のＲＴＰパケットの長さが一定のままである限りは、一定のままである。ＵＤＰの長さがセッション（例えばビデオの伝送）全体にわたって可変である場合には、パケットの長さは圧縮されたヘッダ内で伝送されなければならない。フィールド３２４は、ＵＤＰチェックサムに対応し、伝送のエラーを検出するために使用される。このフィールドは、強力なエラー保護メカニズム又は伝送エラーを検出するための手段（例えば比較的に低いプロトコル層のチェックサム）を有する伝送リンクでは伝送される必要はない。この実施態様では、ＳＮＤＣＰ解凍機能は、例えば、解凍されたフィールドからチェックサムを計算し、その計算されたチェックサムを解凍されたパケットに使用することができる。
【００２０】
ＩＰを考察すると、ＩＰバージョンを示すフィールド３３１、ヘッダ長さを示すフィールド３３２、サービスの種類を示すフィールド３３３、及びパケットの全長を示すフィールド３３４は、少なくとも一定のビットレートで符号化されている音声フレームが伝送されている限りは、一定のままであると仮定される。フラグを示すフィールド３３６は、断片化が使用されない限りは、一定のままであると仮定され得る。１３ビット断片オフセットを含むフィールド３３７は、プロトコルを示すフィールド３３９と共に一定のままであると仮定される。生存時間を示すフィールド３３８と、チェックサムを示す３４０はＳＮＤＣＰ機能により定義され得る。データ伝送中、ＩＰソース及び宛先は一定のままであるので、ソースＩＰアドレス及び宛先ＩＰアドレスをそれぞれ示すフィールド３４１及び３４２は一定のままであると仮定される。識別フィールド３３５は、主としてＩＰパケット断片化のために使用される。もし断片化が使用されなければ、このフィールドを送る必要はない。断片化が使用されるのであれば、ＳＮＤＣＰは、始めに、パケットを圧縮する前にまずパケットを再構築するべきである。
【００２１】
時間の殆どにわたって一定を維持すると仮定されるフィールドは、無変化フィールドの集合にグループ化される。この実施態様、及び定ビットレート符号器からの音声フレームとの関連において、その集合はフィールド３１０、３１１、３１２、３１３、３１５、３１８、３２１、３２２、３３１、３３２、３３３、３３４、３３６、３３７、３３８、３３９、３４１、３４２、及び３４３を含む。これらのフィールドは、少なくともリンクの受信（復元）側端部で維持される圧縮状態を構成する。
【００２２】
前述したように、無変化フィールドの他に、その内容が受信された情報から推測され得るフィールドの第２の集合は、圧縮されているヘッダから省略され得る。その様なフィールドは、圧縮の状態に如何なる影響も及ぼさない。提示されている実施態様では、その様なフィールドはパケットの有効性を検査するために使用されるチェックサムを含んでいるフィールド３２４及び３４０である。これらのサムは、デコンプレッサにおいて復元されたデータ・フィールドから計算され得る。例えばアクセス・ネットワーク・レベルのデータ・ユニットなどの比較的に低レベルのチェックサムを用いて、パケットの有効性は確かめられ得る。
【００２３】
各パケットについて変化するフィールドを管理するための本発明の方法の解決策が図４に一般的な形で示されているが、この実施態様ではＳＧＳＮ（デコンプレッサも）受信側エンティティの機能も示されている。セッション・セットアップと関連して圧縮状態のために必要とされる情報は、デコンプレッサ（例えばフル・ヘッダ）で受信される。正しい圧縮状態が使用されることを保証するために、セッション・セットアップ・シグナリングに受け取り通知処理手順を含めることができる。ステップ４０では、圧縮状態ＳｏＣがデコンプレッサに記憶される。ステップ４１では、各々が一定の圧縮シーケンスに関連する１つ以上のコンテキスト値Ｃｊを含むセッション・コンテキストがデコンプレッサにおいて開始される。パケットが送信側エンティティ、この場合にはＭＳ（コンプレッサも）から受信される（ステップ４２）。パケットは、被圧縮データ・フィールドＤｃｏｍを含む。２つ以上のコンテキスト値が維持される場合（ｊについての最大値＞１）には、受信されたＤｃｏｍを対応するコンテキスト値Ｃｊに関連付けするための決定規則Ｄｍの集合が定義される。受信されたＤｃｏｍと整合するＤｍが決定され（ステップ４３）、復元値Ｄｆｕｌｌが、受信されたＩＤｃｏｍの値と、決定されたＤｍのコンテキスト値Ｃｍとから得られる（ステップ４４）。予測されたフィールドの進展に従って、コンテキスト・データを維持するためにゼロ、１、あるいはより多くのコンテキスト値が更新される（ステップ４５）。データ転送セッション全体にわたって、新しいパケットについてこの処理手順が続けられる。
【００２４】
この実施態様で伝送されるべき変化するフィールドは、ＲＴＰ一連番号を示すフィールド３１６、ＲＴＰタイム・スタンプを示すフィールド３１７、及びＩＰ識別情報を示すフィールド３３５である。これらのフィールドの増分が一般にはセッション全体にわたって一定にとどまるという事実を考慮すると、従来技術の（前に伝送されたパケットを参照する）デルタ符号化方式が示唆される。いずれにしても、前述した問題を避けるために、圧縮を必要とする各ネットワーク層のパケットのために独立の識別情報が提供される。
【００２５】
第１の実施態様では、ヘッダ・フィールドは短縮フィールドに圧縮され、リンクを介して伝送される。短縮フィールドの長さは、一般にセッションより短い間隔で圧縮シーケンス中にパケットの正しい識別を容易にする情報の伝送を提供するように選択される。その短縮フィールドにより提供される、デコンプレッサで維持される長期間のコンテキストと結合された短期間識別情報は、データ伝送セッションの全体にわたってパケットの首尾一貫した識別を提供し、従ってデータ伝送セッションの全体にわたって被圧縮ヘッダ・フィールドのフル・ヘッダ・フィールドへの明白なマッピングを可能にする。
【００２６】
この様な構成の例として、短縮タイム・スタンプの場合が提示される。図５は、この実施態様で使われる圧縮されたヘッダのためのフォーマットを表している。フィールド５１は、圧縮されているパケットの種類Ｔを示している。もしＴ＝０ならば、最後のオクテット５６は含まれておらず、第１オクテットの最後の６ビット５３は例えばＣＲＣチェックなどの他の目的に使用され、又は短縮タイム・スタンプのために使われるゼロにセットされる。もしＴ＝１ならば、圧縮されているヘッダは長さオクテットを含んでいなければならず、ビット５３と最後のオクテット５６はＲＴＰペイロードの長さを示すために使われる。この長さ情報は、例えばビデオのビット・ストリームなど、パケットの長さが変化するかもしれないビット・ストリームに必要とされる。フィールド５２は、前に説明したようにＲＴＰヘッダのマーカー・ビットを示す。この実施態様における短縮タイム・スタンプは、ＲＴＰタイム・スタンプの下位１６ビットを示す１６ビットのフィールドである。コンテキスト・データはＲＴＰタイム・スタンプの上位１６ビットを含んでおり、少なくともリンクのデコンプレッサ端部で維持される。
【００２７】
図６のフローチャートは、短縮タイム・スタンプが使用される発明された方法の実施態様のステップを示している。ステップ６１において、この場合にはセッションの始まりにおいて受信されるフル・タイム・スタンプＴＳｆｕｌｌ内で、圧縮状態が受信される。セッションの始まりにおいてコンテキスト・データが初期化されるが、この場合にはＴＳｍｅｍ１は、元のタイム・スタンプの下位１６ビットを含み、ＴＳｍｅｍ２は元のタイム・スタンプの上位１６ビットを含む（ステップ６２）。ステップ６３では、新しい圧縮ネットワーク層データ・パケットのタイム・スタンプの下位１６ビットを運ぶ新しい短縮タイム・スタンプＴＳａｂｂが受信される。その新しい短縮タイム・スタンプはデコンプレッサにおいて蓄積されている値ＴＳｍｅｍ１と比較される。後に見られるように、ＴＳｍｅｍ１の値は、それまでに受信された最大のタイム・スタンプの下位１６ビットを含むであろう。
【００２８】
もし新しい短縮タイム・スタンプＴＳａｂｂが蓄積されている値ＴＳｍｅｍ１より大きければ、さらにその新しい短縮タイム・スタンプＴＳａｂｂが蓄積されている値ＴＳｍｅｍ１と予め定義された値Δの合計より大きいか否かが調べられる。この値Δは、無音、パケットの喪失、又は少し間違った順序で到着したパケットなどの、予期される何らかの事象に起因すると解され得る最下位ビットの最大の変化を表す。タイム・スタンプの下位１６ビットにより表される数がその最大値に達したとき、それはリセットして最小値（圧縮シーケンス）から再び出発する。パケットが遅れてコンプレッサに来るときには、記憶されている値ＴＳｍｅｍ１が既にリセットから再出発しており、受信された短縮タイム・スタンプＴＳａｂｂの値がＴＳｍｅｍ１よりかなり大きいということがあり得る。Δのために適切な値を定めることにより、その様な場合が、受信されたパケットのストリーム中で検出され得る。もし受信された短縮タイム・スタンプＴＳａｂｂが、ＴＳｍｅｍ１より大きいけれども差があまり大きくなければ（小さなΔ）、値ＴＳｍｅｍ２に記憶されている上位１６ビットを用いて、コンプレッサから受信される下位１６ビットに結合させることによってタイム・スタンプが復元され得る（ステップ６４）。受信された短縮タイム・スタンプＴＳａｂｂは、それまでに受信された最大の短縮タイム・スタンプであるので、ＴＳｍｅｍ１として記憶される。もし受信された短縮タイム・スタンプＴＳａｂｂがＴＳｍｅｍ１より大きく、差がΔより大きければ、ＴＳａｂｂが遅れて到着し、ＴＳｍｅｍ１が既にリセットから再出発していると仮定される。それらの場合のために、以前の圧縮シーケンスに関連する別の文脈データ値ＴＳｍｅｍ３が、コンテキスト・データにおいて維持される。ＴＳｍｅｍ３は、ＴＳｍｅｍ２の以前に記憶された値を含んでいる。タイム・スタンプの復元は、値ＴＳｍｅｍ３に記憶されている上位１６ビットを用い、コンプレッサから受信される下位１６ビットと結合させることによって行われる。ＴＳｍｅｍ１，ＴＳｍｅｍ２、ＴＳｍｅｍ３の値の更新は行われない。
【００２９】
もし受信された短縮タイム・スタンプＴＳａｂｂがＴＳｍｅｍ１より小さければ、差がΔより大きいか否か調べられる。このΔより大きい場合が、タイム・スタンプの下位１６ビットを含む短縮タイム・スタンプが最大値に達し、リセットから再出発していて、記憶されている値ＴＳｍｅｍ２は次の可能な値にインクリメントされなければならない場合である（ステップ６７）。その後、タイム・スタンプが復元されることが可能であり、ステップ６４及び６５で説明したように記憶されている値ＴＳｍｅｍ１が更新され得る。例えば、記憶されているタイム・スタンプ値がＴＳｍｅｍ１＝ＦＦ ＦＦ（１６進数）、ＴＳｍｅｍ２＝０２ ＦＦ（１６進数）、Δ＝０ＦＦＦ（１６進数）であり、受信された短縮タイム・スタンプ値がＴＳａｂｂ＝００  ０Ａ（１６進数）である場合を考察しよう。今、短縮タイム・スタンプ値００  ０Ａは蓄積されているタイム・スタンプ値ＦＦ  ＦＦ小さく、差はΔより大きいので、ＴＳｍｅｍ２の上位１６ビット０２  ＦＦを１だけ更新して０３  ００にしなければならない。その結果としてのタイム・スタンプ値は０３  ００  ００  ０Ａとなる。もし差がΔより小さければ、それは、そのパケットが現在のシーケンスに属するけれども遅れて到着したということを意味する。その様な場合、値ＴＳｍｅｍ２に蓄積されている上位１６ビットを用い、これをコンプレッサから受信された短縮タイム・スタンプＴＳａｂｂに結合することによってタイム・スタンプが復元され得る。これは、それまでに受信された最大の短縮タイム・スタンプではないので、値ＴＳｍｅｍ１は更新されない。もっと多くの新しいパケットが到着する間は、この処理手順が続けられる。
【００３０】
同じ着想を他のフィールドにも応用することができる。例えば、ＲＴＰヘッダの完全な一連番号を考察しよう。もし元の一連番号が（２進法の形式で）０００１００００，０００１０００１，０００１００１０であるならば、デコンプレッサに送られる短縮一連番号は００００，０００１，００１０である。デコンプレッサにおいては、少なくとも現在の最上位ビットを含むコンテキスト・データが維持される。同様の種類の決定規則で、デコンプレッサにおいて圧縮されているデータが圧縮シーケンスと関連付けされ、フル・ヘッダ・フィールドにマッピングされ得る。
【００３１】
圧縮されているデータとデコンプレッサで使用されるインクリメントの間の他の種類の関係も同じく存在し得る。例えば、タイム・スタンプが各パケットについて２４０だけ変化し得ることが知られているときには、コンプレッサにおける１のインクリメントはデコンプレッサの２４０のインクリメントにマッピングされ得る。この場合には、（圧縮値→復元されたタイム・スタンプ）、０００１→２４０  ００１０→４８０  ００１１→７２０  ０１００→９６０などとなる。
【００３２】
図示されているように、コンテキスト・データは、受信された短縮フィールドの情報に応じて更新される。短縮の程度、即ち短縮されたフィールドを表すために使われるビットの量は、デコンプレッサにおいてコンテキスト情報が更新される速度に影響を及ぼす。例えば、圧縮シーケンスが短いほど、タイム・スタンプの最上位ビットを蓄積しているタイム・スタンプ値ＴＳｍｅｍ２は頻繁に更新されなければならない。たとえ何らかのパケットが失われたり、又はその順序が僅かに変化したとしても、前に示した有効性についての比較は、データが正しく復元され得ることに注意する。無線接続では、パケットの長いシーケンスの喪失は、一般的には進行中の呼びの脱落につながる。従って、接続が維持され得る間は、デコンプレッサにおいて首尾一貫した文脈情報を、程良い圧縮程度で維持することも可能である。例えば、６ビットでは、６４個のパケットを区別することが可能である。連続するパケットが６４個失われ、なお接続が維持されるということはありそうもないので、発明された方法は、接続が維持され得る限りは、良好に作用するであろう。
【００３３】
例えば非常に遅れてコンプレッサに到達したために圧縮情報を更新する順序を混乱させる可能性のあるパケットなどの、圧縮を混乱させるかも知れないパケットについては、コンプレッサに別の機能を設けるのが好ましい。圧縮情報にエラーを生じさせる危険を主張するために短縮されるべきフィールドが検出される遅れたパケットの受信は、コンプレッサ側での事前の訂正動作をもたらす。例えば、その様なパケットは完全に破棄されるかも知れない。例えば、遅れて到着したけれども前の圧縮シーケンスに属するパケットは、図６で説明したように、コンテキスト値ＴＳｍｅｍ３の使用から再生され得る。先行圧縮シーケンスに先行する圧縮シーケンスに属するパケットは、最早正しくは再生されないであろうから、その様なパケットは事前にコンプレッサにおいて優先的に処理されることが望ましい。図７のフローチャートは、非常に遅れているパケットを伴う事態を処理するためにコンプレッサ側において発明された方法に付け加えられ得るフィルタリング・アルゴリズムの例を示している。
【００３４】
ステップ７１において、第１の受信されたパケットのタイム・スタンプ全体が記憶される。新しいパケットが受信される（ステップ７２）と、そのタイム・スタンプＴＳｎｅｗが読み込まれ（ステップ７３）、蓄積されているタイム・スタンプＴＳと新しいタイム・スタンプＴＳｎｅｗとの差Ｄが計算される（ステップ７４）。もし差Ｄがある予め定められた値Ｄｍａｘより大きければ、コンプレッサは、そのパケットが非常に遅れていると見なし、訂正動作を開始する（ステップ７５）。その様な動作は、例えば、短縮されているフィールドの代わりにフィールド全体を送り、デコンプレッサに対するコンテキスト・データの更新をしないとの指示を含むものである。この様な動作は、又この様に遅れたパケットを単に破棄するのでも良い。非常に遅れて到着するパケットはいずれにせよアプリケーションのためには役に立たないので、それらを事前にコンプレッサ側で破棄することができるので、これは実時間データ・パケットに関しては自然な動作である。差ＤがＤｍａｘより大きくなければ、発明された方法に従ってタイム・スタンプＴＳが圧縮される。もしその差がゼロより大きければ、それはこのパケットが少し遅れて到着したことを意味する。好ましくは、記憶されている値ＴＳは、それまでに伝送されたタイム・スタンプの最大値を表すので、記憶されているタイム・スタンプの値は更新されないことが好ましい。差Ｄがゼロより小さければ、記憶されているタイム・スタンプの値は更新される（ステップ７７）。この処理手順はセッションの全体にわたって各パケットについて続けられる。
【００３５】
ある場合には、圧縮されたヘッダにおいて識別データが最小限度までに圧縮され得るが、圧縮シーケンスは依然としてセッション全体に及ぶ。その様な実施態様は、ネットワーク層のフィールドとアクセス・ネットワーク層プロトコルの間のマッピングを含んでいる。この文においてネットワーク層は、ここに示されている実施態様におけるＩＰ、ＵＤＰ及びＲＴＰプロトコルを参照するパケットデータ・ネットワーク・レベル・プロトコル層を指す。この文においてアクセス・ネットワーク層は、アクセス・ネットワークに固有のプロトコル層を指し、圧縮及び解凍機能を行うものであり、この場合にはＳＮＤＣＰである。ＳＮＤＣＰのパケット・データ・ユニット（ＰＤＵ）は、整数個のオクテット、ヘッダ部分、及びデータ部分を含んでいる。２つの異なるＳＮ−ＰＤＵフォーマット、受け取り通知が出されたデータ転送についてのＳＮ−ＤＡＴＡ  ＰＤＵ、及び受け取り通知が出されないデータ転送についてのＳＮ−ＵＮＩＴＤＡＴＡ  ＰＤＵが定義されている。図８は、ＧＰＲＳの受け取り通知が出されない伝送に用いられるＳＮＤＣＰ  ＳＮ−ＵＮＩＴＤＡＴＡ  ＰＤＵのフォーマットを図解している。ＳＮ−ＵＮＩＴＤＡＴＡ  ＰＤＵは、セッション全体にわたって進行する通過番号であるフィールドＮ−ＰＤＵ番号８１を含んでいる。
【００３６】
ネットワーク層データ・パケットと圧縮を行うプロトコル層のデータ・パケットの間のマッピングが生成され得る。本書における実施態様では、ＳＮＤＣＰ  ＳＮ−ＵＮＩＴＤＡＴＡ  ＰＤＵフィールドのＮ−ＰＤＵ番号とＲＴＰ一連番号、ＩＰ識別子及びＲＴＰタイム・スタンプが示されている。Ｎ−ＰＤＵ番号が１だけ大きくなるとき、ＲＴＰ一連番号フィールド３１６及びＩＰ識別子フィールド３３５の値は一般にセッション全体を通じて一定である値だけ大きくなる。更に、その後のＲＴＰタイム・スタンプ間の差は一定であるコーデックが存在する。１６進法の表示を用いた時に、この差がＦ０であり、ＲＴＰ一連番号に対する増分が１であり、ＩＰ識別子が０１００である場合については、次のマッピングが有効である。
Ｎ−ＰＤＵ番号＝５
ＲＴＰ一連番号＝１６Ｃ５
ＲＴＰタイム・スタンプ＝０２ＦＦＢＦＥＦ
ＩＰ識別子＝Ｅ７Ｅ６
Ｎ−ＰＤＵ番号＝６
ＲＴＰ一連番号＝１６Ｃ６
ＲＴＰタイム・スタンプ＝０２ＦＦＣ０ＤＦ
ＩＰ識別子＝Ｅ８Ｅ６
Ｎ−ＰＤＵ番号＝７
ＲＴＰ一連番号＝１６Ｃ７
ＲＴＰタイム・スタンプ＝０２ＦＦＣ１ＤＦ
ＩＰ識別子＝Ｅ９Ｅ６
【００３７】
本書では一定の増分が利用されているけれども、マッピングは他の幾つかの方法によっても実現され得る。例えば、アクセス・ネットワーク層プロトコルとネットワーク層プロトコル・ヘッダ・フィールドの間のマッピング機能が確立され得る。更に、アプリケーションにより、アクセス・ネットワーク層プロトコル及びネットワーク層プロトコルの外のいずれのフィールド間のマッピングも利用され得る。デコンプレッサのコンテキスト・データは、アクセス・ネットワーク層プロトコル・フィールドをネットワーク層プロトコル・フィールドにマッピングするために必要な情報を含んでいる。図４において提示されている方法の比較ステップは、アクセス・ネットワーク層フィールドの内容の単純な有効性検査を含む。文脈データは優先的に一定のままであり、従って更新を要しない（ステップ４５を参照）。
【００３８】
セッションが存在している間に無変化フィールドが変化する可能性のあるネットワーク層パケットについては、図９に示されている代わりの実施態様が提案される。この実施態様も、送信側エンティティがＭＳで、受信側エンティティがＳＧＳＮである例を用いて提示される。セッションのセットアップと関連して、圧縮の状態がＭＳ（ＳｏＣｃ）及びＳＧＳＮ（ステップ９１）（ＳｏＣｄ）の両方に記憶される。ＳＧＳＮへ転送されるべきパケットが音声コーデックから受信された（ステップ９）とき、圧縮されるべきヘッダの無変化フィールドと圧縮の状態のフィールドに変化があるかが調べられる（ステップ９３）。変化がないことが検出されたならば、前述したようにヘッダは圧縮され（ステップ９４）、圧縮されているパケットがデコンプレッサに伝送される（ステップ９５）。いずれにせよ、変化が検出されたときには、新しいＳＮＤＣＰ機能が新しいヘッダから変化している無変化フィールドのみを抽出し（ステップ９６）、それらを記憶されている圧縮の状態に更新し（ステップ９７）、前記値をＳＧＳＮへ伝送し（ステップ９８）、前記値をＳＧＳＮに記憶されている圧縮の状態に更新する（ステップ９８）。受け取り通知モード又は強力エラー保護を用いてその様な情報の伝送が実行され得る。
【００３９】
圧縮／解凍アルゴリズムでは、これらの実施態様のどの様な組み合わせも使用され得る。発明された方法の使用例を次に提示する。表１は、ネットワーク層プロトコルＩＰ、ＵＤＰ、ＩＰに対応するフル・ヘッダのフィールドを表している。影の付いているフィールドはセッション全体にわたって一定のままでいるフィールドに対応し、白いフィールドはセッション中に変化することのあるフィールドを表している。
【表１】
0003751823.tif 000002
【００４０】
これがＳＮＤＣＰコンプレッサで受信された第１のＲＴＰ／ＩＰ／ＵＤＰヘッダであると仮定する。ここに示されている値は１６進法のフォーマットであり、１つの行には４個のオクテットがある。始めの５行（２０オクテット）はＩＰヘッダを表す。次の２つの行はＵＤＰヘッダのオクテットであり、最後の３行はＲＴＰヘッダを表しており、全体で典型的なＲＴＰ／ＵＤＰ／ＩＰヘッダを形成している（４０バイト）。ＳＮＤＣＰコンプレッサはこれらの値をコピーしなければならず、フル・ヘッダは対応するＳＮＤＣＰエレメントに送られる。
【００４１】
表２は、コンプレッサが受け取る次のヘッダを提示している。
【表２】
0003751823.tif 000003
【００４２】
記憶されている値とは異なるフィールドには表１及び表２において斜線が付けられており、下記のものを含む。
・  ＩＰヘッダの１６ビット識別情報フィールド
Ｅ７Ｅ６からＥ８Ｅ６まで
・  ＩＰヘッダの１６ビットのヘッダ・チェックサム
６３ＤＣから６２ＤＣまで
・  １６ビットのＵＤＰチェックサム
ＡＦ５ＥからＤ４４０まで
・  ＲＴＰヘッダの一連番号
１６Ｃ５から１６Ｃ６まで
・  ＲＴＰヘッダのタイム・スタンプ
０２ＦＦＢＦＥＦから０２ＦＦＣ０ＤＦ
【００４３】
他のフィールドは同じままである。今、本発明に従って、次の圧縮されているヘッダが作られる。
【表３】
0003751823.tif 000004
【００４４】
この圧縮されているヘッダのフォーマットは、図５に関連して提示されたものに従い、２進数形式で表わされている。パケットの長さは変わっていないので、第１オクテットの７番目のビットは０であり、マーカー・ビットは０であり、この場合には第１オクテットの残りのビットはゼロである。次の２つのオクテットは短縮タイム・スタンプ（１６進法でＣ０  ＤＦ）を含んでいる。圧縮されているヘッダとＲＴＰペイロードとを含むＳＮＤＣＰパケットはデコンプレッサに送られる。
【００４５】
図６に関して前述したように、フル・タイム・スタンプは短縮されているタイム・スタンプ値から再現される。最後のフル・ヘッダからのオフセットとしてＳＮＤＣＰパケットのＮ−ＰＤＵ番号を用いてＲＴＰヘッダの一連番号とＩＰヘッダの１６ビット識別番号が導出されなければならない。デコンプレッサがフル・ヘッダを含む第１パケットを受け取ったとき、アルゴリズムはＲＴＰ一連番号とＳＮＤＣＰパケットのＮ−ＰＤＵ番号の間を関連づける。この場合には一連番号は１６Ｃ５であり、Ｎ−ＰＤＵ番号は、例えばｘである。圧縮されているヘッダが伝送されるとき、ＳＮ−ＵＮＩＴＤＡＴＡ  Ｎ−ＰＤＵ番号は、Ｎ−ＰＤＵ同士の差がｙ−ｘであり、その番号が記憶されている一連番号に加えられなければならないことを意味するｙである。
【００４６】
ここに記載した方法を実現するネットワーク・エレメントの例として、移動通信システムの移動端末装置がある。本発明に従う移動端末装置の構造は、当業者に以前から知られていた在来の移動端末装置のそれである。図１０を参照すると、中央処理ユニット１０１は、移動局の種々の機能を実行するブロック、即ちメモリ（ＭＥＭ）１０２、無線周波数ブロック（ＲＦ）１０３、ユーザ・インターフェース（ＵＩ）１０４及びインターフェース・ユニット（ＩＵ）１０５を制御する。ＣＰＵは、通常は１つ以上の機能的に相互作用するマイクロプロセッサで実現される。メモリは、ＲＯＭ（読み出し専用メモリ）、ＲＡＭ（ランダム・アクセス・メモリ）を含むことが好ましく、一般的にはＳＩＭユーザ識別モジュールで供給されるメモリで補われる。そのプログラムに従って、マイクロプロセッサは、無線でメッセージを送受信するためにＲＦブロック１０３を使用する。ユーザとの通信は通常はスピーカ、ディスプレイ及びキーボードを含むＵＩ１０４により取り扱われる。インターフェース・ユニット１０５はデータ処理エンティティへのリンクであり、ＣＰＵ１０１によって制御される。データ処理エンティティ１０１は、集積データ・プロセッサ又は外付けデータ処理装置であって良い。
【００４７】
図１０は、本発明に従うデータ処理エンティティＴＥの機能モジュールも図示している。端末装置ＴＥは、例えば以前からオフィス環境から知られているパーソナルコンピュータ、又はワークステーションであって良い。ＴＥは、ＵＩ及びＣＰＵなどのエレメントをＭＳと共有するＭＳ（例えばスマートホーン）の必須部分であっても良い。逆に、ＭＳがＴＥに統合されても良い（例えばカードホーン）。図１０には２つの別々のブロックが示されているけれども、そこに構成の限定は示唆されていない。
【００４８】
ＴＥは、実質的に、ＭＳへのインターフェースを制御するためにＭＳのインターフェイスに対応するインターフェース・ユニットＩＵ１０７を含んでいる。それは、ユーザのコマンドを受け取ると共に情報をユーザに出力するユーザ・インターフェースＵＩ１０８、アプリケーションＳＷＡＰＰ１１０、及びアプリケーション関連データを蓄積するメモリーＭＥＭ１０９、ならびにＴＥの動作を制御すると共にアプリケーション処理手順を実行するプロセッサＣＰＵ１１１を含んでいる。
【００４９】
移動局ＭＳとデータ処理エンティティを接続する方法は幾つかあり、全て当業者に知られている。その方法のうちの１つは、有線接続、即ち例えばシリアル・ポートである適当な相互接続インターフェイスを具備するインターフェイス・ユニットＩＵを介して装置を相互接続することであり、インターフェイス・ユニットＩＵの動作を制御するＣＰＵ内の適当なインターフェイス・ソフトウェアで補充される。もう１つの方法は、赤外線波長範囲の無線接続を使用すること、又は低電力無線周波数送受信装置を使用することである。ＭＳをＴＥに統合する新しい解決策は、非常に適したプラットフォームを本発明のシステムに提供する。
【００５０】
ユーザがＴＥでパケット・データ・ネットワークにアクセスすることを望むとき、ユーザ入力装置からのコマンドに基づいてプロセッサＣＰＵ１１１はメモリＭＥＭ１０９からパケット・データ・アクセス・アプリケーションＳＷ  ＡＰＰ１１０を検索する。そのアプリケーションはＣＰＵ１１１においてパケットの形で処理され、アプリケーション関連情報を送る必要が生じる度にパケットがＩＵ１０７を通してＭＳに転送される。
【００５１】
第１の実施態様では、圧縮機能及び復元機能は、移動端末装置のプロトコル・スタックのＳＮＤＣＰ層において実現される。ここで示されている実施態様では、ＳＮＤＣＰ機能と関連付けられるエレメントは、ＭＳ部分で説明したものである。アップリンク方向ではＭＳはコンプレッサとして動作し、ダウンリンク方向ではＭＳはデコンプレッサとして動作する。圧縮動作及び復元動作に用いられる値はＭＳのメモリ１０２に記憶されている。圧縮は中央ユニット１１１で実行され、圧縮されたユニットは、ＢＳを通してＳＧＳＮへ伝送するためにＲＦユニット１０２へ転送される。ＳＧＳＮから出力される圧縮されたパケットは、ＲＦユニットにより受信され、復元のためにＣＰＵ１１１へ転送される。復元されたパケットは、インターフェース・ユニット１０５及び１０７を通してＴＥへ転送される。
【００５２】
好ましい実施態様に関して本発明は開示され説明されたけれども、当業者は、以下で請求される発明の範囲から逸脱することなく、好ましい実施例に対する修正がなされてもよいことを認めるであろう。例えば、将来、ＧＰＲＳ又は対応するサービス（ＧＰＲＳ派生物）は他の移動通信システムにも実施されるであろう。第３世代ＷＣＤＭＡ（Wideband Code Division Multiple Access（広帯域符号分割多元接続））規格は、ＧＰＲＳに近い構造を有し、ＧＰＲＳのＳＮＤＣＰに対応するＬ３ＣＥ層を含んでいる。発明された機能を組み込むためのその様な層はＣＤＭＡ２０００のＳＮＤＣＦ層である。本発明を固定ネットワークにも応用することが可能である。従って、本発明を実施し使用するための可能性は、含まれる請求項のみにより限定される。
【図面の簡単な説明】
【図１】  無線ＩＰ接続を介する１つの音声フレーム１０の伝送における種々の層によるヘッダ・オーバーヘッドの蓄積を示す。
【図２】  ＧＰＲＳネットワークの機能エレメントのうちの幾つかと、関連するプロトコル構造を示す。
【図３】  ネットワーク層ＲＴＰ、ＵＤＰ及びＩＰヘッダのフィールドを示す。
【図４】  本発明の受信側エンティティにおける機能を示す。
【図５】  本発明の実施態様において使用される圧縮されたヘッダのためのフォーマットを示す。
【図６】  短縮されたタイム・スタンプが使用される発明された方法の実施態様のステップを示す。
【図７】  本発明のフィルタリング・アルゴリズムの例を示す。
【図８】  ＳＮＤＣＰ  ＳＮ−ＵＮＩＴＤＡＴＡ  ＰＤＵのフォーマットを示す。
【図９】  代わりの実施態様を示す。
【図１０】  本発明の移動局における種々の機能を行うブロックを示す。
【図１】
0003751823.tif 000005
【図２】
0003751823.tif 000006
【図３】
0003751823.tif 000007
【図４】
0003751823.tif 000008
【図５】
0003751823.tif 000009
【図６】
0003751823.tif 000010
【図７】
0003751823.tif 000011
【図８】
0003751823.tif 000012
【図９】
0003751823.tif 000013
【図１０】
0003751823.tif 000014