(57)【要約】本発明は、無線通信システムで状態報告メッセージ（status report）を送受信する方法及びその送受信装置に関する。本発明の一様相による状態報告メッセージ伝送方法は、無線通信システムにおける状態報告メッセージ（statusreport）伝送方法であって、一つの状態報告メッセージの伝送をトリガリングする段階と、送信側から伝送された多数のデータブロックに対する受信状態情報、及び状態報告メッセージに含まれるということを指示する指示情報を含む少なくとも二つの状態データブロックで状態報告メッセージを構成する段階と、少なくとも二つの状態データブロックを送信側に伝送する段階と、を含む構成とした。
2010511320.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムにおける状態報告メッセージ（status report）伝送方法であって、
一つの状態報告メッセージの伝送をトリガリングする段階と、
送信側から伝送された多数のデータブロックに対する受信状態情報、及び前記状態報告メッセージに含まれるということを指示する指示情報を含む少なくとも二つの状態データブロックで前記状態報告メッセージを構成する段階と、
前記少なくとも二つの状態データブロックを前記送信側に伝送する段階と、
を含む、状態報告メッセージ伝送方法。
【請求項２】
前記指示情報は、前記状態報告メッセージを他の状態報告メッセージと区別するための識別子であることを特徴とする、請求項１に記載の状態報告メッセージ伝送方法。
【請求項３】
各状態データブロックは、一連番号を含むことを特徴とする、請求項１記載の状態報告メッセージ伝送方法。
【請求項４】
各状態データブロックは、該当のデータブロックが前記状態報告メッセージに属する最後の状態データブロックであるか否かを表示するためのフィールドを含むことを特徴とする、請求項３記載の状態報告メッセージ伝送方法。
【請求項５】
各状態データブロックは、前記状態報告メッセージが二つ以上の状態データブロックで構成されるということを表示する指示子を含むことを特徴とする、請求項１記載の状態報告メッセージ伝送方法。
【請求項６】
無線通信システムにおける状態報告メッセージ（status report）受信方法であって、
多数のデータブロックを受信側に伝送する段階と、
前記受信側から前記多数のデータブロックに対する受信状態情報、及び一つの状態報告メッセージに含まれるということを指示する指示情報を含む少なくとも二つの状態データブロックを受信する段階と、
前記指示情報を用いて前記少なくとも二つの状態データブロックから前記多数のデータブロックに対する受信状態情報を獲得する段階と、
を含む、状態報告メッセージ受信方法。
【請求項７】
前記指示情報は、前記状態報告メッセージを他の状態報告メッセージと区別するための識別子であることを特徴とする、請求項６記載の状態報告メッセージ受信方法。
【請求項８】
各状態データブロックは、一連番号を含むことを特徴とする、請求項６記載の状態報告メッセージ受信方法。
【請求項９】
各状態データブロックは、該当のデータブロックが前記状態報告メッセージに属する最後の状態データブロックであるか否かを表示するためのフィールドを含むことを特徴とする、請求項８記載の状態報告メッセージ受信方法。
【請求項１０】
各状態データブロックは、前記状態報告メッセージが二つ以上の状態データブロックで構成されるということを表示する指示子を含むことを特徴とする、請求項６記載の状態報告メッセージ受信方法。
【請求項１１】
無線通信システムで一つの状態報告メッセージ（status report）に含まれる少なくとも二つの状態データブロックのうちいずれか一つの状態データブロックの構造であって、
送信側から伝送された多数のデータブロックの一部に対する受信状態を表す受信状態情報と、
前記状態データブロックが前記状態報告メッセージに含まれるということを指示する指示情報と、
を含む、状態データブロックの構造。
【請求項１２】
前記指示情報は、前記状態報告メッセージを他の状態報告メッセージと区別するための識別子であることを特徴とする、請求項１１に記載の状態データブロックの構造。
【請求項１３】
前記状態データブロックは、一連番号をさらに含むことを特徴とする、請求項１１記載の状態データブロックの構造。
【請求項１４】
前記状態データブロックは、該当のデータブロックが前記状態報告メッセージに属する最後の状態データブロックであるか否かを表示するためのフィールドをさらに含むことを特徴とする、請求項１３記載の状態データブロックの構造。
【請求項１５】
前記状態データブロックは、前記状態報告メッセージが二つ以上の状態データブロックで構成されるということを表示する指示子をさらに含むことを特徴とする、請求項１１記載の状態データブロックの構造。
【請求項１６】
無線通信システムにおける状態報告メッセージを伝送する装置であって、
一つの状態報告メッセージの伝送をトリガリングする手段と、
送信側から伝送された多数のデータブロックに対する受信状態情報、及び前記状態報告メッセージに含まれるということを指示する指示情報を含む少なくとも二つの状態データブロックで前記状態報告メッセージを構成する手段と、
前記少なくとも二つの状態データブロックを前記送信側に伝送する手段と、
を含む、状態報告メッセージ伝送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムで状態報告メッセージ（status report）を送受信する方法及びその送信装置に関する。
【背景技術】
【０００２】
図１は、ＵＭＴＳ（Universal Mobile Telecommunications System）の網構造を示す図である。
【０００３】
ＵＭＴＳは、大きく、使用者端末（User Equipment；UE）、ＵＭＴＳ無線接続網（UMTS Terrestrial Radio Access Network；UTRAN）及び基幹網（CoreNetwork；CN）からなっている。ＵＴＲＡＮは、一つ以上の無線網副システム（Radio Network Sub-systems；RNS）で構成され、各ＲＮＳは、一つの無線網制御器（RadioNetwork Controller；RNC）と、このＲＮＣによって管理される一つ以上の基地局（Node B）で構成される。一つのＮｏｄｅ Ｂには一つ以上のセル（Cell）が存在する。
【０００４】
ＵＭＴＳで使用する無線プロトコルは、多数の階層構造からなっており、なかでもＲＬＣ階層は、各無線ベアラ（Radio Bearer；RB）のＱｏＳ（Quality of service）に対する保障とそれによるデータの伝送を担当する。ＲＬＣ（RadioLink Control）は、ＲＢ固有のＱｏＳを保障するために、ＲＢごとに一つまたは二つの独立したＲＬＣ個体（Entity）を備えており、多様なＱｏＳを支援するために、ＴＭ（TransparentMode；透明モード）、ＵＭ（Unacknowledged Mode；無応答モード）及びＡＭ（Acknowledged Mode；応答モード）の３種類のＲＬＣモードを提供する。
【０００５】
ここで、応答モードＲＬＣは、再伝送を通じて誤り無し（error-free）データの伝送を保障することに目的がある。したがって、応答モードＲＬＣは、主として使用者平面でＴＣＰ／ＩＰなどのようなパケットスイッチング領域の非実時間パケット伝送を担当し、制御平面では、セル内の特定使用者端末に伝送するＲＲＣメッセージのうち、受信確認応答を必ず必要とするＲＲＣメッセージの伝送を担当する。
【０００６】
応答モードＲＬＣで使用するＰＤＵ（Protocol Data Unit）は、大きく、データＰＤＵ（Data PDU）と制御ＰＤＵ（Control PDU）とに分類されることができ、制御ＰＤＵは再び、状態ＰＤＵ（statusPDU）、ピギーバック状態ＰＤＵ（Piggybacked status PDU）、リセットＰＤＵ（Reset PDU）、リセット応答ＰＤＵ（Reset AckPDU）に分類されることができる。
【０００７】
一方、ＭＡＣ（MediaAccess Channel）階層に備えられたＭＡＣ個体は、毎ＴＴＩごとにどんなＲＬＣ個体がどれだけのデータを伝送するかを決定する。このようなＭＡＣ個体の決定によって、それぞれのＲＬＣ個体はＲＬＣＰＤＵを構成しそれをＭＡＣ個体に伝達する。
【０００８】
ＲＬＣ個体の立場では、下位の個体が理想的に動作するとすれば、ＲＬＣ個体間に互いにやり取りする状態情報の量は微小である。例えば、使用者端末機が基地局の近くに位置するとすれば、ＲＬＣ個体が下位端に伝達したＲＬＣＰＤＵが下位端から正しく伝送されず、相手側のＲＬＣ個体に到達できない場合はほとんどない。したがって、受信側ＲＬＣ個体があるＲＬＣ ＰＤＵの受信に失敗し、該当のＲＬＣＰＤＵを再伝送してもらいたいという状態情報を送信側ＲＬＣ個体に送ることもほとんどない。
【０００９】
しかし、移動通信システムにおいて使用者端末は絶えず位置を変更しており、使用者端末が移動をしない場合であっても通信環境が時々刻々変わることができる。また、使用者端末が一つ以上のセルの境界面に位置したり、あるいは、使用者端末が急にトンネル中に入っていく場合、使用者端末が伝送しているデータブロックと基地局が使用者端末に伝送するデータブロックとも無線区間で損失する確率が高い。この場合、基地局と使用者端末が互いにやり取りしなければならない制御情報、すなわち、状態情報の量は相対的に増加してしまう。ここで、状態情報には、データの受信状態情報、すなわち、各データブロックが成功的に受け取られたか否かに関する情報を報告する所定の状態報告メッセージ（status report message）が該当することができる。
【００１０】
一方、無線環境が劣悪な状況では、使用者端末が毎伝送時間間隔（TTI：Transmit Time Interval）に伝送できるデータの量も制約されざるを得ない。したがって、受信側のＲＬＣ個体が伝送できる状態報告メッセージも一定大きさに制限されるため、受信側のＲＬＣ個体は、当該状態報告メッセージを多数の状態ＰＤＵ（statusPDU）に分割して送信側に伝送しなければならない。この時、色々な理由から、分割された状態ＰＤＵの一部が送信側ＲＬＣ個体に正しく到着しない場合があり得、この場合、送信側ＲＬＣ個体が受信側ＲＬＣ個体のデータ受信状況を誤判断する結果につながることができる。
【００１１】
例えば、一つの状態報告メッセージが二つの状態ＰＤＵ（status PDU）に分割される時、１番目の状態ＰＤＵは１番〜５番、そして７番〜１０番のＲＬＣ ＰＤＵを成功的に受信したことを知らせ、２番目の状態ＰＤＵは１１番〜１５のＲＬＣＰＤＵを成功的に受信したことを知らせると仮定する。
【００１２】
ここで、送信側ＲＬＣ個体が２番目の状態ＰＤＵのみを成功的に受信する場合、送信側ＲＬＣ個体は、受信側ＲＬＣ個体が１番〜１５番をいずれも正しく受け取ったと誤判断することができる。または、送信側ＲＬＣ個体は、受信側ＲＬＣ個体が１番〜１０番をいずれも正しく受け取ることができなかったと誤判断することができる。または、送信側ＲＬＣ個体が２番目の状態ＰＤＵを受信した後に１番目の状態ＰＤＵを受信した場合、送信側ＲＬＣ個体は、１５番目のＲＬＣＰＤＵの後に生成されたＲＬＣ ＰＤＵのうち、６番が成功的に伝達されなかったと判断することもできる。これら全ての場合が、大きさの大きい状態報告メッセージを送信側ＲＬＣ個体に正しく伝達できないことから生じうる問題点である。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
本発明は上記の従来技術の問題点を解決するために提案されたもので、その目的は、信頼性ある状態情報の伝送を保障できる方案を提供することにある。
【００１４】
本発明の他の目的は、無線通信システムで状態情報の伝送効率を最大化するための方案を提供することにある。
【課題を解決するための手段】
【００１５】
本発明の一様相による状態報告メッセージ伝送方法によれば、無線通信システムで受信側は、送信側から受け取った多数のデータブロックに対する受信状態情報を報告するために、送信側に状態報告メッセージ（Status report）を伝送する。すなわち、受信側で所定イベントが発生すると、一つの状態報告メッセージの伝送をトリガリング（triggering）する。多数のデータブロックに対する受信状態情報を含む状態データブロックの大きさが、既に設定された最大許容値を超過する場合、受信側は、一つの状態報告メッセージを二つ以上の状態データブロックから構成して、送信側に伝送する。各状態データブロックは、多数のデータブロックのうち一部に対する受信状態情報、及び該状態データブロックが一つの状態報告メッセージに含まれるということを指示する指示情報を含む。送信側は受信側から多数のデータブロックに対する受信状態情報及び一つの状態報告メッセージに含まれるということを指示する指示情報を含む少なくとも二つの状態データブロックを受信する。送信側は、指示情報を用いて少なくとも二つの状態データブロックから多数のデータブロックに対する受信状態情報を獲得する。
【図面の簡単な説明】
【００１６】
【図１】ＵＭＴＳ（UniversalMobile Telecommunications System）の網構造を示す図である。
【図２】ＵＭＴＳで使用する無線プロトコルの構造を示すブロック図である。
【図３】制御ＰＤＵのうち、状態ＰＤＵ（status PDU）の構造を示す図である。
【図４】本発明の一実施例による状態報告メッセージ伝送方法を示すフローチャートである。
【図５】本発明の一実施例によって一つの状態報告メッセージを二つ以上の状態ＰＤＵで構成する場合、各状態ＰＤＵのデータフォーマットの一例を示す図である。
【図６】本発明の他の実施例による状態報告メッセージ伝送方法を示すフローチャートである。
【図７】ＲＬＣ状態報告メッセージの送信側を使用者端末と仮定する時、該使用者端末の主要構成を示す図である。
【発明を実施するための形態】
【００１７】
以下、添付の図面を参照しつつ説明される本発明の実施例から、本発明の構成、作用及び他の特徴が容易に理解される。
【００１８】
本発明は、様々な無線通信システムの下りリンク（downlink）または上りリンク（uplink）に適用されることができる。下りリンクは、基地局（base station；BS）から使用者端末機（mobilestation；MS）への通信を意味し、上りリンクは、使用者端末機から基地局への通信を意味する。基地局は、一般に、使用者端末機と通信する固定した地点（fixedstation）のことをいい、ノード−Ｂ（node-B）、ＢＴＳ（base transceiver system）、アクセスポイント（access point）等、別の用語（terminology）と呼ばれることができる。使用者端末機は、固定されたり移動性を持つことができ、ＵＥ（userequipment）、ＵＴ（user terminal）、ＳＳ（subscriber station）、無線機器（wireless device）等、別の用語と呼ばれることができる。
【００１９】
また、本発明の一実施例はＵＭＴＳで動作することができる。以下では、まず本発明の実施例の動作背景について説明し、続いて本発明の実施例の具体的な動作過程について説明する。
【００２０】
図２は、ＵＭＴＳで使用する無線プロトコルの構造を示すブロック図である。同図の無線プロトコル階層は、使用者端末とＵＴＲＡＮに対（pair）として存在して、無線区間のデータ伝送を担当する。
【００２１】
第１階層であるＰＨＹ階層は、様々な無線伝送技術を用いてデータを無線区間に伝送する役割を担当し、無線区間の信頼性あるデータＰＨＹ階層は、上位階層であるＭＡＣ階層と伝送チャネル（Transport Channel）を通じて連結されている。
【００２２】
第２階層には、ＭＡＣ、ＲＬＣ、ＰＤＣＰ及びＢＭＣ階層が存在する。
【００２３】
ＭＡＣ階層は、様々な論理チャネル（Logical Channel）を様々な伝送チャネルにマッピングさせる役割を果たし、また、多数の論理チャネルを一つの伝送チャネルにマッピングさせる論理チャネル多重化（Multiplexing）の役割も果たす。ＭＡＣ階層は、上位階層であるＲＬＣ階層とは論理チャネル（LogicalChannel）で連結されており、論理チャネルは、大きく、伝送される情報の種類によって、制御平面（Control Plane）の情報を伝送する制御チャネル（ControlChannel）と、使用者平面（User Plane）の情報を伝送するトラフィックチャネル（Traffic Channel）とに区分される。
【００２４】
ＲＬＣ階層は、各無線ベアラ（Radio Bearer；RB）に対するＱｏＳ保障とそれによるデータの伝送を担当し、その詳細な内容は後述する。
【００２５】
ＢＭＣ（Broadcast/MulticastControl）階層は、ＲＬＣ階層の上位に存在しながらセル放送メッセージ（Cell Broadcast Message）をスケジューリングし、特定セルに位置している使用者端末に放送する機能を果たす。ＰＤＣＰ階層は、ＲＬＣ階層の上位に位置して、ＩＰｖ４やＩＰｖ６のようなＩＰパケットを用いて伝送されるデータが、相対的に帯域幅の小さい無線区間で効率的に伝送されるようにする。
【００２６】
第３階層に位置しているＲＲＣ（Radio Resource Control；無線資源制御）階層は、制御平面でのみ定義され、ＲＢの設定、再設定及び解除と関連して第１及び第２階層のパラメータを制御し、論理チャネル、伝送チャネル及び物理チャネルの制御を担当する。
【００２７】
以下、本発明の実施例と密接に関連しているＲＬＣ階層について詳述する。
【００２８】
ＲＬＣ階層の基本機能は、各ＲＢのＱｏＳに対する保障とこれによるデータの伝送である。このＲＢサービスは、無線プロトコルの第２階層が上位に提供するサービスであるため第２階層全体がＱｏＳに影響を与えるが、なかでも特にＲＬＣ階層の影響が大きい。ＲＬＣ階層は、ＲＢ固有のＱｏＳを保障するためにＲＢごとに独立したＲＬＣ個体（Entity）を備えており、様々なＱｏＳを支援するために透明モード（Transparent Mode；以下、‘ＴＭ’という。）、無応答モード（UnacknowledgedMode；以下、‘ＵＭ’という。）及び応答モード（Acknowledged Mode；以下、‘ＡＭ’という。）の３種類のＲＬＣモードを提供する。このようなＲＬＣの３種類モードはそれぞれが支援するＱｏＳが異なることから、動作方法に差があり、その細部的な機能もまた異なっている。したがって、ＲＬＣは、その動作モード別に考慮される必要がある。
【００２９】
ＴＭ ＲＬＣは、ＲＬＣ ＰＤＵを構成するに当たり、上位から伝達されたＲＬＣＳＤＵ（Service Data Unit）にいかなるオーバーヘッドも追加しないモードである。すなわち、ＲＬＣがＳＤＵを透明（Transparent）に通過させることから、ＴＭＲＬＣといい、このような特性によって、使用者平面と制御平面において下記のような役割を果たす。
【００３０】
使用者平面では、ＲＬＣ内でのデータ処理時間が短いから、主として回線サービス領域（Circuit Service domain；以下、‘ＣＳドメイン’という。）の音声やストリーミングのような実時間回線データの伝送を担当し、制御平面では、ＲＬＣ内でのオーバーヘッドがないため、上りリンク（Uplink）の場合、不特定使用者端末からのＲＲＣメッセージに対する伝送を担当し、下りリンク（Downlink）の場合、セル内の全ての使用者端末に放送されるＲＲＣメッセージに対する伝送を担当する。
【００３１】
透明モードとは違い、ＲＬＣでオーバーヘッドが追加されるモードを不透明モード（Non-transparent mode）といい、ここには、伝送したデータに対する受信確認応答がないモード（ＵＭ）と、応答があるモード（ＡＭ）の２種類がある。
【００３２】
無応答モードＲＬＣは、各ＰＤＵごとに一連番号（Sequence Number；以下、‘ＳＮ’という。）を含むＰＤＵヘッダを添付して伝送することによって、どのＰＤＵが伝送中に消失されたかを受信側が確認できるようにする。このような機能によって無応答モードＲＬＣは、使用者平面で放送／マルチキャストデータの伝送やパケットサービス領域（PacketService domain；以下、‘ＰＳドメイン’という。）の音声（例：ＶｏＩＰ）やストリーミングのような実時間パケットデータの伝送を担当する。また、制御平面では、セル内の特定使用者端末または特定使用者端末グループに伝送するＲＲＣメッセージのうち、受信確認応答が要らないＲＲＣメッセージの伝送を担当する。
【００３３】
応答モードＲＬＣは、無応答モードＲＬＣと同様に、ＰＤＵ構成においてＳＮを含むＰＤＵヘッダを添付してＰＤＵを構成するが、無応答モードＲＬＣとは違い、伝送されたＰＤＵに対して受信側が応答（Acknowledgement）をする。応答モードＲＬＣで受信側が応答をする理由は、自身が受信できなかったＰＤＵに対して送信側が再伝送（Retransmission）をするように要求するためである。したがって、応答モードＲＬＣは、再伝送を通じて誤り無し（error-free）データの伝送を保障することに目的があり、このような目的から、応答モードＲＬＣは、使用者平面で主としてＰＳドメインのＴＣＰ／ＩＰのような非実時間パケットデータの伝送を担当し、制御平面では、セル内の特定使用者端末に伝送するＲＲＣメッセージのうち、受信確認応答を必ず必要とするＲＲＣメッセージの伝送を担当する。
【００３４】
方向性の面からみると、ＴＭと無応答モードＲＬＣは、単方向（uni-directional）通信に使われるのに対し、応答モードＲＬＣは受信側から所定のフィードバック（feedback）が行なわれるため、両方向（bi-directional）通信に使われる。このような両方向通信は主として点対点（point-to-point）通信で使用されるため、応答モードＲＬＣは専用論理チャネルのみを使用する。
【００３５】
また、構造的な面からみると、ＴＭと無応答モードＲＬＣでは、一つのＲＬＣ個体が送信側または受信側のいずれか一方にのみ該当するが、応答モードＲＬＣは、一つのＲＬＣ個体中に送信側と受信側が両方とも存在する。一方、応答モードＲＬＣは、再伝送管理のために送受信バッファーの他に再伝送バッファーを備えており、流れ制御のために送受信ウィンドウを使用する。
【００３６】
応答モードＲＬＣの送信側は、ポーリング（Polling）を通じてピア（peer）ＲＬＣ個体の受信側に状態情報を要求し、応答モードＲＬＣの受信側は、ピアＲＬＣ個体の送信側に状態報告メッセージ（statusreport）を伝送して、自身のデータ状態を報告する。この状態報告メッセージは、状態ＰＤＵ（status PDU）の形態で伝送され、データ伝送の効率を高めるべく、データＰＤＵ内に状態ＰＤＵを挿入（Piggyback）して伝送する。
【００３７】
その他、応答モードＲＬＣ個体が動作過程で重大な誤りを発見した場合、相手側の応答モードＲＬＣ個体に全ての動作及びパラメータの再設定を要求するリセットＰＤＵ（Reset PDU）と、このようなリセットＰＤＵの応答に用いられるリセット応答ＰＤＵ（Reset Ack PDU）もある。また、これらの機能を支援すべく、応答モードＲＬＣには様々なプロトコルパラメータ、状態変数及びタイマーも必要となる。上記の状態ＰＤＵ、ピギーバック状態ＰＤＵ、リセットＰＤＵ、リセット応答ＰＤＵなどのように、応答モードＲＬＣでデータ伝送の制御のために用いられるＰＤＵを制御ＰＤＵ（ControlPDU）と呼び、使用者データ（UserData）を伝達するために用いられるＰＤＵをデータＰＤＵ（Data PDU）と呼ぶ。
【００３８】
このような制御ＰＤＵのうち状態ＰＤＵ（status PDU）の構造を、図３を参照しつつ詳細に説明する。
【００３９】
Ｄ／Ｃフィールド３１は、ＰＤＵがデータＰＤＵかあるいは制御ＰＤＵかを区分し、ＰＤＵｔｙｐｅフィールド３２は、当該ＰＤＵが状態ＰＤＵ、ピギーバック状態ＰＤＵ、リセットＰＤＵ、リセット応答ＰＤＵのいずれであるかを明示する。状態ＰＤＵは、多数のＳＵＦＩ（Super Field）３３−１，…，３３−ｋを含む。ＳＵＦＩは、受信側にどんな応答モードＲＬＣ ＰＤＵが到着したか、また、どんなＡＭ ＲＬＣＰＤＵが到着しなかったかなどの情報を知らせたり、送信側がどのＲＬＣ ＳＤＵを削除してそれ以上伝送しないかを知らせる。ＳＵＦＩは、種類、長さ、値の３部分からなる。状態ＰＤＵの大きさは可変的であるが、状態ＰＤＵが伝送される論理チャネルの最も大きいＲＬＣＰＤＵの大きさに制限される。
【００４０】
図４は、本発明の一実施例による状態報告メッセージ伝送方法を示すフローチャートであり、受信側ＲＬＣ階層から送信側に伝送された多数のデータブロック、すなわち、多数のＲＬＣＰＤＵに対する受信状態情報を、送信側に伝送する過程を示している。受信状態情報は、送信側から伝送された各ＲＬＣ ＰＤＵが受信側に成功的に伝送されたか否かに関する情報である。以下では、‘送信側’という用語は、多数のＲＬＣＰＤＵを送信する側面として用いられたし、‘受信側’という用語は、送信側から伝送された多数のＲＬＣ ＰＤＵを受信する側面として用いられた。
【００４１】
図４を参照すると、受信側のＲＬＣ階層で所定イベントが発生すると、一つの状態報告メッセージの伝送をトリガリングする［Ｓ４１］。例えば、送信側からポーリング（Polling）を通じて状態報告を行なうように指示された場合、または、上位階層から送信側に状態報告メッセージを伝送するという指示を受けた場合に、受信側のＲＬＣ階層は一つの状態報告メッセージの伝送をトリガリングする。この状態報告メッセージの伝送をトリガリングする所定イベントは、上記した例だけでなく、他の例もあり得る。
【００４２】
状態報告がトリガリングされた場合、受信側のＲＬＣ受信バッファー状態に基づいて送信側に伝送する受信状態情報を一つの状態ＰＤＵに含める場合、その大きさが既に設定された最大許容値より大きいか否か判断する［Ｓ４２］。最大許容値は、受信側のＭＡＣ階層によって決定されてＲＬＣ階層に通報されることができる。このＭＡＣ階層は、送信側と受信側間のチャネル状態を考慮して最大許容値を可変的に決定できる。例えば、チャネル状態が良好な場合には最大許容値を大きく設定することによって、ＲＬＣ階層が生成できる一つの状態ＰＤＵの大きさを相対的に大きくすることができ、チャネル状態がよくない場合には、最大許容値を小さく設定することによって、状態ＰＤＵの大きさを相対的に小さくすることができる。最大許容値は、上位階層や送信側から指示されることも可能である。
【００４３】
送信側に伝送する受信状態情報を一つの状態ＰＤＵに含める場合、その大きさが既に設定された最大許容値よりも大きい場合に、受信側のＲＬＣ階層は、送信側に伝送する一つの状態報告メッセージを二つ以上の状態ＰＤＵで構成する［Ｓ３４］。すなわち、送信側に伝送する受信状態情報を二つ以上に分割して、それぞれを含む二つ以上の状態ＰＤＵを構成することで、各状態ＰＤＵの大きさを最大許容値よりも小さくする。送信側に伝送する受信状態情報を一つの状態ＰＤＵに含める場合、その大きさが既に設定された最大許容値より小さい場合に、受信側のＲＬＣ階層は、送信側に伝送する一つの状態報告メッセージを一つの状態ＰＤＵにより構成する［Ｓ４４］。Ｓ４３またはＳ４４段階で生成された各状態ＰＤＵは、送信側に伝送される［Ｓ４５］。
【００４４】
図５は、本発明の一実施例によって一つの状態報告メッセージを二つ以上の状態ＰＤＵで構成する場合、各状態ＰＤＵのデータフォーマットの一例を示す図である。
【００４５】
図３の一般的な状態ＰＤＵと比較して、図５の状態ＰＤＵには、‘ｓｅｔＩＤ’フィールド、‘ＳＮ’フィールド及び‘Ｌ’フィールドがさらに含まれることがわかる。図５で‘ＰＤＵ ｔｙｐｅ’フィールドには、該当の状態ＰＤＵを他の種類の制御ＰＤＵと区別するための識別情報が含まれる。または、‘ＰＤＵｔｙｐｅ’フィールドに、多数の状態ＰＤＵにより一つの状態報告メッセージを構成する場合の各状態ＰＤＵを、一つの状態ＰＤＵにより一つの状態報告メッセージを構成する場合の状態ＰＤＵと区別するための情報が含まれることもできる。すなわち、一つの状態報告メッセージが一つの状態ＰＤＵで構成される場合の状態ＰＤＵと、一つの状態報告メッセージが多数の状態ＰＤＵで構成される場合の状態ＰＤＵを互いに異なるＰＤＵタイプとして区別するわけである。
【００４６】
‘ｓｅｔ ＩＤ’フィールドは、該当の状態報告メッセージを他の状態報告メッセージと区別するための識別情報を含む。一つの状態報告メッセージが二つ以上の状態ＰＤＵで構成される場合、各状態ＰＤＵの‘ｓｅｔＩＤ’フィールドは同一の識別情報を含むことによって、該当の状態ＰＤＵが同一の状態報告メッセージに含まれることを知らせることができる。例えば、受信側のＲＬＣ階層から多数の状態報告メッセージを送信側に伝送する場合、伝送順序によって各状態報告メッセージに一連番号（sequence number）を付与し、各状態報告メッセージに含まれる状態ＰＤＵの‘ｓｅｔ ＩＤ’フィールドに該当の一連番号を含めて伝送する。この時、一つの状態報告メッセージを多数の状態ＰＤＵで構成する場合、各状態ＰＤＵの‘ｓｅｔＩＤ’フィールドには同一の一連番号が含まれる。
【００４７】
‘ＳＮ’フィールドには、該当の状態ＰＤＵの一連番号が含まれる。例えば、一つの状態報告メッセージが三つの状態ＰＤＵで構成される場合、各状態ＰＤＵの‘ＳＮ’フィールドには０、１、２順の一連番号が含まれる。‘Ｌ’フィールドは、該当の状態ＰＤＵが一つの状態報告メッセージに属する最後の状態ＰＤＵであるか否かを表示する情報を含む。この三つの状態ＰＤＵで一つの状態報告メッセージを構成する例において、１番及び２番目の状態ＰＤＵの‘Ｌ’フィールドには、該当の状態ＰＤＵが一つの状態報告メッセージに属する最後の状態ＰＤＵでないことを表示する情報が含まれ、３番目の状態ＰＤＵの‘Ｌ’フィールドには、該当の状態ＰＤＵが一つの状態報告メッセージに属する最後の状態ＰＤＵであることを表示する情報が含まれる。
【００４８】
送信側のＲＬＣ階層で一つの状態報告メッセージに含まれる多数の状態ＰＤＵを受信する場合、送信側のＲＬＣ階層は、各状態ＰＤＵの‘ｓｅｔＩＤ’フィールドに含まれた情報を通じて該当の状態ＰＤＵが一つの状態報告メッセージに属することがわかり、‘ＳＮ’フィールド及び‘Ｌ’フィールドに含まれた情報を通じて当該一つの状態報告メッセージに属する全ての状態ＰＤＵが受信されたか否かが判断できる。したがって、送信側のＲＬＣ階層は、受信側のＲＬＣ階層が伝送した受信状態情報を正確に獲得することができる。
【００４９】
図６は、本発明の他の実施例による状態報告メッセージ伝送過程を示すフローチャートである。以下では、図４及び図５の実施例とは違い、‘送信側’は、状態ＰＤＵを送信する側面として用いられた用語で、‘受信側’は、状態ＰＤＵを受信する側面として用いられた用語である。
【００５０】
分割されたＲＬＣ状態報告メッセージに識別情報追加
状態報告をトリガリングする所定イベントが発生した時、受信側に伝送すべき受信状態情報の大きさが既に設定された許容限界値を超過する場合、送信側のＲＬＣ階層は、一つの状態報告メッセージを二つ以上の状態ＰＤＵで構成する（Ｓ１０１）。送信側のＲＬＣ階層は、各状態ＰＤＵに識別情報を追加する（Ｓ１０２）。
【００５１】
この識別情報は、該当のＲＬＣ状態報告メッセージを他のＲＬＣ状態報告メッセージと区別するための識別子（status PDU set identifier）、該当の状態ＰＤＵの一連番号、及び該当の状態ＰＤＵが状態報告メッセージに属する最後の状態ＰＤＵであることを表す指示子（finalstatus PDU indicator）のうち、少なくとも一つを含む。この識別情報は、図３の状態ＰＤＵ構造でＳＵＦＩ（Super Field）３３−１，…，３３−ｋに添付されても良く、別の新しいフィールドに追加されても良い。
【００５２】
具体的に、一つの状態報告メッセージが多数の状態ＰＤＵで構成される場合、一つの状態報告メッセージに属するそれぞれの状態ＰＤＵは、同一の値に設定された状態ＰＤＵセット識別子を含むことができる。したがって、送信側は、ＲＬＣ状態報告メッセージに関連した状態ＰＤＵの状態ＰＤＵセット識別子を同一の値に設定し、また、ＲＬＣ状態報告メッセージを受信する側は、受信した状態ＰＤＵに対して同一の状態ＰＤＵセット識別子を持つ状態ＰＤＵ同士をまとめて処理する。すなわち、受信側は、同一の値に設定された状態ＰＤＵセット識別子を持つ状態ＰＤＵを併合処理して、状態報告メッセージを復元する。
【００５３】
また、同一の状態ＰＤＵセット識別子を持つ状態ＰＤＵの処理順序、または、情報の順序を決定する目的で、それぞれの状態ＰＤＵは一連番号を含むことができる。すなわち、一つの状態報告メッセージが多数の状態ＰＤＵからなる場合、それぞれの状態ＰＤＵの構成順序または生成順序などの情報を表現するために一連番号が用いられる。したがって、一つの状態報告メッセージに属する状態ＰＤＵが、伝送中に順序が変わって受信側に伝達されても、受信側はその一連番号を用いてそれぞれの状態ＰＤＵを再整列しそれを併合しすることで、元来の状態報告メッセージを復元できる。
【００５４】
また、状態報告メッセージを受信するＲＬＣ個体は、当該状態報告メッセージがいくつの状態ＰＤＵで構成されたかに関する情報を必要とする。この情報がないと、状態報告メッセージを受信するＲＬＣ個体は、一つのＲＬＣ状態報告メッセージに属する全ての状態ＰＤＵを受信したか否か確認できない。したがって、一つの状態報告メッセージが多数の状態ＰＤＵからなる場合、合計いくつの状態ＰＤＵに分割されたか、または、どの状態ＰＤＵが状態報告メッセージの最後の部分であるかを知らせる情報が必要である。
【００５５】
一つの状態報告メッセージに属する最後の状態ＰＤＵであることを表示すべく、それぞれの状態ＰＤＵは、最終状態ＰＤＵ指示子（final status PDU indicator）を含むことができる。したがって、送信側のＲＬＣ個体は、最後に伝送する状態ＰＤＵの最終状態ＰＤＵ指示子に最後のユニットであることを設定し、残りの状態ＰＤＵに対しては最終状態ＰＤＵ指示子を設定しない（クリアする）ことが好ましい。
【００５６】
受信側のＲＬＣ個体では、受信した状態ＰＤＵに対して最終状態ＰＤＵ指示子を検査した後、最終状態ＰＤＵ指示子が設定された状態ＰＤＵを、該当のＲＬＣ状態報告メッセージの最後の部分と見なす。この時、該当の状態報告メッセージに属する全ての状態ＰＤＵを受信した場合、受信側は、受信した状態ＰＤＵを再整列及び併合して一つの状態報告メッセージを構成する。
【００５７】
受信結果通報及び再伝送
受信側は、一つのＲＬＣ状態報告メッセージを構成する各状態ＰＤＵに対する受信結果を、送信側に通報することができる。送信側に通報される内容は、特定状態ＰＤＵが成功的に受信されたか、または、その受信に失敗したかである。ここで、受信失敗は、特定状態ＰＤＵが受信されたものの正常に受信されなかった場合と、特定状態ＰＤＵが全く受信されなかった場合の両方を表しても良く、両場合をそれぞれ区分して表しても良い。
【００５８】
また、受信成功とは、受信された状態ＰＤＵを用いてＲＬＣ状態報告メッセージを成功的に復元した場合、または、一つのＲＬＣ状態報告メッセージに該当する全ての状態ＰＤＵを正常に受信した場合を表す。一方、受信側は、受信に失敗したか正常に受信できなかった状態ＰＤＵに対して送信側に再伝送を要請することができる。
【００５９】
送信側は、受信側の再伝送要請があると、該当の状態ＰＤＵを再伝送する。ただし、同一の状態ＰＤＵに対する再伝送が無制限に行なわれると通信効率が低下するので、この再伝送はあらかじめ設定された回数以下に制限しておくことができる。したがって、特定状態ＰＤＵに対する再伝送が指定回数以上行なわれたにもかかわらず再び受信側から一部の状態ＰＤＵを正しく受信できなかったという情報を受信した場合には、それ以上状態ＰＤＵを伝送しない。
【００６０】
送信側におけるハンドオーバーの制限
送信側は、一つの状態報告メッセージを構成する複数の状態ＰＤＵのうちのいずれか一つを最初に伝送すると同時に、該当のＲＬＣ状態報告メッセージに対する伝送タイマー（RLC status transmission timer）を駆動する（Ｓ１０３）。送信側が使用者端末であり、ハンドオーバー命令を受信した状況であれば、一定時間内にハンドオーバーを行なわないと円滑な通信が不可能なので、状態報告メッセージも同様に一定時間内に伝送完了することが要求される。
【００６１】
もし、送信側が受信側から特定状態報告メッセージに属する全ての状態ＰＤＵに対して成功的な受信を通報を受けると、ハンドオーバー命令を伝送した第１領域（セルまたはセクター）に対する接続を切り、新しい第２領域への接続を始める。この場合、第１領域の基地局（受信側）は、受信した状態報告メッセージに基づいて端末がまだ受信できなかったＲＬＣＳＤＵと使用者端末に一度も伝送されなかったＲＬＣ ＳＤＵを、第２領域の基地局に伝達する。
【００６２】
しかし、現在領域で状態報告メッセージの伝送を完了できない場合であっても、円滑な通信の維持のためにハンドオーバーを強行する必要があるので、特定状態報告メッセージの全ての状態ＰＤＵに対して成功的な受信の通報を受けなかったとしても、伝送タイマーがあらかじめ設定された時間に到達すると（Ｓ１０４）、ハンドオーバー命令を受信した（Ｓ１０５）第１領域（セルまたはセクター）に対する接続を切り、新しい第２領域への接続を始める（Ｓ１０６）。この場合、第１領域の基地局（受信側）は、受信した状態報告メッセージに基づいて端末が成功的に受信できなかったり未受信したＲＬＣＳＤＵを第２領域の基地局に伝達する。
【００６３】
受信側におけるハンドオーバーの制限
受信側は、状態報告メッセージに属する全ての状態ＰＤＵが到着するまで無制限に待つことはできない。したがって、受信側は、送信側から一つの状態報告メッセージを構成する状態ＰＤＵのうちのいずれか一つを最初に受信すると同時に、該当の状態報告メッセージに対する再結合タイマー（RLC status reassembly timer）を駆動する（Ｓ２０１）。
【００６４】
受信側は、再結合タイマーが動作している間に限ってそれぞれの状態ＰＤＵに対する受信成功／失敗情報を送信側に伝送する。もし、再結合タイマーがあらかじめ設定された時間に到達する前に一つの状態報告メッセージに該当する全ての状態ＰＤＵを正常に受信すると、受信側は、再結合タイマーを停止させ、該当の状態報告メッセージを元の状態に復旧する（Ｓ２０５）。しかし、一つの状態報告メッセージに該当する全ての状態ＰＤＵを正常に受信する前に再結合タイマーがあらかじめ設定された時間に到達した場合には、現在まで受信した状態ＰＤＵを基盤にして該当の状態報告メッセージを復旧する。
【００６５】
一方、受信側が基地局であり、送信側たる使用者端末にハンドオーバー命令が下された状況なら、使用者端末は、一定時間内にハンドオーバーを行なわないと円滑な通信が不可能なため、状態報告メッセージも同様に一定時間内に伝送完了することが要求される。
【００６６】
もし、基地局が再結合タイマーの終了前に一つの状態報告メッセージに対する全ての状態ＰＤＵを成功的に受信すると、使用者端末との接続を解除し、ハンドオーバーを進行する。この場合、基地局は、受信した状態報告メッセージに基づいて端末がまだ受信できなかったＲＬＣＳＤＵ、そして端末に一度も伝送されなかったＲＬＣ ＳＤＵを新しい領域の基地局に伝達する。
【００６７】
送信側から一つの状態報告メッセージに対する全ての状態ＰＤＵを成功的に受信できなかったにもかかわらず再結合タイマーが終了し（Ｓ２０２）、ハンドオーバー命令が下された場合（Ｓ２０３）、ハンドオーバーは同様に行なわれる（Ｓ２０４）。この時、基地局は、受信したＲＬＣ状態報告メッセージに基づいて端末が成功的に受信できなかったり未受信したＲＬＣＳＤＵを新しい領域の基地局に伝達し、第２領域で残りの伝送が行なわれるようにする。
【００６８】
図７は、状態報告メッセージの送信側を使用者端末とする時、該使用者端末の主要構成を示すブロック図である。ただし、これは一例に過ぎず、使用者端末を受信側のＲＬＣ状態報告メッセージの受信側にしても良い。
【００６９】
使用者端末１００は、所望の機能を選択したり情報を取り込むための入力部１０１と、使用者端末１００を運用するための様々な情報を表示する表示部１０３と、使用者端末１００が動作するのに必要な各種プログラム及び受信側に伝送するデータを保存するメモリー部１０５と、外部信号を受信し、受信側にデータを伝送するための無線通信部１０７と、デジタル音声信号をアナログ音声信号に変換し増幅してスピーカーＳＰＫから出力したり、マイクＭＩＣからの音声信号を増幅してデジタル信号に変換する音声処理部１０９と、使用者端末１００の全体駆動を制御する制御部１１１と、を含んでなる。
【００７０】
ここで、制御部１１１は、所定大きさ以上の状態報告メッセージを二つ以上のＲＬＣ状態ＰＤＵで構成し、状態ＰＤＵのそれぞれに識別情報を添付する機能をさらに含む。また、無線通信部１０７は、状態ＰＤＵを送信側に伝送する。
【００７１】
使用者端末１００は、状態報告メッセージに対する最初のデータユニットが伝送されると同時に駆動を開始する伝送タイマー（transmission timer）（図示せず）をさらに含むことができ、この場合、制御部１１１は、ハンドオーバー命令が下された状況で伝送タイマーがあらかじめ設定された時間を経過すると、送信側から状態報告メッセージの全てのデータユニットに対して正常受信の通報を受けたか否かにかかわらずにハンドオーバーを行なう。
【００７２】
ＲＬＣ状態報告メッセージの受信側を基地局（図示せず）とする時、基地局は、基地局が動作するのに必要な各種プログラム及び送信側に伝送するデータを保存するメモリー部（図示せず）と、外部信号を受信し、送信側にデータを伝送するための無線通信部（図示せず）と、基地局の全体駆動を制御する制御部（図示せず）と、を含んでなる。
【００７３】
無線通信部は、所定大きさ以上の状態報告メッセージを構成する二つ以上の状態ＰＤＵを受信する。また、制御部は、受信したデータ状態ＰＤＵに含まれた識別情報を用いて状態報告メッセージを復元する。
【００７４】
この受信装置は、状態報告メッセージに対する最初の状態ＰＤＵを受信すると同時に駆動を開始する再結合タイマー（reassemble timer）をさらに含むことができ、この場合、制御部は、受信側にハンドオーバー命令を下した状況で再結合タイマーがあらかじめ設定された時間を経過すると、受信側から状態報告メッセージの全てのデータユニットを成功的に受信したか否かにかかわらずにハンドオーバーを行なう。
【００７５】
一方、本発明において送信側のＲＬＣ個体は、特定状態報告メッセージを多数の状態ＰＤＵで構成する際に、それぞれの状態ＰＤＵが個別に解釈されるように構成しても良く、個別には解釈されないように構成しても良い。
【００７６】
前者の場合、一つの状態報告メッセージを構成するそれぞれの状態ＰＤＵは、他の状態ＰＤＵがなくても独立して解釈可能である。すなわち、受信側のＲＬＣ個体は、一つのＲＬＣ状態報告メッセージに属する全ての状態ＰＤＵを受信しなくても、それぞれの状態ＰＤＵに含まれた部分的な制御情報を処理することができる。
【００７７】
後者の場合、一つの状態報告メッセージを構成するそれぞれの状態ＰＤＵは、他の状態ＰＤＵがないと個別的な解析が不可能である。すなわち、受信側のＲＬＣ個体は、一つの状態報告メッセージに属する全ての状態ＰＤＵを受信できないと、それぞれの状態ＰＤＵに含まれた制御情報を復元することも、それを利用することもできない。
【００７８】
本発明によると、多数に分割されたメッセージに含まれた識別情報を用いて応答モードのＲＬＣ個体の送信側と受信側間で大きい大きさの状態情報メッセージを安定して伝送することができる。また、送信側及び／または受信側に備えられたタイマーを用いて信頼性ある状態情報伝送と円滑なハンドオーバー実行とが適切に調和されるようにすることができる。
【００７９】
以上の実施例は、本発明の構成要素と特徴が所定の形態で結合されたものである。各構成要素または特徴は別の明示的な言及がない限り選択的なものとして考慮されるべきである。各構成要素または特徴は、他の構成要素や特徴と結合しない形態で実施されても良く、一部構成要素及び／または特徴を結合させて本発明の実施例を構成しても良い。本発明の実施例で説明される動作の順序は変更可能である。ある実施例の一部構成や特徴は他の実施例に含まれることができ、または、他の実施例の対応する構成または特徴と取り替えられることができる。また、特許請求の範囲で明示的な引用関係のない請求項を結合させて実施例を構成したり、出願後の補正により新しい請求項として含めることもできることは明らかである。
【００８０】
本文書において本発明の実施例は送信側及び受信側間のデータ送受信関係を中心に説明された。本文書で送信側または受信側がネットワークである場合に、送信側または受信側により行なわれると説明された特定動作は、場合によっては基地局またはその上位ノード（upper node）により行なわれることができる。すなわち、基地局を含む多数のネットワークノード（network nodes）からなるネットワークで端末との通信のために行なわれる様々な動作は、基地局または基地局以外の他のネットワークノードにより行なわれることができるということは自明である。‘基地局’は、固定局（fixedstation）、Node B、eNode B（eNB）、アクセスポイント（access point）などの用語に替えることができる。また‘端末’はＵＥ（UserEquipment）、ＭＳ（Mobile Station）、ＭＳＳ（Mobile Subscriber Station）などの用語に替えることができる。
【００８１】
本発明による実施例は、様々な手段、例えば、ハードウェア、ファームウェア（firmware）、ソフトウェアまたはそれらの結合などにより具現されることができる。ハードウェアによる具現の場合、本発明の一実施例による無線通信システムにおけるページングメッセージ送受信方法は、一つまたはそれ以上のＡＳＩＣｓ（applicationspecific integrated circuits）、ＤＳＰｓ（digital signal processors）、ＤＳＰＤｓ（digitalsignal processing devices）、ＰＬＤｓ（programmable logic devices）、ＦＰＧＡｓ（fieldprogrammable gate arrays）、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサなどにより具現されることができる。
【００８２】
ファームウエアやソフトウェアによる具現の場合、本発明の一実施例による無線通信システムにおけるページングメッセージ送受信方法は、以上で説明された機能または動作を行なうモジュール、手順、関数などの形態で具現されることができる。ソフトウェアコードはメモリユニットに記憶されてプロセッサーにより駆動されることができる。このメモリユニットはプロセッサ内部または外部に位置し、公知の様々な手段によりプロセッサとデータを交換することができる。
【００８３】
本発明は、本発明の精神及び必須特徴を逸脱しない範囲で他の特定の形態に具体化されることができるということが当業者には自明である。したがって、上記の詳細な説明は、あらゆる面において制限的なものとして解釈されてはならず、例示的なものとして考慮されるべきである。本発明の範囲は、添付した請求項の合理的解釈によって決定されなければならず、本発明の等価的範囲内における変更はいずれも本発明の範囲に含まれる。
【産業上の利用可能性】
【００８４】
本発明は、移動通信システムや無線インターネットシステムなどのような無線通信システムで利用されることができる。
【図１】
2010511320.tif 000003
【図２】
2010511320.tif 000004
【図３】
2010511320.tif 000005
【図４】
2010511320.tif 000006
【図５】
2010511320.tif 000007
【図６】
2010511320.tif 000008
【図７】
2010511320.tif 000009
【国際調査報告】
2010511320.tif 000010
2010511320.tif 000011