JP2009538011A - 低遅延サービスのための双方向ｒｌｃ非永続モード - Google Patents

Abstract

遅延に敏感なアプリケーションに対する転送遅延ＱｏＳ属性は、不完全なデータ・パケットのその時点の有効性を最大データ転送遅延制約に基づいて判定することによって、無線アクセス・ネットワークにおいて実行される。１つの実施形態にしたがって、最大データ転送遅延制約を有するアプリケーションに関連する上位レイヤのパケット・データ・ユニット（ＰＤＵ群）が、１つ以上の上位レイヤＰＤＵに関連するＲＬＣデータ・ブロックの最初の送信に応じてタイマーを開始することによって転送される。タイマーは、最大データ転送遅延制約に基づくタイマー値に初期化される。ＲＬＣデータ・ブロックは、タイマーが切れていない限り、ＲＬＣデータ・ブロックの受信が応答確認されていないことを示す受信メッセージに応じて再送信される。ＲＬＣデータ・ブロックは、タイマー切れること、またはＲＬＣデータ・ブロックの受信が確認応答されていることを示す受信メッセージに応じて、メモリから削除される。
【選択図】 なし

Description

本発明は、一般的には、無線アクセス・ネットワークに関するものであり、そして、特に、無線アクセス・ネットワークによってサービスが提供されるボイスオーバＩＰ（ＶｏＩＰ）のような、遅延に敏感なアプリケーションに対してサービス品質（ＱｏＳ）を維持することに関する。

一部の無線アクセス・ネットワークは、データをパケットにしてルーティングする。たとえば、汎用パケット無線サービス（ＧＰＲＳ）のようなパケット交換無線サービスは、回線交換通信サービスおよびパケット交換の通信サービスの両方を提供するために、全地球移動通信システム（ＧＳＭ）ネットワークのような既存の回線交換ネットワークに追加される。ＧＳＭ拡張型高速データ・レート（ＥＤＧＥ）または高度化ＧＰＲＳ（ＥＧＰＲＳ）は、ＧＰＲＳ／ＧＳＭネットワークにおいてデータ送信レートの向上およびデータ送信信頼性の向上を可能にするデジタル移動電話技術である。ＥＤＧＥでは、拡張信号配列（extended signal constellation）を介して３倍以上の情報を搬送する８−ＰＳＫ変調方式を採用している。

ＧＰＲＳ／ＥＤＧＥ無線ネットワーク（ＧＥＲＡＮ群）は、パケット交換通信をサポートするために、ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）および在圏（serving：サービング）ＧＰＲＳサポート・ノード（ＳＧＳＮ）を含んでいる。ＧＧＳＮは、無線ネットワークと、公衆交換パケット・データ・ネットワークおよび他のＧＰＲＳネットワークと少なくとも一方との間にゲートウェイを提供する。ＧＧＳＮは、認証機能および位置管理機能を実装する。ＳＧＳＮは、無線ネットワークと移動局との間の接続を制御する。ＳＧＳＮは、セッション管理および、ハンドオーバおよびページングのようなＧＰＲＳ移動管理を実行する。回線交換ＧＳＭネットワークの基地局サブシステム（ＢＳＳ）コンポーネントは、パケット交換データ通信をサポートするために更新される。たとえば、パケット制御ユニット（ＰＣＵ）は、パケット・データを無線インタフェースで移動局に転送できるフォーマントに変換するために提供される。

パケット・データは、ＧＥＲＡＮにおいては、いくつかのインタフェースを通して搬送される。各インタフェースでは、データは特定のプロトコルにしたがってパケット化される。たとえば、アプリケーション・データは、ＩＰデータグラムとして、インターネットを介してＧＥＲＡＮに送信される。ＩＰデータグラムは、特定のＩＰアドレスにアドレス指定されているネットワーク・データ・パケット・ユニット（Ｎ−ＰＤＵ）としてＧＧＳＮで受信される。ＧＧＳＮは、Ｎ−ＰＤＵをＧＰＲＳコア・ネットワークを通してトンネルできるようにするＧＴＰヘッダを追加することにより、ＧＰＲＳトンネリング・プロトコル（ＧＴＰ）を使用してＮ−ＰＤＵをカプセル化する。このＧＴＰ−ＰＤＵは、ＵＤＰレイヤに渡される。ＵＤＰレイヤは、ＰＤＵにＵＤＰヘッダを付加する。このヘッダは、発信元（ソース）アドレスおよび宛先ポート・アドレスを示している。ＵＤＰ−ＰＤＵは、その後、ＩＰレイヤに転送される。ＩＰレイヤは、ＳＧＳＮ発信元アドレスおよび宛先アドレスを付加する。ＰＤＵが長すぎる場合には、ＩＰレイヤは、ＰＤＵをより小さいユニットに分割（セグメント化）する。

ＩＰ−ＰＤＵは、Ｎ−ＰＤＵとして扱われるＳＧＳＮに送信される。ＳＧＳＮは、ＧＧＳＮによって付加されている様々なヘッダを取り除き、そして、Ｎ−ＰＤＵをサブネットワーク依存コンバージェンス・プロトコル（ＳＮＤＣＰ：Sub Network Dependent Convergence Protocol）レイヤに提供する。ＳＮＤＣＰレイヤは、Ｎ−ＰＤＵを、根底にあるＧＰＲＳネットワーク・アーキテクチャと互換性があるフォーマットに変換する。終了次第、ＳＮＤＣＰ−ＰＤＵは、論理リンク制御（ＬＬＣ）レイヤに渡される。ＬＬＣレイヤは、ＳＧＳＮと、ＧＥＲＡＮによってサービスが提供されている移動局との間の論理接続を提供する。ＬＬＣレイヤは、ＳＮＤＣＰ−ＰＤＵをＬＬＣヘッダとともにカプセル化する。基地局システムＧＰＲＳプロトコル（ＢＳＳＧＰ）レイヤは、ＬＬＣレイヤの直下に位置しており、そして、ＬＬＣ−ＰＤＵが適切にＢＳＳに（たとえば、フレーム・リレー物理レイヤ上で）ルーティングされるようにルーティング情報を提供する。ＢＳＳＧＰは、ＳＧＳＮとＢＳＳとの間で動作し、すなわち、ＢＳＳＧＰは、無線インタフェースに及ぶことはない。

ＢＳＳで、ＬＬＣ−ＰＤＵは、無線リンク制御（ＲＬＣ）レイヤに提供される。ＲＬＣレイヤは、ＢＳＳと移動局との間に（たとえば、対応するパケット交換サービスのＱｏＳによって要求される場合）信頼性のあるリンクを確立する。ＲＬＣレイヤは、上位レイヤのＰＤＵ（この例では、ＬＬＣ ＰＤＵ）のＲＬＣデータ・ブロックへの分割および再組立を実行する。本明細書では、用語「上位レイヤ」は、ＲＬＣレイヤより上位のプロトコルレイヤを意味する。ＲＬＣデータ・ブロックは、ＲＬＣヘッダ、ＲＬＣデータ・ユニット、およびスペアビットで構成される。ＲＬＣデータ・ブロックは、それから、ブロックをＭＡＣヘッダとともにカプセル化する媒体アクセス制御（ＭＡＣ）レイヤに渡される。ＭＡＣレイヤは、ＲＬＣデータ・ブロックを搬送するために使用されるアップリンクおよびダウンリンクの無線ブロックの割当を含む、無線インタフェースを介するアクセスシグナリングを制御する。次に、データは、物理レイヤを経由して無線インタフェース上で移動局に送信される。この目的を達成するために、テンポラリ・ブロック・フロー（ＴＢＦ）が、ＢＳＳと移動局との間で確立される。ＴＢＦは、ＢＳＳと移動局との間の論理接続であり、その論理接続上でデータが送信される。１つ以上の動的（共用の）または固定の（専用の）パケット・データ・チャネル（タイムスロット）が、ＴＢＦが確立される場合に割り当てられることができる。移動局では、データは物理レイヤで受信され、そして、カプセル化されているヘッダが受信データから取り除かれ、移動局のプロトコル・スタックに移動する。最終的には、元のアプリケーション・データが、アプリケーションレイヤで受信される。

