JP7728348B2 - 通信方法、ユーザ装置 - Google Patents

Description

本開示は、移動通信システムで用いる通信方法に関する。

３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）規格において、第５世代（５Ｇ）の無線アクセス技術であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）の技術仕様が規定されている。ＮＲは、第４世代（４Ｇ）の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。３ＧＰＰにおいて、５Ｇ／ＮＲのマルチキャストブロードキャストサービス（ＭＢＳ）の技術仕様を策定する議論が行われている（例えば、非特許文献１参照）。

３ＧＰＰ寄書：ＲＰ－２０１０３８、"ＷＩＤ ｒｅｖｉｓｉｏｎ： ＮＲ Ｍｕｌｔｉｃａｓｔ ａｎｄ Ｂｒｏａｄｃａｓｔ Ｓｅｒｖｉｃｅｓ"

第１の態様に係る通信方法は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置で用いる通信方法であって、Ｎ個（Ｎ≧２）のグループＲＮＴＩ（Ｇ－ＲＮＴＩ）が１つのマルチキャストブロードキャストサービス（ＭＢＳ）セッションと対応付けられている場合、前記Ｎ個のＧ－ＲＮＴＩの中から前記受信処理に用いるＭ個（Ｍ≦Ｎ）のＧ－ＲＮＴＩを特定することと、前記Ｍ個のＧ－ＲＮＴＩを用いて前記受信処理を行うことと、を有する。

第２の態様に係る通信方法は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置で用いる通信方法であって、セルＲＮＴＩ（Ｃ－ＲＮＴＩ）を用いて、専用トラフィックチャネル（ＤＴＣＨ）を受信するための前記受信処理を行うことと、グループＲＮＴＩ（Ｇ－ＲＮＴＩ）を用いて、マルチキャストトラフィックチャネル（ＭＴＣＨ）を受信するための前記受信処理を行うことと、前記ＤＴＣＨ及び前記ＭＴＣＨに同一の論理チャネル識別子（ＬＣＩＤ）が割り当てられている場合、前記受信処理に応じて得られた受信データが属する論理チャネルを、当該受信処理に用いたＲＮＴＩに基づいて特定することと、を有する。

第３の態様に係る通信方法は、移動通信システムで用いる通信方法であって、基地局が、マルチキャストトラフィックチャネル（ＭＴＣＨ）の受信に用いる設定情報をマルチキャスト制御チャネル（ＭＣＣＨ）上で送信することと、前記基地局が、前記ＭＣＣＨの内容変更に関する通知を、所定タイミングにおいて物理下りリンク制御チャネル（ＰＤＣＣＨ）上でユーザ装置に送信することと、を有する。前記送信することは、前記変更が無い場合、前記変更が無いことを示す前記通知を送信することを含む。

第１実施形態に係る移動通信システムの構成を示す図である。 第１実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 第１実施形態に係るｇＮＢ（基地局）の構成を示す図である。 データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 第１実施形態に係るＭＢＳトラフィック配信の概要を示す図である。 第１実施形態に係る配信モードを示す図である。 第１実施形態に係るスプリット・マルチキャスト無線ベアラ（ＭＲＢ）を示す図である。 グループＲＮＴＩ（Ｇ－ＲＮＴＩ）とＭＢＳセッションとの対応関係（マッピング）を示す図である。 Ｇ－ＲＮＴＩと、マルチキャスト無線ベアラ（ＭＲＢ）／マルチキャストトラフィックチャネル（ＭＴＣＨ）と、サービス品質（ＱｏＳ）フローと、ＭＢＳセッションとの対応関係（マッピング）を示す図である。 第１実施形態に係る動作の一例を示す図である。 第２実施形態に係るＵＥの内部処理を示す図である。 第２実施形態に係る動作の一例を示す図である。 第２実施形態の変更例に係るＵＥの内部処理を示す図である。 第３実施形態に係る動作の一例を示す図である。 第３実施形態に係る動作の変更例を示す図である。 配信モードのステージ２コントロールプレーンの側面の概要を示す図である。 配信モード２のワンステップ設定を示す図である。 ＬＴＥのＭＢＭＳ興味インディケーション（ＲＯＭ関連の設定を除く）を示す図である。 ＬＴＥのＳＩＢ１３の内容を示す図である。 ＬＴＥのＳＩＢ１３の内容を示す図である。 ＬＴＥのＳＩＢ１３の内容を示す図である。 ＬＴＥのＳＩＢ１５の内容を示す図である。 ＬＴＥのＳＩＢ２０の内容を示す図である。 ＬＴＥのＳＣ－ＭＣＣＨの内容を示す図である。 ＬＴＥのＳＣ－ＭＣＣＨの内容を示す図である。 ＬＴＥのＳＣ－ＭＣＣＨの内容を示す図である。 ＬＴＥにおけるＭＢＭＳ興味インディケーションの内容を示す図である。 ＬＴＥにおけるＭＢＭＳ興味インディケーションの内容を示す図である。 ＬＴＥにおけるＭＢＭＳ興味インディケーションの内容を示す図である。 ＬＴＥでのｅＭＢＭＳ周波数のセル再選択の優先順位を示す図である。 イントラ周波数におけるセルレベルの優先順位付けと、ＣＥ（ｅＭＴＣを含む）におけるＮＢ－ＩｏＴ及びＵＥのＬＴＥでの同等の優先度のイントラ周波数セル再選択を示す図である。 ＱｏｆｆｓｅｔＳＣＰＴＭがＳＩＢ５でＳＣＰＴＭ周波数オフセットとして設定される例を示す図である。 ＬＴＥ ＳＣ－ＰＴＭにおけるＵＥ機能ｓｃｐｔｍ－ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎ－ｒ１３を示す図である。 配信モード１を介したＰＴＭ送信のＤＲＸパラメータを示す図である。 配信モード２を介したＰＴＭ送信のＤＲＸパラメータを示す図である。

５Ｇ／ＮＲのマルチキャストブロードキャストサービスは、４Ｇ／ＬＴＥのマルチキャストブロードキャストサービスよりも改善されたサービスを提供することが望まれる。

そこで、本開示は、改善されたマルチキャストブロードキャストサービスを実現可能とする通信方法を提供する。

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

［第１実施形態］

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

移動通信システム１は、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ Ｃｏｒｅ Ｎｅｔｗｏｒｋ）２０とを有する。以下において、ＮＧ－ＲＡＮ１０を単にＲＡＮ１０と呼ぶことがある。また、５ＧＣ２０を単にコアネットワーク（ＣＮ）２０と呼ぶことがある。

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

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

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

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

図２は、第１実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。受信部１１０及び送信部１２０は、ｇＮＢ２００との無線通信を行う無線通信部を構成する。

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

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

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

図３は、第１実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。送信部２１０及び受信部２２０は、ＵＥ１００との無線通信を行う無線通信部を構成する。バックホール通信部２４０は、ＣＮ２０との通信を行うネットワーク通信部を構成する。

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

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

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

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

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

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

ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。なお、ＵＥ１００のＰＨＹレイヤは、ｇＮＢ２００から物理下りリンク制御チャネル（ＰＤＣＣＨ）上で送信される下りリンク制御情報（ＤＣＩ）を受信する。具体的には、ＵＥ１００は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いてＰＤＣＣＨのブラインド復号を行い、復号に成功したＤＣＩを自ＵＥ宛てのＤＣＩとして取得する。ｇＮＢ２００から送信されるＤＣＩには、ＲＮＴＩによってスクランブルされたＣＲＣパリティビットが付加されている。

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

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

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

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

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

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

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

ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００ＡのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。また、ＮＡＳレイヤよりも下位のレイヤをＡＳレイヤと呼ぶ。

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

ブロードキャストサービスは、高信頼性のＱｏＳを必要としないアプリケーションのために、特定のサービスエリア内のすべてのＵＥ１００に対してサービスを提供する。ブロードキャストサービスに用いるＭＢＳセッションをブロードキャストセッションと呼ぶ。

マルチキャストサービスは、すべてのＵＥ１００に対してではなく、マルチキャストサービス（マルチキャストセッション）に参加しているＵＥ１００のグループに対してサービスを提供する。マルチキャストサービスに用いるＭＢＳセッションをマルチキャストセッションと呼ぶ。マルチキャストサービスによれば、ブロードキャストサービスに比べて、無線効率の高い方法でＵＥ１００のグループに対して同じコンテンツを提供できる。

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

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

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

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

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

ＲＡＮ（５Ｇ ＲＡＮ）１０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信方法における無線を介したＭＢＳデータの送信には、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）の２つの配信方法が可能である。ＰＴＰはユニキャストを意味し、ＰＴＭはマルチキャスト及びブロードキャストを意味する。

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

ＰＴＰ配信方法及びＰＴＭ配信方法は主としてユーザプレーンに関するものである。ＭＢＳデータ配信の制御モードとしては、第１配信モード及び第２配信モードの２つの配信モードがある。

図７は、第１実施形態に係る配信モードを示す図である。

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

第１配信モードにおけるＭＢＳ受信の設定は、ＵＥ固有（ＵＥ－ｄｅｄｉｃａｔｅｄ）シグナリングにより行われる。例えば、第１配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にユニキャストで送信されるＲＲＣメッセージであるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（又はＲＲＣ Ｒｅｌｅａｓｅメッセージ）により行われる。

ＭＢＳ受信の設定は、ＭＢＳデータを運ぶＭＢＳトラフィックチャネルの設定に関するＭＢＳトラフィックチャネル設定情報（以下、「ＭＴＣＨ設定情報」と呼ぶ）を含む。ＭＴＣＨ設定情報は、ＭＢＳセッションに関するＭＢＳセッション情報と、このＭＢＳセッションに対応するＭＢＳトラフィックチャネルのスケジューリング情報とを含む。ＭＢＳトラフィックチャネルのスケジューリング情報は、ＭＢＳトラフィックチャネルの間欠受信（ＤＲＸ）設定を含んでもよい。間欠受信設定は、オン期間（Ｏｎ Ｄｕｒａｔｉｏｎ：受信期間）を定義するタイマ値（Ｏｎ Ｄｕｒａｔｉｏｎ Ｔｉｍｅｒ）、オン期間を延長するタイマ値（Ｉｎａｃｔｉｖｉｔｙ Ｔｉｍｅｒ）、スケジューリング間隔もしくはＤＲＸサイクル（Ｓｃｈｅｄｕｌｉｎｇ Ｐｅｒｉｏｄ、ＤＲＸ Ｃｙｃｌｅ）、スケジューリングもしくはＤＲＸサイクルの開始サブフレームのオフセット値（Ｓｔａｒｔ Ｏｆｆｓｅｔ、ＤＲＸ Ｃｙｃｌｅ Ｏｆｆｅｓｔ）、オン期間タイマの開始遅延スロット値（Ｓｌｏｔ Ｏｆｆｓｅｔ）、再送時までの最大時間を定義するタイマ値（Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅｒ）、ＨＡＲＱ再送のＤＬ割り当てまでの最小間隔を定義するタイマ値（ＨＡＲＱ ＲＴＴ Ｔｉｍｅｒ）のいずれか一つ以上のパラメータを含んでもよい。

なお、ＭＢＳトラフィックチャネルは論理チャネルの一種であって、ＭＴＣＨと呼ばれることがある。ＭＢＳトラフィックチャネルは、トランスポートチャネルの一種である下りリンク共有チャネル（ＤＬ－ＳＣＨ）にマッピングされる。

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

第２配信モードにおけるＭＢＳ受信の設定は、ブロードキャストシグナリングにより行われる。例えば、第２配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にブロードキャストで送信される論理チャネル、例えば、ブロードキャスト制御チャネル（ＢＣＣＨ）及び／又はマルチキャスト制御チャネル（ＭＣＣＨ）により行われる。ＵＥ１００は、例えば、技術仕様で予め規定された専用のＲＮＴＩを用いてＢＣＣＨ及びＭＣＣＨを受信できる。ＢＣＣＨ受信用のＲＮＴＩがＳＩ－ＲＮＴＩであって、ＭＣＣＨ受信用のＲＮＴＩがＭＣＣＨ－ＲＮＴＩであってもよい。

第２配信モードにおいて、ＵＥ１００は、次の３つの手順でＭＢＳデータを受信してもよい。第１に、ＵＥ１００は、ｇＮＢ２００からＢＣＣＨ上で伝送されるＳＩＢ（ＭＢＳ－ＳＩＢ）によりＭＣＣＨ設定情報を受信する。第２に、ＵＥ１００は、ＭＣＣＨ設定情報に基づいてｇＮＢ２００からＭＣＣＨを受信する。ＭＣＣＨは、ＭＴＣＨ設定情報を伝送する。第３に、ＵＥ１００は、ＭＴＣＨ設定情報に基づいて、ＭＴＣＨ（ＭＢＳデータ）を受信する。以下において、ＭＴＣＨ設定情報及び／又はＭＣＣＨ設定情報をＭＢＳ受信設定と呼ぶことがある。

第１配信モード及び第２配信モードにおいて、ＵＥ１００は、ｇＮＢ２００から割り当てられるグループＲＮＴＩ（Ｇ－ＲＮＴＩ）を用いてＭＴＣＨを受信してもよい。Ｇ－ＲＮＴＩは、ＭＴＣＨ受信用ＲＮＴＩに相当する。Ｇ－ＲＮＴＩは、ＭＢＳ受信設定（ＭＴＣＨ設定情報）に含まれていてもよい。

なお、ネットワークは、ＭＢＳセッションごとに異なるＭＢＳサービスを提供できる。ＭＢＳセッションは、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ）、ソーススペシフィックＩＰマルチキャストアドレス（アプリケーション機能やアプリケーションサーバ等のソースユニキャストＩＰアドレスと、宛先アドレスを示すＩＰマルチキャストアドレスとから成る）、セッション識別子、及びＧ－ＲＮＴＩのうち少なくとも１つにより識別される。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、及びセッション識別子の少なくとも１つをＭＢＳセッション識別子と呼ぶ。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、セッション識別子、及びＧ－ＲＮＴＩを総括してＭＢＳセッション情報と呼ぶ。

図８は、第１実施形態に係るスプリット・マルチキャスト無線ベアラ（ＭＲＢ）を示す図である。ＭＲＢは、データ無線ベアラ（ＤＲＢ）の一種であってもよい。スプリットＭＲＢは、上述の第１配信モードで用いられてもよい。

