特許 7670807 通信制御方法及びユーザ装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-04-21

(45)【発行日】2025-04-30

(54)【発明の名称】通信制御方法及びユーザ装置

(51)【国際特許分類】

   H04W 4/06 20090101AFI20250422BHJP

   H04W 28/02 20090101ALI20250422BHJP

【ＦＩ】

H04W4/06 150

H04W28/02

【請求項の数】 6

(21)【出願番号】P 2023509210

(86)(22)【出願日】2022-03-22

(86)【国際出願番号】 JP2022013265

(87)【国際公開番号】W WO2022202833

(87)【国際公開日】2022-09-29

【審査請求日】2023-09-21

(31)【優先権主張番号】63/164,682

(32)【優先日】2021-03-23

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】000006633

【氏名又は名称】京セラ株式会社

(74)【代理人】

【識別番号】110001106

【氏名又は名称】弁理士法人キュリーズ

(72)【発明者】

【氏名】藤代 真人

(72)【発明者】

【氏名】チャン ヘンリー

【審査官】桑江 晃

(56)【参考文献】

【文献】Apple，PTM PTP switch with MBS service continuity[online]，3GPP TSG RAN WG2 #113-e R2-2101373，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_113-e/Docs/R2-2101373.zip>，2021年02月05日，１－２頁

【文献】CATT，Open Issues on Dynamic PTM and PTP Switch[online]，3GPP TSG RAN WG2 #113-e R2-2100084，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_113-e/Docs/R2-2100084.zip>，2021年02月05日，１－７頁

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｗ ４／００ － ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いる通信制御方法であって、
前記ユーザ装置が、ＰＴＰ（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ：ユニキャスト）伝送及びＰＴＭ（Ｐｏｉｎｔ－ｔｏ－Ｍｕｌｔｉｐｏｉｎｔ：マルチキャスト又はブロードキャスト）伝送のいずれかの伝送方式で前記基地局から送信されるＭＢＳデータを受信することと、
前記伝送方式が前記ＰＴＰ伝送と前記ＰＴＭ伝送との間で切り替えられたことに応じて、前記ユーザ装置が、前記切り替えに関する受信パケットのシーケンス番号を示す情報を含むメッセージを前記基地局に送信することと、を有し、
前記切り替えが、前記ＰＴＰ伝送から前記ＰＴＭ伝送への切り替えである場合、
前記メッセージを送信することは、前記ＰＴＭ伝送でＭＢＳデータを受信した後に、前記メッセージを送信することを含み、
前記メッセージは、前記ＰＴＭ伝送で最初に受信したパケットのシーケンス番号を示す情報、及び前記ＰＴＰ伝送で最後に受信したいパケットのシーケンス番号を示す情報のうち、少なくとも一方を含む
通信制御方法。

【請求項2】

前記メッセージを送信することは、前記ＰＴＰ伝送と前記ＰＴＭ伝送との間のシーケンス番号のギャップを前記ユーザ装置が検知したことに応じて前記メッセージを送信することを含む
請求項１に記載の通信制御方法。

【請求項3】

前記基地局が、前記メッセージに基づいて、前記ＰＴＰ伝送と前記ＰＴＭ伝送との間のシーケンス番号のギャップと対応する１つ又は複数のパケットを前記ＰＴＰ伝送で前記ユーザ装置に送信することをさらに有する
請求項１に記載の通信制御方法。

【請求項4】

前記切り替えが、前記ＰＴＭ伝送から前記ＰＴＰ伝送への切り替えである場合、
前記メッセージは、前記ＰＴＭ伝送で最後に受信したパケットのシーケンス番号を示す情報、及び前記ＰＴＰ伝送で最初に受信したいパケットのシーケンス番号を示す情報のうち、少なくとも一方を含む
請求項１又は２に記載の通信制御方法。

【請求項5】

前記基地局が、前記メッセージに基づいて、前記ＰＴＰ伝送における送信開始パケットのシーケンス番号を決定することをさらに有する
請求項４に記載の通信制御方法。

【請求項6】

請求項１に記載の通信制御方法を実行するプロセッサを備える
ユーザ装置。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

近年、第５世代（５Ｇ）の移動通信システムが注目されている。５Ｇシステムの無線アクセス技術（ＲＡＴ：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）は、第４世代の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。

【先行技術文献】

【非特許文献】

【0003】

【文献】３ＧＰＰ技術仕様書「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．３．０ （２０２０－０９）」

