JP4934666B2

JP4934666B2 - 無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法

Info

Publication number: JP4934666B2
Application number: JP2008509931A
Authority: JP
Inventors: ヨンデリー，; スンダクチョン，; ミュンチュルユン，
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2005-05-04
Filing date: 2006-05-02
Publication date: 2012-05-16
Anticipated expiration: 2026-05-02
Also published as: US8161341B2; BRPI0612473A2; WO2006118418A2; US20080294958A1; WO2006118418A3; AU2006241604A1; EP1878155A4; RU2419218C2; AU2006241604B2; RU2007144979A; EP1878155A2; EP1878155B1; JP2008541543A

Description

本発明は無線通信システムに係り、さらに詳しくは、無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法に関する。

図１は、ＵＭＴＳ（ユニバーサル移動通信システム）のネットワーク構造のブロック図である。

図１を参照すれば、ＵＭＴＳは、主として、ユーザー装置（以下、ＵＥと略す。）と、ＵＭＴＳターミナル・地上無線接続網（以下、ＵＴＲＡＮと略す。）及びコアネットワーク（以下、ＣＮと略す。）を備えている。

ＵＴＲＡＮは、少なくとも一つの無線ネットワークサブシステム（以下、ＲＮＳと略す。）を備えている。また、ＲＮＳは、一つの無線ネットワーク制御器（以下、ＲＮＣと略す。）と、このＲＮＣにより管理される少なくとも一つの基地局（以下、ノードＢと略す。）と、を備えている。さらに、１ノードＢには少なくとも１以上のセルが存在している。

図２は、ＵＭＴＳ無線プロトコルのアーキテクチャーを示す図である。

図２を参照すれば、無線プロトコル階層は、ＵＥとＵＴＲＡＮとの組として存在して、無線区間のデータ送信を司る。

以下、それぞれの無線プロトコル階層について述べる。

先ず、第１の階層としてのＰＨＹは、種々の無線送信技術を用いてデータを無線区間に送る。ＰＨＹ階層における無線区間の信頼性あるデータＰＨＹ階層は、送信チャンネルを介して上位階層となるＭＡＣ階層に接続される。また、送信チャンネルは、主としてチャンネルの共有有無に応じて専用送信チャンネルと共用送信チャンネルとに大別される。

第２の階層は、ＭＡＣ、ＲＬＣ、ＰＤＣＰ及びＢＭＣ階層を含んでいる。先ず、ＭＡＣ階層は、種々の論理チャンネルを種々の送信チャンネルにそれぞれマッピングさせ、さらに、種々の論理チャンネルを１本の送信チャンネルにマッピングさせるという論理チャンネル多重化の機能を行う。ＭＡＣ階層は、論理チャンネルを介して上位階層となるＲＬＣ階層に接続される。

さらに、論理チャンネルは、主として送られてくる情報の類型に応じて、制御平面の情報送信のための制御チャンネルと、ユーザー平面の情報送信のためのトラフィックチャンネルとに大別できる。

一方、ＭＡＣ階層は、細部的に管理される送信チャンネルの類型に応じて、ＭＡＣ−ｂサブ階層、ＭＡＣ−ｄサブ階層、ＭＡＣ−ｃ／ｓｈサブ階層及びＭＡＣ−ｅサブ階層に分けられる。

ＭＣＡ−ｂ階層は、システム情報の放送を司る送信チャンネルＢＣＨの管理を行う。ＭＡＣ−ｃ／ｓｈ階層は、ＦＡＣＨ（ｆｏｒｗａｒｄａｃｃｅｓｓｃｈａｎｎｅｌ）、ＤＳＣＨ（ｄｏｗｎｌｉｎｋｓｈａｒｅｄｃｈａｎｎｅｌ）などの他のＵＥと共有される共用送信チャンネルを管理する。ＭＡＣ−ｄサブ階層は、特定のＵＥに対する専用送信チャンネルＤＣＨ（ＤｅｄｉｃａｔｅｄＣｈａｎｎｅｌ）の管理を司る。ＭＡＣ−ｈｓサブ階層は、高速なデータ送信のために送信チャンネルＨＳ−ＤＳＣＨ（ＨｉｇｈＳｐｅｅｄＤｏｗｎｌｉｎｋＳｈａｒｅｄＣｈａｎｎｅｌ）を管理し、ダウンリンク及びアップリンク時における高速なデータ送信を支援する。また、ＭＡＣ−ｅサブ階層は、アップリンクデータの送信のための送信チャンネルＥ−ＤＣＨ（ＥｎｈａｎｃｅｄＤｅｄｉｃａｔｅｄＣｈａｎｎｅｌ）を管理する。

ＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）階層は、それぞれの無線ベアラーのＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）に対する保証及び対応するデータの送信を司る。ＲＬＣは、ＲＢの固有のＱｏＳを保証するために、それぞれのＲＢごとに一つの独立したＲＬＣエンティティを設けている。ＲＬＣは、種々のＱｏＳに対応するために、ＴＭ（ＴｒａｎｓｐａｒｅｎｔＭｏｄｅ）、ＵＭ（ＵｎａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）及びＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）などの３種類のＲＬＣモードを提供している。そして、ＲＬＣは、下位階層が無線区間にデータを送るのに適するようにデータサイズを調節する。このために、上位階層から受信したデータを分割及び接続する機能を行う。

ＰＤＣＰ階層はＲＬＣ階層の上位に位置し、ＩＰｖ４やＩＰｖ６などのＩＰパケットを用いて送られてくるデータを相対的に帯域幅の狭い無線区間において効率よく送る。このために、ＰＤＣＰ階層はヘッダーの圧縮機能を行うが、これは、データのヘッダー部への必須情報の送信を可能にして、無線区間の送信効率を高める。ヘッダー圧縮は、ＰＤＣＰ階層の基本的な機能であるため、ＰＤＣＰ階層はＰＳ（ＰａｃｋｅｔＳｅｒｖｉｃｅ）ドメインにのみ存在する。また、それぞれのＰＳサービスに対して効率よいヘッダー圧縮機能を提供するために、それぞれのＲＢにつき一つのＰＤＣＰエンティティが存在する。

