JP2024059904A - 通信制御方法、ユーザ装置、チップセット、プログラム、基地局及びシステム - Google Patents

Abstract

【課題】改善されたマルチキャスト・ブロードキャストサービスを実現する通信制御方法及びユーザ装置を提供する。【解決手段】マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて、ユーザ装置が実行する通信制御方法は、ＲＲＣコネクティッド状態にあるユーザ装置（ＵＥ）が、ＭＢＳ受信に必要なＭＢＳ設定を含むＲＲＣメッセージを基地局ｇＮＢから受信することと、ＲＲＣコネクティッド状態からＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したＵＥが、ＲＲＣコネクティッド状態時に受信したＭＢＳ設定を用いて、ＭＢＳ受信を行うことと、を有する。ＲＲＣメッセージは、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＲＲＣ Ｒｅｌｅａｓｅメッセージである。【選択図】図１０

Description

本開示は、移動通信システムで用いる通信制御方法及びユーザ装置に関する。

近年、第５世代（５Ｇ）の移動通信システムが注目されている。５Ｇシステムの無線アクセス技術（ＲＡＴ：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）は、第４世代の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。

３ＧＰＰ技術仕様書「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．３．０ （２０２０－０９）」

第１の態様に係る通信制御方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する方法である。前記通信制御方法は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にある前記ユーザ装置が、ＭＢＳ受信に必要なＭＢＳ設定を含むＲＲＣメッセージを基地局から受信することと、前記ＲＲＣコネクティッド状態からＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した前記ユーザ装置が、前記ＲＲＣコネクティッド状態時に受信した前記ＭＢＳ設定を用いて、前記ＭＢＳ受信を行うことと、を有する。前記ＲＲＣメッセージは、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＲＲＣ Ｒｅｌｅａｓｅメッセージである。

第２の態様に係るユーザ装置は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて用いる装置である。前記ユーザ装置は、前記ユーザ装置がＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にあるときに、ＭＢＳ受信に必要なＭＢＳ設定を含むＲＲＣメッセージを基地局から受信する受信部と、前記ＲＲＣコネクティッド状態からＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した後に、前記ＲＲＣコネクティッド状態時に受信した前記ＭＢＳ設定を用いて前記ＭＢＳ受信を行う制御部と、を有する。前記ＲＲＣメッセージは、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＲＲＣ Ｒｅｌｅａｓｅメッセージである。

実施形態に係る移動通信システムの構成を示す図である。 実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 実施形態に係るｇＮＢ（基地局）の構成を示す図である。 データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 実施形態に係るＭＢＳトラフィック配信の概要を示す図である。 実施形態に係る配信モードを示す図である。 実施形態に係るスプリットＭＢＳベアラを示す図である。 配信モード１でＭＢＳ受信の設定に用いるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの構成例を示す図である。 一実施形態に係る動作を示す図である。 実施形態の第１変更例に係る動作を示す図である。 実施形態の第２変更例に係る動作を示す図である。 実施形態の第３変更例に係る動作を示す図である。 実施形態の第４変更例に係る動作を示す図である。 実施形態の第５変更例に係る動作を示す図である。 実施形態の第６変更例に係る動作を示す図である。 配信モード１設定の構造の一例を示す図である。 ＬＴＥ ＳＣ－ＰＴＭでの２段階設定を示す図である。 配信モード２のスキームの一例を示す図である。

５Ｇシステム（ＮＲ）にマルチキャスト・ブロードキャストサービスを導入することが検討されている。ＮＲのマルチキャスト・ブロードキャストサービスは、ＬＴＥのマルチキャスト・ブロードキャストサービスよりも改善されたサービスを提供することが望まれる。

そこで、本開示は、改善されたマルチキャスト・ブロードキャストサービスを実現することを目的とする。

図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。

（移動通信システムの構成）
まず、実施形態に係る移動通信システムの構成について説明する。

図１は、一実施形態に係る移動通信システムの構成を示す図である。この移動通信システムは、３ＧＰＰ規格の第５世代システム（５ＧＳ：５ｔｈ Ｇｅｎｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）に準拠する。以下において、５ＧＳを例に挙げて説明するが、移動通信システムにはＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システム及び／又は第６世代（６Ｇ）システムが少なくとも部分的に適用されてもよい。

図１に示すように、移動通信システムは、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ Ｃｏｒｅ Ｎｅｔｗｏｒｋ）２０とを有する。

ＵＥ１００は、移動可能な無線通信装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わない。例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）、タブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ ＵＥ）、及び／又は飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ ＵＥ）である。

ＮＧ－ＲＡＮ１０は、基地局（５Ｇシステムにおいて「ｇＮＢ」と呼ばれる）２００を含む。ｇＮＢ２００は、基地局間インターフェイスであるＸｎインターフェイスを介して相互に接続される。ｇＮＢ２００は、１又は複数のセルを管理する。ｇＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｇＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、及び／又はモビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数に属する。

なお、ｇＮＢがＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）に接続することもできる。ＬＴＥの基地局が５ＧＣに接続することもできる。ＬＴＥの基地局とｇＮＢとが基地局間インターフェイスを介して接続されることもできる。

５ＧＣ２０は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）及びＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）３００を含む。ＡＭＦは、ＵＥ１００に対する各種モビリティ制御等を行う。ＡＭＦは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００のモビリティを管理する。ＵＰＦは、データの転送制御を行う。ＡＭＦ及びＵＰＦは、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してｇＮＢ２００と接続される。

図２は、一実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。

図２に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。

受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。

送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。

図３は、一実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。

図３に示すように、ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。

送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。

制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。

バックホール通信部２４０は、基地局間インターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスを介してＡＭＦ／ＵＰＦ３００と接続される。なお、ｇＮＢは、ＣＵ（Ｃｅｎｔｒａｌ Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間はＦ１インターフェイスで接続されてもよい。

図４は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。

図４に示すように、ユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤとを有する。

ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。

ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｇＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｇＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ１００への割当リソースブロックを決定する。

ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｇＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。

ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。

ＳＤＡＰレイヤは、コアネットワークがＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。

図５は、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。

図５に示すように、制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤを有する。

ＵＥ１００のＲＲＣレイヤとｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合、ＵＥ１００はＲＲＣアイドル状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間の接続がサスペンドされている場合、ＵＥ１００はＲＲＣインアクティブ状態にある。

ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００ＢのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。

なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。

（ＭＢＳ）
次に、一実施形態に係るＭＢＳについて説明する。

ＭＢＳは、ＮＧ－ＲＡＮ１０からＵＥ１００に対してブロードキャスト又はマルチキャスト、すなわち、１対多（ＰＴＭ：Ｐｏｉｎｔ Ｔｏ Ｍｕｌｔｉｐｏｉｎｔ）でのデータ送信を可能とするサービスである。ＭＢＳのユースケース（サービス種別）としては、公安通信、ミッションクリティカル通信、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｅｖｅｒｙｔｈｉｎｇ）通信、ＩＰｖ４又はＩＰｖ６マルチキャスト配信、ＩＰＴＶ、グループ通信、及びソフトウェア配信等が想定される。

ブロードキャストサービスは、高信頼性のＱｏＳを必要としないアプリケーションのために、特定のサービスエリア内のすべてのＵＥ１００に対してサービスを提供する。マルチキャストサービスは、すべてのＵＥ１００に対してではなく、マルチキャストサービスに参加しているＵＥ１００のグループに対してサービスを提供する。マルチキャストサービスによれば、ブロードキャストサービスに比べて、無線効率の高い方法でＵＥ１００のグループに対して同じコンテンツを提供できる。

図６は、一実施形態に係るＭＢＳトラフィック配信の概要を示す図である。

図６に示すように、ＭＢＳトラフィックは、単一のデータソース（アプリケーションサービスプロバイダ）から複数のＵＥに配信される。５Ｇコアネットワークである５Ｇ ＣＮ（５ＧＣ）２０は、アプリケーションサービスプロバイダからＭＢＳトラフィックを受信し、ＭＢＳトラフィックのコピーの作成（Ｒｅｐｌｉｃａｔｉｏｎ）を行って配信する。

５ＧＣ２０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信（５ＧＣ Ｓｈａｒｅｄ ＭＢＳ Ｔｒａｆｆｉｃ ｄｅｌｉｖｅｒｙ）及び５ＧＣ個別ＭＢＳトラフィック配信（５ＧＣ Ｉｎｄｉｖｉｄｕａｌ ＭＢＳ Ｔｒａｆｆｉｃ ｄｅｌｉｖｅｒｙ）の２つのマルチキャスト配信方法が可能である。

５ＧＣ個別ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、ＵＥ１００ごとのＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）セッションを介してそれらのＭＢＳデータパケットの個別のコピーを個別のＵＥ１００に配信する。したがって、ＵＥ１００ごとに１つのＰＤＵセッションをマルチキャストセッションと関連付ける必要がある。

５ＧＣ共有ＭＢＳトラフィック配信方法では、第１に、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、それらのＭＢＳデータパケットの単一コピーをＲＡＮノード（すなわち、ｇＮＢ２００）に配信する。第２に、ｇＮＢ２００は、それらを１つ又は複数のＵＥ１００に配信する。

ＲＡＮ（５Ｇ ＲＡＮ）１０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信方法における無線を介したＭＢＳトラフィックの送信には、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）の２つの配信方法が可能である。

