JP7290196B2 - Ｒａｎノード及びｒａｎノードにより行われる方法 - Google Patents

Description

本開示は、無線通信ネットワークに関し、特にRadio Resource Control (RRC)_INACTIVE状態である無線端末のデータ送信に関する。

3rd Generation Partnership Project（3GPP）は、２０２０年の第１四半期からRelease 17の検討を開始する。Release 17は、RRC_INACTIVEでのスモールデータ送信（small data transmission）のサポートを予定している（非特許文献１を参照）。これの目的（objectives）の１つは、アンカー・リロケーション（anchor relocation）を行わずに、つまりOld Radio Access Network (RAN) node（last serving RAN node）からNew RAN nodeへのUEコンテキストのリロケーションを行わずに、RRC_INACTIVEでのスモールデータ送信を可能にすることである。

なお、3GPP Release 15は、Long Term Evolution category M（LTE-M）devices及びNarrow Band Internet of Things (NB-IoT) devicesのためにearly data transmission（EDT）を既にサポートしている。EDT技術は、control-plane EDT (CP-EDT)及びuser-plane EDT (UP-EDT)を含む。EDTの主要なコンセプトの１つは、アップリンク（Uplink (UL)）データ及びダウンリンク（Downlink (DL)）データがコンテンション・ベースド・ランダムアクセス手順で早く送信される。具体的には、EDTは、ULデータ及びDLデータを、ランダムアクセス手順の第３メッセージ（Msg3）及び第４メッセージ（Msg4）でそれぞれ送信することを可能にする。

UP-EDTでは、RRC_INACTIVEである無線端末（User Equipment (UE)）は、ULデータを、RRC Connection Resume Requestメッセージと共に、コンテンション・ベースド・ランダムアクセス手順の第３ステップにおいて基地局（eNB）に送信する。RRC Connection Resume Requestメッセージを受信したnew eNBは、old eNB（つまり、last serving eNB）からUE contextを取得し、Mobility Management Entity (MME)にパススイッチを要求する。これにより、MMEは、UEのEvolved Packet System (EPS)ベアラの経路をold eNBを通る経路からnew eNBを通る経路に変更する。New eNBは、変更されたEPSベアラ（つまり、変更されたS1-Uベアラ）を介してULデータをServing Gateway (S-GW)に直接的に送信する。

ZTE Corporation, " Work Item on NR small data transmissions in INACTIVE state", RP-193252, 3GPP TSG RAN Meeting #86, Sitges, Spain, December 9-12, 2019

発明者等は、RRC_INACTIVEでのスモールデータ送信に関して検討を行い様々な課題を見出した。１つの課題は、上述のRelease 15で導入されたUP-EDTでは、old eNB（last serving eNB）からnew eNBへのUEコンテキストのリロケーションを行わずに、ULデータをコアネットワークに送信することができないことである。

ここに開示される実施形態が達成しようとする目的の１つは、古いRANノード（直近のサービングRANノード）から新たなRANノードへの無線端末コンテキストのリロケーションを行わずに、RRC_INACTIVEである無線端末のULデータをコアネットワークに送信することを可能にすることに寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、ここに開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

第１の態様では、第１のRadio Access Network（RAN）ノードは、少なくとも１つのメモリ及び前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、Radio Resource Control (RRC)_INACTIVE状態の無線端末からアップリンクデータを伴わないRRC再開要求メッセージを受信し、且つ前記無線端末の無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求する第１タイプの制御メッセージを前記無線端末の直近のサービングRANノードである第２のRANノードに送るよう構成される。さらに、前記少なくとも１つのプロセッサは、前記RRC_INACTIVE状態の前記無線端末から前記アップリンクデータを前記RRC再開要求メッセージと共に受信し、且つ前記無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求し且つ前記第１タイプの制御メッセージと区別された第２タイプの制御メッセージを前記第２のRANノードに送るよう構成される。

第２の態様では、第２のRadio Access Network（RAN）ノードは、少なくとも１つのメモリ及び前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、Radio Resource Control (RRC)_INACTIVE状態の無線端末の無線端末コンテキストを保持するよう構成される。加えて、前記少なくとも１つのプロセッサは、前記無線端末コンテキストを要求する制御メッセージを第１のRANノードから受信するよう構成される。さらに、前記少なくとも１つのプロセッサは、前記制御メッセージが、前記第１のRANノードが前記RRC_INACTIVE状態の前記無線端末からアップリンクデータをRRC再開要求メッセージと共に受信した場合に使用される特定のタイプであるか否かを判定するよう構成される。

第３の態様では、無線端末は、少なくとも１つのメモリ及び前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、前記無線端末がRadio Resource Control (RRC)_INACTIVE状態であるときに、アップリンクデータとデータ活動のタイプを示すタイプ情報を、RRC再開要求メッセージと共にRadio Access Network（RAN）ノードに送信するよう構成される。

第４の態様では、第１のRadio Access Network（RAN）ノードにより行われる方法は以下のステップを含む：
（ａ）Radio Resource Control (RRC)_INACTIVE状態の無線端末からアップリンクデータを伴わないRRC再開要求メッセージを受信し、且つ前記無線端末の無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求する第１タイプの制御メッセージを前記無線端末の直近のサービングRANノードである第２のRANノードに送ること、及び
（ｂ）前記RRC_INACTIVE状態の前記無線端末から前記アップリンクデータを前記RRC再開要求メッセージと共に受信し、且つ前記無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求し且つ前記第１タイプの制御メッセージと区別された第２タイプの制御メッセージを前記第２のRANノードに送ること。

第５の態様では、第２のRadio Access Network（RAN）ノードにより行われる方法は以下のステップを含む：
（ａ）Radio Resource Control (RRC)_INACTIVE状態の無線端末の無線端末コンテキストを保持すること、
（ｂ）前記無線端末コンテキストを要求する制御メッセージを第１のRANノードから受信すること、及び
（ｃ）前記制御メッセージが、前記第１のRANノードが前記RRC_INACTIVE状態の前記無線端末からアップリンクデータをRRC再開要求メッセージと共に受信した場合に使用される特定のタイプであるか否かを判定すること。

第６の態様では、無線端末により行われる方法は、前記無線端末がRadio Resource Control (RRC)_INACTIVE状態であるときに、アップリンクデータとデータ活動のタイプを示すタイプ情報を、RRC再開要求メッセージと共にRadio Access Network（RAN）ノードに送信すること、を含む。

第７の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第４、第５、又は第６の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

上述の態様によれば、古いRANノード（直近のサービングRANノード）から新たなRANノードへの無線端末コンテキストのリロケーションを行わずに、RRC_INACTIVEである無線端末のULデータをコアネットワークに送信することを可能にすることに寄与する装置、方法、及びプログラムを提供できる。

実施形態に係る無線通信ネットワークの構成例を示す図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るnew gNB、Old gNB、及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係る無線通信ネットワークの構成例を示す図である。 実施形態に係るnew gNB及びUEによって行われる動作の一例を示すシーケンス図である。 実施形態に係るgNBの構成例を示すブロック図である。 実施形態に係るUEの構成例を示すブロック図である。

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。

以下に示される複数の実施形態は、3rd Generation Partnership Project（3GPP）第5世代移動通信システム（5G system（5GS））を主な対象として説明される。しかしながら、これらの実施形態は、RRC_INACTIVEでのスモールデータ送信をサポートする他のセルラー通信システムに適用されてもよい。

＜第１の実施形態＞
図１は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワーク（i.e., 5GS）の構成例を示している。図１の例は、無線通信ネットワークは、２つの無線アクセスネットワーク（Radio Access Network（RAN））ノード（i.e., gNBs）１及び２並びに無線端末（i.e., UE）３を含む。以下で詳細に説明するように、UE３はRRC_INACTIVEでのスモールデータ送信を行うためにエアインタフェース１０１を介してgNB１にアクセスすることができ、gNB１はノード間インタフェース１０２を介してRRC_INACTIVEであるUE３のUEコンテキストを持つgNB２と通信する。したがって、以下では、gNB１はnew gNBと呼ばれ、gNB２はold gNB又は（last serving gNBと呼ばれる。old gNBは、UE３に対する直近のサービングRANノードと表現することもできる。

New gNB１とold gNB２の間のノード間インタフェース１０２は、Xnインタフェースである。Xnインタフェースは、コントロールプレーン・インタフェース（i.e., Xn-Cインタフェース）及びユーザプレーン・インタフェース（i.e., Xn-Uインタフェース）を含む。Xn-Cインタフェースは、シグナリング手順（procedures）のためのXn Application Protocol (XnAP)をサポートする。一方、Xn-Uインタフェースは、General Packet Radio Service (GPRS) Tunnelling Protocol for User Plane（GTP-U）プロトコルを使用する。具体的には、Xn-Uインタフェースのtransport network layer (TNL)は、User Datagram Protocol (UDP)/Internet Protocol (IP)ネットワークの上に作られ、UDP/IPプロトコルの上で（on top of UDP/IP）GTP-Uプロトコルを使用する。

UE３は、RRC_INACTIVE状態から再びRRC_CONNECTED状態に遷移するために、及びRAN通知エリア（RAN Notification Area (RNA)）更新をNG-RANに知らせるために、RRCコネクション再開手順（RRC Resume手順）を開始することができる。よく知られているように、RRC_INACTIVE状態は、RRC_CONNETED状態とRRC_IDLE状態の間の中間的な状態であると言うことができる。RRC_INACTIVE状態の幾つかの特徴はRRC_CONNETED状態のそれらと類似するが、RRC_INACTIVE状態の他の幾つかの特徴はRRC_IDLE状態のそれらと類似する。

より具体的には、UE３がRRC_INACTIVE状態であるとき、UE３及びNext Generation(NG)-RAN（gNBs１及び２を含む）がUE (Access Stratum (AS))コンテキストを維持する。RRC_INACTIVE状態であるUE3のために維持されるUE (AS)コンテキストは、例えば、無線ベアラ設定、及びASセキュリティ・コンテキストを含む。さらに、NG-RANは、RRC_INACTIVE状態のUE３のためのコアネットワーク（i.e., 5G Core Network（5GC））とのコントロールプレーン及びユーザプレーン・コネクションを確立したまま維持する。RRC_INACTIVE状態であるUE３についてのUE３及び5GC（i.e., Access and Mobility Management Function（AMF））における5GS Connection Management（CM）状態は、CM-CONNECTED状態である。すなわち、5GCは、UE３がRRC_CONNECTED状態であるか又はRRC_INACTIVE状態であるかを区別しない。RRC_INACTIVE状態のこれらの特徴は、RRC_CONNETED状態の特徴と類似する。