ｇＮＢ２００は、ＰＴＰ通信パス及びＰＴＭ通信パスに分離されたＭＲＢをＵＥ１００に設定し得る。これにより、ｇＮＢ２００は、ＵＥ１００に対するＭＢＳデータの送信をＰＴＰ（ＰＴＰ通信パス）とＰＴＭ（ＰＴＭ通信パス）との間で動的に切り替えることができる。或いは、ｇＮＢ２００は、ＰＴＰ（ＰＴＰ通信パス）及びＰＴＭ（ＰＴＭ通信パス）を併用して同一のＭＢＳデータを二重送信することにより信頼性を高めることができる。以下において、ＰＴＰ通信パスをＰＴＰレグと呼び、ＰＴＭ通信パスをＰＴＭレグと呼ぶ。また、各レイヤに相当する機能部をエンティティと呼ぶ。

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

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

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

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

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

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

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

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

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

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

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

（移動通信システムの動作）
第１実施形態に係る移動通信システム１の動作について説明する。

図９は、グループＲＮＴＩ（Ｇ－ＲＮＴＩ）とＭＢＳセッションとの対応関係（マッピング）を示す図である。Ｇ－ＲＮＴＩは、Ｇ－ＣＳ（Ｃｏｎｆｉｇｕｒｅｄ Ｓｃｈｅｄｕｌｉｎｇ）－ＲＮＴＩであってもよい。以下において、Ｇ－ＲＮＴＩはＧ－ＣＳ－ＲＮＴＩと読み替えられてもよい。例えば２個のＧ－ＲＮＴＩは、１個のＧ－ＲＮＴＩと１個のＧ－ＣＳ－ＲＮＴＩとで構成されてもよい。なお、Ｇ－ＣＳ－ＲＮＴＩは、一定周期で同じ無線リソースの割り当てを行うＣｏｎｆｉｇｕｒｅｄ Ｓｃｈｅｄｕｌｉｎｇに用いるＧ－ＲＮＴＩであって、複数のＵＥに対してＲＲＣで設定された周期（ｐｅｒｉｏｄｉｃｉｔｙ）で、Ｇ－ＣＳ－ＲＮＴＩで指定された無線リソースが割り当てられる。

Ｇ－ＲＮＴＩとＭＢＳセッションとのマッピングには、１つのＧ－ＲＮＴＩと１つのＭＢＳセッションとが対応付けられる「１：１マッピング」と、１つのＧ－ＲＮＴＩとＮ個（Ｎ≧２）のＭＢＳセッションとが対応付けられる「１：Ｎマッピング」と、Ｎ個のＧ－ＲＮＴＩと１つのＭＢＳセッションとが対応付けられる「Ｎ：１マッピング」と、がある。第１実施形態において、Ｎ：１マッピングが用いられる場合を主として想定する。

図１０は、Ｇ－ＲＮＴＩと、マルチキャスト無線ベアラ（ＭＲＢ）／マルチキャストトラフィックチャネル（ＭＴＣＨ）と、サービス品質（ＱｏＳ）フローと、ＭＢＳセッションとの対応関係（マッピング）を示す図である。１つのＭＢＳセッションに複数本のＱｏＳフローが対応付けられる場合と、１つのＧ－ＲＮＴＩに複数本のＱｏＳフローが対応付けられる場合とがある。ＱｏＳフローとＭＲＢ／ＭＴＣＨとは１：１の関係にあってもよい。

Ｎ：１マッピングにおいて、１つのＭＢＳセッション（例えば、１つのＭＢＳアプリケーション）に複数本のＱｏＳフローが対応付けられる場合、ＱｏＳフローごとに異なる設定（例えば、ＱｏＳフローごとに異なるＭＴＣＨ設定）でＭＢＳデータを送受信できる。例えば、ビデオ会議アプリケーションを用いたグループ通信を考えた場合、ＱｏＳフロー＃１はビデオ及びＱｏＳフロー＃２はテキストメッセージ（チャット）をそれぞれ流しているというシナリオが想定される。そのようなシナリオにおいて、例えば以下のような設定でデータ送受信を行うことが最適と考えられる。

ＱｏＳフロー＃１：ＲＬＣ ＵＭ、ＤＲＸサイクル＝ショート
ＱｏＳフロー＃２：ＲＬＣ ＡＭ、ＤＲＸサイクル＝ロング

ここで、“＃1”及び“＃２”はＱｏＳフローの識別子であり、“ＲＬＣ ＵＭ”はＲＬＣのモードが非確認モード（ＵＭ）であることを意味し、“ＲＬＣ ＡＭ”はＲＬＣのモードが確認モード（ＡＭ）であることを意味する。ＤＲＸサイクルは、間欠受信におけるＵＥ１００がウェイクアップする周期を意味する。

このような設定を用いる場合において、ＵＥ１００は、１つのＭＢＳセッションについて２つのＤＲＸサイクルがあるため、ある一定期間内に２回ウェイクアップしなければならず、ＵＥ１００の受信効率（消費電力）の点で好ましくない。第１実施形態は、１つのＭＢＳセッションと対応付けられた複数本のＱｏＳフローのうち一部のＱｏＳフローについてのみ受信することを可能とする実施形態である。

第１実施形態に係る通信方法は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いてｇＮＢ２００からのＰＤＣＣＨの受信処理（以下、「ＰＤＣＣＨ受信処理」と呼ぶ）を行うＵＥ１００で用いる方法である。当該通信方法は、Ｎ個（Ｎ≧２）のＧ－ＲＮＴＩが１つのＭＢＳセッションと対応付けられている場合、Ｎ個のＧ－ＲＮＴＩの中からＰＤＣＣＨ受信処理に用いるＭ個（Ｍ＜Ｎ）のＧ－ＲＮＴＩを特定するステップと、Ｍ個のＧ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行うステップと、を有する（但し、ＭはＮと等しい値になり得る）。例えば、ＵＥ１００は、ＭＢＳセッションの受信において、Ｎ個のＧ－ＲＮＴＩのうち（Ｎ－Ｍ）個のＧ－ＲＮＴＩをＰＤＣＣＨ受信処理に用いることなく、Ｍ個のＧ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行う。これにより、Ｍ＜Ｎの場合、ＵＥ１００は、１つのＭＢＳセッションと対応付けられた複数本のＱｏＳフローのうち一部のＱｏＳフローについてのみ受信を行うことが可能である。

なお、ＰＤＣＣＨ受信処理とは、ＵＥ１００が、ＲＮＴＩを用いてＰＤＣＣＨ（ＤＣＩ）のブラインド復号を行ってＤＣＩに付与されたＣＲＣパリティビットを用いたＣＲＣチェックを行う処理をいい、ＰＤＣＣＨの監視（モニタ）処理と呼ばれてもよい。

ＵＥ１００がウェイクアップするタイミングは、ＰＤＣＣＨ受信処理に用いるＭ個のＧ－ＲＮＴＩと対応付けられたＭＴＣＨ設定により定められてもよい。すなわち、ＵＥ１００は、（Ｎ－Ｍ）個のＧ－ＲＮＴＩと対応付けられたＭＴＣＨ設定を適用しなくてもよいため、当該ＭＴＣＨ設定に応じてウェイクアップしなくてもよい。これにより、ＵＥ１００の消費電力が削減される。

ＵＥ１００は、１つのＭＢＳセッションと対応付けられたＫ本（Ｋ≧２）のＱｏＳフローの中から、自身が受信を希望する所望のＱｏＳフローを特定し、所望のＱｏＳフローと対応付けられたＭ個のＧ－ＲＮＴＩを特定してもよい。所望のＱｏＳフローは、ＵＥ１００の上位レイヤ、例えば、アプリケーションレイヤ及び／又はＮＡＳレイヤにより決定されてもよい。

ＵＥ１００は、１つのＭＢＳセッションとＫ本のＱｏＳフローとＮ個のＧ－ＲＮＴＩとを対応付ける情報（マッピング情報）をｇＮＢ２００から受信してもよい。これにより、ＵＥ１００は、ＭＢＳセッションとＱｏＳフローとＧ－ＲＮＴＩとの対応関係（マッピング）を明確（具体的）に把握できる。

ＵＥ１００は、ＭＢＳセッション（ＵＥ１００が受信している又は受信に興味のあるＭＢＳセッション）の識別子と、当該ＭＢＳセッションに属する所望のＱｏＳフローに関する識別子とを含むメッセージをｇＮＢ２００に送信してもよい。これにより、ｇＮＢ２００は、ＵＥ１００がどのＭＢＳセッションのどのＱｏＳフローの受信を希望しているか、すなわち、どのＱｏＳフローを受信しているか（又は受信に興味があるのか）を把握できる。これにより、ｇＮＢ２００は、例えば、ＵＥ１００が受信を希望するＱｏＳフローと対応付けられたＭＲＢ／ＭＴＣＨのスケジューリングを適切に制御できる。

図１１は、第１実施形態に係る動作の一例を示す図である。ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。ＭＢＳ配信のモードは、第１配信モード、又は第２配信モードであってもよい。

ステップＳ１０１において、ｇＮＢ２００は、ＭＢＳセッションとＱｏＳフローとＧ－ＲＮＴＩのマッピング情報をＵＥ１００に送信する。ｇＮＢ２００は、ブロードキャストシグナリング（ＳＩＢ又はＭＣＣＨ）によりマッピング情報、又はＵＥ専用シグナリング（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＲＲＣ Ｒｅｌｅａｓｅメッセージ）によりマッピング情報を送信してもよい。マッピング情報は、ＭＢＳセッション識別子とＱｏＳフロー識別子とＧ－ＲＮＴＩとのセットを１つ以上含んでいてもよい。マッピング情報は、ＮＡＳメッセージで、ＡＭＦ３００ＡからＵＥ１００に通知されてもよい。

ステップＳ１０２において、ＵＥ１００は、ＭＢＳセッションを受信している又は受信に興味を持っている。なお、ステップＳ１０１は、ステップＳ１０２の後であってもよい。

ステップＳ１０３において、ＵＥ１００は、当該ＭＢＳセッションと対応付けられたＫ本（Ｋ≧２）のＱｏＳフローの中から、自身が受信を希望する所望のＱｏＳフローを特定する。所望のＱｏＳフローは、１本のＱｏＳフロー、又は複数のＱｏＳフローであってもよい。

ここで、ＵＥ１００の上位レイヤ（アプリケーションレイヤ等）は、当該ＭＢＳセッションにおいて、必要なＱｏＳフローの識別子をＡＳレイヤに通知してもよい。例えば、上位レイヤは、ビデオ会議アプリケーションにおいて、ビデオストリーミング（ＱｏＳフロー＃１）は使っているので必要だが、チャット機能（ＱｏＳフロー＃２）はオフしているので必要無い旨をＡＳレイヤに通知してもよい。

ステップＳ１０４において、ＵＥ１００は、ステップＳ１０３で特定した所望のＱｏＳフローと対応付けられたＭ個のＧ－ＲＮＴＩを特定する。

ステップＳ１０５において、ＵＥ１００は、当該ＭＢＳセッション（ＵＥ１００が受信している又は受信に興味のあるＭＢＳセッション）の識別子と、当該ＭＢＳセッションに属する所望のＱｏＳフローに関する識別子とを含むＭＢＳ興味情報メッセージをｇＮＢ２００に送信してもよい。所望のＱｏＳフローに関する識別子は、例えば、所望のＱｏＳフローの識別子、Ｋ本のＱｏＳフローのうち所望のＱｏＳフロー以外のＱｏＳフローの識別子、又は、所望のＱｏＳフローと対応付けられたＧ－ＲＮＴＩであってもよい。ＭＢＳ興味情報メッセージは、ＲＲＣメッセージの一種であって、例えば、ＭＢＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎメッセージ又はＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージであってもよい。ＭＢＳ興味情報メッセージを受信したｇＮＢ２００は、ＭＢＳ興味情報メッセージに含まれる情報（特に、所望のＱｏＳフローに関する識別子）に基づいて、ＵＥ１００が希望しないＱｏＳフローの送信の停止、又はＵＥ１００における設定変更（例えば、ＵＥ１００が希望しないＱｏＳフローの設定削除など）を行ってもよい。なお、ステップＳ１０５は、ステップＳ１０４の前に行われてもよい。

ステップＳ１０６において、ＵＥ１００は、ステップＳ１０４で特定したＭ個のＧ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行う。これにより、ＵＥ１００は、ＭＴＣＨがマッピングされたＰＤＳＣＨのスケジューリング情報をＤＣＩから取得する。

ステップＳ１０７において、ＵＥ１００は、ＰＤＳＣＨ上でｇＮＢ２００からのＭＢＳデータを受信する。

［第２実施形態］
第２実施形態について、上述の第１実施形態との相違点を主として説明する。

図１２は、第２実施形態に係るＵＥ１００の内部処理を示す図である。ＵＥ１００のＰＨＹレイヤは、物理チャネルの１つであるＰＤＳＣＨ上で受信したユーザデータ（受信データ）を処理し、トランスポートチャネルの１つである下りリンク共有チャネル（ＤＬ－ＳＣＨ）に流す。ＵＥ１００のＭＡＣレイヤは、ＤＬ－ＳＣＨ上で受信したデータを処理し、受信データに含まれるヘッダ（ＭＡＣヘッダ）に含まれる論理チャネル識別子（ＬＣＩＤ）に基づいて、当該受信データを対応する論理チャネル（対応するＲＬＣエンティティ）に流す。

ここで、ユーザデータ用の論理チャネルには、専用トラフィックチャネル（ＤＴＣＨ）及びマルチキャストトラフィックチャネル（ＭＴＣＨ）がある。ＤＴＣＨはユニキャスト用の論理チャネルであり、ＭＴＣＨはマルチキャスト／ブロードキャスト用の論理チャネルである。各論理チャネルに対するＬＣＩＤの割り当てはｇＮＢ２００により行われてもよい。なお、ＤＴＣＨはマルチキャスト／ブロードキャストのＰＴＰ用の論理チャネルであり、ＭＴＣＨはマルチキャスト／ブロードキャストのＰＴＭ用の論理チャネルであってもよい。

ＤＴＣＨ及びＭＴＣＨに対して互いに異なるＬＣＩＤが割り当てられる場合、ＭＡＣレイヤは、ＭＡＣヘッダに含まれるＬＣＩＤに基づいて受信データを適切な論理チャネルに流すことができる。しかしながら、例えばＬＣＩＤに関する制約を少なくする観点から、ＤＴＣＨ及びＭＴＣＨでＬＣＩＤ空間を分けないことも想定される。

