JP4574927B2 - 可変容量無線データチャンネルのための無線リンクプロトコルフレーム整列機構 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、無線通信に関する。より詳細には、本発明は、誤り制御プロトコル固有の共通費用を最小にしつつ、無線チャンネルを通して、信頼できるようにデータを送信するための、改善された方法とシステムに関する。
【０００２】
【従来の技術】
符号分割マルチプルアクセス（ＣＤＭＡ）変調技術の使用は、多数のシステム加入者が存在する通信を容易にするための、いくつかの技術の一つである。時間分割マルチプルアクセス（ＴＤＭＡ）、周波数分割マルチプルアクセス（ＦＤＭＡ）、および振幅圧伸単側波帯（ＡＣＳＳＢ）などのＡＭ変調方式は、当業界の人には知られている。これらの技術は、異なった会社によって製造された装置間の相互動作を容易にするために、標準化されてきている。符号分割マルチプルアクセス通信システムは米国においては、“デュアルモード広帯域拡散スペクトラムセルラシステムのための移動局‐基地局互換性規格”と題する、参照としてこの中に組み込まれ、そして以後、 ＩＳ‐９５‐Ｂとして参照される、通信機械工業会ＴＩＡ／ＥＩＡ／ＩＳ‐９５‐Ｂの中に標準化されている。
【０００３】
ＩＳ‐９５‐Ｂは、元来可変レート音声フレームの送信のために最適化された。無線電話応用に代表されるような、二方向音声通信をサポートするためには、通信システムは、かなり一定した、そして最小のデータ遅延を与えることが望ましい。この理由から、 ＩＳ‐９５‐Ｂシステムは、強力な順方向誤り訂正（ＦＥＣ）プロトコルおよび、音声フレーム誤りに対して柔軟に対応するように設計されたボコーダを備えて設計された。フレーム再送信手順を必要とする誤り制御プロトコルは、音声送信に対して、許容できない遅延を加えるので、 ＩＳ‐９５‐Ｂ基準の中には企画されていない。
【０００４】
スタンドアローンＩＳ‐９５‐Ｂ基準を音声応用に対して理想的なものとする最適化は、パケットデータ応用への使用を困難なものとする。インターネットプロトコル（ＩＰ）データ送信のような、多くの非音声応用においては、通信システムの遅延要求は、音声応用におけるよりもずっとゆるやかである。インターネットプロトコル回路網に使用される、多分もっとも一般的なプロトコルである送信制御プロトコル（ＴＣＰ）においては、誤りのない送信を保証するために、実質上無限の送信遅延が許容されている。送信制御プロトコルは、インターネットプロトコルパケットが通常呼ばれるように、この輸送信頼性を与えるために、インターネットプロトコルデータグラムの再送信を使用している。
【０００５】
インターネットプロトコルデータグラムは、通常、単一のＩＳ‐９５‐Ｂフレーム中に収容するには大きすぎる。一つのインターネットプロトコルデータグラムを、一組のＩＳ‐９５‐Ｂフレームの中に収容するのに十分な大きさまで小さく分割した後であっても、全体のＩＳ‐９５‐Ｂフレームの組み合わせは、送信制御プロトコルにとって有用であるためには、単一のインターネットプロトコルに対して誤りなく受信されなければならないであろう。 ＩＳ‐９５‐Ｂシステムに関して典型的な目標フレーム誤り率は、単一のデータグラムのすべてのセグメントに関する、誤りない受信の確率を非常に低いものとする。
【０００６】
ＩＳ‐９５‐Ｂに述べられているように、代わりのサービスオプションは、音声フレームの代わりに他のデータ形式の送信を可能にする。“拡散スペクトラムシステムのためのデータサービスオプション”と題する、今後ＩＳ‐７０７として参照される、通信機械工業会暫定標準ＴＩＡ／ＥＩＡ／ ＩＳ‐７０７‐Ａは、 ＩＳ‐９５‐Ｂシステムにおけるパケットデータの送信に用いられる一連の手順を記述している。
【０００７】
無線リンクプロトコル（ＲＬＰ）は、“拡散スペクトラムシステムのためのデータサービスオプション：無線リンクプロトコル タイプ２”と題する、今後ＲＬＰ２として参照される、そしてこの中に参照によって組み込まれている、ＴＩＡ／ＥＩＡ／ＩＳ‐７０７‐Ａ．８の中に記述されている。ＲＬＰ２は、誤り制御プロトコルを、ＩＳ‐９５‐Ｂフレームレイヤーにフレーム再送信する手順と組み合わせている。ＲＬＰは、当業界の人には有名な、ＮＡＫに基づいたＡＲＱプロトコルとして知られる、誤り制御プロトコルの一つのクラスである。 ＩＳ‐７０７ ＲＬＰは、一連の音声フレームよりはむしろバイトストリームの 、ＩＳ‐９５‐Ｂ通信システムを通しての送信を容易にする。
【０００８】
いくつかのプロトコルレイヤーは、典型的にＲＬＰレイヤーの上に常在している。たとえば、インターネットプロトコルデータグラムは、ＲＬＰプロトコルレイヤーへ、バイトストリームとして与えられる前に、ポイントツーポイントプロトコル（ＰＰＰ）バイトストリームに典型的に変換される。ＲＬＰレイヤーは、プロトコルおよびより高いプロトコルレイヤーのフレーミングを無視するので、ＲＬＰによって輸送されたデータのストリームは、“特徴のないバイトストリーム”であるといわれる。
【０００９】
ＲＬＰは、 本来、ＩＳ‐９５‐Ｂチャンネルを通して大きいデータグラムを送る要求を満足させるために設計された。たとえば、もし５００バイトのインターネットプロトコルダイアグラムが、それぞれ２０バイトを運ぶＩＳ‐９５‐Ｂフレームに送られた場合、このインターネットプロトコルデータグラムは、２５個の連続したＩＳ‐９５‐Ｂフレームを満たすであろう。インターネットプロトコルダイアグラムが、より高いプロトコルレイヤーに対して有用であるためには、若干の種類の誤り制御レイヤーなしに、これらＲＬＰフレームの２５個すべては、誤りなしに受信されなければならない。１％のフレーム誤り率を有しているＩＳ‐９５‐Ｂチャンネル上では、インターネットプロトコルデータグラム配送の実効的誤り率は、（１−（０．９９）^２５）、すなわち２２％となるであろう。これは、インターネットプロトコルトラフィックを運ぶのに用いられる大部分の回路網と比較して、非常に高い誤り率である。ＲＬＰは、インターネットプロトコルトラフィックの誤り率を、１０ベース２イーサネットチャンネルにとって典型的な誤り率と同程度まで減少させる、リンクレイヤープロトコルとして設計された。
【００１０】
ＩＴＵは最近、無線通信チャンネルに高いレートデータおよび高品質の音声サービスを与えるための提案の提出を要求している。これらの提案の第一は、“ｃｄｍａ２０００ ＩＴＵ‐Ｒ ＲＴＴ提出案”と題して、通信機械工業会によって発行された。通信機械工業会は、現在ｃｄｍａ２０００提案を、暫定標準ＴＩＡ／ＥＩＡ／ＩＳ‐２０００として作成中であり、今後ｃｄｍａ２０００として参照される。
“ＥＳＴＩ ＵＭＴＳ 地球無線アクセス（ＵＴＲＡ）ＩＴＵ‐Ｒ ＲＴＴ提出案”と題する、また“広帯域ＣＤＭＡ”としても知られる、そして今後Ｗ‐ＣＤＭＡとして参照される、これらの提案の第二は、欧州電気通信標準協会（ＥＴＳＩ）によって発行された。“ＵＷＣ‐１３６提出案”と題する、今後ＥＤＧＥとして参照される、第三の提案は、米国ＴＧ８／１によって提出された。これらの提案の内容は、公的記録であり、当業界の人にはよく知られている。
【００１１】
ＲＬＰ２は、ＩＳ‐９５‐Ｂとともに使用するよう設計されている。ｃｄｍａ２０００とともに使用するよう設計された新しいＲＬＰは、“拡散スペクトラムシステムのためのデータサービスオプション：無線リンクプロトコル タイプ３”と題する、今後ＲＬＰ３Ｅとして参照され、参照によってこの中に組み込まれている、ＴＩＡ／ＥＩＡ／ＩＳ‐７０７‐Ａ‐１．１０の中に述べられている。関係する技術の記述に関して、通常フレームとして参照される二つの用語は、次のような差異を有している。
・ ＩＳ‐９５‐Ｂおよびｃｄｍａ２０００において、基本的タイミング間隔はフレームと呼ばれる。この種のフレームは今後ＣＤＭＡフレームとして参照される。ＣＤＭＡフレームは、信号情報、第一のトラフィック、第二のトラフィック、あるいはその組み合わせを含むことができる。
・ ＲＬＰ３Ｅにおいて、送信の基本ユニットはフレームと呼ばれる。この種のフレームは、今後ＲＬＰフレームとして参照される。ＲＬＰフレームは、ペイロードデータ、シーケンス番号、ＲＬＰ制御情報（たとえばＳＹＮＫ、ＮＡＫ、等）、あるいはこれらの組み合わせを含むことができる。今後シーケンス番号に対するすべての参照は、ＲＬＰシーケンス番号に対して参照される。
【００１２】
ＩＳ‐９５‐Ｂにおいては、基本および補足チャンネルは、固定された２０ミリ秒期間のＣＤＭＡフレームを有している。 ＩＳ‐９５‐Ｂ補足チャンネルに送信されるＣＤＭＡフレームは、ＣＤＭＡフレームが基本チャンネルに送信されるのと同時に送信される。すべてのＩＳ‐９５‐Ｂ補足ＣＤＭＡフレームは固定された２０ミリ秒の期間であるので、同時に送信を開始したすべての基本および補足ＣＤＭＡフレームは、後に同時に受信機によって受信されるであろう。
【００１３】
ｃｄｍａ２０００は、 ＩＳ‐９５‐Ｂのそれとは全く異なる補足チャンネル構造を有している。ｃｄｍａ２０００は、今後補足１および補足２として参照される二つの補足チャンネルをもつことができる。サービスネゴシエーションの期間中、移動局および基地局は配列をネゴシエートする。その一部は補足チャンネルＣＤＭＡフレーム期間である。それぞれの補足チャンネルに対してネゴシエートされうる期間は、２０ミリ秒、４０ミリ秒、そして８０ミリ秒である。将来、期間は、６０ミリ秒のような代替的あるいは付加的な値を含むかも知れない。もしも６０ミリ秒のＣＤＭＡフレーム長さが、決して存在することがなければ、それで必要性および本発明の価値が減少することは決してない。しかし、６０ミリ秒の値は考えられるために、そしてまた本発明は、現在ｃｄｍａ２０００では用いられていない期間を考慮に入れているために、６０ミリ秒ＣＤＭＡフレーム期間の存在を仮定するこの標準を通して、種々のシナリオが与えられる。
【００１４】
一つのチャンネルに送信されうるデータの総量は、ＣＤＭＡフレーム期間に関係するので、今後ＣＤＭＡフレーム期間は、ＣＤＭＡフレーム長さとして参照する。ｃｄｍａ２０００は、ネゴシエートされた配列が、補足２に対するＣＤＭＡフレーム長さと、補足１に対するＣＤＭＡフレーム長さとが異なっていることを許容する。ｃｄｍａ２０００基地局のような一つのエンティティ（entity）から、異なった符号チャンネルへのデータパケットの同時送信をサポートし、加入者データを基本および補足チャンネルに同時に、ｃｄｍａ２０００移動局のような他の装置に対して送信する能力を有するいかなる通信システムも、今後ｃｄｍａ２０００類似システムとして参照する。
【００１５】
ＲＬＰ２、ＲＬＰ３Ｅ、および現存のＲＬＰ実行において、ＲＬＰプロトコルリンクのおのおのの側において、３個の変数が維持される。これらの変数は、Ｖ（Ｒ）、Ｖ（Ｎ）、およびＶ（Ｓ）である。ＲＬＰ標準のところで論じたように、Ｖ（Ｒ）は、受信される次の新しいフレームにおけるＲＬＰフレームシーケンス番号フィールドに関する、予測される値を含む。Ｖ（Ｎ）は、順々に受信されていない、次に必要とされるフレームのシーケンス番号を含む。送られて来たそれぞれの新しいＲＬＰデータフレーム内の、また、送られて来たそれぞれの新しいＲＬＰアイドルフレーム内の、シーケンス番号フィールド‘ＳＥＱ’は、Ｖ（Ｓ）にセットされるであろう。変数Ｖ（Ｒ）、Ｖ（Ｎ）、およびＶ（Ｓ）のそれぞれは、短縮された（８‐ｂｉｔ）ものであり、フル（１２‐ｂｉｔ）シーケンス番号の空中に対するバージョンＬ＿Ｖ（Ｒ）、Ｌ＿Ｖ（Ｎ）、およびＬ＿Ｖ（Ｓ）もまた、ＲＬＰプロトコルリンクのおのおのの側において維持される。
【００１６】
ＲＬＰ２およびすべての他のＲＬＰｓは、本質的に２０ミリ秒ごとに多重化サブレイヤーから呼ばれるステートマシンとして設計されている。各２０ミリ秒間隔で、多重化サブレイヤーは、ＲＬＰにフィジカルレイヤーから受信したフレーム組み合わせを配送する。それぞれの時刻に、多重化サブレイヤーはＲＬＰエンジンとしても知られているＲＬＰステートマシンに、フレームの組み合わせを配送する。ＲＬＰステートマシンは、ちょうど受信したフレームのシーケンス番号をＬ＿Ｖ（Ｒ）およびＬ＿Ｖ（Ｎ）と比較する。ＲＬＰが新しい‘ホール’が作られたのを発見したときには、ＮＡＫが発生される。‘ホール’という語は、通常当業界において熟練した人により、ＲＬＰ３Ｅエンジンによって連続的でないシーケンス番号を含むフレーム組み合わせが受信されたことを表すのに使用される。‘新しいホール’は、更新されたＬ＿Ｖ（Ｒ）が、前のＬ＿Ｖ（Ｒ）と異なるときはいつでも作られ、前のＬ＿Ｖ（Ｒ）よりも大きいシーケンス番号で受信されたすべてのフレームは連続したシーケンス番号を有しない。
【００１７】
ＲＬＰ３Ｅは多くの点でＲＬＰ２と似ている。一部は、これは符号再使用が与えることのできる多くの利点を得るために行われた。ＲＬＰ３Ｅは、ＲＬＰ２同様、一つのフレームシーケンス番号を、送信されそして受信されたそれぞれのＲＬＰフレームと組み合わせるように設計されている。予想されないシーケンス番号が受信されたときはいつでも、ＮＡＫとして参照される再送信の要求が、同様のＲＬＰ装置に送られる。
【００１８】
同時に送信されたすべてのＩＳ‐９５‐Ｂ ＣＤＭＡフレームは、同時に受信機によって受信されるために、ＲＬＰ２内には不要な再送信は発生しない。もしもＲＬＰ２ステートマシンが、補足チャンネルへのすべてのフレームの同時送信に起因する、多重化サブレイヤーからの２０ミリ秒フレーム組み合わせの受信によって、ホールが作られていることを発見したときには、それは、ホール内のフレームが受信機への途中で、失われあるいは劣化していることを意味する。このようなホールに対して発生された、このようなＮＡＫは不必要ではないので、ホールへのフレームの再送信は望ましいことである。しかし、同じ方法を用いることは、ｃｄｍａ２０００補足チャンネルがフレキシブルな性質を有するために、ＲＬＰ３Ｅが不必要な再送信を行う原因となる。前に述べたように、ｃｄｍａ２０００においては、補足チャンネルに対してＣＤＭＡフレーム長さを変えることが可能であるからである。このような変化は意図的でなしに、ＲＬＰ３Ｅがホールを検出し、不必要なＮＡＫを発生する原因となりうる。
【００１９】
たとえば、図１Ａは、１個の基本チャンネルと、２個の補足チャンネルがある、ＲＬＰ３Ｅデータコールに対して発生されたＲＬＰデータフレームの、１６０ミリ秒時刻間隔を示している。示されているように、補足１は、８０ミリ秒のＣＤＭＡフレーム長さを有し、補足２は、６０ミリ秒のＣＤＭＡフレーム長さを有し、そしてこの時刻間隔の最初におけるＲＬＰシーケンス番号は５である。時刻０において、多重化サブレイヤーは、基本チャンネルおよびそれぞれの補足チャンネルのフレーム期間に対応する３個のフレーム長さについてＲＬＰエンジンに質問する。これに応えて、ＲＬＰエンジンは、シーケンス番号５、６、および７を有する３個のＲＬＰフレームを発生する。２０ミリ秒境界においては、シーケンス番号８を有するＲＬＰフレームが、基本チャンネルに対応する単一フレーム長さに関する質問に答えて発生される。４０ミリ秒境界においては、シーケンス番号９を含むＲＬＰフレームが発生される。６０ミリ秒境界においては、多重化サブレイヤーは、基本チャンネルおよび補足２に対応するフレーム長さについて質問する。これに応えて、ＲＬＰエンジンはシーケンス番号１０および１１を有する２個のＲＬＰフレームを発生する。同様に、シーケンス番号１２及び１３をもったＲＬＰフレームが、同様な理由で、８０ミリ秒境界において発生される。フレーム１４〜１７は、図１Ａに示された時刻において、同様な理由で発生される。
【００２０】
受信ＲＬＰ３Ｅエンジンによる、上に述べたフレームの受信は、図１Ｂに示されている。図１Ｂは、図１Ａにおいてなされている受信されたフレームに関する、長さ／期間は示していない。むしろ、図１Ｂは、フレームが、受信している多重化サブレイヤーから、ＲＬＰ３Ｅ受信エンジンに与えられる時刻を示している。図１Ｂは、図１Ａにおいて完了しているフレーム送信の時刻と、ＲＬＰ３Ｅ受信エンジンが、多重化サブレイヤーによってそこに配送されたフレームを有している時刻とに、遅延がないと仮定している。たとえば、フレーム５の送信は図１Ａにおいて時刻２０ミリ秒において終了しているゆえに、この信号は、図１Ｂにおける、時刻２０ミリ秒においてＲＬＰ３Ｅ受信エンジンによって受信されている。フレーム７および９の送信は、図１Ａにおける６０ミリ秒において完了しているので、それらは、図１Ｂにおける６０ミリ秒において、ＲＬＰ３Ｅエンジンによって、処理のために受信される。同様にして、フレーム６および１０の送信は、図１Ａにおける時刻８０ミリ秒において完了しているので、これらのフレームは、図１Ｂの時刻８０ミリ秒において、ＲＬＰ３Ｅ受信エンジンによって、処理のために受信される。フレーム８および１１から１７までの受信は、同様な方法で線図化されている。
【００２１】
図との比較によって明らかなように、順次増加するシーケンス番号で送信されたＲＬＰフレームは、受信ＲＬＰエンジンによって順序正しく受信されない。フレームは、ＲＬＰ３Ｅがシーケンス番号を発生したと同じシーケンスで送信を開始したが、これらのフレームは異なった順序で受信された。すなわち、ＲＬＰシーケンス番号５から１７を含むＣＤＭＡフレームは、次の順序、５、６、７、８、９、１０、１１、１２、１３、１４、１５、１６、１７で送信されたが、フレーム期間の差によって、すでに、５、８、７、９、６、１０、１２、１１、１４、１５、１３、１７、１６の順に受信された。当業界の熟練した人には明らかなように、ＮＡＫｓはこのタイミングおよびフレーム８、１２、１４、および１７が受信された順序のために、フレーム６、７、１１、１３、および１６に対して発生されるであろう。
【００２２】
当業界の熟練した人は承知しているように、ＮＡＫｓの発生は、すでに受信されているべきＲＬＰデータフレームの送信を、受信機が受信するのに失敗した場合のみ行われるべきであろう。しかし、ｃｄｍａ２０００の可変的なＣＤＭＡフレーム長さのために、不必要なＮＡＫｓが、シーケンス番号が受信されるタイミングのために発生されうる。これは順方向および逆方向リンク両者の貴重な帯域幅を浪費する、望ましくない影響の原因となる。帯域幅は、一つのリンクに送信されたそれぞれのＮＡＫによって、また反対方向のリンクへ不必要に再送信されたデータフレームによって浪費される（不必要な再送信されたデータフレームは、それぞれの受信された不必要なＮＡＫに対して発生される）。
【００２３】
空間に対する帯域幅は、貴重な資源であるので、ｃｄｍａ２０００に対してデータを配送する改善された方法が望まれる。とくに、不必要なＮＡＫおよび再送信を発生しない、ｃｄｍａ２０００に対するデータ配送のための方法が強く望まれる。これらの方法は、ＲＬＰより上のレイヤーに対するデータフレーム配送の待時間を増加させず、また多重化サブレイヤーに対する有効なＮＡＫフレームの配送の待時間を増加させないことが望ましい。とくに、これらの方法が、現在のＲＬＰ３Ｅの実行に対して要求される変化を最小にして、現在の業務に効果を発揮することが望まれる。
【００２４】
【課題を解決するための手段】
本発明は、ＲＬＰ３Ｅが不必要なＮＡＫｓを発生することを防止し、したがってまた不必要なデータフレーム再送信を防止する、新しいそして改善された方法およびシステムである。本発明は、より高いデータサービスレイヤーへのデータフレームの配送を遅らせることなく、また、多重化サブレイヤーへの必要なＮＡＫｓの配送を遅らせることもない効率的な方法である。さらに、本発明は、現在のＲＬＰ３Ｅ実行に対する変化を最小として実行することができる。本発明は、ｃｄｍａ２０００、Ｗ‐ＣＤＭＡ、およびＥＤＧＥなど、データがＡＲＱ（再送信に関する自動的要求）メカニズムを用いて転送され、データパケットが時にそれらが送信されたときとは異なった順序で受信されるシステムに適用可能である。
【００２５】
ＲＬＰフレームの送信および受信に関しては、ＲＬＰ３Ｅは、一般にそれよりも下の多重化サブレイヤーおよびそれよりも上のバイトストリームレイヤーと通信する。バイトストリームレイヤーは、ＰＰＰが一般にバイトストリームレイヤーで用いられるプロトコルであるために、通常ＰＰＰレイヤーとして参照される。しかし、バイトストリームレイヤーはＰＰＰである必要はない（ＩＳＤＮ、あるいは複数のプロトコルの一つであることができる）ので、ここでは、バイトストリームレイヤーとして参照する。前に述べた通信フローは、ｃｄｍａ２０００に対するデータ経路を示しているブロック線図である、図２に示されている。
【００２６】
本発明は、すべての到来するトラフィックに対して、多重化サブレイヤーおよびＲＬＰ３Ｅレイヤー間に挿入された新しいメカニズムを利用している。このサブレイヤーの目的は、受信したパケットを送信されたときの順序に再配列し、そしてこの順序で、ＲＬＰ３Ｅレイヤーにパケットを配送することである。このサブレイヤーは、今後フレーム再配列サブレイヤーと呼ばれ、図３に説明されている。
【００２７】
フレーム再配列サブレイヤーは、多重化サブレイヤーによって受信されたフレームを、フィジカルレイヤーフレームが同等の装置によって送信されている順序を決定することによって、また、それに先立って送信されたすべてのフレームが受信されてしまうまで、それぞれのフレームをバッファリングすることによって再配列する。フレーム再配列サブレイヤーは、これをタイマーおよび／あるいはフレームカウンタ、およびメモリバッファリングメカニズムを用いて達成している。
【００２８】
本発明の特徴、目的、そして利点が、図面と関連させた場合に、以下に記述する詳細な説明からより明白になろう。図面において同様の参照符号は、全体を通して同一のものと認定する。
【００２９】
【発明の実施の形態】
図１Ａおよび図１Ｂは、ｃｄｍａ２０００に類似した無線データ回路網上で、送信されそして受信されるデータフレームの時刻関係を説明しているタイムライン線図である。図１Ａは、基本チャンネル１０および、２個の補足チャンネルを含む、ＲＬＰ３Ｅデータ送信システム５のために発生された、ＲＬＰデータフレームの１６０ミリ秒時刻間隔を説明している。第１の補足チャンネル２０は、８０ミリ秒のＣＤＭＡフレーム期間で構成される。一方第２の補足チャンネル３０は、６０ミリ秒のＣＤＭＡフレーム期間で構成される。この説明は、１６０ミリ秒時刻間隔の開始時、ＲＬＰ３Ｅエンジンは５にセットされたＶ（Ｓ）を有していると仮定している。説明のように、基本チャンネル１０は、シーケンス番号５、８、９、１０、１２、１４、１５、および１７のＲＬＰ３Ｅフレームを含む２０ミリ秒のＣＤＭＡフレームを送信する。第１の補足チャンネル２０は、シーケンス番号６および１３のＲＬＰ３Ｅフレームを含む８０ミリ秒のＣＤＭＡフレームを送信する。第２の補足チャンネル３０は、シーケンス番号７、１１、および１６のＲＬＰ３Ｅフレームを含む６０ミリ秒のＣＤＭＡを送信する。図１Ａに示したように、シーケンス番号５、６、および７を有するフレームは、時刻０において送信を開始する。シーケンス番号５のＲＬＰ３Ｅフレームを含むＣＤＭＡフレームであるフレーム５は、時刻２０において、基本チャンネル１０への送信を終了する。フレーム６は、第１の補足２０に、時刻８０において送信を終了し、そしてフレーム７は、第２の補足３０に、時刻６０において送信を終了する。フレーム８〜１６が送信を開始し、終了する時刻は、同様な方法で示されている。
【００３０】
図１Ｂは、基本チャンネル１０、第１の補足チャンネル２０、および第２の補足チャンネル３０を含む、ＲＬＰ３Ｅデータ受信システム４５のために受信されたＲＬＰデータフレームの、１６０ミリ秒時刻間隔を示している。図１Ｂは、図１Ａにおいて送信されたデータフレームが、同等のｃｄｍａ２０００によって受信された時刻を示している。補足および基本チャンネルは、図１Ｂにおいて、これらが、図１Ａの送信システム５によって使用される同じチャンネルとして参照されることを示すために、１０、２０、および３０と名付けられている。示されたように、ＲＬＰ３Ｅデータ受信システム４５は、ＲＬＰ３Ｅデータ送信システム５による送信の終了に続いて、すぐにＲＬＰ３Ｅフレームを受信する。基本チャンネル１０、第一の補足チャンネル２０、第二の補足チャンネル３０に共通の、任意の伝搬遅延を導入することは、説明の変更を伴わず、単純化のために省略されている。フレーム５は、基本１０上のＲＬＰ３Ｅデータ受信システム４５によって、時刻２０において受信される。フレーム６は、第一の補足２０上のＲＬＰ３Ｅデータ受信システム４５によって、時刻８０において受信される。フレーム７は、第二の補足３０上のＲＬＰ３Ｅデータ受信システムによって、時刻６０において受信される。フレーム８〜１６が受信される時刻は同様な方法で示されている。
【００３１】
図１Ａおよび図１Ｂの両者の考察によって、フレームは、ＲＬＰ３Ｅデータ送信システム５によって送信されたときとは異なった順序で、ＲＬＰ３Ｅデータ受信システム４５によって受信されていることは明らかである。
【００３２】
図２は、通信デバイス２１０および２３０に具体化された、ｃｄｍａ２０００データ受信システム２５０の、典型的実施例の機能的ブロック線図である。説明の都合上、ｃｄｍａ２０００データ送信システムは、順方向リンク上へのパケットデータの送信の形で示されている。しかし、説明は容易に逆方向リンク送信に適用した場合に拡張される。基地局２１０の中には、バイトのストリームをＲＬＰ３Ｅレイヤー２１４に与えるバイトストリームレイヤー２１２が存在する。ＲＬＰ３Ｅレイヤー２１４は、これらのバイトを後の送信のためにバッファーする。２０ミリ秒のフレーム境界間隔において、多重化サブレイヤー２１６はＲＬＰ３Ｅレイヤー２１４からのＲＬＰフレームを要求する。これに応じてＲＬＰ３ＥレイヤーはＲＬＰ３Ｅ仕様に従ってＲＬＰフレームを発生し、これらを多重化サブレイヤー２１６に与える。ＲＬＰ３Ｅ仕様は、ＲＬＰ３Ｅレイヤーが多重化サブレイヤーによって要求されたフレーム長さに従って、フレームシーケンス番号を割り当てるであろうことは規定していない。典型的実施例においては、多重化サブレイヤー２１６は、ｃｄｍａ２０００仕様に従ってこれらのＲＬＰフレームを、カプセルに収納する。多重化サブレイヤー２１６はそこで、ｃｄｍａ２０００仕様に従って、これらのカプセルに収納されたＲＬＰフレームを、フィジカルレイヤー２１８にｃｄｍａ２０００空中リンク２２０への送信のために与える。フィジカルレイヤー２１８にフレームを与えるときに、多重化サブレイヤー２１６は、どのフレームがどのチャンネルに対して送信されるべきかを示す。
【００３３】
移動局２３０のフィジカルレイヤー２３８は、ｃｄｍａ２０００空中リンク２２０からフレームを受信する。２０ミリ秒の間隔で、フィジカルレイヤー２３８は、それぞれ受信されたフレームを多重化サブレイヤー２３６に与え、そして多重化サブレイヤー２３６に、どのチャンネルで各フレームが受信されたかを示す。多重化サブレイヤー２３６は、ｃｄｍａ２０００仕様に従って、ＲＬＰフレームをカプセルから取り出し、ＲＬＰフレームをＲＬＰ３Ｅレイヤー２３４に与える。ＲＬＰ３Ｅレイヤー２３４は、ＲＬＰ３Ｅ仕様に従って、これらのフレームに関するＲＬＰフレーム処理を実行する。何れかの受信されたフレームが、Ｖ（Ｎ）に等しいシーケンス番号をもっている場合、Ｖ（Ｎ）で始まる連続的なシーケンス番号をもっている、すべての受信されたＲＬＰフレームのペイロードは、ＲＬＰ３Ｅレイヤー２３４によってバイトストリームレイヤー２３２に与えられる。新しいホールが作られたときは、一つあるいはそれ以上のデータフレームが、再送信される必要のあることを信号するために、ＮＡＫが発生される。
【００３４】
以上の記述は、順方向リンク方向におけるｃｄｍａ２０００データフローの典型的実施例を述べている。当業界の熟練した人によって知られているように、データフローは、反対方向の経路に沿って逆方向リンク方向にも起きる。
【００３５】
図３は、通信デバイス３１０および３４０に具体化された、本発明のデータサービス送信システム３６０の典型的実施例に関する機能的ブロック線図である。基地局３１０内には、 バイトのストリームをＲＬＰ３Ｅレイヤー３１４に与える、バイトストリームレイヤー３１２が存在する。ＲＬＰ３Ｅに与えられたバイトは一般的にＰＰＰフレームフォーマットである。しかし、ＲＬＰ３Ｅは、これらのバイトを未加工のバイトストリームとして処理し、そしてしたがって、バイトストリームレイヤー３１２における、バイトのいかなるフォーマッティングも、本発明にとっては重要ではない。ＲＬ３Ｅレイヤー３１４は、後の送信のために、現在のＲＬＰ３Ｅ仕様に従って、受信されたバイトをバッファする。２０ミリ秒のフレーム境界間隔で、多重化サブレイヤー３１８は、ＲＬＰ３Ｅレイヤー３１４からのＲＬＰフレームを要求する。これらの要求に従って、ＲＬＰ３Ｅレイヤーは、本発明の方法に従ってＲＬＰフレームを発生する。
【００３６】
本発明の方法は、現在のＲＬＰ３Ｅ仕様を堅持した、そしてまた、次の制約を堅持したＲＬＰ３Ｅレイヤー３１４を利用している。多重化サブレイヤー３１８がＲＬＰ３Ｅレイヤー３１４からの、複数のチャンネルのためのデータフレームを要求するとき、そしてそこにＲＬＰ３Ｅレイヤー３１４が、複数の新しいデータフレーム（再送信ではないＲＬＰフレーム）を発生するであろうときに、ＲＬＰ３Ｅレイヤー３１４はこの結果、もっとも短いＣＤＭＡフレーム長さをもっている新しいデータフレームに、最小の新しいシーケンス番号を与え、もっとも長いＣＤＭＡフレーム長さをもっている新しいデータフレームに、最大のシーケンス番号を与えることを要求される。図５、図６、図７、図８、図９、そして図１０を参照してさらに論じるが、この制約は、フレーム再配列サブレイヤー３４６が、受信されたフレームをＲＬＰ３Ｅレイヤー３４４に配送するであろうときに正確な決定をするのを助ける。
【００３７】
多重化サブレイヤー３１８は、ＲＬＰ３Ｅレイヤーによって与えられたＲＬＰフレームを、ｃｄｍａ２０００仕様に従ってカプセルに収納する。多重化サブレイヤー３１８は、そこでこれらのカプセル収納されたＲＬＰフレームを、ｃｄｍａ２０００空間リンク３３０への送信のために、ｃｄｍａ２０００仕様に従って、フィジカルレイヤー３２０に与える。フレームをフィジカルレイヤー３２０に与えるときに、多重化サブレイヤー３１８は、どのチャンネルに、どのフレームが送信されるべきかを示す。
【００３８】
移動局３４０のフィジカルレイヤー３５０は、ｃｄｍａ２０００空間リンク３３０からフレームを受信する。２０ミリ秒間隔で、フィジカルレイヤー３５０は、それぞれの受信されたフレームを多重化サブレイヤー３４８に与え、多重化サブレイヤー３４８に、各フレームがどのチャンネルで受信されたかを示す。多重化サブレイヤー３４８は、ＲＬＰフレームをｃｄｍａ仕様に従ってカプセルから取り出し、それらをフレーム再配列サブレイヤー３４６に与える。図４および図５を参照して記述したとおり、フレーム再配列サブレイヤー３４６は、本発明の方法に従って、受信されたＲＬＰフレームをバッファーし、そしてそれらを、それらが送信されたときの順序で、ＲＬＰ３Ｅレイヤー３４４に与える。 ＲＬＰ３Ｅレイヤー３４４は、ＲＬＰ３Ｅ仕様に従って、これらのフレームに関するＲＬＰフレーム処理を行う。何れかの受信されたフレームがＶ（Ｎ）に等しいシーケンス番号を有しているときは、Ｖ（Ｎ）で始まる一連のシーケンス番号を有する、すべての受信されたＲＬＰフレームのペイロードは、ＲＬＰ３Ｅレイヤー３４４によってバイトストリームレイヤー３４２に与えられる。新しいホールが検出されるときは、一つあるいはそれ以上のデータフレームが再送信される必要があることを信号するためのＮＡＫが発生される。
【００３９】
図４は、コールセットアップ期間中の、フレーム再配列サブレイヤー３４６の初期化に関する、典型的実施例を説明しているフローチャートである。ブロック４００においてサービスネゴシエーションが始まる。典型的実施例においては、サービスネゴシエーションは、“移動通信システムにおけるサービスネゴシエーションを与えるための方法”と題する、本発明の譲渡人に譲渡され、参照としてこの中に組み込まれている、米国特許５，６３８，４１２の中に記述されている方法に従って実行される。ブロック４１０において、アクティブな補足チャンネルの数、補足チャンネルのオフセット（ＳＣＨ＿ＯＦＦＳＥＴｓ）、および補足チャンネルのフレーム期間が決定され、そしてこれらのチャンネルはそれに応じて割り当てられる。
【００４０】
一度チャンネルが割り当てられると、処理はブロック４２０に移る。ブロック４２０においては、フレーム再配列サブレイヤー３４６は、変数およびタイマーを初期化する。アクティブな補足チャンネルの番号が記録される。もしも、補足チャンネル１がアクティブであれば、そのチャンネルに対するフレーム期間が記録され、そしてタイマーはそのオフセット値にセットされる。もしも、補足チャンネル２がアクティブであれば、そのチャンネルに対するフレーム期間が記録され、そしてタイマーはそのオフセット値にセットされる。たとえば、もしもシステムが図９Ａに示されたように配置されていれば、タイマーは６０ミリ秒にセットされるであろう。タイマーは、したがって時刻６０、基地局３１０が補足１に最初にフレームを送信した時刻を示す点９１０において終了するであろう。その上、補足１におけるフレーム期間は８０ミリ秒であることが記録されるであろう。
【００４１】
他の例として、もしシステムが図９Ｂに示されたように配置されていれば、第一のタイマーは２０ミリ秒にセットされ、第二のタイマーは６０ミリ秒にセットされるであろう。第一のタイマーは時刻２０において、基地局３１０が補足１に最初にフレームを送信した時刻を示す点９６０において終了するであろう。一方第二のタイマーは、基地局３１０が補足２に最初にフレームを送信した時刻を示す時刻６０において、終了するであろう。その上、補足１のフレーム期間は８０ミリ秒、そして補足２のフレーム期間は６０ミリ秒であることが記録されるであろう。
【００４２】
代わりの実施例においては、もしも正確に一つのアクティブな補足チャンネルがあれば、タイマーは、チャンネルオフセットプラス２０ミリ秒に等しい時刻に初期化される。
【００４３】
典型的実施例においては、変数およびタイマーの中の共通のインデックスは相互の関連を表示する。たとえば、ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］およびＳＵＰ＿ＴＩＭＥＲ［１］は、両者ともインデックス１を有するゆえに関連している。これらタイマーおよび変数のすべては、インデックスを示す変数を用いることによって参照され得る。たとえば、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］は、もしもＸが１の値をもてば、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｘ］として参照され得る。一方ＳＵＰ＿ＤＵＲＡＴＩＯＮ［２］は、もしもＸが２の値をもてば、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｘ］として参照され得る。当業界において熟練している人には知られている、インデックスとなる標記は、いくつかの変数およびタイマーに関して今後使用されるであろう。
【００４４】
一つの実施例においては、フラッグ、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫは、図６、図７、および図８を参照して記述された、ステートマシンが最初にブロック６６０あるいはブロック７８０に入ったときに、この間隔中にブロック５０２に受信された基本ＲＬＰ３Ｅフレームは、ＲＬＰ３Ｅレイヤー３４４に進められるべきであることを示すために、ＴＲＵＥにセットされる。
【００４５】
典型的実施例においては、変数およびタイマーはブロック４２０において次のように初期化される。ＭＯＤＥ変数は、フレーム再配列サブレイヤーが、多重化サブレイヤー３４８から受信したすべてのフレームを、ＲＬＰ３Ｅレイヤー３４４に進めるであろうモードにあることを示している、順方向にセットされる。少なくとも一つの補足チャンネルがアクティブであるときは、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］は、ブロック４１０において、補足チャンネル１に対して取り決められたＣＤＭＡフレーム期間にセットされる。タイマーＳＵＰ＿ＴＩＭＥＲ［１］は、補足チャンネル１に対して取り決められたチャンネルオフセットに続いて終了するようにセットされる。二つの補足チャンネルがアクティブであるときは、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［２］は、ブロック４１０において、補足チャンネル２に対して取り決められた、ＣＤＭＡフレーム期間にセットされる。第二のタイマーＳＵＰ＿ＴＩＭＥＲ［２］は、補足チャンネル２に対して取り決められた、チャンネルオフセットに続いて終了するようにセットされる。一つの実施例においては、フラッグ、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫは、次の２０ミリ秒境界において受信された基本ＲＬＰ３Ｅフレームが、ＲＬＰ３Ｅレイヤー３４４に進められるべきであることを示すために、ＴＲＵＥにセットされる。さらに、変数、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［１］および、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［２］は、基地局３１０が、補足チャンネル１あるいは補足チャンネル２それぞれに、いかなるフレームもまだ送信していないことを示している、ＮＯ＿ＳＵＰＳ＿ＴＸＤにセットされる。最後に、二つの補足チャンネルがアクティブであるときは、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］は、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［２］と比較される。もしも、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［２］が、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］よりも大きければ、そこでインデックスＬは２にセットされ、インデックスＳは１にセットされる。そうでなければ、インデックス変数Ｌは１にセットされ、そしてインデックス変数Ｓは２にセットされる。したがって、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｌ］はもっとも長いフレーム期間を返し、一方ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｓ］はもっとも短いフレーム期間を返し、そしてＳＵＰ＿ＴＩＭＥＲ［Ｌ］は、もっとも長いフレーム期間を有しているチャンネルに関連したタイマーを参照し、一方ＳＵＰ＿ＴＩＭＥＲ［Ｓ］は、もっとも短いフレーム期間を有しているチャンネルに関連したタイマーを参照する。
【００４６】
典型的実施例においては、フレームをバッファーし、バッファーからフレームを回収するための時刻基準として、システム時刻が用いられる。当業界において熟練した人にはよく知られているように、代わりの実施例においては、システム時刻の参照は、少なくとも２０ミリ秒の粒子性をもった時刻基準として使用される変数で置き換えることができる。たとえば、代わりの実施例においては、フレームインデックス変数ＲＥＬ＿ＴＩＭＥを、フレームをバッファーし、バッファーからフレームを回収するための時刻基準として用いることができる。変数ＲＥＬ＿ＴＩＭＥを利用している代わりの実施例においては、 ＲＥＬ＿ＴＩＭＥは、ブロック４２０において０に初期化され、後に、１などの一定した数値づつ増加される。各時刻に処理はブロック５０２に移動する。
【００４７】
一度データサービスオプションが結合されると、データフローはブロック３６０で始まる。ブロック３６０についてはさらに図３を参照して記述される。
【００４８】
上記の記述は、フレーム再配列サブレイヤー３４６の初期化に関する典型的実施例を明細に示した。変数ＬおよびＳが保存される必要のない、代わりの実施例が存在する。このような実施例の一つは、それぞれの変数Ｌの使用を、ＳＵＰ＿ＦＲＡＭＥ＿ＤＵＲＡＴＩＯＮ［１］、およびＳＵＰ＿ＦＲＡＭＥ＿ＤＵＲＡＴＩＯＮ［２］の最大値と組み合わせられた、インデックスを返す処理をコールして、返された値で置き換えており、そしてそれぞれの変数Ｓの使用を、 ＳＵＰ＿ＦＲＡＭＥ＿ＤＵＲＡＴＩＯＮ［１］、およびＳＵＰ＿ＦＲＡＭＥ＿ＤＵＲＡＴＩＯＮ［２］の最小値と組み合わせられた、インデックスを返す処理をコールして、返された値で置き換えている。
【００４９】
図５は、典型的実施例におけるフレーム再配列レイヤー３４６によって使用されている方法を示すフローチャートである。
【００５０】
ブロック５００において、処理はその先を処理する前に、基本チャンネルフレーム境界を待つ。典型的実施例においては、処理は２０ミリ秒フレーム境界を各時刻に検出する。２０ミリ秒期間の間に多重化サブレイヤー３４８によって受信されたＲＬＰ３Ｅフレームを含む、フレーム再配列サブレイヤー３４６に対するメッセージを、多重化サブレイヤー３４８は配送する。
【００５１】
代わりの実施例においては、多重化サブレイヤー３４８によって受信されたＲＬＰ３Ｅフレームは、フレーム再配列サブレイヤー３４６によってアクセスが可能なデータストアに収納される。その後、フレーム再配列サブレイヤー３４６と通信中のレイヤーは、２０ミリ秒フレーム境界が終了したこと、そして０あるいはそれ以上の受信されたＲＬＰ３Ｅフレームがさきに述べたデーターストアを経由してアクセス可能であることを示しているメッセージを、フレーム再配列サブレイヤー３４６に配送する。この代わりの実施例においては、サブレイヤー３４８と通信中のレイヤーは、タイマーサブシステム、インタラプトサブシステム、あるいは任意の他のサブシステム、あるいはまた、移動局３４０における、それぞれの２０ミリ秒フレーム境界の後でフレーム再配列サブレイヤー３４６に、正確に信号を送ることのできる処理であることができる。
【００５２】
ブロック５０２においては、データサービスオプションの接続の次の各２０ミリ秒境界において、フレーム再配列サブレイヤー３４６は、ステップ５００において多重化サブレイヤー３４８によって与えられた、ＲＬＰ３Ｅフレームを受信する。そこで処理はブロック５１０に移動する。ブロック５１０に示したように、ブランチが、アクティブな補足チャンネルの数をもとに作成される。
【００５３】
もしも、アクティブな補足の数が０であれば、そこで処理はブロック５２０に移動する。ブロック５２０においては、受信されたすべてのフレームはすぐに、ＲＬＰ３Ｅレイヤー３４４に進められる。いかなるアクティブな補足チャンネルもないコールの場合、すべてのフレームはそれらが送信されたと同じ順序で受信されるからである。処理はそこで、ブロック５００に移動する。そこでは、処理は次の２０ミリ秒間隔の最後に、再び始まるであろう。
【００５４】
もしも、アクティブな補足の数が１であれば、そこで処理はブロック５３０に移動する。ブロック５３０においては、フレーム再配列サブレイヤー３４６は、図６を参照して記述された単一補足方法に従って、フレームを処理する。
【００５５】
もしも、アクティブな補足の数が２であれば、そこで処理はブロック５４０に移動する。ブロック５４０においては、フレーム再配列サブレイヤー３４６は、図５を参照して記述されたデュアル補足方法に従って、フレームを処理する。
【００５６】
図６は、本発明の単一補足チャンネル方法の典型的実施例を説明しているフローチャートである。ブロック６００において、ＭＯＤＥの値がチェックされる。
【００５７】
この時点においてＭＯＤＥが順方向に等しければ、補足チャンネル１に対するチャンネルオフセットは、なお到達されるべきである。このことは、基地局３１０がまだ、いずれかのフレームを補足チャンネル１上に送信すべきであることを示している。したがってこの時刻期間中、すべてのフレームはそれらが送信された順序で受信されなければならないために、すべての受信されたフレームは、ＲＬＰ３Ｅレイヤーに進められなければならない。もしも、図９Ａにおいて点９１０で示されたようにタイマーが終了していれば、基地局３１０は、補足１にフレーム送信を開始しかけていることを示している。このような点においては、モードはバッファーに切り替えられ、そしてタイマーは補足１のフレーム期間にリセットされる。図９Ａにおいて点９２０で示されているように、タイマーは次には時刻１４０において終了する。
【００５８】
もしも、ブロック６００において、ＭＯＤＥが順方向に等しければ、そこで、すべてのフレームはブロック６１０においてＲＬＰ３Ｅレイヤー３４４に進められる。処理はそこで、ＳＵＰ＿ＴＩＭＥＲ［１］が終了しているかどうかをチェックされる制御ブロック６２０に移動する。もしもタイマーが終了していなければ、そこで処理はブロック５００に移動する。そうでなければ、もしもタイマーが終了していれば、そこで処理はブロック６３０に移動する。ブロック６３０においては、モードは順方向からバッファーに変更される。処理はそこで、 ＳＵＰ＿ＴＩＭＥＲ［１］が補足チャンネルフレーム期間ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］にセットされるところの、ブロック６４０に移動する。処理はそこで、ブロック５００に移動する。
【００５９】
もしも、ブロック６００においてＭＯＤＥが順方向に等しくなければ、そこでフレームはタイマーが終了するまでバッファーされる。このことは、受信されたフレームが、不必要なＮＡＫｓが発生することで、ＲＬＰ３Ｅレイヤー３４４に配送されることを防止する。タイマーが終了するとき、図９の点９２０および９３０で示されたように、バッファーされたフレームのすべてはいかなる不必要なＮＡＫＳをも発生させることなしにＲＬＰ３Ｅレイヤー３４４に配送されることができる。たとえば、点９２０において、３から７のＲＬＰシーケンス番号を含むＣＤＭＡフレームは、すべて受信されている。これらは連続したシーケンス番号であるために、ＮＡＫＳは不必要には発生されないであろう。その上、点９２０においてタイマーが終了した後、次の２０ミリ秒境界にある点９１５において、ＲＬＰシーケンス番号４を含むフレームは、不必要なＮＡＫを発生させることなしに進めることができる。しかし、もしそのフレームが、点９１５と９２０の間の時刻に配送されてしまっていれば、そこでフレームＲＬＰフレーム４のために、ＮＡＫが不必要に発生されているであろう。一度フレームが配送されれば、補足チャンネル上で次のフレームが受信されるであろうときを示すためにリセットされる。
【００６０】
さらに、一つの実施例においては、フラッグ、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫがチェックされる。このような実施例においては、もし基本ＲＬＰ３Ｅフレームがステップ５０２において受信されていたならば、そしてＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫの値がＴＲＵＥであれば、そこで基本ＲＬＰ３ＥフレームはＲＬＰ３Ｅレイヤー３４４に配送され、バッファーはされない。このような実施例においては、 ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫは、もしタイマーＳＵＰ＿ＴＩＭＥＲ［１］がこの間隔期間中に終了していれば、そこでＴＲＵＥにセットされ、そうでなければＦＡＬＳＥにセットされる。もしもブロック６００においてＭＯＤＥが順方向に等しくなければ、処理はブロック６６０に移動する。そこでは、タイマーＳＵＰ＿ＴＩＭＥＲ［１］が終了しているかどうかがチェックされる。もしＳＵＰ＿ＴＩＭＥＲ［１］が終了していなければ、そこで処理は、受信されたフレームがメモリーバッファーにおかれるところの、ブロック６７０に移動する。
【００６１】
代わりの実施例においては、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫの値がチェックされる。もしＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫがＦＡＬＳＥにセットされていれば、そこで受信されたフレームはメモリーバッファーにおかれる。しかし、もしも変数ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫがＴＲＵＥの値を有していれば、そして基本ＲＬＰ３Ｅフレームがこの２０ミリ秒間隔の期間中に受信されていれば、そこでそのフレームはＲＬＰ３Ｅレイヤー３４４に進められ、一方いずれかの受信された補足フレームはバッファーされ、そしてＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫはＦＡＬＳＥにリセットされる。そこで処理はブロック６７０からブロック５００に移動する。
【００６２】
もしブロック６６０において、ＳＵＰ＿ＴＩＭＥＲ［１］が終了していると決定されれば、そこで処理はブロック６８０に移動する。ブロック６８０においては、すべてのフレームはメモリーバッファーから取り外され、ＲＬＰ３Ｅレイヤー３４４に進められる。さらに、ブロック６８０においては、ステップ５０２において、現在の２０ミリ秒間隔の間に受信されたフレームも、ＲＬＰ３Ｅレイヤー３４４に進められる。代わりの実施例においては、変数ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫの値はＴＲＵＥにセットされる。処理はそこで、ブロック６４０に移動し、そこでＳＵＰ＿ＴＩＭＥＲ［１］は補足チャンネルＣＤＭＡフレーム期間ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］にセットされる。処理はそこでブロック５００に移動する。
【００６３】
図１１は、図６で述べたオペレーションの望ましい実施形態を示している。図１１を参照して、もしもブロック１６００においてＭＯＤＥが順方向に等しければ、そこで、多重化サブレイヤー３４８から受信されたすべてのフレームは、ブロック１６１０においてＲＬＰ３Ｅレイヤー３４４に進められる。処理はそこで制御ブロック１６２０に移動し、そこではＳＵＰ＿ＴＩＭＥＲ［１］が終了しているかがチェックされる。もしもタイマーが終了していなければ、そこで処理はブロック５００に移動する。そうでなければ、もしタイマーが終了していれば、そこで処理はブロック１６３０に移動する。ブロック１６３０においては、モードは順方向からバッファーに変更される。さらに、この望ましい実施形態においては、変数Ｔ＿ＤＥＬＩＶＥＲは、現在の時刻基準プラス２０ミリ秒の値にセットされる。これは、次の期間中に受信された基本フレームが、ＲＬＰ３Ｅレイヤー３４４に進められるべきことを示すのに用いられるであろう。処理はそこで、ブロック１６４０に移動し、そこでＳＵＰ＿ＴＩＭＥＲ［１］は、補足チャンネルフレーム期間ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］にセットされる。処理はそこでブロック５００に移動する。
【００６４】
もしもブロック１６００において、ＭＯＤＥが順方向に等しくなければ、そこでフレームはタイマーが終了するまでバッファーされる。タイマーが終了した後のみ、すべてのバッファーされたフレームは、次の２０ミリ秒境界において受信されたフレームと同様に、ＲＬＰ３Ｅレイヤー３４４に進められる。このことは、受信されたフレームが、不必要なＮＡＫｓが発生することによって、ＲＬＰ３Ｅレイヤー３４４に配送されることを防止する。タイマーが終了するとき、図９の点９２０および９３０に示したように、バッファーされたフレームのすべては、いかなる不必要なＮＡＫＳをも発生することなしに、ＲＬＰ３Ｅレイヤー３４４に、配送されることができる。たとえば、点９２０において、ＲＬＰシーケンス番号３から７を含むＣＤＭＡフレームは、すべて受信されてしまっている。これらは連続したシーケンス番号であるために、ＮＡＫＳは不必要には発生されないであろう。その上、タイマーが点９２０で終了した後、次の２０ミリ秒境界にある点９１５において、ＲＬＰシーケンス番号４を含むフレームは、不必要なＮＡＫを発生することなしに進められることができる。しかし、もしも点９１５および９２０の間の時刻において、フレームが配送されてしまっていたときば、そこで、フレームＲＬＰフレーム４のために、ＮＡＫが不必要に発生されてしまうであろう。一度フレームが配送されれば、タイマーは補足チャンネル上で次のフレームが受信されるであろうときを示すためにリセットされる。
【００６５】
もしもブロック１６００においてＭＯＤＥが順方向に等しくなければ、そこでフレームはタイマーが終了するまでバッファーされる。タイマーが終了した後のみ、次の２０ミリ秒境界において受信されたフレームと同様に、すべてのバッファーされたフレームは、ＲＬＰ３Ｅレイヤー３４４に進められる。このことは、受信されたフレームが、不必要なＮＡＫｓが発生されて、ＲＬＰ３Ｅレイヤー３４４に配送されることを防止する。図９の点９２０および９３０で説明したように、タイマーが終了するとき、すべてのバッファーされたフレームは、いかなる不必要なＮＡＫＳをも発生することなしに、ＲＬＰ３Ｅレイヤー３４４に配送されることができる。たとえば、点９２０においてＲＬＰシーケンス番号３から７を含むＣＤＭＡフレームは、すべて受信されてしまっている。これらは連続したシーケンス番号であるので、ＮＡＫＳは不必要に発生されることはないであろう。その上、点９２０においてタイマーが終了した後、次の２０ミリ秒境界にある点である、点９１５において、ＲＬＰシーケンス番号４を含むフレームは不必要なＮＡＫを発生することなしに進められることができる。しかし、もしも点９１５と９２０の間の時刻にフレームが配送されてしまったときは、そこでフレームＲＬＰフレーム４のために、ＮＡＫが不必要に発生されているであろう。一度フレームが配送されれば、補足チャンネルで次のフレームが受信されるであろうときを表示するために、タイマーはリセットされる。
【００６６】
もしもブロック１６００において、ＭＯＤＥが順方向に等しくなければ、処理はブロック１６６０に移動する。ブロック１６６０においては、ＳＵＰ＿ＴＩＭＥＲ［１］が終了してしまっているかどうかが決定される。もしＳＵＰ＿ＴＩＭＥＲ［１］が終了してしまっていれば、処理はブロック１６６２に移動する。ブロック１６６２においては、変数Ｔ＿ＤＥＬＩＶＥＲは現在の時刻基準プラス２０ミリ秒の値にセットされる。そこで処理はブロック１６６４に移動する。そしてそこで、 ＳＵＰ＿ＴＩＭＥＲ［１］は補足チャンネルフレーム期間ＳＵＰ＿ＤＵＲＡＴＩＯＮ［１］にセットされる。処理はそこでブロック１６７０に移動する。
【００６７】
ブロック１６６０において、もしもＳＵＰ＿ＴＩＭＥＲ［１］が終了していないと決定されれば、処理はブロック１６７０に移動する。
【００６８】
ブロック１６７０においては、現在の時刻基準の値がＴ＿ＤＥＬＩＶＥＲの値よりも大きいかどうかが決定される。もしも現在の時刻基準の値がＴ＿ＤＥＬＩＶＥＲの値よりも大きければ、そこで処理はブロック１６７５に移動する。そこで、受信されたフレームはメモリーエリアにバッファーされる。処理はそこでブロック５００に移動する。
【００６９】
もしも、ブロック１６７０において現在の時刻基準がＴ＿ＤＥＬＩＶＥＲの値よりも大きくないと決定されれば、そこで処理はブロック１６８０に移動する。ブロック１６８０においては、すべてのフレームはメモリーバッファーから取り外され、現在の期間中多重化サブレイヤー３４８から受信されたフレームとともに、ＲＬＰ３Ｅレーヤー３４４に進められる。そこで処理はブロック５００に移動する。
【００７０】
図７は本発明の、デュアル補足チャンネル方法の典型的実施例を説明しているフローチャートである。制御ブロック７００において、ＭＯＤＥの値がチェックされる。
【００７１】
もしもＭＯＤＥが順方向に等しくなければ、さきに図８を参照して述べられたと同様に、そこでＭＯＤＥはバッファーに等しいとされ、処理はブロック７８０に移動する。もしも逆にＭＯＤＥが順方向に等しければ、そこで処理はブロック７１０に移動する。
【００７２】
ブロック７１０において、もしもＭＯＤＥが順方向に等しければ、補足チャンネル１に対するチャンネルオフセットはまだ到達されていない。これは基地局３１０はまだ補足チャンネル１に、いずれのフレームをも送信すべきであることを示している。このような場合、すべてのフレームはそれらが送信された順序で受信されなければならないので、すべての受信されたフレームは直ちにＲＬＰ３Ｅレイヤーに進められる。どちらか一方あるいは両方のタイマーが終了するとき、基地局３１０は、終了している各タイマーと組み合わせられた補足チャンネルにフレーム送信を開始しかけている。一例として、図９Ｂの点９６０において補足チャンネル１と組み合わせられたタイマーは、基地局３１０が補足チャンネル１にフレーム送信を開始しかけていることを示して終了する。
【００７３】
ＭＯＤＥが順方向に等しく、一つあるいはそれ以上のチャンネルタイマーが終了するときはつねに、ＭＯＤＥはバッファーに切り替えられる。この場合、それぞれの終了したタイマーはそこで、これと組み合わせられた補足チャンネルの期間にセットされる。フレームが、終了したタイマーと組み合わせられた補足チャンネルへの送信を開始した時刻を表示するために、カウンタは初期化される。そして終了したタイマーと組み合わせられた補足チャンネルに送信された相対的シーケンス番号を追跡するために、カウンターは初期化される。‘相対的なシーケンス番号’という言葉は、受信しているエンティティがそれぞれのチャンネルに送信された実際のシーケンス番号の絶対的な数値を追跡する必要のないことを示すために使用される。むしろ、実状を把握するということは、それぞれの補足チャンネル上に送信された最終のフレームにカプセル収納された、ＲＬＰシーケンス番号の関係を追跡することのみを必要とする。とくに、実状を把握するということは、一つの補足チャンネルに送信されているＲＬＰ３Ｅフレームのシーケンス番号が、他の補足チャンネルに送信されているＲＬＰ３Ｅフレームのシーケンス番号よりも、小さいかあるいは大きいか、どちらかを追跡することが必要である。代わりの実施例においては、変数Ｔ＿ＤＥＬＩＶＥＲは、現在の時刻基準プラス２０ミリ秒の値にセットされる。これは、代わりの実施例において、次の間隔において受信された基本ＲＬＰ３ＥフレームがＲＬＰ３Ｅレイヤー３４４に進められるべきであることを示すために使用されるであろう。
【００７４】
一つのタイマーだけが終了したときは、補足フレームのみが、そのタイマーと組み合わせられたチャンネルへの送信を開始していることが記録される。もし両方のタイマーが終了すれば、前に説明したように、二つのフレームが同時に送信されるときには、より短い期間をもった補足チャンネルが、より低いシーケンス番号を割り当てられる。この場合、より長い期間をもった補足に発生されているフレームの中にカプセル収納されているシーケンス番号は、他の補足チャンネルに発生されているフレームにカプセル収納されているＲＬＰシーケンス番号よりも相対的に大きい数値であることが記録される。
【００７５】
上記の一つの例として、図９Ｂの点９６０において、モードは順方向からバッファーに切り替わり、補足チャンネル１と組み合わせられたタイマーは８０ミリ秒にセットされるであろう。さらに、現在の時刻においてフレームは補足チャンネル１に送信されかけており、なお補足２に送信されるべきフレームはないという事実を追跡するために初期化される。
【００７６】
ブロック７１０においては、すべてのフレームはバッファーから取り外され、ＲＬＰ３Ｅレイヤー３４４に進められる。処理はそこでブロック７２０に移動する。そこでは、いずれかのタイマーＳＵＰ＿ＴＩＭＥＲ［１］あるいはＳＵＰ＿ＴＩＭＥＲ［２］が終了しているかどうかが決定される。もしもいずれのタイマーも終了していなければ、そこで処理はブロック５００に移動する。タイマーの一つだけが終了したときには、処理はブロック７３０からブロック７５０に移動する。ブロック７５０においては、 ＳＵＰ＿ＴＩＭＥＲ［１］あるいはＳＵＰ＿ＴＩＭＥＲ［２］が終了したかどうかが決定される。もしもＳＵＰ＿ＴＩＭＥＲ［１］が終了していると決定されれば、インデックス変数Ｅは１にセットされ、インデックス変数Ｎは２にセットされる。そうでなければ、Ｅは２にセットされ、Ｎは１にセットされる。Ｅは、タイマーが終了しているチャンネルと組み合わせられた、タイマー、期間、および最終の送信時刻に対する参照として使用される。Ｎは、タイマーがまだ終了していないチャンネルと組み合わせられた、最終の送信時刻に対する参照として使用される。そこで処理はブロック７６０に移動する。
【００７７】
ブロック７６０においては、ブロック７５０で決定されたＥおよびＮインデックスを利用して、単一のタイマーおよび複数の変数がセットされる。変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｅ］は、第一の補足フレームが補足チャンネルＥに送信されたことを示して、１に等しいとセットされる。変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］は、最大の許容可能な補足チャンネルオフセットのときに、基本チャンネルに送信されることが可能な、フレームの最大数よりも１だけ大きい値に、等しいとしてセットされる。典型的実施例においては、最大の許容可能な補足チャンネルのオフセットは６０ミリ秒であり、そして基本フレーム期間は２０ミリ秒である。そこで、典型的実施例においては、 ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］は、４（１＋（６０／２０））にセットされる。このことは、 ＳＵＰ＿ＴＩＭＥＲ［Ｎ］の終了に先立って補足Ｅで受信されたいかなるフレームも直ちにＲＬＰ３Ｅレイヤー３４４に配送されることを許容する。代わりの実施例においては、 ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］あるいは他のフラッグは、補足チャンネルＮがなお何らかのフレームの送信を開始しなければならないことを示すために、負の１あるいはＮＵＬＬなどの、指定された値にセットされることが可能である。望ましい実施形態においては、 ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］は、補足チャンネルＮが、なお何らかのフレーム送信を開始しなければならないことを示すために、−１（負の１）にセットされる。そしてまた、変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｅ］は、補足Ｅに現在のフレーム送信が開始された時刻に対する時刻基準を示すために、１に等しいとセットされる。望ましい実施形態においては、変数Ｔ＿ＤＥＬＩＶＥＲは、次の間隔において受信される基本ＲＬＰ３Ｅフレームが、ＲＬＰ３Ｅレイヤーに進められるべきことを示している、現在の時刻基準プラス２０ミリ秒の値に等しいとセットされる。
【００７８】
ブロック７６０においては、タイマーＳＵＰ＿ＴＩＭＥＲ［Ｅ］は、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｅ］にセットされる。したがって、ＳＵＰ＿ＴＩＭＥＲ［Ｅ］は、補足Ｅに送信されているフレームの送信が終了すると、すぐに終了するであろう。
【００７９】
処理はそこでブロック７６０からブロック７７０に移動する。ブロック７７０においては、モードは、順方向からバッファーに切り替えられ、その後、処理はブロック５００に移動する。ブロック７３０においては、もしも両タイマーが終了していると決定されれば、処理はブロック７４０に移動する。ブロック７４０においては、複数の変数およびタイマーは、基地局３１０によってフレームが送信されつつあるとき、トラックにセットされる。ブロック７４０においては、ブロック４１０において決定されたＳおよびＬインデックスを利用して、変数がセットされる。
【００８０】
ブロック７４０の典型的実施例においては、変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｓ］は、より小さいシーケンス番号をもったＲＬＰ３Ｅフレームが、補足チャンネルＳに送信されかけていることを示している、１に等しいとセットされる。変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｌ］は、より大きい番号をもったＲＬＰ３Ｅフレームが、補足チャンネルＬに送信されかけていることを示している、２に等しいとセットされる。補足Ｌに送信されたフレームは、補足Ｓへのフレームとして同時に送信されるけれども、本発明の方法は、大きいＲＬＰシーケンス番号をもったフレームが、より小さいシーケンス番号をもったフレームに先立って、ＲＬＰ３Ｅレイヤー３４４に配送されることを防止するために、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｓ］がＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｌ］よりも低い番号にセットされることを要求している。このことは、図３を参照して論じられたＲＬＰ３Ｅレイヤー送信に関してなされた要求と一致している。
【００８１】
変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｓ］は、補助Ｓに現在のフレーム送信が開始された時刻に関する、現在の時刻基準に等しくセットされる。そして変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｌ］は、補助Ｌに現在のフレーム送信が開始された時刻に関する時刻基準を表示するために現在の時刻基準に等しくセットされる。代わりの実施例においては、変数Ｔ＿ＤＥＬＩＶＥＲは、次の間隔において受信される基本ＲＬＰ３Ｅフレームが、ＲＬＰ３Ｅレイヤー３４４に進められるべきことを示している、現在の時刻基準プラス２０ミリ秒の値に等しくセットされる。
【００８２】
ブロック７４０の典型的実施例においては、タイマーＳＵＰ＿ＴＩＭＥＲ［Ｓ］は、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｓ］にセットされ、そしてタイマーＳＵＰ＿ＴＩＭＥＲ［Ｌ］はＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｌ］にセットされる。したがって、タイマーＳＵＰ＿ＴＩＭＥＲ［Ｓ］は、補足Ｓに送信されているフレームの送信が終了すると、すぐに終了するであろう。さらに、タイマーＳＵＰ＿ＴＩＭＥＲ［Ｌ］は、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｌ］にセットされる。したがって、ＳＵＰ＿ＴＩＭＥＲ［Ｌ］は、補足Ｌに送信されているフレームの送信が終了すると、すぐに終了するであろう。
【００８３】
処理は前に述べた、ブロック７７０に移動し、その後、処理はブロック５００に移動する。
【００８４】
ブロック７００において、もしもＭＯＤＥが順方向に等しくないと決定されれば、そこで処理は、図８に示されているブロック７８０に移動する。
【００８５】
図８は、本発明のデュアルチャンネルバッファード方法の、典型的実施例を示しているフローチャートである。
【００８６】
ブロック８１０においては、ＭＯＤＥはバッファーに等しい。ＭＯＤＥがバッファーに等しいときすべてのフレームは、いずれかのタイマーが終了するまでバッファーされる。
【００８７】
もしもいずれのタイマーも終了しなければ、受信された基本フレームが、与えられた期間中に配送されうるかどうかを示すために、フラッグ、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫを使用している代わりの実施例、例外がそれに応じて作成される。この代わりの実施例においては、もしも与えられた期間中どのタイマーも終了していなければ、そしてＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫがｔｒｕｅにセットされていれば、受信された基本はすぐにＲＬＰ３Ｅレイヤー３４４に進められる。この代わりの実施例においては、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫはいずれのタイマーも終了していないそれぞれの期間中、ｆａｌｓｅにセットされる。
【００８８】
望ましい実施形態においては、タイマーが終了していない期間中、Ｔ＿ＤＥＬＩＶＥＲの値は現在の時刻基準と比較される。この場合もしも現在の時刻基準の値がＴ＿ＤＥＬＩＶＥＲよりも大きくなければ、そこでもしも基本ＲＬＰ３Ｅフレームが受信されていれば、フレームはすぐにＲＬＰ３Ｅレイヤー３４４に配送される。
【００８９】
タイマーが終了するときは必ず、どのフレームがバッファーから取り外され、そしてＲＬＰ３Ｅレイヤー３４４に進められるべきかが決定される。タイマーが終了するまでフレームをバッファーリングすることは、不必要なＮＡＫｓが発生されて、受信されたフレームがＲＬＰ３Ｅレイヤー３４４に配送されることを防止する。たとえば、図９Ｂの点９７０において、フレーム０、１、および３は受信されてしまった。もしもこれらがバッファーされてしまっていなかったときは、ＲＬＰ３Ｅレイヤー３４４は、フレーム２のためにＮＡＫを発生しているであろう。異なった単一補足方法５３０は、デュアルチャンネルバッファード方法において、単一タイマーが終了するときは選択されたフレームのみが、不必要なＮＡＫｓの発生の原因となることなしにＲＬＰ３Ｅレイヤー３４４に進められることができる。たとえば、図９Ｂの点９８０において、補足チャンネル１と組み合わせられたタイマーは終了する。この点で受信されたフレームは、シーケンス番号０、１、３、４、６および２を含んでいる。したがって、５よりも小さいシーケンス番号を有するすべてのフレームは、ＲＬＰ３Ｅレイヤー３４４に進むことが望ましいにもかかわらず、フレーム６をＲＬＰ３Ｅレイヤー３４４に進めることは、フレーム５に対する不必要なＮＡＫの発生の原因となるであろうことから望ましくない。本発明の方法は、望まれる、そして望まれるフレームのみをＲＬＰ３Ｅレイヤー３４４に進めることに成功している。
【００９０】
デュアルチャンネルバッファード方法においては、一つあるいは両方のタイマーが同時に終了したかどうかが決定される。図９Ｂの点９７０、９８０、そして９８５で示したように、そして、図１０の、点１０２０、１０３０、そして１０４０で示されているように、他のタイマーが終了するときに、もし一つのタイマーがなお動いていれば、次の方法が用いられる。
【００９１】
第一に、各チャンネルに最終に送信されたフレームの、相対的シーケンス番号が比較される。
【００９２】
もしも、終了したタイマーと組み合わせられた補足チャンネルに、最終的に送信されたシーケンス番号が、他の補足チャンネルに最終的に送信されたシーケンス番号よりも大きければ、そこで受信されたフレームはバッファーされ、そして終了したタイマーは、これと組み合わせられた補足チャンネルのフレーム期間にセットされる。‘より大きい’なる言葉は、有限の組み合わせ内の値が、算術演算あるいはモジューロー算術演算など、予め決定された処理に従って、有限の組み合わせ内の他の値よりも大きいとみなされるという意味に、使用されることができる。たとえば、ＲＬＰ２仕様は、組み合わせ内のいずれの値が他に比して大きいかを決定するための手段として、符号なしのモジューロー２５６算術演算の使用を記載している。当業界の熟練した人には知られているように、変数を、より大きい、よりも小さい、あるいはお互いに等しいとセットするための、そしてある方法を用いて二つの変数の値を比較するための、複数の手段がある。本発明の望ましい実施形態においては、カウンタ（時刻基準カウンタも含めで）および相対的シーケンス番号のセッティングおよび比較は、符号なしのモジューロー２５６算術演算を使用して行われる。代わりの実施例においては、カウントおよび相対的シーケンス番号のセッティングおよび比較は、符号なしのモジューロー８算術演算によってなされる。
【００９３】
図１０の点１０３０において、両補足タイマーが同時に終了している、デュアルバッファード方法の一例として、フレーム４および５は両方バッファーされるであろう。第二の例として、点１０４０において、フレーム６および７は両方バッファーされるであろう。
【００９４】
しかしながら、もしも終了したタイマーと組み合わせられた補足チャンネルに、最終的に送信されたシーケンス番号が、他の補足チャンネルに最終的に送信されたシーケンス番号よりも小さいと決定され、あるいは他のフレームが、他の補足チャンネルに送信を開始していないと決定されれば、そこで次の方法が用いられる。補足チャンネルで受信されたフレームは、他の補足チャンネルに対して開始された最終フレームの送信の後２０ミリ秒において、あるいはそれ以前に受信された、すべてのバッファーされたフレームとともに、ＲＬＰ３Ｅレイヤー３４４に進められる。もしも現在の時刻が、最終のフレーム送信が他の補足チャンネルに対して開始された２０ミリ秒後よりも大きくなければそこで、受信された現在の基本フレームもまたＲＬＰ３Ｅレイヤー３４４に進められ、そうでなければ、現在の基本フレームはバッファーされる。
【００９５】
上記方法の一例として、図９Ｂの点９８０において、時刻８０（６０＋２０）以前あるいはその時刻に受信されたフレームは、ＲＬＰ３Ｅレイヤーに進められるであろう。同様に点９８５において、時刻１２０（１００＋２０）以前あるいはその時刻に受信されたフレームは、ＲＬＰ３Ｅレイヤーに進められるであろう。さらに、終了したタイマーは、これと組み合わせられた補足チャンネルのフレーム期間にセットされ、そしてフレームが、終了したタイマーと組み合わせられたチャンネルに送信を開始しかけていること、そしてこの補足に送信を開始しかけているフレームは、他の補足チャンネルにすでに送信を開始したフレームより大きいＲＬＰシーケンス番号を有するであろうことが記録される。
【００９６】
図９Ｂの点９９０に示されたように、もしも両タイマーが同時に終了したと決定されれば、そこですべての受信されたフレームおよび、すべてのバッファーされたフレームは、ＲＬＰ３Ｅレイヤー３４４に進められる。たとえば、図９Ｂの点９９０において、すべての受信されたそしてバッファーされたフレームは、ＲＬＰ３Ｅレイヤーに進められる。さらに、それぞれの終了したタイマーは、これと組み合わせられた補足チャンネルの、フレーム期間にセットされる。補足により長い期間をもって発生されているフレームに、カプセル収納されたシーケンス番号は、他の補足チャンネルに発生されているフレームに、カプセル収納されたＲＬＰシーケンス番号よりも、相対的に大きい値であることが記録される。さらに、一つの実施例においては、フラッグ、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫは、次の２０ミリ秒境界で受信される基本ＲＬＰ３Ｅフレームが、ＲＬＰ３Ｅレイヤー３４４に進められるべきであることを示している、ＴＲＵＥにセットされる。代わりの実施例においては、変数Ｔ＿ＤＥＬＩＶＥＲは、次の間隔で受信される基本ＲＬＰ３Ｅフレームが、ＲＬＰ３Ｅレイヤー３４４に進められるべきであることを示している、現在の時刻基準プラス２０ミリ秒の値に等しくセットされる。両補足が同じフレーム期間を有することを保証されているシステムにおいては、まさに一つのタイマーが終了したときに他の補足に送信中のフレームは、まさに受信された補足フレームに含まれているより大きい、ＲＬＰシーケンス番号を含むであろう。したがって、両補足が同じフレーム期間を有しているシステムにおいては、デュアルバッファード方法は次の代わりの実施例に単純化されることが可能である。厳密に一つのタイマーが終了するそれぞれの時刻に、最終のフレーム送信が他の補足に対して開始された２０ミリ秒後に、あるいはその前に受信されたすべてのフレームは、ＲＬＰ３Ｅレイヤーに進められる。
【００９７】
ブロック８１０においては、どちらかのタイマーが終了しているかどうかが決定される。もしいずれのタイマーも終了していなければ、処理はブロック８３０に移動する。ブロック８３０においては、多重化サブレイヤー３４８から受信されたすべてのフレームはメモリの中にバッファーされ、現在の時刻基準の値と、バッファーメモリの中で組み合わせられる。さらに、代わりの実施例においては、フラッグ、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫがチェックされる。この実施例においては、もしも基本ＲＬＰ３Ｅフレームがステップ５０２で受信されたときは、そしてＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫの値がＴＲＵＥであれば、そこで基本的ＲＬＰ３Ｅフレームは、ＲＬＰ３Ｅレイヤー３４４に配送され、バッファーされない。この実施例においては、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫは、そこでＦＡＬＳＥの値にセットされる。処理はそこでブロック５００に移動する。
【００９８】
ブロック８１０において、もしもタイマーの何れか一つが終了していれば、そこで処理はブロック８４０に移動し、そこで両タイマーが終了しているかどうかがチェックされる。もしも両タイマーが終了していれば、そこで処理はブロック８５０に移動する。ブロック８５０において、複数の変数およびタイマーは、基地局３１０によってフレームが送信されつつあるときは、トラックにセットされる。
【００９９】
ブロック８５０においては、変数は次のようにセットされる。もっとも長い期間を有している補足チャンネルと組み合わせられたシーケンス番号は、より短い期間を有している補足チャンネルと組み合わせられたシーケンス番号よりもより大きいことを示して、変数、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｓ］は１に等しいとセットされ、そして変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｌ］は、２に等しいとセットされる。変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｓ］およびＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｌ］は、現在のフレーム送信が二つの補足チャンネルに開始されたときの時刻基準を示して、ともに現在の時刻基準の値にセットされる。さらに、タイマー、ＳＵＰ＿ＴＩＭＥＲ［Ｓ］は、ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｓ］にセットされ、そしてタイマー、ＳＵＰ＿ＴＩＭＥＲ［Ｌ］は、ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｌ］にセットされる。したがって、タイマー、ＳＵＰ＿ＴＩＭＥＲ［Ｓ］は、補足Ｓに送信されつつあるフレームの送信が終了すると、直ちに終了するであろう。そしてタイマー、ＳＵＰ＿ＴＩＭＥＲ［Ｌ］は、補足Ｌに送信されつつあるフレームの送信が終了すると、直ちに終了するであろう。代わりの実施例においては、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫの値は、ＴＲＵＥにセットされる。処理はそこでブロック８６０に移動する。
【０１００】
ブロック８６０においては、バッファーされたすべてのフレームは、現在の２０ミリ秒期間中に受信されたフレームとともに、ＲＬＰ３Ｅレーヤー３４４に進められ（そしてバッファーから取り外され）る。処理はそこでブロック５００に移動する。ブロック８４０において、もしも一つのタイマーだけが終了したと決定されれば、処理はブロック８７０に移動する。ブロック８７０においては、ＳＵＰ＿ＴＩＭＥＲ［１］あるいはＳＵＰ＿ＴＩＭＥＲ［２］が終了したかどうかが決定される。もしもＳＵＰ＿ＴＩＭＥＲ［１］が終了したと決定されれば、そこでＥは１にセットされ、そしてＮは２にセットされる。そうでなければ、Ｅは２にセットされ、そしてＮは１にセットされる。したがって、インデックスＥはタイマーが終了したチャンネルと組み合わせられ、一方Ｎはタイマーが終了していなかったチャンネルと組み合わせられる。
【０１０１】
ブロック８８０においては、変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｅ］における値が、変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］における値よりも大きいかどうかがチェックされる。もしもＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｅ］における値が、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］よりも大きいか、あるいはＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］の値がＮＯ＿ＳＵＰＳ＿ＴＸＤにセットされていれば、補足で受信されたフレームは、他の補足で送信中のフレームよりもより大きいＲＬＰシーケンス番号を含むことを示している。この場合、処理はブロック８８２に移動する。ブロック８８２においては、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｅ］は、丁度終了したタイマーと組み合わせられたチャンネルに、新しいフレームが送信されかけていることを示すために、現在の時刻基準の値にセットされる。さらに、タイマー、ＳＵＰ＿ＴＩＭＥＲ［Ｅ］は、ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｅ］にセットされる。したがって、ＳＵＰ＿ＴＩＭＥＲ［Ｅ］は、次のフレームの送信が終了すると直ちに終了するであろう。処理はそこでブロック８８４に移動する。ブロック８８４においては、多重化サブレイヤー３４８から受信されたすべてのフレームは、メモリーエリアにバッファーされ、そしてバッファーメモリ内において、現在の時刻基準の値と組み合わせられる。この規則に対する一つの例外が、受信された基本フレームが、与えられた期間中に配送されうるかどうかを示すためのフラッグ、ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫを使用している実施例において生じる。この場合、もしもＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫが、ＴＲＵＥにセットされているような場合、補足フレームはバッファーされるが、基本ＲＬＰ３Ｅフレームは直ちにＲＬＰ３Ｅレイヤー３４４に配送される。ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫは、ＦＡＬＳＥにリセットされる。処理はそこでブロック５００に移動する。
【０１０２】
もしもブロック８８０において、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｅ］における値がＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］よりも大きくないと決定されれば、補足で受信されたフレームは、他の補足で送信中のフレームよりも、より低いＲＬＰシーケンス番号を含むことを示している。このような場合、処理はブロック８９２に移動する。ブロック８９２において、もしも基本フレームがこの間隔中に受信されたならば、基本フレームはバッファーされる。代わりの実施例においては、もしも現在の時刻基準の値がＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｎ］＋２０ミリ秒よりも大きければ、基本フレームのみがバッファーされ、したがって、フレームをバッファリングするステップを、すぐにフレームを取り外し、それを進めるだけに省略する。処理はブロック８９２からブロック８９４に移動する。ブロック８９４においては、現在送信中の補足フレームが送信を開始した２０ミリ秒後の時刻を表わしている、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｎ］＋２０ミリ秒の時刻値において、あるいはそれに先立って受信された、すべてのバッファーされたフレームは、バッファーから取り外され、丁度受信された補足フレームとともに、ＲＬＰ３Ｅレイヤー３４４に進められる。変数ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫを利用している実施例においては、変数ＦＵＮＤ＿ＤＥＬＩＶＥＲＹ＿ＯＫ は、ＦＡＬＳＥにリセットされる。処理はそこでブロック８９６に移動する。
【０１０３】
ブロック８９６においては、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｅ］は、補足に送信しかけているフレームは、すでに他の補足に送信中のフレームに含まれるよりも大きいＲＬＰシーケンス番号を含むであろうことを示している、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］よりも大きな値にセットされる。ＳＵＰ＿ＦＲＡＭＥ＿ＴＸ＿ＴＩＭＥ［Ｅ］は、新しいフレームが、丁度終了したタイマーと組み合わせられたチャンネルに、送信されかけていることを示すために、現在の時刻基準の値、典型的実施例におけるシステム時刻にセットされる。さらに、タイマー、ＳＵＰ＿ＴＩＭＥＲ［Ｅ］は、ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｅ］にセットされる。したがって、ＳＵＰ＿ＴＩＭＥＲ［Ｅ］は、次のフレームの送信が終了すると直ちに終了するであろう。処理はそこでブロック５００に移動する。
【０１０４】
図１２は、図８に述べられたオペレーションの、望ましい実施形態を示している。図１２を参照して、ブロック１８１０においては、ＭＯＤＥはバッファーに等しい。 Ｔ＿ＤＥＬＩＶＥＲに保存されていた値よりも大きい時刻に到来したすべてのフレームをバッファーし、そしてＴ＿ＤＥＬＩＶＥＲに保存されていた値よりも少ない時刻に到着した、すべてのフレームを配送することが望まれる。
【０１０５】
タイマーが終了したときはつねに、どのフレームがバッファーから取り外され、そしてＲＬＰ３Ｅレイヤー３４４に送られるべきかが決定される。タイマーが終了するまでフレームをバッファーすることは、不必要なＮＡＫｓが発生されて、受信されたフレームがＲＬＰ３Ｅレイヤー３４４に配送されることを防止する。たとえば、図９Ｂの点９７０においては、フレーム０、１、そして３が受信されていた。もしもこれらがバッファーされていなければ、ＲＬＰ３Ｅレイヤー３４４はフレーム２のためにＮＡＫを発生しているであろう。異なった単一補足方法５３０は、デュアルチャンネルバッファード方法において単一のタイマーが終了するとき、ＮＡＫｓの不必要な発生を引き起こすことなしに、選択されたフレームのみがＲＬＰ３Ｅレイヤー３４４に進められることができる。たとえば、図９Ｂの点９８０においては、補足チャンネル１と組み合わせられたタイマーは終了する。この点で受信されたフレームは、シーケンス番号０、１、３、４、６、および２を含んでいる。したがって、５よりも小さいシーケンス番号をもっているすべてのフレームを、ＲＬＰ３Ｅレイヤー３４４に進めることは望ましいが、フレーム６をＲＬＰ３Ｅレイヤー３４４に進めることは、これがフレーム５のための不必要なＮＡＫの発生の原因となるであろうことから望ましくない。本発明の方法は、望まれる、そして望まれるフレームのみをＲＬＰ３Ｅレーヤー３４４に送ることに成功している。
【０１０６】
デュアルチャンネルバッファード方法において、一つあるいは両方のチャンネルが、同時に終了したかどうかが決定される。他が終了するときに、もしも一つのタイマーがなお動いていれば、図９Ｂの点９７０、９８０、および９８５で示したように、そして、図１０の点１０２０、１０３０、および１０４０に示されるように、次の方法が用いられる。
【０１０７】
第一に、各チャンネルに最終的に送信されたフレームの相対的シーケンス番号が比較される。
【０１０８】
もしも、終了したタイマーと組み合わせられた補足チャンネルに、最終的に送信されたシーケンス番号が、他の補足チャンネルに最終的に送信されたシーケンス番号よりも、大きいと決定されれば、そこで、受信されたフレームはバッファーされ、そして終了したタイマーは、これと組み合わせられた補足チャンネルの、フレーム期間にセットされる。望ましい実施形態において、セッティングおよび、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤと組み合わせられた値の比較は、符号なしのモジューロ８算術演算を通して行われる。
【０１０９】
両補足タイマーが同時に終了するときの、デュアルバッファード方法の一例としては、図１０の点１０３０において、フレーム４および５は両方ともバッファーされるであろう。第二の例としては、点１０４０においてフレーム６および７は両方ともバッファーされるであろう。
【０１１０】
しかしながら、もしも終了したタイマーと組み合わせられた補足チャンネルに最終的に送信されたシーケンス番号が、他の補足チャンネルに最終的に送信されたシーケンス番号よりも小さいと決定され、あるいは、他の補足チャンネルへの、他のフレームの送信が開始されていないと決定されれば、そこで、次の方法が用いられる。補足チャンネルで受信されたフレームは、他の補足チャンネルに最終のフレーム送信が開始された後２０ミリ秒において、あるいはそれ以前に受信された、すべてのバッファーされたフレームとともに、ＲＬＰ３Ｅレイヤー３４４に進められる。もしも現在の時刻が、他の補足チャンネルに最終フレームの送信が開始された後、２０ミリ秒よりも大きくなければ、そこで、受信された現在の基本フレームはまたＲＬＰ３Ｅレイヤー３４４に進められ、そうでなければ、現在の基本フレームはバッファーされる。
【０１１１】
上記の方法の一例として、図９Ｂの点９８０において、時刻８０（６０＋２０）以前あるいはこのときに受信されたフレームは、ＲＬＰ３Ｅレイヤーに進められるであろう。同様に、点９８５において、時刻１２０（１００＋２０）以前あるいはこのときに受信されたフレームは、ＲＬＰ３Ｅレイヤーに進められるであろう。さらに、終了したタイマーは、これと組み合わせられた補足チャンネルのフレーム期間にセットされる。そして、終了したタイマーと組み合わせられたチャンネルに、フレームがまさに送信を開始しかけていること、この補足に送信を開始しかけているフレームは、他の補足チャンネルにすでに送信を開始したフレームよりも、大きいＲＬＰシーケンス番号を含むであろうことが記録される。
【０１１２】
図９Ｂの点９９０に示したように、もしも両タイマーが同時に終了したと決定されれば、そこですべての受信されたフレーム、およびすべてのバッファーされたフレームは、ＲＬＰ３Ｅレイヤー３４４に進められる。たとえば、図９Ｂの点９９０において、すべての受信されそしてバッファーされたフレームは、ＲＬＰ３Ｅレイヤーに進められる。さらに、それぞれの終了したタイマーは、それと組み合わせられた補足チャンネルのフレーム期間にセットされる。より長い期間をもって補足に発生されているフレームに、カプセル収納されたシーケンス番号は、他の補足チャンネルに発生されているフレームに、カプセル収納されたＲＬＰシーケンス番号よりも相対的に大きい値であることが記録される。望ましい実施形態においては、変数、Ｔ＿ＤＥＬＩＶＥＲは、次の間隔において受信された基本ＲＬＰ３Ｅフレームが、ＲＬＰ３Ｅレイヤー３４４に進められるべきであることを示して、現在の時刻基準プラス２０ミリ秒の値に等しくセットされる。
【０１１３】
両補足が同じフレーム期間を有していることが保証されているシステムにおいては、厳密に一つのタイマーが終了したときに、他の補足に送信されているフレームは、丁度受信された補足フレームに含まれるよりも大きい、ＲＬＰシーケンス番号を含んでいるであろう。したがって、両補足が同じフレーム期間を有しているシステムにおいては、デュアルバッファード方法は、次の代わりの実施例に単純化されることができる。厳密に一つのタイマーが終了したそれぞれの時刻に、他の補足に最終のフレーム送信が開始された後２０ミリ秒において、あるいはそれ以前に受信された、すべてのフレームはＲＬＰ３Ｅレイヤーに進められる。
【０１１４】
ブロック１８１０において、何れかのタイマー、ＳＵＰ＿ＴＩＭＥＲ［１］あるいはＳＵＰ＿ＴＩＭＥＲ［２］が、終了しているかどうかが決定される。もしも何れのタイマーも終了していなければ、処理はブロック１８１４に移動する。ブロック１８１４においては、現在の時刻基準がＴ＿ＤＥＬＩＶＥＲよりも大きいかどうかが決定される。もしも現在の時刻基準がＴ＿ＤＥＬＩＶＥＲの値よりも大きければ、処理はブロック１８３０に移動する。ブロック１８３０においては、この期間中に受信された基本フレームはメモリの中にバッファーされ、そして現在の時刻基準の値と、バッファーメモリの中で組み合わせられる。処理はそこでブロック５００に移動する。
【０１１５】
ブロック１８１４において、もしも現在の時刻基準が、Ｔ＿ＤＥＬＩＶＥＲの値よりも小さいか等しいと決定されれば、そこで処理はブロック１８１８に移動する。ブロック１８１８においては、この期間中に受信された基本フレームは、ＲＬＰ３Ｅレイヤー３４４に進められる。処理はそこでブロック５００に移動する。
【０１１６】
ブロック１８１０において、タイマーの何れか一方が終了していれば、そこで処理はブロック１８４０に移動する。そこで、両タイマーが終了したかどうかが決定される。もしも両タイマーが終了していれば、そこで処理は１８５０に移動する。ブロック１８５０においては、複数の変数およびタイマーは、フレームが基地局３１０によって送信されつつあるときは、トラックにセットされる。
【０１１７】
ブロック１８５０においては、変数は次のようにセットされる。もっとも長い期間を有している補足チャンネルと組み合わせられたシーケンス番号は、より短い期間を有する補足チャンネルと組み合わせられたシーケンス番号よりも大きいことを表して、変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｓ〕は、１に等しくセットされ、そして変数ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｌ〕は、２に等しくセットされる。変数Ｔ＿ＤＥＬＩＶＥＲは、時刻Ｔ＿ＤＥＬＩＶＥＲ以前に到着するすべてのフレームが、ＲＬＰ３Ｅレイヤー３４４に進められるべきであることを示している、現在の時刻基準プラス２０ミリ秒の値にセットされる。さらにタイマー、ＳＵＰ＿ＴＩＭＥＲ〔Ｓ〕は、ＳＵＰ＿ＤＵＲＡＴＩＯＮ〔Ｓ〕にセットされ、そしてタイマー、ＳＵＰ＿ＴＩＭＥＲ〔Ｌ〕は、 ＳＵＰ＿ＤＵＲＡＴＩＯＮ〔Ｌ〕にセットされる。したがって、タイマー、ＳＵＰ＿ＴＩＭＥＲ〔Ｓ〕は、補足Ｓに送信されつつあるフレームの送信が終了すると、直ちに終了するであろう。そしてタイマー、ＳＵＰ＿ＴＩＭＥＲ〔Ｌ〕は、補足Ｌに送信されつつあるフレームの送信が終了すると、直ちに終了するであろう。処理はそこでブロック１８６０に移動する。
【０１１８】
ブロック１８６０においては、バッファーされたすべてのフレームは、現在の２０ミリ秒の期間中に多重化サブレーヤー３４８から受信されたフレームとともに、ＲＬＰ３Ｅレイヤー３４４に進められ（そしてバッファーから取り外され）る。処理はそこでブロック５００に移動する。
【０１１９】
ブロック１８４０において、もしも一つのタイマーだけが終了したと決定されれば、処理はブロック１８７０に移動する。ブロック１８７０においては、ＳＵＰ＿ＴＩＭＥＲ〔１〕あるいはＳＵＰ＿ＴＩＭＥＲ〔２〕が終了したかどうかが決定される。もしもＳＵＰ＿ＴＩＭＥＲ〔１〕が終了したと決定されれば、そこでＥは１にセットされ、Ｎは２にセットされる。そうでなければ、Ｅは２にセットされ、Ｎは１にセットされる。したがって、インデックスＥはタイマーが終了したチャンネルと組み合わせられ、一方Ｎはタイマーが終了しなかったチャンネルと組み合わせられる。処理はそこでブロック１８７２に移動する。
【０１２０】
ブロック１８７２において、もしもＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｎ〕が、補足チャンネルＮにデータが送信されていないことを示している、−１の値を有していると決定されれば、そこでＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｅ〕は０の値にセットされる。処理はそこでブロック１８８０に移動する。
【０１２１】
ブロック１８８０においては、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｎ〕における値が−１に等しくないかどうか、そしてＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｅ〕における値が、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｎ〕における値よりも大きいかどうかが決定される。もしも、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｎ〕における値が、フレームが補足チャンネルＮに送信を開始していることを示して−１に等しくなく、そして、チャンネルＥで受信されたフレームにおけるシーケンス番号が、チャンネルＮでなお受信されるべきフレームにおけるシーケンス番号よりも大きいことを示して、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｅ〕における値が、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｎ〕における値よりも大きければ、そこで、この期間中フレームはＲＬＰ３Ｅレイヤーに進められるべきでないことが決定され、そして処理は１８９２に移動する。ブロック１８９２においては、多重化サブレイヤー３４８から受信されたすべてのＲＬＰフレームは、メモリーエリアにバッファーされ、現在の時刻基準の値とバッファーメモリ内で組み合わせられる。
【０１２２】
ブロック１８８０において、もしもどのフレームも補足チャンネルＮに送信を開始してしまっていないことを示して、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｎ〕が−１に等しいか、あるいはまた、補足チャンネルＮで受信されたフレームが、補足チャンネルＥに現在送信されつつあるシーケンス番号よりも低い、シーケンス番号を有していることを示して、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｅ〕の値が、ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ〔Ｎ〕の値よりも小さいかの、何れかであることが決定されれば、そこで処理はブロック１８８２に移動し、そこで、特定のフレームがバッファーされ、そして特定のフレームがＲＬＰ３Ｅレイヤー３４４に進められる。
【０１２３】
ブロック１８８２において、もしも現在の時刻基準がＴ＿ＤＥＬＩＶＥＲよりも小さいか、あるいは等しければ、フレームのすべてはバッファーメモリから取り外され、そして現在の期間中に多重化サブレイヤー３４８から受信されたフレームとともに、ＲＬＰ３Ｅレイヤー３４４に進められる。ブロック１８８２において、もしも現在の時刻基準がＴ＿ＤＥＬＩＶＥＲよりも大きければ、この期間中に多重化サブレイヤー３４８から受信されたすべてのフレームは、メモリにバッファーされ、そして現在の時刻基準の値と、バッファーメモリ内において組み合わせられる。さらに、 Ｔ＿ＤＥＬＩＶＥＲより小さいか、あるいは等しい時刻と組み合わせられた、バッファーメモリに保存されたすべてのフレームは、バッファーメモリから取り外され、そしてＲＬＰ３Ｅレイヤー３４４に進められる。処理はそこでブロック１８９６に移動する。
【０１２４】
ブロック１８９６においては、タイマー、ＳＵＰ＿ＴＩＭＥＲ［Ｅ］は、ＳＵＰ＿ＤＵＲＡＴＩＯＮ［Ｅ］の値にセットされる。したがって、ＳＵＰ＿ＴＩＭＥＲ［Ｅ］は、補足Ｅに送信されつつあるフレームが送信終了すると、直ちに終了するであろう。さらに、Ｔ＿ＤＥＬＩＶＥＲは、 時刻Ｔ＿ＤＥＬＩＶＥＲに先立って到着したすべてのフレームは、ＲＬＰ３Ｅレイヤー３４４に進められるべきであることを示している、現在の時刻基準の値プラス２０ミリ秒にセットされる。最後に、 ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｅ］が （ＳＵＰ＿ＦＲＡＭＥ＿ＴＸＤ［Ｎ］＋１）モジューロー８の値にセットされる。処理はそこでブロック５００に移動する。
【０１２５】
図９Ａは、一つのアクティブな補足チャンネルが存在している、典型的なｃｄｍａ２０００類似システムの中に、種々のＲＬＰフレームが送信されているタイミングを説明している、タイムライン線図である。図９Ａは、基本チャンネル９０１および一つの補足チャンネル９０２を含む、ＲＬＰ３Ｅデータ送信システム９００における、そこに、ＲＬＰシーケンス番号０から１２を含むＣＤＭＡフレームが送信されている、２２０ミリ秒時間期間を説明している。補足チャンネル９０２は、８０ミリ秒のＣＤＭＡフレーム期間を有し、６０ミリ秒のチャンネルオフセットを有するように形成されている。
【０１２６】
示されているように、基本チャンネル９０１は、シーケンス番号が０、１、２、３、５、６、７、８、１０、および１２のＲＬＰ３Ｅフレームを含む、２０ミリ秒のＣＤＭＡフレームを送信する。補足チャンネル９０２は、シーケンス番号４および９の、ＲＬＰ３Ｅフレームを含む、８０ミリ秒のＣＤＭＡフレームを送信する。図９Ａに示したように、フレーム０は、時刻２０《０が正しいと思われる》で送信を開始し、時刻２０で、送信を終了する。
【０１２７】
６０ミリ秒の補足チャンネルオフセットを示している、点９１０において、基本チャンネル９０１は、フレーム２（ＲＬＰシーケンス番号２を含むフレーム）の送信を終了し、そしてフレーム３の送信を開始する。さらに、補足チャンネル９０２は、フレーム４の送信を開始する。
【０１２８】
点９１５において、基本チャンネル９０１は、フレーム３の送信を終了し、そしてフレーム５の送信を開始する。
【０１２９】
点９２０において、基本チャンネル９０１は、フレーム７の送信を終了し、そしてフレーム８の送信を開始する。さらに、補足チャンネル９０２は、フレーム４の送信を終了し、フレーム９の送信を開始する。
【０１３０】
点９３０において、基本チャンネル９０１はフレーム１２の送信を終了し、そして補足チャンネル９０２は、フレーム９の送信を終了する。
【０１３１】
図９Ｂは、二つのアクティブな補足チャンネルが存在する、典型的ｃｄｍａ２０００類似のシステムの中に、種々のＲＬＰフレームが送信されているタイミングを示している、タイムライン線図である。図９Ｂは、基本チャンネル９５１、第一の補足チャンネル９５２、そして第二の補足チャンネル９５３を含む、ＲＬＰ３Ｅデータ送信システム９５０における、ＲＬＰシーケンス番号０から１６を含む、ＣＤＭＡフレームが送信されている、２２０ミリ秒時間期間を示している。第一の補足９５２は、８０ミリ秒のＣＤＭＡフレーム期間を有し、そして２０ミリ秒のチャンネルオフセットを有するように形成されている。第二の補足９５３は、６０ミリ秒のＣＤＭＡフレーム期間を有し、そして６０ミリ秒のチャンネルオフセットを有するように形成されている。示されたように、基本チャンネル９５１は、シーケンス番号が０、１、３、４、６、７、９、１１、１２、１３、および１６の、ＲＬＰ３Ｅフレームを含む、２０ミリ秒のＣＤＭＡフレームを送信する。第一の補足９５２は、シーケンス番号２、８、および１４の、ＲＬＰ３Ｅフレームを含む、８０ミリ秒のＣＤＭＡフレームを送信する。第二の補足９５３は、シーケンス番号５、１０、および１５の、ＲＬＰ３Ｅフレームを含む、６０ミリ秒のＣＤＭＡフレームを送信する。図９Ａに示されたように、フレーム０は時刻０に送信を開始し、時刻２０に送信を終了する。
【０１３２】
２０ミリ秒の補足チャンネルオフセットを示している点９６０において、基本チャンネル９５１は、フレーム０（ＲＬＰシーケンス番号０を含むフレーム）の送信を終了し、フレーム１の送信を開始する。さらに、第一の補足９５２は、フレーム２の送信を開始する。
【０１３３】
６０ミリ秒の補足チャンネルオフセットを示している点９７０において、基本チャンネル９５１は、フレーム３の送信を終了し、フレーム４の送信を開始する。さらに、第二の補足９５３は、フレーム５の送信を開始する。
【０１３４】
点９８０において、基本チャンネル９５１は、フレーム６の送信を終了し、そしてフレーム７の送信を開始する。さらに、第一の補足９５２は、フレーム２の送信を終了し、そしてフレーム８の送信を開始する。
【０１３５】
点９８５において基本チャンネル９５１は、フレーム７の送信を終了し、そしてフレーム９の送信を開始する。さらに、第二の補足９５３は、フレーム５の送信を終了し、そしてフレームフレーム１０の送信を開始する。
【０１３６】
点９９０において、基本チャンネル９５１は、フレーム１２の送信を終了し、そしてフレーム１３の送信を開始する。さらに、第一の補足９５２は、フレーム８の送信を終了し、そしてフレーム１４の送信を開始する。最後に、第二の補足９５３は、フレーム１０の送信を終了し、そしてフレーム１５の送信を開始する。
【０１３７】
図１０は、二つのアクティブな補足チャンネルが存在する、典型的ｃｄｍａ２０００類似システムの中に、種々のＲＬＰフレームが送信される、代わりのタイミングを示している、タイムライン線図である。図１０は、ＲＬＰシーケンス番号０から９を含むＣＤＭＡフレームが、基本チャンネル１００１、第一の補足チャンネル１００２、および第二の補足チャンネル１００３を含む、ＲＬＰ３Ｅデータ送信システム１０００に送信されている、１００ミリ秒時間期間を説明している。第一の補足１００２は、８０ミリ秒のＣＤＭＡフレーム期間を有し、そして２０ミリ秒のチャンネルオフセットを有するように形成されている。第二の補足１００３は、２０ミリ秒のＣＤＭＡフレーム期間を有し、そして２０ミリ秒のチャンネルオフセットを有するように形成されている。示されているように、基本チャンネル１００１は、シーケンス番号０、１、４、６、および８の、ＲＬＰ３Ｅフレームを含む、２０ミリ秒のＣＤＭＡフレームを送信する。第一の補足１００１は、シーケンス番号３のＲＬＰ３Ｅフレームを含む、８０ミリ秒のＣＤＭＡフレームを送信する。第二の補足１００３は、シーケンス番号２、５、７、および９のＲＬＰ３Ｅフレームを含む、２０ミリ秒のＣＤＭＡフレームを送信する。
【０１３８】
２０ミリ秒の補足チャンネルオフセットを示している点１０１０において、基本チャンネル１００１は、フレーム０（ＲＬＰシーケンス番号０を含むフレーム）の送信を終了し、そしてフレーム１の送信を開始する。さらに、第一の補足１００２は、フレーム３の送信を開始し、そして第二の補足１００３は、フレーム２の送信を開始する。
【０１３９】
点１０２０において、基本チャンネル１００１は、フレーム１の送信を終了し、そしてフレーム４の送信を開始する。さらに、第二の補足１００３は、フレーム２の送信を終了し、そしてフレーム５の送信を開始する。
【０１４０】
点１０３０において、基本チャンネル１００１は、フレーム４の送信を終了し、そしてフレーム６の送信を開始する。さらに、第二の補足１００３は、フレーム５の送信を終了し、フレーム７の送信を開始する。
【０１４１】
点１０４０において、基本チャンネル１００１は、フレーム６の送信を終了し、そしてフレーム８の送信を開始する。さらに、第二の補足１００３は、フレーム７の送信を終了し、フレーム９の送信を開始する。
【０１４２】
点１０５０において、基本チャンネル１００１は、フレーム８の送信を終了し、第一の補足１００２は、フレーム２の送信を終了し、そして第二の補足１００３は、フレーム９の送信を終了する。
【０１４３】
望ましい実施形態に関するこれまでの記述は、当業界において熟練したいかなる人でも、本発明の作成あるいは使用を可能とする。これらの実施例の種々な変形、は、当業界において熟練した人には容易に明快になるであろうし、そしてこの中に定義された一般的原理は、独創的能力を使用することなしに、他の実施例に適用できるであろう。したがって、本発明は、この中に示した実施例に限定されることを意図したものではなく、ここに開示された原理と、新しい特徴に矛盾しない最も広い範囲に一致されるべきものである。
【図面の簡単な説明】
【図１】 図１Ａおよび１Ｂは、ｃｄｍａ２０００に類似した典型的なマルチチャンネルデータ回路網上に、送信されそして受信されたデータフレームの、時刻関係を説明しているタイムライン線図である。
【図２】 図２は、ｃｄｍａ２０００ＲＬＰ３Ｅ送信システムの、典型的実施例に関する機能的ブロック線図である。
【図３】 図３は、本発明の送信システムの、典型的実施例に関する、機能的ブロック線図である。
【図４】 図４は、本発明のコールセットアップフローの、典型的実施例に関する、高レベルフローチャートである。
【図５】 図５は、受信されたフレームを処理するための、本発明によって用いられた方法の、典型的実施例を説明している、高レベルフローチャートである。
【図６】 図６は、本発明の単一補足チャンネル方法の、典型的実施例を説明している、フローチャートである。
【図７】 図７は、本発明のデュアル補足チャンネル方法の、典型的実施例を説明している、フローチャートである。
【図８】 図８は、本発明のデュアルチャンネルバッファード方法の、典型的実施例を説明しているフローチャートである。
【図９】 図９Ａは、１個のアクティブ補足チャンネルがある、典型的なｃｄｍａ２０００類似システムにおいて、種々のＲＬＰフレームが送信されるタイミングを説明している、タイムライン線図である。
図９Ｂは、２個のアクティブ補足チャンネルがある、典型的なｃｄｍａ２０００類似システムにおいて、種々のＲＬＰフレームが送信されるタイミングを説明しているタイムライン線図である。
【図１０】 図１０は、２個のアクティブ補足チャンネルがある、典型的なｃｄｍａ２０００類似システムにおいて、種々のＲＬＰフレームが送信される、代わりのタイミングを説明している、タイムライン線図である。
【図１１】 図１１は、図６に記述された動作の、望ましい実施形態を説明している。
【図１２】 図１２は、図８に記述された動作の、望ましい実施形態を説明している。

