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

Description

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

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

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

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

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

第１の態様に係る通信方法は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）を基地局から受信するユーザ装置で実行する通信方法であって、前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ） Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記基地局から受信することと、前記ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ハイパーフレーム番号に基づいて、前記ユーザ装置が管理するＰＤＣＰ状態変数の初期値を決定することと、を有する。

第２の態様に係るユーザ装置は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）を基地局から受信するユーザ装置であって、前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ） Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記基地局から受信する受信部と、前記ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ハイパーフレーム番号に基づいて、前記ユーザ装置が管理するＰＤＣＰ状態変数の初期値を決定する制御部と、を備える。

第３の態様に係る基地局は、マルチキャスト・ブロードキャストサービス（ＭＢＳ）データを構成する一連のＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）データＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）をユーザ装置に送信する基地局であって、前記基地局が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号が一周する度にカウントアップされるハイパーフレーム番号を含む無線リソース制御（ＲＲＣ） Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、前記ユーザ装置に送信する送信部を備える。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（移動通信システムの動作）
一般的に、ＰＤＣＰ状態変数の初期値はゼロであり、ｇＮＢ２００（送信側ＰＤＣＰエンティティ２０１）からＵＥ１００（受信側ＰＤＣＰエンティティ１０１）へのデータ送信が開始されると、ｇＮＢ２００（送信側ＰＤＣＰエンティティ２０１）及びＵＥ１００（受信側ＰＤＣＰエンティティ１０１）で同期してＰＤＣＰ状態変数が更新される。

しかしながら、図１０に示すようなシナリオにおいて、ＵＥ１００（ＵＥ１００ａ乃至ＵＥ１００ｃのいずれか）は、必ずしも、ｇＮＢ２００がＭＢＳセッション（マルチキャストセッション又はブロードキャストセッション）の提供を開始した時点からＭＢＳ受信を開始できるとは限らず、ｇＮＢ２００（送信側ＰＤＣＰエンティティ２０１）及びＵＥ１００（受信側ＰＤＣＰエンティティ１０１）でＰＤＣＰ状態変数が非同期の状態になり、上述のようなＰＤＣＰレイヤ動作を適切に実行できないという問題がある。例えば、いずれかのＵＥ１００は、当該ｇＮＢ２００が提供するＭＢＳセッションの途中からＭＢＳ受信を開始し得る。そのようなＵＥ１００は、他のｇＮＢ２００（他のセル）からセル変更（例えば、セル再選択又はハンドオーバ）してきたＵＥ１００でもあり得る。

図１５は、実施形態に係るＵＥ１００の動作を示す図である。実施形態において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ｇＮＢ２００からＰＴＭで送信されるＭＢＳデータを構成する一連のＰＤＣＰデータＰＤＵをｇＮＢ２００から受信する。ＰＤＣＰデータＰＤＵは、ＰＤＣＰ ＭＲＢデータＰＤＵと呼ばれてもよい。

ステップＳ１において、特定のＭＲＢの受信を行うＵＥ１００は、ｇＮＢ２００が送信するＰＤＣＰデータＰＤＵに含まれるシーケンス番号（ＰＤＣＰ ＳＮ）が一周する度にカウントアップされるＨＦＮ（具体的には、当該特定のＭＲＢにおける現在（最新）のＨＦＮ）をｇＮＢ２００から受信する。

ステップＳ１に先立ち、ＵＥ１００は、ＨＦＮの提供をｇＮＢ２００に要求してもよい。ＵＥ１００は、ＭＢＳデータ（ＰＤＣＰデータＰＤＵ）を正常受信できないことに関する条件が満たされたことに応じて、ＨＦＮの提供をｇＮＢ２００に要求してもよい。例えば、ＵＥ１００は、ＭＢＳ受信の失敗が継続する時間が所定時間を超えたことを示す第１条件、及びＭＢＳ受信を連続して失敗した回数が所定回数を超えたことを示す第２条件のうち、少なくとも一方の条件が満たされたことに応じて、ＨＦＮの提供をｇＮＢ２００に要求してもよい。或いは、ＵＥ１００は、現在（最新）のＨＦＮの情報を有していないことを示す第３条件が満たされたことに応じて、ＨＦＮの提供をｇＮＢ２００に要求してもよい。例えば、ＵＥ１００は、ブロードキャストセッションについて途中から受信に興味を持ったこと又は途中から受信を開始したことなどにより、現在のＨＦＮを有していない場合、ＨＦＮの提供をｇＮＢ２００に要求してもよい。このような要求信号の構成例については、第４実施例において説明する。