【発明の概要】

【0004】

第１の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いる方法である。前記通信制御方法は、前記ユーザ装置が、ＰＴＰ伝送及びＰＴＭ伝送のいずれかの伝送方式で前記基地局から送信されるＭＢＳデータを受信することと、前記伝送方式が前記ＰＴＰ伝送と前記ＰＴＭ伝送との間で切り替えられたことに応じて、前記ユーザ装置が、前記切り替えに関する受信パケットのシーケンス番号を示す情報を含むメッセージを前記基地局に送信することと、を有する。

【0005】

第２の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いる方法である。前記通信制御方法は、前記ユーザ装置が、前記基地局からＰＴＭ通信パスを介して送信されるＭＢＳデータの受信を試行するＰＴＭモニタ動作を行うことと、前記ユーザ装置が、前記ＰＴＭ通信パスの通信品質を示す測定値の劣化を検知したことに応じて、前記ＰＴＭモニタ動作を停止することと、を有する。

【0006】

第３の態様に係るユーザ装置は、第１又は第２の態様に係る通信制御方法を実行するプロセッサを備える。

【図面の簡単な説明】

【0007】

【図1】一実施形態に係る移動通信システムの構成を示す図である。

【図2】一実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。

【図3】一実施形態に係るｇＮＢ（基地局）の構成を示す図である。

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

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

【図6】一実施形態に係る下りリンクの論理チャネル（Ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ）とトランスポートチャネル（Ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ）との対応関係を示す図である。

【図7】一実施形態に係るＭＢＳデータの配信方法を示す図である。

【図8】一実施形態に係るスプリットＭＢＳベアラを示す図である。

【図9】一実施形態に係るレグのアクティブ化及び非アクティブ化に関する動作例を示す図である。

【図10】一実施形態に係るＰＴＰ伝送からＰＴＭ伝送への切り替えの動作例を示す図である。

【図11】一実施形態に係るＳＮ通知メッセージの構成例を示す図である。

【図12】一実施形態に係るＰＴＭ伝送からＰＴＰ伝送への切り替えの動作例を示す図である。

【図13】一実施形態に係るＰＴＭモニタ動作に関する動作例を示す図である。

【図14】現在の合意に基づくＰＤＣＰアンカーＰＴＭ／ＰＴＰ切り替えを示す図である。

【図15】合意に基づくＰＤＣＰアンカーＰＴＭ ＲＬＣ－ＵＭ／ＰＴＰ ＲＬＣ－ＵＭ切り替えを示す図である。

【図16】ＰＴＭ ＲＬＣ－ＵＭ＋ＰＴＰ ＲＬＣ－ＡＭのＡ１＋Ｂ１の例を示す図である。

【図17】ＰＴＭ ＲＬＣ－ＵＭ＋ＰＴＰ ＲＬＣ－ＡＭのＡ２＋Ｂ１の例を示す図である。

【図18】ＰＴＭ ＲＬＣ－ＡＭ＋ＰＴＰ ＲＬＣ－ＡＭのＡ３＋Ｂ２（＋Ｂ１）の例を示す図である。

【図19】Ｌ２の信頼性のための可能なオプションの要約を示す図である。

【発明を実施するための形態】

【0008】

５Ｇシステム（ＮＲ）にマルチキャスト・ブロードキャストサービスを導入することが検討されている。ＮＲのマルチキャスト・ブロードキャストサービスは、ＬＴＥのマルチキャスト・ブロードキャストサービスよりも改善されたサービスを提供することが望まれる。

【0009】

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

【0010】

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

【0011】

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

【0012】

図１に示すように、移動通信システムは、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００と、５Ｇの無線アクセスネットワーク（ＮＧ－ＲＡＮ：Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０と、５Ｇのコアネットワーク（５ＧＣ：５Ｇ Ｃｏｒｅ Ｎｅｔｗｏｒｋ）２０とを有する。

【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】

このオプションは、図１６のように解釈できる。

【0178】

Ｌ２の信頼性はＰＴＰレグによってのみ保証されることが考えられる。たとえば、無線状態が悪化すると、データ受信はＰＴＭレグからＰＴＰレグに切り替わる。つまり、ＰＴＭレグは、無線状態が良好で安定している場合にのみ使用できる。

【0179】

