JP7481588B2 - 通信方法、ユーザ装置、移動通信システム、チップセット、及びプログラム - Google Patents

Description

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

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

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

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

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

第１の態様に係る通信方法は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる通信方法であって、基地局からのＭＢＳセッションの受信を開始したユーザ装置が、前記ＭＢＳセッションの途中から前記受信が開始されたことを示す所定条件が満たされたか否かを判定するステップと、前記ユーザ装置が、前記所定条件が満たされたと判定した場合、前記ＭＢＳセッションの開始から前記受信の開始までの間の欠落パケット群を示す欠落パケット識別情報を前記基地局に送信するステップと、を有する。

第２の態様に係るユーザ装置は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いるユーザ装置であって、基地局からのＭＢＳセッションの受信を開始した後、前記ＭＢＳセッションの途中から前記受信が開始されたことを示す所定条件が満たされたか否かを判定する制御部と、前記所定条件が満たされたと判定した場合、前記ＭＢＳセッションの開始から前記受信の開始までの間の欠落パケット群を示す欠落パケット識別情報を前記基地局に送信する送信部と、を有する。

第３の態様に係る通信方法は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる通信方法であって、ユーザ装置が、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）レグ及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）レグにスプリットされるスプリット無線ベアラを設定する設定情報を基地局から受信するステップと、前記ユーザ装置が、各レグに設定されたＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）モードに基づいて、前記スプリット無線ベアラがＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）ベアラであるか又はＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）ベアラであるかを判定するステップと、を有する。

第４の態様に係るユーザ装置は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いるユーザ装置であって、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）レグ及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）レグにスプリットされるスプリット無線ベアラを設定する設定情報を基地局から受信する受信部と、各レグに設定されたＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）モードに基づいて、前記スプリット無線ベアラがＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）ベアラであるか又はＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）ベアラであるかを判定する制御部と、を有する。

実施形態に係る移動通信システムの構成を示す図である。 実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 実施形態に係るｇＮＢ（基地局）の構成を示す図である。 データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。 実施形態に係るＭＢＳトラフィック配信の概要を示す図である。 実施形態に係る配信モードを示す図である。 実施形態に係るスプリット・マルチキャスト無線ベアラ（ＭＲＢ）を示す図である。 実施形態に係る移動通信システムにおけるＰＤＣＰレイヤの動作を示す図である。 実施形態に係るＣＯＵＮＴ値を示す図である。 実施形態に係るＰＤＣＰデータＰＤＵを示す図である。 ＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。 ＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。 第１実施形態に係るＵＥの動作を示す図である。 第１実施形態に係る移動通信システムの動作の一例を示す図である。 第１実施形態に係るＰＤＣＰステータス報告の構成例１乃至３を示す図である。 第１実施形態に係るＲＲＣメッセージの構成例を示す図である。 第１実施形態に係る動作の第１変更例を示す図である。 第１実施形態に係る動作の第２変更例を示す図である。 第２実施形態に係るＵＥの動作を示す図である。 現在の合意に基づくＰＤＣＰ固定型ＰＴＭ／ＰＴＰの切り替えを示す図である。

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

［第１実施形態］

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（ＰＤＣＰレイヤの動作）
図９は、第１実施形態に係る移動通信システム１におけるＰＤＣＰレイヤの動作を示す図である。

ｇＮＢ２００は、あるＭＢＳセッションのＭＢＳデータをＰＴＭ（マルチキャスト又はブロードキャスト）で複数のＵＥ１００（図９の例では、ＵＥ１００ａ乃至ＵＥ１００ｃ）に送信する。各ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。ＭＢＳ配信のモードは、第１配信モード又は第２配信モードであってもよい。第１配信モードでのＭＢＳ配信は、ＰＴＭレグを用いたものであってもよい。

ｇＮＢ２００は、ＰＤＣＰレイヤにおいて、当該ＭＢＳセッションと対応付けられたＰＤＣＰエンティティ２０１（具体的には、当該ＭＢＳセッションに属するマルチキャスト無線ベアラ（ＭＲＢ）と対応付けられた送信側ＰＤＣＰエンティティ）を有する。ＰＤＣＰエンティティ２０１は、ＭＢＳセッションの送信を開始すると、当該ＭＢＳセッションにおけるＰＤＣＰパケットの送信に応じて更新されるＰＤＣＰ変数を管理する。

各ＵＥ１００は、ＰＤＣＰレイヤにおいて、当該ＭＢＳセッションと対応付けられたＰＤＣＰエンティティ１０１（具体的には、当該ＭＢＳセッションに属するＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ）を有する。各ＰＤＣＰエンティティ１０１（図９の例では、ＰＤＣＰエンティティ１０１ａ乃至ＰＤＣＰエンティティ１０１ｂ）は、ＭＢＳセッションの送信を開始すると、当該ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新されるＰＤＣＰ変数を管理する。

図１０に示すように、ＰＤＣＰ変数は、ＰＤＣＰシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号（ＨＦＮ）と、ＰＤＣＰシーケンス番号（ＰＤＣＰ ＳＮ）と、からなるカウント値（ＣＯＵＮＴ値）であってもよい。例えば、ＣＯＵＮＴ値は３２ビットのビット長を有し、ＰＤＣＰ ＳＮは１２ビット又は１８ビットのビット長（ＳＮ＿ｌｅｎｇｔｈ）を有し、ＨＦＮはＣＯＵＮＴ値のビット長からＰＤＣＰ ＳＮのビット長を減じたビット長を有する。ＰＤＣＰ ＳＮのビット長は、ＲＲＣシグナリングにより設定されてもよい。なお、用語「ＰＤＣＰ変数」は、ＣＯＵＮＴ値を指す場合に限らず、ＰＤＣＰレイヤで扱う各種の変数（ＨＦＮ又はＰＤＣＰ ＳＮ等）を指す用語としても用いられる。

図１１は、ＭＢＳデータを構成するＰＤＣＰパケット、具体的には、ＰＤＣＰデータＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）を示す図である。図１１に示すように、ＰＤＣＰデータＰＤＵは、ＰＤＣＰ ＳＮと、データと、ＭＡＣ－Ｉとを有する。ＰＤＣＰ ＳＮは、ＰＤＣＰデータＰＤＵに順次付与されるシーケンス番号である。データは、ＰＤＣＰ ＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）に相当する。ＭＡＣ－Ｉは、メッセージ認証コードに相当する。ＰＤＣＰデータＰＤＵは、ＭＡＣ－Ｉを有していない場合がある。このように、ＰＤＣＰデータＰＤＵは、ＰＤＣＰ ＳＮを有するものの、ＨＦＮを有していない。そのため、ｇＮＢ２００及びＵＥ１００のそれぞれは、ＰＤＣＰデータＰＤＵの送受信に応じてＨＦＮを更新、具体的には、ＰＤＣＰシーケンス番号が一周する度にカウントアップする必要がある。

図１２は、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）において受信したＰＤＣＰデータＰＤＵのＣＯＵＮＴ値であるＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。ここで、受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮをＲＣＶＤ＿ＳＮと呼ぶ。

第１に、
ＲＣＶＤ＿ＳＮ＜ＳＮ（ＲＸ＿ＤＥＬＩＶ）－Ｗｉｎｄｏｗ＿Ｓｉｚｅ
である場合、
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）＋１
である。ここで、ＲＸ＿ＤＥＬＩＶは、受信待ちであって、未だ上位レイヤに提供していないＰＤＣＰ ＳＤＵのうち最も古いものを表す変数である。ＲＸ＿ＤＥＬＩＶの初期値はゼロである。Ｗｉｎｄｏｗ＿Ｓｉｚｅは、リオーダリングウィンドウのサイズを示す定数である。

第２に、
ＲＣＶＤ＿ＳＮ≧ＳＮ（ＲＸ＿ＤＥＬＩＶ）＋Ｗｉｎｄｏｗ＿Ｓｉｚｅ
である場合、
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）－１
である。

第３に、上記のいずれの条件も満たされない場合、
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）
である。

そして、
ＲＣＶＤ＿ＣＯＵＮＴ＝［ＲＣＶＤ＿ＨＦＮ，ＲＣＶＤ＿ＳＮ］
にセットされる。

図１３は、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。

まず、受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰ ＰＤＵを受信すると、当該ＰＤＣＰ ＰＤＵに対して、カウント値（ＲＣＶＤ＿ＣＯＵＮＴ）を用いたセキュリティ処理（具体的には、ｄｅｃｉｐｈｅｒｉｎｇ／ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎ）を行い（ステップＳ１１）、ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎに失敗した場合（ステップＳ１２：Ｙｅｓ）、上位レイヤにｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎ失敗を通知するとともに当該ＰＤＣＰ ＰＤＵを破棄する（ステップＳ１３）。