しかしながら、RRC_INACTIVE状態であるUE３のモビリティは、RRC_IDLE状態であるUE３のそれと類似する。すなわち、RRC_INACTIVE状態であるUE３のモビリティは、UE３によって制御されるセル再選択により取り扱われる。RRC_INACTIVE状態であるUE３の位置は、RAN通知エリア（RAN Notification Area（RNA））のレベルでNG-RANによって知られている。RAN通知エリア（RNA）は、１又はそれ以上のセルを含み、NG-RANにより決定され、NG-RANによりUE３に設定される。RRC_INACTIVE状態であるUE３は、RAN通知エリア内でセル再選択によりセル間を移動してもNG-RANにセル再選択を通知（報告）する必要がない。RRC_INACTIVE状態であるUE３は、設定されたRNA外のセルを再選択した場合、又は周期的（periodic）RAN更新を行う場合に、RRC Resume手順を開始し、NG-RANにRAN通知エリア更新を要求する。

続いて以下では、本実施形態に係るRRC_INACTIVEでのスモールデータ送信について説明する。本実施形態のnew gNB１は、RRC_INACTIVEであるUE３からULデータをRRC（コネクション）再開要求メッセージ（e.g., RRC Resume Requestメッセージ）と共に受信したか否かに依存して、異なるタイプの制御メッセージをold gNB（last serving gNB）２に送る。

より具体的には、図２Ａに示されるように、new gNB１は、RRC_INACTIVEであるUE３からULデータを伴わないRRC Resume Requestメッセージを受信し（ステップ２０１）、且つUE３のUEコンテキストがnew gNB１において利用可能でない場合に、第１タイプの制御メッセージをold gNB２に送る（ステップ２０２）。第１タイプの制御メッセージは、UE３のUEコンテキストを提供するようにold gNB２に要求する。

これに対して、図２Ｂに示されるように、new gNB１は、RRC_INACTIVEであるUE３からULデータをRRC Resume Requestメッセージと共に受信し（ステップ２２１）、且つUE３のUEコンテキストがnew gNB１において利用可能でない場合に、第２タイプの制御メッセージをold gNB２に送る（ステップ２２２）。第２タイプの制御メッセージは、第１タイプの制御メッセージと同様に、UE３のUEコンテキストを提供するようにold gNB２に要求する。しかしながら、第２タイプの制御メッセージは、new gNB１及びold gNB２によって、第１タイプの制御メッセージと区別される。

幾つかの実装では、第２タイプの制御メッセージは、第２タイプの制御メッセージがULデータの存在を直接的に又は間接的に表す表示（indication）を含むことによって、第１タイプの制御メッセージと区別されてもよい。より具体的には、第１タイプの制御メッセージは、既存のXnAP: RETRIEVE UE CONTEXT REQUESTメッセージと同様であってもよい。一方、第２タイプの制御メッセージは、ULデータの存在を直接的に又は間接的に表す新たな情報要素（Information Element (IE)）又は新たなcause値を含む改良されたRETRIEVE UE CONTEXT REQUESTメッセージであってもよい。ULデータの存在を直接的に又は間接的に表す表示は、例えば、（スモール）データが利用可能であることを示す新たなIE（e.g., (small) data available）であってもよいし、フォワードされるべき（スモール）データを示す新たなcause値（e.g., (small) data to be forwarded）であってもよい。これに代えて、第２タイプの制御メッセージは、RETRIEVE UE CONTEXT REQUESTメッセージの情報を包含しつつ、それとは異なる新たに定義されるXnAPメッセージであってもよい。New gNB１は、RRC_INACTIVEのUE３からULデータを受信した場合に、ULデータの存在をold gNB２に知らせるために当該新たなXnAPメッセージを使用してもよい。新たなXnAPメッセージは、例えば、RETRIEVE UE CONTEXT REQUEST FOR DATA TRANSFERメッセージ、又はDATA TRANSFER REQUESTメッセージと呼ばれてもよい。

さらに又はこれに代えて、幾つかの実装では、第２タイプの制御メッセージは、第２タイプの制御メッセージがold gNB２のトランスポート・ネットワーク・レイヤ（TNL）情報の要求を表す表示を含むことによって、第１タイプの制御メッセージと区別されてもよい。TNL情報は、トランスポートレイヤ情報と呼ばれてもよい。より具体的には、第１タイプの制御メッセージは、既存のXnAP: RETRIEVE UE CONTEXT REQUESTメッセージと同様であってもよい。一方、第２タイプの制御メッセージは、old gNB２のTNL情報の要求を表す新たな情報要素（Information Element (IE)）又は新たなcause値を含む改良されたRETRIEVE UE CONTEXT REQUESTメッセージであってもよい。これに代えて、第２タイプの制御メッセージは、RETRIEVE UE CONTEXT REQUESTメッセージの情報を包含しつつ、それとは異なる新たに定義されるXnAPメッセージであってもよい。New gNB１は、RRC_INACTIVEのUE３からULデータを受信した場合に、old gNB２のTNL情報を要求するために当該新たなXnAPメッセージを使用してもよい。新たなXnAPメッセージは、例えば、RETRIEVE UE CONTEXT REQUEST FOR DATA TRANSFERメッセージ、又はDATA TRANSFER REQUESTメッセージと呼ばれてもよい。

Old gNB２のTNL情報（又はトランスポートレイヤ情報）は、old gNB２のTNLアドレス（又はトランスポートレイヤ・アドレス）と言うこともできる。Old gNB２のTNL情報又はTNLアドレスは、ULデータをnew gNB１からold gNB２にユーザプレーン・インタフェース（i.e., Xn-Uインタフェース）を介して送信するためにnew gNB１によって使用される。したがって、old gNB２のTNL情報又はTNLアドレスは、old gNB２側のGTP-Uトンネルのエンドポイントを示すTunnel Endpoint Identifier（TEID）とold gNB２のIPアドレスとの組み合わせであってもよい。Xn-Uインタフェース（GTP-Uトンネル）に関するGTP-U/UDP/IP packetsを転送するために使用されるold gNB２のIPアドレスは、Xn-Cインタフェース（XnAPプロトコル）に関するXnAP/Stream Control Transmission Protocol （SCTP）/IP packetsを転送するために使用されるold gNB２のIPアドレスと同じであってもよいし異なってもよい。

さらに又はこれに代えて、幾つかの実装では、第２タイプの制御メッセージは、第２タイプの制御メッセージがULデータ（i.e., Dedicated Traffic Channel (DTCH)データ）それ自体を含むことによって、第１タイプの制御メッセージと区別されてもよい。より具体的には、第１タイプの制御メッセージは、既存のXnAP: RETRIEVE UE CONTEXT REQUESTメッセージと同様であってもよい。一方、第２タイプの制御メッセージは、ULデータ（i.e., DTCHデータ）を乗せて運ぶ（piggyback）するように改良されたRETRIEVE UE CONTEXT REQUESTメッセージであってもよい。これに代えて、第２タイプの制御メッセージは、RETRIEVE UE CONTEXT REQUESTメッセージの情報を包含しつつ、それとは異なる新たに定義されるXnAPメッセージであってもよい。New gNB１は、RRC_INACTIVEのUE３からULデータを受信した場合に、ULデータをold gNB２にフォワードするために当該新たなXnAPメッセージを使用してもよい。新たなXnAPメッセージは、例えば、RETRIEVE UE CONTEXT REQUEST FOR DATA TRANSFERメッセージ、又はDATA TRANSFER REQUESTメッセージと呼ばれてもよい。New gNB１は、UE３のULデータを特定するため又は復号化（deciphering）するために必要な追加情報を第２タイプの制御メッセージに含めてもよい。当該追加情報は、データ無線ベアラ識別子（Data Radio Bearer (DRB) ID）及び論理チャネル識別子（Logical Chanel ID (LCID)）のうち一方又は両方を含んでもよい。

Old gNB２は、RRC_INACTIVEであるUE３のUEコンテキストを要求する制御メッセージ（ステップ２０２又は２２２）をnew gNB１から受信する。そして、old gNB２は、受信した制御メッセージが第１タイプであるか第２タイプであるかを判定する。言い換えると、old gNB２は、受信した制御メッセージのタイプを特定する。Old gNB２は、受信した制御メッセージのタイプに依存して異なる動作を行ってもよい。

幾つかの実装では、old gNB２は、new gNB１から受信した制御メッセージが第２タイプであるなら、UE３のUEコンテキストをnew gNB1に提供せずに、UE３のULデータをold gNB２を介してコアネットワーク（5GC）に送信することを可能にするよう動作してもよい。より具体的には、old gNB２は、UE３のUEコンテキストがリロケーションされないことを示すXnAPメッセージ（e.g., RETRIEVE UE CONTEXT FAILUREメッセージ）をnew gNB１に送る。当該XnAPメッセージは、old gNB２のTNL情報を含んでもよい。すなわち、当該XnAPメッセージは、old gNB２を介するULデータ転送の許可を示してもよい。あるいは、old gNB２は、UE３のUEコンテキストがリロケーションされないことを示すXnAPメッセージ（e.g., RETRIEVE UE CONTEXT FAILUREメッセージ）とは別に、old gNB２のTNL情報を示すメッセージ（e.g., XN-U ADDRESS INDICATIONメッセージ）をnew gNB１に送ってもよい。当該XnAPメッセージの受信に応答して、New gNB１は、UE３のULデータをXn-Uインタフェース（i.e., GTP-Uトンネル）を介してold gNB２に送信する。そして、old gNB２は、new gNB１から受信したULデータ（i.e., DTCHデータ）に対する復号化（ciphering）を行うことでIPデータ（i.e., １又はそれ以上のIP packets）を取り出す。さらに、old gNB２は、当該IPデータを、RRC_INACTIVEであるUE３のために維持されているコアネットワークとのユーザプレーン・コネクション（i.e., N3 GTP-Uトンネル）を介して、コアネットワーク・ノード（i.e., 5GC内のUser Plane Function (UPF)）に送信する。

さらに又はこれに代えて、old gNB２は、new gNB１から受信した制御メッセージが第２タイプである場合、RRC_INACTIVEであるUE３のULデータをold gNB２を介してコアネットワーク（5GC）に送信するか否かを決定してもよい。Old gNB２を介してULデータを送信することを決定したことに応じて、old gNB２は、上述のように動作してもよい。一方、old gNB２を介してULデータを送信しないと決定したことに応じて、old gNB２は、UE３のUEコンテキストをnew gNB１に提供してもよい。この場合、new gNB１は、UE３のUEコンテキストをold gNB２から受信し、当該UEコンテキストを用いてUE３のULデータを復号化してIPデータを取り出し、当該データをコアネットワーク・ノード（i.e., 5GC内のUser Plane Function (UPF)）に直接的に（つまり、old gNB２を介さずに）送信してもよい。

