JP7701463B2

JP7701463B2 - 通信方法、ユーザ装置、プロセッサ、プログラム、及び移動通信システム

Info

Publication number: JP7701463B2
Application number: JP2023554593A
Authority: JP
Inventors: 真人藤代; ヘンリーチャン
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2021-10-14
Filing date: 2022-10-12
Publication date: 2025-07-01
Anticipated expiration: 2042-10-12
Also published as: US20240260124A1; JPWO2023063371A1; WO2023063371A1

Description

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

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

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

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

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

第１の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信するステップと、前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記基地局から受信するステップと、前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更がＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガするステップと、前記ＰＤＣＰステータス報告を前記基地局に送信するステップと、を有する。

第２の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいてユーザ装置が実行する通信方法であって、マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信するステップと、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態からＲＲＣコネクティッド状態に遷移したこと、及び／又は、ＲＬＣレイヤにおいてＭＢＳデータパケットの破棄が発生したことに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信を自発的にトリガするステップと、前記ＰＤＣＰステータス報告を前記基地局に送信するステップと、を有する。

第３の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおいて基地局が実行する通信方法であって、マルチキャスト無線ベアラ（ＭＲＢ）を介してＭＢＳデータをユーザ装置に送信するステップと、前記ＭＲＢのベアラタイプ変更を指示するメッセージであって、前記ＭＲＢと対応付けられたＰＤＣＰエンティティの再確立を指示する第１情報要素を含むＲＲＣ再設定メッセージを前記ユーザ装置に送信するステップと、前記第１情報要素に基づいて前記ユーザ装置から送信されるＰＤＣＰステータス報告を受信するステップと、を有する。前記ＲＲＣ再設定メッセージを送信するステップは、前記第１情報要素を前記ＲＲＣ再設定メッセージに含める場合、前記ＰＤＣＰエンティティのヘッダ圧縮プロトコルの状態を維持することを指示する第２情報要素をさらに含む前記ＲＲＣ再設定メッセージを送信するステップを含む。

第４の態様に係るユーザ装置は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いるユーザ装置であって、マルチキャスト無線ベアラ（ＭＲＢ）を介して基地局からＭＢＳデータを受信し、前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記基地局から受信する受信部と、前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更がＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガする制御部と、前記ＰＤＣＰステータス報告を前記基地局に送信する送信部と、を備える。

実施形態に係る移動通信システムの構成を示す図である。実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。実施形態に係るｇＮＢ（基地局）の構成を示す図である。データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。実施形態に係るＭＢＳトラフィック配信の概要を示す図である。実施形態に係る配信モードを示す図である。実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の一例を示す図である。実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の他の例を示す図である。実施形態に係る移動通信システムにおけるＰＤＣＰレイヤの動作を示す図である。実施形態に係るＰＤＣＰ状態変数の一例を示す図である。実施形態に係るＭＢＳデータを構成するＰＤＣＰデータＰＤＵの一例を示す図である。実施形態に係るＵＥの受信側ＰＤＣＰエンティティにおいて受信したＰＤＣＰデータＰＤＵのＣＯＵＮＴ値であるＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。実施形態に係るＰＤＣＰステータス報告に関するＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。実施形態に係るＰＤＣＰステータス報告に関するＵＥのＲＲＣエンティティの動作を示す図である。実施形態に係るＰＤＣＰステータス報告の構成例を示す図である。第１実施形態に係るＵＥの動作を示す図である。第１実施形態の第１実施例に係るＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。第１実施形態の第２実施例に係るＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。第１実施形態の第３実施例に係るＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。第２実施形態に係るＵＥの動作を示す図である。第３実施形態に係る移動通信システムの動作を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図８は、第１実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の一例を示す図である。図９は、第１実施形態に係るＵＥ１００のＭＢＳ受信に関する内部処理の他の例を示す図である。

１つのＭＢＳ無線ベアラ（ＭＲＢ）は、マルチキャストセッション又はブロードキャストセッションを伝送する１つの無線ベアラである。すなわち、ＭＲＢにマルチキャストセッションが対応付けられる場合と、ＭＲＢにブロードキャストセッションが対応付けられる場合とがある。

ＭＲＢ及び対応する論理チャネル（例えば、ＭＴＣＨ）は、ＲＲＣシグナリングによってｇＮＢ２００からＵＥ１００に設定される。ＭＲＢの設定手順は、データ無線ベアラ（ＤＲＢ）の設定手順と分離されていてもよい。ＲＲＣシグナリングでは、１つのＭＲＢを、「ＰＴＭのみ（ＰＴＭｏｎｌｙ）」、「ＰＴＰのみ（ＰＴＰｏｎｌｙ）」、又は「ＰＴＭ及びＰＴＰの両方（ｂｏｔｈＰＴＭａｎｄＰＴＰ）」で設定できる。このようなＭＲＢのベアラタイプはＲＲＣシグナリングにより変更できる。

図８において、ＭＲＢ＃１にはマルチキャストセッション及び専用トラフィックチャネル（ＤＴＣＨ）が対応付けられ、ＭＲＢ＃２にはマルチキャストセッション及びＭＴＣＨ＃１が対応付けられ、ＭＲＢ＃３にはブロードキャストセッション及びＭＴＣＨ＃２が対応付けられる一例を示している。すなわち、ＭＲＢ＃１はＰＴＰのみ（ＰＴＰｏｎｌｙ）のＭＲＢであり、ＭＲＢ＃２はＰＴＭのみ（ＰＴＭｏｎｌｙ）のＭＲＢであり、ＭＲＢ＃３はＰＴＭのみ（ＰＴＭｏｎｌｙ）のＭＲＢである。なお、ＤＴＣＨは、セルＲＮＴＩ（Ｃ－ＲＮＴＩ）を用いてスケジューリングされる。ＭＴＣＨは、Ｇ－ＲＮＴＩを用いてスケジューリングされる。

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

図９において、マルチキャストセッションと対応付けられるＭＲＢに、ＤＴＣＨ及びＭＴＣＨが対応付けられる一例を示している。具体的には、１つのＭＲＢが２つのレグに分割（スプリット）され、一方のレグがＤＴＣＨと対応付けられ、他方のレグがＭＴＣＨと対応付けられている。当該２つのレグは、ＰＤＣＰレイヤ（ＰＤＣＰエンティティ）において結合される。すなわち、当該ＭＲＢは、ＰＴＭ及びＰＴＰの両方（ｂｏｔｈＰＴＭａｎｄＰＴＰ）のＭＲＢである。このようなＭＲＢは、スプリットＭＲＢと呼ばれることがある。

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

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

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

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

なお、ｇＮＢ２００は、ＲＲＣシグナリングを各ＵＥ１００と送受信するＲＲＣエンティティ２０２を有する。各ＵＥ１００は、ＲＲＣシグナリングをｇＮＢ２００と送受信するＲＲＣエンティティ１０２（ＲＲＣエンティティ１０２ａ乃至ＲＲＣエンティティ１０２ｃ）を有する。ＵＥ１００のＲＲＣエンティティ１０２は、ｇＮＢ２００のＲＲＣエンティティ２０２から受信するＲＲＣシグナリングに基づいて、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１を制御する。

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

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

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

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

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

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

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

（ＰＤＣＰステータス報告の概要）
ここで、一般的なＰＤＣＰステータス報告について説明する。ＵＥ１００は、ＰＤＣＰレイヤにおけるデータ受信状況を示すＰＤＣＰステータス報告（ＳｔａｔｕｓＲｅｐｏｒｔ）をｇＮＢ２００に送信する。ｇＮＢ２００は、ＵＥ１００からのＰＤＣＰステータス報告に基づいて、欠落したＰＤＣＰパケット（ＰＤＣＰＳＤＵ）を特定し、特定したＰＤＣＰパケットをＵＥ１００に再送することができる。