Claims (9)

1. 無線リンクプロトコル・タイプ３のデータフレームを無線リンクプロトコル・タイプ３のサブレイヤー（３１４）に配送する方法であって、
   補足チャンネルの数を決定することと、
   異なるフレーム長さの無線リンクプロトコル・タイプ３のデータフレームを配列させるために各補足チャンネルためのカウンタおよび／またはタイマをセットすることと、
   受信された無線リンクプロトコル・タイプ３のデータフレームを、その中に含まれるシーケンスナンバーにしたがって配列することと、
   配列された無線リンクプロトコル・タイプ３のデータフレームを前記無線リンクプロトコル・タイプ３のソフトウエア・サブレイヤー（３１４）に配送することと
   を含む、方法。
2. 前記方法は、無線リンクプロトコル・タイプ３における不必要な否定応答を防止するために使用され、無線リンクプロトコル・タイプ３のデータフレームを配列するステップに先立ってさらに含まれる、
   第１の補足チャンネル上で、第１のフレーム長さを有する無線リンクプロトコル・タイプ３のフレームを受信することと、
   第２の補足チャンネル上で、前記第１のフレーム長さとは異なる、第２のフレーム長さを有する無線リンクプロトコル・タイプ３のフレームを受信することと、
   前記第１のフレーム長さを有するフレームと前記第２のフレーム長さを有するフレームとを、多重化サブレイヤーからフレーム再配列サブレイヤーに配送することのステップを含み、
   受信された無線リンクプロトコル・タイプ３のデータフレームを配列するステップは、
   現在のフレームの前に送信された全フレームが受信されるまで、フレーム再配列サブレイヤー（３１６）によって、前記フレームをバッファリングすることと、
   フレーム再配列サブレイヤー（３１６）によって、否定応答フレームが、非連続に受信されたフレームによって生成されないように、前記フレームが同等の装置（peer）から送信された順序を決定することと、
   タイマおよび／またはカウンタ手段によって、前記フレームが前記同等の装置（peer）から送信された順序に、前記フレーム再配列サブレイヤーによって、前記フレームを再配列することと
   のステップをさらに含む、請求項１の方法。
