JP2010515295A

JP2010515295A - 無線通信ネットワークにおける改良されたヘッダ圧縮

Info

Publication number: JP2010515295A
Application number: JP2009542844A
Authority: JP
Inventors: ヤン，トーマス，エス．; チャン，キンキン
Original assignee: アルカテル−ルーセントユーエスエーインコーポレーテッド
Priority date: 2006-12-26
Filing date: 2007-12-17
Publication date: 2010-05-06
Anticipated expiration: 2027-12-17
Also published as: US8027328B2; ATE488973T1; DE602007010662D1; EP2098035A2; WO2008085336A2; US20080151901A1; JP5084842B2; WO2008085336A3; EP2098035B1

Abstract

一実施形態では、受信された無線リンクプロトコル（ＲＬＰ）のパケットの中のＲＬＰのシーケンス番号と受信されたＲＬＰのパケットから復元されたリアルタイムプロトコル（ＲＴＰ）のパケットの中のＲＴＰのシーケンス番号との間で関係を特定する。圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのシーケンス番号は、この特定された関係、及び圧縮されたＲＴＰのパケットを形成する受信されたＲＬＰのパケット又はパケット群のＲＬＰのシーケンス番号のうちの少なくとも１つに基づいて特定される。ＲＴＰのタイムスタンプは同様の方法で特定することができる。

Description

インターネットプロトコル（ＩＰ）は有線ネットワーク及び無線ネットワークの両方において主要な転送プロトコルとなり、電気通信ネットワーク及びデータネットワークの集中をもたらした。多くのサービス及びアプリケーション（例えばＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩＰ）、双方向ゲーム、インスタントメッセージングなど）では、ＩＰパケットのペイロードはヘッダとほぼ同じサイズか又はそれよりもさらに小さい。パケットデータネットワークにおいて効率的な転送を行うために、ＩＰネットワークのプロトコルに加えて他のプロトコル（例えばリアルタイムプロトコル（ＲＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）など）が元の情報ビットに付加される。

幸いにも、常にパケットごとに膨大なＲＴＰ／ＵＤＰ／ＩＰのヘッダを送信する必要はない。代わりにロバストヘッダ圧縮（ＲｏＨＣ）などのヘッダ圧縮アルゴリズムを使用することができる。ヘッダ圧縮の背後にある基本的な考え方は、ＲＴＰ／ＵＤＰ／ＩＰのヘッダの中のフィールドの大部分は静的であり、従ってこれらは送信側のコンプレッサから受信側のデコンプレッサに、第１の通信（例えば無線システムにおいて最初に伝送されるパケット）中に圧縮されないまま一度送信されることが可能であるというものである。デコンプレッサが静的な情報を確実に取得すると、コンプレッサはヘッダの動的部分に関する情報を伝える圧縮されたヘッダの送信を開始する。デコンプレッサは圧縮されたヘッダからＲＴＰ／ＵＤＰ／ＩＰのヘッダを完全に再構成し、このパケットを次に渡すことができる。このようにして、パケットごとに大きなヘッダは送信されず、結果として容量の著しい節約になる。

しかし、現在のヘッダ圧縮方法にはいくつかの欠点がある。説明を簡単にするために、従来の無線通信システムにおいて実施されるヘッダ圧縮に関して、このような欠点を説明する。

図１は周知の無線通信ネットワークの一般的なアーキテクチャを示す。図のように、アクセス端末（ＡＴ）１０がエアインターフェイスによって基地局（ＢＴＳ）１２と通信する。ＡＴの例には、移動局、移動体、無線電話、無線装備されたＰＤＡ又はコンピュータなどがある。複数の基地局１２が無線ネットワーク制御装置（ＲＮＣ）１４と通信し、ＲＮＣは各無線データのセッションに対してシグナリング及びトラフィック処理を提供する。図１はＡＴ１０、ＢＴＳ１２、ＲＮＣ１４を示しており、こうした構成要素間のインターフェースは無線アクセスネットワーク（ＲＡＮ）として知られるものを形成している。ＲＡＮはコアネットワークと通信し、例えばインターネットにアクセスする。図１の例ではコアネットワークはＲＮＣ１４と例えばインターネット（図示せず）との間に接続された１以上のパケットデータサービスノード（ＰＤＳＮ）１６を含んでいる。

一例ではヘッダの圧縮は、ＡＴ１０とＰＤＳＮ１６との間、ＡＴ１０とＲＮＣ１４との間などで行うことができる。ＡＴ１０が例えばＶｏＩＰ呼のようなネットワークと通信を確立すると、アプリケーション層のパケットはＲＴＰ／ＵＤＰ／ＩＰのプロトコルスタックによって運ばれることになる。ＲＴＰ／ＵＤＰ／ＩＰのヘッダは例えば上述のＲｏＨＣアルゴリズムを使用して、ＡＴ１０のコンプレッサによって圧縮される。圧縮されたパケットは、ＢＴＳ１２からＲＮＣ１４へ、さらにＲＮＣ１４からＰＤＳＮ１６へアップリンクに送信される。ＲＮＣ１４又はＰＤＳＮ１６のデコンプレッサはＲｏＨＣヘッダを復元してＲＴＰ／ＵＤＰ／ＩＰのヘッダを再構築する。同様にダウンリンク方向では、ＰＤＳＮ１６及びＲＮＣ１４がパケットを受信し、ＰＤＳＮ１６又はＲＮＣ１４のコンプレッサがＲＴＰ／ＵＤＰ／ＩＰのヘッダを圧縮してＲｏＨＣ即ち圧縮されたヘッダを生成する。圧縮されたヘッダを有するパケットがＢＴＳ１２に送信され、さらにＡＴ１０に送信される。ＡＴ１０のデコンプレッサがＲｏＨＣヘッダを復元して元のＲＴＰ／ＵＤＰ／ＩＰのヘッダを取得し、このパケットをアプリケーション層に渡す。