以上の説明から理解されるように、本実施形態では、new gNB１は、RRC_INACTIVEであるUE３からULデータをRRC（コネクション）再開要求メッセージ（e.g., RRC Resume Requestメッセージ）と共に受信したか否かに依存して、異なるタイプのメッセージをold gNB（last serving gNB）２に送る。new gNB１は、RRC_INACTIVEであるUE３からULデータを伴わないRRC Resume Requestメッセージを受信し（ステップ２０１）、且つUE３のUEコンテキストがnew gNB１において利用可能でない場合に、第１タイプの制御メッセージをold gNB２に送る（ステップ２０２）。第１タイプの制御メッセージは、UE３のUEコンテキストを提供するようにold gNB２に要求する。これに対して、new gNB１は、RRC_INACTIVEであるUE３からULデータをRRC Resume Requestメッセージと共に受信し（ステップ２２１）、且つUE３のUEコンテキストがnew gNB１において利用可能でない場合に、第２タイプの制御メッセージをold gNB２に送る（ステップ２２２）。第２タイプの制御メッセージは、第１タイプの制御メッセージと同様に、UE３のUEコンテキストを提供するようにold gNB２に要求する。しかしながら、第２タイプの制御メッセージは、new gNB１及びold gNB２によって、第１タイプの制御メッセージと区別される。そして、old gNB２は、受信した制御メッセージが第１タイプであるか第２タイプであるかを判定する。これにより、new gNB１は、RRC_INACTIVEであるUE３からのULデータが存在することをold gNB２に知らせることができ、old gNB２はold gNB２を介してULデータをコアネットワークに送信することを可能にするよう動作できる。したがって、本実施形態は、old gNB２からnew gNB１へのUEコンテキストのリロケーションを行わずに、RRC_INACTIVEであるUE３のULデータをコアネットワークに送信することを可能にすることに寄与する。

＜第２の実施形態＞
本実施形態は、第１の実施形態で説明されたRRC_INACTIVEでのデータ送信の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。

図３は、本実施形態に係るRRC_INACTIVEでのデータ送信の第１の例を示している。ステップ３０１では、RRC_INACTIVEであるUE３は、ULデータ（i.e., DTCHデータ）を、RRC Resume Requestメッセージ（i.e., Common Control Channel (CCCH)データ）と共にnew gNB１に送信する。より具体的には、UE３はRRC_CONNECTEDからRRC_INACTIVEに移る指示を示す情報（SuspendConfig IE）を含むRRC Releaseメッセージをold gNB２（old gNBだが、RRC Releaseメッセージを受信した時点ではサービングgNBである）から受信した場合、当該ULデータをRRC Resume Requestメッセージで送信するために必要な設定情報（e.g., UE context）を保持しておき、ステップ３０１でそれを使用する。RRC Resume Requestメッセージ及びULデータは、４ステップ・コンテンション・ベースド・ランダムアクセス（4-Step Contention Based Random Access（CBRA））手順の第３メッセージで送信されてもよい。これに代えて、RRC Resume Requestメッセージ及びULデータは、２ステップ・コンテンション・ベースド・ランダムアクセス（2-Step CBRA）手順の第１メッセージ（メッセージA（MsgA））で送信されてもよい。

より具体的には、幾つかの実装では、new gNB１は、RRC Resume Requestメッセージ（CCCHデータ）及びULデータ（DTCHデータ）を送信するために必要なトランスポートブロック・サイズ（transport block size (TBS)）を持つ第３メッセージの送信のためのULリソース許可（UL grant）を４ステップ・ランダムアクセス手順の第２メッセージ（Random Access Response）を介してUE３に送る。そして、UE３のRRCレイヤは、全てのsignaling radio bearers (SRBs)及びdata radio bearers (DRBs)を再開（resume）し、新たなセキュリティキー（keys）を導出し、Access Stratum（AS）セキュリティを再確立する。一方、UE３のUser Plane（UP）プロトコルでは、UE３のService Data Adaptation Protocol (SDAP)レイヤは、IPデータ（QoSフロー）からSDAPデータを生成し、Packet Data Convergence Protocol（PDCP）レイヤへ渡す。続いて、UE３のPDCPレイヤは、SDAPデータを暗号化（cipher）し、PDCPデータを生成し、これをUE３のRadio Link Control (RLC)レイヤへ渡す。UE３のRLCレイヤは、PDCPデータからRLCデータ（DTCHデータとも呼ばれる）を生成し、UE３のMedium Access Control (MAC)レイヤへ渡す。そして、UE３のMACレイヤは、RRC Resume Requestメッセージ（CCCHデータ）を含むMAC sub-Protocol Data Unit（PDU）とULデータ（DTCHデータ）を含むMAC sub-PDUとを、１つのアップリンクMAC PDUに多重化する。UE３のMedium Access Control (MAC)レイヤは、第２メッセージで割り当てられたUplink Shared Channel（UL-SCH）リソースにおいて、アップリンクMAC PDU（トランスポートブロック）を送信する。New gNB１は、受信したアップリンクMAC PDUからRRC Resume Requestメッセージ（CCCHデータ）及びULデータ（DTCHデータ）を取り出す。

なお、UE３が再開するDRBは、old gNB２がRRC Releaseメッセージにおいて、UE３のRRC Resumeにおけるデータ送信を許可したDRB(s)のみでもよい。また、UE３のSDAPレイヤは、RRC_INACTIVE状態になった時点で使用していたIPデータ（QoSフロー）とDRBとの対応関係（QoS flow to DRB mapping rule）を基にPDCPレイヤへSDAPデータを渡してもよい。さらに又はこれに代えて、UE３のPDCPレイヤは、SDAPデータの暗号化（ciphering）をせずにPDCPデータをRLCレイヤへ渡してもよい。さらに、UE３のRLCレイヤは、Transparent Mode（TM）でPDCPデータをそのままRLCデータ（DTCHデータ）としてMACレイヤへ渡してもよい。

これに代えて、UE３のMACレイヤは、RRC Resume Requestメッセージ（CCCHデータ）を含む第１のアップリンクMAC PDUと、ULデータ（DTCHデータ）を含む第２のアップリンクMAC PDUとを生成し、これら２つのMAC PDUsを時間上で連続するUL-SCHリソースで順に送信してもよい。RRC Resume Requestメッセージは、ULデータが続けて送信されることを示す情報を包含してもよい。また、これらのリソースは、４ステップ・ランダムアクセス（4-Step RA）手順の第２メッセージを介してnew gNB１により指定されてもよい。２ステップ・ランダムアクセス（2-Step RA）手順が使用される場合、UE３は、予め定められた第１メッセージ（MsgA）のリソースで、これら２つのMAC PDUsを送信してもよい。New gNB１は、先ず第１のアップリンクMAC PDUを受信し、第１のアップリンクMAC PDUから第２のアップリンクMAC PDUを続けて受信するべきであることを認識し、第２のアップリンクMAC PDUを更に受信してもよい。New gNB１は、受信した第１のアップリンクMAC PDUからRRC Resume Requestメッセージ（CCCHデータ）を取り出し、受信した第２のアップリンクMAC PDUからULデータ（DTCHデータ）を取り出す。この場合、new gNB１は、RRC_INACTIVEであるUE３からULデータをRRC Resume Requestメッセージに続けて受信し、且つUE３のUEコンテキストがnew gNB１において利用可能でない場合に、第２タイプの制御メッセージをold gNB２に送ってもよい。

ステップ３０２では、ULデータをRRC Resume Requestメッセージと共に受信したことに応答して、new gNB１は、第２タイプの制御メッセージをold gNB２に送る。より具体的には、図３の例では、new gNB１は、old gNB２のTNL情報の要求を表す新たなIE又は新たなcause値（e.g., TNL INFORMATION REQUEST）を含む改良されたRETRIEVE UE CONTEXT REQUESTメッセージを送信する。

Old gNB２は、受信したRETRIEVE UE CONTEXT REQUESTメッセージがold gNB２のTNL情報の要求を表すIE又はcause値を含むことを検出する。そして、old gNB２は、UE３のUEコンテキストをnew gNB１にリロケーションしないことを決定する。ステップ３０３では、old gNB２は、RETRIEVE UE CONTEXT FAILUREメッセージを送信する。当該RETRIEVE UE CONTEXT FAILUREメッセージは、old gNB２のTNL情報（e.g., TEID及びIPアドレス）を示すIEを含む。さらに、当該RETRIEVE UE CONTEXT FAILUREメッセージは、UE３に送信されるためのRRC Releaseメッセージを含む。RRC Releaseメッセージは、RETRIEVE UE CONTEXT FAILUREメッセージ内のOld NG-RAN node To New NG-RAN node Resume Container IEに包含まれる。さらに、当該RETRIEVE UE CONTEXT FAILUREメッセージは、UEコンテキストがリロケーションされないことを示すcause値（e.g., Non-relocation of context）を含んでもよい。これに代えて、当該RETRIEVE UE CONTEXT FAILUREメッセージは、UEコンテキスト・リロケーション無しのデータ転送を示すcause値（e.g., Data transfer without context relocation）を含んでもよい。

ステップ３０４では、new gNB１は、ステップ３０３で受信したTNLアドレス宛てに、UE３のULデータ（DTCHデータ）を送信する。old gNB２は、new gNB１から受信したULデータ（i.e., DTCHデータ）に対する復号化（ciphering）を行うことでIPデータ（i.e., １又はそれ以上のIP packets）を取り出す。より具体的には、old gNB２は、復号化後のPDCP Service Data Unit (SDU)からSDAP PDUを取り出す。そして、保存していたUE３に割り当てていたQoSフローとDRBの対応付け（QoS flow to DRB mapping rule）を基にQoSフローに対応するSDAP SDUを取り出し、これをIPデータへと置換する。さらに、old gNB２は、当該IPデータを、RRC_INACTIVEであるUE３のために維持されているコアネットワークとのユーザプレーン・コネクション（i.e., N3 GTP-Uトンネル）を介して、コアネットワーク・ノード（i.e., 5GC内のUser Plane Function (UPF)）に送信する。

ステップ３０５では、new gNB１は、ステップ３０３で受信したRRC ReleaseメッセージをUE３にフォワードする。New gNB１は、４ステップ・ランダムアクセス手順の第４メッセージ（Msg４）でRRC Releaseメッセージを送信してもよい。これに代えて、new gNB１は、２ステップ・ランダムアクセス手順の第２メッセージ（メッセージB（MsgB））でRRC Releaseメッセージを送信してもよい。この場合、第２メッセージ（MsgB）は、コンテンション解決のための情報（Contention Resolution MAC Control Element (CE)）とRRC Releaseメッセージを包含してもよい。RRC Releaseメッセージの受信に応じて、UE３は、RRC_INACTIVE状態に留まる。これにより、UE３は、RRC_INACTIVE状態からRRC_CONNECTED状態に移ることなく、ULデータを送信できる。