Ａ１＋Ｂ１オプションの場合、Ｌ２の信頼性はＰＴＰレグによって保証されるが、ＰＴＭレグは、無線状態が良好で安定している場合にのみ使用できる。このオプションは、既存のＲＬＣ機能、つまりＰＴＰレグのＡＭモードとＰＴＭレグのＵＭモードを再利用できると想定されるため、ＰＤＣＰレイヤ内での影響は限定的である。

【0180】

Ａ１＋Ｂ１オプションの場合、ＰＤＣＰ仕様は影響を受けるが、ＲＬＣ仕様は影響を受けないと予想される。

【0181】

オプション名、つまり「切り替え手順でのある種のデータ回復」に示されているように、このオプションは、切り替え手順中に送信される現在のＰＤＣＰステータスレポートに基づいていると想定される。ＰＤＣＰステータスレポートは、ＰＴＭレグではなくＰＴＰレグを介して送信できることは明らかである。

【0182】

現在のＰＤＣＰ仕様では、受信側のＰＤＣＰエンティティは次のようにＰＤＣＰステータスレポートをトリガする。

【0183】

ＵＬでＰＤＣＰステータスレポートを送信するように上位層によって設定されたＡＭＤＲＢ（ＴＳ ３８．３３１ のｓｔａｔｕｓＲｅｐｏｒｔＲｅｑｕｉｒｅｄ）の場合、受信側ＰＤＣＰエンティティは次の場合にＰＤＣＰステータスレポートをトリガする必要がある。
・上位層はＰＤＣＰエンティティの再確立を要求する
・上位層はＰＤＣＰデータリカバリを要求する
・上位層はＵＬデータ切り替えを要求する
・上位層は、ＤＡＰＳと、ＴＳ ３８．３３１で設定されているｄａｐｓ－ＳｏｕｒｃｅＲｅｌｅａｓｅを解放するようにＰＤＣＰエンティティを再設定する。

【0184】

最初の条件、つまり「上位層がＰＤＣＰエンティティの再確立を要求する」に関しては、ｇＮＢ内の単一のＰＤＣＰエンティティが、ＰＴＰレグまたはＰＴＭレグのどちらに関連付けられているかに関係なく、複数のＵＥで確立されているため、ＭＲＢ（マルチキャスト無線ベアラ）のＰＤＣＰエンティティを簡単に再確立することはできない。

【0185】

２番目の条件、つまり「上位層がＰＤＣＰデータの回復を要求する」に関しては、ハンドオーバーなどのＵＬの再送信に関連するＰＤＣＰデータの回復手順に関連付けられている。したがって、ＤＬデータ送信しかないためＮＲ ＭＢＳには、関連付けられていない。

【0186】

３番目と４番目の条件、つまり「上位層がＵＬデータスイッチングを要求する」および「上位層が設定されているＤＡＰＳとｄａｐｓ－ＳｏｕｒｃｅＲｅｌｅａｓｅを解放するためにＰＤＣＰエンティティを再設定する」に関しては、これらはＤＡＰＳハンドオーバーに関連している。したがって、これらはＰＴＭ／ＰＴＰ切り替えには使用されない。

【0187】

上記の所見に基づいて、既存の条件をＰＴＭ／ＰＴＰ切り替え中のデータ回復に使用することはできない。したがって、ＰＤＣＰステータスレポートを送信するには、新しいトリガ条件が必要になる。新しいトリガ条件は、スイッチング時ではなく、アクティブ化されたレグを介して受信された最初のパケット、たとえば、ＰＴＭ/ＰＴＰ切り替えの場合のＰＴＰレグである可能性がある。

【0188】

Ａ１＋Ｂ１オプションの場合、ＰＴＭ／ＰＴＰ切り替え中にＰＤＣＰステータスレポート（またはフィードバック用の新しいＰＤＣＰ制御ＰＤＵ）を送信するために、新しいトリガ条件が必要になる場合がある。ＰＤＣＰステータスレポートは、Ｆｉｒｓｔ Ｍｉｓｓｉｎｇ ＣＯＵＮＴを示すＦＭＣと、オプションで次のＰＤＣＰ ＳＤＵが正しく受信されたか欠落しているかをビット位置ごとに示すビットマップで設定される。私たちの理解では、このオプションに再利用することもできるが、現時点でフィードバック用の新しいＰＤＣＰ制御ＰＤＵを導入することを妨げるものではない。

【0189】

Ａ１＋Ｂ１オプションの場合、既存のＰＤＣＰステータスレポートの形式を再利用できる。

【0190】