図２は無線通信ネットワークの別のアーキテクチャ、いわゆるフラットＩＰネットワークアーキテクチャを示している。図のようにＡＴ１０はエアインターフェイスによって基地局（ＢＳ）２０と通信する。このＢＳ２０は複数の移動体ネットワーク要素を単一のエンティティに集中し、シグナリング及びベアラを結合して１つのＩＰ接続にする。このフラットＩＰアーキテクチャではＢＳ２０が無線アクセス技術に基づく機能をすべて含んでいる。言い換えれば図１のＢＴＳ、ＲＮＣ、及びＰＤＳＮの中の機能がＢＳに集中されている。ＢＳ２０はネットワークの中でルータのように機能し、他のＢＳ及びネットワーク要素と通信する。図１と比較すると、別個のＲＮＣ要素及びＰＤＳＮ要素はもはやない。ＢＳはまた、アクセスゲートウェイ２２と通信することができ、アクセスゲートウェイはインターネットのような他のネットワークとの外部接続を行う。

図２のアーキテクチャでは、ＡＴ１０とＢＳ２０との間、又はＡＴ１０とアクセスゲートウェイ２２との間でヘッダの圧縮を行うことができる。ＡＴ１０が例えばＶｏＩＰ呼などのネットワークと通信を確立すると、アプリケーション層のパケットはＲＴＰ／ＵＤＰ／ＩＰのプロトコルスタックによって運ばれることになる。ＲＴＰ／ＵＤＰ／ＩＰのヘッダは例えば上述のＲｏＨＣアルゴリズムを使用して、ＡＴ１０のコンプレッサによって圧縮される。圧縮されたパケットはＡＴ１０からＢＳ２０へ、又はＡＴ１０からＢＳ２０へさらにＢＳ２０からアクセスゲートウェイ２２へ、アップリンクで送信されることになる。ＢＳ２０又はアクセスゲートウェイ２２のデコンプレッサはＲｏＨＣヘッダを復元してＲＴＰ／ＵＤＰ／ＩＰのヘッダを再構築する。同様にダウンリンク方向では、アクセスゲートウェイ２２及びＢＳ２０がパケットを受信し、アクセスゲートウェイ２２又はＢＳ２２のコンプレッサがＲＴＰ／ＵＤＰ／ＩＰのヘッダを圧縮してＲｏＨＣ即ち圧縮されたヘッダを生成する。圧縮されたヘッダを有するパケットはＡＴ１０へ送信される。ＡＴ１０のデコンプレッサがＲｏＨＣヘッダを復元して元のＲＴＰ／ＵＤＰ／ＩＰのヘッダを取得し、このパケットをアプリケーション層に渡す。

ロバストヘッダ圧縮（ＲｏＨＣ）アルゴリズムはそのプロトコルのヘッダの中の動的フィールドの圧縮に、ウィンドウベースの最下位ビット符号化アルゴリズム（ｗｉｎｄｏｗ−ｂａｓｅｄｌｅａｓｔｓｉｇｎｉｆｉｃａｎｔｂｉｔｓｅｎｃｏｄｉｎｇａｌｇｏｒｉｔｈｍ）などの、いくつかの符号化方式を使用する。ＲｏＨＣ圧縮アルゴリズムはまた、フィードバック機構を組み込んでいる。ＲｏＨＣ圧縮アルゴリズムは高いエラー率及び／又は長いラウンドトリップ時間を有する無線リンクにおいて非常に有効である。ＲｏＨＣ圧縮アルゴリズムはその効率性及びロバスト性のために、無線リソースに費用がかかる無線ネットワークにおいて好適である。

リンク層に連続的な大量のパケット損失がある、及び／又は大量のパケットの順序が乱れると、デコンプレッサは新たに受信されたパケットを復元することができない。復元の失敗が起こると、デコンプレッサはそのコンテキストを失うことになる。ヘッダ圧縮セッションのコンテキストはコンプレッサの状態及びデコンプレッサの状態であり、これらの状態はヘッダの復元を成功させるために同期されなければならない。デコンプレッサは通常、コンプレッサにフィードバックパケットを送信し、フルヘッダを送信することによって圧縮のステータスを再同期するようコンプレッサに命令する。デコンプレッサが、圧縮されたヘッダを有する受信されたパケットを、破損していないパケットを含めて廃棄した後に、フルヘッダの情報が圧縮されていないパケットの状態で受信される。その結果、コンプレッサとデコンプレッサとの間の再同期中に、さらなるパケット損失が発生し、呼の性能及び品質を低下させる。コンプレッサとデコンプレッサとの間の同期の損失によって引き起こされるこうしたパケット損失は最小限にされる又は排除されるべきである。

本発明は無線リンクによるヘッダの圧縮／復元を改良することに関する。詳細には、本発明は復元失敗イベント（例えばパケットの損失／エラー又は順序が乱れたパケットの受信）から、コンプレッサとデコンプレッサを再同期することなく回復する際にデコンプレッサを支援する、デコンプレッサにおけるローカルの修復メカニズムを提供する。

一実施形態では、受信された無線リンクプロトコル（ＲＬＰ）のパケットの中のＲＬＰのシーケンス番号と受信されたＲＬＰのパケットから復元されたリアルタイムプロトコル（ＲＴＰ）のパケットの中のＲＴＰのシーケンス番号との間で関係を特定する。圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのシーケンス番号はこの特定された関係及び圧縮されたＲＴＰのパケットを形成する受信されたＲＬＰのパケット又はパケット群のＲＬＰのシーケンス番号のうちの少なくとも１つに基づいて特定される。

別の実施形態では、受信されたＲＬＰのパケットと関連付けられるプロトコルのタイムスタンプと、受信されたＲＬＰのパケットから復元されたＲＴＰのパケットの中のＲＴＰのタイムスタンプとの間で関係を特定する。プロトコルのタイムスタンプはネットワーク要素のインターフェースプロトコル（例えばＢＴＳ／ＲＮＣのインターフェースプロトコル）によって付加されるタイムスタンプである。圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプはこの特定された関係及び圧縮されたＲＴＰのパケットを形成する受信されたＲＬＰのパケット又はパケット群のプロトコルのタイムスタンプの少なくとも１つに基づいて特定される。

さらなる実施形態では、圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプは圧縮されたＲＴＰのパケットを形成する受信されたＲＬＰのパケット又はパケット群の少なくとも１つのプロトコルのタイムスタンプ、前に受信されたＲＬＰのパケットのプロトコルのタイムスタンプ、及び前に受信されたＲＴＰのパケットのＲＴＰのタイムスタンプに基づいて特定される。プロトコルのタイムスタンプは、ネットワーク要素のインターフェースプロトコルによって付加されるタイムスタンプである。