図３の手順は適宜変形されてもよい。例えば、new gNB１がold gNB２のTNLアドレスを既に知っているなら、new gNB１は、ステップ３０３でのRETRIEVE UE CONTEXT FAILUREメッセージ受信よりも前に、UE３のULデータをXn-Uインタフェース上でold gNB２に送信してもよい。例えば、new gNB１は、ステップ３０３でのRETRIEVE UE CONTEXT REQUESTメッセージのXn-Cインタフェース上での送信の直後にUE３のULデータをXn-Uインタフェース上で送信してもよい。あるいは、new gNB１は、ステップ３０３でのRETRIEVE UE CONTEXT REQUESTメッセージのXn-Cインタフェース上での送信と実質的に同時に、UE３のULデータをXn-Uインタフェース上で送信してもよい。これにより、ULデータを早く送信できる。

Old gNB２のTNLアドレスの通知は、ステップ３０３のRETRIEVE UE CONTEXT FAILUREメッセージとは独立した別のXnAPメッセージを介して、old gNB２からnew gNB１に送られてもよい。当該XnAPメッセージは、XN-U ADDRESS INDICATIONメッセージであってもよい。当該XnAPメッセージ（e.g., XN-U ADDRESS INDICATIONメッセージ）は、ステップ３０３のRETRIEVE UE CONTEXT FAILUREメッセージよりも前に送信されてもよい。

図４は、本実施形態に係るRRC_INACTIVEでのデータ送信の第２の例を示している。図４のステップ４０１～４０５は、基本的に、図３のステップ３０１～３０５と同一である。ただし、ステップ４０２のRETRIEVE UE CONTEXT REQUESTメッセージは、ULデータの存在を表す新たなIE（e.g., UL DATA INDICATION）又は新たなcause値（e.g., Data available for transfer）を含む。ステップ４０３のRETRIEVE UE CONTEXT FAILUREメッセージは、UEコンテキスト・リロケーション無しのデータ転送を示すcause値（e.g., Data transfer without context relocation）を含む。当該RETRIEVE UE CONTEXT FAILUREメッセージは、old gNB２のTNL情報を示すIEを含んでもよい。

図５は、本実施形態に係るRRC_INACTIVEでのデータ送信の第３の例を示している。図３を参照して既に説明したように、new gNB１がold gNB２のTNLアドレスを既に知っているなら、new gNB１は、RETRIEVE UE CONTEXT FAILUREメッセージの受信（ステップ３０３）よりも前に、UE３のULデータを早めに送信してもよい。図５の例では、new gNB１は、RETRIEVE UE CONTEXT REQUESTメッセージの送信（ステップ５０２）後にULデータをold gNB２に送信する（ステップ５０３）。ステップ５０１、５０２、５０４、及び５０５は、図３又は図４の対応するステップと同様である。

図６は、本実施形態に係るRRC_INACTIVEでのデータ送信の第４の例を示している。ステップ６０１は、図３のステップ３０１、図４のステップ４０１、及び図５のステップ５０１と同様である。ステップ６０２では、new gNB１は、既存のRETRIEVE UE CONTEXT REQUESTメッセージの情報を包含しつつ、それとは異なる新たに定義されるXnAPメッセージをold gNB２に送る。当該新たなXnAPメッセージは、図６に示されるように、RETRIEVE UE CONTEXT REQUEST FOR DATA TRANSFERメッセージであってもよい。

図３を参照して既に説明したように、old gNB２のTNLアドレスの通知は、RETRIEVE UE CONTEXT FAILUREメッセージ（ステップ３０３）とは独立した別のXnAPメッセージを介してold gNB２からnew gNB１に送られてもよい。図６の例では、old gNB２は、RETRIEVE UE CONTEXT REQUEST FOR DATA TRANSFERメッセージの受信（ステップ６０２）の後に、XN-U ADDRESS INDICATIONメッセージをnew gNB１に送る（ステップ６０３）。当該XN-U ADDRESS INDICATIONメッセージは、old gNB２のTNLアドレス（e.g., TEID及びIPアドレス）を示す。その後に、old gNB２は、RETRIEVE UE CONTEXT FAILURE FOR DATA TRANSFERメッセージを送信する（ステップ６０５）。Old gNB２は、UE３のULデータをnew gNB１から受信（ステップ６０４）した後に、RETRIEVE UE CONTEXT FAILURE FOR DATA TRANSFERメッセージを送信してもよい（ステップ６０５）。RETRIEVE UE CONTEXT FAILURE FOR DATA TRANSFERメッセージは、UE３に送信されるためのRRC Releaseメッセージを含む。図３のステップ３０５と同様に、ステップ６０６では、new gNB１は、ステップ６０５で受信したRRC ReleaseメッセージをUE３にフォワードする。RRC Releaseメッセージの受信に応じて、UE３は、RRC_INACTIVE状態に留まる。これにより、UE３は、RRC_INACTIVE状態からRRC_CONNECTED状態に移ることなく、ULデータを送信できる。

図７は、本実施形態に係るRRC_INACTIVEでのデータ送信の第５の例を示している。図７の例では、ULデータに加えて、DLデータが送信される。ステップ７０１～７０４は、例えば、図３のステップ３０１～３０４又は図４のステップ４０１～４０４と同様である。ステップ７０５では、old gNB２は、UE３のDLデータをXn-Uインタフェースを介してnew gNB１にフォワードする。これを可能とするために、ステップ７０２のRETRIEVE UE CONTEXT REQUESTメッセージは、new gNB１のTNL情報（e.g., TEID及びIPアドレス）を示すIEを含んでもよい。Xn-Uインタフェース（GTP-Uトンネル）に関するGTP-U/UDP/IP packetsを転送するために使用されるnew gNB１のIPアドレスは、Xn-Cインタフェース（XnAPプロトコル）に関するXnAP/SCTP/IP packetsを転送するために使用されるnew gNB１のIPアドレスと同じであってもよいし異なってもよい。ステップ７０５のDLデータ転送は、ステップ７０４のULデータ転送の前に行われてもよいし、ステップ７０４のULデータ転送と並行して行われてもよい。

ステップ７０６では、new gNB１は、ステップ７０５で受信したDLデータを、ステップ７０３で受信したRETRIEVE UE CONTEXT FAILUREメッセージに包含されているRRC Releaseメッセージと共に、UE３に送信する。RRC Releaseメッセージの受信に応じて、UE３は、RRC_INACTIVE状態に留まる。これにより、UE３は、RRC_INACTIVE状態からRRC_CONNECTED状態に移ることなく、ULデータを送信でき、DLデータを受信できる。

図７の手順は適宜変形されてもよい。例えば、new gNB１がold gNB２のTNL情報を既に知っているなら、new gNB１は、ステップ７０３でのRETRIEVE UE CONTEXT FAILUREメッセージ受信よりも前に、UE３のULデータをXn-Uインタフェース上でold gNB２に送信してもよい。さらに、old gNB２がnew gNB１のTNL情報を既に知っているなら、old gNB２は、ステップ７０３でのRETRIEVE UE CONTEXT FAILUREメッセージ送信よりも前に、UE３のDLデータをXn-Uインタフェース上でnew gNB１に送信してもよい。なお、ステップ７０４及びステップ７０５は、ステップ７０３より前に行われてもよい。

図８は、本実施形態に係るRRC_INACTIVEでのデータ送信の第６の例を示している。図８の例は、図６に示された例にDLデータ転送が追加されている。ステップ８０１は、図６のステップ６０１と同様である。ステップ８０２では、既存のRETRIEVE UE CONTEXT REQUESTメッセージの情報を包含しつつ、それとは異なる新たに定義されるXnAPメッセージをold gNB２に送る。当該新たなXnAPメッセージは、new gNB１のTNL情報を示すIEを含む。当該新たなXnAPメッセージは、図８に示されるように、RETRIEVE UE CONTEXT REQUEST FOR DATA TRANSFERメッセージであってもよい。

ステップ８０３は、図６のステップ６０３と同様である。ステップ８０４は、図６のステップ６０４と同様である。ステップ８０５では、old gNB２は、UE３のDLデータをXn-Uインタフェースを介してnew gNB１にフォワードする。ステップ８０５のDLデータ転送は、ステップ８０４のULデータ転送の前に行われてもよいし、ステップ８０４のULデータ転送と並行して行われてもよい。

ステップ８０６は、図６のステップ６０５と同様である。ステップ８０７では、new gNB１は、ステップ８０６でRETRIEVE UE CONTEXT FAILURE FOR DATA TRANSFERメッセージを介して受信したRRC Releaseメッセージを、UE３にフォワードする。さらにステップ８００７では、new gNB１は、ステップ８０５で受信したDLデータを、RRC Releaseメッセージと共にUE３に送信する。RRC Releaseメッセージの受信に応じて、UE３は、RRC_INACTIVE状態に留まる。これにより、UE３は、RRC_INACTIVE状態からRRC_CONNECTED状態に移ることなく、ULデータを送信でき、DLデータを受信できる。

＜第３の実施形態＞
本実施形態は、第１の実施形態で説明されたRRC_INACTIVEでのデータ送信の具体例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。

図９は、本実施形態に係るRRC_INACTIVEでのデータ送信の例を示している。ステップ９０１は、図３のステップ３０１と同様である。ステップ９０２では、ULデータをRRC Resume Requestメッセージと共に受信したことに応答して、new gNB１は、第２タイプの制御メッセージをold gNB２に送る。より具体的には、図９の例では、new gNB１は、ULデータ（i.e., DTCHデータ）それ自体を包含する新たなIEを含む改良されたRETRIEVE UE CONTEXT REQUESTメッセージを送信する。ステップ９０２のXnAPメッセージは、RETRIEVE UE CONTEXT REQUESTメッセージの情報を包含しつつ、それとは異なる新たなXnAPメッセージであってもよい。

幾つかの実装では、ULデータ（i.e., DTCHデータ）は、new gNB１からold gNB２への新たなtransparent container（e.g., New NG-RAN node To Old NG-RAN node Resume Container）のIEに含まれてもよい。当該新たなIEの名称は、例えば、Data Over CP IE又はData Container IEであってもよい。New gNB１は、UE３のULデータを特定するため又は復号化（deciphering）するために必要な追加情報をステップ９０２のXnAPメッセージに含めてもよい。当該追加情報は、DRB ID及びLCIDを含んでもよい。

Old gNB２は、受信したRETRIEVE UE CONTEXT REQUESTメッセージがULデータ（i.e., DTCHデータ）を包含するIEを含むことを検出する。そして、old gNB２は、UE３のUEコンテキストをnew gNB１にリロケーションしないことを決定する。ステップ９０３では、old gNB２は、RETRIEVE UE CONTEXT FAILUREメッセージを送信する。当該RETRIEVE UE CONTEXT FAILUREメッセージは、UE３に送信されるためのRRC Releaseメッセージを含む。RRC Releaseメッセージは、RETRIEVE UE CONTEXT FAILUREメッセージ内のOld NG-RAN node To New NG-RAN node Resume Container IEに包含まれる。当該RETRIEVE UE CONTEXT FAILUREメッセージは、UEコンテキストがリロケーションされないことを示すcause値（e.g., Non-relocation of context）を含んでもよい。これに代えて、当該RETRIEVE UE CONTEXT FAILUREメッセージは、UEコンテキスト・リロケーション無しのデータ転送を示すcause値（e.g., Data transfer without context relocation）を含んでもよい。ステップ９０３のXnAPメッセージは、RETRIEVE UE CONTEXT FAILUREメッセージの情報を包含しつつ、それとは異なる新たなXnAPメッセージであってもよい。

