(57)【要約】  無線通信システムにおいてデータフレームを伝送するための方法は、ウィンドウ開始（ＷＳ）およびウィンドウ終了（ＷＥ）を含む着信時刻（ＴＯＡ）ウィンドウを作成することによって開始される。伝送するためのエアインターフェースにおけるこのデータフレームのＴＯＡが決定され、このデータフレームがこのＴＯＡウィンドウに対して相対的にいつ到着するかに応じて、さらなるアクションが取られる。このＴＯＡがこのＷＳより前にある場合、このデータフレームはバッファされる。このＴＯＡがこのＴＯＡウィンドウ内にある場合に、このデータフレームは伝送される。このＴＯＡがこのＷＥの後にある場合には、このデータフレームは切り捨てられる。
2007525080.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システム中でデータフレームを伝送するための方法であって、
ウィンドウ開始（ＷＳ）およびウィンドウ終了（ＷＥ）を含む着信時刻（ＴＯＡ）ウィンドウを作成するステップと、
伝送するためのエアインターフェースにおいて前記データフレームの前記ＴＯＡを決定するステップと、
前記ＴＯＡが前記ＷＳより前にある場合、前記データフレームをバッファするステップと、
前記ＴＯＡが前記ＴＯＡウィンドウ内にある場合に、前記データフレームを伝送するステップと、
前記ＴＯＡが前記ＷＥの後にある場合には、前記データフレームを切り捨てるステップと
を具えたことを特徴とする方法。
【請求項２】
前記バッファするステップは、バッファが前記データフレームを記憶するのに十分に大きい場合にしか実行されないことを特徴とする請求項１記載の方法。
【請求項３】
バッファサイズは、少なくともＷＳ値にＷＥ値を加えたものの総和と同程度の大きさであり、総和は、伝送時間間隔値によって除算されることを特徴とする請求項２記載の方法。
【請求項４】
長さＷＥのマージンは、前記マージン中にＴＯＡを有するデータフレームが伝送されるように前記ＷＥの後に存在することを特徴とする請求項１記載の方法。
【請求項５】
前記決定するステップは、
前記データフレームが伝送されると想定されるスケジュールされた時刻を取得するステップと、
前記データフレームの処理時間を推定するステップと
を含み、前記ＴＯＡは、式、すなわち
ＴＯＡ＝（スケジュールされた時刻−処理時間−ＷＥ）−現行の時刻
から決定されることを特徴とする請求項１記載の方法。
【請求項６】
前記データフレームが関連するシステムフレーム番号（ＳＦＮ）を有する場合、次いで前記ＴＯＡは、式、すなわち
ＴＯＡ＝（スケジュールされたＳＦＮｔｉｍｅ−処理時間−ＷＥ）−現行のＳＦＮｔｉｍｅ
から決定され、式中で前記スケジュールされたＳＦＮｔｉｍｅは、前記ＳＦＮが最初に伝送すべきようにスケジュールされた時刻であり、前記現行のＳＦＮｔｉｍｅは、現行のＳＦＮの時刻であることを特徴とする請求項５記載の方法。
【請求項７】
前記データフレームが関連する接続フレーム番号（ＣＦＮ）を有する場合、次いで前記ＴＯＡは、式、すなわち
ＴＯＡ＝（スケジュールされたＣＦＮｔｉｍｅ−処理時間−ＷＥ）−現行のＣＦＮｔｉｍｅ
から決定され、式中で前記スケジュールされたＣＦＮｔｉｍｅは、前記ＣＦＮが最初に伝送すべきようにスケジュールされた時刻であり、前記現行のＣＦＮｔｉｍｅは、現行のＣＦＮの時刻であることを特徴とする請求項５記載の方法。
【請求項８】
前記計算されたＴＯＡ値を評価するステップと、
前記ＴＯＡ値が所定の範囲外にある場合に、前記ＴＯＡ値を調整するステップと
をさらに具えたことを特徴とする請求項５記載の方法。
【請求項９】
無線通信システム中で伝送するためにデータフレームのタイミングを調整する方法であって、
前記データフレームについての着信時刻（ＴＯＡ）値を含むタイミング調整制御フレームを受信するステップと、
前記ＴＯＡ値に基づいてオフセット値を計算するステップと、
前記データフレームについてのターゲット接続フレーム番号（ＣＦＮ）を取得するステップと、
前記ターゲットＣＦＮに対して前記オフセット値を適用して、調整されたＣＦＮを取得するステップと、
前記調整されたＣＦＮの時刻に対応する時刻に前記データフレームを伝送するステップと
を具えたことを特徴とする方法。
【請求項１０】
後続のデータフレームについてのターゲットＣＦＮ値に前記オフセット値を適用するステップをさらに具えたことを特徴とする請求項９記載の方法。
【請求項１１】
前記オフセット値に対して追加の調整を適用して、サービス品質特性を補償するステップをさらに具えたことを特徴とする請求項９記載の方法。
【請求項１２】
無線通信システム中のデータフレームについてのターゲット接続フレーム番号（ＣＦＮ）を計算するための方法であって、
（ａ）前記無線通信システム中の制御フレームの伝送遅延に関連した統計値を収集するステップと、
（ｂ）前記統計値に基づいてベースＣＦＮを計算するステップと、
（ｃ）前記制御フレームについての着信時刻（ＴＯＡ）値を決定するステップと、
（ｄ）前記ＴＯＡ値に基づいてオフセット値を計算するステップと、
（ｅ）前記ベースＣＦＮおよび前記オフセット値に基づいて前記ターゲットＣＦＮを計算するステップと
を具えたことを特徴とする方法。
【請求項１３】
ステップ（ｃ）は、複数の制御フレームに基づいて平均ＴＯＡ値を決定するステップを含むことを特徴とする請求項１２記載の方法。
【請求項１４】
前記ターゲットＣＦＮを使用して、所定のＴＯＡウィンドウ内の前記データフレームを伝送することを特徴とする請求項１２記載の方法。
【請求項１５】
ステップ（ｄ）は、前記ＴＯＡウィンドウの終了をターゲットにする前記オフセット値を計算するステップを含むことを特徴とする請求項１４記載の方法。
【請求項１６】
ステップ（ｄ）は、前記ＴＯＡウィンドウの中間をターゲットにする前記オフセット値を計算するステップを含むことを特徴とする請求項１４記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に無線通信におけるダウンリンクデータ伝送同期化戦略に関し、より詳細には、無線アクセスネットワークにおけるダウンリンクデータ伝送同期化およびデータバッファサイジングのためのアルゴリズムに関する。
【背景技術】
【０００２】
無線リンク伝送は、同期通信である。フレームオフセットの使用を介して、Ｓ−ＲＮＣ（ｓｅｒｖｉｎｇ  ｒａｄｉｏ  ｎｅｔｗｏｒｋ  ｃｏｎｔｒｏｌｌｅｒサービング無線ネットワーク制御装置）は、時間基準（ｔｉｍｅ  ｒｅｆｅｒｅｎｃｅ）としての機能を果たす、ＢＣＨ（ｂｒｏａｄｃａｓｔ  ｃｈａｎｎｅｌブロードキャストチャネル）に対する伝送データについての時系列を確立する。ＣＦＮ（ｃｏｎｎｅｃｔｉｏｎ  ｆｒａｍｅ  ｎｕｍｂｅｒ接続フレーム番号）は、エアインターフェース（ａｉｒ  ｉｎｔｅｒｆａｃｅ）上を伝送されることはない。その代わりに、この接続フレーム番号は、Ｌ１フレームカウンタおよびフレームオフセットを使用することにより、ＳＦＮ（ｓｙｓｔｅｍ  ｆｒａｍｅ  ｎｕｍｂｅｒシステムフレーム番号）に対してＬ１（エアインターフェース）によってマッピングされる。このＳＦＮは、このＢＣＨ中でＬ１によってブロードキャストされる。
【０００３】
【非特許文献１】ＴＳ  ２５．４３３，  ３ＧＰＰ  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ：  ＵＴＲＡＮ  Ｉｕｂ  Ｉｎｔｅｒｆａｃｅ  ＮＢＡＰ  Ｓｉｇｎａｌｉｎｇ，  ｓｅｃｔｉｏｎ  ９．２．１．６１
【非特許文献２】ＴＳ  ２５．４３３，  ３ＧＰＰ  Ｔｅｃｈｎｉｃａｌ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｇｒｏｕｐ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ：  ＵＴＲＡＮ  Ｉｕｂ  Ｉｎｔｅｒｆａｃｅ  ＮＢＡＰ  Ｓｉｇｎａｌｉｎｇ，  ｓｅｃｔｉｏｎ  ９．２．１．６０
【発明の開示】
【発明が解決しようとする課題】
【０００４】
データフレームは、特定のＣＦＮにおける伝送に間に合うようにＬ１において使用可能である必要がある。これには、各ネットワークノード、およびそこでのネットワークノード間のデータパス上の伝送リンクについての正確で協調したタイミングが必要になる。
【０００５】
ダウンリンクデータ伝送を取り扱い、この伝送同期化に関連したデータバッファのサイズを最適に決めるためのシステムおよび方法を提供することが望ましい。
【課題を解決するための手段】
【０００６】
本発明は、一般にＲＡＮ（ｒａｄｉｏ  ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ無線アクセスネットワーク）中における、特にＵＭＴＳ（ｕｎｉｖｅｒｓａｌ  ｍｏｂｉｌｅ  ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ｓｙｓｔｅｍユニバーサル移動通信システム）中の無線アクセスネットワーク中におけるダウンリンクデータ伝送同期化と、それに関連したバッファサイジングについての方法を提供している。本発明は、他の伝送システムにも適用可能である。本発明は、厳格なＴＯＡ（ｔｉｍｅ  ｏｆ  ａｒｒｉｖａｌ着信時刻）のパラメータ、厳格なバッファサイズ、タイミング調整を介したダウンリンクデータ伝送のタイミング微調整、ならびにＱｏＳ（ｑｕａｌｉｔｙ  ｏｆ  ｓｅｒｖｉｃｅサービス品質）入力を使用したＲＦＮ（ｒａｄｉｏ  ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ  ｆｒａｍｅ  ｎｕｍｂｅｒ無線アクセスネットワークフレーム番号）／接続フレーム番号（ＣＦＮ）のオフセット調整についての高度なアプローチを取り扱う。
【０００７】
本発明は、データの脱落と、それに関連したＱｏＳの悪化を回避することを目指したダウンリンクデータ伝送同期処理のための簡単で効率的な実装戦略を提供している。トランスポートベアラセットアップ（ｔｒａｎｓｐｏｒｔ  ｂｅａｒｅｒ  ｓｅｔｕｐ）におけるターゲットＣＦＮ初期化と、後続の時間調整処理についての対処が行われる。効果的なＴＯＡウィンドウパラメータ設定と、バッファ設計判断基準と、ラップアラウンド制約条件を伴うＴＯＡ計算法実装形態が提供される。さらに、ＱｏＳ入力を使用したＲＦＮ／ＣＦＮオフセット調整、ＴＯＡサンプリング、トランスポートベアラ多重化、および処理能力多重化情報についての高度なアプローチが提示される。時間的整合プロシージャを使用したＲＦＮ／ＣＦＮオフセットの微調整がカバーされる。
【０００８】
無線通信システム中においてデータフレームを伝送するための方法は、ＷＳ（ｗｉｎｄｏｗ  ｓｔａｒｔウィンドウ開始）およびＷＥ（ｗｉｎｄｏｗ  ｅｎｄウィンドウ終了）を含む着信時刻（ＴＯＡ）ウィンドウを作成することによって開始される。伝送するためのエアインターフェースにおけるデータフレームのＴＯＡが決定され、このデータフレームがこのＴＯＡウィンドウに対して相対的にいつ到着するかに応じてさらなるアクションが取られる。このデータフレームは、すなわち（１）このＴＯＡがこのＷＳよりも以前にある場合にバッファされ、（２）このＴＯＡがこのＴＯＡウィンドウ内にある場合に伝送され、（３）このＴＯＡがこのＷＥの後にある場合には切り捨てられる。
【０００９】
無線通信システム中において伝送するためのデータフレームのタイミングを調整する方法は、このデータフレームについての着信時刻（ＴＯＡ）値を含むタイミング調整制御フレームを受信することによって開始される。このＴＯＡ値に基づいたオフセット値が計算される。このデータフレームについてのターゲット接続フレーム番号（ＣＦＮ）が取得され、このオフセット値がこのターゲットＣＦＮに適用されて、調整されたＣＦＮが取得される。このデータフレームは、この調整されたＣＦＮの時刻に対応する時刻に送信される。
【００１０】
本発明のさらに詳細な理解は、例として提供され、添付図面と併せて理解すべき好ましい実施形態についての以下の説明から得ることができよう。
【発明を実施するための最良の形態】
【００１１】
以下では、ＷＴＲＵ（ｗｉｒｅｌｅｓｓ  ｔｒａｎｓｍｉｔ／ｒｅｃｅｉｖｅ  ｕｎｉｔ無線送信／受信ユニット）は、それだけには限定されないが、無線環境中で動作することが可能な、ユーザ装置、移動局、固定または移動加入者ユニット、ページャ、他の任意のタイプのデバイスを含んでいる。以下で言及するときには、基地局は、それだけには限定されないが、無線環境中における、ノードＢ、サイト制御装置、アクセスポイント、または他の任意のタイプのインターフェースデバイスを含んでいる。この説明中に提供される数の範囲および数値は、例示的なものであり、本発明の概念は、他の数の範囲および数値にも等しく適用可能であることに留意されたい。
【００１２】
図１は、ＲＮＣからＷＴＲＵへのＤＬ（ｄｏｗｎｌｉｎｋダウンリンク）伝送を示すタイミング図である。この主要な遅延コンポーネントは、以下を含んでいる。
【００１３】
１．このタイミング調整の観点から、ＦＰ（ｆｒａｍｅ  ｐｒｏｔｏｃｏｌフレームプロトコル）と、このＲＮＣ内のＦＰ下のデータパス上の他のＲＮＣサブレイヤを含むＲＮＣ内部処理遅延。この処理遅延の定義では、このＭＡＣ  ＰＤＵ（ｐｒｏｔｏｃｏｌ  ｄａｔａ  ｕｎｉｔプロトコルデータユニット）が、作成され、このＦＰエンティティに転送する準備が整っているものと想定している。したがって、考慮しているトランスポートチャネル（または、ＤＣＨ（ｄｅｄｉｃａｔｅｄ  ｃｈａｎｎｅｌ専用チャネル）しか存在しない場合には、これらの協調したトランスポートチャネル）のＴＴＩ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｔｉｍｅ  ｉｎｔｅｒｖａｌ伝送時間間隔）境界において、このＭＡＣプロセスが、開始されており、このトランスポートチャネルが多重化されるコード化された複合物についてのＴＦＣＩ（ｔｒａｎｓｐｏｒｔ  ｆｏｒｍａｔ  ｃｏｍｂｉｎａｔｉｏｎ  ｉｎｄｉｃａｔｏｒトランスポートフォーマット組合せインジケータ）選択をすでに実施している。さらに、このＭＡＣは、ＲＬＣ（ｒａｄｉｏ  ｌｉｎｋ  ｃｏｎｔｒｏｌ無線リンク制御）バッファからのデータを要求しており、このデータは、このＭＡＣにとってすでに使用可能にされている。  
２．Ｉｕｒ／Ｉｕｂインターフェース上のフレームの移動時間を表すＩｕｒ／Ｉｕｂ遅延。  
３．ＦＰプロセスキューと、ＣＲＣ（ｃｙｃｌｉｃ  ｒｅｄｕｎｄａｎｃｙ  ｃｈｅｃｋ巡回冗長検査）計算（ヘッダ、およびオプションとしてＤＣＨについてのペイロード）と、経路指定処理におけるこのフレームの待ち時間を含むノードＢ処理遅延、ＴｐｒｏｃＢ。ＴｐｒｏｃＢは、Ｉｕｒ／Ｉｕｂ遅延を用いて集計することができる。  
４．このセルとこのノードＢの間のこのフレームの移動時間を表すノードＢ−セルインターフェース遅延。  
５．このＬ１プロセッサに至るまでのセルプロセス間のデータ転送を含めて、このセル上の全般的な処理時間を表すセル処理遅延、ＴｐｒｏｃＣ。
【００１４】
タイミング調整の必要性は、この全般的なＤＬ遅延において、ばらつき（ジッタ）が存在することに由来する。タイミング調整を使用して、各データフレームが、このエアインターフェース上における伝送に間に合うように、Ｌ１において使用可能になるようにＲＮＣ伝送時間を適合させる。様々な遅延の原因により、Ｌ１において伝送に間に合うようにするためには、このフレームは、ある一定の時間内に各処理段階に到着する必要がある。
【００１５】
あまりにも遅れて到着するフレームは、このセルまたはこのノードＢによって切り捨てられ、それによってそのＱｏＳが悪化することになる。あまりにも早期に到着しすぎるフレームは、バッファされることになる。後者の状況においては、このバッファ中にスペースがない場合に、すなわちバッファオーバーフロー状況において、フレームが、やはり切り捨てられる可能性がある。（特に、このＩｕｒ／Ｉｕｂインターフェース上の）これらのジッタ値と、その結果としてのＤＬ伝送遅延は、ある種の確率分布を有するランダム変数と考えることができる。このＩｕｒ／Ｉｕｂインターフェース上のジッタは、ある程度まで使用するデータリンク技術に依存し、例えば、ＡＴＭ（ａｓｙｎｃｈｒｏｎｏｕｓ  ｔｒａｎｓｆｅｒ  ｍｏｄｅ非同期転送モード）技術は、イーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ（登録商標））技術よりも多くのジッタを十中八九示すことになる。
【００１６】
この着信時刻（ＴＯＡ）は、このジッタを評価するランダム変数である。制御ウィンドウは、ある種の信頼レベルを用いてこのフレームの所望の到着時刻のあたりに設計することができる。ＴＯＡウィンドウと呼ばれるこのウィンドウは、２つのエンドポイント、すなわちＴＯＡＷＳ（ＴＯＡ  Ｗｉｎｄｏｗ  ｓｔａｒｔＴＯＡウィンドウ開始）およびＴＯＡＷＥ（ＴＯＡ  ｗｉｎｄｏｗ  ｅｎｄＴＯＡウィンドウ終了）によって特徴づけられる。ＴＯＡＷＳおよびＴＯＡＷＥは、このトランスポートベアラのセットアップまたは再構成中にこのＲＮＣによって決定され、このノードＢに信号で伝えられる。
【００１７】
これらの定義については、図２に図示されている。一例として、９９％の信頼レベルが設計パラメータとして選択されるものと想定する。このウィンドウについて注意深い設計を用いて、これらの伝送されるデータフレームの９９％が、この予想されるウィンドウ内に含まれることになり、これらの伝送されるデータフレームの１％に対して、切り捨てられる可能性が残される。この脱落するフレームのパーセンテージは、ＴＯＡＷＥ上のＬＴＯＡ（ｌａｔｅ  ｔｉｍｅ  ｏｆ  ａｒｒｉｖａｌ遅れた着信時刻）マージンの修復効果（ｒｅｍｅｄｙ  ｅｆｆｅｃｔ）と、早期フレームのバッファリングを用いてさらに減少させることができる。次いでこの傾向を取り扱う訂正が、このタイミング調整を呼び出すことにより適用される。
【００１８】
このタイミング調整制御プロシージャは、３ＧＰＰ仕様中において指定されるが、このＴＯＡウィンドウパラメータ設定については、ガイドラインは存在していない。また、タイミング調整制御フレームがこのノードＢから受信されるときに、（ＣＦＮラップアラウンドを考慮した）ＴＯＡの計算についての、またはこのＲＮＣ（ＭＡＣ）におけるこのデータ伝送時間に適用されるこの調整の決定についての指示も存在しない。
【００１９】
アルゴリズム
Ｉ．ノードＢフレームプロトコルのロケーション、およびタイミング調整処理
３ＧＰＰにおいては、このノードＢ−セルインターフェースは、規格化されてはおらず、このノードＢもこのセルも共に、同じハードウェア上に物理的に存在しているという仮説が存在している。しかし、ベンダは、セルおよびこのノードＢが異なるロケーションに存在し、したがって異なるハードウェア構成要素上に存在するという１つのアーキテクチャを選択することができる。かかる場合においては、このＩｕｂインターフェースのノードＢ−セル側において、このＦＰエンティティのロケーションが、このＤＬ伝送タイミング制御に対して影響を及ぼす可能性がある。このＦＰエンティティについての２つの可能性のあるロケーションが、このノードＢ上とこのセル上について検査される。
【００２０】
このＦＰエンティティがこのノードＢ上に実装される場合、このＴＯＡの計算は、特にこのチャネルセットアップにおけるこのノードＢ−セルインターフェース遅延を直接に考慮に入れないことになる。このシナリオの下において、１つのアイデアは、過剰なマージンを伴うこのセル処理時間を設定して、このノードＢ−セルインターフェース遅延を明らかにすることである。この設計選択肢の欠点は、このノードＢ−セルインターフェース上のジッタと、容認しがたいサービス遅延を伴う、このセル側上の結果として生じるより大きなバッファの増大に対して速やかに対応する困難である。この困難については、このノードＢ−セルインターフェース上におけるタイミング調整と同様なプロシージャを実施することによって克服することができる。このセルからのタイミング調整制御フレームの受信に際して、２つの代替形態が使用可能である。すなわち、（ａ）このノードＢが、タイミング調整制御フレームをこのＲＮＣに送信する。あるいは、（ｂ）このノードＢが、ＴＯＡの将来の計算において使用すべきセル処理時間値の推定値を自律的に変更する。
【００２１】
代替形態（ｂ）はまた、実装と性能の観点から、このノードＢによるタイミング調整制御フレームの生成をもたらすことになるが、ジャストインタイム戦略に頼る代替形態（ａ）は、よりすっきりしており、保持すべき変数がさらに少ない。また代替形態（ａ）では、このセル処理パラメータ（ＴｐｒｏｃＣ）に余分なマージンを追加する必要はなく、その結果、このセル側上におけるバッファサイズは、ほとんどサービス遅延なしに比較的小さくすることができる。このＳＦＮもＢＦＮ（ノードＢフレーム番号）も共に互いにロックされない場合には、長期間のクロックドリフトの可能性があり、このクロックドリフトは、このＦＰがこのノードＢ上で実装されるときにおける、タイミング調整処理の困難を増大させる。しかし、このセルが限られた処理能力をもつハードウェアにマッピングされる場合には、このノードＢ上でこのＦＰ処理を実装することにより、このセルの負担を軽減する（ｏｆｆｌｏａｄ）ことが望ましいかもしれない。
【００２２】
このＦＰエンティティがこのセル上で実装される場合には、このＩｕｒ／Ｉｕｂインターフェース上と、このノードＢ−セルインターフェース上の両方の遅延が組み合わされ、このＴＯＡの計算において直接、考慮に入れられる。この処理時間推定値は、厳密にこのセル上の処理時間に対応し、これにより、タイミング調整の観点からさらに良いアプローチがもたらされる。また、このＳＦＮは、直接に使用可能であり、ＢＦＮからＳＦＮへの余分な変換ステップを有する必要性は存在しない。
【００２３】
本明細書中で説明しているように、このＦＰエンティティは、このノードＢの制御下のこれらのセルと同じプラットフォーム上で統合されたノードＢ上に存在し、ここではこのノードＢも、これらのセルも共に、このハードウェアレベルにおいて高速バス上で通信を行い、これは、両方のノードが、ソケットに似たインターフェースを介して互いに通信を行う構成とは対照的である。
【００２４】
ＩＩ．着信時刻ウィンドウおよびバッファサイズの設計の検討
このウィンドウサイズについての設計目標は、これらのＦＰフレームを以下の時刻にこのノードＢに到着させることである。  
１．この推定されたＩｕｒ／Ｉｕｂ遅延が最大であるときに、この基準時刻（ＴＯＡ＝０）よりも遅くないこと。  
２．このＩｕｒ／Ｉｕｂ遅延が最小であるときに、ＴＯＡ＝ＴＯＡＷＳよりも早くないこと。  
【００２５】
ＴＯＡと、ＴＯＡＷＳと、ＴＯＡＷＥの関係は、図２を参照して理解することができる。ＴＯＡとＴＯＡＷＥは、異なる開始ポイントを有する。ＴＯＡＷＥについての開始ポイントは、ＬＴＯＡであり、右から左に向かってカウントされる。すなわち、ＴＯＡＷＥは、常に正の値である。ＴＯＡについての開始ポイントは、ＴＯＡＷＥであり、ＴＯＡＷＥから左に向かって正方向にカウントされ、ＴＯＡＷＥから右に向かって負方向にカウントされる。
【００２６】
伝送するのにあまり遅くはないフレーム（ＴＯＡ≧−ＴＯＡＷＥ、図２に示すようなＴＯＡＷＥとＬＴＯＡの間のクロスハッチ区域）は、バッファリングが考慮されることになり、このＲＮＣにより、このフレームヘッダに含まれるターゲットＣＦＮに宛てて送信されることになる。このバッファサイズは、（ＴＯＡＷＳ＋ＴＯＡＷＥ）／ＴＴＩ以上であり、ＴＯＡＷＳおよびＴＯＡＷＥと同じユニット中で表現される。
【００２７】
あまりにも遅れて到着する（ＴＯＡ＜−ＴＯＡＷＥ、図２に示すようなＬＴＯＡの右側にある）フレームは、切り捨てられることになる。
【００２８】
ＴＯＡＷＥを使用して、遅れて到着するフレームも依然として処理することができるようにＬＴＯＡについて余分なマージンを提供する。したがって、ＴＯＡＷＥは、どのような有効な任意の値にも設定することができる。しかし、有効なタイミング調整処理の観点から、ＴＯＡＷＥは、小さな数（ＴＴＩの１倍または２倍）に設定すべきである。ＴＯＡＷＥが大きな値である場合には、このバッファサイズもまた大きくする必要がある。このターゲットＣＦＮを後方に調整して、フレームがあまりにも早く受信される状況を処理するというシナリオにおいては、これは、データフレームの大きなバッファ遅延を引き起こす可能性があり、このバッファ遅延は、フレームの衝突（同じターゲットＣＦＮを有する２つの異なるデータフレーム）と、最終的にフレームの脱落をもたらす可能性がある。これらの同じターゲットＣＦＮを用いて以前に送信されたフレームは、このエアインターフェース上での伝送のためにこのノードＢ−セル側バッファ中で依然として待っており、衝突がもたらされる可能性がある。
【００２９】
このＴＯＡＷＳ値は、所与の信頼レベルについてのこのＲＮＣとこのノードＢの間のＤＬ伝送遅延の変動性の目安である。このＲＮＣとこのノードＢの間のＤＬ伝送遅延は、正規分布などの確率分布を使用してモデル化することができる。これらのＤＬ遅延値のサンプルは、ノード同期化プロシージャを使用することにより収集することができる。この目的のために、このノード同期化プロシージャは、高優先度チャネルと通常のトラフィックチャネルの両方の上で実行される。この高優先度チャネル上でのノード同期化プロシージャの実行を使用して、両方のロケーションにおける現行のフレーム番号の観点から、このノードＢクロックと、このＲＮＣクロックの間の時間差を推定する。高優先度チャネル上に遅延は存在しないことが想定されるので、これらのクロック間の差は、簡単に決定することができる。次いで、この推定された時間差を（遅延を有する）通常のトラフィックチャネル上で収集されたＤＬ遅延統計値に対する補正ファクタとして使用して、この測定についての時間差成分をオフセットする。このノード同期化プロシージャについては、３ＧＰＰ中に説明されているが、タイミング調整およびＤＬ遅延推定のサポートにおけるその使用については、ベンダ実装に任されている。
【００３０】
ＴＯＡＷＳは、ｋ×σとして設定することができ、式中でｋは、所望の信頼レベルによる整数であり、σは、このＤＬ伝送分布の標準偏差である。このＴＯＡ値の範囲は、｛−１２８０ｍｓ，＋１２７９．８７５ｍｓ｝であるので、ＴＯＡＷＳ≦Ｔ＿ＣＦＮ／２＝１．２８秒（または、ＰＣＨ（ｐｈｙｓｉｃａｌ  ｃｈａｎｎｅｌ物理チャネル）については２０．４８秒）という制約条件を課することが妥当になる。このＣＦＮの範囲は、０から２５５までである。すなわち、このＣＦＮサイクルは、各フレームを１０ｍｓ幅であるとして２５６個の無線フレームにまたがる。Ｔ＿ＣＦＮは、ＣＦＮサイクル長であり、これは２５６０ｍｓである。
【００３１】
このサービスのエンドツーエンド遅延と、ＴＯＡＷＳがこのＤＬ伝送遅延に強く相関づけられることを仮定すると、ＴＯＡＷＳ＜α×ＡＤＪという制約条件を課すこともまた妥当であり、式中、ＡＤＪは、考慮しているサービスタイプについて容認することができる全般的な遅延を仮定して、このＩｕｒ／Ｉｕｂインターフェース上のこのＤＬ上の容認可能な遅延ジッタを示し、αは、｛０，１｝間の係数である。この遅延ジッタは、この遅延中に存在する変動であり、その遅延それ自体ではない。このＲＮＣとこのノードＢの間の遅延は、このシステム中において変化するトラフィックレベルによって一定ではない。この可変の遅延は、このＴＯＡウィンドウを使用するための理由である。したがって、この遅延が一定であった場合には、このフレームのＴＯＡは常に知られているはずなので、このウィンドウは、必要とされないはずである。
【００３２】
ＡＤＪもαも共に構成可能なパラメータとすることができ、ＴＯＡＷＳ＝（ｋ×σ）＜（α×ＡＤＪ）のようにこの確率分布（正規分布）のパラメータが選択される必要がある。この設計の目的は、このＴＯＡＷＳ値はバッファ遅延が小さくなるように設定すべきであるという点において、ＴＯＡＷＥと同様である。特にＲＴ（ｒｅａｌ  ｔｉｍｅリアルタイム）サービスについては、ＴＯＡＷＳは、１００ｍｓ以下に設定することができる。対話形式の音声サービスおよびビデオサービスでは、この好ましいエンドツーエンド遅延は、約１５０ｍｓである。
【００３３】
ノードＢ−セル側上のバッファは、−ＴＯＡＷＥ＜ＴＯＡ≦ＴＯＡＷＳとなるこれらのデータフレームのすべてを保持するのに十分大きくすべきである。負のＴＯＡＷＥ値は、このウィンドウ中の任意のフレーム、ならびに遅れて到着するフレーム（すなわち、図２に示すようなＴＯＡＷＳとＬＴＯＡの間の任意のフレーム）を包含することになる。これは、以下のバッファサイズをもたらす。
【００３４】
【数１】
2007525080.tif 000003
【００３５】
可変なＴＴＩの場合には、最小のＴＴＩが使用される。このノードＢに早期に到着するデータ（ＴＯＡ＞ＴＯＡＷＳ）は、依然としてバッファすることができるが、このバッファサイズは、−ＴＯＡＷＥ＜ＴＯＡ≦ＴＯＡＷＳを伴うこれらのデータフレームだけを保持するように設計される。ＴＯＡＷＳに課される好ましい設計制約条件に関しては、このバッファサイズは、以下のように定義することができる。
【００３６】
【数２】
2007525080.tif 000004
【００３７】
この境界は、ＲＴサービスの場合、特にＴＯＡＷＥが適切に選択される場合には、結び付けられた境界とすることができ、確率モデルを使用する必要性を回避することによって設計の利点をもたらすことができる。
【００３８】
ＩＩＩ．ＴＯＡの計算
このＴＯＡは、このノードＢ上でＦＰ処理の一部分として計算される。ＳｃｈｅｄｕｌｅＣＦＮは、このＲＮＣから受信されたフレーム中に含まれるＣＦＮ値であり、ＣｕｒｒｅｎｔＣＦＮは、このＲＮＣから受信されるフレームの到着時刻に対応する（このＳＦＮカウンタに関する）ＣＦＮ番号である。
【００３９】
以下のパラメータは、次のように定義される。  
１．ＳｃｈｅｄｕｌｅＳＦＮは、このデータが空中でＬ１によって伝送されるべきＳＦＮである。  
２．ＣｕｒｒｅｎｔＳＦＮは、現行のＳＦＮのことである。  
３．ＳＦＮｔｉｍｅは、１／８ｍｓ単位で表現された時間軸上の所与のＳＦＮに対応する時刻である。  
４．ＣＦＮｔｉｍｅは、１／８ｍｓ単位で表現された時間軸上の所与のＣＦＮに対応する時刻である。
【００４０】
このＴＯＡ値は、１／８ｍｓの分解能でこのＩｕｂインターフェース上を転送される。次いでＴＯＡは、整数（非ＰＣＨチャネルについては１６ビット、ＰＣＨチャネルについては２０ビット）として表現することができる。その計算は、以下の仮定に基づいている。  
１．ＴＯＡＷＳとＴＯＡＷＥの使用は、ＮＢＡＰ仕様中のこれらの定義（例えば、ＴＯＡＷＳについては非特許文献１を、ＴＯＡＷＥについては非特許文献２を参照）に基づいている。ＴＯＡＷＳは、この受信ウィンドウのエンドポイントに関して正の相対値であるが、ＴＯＡＷＥは、この時間軸上のＬＴＯＡポイントに関して正の相対値である。  
２．トランスポートベアラのセットアップまたは再構成時に、ＴＯＡＷＳおよびＴＯＡＷＥは、１／８ｍｓ単位でデータベース中に記憶される。  
３．Ｔｐｒｏｃは、１／８ｍｓ単位で記憶されるこのノードＢ−セルインターフェース遅延を一緒に伴う、このセル上の処理時間の推定値である。  
４．ＣｕｒｒｅｎｔＢＦＮｔｉｍｅ、すなわち、この現行のノードＢフレーム番号に対応する時刻は、タイマライブラリに対するＡＰＩコールを介して受信され、１／８ｍｓ単位で表現される。  
５．ＣｕｒｒｅｎｔＳＦＮｔｉｍｅ＝ＣｕｒｒｅｎｔＢＦＮｔｉｍｅ＋ＳＦＮ＿ＢＦＮ＿Ｏｆｆｓｅｔ。ＳＦＮ＿ＢＦＮ＿Ｏｆｆｓｅｔは、このＳＦＮとこのＢＦＮの間の差であり、１／８ｍｓ単位の分解能における範囲｛−４０９５９．８７５ｍｓ×８，．．０，．．＋４０９５９．８７５ｍｓ×８｝＝｛−３２７６７９，．．０，．．＋３２７６７９｝の中にある。  
６．無線フレーム期間（Ｒａｄｉｏ  Ｆｒａｍｅ  Ｐｅｒｉｏｄ）＝１０ｍｓ×８＝１／８ｍｓ単位で８０。
【００４１】
一般的に、このＴＯＡは、以下のように定義される。  
TOA = (ScheduleTime - Tproc - TOAWE) - CurrentTime                式（３）
【００４２】
ＳＦＮ基準において、ＴＯＡは、以下のように表される。  
TOA = (ScheduleSFNtime - Tproc - TOAWE) - CurrentSFNtime              式（４）
【００４３】
ＣＦＮ表記法では、ＴＯＡはまた、以下のように表すことができる。  
TOA = (ScheduleCFNtime - Tproc - TOAWE) - CurrentCFNtime              式（５）
すなわち以下のように表される。
【００４４】
【数３】
2007525080.tif 000005
【００４５】
式（３）〜（６）は、｛０，２５５｝の間に保持されるＣＦＮ値のラップアラウンド効果を考慮していない。また、これらの式は、このＴＯＡの範囲が｛−１２８０ｍｓ，１２７９．８７５ｍｓ｝であることを考慮していない。これらの制約条件は、以下で説明する追加のステップによって考慮される。
【００４６】
計算性能を節約するために、この量
【００４７】
【数４】
2007525080.tif 000006
【００４８】
は、１度だけしか評価せず、次いでＣｕｒｒｅｎｔＣＦＮの式中でもＴＯＡの式中でも共に再使用すべきである。
【００４９】
ＣｕｒｒｅｎｔＣＦＮは、以下の式を用いて計算される。  
この専用チャネル（ＤＣＨ）およびＤＳＣＨ（ＤＬ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌＤＬ共用チャネル）では、以下のようになる。
【００５０】
【数５】
2007525080.tif 000007
【００５１】
ＦＡＣＨ（ｆｏｒｗａｒｄ  ａｃｃｅｓｓ  ｃｈａｎｎｅｌフォワードアクセスチャネル）では、以下のようになる。
【００５２】
【数６】
2007525080.tif 000008
【００５３】
このＰＣＨでは、以下のようになる。
【００５４】
【数７】
2007525080.tif 000009
【００５５】
ＩＶ．ＣＦＮラップアラウンド制約条件を用いたＴＯＡの計算
このＤＣＨ、このＤＳＣＨ、またはこのＦＡＣＨでは、このＣＦＮは、｛０，２５５｝の範囲内にあり、このＴＯＡは、｛−１２８０，１２７９．８７５ｍｓ｝の範囲内、すなわち１／８ｍｓ単位における｛−１０２４０，１０２３９｝の範囲内にある。
【００５６】
このＰＣＨでは、このＣＦＮは、｛０，４０９５｝の範囲内にあり、このＴＯＡは、｛−２０４８０ｍｓ、＋２０４７９．８７５｝の範囲内、すなわち１／８ｍｓ単位における｛−１６３８４０，＋１６３８３９｝の範囲内にある。
【００５７】
このＣＦＮに対するラップアラウンド制約条件は、単にこのＴＯＡが前述の範囲内に存在するようにすることによって考慮することができる。このＤＣＨ、このＤＳＣＨ、またはこのＦＡＣＨについてこのＴＯＡを計算するための方法３００が、図３に示されている。方法３００は、このＣｕｒｒｅｎｔＢＦＮｔｉｍｅを獲得することにより、開始される（ステップ３０２）。次いで、このＣｕｒｒｅｎｔＳＦＮｔｉｍｅは、以下に従って計算される（ステップ３０４）。  
CurrentSFNtime = (CurrentBFNtime + SFN_BFN_Offset)              式（１１）
【００５８】
ＳＦＮ＿ＢＦＮ＿Ｏｆｆｓｅｔは、１／８ｍｓ単位で表される。またこのＬ１において、関係式ＳＦＮ＝（ＢＦＮ＋ＳＦＮ＿ＢＦＮ＿Ｏｆｆｓｅｔ）が、このＳＦＮ＿ＢＦＮ＿Ｏｆｆｓｅｔの計算を行うために使用される。
【００５９】
ＣｕｒｒｅｎｔＣＦＮの値は、式（８）または（９）に従って計算される（ステップ３０６）。次に、ＴＯＡが、式（６）に従って計算される（ステップ３０８）。
【００６０】
次いで、このＴＯＡ値が、評価される（ステップ３１０）。ＴＯＡ≧１０２４０の場合には、ＴＯＡ＝ＴＯＡ＝ＴＯＡ−２０４８０となる（ステップ３１２）。次いでこの方法は、ステップ３１０へと戻って、この調整済みのＴＯＡ値を評価する。ＴＯＡ＜−１０２４０（ステップ３１０）の場合には、ＴＯＡ＝ＴＯＡ＋２０４８０（ステップ３１４）となる。次いで、この方法は、ステップ３１０へと戻って、この調整済みのＴＯＡ値を評価する。−１０２４０≦ＴＯＡ≦１０２３９（ステップ３１０）の場合には、このＴＯＡ値に対してどのような変更も行われず（ステップ３１６）、この方法は終了する（ステップ３１８）。この計算されたＴＯＡ値が所定の範囲外にある場合、ステップ３１２または３１４が実施され、この調整が、このＴＯＡ値を範囲内に含めようとして行われる。
【００６１】
方法３００の一例としては、以下を想定されたい。すなわち、Ｔｐｒｏｃ＝０ｍｓ、ＴＯＡＷＥ＝０ｍｓ、フレームオフセット＝０、ＳｃｈｅｄｕｌｅＣＦＮ＝０、およびＣｕｒｒｅｎｔＳＦＮｔｉｍｅ＝２５５０ｍｓ、すなわち２０４００単位（１／８ｍｓにおける）を想定されたい。ＣｕｒｒｅｎｔＣＦＮ＝ｆｌｏｏｒ（２０４００／８０）ｍｏｄ２５６＝２５５。これらの値および予備計算に基づいて、以下となる。  
ＴＯＡ＝（０−２５５）×８０−０−（０＋０）＝−２０４００
【００６２】
ＴＯＡ＜−１０２４０であるので、この場合には、ＴＯＡ＝−２０４００＋２０４８０＝＋１０ｍｓとなる。
【００６３】
このＰＣＨについて、このＴＯＡを計算するための方法４００が、図４に示されている。方法４００は、このＣｕｒｒｅｎｔＢＦＮｔｉｍｅを獲得することにより、開始される（ステップ４０２）。次いで、このＣｕｒｒｅｎｔＳＦＮｔｉｍｅが、以下の式に従って計算される（ステップ４０４）。
CurrentSFNtime = (CurrentBFNtime + SFN_BFN_Offset)×1/8          式（１２）
【００６４】
このＣｕｒｒｅｎｔＣＦＮの値が、式（８）または（９）に従って計算される（ステップ４０６）。次に、このＴＯＡが、式（６）に従って計算される（ステップ４０８）。
【００６５】
次いで、このＴＯＡの値が、評価される（ステップ４１０）。ＴＯＡ≧１６３８４０である場合、次いでＴＯＡ＝ＴＯＡ＝ＴＯＡ−３２７６８０となる（ステップ４１２）。次いで、この方法は、ステップ４１０へと戻って、この調整済みのＴＯＡ値を評価する。ＴＯＡ＜−１６３８４０である場合（ステップ４１０）、次いで、ＴＯＡ＝ＴＯＡ＋３２７６８０となる（ステップ４１４）。次いでこの方法は、ステップ４１０へと戻って、この調整済みのＴＯＡ値を評価する。−１６３８４０≦ＴＯＡ≦１６３８３９である場合（ステップ４１０）には、次いで、このＴＯＡ値に対して変更は行われず（ステップ４１６）、この方法は、終了する（ステップ４１８）。この計算済みのＴＯＡ値が、所定の範囲外にある場合には、ステップ４１２および４１４が実施され、このＴＯＡ値を範囲内に戻そうとしてこの調整が行われる。
【００６６】
Ｖ．ターゲットＣＦＮの初期化
このＣＦＮの初期化は、送信すべき第１のＴＢＳ（ｔｒａｎｓｐｏｒｔ  ｂｌｏｃｋ  ｓｅｔトランスポートブロックセット）のターゲットＣＦＮを計算することを含んでいる。ＣＦＮは、Ｌ２（ＭＡＣ）によってＬ１に対して送信されるすべてのＴＢＳに関連している。このトランスポートチャネル同期化プロシージャを使用して、このＣＦＮ、すなわち所与の接続についての、この第１のＴＢＳの伝送時間を初期化する。ＣＦＮがフレームに割り当てられた後に、このフレームは、このＣＦＮ上で送信され、したがってこのフレームを送信に先立って適切に処理することができるようにＣＦＮを割り当てることが重要である。例えば、このターゲットＣＦＮが８０である場合、フレーム番号７８におけるフレームの送信は、バッファリングをもたらす可能性があり、フレーム番号８２におけるフレームを送信することにより、このフレームが脱落させられる可能性がある。このトランスポートチャネル同期化プロシージャを使用してタイミング調整のサポート中にＴＯＡサンプリングを実施することもできる。
【００６７】
ターゲットＣＦＮ初期化のための方法５００が、図５ａおよび５ｂに示されている。方法５００は、１０ｍｓ、すなわち１つの無線フレーム長ごとに時を刻むカウントタイマ（Ｔ＿Ｎ、ステップ５０２）を設定することによって開始される。ターゲットＣＦＮ値を見出すために使用されるＮについての初期値が、次式に従って設定される（ステップ５０４）。
【００６８】
【数８】
2007525080.tif 000010
【００６９】
次いで、ＴＯＡ＿ｍｉｎについての初期値が設定される（ステップ５０６）。３ＧＰＰ仕様によれば、ＴＯＡは、｛−１２８０ｍｓ，．．．，＋１２７９．８７５ｍｓ｝の範囲内にある。したがって、任意に決められる厳密な低い側の境界は、１／８ｍｓ単位で表されるＴＯＡ＿ｍｉｎ＝−２５６０×８０としてのＴＯＡ上に設定することができる。ＴＯＡ＿ｍｉｎは、かかる低い値に設定され、その結果、実施すべきサンプリングは、ＴＯＡ＿ｍｉｎよりも大きくなる最大のＴＯＡ値の集まりを可能にすることになる。このＣＦＮ境界をＲＦＮ境界に合わせる必要はない。したがって、目的は、ＣＦＮ境界をＳＦＮ境界に合わせることである。
【００７０】
ＤＬ同期化制御フレームが、ステップ５０４で取得されるＮに等しいターゲットＣＦＮを用いて送信される（ステップ５０８）。このターゲットＣＦＮについてのより良い推定値を取得するために行われるサンプリングを実施するために、このＤＬ同期化制御フレームは、毎回、異なるターゲットＣＦＮ値を用いて、所定数（ｎ）の回数にわたって送信される。例示の一実装形態において、このｎのデフォルト値は、２である。次に、カウンタ（ｉ）が初期化され、このカウンタを使用して収集されるサンプル数をカウントし、ＴＯＡ統計値収集フラグ（ＴＯＡ＿Ｓｔａｔ＿Ｃｏｌｌｅｃｔｉｏｎ）を「オン」に設定して、ＴＯＡ統計値を収集すべきことを示す（ステップ５１０）。これらの変数が初期化された後に、この方法は、レディ状態（ｒｅａｄｙ  ｓｔａｔｅ）になり、このシステムからのアクションに反応するように待つことになる（ステップ５１２）。
【００７１】
このアクションが、１０ｍｓのタイマのティック（ｔｉｃｋ）がこのタイマＴ＿Ｎから受信される（ステップ５１４）ことである場合、このシステムがＴＯＡ統計値を収集しているかどうか（ＴＯＡ＿Ｓｔａｔ＿Ｃｏｌｌｅｔｉｏｎフラグが「オン」に設定されているかどうか、ステップ５１６）についての判定が行われる。このシステムが現在ＴＯＡ統計値を収集していない場合、次いでこの方法は、このレディ状態に戻る（ステップ５１２）。このＴＯＡ統計値が収集されている（ステップ５１６）場合には、次いで、このＮの値は、このタイマの１０ｍｓのティックごとに１だけ増分される（ステップ５１８）。次に、このＮの増分された値に等しいターゲットＣＦＮを有するＤＬ同期化制御フレームが送信され（ステップ５２０）、この方法は、このレディ状態に戻る（ステップ５１２）。
【００７２】
このアクションが、ＵＰ（ｕｐｌｉｎｋアップリンク）同期化制御フレームが受信される（ステップ５２２）ことである場合、これは、このノードＢがこの以前に送信されたＤＬ同期化制御フレームを受信していることを示し、このＵＬ制御フレームをこのＲＮＣに送信し、このＵＬ制御フレームは、この受信されたフレームに対応するノードＢフレーム番号を含んでいる。方法５００を使用してこのターゲットＣＦＮを計算しているので、このＤＬフレーム番号とＵＬフレーム番号は、異なるはずである。このＤＬ制御フレームのＴＯＡも、ステップ５２２において計算される。次いで、このサンプルカウンタは、１だけ増分される（ステップ５２４）。
【００７３】
この現行のＴＯＡ値が、ＴＯＡ＿ｍｉｎよりも大きいかどうかについての判定が行われる（ステップ５２６）。ＴＯＡがＴＯＡ＿ｍｉｎよりも大きくない場合、次いでＴＯＡ＿ｍｉｎに対して変更は行われず（ステップ５２８）、この方法は、このレディ状態へと戻る（ステップ５１２）。ＴＯＡがＴＯＡ＿ｍｉｎよりも大きい場合には（ステップ５２６）、次いでＴＯＡ＿ｍｉｎは、この現行のＴＯＡ値に設定される（ステップ５３０）。次いで、すべての所定数のサンプルが収集されているかどうかについての判定が行われる（ｉ＞ｎ、ステップ５３２）。これらのすべてのサンプルが収集されていない場合、次いでこの方法は、レディ状態へと戻る（ステップ５１２）。これらのすべてのサンプルが収集されている場合（ステップ５３２）、次いでこのＴＯＡ統計値収集は、停止される（ステップ５３４）。
【００７４】
（ステップ５３４までの）方法５００の第１の部分を使用して、このターゲットＣＦＮを計算するための統計値を収集するが、（ステップ５３６から先の）方法５００の第２の部分は、使用すべき実際のターゲットＣＦＮ値を決定する。方法５００は、次に２つの代替形態のうちの一方に従ってＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ値を計算する（ステップ５３６）。
【００７５】
第１の代替形態においては、このＴＯＡウィンドウの最後がターゲットにされ、ここでは、データフレームが、このエアインターフェース上での伝送についてジャストインタイムでこのノードＢ−セルに到着し、したがって、不必要な初期データバッファリングが存在していない。このＴＯＡウィンドウの最後をターゲットにすることにより、バッファ遅延が減少させられ、このノードＢ−セルにそのスケジュール化された送信時刻以前にあまりにも早く受信されるフレームのリスクが、最小化される。時間調整の観点から、このバッファ遅延を最小にして、フレームがこのノードＢにあまりにも早期に到着するのを回避することが望ましい。タイミング調整は、フレームが早くなるのに比べてフレームが遅くなると共により良好に機能する。この代替形態においては、このオフセットは、次式のように定義される。
【００７６】
【数９】
2007525080.tif 000011
【００７７】
この第２の代替形態は、ＴＯＡウィンドウの中間をターゲットにし、これはより保守的なアプローチである。データフレームは、このウィンドウの中間に到着し、フレームをあまりにも早く、または遅く到着させてしまう確率を減少させる。しかし、データが送信される前にバッファされることになるので、このバッファ遅延は増大する。このアプローチは、このエンドツーエンド遅延も増大させ、これにより、この第１のアプローチが好ましいものになる。ＴＯＡ＝ＴＯＡＷＳ／２（すなわち、このウィンドウのちょうど中央）である場合、このウィンドウの中央がすでにターゲットにされていることから、調整を行う必要がないので、ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ＝０となる。そうでない場合には、このオフセットは、次式のように定義される。
【００７８】
【数１０】
2007525080.tif 000012
【００７９】
このオフセットを計算するために使用される式は同じであるが、このオフセットの効果は、ＴＯＡ＿ｍｉｎの値に依存することに留意されたい。
【００８０】
ＴＯＡ＿ｍｉｎ≦０である場合、これは、このフレームが遅れていることを示し、このオフセットの適用は、この所望のフレーム番号をヒットする追加の遅延を提供することにより、このウィンドウの最初をターゲットにすることになる。
【００８１】
ＴＯＡ＿ｍｉｎ＞ＴＯＡＷＳである場合、これは、このフレームがあまりにも早期に到着したこと、およびこの遅延が過大評価されたことを示している。このオフセットを使用して、この遅延を減少させて、このウィンドウの最後をターゲットにする。
【００８２】
０＜ＴＯＡ＿ｍｉｎ＜ＴＯＡＷＳ／２である場合、これは、このフレームがこのウィンドウの前半に到着したことを示している。このオフセットを使用して、このウィンドウの後半をこのウィンドウの開始に向けてターゲットさせる。正の値は、ＴＯＡＷＥからＴＯＡＷＳに向かってカウントされるので、このウィンドウの前半は、たとえ図２に示すように、ＴＯＡＷＳの右側に現れることがあったとしても、より低いＴＯＡ値を有する。
【００８３】
ＴＯＡＷＳ／２＜ＴＯＡ＿ｍｉｎ＜ＴＯＡＷＳである場合には、これは、このフレームがこのウィンドウの後半に到着したことを示している。このオフセットを使用して、このウィンドウの前半をこのウィンドウの終了に向けてターゲットさせる。
【００８４】
ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔが計算された後に、ステップ５０２で設定されるカウントタイマからの次のティックに、この最初のＣＦＮ値は、以下のように設定される（ステップ５３８）。
Ｉｎｉｔｉａｌ＿ＣＦＮ＝Ｎ＋ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ          式（１６）
【００８５】
次に、ＣｕｒｒｅｎｔＳｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮ＝Ｉｎｉｔｉａｌ＿ＣＦＮと設定する（ステップ５４０）。これから以降、ＣｕｒｒｅｎｔＳｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮは、このＣＦＮカウントタイマのティックごとに、１ずつ増分される（ステップ５４２）。ＣｕｒｒｅｎｔＳｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮは、任意のオフセットを含むスケジュールされたターゲットＣＦＮである。したがって、この変数が設定された後に、この変数は、現行のターゲットＣＦＮを表すので、カウンタとして使用される。
【００８６】
（システム処理後に）ＲＬＣバッファ中にデータが存在する場合、データ伝送が開始され、ＣＦＮ＝ＣｕｒｒｅｎｔＳｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮが割り当てられる（ステップ５４４）。変数Ｕｐｄａｔｅ＿Ｔｏ＿ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ＿Ａｄｊｕｓｔｍｅｎｔがゼロに設定され（ステップ５４６）、これを使用して以下で説明するように、ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔに対する調整が追跡される。次いで、この方法は、終了する（ステップ５３０）。
【００８７】
正確なＣＦＮ初期化により、このＲＬＣバッファ中における不必要な初期データの蓄積が回避される。したがって、このＣＦＮ初期化プロシージャは、このトランスポートベアラの確立が完了するとすぐに開始されるべきである。送信すべきこの第１のＤＬデータが、このＲＬＣバッファ中で使用可能になる前に、このプロシージャを完了することが望ましい。ＣＦＮ初期化は、定期的なこのＴＯＡのサンプリングをバックグラウンドプロセスとして実施することにより加速することができる。典型的な商用システムにおいては、このトランスポートベアラは、異なるＱｏＳレベルをサポートするように構成される。ＴＯＡのサンプリングは、各ＱｏＳカテゴリ中のトランスポートベアラについて実施すべきである。トランスポートベアラがセットアップされた後に、正確なＣＦＮ初期化は、ＴＯＡサンプリングを介して収集された既存のＴＯＡ情報を使用して達成することができる。次いで、パラメータｎ、すなわち（トランスポートベアラの確立後の）ＣＦＮ初期化を実行するために必要とされるＴＯＡサンプリング数は、かなり正確な初期ＣＦＮを取得するために小さくすることができる。例えば、このＣＦＮ初期化アルゴリズム中で使用されるＴＯＡ＿ｍｉｎは、トランスポートベアラ確立（ステップ５０２〜５１０）後に計算されるＴＯＡ＿ｍｉｎと、バックグラウンドサンプリングを介して取得されるＴＯＡ＿ｍｉｎとの加重平均とすることができる。
【００８８】
この初期ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ調整計算が、（例えば、ＲＲＣ中の）ＭＡＣ以外のプロセスで実施される場合、このＭＡＣがこの初期調整に適用されてこの初期ＣＦＮを取得するときには、このＭＡＣプロセスが、ステップ５０２において設定されるタイマが提供するティックカウント、およびその対応するＣＦＮカウンタ（ステップ５０４または５１８からのＮの現行値）にアクセスすることができなければ、この初期ＣＦＮの値は、１フレームのオフセットエラーを有する可能性がある。
【００８９】
ＶＩ．ＣＦＮ初期化後のＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ調整の決定
このＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ調整を計算する方法６００は、図６に示されている。方法６００が実施される前に、前述の初期化プロシージャが完了しており、データ伝送が開始されていることが想定される。このシステム中の遅延の可変な性質に起因して、ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔの正確な値は、知られていない。本発明によって計算されるこれらの推定値は、絶えず調整されて、この状態を反映する。
【００９０】
この調整計算は、ＲＲＣプロセスが実装し、このＭＡＣプロセスへと渡すことができ、またこのＭＡＣプロセス中で直接に実施することもできる。好ましい実施形態においては、この調整計算は、このＲＲＣプロセスによってあらかじめ形成され、整数のフレーム数である。方法６００は、このデータフレームが、このＴＯＡウィンドウ内に到着するかどうかを判定することによって開始される（ステップ６０２）。このデータフレームがこのＴＯＡウィンドウ内に到着する場合には、次いで調整は必要でなくなり、この方法は終了する（ステップ６０４）。
【００９１】
データフレームが、このＴＯＡウィンドウ外においてこのノードＢに到着するとき（ステップ６０２）、タイミング調整制御フレームは、このＴＯＡ値と共にこのＲＮＣに送信される（ステップ６０６）。このタイミング調整制御フレームは、フレームがこのノードＢに到着したときに、このフレームのＴＯＡがどれほど不正確かをこのＲＮＣに対して示すＴＯＡ値を含んでいる。このメカニズムにより、このノードＢ上のＦＰ、およびしたがってＬ１は、このＤＬ伝送のタイミングを調整する必要性をこのＲＮＣ（ＦＰおよびＭＡＣ）に対して逆に示すことができるようになる。このタイミング調整（すなわち、このＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔの変更）は、この伝送遅延とこのエアインターフェース上での伝送についてのバッファリング時間を制御し、最小化するために行われる。
【００９２】
例示の一実施形態においては、このノードＢ−セルにおいてフレームが受信されるのが、遅れる（ＴＯＡ＜０）か、あまりにも遅れすぎ（ＴＯＡ＜−ＴＯＡＷＥ）か、あるいはあまりにも早期すぎるか（ＴＯＡ＞ＴＯＡＷＳ）に応じて、異なる調整が、ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔに対して適用される（ステップ６０８）。一実施形態において、このＲＮＣは、このＲＮＣにおける送信時刻に対してではなく、このターゲットＣＦＮに対してこの調整を適用する。したがって、以下で提供する調整計算式は、このようにして除算ファクタ８０を使用して、ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ調整を整数のフレーム数として生成する。このＦＰデータフレームヘッダ中に含まれるターゲットＣＦＮ値もまた、整数のフレーム数として表される。この調整が、このＲＮＣ送信時刻に適用される場合においてさえ、この調整を整数のフレーム数として表現することが依然として望ましい。そうでない場合には、このＣＦＮカウントティックを監視するタイマは、このコアネットワークとの同期を必要とすることもある、時間軸上の異なる開始ポイントに再初期化する必要がある。
【００９３】
フレームがこのノードＢ−セルであまりにも遅く受信される場合、すなわちＴＯＡ＜−ＴＯＡＷＥの場合には、これは、このオフセットが過小評価されたことを示している。したがって、このオフセットは増大させる必要があり、このウィンドウの中間をターゲットにする。これは、保守的なアプローチであり、フレームが脱落されてしまうリスクを低下させる助けをする。ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔに対する調整は、次式のように計算される。
【００９４】
【数１１】
2007525080.tif 000013
【００９５】
あまりにも遅れて到着するフレームは、このＴＯＡウィンドウパラメータの設計がかなり正確であることを仮定すると、このトラフィック負荷のかなり急激な増大を示す表示である。次いで、このタイミング調整アルゴリズムは、速やかに応答してこの状況を補正し、サービス品質における可能性のある悪化を回避する必要がある。
【００９６】
フレームがこのノードＢ−セルにおいて遅れて受信される場合、すなわち、−ＴＯＡＷＥ≦ＴＯＡ＜０である場合には、このフレームは、依然として処理し、このエアインターフェース上で伝送することができる。
【００９７】
【数１２】
2007525080.tif 000014
【００９８】
（ＴＯＡは、この場合に負であり、この調整は正の値であるので）このターゲットＣＦＮを−ＴＯＡ／８０フレームだけ（ＲＦＮに関して）前方に移動させることにより、このトラフィック状態が同じままであると仮定すると、このフレームはこのウィンドウ終了ポイントに到着するはずである。このウィンドウの終了をターゲットとすることにより、このフレームが依然として処理されることになるので、このフレームはバッファされ、または脱落させられる必要があることにはあまりなりそうにない。このウィンドウのエンドポイントは、これらの理由から理想的なターゲットＣＦＮである。ここでの理論的根拠は、使用される以前の暗黙のＲＦＮ＿ＣＦＮオフセットは、ＴＯＡのタイムユニット数だけ遅れて到着するフレームの状況をもたらしていたことである。このオフセットの増大については、このＲＮＣ側においてこのフレームをより早期に送信するものと考えることができる。
【００９９】
フレームが、ノードＢ−セルにおいてあまりにも早期に受信される場合、すなわち、ＴＯＡ＞ＴＯＡＷＳである場合には、これはこの初期オフセットがあまりにも大きすぎたことを示す表示であり、Ｎｅｗ＿ＲＦＮ＿ＣＦＮ＿Ｒｅｌａｔｉｖｅ＿Ａｄｊｕｓｔｍｅｎｔは、式（１８）のように計算される。このターゲットＣＦＮをＴＯＡ／８０フレーム（ＴＯＡは、この場合に正の値である）によって（このＲＦＮに関して）後方に移動させることにより、このトラフィック状態が同じままであると仮定すると、このフレームは、このウィンドウ終了ポイントに到着するはずである。このＮｅｗ＿ＲＦＮ＿ＣＦＮ＿Ｒｅｌａｔｉｖｅ＿Ａｄｊｕｓｔｍｅｎｔ値が計算された（ステップ６０８）後に、この値は、このＭＡＣに送信され（ステップ６１０）、この方法は、終了する（ステップ６０４）。方法６００中で行われる調整に基づいて、このＣｕｒｒｅｎｔＳｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮはまた、これがこのオフセット値に基づいているので変化することになる。
【０１００】
ＶＩＩ．タイミング調整制御フレームの受信に応じてすぐにデータ伝送を遅延させ、または加速させる戦略
このＲＮＣとこのノードＢ−セルの間のデータ伝送パス上のＩｕｒ／Ｉｕｂ遅延およびこれらの処理遅延を仮定すると、このＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ値は、２つの主要な変数、すなわちこのＲＮＣにおける送信時刻（このＭＡＣは、基準送信ポイントとして考えられる）と、このセル上のターゲットＣＦＮ（Ｌ１による送信時刻）によって特徴づけることができる。実際には、このＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔに対する調整は、このＲＮＣにおける送信時刻を移動させるか、またはこのターゲットＣＦＮを移動させるかによって、適用することができる。
【０１０１】
この選択される戦略が、このＲＮＣ上における送信時刻を移動させることである場合、このノードＢ−セルに早期に到着するフレームは、送信すべき将来のフレームもまた、このＲＮＣにおいて遅延させられることになることを意味する。これは、データ伝送について、このノードＢにおける貴重な可能性のある無線フレームが失われていることを意味し、このＲＮＣバッファにおける不必要なデータの蓄積、エンドツーエンド遅延の増大の可能性、および最終的には脱落されるフレームの結果としてのＱｏＳの悪化がもたらされることになる。リアルタイム（ＲＴ）サービスでは、データ伝送を遅延させることにより、データバッファリングがもたらされ、このデータバッファリングは、これらの過酷なエンドツーエンド遅延要件によって関連するＱｏＳ要件と、たぶん矛盾してしまうことになる。しかし、このコアネットワークとの時間的整合プロシージャがサポートされる場合には、このデータ伝送時刻を遅延させる機能を使用して、このタイミング調整を微調整することができる。また、非リアルタイム（ＮＲＴ）サービスでは、このデータフレームは、ＲＴサービスに有利に遅延させることができる。
【０１０２】
フレームが、このノードＢ−セルに遅く、またはあまりにも遅く到着する場合には、次いでこのデータをさらに早期に送信する必要がある。ここでの困難は、明らかなように経過時間は回復することができないので、送信時刻を後に移動することはできないことである。この場合には、ある種のフレームを送信することは手遅れである。これらのフレームは、このＲＮＣにおいてローカルに脱落させられ、あるいはこのノードＢに向かって伝送されることになり、このノードＢ−セル側においてたぶん脱落させられることになり、カスケードするタイミング調整制御フレームを生成する可能性がもたらされることになる。
【０１０３】
この戦略がこのターゲットＣＦＮを移動させることである場合、次いで送信すべき将来のフレームについてのこれらのターゲットＣＦＮは、これらのフレームが遅れて受信されるか、または早期に受信されるかに応じて、前方または後方に移動させられる。この代替形態の欠点は、このＣＦＮを後方へ調整して、データ伝送を遅延させるというシナリオでは、以前に送信されたフレームのターゲットＣＦＮと共に将来のフレームに含められるターゲットＣＦＮのオーバーラップが存在する可能性があり、このセル側上でフレームの衝突がもたらされ、フレームの脱落がもたらされる可能性があることである。このデータをこのエアインターフェース上での伝送にちょうど間に合うように到着させる設計目標を有する、このセル側上の厳密なバッファと、良好なターゲットＣＦＮの初期化を有することによって、この副作用は、制限することができる。本発明は、この第２の戦略を適用して、このターゲットＣＦＮを調整することが好ましい。
【０１０４】
ＶＩＩＩ．基本的アプローチ
ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔに対する（ＲＲＣまたはＭＡＣにより）必要とされるアップデートを計算した後に、このＭＡＣは、図７に示す方法７００によって示されるように送信すべき将来のフレームについてのターゲットＣＦＮを調整する。ＣＦＮ初期化時に、このＣＦＮカウンタ増分を制御するタイマが初期化され、その後実行され、１０ｍｓごとにタイミングティックが提供される。この調整は、このターゲットＣＦＮに対して行われるので、このタイマをこの時間軸上の異なる開始ポイントに再初期化する必要はない。
【０１０５】
方法７００は、このＣＦＮカウンタを増分するタイマ信号を受信するＭＡＣによって開始され（ステップ７０２）、このＣｕｒｒｅｎｔＳｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮ変数は、１だけ増分される（ステップ７０４）。Ｕｐｄａｔｅ＿Ｔｏ＿ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ＿Ａｄｊｕｓｔｍｅｎｔが１に等しいかどうかについての判定が行われ、これは、新しいＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ＿Ａｄｊｕｓｔｍｅｎｔ値が、ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔに対する最後のアップデート以降受信されているかどうかを示している（ステップ７０６）。Ｕｐｄａｔｅ＿Ｔｏ＿ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ＿Ａｄｊｕｓｔｍｅｎｔが１の場合、次いでＮｅｗ＿Ｓｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮは、以下のように計算される（ステップ７０８）。  
New_Schedule_Based_Target_CFN = (CurrentSchedule_Based_Target_CFN + New_RFN_CFN_Offset_Relative_Adjustment/80) mod256                          式（１９）
【０１０６】
次いで、ＣｕｒｒｅｎｔＳｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮは、Ｎｅｗ＿Ｓｃｈｅｄｕｌｅ＿Ｂａｓｅｄ＿Ｔａｒｇｅｔ＿ＣＦＮに設定される（ステップ７１０）。この変数Ｕｐｄａｔｅ＿Ｔｏ＿ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ＿Ａｄｊｕｓｔｍｅｎｔは、ゼロに設定されて（ステップ７１２）、最後のアップデート以来、ＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔに対して変更が存在していないことを示す。次いで、ＴＦＣＩ選択が継続され、このＲＬＣバッファ中にデータが存在する場合にはデータが送信され（ステップ７１４）、この方法は終了する（ステップ７１６）。
【０１０７】
ＩＸ．高度なアプローチ
同じトランスポートベアラ上で幾人かのユーザを多重化し（例えば、同じＡＴＭ仮想チャネルを共用する幾人かのユーザに属するデータフレーム）、または同じ処理デバイスリソースについて競合する場合においては、１ユーザ上での調整が、他のユーザに悪影響を及ぼす可能性がある。高度なアプローチを以下のように実装することができる。  
１．前述のような基本的アプローチを適用する。  
２．ＱｏＳ特性（サービスのタイプおよび受け入れ可能なエンドツーエンド遅延）と、ＴＯＡ統計値に基づいて、ある種のユーザデータは、この基本的アプローチで行われる調整の結果として、遅延または前進させることができる。これは、このトランスポートチャネル同期化プロシージャの定期的な実行を介したＴＯＡサンプルのバックグラウンドでの収集が存在することを想定している。  
３．方法６００において説明したようにこれらの調整を計算し、方法７００に従ってこれらの調整を適用する。ＮＲＴサービスの場合には、この調整は、このターゲットＣＦＮに対する代わりに、この送信時刻に対して適用することができる。例えば、あまりにも早期に到着するフレームの場合に、このＮＲＴサービスのＱｏＳが満たされることを仮定すると、このＲＮＣは、このデータをバッファし、処理能力および他のシステムリソースをＲＴサービスに集中させることができる。
【０１０８】
Ｘ．ＲＮＣ−コアネットワークインターフェース（Ｉｕ）上での時間的整合プロシージャに対する拡張
前述のように、このＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ調整は、このＲＮＣ送信時刻に対して、またはターゲットＣＦＮに対して適用することができる。このＲＮＣにおけるデータ伝送時刻のタイミングは、このコアネットワークにこのデータ伝送の遅延を進めるように指示することにより微調整することができる。特に（例えば１つの無線フレームよりも小さい）小さなＲＦＮ＿ＣＦＮ＿Ｏｆｆｓｅｔ値では、このタイミング調整は、前述の方法と組み合わせて使用することができる。小さなＴＯＡ値でこのノードＢに到着するフレームの場合には、このタイミング整合をこのＲＮＣが排他的に使用して、それに従ってこのコアネットワークにこのデータ伝送を進め、またはこのデータ伝送を遅延させるように指示することができる。このコアネットワーク中においてこのデータ伝送を遅延させることは、（このＲＮＣ側、またはこのノードＢ−セル側における）ＵＴＲＡＮ中の不必要なバッファリングがないことを意味する。より大きいＴＯＡの場合には、このターゲットＣＦＮに対する調整は、フレームスケールに基づいて行うことができ、引き続いてこの時間的整合プロシージャを使用してこの調整を微調整することができる。
【０１０９】
この３ＧＰＰ仕様中に記述されている時間的整合プロシージャ、または同様な任意のプロシージャを使用して、このコアネットワーク（ＧＳＭ  ＡＭＲボコーダ、ＳＭＳセンターなど）にそのダウンリンクデータ伝送タイミングを遅延させ、または進めるように指示することができる。
【０１１０】
本発明の特徴および要素は、特定の組合せの形の好ましい実施形態において説明しているが、各特徴および要素は、（これらの好ましい実施形態の他の特徴および要素なしに）単独で、あるいは本発明の他の特徴および要素を伴い、または伴わない様々な組合せの中で使用することができる。
【０１１１】
本発明の特定の実施形態について示し説明してきたが、当業者なら本発明の範囲を逸脱することなく、多数の変更形態および変形形態を作成することができる。上記説明は、例証するのに役立ち、どのようにも本発明を限定するものではない。
【図面の簡単な説明】
【０１１２】
【図１】無線ネットワーク制御装置（ＲＮＣ）から無線送信／受信ユニット（ＷＴＲＵ）へのダウンリンク伝送時系列を示す図である。
【図２】着信時刻（ＴＯＡ）ウィンドウと、それに関連したパラメータを示す図である。
【図３】ＴＯＡを計算するための方法のフローチャートである。
【図４】ＴＯＡを計算するための別の方法のフローチャートである。
【図５ａ】初期ＣＦＮ値を計算するための方法のフローチャートである。
【図５ｂ】初期ＣＦＮ値を計算するための方法のフローチャートである。
【図６】ＲＦＮ／ＣＦＮオフセット調整を計算するための方法のフローチャートである。
【図７】メディアアクセス制御（ＭＡＣ）についての、ＲＮＣにおけるターゲットＣＦＮ値を調整するための方法のフローチャートである。
【図１】
2007525080.tif 000015
【図２】
2007525080.tif 000016
【図３】
2007525080.tif 000017
【図４】
2007525080.tif 000018
【図５ａ】
2007525080.tif 000019
【図５ｂ】
2007525080.tif 000020
【図６】
2007525080.tif 000021
【図７】
2007525080.tif 000022
【手続補正書】
【提出日】平成17年6月23日(2005.6.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
無線通信システム中でデータフレームを伝送するための方法であって、
ウィンドウ開始（ＷＳ）およびウィンドウ終了（ＷＥ）を含む着信時刻（ＴＯＡ）ウィンドウを作成するステップと、
伝送するためのエアインターフェースにおいて前記データフレームの前記ＴＯＡを決定するステップと、
前記ＴＯＡが前記ＷＳの前にある場合、前記データフレームをバッファするステップと、
前記ＴＯＡが前記ＴＯＡウィンドウ内にある場合に、前記データフレームを伝送するステップと、
前記ＴＯＡが前記ＷＥの後にある場合には、前記データフレームを切り捨てるステップと
を具え、バッファサイズは、少なくともＷＳ値にＷＥ値を加えたものの総和と同程度の大きさであり、総和は、伝送時間間隔値によって除算されることを特徴とする方法。
【請求項２】
前記バッファするステップは、バッファが前記データフレームを記憶するのに十分に大きい場合にしか実施されないことを特徴とする請求項１記載の方法。
【請求項３】
長さＷＥのマージンは、前記マージン中にＴＯＡを有するデータフレームが伝送されるように前記ＷＥの後に存在することを特徴とする請求項１記載の方法。
【請求項４】
前記決定するステップは、
前記データフレームが伝送されると想定されるスケジュールされた時刻を取得するステップと、
前記データフレームの処理時間を推定するステップと
を含み、前記ＴＯＡは、式、すなわち
ＴＯＡ＝（スケジュールされた時刻−処理時間−ＷＥ）−現行の時刻
から決定されることを特徴とする請求項１記載の方法。
【請求項５】
前記データフレームが関連するシステムフレーム番号（ＳＦＮ）を有する場合、次いで前記ＴＯＡは、式、すなわち
ＴＯＡ＝（スケジュールされたＳＦＮｔｉｍｅ−処理時間−ＷＥ）−現行のＳＦＮｔｉｍｅ
から決定され、式中で前記スケジュールされたＳＦＮｔｉｍｅは、前記ＳＦＮが最初に伝送すべきようにスケジュールされた時刻であり、前記現行のＳＦＮｔｉｍｅは、現行のＳＦＮの時刻であることを特徴とする請求項４記載の方法。
【請求項６】
前記データフレームが関連する接続フレーム番号（ＣＦＮ）を有する場合、次いで前記ＴＯＡは、式、すなわち
ＴＯＡ＝（スケジュールされたＣＦＮｔｉｍｅ−処理時間−ＷＥ）−現行のＣＦＮｔｉｍｅ
から決定され、式中で前記スケジュールされたＣＦＮｔｉｍｅは、前記ＣＦＮが最初に伝送すべきようにスケジュールされた時刻であり、前記現行のＣＦＮｔｉｍｅは、現行のＣＦＮの時刻であることを特徴とする請求項４記載の方法。
【請求項７】
前記計算されたＴＯＡ値を評価するステップと、
前記ＴＯＡ値が所定の範囲外にある場合に、前記ＴＯＡ値を調整するステップと
をさらに具えたことを特徴とする請求項４記載の方法。
【請求項８】
無線通信システム中のデータフレームについてのターゲット接続フレーム番号（ＣＦＮ）を計算するための方法であって、
（ａ）前記無線通信システム中の制御フレームの伝送遅延に関連した統計値を収集するステップと、
（ｂ）前記統計値に基づいてベースＣＦＮを計算するステップと、
（ｃ）前記制御フレームについての着信時刻（ＴＯＡ）値を決定するステップと、
（ｄ）前記ＴＯＡ値に基づいてオフセット値を計算するステップと、
（ｅ）前記ベースＣＦＮおよび前記オフセット値に基づいて前記ターゲットＣＦＮを計算するステップと
を具えたことを特徴とする方法。
【請求項９】
ステップ（ｃ）は、複数の制御フレームに基づいて平均ＴＯＡ値を決定するステップを含むことを特徴とする請求項８記載の方法。
【請求項１０】
前記ターゲットＣＦＮを使用して、所定のＴＯＡウィンドウ内の前記データフレームを伝送することを特徴とする請求項８記載の方法。
【請求項１１】
ステップ（ｄ）は、前記ＴＯＡウィンドウの終了をターゲットにする前記オフセット値を計算するステップを含むことを特徴とする請求項１０記載の方法。
【請求項１２】
ステップ（ｄ）は、前記ＴＯＡウィンドウの中間をターゲットにする前記オフセット値を計算するステップを含むことを特徴とする請求項１０記載の方法。
【国際調査報告】
2007525080.tif 000023