受信側ＰＤＣＰエンティティ１０１は、ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎに成功した場合（ステップＳ１２：Ｎｏ）、カウント値（ＲＣＶＤ＿ＣＯＵＮＴ）がＲＸ＿ＤＥＬＩＶよりも小さい場合（ステップＳ１４：Ｙｅｓ）、又は、ＲＣＶＤ＿ＣＯＵＮＴが受信済みである場合（ステップＳ１６：Ｙｅｓ）、当該ＰＤＣＰ ＰＤＵを破棄する（ステップＳ１５）。

次に、受信側ＰＤＣＰエンティティ１０１は、破棄しなかったＰＤＣＰ ＰＤＵを受信バッファに格納し（ステップＳ１７）、「ＲＣＶＤ＿ＣＯＵＮＴ≧ＲＸ＿ＮＥＸＴ」である場合（ステップＳ１８：Ｙｅｓ）、ＲＸ＿ＮＥＸＴ＝ＲＣＶＤ＿ＣＯＵＮＴ＋１に更新する（ステップＳ１９）。ここで、ＲＸ＿ＮＥＸＴは、次に受信することが期待されるＰＤＣＰ ＳＤＵのカウント値（ＲＣＶＤ＿ＣＯＵＮＴ）を示す変数である。ＲＸ＿ＮＥＸＴの初期値はゼロである。Ｏｕｔ－ｏｆ－ｏｒｄｅｒ ｄｅｌｉｖｅｒｙが設定（Ｃｏｎｆｉｇｕｒｅｄ）されている場合（ステップＳ２０：Ｃｏｎｆｉｇｕｒｅｄ）、受信側ＰＤＣＰエンティティ１０１は、当該ＰＤＣＰ ＰＤＵをヘッダ逆圧縮後、上位レイヤに渡す（ステップＳ２１）。具体的には、受信側ＰＤＣＰエンティティ１０１は、ＲＲＣで“ｏｕｔＯｆＯｒｄｅｒＤｅｌｉｖｅｒｙ”が設定されている場合に、Ｓ２１の動作を行う。Ｏｕｔ ｏｆ ｏｒｄｅｒ ｄｅｌｉｖｅｒｙは、順序制御を行わずに上位レイヤにパケットを渡す動作である。よって、ステップＳ２１のように、パケットを受信してバッファに格納したら直ぐに上位レイヤに当該パケットを渡す。なお、ステップＳ２０が”Ｎｏ”の場合、順序制御を行うことになる。

受信側ＰＤＣＰエンティティ１０１は、「ＲＣＶＤ＿ＣＯＵＮＴ＝ＲＸ＿ＤＥＬＩＶ」である場合（ステップＳ２２：Ｙｅｓ）、ＣＯＵＮＴ＝ＲＸ＿ＤＥＬＩＶから始まる連続するＣＯＵＮＴの全てのＰＤＣＰ ＳＤＵをヘッダ逆圧縮後、上位レイヤに渡し（ステップＳ２３）、ＲＸ＿ＤＥＬＩＶを、上位レイヤに渡していない最初の（最も若い）ＣＯＵＮＴ値に更新する（ステップＳ２４）。

受信側ＰＤＣＰエンティティ１０１は、Ｔ－Ｒｅｏｒｄｅｒｉｎｇが動作中であって、「ＲＸ＿ＤＥＬＩＶ≧ＲＸ＿ＲＥＯＲＤ」である場合（ステップＳ２５：Ｙｅｓ）、Ｔ－Ｒｅｏｒｄｅｒｉｎｇをｓｔｏｐ及びｒｅｓｅｔする（ステップＳ２６）。ここで、Ｔ－Ｒｅｏｒｄｅｒｉｎｇは、ＰＤＣＰデータＰＤＵの欠落を検出するために用いるタイマである。ＲＸ＿ＲＥＯＲＤは、Ｔ－ＲｅｏｒｄｅｒｉｎｇをトリガしたＰＤＣＰデータＰＤＵに関連付けられたＣＯＵＮＴ値に続くＣＯＵＮＴ値を示す変数である。

受信側ＰＤＣＰエンティティ１０１は、Ｔ－Ｒｅｏｒｄｅｒｉｎｇが停止中であって、「ＲＸ＿ＤＥＬＩＶ＜ＲＸ＿ＲＥＯＲＤ」である場合（ステップＳ２７：Ｙｅｓ）、ＲＸ＿ＲＥＯＲＤ＝ＲＸ＿ＮＥＸＴに更新するとともにＴ－Ｒｅｏｒｄｅｒｉｎｇを始動（ｓｔａｒｔ）する。

（移動通信システムの動作）
上述のような構成及び動作を前提として、第１実施形態に係る移動通信システム１の動作について説明する。

図９に示す動作シナリオにおいて、ＵＥ１００（ＵＥ１００ａ乃至ＵＥ１００ｃのいずれか）は、必ずしも、ｇＮＢ２００がＭＢＳセッション（マルチキャストセッション又はブロードキャストセッション）の提供を開始した時点からＭＢＳ受信を開始できるとは限らない。例えば、いずれかのＵＥ１００は、ＭＢＳセッションの途中からＭＢＳ受信を開始し得る。その場合、当該ＵＥ１００は、ＭＢＳセッションの開始（提供開始）からＭＢＳ受信の開始までの間の各パケット（例えば、各ＰＤＣＰデータＰＤＵ）を受信できず、当該各パケットが欠落した状態になる。

ここで、当該ＭＢＳセッションがストリーミングデータ配信のためのセッションである場合、パケットの欠落は特に問題はない。これに対し、当該ＭＢＳセッションがソフトウェア配信等のファイルダウンロードのためのセッションであるような場合、当該ファイルが不完全な状態となることは問題である。第１実施形態は、ＡＳレイヤにおいて欠落パケット群をＵＥ１００に再送信可能とする実施形態である。

図１４は、第１実施形態に係るＵＥ１００の動作を示す図である。ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。但し、ＵＥ１００は、ｇＮＢ２００への送信を行う時点ではＲＲＣコネクティッド状態にあるものとする。ＭＢＳ配信のモードは、第１配信モードであってもよい。また、当該ＭＢＳ配信のモードは、第２配信モードであってもよい。

ステップＳ１において、ＵＥ１００は、ｇＮＢ２００からのＭＢＳセッション（マルチキャストセッション又はブロードキャストセッション）の受信を開始する。すなわち、ＵＥ１００は、ｇＮＢ２００からＰＴＭで送信されるＭＢＳデータの受信（ＭＢＳ受信）を開始する。ＵＥ１００は、ＭＢＳ受信を開始する際に、当該ＭＢＳセッションと対応付けられたマルチキャスト無線ベアラ（ＭＲＢ）を扱う受信側ＰＤＣＰエンティティ１０１を確立する。

ステップＳ２において、ＵＥ１００は、当該ＭＢＳセッションの途中からＭＢＳ受信が開始されたことを示す所定条件が満たされたか否かを判定する。所定条件が満たされていないと判定された場合（ステップＳ２：Ｎｏ）、ＵＥ１００は、ステップＳ３及びＳ４の処理を行わずにＭＢＳ受信を継続する。

所定条件は、当該ＭＢＳセッションに途中から参加したという条件であってもよい。ＵＥ１００は、例えば、下記の方法１乃至１０のいずれかにより、当該ＭＢＳセッションに途中から参加したことを判定できる。

方法１：ＵＥ１００は、第１配信モード（ＤＭ１）の場合、ＮＡＳプロシージャによりＭＢＳセッション参加した後、一定期間内（例えば直後）に、ｇＮＢ２００からのＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎでＭＢＳ設定（例えば、ＭＲＢ設定）が行われた場合は当該ＭＢＳセッションに途中参加した（可能性が高い）と判定でき、一定期間よりも後にＭＢＳ設定が行われた場合は当該ＭＢＳセッションに最初から参加した（可能性が高い）と判定できる。当該一定期間はｇＮＢ２００又はＡＭＦ３００Ａから、ＵＥ１００に設定されてもよい。当該一定期間はタイマ値（例えば、時間の範囲を示すタイマ値）でもよく、もしくはカウンタ値（例えば、システムフレーム番号の範囲を示すカウンタ値）であってもよい。

方法２：ＵＥ１００は、第１配信モード（ＤＭ１）の場合、ＮＡＳプロシージャによりＭＢＳセッション参加した後に、当該ＭＢＳセッションの開始（アクティブ化）を示すＧｒｏｕｐ Ｎｏｔｉｆｉｃａｔｉｏｎ（ページング）をモニタし、Ｇｒｏｕｐ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した後にＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎでＭＢＳ設定（例えば、ＭＲＢ設定）が行われた場合は当該ＭＢＳセッションに最初から参加したと判定でき、Ｇｒｏｕｐ Ｎｏｔｉｆｉｃａｔｉｏｎを受信せずにＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎでＭＢＳ設定（例えば、ＭＲＢ設定）が行われた場合は当該ＭＢＳセッションに途中から参加した（可能性が高い）と判定できる。