仮にＬＣＩＤ空間を分けないと規定された場合、ＭＴＣＨ及びＤＴＣＨで別々のＬＣＩＤがｇＮＢ２００から割り当てられれば特に問題はないが、ＭＴＣＨは複数ＵＥに共通の論理チャネルであるため、あるＵＥ１００においてＤＴＣＨ及びＭＴＣＨで同一のＬＣＩＤになってしまう懸念がある。第２実施形態は、ＤＴＣＨ及びＭＴＣＨで同一のＬＣＩＤが割り当てられた場合であっても、適切な論理チャネルに受信データを流すことを可能とする実施形態である。換言すると、ＤＴＣＨとＭＴＣＨに同一のＬＣＩＤが割り当て可能となることにより、有限個であるＬＣＩＤを有効に使用することができる。つまり、ＤＴＣＨとＭＴＣＨは本来２つの独立したＬＣＩＤが必要であったのに対して、１つの共通のＬＣＩＤを割り当てることが可能となる。また、ＤＴＣＨとＭＴＣＨのＬＣＩＤをそれぞれ独立して割り当てること、管理することによって生じる複雑さを回避できる。

第２実施形態に係る通信方法は、ＲＮＴＩを用いてｇＮＢ２００からのＰＤＣＣＨ受信処理を行うＵＥ１００で用いる方法である。当該通信方法は、セルＲＮＴＩ（Ｃ－ＲＮＴＩ）を用いて、ＤＴＣＨを受信するためのＰＤＣＣＨ受信処理を行うステップと、Ｇ－ＲＮＴＩを用いて、ＭＴＣＨを受信するためのＰＤＣＣＨ受信処理を行うステップと、ＤＴＣＨ及びＭＴＣＨに同一のＬＣＩＤが割り当てられている場合、ＰＤＣＣＨ受信処理に応じて得られた受信データが属する論理チャネルを、当該ＰＤＣＣＨ受信処理に用いたＲＮＴＩに基づいて特定するステップと、を有する。このように、ＰＤＣＣＨ受信処理に応じて得られた受信データが属する論理チャネルを、当該ＰＤＣＣＨ受信処理に用いたＲＮＴＩに基づいて特定することにより、ＤＴＣＨ及びＭＴＣＨで同一のＬＣＩＤが割り当てられた場合であっても、適切な論理チャネルに受信データを流すことが可能である。

具体的には、ＵＥ１００のＭＡＣレイヤは、受信データであるＭＡＣ ＰＤＵのヘッダに含まれるＬＣＩＤが、ＤＴＣＨ及びＭＴＣＨで同一のＬＣＩＤである場合において、Ｃ－ＲＮＴＩを用いたＰＤＣＣＨ受信処理に応じて得られた受信データが属する論理チャネルとしてＤＴＣＨを特定する。一方、Ｇ－ＲＮＴＩを用いたＰＤＣＣＨ受信処理に応じて得られた受信データが属する論理チャネルとしてＭＴＣＨを特定する。そして、ＵＥ１００のＭＡＣレイヤは、特定された論理チャネルに対して受信データ（ＭＡＣ ＳＤＵ／ＲＬＣ ＰＤＵ）を出力する。

なお、第２実施形態において、ＵＥ１００は、データ無線ベアラ（ＤＲＢ）とＤＴＣＨのＬＣＩＤとを対応付ける情報と、マルチキャスト無線ベアラ（ＭＲＢ）とＭＴＣＨのＬＣＩＤとを対応付ける情報と、をｇＮＢ２００から受信してもよい。

図１３は、第２実施形態に係る動作の一例を示す図である。ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。例えば、ＵＥ１００のＲＲＣ状態はＲＲＣコネクティッド状態であってもよい。ＭＢＳ配信のモードは、第１配信モード又は第２配信モードである。例えば、ＭＢＳ配信のモードは、第１配信モードであってもよい。

ステップＳ２０１において、ｇＮＢ２００は、ＤＴＣＨのＬＣＩＤとＭＴＣＨのＬＣＩＤについて、それぞれのマッピング情報をＵＥ１００に通知する。例えば、ｇＮＢ２００は、ＤＲＢ＃１とＤＴＣＨ ＬＣＩＤ＃１とを対応付ける情報と、ＭＲＢ＃２とＭＴＣＨ ＬＣＩＤ＃１とを対応付ける情報とをＵＥ１００に送信する。すなわち、本動作例では、ＤＴＣＨ及びＭＴＣＨに同一のＬＣＩＤが対応付けられてもよい。ＵＥ１００は、ＬＣＩＤが同一であると認識した場合、以下の動作を行うとしてもよい。

ステップＳ２０２において、ＵＥ１００は、ＭＢＳセッションを受信している又は受信に興味を持っている。なお、ステップＳ２０１は、ステップＳ２０２の後であってもよい。

ステップＳ２０３において、ＵＥ１００は、ＤＴＣＨ ＬＣＩＤ＃１について、Ｃ－ＲＮＴＩを用いてユニキャスト受信を行ってもよい。具体的には、ＵＥ１００は、Ｃ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行うことにより、ＤＴＣＨ受信を行ってもよい。

ステップＳ２０４において、ＵＥ１００は、ＭＴＣＨ ＬＣＩＤ＃１について、Ｇ－ＲＮＴＩを用いてマルチキャスト受信を行ってもよい。具体的には、ＵＥ１００は、Ｇ－ＲＮＴＩを用いてＰＤＣＣＨ受信処理を行うことにより、ＭＴＣＨ受信を行ってもよい。なお、ステップＳ２０４はステップＳ２０３の前に実行されてもよい。

ステップＳ２０３又はステップＳ２０４に応じて、ステップＳ２０５において、ＵＥ１００は、ＰＤＳＣＨ上でユーザデータを受信する。例えば、ステップＳ２０３に応じてＰＤＳＣＨ上で受信されるユーザデータはユニキャストデータであり、ステップＳ２０４に応じてＰＤＳＣＨ上で受信されるユーザデータはＭＢＳデータ（マルチキャストデータ又はブロードキャストデータ）であってもよい。

ＤＴＣＨ及びＭＴＣＨに同一のＬＣＩＤが対応付けられている場合（ステップＳ２０６：ＹＥＳ）、ステップＳ２０７において、ＵＥ１００（ＭＡＣレイヤ）は、ステップＳ２０５で受信したデータ（パケット）について、受信に用いたＲＮＴＩから、対応する論理チャネルを特定する。ＵＥ１００は、Ｃ－ＲＮＴＩで受信した場合、ＤＲＢ＃１（ＤＴＣＨ）に紐づいたＬＣＩＤ＃１に当該パケットを流す（ステップＳ２０８）。一方、ＵＥ１００は、Ｇ－ＲＮＴＩで受信した場合、ＭＲＢ＃２（ＭＴＣＨ）に紐づいたＬＣＩＤ＃１に当該パケットを流す（ステップＳ２０８）。

ＤＴＣＨ及びＭＴＣＨに同一のＬＣＩＤが対応付けられていない場合（ステップＳ２０６：ＮＯ）、ステップＳ２０８において、ＵＥ１００（ＭＡＣレイヤ）は、パケット（ＭＡＣ ＰＤＵ）のヘッダに含まれるＬＣＩＤが示す論理チャネルに当該パケットを流す。

第２実施形態では、ＤＴＣＨとＭＴＣＨが同一のＬＣＩＤである場合の受信方法について説明したが、これに限らない。別々のＭＴＣＨに同一のＬＣＩＤが割り当てられる場合にも第２実施形態に係る動作を適用可能である。図１４に示すように、ＭＴＣＨ＃１がＧ－ＲＮＴＩ＃１で送信／受信され、ＭＴＣＨ＃２がＧ－ＲＮＴＩ＃２で送信／受信される場合において、ＭＴＣＨ＃１とＭＴＣＨ＃２に同一ＬＣＩＤが割り当てられている（設定されている）場合においても、ＵＥ１００は、受信処理に用いたＧ－ＲＮＴＩ＃１とＧ－ＲＮＴＩ＃２から、適切なＲＬＣエンティティにデータを流すことが可能である。

［第３実施形態］
第３実施形態について、上述の第１及び第２実施形態との相違点を主として説明する。

第２配信モードにおいて、ＵＥ１００は、ｇＮＢ２００からＭＣＣＨを受信することによりＭＴＣＨ設定情報を取得し、ＭＴＣＨ設定情報に基づいてＭＴＣＨ（ＭＢＳデータ）を受信する。ここで、ＭＣＣＨの内容は変更され得る。ＭＣＣＨの内容が維持される期間はＭＣＣＨ変更周期（ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄ）と呼ばれてもよい。ＭＣＣＨの内容が変更され得る所定タイミングはＭＣＣＨ変更バウンダリ（ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｂｏｕｎｄａｒｙ）と呼ばれてもよい。

ＭＢＳ受信を行っている又はＭＢＳ受信に興味のあるＵＥ１００が各ＭＣＣＨ変更バウンダリにおいてＭＣＣＨ（具体的には、物理チャネルであるＰＤＳＣＨ）を受信してその中身を解読することは負荷及び消費電力の増大につながる。そのため、ＭＣＣＨの内容変更に関する通知を、所定タイミングにおいてＰＤＣＣＨ上で（ＤＣＩ中で）ｇＮＢ２００からＵＥ１００に送信することを想定する。これにより、ＵＥ１００は、ＭＣＣＨを受信する必要があるか否かを判定できるため、不要なＭＣＣＨ受信を抑制できる。このようなＭＣＣＨ変更通知は、ＭＣＣＨの内容変更、例えば、ＭＢＳセッション開始、ＭＢＳセッション変更、又はＭＢＳセッション停止に基づいて送信されてもよい。ＭＣＣＨ変更通知は、ＤＣＩ中の１つのビット、すなわち、変更があるときのみ“１”とされる１ビットのフラグとして構成されてもよい。

しかしながら、所定タイミングにおいてＭＣＣＨ変更通知を受信しないＵＥ１００、すなわち、ＭＣＣＨ変更を示すビットを検出しないＵＥ１００は、それがＰＤＣＣＨ（ＤＣＩ）の伝送エラー（無線区間での消失）に起因するのか又はＭＣＣＨ変更が無いことに起因するのかを判別できない。そのため、ＰＤＣＣＨ（ＤＣＩ）の伝送エラーが生じる可能性を考慮すると、所定タイミングにおいてＭＣＣＨ変更通知を受信しないＵＥ１００は、ＭＣＣＨを受信してその中身を解読することが必要になり得る。第３実施形態は、そのような問題を解決しようとする実施形態である。

第３実施形態に係る通信方法は、ｇＮＢ２００が、ＭＴＣＨの受信に用いる設定情報（ＭＴＣＨ設定情報）をＭＣＣＨ上で送信するステップと、ｇＮＢ２００が、ＭＣＣＨの内容変更（以下、「ＭＣＣＨ変更」と呼ぶ）に関する通知（以下、「ＭＣＣＨ通知」と呼ぶ）を、所定タイミングにおいて物理下りリンク制御チャネル（ＰＤＣＣＨ）上でＵＥ１００に送信するステップと、を有する。当該送信するステップは、ＭＣＣＨ変更が無い場合、ＭＣＣＨ変更が無いことを示すＭＣＣＨ通知を送信するステップを含む。このように、ＭＣＣＨ変更が無い場合、ＭＣＣＨ変更が無いことを示すＭＣＣＨ通知を送信することにより、ＵＥ１００は、ＭＣＣＨ変更が無いことを明確に把握できる。そのため、所定タイミングにおいてＭＣＣＨ通知を受信しないＵＥ１００は、それがＰＤＣＣＨ（ＤＣＩ）の伝送エラーに起因するものであると判別できるようになる。よって、ＵＥ１００が不要なＭＣＣＨ受信を行うことを抑制可能である。

例えば、ｇＮＢ２００は、ＭＣＣＨ変更が有る場合、ＭＣＣＨ変更が有ることを示す第１の値をＭＣＣＨ通知として送信する。ｇＮＢ２００は、ＭＣＣＨ変更が無い場合、ＭＣＣＨ変更が無いことを示す第２の値をＭＣＣＨ通知として送信する。これにより、ＵＥ１００は、ＭＣＣＨ変更の有無を明確に把握できる。

例えば、ＵＥ１００は、ＰＤＣＣＨ上で第１の値を受信した場合、ＭＣＣＨの受信を試みてもよい。ＵＥ１００は、ＰＤＣＣＨ上で第２の値を受信した場合、ＭＣＣＨの受信を省略してもよい。ＵＥ１００は、所定タイミングにおいてＰＤＣＣＨ上でＭＣＣＨ通知を受信できなかった場合、ＭＣＣＨの受信を試みてもよい。

図１５は、第３実施形態に係る動作の一例を示す図である。ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。ＭＢＳ配信のモードは、第２配信モードであってもよい。

ステップＳ３０１において、ＵＥ１００は、ＭＢＳセッションを受信している又は受信に興味を持っている。

ステップＳ３０２乃至Ｓ３０４において、ｇＮＢ２００は、ＭＣＣＨ通知の送信処理を行う。ここで、ＭＣＣＨ通知は、ＤＣＩのあるビットを用いて構成される。ＭＢＳセッション開始に基づくＭＣＣＨ通知と、ＭＢＳセッション変更／停止に基づくＭＣＣＨ通知とは、同一ビット、又はそれぞれ異なるビットで通知が行われてもよい。また、当該ＭＣＣＨ通知は、ＭＢＳセッションごとに異なるビットで、又は全セッション共通（１ビットのみ）で通知が行われてもよい。ＭＣＣＨ通知を構成する（各）ビットは、“０”の時は「変更無し」、“１”の時は「変更有り」と定義されてもよい。また、ＭＣＣＨ通知を構成する（各）ビットは、０／１の関係が逆であってもよい。ｇＮＢ２００は、ＭＣＣＨ変更の有無に関わらず、ＭＣＣＨ通知を送信する。

ＭＣＣＨ変更有りの場合（ステップＳ３０２：ＹＥＳ）、ステップＳ３０３において、ｇＮＢ２００は、所定タイミングにおいて、ＭＣＣＨ変更が有ることを示す第１の値（例えば、“１”）をＭＣＣＨ通知として送信する。