第２の階層において、ＢＭＣ（Ｂｒｏａｄｃａｓｔ／ＭｕｌｔｉｃａｓｔＣｏｎｔｒｏｌ）階層がＲＬＣ階層の上位に存在する。ＢＭＣ階層はセル放送メッセージをスケジューリングし、特定のセルに位置しているＵＥに放送する機能を行う。

第３の階層の最下位に位置するＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）階層は、制御平面においてのみ定義される。ＲＲＣ階層は、ＲＢの設定、再構成及び解除と関連して、第１及び第２の階層のパラメータを制御し、論理チャンネル、送信チャンネル及び物理チャンネルの制御を司る。この場合に、ＲＢとは、ＵＥとＵＴＲＡＮとの間のデータ送信のための無線プロトコルの第１及び第２の階層により与えられる論理的なパスのことを言う。さらに、ＲＢ設定とは、特定のサービスを提供するために無線プロトコル階層及びチャンネルの特性を規定し、それぞれの具体的なパラメータ及び動作方法を設定するプロセスを意味する。

以下、ＲＬＣ階層を詳述する。

先ず、ＲＬＣ階層の基本機能は、各ＲＢのＱｏＳに対する保証とこれに対応するデータの送信である。ＲＢサービスは、無線プロトコルの第２の階層が上位階層に提供するサービスであるため、第２の階層の全体がＱｏＳに影響してしまう。また、ＲＬＣの影響が最も大きい。ＲＬＣは、ＲＢの固有のＱｏＳを保証するために、ＲＢごとに独立したＲＬＣエンティティを設けており、ＴＭ、ＵＭ及びＡＭの３種類のＲＬＣモードを提供している。これらの３種類のＲＬＣモードは、支援するＱｏＳが異なるため動作方法に違いがあり、その細部的な機能にも違いが出る。このため、ＲＬＣは、その動作モード別に分けて調べる必要がある。

ＴＭＲＬＣは、ＲＬＣＰＤＵ（ＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）を構成するとき、上位階層から受け取ったＲＬＣＳＤＵ（ＳｅｒｖｉｃｅＤａｔａＵｎｉｔ）にいかなるオーバーヘッドも付加されていないモードである。特に、ＲＬＣがＳＤＵを透明に通過させるため、ＴＭＲＬＣと呼ばれる。このような特性により、ＴＭＲＬＣは、ユーザー平面と制御平面において次のような役割を果たす。ユーザー平面においては、ＲＬＣ内におけるデータ処理時間が短いため、ＣＳ（ＣｉｒｃｕｉｔＳｅｒｖｉｃｅ）ドメインの音声やストリーミングなどのリアルタイムな回線データ送信を司る。一方、制御平面においては、ＲＬＣ内にオーバーヘッドがないため、アップリンクの場合に不特定のＵＥからのＲＲＣメッセージに対する送信を司り、ダウンリンクの場合にセル内の全てのＵＥから放送されるＲＲＣメッセージの送信を司る。

透明モードとは異なり、ＲＬＣにおいてオーバーヘッドが追加されるモードを非透明モードといい、このモードにおいては、送られてきたデータへの受信確認応答がないモード（ＵＭ）と、送られてきたデータへの受信確認応答があるモード（ＡＭ）とに大別される。ＵＭＲＬＣは各ＰＤＵごとにシーケンス番号（ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ；以下、ＳＮと略す。）を含むＰＤＵヘッダーを付加することにより、受信側にどのＰＤＵが送信中に失われたかを察知させる。

このような機能により、ＵＭＲＬＣは、主としてユーザー平面においては放送／マルチキャストデータの送信やＰＳドメインの音声（例えば、ＶｏＩＰ）またはストリーミングなどのリアルタイムなパケットデータの送信を行い、制御平面においてはセル内の特定のＵＥまたは特定のＵＥグループに送られるＲＲＣメッセージのうち受信確認応答が不要なＲＲＣメッセージの送信を行う。

非透明モードの一つであるＡＭＲＬＣは、ＵＭＲＬＣと同様、ＳＮを含むＰＤＵヘッダーを付加してＰＤＵを構成する。しかしながら、ＡＭＲＬＣは、ＵＭＲＬＣとは異なり、送信側が送ったＰＤＵに対して受信側が応答するという点で相違点がある。ＡＭＲＬＣにおいて受信側が応答をする理由は、受信側そのものが受信できなかったＰＤＵに対して送信側に再送信を要請することができるからである。また、このような再送信機能がＡＭＲＬＣの最も大きな特徴である。結局、ＡＭＲＬＣの目的は、再送信を通じてエラーのないデータ送信を保証することである。このような目的により、ＡＭＲＬＣは、主としてユーザー平面においてはＰＳドメインのＴＣＰ／ＩＰなどのリアルタイムではないパケットデータの送信を司り、制御平面においてはセル内の特定のＵＥに送られるＲＲＣメッセージのうち受信確認応答が必ず必要となるＲＲＣメッセージの送信を司る。

方向性の面からは、ＴＭまたはＵＭＲＬＣは単方向通信に使われるのに対し、ＡＭＲＬＣは受信側からのフィードバックがあるために両方向通信に使われる。両方向通信は、主として点対点通信において使われるため、ＡＭＲＬＣは専用の論理チャンネルのみを用いる。構造的な面からも次のような相違点がある。ＴＭまたはＵＭＲＬＣにおいては、一つのＲＬＣエンティティが送信または受信のいずれか一つの構造となっているが、ＡＭＲＬＣにおいては一つのＲＬＣエンティティ内に送信側と受信側が両方ともに存在する。

ＡＭＲＬＣの複雑性は、再送信機能による。ＡＭＲＬＣは、再送信の管理のために送受信バッファに加えて再送信バッファを設けており、流れの制御のための送受信ウィンドウの使用、送信側がピーアＲＬＣエンティティの受信側からのステータス情報を要求するポーリング、受信側がピーアＲＬＣエンティティの送信側に自分のバッファステータスを報告するステータス報告、ステータス情報を伝搬するためのステータスＰＤＵ、データ送信の効率を高めるためにデータＰＤＵ中にステータスＰＤＵを埋め込むピギーバック機能など種々の機能を行う。