方法３：ＵＥ１００は、第２配信モード（ＤＭ２）の場合、セッション開始に伴うＣｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ（ＭＣＣＨ変更通知）を受信した後にＭＣＣＨで該当ＭＢＳ設定（例えば、ＭＴＣＨスケジューリング設定）を受信した場合は当該ＭＢＳセッションに最初から参加したと判定でき、Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎを受信せずにＭＣＣＨを確認した結果、既に該当ＭＢＳ設定が存在した場合は当該ＭＢＳセッションに途中から参加したと判定できる。

方法４：ＵＥ１００は、ＮＡＳプロシージャによるＭＢＳセッション参加プロシージャにおいて、ＵＥ１００からの参加要求に対してＡＭＦ３００Ａが許可する際に、セッションが送信中（ａｃｔｉｖｅ）であることを示す情報、セッションが停止中（ｓｕｓｐｅｎｄ、ｉｎａｃｔｉｖｅ、又はｃｏｎｆｉｇｕｒｅｄ）であることを示す情報をＡＭＦ３００Ａから取得することで、当該ＭＢＳセッションに最初から参加したのか、途中から参加したのかを判定できる。

方法５：ＵＥ１００が予め保持しているＵＳＤ（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）において、ＭＢＳセッションの（概ねの）開始時間が記載されている場合、ＵＥ１００は、当該ＵＳＤの情報から、当該ＭＢＳセッションに最初から参加したのか、途中参加したのかを判定できる。

方法６：ＵＥ１００は、上位レイヤ（例えば、アプリケーションレイヤ）から、ファイルが完全ではないこと（復元が不可能であること）を通知された場合、当該ＭＢＳセッションに途中から参加したと判定できる。当該通知は、アプリケーションレイヤからＮＡＳレイヤへ通知され、ＮＡＳレイヤからＡＳレイヤへ通知されてもよい。

方法７：ＵＥ１００において、ＡＳレイヤは、ＮＡＳレイヤから当該ＭＢＳセッションに途中から参加したことを通知された場合、ＡＳは当該ＭＢＳセッションに途中から参加したことを把握できる。

方法８：ＵＥ１００は、ｇＮＢ２００から当該ＭＢＳセッションが途中（又は開始済み）であることが通知されてもよい。例えば第１配信モード（ＤＭ１）の場合、ｇＮＢ２００がＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎにおいてＭＢＳ設定（例えば、ＭＲＢ設定）を行う時に、当該ＭＢＳ設定（例えば、ＭＲＢ設定）に紐づいた「途中参加フラグ」（もしくは「最初から参加していることを示すフラグ」）をＵＥ１００に通知することにより、ＵＥ１００は、途中参加か否かを判定できる。

方法９：ｇＮＢ２００は、当該ＭＢＳセッション（例えば、当該ＭＲＢ）のファイルリカバリが可能である旨（又は当該ＭＢＳセッションの過去データを保持している旨、又は当該ＭＢＳセッションのファイルリカバリを許可する旨）の通知もしくは情報提供（ＳＩＢ及び／又はＭＣＣＨで報知してもよく、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎでもよい）をＵＥ１００に対して行い、ＵＥ１００は、当該通知に基づいて、暗示的に、当該ＭＢＳセッションに途中参加したと判定してもよい。このような通知は、後述の第１変更例における通知であってもよい。

方法１０：ＭＢＳデータのヘッダ（例えばＰＤＣＰデータＰＤＵのヘッダ）に、当該セッションにおいて、最初のパケットなのか、途中の（又は、最初でない）パケットなのかを示す、１ビットフラグを規定してもよい。ＵＥ１００は、ＭＢＳデータを受信し、当該ＭＢＳデータのヘッダに格納された当該フラグにより、当該ＭＢＳセッションに途中参加したのか否かを判定できる。

所定条件は、当該ＭＢＳセッションについてＵＥ１００が最初に受信したＭＢＳパケットのシーケンス番号（ＳＮ）が初期値ではないという条件であってもよい。例えば、ＵＥ１００は、当該ＭＢＳセッションについてＵＥ１００が最初に受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮがゼロではない場合、当該ＭＢＳセッションの途中からＭＢＳ受信が開始されたと判定してもよい。ここで、ゼロは、初期値の一例である。なお、ＰＤＣＰ ＳＮに限らず、ＲＬＣ ＳＮを用いた判定としてもよいが、以下においてシーケンス番号がＰＤＣＰ ＳＮである一例について主として説明する。また、シーケンス番号は、上述のＣＯＵＮＴ値（ＨＦＮ＋ＰＤＣＰ ＳＮ）であってもよい。

所定条件が満たされたと判定した場合（ステップＳ２：Ｙｅｓ）、ステップＳ３において、ＵＥ１００は、当該ＭＢＳセッションの開始からＭＢＳ受信の開始までの間の欠落パケット群を示す欠落パケット識別情報をｇＮＢ２００に送信する。欠落パケット識別情報は、欠落パケット群のうち最後の欠落パケットのシーケンス番号（例えば、ＰＤＣＰ ＳＮ）を示す情報を含む。これにより、ｇＮＢ２００は、ＵＥ１００がどのパケット（例えば、ＰＤＣＰデータＰＤＵ）までの受信ができていないのかを把握できる。最後の欠落パケットのシーケンス番号を示す情報は、最後の欠落パケットのシーケンス番号そのものであってもよい。また、当該最後の欠落パケットのシーケンス番号を示す情報は、最後の欠落パケットのシーケンス番号に１を加えた値（すなわち、ＵＥ１００が最初に受信したパケットのシーケンス番号）であってもよい。

ここで、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）は、欠落パケット識別情報を含むＰＤＣＰ制御ＰＤＵをＰＤＣＰステータス報告としてｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１に送信してもよい。ベアラ（ＭＲＢ）とＰＤＣＰエンティティとは１対１の関係にあるため、当該ベアラ上でＰＤＣＰステータス報告を送信することにより、欠落パケット識別情報を円滑にｇＮＢ２００に通知できる。例えば、ＵＥ１００は、図８に示すように、ＰＴＭレグでＭＢＳデータを受信し、ＰＤＣＰステータス報告をＰＴＰレグでｇＮＢ２００に送信してもよい。

或いは、ＵＥ１００は、欠落パケット識別情報と、当該欠落パケット識別情報と対応付けられた識別子と、を含むＲＲＣメッセージをｇＮＢ２００に送信してもよい。当該識別子は、当該ＭＢＳセッションのＭＢＳセッション識別子及び当該ＭＢＳセッションがマッピングされたＭＲＢに関する識別子（例えば、ＭＲＢ識別子、ＭＴＣＨ識別子、又はＱｏＳフロー識別子等）の少なくとも一方を含んでもよい。当該ＲＲＣメッセージは、例えば、ＭＢＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎメッセージ又はＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージであってもよい。

ＵＥ１００から欠落パケット識別情報を受信したｇＮＢ２００は、当該欠落パケット識別情報により示される欠落パケット群をＵＥ１００に送信（再送信）する。

ステップＳ４において、ＵＥ１００は、ｇＮＢ２００から欠落パケット群を受信する。ＵＥ１００は、ｇＮＢ２００からＰＴＰで送信される欠落パケット群を受信してもよい。例えば、ＵＥ１００は、図８に示すように、ＰＴＭレグでＭＢＳデータを受信し、ｇＮＢ２００が再送信する欠落パケット群をＰＴＰレグで受信してもよい。但し、ＵＥ１００は、ｇＮＢ２００が再送する欠落パケット群をＰＴＭレグで受信してもよい。

このように、第１実施形態によれば、ＵＥ１００は、ＭＢＳセッションの途中からＭＢＳ受信が開始されたことを示す所定条件が満たされたと判定した場合、当該ＭＢＳセッションの開始から当該ＭＢＳ受信の開始までの間の欠落パケット群を示す欠落パケット識別情報をｇＮＢ２００に送信する。これにより、ｇＮＢ２００が欠落パケット群の再送信をＵＥ１００に対して行うことが可能である。

図１５は、第１実施形態に係る移動通信システム１の動作の一例を示す図である。

ステップＳ１０１において、ｇＮＢ２００は、ＭＢＳセッション（マルチキャストセッション又はブロードキャストセッション）の提供を開始する。具体的には、ｇＮＢ２００は、当該ＭＢＳセッションについてＰＴＭでのＭＢＳデータの送信を開始する。図１５において、当該ＭＢＳセッションの受信に興味のある他のＵＥが、当該ＭＢＳセッションの開始時点からＭＢＳ受信を開始（ステップＳ１０２）する一例を示している。当該他のＵＥが最初に受信したパケットのシーケンス番号（ＳＮ）はゼロであるものとする。