ＰＴＰ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの個別のコピーを無線で個々のＵＥ１００に配信する。他方、ＰＴＭ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの単一コピーを無線でＵＥ１００のグループに配信する。ｇＮＢ２００は、１つのＵＥ１００に対するＭＢＳトラフィックの配信方法としてＰＴＭ及びＰＴＰのどちらを用いるかを動的に決定する。

ＰＴＰ配信方法及びＰＴＭ配信方法は主としてユーザプレーンに関するものである。ＭＢＳトラフィック配信の制御モードとしては、配信モード１及び配信モード２の２つの配信モードがある。図７は、一実施形態に係る配信モードを示す図である。

図７に示すように、配信モード１（Ｄｅｌｉｖｅｒｙ ｍｏｄｅ １）は、ＲＲＣコネクティッド状態のＵＥ１００が利用できる配信モードであって、高ＱｏＳ要件のための配信モードである。配信モード１は、ＭＢＳセッションのうちマルチキャストセッションにのみ用いられる。一実施形態において、配信モード１がマルチキャストセッションに用いられることを想定するが、配信モード１がブロードキャストセッションに用いられてもよい。配信モード１は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００も利用可能であってもよい。

一実施形態において、配信モード１におけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にユニキャストで送信されるＲＲＣメッセージであるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（又はＲＲＣ Ｒｅｌｅａｓｅメッセージ）により行われる。ＭＢＳ受信の設定は、ＭＢＳトラフィックを運ぶＭＢＳトラフィックチャネルのスケジューリング情報を含む。論理チャネルの一種であるＭＢＳトラフィックチャネルは、ＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）と呼ばれることがある。ＭＢＳトラフィックチャネルは、トランスポートチャネルの一種であるＤＬ－ＳＣＨ（Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）にマッピングされる。

配信モード２（Ｄｅｌｉｖｅｒｙ ｍｏｄｅ ２）は、ＲＲＣコネクティッド状態のＵＥ１００だけではなく、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００が利用できる配信モードであって、低ＱｏＳ要件のための配信モードである。配信モード２は、ＭＢＳセッションのうちブロードキャストセッションに用いられる。但し、配信モード２は、マルチキャストセッションにも適用可能であってもよい。

配信モード２におけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にブロードキャストで送信される論理チャネル、例えば、ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）又はＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）により行われる。以下において、このような制御チャネルをＭＢＳ制御チャネルと呼ぶ。

なお、ネットワークは、ＭＢＳセッションごとに異なるＭＢＳサービスを提供できる。ＭＢＳセッションは、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ）及びセッション識別子のうち少なくとも１つにより識別される。これらの識別子のうち少なくとも１つをＭＢＳセッション識別子と呼ぶ。このようなＭＢＳセッション識別子は、ＭＢＳサービス識別子又はマルチキャストグループ識別子と呼ばれてもよい。

（スプリットＭＢＳベアラ）
次に、一実施形態に係るスプリットＭＢＳベアラについて説明する。スプリットＭＢＳベアラは、上述の配信モード１において利用可能である。

ｇＮＢ２００は、ＰＴＰ通信パス及びＰＴＭ通信パスに分離されたＭＢＳベアラ（以下、適宜「スプリットＭＢＳベアラ」と呼ぶ）をＵＥ１００に設定し得る。これにより、ｇＮＢ２００は、ＵＥ１００に対するＭＢＳトラフィックの送信をＰＴＰ（ＰＴＰ通信パス）とＰＴＭ（ＰＴＭ通信パス）との間で動的に切り替えることができる。或いは、ｇＮＢ２００は、ＰＴＰ及びＰＴＭを併用して同一のＭＢＳトラフィックを二重送信することにより信頼性を高めることができる。或いは、ｇＮＢ２００は、ＭＢＳトラフィックの初送をＰＴＭで複数のＵＥ１００に対して行い、ＭＢＳトラフィックの再送を特定のＵＥ１００に対して行うことにより信頼性を高めることができる。

スプリットを終端する所定レイヤは、ＭＡＣレイヤ（ＨＡＲＱ）、ＲＬＣレイヤ、ＰＤＣＰレイヤ、又はＳＤＡＰレイヤである。以下において、スプリットを終端する所定レイヤがＰＤＣＰレイヤである一例について主として説明するが、所定レイヤは、ＭＡＣレイヤ（ＨＡＲＱ）、ＲＬＣレイヤ、又はＳＤＡＰレイヤであってもよい。

図８は、一実施形態に係るスプリットＭＢＳベアラを示す図である。以下において、ＰＴＰ通信パスをＰＴＰレグと呼び、ＰＴＭ通信パスをＰＴＭレグと呼ぶ。また、各レイヤに相当する機能部をエンティティと呼ぶ。

図８に示すように、ｇＮＢ２００のＰＤＣＰエンティティ及びＵＥ１００のＰＤＣＰエンティティのそれぞれは、ＭＢＳに用いるベアラ（データ無線ベアラ）であるＭＢＳベアラをＰＴＰレグ及びＰＴＭレグに分離する。なお、ＰＤＣＰエンティティはベアラごとに設けられる。

ｇＮＢ２００及びＵＥ１００のそれぞれは、レグごとに設けられる２つのＲＬＣエンティティと、１つのＭＡＣエンティティと、１つのＰＨＹエンティティとを有する。ＰＨＹエンティティは、レグごとに設けられてもよい。なお、ＵＥ１００が２つのｇＮＢ２００との通信を行う二重接続（Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）の場合、ＵＥ１００が２つのＭＡＣエンティティを有していてもよい。

ＰＨＹエンティティは、ＵＥ１００と１対１で割り当てられるセルＲＮＴＩ（Ｃ－ＲＮＴＩ：Ｃｅｌｌ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を用いて、ＰＴＰレグのデータを送受信する。ＰＨＹエンティティは、ＭＢＳセッションと１対１で割り当てられるグループＲＮＴＩ（Ｇ－ＲＮＴＩ：Ｇｒｏｕｐ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を用いて、ＰＴＭレグのデータを送受信する。Ｃ－ＲＮＴＩはＵＥ１００ごとに異なるが、Ｇ－ＲＮＴＩは１つのＭＢＳセッションを受信する複数のＵＥ１００で共通のＲＮＴＩである。

ｇＮＢ２００からＵＥ１００に対してＰＴＭレグを用いてＭＢＳトラフィックのＰＴＭ送信（マルチキャスト又はブロードキャスト）を行うためには、ｇＮＢ２００からＵＥ１００にスプリットＭＢＳベアラが設定されており、且つ、ＰＴＭレグがアクティブ化（ａｃｔｉｖａｔｉｏｎ）されている必要がある。言い換えると、ｇＮＢ２００は、ＵＥ１００にスプリットＭＢＳベアラが設定されていても、ＰＴＭレグが非アクティブ（ｄｅａｃｔｉｖａｔｉｏｎ）状態にある場合は、このＰＴＭレグを用いてＭＢＳトラフィックのＰＴＭ送信を行うことができない。

また、ｇＮＢ２００及びＵＥ１００がＰＴＰレグを用いてＭＢＳトラフィックのＰＴＰ送信（ユニキャスト）を行うためには、ｇＮＢ２００からＵＥ１００にスプリットＭＢＳベアラが設定されており、且つ、ＰＴＰレグがアクティブ化されている必要がある。言い換えると、ｇＮＢ２００は、ＵＥ１００にスプリットＭＢＳベアラが設定されていても、ＰＴＰレグが非アクティブ状態にある場合は、このＰＴＰレグを用いてＭＢＳトラフィックのＰＴＰ送信を行うことができない。

ＵＥ１００は、ＰＴＭレグがアクティブ化された状態において、ＭＢＳセッションと対応付けられたＧ－ＲＮＴＩが適用されたＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）をモニタする（すなわち、Ｇ－ＲＮＴＩを用いてＰＤＣＣＨのブラインドデコーディングを行う）。ＵＥ１００は、当該ＭＢＳセッションのスケジューリング機会にのみ当該ＰＤＣＣＨをモニタしてもよい。

ＵＥ１００は、ＰＴＭレグが非アクティブ化された状態において、ＭＢＳセッションと対応付けられたＧ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタしない（すなわち、Ｇ－ＲＮＴＩを用いたＰＤＣＣＨのブラインドデコーディングを行わない）。

ＵＥ１００は、ＰＴＰレグがアクティブ化された状態において、Ｃ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタする。ＵＥ１００は、ＰＴＰレグにおける間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ）が設定されている場合、設定されたオン期間（ＯｎＤｕｒａｔｉｏｎ）においてＰＤＣＣＨをモニタする。ＵＥ１００は、ＭＢＳセッションと紐づいたセル（周波数）が指定されている場合、当該セルが非アクティブ化されていても、当該セルのＰＤＣＣＨをモニタしてもよい。

ＵＥ１００は、ＰＴＰレグが非アクティブ化された状態において、ＭＢＳトラフィック以外の通常のユニキャスト下りリンク送信にそなえて、Ｃ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタしてもよい。但し、ＵＥ１００は、ＭＢＳセッションと紐づいたセル（周波数）が指定されている場合、当該ＭＢＳセッションについて当該ＰＤＣＣＨをモニタしなくてもよい。

なお、ｇＮＢ２００のＲＲＣエンティティがＵＥ１００のＲＲＣエンティティに対して送信するＲＲＣメッセージ（例えば、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）により、上述のようなスプリットＭＢＳベアラが設定されるものとする。