図１４は、ＰＤＣＰステータス報告に関するＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。なお、図１４は、ＰＤＣＰレイヤの３ＧＰＰ技術仕様書「ＴＳ３８．３２３」からの引用である。

ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰステータス報告を送信するように上位レイヤ（ＲＲＣレイヤ）により設定された確認モード（ＡＭ：ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のデータ無線ベアラ（ＤＲＢ：ＤａｔａＲａｄｉｏＢｅａｒｅｒ）について、次のいずれかの条件が満たされた場合、ＰＤＣＰステータス報告の送信をトリガする：
・上位レイヤがＰＤＣＰエンティティの再確立を要求した（ｕｐｐｅｒｌａｙｅｒｒｅｑｕｅｓｔｓａＰＤＣＰｅｎｔｉｔｙｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔ）；
・上位レイヤがＰＤＣＰデータリカバリを要求した（ｕｐｐｅｒｌａｙｅｒｒｅｑｕｅｓｔｓａＰＤＣＰｄａｔａｒｅｃｏｖｅｒｙ）；
・上位レイヤが上りリンクデータ切り替えを要求した（ｕｐｐｅｒｌａｙｅｒｒｅｑｕｅｓｔｓａｕｐｌｉｎｋｄａｔａｓｗｉｔｃｈｉｎｇ）；
・上位レイヤがＤＡＰＳを解放するようにＰＤＣＰエンティティを再設定した（ｕｐｐｅｒｌａｙｅｒｒｅｃｏｎｆｉｇｕｒｅｓｔｈｅＰＤＣＰｅｎｔｉｔｙｔｏｒｅｌｅａｓｅＤＡＰＳ）。

図１５は、ＰＤＣＰステータス報告に関するＵＥ１００のＲＲＣエンティティ１０２の動作を示す図である。なお、図１５は、ＲＲＣレイヤの３ＧＰＰ技術仕様書「ＴＳ３８．３３１」からの引用である。

ＵＥ１００のＲＲＣエンティティ１０２は、現在のＵＥ設定の一部であるｄｒｂ－ＴｏＡｄｄＭｏｄＬｉｓｔに含まれるＤＲＢ識別子（ｄｒｂ－Ｉｄｅｎｔｉｔｙ）ごとに、
・ＰＤＣＰ再確立（ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ）がセットされている場合、そのＤＲＢのＰＤＣＰエンティティを再確立する；
・ＰＤＣＰリカバリ（ｒｅｃｏｖｅｒＰＤＣＰ）がセットされている場合、そのＤＲＢのＰＤＣＰエンティティがデータリカバリを行うことをトリガする。

このように、ＤＲＢについての既存の技術仕様の動作によれば、ＵＥ１００は、ｇＮＢ２００からのＲＲＣシグナリングによってＰＤＣＰ再確立又はＰＤＣＰリカバリを指示されたことに応じて、ＰＤＣＰステータス報告の送信をトリガする。なお、ＭＲＢについてＰＤＣＰステータス報告を適用するか否か、及び、ＭＲＢについてＰＤＣＰステータス報告を適用する場合にどのようにＰＤＣＰステータス報告をトリガするかは、既存の技術仕様では規定されていない。

図１６は、ＰＤＣＰステータス報告の構成例を示す図である。なお、ＰＤＣＰステータス報告を構成するＰＤＣＰ制御ＰＤＵの先頭に、当該ＰＤＵが制御ＰＤＵであることを示すＤ／Ｃフィールドと、当該ＰＤＵがＰＤＣＰステータス報告であることを示すＰＤＵタイプフィールドとが設けられていてもよい。

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

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

（第１実施形態に係る動作）
上述のように、ｇＮＢ２００のＲＲＣエンティティ２０２は、ＵＥ１００のＲＲＣエンティティ１０２に送信するＲＲＣシグナリング、具体的には、ＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージによりＭＲＢのベアラタイプを変更できる。ここで、ＵＥ１００がＲＲＣ再設定メッセージを受信してからＲＲＣ再設定処理が完了するまでに処理遅延が生じる。この遅延時間の間はＭＢＳデータの受信が不可になり、ＵＥ１００においてＭＢＳデータパケットの欠落、すなわち、パケットロスが生じるという問題がある。

上述のように、ＰＤＣＰレイヤは、パケットロスを補償可能な仕組みとして、ＰＤＣＰステータス報告を有する。具体的には、ＵＥ１００は、ＰＤＣＰレイヤにおけるデータ受信状況を示すＰＤＣＰステータス報告をｇＮＢ２００に送信する。ｇＮＢ２００は、ＵＥ１００からのＰＤＣＰステータス報告に基づいて、欠落したＰＤＣＰパケットを特定し、特定したＰＤＣＰパケットをＵＥ１００に再送することができる。

第１実施形態は、ＰＤＣＰステータス報告の送信をＵＥ１００が自発的にトリガすることにより、ＭＲＢのベアラタイプ変更に起因するパケットロスをＰＤＣＰステータス報告により補償可能とする実施形態である。具体的には、ＰＤＣＰステータス報告について、ＭＢＳ受信に関する新たな送信トリガ条件を導入する。

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

ステップＳ１において、ＵＥ１００は、ＭＲＢを介してｇＮＢ２００からＭＢＳデータを受信する。上述のように、ＭＲＢのベアラタイプには、「ＰＴＭのみ（ＰＴＭｏｎｌｙ）」、「ＰＴＰのみ（ＰＴＰｏｎｌｙ）」、又は「ＰＴＭ及びＰＴＰの両方（ｂｏｔｈＰＴＭａｎｄＰＴＰ）」（すなわち、スプリットＭＲＢ）の３つのタイプがある。

ステップＳ２において、ＵＥ１００は、当該ＭＲＢのベアラタイプ変更を指示するＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージをｇＮＢ２００から受信する。ＲＲＣ再設定メッセージは、確立済みのＭＲＢのベアラタイプ変更を行う設定を含む。例えば、ＲＲＣ再設定メッセージは、当該ＭＲＢのベアラ識別子と、当該ＭＲＢの変更先のベアラタイプを示すベアラタイプ情報とを含んでもよい。

ステップＳ３において、ＵＥ１００は、ステップＳ２で受信したＲＲＣ再設定メッセージにより指示されたベアラタイプ変更が所定のベアラタイプ変更であるか否かを判定する。

当該ベアラタイプ変更が所定のベアラタイプ変更である場合（ステップＳ３：ＹＥＳ）、ステップＳ４において、ＵＥ１００は、当該ＭＲＢと対応付けられたＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）におけるデータ受信状況を示すＰＤＣＰステータス報告の送信を自発的にトリガする。

ステップＳ５において、ＵＥ１００は、ＰＤＣＰステータス報告をｇＮＢ２００に送信する。

このように、ＵＥ１００は、所定のベアラタイプ変更をｇＮＢ２００から指示された場合、ＰＤＣＰステータス報告の送信を自発的にトリガする。これにより、ＭＲＢのベアラタイプ変更に起因するパケットロスをＰＤＣＰステータス報告により補償可能になる。

ここで、「自発的にトリガする」とは、ＰＤＣＰステータス報告の送信をトリガすることをｇＮＢ２００から明示的に指示されなくても、ＵＥ１００がＰＤＣＰステータス報告の送信をトリガすることをいう。例えば、ＵＥ１００は、ｇＮＢ２００からのＲＲＣシグナリングによってＰＤＣＰ再確立又はＰＤＣＰリカバリを指示されなくても、所定のベアラタイプ変更に応じてＰＤＣＰステータス報告の送信をトリガする。

ＰＤＣＰステータス報告の送信をトリガすることを目的としてＰＤＣＰ再確立又はＰＤＣＰリカバリを行うことは非効率になり得るが、第１実施形態によれば、ＰＤＣＰ再確立又はＰＤＣＰリカバリを伴わずにＰＤＣＰステータス報告の送信をトリガ可能である。また、ＰＤＣＰステータス報告の送信をトリガするベアラタイプ変更を、所定のベアラタイプ変更に限定することにより、例えばパケットロスが許容されるようなＭＢＳサービスについては、ＰＤＣＰステータス報告の送信をトリガしないことが可能である。