ステップ９０４では、new gNB１は、ステップ９０３で受信したRRC ReleaseメッセージをUE３にフォワードする。New gNB１は、４ステップ・ランダムアクセス手順の第４メッセージ（Msg４）でRRC Releaseメッセージを送信してもよい。これに代えて、new gNB１は、２ステップ・ランダムアクセス手順の第２メッセージ（メッセージB（MsgB））でRRC Releaseメッセージを送信してもよい。RRC Releaseメッセージの受信に応じて、UE３は、RRC_INACTIVE状態に留まる。これにより、UE３は、RRC_INACTIVE状態からRRC_CONNECTED状態に移ることなく、ULデータを送信できる。

本実施形態によれば、UE３のULデータは、new gNB１からold gNB２への最初のXnAPメッセージと同時に早く送信されることができる。

＜第４の実施形態＞
本実施形態は、第１～第３の実施形態で説明されたRRC_INACTIVEでのデータ送信の変形例を提供する。本実施形態に係る無線通信ネットワークの構成例は、図１に示された例と同様である。

本実施形態では、RRC_INACTIVEであるUE３は、データ活動（data activity）のタイプを示すタイプ情報を、ULデータ及びRRC（コネクション）再開要求メッセージと共に、new gNB１に送信する。当該タイプ情報は、RRC（コネクション）再開要求メッセージ（e.g., RRC Resume Requestメッセージ）に含まれる新たなIEであってもよい。当該新たなIEの名称は、例えば、data activity IEであってもよい。

本実施形態のnew gNB１は、UE３のデータ活動のタイプを示す当該タイプ情報をUE３からさらに受信する。そして、new gNB１は、UE３からULデータをRRC Resume Requestメッセージと共に受信し、且つUE３のUEコンテキストがnew gNB１において利用可能でない場合に、第２タイプの制御メッセージをold gNB２に送る。当該第２タイプの制御メッセージは、UE３のUEコンテキストを提供するようにold gNB２に要求するとともに、UE３のデータ活動のタイプを示す。当該第２タイプの制御メッセージは、改良されたRETRIEVE UE CONTEXT REQUESTメッセージであってもよいし、新たなXnAPメッセージであってもよい。

幾つかの実装では、UE３のデータ活動のタイプは、１回のULデータ送信のみである第１のタイプ（e.g., one-shot data）、最初のULデータ送信に引き続く追加のULデータ送信の発生が予定される（expected）第２のタイプ（e.g., more data）、及びULデータ送信の後にDLデータ送信の発生が予定される第３のタイプ（e.g., expect DL data）を含む複数のタイプから選択されてもよい。なお、データ活動（data activity）は、データ・パターン又はトラフィック・パターンと呼ばれてもよい。

幾つかの実装では、old gNB２は、UE３のデータ活動のタイプを考慮して、RRC_INACTIVEであるUE３の（最初の）ULデータをold gNB２を介してコアネットワーク（i.e., 5GC）に送信するか否かを決定してもよい。言い換えると、old gNB２は、UE３のデータ活動のタイプを考慮して、UE３のUEコンテキストをnew gNB１にリロケートするか（又は提供するか）否かを決定してもよい。

図１０は、本実施形態に係るnew gNB１、old gNB２、及びUE３の動作の例を示している。ステップ１００１では、RRC_INACTIVEであるUE３は、データ活動のタイプを示すIE（e.g., Data Activity IE）を包含するRRC Resume RequestメッセージとULデータとをnew gNB１に送信する。RRC Resume Requestメッセージ及びULデータは、４ステップ・コンテンション・ベースド・ランダムアクセス手順の第３メッセージで送信されてもよい。これに代えて、RRC Resume Requestメッセージ及びULデータは、２ステップ・コンテンション・ベースド・ランダムアクセス手順の第１メッセージ（メッセージA（MsgA））で送信されてもよい。

ステップ１００２では、ULデータをRRC Resume Requestメッセージと共に受信したことに応答して、new gNB１は、RETRIEVE UE CONTEXT REQUESTメッセージをold gNB２に送信する。old gNB２は、UE３のlast serving gNBである。当該RETRIEVE UE CONTEXT REQUESTメッセージは、UE３のUEコンテキストを提供するようにold gNB２に要求する。当該RETRIEVE UE CONTEXT REQUESTメッセージは、UE３のデータ活動のタイプを示す情報要素（IE）を含む。当該IEの名称は、Data Activity IE、Data Pattern IE、又はTraffic Pattern IEであってもよい。さらに、当該RETRIEVE UE CONTEXT REQUESTメッセージは、第１～第３の実施形態で説明されたような追加の情報要素を含んでもよい。具体的には、当該RETRIEVE UE CONTEXT REQUESTメッセージは、ULデータの存在を表す新たなIE又は新たなcause値を含んでもよい。さらに又はこれに代えて、当該RETRIEVE UE CONTEXT REQUESTメッセージは、old gNB２のTNL情報の要求を表す新たなIE又は新たなcause値を含んでもよい。さらに又はこれに代えて、当該RETRIEVE UE CONTEXT REQUESTメッセージは、ULデータ（i.e., DTCHデータ）それ自体を包含する新たなIEを含んでもよい。

ステップ１００３では、old gNB２は、UE３のデータ活動のタイプを考慮して、UE３のUEコンテキストをnew gNB１にリロケートするか（又は提供するか）否かを決定する。言い換えると、old gNB２は、UE３のデータ活動のタイプを考慮して、RRC_INACTIVEであるUE３の（最初の）ULデータをold gNB２を介してコアネットワーク（i.e., 5GC）に送信するか否かを決定する。

例えば、old gNB２は、UE３のデータ活動タイプが上述の第１のタイプ（e.g., one-shot data）であるなら、UE３のUEコンテキストをnew gNB１にリロケートせず、RRC_INACTIVEであるUE３のULデータをold gNB２を介してコアネットワーク（i.e., 5GC）に送信することを決定してもよい。これとは対照的に、old gNB２は、UE３のデータ活動タイプが上述の第２のタイプ（e.g., more data）又は第３のタイプ（e.g., expect DL data）であるなら、UE３のUEコンテキストをnew gNB１にリロケートすることを決定してもよい。

UE３のUEコンテキストをnew gNB１にリロケートしないと決定したことに応じて、old gNB２は、UE３のULデータ（及びDLデータ）をold gNB２を介して転送することを可能にする。この動作は、第１～第４の実施形態で説明された複数の例のいずれかと同様であってもよい。

一方、UE３のUEコンテキストをnew gNB１にリロケートすることを決定したことに応じて、old gNB２は、UE３のUEコンテキストをnew gNB１に提供する。この場合、new gNB１は、UE３のUEコンテキストをold gNB２から受信し、当該UEコンテキストを用いてUE３のULデータを復号化してIPデータを取り出し、当該データをコアネットワーク・ノード（i.e., 5GC内のUPF）に直接的に（つまり、old gNB２を介さずに）送信してもよい。さらに、new gNB１は、DLデータをコアネットワーク・ノードから受信し、これをUE３に送信してもよい。UE３のデータ活動タイプが、上述の第２のタイプ（e.g., more data）又は上述の第３のタイプ（e.g., expect DL data）であるなら、new gNB１は、RRC Releaseメッセージではなく、RRC Resumeメッセージを４ステップ・ランダムアクセス手順の第４メッセージ（又は２ステップ・ランダムアクセス手順の第２メッセージ）でUE３に送信してもよい。この場合、UE３は、RRC_CONNECTED状態に入り、さらなる（more）ULデータ若しくはDLデータ又は両方の転送をnew gNB１と行ってもよい。

本実施形態によれば、RRC_INACTIVEであるUE３は、そのデータ活動タイプをnew gNB１に提供でき、new gNB１を介してold gNB２にこれをさらに提供できる。これにより、UE３のUEコンテキストをリロケーションするか否かを決定するためにold gNB２を支援できる。

＜第５の実施形態＞
本実施形態は、第１～第４の実施形態で説明されたRRC_INACTIVEでのデータ送信の変形例を提供する。第１～第４の実施形態で説明されたRRC_INACTIVEでのデータ送信は、Inter-Radio Access Technology (RAT) INACTIVE mobilityのケースに適用されてもよい。より具体的には、5GSと協調動作する機能を持つLTE eNB（ng-eNBとも呼ばれる）が使用される場合、当該LTE eNBは、5G UEsのRRC_INACTIVE状態をサポートしてもよい。このとき、NR gNBのセルにおいてRRC_INACTIVE状態のUE３が、LTE ng-eNBのセルを選択（i.e., inter-RATセル再選択）する場合、UE３はRRC_INACTIVE状態のまま（つまり、RRC_CONNECTED状態またはRRC_IDLE状態に移ることなく）当該ng-eNBのセルに滞在してもよい。

図１１に示されるように、UE３は、NR（New Radio）エリア（例えば、old gNB２のセル）においてRRC_INACTIVEになり、その後にng-eNB４のセルをinter-RAT cell reselectionにより選択し、ng-eNB４の当該セルがold gNB２のRRC Releaseメッセージにより指定されたRNAに含まれるなら、RRC_INACTIVE状態に留まってもよい。UE３は、ULデータ送信のためにRRC Resume手順を開始するとき、RRC Resume Requestメッセージ及びULデータをng-eNB４の当該セルでng-eNB４に送信してもよい。このとき、図１２に示されるように、UE３は、Inter-RAT resumeであることを明示的または暗示的に示す情報（IE又はCause値）をRRC Resume Requestメッセージに含めてもよい。第１～第４の実施形態で説明された複数の例のいずれかに従って、ng-eNB４（i.e., new RAN node）は、old gNB２（i.e., old RAN node又はlast serving RAN node）に、第２タイプの制御メッセージ（e.g., 改良されたRETRIEVE UE CONTEXT REQUESTメッセージ又は新たなXnAPメッセージ）を送信してもよい。なお、図１１で示された例と反対に、UE３がng-eNB（i.e. old ng-eNB）のセルにおいてRRC_INACTIVEになり、gNB（i.e. new gNB）のセルを選択した後、gNBの当該セルでRRC Resume手順によりULデータを送信してもよい。