さらに他の実施形態では、ＲＴＰのシーケンス番号と関連付けられるＲＴＰのタイムスタンプとの間で関係が特定され、圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプは、特定されたＲＴＰのシーケンス番号及び特定された関係に基づいて特定される。

さらに他の実施形態では、ネットワーク要素間（例えばＢＴＳとＲＮＣ間）のインターフェースが（例えばＢＳのアーキテクチャにおいて）簡略化され、集中されるとき、上記の実施形態の中のプロトコルのタイムスタンプを使用する代わりに、伝送パケット情報及びローカルのタイミング情報のうちの少なくとも１つから導出されるタイムスタンプを使用することができる。

以下に提供する詳細な説明、及び単に実例として示す添付の図面から、本発明はさらに十分に理解されるようになるであろう。図面では、同じ参照符号が様々な図面の中で対応する部分を表している。

周知の無線通信ネットワークを示す図である。いわゆるフラットＩＰ無線通信ネットワークを示す図である。本発明の一実施形態による、リバースリンクの通信のための無線通信システムの一部のアーキテクチャを示す図である。本発明の一実施形態による、フォワードリンクの通信のための無線通信システムの一部のアーキテクチャを示す図である。

上述の図１を参照すると、無線ネットワークのリンク層によるデータパケットの伝送はＲＡＮにおけるパケットの引渡し及び処理を保証するための情報を含んでいる。例えば、送信側における無線リンクプロトコル（ＲＬＰ）のレイヤはＲｏＨＣパケットをカプセル化し、パケットの引渡しのためにＲＬＰヘッダの中にシーケンス番号（ＳＮ）を与える。シーケンス番号はＲＬＰのパケットの送信ごとに増え、従って受信側で順序が乱れて受信されたパケットを正しく順序付けるためのメカニズムを提供する。このメカニズムを使用して、欠落したデータパケットを認識することも可能である。

さらに、ＢＴＳ１２とＲＮＣ１４との間のバックホール上のインターフェースが、ＲＬＰのパケットをカプセル化するための別のプロトコル（以下「ＢＴＳ／ＲＮＣインターフェースプロトコル」）を加える。より具体的には、ＢＴＳ／ＲＮＣインターフェースプロトコルはＢＴＳとＲＮＣとの間でＲＬＰのパケットが送信されるときに関するタイミング情報（例えばタイプスタンプ）を維持管理する。リバースリンクでは、このタイミング情報はＲＬＰのパケットがＡＴから送信されてＢＴＳによりＲＮＣに渡される伝送時間を表す。フォワードリンクでは、ＢＴＳ／ＲＮＣインターフェースプロトコルの中にタイムスタンプフィールドがあり、ＲＬＰのパケットがＲＮＣで生成された時間を表している。ＢＴＳがパケットを受信すると、ＢＴＳはその伝送スケジューリングの特定の際にこのタイミング情報を利用することができる。

前述の図２を参照すると、ネットワーク要素ＢＴＳ及びＲＮＣが単一の要素ＢＳに集中されるフラットＩＰアーキテクチャでは、機能エンティティＢＴＳとＲＮＣとの間のインターフェースプロトコルを簡略化することができる。プロトコルのタイムスタンプはパケットの伝送時間及びＢＳにおけるローカル時間から導出されるタイムスタンプに置き換えることができる。つまり、プロトコルのタイムスタンプはインターフェースプロトコルのフィールドの中の値の１つであり、ＢＳがＲＯＨＣパケットを生成し、且つＡＴからパケットを受信もするため、ＢＳはこの情報を完全に理解している。フォワードリンクでは、ＢＳはＲＯＨＣパケットが生成されるタイムインスタンスに基づいてタイムスタンプを取得する。リバースリンクでは、ＢＳはＡＴからパケットを受信し、伝送フォーマット及びＭＡＣヘッダ情報に基づいて、パケットがＡＴから送信されるときを正確に知る。プロトコルのタイムスタンプの使用に関する次の説明は図２のフラットＩＰアーキテクチャにおいても導出されるタイムスタンプに同様に適用可能である。

発明者らは各ＲＬＰのパケットが１以上のＲｏＨＣパケットを含むとき、ＲＬＰのＳＮとＲｏＨＣヘッダの中の圧縮されたＲＴＰのＳＮとの間に一意マッピングがあると理解している。さらに、ＲＬＰのパケットがＲｏＨＣパケットの一部を含むとき、ＲＬＰのヘッダの中の「最初のデータ」及び「最後のデータ」のフィールドを使用して完全な上位レイヤのパケットを再構築することができる。言い換えると、ＲＬＰのヘッダの中の「最初のデータ」のフィールドが１に設定されている場合、このＲＬＰのパケットは上位レイヤのパケットの最初の部分を含んでいることを意味する。「最後のデータ」のフィールドが１に設定されている場合、このＲＬＰのパケットは上位レイヤのパケットの最後の部分を含んでいることを意味する。「最初のデータ」と「最後のデータ」の両方のフィールドが１に設定されている場合、このＲＬＰのパケットは完全な上位レイヤのパケットを含んでいることを意味する。こうした様々な場合において、ＲＬＰのＳＮとＲＴＰのＳＮとの間には一意マッピングが存在する。従って、発明者らは、ＲＴＰのＳＮがＲＯＨＣデコンプレッサで正常に復号できない場合、ＲＬＰのＳＮを使用してＲＴＰのＳＮを回復することができると理解している。さらに、ＢＴＳ／ＲＮＣインターフェースプロトコルのタイムスタンプは伝送タイミング情報を表すので、発明者らはＢＴＳ／ＲＮＣインターフェースプロトコルのタイムスタンプはＲＴＰのタイムスタンプと一意の関係を有すると理解している。この関係は特に、ＲＴＰ／ＵＤＰ／ＩＰのパケットがＡＴ１０においてアプリケーション層により生成され、ＲｏＨＣを用いて圧縮され、順次送出されるリバースリンク即ちアップリンクに関する。図２のアーキテクチャでは、導出されるタイムスタンプがＲＴＰのタイムスタンプと一意の関係を有する。