しかしながら、移動局は、たとえば、劣悪な無線状態、送信誤り等のために、ＢＳＳによる最初の送信後、すべてのＲＬＣデータ・ブロックを受信できるとは限らない。同じように、ＢＳＳは、移動局によって送信される任意の所与のＲＬＣデータ・ブロックの最初の送信を受信できるとは限らない。ＲＬＣデータ・ブロックは、３Ｇパートナーシップ・プロジェクト ＲＬＣ／ＭＡＣプロトコル（３ＧＰＰ ＴＳ ４４．０６０ Ｖ７．７．０）のリリース７に定義されているように、矛盾のないパリティ・ビットを有するレイヤ１フレームで受信される場合に受信されたとみなされる。ＲＬＣデータ・ブロックは、また、順不同で受信される可能性がある。送信されたＲＬＣデータ・ブロックの各々は、一連のＲＬＣデータ・ブロック内での当該ＲＬＣデータ・ブロックの位置を示すシーケンス番号を有している。

３ＧＰＰ ＲＬＣ／ＭＡＣプロトコルのリリース７は、ＲＬＣの受信機エンドポイント（endpoint：端点）に、紛失（missing）ＲＬＣデータ・ブロックを３つの方法のうちの１つで処理できるようにする。ケース１：ＲＬＣ応答確認モードで動作している場合、ＲＬＣの受信機エンドポイントは、パケット応答確認／非応答確認（ＡＣＫ／ＮＡＣＫ）メッセージを、ＲＬＣデータ・ブロックが紛失していることを示しているＲＬＣの送信機エンドポイントに送信する。次に、ＲＬＣの送信機エンドポイントは、紛失ＲＬＣデータ・ブロックを再送信する。紛失ＲＬＣデータ・ブロックは、未処理の（非確認応答の（unacknowledged））ＲＬＣデータ・ブロックの数が、ＲＬＣの送信機エンドポイントで大きくなり過ぎることになるような行き詰まりにＲＬＣプロトコルが直面するけれども、ＲＬＣ応答確認モードで無制限に再送信される。ケース２：ＲＬＣ非応答確認モードで動作している場合、ＲＬＣの送信機エンドポイントは、ＲＬＣデータ・ブロックを再送信しない。したがって、ＲＬＣ非応答確認モードでは、紛失ＲＬＣデータ・ブロックは、ＲＬＣの受信機エンドポイントで無視される。ケース３：ＲＬＣ非永続モードでは、ＲＬＣデータ・ブロックの再送信は、制限回数だけ可能である。しかしながら、全てのＲＬＣデータ・ブロックは、ＲＬＣの受信機エンドポイントで正しく受信されることは必要とされない。

ＲＬＣ応答確認モードに対して、ＲＬＣのエンドポイントは、ブロック・シーケンス番号（ＢＳＮ）に基づいてＲＬＣデータ・ブロックのスライディング・ウィンドウを維持する。スライディング・ウィンドウは、所定の幅（たとえば、ＧＰＲＳでは６４ブロック、そして、ＥＤＧＥでは６４から１０２４ブロックまで）を有する。ＲＬＣの受信機エンドポイントは、スライディング・ウィンドウ内で全ての紛失ＲＬＣデータ・ブロックの再送信を、パケットＡＣＫ／ＮＡＣＫメッセージを介して要求し続ける。ＲＬＣ応答確認モードに関連するこの従来のスライディング・ウィンドウに基づく方法は、また、ＲＬＣ非永続モードに対しても使用される。従来のスライディング・ウィンドウに基づく方法は、ＲＬＣデータ・ブロックが受信側のＲＬＣエンドポイントにより否定的に応答確認（ＮＡＣＫ）されるべきか、または送信側のＲＬＣエンドポイントによって再送信されるべきかを判定するために使用される。しかしながら、その方法は、受信側のＲＬＣエンドポイントがＮＡＣＫを送信側のＲＬＣエンドポイントに送信すること、および紛失ＲＬＣデータ・ブロックの連続再送信に関連する、比較的長いラウンド・トリップ信号伝搬時間を考慮すると、ＶｏＩＰのような遅延に敏感なアプリケーションに対しては、ＱｏＳの課題をもたらす。ＶｏＩＰのような遅延に敏感なアプリケーションは、ユーザの観点からの十分なＱｏＳを保証するために満足しなければならない最大パケット・データ送信遅延制約を有する。たとえば、ＶｏＩＰに対して話し手から聞き手までの最大音声フレーム伝搬は、典型的には、３００ミリ秒以下である。３００ミリ秒の遅延後に受信される紛失音声フレームは、音声通話品質の劣化をユーザが感じることになる可能性がある。

たとえば、現状の無線状態に基づいて、低スループットの変調および符号化（コーディング）方式（たとえば、ＭＣＳ−１）は、ＶｏＩＰサービスをサポートするために確立される双方向ＴＢＦに対する符号化方式として選択される。特定の形式のヘッダ圧縮（たとえば、ロバスト性のあるヘッダ圧縮、すなわち、ＲＯＨＣ）が、また、ＴＢＦが（たとえば、ＳＮＤＣＰレイヤにより）確立される場合に取り決められる。したがって、１つ以上のＲＬＣデータ・ブロックは、ＳＮＤＣＰにより適用されるヘッダ圧縮を伴うＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵの各々に対して無線インタフェースで送信される（すなわち、ＶｏＩＰに対して、完全なプロトコル・スタックは、１つ以上のＲＬＣデータ・ブロックによって搬送されるＲＴＰ／ＵＤＰ／ＳＮＤＣＰ／ＬＬＣ ＰＤＵを含んでいる）。さらに、低転送遅延属性を有するパケット・サービス（ＶｏＩＰのような）に対して、ＲＬＣ非永続モードが、スライディングＲＬＣウィンドウの適用を受ける全てのＲＬＣデータ・ブロックを本質的に有効で、そして常に再送信を前提とすると考えることからもたらされる課題を回避するために、ＲＬＣ応答確認の代わりに選択される。このように、制限回数分の再送信は、音声フレームを無線インタフェースで搬送する場合に、ＶｏＩＰアプリケーションによって許容される最大総転送遅延を超えることなく許容できる低フレーム誤りレートを達成することを目指して、ＲＬＣデータ・ブロックの各々に対して（必要であれば）行われることができる。換言すれば、ＲＬＣ非永続モードは、スライディングＲＬＣウィンドウ概念の使用を依然として維持しながら（但し、ＲＬＣデータ・ブロックの有効性を判定するために使用するのではなく）、ＴＢＦセットアップ時に確立されている（受信側および送信側のＲＬＣエンドポイントの両方に適用できる）転送遅延閾値を考慮することに基づいて、ＲＬＣデータの有効性を確立する。

ＲＬＣウィンドウ・サイズは、明示的な制御プレーン信号方式（シグナリング）によって確立され、そして、ＲＬＣ応答確認モードおよびＲＬＣ非永続モードの両方に対して構成される。ＲＬＣ非永続モードに対して依存として構成されるけれども、この場合におけるＲＬＣウィンドウ・サイズは、スライディングＲＬＣウィンドウ内でシーケンス番号を有する紛失ＲＬＣデータ・ブロックが有効と考えられる（すなわち、受信側のＲＬＣエンドポイントで待ち合わされている（expect）と依然として考えられ、そして、送信側のＲＬＣエンドポイントによって再送信を前提としていると依然として考えられる）か否かを判定するためには使用されない。固定のＲＬＣウィンドウ・サイズに依存することが、遅延に敏感なアプリケーション（ＶｏＩＰのような）に対して、紛失ＲＬＣデータ・ブロックの有効性を判定するには十分ではないことを立証するために、以下の例を示す。