さらに、本実施形態では、UE３に対するRRC_CONNECTEDからRRC_INACTIVEに移る指示（e.g., RRC ReleaseメッセージのSuspendConfig IE）は、UE３がInter-RAT INACTIVE mobilityを実行することが可能か否か（つまり、UE３がそれを許可されているか否か）を明示的又は暗示的に示してもよい。これを暗示的に示すために、当該指示は、異なるRAT（e.g., LTE）のセル又はRANエリアコード（ranac）がRNAに含まれることを示してもよい。さらに又はこれに代えて、ターゲットRAT(e.g., LTE ng-eNB)のセルがInter-RAT INACTIVE mobilityが許可されていることを明示的又は暗示的に示している場合に、UE３はそれを実行してもよい。

続いて以下では、上述の複数の実施形態に係るgNB１、gNB２、UE３、及びng-eNB４の構成例について説明する。図１３は、上述の実施形態に係るgNB１の構成例を示すブロック図である。gNB２及びng-eNB４の構成例も図１３と同様である。図１３を参照すると、gNB１は、Radio Frequency（RF）トランシーバ１３０１、ネットワークインターフェース１３０３、プロセッサ１３０４、及びメモリ１３０５を含む。RFトランシーバ１３０１は、UE３を含むUEsと通信するためにアナログRF信号処理を行う。RFトランシーバ１３０１は、複数のトランシーバを含んでもよい。RFトランシーバ１３０１は、アンテナアレイ１３０２及びプロセッサ１３０４と結合される。RFトランシーバ１３０１は、変調シンボルデータをプロセッサ１３０４から受信し、送信RF信号を生成し、送信RF信号をアンテナアレイ１３０２に供給する。また、RFトランシーバ１３０１は、アンテナアレイ１３０２によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ１３０４に供給する。RFトランシーバ１３０１は、ビームフォーミングのためのアナログビームフォーマ回路を含んでもよい。アナログビームフォーマ回路は、例えば複数の移相器及び複数の電力増幅器を含む。

ネットワークインターフェース１３０３は、ネットワークノード（e.g., 他のgNBs、AMF、及びUser Plane Function（UPF））と通信するために使用される。ネットワークインターフェース１３０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

プロセッサ１３０４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。プロセッサ１３０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ１３０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）又はMicro Processing Unit（MPU））を含んでもよい。

例えば、プロセッサ１３０４によるデジタルベースバンド信号処理は、Service Data Adaptation Protocol（SDAP）レイヤ、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、Medium Access Control（MAC）レイヤ、およびPhysical（PHY）レイヤの信号処理を含んでもよい。また、プロセッサ１３０４によるコントロールプレーン処理は、Non-Access Stratum（NAS）messages、RRC messages、MAC CEs、及びDCIsの処理を含んでもよい。

プロセッサ１３０４は、ビームフォーミングのためのデジタルビームフォーマ・モジュールを含んでもよい。デジタルビームフォーマ・モジュールは、Multiple Input Multiple Output（MIMO）エンコーダ及びプリコーダを含んでもよい。

メモリ１３０５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ１３０５は、プロセッサ１３０４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１３０４は、ネットワークインターフェース１３０３又は図示されていないI/Oインタフェースを介してメモリ１３０５にアクセスしてもよい。

メモリ１３０５は、上述の複数の実施形態で説明されたgNB１による処理を行うための命令群およびデータを含む１つ又はそれ以上のソフトウェアモジュール（コンピュータプログラム）１３０６を格納してもよい。いくつかの実装において、プロセッサ１３０４は、当該ソフトウェアモジュール１３０６をメモリ１３０５から読み出して実行することで、上述の実施形態で説明されたgNB１の処理を行うよう構成されてもよい。

なお、gNB１がcloud RAN（C-RAN）配置（deployment）におけるgNB Central Unit（gNB-CU）である場合、gNB１は、RFトランシーバ１３０１（及びアンテナアレイ１３０２）を含まなくてもよい。

図１４は、UE３の構成例を示すブロック図である。Radio Frequency（RF）トランシーバ１４０１は、NG-RAN nodes（e.g., gNB１、gNB２、及びng-eNB４）と通信するためにアナログRF信号処理を行う。RFトランシーバ１４０１は、複数のトランシーバを含んでもよい。RFトランシーバ１４０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ１４０１は、アンテナアレイ１４０２及びベースバンドプロセッサ１４０３と結合される。RFトランシーバ１４０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ１４０３から受信し、送信RF信号を生成し、送信RF信号をアンテナアレイ１４０２に供給する。また、RFトランシーバ１４０１は、アンテナアレイ１４０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ１４０３に供給する。RFトランシーバ１４０１は、ビームフォーミングのためのアナログビームフォーマ回路を含んでもよい。アナログビームフォーマ回路は、例えば複数の移相器及び複数の電力増幅器を含む。

ベースバンドプロセッサ１４０３は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮／復元、(b) データのセグメンテーション／コンカテネーション、(c) 伝送フォーマット（伝送フレーム）の生成／分解、(d) 伝送路符号化／復号化、(e) 変調（シンボルマッピング）／復調、及び(f) Inverse Fast Fourier Transform（IFFT）によるOFDMシンボルデータ（ベースバンドOFDM信号）の生成などを含む。一方、コントロールプレーン処理は、レイヤ１（e.g., 送信電力制御）、レイヤ２（e.g., 無線リソース管理、及びhybrid automatic repeat request（HARQ）処理）、及びレイヤ３（e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含む。

例えば、ベースバンドプロセッサ１４０３によるデジタルベースバンド信号処理は、Service Data Adaptation Protocol（SDAP）レイヤ、Packet Data Convergence Protocol（PDCP）レイヤ、Radio Link Control（RLC）レイヤ、Medium Access Control（MAC）レイヤ、およびPhysical（PHY）レイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ１４０３によるコントロールプレーン処理は、Non-Access Stratum（NAS）プロトコル、Radio Resource Control（RRC）プロトコル、及びMAC Control Elements（CEs）の処理を含んでもよい。

ベースバンドプロセッサ１４０３は、ビームフォーミングのためのMultiple Input Multiple Output（MIMO）エンコーディング及びプリコーディングを行ってもよい。

ベースバンドプロセッサ１４０３は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., Digital Signal Processor（DSP））とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., Central Processing Unit（CPU）又はMicro Processing Unit（MPU））を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ１４０４と共通化されてもよい。

アプリケーションプロセッサ１４０４は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ１４０４は、複数のプロセッサ（複数のプロセッサコア）を含んでもよい。アプリケーションプロセッサ１４０４は、メモリ１４０６又は図示されていないメモリから読み出されたシステムソフトウェアプログラム（Operating System（OS））及び様々なアプリケーションプログラム（例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション）を実行することによって、UE３の各種機能を実現する。

幾つかの実装において、図１４に破線（１４０５）で示されているように、ベースバンドプロセッサ１４０３及びアプリケーションプロセッサ１４０４は、１つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ１４０３及びアプリケーションプロセッサ１４０４は、１つのSystem on Chip（SoC）デバイス１４０５として実装されてもよい。SoCデバイスは、システムLarge Scale Integration（LSI）またはチップセットと呼ばれることもある。

メモリ１４０６は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ１４０６は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ１４０６は、ベースバンドプロセッサ１４０３、アプリケーションプロセッサ１４０４、及びSoC１４０５からアクセス可能な外部メモリデバイスを含んでもよい。メモリ１４０６は、ベースバンドプロセッサ１４０３内、アプリケーションプロセッサ１４０４内、又はSoC１４０５内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ１４０６は、Universal Integrated Circuit Card（UICC）内のメモリを含んでもよい。

メモリ１４０６は、上述の複数の実施形態で説明されたUE３による処理を行うための命令群およびデータを含む１つ又はそれ以上のソフトウェアモジュール（コンピュータプログラム）１４０７を格納してもよい。幾つかの実装において、ベースバンドプロセッサ１４０３又はアプリケーションプロセッサ１４０４は、当該ソフトウェアモジュール１４０７をメモリ１４０６から読み出して実行することで、上述の実施形態で図面を用いて説明されたUE３の処理を行うよう構成されてもよい。

なお、上述の実施形態で説明されたUE３によって行われるコントロールプレーン処理及び動作は、RFトランシーバ１４０１及びアンテナアレイ１４０２を除く他の要素、すなわちベースバンドプロセッサ１４０３及びアプリケーションプロセッサ１４０４の少なくとも一方とソフトウェアモジュール１４０７を格納したメモリ１４０６とによって実現されることができる。

図１３及び図１４を用いて説明したように、上述の実施形態に係るgNB１、gNB２、UE３、及びng-eNB４が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

＜その他の実施形態＞
上述の実施形態は、各々独立に実施されてもよいし、実施形態全体又はその一部が適宜組み合わせて実施されてもよい。

上述の実施形態におけるUE３によるULデータ（DTCHデータ）の送信に２ステップ・ランダムアクセス（2-Step RA）手順が使用される場合、４ステップ・ランダムアクセス（4-Step RA）手順へのフォールバックが行われてもよい。具体的には、UE３は、2-Step RA手順の第１メッセージ（MsgA）でRRC（コネクション）再開要求メッセージ（e.g., RRC Resume Requestメッセージ）と共にULデータを送信する。New gNB１は、第１メッセージ（MsgA）のランダムアクセス・プリアンブルを検出できたが、第１メッセージ（MsgA）のデータ（payload）を正しく復号できなかった場合、4-Step RA手順へのフォールバックの通知を示すランダムアクセス・レスポンス（fallback RAR）を2 Step RA手順の第２メッセージ（MsgB）でUE３へ送信してもよい。UE３は、4-Step RA手順へのフォールバック通知を受信すると、4-Step RA手順の第３メッセージ（Msg3）で、2-Step RA手順の第１メッセージ（MsgA）で送信したRRC（コネクション）再開要求メッセージとULデータを送信する。以降、new gNB１、old gNB２及びUE３は、4-Step RA手順を用いた上述の実施形態と同様の動作を行ってもよい。