受信されたＲＴＰ／ＵＤＰ／ＩＰのパケットが順序通りである場合、ＲＴＰのタイムスタンプは独特なパターンを有し、ＢＴＳ／ＲＮＣインターフェースプロトコルのヘッダの中のタイムスタンプはＲＴＰのタイムスタンプと相互に関係がある。例えばＶｏＩＰパケットのＲＴＰのタイムスタンプは、一定の間隔（通常２０ｍｓ即ち１６０サンプル）で増える。各ＶｏＩＰパケットの到着時間があまり変化しない場合、ＢＴＳ／ＲＮＣインターフェースプロトコルにおけるタイムスタンプもまた、ほぼ同じ間隔で増える。一般にＲＮＣに到着するＶｏＩＰパケットはネットワークを通過している。各パケットはＲＮＣに到着するとき遅延及び遅延ジッタを経験することになる。一方、各ＶｏＩＰパケットの中のＲＴＰのタイムスタンプは発信元（即ち音声コーデック）で生成されたサンプリング時間を表す。各ＶｏＩＰパケットが同じ遅延を経験せず、ゆえにＶｏＩＰパケット間に遅延ジッタがない場合、ＲＮＣでのパケットの到着時間には、元のＲＴＰのパケットと同じ独特なパターンがない。従って、本発明の諸実施形態による推定法を使用して、ＲＴＰのタイムスタンプとＢＴＳ／ＲＮＣインターフェースプロトコルにおけるタイムスタンプとの間のマッピングを見つけることができる。

ＴＳ_ＲＴＰ１（サンプル数からｍｓに換算）をＲＴＰのパケットのタイムスタンプとし、ＴＳ_{Ｉｎｔｅｒｆａｃｅ１}（単位ｍｓ）をＢＴＳ／ＲＮＣインターフェースプロトコルにおける対応するＲＬＰのパケットのタイムスタンプとする。ＴＳ_ＲＴＰ２（サンプル数からｍｓに換算）を次に続くＲＴＰのパケットのタイムスタンプとし、ＴＳ_{Ｉｎｔｅｒｆａｃｅ２}（単位ｍｓ）をＢＴＳ／ＲＮＣインターフェースプロトコルにおける対応するＲＬＰのパケットのタイムスタンプとする。またＴＳ_{ＲＴＰ＿ｉｎｔｅｒｖａｌ}をＲＴＰのパケット間のタイムスタンプの間隔（即ち２０ｍｓ）とする。インターフェースプロトコルにおけるタイムスタンプとＲＴＰのタイムスタンプとの間のマッピングは次のように特定することができる。

ここでｉｎｔ（）は、１の単位の整数演算である。従って、ＴＳ_ＲＴＰ２が正しく復号できない場合、インターフェースプロトコルにおけるタイムスタンプを使用して、次のようにＴＳ_{ＲＴＰ２＿ｅｓｔｉｍａｔｅｄ}を推定することができる。即ち、

無音圧縮中にＲＴＰのタイムスタンプにジャンプがあるとき、やはり上記の方法を使用してＲＴＰのタイムスタンプを推定することができる。

図２のアーキテクチャでは、プロトコルのタイムスタンプの代わりに導出されたタイムスタンプを使用することによって、同じ方法を適用することができる。

受信したＲＴＰ／ＵＤＰ／ＩＰのパケットの順序が乱れているとき、ＲＯＨＣコンプレッサがＲＮＣにある場合は、ＲＯＨＣコンプレッサがＲＬＰレイヤに再順序付け状態を知らせることができ、インターフェースプロトコルにおけるタイムスタンプを直ちに設定することができる。ＲＯＨＣコンプレッサがＰＤＳＮにある場合は、ＰＤＳＮが再順序付け状態をＲＮＣに渡し、ＲＮＣがこれを直ちに利用できるようにする。従ってＲＯＨＣデコンプレッサがタイムスタンプを正しく復号できない場合、同じ推定法を使用してＲＴＰのタイムスタンプを推定することができる。

次に本発明の諸実施形態について詳細に説明する。まずリバースリンクにおいてリンク層の援助でヘッダの復元を行うアーキテクチャ及び方法の一実施形態について説明する。その後、フォワードリンクにおいてリンク層の援助でヘッダの復元を行うアーキテクチャ及び方法の一実施形態について説明する。単に説明を簡単にするために、図１の無線通信ネットワークで使用されるものとして、これらの実施形態について説明する。しかしながら、本発明のアーキテクチャ及び方法は、この無線システムにも、諸無線システムにも限定されないことを理解されたい。例えば以下の説明は導出されたタイムスタンプがプロトコルのタイムスタンプの代わりに使用される図２のアーキテクチャに適用することもできる。

リバースリンク
図３は、本発明の一実施形態により、リバースリンク即ちアップリンク上で機能するＡＴ１０、ＢＴＳ１２、及びＲＮＣ１４の機能ブロック図を示している。明瞭にするために、当技術分野で周知のＡＴ１０、ＢＴＳ１２、及びＲＮＣ１４の具体的な詳細は示していないことが理解されるであろう。

ＡＴ１０とＢＴＳ１２、ＡＴ１０とＲＮＣ１４、又はＡＴ１０とＰＤＳＮ１６との間に、ロバストヘッダ圧縮（ＲｏＨＣ）のチャネルを確立することができる。リバースリンクについては、コンプレッサ１０４及びデコンプレッサ１４４は、（図３に示すように）それぞれＡＴ１０及びＲＮＣ１４にある場合がある。この実装を使用してこの実施形態を説明する。しかし、この説明はＢＴＳ１２（但しＢＴＳ１２がリンク層の情報を引き出す若しくは生成する）又はＰＤＳＮ１６（但しＲＮＣ１４がリンク層の情報をＰＤＳＮ１６に渡す）にあるデコンプレッサにも同様に適用可能である。

