通信端末及び送信メッセージ生成制御方法
【課題】MAC制御情報に優先度を割り当て、どのような情報を送信させるかを自由に制御することができる通信端末を提供する。
【解決手段】基地局と通信する通信端末は、複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、基地局へ送信する制御情報の優先度を制御する優先度制御部と、前記制御に従い優先度を考慮して送信メッセージを生成する送信メッセージ生成部とを備える。
【解決手段】基地局と通信する通信端末は、複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、基地局へ送信する制御情報の優先度を制御する優先度制御部と、前記制御に従い優先度を考慮して送信メッセージを生成する送信メッセージ生成部とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の手順にしたがって通信する通信端末及び送信メッセージ生成制御方法に関する。
【背景技術】
【０００２】
現在標準化が行われているE-UTRA/E-UTRANにおいては、端末から基地局への上り回線（UL:Up Link）/基地局から端末への下り回線（DL:Down Link）双方とも時間多重が採用されている。上りにおいては、基地局が複数の端末からデータを受信する際、複数の端末が送信したデータの受信タイミングがずれてしまっては、時間多重が効率よく行えない。そのため、時間多重システムにおいては、複数の端末から送信されたデータを、基地局が一定の遅延以内で受信できるように端末の送信タイミングを調整する必要がある。
【０００３】
これを上り同期(uplink synchronization、Timing adjustment、Timing alignment等も使われる)と呼ぶ。端末が上り同期を取る為に必要な動作がRACH手順（RACH プロシージャ(Random Access CHannel procedure）)である。最初にこのRACH procedureの概要に関して説明し、その後本発明で着目したMessage3送信に関して述べる。
【０００４】
［RACH procedure概要］
E-UTRA/E-UTRANにおいてはこのRACH procedureが様々なケースに使われる。RACH procedureの使用理由は、具体的には、呼接続（Initial access）、ハンドオーバーコンプリート（Handover complete）メッセージ送信、UL/DL データ送受信再開（UL/DL data resuming）、再接続（Radio link failure recovery）がある。
【０００５】
Initial accessは、端末がアイドル（RRC_IDLE）状態から呼接続を行う場合である。端末がIDLE状態であるため、基地局との上り同期が取れていない。
【０００６】
Handover complete送信は、端末がhandoverを実施して、受け渡し先（target）の基地局に端末が移動したことを通知する場合である。Targetの基地局とはいままでつながっていないので、ここで同期を取る。
【０００７】
UL/DL data resumingは、間欠受信（DRX）を行っていた端末が、ULもしくはDLのデータを送受信し始める場合である。端末の上り同期はしばらくすると外れてしまうので、同期を取り直す必要がある。
【０００８】
Radio link failure recoveryは、端末が繋がっていたセルを検出できなくなった後に、新たに見つけた(または繋がっていた)セルに対して再接続する場合である。Initial accessと状況が似ている。
【０００９】
また、RACH procedureには大きく二つのタイプが存在する。一つは、端末が自分で基地局に送信するRACH プリアンブル（RACH preamble）を選択する場合（non-dedicated RACH preambleの場合）であり、もう一つは、端末が基地局から与えられたRACH preambleを使用する場合（dedicated RACH preambleの場合）である。
【００１０】
それぞれの動作を図1(a)、(b)に示す。大きな違いとしては、non-dedicated RACH preambleの場合には、複数の端末が同時に同じRACH preambleを使用する可能性があるため、衝突の有無を確認するためのメッセージ（Message4: Contention resolution）が使用されるのに対し、dedicated RACH preambleの場合には、割り当てメッセージ（Message0: RA preamble assignment）によって、使用するRACH preambleを割り当てる点である。
【００１１】
また、Message1、Message2までは全てのケースに関して同じであるが、Message3、Message4がそれぞれのケースに応じて送信されるものが異なる。なお、dedicated RACH preambleを使用することが出来るのは、上記のうちHandover complete送信、DL data resumingのみである。これは、基地局がRACH preambleを割り当てる動作ができるのがその二つの場合に限られているからである。
【００１２】
この二つのprocedureを図2にそれぞれ示す。なお、Handover complete送信、DL data resumingに対しても、常にdedicated RACH preambleが使用されるわけではなく、non-dedicated RACH preambleが使用されることもありうる。
【００１３】
non-dedicated RACH preambleとdedicated RACH preambleのもう一つの大きな違いは、dedicated RACH preambleの場合には、基地局はそれを受信した時点で端末を識別できることである。これによって、それ以降のメッセージでどの端末がRACH preambleを送ったかを確認する作業が不要となる。
【００１４】
言い換えれば、non-dedicated RACH preambleの場合にはMessage 3中に、どの端末がアクセスしてきたかを示す為に、端末のIDを入れる必要がある。この端末のIDは、端末がアクティブ（RRC_CONNECTED）の場合にはセル（cell）単位で使用されるC-RNTI（Controlling Radio Network Temporary Id）が使用され、端末がinitial accessを行う場合にはTracking area(IDLEの端末の移動管理の単位)内で使用されるS-TMSI（S-Temporary Mobile Subscriber Identity）、または端末固有のID(電話番号相当)であるIMSI（International Mobile Subscriber Identity）が使われる。また、radio link failure recoveryの際には、radio link failureを起こす前につながっていたセルのセル識別子（Cell ID）、そのセルでのC-RNTI等が使用される。
【００１５】
［Message3送信］
端末が最初に基地局に対してデータを送信できるのがMessage3であり、そのための情報がMessage2で割り当てられる。しかしながら、Message3のサイズは、端末がセルエッジにいるような場合には72bits程度になってしまうことが知られている。
【００１６】
そのため、全ての情報を一度に送信するのは困難な場合が考えられる。どのようにMessage3が構成されているかを示すために、図3、4、5にそれぞれMAC（Medium Access Control）、RLC（Radio Link Control）、PDCP（Packet Data Convergence Protocol）のヘッダー（header）構成を示す。また、protocolの構成を図14に示す。以下はその概略説明である。
【００１７】
（MAC）
3種類のMACサブヘッダーが用意されており、最小のサブヘッダーが8bitとなっている。LCID (Logical Channel ID)を用いてどのデータが入っているかを示しており、拡張領域（E（Extension）field）でMACサブヘッダーの次にMACサブヘッダーがあるか否かをしめし、長さ領域（L（Length） field）でデータのサイズを示している。
【００１８】
MAC control element (MACの制御情報: 上りとしてはC-RNTI、Buffer status report(バッファ状態報告、端末のバッファーの状況を示すもの。以下BSR)、CQI(Channel Quality Indicator、チャネル品質インジケータ：端末のチャネル状況を示すもの))もLCIDで示される。この場合には、サイズが決まっているため、L fieldはいらない。
【００１９】
（RLC）
RLC AM (acknowledge mode)用に16bitのヘッダーが、RLC UM (unacknowledge mode)用に16bit(長いデータ用に10bitSN)と8bit(短いデータ用に5bitSN)が定義されている。
【００２０】
（PDCP）
SRB (signaling radio bearer、シグナリング無線ベアラ:制御メッセージであるRRC messageを運ぶためのベアラ)とデータ無線ベアラ（data radio bearer：データを運ぶためのベアラ。以下DRBと呼ぶ)とで異なるheaderが定義されている。SRBの場合には40bitsのheaderが必要になる。
データ無線ベアラはユーザプレーン無線ベアラ（user radio bearer）と呼ばれること
もある。
【００２１】
また、Handover completeは、RRC messageとしてメッセージタイプ（message type：メッセージの種類を示すもの)、トランザクション識別子（transaction id：どのメッセージの応答なのかを示すもの)などを含むと考えられており、8bitを想定している。
【先行技術文献】
【非特許文献】
【００２２】
【非特許文献１】TS25.321: “Medium Access Control (MAC) protocol specification”
【発明の概要】
【発明が解決しようとする課題】
【００２３】
上記説明から、Handover completeの送信を考えると、端末が72bitsのみ送信用に割当てられた場合には、表１のように二度に分けて送信することが必要となることがわかる。また、Handoverを行った後にはBSRを送信することが決まっている。UMTS（Universal Mobile Telecommunication System）において、MAC control情報(LTEでのMAC control element)は、常にSRB、DRBよりも優先度が高いとされている（非特許文献1参照）。
【００２４】
そのため、このBSRをHandover completeよりも先に送ることが想定される。この場合、表2のように三度にわけて送信することになり、さらにはHandover completeの送信が遅れてしまうこととなってしまう。
【００２５】
【表１】
【００２６】
【表２】
【００２７】
上述したとおり、MAC control element(例えばBSR)が優先される場合には、Handover completeの送信が遅れることが考えられる。これは、下記のようなデメリットをもつ。
【００２８】
（ネットワークでのパス切り替え（path switching）遅延）
基地局は、Handover completeを受信することで、端末が移動してきたと確実に判断できる。そのため、ネットワーク内での切り替え(元の基地局から新しい基地局へのパス切り替え)は、Handover completeを受信したタイミングで行われる。path switchingが遅れると、元の基地局から新しい基地局に転送されないデータなどは廃棄されてしまう。
【００２９】
図15にネットワーク側の基地局とコアネットワーク（Core network）のエンティティ（entity）との関係を示す。Handover completeを新しい基地局(Target eNB)が受信して、Core networkのentityにパスの切り替えを行うまでは、Core networkのentityは前の基地局(source eNB)に対してデータを送信し続ける。
【００３０】
これは、前の基地局が新しい基地局にデータを転送するような場合には問題ないが、例えば、VoIPなどのリアルタイムサービスではパケットの転送がされないと考えられている。これを最低限に抑えるために、path switching遅延を短くすることが求められている。
【００３１】
（下りの送信開始遅延）
基地局は、Handover completeを受信することで、端末が移動してきたと確実に判断でき、下りのデータ送信を開始できる。そのため、Handover completeの受信が遅れると、元の基地局から新しい基地局に転送されているデータがある場合に、下りのデータ送信開始が遅れることとなってしまう。
【００３２】
上記のようなことを考えると、常にMAC control elementを優先することは望ましくない。そのため、MAC control elementの優先度（priority）を制御する必要がある。
【００３３】
本発明は、上記従来の事情に鑑みてなされたものであって、MAC制御情報に優先度を割り当て、どのような情報を送信させるかを自由に制御することができる通信端末及び送信メッセージ生成制御方法を提供することを目的としている。
【課題を解決するための手段】
【００３４】
本発明の通信端末は、基地局と通信する通信端末であって、複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、前記基地局へ送信する制御情報の優先度を制御する優先度制御部と、前記制御に従い前記優先度を考慮して送信メッセージを生成する送信メッセージ生成部と、を備えるものである。
【００３５】
上記構成によれば、複数のMAC制御情報に個別に割り当てられているMAC制御情報の優先度と、複数のSRBに個別に割り当てられている優先度とを考慮して送信メッセージを生成することができる。
【００３６】
また、本発明の通信端末は、前記制御情報の優先度を制御するための情報を前記基地局から受信する受信部をさらに備えるものである。
【００３７】
また、本発明の通信端末は、前記MAC制御情報の優先度は予め決められており、前記基地局から受信した優先度を制御するための情報を用いて前記SRBを含めた優先度を制御するものである。
【００３８】
本発明の送信メッセージ生成制御方法は、基地局と通信する通信端末により実行される方法であって、複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、前記基地局へ送信する制御情報の優先度を制御するステップと、前記制御に従い前記優先度を考慮して送信メッセージを生成するステップと、を備えるものである。
【００３９】
上記構成によれば、複数のMAC制御情報に個別に割り当てられているMAC制御情報の優先度と、複数のSRBに個別に割り当てられている優先度とを考慮して送信メッセージを生成することができる。
【００４０】
また、本発明の送信メッセージ生成制御方法は、前記制御情報の優先度を制御するための情報を前記基地局から受信するステップをさらに備えるものである。
【００４１】
また、本発明の送信メッセージ生成制御方法は、前記MAC制御情報の優先度は予め決められており、前記基地局から受信した優先度を制御するための情報を用いて前記SRBを含めた優先度を制御するものである。
【発明の効果】
【００４２】
本発明の通信端末及び送信メッセージ生成制御方法によれば、MAC制御情報に優先度を割り当て、MAC制御情報の優先度が通信端末に送信するので、通信端末がどのような情報を送信するかを自由に制御できるようになる。
【図面の簡単な説明】
【００４３】
【図１】non-dedicated RACH preambleとdedicated RACH preambleの動作を示す図
【図２】Handover complete送信およびDL data resumingのprocedureを示す図
【図３】Message3のMACのヘッダー構成を示す図
【図４】Message3のRLCのヘッダー構成を示す図
【図５】Message3のPDCPのヘッダー構成を示す図
【図６】本発明の実施形態２の概念を示す図
【図７】本発明の実施形態２にかかる端末のブロック図
【図８】本発明の実施形態２にかかるprocedureの具体例を示す図
【図９】本発明の実施形態３の概念を示す図
【図１０】本発明の実施形態３にかかる端末のブロック図
【図１１】本発明の実施形態３においてMAC control elementの優先順位自体をRACH procedureの使用理由ごとに変えることを説明するための図
【図１２】本発明の実施形態４の概念を示す図
【図１３】本発明の実施形態４にかかる端末のブロック図
【図１４】Message3のprotocolの構成を示す図
【図１５】ネットワーク側の基地局とCore networkのentityとの関係を示す図
【図１６】本発明の実施形態１においてMAC control element毎にpriorityを設定する概要を示す図
【図１７】本発明の実施形態１にかかる端末のブロック図
【図１８】本発明の実施形態２におけるMAC control elementの優先度のtable、boundary情報の例を示す図
【図１９】本発明の実施形態２において基地局が端末のスピードを考慮する際の動作を示す図
【図２０】本発明の実施形態２において一時的にpriorityを変更する動作を示す図
【図２１】本発明の実施形態３においてsemi-persistent schedulingを用いて送信する場合に使用するboundary情報を端末に送信する方法を示す図
【図２２】本発明の実施形態５にかかる端末のブロック図
【図２３】本発明の実施形態５にかかる動作の本質を示すフローチャート
【図２４】本発明の実施形態２において端末がinitial access (呼接続)、Radio link failure recovery(再接続)を行う場合の流れを示す図
【図２５】従来の提案で使用されるＭＡＣサブヘッダーの構成を示す図
【図２６】従来の提案１にかかるＭＡＣサブヘッダーの構成を示す図
【図２７】本発明の実施形態６にかかるＭＡＣサブヘッダーの構成を示す図
【図２８】本発明の実施形態６にかかる端末の動作の概要を示す図
【図２９】本発明の実施形態６にかかるＭＡＣヘッダーの構成例を示す図
【図３０】本発明の実施形態６にかかるLCIDの定義の例を示す図
【図３１】本発明の実施形態６にかかるＭＡＣヘッダーの他の構成例を示す図
【発明を実施するための形態】
【００４４】
以下、基地局と端末とが、RACH procedureの実施に先立ち、送信するデータの優先度を確定する例を説明する。なお、下記各実施の形態は、図1に示したnon-dedicated RACH preambleの場合及びdedicated RACH preambleの場合のいずれにも同様に適用できる。
【００４５】
＜実施の形態1＞
SRB（signaling radio bearer：制御メッセージであるRRC messageを運ぶためのbearer）、DRB（user plane radio bearer /data radio bearer：データを運ぶためのbearer）は、それぞれ優先度（priority）を持っている。現状SRBとしては優先度の高いRRC messageを送るためのhigh priority SRB（SRB2）と通常のSRBとしてのpriorityを持つlow priority SRB（SRB1）がRRC_CONNECTEDの端末が通信するために存在する。また、initial access、Radio link failure recoveryなどでRRC_CONNECTEDに端末が移るまでのRRC messageを運ぶために別のSRB(SRB0)が定義されている。DRBとしては、端末が使用するサービスに応じて追加され、例えばVoIPのためのDRB、web browsingのためのDRB、emailのやり取りのためのDRBなどが設定される。
【００４６】
ここで、端末がどのbearerを送信すればよいかを基地局側で制御できるように、priorityがbearerごとに設定されている。基本的にSRBはDRBより高い優先度を持つ。また、DRBの中では遅延に対する要求が厳しい（time critical）サービスのためのbearerほど高い優先度を持つ。そのため、上記の例では下記のような優先度が考えられる。
【００４７】
High priority SRB > low priority SRB > DRB for VoIP > DRB for web browsing > DRB for email
【００４８】
本実施の形態では、SRB、DRBと同じようにMAC control element毎にpriorityを設定する。その概要を図16に示す。この図に示されるように、例えば、priorityの値が1-8まであり、1が一番高い場合に、MAC control elementの中で一番優先度の高いと考えられるC-RNTIを優先度1、次に優先度の高いと考えられるBSR、CQIなどを優先度3と設定することが考えられる。
【００４９】
ここで、high priority SRBの優先度が2となった場合には、C-RNTIのみがhigh priority SRBよりも優先される。このような動作により、端末にどのような情報を送信させるかを自由に制御できるようになる。
【００５０】
具体的には、端末がVoIPを使用していてpath switchingを早くする必要がある場合には、BSRよりもhigh priority SRBの優先度を高くすることが考えられる。また逆に、path switchingを早く行う必要がなく、端末の持っているbuffer状態を早く把握したい場合には、BSRをhigh priority SRBよりも優先度を上げることが出来る。
【００５１】
（ブロック図）
図17を用いて本発明の端末のブロック図を示す。図17に示す通信端末は、受信部701と、SRB生成部705と、DRB生成部706と、優先度制御部1701と、送信message生成部704と、バッファー部707と、MAC情報生成部708と、送信部709とを備える。各部の主要動作、役割は下記のとおりである。
【００５２】
701は、受信部であり基地局からのメッセージを受信する。受信部701は、MAC control element毎の優先度を受信し、優先度制御部1701に送る。また、受信部701は、端末が送信するメッセージサイズを受け取り、送信message生成部704に送る。705は、SRB生成部であり、RRC message、NAS message等のSRBを用いて送信するメッセージの作成を行う。706は、DRB生成部であり、user planeデータの作成を行う。
【００５３】
1701は、優先度制御部であり、受信部701からMAC control element毎の優先度を受信する。優先度制御部1701は、MAC control element毎の優先度と通常DRB、SRBに割当てられている優先度とにより、” C-RNTI > SRB > BSR > CQI > DRB”、または” C-RNTI > high priority SRB > BSR > low priority SRB > CQI > DRB”のような、MAC control elementとSRBの優先度の関係を確定する。そして優先度制御部1701は、その結果を用いて、送信message生成部704に、priorityの高い情報を先に送信するような送信メッセージを作成させるよう制御する。
【００５４】
704は、送信message生成部であり、優先度制御部1701からの優先度情報と、受信部701からの送信メッセージサイズをもとに送信メッセージを作成する。送信message生成704は、後述するMAC情報生成部708よりMAC control elementを受け取り、送信可能なbearerとその量をバッファー部707に通知し、バッファー部707よりSRBまたはDRBの送信すべき情報を受け取ることも行う。
【００５５】
707は、バッファー部であり、SRB生成部705とDRB生成部706からの情報を保持し、送信message生成部704の指示に応じて送信message生成部704に送信する。
【００５６】
708は、MAC情報生成部であり、MAC control elementを生成し、送信message生成部704に通知する。具体的には、MAC情報生成部708は、C-RNTIを送信する必要があるときには、送信message生成部704にC-RNTIを渡す。また、MAC情報生成部708は、BSRを送信する必要があるときにはバッファー部707の情報からBSRを生成、送信するなどである。709は、送信部であり、送信message生成部704で作成したメッセージを基地局に送信する役割を持っている。
【００５７】
以上説明したように、本実施の形態によれば、MAC control element毎に自由にpriorityを設定できるため、RACH procedureのMessage3で優先して基地局へ送信すべきデータを、通信サービスの内容や状況に応じて適切に制御できる。
【００５８】
＜実施の形態2＞
本実施の形態の概念を示す図を図6に、また、端末のブロック図を図7、本動作のprocedureの具体例を図8に示す。
【００５９】
実施の形態1では、MAC control element毎に自由にpriorityを設定できるようにした。しかしながら、実施の形態１の方式では基地局が端末に対してpriorityの設定を行うシグナリング（signaling）のオーバーヘッド（overhead）が増加してしまうという課題が存在する。本実施の形態では、MAC control element内での優先度を予め決めておき、SRBに対して高い優先度を持つMAC control elementと低い優先度のMAC control elementの境目（boundary）のみを設定することにより、上記課題を解決する。その概要を図6に示す。
【００６０】
図6(a)のように、MAC control elementはMAC control element内での優先度を決定する。これは、標準化などの仕様（spec）などで規定することが考えられ、報知情報等で送信するのでもよいし、個別のRRC messageで送っても良い。本実施の形態では、標準化などの仕様（spec）などで規定する例に関して説明する。そして、設定するのは、SRBよりも高い優先度となるMAC control elementと低い優先度となるMAC control elementの境目である。具体的には、図6(a)の例でのboundary1-4のどれかを指示することとなる。このときのsignaling例が図6(b)である。なお、図6(b)に示される手順は、図１(a)に示すMessage1以前に実施される。
【００６１】
具体的には、boundary2が指定された場合には、下記のようなpriorityの順になる。
C-RNTI > SRB > BSR > CQI > DRB
【００６２】
また、上記ではSRBとしてひとくくりとしたが、MAC control elementの優先度をhigh priority SRBと比較して設定することも考えられる。そのような場合には下記のようになる。
C-RNTI > high priority SRB > BSR > low priority SRB > CQI > DRB
【００６３】
（ブロック図）
図7に、本実施の形態の端末のブロック図を示す。図７に示す端末は、図１７に示した端末の優先度制御部1701に代えて優先度制御部703と優先度table部702を備える。各部の主要動作、役割について、実施の形態１と異なる点を説明する。
【００６４】
本実施の形態において、受信部701は、実施の形態１で説明した役割に加え、基地局から上記で説明したboundary情報を受信し、優先度制御部703に通知する役割を有する。
【００６５】
優先度table部702は、図6(a)に示すMAC control element内の優先度の情報を保持しており、それを優先度制御部703に通知する役割を持っている。
【００６６】
優先度制御部703は、受信部701からのboundary情報と優先度table部702からの優先度table部情報とにより、” C-RNTI > SRB > BSR > CQI > DRB”、または” C-RNTI > high priority SRB > BSR > low priority SRB > CQI > DRB”のような、MAC control elementとSRBの優先度の関係を確定する。そして優先度制御部703は、その結果を用いて、送信message生成部704に、priorityの高い情報を先に送信させるように制御する。
【００６７】
（詳細説明）
本発明の動作を図7、図8を用いて説明する。なお図8はhandover送信のprocedureの具体例である
【００６８】
図8に示されているように、まず、基地局（Source cell）から端末（UE）にboundary情報が通知される（ST8-1:RRC CONNECTION RECONFIGURATION message）。このboundary情報は、受信部701で受信され、優先度制御部703に渡される。優先度制御部703は、ST8-1で受信されたboundary情報と、優先度table部702に保持されている図6(a)に記載のMAC control element内の優先度を示すtableという二つの情報から、MAC control elementの優先度の情報を得る。優先度制御部703は、これを送信Message生成部704に伝える。
【００６９】
次に、送信message生成部704で作成されたST8-1に対する応答メッセージが、端末の送信部709から基地局に送信される（ST8-2: RRC CONNECTION RECONFIGURATION COMPLETE message）。
【００７０】
そして、基地局は、端末にHandoverの実施を通知する（ST8-3: Handover Command message）。それに応じて端末はhandoverを実施する。なお、この処理は一般的な動作であり、本発明とは直接関係しないため、説明を省略する。
【００７１】
なお、Handover Command、Handover Complete messageは、それぞれ基地局が端末にHandoverを指示するメッセージ、端末が基地局にHandoverの完了を示すメッセージの総称であり、E-UTRA/E-UTRANでは、RRC CONNECTION RECONFIGURATION message、RRC CONNECTION RECONFIGURATION COMPLETE messageがそれぞれ使われる。
【００７２】
ST8-3の後に実施される、ST8-4: Random Access preamble、ST8-5: Random Access responseは、通常のRACH procedureでありここでは詳細な説明を省略する。ST8-5の後、送信message生成部704は、ST8-5で受け取ったリソース割当情報を元に、Message3でのmessage sizeを決定する。このmessage sizeは、受信部701から送信message生成部704に送られる。
【００７３】
ここで、Handover completeとBSRとを両方送りたい場合で、１つのメッセージに両方が入りきらない場合にはpriorityによってどちらを優先するかを決定することとなる。すなわち、BSR > SRBとなっていればBSRを優先するし、BSR < SRBとなっていればHandover completeを優先することとなる。そのため、優先度制御部703で決定された優先度によって、ST8-6、ST8-8で送られる内容が、Handover completeになるかBSRになるか変わってくる。
【００７４】
MAC control elementの優先度のtable、boundary情報の例を図18(a)、(b)にそれぞれ示す。このように、MAC control elementの優先度をtableで持ち、RRC messageの優先度(high priority SRBのみでも良いし、low priority SRBと両方でも良いし、low priority SRBのみでも良い)がboundary情報で通知されるため、送信する内容を制御することが出来る。
【００７５】
次に、基地局がどのようにこのboundary情報を決定するかについて説明する。前述の通り、Handover Complete messageの送信の遅延は、network側のPath切り替えの遅延を引き起こす。このPath切り替えの遅延の影響を大きく受けるのは、前述のとおり元の基地局からHandover先の基地局にデータの転送を行わないVoIPのようなリアルタイムサービスである。
【００７６】
そのため、Handover Completeの送信を、VoIPを行っている端末のみに優先させるという処理が考えられる。また、パスを切り替えるための情報として、基地局間でやりとりする端末情報の有効性も考えられる。Handover時に基地局間で端末の情報のやりとりを行う。
【００７７】
この際に、端末の受信品質、端末のバッファー状態、などの情報もやり取りされる。端末の移動速度がそれほど速くなく、端末の受信品質が基地局間でやり取りされる情報で十分な場合には、CQIの優先度を下げることが考えられるし、逆に端末の移動速度が速い場合にはCQIの優先度をあげることが考えられる。
【００７８】
また、端末のバッファー状態が変動しやすいサービス、変動しにくいサービスが考えられる。例えば、VoIP等のサービスではバッファー状態はそれほど変動しない。それに比べてuploadを行うような場合にはバッファー状態が大きく変動することが考えられる。
【００７９】
そのため、変動しにくいサービスのみを行っている場合には、BSRの優先度を下げて、逆に変動しやすいサービスを行っている場合にはBSRの優先度をあげることが考えられる。このような動作により、端末が送信すべき情報を制御できるようになる。
【００８０】
なお、本実施の形態では、MAC control elementに対して一つのboundaryのみを設定する例を示したが、設定するboundaryを増やすことも可能である。具体的には、high priority SRBに対するboundary(例えば図6(a)のboundary2)とlow priority SRBに対するboundary(例えば図6(a)のboundary3)を設定し、”C-RNTI > high priority SRB > BSR >CQI > low priority SRB > DRB”のような優先度に設定することも考えられる。
【００８１】
本実施の形態では、SRBのみに対してMAC control elementの優先度を設定できるようにした。しかしながら、一番優先度の高いDRBに対して設定することも可能である。すなわち、”C-RNTI > SRB > BSR > high priority DRB > CQI > other DRB”のような処理を、boundary情報を複数持つことで実現が可能である。
【００８２】
本実施の形態ではHandover completeの送信の例を示したが、その他の場合にも適用可能である。具体的な例としては、UL data resumingがあげられる。UL data resumingは、端末がDRX中に送信するデータが発生した場合の動作である。
【００８３】
具体的には、端末の受信状態を示す測定結果(RRC messageとしてはMeasurement report)を送信することや、新たなサービスの追加を求めるサービス要求(NAS messageとしてはservice request等)を送ることが考えられる。測定結果を示すMeasurement reportはHandoverの実施に必要なため、優先度が高いメッセージである。
【００８４】
そのため、端末の移動速度が速い場合にはこのメッセージを早く送信しなければいけないという課題がある。前述の通り、基地局が端末の移動速度を考慮することにより、この際に、発生したデータを送るのか、それともBSRを優先するのか、CQIを優先するのかを本実施の形態に示した処理で決定できる。その際の動作を図19に示す。
【００８５】
MAC control elementの優先度をLCIDの順番の通りにすることも可能である。前述の通り、MAC control elementは、それぞれLCIDで示される。例えば、BSRは11100、CQIは11101などである。ここで、そのLCIDの順番がpriorityの順番となるように定義することで、端末に優先度のtableを特別に用意することが必要なくなるなどのメリットがある。
【００８６】
本実施の形態では、図8に示したように、Handover CommandとBoundary情報の通知を別のメッセージとしたが、Handover CommandにてBoundary情報を通知、変更することも可能である。
【００８７】
本実施の形態では、端末がVoIPを行っていてHandover completeを優先すべき時などにRRC messageのpriorityをあげるように設定する動作をしめした。しかしながら、同一基地局内のセル間のHandoverの際には状況が異なってくるという課題が存在する。
【００８８】
これは、基地局のswitchingがおこらないため、Handover completeを早く送信する必要がなくなるためである。これを実現するために、一時的にpriorityを変更するような動作が考えられる。
【００８９】
図20にその際の動作を示す。ここで図8との大きな違いは、ST8-3に相当するST20-1にて、temporaryなpriorityを割当てている点である。このtemporaryなpriorityは、基地局が送信したST20-1: Handover Commandに対する応答にのみ適用されるものであり、Handover Completeのみに適用される。
【００９０】
本発明では、RACH procedureのMessage 3に着眼して説明したが、本実施の形態は、通常の上り送信全てに適用可能である。
【００９１】
通常の上り送信全てに使用する際の典型的な例として、端末がinitial access (呼接続)、Radio link failure recovery(再接続) を行う場合が考えられる。その流れを図24に示す。端末が呼接続、再接続を行う際には、ネットワーク側は端末の受信状況などを正確に知らない。そのため、CQI等の情報が必要である。
【００９２】
しかしながら、その一方で、端末がST2406aで送る信号には、Core networkに送る情報が入っており、それを送らなければ最終的に呼接続は終了しない。その一方で、ST2406bは主に確認応答のみに使われる。
【００９３】
そのため、ST2404a、ST2404bで与えるboundary情報により、initial access時にはSRB (すなわちRRC CONNECTION SETUP COMPLETE)を優先するといった動作が可能になる。これにより、呼接続の遅延がMAC control elementの送信により増大するといった課題を解決できる。
【００９４】
＜実施の形態3＞
本実施の形態の概念を示す図を図9に、また、端末のブロック図を図10に示す。実施の形態2では、RACH procedureを使用する全ての場合に対して同じpriority設定を使用する場合を示した。しかしながら、RACH procedureの使用理由によって、必要な情報が若干異なるため、RACH procedureを行う理由ごとにそのpriorityを決定することが考えられる。本実施の形態によれば、RACH procedureの使用理由に応じて、より適切な送信データの制御が可能となる。以下に、RACH procedureを行う理由ごとのpriorityの決定例を示す。
【００９５】
（Handover completeの送信）
BSRはそれほど変更が無ければ、元の基地局から移動先の基地局に通知されたものが使用できると考えられる。そのため、Handover complete(すなわちSRB)を優先することが考えられる。
【００９６】
（上りの送信開始遅延）
端末がどれだけ情報を持っているかを知るために、BSRが必要となる。そのため、SRBよりもBSRを優先することが考えられる。
【００９７】
（下りの送信開始遅延）
下りの送信を行う為に、CQIが必要だと考えられる。そのため、CQIを優先することが考えられる。
【００９８】
図9(b)にこれを実現する為の情報の指示の動作を示している。このようにboundary情報をRACH procedureの使用理由ごとに決めることで、RACH procedure毎に動作を変えることが可能となる。
【００９９】
（ブロック図）
図10に、本実施の形態の端末のブロック図を示す。図10に示す端末は、図7に示した端末の優先度制御部703、送信message生成部704に代えて、優先度制御部1001、送信message生成部1002を備える。以下、異なる点のみを説明する。優先度制御部1001は、RACH procedureの理由ごとに異なるpriorityの設定を持つことができ、それを送信message生成部1002に通知する。送信message生成部1002は、RACH procedureの理由ごとに異なるpriorityの設定を用いて送信メッセージを生成する。
【０１００】
なお、本実施の形態では、boundary情報のみをRACH procedureの理由ごとに設定する例を示したが、MAC control elementの優先順位自体をRACH procedureの使用理由ごとに変えるにすることも可能である。この場合、図11に示すように、図10に示した優先度table部702に代えて優先度table部1101を備え、優先度table部1101に、RACH procedureの使用理由ごとの優先度を設定しておけばよい。
【０１０１】
具体的には、下記のような例が考えられる。
Handover complete: C-RNTI >BSR > CQI
UL data resuming: C-RNTI > BSR > CQI
DL data resuming: C-RNTI > CQI > BSR
【０１０２】
また、本実施の形態で示したRACH procedureの使用理由（cause）によって異なるpriorityを用いる動作を、同じbearerであってもdynamic schedulingとsemi-persistent schedulingとで異なるpriorityを設定する場合にも適用できる。E-UTRA/E-UTRANでは、毎回データをPDCCH (Physical Downlink Control Channel)で割当てるdynamic schedulingと、一度PDCCHで割当てたら一定の周期でそのリソースを使い続けるsemi-persistent schedulingとがある。このsemi-persistent schedulingは、VoIPのように定期的にデータが同じサイズで送られるようなサービスに適している。しかしながら、BSR、CQIなどの情報をVoIPのデータより優先して送信しようとするとsemi-persistent schedulingで割当てたリソースでは入りきらず、VoIPのデータを一度に送れないという課題が存在する。そこで、MAC control elementに対する優先度をDRBにも適用し、さらにDRBに対するscheduling方法によってpriorityの設定を変えることにより、上記課題の解決が実現できる。具体的には、semi-persistent schedulingを用いて送信する場合に使用するboundary情報を端末に送信する方法が考えられる(図21)。すなわち、boundary1が示された場合には、端末はsemi-persistent schedulingの時のみにVoIPデータをBSR、CQIより優先し、dynamic schedulingの場合にはBSR、CQIを通常どおり優先することとなる。
【０１０３】
＜実施の形態4＞
本実施の形態の概念を示す図を図12に、また、端末のブロック図を図13に示す。実施の形態2では、SRBをMAC control elementよりも優先できるようにする手段を提供した。しかしながら、MAC control elementよりも優先されるメッセージのサイズが大きい場合には、先にMAC control elementを送ったほうが良いことが考えられる。
【０１０４】
そのため、本実施の形態では、MAC control elementよりも優先されるメッセージが所定のサイズよりも小さい場合のみMAC control elementよりも優先する。そのための閾値（Threshold）は、図12(b)に示されるようにboundary情報と合わせて送られる。
【０１０５】
（ブロック図）
図13に、本実施の形態の端末のブロック図を示す。図13に示す端末は、図7に示した端末の優先度制御部703、送信message生成部704に代えて、優先度制御部1301、送信message生成部1302を備える。以下、異なる点のみを説明する。優先度制御部1301は、MAC control priorityより優先するSRBまたはDRBを送信するか否かを判断するために使用する閾値を受信、処理し、それを送信message生成部1302に送る。送信message生成部1302は、優先するSRBまたはDRBのサイズが閾値を下回っているか否かを判断し、閾値を下回っているときのみ、MAC control elementよりもSRBまたはDRBを優先して送信するよう送信メッセージを作成する。
【０１０６】
＜実施の形態5＞
本実施の形態の端末のブロック図を図22に、動作の概要を示すフローチャートを図23に示す。実施の形態2では、MAC control elementとSRBの優先順位をネットワークからの指示により決定する方法を示した。本実施の形態では、ネットワークからの指示なしに優先順位を決定する動作を示す。
【０１０７】
（ブロック図）
図22は、本実施の形態の端末のブロック図を示す。図22に示す端末は、図7に示した端末の受信部701、優先度制御部703、送信message生成部704に代えて、受信部2201、優先度制御部2202、送信message生成部2203を備える。以下、異なる点のみを説明する。
【０１０８】
受信部2201は、受信部701と異なり、boundary情報を受信し優先度制御部703に通知するのではなく、MAC control elementとSRBの優先順位を決定するのに必要な情報を優先度制御部2202に送る。ここで、MAC control elementとSRBの優先順位を決定するのに必要な情報とは、VoIPのようなpath switching遅延によりパケットロスが多くなるようなサービスを受けているか、Handoverが基地局内のHandoverか、基地局間のHandoverかなどの情報である。
【０１０９】
優先度制御部2202は、優先度制御部703と異なり、受信部2201より受け取った情報をもとにSRBとMAC control elementの優先順位を自ら決定する。優先順位の決定は、送信Message生成部2203が送信メッセージを作成する際に行われる。
【０１１０】
送信Message生成部2203は、優先度制御部2202に、送信する予定のメッセージの内容を通知する。また、送信Message生成部2203は、送信メッセージを作成する都度、優先度制御部2202に優先順位の確認を行う。
【０１１１】
（フローチャート）
図23に、Handover completeを送信する際に、VoIPを使っているか否かと、基地局間Handoverか否かをもとにSRBとMAC Control elementの優先度を決める動作を示す。
【０１１２】
ST2301で、端末の送信Message生成部2203から基地局へのHandover completeの送信が開始される。そして、送信Message生成部2203は、優先度制御部2202に優先度の確認を行う。
【０１１３】
優先度制御部2202は、ST2302にてVoIPを使っているか否かを判断する。使っていない場合にはST2304に進み、使っている場合にはST2303に進む。ST2303では、優先度制御部2202は、今回のHandoverが基地局間Handoverか、基地局内Handoverかを判断する。ST2303にて、基地局内Handoverの場合にはST2304に進み、基地局間Handoverの場合には、ST2305に進む。
【０１１４】
ST2304では、優先度制御部2202は、Handover Complete遅延によっておこるpath switching遅延が問題ないものとして、MAC Control elementを優先すると決定する。逆に、ST2305では、Handover completeの遅延が問題となるため、Handover completeを優先すると決定する。これらの結果は送信Message生成部2203に通知され、送信Message生成部2203は、その結果を元に送信メッセージを生成する。
【０１１５】
なお、本実施の形態では、VoIPを行っているか否か、基地局間Handoverか否かをもとに端末がSRBのMAC control elementに対するpriorityを判断することを示したが、それ以外の条件を用いても良い。具体的には、端末の移動速度が速ければCQIを優先し、遅ければ優先しないなどの処理も考えられる。また、端末内のバッファー状態の変動が激しい場合にはBSRを優先し、変動が激しくない場合にはBSRを優先しないということも考えられる。
【０１１６】
本実施の形態では、VoIPを行っているか否かを判断の一つの基準としたが、単純に基地局間で転送されないサービスがあるか否かで判断しても良い。RLCのUMを使うDRBは転送されないことになっている。そのため、RLCのUMを使うDRBがあるか否かを判断基準とすることが出来る。
【０１１７】
また、さらには、そのRLC UMを使用しているDRBがある優先度以上であるかを判断基準に使用することが出来る。これにより、優先度の低いRLC UMのDRBにひきずられてSRBの優先度が決まってしまうようなことを回避できる。
【０１１８】
＜実施の形態6＞
本実施の形態のMACサブヘッダーの構成を図27に、端末の動作の概要を示すフローチャートを図28に示す。本実施の形態では、端末が自分で基地局に送信するRACH preambleを選択する場合（non-dedicated RACH preambleの場合）にどのように基地局がその内容を区別するかを示す。
【０１１９】
端末が自分で基地局に送信するRACH preambleを選択する場合、基地局は、その端末がinitial accessを行いたいのか、Handover completeの送信を行いたいのか、その他なのかがRACH preamble（図1(a)に示すMessage1）を受信しただけではわからない。そのため、基地局は図1(a)に示すMessage3の内容が何であるのかを、Message3を受信した時点で知ることになる。この際に一つ課題がある。それは、Message3にMACのヘッダーが使用されるかどうかが条件によって異なることに起因する。具体的には、端末に対して72bitsの情報を送るためだけのリソースが割当てられた場合には、呼接続、再接続の場合にはMACのヘッダーが含まれず、直接RRC messageが含まれることになり、それ以外のHandover complete送信、UL/DL データ送受信再開では、MACのヘッダーが含まれる。また、72bitsより多い、例えば144bitsの 情報を送るリソースが割当てられた場合には、呼接続、再接続の場合でもMACヘッダーが含まれることとなる。そのため、基地局は72bits のみを端末に割当てた場合に、MACヘッダーが含まれているか否かを判断する必要がある。
【０１２０】
これを解決するために非特許文献(R2-080162: Message 3 encoding)では、二つの提案を行っている。
【０１２１】
（従来の提案１）
一つ目の提案は、非特許文献(TS36.321 V8.0.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification”)に記載されている現状のMACサブヘッダー(MAC sub-header)の構成（図25(a)参照）を使用したものであり、先頭にあるLCID（Logical Channel IDentifier） 領域(LCID field)を使用するものである。LCID領域は、運ぶデータに該当するLCID、またはMAC control elementに該当するLCIDを入れる場所であり、これにより受信側は受け取ったデータが何かを識別できる。
【０１２２】
当該文献に記載されている具体的な方法は、５bitsあるLCIDの先頭の２bitsを用いてMACヘッダーがあるか、否かを示すものであり、例えば先頭の２bitsの値が”11”となっている場合には、MACヘッダーがあるものとして扱い、それ以外の”00”、”01”、”10”の場合にはMACヘッダーが無しと扱う動作とするものである。呼接続、再接続の場合のRRC message、すなわちRRC CONNECTION REQUEST、RRC CONNECTION RE-ESTABLISHMENT REQUESTの場合には、先頭の２bitsがRRC messageを示すMessage typeに使用されると考えられている。そのため、”00”、”01”、”10”の場合には、RRCにて受信したメッセージがRRC CONNECTION REQUEST、RRC CONNECTION RE-ESTABLISHMENT REQUESTなのかを識別することになる。たとえば、”00”がRRC CONNECTION REQUESTであり、”01”がRRC CONNECTION RE-ESTABLISHMENT REQUESTなどである。
【０１２３】
この場合の欠点は、LCIDで示すことの出来る領域に制限が出てくることである。端末が自分で基地局に送信するRACH preambleを選択する場合には、基地局に対してC-RNTIを通知する必要があり、その情報が含まれなくてはいけない。そのため、C-RNTIを含むMAC control elementのために、３２個中８個のLCIDを予約する必要が出てくる。しかし実際にはC-RNTIを含むMAC control elementは８個も定義されないと考えられるため、無駄にLCIDを予約することになってしまう。
【０１２４】
ここで、MACサブヘッダー内の他の領域に関しても説明を行う。拡張領域(E (Extension) field)は、さらにMACサブヘッダーが続くか否かをしめしており、”0”だと次にデータまたはMAC control elementがはいり、”1”だとMACサブヘッダーが続く形であることを示す。複数のMACサブヘッダーが続く場合の構成例を図26に示す。ここで、図26(a)は、図25に示した長さ領域(L (Length) field)無しのMACサブヘッダーのみでMACヘッダーを構成する例である。長さ領域とは、送るデータのサイズを示すものであり、これによって受信側は、次のデータまたはMAC control elementが何処から始まるかを知ることが出来る。なお、MAC control elementは長さが固定で決まっているため長さ領域が必要なく、また最後のデータも次のデータなどが無いため入れる必要が無くなる。また、長さ領域には二種類あり、7bitsのもの（図26(b)）と15bitsのもの（図26(c)）がある。ここで、どちらが使われているかがフォーマット領域(F (Format) field)で示される。また、予約ビット(R (Reserved) bit)は、後の拡張のために予備として定義されている。
【０１２５】
（従来の提案２）
二つ目の提案は、他のMACヘッダーの構成(図25(b)参照)を用いるものである。この動作では、最初の予約ビットの１bitがMACヘッダーがあるか否かを示すものとして使用される。すなわち、値が”0”だとMACヘッダーありとし、”1”だとMACヘッダー無しとして処理が行われる。RRCでは、常に先頭のbitが”1”となっているため、Message typeの識別には”10”と”11”のみが使用でき、”10”がRRC CONNECTION REQUEST、”11”がRRC CONNECTION RE-ESTABLISHMENT REQUESTのような形になる。
【０１２６】
この場合の課題は、Message typeを全て使っているため、新たにRRC messageを定義できないことである。そのため、LCIDとして定義できる範囲を無駄に使用せず、なおかつ新たにRRC messageを定義できるようにMessage typeに使用できる領域を確保しておくことが望ましい。
【０１２７】
（本実施の形態）
図27に示すように、本実施の形態でのMACヘッダーの構成の特徴は、拡張領域が先頭に存在し、その値によってMAC ヘッダーがあるか否かを判断可能としていることである。これは、72bitsしか送信用に割当てられないような場合には、複数のMACサブヘッダーを使用するという必要性が少ないという特徴をいかし、MAC ヘッダーがある場合には拡張領域を常に”0”にして一つのMACサブヘッダーのみを使用するような動作とすることにより実現される。よって、受信側は、拡張領域が”0”となっていた場合にはMACヘッダーがあるものとして処理し、”1”となっていた場合には、MACヘッダーがないものとしてRRC messageとしてRRCで処理する。RRCでは、最初の２bitsを用いてメッセージの識別を行う。具体的な例としては、”10”がRRC CONNECTION REQUEST、”11”がRRC CONNECTION RE-ESTABLISHMENT REQUESTのような形である。
【０１２８】
本方式ではMACヘッダーの２bit目にあたるがMACとしては使用されておらず予約ビットのままである。そのため、今後MACで拡張を行う際にその予約ビットを使うことが可能である。また逆に、RRC messageを追加する必要がある場合にもそのビットを使うことが可能である。具体的には、MAC ヘッダーがあるか否かを拡張領域のみで見るのではなくて、MACヘッダーの最初の２bitsに当たる拡張領域と予約ビットをみて”00”となっていた場合に、MACヘッダー無しと判断する。これにより、RRC messageを示すのに、”01”、”10” ”11”の三つを使うことが出来る。このように本方式では、拡張領域をMACヘッダーの有無の識別に利用することにより、MACの拡張、もしくはRRC messageの追加に対応している。
【０１２９】
以下図28を用いて本実施形態にかかる端末の動作を説明する。
ST2801において、端末はRandom Access Responseで割当てられたサイズを確認する。ここで、72bitsよりも多く割当てられた場合にはST2803に進む。72bitsが割当てられた場合にはST2804に進む。ST2804では、端末は、呼接続または再接続を行うのか、それ以外かを判断する。すなわち端末は、MACヘッダーを使わないか、使うかを判断する。ここで、MACヘッダーを使う場合には、ST2805に進み、使わない場合にはST2806に進む。ST2805に進んだ場合において、端末がRACHプリアンブルを自分で選択する場合（すなわちNon-dedicated RACH preamble）の場合には、ST2806に進み、基地局から与えられたRACH preambleを用いる場合にはST2803に進む。
【０１３０】
ST2803では、端末は通常どおりMACヘッダーを使用し送信データの作成を行う。一方、ST2806では、端末はMACヘッダーの最初の拡張領域が”0”となるように送信データの作成を行う。このときのMACヘッダー構成例を図29(c)、(d)、(e)、(f)に示す。また、LCIDの定義の例を図30に示す。
【０１３１】
図29(c)は、C-RNTIのみを送信している場合である。ここで、40bitsのうちの16bitsがC-RNTIとして使われ、残りの24bitsがpaddingとなっている。そのため、C-RNTIとpaddingが入っているといいうことを示すLCID(図30の11000)がここでは入れられる。
図29(d)は、C-RNTIとBSRを送信しており、C-RNTIとBSRが入っているといいうことを示すLCID(図30の11001)がここでは入れられる。これは、BSRがハンドオーバーコンプリートよりも優先されるような場合に使われる。
図29(e)は、C-RNTIとDCCH (Dedicated Control Channel)を送信している。ここで、DCCHは、前述のSRBのLogical channelとしての名称であり、high priority SRBとlow priority SRBと分かれているのと同様にDCCHとしても複数に分かれている。LCIDの定義としては、C-RNTIとhigh priority SRBとが後に送信されると示すもののみを定義することも出来るし、逆にC-RNTIとlow priority SRBとが後に送信されると示すもののみを定義することも出来るし、両方を定義しても良い。図30では両方が定義される例をしめした。そして、実際に送信するDCCHに応じてLCIDを設定する(図30の11010または11011)。
図29(f)は、C-RNTIとCQIを送信している。そのため、C-RNTIとCQIが入っているということを示すLCID(図30の11100)がここでは入れられる。
【０１３２】
ST2807では、端末は、MACヘッダー無しでメッセージを送信する。その際の送信データの例が図29(a)、(b)にそれぞれ呼接続時、再接続時として示してある。なお、Message type以外の情報の場所に関しては異なる配置でも良い。
【０１３３】
本実施の形態の動作により、LCIDとして定義できる範囲を無駄に使用せず、なおかつ新たにRRC messageを定義できるようにMessage typeに使用できる領域を確保しておくこと
が可能になる。
【０１３４】
なお、以上の説明ではC-RNTIと他の情報を組み合わせるようにLCIDを定義した例を示したが、それ以外の方法も考えられる。端末がRACHプリアンブルを自分で選択した場合、基地局は、その端末がMessage3でC-RNTIを入れることが予測できる。そのため、端末がRACHプリアンブルを自分で選択した場合には、常にMACヘッダーの後にC-RNTIを入れるような動作に決めておけば、C-RNTIと他の情報を組み合わせるようにLCIDを定義する必要が無くなる。具体的には、図31にその例を示す。図31(a)は、C-RNTIのみが入っていて、残りがpaddingになっている場合である。この場合には、LCIDとしてpaddingを示すLCIDを端末は入れる。基地局は、端末がRACHプリアンブルを自分で選択した場合には、常にMACヘッダーの後にC-RNTIを入れることがわかっているため、C-RNTIがMACヘッダーの後に来て、その後がpaddingであると理解することが可能となる。その他のケースを図31(b)、(c)、(d)に示すが、動作としては同様であり、基地局は、C-RNTIがあり、その後LCIDで示す情報が入ると理解することが可能となる。
なお、上記ではC-RNTIをMACヘッダーの直後に入れる例を示したが、その他の場所に設定することも可能である。
【０１３５】
以上説明した通信端末は、所定の手順にしたがって基地局と通信する通信端末であって、MAC制御情報に割り当てられている優先度であるMAC制御情報の優先度と、DRBおよびSRBに割り当てられている優先度との関係を確定する優先度制御部と、前記優先度制御部で確定した優先度の関係に従い、優先度の高い情報を先に送信するように制御する送信メッセージ生成部とを備える。
【０１３６】
上記構成によれば、MAC制御情報の優先度と、DRBおよびSRBに割り当てられている優先度との関係に応じて、どのような情報を送信するかを自由に制御できるようになる。したがって、通信サービスの内容や状況に応じた適切な制御が可能となる。例えば、VoIPを行っている場合にパス・スイッチングを早くする必要がある場合には、BSRよりもSRBの優先度を高くすることが考えられる。また逆に、パス・スイッチングを早く行う必要がなく、端末の持っているバッファー状態を早く把握したい場合には、BSRをSRBよりも優先度を上げることが出来る。
【０１３７】
また、当該通信端末には、前記基地局から送信される前記MAC制御情報の優先度を受信する受信部を設けることができる。
【０１３８】
また、当該通信端末は、前記MAC制御情報が、C-RNTI、BSR、およびCQIを含み、前記送信メッセージ生成部が、前記DRB、SRB、C-RNTI、BSR、およびCQIの優先度に従い、優先度の高い情報を先に送信するものである。
【０１３９】
上記構成によれば、例えば、C-RNTIを優先度1、BSRおよびCQIを優先度3に設定すれば、SRBの優先度が2の場合に、C-RNTIのみをSRBよりも優先させることができ、どのような情報を送信するかを自由に制御できるようになる。
【０１４０】
また、当該通信端末は、前記MAC制御情報の優先度の情報を保持する優先度テーブル部を備え、前記受信部が、前記MAC制御情報の優先度の境界を示す境目情報を受信し、前記優先度制御部が、前記境目情報を参照して、前記MAC制御情報の優先度と前記DRBおよびSRBに割り当てられている優先度との関係を確定するものである。
【０１４１】
上記構成によれば、少ないビット数でMAC制御情報の優先度の境目情報を設定することができるので、シグナリングのオーバーヘッドの増加を抑えることができる。
【０１４２】
また、当該通信端末は、前記優先度制御部が、RACHプロシージャの使用理由に応じて、前記MAC制御情報の優先度を指定するものである。
【０１４３】
上記構成によれば、MAC制御情報の優先度をRACHプロシージャの使用理由に応じて指定することにより、RACHプロシージャ毎に送信動作を変えることが可能となる。
【０１４４】
また、当該通信端末は、前記受信部が、前記基地局からメッセージのサイズに関する閾値を受信し、前記優先度制御部が、前記閾値を参照して、前記MAC制御情報の優先度と前記DRBおよびSRBに割り当てられている優先度との関係を確定するものである。
【０１４５】
上記構成によれば、先に送信するように設定されたメッセージが大きい場合には、MAC制御情報を先に送信して、大きなメッセージの送信に伴うオーバーヘッドを減少させることができる。
【０１４６】
また、当該通信端末は、前記受信部が、前記基地局から前記MAC制御情報と前記SRBの優先順位を決定するのに必要な情報を受信し、前記優先度制御部が、前記情報を参照して、前記SRBと前記MAC制御情報の優先順位を決定するものである。
【０１４７】
上記構成によれば、ネットワークからの指示なしに優先順位を決定することができる。
【０１４８】
また、当該通信端末は、前記MAC制御情報と前記SRBの優先順位を決定するのに必要な情報は、パス・スイッチング遅延によりパケットロスが多くなるサービスを受けているかどうかを示す情報、ハンドオーバーが前記基地局内のハンドオーバーかどうかを示す情報、およびハンドオーバーが前記基地局間のハンドオーバーかどうかを示す情報を含むものである。
【０１４９】
上記構成によれば、VoIPを使っているか否か、および基地局内または基地局間ハンドオーバーか否かをもとに、ネットワークからの指示なしにSRBとMAC制御情報の優先順位を決定することができる。
【０１５０】
また、当該通信端末は、MACサブヘッダー内の先頭に、MACサブヘッダーが次に続くか否かを示す拡張領域を配置し、MACサブヘッダーの72bitsのみのリソースが割当てられた場合に、MACヘッダーが存在するか否かを、MACヘッダーの最初に位置する拡張領域の値によって示すものである。
【０１５１】
上記構成によれば、端末は新たなbitを使用せずにMACヘッダーが存在するか否かを基地局に通知することが出来る。
【０１５２】
このように、上記通信端末によれば、MAC制御情報の優先度と、DRBおよびSRBに割り当てられている優先度とを比較することにより、どのような情報を送信するかを自由に制御できるようになる。
【０１５３】
また、上記説明した基地局は、MACサブヘッダー内の先頭に、MACサブヘッダーが次に続くか否かを示す拡張領域を配置し、MACサブヘッダーの72bitsのみのリソースが割当てられた場合に、MACヘッダーが存在するか否かを、MACヘッダーの最初に位置する拡張領域の値によって判断するものである。
【０１５４】
上記構成によれば、基地局は新たなbitを使用せずにMACヘッダーが存在するか否かを判断することが出来る。
【０１５５】
本出願は、２００８年２月１日出願の日本特許出願、特願２００８−０２３１７１に基づくものであり、その内容はここに参照として取り込まれる。
【０１５６】
以上、本発明の各種実施形態を説明したが、本発明は前記実施形態において示された事項に限定されず、明細書の記載、並びに周知の技術に基づいて、当業者がその変更・応用することも本発明の予定するところであり、保護を求める範囲に含まれる。
【産業上の利用可能性】
【０１５７】
本発明は、MAC制御情報に優先度を割り当て、どのような情報を送信させるかを自由に制御することができる通信端末及び送信メッセージ生成制御方法等として利用可能である。
【符号の説明】
【０１５８】
701,2201 受信部
702,1101 優先度table部
703,1001,1301,1701,2202 優先度制御部
704,1002,1302,2203 送信message生成部
705 SRB生成部
706 DRB生成部
707 バッファー部
708 MAC情報生成部
709 送信部
【技術分野】
【０００１】
本発明は、所定の手順にしたがって通信する通信端末及び送信メッセージ生成制御方法に関する。
【背景技術】
【０００２】
現在標準化が行われているE-UTRA/E-UTRANにおいては、端末から基地局への上り回線（UL:Up Link）/基地局から端末への下り回線（DL:Down Link）双方とも時間多重が採用されている。上りにおいては、基地局が複数の端末からデータを受信する際、複数の端末が送信したデータの受信タイミングがずれてしまっては、時間多重が効率よく行えない。そのため、時間多重システムにおいては、複数の端末から送信されたデータを、基地局が一定の遅延以内で受信できるように端末の送信タイミングを調整する必要がある。
【０００３】
これを上り同期(uplink synchronization、Timing adjustment、Timing alignment等も使われる)と呼ぶ。端末が上り同期を取る為に必要な動作がRACH手順（RACH プロシージャ(Random Access CHannel procedure）)である。最初にこのRACH procedureの概要に関して説明し、その後本発明で着目したMessage3送信に関して述べる。
【０００４】
［RACH procedure概要］
E-UTRA/E-UTRANにおいてはこのRACH procedureが様々なケースに使われる。RACH procedureの使用理由は、具体的には、呼接続（Initial access）、ハンドオーバーコンプリート（Handover complete）メッセージ送信、UL/DL データ送受信再開（UL/DL data resuming）、再接続（Radio link failure recovery）がある。
【０００５】
Initial accessは、端末がアイドル（RRC_IDLE）状態から呼接続を行う場合である。端末がIDLE状態であるため、基地局との上り同期が取れていない。
【０００６】
Handover complete送信は、端末がhandoverを実施して、受け渡し先（target）の基地局に端末が移動したことを通知する場合である。Targetの基地局とはいままでつながっていないので、ここで同期を取る。
【０００７】
UL/DL data resumingは、間欠受信（DRX）を行っていた端末が、ULもしくはDLのデータを送受信し始める場合である。端末の上り同期はしばらくすると外れてしまうので、同期を取り直す必要がある。
【０００８】
Radio link failure recoveryは、端末が繋がっていたセルを検出できなくなった後に、新たに見つけた(または繋がっていた)セルに対して再接続する場合である。Initial accessと状況が似ている。
【０００９】
また、RACH procedureには大きく二つのタイプが存在する。一つは、端末が自分で基地局に送信するRACH プリアンブル（RACH preamble）を選択する場合（non-dedicated RACH preambleの場合）であり、もう一つは、端末が基地局から与えられたRACH preambleを使用する場合（dedicated RACH preambleの場合）である。
【００１０】
それぞれの動作を図1(a)、(b)に示す。大きな違いとしては、non-dedicated RACH preambleの場合には、複数の端末が同時に同じRACH preambleを使用する可能性があるため、衝突の有無を確認するためのメッセージ（Message4: Contention resolution）が使用されるのに対し、dedicated RACH preambleの場合には、割り当てメッセージ（Message0: RA preamble assignment）によって、使用するRACH preambleを割り当てる点である。
【００１１】
また、Message1、Message2までは全てのケースに関して同じであるが、Message3、Message4がそれぞれのケースに応じて送信されるものが異なる。なお、dedicated RACH preambleを使用することが出来るのは、上記のうちHandover complete送信、DL data resumingのみである。これは、基地局がRACH preambleを割り当てる動作ができるのがその二つの場合に限られているからである。
【００１２】
この二つのprocedureを図2にそれぞれ示す。なお、Handover complete送信、DL data resumingに対しても、常にdedicated RACH preambleが使用されるわけではなく、non-dedicated RACH preambleが使用されることもありうる。
【００１３】
non-dedicated RACH preambleとdedicated RACH preambleのもう一つの大きな違いは、dedicated RACH preambleの場合には、基地局はそれを受信した時点で端末を識別できることである。これによって、それ以降のメッセージでどの端末がRACH preambleを送ったかを確認する作業が不要となる。
【００１４】
言い換えれば、non-dedicated RACH preambleの場合にはMessage 3中に、どの端末がアクセスしてきたかを示す為に、端末のIDを入れる必要がある。この端末のIDは、端末がアクティブ（RRC_CONNECTED）の場合にはセル（cell）単位で使用されるC-RNTI（Controlling Radio Network Temporary Id）が使用され、端末がinitial accessを行う場合にはTracking area(IDLEの端末の移動管理の単位)内で使用されるS-TMSI（S-Temporary Mobile Subscriber Identity）、または端末固有のID(電話番号相当)であるIMSI（International Mobile Subscriber Identity）が使われる。また、radio link failure recoveryの際には、radio link failureを起こす前につながっていたセルのセル識別子（Cell ID）、そのセルでのC-RNTI等が使用される。
【００１５】
［Message3送信］
端末が最初に基地局に対してデータを送信できるのがMessage3であり、そのための情報がMessage2で割り当てられる。しかしながら、Message3のサイズは、端末がセルエッジにいるような場合には72bits程度になってしまうことが知られている。
【００１６】
そのため、全ての情報を一度に送信するのは困難な場合が考えられる。どのようにMessage3が構成されているかを示すために、図3、4、5にそれぞれMAC（Medium Access Control）、RLC（Radio Link Control）、PDCP（Packet Data Convergence Protocol）のヘッダー（header）構成を示す。また、protocolの構成を図14に示す。以下はその概略説明である。
【００１７】
（MAC）
3種類のMACサブヘッダーが用意されており、最小のサブヘッダーが8bitとなっている。LCID (Logical Channel ID)を用いてどのデータが入っているかを示しており、拡張領域（E（Extension）field）でMACサブヘッダーの次にMACサブヘッダーがあるか否かをしめし、長さ領域（L（Length） field）でデータのサイズを示している。
【００１８】
MAC control element (MACの制御情報: 上りとしてはC-RNTI、Buffer status report(バッファ状態報告、端末のバッファーの状況を示すもの。以下BSR)、CQI(Channel Quality Indicator、チャネル品質インジケータ：端末のチャネル状況を示すもの))もLCIDで示される。この場合には、サイズが決まっているため、L fieldはいらない。
【００１９】
（RLC）
RLC AM (acknowledge mode)用に16bitのヘッダーが、RLC UM (unacknowledge mode)用に16bit(長いデータ用に10bitSN)と8bit(短いデータ用に5bitSN)が定義されている。
【００２０】
（PDCP）
SRB (signaling radio bearer、シグナリング無線ベアラ:制御メッセージであるRRC messageを運ぶためのベアラ)とデータ無線ベアラ（data radio bearer：データを運ぶためのベアラ。以下DRBと呼ぶ)とで異なるheaderが定義されている。SRBの場合には40bitsのheaderが必要になる。
データ無線ベアラはユーザプレーン無線ベアラ（user radio bearer）と呼ばれること
もある。
【００２１】
また、Handover completeは、RRC messageとしてメッセージタイプ（message type：メッセージの種類を示すもの)、トランザクション識別子（transaction id：どのメッセージの応答なのかを示すもの)などを含むと考えられており、8bitを想定している。
【先行技術文献】
【非特許文献】
【００２２】
【非特許文献１】TS25.321: “Medium Access Control (MAC) protocol specification”
【発明の概要】
【発明が解決しようとする課題】
【００２３】
上記説明から、Handover completeの送信を考えると、端末が72bitsのみ送信用に割当てられた場合には、表１のように二度に分けて送信することが必要となることがわかる。また、Handoverを行った後にはBSRを送信することが決まっている。UMTS（Universal Mobile Telecommunication System）において、MAC control情報(LTEでのMAC control element)は、常にSRB、DRBよりも優先度が高いとされている（非特許文献1参照）。
【００２４】
そのため、このBSRをHandover completeよりも先に送ることが想定される。この場合、表2のように三度にわけて送信することになり、さらにはHandover completeの送信が遅れてしまうこととなってしまう。
【００２５】
【表１】
【００２６】
【表２】
【００２７】
上述したとおり、MAC control element(例えばBSR)が優先される場合には、Handover completeの送信が遅れることが考えられる。これは、下記のようなデメリットをもつ。
【００２８】
（ネットワークでのパス切り替え（path switching）遅延）
基地局は、Handover completeを受信することで、端末が移動してきたと確実に判断できる。そのため、ネットワーク内での切り替え(元の基地局から新しい基地局へのパス切り替え)は、Handover completeを受信したタイミングで行われる。path switchingが遅れると、元の基地局から新しい基地局に転送されないデータなどは廃棄されてしまう。
【００２９】
図15にネットワーク側の基地局とコアネットワーク（Core network）のエンティティ（entity）との関係を示す。Handover completeを新しい基地局(Target eNB)が受信して、Core networkのentityにパスの切り替えを行うまでは、Core networkのentityは前の基地局(source eNB)に対してデータを送信し続ける。
【００３０】
これは、前の基地局が新しい基地局にデータを転送するような場合には問題ないが、例えば、VoIPなどのリアルタイムサービスではパケットの転送がされないと考えられている。これを最低限に抑えるために、path switching遅延を短くすることが求められている。
【００３１】
（下りの送信開始遅延）
基地局は、Handover completeを受信することで、端末が移動してきたと確実に判断でき、下りのデータ送信を開始できる。そのため、Handover completeの受信が遅れると、元の基地局から新しい基地局に転送されているデータがある場合に、下りのデータ送信開始が遅れることとなってしまう。
【００３２】
上記のようなことを考えると、常にMAC control elementを優先することは望ましくない。そのため、MAC control elementの優先度（priority）を制御する必要がある。
【００３３】
本発明は、上記従来の事情に鑑みてなされたものであって、MAC制御情報に優先度を割り当て、どのような情報を送信させるかを自由に制御することができる通信端末及び送信メッセージ生成制御方法を提供することを目的としている。
【課題を解決するための手段】
【００３４】
本発明の通信端末は、基地局と通信する通信端末であって、複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、前記基地局へ送信する制御情報の優先度を制御する優先度制御部と、前記制御に従い前記優先度を考慮して送信メッセージを生成する送信メッセージ生成部と、を備えるものである。
【００３５】
上記構成によれば、複数のMAC制御情報に個別に割り当てられているMAC制御情報の優先度と、複数のSRBに個別に割り当てられている優先度とを考慮して送信メッセージを生成することができる。
【００３６】
また、本発明の通信端末は、前記制御情報の優先度を制御するための情報を前記基地局から受信する受信部をさらに備えるものである。
【００３７】
また、本発明の通信端末は、前記MAC制御情報の優先度は予め決められており、前記基地局から受信した優先度を制御するための情報を用いて前記SRBを含めた優先度を制御するものである。
【００３８】
本発明の送信メッセージ生成制御方法は、基地局と通信する通信端末により実行される方法であって、複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、前記基地局へ送信する制御情報の優先度を制御するステップと、前記制御に従い前記優先度を考慮して送信メッセージを生成するステップと、を備えるものである。
【００３９】
上記構成によれば、複数のMAC制御情報に個別に割り当てられているMAC制御情報の優先度と、複数のSRBに個別に割り当てられている優先度とを考慮して送信メッセージを生成することができる。
【００４０】
また、本発明の送信メッセージ生成制御方法は、前記制御情報の優先度を制御するための情報を前記基地局から受信するステップをさらに備えるものである。
【００４１】
また、本発明の送信メッセージ生成制御方法は、前記MAC制御情報の優先度は予め決められており、前記基地局から受信した優先度を制御するための情報を用いて前記SRBを含めた優先度を制御するものである。
【発明の効果】
【００４２】
本発明の通信端末及び送信メッセージ生成制御方法によれば、MAC制御情報に優先度を割り当て、MAC制御情報の優先度が通信端末に送信するので、通信端末がどのような情報を送信するかを自由に制御できるようになる。
【図面の簡単な説明】
【００４３】
【図１】non-dedicated RACH preambleとdedicated RACH preambleの動作を示す図
【図２】Handover complete送信およびDL data resumingのprocedureを示す図
【図３】Message3のMACのヘッダー構成を示す図
【図４】Message3のRLCのヘッダー構成を示す図
【図５】Message3のPDCPのヘッダー構成を示す図
【図６】本発明の実施形態２の概念を示す図
【図７】本発明の実施形態２にかかる端末のブロック図
【図８】本発明の実施形態２にかかるprocedureの具体例を示す図
【図９】本発明の実施形態３の概念を示す図
【図１０】本発明の実施形態３にかかる端末のブロック図
【図１１】本発明の実施形態３においてMAC control elementの優先順位自体をRACH procedureの使用理由ごとに変えることを説明するための図
【図１２】本発明の実施形態４の概念を示す図
【図１３】本発明の実施形態４にかかる端末のブロック図
【図１４】Message3のprotocolの構成を示す図
【図１５】ネットワーク側の基地局とCore networkのentityとの関係を示す図
【図１６】本発明の実施形態１においてMAC control element毎にpriorityを設定する概要を示す図
【図１７】本発明の実施形態１にかかる端末のブロック図
【図１８】本発明の実施形態２におけるMAC control elementの優先度のtable、boundary情報の例を示す図
【図１９】本発明の実施形態２において基地局が端末のスピードを考慮する際の動作を示す図
【図２０】本発明の実施形態２において一時的にpriorityを変更する動作を示す図
【図２１】本発明の実施形態３においてsemi-persistent schedulingを用いて送信する場合に使用するboundary情報を端末に送信する方法を示す図
【図２２】本発明の実施形態５にかかる端末のブロック図
【図２３】本発明の実施形態５にかかる動作の本質を示すフローチャート
【図２４】本発明の実施形態２において端末がinitial access (呼接続)、Radio link failure recovery(再接続)を行う場合の流れを示す図
【図２５】従来の提案で使用されるＭＡＣサブヘッダーの構成を示す図
【図２６】従来の提案１にかかるＭＡＣサブヘッダーの構成を示す図
【図２７】本発明の実施形態６にかかるＭＡＣサブヘッダーの構成を示す図
【図２８】本発明の実施形態６にかかる端末の動作の概要を示す図
【図２９】本発明の実施形態６にかかるＭＡＣヘッダーの構成例を示す図
【図３０】本発明の実施形態６にかかるLCIDの定義の例を示す図
【図３１】本発明の実施形態６にかかるＭＡＣヘッダーの他の構成例を示す図
【発明を実施するための形態】
【００４４】
以下、基地局と端末とが、RACH procedureの実施に先立ち、送信するデータの優先度を確定する例を説明する。なお、下記各実施の形態は、図1に示したnon-dedicated RACH preambleの場合及びdedicated RACH preambleの場合のいずれにも同様に適用できる。
【００４５】
＜実施の形態1＞
SRB（signaling radio bearer：制御メッセージであるRRC messageを運ぶためのbearer）、DRB（user plane radio bearer /data radio bearer：データを運ぶためのbearer）は、それぞれ優先度（priority）を持っている。現状SRBとしては優先度の高いRRC messageを送るためのhigh priority SRB（SRB2）と通常のSRBとしてのpriorityを持つlow priority SRB（SRB1）がRRC_CONNECTEDの端末が通信するために存在する。また、initial access、Radio link failure recoveryなどでRRC_CONNECTEDに端末が移るまでのRRC messageを運ぶために別のSRB(SRB0)が定義されている。DRBとしては、端末が使用するサービスに応じて追加され、例えばVoIPのためのDRB、web browsingのためのDRB、emailのやり取りのためのDRBなどが設定される。
【００４６】
ここで、端末がどのbearerを送信すればよいかを基地局側で制御できるように、priorityがbearerごとに設定されている。基本的にSRBはDRBより高い優先度を持つ。また、DRBの中では遅延に対する要求が厳しい（time critical）サービスのためのbearerほど高い優先度を持つ。そのため、上記の例では下記のような優先度が考えられる。
【００４７】
High priority SRB > low priority SRB > DRB for VoIP > DRB for web browsing > DRB for email
【００４８】
本実施の形態では、SRB、DRBと同じようにMAC control element毎にpriorityを設定する。その概要を図16に示す。この図に示されるように、例えば、priorityの値が1-8まであり、1が一番高い場合に、MAC control elementの中で一番優先度の高いと考えられるC-RNTIを優先度1、次に優先度の高いと考えられるBSR、CQIなどを優先度3と設定することが考えられる。
【００４９】
ここで、high priority SRBの優先度が2となった場合には、C-RNTIのみがhigh priority SRBよりも優先される。このような動作により、端末にどのような情報を送信させるかを自由に制御できるようになる。
【００５０】
具体的には、端末がVoIPを使用していてpath switchingを早くする必要がある場合には、BSRよりもhigh priority SRBの優先度を高くすることが考えられる。また逆に、path switchingを早く行う必要がなく、端末の持っているbuffer状態を早く把握したい場合には、BSRをhigh priority SRBよりも優先度を上げることが出来る。
【００５１】
（ブロック図）
図17を用いて本発明の端末のブロック図を示す。図17に示す通信端末は、受信部701と、SRB生成部705と、DRB生成部706と、優先度制御部1701と、送信message生成部704と、バッファー部707と、MAC情報生成部708と、送信部709とを備える。各部の主要動作、役割は下記のとおりである。
【００５２】
701は、受信部であり基地局からのメッセージを受信する。受信部701は、MAC control element毎の優先度を受信し、優先度制御部1701に送る。また、受信部701は、端末が送信するメッセージサイズを受け取り、送信message生成部704に送る。705は、SRB生成部であり、RRC message、NAS message等のSRBを用いて送信するメッセージの作成を行う。706は、DRB生成部であり、user planeデータの作成を行う。
【００５３】
1701は、優先度制御部であり、受信部701からMAC control element毎の優先度を受信する。優先度制御部1701は、MAC control element毎の優先度と通常DRB、SRBに割当てられている優先度とにより、” C-RNTI > SRB > BSR > CQI > DRB”、または” C-RNTI > high priority SRB > BSR > low priority SRB > CQI > DRB”のような、MAC control elementとSRBの優先度の関係を確定する。そして優先度制御部1701は、その結果を用いて、送信message生成部704に、priorityの高い情報を先に送信するような送信メッセージを作成させるよう制御する。
【００５４】
704は、送信message生成部であり、優先度制御部1701からの優先度情報と、受信部701からの送信メッセージサイズをもとに送信メッセージを作成する。送信message生成704は、後述するMAC情報生成部708よりMAC control elementを受け取り、送信可能なbearerとその量をバッファー部707に通知し、バッファー部707よりSRBまたはDRBの送信すべき情報を受け取ることも行う。
【００５５】
707は、バッファー部であり、SRB生成部705とDRB生成部706からの情報を保持し、送信message生成部704の指示に応じて送信message生成部704に送信する。
【００５６】
708は、MAC情報生成部であり、MAC control elementを生成し、送信message生成部704に通知する。具体的には、MAC情報生成部708は、C-RNTIを送信する必要があるときには、送信message生成部704にC-RNTIを渡す。また、MAC情報生成部708は、BSRを送信する必要があるときにはバッファー部707の情報からBSRを生成、送信するなどである。709は、送信部であり、送信message生成部704で作成したメッセージを基地局に送信する役割を持っている。
【００５７】
以上説明したように、本実施の形態によれば、MAC control element毎に自由にpriorityを設定できるため、RACH procedureのMessage3で優先して基地局へ送信すべきデータを、通信サービスの内容や状況に応じて適切に制御できる。
【００５８】
＜実施の形態2＞
本実施の形態の概念を示す図を図6に、また、端末のブロック図を図7、本動作のprocedureの具体例を図8に示す。
【００５９】
実施の形態1では、MAC control element毎に自由にpriorityを設定できるようにした。しかしながら、実施の形態１の方式では基地局が端末に対してpriorityの設定を行うシグナリング（signaling）のオーバーヘッド（overhead）が増加してしまうという課題が存在する。本実施の形態では、MAC control element内での優先度を予め決めておき、SRBに対して高い優先度を持つMAC control elementと低い優先度のMAC control elementの境目（boundary）のみを設定することにより、上記課題を解決する。その概要を図6に示す。
【００６０】
図6(a)のように、MAC control elementはMAC control element内での優先度を決定する。これは、標準化などの仕様（spec）などで規定することが考えられ、報知情報等で送信するのでもよいし、個別のRRC messageで送っても良い。本実施の形態では、標準化などの仕様（spec）などで規定する例に関して説明する。そして、設定するのは、SRBよりも高い優先度となるMAC control elementと低い優先度となるMAC control elementの境目である。具体的には、図6(a)の例でのboundary1-4のどれかを指示することとなる。このときのsignaling例が図6(b)である。なお、図6(b)に示される手順は、図１(a)に示すMessage1以前に実施される。
【００６１】
具体的には、boundary2が指定された場合には、下記のようなpriorityの順になる。
C-RNTI > SRB > BSR > CQI > DRB
【００６２】
また、上記ではSRBとしてひとくくりとしたが、MAC control elementの優先度をhigh priority SRBと比較して設定することも考えられる。そのような場合には下記のようになる。
C-RNTI > high priority SRB > BSR > low priority SRB > CQI > DRB
【００６３】
（ブロック図）
図7に、本実施の形態の端末のブロック図を示す。図７に示す端末は、図１７に示した端末の優先度制御部1701に代えて優先度制御部703と優先度table部702を備える。各部の主要動作、役割について、実施の形態１と異なる点を説明する。
【００６４】
本実施の形態において、受信部701は、実施の形態１で説明した役割に加え、基地局から上記で説明したboundary情報を受信し、優先度制御部703に通知する役割を有する。
【００６５】
優先度table部702は、図6(a)に示すMAC control element内の優先度の情報を保持しており、それを優先度制御部703に通知する役割を持っている。
【００６６】
優先度制御部703は、受信部701からのboundary情報と優先度table部702からの優先度table部情報とにより、” C-RNTI > SRB > BSR > CQI > DRB”、または” C-RNTI > high priority SRB > BSR > low priority SRB > CQI > DRB”のような、MAC control elementとSRBの優先度の関係を確定する。そして優先度制御部703は、その結果を用いて、送信message生成部704に、priorityの高い情報を先に送信させるように制御する。
【００６７】
（詳細説明）
本発明の動作を図7、図8を用いて説明する。なお図8はhandover送信のprocedureの具体例である
【００６８】
図8に示されているように、まず、基地局（Source cell）から端末（UE）にboundary情報が通知される（ST8-1:RRC CONNECTION RECONFIGURATION message）。このboundary情報は、受信部701で受信され、優先度制御部703に渡される。優先度制御部703は、ST8-1で受信されたboundary情報と、優先度table部702に保持されている図6(a)に記載のMAC control element内の優先度を示すtableという二つの情報から、MAC control elementの優先度の情報を得る。優先度制御部703は、これを送信Message生成部704に伝える。
【００６９】
次に、送信message生成部704で作成されたST8-1に対する応答メッセージが、端末の送信部709から基地局に送信される（ST8-2: RRC CONNECTION RECONFIGURATION COMPLETE message）。
【００７０】
そして、基地局は、端末にHandoverの実施を通知する（ST8-3: Handover Command message）。それに応じて端末はhandoverを実施する。なお、この処理は一般的な動作であり、本発明とは直接関係しないため、説明を省略する。
【００７１】
なお、Handover Command、Handover Complete messageは、それぞれ基地局が端末にHandoverを指示するメッセージ、端末が基地局にHandoverの完了を示すメッセージの総称であり、E-UTRA/E-UTRANでは、RRC CONNECTION RECONFIGURATION message、RRC CONNECTION RECONFIGURATION COMPLETE messageがそれぞれ使われる。
【００７２】
ST8-3の後に実施される、ST8-4: Random Access preamble、ST8-5: Random Access responseは、通常のRACH procedureでありここでは詳細な説明を省略する。ST8-5の後、送信message生成部704は、ST8-5で受け取ったリソース割当情報を元に、Message3でのmessage sizeを決定する。このmessage sizeは、受信部701から送信message生成部704に送られる。
【００７３】
ここで、Handover completeとBSRとを両方送りたい場合で、１つのメッセージに両方が入りきらない場合にはpriorityによってどちらを優先するかを決定することとなる。すなわち、BSR > SRBとなっていればBSRを優先するし、BSR < SRBとなっていればHandover completeを優先することとなる。そのため、優先度制御部703で決定された優先度によって、ST8-6、ST8-8で送られる内容が、Handover completeになるかBSRになるか変わってくる。
【００７４】
MAC control elementの優先度のtable、boundary情報の例を図18(a)、(b)にそれぞれ示す。このように、MAC control elementの優先度をtableで持ち、RRC messageの優先度(high priority SRBのみでも良いし、low priority SRBと両方でも良いし、low priority SRBのみでも良い)がboundary情報で通知されるため、送信する内容を制御することが出来る。
【００７５】
次に、基地局がどのようにこのboundary情報を決定するかについて説明する。前述の通り、Handover Complete messageの送信の遅延は、network側のPath切り替えの遅延を引き起こす。このPath切り替えの遅延の影響を大きく受けるのは、前述のとおり元の基地局からHandover先の基地局にデータの転送を行わないVoIPのようなリアルタイムサービスである。
【００７６】
そのため、Handover Completeの送信を、VoIPを行っている端末のみに優先させるという処理が考えられる。また、パスを切り替えるための情報として、基地局間でやりとりする端末情報の有効性も考えられる。Handover時に基地局間で端末の情報のやりとりを行う。
【００７７】
この際に、端末の受信品質、端末のバッファー状態、などの情報もやり取りされる。端末の移動速度がそれほど速くなく、端末の受信品質が基地局間でやり取りされる情報で十分な場合には、CQIの優先度を下げることが考えられるし、逆に端末の移動速度が速い場合にはCQIの優先度をあげることが考えられる。
【００７８】
また、端末のバッファー状態が変動しやすいサービス、変動しにくいサービスが考えられる。例えば、VoIP等のサービスではバッファー状態はそれほど変動しない。それに比べてuploadを行うような場合にはバッファー状態が大きく変動することが考えられる。
【００７９】
そのため、変動しにくいサービスのみを行っている場合には、BSRの優先度を下げて、逆に変動しやすいサービスを行っている場合にはBSRの優先度をあげることが考えられる。このような動作により、端末が送信すべき情報を制御できるようになる。
【００８０】
なお、本実施の形態では、MAC control elementに対して一つのboundaryのみを設定する例を示したが、設定するboundaryを増やすことも可能である。具体的には、high priority SRBに対するboundary(例えば図6(a)のboundary2)とlow priority SRBに対するboundary(例えば図6(a)のboundary3)を設定し、”C-RNTI > high priority SRB > BSR >CQI > low priority SRB > DRB”のような優先度に設定することも考えられる。
【００８１】
本実施の形態では、SRBのみに対してMAC control elementの優先度を設定できるようにした。しかしながら、一番優先度の高いDRBに対して設定することも可能である。すなわち、”C-RNTI > SRB > BSR > high priority DRB > CQI > other DRB”のような処理を、boundary情報を複数持つことで実現が可能である。
【００８２】
本実施の形態ではHandover completeの送信の例を示したが、その他の場合にも適用可能である。具体的な例としては、UL data resumingがあげられる。UL data resumingは、端末がDRX中に送信するデータが発生した場合の動作である。
【００８３】
具体的には、端末の受信状態を示す測定結果(RRC messageとしてはMeasurement report)を送信することや、新たなサービスの追加を求めるサービス要求(NAS messageとしてはservice request等)を送ることが考えられる。測定結果を示すMeasurement reportはHandoverの実施に必要なため、優先度が高いメッセージである。
【００８４】
そのため、端末の移動速度が速い場合にはこのメッセージを早く送信しなければいけないという課題がある。前述の通り、基地局が端末の移動速度を考慮することにより、この際に、発生したデータを送るのか、それともBSRを優先するのか、CQIを優先するのかを本実施の形態に示した処理で決定できる。その際の動作を図19に示す。
【００８５】
MAC control elementの優先度をLCIDの順番の通りにすることも可能である。前述の通り、MAC control elementは、それぞれLCIDで示される。例えば、BSRは11100、CQIは11101などである。ここで、そのLCIDの順番がpriorityの順番となるように定義することで、端末に優先度のtableを特別に用意することが必要なくなるなどのメリットがある。
【００８６】
本実施の形態では、図8に示したように、Handover CommandとBoundary情報の通知を別のメッセージとしたが、Handover CommandにてBoundary情報を通知、変更することも可能である。
【００８７】
本実施の形態では、端末がVoIPを行っていてHandover completeを優先すべき時などにRRC messageのpriorityをあげるように設定する動作をしめした。しかしながら、同一基地局内のセル間のHandoverの際には状況が異なってくるという課題が存在する。
【００８８】
これは、基地局のswitchingがおこらないため、Handover completeを早く送信する必要がなくなるためである。これを実現するために、一時的にpriorityを変更するような動作が考えられる。
【００８９】
図20にその際の動作を示す。ここで図8との大きな違いは、ST8-3に相当するST20-1にて、temporaryなpriorityを割当てている点である。このtemporaryなpriorityは、基地局が送信したST20-1: Handover Commandに対する応答にのみ適用されるものであり、Handover Completeのみに適用される。
【００９０】
本発明では、RACH procedureのMessage 3に着眼して説明したが、本実施の形態は、通常の上り送信全てに適用可能である。
【００９１】
通常の上り送信全てに使用する際の典型的な例として、端末がinitial access (呼接続)、Radio link failure recovery(再接続) を行う場合が考えられる。その流れを図24に示す。端末が呼接続、再接続を行う際には、ネットワーク側は端末の受信状況などを正確に知らない。そのため、CQI等の情報が必要である。
【００９２】
しかしながら、その一方で、端末がST2406aで送る信号には、Core networkに送る情報が入っており、それを送らなければ最終的に呼接続は終了しない。その一方で、ST2406bは主に確認応答のみに使われる。
【００９３】
そのため、ST2404a、ST2404bで与えるboundary情報により、initial access時にはSRB (すなわちRRC CONNECTION SETUP COMPLETE)を優先するといった動作が可能になる。これにより、呼接続の遅延がMAC control elementの送信により増大するといった課題を解決できる。
【００９４】
＜実施の形態3＞
本実施の形態の概念を示す図を図9に、また、端末のブロック図を図10に示す。実施の形態2では、RACH procedureを使用する全ての場合に対して同じpriority設定を使用する場合を示した。しかしながら、RACH procedureの使用理由によって、必要な情報が若干異なるため、RACH procedureを行う理由ごとにそのpriorityを決定することが考えられる。本実施の形態によれば、RACH procedureの使用理由に応じて、より適切な送信データの制御が可能となる。以下に、RACH procedureを行う理由ごとのpriorityの決定例を示す。
【００９５】
（Handover completeの送信）
BSRはそれほど変更が無ければ、元の基地局から移動先の基地局に通知されたものが使用できると考えられる。そのため、Handover complete(すなわちSRB)を優先することが考えられる。
【００９６】
（上りの送信開始遅延）
端末がどれだけ情報を持っているかを知るために、BSRが必要となる。そのため、SRBよりもBSRを優先することが考えられる。
【００９７】
（下りの送信開始遅延）
下りの送信を行う為に、CQIが必要だと考えられる。そのため、CQIを優先することが考えられる。
【００９８】
図9(b)にこれを実現する為の情報の指示の動作を示している。このようにboundary情報をRACH procedureの使用理由ごとに決めることで、RACH procedure毎に動作を変えることが可能となる。
【００９９】
（ブロック図）
図10に、本実施の形態の端末のブロック図を示す。図10に示す端末は、図7に示した端末の優先度制御部703、送信message生成部704に代えて、優先度制御部1001、送信message生成部1002を備える。以下、異なる点のみを説明する。優先度制御部1001は、RACH procedureの理由ごとに異なるpriorityの設定を持つことができ、それを送信message生成部1002に通知する。送信message生成部1002は、RACH procedureの理由ごとに異なるpriorityの設定を用いて送信メッセージを生成する。
【０１００】
なお、本実施の形態では、boundary情報のみをRACH procedureの理由ごとに設定する例を示したが、MAC control elementの優先順位自体をRACH procedureの使用理由ごとに変えるにすることも可能である。この場合、図11に示すように、図10に示した優先度table部702に代えて優先度table部1101を備え、優先度table部1101に、RACH procedureの使用理由ごとの優先度を設定しておけばよい。
【０１０１】
具体的には、下記のような例が考えられる。
Handover complete: C-RNTI >BSR > CQI
UL data resuming: C-RNTI > BSR > CQI
DL data resuming: C-RNTI > CQI > BSR
【０１０２】
また、本実施の形態で示したRACH procedureの使用理由（cause）によって異なるpriorityを用いる動作を、同じbearerであってもdynamic schedulingとsemi-persistent schedulingとで異なるpriorityを設定する場合にも適用できる。E-UTRA/E-UTRANでは、毎回データをPDCCH (Physical Downlink Control Channel)で割当てるdynamic schedulingと、一度PDCCHで割当てたら一定の周期でそのリソースを使い続けるsemi-persistent schedulingとがある。このsemi-persistent schedulingは、VoIPのように定期的にデータが同じサイズで送られるようなサービスに適している。しかしながら、BSR、CQIなどの情報をVoIPのデータより優先して送信しようとするとsemi-persistent schedulingで割当てたリソースでは入りきらず、VoIPのデータを一度に送れないという課題が存在する。そこで、MAC control elementに対する優先度をDRBにも適用し、さらにDRBに対するscheduling方法によってpriorityの設定を変えることにより、上記課題の解決が実現できる。具体的には、semi-persistent schedulingを用いて送信する場合に使用するboundary情報を端末に送信する方法が考えられる(図21)。すなわち、boundary1が示された場合には、端末はsemi-persistent schedulingの時のみにVoIPデータをBSR、CQIより優先し、dynamic schedulingの場合にはBSR、CQIを通常どおり優先することとなる。
【０１０３】
＜実施の形態4＞
本実施の形態の概念を示す図を図12に、また、端末のブロック図を図13に示す。実施の形態2では、SRBをMAC control elementよりも優先できるようにする手段を提供した。しかしながら、MAC control elementよりも優先されるメッセージのサイズが大きい場合には、先にMAC control elementを送ったほうが良いことが考えられる。
【０１０４】
そのため、本実施の形態では、MAC control elementよりも優先されるメッセージが所定のサイズよりも小さい場合のみMAC control elementよりも優先する。そのための閾値（Threshold）は、図12(b)に示されるようにboundary情報と合わせて送られる。
【０１０５】
（ブロック図）
図13に、本実施の形態の端末のブロック図を示す。図13に示す端末は、図7に示した端末の優先度制御部703、送信message生成部704に代えて、優先度制御部1301、送信message生成部1302を備える。以下、異なる点のみを説明する。優先度制御部1301は、MAC control priorityより優先するSRBまたはDRBを送信するか否かを判断するために使用する閾値を受信、処理し、それを送信message生成部1302に送る。送信message生成部1302は、優先するSRBまたはDRBのサイズが閾値を下回っているか否かを判断し、閾値を下回っているときのみ、MAC control elementよりもSRBまたはDRBを優先して送信するよう送信メッセージを作成する。
【０１０６】
＜実施の形態5＞
本実施の形態の端末のブロック図を図22に、動作の概要を示すフローチャートを図23に示す。実施の形態2では、MAC control elementとSRBの優先順位をネットワークからの指示により決定する方法を示した。本実施の形態では、ネットワークからの指示なしに優先順位を決定する動作を示す。
【０１０７】
（ブロック図）
図22は、本実施の形態の端末のブロック図を示す。図22に示す端末は、図7に示した端末の受信部701、優先度制御部703、送信message生成部704に代えて、受信部2201、優先度制御部2202、送信message生成部2203を備える。以下、異なる点のみを説明する。
【０１０８】
受信部2201は、受信部701と異なり、boundary情報を受信し優先度制御部703に通知するのではなく、MAC control elementとSRBの優先順位を決定するのに必要な情報を優先度制御部2202に送る。ここで、MAC control elementとSRBの優先順位を決定するのに必要な情報とは、VoIPのようなpath switching遅延によりパケットロスが多くなるようなサービスを受けているか、Handoverが基地局内のHandoverか、基地局間のHandoverかなどの情報である。
【０１０９】
優先度制御部2202は、優先度制御部703と異なり、受信部2201より受け取った情報をもとにSRBとMAC control elementの優先順位を自ら決定する。優先順位の決定は、送信Message生成部2203が送信メッセージを作成する際に行われる。
【０１１０】
送信Message生成部2203は、優先度制御部2202に、送信する予定のメッセージの内容を通知する。また、送信Message生成部2203は、送信メッセージを作成する都度、優先度制御部2202に優先順位の確認を行う。
【０１１１】
（フローチャート）
図23に、Handover completeを送信する際に、VoIPを使っているか否かと、基地局間Handoverか否かをもとにSRBとMAC Control elementの優先度を決める動作を示す。
【０１１２】
ST2301で、端末の送信Message生成部2203から基地局へのHandover completeの送信が開始される。そして、送信Message生成部2203は、優先度制御部2202に優先度の確認を行う。
【０１１３】
優先度制御部2202は、ST2302にてVoIPを使っているか否かを判断する。使っていない場合にはST2304に進み、使っている場合にはST2303に進む。ST2303では、優先度制御部2202は、今回のHandoverが基地局間Handoverか、基地局内Handoverかを判断する。ST2303にて、基地局内Handoverの場合にはST2304に進み、基地局間Handoverの場合には、ST2305に進む。
【０１１４】
ST2304では、優先度制御部2202は、Handover Complete遅延によっておこるpath switching遅延が問題ないものとして、MAC Control elementを優先すると決定する。逆に、ST2305では、Handover completeの遅延が問題となるため、Handover completeを優先すると決定する。これらの結果は送信Message生成部2203に通知され、送信Message生成部2203は、その結果を元に送信メッセージを生成する。
【０１１５】
なお、本実施の形態では、VoIPを行っているか否か、基地局間Handoverか否かをもとに端末がSRBのMAC control elementに対するpriorityを判断することを示したが、それ以外の条件を用いても良い。具体的には、端末の移動速度が速ければCQIを優先し、遅ければ優先しないなどの処理も考えられる。また、端末内のバッファー状態の変動が激しい場合にはBSRを優先し、変動が激しくない場合にはBSRを優先しないということも考えられる。
【０１１６】
本実施の形態では、VoIPを行っているか否かを判断の一つの基準としたが、単純に基地局間で転送されないサービスがあるか否かで判断しても良い。RLCのUMを使うDRBは転送されないことになっている。そのため、RLCのUMを使うDRBがあるか否かを判断基準とすることが出来る。
【０１１７】
また、さらには、そのRLC UMを使用しているDRBがある優先度以上であるかを判断基準に使用することが出来る。これにより、優先度の低いRLC UMのDRBにひきずられてSRBの優先度が決まってしまうようなことを回避できる。
【０１１８】
＜実施の形態6＞
本実施の形態のMACサブヘッダーの構成を図27に、端末の動作の概要を示すフローチャートを図28に示す。本実施の形態では、端末が自分で基地局に送信するRACH preambleを選択する場合（non-dedicated RACH preambleの場合）にどのように基地局がその内容を区別するかを示す。
【０１１９】
端末が自分で基地局に送信するRACH preambleを選択する場合、基地局は、その端末がinitial accessを行いたいのか、Handover completeの送信を行いたいのか、その他なのかがRACH preamble（図1(a)に示すMessage1）を受信しただけではわからない。そのため、基地局は図1(a)に示すMessage3の内容が何であるのかを、Message3を受信した時点で知ることになる。この際に一つ課題がある。それは、Message3にMACのヘッダーが使用されるかどうかが条件によって異なることに起因する。具体的には、端末に対して72bitsの情報を送るためだけのリソースが割当てられた場合には、呼接続、再接続の場合にはMACのヘッダーが含まれず、直接RRC messageが含まれることになり、それ以外のHandover complete送信、UL/DL データ送受信再開では、MACのヘッダーが含まれる。また、72bitsより多い、例えば144bitsの 情報を送るリソースが割当てられた場合には、呼接続、再接続の場合でもMACヘッダーが含まれることとなる。そのため、基地局は72bits のみを端末に割当てた場合に、MACヘッダーが含まれているか否かを判断する必要がある。
【０１２０】
これを解決するために非特許文献(R2-080162: Message 3 encoding)では、二つの提案を行っている。
【０１２１】
（従来の提案１）
一つ目の提案は、非特許文献(TS36.321 V8.0.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification”)に記載されている現状のMACサブヘッダー(MAC sub-header)の構成（図25(a)参照）を使用したものであり、先頭にあるLCID（Logical Channel IDentifier） 領域(LCID field)を使用するものである。LCID領域は、運ぶデータに該当するLCID、またはMAC control elementに該当するLCIDを入れる場所であり、これにより受信側は受け取ったデータが何かを識別できる。
【０１２２】
当該文献に記載されている具体的な方法は、５bitsあるLCIDの先頭の２bitsを用いてMACヘッダーがあるか、否かを示すものであり、例えば先頭の２bitsの値が”11”となっている場合には、MACヘッダーがあるものとして扱い、それ以外の”00”、”01”、”10”の場合にはMACヘッダーが無しと扱う動作とするものである。呼接続、再接続の場合のRRC message、すなわちRRC CONNECTION REQUEST、RRC CONNECTION RE-ESTABLISHMENT REQUESTの場合には、先頭の２bitsがRRC messageを示すMessage typeに使用されると考えられている。そのため、”00”、”01”、”10”の場合には、RRCにて受信したメッセージがRRC CONNECTION REQUEST、RRC CONNECTION RE-ESTABLISHMENT REQUESTなのかを識別することになる。たとえば、”00”がRRC CONNECTION REQUESTであり、”01”がRRC CONNECTION RE-ESTABLISHMENT REQUESTなどである。
【０１２３】
この場合の欠点は、LCIDで示すことの出来る領域に制限が出てくることである。端末が自分で基地局に送信するRACH preambleを選択する場合には、基地局に対してC-RNTIを通知する必要があり、その情報が含まれなくてはいけない。そのため、C-RNTIを含むMAC control elementのために、３２個中８個のLCIDを予約する必要が出てくる。しかし実際にはC-RNTIを含むMAC control elementは８個も定義されないと考えられるため、無駄にLCIDを予約することになってしまう。
【０１２４】
ここで、MACサブヘッダー内の他の領域に関しても説明を行う。拡張領域(E (Extension) field)は、さらにMACサブヘッダーが続くか否かをしめしており、”0”だと次にデータまたはMAC control elementがはいり、”1”だとMACサブヘッダーが続く形であることを示す。複数のMACサブヘッダーが続く場合の構成例を図26に示す。ここで、図26(a)は、図25に示した長さ領域(L (Length) field)無しのMACサブヘッダーのみでMACヘッダーを構成する例である。長さ領域とは、送るデータのサイズを示すものであり、これによって受信側は、次のデータまたはMAC control elementが何処から始まるかを知ることが出来る。なお、MAC control elementは長さが固定で決まっているため長さ領域が必要なく、また最後のデータも次のデータなどが無いため入れる必要が無くなる。また、長さ領域には二種類あり、7bitsのもの（図26(b)）と15bitsのもの（図26(c)）がある。ここで、どちらが使われているかがフォーマット領域(F (Format) field)で示される。また、予約ビット(R (Reserved) bit)は、後の拡張のために予備として定義されている。
【０１２５】
（従来の提案２）
二つ目の提案は、他のMACヘッダーの構成(図25(b)参照)を用いるものである。この動作では、最初の予約ビットの１bitがMACヘッダーがあるか否かを示すものとして使用される。すなわち、値が”0”だとMACヘッダーありとし、”1”だとMACヘッダー無しとして処理が行われる。RRCでは、常に先頭のbitが”1”となっているため、Message typeの識別には”10”と”11”のみが使用でき、”10”がRRC CONNECTION REQUEST、”11”がRRC CONNECTION RE-ESTABLISHMENT REQUESTのような形になる。
【０１２６】
この場合の課題は、Message typeを全て使っているため、新たにRRC messageを定義できないことである。そのため、LCIDとして定義できる範囲を無駄に使用せず、なおかつ新たにRRC messageを定義できるようにMessage typeに使用できる領域を確保しておくことが望ましい。
【０１２７】
（本実施の形態）
図27に示すように、本実施の形態でのMACヘッダーの構成の特徴は、拡張領域が先頭に存在し、その値によってMAC ヘッダーがあるか否かを判断可能としていることである。これは、72bitsしか送信用に割当てられないような場合には、複数のMACサブヘッダーを使用するという必要性が少ないという特徴をいかし、MAC ヘッダーがある場合には拡張領域を常に”0”にして一つのMACサブヘッダーのみを使用するような動作とすることにより実現される。よって、受信側は、拡張領域が”0”となっていた場合にはMACヘッダーがあるものとして処理し、”1”となっていた場合には、MACヘッダーがないものとしてRRC messageとしてRRCで処理する。RRCでは、最初の２bitsを用いてメッセージの識別を行う。具体的な例としては、”10”がRRC CONNECTION REQUEST、”11”がRRC CONNECTION RE-ESTABLISHMENT REQUESTのような形である。
【０１２８】
本方式ではMACヘッダーの２bit目にあたるがMACとしては使用されておらず予約ビットのままである。そのため、今後MACで拡張を行う際にその予約ビットを使うことが可能である。また逆に、RRC messageを追加する必要がある場合にもそのビットを使うことが可能である。具体的には、MAC ヘッダーがあるか否かを拡張領域のみで見るのではなくて、MACヘッダーの最初の２bitsに当たる拡張領域と予約ビットをみて”00”となっていた場合に、MACヘッダー無しと判断する。これにより、RRC messageを示すのに、”01”、”10” ”11”の三つを使うことが出来る。このように本方式では、拡張領域をMACヘッダーの有無の識別に利用することにより、MACの拡張、もしくはRRC messageの追加に対応している。
【０１２９】
以下図28を用いて本実施形態にかかる端末の動作を説明する。
ST2801において、端末はRandom Access Responseで割当てられたサイズを確認する。ここで、72bitsよりも多く割当てられた場合にはST2803に進む。72bitsが割当てられた場合にはST2804に進む。ST2804では、端末は、呼接続または再接続を行うのか、それ以外かを判断する。すなわち端末は、MACヘッダーを使わないか、使うかを判断する。ここで、MACヘッダーを使う場合には、ST2805に進み、使わない場合にはST2806に進む。ST2805に進んだ場合において、端末がRACHプリアンブルを自分で選択する場合（すなわちNon-dedicated RACH preamble）の場合には、ST2806に進み、基地局から与えられたRACH preambleを用いる場合にはST2803に進む。
【０１３０】
ST2803では、端末は通常どおりMACヘッダーを使用し送信データの作成を行う。一方、ST2806では、端末はMACヘッダーの最初の拡張領域が”0”となるように送信データの作成を行う。このときのMACヘッダー構成例を図29(c)、(d)、(e)、(f)に示す。また、LCIDの定義の例を図30に示す。
【０１３１】
図29(c)は、C-RNTIのみを送信している場合である。ここで、40bitsのうちの16bitsがC-RNTIとして使われ、残りの24bitsがpaddingとなっている。そのため、C-RNTIとpaddingが入っているといいうことを示すLCID(図30の11000)がここでは入れられる。
図29(d)は、C-RNTIとBSRを送信しており、C-RNTIとBSRが入っているといいうことを示すLCID(図30の11001)がここでは入れられる。これは、BSRがハンドオーバーコンプリートよりも優先されるような場合に使われる。
図29(e)は、C-RNTIとDCCH (Dedicated Control Channel)を送信している。ここで、DCCHは、前述のSRBのLogical channelとしての名称であり、high priority SRBとlow priority SRBと分かれているのと同様にDCCHとしても複数に分かれている。LCIDの定義としては、C-RNTIとhigh priority SRBとが後に送信されると示すもののみを定義することも出来るし、逆にC-RNTIとlow priority SRBとが後に送信されると示すもののみを定義することも出来るし、両方を定義しても良い。図30では両方が定義される例をしめした。そして、実際に送信するDCCHに応じてLCIDを設定する(図30の11010または11011)。
図29(f)は、C-RNTIとCQIを送信している。そのため、C-RNTIとCQIが入っているということを示すLCID(図30の11100)がここでは入れられる。
【０１３２】
ST2807では、端末は、MACヘッダー無しでメッセージを送信する。その際の送信データの例が図29(a)、(b)にそれぞれ呼接続時、再接続時として示してある。なお、Message type以外の情報の場所に関しては異なる配置でも良い。
【０１３３】
本実施の形態の動作により、LCIDとして定義できる範囲を無駄に使用せず、なおかつ新たにRRC messageを定義できるようにMessage typeに使用できる領域を確保しておくこと
が可能になる。
【０１３４】
なお、以上の説明ではC-RNTIと他の情報を組み合わせるようにLCIDを定義した例を示したが、それ以外の方法も考えられる。端末がRACHプリアンブルを自分で選択した場合、基地局は、その端末がMessage3でC-RNTIを入れることが予測できる。そのため、端末がRACHプリアンブルを自分で選択した場合には、常にMACヘッダーの後にC-RNTIを入れるような動作に決めておけば、C-RNTIと他の情報を組み合わせるようにLCIDを定義する必要が無くなる。具体的には、図31にその例を示す。図31(a)は、C-RNTIのみが入っていて、残りがpaddingになっている場合である。この場合には、LCIDとしてpaddingを示すLCIDを端末は入れる。基地局は、端末がRACHプリアンブルを自分で選択した場合には、常にMACヘッダーの後にC-RNTIを入れることがわかっているため、C-RNTIがMACヘッダーの後に来て、その後がpaddingであると理解することが可能となる。その他のケースを図31(b)、(c)、(d)に示すが、動作としては同様であり、基地局は、C-RNTIがあり、その後LCIDで示す情報が入ると理解することが可能となる。
なお、上記ではC-RNTIをMACヘッダーの直後に入れる例を示したが、その他の場所に設定することも可能である。
【０１３５】
以上説明した通信端末は、所定の手順にしたがって基地局と通信する通信端末であって、MAC制御情報に割り当てられている優先度であるMAC制御情報の優先度と、DRBおよびSRBに割り当てられている優先度との関係を確定する優先度制御部と、前記優先度制御部で確定した優先度の関係に従い、優先度の高い情報を先に送信するように制御する送信メッセージ生成部とを備える。
【０１３６】
上記構成によれば、MAC制御情報の優先度と、DRBおよびSRBに割り当てられている優先度との関係に応じて、どのような情報を送信するかを自由に制御できるようになる。したがって、通信サービスの内容や状況に応じた適切な制御が可能となる。例えば、VoIPを行っている場合にパス・スイッチングを早くする必要がある場合には、BSRよりもSRBの優先度を高くすることが考えられる。また逆に、パス・スイッチングを早く行う必要がなく、端末の持っているバッファー状態を早く把握したい場合には、BSRをSRBよりも優先度を上げることが出来る。
【０１３７】
また、当該通信端末には、前記基地局から送信される前記MAC制御情報の優先度を受信する受信部を設けることができる。
【０１３８】
また、当該通信端末は、前記MAC制御情報が、C-RNTI、BSR、およびCQIを含み、前記送信メッセージ生成部が、前記DRB、SRB、C-RNTI、BSR、およびCQIの優先度に従い、優先度の高い情報を先に送信するものである。
【０１３９】
上記構成によれば、例えば、C-RNTIを優先度1、BSRおよびCQIを優先度3に設定すれば、SRBの優先度が2の場合に、C-RNTIのみをSRBよりも優先させることができ、どのような情報を送信するかを自由に制御できるようになる。
【０１４０】
また、当該通信端末は、前記MAC制御情報の優先度の情報を保持する優先度テーブル部を備え、前記受信部が、前記MAC制御情報の優先度の境界を示す境目情報を受信し、前記優先度制御部が、前記境目情報を参照して、前記MAC制御情報の優先度と前記DRBおよびSRBに割り当てられている優先度との関係を確定するものである。
【０１４１】
上記構成によれば、少ないビット数でMAC制御情報の優先度の境目情報を設定することができるので、シグナリングのオーバーヘッドの増加を抑えることができる。
【０１４２】
また、当該通信端末は、前記優先度制御部が、RACHプロシージャの使用理由に応じて、前記MAC制御情報の優先度を指定するものである。
【０１４３】
上記構成によれば、MAC制御情報の優先度をRACHプロシージャの使用理由に応じて指定することにより、RACHプロシージャ毎に送信動作を変えることが可能となる。
【０１４４】
また、当該通信端末は、前記受信部が、前記基地局からメッセージのサイズに関する閾値を受信し、前記優先度制御部が、前記閾値を参照して、前記MAC制御情報の優先度と前記DRBおよびSRBに割り当てられている優先度との関係を確定するものである。
【０１４５】
上記構成によれば、先に送信するように設定されたメッセージが大きい場合には、MAC制御情報を先に送信して、大きなメッセージの送信に伴うオーバーヘッドを減少させることができる。
【０１４６】
また、当該通信端末は、前記受信部が、前記基地局から前記MAC制御情報と前記SRBの優先順位を決定するのに必要な情報を受信し、前記優先度制御部が、前記情報を参照して、前記SRBと前記MAC制御情報の優先順位を決定するものである。
【０１４７】
上記構成によれば、ネットワークからの指示なしに優先順位を決定することができる。
【０１４８】
また、当該通信端末は、前記MAC制御情報と前記SRBの優先順位を決定するのに必要な情報は、パス・スイッチング遅延によりパケットロスが多くなるサービスを受けているかどうかを示す情報、ハンドオーバーが前記基地局内のハンドオーバーかどうかを示す情報、およびハンドオーバーが前記基地局間のハンドオーバーかどうかを示す情報を含むものである。
【０１４９】
上記構成によれば、VoIPを使っているか否か、および基地局内または基地局間ハンドオーバーか否かをもとに、ネットワークからの指示なしにSRBとMAC制御情報の優先順位を決定することができる。
【０１５０】
また、当該通信端末は、MACサブヘッダー内の先頭に、MACサブヘッダーが次に続くか否かを示す拡張領域を配置し、MACサブヘッダーの72bitsのみのリソースが割当てられた場合に、MACヘッダーが存在するか否かを、MACヘッダーの最初に位置する拡張領域の値によって示すものである。
【０１５１】
上記構成によれば、端末は新たなbitを使用せずにMACヘッダーが存在するか否かを基地局に通知することが出来る。
【０１５２】
このように、上記通信端末によれば、MAC制御情報の優先度と、DRBおよびSRBに割り当てられている優先度とを比較することにより、どのような情報を送信するかを自由に制御できるようになる。
【０１５３】
また、上記説明した基地局は、MACサブヘッダー内の先頭に、MACサブヘッダーが次に続くか否かを示す拡張領域を配置し、MACサブヘッダーの72bitsのみのリソースが割当てられた場合に、MACヘッダーが存在するか否かを、MACヘッダーの最初に位置する拡張領域の値によって判断するものである。
【０１５４】
上記構成によれば、基地局は新たなbitを使用せずにMACヘッダーが存在するか否かを判断することが出来る。
【０１５５】
本出願は、２００８年２月１日出願の日本特許出願、特願２００８−０２３１７１に基づくものであり、その内容はここに参照として取り込まれる。
【０１５６】
以上、本発明の各種実施形態を説明したが、本発明は前記実施形態において示された事項に限定されず、明細書の記載、並びに周知の技術に基づいて、当業者がその変更・応用することも本発明の予定するところであり、保護を求める範囲に含まれる。
【産業上の利用可能性】
【０１５７】
本発明は、MAC制御情報に優先度を割り当て、どのような情報を送信させるかを自由に制御することができる通信端末及び送信メッセージ生成制御方法等として利用可能である。
【符号の説明】
【０１５８】
701,2201 受信部
702,1101 優先度table部
703,1001,1301,1701,2202 優先度制御部
704,1002,1302,2203 送信message生成部
705 SRB生成部
706 DRB生成部
707 バッファー部
708 MAC情報生成部
709 送信部
【特許請求の範囲】
【請求項１】
基地局と通信する通信端末であって、
複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、前記基地局へ送信する制御情報の優先度を制御する優先度制御部と、
前記制御に従い前記優先度を考慮して送信メッセージを生成する送信メッセージ生成部と、
を備える通信端末。
【請求項２】
前記制御情報の優先度を制御するための情報を前記基地局から受信する受信部をさらに備える請求項１記載の通信端末。
【請求項３】
前記MAC制御情報の優先度は予め決められており、前記基地局から受信した優先度を制御するための情報を用いて前記SRBを含めた優先度を制御する、請求項２記載の通信端末。
【請求項４】
基地局と通信する通信端末により実行される方法であって、
複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、前記基地局へ送信する制御情報の優先度を制御するステップと、
前記制御に従い前記優先度を考慮して送信メッセージを生成するステップと、
を備える送信メッセージ生成制御方法。
【請求項５】
前記制御情報の優先度を制御するための情報を前記基地局から受信するステップをさらに備える請求項４記載の送信メッセージ生成制御方法。
【請求項６】
前記MAC制御情報の優先度は予め決められており、前記基地局から受信した優先度を制御するための情報を用いて前記SRBを含めた優先度を制御する、請求項５記載の送信メッセージ生成制御方法。
【請求項１】
基地局と通信する通信端末であって、
複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、前記基地局へ送信する制御情報の優先度を制御する優先度制御部と、
前記制御に従い前記優先度を考慮して送信メッセージを生成する送信メッセージ生成部と、
を備える通信端末。
【請求項２】
前記制御情報の優先度を制御するための情報を前記基地局から受信する受信部をさらに備える請求項１記載の通信端末。
【請求項３】
前記MAC制御情報の優先度は予め決められており、前記基地局から受信した優先度を制御するための情報を用いて前記SRBを含めた優先度を制御する、請求項２記載の通信端末。
【請求項４】
基地局と通信する通信端末により実行される方法であって、
複数のMAC制御情報に個別に割り当てられている優先度であるMAC制御情報の優先度と、RRC制御情報を送信するための複数のSRBに個別に割り当てられている優先度に基づき、前記基地局へ送信する制御情報の優先度を制御するステップと、
前記制御に従い前記優先度を考慮して送信メッセージを生成するステップと、
を備える送信メッセージ生成制御方法。
【請求項５】
前記制御情報の優先度を制御するための情報を前記基地局から受信するステップをさらに備える請求項４記載の送信メッセージ生成制御方法。
【請求項６】
前記MAC制御情報の優先度は予め決められており、前記基地局から受信した優先度を制御するための情報を用いて前記SRBを含めた優先度を制御する、請求項５記載の送信メッセージ生成制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２０１２−１３００５２（Ｐ２０１２−１３００５２Ａ）
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願番号】特願２０１２−２７５７１（Ｐ２０１２−２７５７１）
【出願日】平成２４年２月１０日（２０１２．２．１０）
【分割の表示】特願２０１１−２８７４２（Ｐ２０１１−２８７４２）の分割
【原出願日】平成２１年１月３０日（２００９．１．３０）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成２４年７月５日（２０１２．７．５）
【国際特許分類】
【出願日】平成２４年２月１０日（２０１２．２．１０）
【分割の表示】特願２０１１−２８７４２（Ｐ２０１１−２８７４２）の分割
【原出願日】平成２１年１月３０日（２００９．１．３０）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]