一方、ＡＭＲＬＣエンティティが動作中に重大なエラーを見つけた場合、他方の側のＡＭＲＬＣエンティティに全ての動作及びパラメータの再設定を要求するリセットＰＤＵが存在する。また、リセットＰＤＵの応答に使われるリセットＡｃｋＰＤＵもある。これらの機能に対応するために、ＡＭＲＬＣには種々のプロトコルパラメータ、状態変数及びタイマーが必要となる。このようなステータス報告またはステータスＰＤＵ、リセットＰＤＵなどのようにＡＭＲＬＣにおいてデータ送信の制御のために使われるＰＤＵを制御ＰＤＵといい、ユーザーデータを送信するために使われるＰＤＵをデータＰＤＵと言う。

要するに、ＡＭＲＬＣにおいて用いるＰＤＵは、主として２種類に大別できる。一つはデータＰＤＵであり、もう一つは制御ＰＤＵである。また、制御ＰＤＵは、ステータスＰＤＵ、ピギーバックドステータスＰＤＵ、リセットＰＤＵ、リセットＡｃｋＰＤＵを含む。

コントロールＰＤＵを用いる場合の一つが、リセットの手続きである。リセットの手続きは、ＡＭＲＬＣの動作におけるエラー状況を解消するために使われる。エラー状況とは、例えば、使用するシーケンス番号が互いに異なる場合、または、ＰＤＵまたはＳＤＵが回数限界に達して送信に失敗する場合である。このリセットの手続きを用いると、受信側のＡＭＲＬＣと送信側のＡＭＲＬＣが環境変数を初期化した後、通信可能なステータスに入り直す。

以下、リセットの手続きについて説明する。

先ず、リセットの手続きを始めると決めた側、すなわち、送信側のＡＭＲＬＣは、リセットＰＤＵにおいて現在使われている送信方向ＨＦＮ（ＨｙｐｅｒＦｒａｍｅＮｕｍｂｅｒ）値を含めてこのリセットＰＤＵを受信側に送る。リセットＰＤＵを受信した受信側のＡＭＲＬＣは、自分の受信方向のＨＦＮ値を再設定した後、シーケンス番号などの環境変数をリセットする。続けて、受信側のＡＭＲＬＣは、自分の送信方向ＨＦＮをリセットＡｃｋＰＤＵに含めてこのリセットＡｃｋＰＤＵを送信側のＡＭＲＬＣに送る。送信側のＡＭＲＬＣは、リセットＡｃｋＰＤＵを受信すれば、自分の受信方向ＨＦＮ値を再設定した後、環境変数をリセットする。

以下、ＡＭＲＬＣエンティティにおいて使われるＲＬＣＰＤＵの構造を詳述する。

図３は、ＡＭＲＬＣＰＤＵの構造図である。

図３を参照すれば、ＡＭＲＬＣＰＤＵは、ＡＭＲＬＣエンティティがユーザーデータまたはピギーバックドステータス情報及びポーリングビットを送りたいときに使われる。ユーザーデータ部は８ビットの整数倍として構成され、ＡＭＲＬＣＰＤＵのヘッダーは２オクテットサイズのシーケンス番号により構成される。また、ＡＭＲＬＣＰＤＵのヘッダー部は長さ指示子（ＬＩ：ＬｅｎｇｔｈＩｎｄｉｃａｔｏｒ）を含む。

図４は、ステータスＰＤＵの構造図である。

図４を参照すれば、ステータスＰＤＵは、他の類型のＳＵＦＩ（ＳｕｐｅｒＦｉｅｌｄ）を含む。ステータスＰＤＵのサイズは可変的であるが、ステータスＰＤＵが送られる論理チャンネルの最も大きなＲＬＣＰＤＵのサイズに限られる。この場合に、ＳＵＦＩは、受信側にどの類型のＡＭＲＬＣＰＤＵが到達し、且つ、受信側にどの類型のＡＭＲＬＣＰＤＵが未到達であるかなどの情報を通知する。ＳＵＦＩは、類型、長さ及び値の３種類により構成される。

図５は、ピギーバックドステータスＰＤＵの構造図である。

図５を参照すれば、ピギーバックドステータスＰＤＵの構造は、ステータスＰＤＵの構造に類似しているが、Ｄ／Ｃフィールドが予約ビット（Ｒ２）に置き換えられている点で異なる。このピギーバックドステータスＰＤＵは、ＡＭＲＬＣＰＤＵに十分な空間が残っている場合に埋め込まれる。なお、ＰＤＵ種類値は常に「０００」に固定可能である。

図６は、リセットＡＣＫＰＤＵの構造図である。

図６を参照すれば、リセットＰＤＵは、１ビットのＲＳＮと名付けられたシーケンス番号を含む。また、リセットＡＣＫＰＤＵは、受信されたリセットＰＤＵに応答して、受信されたリセットＰＤＵに含まれているＲＳＮを含めて送られてくる。

以下、ＰＤＵフォーマットに使われるパラメータについて説明する。

先ず、「Ｄ／Ｃフィールド」の値は、当該ＰＤＵがコントロールＰＤＵであるか、データＰＤＵであるかを指示する。

「ＰＤＵ類型」は、コントロールＰＤＵの種類を指示する。特に、当該ＰＤＵがリセットＰＤＵであるか、ステータスＰＤＵであるかなどを指示する。

「シーケンス番号」値は、ＡＭＲＬＣＰＤＵのシーケンス番号情報を意味する。

一方、「ポーリングビット」値は、ステータス報告を受信側に要請するときに設定される。

「延長ビット（Ｅ）」値は、次のオクテットが長さ指示子（ＬＩ）であるかどうかを指示する。

「予約ビット（Ｒ１）」値は、リセットＰＤＵまたはリセットＡＣＫＰＤＵにおいて使われ、「０００」に符号化される。

「ヘッダー延長ビット（ＨＥ）」値は、後続するオクテットが長さ指示子（ＬＩ）であるか、データであるかを指示する。

「長さ指示子」値は、ＰＤＵのデータ部中に異なるＳＤＵ間の境界面が存在するとき、その境界面の位置を指示する。

