(移動通信システム)
実施形態に係る移動通信システムの構成について説明する。実施形態に係る移動通信システムは、3GPPで仕様が策定されているLTE(Long Term Evolution)システムである。図1は、実施形態に係るLTEシステムの構成を示す図である。図2は、MBMSのためのネットワーク構成を示す図である。
図1に示すように、LTEシステムは、無線端末(UE:User Equipment)100、無線アクセスネットワーク(E−UTRAN:Evolved−UMTS Terrestrial Radio Access Network)10、及びコアネットワーク(EPC:Evolved Packet Core)20を備える。E−UTRAN10及びEPC20は、LTEシステムのネットワークを構成する。
UE100は、移動型の通信装置であり、自身が在圏するセル(サービングセル)を管理するeNB200との無線通信を行う。
E−UTRAN10は、基地局(eNB:evolved Node−B)200を含む。eNB200は、X2インターフェイスを介して相互に接続される。eNB200は、1又は複数のセルを管理しており、自セルとの接続を確立したUE100との無線通信を行う。eNB200は、無線リソース管理(RRM)機能、ユーザデータ(以下、単に「データ」という)のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、UE100との無線通信を行う機能又はリソースを示す用語としても用いられる。
EPC20は、モビリティ管理エンティティ(MME)及びサービングゲートウェイ(S−GW)300を含む。MMEは、UE100に対する各種モビリティ制御等を行う。S−GWは、データの転送制御を行う。MME/S−GW300は、S1インターフェイスを介してeNB200と接続される。
MBMS向けのネットワークエンティティについて説明する。E−UTRAN10は、MCE(Multi−Cell/Multicast Coordinating Entity)11を含む。MCE11は、M2インターフェイスを介してeNB200と接続され、M3インターフェイスを介してMME300と接続される(図2参照)。MCE11は、MBSFN無線リソース管理・割当等を行う。具体的には、MCE11は、MBSFN伝送のスケジューリングを行う。これに対し、SC−PTM伝送のスケジューリングはeNB200により行われる。
EPC20は、MBMS GW(MBMS Gateway)21を含む。MBMS GW21は、M1インターフェイスを介してeNB200と接続され、Smインターフェイスを介してMME300と接続され、SG−mb及びSGi−mbインターフェイスを介してBM−SC22と接続される(図2参照)。MBMS GW21は、eNB200に対してIPマルチキャストのデータ伝送及びセッション制御等を行う。
EPC20は、BM−SC(Broadcast Multicast Service Center)22を含む。BM−SC22は、SG−mb及びSGi−mbインターフェイスを介してMBMS GW21と接続され、SGiインターフェイスを介してP−GW23と接続される(図2参照)。BM−SC22は、TMGI(Temporary Mobile Group Identity)の管理・割当等を行う。
EPC20の外部のネットワーク(すなわち、インターネット)には、GCS AS(Group Communication Service Application Server)31が設けられる。GCS AS31は、グループ通信用のアプリケーションサーバである。GCS AS31は、MB2−U及びMB2−Cインターフェイスを介してBM−SC22と接続され、SGiインターフェイスを介してP−GW23と接続される。GCS AS31は、グループ通信におけるグループの管理及びデータ配信等を行う。
図3は、実施形態に係るUE100(無線端末)の構成を示す図である。図3に示すように、UE100は、受信部110、送信部120、及び制御部130を備える。
受信部110は、制御部130の制御下で各種の受信を行う。受信部110は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部130に出力する。
送信部120は、制御部130の制御下で各種の送信を行う。送信部120は、アンテナ及び送信機を含む。送信機は、制御部130が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部130は、UE100における各種の制御を行う。制御部130は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPU(Central Processing Unit)と、を含む。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサは、後述する各種の処理を実行する。
図4は、実施形態に係るeNB200(基地局)の構成を示す図である。図4に示すように、eNB200は、送信部210、受信部220、制御部230、及びバックホール通信部240を備える。
送信部210は、制御部230の制御下で各種の送信を行う。送信部210は、アンテナ及び送信機を含む。送信機は、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
受信部220は、制御部230の制御下で各種の受信を行う。受信部220は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部230に出力する。
制御部230は、eNB200における各種の制御を行う。制御部230は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPU(Central Processing Unit)と、を含む。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各種の処理を実行する。
バックホール通信部240は、X2インターフェイスを介して隣接eNBと接続され、S1インターフェイスを介してMME/S−GW300と接続される。バックホール通信部240は、X2インターフェイス上で行う通信及びS1インターフェイス上で行う通信等に用いられる。
図5は、LTEシステムにおける無線インターフェイスのプロトコルスタックを示す図である。図5に示すように、無線インターフェイスプロトコルは、OSI参照モデルの第1レイヤ乃至第3レイヤに区分されている。第1レイヤは物理(PHY)レイヤを含む。第2レイヤは、MAC(Medium Access Control)レイヤ、RLC(Radio Link Control)レイヤ、及びPDCP(Packet Data Convergence Protocol)レイヤを含む。第3レイヤは、RRC(Radio Resource Control)レイヤを含む。
物理レイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。UE100の物理レイヤとeNB200の物理レイヤとの間では、物理チャネルを介してデータ及び制御信号が伝送される。
MACレイヤは、データの優先制御、HARQ(Hybrid ARQ)による再送処理等を行う。UE100のMACレイヤとeNB200のMACレイヤとの間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。eNB200のMACレイヤは、スケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式(MCS))、及びUE100への割当リソースブロックを決定する。
RLCレイヤは、MACレイヤ及び物理レイヤの機能を利用してデータを受信側のRLCレイヤに伝送する。UE100のRLCレイヤとeNB200のRLCレイヤとの間では、論理チャネルを介してデータ及び制御信号が伝送される。
PDCPレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
RRCレイヤは、制御信号を取り扱う制御プレーンでのみ定義される。UE100のRRCレイヤとeNB200のRRCレイヤとの間では、各種設定のためのメッセージ(RRCメッセージ)が伝送される。RRCレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。UE100のRRCとeNB200のRRCとの間に接続(RRC接続)がある場合、UE100はRRCコネクティッドモードであり、そうでない場合、UE100はRRCアイドルモードである。
RRCレイヤの上位に位置するNAS(Non−Access Stratum)レイヤは、セッション管理及びモビリティ管理等を行う。
図6は、LTEシステムの下りリンクのチャネルの構成を示す図である。図6Aは、論理チャネル(Downlink Logical Channel)とトランポートチャネル(Downlink Transport Channel)との間のマッピングを示す。
図6Aに示すように、PCCH(Paging Control Channel)は、ページング情報、及びシステム情報変更を通知するための論理チャネルである。PCCHは、トランスポートチャネルであるPCH(Paging Channel)にマッピングされる。
BCCH(Broadcast Control Channel)は、システム情報のための論理チャネルである。BCCHは、トランスポートチャネルであるBCH(Broadcast Control Channel)及びDL−SCH(Downlink Shared Channel)にマッピングされる。
CCCH(Common Control Channel)は、UE100とeNB200との間の送信制御情報のための論理チャネルである。CCCHは、UE100がネットワークとの間でRRC接続を有していない場合に用いられる。CCCHは、DL−SCHにマッピングされる。
DCCH(Dedicated Control Channel)は、UE100とネットワークとの間の個別制御情報を送信するための論理チャネルである。DCCHは、UE100がRRC接続を有する場合に用いられる。DCCHは、DL−SCHにマッピングされる。
DTCH(Dedicated Traffic Channel)は、データ送信のための個別論理チャネルである。DTCHは、DL−SCHにマッピングされる。
SC−MTCH(Single Cell Multicast Traffic Channel)は、SC−PTM伝送のための論理チャネルである。SC−MTCHは、SC−PTM伝送を用いてネットワークからUE100にデータを送信するための1対多チャネル(point−to−multipoint downlink channel)である。
SC−MCCH(Single Cell Multicast Control Channel)は、SC−PTM伝送のための論理チャネルである。SC−MTCHは、1又は複数のSC−MTCHのためのMBMS制御情報をネットワークからUE100に送信するための1対多チャネル(point−to−multipoint downlink channel)である。SC−MCCHは、SC−PTMを用いてMBMSを受信する又は受信に興味を持つUE100に用いられる。また、SC−MCCHは、1つのセルに1つのみ存在する。「MBMSの受信に興味を持つ」とは、例えば、MBMSサービスを未だ受信していないものの、上位レイヤ(例えばアプリケーションレイヤ)からMBMSサービスを受信するよう設定された状態を意味する。
MCCH(Multicast Control Channel)は、MBSFN伝送のための論理チャネルである。MCCHは、ネットワークからUE100へのMTCH用のMBMS制御情報の送信のために用いられる。MCCHは、トランスポートチャネルであるMCH(Multicast Channel)にマッピングされる。
MTCH(Multicast Traffic Channel)は、MBSFN伝送のための論理チャネルである。MTCHは、MCHにマッピングされる。
図6Bは、トランポートチャネル(Downlink Transport Channel)と物理チャネル(Downlink Physical Channel)との間のマッピングを示す。
図6Bに示すように、BCHは、PBCH(Physical Broadcast Channel)にマッピングされる。
MCHは、PMCH(Physical Multicast Channel)にマッピングされる。MCHは、複数のセルによるMBSFN伝送をサポートする。
PCH及びDL−SCHは、PDSCH(Physical Downlink Shared Channel)にマッピングされる。DL−SCHは、HARQ、リンクアダプテーション、及び動的リソース割当をサポートする。
PDCCHは、PDSCH(DL−SCH、PCH)のリソース割り当て情報及びDL−SCHに関するHARQ情報等を運搬する。また、PDCCHは、上りリンクのスケジューリンググラントを運ぶ。
図7は、LTEシステムの無線フレームの構成を示す図である。LTEシステムにおいて、下りリンクにはOFDMA(Orthogonal Frequency Division Multiple Access)、上りリンクにはSC−FDMA(Single Carrier Frequency Division Multiple Access)がそれぞれ適用される。
図7に示すように、無線フレームは、時間方向に並ぶ10個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ2個のスロットで構成される。各サブフレームの長さは1msであり、各スロットの長さは0.5msである。各サブフレームは、周波数方向に複数個のリソースブロック(RB)を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。1つのシンボル及び1つのサブキャリアにより1つのリソースエレメント(RE)が構成される。また、UE100に割り当てられる無線リソース(時間・周波数リソース)のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム(又はスロット)により特定できる。
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御信号を伝送するためのPDCCHとして用いられる領域である。各サブフレームの残りの部分は、主に下りリンクデータを伝送するためのPDSCHとして使用できる領域である。また、下りリンクにおいて、MBSFN伝送向けのサブフレームであるMBSFNサブフレームが設定され得る。
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御信号を伝送するためのPUCCHとして用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するためのPUSCHとして使用できる領域である。
(特定状態)
特定状態について説明する。特定状態は、UE100用のS1接続が維持されつつUE100用のシグナリングが抑制される状態である。S1接続は、S1ベアラと称されてもよい。S1接続は、S1インターフェイス上でeNB200とEPC20との間に確立される接続である。S1インターフェイスは、ユーザプレーン用のS1−Uインターフェイスと制御プレーン用のS1−MMEインターフェイスとを含む。S1接続は、S1−Uインターフェイス上でeNB200とS−GW300Uとの間に確立されるS1−U接続と、S1−Cインターフェイス上でeNB200とMME300Cとの間に確立されるS1−MME接続と、を含んでもよい。
特定状態は、RRCコネクティッドモードの一状態又はRRCアイドルモードの一状態であってもよい。或いは、特定状態は、RRCアイドルモード及びRRCアイドルモードとは異なるRRC状態であってもよい。特定状態によれば、一般的なRRCコネクティッドモードに比べてシグナリングが削減される。また、特定状態によれば、一般的なRRCアイドルモードに比べてUE100が迅速にデータ通信を開始することができる。以下において、特定状態を「Light Connected状態(Light Connected substate)」と称する。
図8は、Light Connected状態(特定状態)への遷移に係る動作を示す図である。図8の初期状態において、UE100はRRCコネクティッドモードであり、UE100とeNB200との間にRRC接続(RRC Connection)が確立されている。また、eNB200とMME300Cとの間にS1−MME接続(S1−MME Connection)が確立されている。eNB200とS−GW300Uとの間にS1−U接続(S1−U Connection)が確立されている。UE100は、eNB200とのデータ通信を行う。
図8に示すように、ステップS1において、eNB200は、Light Connected状態への遷移を指示する遷移指示(Request to Light Conn.)をUE100に送信する。
ステップS2において、UE100は、遷移指示の受信に応じて、肯定応答(Ack)メッセージをeNB200に送信する。但し、ステップS2は必須ではなく、省略してもよい。
ステップS3において、UE100及びeNB200は、RRC接続を維持又は解放する。
ステップS4において、eNB200及びMME300Cは、S1−MME接続を維持する。ステップS5において、eNB200及びS−GW300Uは、S1−U接続を維持する。ステップS6において、UE100は、Light Connected状態に遷移し、eNB200とのデータ通信を中断する。
eNB200は、Light Connected状態に遷移したUE100のコンテキスト情報(UEコンテキスト)を破棄せずに維持する。UEコンテキストは、UE100に対する各種の設定及び能力等に関する情報を含む。各種の設定は、AS(Access Stratum)の設定を含む。
Light Connected状態のUE100は、維持されているS1接続及びUEコンテキストを活用して、少ないシグナリングでeNB200とのデータ通信を再開することができる。
第1のeNB200のセルにおいてLight Connected状態に遷移したUE100は、第1のeNB200のセルから第2のeNB200のセルに移動してもよい。第2のeNB200のセルにおいてUE100がデータ通信を再開する場合、第2のeNB200は、UE100のUEコンテキストを第1のeNB200からX2インターフェイス上で取得し、取得したUEコンテキストをUE100とのデータ通信に利用してもよい。
Light Connected状態のUE100には、RANベースページングが適用されてもよい。RANベースページングは、E−UTRAN10(eNB200)によりページングが制御される所定ページングエリア単位でページングを行う。所定ページングエリアは、トラッキングエリアよりも狭いエリアである。所定ページングエリアを導入することにより、1のUE100に対してページングを行うセルの数を削減することができるため、シグナリングを削減することができる。以下において、このような所定ページングエリアを「RANページングエリア」と称する。
一例として、RANページングエリアは、Light Connected状態のUE100のS1接続を維持する特定のeNB200のセルと当該特定のeNB200の周辺のeNB200のセルとにより構成される。周辺のeNB200は、特定のeNB200とのX2インターフェイスを有するeNB200であってもよい。特定のeNB200は、Light Connected状態のUE100宛てのデータ又はNASシグナリングをMME/S−GW300から受信すると、RANベースページングを行うと判断し、周辺のeNB200と共にUE100のページングを行う。当該ページングは、RRCページングメッセージを送信することにより行われてもよいし、UE100宛てのデータをページングメッセージとして送信することにより行われてもよい。
(第1実施形態)
第1実施形態について説明する。第1実施形態において、RRCアイドルモードのUE100がネットワークからMBMSサービスを受信するシナリオを想定する。或いは、Light Connected状態のUE100がネットワークからMBMSサービスを受信するシナリオを想定してもよい。
一般的なLTEシステムにおいて、ネットワークは、MBMSカウンティングプロシージャを用いて、特定のMBMSサービスを受信している又は受信に興味を持つRRCコネクティッドモードのUE100の数をカウントすることができる。具体的には、eNB200は、RRCコネクティッドモードのUE100に対してカウンティング要求を送信する。カウンティング要求は、カウント対象のMBMSサービスのサービス識別子(TMGI)のリストを含む。カウンティング要求を受信したUE100は、カウント対象のMBMSサービスを受信している又は受信に興味を持つか否かを判断する。UE100は、UE100が当該MBMSサービスを受信している又は受信に興味を持つことに応じて、カウンティング応答をeNB200に送信する。カウンティング応答は、カウント対象のMBMSサービスのうちUE100が受信している又は受信に興味を持つMBMSサービスを示す情報を含む。eNB200は、カウント対象のMBMSサービスを受信している又は受信に興味を持つUE100の数をカウントし、カウント結果をMCE11に報告する。
一般的なカウンティング応答は、通常の上りリンク送信プロシージャを用いてUE100からeNB200に送信される。具体的には、UE100は、スケジューリング要求(SR)及び/又はバッファステータス報告(BSR)をeNB200に送信する。eNB200は、SR及び/又はBSRに基づいて、UE100に上りリンク無線リソース(すなわち、PUSCHリソース)をスケジューリングし、スケジューリング情報をUE100に送信する。UE100は、スケジューリングされた上りリンク無線リソースを用いてカウンティング応答をeNB200に送信する。
このような一般的なMBMSカウンティングプロシージャは、RRCアイドルモード又はLight Connected状態のUE100には適用することができない。よって、ネットワークは、RRCアイドルモード又はLight Connected状態のUE100におけるMBMSサービスの受信状況を把握することができない。また、一般的なMBMSカウンティングプロシージャにおいて、カウンティング応答の送受信は、複数のUE個別シグナリング(専用シグナリング)を伴うため、シグナリングの増大を引き起こす懸念がある。
以下において、このような問題を解決することができる新規なMBMSカウンティングプロシージャについて説明する。
図9は、第1実施形態に係る動作例を示す図である。図9の初期状態において、UE100はRRCアイドルモード又はLight Connected状態である。図9においてUE100を1つのみ示しているが、実際にはeNB200のカバレッジエリア内に複数のUE100が在圏していてもよい。
図9に示すように、ステップS11において、eNB200(送信部210)は、カウント対象のMBMSサービス(特定のMBMSサービス)を受信している又は受信に興味を持つ複数のUE100にカウンティング応答の送信を要求するカウンティング要求を送信する。カウンティング要求は、ブロードキャスト又はマルチキャストで送信される。例えば、eNB200(送信部210)は、システム情報ブロック(SIB)、SC−MCCH、又はMCCHを用いてカウンティング要求を送信する。カウンティング要求は、カウント対象のMBMSサービスのサービス識別子(TMGI)のリストを含む。カウンティング要求は、RRCアイドルモード又はLight Connected状態のUE100を対象とすることを示す情報を含んでもよい。
ステップS12において、eNB200(送信部210)は、複数のUE100がカウンティング応答の送信に共通に用いるべき共通リソースプールを示す共通リソース設定を送信する。共通リソース設定は、ブロードキャスト又はマルチキャストで送信される。例えば、eNB200(送信部210)は、SIB、SC−MCCH、又はMCCHを用いて共通リソース設定を送信する。共通リソース設定は、共通リソースプールを示す時間リソースパラメータ及び周波数リソースパラメータを含む。共通リソース設定は、カウンティング応答の送信電力を制御するための電力制御パラメータをさらに含んでもよい。時間リソースパラメータは、システムフレーム番号(SFN)を示す情報、サブフレームを示す情報(ビットマップ)等を含んでもよい。周波数リソースパラメータは、リソースブロックの始点又は終点を示す情報、連続するリソースブロックの範囲(リソースブロック数)を示す情報等を含んでもよい。共通リソース設定は、共通リソースプールが提供される期間(又は、開始時間/終了時間)を含んでもよい。当該期間は、秒として定義されてもよく、フレーム番号(SFN、サブフレーム等)で定義されてもよい。当該期間は、予め決められた値(例えば10サブフレーム期間等)であってもよい。当該期間が存在する場合、UE100は、当該期間内においてカウンティング応答を送信する。言い換えると、UE100は、当該期間の経過後はカウンティング応答を送信しない。
ステップS12は、ステップS11の前に行われてもよいし、ステップS13の後に行われてもよい。或いは、ステップS12は、ステップS11と同時に行われてもよい。この場合、カウンティング要求及び共通リソース設定は、1つのメッセージに含まれてもよい。
UE100(受信部110)は、カウンティング要求及び共通リソース設定を受信する。
ステップS13において、UE100(制御部130)は、カウンティング要求の受信に応じて、カウント対象のMBMSサービスをUE100が受信している又は受信に興味を持つか否かを判断する。ここでは、カウント対象のMBMSサービスをUE100が受信している又は受信に興味を持つと仮定して説明を進める。
ステップS14において、UE100(制御部130)は、カウント対象のMBMSサービスを受信している又は受信に興味を持つことに応じて、共通リソースプールに含まれる一部の無線リソース(時間・周波数リソース)をランダムに選択する。
ステップS15において、UE100(送信部120)は、選択された一部の無線リソース(すなわち、PUSCHリソース)を用いて、カウンティング応答をeNB200に送信する。カウンティング応答は、カウント対象のMBMSサービスのうちUE100が受信している又は受信に興味を持つMBMSサービスを示す情報を含む。ここで、UE100は、RRCアイドルモード又はLight Connected状態を維持しつつ、カウンティング応答をeNB200に送信可能である。
eNB200(受信部220)は、共通リソースプールに含まれる無線リソースを用いて複数のUE100が送信するカウンティング応答を受信する。複数のUE100間で無線リソースの衝突が発生した場合、eNB200(受信部220)は、衝突した無線リソースを用いて送信されたカウンティング応答の復号に失敗する。但し、eNB200は、カウンティング応答の再送を要求しないことに留意すべきである。これに対し、無線リソースの衝突が発生しない場合、eNB200(受信部220)は、衝突が発生した無線リソースを用いて送信されたカウンティング応答の復号に成功する。
eNB200(制御部230)は、カウンティング応答に基づいて、カウント対象のMBMSサービスを受信している又は受信に興味を持つUE100の数をカウントし、カウント結果をMCE11に報告する。MCE11(又はeNB200)は、カウント結果に基づいて、MBMSサービス(TMGI)ごとに、ユニキャスト伝送、MBSFN伝送、及びSC−PTM伝送のうち何れを適用するか判断してもよい。一例として、MCE11(又はeNB200)は、特定のMBMSサービス(TMGI)を受信している又は受信に興味を持つUE100の数が判定閾値を上回る場合、MBSFN伝送又はSC−PTM伝送を用いて当該特定のMBMSサービスを提供すると判断する。MCE11(又はeNB200)は、特定のMBMSサービスを受信している又は受信に興味を持つUE100があるセルに偏っていれば、当該セルにおいて特定のMBMSサービスをSC−PTM伝送で送信すると判断してもよい。特定のMBMSサービスを受信している又は受信に興味を持つUE100が非常に多くのセルに点在していれば、MCE11(又はeNB200)は、これらのセルを含む1又は複数のMBSFNエリアにおいて特定のMBMSサービスをSC−PTM伝送で送信すると判断してもよい。これらの状態の中間の状態、例えば、特定のMBMSサービスを受信している又は受信に興味を持つUE100が複数のセル等にまたがって存在する場合、MCE11(又はeNB200)は、当該複数のセルが1つのeNBに収容されていればSC−PTMを選択し、当該複数のセルが複数eNBにまたがっていればMBSFNを選択してもよい。
第1実施形態によれば、ネットワークは、RRCアイドルモード又はLight Connected状態のUE100におけるMBMSサービスの受信状況を大まかに把握することができる。第1実施形態によれば、一般的なMBMSカウンティングプロシージャに比べて、カウンティング応答の送受信に伴うシグナリングを削減することができる。
図10は、第1実施形態に係る共通リソースプールを示す図である。図10において、時間方向の1つの区画は、1つの無線フレーム(又は1つのサブフレーム)を示す。
図10に示すように、共通リソースプール(A set of resources)は、eNB200の上りリンク無線リソースの一部である。一例として、共通リソースプールは、複数のリソースブロック(PRB:Physical Resource Block)からなる。UE#1乃至#6は、eNB200から受信するカウンティング要求及び共通リソース設定に基づいて、共通リソースプールに含まれるリソースブロックを用いてカウンティング応答をeNB200に送信する。リソースブロックは、ランダムに選択される。
図10の例において、UE#1がリソースブロックAを選択し、UE#2がリソースブロックBを選択し、UE#3がリソースブロックCを選択し、UE#4乃至#6がリソースブロックDを選択している。すなわち、UE#4乃至#6間でリソースブロックの衝突が発生している。eNB200は、衝突が発生したリソースブロックDを用いて送信されたカウンティング応答の復号に失敗する。これに対し、リソースブロックA、B、Cについては衝突が発生していないため、eNB200は、UE#1乃至#3のそれぞれのカウンティング応答の復号に成功する。
カウンティング応答の送信に用いるリソースブロックの数は、1つである場合に限らず、2以上の数であってもよい。カウンティング応答の送信に用いるリソースブロックの数は、共通リソース設定のパラメータの1つとしてeNB200が設定してもよい。
eNB200又はMCE11は、共通リソースプールのリソース量(すなわち、共通リソースプールのリソースブロック数)を決定してもよい。MCE11が共通リソースプールのリソース量を決定する場合、MCE11は、決定した共通リソースプールをeNB200に通知する。eNB200は、決定された共通リソースプールを示す共通リソース設定を送信する。
eNB200又はMCE11は、MBSFN又はSC−PTMを用いるか否かを判定するための判定閾値に比例して共通リソースプールのリソース量を決定してもよい。一例として、あるMBMSサービスに興味のあるUEの数が多数になった場合のみ、当該MBMSサービスのSC−PTM伝送を行うという前提下では、共通リソースプールのリソース量を多くする。これにより、共通リソースプール内での衝突の回避に寄与することができる。
eNB200又はMCE11は、RRCアイドルモードのUEの数及び/又はLight Connected状態のUEの数が既知である場合には、これらのUEの数に比例して共通リソースプールのリソース量を決定してもよい。一例として、RRCアイドルモードのUEの数及び/又はLight Connected状態のUEの数が多い場合に、共通リソースプールのリソース量を多くする。
(第2実施形態)
第2実施形態について、第1実施形態との相違点を主として説明する。第2実施形態は、第1実施形態に係る動作を前提として、共通リソースプール内で衝突が発生する可能性を低下させることを可能とする実施形態である。
一例として、UE100(制御部130)は、自身が発生させた乱数又は自身の固有識別子を取得する。固有識別子は、IMSI(International Mobile Subscriber Identity)であってもよい。固有識別子は、S−TMSI(SAE−Temporary Mobile Subscriber Identity)であってもよいし、電話番号であってもよい。固有識別子は、eNB200がUE100に割り当てた識別子であってもよい。このような識別子は、復旧用識別子(Resume ID)であってもよいし、Light Connectionに遷移する時にeNBから与えられた識別子(例えばセルID+C−RNTI等)であってもよい。UE100(制御部130)は、乱数又は固有識別子に基づいて、カウンティング応答の送信が許可されるか否かを判断する。
他の例として、UE100(制御部130)は、乱数又は固有識別子に基づいて、カウンティング応答の送信タイミングを決定する。送信タイミングは、無線フレームを識別するシステムフレーム番号(SFN)により定義されてもよい。送信タイミングは、サブフレームフレームを識別するサブフレーム番号により定義されてもよい。
UE100(受信部110)は、ネットワーク(eNB200)から送信された所定値を受信してもよい。所定値は、乱数又は固有識別子が所定の条件を満たしたか否かを判定するための閾値又は変数であってもよい。所定値は、専用シグナリング、マルチキャストシグナリング(MCCH/SC−MCCH)、又はブロードキャストシグナリング(SIB)によりeNB200から送信されてもよい。UE100(制御部130)は、乱数又は固有識別子と、所定値とに基づいて、カウンティング応答の送信が許可されるか否かを判断してもよい。UE100(制御部130)は、乱数又は固有識別子と、所定値とに基づいて、カウンティング応答の送信タイミングを判断してもよい。
図11は、第2実施形態に係る動作例を示す図である。ここでは、第1実施形態との相違点を主として説明し、重複する説明を省略する。図11において、ステップS13、S21、S22、S14はこの順に行われなくてもよく、ステップS13、S21、S22、S14の順番を変更してもよい。ステップS21及びステップS22のうち一方のみを行ってもよい。
図11に示すように、ステップS11乃至S13は第1実施形態と同様である。
ステップS21において、UE100(制御部130)は、自身のカウンティング応答の送信が許可されているか否かを判断する。
一例として、UE100(制御部130)は、乱数(0〜1の範囲)を発生させ、eNB200から通知された閾値(0〜1の範囲)と乱数とを比較する。UE100(制御部130)は、乱数が閾値条件を満たした場合に、カウンティング応答の送信が許可されていると判断し、カウンティング応答の送信機能を有効化する。「乱数が閾値条件を満たす」とは、乱数が閾値条件を超えたことであってもよいし、乱数が閾値条件を下回ったことであってもよい。UE100(制御部130)は、乱数が閾値条件を満たさない場合に、カウンティング応答の送信が許可されていないと判断し、カウンティング応答の送信機能を無効化する。
他の例として、UE100(制御部130)は、自身のIMSIを取得し、eNB200から通知された変数(”N”、”T”)により定義される条件をIMSIが満たすか否かを判断する。このような条件として、「(IMSI) mod (N) = (T)」という条件式を用いてもよい。当該条件式において、IMSIそのものを用いることに代えて、IMSIに基づく値(例えば、IMSI mod 1024)を用いてもよい。当該条件式において、等式を用いることに代えて、不等式(>、<、≦、又は≧)を用いてもよい。UE100(制御部130)は、IMSIが条件を満たした場合に、カウンティング応答の送信が許可されていると判断し、カウンティング応答の送信機能を有効化する。UE100(制御部130)は、IMSIが条件を満たさない場合に、カウンティング応答の送信が許可されていないと判断し、カウンティング応答の送信機能を無効化する。
図12は、カウンティング応答の送信可否判断を示す図である。UE#1乃至#6のそれぞれは、自身のカウンティング応答の送信が許可されているか否かを判断する。図12の例において、UE#1、#3、及び#4は条件を満たすが、UE#2、#5、及び#6は条件を満たさない。この場合、UE#1、#3、及び#4は、共通リソースプール内のリソースブロックを用いてカウンティング応答を送信する。UE#2、#5、及び#6は、カウンティング応答の送信が禁止される。
ステップS22において、UE100(制御部130)は、自身のカウンティング応答の送信タイミングを決定する。ステップS22は、ステップS21でカウンティング応答の送信が許可された場合に限り行われてもよい。
一例として、UE100(制御部130)は、自身のIMSIを取得し、eNB200から通知された変数(”N”)及びIMSIにより定義される条件を満たすSFNを決定する。このような条件として、「(IMSI) mod (N) = (SFN) mod (N)」という条件式を用いてもよい。当該条件式において、IMSIそのものを用いることに代えて、IMSIに基づく値(例えば、IMSI mod 1024)を用いてもよい。UE100(制御部130)は、条件を満たしたSFNにおいてカウンティング応答を送信することを決定する。UE100(制御部130)は、条件を満たさないSFNにおいてカウンティング応答を送信しないことを決定する。他の例として、IMSIに代えて乱数を用いてもよい。
図13は、カウンティング応答の送信タイミングを示す図である。UE#1乃至#6のそれぞれは、UE#1乃至#6のそれぞれのカウンティング応答の送信タイミングをIMSI(又は乱数)に基づいて決定する。図13の例において、UE#1及び#2はSFN#1をカウンティング応答の送信タイミングとして決定する。UE#3及び#4はSFN#2をカウンティング応答の送信タイミングとして決定する。UE#5及び#6はSFN#3をカウンティング応答の送信タイミングとして決定している。このように、複数のUEのカウンティング応答の送信タイミングを時間方向に分散させることができる。
ステップS21及びS22を併用してもよい。この場合、UE100(制御部130)は、ステップS22で決定した送信タイミング(SFN)ごとに、ステップS21の送信可否判断を行ってもよい。一例として、UE100(制御部130)は、あるSFNにおいてカウンティング応答を送信できなかった場合であって、カウンティング対象のMBMSサービスについてなお興味を有している場合に、次の送信機会(次の送信タイミング)でカウンティング応答の送信を再試行してもよい。但し、一旦カウンティング応答を送信した後は、そのような再試行を行ってはならない。
ステップS14乃至S15は第1実施形態と同様である。
(第3実施形態)
第3実施形態について、第1及び第2実施形態との相違点を主として説明する。第3実施形態は、第1実施形態に係る動作を前提として、複数の共通リソースプールのそれぞれに特定のMBMSサービスを対応付ける実施形態である。
第3実施形態において、カウンティング要求は、複数のMBMSサービスのそれぞれのサービス識別子(TMGI)を含む。共通リソース設定は、複数のMBMSサービスのそれぞれに対応する共通リソースプールからなる複数の共通リソースプールを示す。UE100(制御部130)は、自身が受信している又は受信に興味を持つMBMSサービスのサービス識別子に対応する共通リソースプールを複数の共通リソースプールの中から選択する。UE100(送信部120)は、選択した共通リソースプールに含まれる無線リソースを用いてカウンティング応答をネットワーク(eNB200)に送信する。
MBMSサービスと共通リソースプールとを対応付けることより、共通リソースプール内で衝突が発生する可能性を低下させることができる。このような対応関係を導入することにより、カウンティング応答の情報量を削減することができる。一例として、カウンティング応答は、1ビットのフラグにより構成してもよい。eNB200は、共通リソースプールごとにカウンティング応答をカウントすることにより、各MBMSサービスを受信している又は受信に興味を持つUEの数を把握する。
一例として、UE100(送信部120)は、カウンティング応答として、複数のUEがカウンティング応答の送信に共通に用いる共通信号系列を送信する。共通信号系列は、UE100に事前設定されていてもよい。共通信号系列は、eNB200がUE100に設定してもよい。共通信号系列は、スケジューリング要求(SR)のような信号系列である。eNB200は、共通リソースプールごとに、カウンティング応答(共通信号系列)の受信電力を測定する。eNB200は、各共通リソースプールの受信電力に基づいて、当該共通リソースプールに対応するMBMSサービスを受信している又は受信に興味を持つUEの数を大まかに把握することができる。eNB200は、ターゲット電力と実際の受信電力との差分より、当該MBMSサービスを受信している又は受信に興味を持つUEの数を大まかに把握してもよい。
他の例として、UE100(制御部130)は、自身で発生させた乱数又は自身の固有識別子を取得し、乱数又は識別子を用いて信号系列を選択する。UE100(送信部120)は、カウンティング応答として、乱数又は識別子を用いて選択された信号系列(個別信号系列)を送信する。eNB200は、共通リソースプールごとに、カウンティング応答(個別信号系列)の数を判定することにより、当該共通リソースプールに対応するMBMSサービスを受信している又は受信に興味を持つUEの数を把握することができる。
複数の共通リソースプールのそれぞれは、物理ランダムアクセスチャネル(PRACH)リソースとして設定されてもよい。この場合、ランダムアクセスプリアンブルをカウンティング応答として用いてもよい。共通リソースプールとして用いられるPRACHリソースは、リソース位置が定められた通常のPRACHリソースとは異なるPRACHリソースとして設定される。
図14は、第3実施形態に係る動作例を示す図である。ここでは、第1実施形態との相違点を主として説明し、重複する説明を省略する。図14において、ステップS13、S31、S32、S14はこの順に行われなくてもよく、ステップS13、S31、S32、S14の順番を変更してもよい。上述した共通信号系列を用いる場合、ステップS32を省略してもよい。上述した個別信号系列を用いる場合、ステップS14を省略してもよい。
図14に示すように、ステップS11乃至S13は第1実施形態と同様である。但し、ステップS11において、eNB200(送信部210)は、複数のMBMSサービスのそれぞれのサービス識別子(TMGI)を含むカウンティング要求を送信する。ステップS12において、eNB200(送信部210)は、当該複数のMBMSサービスに対応する複数の共通リソースプールを示す共通リソース設定を送信する。ステップS11又はS12(又は他のシグナリング)において、eNB200(送信部210)は、サービス識別子(TMGI)と共通リソースプールとの対応関係を示す情報(すなわち、マッピング情報)を送信してもよい。或いは、カウンティング要求中のサービス識別子の並び順と、共通リソース設定中の共通リソースプールの並び順とを合わせることにより、対応関係を暗示的に示してもよい。サービス識別子と共通リソースプールとの対応関係は、1対1の関係である。但し、1対多の関係としてもよい。
上述した共通信号系列を用いる場合、eNB200は、共通信号系列を示すパラメータをUE100に設定してもよい。eNB200は、共通信号系列の開ループ送信電力制御等に用いる送信電力パラメータ(例えば、eNB200におけるターゲット受信電力)をUE100に設定してもよい。上述した個別信号系列を用いる場合、eNB200は、個別信号系列及び/又はその送信電力を決定するためのパラメータをUE100に設定してもよい。これらのパラメータは、専用シグナリング、マルチキャストシグナリング(MCCH/SC−MCCH)、又はブロードキャストシグナリング(SIB)によりeNB200から送信されてもよい。
ステップS31において、UE100(制御部130)は、UE100が受信している又は受信に興味を持つMBMSサービスのサービス識別子(TMGI)に対応する共通リソースプールを複数の共通リソースプールの中から選択する。カウンティング対象のMBMSサービスのうち複数のMBMSサービスをUE100が受信している又は受信に興味を持つ場合、UE100(制御部130)は、当該複数のMBMSサービスに対応する複数の共通リソースプールを選択してもよい。
ステップS32において、UE100(制御部130)は、UE100で発生させた乱数又はUE100の固有識別子を用いて個別信号系列(例えば、プリアンブル系列)を選択する。プリアンブル系列は、ベース系列とサイクリックシフト量とにより決定される。一例として、UE100(制御部130)は、「(IMSI) mod (max# of “v”)」によりサイクリックシフト量を決定する。(max# of “v”)は、サイクリックシフト量(サイクリックシフトパターン)の最大数である。UE100(制御部130)は、「(IMSI) mod (max# of Index)」により「PRACH Config Index」を決定してもよい。(max# of Index)は、「PRACH Config Index」の最大数(例えば、64)である。「PRACH Config Index」は、プリアンブル送信のタイミング(SFN)及びプリアンブルフォーマット(信号の長さ)に関するパラメータである。全ての「PRACH Config Index」を候補とするのではなく、一部の「PRACH Config Index」に候補を限定してもよい。一例として、「PRACH Config Index」は、”Any”(TS 36.211のTable 5.7.1−2を参照)だけに限定されてもよい。”Any”は、どのSFNでも送信が可能な設定である。この場合、(max# of Index)は43等に限定される。また、この場合、決定されたPRACH Config Indexはシフトする(例えば、Indexが0の場合、TS 36.211のTable 5.7.1−2のIndexは3を示す)。このように制御する事で、信号受信に割り当てたリソースを有効活用することができる。より短時間でカウントを行うことができる。
ステップS14乃至S15は第1実施形態と同様である。但し、ステップS15において、UE100(送信部120)は、ステップS31で選択した共通リソースプールを用いて、共通信号系列又は個別信号系列をカウンティング応答としてネットワーク(eNB200)に送信する。
図15は、サービス識別子(TMGI)と共通リソースプールとの対応関係を示す図である。図15に示すように、TMGI#1乃至#4に対応する4つの共通リソースプールが設定されている。UE#1は、TMGI#1、#2、及び#3の各MBMSサービスを受信している又は受信に興味を持っており、TMGI#1、#2、及び#3に対応する各共通リソースプールにおいてカウンティング応答を送信する。他のUEも同様に、他のUEが受信している又は受信に興味を持つMBMSサービスに対応する共通リソースプールにおいてカウンティング応答を送信する。なお、各共通リソースプールのリソース量は、上述した方法を用いて個別に設定されてもよい。
(第3実施形態の変更例)
上述した第1乃至第3実施形態において、新たなカテゴリのUE100が存在するシナリオを考慮していなかった。新たなカテゴリのUE100は、システム送受信帯域の一部のみに送受信帯域幅が制限されるUE100である。本変更例では、このようなUE100に対して、MBMSを用いたマルチキャスト/ブロードキャストによりファームウェア等の一括配信を行うシナリオを想定する。
新たなUEカテゴリは、例えば、カテゴリM1及びNB(Narrow Band)−IoTカテゴリと称される。ここで、カテゴリM1は、eMTC(enhanced Machine Type Communications)UEである。また、NB−IoT UEは、カテゴリNB1である。カテゴリM1は、UE100の送受信帯域幅を1.08MHz(すなわち、6リソースブロックの帯域幅)に制限するとともに、繰り返し送信等を用いたカバレッジ強化(CE:Enhanced Coverage)技術をサポートする。NB−IoTカテゴリは、UE100の送受信帯域幅を180kHz(すなわち、1リソースブロックの帯域幅)にさらに制限するとともに、カバレッジ強化技術をサポートする。繰り返し送信は、複数のサブフレームを用いて同一のデータを繰り返し送信する技術である。一例として、LTEシステムのシステム帯域幅は10MHzであり、そのうちの送受信帯域幅は9MHz(すなわち、50リソースブロックの帯域幅)である。一方、カテゴリM1のUE100は、6リソースブロックよりも広い帯域幅で送信される下りリンク無線信号を受信することができないため、通常のPDCCHを受信することができない。このため、MTC向けのPDCCHであるMPDCCH(MTC−PDCCH)が導入される。同様な理由で、NB−IoT向けのPDCCHであるNPDCCH(NB−PDCCH)が導入される。
以下において、UE100に必要とされるカバレッジ強化の度合いを「CEレベル」と称する。「CEレベル」は、少なくとも繰り返し送信における送信回数(すなわち、Repetition回数)と関連する。
本変更例において、複数の共通リソースプールのそれぞれにCEレベルを対応付ける。eNB200は、専用シグナリング、マルチキャストシグナリング(MCCH/SC−MCCH)、又はブロードキャストシグナリング(SIB)により、共通リソースプールとCEレベルとの対応関係(マッピング情報)をUE100に設定してもよい。
複数の共通リソースプールのそれぞれには、サービス識別子(TMGI)とCEレベルとが対応付けられていてもよい。一例として、TMGI#1且つCEレベル#1に対応する共通リソースプール#1と、TMGI#1且つCEレベル#2に対応する共通リソースプール#2と、・・・を設定してもよい。eNB200は、カウンティング要求を行う際に、カウンティング対象のTMGI及びそのTMGIに対応するCEレベル毎のプール(共通リソース設定)をUE100に通知してもよい。或いは、eNB200は、SC−MCCH(もしくはSIB20)で、TMGI毎の設定情報としてCEレベル毎のプール(共通リソース設定)をUE100に通知してもよい。
UE100は、自身のCEレベルを取得する。CEレベルは、UE100に事前設定されていてもよい。或いは、CEレベルは、UE100の状況に応じて可変であってもよい。一例として、UE100は、ネットワークからの受信電力(RSRP:Reference Signal Received Power)と閾値との比較結果に応じて自身のCEレベルを決定する。閾値(のリスト)は、ネットワークからUE100に通知されてもよい。各閾値は、CEレベルと対応付けられている。
UE100は、複数の共通リソースプールのうち、自身のCEレベルに対応する共通リソースプールを選択する。UE100は、自身が受信している又は受信に興味を持つMBMSサービスのサービス識別子(TMGI)に対応する複数の共通リソースプールを選択し、当該複数の共通リソースプールの中から自身のCEレベルに対応する共通リソースプールをさらに選択してもよい。所定のCEレベル(例えば、カバレッジ強化の必要が無いことを示すレベル)を有するUE100、若しくは通常のカバレッジエリアに在圏するUE100は、カウンティング応答を送信しなくてもよい。
eNB200は、共通リソースプールごとに、カウンティング応答の数をカウントする、又はカウンティング応答の受信電力を測定する。これにより、eNB200(又はMCE11)は、MBMSサービスごとに、且つCEレベルごとに、UE100の数を推定してもよい。eNB200(又はMCE11)は、推定結果に基づいて、MBMSサービスのRepetition回数を決定してもよい。一例として、eNB200(又はMCE11)は、あるMBMSサービスを受信している又は受信に興味を持つ複数のUE100についてCEレベルの分布から、最もUE100の数が多いCEレベル(或いは、UE100の数が閾値を超えるCEレベル)を当該MBMSサービスのCEレベルとして決定し、決定したCEレベルに対応するRepetition回数等で当該MBMSサービスをSC−PTMで送信する。eNB200(又はMCE11)は、あるMBMSサービスを受信している又は受信に興味を持つ複数のUE100について、カウンティング応答が得られた最高のCEレベル(例えば、Repetition回数が最も多いCEレベル)を当該MBMSサービスのCEレベルとして決定してもよい。
(第4実施形態)
第4実施形態について、第1乃至第3実施形態との相違点を主として説明する。第4実施形態は、MBMSサービスを受信中のUE100の移動を考慮した実施形態である。
一例として、SC−PTMによりMBMSサービスを受信中のUE100が別のセルに移動した時に、移動先セルでSC−PTMが提供されていないことがあり得る。この場合、UE100は、MBMSサービスを継続的に受信するためには、RRCコネクティッドモードに遷移する必要があり得る。
上述したように、UE100(送信部120)は、自身が特定状態(RRCアイドルモード又はLight Connected状態)にある場合において、共通リソースプールの少なくとも一部を用いてカウンティング応答をネットワークに送信する。第4実施形態において、UE100(送信部120)は、自身が特定状態から復旧するための要求メッセージをネットワークに送信する。当該要求メッセージは、UE100がMBMSサービスを受信している又は受信に興味を持つことを示す情報を含む。当該要求メッセージは、RRC接続の確立を要求する「RRC Connection Requestメッセージ」、RRC接続の復旧を要求する「RRC Connection Resume Requestメッセージ」、又は「Light Connection用のActivation Requestメッセージ」の何れかである。
要求メッセージは、その理由を示すCauseフィールドを有する。UE100は、MBMSサービスを受信している又は受信に興味を持つことを示す情報をCauseフィールドに含める。一般的に、Causeフィールドには、emergency、highPriorityAccess、mt−Access、mo−Signalling、mo−Data、delayTolerantAccess、mo−VoiceCallの何れかが設定される。eNB200は、Causeフィールドの内容に基づいて、要求メッセージを処理する優先度を判断する。
要求メッセージを受信したeNB200は、MBMSサービスを受信している又は受信に興味を持つことを示す情報が当該要求メッセージに含まれていることに応じて、当該要求メッセージを優先的に処理する。言い換えると、eNB200は、MBMSサービスを受信している又は受信に興味を持つUE100を優先的にRRCコネクティッドモードに遷移させるよう制御する。この場合の優先度は、例えば、mo dataとhigh priority accessとの中間程度に設定することができる。
(その他の実施形態)
第3実施形態の変更例において、CEレベルがUE100の状況に応じて可変である一例を説明した。UE100は、自身のCEレベルが変化した又はマルチキャスト受信(MBMS受信)に失敗したことに応じて、eNB200にその旨を通知してもよい。UE100は、自身のCEレベルが変化した又はマルチキャスト受信(MBMS受信)に失敗し、且つ、依然として当該マルチキャスト受信に興味がある、及び/又は当該MBMSサービスが進行中である場合に、当該通知を行ってもよい。eNB200は、当該通知により、当該MBMSサービスのRepetition回数等を変更してもよい。
UE100は、自身のCEレベルに基づいて、eNB200に対するMBMS興味通知の送信を制御してもよい。MBMS興味通知(MBMS interest indication)は、UE100がMBMSサービスを受信している又は受信に興味を持つことを示すRRCメッセージである。MBMS興味通知には、UE100がMBMSサービスを受信している又は受信に興味を持つMBMSサービスの周波数、当該MBMSサービスの受信をユニキャスト受信よりも優先するか否かを示す情報、当該MBMSサービスのサービス識別子(TMGI)のリスト、のうち少なくとも1つを含めることができる。UE100は、自身のCEレベルをMBMS興味通知に含めてもよい。UE100は、カバレッジ強化(CE)が必要であると判断した場合に限り、MBMS興味通知をネットワークに送信してもよい。eNB200は、このような特殊なMBMS興味通知の送信をUE100に要求(又は許可)してもよい。eNB200は、CEレベルをMBMS興味通知に含めるべきか否かを示す情報をUE100に送信してもよい。これらのeNB200のシグナリングは、専用シグナリング、マルチキャストシグナリング(MCCH/SC−MCCH)、又はブロードキャストシグナリング(SIB)であってもよい。UE100は、eNB200からのシグナリングに従ってMBMS興味通知をeNB200に送信する。
eNB200が行うと説明した処理の少なくとも一部をMCE11及び/又はMME300が行ってもよい。MCE11は、MME300からCEレベルを通知されてもよい。当該CEレベルは、TMGIと紐付いていてもよい。当該CEレベルは、当該TMGIが示すMBMSサービスに興味があるUE100のCEレベルのうち最も拡張が必要なCEレベル(例えば、Repetition回数が最も多いCEレベル)であってもよい。MCE11(又はMME300)は、MBMSサービスのセッション開始要求において、eNB200(又はMCE11)に対して、当該MBMSサービスのRepetition回数を通知してもよい。
上述した各実施形態に係るMBMSカウンティングプロシージャを一般的なMBMSカウンティングプロシージャと併用してもよい。一例として、一般的なMBMSカウンティングプロシージャにより特定のMBMSサービスを受信している又は受信に興味を持つRRCコネクティッドモードのUE数を把握し、当該RRCコネクティッドモードのUE数に基づいて共通リソースプールのリソース量等を決定してもよい。
上述した各実施形態における上りリンク送信動作をコンテンションベースの上りリンクデータ送信に適用してもよい。そのような変更例においては、カウンティング要求は用いられず、かつ、「カウンティング応答」を「上りリンク信号」と読み替える。より具体的には、「カウンティング応答」を「上りリンクデータ」と読み替えてもよい。そのような変更例は、次のように要約することができる。移動通信システムのための無線端末は、複数の無線端末が上りリンク信号の送信に共通に用いるべき共通リソースを示す共通リソース設定をネットワークから受信する受信部と、自無線端末の固有識別子を取得し、前記固有識別子に基づいて自無線端末が上りリンク信号の送信に用いる無線リソースを前記共通リソースの中から決定する制御部と、前記決定された無線リソースを用いて、上りリンク信号を前記ネットワークに送信する送信部と、を備える。ここで、前記制御部は、前記固有識別子に基づいて、自無線端末が上りリンク信号の送信に用いる時間リソース(例えば、サブフレーム)を決定してもよい。前記制御部は、前記固有識別子に基づいて、自無線端末が上りリンク信号の送信に用いる周波数リソース(例えば、NB−IoTにおける180kHz(1リソースブロックの帯域幅)のキャリア)を決定してもよい。
コンテンションベースの上りリンクデータ送信において、UE100は、例えば、「IMSI mod x = 0」となるサブフレームのみ、コンテンションベースUL送信を行ってもよい。ここで、コンテンションベースUL送信を許可するサブフレームが歯抜けの場合(例えば、有効サブフレームがパターンでUE100に指定されている場合)、開始サブフレーム番号から起算して、有効サブフレームだけをカウントしてもよい。すなわち、UE100は、歯抜けの有効サブフレームのみを対象として、最初から順に0,1,2,3…番とみなしてもよい。eNB200は、コンテンションベース送信の許可識別子(例えば、SIBによる通知)、コンテンションベース送信の有効サブフレームのパターンを示すパラメータ(例えば、start subframe {start offset}、又はbitmap pattern {3, 5, 7, 10, 18}等)をブロードキャスト又はマルチキャストでUE100に通知してもよい。上述したように、UEの固有識別子としては、IMSIに限らず、Resume ID、C−RNTI、S−TMSIを用いてもよい。ここではコンテンションベースの上りリンクデータ送信を時間方向に分散させる一例を説明したが、周波数方向への分散を行ってもよい。例えば、UE100は、IMSI mod x = 0を満たすcarrier(すなわち、NB−IoTにおける180kHz(1リソースブロックの帯域幅))のみで上りリンク送信を行ってもよい。
コンテンションベースの上りリンクデータ送信において、CE(Enhanced Coverage)に居るUEとNC(Normal Coverage)に居るUEとで、別のリソース(サブフレーム及び/又は周波数)を割り当ててもよい(第3実施形態の変更例参照)。UE100は、測定したRSRPがある閾値を超えたか否かに応じてCEに居るか否かを判定してもよい。UE100は、繰り返し送信回数がある閾値を超えたか否かで判定してもよい。これらの閾値は、eNB200からUE100に対してブロードキャスト又はマルチキャストで通知されていてもよい。
コンテンションベースの上りリンクデータ送信において、UE100は、送信MCS毎に又は繰り返し送信回数毎に異なるリソースを割り当てられてもよい。UE100が送信MCSに応じて送信リソースを決定して上りリンク送信を行う場合、eNB200は、受信リソースに応じてデコード方式(MCS)を変更してもよい。
上述した各実施形態を別個独立に実施する場合に限らず、2以上の実施形態を組み合わせて実施してもよい。例えば、一の実施形態に係る一部の処理を他の実施形態に追加してもよい。或いは、一の実施形態に係る一部の処理を他の実施形態の一部の構成と置換してもよい。
上述した各実施形態において、移動通信システムとしてLTEシステムを例示した。しかしながら、本開示はLTEシステムに限定されない。LTEシステム以外の移動通信システムに本開示を適用してもよい。
本願は米国仮出願第62/381140号(2016年8月30日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。