これに対し、ＭＣＣＨ変更無しの場合（ステップＳ３０２：ＮＯ）、ステップＳ３０４において、ｇＮＢ２００は、所定タイミングにおいて、ＭＣＣＨ変更が無いことを示す第２の値（例えば、“０”）をＭＣＣＨ通知として送信する。

ＵＥ１００は、所定タイミング（ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｂｏｕｎｄａｒｙ）においてＭＣＣＨ通知（ＤＣＩ）の受信を試みる。

ここで、ＵＥ１００は、ＭＣＣＨ通知を正常に受信し、受信したＭＣＣＨ通知が第２の値である場合（ステップＳ３０５：ＹＥＳ）、ＵＥ１００は、ＭＣＣＨ（ＰＤＳＣＨ）の受信を試みない。

一方、ＭＣＣＨ通知を正常に受信し、受信したＭＣＣＨ通知が第１の値である場合、ＭＣＣＨ（ＰＤＳＣＨ）の受信を試みる（ステップＳ３０６）。また、ＵＥ１００は、ＭＣＣＨ通知を正常に受信ができなかった場合、ＭＣＣＨ（ＰＤＳＣＨ）の受信を試みる（ステップＳ３０６）。具体的には、ＵＥ１００は、ＭＣＣＨ（ＰＤＳＣＨ）のスケジューリング情報を伝送するＰＤＣＣＨ（ＤＣＩ）の受信を試みる。なお、ＭＣＣＨ通知を構成するＤＣＩは専用のＲＮＴＩ（例えばＳＣ－Ｎ－ＲＮＴＩ）でスクランブルされてもよく、ＭＣＣＨ用ＤＣＩは専用のＲＮＴＩ（例えばＳＣ－ＲＮＴＩ）でスクランブルされてもよい。これらのＲＮＴＩは、技術仕様で規定された固定のＲＮＴＩであってもよい。ＵＥ１００は、受信したＭＣＣＨを確認し、変更があった場合は、当該ＭＣＣＨの内容（設定）を適用する。

第２実施形態において、ＭＣＣＨ変更の有無をビットの値で表す一例について説明したが、ＭＣＣＨ変更の有無をＲＮＴＩの値で表すように変更してもよい。その場合、ＭＣＣＨ変更の有無にかかわらず、ビットの値は固定値であってもよい。図１６のステップＳ３０３’、Ｓ３０４’、及びＳ３０５’に示すように、第１のＲＮＴＩ（ＲＮＴＩ＃１）でＭＣＣＨ通知が送信された場合は「変更無し」、第２のＲＮＴＩ（ＲＮＴＩ＃２）でＭＣＣＨ通知が送信された場合は「変更有り」と定義されてもよい。

［その他の実施形態］
上述の各動作フローは、別個独立に実施する場合に限らず、２以上の動作フローを組み合わせて実施可能である。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよい。１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。

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

ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭ又はＤＶＤ－ＲＯＭ等の記録媒体であってもよい。また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ ｏｎ ａ ｃｈｉｐ）として構成してもよい。

本開示で使用されている「に基づいて（ｂａｓｅｄ ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。

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

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

［付記１］
（１．導入）
ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８で承認された。

ＲＡＮ２は、２つの配信モードに同意した。つまり、コネクティッド状態のＵＥが受信するマルチキャストセッションの配信モード１と、すべてのＲＲＣ状態のＵＥが受信するブロードキャストセッションの配信モード２である。

ＲＡＮ２は、ＭＣＣＨスケジューリング方法の詳細、つまり、ＭＣＣＨ繰り返し期間、ＭＣＣＨ送信ウィンドウ、検索スペース、及びＭＣＣＨ変更期間にも同意した。

ＲＡＮ２＃１１４－ｅでは、２つの配信モードについて次の合意に達した。

マルチキャスト有効化通知にＰＣＣＨを使用する（ＭＢＳサポートノードにも使用する）。
通知でＭＢＳセッションＩＤが伝達されていることを確認する。
ＰＲＮＴＩを使用したすべての（レガシー）ＰＯにおけるページングの使用は、ベースラインの前提である（他の変更についても議論可能である）。
ＭＢＳ固有のＳＩＢは、ＭＣＣＨ設定を実行するように定義される。
ＭＣＣＨのコンテンツには、Ｇ－ＲＮＴＩ、ＭＢＳセッションＩＤなどのブロードキャストセッションに関する情報と、ＭＴＣＨのスケジュール情報（検索スペース、ＤＲＸなど）を含める必要がある。
ＭＣＣＨに含める必要のあるＬ１パラメータは、更なるＲＡＮ１の進行とインプットを保留する。
ＲＡＮ１がＭＣＣＨのＢＷＰ／ＣＦＲについて進行するまで、専用のＭＣＣＨ設定が必要かどうかについての議論を延期する。
進行中のセッションの設定の変更（セッション停止を含む）によるＭＣＣＨ変更のインディケーションは、ネットワークからの明示的な通知で提供される（ＲＡＮ１が、セッション開始通知用のビットに加えて、この目的のための別のビットをＭＣＣＨ変更通知ＤＣＩに収容できることを確認した場合）。この通知をＭＣＣＨが保持する他の情報の変更に再利用できるかどうかについては更なる検討が必要である。
ＵＥがＭＣＣＨ変更通知を見逃す可能性に対処する必要があるか、又はＵＥの実装に任せることができるかどうかは更なる検討が必要である。
少なくとも、ＲＡＮ１がＭＣＣＨ変更通知のためにＭＣＣＨ－ＲＮＴＩ以外のＲＮＴＩを利用することを決定した場合、ＭＣＣＨ変更通知は、各ＭＣＣＨ繰り返し期間の最初のＭＣＣＨ監視機会に送信される。
シングルＭＣＣＨをサポートする。

付記１では、ＬＴＥ ｅＭＢＭＳメカニズムのベースラインを考慮して、配信モード２のコントロールプレーンの側面の詳細を提供する。

（２．議論）
（３．残りのステージ２の問題）
この時点で、ＲＡＮ２の合意に従って、２つの配信モードの特性を図１７に示す。

（４．配信モード２を介して接続されたマルチキャストセッション）
ＮＲ ＭＢＳは、以下のＷＩＤから引用されているように、さまざまなタイプのユースケースをサポートすることが期待されている。ＮＲ ＭＢＳは、ミッションクリティカルやＶ２Ｘなどの遅延に敏感なアプリケーションから、ＩｏＴなどの遅延耐性のあるアプリケーションまで、さまざまな要件に合わせて適切に設計する必要がある。ＩＰＴＶなどのＵＤＰタイプのストリーミングへのソフトウェア配信として、実際には、すべてのマルチキャストサービスが「高ＱｏＳ」を必要とするわけではない。

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

「ＱｏＳ要件が低い」これらのサービスの一部は配信モード２でカバーされる場合があるが、「ＱｏＳ要件が高い」他のサービスは配信モード１が必要である。さらに、ＬＴＥ ｅＭＢＭＳはマルチキャストセッションを配信する場合があり、これはＮＲ ＭＢＳのベースラインと見なすことができる。この意味で、ｇＮＢがマルチキャストセッションに配信モード２を使用することを選択できることは有益である。この問題は、ＲＡＮ２＃１１２－ｅからＲＡＮ２＃１１４－ｅまで更なる検討が必要であるが、一般的に、制限する技術的な理由はない。

ＲＡＮ２では「ＲＡＮ２は、Ｒｅｌ－１７のＲＲＣコネクティッドモードでのアクティブマルチキャストサポートを優先し、時間が許せば、ＲＲＣインアクティブ状態のマルチキャストサポートを（コネクティッドモードのマルチキャストソリューション、及びブロードキャストソリューションがより成熟した）後で議論できる」ことを同意したが、配信モード１のコンテキストで合意が行われたため、コネクティッド状態のＵＥの配信モード２によるマルチキャストセッションを排除するものではない。

提案１：ＲＡＮ２は、ブロードキャストセッションに加えて、配信モード２を少なくともＲＲＣコネクティッド状態のＵＥのマルチキャストセッションに使用できることに同意する必要がある。

（５．専用のＭＣＣＨ（サービス継続性の観点から））
ＲＡＮ２は「ＲＡＮ１がＭＣＣＨのＢＷＰ／ＣＦＲで進展するまで、専用のＭＣＣＨ設定が必要かどうかに関する議論を延期する」ことに同意した。専用のＭＣＣＨは、サポートされている場合、例えば、ＲＲＣ再設定によって提供されることが期待される。

所見１：専用のＭＣＣＨは、ＭＣＣＨがＲＲＣ再設定によって提供される。つまりブロードキャストベースの方法ではないと解釈できる。

一方、専用のＭＣＣＨは、ブロードキャストサービスの継続性の観点から考えることができる。ＲＡＮ２は「コネクティッド状態のＵＥのＬＴＥ ＳＣ－ＰＴＭメカニズムを再利用して、ＮＲ ＭＢＳ配信モード２のＰＴＭ設定、つまりブロードキャストベースの方法を受信できると想定する」ことにすでに同意している。この想定はセル内設定に関するものであるが、セル間サービスの継続性、つまりハンドオーバに関するものではない。

所見２：ＲＡＮ２が合意したＭＣＣＨは、セル内設定に対してブロードキャストベースの方法で提供されるが、セル間サービスの継続性のためではない。

ＬＴＥ ＳＣ－ＰＴＭでは、ＵＥは、ハンドオーバ前、ハンドオーバ中、又はハンドオーバ後でも、ターゲットセルのＳＩＢ２０とＭＣＣＨを何らかの方法で取得すると想定される。これは、ＮＲ ＭＢＳ配信モード２のベースラインと見なされる可能性がある。ただし、ＵＥが、例えば、ビジー状態で、隣接セルのＭＣＣＨを取得するのを見逃したり、遅延したりする可能性があるため、サービスが中断するリスクがあることを意味する。したがって、より信頼性の高いソリューションを議論する価値がある。具体的には、ターゲットセルのＭＣＣＨ、少なくとも対象のＭＴＣＨスケジューリング情報は、同期を使用したＲＲＣ再設定、つまりハンドオーバーコマンドによって提供される必要がある。このソリューションにより、ハンドオーバ後のサービス継続性を確実に確保できる。

提案２：ＲＡＮ２は、ターゲットセルのＭＣＣＨ、少なくとも対象のＭＴＣＨスケジューリング情報が、ハンドオーバ手順中に提供されることに同意する必要がある。つまり、ＲＲＣコネクティッド状態のＵＥのセル間サービスの継続性を確保するために、同期を使用したＲＲＣ再設定によって提供される。

（６．その他の情報に関するＭＣＣＨ変更通知）
ＲＡＮ２は、セッションの開始、セッションの変更、及び停止により、ＭＣＣＨ変更通知を導入することに同意し、これにより、ＭＴＣＨ受信に関連する設定（例えば、ＭＢＳセッション情報、及びＭＴＣＨスケジューリング情報）が変更されたときにＭＣＣＨ変更通知が送信されることが現在の意図である。ＲＡＮ２は、「この通知を、ＭＣＣＨが保持する他の情報の変更に再利用できるかどうかについては更なる検討が必要である」と残した。

考えられる「その他の情報」は、隣接セル／周波数情報として解釈でき、これについては、以下のセクションで議論する。ＵＥが隣接セル／周波数情報を見逃した場合、ＵＥがサービングセルに留まっているときは重大な問題ではない。ただし、最新の隣接セル／周波数情報は、アイドル／インアクティブ状態のＵＥ、及び提案５が合意されていない場合はＲＲＣコネクティッド状態のＵＥのセル間モビリティの場合に重要な情報である。この意味で、より信頼性の高いサービス継続性のために、ＲＡＮ２が隣接セル／周波数情報がＭＣＣＨによって提供されることに同意した場合、他の情報が変更されたときにもＭＣＣＨ変更通知を送信する必要がある。

提案３：ＲＡＮ２は、ＭＣＣＨの内容のいずれかが変更されたときに、ＭＣＣＨ変更通知が送信されることに同意する必要がある。つまり、ＭＢＳセッション情報及びＭＴＣＨスケジューリング情報に加えて、少なくとも隣接周波数／セル情報（ＭＣＣＨによって提供されることに同意した場合）である「その他の情報」にも適用される。

（７．ＭＣＣＨ変更通知の見逃し）
ＲＡＮ２は、「ＵＥがＭＣＣＨ変更通知を見逃す可能性に対処する必要があるか、ＵＥの実装に任せることができるかどうかは更なる検討が必要である」と残した。合意によると、ＭＣＣＨ変更通知はＤＣＩで提供されると予想されるが、詳細はＲＡＮ１までである。

更なる検討が必要なことはセッションの変更／停止だけでなく、セッションの開始にも関連しており、ＬＴＥ ｅＭＢＭＳで問題として認識されたことはない。さらに、問題が実際に存在するかどうかは、ＲＡＮ１のＤＣＩ設計に依存する場合がある。例えば、ＭＣＣＨが変更されていない場合にも、ＭＣＣＨ変更通知が送信される場合がある。例えば、ＤＣＩのビットは、「０」で「変更なし」を示し、「１」で「変更」を示すことができるため、ＵＥはＭＣＣＨ変更を見逃したかどうかを通知できる。追加の電力消費なしで通知し、回復のためにいくつかのアクションを実行する場合がある。したがって、現時点でＲＡＮ２が更なる検討が必要なことについて議論すべきかどうかは不明である。

所見３：ＲＡＮ２でＵＥがＭＣＣＨ変更通知を見逃す可能性について議論する前に、ＭＣＣＨ変更通知のＤＣＩ設計のＲＡＮ１進捗状況が必要である。

（８．オンデマンドＭＣＣＨ）
ＮＲの新しいパラダイムは、オンデマンドＳＩ送信のサポートである。この概念は、配信モード２のＭＣＣＨ、つまりオンデマンドＭＣＣＨで再利用できる。例えば、遅延耐性サービスのＭＣＣＨはオンデマンドで提供されるため、シグナリングのリソース消費を最適化できる。言うまでもなく、ネットワークには、つまり、遅延に敏感なサービス等のオンデマンドではなく、ＭＣＣＨを定期的に提供する別のオプションがある。

提案４：ＲＡＮ２は、ＭＣＣＨをオンデマンドで提供できることに同意する必要がある。