3. 無線リンクプロトコル・タイプ３のデータフレームを生成する方法であって、
   無線リンクプロトコル・タイプ３のサブレイヤー（３１４）において、多重化サブレイヤー（３１８）からデータフレームの要求を受信することと、
   前記無線リンクプロトコル・タイプ３のサブレイヤー（３１４）によって、複数の新データフレームを生成することであって、最小の新シーケンスナンバーは、最小のフレーム長さを有する前記新データフレームに置かれ、最大の新シーケンスナンバーは、最代のフレーム長さを有する前記新データフレームに置かれる、生成することと
   を含む方法。
4. 前記方法は、第１の補足チャンネルと第２の補足チャンネルを有する、無線通信システム（３６０）においてフレーム再配列に使用される方法であって、前記第２の補足チャンネルは、前記第１の補足チャンネルのフレーム長さとは異なるフレーム長さを有するように構成されている、前記方法は、
   否定応答フレームの送信を遅らせるために、前記第１の補足チャンネルと第２の補足チャンネルのタイマをセットすることを含み、
   前記受信された無線リンクプロトコル・タイプ３のデータフレームを配列する前記ステップは、
   その中に含まれる前記シーケンスナンバーにしたがって、受信データフレームを配列することと、
   否定応答が、非連続に受信されたデータフレームに対して送信されないように、前記タイマをリセットすることと
   のステップをさらに含む、請求項１の方法。