なお、ｇＮＢ２００は、送信したパケットをそのシーケンス番号と対応付けて保持することにより、欠落パケット群の再送信に備えるものとする。例えば、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、ＰＤＣＰ ＳＮを含むＰＤＣＰデータＰＤＵを送信するとともに、バッファに当該ＰＤＣＰデータＰＤＵの複製を保持する。

ステップＳ１０３において、ＵＥ１００は、当該ＭＢＳセッションの受信を開始する。ＵＥ１００が最初に受信したパケットのシーケンス番号（ＳＮ）はＸであるものとする。

ステップＳ１０４において、ＵＥ１００は、欠落パケット群を特定する。ＵＥ１００は、ｇＮＢ２００から最初に受信したパケットのＳＮを確認し、データの欠落があることを検知してもよい。例えば、ｇＮＢ２００がＳＮ＝０から送信を開始していると仮定した場合、ＵＥ１００がｇＮＢ２００から最初に受信したパケットがＳＮ＝１００であれば、ＳＮ＝０～９９のパケット群が欠落していると判定できる。

ステップＳ１０５において、ＵＥ１００は、ステップＳ１０３で特定した欠落パケット群を示す欠落パケット識別情報をｇＮＢ２００に送信する。ＵＥ１００は、欠落パケット識別情報をＰＤＣＰ制御ＰＤＵ（ＰＤＣＰステータス報告）又はＲＲＣメッセージによりｇＮＢ２００に送信する。

図１６に、第１実施形態に係るＰＤＣＰステータス報告の構成例１乃至３を示す。ＰＤＣＰ制御ＰＤＵ（ＰＤＣＰステータス報告）の先頭に、当該ＰＤＣＰ ＰＤＵが制御ＰＤＵであることを示すＤ／Ｃフィールドと、当該ＰＤＣＰ ＰＤＵがＰＤＣＰステータス報告であることを示すＰＤＵタイプフィールドとが設けられていてもよい。ＰＤＵタイプフィールドには、ＭＢＳ専用のＰＤＣＰステータス報告であることを示す情報がセットされてもよい。

構成例１において、ＰＤＣＰステータス報告は、ＦＭＣ（Ｆｉｒｓｔ ｍｉｓｓｉｎｇ ＣＯＵＮＴ）及びビットマップの各フィールドを含む。ＦＭＣフィールドには、リオーダリングウィンドウ内で最初に欠落しているＰＤＣＰ ＳＤＵのＣＯＵＮＴ値、すなわち、ＲＸ＿ＤＥＬＩＶがセットされる。ビットマップフィールドには、各ＰＤＣＰ ＰＤＵと対応付けられたビットがセットされ、正しく受信した場合は“１”がセットされ、欠落した場合は“０”がセットされる。

構成例２において、ＰＤＣＰステータス報告は、ＦＭＣ及びＬＭＣ（Ｌａｓｔ ｍｉｓｓｉｎｇ ＣＯＵＮＴ）の各フィールドを含む。ＬＭＣフィールドには、欠落パケット群のうち最後のパケットのシーケンス番号（ＣＯＵＮＴ値）がセットされる。ＬＭＣフィールドには、最初に受信成功したパケットのＣＯＵＮＴ値（ＬＭＣ＋１、例えばＦｉｒｓｔ Ｓｕｃｃｅｓｓｆｕｌ ＣＯＵＮＴ： ＦＳＣ）がセットされてもよい。上述の構成例１はビットマップフィールドのビット長が長くなり得る（例えば、２００パケット分のビットマップは２００ビットになる）が、ビットマップフィールドに代えてＬＭＣフィールドを設けることにより、ＰＤＣＰステータス報告のビット長を短縮できる。

構成例３において、ＰＤＣＰステータス報告は、ＬＭＣフィールドを含む。ｇＮＢ２００は、最初の送信パケット（ＦＭＣに相当）は知っているので、ＬＭＣが分かれば、どこからどこまでのデータ欠落があるのかを把握できる。構成例３によれば、ＦＭＣフィールドを不要とすることで、構成例２よりもＰＤＣＰステータス報告のビット長を短縮できる。

図１７に、第１実施形態に係るＲＲＣメッセージの構成例を示す。例えば、ＲＲＣメッセージは、ＵＥ１００がｇＮＢ２００に送信するＭＢＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎメッセージ又はＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージであってもよい。

当該ＲＲＣメッセージは、ＭＲＢの識別子（ベアラＩＤ、ＲＬＣ ｃｈａｎｎｅｌ ＩＤ、ＬＣＩＤ等）もしくはＭＢＳセッション識別子（ＴＭＧＩ等）と、欠落パケット識別情報とを含む。欠落パケット識別情報の構成は、上述のＰＤＣＰステータス報告の構成と同様であってもよい。このようなＲＲＣメッセージをＲＲＣレイヤで生成するために、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は欠落パケット群に関する情報をＲＲＣレイヤに提供してもよい。

図１５に戻り、ｇＮＢ２００は、ステップＳ１０５でＵＥ１００から欠落パケット識別情報を受信する。

ステップＳ１０６において、ｇＮＢ２００は、当該欠落パケット識別情報により示される欠落パケット群をＵＥ１００に送信（再送信）する。ＵＥ１００は、ｇＮＢ２００から欠落パケット群を受信する。

なお、ｇＮＢ２００のバッファ容量の制限等に起因して、ｇＮＢ２００が欠落パケット群の全てをＵＥ１００に再送信できない場合も想定される。そのような場合に限り、ＵＥ１００は、ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）等の上位レイヤメカニズムを使ってファイルリカバリを試みてもよい。ＦＬＵＴＥは、ＩＥＴＦ ＲＦＣ６７２６／ＲＦＣ３９２６で規定された上位レイヤのデータ復旧メカニズムであり、ＵＥ１００は欠落したデータ（ＦＬＵＴＥ Ｂｌｏｃｋ）を、後からユニキャストでアプリケーションサーバから取得する。

［第１変更例］
ｇＮＢ２００のバッファ容量の制限を考慮すると、無制限にＵＥ１００がｇＮＢ２００に再送信を要求可能とすることは好ましくないと考えられる。そのため、ｇＮＢ２００は、ＵＥ１００による欠落パケット識別情報の送信を制御するための情報をＵＥ１００に送信してもよい。

図１８は、第１実施形態に係る移動通信システム１の動作の第１変更例を示す図である。ここでは、上述の第１実施形態との相違点を説明する。

ステップＳ１３１において、ｇＮＢ２００は、ＵＥ１００による欠落パケット識別情報の送信を制御するための制御設定情報をＵＥ１００に送信する。ｇＮＢ２００は、制御設定情報を、ＳＩＢ、ＭＣＣＨ、ＲＲＣメッセージ（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）、ＭＡＣヘッダ、ＭＡＣ ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）、又はＰＤＣＰ制御ＰＤＵでＵＥ１００に送信してもよい。ｇＮＢ２００は、制御設定情報と共に、当該制御設定情報と対応付けられた識別子をＵＥ１００に送信してもよい。当該識別子は、ＭＢＳセッションのＭＢＳセッション識別子及び当該ＭＢＳセッションがマッピングされたＭＲＢに関する識別子（例えば、ＭＲＢ識別子、ＭＴＣＨ識別子、又はＱｏＳフロー識別子等）の少なくとも一方を含んでもよい。

例えば、ステップＳ１３１において、ｇＮＢ２００は、ＵＥ１００が欠落パケット識別情報により示すことを許可する欠落パケット群のシーケンス番号の範囲を示す範囲情報を制御設定情報としてＵＥ１００に送信してもよい。ステップＳ１０５において、ＵＥ１００は、ｇＮＢ２００からの範囲情報に基づいて、ｇＮＢ２００により指定された範囲内の欠落パケット群を示す欠落パケット識別情報を送信してもよい。

このように、ｇＮＢ２００は、データリカバリのために通知してもよい過去のＳＮの範囲（例えば、１，０００パケット（ＳＮ）以内等）をＵＥ１００に設定又は通知する。当該範囲は、ｇＮＢ２００のデータバッファ量（能力）に応じて定められてもよい。ｇＮＢ２００は、自身がバッファしているデータのうち最も小さいシーケンス番号を示す情報を範囲情報として送信してもよい。また、ｇＮＢ２００は、自身がバッファしているデータのパケット個数を示す情報を範囲情報として送信してもよい。ＵＥ１００は、ｇＮＢ２００から設定又は通知された範囲内で欠落パケット識別情報をｇＮＢ２００に送信する。例えば、ＵＥ１００は、欠落パケット識別情報に含めるＦＭＣとして、当該範囲の下限値をセットしてもよい。或いは、ＵＥ１００は、自身が特定した欠落パケット群が、ｇＮＢ２００から設定又は通知された範囲を超える場合、欠落パケット識別情報をｇＮＢ２００に送信しないと決定してもよい。その場合、ＵＥ１００は、上述のような上位レイヤのファイルリカバリ（ＦＬＵＴＥ等）を実行することを決定してもよい。ここで、ＵＥ１００において、ＡＳレイヤは、上位レイヤ（ＮＡＳ ｏｒ アプリケーション）に対して、ＡＳレイヤにおけるファイルリカバリが不可能であること（完全性が担保できないこと）を報告してもよい。