（一実施形態に係る動作）
次に、一実施形態に係る動作について説明する。以下において、配信モードとして配信モード１を用いる場合を主として想定する。

図９は、配信モード１でＭＢＳ受信の設定に用いるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの構成例を示す図である。図９に示すように、ｇＮＢ２００からＵＥ１００に送信されるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、ＭＢＳ受信に必要なＭＢＳ設定を情報要素として含む。

ＭＢＳ設定は、ＭＢＳ受信のための基本的な設定である基本受信設定と、ＲＲＣコネクティッド状態におけるＭＢＳ受信にのみ適用可能なＲＲＣコネクティッド専用設定とを含む。

基本受信設定は、全ＲＲＣ状態（すなわち、ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）で共通の設定である。基本受信設定は、ＭＴＣＨスケジューリング情報を含む。ＭＴＣＨスケジューリング情報は、グループＲＮＴＩ、ＭＢＳセッション識別子、送信オケージョン、及び送信ＢＷＰ（Ｂａｎｄｗｉｄｔｈ Ｐａｒｔ）のうち少なくとも１つを含む。

ここで、グループＲＮＴＩは、ＵＥ１００のグループに対して共通に割り当てられるＲＮＴＩである。送信オケージョンは、ｇＮＢ２００がＭＴＣＨを用いてＭＢＳトラフィックを送信するタイミング（例えばサブフレーム）の候補である。送信ＢＷＰは、ｇＮＢ２００がＭＴＣＨを用いてＭＢＳトラフィックを送信するＢＷＰである。ＢＷＰは、１つのセルの周波数帯域幅よりも狭い帯域幅部分であって、ＵＥ１００の動作帯域幅を限定するためのものである。

他方、ＲＲＣコネクティッド専用設定は、スプリットＭＢＳベアラに関する設定等であって、例えば、スプリットＭＢＳベアラのベアラ設定、ＰＴＰとＰＴＭとの動的切り替え設定、及びＰＴＰレグ設定のうち少なくとも１つを含む。なお、ＰＴＭレグ設定は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態でも使用可能であるため、基本受信設定に含まれてもよい。ＲＲＣコネクティッド専用設定は、ＨＡＲＱフィードバック設定を含んでもよい。

一実施形態において、例えばＭＢＳ設定を有するＵＥ１００についてマルチキャストセッションの進行中のデータがないとき、ｇＮＢ２００は、ＵＥ１００をＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移させる。ここで、ｇＮＢ２００は、輻輳が原因でＵＥ１００をＲＲＣコネクティッド状態に維持できない状況にあってもよい。

ＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した場合であっても、ＭＢＳ受信を継続できることが望ましい。一実施形態において、ＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態で用いるＭＢＳ設定として、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージによって提供されたＭＢＳ設定を引き続き適用する。すなわち、ＵＥ１００は、ＲＲＣコネクティッド状態時に提供されたＭＢＳ設定を再利用する。

すなわち、一実施形態に係るＵＥ１００は、ＲＲＣコネクティッド状態にあるときに、ＭＢＳ受信に必要なＭＢＳ設定を含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（ＲＲＣメッセージ）を基地局から受信する。ＵＥ１００は、ＲＲＣコネクティッド状態からＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した後に、ＲＲＣコネクティッド状態時に受信したＭＢＳ設定を用いてＭＢＳ受信を行う。

ここで、ＭＢＳ設定のうちＲＲＣコネクティッド専用設定の取り扱いが問題になる。一実施形態に係るＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移する際に、ＲＲＣコネクティッド状態時に受信したＭＢＳ設定に含まれるＲＲＣコネクティッド専用設定を無効化する処理を行う。これにより、ＵＥ１００の記憶容量を節約できるとともに、予期せぬエラーの発生を抑制できる。

図１０は、一実施形態に係る動作を示す図である。

図１０に示すように、ステップＳ１０１において、ＵＥ１００は、ｇＮＢ２００のセルにおいてＲＲＣコネクティッド状態にある。

ステップＳ１０２において、ｇＮＢ２００は、ＭＢＳ設定、すなわち、基本受信設定とＲＲＣコネクティッド専用設定とを含むＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥ１００に送信する。ＵＥ１００は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信する。

ステップＳ１０３において、ＵＥ１００は、受信したＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれるＭＢＳ設定を記憶及び適用する。

ステップＳ１０４において、ＵＥ１００は、ステップＳ１０３で適用したＭＢＳ設定、すなわち、基本受信設定とＲＲＣコネクティッド専用設定とを用いて、ｇＮＢ２００からＭＢＳトラフィックを受信する。

このようにして、ＵＥ１００は、ＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージでＭＢＳ設定を受信し、ＭＢＳトラフィックを受信する。

その後、ステップＳ１０５において、ｇＮＢ２００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移させるＵＥ１００を特定する。

ここで、ｇＮＢ２００は、対象のＭＢＳセッションを受信しているＵＥ１００を、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移させるＵＥ１００として特定してもよい。例えば、ステップＳ１０４のＭＢＳトラフィック送信がマルチキャストで行われる場合、ｇＮＢ２００は、５ＧＣ２０に対して情報提供を要求し、対象のＭＢＳセッションを受信しているＵＥ１００を特定する。他方、ステップＳ１０４のＭＢＳトラフィック送信がブロードキャストで行われる場合、ｇＮＢ２００は、事前にＵＥ１００からＭＢＳ興味インディケーションメッセージ（ＭＩＩ）で情報提供を受ける。これにより、ｇＮＢ２００は、対象のＭＢＳセッションを受信しているＵＥ１００を特定する。

ｇＮＢ２００は、移動しないＵＥ１００を、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移させるＵＥ１００として特定してもよい。

移動中のＵＥ１００の場合、ＭＢＳサービスの継続性を保証するべく、ｇＮＢ２００がハンドオーバ制御を行う必要があり得るため、移動中のＵＥ１００はＲＲＣコネクティッド状態に維持することが望ましい。これに対し、移動しないＵＥ１００はそのような必要が無いため、ｇＮＢ２００は、移動しないＵＥ１００をＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移させる。これにより、ｇＮＢ２００の負荷を軽減できる。

また、ＵＥ１００がセル（又は後述のエリア範囲）から出ると、このセルのＭＢＳ設定が無効になる虞があるが、移動しないＵＥ１００はそのような虞が無い。そのため、ｇＮＢ２００は、移動しないＵＥ１００をＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移させることにより、ｇＮＢ２００の負荷を軽減できる。

なお、ｇＮＢ２００は、自セルにおける滞在時間が所定時間を超えるＵＥ１００を移動しないＵＥ１００として特定してもよい。また、ｇＮＢ２００は、ＵＥ１００から周期的に受信する位置情報に基づいて、移動しないＵＥ１００を特定してもよい。もしくは、ｇＮＢ２００は、ＵＥ１００から移動状態を通知されることにより、移動しないＵＥ１００を特定してもよい。当該通知はｇＮＢ２００からの要求によって通知されてもよい。当該通知はＵＥ１００自身が判断して（例えば移動状態が変化したことに伴って）通知されてもよい。当該移動状態はＭＢＳ興味インディケーション（ＭＩＩ）を用いて通知されてもよい。当該移動状態はＭＢＳ受信への興味情報と紐づいて通知されてもよい。

ステップＳ１０６において、ｇＮＢ２００は、ステップＳ１０５で特定したＵＥ１００に対してＲＲＣ Ｒｅｌｅａｓｅメッセージを送信する。ＵＥ１００は、ＲＲＣ Ｒｅｌｅａｓｅメッセージを受信する。ｇＮＢ２００は、ＵＥ１００をＲＲＣインアクティブ状態に遷移させる場合、ｓｕｓｐｅｎｄ ｃｏｎｆｉｇを情報要素として含むＲＲＣ ＲｅｌｅａｓｅメッセージをＵＥ１００に送信する。

ステップＳ１０７において、ＵＥ１００は、受信したＲＲＣ Ｒｅｌｅａｓｅメッセージに基づいてＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移する。

ステップＳ１０８において、ＵＥ１００は、基本受信設定の適用を継続するとともに、ＲＲＣコネクティッド専用設定を無効化する処理を行う。無効化する処理は、ＲＲＣコネクティッド専用設定の破棄（ｄｉｓｃａｒｄ）、ＲＲＣコネクティッド専用設定の適用中断（ｓｕｓｐｅｎｄ）、又はＲＲＣコネクティッド専用設定の非アクティブ化（ｄｅａｃｔｉｖａｔｅ）である。

ｓｕｓｐｅｎｄ又はｄｅａｃｔｉｖａｔｅの場合、ＲＲＣコネクティッド専用設定は破棄されずに保持される。保持されたＲＲＣコネクティッド専用設定は、ＵＥ１００が再びＲＲＣコネクティッド状態に戻った際に復旧（有効化）され得る。なお、ＵＥ１００がＲＲＣインアクティブ状態からＲＲＣコネクティッド状態に遷移する動作はレジューム（ＲＲＣレジューム）と呼ばれる。ＵＥ１００は、ＲＲＣレジューム時に、保持されたＲＲＣコネクティッド専用設定を有効化しなくてもよい。ＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したときのセルと、ＲＲＣコネクティッド状態に戻るときのセルとが同じである場合はＲＲＣコネクティッド専用設定を有効化し、これらが異なるセルである場合はＲＲＣコネクティッド専用設定を有効化しないとしてもよい（詳細については、後述の変更例で説明する）。