名目上の固定のＲＬＣウィンドウ・サイズは、所与の変調および符号化方式（Modulation and Coding Scheme：ＭＣＳ）に必要なＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵを搬送するために必要となるＲＬＣデータ・ブロックの比率Ｘに基づいて、（最初のＴＢＦ確立時に）確立できる。ＭＣＳ−１、音声（ＲＴＰ）フレームあたり２０ミリ秒の音声およびＸ＝２を想定すると、ウィンドウ・サイズは、たとえば、８Ｘに設定でき、これは８ＲＴＰフレーム（ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵｓ）を搬送する１６ＲＬＣデータ・ブロックを意味しており、そして、したがって、１６０ミリ秒前の音声ペイロードは有効と考えられるであろう。時間が経過するにつれて、無線状態は、各ＲＬＣデータ・ブロックのペイロード負担能力が２倍に（たとえば、ＭＣＳ−４に）なるように改善される場合がある。この時点で、ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵを送信するために必要なＲＬＣデータ・ブロックの数は半分にされる（すなわち、Ｘは１に減る）。このようにして、ＲＣＬウィンドウ・サイズによって可能になる１６以下のＲＬＣデータ・ブロックを用いて、３２０ミリ秒前のＲＴＰフレームは、当初確立されているウィンドウ・サイズに基づいて事実上有効と考えられるであろう。ＲＴＰフレームを無線インタフェースを通して搬送するために許容される時間内でのそのような変動は、ＶｏＩＰアプリケーションに対するＱｏＳ遅延属性を超えるという結果になりうる。勿論、無線状態は、本明細書で考えているＭＣＳ−４よりもよくなる場合があり、３２０ミリ秒よりもさらに前にバッファされているＲＬＣデータ・ブロックが、それで有効と考えられるであろう。この固定のＲＬＣウィンドウ・サイズによる方法は、紛失ＲＬＣデータ・ブロックがＶｏＩＰアプリケーションに対するＱｏＳ遅延属性を超える期間、紛失しているとしても依然として待ち合わせる、ＲＬＣの受信機エンドポイントで同じような課題を引き起こす。また注目すべきは、ＲＬＣウィンドウ・サイズを無線状態が変化するにつれて動的に再度取り決めるいかなる試みも、実際上煩わしすぎる（すなわち、制御プレーン信号を必要とする）であろうし、そして、実際にＱｏＳ劣化体験として実感されるであろうサービス中断を発生させる結果となる場合がある。

名目上の固定のＲＬＣウィンドウ・サイズによる方法は、また、次の例で示されるように、ＲＴＰ音声フレームをこれ以上有効ではないと時期尚早に考えられてしまうようにさせる可能性がある。最初のＴＢＦの確立中に選択されているＭＣＳ符号化方式が、少し高位（たとえば、ＭＣＳ−４）である場合、平均Ｙ個のＲＬＣデータ・ブロックが、無線インタフェースで送信される各ＲＴＰフレーム（ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵ）を搬送するために必要である。ＭＣＳ−４、音声（ＲＴＰ）フレームあたり２０ミリ秒の音声およびＹ＝１を想定すると、ウィンドウ・サイズは、たとえば、８Ｙに設定でき、これは、８ＲＴＰフレーム（ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵｓ）を搬送する８ＲＬＣデータ・ブロックを意味し、そしてしたがって、１６０ミリ秒前の音声ペイロードは有効と考えられるであろう。時間が経過するにつれて、無線状態は劣化する場合があり、各ＲＬＣデータ・ブロックのペイロード負担能力が半分に（たとえば、ＭＣＳ−１に）される。これが発生する場合、ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵの各々に対して送信されるＲＬＣデータ・ブロックの数は、２倍になる（すなわち、Ｙが２に増加する）。したがって、従前に確立されているウィンドウ・サイズが、今度は、８０ミリ秒以内の音声ペイロードを含むＲＬＣデータ・ブロックが有効であると考えられるようにできる。このように、無線状態が劣化する場合、（送信側のＲＬＣエンドポイントで）バッファされているＲＬＣデータ・ブロックまたは（受信側のＲＬＣエンドポイントで）紛失ＲＬＣデータ・ブロックが有効であると考えられる時間は極端に短くなる場合があり、その結果、不必要に高い音声フレーム誤りレートをもたらすことになる。

他の例では、ＭＣＳ方式、ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵ当たりのＲＬＣデータ・ブロック数、ヘッダ圧縮、１つのＲＴＰフレームで搬送される音声サンプルのサイズおよびウィンドウ・サイズは、最初の２つの例におけると同一である。しかしながら、今度は、音声ペイロードのフローでの一時的な停止（たとえば、ユーザが話を中断する場合）を考える。固定のＲＬＣウィンドウ・サイズによる方法は、今度の場合も、次のように最適なパフォーマンスより劣る結果になるであろう。ユーザが話を中断する場合、ＲＬＣの送信機エンドポイントは、管理フレームまたは「キープ・アライブ（keep alive）」フレーム（すなわち、ＳＩＤフレームとしても知られる無音記述子フレーム（Silence Descriptor frames））を依然として生成する場合がある。ＳＩＤフレームは、ＲＴＰフレームより少ないペイロードを含み、そして、ＲＴＰフレームより送信される頻度は少ない（たとえば、第８ＲＴＰフレームごとに相当）ので、ＲＬＣデータ・ブロックが送信される総合レートは、送信が必要な実際の音声フレームがない期間では著しく減少する。しかしながら、これはバッファリング要求の減少をもたらす可能性があり、要求の減少が、今度は、無音期間に入る前にバッファされている音声フレーム・ペイロードを含むＲＬＣデータ・ブロックが、ＲＬＣウィンドウ・サイズが固定で、そしてウィンドウの終端に達するのに長く時間が掛かるので（すなわち、無音期間の間に遭遇するＲＬＣデータ・ブロックのスループットレートが減少するために）、過度に長期間にわたって有効と考えられる結果となる可能性がある。（音声フレーム・ペイロードを含む）ＲＬＣデータ・ブロックが有効と考えられる時間を伸ばすことは、したがって、上述のように、ＶｏＩＰアプリケーションに対するＱｏＳ遅延属性を超える結果となりうる。今度の場合も、この同一のシナリオが、紛失ＲＬＣデータ・ブロックが然るべき期間よりも長く有効であると考えられる（すなわち、依然として待ち合わせる）ＲＬＣの受信機エンドポイントで同じような課題を生じうる。

さらにもう１つの例では、ＭＣＳ方式、ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵ当たりのＲＬＣデータ・ブロック数、ヘッダ圧縮、１つのＲＴＰフレームで搬送される音声サンプルの大きさおよびウィンドウ・サイズは、最初の２つの例におけると同一である。しかしながら、今度は、ＴＢＦの確立中のヘッダ圧縮効率が低く、その後に時間が経過するにつれて圧縮効率がその後増加する（すなわち、向上する）と考える。圧縮効率の変化が、それからまた、ＶｏＩＰセッションが最初に確立されていて、そして良好なレベルの圧縮効率が確立されてから十分たってから、（たとえば、ハンドオーバを使用して遂行されるセル変更のために）生じる場合がある。圧縮効率が低い期間中は、各ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵを送信するために必要なＲＬＣデータ・ブロックの数は（すなわち、ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵ数は、圧縮効率が低い期間中はより大きいので）高い。さらに、最初のＴＢＦ確立時に確立される固定のＲＬＣウィンドウ・サイズは、典型的には、定常状態の間に適用できるような比較的高い圧縮効率を想定する。したがって、圧縮効率が低い期間中は、ＲＬＣデータ・ブロックが、固定の（但し、スライディングの）ＲＬＣウィンドウから外れるようにすぐに考えられるようになる場合があり、そして、それ故、実際にＲＬＣデータ・ブロックが、相当するＶｏＩＰアプリケーションの遅延ＱｏＳ属性によって許容される転送遅延時間の十分範囲内にある場合に、（送信側および受信側のＲＬＣエンドポイントの両方によって）無効であると扱われるようになる場合がある。