或いは、ステップＳ１３１において、ｇＮＢ２００は、ＭＢＳセッションの最初の配信パケットをｇＮＢ２００が保持（バッファ）しているか否かを示す通知情報を制御設定情報としてＵＥ１００に送信してもよい。ＵＥ１００は、ｇＮＢ２００からの通知情報に基づいて、欠落パケット識別情報をｇＮＢ２００に送信するか否かを決定してもよい。当該最初の配信パケットをｇＮＢ２００が保持していない場合、ＡＳレイヤでのデータリカバリでは完全にはリカバリできない。そのため、ＵＥ１００は、当該最初の配信パケットをｇＮＢ２００が保持していないことを通知情報が示す場合、欠落パケット識別情報をｇＮＢ２００に送信しないと決定してもよい。これに対し、ＵＥ１００は、当該最初の配信パケットをｇＮＢ２００が保持していることを通知情報が示す場合、欠落パケット識別情報をｇＮＢ２００に送信してもよい（ステップＳ１０５）。当該通知情報は、当該最初の配信パケットとして、シーケンス番号がゼロである配信パケットをｇＮＢ２００が保持しているか否かを示す情報であってもよい。すなわち、当該通知情報は、最初のパケットから再送可能か否かを通知する情報であればよい。

［第２変更例］
ＵＥ１００は、欠落パケット識別情報をＰＤＣＰ制御ＰＤＵ（ＰＤＣＰステータス報告）としてｇＮＢ２００に送信するためには、ｇＮＢ２００とのＰＴＰ通信パスを有している必要がある。例えば、ＰＴＰ通信パスは、図８に示すＰＴＰレグであってもよい。そのため、ｇＮＢ２００とのＰＴＰ通信パスを有していないＵＥ１００は、欠落パケット識別情報をｇＮＢ２００に送信可能とするために、ＰＴＰ通信パスの確立をｇＮＢ２００に要求してもよい。

図１９は、第１実施形態に係る移動通信システム１の動作の第２変更例を示す図である。ここでは、上述の第１実施形態との相違点を説明する。

ステップＳ１５１において、ＵＥ１００は、ＭＢＳセッションと対応付けられたＰＴＰ通信パスを有していない場合、すなわち、ＰＴＭのみのＭＲＢでＭＢＳデータ受信を行っている場合、ＰＴＰ通信パスの設定を要求するための要求情報をｇＮＢ２００に送信する。ＵＥ１００は、シグナリング無線ベアラ（ＳＲＢ）上で伝送されるＲＲＣメッセージにより要求情報をｇＮＢ２００に送信してもよい。当該ＲＲＣメッセージは、ＭＢＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎメッセージ又はＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージであってもよい。要求情報は、ＰＴＰレグの設定を要求する情報、データリカバリを行いたい旨の情報、上りリンク送信が必要であることを示す情報、又はスプリットＭＲＢが必要であることを示す情報であってもよい。当該ＲＲＣメッセージは、当該要求情報と対応付けられた識別子をさらに含んでもよい。当該識別子は、対象のＭＲＢのベアラＩＤ、ＲＬＣ Ｃｈａｎｎｅｌ ＩＤ、ＬＣＩＤ、又はＭＢＳセッション識別子（例えば、ＴＭＧＩ）であってもよい。

ステップＳ１５２において、ｇＮＢ２００は、ＵＥ１００からの要求情報の受信に応じて、ＵＥ１００にＰＴＰ通信パスを設定する。例えば、ｇＮＢ２００は、当該ＭＲＢを、スプリットＭＲＢに設定変更してもよい。また、ｇＮＢ２００は、当該ＭＲＢを、ＰＴＰのみのＭＲＢに変更してもよい。

ステップＳ１０５において、ＵＥ１００は、ステップＳ１５２で設定されたＰＴＰ通信パス上でＰＤＣＰステータス報告をｇＮＢ２００に送信する。

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

データ無線ベアラ（ＤＲＢ）は、対応するＲＬＣモードがＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）であるか又はＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）であるかに応じて、ＡＭ ＤＲＢ及びＵＭ ＤＲＢのいずれか一方に分類される。具体的には、ＵＥ１００は、ＤＲＢと対応付けられたＲＬＣエンティティのモードがＡＭである場合は当該ＤＲＢがＡＭ ＤＲＢであると判定し、ＤＲＢと対応付けられたＲＬＣエンティティのモードがＵＭである場合は当該ＤＲＢがＵＭ ＤＲＢであると判定する。例えば、ＤＲＢについてのＰＤＣＰステータス報告のトリガ条件は、当該ＤＲＢがＡＭ ＤＲＢであるか又はＵＭ ＤＲＢであるかに応じて異なる。

ここで、スプリットＭＲＢについては２つのレグが存在し、対応するＲＬＣエンティティが２つ存在する（図８参照）。例えば、ＰＴＭレグはＵＭのみをサポートし、ＰＴＰレグはＡＭ及びＵＭの両ＲＬＣモードをサポートする。そのため、スプリットＭＲＢがＡＭベアラであるか又はＵＭベアラであるかを判定する方法が必要であると考えられる。

図２０は、第２実施形態に係るＵＥ１００の動作を示す図である。

ステップＳ２０１において、ＵＥ１００は、ＰＴＰレグ及びＰＴＭレグにスプリットされるスプリット無線ベアラ（スプリットＭＲＢ）を設定する設定情報をｇＮＢ２００から受信する。このような設定情報は、ＵＥ専用ＲＲＣシグナリング（例えば、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）によりｇＮＢ２００からＵＥ１００に送信されてもよい。ここで、ＵＥ１００は、ＰＴＰレグを扱うＲＬＣエンティティ及びＰＴＭレグを扱うＲＬＣエンティティのそれぞれのＲＬＣモードがｇＮＢ２００により設定される。

ステップＳ２０２において、ＵＥ１００は、各レグに設定されたＲＬＣモードに基づいて、設定されたスプリット無線ベアラ（スプリットＭＲＢ）がＡＭベアラ（ＡＭ ＭＲＢ）であるか又はＵＭベアラ（ＵＭ ＭＲＢ）であるかを判定する。例えば、ＵＥ１００は、ＰＴＰレグ又はＰＴＭレグに設定されたＲＬＣモードがＡＭであることに応じて、設定されたスプリット無線ベアラ（スプリットＭＲＢ）がＡＭベアラ（ＡＭ ＭＲＢ）であると判定してもよい。ＵＥ１００は、ＰＴＰレグ又はＰＴＭレグに設定されたＲＬＣモードがＵＭであることに応じて、スプリット無線ベアラ（スプリットＭＲＢ）がＵＭベアラ（ＵＭ ＭＲＢ）であると判定してもよい。

具体的には、ＵＥ１００は、設定されたスプリットＭＲＢについて、ＰＴＰレグのＲＬＣエンティティがＡＭで設定された場合、又は、ＰＴＭレグのＲＬＣエンティティがＡＭで設定された場合、当該スプリットＭＲＢがＡＭ ＭＲＢであると判定してもよい。ＵＥ１００は、ＰＴＰレグがｂｉ－ｄｉｒｅｃｔｉｏｎａｌ ＵＭで設定された場合、及び／又は、ＰＴＭレグがｂｉ－ｄｉｒｅｃｔｉｏｎａｌ ＵＭで設定された場合、当該スプリットＭＲＢがＡＭ ＭＲＢであると判定してもよい。

ＵＥ１００は、設定されたスプリットＭＲＢについて、ＰＴＰレグのＲＬＣエンティティがＵＭで設定された場合であって、且つ、ＰＴＭレグのＲＬＣエンティティがＵＭで設定された場合、当該スプリットＭＲＢがＵＭ ＭＲＢであると判定してもよい。ＵＥ１００は、ＰＴＰレグがｕｎｉ－ｄｉｒｅｃｔｉｏｎａｌ ＵＭで設定された場合であって、且つ、ＰＴＭレグがｕｎｉ－ｄｉｒｅｃｔｉｏｎａｌ ＵＭで設定された場合、当該スプリットＭＲＢがＵＭ ＭＲＢであると判定してもよい。