（９．ワンステップ設定）
別の可能性として、ＭＣＣＨをＢＣＣＨにマージすること、つまり、図１８に示すようなワンステップ設定をさらに議論することができる。例えば、ＳＩＢは、ＭＴＣＨスケジューリング情報を直接、つまりＭＣＣＨなしで提供する。遅延耐性のあるサービスや電力に敏感なＵＥの最適化を提供する。例えば、ＵＥは、ＳＩＢ（オンデマンド）を要求することができ、ｇＮＢは、複数のＵＥからの要求の後に、ＳＩＢ及び対応するサービスの提供を開始することができる。これらのＵＥは、繰り返しブロードキャストされるＭＣＣＨを監視する必要はない。

提案５：ＲＡＮ２は、ＭＣＣＨなしのマルチキャスト受信がサポートされていること（つまり、ワンステップ設定）に同意する必要がある。例えば、ＳＩＢはＭＴＣＨスケジューリング情報を直接提供する。

（１０．アイドル／インアクティブ状態でのカウント）
ＮＲ ＭＢＳの場合、ＭＢＳ興味インディケーションは、ＲＲＣコネクティッド状態でサポートされることに同意したが、アイドル／インアクティブ状態ではサポートされない。これに基づいて、ＬＴＥ ｅＭＢＭＳに加えての機能強化を議論する価値がある。

ＬＴＥ ｅＭＢＭＳでは、ＵＥの大部分がＲＲＣアイドル状態でブロードキャストサービスを受信している場合でも、ＭＩＩもカウントもアイドル状態のＵＥから情報を収集できない。これは、セッション制御とリソース効率の観点から見たＬＴＥ ｅＭＢＭＳの残りの問題の１つである。

所見４：ブロードキャストセッションの場合、ＭＢＳサービスを受信するほとんどのＵＥはＲＲＣアイドル／インアクティブ状態にある可能性がある。

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

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

ＮＲ ＭＢＳにはＭＣＥがないことに注意し、これは、ＭＣＥ機能がｇＮＢ内に統合されることを意味する。この意味で、ネットワークインターフェイスの観点からＲＡＮ３が決定したものに関係なく、ＮＲ ＭＢＳでカウントが必要かどうかを決定するのはＲＡＮ２である。

提案６： ＲＡＮ２は、ＭＢＳカウントが導入されているかどうか、及びアイドル／インアクティブ状態のＵＥからも収集されているかどうかについて議論する必要がある。

（１１．ステージ３の側面）
ＳＩＢ１３、ＳＩＢ１５、ＳＩＢ２０、ＳＣ－ＭＣＣＨ、ＭＢＭＳ興味インディケーションのＩＥ、及びＬＴＥでのセル再選択手順は、ＮＲ ＭＢＳのステージ３仕様のベースラインと見なすことができる。

（１２．ＭＢＳ固有のＳＩＢ）
（１３．基本的な内容）
ＲＡＮ２は、「ＭＢＳ固有のＳＩＢはＭＣＣＨ設定を実行するように定義されている」ことに同意した。ＭＣＣＨ設定に関して、ＲＡＮ２は、「ＭＣＣＨ送信ウィンドウはＭＣＣＨ繰り返し期間、ＭＣＣＨウィンドウ期間、及び無線フレーム／スロットオフセットによって定義される」、及び「変更期間はＮＲ ＭＣＣＨに対して定義される」ことにすでに同意している。これらのパラメータは、ＳＩＢ２０と同じであり、つまり、それぞれＳＣ－ＭＣＣＨ－繰り返し期間、ＳＣ－ＭＣＣＨ－第１サブフレーム、ＳＣ－ＭＣＣＨ－期間、ＳＣ－ＭＣＣＨ－オフセット、及びＳＣ－ＭＣＣＨ－変更期間である。したがって、これらのパラメータの範囲は、標準化の労力を最小限に抑えるために簡単に再利用できる。

提案７：ＲＡＮ２は、ＭＢＳ固有のＳＩＢで、ＭＣＣＨ繰り返し期間、期間、無線フレーム／オフセット、及び変更期間の範囲が、ＬＴＥ ＳＣ－ＰＴＭ、つまりＳＩＢ２０のこれらのパラメータの範囲を再利用することに同意する必要がある。

（１４．高度なコンテンツ）
ＭＢＳサービスがＰＴＰ又はＰＴＭのどちらで提供されるか、及び配信モード１又は配信モード２で提供されるかどうかは、ＮＷの実装次第である。これにより、サービスの信頼性とスペクトル効率のバランスをうまくとることができる。ただし、ＵＥの観点から、特にアイドル／インアクティブ状態のＵＥ及び遅れて参加するＵＥの場合、ＵＥは、対象のＭＢＳサービスを取得するために接続確立を開始する必要があるかどうかを知る必要がある。ＵＥは最初にＭＣＣＨをチェックし、ＭＣＣＨが対象のＭＢＳサービスのＭＴＣＨスケジューリング情報を含まない場合、ＵＥは、ＭＢＳサービスがＲＲＣコネクティッド状態で、すなわち、ＰＴＰ、配信モード１、又は、ユニキャスト（ＰＤＵセッション）を介して、のみ提供されることに気付くと考えることができる。ただし、このようなプロセスはＵＥにとって負担であり、ＭＢＳサービスを取得する前に多少の遅延が発生する可能性がある。したがって、ＭＢＳ固有のＳＩＢが、ＭＢＳサービスを取得するためにＵＥが接続されている必要があるかどうかの情報を提供するかどうかを議論する価値がある。

提案８：ＲＡＮ２は、ＭＢＳ固有のＳＩＢがＭＢＳサービスをそれらの配信モードに関連付けるための情報を提供するかどうかについて議論する必要がある。

ＲＡＮ２は、ブロードキャストセッションで使用されると想定されているＭＢＳ興味インディケーションを導入することに同意した。少なくともＡＳの観点からは、ＭＢＳサービスがマルチキャストセッションとして提供されるかブロードキャストセッションとして提供されるかはネットワーク次第である。さらに、ＵＥの観点からは、ｇＮＢはＵＥが興味のあるＭＢＳサービスに関する情報を取得できるかどうかは不明であり、これは、マルチキャストセッション用にＡＭＦによって提供される可能性があるが、ブロードキャストセッション用ではない。その結果、ＵＥは、興味のあるＭＢＳサービスに対してＭＢＳ興味インディケーションを送信する必要があるかどうかを知ることができない。したがって、ｇＮＢが各ＭＢＳサービスに対してＭＢＳ興味インディケーションが許可されているかどうかに関する情報を提供する場合、ＵＥにとって役立つ。言い換えれば、どのＭＢＳサービスにＭＢＳ興味インディケーションが必要かということである。したがって、ＲＡＮ２は、そのような追加情報が必要かどうかについて議論する必要がある。

提案９：ＲＡＮ２は、ＭＢＳ固有のＳＩＢが、ＭＢＳ興味インディケーションを各ＭＢＳサービスに送信できるかどうかに関する情報を提供するかどうかについて議論する必要がある。

（１５．ＭＣＣＨ）
ＲＡＮ２は、「ＭＣＣＨのコンテンツには、Ｇ－ＲＮＴＩ、ＭＢＳセッションＩＤなどのブロードキャストセッションに関する情報と、ＭＴＣＨのスケジュール情報（検索スペース、ＤＲＸなど）を含める必要があることに同意した。ＭＣＣＨに含める必要のあるＬ１パラメータは、ＲＡＮ１の進行と入力が保留されている」、及び「ＲＡＮ１がＭＣＣＨのＢＷＰ／ＣＦＲで進行するまで、専用のＭＣＣＨ設定が必要かどうかの議論を延期する」。

ＭＴＣＨスケジューリング情報については、ＬＴＥ ＳＣ－ＰＴＭのＳＣ－ＭＣＣＨには、ＭＢＭＳ Ｓｅｓｓｉｏｎ Ｉｎｆｏ（ＴＭＧＩ及びセッションＩＤ）、ｇ－ＲＮＴＩ、及びＳＣ－ＭＴＣＨ－ｓｃｈｅｄｕｌｉｎｇ Ｉｎｆｏ（Ｏｎ Ｄｕｒａｔｉｏｎ Ｔｉｍｅｒ ＳＣＰＴＭ、ＤＲＸ－Ｉｎａｃｔｉｖｉｔｙ Ｔｉｍｅｒ ＳＣＰＴＭ、Ｓｃｈｅｄｕｌｉｎｇ Ｐｅｒｉｏｄ Ｓｔａｒｔ Ｏｆｆｓｅｔ ＳＣＰＴＭ）を含むＳＣ－ＭＴＣＨ－ＩｎｆｏＬｉｓｔが含まれている。ＲＡＮ２は「ＮＲ ＭＢＳ配信モード２の場合、ＬＴＥ ＳＣ－ＰＴＭ ＤＲＸスキームがベースラインとして使用される」ことに同意したため、これらのパラメータと値の範囲は、標準化の労力を最小限に抑えるために単純に再利用される。

提案１０：ＲＡＮ２は、ＭＣＣＨがＭＢＳ Ｓｅｓｓｉｏｎ Ｉｎｆｏ（ＴＭＧＩ及びセッションＩＤ）、Ｇ－ＲＮＴＩ及びＭＴＣＨ－ｓｃｈｅｄｕｌｉｎｇ Ｉｎｆｏ（Ｏｎ Ｄｕｒａｔｉｏｎ Ｔｉｍｅｒ、Ｉｎａｃｔｉｖｉｔｙ Ｔｉｍｅｒ、Ｓｃｈｅｄｕｌｉｎｇ Ｐｅｒｉｏｄ、及びＳｔａｒｔ Ｏｆｆｓｅｔ）をＭＴＣＨ情報として提供することに同意する必要がある。

提案１１：ＲＡＮ２は、ＭＴＣＨスケジューリング情報の各パラメータの値の範囲（つまり、Ｏｎ Ｄｕｒａｔｉｏｎ Ｔｉｍｅｒ、Ｉｎａｃｔｉｖｉｔｙ Ｔｉｍｅｒ、Ｓｃｈｅｄｕｌｉｎｇ Ｐｅｒｉｏｄ、及びＳｔａｒｔ Ｏｆｆｓｅｔ）がＬＴＥ ＳＣ－ＰＴＭ、つまりＳＣ－ＰＴＭ設定のこれらのパラメータと同じであることに同意する必要がある。

ＬＴＥ ｅＭＢＭＳでは、ＳＩＢ１５はＳＡＩで周波数間情報を提供し、つまり、ＭＢＭＳ－ＳＡＩ－インタ周波数リストである。ＬＴＥ ＳＣ－ＰＴＭでは、ＳＣ－ＭＣＣＨには、セルＩＤと周波数で構成されるＳＣＰＴＭ－隣接セルリストと、隣接セルリストを参照するビット文字列であるＳＣ－ＭＴＣＨ隣接セルリストが含まれている。これらの情報は、ＵＥの観点からのサービス継続性、つまりＭＢＭＳ興味インディケーション及びセル再選択優先順位処理に役立つ。

このような隣接セル／周波数情報は、同じ目的、つまりサービスの継続性のためにＮＲ ＭＢＳで引き続き有用であると見なされる。したがって、ＲＡＮ２は、ＭＢＳサービスがブロードキャストされるセル／周波数リストに同意する必要がある。ＵＥは対象のＭＢＳサービスが提供されているセル／周波数を知る必要があるため、隣接セル／周波数情報はＭＢＳセッションＩＤ（ＴＭＧＩなど）に関連付ける必要がある。例えば、ＬＴＥ ｅＭＢＭＳのようなＳＡＩにさらに関連付けられるセル／周波数リストは更なる検討が必要であり、ＭＢＳ固有のＳＩＢ又はＭＣＣＨを介してブロードキャストされているかどうかも更なる検討が必要である。

提案１２：ＲＡＮ２は、ＭＢＳセッションＩＤ（ＴＭＧＩなど）に関連付けられている隣接セル／周波数リストがサービス継続性のためにブロードキャストされることに同意する必要がある。ＳＡＩにさらに関連付けられているかどうか、及びＭＢＳ固有のＳＩＢ又はＭＣＣＨで提供されているかどうかは更なる検討が必要である。

（１６．ＭＢＳ興味インディケーション）
（１７．基本的な内容）
ＲＡＮ２は、「ＭＢＳ興味インディケーションがブロードキャストサービスのコネクティッドモードのＵＥでサポートされていると想定する」ことに同意したが、正確なコンテンツについてはまだ議論されていない。

ＬＴＥでは、ＭＢＭＳ興味インディケーションには、ＲＯＭ関連の設定を除いて、３つのＩＥが含まれる（図１９に示す）。この支援情報は、ｇＮＢのスケジューリングやハンドオーバの決定などのサービスの継続性を確保するのに役立つ。ＳＣ－ＰＴＭと配信モード２の特性は非常に似ているため、同じ情報がＮＲ ＭＢＳに役立つと見なされる。

提案１３：ＲＡＮ２は、ＬＴＥのＭＢＭＳ興味インディケーションと同様に、ＭＢＳ興味インディケーションに周波数リスト、ＭＢＳ受信とユニキャスト間の優先順位、及びＭＢＳサービスリストが含まれることに同意する必要がある。

最小ＭＢＳサービスエリアはＮＲ ＭＢＳのセルである可能性があるため、ＭＢＳ興味インディケーションには、ＵＥの興味のあるＭＢＳサービスを提供するセルのリストも含める必要があるかどうかが考慮される。ＬＴＥ ＳＣ－ＰＴＭでは、ｇＮＢが隣接セル情報を提供するため、ｇＮＢがどの隣接セルがどのＭＢＳサービスを提供するかを知っていると想定すると、ＭＢＭＳサービスはそのようなセルを意味する。特に、提案９が同意できる場合、同じ想定がＮＲ ＭＢＳにも当てはまる。したがって、ＲＡＮ２はｇＮＢを確認する必要がある。

提案１４：ＲＡＮ２は、ＭＢＳサービスリストがＭＢＳ興味インディケーションに含まれている場合、ＵＥの興味のあるＭＢＳサービスを提供するセルを意味することを確認する必要があり、つまり、ｇＮＢは隣接セルで提供されるＭＢＳサービスを知っていると想定する。

（１８．高度なコンテンツ）
ＬＴＥベースライン、つまり上記の提案１３及び提案１４に加えて、ＭＢＳ興味インディケーションが他の支援情報を提供する必要があるかどうかを検討する価値がある。