本明細書で教示される方法および装置にしたがって、（ＶｏＩＰのような）遅延に敏感なパケット・サービスに対する転送遅延ＱｏＳは、無線アクセス・ネットワーク内において、受信側のＲＬＣエンドポイントおよび送信側のＲＬＣエンドポイントの両方でパケット・データのペイロードの有効性をスライディングＲＬＣウィンドウ・サイズ方法ではなく最大データ転送遅延制約に基づいて判定することによって、満足することができる。送信機側では、タイマーに基づくパケット・バッファリング方法が、ＶｏＩＰデータ・パケットのような遅延に敏感なパケット・データを送信する場合に採用される。送信されるパケット・データは、最初のＴＢＦ確立時に確立される転送遅延時間値（すなわち、ここでは、割り当てられる転送遅延値は、割り当てられたＴＢＦによってサポートされるパケット・データ・アプリケーションに対する転送遅延ＱｏＳ属性の反映である）によって判定される期間の間バッファされる。バッファされたＲＬＣデータ・ブロックは、対応する転送遅延タイマーが切れてから削除され、それ故、削除された（そして、これ以上有効ではない）ＲＬＣデータ・ブロックのその後の再送信を防止する。

受信側では、タイマーに基づくパケット再送信要求方法が、ＲＬＣデータ・ブロックが紛失したと検出される場合に同様に採用される。受信機で紛失したと検出されるＲＬＣデータ・ブロックは、対応する転送遅延タイマーが切れるまで、受信されるものとして待ち合わされる。対応する転送遅延タイマーが切れる場合、紛失ＲＬＣデータ・ブロックは、これ以上受信されるものとしては待ち合わされない。次に、対応するアプリケーションレイヤには、１つ以上の紛失ＲＬＣデータ・ブロックがこれ以上待ち合わされることはない、ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵの部分的に不完全なもの（すなわち、誤ったもの）が提供される可能性がある。

最大データ転送遅延制約は、アプリケーション・タイプに依存することが好ましい。無線インタフェース上でのデータ転送遅延は、ＶｏＩＰデータ・パケットに対してほぼ１００ミリ秒である。そのようなものとして、最初の送信後、約１００ミリ秒の間にバッファされたままの送信ＲＬＣデータ・ブロックは、ＲＬＣの送信機エンドポイントでメモリから削除される。同様に、ＲＬＣの受信機エンドポイントで、ＲＬＣデータ・ブロックは、最初に紛失したと検出されてからほぼ１００ミリ秒の間待ち合わされ続け、その後にＲＬＣデータ・ブロックは無効化されることになる。他の実装形態では、パケット・データ転送遅延属性の値は、マルチメディアブロードキャストマルチキャスト・サービス（ＭＢＭＳ）に基づくアプリケーションに対して、ほぼ３秒以下である。

１つの実施形態にしたがって、最大データ転送遅延制約を有するアプリケーションに関連する上位レイヤのパケット・データ・ユニット（ＰＤＵ群）は、１つ以上の上位レイヤＰＤＵ（たとえば、ＬＬＣ ＰＤＵ群）に関連するＲＬＣデータ・ブロックの最初の送信に応じて、タイマーを開始することによって転送される。タイマーは、最大データ転送遅延制約に基づいているタイマー値に初期化される。タイマーが切れていない限り、ＲＬＣデータ・ブロックは、その受信が応答確認されていないことを示す受信メッセージに対応して再送信される。ＲＬＣデータ・ブロックは、タイマー切れまたは受信が応答確認されていないことを示す受信メッセージに応じて、メモリから削除される。タイマーの値は、最初のＴＢＦ確立時に（たとえば、対応するパケット・サービスの転送遅延ＱｏＳ属性に基づいて）判定できる。

他の実施形態にしたがって、受信側のＲＬＣエンドポイントは、１つ以上の上位レイヤＰＤＵに関連する１つ以上の送信されたＲＬＣデータ・ブロックのシーケンスの中で、紛失ＲＬＣデータ・ブロックを検出する。タイマーは、紛失ＲＬＣデータ・ブロックの検出に応じて開始される。タイマーは、最大データ転送遅延制約に基づいているタイマー値に初期化される。紛失ＲＬＣデータ・ブロックは、タイマーが切れるまでは受信されるものとして待ち合わされる。紛失ＲＬＣデータ・ブロックは、タイマーが切れる時点でメモリから削除されても良い。

もちろん、本発明は上述の特徴および長所に限定されない。当業者は、以下の詳細な明細書を理解し、そして、添付の図面を参照することで、更なる特徴および長所を認識するであろう。

無線アクセス・ネットワークの１つの実施形態のブロック図である。 最大データ転送遅延制約に基づいて、送信されたデータ・パケットを送信機でバッファするための処理ロジックの実施形態を示する図である。 最大データ転送遅延制約に基づいて、紛失データ・パケットを受信機で処理するための処理ロジックの実施形態を示す図である。

図１は、ＧＰＲＳ／ＥＤＧＥ無線アクセス・ネットワーク（ＧＥＲＡＮ）１００の実施形態を示している。ＧＥＲＡＮ１００は、回線交換通信とパケット交換通信の両方をサポートする。ＧＥＲＡＮ１００は、ダウンリンクＴＢＦとしても知られるダウンリンク通信チャネル１０４上で、移動電話のような移動装置１０２にデータ・パケットを送信する。勿論、ＧＥＲＡＮ１００は、マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のようなポイント・ツー・マルチポイント送信方法を使用して、同一のデータ・パケットを複数のデバイス（不図示）に送信することもできる。説明を簡単にするだけのために、ＧＥＲＡＮ１００の動作を、本明細書では、ＧＥＲＡＮ１００と単一の移動装置１０２との間のポイント・ツー・ポイント通信リンクに関して説明する。しかしながら、当業者は、本明細書で開示される技術がポイント・ツー・マルチポイント送信方式に等しく適用することを容易に理解するであろう。

ＧＥＲＡＮ１００は、ＶｏＩＰデータ・パケットのような遅延に敏感なデータ・パケットを送信する場合に、タイマーに基づくパケット・バッファリング方法（timer-based packet buffering approach）を実装する。タイマーに基づくパケット・バッファリング方法は、対応するＲＬＣデータ・ブロックがスライディングＲＬＣウィンドウ内に留まっているか否かに基づいて、パケット・データのその時点での有効性は判定しない。その代わりに、送信されたデータ・パケットは、サービスが提供されているアプリケーションに対応する転送遅延ＱｏＳ属性によって判定される時間の間、ＧＥＲＡＮ１００によってバッファされる。サービスが提供されているアプリケーションによって示される送信時間の制約は、本明細書では、最大データ転送遅延と呼んでいる。最大データ転送遅延は、データ・パケットの送受信に許容される最大の時間に相当し、最大の時間を超えるとパケットは無効と考えられ、そして、最大の時間は、サービスが提供されている、遅延に敏感なアプリケーションの転送遅延ＱｏＳ属性によって判定される。ＢＳＳ１２２または移動装置１０２に配置されている、送信側のＲＬＣエンドポイントで、送信された上位レイヤのＰＤＵ（すなわち、ＬＬＣ ＰＤＵ）の各々は、サービスが提供されているアプリケーションによって示されるデータ転送遅延に相当する時間の間（１つ以上のＲＬＣデータ・ブロックを使用して）バッファされる。バッファされたＲＬＣデータ・ブロックは、許容されるデータ転送遅延を超えて格納された場合に削除され、このようにして、後でより詳細に説明するように、遅延に敏感なアプリケーションの転送遅延ＱｏＳ属性の遵守を保証する。