5. 無線リンクプロトコル・タイプ３のソフトウエア・サブレイヤーから無線リンクプロトコル・タイプ３のデータフレームの要求を生成するため、および、基地局（３１０）の前記無線リンクプロトコル・タイプ３のソフトウエア・サブレイヤー（３１４）からシーケンシャルにナンバーが付されたデータフレームを受信するための多重化ソフトウエア・サブレイヤー（３４８）と、
   シーケンスナンバーにしたがって、前記多重化ソフトウエア・レイヤー（３４８）から受信されたデータフレームを配列するため、および、移動局（３４０）の無線リンクプロトコル・タイプ３のソフトウエア・サブレイヤーへ前記配列されたフレームを配送するためのフレーム再配列ソフトウエア・サブレイヤー（３４６）と
   を備える移動局（３４０）
6. 前記フレーム再配列ソフトウエア・サブレイヤー（３４６）は、無線リンクプロトコル・タイプ３のフレーム再配列サブレイヤーであり、
   シーケンスナンバーを有し、異なるフレーム長さの無線リンクプロトコル・タイプ３のフレームをバッファリングするバッファと、
   前記シーケンスナンバーにしたがって、前記無線リンクプロトコル・タイプ３のフレームを配列するためのタイマーおよび／またはカウンターとを
   インプリメントするように適合されている、請求項４の移動局（３４０）。