ＰＴＭ ＲＬＣ－ＵＭ＋ＰＴＰ ＲＬＣ－ＡＭのＡ２＋Ｂ１
このオプションは、図１７のように解釈できる。

【0191】

ＰＴＭレグまたはＰＴＰレグのいずれかを使用し、ＰＴＭレグから欠落しているパケットを補うことが考えられる。無線状態が比較的悪い場合、及び／又は不安定な場合でもＰＴＭレグを使用できるため、上記のＡ１＋Ｂ１オプションと比較してスペクトル効率が向上する。

【0192】

Ａ２＋Ｂ１オプションの場合、Ｌ２の信頼性はＰＴＰレグ支援によって保証できるため、無線状態が比較的悪く不安定な場合でもＰＴＭレグを使用できる。上記のＡ１＋Ｂ１オプションと同様に、このオプションはＲＬＣレイヤに影響を与えないと予想されるため、仕様への影響はＰＤＣＰレイヤ内で制限される。

【0193】

Ａ２＋Ｂ１オプションの場合、ＰＤＣＰ仕様は影響を受けるが、ＲＬＣ仕様は影響を受けないと予想される。Ａ２は、図１７に示すように「ＰＴＭ用ＰＤＣＰによるＬ２ ＡＲＱ」を意図しているが、既存のＡＲＱ機能はＲＬＣ層にあるが、ＰＤＣＰ層にはない。したがって、ＰＤＣＰ仕様に新しいＡＲＱ機能が必要であることは明らかである。

【0194】

Ａ２＋Ｂ１オプションの場合、ＰＤＣＰレイヤで新しいＡＲＱ機能を指定する必要がある。これは、ＲＬＣ仕様のベースラインＡＲＱ機能であると見なすことができる。たとえば、手順についてはセクション５．３、ＳＴＡＴＵＳ ＰＤＵ形式については６．２．２．５である。これはＡＣＫ／ＮＡＣＫタイプのＡＲＱメカニズムであり、フィードバックはＳＴＡＴＵＳ ＰＤＵを介して送信される。

【0195】

現在のＲＬＣ仕様では、ＳＴＡＴＵＳ ＰＤＵは次の２つの条件によってトリガされる。

【0196】

ＡＭ ＲＬＣエンティティは、ＲＬＣ ＳＤＵ（またはそれらの一部）の肯定的および／または否定的な確認応答を提供するために、ステータスＰＤＵを同等のＡＭＲＬＣエンティティに送信する。ステータスレポートを開始するトリガは次のとおりである。
・ピアのＡＭＲＬＣエンティティからのポーリング
・ＡＭＤＰＤＵの受信障害の検出

【0197】

最初の条件、つまり「同等のＡＭ ＲＬＣエンティティからのポーリング」に関しては、ｇＮＢが１つまたは複数のＵＥにポーリングを送信する可能性があるため再利用できるが、ＰＤＣＰデータＰＤＵにポーリングビット（Ｐ）フィールドを追加する必要がある場合がある。

【0198】

２番目の条件、つまり「ＡＭＤ ＰＤＵの受信障害の検出」に関しては、ＵＥがＰＤＣＰの受信障害を何らかの方法で検出する可能性があるため、この概念を再利用できる。現在、ｔ－Ｒｅａｓｓｅｍｂｌｙの有効期限が切れるとＲＬＣで検出されるが、ＰＤＣＰで受信障害を検出する方法についての議論が必要になる場合がある。ＲＬＣ ＡＲＱメカニズムが再利用される場合、以下のＡ３＋Ｂ２オプションで同じ最適化が期待される。例えば、受信ウィンドウを強制的に移動させる追加の条件等である。

【0199】

Ａ２＋Ｂ１オプションの場合、ＳＴＡＴＵＳ ＰＤＵの形式を含むＲＬＣ ＡＲＱメカニズムをＰＤＣＰ ＡＲＱのベースラインにすることができるが、受信障害の検出方法など、詳細を変更する必要がある。別の可能性として、当たり障りのない新しいＡＲＱメカニズムを検討することができる。これは、一種のＮＡＣＫのみのＡＲＱメカニズムと見なすことができる。この場合、ＦＭＣのみが報告されると仮定すると、現在のＰＤＣＰステータスレポートがベースラインになる可能性がある。上記のＡ１＋Ｂ１オプションと同様に、ＰＤＣＰステータスレポート（または新しいＰＤＣＰ制御ＰＤＵ）には新しいトリガ条件が必要である。また、上記のＲＬＣ ＡＲＱベースラインと同様に、受信障害を検出する方法、及び又は導入された場合の受信ウィンドウの管理方法について議論する必要がある。