また、ステップＳ１０８において、ＵＥ１００は、ＲＲＣコネクティッド状態のみで使用していたエンティティ、例えば、ＰＴＰレグのＲＬＣエンティティを解放してもよい。ＵＥ１００は、関連するエンティティの再設定、例えば、ＰＤＣＰエンティティのスプリット（又は結合）機能を停止設定してもよい。

ステップＳ１０９において、ＵＥ１００は、基本受信設定を用いて、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態でＭＢＳトラフィックの受信を継続する。

（第１変更例）
次に、上述の実施形態の第１変更例について、上述の実施形態との相違点を主として説明する。

本変更例において、ＵＥ１００は、ＲＲＣコネクティッド状態からＲＲＣインアクティブ状態へ遷移する場合、ＲＲＣコネクティッド専用設定を保持するものとする。これにより、ＵＥ１００は、保持している設定を有効に活用して、素早くスプリットＭＢＳベアラ等の設定を行うことが可能になる。なお、ＵＥ１００がＲＲＣインアクティブ状態に遷移したときのｇＮＢ２００と、ＲＲＣコネクティッド状態に戻るときのｇＮＢ２００とが同じであってもよいし、これらのｇＮＢ２００が異なっていてもよい。

本変更例において、ＲＲＣインアクティブ状態に遷移したＵＥ１００は、ＲＲＣインアクティブ状態においてＲＲＣコネクティッド専用設定を保持する。ＵＥ１００は、ＲＲＣインアクティブ状態からＲＲＣコネクティッド状態に遷移するレジューム動作時に、ＲＲＣコネクティッド専用設定を保持していることを示す通知をｇＮＢ２００に送信する。この通知を受信したｇＮＢ２００は、ＵＥ１００が保持しているＲＲＣコネクティッド専用設定を有効化するか否かをＵＥ１００に指示する。

図１１は、実施形態の第１変更例に係る動作を示す図である。ここでは、ＵＥ１００がＲＲＣインアクティブ状態に遷移したときのｇＮＢ２００ａと、ＲＲＣコネクティッド状態に戻るときのｇＮＢ２００ｂとが異なる一例について説明する。

図１１に示すように、ステップＳ２０１乃至Ｓ２０８の動作は、上述の実施形態と同様である。但し、本変更例において、ＵＥ１００は、ＲＲＣインアクティブ状態に遷移する際に、ＲＲＣコネクティッド専用設定を無効化及び保持するものとする。ステップＳ２０９において、ＵＥ１００は、基本受信設定を用いて、ＲＲＣインアクティブ状態でＭＢＳトラフィックの受信を継続する。

ステップＳ２１０において、ＲＲＣインアクティブ状態にあるＵＥ１００は、ｇＮＢ２００ａのセルからｇＮＢ２００ｂのセルへのセル再選択を行う。

ＵＥ１００は、ＲＲＣ接続のレジュームを行うことを決めると、ステップＳ２１１において、ｇＮＢ２００ｂとのランダムアクセスプロシージャを開始する。

ＲＲＣレジュームの場合の一般的なランダムアクセスプロシージャは、以下の１）～５）を含む。
１）ＵＥ１００からｇＮＢ２００ｂへのランダムアクセスプリアンブル（Ｍｓｇ１）の送信
２）ｇＮＢ２００ｂからＵＥ１００へのランダムアクセス応答（Ｍｓｇ２）の送信
３）ＵＥ１００からｇＮＢ２００ｂへのＲＲＣ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔメッセージ（Ｍｓｇ３）の送信
４）ｇＮＢ２００ｂからＵＥ１００へのＲＲＣ Ｒｅｓｕｍｅメッセージ（Ｍｓｇ４）の送信
５）ＵＥ１００からｇＮＢ２００ｂへのＲＲＣ Ｒｅｓｕｍｅ Ｃｏｍｐｌｅｔｅメッセージ（Ｍｓｇ５）の送信
他方、２ステップのランダムアクセスプロシージャは、Ｍｓｇ１及びＭｓｇ３が１つのメッセージ（ＭｓｇＡ）に統合され、Ｍｓｇ２及びＭｓｇ４が１つのメッセージ（ＭｓｇＢ）に統合される。

このようなランダムアクセスプロシージャにおいて、ＵＥ１００は、特別なＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）リソースを用いてＭｓｇ１又はＭｓｇＡを送信する。これにより、ＵＥ１００は、ＲＲＣコネクティッド専用設定を保持していることをｇＮＢ２００ｂに通知する（ステップＳ２１１ａ）。或いは、ＵＥ１００は、ＲＲＣコネクティッド専用設定を保持していることを示す情報要素を含むＭｓｇ３、ＭｓｇＡ、又はＭｓｇ５を送信する。これにより、ＵＥ１００は、ＲＲＣコネクティッド専用設定を保持していることをｇＮＢ２００ｂに通知する（ステップＳ２１１ａ）。

ＵＥ１００から保持通知を受けたｇＮＢ２００ｂは、ＵＥ１００が保持しているＲＲＣコネクティッド専用設定を有効化するか否かを決定し、決定結果を示す指示をＵＥ１００に送信する（ステップＳ２１２）。例えば、ｇＮＢ２００ｂは、ＵＥ１００のコンテキスト情報をｇＮＢ２００ａから取得できた場合に限り、ＵＥ１００が保持しているＲＲＣコネクティッド専用設定を有効化すると決定してもよい。

ＵＥ１００は、ＲＲＣコネクティッド専用設定を有効化する指示をｇＮＢ２００ｂから受信した場合、保持しているＲＲＣコネクティッド専用設定を有効化する。これに対し、ＵＥ１００は、ＲＲＣコネクティッド専用設定を有効化する指示をｇＮＢ２００ｂから受信しない場合、保持しているＲＲＣコネクティッド専用設定を有効化しない。この場合、ＵＥ１００は、保持しているＲＲＣコネクティッド専用設定を破棄してもよい。

（第２変更例）
次に、上述の実施形態の第２変更例について、上述の実施形態との相違点を主として説明する。本変更例において、ＵＥ１００は、ＲＲＣコネクティッド状態からＲＲＣアイドル状態又はＲＲＣインアクティブ状態へ遷移する場合、ＲＲＣコネクティッド専用設定を保持するものとする。

マルチキャストセッション（配信モード１）は、基本的に、ネットワーク制御型の配信モードであってＵＥ１００がＲＲＣコネクティッド状態に維持される。しかし、一時的なネットワーク混雑等の理由で、ＵＥ１００はＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移される。

他方、ＲＲＣコネクティッド専用設定におけるスプリットＭＢＳベアラは、セル端のＵＥ１００に設定されることが多いと想定される。例えば、セル端のＵＥ１００は無線状況が悪いため、ｇＮＢ２００は、ＰＴＰレグを用いてＭＢＳトラフィックを伝送し得る。或いは、セル端のＵＥ１００についてはハンドオーバを行う蓋然性が高いため、ｇＮＢ２００は、ハンドオーバ時のパケットロスを無くすためにＰＴＰレグを用いてＭＢＳトラフィックを伝送し得る。

このため、本変更例において、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態へ遷移し、且つＲＲＣコネクティッド専用設定を保持するＵＥ１００は、セル端において他セルへのセル再選択を行う前にｇＮＢ２００に通知する。これにより、ｇＮＢ２００（ネットワーク）が通知に基づいてＵＥ１００に対するモビリティ制御を行うことが可能である。

本変更例において、ＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態において、セル再選択に関する所定条件（トリガ条件）が満たされたと判定した場合、ｇＮＢ２００に対するランダムアクセスプロシージャを開始する。ＵＥ１００は、ランダムアクセスプロシージャにおいて、所定条件が満たされたことを示す通知をｇＮＢ２００に送信する。

図１２は、実施形態の第２変更例に係る動作を示す図である。ここでは、ＵＥ１００がＲＲＣインアクティブ状態に遷移する場合を想定しているが、ＵＥ１００がＲＲＣアイドル状態に遷移する場合を想定してもよい。すなわち、図１２におけるＲＲＣインアクティブ状態をＲＲＣアイドル状態と読み替えてもよい。

図１２に示すように、ステップＳ３０１乃至Ｓ３０８の動作は、上述の実施形態と同様である。但し、本変更例において、ＵＥ１００は、ＲＲＣインアクティブ状態（又はＲＲＣアイドル状態）に遷移する際に、ＲＲＣコネクティッド専用設定を無効化及び保持するものとする。ステップＳ３０９において、ＵＥ１００は、基本受信設定を用いて、ＲＲＣインアクティブ状態（又はＲＲＣアイドル状態）でＭＢＳトラフィックの受信を継続する。

ステップＳ３１０において、ＵＥ１００は、ｇＮＢ２００のセルから他セルへのセル再選択に関するトリガを検知する。セル再選択に関するトリガ条件は、実際にセル再選択をトリガする条件であってもよいし、セル再選択をトリガする予兆を示す条件であってもよい。トリガ条件は、ｇＮＢ２００からＵＥ１００に設定される閾値（例えば、ＲＳＲＰ／ＲＳＲＱ閾値）及びその比較対象を指定する情報（イベント情報）を含んでもよい。

ＵＥ１００は、セル再選択に関するトリガを検知すると、ステップＳ３１１において、ｇＮＢ２００とのランダムアクセスプロシージャを開始する。