ＢＳＳ１２２において、バッファされたＲＬＣデータ・ブロックは、移動装置１０２からの要求で、たとえば、否定的に応答確認されたパケットに応じて（すなわち、ＲＬＣ非永続モードで、移動装置１０２から受信されるパケットＮＡＣＫメッセージに応じて）、再送信に利用できる。パケットＮＡＣＫメッセージは、たとえば、ＲＬＣデータ・ブロックが移動装置１０２で順不同で受信されているために、ＲＬＣデータ・ブロックが移動装置１０２によって受信されていないことを示すものである。このように、ＢＳＳ１２２は紛失ＲＬＣデータ・ブロックを移動装置１０２に、対応するデータ転送遅延が超過していないかぎり再送信する。さらに、順不同のＲＬＣデータ・ブロックを識別すると、移動装置１０２は、紛失ＲＬＣデータ・ブロックを待ち合わせ続けようとする期間を判定するために使用される、対応するタイマー１３２を開始する。タイマー１３２が切れると、移動装置１０２は、紛失ＲＬＣデータ・ブロックまたは同一の上位レイヤＰＤＵに対応する任意の他の更なるＲＬＣデータ・ブロックをこれ以上待ち合わせないので、不完全な（すなわち、誤った）上位レイヤＰＤＵを生成しうる。不完全な上位レイヤＰＤＵを生成することは、この場合、全く上位レイヤＰＤＵを生成しないよりは有益となりうる。１つの実施形態では、無線インタフェースのデータ転送遅延は、ＶｏＩＰデータ・パケットに対してほぼ１００ミリ秒である。バッファされているＶｏＩＰデータ・パケット（すなわち、所与のデータ・パケットを送信するために使用される全てのバッファされたＲＬＣデータ・ブロック）は、対応するパケット応答確認（パケットＡＣＫ）メッセージが移動装置１０２から受信される前に１００ミリ秒以上格納されていると、削除され、このようにして、ＶｏＩＰアプリケーションに対するＱｏＳを実行する。

移動装置１０２は、アップリンク通信に対して、同様のタイマーに基づくパケット再送信要求方法を実装する。アップリンク通信中、ＢＳＳ１２２は、アップリンクＴＢＦとしても知られるアップリンク通信チャネル１０６上で移動装置１０２からＲＬＣデータ・ブロックを受信する。この実施形態にしたがって、ＢＳＳ１２２は、紛失ＲＬＣデータ・ブロックの再送信を、たとえば、移動装置１０２にパケットＮＡＣＫメッセージを送信することによって要求する。ＢＳＳ１２２は、アプリケーションによって要求されるデータ転送遅延が、ダウンリンク通信チャネル１０４上で送信されるパケット・データに対して、上述の方法と同様の方法で超過してしまうまで、紛失ＲＬＣデータ・ブロックを受信するものとして待ち合わせる。このことが発生すると、ＢＳＳ１２２は、紛失ＲＬＣデータ・ブロックまたは同一の上位レイヤのＰＤＵに対応する任意の他の更なるＲＬＣデータ・ブロックを受信することをこれ以上待ち合わせないので、不完全な（すなわち、誤った）上位レイヤＰＤＵを直ちに生成する場合がある。

移動装置１０２は、同様のタイマーに基づくパケット・データ・バッファリングおよび、遅延に敏感なアプリケーションにサービスを提供する場合にＢＳＳ１２２によって使用される再送信要求方法を実装する。すなわち、移動装置１０２は、アップリンク通信チャネル１０６上で送信するＲＬＣデータ・ブロックを、ＲＬＣデータ・ブロックがサービスが提供されているアプリケーションによって要求される最大データ転送遅延により許容される以上に長くバッファされるまで格納する。データ転送遅延で示されるように許容されるよりも長くバッファされたＲＬＣデータ・ブロックは、削除される。ダウンリンク構成では、移動装置１０２は、最大データ転送遅延制約を超えるまでは、ダウンリンク通信チャネル１０４上で紛失ＲＬＣデータ・ブロックを受信するものとして待ち合わせる。対応するパケット・データ転送遅延ＱｏＳ属性で示されるよりも長く紛失しているＲＬＣデータ・ブロックは、移動装置１０２によってこれ以上待ち合わされない。このように、転送遅延ＱｏＳ属性は、サービスが提供されている、遅延に敏感なアプリケーションに対して実行される。

たとえば、ＭＣＳ−１のような低スループットの変調および符号化方式は、無線状態が劣悪な場合に使用できる。ＲＴＰ／ＵＤＰ／ＩＰ ＰＤＵのようなＶｏＩＰデータを搬送するために使用される上位レイヤのパケット・データ・ユニット（ＰＤＵ）の各々は、ＭＣＳ−１を使用して符号化される場合、２０ミリ秒の音声データを含むことができる。符号化方式は、無線状態が改善される場合、たとえば、ＭＣＳ−４にアップグレードすることができる。上位レイヤのＶｏＩＰ ＰＤＵを送信するために必要なＲＬＣデータ・ブロックの数は、符号化方式がＭＣＳ−１からＭＣＳ−４にアップグレード場合には、半分にされる。ＶｏＩＰアプリケーションによって特定される最大データ転送遅延制約は、したがって、無線状態が遅延に敏感なアプリケーションの経過中にどのように変化し得るかとは無関係に一定のままである。

更に詳細には、ＧＥＲＡＮ１００は、ＧＥＲＡＮ１００と公衆交換電話網（ＰＳＴＮ）１１０との間にゲートウェイを提供するためのＧＳＭゲートウェイ移動交換局（ＧＭＳＣ）１０８を含んでいる。ＧＥＲＡＮ１００は、また、回線交換通信をサポートするために移動サービス交換局（Mobile services Switching Center：ＭＳＣ）および訪問先ロケーション・レジスタ（Visitor Location Register：ＶＬＲ）１１２を含んでいる。ＭＳＣ／ＶＬＲ１１２は、回線交換機能を実行して、他の回線交換ネットワーク（不図示）への接続を提供し、そして、回線交換サービスを提供するために必要な加入者情報を含んでいる。中央データベース１１４は、ＧＥＲＡＮ１００を使用することを認可されている各移動電話加入者に関連する情報を含むホーム・ロケーション・レジスタ（Home Location Register：ＨＬＲ）を維持している。

ＧＥＲＡＮ１００は、さらに、パケット交換通信をサポートするための補完的な構成要素を含んでいる。ゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）１１６は、ＧＥＲＡＮ１００と、公衆交換パケット・データ・ネットワーク１１８および他のＧＰＲＳネットワーク（不図示）の少なくとも一方との間のゲートウェイを提供する。ＧＧＳＮ１１６は、認証および位置管理の機能を実装する。ＧＥＲＡＮ１００は、また、ＧＥＲＡＮ１００と移動装置１０２との間の接続を制御する在圏（サービング）ＧＰＲＳサポート・ノード（ＳＧＳＮ）１２０を含んでいる。ＳＧＳＮ１２０は、セッション管理および、ハンドオーバおよびページングのようなＧＰＲＳ移動管理を実行する。ＳＧＳＮ１２０は、ＳＧＳＮアドレスを格納し、そして、ＧＰＲＳ加入者データおよびルーティング情報を維持する中央データベース１１４によって維持されるＧＰＲＳレジスタへのアクセスを有している。ＧＥＲＡＮ１００は、さらに、移動装置１０２とＧＥＲＡＮ１００との間でトラヒックおよび信号を処理するための基地局サブシステム（ＢＳＳ）１２２を含んでいる。ＢＳＳ１２２は、音声チャネルをトランスコード（transcode）し、無線チャネルを割り当て、ページングを実行し、無線インタフェース上での送受信品質を管理し、また、当業者には周知のＧＥＲＡＮ１００に関連している多くの他のタスクを管理する。