このような動作は、確立済みのＭＲＢのベアラタイプ変更に適用され、新たなＭＲＢを確立する場合には適用されない。すなわち、ＵＥ１００は、新たなＭＲＢを確立する場合は、ＰＤＣＰステータス報告の自発的な送信トリガを行わない。

（第１実施形態の実施例）
上述の第１実施形態に係る動作を前提として、第１実施形態に係る第１実施例乃至第３実施例について説明する。

（１）第１実施例
本実施例において、所定のベアラタイプ変更は、ＰＴＰ（Ｐｏｉｎｔ－Ｔｏ－Ｐｏｉｎｔ）のみのＭＲＢタイプへの変更又はスプリットＭＲＢへの変更である。すなわち、ＵＥ１００は、ＰＴＰのみ又はスプリットＭＲＢに変更された時に（のみ）、ＰＤＣＰステータス報告の送信をトリガする。

ここで、ＰＴＰのみ又はスプリットＭＲＢへのベアラタイプ変更は、次の４パターンがある：
１）ＰＴＭのみ→ＰＴＰのみ；
２）ＰＴＭのみ→スプリットＭＲＢ；
３）ＰＴＰのみ→スプリットＭＲＢ；
４）スプリットＭＲＢ→ＰＴＰのみ。

ＰＴＭのみのＭＲＢは、上りリンクのパスが存在しないため、ＰＤＣＰステータス報告を送信しようとしても、送信することはできない。また、ＰＴＭのみのＭＲＢは、ＰＴＰのみのＭＲＢ及びスプリットＭＲＢに比べて、高信頼性が要求されないと考えられる。そのため、本実施例では、ＰＴＰのみ又はスプリットＭＲＢに変更された時に（のみ）、ＰＤＣＰステータス報告の送信をトリガすることとしている。

図１８は、本実施例に係るＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。図１８において、図１４と異なる部分を下線で示している。但し、図１８における「ＤＲＢ」を「ＭＲＢ」と読み替えてもよい。

ＵＥ１００は、当該ＭＲＢのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）にｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄが設定されており、且つ、ＰＴＰのみ又はスプリットＭＲＢへのベアラタイプ変更を行うよう上位レイヤが当該ＰＤＣＰエンティティを再設定した場合（ｕｐｐｅｒｌａｙｅｒｒｅｃｏｎｆｉｇｕｒｅｓｔｈｅＰＤＣＰｅｎｔｉｔｙｔｏｃｈａｎｇｅｂｅａｒｅｒｔｙｐｅｔｏＰＴＰ－ｏｎｌｙＭＲＢｏｒＳｐｌｉｔＭＲＢ）、ＰＤＣＰステータス報告をトリガする。

（２）第２実施例
本実施例において、所定のベアラタイプ変更は、ＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のＭＲＢタイプへの変更である。すなわち、ＵＥ１００は、ＡＭＭＲＢに変更された時に（のみ）、ＰＤＣＰステータス報告の送信をトリガする。

ＰＴＭのみのＭＲＢは、ＵＭ（ＵｎａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のＭＲＢとして扱われると考えられる。また、ＰＴＭ（特に、ＰＴＭのみ）はＰＴＰに比べて無線リソースの使用効率が良いことから、ｇＮＢ２００は、出来るだけＵＥ１００をＰＴＭ（－ｏｎｌｙ）にしたいという動機があると考えられる。

この場合、ｇＮＢ２００は、例えば、無線状態が良い場合はＰＴＭ（－ｏｎｌｙ）（すなわち、ＵＭＭＲＢ）とし、無線状態が悪くなってきたらＰＴＰのみ又はスプリットＭＲＢ（すなわち、ＡＭＭＲＢ）という使い分けをベアラタイプ変更により行うと考えられる。なお、無線状況は、例えば既存の測定報告により判断できる。

ここで、ある程度高い信頼性が要求されるサービスについて、ベアラタイプ変更時のパケットロス補償として、次のような方法がある：
・ＡＭからＵＭへの変更；
ＡＭ（ＰＴＰ）にて、ＵＭ（ＰＴＭ）のＳＮよりも先のパケットを予め伝送しておく；
・ＵＭからＡＭへの変更；
ＵＭ（ＰＴＭ）で欠損したパケットを、後からＡＭ（ＰＴＰ）で伝送する。ここで、ＰＤＣＰステータス報告が必要となる。

よって、本実施例では、ＵＥ１００は、ＡＭＭＲＢへ変更された場合に、ＰＤＣＰステータス報告の自発的な送信トリガを行う。ＡＭＭＲＢへの変更（ＭＲＢ再設定）は、次の２パターンがある：
１）ＵＭＭＲＢ→ＡＭＭＲＢ；
２）ＡＭＭＲＢ→ＡＭＭＲＢ；例えば、スプリットＭＲＢからＰＴＰのみのＭＲＢの場合など。

図１９は、本実施例に係るＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。図１９において、図１４と異なる部分を下線で示している。但し、図１９における「ＤＲＢ」を「ＭＲＢ」と読み替えてもよい。

ＵＥ１００は、当該ＭＲＢのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）にｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄが設定されており、且つ、ＡＭＭＲＢへのベアラタイプ変更を行うよう上位レイヤが当該ＰＤＣＰエンティティを再設定した場合（ｕｐｐｅｒｌａｙｅｒｒｅｃｏｎｆｉｇｕｒｅｓｔｈｅＰＤＣＰｅｎｔｉｔｙｔｏｃｈａｎｇｅｂｅａｒｅｒｔｙｐｅｔｏＡＭＭＲＢ）、ＰＤＣＰステータス報告をトリガする。

（３）第３実施例
本実施例において、所定のベアラタイプ変更は、ＰＴＭのみのＭＲＢタイプから他のＭＲＢタイプへの変更である。すなわち、ＵＥ１００は、ＰＴＭのみからＰＴＭのみ以外に変更された時に（のみ）、ＰＤＣＰステータス報告をトリガする。

スプリットＭＲＢは、ＰＴＰレグを使ってパケットロス補償が可能であるが、ＰＴＭのみのＭＲＢについてパケットロス補償を行う場合、必ずベアラタイプ変更が必要になる。そのため、ＰＴＭのみからＰＴＭのみ以外に変更された時に（のみ）、ＰＤＣＰステータス報告をトリガすることとしている。

図２０は、本実施例に係るＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。図２０において、図１４と異なる部分を下線で示している。但し、図２０における「ＤＲＢ」を「ＭＲＢ」と読み替えてもよい。

ＵＥ１００は、当該ＭＲＢのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）にｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄが設定されており、且つ、ＰＴＰのみから他のタイプへのベアラタイプ変更を行うよう上位レイヤが当該ＰＤＣＰエンティティを再設定した場合（ｕｐｐｅｒｌａｙｅｒｒｅｃｏｎｆｉｇｕｒｅｓｔｈｅＰＤＣＰｅｎｔｉｔｙｔｏｃｈａｎｇｅｂｅａｒｅｒｔｙｐｅｆｒｏｍＰＴＰ－ｏｎｌｙｔｏｏｔｈｅｒｔｙｐｅ）、ＰＤＣＰステータス報告をトリガする。

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

第２実施形態において、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態でＭＢＳ受信（ＰＴＭ受信）を行うＵＥ１００がランダムアクセスプロシージャによりＲＲＣコネクティッド状態に遷移するシナリオを主として想定する。このようなシナリオにおいて、ランダムアクセスプロシージャの実行中は、ＵＥ１００がＭＢＳ受信を行うことができず、ＭＢＳデータのパケットロスが発生し得る。第２実施形態では、そのようなパケットロスを補償可能とする実施形態である。