ステップＳ１において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＨＦＮを含むＰＤＣＰ制御ＰＤＵ、又はＨＦＮをヘッダに含むＰＤＣＰデータＰＤＵをｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１から受信してもよい。ＰＨＹレイヤにおいて、当該ＰＤＣＰ制御ＰＤＵの伝送には、複数ＵＥ向けのＲＮＴＩ（例えば、Ｇ－ＲＮＴＩ、ＭＣＣＨ－ＲＮＴＩ、ＳＩ－ＲＮＴＩ等）が用いられてもよい。また、当該ＰＤＣＰ制御ＰＤＵの伝送には、単一ＵＥ向けのＲＮＴＩ（例えば、Ｃ－ＲＮＴＩ）が用いられてもよい。ＵＥ１００は、当該特定のＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ１０１においてのみ当該ＨＦＮを適用する。

ステップＳ１において、ＵＥ１００のＲＲＣエンティティは、ＨＦＮを含むメッセージ（例えば、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ、ＳＩＢ、又はＭＣＣＨ）をｇＮＢ２００のＲＲＣエンティティから受信してもよい。当該メッセージは、ＨＦＮと、当該ＨＦＮと対応付けられたＭＲＢ識別子、ＭＢＳサービス識別子（例えば、ＴＭＧＩ）及び／又は論理チャネル識別子（ＬＣＩＤ）とを含んでもよい。ＵＥ１００は、当該メッセージに含まれるＭＲＢ識別子及び／又はＭＢＳサービス識別子が示すＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ１０１においてのみ当該ＨＦＮを適用する。なお、ＳＩＢがＨＦＮを含む場合、ＨＦＮの変更によるＶａｌｕｅ Ｔａｇのインクリメントは行わなくてもよい。

ステップＳ１において、ＵＥ１００のＭＡＣエンティティは、ＨＦＮを含むＭＡＣ制御要素（ＭＡＣ ＣＥ）をｇＮＢ２００のＭＡＣエンティティから受信してもよい。ＰＨＹレイヤにおいて、当該ＰＤＣＰ制御ＰＤＵの伝送には、複数ＵＥ向けのＲＮＴＩ（例えば、Ｇ－ＲＮＴＩ、ＭＣＣＨ－ＲＮＴＩ、ＳＩ－ＲＮＴＩ等）が用いられてもよい。また、当該ＰＤＣＰ制御ＰＤＵの伝送には、単一ＵＥ向けのＲＮＴＩ（例えば、Ｃ－ＲＮＴＩ）が用いられてもよい。当該ＭＡＣ ＣＥは、ＨＦＮと、当該ＨＦＮと対応付けられたＭＲＢ識別子、ＭＢＳサービス識別子（例えば、ＴＭＧＩ）及び／又は論理チャネル識別子（ＬＣＩＤ）とを含んでもよい。ＵＥ１００は、当該メッセージに含まれるＭＲＢ識別子及び／又はＭＢＳサービス識別子が示すＭＲＢと対応付けられた受信側ＰＤＣＰエンティティ１０１においてのみ当該ＨＦＮを適用する。

ステップＳ２において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１でｇＮＢ２００から受信したＨＦＮと、ｇＮＢ２００からＵＥ１００が受信するＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮとから、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）が管理するＰＤＣＰ状態変数の初期値を決定する。例えば、ＵＥ１００（受信側ＰＤＣＰエンティティ１０１）は、ステップＳ１でｇＮＢ２００から受信したＨＦＮと、ｇＮＢ２００からＵＥ１００が受信するＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮとを結合した結果に応じてＰＤＣＰ状態変数（例えば、ＲＸ＿ＮＥＸＴ、ＲＸ＿ＤＥＬＩＶ）の初期値を決定する。ここで、ＵＥ１００は、ＲＸ＿ＮＥＸＴの初期値を
(x +1) modulo (2^{[sl-PDCP-SN-Size]})
により決定し、ＲＸ＿ＤＥＬＩＶの初期値を
(x - 0.5 × 2^{[sl-PDCP-SN-Size-1]}) modulo (2^{[sl-PDCP-SN-Size]})
により決定してもよい。但し、xは、最初に受信したパケットのＳＮである。

ステップＳ３において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２で決定した初期値によってＰＤＣＰ状態変数を初期化する。すなわち、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２で決定した初期値をＰＤＣＰ状態変数としてセットする。

