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)による再送処理、及びランダムアクセスプロシージャ等を行う。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は、MBMS(Multimedia Broadcast and Multicast Service)と呼ばれてもよい。なお、MBSのユースケース(サービス種別)としては、公安通信、ミッションクリティカル通信、V2X(Vehicle to Everything)通信、IPv4又はIPv6マルチキャスト配信、IPTV、グループ通信、及びソフトウェア配信等がある。
LTEにおけるMBSの送信方式には、MBSFN(Multicast Broadcast Single Frequency Network)送信及びSC-PTM(Single Cell Point To Multipoint)送信の2種類がある。図6は、実施形態に係る下りリンクの論理チャネル(Logical channel)とトランスポートチャネル(Transport channel)との対応関係を示す図である。
図6に示すように、MBSFN送信に用いる論理チャネルはMTCH(Multicast Traffic Channel)及びMCCH(Multicast Control Channel)であり、MBSFN送信に用いるトランスポートチャネルはMCH(Multicast Channel)である。MBSFN送信は、主にマルチセル送信用に設計されており、複数のセルからなるMBSFNエリアにおいて各セルが同じMBSFNサブフレームで同じ信号(同じデータ)の同期送信を行う。
SC-PTM送信に用いる論理チャネルはSC-MTCH(Single Cell Multicast Traffic Channel)及びSC-MCCH(Single Cell Multicast Control Channel)であり、SC-PTM送信に用いるトランスポートチャネルはDL-SCH(Downlink Shared Channel)である。SC-PTM送信は、主に単一セル送信用に設計されており、セル単位でブロードキャスト又はマルチキャストでのデータ送信を行う。SC-PTM送信に用いる物理チャネルはPDCCH(Physical Downlink Control Channel)及びPDSCH(Physical Downlink Shared Channel)であり、動的なリソース割当が可能になっている。
以下において、SC-PTM伝送方式を用いてMBSが提供される一例について主として説明するが、MBSFN伝送方式を用いてMBSが提供されてもよい。また、MBSがマルチキャストにより提供される一例について主として説明する。このため、MBSをマルチキャストと読み替えてもよい。但し、MBSがブロードキャストにより提供されてもよい。
また、MBSデータとは、MBSにより送信されるデータをいい、MBS制御チャネルとは、MCCH又はSC-MCCHをいい、MBSトラフィックチャネルとは、MTCH又はSC-MTCHをいうものとする。但し、MBSデータは、ユニキャストで送信される場合もある。MBSデータは、MBSパケット又はMBSトラフィックと呼ばれてもよい。
ネットワークは、MBSセッションごとに異なるMBSサービスを提供できる。MBSセッションは、TMGI(Temporary Mobile Group Identity)及びセッション識別子のうち少なくとも1つにより識別され、これらの識別子のうち少なくとも1つをMBSセッション識別子と呼ぶ。このようなMBSセッション識別子は、MBSサービス識別子又はマルチキャストグループ識別子と呼ばれてもよい。
図7は、実施形態に係るMBSデータの配信方法を示す図である。
図7に示すように、MBSデータ(MBS Traffic)は、単一のデータソース(アプリケーションサービスプロバイダ)から複数のUEに配信される。5Gコアネットワークである5G CN(5GC)20は、アプリケーションサービスプロバイダからMBSデータを受信し、MBSデータのコピーの作成(Replication)を行って配信する。
5GC20の観点からは、共有MBSデータ配信(Shared MBS Traffic delivery)及び個別MBSデータ配信(Individual MBS Traffic delivery)の2つの配信方法が可能である。
共有MBSデータ配信では、5G無線アクセスネットワーク(5G RAN)であるNG-RAN10と5GC20との間に接続が確立され、5GC20からNG-RAN10へMBSデータを配信する。以下において、このような接続(トンネル)を「MBS接続」と呼ぶ。
MBS接続は、Shared MBS Traffic delivery接続又は共有トランスポート(shared transport)と呼ばれてもよい。MBS接続は、NG-RAN10(すなわち、gNB200)で終端する。MBS接続は、MBSセッションと1対1で対応していてもよい。gNB200は、自身の判断でPTP(Point-to-Point:ユニキャスト)及びPTM(Point-to-Multipoint:マルチキャスト又はブロードキャスト)のいずれを選択し、選択した方法でUE100にMBSデータを送信する。
他方、個別MBSデータ配信では、NG-RAN10とUE100との間にユニキャストのセッションが確立され、5GC20からUE100へMBSデータを個別に配信する。このようなユニキャストは、PDUセッション(PDU Session)と呼ばれてもよい。ユニキャスト(PDUセッション)は、UE100で終端する。
(第1実施形態)
次に、第1実施形態について説明する。
第1実施形態において、gNB200からPTMで送信されるMBSデータの受信(以下、「PTM受信」と呼ぶ)に必要なMBS設定がユニキャストシグナリングによりgNB200からUE100に送信される場合を主として想定する。ユニキャストシグナリングは、専用シグナリング(Dedicated signalling)と呼ばれることがある。このようなユニキャスト設定を用いることにより、ベアラ設定等の高度なMBS設定をUE100に対し個別に行うことができる。
但し、このようなユニキャスト設定は、RRCコネクティッド状態にあるUE100は受信可能であるものの、RRCアイドル状態又はRRCインアクティブ状態にあるUE100は受信することができない。このため、ユニキャスト設定のみを用いる場合を想定すると、RRCアイドル状態又はRRCインアクティブ状態にあるUE100がMBS受信を行うことができない懸念がある。
第1実施形態は、ユニキャスト設定のみを用いる場合であっても、RRCアイドル状態又はRRCインアクティブ状態にあるUE100がMBS受信を行うことを可能とする実施形態である。
第1実施形態において、RRCコネクティッド状態にあるUE100は、MBS受信に必要なMBS設定を含むユニキャストシグナリングをgNB200から受信する。このようなMBS設定は、MBSベアラに関する設定及びMBSトラフィックチャネルに関する設定(例えばMBSトラフィックチャネルのスケジューリング情報)のうち少なくとも一方を含む。
MBS設定に用いるユニキャストシグナリングは、例えばRRC Reconfigurationメッセージである。MBS設定に用いるユニキャストシグナリングは、RRC Releaseメッセージであってもよい。
RRCコネクティッド状態からRRCアイドル状態又はRRCインアクティブ状態に遷移したUE100は、RRCコネクティッド状態において受信したMBS設定を用いてMBS受信を行う。
一般的に、RRCコネクティッド状態において設定されたUE個別設定(Dedicated configuration)は、UE100がRRCコネクティッド状態から離れる際(特に、RRCアイドル状態又はRRCインアクティブ状態に遷移する際)に破棄される。これに対し、第1実施形態では、RRCコネクティッド状態において設定されたUE個別のMBS設定を破棄せずに維持することにより、RRCアイドル状態又はRRCインアクティブ状態にあるUE100がMBS受信を行うことを可能とする。
図8は、第1実施形態に係る動作例を示す図である。
図8に示すように、ステップS101において、UE100は、gNB200のセルにおいてRRCコネクティッド状態にある。ここで、UE100は、gNB200に対して、RRCアイドル状態又はRRCインアクティブ状態においてMBS受信を継続することを通知してもよい。もしくは、UE100は、gNB200に対して、RRCアイドル状態又はRRCインアクティブ状態においてMBS受信を継続しないことを希望することを通知してもよい。これら通知は、UE100の希望(プリファレンス)の通知であってもよい。これらの通知はMBSセッション識別子(例えばTMGI)と紐づいていてもよい。
ステップS102において、gNB200は、MBS設定を含むRRC ReconfigurationメッセージをUE100に送信する。UE100は、RRC Reconfigurationメッセージを受信する。
RRC Reconfigurationメッセージは、RRCコネクティッド状態において受信したMBS設定をRRCアイドル状態又はRRCインアクティブ状態において使用可能とするか否か(又はMBS受信を継続してもよいか否か)を示す使用可否情報を含んでもよい。
ステップS103において、UE100は、受信したRRC Reconfigurationメッセージに含まれるMBS設定を記憶及び適用する。
ステップS104において、UE100は、ステップS103で適用したMBS設定を用いて、gNB200からMBSデータ(MBSトラフィックチャネル)を受信する。
その後、ステップS105において、gNB200は、UE100をRRCアイドル状態又はRRCインアクティブ状態に遷移させるためのRRC ReleaseメッセージをUE100に送信する。UE100は、RRC Releaseメッセージを受信する。
RRC Releaseメッセージは、上述の使用可否情報を含んでもよい。RRC Releaseメッセージが使用可否情報を含む場合、RRC Reconfigurationメッセージは使用可否情報を含まなくてもよい。
ステップS106において、UE100は、RRCコネクティッド状態からRRCアイドル状態又はRRCインアクティブ状態に遷移する。
ステップS107において、UE100は、ステップS103で記憶及び適用したMBS設定を破棄せずに維持する。UE100は、RRC Reconfigurationメッセージ又はRRC Releaseメッセージが使用可否情報を含み、且つ、使用可否情報が「使用可」を示す場合、MBS設定を破棄せずに維持してもよい。他方、RRC Reconfigurationメッセージ又はRRC Releaseメッセージが使用可否情報を含み、且つ、使用可否情報が「使用不可」を示す場合、UE100は、MBS設定を破棄してもよい。
ステップS108において、UE100は、gNB200からのMBS受信を継続する。
(第1実施形態の変更例1)
次に、第1実施形態の変更例1について説明する。
上述の第1実施形態において、RRCアイドル状態又はRRCインアクティブ状態にあるUE100は、ネットワーク(gNB200)から制御できないため、一旦設定したMBS設定がいつまで有効なのかという問題が生じる。RRCアイドル状態又はRRCインアクティブ状態にあるUE100が永続的にMBS設定を使用可能である場合、ネットワーク側ではMBS設定を変更したくても変更できない。ネットワーク側でMBS設定を変更すると、UE100のMBS受信が出来ない状態になるためである。他方、UE100は、ネットワーク側でのMBS設定変更に事前に気付けないため、MBS受信が出来なくなってMBS設定変更に初めて気付くことになる。
第1実施形態の変更例1において、RRCコネクティッド状態にあるUE100は、MBS設定の受信時点、又はRRCアイドル状態又はRRCインアクティブ状態への遷移時点からのMBS設定の有効期間を示す情報をgNB200から受信する。このような有効期間をMBS設定について定めることにより、上述の問題を解決できる。
RRCコネクティッド状態にあるUE100は、MBS設定の有効期間を示す情報と、有効期間を示す情報と対応付けられたMBSセッション識別子(例えばTMGI)とを受信してもよい。これにより、MBSセッション(MBSサービス)ごとにMBS設定の有効期間を定めることができる。
RRCアイドル状態又はRRCインアクティブ状態に遷移してMBS受信を行うUE100は、MBS設定の有効期間の満了に応じて、RRCコネクティッド状態に遷移して新たなMBS設定を取得してもよい。これにより、MBS設定の有効期間の満了後にも、MBS受信を継続可能とすることができる。
図9は、第1実施形態の変更例1を示す図である。ここでは、上述の第1実施形態との相違点を主として説明する。
図9に示すように、ステップS201において、UE100は、gNB200のセルにおいてRRCコネクティッド状態にある。
ステップS202において、gNB200は、MBS設定を含むRRC ReconfigurationメッセージをUE100に送信する。UE100は、RRC Reconfigurationメッセージを受信する。
RRC Reconfigurationメッセージは、MBS設定の有効期間を示す情報(タイマ値)を含んでもよい。ここで、MBS設定の有効期間は、ステップS202で設定がされた時点からの有効期間であってもよい。MBS設定の有効期間は、UE100がRRCアイドル状態又はRRCインアクティブ状態に遷移した時点(後述のステップS206)からの有効期間であってもよい。MBS設定の有効期間は、例えばgNB200がMBS設定を変更しない期間(modification period)、又はMBSセッションが終了する予定時間までの期間に従って設定されてもよい。MBS設定の有効期間を、ステップS202で設定がされた時点からの有効期間とする場合、UE100は、ステップS202で設定がされた際に、MBS設定の有効期間をセットしたタイマ(有効期間タイマ)を始動する。
ステップS203において、UE100は、受信したRRC Reconfigurationメッセージに含まれるMBS設定を記憶及び適用する。
ステップS204において、UE100は、ステップS203で適用したMBS設定を用いて、gNB200からMBSデータ(MBSトラフィックチャネル)を受信する。
その後、ステップS205において、gNB200は、UE100をRRCアイドル状態又はRRCインアクティブ状態に遷移させるためのRRC ReleaseメッセージをUE100に送信する。UE100は、RRC Releaseメッセージを受信する。
RRC Releaseメッセージは、MBS設定の有効期間を示す情報(タイマ値)を含んでもよい。ここで、MBS設定の有効期間は、UE100がRRCアイドル状態又はRRCインアクティブ状態に遷移した時点(すなわち、RRC Releaseメッセージの受信時点)からの有効期間であってもよい。MBS設定の有効期間は、例えばgNB200がMBS設定を変更しない期間、又はMBSセッションが終了する予定時間までの期間に従って設定されてもよい。UE100は、RRC Releaseメッセージを受信した際に、MBS設定の有効期間をセットしたタイマ(有効期間タイマ)を始動する。
ステップS206において、UE100は、RRCインアクティブ状態からRRCアイドル状態又はRRCインアクティブ状態に遷移する。
ステップS207において、UE100は、ステップS203で記憶及び適用したMBS設定を破棄せずに維持する。
ステップS208において、UE100は、有効期間タイマが満了するまで、gNB200からのMBS受信を継続する。
有効期間タイマが満了した場合(ステップS209:YES)、ステップS210において、UE100は、MBS受信中止処理を行う。MBS受信中止処理は、MBS受信を停止する処理、MBS設定の適用を解除する処理、及びMBS設定を破棄する処理のうち、少なくとも1つを含む。
有効期間タイマが満了し、UE100がMBS受信の継続を希望する場合、ステップS211において、UE100は、gNB200との接続処理を行う。
例えば、RRCアイドル状態にあるUE100は、RRC Setupプロシージャを開始する。RRC Setupプロシージャにおいて、UE100は、MBS受信設定の取得が目的であることを示す情報をRRC Setup Requestメッセージ中の情報要素(例えばCause)として含めてもよい。
RRCインアクティブ状態にあるUE100は、RRC Resumeプロシージャを開始する。RRC Resumeプロシージャにおいて、UE100は、MBS受信設定の取得が目的であることを示す情報をRRC Resume Requestメッセージ中の情報要素(例えばCause)として含めてもよい。
gNB200との接続処理によりUE100がRRCコネクティッド状態に遷移(ステップS212)した後、ステップS213において、UE100は、新たなMBS設定を含むRRC ReconfigurationメッセージをgNB200から受信する。
本動作例において、ユニキャストでのMBS設定のみを用いる場合を想定しているが、ブロードキャストでのMBS設定も併用される場合を想定してもよい。UE100は、有効期間タイマが満了した場合(ステップS209:YES)、MBS受信中止処理(ステップS210)を行うとともに、gNB200からブロードキャストで送信されるMBS制御チャネルからMBS設定を取得してもよい。
本変更例において、MBS設定の有効期間は、MBSセッション(TMGI)ごとに別であってもよいし、全てのMBSセッションに共通(1つだけ)であってもよい。MBS設定の有効期間がMBSセッションごとに別である場合、UE100は、UE100が受信するMBSセッションに対応する有効期間をタイマにセットする。
(第1実施形態の変更例2)
次に、第1実施形態の変更例2について説明する。
上述のように、ネットワーク(gNB200)側でMBS設定の変更(例えばリソース変更等)を行うと、RRCアイドル状態又はRRCインアクティブ状態にあるUE100は、希望するMBSセッションを受信できなくなってしまう虞がある。
第1実施形態の変更例2において、RRCアイドル状態又はRRCインアクティブ状態に遷移してMBS受信を行うUE100は、MBS設定の更新を示す通知をgNB200から受信する。UE100は、当該通知の受信に応じて、RRCコネクティッド状態に遷移して新たなMBS設定を取得する。これにより、UE100は、新たなMBS設定を用いてMBS受信を継続できる。
図10は、第1実施形態の変更例2を示す図である。ここでは、上述の第1実施形態との相違点を主として説明する。
図10に示すように、ステップS301乃至S308は、上述の第1実施形態のステップS101乃至S108と同様である。但し、ステップS302において、gNB200は、UE100へのMBS設定時に、当該MBS設定と紐づいた設定識別子(value tag値)をUE100に通知してもよい。
ステップS309において、gNB200は、MBS設定の変更を決定する。例えば、gNB200は、PTM送信のリソース(時間・周波数リソース)の変更及びPTM送信の停止・開始の少なくとも一方を決定する。
ステップS310において、gNB200は、RRCアイドル状態又はRRCインアクティブ状態にあるUE100に対して通知を行う。
ステップS310の通知は、gNB200がブロードキャストするシステム情報(SIB:System Information Block)であってもよい。当該通知は、MBS設定に変更がある旨の通知及び/又はある一定期間内に変更予定である旨の通知であってもよいし、接続処理(例えばRRC Setup)を行う指示であってもよい。当該通知は、MBS設定に変更があるMBSセッションの識別子(例えばTMGI)を含んでもよい。
gNB200は、現在有効なMBS設定のvalue tag値をSIBに含めてもよい。なお、gNB200は、MBS設定を変更するたびにvalue tag値をカウントアップ(インクリメント)する。UE100は、ステップS302でgNB200から通知されたvalue tag値と、ステップS310でgNB200から受信したSIBに含まれるvalue tag値とが同じである場合には、現在のMBS設定が有効と判断し、value tag値が異なる場合には、現在のMBS設定が無効であると判断する。
ステップS310の通知は、MBS設定に変更があるMBSセッションの識別子を含むページングメッセージであってもよい。例えば、gNB200は、ページングメッセージに含まれるページングレコードの中に、設定変更が必要なMBSセッション識別子を入れる。UE100は、UE100の所望のMBSセッション識別子がページングレコードの中にある場合、MBS設定の再取得が必要であると判断する。なお、UE100は、通常のページング機会のみモニタすればよい。gNB200は、ある一定期間における全てのUE100のページング機会において、MBSセッション識別子を含むページングメッセージを送信する。
ステップS311において、MBS受信の継続を希望するUE100は、ステップS310の通知の受信に応じて、上述のMBS受信中止処理(ステップS311)を行うとともに、上述の接続処理(ステップS312)を行う。そして、ステップS313において、UE100は、RRCコネクティッド状態に遷移後、新たなMBS受信設定を取得してMBS受信を継続する。このような動作は、第1実施形態の変更例1と同様である。
(第1実施形態の変更例3)
次に、第1実施形態の変更例3について説明する。
本変更例において、RRCコネクティッド状態において適用するMBS設定と、RRCアイドル状態又はRRCインアクティブ状態において適用するMBS設定とが異なる場合を想定する。
本変更例において、gNB200からUE100に対して送信するユニキャストシグナリング(RRC Reconfigurationメッセージ)は、RRCコネクティッド状態におけるMBS受信に必要な第1MBS設定と、RRCアイドル状態又はRRCインアクティブ状態におけるMBS受信に必要な第2MBS設定とを含む。
図11は、第1実施形態の変更例3を示す図である。ここでは、上述の第1実施形態との相違点を主として説明する。
図11に示すように、ステップS401において、UE100は、gNB200のセルにおいてRRCコネクティッド状態にある。
ステップS402において、gNB200は、第1MBS設定及び第2MBS設定を含むRRC ReconfigurationメッセージをUE100に送信する。UE100は、RRC Reconfigurationメッセージを受信する。
第1MBS設定は、RRCコネクティッド状態用のMBS受信設定である。第1MBS設定は、MBSベアラ設定情報を含む。第1MBS設定において、MBSベアラとMBSセッション識別子(例えばG-RNTI)とが対応付けられていてもよい。第1MBS設定は、RRCコネクティッド状態用の設定である旨の識別子を含んでもよいし、RRCアイドル状態又はRRCインアクティブ状態で当該設定を用いてはならない旨の識別子を含んでもよい。
第1MBS設定は、必ずしもRRCコネクティッド状態に専用でなくてもよい。第1MBS設定は、RRCアイドル状態又はRRCインアクティブ状態でも当該設定を用いてもよい旨の識別子を含んでもよい。
他方、第2MBS設定は、RRCアイドル状態又はRRCインアクティブ状態用のMBS受信設定である。第2MBS設定は、MBSトラフィックチャネルに関する設定情報(例えばスケジューリング情報)を含む。第2MBS設定は、RRCアイドル状態又はRRCインアクティブ状態用の受信設定である旨の識別子を含んでもよいし、RRCコネクティッド状態で当該設定を用いてはならない旨の識別子を含んでもよい。第2MBS設定において、RRCアイドル状態用の設定とRRCインアクティブ状態用の設定とが別々に設けられてもよい。
第2MBS設定は、必ずしもRRCアイドル状態又はRRCインアクティブ状態に専用でなくてもよい。第2MBS設定は、RRCコネクティッド状態でも当該設定を用いてもよい旨の識別子を含んでもよい。
ステップS403において、UE100は、受信したRRC Reconfigurationメッセージに含まれる第1MBS設定を記憶及び適用するとともに第2MBS設定を記憶する。
ステップS404において、UE100は、ステップS403で適用した第1MBS設定を用いて、gNB200からMBSデータを受信する。ここで、UE100は、RRCコネクティッド状態にも有効な第2MBS設定を適用してもよい。UE100は、RRCアイドル状態又はRRCインアクティブ状態にのみ有効な第2MBS設定は適用しない。
その後、ステップS405において、gNB200は、UE100をRRCアイドル状態又はRRCインアクティブ状態に遷移させるためのRRC ReleaseメッセージをUE100に送信する。UE100は、RRC Releaseメッセージを受信する。
ステップS406において、UE100は、RRCコネクティッド状態からRRCアイドル状態又はRRCインアクティブ状態に遷移する。
ステップS407において、UE100は、第1MBS設定に含まれる識別子及び第2MBS設定に含まれる識別子に応じた処理を行う。例えば、UE100は、RRCコネクティッド状態にのみ有効な第1MBS設定を破棄する。但し、UE100がRRCインアクティブ状態の場合は当該第1MBS設定を保持してもよい。UE100は、RRCアイドル状態又はRRCインアクティブ状態に有効な第2MBS設定を保持する(破棄しない)、もしくは、適用を継続する(もしくは、改めて適用する)。
ステップS408において、UE100は、ステップS407で適用した第2MBS設定を用いて、gNB200からMBSデータを受信する。
(第2実施形態)
次に、第2実施形態について、第1実施形態との相違点を主として説明する。
第2実施形態において、ユニキャストでのMBS設定及びブロードキャストでのMBS設定が併存する場合を想定する。このような2通りの設定方法がある場合、UE100は、MBS受信に際して、どの方法に従ってMBS設定を取得するべきかを適切に決定する必要がある。
第2実施形態において、gNB200は、MBS受信に必要な第1MBS設定がユニキャストシグナリングにより提供される第1MBSセッションを示す第1識別子(第1MBSセッション識別子)、及びMBS受信に必要な第2MBS設定がブロードキャストシグナリングにより提供される第2MBSセッションを示す第2識別子(第2MBSセッション識別子)のうち、少なくとも一方を含むブロードキャストメッセージをUE100に送信する。このブロードキャストメッセージは、ブロードキャスト制御チャネルで送信するSIBであってもよいし、MBS制御チャネルで送信するMBS制御情報であってもよい。
これにより、UE100は、MBS受信に際して、ユニキャスト設定及びブロードキャスト設定のうちどの方法に従ってMBS設定を取得するべきかを適切に決定できる。UE100は、gNB200からのブロードキャストメッセージと、UE100の所望MBSセッションとに基づいて、第1MBS設定(すなわち、ユニキャストでのMBS設定)及び第2MBS設定(すなわち、ブロードキャストでのMBS設定)のいずれかをgNB200から受信する。
図12は、第2実施形態に係る動作例を示す図である。
図12に示すように、ステップS501において、gNB200は、ユニキャストシグナリング(例えばRRC Reconfigurationメッセージ)でMBS設定を受信しなければならないサービス(第1MBSセッション識別子)、及び/又はブロードキャストシグナリング(例えばSC-MCCH)で設定を受信可能なサービス(第2MBSセッション識別子)をSIBによりUE100(UE100A、UE100B)に通知する。すなわち、gNB200は、SIB(もしくはSC-MCCH)にて、MBSセッション識別子ごとにMBS設定の取得方法をブロードキャストする。
図12において、ユニキャスト設定が適用されるMBSセッション(第1MBSセッション識別子)がMBSセッション#1であり、ブロードキャスト設定が適用されるMBSセッション(第2MBSセッション識別子)がMBSセッション#2である一例を示している。
例えば、ユニキャスト設定が適用されるMBSセッションは、マルチキャスト系のサービス(例えば、グループ通信)に属するMBSセッションである。これに対し、ブロードキャスト設定が適用されるMBSセッションは、ブロードキャスト系のサービス(例えば、放送関係、IPTV)に属するMBSセッションである。
ステップS502において、マルチキャスト系のサービスの受信を希望するUE100Aは、gNB200からのSIBに基づいて、MBSセッション#1の受信を決定する。他方、ステップS503において、ブロードキャスト系のサービスの受信を希望するUE100Bは、gNB200からのSIBに基づいて、MBSセッション#2の受信を決定する。
ステップS504において、UE100Aは、自身がRRCアイドル状態又はRRCインアクティブ状態にある場合、第1MBS設定を受信するためにRRCコネクティッド状態に遷移する処理(接続処理)を行う。
ステップS505において、UE100Aは、第1MBS設定を含むRRC ReconfigurationメッセージをgNB200から受信する。
ステップS506において、UE100Aは、ステップS505で受信した第1MBS設定を適用することにより、MBSセッション#1のMBSデータをgNB200から受信する。
他方、ステップS507において、UE100Bは、第2MBS設定を含むMBS制御チャネルをgNB200から受信する。例えば、UE100Bは、自身がRRCコネクティッド状態にある場合、gNB200からのRRC ReconfigurationメッセージでのMBS設定獲得を期待せずに、MBS制御チャネル(例えばSC-MCCH)の受信を試みる。RRCコネクティッド状態にあるUE100は、RAI(Release Assistance Information)をgNB200に送信することによりRRC接続を解放してもらい、RRCアイドル状態又はRRCインアクティブ状態に遷移してもよい。
ステップS508において、UE100Bは、ステップS507で受信した第2MBS設定を適用することにより、MBSセッション#2のMBSデータをgNB200から受信する。
なお、本動作例において、gNB200は、自身が提供可能なMBSセッション識別子をブロードキャストしているとみなすことができる。UE100は、gNB200が提供不可のMBSセッションの受信に興味がある場合、ユニキャストセッションを5GC20と確立することで当該MBSセッションのMBSデータを受信してもよい。
また、本動作例において、gNB200は、MBS設定がユニキャストシグナリング及びブロードキャストシグナリングの両方で提供される第3MBSセッションを示す第3識別子(第3MBSセッション識別子)をさらに含むブロードキャストメッセージをUE100に送信してもよい。
(第3実施形態)
次に、第3実施形態について、第1及び第2実施形態との相違点を主として説明する。
第3実施形態において、gNB200の1つのセルに複数のMBS制御チャネル(例えば複数のSC-MCCH)が構成される場合を想定する。これにより、例えばMBSセッションのサービス要件に応じてMBS制御チャネルを使い分けることができる。
このような複数のMBS制御チャネルが構成される場合、各MBS制御チャネルを伝送するためのPDCCHのRNTIが異なることが考えられる。具体的には、gNB200の物理レイヤにおいて、あるMBS制御チャネルを伝送する際に、当該MBS制御チャネル用のRNTIを適用したPDCCHをUE100に送信することで、MBS設定を運ぶPDSCHのリソースをUE100に割り当てる。
このように、MBS制御チャネルごとにRNTIが異なる場合、どのRNTIがどのMBS制御チャネルを伝送するのかを指定する必要がある。
第3実施形態において、1つのセルにおいて複数のMBS制御チャネルを提供するgNB200は、当該複数のMBS制御チャネルのそれぞれについて、該MBS制御チャネルの受信に用いるRNTIを含むブロードキャストメッセージをUE100に送信する。このブロードキャストメッセージは、ブロードキャスト制御チャネルで送信するSIBであってもよい。
MBS制御チャネルの受信に用いるRNTIとは、MBS制御チャネルに適用するRNTI(以下、「SC-RNTI」と呼ぶ)であってもよいし、MBS制御チャネルの変更通知(Change Notification)に適用するRNTI(以下、「SC-N-RNTI」と呼ぶ)であってもよい。
図13は、第3実施形態に係る動作例を示す図である。
図13に示すように、ステップS601において、gNB200は、各MBS制御チャネルの設定情報を含むSIBをブロードキャストする。この設定情報は、MBS制御チャネルごとのSC-RNTI値を含んでもよいし、MBSセッション識別子ごとのSC-RNTI値を含んでもよい。この設定情報は、MBS制御チャネルごとのSC-N-RNTI値を含んでもよいし、MBSセッション識別子ごとのSC-N-RNTI値を含んでもよい。
図13に示す例において、SIBは、MBS制御チャネル#1について、RNTI(SC-RNTI及び/又はSC-N-RNTI)#1とMBSセッション識別子#1とのセットを含む。また、SIBは、MBS制御チャネル#2について、RNTI(SC-RNTI及び/又はSC-N-RNTI)#2とMBSセッション識別子#2とのセットを含む。
ステップS602において、UE100Aは、gNB200からのSIBに基づいて、MBSセッション#1の受信を決定する。そして、ステップS603において、UE100Aは、gNB200からのSIBに基づいて、MBSセッション#1に対応するRNTI#1を適用してMBS制御チャネル#1の受信を試みる。
他方、ステップS604において、UE100Bは、gNB200からのSIBに基づいて、MBSセッション#2の受信を決定する。そして、ステップS605において、UE100Bは、gNB200からのSIBに基づいて、MBSセッション#2に対応するRNTI#2を適用してMBS制御チャネル#2の受信を試みる。
ステップS606において、UE100Aは、gNB200からMBS制御チャネル#1を受信する。ステップS607において、UE100Aは、ステップS606で受信したMBS制御チャネル#1に含まれるMBS設定を用いて、MBSセッション#1のMBSデータをgNB200から受信する。
他方、ステップS608において、UE100Bは、gNB200からMBS制御チャネル#2を受信する。ステップS609において、UE100Bは、ステップS608で受信したMBS制御チャネル#2に含まれるMBS設定を用いて、MBSセッション#2のMBSデータをgNB200から受信する。
(第4実施形態)
次に、第4実施形態について、第1乃至第3実施形態との相違点を主として説明する。第4実施形態は、RRCアイドル状態又はRRCインアクティブ状態にあるUE100が行うセル再選択に関する実施形態である。
LTEでは、興味のある又は受信中のMBMSセッションが提供される周波数を最高優先度としてセル再選択を行うメカニズムが導入されている。しかしながら、当該メカニズムでは、どの周波数(又はどのセル)を再選択するのかはUE100依存であり、ネットワーク視点では制御不能な状態になる。このため、ネットワーク制御を可能としつつ、UE100が希望するMBSセッションを受信できるようにする方式が望まれる。
第4実施形態において、gNB200は、セル再選択におけるセル又は周波数ごとの優先度を示す優先度情報と、当該優先度情報と対応付けられたMBSセッション識別子とを含むセル再選択制御情報を送信する。RRCアイドル状態又はRRCインアクティブ状態にあるUE100は、gNB200からのセル再選択制御情報に基づいて、当該UE100の所望のMBSセッション識別子に対応する優先度情報を用いてセル再選択を行う。これにより、ネットワーク制御を可能としつつ、UE100が希望するMBSセッションを受信可能なセル再選択制御を実現できる。
図14は、第4実施形態に係る動作例を示す図である。
図14に示すように、ステップS701において、UE100は、RRCアイドル状態又はRRCインアクティブ状態にあってもよい。
ステップS702において、gNB200は、MBSセッションごとに優先度情報(cell reselection priority)をUE100に通知する。例えば、gNB200は、MBSセッションと対応付けられた優先度情報を含むSIBをブロードキャストする。或いは、gNB200は、MBSセッションと対応付けられた優先度情報を含むユニキャストシグナリング(例えばRRC Releaseメッセージ)をUE100に送信してもよい。MBSセッションと対応付けられた優先度情報を含むRRC ReleaseメッセージをUE100に送信する場合、UE100は、このRRC Releaseメッセージの受信に応じて、RRCコネクティッド状態からRRCアイドル状態又はRRCインアクティブ状態に遷移する。以下において、SIBを用いる一例について説明するが、SIBに代えてRRC Releaseメッセージを用いてもよい。
SIBは、MBSセッション識別子と、セル及び/又は周波数の優先度情報とのセットを複数含む。図14に示す例において、MBSセッション識別子#1に対して優先度情報#1が対応付けられ、MBSセッション識別子#2に対して優先度情報#2が対応付けられる。優先度情報#1は、周波数#1が高優先度、周波数#2が中優先度、周波数#3が低優先度といった情報である。優先度情報#2は、周波数#1が低優先度、周波数#2が中優先度、周波数#3が高優先度といった情報である。例えば、高速通信が求められるMBSセッションについては高い周波数が優先され、高信頼性が求められるMBSセッションについては低い周波数が優先されるといった優先度付けがなされている。なお、これら優先度情報は、周波数ではなく、セルIDと紐づいていてもよい。
ステップS703において、UE100は、自身の所望MBSセッションと、gNB200からのSIBとに基づいて、自身の所望MBSセッションに対応する優先度情報を用いてセル再選択を制御する。このセル再選択制御において、UE100は、優先度情報により高い優先度が付与された周波数(又はセル)を優先的に選択する。
ここで、UE100内において、上位レイヤ(NASレイヤ)から下位レイヤ(ASレイヤ)に対して所望MBSセッションが通知され、ASレイヤがこれを用いてセル再選択制御を行ってもよい。また、所望MBSセッションが複数存在する場合、上位レイヤ(NASレイヤ)から下位レイヤ(ASレイヤ)に対してMBSセッションごとの受信優先度が通知され、下位レイヤ(ASレイヤ)は、最高の受信優先度を有するMBSセッションに対応する優先度情報を用いてセル再選択制御を行ってもよい。
なお、本動作例において、SIBは、MBSセッション識別子と紐づかない従来型の優先度情報をさらに含んでもよい。このような従来型の優先度情報は、MBSをサポートしないレガシーUEや、MBS受信に興味がないUE100が使用するものとする。
ところで、MBSセッションがネットワークスライスと紐づいている場合、gNB200は、ネットワークスライス毎に周波数・セルの優先度情報を報知してもよい。当該MBSセッション識別子(TMGI等)とネットワークスライス識別子(S-NSSAI等)の紐づけ情報は、コアネットワークからUE100及び/又はgNB200に通知されてもよい。UE100は、受信を希望するMBSセッションに紐づいたネットワークスライスにおける周波数・セルの優先度情報に従ってセル(再)選択処理を行う。
このような実施例においては、上述の第4実施形態におけるMBSセッション識別子をネットワークスライス識別子と読み替えてもよい。具体的には、gNB200は、セル再選択におけるセル又は周波数ごとの優先度を示す優先度情報と、当該優先度情報と対応付けられたネットワークスライス識別子とを含むセル再選択制御情報を送信する。RRCアイドル状態又はRRCインアクティブ状態にあるUE100は、gNB200からのセル再選択制御情報に基づいて、当該UE100の所望のネットワークスライスに対応する優先度情報を用いてセル再選択を行う。
(第5実施形態)
次に、第5実施形態について、第1乃至第4実施形態との相違点を主として説明する。第5実施形態は、RRCコネクティッド状態にあるUE100が行うRRC再確立(RRC Reestablishment)に関する実施形態である。
RRCコネクティッド状態にあるUE100が、MBSセッション受信中に無線リンク障害(RLF)を検知し、RRC再確立処理を開始した場合、RRC再確立処理中のセル選択において当該MBSセッションを提供しないセルを選択してしまうと、MBS受信の中断が発生する虞がある。第5実施形態では、RRC再確立処理中のセル選択において当該MBSセッションを提供するセルを優先して選択することで、MBS受信の継続性を向上させる。
第5実施形態において、RRCコネクティッド状態においてMBSセッションを受信するUE100は、RRC再確立処理を開始すると、RRC再確立処理においてセル選択を行う。セル選択において、UE100は、当該MBSセッションを提供するセルを優先して選択する。これにより、MBS受信の継続性を向上させることができる。
図15は、第5実施形態に係る動作例を示す図である。
図15に示すように、ステップS801において、UE100は、gNB200Aのセル#1においてRRCコネクティッド状態にある。
ステップS802において、UE100は、gNB200AからMBSセッションのMBSデータを受信する。
ステップS803において、UE100は、隣接セルであるセル#2が提供するMBSセッションのMBSセッション識別子を含む隣接セル情報をgNB200Aから受信してもよい。
ステップS804において、UE100は、gNB200AとのRLFを検知し、RRC再確立処理を開始する。
ステップS805において、UE100は、セルサーチ時に、gNB200B(セル#2)がブロードキャストするMBS情報を受信してもよい。このMBS情報は、セル#2が提供するMBSセッションのMBSセッション識別子を含むSIBであってもよい。
ステップS806において、UE100は、ステップS803又はステップS805で受信した情報に基づいて、gNB200A(セル#2)が提供するMBSセッションを特定する。
ステップS807において、UE100は、ステップS802で受信していたMBSセッションをgNB200A(セル#2)が提供するか否かを判定する。
ステップS802で受信していたMBSセッションをgNB200A(セル#2)が提供すると判定した場合(ステップS807:YES)、ステップS808において、UE100は、セル#2を選択する。
ステップS809において、UE100は、選択したセル#2にアクセスし、RRC再確立を行うことにより、受信中の(興味のある)MBSセッションの受信を継続する。
(第6実施形態)
次に、第6実施形態について、第1乃至第5実施形態との相違点を主として説明する。
NRにおいて、1つのセルの周波数帯域幅よりも狭い帯域幅部分(BWP(Bandwidth part))をUE100に設定することで、UE100の動作帯域幅を限定することが可能であり、このようなBWPがMBS用に導入される可能性がある。このようなMBS用のBWPが導入された場合、MBS用のBWPがMBS設定でUE100に通知されると考えられる。しかしながら、MBS用のBWPの情報がMBS設定に含まれない場合、UE100はMBS用のBWPを特定することができず、予期せぬエラーが発生する虞がある。
第6実施形態において、UE100は、gNB200が用いるイニシャルBWPを示す情報をgNB200から受信する。イニシャルBWPとは、SIBにより通知されるBWPであって、UE100がgNB200への初期アクセスに用いるBWPをいう。UE100は、UE100向けのBWP設定をgNB200から受信するまではイニシャルBWPを用いる。
また、UE100は、MBS受信に必要なMBS設定をgNB200から受信する。ここで、MBS設定にBWP設定が含まれない場合、UE100は、イニシャルBWPを用いてMBS受信を行う。このように、MBS設定に不備がある場合のUE100の挙動を規定することにより、予期せぬエラーが発生する可能性を低減できる。
図16は、第6実施形態に係る動作例を示す図である。
図16に示すように、ステップS901において、UE100は、イニシャルBWP情報を含むSIBをgNB200から受信する。
ステップS902において、UE100は、MBS設定をgNB200から受信する。
ステップS903において、UE100は、gNB200から受信したMBS設定にMBS用BWPの設定が含まれているか否かを判定する。
gNB200から受信したMBS設定にMBS用BWPの設定が含まれている場合(ステップS903:YES)、ステップS904において、UE100は、当該MBS用BWPの設定を適用する。
これに対し、gNB200から受信したMBS設定にMBS用BWPの設定が含まれていない場合(ステップS903:NO)、ステップS905において、UE100は、PTMのMBSデータがイニシャルBWPで送信されてくるものと判断(仮定)する。MBS用BWPのデフォルト値がイニシャルBWPとして設定されていてもよい。
ステップS906において、UE100は、設定したBWPにおいて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(System on a chip))として構成してもよい。
以上、図面を参照して実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
本願は、米国仮出願第63/104044号(2020年10月22日出願)の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
(付記)
・導入
NRマルチキャスト及びブロードキャストサービス(MBS)に関する改訂されたワークアイテムが承認された。ワークアイテムの目的は次の通りである。
-RRCコネクティッド状態のUEのブロードキャスト/マルチキャストのRAN基本機能を規定する。
-UEがブロードキャスト/マルチキャストサービスを受信できるようにするグループスケジューリングメカニズムを規定する。
-この目的には、ユニキャスト受信との同時操作を可能にするために必要な拡張機能を規定することが含まれる。
-既定のUEのサービス継続性を備えたマルチキャスト(PTM)とユニキャスト(PTP)との間のブロードキャスト/マルチキャストサービス配信の動的変更のサポートを規定する。
-サービス継続性を備えた基本的なモビリティのサポートを規定する。
-(MCEによってホストされる機能などの)必要な調整機能がgNB-CUにあると想定して、ブロードキャスト/マルチキャストにおけるSA2 SIの結果を考慮して、RANアーキテクチャ及びインターフェイスに必要な変更を規定する。
-例えば、ULフィードバックによって、ブロードキャスト/マルチキャストサービスの信頼性を向上させるために必要な変更を規定する。信頼性のレベルは、提供されるアプリケーション/サービスの要件に基づくべきである。
-1つのgNB-DU内のブロードキャスト/マルチキャスト送信エリアの動的制御のサポートを研究し、それを有効にするために必要なものがある場合はそれを規定する。
-RRCアイドル/RRCインアクティブ状態のUEのブロードキャスト/マルチキャストのRAN基本機能を規定する。
-PTM受信の設定についてRRCコネクティッド状態とRRCアイドル/RRCインアクティブ状態の間で共通性を最大限維持することを目的として、RRCアイドル/RRCインアクティブ状態のUEによるPoint to Multipoint送信の受信を可能にするために必要な変更を規定する。
RAN2#111-eでは、多くの企業がアイドル/インアクティブ状態のUEにLTE SC-PTMメカニズムを再利用することを提案したが、議長が次のように要約したように、多くの企業はコネクティッドとアイドル/インアクティブ状態の解決策に大きな違いがあると考えた。
-議長:多くの企業は、アイドル及びコネクティッド状態の解決策には大きな違いがあると考えている。それが最終的に何を意味するかさらなる検討が必要である。
-議長の見解:アイドル用/非アクティブNR用のLTE SC-PTMを(かなりの程度または100%)再利用するための多くの提案。一部の企業は、アイドル/非アクティブ配信に対しても接続して制御などを行うことを提案している。
この付記では、NR MBSのコントロールプレーンの考慮事項について検討する。
・議論
LTE SC-PTMにおいて、設定は2つのメッセージ、即ち、SIB20及びSC-MCCHによって提供される。SIB20は、SC-MCCHスケジューリング情報を提供し、SC-MCCHは、G-RNTI及びTMGIを含むSC-MTCHスケジューリング情報、及び隣接セル情報を提供する。
図17に示すようなLTEの2段階設定の利点は、SC-MCCHスケジューリングが、繰り返し期間、期間、変更期間などの観点でSIB20スケジューリングから独立していることであった。2段階設定は、特に、セッションに遅れて参加する、遅延にセンシティブなサービス及び/又はUEに対して、SC-MCCHの頻繁なスケジューリング/更新を容易にした。WIDによると、アプリケーションの1つがグループ通信などであるため、NR MBSでも同様である。
所見1:LTEでは、SIB20及びSC-MCCHを使用した2段階設定が、これらの制御チャネルの異なるスケジューリングに役立つ。これは、NR MBSにも役立つ。
提案1:RAN2は、SC-PTMのSIB20やSC-MCCHなど、NR MBSのメッセージが異なる2段階設定を使用することに合意すべきである。
提案1に加えて、NR MBSは、WIDに記載されている様々なタイプのユースケースをサポートすることが想定される。NR MBSは、ソフトウェア配信などのロスレスアプリケーションからIPTVなどのUDPタイプのストリーミングまでの要件の他の側面に加えて、ミッションクリティカルやV2Xなどの遅延にセンシティブなアプリケーションから、IoTなどの遅延に寛容なアプリケーションまで、様々な要件に合わせて適切に設計すべきであることは気づかれる。
従って、制御チャネルの設計では、柔軟性及びそのリソース効率を考慮すべきである。そうしないと、例えば、遅延に寛容なサービスと遅延にセンシティブなサービスとが1つの制御チャネルで一緒に設定されている場合に、遅延にセンシティブなサービスからの遅延要件を満たすために、制御チャネルを頻繁にスケジュールする必要があるため、より多くのシグナリングオーバーヘッドが発生する可能性がある。
SA2 SIの目的Aは、5GSを介した一般的なMBSサービスを可能にすることに関するものであり、この機能の恩恵を受ける可能性のある特定されたユースケースには、公共安全、ミッションクリティカル、V2Xアプリケーション、透過的なIPv4/IPv6マルチキャスト配信、IPTV、無線を介したソフトウェア配信、グループ通信、及びIoTアプリケーションが含まれる(但し、これらに限定されない)。
所見2:NR MBS制御チャネルは、様々なタイプのユースケースに対して柔軟でリソース効率が必要とされる。
一つの可能性として、図18に示すように、異なるユースケースで設定チャネルを分離する必要があるかどうか検討することである。例えば、一つの制御チャネルは遅延にセンシティブなサービスを頻繁に提供し、別の制御チャネルは遅延に寛容なサービスをまばらに提供する。LTE SC-PTMでは、1つのセルは1つのSC-MCCHしか有せないという制限があった。しかしながら、LTEよりも多くのユースケースが想定されることを考慮すると、NR MBSはそのような制限を取り除くべきである。セル内で複数のSC-MCCHが許可されている場合、各SC-MCCHには、特定のサービス用に最適化可能な、繰り返し期間などの異なるスケジューリング設定がある。UEが興味のあるサービスを提供するSC-MCCHをどのように識別するかは更なる検討が必要である。
提案2:RAN2は、LTEになかった複数のSC-MCCHのように、NR MBSのセルで複数の制御チャネルがサポートされるかどうかを議論すべきである。
さらに、NRの新しいパラダイムは、オンデマンドSI送信のサポートである。この概念は、NR MBSのSC-MCCH、即ち、オンデマンドSC-MCCHに再利用され得る。例えば、遅延に寛容なサービス用のSC-MCCHはオンデマンドで提供されるため、シグナリングのリソース消費を最適化可能である。言うまでもなく、ネットワークには、SC-MCCHを定期的に、即ち、オンデマンドではなく、遅延にセンシティブなサービスなどに提供するための別のオプションがある。
提案3:RAN2は、LTEになかったオンデマンドSC-MCCHのように、制御チャネルがオンデマンドベースで提供される場合のオプションについて議論すべきである。
別の可能性として、図13に示すように、これらのメッセージをマージすること、即ち、1段階設定をさらに検討され得る。例えば、SIBは、SC-MTCHスケジューリング情報を直接、即ち、SC-MCCHなしで、提供する。これは、遅延に寛容なサービス及び/又は電力にセンシティブなUEのための最適化を提供するであろう。例えば、UEは、SIB(オンデマンド)を要求してもよく、gNBは、複数のUEからの要求の後に、SIB及び対応するサービスの提供を開始してもよい。これらのUEは、繰り返しブロードキャストされるSC-MCCHを監視する必要がない。
提案4:RAN2は、SC-MCCHを使用しないマルチキャスト受信(即ち、1段階設定)がサポートされている場合、SIBがトラフィックチャネル設定を直接提供するなどのオプションについて議論すべきである。
(専用シグナリングベースの設定)
一部の企業は、MBS設定が専用シグナリングによってのみ提供されることを提案した。グループ通信などのマルチキャストサービスでRRCコネクティッド状態のUEの場合、専用のシグナリングは簡単だが、アイドル/インアクティブ状態のUEは、これらのUEがブロードキャストサービスのみに興味を持つ場合でも、MBSサービスを受信する前に、常にRRCコネクティッド状態に遷移する必要があることを意味する。これにより、UEの不要な電力消費が発生する可能性があり、また、将来のリリースで無料放送サービスがサポートされるなど、将来の保証が少なくなる可能性がある。したがって、ブロードキャストシグナリングを介したMBS設定は、LTE SC-PTMと同様、提案1から提案4のようにベースラインになるはずであると考える。
ただし、図13に示すように、RRC再設定を介して制御チャネルを提供できる場合は、ネットワークの実装と展開ポリシーの柔軟性が得られると考えられる。たとえば、ネットワークはMBS制御チャネルをブロードキャストせず、ブロードキャストサービスを提供しない事業者などに必要な場合に、専用のシグナリングを介した設定を提供することのみを決定する場合がある。別の例として、ターゲットセルがハンドオーバーコマンドを介してMBS設定を提供する場合、ハンドオーバー中のサービス継続性にとって有益である。
したがって、RAN2は、RRC再設定がMBS制御チャネルを提供するかどうかについて検討する必要がある。
提案5:RAN2は、RRC再設定がLTEになかったSC-MCCHを提供する場合のオプションについて検討する必要ある。
(興味のインディケーション/カウンティング)
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エリアに関する情報とは必要ないことに注意する。
提案6:RAN2は、たとえば、MBMS興味インディケーション及び/又はMBMSカウンティングなど、NR MBSのUEアシスタンス情報を導入することに同意する必要がある。
提案6に同意できる場合は、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リソースパーティショニングがそのようなレポートに導入された場合に達成される可能性がある。
提案7:RAN2は、MBMSカウンティングなどのUEアシスタンス情報もアイドル/インアクティブ状態のUEから収集されるかどうかを検討する必要がある。