このランダムアクセスプロシージャにおいて、ＵＥ１００は、セル再選択に関するトリガ条件が満たされたことを示す通知をｇＮＢ２００に送信する。このような通知の方法としては、上述の実施形態の第１変更例と同様な方法を用いることができる。すなわち、ＵＥ１００は、特別なＰＲＡＣＨリソースを用いてＭｓｇ１又はＭｓｇＡを送信することにより、セル再選択に関するトリガ条件が満たされたことをｇＮＢ２００に通知する（ステップＳ３１１ａ）。或いは、ＵＥ１００は、セル再選択に関するトリガ条件が満たされたことを示す情報要素を含むＭｓｇ３、ＭｓｇＡ、又はＭｓｇ５を送信することにより、セル再選択に関するトリガ条件が満たされたことをｇＮＢ２００に通知する（ステップＳ３１１ａ）。なお、ＵＥ１００は、ステップＳ３１２でのモビリティ制御に用いるために、自身の無線状況を示す無線測定結果を含む測定報告をｇＮＢ２００に送信してもよい。

ステップＳ３１２において、ｇＮＢ２００は、ステップＳ３１１ａでＵＥ１００から受信した通知に基づいて、ＵＥ１００に対するモビリティ制御（ハンドオーバ制御又はセル再選択制御）を行う。例えば、ｇＮＢ２００は、ＵＥ１００をＲＲＣコネクティッド状態に遷移させたうえで他セルへのハンドオーバを行う。或いは、ｇＮＢ２００は、ＵＥ１００をＲＲＣアイドル状態又はＲＲＣインアクティブ状態に留めたうえで他セルへのセル再選択をＵＥ１００に行わせる。この場合、ｇＮＢ２００は、ＲＲＣコネクティッド専用設定の破棄をＵＥ１００に指示してもよい。

（第３変更例）
次に、上述の実施形態の第３変更例について、上述の実施形態との相違点を主として説明する。

本変更例において、ＲＲＣコネクティッド状態においてＲＲＣコネクティッド専用設定を有するＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態への遷移が禁止されるものとする。このような前提下において、ｇＮＢ２００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態にＵＥ１００を遷移させる前に、ＲＲＣコネクティッド専用設定をＵＥ１００に解放（破棄）させたうえで、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態へＵＥ１００を遷移させる。そして、ＵＥ１００は、ｇＮＢ２００によりＲＲＣコネクティッド専用設定が解放された後に、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移する。

図１３は、実施形態の第３変更例に係る動作を示す図である。

図１３に示すように、ステップＳ４０１乃至Ｓ４０５の動作は、上述の実施形態と同様である。但し、ステップＳ４０５において、ｇＮＢ２００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移可能なＵＥ１００を特定してもよい。例えば、ｇＮＢ２００は、一定期間にわたって上りリンク送信の見込みがないＵＥ１００又はユニキャスト通信がないＵＥ１００を特定する。ステップＳ４０５において、ｇＮＢ２００は、ＲＲＣ接続の解放を促すメッセージ、例えば、ＲＡＩ（Ｒｅｌｅａｓｅ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージを送信したＵＥ１００を特定してもよい。

ステップＳ４０６において、ｇＮＢ２００は、特定したＵＥ１００に対して、ＲＲＣコネクティッド専用設定を解放することを示す情報要素を含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを送信する。

ステップＳ４０７において、ＵＥ１００は、ステップＳ４０６のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの受信に応じて、ＲＲＣコネクティッド専用設定を解放（破棄）する。ＵＥ１００は、ＭＢＳ設定のうちＰＴＭのＭＢＳ設定（基本受信設定）のみを有する状態になる。

ステップＳ４０８において、ｇＮＢ２００は、ＲＲＣコネクティッド専用設定を解放したＵＥ１００に対してＲＲＣ Ｒｅｌｅａｓｅメッセージを送信する。ＵＥ１００は、ＲＲＣ Ｒｅｌｅａｓｅメッセージを受信する。

ステップＳ４０９において、ＵＥ１００は、受信したＲＲＣ Ｒｅｌｅａｓｅメッセージに基づいてＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移する。

ステップＳ４１０において、ＵＥ１００は、基本受信設定の適用を継続する。

ステップＳ４１１において、ＵＥ１００は、基本受信設定を用いて、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態でＭＢＳトラフィックの受信を継続する。

なお、本変更例において、ＭＢＳ設定をＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージにより行うシナリオを想定しているが、ＭＢＳ設定をＲＲＣ Ｒｅｌｅａｓｅメッセージにより行うシナリオを想定してもよい。ＭＢＳ設定をＲＲＣ Ｒｅｌｅａｓｅメッセージにより行うシナリオにおいて、ステップＳ４０６のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの送信は不要である。このようなシナリオにおいて、ｇＮＢ２００は、ＲＲＣコネクティッド専用設定をＲＲＣ Ｒｅｌｅａｓｅメッセージにより行うことが禁止されてもよい。例えば、ＲＲＣコネクティッド専用設定に関する情報要素は、ＲＲＣ Ｒｅｌｅａｓｅメッセージでは使えない条件設定となっていてもよい。

（第４変更例）
次に、上述の実施形態の第４変更例について、上述の実施形態との相違点を主として説明する。

本変更例において、複数のセルからなるエリア範囲においてＭＢＳ設定が共通化されるものとする。これにより、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したＵＥ１００は、当該エリア範囲内ではＭＢＳ設定を更新することなくＭＢＳトラフィックの受信を継続できる。当該エリア範囲は、上述の実施形態の第１変更例及び第２変更例に係る通知が不要なエリアとして定義されてもよい。

具体的には、本変更例に係るＵＥ１００は、ＭＢＳ設定が有効なエリア範囲を示すエリア情報を含むＲＲＣメッセージ（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＲＲＣ Ｒｅｌｅａｓｅメッセージ）をｇＮＢ２００から受信する。ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したＵＥ１００は、当該エリア情報が示すエリア範囲内において、当該ＭＢＳ設定を用いてＭＢＳ受信を行う。

図１４は、実施形態の第４変更例に係る動作を示す図である。

図１４に示すように、ステップＳ５０１乃至Ｓ５０７の動作は、上述の実施形態と同様である。但し、ステップＳ５０２又はＳ５０６において、ｇＮＢ２００は、ＭＢＳ設定とともにエリア情報をＵＥ１００に送信することにより、当該ＭＢＳ設定が有効なエリア範囲をＵＥ１００に設定する。エリア情報は、エリア範囲を構成する各セルの識別子（セル識別子）からなるリストであってもよい。各セルが自セルの識別子を報知しているため、ＵＥ１００は、設定されたリストを用いて、自身が当該エリア範囲内であるか否かを判定できる。或いは、エリア情報は、エリア範囲を示す識別子（エリア識別子）であってもよい。各セルが自セルの属するエリア範囲のエリア識別子を報知しているため、ＵＥ１００は、設定されたエリア識別子を用いて、自身が当該エリア範囲内であるか否かを判定できる。

ステップＳ５０７において、ＵＥ１００は、ステップＳ５０６で受信したＲＲＣ Ｒｅｌｅａｓｅメッセージに基づいてＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移する。

ステップＳ５０８及びＳ５０９において、ＵＥ１００は、ｇＮＢ２００から設定されたＭＢＳ設定のうち基本受信設定を用いてＭＢＳトラフィックの受信を継続する。ここで、ＵＥ１００は、ｇＮＢ２００から設定されたエリア範囲内においては当該ＭＢＳ設定が有効であるとみなし、セル再選択を行う場合でもネットワークへの通知を行わない。

ＵＥ１００は、当該エリア範囲外のセルへ自身が移動した場合、当該エリア範囲外のセルに対してランダムアクセスを行うことにより、このセルから新たなＭＢＳ設定を受信する。或いは、ＵＥ１００は、当該エリア範囲外のセルを検知した場合、当該エリア範囲外に移動する前に現在のセルに対してランダムアクセスを行うことにより、このセルから新たなＭＢＳ設定を受信してもよい。

（第５変更例）
次に、上述の実施形態の第５変更例について、上述の実施形態との相違点を主として説明する。

本変更例において、ｇＮＢ２００は、ＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージによるＭＢＳ設定（具体的には、基本受信設定）をＲＲＣアイドル状態又はＲＲＣインアクティブ状態でも使用してよいか否かを、ＲＲＣ ＲｅｌｅａｓｅメッセージでＵＥ１００に通知する。すなわち、ＵＥ１００は、ＲＲＣコネクティッド状態時に受信したＭＢＳ設定をＲＲＣアイドル状態又はＲＲＣインアクティブ状態において使用可能とするか否かを示す情報を含むＲＲＣ ＲｅｌｅａｓｅメッセージをｇＮＢ２００から受信する。

図１５は、実施形態の第５変更例に係る動作を示す図である。

図１５に示すように、ステップＳ６０１乃至Ｓ６０９の動作は、上述の実施形態と同様である。但し、ステップＳ６０６において、ｇＮＢ２００は、次のＡ）及びＢ）のいずれかの情報を含むＲＲＣ ＲｅｌｅａｓｅメッセージをＵＥ１００に送信する。

Ａ）ステップＳ６０２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージで設定されたＭＢＳ設定をＲＲＣアイドル状態又はＲＲＣインアクティブ状態において継続使用してよいか否かを示す情報。