例えば、ＵＥ１００は、ＲＲＣコネクティッド状態に遷移した時に、ＰＤＣＰステータス報告の送信を自発的にトリガする。ＵＥ１００のＲＲＣエンティティ１０２はＲＲＣコネクティッド状態に遷移した旨を受信側ＰＤＣＰエンティティ１０１に通知し、受信側ＰＤＣＰエンティティ１０１は、当該通知に応じてＰＤＣＰステータス報告の送信を自発的にトリガしてもよい。但し、ランダムアクセスプロシージャを実行してもパケットロスが発生しない場合もある。そのため、ＵＥ１００は、ＲＬＣでパケット破棄が発生した場合に、ＰＤＣＰステータス報告を自発的にトリガしてもよい。具体的には、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＲＬＣレイヤからパケット破棄を通知された場合に、ＰＤＣＰステータス報告を自発的にトリガしてもよい。

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

ステップＳ１１において、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態にあるＵＥ１００は、ＭＲＢを介してｇＮＢ２００からＭＢＳデータを受信する。

ステップＳ１２において、ＵＥ１００は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態からＲＲＣコネクティッド状態に遷移したこと、及びＲＬＣレイヤにおいてＭＢＳデータパケットの破棄が発生したことの少なくとも一方の条件が満たされたか否かを判定する。

当該少なくとも一方の条件が満たされた場合（ステップＳ１２：ＹＥＳ）、ステップＳ１３において、ＵＥ１００は、当該ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信を自発的にトリガする。

ステップＳ１４において、ＵＥ１００は、ＰＤＣＰステータス報告をｇＮＢ２００に送信する。

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

第３実施形態は、ｇＮＢ２００がＭＲＢについてベアラタイプ変更をＵＥ１００に指示する点は第１実施形態及び第２実施形態と同じであるが、当該指示の際に、ｇＮＢ２００がＰＤＣＰステータス報告をＵＥ１００にトリガさせる。具体的には、ｇＮＢ２００は、ＭＲＢのベアラタイプ変更を指示するＲＲＣメッセージ（ＲＲＣ再設定メッセージ）に、当該ＭＲＢと対応付けられたＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）の再確立を指示する第１情報要素（ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ）を含める。

但し、このようなＲＲＣ再確立を指示する場合、当該ＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）におけるヘッダ圧縮プロトコル、具体的には、ＲｏＨＣ（ＲｏｂｕｓｔＨｅａｄｅｒＣｏｍｐｒｅｓｓｉｏｎ）の動作がリセットされ、ＲｏＨＣコンテキストもリセットされてしまう。ＲｏＨＣコンテキストは、ヘッダにおける固定の値、及びヘッダにおける値を予測するための情報を含み、圧縮されたヘッダをＵＥ１００が復元するために必要な情報である。ＲｏＨＣコンテキストもリセットされると、ベアラタイプ変更後において、圧縮されていない完全なヘッダを送受信する必要があり、オーバーヘッドが大きくなるという問題がある。

よって、第３実施形態では、ｇＮＢ２００は、ＭＲＢのベアラタイプ変更を指示するＲＲＣ再設定メッセージに第１情報要素（ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ）を含める場合、ＵＥ１００のＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）のヘッダ圧縮プロトコルの状態（例えば、ＲｏＨＣコンテキスト）を維持することを指示する第２情報要素（ｄｒｂ－ＣｏｎｔｉｎｕｅＲＯＨＣ）を当該ＲＲＣ再設定メッセージに含める。これにより、ＵＥ１００のＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）のヘッダ圧縮プロトコルの状態（例えば、ＲｏＨＣコンテキスト）が維持されるため、ベアラタイプ変更後においても圧縮されたヘッダを送受信することが可能である。

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

ステップＳ１０１において、ＵＥ１００は、ｇＮＢ２００からＭＲＢを介してＭＢＳデータを受信する。

ステップＳ１０２において、ｇＮＢ２００は、当該ＭＲＢについてベアラタイプ変更を決定する。具体的には、ｇＮＢ２００は、ＰＴＰのみ、ＰＴＭのみ、及びスプリットＭＲＢ（ＰＴＰレグ及びＰＴＭレグ）の３つのタイプ間での変更を決定する。例えば、ｇＮＢ２００は、ＵＥ１００からの無線品質の報告（ｍｅａｓｕｒｅｍｅｎｔｒｅｐｏｒｔ）及び／又はｇＮＢ２００の無線リソース状況などに応じてステップＳ１０２の決定を行う。

ステップＳ１０３において、ｇＮＢ２００は、ベアラタイプ変更用のＲＲＣ再設定メッセージをＵＥ１００に送信する。ＲＲＣ再設定メッセージは、確立済みのＭＲＢのベアラタイプ変更を行う設定を含む。例えば、ＲＲＣ再設定メッセージは、当該ＭＲＢのベアラ識別子と、当該ＭＲＢの変更先のベアラタイプを示すベアラタイプ情報とを含んでもよい。ここで、ｇＮＢ２００は、当該ＭＲＢ識別子と対応付けて「ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ“ｔｒｕｅ”」及び「ｄｒｂ－ＣｏｎｔｉｎｕｅＲＯＨＣ“ｔｒｕｅ”」をＲＲＣ再設定メッセージにセットする。

ステップＳ１０４において、ＲＲＣ再設定メッセージを受信したＵＥ１００は、ＲＲＣ再設定メッセージに含まれる「ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ“ｔｒｕｅ”」に応じてＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）を再確立し、当該再確立に応じてＰＤＣＰステータス報告の送信をトリガする（図１４のＰＤＣＰ動作を参照）。ここで、ＵＥ１００は、ＲＲＣ再設定メッセージに含まれる「ｒｅｅｓｔａｂｌｉｓｈＰＤＣＰ“ｔｒｕｅ”」に応じて、ＲｏＨＣ処理を継続する（具体的には、直前まで使っていたＲｏＨＣコンテキストを使用継続し、ＲｏＨＣ状態も維持する）。

ステップＳ１０５において、ＵＥ１００は、ＰＤＣＰステータス報告をｇＮＢ２００に送信する。ｇＮＢ２００は、ＰＤＣＰステータス報告を受信する。

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

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

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

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

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

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

（付記）
１．導入
ＲＡＮ２＃１１５ｅでは、ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）の作業項目が、マルチキャストサービスの継続性について次の合意を達成した。

ＲＲＣシグナリングでは、１つのＭＲＢを、ＰＴＭのみ、ＰＴＰのみ、又はＰＴＭとＰＴＰとの両方で設定できる。ＰＴＭ、ＰＴＭ＋ＰＴＰ、又はＰＴＰのみ、のいずれかをＲＲＣシグナリングで変更できる。

ＲＲＣ信号において、ＰＴＭ用のＵＭＲＬＣ設定のみのDL、ＰＴＰ用のＤＬ及びＵL ＡＭＲＬＣ設定、ＰＴＰ用のＵＭＲＬＣ設定のみのDLをサポートする。ＰＴＰ用のＤＬ及びＵＬＵＭＲＬＣ設定をサポートすることについては更なる検討が必要である。

ＲＲＣ信号のベアラタイプ変更に伴うＰＤＣＰＳＲの発生可否と、発生した場合のＰＤＣＰＳＲの発生方法とについては更なる検討を行う。

上記の最初の合意に準拠したＲＲＣ再構成を超えるＰＴＭのインアクティブ化／アクティブ化はサポートされない。

構成中のＰＴＭＰＤＣＰ状態変数のセットでは、これらの変数のＣＯＵＮＴ値のＳＮ部分は、（ＵＥによって）最初に受信されたパケットのＳＮと、必要に応じてｇＮＢによって示されるＨＦＮとに従ってセットされる。

ＭＲＢ構成のＰＴＭＲＬＣエンティティを初期化し、ＳＮを含む最初の受信パケットのＳＮに応じて、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ及びＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙの値をセットする。

ＭＲＢ構成により、ＰＴＰＲＬＣ受信ウィンドウの０ＲＬＣ状態変数を初期値（０）にセットすることができる。

本付記では、マルチキャストのサービス継続に関する残された課題について議論する。

２．議論
２．１．ベアラタイプ変更時のＰＤＣＰステータス報告
ＲＡＮ２＃１１５ｅでは、以下のオープンイシューが合意された。