例えば、ＭＢＭＳ優先順位は、ＵＥがユニキャスト受信よりもＭＢＭＳ受信を優先するかどうかを示すために使用され、これは、例えば、ｇＮＢのスケジューリングに役立ち、ＮＲ ＭＢＳで再利用できる。ただし、ＮＲ ＭＢＳには２つの配信モードがあり、つまり、Ｃ－ＲＮＴＩを使用した配信モード１及びＧ－ＲＮＴＩを使用した配信モード２があり、ＭＴＣＨ送信に関して異なるスケジューリングアルゴリズムに基づいている。したがって、ＵＥが異なる配信モードを介して提供される複数のＭＢＳサービスに興味がある場合、ＵＥが配信モード１の受信と配信モード２の受信との間に優先順位を提供すると役立つ場合がある。必要に応じて説明するＵＥの省電力設定など、他の例を検討することもできる。したがって、ＲＡＮ２はまず、高度な目的のための追加情報がＭＢＳ興味インディケーションによって提供されるかどうかについて議論する必要がある。

提案１５：ＲＡＮ２は、追加情報がＭＢＳ興味インディケーションによって提供されるかどうか、例えば、配信モード１の受信と配信モード２の受信との間の優先順位について議論する必要がある。

（１９．メッセージの定義）
検討する価値のあるもう１つの問題は、ＭＢＳ興味インディケーションが新しい／個別のメッセージであるか、ＵＥ支援情報メッセージと統合されているかである。ＬＴＥでは、前提条件が異なるため、つまり、ＵＡＩのＲＲＣ接続再設定中にＭＩＩのＳＩＢ１５を取得するため、ＭＢＭＳ興味インディケーション（ＭＩＩ）がＵＥ支援情報（ＵＡＩ）から分離される。一方、ＬＴＥでは個別のメッセージであったＩｎ－ｄｅｖｉｃｅＣｏｅｘｉｓｔｅｎｃｅＩｎｄｉｃａｔｉｏｎ（ＩＤＣ）は、ＮＲのＵＡＩに統合されている。ＬＴＥ（及びＮＲ）の前提条件は、ＩＤＣとＵＡＩの間で同じであったため、つまり、ＲＲＣ接続再設定が同じであるため、実現可能である。

所見５：ＭＢＳ興味インディケーションをＵＥ支援情報と統合できるかどうかは、前提条件が２つのメッセージ間で調整されているかどうかによって異なる。

ＮＲ ＭＢＳの場合、提案１０のＩＥでＭＢＳ興味インディケーションメッセージを生成するには、提案９のようなＭＢＳ固有のＳＩＢ又はＭＣＣＨの隣接セル／周波数情報が必要である。また、ＭＢＳ興味インディケーションはＭＢＳ固有のＳＩＢ、ＬＴＥ ｅＭＢＭＳの場合と同じＳＩＢ（又はＭＣＣＨ）で設定されることが期待される。したがって、ＵＡＩの前提条件、つまりＲＲＣ再設定とは一致していない。したがって、ＭＢＳ興味インディケーションは、ＬＴＥ ｅＭＢＭＳのように、ＵＡＩとは別のメッセージである必要がある。

提案１６：ＲＡＮ２は、ＭＢＳ興味インディケーションを新しいメッセージとして、つまりＵＥ支援情報とは別に定義することに同意する必要がある。

提案１７：ＲＡＮ２は、ＵＥがサービングセルからＭＢＳ固有のＳＩＢを取得できる場合（つまり、前提条件として）、ＭＢＳ興味インディケーションの送信が許可されることに同意する必要がある。

（２０．マルチキャストセッションのＭＢＳ興味インディケーション）
ＲＡＮ２は、ＭＢＳ興味インディケーションがブロードキャストセッションでサポートされていると想定していますが、マルチキャストセッションではサポートされていない。マルチキャストセッションの場合、マルチキャストセッションには上位層のセッション参加手順があるため、コアネットワークがｇＮＢにＵＥの興味を通知するというのが一般的な理解のようである。提案１０と図１８の文脈で、それはＵＥの興味のあるＭＢＳサービスに当てはまる。また、提案１１が合意できる場合、ｇＮＢはＭＢＳ周波数とＵＥの興味のあるＭＢＳサービスを提供するセルを知っていることは明らかである。ただし、ＭＢＳ受信とユニキャストの間の優先順位はＬＴＥのＭＢＭＳ優先順位と同様であり、純粋にＡＳ関連の情報であるため、つまり、ＵＥがコアネットワークにセッション参加手順内の優先順位の情報を通知するのは奇妙であるため、コアネットワークによって提供されない場合がある。

所見６：マルチキャストセッションの場合、コアネットワークはＭＢＳサービスなどのＵＥの興味のあるｇＮＢを提供し、ｇＮＢはＭＢＳ周波数／セルを知るが、コアネットワークとｇＮＢはＭＢＳとユニキャストと間のＵＥのＡＳ優先順位を知らない場合がある。

優先順位情報は、例えば、サービスの継続性にも関連するＬＴＥ ｅＭＢＭＳと同様にスケジューリング及びハンドオーバの決定に関して、ｇＮＢにとって依然として有用であると見なされる。したがって、ＵＥは、マルチキャストセッションについても優先順位情報をｇＮＢに通知する必要がある。この意味で、ＲＡＮ２は、マルチキャストサービス／配信モード１でもＭＢＳ興味インディケーションをサポートする必要があることに同意する必要がある。

提案１８：ＲＡＮ２は、少なくともＵＥがＭＢＳ受信とユニキャストとの間の優先順位をｇＮＢに通知するために、マルチキャストセッション／配信モード１でもＭＢＳ興味インディケーションがサポートされることに同意する必要がある。

（２１．セル再選択）
（２２．セル再選択の優先順位の処理）
ＬＴＥ ｅＭＢＭＳでは、周波数間セル再選択のために、いわゆる「最高優先ルール」がセル再選択の優先順位の処理に適用される。詳細には、ＵＥは、興味のあるＭＢＭＳサービスを提供する周波数を最優先事項と見なすことができる。また、ＵＥは、興味のあるＭＢＭＳサービスを提供しない周波数を最低の優先順位と見なすことができる。ｅＮＢによって設定された絶対周波数の優先順位に関係なく、ＵＥは対象のＭＢＭＳサービスを提供するセルを再選択できるため、サービスの継続性が保証される。これらのルールは周波数レベルにのみ適用され、ＭＢＭＳサービスが周波数ごとに提供されていると想定すれば十分である。

所見７：ＬＴＥでは、サービスの継続性は、対象のＭＢＭＳサービスを提供する周波数を最優先事項と見なすことができるＵＥによって保証され、これは、周波数間セルの再選択に適用できる。

所見８：ＬＴＥでは、ＵＥは、対象のＭＢＭＳサービスを提供していない周波数を最低の優先順位と見なすこともでき、これは、周波数間セルの再選択に適用できる。

さらに、イントラ周波数及び同等の優先順位のインタ周波数セル再選択、及びＣＥのＮＢ－ＩｏＴ及びＵＥ（つまり、拡張カバレッジ）のために、Ｒ基準（つまり、ランキング）はＳＣ－ＰＴＭ固有のオフセットを適用し、これは「無限大」に設定できる。これは、セルごとに「最高優先順位ルール」を模倣している。これは、「定義されたランキングが、イントラ周波数及びインタ周波数セルの再選択に適用されるため（設定された周波数優先順位に関係なく）、ＵＥは拡張されたカバレッジにある」、つまり、従来の周波数間セル再選択は、ＣＥのＮＢ－ＩｏＴ及びＵＥに適用できない。

所見９：ＬＴＥでは、ＮＢ－ＩｏＴ ＵＥとＣＥのＵＥは、Ｒ基準にＳＣ－ＰＴＭ固有のオフセット（「無限大」の場合があります）を適用する。これは、イントラ周波数及び同じ優先順位のインタ周波数セル再選択に適用できる。

要約すると、ＬＴＥには、周波数間セル再選択（つまり、周波数ベース）と、イントラ周波数及び同等の優先順位のインタ周波数再選択（つまり、セルベース）にそれぞれ適用できる２つのメカニズムがある。周波数間セル再選択の「最優先ルール」は、ＬＴＥ ｅＭＢＭＳと同様に、アイドル／インアクティブ状態のＵＥが対象のＭＢＳサービスを提供する周波数でキャンプする必要があるため、ＮＲ ＭＢＳに導入するのは簡単である。したがって、ＲＡＮ２は、ＮＲ ＭＢＳに「最優先ルール」を導入することに同意する必要がある。さらに、所見５のような「最低優先順位ルール」も導入する必要がある。

提案１９：ＲＡＮ２は、ＬＴＥと同様に、ＵＥが対象のＭＢＳサービスを提供する周波数を最優先事項と見なす場合があることに同意する必要がある。

提案２０：ＲＡＮ２は、ＬＴＥと同様に、ＵＥが対象のＭＢＳサービスを提供しない周波数を最低の優先順位と見なす場合があることに同意する必要がある。

（２３．Ｒ基準）
もう１つのメカニズム、つまりＲ基準のＳＣ－ＰＴＭ固有のオフセットは、ＮＲ ＭＢＳの最小サービスエリアがセルと見なされることを考慮に入れる価値があるが、それでもＲｅｌ－１７で優先される展開シナリオ、つまり、周波数ベース又はセルベースに依存する。周波数ベースの展開、つまり同じＭＢＳサービスが特定のＭＢＳサービスエリア内の周波数でセル間で提供されるのは、セルベースの展開のサブセットである。つまり、ＭＢＳサービスは周波数をセルのリストで表すことができるため、ＭＢＳサービスはセルでのみ提供され、これにより、リストには周波数上のすべてのセルが含まれる。したがって、ＭＢＳサービスが基本的にセルごとに提供される場合は、さまざまな展開シナリオをサポートするための柔軟性が高くなる。

上記のように、ＳＣ－ＰＴＭ固有のオフセットはＲｅｌ－１４のｅＭＴＣ／ＮＢ－ＩｏＴでのマルチキャストサポートのために、つまり、ＣＥでの周波数間セルの再選択がないために導入されたが、特定のセルに優先順位を付けるために使用できる。興味のあるＭＢＭＳサービスを提供する。したがって、同じメカニズムを再利用して、ＵＥの興味のあるＭＢＳサービスを提供するセルに優先順位を付けることができ、これにより、標準化の労力を減らすことができる。

提案２１：ＲＡＮ２は、ＵＥの興味のあるＭＢＳサービスを提供する特定のセルに優先順位を付けるために、ＭＢＳ固有のオフセットがＲ基準に適用可能であることに同意する必要があり、これにより、ＬＴＥと同様に、オフセットを「無限大」で設定できる。

［附属書］
ＬＴＥのＳＩＢ１３
ＬＴＥのＳＩＢ１３の内容を図２０－図２２に示す。

ＬＴＥのＳＩＢ１５
ＬＴＥのＳＩＢ１５の内容を図２３に示す。

ＬＴＥのＳＩＢ２０
ＬＴＥのＳＩＢ２０の内容を図２４に示す。

ＬＴＥのＳＣ－ＭＣＣＨ
ＬＴＥのＳＣ－ＭＣＣＨの内容を図２５－図２７に示す。

ＬＴＥでのＭＢＭＳ興味インディケーション
ＬＴＥにおけるＭＢＭＳ興味インディケーションの内容を図２８－図３０に示す。

ＬＴＥでのセル再選択優先処理
ＬＴＥでのｅＭＢＭＳ周波数のセル再選択の優先順位を図３１に示す。

LTEでのセルレベルの優先順位付け
イントラ周波数におけるセルレベルの優先順位付けと、ＣＥ（ｅＭＴＣを含む）におけるＮＢ－ＩｏＴ及びＵＥのＬＴＥでの同等の優先度のイントラ周波数セル再選択を図３２に示す。

ＱｏｆｆｓｅｔＳＣＰＴＭがＳＩＢ５でＳＣＰＴＭ周波数オフセットとして設定される例を図３３に示す。

［付記２］
（１．導入）
ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８で承認された。グループスケジューリングの側面に関して、ＲＡＮ２＃１１４は次の合意に達した。

Ｇ－ＲＮＴＩとＭＢＳセッション間の１対１のマッピングは、ＮＲ ＭＢＳでサポートされている。その他のマッピングは更なる検討が必要である。
Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１対１のマッピングは、ＮＲ ＭＢＳでサポートされている。その他のマッピングは更なる検討が必要である。
ＵＥは複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩをサポートできる。これがＵＥの機能に依存するかどうかは更なる検討が必要である。この合意をＲＡＮ１に通知する。
同じＭＢＳセッションに対応する複数のＭＢＳ ＱｏＳフローを、１つ又は複数のＭＢＳ無線ベアラにマッピングできる。
ＭＣＣＨは、ＮＲ ＭＢＳ配信モード２のＤＬ－ＳＣＨにマッピングされる。
ＭＴＣＨは、ＮＲ ＭＢＳのＰＴＭ送信用に規定されている。
ＭＴＣＨはＤＬ－ＳＣＨにマッピングされる。
ＤＴＣＨは、ＮＲ ＭＢＳのＰＴＰ送信に再利用される。
使用するチャネルに特定のＬＣＩＤスペースが必要かどうかは更なる検討が必要である。
同じＧ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化は、ＮＲ ＭＢＳでサポートされている。
同じＧ－ＣＳ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化がＮＲ ＭＢＳでサポートされるかどうかは更なる検討が必要である。
Ｃ－ＲＮＴＩに関連付けられたさまざまな論理チャネルの多重化／逆多重化は、ＮＲ ＭＢＳでサポートされている。

付記２では、グループスケジューリングで認識された未解決の問題について議論する。これらの未解決の問題は、配信モード１及び配信モード２の共通の問題と見なされることに注意する。したがって、特に明記されていない限り、所見と提案は両方の配信モードに適用される。

（２．議論）
（３．Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間のマッピング）
ＲＡＮ２は、Ｇ－ＲＮＴＩとＭＢＳセッション間、及びＧ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１：１マッピングに同意したが、他のマッピングがサポートされているかどうかは更なる検討が必要である。

最も単純なスキームであり、ＮＲ ＭＢＳのベースラインとして広く再利用されているＬＴＥ ＳＣ－ＰＴＭで採用されている１：１マッピングの利点は、興味のないＭＢＳセッションを受信しようとすることによる不要なＵＥ電力消費を回避することである。例えば、ＴＭＧＩ＃１のみに興味のあるＵＥは、Ｇ－ＲＮＴＩ＃１のみを監視する必要がある。言い換えると、ＵＥは、他のＧ－ＲＮＴＩとスクランブルされたＰＤＣＣＨによって割り当てられたＰＤＳＣＨをデコードしようとはしない。

