本発明の局面は、本発明の様々な実施例に向けられた、以下の説明および関連する図面で示される。代替実施例が、本発明の精神あるいは範囲から逸脱せずに考案されうる。より明らかに本発明を例示するために、当該技術における通常の熟練者に非常によく知られているいくつかの要素は、さほど詳細に記載されないかもしれない。あるいは本発明の適切な詳細を不明瞭にしないように省略されるかもしれない。
本開示及び特許請求の範囲を通じて使用されている用語「送信エンティティ」(又は「送信者」)、「受信エンティティ」(又は受信者」)は、例えば破損パケットのような特定のパケットに対する通信局の関係を称する。送信エンティティは、パケットを送った通信局又はデバイスである。受信エンティティは、パケットを受信するか、又は破損パケットの場合、このパケットを受信するように意図された通信局又はデバイスである。双方向通信に従事するデバイスは、あるパケットに対しては送信エンティティであり、別のパケットに対しては受信エンティティである。受信エンティティと同様に、送信エンティティは、受信回路と送信回路との両方を持っている。送信エンティティ及び受信エンティティの何れかは、(例えば、移動局のような)無線通信局かもしれないし、ケーブル又は有線を経由して通信する固定局かもしれない。本明細書で使用される用語「プロトコルデータユニット」(PDU)は、ネットワークを介して渡されたか、あるいはネットワーク内のピアレイヤ間で交換された情報、パケット、又はフレームのユニットである。用語「PDU」及び「パケット」は、本明細書では置換可能に使用され、同じ意味を持つものと定義される。
図2は、本発明の様々な実施例に従って、固定局及び無線局の間の通信をサポートする一般的な無線ネットワークアーキテクチャ200を示す。多くの競合するシステムが、音声、データ、およびコンテンツの無線送信のために、最近人気を獲得した。これらのシステムのうちの1つは、3GPP(第3世代パートナシップ計画)によって1999年12月に最初にリリースされたW−CDMA(広帯域符号分割多元接続方式)である。最初の1999年のW−CDMAリリースは、R−99と呼ばれる。本明細書で提供される例及び説明の多くはW−CDMAシステムに言及するが、様々な実施例が、W−CDMA、cdma2000、GSM/GPRS、又はその他様々な技術からなる様々なリリース及び実装を含む他の多くの無線通信規格あるいは有線通信規格に従って実施されうる。
無線システム200は、コアネットワーク250、1つ又は複数のラジオネットワークサブシステム240、無線ユーザ機器210、および地上通信線電話260のような有線ユーザ機器を含んでいる。一方、ラジオネットワークサブシステムRNS240は、それぞれ多くの基地局220に通信可能に接続された1つ又は複数のラジオネットワークコントローラRNC230(W−CDMAでは一般に「ノードB」と称される)を含む。実装の詳細によって、ノードB220は様々な形式をとり、別の名前で表されるか、別のシステムの局面を共通して持っているかもしれない。例えば、いくつかのシステムでは、ノードB220基地局は、基地トランシーバ局(BTS)あるいは基地局システム(BSS)と呼ばれるかもしれない。図中RNC230として示されるラジオネットワークコントローラは、ある実装では、他の形式をとり、別の名前で称されるか、例えば基地局コントローラ(BSC:base station controller)、モバイル交換局(MSC:Mobile Switching Center)、又はサービスGPRSサポートノード(SGSN:Serving GPRS Support Node)のような他のシステムに共通した局面を持っているかもしれない。一般に、SGSNは、パケット交換接続を取り扱うコアネットワークエンティティであり、MSCは、回路交換接続を取り扱うコアネットワークエンティティである。図2は、無線ユーザ機器UE210を示す。無線ユーザ機器UE210は、例えばセルラ電話、移動局、無線送受話器等のような多くの異なる名前として知られている。本発明の範囲は、これらおよびその他のそのようなシステム、名前、用語、及び類似タイプの無線システムの要素のための実装をカバーする。
図中に示されるネットワークは単なる典型例であり、無線による、あるいは要素間の固定ケーブルや有線通信経路による通信を可能にする任意のシステムを含みうる。本システムは、図2に示すような方法、あるいは当該技術における通常の熟練者によって知られている方法で接続されるかもしれない。UE210および固定局260は、電話、セルラ電話、無線接続したコンピュータ、PDA(携帯情報端末)、ページャ、ナビゲーションデバイス、音楽あるいはビデオコンテンツダウンロードユニット、無線ゲーム装置、在庫制御ユニット、あるいはエアインタフェースを介して無線通信するその他の同様なタイプのデバイスのうちの1つ又は複数を含む多くの異なるタイプの有線又は無線デバイスの形態で具体化されうる。セルラ電話又はその他の無線電気通信サービスは、公衆交換電話網(PSTN)、インターネット、統合サービスデジタル網(ISDN)、1つ又は複数のローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、仮想プライベートネットワーク(VPN)、あるいは他のそのようなネットワークかもしれない固定ネットワーク250を経由して、データリンクあるいは他のネットワークリンクを介して搬送波ネットワークと通信しうる。通信はさらに、PSTNあるいは他の固定ネットワーク250によって通信する固定局260を使用してなされうる。
無線システム200は、一般に、RNS240を経由してデータパケットとしてUE210に送られるメッセージあるいは他の情報を制御する。各RNC230は、1つ又は複数のノードB220基地局に接続されうる。1つより多いノードB220が特定のUE210に関連付けられている事象では、そのUE210のアクティブセット内のノードB220の全てが、同じ概念のE−DCHフレーム番号を持つ。これによって、UE210とソフトハンドオーバ(SHO)を行っている2つの異なるノードB220とやり取りするパケットが解釈され、正しくソートされる。RNC230を含むサブシステムRNS240は、ノードB220とUE210との間のラジオリンクを制御する。一般に、RNC230は、無線UE210を管理し制御するためのロジック(例えば、プロセッサかコンピュータ)を含んでいる。RNC230のロジックは、呼出ルーティング、登録、認証、位置更新、ハンドオーバ、およびRNC230に関連したノードBにおいて登録される無線UE210のための符号化スキームのような機能を管理し制御する。
RNC230は一般に、ネットワーク250の相互接続に類似した方法で固定通信線路のネットワークによって、データ転送及び/又は音声情報のために形成されるネットワークによってノードB220に接続される。様々なRNC230およびノードB220の要素との通信は一般に、インターネット及び/又はPSTNの一部を含んでいるかもしれない地上通信線のネットワークによって実行される。上流側に、RNC230は、(例えばPSTN、インターネット、ISDN等の)上述したものによって複数のネットワークに接続され、これによって、よりブロードな通信ネットワークへの無線UE210デバイスアクセスが可能となる。音声送信に加えて、ショートメッセージサービス(SMS)又は当該技術で周知のその他のエアを介した(OTA:over- the-air)方法を用いてデータが送信されうる。
各ノードB220は、ノードB220に関連付けられたかあるいは登録された1つ又は複数のUE210との情報の送受信のために1つ又は複数の送信機及び受信機を有する。ノードB220は、当該技術における通常の熟練者に周知のOTA方法によって、UE210に無線によってデータメッセージ又はその他の情報をブロードキャストする。例えば、UE210とノードB220との間の無線信号は、限定される訳ではないが、CDMA(符号分割多元接続)、TDMA(時分割多元接続)、FDMA(周波数分割多重接続)、OFDM(直交周波数分割多重化)、および例えばGSMのようなハイブリッド符号化技術、あるいは通信又はデータネットワークで使用されるその他同様の無線プロトコルを含むいくつかの異なる技術のうちの何れかに基づきうる。
図3は、UE210およびノードB220の詳細を示す。適切な符号化プロトコル又はスキームにおいて、送信される情報を符号化し、受信情報を復号するエンコーダ/デコーダ225を、ノードB220は含んでいる。UE210からのパケットを無線で送受信し、RNC230とパケットを送受信する(地上通信線を経由して送信されうる)ための受信/送信回路227を、ノードB220は含む。ノードB220は更に、無線通信に含まれる処理及び動作、特に本明細書で記述する処理又は動作を実行あるいは制御する回路又はその他のロジックを含むプロセッサ221を含んでいる。
また、本明細書で記述するような無線通信を行う際に使用される様々なプロトコル、ルーチン、処理、又はソフトウェアを格納するためのメモリ223を含むようにノードB220は構成される。例えば、メモリ223は、UE210と通信するための1つ又は複数の送信、スキーム、プロトコル、又はストラテジを格納しうる。送信スキーム、ストラテジ、およびプロトコルは、喪失又は破損したデータによる再送信のためのタイミングに関する情報、(必要であれば)冗長バージョン符号、無線通信の送受信のために使用される任意の符号化スキーム又はプロトコルを含む。この情報はまた、RNC230のメモリに格納され、必要に応じて、あるいは定期的更新及びシステムメンテナンスの実施中にノードB220へ通信される。
UE210の実施例は一般に、図3に示すように、ノードB220の対応部分と類似の機能を実行するプロセッサあるいは他のロジック207、メモリ209、及びエンコーダ/デコーダ回路211を含む。例えば、UE210に備えられたエンコーダ回路211やその他同様の回路は、ノードB220へ送信するためにデータを符号化したり、あるいはパケットにカプセル化するように構成されうる。各UE210はまた、情報の無線による送受信のために、当該技術における熟練者に周知のアンテナ213、受信/送信回路215、及びその他のエレクトロニクスを有する。受信回路215は、受信したパケットが破損しているかを検知するように構成される。また、送信回路は、破損したパケットに対するNAKを(例えば、ノードB220のような)送信エンティティに送り戻すように構成される。ノードB220およびUE210は、ともに送信エンティティとして、ウィンドウを進めるためにACKが受信される前にウィンドウが止まることを阻止するため、十分なパケットを格納するための十分なメモリを有するべきである。
UE210は、図3においてプロセッサ207として示されているUE210の機能を制御するためのロジックを含んでいる。実際、このロジックは、常駐構成されたロジックを実行する1つ又は複数の処理回路、マイクロプロセッサ、デジタル信号プロセッサ(DSP)、マイクロコントローラ、又はこれらや他のハードウェアの組み合わせ、例えば本明細書で記述したUE210動作のような動作を少なくとも実行するように構成されたソフトウェア及び/又はハードウェアの形態で構成されうる。
チャネルの送信条件によって、ビット誤りが、混乱を引き起こす場合がある。この混乱は、誤り復元または再送信技術によって対処されうるフレームがビット誤りを含む確率は、チャネルのビット誤り率、およびフレームのインスタンスか長さにおけるデータ量の関数である傾向がある。無線システム200は、例えば自動反復要求(ARQ: Automatic Repeat Request)及び/又は順方向誤り訂正(FEC:Forward Error Correction)、又はハイブリッドARQ(HARQ)のようなビット誤りを被る送信を検知し、復元するための1つ又は複数のメカニズムとともに実装されうる。HARQシステムは、ARQアクノレッジメントフィードバック技術に、順方向誤り訂正(FEC)の使用を加える。
無線システムは一般に、送信の成功又は失敗に関する情報を受信機が送信機に送り戻すことを可能にするフィードバックチャネルを使用する。幾つかの誤り訂正スキームは、帯域内フィードバックを用いて実施されるが、誤り訂正スキームはしばしば、帯域外フィードバックチャネルを使用して実施される。ARQは、再送信を要求するために、否定的なアクノレッジメント(NAK、しばしばNACKと表される)を用いて明示的に実施されうる。あるいは、ARQは、タイムアウト規則と共にアクノレッジメント(ACK)を使用して暗黙的に実施されうる。
UE210から送信を受信すると、ノードB220は、ACKかNAKの何れかの形態で、送信に関するフィードバックを提供するためにARQ信号を送るように構成されうる。例えば、明示的な帯域外ARQフィードバックを備えたシステムでは、UE210からのデータが、ノードB220によって受信される前に破損又は失われた場合、ノードBは、UE210が、失敗した送信を再送信すべきであることを示すNAKを送り返す。
無線システム200は、R−99 W−CDMAシステムとして、あるいはその他の幾つかの無線規格あるいは技術のうちの何れかに従って実施されうる。例えば、無線システムは、本明細書にその全体が参照によって明らかに組み込まれるユニバーサルモバイルテレコミュニケーションシステム(UMTS)無線リンク制御(RLC)プロトコル仕様(3GPP TS 25.322バージョン6.0.0リリース6)に従うかもしれない。R−99 W−CDMAでは、無線リンク制御(RLC)プロトコルが、フレーム化及び再送信機能を取り扱う。RLCプロトコルは、透過(RLC−TM)、非アクノレッジ(RLC−UM)、及びアクノレッジ(RLC−AM)の個別の3つの送信モードをサポートする。RLCは物理層と結合して、異なるタイプのQoS(例えば、異なる最大遅延および見逃し誤り率)のサポートを可能にするように十分柔軟性がある。マイナーな増強を除いて、従来のRLC実装は、R−99の一部として、最初から修正されていない。オリジナルのRLC成分のほとんどは、UMTS開発の初期段階から来ており、その時以来変わっていない。新しい物理層特徴が導入されると、RLCを修正しないようにし、その代わり、他の層の中でその制限のうちのいくつかに対処することを試みるように決定された。これは例えば、高速ダウンリンクパケット接続(HSDPA)のためのプロトコルデータユニット(PDU)の無秩序な受信のニーズに応じるためになされた。
R−99 W−CDMAは、不要な再送信がないことを保証するために、状況禁止メカニズムを使用する。R−99はまた、この状況禁止メカニズムが動作している間、少なくとも1つのポールが受信されたことを保証するために多くのポーリングスキームを使用する。R−99状況禁止値は一般に、再送信を実行する場合に利用可能な有限帯域幅を確保するために、予測される往復時間よりも40又は60ms長く設定される。状況報告を開始するために利用可能な複数のメカニズムが存在する。例えば状況報告は、一定時間間隔で定期的に送られるかもしれないし、あるいは連続番号シーケンス内の切れ目が検出される場合、行方不明のPDUにより開始されるかもしれない。あるいは、状況報告は、状況報告を要求する通信リンクのもう1つの端における送信エンティティから受信されたポールに応答して開始されうる。ポールは、例えば、RLC−AMヘッダ上にビットを設定することにより、送信エンティティによって示されうる。
状況報告を開始するポールの使用に関し、送信エンティティによるポールの送信を開始するために利用可能な多くのメカニズムがある。ポールを開始するためのこれらメカニズムは、定期的なポール、送信バッファ内の最後のPDUに対するポーリング、ポールタイマを使用すること、ウィンドウベースのポール、全てのPoll_PDU PDU(プロトコルデータユニット)又は全てのPoll_SDU SDU(サービスデータユニット)に応じたカウンタベースのポーリングを含む。これらのポーリングは、以下のような動作を開始させる。定期的なポールについては、予め定めた定期的な時間間隔でポールが開始される。送信バッファ検出については、送信バッファあるいは再送信バッファにおける最後のPDUが検出されるとポールは開始される。例えば、ポールは、送信バッファ又は再送信バッファにおける最後のPDUのヘッダ上に設定されうる。送信バッファヘッダ又は再送信バッファヘッダは、これを達成するために独立して構成されうる。ポールタイマを使用するために、タイマが時間切れになった後、送信されたデータが肯定的にアクノレッジされていないのであれば、前のポールの後、予め定めた固定された時間、ポールが開始される。ポールタイマスキームは、ポールが失われた場合、冗長性を保証する。ウィンドウベースのポーリングの場合、送信ウィンドウが、送信ウィンドウのある部分よりも進んだ後、ポールが開始されうる。
全てのPoll_PDU PDUのポーリングを開始したカウンタの場合、Poll_PDU PDUメッセージの送信後、状態変数VT(PDU)が、上部層によって設定されるPoll_PDU値に達する場合、ポールが開始される。状態変数VT(PDU)は、AMD(アクノレッジされたモードデータ)PDUが(PDU再送信を含んで)送信される毎に1ずつインクリメントされる。同様に、全てのPoll_SDU SDUに関するポールの場合、状態変数VT(SDU)が、上部層によって設定されるPoll_PDU値に達する場合、Poll_SDU SDUの送信後にポールが開始される。状態変数VT(SDU)は、最初のSDUセグメントを運ぶAMD PDUが、初めて送信されるとスケジュールされた場合、所定のSDUに対して1ずつインクリメントされる。
RLC−AM受信エンティティは、VR(R)、VR(H)、およびVR(MR)を含む多くの状態変数を保持する。状態変数VR(R)は、シーケンスに従って受信された最も直近のシーケンス番号を表す。VR(R)は、受信機ウィンドウの開始を示す。状態変数VR(H)は、受信された任意のPDUのための最も高い連続番号である。状態変数VR(MR)は、有効であると受け入れられる最も高い連続番号である。VR(MR)は、受信機ウィンドウの端を示す。よって、VR(MR)は、VR(R)+Rx Window Sizeに設定される。RLCウィンドウ、受信機ウィンドウ、および送信ウィンドウといった用語に関し、これら用語は、たとえ異なる意味を有していても、当該技術では、しばしば置換可能に使用されることが注目される。RLCが設定される場合、同じサイズの2つのウィンドウ、すなわち、受信エンティティにおける受信機ウィンドウ(しばしば受信ウィンドウと称される)と、送信エンティティにおける送信ウィンドウとが生成される。受信ウィンドウは、シーケンスに従ってPDUが受信されると進められる。PDUがシーケンスに従って受信されない(例えば、1つ又は複数の破損PDUが存在する)場合には、受信ウィンドウの進行は、行方不明のPDUの再送信が受信されるか、行方不明のPDUが廃棄される(例えば、最大数の再送信に達する場合)まで待つ。送信ウィンドウは、送信エンティティが、受信エンティティから、一定のPDU数までのPDUがシーケンスに従って適切に受信されたことを示すACKを受信する毎に進められる。RLCウィンドウという用語は、一般に、RLCに関してしばしば使用される。
上述したように、従来システムにおける各RLC状況報告は、受信機ウィンドウで検出される全てのホール又はデータギャップに対してNAKを含むことが要求される。従って、従来ネットワークは、RLC往復時間よりも僅かに長い状況禁止を使用する。例えば、従来のR−99 W−CDMA実装では、一般に、状況禁止値は、予測される往復時間よりも40〜60ミリ秒長く設定される。従来のW−CDMA構成では、保持するデータ送信中に、状況報告が、RLC往復時間につき一度送信される。
本発明者は、往復時間(RTT)毎に1つだけ状況報告を送信することによる遅延の欠点を認識した。従来の状況禁止タイマが動作している間、更なる状況報告が送られないというW−CDMA要求は、しばしば、破損したパケットの再送信における遅延をもたらす。図4は、1つのみの状況報告がRTT毎に送信される従来スキームの場合、行方不明又は破損したPDUから復元するために再送信されたパケットの遅延を示す。この例では、識別子401、403、405、407および409は、受信エンティティから送信エンティティに送り戻されている状況報告を表わす。状況報告401を送信すると、状況禁止タイマ421が起動する。従来のW−CDMA実施に従って、状況禁止タイマ421が終了するまで、状況報告は送られない。状況禁止タイマ421が時間切れになった後、状況禁止タイマ421による遅延431後に状況報告403が送信されうる。同じ状態は、従来のW−CDMAで送られる全ての状況報告の場合に生じる。状況報告401〜409の各々に続いて、状況禁止タイマ421〜427のうちの1つが開始され、1つのRTT、あるいは1つのRTTよりも僅かに長く有効状態を保つ。禁止タイマ421〜427は、動作中の状況禁止タイマ421〜427が時間切れになるまで、次の状況報告が送られることを阻止する。状況報告401〜409は、各受信機ウィンドウで検出される全てのホール(例えば、破損したPDU411,413,及び415)に対するNAKを含む。
この例では、ブロック411,413,および415は、RLC連続番号における3つの新しいホールの検出を示す。各ホールが検出される場合、状況禁止タイマ421〜427のうちの1つが有効であるので、ホールの検出と、次の状況報告における対応するNAkの送信との間に遅延が発生する。ホール411、413、および415に対する遅延は、431、433、および435としてそれぞれ示される。送信誤りは、状況報告タイミングと相関しないので、更なる遅延が、零(0)と、状況禁止タイマの値との間で一様に分布する。従来システムでは、状況禁止タイマの長さは、RTT近傍に設定される。これは、ホールが検出される時間と、再送信が受信される時間との間の合計遅延が、平均して、往復遅延時間の1.5倍に等しいことを意味する。特定のホールに対する最初の再送信のみが、この遅延によって影響されうることに留意されたい。ホールに対するこの最初の再送信が失敗すれば、次の再送信と、その後のホールのための全ての再送信は、1つのRTTによってのみ遅延される。
フロー制御を行う送信ウィンドウに依存するRLC−AM及びTCPのようなプロトコルの場合、送信ウィンドウを前に進めるよう注意喚起するためにアクノレッジメントACKが使用される。比較的大きいウィンドウサイズの場合、アクノレッジメントを送信する際の遅延は、著しく性能に悪影響を与えない。しかし、従来のRLC−AM実装では、ACKは、報告すべきNAKが存在するか否かに関わらず、同じ周波数で送られる。送信エンティティは、送信中に誤りがないことを仮定して、ウィンドウを進めるためにACKが受信される前にウィンドウが止まらないことを保証するために、多くのPDUを格納できるべきである。一般に、2つの連続した状況報告の受信の間に、送信エンティティによってバッファされる必要のあるデータ量(例えば、最大のバッファデータ)は、往復時間の2倍で送信されることが可能なデータ量に相当する。PDUバッファは、R−99ではなくHSDPAにおいてより重要かもしれない。なぜなら、HSDPAでは、RLCウィンドウサイズは、より制限される傾向にあるからである。例えば、200ミリ秒の往復時間と、320ビットのPDUサイズとを仮定すると、達成可能な最大データレートは、2048×320/(2×0.2)=1.63Mbpsとなる。HSDPAの場合、状況禁止は、しばしば小さな値として設定されうる。なぜなら、良好なチャネル条件では、見逃し誤り率は極端に低いからである。しかしながら、セルを介した同じ設定を使用すれば、劣悪なチャネル条件を有するエリア内のユーザは、極めて多くの不要な再送信によって悪影響を受けるだろう。
従来RLCの欠点は、RTTあたり1つよりも多い状況報告の送信が、不要な再送信を引き起こすかもしれないことである。しかしながら、RTTあたり1つ程度に状況報告を制限することによって、RLCウィンドゥを進め、行方不明のPDUに対するNAKを送る際に、より長い遅延を引き起こす。従来のRLC実装は、NAK遅延とACK遅延とを調節することを不可能にする多くの制約を含んでいる。例えば、従来の状況報告は、全てのホールのためのNAKを連続番号(SN)で含んでいる。そして、状況報告は、どんなNAKが存在しているかとは無関係な同じレートで、ACKが何度も送られる必要がないという事実にも関わらず送られる。もしも状況報告期間が、往復時間よりも大きくなければ、従来のRLC実装のこの要求は、不要な再送信を引き起こす。
本明細書で開示された様々な実施例は、PDUシーケンスにおけるホールを独立して追跡することにより、更なる柔軟性を提供する。(全てのホールに対して適用可能である)規則的な状況禁止タイマに加えて、ホール毎に個別のタイマが提供される。NAK禁止タイマと呼ばれるこのタイマは、状況PDUの送信を阻止しない。与えられたホールのためのNAK禁止タイマは、与えられたホールのためのNAK禁止タイマが時間切れになるまで、送信されたあらゆる状況報告におけるホールを称するNAKを含むことを阻止する。ポーリングと状況禁止との組み合わせによって、システムは、報告が生成されるレートを定義することが可能になる。また、行方不明のPDU報告トリガを効率的に使用することを可能にする。
図1A及び図1Bに示す従来のスキームは、しばしば、本明細書で開示された様々な実施例によって送信されるNAKの数(例えば、図5A及び図5Bにおける531,532,533,及び534)よりも少ないNAK送信(例えば、131,132,及び133)しか必要としない。しかし、従来スキームは、フィードバックを送る際の遅延の低減を可能にしない。本実施例は、状況報告の増加した数に対するフィードバック遅延のトレードオフにおける更なる柔軟性を可能にする。本明細書で開示された実施例に従ってより頻繁に状況報告送信を送ることは、再送信のより均衡のとれた配信を提供する傾向にある。更に、本明細書で開示された様々な実施例の状況禁止タイマは、不要な再送信の可能性を増加することなく、従来システムの状況禁止タイマよりも短い値に設定される。
最も直近のシーケンスに従って受信された連続番号を報告するために、すなわち、RLCウィンドウの最初を更新するために、ACKが受信エンティティから送信エンティティへと頻繁に送り戻される。ACKは、一般に、NAKを含む状況報告に含まれるだろう。しかしながら、利用可能なNAKがない場合、サポートされているウィンドウサイズに依存して、ACKの送信を開始することは、必ずしも意味のあることではない。送られるNAKが存在しない場合に、不必要にACKを開始することを回避するために、本明細書で開示された様々な実施例は、「ACK禁止タイマ」を提供する。このタイマは、NAK禁止タイマよりもより長い値に設定されうる。NAKを含む状況報告は、状況禁止タイマが動作している場合、又は関連するNAK禁止タイマが時間切れになっていない場合にのみ遅延する。しかしながら、ACKのみの状況報告、すなわち、ACKのみであってNAKではない状況報告は、状況禁止タイマ又はACK禁止タイマの何れか一方が動作している場合に遅延する。様々な実施例においてNAK禁止タイマはNAK特有であるので、異なるNAK又は任意のACKの状況報告の送信に悪影響を与えないであろう。
図5A乃至図5Bは、本明細書で開示された様々な実施例に従って、見落とされた又は破損した無線パケットを復元するスキームの局面を示す。図5Aは、NAK禁止タイマを例示しており、送信エンティティから受信したポール520、見落とされたパケット501〜505、送信エンティティにNAK531〜534を送り戻す状況報告、NAK禁止タイマ541〜544、及び再送信パケット511〜515の典型的な時間関係を示している。スロット501〜505は、受信エンティティにおける破損パケットを示す。図5Aが、受信エンティティにおいて受信される様々な信号501〜520を示している一方、図5Bは、受信エンティティと送信エンティティとの間で送られるNAK531〜534及び再送信511〜515を示す。明瞭さのために、ACK禁止タイマと状況禁止タイマとは、図5A及び図5Bともに関連して提供されるNAK禁止タイマの説明には考慮されない。ACK禁止タイマと状況禁止タイマとは、図6A及び図6Bともに以下に説明する。
パケット(例えばパケット501)が破損されていると判定すると、受信エンティティは、送信エンティティに対して、破損したパケット501の再送信を開始するように命令するNAK531を含む状況報告を送信エンティティに送り戻す。不要な再送信を引き起こさないようにするために、NAK禁止タイマ541が開示される。様々な実施例に従って、NAK禁止タイマは、状況報告が送信されるや否や開始される。従来のW−CDMA実装の状況禁止タイマとは異なり、本明細書で開示されたNAK禁止タイマは、NAKに特有である。NAKに特有なので、NAK禁止タイマは、特定の失われたPDUについての更なるNAKのみを禁止する。あるいは、いくつかの連続する失われたPDUのホールが存在する場合、NAK禁止タイマは、このホールの連続する失われたPDU更なるNAKを、NAK禁止タイマが時間切れになるまで禁止する。ここで使用されるように、NAK特有であるNAK禁止タイマは、1つ又は複数の破損パケットに関連付けられていると言われる。したがって、NAK禁止タイマが時間切れになるまで、1つ又は複数の破損パケットのために更なるNAKは送られないであろう。これは、タイマが時間切れになるまで更なる状況報告を禁止する従来技術の一般的な状況禁止タイマとは異なる。
図5に示すように、NAK531を含む状況報告が受信エンティティから送られるや否や、状況禁止タイマ541が開始される。これによって、NAK禁止タイマ541が時間切れになるまで、破損パケット501に対する更なるNAKの送信を回避する。しかしながら、NAK禁止タイマ541は、破損パケット501のためのNAKに関してNAK特有であるので、他の破損PDUのための他のNAKはブロックされない。従って、破損PDU502を検出すると、NAK禁止タイマ541がまだ動いているという事実にも関わらず、受信エンティティはNAK532を送ることができる。NAK禁止タイマが動作している間に、送信エンティティから受信されたポールは、NAK禁止タイマを考慮して無視される必要はない。上述したように、2つ以上の連続する喪失PDUのホールが存在する場合、NAK禁止タイマは、NAK禁止タイマが時間切れになるまで、このホールの連続する喪失PDUのための更なるNAKを禁止する。例えば、破損PDU504及び505は、2つの連続する喪失PDUのホールを形成する。2つのNAKを送るのではなく、幾つかの実施例では、2つの破損パケット504及び505のために単一のNAK534を送ることによって、オーバヘッドが節約される。そのような例では、単一のNAK禁止タイマ544が、ホールの両方の破損パケット504及び505を報告するNAK534について開始される。NAK禁止タイマ544は、喪失PDU504、及び喪失PUD505の両方に関連すると言われている。したがって、NAK禁止タイマ544が時間切れになるまで、これら2つの喪失PDUのうちの何れかのために、更なるNAKが送信されることを阻止する。
状況報告の送信、特に、破損パケットのためにNAKを送るタイミングに関し、一般に、送信エンティティから送られたポールを受信するや否や状況報告が送られる。しかしながら、様々な実装では、NAKを含む状況報告は、ポールを待つことなく、破損PDUを検出した際に送られるかもしれない。例えば、W−CDMAでは、「行方不明PDUインジケータ」オプションが、ポールを待つことなく、新たに発見された破損PDUのためにNAKを送るように構成されうる。ポールを待たずにNAKを送るように構成されたこのオプションを用いてでさえ、動作中の状況禁止タイマによって、NAKは遅れるかもしれない。
図6Aは、NAK禁止タイマ、ACK禁止タイマ、及び状況禁止タイマの間の相互作用を様々な実施例に従って例示する。図6Aは、3つのタイプのタイマ、すなわちNAK禁止タイマ641〜642、状況禁止タイマ650、及びACK禁止タイマ661〜663を示す。NAK禁止タイマは、NAKに特有である。これは、NAKが一旦送られると、NAK禁止タイマが時間切れになるまで、NAK禁止タイマに関連付けられた破損PDUのためのあらゆる更なるNAKの送信を阻止するが、他の失われたPDUのためにNAKが送られることを阻止しないことを意味する。1つの失われたPDUに関連付けられたNAK特有のNAK禁止タイマは、別の失われたPDUのためにNAKが送られることを阻止しない。NAK禁止タイマは、一般に、1つのRTTよりも僅かに大きく(例えば、RTTよりも20〜100ms長く)設定される。一方、状況禁止タイマは、NAKに特有ではない。状況禁止タイマは、時間切れになるまで、あらゆる状況報告が送られないようにする。従って、送るべきNAKがある場合、NAKは、動作中の状況禁止タイマが時間切れになるまで遅延される。状況禁止タイマは、任意の時間長さに設定されうるが、様々な実施例に従って、一般に、RTTよりも幾分短い持続時間に設定される。このように、シーケンスにしたがって最も直近に受信された連続番号に対する状態変数VR(R)(受信機ウィンドウの始まりを表す)は、頻繁に更新される。これによって、RLCウィンドウをタイムリーに移動させる。ACKタイマは、動作中のACKタイマが時間切れになるまで、NAKではなくACKのみを含む状況報告の送信を阻止する。しかしながら、ACKタイマは、NAKを含む状況報告を阻止もしないし、遅らせもしない。更に、いくつかの実施例では、(ACKタイマはNAKを遅らせないので)送るべきNAKが存在すれば、状況報告が送られ、NAKによって促される状況報告は、いずれにせよ送られるので、ACKも含みうる。
PDUが受信されると、チャネル条件に依存して、受信エンティティは時々、破損パケット(例えばPDU601及び602)を検出する。いくつかの実装では、たとえポールが送信機から受信されていなくても、NAKがすぐに送られるかもしれない。一方、他の実装では、受信エンティティは、NAKの送信を開始するために、次のポールが受信されるまで待つ。しかしながら、何れかの実装では、動作中の状況禁止タイマが有効であれば、NAKを含む状況報告は送られないであろう。図6Aにおいて示す例では、状況禁止タイマ651が動作中であれば、破損PDU601に対するNAK631はすぐには送られない。破損PDU601に対するNAK631は、時間691において時間切れになるまで状況禁止タイマ651によって遅延される。時間691において、ACK禁止タイマ661が動作中であることが注目されるべきである。しかしながら、ACK禁止タイマは、NAKの送信を遅らせないし、悪影響も与えないので、破損パケット601のNAKは、たとえACK禁止タイマ661が現在動作中であっても、送信されるであろう。更に、幾つかの実施例では、ACKタイマ661が有効であっても、NAK631を含む状況報告もまたACKを含む。何れにせよ、NAK631のために開始される状況報告は送られるので、状況報告とともにACKを送ることは、オーバヘッドを増加しない。いくつかの実施例では、ACK禁止タイマが有効である間、ACKは、送られる状況報告内にNAKを同伴するので、ACK禁止タイマはリセットされる。
従来システムでは、状況禁止タイマは、一般に、RTTに等しいか、RTTよりも僅かに大きい。本明細書で開示された様々な実施例に従って、状況禁止タイマは、RTTよりもはるかに短い持続時間であり、しばしばRTTよりも数倍短い(例えば、状況禁止タイマ650)。図6Aは、NAK禁止タイマ(641〜642)が状況禁止タイマのほとんど2.5倍である典型的な場合を示す。一方、ACK禁止タイマは、状況禁止タイマの3倍として示される。状況禁止タイマをRTTよりもはるかに短くすることによって、様々な実施例が、シーケンスに従って受信された最も直近の連続番号に対する状態変数VR(R)を更新することができる。そして、RLCウィンドウを、より少ない遅延で進め続けることができる。
図7は、本発明の様々な実施例に従うリンク制御のための方法を示す。この方法は701で始まり、PDUが検出される705に進む。705では、予め定めた時間期間、時間スロット、又はTTI(送信時間間隔)内に、受信エンティティにおいて、送信エンティティからのデータが受信されると期待される。例えば、受信エンティティ(例えば、図2のUE210)は、特定の時間スロット(例えば、図5Aの501)において、送信エンティティ(例えば、ノードB220)からデータパケットを受信することが期待される。受信エンティティは、移動局であることに必ずしも限定される必要はない。受信エンティティは、固定局(例えば、図2のノードB220又は地上通信線電話260)でありえる。また、送信エンティティは、別の固定局あるいは移動局でありえる。双方向通信を行う特定の局は、いくつかのPDUの受信エンティティ、および他のPDUの送信エンティティであろう。PDUが受信されたかどうかを検知すると、この方法は705から707へ進む。
707では、受信エンティティが、PDUが正しく受信されたか(例えば図5の511又は580)、又は破損しているか(例えば、501〜505)を判定する。正しく受信されたパケットは、再送信されたパケット(例えば511〜515)であるか、あるいは最初に送信されたパケットである初期送信(例えば、ラベルされていない図5の580及びその他のパケット)として送信されたパケットのうちの何れかでありうる。更に、正しく受信されたパケットは、破損したが、誤り訂正を用いて復元されたパケットの結果かもしれない。破損したパケット(しばしば、失われたパケットと呼ばれる)は、誤っているか、判読できないデータを含んでいるかもしれないし、あるいは全く受信されないかもしれない。707の一部として、受信エンティティは、いくつかの実施例の中で、PDUが破損しているかどうかを判断するために誤りチェックを行なうかもしれない。誤りチェックは、(チェックサムや、巡回冗長検査(CRC)や、フレームチェックシーケンス(FCS)や、例えばハミングコード、リードソロモンコード、リードミュラーコード、バイナリゴーレイコード、畳み込みコード、ターボコードのような誤り訂正コード(ECC)や、その他のタイプの誤り検出又は検出/訂正スキームのような)いくつかの誤りチェックルーチンあるいはアルゴリズムのうちの何れかを含む。ブロック707において、PDUが正しく受信されたか、破損しているかをチェックすることは、チャネル測定又は受信電力測定、移動ユニット受信品質の暗黙推定、又はその他同様の種類の任意の手続き、又は当該技術における熟練者に周知の受信時における誤りのためのテストのような動作を必要としうる。707では、PDUが破損していると判定された場合には、本方法は、NAK処理のために709に進む。ブロック709のNAK処理は、図8においてより詳細に説明される。
ブロック709のNAK処理が一旦完了すると、本方法は、711に進み、ACKカウンタ処理を実行する。いくつかの実施例は、ACKカウンタ処理を実行するかもしれないが、他は実行しない。ACKカウンタ処理が実施されないのであれば、本方法は、709から703に直接進む。703では、通信が終了したかが判定される。ACKカウンタ処理を実施する実施例の場合、ブロック711の処理が実行される。ブロック711のACKカウンタ処理は、図10においてより詳細に説明される。ACKカウンタ処理が一旦終了すると、本方法は703に進む。
707に戻り、PDUが正しく受信されたと判定されると、本方法は713に進む。713では、受信されたPDUが、新たなデータの最初の送信であるか、以前に破損したデータの再送信であるかが判定される。PDUが新たなデータであると判定された場合、本方法はACK処理のために715に移る。713では、受信されたPDUが、以前に破損したパケットの再送信であると判定された場合、本方法は719に進む。719では、再送信に関連付けられたNAK禁止タイマは、まだ動作しているのであれば停止又は取り除かれる。再送信されたパケットは受信されているので、送信が待たされた再送信パケットに関連付けられたNAKはもはや必要とされず、送られることなく破棄される。本方法は719から715へ進む。ACK処理715は、図9においてより詳細に説明される。ACK処理715の結果は、ACKが送信されるか、あるいはACK禁止タイマが有効であれば、ACK禁止タイマが期限切れになったときに、ACKは送信のために待たされる。
ACK処理715が一旦終了すると、本方法は717に進み、再送信が未だに受信されていない以前に破損したパケットからの期限切れNAK禁止タイマが存在するかが判定される。NAK禁止タイマは、受信エンティティ内で任意の値に設定されうるが、一般に、NAK禁止タイマを、1つの往復時間(RTT)よりも僅かに大きく設定することが有利である。RTTは、NAKが送信エンティティに送り戻され、送信エンティティによって処理され、そして、送信エンティティに、再送信を受信エンティティに送らせるために期待される時間である。RTT値は、チャネル条件に幾分依存しているか、あるいは、地上通信線の場合には、信号の通信経路に依存するかもしれない。NAK禁止タイマを、1つのRTTよりも僅かに大きく設定することは、たとえ前のNAKによる動作で設定された再送信が既に存在していても、不要な再送信、すなわち、更なるNAKを送ることによって生じる1つ又は複数の余分で不必要な再送信を回避する傾向にある。従って、NAK禁止タイマは、一般に、おおよそ1つのRTTか、あるいは1つのRTTよりも僅かに大きく設定される。例えば、NAK禁止タイマは、RTTに、追加の送信時間間隔(TII)を加えた値、RTT+2×TII、RTT+3×TII、又は条件が保証するのであれば、より長い時間設定に設定される。いくつかの実施例では、NAK禁止タイマ設定は、例えば110%のようなRTTの割合として測定されうる。タイマが設定されたいかなる値についても、特定の破損PDUのためのNAK禁止タイマが時間切れになると、別のNAKがその特定の破損PDUのために送られる。第2のNAK(すなわち次のNAK)を送ることが、しばしば不要な再送信をもたらすことになるかもしれないが、NAK禁止タイマによって導入される追加NAKを送る際の遅延は、不要な再送信の発生を著しく低減するであろう。
717では、再送信が再び受信されない(あるいは破損している)ために、時間切れになったNAK禁止タイマが存在すると判定されたのであれば、本方法は、717から、「YES」分岐に沿って721に進む。いくつかのシステムでは、例えば、通信が停止することを回避するために、特定の破損パケットのために送られるNAKの数に制限がある。そのようなシステムでは、ブロック721は、最大数のNAKが、そのパケットのために送られたかどうかを判定する。最大数でなければ、本方法は、721から「No」分岐に沿って709に進み、NAK処理が実行され、破損パケットのための別のNAKが開始される。721では、最大数の再送信が送られたと判定されると、本方法は、721から「Yes」分岐に沿って、723において誤り処理が実行される。この誤り処理は、システムへの誤り報告と、PDUホールを埋めるためのギャップ停止手段として、恐らくは、隣接パケットからのデータを用いた誤り復元ルーチン又はデータ補間を要しうる。あるいは、破損スロットは、ブランクのままかもしれない。723の誤り処理を終了すると、本方法は703に進む。
717に戻り、以前に送られたNAKのために期限切れになったNAK禁止タイマが存在しないと判定された場合、本方法は、717から「NO」分岐に沿って703に進む。703では、例えば、データ送信が終了するか、又はあるユーザ或いは他のユーザが切断又はハングアップされて通信が終了したかが判定される。703において、通信が終了していないと判定されると、本方法は、703から「No」パスに沿って705に進み、PDUが次のスロットで受信されたかが検出される。通信が終了している場合、本方法は、703から「YES」パスに沿って725に進み、通信を終了させるルーチンが実行され方法が終了する。
図8は、本発明の様々な実施例に従ってリンク制御の一部としてNAKを開始する方法を示す。特に図8は、図7のブロック709のNAK処理の詳細を示す。そのため、図8の801は一般に、図7の707あるいは721のうちの何れかの後に実行される。801が721の後に実行される場合、処理中の破損データパケットのために有効なNAK特有のNAK禁止タイマは存在しないだろう。なぜなら、717で、前のNAK禁止タイマが期限切れになったと判定されたからである。801では、707において、破損パケットを検出することに応じてNAKが送られることを阻止する有効なNAK禁止タイマが存在するかが判定される。動作中のNAK禁止タイマは頻繁には存在しないだろう。なぜなら、破損パケットは、NAK禁止タイマが存在しない最初の送信であるか、あるいは、破損パケットは、NAK禁止タイマが期限切れ又はほとんど期限切れによる再送信であるかの何れかだからである。受信エンティティが、再送信される破損パケットの識別表示を検出することができる状態の場合、別のNAKの送信を更に遅らせる必要がないので、受信エンティティは、NAK禁止タイマにおける残りの時間を終了するかもしれない。
801において、有効であるNAK禁止タイマが存在すると判定された場合、本方法は、801から「YES」分岐に沿って803に進み、NAK禁止タイマが有効期限になった後、NAKを後で送るためにキューする。いくつかの実施例では、NAKは、NAK禁止タイマが期限切れになることに応じて送られうる。一方、他の実施例では、システムは、送られるべきNAKが存在すると判定すると、動作中のNAK禁止タイマをチェックし、動作中のNAK禁止タイマが見つからない場合にはNAKを送る。803において、NAKが、送信のためにキューされると、本方法は、図7の703に進む。801において、有効なNAK禁止タイマが存在しないと判定された場合には、本方法は、801から「NO」分岐に沿って805に移動する。
805では、NAKを含む任意の状況報告を送ることを阻止する動作中の状況禁止タイマが存在するかが判定される。任意の特定のパケット又はNAKに特有ではない状況禁止タイマは、RLCウィンドウをより感度良く前に進めるために、一般に、RTTよりも幾分短く設定される。一般に、状況禁止タイマは、RTTの1/2から1/10に設定されうる。極端な例では、状況禁止タイマは、高々1RTTで、かつ1スロット幅以上に設定されるべきである。805では、状況禁止タイマが有効であると判定されると、本方法は、805から「YES」分岐に沿って803に進み、NAKを、状況禁止タイマがもはや動作しなくなった場合に送るためにキューする。805では、有効である状況禁止タイマが存在しないと判定された場合には、本方法は、805から「NO」分岐に沿って807に進む。ブロック807では、NAKが受信エンティティから送信エンティティに送信され、本方法は、図7の703に進む。
図9は、本発明の様々な実施例に従って、リンク制御の一部としてACKを開始する方法を示す。特に、図9は、図7のブロック715のACK処理の詳細を示す。そのため、図9の901は、一般に、図7の713又は719かの何れかに続いて行われる。901では、RLCウィンドウがどの程度まで移動されるべきであるかが、すなわち、どのスロットまでが全てのPDUを正しく受信したのか(再送信を含む)が判定されるか、あるいは説明される。状態変数VR(R)は、受信機ウィンドウの最初を示すシーケンスに従って受信された最も直近の連続番号を表す。ブロック901は、例えば、状態変数VR(R)の値に基づいて、ウィンドウをどの程度移動すべきかを判定する。最後に正確に受信された連続PDUである時間スロット、すなわちHARQインスタンスは、ACKが送られるためのものである。状況報告では、1つのPDUのみがアクノレッジされる必要がある。一般に、事前調整された取り決めによって、ACK内で指定されたものの前の全てのPDUは正しく受信されていると仮定される。他のいくつかの実施例では、これは、ウィンドウを進めるために、最後に正しく受信されたPDUを指定するのではなく、受信されたPDUの全てをリストすることによって、より煩わしい方法で達成されるかもしれない。901では、ウィンドウをどの程度移動し、どのPDUをアクノレッジすべきかが一旦決定されると、方法は903に進む。
903では、ACK禁止タイマが有効であるかが判定される。ACK禁止タイマは、通信のパラメータ及びタイムリーなデータに対する要求に基づいて、受信エンティティ内における広範な値のうちの任意の値に設定されうる。例えば、比較的高いデータレートの場合、ACK禁止タイマは、受信機ウィンドウをより感度良く前に進めるために、1RTTよりも幾分短い値に設定される。一方、比較的低いデータレートの場合、特に、受信機ウィンドウを前に進める緊急の必要性がないのであれば、ACK禁止タイマは、(しばしば1RTTよりも僅かに大きく設定される)NAK禁止タイマよりも長い値に設定される。更に、ACKカウンタが実装される場合には、ACK禁止タイマは、ギャップ停止手段となるので、ACK禁止タイマのために使用される値は、比較的大きな値に設定される。
903では、ACK禁止タイマが動作していると判定された場合には、本方法は、903から「YES」分岐に沿って905に進み、ACK禁止タイマが一旦時間切れになると、ACKを送信のためにキューする。いくつかの実施例では、ACK禁止タイマが時間切れになることに応じてACKが送られうる一方、他の実施例では、受信エンティティは、送られるACKが存在することを判定すると、動作中のACK禁止タイマをチェックし、動作中のACK禁止タイマが見つからないのであればACKを送る。905では、送信のためにACKが一旦キューされると、本方法は図7の717に進む。903では、有効なACK禁止タイマが存在しないと判定されると、本方法は、903から「NO」分岐に沿って907に進む。
907では、ACKを含むあらゆる状況報告を送ることを阻止する状況禁止タイマが存在するかが判定される。状況禁止タイマが現在動作中であると判定された場合には、本方法は、907から「YES」分岐に沿って905に進み、状況禁止タイマがもはや動作していない時に、送信のためACKをキューする。907では、有効な状況禁止タイマが存在しないと判定されると、本方法は、907から「NO」分岐に沿って909に進む。ブロック909では、ACKが受信エンティティから送信エンティティへ送信され、本方法は、図7の717に進む。909又は905では、新たなACK禁止タイマ設定が、一般的な条件に適切であると判定された場合には、909又は905のACKを経由して送信エンティに伝達される。
図10は、ACKカウンタ処理を示す。これは、本明細書で開示された様々な実施例に従って、ACK報告期間を調節するために使用されうる。特に、図10は、図7のブロック711のACKカウンタ処理の詳細を示す。図10のブロック1001は、一般に、図7の709の後に実施される。ACKカウンタが有効である場合、ACK報告機能は主に、ACKカウンタによって起動されるので、ACK禁止タイマが、比較的長い値に設定されうる。
ACKカウンタは、現在のデータ送信レートに応じるようにACK報告期間を適応させるので、RLCウィンドウを効率的に前に進め続けることを支援する。ACKカウンタがない状態では、例えば、送信データレートが変化した場合、送信条件変化として、送信エンティティは、新たなACK禁止タイマ値を、受信エンティティに伝達する。データレートの変化にしたがってACK禁止タイマが調節されないのであれば、RLCスループットは制限されるか、あるいは低下するかもしれない。例えば、ACK禁止タイマが、比較的大きな値に設定され、データレートが突然増加すれば、RLCスループットは制限されるだろう。同じ理由で、例えば、ACK禁止タイマが比較的低い値に設定され、レートが突然減少すれば、不必要に大きなシグナリング負荷が、反対方向に、受信エンティティから送信エンティティへ逆に引き起こるかもしれない。
ACK禁止タイマを、送信データレートのために非効率な値に設定することを避けるために、本明細書で開示する様々な実施例は、ACK_Counter変数を有する。ACK_Counter変数は、受信エンティティが、最後のACK値が報告されてからVR(R)値が増加した量を追跡することを可能にする。状態変数VR(R)は、シーケンスに従って受信した最も直近の連続番号を表すので、ACKカウンタは、受信機ウィンドウが埋められる範囲を示す。ACK_Counterが、予め定めた閾値を通過すると、ACKは、送られた次の状況報告とともに報告されるので、前述した性能上の欠点を回避する。この閾値は、様々なデータレートに関連付けられたインクリメントか、あるいは設定された受信機ウィンドウサイズの割合かの何れかによって定義されうる。
状態変数VR(R)は、受信エンティティにおいて、シーケンスに従って受信された最も直近のPDUを表わす。受信エンティティにおいて、別の連続するPDUが正しく受信される毎に、状態変数VR(R)がインクリメントされる。図10の1001では、VR(R)が閾値に達したかが判定される。この閾値は、例えば受信機ウィンドウの10%から50%の値のように、設定された受信機あるいはRLCウィンドウサイズの割合として定義される。例えば、ウィンドウサイズの80%まで、あるいはそれ以上のように、リンク制御条件に適切な、より小さい、あるいは大きなウィンドウサイズの割合が使用されてもよい。1001では、VR(R)が閾値に達したと判定されると、本方法は、1001から「YES」分岐に沿って1003へ進む。1003では、通信条件に適切な新たなACKタイマ設定が決定されると、ACKを経由して送信エンティティに伝達される。ACK禁止タイマのための調節を含むACKが、受信エンティティから送信エンティティへと一旦送られると、本方法は、1003から、図7の703に戻る。ACKカウンタを使用する1つの利点は、ACK報告の頻度が、レート条件に容易に適用されうることである。比較的高い送信データレートについては、ACKは、より頻繁に報告されるようになり、RLCウィンドウをより速く進めることが可能となる。レートが劇的に低くなる場合、ACKは、それほど頻繁に報告されないように調節され、もって、反対方向におけるシグナリング負荷を低減する。ACK値が報告されない状態を回避するために、図9を用いて説明したACK禁止タイマが維持されうる。ACK報告期間を、比較的大きな値に設定し続けることは、システムフィードバックリソースに極めて多くの量まで負担をかけることではない。ある意味では、ACKカウンタがイネーブルされる場合、ACK禁止タイマは、ACK報告期間のための最大境界値の役割をすると見なされるかもしれない。同様に、最も高いデータレートの場合、ACK報告頻度は、状況禁止タイマによって、最低値に制限される。
図面は、本発明を説明し可能にし、かつ本発明の原理を例示するために提供される。図中における方法ブロック図に示す本発明を実行するための動作のうちのいくつかは、図中に示すもの以外の規則で実施されるかもしれないし、あるいは完全に省略されるかもしれない。例えば、図7では、通信が終了するかの判定(703)は、次のPDUを検出すること(705)と同時に、又はその後に起こるかもしれない。同様に、ACKカウンタ処理(711)は、いくつかの実施例では、NAK処理(709)の前に行なわれ、他の実施例では、次のPDUの検出(705)の後に行われ、他の実施例では、全く実施されないかもしれない。
当該技術分野における熟練者であれば、これら情報および信号が、種々異なった技術や技法を用いて表されることを理解するであろう。例えば、上述した記載の全体で引用されているデータ、指示、命令、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または磁性粒子、光学場または光学微粒子、あるいはこれら何れかの組み合わせによって表現されうる。これら熟練者であれば、更に、ここで開示された実施例に関連して記載された様々な説明的論理ブロック、モジュール、回路、およびアルゴリズムステップが、電子工学ハードウェア、コンピュータソフトウェア、あるいはこれらの組み合わせとして実現されることを理解するであろう。ハードウェアとソフトウェアとの相互互換性を明確に説明するために、様々に例示された部品、ブロック、モジュール、回路、およびステップが、それらの機能に関して一般的に記述された。それら機能がハードウェアとして又はソフトウェアとして実現されているかは、特定のアプリケーション及びシステム全体に課せられている設計制約に依存する。熟練した技術者であれば、各特定のアプリケーションに応じて変更した方法で上述した機能を実施しうる。しかしながら、この適用判断は、本発明の範囲から逸脱したものと解釈されるべきではない。
ここで開示された実施例に関連して記述された様々の説明的論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ(DSP)、アプリケーションに固有の集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)あるいはその他のプログラマブル論理デバイス、ディスクリートゲートあるいはトランジスタロジック、ディスクリートハードウェア部品、又は上述された機能を実現するために設計された上記何れかの組み合わせを用いて実現又は実行されうる。汎用プロセッサとしてマイクロプロセッサを用いることが可能であるが、代わりに、従来技術によるプロセッサ、コントローラ、マイクロコントローラ、あるいは状態機器を用いることも可能である。プロセッサは、たとえばDSPとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、DSPコアに接続された1つ以上のマイクロプロセッサ、またはこのような任意の構成である計算デバイスの組み合わせとして実現することも可能である。
ここで開示された実施例に関連して記述された方法やアルゴリズムのステップは、ハードウェアや、プロセッサによって実行されるソフトウェアモジュールや、これらの組み合わせによって直接的に具現化される。ソフトウェアモジュールは、RAMメモリ、フラッシュメモリ、ROMメモリ、EPROMメモリ、EEPROMメモリ、レジスタ、ハードディスク、リムーバブルディスク、CD−ROM、あるいは当該技術分野で知られているその他の型式の記憶媒体に収納されうる。典型的な記憶媒体は、プロセッサがそこから情報を読み取り、またそこに情報を書き込むことができるようにプロセッサに結合される。または、記憶媒体はプロセッサに統合されうる。このプロセッサと記憶媒体は、ASIC内に存在することができる。ASICは、ユーザ端末内に存在することもできる。あるいはこのプロセッサと記憶媒体は、ユーザ端末内のディスクリート部品として存在しうる。
「典型的な」(exemplary)という用語は、例、インスタンス、又は例示として役立つことを意味する。本明細書において「典型的な」(exemplary)と記述された実施例及び特徴は、本発明の他の実施例又は特徴よりも好適であるとか、有利であるとか必ずしも解釈される必要はない。
開示された実施例における上述の記載は、当該技術分野におけるいかなる人であっても、本発明の活用または利用を可能とするように提供される。これらの実施例への様々な変形例もまた、当該技術分野における熟練者に対しては明らかであって、ここで定義された一般的な原理は、本発明の主旨または範囲を逸脱せずに他の実施例にも適用されうる。このように、本発明は、ここで示された実施例に制限されるものではなく、ここで記載された原理と新規の特徴に一致した最も広い範囲に相当するものを意図している。