説明を簡単にするだけのために、ＢＳＳ１２２および移動装置１０２の動作を、ＢＳＳ１２２から移動装置１０２へのダウンリンクデータ・パケット転送に関して次に説明する。そのようなものとして、ＢＳＳ１２２は、移動装置１０２に（１つ以上のＲＬＣデータ・ブロックを使用して搬送される）データ・パケットを送信する場合、タイマーに基づくパケット・バッファリング方法を実装する。移動装置１０２は、ＢＳＳ１２２からデータ・パケットを受信する場合、タイマーに基づく再送信要求方法を実装する。しかしながら、アップリンク構成では、タイマーに基づくパケット・データ・バッファリング方法は、移動装置がＢＳＳ１２２にデータ・パケットを送信する場合、移動装置１０２によって実装される。これに対応して、アップリンクの場合、ＢＳＳ１２２は、アップリンク通信チャネル１０６上で移動装置１０２からデータ・パケットを受信する場合、タイマーに基づく再送信要求方法を実装する。これを理解した上で、本明細書で使用する用語「無線受信機」は（１つ以上のＲＬＣデータ・ブロックを使用して搬送される）データ・パケットを受信する装置を意味するものとし、そして、本明細書で使用する用語「無線送信機」は、データ・パケットを送信する装置を意味するものとする。

次に、ＢＳＳ１２２について見てみると、ＢＳＳ１２２に含まれるプロセッサ１２４は、プロトコル・スタック管理を含むデータ・パケット操作を管理する。ＢＳＳプロセッサ１２４は、全てをハードウェアで実装されても良く、あるいは、一部をハードウェアおよび一部をソフトウェアで実装されても良く、または完全にソフトウェアで実装されても良い。これに関係することなく、ＢＳＳプロセッサ１２４は、移動装置１０２とＳＧＳＮ１２０との間でコヒーレント通信を可能にする。たとえば、ＳＧＳＮ１２０は、論理リンク制御（ＬＬＣ）プロトコルレイヤのような上位レイヤのプロトコルレイヤを使用してＢＳＳ１２２と通信する。移動装置１０２は、媒体アクセス制御（ＭＡＣ）のような低位のプロトコルレイヤおよびＲＬＣプロトコルレイヤでＢＳＳ１２２と通信する。ＢＳＳプロセッサ１２４は、上位レイヤのＬＬＣ ＰＤＵを、ＲＬＣおよびＭＡＣブロックに変換し、またその逆変換も行う。

ＢＳＳプロセッサ１２４は、また、（１つ以上のＲＬＣデータ・ブロック内で搬送される）データ・パケットを、ＧＰＲＳ／ＥＤＧＥパケット・データ・トラヒック・チャネル（ＰＤＴＣＨ）のような固定または動的なダウンリンク通信チャネル１０４上で移動装置１０２に送信する場合に、パケット・バッファリングを管理する。ＢＳＳプロセッサ１２４は、ＶｏＩＰパケット・データのようなアプリケーション・データから、ＲＬＣデータ・ブロックを生成する。ダウンリンクＶｏＩＰパケット・データは、ＩＰデータグラムとしてＧＥＲＡＮ１００に到達する。ＧＧＳＮ１１６およびＳＧＳＮ１２０は、一群のＬＬＣ ＰＤＵとしてＢＳＳ１２２に到達するＶｏＩＰデータを処理する。ＢＳＳプロセッサ１２４は、ＢＳＳプロトコル・スタックに基づいて、ＬＬＣ ＰＤＵをＲＬＣデータ・ブロックに変換する。ＢＳＳプロセッサ１２４は、それから、テンポラリ・ブロック・フロー（ＴＢＦ）確立メッセージ、たとえば、パケットダウンリンク割当メッセージを生成する。ＴＢＦ確立メッセージは、移動装置１０２に送信される。それに応えて、ＴＢＦがＢＳＳ１２２と移動装置１０２との間で確立される。ここで、ＴＢＦは、ＲＬＣデータ・ブロックが転送される動的な物理接続である。

各ＲＬＣデータ・ブロックは、送信される前に、たとえば、図２のステップ２００で示されるように、ＢＳＳ１２２に含まれるバッファ１２６に格納される。次に、ＲＬＣデータ・ブロックは、ダウンリンク通信チャネル１０４上で、たとえば、図２のステップ２０２で示されるように、送信される。ＢＳＳプロセッサ１２４は、ＲＬＣデータ・ブロックが送信される毎に、プロセッサ１２４に含まれるまたは関連するタイマー１２８を開始する。タイマー１２８は、対応するＶｏＩＰアプリケーションに対する最大データ転送遅延制約に基づいている値に初期化される。データ転送遅延制約は、ＳＧＳＮ１２０とＧＧＳＮ１１６の両方に存在するパケット・データ・プロトコル（ＰＤＰ）コンテキスト・データ構造の一部として確立される転送遅延ＱｏＳ属性から導出することができ、このＰＤＰコンテキスト・データ構造は、起動されるＰＤＰコンテキストの各々に適用できる加入者セッションＱｏＳ属性を含んでいる。１つの実施形態では、アプリケーションは、ＶｏＩＰに基づいていて、そして、データ転送遅延は、ほぼ１００ミリ秒である。したがって、タイマー１２８は、ほぼ１００ミリ秒の値に初期化される。他の実施形態では、アプリケーションはＭＢＭＳに基づいている。この実施形態にしたがって、タイマー１２８は、ほぼ３秒以下のデータ転送遅延の値に初期化される。

タイマー１２８は、対応するＲＬＣデータ・ブロックがＢＳＳ１２２によって最初に送信される場合、たとえば、図２のステップ２０４で示されるように、初期化された状態からカウントダウンされ始める。ＢＳＳプロセッサ１２４は、たとえば、図２のステップ２０６で示されるように、１つ以上のタイマー１２８が切れているかどうかを判定するために、送信されたＲＬＣデータ・ブロックの各々に対する現状のタイマー値を定期的に監視する。タイマー１２８のインスタンスが切れている場合、ＢＳＳプロセッサ１２４は、バッファ１２６から対応するＲＬＣデータ・ブロックを、たとえば、図２のステップ２０８で示されるように、削除する。このように、ＲＬＣデータ・ブロックは、移動装置１０２から受信される後続のパケットＮＡＣＫメッセージに応じて再送信されることはない。ＢＳＳプロセッサ１２４は、所与の上位レイヤＰＤＵを送信するために必要とされる複数の潜在的なＲＬＣデータ・ブロックのうちの最初のものがバッファされる場合、ＲＬＣデータ・ブロックの全てが、タイマー１２８が切れる前にＲＬＣの受信側エンドポイントに正常に送信されなければならないので、タイマー１２８のうちの１つのインスタンスのみを開始することができる（すなわち、これらのＲＬＣデータ・ブロックの各々に対するタイマー１２８のインスタンスを開始する必要はなくてもよい）。

ＢＳＳプロセッサ１２４は、また、図２のステップ２１０およびステップ２０８で示されるように、ＲＬＣデータ・ブロックが受信されたことを示す移動装置１０２からパケットＡＣＫメッセージが受信される場合、タイマー１２８が切れる前でも、送信バッファ１２６からＲＬＣデータ・ブロックを取り除く。バッファされたＲＬＣデータ・ブロックは、図２のステップ２１２およびステップ２１４で示されるように、ＲＬＣデータ・ブロックに関連するタイマー１２８のインスタンスが切れる前にパケットＮＡＣＫメッセージが受信される場合、パケットＮＡＣＫメッセージに応答して再送信される。このように、移動装置１０２によって紛失と確認されているＲＬＣデータ・ブロックは、そのブロックのタイマー１２８が切れていないかぎり、再送信することができる。

