(57)【特許請求の範囲】
【請求項１】
第一通信局から第二通信局に通信信号を送信する方法において、
通信信号がアクティブな期間中に、ヘッダ情報と通信信号情報を含む通信信号パケットを第一局から第二局へ送り、
第一局が通信信号のアクティビティの欠如を検出し、
第一局の通信信号のアクティビティの欠如の検出に応答して、第二局によって使用可能なヘッダ更新情報を含む更新パケットを第一局から第二局へ送って、第一局から第二局へ送られた次の通信信号パケットのヘッダ情報を解読することを含んでなる方法。
【請求項２】
第一通信局から第二通信局に通信信号を送信する方法において、
第一局が、ヘッダ情報とペイロード情報を含むパケットを集めて、集めたパケットを第一局から第二局へ送り、
上記収集工程は、第一局から第二局へ送られた次のパケットのヘッダ情報を解読するために第二局によって使用可能なヘッダ更新情報と少なくとも一部のペイロード情報を置換することを含む更新パケットを第一局が集めることを含み、
上記送る工程が、第一局から第二局へ上記更新パケットを送ることを含む方法。
【請求項３】
第二通信装置に通信信号を送信する通信装置において、
通信信号がアクティブな期間中に、通信信号情報を受信する入力を持ち、通信信号情報とヘッダ情報を含む通信信号パケットを第二装置に送るための出力を有するパケットユニットと、
上記パケットユニットに連結されて、上記ヘッダ情報をそれに提供し、上記パケットユニットから第二装置に送られる次の通信信号パケットのヘッダ情報を解読するために第二装置によって使用可能なヘッダ更新情報をそれに提供するヘッダユニットとを具備し、
上記パケットユニットが、通信信号のアクティビティの欠如に応答して上記ヘッダ更新情報を含む更新パケットを上記出力から第二装置に送るように構成された通信装置。
【請求項４】
第二通信装置に情報を送信する通信装置において、
ペイロード情報を受け取る入力を持ち、ペイロード情報とヘッダ情報を含むパケットを第二装置に送るための出力を有するパケットユニットと、
上記パケットユニットに連結されて、上記ヘッダ情報をそれに提供すると共に、上記パケットユニットから第二装置に送られる次のパケットのヘッダ情報を解読するために第二装置によって使用可能なヘッダ更新情報をそれに提供するヘッダユニットとを具備し、
上記パケットユニットが、上記パケットの一つを送る前に、ヘッダ更新情報でペイロード情報の少なくとも一部分を置換するように作用可能である通信装置。
【請求項５】
第一通信局から第二通信局にソースコード化データを送信する方法において、
第一局が、ヘッダ情報とペイロード情報を含むソースコード化データパケットを集めて、集めたパケットを第一局から第二局へ送り、
第一局が、ソースコード化データをつくり出したコーデックのビットレートが閾値以下であることを決定し、その後、第一局から第二局に送られる次のソースコード化データのヘッダ情報を解読するために第二局によって使用可能なヘッダ更新情報、ソースコード化データ及びヘッダ情報を含む更新パケットを集める方法。
【請求項６】
第二通信装置にソースコード化データを送信する通信装置において、
ソースコード化データを受け取る入力を持ち、ソースコード化データとヘッダ情報を含むソースコード化データパケットを第二装置に送るための出力を有するパケットユニットと、
上記パケットユニットに連結されて、上記ヘッダ情報をそれに提供すると共に、上記パケットユニットから第二装置に送られる次のソースコード化データパケットのヘッダ情報を解読するために第二装置によって使用可能なヘッダ更新情報をそれに提供するヘッダユニットとを具備し、
上記パケットユニットが、ソースコード化データをつくり出したコーデックのビットレートが閾値以下であることを示す情報を受け取る入力を持ち、上記パケットユニットが、上記情報に応答して、ヘッダ情報とソースコード化データと併せて上記ソースコード化データパケットの一つにヘッダ更新情報を挿入する通信装置。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は一般にパケット通信に係り、より詳細にはパケット通信におけるヘッダ圧縮に関する。
【０００２】
（従来技術）
ヘッダ圧縮（ＨＣ）という用語は、２点間直結リンク上でパーホップベースにてパケットヘッダ中に運ばれる情報に必要なバンド幅を最小にする技術を意味する。ヘッダ圧縮は通常最初は空白情報のみを送信することで実現される。ついで、半空白情報は、以前のヘッダからの変化分のみを送信することによって伝送され、全く一定していない長さの情報を圧縮せずに送信する。ゆえに、ヘッダ圧縮は通常ステートマシンで行う。
【０００３】
従来のＶｏＩＰパケット（音声ＩＰ）は、図１に示したように、基本的に異なる品質要求で三の部分から構成される。この三の部分は、
（１）圧縮されるかまたは圧縮されないヘッダ１１。例えば、実時間の会話で従来のＩＰ／ＵＤＰ／ＲＴＰヘッダがよく使用される。
（２）パート１２のスピーチコーデックのビットは音声の品質にきわめて重要である。例えば、ＧＳＭフルレートスピーチコーデックは、１Ａ、１Ｂ、および２の３つのクラスがあり、クラス１Ａとクラス２のスピーチコーデックビットは音声の品質に対してそれぞれ最も重要である、また余り重要ではない。
（３）番号１３のスピーチコーデックビットは、例えばＧＳＭのクラス２のように余り重要ではない。
【０００４】
ＩＰ／ＵＤＰ／ＲＴＰに対する従来のヘッダ圧縮スキームは、通常以前のヘッダに依存するかもしれない、ＨＣの状態のようなソフトステート特性を持つ。圧縮されたヘッダ内のエラーは対応するパケットの損失となるかもしれない。なぜならば、それぞれのヘッダは通常以前のヘッダからの変化として示され（デルタコーディング）、圧縮ヘッダ内のエラーはＨＣソフトステートが更新されるまで連続するパケットが損失する原因となろう不完全な状態であるからである。もし圧縮ヘッダを含めたパケットのペイロードが実時間サービスを支援するならば、いくつかの連続パケットの損失は実時間サービスの品質に悲劇的である。例えば、実時間音声サービスの品質は連続する損失音声フレームが原因で実質的に低下する。もし音声フレームエラーレートが突発的な特性を持つならば、音声品質は同様の音声フレームエラーレートよりも悪くなる、しかしフレームエラー特性との関連は少ない。
【０００５】
ビットエラーの効果は、ＶｏＩＰパケット内のどこでビットエラーが発生したかに依存して異なるかもしれない。
（１）  図１の番号１３内のビットエラー（スピーチコーデックビットよりは重要でない）は特定のパケットのために音声に対する品質がわずかに低下する結果となる。
（２）  図１の番号１２内のビットエラーは、パケットが使用できないと判定され、音声復号機として使用されないため深刻である。従って特定のパケットは、パケットの番号１２内のビットエラーのため損失する。
（３）  図１の番号１１のビットエラーは、プロトコルスタックの上の層へ伝送されなかった故の特定のパケットの損失という結果になる。さらに、ヘッダ圧縮ソフトステートは不正となるために、多数の連続する失ったフューチャーパケットという結果となる。これらは、あるパケット内のビットエラーは多数の連続するパケットを損失させる結果となるため、最も深刻なエラーである。
【０００６】
従来のヘッダ圧縮アルゴリズムは、狭帯域回線、回線のエラーレートが固定されている小さい有線回線に適している。この回線の使用法は同様の回線を使用する他のユーザーに影響しない。これはワイヤレス回線の場合ではない。ワイヤレス回線の音声品質は急速に変化し、この回線の使用法は干渉という点で他のユーザに影響を与える。ワイヤレス回線のヘッダ圧縮のスキームにおいて、圧縮ヘッダ内のエラーの確率は大きくなり、これらの圧縮ヘッダエラーの効果は減少させなければならない。
【０００７】
これらの問題を回避する二の方法は、ＨＣソフトステートの更新をする回数を最小にするか、圧縮ヘッダ内のビットエラーの確率を最小にするかのどちらかである。
【０００８】
ＨＣソフトステートの更新に関する一の既知の方法は、完全なヘッダを定期的に、頻繁に送信することである。例えば、完全なヘッダを、他のパケット内の圧縮ヘッダを送信している間５音声パケット毎に送信する。もし固定ビット率の回線を使用するならば、この回線のビット率については、遅延の変動は好ましくないため、それぞれの最も大きいパケットサイズに選ばれる。故に、回線のビットレートは完全なヘッダの状態でパケットを参照して選ばれ、結果的にリソース（例えば無線リソース）を浪費する。さらに、そのようなヘッダ圧縮スキームのロバスト性を達成するために、完全なヘッダの繰り返し送信の回数はある程度大きくなければならず、これは圧縮度とヘッダ圧縮スキームの効率を減少させる。従って、完全なヘッダの状態でヘッダ圧縮状態の通常の更新は、結果的に非効率なヘッダ圧縮か、例えばビットエラーに不利で必要なロバスト性のない効率的なヘッダ圧縮のどちらかである。
【０００９】
ヘッダ圧縮ソフトステートを更新する他の方法は、必要なときはいつでもソフトステートの更新要求をするヘッダ圧縮スキームである。しかしながらこの方法は、不正なソフトステート期間を小さく保つために、重複回線を要求は短いラウンドトリップ時間ですませることができる。さらに、そのようなスキームは、一般に信頼できるソフトステートを更新する要求を伝達させる寄生チャンネルを要求する。
【００１０】
先に提示したヘッダ圧縮スキームのソフトステートの更新の見地から上述の従来技術の不利な点を回避することが要求されている。
【００１１】
本発明は、実時間通信信号を含むパケットの往来を伝える通信システム内の、ヘッダ圧縮スキームソフトステートを更新するために提供する。ヘッダ圧縮の状態は、通信信号が活動していない期間中に更新される。本発明はまた、ヘッダ更新情報を伝えるために通信信号からビットを取り出すことによるヘッダ圧縮の状態の更新に対して提供する。もし、通信信号がソース信号符号化データを含むならば、本発明は、ソース信号符号化データを生成するコーデックのビットレートを基礎とする、ヘッダ圧縮状態を選択的に更新するために提供する。この動作は、ソース信号符号化データを取り出すことなくヘッダ圧縮状態を更新することを可能にする。
【００１２】
（詳細な記載）
本発明の実施例は、従来のデジタル音声サービスで用いられるＤＴＸ技術と協調できる。ＤＴＸ（不連続伝送）は、非音声（静寂）区間を検出し、受信端でコンフォートノイズを生成するために、これらの区間の間で静寂記述子（ＳＩＤフレーム）のみを送信する技術を有する。このコンフォートノイズは幻影的な音を連続伝送する。よって、非音声区間の間は、伝送されたパケットは、ＳＩＤフレームを含む内容の部分（１２と１３）を除く、図１に示したものと同様なフォーマットを持つ。図２と３は、元のＤＴＸ（図２）とソフトＤＴＸ（図３）と呼ばれる従来のＤＴＸスキームを示す。
【００１３】
本発明の実施例によると、ヘッダ更新情報は図２のＳＩＤフレームに加えられるかまたは、図２のＳＩＤフレームを置き換える。ＧＳＭでは例えば、ＳＩＤフレーム（図２の番号２１を参照）は静寂区間の間定期的に伝送される（０．４８秒ごと）。要求されたヘッダ圧縮状態の更新は、例えば図２と４を参照して、ＳＩＤフレームと一緒（４１参照）かまたは代わりの（４２参照）完全なヘッダのような、ヘッダ更新情報を送信することによって達成できる。別の実施例は、ヘッダ圧縮状態は図３に示したように、従来のソフトＤＴＸ技術と共に達成される（”Continuous and Dis-Continuous Power Reduced Transmission of Speech Inactivity for the GSM System”, Stefan Bruhn et al. GlobeCom98）。ソフトDTX技術は、非音声区間の間他のリンクへ多くのインターフェースを導入せず、フレーム３１の低ビット率ストリームを実現する可能性がある。ゆえに、ソフトＤＴＸは図５に示したように非音声区間の間ヘッダ更新情報を運ぶために使用される。
【００１４】
ＨＣソフトステートの更新を生成するための上で記載したＤＴＸの使用のひとつの例を図６に示した。６１で更新が要求されると、ＤＴＸの動作が行われているかどうかを６２で決定する。もしそうならば、ヘッダ更新情報は６３でＳＩＤフレームに加えられる（図５と図４の４１参照）か、ＳＩＤフレームと置き変えられる（図４の４２参照）。
【００１５】
従来の映像符号化では、伝送局は例えば現在取得した映像と、現在の画像のすぐ前に取得した画像との違いを表示する情報をそれぞれ含むフレームのシーケンスを出力する。このように、画像が伝送局で読みとられている間は変化しない、伝送局は、現在の画像が直前の画像と異ならない（少なくとも一定の限度を超えて異ならない）。これら静止画像フレームは一般に、画像が変化せず（または実質変化しない）静止映像区間が集まっているという点で上述のＳＩＤフレームに類似している。上述の図２から６に関して記載された技術は、映像パケットの実施に応用でき、ヘッダ更新情報は「静止画像」フレームに加えられるか、「静止映像」の間「静止画像」フレームと置き換えるかのどちらかで送信される。
【００１６】
本発明のさらなる実施例は、ヘッダ圧縮更新情報を含むパケットペイロードビット、例えば音声フレームビット、映像フレームビットまたはどんな要求された情報でも表すペイロードビットを置き換える。もしヘッダ圧縮状態が不正である（例えば、以前に圧縮されたヘッダ内のビットエラー）とき、ペイロードビットは（例えば図１の１２と１３参照）はヘッダ圧縮状態が修復されるまでアプリケーション層へ配信されない。ゆえに、ヘッダ圧縮状態が修復されている間、ペイロードビットはとにかく役立たない。搭載例として音声フレームを用いて、ヘッダ圧縮更新情報を含む音声データのいくつかの部分を置き換えることによって、直後のフューチャー音声フレームはアプリケーション層へ配信される。音声フレームの一部または全部はヘッダ更新情報で置き換えられるかもしれない。この搭載ビットの置き換えは、搭載ビットは「取り出され」ヘッダ更新情報を伝えるために用いられるので「スチールビット」と呼ばれる。
【００１７】
ヘッダ更新情報で置き換えるための音声フレームビットが検出されると、音声コーデックの特性は考慮に入れることができる。もっとも一般的な音声コーデックは、関連する重要度によって分類できる。例えば、上で挙げたように、ＧＳＭ完全レート音声コーデックは異なる重要度の三のビットのクラス：クラス１Ａ、１Ｂおよびクラス２を持っている。クラス１Ａビットは最も重要でクラス２ビットはあまり重要でない。このように、ヘッダ更新情報ビットはむしろ、これらのビットが結果的な音声品質に対してあまり重要でないため、有効なクラス２ビットに置き換える。図７はこれがどのように実現されるかの例を示している。
【００１８】
図７の７１で、最も重要なビットを除いた全てのビットは取られ、全てのビットが７２で取られる。７３と７４での更新によると、より多くのビットが７４でより短い時間に対して取り出されている間、わずかのビットが、７３でより長い時間に対して取り出される。
【００１９】
本発明の重要度のレベルが変化する選択するビットの中でのビットスチール技術は、上で参照した、関連する重要度によって出力ビットが分類されている、音声コーデックを例として記載され、これらのビットスチール技術は関連する重要度によって出力ビットが分類されているどんなタイプのコーデックにも応用できる。映像コーデックもまたこのタイプのコーデックの例である。
【００２０】
ソースコード化データを含むペイロードの例では、ヘッダー圧縮ソフトステートは、どんなソースコード化データも取り出すことなしにソースコード化データビットを生成するコーデックのビットレートの変化と連携して更新できる。例えば音声または映像コーデックのような従来のコーデックは通常、二の典型的な理由のためビットレートは低い：（１）コーデックはビットレートを回線の状態に適合させる（回線適合モードと呼ばれる）、回線が混んでいるときはビットレートを低くする。（２）コーデックはソースの振る舞いにビットレートを適合させる（ソース適合モードと呼ばれる）、ソース（例えば音声ソースまたは映像ソース）が少ないソース活性情報（すなわちより多くの静寂区間または「静止映像」）を生成するとき。ソース適合モード内の低ビットレートは、少ないビットはソースの活性化を表すために用いられ、さらにヘッダ更新情報に対して用いられるビットを減らすので、ヘッダ更新情報を送信するのに有利である。
【００２１】
図１３は、例えば音声および映像パケットのようなソースコード化データパケット内のヘッダ圧縮ソフトステート更新を促進するために、上で記載した低コーデックビットレートを実現させるための動作例を示した。ＨＣソフトステート更新が１２１で要求されたとき、コーデックビットレートがしきい値レベルＴＨの下かどうかを１２２で決定する。しきい値レベルＴＨは要求された性能を提供するために経験的に決定される。もし１２２でコーデックビットレートがＴＨを下回るとき、ヘッダ更新情報はソースコード化データとともにパケット内に１２６で送信される。
【００２２】
もし、いま１２２でコーデックビットレートがＴＨを下回るとき、ＴＨを下回る低いビットレートのコーデックを要求するかどうかを１２４で決定する。もしそうならば、コーデックはＴＨを下回る低いビットレートに１２５で要求され、ヘッダ更新情報はソースコード化データとともにパケット内に１２６で送信される。実施例では、コーデックは低いビットレートへ要求されず、動作は１２４から１２２へ戻る。
【００２３】
ヘッダ更新情報が１２６で送信された後、コーデックビットレートは必要ならば（すなわち、もし１２５で低かったならば）１２７で修復される。
【００２４】
本発明はまた、段階的に更新するヘッダ圧縮ステートを提供する。例えば、与えられた時間でヘッダ内で一のフィールド（または二、三のフィールド）のみ更新するために決定されるかもしれない。特別な実施例として、もし与えられた音声フレームが十分なビットを持たないならば、ＩＰ／ＵＤＰ／ＲＴＰヘッダの一部のＲＴＰのＲＴＰシーケンス番号のみが、音声フレーム内で更新される。段階的な更新情報を送信するための少数のビットの使用は、いくつかの場合において、十分なソフトステート更新を提供する、しかし、他の場合、より多くの時間を費やして要求された更新を完成させる（例えば、図７の７３参照）。
【００２５】
図８は、本発明によるビットスチールスキームの実現のために実行されることができる動作の例を示した。もし更新が８１で要求されると、取り出すために使用できる十分なビットがあるかどうかを決定し、完全なヘッダ更新情報を送信するために使用する。もしそうなら、８３でビットは取り出され、完全なヘッダ更新情報を送信するために用いられる。もし８２で有効な十分なビットがなければ、例えば、不十分なＧＳＭクラス２音声ビットまたは全体内の不十分なペイロードビット、８４で、有効なビットは取り出され、ヘッダ更新情報の一部を送信するために用いられる。
【００２６】
図６、８、１３の点線で示したように、それぞれの動作は様々に結合して示されている。例えば、音声、映像の実施ではもし、図６内で更新が要求されしかし、ＤＴＸ（または「静止映像」）動作が６２で現れないならば、図８のビットスチール動作か、図１３のコーデック関連のどちらかが実行される。別の実施例では、もし図１３の動作がヘッダ更新情報の送信内で起こらなければ、図８のビットスチール動作または図６のＤＴＸ／「静止映像」動作が実行される。更新が要求されたかどうかの決定は（６１、８１、１２１参照）、従来の基準が用いられる。
【００２７】
図４、５のＤＴＸ／静止映像更新技術を参照して、非音声／静止映像区間で送信される更新情報を含むパケットの例を図９に示した。図９のパケットの例は、従来のヘッダ（圧縮または非圧縮）ソフトステート更新タグ９１、ヘッダ更新情報の一部９３を含む。ソフトステート更新タグ９１は通信局が、パケットがヘッダ更新情報９３を含むことを認識するために、従来の音声（または映像）パケットまたは従来のＳＩＤ（または「静止画像」）フレームパケットに対する図９のパケットを間違いなく受信する。図９の点線９４で示したように、ヘッダ更新情報９３とタグ９１は、図５と図４の４１を参照して上で議論したように、ＳＩＤ（または「静止画像」）フレームをパケット内に含むことができる。
【００２８】
図１０は、本発明のペイロードビットを取り出す技術を使用して、ヘッダ更新情報を伝送するためにそれらを用いるとき、ヘッダ更新情報を伝送するために用いられるパケットの一例を示した。図１０のパケットは、従来のヘッダ（圧縮または非圧縮）、ソフトステート更新タグ１１０およびヘッダ更新情報１１０を含む。タグ１１０は、ペイロードデータへ付加する（または代わりに）ヘッダ更新情報含む図１０のパケットを認識する受信通信局を提供する。図１０の例は、ペイロードの一部１１２を点線で示した、例えば図１の１２で、最も重要な音声コーデックビットはヘッダ更新情報１１１とともにパケット内に含まれる。
【００２９】
図１０のパケットは、図１３のコーデック関連技術によるヘッダ更新情報を伝送するために用いられる。この場合、ペイロード全体は、低コーデックビットレートに対するしきい値ＴＨは、どんなペイロード（すなわち、ソースコード化データ）ビットも取り出すことなく付加される（挿入）ヘッダ更新情報１１１を許可するための必要な設定をすることができるので、１１２に含まれる。
【００３０】
図１１は、パケットが受信されたときＨＣソフトステートの更新のサポート内の本発明のによる実行例を示した。１０１でパケットを受信した後、パケットがソフトステート更新タグ（例えば図９の９１または図１０の１１０）を含むかどうかを１０３で決定する。もし含まなければＨＣソフトステート更新はない。もし含むならば、ヘッダ更新情報（図９の９３または図１０の１１１参照）は、１０４で再実行され、ＨＣソフトステート更新を実行するために１０５で使用される。
【００３１】
図１２は、図１−１１および１３を参照して上で記載した動作例を実行できる本発明による通信局の実施例の適切な部分である。図１２の通信局の例は、例えばセルラー電話または固定基地無線トランシーバーのような移動無線トランシーバーのようなワイヤレス局である。図１２の通信局は、例えばビデオ会議ホストのような有線回線を用いたワイヤライン通信局であってもよい。
【００３２】
図１２の通信局は、パケットユニットへ多量の情報（例えば音声または映像情報）提供するために、およびパケットユニット１３２から多量の情報を受信するために通信ポート１３１を含む。通信ポート１３１はヘッダユニット１３３へヘッダ情報を提供する。ヘッダユニット１３３は、通信ポート１３１によって提供されるヘッダ情報からヘッダ（圧縮または非圧縮）を提供するために従来の技術を用いる。ヘッダユニット１３３はパケットユニット１３２へ出力ヘッダを提供し、パケットユニット１３２から入力ヘッダを受け取る。
【００３３】
パケットユニット１３２は、ヘッダユニット１３３から受信したヘッダビットと、例えば図１に示したように出力パケットを形成するために通信ポート１３１から受信した固有情報ビット（すなわちペイロードビット）を組み合わせるために従来の方法で操作できる。パケットユニット１３２は、無線リンク１３５を通じてパケットを伝送する無線ユニット１３４へ組み合わせたパケットを転送する。他の実施例では（例えばビデオ会議ホスト）、パケットユニット１３２は点線で示したように有線通信回線（例えばインターネットのようなデータネットワーク）へパケットを出力できる。図１２の出力パケットは、図１２の通信局と類似の構造と機能を持つ受信局（図示しない）によって受信される。
【００３４】
パケットユニット１３２は、無線リンク１３５を通じて無線ユニットによって受信される入力パケットを無線ユニット１３４から受け取る。パケットユニット１３２は従来通り入力パケットを分解し、それぞれの入力パケットから通信ポート１３１へ従来の使い方で固有の情報を提供する。パケットユニットは、入力パケットからヘッダユニット１３３へ、従来の技術を使用するのに必要である解凍をして通信ポート１３１へヘッダ情報を転送する、ヘッダを提供する。
【００３５】
パケットユニット１３２は通信ポート１３１から、図２と３に示したＳＩＤ「静止画像」フレームを含む出力パケットによって応答するＤＴＸ表示（すなわち音声アクティビティがない）かまたは「静止映像」表示（すなわち映像アクティビティがない）を受信する。
【００３６】
パケットユニットは、図１３を参照して上で記載されたように、ビットレート情報を受け取るために、低い／修復ビットレートを注文するために提供するコーデックと通信できる。
【００３７】
ヘッダユニット１３３は、パケットユニット１３２とヘッダ更新情報をやりとりするために連結され、出力パケット内のヘッダ更新情報の送信を要求されたとき、パケットユニット１３２へ信号を送信する。出力パケット内のヘッダ更新情報を送信する信号の受信に応じて、パケットユニット１３２は、個別か上で議論したように満足するかのどちらかで、図６、８、１３に示した動作を実行する。図９に示されたようなパケットは、もしＤＴＸ／「静止映像」の動作が現れ、図１０に示されたようなパケットが、ＤＴＸ動作が現れなかったとき生成されるならば、生成される。
【００３８】
図１２の通信局が入ってくるパケットを受信したとき、図１１で示した動作例を実行する。パケット１３２が図９の９１または図１０の１１０に示したような更新タグを検出すると、パケットユニットはヘッダ更新情報を受け取り、ヘッダ更新情報をＨＣソフトステートを更新するためのヘッダユニットを支持する信号と共にヘッダユニット１３３へヘッダ更新情報を提供する。もし例えば、ヘッダ更新情報が完全なヘッダを含むならば、ヘッダ圧縮ステートマシン（図示しない）をリセット（すなわち更新）するために従来の方法で完全なヘッダを使用する。
【００３９】
当業者ならば明らかであるが、以上記載した本発明は、例えば従来のワイヤレスまたはワイヤライン通信局の部分のパケット通信内でハードウエア、ソフトウエアまたは両方を適切に変更することで実現できる。
【００４０】
前述の議論からわかるように、本発明は以下に示す従来技術を超える利点を提供する。すなわちヘッダ圧縮状態の連続的な更新はリソースを効率よく用いることで固定ビットレート回線内で実現され、そして不正ステート内にあるヘッダ圧縮スキームの間の時間はリソースを効率的に使用することで減少され、不正なヘッダ圧縮状態による多数の損失パケットは減少される。これによって実時間サービスの品質は改良される。
【００４１】
本発明の実施例を上に詳細に記載したが、これは本発明の範囲を限定するものではなく、発明は様々な実施例の形で実現できるものである。
【図面の簡単な説明】
【図１】  図１は、本発明と関連して用いられるパケットフォーマットの例を示した。また図１Ａは、図１で用いられる陰に対する記載である。
【図２】図２は従来の音声コーデックによるＤＴＸ（不連続伝送）の例の線図を示した。
【図３】  図３は従来の音声コーデックによるＤＴＸ（不連続伝送）の例の線図を示した。
【図４】  図４は、半発明が、ヘッダ圧縮ソフトステート更新情報を伝送するための、図２と３の従来のＤＴＸの動作を利用する方法の例を示した。
【図５】  図５は、半発明が、ヘッダ圧縮ソフトステート更新情報を伝送するための、図２と３の従来のＤＴＸの動作を利用する方法の例を示した。また図５Ａは図２から５で用いられる陰に対する記載である。
【図６】  図６は、図４と５に示されたヘッダ圧縮更新スキームに関連した動作の例を示した。
【図７】  図７は、ヘッダ圧縮ソフトステート更新を許可するための、本発明によるビットの間引き動作の実行例の線図を示した。また図７Ａは図７で用いられる陰に対する記載である。
【図８】  図８は、図７のビットの間引きスキームに関連した動作の例を示した。
【図９】  図９は、図４と５のＤＴＸ更新スキーム併せて用いられるパケットの例を示した。
【図１０】  図１０は図７のビットの間引きスキームと併せて使用されるパケットの例を示した。
【図１１】  図１１は本発明によるパケットの受信の時、ＨＣソフトの更新を支援して実行する動作の例を示した。
【図１２】  図１２は、本発明による通信局の例の適当な部分を示した。
【図１３】  図１３は、パケットペイロード情報が源信号符号化データを含むとき、本発明によるＨＣソフトの更新を支援して動作できる動作の例を示した。
【図１】
0004413437.tif 000002
【図１Ａ】
0004413437.tif 000003
【図２】
0004413437.tif 000004
【図３】
0004413437.tif 000005
【図４】
0004413437.tif 000006
【図５】
0004413437.tif 000007
【図５Ａ】
0004413437.tif 000008
【図６】
0004413437.tif 000009
【図７】
0004413437.tif 000010
【図７Ａ】
0004413437.tif 000011
【図８】
0004413437.tif 000012
【図９】
0004413437.tif 000013
【図１０】
0004413437.tif 000014
【図１１】
0004413437.tif 000015
【図１２】
0004413437.tif 000016
【図１３】
0004413437.tif 000017