知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024083465
(43)【公開日】2024-06-21
(54)【発明の名称】通信方法、ユーザ装置、プログラム、及びプロセッサ
(51)【国際特許分類】
H04W 76/25 20180101AFI20240614BHJP
H04W 4/06 20090101ALI20240614BHJP
H04W 80/02 20090101ALI20240614BHJP
H04W 24/02 20090101ALI20240614BHJP
【ＦＩ】
H04W76/25
H04W4/06
H04W80/02
H04W24/02
【審査請求】有
【請求項の数】13
【出願形態】ＯＬ
(21)【出願番号】P 2024061033
(22)【出願日】2024-04-04
(62)【分割の表示】P 2023540377の分割
【原出願日】2022-08-03
(31)【優先権主張番号】63/229,155
(32)【優先日】2021-08-04
(33)【優先権主張国・地域又は機関】US
(71)【出願人】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
(57)【要約】
【課題】改善されたマルチキャストブロードキャストサービスを実現可能とする。
【解決手段】マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる通信方法は、基地局からのＭＢＳセッションの受信を開始したユーザ装置が、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理するステップと、前記ユーザ装置が、前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記基地局が管理している第２のＰＤＣＰ変数と同期させるための制御を行うステップと、を有する。
【選択図】図１４
【解決手段】マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる通信方法は、基地局からのＭＢＳセッションの受信を開始したユーザ装置が、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理するステップと、前記ユーザ装置が、前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記基地局が管理している第２のＰＤＣＰ変数と同期させるための制御を行うステップと、を有する。
【選択図】図１４
【特許請求の範囲】
【請求項1】
マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる通信方法であって、
ネットワークノードからのＭＢＳセッションの受信を開始したユーザ装置が、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理することと、
前記ユーザ装置が、前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記ネットワークノードが管理している第２のＰＤＣＰ変数と同期させるための制御を行うことと、を有する
通信方法。
ネットワークノードからのＭＢＳセッションの受信を開始したユーザ装置が、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理することと、
前記ユーザ装置が、前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記ネットワークノードが管理している第２のＰＤＣＰ変数と同期させるための制御を行うことと、を有する
通信方法。
【請求項2】
前記制御を行うことは、
前記第２のＰＤＣＰ変数を確認するための要求を前記ネットワークノードに送信することと、
前記要求に応じて前記ネットワークノードから送信される前記第２のＰＤＣＰ変数を受信することと、を含む
請求項１に記載の通信方法。
前記第２のＰＤＣＰ変数を確認するための要求を前記ネットワークノードに送信することと、
前記要求に応じて前記ネットワークノードから送信される前記第２のＰＤＣＰ変数を受信することと、を含む
請求項１に記載の通信方法。
【請求項3】
前記要求を送信することは、前記要求と、前記要求と対応付けられた識別子と、を含むＲＲＣメッセージを前記ネットワークノードに送信することを含み、
前記識別子は、前記ＭＢＳセッションのＭＢＳセッション識別子及び前記ＭＢＳセッションがマッピングされたマルチキャスト無線ベアラ（ＭＲＢ）に関する識別子の少なくとも一方を含む
請求項２に記載の通信方法。
前記識別子は、前記ＭＢＳセッションのＭＢＳセッション識別子及び前記ＭＢＳセッションがマッピングされたマルチキャスト無線ベアラ（ＭＲＢ）に関する識別子の少なくとも一方を含む
請求項２に記載の通信方法。
【請求項4】
前記要求を送信することは、前記要求を含むＰＤＣＰ制御ＰＤＵを前記ネットワークノードに送信することを含む
請求項２に記載の通信方法。
請求項２に記載の通信方法。
【請求項5】
前記制御を行うことは、前記ネットワークノードから受信した前記第２のＰＤＣＰ変数を前記第１のＰＤＣＰ変数に適用することをさらに含む
請求項２に記載の通信方法。
請求項２に記載の通信方法。
【請求項6】
前記制御を行うことは、前記ＭＢＳセッションの受信のためのＰＤＣＰエンティティを再確立することを含む
請求項１に記載の通信方法。
請求項１に記載の通信方法。
【請求項7】
前記第１のＰＤＣＰ変数及び前記第２のＰＤＣＰ変数のそれぞれは、ＰＤＣＰシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号（ＨＦＮ）と、前記ＰＤＣＰシーケンス番号と、からなるカウント値である
請求項１に記載の通信方法。
請求項１に記載の通信方法。
【請求項8】
前記第１のＰＤＣＰ変数及び前記第２のＰＤＣＰ変数のそれぞれは、ＰＤＣＰシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号（ＨＦＮ）である
請求項１に記載の通信方法。
請求項１に記載の通信方法。
【請求項9】
前記制御を行うことは、前記第１のＰＤＣＰ変数に初期値をセットすることを含み、
前記初期値をセットすることは、前記ネットワークノードから前記ＭＢＳセッションを介して受信するＰＤＣＰパケットに含まれるＰＤＣＰシーケンス番号を前記初期値の少なくとも一部として用いることを含む
請求項１に記載の通信方法。
前記初期値をセットすることは、前記ネットワークノードから前記ＭＢＳセッションを介して受信するＰＤＣＰパケットに含まれるＰＤＣＰシーケンス番号を前記初期値の少なくとも一部として用いることを含む
請求項１に記載の通信方法。
【請求項10】
前記ユーザ装置が、前記所定時間を計時するためのタイマの設定値を前記ネットワークノードから受信することをさらに有する
請求項１に記載の通信方法。
請求項１に記載の通信方法。
【請求項11】
マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いるユーザ装置であって、
ネットワークノードからのＭＢＳセッションの受信を開始すると、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理する手段と、
前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記ネットワークノードが管理している第２のＰＤＣＰ変数と同期させるための制御を行う手段と、を有する
ユーザ装置。
ネットワークノードからのＭＢＳセッションの受信を開始すると、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理する手段と、
前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記ネットワークノードが管理している第２のＰＤＣＰ変数と同期させるための制御を行う手段と、を有する
ユーザ装置。
【請求項12】
マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いるユーザ装置に、
ネットワークノードからのＭＢＳセッションの受信を開始すると、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理することと、
前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記ネットワークノードが管理している第２のＰＤＣＰ変数と同期させるための制御を行うことと、を実行させる
プログラム。
ネットワークノードからのＭＢＳセッションの受信を開始すると、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理することと、
前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記ネットワークノードが管理している第２のＰＤＣＰ変数と同期させるための制御を行うことと、を実行させる
プログラム。
【請求項13】
マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いるプロセッサであって、
ネットワークノードからのＭＢＳセッションの受信を開始すると、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理することと、
前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記ネットワークノードが管理している第２のＰＤＣＰ変数と同期させるための制御を行うことと、を実行する
プロセッサ。
ネットワークノードからのＭＢＳセッションの受信を開始すると、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理することと、
前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記ネットワークノードが管理している第２のＰＤＣＰ変数と同期させるための制御を行うことと、を実行する
プロセッサ。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、移動通信システムで用いる通信方法、ユーザ装置、プログラム、及びプロセッサに関する。
【背景技術】
【0002】
３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）（登録商標。以下同じ）規格において、第５世代（５Ｇ）の無線アクセス技術であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）の技術仕様が規定されている。ＮＲは、第４世代（４Ｇ）の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。３ＧＰＰにおいて、５Ｇ／ＮＲのマルチキャストブロードキャストサービス（ＭＢＳ）の技術仕様を策定する議論が行われている（例えば、非特許文献１参照）。
【先行技術文献】
【非特許文献】
【0003】
【非特許文献1】３ＧＰＰ寄書：ＲＰ－２０１０３８、“ＷＩＤ ｒｅｖｉｓｉｏｎ： ＮＲ Ｍｕｌｔｉｃａｓｔ ａｎｄ Ｂｒｏａｄｃａｓｔ Ｓｅｒｖｉｃｅｓ”
【発明の概要】
【0004】
５Ｇ／ＮＲのマルチキャストブロードキャストサービスは、４Ｇ／ＬＴＥのマルチキャストブロードキャストサービスよりも改善されたサービスを提供することが望まれる。
【0005】
そこで、本開示は、改善されたマルチキャストブロードキャストサービスを実現可能とする通信方法、ユーザ装置、及び基地局を提供することを目的とする。
【0006】
第１の態様に係る通信方法は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる方法である。前記通信方法は、ユーザ装置が、ＭＢＳセッションのＭＢＳセッション識別子と、前記ＭＢＳセッションがマッピングされたＭＲＢに関する識別子と、前記ＭＢＳセッションに対応するハイパーフレーム番号（ＨＦＮ）と、を含む無線リソース制御（ＲＲＣ）Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを基地局から受信するステップを有する。
【0007】
第２の態様に係るユーザ装置は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いるユーザ装置である。前記ユーザ装置は、ＭＢＳセッションのＭＢＳセッション識別子と、前記ＭＢＳセッションがマッピングされたＭＲＢに関する識別子と、前記ＭＢＳセッションに対応するハイパーフレーム番号（ＨＦＮ）と、を含む無線リソース制御（ＲＲＣ）Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを基地局から受信する受信部を備える。
【0008】
第３の態様に係る基地局は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる基地局である。前記基地局は、ＭＢＳセッションのＭＢＳセッション識別子と、前記ＭＢＳセッションがマッピングされたＭＲＢに関する識別子と、前記ＭＢＳセッションに対応するハイパーフレーム番号（ＨＦＮ）と、を含む無線リソース制御（ＲＲＣ）Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをユーザ装置に送信する送信部を備える。
【0009】
第４の態様に係る通信方法は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる通信方法であって、基地局からのＭＢＳセッションの受信を開始したユーザ装置が、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理するステップと、前記ユーザ装置が、前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記基地局が管理している第２のＰＤＣＰ変数と同期させるための制御を行うステップと、を有する。
【0010】
第５の態様に係るユーザ装置は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いるユーザ装置であって、基地局からのＭＢＳセッションの受信を開始すると、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新される第１のＰＤＣＰ変数を管理する制御部を備える。前記制御部は、前記ＭＢＳセッションの受信が所定時間にわたって途絶したと判定したことに応じて、前記第１のＰＤＣＰ変数を、前記基地局が管理している第２のＰＤＣＰ変数と同期させるための制御を行う。
【0011】
第６の態様に係る基地局は、マルチキャストブロードキャストサービス（ＭＢＳ）をサポートする移動通信システムで用いる基地局であって、ＭＢＳセッションの送信を開始すると、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤにおいて、前記ＭＢＳセッションにおけるＰＤＣＰパケットの送信に応じて更新されるＰＤＣＰ変数を管理する制御部と、前記ＰＤＣＰ変数を確認するための要求をユーザ装置から受信する受信部と、前記要求に応じて、前記ＰＤＣＰ変数を前記ユーザ装置に送信する送信部と、を備える。
【図面の簡単な説明】
【0012】
【図1】実施形態に係る移動通信システムの構成を示す図である。
【図2】実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。
【図3】実施形態に係るｇＮＢ（基地局）の構成を示す図である。
【図4】データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
【図5】シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
【図6】実施形態に係るＭＢＳトラフィック配信の概要を示す図である。
【図7】実施形態に係る配信モードを示す図である。
【図8】実施形態に係るスプリット・マルチキャスト無線ベアラ（ＭＲＢ）を示す図である。
【図9】実施形態に係る移動通信システムの動作シナリオを示す図である。
【図10】実施形態に係るＰＤＣＰ変数の一例を示す図である。
【図11】実施形態に係るＰＤＣＰデータＰＤＵを示す図である。
【図12】実施形態に係るＵＥ（受信側ＰＤＣＰエンティティ）において受信したＰＤＣＰデータＰＤＵのＣＯＵＮＴ値であるＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。
【図13】実施形態に係るＵＥの受信側ＰＤＣＰエンティティの動作を示す図である。
【図14】実施形態に係るＵＥの動作を示す図である。
【図15】実施形態に係る移動通信システムの動作の一例を示す図である。
【図16】実施形態に係る移動通信システムの動作の他の例を示す図である。
【図17】現在の合意に基づくＰＤＣＰ固定型ＰＴＭ／ＰＴＰの切り替えを示す図である。
【発明を実施するための形態】
【0013】
図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【0014】
（移動通信システムの構成）
図１は、本実施形態に係る移動通信システム１の構成を示す図である。移動通信システム１は、３ＧＰＰ規格の第５世代システム（５ＧＳ：５ｔｈ Ｇｅｎｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）に準拠する。以下において、５ＧＳを例に挙げて説明するが、移動通信システムにはＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムが少なくとも部分的に適用されてもよい。また、移動通信システムには、第６世代（６Ｇ）システムが少なくとも部分的に適用されてもよい。
図１は、本実施形態に係る移動通信システム１の構成を示す図である。移動通信システム１は、３ＧＰＰ規格の第５世代システム（５ＧＳ：５ｔｈ Ｇｅｎｅｒａｔｉｏｎ Ｓｙｓｔｅｍ）に準拠する。以下において、５ＧＳを例に挙げて説明するが、移動通信システムにはＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムが少なくとも部分的に適用されてもよい。また、移動通信システムには、第６世代（６Ｇ）システムが少なくとも部分的に適用されてもよい。
【0015】
移動通信システム１は、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ Ｃｏｒｅ Ｎｅｔｗｏｒｋ）２０とを有する。以下において、ＮＧ－ＲＡＮ１０を単にＲＡＮ１０と呼ぶことがある。また、５ＧＣ２０を単にコアネットワーク（ＣＮ）２０と呼ぶことがある。
【0016】
ＵＥ１００は、移動可能な無線通信装置である。ＵＥ１００は、ユーザにより利用される装置であればどのような装置であっても構わない。例えば、ＵＥ１００は、携帯電話端末（スマートフォンを含む）又はタブレット端末、ノートＰＣ、通信モジュール（通信カード又はチップセットを含む）、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置（Ｖｅｈｉｃｌｅ ＵＥ）、飛行体若しくは飛行体に設けられる装置（Ａｅｒｉａｌ ＵＥ）である。
【0017】
ＮＧ－ＲＡＮ１０は、基地局（５Ｇシステムにおいて「ｇＮＢ」と呼ばれる）２００を含む。ｇＮＢ２００は、基地局間インターフェイスであるＸｎインターフェイスを介して相互に接続される。ｇＮＢ２００は、１又は複数のセルを管理する。ｇＮＢ２００は、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｇＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。１つのセルは１つのキャリア周波数（以下、単に「周波数」と呼ぶ）に属する。
【0018】
なお、ｇＮＢがＬＴＥのコアネットワークであるＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）に接続することもできる。ＬＴＥの基地局が５ＧＣに接続することもできる。ＬＴＥの基地局とｇＮＢとが基地局間インターフェイスを介して接続されることもできる。
【0019】
５ＧＣ２０は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）及びＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）３００を含む。ＡＭＦは、ＵＥ１００に対する各種モビリティ制御等を行う。ＡＭＦは、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００のモビリティを管理する。ＵＰＦは、データの転送制御を行う。ＡＭＦ及びＵＰＦは、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してｇＮＢ２００と接続される。
【0020】
図２は、本実施形態に係るＵＥ１００（ユーザ装置）の構成を示す図である。ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。受信部１１０及び送信部１２０は、ｇＮＢ２００との無線通信を行う無線通信部を構成する。
【0021】
受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
【0022】
送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【0023】
制御部１３０は、ＵＥ１００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。制御部１３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
【0024】
図３は、本実施形態に係るｇＮＢ２００（基地局）の構成を示す図である。ｇＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。送信部２１０及び受信部２２０は、ＵＥ１００との無線通信を行う無線通信部を構成する。バックホール通信部２４０は、ＣＮ２０との通信を行うネットワーク通信部を構成する。
【0025】
送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【0026】
受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
【0027】
制御部２３０は、ｇＮＢ２００における各種の制御及び処理を行う。このような処理は、後述の各レイヤの処理を含む。制御部２３０は、少なくとも１つのプロセッサ及び少なくとも１つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。
【0028】
バックホール通信部２４０は、基地局間インターフェイスであるＸｎインターフェイスを介して隣接基地局と接続される。バックホール通信部２４０は、基地局－コアネットワーク間インターフェイスであるＮＧインターフェイスを介してＡＭＦ／ＵＰＦ３００と接続される。なお、ｇＮＢ２００は、ＣＵ（Ｃｅｎｔｒａｌ Ｕｎｉｔ）とＤＵ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）とで構成され（すなわち、機能分割され）、両ユニット間がフロントホールインターフェイスであるＦ１インターフェイスで接続されてもよい。
【0029】
図４は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
【0030】
ユーザプレーンの無線インターフェイスプロトコルは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤと、ＳＤＡＰ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤとを有する。
【0031】
ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００のＰＨＹレイヤとｇＮＢ２００のＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。なお、ＵＥ１００のＰＨＹレイヤは、ｇＮＢ２００から物理下りリンク制御チャネル（ＰＤＣＣＨ）上で送信される下りリンク制御情報（ＤＣＩ）を受信する。具体的には、ＵＥ１００は、無線ネットワーク一時識別子（ＲＮＴＩ）を用いてＰＤＣＣＨのブラインド復号を行い、復号に成功したＤＣＩを自ＵＥ宛てのＤＣＩとして取得する。ｇＮＢ２００から送信されるＤＣＩには、ＲＮＴＩによってスクランブルされたＣＲＣパリティビットが付加されている。
【0032】
ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＵＥ１００のＭＡＣレイヤとｇＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ｇＮＢ２００のＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ））及びＵＥ１００への割当リソースブロックを決定する。
【0033】
ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｇＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
【0034】
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化等を行う。
【0035】
ＳＤＡＰレイヤは、コアネットワークがＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御を行う単位であるＩＰフローとＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）がＱｏＳ制御を行う単位である無線ベアラとのマッピングを行う。なお、ＲＡＮがＥＰＣに接続される場合は、ＳＤＡＰが無くてもよい。
【0036】
図５は、シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
【0037】
制御プレーンの無線インターフェイスのプロトコルスタックは、図４に示したＳＤＡＰレイヤに代えて、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤ及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤを有する。
【0038】
ＵＥ１００のＲＲＣレイヤとｇＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合、ＵＥ１００はＲＲＣアイドル状態にある。ＵＥ１００のＲＲＣとｇＮＢ２００のＲＲＣとの間の接続がサスペンドされている場合、ＵＥ１００はＲＲＣインアクティブ状態にある。
【0039】
ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＵＥ１００のＮＡＳレイヤとＡＭＦ３００ＡのＮＡＳレイヤとの間では、ＮＡＳシグナリングが伝送される。なお、ＵＥ１００は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。また、ＮＡＳレイヤよりも下位のレイヤをＡＳレイヤと呼ぶ。
【0040】
（ＭＢＳの概要）
本実施形態に係るＭＢＳの概要について説明する。ＭＢＳは、ＮＧ－ＲＡＮ１０からＵＥ１００に対してブロードキャスト又はマルチキャスト、すなわち、１対多（ＰＴＭ：Ｐｏｉｎｔ Ｔｏ Ｍｕｌｔｉｐｏｉｎｔ）でのデータ送信を可能とするサービスである。ＭＢＳのユースケース（サービス種別）としては、公安通信、ミッションクリティカル通信、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｅｖｅｒｙｔｈｉｎｇ）通信、ＩＰｖ４又はＩＰｖ６マルチキャスト配信、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｔｅｌｅｖｉｓｉｏｎ）、グループ通信、及びソフトウェア配信等が想定される。
本実施形態に係るＭＢＳの概要について説明する。ＭＢＳは、ＮＧ－ＲＡＮ１０からＵＥ１００に対してブロードキャスト又はマルチキャスト、すなわち、１対多（ＰＴＭ：Ｐｏｉｎｔ Ｔｏ Ｍｕｌｔｉｐｏｉｎｔ）でのデータ送信を可能とするサービスである。ＭＢＳのユースケース（サービス種別）としては、公安通信、ミッションクリティカル通信、Ｖ２Ｘ（Ｖｅｈｉｃｌｅ ｔｏ Ｅｖｅｒｙｔｈｉｎｇ）通信、ＩＰｖ４又はＩＰｖ６マルチキャスト配信、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ ｔｅｌｅｖｉｓｉｏｎ）、グループ通信、及びソフトウェア配信等が想定される。
【0041】
ブロードキャストサービスは、高信頼性のＱｏＳを必要としないアプリケーションのために、特定のサービスエリア内のすべてのＵＥ１００に対してサービスを提供する。ブロードキャストサービスに用いるＭＢＳセッションをブロードキャストセッションと呼ぶ。
【0042】
マルチキャストサービスは、すべてのＵＥ１００に対してではなく、マルチキャストサービス（マルチキャストセッション）に参加しているＵＥ１００のグループに対してサービスを提供する。マルチキャストサービスに用いるＭＢＳセッションをマルチキャストセッションと呼ぶ。マルチキャストサービスによれば、ブロードキャストサービスに比べて、無線効率の高い方法でＵＥ１００のグループに対して同じコンテンツを提供できる。
【0043】
図６は、本実施形態に係るＭＢＳトラフィック配信の概要を示す図である。
【0044】
ＭＢＳトラフィック（ＭＢＳデータ）は、単一のデータソース（アプリケーションサービスプロバイダ）から複数のＵＥに配信される。５Ｇコアネットワークである５Ｇ ＣＮ（５ＧＣ）２０は、アプリケーションサービスプロバイダからＭＢＳデータを受信し、ＭＢＳデータのコピーの作成（Ｒｅｐｌｉｃａｔｉｏｎ）を行って配信する。
【0045】
５ＧＣ２０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信（５ＧＣ Ｓｈａｒｅｄ ＭＢＳ Ｔｒａｆｆｉｃ ｄｅｌｉｖｅｒｙ）及び５ＧＣ個別ＭＢＳトラフィック配信（５ＧＣ Ｉｎｄｉｖｉｄｕａｌ ＭＢＳ Ｔｒａｆｆｉｃ ｄｅｌｉｖｅｒｙ）の２つのマルチキャスト配信方法が可能である。
【0046】
５ＧＣ個別ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、ＵＥ１００ごとのＰＤＵセッションを介してそれらのＭＢＳデータパケットの個別のコピーを個別のＵＥ１００に配信する。したがって、ＵＥ１００ごとに１つのＰＤＵセッションをマルチキャストセッションと関連付ける必要がある。
【0047】
５ＧＣ共有ＭＢＳトラフィック配信方法では、５ＧＣ２０は、ＭＢＳデータパケットの単一コピーを受信し、それらのＭＢＳパケットの単一コピーをＲＡＮノード（すなわち、ｇＮＢ２００）に配信する。ｇＮＢ２００は、ＭＢＳトンネル接続を介してＭＢＳデータパケットを受信し、それらを１つ又は複数のＵＥ１００に配信する。
【0048】
ＲＡＮ（５Ｇ ＲＡＮ）１０の観点からは、５ＧＣ共有ＭＢＳトラフィック配信方法における無線を介したＭＢＳデータの送信には、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ）の２つの配信方法が可能である。ＰＴＰはユニキャストを意味し、ＰＴＭはマルチキャスト及びブロードキャストを意味する。
【0049】
ＰＴＰ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの個別のコピーを無線で個々のＵＥ１００に配信する。他方、ＰＴＭ配信方法では、ｇＮＢ２００は、ＭＢＳデータパケットの単一コピーを無線でＵＥ１００のグループに配信する。ｇＮＢ２００は、１つのＵＥ１００に対するＭＢＳデータの配信方法としてＰＴＭ及びＰＴＰのどちらを用いるかを動的に決定できる。
【0050】
ＰＴＰ配信方法及びＰＴＭ配信方法は主としてユーザプレーンに関するものである。ＭＢＳデータ配信の制御モードとしては、第１配信モード及び第２配信モードの２つの配信モードがある。
【0051】
図７は、本実施形態に係る配信モードを示す図である。
【0052】
第１配信モード（Ｄｅｌｉｖｅｒｙ ｍｏｄｅ １：ＤＭ１）は、ＲＲＣコネクティッド状態のＵＥ１００が利用できる配信モードであって、高ＱｏＳ要件のための配信モードである。第１配信モードは、ＭＢＳセッションのうちマルチキャストセッションに用いられる。但し、第１配信モードがブロードキャストセッションに用いられてもよい。第１配信モードは、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００も利用可能であってもよい。
【0053】
第１配信モードにおけるＭＢＳ受信の設定は、ＵＥ固有（ＵＥ－ｄｅｄｉｃａｔｅｄ）シグナリングにより行われる。例えば、第１配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にユニキャストで送信されるＲＲＣメッセージであるＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（又はＲＲＣ Ｒｅｌｅａｓｅメッセージ）により行われる。
【0054】
ＭＢＳ受信の設定は、ＭＢＳデータを運ぶＭＢＳトラフィックチャネルの設定に関するＭＢＳトラフィックチャネル設定情報（以下、「ＭＴＣＨ設定情報」と呼ぶ）を含む。ＭＴＣＨ設定情報は、ＭＢＳセッションに関するＭＢＳセッション情報と、このＭＢＳセッションに対応するＭＢＳトラフィックチャネルのスケジューリング情報とを含む。ＭＢＳトラフィックチャネルのスケジューリング情報は、ＭＢＳトラフィックチャネルの間欠受信（ＤＲＸ）設定を含んでもよい。間欠受信設定は、オン期間（Ｏｎ Ｄｕｒａｔｉｏｎ：受信期間）を定義するタイマ値（Ｏｎ Ｄｕｒａｔｉｏｎ Ｔｉｍｅｒ）、オン期間を延長するタイマ値（Ｉｎａｃｔｉｖｉｔｙ Ｔｉｍｅｒ）、スケジューリング間隔もしくはＤＲＸサイクル（Ｓｃｈｅｄｕｌｉｎｇ Ｐｅｒｉｏｄ、ＤＲＸ Ｃｙｃｌｅ）、スケジューリングもしくはＤＲＸサイクルの開始サブフレームのオフセット値（Ｓｔａｒｔ Ｏｆｆｓｅｔ、ＤＲＸ Ｃｙｃｌｅ Ｏｆｆｓｅｔ）、オン期間タイマの開始遅延スロット値（Ｓｌｏｔ Ｏｆｆｓｅｔ）、再送時までの最大時間を定義するタイマ値（Ｒｅｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅｒ）、ＨＡＲＱ再送のＤＬ割り当てまでの最小間隔を定義するタイマ値（ＨＡＲＱ ＲＴＴ Ｔｉｍｅｒ）のいずれか一つ以上のパラメータを含んでもよい。
【0055】
なお、ＭＢＳトラフィックチャネルは論理チャネルの一種であって、ＭＴＣＨと呼ばれることがある。ＭＢＳトラフィックチャネルは、トランスポートチャネルの一種である下りリンク共有チャネル（ＤＬ－ＳＣＨ）にマッピングされる。
【0056】
第２配信モード（Ｄｅｌｉｖｅｒｙ ｍｏｄｅ ２：ＤＭ２）は、ＲＲＣコネクティッド状態のＵＥ１００だけではなく、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態のＵＥ１００が利用できる配信モードであって、低ＱｏＳ要件のための配信モードである。第２配信モードは、ＭＢＳセッションのうちブロードキャストセッションに用いられる。但し、第２配信モードは、マルチキャストセッションにも適用可能であってもよい。
【0057】
第２配信モードにおけるＭＢＳ受信の設定は、ブロードキャストシグナリングにより行われる。例えば、第２配信モードにおけるＭＢＳ受信の設定は、ｇＮＢ２００からＵＥ１００にブロードキャストで送信される論理チャネル、例えば、ブロードキャスト制御チャネル（ＢＣＣＨ）及び／又はマルチキャスト制御チャネル（ＭＣＣＨ）により行われる。ＵＥ１００は、例えば、技術仕様で予め規定された専用のＲＮＴＩを用いてＢＣＣＨ及びＭＣＣＨを受信できる。ＢＣＣＨ受信用のＲＮＴＩがＳＩ－ＲＮＴＩであって、ＭＣＣＨ受信用のＲＮＴＩがＭＣＣＨ－ＲＮＴＩであってもよい。
【0058】
第２配信モードにおいて、ＵＥ１００は、次の３つの手順でＭＢＳデータを受信してもよい。第１に、ＵＥ１００は、ｇＮＢ２００からＢＣＣＨ上で伝送されるＳＩＢ（ＭＢＳ－ＳＩＢ）によりＭＣＣＨ設定情報を受信する。第２に、ＵＥ１００は、ＭＣＣＨ設定情報に基づいてｇＮＢ２００からＭＣＣＨを受信する。ＭＣＣＨは、ＭＴＣＨ設定情報を伝送する。第３に、ＵＥ１００は、ＭＴＣＨ設定情報に基づいて、ＭＴＣＨ（ＭＢＳデータ）を受信する。以下において、ＭＴＣＨ設定情報及び／又はＭＣＣＨ設定情報をＭＢＳ受信設定と呼ぶことがある。
【0059】
第１配信モード及び第２配信モードにおいて、ＵＥ１００は、ｇＮＢ２００から割り当てられるグループＲＮＴＩ（Ｇ－ＲＮＴＩ）を用いてＭＴＣＨを受信してもよい。Ｇ－ＲＮＴＩは、ＭＴＣＨ受信用ＲＮＴＩに相当する。Ｇ－ＲＮＴＩは、ＭＢＳ受信設定（ＭＴＣＨ設定情報）に含まれていてもよい。
【0060】
なお、ネットワークは、ＭＢＳセッションごとに異なるＭＢＳサービスを提供できる。ＭＢＳセッションは、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ）、ソーススペシフィックＩＰマルチキャストアドレス（アプリケーション機能やアプリケーションサーバ等のソースユニキャストＩＰアドレスと、宛先アドレスを示すＩＰマルチキャストアドレスとから成る）、セッション識別子、及びＧ－ＲＮＴＩのうち少なくとも１つにより識別される。ＴＭＧＩ、Ｇ－ＲＮＴＩ、ソーススペシフィックＩＰマルチキャストアドレス、及びセッション識別子の少なくとも１つをＭＢＳセッション識別子と呼ぶ。ＴＭＧＩ、ソーススペシフィックＩＰマルチキャストアドレス、セッション識別子、及びＧ－ＲＮＴＩを総括してＭＢＳセッション情報と呼ぶ。
【0061】
図８は、本実施形態に係るスプリット・マルチキャスト無線ベアラ（ＭＲＢ）を示す図である。ＭＲＢは、データ無線ベアラ（ＤＲＢ）の一種であってもよい。スプリットＭＲＢは、上述の第１配信モードで用いられてもよい。
【0062】
ｇＮＢ２００は、ＰＴＰ通信パス及びＰＴＭ通信パスに分離されたＭＲＢをＵＥ１００に設定し得る。これにより、ｇＮＢ２００は、ＵＥ１００に対するＭＢＳデータの送信をＰＴＰ（ＰＴＰ通信パス）とＰＴＭ（ＰＴＭ通信パス）との間で動的に切り替えることができる。或いは、ｇＮＢ２００は、ＰＴＰ（ＰＴＰ通信パス）及びＰＴＭ（ＰＴＭ通信パス）を併用して同一のＭＢＳデータを二重送信することにより信頼性を高めることができる。以下において、ＰＴＰ通信パスをＰＴＰレグと呼び、ＰＴＭ通信パスをＰＴＭレグと呼ぶ。また、各レイヤに相当する機能部をエンティティと呼ぶ。
【0063】
スプリットを終端する所定レイヤは、ＭＡＣレイヤ（ＨＡＲＱ）、ＲＬＣレイヤ、ＰＤＣＰレイヤ、又はＳＤＡＰレイヤである。以下において、スプリットを終端する所定レイヤがＰＤＣＰレイヤである一例について主として説明するが、所定レイヤは、ＭＡＣレイヤ（ＨＡＲＱ）、ＲＬＣレイヤ、又はＳＤＡＰレイヤであってもよい。
【0064】
ｇＮＢ２００のＰＤＣＰエンティティ及びＵＥ１００のＰＤＣＰエンティティのそれぞれは、ＭＢＳに用いるベアラ（データ無線ベアラ）であるＭＲＢをＰＴＰレグ及びＰＴＭレグに分離する。なお、ＰＤＣＰエンティティはベアラごとに設けられる。
【0065】
ｇＮＢ２００及びＵＥ１００のそれぞれは、レグごとに設けられる２つのＲＬＣエンティティと、１つのＭＡＣエンティティと、１つのＰＨＹエンティティとを有する。ＰＨＹエンティティは、レグごとに設けられてもよい。なお、ＵＥ１００が２つのｇＮＢ２００との通信を行う二重接続（Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）の場合、ＵＥ１００が２つのＭＡＣエンティティを有していてもよい。
【0066】
ＰＨＹエンティティは、ＵＥ１００と１対１で割り当てられるセルＲＮＴＩ（Ｃ－ＲＮＴＩ：Ｃｅｌｌ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を用いて、ＰＴＰレグのデータを送受信する。ＰＨＹエンティティは、ＭＢＳセッションと１対１で割り当てられるＧ－ＲＮＴＩを用いて、ＰＴＭレグのデータを送受信する。Ｃ－ＲＮＴＩはＵＥ１００ごとに異なるが、Ｇ－ＲＮＴＩは１つのＭＢＳセッションを受信する複数のＵＥ１００で共通のＲＮＴＩである。
【0067】
ｇＮＢ２００からＵＥ１００に対してＰＴＭレグを用いてＭＢＳデータのＰＴＭ送信（マルチキャスト又はブロードキャスト）を行うためには、ｇＮＢ２００からＵＥ１００にスプリットＭＲＢが設定されており、且つ、ＰＴＭレグがアクティブ化（ａｃｔｉｖａｔｉｏｎ）されている必要がある。言い換えると、ｇＮＢ２００は、ＵＥ１００にスプリットＭＲＢが設定されていても、ＰＴＭレグが非アクティブ（ｄｅａｃｔｉｖａｔｉｏｎ）状態にある場合は、このＰＴＭレグを用いてＭＢＳデータのＰＴＭ送信を行うことができない。
【0068】
また、ｇＮＢ２００及びＵＥ１００がＰＴＰレグを用いてＭＢＳデータのＰＴＰ送信（ユニキャスト）を行うためには、ｇＮＢ２００からＵＥ１００にスプリットＭＲＢが設定されており、且つ、ＰＴＰレグがアクティブ化されている必要がある。言い換えると、ｇＮＢ２００は、ＵＥ１００にスプリットＭＲＢが設定されていても、ＰＴＰレグが非アクティブ状態にある場合は、このＰＴＰレグを用いてＭＢＳデータのＰＴＰ送信を行うことができない。
【0069】
ＵＥ１００は、ＰＴＭレグがアクティブ化された状態において、ＭＢＳセッションと対応付けられたＧ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタする（すなわち、Ｇ－ＲＮＴＩを用いてＰＤＣＣＨのブラインドデコーディングを行う）。ＵＥ１００は、当該ＭＢＳセッションのスケジューリング機会にのみ当該ＰＤＣＣＨをモニタしてもよい。
【0070】
ＵＥ１００は、ＰＴＭレグが非アクティブ化された状態において、ＭＢＳセッションと対応付けられたＧ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタしない（すなわち、Ｇ－ＲＮＴＩを用いたＰＤＣＣＨのブラインドデコーディングを行わない）。
【0071】
ＵＥ１００は、ＰＴＰレグがアクティブ化された状態において、Ｃ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタする。ＵＥ１００は、ＰＴＰレグにおける間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ）が設定されている場合、設定されたオン有効期間（ＯｎＤｕｒａｔｉｏｎ）においてＰＤＣＣＨをモニタする。ＵＥ１００は、ＭＢＳセッションと紐づいたセル（周波数）が指定されている場合、当該セルが非アクティブ化されていても、当該セルのＰＤＣＣＨをモニタしてもよい。
【0072】
ＵＥ１００は、ＰＴＰレグが非アクティブ化された状態において、ＭＢＳデータ以外の通常のユニキャスト下りリンク送信に備えて、Ｃ－ＲＮＴＩが適用されたＰＤＣＣＨをモニタしてもよい。但し、ＵＥ１００は、ＭＢＳセッションと紐づいたセル（周波数）が指定されている場合、当該ＭＢＳセッションについて当該ＰＤＣＣＨをモニタしなくてもよい。
【0073】
なお、ｇＮＢ２００のＲＲＣエンティティがＵＥ１００のＲＲＣエンティティに対して送信するＲＲＣメッセージ（例えば、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）により、上述のようなスプリットＭＲＢが設定されるものとする。
【0074】
（移動通信システムの動作）
図９は、本実施形態に係る移動通信システム１の動作シナリオを示す図である。
図９は、本実施形態に係る移動通信システム１の動作シナリオを示す図である。
【0075】
ｇＮＢ２００は、あるＭＢＳセッションのＭＢＳデータをＰＴＭ（マルチキャスト又はブロードキャスト）で複数のＵＥ１００（図９の例では、ＵＥ１００ａ乃至ＵＥ１００ｃ）に送信する。各ＵＥ１００のＲＲＣ状態はどのような状態（ＲＲＣコネクティッド状態、ＲＲＣアイドル状態、ＲＲＣインアクティブ状態）であってもよい。ＭＢＳ配信のモードは、第１配信モード又は第２配信モードであってもよい。第１配信モードでのＭＢＳ配信は、ＰＴＭレグを用いたものであってもよい。
【0076】
ｇＮＢ２００は、ＰＤＣＰレイヤにおいて、当該ＭＢＳセッションと対応付けられたＰＤＣＰエンティティ２０１（具体的には、当該ＭＢＳセッションに属するマルチキャスト無線ベアラ（ＭＲＢ）と対応付けられた送信側ＰＤＣＰエンティティ）を有する。ＰＤＣＰエンティティ２０１は、ＭＢＳセッションの送信を開始すると、当該ＭＢＳセッションにおけるＰＤＣＰパケットの送信に応じて更新されるＰＤＣＰ変数を管理する。
【0077】
各ＵＥ１００は、ＰＤＣＰレイヤにおいて、当該ＭＢＳセッションと対応付けられたＰＤＣＰエンティティ１０１（具体的には、当該ＭＢＳセッションに属するＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ）を有する。各ＰＤＣＰエンティティ１０１（図１０の例では、ＰＤＣＰエンティティ１０１ａ乃至ＰＤＣＰエンティティ１０１ｂ）は、ＭＢＳセッションの送信を開始すると、当該ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新されるＰＤＣＰ変数を管理する。
【0078】
図１０に示すように、ＰＤＣＰ変数は、ＰＤＣＰシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号（ＨＦＮ）と、ＰＤＣＰシーケンス番号（ＰＤＣＰ ＳＮ）と、からなるカウント値（ＣＯＵＮＴ値）であってもよい。例えば、ＣＯＵＮＴ値は３２ビットのビット長を有し、ＰＤＣＰ ＳＮは１２ビット又は１８ビットのビット長（ＳＮ＿ｌｅｎｇｔｈ）を有し、ＨＦＮはＣＯＵＮＴ値のビット長からＰＤＣＰ ＳＮのビット長を減じたビット長を有する。ＰＤＣＰ ＳＮのビット長は、ＲＲＣシグナリングにより設定されてもよい。なお、用語「ＰＤＣＰ変数」は、ＣＯＵＮＴ値を指す場合に限らず、ＰＤＣＰレイヤで扱う各種の変数（ＨＦＮ又はＰＤＣＰ ＳＮ等）を指す用語としても用いられる。
【0079】
図１１は、ＭＢＳデータを構成するＰＤＣＰパケット、具体的には、ＰＤＣＰデータＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）を示す図である。図１１に示すように、ＰＤＣＰデータＰＤＵは、ＰＤＣＰ ＳＮと、データと、ＭＡＣ－Ｉとを有する。ＰＤＣＰ ＳＮは、ＰＤＣＰデータＰＤＵに順次付与されるシーケンス番号である。データは、ＰＤＣＰ ＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）に相当する。ＭＡＣ－Ｉは、メッセージ認証コードに相当する。ＰＤＣＰデータＰＤＵは、ＭＡＣ－Ｉを有していない場合がある。このように、ＰＤＣＰデータＰＤＵは、ＰＤＣＰ ＳＮを有するものの、ＨＦＮを有していない。そのため、ｇＮＢ２００及びＵＥ１００のそれぞれは、ＰＤＣＰデータＰＤＵの送受信に応じてＨＦＮを更新、具体的には、ＰＤＣＰシーケンス番号が一周する度にカウントアップする必要がある。
【0080】
図１２は、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）において受信したＰＤＣＰデータＰＤＵのＣＯＵＮＴ値であるＲＣＶＤ＿ＣＯＵＮＴを特定する動作を示す図である。ここで、受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮをＲＣＶＤ＿ＳＮと呼ぶ。
【0081】
第１に、
ＲＣＶＤ＿ＳＮ＜ＳＮ（ＲＸ＿ＤＥＬＩＶ）－Ｗｉｎｄｏｗ＿Ｓｉｚｅ
である場合、
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）＋１
である。ここで、ＲＸ＿ＤＥＬＩＶは、受信待ちであって、未だ上位レイヤに提供していないＰＤＣＰ ＳＤＵのうち最も古いものを表す変数である。ＲＸ＿ＤＥＬＩＶの初期値はゼロである。Ｗｉｎｄｏｗ＿Ｓｉｚｅは、リオーダリングウィンドウのサイズを示す定数である。
ＲＣＶＤ＿ＳＮ＜ＳＮ（ＲＸ＿ＤＥＬＩＶ）－Ｗｉｎｄｏｗ＿Ｓｉｚｅ
である場合、
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）＋１
である。ここで、ＲＸ＿ＤＥＬＩＶは、受信待ちであって、未だ上位レイヤに提供していないＰＤＣＰ ＳＤＵのうち最も古いものを表す変数である。ＲＸ＿ＤＥＬＩＶの初期値はゼロである。Ｗｉｎｄｏｗ＿Ｓｉｚｅは、リオーダリングウィンドウのサイズを示す定数である。
【0082】
第２に、
ＲＣＶＤ＿ＳＮ≧ＳＮ（ＲＸ＿ＤＥＬＩＶ）＋Ｗｉｎｄｏｗ＿Ｓｉｚｅ
である場合、
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）－１
である。
ＲＣＶＤ＿ＳＮ≧ＳＮ（ＲＸ＿ＤＥＬＩＶ）＋Ｗｉｎｄｏｗ＿Ｓｉｚｅ
である場合、
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）－１
である。
【0083】
第３に、上記のいずれの条件も満たされない場合、
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）
である。
ＲＣＶＤ＿ＨＦＮ＝ＨＦＮ（ＲＸ＿ＤＥＬＩＶ）
である。
【0084】
そして、
ＲＣＶＤ＿ＣＯＵＮＴ＝［ＲＣＶＤ＿ＨＦＮ，ＲＣＶＤ＿ＳＮ］
にセットされる。
ＲＣＶＤ＿ＣＯＵＮＴ＝［ＲＣＶＤ＿ＨＦＮ，ＲＣＶＤ＿ＳＮ］
にセットされる。
【0085】
図１３は、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１の動作を示す図である。
【0086】
まず、受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰ ＰＤＵを受信すると、当該ＰＤＣＰ ＰＤＵに対して、カウント値（ＲＣＶＤ＿ＣＯＵＮＴ）を用いたセキュリティ処理（具体的には、ｄｅｃｉｐｈｅｒｉｎｇ／ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎ）を行い（ステップＳ１２）、ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎに失敗した場合（ステップＳ１２：Ｙｅｓ）、上位レイヤにｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎ失敗を通知するとともに当該ＰＤＣＰ ＰＤＵを破棄する（ステップＳ１３）。
【0087】
受信側ＰＤＣＰエンティティ１０１は、ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎに成功した場合（ステップＳ１２：Ｎｏ）、カウント値（ＲＣＶＤ＿ＣＯＵＮＴ）がＲＸ＿ＤＥＬＩＶよりも小さい場合（ステップＳ１４：Ｙｅｓ）、又は、ＲＣＶＤ＿ＣＯＵＮＴが受信済みである場合（ステップＳ１６：Ｙｅｓ）、当該ＰＤＣＰ ＰＤＵを破棄する（ステップＳ１５）。
【0088】
次に、受信側ＰＤＣＰエンティティ１０１は、破棄しなかったＰＤＣＰ ＰＤＵを受信バッファに格納し（ステップＳ１７）、「ＲＣＶＤ＿ＣＯＵＮＴ≧ＲＸ＿ＮＥＸＴ」である場合（ステップＳ１８：Ｙｅｓ）、ＲＸ＿ＮＥＸＴ＝ＲＣＶＤ＿ＣＯＵＮＴ＋１に更新する（ステップＳ１９）。ここで、ＲＸ＿ＮＥＸＴは、次に受信することが期待されるＰＤＣＰ ＳＤＵのカウント値（ＲＣＶＤ＿ＣＯＵＮＴ）を示す変数である。ＲＸ＿ＮＥＸＴの初期値はゼロである。Ｏｕｔ－ｏｆ－ｏｒｄｅｒ ｄｅｌｉｖｅｒｙが設定（Ｃｏｎｆｉｇｕｒｅｄ）されている場合（ステップＳ２０：Ｙｅｓ）、受信側ＰＤＣＰエンティティ１０１は、当該ＰＤＣＰ ＰＤＵをヘッダ逆圧縮後、上位レイヤに渡す（ステップＳ２１）。具体的には、受信側ＰＤＣＰエンティティ１０１は、ＲＲＣで“ｏｕｔＯｆＯｒｄｅｒＤｅｌｉｖｅｒｙ”が設定されている場合に、Ｓ２１の動作を行う。Ｏｕｔ ｏｆ ｏｒｄｅｒ ｄｅｌｉｖｅｒｙは、順序制御を行わずに上位レイヤにパケットを渡す動作である。よって、ステップＳ２１のように、パケットを受信してバッファに格納したら直ぐに上位レイヤに当該パケットを渡す。なお、ステップＳ２０が”Ｎｏ”の場合、順序制御を行うことになる。
【0089】
受信側ＰＤＣＰエンティティ１０１は、「ＲＣＶＤ＿ＣＯＵＮＴ＝ＲＸ＿ＤＥＬＩＶ」である場合（ステップＳ２２：Ｙｅｓ）、ＣＯＵＮＴ＝ＲＸ＿ＤＥＬＩＶから始まる連続するＣＯＵＮＴの全てのＰＤＣＰ ＳＤＵをヘッダ逆圧縮後、上位レイヤに渡し（ステップＳ２３）、ＲＸ＿ＤＥＬＩＶを、上位レイヤに渡していない最初の（最も若い）ＣＯＵＮＴ値に更新する（ステップＳ２４）。
【0090】
受信側ＰＤＣＰエンティティ１０１は、Ｔ-Ｒｅｏｒｄｅｒｉｎｇが動作中であって、「ＲＸ＿ＤＥＬＩＶ≧ＲＸ＿ＲＥＯＲＤ」である場合（ステップＳ２５：Ｙｅｓ）、Ｔ－Ｒｅｏｒｄｅｒｉｎｇをｓｔｏｐ及びｒｅｓｅｔする（ステップＳ２６）。ここで、Ｔ－Ｒｅｏｒｄｅｒｉｎｇは、ＰＤＣＰデータＰＤＵの欠損を検出するために用いるタイマである。ＲＸ＿ＲＥＯＲＤは、Ｔ－ＲｅｏｒｄｅｒｉｎｇをトリガしたＰＤＣＰデータＰＤＵに関連付けられたＣＯＵＮＴ値に続くＣＯＵＮＴ値を示す変数である。
【0091】
受信側ＰＤＣＰエンティティ１０１は、Ｔ-Ｒｅｏｒｄｅｒｉｎｇが停止中であって、「ＲＸ＿ＤＥＬＩＶ＜ＲＸ＿ＲＥＯＲＤ」である場合（ステップＳ２７：Ｙｅｓ）、ＲＸ＿ＲＥＯＲＤ＝ＲＸ＿ＮＥＸＴに更新するとともにＴ-Ｒｅｏｒｄｅｒｉｎｇを始動（ｓｔａｒｔ）する。
【0092】
上述のように、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ｇＮＢ２００からのＰＤＣＰパケット（ＰＤＣＰデータＰＤＵ）の受信に応じてＰＤＣＰ変数を更新する。具体的には、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰ変数の初期値をゼロに設定し、ｇＮＢ２００からのパケット受信に応じてＰＤＣＰ変数を更新（インクリメント、カウントアップ）していく。
【0093】
また、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰパケット（ＰＤＣＰデータＰＤＵ）について、Ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎが失敗した場合、又はＲＣＶＤ＿ＣＯＵＮＴ＜ＲＸ＿ＤＥＬＩＶの場合（既に受信済みであった場合等）、又はＲＣＶＤ＿ＣＯＵＮＴが既に受信済みであった場合等において、当該ＰＤＣＰパケットを破棄する。
【0094】
例えば、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、無線状況が悪い等の理由で一定期間以上パケットを受信できず、その後パケットを受信し始めた時に、正常受信できなくなることがある。具体的には、ＲＣＶＤ＿ＳＮ＞＞ＳＮ（ＲＸ＿ＤＥＬＩＶ）となった場合、過去パケットと見なされる虞がある。
【0095】
このような問題は、主として、ｇＮＢ２００及びＵＥ１００でＨＦＮが同期外れになることに起因する。ＵＥ１００がＭＢＳ受信（ＰＴＭ受信）をある一定期間受信できなかった場合、このような同期外れが発生し得る。とりわけ、ＰＴＭは、複数ＵＥが受信すること及びレイヤ２フィードバックが無いことから、このような状況が発生し易い傾向にある。その結果、ＵＥ１００は、ＰＤＣＰレイヤにおける受信ウィンドウ制御及びパケット並び替え（Ｒｅｏｒｄｅｒｉｎｇ）等を適切に行うことができず、ＭＢＳ受信を適切に継続することができなくなる懸念がある。本実施形態は、このような問題を解決しようとする実施形態である。
【0096】
【0097】
ステップＳ１において、ＵＥ１００は、ｇＮＢ２００からのＭＢＳセッションの受信（ＰＴＭ受信）を開始する。ＭＢＳセッションは、マルチキャストセッション又はブロードキャストセッションであってもよい。
【0098】
ステップＳ２において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＭＢＳセッションにおけるＰＤＣＰパケットの受信に応じて更新されるＰＤＣＰ変数（以下、「第１のＰＤＣＰ変数」と呼ぶ）を管理する。
【0099】
ステップＳ３において、ＵＥ１００は、ＭＢＳセッションの受信が所定時間にわたって途絶したか否かを判定する。ＭＢＳセッションの受信が所定時間にわたって途絶していない場合（ステップＳ３：Ｎｏ）、ステップＳ２に処理が戻る。
【0100】
ＭＢＳセッションの受信が所定時間にわたって途絶したと判定された場合（ステップＳ３：Ｙｅｓ）、ステップＳ４において、ＵＥ１００は、第１のＰＤＣＰ変数を、ｇＮＢ２００が管理しているＰＤＣＰ変数（以下、「第２のＰＤＣＰ変数」と呼ぶ）と同期させるための制御を行う。
【0101】
このように、ｇＮＢ２００及びＵＥ１００でＨＦＮが同期外れになったとみなすことができる状況下において、ＵＥ１００は、自身が管理する第１のＰＤＣＰ変数を、ｇＮＢ２００が管理している第２のＰＤＣＰ変数と同期させるための制御を行うことにより、ＭＢＳ受信を適切に継続することが可能である。
【0102】
ステップＳ４は、第２のＰＤＣＰ変数を確認するための要求をｇＮＢ２００に送信するステップと、当該要求に応じてｇＮＢ２００から送信される第２のＰＤＣＰ変数を受信するステップと、を含んでもよい。ＵＥ１００は、ｇＮＢ２００から受信した第２のＰＤＣＰ変数を第１のＰＤＣＰ変数に適用してもよい。これにより、ＵＥ１００は、自身が管理する第１のＰＤＣＰ変数を、ｇＮＢ２００が管理している第２のＰＤＣＰ変数と同期させることが可能になる。
【0103】
ここで、ＵＥ１００は、第２のＰＤＣＰ変数を確認するための要求と、当該要求と対応付けられた識別子と、を含むＲＲＣメッセージをｇＮＢ２００に送信してもよい。当該識別子は、ＭＢＳセッションのＭＢＳセッション識別子及びＭＢＳセッションがマッピングされたＭＲＢに関する識別子（例えば、ＭＲＢ識別子、ＭＴＣＨ識別子、又はＱｏＳフロー識別子等）の少なくとも一方を含んでもよい。当該ＲＲＣメッセージは、例えば、ＭＢＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎメッセージ又はＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージであってもよい。
【0104】
ＵＥ１００は、第２のＰＤＣＰ変数と、当該第２のＰＤＣＰ変数と対応付けられた識別子と、を含むメッセージをｇＮＢ２００から受信してもよい。当該識別子は、上述のＲＲＣメッセージに含まれる識別子と同様な識別子である。但し、当該メッセージは、当該第２のＰＤＣＰ変数と対応付けられた識別子を含まなくてもよい。当該メッセージは、ＵＥ専用シグナリング（例えば、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ又はＭＡＣ制御エレメント（ＭＡＣ ＣＥ））であってもよい。また、当該メッセージは、ブロードキャストシグナリング（例えば、ＭＢＳ－ＳＩＢ又はＭＣＣＨ）であってもよい。
【0105】
或いは、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、第２のＰＤＣＰ変数を確認するための要求を含むＰＤＣＰ制御ＰＤＵをｇＮＢ２００に送信してもよい。ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、当該ＰＤＣＰ制御ＰＤＵの受信に応じて、第２のＰＤＣＰ変数を含むＰＤＣＰ制御ＰＤＵをＵＥ１００の受信側ＰＤＣＰエンティティ１０１に送信してもよい。
【0106】
ステップＳ４は、ＭＢＳセッションの受信のためのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）を再確立するステップを含んでもよい。これにより、ｇＮＢ２００及びＵＥ１００でＨＦＮが同期外れになったとみなすことができる状況下において、ＵＥ１００が管理している第１のＰＤＣＰ変数を初期化（リセット）することができる。
【0107】
ステップＳ４は、第１のＰＤＣＰ変数に初期値をセットするステップを含んでもよい。初期値をセットするステップは、ｇＮＢ２００からＭＢＳセッションを介して受信するＰＤＣＰパケット（ＰＤＣＰデータＰＤＵ）に含まれるＰＤＣＰ ＳＮを当該初期値の少なくとも一部として用いるステップを含んでもよい。これにより、最新のＰＤＣＰ ＳＮを第１のＰＤＣＰ変数の少なくとも一部として適用できる。
【0108】
図１５は、本実施形態に係る移動通信システム１の動作の一例を示す図である。
【0109】
ステップＳ１０１において、ｇＮＢ２００は、所定時間を計時するためのタイマの設定値をＵＥ１００に送信してもよい。ＵＥ１００は、タイマ設定値を受信する。タイマ設定値は、ＵＥ専用シグナリング（例えば、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）でＵＥ１００に通知されてもよい。また、当該タイマ設定値は、ブロードキャストシグナリング（例えば、ＭＢＳ－ＳＩＢ又はＭＣＣＨ）でＵＥ１００に通知されてもよい。但し、タイマ設定値は、ＵＥ１００の実装依存で決定してもよい。タイマ設定値は、ＭＢＳセッション毎、ＱｏＳフロー毎、又はＧ－ＲＮＴＩ毎に設定できてもよい。
【0110】
ステップＳ１０２において、ｇＮＢ２００は、あるＭＢＳセッションのＭＢＳデータをＰＴＭ（マルチキャスト又はブロードキャスト）で複数のＵＥ１００（図９の例では、ＵＥ１００ａ乃至ＵＥ１００ｃ）に送信することを開始する。ＵＥ１００は、ＭＢＳデータの受信を開始し、自身のＰＤＣＰ変数（第１のＰＤＣＰ変数）を更新していく。
【0111】
ステップＳ１０３において、ＵＥ１００は、ＭＢＳ受信（ＰＴＭ受信）に失敗したか否かを判定する。例えば、ＵＥ１００は、下位レイヤでＭＢＳデータの復号に失敗した場合、ＭＢＳ受信に失敗したと判定する。ＭＢＳ受信に失敗したと判定した場合（ステップＳ１０３：Ｙｅｓ）、ステップＳ１０４において、ＵＥ１００は、上述のタイマ設定値がセットされたタイマを始動する。
【0112】
ステップＳ１０５において、ＵＥ１００は、ＭＢＳ受信（ＰＴＭ受信）に成功したか否かを判定する。例えば、ＵＥ１００は、下位レイヤでＭＢＳデータの復号に成功した場合、ＭＢＳ受信に成功したと判定する。ＭＢＳ受信に成功したと判定した場合（ステップＳ１０５：Ｙｅｓ）、ステップＳ１０６において、ＵＥ１００は、タイマを停止する。ＭＢＳ受信に成功しない場合（ステップＳ１０５：Ｎｏ）、ＵＥ１００は、タイマを停止しない。
【0113】
ステップＳ１０７において、ＵＥ１００は、タイマが満了したか否かを判定する。すなわち、ＵＥ１００は、ＭＢＳ受信が所定時間（タイマ設定値で設定された時間）にわたって途絶したか否かを判定する。タイマが満了していない場合（ステップＳ１０７：Ｎｏ）、ＵＥ１００は、処理をステップＳ１０５に戻す。一方、タイマが満了した場合（ステップＳ１０７：Ｙｅｓ）、ＵＥ１００は、ステップＳ１０８乃至Ｓ１１２のうち少なくとも１つの処理を行う。
【0114】
ステップＳ１０８において、ＵＥ１００は、ＭＢＳ受信のためのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）を再確立してもよい。ＵＥ１００は、このようなＰＤＣＰ再確立により、自動的に第１のＰＤＣＰ変数（例えば、ＲＸ＿ＤＥＬＩＶ）に初期値が代入されるものとする。ここで、ＵＥ１００において、ＲＲＣレイヤがＰＤＣＰレイヤ（受信側ＰＤＣＰエンティティ１０１）にＰＤＣＰ再確立の指示を行ってもよい。また、ＰＤＣＰレイヤ（受信側ＰＤＣＰエンティティ１０１）が自動的にＰＤＣＰ再確立を行ってもよい。ＰＤＣＰレイヤ（受信側ＰＤＣＰエンティティ１０１）は、自動的にＰＤＣＰ再確立を行った場合、その旨をＲＲＣレイヤに通知してもよい。
【0115】
ステップＳ１０９において、ＵＥ１００は、ｇＮＢ２００に対して、ｇＮＢ２００が管理している現在のＣＯＵＮＴ値（第２のＰＤＣＰ変数）の確認要求（問い合わせ）を行う。ｇＮＢ２００は、当該確認要求（問い合わせ）を受信する。
【0116】
ステップＳ１１０において、ｇＮＢ２００は、ＵＥ１００からの確認要求（問い合わせ）の受信に応じて、ｇＮＢ２００が管理しているＣＯＵＮＴ値（第２のＰＤＣＰ変数）をＵＥ１００に送信する。ＵＥ１００は、ｇＮＢ２００が管理しているＣＯＵＮＴ値（第２のＰＤＣＰ変数）を受信する。
【0117】
ステップＳ１１１において、ＵＥ１００は、ｇＮＢ２００から受信したＣＯＵＮＴ値（第２のＰＤＣＰ変数）を、ＵＥ１００が管理するＣＯＵＮＴ値として適用する。例えば、ＵＥ１００は、ｇＮＢ２００から受信したＣＯＵＮＴ値（第２のＰＤＣＰ変数）を、ＭＢＳ受信のためのＰＤＣＰエンティティ（受信側ＰＤＣＰエンティティ１０１）の第１のＰＤＣＰ変数（例えば、ＲＸ＿ＤＥＬＩＶ）にセットする。
【0118】
ステップＳ１１２において、ＵＥ１００は、ステップＳ１１１でセットした第１のＰＤＣＰ変数を用いて、当該ＭＢＳセッションの受信を試みる。
【0119】
上述のタイマの変更例として、次のようなタイマ動作としてもよい。具体的には、ＵＥ１００は、ステップＳ１０４においてタイマを始動していたが、当該タイマはＳ１０２において、ＭＢＳデータを正常受信した時に、始動（又はリセット及び再始動）してもよい。ＵＥ１００は、当該タイマが満了した場合、Ｓ１０７と同様に、ＭＢＳ受信が所定時間にわたって途絶したことを検知できる。すなわち、ＵＥ１００は、ＭＢＳデータを正常受信する度にタイマを始動（又はリセット及び再始動）し、当該タイマが満了した場合にＭＢＳ受信が所定時間にわたって途絶したと判定してもよい。
【0120】
【0121】
ステップＳ２０１乃至Ｓ２０８の動作は、図１５のステップＳ１０１乃至Ｓ１０８の動作と同様である。
【0122】
ステップＳ２０９において、ＵＥ１００は、ｇＮＢ２００に対して、ｇＮＢ２００が管理している現在のＨＦＮ（第２のＰＤＣＰ変数）の確認要求（問い合わせ）を行ってもよい。ｇＮＢ２００は、当該確認要求（問い合わせ）を受信する。
【0123】
ステップＳ２１０において、ｇＮＢ２００は、ＵＥ１００からの確認要求（問い合わせ）の受信に応じて、ｇＮＢ２００が管理しているＨＦＮ（第２のＰＤＣＰ変数）をＵＥ１００に送信してもよい。ＵＥ１００は、ｇＮＢ２００が管理しているＨＦＮ（第２のＰＤＣＰ変数）を受信する。
【0124】
或いは、ＵＥ１００は、ｇＮＢ２００が管理しているＨＦＮ（第２のＰＤＣＰ変数）を類推してもよい。例えば、ＵＥ１００は、ＨＦＮ候補を生成し、各ＨＦＮ候補を用いてｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎを試み、ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎに成功したＨＦＮ候補を、ｇＮＢ２００が管理しているＨＦＮ（第２のＰＤＣＰ変数）として決定してもよい。
【0125】
ステップＳ２１１において、ＵＥ１００は、自身が管理しているＣＯＵＮＴ値（第１のＰＤＣＰ変数）のＨＦＮ部、例えば、ＲＸ＿ＤＥＬＩＶのＨＦＮ部に、ステップＳ２１０で受信したＨＦＮ（第２のＰＤＣＰ変数）又は自身で決定したＨＦＮ（第２のＰＤＣＰ変数）をセットする。ＵＥ１００は、ＲＲＣ再確立（ステップＳ２０８）の後、自身が管理しているＣＯＵＮＴ値（第１のＰＤＣＰ変数）のＨＦＮ部の初期値として、ステップＳ２１０で受信したＨＦＮ（第２のＰＤＣＰ変数）又は自身で決定したＨＦＮ（第２のＰＤＣＰ変数）をセットしてもよい。
【0126】
ステップＳ２１２において、ＵＥ１００は、ｇＮＢ２００からのＭＢＳセッション（データ）を受信する。
【0127】
ステップＳ２１３において、ＵＥ１００は、ステップＳ２１２でｇＮＢ２００から最初に受信したＰＤＣＰパケット（ＰＤＣＰデータＰＤＵ）のＰＤＣＰ ＳＮを取得する。そして、ＵＥ１００は、自身が管理しているＣＯＵＮＴ値（第１のＰＤＣＰ変数）のＰＤＣＰ ＳＮ部、例えば、ＲＸ＿ＤＥＬＩＶのＰＤＣＰ ＳＮ部に、最初に受信したＰＤＣＰパケットから取得したＰＤＣＰ ＳＮをセットする。ＵＥ１００は、ＲＲＣ再確立（ステップＳ２０８）の後、自身が管理しているＣＯＵＮＴ値（第１のＰＤＣＰ変数）のＰＤＣＰ ＳＮ部の初期値として、最初に受信したＰＤＣＰパケットから取得したＰＤＣＰ ＳＮをセットしてもよい。
【0128】
（その他の実施形態）
上述の実施形態において、無線状態の悪化によりＵＥ１００がＰＴＭを一定期間受信できなかったシナリオを主として想定していた。しかしながら、ｇＮＢ２００は、意図的に（送信するデータが無いなどの理由で）送信を一定期間止める場合も想定される。そのため、上述の実施形態のように、タイマを用いてＭＢＳ受信が所定時間に渡って途絶したことを検知する例において、ｇＮＢ２００が意図的に（送信すべきデータが無い等の理由により）ＭＢＳ送信を所定時間に渡って中断した場合にも、ＵＥ１００はＭＢＳ受信が途絶したと判定してしまうため、本来不要な処理を実行してしまう虞がある。そこで、ｇＮＢ２００は意図的にＭＢＳ送信を停止する場合、ＵＥ１００に当該タイマの停止指示を送信してもよい。ＵＥ１００は、当該停止指示を受信した場合、当該タイマを停止する。ｇＮＢ２００はＭＢＳ送信を再開する時に、ＵＥ１００に当該タイマの再開指示を送信してもよい。ＵＥ１００は当該再開指示を受信した場合、当該タイマを再開する。再開時、当該タイマはリセットしてもよいし（つまり０にセットする）、リセットしなくてもよい（つまり停止時の値から再開してもよい）。もしくは、ｇＮＢ２００は、ＭＢＳ送信を再開する時に、前記再開指示を送信せずに、ＭＢＳデータの送信を再開してもよい。ＵＥ１００はＭＢＳデータを受信した場合、ｇＮＢ２００がＭＢＳ送信を再開したと見なし、当該タイマを再開する。
上述の実施形態において、無線状態の悪化によりＵＥ１００がＰＴＭを一定期間受信できなかったシナリオを主として想定していた。しかしながら、ｇＮＢ２００は、意図的に（送信するデータが無いなどの理由で）送信を一定期間止める場合も想定される。そのため、上述の実施形態のように、タイマを用いてＭＢＳ受信が所定時間に渡って途絶したことを検知する例において、ｇＮＢ２００が意図的に（送信すべきデータが無い等の理由により）ＭＢＳ送信を所定時間に渡って中断した場合にも、ＵＥ１００はＭＢＳ受信が途絶したと判定してしまうため、本来不要な処理を実行してしまう虞がある。そこで、ｇＮＢ２００は意図的にＭＢＳ送信を停止する場合、ＵＥ１００に当該タイマの停止指示を送信してもよい。ＵＥ１００は、当該停止指示を受信した場合、当該タイマを停止する。ｇＮＢ２００はＭＢＳ送信を再開する時に、ＵＥ１００に当該タイマの再開指示を送信してもよい。ＵＥ１００は当該再開指示を受信した場合、当該タイマを再開する。再開時、当該タイマはリセットしてもよいし（つまり０にセットする）、リセットしなくてもよい（つまり停止時の値から再開してもよい）。もしくは、ｇＮＢ２００は、ＭＢＳ送信を再開する時に、前記再開指示を送信せずに、ＭＢＳデータの送信を再開してもよい。ＵＥ１００はＭＢＳデータを受信した場合、ｇＮＢ２００がＭＢＳ送信を再開したと見なし、当該タイマを再開する。
【0129】
上述の各動作フローは、別個独立に実施する場合に限らず、２以上の動作フローを組み合わせて実施可能である。例えば、１つの動作フローの一部のステップを他の動作フローに追加してもよい。また、１つの動作フローの一部のステップを他の動作フローの一部のステップと置換してもよい。
【0130】
上述の実施形態及び実施例において、基地局がＮＲ基地局（ｇＮＢ）である一例について説明したが基地局がＬＴＥ基地局（ｅＮＢ）又は６Ｇ基地局であってもよい。また、基地局は、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノード等の中継ノードであってもよい。基地局は、ＩＡＢノードのＤＵであってもよい。また、ユーザ装置は、ＩＡＢノードのＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｉｏｎ）であってもよい。
【0131】
ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ ｏｎ ａ ｃｈｉｐ）として構成してもよい。
【0132】
本開示で使用されている「に基づいて（ｂａｓｅｄ ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。
【0133】
以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
【0134】
本願は、米国仮出願第６３／２２９１５５号（２０２１年８月４日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
【0135】
（付記）
１．導入
ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８で承認された。これには、動的なＰＴＭ／ＰＴＰの切り替えとサービス継続性を備えたモビリティを次のように規定する目的が含まれている。
ＲＲＣコネクティッド状態のＵＥのブロードキャスト／マルチキャストのＲＡＮ基本機能を規定する。
特定のＵＥのサービス継続性を備えたマルチキャスト（ＰＴＭ）とユニキャスト（ＰＴＰ）と間のブロードキャスト／マルチキャストサービス配信の動的変更のサポートを規定する。
サービス継続性を備えた基本的なモビリティのサポートを規定する。
１．導入
ＮＲマルチキャスト及びブロードキャストサービス（ＭＢＳ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８で承認された。これには、動的なＰＴＭ／ＰＴＰの切り替えとサービス継続性を備えたモビリティを次のように規定する目的が含まれている。
ＲＲＣコネクティッド状態のＵＥのブロードキャスト／マルチキャストのＲＡＮ基本機能を規定する。
特定のＵＥのサービス継続性を備えたマルチキャスト（ＰＴＭ）とユニキャスト（ＰＴＰ）と間のブロードキャスト／マルチキャストサービス配信の動的変更のサポートを規定する。
サービス継続性を備えた基本的なモビリティのサポートを規定する。
【0136】
動的なＰＴＭ／ＰＴＰ切り替えに関しては、ＲＡＮ２はすでにこのトピックに関連するいくつかの合意に達している。ＲＡＮ２＃１１１－ｅには以下の合意があった。
ＵＥの場合、ｇＮＢは、マルチキャストデータをＰＴＭ又はＰＴＰ（共有配信）のどちらで配信するかを動的に決定する。
レイヤが信頼性（一般的に）、順序どおりの配信／重複処理を処理することについては更なる検討が必要であり、ＰＴＭとＰＴＰとの切り替えでどのように機能するかは更なる検討が必要である。
ＵＥの場合、ｇＮＢは、マルチキャストデータをＰＴＭ又はＰＴＰ（共有配信）のどちらで配信するかを動的に決定する。
レイヤが信頼性（一般的に）、順序どおりの配信／重複処理を処理することについては更なる検討が必要であり、ＰＴＭとＰＴＰとの切り替えでどのように機能するかは更なる検討が必要である。
【0137】
ＲＡＮ２＃１１３－ｅでは、動的なＰＴＭ／ＰＴＰの切り替えのアーキテクチャが、Ｌ２の信頼性に関する議論に関連して次のように合意された。
ＰＴＭとＰＴＰとの両方がＲＬＣ ＵＭの場合、Ｌ２ ＡＲＱがなく、ＰＤＣＰが固定されたＰＴＭとＰＴＰとの切り替えを使用した設定がサポートされる（たとえば、ユニキャスト用にＲＬＣ ＵＭで通常設定されるサービスの場合）。
ＰＴＭとＰＴＰとの両方がＲＬＣ ＵＭの場合、Ｌ２ ＡＲＱがなく、ＰＤＣＰが固定されたＰＴＭとＰＴＰとの切り替えを使用した設定がサポートされる（たとえば、ユニキャスト用にＲＬＣ ＵＭで通常設定されるサービスの場合）。
【0138】
ＲＡＮ２＃１１３ｂｉｓ－ｅでは、アーキテクチャとシグナリングについて次のようにさらに合意が達せられた。
合意
以下の合意は、これまでのところアーキテクチャの決定にのみ基づいていることに注意する。信頼性の議論はまだ終わっていない。つまり、ＲＬＣ ＵＭ＋ＲＬＣ ＵＭ以外の場合である。このような他の場合のＰＴＭとＰＴＰとの切り替えについては、更なる検討が必要である。
動的なＰＴＭ／ＰＴＰの切り替えは、共通の（単一の）ＰＤＣＰエンティティを有するスプリットＭＲＢベアラ（タイプ）でサポートされる。
基本として、ｇＮＢスイッチの決定をサポートするための新しいＵＥベースのシグナリングは導入されていない（たとえば、高信頼性のためのＰＤＣＰ ＳＲは未定である）。
ＰＴＭレグとＰＴＰレグで設定されたスプリットＭＲＢ（オンラインセッション中に合意された）を想定すると、必要なスプリットＭＲＢ設定の後で、ＰＴＰレグの使用を非アクティブ化することはできない（つまり、ＵＥは常にＣ－ＲＮＴＩを監視する必要がある）。
ＰＴＭレグとＰＴＰレグとで設定されたスプリットＭＲＢ（オンラインセッション中に合意された）を想定すると、スプリットＭＲＢのＰＴＭレグの使用がアクティブ化又は非アクティブ化の対象となるかどうか、及びその詳細については更なる検討が必要である。
合意
以下の合意は、これまでのところアーキテクチャの決定にのみ基づいていることに注意する。信頼性の議論はまだ終わっていない。つまり、ＲＬＣ ＵＭ＋ＲＬＣ ＵＭ以外の場合である。このような他の場合のＰＴＭとＰＴＰとの切り替えについては、更なる検討が必要である。
動的なＰＴＭ／ＰＴＰの切り替えは、共通の（単一の）ＰＤＣＰエンティティを有するスプリットＭＲＢベアラ（タイプ）でサポートされる。
基本として、ｇＮＢスイッチの決定をサポートするための新しいＵＥベースのシグナリングは導入されていない（たとえば、高信頼性のためのＰＤＣＰ ＳＲは未定である）。
ＰＴＭレグとＰＴＰレグで設定されたスプリットＭＲＢ（オンラインセッション中に合意された）を想定すると、必要なスプリットＭＲＢ設定の後で、ＰＴＰレグの使用を非アクティブ化することはできない（つまり、ＵＥは常にＣ－ＲＮＴＩを監視する必要がある）。
ＰＴＭレグとＰＴＰレグとで設定されたスプリットＭＲＢ（オンラインセッション中に合意された）を想定すると、スプリットＭＲＢのＰＴＭレグの使用がアクティブ化又は非アクティブ化の対象となるかどうか、及びその詳細については更なる検討が必要である。
【0139】
モビリティの側面に関しては、ＲＡＮ２は以下にリストされている基本原則のみに合意した。
Ｒ２は、これを必要とするサービスのＭＢＳ－ＭＢＳモビリティのロスレスなハンドオーバーをサポートすることを目的としている（シナリオの詳細は未定である。少なくともＰＴＰ－ＰＴＰ）。
５Ｇ ＭＢＳサービスのロスレスなハンドオーバーをサポートするには、少なくともＤＬ ＰＤＣＰ ＳＮの同期と、ソースセルとターゲットセル間の継続性とがネットワーク側で保証されている必要がある。これを実現するための特定のアプローチの設計は、ＷＧ ＲＡＮ３に関係する可能性がある。
ネットワーク側から、ソースｇＮＢはデータをターゲットｇＮＢに転送する場合があり、ターゲットｇＮＢは転送データを配信する。一方、ＳＮ ＳＴＡＴＵＳ ＴＲＡＮＳＦＥＲは、ＭＢＳデータのＰＤＣＰＳＮをカバーするように拡張する必要がある。次に、ＵＥは、ターゲット設定に従って、ターゲットセルによってターゲットセル内のＭＢＳを受信する。
ＵＥ側からは、ＰＤＣＰ状態報告もサポートされる場合がある。
Ｒ２は、これを必要とするサービスのＭＢＳ－ＭＢＳモビリティのロスレスなハンドオーバーをサポートすることを目的としている（シナリオの詳細は未定である。少なくともＰＴＰ－ＰＴＰ）。
５Ｇ ＭＢＳサービスのロスレスなハンドオーバーをサポートするには、少なくともＤＬ ＰＤＣＰ ＳＮの同期と、ソースセルとターゲットセル間の継続性とがネットワーク側で保証されている必要がある。これを実現するための特定のアプローチの設計は、ＷＧ ＲＡＮ３に関係する可能性がある。
ネットワーク側から、ソースｇＮＢはデータをターゲットｇＮＢに転送する場合があり、ターゲットｇＮＢは転送データを配信する。一方、ＳＮ ＳＴＡＴＵＳ ＴＲＡＮＳＦＥＲは、ＭＢＳデータのＰＤＣＰＳＮをカバーするように拡張する必要がある。次に、ＵＥは、ターゲット設定に従って、ターゲットセルによってターゲットセル内のＭＢＳを受信する。
ＵＥ側からは、ＰＤＣＰ状態報告もサポートされる場合がある。
【0140】
この付記では、合意されたアーキテクチャに基づく、つまりＰＤＣＰに固定されたスプリットＭＲＢを使用した、サービス継続性を備えた動的なＰＴＭ／ＰＴＰの切り替えとモビリティの残りの問題について説明する。
【0141】
【0142】
一般に、ＲＲＣ再設定は、マルチキャストセッションを受信するための情報とともに、２つの論理チャネル（ＰＴＭレグ及びＰＴＰレグ）を含むベアラ設定を提供するために使用されるとみなすことができる。ＲＡＮ２は、「ＰＴＭレグとＰＴＰレグとで設定されたスプリットＭＲＢ（オンラインセッションで合意されたもの）を想定する」と述べているが、１つのマルチキャスト無線ベアラに２つの論理チャネルを関連付ける設定は、動的なＰＴＭ／ＰＴＰの切り替えの準備としてＲＲＣ再設定で提供されることがすでに共通の理解になっていると思われる。
【0143】
所見１：１つのＭＲＢに２つの論理チャネルを関連付ける設定は、動的なＰＴＭ／ＰＴＰ切り替え動作に先立ち、ＲＲＣ再設定によって提供されるというのが共通の理解であると思われる。
【0144】
４．動的なＰＴＭ／ＰＴＰの切り替え動作
５．シグナリング
スプリットＭＲＢのＰＴＭレグの使用は、アクティブ化又は非アクティブ化の対象となり得るかどうか、及びその詳細については、更なる検討が必要である。
５．シグナリング
スプリットＭＲＢのＰＴＭレグの使用は、アクティブ化又は非アクティブ化の対象となり得るかどうか、及びその詳細については、更なる検討が必要である。
【0145】
ＰＴＭレグ／ＰＴＰレグを有するスプリットＭＲＢが設定されると、ＵＥはＰＴＭレグのＧ－ＲＮＴＩとＰＴＰレグのＣ－ＲＮＴＩとの両方をモニタする必要がある。ＬＴＥ ＳＣ－ＰＴＭでは、「ＳＣ－ＰＴＭの受信機会はユニキャストＤＲＸ方式から独立している」、つまり、ＤＲＸが別々になっている。Ｇ－ＲＮＴＩは複数のＵＥで受信されるのに対し、Ｃ－ＲＮＴＩはＵＥ固有であり、２つのＤＲＸの位置合わせは非常に難しいため、このコンセプトがＮＲ ＭＢＳの基本となる可能性がある。これは、ＵＥが常にＧ－ＲＮＴＩを監視しなければならない場合、頻繁にウェイクアップする必要があることを意味し、さらなる電力消費の原因となる。一方、接続中のＵＥは、ユニキャスト受信のためにＣ－ＲＮＴＩ、すなわちＣ－ＤＲＸを監視する必要があるが、これはＵＥにとって追加の負担ではない。
【0146】
所見２：ＵＥは、Ｃ－ＤＲＸと同じＰＴＰレグの送信機会（すなわちＣ－ＲＮＴＩ）に加えて、ＬＴＥ ＳＣ－ＰＴＭのＳＣ－ＭＴＣＨ機会のようにＰＴＭレグの送信機会（すなわちＧ－ＲＮＴＩ）でウェイクアップする必要がある。
【0147】
ＰＴＭ／ＰＴＭを伴うＭＲＢ受信時、つまり切り替え動作時の選択肢は以下の４つである。
【0148】
選択肢１：アクティブ化／非アクティブ化ベースの切り替え
ｇＮＢは、ＤＣＩ、ＭＡＣ ＣＥ、又はＲＲＣ信号などによって、ＰＴＭレグの有効化／無効化をＵＥに指示する。この選択肢は、ＰＴＭ又はＰＴＰのいずれかを介したＭＢＳデータ受信に加え、スプリットベアラ又はＰＤＣＰパケット重複のように、ＭＢＳデータを２つのレグを介して受信する場合、より柔軟に対応することができる。ＵＥは、非アクティブ化されたＰＴＭレグからの消費電力を低減することができる。ＮＷの実装では、常に２つのレグをアクティブにしておくことを決定する可能性があり、以下の選択肢４の意図をカバーすることができることに留意する。
ｇＮＢは、ＤＣＩ、ＭＡＣ ＣＥ、又はＲＲＣ信号などによって、ＰＴＭレグの有効化／無効化をＵＥに指示する。この選択肢は、ＰＴＭ又はＰＴＰのいずれかを介したＭＢＳデータ受信に加え、スプリットベアラ又はＰＤＣＰパケット重複のように、ＭＢＳデータを２つのレグを介して受信する場合、より柔軟に対応することができる。ＵＥは、非アクティブ化されたＰＴＭレグからの消費電力を低減することができる。ＮＷの実装では、常に２つのレグをアクティブにしておくことを決定する可能性があり、以下の選択肢４の意図をカバーすることができることに留意する。
【0149】
選択肢２：切り替えオーダー／コマンドベース切り替え
ｇＮＢは、ＤＣＩ、ＭＡＣ ＣＥ、又はＲＲＣシグナリングなどによって、ＵＥにＰＴＭレグとＰＴＰレグの間の切り替えを指示する。この選択肢は、ＰＴＭレグの非アクティブ化による省電力化という点では、上記の選択肢１と同様であり、シンプルである。しかし、ＰＤＣＰパケットの重複を含むスプリットベアラ的な動作には柔軟性に欠ける。この選択肢は、ＰＴＭレグとＰＴＰレグ間の切り替えのみで、両方をアクティブ化することはできないと思われる。
ｇＮＢは、ＤＣＩ、ＭＡＣ ＣＥ、又はＲＲＣシグナリングなどによって、ＵＥにＰＴＭレグとＰＴＰレグの間の切り替えを指示する。この選択肢は、ＰＴＭレグの非アクティブ化による省電力化という点では、上記の選択肢１と同様であり、シンプルである。しかし、ＰＤＣＰパケットの重複を含むスプリットベアラ的な動作には柔軟性に欠ける。この選択肢は、ＰＴＭレグとＰＴＰレグ間の切り替えのみで、両方をアクティブ化することはできないと思われる。
【0150】
選択肢３：ＲＲＣ再設定ベースの切り替え
ｇＮＢは、ＲＲＣ再設定により、ＵＥをＰＴＭ又はＰＴＰのいずれかをＭＲＢとして再設定する。つまり、ＰＴＭレグとＰＴＰレグとを１つのＭＲＢに関連付けない。つまり「ベアラタイプの変更」のようなもので、スプリットＭＲＢアーキテクチャとは整合性がとれていない。また、この選択肢は、Ｌ３が関与するため、ＰＴＭとＰＴＰとの切り替えをどれだけ「動的」に行えるかは疑問が残る。
ｇＮＢは、ＲＲＣ再設定により、ＵＥをＰＴＭ又はＰＴＰのいずれかをＭＲＢとして再設定する。つまり、ＰＴＭレグとＰＴＰレグとを１つのＭＲＢに関連付けない。つまり「ベアラタイプの変更」のようなもので、スプリットＭＲＢアーキテクチャとは整合性がとれていない。また、この選択肢は、Ｌ３が関与するため、ＰＴＭとＰＴＰとの切り替えをどれだけ「動的」に行えるかは疑問が残る。
【0151】
選択肢４：切り替えに基づくシグナリングなし
ＵＥは、スプリットＭＲＢに２つのレグが設定されている場合は常に、ＰＴＭレグとＰＴＰレグとの両方からの受信を試行する必要がある。この選択肢は、ｇＮＢの観点から最大限のスケジューリングの柔軟性を確保するが、ＵＥにとっては節電の機会がない。
ＵＥは、スプリットＭＲＢに２つのレグが設定されている場合は常に、ＰＴＭレグとＰＴＰレグとの両方からの受信を試行する必要がある。この選択肢は、ｇＮＢの観点から最大限のスケジューリングの柔軟性を確保するが、ＵＥにとっては節電の機会がない。
【0152】
以上のことから、選択肢１は、スケジューリングの柔軟性、ＵＥの消費電力、及びスプリットＭＲＢアーキテクチャとの整合性の点で最も適した選択肢であると言える。選択肢４は、ＰＴＭレグが常にアクティブである場合、選択肢１のサブセットと見なすことができる。シグナリングレイヤについては、アクティブ化／非アクティブ化はほとんどＤＲＸの動作に関連しているため、ＭＡＣ ＣＥは容易である可能性がある。したがって、ＲＡＮ２は、ＰＴＭレグがＭＡＣ ＣＥを介してアクティブ化／非アクティブ化できることに合意すべきである。
【0153】
提案１：動的なＰＴＭ／ＰＴＰ切り替えのために、ＲＡＮ２は、スプリットＭＲＢのＰＴＭレグをアクティブ／非アクティブにするＭＡＣ ＣＥを導入することに合意すべきである。
【0154】
動的な切り替えとは異なる「ベアラタイプ変更」について、ベアラタイプ変更には以下のようなケースがあると考えられる。
ケース１：ＰＴＭのみＭＲＢ←→ＰＴＰのみＭＲＢ
ケース２：スプリットＭＲＢ←→ＰＴＭのみＭＲＢ
ケース３：スプリットＭＲＢ←→ＰＴＰのみＭＲＢ
ケース１：ＰＴＭのみＭＲＢ←→ＰＴＰのみＭＲＢ
ケース２：スプリットＭＲＢ←→ＰＴＭのみＭＲＢ
ケース３：スプリットＭＲＢ←→ＰＴＰのみＭＲＢ
【0155】
このようなベアラタイプ変更の場合、ＲＲＣ再設定、つまり選択肢３を使用するのが容易である。
【0156】
提案２：ＰＴＭのみＭＲＢ、ＰＴＰのみＭＲＢ、及びスプリットＭＲＢ間のベアラタイプ変更については、ＲＡＮ２はＲＲＣ再設定を使用することに合意すべきである。
【0157】
６．ＰＤＣＰの行動
７．状態変数の初期値
ＲＡＮ２は、ＲＬＣ ＵＭモードに加え、スプリットＭＲＢのＰＴＰレグのＲＬＣ ＡＭモードをサポートすることに合意した。また、「ＲＬＣ－ＡＭはＰＴＭに対応していない（ＭＢＳ Ｒ１７ ＷＩ用）」ため、Ｌ２信頼性は動的なＰＴＭ／ＰＴＰ切り替えにのみ依存するというのが共通認識となっている。そのため、ＭＢＳデータ受信開始時や動的なＰＴＭ／ＰＴＰ切り替え時のパケットロスをいかに少なくするかは、サービス継続のために検討する価値がある。
７．状態変数の初期値
ＲＡＮ２は、ＲＬＣ ＵＭモードに加え、スプリットＭＲＢのＰＴＰレグのＲＬＣ ＡＭモードをサポートすることに合意した。また、「ＲＬＣ－ＡＭはＰＴＭに対応していない（ＭＢＳ Ｒ１７ ＷＩ用）」ため、Ｌ２信頼性は動的なＰＴＭ／ＰＴＰ切り替えにのみ依存するというのが共通認識となっている。そのため、ＭＢＳデータ受信開始時や動的なＰＴＭ／ＰＴＰ切り替え時のパケットロスをいかに少なくするかは、サービス継続のために検討する価値がある。
【0158】
図１７に示すように、既存のＰＤＣＰ機能ビューを再利用すれば、ＰＤＣＰ ＳＮは、ＰＴＭレグとＰＴＰレグとで共通である。ＰＴＭレグは複数のＵＥで使用されるため、ＰＤＣＰ ＳＮはＵＥ固有でない可能性があり、ＰＴＭレグとＰＴＰレグとの両方に影響する。これは、ＵＥがマルチキャストセッションに遅れて参加する場合、最初に受信したＭＢＳデータがＰＴＭレグとＰＴＰレグとのどちらから来るかに関係なく、各状態変数の初期値を常に「０」にすることはできないことを意味している。つまり、ＵＥが最初に受信するＰＤＣＰ ＳＮは、今回のユニキャスト送信で想定していない任意の値であってもよい。また、状態変数が初期値に設定されるため、あるＵＥのＰＤＣＰ再確立が他のすべてのＵＥに影響を与える可能性がある。受信ウィンドウで予期せぬ動作、つまりウィンドウ外のＰＤＣＰ ＰＤＵを破棄することになる。ハンドオーバーのシナリオでも同じ問題が存在する可能性があることが指摘されている。
【0159】
所見３：マルチキャストセッションに後発で参加し、スプリットＭＲＢが設定されているＵＥの場合、最初に受信したＰＤＣＰ ＰＤＵのＳＮは、ＰＴＭレグ又はＰＴＰレグに関わらず初期値（すなわち「０」）ではないことが確認されている。
【0160】
この問題を解決するために、以下の選択肢が提案されている。
【0161】
選択肢Ａ：ｇＮＢは、ＣＯＵＮＴの初期値、又はＲＸ＿ＮＥＸＴ及びＲＸ＿ＤＥＬＩＶをＵＥに通知する。
この選択肢は、ＵＥが既存のメカニズムでＭＢＳデータの最初の送信を受信できるように、ｇＮＢからの情報に基づいて受信ウィンドウに関する初期値を単に変更するものである。しかし、ＰＤＣＰレイヤの観点からは、切り替えの遅延、無線状態の悪化、ＲＬＣ再構築ウィンドウの範囲外など、ｇＮＢが意図した最初の送信をＵＥが常に正常に受信できるかは疑問がある。この場合、この選択肢がどのように機能するかは不明確である。
この選択肢は、ＵＥが既存のメカニズムでＭＢＳデータの最初の送信を受信できるように、ｇＮＢからの情報に基づいて受信ウィンドウに関する初期値を単に変更するものである。しかし、ＰＤＣＰレイヤの観点からは、切り替えの遅延、無線状態の悪化、ＲＬＣ再構築ウィンドウの範囲外など、ｇＮＢが意図した最初の送信をＵＥが常に正常に受信できるかは疑問がある。この場合、この選択肢がどのように機能するかは不明確である。
【0162】
選択肢Ｂ：ｇＮＢはＵＥに初期ＨＦＮを通知し、ＵＥは最初に受信したＰＤＣＰ ＰＤＵから初期ＨＦＮとＳＮを推測する。
ＳＮ部については、Ｒｅｌ－１６のＶ２Ｘメカニズムと同様の選択肢、すなわち、以下の通りである。「ＲＸ＿ＮＥＸＴのＳＮ部の初期値は、（ｘ＋１）ｍｏｄｕｌｏ（２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ］）であり、ｘは最初に受信したＰＤＣＰデータＰＤＵのＳＮである」、「ＮＲ ｓｉｄｅｌｉｎｋ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｒ ｂｒｏａｄｃａｓｔ ａｎｄ ｇｒｏｕｐｃａｓｔでは、ＲＸ＿ＤＥＬＩＶのＳＮ部の初期値は（ｘ－０．５×２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ－１］）ｍｏｄｕｌｏ（２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ］），ただしｘは最初に受信したＰＤＣＰ Ｄａｔａ ＰＤＵのＳＮである」。
ＳＮ部については、Ｒｅｌ－１６のＶ２Ｘメカニズムと同様の選択肢、すなわち、以下の通りである。「ＲＸ＿ＮＥＸＴのＳＮ部の初期値は、（ｘ＋１）ｍｏｄｕｌｏ（２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ］）であり、ｘは最初に受信したＰＤＣＰデータＰＤＵのＳＮである」、「ＮＲ ｓｉｄｅｌｉｎｋ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｆｏｒ ｂｒｏａｄｃａｓｔ ａｎｄ ｇｒｏｕｐｃａｓｔでは、ＲＸ＿ＤＥＬＩＶのＳＮ部の初期値は（ｘ－０．５×２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ－１］）ｍｏｄｕｌｏ（２［ｓｌ－ＰＤＣＰ－ＳＮ－Ｓｉｚｅ］），ただしｘは最初に受信したＰＤＣＰ Ｄａｔａ ＰＤＵのＳＮである」。
【0163】
ＨＦＮ部分については、Ｒｅｌ－１６ Ｖ２Ｘメカニズムでは、セキュリティのためにＨＦＮを使用しないため、送信機と受信機の同期を必要としない。すなわち、「注：ＲＸ＿ＤＥＬＩＶの初期値を正の値にするように、ＲＸ＿ＮＥＸＴのＨＦＮを選択するのはＵＥ実装次第」とされている。ＮＲ ＭＢＳについては、「ＲＡＮ２は、ＲＡＮ２でセキュリティの側面を議論する前に、ＳＡ３がＭＢＳのセキュリティに関する研究を完了させるのを待つと回答する」。したがって、ＲＡＮ２は、ＳＡ３がセキュリティに関する研究を完了するまで、ＨＦＮ部分の議論を延期すべきである。
【0164】
以上のことから、選択肢Ｂを基本として、さらに議論を深めていくべきである。ブロードキャスト及びグループキャストのＲｅｌ－１６サイドリンク通信によると、ＮＲ ＭＢＳのセキュリティに関するＳＡ３の進展を考慮すると、ＲＡＮ２は少なくとも、ＵＥがＭＢＳデータの最初の受信ＰＤＣＰ ＰＤＵから状態変数の初期値を設定することに合意すべきである。
【0165】
提案３：ＲＡＮ２は、ＰＴＭレグ又はＰＴＰレグに関係なく、ＵＥが最初に受信したＭＢＳデータからＲＸ＿ＮＥＸＴ及びＲＸ＿ＤＥＬＩＶのＳＮ部分の初期値を設定することに合意すべきである。ＨＦＮの部分がｇＮＢから通知されるかどうかは、ＳＡ３の進捗次第あり、更なる検討が必要である。
【0166】
８．同時受信とＵＥ支援情報
特に、ＰＴＰ（レグ）は信頼性が要求されるサービスではＲＬＣ ＡＭで設定され、ロスレスなモビリティと同様にサービス継続のためにロスレスな切り替えは重要である。提案１に合意する場合、ＵＥはＰＴＭレグとＰＴＰレグとの両方からの同時受信をサポートする必要がある。つまり、既存のＰＤＣＰパケット重複と同様に、２つのレグを同時にアクティブ化できる。これは、ＰＴＭレグが複数のＵＥによって受信されるため、特定のＵＥにとって最適なＭＣＳではないことが容易に起こり得るためである。そのため、ＲＡＮ２は動的なＰＴＭ／ＰＴＰ切り替え時に、少なくとも一定期間同時受信の使用を採用することに合意すべきである。
特に、ＰＴＰ（レグ）は信頼性が要求されるサービスではＲＬＣ ＡＭで設定され、ロスレスなモビリティと同様にサービス継続のためにロスレスな切り替えは重要である。提案１に合意する場合、ＵＥはＰＴＭレグとＰＴＰレグとの両方からの同時受信をサポートする必要がある。つまり、既存のＰＤＣＰパケット重複と同様に、２つのレグを同時にアクティブ化できる。これは、ＰＴＭレグが複数のＵＥによって受信されるため、特定のＵＥにとって最適なＭＣＳではないことが容易に起こり得るためである。そのため、ＲＡＮ２は動的なＰＴＭ／ＰＴＰ切り替え時に、少なくとも一定期間同時受信の使用を採用することに合意すべきである。
【0167】
提案４：ＲＡＮ２は、動的なＰＴＭ／ＰＴＰ切り替え後の一定期間、ＵＥがＰＴＭレグ及びＰＴＰレグの両方からの同時受信をサポートすることに合意すべきである。
【0168】
提案３と提案４が合意された場合、ＵＥがＰＴＭレグを介してどのＰＤＣＰ ＳＮを正常に受信し始めたかどうかをｇＮＢが実際に知らない可能性がある。ＰＴＰからＰＴＭへの切り替える場合、ｇＮＢは、どのＰＤＣＰ ＰＤＵをＰＴＰレグで送信すべきか、また、いつＰＴＰレグの送信を停止できるかがわからない場合がある。この問題を解決するために、ＵＥがＰＴＭ受信に成功したことをｇＮＢに通知し、ＰＴＰレグを通じて送信することが提案されている。ただし、ＵＥがＰＤＣＰ ＳＮ情報も同じメッセージに含めるべきかどうかは不明確である。
【0169】
所見４：ＰＴＰからＰＴＭへ切り替える場合、ｇＮＢは、どのＰＤＣＰ ＰＤＵからＰＴＰレグの送信を維持する必要があるか、又はＵＥがどのＰＤＣＰ ＰＤＵからＰＴＭレグによる受信を正常に開始するかを知らない場合がある。
【0170】
同様に、ＰＴＭからＰＴＰへ切り替える場合、ＵＥがＰＴＭレグを介してどのＰＤＣＰ ＳＮを正常に受信したかをｇＮＢが知らない可能性がある（特に、ＵＥの無線状態が悪い場合）。これは、ＰＴＰレグの開始時にどのＰＤＣＰ ＰＤＵを使用すべきかをｇＮＢが知らない可能性があることを意味する。
【0171】
所見５：ＰＴＭからＰＴＰへ切り替える場合、ｇＮＢは、ＰＴＰレグがどのＰＤＣＰ ＰＤＵから送信を開始する必要があるか、又はＵＥがＰＴＭレグを介してどのＰＤＣＰ ＰＤＵを正常に受信したかを知らない場合がある。
【0172】
そのため、ＵＥは動的なＰＴＭ／ＰＴＰ切り替え時に、ＰＴＰレグを介してＳＮ情報をｇＮＢに通知することが検討される。ＰＴＭとＰＴＰとの間の動的な切り替え時にＵＥがＳＮ情報を報告する場合、ＰＤＣＰ制御ＰＤＵ、つまり、ＦＭＣ（最初のＰＤＣＰ ＳＤＵが見つからない）及び選択肢としてビットマップ（後続のＰＤＣＰ ＳＤＵが見つからないか正しく受信されているかを示す）を含むＰＤＣＰ状態報告を再利用することは容易である。一方、ＵＥがＰＴＭレグを介して最初／最後のＰＤＣＰ ＰＤＵ受信に成功したＳＮを報告することも選択肢の１つである。したがって、ＰＴＭとＰＴＰとの動的な切り替え時にＵＥが報告する内容については、さらなる議論が必要である。
【0173】
上記のいずれの場合（すなわち、ＰＴＰからＰＴＭへ切り替える場合及びＰＴＭからＰＴＰへ切り替える場合）でも、動的な切り替え（例えば、ＭＡＣ ＣＥのアクティブ化／非アクティブ化）時に、サービス継続のためのＰＤＣＰ ＳＮ情報を含むＰＤＣＰ制御ＰＤＵをトリガする必要がある。
【0174】
提案５：ＲＡＮ２は、サービス継続のために、ＵＥが動的な切り替え時にＰＤＣＰ ＳＮ情報を含むＰＤＣＰ 制御ＰＤＵを送信するかどうかを検討すべきである。ＰＤＣＰ情報報告が再利用可能かどうかについては、更なる検討が必要である。
【0175】
もう一つは、提案５のようなロスレスな動的切り替えと同様のロスレスなベアラタイプの変更が必要かという点である。ＲＬＣ ＡＭを伴うＰＴＰ（レグ）を含むベアラタイプの変更は、サービス継続性、ロスレスなモビリティの観点から、動的な切り替えと同様の信頼性が必要であると考えられる。そのため、ＲＡＮ２は、ロスレスなベアラタイプの変更をサポートするかどうかを検討すべきである。サポートする場合は、提案５と同様にＵＥ支援情報としてＰＤＣＰ制御ＰＤＵを再利用すべきである。
【0176】
提案６：ＲＡＮ２は、ＲＲＣ再設定を伴うロスレスなベアラタイプの変更、すなわち提案５のようなＰＤＣＰ制御ＰＤＵによるロスレスな動的切り替えと同じ解決策が適用可能かどうかを議論すべきである。
【符号の説明】
【0177】
１ ：移動通信システム
１０ ：ＲＡＮ
２０ ：ＣＮ
１００ ：ＵＥ
１１０ ：受信部
１２０ ：送信部
１３０ ：制御部
２００ ：ｇＮＢ
２１０ ：送信部
２２０ ：受信部
２３０ ：制御部
２４０ ：バックホール通信部
１０ ：ＲＡＮ
２０ ：ＣＮ
１００ ：ＵＥ
１１０ ：受信部
１２０ ：送信部
１３０ ：制御部
２００ ：ｇＮＢ
２１０ ：送信部
２２０ ：受信部
２３０ ：制御部
２４０ ：バックホール通信部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】