なお、ＵＥ１００は、ＭＢＳデータ（ＰＤＣＰデータＰＤＵ）を正常受信できないことに関する条件（例えば、上述の第１条件乃至第３条件のいずれか）が満たされたことに応じて、実施形態に係る動作を実行してもよい。すなわち、ＵＥ１００は、ＰＤＣＰ状態変数の同期外れが生じた可能性があると判定できる状況下において、実施形態に係る動作を実行してもよい。ＵＥ１００は、第１条件乃至第３条件のいずれの条件も満たされない場合、ステップＳ１でｇＮＢ２００から受信するＨＦＮを無視又は破棄してもよい。

実施形態に係る動作によれば、ｇＮＢ２００がＭＢＳセッションの提供を開始した時点からＵＥ１００がＭＢＳ受信を開始できない場合であっても、ｇＮＢ２００（送信側ＰＤＣＰエンティティ２０１）及びＵＥ１００（受信側ＰＤＣＰエンティティ１０１）でＰＤＣＰ状態変数を同期させることができ、上述のようなＰＤＣＰレイヤ動作を適切に実行可能になる。

実施形態に係る動作は、ＭＢＳセッションの途中からＭＢＳ受信を開始するＵＥ１００が実行する場合に限らず、他のｇＮＢ２００（他のセル）からセル変更（例えば、セル再選択又はハンドオーバ）してきたＵＥ１００が実行してもよい。セル変更元である当該他のｇＮＢ２００（他のセル）をソースと呼び、セル変更先であるｇＮＢ２００（セル）をターゲットと呼ぶ。セル間（ソース及びターゲット間）でＨＦＮが同期していない場合、ＰＴＭで送信されるＭＢＳデータを受信するＵＥ１００は、上述の実施形態に係る動作を実行してもよい。

この場合、セル間でＨＦＮが同期していないことを、ソース及び／又はターゲットからＵＥ１００へ通知してもよい。例えば、ソース及び／又はターゲットは、ＨＦＮが同期していない隣接セルのセル識別子をＵＥ１００に通知してもよい。もしくは、ソース及び／又はターゲットは、ＨＦＮが同期している隣接セルのセル識別子をＵＥ１００に通知してもよい。ＵＥ１００は、当該通知に基づいて、ターゲットに移動した際に（例えば、ターゲットからＭＢＳデータ受信を開始した際に）上述の実施形態に係る動作を実行するか否かを決定してもよい。ＵＥ１００は、当該通知に基づいて、セル間（ソース及びターゲット間）でＨＦＮが同期していないと判定した場合に限り、上述の実施形態に係る動作を実行すると決定してもよい。

（実施例）
上述の実施形態に係る動作を前提として、第１実施例乃至第４実施例について説明する。これらの実施例において、２以上の実施例を組み合わせて実施してもよい。

（１）第１実施例
第１実施例において、ＵＥ１００は、ｇＮＢ２００から最初のＰＤＣＰデータＰＤＵを受信する前に、ｇＮＢ２００からＨＦＮを受信するものとする。

第１に、ＵＥ１００は、ｇＮＢ２００から受信したＨＦＮを記憶する。第２に、ＵＥ１００は、ＨＦＮをｇＮＢ２００から受信した後に、ｇＮＢ２００から最初のＰＤＣＰデータＰＤＵを受信する。第３に、ＵＥ１００は、記憶されたＨＦＮと、最初のＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮとから、ＰＤＣＰ状態変数の初期値を決定する。

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

ステップＳ１０１において、ｇＮＢ２００は、ＭＢＳデータの現在のＨＦＮをＵＥ１００に通知する。ＵＥ１００は、当該ＨＦＮを受信する。

ステップＳ１０２において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１０１で受信したＨＦＮを（メモリに）記憶する。

ステップＳ１０３において、ＵＥ１００は、ＭＢＳデータの受信を開始する。なお、ｇＮＢ２００は、ステップＳ１０３よりも前にＭＢＳデータの送信を開始している。

ステップＳ１０４において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、最初のＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、最初のＰＤＣＰデータＰＤＵを受信する。

ステップＳ１０５において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１０４で受信した最初のＰＤＣＰデータＰＤＵのヘッダに含まれるＰＤＣＰ ＳＮを確認する。