ＢＳＳプロセッサ１２４によって使用されるタイマー値は、移動装置１０２に明示的に送信される、またはＰＤＰコンテキスト起動時に確立される転送遅延ＱｏＳ属性から導出される。それにより、移動装置１０２は、ＢＳＳ１２２によって送信されるＲＬＣデータ・ブロックを処理する場合に、そのタイマー値を使用することができる。移動装置１０２は、紛失ＲＬＣデータ・ブロックをこれ以上待ち合わせるべきではない時点を判定するために、そのタイマー値を使用することができる。移動装置１０２は、また、ＢＳＳ１２２が対応する受信をまだ応答確認していないＲＬＣデータ・ブロックのＢＳＳ１２２への再送信をいつ停止すべきかを判定するために、そのタイマー値を使用することができる。１つの実施形態では、最大データ転送遅延制約が、たとえば、ＲＬＣデータ・ブロックが送信される（ＰＤＰコンテキストのサポートに使用される）ＴＢＦに適用できる（転送遅延を含む）ＱｏＳ属性を判定するために使用されるＰＤＰコンテキスト起動手順の一部として、移動装置１０２に提供される。他の実施形態では、ＢＳＳタイマー１２８によって使用されるタイマー値は、たとえば、メッセージのＩＥ部分として、移動装置１０２に提供される。

これとは無関係に、移動装置１０２は、また、紛失ダウンリンクＲＬＣデータ・ブロックのその時点での有効性を最大データ転送遅延制約に基づいていつ確立すべきかが指示される。１つの実施形態では、ＲＬＣデータ・ブロックがＢＳＳ１２２によって送信されるダウンリンクＴＢＦを確立するために使用されるＴＢＦ確立メッセージの中に、ＩＥをプログラムする。たとえば、ＥＤＧＥ ＴＢＦ確立メッセージのウィンドウ・サイズＩＥ内で１つ以上の未使用ビットが、移動装置１０２が、紛失ダウンリンクＲＬＣデータ・ブロックのその時点の有効性を最大データ転送遅延制約に基づいて確立すべきであることを示すために、ＢＳＳプロセッサ１２４によってプログラムされることができる。移動装置１０２に含まれるプロセッサ１３０は、移動装置１０２が、紛失ダウンリンクＲＬＣデータ・ブロックのその時点の有効性を最大データ転送遅延制約に基づいて確立すべきかどうかを判定するために、ＴＢＦ確立メッセージ内の適切なＩＥを検索する。そうでなければ、移動装置１０２は、紛失ダウンリンクＲＬＣデータ・ブロックのその時点の有効性を、従来のスライディングＲＬＣウィンドウ方法に基づいて確立する。

移動装置のプロセッサ１３０内に含まれるまたは関連するタイマー１３２は、ＢＳＳプロセッサ１２４にそうするように指示される場合、移動装置１０２でタイマーに基づくパケット再送信要求方法をサポートする。移動局のタイマー１３２は、紛失ダウンリンクＲＬＣデータ・ブロック、すなわち、移動装置１０２により待ち合わされてはいるが、まだ受信されていないＲＬＣデータ・ブロックの経時を追跡する。ＲＬＣデータ・ブロックが最初に紛失しているとして検出されるたびに、たとえば、図３のステップ３００で示されるように、新しいタイマーが開始される。１つ以上のＲＬＣデータ・ブロックが、送信されているＲＬＣデータ・ブロックの各々の一部として含まれるシーケンス番号によって示される順序と違って受信される場合、ＲＬＣデータ・ブロックは、紛失しているとして検出される。移動局のタイマー１３２は、移動装置１０２によってそれまでに受信されている最大データ転送遅延制約に基づく値に初期化される。生のデータ転送遅延そのものが、タイマー値として使用することもでき、または移動装置１０２は、ＲＬＣデータ・ブロックが紛失していることを検出する場合、（ＢＳＳによる最初の送信以降）既に経過している可能性のある時間を明らかにするために、典型的な無線インタフェース送信時間間隔を考慮に入れることができる。

移動局のプロセッサ１３０は、検出した紛失ＲＬＣデータ・ブロックの各々に対して、たとえば、図３のステップ３０２で示されるように、移動局のタイマー１３２が切れているかどうかを定期的に判定する。対応するＲＬＣデータ・ブロックが受信される前にタイマーが切れる場合、紛失ＲＬＣデータ・ブロックは、移動局のプロセッサ１３０によって、たとえば、図３のステップ３０４で示されるように、無効化される。移動装置１０２は、無効化されたＲＬＣデータ・ブロックを受信することをこれ以上待ち合わせない。その代わりに、移動局のプロセッサ１３０は、それから、上位レイヤのＰＤＵを全く送信しない代わりに不完全な（すなわち、誤った）上位レイヤＰＤＵを生成しても良い。

移動局のプロセッサ１３０は、それぞれのタイマー１３２がまだ切れていない紛失ＲＬＣデータ・ブロックを待ち合わせ続ける。タイマー１３２が切れていなくて、そして対応するＲＬＣデータ・ブロックがまだ受信されていない場合、移動局のプロセッサ１３０は、たとえば、図３のステップ３０６およびステップ３０８で示されるように、紛失ＲＬＣデータ・ブロックの再送信を要求する。タイマー１３２が切れる前に受信されている紛失ＲＬＣデータ・ブロックは、移動局のプロセッサ１３０によって有効と見なされる。有効なＲＬＣデータ・ブロックは、移動局のプロセッサ１３０によってデータ・パケットが移動局のプロトコル・スタックに上がって処理されるにつれて、たとえば、図３のステップ３１０で示されるように、カプセル化のヘッダを取り除くことによって処理される。アップリンクＲＬＣデータ・ブロックをＢＳＳ１２２に送信する場合、移動装置１０２は、また、ＢＳＳ１２２内のタイマー１２８に対して、上述の機能と同一の機能を有するタイマーを維持する。アップリンクＲＬＣデータ・ブロックを移動装置１０２から受信する場合と同様の方法で、ＢＳＳ１２２は、移動装置１０２内のタイマー１３２に対して上述の機能と同一の機能を有するタイマーを維持する。

変形および用途の上記範囲を考慮に入れて、当然のことながら、本発明は、上述の明細書に限定されるものではなく、また、添付の図面に制限されるものでもないことが理解されるべきである。その代わりに、本発明は、特許請求の範囲、およびそれらの法的均等物によってのみ限定される。

Claims (28)

1. 最大データ転送遅延制約を有するアプリケーションに関連する上位レイヤのパケット・データ・ユニットであるＰＤＵを送信する方法であって、
   １つ以上の前記上位レイヤのＰＤＵに関連する無線リンク制御データ・ブロックであるＲＬＣデータ・ブロックの最初の送信に応じて、前記最大データ転送遅延制約に基づいているタイマー値に初期化されるタイマーを開始するステップと、
   前記タイマーが切れていない限り、前記ＲＬＣデータ・ブロックの受信が応答確認されていないことを示す受信メッセージに応じて、前記ＲＬＣデータ・ブロックを再送信するステップと、
   前記タイマーが切れていることまたは前記ＲＬＣデータ・ブロックの受信が応答確認されていることを示す受信メッセージに応じて、前記ＲＬＣデータ・ブロックをメモリから削除するステップと
   を備えることを特徴とする方法。
2. 前記アプリケーションがボイスオーバＩＰに基づくものである場合、前記タイマーをほぼ１００ミリ秒に初期化するステップを更に備える
   ことを特徴とする請求項１に記載の方法。
3. 前記アプリケーションがマルチメディアキャストマルチキャストサービスに基づくものである場合、前記タイマーをほぼ３秒以下に初期化するステップを更に備える
   ことを特徴とする請求項１に記載の方法。
4. 前記タイマー値を、前記上位レイヤのＰＤＵを受信するように構成されている１つ以上の無線受信機に送信するステップを更に備える
   ことを特徴とする請求項１に記載の方法。
5. 前記送信するステップは、前記１つ以上の無線受信機に送信されるメッセージ内の情報要素として該タイマー値を含めることを含んでいる
   ことを特徴とする請求項４に記載の方法。
