5Gシステム(NR)にマルチキャスト・ブロードキャストサービスを導入することが検討されている。NRのマルチキャスト・ブロードキャストサービスは、LTEのマルチキャスト・ブロードキャストサービスよりも改善されたサービスを提供することが望まれる。
そこで、本開示は、改善されたマルチキャスト・ブロードキャストサービスを実現することを目的とする。
図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
(移動通信システムの構成)
まず、実施形態に係る移動通信システムの構成について説明する。
図1は、一実施形態に係る移動通信システムの構成を示す図である。この移動通信システムは、3GPP規格の第5世代システム(5GS:5th Generation System)に準拠する。以下において、5GSを例に挙げて説明するが、移動通信システムにはLTE(Long Term Evolution)システム及び/又は第6世代(6G)システムが少なくとも部分的に適用されてもよい。
図1に示すように、移動通信システムは、ユーザ装置(UE:User Equipment)100と、5Gの無線アクセスネットワーク(NG-RAN:Next Generation Radio Access Network)10と、5Gのコアネットワーク(5GC:5G Core Network)20とを有する。
UE100は、移動可能な無線通信装置である。UE100は、ユーザにより利用される装置であればどのような装置であっても構わない。例えば、UE100は、携帯電話端末(スマートフォンを含む)、タブレット端末、ノートPC、通信モジュール(通信カード又はチップセットを含む)、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置(Vehicle UE)、及び/又は飛行体若しくは飛行体に設けられる装置(Aerial UE)である。
NG-RAN10は、基地局(5Gシステムにおいて「gNB」と呼ばれる)200を含む。gNB200は、基地局間インターフェイスであるXnインターフェイスを介して相互に接続される。gNB200は、1又は複数のセルを管理する。gNB200は、自セルとの接続を確立したUE100との無線通信を行う。gNB200は、無線リソース管理(RRM)機能、ユーザデータ(以下、単に「データ」という)のルーティング機能、及び/又はモビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、UE100との無線通信を行う機能又はリソースを示す用語としても用いられる。1つのセルは1つのキャリア周波数に属する。
なお、gNBがLTEのコアネットワークであるEPC(Evolved Packet Core)に接続することもできる。LTEの基地局が5GCに接続することもできる。LTEの基地局とgNBとが基地局間インターフェイスを介して接続されることもできる。
5GC20は、AMF(Access and Mobility Management Function)及びUPF(User Plane Function)300を含む。AMFは、UE100に対する各種モビリティ制御等を行う。AMFは、NAS(Non-Access Stratum)シグナリングを用いてUE100と通信することにより、UE100のモビリティを管理する。UPFは、データの転送制御を行う。AMF及びUPFは、基地局-コアネットワーク間インターフェイスであるNGインターフェイスを介してgNB200と接続される。
図2は、一実施形態に係るUE100(ユーザ装置)の構成を示す図である。
図2に示すように、UE100は、受信部110、送信部120、及び制御部130を備える。
受信部110は、制御部130の制御下で各種の受信を行う。受信部110は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部130に出力する。
送信部120は、制御部130の制御下で各種の送信を行う。送信部120は、アンテナ及び送信機を含む。送信機は、制御部130が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
制御部130は、UE100における各種の制御を行う。制御部130は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPU(Central Processing Unit)とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。
図3は、一実施形態に係るgNB200(基地局)の構成を示す図である。
図3に示すように、gNB200は、送信部210、受信部220、制御部230、及びバックホール通信部240を備える。
送信部210は、制御部230の制御下で各種の送信を行う。送信部210は、アンテナ及び送信機を含む。送信機は、制御部230が出力するベースバンド信号(送信信号)を無線信号に変換してアンテナから送信する。
受信部220は、制御部230の制御下で各種の受信を行う。受信部220は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号(受信信号)に変換して制御部230に出力する。
制御部230は、gNB200における各種の制御を行う。制御部230は、少なくとも1つのプロセッサ及び少なくとも1つのメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、CPUとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。CPUは、メモリに記憶されるプログラムを実行して各種の処理を行う。
バックホール通信部240は、基地局間インターフェイスを介して隣接基地局と接続される。バックホール通信部240は、基地局-コアネットワーク間インターフェイスを介してAMF/UPF300と接続される。なお、gNBは、CU(Central Unit)とDU(Distributed Unit)とで構成され(すなわち、機能分割され)、両ユニット間はF1インターフェイスで接続されてもよい。
図4は、データを取り扱うユーザプレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
図4に示すように、ユーザプレーンの無線インターフェイスプロトコルは、物理(PHY)レイヤと、MAC(Medium Access Control)レイヤと、RLC(Radio Link Control)レイヤと、PDCP(Packet Data Convergence Protocol)レイヤと、SDAP(Service Data Adaptation Protocol)レイヤとを有する。
PHYレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。UE100のPHYレイヤとgNB200のPHYレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
MACレイヤは、データの優先制御、ハイブリッドARQ(HARQ:Hybrid Automatic Repeat reQuest)による再送処理、及びランダムアクセスプロシージャ等を行う。UE100のMACレイヤとgNB200のMACレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。gNB200のMACレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式(MCS))及びUE100への割当リソースブロックを決定する。
RLCレイヤは、MACレイヤ及びPHYレイヤの機能を利用してデータを受信側のRLCレイヤに伝送する。UE100のRLCレイヤとgNB200のRLCレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
PDCPレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
SDAPレイヤは、コアネットワークがQoS(Quality of Service)制御を行う単位であるIPフローとAS(Access Stratum)がQoS制御を行う単位である無線ベアラとのマッピングを行う。なお、RANがEPCに接続される場合は、SDAPが無くてもよい。
図5は、シグナリング(制御信号)を取り扱う制御プレーンの無線インターフェイスのプロトコルスタックの構成を示す図である。
図5に示すように、制御プレーンの無線インターフェイスのプロトコルスタックは、図4に示したSDAPレイヤに代えて、RRC(Radio Resource Control)レイヤ及びNAS(Non-Access Stratum)レイヤを有する。
UE100のRRCレイヤとgNB200のRRCレイヤとの間では、各種設定のためのRRCシグナリングが伝送される。RRCレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。UE100のRRCとgNB200のRRCとの間に接続(RRC接続)がある場合、UE100はRRCコネクティッド状態にある。UE100のRRCとgNB200のRRCとの間に接続(RRC接続)がない場合、UE100はRRCアイドル状態にある。UE100のRRCとgNB200のRRCとの間の接続がサスペンドされている場合、UE100はRRCインアクティブ状態にある。
RRCレイヤの上位に位置するNASレイヤは、セッション管理及びモビリティ管理等を行う。UE100のNASレイヤとAMF300BのNASレイヤとの間では、NASシグナリングが伝送される。
なお、UE100は、無線インターフェイスのプロトコル以外にアプリケーションレイヤ等を有する。
(MBS)
次に、一実施形態に係るMBSについて説明する。
MBSは、NG-RAN10からUE100に対してブロードキャスト又はマルチキャスト、すなわち、1対多(PTM:Point To Multipoint)でのデータ送信を可能とするサービスである。MBSのユースケース(サービス種別)としては、公安通信、ミッションクリティカル通信、V2X(Vehicle to Everything)通信、IPv4又はIPv6マルチキャスト配信、IPTV、グループ通信、及びソフトウェア配信等が想定される。
ブロードキャストサービスは、高信頼性のQoSを必要としないアプリケーションのために、特定のサービスエリア内のすべてのUE100に対してサービスを提供する。マルチキャストサービスは、すべてのUE100に対してではなく、マルチキャストサービスに参加しているUE100のグループに対してサービスを提供する。マルチキャストサービスによれば、ブロードキャストサービスに比べて、無線効率の高い方法でUE100のグループに対して同じコンテンツを提供できる。
図6は、一実施形態に係るMBSトラフィック配信の概要を示す図である。
図6に示すように、MBSトラフィックは、単一のデータソース(アプリケーションサービスプロバイダ)から複数のUEに配信される。5Gコアネットワークである5G CN(5GC)20は、アプリケーションサービスプロバイダからMBSトラフィックを受信し、MBSトラフィックのコピーの作成(Replication)を行って配信する。
5GC20の観点からは、5GC共有MBSトラフィック配信(5GC Shared MBS Traffic delivery)及び5GC個別MBSトラフィック配信(5GC Individual MBS Traffic delivery)の2つのマルチキャスト配信方法が可能である。
5GC個別MBSトラフィック配信方法では、5GC20は、MBSデータパケットの単一コピーを受信し、UE100ごとのPDU(Protocol Data Unit)セッションを介してそれらのMBSデータパケットの個別のコピーを個別のUE100に配信する。したがって、UE100ごとに1つのPDUセッションをマルチキャストセッションと関連付ける必要がある。
5GC共有MBSトラフィック配信方法では、第1に、5GC20は、MBSデータパケットの単一コピーを受信し、それらのMBSデータパケットの単一コピーをRANノード(すなわち、gNB200)に配信する。第2に、gNB200は、それらを1つ又は複数のUE100に配信する。
RAN(5G RAN)10の観点からは、5GC共有MBSトラフィック配信方法における無線を介したMBSトラフィックの送信には、PTP(Point-to-Point)及びPTM(Point-to-Multipoint)の2つの配信方法が可能である。
PTP配信方法では、gNB200は、MBSデータパケットの個別のコピーを無線で個々のUE100に配信する。他方、PTM配信方法では、gNB200は、MBSデータパケットの単一コピーを無線でUE100のグループに配信する。gNB200は、1つのUE100に対するMBSトラフィックの配信方法としてPTM及びPTPのどちらを用いるかを動的に決定する。
PTP配信方法及びPTM配信方法は主としてユーザプレーンに関するものである。MBSトラフィック配信の制御モードとしては、配信モード1及び配信モード2の2つの配信モードがある。図7は、一実施形態に係る配信モードを示す図である。
図7に示すように、配信モード1(Delivery mode 1)は、RRCコネクティッド状態のUE100が利用できる配信モードであって、高QoS要件のための配信モードである。配信モード1は、MBSセッションのうちマルチキャストセッションにのみ用いられる。一実施形態において、配信モード1がマルチキャストセッションに用いられることを想定するが、配信モード1がブロードキャストセッションに用いられてもよい。配信モード1は、RRCアイドル状態又はRRCインアクティブ状態のUE100も利用可能であってもよい。
一実施形態において、配信モード1におけるMBS受信の設定は、gNB200からUE100にユニキャストで送信されるRRCメッセージであるRRC Reconfigurationメッセージ(又はRRC Releaseメッセージ)により行われる。MBS受信の設定は、MBSトラフィックを運ぶMBSトラフィックチャネルのスケジューリング情報を含む。論理チャネルの一種であるMBSトラフィックチャネルは、MTCH(Multicast Traffic Channel)と呼ばれることがある。MBSトラフィックチャネルは、トランスポートチャネルの一種であるDL-SCH(Downlink Shared Channel)にマッピングされる。
配信モード2(Delivery mode 2)は、RRCコネクティッド状態のUE100だけではなく、RRCアイドル状態又はRRCインアクティブ状態のUE100が利用できる配信モードであって、低QoS要件のための配信モードである。配信モード2は、MBSセッションのうちブロードキャストセッションに用いられる。但し、配信モード2は、マルチキャストセッションにも適用可能であってもよい。
配信モード2におけるMBS受信の設定は、gNB200からUE100にブロードキャストで送信される論理チャネル、例えば、BCCH(Broadcast Control Channel)又はMCCH(Multicast Control Channel)により行われる。以下において、このような制御チャネルをMBS制御チャネルと呼ぶ。
なお、ネットワークは、MBSセッションごとに異なるMBSサービスを提供できる。MBSセッションは、TMGI(Temporary Mobile Group Identity)及びセッション識別子のうち少なくとも1つにより識別される。これらの識別子のうち少なくとも1つをMBSセッション識別子と呼ぶ。このようなMBSセッション識別子は、MBSサービス識別子又はマルチキャストグループ識別子と呼ばれてもよい。
(スプリットMBSベアラ)
次に、一実施形態に係るスプリットMBSベアラについて説明する。スプリットMBSベアラは、上述の配信モード1において利用可能である。
gNB200は、PTP通信パス及びPTM通信パスに分離されたMBSベアラ(以下、適宜「スプリットMBSベアラ」と呼ぶ)をUE100に設定し得る。これにより、gNB200は、UE100に対するMBSトラフィックの送信をPTP(PTP通信パス)とPTM(PTM通信パス)との間で動的に切り替えることができる。或いは、gNB200は、PTP及びPTMを併用して同一のMBSトラフィックを二重送信することにより信頼性を高めることができる。或いは、gNB200は、MBSトラフィックの初送をPTMで複数のUE100に対して行い、MBSトラフィックの再送を特定のUE100に対して行うことにより信頼性を高めることができる。
スプリットを終端する所定レイヤは、MACレイヤ(HARQ)、RLCレイヤ、PDCPレイヤ、又はSDAPレイヤである。以下において、スプリットを終端する所定レイヤがPDCPレイヤである一例について主として説明するが、所定レイヤは、MACレイヤ(HARQ)、RLCレイヤ、又はSDAPレイヤであってもよい。
図8は、一実施形態に係るスプリットMBSベアラを示す図である。以下において、PTP通信パスをPTPレグと呼び、PTM通信パスをPTMレグと呼ぶ。また、各レイヤに相当する機能部をエンティティと呼ぶ。
図8に示すように、gNB200のPDCPエンティティ及びUE100のPDCPエンティティのそれぞれは、MBSに用いるベアラ(データ無線ベアラ)であるMBSベアラをPTPレグ及びPTMレグに分離する。なお、PDCPエンティティはベアラごとに設けられる。
gNB200及びUE100のそれぞれは、レグごとに設けられる2つのRLCエンティティと、1つのMACエンティティと、1つのPHYエンティティとを有する。PHYエンティティは、レグごとに設けられてもよい。なお、UE100が2つのgNB200との通信を行う二重接続(Dual Connectivity)の場合、UE100が2つのMACエンティティを有していてもよい。
PHYエンティティは、UE100と1対1で割り当てられるセルRNTI(C-RNTI:Cell Radio Network Temporary Identifier)を用いて、PTPレグのデータを送受信する。PHYエンティティは、MBSセッションと1対1で割り当てられるグループRNTI(G-RNTI:Group Radio Network Temporary Identifier)を用いて、PTMレグのデータを送受信する。C-RNTIはUE100ごとに異なるが、G-RNTIは1つのMBSセッションを受信する複数のUE100で共通のRNTIである。
gNB200からUE100に対してPTMレグを用いてMBSトラフィックのPTM送信(マルチキャスト又はブロードキャスト)を行うためには、gNB200からUE100にスプリットMBSベアラが設定されており、且つ、PTMレグがアクティブ化(activation)されている必要がある。言い換えると、gNB200は、UE100にスプリットMBSベアラが設定されていても、PTMレグが非アクティブ(deactivation)状態にある場合は、このPTMレグを用いてMBSトラフィックのPTM送信を行うことができない。
また、gNB200及びUE100がPTPレグを用いてMBSトラフィックのPTP送信(ユニキャスト)を行うためには、gNB200からUE100にスプリットMBSベアラが設定されており、且つ、PTPレグがアクティブ化されている必要がある。言い換えると、gNB200は、UE100にスプリットMBSベアラが設定されていても、PTPレグが非アクティブ状態にある場合は、このPTPレグを用いてMBSトラフィックのPTP送信を行うことができない。
UE100は、PTMレグがアクティブ化された状態において、MBSセッションと対応付けられたG-RNTIが適用されたPDCCH(Physical Downlink Control Channel)をモニタする(すなわち、G-RNTIを用いてPDCCHのブラインドデコーディングを行う)。UE100は、当該MBSセッションのスケジューリング機会にのみ当該PDCCHをモニタしてもよい。
UE100は、PTMレグが非アクティブ化された状態において、MBSセッションと対応付けられたG-RNTIが適用されたPDCCHをモニタしない(すなわち、G-RNTIを用いたPDCCHのブラインドデコーディングを行わない)。
UE100は、PTPレグがアクティブ化された状態において、C-RNTIが適用されたPDCCHをモニタする。UE100は、PTPレグにおける間欠受信(DRX:Discontinuous Reception)が設定されている場合、設定されたオン期間(OnDuration)においてPDCCHをモニタする。UE100は、MBSセッションと紐づいたセル(周波数)が指定されている場合、当該セルが非アクティブ化されていても、当該セルのPDCCHをモニタしてもよい。
UE100は、PTPレグが非アクティブ化された状態において、MBSトラフィック以外の通常のユニキャスト下りリンク送信にそなえて、C-RNTIが適用されたPDCCHをモニタしてもよい。但し、UE100は、MBSセッションと紐づいたセル(周波数)が指定されている場合、当該MBSセッションについて当該PDCCHをモニタしなくてもよい。
なお、gNB200のRRCエンティティがUE100のRRCエンティティに対して送信するRRCメッセージ(例えば、RRC Reconfigurationメッセージ)により、上述のようなスプリットMBSベアラが設定されるものとする。
(一実施形態に係る動作)
次に、一実施形態に係る動作について説明する。以下において、配信モードとして配信モード1を用いる場合を主として想定する。
図9は、配信モード1でMBS受信の設定に用いるRRC Reconfigurationメッセージの構成例を示す図である。図9に示すように、gNB200からUE100に送信されるRRC Reconfigurationメッセージは、MBS受信に必要なMBS設定を情報要素として含む。
MBS設定は、MBS受信のための基本的な設定である基本受信設定と、RRCコネクティッド状態におけるMBS受信にのみ適用可能なRRCコネクティッド専用設定とを含む。
基本受信設定は、全RRC状態(すなわち、RRCコネクティッド状態、RRCアイドル状態、RRCインアクティブ状態)で共通の設定である。基本受信設定は、MTCHスケジューリング情報を含む。MTCHスケジューリング情報は、グループRNTI、MBSセッション識別子、送信オケージョン、及び送信BWP(Bandwidth Part)のうち少なくとも1つを含む。
ここで、グループRNTIは、UE100のグループに対して共通に割り当てられるRNTIである。送信オケージョンは、gNB200がMTCHを用いてMBSトラフィックを送信するタイミング(例えばサブフレーム)の候補である。送信BWPは、gNB200がMTCHを用いてMBSトラフィックを送信するBWPである。BWPは、1つのセルの周波数帯域幅よりも狭い帯域幅部分であって、UE100の動作帯域幅を限定するためのものである。
他方、RRCコネクティッド専用設定は、スプリットMBSベアラに関する設定等であって、例えば、スプリットMBSベアラのベアラ設定、PTPとPTMとの動的切り替え設定、及びPTPレグ設定のうち少なくとも1つを含む。なお、PTMレグ設定は、RRCアイドル状態又はRRCインアクティブ状態でも使用可能であるため、基本受信設定に含まれてもよい。RRCコネクティッド専用設定は、HARQフィードバック設定を含んでもよい。
一実施形態において、例えばMBS設定を有するUE100についてマルチキャストセッションの進行中のデータがないとき、gNB200は、UE100をRRCアイドル状態又はRRCインアクティブ状態に遷移させる。ここで、gNB200は、輻輳が原因でUE100をRRCコネクティッド状態に維持できない状況にあってもよい。
UE100は、RRCアイドル状態又はRRCインアクティブ状態に遷移した場合であっても、MBS受信を継続できることが望ましい。一実施形態において、UE100は、RRCアイドル状態又はRRCインアクティブ状態で用いるMBS設定として、RRC Reconfigurationメッセージによって提供されたMBS設定を引き続き適用する。すなわち、UE100は、RRCコネクティッド状態時に提供されたMBS設定を再利用する。
すなわち、一実施形態に係るUE100は、RRCコネクティッド状態にあるときに、MBS受信に必要なMBS設定を含むRRC Reconfigurationメッセージ(RRCメッセージ)を基地局から受信する。UE100は、RRCコネクティッド状態からRRCアイドル状態又はRRCインアクティブ状態に遷移した後に、RRCコネクティッド状態時に受信したMBS設定を用いてMBS受信を行う。
ここで、MBS設定のうちRRCコネクティッド専用設定の取り扱いが問題になる。一実施形態に係るUE100は、RRCアイドル状態又はRRCインアクティブ状態に遷移する際に、RRCコネクティッド状態時に受信したMBS設定に含まれるRRCコネクティッド専用設定を無効化する処理を行う。これにより、UE100の記憶容量を節約できるとともに、予期せぬエラーの発生を抑制できる。
図10は、一実施形態に係る動作を示す図である。
図10に示すように、ステップS101において、UE100は、gNB200のセルにおいてRRCコネクティッド状態にある。
ステップS102において、gNB200は、MBS設定、すなわち、基本受信設定とRRCコネクティッド専用設定とを含むRRC ReconfigurationメッセージをUE100に送信する。UE100は、RRC Reconfigurationメッセージを受信する。
ステップS103において、UE100は、受信したRRC Reconfigurationメッセージに含まれるMBS設定を記憶及び適用する。
ステップS104において、UE100は、ステップS103で適用したMBS設定、すなわち、基本受信設定とRRCコネクティッド専用設定とを用いて、gNB200からMBSトラフィックを受信する。
このようにして、UE100は、RRC ReconfigurationメッセージでMBS設定を受信し、MBSトラフィックを受信する。
その後、ステップS105において、gNB200は、RRCアイドル状態又はRRCインアクティブ状態に遷移させるUE100を特定する。
ここで、gNB200は、対象のMBSセッションを受信しているUE100を、RRCアイドル状態又はRRCインアクティブ状態に遷移させるUE100として特定してもよい。例えば、ステップS104のMBSトラフィック送信がマルチキャストで行われる場合、gNB200は、5GC20に対して情報提供を要求し、対象のMBSセッションを受信しているUE100を特定する。他方、ステップS104のMBSトラフィック送信がブロードキャストで行われる場合、gNB200は、事前にUE100からMBS興味インディケーションメッセージ(MII)で情報提供を受ける。これにより、gNB200は、対象のMBSセッションを受信しているUE100を特定する。
gNB200は、移動しないUE100を、RRCアイドル状態又はRRCインアクティブ状態に遷移させるUE100として特定してもよい。
移動中のUE100の場合、MBSサービスの継続性を保証するべく、gNB200がハンドオーバ制御を行う必要があり得るため、移動中のUE100はRRCコネクティッド状態に維持することが望ましい。これに対し、移動しないUE100はそのような必要が無いため、gNB200は、移動しないUE100をRRCアイドル状態又はRRCインアクティブ状態に遷移させる。これにより、gNB200の負荷を軽減できる。
また、UE100がセル(又は後述のエリア範囲)から出ると、このセルのMBS設定が無効になる虞があるが、移動しないUE100はそのような虞が無い。そのため、gNB200は、移動しないUE100をRRCアイドル状態又はRRCインアクティブ状態に遷移させることにより、gNB200の負荷を軽減できる。
なお、gNB200は、自セルにおける滞在時間が所定時間を超えるUE100を移動しないUE100として特定してもよい。また、gNB200は、UE100から周期的に受信する位置情報に基づいて、移動しないUE100を特定してもよい。もしくは、gNB200は、UE100から移動状態を通知されることにより、移動しないUE100を特定してもよい。当該通知はgNB200からの要求によって通知されてもよい。当該通知はUE100自身が判断して(例えば移動状態が変化したことに伴って)通知されてもよい。当該移動状態はMBS興味インディケーション(MII)を用いて通知されてもよい。当該移動状態はMBS受信への興味情報と紐づいて通知されもよい。
ステップS106において、gNB200は、ステップS105で特定したUE100に対してRRC Releaseメッセージを送信する。UE100は、RRC Releaseメッセージを受信する。gNB200は、UE100をRRCインアクティブ状態に遷移させる場合、suspend configを情報要素として含むRRC ReleaseメッセージをUE100に送信する。
ステップS107において、UE100は、受信したRRC Releaseメッセージに基づいてRRCアイドル状態又はRRCインアクティブ状態に遷移する。
ステップS108において、UE100は、基本受信設定の適用を継続するとともに、RRCコネクティッド専用設定を無効化する処理を行う。無効化する処理は、RRCコネクティッド専用設定の破棄(discard)、RRCコネクティッド専用設定の適用中断(suspend)、又はRRCコネクティッド専用設定の非アクティブ化(deactivate)である。
suspend又はdeactivateの場合、RRCコネクティッド専用設定は破棄されずに保持される。保持されたRRCコネクティッド専用設定は、UE100が再びRRCコネクティッド状態に戻った際に復旧(有効化)され得る。なお、UE100がRRCインアクティブ状態からRRCコネクティッド状態に遷移する動作はレジューム(RRCレジューム)と呼ばれる。UE100は、RRCレジューム時に、保持されたRRCコネクティッド専用設定を有効化しなくてもよい。UE100は、RRCアイドル状態又はRRCインアクティブ状態に遷移したときのセルと、RRCコネクティッド状態に戻るときのセルとが同じである場合はRRCコネクティッド専用設定を有効化し、これらが異なるセルである場合はRRCコネクティッド専用設定を有効化しないとしてもよい(詳細については、後述の変更例で説明する)。
また、ステップS108において、UE100は、RRCコネクティッド状態のみで使用していたエンティティ、例えば、PTPレグのRLCエンティティを解放してもよい。UE100は、関連するエンティティの再設定、例えば、PDCPエンティティのスプリット(又は結合)機能を停止設定してもよい。
ステップS109において、UE100は、基本受信設定を用いて、RRCアイドル状態又はRRCインアクティブ状態でMBSトラフィックの受信を継続する。
(第1変更例)
次に、上述の実施形態の第1変更例について、上述の実施形態との相違点を主として説明する。
本変更例において、UE100は、RRCコネクティッド状態からRRCインアクティブ状態へ遷移する場合、RRCコネクティッド専用設定を保持するものとする。これにより、UE100は、保持している設定を有効に活用して、素早くスプリットMBSベアラ等の設定を行うことが可能になる。なお、UE100がRRCインアクティブ状態に遷移したときのgNB200と、RRCコネクティッド状態に戻るときのgNB200とが同じであってもよいし、これらのgNB200が異なっていてもよい。
本変更例において、RRCインアクティブ状態に遷移したUE100は、RRCインアクティブ状態においてRRCコネクティッド専用設定を保持する。UE100は、RRCインアクティブ状態からRRCコネクティッド状態に遷移するレジューム動作時に、RRCコネクティッド専用設定を保持していることを示す通知をgNB200に送信する。この通知を受信したgNB200は、UE100が保持しているRRCコネクティッド専用設定を有効化するか否かをUE100に指示する。
図11は、実施形態の第1変更例に係る動作を示す図である。ここでは、UE100がRRCインアクティブ状態に遷移したときのgNB200aと、RRCコネクティッド状態に戻るときのgNB200bとが異なる一例について説明する。
図11に示すように、ステップS201乃至S208の動作は、上述の実施形態と同様である。但し、本変更例において、UE100は、RRCインアクティブ状態に遷移する際に、RRCコネクティッド専用設定を無効化及び保持するものとする。ステップS209において、UE100は、基本受信設定を用いて、RRCインアクティブ状態でMBSトラフィックの受信を継続する。
ステップS210において、RRCインアクティブ状態にあるUE100は、gNB200aのセルからgNB200bのセルへのセル再選択を行う。
UE100は、RRC接続のレジュームを行うことを決めると、ステップS211において、gNB200bとのランダムアクセスプロシージャを開始する。
RRCレジュームの場合の一般的なランダムアクセスプロシージャは、以下の1)~5)を含む。
1)UE100からgNB200bへのランダムアクセスプリアンブル(Msg1)の送信
2)gNB200bからUE100へのランダムアクセス応答(Msg2)の送信
3)UE100からgNB200bへのRRC Resume Requestメッセージ(Msg3)の送信
4)gNB200bからUE100へのRRC Resumeメッセージ(Msg4)の送信
5)UE100からgNB200bへのRRC Resume Completeメッセージ(Msg5)の送信
他方、2ステップのランダムアクセスプロシージャは、Msg1及びMsg3が1つのメッセージ(MsgA)に統合され、Msg2及びMsg4が1つのメッセージ(MsgB)に統合される。
このようなランダムアクセスプロシージャにおいて、UE100は、特別なPRACH(Physical Random Access Channel)リソースを用いてMsg1又はMsgAを送信する。これにより、UE100は、RRCコネクティッド専用設定を保持していることをgNB200bに通知する(ステップS211a)。或いは、UE100は、RRCコネクティッド専用設定を保持していることを示す情報要素を含むMsg3、MsgA、又はMsg5を送信する。これにより、UE100は、RRCコネクティッド専用設定を保持していることをgNB200bに通知する(ステップS211a)。
UE100から保持通知を受けたgNB200bは、UE100が保持しているRRCコネクティッド専用設定を有効化するか否かを決定し、決定結果を示す指示をUE100に送信する(ステップS212)。例えば、gNB200bは、UE100のコンテキスト情報をgNB200aから取得できた場合に限り、UE100が保持しているRRCコネクティッド専用設定を有効化すると決定してもよい。
UE100は、RRCコネクティッド専用設定を有効化する指示をgNB200bから受信した場合、保持しているRRCコネクティッド専用設定を有効化する。これに対し、UE100は、RRCコネクティッド専用設定を有効化する指示をgNB200bから受信しない場合、保持しているRRCコネクティッド専用設定を有効化しない。この場合、UE100は、保持しているRRCコネクティッド専用設定を破棄してもよい。
(第2変更例)
次に、上述の実施形態の第2変更例について、上述の実施形態との相違点を主として説明する。本変更例において、UE100は、RRCコネクティッド状態からRRCアイドル状態又はRRCインアクティブ状態へ遷移する場合、RRCコネクティッド専用設定を保持するものとする。
マルチキャストセッション(配信モード1)は、基本的に、ネットワーク制御型の配信モードであってUE100がRRCコネクティッド状態に維持される。しかし、一時的なネットワーク混雑等の理由で、UE100はRRCアイドル状態又はRRCインアクティブ状態に遷移される。
他方、RRCコネクティッド専用設定におけるスプリットMBSベアラは、セル端のUE100に設定されることが多いと想定される。例えば、セル端のUE100は無線状況が悪いため、gNB200は、PTPレグを用いてMBSトラフィックを伝送し得る。或いは、セル端のUE100についてはハンドオーバを行う蓋然性が高いため、gNB200は、ハンドオーバ時のパケットロスを無くすためにPTPレグを用いてMBSトラフィックを伝送し得る。
このため、本変更例において、RRCアイドル状態又はRRCインアクティブ状態へ遷移し、且つRRCコネクティッド専用設定を保持するUE100は、セル端において他セルへのセル再選択を行う前にgNB200に通知する。これにより、gNB200(ネットワーク)が通知に基づいてUE100に対するモビリティ制御を行うことが可能である。
本変更例において、UE100は、RRCアイドル状態又はRRCインアクティブ状態において、セル再選択に関する所定条件(トリガ条件)が満たされたと判定した場合、gNB200に対するランダムアクセスプロシージャを開始する。UE100は、ランダムアクセスプロシージャにおいて、所定条件が満たされたことを示す通知をgNB200に送信する。
図12は、実施形態の第2変更例に係る動作を示す図である。ここでは、UE100がRRCインアクティブ状態に遷移する場合を想定しているが、UE100がRRCアイドル状態に遷移する場合を想定してもよい。すなわち、図12におけるRRCインアクティブ状態をRRCアイドル状態と読み替えてもよい。
図12に示すように、ステップS301乃至S308の動作は、上述の実施形態と同様である。但し、本変更例において、UE100は、RRCインアクティブ状態(又はRRCアイドル状態)に遷移する際に、RRCコネクティッド専用設定を無効化及び保持するものとする。ステップS309において、UE100は、基本受信設定を用いて、RRCインアクティブ状態(又はRRCアイドル状態)でMBSトラフィックの受信を継続する。
ステップS310において、UE100は、gNB200のセルから他セルへのセル再選択に関するトリガを検知する。セル再選択に関するトリガ条件は、実際にセル再選択をトリガする条件であってもよいし、セル再選択をトリガする予兆を示す条件であってもよい。トリガ条件は、gNB200からUE100に設定される閾値(例えば、RSRP/RSRQ閾値)及びその比較対象を指定する情報(イベント情報)を含んでもよい。
UE100は、セル再選択に関するトリガを検知すると、ステップS311において、gNB200とのランダムアクセスプロシージャを開始する。
このランダムアクセスプロシージャにおいて、UE100は、セル再選択に関するトリガ条件が満たされたことを示す通知をgNB200に送信する。このような通知の方法としては、上述の実施形態の第1変更例と同様な方法を用いることができる。すなわち、UE100は、特別なPRACHリソースを用いてMsg1又はMsgAを送信することにより、セル再選択に関するトリガ条件が満たされたことをgNB200に通知する(ステップS311a)。或いは、UE100は、セル再選択に関するトリガ条件が満たされたことを示す情報要素を含むMsg3、MsgA、又はMsg5を送信することにより、セル再選択に関するトリガ条件が満たされたことをgNB200に通知する(ステップS311a)。なお、UE100は、ステップS312でのモビリティ制御に用いるために、自身の無線状況を示す無線測定結果を含む測定報告をgNB200に送信してもよい。
ステップS312において、gNB200は、ステップS311aでUE100から受信した通知に基づいて、UE100に対するモビリティ制御(ハンドオーバ制御又はセル再選択制御)を行う。例えば、gNB200は、UE100をRRCコネクティッド状態に遷移させたうえで他セルへのハンドオーバを行う。或いは、gNB200は、UE100をRRCアイドル状態又はRRCインアクティブ状態に留めたうえで他セルへのセル再選択をUE100に行わせる。この場合、gNB200は、RRCコネクティッド専用設定の破棄をUE100に指示してもよい。
(第3変更例)
次に、上述の実施形態の第3変更例について、上述の実施形態との相違点を主として説明する。
本変更例において、RRCコネクティッド状態においてRRCコネクティッド専用設定を有するUE100は、RRCアイドル状態又はRRCインアクティブ状態への遷移が禁止されるものとする。このような前提下において、gNB200は、RRCアイドル状態又はRRCインアクティブ状態にUE100を遷移させる前に、RRCコネクティッド専用設定をUE100に解放(破棄)させたうえで、RRCアイドル状態又はRRCインアクティブ状態へUE100を遷移させる。そして、UE100は、gNB200によりRRCコネクティッド専用設定が解放された後に、RRCアイドル状態又はRRCインアクティブ状態に遷移する。
図13は、実施形態の第3変更例に係る動作を示す図である。
図13に示すように、ステップS401乃至S405の動作は、上述の実施形態と同様である。但し、ステップS405において、gNB200は、RRCアイドル状態又はRRCインアクティブ状態に遷移可能なUE100を特定してもよい。例えば、gNB200は、一定期間にわたって上りリンク送信の見込みがないUE100又はユニキャスト通信がないUE100を特定する。ステップS405において、gNB200は、RRC接続の解放を促すメッセージ、例えば、RAI(Release Assistance Information)メッセージを送信したUE100を特定してもよい。
ステップS406において、gNB200は、特定したUE100に対して、RRCコネクティッド専用設定を解放することを示す情報要素を含むRRC Reconfigurationメッセージを送信する。
ステップS407において、UE100は、ステップS406のRRC Reconfigurationメッセージの受信に応じて、RRCコネクティッド専用設定を解放(破棄)する。UE100は、MBS設定のうちPTMのMBS設定(基本受信設定)のみを有する状態になる。
ステップS408において、gNB200は、RRCコネクティッド専用設定を解放したUE100に対してRRC Releaseメッセージを送信する。UE100は、RRC Releaseメッセージを受信する。
ステップS409において、UE100は、受信したRRC Releaseメッセージに基づいてRRCアイドル状態又はRRCインアクティブ状態に遷移する。
ステップS410において、UE100は、基本受信設定の適用を継続する。
ステップS411において、UE100は、基本受信設定を用いて、RRCアイドル状態又はRRCインアクティブ状態でMBSトラフィックの受信を継続する。
なお、本変更例において、MBS設定をRRC Reconfigurationメッセージにより行うシナリオを想定しているが、MBS設定をRRC Releaseメッセージにより行うシナリオを想定してもよい。MBS設定をRRC Releaseメッセージにより行うシナリオにおいて、ステップS406のRRC Reconfigurationメッセージの送信は不要である。このようなシナリオにおいて、gNB200は、RRCコネクティッド専用設定をRRC Releaseメッセージにより行うことが禁止されてもよい。例えば、RRCコネクティッド専用設定に関する情報要素は、RRC Releaseメッセージでは使えない条件設定となっていてもよい。
(第4変更例)
次に、上述の実施形態の第4変更例について、上述の実施形態との相違点を主として説明する。
本変更例において、複数のセルからなるエリア範囲においてMBS設定が共通化されるものとする。これにより、RRCアイドル状態又はRRCインアクティブ状態に遷移したUE100は、当該エリア範囲内ではMBS設定を更新することなくMBSトラフィックの受信を継続できる。当該エリア範囲は、上述の実施形態の第1変更例及び第2変更例に係る通知が不要なエリアとして定義されてもよい。
具体的には、本変更例に係るUE100は、MBS設定が有効なエリア範囲を示すエリア情報を含むRRCメッセージ(RRC Reconfigurationメッセージ又はRRC Releaseメッセージ)をgNB200から受信する。RRCアイドル状態又はRRCインアクティブ状態に遷移したUE100は、当該エリア情報が示すエリア範囲内において、当該MBS設定を用いてMBS受信を行う。
図14は、実施形態の第4変更例に係る動作を示す図である。
図14に示すように、ステップS501乃至S507の動作は、上述の実施形態と同様である。但し、ステップS502又はS506において、gNB200は、MBS設定とともにエリア情報をUE100に送信することにより、当該MBS設定が有効なエリア範囲をUE100に設定する。エリア情報は、エリア範囲を構成する各セルの識別子(セル識別子)からなるリストであってもよい。各セルが自セルの識別子を報知しているため、UE100は、設定されたリストを用いて、自身が当該エリア範囲内であるか否かを判定できる。或いは、エリア情報は、エリア範囲を示す識別子(エリア識別子)であってもよい。各セルが自セルの属するエリア範囲のエリア識別子を報知しているため、UE100は、設定されたエリア識別子を用いて、自身が当該エリア範囲内であるか否かを判定できる。
ステップS507において、UE100は、ステップS506で受信したRRC Releaseメッセージに基づいてRRCアイドル状態又はRRCインアクティブ状態に遷移する。
ステップS508及びS509において、UE100は、gNB200から設定されたMBS設定のうち基本受信設定を用いてMBSトラフィックの受信を継続する。ここで、UE100は、gNB200から設定されたエリア範囲内においては当該MBS設定が有効であるとみなし、セル再選択を行う場合でもネットワークへの通知を行わない。
UE100は、当該エリア範囲外のセルへ自身が移動した場合、当該エリア範囲外のセルに対してランダムアクセスを行うことにより、このセルから新たなMBS設定を受信する。或いは、UE100は、当該エリア範囲外のセルを検知した場合、当該エリア範囲外に移動する前に現在のセルに対してランダムアクセスを行うことにより、このセルから新たなMBS設定を受信してもよい。
(第5変更例)
次に、上述の実施形態の第5変更例について、上述の実施形態との相違点を主として説明する。
本変更例において、gNB200は、RRC ReconfigurationメッセージによるMBS設定(具体的には、基本受信設定)をRRCアイドル状態又はRRCインアクティブ状態でも使用してよいか否かを、RRC ReleaseメッセージでUE100に通知する。すなわち、UE100は、RRCコネクティッド状態時に受信したMBS設定をRRCアイドル状態又はRRCインアクティブ状態において使用可能とするか否かを示す情報を含むRRC ReleaseメッセージをgNB200から受信する。
図15は、実施形態の第5変更例に係る動作を示す図である。
図15に示すように、ステップS601乃至S609の動作は、上述の実施形態と同様である。但し、ステップS606において、gNB200は、次のA)及びB)のいずれかの情報を含むRRC ReleaseメッセージをUE100に送信する。
A)ステップS602のRRC Reconfigurationメッセージで設定されたMBS設定をRRCアイドル状態又はRRCインアクティブ状態において継続使用してよいか否かを示す情報。
B)ステップS602のRRC Reconfigurationメッセージで設定されたMBS設定をRRCアイドル状態又はRRCインアクティブ状態で使用する場合の有効期限を示す情報。有効期限を示す情報は、SFN(System Frame Number)、H-SFN(Hyper SFN)、及びサブフレームのうち少なくとも1つにより表現されてもよい。有効期限を示す情報は、有効期限の時間長を示すタイマ値であってもよい。
上述のA)の場合において、UE100は、継続使用が許可されることを示す情報を含むRRC ReleaseメッセージをgNB200から受信(ステップS606)した場合に限り、ステップS602のRRC Reconfigurationメッセージ中のMBS設定をRRCアイドル状態又はRRCインアクティブ状態において継続使用する。
上述のB)の場合において、UE100は、RRC Releaseメッセージで設定された有効期限内においてのみ、ステップS602のRRC Reconfigurationメッセージ中のMBS設定をRRCアイドル状態又はRRCインアクティブ状態において継続使用する。なお、有効期限がタイマ値により設定される場合、UE100は、RRCアイドル状態又はRRCインアクティブ状態に遷移(ステップS607)する際に、タイマ(タイマ値に対応するタイマ)を起動し、このタイマが満了するまでの間においてMBS設定を継続使用する。
ここで、有効期限が切れた場合(タイマが満了した場合)、まだMBS受信に興味があるUE100は、gNB200に対してランダムアクセスを行うことにより、gNB200から新たなMBS設定を受信してもよい。当該ランダムアクセスプロシージャにおいて、UE100は、MBS設定の更新のためのアクセスであることをgNB200に通知してもよい。当該通知は、特別なPRACHリソースを用いたMsg1/MsgAで示されてもよく、Msg3において示されてもよい。もしくは、配信モード2によるMBS設定がSIB又はMCCHで報知されている場合、UE100は、配信モード2によるMBS設定の取得を試みてもよい。他方、有効期限が切れた際に、既にMBS受信に興味がないUE100は、RRC Reconfigurationメッセージで設定されたMBS設定を破棄してもよい。
(第6変更例)
次に、上述の実施形態の第6変更例について、上述の実施形態との相違点を主として説明する。
本変更例において、UE100は、隣接セル情報を含むRRC Releaseメッセージを受信する。隣接セル情報は、隣接セルの識別子と、当該隣接セルが提供するMBSサービス(MBSセッション)を示す識別子とを含む。これにより、UE100は、RRCアイドル状態又はRRCインアクティブ状態においてセル再選択を行う際に、自身の興味があるMBSサービスを提供するセルを優先的に選択可能になる。RRCアイドル状態又はRRCインアクティブ状態に遷移したUE100は、受信した隣接セル情報に基づいてセル再選択を制御する。
図16は、実施形態の第6変更例に係る動作を示す図である。
図16に示すように、ステップS701乃至S709の動作は、上述の実施形態と同様である。但し、ステップS706において、gNB200は、隣接セル情報を含むRRC ReleaseメッセージをUE100に送信する。gNB200は、隣接セル情報とMBS設定(具体的には、基本受信設定)とを含むRRC ReleaseメッセージをUE100に送信してもよい。
この隣接セル情報は、隣接セルの識別子(セル識別子)と、当該隣接セルが提供するMBSサービスを示す識別子(セッション識別子)のリストとを含む。UE100は、自身が興味のあるMBS設定を提供しているセルをセル再選択における最高優先度とみなしてセル再選択を行う。
(その他の実施形態)
上述の各変更例は、別個独立して実施する場合に限らず、2以上の変更例を組み合わせて実施可能である。
また、上述の実施形態において、基地局がNR基地局(gNB)である一例について説明したが基地局がLTE基地局(eNB)であってもよい。また、基地局は、IAB(Integrated Access and Backhaul)ノード等の中継ノードであってもよい。基地局は、IABノードのDU(Distributed Unit)であってもよい。
UE100又はgNB200が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、CD-ROMやDVD-ROM等の記録媒体であってもよい。
また、UE100又はgNB200が行う各処理を実行する回路を集積化し、UE100又はgNB200の少なくとも一部を半導体集積回路(チップセット、SoC)として構成してもよい。
以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
本願は、米国仮出願第63/134,280号(2021年1月6日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
(付記)
(導入)
NRのマルチキャストブロードキャストサービス(MBS)に関する改訂されたワークアイテムが承認された。MBSの2つの配信モードを次のように導入することが合意された。
・Rel-17において、R2は、次の2つのモードを規定する。
1:コネクティッド(データ受信がない場合、UEは他の状態に切り替えることができる可能性があるが、未定)で利用可能な高QoS(信頼性、遅延)要件のための配信モード。
2:「低」QoS要件のための配信モード。UEはインアクティブ/アイドルでもデータを受信し得る(詳細は未定)。
・R2は、(R17の場合)配信モード1がマルチキャストセッションにのみ使用されることを前提とする。
・R2は、配信モード2がブロードキャストセッションに使用されることを前提とする。
・配信モード2のマルチキャストセッションへの適用性は、更なる検討が必要である。
・データなし:マルチキャストセッションで進行中のデータがない場合、UEはRRCコネクティッドに留まり得る。その他の場合は、更なる検討が必要である。
配信モード2に関して、MBS設定の概要を以下のように追加合意した。
UEは、BCCH及び/又はMCCH(未定)によって(ブロードキャスト/配信モード2の場合)MBS設定を受信し、これは、アイドル/インアクティブモードで受信され得る。コネクティッドモードは、更なる検討が必要である。通知メカニズムは、MBS制御情報の変更を通知するために使用される。
この付記では、LTE eMBMSメカニズム及び最新のRAN2の合意を考慮して、NR MBSの制御プレーンの側面を考慮する。
(議論)
RAN2の合意に従って、この時点での2つの配信モードを表1に要約する。
(配信モード1設定)
配信モード1は、主にRRCコネクティッドでのデータ受信のために検討されるが、設定の側面はまだ合意されていない。MBS設定がRRC再設定によって提供されることは非常に平易であり得るが、LTE eMBMSのようにコネクティッドでMCCHが受信されることはまだ検討中である。配信モード1は高QoSサービスに期待されることを考慮すると、例えば、PTP/PTMスプリットベアラ及び/又はロスレスハンドオーバなどを伴うべきである。これらのUE固有の設定がMCCHを介して提供されている場合、意味がないため、私たちの見解では、配信モード1の設定にRRC再設定が使用されるべきである。
提案1:配信モード1において、RAN2は、MBS設定にRRC再設定を使用することに合意すべきである。
一方、WIDは、次のように、RRCコネクティッド及びアイドル/インアクティブがMBS設定に関して最大の共通性を持つべきであることを明確に示すが、RAN2は、マルチキャストセッション及びブロードキャストセッションのそれぞれに対して別々の配信モードに同意した。
PTM受信の設定でRRCコネクティッド状態とRRCアイドル/インアクティブ状態との間で最大の共通性を維持することを目的として、RRCアイドル/インアクティブ状態のUEによるPTM送信の受信を有効にするために必要な変更を規定する。
これらの配信モードのRRCメッセージが異なる場合でも、WIDの目的を達成するには、MBS設定の構造及びIEを2つの配信モード間で可能な限り調整すべきである。例えば、配信モード1のRRC再設定には、配信モード2と共通のブロックであるMTCHスケジューリング情報に加えて、PTP/PTMスプリットベアラ及びハンドオーバ関連情報などの配信モード1固有の情報が含まれる。このため、詳細はこの時点で更なる検討が必要である。
提案2:RAN2は、MBS設定の観点から、例えば、共通の構造及びIEを使用して、2つの配信モード間の最大の共通性を目指すことに合意すべきである。
なお、図17における「MCCH」は、MTCHスケジューリング情報、即ち、MBSセッション情報と関連するMTCH設定のみを指している。配信モード1の場合、隣接セル情報は必要ない。
マルチキャストセッションの進行中のデータがない場合にUEをアイドル/インアクティブに解放し得るかは、更なる検討が必要である。言い換えると、アイドル/インアクティブのUEが配信モード1を介してMBSデータを受信できるかどうかは、更なる検討が必要である。RAN2が同意したように、UEは配信モード1、つまり高いQoSを必要とするマルチキャストセッションのためにRRCコネクティッドに維持すべきであることがベースラインである。しかし、他の/例外的なケースについても、まだ検討する価値がある。
Eメールディスカッション中に、一部の企業は、輻輳が原因でネットワークがすべてのUEをコネクティッドに維持できない可能性があることを指摘した。他の一部の企業も、アップリンクアクティビティ、QoS要件、及び/又はUEの電力消費のために、UEが常にコネクティッドのままである必要はないことを指摘した。
RAN2の観点から、ネットワーク及びUEの両方がこの機能をサポートすることは有益であると考えられ得る。UEがインアクティブに解放されるか/いつ解放されるかはgNBの実装次第であり、UEがアイドルに解放されるかはコアネットワーク次第であると想定される。アイドルでのMBSデータ受信に関する1つの懸念は、gNBがUEコンテキストを解放することである。一方、UEコンテキストは、インアクティブでは保持される。これは、gNBの可制御性が失われる可能性があることを意味し、一般的な配信モード1の概念と矛盾する可能性がある。したがって、RAN2は、配信モード1を少なくともインアクティブでUEが受信し得ることに合意すべきあるが、アイドルにおいては更なる検討が必要である。
提案3:配信モード1において、RAN2は、配信モード1を少なくともインアクティブでUEが受信し得ることに合意すべきある。アイドルにおいては更なる検討が必要である。
提案3に合意できる場合、アイドル/インアクティブのMBS設定がUEにどのように提供されるかは明確ではない。次の3つのオプションが考えられる。
・オプション1:RRC再設定
アイドル/インアクティブのUEは、RRC再設定によって提供されたMBS設定を引き続き適用する。UEは元々RRCコネクティッド用に提供されたMBS設定を再利用するだけなので、このオプションは単純である。しかし、アイドル/インアクティブに遷移する場合及び/又はRRCコネクティッドをレジュームする場合に、例えば、設定されている場合はPTP/PTMスプリットベアラ設定を処理する方法など、いくつかのUEの動作を検討する必要がある可能性がある。
・オプション2:RRC解放
アイドル/インアクティブのUEは、RRC解放によって提供されるMBS設定を適用する。このオプションは明快であるが、MBS設定が以前にRRC再設定によって提供されたものと異なるかどうかは疑わしいため、効率的ではない可能性がある。
・オプション3:モード1からモード2への配信モードの切り替え
UEは、アイドル/インアクティブに解放される前に、配信モード1から配信モード2に切り替えられる。配信モード2は、RAN2が合意したように、すべてのRRC状態でデータを受信できるように設計されているため、このオプションはもう1つの簡単な解決策である。しかし、例えば、MCCHの取得が原因で、スイッチング中にパケット損失及び/又は遅延が発生することが予想される可能性がある。
各オプションには長所及び短所があるが、私たちの見解では、単純さ及び効率の観点から、オプション1の方がわずかに望ましい。RAN2は、上記のオプションを考慮するがこれに限定されず、アイドル/インアクティブでデータ受信用の配信モード1設定を提供する方法について議論すべきである。
提案4:提案3に合意できる場合、RAN2は、インアクティブでのデータ受信のための配信モード1設定がUEにどのように提供されるかについて議論すべきである。
(配信モード2設定)
LTE SC-PTMにおいて、設定は2つのメッセージ、即ち、SIB20及びSC-MCCHによって提供される。SIB20は、SC-MCCHスケジューリング情報を提供し、SC-MCCHは、G-RNTI及びTMGIを含むSC-MTCHスケジューリング情報、及び隣接セル情報を提供する。
図18に示すようなLTEの2段階設定の利点は、SC-MCCHスケジューリングが、繰り返し期間、期間、変更期間などの観点でSIB20スケジューリングから独立していることであった。特に、セッションに遅れて参加する、遅延にセンシティブなサービス及び/又はUEに対して、SC-MCCHの頻繁なスケジューリング/更新が容易にした。WIDによると、アプリケーションの1つがグループ通信などであるため、NR MBSでも同様である。
所見1:LTEでは、SIB20及びSC-MCCHを使用した2段階設定が、これらの制御チャネルの異なるスケジューリングに役立つ。これは、NR MBSにも役立つ。
提案5:RAN2は、SC-PTMのSIB20及びSC-MCCHなど、NR MBSのメッセージが異なる2段階設定を使用することに合意すべきである。
提案5に加えて、NR MBSは、WIDに記載されている様々なタイプのユースケースをサポートすることが想定される。NR MBSは、ソフトウェア配信などのロスレスアプリケーションからIPTVなどのUDPタイプのストリーミングまでの要件の他の側面に加えて、ミッションクリティカルやV2Xなどの遅延にセンシティブなアプリケーションから、IoTなどの遅延に寛容なアプリケーションまで、様々な要件に合わせて適切に設計すべきであることは気づかれる。これらのサービスの一部は配信モード2でカバーされる可能性があるが、「高いQoS要件」を持つ他のサービスには配信モード1が必要である。この意味で、gNBにとって、マルチキャストセッションに配信モード2を使用することを選択できることは有益である。
また、RAN2はRRCコネクティッドでのデータ受信を許可することにすでに合意しているため、RRCコネクティッドのUEがMBS設定を受信できるようにするのは簡単である。UEがMCCHを取得するためだけにアイドル/インアクティブに遷移する必要がある場合、意味がない。コネクティッドのUEがMCCHを受信できるようにするのは簡単であるが、スケジューリングの柔軟性(UEには「ギャップ」が必要な場合があるため)及び/又はUEの消費電力(UEはC-RNTI及びG-RNTIに加えて「SC-RNTI」を監視する必要があるため)の点で最適ではない可能性がある。したがって、UEがMCCHまたはRRC再設定を介してMBS設定を受信するかについては、さらに議論が必要になる可能性がある。
これらの2つの課題は残されたままであったが、一般に、私たちの観点からそれらを制限する技術的な理由はないようである。
提案6:RAN2は、ブロードキャストセッションに加えて、配信モード2をマルチキャストセッションに使用できることに合意すべきである。
提案7:配信モード2において、RAN2は、MBS設定がRRCコネクティッドのUEでも受信できることに合意すべきである。MCCHかRRC再設定かは、更なる検討が必要である。
提案6に照らして、配信モード2の制御チャネル設計は、柔軟性及びそのリソース効率を考慮すべきである。そうしないと、例えば、遅延に寛容なサービスと遅延にセンシティブなサービスとが1つの制御チャネルで一緒に設定されている場合に、遅延にセンシティブなサービスからの遅延要件を満たすために、制御チャネルを頻繁にスケジュールする必要があるため、より多くのシグナリングオーバーヘッドが発生する可能性がある。
SA2 SIの目的Aは、5GSを介した一般的なMBSサービスを可能にすることに関するものであり、この機能の恩恵を受ける可能性のある特定されたユースケースには、公共安全、ミッションクリティカル、V2Xアプリケーション、透過的なIPv4/IPv6マルチキャスト配信、IPTV、無線を介したソフトウェア配信、グループ通信、及びIoTアプリケーションが含まれる(但し、これらに限定されない)。
所見2:配信モード2のためのNR MBS制御チャネルは、様々なタイプのユースケースに対して柔軟でリソース効率が必要とされる。
一つの可能性として、図19に示すように、異なるユースケースで設定チャネルを分離する必要があるかどうか検討することである。例えば、一つのMCCHは遅延にセンシティブなサービスを頻繁に提供し、別のMCCHは遅延に寛容なサービスをまばらに提供する。LTE SC-PTMでは、1つのセルは1つのSC-MCCHしか有せないという制限があった。しかしながら、LTEよりも多くのユースケースが想定されることを考慮すると、NR MBSの配信モード2はそのような制限を取り除くべきである。セル内で複数のMCCHが許可されている場合、各MCCHには、特定のサービス用に最適化可能な、繰り返し期間などの異なるスケジューリング設定がある。UEが興味のあるサービスを提供するMCCHをどのように識別するかは更なる検討が必要である。
提案8:配信モード2において、RAN2は、LTEになかった、セルで複数のMCCHがサポートされるかどうかを議論すべきである。
さらに、NRの新しいパラダイムは、オンデマンドSI送信のサポートである。この概念は、配信モード2におけるMCCH、即ち、オンデマンドMCCHに再利用され得る。例えば、遅延に寛容なサービス用のMCCHはオンデマンドで提供されるため、シグナリングのリソース消費を最適化可能である。言うまでもなく、ネットワークには、MCCHを定期的に、即ち、オンデマンドではなく、遅延にセンシティブなサービスなどに提供するための別のオプションがある。
提案9:配信モード2において、RAN2は、LTEになかった、MCCHがオンデマンドベースで提供される場合のオプションについて議論すべきである。
別の可能性として、図19に示すように、これらのメッセージをマージすること、即ち、1段階設定をさらに検討され得る。例えば、SIBは、MTCHスケジューリング情報を直接、即ち、MCCHなしで、提供する。これは、遅延に寛容なサービス及び/又は電力にセンシティブなUEのための最適化を提供するであろう。例えば、UEは、SIB(オンデマンド)を要求してもよく、gNBは、複数のUEからの要求の後に、SIB及び対応するサービスの提供を開始してもよい。これらのUEは、繰り返しブロードキャストされるMCCHを監視する必要がない。
提案10:配信モード2において、RAN2は、MCCHを使用しないマルチキャスト受信(即ち、1段階設定)がサポートされている場合、SIBがMTCHスケジューリング情報を直接提供するなどのオプションについて議論すべきである。
(興味のインディケーション/カウンティング)
LTE eMBMSでは、ネットワークがMBMSセッションの開始/停止を含むMBMSデータ配信の適切な決定をするために、UEの受信/興味サービスを収集する2種類の方法、つまりMBMS興味インディケーション(MII)とMBMSカウンティングが指定された。UEによってトリガされるMIIには、興味を持つMBMS周波数、興味を持つMBMSサービス、MBMS優先度、およびMBMS ROM(受信専用モード)に関連する情報が含まれている。特定のMBMSサービスのカウンティング要求を介してネットワークによってトリガされるカウンティング応答には、興味を持つMBSFNエリアおよびMBMSサービスに関連する情報が含まれている。
これらのメソッドは、さまざまな目的で導入された。MIIはUEがコネクティッド状態の間に興味を持つサービスを引き続き受信できることを保証するため主にネットワークに使用されている。一方、カウンティングは、ネットワークが十分な数のUEがサービスの受信に興味を持っているかどうかを判断できるようにするために使用される。
所見3:LTE e MBMSでは、2種類のUEアシスタンス情報が異なる目的で導入される。即ち、NBのスケジューリングのためにMBMS興味インディケーションが導入され、MCEのセッション制御のためにMBMSカウンティングが導入される。
NR MBSの場合、グループ通信のユースケースなどのマルチキャストサービスが予想され、ネットワークには、コネクティッド状態のUEが受信/興味を持っているMBSサービスに関する完全な知識が既にあるため、例えば、ネットワークのPTP/PTM配信の決定など、UEからのアシスタンス情報はネットワークの役に立たない。ただし、私たちの理解では、同じことは、ブロードキャストサービス及び/又はアイドル/インアクティブ状態のUEには当てはまらない。特にブロードキャストサービスの場合、LTE eMBMSにおいてMIIとのカウンティングによって解決された問題、つまり所見3がNR MBSにまだ存在する。したがって、RAN2は、MIIやカウンティングなどのアシスタンス情報がNR MBSに役立つかどうかについて検討する必要がある。
WIDに記載されているようにROMとSFNとはサポートされていないため、Rel-17ではMIIのMBMS ROM情報とカウンティング応答のMBSFNエリアに関する情報とは必要ないことに注意する。
提案11:RAN2は、たとえば、MBS興味インディケーション及び/又はMBSカウンティングなど、NR MBSのUEアシスタンス情報を導入することに同意する必要がある。
提案11に同意できる場合は、LTE eMBMSに加えて拡張機能を検討する価値がある。LTE eMBMSでは、UEの大部分がRRCアイドル状態でブロードキャストサービスを受信している場合でも、MIIもカウンティングもアイドル状態のUEから情報を収集できない。これは、私たちの理解では、セッション制御及びリソース効率の観点から見たLTE eMBMSの残りの問題の1つである。
NR MBSでは、アイドル/インアクティブ状態のUEにも同じ問題が存在する可能性がある。たとえば、ネットワークは、アイドル/インアクティブ状態のUEがブロードキャストサービスを受信/興味を持っていないかどうかが分からない。したがって、サービスを受けているUEがなくても、ネットワークは、PTM送信を提供し続ける可能性がある。gNBがアイドル/インアクティブ状態のUEの興味を認識している場合、このような不要なPTMは回避されるべきである。逆に、サービスを受信しているアイドル/インアクティブ状態のUEがまだ存在するときにPTMが停止すると、多くのUEが同時に接続を要求する可能性がある。これも望ましくない。
したがって、アイドル/インアクティブ状態のUEから、具体的にはMBMSカウンティングの、UEアシスタンス情報を収集するメカニズムを導入するかどうかを検討する価値がある。言うまでもなく、アイドル/インアクティブ状態のUEは、RRCコネクティッドに遷移せずに情報を報告できることが望ましい。たとえば、MBSサービスに関連付けられたPRACHリソースパーティショニングがそのようなレポートに導入された場合に達成される可能性がある。
提案12:RAN2は、MBSカウンティングなどのUEアシスタンス情報もアイドル/インアクティブ状態のUEから収集されるかどうかを検討する必要がある。