"エリアにより異なる複数のSingleFrequencyNetwork運用形態を有するMBMSサービスを提供するシステムにおいて使用される基地局装置であって、前記複数のSFN運用形態を有するMultimediaBroadcastMulticastService用の制御情報について、前記複数のSFN運用形態毎に異なる制御情報であるMBMS制御情報を作成するMBMS制御情報作成手段と、作成された前記MBMS制御情報を送信する送信手段と、前記複数のSFN運用形態において共通のL1L2制御チャネルを介して前記MBMS制御情報の取得指示を通知する通知情報と、前記MBMS制御情報を取得するためのスケジューリングに関する情報とを送信する通知手段と、を具備する無線通信基地局装置。前記MBMS制御情報を取得するためのスケジューリングに関する情報は、前記MBMS制御情報のスケジューリング情報を含む、前記複数のSFN運用形態における共通のMBMS用のSchedulingBlockである、請求項1に記載の無線通信基地局装置。前記複数のSFNの運用形態は、SFNが運用される運用形態とSFNが運用されない運用形態Non-SFNを含む、請求項1または請求項2に記載の無線通信基地局装置。前記通知手段は、前記MBMS制御情報の取得指示をMBMSIndicationChannelにより通知する、請求項1から請求項3のいずれかに記載の無線通信基地局装置。前記MBMS制御情報は、MBMSSystemInformationBlockである、請求項1から請求項4のいずれかに記載の無線通信基地局装置。前記MBMS制御情報は、MBMSpointtomultipointControlChannelである、請求項1から請求項4のいずれかに記載の無線通信基地局装置。前記MBMS制御情報の取得指示の通知と、前記MBMS制御情報のスケジューリングに関する情報とが同一の送信単位となるように、送信タイミングを調整する送信タイミング調整手段を具備する請求項1から請求項6のいずれかに記載の無線通信基地局装置。しかしながら、LTEでは、MBMSがシステム開発当初から適用されており、様々な文献等においてMBMS用の新規機能、また新たなフレームワークを盛り込むことが提案されているものの、オーバーヘッドが増大するという問題がある。本発明はかかる点に鑑みてなされたものであり、LTEのMBMSにおいて、オーバーヘッドを削減する無線通信基地局装置を提供することを目的とする。本発明の無線通信基地局装置は、エリアにより異なる複数のSingleFrequencyNetwork運用形態を有するMBMSサービスを提供するシステムにおいて使用される基地局装置であって、前記複数のSFN運用形態を有するMultimediaBroadcastMulticastService用の制御情報について、前記複数のSFN運用形態毎に異なる制御情報であるMBMS制御情報を作成するMBMS制御情報作成手段と、作成された前記MBMS制御情報を送信する送信手段と、前記複数のSFN運用形態において共通のL1L2制御チャネルを介して前記MBMS制御情報の取得指示を通知する通知情報と、前記MBMS制御情報を取得するためのスケジューリングに関する情報とを送信する通知手段と、を具備する構成を採る。本発明によれば、LTEのMBMSにおいて、オーバーヘッドを削減することができる。以下、本発明の実施の形態について、図面を参照して詳細に説明する。ただし、実施の形態において、同一の機能を有する構成には同一符号を付し、重複する説明は省略する。実施の形態1図1は、本発明の実施の形態1に係るMIBMBMSSBMBMSSIBの関係を示す図である。UMTSでは、MCCHとして定義されている複数のMessageが報知情報の形態、すなわち、Systeminformationblockとは異なる体系で送信されていたが、ここでは、図1に示したように、MBMS用のSIB以下、MBMSSIBというとして定義されている。なお、SIBの単位としては、UMTSのMCCHでのmessage毎として考えることができる。例えば、MBMSMODIFIEDSERVICESINFORMATIONに該当するような情報を伝送するSIBを一つ定義し、MBMSUNMODIFIEDSERVICESINFORMATIONに該当するような情報を伝送するSIBを一つ定義するなどである。ただし、SIBの割り当て方としては、上記の方法に限らず、別の方法を用いてもかまわない。このように定義されたMBMSSIBは、MBMSのSIBに対するスケジューリング情報を含むMBMS用のSchedulingblock以下、MBMSSBというによってスケジューリングされる。スケジューリング情報としては、UMTSの報知情報の送信で定義されていた送信タイミングSystemFrameNumber上のポジション、送信間隔に加えて、radioblock等の別の情報が必要とされる可能性もあるが、どのような情報であってもよい。MBMSSBは、通常のSBと同様にMasterInformationBlockによってスケジューリングされる。このような動作により、UMTSにおいて、別の機能が必要とされていたMBMSのMCCH受信が報知情報で用いられている機能によって置き換えることが可能となる。具体的には、UMTSにおいて定義されていたRepetitionperiod、Accessinfoperiodは、MBMSSIBの送信間隔によって定義できる。これは、通常のSIBの送信に用いられる情報と同じである。これについて図2を用いて説明する。この図では、MIBは、送信間隔repetitionperiodを4とし、送信タイミングpositionを0としている。これは、UMTSでの定義と同様である。このような場合、SuperFrameNumberを4で割った余りが0となるタイミングでMIBが送信されることとなる。ここでは、MIBに格納されたMBMSSBのスケジューリング情報として、送信間隔repetitionperiod8、送信タイミングposition2となっていることから、SuperFrameNumberを8で割った余りが2となるタイミングでMBMSSBが送信されることとなる。同様に、MBMSSBに格納されたSIBのスケジューリング情報に基づいてSIBの送信間隔及び送信タイミングが決定される。以下、本発明の実施の形態1に係る基地局装置100の構成について図3を用いて説明する。スケジューリング部101は、後述するMBMSSIB作成部106からMBMSSIB種別と各MBMSSIB種別のデータサイズを取得し、これらに基づいて、MBMSSIBのスケジューリング情報を決定する。また、スケジューリング部101は、後述するMBMSSB作成部104から作成されたMBMSSBのデータサイズ等の情報を取得し、これに基づいて、MBMSSBのスケジューリング情報を決定する。決定されたMBMSSIBのスケジューリング情報はMBMSSB作成部104に、MBMSSBのスケジューリング情報はMIB作成部103にそれぞれ出力される。また、これらのスケジューリング情報は送信部107に出力される。報知情報データベース部102は、報知情報のうちMIBに関連する情報を記憶し、記憶したMIB関連情報をMIB作成部103に出力する。MIB作成部103は、スケジューリング部101から出力されたMBMSSBスケジューリング情報と、報知情報データベース部102から出力されたMIB関連情報とからMIBを作成し、作成したMIBを送信部107に出力する。MBMSSB作成部104は、スケジューリング部101から出力されたMBMSSIBスケジューリング情報に基づいて、MBMSSBを作成し、作成したMBMSSBを送信部107に出力する。また、作成したMBMSSBのデータサイズ等の情報をスケジューリング部101に出力する。MBMSデータベース部105は、MBMSとして提供するサービス情報と、このサービスを提供するために必要な設定情報を記憶し、記憶したこれらの情報をMBMSSIB作成部106に出力する。MBMSSIB作成部106は、MBMSデータベース部105から出力されたサービス情報と設定情報とに基づいて、MBMSSIBを作成し、作成したMBMSSIBを送信部107に出力する。また、作成したMBMSSIBの種別及びデータサイズをスケジューリング部101に出力する。送信部107は、MIB作成部103から出力されたMIB、MBMSSB作成部104から出力されたMBMSSB、MBMSSIB作成部106から出力されたMBMSSIBを、スケジューリング部101から出力されたスケジューリング情報にしたがって送信する。基地局装置100は、このような構成を有することから、MBMSSIBを通常の報知情報と同様に送信することができる。また、UMTSでは、Criticalinformation内で同一のRepetitionperiodを用いる必要があり、またどのような順番でMCCHのmessageが並んでいるかは受信するまで分からなかったが、上記方式では、MBMSSIB毎に送信頻度を変えられると共に、MBMSSIB毎の送信タイミングも通知できるため、より柔軟な動作が可能となる。Modificationperiodについても、UMTSの報知情報にて使用されているValuetagを使用することが考えられる。すなわち、Modificationperiodのような変更されない区間を定義するのではなく、Valuetagによって内容が変更されたか否かを通知することにより、端末において変更の有無を検出することができる。なお、このValuetagは、全てのMBMSSIB毎に別々に運用するのではなく、関連するMBMSSIB同士を同時に更新することも考えられる。具体的には、Notificationに関する情報はセットとして考えられるので、MBMSMODIFIEDSERVICESINFORMATIONに該当する情報を伝送するSIBと、MBMSUNMODIFIEDSERVICESINFORMATIONに該当する情報を伝送するSIBとで同様にValuetagをインクリメントする方法がある。また、極端な運用としては、UMTSにおいてCriticalとして定義されているmessageに該当する情報を伝送するSIBでは、全て同様にValuetagをインクリメントする方法も考えられる。なお、このValuetagは、他の報知情報送信用のValuetagと異なる値の範囲を持つことも可能である。具体的には、報知情報送信の際に、Predefinedconfiguration用のValuetag、Cellレベルの情報のValuetag、PLMNレベルの情報のValuetag等の複数の種類のValuetagがUMTSでは用意されている。これと同様に、MBMSSIB用のValuetagを設けることが考えられる。このように実施の形態1によれば、MCCHを報知情報のMBMSSIBとして作成し、MBMSSIBのスケジューリング情報を含めてMBMSSBを作成し、MBMSSBのスケジューリング情報を含めてMIBを作成し、作成したこれらの情報を端末に送信することにより、MBMSSIBを通常の報知情報と同様に送信することができるので、オーバーヘッドを削減することができる。なお、本実施の形態では、Modificationperiodの代わりにValuetagを用いて変更を検出する方法について説明したが、Modificationperiodの概念を使用することも可能である。具体的には、MBMSSBもしくはMIBにModificationperiodの情報を含めて端末に通知することである。この際、Modificationperiodを開始する点としてはUMTSと同じく、SystemFrameNumberを特定の値でModをとった値が0になる点でもよいし、MBMSSBなどを基点としてもよい。また、Modificationperiodの間隔も、UMTSと同様にMBMSSIBの送信間隔の整数倍にすることが考えられるし、MBMSSBの送信間隔の整数倍として定義することも可能である。また、本実施の形態では、MBMSSBを定義したが、MBMSSBの内容が全てMIBに含まれることも運用として考えられる。このような場合には、MIBから直接MBMSSIBのスケジューリングが行われる。また、MBMSSBとしてMBMS関連のSIBのみを含むのではなく他のSIBを含めるように普通のSBを用いてもかまわない。LTEにおいては、報知情報の送信は固定のリソースで送られる部分と、可変のリソースで送られる部分が定義されている。ここで、固定のリソースとは、図4に示す中心の1.25MHz帯域のうち、固定の時間タイミングとなる。また、可変のリソースは、中心の10MHz帯域である。この際に、MIB、MBMSSB、MBMSSIBがどのように送信されるかについていくつかパターンが考えられる。MIBは、端末が固定の情報のみで受信可能なように固定のリソースで送られる必要がある。一方、MBMSSBとMBMSSIBは、可変のリソースで送ることが考えられる。そのため、図4に示すように、MIBのみを固定のリソースを用いて送信し、MBMSSBとMBMSSIBを可変のリソースで送信することが考えられる。しかしながら、MBMSSBを上述したようにMIBに含むことも可能であるし、固定のリソースで送ることも可能である。また、MBMSSIBに関しても固定のリソースを用いて送信してもかまわない。また、複数の周波数帯域がMBMS用に使用されることが考えられる。この様子を図5に示す。ここで、図5aは、複数の周波数帯域のそれぞれで同じエリアのセルを構成する例を示し、図5bは、複数の周波数帯域で異なるエリアのセルを構成する例を示す。まず、図5aに示した例について考える。この場合、MBMSSBの送信方法として、図6a~dに示すように、4通り考えられる。図6aは、複数の周波数帯域でMBMSを提供し、それぞれの周波数帯域のMBMSSBの情報をそれぞれの周波数帯域で送信する場合を示す。図6bは、複数の周波数帯域でMBMSを提供し、それぞれの周波数帯域のMBMSSBの情報と他の周波数帯域のMBMSSBの情報をそれぞれの周波数帯域で送信する場合を示す。図6cは、特定の周波数帯域でMBMSを提供し、MBMSを提供している周波数帯域のMBMSSBの情報をそれぞれの周波数帯域で送信する場合を示す。図6dは、特定の周波数帯域でMBMSを提供し、MBMSを提供している周波数帯域はMBMSSBの情報を提供し、それ以外の周波数帯域は、MBMSを提供している周波数帯域の情報のみを送信する場合を示す。本実施の形態では、図6a~dに示したいずれの方法でも適用可能である。次に、図5bに示した例について考える。この場合MBMSSBの送信方法として、図7a~dに示すように4通りの方法が考えられる。また、図7a~dは、それぞれ図6a~dとそれぞれ同じような動作となっている。ただし、異なる点としては、セルのエリアが周波数帯域毎に異なるため、複数のセルが他周波数帯域の同一セルを示すケース、逆に一つのセルが他周波数帯域の複数のセルを示すことが考えられる。すなわち、MBMSを提供しているエリアと通常のサービスを提供するエリアが異なることになるため、複数のセルが一つのセルを示すケースがある図7b、図7c。また、LTEにおいてはMBMS専用の周波数帯域を設けることが考えられている。これらは、LTEにおいてMBMSdedicatedcell、MBMSdedicatedlayer等と呼ばれている。これらのセルでは、通常のセルのようにMIB等が送信されない可能性がある。この場合には、図8a及び図8bに示すように、二つの対応が可能である。図8aは、MBMSdedicatedcellを含む複数の周波数帯域でMBMSを提供し、それぞれの周波数帯域のMBMSSBの情報とMBMSdedicatedcellのMBMSSBの情報をMBMSdedicatedcell以外のセルで送信する場合を示す。図8bは、MBMSdedicatedcellのみでMBMSを提供し、MBMSdedicatedcellのMBMSSBの情報をMBMSdedicatedcell以外のセルで送信する場合を示す。これらの動作により、異なる周波数帯を用いた運用、MBMSdedicatedcellを用いた運用にも対応することが可能である。なお、複数の周波数帯域でMBMSを送信する際に、MBMSSBのスケジューリング情報を周波数間で共通にすることが考えられる。すなわち、自周波数帯域のMBMSSBの位置を示す為にMIBに含まれる情報が、全ての周波数帯域で同じものにすることである。このようなことで、MBMSSBを示す為の情報を削減することも可能である。実施の形態2LTEでのMBMSにおいては、SFNoperationが検討されている。SFNoperationとは、複数の基地局から同じ周波数帯域で同じタイミングで同一情報を送信することにより、信号を無線上で合成する機能である。このSFNoperationにより、セルエッジに存在するような端末の受信品質を大幅に改善することが可能である。しかしながら、これは複数の基地局で同じ情報を適用することを前提としているため、特定の基地局のみで送信されるような情報に関しては適用されない。そのようなケースをここではNonSFNoperationと呼ぶ。SFNoperationの特徴は、上述したように基地局間の信号の合成にあるが、これを実現するには、通常のセル内の通信に比べて長いCyclicPrefixを用いる必要がある。これは、複数の基地局からの信号を合成するのは、1つの基地局からの信号を合成するのに比べて長い期間が必要となるからである。これらのことから、SFNoperationを行うケースと、NonSFNoperationを行うケースとで異なるフォーマットでデータが送信されることになる。LTEでは、SFNoperationに対応したTransportchannelとしてMulticastChannelが用意されており、通常の送信用のTransportchannelとして、DownlinkSharedChannelが用意されている。そのため、SFNoperation用の情報はMCHで運ばれ、NonSFNoperation用の情報はDLSCHで送られるといえる。上述の通り、MCHとDLSCHとではフォーマットが異なるため、同じ周波数帯域内で同一のタイミングでは送信できないため、異なるタイミングで送信する必要がある。よって、SFNoperationのMBMSデータと、NonSFNoperationのMBMSデータとでは異なるタイミングで送信されることとなる。このことは、データ自体のみならず、その制御情報MCCHにも当てはめることが可能である。すなわち、SFNoperationを行うMBMSデータをSFNoperationし、NonSFNoperationのMBMSデータをNonSFNoperationするということである。ここで、サブフレームの配置例を図9に示す。図9に示すように、MBMSSBにおいて、SFNoperation用のSIBとNonSFNoperation用のSIBが別々にスケジューリングされている。これは、1つのSIBであっても、SFNoperation用とNonSFNoperation用とで別のタイミングで送る必要があるからである。このようなスケジューリングにより、MCCHに対してもSFNoperationとNonSFNoperationを提供することができる。以下、本発明の実施の形態2に係る基地局装置200の構成について図10を用いて説明する。SFN対応スケジューリング部201は、後述するSFNoperation用MBMSSIB作成部203からSFNoperation用のMBMSSIB種別とそのデータサイズを取得し、また、後述するNonSFNoperation用MBMSSIB作成部204からNonSFNoperation用のMBMSSIB種別とそのデータサイズを取得し、取得したこれらの情報に基づいて、MBMSSIBのスケジューリング情報を決定する。決定されたMBMSSIBのスケジューリング情報はMBMSSB作成部202に出力される。このとき、SFN対応スケジューリング部201は、SFNoperation用MBMSSIBをSFNoperationが可能なタイミングで送信できるように設定し、NonSFNoperation用MBMSSIBをSFNoperationが行わないタイミングで送信するように設定する。なお、SFN対応スケジューリング部201はSFNoperationが行えるか否かの情報を有しているものとする。SFN対応MBMSSB作成部202は、SFN対応スケジューリング部201から出力されたMBMSSIBのスケジューリング情報を用いて、SFNoperation用のスケジューリング情報と、NonSFNoperation用のスケジューリング情報とを分けたMBMSSBを作成する。作成されたMBMSSBは送信部107に出力される。また、作成したMBMSSBのデータサイズ等の情報をSFN対応スケジューリング部201に出力する。SFNoperation用MBMSSIB作成部203は、MBMSデータベース部105から出力されたサービス情報と設定情報とに基づいて、SFNoperation用MBMSSIBを作成し、作成したSFNoperation用MBMSSIBを送信部107に出力する。また、作成したSFNoperation用MBMSSIBの種別及びデータサイズをSFN対応スケジューリング部201に出力する。NonSFNoperation用MBMSSIB作成部204は、MBMSデータベース部105から出力されたサービス情報と設定情報とに基づいて、NonSFNoperation用MBMSSIBを作成し、作成したNonSFNoperation用MBMSSIBを送信部107に出力する。また、作成したNonSFNoperation用MBMSSIBの種別及びデータサイズをSFN対応スケジューリング部201に出力する。このように実施の形態2によれば、SFNoperation用のMBMSデータに対するMBMSSIBと、NonSFNoperation用のMBMSデータに対するMBMSSIBとをそれぞれスケジューリングすることにより、SFNoperationに対応するMBMSの制御情報を送信することができる。なお、本実施の形態では、1つのMBMSSBがSFNoperation用のSIBに対するスケジューリング情報、NonSFNoperation用のSIBに対するスケジューリング情報の両方を含む場合について説明したが、MBMSSBとしてSFNoperation用のMBMSSB、NonSFNoperation用のMBMSSBと定義することも可能である。また、MBMSSBというMBMS専用のSBではなく一般的なSBである場合には、SFNoperationを行うSIB用のSB、NonSFNoperationを行うSIB用のSBとして定義することも可能である。実施の形態3実施の形態2では、SFNoperation用のMBMSデータに対する制御情報MCCHをSFNoperationを行い、NonSFNoperation用のMBMSデータに対する制御情報MCCHをNonSFNoperationを行う場合について説明したが、SFNoperationを行うか、NonSFNoperationを行うかがMBMS制御手順であるProcedureの途中で変わることが考えられる。具体的には、特定のMBMSデータを要求する端末の数が少なく、これらの端末が特定のセルに集中している場合を想定する。このような場合には、SFNoperationを行って、受信する端末のいないセルを多数含む全てのセルでMBMSデータを送るよりも、NonSFNoperationを行って、特定のMBMSデータを要求する端末が存在するセルのみでMBMSデータを送信する方が効率的である。この様子を図11に示す。図11に示すSFNareaは、SFNoperationを行う単位であり、この範囲内の全てのセルにおいて同一の情報が同一タイミング及び同一周波数で送信される。これにより、このSFNarea内であればセルエッジにいても基地局間合成が無線上で実施される。この図では、特定のMBMSデータを要求する端末が3つのセルにのみ存在する場合を示している。このような場合には、上記3つのセル以外の他セルでMBMSデータを送信することは無駄であるため、上記3つのセルのみで送信することが考えられる。ところが、このように3つのセルにのみ特定のMBMSデータを要求する端末が存在することを検出するには、このMBMSデータを要求する端末の場所を既存のCountingなどを用いる必要がある。このCountingの指示は、セル間で共通にすることができるので、SFNoperationを適用することが可能である。このように、SFNoperationでProcedureが始まり、最終的にNonSFNoperationとなるような動作が考えられる。このようなProcedureの例を図12に示す。図12a~hにおいては、全て同じProcedureとなっているが、個々のmessageにSFNoperationを行うか、NonSFNoperationを行うかが異なっている。以下、具体的なProcedureの手順を示す。ST301では、基地局から端末にサービスの提供が始まることを通知し、ST302では、基地局から端末にどのようなサービスが開始するかを示す情報を含むNotificationを送信する。ST303では、基地局から端末にAccessInfoを送信することによってCountingに用いる情報を提供し、ST304では、端末から基地局にCountingresponseを送信することによって、Countingの結果を通知する。ST305では、基地局から端末にRBInfoを送信することによって、MTCHを送信するRB情報を通知し、ST306では、基地局から端末にMTCHによって実際にデータを送信する。このようなProcedureの過程で、MessageをMCH又はDLSCHによって送信することが考えられる。例えば、図12aでは、全てのMessageがMCHによって送信される場合で送られるProcedureを示しており、図12cでは、ST301~ST303までのMessageがMCHによって送信され、CountingResponseの結果、NonSFNoperationが決定されると、ST305,ST306のMessageがNonSFNoperationのDLSCHによって送信されるProcedureを示している。また、図12gでは、図12cに示すProcedureとは逆に、ST301~ST303までのMessageがDLSCHによって送信され、CountingResponseの結果、NonSFNoperationが決定されると、ST305,ST306のMessageがSFNoperationのMCHによって送信されるProcedureを示している。ところが、このように、SFNoperationとNonSFNoperationが切り替わる場合には、以下のような問題がある。すなわち、個々のサービスをSFNoperationで運用するか、NonSFNoperationで運用するかを切り替える場合には、端末では両方のMessageを受信する必要がある。具体的には、図12cに示す場合では、ST305のRBInfoからNonSFNoperationのDLSCHに切り替わっている。そのため、端末ではST305のRBInfoをNonSFNoperation用として認識する必要があり、このような切り替えに対応する必要がある。図12では、全てのパターンを示したが、Countingの結果に基づいてSFNoperationか否かを判断する場合、SFNoperationとNonSFNoperationとの切り替えが生じるのは、図12cとgに示すProcedureである。そのため、Countingの結果を通知するMessageを図13に示すようにST351のCountingresultとして定義する。ここで、Countingresultは、今までのProcedureと同じチャネル、すなわち、MCHかDLSCHで送信される。図13aに示す場合には、ST301~ST303のMessageがMCHによって送信される。そのため、ST351のCountingresultもMCHによって送信され、これによりST305及びST306のMessageがMCHかDLSCHかを通知する。図13bに示す場合には、ST301~ST303のMessageがDLSCHによって送信される。そのため、ST351のCountingresultもDLSCHによって送信され、これによりST305及びST306のMessageがMCHかDLSCHかを通知する。図14は、本発明の実施の形態3に係る基地局400の構成を示すブロック図である。図14が図10と異なる点は、受信部401及びCounting処理部402を追加した点と、MBMSデータベース部105をMBMSデータベース部403に変更した点である。受信部401は、複数の端末から送信された信号を受信し、受信した信号をCounting処理部402に出力する。Counting処理部402は、受信部401から出力された信号に基づいてCountingを行い、Countingの結果をMBMSデータベース部403に出力する。Message作成手段としてのMBMSデータベース部403は、Counting処理部402から出力されたCountingの結果に基づいて、特定のMBMSデータに対する制御情報にSFNoperationを適用するか否かを判定する。MBMSデータベース部403は、この判定結果をCountingresultとしてSFNoperation用MBMSSIB作成部203又はNonSFNoperation用MBMSSIB作成部204に出力する。ここで、図14に示した基地局400の動作を図13aに示したProcedureに基づいて説明する。まず、ST301のNotification及びST302のAccessInfoはMCHで送信されるため、対応するSIBの作成に用いる情報がMBMSデータベース部403からSFNoperation用MBMSSIB作成部203に出力される。SFNoperation用MBMSSIB作成部203では、MBMSデータベース部403から出力された情報を用いてSIBを作成し、作成したSIBを示す情報をSFN対応スケジューリング部201に、SIB自体を送信部107に出力する。これ以降ST301のNotification及びST302のAccessInfoの送信処理は実施の形態2と同様であるため、その詳細な説明は省略する。受信部401では、ST304のCountingresponseを受信し、受信したCountingresponseをCounting処理部402に出力する。Counting処理部402では、受信部401から出力されたCountingresponseに基づいて、このサービスの提供をこのセルで行うか否かを判定し、提供を行う場合にはSFNoperationを行うか否かを判定する。判定結果はMBMSデータベース部403に出力される。MBMSデータベース部403では、Counting処理部402から出力された判定結果に基づいて、ST305のRBInfo及びST306のMTCHを送信する必要があるか否かを判定する。送信する必要がある場合には、SFNoperationを行うか否かを判定する。そしてその結果をST351のCountingresultとしてSFNoperation用MBMSSIB作成部203又はNonSFNoperation用MBMSSIB作成部204に出力される。ただし、ST303のAccessInfoがSFNoperationで送信されていた場合には、CountingresultはSFNoperation用MBMSSIB作成部203に出力され、ST303のAccessInfoがNonSFNoperationで送信されていた場合には、CountingresultはNonSFNoperation用MBMSSIB作成部204に出力される。また、SFNoperationを行うと判断した場合には、ST303のRBInfoの内容をSFNoperation用MBMSSIB作成部203に出力し、NonSFNoperationを行うと判断した場合には、ST303のRBInfoの内容をNonSFNoperation用MBMSSIB作成部204に出力する。図12cでは、NonSFNoperationで行うことになっているため、RBInfoの内容をNonSFNoperation用MBMSSIB作成部204に出力することになる。これ以降の動作としては、既存の動作及び実施の形態2の動作と同様である。図15は、上述した基地局400の動作を示すフロー図である。この図において、ST501では、Notificationを送信し、ST502では、AccessInfoで設定するパラメータを決定する。具体的には、既にAccessInfoを送信している場合には、Responseを返す端末がより増えるようなパラメータに決定するなどである。ST503では、AccessInfoを送信し、その結果であるResponseを確認する。ST504では、Countingの結果が、送信を行うか否か、SFNoperationか否かの判定に十分であるか否かの判定を行う。十分である場合にはST505に移行し、十分でない場合にはST502に戻る。ST505では、Countingの結果、サービスの提供をこのセルで行うか否かを判定し、提供を行うことになった場合にはST506に移行し、送信を行わないことになった場合にはST511に移行し、処理を終了する。ST506では、SFNoperationを行うか否かを判断し、行う場合にはST507に移行し、行わない場合にはST509に移行する。ST507では、SFNoperationでサービスが開始されることをCountingresultで端末に通知し、ST508では、以降のMBMS制御情報、データをSFNoperationで送信するように制御する。ST509では、NonSFNoperationでサービスが開始されることをCountingresultで端末に通知し、ST510では、以降のMBMS制御情報、データをNonSFNoperationで送信するように制御する。このような動作により、SFNoperationとNonSFNoperationとの切り替えが可能である。なお、ここでは1つのサービスに対しての動作であり、MBMS全体の動作ではない。図16は、本発明の実施の形態3に係る端末600の構成を示すブロック図である。図16において、報知情報受信部601は、基地局400から送信された報知情報を受信し、後述するMIB処理部602、MBMSSB処理部603及びMBMS制御部605から出力される情報に基づいて、受信した報知情報に含まれるMIBをMIB処理部602に、MBMSSBをMBMSSB処理部603に、MBMSSIBをMBMSSIB処理部604にそれぞれ出力する。なお、ここでは、報知情報として、MIB、MBMSSB、MBMSSIBが含まれる。MIB処理部602は、報知情報受信部601から出力されたMIBに基づいて、MBMSSBのスケジューリング情報を取得し、取得したMBMSSBのスケジューリング情報をMBMS制御部605に通知すると共に、報知情報受信部601にMBMSSBのスケジューリング情報をセットする。MBMSSB処理部603は、報知情報受信部601から出力されたMBMSSBからMBMSSIBのスケジューリング情報を取得し、取得したMBMSSIBのスケジューリング情報をMBMS制御部605に通知すると共に、報知情報受信部601にMBMSSIBのスケジューリング情報をセットする。MBMSSIB処理部604は、報知情報受信部601から出力されたMBMSSIBを処理し、処理したMBMSSIBをMBMS制御部605に通知する。MBMS制御部605は、MIB処理部602、MBMSSB処理部603、MBMSSIB処理部604から出力された情報に基づいてMBMSの制御を行う。この制御結果に基づいて、報知情報受信部601にMBMSSB受信及びMBMSSIB受信の指示を行い、MBMSデータ受信部607にMBMSデータ受信の指示を行う。また、Counting等により応答を返す必要がある場合には、その応答を作成し、作成した応答をMBMS関連Message送信部606に出力する。MBMS関連Message送信部606は、MBMS制御部605から出力されたCountingの応答などのMBMS用の上り信号を基地局400に送信する。MBMSデータ受信部607は、MBMS制御部605から出力されたMBMSデータ受信の指示に従い、基地局400から送信されたMBMSデータを受信する。このような構成により、端末600はMBMSの制御情報を報知情報として報知情報受信部601で受信し、MBMS制御情報であるMBMSSIBをMBMSSIB処理部604で処理できるようになる。ここで、SFNoperationとNonSFNoperationとが1つのMBMSデータのために異なる例として、Counting処理のみをセル単位で実施できるようにすることが考えられる。すなわち、Counting処理はセル毎に端末からの応答を受け取って処理するものであるため、あるセルではCountingで端末が存在することを直ちに検出できる場合もあるし、また、あるセルではCountingで端末が存在することをなかなか検出できない場合もある。このようなことから、Counting処理はセル毎に行うことが考えられる。Counting処理においては、適切な数の端末600がResponseを返すようにProbabilityfactorを調整する必要がある。この処理が基地局間で異なる場合が考えられる。このときの動作を図17に示す。図17aは、Countingのためのmessageが常にMCHで送られる場合を示している。これに対して、図17bにおいては途中でMCHからDLSCHに変わっている。これは、最初はSFNarea内で全て同じ設定で始めたが途中で変更する必要がある場合である。このような動作に対応するために、次のAccessInfoがMCHで送信されるのか、DLSCHで送信されるのかをST702-n1≦n≦N-1のAccessInfoのMessageに示すことが考えられる。図17cは、AccessInfoが最初からDLSCHで送られている。この場合には、DLSCHによってAccessInfoが送られることをST301のNotificationで示す必要がある。この動作も、図14に示した構成で実現可能である。具体的には、Counting処理部402からの結果に基づいて、MBMSデータベース部403においてAccessInfoST702-1~ST702-Nが送られるのがSFNoperationか否かの情報を前のMessage~AccessInfoの情報として追加するようになる。このような動作は、図11に示したような環境で必要となる。すなわち、通常のSFNoperationではSFNarea内の全てのセルで送信するか否かを最初に判断し、SFNoperationを行わないと判断した場合には、各セルでサービス提供を行う必要があるかどうかの判断を行うことになる。この際に、該当する端末が存在することを早く検出したセルと遅く検出したセルとで異なるProbabilityfactorを用いて送信することが考えられる。これにより、早く検出できたセルでの不要な端末からの送信を制限することができる。このような動作は、図18に示したような部分的なSFNoperationを行う際にも必要と考えられる。この場合では、図11の動作に加えてCountingの結果、端末の存在を検出したセルの隣接セルに対しても送信を行い、部分的なSFNoperationを行うことが考えられる。この場合には、端末を検出したセル、その隣接セル、端末を検出していないセルのそれぞれで異なるProbabilityfactorを用いることが考えられる。このように実施の形態3によれば、SFNoperationとNonSFNoperationとがMBMS制御手順であるProcedureの途中で切り替わる場合、端末に通知するCountingresultに切り替えを示す情報を含めることにより、SFNoperationを適用したMessageとNonSFNoperationを適用したMessageの両方を送る必要がなくなり、MBMS制御手順を効率よく行うことができる。なお、本実施の形態では、Countingresponseが返ってくるタイミングをAccessInfoが終わってから返ってくる例を図12、13、17に示したが、端末のCountingprocedureの結果によっては、ST303-1~ST303-Nの間で返ってくることもあり、どのようなタイミングでresponseが返ってきてもよい。また、本実施の形態では、図12、13、17に示したように、Notificationとして1つのMessage、RBInfoとして1つのMessageであるような場合を示したが、従来例で示したUMTSのように複数のMessageまたはSIBで運用してもよい。また、図16で記載した端末の動作は、実施の形態1、2に対応した基地局からの信号を受信する端末としても成立する。実施の形態4UMTSにおいて、MBMSIndicationChannelが定義されており、これによりMCCHの受信を端末に対して指示することが可能となっている。より詳細には、図19に示すようにMICHが、次のModificationperiodの最初からMCCHのNotificationmessageを受信することを促すような動作となっている。また、ここで、MICHとしては複数のサービスをまとめたIDを用いて端末に対する指示を行う。そのため、端末としては実際に受信したいサービスに対する通知ではない場合もある。よって、端末はNotificationの内容を確認して最終的に自分の受信したいサービスが存在するのかを判断するようになる。このMICHの動作は、UMTSにおいて通常の呼の通知を行うPagingIndicatorと近い概念となっている。そのため、LTEにおいてもPICHと近い概念になると考えられる。LTEでのPICHの概念を図20に示す。ここに示されるようにPICHは、データ部分にどの様な情報がどのように送信されているかを示すL1L2制御チャネルにて送信される。端末は、このPICHを取得することによりPaging情報が含まれていることを認識することができる。この動作と同じようにMICHを考えると、MICHがL1L2制御チャネルにて送信され、データ部分にNotificationが送られるような動作が考えられる。しかしながら、実施の形態2に示した通り、SFNoperationを行うNotificationとNonSFNoperationを行うNotificationがあると考えられ、それぞれ異なるタイミングで送信する必要がある。そのため、MICHとしても2通り用意し、端末としても両方のMICHを待ち受けなくてはいけない。この結果、端末として受信を行う時間が長くなるため、消費電力が増加してしまう。また、Modificationperiodの概念がLTEにも導入された場合には、SFNoperationとNonSFNoperationとで異なるrepetitionperiodを用いる可能性がある。そのため、この場合でもMICHとして二種類必要となる。そこで、Notificationに対してMICHを定義するのではなくて、MBMSSBに対してMICHを定義することが考えられる。この概念図を図21に示す。図21に示すように、MICHはMBMSSBが送信されるのと同じサブフレームまたはslot、TTIで送られる。これにより、端末はMBMSSBが送信されるTTIのL1L2controlchannelを確認するだけでよく、複数のNotificationを待ち受ける必要がなくなる。また、図21に示したように、MCHを送信するサブフレームまたはslot、TTIではL1L2制御情報が存在しない可能性もある。これは、MBMSがある程度固定的なリソースで送信されるものであり、時間や周波数上に自由にスケジューリングする種類のものではないからである。このような場合に対しても、MBMSSBに対してMICHを定義することは有効である。図22は、本発明の実施の形態4に係る基地局800の構成を示すブロック図である。図22が図10と異なる点は、MICH作成部802及びMICH送信タイミング調整部804を追加した点と、MBMSデータベース部105をMBMSデータベース部801に変更し、送信部107を削除し、L3L2送信部803及びL1送信部805を追加した点である。MBMSデータベース部801は、サービス情報と設定情報とをSFNoperation用MBMSSIB作成部203とNonSFNoperation用MBMSSIB作成部204とに出力し、また、MICHを作成するための情報をMICH作成部802に出力する。MICH作成部802は、MBMSデータベース部801から出力された情報に基づいて、MICHを作成し、作成したMICHをMICH送信タイミング調整部804に出力する。L3L2送信部803は、MIB作成部103から出力されたMIB、SFN対応MBMSSB作成部202から出力されたMBMSSB及びSFNoperation用MBMSSIB作成部203から出力されたSFNoperation用MBMSSIBをLayer3、Layer2レベルから下位レイヤへ送信すると共に、MICH送信タイミング調整部804に出力する。MICH送信タイミング調整部804は、L3L2送信部803から出力されたMBMSSBが送信されるサブフレームのL1L2制御チャネルにて、MICH作成部802から出力されたMICHを送信するように、SFN対応スケジューリング部201から出力されたスケジューリング情報に基づいて、MICHの送信タイミングを調整し、送信タイミングを調整したMICHをL1送信部805に出力する。L1送信部805は、SFN対応スケジューリング部201から出力されたスケジューリング情報に基づいて、MICH送信タイミング調整部804から出力されたMICHをLayer1レベルで送信する。ここで、図22に示した基地局800の動作について説明する。MBMSデータベース部801は、新しいサービスの開始を行う際にMICH作成部802に対してそのサービスの情報を通知する。MICH作成部802では、MBMSデータベース部801から取得した情報に基づいて、MICHとして送信する内容を作成する。具体的には、新しく開始されるサービスを示す指示情報を作成する。この情報はMICH送信タイミング調整部804に出力される。MICH送信タイミング調整部804では、MBMSSBとMICHとが同一のタイミングで送られるように調整する。この際に、単純に同一のタイミングで送信するのみではなく、新たなサービスを提供するための制御情報が送信されるタイミングを考慮する必要がある。実施の形態1で示したようにUMTSでのModificationperiodと同じような役割を果たすために、Valuetagの更新、またはModificationperiodを適用することが考えられる。前者の場合には、新しいサービスに対する情報を送ることにより制御情報に対するValuetagが更新された最初のMBMSSBからMICHを送信する必要がある。この動作例を図23に示す。このようにValuetagが更新されたタイミングからMICHの送信が始まる。また、今回はSFNoperationに関する制御情報のみがvaluetag更新されている例を示した。端末がvaluetagの更新に追従している時などでは、このvaluetagの更新された方のみを確認するなどの動作も可能である。なお、Modificationperiod自体が使われる場合には、Modificationperiod内で最初のMBMSSBからMICHを送信する必要がある。この際、前述のようにSFNoperationとNonSFNoperationとが異なるModificationperiodを使用する場合を考慮する必要がある。そのため、SFNoperationの場合には、SFNoperationのModificationperiod内の先頭のMBMSSBに対してMICHを送信し、NonSFNoperationの場合には、NonSFNoperationのModificationperiod内の先頭のMBMSSBに対してMICHを送信することが考えられる。なお、ここでは、Notificationの内容が変更されるModificationperiod内のMBMSSBに対してMICHを送信することを考えたが、前のModificationperiodにおいてMBMSSBを先に更新するような場合には、前のModificationperiodにおいてMBMSSBに対するMICHを送信することになる。以上の動作により、1つのMICHを用いて端末がSFNoperationされるMBMSデータとNonSFNoperationされるMBMSデータの双方の待ち受けが可能となる。図24は、本発明の実施の形態4に係る端末900の構成を示すブロック図である。図24が図16と異なる点は、MICH受信部901を追加した点である。MICH受信部901は、MIB処理部602から出力されたMBMSSBのスケジューリング情報に基づいて、MICHを受信する。受信したMICHはMBMS制御部605及び報知情報受信部601に出力される。すなわち、MBMSSBをMICHに基づいて受信する場合には、MICH受信部901からの情報に基づいてMBMSSB受信処理が報知情報受信部601で行われる。また、MBMSSIBのNotificationをこのMICHに基づいて受信する場合には、MBMS制御部605からの情報に基づいてMBMSSIB受信処理が報知情報受信部601で行われる。このような構成により、MICHに対応してMBMSSB又はMBMSSIBの受信が可能となる。このように実施の形態4によれば、MBMSSBとMICHとを同一のTTI又はslot等の同一の送信単位で送信することにより、1つのMICHを用いて端末がSFNoperationされるMBMSデータとNonSFNoperationされるMBMSデータの双方の待ち受けが可能となり、端末の待ち受け時間を短縮することができるので、消費電力を低減することができる。なお、本実施の形態では、MICHをMBMSSBを送るサブフレームまたはslot、TTIのL1L2制御チャネルで送信することを示した。この拡張として、MBMSSBを送るタイミングの数サブフレームまたはslot、TTI前からMICHの送信を行うことも可能である。このような動作により、MICHの受信失敗などを防ぐことが可能となる。この動作例を図25に示す。また、本実施の形態では、MICHに含まれる内容としてサービスを示す情報を示した。これに加えて、そのサービスに対するNotificationがSFNoperationされるのか、NonSFNoperationされるのかを情報として含むことが考えられる。この場合には、端末はSFNoperationのNotificationを確認すればよいのか、NonSFNoperationのSFNを確認すればよいのかがわかるため、片方のみのNotificationを確認することが可能である。また、上記で示したようにUMTSではサービスを完全に示す内容がMICHで送信されているのではなく、サービス群を示す情報がMICHにて送信されている。この概念をLTEで用いる際に、SFNoperationでNotificationを行うものとNonSFNoperationでNotificationを行うものとでグループを分けるようなことが可能である。なお、上記各実施の形態では、本発明をハードウェアで構成する場合を例にとって説明したが、本発明はソフトウェアで実現することも可能である。また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるLSIとして実現される。これらは個別に1チップ化されてもよいし、一部または全てを含むように1チップ化されてもよい。ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGAFieldProgrammableGateArrayや、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサーを利用してもよい。さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。"