(57)【特許請求の範囲】
【請求項１】
送信ノードと受信ノードの間に少なくとも１つの通信経路を提供する無線システムにおける通信方法であって、
前記送信ノードから送信されたデータ・パケットのシーケンス内の少なくとも１つのデータ・パケットについての、前記受信ノードのところで受信機において生起する失速状態の可能性を、前記送信ノードのところで送信機にて判定する工程であって、前記失速状態の可能性が、前記無線システムについての、前記送信機にて判定可能な少なくとも１つのシステム・パラメータに関係して判定されるものである工程と、
前記失速状態の前記判定された可能性に基づいて前記受信機に対して、前記失速状態を終了させるフラッシュ・コマンドを送信する工程と、を含む方法。
方法。
【請求項２】
前記フラッシュ・コマンドを送信する工程に先立って、前記失速状態の前記判定された可能性の関数として待ち時間を見積もる工程を含む、請求項１に記載の方法。
【請求項３】
前記待ち時間を見積もる工程が、
送信に先立って少なくとも第１のデータ・パケット用のタイム・スロットの平均数を測定する工程を含む、請求項２に記載の方法。
【請求項４】
前記待ち時間のスロットの平均数を測定する工程が、
送信用に少なくとも前記第１のデータ・パケットを保存する工程と、
前記第１のデータ・パケットよりも低位のシーケンス指定を有する第２のデータ・パケットが失速しているかどうかを判定する工程とを含む、請求項３に記載の方法。
【請求項５】
前記フラッシュ・コマンドを送信する工程が、
前記第２のデータ・パケットが失速していると判定したことに応答して前記第１のデータ・パケットを送信する工程を含む、請求項４に記載の方法。
【請求項６】
前記第１のデータ・パケットを送信する工程が、
前記第２のデータ・パケットが特定のメモリ・ロケーション用に指定されるかどうかを判定する工程であって、前記特定のメモリ・ロケーションが有限バッファの一端に存在する工程とを含む、請求項５に記載の方法。
【請求項７】
失速状態の前記判定された可能性に応答してサービス・タイムアウト条件用の推奨範囲を送信する工程であって、前記サービス・タイムアウト条件がＨｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  ＡｃｃｅｓｓサービスとＨｉｇｈ  Ｓｐｅｅｄ  Ｕｐｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓサービスの少なくとも１つと通信する工程を含む、請求項１に記載の方法。
【請求項８】
前記少なくとも１つの無線システム・パラメータが、前記データ・パケットのシーケンスのサイズ、複数の再送要求プロセス、前記複数の再送要求プロセスのそれぞれにとっての少なくとも１つの優先順位、アップリンク上のエラーの可能性、およびダウンリンク上のエラーの可能性を含む、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は遠隔通信に関し、より詳細には無線通信に関する。
【背景技術】
【０００２】
無線通信システムは、複数の地理的に分散したセルラ通信サイトや基地局を採用している。各基地局は、定常すなわち固定型の無線通信デバイスやユニットとの間における通信信号の送受信をサポートする。各基地局は、通常セル／セクタと呼ばれる特定の領域にわたって通信を処理する。無線通信システム用の全サービス・エリアは、展開された基地局用のセルの和集合（ｕｎｉｏｎ）によって定義される。この点に関して、隣接したセル・サイトまたは近くのセル・サイト用のサービス・エリアは、可能であれば、システムの外側境界内の隣接した通信範囲を確保するため、互いに重なり合うことができる。
【０００３】
アクティブなとき、無線ユニットはフォワード・リンクすなわちダウンリンクを介して少なくとも１つの基地局から信号を受信し、リバース・リンクすなわちアップリンクを介して少なくとも１つの基地局へ信号を送信する。セルラ通信システム用のリンクまたはチャネルを定義するための多くの異なるスキームが存在し、これには、たとえばＴＤＭＡ（時分割多元接続）スキーム、ＦＤＭＡ（周波数分割多元接続）スキーム、およびＣＤＭＡ（符号分割多元接続）スキームなどが含まれる。ＣＤＭＡ通信では、異なる無線チャネルは、異なる情報ストリームを暗号化するために使用される異なるチャネル化コードまたはシーケンスによって区別され、これは、同時伝送用の１つまたは複数の異なる搬送周波数で変調することができる。受信側は適切なコードまたはシーケンスを使用して、受信された信号から特定のストリームを復元し、受信された信号を復号することができる。
【０００４】
音声用途のために、従来のセルラ通信システムは無線ユニットと基地局の間の専用リンクを採用している。音声通信は本質的に遅延への耐性が低い。したがって無線セルラ通信システム内の無線ユニットは、１つまたは複数の専用リンクを介して信号を送受信する。この点に関して、アクティブな各無線ユニットは通常、アップリンク上の専用リンクだけでなく、ダウンリンク上の専用リンクの割り当ても要求する。
【０００５】
インターネットの爆発的な普及とデータに対する需要の増加によって、リソース管理がセルラ通信システムにおいてますます大きな問題となっている。次世代無線通信システムは、インターネット・アクセスとマルチメディア通信のサポートにおいて高速のパケット・データ・サービスを提供することを期待されている。しかし音声とは異なり、データ通信は遅延への耐性が比較的高く、潜在的に集中的な性質を内在することがある。そういうものとして、データ通信はダウンリンクまたはアップリンク上の専用リンクを要求せずに、むしろ１つまたは複数のチャネルを複数の無線ユニットによって共有できるようにする場合がある。この構成によって、アップリンク上の各無線ユニットは、利用可能なリソースを求めて競い合う。アップリンクにおける管理対象リソースは、基地局で受信された電力と、各ユーザによって、たとえば他のセクタまたはセル内だけでなく、同一のセクタまたはセル内の他のユーザに対して生じた干渉とを含む。これは、固定された送信電力の割当量（ｂｕｄｇｅｔ）を含むダウンリンク上の管理対象リソースとは対照的である。
【０００６】
データ通信は遅延への耐性が比較的高く、潜在的に集中的な性質を内在することがあるが、次世代無線通信システムにおいて予想される１つの問題は、データ・ブロックまたはデータ・パケット送信の失敗である。より具体的には、たとえば基地局は複数のパケットからの１つまたは複数のデータ・パケットを、識別された無線ユニットへ首尾よく送信できない場合がある。この失敗の結果、基地局はハイブリッド自動再送要求（「ＨＡＲＱ」）などの任意の数の再送信技術を使用して、たとえば無線ユニットによって首尾よく受信されなかったデータ・パケットを配送することがある。しかし基地局が、以前に首尾よく送信できなかったパケットの再送信を試みている間に、他のデータ・パケットが後からその無線ユニットに送信される場合がある。
【０００７】
Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（「ＨＳＤＰＡ」）システムでは、各無線ユニットは、基地局によって設定されるタイマを採用している。パケット・データは基地局から無線ユニットへシーケンス方式（ｓｅｑｕｅｎｔａｌ  ｍａｎｎｅｒ）で送信される。無事に受信されると、無線ユニットは、処理用にそのバッファからパケット・データを同じシーケンス・オーダー（ｓｅｑｕｅｎｔｉａｌ  ｏｒｄｅｒ）で配送する。もしも受信中に、受信されたデータ・パケットのシーケンス・オーダー（ｓｅｑｕｅｎｔｉａｌ  ｏｒｄｅｒ）にギャップが生じたと無線ユニットが判断した場合、無線ユニットは未着データ・パケット用のタイマを始動させる。このタイマはタイム・ウィンドウを提供し、このウィンドウ内で無線ユニットは、未着と認識された各データ・パケットが送信および／または再送信スキームによって首尾よく受信されるのを待つ。タイマ・ウィンドウが終了する前に、再送信スキームが未着データ・パケットを無線ユニットに首尾よく配送できない場合、無線ユニットはそのパケットが失われたとみなす。
【０００８】
データ・パケットは、様々な理由で失われることがある。第１のシナリオとしては、データ・パケットを再送信する試みが最大限度を超過し、これ以上の再送信は許容できないと基地局が判断する場合がある。第２のシナリオとしては、基地局がデータ・パケットの送信や再送信を一方的に中断するよう決定する場合がある。第３のシナリオとしては、より優先順位の高いカスタマまたはより優先順位の高いデータが基地局のリソースを必要としていると基地局が判断し、それに従って「未着」データ・パケットの送信および／または再送信を終了する場合がある。第４のシナリオとしては、無線ユニットが、エラーを伴って送信されたデータ・パケットを受信する場合がある。この点に関しては、無線ユニットがＮＡＣＫ（たとえば、エラーを伴ったデータ・パケットの受信を示す否定応答）を送信する一方で、基地局は代わりにＡＣＫ（たとえば、無線ユニットがデータ・パケットを首尾よく受信したことを示す肯定応答）を誤って受信し、結果的に基地局内では再送信がまったく行われない。
【０００９】
したがってＨＳＤＰＡシステムでは、未着である１つまたは複数のデータ・パケットが送信および／または再送信のいずれかの時点で失われたと基地局が判断する場合がある。しかし対照的に無線ユニットは、タイマが切れるまで未着データ・パケットが失われたことを確認しない。したがって無線ユニットは、受信されたデータ・パケットを処理する前に、および／または様々な他の技術によって失われたパケットの回復を試みる前に、タイマが切れるまで待たなければならない。タイマが切れるまでのこの遅延または待ち時間は、時に失速期間と呼ばれる。
【００１０】
失速期間の長さは、比較的長時間に及ぶことがある。基地局は、たとえば再送信を中断することによって、またはより優先順位の高いカスタマやより優先順位の高いデータに対応するよう決定することによって、基地局によるタイマの設定よりも大幅に短い時間で、未着パケットが失われたと判定を下す場合がある。未着データ・パケットを再送信する試みを無線ユニットが所定の回数処理できるように、タイマは当初控えめに設定されている点に留意されたい。各送信を完了するまでの時間にはばらつきがあるため、再送信の試みを所定の回数完了するまでの時間は異なる可能性がある。したがって有効な送信が尚早に終了することのないように、タイマは控えめに設定されている。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記の結果として、不要な遅延を回避するかまたは最小限に抑える効率的で高速なデータ通信をサポートする方法に対する需要が存在する。さらに、無線ユニットにおける失速状態（ｓｔａｌｌｉｎｇ  ｃｏｎｄｉｔｉｏｎ）期間の影響を最小限に抑える方法に対するニーズが存在する。
【課題を解決するための手段】
【００１２】
本発明は、遠隔通信ネットワークにおける失速状態の影響を最小限に抑えるデータ通信のための方法を提供する。より詳細には、本発明は、複数のシーケンス・データ・パケットの１つがオーダーの乱れた（ｏｕｔ−ｏｆ−ｏｒｄｅｒ）受信によって失速する（ｓｔａｌｌ）可能性を判定する方法を提供する。判定された失速状態の可能性によって、本発明は、失速状態の影響を軽減するフラッシュ・コマンド（ｆｌｕｓｈ  ｃｏｍｍａｎｄ）を送信することができる。本発明の目的のために、フラッシュ・コマンドは、データ・パケットが失速しているかどうかを検出するために、そして失速したデータ・パケットを無線ユニットで特定のメモリ・ロケーション（たとえば有限バッファの一端）用に指定できるかどうかを検出するために、基地局（たとえばノードＢ）と通信することができる。
【００１３】
本発明の一実施形態では、失速状態の可能性は、データ・パケットのシーケンス内にある少なくとも１つのデータ・パケット用に判定される。またこの方法は、判定された失速状態の可能性に応答してフラッシュ・コマンドを送信する工程も含む。フラッシュ・コマンドの送信に先立って、失速状態用に判定された可能性に応答して待ち時間を見積もることができる。この待ち時間は、１つのデータ・パケットを送信できる前に必要となるタイム・スロットの平均数を測定することによって見積もることができる。見積もられた待ち時間は、データ・パケットのシーケンス内で低位の（たとえば前の）指定を有する別のパケットを首尾よく送信できたことや、失速状態用に判定された可能性（たとえば非失速状態の可能性）に依存する場合がある。
【００１４】
この実施形態および他の実施形態は、以降の詳細な説明を添付の特許請求の範囲および本明細書に付属の図面と併せて読めば、当業者には明らかになるであろう。
本発明は、添付の図面を参照しながら非限定的な実施形態に関する以降の説明を読むことによって、よりよく理解できるであろう。
【００１５】
本出願の図面は正確な縮尺を期したものではなく、単なる概略図であり、したがって本発明の具体的な寸法を描くことを意図したものではないことを強調しておきたい。本発明の具体的な寸法は、当業者が本明細書の開示を精査することによって測定することができる。
【発明を実施するための最良の形態】
【００１６】
本発明は、遠隔通信ネットワークにおける失速状態の影響を最小限に抑えるデータ通信のための方法を提供する。より詳細には、本発明は、複数のシーケンス・データ・パケットの１つがオーダーの乱れた受信によって失速する可能性を判定する方法を提供する。判定された可能性によって、本発明は失速状態の影響を軽減するよう試みることができる。
【００１７】
図１を参照すると、本発明の一実施形態を示すフローチャートが描かれている。より詳細には、遠隔通信ネットワークにおける失速状態の影響を最小限に抑えるためのアルゴリズム的方法（１０）が示されている。本発明の一実施例では、Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（「ＨＳＤＰＡ」）および／またはＨｉｇｈ  Ｓｐｅｅｄ  Ｕｐｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（「ＨＳＵＰＡ」）のサポートにおいてパケットが送信される場合に、失速状態が生じる可能性がある点に留意されたい。したがってこれらのパケットは、具体的に指定されたシーケンスまたはオーダーを有する場合がある。
【００１８】
図１のアルゴリズム的方法（１０）は、はじめにデータ・パケットのシーケンスからの少なくとも１つのパケット用の失速状態の可能性を判定する工程（工程２０）を含む場合がある。失速状態の可能性は、１つまたは複数のシステム・パラメータに応答して判定することができる。このシステム・パラメータは、基地局（たとえばノードＢ）において利用可能、確認可能、および／または計算可能とすることができる。この１つまたは複数のシステム・パラメータは、たとえばデータ・パケットのシーケンスのサイズ、複数の再送要求プロセス、その複数の再送要求プロセスのそれぞれにとっての少なくとも１つの優先順位、アップリンク上のエラーの可能性（たとえばアップリンク応答エラー）、およびダウンリンク上のエラーの可能性（たとえばダウンリンクパケット送信エラー）を含むことができる。
【００１９】
少なくとも１つのパケット用の失速状態の可能性が判定されると、その後図１のアルゴリズム的方法（１０）は、失速状態の影響を軽減するよう試みる前の待ち時間を見積もる工程（工程３０）を含むことができる。この待ち時間を見積もる工程は、失速状態の可能性を判定したことに応答して実行することができる。より詳細には、この待ち時間を見積もる工程は、データ・パケットのシーケンスからの１つのデータ・パケット（たとえば最新のデータ・パケット）が送信に先立って（たとえば最新のデータ・パケットの送信に先立って）経験する可能性のあるタイム・スロットの数を測定する工程を含むことができる。一実施例では、タイム・スロットの数は平均とすることができる。
【００２０】
タイム・スロットの数を測定する工程は複数の工程によって実現できる点に留意されたい。この点に関して、最新のデータ・パケットが送信用に最初にきっかけを与えられる場合がある。その後、最新のデータ・パケットよりも低位のシーケンス指定を有し、かつ以前に送信されたがまだ受信されていない別のデータ・パケットが失速する可能性があるかどうかについて判定が下される。これらの工程から、最新のデータ・パケット用に見積もられた待ち時間の有意性を得ることができる。
【００２１】
次いで図１のアルゴリズム的方法（１０）は、その後に失速状態の影響を軽減するフラッシュ・コマンドを送信する工程（工程４０）を含むことができる。フラッシュ・コマンドの送信は、判定された可能性に応答して実行することができる。本発明の目的のために、フラッシュ・コマンドは、データ・パケットが失速しているかどうかを検出するために、そして失速したデータ・パケットを無線ユニットで特定のメモリ・ロケーション（たとえば有限バッファの一端）用に指定できるかどうかを検出するために、基地局（たとえばノードＢ）と通信することができる。
【００２２】
本発明の一実施形態では、フラッシュ・コマンドを送信する工程は、最新のデータ・パケットよりも低位のシーケンス指定を有し、かつ以前に送信された別のデータ・パケットが失速していることを判定したことに応答して前述の最新のデータ・パケットを送信することによって、実現することができる。この時点で、受信側は最新のデータ・パケットを受信することができる。次いで受信側および／または送信側で、失速したデータ・パケットが特定のメモリ・ロケーション用に指定されたかどうかについて判定を下すことができる。一実施例では、特定のメモリ・ロケーションは有限メモリ・バッファの一端（たとえば、最上部または最下部）に存在する。たとえば、失速したデータ・パケットがバッファの最下部用に指定された場合、送信側はフラッシュ・コマンドを実行することができ、これによって最新のデータ・パケットは、隣接するメモリ・ロケーション内のデータ・パケットにバッファ内のギャップを埋めさせる。
【００２３】
図２を参照すると、本発明の別の実施形態を示すフローチャートが描かれている。より詳細には、たとえば基地局（たとえばノードＢ）と基地局コントローラ（たとえば無線ネットワーク・コントローラ）など、遠隔通信ネットワーク内のインフラストラクチャ・エレメントの間の失速状態に対処するためのアルゴリズム的方法（１００）が示されている。本発明の一実施例では、Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（「ＨＳＤＰＡ」）および／またはＨｉｇｈ  Ｓｐｅｅｄ  Ｕｐｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（「ＨＳＵＰＡ」）などのサービスのサポートにおいてパケットが送信される場合に、失速状態が生じる可能性がある点に留意されたい。したがってこれらのパケットは、具体的に指定されたシーケンスまたはオーダーを有する場合がある。
【００２４】
図２のアルゴリズム的方法（１００）は、データ・パケットのシーケンスからの少なくとも１つのパケット用の失速状態の可能性を判定する工程（工程１２０）を含む。一実施例では、失速状態の可能性を判定する工程は、１つまたは複数のシステム・パラメータに応答して基地局（たとえばノードＢ）で実施することができる。これらのシステム・パラメータは、基地局（たとえばノードＢ）において利用可能、確認可能、および／または計算可能とすることができる。この１つまたは複数のシステム・パラメータは、たとえばデータ・パケットのシーケンスのサイズ、複数の再送要求プロセス、その複数の再送要求プロセスのそれぞれにとっての少なくとも１つの優先順位、アップリンク上のエラーの可能性、およびダウンリンク上のエラーの可能性を含むことができる。
【００２５】
少なくとも１つのパケット用の失速状態の可能性が判定されると、図２のアルゴリズム的方法（１００）は、判定された可能性に応答してサービス・タイムアウト条件用の推奨範囲を計算し、送信することができる（工程１３０）。このサービス・タイムアウト条件は基地局（たとえばノードＢ）によって実施され、次いで基地局コントローラ（たとえば無線ネットワーク・コントローラ）へ送信することができる。推奨されたサービス・タイムアウト条件は、ネットワーク効率を維持しつつ失速状態を最小限に抑えるために提示されたタイマ範囲に相当する場合がある。
【００２６】
より詳細には、提示されたタイマ範囲から選択されたタイマは、たとえば万一データ・パケットが未着とみなされた場合に始動することができる。タイマが切れると、失速状態の誘因となった未着データ・パケットは失われたとみなされる。タイマが切れると、無線ユニットはパケットが失われたことを上位層に伝える点に留意されたい。したがって、上位層はこの失われたパケットを回復するよう試みることができる。
【００２７】
その後、基地局コントローラ（たとえば無線ネットワーク・コントローラ）は、サービス・タイムアウト条件用の推奨範囲を基地局（たとえばノードＢ）から受信することができる。たとえばコール・セットアップの間、サービス・タイムアウト条件の範囲は、基地局コントローラ（たとえば無線ネットワーク・コントローラ）によって無線ユニットへ送信することができる。次いで無線ユニットは、自身のパフォーマンスを最大に高めるための最適なサービス・タイムアウト条件を選択する。したがって図２のアルゴリズム的方法（１００）は、コール・セットアップ中に基地局コントローラによって測定されたサービス・タイムアウト条件の範囲を無線ユニットへ送信する工程を含むこともできる（工程１４０）。
【００２８】
Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍ  Ｓｅｒｖｉｃｅ（「ＵＭＴＳ」）では、たとえばＨｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（「ＨＳＤＰＡ」）およびＨｉｇｈ  Ｓｐｅｅｄ  Ｕｐｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ（「ＨＳＵＰＡ」）機能用のデータ保全性は、非同期ダウンリンクで同期アップリンク、かつＮ−チャネルのハイブリッド自動再送要求（「ＡＲＱ」）スキームを介して維持することができる。受信側はこのタイプのＡＲＱ法を使用して、本来意図していたシーケンスに拘束されることなくパケットを受け取ることができる。パケットが必ず高位層へ正しいオーダーで転送されるために、並べ替えバッファが受信側のプロトコル内に存在する。したがって、シミュレーションを介して広範囲のシステム・パラメータ値にわたる並べ替えバッファの動作は、失速状態への対処に関連する場合がある。受信側の並べ替えバッファの分析モデルは、失速の可能性および失速を取り除くのにかかると予想された待ち時間を得ることによって採用することができる。この点に関して送信側は、デッド・フェーズ（ｄｅａｄ  ｐｈａｓｅ）に際して、どのような場合に、またどのようなときに受信側において失速を取り除くべきかを決定することができる。
【００２９】
従来のＡＲＱスキームの場合と同様に、各データ・パケットには昇順のシーケンス番号を割り当てることができる。また情報ビットにエラー検出コードを追加し、パケットが肯定的に（たとえばＡＣＫ）または否定的に（たとえばＮＡＣＫ）応答されるよう要求することによって、パケットの配送を保証することもできる。ＮＡＣＫの場合、パケットを再送信すべきである。もしも所定のインターバル内にフィードバック・メッセージが受信されない場合、送信側はこれをＮＡＣＫと解釈できるため、そのパケットを再送信することもでき、したがって同期アップリンクとなる。
【００３０】
たとえばＵＭＴＳでは、ＨＳＤＰＡ機能を導入して、ダウンリンク・パフォーマンスの最大速度およびスループットを増大させることができる。増大における１つの領域は、チャネルの状況に迅速に適合するための即応性を向上させることである。したがって、ＭＡＣ―ｈｓと呼ばれることもあるメディア・アクセス制御（「ＭＡＣ」）エンティティの追加を、ＭＡＣ副層の一部として基地局（たとえばノードＢ）内で実施することができる。基地局内のＭＡＣ―ｈｓエンティティにおいてＮ個のＡＲＱ状態マシンまたはプロセスを介して１つのＡＲＱ技術をサポートすることができる。１つのＡＲＱプロセスは１つのチャネル上でＡＲＱの動作を制御することから、Ｎ個のチャネルに対してはＮ個のＡＲＱプロセスが存在することができる。各無線ユニット用に、新たな送信シーケンス番号（「ＴＳＮ」）をＮチャネル内の各送信に添付することができる。単一の無線ユニット用に最大８つまでの同時チャネルまたはプロセスが存在することができる。これらのプロセスは、トラフィックの異なる優先順位クラスに従ってサブグループに分割することができ、ＴＳＮは各優先順位クラスにとって固有のものとすることができる。
【００３１】
このスキームの下では、データ・パケットは自身の本来のオーダーに拘束されることなく受信側に到達することができる。異なるＨＡＲＱ技術は、それぞれ異なる回数の再送信を要求する場合があるため、再送信プロセスは無作為の時間に首尾よく受信することができる。データ・パケットは各自の本来のオーダーで高位層へ配送されることになっているため、あるパケットは、自分よりも低位のシーケンス番号を有するデータ・パケットがまだ受信されていない場合、高位層へ配送されないことがある。高位層上のシーケンスの乱れたパケットの影響は、特定のサービス用に構成された動作モードに依存する場合がある。
【００３２】
あるパケットが自分よりも低位の未着パケットのために高位層へ配送されない場合、その未着パケットは失速したとみなすことができる。図３を参照すると、受信側における失速の一例が示されている。ここでは、受信側における並べ替えバッファが示されている。ここではパケット＃１、＃２、＃３、＃４が送信されたが、パケット＃２がまだ受信側で正しく受信されていない。パケット＃１は高位層へ配送されたが、並べ替えバッファ内に失速すなわち「ギャップ」があり、パケット＃３および＃４を高位層へ配送できないでいる。
【００３３】
シーケンスの乱れた配送による並べ替えバッファ内のギャップを取り除くために、２つの基本的な失速回避メカニズムを採用することができる。第１の失速回避手法はタイマ・メカニズムを利用する。ここでは、低位のシーケンス番号を有するパケットが到達しないためにあるパケットが高位層に配送されない場合に、タイマを始動することができる。タイマが切れると、ギャップをフラッシュすることができ、高位のＲａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ（「ＲＬＣ」）層を介して、失われたパケットを回復することができる。しかしこの方法によって、待ち時間が増大する。
【００３４】
第２の失速回避はウィンドウ・ベースのメカニズムとすることができる。ここでは、送信側は受信側の並べ替えバッファ内の失速を取り除くために、パケット・シーケンス番号のモジュール性（ｍｏｄｕｌａｒ  ｎａｔｕｒｅ）から得られた１セットのルールの下で動作することができる。ウィンドウ・サイズは、受信側で予想されるシーケンス番号の範囲を定義し、あいまいにならないように、ウィンドウ・サイズはＴＳＮスペースの半分を超えてはならない。たとえばＴＳＮが３ビットを割り当てられている場合、シーケンス番号の範囲は０、１、２、．．．７とすることができる。送信側は、４パケット（またはそれ未満）のＴＳＮウィンドウの範囲内でしかパケットを送信することができない。ＴＳＮ＃１、＃２、および＃３が受信され、＃０が受信されていない場合、送信側は＃０を再送信するか、または新たなパケット＃４を送信することができる。しかし＃４を送信すれば、ウィンドウが進み、＃０が再送信されないことを受信側に伝えることができる。こうすれば、高位層へ配送されない可能性のあるパケット＃０によって高位のパケット上に生じた失速を終了させることができる。
【００３５】
ＵＭＴＳにとって、ウィンドウ・サイズは、受信側で受け入れることができるパケット番号の最大範囲を規定する可能性がある点に留意されたい。ウィンドウ・サイズベースの技術には、こうした最大範囲は存在しない。たとえばＵＭＴＳのウィンドウ・サイズが３である場合、はじめにＴＳＮ｛０、１、２｝を送信することができる。しかし＃１および＃２が受信される一方で、＃０が受信されない場合、＃０を再送信するか、または＃３を送信することができる。＃０を送信した場合、組合せ｛０｝しか許容できないが、一方で＃３を送信した場合、ウィンドウが進み、許容できる組合せは｛３、４、５｝となる。ウィンドウ・サイズベースのスキームでは、｛０、４、５｝を許容することができ、パケット番号の範囲を３よりも大きくすることができる。予想されるシーケンス番号の範囲の増大を認めることができる。一方、ウィンドウ・サイズの定義は、再送信または新たなパケットの送信のいずれかの前に送信されるパケットの番号とすることができる。他のＵＭＴＳスキームでは、新たなウィンドウは、ウィンドウが進んだ場合に新たなパケットを送信することしかできないが、対照的にウィンドウ・サイズベースの技術では、前のウィンドウ内の少なくとも１つのパケットを首尾よく受信できる限り、新たなパケットを各ウィンドウに送信することができる。
【００３６】
さらに、１つのＵＭＴＳのＮ−チャネル・スキームの下では、各プロセスは特定のタイム・スロットと結びついていない場合がある。この点に関して、各プロセスは、より良好な無線通信条件を有するより優先順位の高いクラスのトラフィックやユーザによる優先使用のためにその順番を失う場合がある。実際に送信側は、異なる優先順位クラスおよび他のユーザや内部の優先順位クラスによる優先使用が存在するために、いくつかのタイム・スロットの間、ユーザやユーザ内の特定の優先順位クラスに対して何も送信しない場合がある。
【００３７】
本明細書に記載のウィンドウ・サイズベースの技術は、事前に無限のシーケンス番号スペースを前提としているが、一方で１つのＵＭＴＳ手法は、ＴＳＮに割り当てられたビット数に基づいてモジュラ・スキームを定義する場合がある。直接の結果として、この１つのＵＭＴＳ手法は前述のウィンドウ・メカニズムの下で動作することになる。
【００３８】
図４を参照すると、１つの送信プロセスが示されている。説明をわかりやすくするため、ＨＡＲＱプロセスの数はＴＳＮスペースの半分に等しくすることができると仮定する。さらに、ＮＡＣＫからＡＣＫへのフィードバック・チャネルにおけるエラーも考慮していない。前述の教示の目的から、以下の点に留意されたい。まずはＭ＝１と設定することによる複数の受信側からのバックワード／フォワード・フェーズの表記のケースである。さらにフォワード・フェーズ（「Ｆ」）は、パケットを正しく受信できるまでに、列上の連続したスロットのシーケンスとして定義することができ、一方でバックワード・フェーズ（「Ｂ」）は、対応するＡＣＫを送信側で受信できるまでに、受信に続く列上のスロットのシーケンスとして定義することができる。下線の付いたＦは、バックワード・フェーズなしで生じることができる、たとえば最初の試みでＡＣＫを受信することができる新たなパケット遷移（ｐａｃｋｅｔ  ｔｒａｎｓｉｔｉｏｎ）を識別する点にも留意されたい。パケット・シーケンス番号は、送信プロセスをさらに示す際の補助とすることができる。本明細書で詳述するように、シーケンス番号スペースが０、１、２、．．．７に相当し、４の再送信プロセスが採用され、ＮＡＣＫからＡＣＫへのエラーがない場合、ＴＳＮ用に３ビットを採用できることも前提とすべきである。別の前提は、モジュラ・ウィンドウがシーケンス番号スペースの半分のサイズ、たとえば４を有する場合である。
【００３９】
第１のフレーム／サイクルでは、プロセスＡ、Ｂ、Ｃ、およびＤによってパケット＃０、＃１、＃２、および＃３をそれぞれ送信することができる。成功できるのは、＃０だけである。しかし対応するＡＣＫも、はじめは成功することができる。
【００４０】
第２のフレームでは、プロセスＡ、Ｂ、Ｃ、およびＤによってパケット＃４、＃１、＃２、および＃３をそれぞれ送信することができる。モジュラ・ウィンドウは、第１のフレームの間にパケット＃０を首尾よく受信できたため、進むことができる。パケット＃２は、成功できなかった唯一のパケットである可能性がある。図示してあるように、プロセスＡは、ＡＣＫが正しく受信されていないことを示すためにパケット＃２を送信し続け、やがて受信側内に失速を引き起こす可能性がある。
【００４１】
第３のフレームでは、プロセスＡ、Ｂ、Ｃ、およびＤによってパケット＃４、＃５、＃２、および＃３をそれぞれ送信することができる。モジュラ・ウィンドウは、第２のフレームの間にパケット＃１を首尾よく受信できたため、進むことができる。再びパケット＃２が不成功に終わる。プロセスＡは、ＡＣＫが前のフレームの間に受信されなかったため、＃４を再送信している可能性がある。その一方でプロセスＤは、次のパケット番号＃６が現行ウィンドウの外にあるため、新たなパケットを送信できない可能性がある。この状況は失速フェーズと呼んでさしつかえない。たしかに送信側は、ウィンドウを進めて、その後並べ替えバッファをフラッシュし、それによってデッド・フェーズを回避するよう決定することができる。しかしこれを行うと、高位層におけるパケット回復のために待ち時間が増える可能性がある。
【００４２】
フレーム４では、前のフレームの間にパケット＃２が不成功に終わったために、そしてそれに伴ってウィンドウを進めることができなかったために、プロセスＡ、Ｂ、およびＤが失速フェーズを経験する可能性がある。しかし今度はパケット＃２が成功し、ウィンドウが進み、フレーム５において４つの新たなパケットを送信することができる。失速フェーズによって、各プロセスのパケット更新から次のパケット更新までの時間が増加する。さらに送信プロセス（列）は、もはや独立した存在ではなくなる可能性がある。具体的には、１つのフレーム中の１つのプロセスにおける送信の失敗によって、次のフレームにおける他のすべてのプロセスで新たなパケットを送信できなくなる可能性がある。
【００４３】
例示的な実施形態を参照しながら具体的な発明について説明したが、この説明は限定的な意味で解釈されることを意図したものではない。本発明について説明したが、この説明を参照すれば、本明細書に添付された特許請求の範囲に列挙された本発明の趣旨から逸脱することなく、例示的実施形態に対する様々な修正、ならびに本発明に関する追加の実施形態が当業者にとって明らかになることを理解されたい。したがって方法、システム、およびその一部、ならびに本明細書に記載の方法およびシステムの一部は、ネットワーク・エレメント、無線ユニット、基地局、基地局コントローラ、携帯電話交換局、および／またはレーダー・システムなど、異なる場所に実装することができる。さらに、本明細書に記載のシステムを実装および使用するのに必要な処理回路は、特定用途向け集積回路、ソフトウェア駆動型処理回路、ファームウェア、プログラマブル論理装置、ハードウェア、こうしたコンポーネントの個々のコンポーネントまたは構成内に実装することができ、これは当業者が本開示の利点を享受すれば理解できるであろう。これらの修正、構成、および方法、ならびに他の様々な修正、構成、および方法は、本明細書に図示および記載した代表的な応用例に厳密に準拠することなく、かつ本発明の趣旨および範囲から逸脱することなく本発明に対して実施できることを、当業者なら容易に認識するであろう。したがって添付の特許請求の範囲は、本発明の真の範囲内に収まる修正や実施形態をすべて包含すると考えられる。
【図面の簡単な説明】
【００４４】
【図１】本発明の一実施形態を示すフローチャート図である。
【図２】本発明の別の実施形態を示すフローチャート図である。
【図３】本発明の一態様を示す図である。
【図４】本発明の別の態様を示す図である。
【図１】
0004822728.tif 000002
【図２】
0004822728.tif 000003
【図３】
0004822728.tif 000004
【図４】
0004822728.tif 000005