7. 移動局（３４０）の無線リンクプロトコル・タイプ３のソフトウエア・サブレイヤー（３４４）からの無線リンクプロトコル・タイプ３のデータフレームの要求を生成するための、および、移動局（３４０）の前記無線リンクプロトコル・タイプ３のソフトウエア・サブレイヤー（３４４）からシーケンシャルにナンバーが付されたデータフレームを受信するための、多重化ソフトウエア・サブレイヤー（３１８）と、
   シーケンスナンバーにしたがって、前記多重化ソフトウエアレイヤー（３１８）から受信されたデータフレームを配列するための、および、前記基地局（３１０）の無線リンクプロトコル・タイプ３のソフトウエア・サブレイヤー（３１４）へ前記配列されたフレームを配送するための、フレーム再配列ソフトウエア・サブレイヤー（３１６）とを
   備える基地局（３１０）。
8. 前記フレーム再配列ソフトウエア・サブレイヤー（３１６）は、
   シーケンスナンバーを有し、異なるフレーム長さの無線リンクプロトコル・タイプ３のフレームをバッファリングするバッファと、
   前記シーケンスナンバーにしたがって、前記無線リンクプロトコル・タイプ３のフレームを配列するためのタイマーおよび／またはカウンターとを
   インプリメントするように適合されている無線リンクプロトコル・タイプ３のフレーム再配列サブレイヤーである、請求項７の基地局（３１０）。
9. 請求項１乃至４のいずれかにしたがって一つの方法を実行するのに適切な命令を含むコンピュータ可読媒体。

Images