ステップＳ１０６において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１０２で記憶したＨＦＮを（メモリから）読みだす。そして、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、読み出したＨＦＮと、ステップＳ１０５で確認したＰＤＣＰ ＳＮとから、ＰＤＣＰ状態変数の初期値を決定し、ＰＤＣＰ状態変数を初期化する。ＵＥ１００は、ＰＤＣＰ状態変数の初期化が完了した後、記憶していたＨＦＮをメモリから削除（破棄）してもよい。

ステップＳ１０７において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、２つ目以降のＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、２つ目以降のＰＤＣＰデータＰＤＵを受信する。

ステップＳ１０８において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ１０７で受信したＰＤＣＰデータＰＤＵに応じてＰＤＣＰ状態変数を更新する。

（２）第２実施例
第２実施例において、ＵＥ１００は、ｇＮＢ２００から少なくとも１つのＰＤＣＰデータＰＤＵを受信した後に、ｇＮＢ２００からＨＦＮを受信するものとする。例えば、ＰＴＭデータ送信が、他のＵＥ１００のために既に実施中の状況で、ＵＥ１００が遅れてセッションに入ってきた（受信を開始した）場合、ＨＦＮ受信よりもデータ受信の方が先になる可能性がある。

第１に、ＵＥ１００は、ＨＦＮをｇＮＢ２００から受信する前に、少なくとも１つのＰＤＣＰデータＰＤＵをｇＮＢ２００から受信する。第２に、ＵＥ１００は、当該少なくとも１つのＰＤＣＰデータＰＤＵを記憶する。第３に、ＵＥ１００は、ＨＦＮをｇＮＢ２００から受信した後に、当該ＨＦＮと、記憶されたＰＤＣＰデータＰＤＵのうち最初のＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮとから、ＰＤＣＰ状態変数の初期値を決定する。

すなわち、ＵＥ１００は、ＨＦＮが提供される前に受信したＭＢＳデータの処理を保留し（データを記憶し）、ＨＦＮが提供された時点でＰＤＣＰ状態変数の初期化を行い、データ受信処理（ＰＤＣＰ処理）を開始する。

図１７は、第２実施例に係る動作を示す図である。

ステップＳ２０１において、ＵＥ１００は、ＰＤＣＰ状態変数の初期化をまだ実施していない状況で、ＭＢＳデータの受信を開始する。

ステップＳ２０２において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、ＭＢＳデータを構成する少なくとも１つのＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、当該少なくとも１つのＰＤＣＰデータＰＤＵを受信する。

ステップＳ２０３において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰ処理を行う前の段階で、ステップＳ２０２で受信したＰＤＣＰデータＰＤＵをバッファに記憶する。例えば、受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰ処理を行う前段（具体的には、当該ＰＤＣＰエンティティの入力直後であって、上述のＰＤＣＰ受信処理を行う前の段階）にバッファを有するものとする。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０２で複数のＰＤＣＰデータＰＤＵを受信した場合、受信した順番にバッファに格納してもよい。また、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０２で複数のＰＤＣＰデータＰＤＵを受信した場合、当該ＰＤＣＰデータＰＤＵのＰＤＣＰ ＳＮが小さい（又は大きい）順に並べ替えてバッファに格納してもよい。

その後、ステップＳ２０４において、ｇＮＢ２００は、現在のＨＦＮをＵＥ１００に通知する。ＵＥ１００は、当該ＨＦＮを受信する。

ステップＳ２０５において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０４で受信したＨＦＮと、ステップＳ２０３で記憶した最初のＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮとを確認する。ここで、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０３で複数のＰＤＣＰデータＰＤＵを記憶している場合、ＰＤＣＰ ＳＮが最も小さいＰＤＣＰデータＰＤＵもしくはＰＤＣＰ ＳＮが最も大きいＰＤＣＰデータＰＤＵからＰＤＣＰ ＳＮを取得してもよい。もしくは、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、最初に受信したＰＤＣＰデータＰＤＵからＰＤＣＰ ＳＮを取得してもよい。

ステップＳ２０６において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０５で確認したＨＦＮ及びＰＤＣＰ ＳＮから、ＰＤＣＰ状態変数の初期値を決定し、ＰＤＣＰ状態変数を初期化する。

ステップＳ２０７において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０３でバッファに格納した少なくとも１つのＰＤＣＰデータＰＤＵに対して順次ＰＤＣＰ処理を行う。

ステップＳ２０８において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、ＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰデータＰＤＵを受信する。