第２実施形態の変更例として、ｇＮＢ２００が、スプリットＭＲＢがＡＭ ＭＲＢであるのか又はＵＭ ＭＲＢであるのか（つまりどちらのモードと見なすのか）をＵＥ１００に設定してもよい。ＵＥ１００は、設定されたＭＲＢのモードに従って、スプリットＭＲＢがＡＭ ＭＲＢであるのか又はＵＭ ＭＲＢであるのかを判定してもよい。

具体的には、ｇＮＢ２００は、当該ＭＲＢをＡＭ ＭＲＢと見なすのか、ＵＭ ＭＲＢと見なすのかを明示的にＵＥ１００に設定する。例えば、ｇＮＢ２００は、ＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎによりスプリットＭＲＢをＵＥ１００に設定する際に、当該スプリットＭＲＢに紐づいたモード識別子（ＡＭ ＭＲＢもしくはＵＭ ＭＲＢ）を当該設定に含める。ＵＥ１００は、当該モード識別子に基づいて、当該スプリットＭＲＢがＡＭ ＭＲＢであるのか又はＵＭ ＭＲＢであるのかを判定する。

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

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

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

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

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

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

［付記］
１．導入
ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８で承認された。これには、動的なＰＴＭ／ＰＴＰの切り替えとサービス継続性を備えたモビリティを次のように規定する目的が含まれている。
ＲＲＣコネクティッド状態のＵＥのブロードキャスト／マルチキャストのＲＡＮ基本機能を規定する。
特定のＵＥのサービス継続性を備えたマルチキャスト（ＰＴＭ）とユニキャスト（ＰＴＰ）と間のブロードキャスト／マルチキャストサービス配信の動的変更のサポートを規定する。
サービス継続性を備えた基本的なモビリティのサポートを規定する。

動的なＰＴＭ／ＰＴＰ切り替えに関しては、ＲＡＮ２はすでにこのトピックに関連するいくつかの合意に達している。ＲＡＮ２＃１１１－ｅには以下の合意があった。
ＵＥの場合、ｇＮＢは、マルチキャストデータをＰＴＭ又はＰＴＰ（共有配信）のどちらで配信するかを動的に決定する。
レイヤが信頼性（一般的に）、順序どおりの配信／重複処理を処理することについては更なる検討が必要であり、ＰＴＭとＰＴＰとの切り替えでどのように機能するかは更なる検討が必要である。

ＲＡＮ２＃１１３－ｅでは、動的なＰＴＭ／ＰＴＰの切り替えのアーキテクチャが、Ｌ２の信頼性に関する議論に関連して次のように合意された。
ＰＴＭとＰＴＰとの両方がＲＬＣ ＵＭの場合、Ｌ２ ＡＲＱがなく、ＰＤＣＰが固定されたＰＴＭとＰＴＰとの切り替えを使用した設定がサポートされる（たとえば、ユニキャスト用にＲＬＣ ＵＭで通常設定されるサービスの場合）。

ＲＡＮ２＃１１３ｂｉｓ－ｅでは、アーキテクチャとシグナリングについて次のようにさらに合意が達せられた。
合意
以下の合意は、これまでのところアーキテクチャの決定にのみ基づいていることに注意する。信頼性の議論はまだ終わっていない。つまり、ＲＬＣ ＵＭ＋ＲＬＣ ＵＭ以外の場合である。このような他の場合のＰＴＭとＰＴＰとの切り替えについては、更なる検討が必要である。
動的なＰＴＭ／ＰＴＰの切り替えは、共通の（単一の）ＰＤＣＰエンティティを有するスプリットＭＲＢベアラ（タイプ）でサポートされる。
基本として、ｇＮＢスイッチの決定をサポートするための新しいＵＥベースのシグナリングは導入されていない（たとえば、高信頼性のためのＰＤＣＰ ＳＲは未定である）。
ＰＴＭレグとＰＴＰレグで設定されたスプリットＭＲＢ（オンラインセッション中に合意された）を想定すると、必要なスプリットＭＲＢ設定の後で、ＰＴＰレグの使用を非アクティブ化することはできない（つまり、ＵＥは常にＣ－ＲＮＴＩを監視する必要がある）。
ＰＴＭレグとＰＴＰレグとで設定されたスプリットＭＲＢ（オンラインセッション中に合意された）を想定すると、スプリットＭＲＢのＰＴＭレグの使用がアクティブ化又は非アクティブ化の対象となるかどうか、及びその詳細については更なる検討が必要である。

モビリティの側面に関しては、ＲＡＮ２は以下にリストされている基本原則のみに合意した。
Ｒ２は、これを必要とするサービスのＭＢＳ－ＭＢＳモビリティのロスレスハンドオーバをサポートすることを目的としている（シナリオの詳細は未定である。少なくともＰＴＰ－ＰＴＰ）。
５Ｇ ＭＢＳサービスのロスレスハンドオーバをサポートするには、少なくともＤＬ ＰＤＣＰ ＳＮの同期と、ソースセルとターゲットセル間の継続性とがネットワーク側で保証されている必要がある。これを実現するための特定のアプローチの設計は、ＷＧ ＲＡＮ３に関係する可能性がある。
ネットワーク側から、ソースｇＮＢはデータをターゲットｇＮＢに転送する場合があり、ターゲットｇＮＢは転送データを配信する。一方、ＳＮ ＳＴＡＴＵＳ ＴＲＡＮＳＦＥＲは、ＭＢＳデータのＰＤＣＰＳＮをカバーするように拡張する必要がある。次に、ＵＥは、ターゲット設定に従って、ターゲットセルによってターゲットセル内のＭＢＳを受信する。
ＵＥ側からは、ＰＤＣＰ状態報告もサポートされる場合がある。

この付記では、合意されたアーキテクチャに基づく、つまりＰＤＣＰに固定されたスプリットＭＲＢを使用した、サービス継続性を備えた動的なＰＴＭ／ＰＴＰの切り替えとモビリティの残りの問題について説明する。

２．議論
３．スプリットＭＲＢ設定
ＰＤＣＰに固定されたＰＴＭ／ＰＴＰの切り替えのアーキテクチャ、つまりスプリットＭＲＢは、現在の合意に基づいて、図２１に示すように解釈できる。

一般に、ＲＲＣ再設定は、マルチキャストセッションを受信するための情報とともに、２つの論理チャネル（ＰＴＭレグ及びＰＴＰレグ）を含むベアラ設定を提供するために使用されるとみなすことができる。ＲＡＮ２は、「ＰＴＭレグとＰＴＰレグとで設定されたスプリットＭＲＢ（オンラインセッションで合意されたもの）を想定する」と述べているが、１つのマルチキャスト無線ベアラに２つの論理チャネルを関連付ける設定は、動的なＰＴＭ／ＰＴＰの切り替えの準備としてＲＲＣ再設定で提供されることがすでに共通の理解になっていると思われる。

所見１：１つのＭＲＢに２つの論理チャネルを関連付ける設定は、動的なＰＴＭ／ＰＴＰ切り替え動作に先立ち、ＲＲＣ再設定によって提供されるというのが共通の理解であると思われる。

４．動的なＰＴＭ／ＰＴＰの切り替え動作
５．シグナリング
スプリットＭＲＢのＰＴＭレグの使用は、アクティブ化又は非アクティブ化の対象となり得るかどうか、及びその詳細については、更なる検討が必要である。

ＰＴＭレグ／ＰＴＰレグを有するスプリットＭＲＢが設定されると、ＵＥはＰＴＭレグのＧ－ＲＮＴＩとＰＴＰレグのＣ－ＲＮＴＩとの両方をモニタする必要がある。ＬＴＥ ＳＣ－ＰＴＭでは、「ＳＣ－ＰＴＭの受信機会はユニキャストＤＲＸ方式から独立している」、つまり、ＤＲＸが別々になっている。Ｇ－ＲＮＴＩは複数のＵＥで受信されるのに対し、Ｃ－ＲＮＴＩはＵＥ固有であり、２つのＤＲＸの位置合わせは非常に難しいため、このコンセプトがＮＲ ＭＢＳの基本となる可能性がある。これは、ＵＥが常にＧ－ＲＮＴＩを監視しなければならない場合、頻繁にウェイクアップする必要があることを意味し、さらなる電力消費の原因となる。一方、接続中のＵＥは、ユニキャスト受信のためにＣ－ＲＮＴＩ、すなわちＣ－ＤＲＸを監視する必要があるが、これはＵＥにとって追加の負担ではない。

所見２：ＵＥは、Ｃ－ＤＲＸと同じＰＴＰレグの送信機会（すなわちＣ－ＲＮＴＩ）に加えて、ＬＴＥ ＳＣ－ＰＴＭのＳＣ－ＭＴＣＨ機会のようにＰＴＭレグの送信機会（すなわちＧ－ＲＮＴＩ）でウェイクアップする必要がある。