Ｂ）ステップＳ６０２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージで設定されたＭＢＳ設定をＲＲＣアイドル状態又はＲＲＣインアクティブ状態で使用する場合の有効期限を示す情報。有効期限を示す情報は、ＳＦＮ（Ｓｙｓｔｅｍ Ｆｒａｍｅ Ｎｕｍｂｅｒ）、Ｈ－ＳＦＮ（Ｈｙｐｅｒ ＳＦＮ）、及びサブフレームのうち少なくとも１つにより表現されてもよい。有効期限を示す情報は、有効期限の時間長を示すタイマ値であってもよい。

上述のＡ）の場合において、ＵＥ１００は、継続使用が許可されることを示す情報を含むＲＲＣ ＲｅｌｅａｓｅメッセージをｇＮＢ２００から受信（ステップＳ６０６）した場合に限り、ステップＳ６０２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ中のＭＢＳ設定をＲＲＣアイドル状態又はＲＲＣインアクティブ状態において継続使用する。

上述のＢ）の場合において、ＵＥ１００は、ＲＲＣ Ｒｅｌｅａｓｅメッセージで設定された有効期限内においてのみ、ステップＳ６０２のＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ中のＭＢＳ設定をＲＲＣアイドル状態又はＲＲＣインアクティブ状態において継続使用する。なお、有効期限がタイマ値により設定される場合、ＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移（ステップＳ６０７）する際に、タイマ（タイマ値に対応するタイマ）を起動し、このタイマが満了するまでの間においてＭＢＳ設定を継続使用する。

ここで、有効期限が切れた場合（タイマが満了した場合）、まだＭＢＳ受信に興味があるＵＥ１００は、ｇＮＢ２００に対してランダムアクセスを行うことにより、ｇＮＢ２００から新たなＭＢＳ設定を受信してもよい。当該ランダムアクセスプロシージャにおいて、ＵＥ１００は、ＭＢＳ設定の更新のためのアクセスであることをｇＮＢ２００に通知してもよい。当該通知は、特別なＰＲＡＣＨリソースを用いたＭｓｇ１／ＭｓｇＡで示されてもよく、Ｍｓｇ３において示されてもよい。もしくは、配信モード２によるＭＢＳ設定がＳＩＢ又はＭＣＣＨで報知されている場合、ＵＥ１００は、配信モード２によるＭＢＳ設定の取得を試みてもよい。他方、有効期限が切れた際に、既にＭＢＳ受信に興味がないＵＥ１００は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージで設定されたＭＢＳ設定を破棄してもよい。

（第６変更例）
次に、上述の実施形態の第６変更例について、上述の実施形態との相違点を主として説明する。

本変更例において、ＵＥ１００は、隣接セル情報を含むＲＲＣ Ｒｅｌｅａｓｅメッセージを受信する。隣接セル情報は、隣接セルの識別子と、当該隣接セルが提供するＭＢＳサービス（ＭＢＳセッション）を示す識別子とを含む。これにより、ＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態においてセル再選択を行う際に、自身の興味があるＭＢＳサービスを提供するセルを優先的に選択可能になる。ＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したＵＥ１００は、受信した隣接セル情報に基づいてセル再選択を制御する。

図１６は、実施形態の第６変更例に係る動作を示す図である。

図１６に示すように、ステップＳ７０１乃至Ｓ７０９の動作は、上述の実施形態と同様である。但し、ステップＳ７０６において、ｇＮＢ２００は、隣接セル情報を含むＲＲＣ ＲｅｌｅａｓｅメッセージをＵＥ１００に送信する。ｇＮＢ２００は、隣接セル情報とＭＢＳ設定（具体的には、基本受信設定）とを含むＲＲＣ ＲｅｌｅａｓｅメッセージをＵＥ１００に送信してもよい。

この隣接セル情報は、隣接セルの識別子（セル識別子）と、当該隣接セルが提供するＭＢＳサービスを示す識別子（セッション識別子）のリストとを含む。ＵＥ１００は、自身が興味のあるＭＢＳ設定を提供しているセルをセル再選択における最高優先度とみなしてセル再選択を行う。

（その他の実施形態）
上述の各変更例は、別個独立して実施する場合に限らず、２以上の変更例を組み合わせて実施可能である。

また、上述の実施形態において、基地局がＮＲ基地局（ｇＮＢ）である一例について説明したが基地局がＬＴＥ基地局（ｅＮＢ）であってもよい。また、基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノード等の中継ノードであってもよい。基地局は、ＩＡＢノードのＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）であってもよい。

ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。

また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ）として構成してもよい。

以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。

本願は、米国仮出願第６３／１３４，２８０号（２０２１年１月６日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。

（付記）
（導入）
ＮＲのマルチキャストブロードキャストサービス（ＭＢＳ）に関する改訂されたワークアイテムが承認された。ＭＢＳの２つの配信モードを次のように導入することが合意された。

・Ｒｅｌ－１７において、Ｒ２は、次の２つのモードを規定する。
１：コネクティッド（データ受信がない場合、ＵＥは他の状態に切り替えることができる可能性があるが、未定）で利用可能な高ＱｏＳ（信頼性、遅延）要件のための配信モード。
２：「低」ＱｏＳ要件のための配信モード。ＵＥはインアクティブ／アイドルでもデータを受信し得る（詳細は未定）。
・Ｒ２は、（Ｒ１７の場合）配信モード１がマルチキャストセッションにのみ使用されることを前提とする。
・Ｒ２は、配信モード２がブロードキャストセッションに使用されることを前提とする。
・配信モード２のマルチキャストセッションへの適用性は、更なる検討が必要である。
・データなし：マルチキャストセッションで進行中のデータがない場合、ＵＥはＲＲＣコネクティッドに留まり得る。その他の場合は、更なる検討が必要である。

配信モード２に関して、ＭＢＳ設定の概要を以下のように追加合意した。

ＵＥは、ＢＣＣＨ及び／又はＭＣＣＨ（未定）によって（ブロードキャスト／配信モード２の場合）ＭＢＳ設定を受信し、これは、アイドル／インアクティブモードで受信され得る。コネクティッドモードは、更なる検討が必要である。通知メカニズムは、ＭＢＳ制御情報の変更を通知するために使用される。

この付記では、ＬＴＥ ｅＭＢＭＳメカニズム及び最新のＲＡＮ２の合意を考慮して、ＮＲ ＭＢＳの制御プレーンの側面を考慮する。

（議論）
ＲＡＮ２の合意に従って、この時点での２つの配信モードを表１に要約する。

（配信モード１設定）
配信モード１は、主にＲＲＣコネクティッドでのデータ受信のために検討されるが、設定の側面はまだ合意されていない。ＭＢＳ設定がＲＲＣ再設定によって提供されることは非常に平易であり得るが、ＬＴＥ ｅＭＢＭＳのようにコネクティッドでＭＣＣＨが受信されることはまだ検討中である。配信モード１は高ＱｏＳサービスに期待されることを考慮すると、例えば、ＰＴＰ／ＰＴＭスプリットベアラ及び／又はロスレスハンドオーバなどを伴うべきである。これらのＵＥ固有の設定がＭＣＣＨを介して提供されている場合、意味がないため、私たちの見解では、配信モード１の設定にＲＲＣ再設定が使用されるべきである。

提案１：配信モード１において、ＲＡＮ２は、ＭＢＳ設定にＲＲＣ再設定を使用することに合意すべきである。

一方、ＷＩＤは、次のように、ＲＲＣコネクティッド及びアイドル／インアクティブがＭＢＳ設定に関して最大の共通性を持つべきであることを明確に示すが、ＲＡＮ２は、マルチキャストセッション及びブロードキャストセッションのそれぞれに対して別々の配信モードに同意した。

ＰＴＭ受信の設定でＲＲＣコネクティッド状態とＲＲＣアイドル／インアクティブ状態との間で最大の共通性を維持することを目的として、ＲＲＣアイドル／インアクティブ状態のＵＥによるＰＴＭ送信の受信を有効にするために必要な変更を規定する。

これらの配信モードのＲＲＣメッセージが異なる場合でも、ＷＩＤの目的を達成するには、ＭＢＳ設定の構造及びＩＥを２つの配信モード間で可能な限り調整すべきである。例えば、配信モード１のＲＲＣ再設定には、配信モード２と共通のブロックであるＭＴＣＨスケジューリング情報に加えて、ＰＴＰ／ＰＴＭスプリットベアラ及びハンドオーバ関連情報などの配信モード１固有の情報が含まれる。このため、詳細はこの時点で更なる検討が必要である。

提案２：ＲＡＮ２は、ＭＢＳ設定の観点から、例えば、共通の構造及びＩＥを使用して、２つの配信モード間の最大の共通性を目指すことに合意すべきである。

なお、図１７における「ＭＣＣＨ」は、ＭＴＣＨスケジューリング情報、即ち、ＭＢＳセッション情報と関連するＭＴＣＨ設定のみを指している。配信モード１の場合、隣接セル情報は必要ない。

マルチキャストセッションの進行中のデータがない場合にＵＥをアイドル／インアクティブに解放し得るかは、更なる検討が必要である。言い換えると、アイドル／インアクティブのＵＥが配信モード１を介してＭＢＳデータを受信できるかどうかは、更なる検討が必要である。ＲＡＮ２が同意したように、ＵＥは配信モード１、つまり高いＱｏＳを必要とするマルチキャストセッションのためにＲＲＣコネクティッドに維持すべきであることがベースラインである。しかし、他の／例外的なケースについても、まだ検討する価値がある。