ステップＳ２０９において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ２０８で受信したＰＤＣＰデータＰＤＵに応じてＰＤＣＰ状態変数を更新する。

（３）第３実施例
上述の第１実施例及び第２実施例において、ＰＤＣＰデータＰＤＵ及びＨＦＮが別々にｇＮＢ２００から提供されることを主として想定しており、提供されるＨＦＮとＰＤＣＰデータＰＤＵとの間に提供タイミングのギャップが発生する。そのため、ＰＤＣＰ ＳＮが一巡（ｗｒａｐ ａｒｏｕｎｄ）する近辺のタイミングでｇＮＢ２００がＨＦＮを送信すると、ｇＮＢ２００とＵＥ１００との間でＨＦＮの同期外れ（ｄｅｓｙｎｃ）が発生してしまう可能性がある。

ＰＤＣＰデータＰＤＵのヘッダ中でＨＦＮを送信することにより、このような問題を解決可能である。第３実施例において、ＵＥ１００は、ｇＮＢ２００からＰＤＣＰデータＰＤＵを受信すると同時にＨＦＮを受信する。具体的には、ＵＥ１００は、ＨＦＮを含むヘッダを有するＰＤＣＰデータＰＤＵをｇＮＢ２００から受信する。但し、当該ヘッダに常にＨＦＮを含める場合、オーバーヘッドが大きくなる。第３実施例では、ＨＦＮを動的に挿入できるような可変フォーマット（例えば、可変ヘッダ）を導入する。例えば、ＰＤＣＰデータＰＤＵのヘッダには、当該ヘッダにＨＦＮが含まれていることを示すフラグを含めることが可能な構成とする。

図１８は、第３実施例に係る動作を示す図である。ＵＥ１００は、ＰＴＭで送信されるＭＢＳデータを受信中又は受信に興味を持っているものとする。

ステップＳ３０１において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、現在のＨＦＮをヘッダに含むＰＤＣＰデータＰＤＵをＵＥ１００に送信する。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、当該ＰＤＣＰデータＰＤＵを受信する。

ステップＳ３０１に先立ち、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＨＦＮをヘッダに含むＰＤＣＰデータＰＤＵの受信を待ち受けてもよい。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、当該ＰＤＣＰデータＰＤＵを使用することをｇＮＢ２００から設定された場合に限り、当該ＰＤＣＰデータＰＤＵを待ち受けてもよい。このような設定は、ＲＲＣシグナリングによりなされてもよい。

ＨＦＮをヘッダに含むＰＤＣＰデータＰＤＵは、ＨＦＮを含まないＰＤＣＰデータＰＤＵと別のフォーマットのＰＤＣＰデータＰＤＵとして定義されてもよい。例えば、ＨＦＮ無しの場合は既存ＰＤＣＰデータＰＤＵ、ＨＦＮ有りの場合はＰＤＣＰ ＭＲＢデータＰＤＵと定義されてもよい。

ステップＳ３０２において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ３０１で受信したＰＤＣＰデータＰＤＵに含まれるＨＦＮ及びＳＮを確認する。

ステップＳ３０３において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ３０２で確認したＨＦＮ及びＰＤＣＰ ＳＮから、ＰＤＣＰ状態変数の初期値を決定し、ＰＤＣＰ状態変数を初期化する。

ステップＳ３０４において、ｇＮＢ２００の送信側ＰＤＣＰエンティティ２０１は、ＰＤＣＰデータＰＤＵをＵＥ１００に送信する。このＰＤＣＰデータＰＤＵは、ＨＦＮを含まないものであってもよい。ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ＰＤＣＰデータＰＤＵを受信する。

ステップＳ３０５において、ＵＥ１００の受信側ＰＤＣＰエンティティ１０１は、ステップＳ３０４で受信したＰＤＣＰデータＰＤＵに応じてＰＤＣＰ状態変数を更新する。

図１９は、第３実施例に係るＰＤＣＰデータＰＤＵを示す図である。図１９に示すＨＦＮ有りのＰＤＣＰデータＰＤＵは、ＰＤＣＰ ＭＲＢデータＰＤＵと定義されてもよい。なお、ＰＤＣＰ ＳＮのビット長が１２ビットである一例を示している。