図のようにＡＴ１０は特定のアプリケーションに対してＩＰパケットを生成するアプリケーション層のＩＰジェネレータ１０２を含んでいる。例えばＶｏＩＰ呼はＲＴＰ／ＵＤＰ／ＩＰのパケットにカプセル化された音声フレームからなる。接続を確立すると、アプリケーション層のジェネレータ１０２が、アプリケーション層のパケットを生成し、これがプロトコルスタックを介してＲＴＰ／ＵＤＰ／ＩＰのパケットになる。ヘッダコンプレッサ１０４はこのＲＴＰ／ＵＤＰ／ＩＰのパケットを、例えばＲｏＨＣアルゴリズムを使用してＲｏＨＣパケットに圧縮する。その後リンク層のパケットジェネレータ１０６が、ＲｏＨＣパケットをＲＬＰのパケットに配列することによってリンク層のパケットを生成する。リンク層のジェネレータ１０６は上位層のパケット上で連結又は断片化を行うことができる。この例では、ＲＬＰのパケットは１以上のＲＯＨＣパケットからなる可能性がある。またＲＬＰのパケットは１つのＲＯＨＣパケットの一部のみを含む可能性もある。ＲＬＰのパケットのサイズはＡＴがその時点で使用できる利用可能な伝送速度に基づいて特定される。上述のようにＲＬＰのレイヤはパケットの配信に対してＲＬＰのヘッダに独自のＳＮを与え、欠落したデータパケットを認識するメカニズムを提供する。

ＢＴＳ１２はＲＬＰのパケットを受信し、インターフェースプロトコル１０８がＲＬＰのパケットにヘッダを付加する。より具体的には、ＢＴＳ／ＲＮＣインターフェースプロトコル１０８がＲＬＰのパケットをカプセル化し、このインターフェースプロトコルのパケットのヘッダにはＡＴ１０におけるＲＬＰのパケットの伝送タイミング情報を表すパケットＩＤ（又はタイムスタンプ）が含まれている。ＢＴＳ１２はＲＬＰのパケットをＲＮＣ１４又はＰＤＳＮ１６（図示せず）に渡して復元する。システムの設計により、ＲＬＰ及びインターフェースプロトコルに加えて他のプロトコルを追加することも可能である。

ＲＮＣ１４はＲＬＰ処理モジュール１４２及びデコンプレッサ１４４を含んでいる。ＲＬＰ処理モジュール１４２は、ＲＬＰのパケットを受信し、そこからＲＴＰ／ＵＤＰ／ＩＰのパケットを取得し、ＲＴＰ／ＵＤＰ／ＩＰのパケットと共にＲＬＰのＳＮ及び伝送タイミング情報（以後同義で「リンク層の情報」と呼ぶ）をデコンプレッサ１４４に渡す。

デコンプレッサ１４４は、例えばＲＯＨＣアルゴリズムにより、周知の方法でＲＴＰ／ＵＤＰ／ＩＰのパケットを復元する。復元の結果、デコンプレッサ１４４は、特にＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを取得する。デコンプレッサ１４４はＲＬＰのシーケンス番号をＲＴＰのシーケンス番号にマップし、またＢＴＳ／ＲＮＣインターフェースプロトコルのタイミング情報をＲＴＰのタイムスタンプにマップする。例えば３つの連続するパケットについては、ＲＬＰのシーケンス番号は２０、２１、及び２２とすることができ、関連付けられる３つのＲＴＰのシーケンス番号は８、９、及び１０とすることができる。従って、以下の表１に示すように、ＲＬＰのシーケンス番号２０はＲＴＰのシーケンス番号８にマップされ（例えば関連付けて格納される）、ＲＬＰのシーケンス番号２１はＲＴＰのシーケンス番号９にマップされるなどとなる。

或いは、ＲＬＰ及びＲＴＰのシーケンス番号が一定量ずつ増え、関連したＲＬＰのシーケンス番号とＲＴＰのシーケンス番号との間に同じ一定のオフセットが存在する場合、デコンプレッサ１４４はこのオフセット量を代わりに又は加えて格納することができる。

上位層のＲＯＨＣパケットが複数のＲＬＰのパケットに断片化される場合、ＲＬＰヘッダの中の「最初のデータ」及び「最後のデータ」のフィールドを使用して、ＲＯＨＣパケットのフレームの境界（最初の部分及び最後の部分）を特定することができる。例えば、６つの連続するパケットについては、ＲＬＰのシーケンス番号は２０、２１、２２、２３、２４、及び２５とすることができる。ＲＬＰのパケット２０の中の「最初のデータ」のフィールドは１であるが、「最後のデータ」のフィールドは０である。これはＲＬＰのパケット２０がＲＯＨＣのパケットの最初の部分であることを示す。ＲＬＰのパケット２１の中の「最初のデータ」及び「最後のデータ」は共に０である。ＲＬＰのパケット２２の中の「最初のデータ」はゼロであり、ＲＬＰのパケット２２の中の「最後のデータ」は１である。従って、ＲＬＰのパケット２０、２１、及び２２が完全なＲＯＨＣパケットを形成し、対応するＲＴＰのＳＮは８である。ＲＬＰのパケット２３の中の「最初のデータ」のフィールドは再び１となり、別の上位レイヤのパケットの開始を示している。従って、以下の表２に示すように、ＲＬＰのシーケンス番号２０はＲＴＰのシーケンス番号８にマップされ（例えば関連付けて格納される）、ＲＬＰのシーケンス番号２３はＲＴＰのシーケンス番号９にマップされるなどとなる。

この例では、ＲＬＰのＳＮからＲＴＰのＳＮへのマッピングは一意であるが、３対１のマッピングである。

インターフェースプロトコルのタイミング情報及びＲＴＰのタイムスタンプはＲＬＰからＲＴＰへのシーケンス番号のマッピングと同様の方法でマップされる。

無線リンク上でエラーを有するパケット及び／又はパケットの損失が多くあるとき、ＲＬＰ処理モジュール１４２は破損したパケットをデコンプレッサ１４４に渡すことなくこれらを廃棄する。またパケットは無線リンク上で順序が乱れて受信される。

最終的にパケットは再び正常に受信されることが可能である。正常に受信されたパケットはＲＬＰ処理モジュール１４２によってデコンプレッサ１４４に渡されることになる。しかし、復元失敗イベント（例えばパケットの損失／エラー又は順序の乱れたパケットの受信）のために、デコンプレッサ１４４が、受信されたパケットを復元できない場合がある。この結果、復元の失敗が生じる。このようなことが起こると、デコンプレッサ１４４はリンク層の情報を使用してローカルの修復メカニズムを呼び出し、復元の失敗を発生させた原因の受信されたパケットを復元しようと試みる。

