(57)【要約】無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法を提供することにより、送信側における送信効率を高めることができる。本発明は、受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は受信側に送られてくる複数のデータブロックに関する受信確認情報を与える前記第１の制御情報ブロック受信ステップと、第２の制御情報ブロックに最後のステータス報告情報として位置する第２のステータス報告情報を含む前記第２の制御情報ブロック受信ステップと、前記第１のステータス報告情報にある受信確認情報を用いて送信ウィンドウを更新する更新ステップと、を含む。【選択図】図１０
2008541543.tif 000002
【特許請求の範囲】
【請求項１】
移動通信システムにおいて送信ウィンドウを更新する方法であって、
受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は受信側に送られてくる複数のデータブロックに関する受信確認情報を与える前記第１の制御情報ブロック受信ステップと、
第２の制御情報ブロックに最後のステータス報告情報として位置する第２のステータス報告情報を含む前記第２の制御情報ブロック受信ステップと、
前記第１のステータス報告情報にある受信確認情報を用いて送信ウィンドウを更新する更新ステップと、
を含むことを特徴とする送信ウィンドウの更新方法。
【請求項２】
前記第２のステータス報告情報は、前記受信側に受信された複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示するフィールドを含むことを特徴とする請求項１に記載の送信ウィンドウの更新方法。
【請求項３】
前記送信ウィンドウの下位エッジは、前記第１のステータス報告情報にある受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号をもって更新されることを特徴とする請求項１に記載の送信ウィンドウの更新方法。
【請求項４】
前記第１のステータス報告情報は、ビットマップ型スーパーフィールド（ＳＵＦＩ）であることを特徴とする送信ウィンドウの更新方法。
【請求項５】
前記第２のステータス報告情報は、ＡＣＫ型スーパーフィールド（ＳＵＦＩ）であることを特徴とする請求項１に記載の送信ウィンドウの更新方法。
【請求項６】
移動通信システムにおいて送信ウィンドウを更新する方法であって、
受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は受信側に送られてくる複数のデータブロックに関する受信確認情報を与える前記第１の制御情報ブロック受信ステップと、
前記第１のステータス報告情報にある受信確認情報を用いて送信ウィンドウを更新する更新ステップと、
を含むことを特徴とする送信ウィンドウの更新方法。
【請求項７】
前記送信ウィンドウの下位エッジは、前記第１のステータス報告情報にある受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号をもって更新されることを特徴とする請求項６に記載の送信ウィンドウの更新方法。
【請求項８】
制御情報ブロックを送信側に送り、前記送信側が送るデータブロックの上にステータス報告情報を与える方法であって、
第１のステータス報告情報を含む第１の制御情報ブロックを前記送信側に送るが、前記第１のステータス報告情報は、前記送信側が送る複数のデータブロックに関する受信確認情報を与える第１の制御情報ブロック送信ステップと、
第２の制御情報ブロックに最後のステータス報告情報として位置するが、受信ウィンドウの下位エッジに対応するシーケンス番号を指示するフィールドを備える第２のステータス報告情報を含む前記第２の制御情報ブロックを送るステップと、
を含むことを特徴とするステータス報告情報提供方法。
【請求項９】
移動通信システムにおいて送信ウィンドウを更新する送信機であって、
受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は前記受信側に送られてくる複数のデータブロックに関する受信確認情報を与える第１の制御情報ブロックを受信する手段と、
第２の制御情報ブロックに最後のステータス報告情報として位置する第２のステータス報告情報を含む前記第２の制御情報ブロックを受信する手段と、
前記第１のステータス報告情報にある前記受信確認情報を用いて送信ウィンドウを更新する手段と、
を備えることを特徴とする送信機。
【請求項１０】
前記第２のステータス報告情報は、前記受信側に受信された複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示するフィールドを含むことを特徴とする請求項９に記載の送信機。
【請求項１１】
前記送信ウィンドウの下位エッジは、前記第１のステータス報告情報にある前記受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号をもって更新されることを特徴とする請求項９に記載の送信機。
【請求項１２】
受信側に送られてくる複数のデータブロックに受信確認情報を与える制御情報ブロックに含まれているステータス報告指示子のデータ構造であって、
前記ステータス報告指示子の類型を指示する第１のフィールドと、
前記受信側に送られてくる複数のデータブロックに前記受信確認情報を与える第２のフィールドと、
前記受信側において使われる受信ウィンドウの下位エッジに等しいかそれよりも大きなシーケンス番号を指示する第３のフィールドと、
を含むことを特徴とするデータ構造。
【請求項１３】
前記第３のフィールドは、前記受信側に受信される複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示する最後のシーケンス番号（ＬＳＮ）であることを特徴とする請求項１２に記載のデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線通信システムに係り、さらに詳しくは、無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法に関する。
【背景技術】
【０００２】
図１は、ＵＭＴＳ（ユニバーサル移動通信システム  ）のネットワーク構造のブロック図である。
【０００３】
図１を参照すれば、ＵＭＴＳは、主として、ユーザー装置（以下、ＵＥと略す。）と、ＵＭＴＳターミナル・地上無線接続網（以下、ＵＴＲＡＮと略す。）及びコアネットワーク（以下、ＣＮと略す。）を備えている。
【０００４】
ＵＴＲＡＮは、少なくとも一つの無線ネットワークサブシステム（以下、ＲＮＳと略す。）を備えている。また、ＲＮＳは、一つの無線ネットワーク制御器（以下、ＲＮＣと略す。）と、このＲＮＣにより管理される少なくとも一つの基地局（以下、ノードＢと略す。）と、を備えている。さらに、１ノードＢには少なくとも１以上のセルが存在している。
【０００５】
図２は、ＵＭＴＳ無線プロトコルのアーキテクチャーを示す図である。
【０００６】
図２を参照すれば、無線プロトコル階層は、ＵＥとＵＴＲＡＮとの組として存在して、無線区間のデータ送信を司る。
【０００７】
以下、それぞれの無線プロトコル階層について述べる。
【０００８】
先ず、第１の階層としてのＰＨＹは、種々の無線送信技術を用いてデータを無線区間に送る。ＰＨＹ階層における無線区間の信頼性あるデータＰＨＹ階層は、送信チャンネルを介して上位階層となるＭＡＣ階層に接続される。また、送信チャンネルは、主としてチャンネルの共有有無に応じて専用送信チャンネルと共用送信チャンネルとに大別される。
【０００９】
第２の階層は、ＭＡＣ、ＲＬＣ、ＰＤＣＰ及びＢＭＣ階層を含んでいる。先ず、ＭＡＣ階層は、種々の論理チャンネルを種々の送信チャンネルにそれぞれマッピングさせ、さらに、種々の論理チャンネルを１本の送信チャンネルにマッピングさせるという論理チャンネル多重化の機能を行う。ＭＡＣ階層は、論理チャンネルを介して上位階層となるＲＬＣ階層に接続される。
【００１０】
さらに、論理チャンネルは、主として送られてくる情報の類型に応じて、制御平面の情報送信のための制御チャンネルと、ユーザー平面の情報送信のためのトラフィックチャンネルとに大別できる。
【００１１】
一方、ＭＡＣ階層は、細部的に管理される送信チャンネルの類型に応じて、ＭＡＣ−ｂサブ階層、ＭＡＣ−ｄサブ階層、ＭＡＣ−ｃ／ｓｈサブ階層及びＭＡＣ−ｅサブ階層に分けられる。
【００１２】
ＭＣＡ−ｂ階層は、システム情報の放送を司る送信チャンネルＢＣＨの管理を行う。ＭＡＣ−ｃ／ｓｈ階層は、ＦＡＣＨ（ｆｏｒｗａｒｄ  ａｃｃｅｓｓ  ｃｈａｎｎｅｌ）、ＤＳＣＨ（ｄｏｗｎｌｉｎｋ  ｓｈａｒｅｄ  ｃｈａｎｎｅｌ）などの他のＵＥと共有される共用送信チャンネルを管理する。ＭＡＣ−ｄサブ階層は、特定のＵＥに対する専用送信チャンネルＤＣＨ（Ｄｅｄｉｃａｔｅｄ  Ｃｈａｎｎｅｌ）の管理を司る。ＭＡＣ−ｈｓサブ階層は、高速なデータ送信のために送信チャンネルＨＳ−ＤＳＣＨ（Ｈｉｇｈ  Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）を管理し、ダウンリンク及びアップリンク時における高速なデータ送信を支援する。また、ＭＡＣ−ｅサブ階層は、アップリンクデータの送信のための送信チャンネルＥ−ＤＣＨ（Ｅｎｈａｎｃｅｄ  Ｄｅｄｉｃａｔｅｄ  Ｃｈａｎｎｅｌ）を管理する。
【００１３】
ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）階層は、それぞれの無線ベアラーのＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）に対する保証及び対応するデータの送信を司る。ＲＬＣは、ＲＢの固有のＱｏＳを保証するために、それぞれのＲＢごとに一つの独立したＲＬＣエンティティを設けている。ＲＬＣは、種々のＱｏＳに対応するために、ＴＭ（Ｔｒａｎｓｐａｒｅｎｔ  Ｍｏｄｅ）、ＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ）及びＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ  Ｍｏｄｅ）などの３種類のＲＬＣモードを提供している。そして、ＲＬＣは、下位階層が無線区間にデータを送るのに適するようにデータサイズを調節する。このために、上位階層から受信したデータを分割及び接続する機能を行う。
【００１４】
ＰＤＣＰ階層はＲＬＣ階層の上位に位置し、ＩＰｖ４やＩＰｖ６などのＩＰパケットを用いて送られてくるデータを相対的に帯域幅の狭い無線区間において効率よく送る。このために、ＰＤＣＰ階層はヘッダーの圧縮機能を行うが、これは、データのヘッダー部への必須情報の送信を可能にして、無線区間の送信効率を高める。ヘッダー圧縮は、ＰＤＣＰ階層の基本的な機能であるため、ＰＤＣＰ階層はＰＳ（Ｐａｃｋｅｔ  Ｓｅｒｖｉｃｅ）ドメインにのみ存在する。また、それぞれのＰＳサービスに対して効率よいヘッダー圧縮機能を提供するために、それぞれのＲＢにつき一つのＰＤＣＰエンティティが存在する。
【００１５】
第２の階層において、ＢＭＣ（Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ）階層がＲＬＣ階層の上位に存在する。ＢＭＣ階層はセル放送メッセージをスケジューリングし、特定のセルに位置しているＵＥに放送する機能を行う。
【００１６】
第３の階層の最下位に位置するＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）階層は、制御平面においてのみ定義される。ＲＲＣ階層は、ＲＢの設定、再構成及び解除と関連して、第１及び第２の階層のパラメータを制御し、論理チャンネル、送信チャンネル及び物理チャンネルの制御を司る。この場合に、ＲＢとは、ＵＥとＵＴＲＡＮとの間のデータ送信のための無線プロトコルの第１及び第２の階層により与えられる論理的なパスのことを言う。さらに、ＲＢ設定とは、特定のサービスを提供するために無線プロトコル階層及びチャンネルの特性を規定し、それぞれの具体的なパラメータ及び動作方法を設定するプロセスを意味する。
【００１７】
以下、ＲＬＣ階層を詳述する。
【００１８】
先ず、ＲＬＣ階層の基本機能は、各ＲＢのＱｏＳに対する保証とこれに対応するデータの送信である。ＲＢサービスは、無線プロトコルの第２の階層が上位階層に提供するサービスであるため、第２の階層の全体がＱｏＳに影響してしまう。また、ＲＬＣの影響が最も大きい。ＲＬＣは、ＲＢの固有のＱｏＳを保証するために、ＲＢごとに独立したＲＬＣエンティティを設けており、ＴＭ、ＵＭ及びＡＭの３種類のＲＬＣモードを提供している。これらの３種類のＲＬＣモードは、支援するＱｏＳが異なるため動作方法に違いがあり、その細部的な機能にも違いが出る。このため、ＲＬＣは、その動作モード別に分けて調べる必要がある。
【００１９】
ＴＭＲＬＣは、ＲＬＣ  ＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）を構成するとき、上位階層から受け取ったＲＬＣ  ＳＤＵ（Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）にいかなるオーバーヘッドも付加されていないモードである。特に、ＲＬＣがＳＤＵを透明に通過させるため、ＴＭ  ＲＬＣと呼ばれる。このような特性により、ＴＭ  ＲＬＣは、ユーザー平面と制御平面において次のような役割を果たす。ユーザー平面においては、ＲＬＣ内におけるデータ処理時間が短いため、ＣＳ（Ｃｉｒｃｕｉｔ  Ｓｅｒｖｉｃｅ）ドメインの音声やストリーミングなどのリアルタイムな回線データ送信を司る。一方、制御平面においては、ＲＬＣ内にオーバーヘッドがないため、アップリンクの場合に不特定のＵＥからのＲＲＣメッセージに対する送信を司り、ダウンリンクの場合にセル内の全てのＵＥから放送されるＲＲＣメッセージの送信を司る。
【００２０】
透明モードとは異なり、ＲＬＣにおいてオーバーヘッドが追加されるモードを非透明モードといい、このモードにおいては、送られてきたデータへの受信確認応答がないモード（ＵＭ）と、送られてきたデータへの受信確認応答があるモード（ＡＭ）とに大別される。ＵＭ  ＲＬＣは各ＰＤＵごとにシーケンス番号（Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ；以下、ＳＮと略す。）を含むＰＤＵヘッダーを付加することにより、受信側にどのＰＤＵが送信中に失われたかを察知させる。
【００２１】
このような機能により、ＵＭ  ＲＬＣは、主としてユーザー平面においては放送／マルチキャストデータの送信やＰＳドメインの音声（例えば、ＶｏＩＰ）またはストリーミングなどのリアルタイムなパケットデータの送信を行い、制御平面においてはセル内の特定のＵＥまたは特定のＵＥグループに送られるＲＲＣメッセージのうち受信確認応答が不要なＲＲＣメッセージの送信を行う。
【００２２】
非透明モードの一つであるＡＭ  ＲＬＣは、ＵＭ  ＲＬＣと同様、ＳＮを含むＰＤＵヘッダーを付加してＰＤＵを構成する。しかしながら、ＡＭ  ＲＬＣは、ＵＭ  ＲＬＣとは異なり、送信側が送ったＰＤＵに対して受信側が応答するという点で相違点がある。ＡＭ  ＲＬＣにおいて受信側が応答をする理由は、受信側そのものが受信できなかったＰＤＵに対して送信側に再送信を要請することができるからである。また、このような再送信機能がＡＭ  ＲＬＣの最も大きな特徴である。結局、ＡＭ  ＲＬＣの目的は、再送信を通じてエラーのないデータ送信を保証することである。このような目的により、ＡＭ  ＲＬＣは、主としてユーザー平面においてはＰＳドメインのＴＣＰ／ＩＰなどのリアルタイムではないパケットデータの送信を司り、制御平面においてはセル内の特定のＵＥに送られるＲＲＣメッセージのうち受信確認応答が必ず必要となるＲＲＣメッセージの送信を司る。
【００２３】
方向性の面からは、ＴＭまたはＵＭ  ＲＬＣは単方向通信に使われるのに対し、ＡＭ  ＲＬＣは受信側からのフィードバックがあるために両方向通信に使われる。両方向通信は、主として点対点通信において使われるため、ＡＭ  ＲＬＣは専用の論理チャンネルのみを用いる。構造的な面からも次のような相違点がある。ＴＭまたはＵＭ  ＲＬＣにおいては、一つのＲＬＣエンティティが送信または受信のいずれか一つの構造となっているが、ＡＭ  ＲＬＣにおいては一つのＲＬＣエンティティ内に送信側と受信側が両方ともに存在する。
【００２４】
ＡＭ  ＲＬＣの複雑性は、再送信機能による。ＡＭ  ＲＬＣは、再送信の管理のために送受信バッファに加えて再送信バッファを設けており、流れの制御のための送受信ウィンドウの使用、送信側がピーアＲＬＣエンティティの受信側からのステータス情報を要求するポーリング、受信側がピーアＲＬＣエンティティの送信側に自分のバッファステータスを報告するステータス報告、ステータス情報を伝搬するためのステータスＰＤＵ、データ送信の効率を高めるためにデータＰＤＵ中にステータスＰＤＵを埋め込むピギーバック機能など種々の機能を行う。
【００２５】
一方、ＡＭ  ＲＬＣエンティティが動作中に重大なエラーを見つけた場合、他方の側のＡＭ  ＲＬＣエンティティに全ての動作及びパラメータの再設定を要求するリセットＰＤＵが存在する。また、リセットＰＤＵの応答に使われるリセットＡｃｋＰＤＵもある。これらの機能に対応するために、ＡＭ  ＲＬＣには種々のプロトコルパラメータ、状態変数及びタイマーが必要となる。このようなステータス報告またはステータスＰＤＵ、リセットＰＤＵなどのようにＡＭ  ＲＬＣにおいてデータ送信の制御のために使われるＰＤＵを制御ＰＤＵといい、ユーザーデータを送信するために使われるＰＤＵをデータＰＤＵと言う。
【００２６】
要するに、ＡＭ  ＲＬＣにおいて用いるＰＤＵは、主として２種類に大別できる。一つはデータＰＤＵであり、もう一つは制御ＰＤＵである。また、制御ＰＤＵは、ステータスＰＤＵ、ピギーバックドステータスＰＤＵ、リセットＰＤＵ、リセットＡｃｋＰＤＵを含む。
【００２７】
コントロールＰＤＵを用いる場合の一つが、リセットの手続きである。リセットの手続きは、ＡＭ  ＲＬＣの動作におけるエラー状況を解消するために使われる。エラー状況とは、例えば、使用するシーケンス番号が互いに異なる場合、または、ＰＤＵまたはＳＤＵが回数限界に達して送信に失敗する場合である。このリセットの手続きを用いると、受信側のＡＭ  ＲＬＣと送信側のＡＭ  ＲＬＣが環境変数を初期化した後、通信可能なステータスに入り直す。
【００２８】
以下、リセットの手続きについて説明する。
【００２９】
先ず、リセットの手続きを始めると決めた側、すなわち、送信側のＡＭ  ＲＬＣは、リセットＰＤＵにおいて現在使われている送信方向ＨＦＮ（Ｈｙｐｅｒ  Ｆｒａｍｅ  Ｎｕｍｂｅｒ）値を含めてこのリセットＰＤＵを受信側に送る。リセットＰＤＵを受信した受信側のＡＭ  ＲＬＣは、自分の受信方向のＨＦＮ値を再設定した後、シーケンス番号などの環境変数をリセットする。続けて、受信側のＡＭ  ＲＬＣは、自分の送信方向ＨＦＮをリセットＡｃｋＰＤＵに含めてこのリセットＡｃｋＰＤＵを送信側のＡＭ  ＲＬＣに送る。送信側のＡＭ  ＲＬＣは、リセットＡｃｋＰＤＵを受信すれば、自分の受信方向ＨＦＮ値を再設定した後、環境変数をリセットする。
【００３０】
以下、ＡＭ  ＲＬＣエンティティにおいて使われるＲＬＣ  ＰＤＵの構造を詳述する。
【００３１】
図３は、ＡＭ  ＲＬＣ  ＰＤＵの構造図である。
【００３２】
図３を参照すれば、ＡＭ  ＲＬＣ  ＰＤＵは、ＡＭ  ＲＬＣエンティティがユーザーデータまたはピギーバックドステータス情報及びポーリングビットを送りたいときに使われる。ユーザーデータ部は８ビットの整数倍として構成され、ＡＭ  ＲＬＣ  ＰＤＵのヘッダーは２オクテットサイズのシーケンス番号により構成される。また、ＡＭ  ＲＬＣ  ＰＤＵのヘッダー部は長さ指示子（ＬＩ：Ｌｅｎｇｔｈ  Ｉｎｄｉｃａｔｏｒ）を含む。
【００３３】
図４は、ステータスＰＤＵの構造図である。
【００３４】
図４を参照すれば、ステータスＰＤＵは、他の類型のＳＵＦＩ（Ｓｕｐｅｒ  Ｆｉｅｌｄ）を含む。ステータスＰＤＵのサイズは可変的であるが、ステータスＰＤＵが送られる論理チャンネルの最も大きなＲＬＣ  ＰＤＵのサイズに限られる。この場合に、ＳＵＦＩは、受信側にどの類型のＡＭ  ＲＬＣ  ＰＤＵが到達し、且つ、受信側にどの類型のＡＭ  ＲＬＣ  ＰＤＵが未到達であるかなどの情報を通知する。ＳＵＦＩは、類型、長さ及び値の３種類により構成される。
【００３５】
図５は、ピギーバックドステータスＰＤＵの構造図である。
【００３６】
図５を参照すれば、ピギーバックドステータスＰＤＵの構造は、ステータスＰＤＵの構造に類似しているが、Ｄ／Ｃフィールドが予約ビット（Ｒ２）に置き換えられている点で異なる。このピギーバックドステータスＰＤＵは、ＡＭ  ＲＬＣ  ＰＤＵに十分な空間が残っている場合に埋め込まれる。なお、ＰＤＵ種類値は常に「０００」に固定可能である。
【００３７】
図６は、リセットＡＣＫ  ＰＤＵの構造図である。
【００３８】
図６を参照すれば、リセットＰＤＵは、１ビットのＲＳＮと名付けられたシーケンス番号を含む。また、リセットＡＣＫ  ＰＤＵは、受信されたリセットＰＤＵに応答して、受信されたリセットＰＤＵに含まれているＲＳＮを含めて送られてくる。
【００３９】
以下、ＰＤＵフォーマットに使われるパラメータについて説明する。
【００４０】
先ず、「Ｄ／Ｃフィールド」の値は、当該ＰＤＵがコントロールＰＤＵであるか、データＰＤＵであるかを指示する。
【００４１】
「ＰＤＵ類型」は、コントロールＰＤＵの種類を指示する。特に、当該ＰＤＵがリセットＰＤＵであるか、ステータスＰＤＵであるかなどを指示する。
【００４２】
「シーケンス番号」値は、ＡＭ  ＲＬＣ  ＰＤＵのシーケンス番号情報を意味する。
【００４３】
一方、「ポーリングビット」値は、ステータス報告を受信側に要請するときに設定される。
【００４４】
「延長ビット（Ｅ）」値は、次のオクテットが長さ指示子（ＬＩ）であるかどうかを指示する。
【００４５】
「予約ビット（Ｒ１）」値は、リセットＰＤＵまたはリセットＡＣＫ  ＰＤＵにおいて使われ、「０００」に符号化される。
【００４６】
「ヘッダー延長ビット（ＨＥ）」値は、後続するオクテットが長さ指示子（ＬＩ）であるか、データであるかを指示する。
【００４７】
「長さ指示子」値は、ＰＤＵのデータ部中に異なるＳＤＵ間の境界面が存在するとき、その境界面の位置を指示する。
【００４８】
「ＰＡＤ」部はパッディング領域であり、ＡＭ  ＲＬＣ  ＰＤＵにおいては使われない領域である。
【００４９】
以下、ＳＵＦＩ（Ｓｕｐｅｒ  ＦＩｅｌｄ）について説明する。
【００５０】
以上で簡単に述べたように、ＳＵＦＩは、受信側にいかなる種類のＡＭ  ＲＬＣ  ＰＤＵが到達し、受信側にいかなる種類のＡＭ  ＲＬＣ  ＰＤＵが未到達であるかなどの情報を送信側に指示する。現在は、８種類のＳＵＦＩが定義されて使われている。
【００５１】
それぞれのＳＵＦＩは、類型、長さ及び値により構成される。
【００５２】
また、ＮＯ＿ＭＯＲＥ（Ｎｏ  Ｍｏｒｅ  Ｄａｔａ）、ＷＩＮＤＯＷ（Ｗｉｎｄｏｗ  Ｓｉｚｅ）、ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）、ＬＩＳＴ（Ｌｉｓｔ）、ＢＩＴＭＡＰ（Ｂｉｔｍａｐ）、Ｒｌｉｓｔ（Ｒｅｌａｔｉｖｅ  ｌｉｓｔ）、ＭＲＷ（Ｍｏｖｅ  Ｒｅｃｅｉｖｉｎｇ  Ｗｉｎｄｏｗ）、ＭＲＷ  ＡＣＫ（Ｍｏｖｅ  Ｒｅｃｅｉｖｉｎｇ  Ｗｉｎｄｏｗ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）などをはじめとする種々の類型のＳＵＦＩがある。
【００５３】
以下、ＳＵＦＩ類型について詳述する。
【００５４】
（Ａ）ＮＯ＿ＭＯＲＥ  ＳＵＦＩ
図７は、従来の技術によるＮＯ＿ＭＯＲＥ  ＳＵＦＩフィールドの構造図である。
【００５５】
図７を参照すれば、ＮＯ＿ＭＯＲＥ  ＳＵＦＩは、類型フィールドとしてのみ存在する。ＮＯ＿ＭＯＲＥ  ＳＵＦＩは、ＮＯ＿ＭＯＲＥ  ＳＵＦＩに後続してそれ以上のＳＵＦＩが存在しないことを指示する。このため、このＳＵＦＩ以降の領域はＰＡＤ（パッディング）領域と看做されうる。
【００５６】
（Ｂ）ＢＩＴＭＡＰ  ＳＵＦＩ
図８は、従来の技術によるＢＩＴＭＡＰ  ＳＵＦＩフィールドの構造図である。
【００５７】
図８を参照すれば、ＢＩＴＭＡＰ  ＳＵＦＩは、類型、ビットマップ長さ（ＬＥＮＧＴ）、開始シーケンス番号（ＦＳＮ）及びビットマップにより構成される。
【００５８】
ＬＥＮＧＴＨは４ビットから構成され、（ＬＥＮＧＴＨ＋１）はビットマップのオクテットサイズを意味する。例えば、ＬＥＮＧＴＨ＝「００００」であれば、ビットマップオクテットサイズは１であることを意味する。ＬＥＮＧＴＨが「１１１１」までの値に設定可能であるため、ビットマップの最大のオクテットサイズは「１６」となる。
【００５９】
ＦＳＮは１２ビットから構成され、ビットマップの第１のビットに相当するシーケンス番号（ＳＮ）を意味する。
【００６０】
ビットマップは、ＬＥＮＧＴＨフィールドにより与えられる値に応じて可変する。［ＦＳＮ、ＦＳＮ＋（ＬＥＮＧＴＨ＋１）＊８−１］に相当する区間にシーケンス番号に相当するＡＭ  ＲＬＣ  ＰＤＵのステータス情報を報知することができる。順序は左側から右側に向かってシーケンス番号が増大し、ＡＭ  ＲＬＣ  ＰＤＵの受信ステータスは「０」（非正常受信：ＮＡＣＫ）または「１」（正常受信：ＡＣＫ）で表示される。
【００６１】
ＵＥにおいて、ＢＩＴＭＡＰ  ＳＵＦＩが受信側に正確に受信されたと報告したＡＭ  ＲＬＣ  ＰＤＵを送信側により削除することができる。
【００６２】
（Ｃ）ＡＣＫ  ＳＵＦＩ
図９は、従来の技術によるＡＣＫ  ＳＵＦＩフィールドの構造図である。
【００６３】
図９を参照すれば、ＡＣＫ  ＳＵＦＩは、種類及びＬＳＮ（Ｌａｓｔ  ＳｅｑｕｅｎｃｅＮｕｍｂｅｒ）により構成される。
【００６４】
ＡＣＫ  ＳＵＦＩは、ＮＯ＿ＭＯＲＥ  ＳＵＦＩなどのステータスＰＤＵにおいて、データ部の最後の部分であることを指示する。ＡＣＫ  ＳＵＦＩがステータスＰＤＵの最後の部分に存在すれば、ＮＯ＿ＭＯＲＥ  ＳＵＦＩが同時に存在する必要はない。換言すれば、ＮＯ＿ＭＯＲＥ  ＳＵＦＩで終了されていないステータスＰＤＵにはＡＣＫ  ＳＵＦＩが存在することが必要である。ＡＣＫ  ＳＵＦＩ以降の部分はＰＡＤ（パッディング）として看做されうる。
【００６５】
ＡＣＫ  ＳＵＦＩは、ステータスＰＤＵの前部においてそれぞれエラーとして報告されていないＳＮ＜ＬＳＮの全てのＡＭ  ＲＬＣ  ＰＤＵの受信に対して応答をする。換言すれば、ＬＳＮ＞ＶＲ（Ｒ）であれば、受信エラー状態であるＡＭ  ＲＬＣ  ＰＤＵに関する応答情報は、一つのステータスＰＤＵを用いて一つとして送信される必要がある。特に、受信エラー状態であるＡＭ  ＲＬＣ  ＰＤＵに関する応答情報は複数のステータスＰＤＵに分離されて送信されることはできない。もし、ＬＳＮ＝ＶＲ（Ｒ）であれば、受信エラー状態であるＡＭ  ＲＬＣ  ＰＤＵは複数のステータスＰＤＵに分離されて送信可能である。ＬＳＮ＜ＶＲ（Ｒ）である場合には使用できない。また、ＬＳＮの値はＶＲ（Ｈ）に等しいか小さな値に設定可能である。この場合、ＶＲ（Ｈ）は受信側が受信したＡＭ  ＲＬＣ  ＰＤＵのうち最も大きなＳＮ以降に到達するＡＭ  ＲＬＣ  ＰＤＵのＳＮである。特に、受信側が受信したＡＭ  ＲＬＣ  ＰＤＵのうち最も大きなＳＮであるｘを受信したならば、ＶＲ（Ｈ）は（ｘ＋１）となる。
【００６６】
ステータスＰＤＵを受信した送信側は、ＬＳＮとステータスＰＤＵに含まれている第１の受信エラー状態であるＡＭ  ＲＬＣ  ＰＤＵのＳＮとを比較して、ＶＴ（Ａ）の値を更新することができる。
【００６７】
もし、受信されたＬＳＮの値がステータスＰＤＵにおける第１の受信エラーに相当するＡＭ  ＲＬＣ  ＰＤＵのＳＮよりも小さいかそれに等しければ（ＬＳＮ≦ＳＴＡＴＵＳ  ＰＤＵの第１のエラービットのＳＮ）、ＶＴ（Ａ）はＬＳＮ値に更新される。もし、受信されたＬＳＮ値がステータスＰＤＵにおける第１の受信エラーに相当するＡＭ  ＲＬＣ  ＰＤＵのＳＮよりも大きければ（ＬＳＮ＞ＳＴＡＴＵＳ  ＰＤＵの第１のエラービットのＳＮ）、ＶＴ（Ａ）はステータスＰＤＵの第１の受信エラーに相当するＡＭ  ＲＬＣ  ＰＤＵのＳＮ値に更新される。
【００６８】
ＶＲ（Ｒ）は、受信側に順番に受信された最終的なＡＭ  ＲＬＣ  ＰＤＵに後続して受信されると予想されるＡＭ  ＲＬＣ  ＰＤＵのＳＮである。例えば、受信側が受信エラー無しにＮ番目のＡＭ  ＲＬＣ  ＰＤＵまでＡＭ  ＲＬＣＰＵＤを受信したならば、ＶＲ（Ｒ）は（Ｎ＋１）である。また、ＶＴ（Ａ）は、受信側から送信側にＡＣＫ（正常受信応答）情報が順番に受信された最終的なＡＭ  ＲＬＣ  ＰＤＵに後続して受信されると予想されるＡＭ  ＲＬＣ  ＰＤＵのＳＮである。例えば、送信側が受信側からＭ番目までＡＭ  ＲＬＣ  ＰＤＵに関するＡＣＫ（正常受信応答）情報を受信したならば、ＶＴ（Ａ）は（Ｍ＋１）である。
【００６９】
従来の技術においては、送信側がステータス報告を受信した場合、ＡＣＫ  ＳＵＦＩに含まれているＬＳＮ値に基づき送信ウィンドウの下位エッジが更新される。すなわち、従来の技術において、送信側のＡＭ  ＲＬＣは、受信されたＬＳＮ値とステータス報告についてステータスＰＤＵまたはピギーバックドステータスＰＤＵにおいて受信エラーとして報告されたＡＭ  ＲＬＣ  ＰＤＵのシーケンス番号（ＳＮ）とを比較することにより、送信ウィンドウの下位エッジのＶＴ（Ａ）の値を更新すると仮定する。
【００７０】
しかしながら、従来の技術において、送信側は、受信側からＬＳＮ値を含むＡＣＫ  ＳＵＦＩを受信するまで送信ウィンドウを更新することができない。ＡＣＫ  ＳＵＦＩを含むピギーバックドステータスＰＤＵまたはステータスＰＤＵが正常に受信できなかった場合に、受信側がエラー無しにＡＭ  ＲＬＣ  ＰＤＵを受信した旨を認識するにも拘わらず、送信ウィンドウを更新することができない。これにより、受信側へのデータ送信を効率よく行うことができなくなる。
【発明の開示】
【発明が解決しようとする課題】
【００７１】
よって、本発明は、従来の技術の限界及び欠点に起因する１以上の問題点を実質的に除去する、無線通信システムにおける制御情報の送信方法及びこの方法を用いた送信ウィンドウの更新方法に関するものである。
【００７２】
本発明の目的は、無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法を提供することにより、送信側における送信効率を高められるところにある。
【００７３】
本発明の他の目的は、無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法を提供することにより、受信側がエラー無しにデータブロックを受信した旨の情報を取得すれば、送信側の送信ウィンドウを取得された情報に基づいて即座で更新可能にするところにある。
【００７４】
本発明のさらに他の目的は、無線通信システムにおける制御情報の送信方法及びこれを用いた送信ウィンドウの更新方法を提供することにより、送信側におけるデータブロックの送信レートを高めるところにある。
【課題を解決するための手段】
【００７５】
本発明のさらなる特徴及び利点は次の説明において詳述され、部分的には詳細な説明から明らかになり、または、本発明を行うことにより教示可能なものである。本発明の目的及び別の利点は添付図面に加えて、詳細な説明及び請求の範囲において特別に指摘された構造により実現されたり得られるであろう。
【００７６】
送信側が複数のデータブロックを受信側に送るとき、受信側は、受信された複数のデータブロックに関するステータス報告情報を送信側に送る。この場合に、ステータス報告情報は、それぞれのデータブロックに対して受信エラーが存在するかどうかを指示する受信確認情報を含む。好ましくは、ステータス報告情報は、受信側から送信側に送られてくる制御情報ブロックに含まれて送られる。受信側は、複数のデータブロックに関するステータス報告情報を少なくとも２つの制御情報ブロックに含めて送信側に送ることができる。送信側は、受信側から送られてきたステータス報告情報を用いて送信ウィンドウを更新する。
【００７７】
送信側が少なくとも２つの制御情報ブロックを介してステータス報告情報を受信する場合に、第１の制御情報ブロックに含まれているステータス報告情報から、エラーなしに受信側に受信されたデータブロックに関する情報（例えば、第１の受信エラーを有するデータブロックのシーケンス番号）を取得すれば、送信側は第２の制御情報ブロックを受信しなかった場合であっても、送信ウィンドウを更新する。
【００７８】
一方、第１のステータス報告情報及び第２のステータス報告情報が異なる制御情報ブロックにそれぞれ含まれている場合には、複数の制御情報ブロックのうち送信側に最初に受信された制御情報ブロックに含まれている第１のステータス報告情報は、受信側にエラーが発生してから最初に受信された第１のデータブロックに関する情報を含む。なお、第２のステータス報告情報は、送信側に最終的に送られてきた制御データブロックに含まれる。
【００７９】
一方、送信側は、送信側に受信された複数の制御データブロックのうち最初に受信された制御データブロックに含まれている第１のステータス報告情報から、受信エラーを有する第１のデータブロックに関する情報を取得する。最初に受信された制御データブロックを正常に受信するのに失敗した場合には、送信側は、受信された制御データブロックのうち最終的に受信された制御データブロックに含まれている第２のステータス報告情報から、受信エラーを有する第１のデータブロックに関する情報を取得する。
【００８０】
データブロックとは、特定のプロトコル階層において使われるユーザーデータを含むデータユニットを意味する。例えば、データブロックは、ＲＬＣ階層のＰＤＵ（ｐｒｏｔｏｃｏｌ  ｄａｔａ  ｕｎｉｔ）に対応する。制御情報ブロックとは、特定のプロトコル階層に使われた制御情報を含むデータユニットを意味する。例えば、制御情報ブロックは、ステータスＰＤＵ、ピギーバックドステータスＰＤＵなどに対応する。さらに、ステータス報告情報は、制御情報ブロックに含まれているステータス報告指示子である。例えば、ステータス報告情報は、ステータスＰＵＤまたはピギーバックドステータスＰＤＵに含まれている種々のＳＵＦＩ（Ｓｕｐｅｒ  Ｆｉｅｌｄ）に対応する。
【００８１】
これら及び別の利点を達成するために、また、本発明の目的によって具体化されて広義で説明されるものであって、本発明による移動通信システムにおける送信ウィンドウの更新方法は、受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は受信側に送られてくる複数のデータブロックに関する受信確認情報を与える前記第１の制御情報ブロック受信ステップと、第２の制御情報ブロックに最後のステータス報告情報として位置する第２のステータス報告情報を含む前記第２の制御情報ブロック受信ステップと、前記第１のステータス報告情報にある受信確認情報を用いて送信ウィンドウを更新する更新ステップと、を含む。
【００８２】
好ましくは、第２のステータス報告情報は、受信側に受信された複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示するフィールドを含む。
【００８３】
好ましくは、送信ウィンドウの下位エッジは、第１のステータス報告情報にある受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号をもって更新される。
【００８４】
好ましくは、第１のステータス報告情報は、ビットマップ型スーパーフィールド（ＳＵＦＩ）である。
【００８５】
好ましくは、第２のステータス報告情報は、ＡＣＫ型スーパーフィールド（ＳＵＦＩ）である。
【００８６】
これら及び他の利点をさらに達成するために、また、本発明の目的に応じて、移動通信システムにおける送信ウィンドウの更新方法は、受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は受信側に送られてくる複数のデータブロックに関する受信確認情報を与える前記第１の制御情報ブロック受信ステップと、前記第１のステータス報告情報にある受信確認情報を用いて送信ウィンドウを更新する更新ステップと、を含む。
【００８７】
好ましくは、送信ウィンドウの下位エッジは、前記第１のステータス報告情報にある受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号をもって更新される。
【００８８】
これら及び別の利点をさらに達成するために、また、本発明の目的に応じて、制御情報ブロックを送信側に送り、前記送信側が送るデータブロックの上にステータス報告情報を与える方法は、第１のステータス報告情報を含む第１の制御情報ブロックを前記送信側に送るが、前記第１のステータス報告情報は前記送信側が送る複数のデータブロックに関する受信確認情報を与える第１の制御情報ブロック送信ステップと、第２の制御情報ブロックに最後のステータス報告情報として位置するが、受信ウィンドウの下位エッジに対応するシーケンス番号を指示するフィールドを備える第２のステータス報告情報を含む前記第２の制御情報ブロックを送るステップと、を含む。
【００８９】
これら及び他の利点をさらに達成するために、また、本発明の目的に応じて、移動通信システムにおいて送信ウィンドウを更新する送信機は、受信側から第１のステータス報告情報を含む第１の制御情報ブロックを受信するが、前記第１のステータス報告情報は前記受信側に送られてくる複数のデータブロックに関する受信確認情報を与える第１の制御情報ブロックを受信する手段と、第２の制御情報ブロックに最後のステータス報告情報として位置する第２のステータス報告情報を含む前記第２の制御情報ブロックを受信する手段と、前記第１のステータス報告情報にある前記受信確認情報を用いて送信ウィンドウを更新する手段と、を備える。
【００９０】
好ましくは、第２のステータス報告情報は、受信側に受信された複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示するフィールドを含む。
【００９１】
好ましくは、送信ウィンドウの下位エッジは、第１のステータス報告情報にある受信確認情報の第１のＮＡＣＫ情報に対応するデータブロックのシーケンス番号をもって更新される。
【００９２】
これら及び他の利点をさらに達成するために、また、本発明の目的に応じて、受信側に送られてくる複数のデータブロックに受信確認情報を与える制御情報ブロックに含まれているステータス報告指示子のデータ構造は、前記ステータス報告指示子の類型を指示する第１のフィールドと、前記受信側に送られてくる複数のデータブロックに前記受信確認情報を与える第２のフィールドと、前記受信側において使われる受信ウィンドウの下位エッジに等しいかそれよりも大きなシーケンス番号を指示する第３のフィールドと、を含む。
【００９３】
好ましくは、第３のフィールドは、受信側に受信される複数のデータブロックのうち第１の受信エラーを有するデータブロックのシーケンス番号を指示する最後のシーケンス番号（ＬＳＮ）である。
【００９４】
上述した通常の説明及び後述する詳細な説明はいずれも例示的なものであり、説明のためのものであり、請求されるように、本発明のさらなる説明を提供しようとするためのものであることが理解できるであろう。
【発明を実施するための最良の形態】
【００９５】
以下、添付図面に基づき、本発明の好適な実施形態について詳述する。
【００９６】
本発明の後述する実施形態において、本発明の技術的な特徴は、ＵＭＴＳに適用される。
【００９７】
図１０は、本発明の好適な一実施形態によるフローチャートである。
【００９８】
図１０を参照すれば、送信側は、複数のＲＬＣ  ＰＤＵを受信側に送る（Ｓ１１）。送信側は、必要に応じて、受信側にステータス報告情報を要請することができる（Ｓ１２）。送信側からステータス報告情報要請を受信したり、必要に応じて、受信側は、ステータス報告に関するステータスＰＤＵまたはピギーバックドステータスＰＤＵを構成した後、構成されたこのＰＤＵを周期的にまたは非周期的に送信側に送る。
【００９９】
受信側は、送信側から送られてきた複数のＲＬＣ  ＰＤＵに関するステータス報告のために少なくとも一つのステータスＰＤＵまたはピギーバックドステータスＰＤＵを構成し、構成された少なくとも一つのステータスＰＤＵまたはピギーバックドステータスＰＤＵを送信側に送る。図１０に示す実施形態において、受信側は、シーケンス番号（ＳＮ）０〜９９の受信状態について、２つのステータスＰＤＵまたは２つのピギーバックドステータスＰＤＵにより状態を報告する（Ｓ１３、Ｓ１５）。
【０１００】
図１１及び図１２は、本発明の好適な一実施形態により受信側から送信側にステータス報告のために送られてきた第１及び第２のステータスＰＤＵのデータフォーマットを示す図である。図１１及び図１２を参照すれば、ＢＩＴＭＡＰｘ１  ＳＵＦＩ及びＢＩＴＭＡＰｘ２  ＳＵＦＩは、ビットマップを構成することにより、ＳＮ：０〜ＳＮ：９９のＰＤＵに対して受信確認情報、すなわち、ＡＣＫ／ＮＡＣＫを報知することができる。
【０１０１】
例えば、受信側において受信エラーの発生したＰＤＵがＳＮ：３０、ＳＮ：５０、ＳＮ：５５及びＳＮ：８０にそれぞれ対応するとすれば、第１の受信エラーに対応するＡＭ  ＲＬＣ  ＰＤＵのＳＮは３０であり、図１２に示す第２のステータスＰＤＵに含まれているＡＣＫ  ＳＵＦＩのＬＳＮ値は「３０」であると定義できる。すなわち、ＡＣＫ  ＳＵＦＩのＬＳＮ値はＶＲ（Ｒ）に設定されるわけではなく、第１の受信エラーに対応するＲＬＣ  ＰＤＵのＳＮ値に設定される。
【０１０２】
ＢＩＴＭＡＰｘ１は、ＳＮ：〜ＳＮ：ＫのＰＤＵに関するＡＣＫ／ＮＡＣＫ情報を含み、ＢＩＴＭＡＰｘ２は、ＳＮ：（Ｋ＋１）〜ＳＮ：９９のＰＤＵに関するＡＣＫ／ＮＡＣＫ情報を含む。
【０１０３】
第１のステータスＰＤＵを受信する場合に（Ｓ１３）、送信側は、第１のステータスＰＤＵに含まれているＢＩＴＭＡＰｘ１からＳＮ：０〜ＳＮ：Ｋの範囲に属するＡＣＫ／ＮＡＣＫ情報を取得することができる。このため、送信側は、ＳＮ：３０のＰＤＵは第１の受信エラーに対応する旨を認識することができる。これにより、送信側は、他のステータスＰＤＵの受信を待つことなく、送信ウィンドウを直ちに更新する（Ｓ１４）。
【０１０４】
すなわち、送信側が以前に受信したステータス報告後に第１の受信エラーに対応するＳＮ：３０のＰＤＵまでＰＤＵが順番に正常に受信されるという旨を認知する場合に、送信側は、通信ウィンドウの下位エッジ、すなわち、ＶＴ（Ａ）を更新することができる。この例において、第１の受信エラーに対応するＳＮが３０であるため、ＶＴ（Ａ）は３０に更新される。また、第１の受信エラーに対応するＳＮは、受信側が設定したＬＳＮ値と同値である。
【０１０５】
送信側が第２のステータスＰＤＵを受信すれば（Ｓ１５）、送信側はＡＣＫ  ＳＵＦＩに含まれているＬＳＮ値を確認することができる。あるいは、第２のステータスＰＤＵに含まれていないＡＣＫ  ＳＵＦＩを有していてもよい。
【０１０６】
少なくとも３つのステータスＰＤＵから構成されたステータス報告において第１のステータスＰＤＵなどが失われている場合には、送信側がＡＣＫ／ＮＡＣＫ情報を順次に受信しなかったことを意味する。このため、第２のステータスＰＤＵが正常に受信されたとしても、ＶＴ（Ａ）は第２のステータスＰＤＵの第１のエラーに対応するＳＮ値に更新されない。この場合に、ＶＴ（Ａ）は、最終的なステータスＰＤＵを受信することにより、ＡＣＫ  ＳＵＦＩに含まれているＬＳＮ値をもって更新されることが必要である。
【０１０７】
ＢＩＴＭＡＰｘ１は、受信側において第１の受信エラーに対応するＲＬＣ  ＰＤＵのＳＮを用いてＳＵＦＩが構成される旨を知らせるために、従来のＢＩＴＭＡＰ  ＳＵＦＩとは差別化可能である。すなわち、上記の用途を有する新規な類型のＳＵＦＩが構成可能である。例えば、ＬＳＮがＢＩＴＭＡＰｘ１に含まれうる。これについては後述する。
【０１０８】
従来の技術において、ＡＣＫ／ＮＡＣＫ情報を指示するＳＵＦＩ（例えば、ＢＩＴＭＡＰ、ＬＩＳＴ、ＲＬＩＳＴ  ＳＵＦＩなど）が同じまたは異なるステータスＰＤＵを介してＡＣＫ  ＳＵＦＩと共に送信される必要がある。この場合に、ＡＣＫ  ＳＵＦＩの代わりにＬＳＮ値を有するＳＵＦＩ（例えば、ＢＩＴＭＡＰ、ＬＩＳＴ、ＲＬＩＳＴ  ＳＵＦＩなど）と関連するＡＣＫ／ＮＡＣＫの新規な類型を考慮する場合、ＡＣＫ  ＳＵＦＩを個別的に送ることなく、ＬＳＮ値が送信側に送られることがある。
【０１０９】
図１３は、本発明の好適な一実施形態によるＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘ  ＳＵＦＩ）のデータフォーマットを示す図である。
【０１１０】
図１３を参照すれば、従来のＢＩＴＭＡＰ  ＳＵＦＩと比較して、本発明の好適な一実施形態によるＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘ１  ＳＵＦＩ）はＬＳＮフィールドをさらに含む。
【０１１１】
ＬＳＮフィールドは１２ビットから構成でき、２つのランダムフィールド間に位置することができる。特に、ＳＵＦＩは、ビットマップフィールドに後続して、または、類型及び長さ、ＬＥＮＧＴＨ及びＦＳＮ、ＦＳＮ及びＢｉｔｍａｐなどを含む任意のフィールド間に位置するように構成可能である。図１３に示す例において、ＢＩＴＭＡＰ  ＳＵＦＩが使われる。あるいは、ＬＳＮフィールドは、ＬＩＳＴ、ＲＬＩＳＴなどに付加できる。
【０１１２】
図１４は、本発明の好適な一実施形態によるＢＩＴＭＡＰ拡張ＳＵＦＩを用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。
【０１１３】
先ず、送信側からステータス報告要請を受信した受信側は、ステータス報告のためにステータスＰＤＵを構成する。従来の技術において、ＬＳＮ値がＶＲ（Ｒ）値よりも大きな値に設定されると、受信されたＰＤＵのＡＣＫ／ＮＡＣＫ情報が一つのＰＤＵに含まれる必要があるため、一つのステータスＰＤＵが構成される。図１４は、ステータスＰＤＵが本発明の好適な一実施形態によるＢＩＴＭＡＰｘから構成される例を示すものであり、一つのＢＩＴＭＡＰｘが使われる。いくつかのＢＩＴＭＡＰが必要であれば、ＢＩＴＭＡＰｘのみを用いて最終的なＢＩＴＭＡＰを構成することができる。
【０１１４】
図１４または図１５に示すように、ステータス報告のためにステータスＰＤＵを受信した送信側は、ＢＩＴＭＡＰｘの「ＢＩＴＭＡＰ」フィールドを介して受信側においてＡＣＫ／ＮＡＣＫを取得することができる。
【０１１５】
図１４または図１５に示すＢＩＴＭＡＰ拡張ＳＵＦＩを受信する場合に、送信側は、ＬＳＮ値が当該ＳＵＦＩの「ＬＥＮＴＨ」フィールドにより指示されたオクテットサイズの位置の後続位置に対応する旨を認知する。ＬＥＮＧＴＨ＝「０００１」であれば、ＢＩＴＭＡＰフィールドは２−オクテットサイズを有する。これにより、当該ビットマップに続く１２ビットがＬＳＮ値として認識可能である。
【０１１６】
ＢＩＴＭＡＰｘ中のＬＳＮの位置が変わる場合、ＬＳＮ値は、送信側がＬＳＮの位置を適切に認識するような方式により正確に取得可能である。
【０１１７】
ＢＩＴＭＡＰ拡張ＳＵＦＩを受信した送信側は、それ以上のＳＵＦＩが存在せず、後続する位置がＰＡＤに対応すると見なす。本発明による新規な類型のＳＵＦＩは、他のＳＵＦＩから当該ＳＵＦＩを識別するためのＩＤにより識別されることが好ましい。例えば、図１３に示すＢＩＴＭＡＰｘ  ＳＵＦＩが新規なタイプＩＤを用いるための新規な類型として定義されることが好ましい。
【０１１８】
図１６及び図１７は、本発明の好適な他の実施形態を説明する図である。ＢＩＴＭＡＰｘが従来のＳＵＦＩのものからさっぱり除去され、送信側がＬＳＮ値を取得できるならば、本発明のＳＵＦＩはいくつかのステータスＰＤＵに分割されることにより、送信側に送られたステータス報告に使用可能である。図１６または図１７中、ステータス報告がいくつかのステータスＰＤＵに分割されることで行われると、ステータスＰＤＵはＢＩＴＭＡＰｘを新規な拡張ＳＵＦＩとして用いてＡＣＫ  ＳＵＦＩ無しに構成可能である。
【０１１９】
この明細書中には本発明が実施形態に基づいて説明及び図示されているが、本発明の思想及び範囲から逸脱しない限り、種々の修正及び変更が可能であることは、当該分野における通常の知識を持った者にとって自明である。よって、本発明は、特許請求の範囲及びその等価物の範囲内に納まる本発明の修正及び変更をカバーしようとする。
【産業上の利用可能性】
【０１２０】
よって、本発明は、無線インターネット、移動通信システムなどの無線通信システムに適用可能である。
【図面の簡単な説明】
【０１２１】
本発明のさらなる理解のために提供される添付図面は本発明の一部として取り込まれて本発明の実施形態を例示し、説明と共に本発明の原理を説明するのに寄与する。
【図１】従来の技術によるＵＭＴＳのネットワーク構造のブロック図である。
【図２】従来の技術によるＵＭＴＳ無線プロトコルのアーキテクチャーを示す図である。
【図３】従来の技術によるＡＭ  ＲＬＣ  ＰＤＵの構造図である。
【図４】従来の技術によるステータスＰＤＵの構造図である。
【図５】従来の技術によるピギーバックドステータスＰＤＵの構造図である。
【図６】従来の技術によるリセットＡＣＫ  ＰＤＵの構造図である。
【図７】従来の技術によるＮＯ＿ＭＯＲＥ  ＳＵＦＩフィールドの構造図である。
【図８】従来の技術によるＢＩＴＭＡＰ  ＳＵＦＩの構造図である。
【図９】従来の技術によるＡＣＫ  ＳＵＦＩの構造図である。
【図１０】本発明の好適な一実施形態によるフローチャートである。
【図１１】本発明の好適な一実施形態により受信側から送信側にステータス報告のために送られてきた第１及び第２のステータスＰＤＵのそれぞれのデータフォーマットを示す図である。
【図１２】本発明の好適な一実施形態により受信側から送信側にステータス報告のために送られてきた第１及び第２のステータスＰＤＵのそれぞれのデータフォーマットを示す図である。
【図１３】本発明の好適な一実施形態によるＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘ  ＳＵＦＩ）のデータフォーマットを示す図である。
【図１４】本発明の好適な一実施形態によりＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘ  ＳＵＦＩ）を用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。
【図１５】本発明の好適な一実施形態によりＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘ  ＳＵＦＩ）を用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。
【図１６】本発明の好適な一実施形態によりＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘ  ＳＵＦＩ）を用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。
【図１７】本発明の好適な一実施形態によりＢＩＴＭＡＰ拡張ＳＵＦＩ（ＢＩＴＭＡＰｘ  ＳＵＦＩ）を用いて受信側から送信側にステータス報告を行うプロセスを説明する図である。
【図１】
2008541543.tif 000003
【図２】
2008541543.tif 000004
【図３】
2008541543.tif 000005
【図４】
2008541543.tif 000006
【図５】
2008541543.tif 000007
【図６】
2008541543.tif 000008
【図７】
2008541543.tif 000009
【図８】
2008541543.tif 000010
【図９】
2008541543.tif 000011
【図１０】
2008541543.tif 000012
【図１１】
2008541543.tif 000013
【図１２】
2008541543.tif 000014
【図１３】
2008541543.tif 000015
【図１４】
2008541543.tif 000016
【図１５】
2008541543.tif 000017
【図１６】
2008541543.tif 000018
【図１７】
2008541543.tif 000019
【国際調査報告】
2008541543.tif 000020
2008541543.tif 000021
2008541543.tif 000022