図１９に示すＰＤＣＰデータＰＤＵの「Ｏｃｔ １」は、当該ＰＤＵが制御ＰＤＵであるか又はデータＰＤＵであるかを示す１ビットの「Ｄ／Ｃ」フィールドに加えて、１ビットの「Ｈ」フィールドを有する。「Ｈ」フィールドに“１”がセットされる場合、ＨＦＮ入りのフォーマットであることを示し、「Ｈ」フィールドに“０”がセットされる場合、ＨＦＮ無しのフォーマット、すなわち、既存のＰＤＣＰデータＰＤＵフォーマットであることを示す。なお、既存のＰＤＣＰデータＰＤＵでは、「Ｈ」フィールドは予約フィールド“Ｒ”であるため、通常は“０”がセットされる。図１９に示すＰＤＣＰデータＰＤＵの「Ｏｃｔ ２」乃至「Ｏｃｔ ４」の前半部分には、ＨＦＮがセットされる。図１９に示すＰＤＣＰデータＰＤＵの「Ｏｃｔ ４」の後半部分乃至「Ｏｃｔ ５」には、ＰＤＣＰ ＳＮがセットされる。そして、「Ｏｃｔ ６」からデータが格納される。

図１９に示すフォーマット例では、ＨＦＮフィールドがＰＤＣＰ ＳＮフィールドよりも前に位置しているが、ＨＦＮフィールドは、ＰＤＣＰ ＳＮフィールドよりも後に位置してもよい。また、図１９において、ＨＦＮフィールドをヘッダに設けるフォーマット例を示しているが、ＨＦＮフィールドをデータの後、もしくはＭＡＣ－Ｉフィールドの後に設けてもよい。この場合、図１９に示すフォーマットと同様に、「Ｈ」フィールドによって、ＨＦＮフィールドが付与されているか否かを通知してもよい。

（４）第４実施例
ＵＥ１００がカバレッジホールや干渉などにより一定期間ＰＴＭ受信に失敗した場合、又はＵＥ１００が別セルに入った場合（ハンドオーバ、セル再選択）において、ＵＥ１００は、ＰＤＣＰデータＰＤＵを正常に受信できなくなる虞がある。これらの場合、ＰＤＣＰ状態変数の同期が外れてしまい、現在のＨＦＮ及び／又はＰＤＣＰ ＳＮ値が分からなくなる可能性がある。

但し、受信失敗した期間がそれほど長時間でない場合、ＨＦＮはまだｇＮＢ２００と同期しているため、ＰＤＣＰ ＳＮ部の初期化だけで済む可能性がある。例えば、受信失敗時のＨＦＮをそのまま適用し、ＰＤＣＰ処理に失敗した場合は例えば「＋１」のＨＦＮを適用することにより、ＣＯＵＮＴ値がｇＮＢ２００と同期し、正常に受信が再開できる可能性がある。

しかしながら、受信失敗が長期間になった場合などの状況においては、上記の限りではない。第４実施例では、ＰＤＣＰデータＰＤＵをＵＥ１００が正常受信できない状況下において、ＵＥ１００がＰＤＣＰ状態変数の初期化を行う。

第４実施例において、ＵＥ１００は、ＭＢＳ受信の失敗が継続する時間が所定時間を超えたことを示す第１条件、及びＭＢＳ受信を連続して失敗した回数が所定回数を超えたことを示す第２条件のうち、少なくとも一方の条件が満たされたことに応じて、ＨＦＮの提供を要求する要求信号をｇＮＢ２００に送信してもよい。ＵＥ１００は、要求信号に応じてｇＮＢ２００から送信されるＨＦＮを受信する。

また、第４実施例において、ＵＥ１００は、第１条件及び第２条件のうち少なくとも一方の条件が満たされたことに応じて、初期値によってＰＤＣＰ状態変数を初期化してもよい。

図２０は、第４実施例に係る動作を示す図である。

ステップＳ４０１において、ＵＥ１００は、ｇＮＢ２００からのＭＢＳデータ受信（ＰＴＭ受信）を行う。

ステップＳ４０２において、ＵＥ１００は、ＭＢＳデータ（ＰＤＣＰデータＰＤＵ）を正常受信できないことに関する条件が満たされたか否かを判定する。例えば、ＵＥ１００は、ＭＢＳ受信の失敗が継続する時間が所定時間を超えたことを示す第１条件、及びＭＢＳ受信を連続して失敗した回数が所定回数を超えたことを示す第２条件のうち、少なくとも一方の条件が満たされたか否かを判定する。ここで、ＵＥ１００は、ＰＴＭ（－ｌｅｇ）における受信失敗のみを対象として判定を行ってもよい。