修復メカニズムは復元の失敗を引き起こしているパケットのＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを特定することを含んでいる。このＲＴＰのシーケンス番号を特定するために、デコンプレッサ１４４はこのパケットのＲＬＰのシーケンス番号、及びＲＬＰからＲＴＰへのシーケンス番号のマップを使用する。上記表１のＲＬＰからＲＴＰへのシーケンス番号のマップを使用して、ＲＴＰのシーケンス番号の修復動作の一例を説明する。受信されたパケットのＲＬＰのシーケンス番号が２５である場合、デコンプレッサ１４４はシーケンス番号２３及び２４を有するＲＬＰのパケットが欠落したと認識する。またデコンプレッサ１４４はこの欠落したパケットのＲＴＰのシーケンス番号は１１及び１２であったであろうと判断する。これは表１に示されたシーケンスに従っている。従ってデコンプレッサ１４４は２５をＲＬＰのシーケンス番号とする受信されたパケットのＲＴＰのシーケンス番号として１３を特定する。

或いは又はさらにデコンプレッサ１４４はＲＬＰからＲＴＰへのマッピングのオフセットを特定した場合がある。表１の例では、このオフセットは−１２となる。従ってこのマッピングのオフセットを使用すると、２５というＲＬＰのシーケンス番号はＲＴＰシーケンス番号１３（＝２５＋（−１２））にマップされる。

同様にしてデコンプレッサ１４４はＢＴＳ／ＲＮＣタイミング情報からＲＴＰのタイムスタンプを特定することもできる。例えば表３は（４スロット単位即ち６．６７ｍｓ中の）インターフェースプロトコルにおけるパケットＩＤ（又はタイムスタンプ）の値、対応する伝送時間（単位ｍｓ）、（サンプル単位の）ＲＴＰのタイムスタンプ値、及び対応するサンプリング時間を示している。

伝送時間はＲＴＰのタイムスタンプと相互に関連付けることができる。この例では、伝送時間は２０ｍｓのオフセットによりＲＴＰのパケットのサンプリング時間にマップされ、即ち４０ｍｓは２０ｍｓにマップされる。欠落したパケットがある場合、デコンプレッサ１４４はパケットを正常に復元することができない。次に正常に受信されたパケットが２４というＩＤを有すると仮定すると、デコンプレッサ１４４は、まずパケットＩＤの値２４を１６０ｍｓ（即ち２４＊６．６７＝１６０ｍｓ）の伝送時間にマップし、次に１６０ｍｓを１４０ｍｓ（即ち１６０−２０＝１４０ｍｓ）のＲＴＰのサンプリング時間にマップし、最後にこのＲＴＰのサンプリング時間をＲＴＰのタイムスタンプ値として１１２０（即ち１４０＊８＝１１２０）にマップすることができる。

表３に関する例は、パケットがエンコーダで生成されてトランスミッタに渡された後に、ＡＴにおける各パケットの伝送時間が同じ遅延を経験すると仮定する。しかし、これは保証されず、しばしば非常に小さい遅延及び遅延変動が存在する可能性がある。従って代わりに上記で詳細に説明したように、式（２）の推定方法を使用して、ＢＴＳ／ＲＮＣインターフェースプロトコルのタイムスタンプからＲＴＰのタイムスタンプを特定することができる。一例として表４は表３中のものと同じＲＴＰのタイムスタンプ及び対応するサンプリング時間を示している。しかしながらパケットＩＤ及び対応する伝送時間はいくつかの遅延変動を有する。パケットＩＤ６は４０ｍｓ（６＊６．６７ｍｓ＝４０ｍｓ）という伝送時間に対応する。次のＲＴＰのパケットのパケットＩＤは１０であり、６６．７ｍｓの伝送時間に対応する。またパケットＩＤ１２は、８０ｍｓという伝送時間に対応する。連続したパケット間の伝送時間の間隔はＲＴＰのＴＳで表されるように正確に２０ｍｓではない。しかし、伝送時間はやはり式（２）の推定方法を使用して、ＲＴＰのタイムスタンプと相互に関連付けることができる。

この例では、欠落したパケットがある場合、デコンプレッサ１４４はパケットを正常に復元することができない。次に正常に受信されたパケットが２３というＩＤを有すると仮定すると、デコンプレッサ１４４は、まずパケットＩＤの値２３を１５３．３３ｍｓ（即ち２３＊６．６７＝１５３．３３ｍｓ）の伝送時間にマップし、次に式（２）を使用してパケットＩＤ１２から推定されたＲＴＰのサンプリング時間、即ち６０＋ｉｎｔ（（１５３．３３−８０）／２０，１）＊２０＝１４０ｍｓを取得することができる。そして次にこのＲＴＰのサンプリング時間をＲＴＰのタイムスタンプ値として１１２０（即ち１４０＊８＝１１２０）にマップする。

この修復動作を行うとデコンプレッサ１４４は、特定されたＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを受信されたパケットの復元後のＲＴＰのシーケンス番号及びタイムスタンプとして使用する。次にデコンプレッサ１４４はＲＯＨＣヘッダの中のＣＲＣ（巡回冗長検査）を使用してエラーの検出を行う。正常である場合、デコンプレッサ１４４は後続パケットの復元を継続し、復元の失敗を回避することになる。その結果デコンプレッサ１４４はコンプレッサ１０４にフルヘッダを送信することによって圧縮ステータスを再同期するよう命令するフィードバックパケットをコンプレッサ１０４に送信する必要がなくなる。またデコンプレッサ１４４はフルヘッダ情報が圧縮されていないパケット状態で受信されるまで、圧縮されたヘッダを有する受信されたパケットを、破損していないパケットを含めて廃棄しなければならないことも避けられる。

フォワードリンク
上記の詳細な説明はリバースリンクにおける圧縮及び復元に関するものであったが、上述の本発明の方法はフォワードリンクにも適用可能である。図４は、本発明の一実施形態により、フォワードリンク即ちダウンリンク上で機能するＡＴ１０、ＢＴＳ１２、及びＲＮＣ１４の機能ブロック図を示している。当技術分野で周知のＡＴ１０、ＢＴＳ１２、及びＲＮＣ１４の特定の詳細（例えばＲＴＰ／ＵＤＰ／ＩＰのプロトコルスタックなど）については、明瞭にするために示していないことを理解されたい。