「ＰＡＤ」部はパッディング領域であり、ＡＭＲＬＣＰＤＵにおいては使われない領域である。

以下、ＳＵＦＩ（ＳｕｐｅｒＦＩｅｌｄ）について説明する。

以上で簡単に述べたように、ＳＵＦＩは、受信側にいかなる種類のＡＭＲＬＣＰＤＵが到達し、受信側にいかなる種類のＡＭＲＬＣＰＤＵが未到達であるかなどの情報を送信側に指示する。現在は、８種類のＳＵＦＩが定義されて使われている。

それぞれのＳＵＦＩは、類型、長さ及び値により構成される。

また、ＮＯ＿ＭＯＲＥ（ＮｏＭｏｒｅＤａｔａ）、ＷＩＮＤＯＷ（ＷｉｎｄｏｗＳｉｚｅ）、ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）、ＬＩＳＴ（Ｌｉｓｔ）、ＢＩＴＭＡＰ（Ｂｉｔｍａｐ）、Ｒｌｉｓｔ（Ｒｅｌａｔｉｖｅｌｉｓｔ）、ＭＲＷ（ＭｏｖｅＲｅｃｅｉｖｉｎｇＷｉｎｄｏｗ）、ＭＲＷＡＣＫ（ＭｏｖｅＲｅｃｅｉｖｉｎｇＷｉｎｄｏｗＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）などをはじめとする種々の類型のＳＵＦＩがある。

以下、ＳＵＦＩ類型について詳述する。

（Ａ）ＮＯ＿ＭＯＲＥＳＵＦＩ
図７は、従来の技術によるＮＯ＿ＭＯＲＥＳＵＦＩフィールドの構造図である。

図７を参照すれば、ＮＯ＿ＭＯＲＥＳＵＦＩは、類型フィールドとしてのみ存在する。ＮＯ＿ＭＯＲＥＳＵＦＩは、ＮＯ＿ＭＯＲＥＳＵＦＩに後続してそれ以上のＳＵＦＩが存在しないことを指示する。このため、このＳＵＦＩ以降の領域はＰＡＤ（パッディング）領域と看做されうる。

（Ｂ）ＢＩＴＭＡＰＳＵＦＩ
図８は、従来の技術によるＢＩＴＭＡＰＳＵＦＩフィールドの構造図である。

図８を参照すれば、ＢＩＴＭＡＰＳＵＦＩは、類型、ビットマップ長さ（ＬＥＮＧＴ）、開始シーケンス番号（ＦＳＮ）及びビットマップにより構成される。

ＬＥＮＧＴＨは４ビットから構成され、（ＬＥＮＧＴＨ＋１）はビットマップのオクテットサイズを意味する。例えば、ＬＥＮＧＴＨ＝「００００」であれば、ビットマップオクテットサイズは１であることを意味する。ＬＥＮＧＴＨが「１１１１」までの値に設定可能であるため、ビットマップの最大のオクテットサイズは「１６」となる。

ＦＳＮは１２ビットから構成され、ビットマップの第１のビットに相当するシーケンス番号（ＳＮ）を意味する。

ビットマップは、ＬＥＮＧＴＨフィールドにより与えられる値に応じて可変する。［ＦＳＮ、ＦＳＮ＋（ＬＥＮＧＴＨ＋１）＊８−１］に相当する区間にシーケンス番号に相当するＡＭＲＬＣＰＤＵのステータス情報を報知することができる。順序は左側から右側に向かってシーケンス番号が増大し、ＡＭＲＬＣＰＤＵの受信ステータスは「０」（非正常受信：ＮＡＣＫ）または「１」（正常受信：ＡＣＫ）で表示される。

ＵＥにおいて、ＢＩＴＭＡＰＳＵＦＩが受信側に正確に受信されたと報告したＡＭＲＬＣＰＤＵを送信側により削除することができる。

（Ｃ）ＡＣＫＳＵＦＩ
図９は、従来の技術によるＡＣＫＳＵＦＩフィールドの構造図である。

図９を参照すれば、ＡＣＫＳＵＦＩは、種類及びＬＳＮ（ＬａｓｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ）により構成される。

ＡＣＫＳＵＦＩは、ＮＯ＿ＭＯＲＥＳＵＦＩなどのステータスＰＤＵにおいて、データ部の最後の部分であることを指示する。ＡＣＫＳＵＦＩがステータスＰＤＵの最後の部分に存在すれば、ＮＯ＿ＭＯＲＥＳＵＦＩが同時に存在する必要はない。換言すれば、ＮＯ＿ＭＯＲＥＳＵＦＩで終了されていないステータスＰＤＵにはＡＣＫＳＵＦＩが存在することが必要である。ＡＣＫＳＵＦＩ以降の部分はＰＡＤ（パッディング）として看做されうる。

ＡＣＫＳＵＦＩは、ステータスＰＤＵの前部においてそれぞれエラーとして報告されていないＳＮ＜ＬＳＮの全てのＡＭＲＬＣＰＤＵの受信に対して応答をする。換言すれば、ＬＳＮ＞ＶＲ（Ｒ）であれば、受信エラー状態であるＡＭＲＬＣＰＤＵに関する応答情報は、一つのステータスＰＤＵを用いて一つとして送信される必要がある。特に、受信エラー状態であるＡＭＲＬＣＰＤＵに関する応答情報は複数のステータスＰＤＵに分離されて送信されることはできない。もし、ＬＳＮ＝ＶＲ（Ｒ）であれば、受信エラー状態であるＡＭＲＬＣＰＤＵは複数のステータスＰＤＵに分離されて送信可能である。ＬＳＮ＜ＶＲ（Ｒ）である場合には使用できない。また、ＬＳＮの値はＶＲ（Ｈ）に等しいか小さな値に設定可能である。この場合、ＶＲ（Ｈ）は受信側が受信したＡＭＲＬＣＰＤＵのうち最も大きなＳＮ以降に到達するＡＭＲＬＣＰＤＵのＳＮである。特に、受信側が受信したＡＭＲＬＣＰＤＵのうち最も大きなＳＮであるｘを受信したならば、ＶＲ（Ｈ）は（ｘ＋１）となる。