【0200】

Ａ２＋Ｂ１オプションの場合、ＰＤＣＰステータスレポート（またはフィードバック用の新しいＰＤＣＰ制御ＰＤＵ）をＰＤＣＰ ＡＲＱの別のベースラインにすることができるが、受信障害の検出方法、及び／又は受信ウィンドウの管理方法など、新しいトリガ条件と関連する動作を指定する必要がある場合がある。

【0201】

ＰＴＭ ＲＬＣ－ＡＭ＋ＰＴＰ ＲＬＣ－ＡＭのＡ３＋Ｂ２（＋Ｂ１）
このオプションは、図１８のように解釈できる。

【0202】

上記のＡ２＋Ｂ１オプションと同様に、ＰＴＭレグまたはＰＴＰレグのいずれかを使用して、ＰＴＭレグから欠落しているパケットを補うと考えることができる。無線状態が比較的悪い場合、及び／又は不安定な場合でもＰＴＭレグを使用できるため、上記のＡ１＋Ｂ１オプションと比較してスペクトル効率が向上する。さらに、再送信はＲＬＣセグメントごとに実行できる。これは、ＰＤＣＰ ＳＤＵごとの再送信を実行する上記のＡ２＋Ｂ１オプションとは異なる。したがって、このオプションは、スペクトル効率の観点から、候補オプションの中で最高のパフォーマンスと見なすことができる。

【0203】

Ａ３＋Ｂ２オプションの場合、Ｌ２の信頼性はＰＴＰレグ支援によって保証できるため、無線状態が比較的悪く不安定な場合でもＰＴＭレグを使用できる。

【0204】

Ａ３＋Ｂ２オプションの場合、ＲＬＣセグメントごとに再送信を実行できる。他のオプションとは異なり、ＰＴＰレグとＰＴＭレグはＲＬＣレイヤにアンカーされている。したがって、このオプションは基本的にＰＤＣＰ仕様に影響を与えないが、上記のＡ１＋Ｂ１オプションがこのオプションで使用されるかどうかによって異なる。つまり、この場合、ＰＤＣＰ仕様で同じ影響が予測される可能性がある。

【0205】

Ａ３＋Ｂ２オプションの場合、ＰＤＣＰ仕様は影響を受けるとは予想されないが、他のオプションを一緒に使用するかどうかによって異なる。

【0206】

主要な影響はＲＬＣ仕様に導入されていると考えることができる。ただし、少なくともＡＲＱについては、主にｇＮＢの実装に依存しているため、影響はない（または軽微である）と予想される。実際には、すべてのＵＥが最後に欠落しているすべてのＲＬＣ ＰＤＵを時間内に受信できれば、受信ウィンドウに問題がないため、既存のＡＲＱをそのまま再利用することも可能である。再送信はＰＴＭレグに加えてＰＴＰレグを介して実行できるため、ＰＴＰレグは、Ｂ１に関連する他のオプションの基本的な仮定であるため十分に信頼できると見なすことができる。ただし、エラーの場合に、受信ウィンドウ（ＲＸ＿Ｎｅｘｔ）を強制的に移動させるための新しい条件のいくつかが提案されている。

【0207】

Ａ３＋Ｂ２オプションの場合、ＲＬＣ仕様は影響なし（または軽微）であると予想される。
（要約）
所見の結果を図１９にまとめている。

【0208】

Ａ２＋Ｂ１オプションは、他のオプション、つまりＡ１＋Ｂ１オプションとＡ３＋Ｂ２オプションに比べてメリットが少ないことは明らかである。Ａ３＋Ｂ２オプションは最良のアプローチと見なすことができるが、一方、ＲＡＮ２には、「動作の前提：ＰＴＭ用のＲＬＣ－ＡＭはサポートされていない（再検討できるが、これを変更するには、ＰＴＭ用のＲＬＣ－ＡＭの支持者が必要性を示す必要があることを意味する）。」、これは技術的な理由の観点から再検討する必要がある。

【0209】

ＲＡＮ２は、Ａ１＋Ｂ１（つまり、スイッチング中のＰＤＣＰアンカーおよびデータリカバリ）、及び／又はＡ３＋Ｂ２（つまり、ＰＴＭのＲＬＣアンカーおよびＲＬＣ ＡＭ）を導入することに同意する必要がある。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】