6. 受信された前記ＲＬＣデータ・ブロックを処理する場合に、前記タイマー値を使用することを、前記１つ以上の無線受信機に指示するステップを更に備える
   ことを特徴とする請求項４に記載の方法。
7. 前記指示するステップは、テンポラリ・ブロック・フロー確立メッセージであるＴＢＦ確立メッセージ内に情報要素をプログラムすることを含み、
   前記情報要素は、紛失ＲＬＣデータ・ブロックを処理する場合に、前記タイマー値を使用することを、前記１つ以上の無線受信機に指示するように構成されている
   ことを特徴とする請求項６に記載の方法。
8. 最大データ転送遅延制約を有するアプリケーションに関連する上位レイヤのパケット・データ・ユニットであるＰＤＵを送信する無線送信機であって、
   １つ以上の前記上位レイヤのＰＤＵに関連する無線リンク制御データ・ブロックであるＲＬＣデータ・ブロックの最初の送信に応じて、カウントを開始するように構成されているタイマーであって、前記最大データ転送遅延制約に基づいているタイマー値に初期化されるタイマーと、
   前記タイマーが切れていることまたは前記ＲＬＣデータ・ブロックの受信が応答確認されていることを示す受信メッセージに応じて、前記ＲＬＣデータ・ブロックをバッファから削除するように構成されているバッファと、
   前記タイマーが切れない限り、前記ＲＬＣデータ・ブロックの受信が応答確認されていないことを示す受信メッセージに応じて、前記ＲＬＣデータ・ブロックを再送信するように構成されているプロセッサと
   を備えることを特徴とする無線送信機。
9. 前記プロセッサは、更に、前記アプリケーションがボイスオーバＩＰに基づくものである場合、前記タイマーをほぼ１００ミリ秒に初期化するように構成されている
   ことを特徴とする請求項８に記載の無線送信機。
10. 前記プロセッサは、更に、前記アプリケーションがマルチメディアキャストマルチキャストサービスに基づくものである場合、前記タイマーをほぼ３秒以下に初期化するように構成されている
    ことを特徴とする請求項８に記載の無線送信機。
11. 前記プロセッサは、更に、前記タイマー値を、前記上位レイヤのＰＤＵを受信するように構成されている１つ以上の無線受信機に送信するように構成されている
    ことを特徴とする請求項８に記載の無線送信機。
12. 前記プロセッサは、更に、前記１つ以上の無線受信機に送信されるメッセージ内の情報要素として該タイマー値を含めるように構成されている
    ことを特徴とする請求項１１に記載の無線送信機。
13. 前記プロセッサは、更に、受信された前記ＲＬＣデータ・ブロックを処理する場合に、前記タイマー値を使用することを、前記１つ以上の無線受信機に指示するように構成されている
    ことを特徴とする請求項１１に記載の無線送信機。
14. 前記プロセッサは、テンポラリ・ブロック・フロー確立メッセージであるＴＢＦ確立メッセージ内に情報要素をプログラムするように構成されていて、
    前記情報要素は、紛失ＲＬＣデータ・ブロックを処理する場合に、前記タイマー値を使用することを、前記１つ以上の無線受信機に指示するように構成されている
    ことを特徴とする請求項１３に記載の無線送信機。
15. 最大データ転送遅延制約を有するアプリケーションに関連する１つ以上の上位レイヤのパケット・データ・ユニットであるＰＤＵを受信する方法であって、
    前記１つ以上の上位レイヤのＰＤＵに関連する、１つ以上の送信された無線リンク制御データ・ブロックであるＲＬＣデータ・ブロックのシーケンスにおいて、紛失ＲＬＣデータ・ブロックを検出するステップと、
    前記紛失ＲＬＣデータ・ブロックの検出に応じて、前記最大データ転送遅延制約に基づいているタイマー値に初期化されるタイマーを開始するステップと、
    前記タイマーが切れるまで、前記紛失ＲＬＣデータ・ブロックを受信するものとして待ち合わせるステップと
    を備えることを特徴とする方法。
16. 前記アプリケーションがボイスオーバＩＰに基づくものである場合、前記タイマーをほぼ１００ミリ秒に初期化するステップを更に備える
    ことを特徴とする請求項１５に記載の方法。
17. 前記アプリケーションがマルチメディアキャストマルチキャストサービスに基づくものである場合、前記タイマーをほぼ３秒以下に初期化するステップを更に備える
    ことを特徴とする請求項１５に記載の方法。
18. 受信メッセージに含まれる情報要素から前記タイマー値を取得するステップを更に備える
    ことを特徴とする請求項１５に記載の方法。
19. 紛失ＲＬＣデータ・ブロックが前記タイマー値に基づいて処理されることを指示するステップを更に備える
    ことを特徴とする請求項１５に記載の方法。
20. 前記指示するステップは、受信されるテンポラリー・ブロック・フロー確立メッセージであるＴＢＦ確立メッセージに応じて、メッセージを生成することを含み、
    前記ＴＢＦ確立メッセージは、紛失ＲＬＣデータ・ブロックを処理する場合に、前記タイマー値の使用を指示するように構成されている情報要素を含んでいる
    ことを特徴とする請求項１９に記載の方法。
21. 前記紛失ＲＬＣデータ・ブロックが受信される前に、前記タイマーが切れることに応じて、該紛失ＲＬＣデータ・ブロックをメモリから削除するステップを更に備える
    ことを特徴とする請求項１５に記載の方法。
22. 最大データ転送遅延制約を有するアプリケーションに関連する１つ以上の上位レイヤのパケット・データ・ユニットであるＰＤＵを受信する無線受信機であって、
    前記１つ以上の上位レイヤのＰＤＵに関連する、１つ以上の送信された無線リンク制御データ・ブロックであるＲＬＣデータ・ブロックのシーケンスにおいて、紛失ＲＬＣデータ・ブロックを検出し、
    前記紛失ＲＬＣデータ・ブロックの検出に応じて、前記最大データ転送遅延制約に基づいているタイマー値に初期化されるタイマーを開始し、
    前記タイマーが切れるまで、前記紛失ＲＬＣデータ・ブロックを受信するものとして待ち合わせる
    ように構成されているプロセッサを備える
    ことを特徴とする無線受信機。
23. 前記プロセッサは、更に、前記アプリケーションがボイスオーバＩＰに基づくものである場合、前記タイマーをほぼ１００ミリ秒に初期化するように構成されている
    ことを特徴とする請求項２２に記載の無線受信機。
24. 前記プロセッサは、更に、前記アプリケーションがマルチメディアキャストマルチキャストサービスに基づくものである場合、前記タイマーをほぼ３秒以下に初期化するように構成されている
    ことを特徴とする請求項２２に記載の無線受信機。
25. 前記プロセッサは、更に、受信メッセージに含まれる情報要素から前記タイマー値を取得するように構成されている
    ことを特徴とする請求項２２に記載の無線受信機。
26. 前記プロセッサは、更に、紛失ＲＬＣデータ・ブロックが前記タイマー値に基づいて処理されることを指示するように構成されている
    ことを特徴とする請求項２２に記載の無線受信機。
27. 前記プロセッサは、更に、受信されるテンポラリー・ブロック・フロー確立メッセージであるＴＢＦ確立メッセージに応じて、メッセージを生成するように構成されていて、
    前記ＴＢＦ確立メッセージは、紛失ＲＬＣデータ・ブロックを処理する場合に、前記タイマー値を使用することを前記無線受信機に指示するように構成されている情報要素を含んでいる
    ことを特徴とする請求項２６に記載の無線受信機。
28. 前記プロセッサは、更に、前記紛失ＲＬＣデータ・ブロックが受信される前に、前記タイマーが切れることに応じて、該紛失ＲＬＣデータ・ブロックをメモリから削除するように構成されている
    ことを特徴とする請求項２２に記載の無線受信機。

Images