JP4582565B2 - パケット通信におけるロバストヘッダ圧縮 - Google Patents

Description

【０００１】
（発明の分野）
本発明は、パケット通信に関し、さらに詳細にはパケット通信におけるヘッダ圧縮に関する。
【０００２】
（従来の技術）
インターネットの驚異的な成功により、全リンクにインターネットプロトコルつまりＩＰを使用することが挑戦的な課題となった（例えば参考文献として添付し、その記載内容をここに取り込むものとする Jon Pastel著, “Internet Protocol”, DARPA REC 791, September 1981参照）。しかし、ＩＰプロトコルは高速大容量の有線リンク用に設計されていること、ＩＰプロトコルのパケットのヘッダは結構大きいことから、ＩＰプロトコルを携帯電話などの狭帯域で使用することは簡単ではない。例えば、通常の音声の様なリアルタイムのデータにＩＰプロトコルを使用することを考えてみれば、ＵＤＰ（User Datagram Protocol）と（例えば参考文献として添付し、その記載内容をここに取り込むものとする Jon Postel著,“ User Datagram Protocol”, DARPA RFC 768, August 1980 参照）、ＲＴＰ（Real-Time Transport Protocol）が（例えば参考文献として添付し、その記載内容をここに取り込むものとするHenning Schulzrinne, Stephen L. Casner, Ron Frederick and Van Jacobson共著, “RTP: A Transport Protocol for Real-Time Applications”, IETF RFC 1889, IETF Audio/Video Transport Working Group, January 1996参照）、ＩＰの前につけられる。それらのヘッダは総計で４０オクテット必要になる（ＩＰ２０オクテット、ＵＤＰ８オクテットそしてＲＴＰ１２オクテット）。これらのヘッダを、フレームサイズが１５−２０オクテットにすぎない通常の音声につけると、ヘッダ部がパケットの７０％より大きくなることになり、不利益を生じる。今度のＩＰversion ６では、ヘッダ長が４０バイトあるのでこの問題は更に深刻になるだろう（例えば、参考文献として添付し、その記載内容をここに取り込むものとするSteven Deering and Robert Hinden共著、“Internet Protocol Version 6 (Ipv6) Specification”, RFC 2460, IETF Network Working Group, December 1998 参照）。ヘッダサイズを縮小すればスペクトルの利用効率が改善され、無線リンクで転送する際の費用を大幅に削減できる。
【０００３】
ヘッダ圧縮（ＨＣ）という言葉は、ホップごと（per-hop）を基本としたポイント・ツー・ポイントリンクにおいてヘッダに含まれる情報に必要な帯域幅を最小化する技術を意味している。ヘッダの一部のフィールドはフローの間変わらないし、ほとんどのヘッダの変化は少ないおよび/または予想可能なので、ヘッダ圧縮はこの点を利用する。従来のヘッダ圧縮方法は、この点を利用して、静的な情報は最初だけ送り、一方で変化するフィールドは圧縮せずに（例えば完全にランダムな情報として）、またはパケットとパケットの間の差（デルタ値）として送る方法を取っており、後者は一般的には差分（デルタ）によるエンコーディングと呼ばれている。差分によるエンコーディングを行うと、圧縮は不安定になり、その動作はリンクの状況に大きく影響される。例えば、パケットの消失が頻繁に起きるリンクにおいては、紛失が起こる度にそれに続く多くのパケットが失われるのが典型的であり、したがって品質の低下を生じることになる。
【０００４】
従来のヘッダ圧縮/伸長の方法はステートマシンを使用することが多いが、ここで解決しようとしている課題は、圧縮と伸長の状況（またはコンテキスト）を整合させることである。
【０００５】
従来の伸長コンテキストを最新のものに保つ方法として、一般的に２つの方法がある。第一の方法は、全ヘッダデータが送られた時点で、定期的に更新する方法である。この方法の利点は、デコンプレッサからコンプレッサへメッセージを送らないので、動作がリンクのラウンドトリップ時間（ＲＴＴ）に影響されない点である。これはつまり、単信方式のリンクにも利用できる。一方、定期的な更新には多くの不便な点がある。例えば、更新ヘッダの数が多いためにヘッダオーバーヘッドが平均的に大きくなるが、更新ヘッダの大部分は不要である。一方、リンク上のエラーが頻繁に起こる場合、ヘッダの更新率が低すぎると紛失パケット数が増える。
【０００６】
コンテキストを最新のものに保つための別の一般的な方法は、デコンプレッサから要求があったときのみ更新情報（つまり、全ヘッダデータ）をコンプレッサへ送る方法である。これには複線式のリンクが必要であるが、不必要な更新は行われないので平均的なヘッダオーバーヘッドは小さくなる。ラウンドトリップ時間（ＲＴＴ）が短いとき、この解決法によって、リンクエラー後のコンテキスト状態に矛盾がある時のパケット紛失回数を減らすことができる。明らかに不利な点は、複線式リンクの補助チャネルへの依存、リンクで紛失されたパケットへの感度、そしてラウンドトリップ時間（ＲＴＴ）が長く、コンテキストが無効になった場合（とそれに伴う更新請求）に連続的に紛失するパケットが多いことである。
【０００７】
すべてのヘッダ圧縮方法に関して、動作の測定には２つの基準がある。圧縮効率は、ヘッダがどの程度圧縮されるかを示す。それは平均または最大のヘッダサイズ、その両方の組み合わせ、または他の方法で表される。耐性は、リンク上でのパケットの紛失をいかにうまく処理するかを表すものである。パケットの紛失はヘッダのコンテキストに矛盾を生じさせ、多数の連続したパケット紛失を導くかどうかでる。
【０００８】
通常、従来のヘッダ圧縮方法の大部分はうまく作動するが、それには低いエラー発生率と短いラウンドトリップ時間（ＲＴＴ）が必要である。
【０００９】
現在では、多数のヘッダ圧縮方法がある。実際は、それらは全く違う方法というわけではなく、考え方は同じであるが開発状態が異なっているだけである。一番最初の提案は（例えば、参考文献として添付しその記載内容をここに取り込むものとするVan Jacobson著,“Compressing TCP/IP Headers for Low-Speed Serial Links”, IETF RDC 1144, IETF Network Working Group, February 1990参照）ＴＣＰの圧縮のみ行ったのであるが（例えば、参考文献として添付しその記載内容をここに取り込むものとするJon Pastel著, “Transmission Control Protocol”, DARPA RFC 761, January 1980参照）、考え方が後になって発達して、ＵＤＰおよびＲＴＰヘッダの圧縮も可能になったのである。（例えば、参考文献として添付しその記載内容をここに取り込むものとするMikael Degermark, Bjorn Nordgren and Stephen Pink共著,“ IP Header Compression”, IETF RFC 2507, IETF Network Working Group, February 1999, および Steven Casner and Van Jacobson共著,“ Compressing IP/UDP/RTP Headers for Low-Speed Serial Links”, IETF RFC 2508, IETF Network Working Group, February 1999参照） ゆえに、今日のリアルタイムデータフローの際のヘッダ圧縮方法はただ一つであり（上記の、Casner とJacobsonに記述）それは最近ＩＥＴＦ（Internet Engineering Task Force）によって標準化された、音声／映像転送研究グループによるＣＲＴＰと呼ばれるヘッダ圧縮であるということがいえる。
【００１０】
ＣＲＴＰではほとんどのパケットについて４０オクテットのＲＴＰ／ＵＤＰ／ＩＰヘッダを２オクテットにまで圧縮し、リンクが信頼できるものである限りこの最小のサイズがほとんど平均値になる。ＣＲＴＰは、ＲＴＰシーケンスナンバーフィールド、ＲＴＰタイムスタンプフィールド、そしてＩＰヘッダのＩＤフィールドの３つのフィールドで異なるエンコーディングを使用する。無効となった伸長コンテキストを更新するため、ＣＲＴＰは上述の更新請求を行う。
【００１１】
ＵＤＰ／ＩＰヘッダの圧縮のより一般的な方法は（上記Degermark 等の共著に記述）、定期的更新の原則に基づくものであるが、ＲＴＰヘッダが圧縮されずに送られることがあり、その結果、各パケットについて１２オクテット余分に必要になる。
【００１２】
ＣＲＴＰは、ビットエラー率が低く、および／または、ラウンドトリップ時間（ＲＴＴ）が小さいリンクに使用する限り、うまく動作する。しかし無線リンクではそうでない場合が多い。一般的には、ラウンドトリップ時間（ＲＴＴ）が大きいので、デコンプレッサがコンテキストの更新を受信する前に、連続した多数のパケットを紛失する結果になる。これは一般的にリアルタイムの音声や映像のようなアプリケーションでは好ましくない。それゆえ、全体的なパケット紛失率が高すぎ、結果を改善するために無線リンクの性能を改善することは不可能であると考えられている。ビットエラー率（ＢＥＲ）とラウンドトリップ時間（ＲＴＴ）を共に縮小することは大変費用がかかる。このようなわけで、ＣＲＴＰの弱点は耐性であるとみなされている。
【００１３】
一般に普及しているヘッダ圧縮方法に共通することは、デコンプレッサが少ない情報しか持っていないことである。一般的にヘッダフィールドはほぼ予想可能で、データの種類が判っているときには特に顕著なので、この単純さが重大な制限となる場合がある。もし、デコンプレッサがヘッダを「推定」することが出来れば、たとえコンテキストが矛盾する場合でも多くのヘッダは復元可能であろう。しかしこれらの「推定」は、何らかの方法で確認する必要がある。
【００１４】
デコンプレッサの能力を高めるという試みの一つは、Degermark等のTwiceメカニズムによって提唱された。Twiceというアイデアは、もしパケットが一つ紛失した場合、次のパケットのデルタ値が二度適用され、ほとんどの場合そうで有るように、次のデルタ値が消失したパケットのデルタ値と同じであればヘッダが正しく復元される。結果として、ヘッダコンテキストが矛盾する場合にもパケットを廃棄する必要がなくなる。
【００１５】
しかし、より正確に復元するためにはヘッダが正しく復元されたかどうか確認する方法が必要である。Twiceに提案されている一つの方法では、トランスポート層のチェックサムを利用する。その解決方法の問題点の一つは、ＵＤＰの場合で、全パケットについてチェックサムを行うので、ペイロードについても行われてしまう点である。例えば、音声コーデックでは、データが全くないより、破壊されたペイロードを受信するほうがよい。
【００１６】
前述のトランスポート層のチェックサムに関する問題の一つの解決策はいわゆるUDP Liteアプローチで、ヘッダは、パケットの必要な部分のみ、例えばヘッダ部をカバーする部分的なチェックサムを含むことが出来る。このようにUDP Liteヘッダはチェックサムと、チェックサムでカバーされるヘッダ部を示しているチェックサムカバーフィールドと、カバーされるヘッダ部そのものを含んでいる。
【００１７】
前述の点から、デコンプレッサのコンテキストを失わずにリンク内で紛失したパケットを処理することが出来、かつ現在の技術より高い圧縮効率を提供することの出来るヘッダ圧縮／伸長技術を提供することが望まれている。
【００１８】
（発明の概要）
本発明は、パケットがリンク内で紛失した場合でさえコンテキストの矛盾を回避することが出来るロバストヘッダ圧縮方法についての基本概念を提供するものである。それは、上記の両方の原則に比較して紛失パケット数を顕著に減らすことになる。
【００１９】
本発明は圧縮されていないヘッダに作用するヘッダコンプレッサのチェックサムを取り入れている。このチェックサムは圧縮ヘッダとして送信することが可能で、デコンプレッサで復元ヘッダデータの確認に利用することが出来る。
【００２０】
（発明の詳細な説明）
図１は、本発明による代表的なパケットヘッダ圧縮と伸長技術の概念図である。パケットデータ送信ステーションでヘッダ圧縮が行われ、パケットデータ受信ステーションでヘッダ伸長が行われる。特に、図１に図示されているヘッダ圧縮について、従来のデータパケット１１はヘッダ部１２とペイロード部分１３を含んでいる。ヘッダ１２（またはその任意の所望のフィールド）は例えば従来のＣＲＣ（Cyclic Redundancy Code）チェックサムのようなチェックサム１４を計算するために使用することが出来る。チェックサム１４のみで、通信チャネルを通じてペイロード１３と一緒に送信される圧縮されたヘッダ（またはヘッダフィールド）１５として使用できる。通信チャネルは、一例として携帯電話の無線リンクのような紛失の多い狭帯域リンクも含む。図１中の破線で示されているように、圧縮ヘッダ１５は後述の他の圧縮ヘッダ情報Ｉを付加することを選択できる。
【００２１】
ヘッダ伸長操作はヘッダ復元プロセス１６を含む。ヘッダデコンプレッサへ入力されるのは通信チャネルから受信した（壊れている可能性のある）圧縮ヘッダ１５である。復元プロセスが出力するのはオリジナルのヘッダ１２に一致するはずの復元されたヘッダ１２’である。復元されたヘッダ１２’は検証プロセス１７に入力される。検証プロセス１７ではオリジナルチェックサム１４の受信版１４’を用いて検証が試みられる。一実施例では、検証プロセスではチェックサム（例えば図１のＣＲＣチェックサム）を計算するために復元されたヘッダ１２’を使用し、そして計算されたチェックサムとオリジナルチェックサム１４の受信版１４’を比較する。もし検証プロセス１７で計算されたチェックサムが受信したチェックサム１４’に等しいときは、検証プロセスは、復元されたヘッダ１２’は良好であることを知らせる（検証プロセス１７のＯＫ出力参照）。もし計算値と受信されたチェックサムが一致しないときには、検証プロセス１７はＮＯＴ ＯＫの表示をヘッダ復元プロセス１６に出力する。ＮＯＴ ＯＫの表示に対応して、ヘッダ復元プロセス１６は別の復元されたヘッダ１２’を出力し、その後、上記の検証プロセスを繰り返すことができる。
【００２２】
上記のヘッダ伸長手続きは、チェックサムの値が受信したチェックサム１４’に一致するヘッダ１２’を作成するために、必要であれば何回でも繰り返すことが可能である。
【００２３】
図２は、上記のヘッダ圧縮技術に伴う本発明による代表的な手順を図示している。オリジナルの（圧縮されていない）ヘッダ情報を２１で受信した後、２２でヘッダ情報からチェックサムが計算される。それにより２３で、圧縮ヘッダに計算されたチェックサムが（選択により他の圧縮ヘッダ情報の付加可能）提供される。２４で、圧縮ヘッダとペイロードを含むパケットが通信チャネルを通じて送信される。
【００２４】
図３は、上記のヘッダ伸長技術に伴う本発明による代表的な手順を図示している。３１で、通信チャネルから圧縮ヘッダを受信する。３２で、ヘッダ復元プロセスはオリジナルの非圧縮ヘッダを推定しようと試みる。（図１の１２参照） 多くの例では連続パケットのヘッダ間の差分値（デルタ値）は復元プロセスで容易に予想可能である。例えば、リアルタイム音声通信での言葉が発せられている間、タイムスタンプ値は一般的には、連続して受信された２パケット間ではどこでも、おおよそ同量変化することが予測される。よって、図２の３２の、復元プロセス（図１の１６参照）では、以前のパケットのタイムスタンプ値に基づいて現在のパケットのタイムスタンプを正確に推定することが一般的には可能で、現在のパケットの圧縮ヘッダにある現在のパケットと直前のパケットのそれぞれのタイムスタンプの違いについての情報（例えば図１のＩ）を受信しなくてもよい。
【００２５】
しかし、他の状況では、送信されたヘッダフィールドを３２で予想するのは簡単ではない。リアルタイム音声通信に関する前述の例を用いて、沈黙または音声活動がなされていない期間には一般的には予め決められた無音声パケット（たとえば、従来のＤＴＸシステムのＳＩＤフレームパケット）が送信され、その後受信する最初の音声パケットのタイムスタンプは、音声活動のない期間の前に受信された最後の音声パケットのタイムスタンプ値とは一般的には大きく異なり、さらに重要な点は予想できない値であることだ。このような状況ではオリジナルのヘッダを復元する復元プロセス１６を援助するために、付加的な圧縮情報（図１のＩ）をチェックサムを含んだ圧縮ヘッダと一緒に送信することが可能である。
【００２６】
リアルタイム音声通信の例では情報Ｉは、例えば音声のない期間の後に送られる最初の音声パケットのタイムスタンプの最も下位のビットなどである。復元プロセス１６では、例えば無音声の期間以前に受信した最後の音声パケットの到着と、無音声の期間後に受信した最初の音声パケットの到着の間には時差の絶対値を認めることが出来る。この時間差は、前記の二つのパケットのタイムスタンプの差の推定値を得るための、スタンプ値の単位時間当たりの典型的な変化率の推定値と組み合わせることができる。このタイムスタンプの差の推定の最も上位のビットは、３２で非圧縮のタイムスタンプ値の推定を提供する圧縮ヘッダに含まれて受信する最下位のビットと結合することができる。
【００２７】
３４では、推定されたヘッダは（例えばタイムスタンプの推定）、チェックサムを計算するために利用され、計算されたチェックサムは３５で受信したチェックサムと比較される。もし計算された値と受信したチェックサムの値が一致すれば、推定されたヘッダは３６で容認される。もし計算された値と受信したチェックサムの値が３５で一致しなければ、経過時間の総計または失敗した推定の数などのような、希望のタイムアウトの基準を３７で考慮し、３２で別の推定を試みるかヘッダ復元プロセスを断念するかを決定することが可能である。
【００２８】
図４は、本発明によるパケットデータ送信ステーションの代表的な実施例を図示したものである。図４の実施例では従来のパケットデータ通信アプリケーション４５が４３でヘッダ情報をそして４４でペイロード情報を提供する。ヘッダ情報４３はヘッダコンプレッサ４１に入力されて、圧縮ヘッダ４６が作成される。圧縮ヘッダ４６はペイロード４２と結合してパケット４０を形成する。ペイロード４２はペイロードプロセッサ４８によって従来の方法で作成される。パケット４０は衆知の技術を使用している従来の無線送信装置４６へ送られ、例えば携帯電話の無線リンクのような無線通信リンクでパケットを送信する。図４の送信ステーションは、例えば静止衛星または携帯電話通信ネットワークで使用されている移動送信ステーションである。
【００２９】
図５は、図２の典型的な操作を実行する図４のヘッダ圧縮プログラム４１の代表的な部分を図示している。図４の通信アプリケーション４５から送られたヘッダ情報４３は、そのチェックサム５２を計算するチェックサム計算回路５１に入力される。ヘッダ情報はヘッダ圧縮装置５３にも入力される。ヘッダ圧縮装置５３では、デコンプレッサでヘッダ情報を復元するときに使用される付加的な圧縮情報Ｉ（図１参照）を選択的に提供出来る。チェックサム５２と、選択的に付加することが出来るので図５では破線で示されている付加情報Ｉは、結合して図４の圧縮ヘッダ４６の一部分５４（例えば、フィールド）を形成する。
【００３０】
図２と図５に図示されている代表的な技術は、ヘッダ情報４３のある部分（すなわちフィールド）またはすべての部分を圧縮するために利用できる。
【００３１】
図６は本発明によるパケットデータ受信ステーションの代表的な実施例を図示している。従来の無線受信機６４は。無線リンクで送信された図４では４０として図示されているようなパケットの受信版４０’を受信するために使用できることはよく知られた技術である。受信版パケット４０’はオリジナルの圧縮ヘッダ４６の受信版４６’とオリジナルのペイロード４２の受信版４２’を含んでいる。受信版のペイロード４２’は従来のペイロードプロセッサ６８に入力され、対応する受信されたペイロード情報６２を得てパケットデータ通信アプリケーション６５に入力される。受信版圧縮ヘッダ４６’にはヘッダデコンプレッサ６３が適用され、デコンプレッサ６３は受信版圧縮ヘッダ４６’を伸長し、それが受信されたヘッダ情報６１として通信アプリケーション６５に入力される。
【００３２】
図７は、図３の一般的な操作を行うことが可能な図６のヘッダデコンプレッサ６３の代表的な部分を図示したものである。図７の実施例では、ヘッダ復元回路７２はオリジナルの圧縮ヘッダに付加出来る付加圧縮ヘッダ情報Ｉの受信版Ｉ’を受信する（例えば、図５参照）。ヘッダ復元回路は推定ヘッダ７１を作成するが、それは例えば、従来の一般的な方法である連続するパケット間のヘッダフィールドの違いに基づく推定、または、受信した付加情報Ｉ’に基づく推定である。
【００３３】
推定ヘッダ７１はチェックサム計算回路７３へ入力され、７６でチェックサムが計算される。コンパレータ７４で、計算によるチェックサム７６とオリジナルのチェックサムを受信版５２’を比較する（例えば図５の５２参照）。もし、計算された値と受信したチェックサムが一致すれば、コンパレータの出力７７は、通信アプリケーション６５の受信ヘッダ情報入力６１に推定ヘッダ７１を入力させるための接続装置７５を起動させる（図６参照）。もし、計算された値と受信したチェックサムが一致しなければ、コンパレータ７４はＡＧＡＩＮ出力部７８を起動し、復元回路７２に別の推定をするよう指示する。このように、チェックサム計算回路７３とコンパレータ７４は、受信したチェックサム５２’を推定ヘッダ７１の妥当性を立証または否定するために使用する確認回路を形成する。チェックサムが一致しないうちにタイムアウト時間が経過したとき、または、予め決められた回数だけ比較したチェックサムが一致しなかったとき、コンパレータ７４は、ヘッダ情報の復元に成功しなかったことを示すフェール信号７９を出力することが出来る。
【００３４】
図３および図７の代表的な技術は、図６の４６’で図示されるような圧縮ヘッダの所望の部分（例えばフィールド）またはすべての部分を伸長することが出来る。
【００３５】
当業者にとって、従来のパケットデータ送信そして受信ステーションでのヘッダの圧縮および伸長についてのソフトウェア、ハードウェアまたは両方の適切な変更を行うことによって、図１から７についての上記の実施例を容易に実行出来ることは自明である。
【００３６】
また、当該分野の技術者は、上記の発明は復元されたヘッダフィールドの妥当性を立証するための方法を提供していることを高く評価するだろう。本発明は、圧縮ヘッダで送られたいかなる付加情報および／またはヘッダフィールド変化に関する認識に基づくより正確な「推定」をデコンプレッサで行うことを可能にする。本発明は、例えはエラー検出を提供する必要のない単純なリンク層を使用することも可能にする。本発明に基づくヘッダ圧縮は従来の方法に比較して耐性を向上させた。本発明は、パケット紛失を減少させ、連続するパケット紛失の長さも減らすことが出来る。また、本発明の復元技術はソフトステートの更新回数を減少させるので、それに応じて平均のヘッダサイズが小さくなる。
【００３７】
以上述べた発明は、例えばリアルタイム音声および映像アプリケーションのようなリアルタイム通信を含む、紛失の多い狭い帯域幅リンクでのパケット通信に適切であることは明白である。上記に詳細を記した本発明の代表的な実施例は、本発明の範囲を限定するものではなく、種々の実施例が実行可能である。
【００３８】
【図面の簡単な説明】
【図１】図１は、本発明による代表的なパケットヘッダ圧縮および伸長技術の概念図である。
【図２】図２は、図１のヘッダ圧縮技術に伴う典型的な操作を図示している。
【図３】図３は、図１のヘッダ伸長技術に伴う典型的な操作を図示している。
【図４】図４は、本発明による代表的なパケットデータ送信ステーションを図示している。
【図５】図５は、図４のヘッダコンプレッサの典型的な実施例を図示している。
【図６】図６は、本発明による代表的なパケットデータ受信ステーションを図示している。
【図７】図７は、図６のヘッダデコンプレッサの代表的な実施例を図示している。