ＲＲＣ信号において、ＰＴＭのＵＭＲＬＣ構成のみのＤＬ、ＰＴＰのＤＬとＵＬのＡＭＲＬＣ構成、ＰＴＰのＵＭＲＬＣ構成のみのＤＬをサポートする。ＰＴＰのDL及びUL ＵＭＲＬＣ構成をサポートすることについては、更なる検討が必要である。

現在のＰＤＣＰ仕様によれば、ＰＤＣＰステータス報告は、主にＡＭＤＲＢ（場合によってはＵＭＤＲＢ）に対して、以下のイベント発生時にＲＲＣによってトリガされる。

上りリンクでＰＤＣＰステータス報告を送信するように上位層によって構成されたＡＭＤＲＢ（ＴＳ３８．３３１のｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄ）の場合、受信ＰＤＣＰエンティティは、次の場合にＰＤＣＰステータス報告をトリガする必要がある。
－上位層はＰＤＣＰエンティティの再確立を要求する。
－上位層がＰＤＣＰデータ回復を要求する。
－上位レイヤが上りリンクデータスイッチングを要求する。
－上位層はＰＤＣＰエンティティを再構成してＤＡＰＳを解放し、ｄａｐｓ－ＳｏｕｒｃｅＲｅｌｅａｓｅはＴＳ３８．３３１で構成される。

上りリンクでＰＤＣＰステータス報告（ＴＳ３８．３３１のｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄ）を送信するように上位層によって構成されたＵＭＤＲＢの場合、受信ＰＤＣＰエンティティは、次の場合にＰＤＣＰステータス報告をトリガする必要がある。
上位レイヤは、上りリンクデータ切替を要求する。

ＭＢＳでは、ＰＴＭのみのＭＲＢはＲＬＣＵＭでのみ構成されるが、ＰＴＰのみのＭＲＢとスプリットＭＲＢのＰＴＰレグとはＲＬＣＵＭ又はＲＬＣＡＭで構成される。これらは、それぞれＵＭＭＲＢ及びＡＭＭＲＢと呼ばれる。

現在のＲＲＣ仕様によると、ＲＲＣ再構成の処理遅延に関するＵＥのパフォーマンス要件は１０ｍｓで規定されている。そのため、ＵＥは、ベアラタイプ変更のためのＲＲＣ再構成中にＭＢＳ送信を見逃す可能性があり、欠落したパケットは、ベアラタイプ変更後に補償する必要がある。この意味で、ＰＤＣＰステータス報告は、少なくとも特定のＭＢＳサービスによって要求されるより高い信頼性を満たすためにサポートされるべきである。

また、どのような場合にＰＤＣＰステータス報告が必要であるかについても検討する価値がある。ＡＭＭＲＢの場合は、一般的に「高ＱｏＳ」のＭＢＳサービスを想定しているため、ベアラタイプ変更の際にも信頼性が求められることは明らかである。ＡＭＭＲＢ間でベアラタイプを変更する場合、ＵＭＭＲＢからＡＭＭＲＢへ変更する場合も含まれる。

提案１：ＲＡＮ２は、少なくともＡＭＭＲＢ間、及びＵＭＭＲＢからＡＭＭＲＢへのロスレスベアラタイプの変更にＰＤＣＰステータス報告がサポートされることに合意すべきである。

一般に、ＵＭＭＲＢはベアラタイプ変更時の信頼性、すなわちロスレスを必要としないと考えられる。しかし、ＵＭＭＲＢを「高ＱｏＳ」ＭＢＳサービスに使用するかどうかは、実際にはＮＷの実装に委ねることができる。無線状態が良好なＵＥに対してはＰＴＭのみのＭＲＢを使用し、無線状態が一定以上悪化した場合にはＰＴＰのみのＭＲＢ（又は、スプリットＭＲＢ）に再構成することで、ＮＷはリソースを効率的に運用することができる。現在の仕様では、ある場合にＵＭＤＲＢがＰＤＣＰステータス報告をトリガすることが認められていることを考えると、ＮＷがＰＤＣＰステータス報告を必要とするかどうかをＵＭＭＲＢに設定できることは容易に明らかである。この場合、ＰＴＰのみのＭＲＢとスプリットＭＲＢのＰＴＰレグには、ＤＬ／ＵＬ双方向ＵＭ、すなわちＭＢＳデータ受信用のＤＬＲＬＣエンティティ及びＰＤＣＰステータス報告送信用のＵＬＲＬＣエンティティを設定する必要がある。

提案２：ＲＡＮ２は、ＵＭＭＲＢのベアラタイプ変更時にＰＤＣＰステータス報告を使用するかどうかはＮＷの実装次第であることに合意すべきである。そのためにはＤＬ／ＵＬ双方向ＲＬＣＵＭでＰＴＰを構成できる仕様が必要である。

２．２．ＰＴＭのＰＤＣＰ／ＲＬＣ状態変数
２．２．１．初期値
ＲＡＮ２＃１１５ｅでは、以下の記述に合意した。

構成中のＰＴＭＰＤＣＰ状態変数のセットについては、これらの変数のＣＯＵＮＴ値のＳＮ部は、（ＵＥによる）最初の受信パケットのＳＮと、必要に応じてｇＮＢによって示されるＨＦＮとに従って設定される。

ＭＲＢ構成のＰＴＭＲＬＣエンティティを初期化し、ＳＮを含む最初の受信パケットのＳＮに応じて、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ及びＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙの値を設定する。

２つの契約における「ａｃｃｏｒｄｉｎｇｔｏ」という言葉は、次のような３つの選択肢を意図している。

選択肢１：各状態変数の初期値は、単純に最初に受信したパケットのSNにセットされる。

選択肢２：Ｒｅｌ－１６Ｖ２Ｘ解決策が再利用される。

ＰＤＣＰ「ＲＸ＿ＮＥＸＴ」の場合、「ＲＸ＿ＮＥＸＴのＳＮ部の初期値は(x +1) modulo (2^{[sl-PDCP-SN-Size]})、ｘは最初に受信したＰＤＣＰデータＰＤＵのＳＮである」。
ＰＤＣＰ「ＲＸ＿ＤＥＬＩＶ」の場合、「ＲＸ＿ＤＥＬＩＶのＳＮ部の初期値は(x - 0.5 × 2^{[sl-PDCP-SN-Size-1]}) modulo (2^{[sl-PDCP-SN-Size]})、ｘは最初の受信ＰＤＣＰＤａｔａＰＤＵのＳＮ」。
ＲＬＣＵＭ「ＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙ」については、「ＳＮを含む最初に受信したＵＭＤＰＤＵのＳＮに初期設定される」。
ＲＬＣＵＭ「ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ」について、「ＳＮを含む最初に受信したＵＭＤＰＤＵのＳＮに初期設定される」。

選択肢３：ＲＬＣＵＭのための新しいメカニズムが導入される。

ＰＤＣＰ状態変数については、選択肢１又は選択肢２のいずれかを適用することができる。
ＲＬＣＵＭ「ＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙ」については、「ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ」よりも前の値に初期設定される。
ＲＬＣＵＭ「ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔ」については、上記選択肢２と同様に、「ＳＮを含む最初に受信したＵＭＤＰＤＵのＳＮに初期設定される」。

ＰＤＣＰの状態変数では、選択肢２の場合、次に受信するパケットであるＲＸ＿ＮＥＸＴは、（［最初に受信したパケットのＳＮ］＋１）に設定される。上位層に配信されない最初のパケットであるＲＸ＿ＤＥＬＩＶは、（［最初に受信したパケットのＳＮ］－［ＳＮ長の１／４］）に設定される。これは、最初に受信したパケットの後に古いパケットを受信しても、並べ替えを行うことができることを意味する。したがって、選択肢２は選択肢１よりも信頼性が高いと考えられる。

提案３：ＲＡＮ２は、Ｒｅｌ－１６Ｖ２Ｘと同様に、ＲＸ＿ＮＥＸＴの初期値を（［最初に受信したパケットのＳＮ］＋１）ｍｏｄｕｌｏ（２＾［ＰＤＣＰＳＮｌｅｎｇｔｈ］）とすることにＰＤＣＰに対して合意すべきである。