ＡＴ１０とＢＴＳ１２、ＡＴ１０とＲＮＣ１４、又はＡＴ１０とＰＤＳＮ１６との間に、ロバストヘッダ圧縮（ＲｏＨＣ）のチャネルを確立することができる。フォワードリンクについては、コンプレッサ２０４及びデコンプレッサ２４４は（図４に示すように）それぞれＲＮＣ１４及びＡＴ１０にある場合がある。この実装を使用して、この実施形態について説明する。しかし、この説明はＢＴＳ１２又はＰＤＳＮ１６にあるコンプレッサにも同様に適用可能である。

図のようにＲＮＣ１４は特定のアプリケーションに対してＩＰパケットを生成するアプリケーション層のＩＰジェネレータ２０２を含んでいる。例えばＶｏＩＰ呼はＲＴＰ／ＵＤＰ／ＩＰのパケットにカプセル化された音声フレームからなる。接続が確立するとアプリケーション層のジェネレータ２０２はアプリケーション層のパケットを生成し、これがプロトコルスタックを介してＲＴＰ／ＵＤＰ／ＩＰのパケットになる。ヘッダコンプレッサ２０４はこのＲＴＰ／ＵＤＰ／ＩＰのパケットを、例えばＲｏＨＣアルゴリズムを使用してＲｏＨＣパケットに圧縮する。続いてリンク層のパケットジェネレータ２０６が、各ＲｏＨＣパケットをＲＬＰのパケットに配列することによってリンク層のパケットを生成する。上述のようにＲＬＰのレイヤはパケットの配信に対してＲＬＰのヘッダに独自のＳＮを与え、欠落したデータパケットを認識するメカニズムを提供する。さらに、フォワードリンクに関連して触れたように、ＲｏＨＣパケットを２つ以上のＲＬＰのパケットに断片化することができる。

ＲＮＣにおけるＢＴＳ／ＲＮＣインターフェースプロトコル２０８はＲＬＰのパケットをＢＴＳに送信する前にＲＬＰのパケットにインターフェースプロトコルのヘッダを付加する。より具体的には、ＢＴＳ／ＲＮＣインターフェースプロトコルはＲＬＰのパケットをカプセル化し、インターフェースプロトコルのパケットのヘッダには、ＲＬＰのパケットの伝送タイミング情報を表すシーケンス番号が含まれる。ＢＴＳ１２はＢＴＳ／ＲＮＣインターフェースプロトコルのヘッダを除去し、ＲＬＰのパケットをＡＴ１０に渡して復元する。システムの設計により、ＲＬＰ及びインターフェースプロトコルに加えて他のプロトコルを追加することも可能である。

ＡＴ１０はＲＬＰ処理モジュール２４２及びデコンプレッサ２４４を含んでいる。ＲＬＰ処理モジュール２４２はＲＬＰのパケットを受信し、そこからＲＴＰ／ＵＤＰ／ＩＰのパケットを取得し、ＲＴＰ／ＵＤＰ／ＩＰのパケットと共にＲＬＰのＳＮ及び伝送タイミング情報（以後同義で「リンク層の情報」と呼ぶ）をデコンプレッサ２４４に渡す。

デコンプレッサ２４４は、例えばＲＯＨＣアルゴリズムにより、周知の方法でＲＴＰ／ＵＤＰ／ＩＰのパケットを復元する。復元の結果、デコンプレッサ２４４は特にＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを取得する。デコンプレッサ２４４はリバースリンクに関して詳細に上述した同じ方法で、ＲＬＰのシーケンス番号をＲＴＰのシーケンス番号にマップし、ＢＴＳ／ＲＮＣインターフェースプロトコルのタイミング情報をＲＴＰのタイムスタンプにマップする。

デコンプレッサ２４４において復元失敗イベントが発生すると、デコンプレッサ２４４はＲＴＰのタイムスタンプの特定以外はリバースリンクに関して上述した同じ方法でローカルの修復メカニズムを実行する。

ＢＴＳ／ＲＮＣインターフェースプロトコルのヘッダはＲＬＰのパケットと共にＢＴＳからＡＴへ送信されない。従って、ＢＴＳ／ＲＮＣインターフェースプロトコルのタイミング情報はローカルの修復メカニズムにおいてＡＴが利用できない。

一実施形態では、このタイミング情報はＢＴＳ／ＲＮＣインターフェースプロトコルのヘッダの中ではないが、ＡＴに送信されることが可能である。例えば、このタイミング情報は付加的なシグナリングを介してＢＴＳによりＡＴに送信されることが可能であり、ＲＬＰのヘッダの中に付加的なフィールドを備えるか、又は付加的なメッセージを別個にＡＴに送信する。

別の実施形態では、ＲＴＰのタイムスタンプ（ＴＳ）は修復されたＲＴＰのシーケンス番号（ＳＮ）を用いて推測される。ＲＴＰのタイムスタンプはＲＴＰのパケットのペイロードを生成するために使用されるサンプルの数を識別するために定義される。ＲＴＰのパケットが一定のサンプリング間隔に対応するペイロードを運び、サンプルレートが一定であるとき、ＴＳとＳＮとの間には一意マッピングがある。例えば、従来の音声については、８ｋＨｚの一定のサンプリングレートが使用されることが多い。音声のペイロードは２０ｍｓごとに生成される。これは連続パケットについてはＲＴＰのＴＳの領域が１６０増加することに等しい。言い換えれば、会話区間（ｔａｌｋｓｐｕｒｔ）（無音抑制（ｓｉｌｅｎｃｅｓｕｐｐｒｅｓｓｉｏｎ）が適用されない）の間に、ＲＴＮのＳＮ番号は１だけ増加し、ＴＳは１６０だけ増加する。この場合、ＲＴＰのＳＮを回復する方法から間接的にＴＳを回復することができる。

理解されるであろうが、提供したシステム及び方法によるローカルの修復メカニズムはコンプレッサとデコンプレッサとの間で復元の失敗及び／又は再同期を減少させることができる。