Claims (1)

1. ヘッダ情報を作成するために通信チャネルから受信した所定のデータパケットの圧縮ヘッダ部を伸長する方法であって、
   前のデータパケットを受信してから活動してない期間後に続いて、前記所定のデータパケットが受信され、
   所定のデータパケットのヘッダ情報から生成されたチェックサムの受信版を前記所定のデータパケットの圧縮ヘッダ部から取得するステップと、
   複数のビットによって表示された値を有する少なくとも１つのタイムスタンプの最下位ビットを前記所定のデータパケットの圧縮ヘッダ部から取得するステップと、
   前のデータパケットの受信と所定のデータパケットの受信との間の時差の絶対値を求めるステップと、
   タイムスタンプ値の単位時間当りの典型的な変化率の推定値を取得するステップと、
   前のデータパケットのタイムスタンプと所定のデータパケットのタイムスタンプとの間の差のタイムスタンプの差の推定値であって、前記タイムスタンプ値の単位時間当りの典型的な変化率の推定値と、前記時差の絶対値とから求められて最上位ビットと最下位ビットとを含むタイムスタンプの差の推定値を求めるステップと、
   前記タイムスタンプの差の推定値の最上位ビットを、前記所定のデータパケットの圧縮ヘッダ部から取得したタイムスタンプの前記少なくとも１つの最下位ビットと結合し、前記所定のデータパケットの圧縮してないタイムスタンプ値を推定するステップと、
   前記所定のデータパケットの圧縮してないタイムスタンプ値の推定を利用して、チェックサムを生成するステップと、
   前記作成したチェックサムを前記チェックサムの受信版と比較して、圧縮してないタイムスタンプ値の推定を確認するステップと、
   を含む方法。

Images