第１条件の判定において、ＵＥ１００は、タイマを用いて、一定期間受信に失敗したことを検知してもよい。例えば、ＵＥ１００は、受信失敗が継続している時間を測定する。ＵＥ１００は、受信失敗時に、タイマに一定期間（設定値）をセットしたうえでタイマを起動する。当該タイマの設定値は、ｇＮＢ２００からＵＥ１００に設定されていてもよい。ＵＥ１００は、当該タイマを、例えばＧ－ＲＮＴＩごと又はＭＴＣＨごとに別々に管理してもよい。ＵＥ１００は、受信成功時に、当該タイマを停止する。一方、当該タイマが満了した場合、ＵＥ１００は、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。

第２条件の判定において、ＵＥ１００は、カウンタを用いて、一定回数連続して受信に失敗したことを検知してもよい。例えば、ＵＥ１００は、ＭＴＣＨ受信機会ごとにカウンタを操作し、連続受信失敗回数を測定する。ＵＥ１００は、受信失敗時に、カウンタを１インクリメントする。ＵＥ１００は、当該カウンタを、例えばＧ－ＲＮＴＩごと又はＭＴＣＨごとに別々に管理してもよい。ＵＥ１００は、受信成功時に、カウンタのカウント値をゼロに初期化する。一方、当該カウンタのカウント値が閾値を超えた場合、ＵＥ１００は、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。当該閾値は、ｇＮＢ２００からＵＥ１００に設定されていてもよい。

ＵＥ１００は、タイマ及びカウンタを組み合わせた判定を行ってもよい。ＵＥ１００は、一定時間内に発生した受信失敗回数が閾値を超えた場合、ＰＤＣＰ状態変数の初期化処理を行う。例えば、ＵＥ１００は、ある時点でタイマを開始するとともにカウンタをゼロにセットする。ＵＥ１００は、タイマが動作中は、受信失敗ごとにカウンタを１インクリメントする。タイマが満了した場合、ＵＥ１００は、タイマを再起動し、カウンタをゼロにセットする。一方、カウンタが閾値を超えた場合、ＵＥ１００は、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。

ステップＳ４０２において、ＵＥ１００は、ＰＤＣＰ状態変数（ＨＦＮ、ＰＤＣＰ ＳＮ）の同期外れの可能性を検知してもよい。例えば、ＵＥ１００は、受信側ＰＤＣＰエンティティ１０１において記憶しているＣＯＵＮＴ値と、受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮから導出したＣＯＵＮＴ値とが乖離している（両ＣＯＵＮＴ値が一定以上離れている）場合、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。ここで、受信側ＰＤＣＰエンティティ１０１において記憶しているＨＦＮと受信したパケットのＰＤＣＰ ＳＮとで構成したＣＯＵＮＴ値を用いたセキュリティ処理（ｄｅｃｉｐｈｅｒｉｎｇ／ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎ）に失敗した場合、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。

ステップＳ４０２において、ＵＥ１００は、ＰＤＣＰ状態変数（ＨＦＮ、ＰＤＣＰ ＳＮ）がソースと同期していないターゲットでの受信を開始した場合、ＰＤＣＰ状態変数の初期化処理を行うことを決定してもよい。

なお、ステップＳ４０２における条件判定をＰＤＣＰ／ＲＬＣ／ＭＡＣのいずれかのレイヤで行い、判定結果をＲＲＣへ通知してもよい。

ステップＳ４０３において、ＵＥ１００は、現在のＨＦＮの提供を要求する要求信号をｇＮＢ２００に送信する。要求信号は、ＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージ又はＭＢＳ Ｉｎｔｅｒｅｓｔ ＩｎｄｉｃａｔｉｏｎメッセージなどのＲＲＣシグナリングであってもよい。また、当該要求信号は、ＰＤＣＰ制御ＰＤＵ、ＰＤＣＰデータＰＤＵ又はＭＡＣ ＣＥであってもよい。また、当該要求信号は、特別なＰＲＡＣＨリソース（特別な時間・周波数リソース又は特別なプリアンブル系列）を用いて送信するランダムアクセスプリアンブルであってもよい。ランダムアクセスプリアンブルを要求信号とする方法は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態にあるＵＥ１００にとって好適である。