Ｅメールディスカッション中に、一部の企業は、輻輳が原因でネットワークがすべてのＵＥをコネクティッドに維持できない可能性があることを指摘した。他の一部の企業も、アップリンクアクティビティ、ＱｏＳ要件、及び／又はＵＥの電力消費のために、ＵＥが常にコネクティッドのままである必要はないことを指摘した。

ＲＡＮ２の観点から、ネットワーク及びＵＥの両方がこの機能をサポートすることは有益であると考えられ得る。ＵＥがインアクティブに解放されるか／いつ解放されるかはｇＮＢの実装次第であり、ＵＥがアイドルに解放されるかはコアネットワーク次第であると想定される。アイドルでのＭＢＳデータ受信に関する１つの懸念は、ｇＮＢがＵＥコンテキストを解放することである。一方、ＵＥコンテキストは、インアクティブでは保持される。これは、ｇＮＢの可制御性が失われる可能性があることを意味し、一般的な配信モード１の概念と矛盾する可能性がある。したがって、ＲＡＮ２は、配信モード１を少なくともインアクティブでＵＥが受信し得ることに合意すべきあるが、アイドルにおいては更なる検討が必要である。

提案３：配信モード１において、ＲＡＮ２は、配信モード１を少なくともインアクティブでＵＥが受信し得ることに合意すべきある。アイドルにおいては更なる検討が必要である。

提案３に合意できる場合、アイドル／インアクティブのＭＢＳ設定がＵＥにどのように提供されるかは明確ではない。次の３つのオプションが考えられる。

・オプション１：ＲＲＣ再設定
アイドル／インアクティブのＵＥは、ＲＲＣ再設定によって提供されたＭＢＳ設定を引き続き適用する。ＵＥは元々ＲＲＣコネクティッド用に提供されたＭＢＳ設定を再利用するだけなので、このオプションは単純である。しかし、アイドル／インアクティブに遷移する場合及び／又はＲＲＣコネクティッドをレジュームする場合に、例えば、設定されている場合はＰＴＰ／ＰＴＭスプリットベアラ設定を処理する方法など、いくつかのＵＥの動作を検討する必要がある可能性がある。

・オプション２：ＲＲＣ解放
アイドル／インアクティブのＵＥは、ＲＲＣ解放によって提供されるＭＢＳ設定を適用する。このオプションは明快であるが、ＭＢＳ設定が以前にＲＲＣ再設定によって提供されたものと異なるかどうかは疑わしいため、効率的ではない可能性がある。

・オプション３：モード１からモード２への配信モードの切り替え
ＵＥは、アイドル／インアクティブに解放される前に、配信モード１から配信モード２に切り替えられる。配信モード２は、ＲＡＮ２が合意したように、すべてのＲＲＣ状態でデータを受信できるように設計されているため、このオプションはもう１つの簡単な解決策である。しかし、例えば、ＭＣＣＨの取得が原因で、スイッチング中にパケット損失及び／又は遅延が発生することが予想される可能性がある。

各オプションには長所及び短所があるが、私たちの見解では、単純さ及び効率の観点から、オプション１の方がわずかに望ましい。ＲＡＮ２は、上記のオプションを考慮するがこれに限定されず、アイドル／インアクティブでデータ受信用の配信モード１設定を提供する方法について議論すべきである。

提案４：提案３に合意できる場合、ＲＡＮ２は、インアクティブでのデータ受信のための配信モード１設定がＵＥにどのように提供されるかについて議論すべきである。

（配信モード２設定）
ＬＴＥ ＳＣ－ＰＴＭにおいて、設定は２つのメッセージ、即ち、ＳＩＢ２０及びＳＣ－ＭＣＣＨによって提供される。ＳＩＢ２０は、ＳＣ－ＭＣＣＨスケジューリング情報を提供し、ＳＣ－ＭＣＣＨは、Ｇ－ＲＮＴＩ及びＴＭＧＩを含むＳＣ－ＭＴＣＨスケジューリング情報、及び隣接セル情報を提供する。

図１８に示すようなＬＴＥの２段階設定の利点は、ＳＣ－ＭＣＣＨスケジューリングが、繰り返し期間、期間、変更期間などの観点でＳＩＢ２０スケジューリングから独立していることであった。特に、セッションに遅れて参加する、遅延にセンシティブなサービス及び／又はＵＥに対して、ＳＣ－ＭＣＣＨの頻繁なスケジューリング／更新が容易にした。ＷＩＤによると、アプリケーションの１つがグループ通信などであるため、ＮＲ ＭＢＳでも同様である。

所見１：ＬＴＥでは、ＳＩＢ２０及びＳＣ－ＭＣＣＨを使用した２段階設定が、これらの制御チャネルの異なるスケジューリングに役立つ。これは、ＮＲ ＭＢＳにも役立つ。

提案５：ＲＡＮ２は、ＳＣ－ＰＴＭのＳＩＢ２０及びＳＣ－ＭＣＣＨなど、ＮＲ ＭＢＳのメッセージが異なる２段階設定を使用することに合意すべきである。

提案５に加えて、ＮＲ ＭＢＳは、ＷＩＤに記載されている様々なタイプのユースケースをサポートすることが想定される。ＮＲ ＭＢＳは、ソフトウェア配信などのロスレスアプリケーションからＩＰＴＶなどのＵＤＰタイプのストリーミングまでの要件の他の側面に加えて、ミッションクリティカルやＶ２Ｘなどの遅延にセンシティブなアプリケーションから、ＩｏＴなどの遅延に寛容なアプリケーションまで、様々な要件に合わせて適切に設計すべきであることは気づかれる。これらのサービスの一部は配信モード２でカバーされる可能性があるが、「高いＱｏＳ要件」を持つ他のサービスには配信モード１が必要である。この意味で、ｇＮＢにとって、マルチキャストセッションに配信モード２を使用することを選択できることは有益である。

また、ＲＡＮ２はＲＲＣコネクティッドでのデータ受信を許可することにすでに合意しているため、ＲＲＣコネクティッドのＵＥがＭＢＳ設定を受信できるようにするのは簡単である。ＵＥがＭＣＣＨを取得するためだけにアイドル／インアクティブに遷移する必要がある場合、意味がない。コネクティッドのＵＥがＭＣＣＨを受信できるようにするのは簡単であるが、スケジューリングの柔軟性（ＵＥには「ギャップ」が必要な場合があるため）及び／又はＵＥの消費電力（ＵＥはＣ－ＲＮＴＩ及びＧ－ＲＮＴＩに加えて「ＳＣ－ＲＮＴＩ」を監視する必要があるため）の点で最適ではない可能性がある。したがって、ＵＥがＭＣＣＨまたはＲＲＣ再設定を介してＭＢＳ設定を受信するかについては、さらに議論が必要になる可能性がある。

これらの２つの課題は残されたままであったが、一般に、私たちの観点からそれらを制限する技術的な理由はないようである。

提案６：ＲＡＮ２は、ブロードキャストセッションに加えて、配信モード２をマルチキャストセッションに使用できることに合意すべきである。

提案７：配信モード２において、ＲＡＮ２は、ＭＢＳ設定がＲＲＣコネクティッドのＵＥでも受信できることに合意すべきである。ＭＣＣＨかＲＲＣ再設定かは、更なる検討が必要である。

提案６に照らして、配信モード２の制御チャネル設計は、柔軟性及びそのリソース効率を考慮すべきである。そうしないと、例えば、遅延に寛容なサービスと遅延にセンシティブなサービスとが１つの制御チャネルで一緒に設定されている場合に、遅延にセンシティブなサービスからの遅延要件を満たすために、制御チャネルを頻繁にスケジュールする必要があるため、より多くのシグナリングオーバーヘッドが発生する可能性がある。

ＳＡ２ ＳＩの目的Ａは、５ＧＳを介した一般的なＭＢＳサービスを可能にすることに関するものであり、この機能の恩恵を受ける可能性のある特定されたユースケースには、公共安全、ミッションクリティカル、Ｖ２Ｘアプリケーション、透過的なＩＰｖ４／ＩＰｖ６マルチキャスト配信、ＩＰＴＶ、無線を介したソフトウェア配信、グループ通信、及びＩｏＴアプリケーションが含まれる（但し、これらに限定されない）。

所見２：配信モード２のためのＮＲ ＭＢＳ制御チャネルは、様々なタイプのユースケースに対して柔軟でリソース効率が必要とされる。

一つの可能性として、図１９に示すように、異なるユースケースで設定チャネルを分離する必要があるかどうか検討することである。例えば、一つのＭＣＣＨは遅延にセンシティブなサービスを頻繁に提供し、別のＭＣＣＨは遅延に寛容なサービスをまばらに提供する。ＬＴＥ ＳＣ－ＰＴＭでは、１つのセルは１つのＳＣ－ＭＣＣＨしか有せないという制限があった。しかしながら、ＬＴＥよりも多くのユースケースが想定されることを考慮すると、ＮＲ ＭＢＳの配信モード２はそのような制限を取り除くべきである。セル内で複数のＭＣＣＨが許可されている場合、各ＭＣＣＨには、特定のサービス用に最適化可能な、繰り返し期間などの異なるスケジューリング設定がある。ＵＥが興味のあるサービスを提供するＭＣＣＨをどのように識別するかは更なる検討が必要である。

提案８：配信モード２において、ＲＡＮ２は、ＬＴＥになかった、セルで複数のＭＣＣＨがサポートされるかどうかを議論すべきである。