ステータスＰＤＵを受信した送信側は、ＬＳＮとステータスＰＤＵに含まれている第１の受信エラー状態であるＡＭＲＬＣＰＤＵのＳＮとを比較して、ＶＴ（Ａ）の値を更新することができる。

もし、受信されたＬＳＮの値がステータスＰＤＵにおける第１の受信エラーに相当するＡＭＲＬＣＰＤＵのＳＮよりも小さいかそれに等しければ（ＬＳＮ≦ＳＴＡＴＵＳＰＤＵの第１のエラービットのＳＮ）、ＶＴ（Ａ）はＬＳＮ値に更新される。もし、受信されたＬＳＮ値がステータスＰＤＵにおける第１の受信エラーに相当するＡＭＲＬＣＰＤＵのＳＮよりも大きければ（ＬＳＮ＞ＳＴＡＴＵＳＰＤＵの第１のエラービットのＳＮ）、ＶＴ（Ａ）はステータスＰＤＵの第１の受信エラーに相当するＡＭＲＬＣＰＤＵのＳＮ値に更新される。

ＶＲ（Ｒ）は、受信側に順番に受信された最終的なＡＭＲＬＣＰＤＵに後続して受信されると予想されるＡＭＲＬＣＰＤＵのＳＮである。例えば、受信側が受信エラー無しにＮ番目のＡＭＲＬＣＰＤＵまでＡＭＲＬＣＰＵＤを受信したならば、ＶＲ（Ｒ）は（Ｎ＋１）である。また、ＶＴ（Ａ）は、受信側から送信側にＡＣＫ（正常受信応答）情報が順番に受信された最終的なＡＭＲＬＣＰＤＵに後続して受信されると予想されるＡＭＲＬＣＰＤＵのＳＮである。例えば、送信側が受信側からＭ番目までＡＭＲＬＣＰＤＵに関するＡＣＫ（正常受信応答）情報を受信したならば、ＶＴ（Ａ）は（Ｍ＋１）である。

従来の技術においては、送信側がステータス報告を受信した場合、ＡＣＫＳＵＦＩに含まれているＬＳＮ値に基づき送信ウィンドウの下位エッジが更新される。すなわち、従来の技術において、送信側のＡＭＲＬＣは、受信されたＬＳＮ値とステータス報告についてステータスＰＤＵまたはピギーバックドステータスＰＤＵにおいて受信エラーとして報告されたＡＭＲＬＣＰＤＵのシーケンス番号（ＳＮ）とを比較することにより、送信ウィンドウの下位エッジのＶＴ（Ａ）の値を更新すると仮定する。

しかしながら、従来の技術において、送信側は、受信側からＬＳＮ値を含むＡＣＫＳＵＦＩを受信するまで送信ウィンドウを更新することができない。ＡＣＫＳＵＦＩを含むピギーバックドステータスＰＤＵまたはステータスＰＤＵが正常に受信できなかった場合に、受信側がエラー無しにＡＭＲＬＣＰＤＵを受信した旨を認識するにも拘わらず、送信ウィンドウを更新することができない。これにより、受信側へのデータ送信を効率よく行うことができなくなる。

よって、本発明は、従来の技術の限界及び欠点に起因する１以上の問題点を実質的に除去する、無線通信システムにおける制御情報の送信方法及びこの方法を用いた送信ウィンドウの更新方法に関するものである。

本発明の目的は、無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法を提供することにより、送信側における送信効率を高められるところにある。

本発明の他の目的は、無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法を提供することにより、受信側がエラー無しにデータブロックを受信した旨の情報を取得すれば、送信側の送信ウィンドウを取得された情報に基づいて即座で更新可能にするところにある。

本発明のさらに他の目的は、無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法を提供することにより、送信側におけるデータブロックの送信レートを高めるところにある。

本発明のさらなる特徴及び利点は次の説明において詳述され、部分的には詳細な説明から明らかになり、または、本発明を行うことにより教示可能なものである。本発明の目的及び別の利点は添付図面に加えて、詳細な説明及び請求の範囲において特別に指摘された構造により実現されたり得られるであろう。

送信側が複数のデータブロックを受信側に送るとき、受信側は、受信された複数のデータブロックに関するステータス報告情報を送信側に送る。この場合に、ステータス報告情報は、それぞれのデータブロックに対して受信エラーが存在するかどうかを指示する受信確認情報を含む。好ましくは、ステータス報告情報は、受信側から送信側に送られてくる制御情報ブロックに含まれて送られる。受信側は、複数のデータブロックに関するステータス報告情報を少なくとも２つの制御情報ブロックに含めて送信側に送ることができる。送信側は、受信側から送られてきたステータス報告情報を用いて送信ウィンドウを更新する。

送信側が少なくとも２つの制御情報ブロックを介してステータス報告情報を受信する場合に、第１の制御情報ブロックに含まれているステータス報告情報から、エラーなしに受信側に受信されたデータブロックに関する情報（例えば、第１の受信エラーを有するデータブロックのシーケンス番号）を取得すれば、送信側は第２の制御情報ブロックを受信しなかった場合であっても、送信ウィンドウを更新する。

一方、第１のステータス報告情報及び第２のステータス報告情報が異なる制御情報ブロックにそれぞれ含まれている場合には、複数の制御情報ブロックのうち送信側に最初に受信された制御情報ブロックに含まれている第１のステータス報告情報は、受信側にエラーが発生してから最初に受信された第１のデータブロックに関する情報を含む。なお、第２のステータス報告情報は、送信側に最終的に送られてきた制御データブロックに含まれる。

一方、送信側は、送信側に受信された複数の制御データブロックのうち最初に受信された制御データブロックに含まれている第１のステータス報告情報から、受信エラーを有する第１のデータブロックに関する情報を取得する。最初に受信された制御データブロックを正常に受信するのに失敗した場合には、送信側は、受信された制御データブロックのうち最終的に受信された制御データブロックに含まれている第２のステータス報告情報から、受信エラーを有する第１のデータブロックに関する情報を取得する。