提案４：ＲＡＮ２は、ＲＸ＿ＤＥＬＩＶの初期値を、Ｒｅｌ－１６Ｖ２Ｘと同様に、｛［最初の受信パケットのＳＮ］－２＾（［ＰＤＣＰＳＮ長］－２）｝ｍｏｄｕｌｏ（２＾［ＰＤＣＰＳＮ長］）とすることにＰＤＣＰについて合意すべきである。

ＲＬＣ状態変数については、選択肢１と選択肢２が全く同じである。また、選択肢２と選択肢３は、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔの点でも同じである。したがって、ＲＡＮ２は、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔの初期値について、他の解がないことを確認すればよい。

提案５：ＲＡＮ２は、Ｒｅｌ－１６Ｖ２Ｘと同様に、ＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔの初期値が最初に受信したパケットのＳＮであるというＲＬＣＵＭに合意すべきである。

ＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙに関して、選択肢２と選択肢３とは異なる。選択肢３の利点は、ＰＤＣＰ状態変数の選択肢２と似ている。つまり、最初に受信したパケットの後に受信した古いパケットを破棄することを回避できる。ＲＬＣセグメンテーションが実行された場合にのみこの問題が発生することも指摘されているが、パケット損失が最小限に抑えられれば常に良いことである。

提案６：ＲＡＮ２はＲＬＣＵＭについて、ＲＸ＿Ｎｅｘｔ＿Ｒｅａｓｓｅｍｂｌｙの初期値が最初に受信したパケットのＳＮであるか（Ｒｅｌ－１６Ｖ２Ｘと同じ）、又はＲＸ＿Ｎｅｘｔ＿Ｈｉｇｈｅｓｔの前の値であるかについて議論すべきである。

２．２．２．ＨＦＮプロビジョニング
１）ＳＡ３がセキュリティのためにＨＦＮを使用するかどうか、２）ＲＡＮ２＃１１５ｅで説明したように、ＣＯＵＮＴがＨＦＮパートを有するためＰＤＣＰステータス報告がサポートされるかどうか、などである。ＰＤＣＰステータス報告は、ハンドオーバの場合にサポートされることが既に合意されており、２．１節のようにベアラタイプ変更の場合にもサポートされると思われる。そのため、ＲＡＮ２が合意したように、ＨＦＮはｇＮＢによって示される必要がある。

その上で、ｇＮＢがＵＥにどのようにＨＦＮを提供するかを議論すべきである。ＨＦＮを提供する方法としては、以下の選択肢が考えられる。
Ａｌｔ．１：ＲＲＣ再構成
Ａｌｔ．２：ＰＤＣＰ制御ＰＤＵ
Ａｌｔ．３：ＭＣＣＨ
Ａｌｔ．４：ＳＩＢ
Ａｌｔ．５：ＰＤＣＰデータＰＤＵのヘッダ

Ａｌｔ．１は、ｇＮＢがＲＲＣ再構成によってＵＥにマルチキャスト用のＭＲＢを構成する必要があり、つまり、ＨＦＮはＭＲＢと一緒に設定されるため、簡単だと考えられている。しかし、ＲＲＣ再構成は特定のＵＥに対する専用のシグナリングであり、基本的に第１配信モード（Ｄｅｌｉｖｅｒｙｍｏｄｅ１：ＤＭ１）でのみ使用され、Ａｌｔ．２と比較して処理が少し重いという欠点がある。また、ＲＲＣ再構成の受信と最初の受信パケットとの間に一定のタイミングのギャップがあり、ＨＦＮ非同期の原因となる可能性がある。さらに、ＨＦＮがどのＭＲＢに適用されるかを示すための追加情報が必要な場合がある。

Ａｌｔ．２は、ｇＮＢがＰＴＭ上でＨＦＮを指示することができるため、より軽量で効率的なシグナリングであると考えられている。ＰＤＣＰエンティティはＭＲＢと関連付けられているため、追加情報であるＨＦＮとＭＲＢとのマッピングは不要である。つまり、このＰＤＣＰ制御ＰＤＵを受信したＰＤＣＰエンティティは、ＨＦＮを初期値として適用すれば良い。これは、第１配信モードと第２配信モード（Ｄｅｌｉｖｅｒｙｍｏｄｅ２：ＤＭ２）とで一般的に使用されている。また、同じＰＤＣＰエンティティがこれらのＰＤＣＰＰＤＵを処理するため、ＰＤＣＰ制御ＰＤＵと最初に受信したパケットとの間のタイミングのギャップを最小にすることができる可能性がある。ただし、ＰＤＣＰ制御ＰＤＵはセキュリティ保護されていないことが懸念される。

Ａｌｔ．３は別の可能性であるが、ＭＣＣＨは第２配信モードにのみ適用可能であり、第１配信モードを受信するＵＥにＭＣＣＨの取得という追加の負担を義務付けることは好ましくないと考えられる。また、ＭＣＣＨの受信と最初の受信パケットとの間に一定のタイミングのギャップがある可能性がある。さらにＡｌｔ．１と同様にＨＦＮとＭＲＢとのマッピングという追加情報が必要になる可能性があるため、ＭＣＣＨの取得を義務付けることは好ましくない。

Ａｌｔ．４は通常のプロビジョニング方法として考えられている。ＳＩＢは基本的に第１配信モード１及び第２配信モードの両方に適用されるが、マルチキャスト受信のために接続されたＵＥがＳＩＢを監視することが義務付けられているかどうかは、まだ不明である。懸念点としては、Ａｌｔ．２と同様にＳＩＢがセキュリティ保護されていないこと、Ａｌｔ．１と同様にＨＦＮとＭＲＢとのマッピングという追加情報が発生すること、ＳＩＢ受信と最初の受信パケットとの間に一定のタイミングのギャップが生じることなどが挙げられる。また、オンデマンドＳＩを適用する場合、ＵＥはＳＩＢを取得する前にオンデマンドＳＩ要求メッセージを送信する必要があり、ＨＦＮ初期化の遅延を引き起こす可能性がある。

Ａｌｔ．５には、Ａｌｔ．２と同様の利点が見られる。つまり、ＰＴＭ方式で配信でき、追加情報は必要なく、第１配信モード及び第２配信モードの共通の解決策である。Ａｌｔ．５が最初に受信したパケットがＨＦＮを一緒に伝達するため、最も重要な利点は、理論的にはタイミングのギャップである。ただし、ＨＦＮが最初に受信したパケットのヘッダに含まれていると仮定すると、パケットがＰＴＭを介して他のＵＥに送信され始めていることを考えると、ｇＮＢがＵＥの最初に受信したパケットをどのように知るかは疑問である。それ以外の場合、ｇＮＢは常に各データパケットにＨＦＮを含める必要がある。懸念事項は、Ａｌｔ．２と同様にＰＤＣＰヘッダがセキュリティ保護されていないことである。ＨＦＮプロビジョニングは、Ａｌｔ．２を含む他の代替案と同様にＣプレーンシグナリングと見なされるため、概念／原理の観点からは少し奇妙である。一方、Ａｌｔ．５はＵプレーンデータを使用する。

別の角度から見ると、第１配信モード（ＤＭ１）と第２配信モード（ＤＭ２）とでは、ＨＦＮの提供方法に違いがあることがわかる。一般に、ＤＭ１（又は、マルチキャスト）はＤＭ２（又は、ブロードキャスト）よりも安全である。これは、構成が専用のシグナリングによって提供されるためである（また、ＮＡＳではセッション参加手順が利用可能である）。この意味で、ＨＦＮもＤＭ１で安全に提供する必要がある。この場合、最も簡単な解決策はＡｌｔ．１であるが、ＤＭ１とＤＭ２との共通性を実現するには適していない。Ａｌｔ．２は、ＰＤＣＰ制御ＰＤＵがＣ－ＲＮＴＩで送信される場合、Ａｌｔ．３、Ａｌｔ．４、Ａｌｔ．５よりもある程度のセキュリティを確保できると想定される。一方、ＤＭ２はＵＥにＣＯＮＮＥＣＴＥＤへの移行を義務付けるべきではなく、ＨＦＮの取得のみを目的としている。ＤＭ２をサポートするために、ＨＦＮは定期的にブロードキャスト方式で（つまり、Ｇ－ＲＮＴＩ、ＭＣＣＨ－ＲＮＴＩ、又はＳＩ－ＲＮＴＩを使用して）提供される。

