(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-02
(45)【発行日】2024-09-10
(54)【発明の名称】通信制御方法、ユーザ装置及びプロセッサ
(51)【国際特許分類】
H04W 4/06 20090101AFI20240903BHJP
H04W 80/02 20090101ALI20240903BHJP
H04W 28/04 20090101ALI20240903BHJP
【ＦＩ】
H04W4/06
H04W80/02
H04W28/04 110
【請求項の数】
3
(21)【出願番号】P 2023078854
(22)【出願日】2023-05-11
(62)【分割の表示】P 2022541541の分割
【原出願日】2021-08-02
(65)【公開番号】P2023100957
(43)【公開日】2023-07-19
【審査請求日】2023-05-11
(31)【優先権主張番号】P 2020132044
(32)【優先日】2020-08-03
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
【審査官】吉倉 大智
(56)【参考文献】
【文献】韓国公開特許第１０－２０２０－００７３６２６（ＫＲ，Ａ）
【文献】特開２０１１－２５４５０７（ＪＰ，Ａ）
【文献】特表２０１１－５１４７０５（ＪＰ，Ａ）
【文献】Huawei，RLC SN reset and UM Window for MBMS[online]，3GPP TSG-RAN WG2♯67bis R2-095510，2009年10月06日，Internet ＜URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_67bis/Docs/R2-095510.zip＞
【文献】Hytera Communications Corp.，Dynamic Configuration of MBSFN areas for MC service[online]，3GPP TSG RAN WG2 #98 R2-1705086，2017年05月07日，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_98/Docs/R2-1705086.zip>
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－ ７／２６
Ｈ０４Ｗ ４／００－９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いる通信制御方法であって、前記ユーザ装置が、前記基地局からＭＢＳデータを受信することと、
前記ユーザ装置のＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）エンティティが、前記基地局から最初に受信したＭＢＳデータのシーケンス番号を、所定ＲＬＣ動作に用いる変数の初期値として設定することと、を有する
通信制御方法。
【請求項2】
ユーザ装置であって、基地局からマルチキャスト・ブロードキャストサービス（ＭＢＳ）データを受信する受信部と、
前記基地局から最初に受信したＭＢＳデータのシーケンス番号を、所定ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）動作に用いる変数の初期値として設定する制御部と、を備える
ユーザ装置。
【請求項3】
ユーザ装置を制御するプロセッサであって、基地局からマルチキャスト・ブロードキャストサービス（ＭＢＳ）データを受信する処理と、
前記基地局から最初に受信したＭＢＳデータのシーケンス番号を、所定ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）動作に用いる変数の初期値として設定する処理と、を実行する
プロセッサ。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、移動通信システムで用いる通信制御方法、ユーザ装置及びプロセッサに関する。
【背景技術】
【0002】
近年、第５世代（５Ｇ）の移動通信システムが注目されている。５Ｇシステムの無線アクセス技術（ＲＡＴ：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ）であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）は、第４世代の無線アクセス技術であるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に比べて、高速・大容量かつ高信頼・低遅延といった特徴を有する。
【先行技術文献】
【非特許文献】
【0003】
【文献】３ＧＰＰ技術仕様書「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．２．０ （２０２０－０７）」
【発明の概要】
【0004】
第１の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いる通信制御方法であって、前記基地局から前記ユーザ装置に対して、前記ユーザ装置のＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）エンティティに関する設定を行うためのメッセージを送信することを有し、前記メッセージは、ＭＢＳデータを伝送するＭＢＳトラフィックチャネルに対する前記ＲＬＣエンティティの動作モードを指定する情報要素を含む。
【0005】
第２の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いる通信制御方法であって、前記ユーザ装置が、前記基地局からＭＢＳデータを受信することと、前記ユーザ装置のＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）エンティティが、前記基地局から最初に受信したＭＢＳデータのシーケンス番号を、所定ＲＬＣ動作に用いる変数の初期値として設定することとを有する。
【0006】
第３の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いる通信制御方法であって、前記ユーザ装置が、前記基地局からＭＢＳデータを受信することと、前記ユーザ装置のＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）エンティティが、前記ＭＢＳデータに対するＭＢＳ受信処理を行うことと、を有し、前記ＭＢＳ受信処理を行うことは、前記ＰＤＣＰエンティティが暗号解除処理及びヘッダ圧縮解除処理の少なくとも一方を行わずに、前記ＰＤＣＰエンティティが重複パケット破棄処理及びパケット並べ替え処理の少なくとも一方を行うことを含む。
【0007】
第４の態様に係る通信制御方法は、基地局からユーザ装置に対してマルチキャスト・ブロードキャストサービス（ＭＢＳ）を提供する移動通信システムで用いる通信制御方法であって、前記ユーザ装置が、第１セルからＭＢＳデータを受信することと、前記ユーザ装置が、前記第１セルから第２セルへのハンドオーバを行うことと、前記ユーザ装置のＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）エンティティが、前記ハンドオーバの際に前記ＭＢＳデータの受信に失敗した場合、受信に失敗したＭＢＳデータを示すシーケンス番号を前記第２セルに送信することとを有する。
【図面の簡単な説明】
【0008】
【図1】実施形態に係る移動通信システムの構成を示す図である。
【図2】実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。
【図3】実施形態に係るｇＮＢ（基地局）の構成を示す図である。
【図4】データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
【図5】シグナリング（制御信号）を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
【図6】実施形態に係る下りリンクの論理チャネル（Ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ）とトランスポートチャネル（Ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ）との対応関係を示す図である。
【図7】第１実施形態に係る動作の一例を示す図である。
【図8】第１実施形態に係る動作の具体例を示す図である。
【図9】第１実施形態に係るＲＬＣ動作を示す図である。
【図10】第１実施形態に係るＡＭのＲＬＣ動作を示す図である。
【図11】第１実施形態に係るＵＭのＲＬＣ動作を示す図である。
【図12】第２実施形態に係るＰＤＣＰ動作モードを説明するための図である。
【図13】第２実施形態に係るＰＤＣＰ動作モードを説明するための図である。
【図14】第２実施形態に係るＰＤＣＰ動作の一例を示す図である。
【図15】第２実施形態に係るハンドオーバ動作を示す図である。
【図16】第２実施形態に係るハンドオーバ動作の他の例を示す図である。
【発明を実施するための形態】
【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】
本願は、日本国特許出願第２０２０－１３２０４４号（２０２０年８月３日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】