データブロックとは、特定のプロトコル階層において使われるユーザーデータを含むデータユニットを意味する。例えば、データブロックは、ＲＬＣ階層のＰＤＵ（ｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ）に対応する。制御情報ブロックとは、特定のプロトコル階層に使われた制御情報を含むデータユニットを意味する。例えば、制御情報ブロックは、ステータスＰＤＵ、ピギーバックドステータスＰＤＵなどに対応する。さらに、ステータス報告情報は、制御情報ブロックに含まれているステータス報告指示子である。例えば、ステータス報告情報は、ステータスＰＵＤまたはピギーバックドステータスＰＤＵに含まれている種々のＳＵＦＩ（ＳｕｐｅｒＦｉｅｌｄ）に対応する。

これら及び別の利点を達成するために、また、本発明の目的によって具体化されて広義で説明されるものであって、本発明による移動通信システムにおける送信ウィンドウの更新方法は、受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は受信側に送られてくる複数のデータブロックに関する受信確認情報を与える前記第１の制御情報ブロック受信ステップと、第２の制御情報ブロックに最後のステータス報告情報として位置する第２のステータス報告情報を含む前記第２の制御情報ブロック受信ステップと、前記第１のステータス報告情報にある受信確認情報を用いて送信ウィンドウを更新する更新ステップと、を含む。

好ましくは、第２のステータス報告情報は、受信側に受信された複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示するフィールドを含む。

好ましくは、送信ウィンドウの下位エッジは、第１のステータス報告情報にある受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号をもって更新される。

好ましくは、第１のステータス報告情報は、ビットマップ型スーパーフィールド（ＳＵＦＩ）である。

好ましくは、第２のステータス報告情報は、ＡＣＫ型スーパーフィールド（ＳＵＦＩ）である。

これら及び他の利点をさらに達成するために、また、本発明の目的に応じて、移動通信システムにおける送信ウィンドウの更新方法は、受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は受信側に送られてくる複数のデータブロックに関する受信確認情報を与える前記第１の制御情報ブロック受信ステップと、前記第１のステータス報告情報にある受信確認情報を用いて送信ウィンドウを更新する更新ステップと、を含む。

好ましくは、送信ウィンドウの下位エッジは、前記第１のステータス報告情報にある受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号をもって更新される。

これら及び別の利点をさらに達成するために、また、本発明の目的に応じて、制御情報ブロックを送信側に送り、前記送信側が送るデータブロックの上にステータス報告情報を与える方法は、第１のステータス報告情報を含む第１の制御情報ブロックを前記送信側に送るが、前記第１のステータス報告情報は前記送信側が送る複数のデータブロックに関する受信確認情報を与える第１の制御情報ブロック送信ステップと、第２の制御情報ブロックに最後のステータス報告情報として位置するが、受信ウィンドウの下位エッジに対応するシーケンス番号を指示するフィールドを備える第２のステータス報告情報を含む前記第２の制御情報ブロックを送るステップと、を含む。

これら及び他の利点をさらに達成するために、また、本発明の目的に応じて、移動通信システムにおいて送信ウィンドウを更新する送信機は、受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は前記受信側に送られてくる複数のデータブロックに関する受信確認情報を与える第１の制御情報ブロックを受信する手段と、第２の制御情報ブロックに最後のステータス報告情報として位置する第２のステータス報告情報を含む前記第２の制御情報ブロックを受信する手段と、前記第１のステータス報告情報にある前記受信確認情報を用いて送信ウィンドウを更新する手段と、を備える。

これら及び他の利点をさらに達成するために、また、本発明の目的に応じて、受信側に送られてくる複数のデータブロックに受信確認情報を与える制御情報ブロックに含まれているステータス報告指示子のデータ構造は、前記ステータス報告指示子の類型を指示する第１のフィールドと、前記受信側に送られてくる複数のデータブロックに前記受信確認情報を与える第２のフィールドと、前記受信側において使われる受信ウィンドウの下位エッジに等しいかそれよりも大きなシーケンス番号を指示する第３のフィールドと、を含む。

好ましくは、第３のフィールドは、受信側に受信される複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示する最後のシーケンス番号（ＬＳＮ）である。

上述した通常の説明及び後述する詳細な説明はいずれも例示的なものであり、説明のためのものであり、請求されるように、本発明のさらなる説明を提供しようとするためのものであることが理解できるであろう。

以下、添付図面に基づき、本発明の好適な実施形態について詳述する。

本発明の後述する実施形態において、本発明の技術的な特徴は、ＵＭＴＳに適用される。

図１０は、本発明の好適な一実施形態によるフローチャートである。

図１０を参照すれば、送信側は、複数のＲＬＣＰＤＵを受信側に送る（Ｓ１１）。送信側は、必要に応じて、受信側にステータス報告情報を要請することができる（Ｓ１２）。送信側からステータス報告情報要請を受信したり、必要に応じて、受信側は、ステータス報告に関するステータスＰＤＵまたはピギーバックドステータスＰＤＵを構成した後、構成されたこのＰＤＵを周期的にまたは非周期的に送信側に送る。

受信側は、送信側から送られてきた複数のＲＬＣＰＤＵに関するステータス報告のために少なくとも一つのステータスＰＤＵまたはピギーバックドステータスＰＤＵを構成し、構成された少なくとも一つのステータスＰＤＵまたはピギーバックドステータスＰＤＵを送信側に送る。図１０に示す実施形態において、受信側は、シーケンス番号（ＳＮ）０〜９９の受信状態について、２つのステータスＰＤＵまたは２つのピギーバックドステータスＰＤＵにより状態を報告する（Ｓ１３、Ｓ１５）。

図１１及び図１２は、本発明の好適な一実施形態により受信側から送信側にステータス報告のために送られてきた第１及び第２のステータスＰＤＵのデータフォーマットを示す図である。図１１及び図１２を参照すれば、ＢＩＴＭＡＰｘ１ＳＵＦＩ及びＢＩＴＭＡＰｘ２ＳＵＦＩは、ビットマップを構成することにより、ＳＮ：０〜ＳＮ：９９のＰＤＵに対して受信確認情報、すなわち、ＡＣＫ／ＮＡＣＫを報知することができる。