上記のとおり、（以下の表にも要約されているように）、ＨＦＮはＰＤＣＰ制御ＰＤＵ（つまり、Ａｌｔ．２）を介して提供されることが、パフォーマンスとセキュリティのバランスが取れており、また、両方の配信モード（つまり、ＤＭ１及びＤＭ２）に共通の解決策であるため、わずかに好ましいと言える。

提案７：ＲＡＮ２は、ＨＦＮの初期値がＰＤＣＰ制御ＰＤＵを介して提供されることに合意すべきである。

提案８：提案７が合意可能である場合、ＲＡＮ２はさらに、ＰＤＣＰ制御ＰＤＵ（ＨＦＮプロビジョニング用）をＧ－ＲＮＴＩ及びＣ－ＲＮＴＩと共に送信できることに合意すべきである。

２．２．３．ＨＦＮ初期化前のデータ受信
ＵＥは、ＨＦＮを受信する前にデータを受信する可能性がある。これは、ＨＦＮと最初に受信したパケットの受信タイミングが、順序どおりでない配信（たとえば、悪い無線状態での再送信及び／又はハンドオーバ中の再送信など）により異なる可能性があるためである。及び／又は、セクション２．２．２のどの選択肢が選択されているかによって異なる。さらに、当該ＰＴＭ送信は、他のＵＥへの送信が既に開始されているため、ＵＥは、ＭＲＢをセットするとすぐにデータを受信することができる。

所見１：ＵＥは、ＨＦＮ初期化の前に、ＰＴＭを介してＭＢＳデータを受信する場合がある。

現在のＰＤＣＰ仕様では、ＲＲＣがＰＤＣＰエンティティの確立、ＰＤＣＰエンティティの再確立、又はＰＤＣＰエンティティの一時停止を要求すると、ＲＸ＿ＮＥＸＴとＲＸ＿ＤＥＬＩＶとは初期値に（再）設定される。当然、ＣＯＵＮＴ値の初期化はデータ受信前に行われる。したがって、ＰＤＣＰの観点からは、たとえ下位層がデータ受信の準備を完了していても、データが受信されない場合がある。つまり、ＲＬＣ層がＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）をＰＤＣＰ層に送信したとしても、データが受信されない場合がある。ＰＤＣＰがこれらのＰＤＣＰＰＤＵを受け入れたとしても、ＨＦＮがまだアオリスティックであるため、これらのＰＤＵは完全性検証の失敗により破棄される。

所見２：ＨＦＮの初期化の前に、現在の仕様によると、下位層からのＰＤＣＰＰＤＵは受け入れられないか、ＰＤＣＰ層で破棄される可能性がある。

したがって、セクション２．２．１で説明されているＳＮの状態変数の初期化のすべての拡張機能（一部）と、セクション２．２．２で説明されているように、パケット損失を最小限に抑えることを目指している。簡単な方法の１つは、ＰＤＣＰがこれらのＰＤＵをＰＤＣＰ処理の前に一時的にバッファリングし、ＨＦＮの初期化後にこれらのＰＤＵの処理を開始することである。

提案９：ＲＡＮ２は、ＨＦＮの初期化の前に、ＵＥが受信したデータパケットをどのように処理するかについて議論すべきである。

２．２．４．ＨＦＮプロビジョニングのリクエスト
もう１つの考えられる問題は、ＵＥがｇＮＢに現在のＨＦＮを問い合わせることが許可されているかどうかである。特にＰＴＭのみのＭＲＢの場合、たとえばカバレッジホールや干渉が原因で、ＵＥが一定期間パケットを受信できなかった場合、ＨＦＮが非同期になる可能性がある。もう１つのケースは、（セクション２．２．２で簡単に説明したように）ＨＦＮがＭＢＳセッションのアクティブ化時にのみ提供される場合、ＵＥが既にアクティブ化されているＭＢＳセッションに後で参加するときにＨＦＮを必要とすることである。

そのため、ＵＥがＨＦＮプロビジョニングの必要性に気付いた場合、ＵＥが現在のＨＦＮを提供するようｇＮＢに要求できるようにすると便利である。たとえば、ＲＲＣシグナリング又はＰＤＣＰ制御ＰＤＵを介して、要求を送信する方法については更なる検討が必要である。同じ条件で、ＵＥは、受信ウィンドウの外にある次のパケットを受信しない場合がある。この場合、ＵＥは、すべての状態変数を初期値にリセットすることができる。

提案１０：ＲＡＮ２は、ＵＥがｇＮＢにＭＢＳセッションの現在のＨＦＮを提供するよう要求することを許可されているかどうかを議論すべきである。

提案１１：ＲＡＮ２は、ＵＥが一定期間ＭＢＳセッションの受信に失敗した場合に状態変数をリセットできるかどうかについて議論すべきである。

２．３．ロスレスモビリティオペレーション
「ＲＡＮ２は、これを必要とするサービスのためにＭＢＳ－ＭＢＳモビリティのロスレスハンドオーバをサポートすることを目指している（シナリオの詳細は未定だが、少なくともＰＴＰ－ＰＴＰ）」及び「ＵＥ側からは、ＰＤＣＰステータス報告もサポートされる可能性がある」。これらの合意は、ＭＲＢがＰＴＰのみで構成されている場合、ユニキャストの既存のハンドオーバと非常によく似たメカニズムを意味する。

所見３：ロスレスハンドオーバをサポートするために、ユニキャスト用の既存のハンドオーバ機構をＰＴＰのみで構成されたＭＲＢに再利用することが可能である。

そこで、ＰＴＭ（－ｌｅｇ）を含むハンドオーバの場合、すなわち、ＰＴＭのみで構成されたＭＲＢ及びＰＴＰレグとＰＴＭレグとを含むスプリットＭＲＢについて検討する必要がある。

スプリットＭＲＢは、ＰＴＭレグを使用しない場合は、ＰＴＰのみのＭＲＢとみなすことができる。そのため、従来のユニキャストハンドオーバをベースに、ロスレスハンドオーバを容易にサポートすることができる。そこであるスプリットＭＲＢの基本的な手順は、以下のように考えられる。

ステップ１：スプリットＭＲＢのＰＴＰレグは、必要に応じて、ソースセルでロスレス動的切替により使用される。
ステップ２：ＵＥは、ＰＴＰ－ＰＴＰハンドオーバ（又は、ユニキャストハンドオーバのように）、ロスレスハンドオーバを実行する。
ステップ３：スプリットＭＲＢのＰＴＭレグは、必要に応じて、ロスレス動的切替によってターゲットセルで使用される。

このとき、ＮＷの実装によって確保されるロスレス動的切替が重要な役割を果たすことになる。

所見４：スプリットＭＲＢのロスレスハンドオーバには、ロスレスの動的ＰＴＭ／ＰＴＰ切替が不可欠である。

ＰＴＭのみのＭＲＢに関しては、以下のように非常に類似した手順が適用可能である。

ステップ１：ソースセルにおいて、ロスレスベアラタイプ変更により、ＰＴＭ用のＭＲＢをＰＴＰ用のＭＲＢ（又は、スプリットＭＲＢ）に再構成する。
ステップ２：ＵＥは、ＰＴＰ－ＰＴＰハンドオーバとして（又は、ユニキャストハンドオーバのように）、ロスレスハンドオーバを実行する。
ステップ３：ロスレスベアラタイプ変更により、必要に応じて、ターゲットセルにおいて、ＰＴＰのみのＭＲＢ（又は、スプリットＭＲＢ）をＰＴＭのみのＭＲＢに再構成することができる。

この場合、２．１節で述べたロスレスベアラタイプの変更もロスレスハンドオーバのために重要である。

