所定の手順にしたがって通信端末と通信する基地局であって、MAC制御情報に優先度を割り当て、前記MAC制御情報の優先度を前記通信端末に送信する基地局。請求項1記載の基地局であって、前記MAC制御情報の優先度を予め決めておき、SRBに対して高い優先度を持つMAC制御情報と低い優先度を持つMAC制御情報の境目の情報のみを前記通信端末に送信する基地局。請求項1記載の基地局であって、RACHプロシージャの使用理由に応じた前記MAC制御情報の優先度を前記通信端末に送信する基地局。請求項1記載の基地局であって、送信すべきメッセージのサイズが所定のサイズよりも大きい場合には、前記MAC制御情報を優先させる基地局。上記説明から、Handovercompleteの送信を考えると、端末が72bitsのみ送信用に割当てられた場合には、表1のように二度に分けて送信することが必要となることがわかる。また、Handoverを行った後にはBSRを送信することが決まっている。UMTSUniversalMobileTelecommunicationSystemにおいて、MACcontrol情報は、常にSRB、DRBよりも優先度が高いとされている非特許文献1参照。そのため、このBSRをHandovercompleteよりも先に送ることが想定される。この場合、表2のように三度にわけて送信することになり、さらにはHandovercompleteの送信が遅れてしまうこととなってしまう。上述したとおり、MACcontrolelementが優先される場合には、Handovercompleteの送信が遅れることが考えられる。これは、下記のようなデメリットをもつ。ネットワークでのパス切り替えpathswitching遅延基地局は、Handovercompleteを受信することで、端末が移動してきたと確実に判断できる。そのため、ネットワーク内での切り替えは、Handovercompleteを受信したタイミングで行われる。pathswitchingが遅れると、元の基地局から新しい基地局に転送されないデータなどは廃棄されてしまう。図15にネットワーク側の基地局とコアネットワークCorenetworkのエンティティentityとの関係を示す。Handovercompleteを新しい基地局が受信して、Corenetworkのentityにパスの切り替えを行うまでは、Corenetworkのentityは前の基地局に対してデータを送信し続ける。これは、前の基地局が新しい基地局にデータを転送するような場合には問題ないが、例えば、VoIPなどのリアルタイムサービスではパケットの転送がされないと考えられている。これを最低限に抑えるために、pathswitching遅延を短くすることが求められている。下りの送信開始遅延基地局は、Handovercompleteを受信することで、端末が移動してきたと確実に判断でき、下りのデータ送信を開始できる。そのため、Handovercompleteの受信が遅れると、元の基地局から新しい基地局に転送されているデータがある場合に、下りのデータ送信開始が遅れることとなってしまう。上記のようなことを考えると、常にMACcontrolelementを優先することは望ましくない。そのため、MACcontrolelementの優先度priorityを制御する必要がある。本発明は、上記従来の事情に鑑みてなされたものであって、MAC制御情報に優先度を割り当て、どのような情報を送信させるかを自由に制御することができる基地局を提供することを目的としている。本発明の基地局は、所定の手順にしたがって通信端末と通信する基地局であって、MAC制御情報に優先度を割り当て、前記MAC制御情報の優先度を前記通信端末に送信するものである。上記構成によれば、MAC制御情報に優先度を割り当てるので、通信端末がどのような情報を送信するかを自由に制御できるようになる。また、本発明の基地局は、前記MAC制御情報の優先度を予め決めておき、SRBに対して高い優先度を持つMAC制御情報と低い優先度を持つMAC制御情報の境目の情報のみを送信するものである。上記構成によれば、少ないビット数でMAC制御情報の境目を設定することができ、シグナリングのオーバーヘッドの増加を抑えることができる。また、本発明の基地局は、RACHプロシージャの使用理由に応じた前記MAC制御情報の優先度を前記通信端末に送信するものである。上記構成によれば、MAC制御情報の優先度をRACHプロシージャの使用理由に応じて指定することにより、RACHプロシージャ毎に端末の動作を変えることが可能となる。また、本発明の基地局は、送信すべきメッセージのサイズが所定のサイズよりも大きい場合には、前記MAC制御情報を優先させるものである。上記構成によれば、先に送信するように設定されたメッセージが大きい場合に、MAC制御情報を先に送信して、大きなメッセージの送信に伴うオーバーヘッドを減少させることができる。本発明の基地局によれば、MAC制御情報に優先度を割り当て、MAC制御情報の優先度を通信端末に送信するので、通信端末がどのような情報を送信するかを自由に制御できるようになる。以下、基地局と端末とが、RACHprocedureの実施に先立ち、送信するデータの優先度を確定する例を説明する。なお、下記各実施の形態は、図1に示したnondedicatedRACHpreambleの場合及びdedicatedRACHpreambleの場合のいずれにも同様に適用できる。<実施の形態1>SRBsignalingradiobearer:制御メッセージであるRRCmessageを運ぶためのbearer、DRBuserplaneradiobearerdataradiobearer:データを運ぶためのbearerは、それぞれ優先度priorityを持っている。現状SRBとしては優先度の高いRRCmessageを送るためのhighprioritySRBSRB2と通常のSRBとしてのpriorityを持つlowprioritySRBSRB1がRRCCONNECTEDの端末が通信するために存在する。また、initialaccess、RadiolinkfailurerecoveryなどでRRCCONNECTEDに端末が移るまでのRRCmessageを運ぶために別のSRBが定義されている。DRBとしては、端末が使用するサービスに応じて追加され、例えばVoIPのためのDRB、webbrowsingのためのDRB、emailのやり取りのためのDRBなどが設定される。ここで、端末がどのbearerを送信すればよいかを基地局側で制御できるように、priorityがbearerごとに設定されている。基本的にSRBはDRBより高い優先度を持つ。また、DRBの中では遅延に対する要求が厳しいtimecriticalサービスのためのbearerほど高い優先度を持つ。そのため、上記の例では下記のような優先度が考えられる。HighprioritySRBlowprioritySRBDRBforVoIPDRBforwebbrowsingDRBforemail本実施の形態では、SRB、DRBと同じようにMACcontrolelement毎にpriorityを設定する。その概要を図16に示す。この図に示されるように、例えば、priorityの値が18まであり、1が一番高い場合に、MACcontrolelementの中で一番優先度の高いと考えられるCRNTIを優先度1、次に優先度の高いと考えられるBSR、CQIなどを優先度3と設定することが考えられる。ここで、highprioritySRBの優先度が2となった場合には、CRNTIのみがhighprioritySRBよりも優先される。このような動作により、端末にどのような情報を送信させるかを自由に制御できるようになる。具体的には、端末がVoIPを使用していてpathswitchingを早くする必要がある場合には、BSRよりもhighprioritySRBの優先度を高くすることが考えられる。また逆に、pathswitchingを早く行う必要がなく、端末の持っているbuffer状態を早く把握したい場合には、BSRをhighprioritySRBよりも優先度を上げることが出来る。ブロック図図17を用いて本発明の端末のブロック図を示す。図17に示す通信端末は、受信部701と、SRB生成部705と、DRB生成部706と、優先度制御部1701と、送信message生成部704と、バッファー部707と、MAC情報生成部708と、送信部709とを備える。各部の主要動作、役割は下記のとおりである。701は、受信部であり基地局からのメッセージを受信する。受信部701は、MACcontrolelement毎の優先度を受信し、優先度制御部1701に送る。また、受信部701は、端末が送信するメッセージサイズを受け取り、送信message生成部704に送る。705は、SRB生成部であり、RRCmessage、NASmessage等のSRBを用いて送信するメッセージの作成を行う。706は、DRB生成部であり、userplaneデータの作成を行う。1701は、優先度制御部であり、受信部701からMACcontrolelement毎の優先度を受信する。優先度制御部1701は、MACcontrolelement毎の優先度と通常DRB、SRBに割当てられている優先度とにより、CRNTISRBBSRCQIDRB、またはCRNTIhighprioritySRBBSRlowprioritySRBCQIDRBのような、MACcontrolelementとSRBの優先度の関係を確定する。そして優先度制御部1701は、その結果を用いて、送信message生成部704に、priorityの高い情報を先に送信するような送信メッセージを作成させるよう制御する。704は、送信message生成部であり、優先度制御部1701からの優先度情報と、受信部701からの送信メッセージサイズをもとに送信メッセージを作成する。送信message生成704は、後述するMAC情報生成部708よりMACcontrolelementを受け取り、送信可能なbearerとその量をバッファー部707に通知し、バッファー部707よりSRBまたはDRBの送信すべき情報を受け取ることも行う。707は、バッファー部であり、SRB生成部705とDRB生成部706からの情報を保持し、送信message生成部704の指示に応じて送信message生成部704に送信する。708は、MAC情報生成部であり、MACcontrolelementを生成し、送信message生成部704に通知する。具体的には、MAC情報生成部708は、CRNTIを送信する必要があるときには、送信message生成部704にCRNTIを渡す。また、MAC情報生成部708は、BSRを送信する必要があるときにはバッファー部707の情報からBSRを生成、送信するなどである。709は、送信部であり、送信message生成部704で作成したメッセージを基地局に送信する役割を持っている。以上説明したように、本実施の形態によれば、MACcontrolelement毎に自由にpriorityを設定できるため、RACHprocedureのMessage3で優先して基地局へ送信すべきデータを、通信サービスの内容や状況に応じて適切に制御できる。<実施の形態2>本実施の形態の概念を示す図を図6に、また、端末のブロック図を図7、本動作のprocedureの具体例を図8に示す。実施の形態1では、MACcontrolelement毎に自由にpriorityを設定できるようにした。しかしながら、実施の形態1の方式では基地局が端末に対してpriorityの設定を行うシグナリングsignalingのオーバーヘッドoverheadが増加してしまうという課題が存在する。本実施の形態では、MACcontrolelement内での優先度を予め決めておき、SRBに対して高い優先度を持つMACcontrolelementと低い優先度のMACcontrolelementの境目boundaryのみを設定することにより、上記課題を解決する。その概要を図6に示す。図6のように、MACcontrolelementはMACcontrolelement内での優先度を決定する。これは、標準化などの仕様specなどで規定することが考えられ、報知情報等で送信するのでもよいし、個別のRRCmessageで送っても良い。本実施の形態では、標準化などの仕様specなどで規定する例に関して説明する。そして、設定するのは、SRBよりも高い優先度となるMACcontrolelementと低い優先度となるMACcontrolelementの境目である。具体的には、図6の例でのboundary14のどれかを指示することとなる。このときのsignaling例が図6である。なお、図6に示される手順は、図1に示すMessage1以前に実施される。具体的には、boundary2が指定された場合には、下記のようなpriorityの順になる。CRNTISRBBSRCQIDRBまた、上記ではSRBとしてひとくくりとしたが、MACcontrolelementの優先度をhighprioritySRBと比較して設定することも考えられる。そのような場合には下記のようになる。CRNTIhighprioritySRBBSRlowprioritySRBCQIDRBブロック図図7に、本実施の形態の端末のブロック図を示す。図7に示す端末は、図17に示した端末の優先度制御部1701に代えて優先度制御部703と優先度table部702を備える。各部の主要動作、役割について、実施の形態1と異なる点を説明する。本実施の形態において、受信部701は、実施の形態1で説明した役割に加え、基地局から上記で説明したboundary情報を受信し、優先度制御部703に通知する役割を有する。優先度table部702は、図6に示すMACcontrolelement内の優先度の情報を保持しており、それを優先度制御部703に通知する役割を持っている。優先度制御部703は、受信部701からのboundary情報と優先度table部702からの優先度table部情報とにより、CRNTISRBBSRCQIDRB、またはCRNTIhighprioritySRBBSRlowprioritySRBCQIDRBのような、MACcontrolelementとSRBの優先度の関係を確定する。そして優先度制御部703は、その結果を用いて、送信message生成部704に、priorityの高い情報を先に送信させるように制御する。詳細説明本発明の動作を図7、図8を用いて説明する。なお図8はhandover送信のprocedureの具体例である図8に示されているように、まず、基地局Sourcecellから端末UEにboundary情報が通知されるST81RRCCONNECTIONRECONFIGURATIONmessage。このboundary情報は、受信部701で受信され、優先度制御部703に渡される。優先度制御部703は、ST81で受信されたboundary情報と、優先度table部702に保持されている図6に記載のMACcontrolelement内の優先度を示すtableという二つの情報から、MACcontrolelementの優先度の情報を得る。優先度制御部703は、これを送信Message生成部704に伝える。次に、送信message生成部704で作成されたST81に対する応答メッセージが、端末の送信部709から基地局に送信されるST82RRCCONNECTIONRECONFIGURATIONCOMPLETEmessage。そして、基地局は、端末にHandoverの実施を通知するST83HandoverCommandmessage。それに応じて端末はhandoverを実施する。なお、この処理は一般的な動作であり、本発明とは直接関係しないため、説明を省略する。なお、HandoverCommand、HandoverCompletemessageは、それぞれ基地局が端末にHandoverを指示するメッセージ、端末が基地局にHandoverの完了を示すメッセージの総称であり、EUTRAEUTRANでは、RRCCONNECTIONRECONFIGURATIONmessage、RRCCONNECTIONRECONFIGURATIONCOMPLETEmessageがそれぞれ使われる。ST83の後に実施される、ST84RandomAccesspreamble、ST85RandomAccessresponseは、通常のRACHprocedureでありここでは詳細な説明を省略する。ST85の後、送信message生成部704は、ST85で受け取ったリソース割当情報を元に、Message3でのmessagesizeを決定する。このmessagesizeは、受信部701から送信message生成部704に送られる。ここで、HandovercompleteとBSRとを両方送りたい場合で、1つのメッセージに両方が入りきらない場合にはpriorityによってどちらを優先するかを決定することとなる。すなわち、BSRSRBとなっていればBSRを優先するし、BSRhighprioritySRBBSRCQIlowprioritySRBDRBのような優先度に設定することも考えられる。本実施の形態では、SRBのみに対してMACcontrolelementの優先度を設定できるようにした。しかしながら、一番優先度の高いDRBに対して設定することも可能である。すなわち、CRNTISRBBSRhighpriorityDRBCQIotherDRBのような処理を、boundary情報を複数持つことで実現が可能である。本実施の形態ではHandovercompleteの送信の例を示したが、その他の場合にも適用可能である。具体的な例としては、ULdataresumingがあげられる。ULdataresumingは、端末がDRX中に送信するデータが発生した場合の動作である。具体的には、端末の受信状態を示す測定結果を送信することや、新たなサービスの追加を求めるサービス要求を送ることが考えられる。測定結果を示すMeasurementreportはHandoverの実施に必要なため、優先度が高いメッセージである。そのため、端末の移動速度が速い場合にはこのメッセージを早く送信しなければいけないという課題がある。前述の通り、基地局が端末の移動速度を考慮することにより、この際に、発生したデータを送るのか、それともBSRを優先するのか、CQIを優先するのかを本実施の形態に示した処理で決定できる。その際の動作を図19に示す。MACcontrolelementの優先度をLCIDの順番の通りにすることも可能である。前述の通り、MACcontrolelementは、それぞれLCIDで示される。例えば、BSRは11100、CQIは11101などである。ここで、そのLCIDの順番がpriorityの順番となるように定義することで、端末に優先度のtableを特別に用意することが必要なくなるなどのメリットがある。本実施の形態では、図8に示したように、HandoverCommandとBoundary情報の通知を別のメッセージとしたが、HandoverCommandにてBoundary情報を通知、変更することも可能である。本実施の形態では、端末がVoIPを行っていてHandovercompleteを優先すべき時などにRRCmessageのpriorityをあげるように設定する動作をしめした。しかしながら、同一基地局内のセル間のHandoverの際には状況が異なってくるという課題が存在する。これは、基地局のswitchingがおこらないため、Handovercompleteを早く送信する必要がなくなるためである。これを実現するために、一時的にpriorityを変更するような動作が考えられる。図20にその際の動作を示す。ここで図8との大きな違いは、ST83に相当するST201にて、temporaryなpriorityを割当てている点である。このtemporaryなpriorityは、基地局が送信したST201HandoverCommandに対する応答にのみ適用されるものであり、HandoverCompleteのみに適用される。本発明では、RACHprocedureのMessage3に着眼して説明したが、本実施の形態は、通常の上り送信全てに適用可能である。通常の上り送信全てに使用する際の典型的な例として、端末がinitialaccess、Radiolinkfailurerecoveryを行う場合が考えられる。その流れを図24に示す。端末が呼接続、再接続を行う際には、ネットワーク側は端末の受信状況などを正確に知らない。そのため、CQI等の情報が必要である。しかしながら、その一方で、端末がST2406aで送る信号には、Corenetworkに送る情報が入っており、それを送らなければ最終的に呼接続は終了しない。その一方で、ST2406bは主に確認応答のみに使われる。そのため、ST2404a、ST2404bで与えるboundary情報により、initialaccess時にはSRBを優先するといった動作が可能になる。これにより、呼接続の遅延がMACcontrolelementの送信により増大するといった課題を解決できる。<実施の形態3>本実施の形態の概念を示す図を図9に、また、端末のブロック図を図10に示す。実施の形態2では、RACHprocedureを使用する全ての場合に対して同じpriority設定を使用する場合を示した。しかしながら、RACHprocedureの使用理由によって、必要な情報が若干異なるため、RACHprocedureを行う理由ごとにそのpriorityを決定することが考えられる。本実施の形態によれば、RACHprocedureの使用理由に応じて、より適切な送信データの制御が可能となる。以下に、RACHprocedureを行う理由ごとのpriorityの決定例を示す。Handovercompleteの送信BSRはそれほど変更が無ければ、元の基地局から移動先の基地局に通知されたものが使用できると考えられる。そのため、Handovercompleteを優先することが考えられる。上りの送信開始遅延端末がどれだけ情報を持っているかを知るために、BSRが必要となる。そのため、SRBよりもBSRを優先することが考えられる。下りの送信開始遅延下りの送信を行う為に、CQIが必要だと考えられる。そのため、CQIを優先することが考えられる。図9にこれを実現する為の情報の指示の動作を示している。このようにboundary情報をRACHprocedureの使用理由ごとに決めることで、RACHprocedure毎に動作を変えることが可能となる。ブロック図図10に、本実施の形態の端末のブロック図を示す。図10に示す端末は、図7に示した端末の優先度制御部703、送信message生成部704に代えて、優先度制御部1001、送信message生成部1002を備える。以下、異なる点のみを説明する。優先度制御部1001は、RACHprocedureの理由ごとに異なるpriorityの設定を持つことができ、それを送信message生成部1002に通知する。送信message生成部1002は、RACHprocedureの理由ごとに異なるpriorityの設定を用いて送信メッセージを生成する。なお、本実施の形態では、boundary情報のみをRACHprocedureの理由ごとに設定する例を示したが、MACcontrolelementの優先順位自体をRACHprocedureの使用理由ごとに変えるにすることも可能である。この場合、図11に示すように、図10に示した優先度table部702に代えて優先度table部1101を備え、優先度table部1101に、RACHprocedureの使用理由ごとの優先度を設定しておけばよい。具体的には、下記のような例が考えられる。HandovercompleteCRNTIBSRCQIULdataresumingCRNTIBSRCQIDLdataresumingCRNTICQIBSRまた、本実施の形態で示したRACHprocedureの使用理由causeによって異なるpriorityを用いる動作を、同じbearerであってもdynamicschedulingとsemipersistentschedulingとで異なるpriorityを設定する場合にも適用できる。EUTRAEUTRANでは、毎回データをPDCCHで割当てるdynamicschedulingと、一度PDCCHで割当てたら一定の周期でそのリソースを使い続けるsemipersistentschedulingとがある。このsemipersistentschedulingは、VoIPのように定期的にデータが同じサイズで送られるようなサービスに適している。しかしながら、BSR、CQIなどの情報をVoIPのデータより優先して送信しようとするとsemipersistentschedulingで割当てたリソースでは入りきらず、VoIPのデータを一度に送れないという課題が存在する。そこで、MACcontrolelementに対する優先度をDRBにも適用し、さらにDRBに対するscheduling方法によってpriorityの設定を変えることにより、上記課題の解決が実現できる。具体的には、semipersistentschedulingを用いて送信する場合に使用するboundary情報を端末に送信する方法が考えられる。すなわち、boundary1が示された場合には、端末はsemipersistentschedulingの時のみにVoIPデータをBSR、CQIより優先し、dynamicschedulingの場合にはBSR、CQIを通常どおり優先することとなる。<実施の形態4>本実施の形態の概念を示す図を図12に、また、端末のブロック図を図13に示す。実施の形態2では、SRBをMACcontrolelementよりも優先できるようにする手段を提供した。しかしながら、MACcontrolelementよりも優先されるメッセージのサイズが大きい場合には、先にMACcontrolelementを送ったほうが良いことが考えられる。そのため、本実施の形態では、MACcontrolelementよりも優先されるメッセージが所定のサイズよりも小さい場合のみMACcontrolelementよりも優先する。そのための閾値Thresholdは、図12に示されるようにboundary情報と合わせて送られる。ブロック図図13に、本実施の形態の端末のブロック図を示す。図13に示す端末は、図7に示した端末の優先度制御部703、送信message生成部704に代えて、優先度制御部1301、送信message生成部1302を備える。以下、異なる点のみを説明する。優先度制御部1301は、MACcontrolpriorityより優先するSRBまたはDRBを送信するか否かを判断するために使用する閾値を受信、処理し、それを送信message生成部1302に送る。送信message生成部1302は、優先するSRBまたはDRBのサイズが閾値を下回っているか否かを判断し、閾値を下回っているときのみ、MACcontrolelementよりもSRBまたはDRBを優先して送信するよう送信メッセージを作成する。<実施の形態5>本実施の形態の端末のブロック図を図22に、動作の概要を示すフローチャートを図23に示す。実施の形態2では、MACcontrolelementとSRBの優先順位をネットワークからの指示により決定する方法を示した。本実施の形態では、ネットワークからの指示なしに優先順位を決定する動作を示す。ブロック図図22は、本実施の形態の端末のブロック図を示す。図22に示す端末は、図7に示した端末の受信部701、優先度制御部703、送信message生成部704に代えて、受信部2201、優先度制御部2202、送信message生成部2203を備える。以下、異なる点のみを説明する。受信部2201は、受信部701と異なり、boundary情報を受信し優先度制御部703に通知するのではなく、MACcontrolelementとSRBの優先順位を決定するのに必要な情報を優先度制御部2202に送る。ここで、MACcontrolelementとSRBの優先順位を決定するのに必要な情報とは、VoIPのようなpathswitching遅延によりパケットロスが多くなるようなサービスを受けているか、Handoverが基地局内のHandoverか、基地局間のHandoverかなどの情報である。優先度制御部2202は、優先度制御部703と異なり、受信部2201より受け取った情報をもとにSRBとMACcontrolelementの優先順位を自ら決定する。優先順位の決定は、送信Message生成部2203が送信メッセージを作成する際に行われる。送信Message生成部2203は、優先度制御部2202に、送信する予定のメッセージの内容を通知する。また、送信Message生成部2203は、送信メッセージを作成する都度、優先度制御部2202に優先順位の確認を行う。フローチャート図23に、Handovercompleteを送信する際に、VoIPを使っているか否かと、基地局間Handoverか否かをもとにSRBとMACControlelementの優先度を決める動作を示す。ST2301で、端末の送信Message生成部2203から基地局へのHandovercompleteの送信が開始される。そして、送信Message生成部2203は、優先度制御部2202に優先度の確認を行う。優先度制御部2202は、ST2302にてVoIPを使っているか否かを判断する。使っていない場合にはST2304に進み、使っている場合にはST2303に進む。ST2303では、優先度制御部2202は、今回のHandoverが基地局間Handoverか、基地局内Handoverかを判断する。ST2303にて、基地局内Handoverの場合にはST2304に進み、基地局間Handoverの場合には、ST2305に進む。ST2304では、優先度制御部2202は、HandoverComplete遅延によっておこるpathswitching遅延が問題ないものとして、MACControlelementを優先すると決定する。逆に、ST2305では、Handovercompleteの遅延が問題となるため、Handovercompleteを優先すると決定する。これらの結果は送信Message生成部2203に通知され、送信Message生成部2203は、その結果を元に送信メッセージを生成する。なお、本実施の形態では、VoIPを行っているか否か、基地局間Handoverか否かをもとに端末がSRBのMACcontrolelementに対するpriorityを判断することを示したが、それ以外の条件を用いても良い。具体的には、端末の移動速度が速ければCQIを優先し、遅ければ優先しないなどの処理も考えられる。また、端末内のバッファー状態の変動が激しい場合にはBSRを優先し、変動が激しくない場合にはBSRを優先しないということも考えられる。本実施の形態では、VoIPを行っているか否かを判断の一つの基準としたが、単純に基地局間で転送されないサービスがあるか否かで判断しても良い。RLCのUMを使うDRBは転送されないことになっている。そのため、RLCのUMを使うDRBがあるか否かを判断基準とすることが出来る。また、さらには、そのRLCUMを使用しているDRBがある優先度以上であるかを判断基準に使用することが出来る。これにより、優先度の低いRLCUMのDRBにひきずられてSRBの優先度が決まってしまうようなことを回避できる。<実施の形態6>本実施の形態のMACサブヘッダーの構成を図27に、端末の動作の概要を示すフローチャートを図28に示す。本実施の形態では、端末が自分で基地局に送信するRACHpreambleを選択する場合nondedicatedRACHpreambleの場合にどのように基地局がその内容を区別するかを示す。端末が自分で基地局に送信するRACHpreambleを選択する場合、基地局は、その端末がinitialaccessを行いたいのか、Handovercompleteの送信を行いたいのか、その他なのかがRACHpreamble図1に示すMessage1を受信しただけではわからない。そのため、基地局は図1に示すMessage3の内容が何であるのかを、Message3を受信した時点で知ることになる。この際に一つ課題がある。それは、Message3にMACのヘッダーが使用されるかどうかが条件によって異なることに起因する。具体的には、端末に対して72bitsの情報を送るためだけのリソースが割当てられた場合には、呼接続、再接続の場合にはMACのヘッダーが含まれず、直接RRCmessageが含まれることになり、それ以外のHandovercomplete送信、ULDLデータ送受信再開では、MACのヘッダーが含まれる。また、72bitsより多い、例えば144bitsの情報を送るリソースが割当てられた場合には、呼接続、再接続の場合でもMACヘッダーが含まれることとなる。そのため、基地局は72bitsのみを端末に割当てた場合に、MACヘッダーが含まれているか否かを判断する必要がある。これを解決するために非特許文献では、二つの提案を行っている。従来の提案1一つ目の提案は、非特許文献MediumAccessControlprotocolspecificationに記載されている現状のMACサブヘッダーの構成図25参照を使用したものであり、先頭にあるLCIDLogicalChannelIDentifier領域を使用するものである。LCID領域は、運ぶデータに該当するLCID、またはMACcontrolelementに該当するLCIDを入れる場所であり、これにより受信側は受け取ったデータが何かを識別できる。当該文献に記載されている具体的な方法は、5bitsあるLCIDの先頭の2bitsを用いてMACヘッダーがあるか、否かを示すものであり、例えば先頭の2bitsの値が11となっている場合には、MACヘッダーがあるものとして扱い、それ以外の00、01、10の場合にはMACヘッダーが無しと扱う動作とするものである。呼接続、再接続の場合のRRCmessage、すなわちRRCCONNECTIONREQUEST、RRCCONNECTIONREESTABLISHMENTREQUESTの場合には、先頭の2bitsがRRCmessageを示すMessagetypeに使用されると考えられている。そのため、00、01、10の場合には、RRCにて受信したメッセージがRRCCONNECTIONREQUEST、RRCCONNECTIONREESTABLISHMENTREQUESTなのかを識別することになる。たとえば、00がRRCCONNECTIONREQUESTであり、01がRRCCONNECTIONREESTABLISHMENTREQUESTなどである。この場合の欠点は、LCIDで示すことの出来る領域に制限が出てくることである。端末が自分で基地局に送信するRACHpreambleを選択する場合には、基地局に対してCRNTIを通知する必要があり、その情報が含まれなくてはいけない。そのため、CRNTIを含むMACcontrolelementのために、32個中8個のLCIDを予約する必要が出てくる。しかし実際にはCRNTIを含むMACcontrolelementは8個も定義されないと考えられるため、無駄にLCIDを予約することになってしまう。ここで、MACサブヘッダー内の他の領域に関しても説明を行う。拡張領域fieldは、さらにMACサブヘッダーが続くか否かをしめしており、0だと次にデータまたはMACcontrolelementがはいり、1だとMACサブヘッダーが続く形であることを示す。複数のMACサブヘッダーが続く場合の構成例を図26に示す。ここで、図26は、図25に示した長さ領域field無しのMACサブヘッダーのみでMACヘッダーを構成する例である。長さ領域とは、送るデータのサイズを示すものであり、これによって受信側は、次のデータまたはMACcontrolelementが何処から始まるかを知ることが出来る。なお、MACcontrolelementは長さが固定で決まっているため長さ領域が必要なく、また最後のデータも次のデータなどが無いため入れる必要が無くなる。また、長さ領域には二種類あり、7bitsのもの図26と15bitsのもの図26がある。ここで、どちらが使われているかがフォーマット領域fieldで示される。また、予約ビットbitは、後の拡張のために予備として定義されている。従来の提案2二つ目の提案は、他のMACヘッダーの構成参照を用いるものである。この動作では、最初の予約ビットの1bitがMACヘッダーがあるか否かを示すものとして使用される。すなわち、値が0だとMACヘッダーありとし、1だとMACヘッダー無しとして処理が行われる。RRCでは、常に先頭のbitが1となっているため、Messagetypeの識別には10と11のみが使用でき、10がRRCCONNECTIONREQUEST、11がRRCCONNECTIONREESTABLISHMENTREQUESTのような形になる。この場合の課題は、Messagetypeを全て使っているため、新たにRRCmessageを定義できないことである。そのため、LCIDとして定義できる範囲を無駄に使用せず、なおかつ新たにRRCmessageを定義できるようにMessagetypeに使用できる領域を確保しておくことが望ましい。本実施の形態図27に示すように、本実施の形態でのMACヘッダーの構成の特徴は、拡張領域が先頭に存在し、その値によってMACヘッダーがあるか否かを判断可能としていることである。これは、72bitsしか送信用に割当てられないような場合には、複数のMACサブヘッダーを使用するという必要性が少ないという特徴をいかし、MACヘッダーがある場合には拡張領域を常に0にして一つのMACサブヘッダーのみを使用するような動作とすることにより実現される。よって、受信側は、拡張領域が0となっていた場合にはMACヘッダーがあるものとして処理し、1となっていた場合には、MACヘッダーがないものとしてRRCmessageとしてRRCで処理する。RRCでは、最初の2bitsを用いてメッセージの識別を行う。具体的な例としては、10がRRCCONNECTIONREQUEST、11がRRCCONNECTIONREESTABLISHMENTREQUESTのような形である。本方式ではMACヘッダーの2bit目にあたるがMACとしては使用されておらず予約ビットのままである。そのため、今後MACで拡張を行う際にその予約ビットを使うことが可能である。また逆に、RRCmessageを追加する必要がある場合にもそのビットを使うことが可能である。具体的には、MACヘッダーがあるか否かを拡張領域のみで見るのではなくて、MACヘッダーの最初の2bitsに当たる拡張領域と予約ビットをみて00となっていた場合に、MACヘッダー無しと判断する。これにより、RRCmessageを示すのに、01、1011の三つを使うことが出来る。このように本方式では、拡張領域をMACヘッダーの有無の識別に利用することにより、MACの拡張、もしくはRRCmessageの追加に対応している。以下図28を用いて本実施形態にかかる端末の動作を説明する。ST2801において、端末はRandomAccessResponseで割当てられたサイズを確認する。ここで、72bitsよりも多く割当てられた場合にはST2803に進む。72bitsが割当てられた場合にはST2804に進む。ST2804では、端末は、呼接続または再接続を行うのか、それ以外かを判断する。すなわち端末は、MACヘッダーを使わないか、使うかを判断する。ここで、MACヘッダーを使う場合には、ST2805に進み、使わない場合にはST2806に進む。ST2805に進んだ場合において、端末がRACHプリアンブルを自分で選択する場合すなわちNondedicatedRACHpreambleの場合には、ST2806に進み、基地局から与えられたRACHpreambleを用いる場合にはST2803に進む。ST2803では、端末は通常どおりMACヘッダーを使用し送信データの作成を行う。一方、ST2806では、端末はMACヘッダーの最初の拡張領域が0となるように送信データの作成を行う。このときのMACヘッダー構成例を図29、、、に示す。また、LCIDの定義の例を図30に示す。図29は、CRNTIのみを送信している場合である。ここで、40bitsのうちの16bitsがCRNTIとして使われ、残りの24bitsがpaddingとなっている。そのため、CRNTIとpaddingが入っているといいうことを示すLCIDがここでは入れられる。図29は、CRNTIとBSRを送信しており、CRNTIとBSRが入っているといいうことを示すLCIDがここでは入れられる。これは、BSRがハンドオーバーコンプリートよりも優先されるような場合に使われる。図29は、CRNTIとDCCHを送信している。ここで、DCCHは、前述のSRBのLogicalchannelとしての名称であり、highprioritySRBとlowprioritySRBと分かれているのと同様にDCCHとしても複数に分かれている。LCIDの定義としては、CRNTIとhighprioritySRBとが後に送信されると示すもののみを定義することも出来るし、逆にCRNTIとlowprioritySRBとが後に送信されると示すもののみを定義することも出来るし、両方を定義しても良い。図30では両方が定義される例をしめした。そして、実際に送信するDCCHに応じてLCIDを設定する。図29は、CRNTIとCQIを送信している。そのため、CRNTIとCQIが入っているといいうことを示すLCIDがここでは入れられる。ST2807では、端末は、MACヘッダー無しでメッセージを送信する。その際の送信データの例が図29、にそれぞれ呼接続時、再接続時として示してある。なお、Messagetype以外の情報の場所に関しては異なる配置でも良い。本実施の形態の動作により、LCIDとして定義できる範囲を無駄に使用せず、なおかつ新たにRRCmessageを定義できるようにMessagetypeに使用できる領域を確保しておくことが可能になる。なお、以上の説明ではCRNTIと他の情報を組み合わせるようにLCIDを定義した例を示したが、それ以外の方法も考えられる。端末がRACHプリアンブルを自分で選択した場合、基地局は、その端末がMessage3でCRNTIを入れることが予測できる。そのため、端末がRACHプリアンブルを自分で選択した場合には、常にMACヘッダーの後にCRNTIを入れるような動作に決めておけば、CRNTIと他の情報を組み合わせるようにLCIDを定義する必要が無くなる。具体的には、図31にその例を示す。図31は、CRNTIのみが入っていて、残りがpaddingになっている場合である。この場合には、LCIDとしてpaddingを示すLCIDを端末は入れる。基地局は、端末がRACHプリアンブルを自分で選択した場合には、常にMACヘッダーの後にCRNTIを入れることがわかっているため、CRNTIがMACヘッダーの後に来て、その後がpaddingであると理解することが可能となる。その他のケースを図31、、に示すが、動作としては同様であり、基地局は、CRNTIがあり、その後LCIDで示す情報が入ると理解することが可能となる。なお、上記ではCRNTIをMACヘッダーの直後に入れる例を示したが、その他の場所に設定することも可能である。以上説明した通信端末は、所定の手順にしたがって基地局と通信する通信端末であって、MAC制御情報に割り当てられている優先度であるMAC制御情報の優先度と、DRBおよびSRBに割り当てられている優先度との関係を確定する優先度制御部と、前記優先度制御部で確定した優先度の関係に従い、優先度の高い情報を先に送信するように制御する送信メッセージ生成部とを備える。上記構成によれば、MAC制御情報の優先度と、DRBおよびSRBに割り当てられている優先度との関係に応じて、どのような情報を送信するかを自由に制御できるようになる。したがって、通信サービスの内容や状況に応じた適切な制御が可能となる。例えば、VoIPを行っている場合にパススイッチングを早くする必要がある場合には、BSRよりもSRBの優先度を高くすることが考えられる。また逆に、パススイッチングを早く行う必要がなく、端末の持っているバッファー状態を早く把握したい場合には、BSRをSRBよりも優先度を上げることが出来る。また、当該通信端末には、前記基地局から送信される前記MAC制御情報の優先度を受信する受信部を設けることができる。また、当該通信端末は、前記MAC制御情報が、CRNTI、BSR、およびCQIを含み、前記送信メッセージ生成部が、前記DRB、SRB、CRNTI、BSR、およびCQIの優先度に従い、優先度の高い情報を先に送信するものである。上記構成によれば、例えば、CRNTIを優先度1、BSRおよびCQIを優先度3に設定すれば、SRBの優先度が2の場合に、CRNTIのみを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ヘッダーが存在するか否かを判断することが出来る。本出願は、2008年2月1日出願の日本特許出願、特願2008-023171に基づくものであり、その内容はここに参照として取り込まれる。以上、本発明の各種実施形態を説明したが、本発明は前記実施形態において示された事項に限定されず、明細書の記載、並びに周知の技術に基づいて、当業者がその変更応用することも本発明の予定するところであり、保護を求める範囲に含まれる。