例えば、受信側において受信エラーの発生したＰＤＵがＳＮ：３０、ＳＮ：５０、ＳＮ：５５及びＳＮ：８０にそれぞれ対応するとすれば、第１の受信エラーに対応するＡＭＲＬＣＰＤＵのＳＮは３０であり、図１２に示す第２のステータスＰＤＵに含まれているＡＣＫＳＵＦＩのＬＳＮ値は「３０」であると定義できる。すなわち、ＡＣＫＳＵＦＩのＬＳＮ値はＶＲ（Ｒ）に設定されるわけではなく、第１の受信エラーに対応するＲＬＣＰＤＵのＳＮ値に設定される。

ＢＩＴＭＡＰｘ１は、ＳＮ：〜ＳＮ：ＫのＰＤＵに関するＡＣＫ／ＮＡＣＫ情報を含み、ＢＩＴＭＡＰｘ２は、ＳＮ：（Ｋ＋１）〜ＳＮ：９９のＰＤＵに関するＡＣＫ／ＮＡＣＫ情報を含む。

第１のステータスＰＤＵを受信する場合に（Ｓ１３）、送信側は、第１のステータスＰＤＵに含まれているＢＩＴＭＡＰｘ１からＳＮ：０〜ＳＮ：Ｋの範囲に属するＡＣＫ／ＮＡＣＫ情報を取得することができる。このため、送信側は、ＳＮ：３０のＰＤＵは第１の受信エラーに対応する旨を認識することができる。これにより、送信側は、他のステータスＰＤＵの受信を待つことなく、送信ウィンドウを直ちに更新する（Ｓ１４）。

すなわち、送信側が以前に受信したステータス報告後に第１の受信エラーに対応するＳＮ：３０のＰＤＵまでＰＤＵが順番に正常に受信されるという旨を認知する場合に、送信側は、通信ウィンドウの下位エッジ、すなわち、ＶＴ（Ａ）を更新することができる。この例において、第１の受信エラーに対応するＳＮが３０であるため、ＶＴ（Ａ）は３０に更新される。また、第１の受信エラーに対応するＳＮは、受信側が設定したＬＳＮ値と同値である。

送信側が第２のステータスＰＤＵを受信すれば（Ｓ１５）、送信側はＡＣＫＳＵＦＩに含まれているＬＳＮ値を確認することができる。あるいは、第２のステータスＰＤＵに含まれていないＡＣＫＳＵＦＩを有していてもよい。

少なくとも３つのステータスＰＤＵから構成されたステータス報告において第１のステータスＰＤＵなどが失われている場合には、送信側がＡＣＫ／ＮＡＣＫ情報を順次に受信しなかったことを意味する。このため、第２のステータスＰＤＵが正常に受信されたとしても、ＶＴ（Ａ）は第２のステータスＰＤＵの第１のエラーに対応するＳＮ値に更新されない。この場合に、ＶＴ（Ａ）は、最終的なステータスＰＤＵを受信することにより、ＡＣＫＳＵＦＩに含まれているＬＳＮ値をもって更新されることが必要である。

ＢＩＴＭＡＰｘ１は、受信側において第１の受信エラーに対応するＲＬＣＰＤＵのＳＮを用いてＳＵＦＩが構成される旨を知らせるために、従来のＢＩＴＭＡＰＳＵＦＩとは差別化可能である。すなわち、上記の用途を有する新規な類型のＳＵＦＩが構成可能である。例えば、ＬＳＮがＢＩＴＭＡＰｘ１に含まれうる。これについては後述する。

従来の技術において、ＡＣＫ／ＮＡＣＫ情報を指示するＳＵＦＩ（例えば、ＢＩＴＭＡＰ、ＬＩＳＴ、ＲＬＩＳＴＳＵＦＩなど）が同じまたは異なるステータスＰＤＵを介してＡＣＫＳＵＦＩと共に送信される必要がある。この場合に、ＡＣＫＳＵＦＩの代わりにＬＳＮ値を有するＳＵＦＩ（例えば、ＢＩＴＭＡＰ、ＬＩＳＴ、ＲＬＩＳＴＳＵＦＩなど）と関連するＡＣＫ／ＮＡＣＫの新規な類型を考慮する場合、ＡＣＫＳＵＦＩを個別的に送ることなく、ＬＳＮ値が送信側に送られることがある。

図１３は、本発明の好適な一実施形態によるＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘＳＵＦＩ）のデータフォーマットを示す図である。

図１３を参照すれば、従来のＢＩＴＭＡＰＳＵＦＩと比較して、本発明の好適な一実施形態によるＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘ１ＳＵＦＩ）はＬＳＮフィールドをさらに含む。

ＬＳＮフィールドは１２ビットから構成でき、２つのランダムフィールド間に位置することができる。特に、ＳＵＦＩは、ビットマップフィールドに後続して、または、類型及び長さ、ＬＥＮＧＴＨ及びＦＳＮ、ＦＳＮ及びＢｉｔｍａｐなどを含む任意のフィールド間に位置するように構成可能である。図１３に示す例において、ＢＩＴＭＡＰＳＵＦＩが使われる。あるいは、ＬＳＮフィールドは、ＬＩＳＴ、ＲＬＩＳＴなどに付加できる。

図１４は、本発明の好適な一実施形態によるＢＩＴＭＡＰ拡張ＳＵＦＩを用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。

先ず、送信側からステータス報告要請を受信した受信側は、ステータス報告のためにステータスＰＤＵを構成する。従来の技術において、ＬＳＮ値がＶＲ（Ｒ）値よりも大きな値に設定されると、受信されたＰＤＵのＡＣＫ／ＮＡＣＫ情報が一つのＰＤＵに含まれる必要があるため、一つのステータスＰＤＵが構成される。図１４は、ステータスＰＤＵが本発明の好適な一実施形態によるＢＩＴＭＡＰｘから構成される例を示すものであり、一つのＢＩＴＭＡＰｘが使われる。いくつかのＢＩＴＭＡＰが必要であれば、ＢＩＴＭＡＰｘのみを用いて最終的なＢＩＴＭＡＰを構成することができる。

図１４または図１５に示すように、ステータス報告のためにステータスＰＤＵを受信した送信側は、ＢＩＴＭＡＰｘの「ＢＩＴＭＡＰ」フィールドを介して受信側においてＡＣＫ／ＮＡＣＫを取得することができる。