所見５：ＰＴＭのみのＭＲＢのロスレスハンドオーバには、ロスレスベアラタイプ変更が必須である。

以上のことから、ロスレスハンドオーバの基本手順のポイントは、ＰＴＰレグを使用するか、ＰＴＭのみのＭＲＢを再構成する（＝ステップ１）ことと、ハンドオーバ実行は既存のユニキャストハンドオーバと同じで、何の拡張もないことである。

提案１２：ＲＡＮ２は、ＭＲＢの基本的なロスレスハンドオーバが常にＰＴＰ（－ｌｅｇ）を含む必要があることに合意すべきである。つまり、スプリットＭＲＢのＰＴＰレグが使用されるか、ＰＴＭのみのＭＲＢをＰＴＰのみのＭＲＢ（又は、スプリットＭＲＢ）に再構成してからハンドオーバを実行する。

提案１３：ＲＡＮ２は、ＭＲＢのハンドオーバの実行はユニキャストのハンドオーバと同じであること、つまり、基本的なロスレスハンドオーバのための拡張は必要ないことに合意すべきである。

次に、最も興味深い高度な手順は、直接ＰＴＭ－ＰＴＭハンドオーバである。つまり、ＰＴＭ（－ｌｅｇ）を介してＭＢＳを受信しているＵＥがロスレスハンドオーバを実行する。上記の基本的なハンドオーバ手順のシグナリングオーバーヘッドと複雑さを軽減できる。つまり、ステップ１とステップ３とをスキップできる。さらに、このような直接的なＰＴＭ－ＰＴＭロスレスハンドオーバは、特にＰＴＰレグが設定されたスプリットＭＲＢで予想されると考えられる。つまり、より高い信頼性を必要とするサービスに使用される。ただし、それはすでにリリース１７タイムフレームの中間点を過ぎており、ＷＩＤは「サービス継続性を伴う基本的なモビリティのサポートを指定する」と述べているだけである。そのため、高度なロスレスハンドオーバは、将来のリリースまで延期する必要がある。

所見６：ＰＴＭ（－ｌｅｇ）を介してＭＢＳサービスを受けるＵＥの高度なロスレスハンドオーバ、つまり「直接ＰＴＭ－ＰＴＭハンドオーバ」は、特定のサービスでは有用であると考えられるが、Ｒｅｌ１７タイムフレームの残りの時間を考慮すると、将来のリリースに延期する必要がある場合がある。

２．４．マルチキャストのＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎ
ＲＡＮ２は現在、ブロードキャストセッションではＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎがサポートされていると想定しているが、マルチキャストセッションではサポートされていない。ＲＡＮ２＃１１５ｅは、次のようにＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎの基本的な内容に合意した。

ＣＯＮＮＥＣＴＥＤの場合
ＵＥは以下のＭＢＳＩｎｔｅｒｅｓｔｉｎｆｏｒｍａｔｉｏｎを（ＬＴＥＳＣ－ＰＴＭとして）報告する。
ＭＢＳ周波数リスト
リスト化されたすべてのＭＢＭＳ周波数の受信と、任意のユニキャスト・ベアラの受信の間の優先順位
ＴＭＧＩリスト
ＭＢＳ周波数の報告が許可されている場合、ＵＥが報告するＭＢＳ周波数は、ＬＴＥＳＣ－ＰＴＭと同様に関心の高い順に並べ替えられる。

マルチキャストセッションの場合、マルチキャストセッションでは上位層にセッション参加手順があるため、コアネットワークがｇＮＢにＵＥの関心を通知するというのが一般的な理解のようである。これはＵＥの興味のあるＭＢＳサービスに当てはまる。また、ｇＮＢがＭＢＳ周波数と、ＵＥの興味のあるＭＢＳサービスを提供するセルを知っている可能性もある。ただし、ＭＢＳ受信とユニキャストの間の優先順位は、純粋にＡＳ関連の情報であるため、コアネットワークによって提供されない場合がある。

所見７：マルチキャストセッションでは、コアネットワークはＵＥの関心事であるＭＢＳサービスをｇＮＢに提供し、ｇＮＢはＭＢＳ周波数／セルを知っている可能性がある。しかし、コアネットワークとｇＮＢとは、ＭＢＳとユニキャストとの間のＵＥのＡＳ優先度を知らない可能性がある。

優先度情報は、ＬＴＥｅＭＢＭＳと同様に、スケジューリングやハンドオーバの決定など、ｇＮＢにとっても有用であり、サービスの継続性にも関係すると考えられる。したがって、ＵＥは、マルチキャストセッションについても、その優先度情報をｇＮＢに通知する必要がある。この意味で、ＲＡＮ２は、マルチキャストサービス／配信モード１についてもＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎがサポートされるべきであると合意すべきである。

提案１４：ＲＡＮ２は、少なくともＵＥがＭＢＳ受信とユニキャスト受信との間の優先順位をｇＮＢに通知するために、ＭＢＳＩｎｔｅｒｅｓｔＩｎｄｉｃａｔｉｏｎがマルチキャストセッション／第１配信モードでもサポートされることに合意すべきである。

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

Claims

マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムにおける通信方法であって、
ユーザ装置が、マルチキャスト無線ベアラ（ＭＲＢ）を介してネットワークノードからＭＢＳデータを受信することと、
前記ユーザ装置が、前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記ネットワークノードから受信することと、
前記ユーザ装置が、前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更が特定のＭＲＢタイプからＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガすることと、
前記ユーザ装置が、前記ＰＤＣＰステータス報告を前記ネットワークノードに送信することと、を有する
通信方法。
前記特定のＭＲＢタイプからＡＭのＭＲＢタイプへの変更は、ＵＭ（ＵｎａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のＭＲＢタイプから前記ＡＭのＭＲＢタイプへの変更、又はＡＭのＭＲＢタイプからベアラの構成が異なる前記ＡＭのＭＲＢタイプへの変更である
請求項１に記載の通信方法。
前記ユーザ装置が、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態からＲＲＣコネクティッド状態に遷移したこと、及び／又は、ＲＬＣレイヤにおいてＭＢＳデータパケットの破棄が発生したことに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信を自発的にトリガすることをさらに有する
請求項１に記載の通信方法。
前記ネットワークノードが、前記ＭＲＢのベアラタイプ変更を指示するメッセージであって、前記ＭＲＢと対応付けられたＰＤＣＰエンティティの再確立を指示する第１情報要素を含むＲＲＣ再設定メッセージを前記ユーザ装置に送信することと、
前記ネットワークノードが、前記第１情報要素に基づいて前記ユーザ装置から送信されるＰＤＣＰステータス報告を受信することと、をさらに有し、
前記ＲＲＣ再設定メッセージを送信することは、前記第１情報要素を前記ＲＲＣ再設定メッセージに含める場合、前記ＰＤＣＰエンティティのヘッダ圧縮プロトコルの状態を維持することを指示する第２情報要素をさらに含む前記ＲＲＣ再設定メッセージを送信することを含む
請求項１に記載の通信方法。
マルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いるユーザ装置であって、
マルチキャスト無線ベアラ（ＭＲＢ）を介してネットワークノードからＭＢＳデータを受信し、前記ＭＲＢのベアラタイプ変更を指示する無線リソース制御（ＲＲＣ）再設定メッセージを前記ネットワークノードから受信する受信部と、
前記ＲＲＣ再設定メッセージにより指示された前記ベアラタイプ変更が特定のＭＲＢタイプからＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のＭＲＢタイプへの変更であることに応じて、前記ＭＲＢと対応付けられたＰＤＣＰエンティティにおけるデータ受信状況を示すＰＤＣＰステータス報告の送信をトリガする制御部と、
前記ＰＤＣＰステータス報告を前記ネットワークノードに送信する送信部と、を備える
ユーザ装置。
ユーザ装置に用いられ、請求項１に記載の通信方法を実行する
プロセッサ。
ユーザ装置に請求項１に記載の通信方法を実行させる
プログラム。
請求項５に記載のユーザ装置と、ネットワークノードとを有する
移動通信システム。