本発明を上記のように説明しているが、同様のものを様々に変更することが可能であることは明らかであろう。このような変形形態は本発明からの逸脱とみなされてはならず、このような変更形態はすべて本発明の範囲内に含まれるものとする。

Claims

方法であって、
受信された無線リンクプロトコル（ＲＬＰ）のパケットの中のＲＬＰのシーケンス番号と受信されたＲＬＰのパケットから復元されたリアルタイムプロトコル（ＲＴＰ）のパケットの中のＲＴＰのシーケンス番号との間で関係を特定するステップ、及び
前記特定された関係、及び前記圧縮されたＲＴＰのパケットを形成する前記受信されたＲＬＰのパケット又はパケット群の前記ＲＬＰのシーケンス番号のうちの少なくとも１つに基づいて、前記圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのシーケンス番号を特定するステップ
からなる方法。
請求項１の方法において、
前記関係を特定するステップが、ＲＬＰのシーケンス番号をＲＴＰのシーケンス番号にマッピングするステップを含み、
前記ＲＴＰのシーケンス番号を特定するステップが、前記ＲＬＰからＲＴＰへのマップ、及び前記圧縮されたＲＴＰのパケットを形成している前記受信されたＲＬＰのパケット又はパケット群の少なくとも１つのＲＬＰのシーケンス番号に基づいて、前記ＲＴＰのシーケンス番号を特定する方法。
請求項１の方法において、
前記関係を特定するステップが、ＲＬＰのシーケンス番号とＲＴＰのシーケンス番号との間のオフセットを特定するステップを含み、
前記ＲＴＰのシーケンス番号を特定するステップが、前記圧縮されたＲＴＰのパケットを形成している前記受信されたＲＬＰのパケット群の前記少なくとも１つのＲＬＰのシーケンス番号に前記オフセットを付加することによって、前記ＲＴＰのシーケンス番号を特定する方法。
請求項１の方法において、前記ＲＴＰのシーケンス番号を特定するステップが、復元失敗イベントの後にＲＬＰのパケットが正常に受信される場合に行われる方法。
請求項１の方法であって、さらに、
受信されたＲＬＰのパケットと関連付けられる、ネットワーク要素のインターフェースプロトコルによって付加されるタイムスタンプであるプロトコルのタイムスタンプと、前記受信されたＲＬＰのパケットから復元されたＲＴＰのパケットの中のＲＴＰのタイムスタンプとの間で関係を特定するステップ、及び
ｉ）前記プロトコルのタイムスタンプと前記ＲＴＰのタイムスタンプとの間の前記特定された関係、及びｉｉ）前記圧縮されたＲＴＰのパケットを形成する前記受信されたＲＬＰのパケット又はパケット群と関連付けられる前記プロトコルのタイムスタンプのうちの少なくとも１つ、に基づいて、前記圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプを特定するステップ
を備える方法。
請求項１の方法であって、さらに、
前記圧縮されたＲＴＰのパケットを形成する前記受信されたＲＬＰのパケット又はパケット群の少なくとも１つのプロトコルのタイムスタンプ、前に受信されたＲＬＰのパケットのプロトコルのタイムスタンプ、及び前に受信されたＲＴＰのパケットのＲＴＰのタイムスタンプに基づいて、前記圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプを特定するステップを備え、
前記プロトコルのタイムスタンプが、ネットワーク要素のインターフェースプロトコルによって付加されるタイムスタンプである方法。
方法であって、
受信された無線リンクプロトコル（ＲＬＰ）のパケットと関連付けられる、ネットワーク要素のインターフェースプロトコルによって付加されるタイムスタンプであるプロトコルのタイムスタンプと、前記受信されたＲＬＰのパケットから復元されたＲＴＰのパケットの中のリアルタイムプロトコル（ＲＴＰ）のタイムスタンプとの間で関係を特定するステップ、及び
前記特定された関係、及び前記圧縮されたＲＴＰのパケットを形成する前記受信されたＲＬＰのパケット又はパケット群の前記プロトコルのタイムスタンプのうちの少なくとも１つに基づいて、前記圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプを特定するステップ
からなる方法。
方法であって、
圧縮されたリアルタイムプロトコル（ＲＴＰ）のパケットを形成する受信された無線リンクプロトコル（ＲＬＰ）のパケット又はパケット群の少なくとも１つのプロトコルのタイムスタンプ、前に受信されたＲＬＰのパケットのプロトコルのタイムスタンプ、及び前に受信されたＲＴＰのパケットのＲＴＰのタイムスタンプに基づいて、前記圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプを特定するステップからなり、
前記プロトコルのタイムスタンプが、ネットワーク要素のインターフェースプロトコルによって付加されるタイムスタンプである方法。
方法であって、
受信された無線リンクプロトコル（ＲＬＰ）のパケットに関する伝送タイミング情報、及び前記受信されるＲＬＰのパケットを受信する基地局におけるローカルタイミング情報のうちの少なくとも１つに基づいてタイムスタンプを導出するステップ、
前記受信されたＲＬＰのパケットと関連付けられる前記導出されたタイムスタンプと、前記受信されたＲＬＰのパケットから復元されたリアルタイムプロトコル（ＲＴＰ）のパケットの中のＲＴＰのタイムスタンプとの間で関係を特定するステップ、及び
前記特定された関係、及び前記圧縮されたＲＴＰのパケットを形成する前記受信されたＲＬＰのパケット又はパケット群の前記導出されたタイムスタンプのうちの少なくとも１つに基づいて、前記圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプを特定するステップ
からなる方法。
方法であって、
受信された無線リンクプロトコル（ＲＬＰ）のパケットに関する伝送タイミング情報、及び前記受信されるＲＬＰのパケットを受信する基地局におけるローカルタイミング情報のうちの少なくとも１つに基づいてタイムスタンプを導出するステップ、及び
圧縮されたリアルタイムプロトコル（ＲＴＰ）のパケットを形成する前記受信されたＲＬＰのパケット又はパケット群の少なくとも１つの導出されたタイムスタンプ、前に受信されたＲＬＰのパケットの前記導出されたタイムスタンプ、及び前に受信されたＲＴＰのパケットのＲＴＰのタイムスタンプに基づいて、前記圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプを特定するステップ
からなる方法。