図１４または図１５に示すＢＩＴＭＡＰ拡張ＳＵＦＩを受信する場合に、送信側は、ＬＳＮ値が当該ＳＵＦＩの「ＬＥＮＴＨ」フィールドにより指示されたオクテットサイズの位置の後続位置に対応する旨を認知する。ＬＥＮＧＴＨ＝「０００１」であれば、ＢＩＴＭＡＰフィールドは２−オクテットサイズを有する。これにより、当該ビットマップに続く１２ビットがＬＳＮ値として認識可能である。

ＢＩＴＭＡＰｘ中のＬＳＮの位置が変わる場合、ＬＳＮ値は、送信側がＬＳＮの位置を適切に認識するような方式により正確に取得可能である。

ＢＩＴＭＡＰ拡張ＳＵＦＩを受信した送信側は、それ以上のＳＵＦＩが存在せず、後続する位置がＰＡＤに対応すると見なす。本発明による新規な類型のＳＵＦＩは、他のＳＵＦＩから当該ＳＵＦＩを識別するためのＩＤにより識別されることが好ましい。例えば、図１３に示すＢＩＴＭＡＰｘＳＵＦＩが新規なタイプＩＤを用いるための新規な類型として定義されることが好ましい。

図１６及び図１７は、本発明の好適な他の実施形態を説明する図である。ＢＩＴＭＡＰｘが従来のＳＵＦＩのものからさっぱり除去され、送信側がＬＳＮ値を取得できるならば、本発明のＳＵＦＩはいくつかのステータスＰＤＵに分割されることにより、送信側に送られたステータス報告に使用可能である。図１６または図１７中、ステータス報告がいくつかのステータスＰＤＵに分割されることで行われると、ステータスＰＤＵはＢＩＴＭＡＰｘを新規な拡張ＳＵＦＩとして用いてＡＣＫＳＵＦＩ無しに構成可能である。

この明細書中には本発明が実施形態に基づいて説明及び図示されているが、本発明の思想及び範囲から逸脱しない限り、種々の修正及び変更が可能であることは、当該分野における通常の知識を持った者にとって自明である。よって、本発明は、特許請求の範囲及びその等価物の範囲内に納まる本発明の修正及び変更をカバーしようとする。

よって、本発明は、無線インターネット、移動通信システムなどの無線通信システムに適用可能である。

本発明のさらなる理解のために提供される添付図面は本発明の一部として取り込まれて本発明の実施形態を例示し、説明と共に本発明の原理を説明するのに寄与する。
従来の技術によるＵＭＴＳのネットワーク構造のブロック図である。従来の技術によるＵＭＴＳ無線プロトコルのアーキテクチャーを示す図である。従来の技術によるＡＭＲＬＣＰＤＵの構造図である。従来の技術によるステータスＰＤＵの構造図である。従来の技術によるピギーバックドステータスＰＤＵの構造図である。従来の技術によるリセットＡＣＫＰＤＵの構造図である。従来の技術によるＮＯ＿ＭＯＲＥＳＵＦＩフィールドの構造図である。従来の技術によるＢＩＴＭＡＰＳＵＦＩの構造図である。従来の技術によるＡＣＫＳＵＦＩの構造図である。本発明の好適な一実施形態によるフローチャートである。本発明の好適な一実施形態により受信側から送信側にステータス報告のために送られてきた第１及び第２のステータスＰＤＵのそれぞれのデータフォーマットを示す図である。本発明の好適な一実施形態により受信側から送信側にステータス報告のために送られてきた第１及び第２のステータスＰＤＵのそれぞれのデータフォーマットを示す図である。本発明の好適な一実施形態によるＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘＳＵＦＩ）のデータフォーマットを示す図である。本発明の好適な一実施形態によりＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘＳＵＦＩ）を用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。本発明の好適な一実施形態によりＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘＳＵＦＩ）を用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。本発明の好適な一実施形態によりＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘＳＵＦＩ）を用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。本発明の好適な一実施形態によりＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘＳＵＦＩ）を用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。

Claims

移動通信システムにおいて送信側で送信ウィンドウを更新する方法であって、
前記方法は、
受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するステップであって、前記第１のステータス報告情報は、前記受信側に送られてくる複数のデータブロックに関する受信確認情報を与える、ステップと、
前記第１のステータス報告情報内の前記受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号を用いて前記送信ウィンドウの下位エッジを更新するステップと、
第２のステータス報告情報を含む第２の制御情報ブロックを受信するステップであって、前記第２のステータス報告情報は、前記第２の制御情報ブロックにおいて最後のステータス報告情報として位置する、ステップと
を含む、方法。
前記第２のステータス報告情報は、前記受信側によって受信された複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示するフィールドを含む、請求項１に記載の方法。
前記第１のステータス報告情報は、ビットマップ型スーパーフィールド（ＳＵＦＩ）である、請求項１に記載の方法。
前記第２のステータス報告情報は、ＡＣＫ型スーパーフィールド（ＳＵＦＩ）である、請求項１に記載の方法。
移動通信システムにおいて送信側で送信ウィンドウを更新する方法であって、
前記方法は、
受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するステップであって、前記第１のステータス報告情報は、前記受信側に送られてくる複数のデータブロックに関する受信確認情報を与える、ステップと、
前記第１のステータス報告情報内の前記受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号を用いて前記送信ウィンドウの下位エッジを更新するステップと
を含む、方法。
移動通信システムにおいて送信ウィンドウを更新する送信機であって、
前記送信機は、
受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信する手段であって、前記第１のステータス報告情報は、前記受信側に送られてくる複数のデータブロックに関する受信確認情報を与える、手段と、
前記第１のステータス報告情報内の前記受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号を用いて前記送信ウィンドウの下位エッジを更新する手段と、
第２のステータス報告情報を含む第２の制御情報ブロックを受信する手段であって、前記第２のステータス報告情報は、前記第２の制御情報ブロックにおいて最後のステータス報告情報として位置する、手段と
を備える、送信機。
前記第２のステータス報告情報は、前記受信側によって受信された複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示するフィールドを含む、請求項６に記載の送信機。