所見１：Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩからＭＢＳセッションへの１：１マッピングは、ＵＥの消費電力と単純さの観点から有益である。

１：Ｎマッピングに関しては、１つのＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩが複数のＭＢＳセッションを多重化する。例えば、Ｇ－ＲＮＴＩ＃１はＴＭＧＩ＃１とＴＭＧＩ＃２を伝達する。同様のＱｏＳを必要とする一部のＭＢＳセッションが１つのＧ－ＲＮＴＩで送信される可能性があるため、ＮＷの観点から柔軟性が得られる。また、ＵＥが複数のＭＢＳセッションを同時に受信することに興味がある場合、１：ＮマッピングによってＵＥの複雑さが軽減される可能性があることが指摘されている。ただし、そのような最適化が本当に必要かどうかは明確ではない。ＲＡＮ２はすでに「ＵＥは複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩをサポートできる。これがＵＥの機能に依存するかどうかは更なる検討が必要である」ので、複数のＭＣＰＴＴセッションなどを同時に受信する必要があるＵＥはそのような機能（定義されている場合）をサポートするだけである。さらに、１：Ｎマッピングは再送信については非効率であり、例えば、１つのＴＭＧＩのみがＮＡＣＫを受信し、他のＴＭＧＩがＡＣＫを受信する場合、トランスポートブロック全体を再送信する必要がある。

一方、ＴＭＧＩ＃１のみに興味のあるＵＥは、ＴＭＧＩ＃２からデータをまだ受信する必要があるため、ＵＥの消費電力の観点からは最適ではない。つまり、予想よりも大きなＰＤＳＣＨをデコードする必要がある。

所見２：Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩからＭＢＳセッションへの１：Ｎマッピングにより、ＮＷの観点からは限られたケースで柔軟性が得られる可能性があるが、ＵＥの電力消費の観点からは最適ではない。

Ｎ：１マッピングに関しては、複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩが１つのＭＢＳセッションを伝達する。例えば、ＴＭＧＩ＃１はＧ－ＲＮＴＩ＃１とＧ－ＲＮＴＩ＃２に分割されていると考えることができる。ＲＡＮ２は「同じＭＢＳセッションに対応する複数のＭＢＳ ＱｏＳフローを１つ又は複数のＭＢＳ無線ベアラにマッピングできる」に同意した。これは、これらのＱｏＳフローには異なるＱｏＳが必要であると想定している可能性があり、例えば、ビデオストリーミング用の１つのＱｏＳフローと、同じＭＢＳセッション内のテキスト転送用の別のＱｏＳフローなどである。したがって、これらのＱｏＳフローは、例えば、異なる周期性とリソース量を持つ異なるＧ－ＲＮＴＩで送信されることは理にかなっている。ＵＥは対象のＭＢＳセッション（及びＱｏＳフロー）に関連付けられたＧ－ＲＮＴＩのみを監視する必要があるため、ＵＥの消費電力が大幅に増加することは期待できない。

注：所見１０のように１：１マッピングでは、同じＭＢＳセッションに対応し、複数のＭＲＢにマッピングされるすべてのＱｏＳフローは、これらのＱｏＳフローのＱｏＳ要件が異なる場合でも、同じＧ－ＲＮＴＩにマッピングする必要がある。１：１マッピングはほとんどの場合効率的であるが、すべての場合で同じではない場合がある。

所見３：Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩのＭＢＳセッションへのＮ：１マッピングは、さまざまなＱｏＳ要件を持つさまざまなＱｏＳフローに対して効率的であり、ＵＥの電力消費への影響が少ない可能性がある。

上記の所見を考慮すると、Ｎ：１マッピングはサポートする価値があるが、１：Ｎマッピングはあまり有益ではない可能性がある。したがって、ＲＡＮ２は、１：１マッピングに加えて、Ｎ：１マッピングをサポートする必要があるかどうかを議論する必要がある。

提案１：ＲＡＮ２は、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩのＭＢＳセッションへのＮ：１マッピングが追加でサポートされているかどうかを議論する必要がある。

図９に、複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩのＵＥ機能を示す。

（４．複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩのためのＵＥ能力）
ＲＡＮ２は「ＵＥは複数のＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩをサポートできる」ことに同意したが、「これがＵＥの機能に依存するかどうかは更なる検討が必要である」。

ＬＴＥ ＳＣ－ＰＴＭでは、ＵＥ機能ｓｃｐｔｍ－ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎ－ｒ１３は図３４のように定義されている。

ＮＲ ＭＢＳの場合、同様のＵＥ機能をベースラインとして使用できますが、ＢＷＰ／ＣＦＲ（Ｃｏｍｍｏｎ Ｆｒｅｑｕｅｎｃｙ Ｒｅｓｏｕｒｃｅ）の使用など、まだ多くの未解決の問題とＮＲ固有の拡張機能が議論されている。したがって、現時点でＵＥ機能の側面について議論するのは時期尚早である。

所見４：ＵＥ機能については、機能が固まった後に議論する。

（５．ＭＣＣＨ及びＭＴＣＨのＬＣＩＤ及びＬＣＩＤスペース）
ＲＡＮ２は「使用するチャネルに特定のＬＣＩＤスペースが必要かどうかは更なる検討が必要である」とした。ＬＴＥ ｅＭＢＭＳでは、ＭＣＨのＭＣＣＨ（「０００００」）及びＭＴＣＨ（「００００１－１１１００」、あるケースでは「０００００」）、ＤＬ－ＳＣＨのＳＣ－ＭＣＣＨ及びＳＣ－ＭＴＣＨ（「１１００１」）に別々のＬＣＩＤスペースが用意された。ｅＭＢＭＳはＰＤＣＰレイヤをサポートせず、ＲＬＣ－ＵＭモードのみが適用されたため、これらは実行可能である。

ＬＴＥ ＭＢＳＦＮでは、ＭＣＨにＭＣＣＨがない場合、ＭＣＣＨとＭＴＣＨは同じＬＣＩＤ（つまり、「０００００」）を共有できるが、異なるＭＴＣＨには異なるＬＣＩＤ（「００００１－１１１００」）が割り当てられる。「ＭＴＣＨとＭＣＣＨは同じＭＣＨで多重化できる」、「複数のＭＢＭＳサービスは同じＭＣＨにマッピングできる」、つまり、所見１１のように１：Ｎでマッピングするため、ＭＣＣＨと異なるＭＴＣＨを区別するために異なるＬＣＩＤが必要である。言うまでもなく、ＭＣＣＨ／ＭＴＣＨはＭＣＨにマッピングされ、ＤＴＣＨはＤＬ－ＳＣＨにマッピングされるため、ＭＣＣＨ／ＭＴＣＨのＬＣＩＤスペースはユニキャストのＬＣＩＤスペースから分離される。ＭＢＳＦＮのＬＣＩＤ（つまり、ＭＢＭＳエリア固有でありＵＥのグループに共通）がユニキャストの同じＬＣＩＤ（つまり、セル固有及びＵＥ固有）と衝突するのを回避することは有用である。

所見５：ＬＴＥ ＭＢＳＦＮでは、各ＭＴＣＨに異なるＬＣＩＤ（１：Ｎマッピングのため最大３２）があり、ＭＣＨにＭＣＣＨがない場合を除き、ＭＣＣＨのＬＣＩＤはＭＴＣＨで共有されない場合があり、ＭＣＣＨ／ＭＴＣＨのＬＣＩＤスペースはＤＴＣＨの場合は１つから分離される。

ＬＴＥ ＳＣ－ＰＴＭでは、同じＬＣＩＤ（「１１００１」）がＳＣ－ＭＣＣＨ、ＳＣ－ＭＴＣＨ、及び複数のＳＣ－ＭＴＣＨによって共有される。ＳＣ－ＭＣＣＨはＳＣ－ＲＮＴＩで送信され、「ＳＣ－ＭＣＣＨ及びＳＣ－ＭＴＣＨ送信は、それぞれＰＤＣＣＨ上の論理チャネル固有のＲＮＴＩによって示される（ＳＣ－ＭＴＣＨがマッピングされているＤＬ－ＳＣＨの受信に使用されるＴＭＧＩとＧ－ＲＮＴＩの間には１対１のマッピングがある）」ため、ＳＣ－ＭＣＣＨと異なるＳＣ－ＭＴＣＨを区別するために異なるＬＣＩＤは必要ではない。つまり、ＵＥはこれらのＬＣＨをＲＮＴＩで区別できる。ＭＢＳＦＮと同様に、デフォルトでは、個別のＬＣＩＤスペースがＳＣ－ＰＴＭとユニキャスト間のＬＣＩＤ衝突を回避するために機能する。

所見６：ＬＴＥＳＣ－ＰＴＭでは、すべてのＭＴＣＨとＭＣＣＨが同じＬＣＩＤを共有し（１：１マッピングと論理チャネル固有のＲＮＴＩのため）、ＬＣＩＤ（スペース）はＤＴＣＨのＬＣＩＤスペースから分離される。

ＮＲ ＭＢＳの場合、ＬＴＥ ＳＣ－ＰＴＭと同様に、ＲＡＮ２が「ＭＣＣＨのスケジューリング用に新しいＲＮＴＩが定義されている」ことに同意したため、ＭＣＣＨはＲＮＴＩによって区別できる。ＭＴＣＨについても同じことが言える。つまり、ＭＴＣＨは、一般にＧ－ＲＮＴＩによって他の論理チャネルと区別できる。

所見７：ＮＲ ＭＢＳの場合、ＵＥはＬＣＩＤに関係なく、合意されたＭＣＣＨの新しいＲＮＴＩ又はＭＴＣＨのＧ－ＲＮＴＩのいずれかによってこれらの論理チャネルを区別できるため、ＭＣＣＨ及びＭＴＣＨのＬＣＩＤは他の論理チャネルで共有できる。

一方、ＭＴＣＨの場合、ＲＡＮ２は、「同じＭＢＳセッションに対応する複数のＭＢＳ ＱｏＳフローを１つ又は複数のＭＢＳ無線ベアラにマッピングできる」ことに同意した。これにより、図９に示すように、各ＭＲＢが個別のＬＣＨに関連付けられていると単純に想定できる。したがって、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１：１マッピングが採用されている場合でも、ＵＥは同じＭＢＳセッションに属する各ＭＴＣＨを区別できない。つまり、同じＧ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩは、同じＭＢＳセッションに関連付けられた複数のＭＴＣＨを伝送できる。したがって、ＬＴＥ ＳＣ－ＰＴＭのように複数のＭＴＣＨで共有される１つのＬＣＩＤの概念は、ＮＲ ＭＢＳには適用できず、ＬＴＥ ＭＢＳＦＮのようにＭＴＣＨには複数のＬＣＩＤが必要である。

所見８：ＮＲ ＭＢＳの場合、１つのＬＣＩＤを複数のＭＴＣＨで共有することはできない。つまり、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１：１マッピングが想定されている場合でも、同じＭＢＳセッションに属する複数のＭＲＢ／ＭＴＣＨが存在する可能性があるため、複数のＬＣＩＤが必要である。

一方、ＭＴＣＨのＬＣＩＤを定義する方法は、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩとＭＢＳセッション間の１：１マッピングの原則を維持するかどうかにも関係する。１：１マッピングを使用すると、ＵＥは対応するＧ－ＲＮＴＩから各ＭＢＳセッションを知ることができる。したがって、ＬＣＩＤはＭＢＳセッション（又はＧ－ＲＮＴＩ）ごとにグループ化できるため、ＬＣＩＤの数は同じＭＢＳセッションに属するＭＴＣＨの数に等しくなる。例えば、図１０に示すようにＭＢＳセッションの数に関係なく３つのＬＣＩＤである。Ｎ：１マッピングを使用すると、ＵＥは対応するＧ－ＲＮＴＩからの各ＭＢＳセッションも知ることができる。したがって、ＬＣＩＤの数は、同じＧ－ＲＮＴＩにマッピングされたＭＴＣＨの数に等しくなる。例えば、図１０に示すように、ＭＢＳセッションの数に関係なく最大２つのＬＣＩＤになります。１：Ｎマッピングが許可されている場合、ＵＥは各ＭＢＳセッションをＧ－ＲＮＴＩと区別できない。したがって、ＬＣＩＤの数は、すべてのＭＢＳセッションのＭＴＣＨの数と同じである。したがって、１：１又はＮ：１マッピングの場合と比較して、１：Ｎマッピングの場合はより多くのＬＣＩＤが必要になる可能性がある。

所見９：ＮＲ ＭＢＳの場合、ＭＴＣＨのＬＣＩＤの数は、Ｇ－ＲＮＴＩ／Ｇ－ＣＳ－ＲＮＴＩからＭＢＳセッションへのマッピングルール（１：１、Ｎ：１、又は１：Ｎ）に関連する。

所見１０：ＮＲ ＭＢＳの場合、１：１及びＮ：１マッピングルールでは、１：Ｎマッピングと比較して、ＭＴＣＨのＬＣＩＤの数が少なくなる可能性がある。

上記の所見に照らして、各ＭＴＣＨには異なるＬＣＩＤを割り当てる必要がある。これは、ＭＴＣＨのＬＣＩＤの最大数を定義することを意味する。この時点で、前述のＬＴＥ ＭＢＳＦＮによれば、このような最大数は３２と見なすことができるが、より少ない数が望ましい場合がある。

提案２：ＲＡＮ２は、ＭＴＣＨのＬＣＩＤの最大数について議論する必要がある。例えば、可能なベースラインとして、ＬＴＥ ＭＢＳＦＮに基づく３２ＬＣＩＤ未満である。

また、上記の所見の文脈では、ＲＡＮ２は、ＬＣＩＤを不必要に消費することを避けるために、ＭＣＣＨとＭＴＣＨが同じＬＣＩＤを共有する可能性があることに同意する必要がある。

提案３：ＲＡＮ２は、ＭＣＣＨとＭＴＣＨが同じＬＣＩＤを共有する可能性があることに同意する必要がある。つまり、ＵＥは合意された新しいＲＮＴＩによってＭＣＣＨを区別し、Ｇ－ＲＮＴＩによってＭＴＣＨを区別するが、各ＭＴＣＨは対応するＬＣＩＤによって区別される。

