(58)【調査した分野】(Int.Cl.,DB名)
前記受信部は、前記少なくとも一つのBSRが正規BSRであり、前記少なくとも一つの正規BSRがトリガーされ、取り消されない場合に前記SRを受信することを特徴とする請求項10に記載の移動通信システム。
【背景技術】
【0002】
一般的に、移動通信システムは、ユーザの移動性を確保しつつ通信サービスを提供するためのものである。このような移動通信システムは、飛躍的な技術発展にこたえて音声通信だけではなく高速のデータ通信サービスも提供することができる段階にいたった。
【0003】
最近では、次世代移動通信システムの中の1つとして3GPP(3rd Generation Partnership Project)におけるロングタームエボルーション(Long Term Evolution:LTE)に対する標準化作業が進んでいる。LTEは、2010年ほどを商用化目標にし、現在使用可能なデータ送信率より高い最大100Mbps程度の送信速度を有する高速のパケット基盤通信を実現することができる技術である。このような高速の通信をサポートするために、ネットワーク構造を簡単にすることにより通信リンクでのノードの数を減少させる方法及び可能であれば無線プロトコルを無線チャネルに最大に近接させる方法のような様々な方法が論議されている。
【0004】
一方、音声サービスとは異なり、データサービスにおいて、1つの端末に割り当てられる無線リソースの量は、送信データの量及びチャネル状況に基づいて決定される。したがって、移動通信システムのような無線通信システムは、スケジューラが送信リソースの量、チャネルの状況、及び送信データの量などを考慮して送信リソースを割り当てるように管理する。これは、次世代移動通信システムの中の1つであるLTEでも同様に行われ、このためには、基地局に位置したスケジューラは、無線送信リソースを管理し、これを端末に適切に割り当てる。
【0005】
移動通信システムのような無線通信システムにおいて、データ送信の方向に基づいてダウンリンク送信及びアップリンク送信に区分される。ダウンリンク送信は、基地局から端末への送信を意味し、アップリンク送信は、端末から基地局への送信を意味する。
【0006】
ダウンリンク送信の場合に、基地局が現在のチャネル状況、割り当て可能な無線リソースの量、及び送信データの量を正確に把握することができるので、基地局のスケジューラは、この情報に基づいて円滑にスケジューリングを実行することができる。しかしながら、アップリンク送信の場合に、基地局のスケジューラは、端末の現在のバッファ状態を正確に把握することができない状態で実行され得るために、無線リソースを端末に適切に割り当て得ないという観点でアップリンク送信に難しさがある。
【0007】
このようなアップリンク送信の難しさを解決するためには、LTEシステムにおいて、端末は、“バッファ状態報告制御情報(Buffer Status Report Control Element)”を使用して現在の端末のバッファ状態を基地局に報告する。
【0008】
このバッファ状態報告制御情報は、特定の条件が満足する場合に、端末によって基地局に送信されるように設定される。例えば、優先順位が高い送信データが新たに発生する場合及び所定のタイマーが満了する場合などがある。
【0009】
優先順位が高い新たなデータが発生した場合のバッファ状態報告(Buffer Status Report:以下、“BSR”と称する。)を正規BSRと称する。可能であれば正規BSRを迅速に基地局に送信するためには、端末は、正規BSRが発生する時、専用スケジューリング要請(Dedicate Scheduling Request:以下、“D−SR”と称する。)と呼ばれる1ビット情報を基地局に送信することによりBSR送信のための送信リソースを要請する。すなわち、D−SRは、正規BSRを送信するための無線リソースを基地局に要請するための用途として使用される。
【発明を実施するための形態】
【0018】
以下、本発明の好適な実施形態について添付図面を参照しながら詳細に説明する。図面における同様な構成要素に対しては、他の図面に表示されても、同様な参照番号及び符号を付けてあることに注意されたい。下記の説明において、本発明の要旨のみを明瞭にするために、関連した公知の機能や構成についての具体的な説明は、適宜省略する。
【0019】
本発明は、端末がD−SRを送信するにあたり不必要な誤動作を防止する方法及び装置を提供する。
【0020】
本発明の詳細な説明に先立って、LTE移動通信システムについて簡略に説明する。
図1は、LTE移動通信システムの構造を説明する図である。
【0021】
図1を参照すると、LTE移動通信システムの無線アクセスネットワークは、次世代基地局(Evolved Node B:以下、“ENB”又は“Node B”と称する。)105,110,115,及び120と移動性管理エンティティ(Mobility Management Entity:MME)125とサービングゲートウェイ(Serving-Gateway:S−GW)130とを含む。ユーザ端末(User Equipment:以下、“UE”と称する)135は、対応する端末が接続されたENB105及びS−GW130を通してネットワークにアクセスする。
【0022】
ENB105乃至120は、レガシーUMTSシステムのノードB(Node B)に対応する。ENB105は、無線チャネルを介してUE135に接続され、レガシーノードBより複雑な機能を実行する。LTEは、インターネットプロトコルを通したVoIP(Voice over IP)のようなリアルタイムサービスを含むすべてのユーザトラフィックが共用チャネル(shared channel)を通してサービスされるので、UEの状態情報を収集することによりスケジューリングを実行する。このようなスケジューリング機能は、ENB105乃至120により担当される。
【0023】
1つのENBは、通常、複数のセルを制御する。最大100Mbpsの送信速度を実現するために、LTEは、最大20MHzの帯域幅で直交周波数分割多重(Orthogonal Frequency Division Multiplexing:以下、“OFDM”と称する)方式を無線接続技術として使用する。また、LTEは、端末のチャネル状態に基づいて変調方式(modulation scheme)及びチャネル符号化率(channel coding rate)を適応的に決定する適応変調符号化(Adaptive Modulation & Coding:以下、“AMC”と称する)方式を適用する。
【0024】
S−GW130は、データベアラを提供する装置であり、MME125の制御の下にデータベアラを生成するか又は除去する。無線接続のための各種制御機能を担当する装置であるMME125は、複数の基地局に接続される。
【0025】
図2は、LTEシステムの無線プロトコルの構造を説明する図である。
図2を参照すると、LTEシステムの無線プロトコルは、パケットデータコンバージェンスプロトコル(Packet Data Convergence Protocol:以下、“PDCP”と称する)205及び240と、無線リンク制御(Radio Link Control:以下、“RLC”と称する)210及び235と、媒体アクセス制御(Medium Access Control:MAC)215及び230とを含む。PDCP205及び240は、IPヘッダーの圧縮/復元などの動作を実行し、RLC210及び235は、PDCPパケットデータユニット(Packet Data Unit:以下、“PDCP PDU”と称する)を適切なサイズで再構成することによりARQ動作などを実行する。MAC215及び230は、1つの端末に形成された様々なRLCレイヤー装置に接続され、RLC PDUをMAC PDUに多重化し、MAC PDUをRLC PDUに逆多重化する動作を実行する。物理(PHY)レイヤー220及び225は、上位レイヤーデータをOFDMシンボルへのチャネル符号化及び変調を行い、OFDMシンボルを無線チャネルを介して送信し、及び/又は無線チャネルを通して受信されたOFDMシンボルの復調及びチャネル復号化を行い、この復号化されたOFDMシンボルを上位レイヤーに送信する。
【0026】
図3は、LTE移動通信システムにおけるバッファ状態報告(BSR)及び専用スケジューリング要請(D−SR)を説明する図である。
【0027】
基地局310は、端末305のためのD−SR送信リソースを設定し得る。ここで使用される‘D−SR送信リソース’は、端末がD−SRを基地局に送信するために基地局が端末に割り当てるリソースを意味する。D−SR送信リソースは、所定の期間の間に基地局310により端末305に割り当てられ得る。したがって、ステップ315で、基地局310は、D−SR送信リソース設定情報を含む制御メッセージを端末305に送信する。この制御メッセージに基づいて、端末305は、端末305のためのD−SR送信リソースがどの送信リソースに設定されており、どのサブフレームでD−SR送信リソースが使用可能であるように設定されたかがわかる。
【0028】
ステップ320で、ステップ315の後の任意の時点で正規BSRが端末305にトリガーされる特定の状況を仮定する。ステップ325で、正規BSRがトリガーされた後にスケジューリング要請(Scheduling Request:SR)送信過程もトリガーされる。ここで使用される‘SR送信過程’は、端末がBSR送信用無線リソースの割り当てを基地局から受信するまでD−SRを基地局に送信する過程を意味する。すなわち、SR送信過程がトリガーされる場合に、端末305は、SR送信過程が取り消されるまでD−SRを基地局310に送信する。
【0029】
端末305は、ステップ315で受信した制御メッセージに基づいて自身のD−SR送信リソースに割り当てられたサブフレームを確認することができるので、この割り当てられたサブフレームでD−SRを送信する。端末305は、BSR送信用リソースの割り当てを受信するまでD−SRを基地局に反復して送信する。ステップ345で、端末305がBSR送信用リソースの割り当てを受信したものと仮定する場合に、端末305は、ステップ350で、BSR送信用リソースを用いてBSRを基地局310に送信する。
【0030】
このように、端末305は、BSRを基地局310に送信した後に、ステップ325でトリガーされたSR送信過程を取り消し、これ以上D−SRを送信しない。
【0031】
しかしながら、D−SR送信の間にアップリンク送信電力値が誤って設定されるなどの何らかの理由から、基地局310は、端末305が送信したD−SRを受信しない場合もある。この場合に、端末305は、D−SRを基地局310に反復して送信するので、端末305の電力消費及びアップリンク干渉を増加させるなどの問題が発生する。
【0032】
このような問題を解決するために、現在のLTE標準は、端末のD−SR送信回数を所定のしきい値dsr−transmax以下に限定されている。端末がD−SRをこのしきい値dsr−transmaxの回数だけ送信した後にも、BSR送信用リソースの割り当てを基地局から受信しない場合に、端末は、D−SR送信を中断し、BSR送信のためにランダムアクセス過程を開始する。
【0033】
端末がD−SRをしきい値dsr−transmaxだけ基地局に送信したとしても、基地局がアップリンクグラントを受信できなかった、すなわち、端末がBSR送信用リソースの割り当てを受信できなかったということは、端末のアップリンク送信の設定に深刻なエラーがあり得ることを示す。したがって、このような場合に、端末は、D−SR送信リソースを含む専用アップリンク送信リソースを解除する。以下では、説明の便宜上、端末がD−SRをしきい値dsr−transmaxの回数だけ基地局に送信したが、アップリンクグラントを基地局から受信できない場合を“D−SR送信失敗”と称する。
【0034】
端末は、D−SR送信が失敗したか否かを判定するために、パラメータSR_COUNTERが設定された所定のカウンターを運用する。SR_COUNTERの値は、SRがトリガーされる場合に0に初期化され、D−SRが送信される度に1ずつ増加する。SR_COUNTERがD−SR送信に対するしきい値dsr−transmaxに到達する場合に、端末は、D−SR送信失敗が発生したことを判定し、D−SR送信リソースを含む専用アップリンク送信リソースを解除し、ランダムアクセス過程を実行する。以下では、説明の便宜上、D−SR送信リソースを含む専用アップリンク送信リソースを解除し、ランダムアクセス過程を開始する一連の動作を“D−SR送信失敗後続手順”と称する。
【0035】
一方、現在のLTE標準において、端末は、dsr−transmax番目のD−SRを送信した後に、アップリンクグラントが受信されるか否かを確認せず即座にD−SR送信失敗後続手順を実行する。すなわち、最後のD−SRを送信した後に、端末は、基地局が最後のD−SRを受信し、アップリンクグラントを割り当てる前に、D−SR送信失敗後続手順を実行する。その結果、端末は、この送信された最後のD−SRに対する基地局からのアップリンクグラントを確認せずD−SR送信失敗後続手順を実行するので、この最後のD−SRの送信によって、不必要なリソースの浪費、アップリンク干渉の増加、及び端末の電力消費を引き起こす問題が発生し得る。このような問題点を
図4と関連してより詳細に説明する。
【0036】
図4は、本発明の第1の実施形態に関連した従来技術の問題点を示す図である。
図4において、1つの方形は、1msecのサブフレームを示す。端末に割り当てられたD−SR送信リソースのためのサブフレームは、矢印405、410、415、420、及び430で表示される。
【0037】
任意の時点でSR送信過程が端末でトリガーされると仮定する。
図4では、これを参照符号435で表した。このように、ステップ435でSR送信過程がトリガーされる場合に、ステップ440で、端末は、SR_COUNTERを0に初期化し、使用可能なD−SR送信リソースのために割り当てられたサブフレームまで待機する。
【0038】
ステップ445で、端末は、D−SR送信リソースとして使用可能であるように割り当てられたサブフレーム410でD−SR送信を実行するか否かを決定するために、SR_COUNTERを最大許容可能なD−SR送信回数dsr−transmaxと比較する。この比較の結果、SR_COUNTERがdsr−transmaxより小さい場合、すなわち、SR送信回数が最大許容可能なD−SR送信回数に到達しなかった場合に、ステップ450で、端末は、SR_COUNTERを1増加させ、ステップ455で、D−SRを送信する。
【0039】
このような方式で、端末は、SR送信過程が進行中にある場合に、D−SR送信リソースが使用可能なサブフレームごとにSR_COUNTERをdsr−transmaxと比較し、SR_COUNTERがdsr−transmaxより小さい場合には、SR_COUNTERを1増加させ、SRを送信する動作を繰り返す。例えば、dsr−transmaxが3に設定される場合に、対応する時点でのSR_COUNTERが2であるので、サブフレーム420でSRを送信し、SR_COUNTERを1増加させる。
【0040】
次のサブフレーム425では、SR_COUNTERが3であり、この時のSR_COUNTERの値がdsr−transmaxと同一であるので、端末は、SR_COUNTERがdsr−transmaxより大きいか又は同一である場合に、D−SR送信失敗後続手順、すなわち、D−SR送信リソースを解除し、BSR送信用リソースのためのランダムアクセスを実行する。すなわち、端末がサブフレーム420で送信したSRに応答する前にD−SR送信失敗後続手順を実行する。
【0041】
このような問題は、端末がD−SRを送信した後にこれに対する基地局の応答、すなわち、アップリンクグラントを受信するか否かを所定の期間の間待機することが好ましいが、上述した従来のLTE標準の動作で端末が最後のD−SRを送信した直後の次のサブフレームでD−SR送信失敗後続手順を即座に実行するために発生する。
【0042】
本発明の第1の実施形態は、
図4に関連して説明した問題点を解決するためのものである。従来では、D−SRを送信した後に、端末は、SR_COUNTERを増加させ、SR_COUNTERをdsr−transmaxと比較し、SR_COUNTERがdsr−transmaxより大きいか又は同一である場合にD−SR送信失敗後続手順を即座に実行する。
【0043】
しかしながら、本発明の第1の実施形態では、従来の方式とは異なり、端末は、D−SRの送信時点より所定の時間先立った時点でSR_COUNTERをあらかじめ増加させる。この後、端末は、SR_COUNTERをdsr−transmaxと比較し、この比較の結果、SR_COUNTERがdsr−transmaxより大きい場合に、D−SR送信失敗後続手順を実行する。このように、本発明の第1の実施形態は、D−SR送信失敗後続手順の開始時点を変更することにより上述した問題点を解決することができる。
【0044】
上述した本発明の第1の実施形態の動作によると、端末は、SR_COUNTER値がdsr−transmax値と同一となる時点ではD−SRを送信するが、D−SR送信失敗後続手順を開始しない。また、端末は、D−SR送信リソースのために使用可能な次のサブフレームより所定の時間先立った時点でSR_COUNTERを1増加させるので、SR_COUNTERがdsr−transmaxより大きい条件を満足させる。このようにすることにより、端末は、D−SRを送信せずD−SR送信失敗後続手順を実行することができる。
【0045】
結果的に、最後のD−SRを送信した後に、D−SR送信失敗後続手順を即座に実行せず、端末は、D−SR送信リソースのために使用可能な次のサブフレームまで待機した後にD−SR送信失敗後続手順を実行するか否かを判定することにより、不必要なD−SRの送信を防止することができる。
【0046】
図5は、本発明の第1の実施形態による端末のスケジューリング要請信号を送信する動作を示す図である。
【0047】
ステップ505で、SR送信過程が、例えば、正規BSRの発生によりトリガーされる場合に、ステップ510で、端末は、SR_COUNTERを0に初期化する。ステップ515で、D−SRを送信するか否かを決定するために、まず、端末は、D−SR送信リソースのために使用可能なサブフレームに近い所定の時点まで待機する。この所定の時点は、D−SR送信リソースのために使用可能なサブフレームよりSRを送信するか否か、又はD−SR送信失敗後続手順を実行するか否かを判定するのに必要とされる端末の処理遅延だけ先立った時点として設定され得、この時点は、変更され得る。
【0048】
ステップ520で、端末は、D−SRを送信するか否かを判定する過程に先立って、SR_COUNTERを1増加させる。上述したように、D−SRを送信するか否か及びD−SR送信失敗後続手順を実行するか否かを判定する過程に先立って、SR_COUNTERをあらかじめ増加させることにより、端末は、D−SR送信失敗後続手順を実行する前に不必要なD−SRを送信しないことがある。
【0049】
図4において、例えば、端末は、サブフレーム430より先立ち、サブフレーム430に近い所定の時点でSR_COUNTERを4に更新し、SR_COUNTERをdsr−transmaxと比較する。この場合に、SR_COUNTERがdsr−transmaxより大きいために、端末は、サブフレーム430で後続動作を実行する。すなわち、最後のD−SRを送信した後に後続動作を即座に実行せず、端末は、D−SR送信リソースのために使用可能なサブフレームまで待機した後に後続動作を実行する。
【0050】
ステップ525で、端末は、SR_COUNTERをdsr−transmaxと比較する。SR_COUNTERがdsr−transmaxより小さいか又は同一である場合に、端末は、D−SR送信のためにステップ545に進む。SR_COUNTERがdsr−transmaxより大きい場合に、端末は、D−SR送信失敗後続手順のためにステップ530に進む。
【0051】
従来では、SR_COUNTERがdsr−transmaxより大きいか又は同一である場合にステップ530の動作を実行する。しかしながら、本発明において、端末は、SR_COUNTERがdsr−transmaxより大きい場合にステップ530に進む。一方、従来技術に比べてdsr−transmaxが1大きい値に設定される場合に、従来の判定手順は、そのまま使用され得る。すなわち、この場合に、ステップ525で、SR_COUNTERがdsr−transmaxより小さい場合には、UEは、ステップ545に進む。SR_COUNTERがdsr−transmaxと同一であるか又は大きい場合には、端末は、ステップ530に進む。しかしながら、この場合に、端末は、(dsr−transmax−1)番目のD−SR送信が最後のD−SR送信であるので、従来の方式に比べてdsr−transmaxを1大きい値に設定しなければならない。
【0052】
ステップ530に進むということは、D−SR送信を所定の最大回数まで実行したが、端末は、これに対する応答、すなわちアップリンクグラントを受信できなかったということを意味する。したがって、端末は、D−SR送信失敗後続手順を実行する。言い換えれば、端末は、ステップ530で、D−SR送信リソースを含む様々な専用アップリンク送信リソースを解除し、ステップ535でランダムアクセス過程を開始し、ステップ540で進行中であるSR送信過程をすべて取り消す。
【0053】
ステップ545に進むということは、D−SR送信回数が所定の最大D−SR送信回数に到達しなかったということを意味するので、端末は、D−SRを送信する。ステップ550で、端末は、SR送信過程が進行中にあるか否かを検査する。進行中にあるSR送信過程は、SR送信過程がトリガーされた後に取り消されなかったことを意味する。SR送信過程は、ステップ540のようにD−SR送信失敗後続手順により取り消されることもあり、正規BSRが送信されることにより取り消されることもある。
【0054】
SR送信過程がやはり進行中にある場合には、端末は、ステップ515に進み、SR送信過程を継続して実行する。しかしながら、SR送信過程が進行中でない場合、すなわち、SR送信過程がトリガーされた後にBSRが送信されることによりSR送信過程が取り消される場合には、端末は、ステップ555でSR送信過程を終了する。
【0055】
以下では、本発明の第2の実施形態による端末のスケジューリング要請信号を送信する過程について説明する。
【0056】
図6は、本発明の第2の実施形態に関連した従来技術の問題点及び本発明の第2の実施形態による端末のスケジューリング要請信号を送信する過程を説明する図である。
【0057】
上述したように、正規BSRがトリガーされる場合に、端末が正規BSR送信用リソースの割り当てを受信するためにSR送信過程もトリガーされる。しかしながら、正規BSRがトリガーされるとしてもD−SRが送信されない例外的な状況が発生し得る。
【0058】
例えば、ステップ605で、任意の時点で正規BSRがトリガーされ、SR送信過程がトリガーされ、ステップ610で、D−SR送信リソースのために使用可能なサブフレームでD−SRが送信される場合において、D−SRの送受信に成功した場合に、端末は、ステップ615で、任意のサブフレームでアップリンクグラントを受信する。一方、ステップ625で、端末は、アップリンクグラントが受信されたサブフレームから4個のサブフレームの後にアップリンク送信を実行する。
【0059】
端末は、アップリンクグラントを受信する時に、アップリンク送信が行われるMAC PDUを生成し、MAC PDUは、BSRを含む。一方、MAC PDUの生成が完了する時点620とこの生成されたMAC PDUが実際に送信される時点625との間で、新たな正規BSRがステップ635で発生すると仮定する。
【0060】
この場合に、新たな正規BSRは、時点625で送信されるMAC PDUに含まれないことがあり得る。しかしながら、時点625でBSRが含まれたMAC PDUが送信される場合に、ステップ605でトリガーされたSR送信過程は、時点630で取り消される。この場合に、ステップ635で新たに発生した正規BSRに対するSR送信過程は、D−SR送信を開始せず取り消され得る。
【0061】
この問題点を解決するために、現在のLTE標準は、最も最近のバッファ状態を反映したBSRが送信される場合だけ既存のSR送信過程を取り消すように規定している。このような解決方案は、
図6に関連して説明した状況で前のBSRのためにステップ605でトリガーされたSR送信過程を取り消さず、ステップ635で新たに発生した正規BSRのためのSR送信過程につながる。したがって、SR_COUNTER値が初期化されず、ステップ605で前のBSRのためのSR送信過程で使用されたSR_COUNTERは、そのまま使用される。これは、ステップ635で、新たなBSRに対するD−SRの最大許容可能な送信回数が減少するために、D−SR送信失敗後続手順があまり速く実行される結果を引き起こし得る。
【0062】
このような問題点を解決するために、本発明の第2の実施形態において、端末は、BSRを含むMAC PDUが送信される瞬間現在進行中であるSR送信過程(すなわち、
図6のステップ605のSR送信過程)を取り消し、新たな正規BSRがトリガーされたとしても現在進行中であるSR送信過程がない場合には、新たなSR送信過程をトリガーする。
【0063】
例えば、時点630で、端末は、BSRを含むMAC PDUを送信する場合に、進行中であるSR送信過程を取り消す。一方、端末は、時点630でまだ取り消されていないBSR(すなわち、ステップ635のBSR)が存在するとしても、現在進行中であるSR送信過程がない場合には新たなSR送信過程をトリガーする。すなわち、ステップ635で、端末は、ステップ630の既存のSR送信過程を取り消した後に、新たに発生した正規BSRの送信のためのSR送信過程を新たにトリガーする。
【0064】
図7は、本発明の第2の実施形態による端末のスケジューリング要請信号を送信する動作を説明する図である。
【0065】
ステップ705で、正規BSRがトリガーされる場合に、端末は、ステップ710でSR送信過程をトリガーする。すなわち、端末は、SR送信リソースが使用可能な時点でD−SRを送信する。アップリンクグラントを受信する際に、端末は、BSRを含むMAC
【0066】
PDUを生成し送信する。アップリンクグラントの受信に失敗する時に、端末は、D−SRを送信するなどの動作を実行する。
【0067】
この動作を実行する間に、端末は、ステップ715でトリガーされたBSRが取り消されるか否かを監視する。例えば、端末は、トリガーされたBSRが取り消されなかったかを送信時間間隔(Transmission Time Interval:TTI)ごとに監視することができる。一方、BSRがトリガーされた後に、最も最近のバッファ状態を反映したBSRが(送信される)MAC PDUに含まれる場合に、トリガーされたBSR過程は終了する。トリガーされたBSRが取り消される場合には、端末は、この動作を終了する。
【0068】
他方、トリガーされたBSRが取り消されない場合には、端末は、ステップ720に進み、現在進行中であるSR送信過程があるか否かを検査する。参考に、最も最近のバッファ状態を反映したBSRがまだMAC PDUに含まれていないか、又はBSRがMAC
【0069】
PDUに含まれたが、BSRが端末の現在のバッファ状態を反映していない場合には、このトリガーされたBSR過程は取り消されない。
【0070】
一般的な場合において、取り消されないBSRがある場合に、進行中であるSR送信過程も存在しなければならない。しかしながら、ステップ625及びステップ630の動作におけるように前のバッファ状態を反映したBSRが送信される間にSR送信過程が取り消される場合には、取り消されないBSRは存在するが、進行中であるSR送信過程が存在しない場合があり得る。
【0071】
したがって、ステップ720で、現在進行中であるSR送信過程が存在する場合に、端末は、ステップ715に戻って、SR送信過程を継続して進行しつつBSR過程を取り消すか否かを継続して監視する。しかしながら、ステップ720で現在進行中であるSR送信過程が存在しない場合に、端末は、ステップ725で新たなSR送信過程をトリガーする。その後に、端末は、ステップ715に戻ってBSRが取り消されるか否かを監視する。ステップ715で、BSRが取り消される場合には、端末は、この動作を終了する。
【0072】
図8は、本発明の第1及び第2の実施形態による端末の構成を示すブロック図である。
図8の端末のブロック図において、上位レイヤー装置が図示されなかったことに留意しなければならない。
【0073】
図8を参照すると、端末は、多重化及び逆多重化(MUX/DEMUX)部805と、HARQプロセッサ810と、SR/BSR制御部815と、MAC制御部820と、送受信部825とを含む。
【0074】
SR/BSR制御部815は、上位レイヤーデータの発生を監視することによりBSRがトリガーされるか否かを判定する。本発明の第1の実施形態によると、BSRがトリガーされる場合に、SR/BSR制御部815は、SR送信過程をトリガーし、D−SRを送信するか否か及びSR_COUNTER及びdsr−transmaxを運用することによりD−SR送信失敗後続手順を実行するか否か及びD−SR送信失敗後続動作を実行するか否かを判定し、この判定の結果に基づいて送受信部825がD−SRを送信するか又はランダムアクセス動作を実行するように制御する。また、本発明の第2の実施形態によると、SR/BSR制御部815は、BSRが取り消されるか否かを判定し、取り消されないBSRが存在しても、進行中であるSR送信過程が存在しない場合には、新たなSR送信過程をトリガーする。
【0075】
MAC制御部820は、ダウンリンク及びアップリンク制御チャネルを通して受信されたスケジューリング情報を分析し、送受信部825がダウンリンクデータを受信するか又はアップリンクデータを送信するように制御する。
【0076】
MAC制御部820は、多重化/逆多重化部805がアップリンク送信データを生成するように制御する。アップリンクグラントを受信する時に、MAC制御部820は、SR送信過程が取り消されるか否か及びBSRが取り消されるか否かをSR/BSR制御部815が判定することができるように、このアップリンクグラントの受信をSR/BSR制御部815に通知する。
【0077】
送受信部825は、無線チャネルを介してMAC PDUを送受信するか又は制御情報を送受信し、HARQパケットを送受信する装置である。HARQプロセッサ810は、HARQ動作を実行するために構成されるソフトバッファの集合であり、HARQプロセス識別子で識別される。
【0078】
多重化及び逆多重化部805は、複数の論理チャネルに乗せられたデータを連結することによりMAC PDUを生成するか又はMAC PDUをMAC SDUに逆多重化し、これらを適切な論理チャネルを介して送信する。
【0079】
一方、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び精神を逸脱することなく様々な変形が可能であるということは、当該技術分野における通常の知識を持つ者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。