上述の実施形態におけるUE３によるULデータ（DTCHデータ）の送信は、RRC_INACTIVE状態のまま行われる。より具体的には、これは以下のように行われてもよい。UE３は、RRC_CONNECTED状態からRRC_INACTIVE状態に移る指示（SuspendConfig）を包含するRRC Releaseメッセージで受信すると、UEコンテキストを保存する。このUEコンテキストは、UE Access Stratum（AS）コンテキスト又はUE Inactive ASコンテキストとも呼ばれる。UEコンテキストには、例えば現在のセキュリティ情報、サービングセル（PCell）のセル識別子（cellIdentity, PCI）、UE３に割り当てられたC-RNTI、SDAPレイヤのIPデータ（QoSフロー）とDRBとの対応関係（QoS flow to DRB mapping rule）の情報が含まれる。さらに、UE３は、RRC_INACTIVE状態でのULデータ送信を許可することを示す情報がRRC Releaseメッセージ（例えば、SuspendConfig）に包含されているか否かを判定してもよい。そして、UE３がRRC_INACTIVE状態であるとき、UE３の上位レイヤ（Non-access stratum (NAS) layer）がRRCレイヤ（AS layer）へ送信すべきデータがあることを通知すると、UE３のRRCレイヤはRRC_INACTIVE状態でのULデータ送信を許可されているか否かを判定する。さらに、UE３は、それがサービングセル（RRC_INACTIVE状態のCamping cell）において許可されているか否か（又はサポートされているか否か）を判定してもよい。UE３は、RRC_INACTIVE状態でのULデータ送信を許可されている場合（さらに、それがサービングセルで許可されている場合）、保持しているUEコンテキストから必要情報を取り出し（restore）、RRC（connection）再開要求の手順を開始する。RRC（connection）再開要求の手順が４ステップのランダムアクセス（4-Step RA）手順で行われる場合には第３のメッセージ（Msg3）でULデータを送信し、２ステップのランダムアクセス（2-Step RA）手順で行われる場合には第１のメッセージのデータ部分（MsgA payload）でULデータを送信する。このとき、ULデータと共に送信されるRRC Resume Requestメッセージは、ULデータ送信を伴うこと（又は、それを目的としていること）を示すCause値（e.g. UL-data-Inactive, mo-Data-Inactive）を包含してもよい。そして、UE３は、RRC Resume Requestメッセージに応答してRRC Releaseメッセージを受信した場合、RRC_INACTIVE状態に留まる。このとき、UE３は保持しているUEコンテキストの一部をRRC Releaseメッセージ（e.g. SuspendConfig IE）に包含される設定情報と置き換える（当該設定情報で上書きする）。当該設定情報は、例えばRANエリア情報（e.g. ran-NotificationAreaInfo）、及びセキュリティ情報（e.g. nextHopChainingCount）を含んでもよい。さらに、当該設定情報は、UE３がRRC Resumeにおけるデータ送信を行うことを許可するか否か（言い換えると、UE３がそれを許可されているか否か）を示す情報を含んでもよい。当該情報は、さらに、UE３に設定されている１又はそれ以上のDRBsのうちどれが、RRC Resumeにおけるデータ送信を行うことが許可されるかを示してもよい。これにより、UE３は、再びULデータが発生した時点で滞在しているサービングセルにおいて、RRC_INACTIVE状態のままULデータを送信することができる。一方、UE３はRRC Resume Requestメッセージに応答して、RRC Resumeメッセージを受信した場合、RRC_CONNECTED状態へと移る。

上述の実施形態で説明されたように、Xn-Uインタフェース（GTP-Uトンネル）に関するGTP-U/UDP/IP packetsを転送するために使用されるold gNB２のIPアドレスは、Xn-Cインタフェース（XnAPプロトコル）に関するXnAP/SCTP/IP packetsを転送するために使用されるold gNB２のIPアドレスと同じであってもよい。Old gNB２は、new gNB１と事前にシグナルし、Xn-Uインタフェース及びXn-Cインタフェースの両方のために同じIPアドレスが使用されることをnew gNB１に通知してもよい。

同様に、Xn-Uインタフェース（GTP-Uトンネル）に関するGTP-U/UDP/IP packetsを転送するために使用されるnew gNB１のIPアドレスは、Xn-Cインタフェース（XnAPプロトコル）に関するXnAP/SCTP/IP packetsを転送するために使用されるnew gNB１のIPアドレスと同じであってもよい。New gNB１は、old gNB２と事前にシグナルし、Xn-Uインタフェース及びXn-Cインタフェースの両方のために同じIPアドレスが使用されることをold gNB２に通知してもよい。

上述の実施形態は、LTEにおいて実施されてもよい。具体的には、上述の実施形態は、EPC（又はその高度化）に接続されるLTE eNB（又はその高度化）のセルにおいて、UE３がRRC_INACTIVE状態のままULデータを送信する場合に適用されてもよい。より具体的には、new eNBがUE３からRRC（コネクション）再開要求メッセージと共にULデータを受信し、且つUE３のUEコンテキストがnew eNBにおいて利用可能でない場合に、new eNBは、X2インタフェースで第２タイプの制御メッセージをold eNBに送る。old eNBは、old eNBを介してULデータをコアネットワーク（i.e. EPC）に送信するか、或いはUEコンテキストをnew eNBへ送信するかを決定する。old eNBは、old eNBを介してULデータをコアネットワークに送信すると決定した場合、new eNBへold eNBのTNL情報を送信してもよい。new eNBは、これに応答して、ULデータをold eNBへ送信してもよい。これにより、UE３のUEコンテキストをold eNBからnew eNBへ移すことなく、ULデータをコアネットワークへ送信することができる。

上述の実施形態で説明されたnew gNB1（又はnew ng-eNB４）、old gNB２、及びUE３の動作は、UEによるLTE eNBのセルとng-eNBのセルとの間のcell reselection （intra-RAT inter-system cell reselectionとも呼ぶ）において実施されてもよく、LTE eNBのセルとgNBのセルとの間のinter-RAT cell reselectionにおいて実施されてもよい。例えば、上述の実施形態で説明されたnew gNB1（又はnew ng-eNB４）及びold gNB２の動作は、LTE eNBとng-eNBとの間で実施されてもよく、LTE eNBとgNBとの間で実施されてもよい。

さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）
第１のRadio Access Network（RAN）ノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
Radio Resource Control (RRC)_INACTIVE状態の無線端末からアップリンクデータを伴わないRRC再開要求メッセージを受信し、且つ前記無線端末の無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求する第１タイプの制御メッセージを前記無線端末の直近のサービングRANノードである第２のRANノードに送るよう構成され、
前記RRC_INACTIVE状態の前記無線端末から前記アップリンクデータを前記RRC再開要求メッセージと共に受信し、且つ前記無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求し且つ前記第１タイプの制御メッセージと区別された第２タイプの制御メッセージを前記第２のRANノードに送るよう構成される、
第１のRANノード。
（付記２）
前記第２タイプの制御メッセージは、前記第２タイプの制御メッセージが前記アップリンクデータの存在を直接的に又は間接的に表す表示を含むことによって、前記第１タイプの制御メッセージと区別される、
付記１に記載の第１のRANノード。
（付記３）
前記第２タイプの制御メッセージは、前記第２タイプの制御メッセージが前記第２のRANノードのトランスポート・ネットワーク・レイヤ（TNL）情報の要求を表す表示を含むことによって、前記第１タイプの制御メッセージと区別される、
付記１に記載の第１のRANノード。
（付記４）
前記少なくとも１つのプロセッサは、
前記第２タイプの制御メッセージの送信後に第３の制御メッセージを前記第２のRANノードから受信するよう構成され、
前記第３の制御メッセージが前記無線端末コンテキストのリロケーションが行われないことを示すことに応答して、前記アップリンクデータを前記第２のRANノードに送信するよう構成される、
付記１～３のいずれか１項に記載の第１のRANノード。
（付記５）
前記少なくとも１つのプロセッサは、
前記第２タイプの制御メッセージの送信後に第３の制御メッセージを前記第２のRANノードから受信するよう構成され、
前記第３の制御メッセージが前記第２のRANノードを介するアップリンクデータ転送の許可を示すことに応答して、前記アップリンクデータを前記第２のRANノードに送信するよう構成される、
付記１～３のいずれか１項に記載の第１のRANノード。
（付記６）
前記少なくとも１つのプロセッサは、前記第２タイプの制御メッセージの送信後に、前記第２のRANノードのトランスポート・ネットワーク・レイヤ（TNL）情報を示す第３の制御メッセージを前記第２のRANノードから受信したことに応答して、前記アップリンクデータを前記第２のRANノードに送信するよう構成される、
付記１～３のいずれか１項に記載の第１のRANノード。
（付記７）
前記第２タイプの制御メッセージは、前記第２タイプの制御メッセージが前記アップリンクデータそれ自体を含むことによって、前記第１タイプの制御メッセージと区別される、
付記１に記載の第１のRANノード。
（付記８）
前記少なくとも１つのプロセッサは、前記アップリンクデータを特定するため又は復号化するために必要な追加情報を前記第２タイプの制御メッセージに含めるよう構成される、
付記７に記載の第１のRANノード。
（付記９）
前記追加情報は、データ無線ベアラ識別子及び論理チャネル識別子のうち一方又は両方を含む、
付記８に記載の第１のRANノード。
（付記１０）
前記少なくとも１つのプロセッサは、
データ活動のタイプを示すタイプ情報を前記アップリンクデータと共に前記無線端末から受信するよう構成され、
前記データ活動の前記タイプを前記第２のRANノードに前記第２タイプの制御メッセージを介して知らせるよう構成される、
付記１～９のいずれか１項に記載の第１のRANノード。
（付記１１）
前記データ活動の前記タイプは、前記アップリンクデータの送信のみである第１のタイプ、前記アップリンクデータの送信に引き続く追加のアップリンクデータ送信の発生が予定される（expected）第２のタイプ、及び前記アップリンクデータの送信後にダウンリンクデータ送信の発生が予定される第３のタイプを含む複数のタイプから選択される、
付記１０に記載の第１のRANノード。
（付記１２）
前記少なくとも１つのプロセッサは、前記第１のRANノードのトランスポート・ネットワーク・レイヤ（TNL）情報を前記第２タイプの制御メッセージに含めるよう構成される、
付記１～１１のいずれか１項に記載の第１のRANノード。
（付記１３）
第２のRadio Access Network（RAN）ノードであって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、
Radio Resource Control (RRC)_INACTIVE状態の無線端末の無線端末コンテキストを保持するよう構成され、
前記無線端末コンテキストを要求する制御メッセージを第１のRANノードから受信するよう構成され、
前記制御メッセージが、前記第１のRANノードが前記RRC_INACTIVE状態の前記無線端末からアップリンクデータをRRC再開要求メッセージと共に受信した場合に使用される特定のタイプであるか否かを判定するよう構成される、
第２のRANノード。
（付記１４）
前記特定のタイプは、前記制御メッセージが前記アップリンクデータの存在を直接的に又は間接的に表す表示を含むことによって、他のタイプと区別される、
付記１３に記載の第２のRANノード。
（付記１５）
前記特定のタイプは、前記制御メッセージが前記第２のRANノードのトランスポート・ネットワーク・レイヤ（TNL）情報の要求を表す表示を含むことによって、他のタイプと区別される、
付記１３に記載の第２のRANノード。
（付記１６）
前記特定のタイプは、前記制御メッセージが前記アップリンクデータそれ自体を含むことによって、他のタイプと区別される、
付記１３に記載の第２のRANノード。
（付記１７）
前記少なくとも１つのプロセッサは、前記制御メッセージが前記特定のタイプであるなら、前記無線端末コンテキストを前記第１のRANノードに提供せずに、前記アップリンクデータを前記第２のRANノードを介してコアネットワークに送信するよう構成される、
付記１３～１６のいずれか１項に記載の第２のRANノード。
（付記１８）
前記少なくとも１つのプロセッサは、前記制御メッセージが前記特定のタイプである場合、前記アップリンクデータを前記第２のRANノードを介してコアネットワークに送信するか否かを決定するよう構成される、
付記１３～１７のいずれか１項に記載の第２のRANノード。
（付記１９）
前記少なくとも１つのプロセッサは、前記制御メッセージによって示される前記無線端末のデータ活動のタイプを考慮して、前記アップリンクデータを前記第２のRANノードを介して前記コアネットワークに送信するか否かを決定するよう構成される、
付記１８に記載の第２のRANノード。
（付記２０）
前記データ活動の前記タイプは、前記アップリンクデータの送信のみである第１のタイプ、前記アップリンクデータの送信に引き続く追加のアップリンクデータ送信の発生が予定される（expected）第２のタイプ、及び前記アップリンクデータの送信後にダウンリンクデータ送信の発生が予定される第３のタイプを含む複数のタイプから選択される、
付記１９に記載の第２のRANノード。
（付記２１）
前記少なくとも１つのプロセッサは、前記アップリンクデータを前記第２のRANノードを介して前記コアネットワークに送信することを決定したことに応答して、前記第２のRANノードのトランスポート・ネットワーク・レイヤ（TNL）情報を示す制御メッセージを前記第１のRANノードに送るよう構成される、
付記１８～２０のいずれか１項に記載の第２のRANノード。
（付記２２）
前記少なくとも１つのプロセッサは、前記アップリンクデータを前記第２のRANノードを介して前記コアネットワークに送信することを決定したことに応答して、前記無線端末コンテキストのリロケーションが行われないことを示す制御メッセージを前記第１のRANノードに送るよう構成される、
付記１８～２０のいずれか１項に記載の第２のRANノード。
（付記２３）
前記少なくとも１つのプロセッサは、前記アップリンクデータを前記第２のRANノードを介して前記コアネットワークに送信することを決定したことに応答して、前記第２のRANノードを介するアップリンクデータ転送の許可を示す制御メッセージを前記第１のRANノードに送るよう構成される、
付記１８～２０のいずれか１項に記載の第２のRANノード。
（付記２４）
無線端末であって、
少なくとも１つのメモリと、
前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、前記無線端末がRadio Resource Control (RRC)_INACTIVE状態であるときに、アップリンクデータとデータ活動のタイプを示すタイプ情報を、RRC再開要求メッセージと共にRadio Access Network（RAN）ノードに送信するよう構成される、
無線端末。
（付記２５）
前記少なくとも１つのプロセッサは、前記データ活動の前記タイプを、前記アップリンクデータの送信のみである第１のタイプ、前記アップリンクデータに引き続く追加のアップリンクデータ送信の発生が予定される（expected）第２のタイプ、及び前記アップリンクデータの送信後にダウンリンクデータ送信の発生が予定される第３のタイプを含む複数のタイプから選択するよう構成される、
付記２４に記載の無線端末。
（付記２６）
前記タイプ情報は、前記RRC再開要求メッセージに含まれる、
付記２４又は２５に記載の無線端末。
（付記２７）
第１のRadio Access Network（RAN）ノードにより行われる方法であって、
Radio Resource Control (RRC)_INACTIVE状態の無線端末からアップリンクデータを伴わないRRC再開要求メッセージを受信し、且つ前記無線端末の無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求する第１タイプの制御メッセージを前記無線端末の直近のサービングRANノードである第２のRANノードに送ること、及び
前記RRC_INACTIVE状態の前記無線端末から前記アップリンクデータを前記RRC再開要求メッセージと共に受信し、且つ前記無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求し且つ前記第１タイプの制御メッセージと区別された第２タイプの制御メッセージを前記第２のRANノードに送ること、
を備える方法。
（付記２８）
第２のRadio Access Network（RAN）ノードにより行われる方法であって、
Radio Resource Control (RRC)_INACTIVE状態の無線端末の無線端末コンテキストを保持すること、
前記無線端末コンテキストを要求する制御メッセージを第１のRANノードから受信すること、及び
前記制御メッセージが、前記第１のRANノードが前記RRC_INACTIVE状態の前記無線端末からアップリンクデータをRRC再開要求メッセージと共に受信した場合に使用される特定のタイプであるか否かを判定すること、
を備える方法。
（付記２９）
無線端末により行われる方法であって、
前記無線端末がRadio Resource Control (RRC)_INACTIVE状態であるときに、アップリンクデータとデータ活動のタイプを示すタイプ情報を、RRC再開要求メッセージと共にRadio Access Network（RAN）ノードに送信すること、
を備える方法。
（付記３０）
第１のRadio Access Network（RAN）ノードのための方法をコンピュータに行わせるプログラムであって、
前記方法は、
Radio Resource Control (RRC)_INACTIVE状態の無線端末からアップリンクデータを伴わないRRC再開要求メッセージを受信し、且つ前記無線端末の無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求する第１タイプの制御メッセージを前記無線端末の直近のサービングRANノードである第２のRANノードに送ること、及び
前記RRC_INACTIVE状態の前記無線端末から前記アップリンクデータを前記RRC再開要求メッセージと共に受信し、且つ前記無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求し且つ前記第１タイプの制御メッセージと区別された第２タイプの制御メッセージを前記第２のRANノードに送ること、
を備える、プログラム。
（付記３１）
第２のRadio Access Network（RAN）ノードのための方法をコンピュータに行わせるプログラムであって、
前記方法は、
Radio Resource Control (RRC)_INACTIVE状態の無線端末の無線端末コンテキストを保持すること、
前記無線端末コンテキストを要求する制御メッセージを第１のRANノードから受信すること、及び
前記制御メッセージが、前記第１のRANノードが前記RRC_INACTIVE状態の前記無線端末からアップリンクデータをRRC再開要求メッセージと共に受信した場合に使用される特定のタイプであるか否かを判定すること、
を備える、プログラム。
（付記３２）
無線端末のための方法をコンピュータに行わせるプログラムであって、
前記方法は、前記無線端末がRadio Resource Control (RRC)_INACTIVE状態であるときに、アップリンクデータとデータ活動のタイプを示すタイプ情報を、RRC再開要求メッセージと共にRadio Access Network（RAN）ノードに送信することを備える、
プログラム。

この出願は、２０２０年２月１３日に出願された日本出願特願２０２０－０２２４７１を基礎とする優先権を主張し、その開示の全てをここに取り込む。

１ gNB
２ gNB
３ UE
４ ng-eNB
１３０４ プロセッサ
１３０５ メモリ
１３０６ モジュール（modules）
１４０３ ベースバンドプロセッサ
１４０４ アプリケーションプロセッサ
１４０６ メモリ
１４０７ モジュール（modules）

Claims (9)

1. 第１のRadio Access Network（RAN）ノードであって、
   少なくとも１つのメモリと、
   前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   Radio Resource Control (RRC)_INACTIVE状態の無線端末からアップリンクデータを伴わないRRC再開要求メッセージを受信し、且つ前記無線端末の無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求する第１タイプの制御メッセージを前記無線端末の直近のサービングRANノードである第２のRANノードに送るよう構成され、
   前記RRC_INACTIVE状態の前記無線端末から前記アップリンクデータを前記RRC再開要求メッセージと共に受信し、且つ前記無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求し且つ前記第１タイプの制御メッセージと区別された第２タイプの制御メッセージを前記第２のRANノードに送るよう構成される、
   第１のRANノード。
2. 前記第２タイプの制御メッセージは、前記第２タイプの制御メッセージが前記アップリンクデータの存在を直接的に又は間接的に表す表示を含むことによって、前記第１タイプの制御メッセージと区別される、
   請求項１に記載の第１のRANノード。
3. 前記第２タイプの制御メッセージは、前記第２タイプの制御メッセージが前記第２のRANノードのトランスポート・ネットワーク・レイヤ（TNL）情報の要求を表す表示を含むことによって、前記第１タイプの制御メッセージと区別される、
   請求項１に記載の第１のRANノード。
4. 前記少なくとも１つのプロセッサは、
   前記第２タイプの制御メッセージの送信後に第３の制御メッセージを前記第２のRANノードから受信するよう構成され、
   前記第３の制御メッセージが前記無線端末コンテキストのリロケーションが行われないことを示すことに応答して、前記アップリンクデータを前記第２のRANノードに送信するよう構成される、
   請求項１～３のいずれか１項に記載の第１のRANノード。
5. 前記少なくとも１つのプロセッサは、
   前記第２タイプの制御メッセージの送信後に第３の制御メッセージを前記第２のRANノードから受信するよう構成され、
   前記第３の制御メッセージが前記第２のRANノードを介するアップリンクデータ転送の許可を示すことに応答して、前記アップリンクデータを前記第２のRANノードに送信するよう構成される、
   請求項１～３のいずれか１項に記載の第１のRANノード。
6. 前記少なくとも１つのプロセッサは、前記第２タイプの制御メッセージの送信後に、前記第２のRANノードのトランスポート・ネットワーク・レイヤ（TNL）情報を示す第３の制御メッセージを前記第２のRANノードから受信したことに応答して、前記アップリンクデータを前記第２のRANノードに送信するよう構成される、
   請求項１～３のいずれか１項に記載の第１のRANノード。
7. 第２のRadio Access Network（RAN）ノードであって、
   少なくとも１つのメモリと、
   前記少なくとも１つのメモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   Radio Resource Control (RRC)_INACTIVE状態の無線端末の無線端末コンテキストを保持するよう構成され、
   前記無線端末コンテキストを要求する制御メッセージを第１のRANノードから受信するよう構成され、
   前記制御メッセージが、前記第１のRANノードが前記RRC_INACTIVE状態の前記無線端末からアップリンクデータをRRC再開要求メッセージと共に受信した場合に使用される特定のタイプであるか否かを判定するよう構成される、
   第２のRANノード。
8. 前記少なくとも１つのプロセッサは、前記制御メッセージが前記特定のタイプであるなら、前記無線端末コンテキストを前記第１のRANノードに提供せずに、前記アップリンクデータを前記第２のRANノードを介してコアネットワークに送信するよう構成される、
   請求項７に記載の第２のRANノード。
9. 第１のRadio Access Network（RAN）ノードにより行われる方法であって、
   Radio Resource Control (RRC)_INACTIVE状態の無線端末からアップリンクデータを伴わないRRC再開要求メッセージを受信し、且つ前記無線端末の無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求する第１タイプの制御メッセージを前記無線端末の直近のサービングRANノードである第２のRANノードに送ること、及び
   前記RRC_INACTIVE状態の前記無線端末から前記アップリンクデータを前記RRC再開要求メッセージと共に受信し、且つ前記無線端末コンテキストが前記第１のRANノードにおいて利用可能でない場合に、前記無線端末コンテキストを要求し且つ前記第１タイプの制御メッセージと区別された第２タイプの制御メッセージを前記第２のRANノードに送ること、
   を備える方法。

Images