次に、残りの問題は、ＭＢＳのＬＣＩＤスペースをユニキャストのＬＣＩＤスペースと共通にするか、それとも分離するかである。提案２のように３２個のＬＣＩＤを想定すると、ｅＬＣＩＤのスペースが大きいため、ｅＬＣＩＤは、ＭＢＳ専用のこのようなコードポイントを消費することが許容される場合がある。つまり、主にＭＡＣ ＣＥの場合は１オクテットｅＬＣＩＤにおいて２５６、主にＤＴＣＨの場合は２オクテットｅＬＣＩＤにおいて６５，５３６である。ただし、実際のメリットが不明であるため、このような個別のＬＣＩＤスペースを準備することには疑問がある。ＵＥのＭＡＣの観点から、ＭＡＣ ＰＤＵを受信して逆多重化した後、各ＭＡＣ ＳＤＵは対応するＲＬＣエンティティに送信される。つまり、これらのＭＡＣ ＳＤＵがＭＣＣＨ、ＭＴＣＨ、又はＤＴＣＨのいずれに関連付けられているかに関係なく、ＵＥの動作は同じである。さらに、ＭＢＳサービスが提供されているかどうかに関係なく、ＬＣＩＤのセット（３２など）がデフォルトでＭＢＳ用に予約されている場合、ＬＣＩＤの使用には非効率的である（つまり、ＭＣＣＨ／ＭＴＣＨはセルで送信される）。

所見１１：ＮＲ ＭＢＳの場合、ＭＢＳ用に個別のＬＣＩＤスペースを使用することの利点は、ＵＥの観点からは明確ではない。

さらに、ＮＲ ＭＢＳはＲｅｌ－１７の単一セル伝送のみをサポートする。つまり、ＳＦＮ（単一周波数ネットワーク）の標準サポートはない。したがって、ｇＮＢは、実装によって、ＭＣＣＨ／ＭＴＣＨのＬＣＩＤ（セル固有であり、すべてのＵＥに共通）を完全に管理して、ＤＴＣＨのＬＣＩＤ（ＵＥ固有）と競合しないようにすることができる。

所見１２：ＮＲ ＭＢＳの場合、標準サポートはＲｅｌ－１７の単一セル送信に制限されているため、ＮＷ実装はＭＢＳのＬＣＩＤを管理して、個別のＬＣＩＤスペースがなくてもユニキャストのＬＣＩＤと競合しないようにすることができる。

一方、将来の保証の観点から、例えば、ＳＦＮの標準サポートの可能性については、ＭＢＳのＬＣＩＤを複数のセル／ｇＮＢ間で調整する必要があるため、ＭＢＳの個別のＬＣＩＤスペースが有益である。つまり、ＬＣＩＤはＭＢＳエリア固有であり、すべてのＵＥに共通であり、ＤＴＣＨのＬＣＩＤ（セル固有及びＵＥ固有）と競合するリスクがある可能性がある。したがって、ＭＢＳの将来の拡張のためだけに、このリリースで個別のＬＣＩＤスペースがＭＣＣＨ／ＭＴＣＨ用に予約されているかどうかを議論する必要がある。

提案４：ＲＡＮ２は、将来の保証（単一周波数ネットワークのサポートなど）のために、ＭＣＣＨとＭＴＣＨのＬＣＩＤスペースがＤＴＣＨのＬＣＩＤスペースとは別のものであるかどうかを議論する必要がある。

ちなみに、ＰＴＰ送信に関しては、ＲＡＮ２は「ＮＲ ＭＢＳのＰＴＰ送信にＤＴＣＨを再利用する」ことに同意した。したがって、ＰＴＰ送信用のＬＣＩＤは、認識された更なる検討が必要であるＲＡＮ２の一部ではないと考えている。つまり、ユニキャストと同じＬＣＩＤスペースを共有するのは非常に自然なことである。ただし、ＲＡＮ２が合意の意図を確認することは有益かもしれない。

提案５：ＲＡＮ２は、ＰＴＰ送信用のＤＴＣＨがユニキャスト用のＤＴＣＨとＬＣＩＤスペースを共有することを確認する必要がある。つまり、少なくともＭＡＣの観点から、ＰＴＰ送信は従来のユニキャストと同じである。

（６．異なる論理チャネルの（逆）多重化）
ＲＡＮ２は「同じＧ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化はＮＲ ＭＢＳでサポートされている」、及び「Ｃ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化はＮＲ ＭＢＳでサポートされている」ことに同意した。ＲＡＮ２は「同じＧ－ＣＳ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化がＮＲ ＭＢＳでサポートされるかどうかは更なる検討が必要である」と残した。

更なる検討が必要であることは、Ｇ－ＣＳ－ＲＮＴＩで異なる論理チャネルを（逆）多重化するために認識されるが、ＲＡＮ２はすでにＧ－ＲＮＴＩで１つに同意している。Ｇ－ＲＮＴＩと同様に、同じＧ－ＣＳ－ＲＮＴＩで異なる論理チャネルの（逆）多重化をサポートすることに問題はない。

提案６：ＲＡＮ２は、Ｇ－ＲＮＴＩと同様に、同じＧ－ＣＳ－ＲＮＴＩに関連付けられた異なる論理チャネルの（逆）多重化がサポートされていることに同意する必要がある。

（７．ＰＴＭ送信用のＤＲＸ）
ＲＡＮ２は「ＮＲ ＭＢＳのＰＴＭ送信の場合、ＤＲＸスキームがユニキャスト送信のＤＲＸから独立しているかどうかにかかわらず更なる検討が必要であり、例えば、Ｇ－ＲＮＴＩごとにサポートされる」ことを残した。ＬＴＥ ＳＣ－ＰＴＭでは、ＳＣ－ＭＴＣＨのＤＲＸはユニキャストのＤＲＸから独立している。言うまでもなく、ＬＴＥ ＭＢＳＦＮでは、ＭＴＣＨのＤＲＸ（つまり、ＭＢＳＦＮサブフレーム）はユニキャストのＤＲＸから独立している。

ＮＲ ＭＢＳの場合、ＭＴＣＨのＤＲＸは複数のＵＥに共通であるのに対し、ユニキャストのＤＲＸはＵＥ固有であるため、同じ原則が適用される。したがって、これらのＤＲＸを調整することは困難で非効率的である。さらに、ＲＡＮ２はすでに「同じＧ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化がＮＲ ＭＢＳでサポートされる」ことに同意しているため、ＭＴＣＨのＤＲＸはＧ－ＲＮＴＩごとに設定される。ＵＥは、ＰＴＭ送信機会（オン期間）でウェイクアップして、関連するＧ－ＲＮＴＩを監視する。したがって、ＲＡＮ２は、ＤＲＸ設定がユニキャストＤＲＸから独立しているＧ－ＲＮＴＩごとに提供されることに同意する必要がある。

提案７：ＲＡＮ２は、ＰＴＭのＤＲＸがユニキャストのＤＲＸから独立しており、Ｇ－ＲＮＴＩごとに設定されていることに同意する必要がある。

（８．配信モード１のＤＲＸパラメータ）
配信モード１でのＭＴＣＨ受信は、基本的にＲＲＣコネクティッド状態のＵＥによって実行され、動的スケジューリングやＨＡＲＱフィードバック／再送信などをサポートするため、その特性はＤＴＣＨ、つまりユニキャストと同様である。したがって、ユニキャストのＤＲＸパラメータ、つまりＤＲＸ設定を再利用することは理にかなっている。

提案８：ＲＡＮ２は、配信モード１を介したＰＴＭ送信のＤＲＸパラメータが、ユニキャスト用の１つ、つまりＤＲＸ設定をベースラインとして使用することに同意する必要がある。

提案８に同意する場合は、配信モード１を介したＰＴＭ送信にどのパラメータを正確に導入する必要があるかを議論する必要がある。図３５に示すように、ＵＬ再送信はＮＲ ＭＢＳに適用できないため、ＵＬ再送信に関連するパラメータは必要ないことは明らかである。さらに、短いＤＲＸはＭＢＳトラフィックに対してそれほど効率的ではない可能性があるため、短いＤＲＸに関連するパラメータも必要ではない。例えば、一般的なＭＢＳトラフィックは一種の音声及びビデオであると想定されるため、これらの送信サイクルは安定している可能性があり、長いＤＲＸに適合する。また、ＬＴＥ ＳＣ－ＰＴＭには、図３６に示すように短いＤＲＸオプションがない。言い換えれば、長いＤＲＸ及びＤＬ再送信に関連するパラメータをそのまま再利用できる。

提案９：提案８（つまり、配信モード１を介したＰＴＭ送信のベースラインとしてのユニキャストＤＲＸ）に加えて、ＲＡＮ２は、ＵＬ再送信及び短いＤＲＸに関連するパラメータが不要であることに同意する必要がある。

（９．配信モード２のＤＲＸパラメータ）
ＲＡＮ２は「ＮＲ ＭＢＳ配信モード２の場合、ＬＴＥ ＳＣ－ＰＴＭ ＤＲＸスキームがベースラインとして使用される」ことに同意した。ＬＴＥ ＳＣ－ＰＴＭのＤＲＸパラメータを図３６に示す。これは、ＤＬ再送信に関連するパラメータの場合、基本的に図３５／提案３０（つまり、配信モード１を介したＰＴＭ送信の場合）と同じである。配信モード２では不要なＤＬ再送に関連するパラメータが除外されている場合、オン期間タイマ、非アクティブタイマ、スケジューリング期間、及び開始オフセットは、大きな問題なしに再利用できる。

所見１３：配信モード２を介したＰＴＭ送信のＤＲＸパラメータのベースライン、つまり、ＳＣ－ＭＴＣＨスケジューリング情報に基づくベースラインを確認できる。

（１０．ＰＴＰ送信用のＤＲＸ）
ＲＡＮ２は「ＰＴＰ送信の場合、ユニキャスト送信のＤＲＸ操作を再利用するかどうかは更なる検討が必要である」ことを残した。一方、ＲＡＮ２はすでに「Ｃ－ＲＮＴＩに関連付けられた異なる論理チャネルの多重化／逆多重化はＮＲ ＭＢＳでサポートされている」ことに同意した。これは、ＭＢＳサービスに属する異なる論理チャネル内に限定されない。つまり、ユニキャストサービスと（逆）多重化される場合がある。さらに、ＲＡＮ２は「ＤＴＣＨはＮＲ ＭＢＳのＰＴＰ送信に再利用される」ことに同意した。これは、ＭＡＣがＤＴＣＨに対する各ＭＡＣ ＳＤＵがＤＲＢ又はＭＲＢのどちらに属しているかを知る必要がないことを意味する。また、ＰＴＰ伝送は、既存のユニキャスト伝送と同じＣ－ＲＮＴＩを使用して伝送されることはすでに明らかである。この意味で、ＰＴＰ送信は、少なくともＤＲＸ操作の観点からは、まったく同じであり、ユニキャスト送信と整合する。

提案１０：ＲＡＮ２は、ＰＴＰ受信の場合、ＵＥはユニキャストのオン期間でのみウェイクアップすることに同意する必要がある。つまり、少なくともＤＲＸの観点からは、追加のオン期間やＰＴＰ送信の特定の拡張はない。

１ ：移動通信システム
１０ ：ＲＡＮ
２０ ：ＣＮ
１００ ：ＵＥ
１１０ ：受信部
１２０ ：送信部
１３０ ：制御部
２００ ：ｇＮＢ
２１０ ：送信部
２２０ ：受信部
２３０ ：制御部
２４０ ：バックホール通信部

Claims (5)

1. 無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置で用いる通信方法であって、
   Ｎ個（Ｎ≧２）のグループＲＮＴＩ（Ｇ－ＲＮＴＩ）が１つのマルチキャストブロードキャストサービス（ＭＢＳ）セッションと対応付けられている場合、前記Ｎ個のＧ－ＲＮＴＩの中から前記受信処理に用いるＭ個（Ｍ≦Ｎ）のＧ－ＲＮＴＩを特定することと、
   前記Ｍ個のＧ－ＲＮＴＩを用いて前記受信処理を行うことと、を有し、
   前記特定することは、
   前記１つのＭＢＳセッションと対応付けられたＫ本（Ｋ≧２）のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）フローの中から、前記ユーザ装置が受信を希望する所望のＱｏＳフローを特定することと、
   前記所望のＱｏＳフローと対応付けられた前記Ｍ個のＧ－ＲＮＴＩを特定することと、
   を含む
   通信方法。
2. 前記受信処理を行うことは、前記ＭＢＳセッションの受信において、前記Ｎ個のＧ－ＲＮＴＩのうち（Ｎ－Ｍ）個のＧ－ＲＮＴＩを前記受信処理に用いることなく、前記Ｍ個のＧ－ＲＮＴＩを用いて前記受信処理を行うことを含む
   請求項１に記載の通信方法。
3. 前記１つのＭＢＳセッションと前記Ｋ本のＱｏＳフローと前記Ｎ個のＧ－ＲＮＴＩとを対応付ける情報を前記基地局から受信することをさらに有する
   請求項１に記載の通信方法。
4. 前記ＭＢＳセッションの識別子と前記所望のＱｏＳフローに関する識別子とを含むメッセージを前記基地局に送信することをさらに有する
   請求項１に記載の通信方法。
5. 無線ネットワーク一時識別子（ＲＮＴＩ）を用いて基地局からの物理下りリンク制御チャネル（ＰＤＣＣＨ）の受信処理を行うユーザ装置であって、
   Ｎ個（Ｎ≧２）のグループＲＮＴＩ（Ｇ－ＲＮＴＩ）が１つのマルチキャストブロードキャストサービス（ＭＢＳ）セッションと対応付けられている場合、前記Ｎ個のＧ－ＲＮＴＩの中から前記受信処理に用いるＭ個（Ｍ≦Ｎ）のＧ－ＲＮＴＩを特定する制御部と、
   前記Ｍ個のＧ－ＲＮＴＩを用いて前記受信処理を行う通信部と、を備え、
   前記制御部は、
   前記１つのＭＢＳセッションと対応付けられたＫ本（Ｋ≧２）のＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）フローの中から、前記ユーザ装置が受信を希望する所望のＱｏＳフローを特定し、
   前記所望のＱｏＳフローと対応付けられた前記Ｍ個のＧ－ＲＮＴＩを特定する
   ユーザ装置。