ＰＴＭ／ＰＴＭを伴うＭＲＢ受信時、つまり切り替え動作時の選択肢は以下の４つである。

選択肢１：アクティブ化／非アクティブ化ベースの切り替え
ｇＮＢは、ＤＣＩ、ＭＡＣ ＣＥ、又はＲＲＣ信号などによって、ＰＴＭレグの有効化／無効化をＵＥに指示する。この選択肢は、ＰＴＭ又はＰＴＰのいずれかを介したＭＢＳデータ受信に加え、スプリットベアラ又はＰＤＣＰパケット重複のように、ＭＢＳデータを２つのレグを介して受信する場合、より柔軟に対応することができる。ＵＥは、非アクティブ化されたＰＴＭレグからの消費電力を低減することができる。ＮＷの実装では、常に２つのレグをアクティブにしておくことを決定する可能性があり、以下の選択肢４の意図をカバーすることができることに留意する。

選択肢２：切り替えオーダー／コマンドベース切り替え
ｇＮＢは、ＤＣＩ、ＭＡＣ ＣＥ、又はＲＲＣシグナリングなどによって、ＵＥにＰＴＭレグとＰＴＰレグの間の切り替えを指示する。この選択肢は、ＰＴＭレグの非アクティブ化による省電力化という点では、上記の選択肢１と同様であり、シンプルである。しかし、ＰＤＣＰパケットの重複を含むスプリットベアラ的な動作には柔軟性に欠ける。この選択肢は、ＰＴＭレグとＰＴＰレグ間の切り替えのみで、両方をアクティブ化することはできないと思われる。

選択肢３：ＲＲＣ再設定ベースの切り替え
ｇＮＢは、ＲＲＣ再設定により、ＵＥをＰＴＭ又はＰＴＰのいずれかをＭＲＢとして再設定する。つまり、ＰＴＭレグとＰＴＰレグとを１つのＭＲＢに関連付けない。つまり「ベアラタイプの変更」のようなもので、スプリットＭＲＢアーキテクチャとは整合性がとれていない。また、この選択肢は、Ｌ３が関与するため、ＰＴＭとＰＴＰとの切り替えをどれだけ「動的」に行えるかは疑問が残る。

選択肢４：切り替えに基づくシグナリングなし
ＵＥは、スプリットＭＲＢに２つのレグが設定されている場合は常に、ＰＴＭレグとＰＴＰレグとの両方からの受信を試行する必要がある。この選択肢は、ｇＮＢの観点から最大限のスケジューリングの柔軟性を確保するが、ＵＥにとっては節電の機会がない。

以上のことから、選択肢１は、スケジューリングの柔軟性、ＵＥの消費電力、及びスプリットＭＲＢアーキテクチャとの整合性の点で最も適した選択肢であると言える。選択肢４は、ＰＴＭレグが常にアクティブである場合、選択肢１のサブセットと見なすことができる。シグナリングレイヤについては、アクティブ化／非アクティブ化はほとんどＤＲＸの動作に関連しているため、ＭＡＣ ＣＥは容易である可能性がある。したがって、ＲＡＮ２は、ＰＴＭレグがＭＡＣ ＣＥを介してアクティブ化／非アクティブ化できることに合意すべきである。

提案１：動的なＰＴＭ／ＰＴＰ切り替えのために、ＲＡＮ２は、スプリットＭＲＢのＰＴＭレグをアクティブ／非アクティブにするＭＡＣ ＣＥを導入することに合意すべきである。

動的な切り替えとは異なる「ベアラタイプ変更」について、ベアラタイプ変更には以下のようなケースがあると考えられる。
ケース１：ＰＴＭのみのＭＲＢ←→ＰＴＰのみのＭＲＢ
ケース２：スプリットＭＲＢ←→ＰＴＭのみのＭＲＢ
ケース３：スプリットＭＲＢ←→ＰＴＰのみのＭＲＢ

このようなベアラタイプ変更の場合、ＲＲＣ再設定、つまり選択肢３を使用するのが容易である。

提案２：ＰＴＭのみのＭＲＢ、ＰＴＰのみのＭＲＢ、及びスプリットＭＲＢ間のベアラタイプ変更については、ＲＡＮ２はＲＲＣ再設定を使用することに合意すべきである。

６．ＰＤＣＰの行動
７．状態変数の初期値
ＲＡＮ２は、ＲＬＣ ＵＭモードに加え、スプリットＭＲＢのＰＴＰレグのＲＬＣ ＡＭモードをサポートすることに合意した。また、「ＲＬＣ－ＡＭはＰＴＭに対応していない（ＭＢＳ Ｒ１７ ＷＩ用）」ため、Ｌ２信頼性は動的なＰＴＭ／ＰＴＰ切り替えにのみ依存するというのが共通認識となっている。そのため、ＭＢＳデータ受信開始時や動的なＰＴＭ／ＰＴＰ切り替え時のパケットロスをいかに少なくするかは、サービス継続のために検討する価値がある。

図２１に示すように、既存のＰＤＣＰ機能ビューを再利用すれば、ＰＤＣＰ ＳＮは、ＰＴＭレグとＰＴＰレグとで共通である。ＰＴＭレグは複数のＵＥで使用されるため、ＰＤＣＰ ＳＮはＵＥ固有でない可能性があり、ＰＴＭレグとＰＴＰレグとの両方に影響する。これは、ＵＥがマルチキャストセッションに遅れて参加する場合、最初に受信したＭＢＳデータがＰＴＭレグとＰＴＰレグとのどちらから来るかに関係なく、各状態変数の初期値を常に「０」にすることはできないことを意味している。つまり、ＵＥが最初に受信するＰＤＣＰ ＳＮは、今回のユニキャスト送信で想定していない任意の値であってもよい。また、状態変数が初期値に設定されるため、あるＵＥのＰＤＣＰ再確立が他のすべてのＵＥに影響を与える可能性がある。受信ウィンドウで予期せぬ動作、つまりウィンドウ外のＰＤＣＰ ＰＤＵを破棄することになる。ハンドオーバのシナリオでも同じ問題が存在する可能性があることが指摘されている。

所見３：マルチキャストセッションに後発で参加し、スプリットＭＲＢが設定されているＵＥの場合、最初に受信したＰＤＣＰ ＰＤＵのＳＮは、ＰＴＭレグ又はＰＴＰレグに関わらず初期値（すなわち「０」）ではないことが確認されている。

この問題を解決するために、以下の選択肢が提案されている。

選択肢Ａ：ｇＮＢは、ＣＯＵＮＴの初期値、又はＲＸ＿ＮＥＸＴ及びＲＸ＿ＤＥＬＩＶをＵＥに通知する。
この選択肢は、ＵＥが既存のメカニズムでＭＢＳデータの最初の送信を受信できるように、ｇＮＢからの情報に基づいて受信ウィンドウに関する初期値を単に変更するものである。しかし、ＰＤＣＰレイヤの観点からは、切り替えの遅延、無線状態の悪化、ＲＬＣ再構築ウィンドウの範囲外など、ｇＮＢが意図した最初の送信をＵＥが常に正常に受信できるかは疑問がある。この場合、この選択肢がどのように機能するかは不明確である。

選択肢Ｂ：ｇＮＢはＵＥに初期ＨＦＮを通知し、ＵＥは最初に受信したＰＤＣＰ ＰＤＵから初期ＨＦＮとＳＮを推測する。
ＳＮ部については、Ｒｅｌ－１６のＶ２Ｘメカニズムと同様の選択肢、すなわち、以下の通りである。「ＲＸ＿ＮＥＸＴのＳＮ部の初期値は、（ｘ＋１）ｍｏｄｕｌｏ（２^{［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ］}）であり、ｘは最初に受信したＰＤＣＰデータＰＤＵのＳＮである」、「ＮＲ ｓｉｄｅｌｉｎｋ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｒ ｂｒｏａｄｃａｓｔ ａｎｄ ｇｒｏｕｐｃａｓｔでは、ＲＸ＿ＤＥＬＩＶのＳＮ部の初期値は（ｘ－０．５×２^{［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ－１］}）ｍｏｄｕｌｏ（２^{［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ］}），ただしｘは最初に受信したＰＤＣＰ Ｄａｔａ ＰＤＵのＳＮである」。

ＨＦＮ部分については、Ｒｅｌ－１６ Ｖ２Ｘメカニズムでは、セキュリティのためにＨＦＮを使用しないため、送信機と受信機の同期を必要としない。すなわち、「注：ＲＸ＿ＤＥＬＩＶの初期値を正の値にするように、ＲＸ＿ＮＥＸＴのＨＦＮを選択するのはＵＥ実装次第」とされている。ＮＲ ＭＢＳについては、「ＲＡＮ２は、ＲＡＮ２でセキュリティの側面を議論する前に、ＳＡ３がＭＢＳのセキュリティに関する研究を完了させるのを待つと回答する」。したがって、ＲＡＮ２は、ＳＡ３がセキュリティに関する研究を完了するまで、ＨＦＮ部分の議論を延期すべきである。