さらに、ＮＲの新しいパラダイムは、オンデマンドＳＩ送信のサポートである。この概念は、配信モード２におけるＭＣＣＨ、即ち、オンデマンドＭＣＣＨに再利用され得る。例えば、遅延に寛容なサービス用のＭＣＣＨはオンデマンドで提供されるため、シグナリングのリソース消費を最適化可能である。言うまでもなく、ネットワークには、ＭＣＣＨを定期的に、即ち、オンデマンドではなく、遅延にセンシティブなサービスなどに提供するための別のオプションがある。

提案９：配信モード２において、ＲＡＮ２は、ＬＴＥになかった、ＭＣＣＨがオンデマンドベースで提供される場合のオプションについて議論すべきである。

別の可能性として、図１９に示すように、これらのメッセージをマージすること、即ち、１段階設定をさらに検討され得る。例えば、ＳＩＢは、ＭＴＣＨスケジューリング情報を直接、即ち、ＭＣＣＨなしで、提供する。これは、遅延に寛容なサービス及び／又は電力にセンシティブなＵＥのための最適化を提供するであろう。例えば、ＵＥは、ＳＩＢ（オンデマンド）を要求してもよく、ｇＮＢは、複数のＵＥからの要求の後に、ＳＩＢ及び対応するサービスの提供を開始してもよい。これらのＵＥは、繰り返しブロードキャストされるＭＣＣＨを監視する必要がない。

提案１０：配信モード２において、ＲＡＮ２は、ＭＣＣＨを使用しないマルチキャスト受信（即ち、１段階設定）がサポートされている場合、ＳＩＢがＭＴＣＨスケジューリング情報を直接提供するなどのオプションについて議論すべきである。

（興味のインディケーション／カウンティング）
ＬＴＥ ｅＭＢＭＳでは、ネットワークがＭＢＭＳセッションの開始／停止を含むＭＢＭＳデータ配信の適切な決定をするために、ＵＥの受信／興味サービスを収集する２種類の方法、つまりＭＢＭＳ興味インディケーション（ＭＩＩ）とＭＢＭＳカウンティングが指定された。ＵＥによってトリガされるＭＩＩには、興味を持つＭＢＭＳ周波数、興味を持つＭＢＭＳサービス、ＭＢＭＳ優先度、およびＭＢＭＳ ＲＯＭ（受信専用モード）に関連する情報が含まれている。特定のＭＢＭＳサービスのカウンティング要求を介してネットワークによってトリガされるカウンティング応答には、興味を持つＭＢＳＦＮエリアおよびＭＢＭＳサービスに関連する情報が含まれている。

これらのメソッドは、さまざまな目的で導入された。ＭＩＩはＵＥがコネクティッド状態の間に興味を持つサービスを引き続き受信できることを保証するため主にネットワークに使用されている。一方、カウンティングは、ネットワークが十分な数のＵＥがサービスの受信に興味を持っているかどうかを判断できるようにするために使用される。

所見３：ＬＴＥ ｅ ＭＢＭＳでは、２種類のＵＥアシスタンス情報が異なる目的で導入される。即ち、ＮＢのスケジューリングのためにＭＢＭＳ興味インディケーションが導入され、ＭＣＥのセッション制御のためにＭＢＭＳカウンティングが導入される。

ＮＲ ＭＢＳの場合、グループ通信のユースケースなどのマルチキャストサービスが予想され、ネットワークには、コネクティッド状態のＵＥが受信／興味を持っているＭＢＳサービスに関する完全な知識が既にあるため、例えば、ネットワークのＰＴＰ／ＰＴＭ配信の決定など、ＵＥからのアシスタンス情報はネットワークの役に立たない。ただし、私たちの理解では、同じことは、ブロードキャストサービス及び／又はアイドル／インアクティブ状態のＵＥには当てはまらない。特にブロードキャストサービスの場合、ＬＴＥ ｅＭＢＭＳにおいてＭＩＩとのカウンティングによって解決された問題、つまり所見３がＮＲ ＭＢＳにまだ存在する。したがって、ＲＡＮ２は、ＭＩＩやカウンティングなどのアシスタンス情報がＮＲ ＭＢＳに役立つかどうかについて検討する必要がある。

ＷＩＤに記載されているようにＲＯＭとＳＦＮとはサポートされていないため、Ｒｅｌ－１７ではＭＩＩのＭＢＭＳ ＲＯＭ情報とカウンティング応答のＭＢＳＦＮエリアに関する情報とは必要ないことに注意する。

提案１１：ＲＡＮ２は、たとえば、ＭＢＳ興味インディケーション及び／又はＭＢＳカウンティングなど、ＮＲ ＭＢＳのＵＥアシスタンス情報を導入することに同意する必要がある。

提案１１に同意できる場合は、ＬＴＥ ｅＭＢＭＳに加えて拡張機能を検討する価値がある。ＬＴＥ ｅＭＢＭＳでは、ＵＥの大部分がＲＲＣアイドル状態でブロードキャストサービスを受信している場合でも、ＭＩＩもカウンティングもアイドル状態のＵＥから情報を収集できない。これは、私たちの理解では、セッション制御及びリソース効率の観点から見たＬＴＥ ｅＭＢＭＳの残りの問題の１つである。

ＮＲ ＭＢＳでは、アイドル／インアクティブ状態のＵＥにも同じ問題が存在する可能性がある。たとえば、ネットワークは、アイドル／インアクティブ状態のＵＥがブロードキャストサービスを受信／興味を持っていないかどうかが分からない。したがって、サービスを受けているＵＥがなくても、ネットワークは、ＰＴＭ送信を提供し続ける可能性がある。ｇＮＢがアイドル／インアクティブ状態のＵＥの興味を認識している場合、このような不要なＰＴＭは回避されるべきである。逆に、サービスを受信しているアイドル／インアクティブ状態のＵＥがまだ存在するときにＰＴＭが停止すると、多くのＵＥが同時に接続を要求する可能性がある。これも望ましくない。

したがって、アイドル／インアクティブ状態のＵＥから、具体的にはＭＢＭＳカウンティングの、ＵＥアシスタンス情報を収集するメカニズムを導入するかどうかを検討する価値がある。言うまでもなく、アイドル／インアクティブ状態のＵＥは、ＲＲＣコネクティッドに遷移せずに情報を報告できることが望ましい。たとえば、ＭＢＳサービスに関連付けられたＰＲＡＣＨリソースパーティショニングがそのようなレポートに導入された場合に達成される可能性がある。

提案１２：ＲＡＮ２は、ＭＢＳカウンティングなどのＵＥアシスタンス情報もアイドル／インアクティブ状態のＵＥから収集されるかどうかを検討する必要がある。

Claims (6)

1. マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信制御方法であって、
   ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にある前記ユーザ装置が、ＭＢＳ受信に必要なＭＢＳ設定を含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを基地局から受信することと、
   前記ユーザ装置が、前記ＲＲＣコネクティッド状態時に受信した前記ＭＢＳ設定をＲＲＣインアクティブ状態において使用可能とするか否かを示す情報を含むＲＲＣ Ｒｅｌｅａｓｅメッセージを前記基地局から受信することと、を有する
   通信制御方法。
2. ユーザ装置であって、
   前記ユーザ装置がＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にあるときに、マルチキャスト・ブロードキャストサービス（ＭＢＳ）受信に必要なＭＢＳ設定を含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを基地局から受信する受信部を備え、
   前記受信部は、前記ＲＲＣコネクティッド状態時に受信した前記ＭＢＳ設定をＲＲＣインアクティブ状態において使用可能とするか否かを示す情報を含むＲＲＣ Ｒｅｌｅａｓｅメッセージを、前記基地局から受信する
   ユーザ装置。
3. ユーザ装置を制御するためのチップセットであって、
   前記ユーザ装置がＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にあるときに、マルチキャスト・ブロードキャストサービス（ＭＢＳ）受信に必要なＭＢＳ設定を含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを基地局から受信する処理と、
   前記ＲＲＣコネクティッド状態時に受信した前記ＭＢＳ設定をＲＲＣインアクティブ状態において使用可能とするか否かを示す情報を含むＲＲＣ Ｒｅｌｅａｓｅメッセージを、前記基地局から受信する処理と、を実行する
   チップセット。
4. ユーザ装置を制御するためのプログラムであって、
   前記ユーザ装置がＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にあるときに、マルチキャスト・ブロードキャストサービス（ＭＢＳ）受信に必要なＭＢＳ設定を含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを基地局から受信する処理と、
   前記ＲＲＣコネクティッド状態時に受信した前記ＭＢＳ設定をＲＲＣインアクティブ状態において使用可能とするか否かを示す情報を含むＲＲＣ Ｒｅｌｅａｓｅメッセージを、前記基地局から受信する処理と、を前記ユーザ装置に実行させる
   プログラム。
5. 基地局であって、
   ユーザ装置がＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）コネクティッド状態にあるときに、マルチキャスト・ブロードキャストサービス（ＭＢＳ）受信に必要なＭＢＳ設定を含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを前記ユーザ装置に送信する送信部を備え、
   前記送信部は、前記ＲＲＣコネクティッド状態時に受信した前記ＭＢＳ設定をＲＲＣインアクティブ状態において使用可能とするか否かを示す情報を含むＲＲＣ Ｒｅｌｅａｓｅメッセージを、前記ユーザ装置に送信する
   基地局。
6. 請求項２に記載のユーザ装置及び基地局を備えるシステム。

Images