要求信号としてＲＲＣシグナリング又はＭＡＣ ＣＥを用いる場合、当該要求信号は、ＨＦＮを提供して欲しいＭＲＢを識別するＭＲＢ識別子を含んでもよい。また、当該要求信号は、ＨＦＮを提供して欲しいＭＢＳセッションを識別するＭＢＳセッション識別子（例えば、ＴＭＧＩ）を含んでもよい。また、当該要求信号は、ＨＦＮを提供して欲しい論理チャネルを識別する論理チャネル識別子（ＬＣＩＤ）を含んでもよい。要求信号としてＰＤＣＰデータＰＤＵを用いる場合、当該要求信号は、ＨＦＮの提供を要求することを示すフラグビットとして“１”がセットされたヘッダを有するＰＤＣＰデータＰＤＵであってもよい。

ステップＳ４０４において、ｇＮＢ２００は、ステップＳ４０３でＵＥ１００から受信した要求信号に応じて、現在のＨＦＮをＵＥ１００に通知する。ＵＥ１００は、当該ＨＦＮを受信する。

ここで、ＨＦＮがＳＩＢ又はＭＣＣＨ等によりブロードキャストで通知される場合、要求信号を送信したＵＥ１００以外の他のＵＥ（すなわち、ＰＤＣＰ状態変数の初期化が必要ではないＵＥ）もＨＦＮを受信し得る。ＭＢＳ受信を正常に実施できている当該他のＵＥは、ＨＦＮを受信しても、当該受信したＨＦＮを無視又は破棄し、当該ＨＦＮを用いてＰＤＣＰ状態変数の初期化を行わなくてもよい。

ステップＳ４０５において、ＵＥ１００は、ステップＳ４０４で受信したＨＦＮと、受信したＰＤＣＰデータＰＤＵに含まれるＰＤＣＰ ＳＮとから、ＰＤＣＰ状態変数の初期値を決定し、ＰＤＣＰ状態変数を初期化する。その後の動作は、上述の実施例と同様である。

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

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

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

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

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

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

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

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

ＲＲＣ信号において、ＰＴＭ用のＵＭ ＲＬＣ設定のみの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 (7)

1. ＲＲＣコネクティッド状態のユーザ装置が、マルチキャスト・ブロードキャストサービス（ＭＢＳ）のマルチキャストセッションと対応付けられたＭＢＳ無線ベアラ（ＭＲＢ）を設定するための無線リソース制御（ＲＲＣ） Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをネットワークノードから受信することと、
   前記ＲＲＣ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、前記ＭＲＢと対応付けられたハイパーフレーム番号（ＨＦＮ）と、前記ＨＦＮと対応付けられたマルチキャスト無線ベアラ（ＭＲＢ）識別子と、前記ＨＦＮと対応付けられたＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ）と、を含むことと、
   前記ユーザ装置が、前記ＭＲＢについて管理するＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）状態変数を、前記ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ＨＦＮに基づいて決定することと、を有する
   通信方法。
2. 前記決定することは、受信待ちであって未だ上位レイヤに提供していないＰＤＣＰ ＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）のうち最も古いＣＯＵＮＴ値を示すＲＸ＿ＤＥＬＩＶの初期値を、前記ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ＨＦＮに基づいて決定することを含む
   請求項１に記載の通信方法。
3. 前記ＲＸ＿ＤＥＬＩＶは、前記ＨＦＮ及びＰＤＣＰシーケンス番号（ＰＤＣＰ ＳＮ）からなるＣＯＵＮＴ値を含む
   請求項２に記載の通信方法。
4. ＲＲＣコネクティッド状態において、マルチキャスト・ブロードキャストサービス（ＭＢＳ）のマルチキャストセッションと対応付けられたＭＢＳ無線ベアラ（ＭＲＢ）を設定するための無線リソース制御（ＲＲＣ） Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをネットワークノードから受信する受信部であって、前記ＲＲＣ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、前記ＭＲＢと対応付けられたハイパーフレーム番号（ＨＦＮ）と、前記ＨＦＮと対応付けられたマルチキャスト無線ベアラ（ＭＲＢ）識別子と、前記ＨＦＮと対応付けられたＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ）と、を含む、前記受信部と、
   前記ＭＲＢについて管理するＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）状態変数を、前記ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる前記ＨＦＮに基づいて決定する制御部と、を有する
   ユーザ装置。
5. ユーザ装置に用いられ、請求項１に記載の通信方法を実行する
   プロセッサ。
6. 請求項１に記載の通信方法をユーザ装置に実行させる
   プログラム。
7. 請求項４に記載のユーザ装置と、ネットワークノードとを有する
   移動通信システム。
   

Images