以上のことから、選択肢Ｂを基本として、さらに議論を深めていくべきである。ブロードキャスト及びグループキャストのＲｅｌ－１６サイドリンク通信によると、ＮＲ ＭＢＳのセキュリティに関するＳＡ３の進展を考慮すると、ＲＡＮ２は少なくとも、ＵＥがＭＢＳデータの最初の受信ＰＤＣＰ ＰＤＵから状態変数の初期値を設定することに合意すべきである。

提案３：ＲＡＮ２は、ＰＴＭレグ又はＰＴＰレグに関係なく、ＵＥが最初に受信したＭＢＳデータからＲＸ＿ＮＥＸＴ及びＲＸ＿ＤＥＬＩＶのＳＮ部分の初期値を設定することに合意すべきである。ＨＦＮの部分がｇＮＢから通知されるかどうかは、ＳＡ３の進捗次第あり、更なる検討が必要である。

８．同時受信とＵＥ支援情報
特に、ＰＴＰ（レグ）は信頼性が要求されるサービスではＲＬＣ ＡＭで設定され、ロスレスなモビリティと同様にサービス継続のためにロスレスな切り替えは重要である。提案１に合意する場合、ＵＥはＰＴＭレグとＰＴＰレグとの両方からの同時受信をサポートする必要がある。つまり、既存のＰＤＣＰパケット重複と同様に、２つのレグを同時にアクティブ化できる。これは、ＰＴＭレグが複数のＵＥによって受信されるため、特定のＵＥにとって最適なＭＣＳではないことが容易に起こり得るためである。そのため、ＲＡＮ２は動的なＰＴＭ／ＰＴＰ切り替え時に、少なくとも一定期間同時受信の使用を採用することに合意すべきである。

提案４：ＲＡＮ２は、動的なＰＴＭ／ＰＴＰ切り替え後の一定期間、ＵＥがＰＴＭレグ及びＰＴＰレグの両方からの同時受信をサポートすることに合意すべきである。

提案３と提案４が合意された場合、ＵＥがＰＴＭレグを介してどのＰＤＣＰ ＳＮを正常に受信し始めたかどうかをｇＮＢが実際に知らない可能性がある。ＰＴＰからＰＴＭへの切り替える場合、ｇＮＢは、どのＰＤＣＰ ＰＤＵをＰＴＰレグで送信すべきか、また、いつＰＴＰレグの送信を停止できるかがわからない場合がある。この問題を解決するために、ＵＥがＰＴＭ受信に成功したことをｇＮＢに通知し、ＰＴＰレグを通じて送信することが提案されている。ただし、ＵＥがＰＤＣＰ ＳＮ情報も同じメッセージに含めるべきかどうかは不明確である。

所見４：ＰＴＰからＰＴＭへ切り替える場合、ｇＮＢは、どのＰＤＣＰ ＰＤＵからＰＴＰレグの送信を維持する必要があるか、又はＵＥがどのＰＤＣＰ ＰＤＵからＰＴＭレグによる受信を正常に開始するかを知らない場合がある。

同様に、ＰＴＭからＰＴＰへ切り替える場合、ＵＥがＰＴＭレグを介してどのＰＤＣＰ ＳＮを正常に受信したかをｇＮＢが知らない可能性がある（特に、ＵＥの無線状態が悪い場合）。これは、ＰＴＰレグの開始時にどのＰＤＣＰ ＰＤＵを使用すべきかをｇＮＢが知らない可能性があることを意味する。

所見５：ＰＴＭからＰＴＰへ切り替える場合、ｇＮＢは、ＰＴＰレグがどのＰＤＣＰ ＰＤＵから送信を開始する必要があるか、又はＵＥがＰＴＭレグを介してどのＰＤＣＰ ＰＤＵを正常に受信したかを知らない場合がある。

そのため、ＵＥは動的なＰＴＭ／ＰＴＰ切り替え時に、ＰＴＰレグを介してＳＮ情報をｇＮＢに通知することが検討される。ＰＴＭとＰＴＰとの間の動的な切り替え時にＵＥがＳＮ情報を報告する場合、ＰＤＣＰ制御ＰＤＵ、つまり、ＦＭＣ（最初のＰＤＣＰ ＳＤＵが見つからない）及び選択肢としてビットマップ（後続のＰＤＣＰ ＳＤＵが見つからないか正しく受信されているかを示す）を含むＰＤＣＰ状態報告を再利用することは容易である。一方、ＵＥがＰＴＭレグを介して最初／最後のＰＤＣＰ ＰＤＵ受信に成功したＳＮを報告することも選択肢の１つである。したがって、ＰＴＭとＰＴＰとの動的な切り替え時にＵＥが報告する内容については、さらなる議論が必要である。

上記のいずれの場合（すなわち、ＰＴＰからＰＴＭへ切り替える場合及びＰＴＭからＰＴＰへ切り替える場合）でも、動的な切り替え（例えば、ＭＡＣ ＣＥのアクティブ化／非アクティブ化）時に、サービス継続のためのＰＤＣＰ ＳＮ情報を含むＰＤＣＰ制御ＰＤＵをトリガする必要がある。

提案５：ＲＡＮ２は、サービス継続のために、ＵＥが動的な切り替え時にＰＤＣＰ ＳＮ情報を含むＰＤＣＰ 制御ＰＤＵを送信するかどうかを検討すべきである。ＰＤＣＰ情報報告が再利用可能かどうかについては、更なる検討が必要である。

もう一つは、提案５のようなロスレスな動的切り替えと同様のロスレスなベアラタイプの変更が必要かという点である。ＲＬＣ ＡＭを伴うＰＴＰ（レグ）を含むベアラタイプの変更は、サービス継続性、ロスレスなモビリティの観点から、動的な切り替えと同様の信頼性が必要であると考えられる。そのため、ＲＡＮ２は、ロスレスなベアラタイプの変更をサポートするかどうかを検討すべきである。サポートする場合は、提案５と同様にＵＥ支援情報としてＰＤＣＰ制御ＰＤＵを再利用すべきである。

提案６：ＲＡＮ２は、ＲＲＣ再設定を伴うロスレスなベアラタイプの変更、すなわち提案５のようなＰＤＣＰ制御ＰＤＵによるロスレスな動的切り替えと同じ解決策が適用可能かどうかを議論すべきである。

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

Claims (8)

1. マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる通信方法であって、
   ユーザ装置が、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）レグ及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）レグを有するマルチキャスト無線ベアラの設定をネットワークノードから受信することと、
   前記ユーザ装置が、前記設定に基づいて、前記マルチキャスト無線ベアラがＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）ベアラであるか又はＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）ベアラであるかを判定することと、を有し、
   前記ユーザ装置は、前記ＰＴＰレグ又は前記ＰＴＭレグに設定されたＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）モードがＡＭであることに応じて、前記マルチキャスト無線ベアラをＡＭベアラとして扱う
   通信方法。
2. 前記ユーザ装置は、前記ＰＴＰレグのＲＬＣエンティティがＡＭで設定された場合、又は前記ＰＴＭレグのＲＬＣエンティティがＡＭで設定された場合、前記マルチキャスト無線ベアラをＡＭ ＭＲＢとして扱う
   請求項１に記載の通信方法。
3. 前記ユーザ装置は、前記ＰＴＰレグ又は前記ＰＴＭレグに設定されたＲＬＣモードがＵＭであることに応じて、前記マルチキャスト無線ベアラをＵＭベアラとして扱う
   請求項１又は２に記載の通信方法。
4. 前記ユーザ装置は、前記ＰＴＰレグのＲＬＣエンティティがＵＭで設定された場合であって、且つ、前記ＰＴＭレグのＲＬＣエンティティがＵＭで設定された場合、前記マルチキャスト無線ベアラをＵＭ ＭＲＢとして扱う
   請求項３に記載の通信方法。
5. マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いるユーザ装置であって、
   ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）レグ及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）レグを有するマルチキャスト無線ベアラの設定をネットワークノードから受信する受信部と、
   前記設定に基づいて、前記マルチキャスト無線ベアラがＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）ベアラであるか又はＵＭ（Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）ベアラであるかを判定する制御部と、を有し、
   前記制御部は、前記ＰＴＰレグ又は前記ＰＴＭレグに設定されたＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）モードがＡＭであることに応じて、前記マルチキャスト無線ベアラをＡＭベアラとして扱う
   ユーザ装置。
6. 請求項５に記載のユーザ装置とネットワークノードとを備える移動通信システム。
7. 請求項１に記載の通信方法を実行する手段を備えるチップセット。
8. 請求項１に記載の通信方法をユーザ装置に実行させるプログラム。
   

Images