JP6969636B2 - 無線端末、無線端末における方法、及び無線局 - Google Patents

Description

本開示は、データ送信のための複数の通信アーキテクチャ・タイプをサポートする無線通信システムに関する。

3rd Generation Partnership Project (3GPP)ではCellular Internet of Things（CIoT）の標準化が行われている。3GPPが対象としているCIoTは、Long Term Evolution enhanced Machine to Machine（LTE eMTC）及びNarrowband IoT（NB-IoT）を含む。LTE eMTC及びNB-IoTは、極めて低いUser Equipment（UE）消費電力（Ultra low UE power consumption）、セルあたりの多数のデバイス、狭帯域スペクトラム、拡張されたカバレッジ等の特徴を含む。LTE eMTC（Category M）では、UEの受信無線周波数（Radio Frequency（RF））帯域は1.4 MHzと定められている。これに対して、NB-IoTでは、更なるコスト最適化、低消費電力、及びカバレッジ拡張のために、ダウンリンク及びアップリンクのピークレートが200 kbps又は144 kbpsであり、UEの受信RF帯域は、アップリンク及びダウンリンクともに200 kHz程度（実効180 kHz）であることが想定されている。

非特許文献１は、NB-IoTにおける頻繁でないスモールデータ送信（infrequent small data transmission）のための幾つかの通信アーキテクチャ・ソリューションを記載している。これらのソリューションは、コントロールプレーンでのデータ送信アーキテクチャ（ソリューション２）と、RRCコネクションの一時中止（suspension）及び再開（resumption）を伴う ユーザプレーンでのデータ送信アーキテクチャ（ソリューション１８）を含む。非特許文献１では、ソリューション２のサポートがUE及びネットワークの両方に必須とされており、ソリューション１８のサポートがUE及びネットワークの両方にオプションとされている。

ソリューション２は、CIoTのためのライトウェイト・コアネットワーク（CN）アーキテクチャに基づいている。ライトウェイトCNアーキテクチャでは、CIoTデバイスの典型的なユースケースを考慮して、コアネットワークは、既存のLTEのCNエンティティ（i.e., Mobility Management Entity（MME）、Serving Gateway（S-GW）、及びPacket Data Network Gateway（P-GW））と比べて限られた機能のみをサポートする。図１は、非ローミングのケースでのCIoTのためのネットワークアーキテクチャを示している。

CIoT Serving Gateway Node（C-SGN）は、新たな論理的なネットワークエンティティである。C-SGNは、コントロールプレーン（CP）及びユーザプレーン（UP）を兼ね備えたCNノードである。C-SGNは、CIoTデバイスのための限られたモビリティ管理（Mobility Management（MM））手順、スモールデータ送信手順、スモールデータ送信のためのセキュリティ手順、非ローミングのケースのためのSGiインタフェースの終端を提供する。なお、P-GW機能は、C-SGNから分離されてもよい。この場合、S5インタフェースがC-SGNとP-GWの間に使用される。ローミングのケースの場合、C-SGNは、S8インタフェースを提供する。

S1-liteインタフェースは、S1-C（S1-MME）の最適化されたバージョンである。S1-liteインタフェースは、CIoTのための手順に必要なS1 Application Protocol（S1AP）メッセージ及び情報要素（Information Elements（IEs））をサポートし、最適化されたセキュリティ手順をサポートする。効率的なスモールデータ送信のために、ユーザデータは、S1APレイヤで運ばれる。

具体的には、非ローミングケースのMobile Originated（MO）スモールデータ送信の場合、UEは、スモールデータパケット（e.g., Internet Protocol（IP）、non-IP、short message service（SMS））を運ぶアップリンクNon-Access Stratum（NAS）メッセージを送信する。当該アップリンクNASメッセージは、CIoT Base Station（CIoT BS）を介してC-SGNに届く。当該アップリンクNASメッセージは、シグナリング無線ベアラ（Signaling Radio Bearer（SRB）上で送信される。従って、データ無線ベアラ（Data Radio Bearer（DRB））のセットアップは必要とされない。また、Access Stratum（AS）セキュリティは省略されてもよい。

C-SGNは、スモールデータパケットを得るために、当該アップリンクNASメッセージを復号化（decrypt）する。C-SGNは、スモールデータパケットのデータタイプに依存して、スモールデータパケットをフォワードする。IPスモールデータの場合、C-SGNは、これをSGiインタフェース上で送信する。SMSの場合、C-SGNは、これをSMSに関するエンティティ（e.g., SMS Gateway Mobile Services Switching Center（SMS-GMSC）、SMS Interworking Mobile Services Switching Center（SMS-IWMSC）、SMS router）に送る。Non-IPスモールデータの場合、C-SGNは、これをService Capability Exposure Function（SCEF）に送信する。

非ローミングケースのMobile Terminated（MT）スモールデータ送信の場合、C-SGNは、スモールデータパケットを運ぶダウンリンクNASメッセージをUEにCIoT BSを介して送信する。ダウンリンクでのスモールデータパケット送信においてもDRBは必要とされず、ASセキュリティは省略されてもよい。

図１に示されたCIoT BSは、CIoT Radio Access Network（CIoT RAN）内の基地局である。図１のCIoT BSの代わりに、C-SGNと接続できるよう構成されたLTE eNBが使用されてもよい。このLTE eNBは、LTE eMTCをサポートするeNBであってもよい。

一方、ソリューション１８に係るアーキテクチャは、頻繁でないスモールデータのユーザプレーン上での送信を提供する。ただし、UEのRadio Resource Control（RRC）状態遷移に伴うシグナリングを削減するために、ソリューション１８に係るアーキテクチャは、以前の（previous）RRCコネクションからの情報を後の（subsequent）のRRCコネクション・セットアップのために再利用することを特徴とする。

具体的には、UEは、RRC-ConnectedからRRC-Idleモードに遷移し、RRC-IdleモードにおいてRRCコネクションに関する情報、e.g., Access Stratum Security Context, bearer related information (incl. RoHC state information) and L2/1 parameters when applicableを保持（retain）する。同様に、eNBも、当該UEのRRCコネクションに関する情報、e.g., Access Stratum Security Context, bearer related information (incl. RoHC state information) and L2/1 parameters when applicableを保持する。さらに、eNB及びMMEは、S1AP UE Contextsを保持する。さらにまた、eNBは、S1-U tunnel addressesを保持する。

RRC-Connectedモードに戻るとき、UEは、RRC Connection Resume RequestをeNBに送る。eNBは、保持していたRRCコネクションに関する情報に基づいて、DRB、セキュリティコンテキスト、S1APコネクション、S1-Uトンネルを復元する。さらに、eNBは、新たなS1AP message（i.e., S1-AP UE Context Active）を用いて、UE 状態変更（state change）をMMEに知らせる。MMEは、当該UEのEvolved Packet System（EPS）Connection Management（ECM）状態をECM-Connected 状態に戻し、Modify Bearer Request messageをS-GWに送る。これにより、S-GWは、UE が Connected状態にあると認識し、当該UEに向けたダウンリンクデータを送信できる状態となる。

ソリューション１８では、UEは、NASメッセージ（i.e., Service Request）を送信せずに、RRC-ConnectedかつECM-Connected に戻ることができる。また、既存の（legacy）RRCコネクション・セットアップ手順に比べて、以下のRRCメッセージを削減できる：
・RRC Connection Setup Complete；
・RRC Security Mode Command；
・RRC Security Mode Complete；
・RRC Connection Reconfiguration；及び
・RRC Connection Reconfiguration Complete。

非特許文献２は、上述のソリューション２のアーキテクチャ及びソリューション１８のアーキテクチャのうちどちらを使用したいかをUEがアタッチ手順において決定してもよいことを記載している。さらに、非特許文献２は、ソリューション２又はソリューション１８をデータ送信のために選択することをネットワークに可能とするための情報をAS手順またはNAS手順が含んでもよいことを記載している。

3GPP TR 23.720 V1.2.0 (2015-11), "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for Cellular Internet of Things (Release 13)", November 2015 3GPP R2-156645, Qualcomm Incorporated, "NB-IoT SA2 architecture implications", 3GPP TSG RAN WG2 #92, Anaheim, USA, 16-20 November 2015

発明者等は、CIoTのための通信アーキテクチャ又は無線端末の省電力化ための通信アーキテクチャに関して検討を行い、幾つかの課題を見出した。例えば、非特許文献１及び２は、複数の通信アーキテクチャ・タイプ（e.g., ソリューション２及びソリューション１８）の中からUEのデータパケット送信のために使用されるアーキテクチャ・タイプを決定するための具体的な手順を示していない。発明者等は、CIoTデバイスとしてのUEのために使用される通信アーキテクチャの決定（又は選択）を伴う具体的な通信手順を検討し、通信手順の効率化、シグナリングメッセージの削減、又は適切なCN選択などに寄与する幾つかの改良を考案した。

また、例えば、非特許文献１及び２は、CIoTデバイスとしてのUEのモビリティについて十分に考慮していない。ここで、CIoTデバイスのモビリティは、アイドルモード（e.g., RRC-Idle）でのセル変更（アイドルモード・モビリティ）およびコネクテッドモード（e.g., RRC-Connectedモード）でのセル変更（コネクテッドモード・モビリティ）を含む。発明者等は、CIoTデバイスのモビリティ手順に関するいくつかの改良を考案した。

したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、CIoTデバイスとしてのUEのために使用される通信アーキテクチャの決定（又は選択）を伴う具体的な通信手順に関して、通信手順の効率化、シグナリングメッセージの削減、又は適切なCN選択に寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

第１の態様では、無線端末は、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうちいずれの使用を希望するか、いずれをサポートしているか、又はいずれが設定されているかを示す確立要因又はその他の情報要素を含むRadio Resource Control（RRC）コネクション要求メッセージを無線局に送信するよう構成されている。

第２の態様では、無線端末における方法は、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうちいずれの使用を希望するか、いずれをサポートしているか、又はいずれが設定されているかを示す確立要因又はその他の情報要素を含むRadio Resource Control（RRC）コネクション要求メッセージを無線局に送信することを含む。

第３の態様では、無線局は、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、無線端末からRadio Resource Control（RRC）コネクション要求メッセージを受信するよう構成されている。さらに、前記少なくとも１つのプロセッサは、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうち前記無線端末がいずれの使用を希望するか、いずれをサポートしているか、又はいずれが設定されているかを示す確立要因又はその他の情報要素を前記RRCコネクション要求メッセージから取り出すよう構成されている。

第４の態様では、無線局における方法は、（ａ）無線端末からRadio Resource Control（RRC）コネクション要求メッセージを受信すること、及び（ｂ）Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうち前記無線端末がいずれの使用を希望するか、いずれをサポートしているか、又はいずれが設定されているかを示す確立要因又はその他の情報要素を前記RRCコネクション要求メッセージから取り出すこと、を含む。

第５の態様では、無線端末は、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうちいずれの使用を希望するか、いずれをサポートしているか、又はいずれが設定されているかを示すUEアシスタンス情報要素を含むRadio Resource Control（RRC）コネクション・セットアップ完了メッセージを無線局に送信するよう構成されている。

第６の態様では、無線端末における方法は、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうちいずれの使用を希望するか、いずれをサポートしているか、又はいずれが設定されているかを示すUEアシスタンス情報要素を含むRadio Resource Control（RRC）コネクション・セットアップ完了メッセージを無線局に送信することを含む。

第７の態様では、無線局は、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、無線端末からRadio Resource Control（RRC）コネクション・セットアップ完了メッセージを受信するよう構成されている。さらに、前記少なくとも１つのプロセッサは、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうち前記無線端末がいずれの使用を希望するか、いずれをサポートしているか、又はいずれが設定されているかを示すUEアシスタンス情報要素を前記RRCコネクション・セットアップ完了メッセージから取り出すよう構成されている。

第８の態様では、無線局における方法は、（ａ）無線端末からRadio Resource Control（RRC）コネクション・セットアップ完了メッセージを受信すること、及び（ｂ）Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうち前記無線端末がいずれの使用を希望するか、いずれをサポートしているか、又はいずれが設定されているかを示すUEアシスタンス情報要素を前記RRCコネクション・セットアップ完了メッセージから取り出すこと、を含む。

第９の態様では、無線局は、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、Radio Resource Control（RRC）コネクション・セットアップ完了メッセージを無線端末から受信するよう構成されている。さらに、前記少なくとも１つのプロセッサは、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうちデータパケットがユーザプレーンを介して送信される第２の通信アーキテクチャ・タイプが前記無線端末のために使用される場合に、前記RRCコネクション・セットアップ完了メッセージから取り出されたイニシャルNon-Access Stratum（NAS）メッセージと前記第２の通信アーキテクチャ・タイプで使用されるダウンリンク・トンネル・エンドポイント識別子とを包含するイニシャルUEメッセージを生成するよう構成されている。さらにまた、前記少なくとも１つのプロセッサは、前記イニシャルUEメッセージをコアネットワークに送信するよう構成されている。

第１０の態様では、無線局における方法は、
（ａ）Radio Resource Control（RRC）コネクション・セットアップ完了メッセージを無線端末から受信すること、
（ｂ）Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうちデータパケットがユーザプレーンを介して送信される第２の通信アーキテクチャ・タイプが前記無線端末のために使用される場合に、前記RRCコネクション・セットアップ完了メッセージから取り出されたイニシャルNon-Access Stratum（NAS）メッセージと前記第２の通信アーキテクチャ・タイプで使用されるダウンリンク・トンネル・エンドポイント識別子とを包含するイニシャルUEメッセージを生成すること、及び
（ｃ）前記イニシャルUEメッセージをコアネットワークに送信すること、
を含む。

第１１の態様では、コアネットワークノードは、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、イニシャルUEメッセージを無線局から受信するよう構成されている。前記イニシャルUEメッセージは、無線端末からのイニシャルNon-Access Stratum（NAS）メッセージと、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプの中から前記無線局により決定された通信アーキテクチャ・タイプを示す情報要素とを包含する。さらに、前記少なくとも１つのプロセッサは、前記情報要素に基づいて、前記決定された通信アーキテクチャ・タイプに対応するコアネットワークに前記イニシャルNASメッセージをリルートすることを決定するよう構成されている。さらにまた、前記少なくとも１つのプロセッサは、前記イニシャルNASメッセージが前記対応するコアネットワークにリルートされることを示すリルートNASメッセージ要求メッセージを前記無線局に送信するよう構成されている。

第１２の態様では、コアネットワークノードにおける方法は、
（ａ）イニシャルUEメッセージを無線局から受信すること、前記イニシャルUEメッセージは、無線端末からのイニシャルNon-Access Stratum（NAS）メッセージと、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプの中から前記無線局により決定された通信アーキテクチャ・タイプを示す情報要素とを包含し；
（ｂ）前記情報要素に基づいて、前記決定された通信アーキテクチャ・タイプに対応するコアネットワークに前記イニシャルNASメッセージをリルートすることを決定すること；及び
（ｃ）前記イニシャルNASメッセージが前記対応するコアネットワークにリルートされることを示すリルートNASメッセージ要求メッセージを前記無線局に送信すること；
を含む。

第１３の態様では、コアネットワークノードは、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、イニシャルUEメッセージを無線局から受信するよう構成されている。前記イニシャルUEメッセージは、無線端末からのイニシャルNon-Access Stratum（NAS）メッセージと、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうちいずれの使用を前記無線端末が希望するか、いずれをサポートしているか、又はいずれが設定されているかを示す情報要素を包含する。前記少なくとも１つのプロセッサは、前記情報要素に基づいて、前記無線端末のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定するよう構成されている。さらに、前記少なくとも１つのプロセッサは、前記決定された通信アーキテクチャ・タイプに対応するコアネットワークに前記イニシャルNASメッセージをリルートすることを決定するよう構成されている。さらにまた、前記少なくとも１つのプロセッサは、前記イニシャルNASメッセージが前記対応するコアネットワークにリルートされることを示すリルートNASメッセージ要求メッセージを前記無線局に送信するよう構成されている。

第１４の態様では、コアネットワークノードにおける方法は、
（ａ）イニシャルUEメッセージを無線局から受信すること、前記イニシャルUEメッセージは、無線端末からのイニシャルNon-Access Stratum（NAS）メッセージと、Cellular Internet of Things（CIoT）に関するデータパケット送信のための複数の通信アーキテクチャ・タイプのうちいずれの使用を前記無線端末が希望するか、いずれをサポートしているか、又はいずれが設定されているかを示す情報要素を包含し；
（ｂ）前記情報要素に基づいて、前記無線端末のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定すること；
（ｃ）前記決定された通信アーキテクチャ・タイプに対応するコアネットワークに前記イニシャルNASメッセージをリルートすることを決定すること；及び
（ｄ）前記イニシャルNASメッセージが前記対応するコアネットワークにリルートされることを示すリルートNASメッセージ要求メッセージを前記無線局に送信すること；
を含む。

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

上述の態様によれば、CIoTデバイスとしてのUEのために使用される通信アーキテクチャの決定（又は選択）を伴う具体的な通信手順に関して、通信手順の効率化、シグナリングメッセージの削減、又は適切なCN選択に寄与する装置、方法、及びプログラムを提供できる。

CIoTアーキテクチャの一例を示す図である。 幾つかの実施形態に係る無線通信ネットワークの構成例を示す図である。 第１の実施形態に係る通信手順の一例を示すシーケンス図である。 第２の実施形態に係る通信手順の一例を示すシーケンス図である。 第３の実施形態に係る通信手順の一例を示すシーケンス図である。 第４の実施形態に係る通信手順の一例を示すシーケンス図である。 第５の実施形態に係る通信手順の一例を示すシーケンス図である。 第６の実施形態に係る通信手順の一例を示すシーケンス図である。 第７の実施形態に係る通信手順の一例を示すシーケンス図である。 第８の実施形態に係る通信手順の一例を示すシーケンス図である。 第９の実施形態に係る通信手順の一例を示すシーケンス図である。 第９の実施形態に係る通信手順の一例を示すシーケンス図である。 第１０の実施形態に係る通信手順の一例を示すシーケンス図である。 第１０の実施形態に係る通信手順の一例を示すシーケンス図である。 第１１の実施形態に係る通信手順の一例を示すシーケンス図である。 第１１の実施形態に係る通信手順の一例を示すシーケンス図である。 第１２の実施形態に係る通信手順の一例を示すシーケンス図である。 第１３の実施形態に係る通信手順の一例を示すシーケンス図である。 第１４の実施形態に係る通信手順の一例を示すシーケンス図である。 第１９の実施形態に係る通信手順の一例を示すシーケンス図である。 第１９の実施形態に係る通信手順の一例を示すシーケンス図である。 第２０の実施形態に係る通信手順の一例を示すシーケンス図である。 第２０の実施形態に係る通信手順の一例を示すシーケンス図である。 第２１の実施形態に係る通信手順の一例を示すシーケンス図である。 第２１の実施形態に係る通信手順の一例を示すシーケンス図である。 第２１の実施形態に係る通信手順の一例を示すシーケンス図である。 幾つかの実施形態に係る無線端末の構成例を示すブロック図である。 幾つかの実施形態に係る基地局の構成例を示すブロック図である。 幾つかの実施形態に係るコアネットワークノードの構成例を示すブロック図である。

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

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

以下に説明される複数の実施形態は、LTE eMTC及びNB-IoTを含むCIoTのための無線通信ネットワークを主な対象として説明される。しかしながら、これらの実施形態は、その他のCIoTのための無線通信ネットワークに適用されてもよい。

＜第１の実施形態＞
図２は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワークの構成例を示している。図２の例では、CIoTデバイスとしてのUE１は、CIoT無線アクセスネットワーク（RAN）２及びコアネットワーク（CN）３を介してアプリケーションサーバ４と通信する。RAN２は、CIoTに関するデータパケット送信のための複数の通信アーキテクチャ・タイプをサポートする。RAN２は、RAN２によってサポートされている複数の通信アーキテクチャ・タイプを明示的に又は暗示的に示す情報を例えばMaster Information Block（MIB）又はSystem Information Block（SIB）を用いてセルで報知する。UE１は、これら複数の通信アーキテクチャ・タイプのうち少なくとも１つをサポートする。CN３は、これら複数の通信アーキテクチャ・タイプをサポートする。CN３は、これら複数の通信アーキテクチャ・タイプのうちの一部に向けられた個別dedicated CN（DCN）と、他の一部に向けられた別のDCNを含んでもよい。

いくつかの実装において、複数の通信アーキテクチャ・タイプは、非特許文献１に示されたソリューション２及び１８にそれぞれ相当する第１及び第２の通信アーキテクチャ・タイプを含んでもよい。第１の通信アーキテクチャ・タイプでは、UE１によって送信又は受信されるユーザデータパケットがコントロールプレーン（e.g., UEとMME/C-SGNの間のNASメッセージ）を介して送信される。第１の通信アーキテクチャ・タイプでは、UE１のデータパケット送信のためにRAN２によるDRBのセットアップは必要とされない。また、データパケット送信に使用されるSRBに関して、RAN２によるAccess Stratum（AS）セキュリティ（i.e., ciphering and deciphering of control plane data及びintegrity protection and integrity verification of control plane data）は省略されてもよい。言い換えると、データパケット送信に使用されるSRBのためのPacket Data Convergence Protocol（PDCP）レイヤの処理は省略されてもよい。この場合、UE１のデータパケットは、NAS security keysを用いてUE１及びCN３（e.g., MME、C-SGN）によって暗号化及び復号化される。一方、第２の通信アーキテクチャ・タイプでは、UE１によって送信又は受信されるユーザデータパケットがユーザプレーン（e.g., DRB及びGeneral Packet Radio Service (GPRS) Tunneling Protocol（GTP）トンネルを包含するEPSベアラ）を介して送信される。

UE１は、LTE eMTC及びNB-IoTのいずれか又は両方をサポートしてもよい。言い換えると、UE１は、CIoT RAT（NB-IoT RAT）及びLTE RAT（eMTC）のいずれか又は両方をサポートしてもよい。RAN２は、CIoT RAT（NB-IoT RAT）をサポートするCIoT BS及びLTE RAT（eMTC）をサポートするeNBのいずれか又は両方を含んでもよい。CN３は、C-SGN、若しくはMME及びS-GW、又はこれら両方を含んでもよい。CN３は、さらに、P-GW、Home Subscriber Server（HSS）、及びPolicy and Charging Rules Function（PCRF）等の他のネットワークエンティティを含んでもよい。

図３は、本実施形態に係る通信手順の一例を示すシーケンス図である。図３の手順では、UE１のCN３へのアタッチ手順の間に、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプが決定される。UE１は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定し、決定された通信アーキテクチャ・タイプを明示的又は暗示的に示す確立要因（establishment cause）を含むRRCコネクション要求（RRC Connection Request）メッセージをRAN２に送信する。

ステップ３０１では、UE１は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定（選択）する。いくつかの実装において、UE１は、UE１に予め設定されたデフォルトUE 能力（capability）に基づいて、使用する通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、UE１は、RAN２からの参照信号の受信電力（RSRP）又はUE１とRAN２（CIoT-BS/eNB）の間の推定される伝搬損失を計測し、計測されたRSRP又は伝搬損失に基づいて、使用する通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、UE１は、計測されたRSRP又は伝搬損失に基づいて必要とされるカバレッジ向上（coverage enhancement（CE））レベルを決定し、当該CEレベルに基づいて通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、UE１は、データ送信トリガー（e.g., mo-Data、mo-ExceptionData、mt-Access、mo-Signaling）に応じて通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、UE１は、データパケット送信を行うアプリケーションの種別に応じて通信アーキテクチャ・タイプを選択してもよい。

ステップ３０２では、UE１は、ランダム・アクセス手順を開始する。すなわち、UE１は、ランダム・アクセス・プリアンブル（Random Access Channel （RACH）プリアンブル）をRAN２に送信し、RAN２からランダム・アクセス・レスポンス（RAR）メッセージを受信する。

ステップ３０３では、UE１は、ランダム・アクセス手順の第３メッセージ（Msg3）、つまりRRCコネクション要求（RRC Connection Request）メッセージをRAN２に送信する。当該RRC Connection Requestメッセージは、Common Control Channel（CCCH）上のSRB 0を用いて送信される。当該RRC Connection Requestメッセージは、UE１によって決定（選択）された通信アーキテクチャ・タイプを明示的又は暗示的に示す確立要因（establishment cause）情報要素を含む。

ここで、通信アーキテクチャ・タイプを示す確立要因は、例えば、第１（又は第２）の通信アーキテクチャ・タイプの場合には、通常の確立要因の１つ（e.g., mo-Data, mo-ExceptionData, mo-Signaling, mt-Access）を使用し、第２（又は第１）の通信アーキテクチャ・タイプの場合には、特定の確立要因を使用してもよい。特定の確立要因は、第１の通信アーキテクチャ・タイプに適用する場合、例えばNASメッセージでユーザデータを送信する通信アーキテクチャ・タイプであることを示す情報（e.g., mo-DataOverNAS, mo-ExceptionDataOverNAS, mo-SignalingDataOverNAS, mt-AccessDataOverNAS）でもよい。また、特定の確立要因は、第２の通信アーキテクチャ・タイプに適用する場合、例えばDRBを設定してユーザプレーン（UP）（ASメッセージ）でユーザデータを送信することを示す情報（e.g., mo-DataUP, mo-ExceptionDataUP, mo-SignalingUP, mt-AccessUP）でもよい。

ステップ３０４では、RAN２は、RRC Connection Requestメッセージの受信に応答して、RRCコネクション・セットアップ（RRC Connection Setup）メッセージをUE１に送信する。当該RRC Connection Setupメッセージは、CCCH上のSRB 0を用いて送信される。当該RRC Connection Setupメッセージは、SRB 1の設定情報を含み、後続の（subsequent）シグナリングにDedicated Control Channel（DCCH）を使用することを可能にする。

当該RRC Connection Setupメッセージは、PDCPの必要性を示してもよい。より具体的には、当該RRC Connection Setupメッセージは、PDCPの必要性（例えばPDCPを従来通り使用するか否か）をUE１に示してもよい。いくつかの実装において、PDCPの必要性を示すフラグ情報が、当該RRC Connection Setupメッセージに包含されるRadioResourceConfigDedicated IE内又は他のIE内に含まれてもよい。

いくつかの実装において、当該RRC Connection Setupメッセージに包含されているPDCP設定（pdcp-Config）がPDCPの必要性を示してもよい。当該PDCP設定は、PDCPの必要性（例えばPDCPを従来通り使用するか否か）をUE１に示すフラグ情報を含んでもよい。当該PDCP設定は、SRB1のPDCP Configのdefault設定を有効にするべきか否かをUE１に示す情報を含んでもよい。当該PDCP設定は、具体的なPDCP Config（例えば、SRB1に適用されるRLC-SAP及びPDCP Sequence Number (SN) length）を含んでもよい。あるいは、RAN２は、UE１により決定された通信アーキテクチャ・タイプに応じて、当該RRC Connection SetupメッセージにPDCP設定（pdcp-Config）を含めるか否かを決定してもよい。具体的には、RAN２は、UE１が第２の通信アーキテクチャ・タイプを選択した場合、当該RRC Connection SetupメッセージにSRB 1のためのPDCP設定を含めてもよい。

ステップ３０５では、UE１は、RRCコネクション・セットアップ完了（RRC Connection Setup Complete）メッセージをRAN２に送信する。当該RRC Connection Setup Completeメッセージは、DCCH上のSRB 1を用いて送信される。当該RRC Connection Setup Completeメッセージは、イニシャルNASメッセージを運ぶ。なお、図３はアタッチ手順を対象としているから、当該イニシャルNASメッセージはアタッチ要求（Attach Request）メッセージである。当該Attach Requestメッセージは、“CIoT Attach”にセットされたEPS attach type IE（情報要素）を含む。

RAN２は、UE１からRRC Connection Setup Completeメッセージを受信し、RRC Connection Setup Completeメッセージから取り出されたイニシャルNASメッセージ（i.e., Attach Requestメッセージ）をCN３（e.g., MME、C-SGN）にS1AP: イニシャルUE（Initial UE）メッセージを用いて送信する。イニシャルNASメッセージ（i.e., Attach Requestメッセージ）は、S1AP: Initial UEメッセージのNAS-Protocol Data Unit (PDU) IE（情報要素）に埋め込まれる。RAN２は、UE１により決定（選択）された通信アーキテクチャ・タイプを示す情報要素をS1AP: Initial UEメッセージに含めてもよい。RAN２は、UE１により決定された通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、イニシャルNASメッセージ（i.e., Attach Requestメッセージ）を運ぶS1AP: Initial UEメッセージを選択されたDCNに送信してもよい。

ステップ３０６では、CN３（e.g., MME、C-SGN）は、認証(Authentication)及びセキュリティ手順を実行し、NASセキュリティをセットアップする。認証及びセキュリティ手順に必要なダウンリンクNASメッセージ（i.e., Authentication Request及びNAS Security Mode Command）は、RRC: DL Information Transferメッセージを用いてSRB 1上で送信される。同様に、認証及びセキュリティ手順に必要なアップリンクNASメッセージ（i.e., Authentication Response及びNAS Security Mode Complete）は、RRC: UL Information Transferメッセージを用いてSRB 1上で送信される。

ステップ３０７では、CN３（e.g., MME、C-SGN）は、NAS: アタッチ承認（Attach Accept）メッセージをUE１に送信する。なお、UE１のためのセッション（e.g., DRB及びS1ベアラ）のセットアップは行われなくてもよい。このため、CN３（e.g., MME、C-SGN）は、S1AP: Initial Context Setup RequestメッセージをRAN２（e.g., CIoT-BS、eNB）に送信する必要はない。したがって、当該Attach Acceptメッセージは、S1AP: Downlink NAS transportメッセージを用いてCN３からRAN２に送信されてもよい。そして、RAN２は、当該Attach Acceptメッセージを、RRC: DL Information Transferメッセージを用いてSRB 1上でUE１に送信する。

UE１は、Attach AcceptメッセージをCN３からRAN２を介して受信する。Attach Acceptメッセージは、転送データタイプ（e.g., IP、non-IP、SMS）及びUEアドレス（e.g.,IPアドレス）を示してもよい。UE１は、Attach Acceptメッセージの受信に応答して、NAS: アタッチ完了（Attach Complete）メッセージをCN３に送信する。当該Attach Completeメッセージは、RRC: UL Information Transferメッセージを用いてSRB 1上でRAN２に送信される。RAN２は、受信したAttach CompleteメッセージをS1AP: Uplink NAS transportメッセージを用いてCN３にフォワードする。

ステップ３０８では、RAN２は、RRCコネクション解放（RRC Connection Release）メッセージをSRB 1上でUE１に送信する。CN３は、S1AP: S1 UE Context Release CommandメッセージをRAN２に送信することによって、UE１とのRRCコネクションの解放をRAN２に要求してもよい。RRCコネクション解放（RRC Connection Release）メッセージを受信したことに応答して、UE１は、RRC-ConnectedモードからRRC-Idleモードに遷移する。なお、CIoTデバイスとしてのUE１のために、既存のRRC-idleモードとは異なる他の休止モード又は状態が定義されてもよい。したがって、UE１は、RRCコネクション解放（RRC Connection Release）メッセージを受信したことに応答して、RRC-Idleモード又は他の休止モードに遷移してもよい。当該他の休止モード又は状態は、RRCコネクションに関する情報（e.g., Access Stratum Security Context, bearer related information, L2/1 parameters）を保持しておくために、第２の通信アーキテクチャ・タイプにおいて使用されてもよい。

ステップ３０７のAttach Acceptメッセージ、ステップ３０８のRRC Connection Releaseメッセージ、又はその他のCN３からUE１へのダウンリンクNASメッセージは、UE１のために使用される通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を明示的に又は暗示的に示してもよい。

ステップ３０９では、UE１は、アタッチ手順において設定された通信アーキテクチャ・タイプを記憶（格納）する。

図３に示された手順は、例えば以下のように変更されてもよい。UE１は、RRC Connection Requestメッセージ（ステップ３０３）において、通常の確立要因と共に、別の情報要素で通信アーキテクチャ・タイプを示してもよい。当該別の情報要素は、例えば、第１及び第２の通信アーキテクチャ・タイプのどちらを選択したかを示す情報要素（e.g., Selected Architecture Type, Applied Architecture Type）でもよい。例えばUE１は、第１の通信アーキテクチャ・タイプを示す場合に当該情報要素の値をDataOverNAS（DONAS）またはType 1に設定し、第２の通信アーキテクチャ・タイプを示す場合に当該情報要素の値を RRC-SuspendまたはType 2に設定してもよい。

例えば、当該別の情報要素は、SelectedArcType ENUMERATED {type1, type2}（又は、｛dataOverNAS, rrc-Suspend｝）のように規定されてもよい。これに代えて、当該別の情報要素は、第１の通信アーキテクチャ・タイプを選択したことを示すフラグ情報（e.g., SelectedArcType ENUMERATED {type1}, ArcType1 ENUMERATED {true}）でもよい。さらに、これに代えて、当該別の情報要素は、第２の通信アーキテクチャ・タイプを選択したことを示すフラグ情報（e.g., SelectedArcType ENUMERATED {type2}, ArcType2 ENUMERATED {true}）でもよい。

２つの通信アーキテクチャ・タイプのうち一方（e.g., 第２の通信アーキテクチャ・タイプ）が選択されたことを示すフラグ情報を送信する方法がUE１に実装される場合、UE１が他方の通信アーキテクチャ・タイプ（e.g., 第１の通信アーキテクチャ・タイプ）を使用することがデフォルト（基本設定）として規定されてもよい。したがって、UE１が当該フラグ情報を送信しない場合、UE１はデフォルトの通信アーキテクチャ・タイプを選択したものとみなすことができる。つまり、RAN２は、当該フラグ情報を受信しなかった場合、UE１がデフォルトの通信アーキテクチャ・タイプを選択したと認識する。

図３に示された手順は、例えばさらに以下のように変更されてもよい。RAN２は、UE１によりRRC Connection Requestメッセージ（ステップ３０３）に示された通信アーキテクチャ・タイプとは異なる他の通信アーキテクチャ・タイプをUE１のために使用してもよい。この場合、RAN２は、RRC Connection Setupメッセージ（ステップ３０４）を用いて、当該他の通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）をUE１に通知してもよい。あるいは、RAN２は、ステップ３０４において代わりにRRC Connecion RejectメッセージをUE１に送信し、当該メッセージで他の通信アーキテクチャ・タイプをUE１に通知してもよい。当該他の通信アーキテクチャ・タイプの通知の受信に応答して、UE１は、現在のアタッチ手順を終了して、新たなRRCコネクション・セットアップ手順（RRC Connection Setup procedure）からリスタートしてもよい。これに代えて、UE１は、RAN２からの他の通信アーキテクチャ・タイプの通知に従って、現在のアタッチ手順及びRRCコネクション・セットアップ手順を継続してもよい。

ユーザプレーン（e.g., DRB及びGPRS Tunneling Protocol（GTP）トンネルを包含するEPSベアラ）を介してユーザデータパケットが送信される第２の通信アーキテクチャ・タイプがUE１のために使用される場合、CN３は、ステップ３０７において、NAS: Attach AcceptメッセージをS1AP: Initial Context Setup Requestメッセージに含めてRAN２に送信してもよい。当該S1AP: Initial Context Setup Requestメッセージは、UE１のために使用されるセキュリティキー（K_eNB）及びUE Security Algorithmを含む。RAN２は、受信したセキュリティキー（K_eNB）及びUE Security Algorithmに従って、ASセキュリティセットアップを実行してもよい。ASセキュリティセットアップは、NAS: Attach AcceptメッセージをUE１に送信する前に行われてもよいし、送信した後に行われてもよい。

図３はMobile Originated（MO）データ送信を示しているが、図３と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

図３の例によれば、UE１は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定し、決定された通信アーキテクチャ・タイプを示す確立要因（establishment cause）又は他の情報要素を含むRRC Connection RequestメッセージをRAN２に送信する。UE１によって決定された通信アーキテクチャ・タイプを示すためにRRC Connection Requestメッセージ内の確立要因又は他の情報要素を使用することは、例えば以下の利点をもたらす。第１に、UE１は、UE１によって決定された通信アーキテクチャ・タイプをNAS情報ではなくAS（RRC）情報として送信することができる。したがって、RAN２は、UE１が希望する通信アーキテクチャ・タイプを認識することができ、RAN２は、UE１が希望する通信アーキテクチャ・タイプに応じた処理（e.g., CN（DCN）の選択）を行うことができる。第２に、UE１は、UE１によって決定された通信アーキテクチャ・タイプをRRCコネクションの設定前にRAN２に知らせることができる。したがって、RAN２は、UE１により決定された通信アーキテクチャに依存したRRCコネクションをセットアップするために必要なシグナリングメッセージ数を削減できる。

＜第２の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図４は、本実施形態に係る通信手順の一例を示すシーケンス図である。図４の手順では、UE１のCN３へのアタッチ手順の間に、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプが決定される。UE１は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定し、決定された通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関する情報要素を含むRRC Connection Setup CompleteメッセージをRAN２に送信する。

ステップ４０１〜４０４は、図３に示されたステップ３０１〜３０４と同様である。ただし、ステップ４０３のRRC Connection Requestメッセージは、UE１によって決定（選択）された通信アーキテクチャ・タイプを示さない。

ステップ４０５では、UE１は、RRCコネクション・セットアップ完了（RRC Connection Setup Complete）メッセージをRAN２に送信する。当該RRC Connection Setup Completeメッセージは、DCCH上のSRB 1を用いて送信される。当該RRC Connection Setup Completeメッセージは、UE１によって決定された通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関するUEアシスタンス IE（情報要素）と、イニシャルNASメッセージとを含む。UEアシスタンス IEは、NAS情報であってもよいし、AS（RRC）情報であってもよい。

UEアシスタンス IEがAS（RRC）情報である場合、RAN２は、UE１により決定された通信アーキテクチャ・タイプに応じて、SRB 1のためのPDCP設定（pdcp-Config）をUE１に送信してもよいし、PDCPレイヤを使用（適用）することをUE１に通知してもよい。具体的には、RAN２は、UE１が第２の通信アーキテクチャ・タイプを選択した場合、SRB 1のためのPDCP設定をUE１に送信してもよい。

RAN２は、UE１からRRC Connection Setup Completeメッセージを受信し、RRC Connection Setup Completeメッセージから取り出されたイニシャルNASメッセージ（i.e., Attach Requestメッセージ）をCN３（e.g., MME、C-SGN）にイニシャルUEメッセージを用いて送信する。UEアシスタンス IEがAS（RRC）情報である場合、RAN２は、UE１により決定された通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、イニシャルNASメッセージ（i.e., Attach Requestメッセージ）を運ぶInitial UEメッセージを選択されたDCNに送信してもよい。これに対して、UEアシスタンス IEがNAS情報である場合、UEアシスタンス IEはイニシャルNASメッセージと共にS1AP: Initial UEメッセージのNAS-PDU IE（情報要素）に埋め込まれる。この場合、RAN２は、UE１により決定された通信アーキテクチャ・タイプを明示的又は暗示的に示す通知を、例えばInitial Context Setup Requestメッセージ（e.g., Architecture Type IE）で、CN３から受信してもよい。

ステップ４０６〜４０９は、図３のステップ３０６〜３０９と同様である。

図４に示された手順は、例えば以下のように変更されてもよい。RAN２又はCN３は、UE１によりRRC Connection Setup Completeメッセージ又はAttach Requestメッセージ（ステップ４０４）に示された通信アーキテクチャ・タイプとは異なる他の通信アーキテクチャ・タイプをUE１のために使用してもよい。

RAN２は、RRC Connection Setup Completeメッセージ（ステップ４０４）に応答して、他の通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を示すRRC Connection RejectメッセージをUE１に送信してもよい。この場合、UE１は、新たなRRCコネクション・セットアップ手順をリスタートしてもよい。

これに代えて、CN３は、Attach Acceptメッセージ（ステップ４０７）を用いて、他の通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）をUE１に通知してもよい。この場合、UE１は、現在のアタッチ手順を終了して、新たなRRCコネクション・セットアップ手順からリスタートしてもよい。これに代えて、UE１は、RAN２からの他の通信アーキテクチャ・タイプの通知に従って、現在のアタッチ手順を継続してもよい。

ユーザプレーン（e.g., DRB及びGPRS Tunneling Protocol（GTP）トンネルを包含するEPSベアラ）を介してユーザデータパケットが送信される第２の通信アーキテクチャ・タイプがUE１のために使用される場合、CN３は、ステップ４０７において、NAS: Attach AcceptメッセージをS1AP: Initial Context Setup Requestメッセージに含めてRAN２に送信してもよい。当該S1AP: Initial Context Setup Requestメッセージは、UE１のために使用されるセキュリティキー（K_eNB）及びUE Security Algorithmを含む。RAN２は、受信したセキュリティキー（K_eNB）及びUE Security Algorithmに従って、ASセキュリティセットアップを実行してもよい。ASセキュリティセットアップは、NAS: Attach AcceptメッセージをUE１に送信する前に行われてもよいし、送信した後に行われてもよい。

図４はMobile Originated（MO）データ送信を示しているが、図４と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

図４の例によれば、UE１は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定し、決定された通信アーキテクチャ・タイプを示すUEアシスタンスIEを含むRRC Connection Setup CompleteメッセージをRAN２に送信する。UE１によって決定された通信アーキテクチャ・タイプを示すためにRRC Connection Setup Completeメッセージを使用することは、例えば以下の利点をもたらす。幾つかの実装において、UE１は、UE１によって決定された通信アーキテクチャ・タイプをNAS情報として送信することができる。したがって、UE１は、UE１が希望する通信アーキテクチャ・タイプをCN３に容易に知らせることができる。

＜第３の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図５は、本実施形態に係る通信手順の一例を示すシーケンス図である。図５の手順では、UE１のCN３へのアタッチ手順の間に、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプをRAN２が決定（又は選択）する。

ステップ５０１〜５０４は、図４に示されたステップ４０２〜４０５と同様である。ただし、ステップ５０４のRRC Connection Setup Completeメッセージは、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関する情報要素（e.g., UE Supported Architecture Type）を含む。当該情報要素は、AS（RRC）情報である。したがって、RAN２（e.g., CIoT-BS、eNB）は、当該情報要素に基づいて、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを検出できる。

当該情報要素は、例えばUE１によってサポートされている通信アーキテクチャ・タイプを示してもよい（e.g., {type1, type2, ..}, or {DONAS, RRC-Suspend, ..}）。当該情報要素は、複数の通信アーキテクチャ・タイプのうちどのタイプがUE１によってサポートされているかを示すビットマップであってもよい。当該情報要素は、デフォルトの通信アーキテクチャ・タイプを除いて、１又は複数のオプションの通信アーキテクチャ・タイプがUE１によってサポートされているかを示すフラッグ又はビットマップであってもよい。すなわち、当該情報要素は、オプションの通信アーキテクチャ・タイプがサポートされていることを示してもよいし（e.g., typeX supported）、それがサポートされているか否かを示してもよい（e.g., Support of typeX = ENUMERATED {true,…}, or {Supported, Not Supported}）。なお、上記type1, type2（及びtypeX）は、例えばDataOverNAS (DONAS), RRC-Suspendのようにより具体的に通信アーキテクチャ・タイプを示す名称に置き換えられてもよい。

ステップ５０５では、RAN２は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを考慮し、UE１のために使用される通信アーキテクチャ・タイプを決定する。いくつかの実装において、RAN２は、UE１に予め設定されたデフォルトUE 能力（capability）に基づいて、UE１のために使用する通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、RAN２は、RAN２からの参照信号のUE１による受信電力（RSRP）又はUE１とRAN２（CIoT-BS/eNB）の間の推定される伝搬損失に基づいて、UE１のために使用する通信アーキテクチャ・タイプを選択してもよい。RSRP又は伝搬損失の計測結果は、UE１からRAN２に送られてもよい。さらに又はこれに代えて、RAN２は、CN３のネットワーク能力（capability）に基づいて、UE１のために使用する通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、RAN２は、RAN２の負荷（e.g., Cell load、S1 Transport Network Layer (TNL) load、number of Connected UEs、number of UEs whose UE context stored）に基づいて、UE１のために使用する通信アーキテクチャ・タイプを選択してもよい。

RAN２は、UE１により決定された通信アーキテクチャ・タイプに応じて、SRB 1のためのPDCP設定（pdcp-Config）をUE１に送信してもよいし、PDCPレイヤを使用（適用）することをUE１に通知してもよい。具体的には、RAN２は、UE１のために第２の通信アーキテクチャ・タイプを選択した場合、SRB 1のためのPDCP設定をUE１に送信してもよい。

ステップ５０６では、RAN２は、RRC Connection Setup Completeメッセージから取り出されたイニシャルNASメッセージ（i.e., Attach Requestメッセージ）をCN３（e.g., MME、C-SGN）にS1AP: Initial UEメッセージを用いて送信する。イニシャルNASメッセージ（i.e., Attach Requestメッセージ）は、S1AP: Initial UEメッセージのNAS-PDU IE（情報要素）に埋め込まれる。RAN２は、ステップ５０５において決定した通信アーキテクチャ・タイプを示す情報要素をS1AP: Initial UEメッセージに含めてもよい。RAN２は、ステップ５０５において決定した通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、イニシャルNASメッセージ（i.e., Attach Requestメッセージ）を運ぶS1AP: Initial UEメッセージを選択されたDCNに送信してもよい。

ステップ５０７〜５１０は、図３のステップ３０６〜３０９、又は図４のステップ４０６〜４０９と同様である。

第２の通信アーキテクチャ・タイプがUE１のために使用される場合、図５に示された手順は、上述した他の手順と同様に、ASセキュリティセットアップを行うように変更されてもよい。図５はMobile Originated（MO）データ送信を示しているが、図５と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

＜第４の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図６は、本実施形態に係る通信手順の一例を示すシーケンス図である。図６の手順では、UE１のCN３へのアタッチ手順の間に、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプをRAN２が決定する。なお、図６の手順は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関する情報要素（e.g., UE Supported Architecture Type）がRRC Connection Requestメッセージを用いて送信される点が図５に示された手順と異なる。

ステップ６０１及び６０２は、図３に示されたステップ３０２及び３０３と同様である。ただし、ステップ６０２のRRC Connection Requestメッセージは、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを示す情報要素（e.g., UE Supported Architecture Type）を含む。当該情報要素は、AS（RRC）情報である。したがって、RAN２（e.g., CIoT-BS、eNB）は、当該情報要素に基づいて、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを検出できる。

ステップ６０３では、RAN２は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを考慮し、UE１のために使用される通信アーキテクチャ・タイプを決定する。

ステップ６０４は、図３のステップ３０４と同様である。ただし、ステップ６０４のRRC Connection Setupメッセージは、ステップ６０３においてRAN２により決定された通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を示してもよい。

ステップ６０５及び６０６は、図３のステップ３０５と同様である。ただし、RAN２は、ステップ６０３において決定された通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を示す情報要素をS1AP: Initial UEメッセージに含めてもよい。RAN２は、ステップ６０３において決定された通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、イニシャルNASメッセージ（i.e., Attach Requestメッセージ）を運ぶS1AP: Initial UEメッセージを選択されたDCNに送信してもよい。

ステップ６０７〜６１０は、図３のステップ３０６〜３０９、又は図５のステップ５０７〜５１０と同様である。

第２の通信アーキテクチャ・タイプがUE１のために使用される場合、図６に示された手順は、上述した他の手順と同様に、ASセキュリティセットアップを行うように変更されてもよい。図６はMobile Originated（MO）データ送信を示しているが、図６と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

＜第５の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図７は、本実施形態に係る通信手順の一例を示すシーケンス図である。図７の手順では、UE１のCN３へのアタッチ手順の間に、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプをRAN２が決定する。なお、図７の手順は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関する情報要素（e.g., UE Supported Architecture Type）がイニシャルNASメッセージ（i.e., Attach Requestメッセージ）と共にNAS情報として送信される点が図５及び図６に示された手順と異なる。

ステップ７０１〜７０４は、図４に示されたステップ４０２〜４０５と同様である。ただし、ステップ７０４では、UE１は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを示すNAS情報要素（e.g., UE Supported Architecture Type）をAttach Requestメッセージと共に送信する。当該NAS情報要素は、例えばUE１によってサポートされている通信アーキテクチャ・タイプを示してもよい（e.g., {type1, type2, ..}, or {DONAS, RRC-Suspend, ..}）。これに代えて、当該NAS情報要素は、オプションの通信アーキテクチャ・タイプがサポートされていることを示してもよいし（e.g., typeX supported）、それがサポートされているか否かを示してもよい（e.g., Support of typeX = ENUMERATED {true,…}, or {Supported, Not Supported}）。なお、上記type1, type2（及びtypeX）は、例えばDataOverNAS (DONAS), RRC-Suspendのようにより具体的に通信アーキテクチャ・タイプを示す名称に置き換えられてもよい。

ステップ７０５では、CN３は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプ（e.g., UE Supported Architecture Type）を示すS1AP: Initial Context Setup RequestメッセージをRAN２に送信する。ステップ７０６では、RAN２は、CN３から受信した情報に基づいてUE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを考慮し、UE１のために使用される通信アーキテクチャ・タイプを決定する。RAN２は、決定した通信アーキテクチャ・タイプをCN３にS1AP: Initial Context Setup Responseメッセージを用いて通知してもよい（ステップ７０７）。

ステップ７０８〜７１１は、図３のステップ３０６〜３０９、図５のステップ５０７〜５１０、又は図６のステップ６０７〜６１０と同様である。

第２の通信アーキテクチャ・タイプがUE１のために使用される場合、図７に示された手順は、上述した他の手順と同様に、ASセキュリティセットアップを行うように変更されてもよい。図７はMobile Originated（MO）データ送信を示しているが、図７と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

＜第６の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図８は、本実施形態に係る通信手順の一例を示すシーケンス図である。図８の手順では、UE１のCN３へのアタッチ手順の間に、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプをRAN２が決定する。なお、図８の手順は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関する情報要素（e.g., UE Supported Architecture Type）がHSS５からCN３（e.g., MME、C-SGN）を介してRAN２に送られる点が図５〜図７に示された手順と異なる。

ステップ８０１〜８０４は、図７に示されたステップ７０１〜７０４と同様である。ただし、ステップ８０４では、UE１は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを示すNAS情報要素（e.g., UE Supported Architecture Type）を送信する必要がない。

ステップ８０５では、CN３（e.g., MME、C-SGN）は、認証(Authentication)及びセキュリティ手順を実行し、NASセキュリティをセットアップする。ステップ８０６では、CN３（e.g., MME、C-SGN）は、UE１の認証情報（Authentication Information）をHSS５から受信する際に、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプ（e.g., UE Supported Architecture Type）をHSS５から受信する。HSS５は、UE１の加入者情報としてUE Supported Architecture Typeを管理する。

ステップ８０７〜８０９は、図７のステップ７０５〜７０７と同様である。ステップ８１０〜８１２は、図３のステップ３０７〜３０９、図５のステップ５０８〜５１０、図６のステップ６０８〜６１１、又は図７のステップ７０９〜７１１と同様である。

第２の通信アーキテクチャ・タイプがUE１のために使用される場合、図８に示された手順は、上述した他の手順と同様に、ASセキュリティセットアップを行うように変更されてもよい。図８はMobile Originated（MO）データ送信を示しているが、図８と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

＜第７の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図９は、本実施形態に係る通信手順の一例を示すシーケンス図である。図９の手順では、UE１のCN３へのアタッチ手順の間に、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプをCN３が決定する。

ステップ９０１〜９０４は、図７のステップ７０１〜７０４と同様である。すなわち、ステップ９０４では、CN３（e.g., MME、C-SGN）は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関するNAS情報要素（e.g., UE Supported Architecture Type）をAttach Requestメッセージと共にUE１から受信する。

ステップ９０５では、CN３は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプ（UE Supported Architecture Type）を考慮し、UE１のために使用される通信アーキテクチャ・タイプを決定する。いくつかの実装において、CN３は、UE１に予め設定されたデフォルトUE 能力（capability）に基づいて、UE１のために使用する通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、CN３は、RAN２（e.g., CIoT BS、eNB）のネットワーク能力（capability）に基づいて、UE１のために使用する通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、CN３は、CN３の負荷（e.g., S1 Transport Network Layer (TNL) load、number of Connected UEs、number of UEs whose UE context stored）に基づいて、UE１のために使用する通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、CN３は、UE１に適用されるQuality of Service（QoS）（e.g., QoS Class Identifier（QCI）、Allocation and Retention Priority（ARP）、リソースタイプ（Guaranteed Bit Rate（GBR）又はnon-GBR））に基づいて、UE１のために使用する通信アーキテクチャ・タイプを選択してもよい。

ステップ９０６では、CN３は、ステップ９０５において決定した通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を示すS1AP: Initial Context Setup RequestメッセージをRAN２に送信する。RAN２は、ステップ９０６の通知に対する応答を送信してもよい（ステップ９０７）。

ステップ９０８〜９１１は、図３のステップ３０６〜３０９、図４のステップ４０６〜４０９、図５のステップ５０７〜５１０、図６のステップ６０７〜６１０、又は図７のステップ７０８〜７１１と同様である。

第２の通信アーキテクチャ・タイプがUE１のために使用される場合、図９に示された手順は、上述した他の手順と同様に、ASセキュリティセットアップを行うように変更されてもよい。図９はMobile Originated（MO）データ送信を示しているが、図９と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

＜第８の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図１０は、本実施形態に係る通信手順の一例を示すシーケンス図である。図１０の手順では、UE１のCN３へのアタッチ手順の間に、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプをCN３が決定する。なお、図１０の手順は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関する情報要素（e.g., UE Supported Architecture Type）がHSS５からCN３（e.g., MME、C-SGN）に送られる点が図９に示された手順と異なる。

ステップ１００１〜１００６は、図８のステップ８０１〜８０６と同様である。ステップ１００７〜１００９は、図９のステップ９０５〜９０７と同様である。ステップ１０１０〜１０１２は、図３のステップ３０７〜３０９、図４のステップ４０７〜４０９、図５のステップ５０８〜５１０、図６のステップ６０８〜６１０、図７のステップ７０９〜７１１、図８のステップ８１０〜８１２、又は図９のステップ９０９〜９１１と同様である。

第２の通信アーキテクチャ・タイプがUE１のために使用される場合、図１０に示された手順は、上述した他の手順と同様に、ASセキュリティセットアップを行うように変更されてもよい。図１０はMobile Originated（MO）データ送信を示しているが、図１０と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

＜第９の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図１１及び図１２は、本実施形態に係る通信手順の一例を示すシーケンス図である。図１１及び図１２の手順では、アタッチ完了後にUE１がデータパケット送信のためにRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードに遷移する際のRRCコネクション・セットアップ手順の間に、UE１がUE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定（又は選択）する。

図１１は、UE１のために第１の通信アーキテクチャ・タイプが使用されるケースを示している。既に説明したように、第１の通信アーキテクチャ・タイプでは、UE１によって送信又は受信されるユーザデータパケットがコントロールプレーン（e.g., UEとMME/C-SGNの間のNASメッセージ）を介して送信される。一方、図１２は、UE１のために第２の通信アーキテクチャ・タイプが使用されるケースを示している。第２の通信アーキテクチャ・タイプでは、UE１によって送信又は受信されるユーザデータパケットがユーザプレーン（e.g., DRB及びGPRS Tunneling Protocol（GTP）トンネルを包含するEPSベアラ）を介して送信される。

図１１について説明する。ステップ１１０１では、UE１は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定（選択）する。通信アーキテクチャ・タイプを決定するために考慮されるパラメータは、図３のステップ３０１と同様であってもよい。なお、図１１の例では、UE１は、データパケットの送信機会毎に通信アーキテクチャ・タイプを決定（選択）できる。したがって、UE１は、データパケットの送信機会毎に動的に変化するパラメータを考慮してもよい。例えば、UE１は、データ送信トリガー（e.g., mo-Data、mo-ExceptionData、mt-Access、mo-Signaling）に応じて通信アーキテクチャ・タイプを選択してもよい。さらに又はこれに代えて、UE１は、データパケット送信を行うアプリケーションの種別に応じて通信アーキテクチャ・タイプを選択してもよい。

ステップ１１０２〜１１０６は、図３のステップ３０２〜３０５と同様である。ただし、図１１の例は、アタッチ完了後のRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードへの遷移を示している。さらに、図１１の例では、ステップ１１０１において、UE１は、第１の通信アーキテクチャ・タイプを選択する。したがって、ステップ１１０５においてUE１によって送信されるイニシャルNASメッセージは、スモールデータを運ぶNASメッセージである。すなわち、UE１は、スモールデータをイニシャルNASメッセージ上にピギーバックする。

ステップ１１０６では、RAN２は、RRC Connection Setup Completeメッセージから取り出されたイニシャルNASメッセージ（i.e., スモールデータを運ぶNASメッセージ）をCN３（e.g., MME、C-SGN）にS1AP: Initial UEメッセージを用いて送信する。イニシャルNASメッセージ（i.e., スモールデータを運ぶNASメッセージ）は、S1AP: Initial UEメッセージのNAS-PDU IE（情報要素）に埋め込まれる。RAN２は、UE１により決定された第１の通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素をS1AP: Initial UEメッセージに含めてもよい。RAN２は、UE１により決定された第１の通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、S1AP: Initial UEメッセージを選択されたDCNに送信してもよい。

ステップ１１０７では、CN３（e.g., MME、C-SGN）は、スモールデータパケットを得るために、UE１からのアップリンクNASメッセージを復号化（decrypt）する。ステップ１１０８では、CN３は、スモールデータパケットのデータタイプに依存して、スモールデータパケットをフォワードする。Mobile Originated スモールパケットに対するACK又は応答が期待される場合、CN３は、到着した応答ダウンリンク・データパケットを受信する（ステップ１１０９）。ステップ１１１０では、CN３は、ダウンリンク・データパケットを暗号化し、暗号化されたダウンリン・データパケットを運ぶダウンリンクNASメッセージを生成する。ステップ１１１１では、S1AP: DL NAS TransportメッセージをRAN２に送信する。ステップ１１１２では、RAN２は、RRC: DL Information TransferメッセージをUE１にSRB 1において送信する。当該DL Information Transferメッセージは、UE１宛ての暗号化されたダウンリン・データパケットを運ぶダウンリンクNASメッセージを含む。

続いて図１２について説明する。図１２のステップ１２０１は、図１１のステップ１１０１と同様である。ただし、図１２の例では、UE１は、UE１のデータパケット送信のために第２の通信アーキテクチャ・タイプを選択する。

ステップ１２０２〜１２０６は、図１１のステップ１１０２〜１１０６と同様である。ただし、図１２の例では第２の通信アーキテクチャ・タイプが使用されるため、ステップ１２０５においてUE１によって送信されるイニシャルNASメッセージは、サービス要求（Service Request）メッセージである。

ステップ１２０６では、RAN２は、RRC Connection Setup Completeメッセージから取り出されたイニシャルNASメッセージ（i.e., Service Requestメッセージ）をCN３（e.g., MME、C-SGN）にS1AP: Initial UEメッセージを用いて送信する。イニシャルNASメッセージ（i.e., Service Requestメッセージ）は、S1AP: Initial UEメッセージのNAS-PDU IE（情報要素）に埋め込まれる。RAN２は、UE１により決定された第２の通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素をS1AP: Initial UEメッセージに含めてもよい。RAN２は、UE１により決定された第２の通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、S1AP: Initial UEメッセージを選択されたDCNに送信してもよい。

ステップ１２０７〜１２１１は、既存のサービス要求手順におけるEPSベアラの確立手順と同様である。ステップ１２１２及び１２１３では、UE１は、アップリンクベアラ上でS-GW６及びRAN２を介してアップリンク・データを送信し、ダウンリンクベアラ上でS-GW６及びRAN２を介してダンリンク・データを受信する。

ステップ１２１４では、UE１、RAN２、及びCN３は、RRCコネクションの一時中止（suspension）を行う。UE１は、RRC-ConnectedからRRC-Idleモード（又は他の休止モード）に遷移し、RRC-Idleモード（又は他の休止モード）においてRRCコネクションに関する情報、e.g., Access Stratum Security Context, bearer related information (incl. RoHC state information) and L2/1 parameters when applicableを保持（retain）する。同様に、RAN２も、UE１のRRCコネクションに関する情報、e.g., Access Stratum Security Context, bearer related information (incl. RoHC state information) and L2/1 parameters when applicableを保持する。さらに、RAN２及びCN３は、S1AP UE Contextsを保持する。さらにまた、RAN２は、S1-U tunnel addressesを保持する。これにより、UE１、RAN２、及びCN３は、以前の（previous）RRCコネクションからの情報を後の（subsequent）のRRCコネクション・セットアップのために再利用することができる。

図１１及び図１２はMobile Originated（MO）データ送信を示しているが、図１１及び図１２と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

図１２の手順は、以下のように変更されてもよい。いくつかの実装において、ステップ１２０６のS1AP: Initial UEメッセージは、第２の通信アーキテクチャ・タイプで使用されるダウンリンク・トンネル・エンドポイント識別子を示してもよい。ダウンリンク・トンネル・エンドポイント識別子は、第２の通信アーキテクチャ・タイプにおいてUE１のデータパケット送信のために使用されるRAN２とCN３との間のベアラのRAN２側のトンネル・エンドポイントを特定する。ダウンリンク・トンネル・エンドポイント識別子は、S1ベアラ（GTPトンネル）のS1 eNB TEID（S1 TEID (DL)）であってもよい。さらに、ステップ１２０６のS1AP: Initial UEメッセージは、第２の通信アーキテクチャ・タイプにおいてUE１のデータパケット送信のために使用されるRAN２のアドレス（e.g., eNB address）を示してもよい。これにより、通常のEPSベアラ確立手順において必要な、MMEからS-GWへのModify Bearer Requestメッセージ、及びS-GWからMMEへのModify Bearer Responseメッセージの送信を省略できる。さらに又はこれに代えて、通常のEPSベアラ確立手順において必要なeNBからMMEへのInitial Context Setup Responseメッセージの送信を省略できる。CIoTでは、RAN２及びCN３は、多数のCIoTデバイスとの通信を行える能力が必要とされる。これらのシグナリングメッセージの送信を無くすことで、CIoTのためのRAN２及びCN３の負荷の低減に寄与できる。

図１１及び図１２の例によれば、UE１は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定し、決定された通信アーキテクチャ・タイプを示す確立要因（establishment cause）を含むRRC Connection RequestメッセージをRAN２に送信する。したがって、図１１及び図１２の例は、図３の例と同様の利点をもたらすことができる。さらに、図１１及び図１２の例は、アタッチ完了後にUE１がデータパケット送信のためにRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードに遷移する際のRRCコネクション・セットアップ手順の間に、UE１がUE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定することを可能にできる。

＜第１０の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図１３及び図１４は、本実施形態に係る通信手順の一例を示すシーケンス図である。図１３及び図１４の手順では、アタッチ完了後にUE１がデータパケット送信のためにRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードに遷移する際のRRCコネクション・セットアップ手順の間に、UE１がUE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定する。図１３は、UE１のために第１の通信アーキテクチャ・タイプが使用されるケースを示している。一方、図１４は、UE１のために第２の通信アーキテクチャ・タイプが使用されるケースを示している。なお、図１３及び図１４の手順は、UE１によって決定された通信アーキテクチャ・タイプがRRC Connection Setup Completeメッセージを用いてRAN２に送られる点が図１１及び図１２の手順と異なる。

図１３について説明する。ステップ１３０１〜１３１２は、図１１のステップ１１０１〜１１１２と同様である。ただし、図１３の手順では、図４の手順と同様に、UE１は、UE１によって決定された第１の通信アーキテクチャ・タイプを明示的又は暗示的に示すUEアシスタンス IE（情報要素）をRRC Connection Setup Completeメッセージ（ステップ１３０５）を用いてRAN２に送信する。

続いて図１４について説明する。ステップ１４０１〜１４１４は、図１２のステップ１２０１〜１２１４と同様である。ただし、図１４の手順では、図４の手順と同様に、UE１は、UE１によって決定された第２の通信アーキテクチャ・タイプを明示的又は暗示的に示すUEアシスタンス IE（情報要素）をRRC Connection Setup Completeメッセージ（ステップ１４０５）を用いてRAN２に送信する。

図１３及び図１４はMobile Originated（MO）データ送信を示しているが、図１３及び図１４と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

図１３及び図１４の例によれば、UE１は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定し、決定された通信アーキテクチャ・タイプを示すUEアシスタンスIEを含むRRC Connection Setup CompleteメッセージをRAN２に送信する。したがって、図１３及び図１４の例は、図４の例と同様の利点をもたらすことができる。さらに、図１３及び図１４の例は、アタッチ完了後にUE１がデータパケット送信のためにRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードに遷移する際のRRCコネクション・セットアップ手順の間に、UE１がUE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定することを可能にできる。

＜第１１の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態では、UE１のために使用される通信アーキテクチャの決定（又は選択）を伴う他の通信手順が説明される。図１５及び図１６は、本実施形態に係る通信手順の一例を示すシーケンス図である。図１５及び図１６の手順では、アタッチ完了後にUE１がデータパケット送信のためにRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードに遷移する際のRRCコネクション・セットアップ手順の間に、RAN２がUE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定する。図１５は、UE１のために第１の通信アーキテクチャ・タイプが使用されるケースを示している。一方、図１６は、UE１のために第２の通信アーキテクチャ・タイプが使用されるケースを示している。なお、図１５及び図１６の手順は、RAN２が通信アーキテクチャ・タイプの決定を行う点が図１１及び図１２に示された手順と異なる。

図１５について説明する。ステップ１５０１〜１５０５は、図６のステップ６０１〜６０５と同様である。ただし、図１５の例は、アタッチ完了後のRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードへの遷移を示している。さらに、図１５の例では、ステップ１５０３において、RAN２は、UE１のために第１の通信アーキテクチャ・タイプを選択する。したがって、ステップ１５０５においてUE１によって送信されるイニシャルNASメッセージは、スモールデータを運ぶNASメッセージである。すなわち、UE１は、スモールデータをイニシャルNASメッセージ上にピギーバックする。なお、ステップ１５０４のRRC Connection Setupメッセージは、ステップ１５０３においてRAN２により決定された第１の通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を明示的に又は暗示的に示してもよい。

ここで、RAN２が明示的に通信アーキテクチャ・タイプを示す場合、RAN２は、当該通信アーキテクチャ・タイプを示すAS レイヤ（e.g., RRCレイヤ）の情報要素、又はNASレイヤの情報要素をRRC Connection Setupメッセージに入れてUE１に送信してもよい。通信アーキテクチャ・タイプを示すNAS情報要素が送信される場合、UE１のNASレイヤは、使用すべき通信アーキテクチャ・タイプを示す情報をUE１のASレイヤに送信してもよいし、当該通信アーキテクチャ・タイプに従ってデータ送信を開始してもよい。一方、RAN２が暗示的に通信アーキテクチャ・タイプを示す場合、RAN２は、選択された通信アーキテクチャ・タイプに関する設定情報をRRC Connection Setupメッセージを含めることによって、当該選択された通信アーキテクチャ・タイプをUE１に通知してもよい。

ステップ１５０６では、RAN２は、RRC Connection Setup Completeメッセージから取り出されたイニシャルNASメッセージ（i.e., スモールデータを運ぶNASメッセージ）をCN３（e.g., MME、C-SGN）にS1AP: Initial UEメッセージを用いて送信する。イニシャルNASメッセージ（i.e., スモールデータを運ぶNASメッセージ）は、S1AP: Initial UEメッセージのNAS-PDU IE（情報要素）に埋め込まれる。RAN２は、ステップ１５０３において決定された通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を示す情報要素をS1AP: Initial UEメッセージに含めてもよい。RAN２は、ステップ１５０３において決定された通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、イニシャルNASメッセージ（i.e., Attach Requestメッセージ）を運ぶS1AP: Initial UEメッセージを選択されたDCNに送信してもよい。

ステップ１５０７〜１５１２は、図１１のステップ１１０７〜１１１２、又は図１３のステップ１３０７〜１３１２と同様である。

続いて図１６について説明する。ステップ１６０１〜１６０６は、図１５のステップ１５０１〜１５０５と同様である。ただし、ステップ１６０３では、RAN２は、UE１のために第２の通信アーキテクチャ・タイプを選択する。したがって、ステップ１６０５においてUE１によって送信されるイニシャルNASメッセージは、サービス要求（Service Request）メッセージである。なお、ステップ１６０４のRRC Connection Setupメッセージは、ステップ１６０３においてRAN２により決定された第２の通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を明示的に又は暗示的に示してもよい。

ステップ１６０６〜１６１４は、図１２のステップ１２０６〜１２１４、又は図１４のステップ１４０６〜１４１４と同様である。

図１５及び図１６はMobile Originated（MO）データ送信を示しているが、図１５及び図１６と同様の手順は、Mobile Terminated（MT）データ送信に適用されてもよい。

図１５及び図１６の例は、アタッチ完了後にUE１がデータパケット送信のためにRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードに遷移する際のRRCコネクション・セットアップ手順の間に、RAN２がUE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定することを可能にできる。

＜第１２の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。ただし、CN３は、複数の（個別）コアネットワークを含む。RAN２は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定するとともに、決定された通信アーキテクチャ・タイプに対応する（個別）コアネットワークをCN３内の複数の（個別）コアネットワークの中から選択するよう構成されている。さらに、RAN２は、イニシャルNon-Access Stratum（NAS）メッセージを、選択されたコアネットワークに送信するよう構成されている。

図１７は、本実施形態に係る通信手順の一例を示すシーケンス図である。図１７の例では、CN３は、第１の通信アーキテクチャ・タイプに対応する第１の（個別）コアネットワーク（(D)CN-1 ３Ａ）、及び第２の通信アーキテクチャ・タイプに対応する第２の（個別）コアネットワーク（(D)CN-2 ３Ｂ）を含む。

ステップ１７０１は、図５のステップ５０４と同様である。すなわち、UE１は、初期アタッチのためのRRCコネクション・セットアップ手順において、RRC Connection Setup Completeメッセージを送信する。ステップ１７０１のRRC Connection Setup Completeメッセージは、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素（e.g., UE Supported Architecture Type）を含む。当該情報要素は、AS（RRC）情報である。

ステップ１７０２では、図５のステップ５０５と同様に、RAN２は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを考慮し、UE１のために使用される通信アーキテクチャ・タイプを決定する。さらに、RAN２は、決定された通信アーキテクチャ・タイプに対応する（個別）コアネットワークをCN３内の複数の（個別）コアネットワークの中から選択する。すなわち、RAN２は、UE１のために第１の通信アーキテクチャ・タイプを選択した場合にCN-1 ３Ａを選択し、CN-1 ３ＡにS1AP: Initial UEメッセージを送信する（ステップ１７０３）。RAN２は、UE１のために第２の通信アーキテクチャ・タイプを選択した場合にCN-2 ３Ｂを選択し、CN-2 ３ＢにInitial UEメッセージを送信する（ステップ１７０４）。当該Initial UEメッセージは、RAN２によって選択された通信アーキテクチャ・タイプ（e.g., Applied Architecture Type、Selected Architecture Type）を示してもよい。

ステップ１７０５〜１７０８は、図５のステップ５０７〜５１０と同様である。ステップ１７０６のAttach Acceptメッセージ、ステップ１７０７のRRC Connection Releaseメッセージ、又はその他のCN３（i.e., CN-1 ３Ａ又はCN-2 ３Ｂ）からUE１へのダウンリンクNASメッセージは、UE１のために使用される通信アーキテクチャ・タイプを明示的に又は暗示的に示してもよい。

なお、図１７に示された手順に従ってアタッチを完了した後にUE１がデータ送信を行う場合、UE１は、RRC Connection Setup Completeメッセージ内のRegistered MME IE（情報要素）を用いて、UE１が登録されている（個別）CNの情報、つまりMME又はC-SGNの情報、を示してもよい。RAN２は、UE１に適用する通信アーキテクチャ・タイプの選択及び（個別）CNの選択のために、RRC Connection Setup Completeメッセージ内のRegistered MME IEを参照してもよい。すなわち、RAN２は、Registered MME IEがCN-1 ３ＡのNASノード（MME/C-SGN）を示す場合に、第１の通信アーキテクチャ・タイプ及びCN-1 ３ＡをUE１のために選択し、Registered MME IEがCN-2 ３ＢのNASノード（MME/C-SGN）を示す場合に、第２の通信アーキテクチャ・タイプ及びCN-2 ３ＢをUE１のために選択してもよい。なお、Registered MME IEに加えて、又はこれに代えて、Registered C-SGN IE、Registered DCN IE、又はUE Usage Typeが用いられてもよい。

図１７の例によれば、RAN２は、UE１のために使用される通信アーキテクチャ・タイプを決定するとともに、Initial UEメッセージが送信されるべき（個別）コアネットワークを選択する。したがって、RAN２は、UE１のために使用される通信アーキテクチャ・タイプのRAN２での動的な決定に従って、適切な（個別）コアネットワークを選択することができる。

＜第１３の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。ただし、CN３は、複数の（個別）コアネットワークを含む。RAN２は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定するよう構成されている。CN３は、RAN２により決定された通信アーキテクチャ・タイプに対応した適切な（個別）コアネットワークにInitial UEメッセージが送信されるように、Initial UEメッセージのリルーティング（リダイレクション）を行うよう構成されている。

図１８は、本実施形態に係る通信手順の一例を示すシーケンス図である。図１８の例では、CN３は、第１の通信アーキテクチャ・タイプに対応する第１の（個別）コアネットワーク（(D)CN-1 ３Ａ）、及び第２の通信アーキテクチャ・タイプに対応する第２の（個別）コアネットワーク（(D)CN-2 ３Ｂ）を含む。

ステップ１８０１及び１８０５は、図５のステップ５０４及び５０５と同様である。RAN２は、イニシャルNASメッセージを包含するRRC Connection Setup CompleteメッセージをUE１から受信する。そして、RAN２は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプを考慮し、UE１のために使用される通信アーキテクチャ・タイプを決定する。

ステップ１８０３では、RAN２は、予め指定された又は任意に選択された（個別）コアネットワークにS1AP: Initial UEメッセージを送信する。当該Initial UEメッセージは、UE１のために使用される通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素（e.g., Applied Architecture Type、Selected Architecture Type）を含む。図１８の例では、RAN２は、（個別）コアネットワークCN-2 ３ＢにInitial UEメッセージを送信する。なお、予め指定された（個別）コアネットワークは、例えばデフォルトの通信アーキテクチャ・タイプをサポートするものでもよい。

ステップ１８０４では、CN３（ここでは、CN-2 ３Ｂ）内のNASノード（MME/C-SGN）は、RAN２から受信したInitial UEメッセージを受信し、当該メッセージ内の通信アーキテクチャ・タイプを示す情報要素（e.g., Applied Architecture Type、Selected Architecture Type）を参照する。UE１のために使用される通信アーキテクチャ・タイプがCN-2 ３Ｂに対応付けられている場合、CN-2 ３Ｂ内のNASノードは、当該Initial UEメッセージに包含されたAttach Requestメッセージに基づいてアタッチ処理を継続する。これに対して、UE１のために使用される通信アーキテクチャ・タイプが他の（個別）コアネットワーク（ここでは、CN-1 ３Ａ）に対応付けられている場合、CN-2 ３Ｂ内のNASノードは、当該Initial UEメッセージをCN-1 ３ＡにリルートするようRAN２に要求する。具体的には、図１８に示されているように、CN-2 ３Ｂは、S1AP: Reroute NAS Message RequestメッセージをRAN２に送信する。当該Reroute NAS Message Requestメッセージは、Initial UEメッセージが送られるべき（個別）コアネットワークの識別子（e.g., MME Group ID、C-SGN Group ID、DCN Group ID及びAdditional Global Unique Temporary Identity（GUTI））を含む。

ステップ１８０４では、Initial UEメッセージのリルートを決定する際に、CN３は、HSS５から取得したUE１の加入者データ（subscription data）、例えばUE Capability、又はUE Usage Type（e.g., C-IoT, general MTC, delay tolerant MTC）をさらに考慮してもよい。

ステップ１８０５では、RAN２は、S1AP: Reroute NAS Message Requestメッセージを受信したことに応答して、当該Reroute NAS Message Requestメッセージ内で指定された（個別）コアネットワーク（ここでは、CN-1 ３Ａ）に向けてInitial UEメッセージをリルートする。

ステップ１８０６〜１８０９は、図１７のステップ１７０５〜１７０８と同様である。ステップ１８０７のAttach Acceptメッセージ、ステップ１８０８のRRC Connection Releaseメッセージ、又はその他のCN３（i.e., CN-1 ３Ａ又はCN-2 ３Ｂ）からUE１へのダウンリンクNASメッセージは、UE１のために使用される通信アーキテクチャ・タイプを明示的に又は暗示的に示してもよい。

図１８に示された手順に従ってアタッチを完了した後にUE１がデータ送信を行う場合、UE１は、RRC Connection Setup Completeメッセージ内のRegistered MME IE（情報要素）を用いて、UE１が登録されている（個別）CNの情報、つまりMME又はC-SGNの情報、を示してもよい。RAN２は、UE１に適用する通信アーキテクチャ・タイプの選択及び（個別）CNの選択のために、RRC Connection Setup Completeメッセージ内のRegistered MME IEを参照してもよい。すなわち、RAN２は、Registered MME IEがCN-1 ３ＡのNASノード（MME/C-SGN）を示す場合に、第１の通信アーキテクチャ・タイプ及びCN-1 ３ＡをUE１のために選択し、Registered MME IEがCN-2 ３ＢのNASノード（MME/C-SGN）を示す場合に、第２の通信アーキテクチャ・タイプ及びCN-2 ３ＢをUE１のために選択してもよい。

図１８の例によれば、CN３は、RAN２により決定された通信アーキテクチャ・タイプを認識し、RAN２により決定された通信アーキテクチャ・タイプに応じてInitial UEメッセージをリルートする。したがって、CN３は、UE１のために使用される通信アーキテクチャ・タイプのRAN２での動的な決定に応じて、適切な（個別）コアネットワークにおいてInitial UEメッセージを処理することができる。

＜第１４の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。ただし、CN３は、複数の（個別）コアネットワークを含む。CN３は、UE１のデータパケット送信のために使用される通信アーキテクチャ・タイプを決定するとともに、CN３により決定された通信アーキテクチャ・タイプに対応した適切な（個別）コアネットワークにInitial UEメッセージが送信されるように、Initial UEメッセージのリルーティング（リダイレクション）を行うよう構成されている。

図１９は、本実施形態に係る通信手順の一例を示すシーケンス図である。図１９の例では、CN３は、第１の通信アーキテクチャ・タイプに対応する第１の（個別）コアネットワーク（(D)CN-1 ３Ａ）、及び第２の通信アーキテクチャ・タイプに対応する第２の（個別）コアネットワーク（(D)CN-2 ３Ｂ）を含む。なお、図１９の手順は、CN３がUE１のために使用される通信アーキテクチャ・タイプの決定を行う点が図１８に示された手順と異なる。

ステップ１９０１及び１９０２は、図９のステップ９０４と同様である。すなわち、ステップ１９０１では、UE１は、イニシャルNASメッセージ（i.e., Attach Requestメッセージ）と、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプ（UE Supported Architecture Type）とを包含する個別NAS情報（Dedicated NAS Information）を運ぶRRC Connection Setup CompleteメッセージをRAN２に送信する。ステップ１９０２では、RAN２は、RRC Connection Setup Completeメッセージから個別NAS情報を取り出す。そして、RAN２は、取り出された個別NAS情報を包含するNAS-PDUを運ぶS1AP: Initial UEメッセージを、予め指定された又は任意に選択された（個別）コアネットワークに送信する。図１９の例では、RAN２は、（個別）コアネットワークCN-2 ３ＢにInitial UEメッセージを送信する。

ステップ１９０３は、図９のステップ９０５と同様である。すなわち、CN３（ここでは、CN-2 ３Ｂ）内のNASノード（MME/C-SGN）は、UE１によってサポートされている１又は複数の通信アーキテクチャ・タイプ（UE Supported Architecture Type）を考慮し、UE１のために使用される通信アーキテクチャ・タイプを決定する。CN-2 ３Ｂ内のNASノードは、通信アーキテクチャ・タイプの決定において、HSS５から取得したUE１の加入者データ（subscription data）、例えばUE Capability、又はUE Usage Typeをさらに考慮してもよい。

ステップ１９０４〜１９０９は、図１８のステップ１８０４〜１８０９と同様である。ただし、ステップ１９０４のS1AP: Reroute NAS Message Requestメッセージは、CN-2 ３Ｂにより決定（選択）されたUE１のために使用される通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素（e.g., Applied Architecture Type、Selected Architecture Type）を含んでもよい。これにより、RAN２は、UE１のために使用される通信アーキテクチャ・タイプを認識することができる。

図１９の例によれば、CN３は、UE１のための通信アーキテクチャ・タイプを決定すると共に、当該決定された通信アーキテクチャ・タイプに応じてInitial UEメッセージをリルートする。したがって、CN３は、UE１のために使用される通信アーキテクチャ・タイプのCN３での動的な決定に応じて、適切な（個別）コアネットワークにおいてInitial UEメッセージを処理することができる。

＜第１５の実施形態＞
通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素をUE１からRAN２に送信するための方法は、上述の各実施形態で説明された方法、すなわちRRCメッセージ（e.g., RRC Connection Request、RRC Connection Setup Complete）を用いる方法に限定されない。

例えば、UE１は、RRCより下位のレイヤ（i.e., RLC、MAC）のRLC header、MAC header又はMAC Control Element（MAC CE）を用いて、通信アーキテクチャ・タイプを示す情報要素（UEアシスタンスIE）を送信してもよい。さらに又はこれに代えて、UE１は、RLC header、MAC header又はMAC CEを用いて、PDCP処理（e.g., ASセキュリティ処理）の省略を示す情報をRAN２に送信してもよい。より具体的には、第１の通信アーキテクチャ・タイプがPDCP処理の省略を伴う場合、UE１は、第１の通信アーキテクチャ・タイプを示す情報要素とPDCP処理の省略を示す情報要素の少なくとも一方をMAC CEで送信してもよい。

例えば、図４のステップ４０１においてUE１が第１の通信アーキテクチャ・タイプを決定（選択）した場合、UE１は、RRC Connection Setup Completeメッセージ（ステップ４０５）を送信する際に、SRB 1のためのPDCP処理を省略しているかもしれない。そこで、UE１は、MAC CEを用いて、第１の通信アーキテクチャ・タイプを示す情報要素とPDCP処理の省略を示す情報要素の少なくとも一方を送信する。MAC CEを用いることにより、RAN２は、UE１から受信したメッセージ（RRC Connection Setup Completeを含む）に関して、PDCP処理より前のMAC処理の時点で当該メッセージのPDCP処理が省略されたことを認識することができる。

＜第１６の実施形態＞
上述の実施形態では、UE１がRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードに遷移する際に、ランダム・アクセス・プリアンブルの送信を伴うランダム・アクセス手順が行われる例を示したが、これには限定されない。他のランダム・アクセス手順がUE１及びRAN２に実装されてもよい。いくつかの実装において、UE１１は、ランダム・アクセス・プリアンブル（RACHプリアンブル）の代わりに、小さい（短い）メッセージをRACHで送信してもよい。この場合、RACHで送信される当該メッセージは、UE１によって決定（選択）された又はサポートされている通信アーキテクチャ・タイプを示してもよい。これにより、UE１は、UE１によって決定（選択）された又サポートされている通信アーキテクチャ・タイプをRRCコネクションの設定前にRAN２に知らせることができる。例えば、RAN２は、UE１から通知された通信アーキテクチャ・タイプを考慮して、RAレスポンス・メッセージを生成できる。例えば、RAレスポンス・メッセージは、UE１から通知された通信アーキテクチャ・タイプに応じたbackoff indicatorを含んでもよい。

＜第１７の実施形態＞
UE１がRRC-Idleモード（又は他の休止モード）からRRC-Connectedモードに遷移する際に使用されるRACHリソースは、複数の通信アーキテクチャ・タイプに個別に割り当てられてもよい。この場合、UE１は、プリアンブル又は小さい（短い）メッセージを含む最初のRACH送信のためにいずれのRACHリソースが使用されるかによって、UE１によって決定（選択）された又はサポートされている通信アーキテクチャ・タイプを暗示的に示してもよい。これにより、UE１は、UE１によって決定（選択）された又サポートされている通信アーキテクチャ・タイプをRRCコネクションの設定前にRAN２に知らせることができる。例えば、RAN２は、UE１から通知された通信アーキテクチャ・タイプを考慮して、RAレスポンス・メッセージを生成できる。例えば、RAレスポンス・メッセージは、UE１から通知された通信アーキテクチャ・タイプに応じたbackoff indicatorを含んでもよい。

＜第１８の実施形態＞
上述の実施形態は、NB-IoTの通信、LTE eMTCの通信、又はこれら両方に適用されてもよい。さらに、上述の実施形態は、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEの通信に適用されてもよい。

本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。なお、本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。本実施形態では、上述した複数の通信アーキテクチャ・タイプのいずれかがUE１に適用される場合のモビリティの例が説明される。

UE１のモビリティは、アイドルモード（e.g., RRC-Idle、他の休止モード）でのセル変更（アイドルモード・モビリティ）およびコネクテッドモード（e.g., RRC-Connected）でのセル変更（コネクテッドモード・モビリティ）を含む。アイドルモード・モビリティは、アイドルモードでのセル再選択手順を含む。コネクテッドモード・モビリティは、コネクテッドモードでのバックワード・ハンドオーバ手順およびフォワード・ハンドオーバ手順（e.g., リダイレクションを伴うRRCリリース（RRC release with redirection）を含む。

本実施形態に係る無線通信ネットワークは、第１および第２の通信アーキテクチャ・タイプを含む複数の通信アーキテクチャ・タイプの１つ以上に関して、これらの通信アーキテクチャ・タイプのいずれかが適用されたUE１のモビリティをサポートしなくてもよい。ここで、“モビリティをサポートしない”とは、アイドルモード又はコネクテッドモードでのセル変更の後にUE１に適用される通信アーキテクチャ・タイプの決定又は選択の際に、セル変更前にUE１に適用されていた通信アーキテクチャ・タイプ及びその設定が考慮されないことを意味する。

いくつかの実装において、RAN２は、第１（又は第２）の通信アーキテクチャ・タイプを適用するUE１に対するRRC-Connectedモードのモビリティ（handover, redirection）の機能を無効（disabled）にしてもよい。言い換えると、UE１は、RRC-Connectedモードのモビリティの機能（e.g., measurement report, handover, redirection）を無効化（deactivated）してもよい。さらに又はこれに代えて、RAN２は、例えば、第２（又は第１）の通信アーキテクチャ・タイプを適用するUE１に対するRRC-Idleモードのモビリティ（セル再選択）の機能を無効（disabled）にしてもよい。言い換えると、UE１は、RRC-Idleモードのモビリティの機能（e.g., cell reselection, measurement）を無効化（deactivated）してもよい。

いくつかの実装において、第１（又は第２）の通信アーキテクチャ・タイプを適用するUE１は、RRC-Idleモードのモビリティの機能及びRRC-Connectedモードのモビリティの機能を有効化（activated）されてもよい。この場合、UE１は、RRC-Idle又はRRC-Connectedモードでのセル変更の際に以下のように動作してもよい。

例えば、UE１は、セル再選択の実行に応答して、再選択前のセルにおいてUE１に設定されている（適用されている）通信アーキテクチャ・タイプの情報を解放（破棄）してもよい。

例えば、UE１は、RRC-Connectedモードでのハンドオーバ手順（バックワード・ハンドオーバ）の間に、RAN２内のソースRANノード（e.g., ソースeNB、ソースCIoT BS）からハンドオーバ指示を受信したことに応答して、UE１に設定されている（適用されている）通信アーキテクチャ・タイプに関する情報を解放（破棄）してもよい。ハンドオーバ指示は、例えば、mobilityControlInfo IEを含むRRC Connection Reconfigurationメッセージであってもよい。

例えば、UE１は、RRC-ConnectedモードでのRRC release with redirection手順の間に、リダイレクションを要求するRRC Connection ReleaseメッセージをRAN２内のソースRANノード（e.g., ソースeNB、ソースCIoT BS）から受信したことに応答して、UE１に設定されている（適用されている）通信アーキテクチャ・タイプに関する情報を解放（破棄）してもよい。あるいは、UE１は、リダイレクションを要求するRRC Connection Releaseメッセージに従ってセル再選択の実行に応答して、再選択前のセルにおいてUE１に設定されている（適用されている）通信アーキテクチャ・タイプの情報を解放（破棄）してもよい。ここで、RRC Connection Releaseメッセージで使用されるRelease Causeは、”other”でもよいし、新たなcause（e.g., redirectionForCIoT, redirectionForCellUpdate, redirectionRequired, cellUpdateRequired）が規定され、これを使用してもよい。

UE１のセル変更の後に、UE１、RAN２、及びCN３は、上述の実施形態のいずれかに記載の方法に従って、UE１のために使用される通信アーキテクチャ・タイプを決定（選択）してもよい。あるいは、UE１は、セル変更の後に、既存のLTE及びLTE-Advancedにおけるデータ送信を行ってもよい（fall back to legacy/conventional mechanism）。

上述したように、本実施形態では、アイドルモード（休止モード）又はコネクテッドモードでのUE１のセル変更の際に、UE１は、セル変更前の通信アーキテクチャ・タイプ設定を解放（破棄）する。したがって、UE１とセル変更後のネットワークとの間で通信アーキテクチャ・タイプ設定の不整合（不一致）が生じることを防止できる。

＜第１９の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。本実施形態では、上述した複数の通信アーキテクチャ・タイプのいずれかがUE１に適用される場合のアイドルモード・モビリティの例が説明される。

本実施形態に係るUE１は、セル再選択を行った場合に、セル再選択前からUE１に設定されている（適用されている）通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素をRAN２またはCN３に送信する。具体的には、UE１は、セル再選択後に最初にRRC-Connectedモードになる際に、当該情報要素を送信してもよい。

図２０及び図２１は、本実施形態に係る通信手順の一例を示すシーケンス図である。図２０は、UE１のために第１の通信アーキテクチャ・タイプが使用されるケースを示している。一方、図２１は、UE１のために第２の通信アーキテクチャ・タイプが使用されるケースを示している。図２０及び図２１の例では、RAN２は、RAN-1 ２Ａ及びRAN-2 ２Ｂを含む。RAN-1 ２Ａは、セル変更（セル再選択）の前のRANノード（e.g., CIoT BS、eNB）に対応し、RAN-2 ２Ｂは、セル変更後のRANノードに対応する。

図２０について説明する。ステップ２００１では、第１〜第１７の実施形態で説明されたいずれかの手順に従って、UE１のために使用される通信アーキテクチャ・タイプが決定され、決定された通信アーキテクチャ・タイプに応じてUE１が設定される。図２０の例では、UE１は、第１の通信アーキテクチャ・タイプを使用する。ステップ２００２では、RAN-1 ２Ａは、RRCコネクション解放（RRC Connection Release）メッセージをSRB 1上でUE１に送信する。ステップ２００３では、UE１は、UE１に設定されている通信アーキテクチャ・タイプを記憶（格納）し、RRC-Idleモード（又は他の休止モード）に遷移する。図２０の例では、UE１は、第１の通信アーキテクチャ・タイプを使用する。

UE１は、RRC-Idleモード（又は他の休止モード）においてサービングセル及び周辺セルを測定する。ステップ２００４では、UE１は、セル再選択を実行する。ステップ２００５及び２００６では、UE１及びRAN-2 ２Ｂは、UE１がセル再選択後に最初にRRC-ConnectedモードになるためのRRCコネクション確立手順を行う。当該手順の間に、UE１は、セル再選択前からUE１に設定されている（適用されている）通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素（e.g., Configured arc-type information）をRAN-2 ２Ｂに送信する。当該情報要素は、例えば、RRC Connection Requestメッセージを用いて送信されてもよいし、RRC Connection Setup Completeメッセージを用いて送信されてもよい。図２０の例では、当該情報要素は、第１の通信アーキテクチャ・タイプを示す。これにより、RAN-2 ２Ｂは、セル再選択前からUE１に設定されている（適用されている）通信アーキテクチャ・タイプを知ることができ、RAN２は、UE１に設定されている通信アーキテクチャ・タイプに応じた処理を行うことができる。

ステップ２００７では、UE１は、NASメッセージを使用してULデータ送信若しくはDLデータ受信又は両方を行う。第９〜第１０の実施形態と同様に、UE１は、RRC Setup Completeメッセージ又はRRC: UL Information Transferメッセージを用いてSRB 1上で、ULデータを含むNASメッセージを送信してもよい。UE１は、RRC: DL Information Transferメッセージを用いてSRB 1上で、DLデータを含むNASメッセージを受信してもよい。

図２０の手順は、以下のように変更されてもよい。例えば、RAN-2 ２Ｂは、CN３と通信し、UE１の認証又は承認を行ってもよい。

UE１は、セル再選択前からUE１に設定されている（適用されている）通信アーキテクチャ・タイプを示す情報要素（e.g., Configured arc-type information）を、NASメッセージを用いてCN３に送信してもよい。この場合、CN３は、UE１に設定されている（適用されている）通信アーキテクチャ・タイプを示す情報要素をRAN-2 ２Ｂに送信してもよい。

UE１は、UE１に設定されている（適用されている）通信アーキテクチャ・タイプを示す情報要素に代えて、設定されている通信アーキテクチャ・タイプの再開（resume）を示す情報要素と、再選択前のセル又はRANノードを示す情報要素（e.g., Physical Cell ID（PCI）、Carrier frequency （EARFCN）、E-UTRAN Cell Global ID（ECGI））をRAN-2 ２Ｂに送信してもよい。この場合、RAN-2 ２Ｂは、UE１に設定されている（適用されている）通信アーキテクチャ・タイプを、再選択前のセルを管理するRANノードに問い合わせてもよい。

UE１は、設定されている通信アーキテクチャ・タイプの再開（resume）を示す情報要素をCN３に送信してもよい。この場合、CN３は、UE１に設定されている（適用されている）通信アーキテクチャ・タイプを示す情報要素をRAN-2 ２Ｂに送信してもよい。

続いて図２１を説明する。ステップ２１０１では、第１〜第１７の実施形態で説明されたいずれかの手順に従って、UE１のために使用される通信アーキテクチャ・タイプが決定され、決定された通信アーキテクチャ・タイプに応じてUE１が設定される。図２１の例では、UE１は、第２の通信アーキテクチャ・タイプを使用する。ステップ２１０２では、RAN-1 ２Ａは、RRCコネクションの一時中止（suspension）のためのRRCメッセージ（RRC Connection Suspendメッセージ）をUE１に送信する。当該RRCメッセージの受信に応答して、UE１は、RRC-ConnectedからRRC-Idleモード（又は他の休止モード）に遷移し、RRC-Idleモード（又は他の休止モード）においてRRCコネクションに関する情報を保持する（ステップ２１０３）。同様に、RAN-1 ２Ａ及びCN３もRRCコネクションの一時中止（suspension）のために必要なUE１に関するコンテキストを保持する（ステップ２１０３）。さらに、UE１及びRAN-1 ２Ａは、UE１に設定されている通信アーキテクチャ・タイプ（ここでは、第２の通信アーキテクチャ・タイプ）を記憶する（ステップ２１０４）。

ステップ２１０５及び２１０６は、図２０のステップ２００４及び２００５と同様である。ただし、ステップ２１０６で送信されるRRCメッセージでは、UE１に設定されている（適用されている）通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素（e.g., Configured arc-type information）は、第２の通信アーキテクチャ・タイプを示す。さらに、ステップ２１０６で送信されるRRCメッセージは、再選択前のセル又はRANノードを示す情報要素（e.g., PCI、ECGI）を含む。

ステップ２１０７では、ステップ２１０６でのRRCメッセージの受信に応答して、RAN-2 ２Ｂは、セル再選択前のRAN-1 ２ＡにUEコンテキストを要求する。ステップ２０９８では、RAN-1 ２Ａは、RAN-1 ２Ａにおいて保持されているUEコンテキストをRAN-2 ２Ｂに送る。ステップ２１０９では、RAN-2 ２Ｂは、サスペンドされていたRRCコネクションを再開するために、CN３と通信する。具体的には、RAN-2 ２Ｂは、S1-AP: UE Context ActiveメッセージをCN３に送信し、S1-AP: UE Context Active AckメッセージをCN３から受信してもよい。S1-AP: UE Context Activeメッセージは、CN３内でのS1ベアラの構成変更（modification）手順を引き起こす。当該手順は、例えば、MME（又はC-SSN）からS-GWへのModify Bearer Requestメッセージの送信、及びS-GWからMME（又はC-SSN）へのModify Bearer Responseメッセージの送信を含む。

ステップ２１１０では、RAN-2 ２Ｂは、RRCコネクションの再開（resumption）の完了を示すRRCメッセージ（RRC Connection Resume Completeメッセージ）をUE１に送信する。当該RRCメッセージは、ASセキュリティ情報を含む。ステップ２１１１では、UE１及びRAN-2 ２Ｂは、ASセキュリティを確立する。ステップ２１１２では、UE１は、ULベアラ上でRAN-2 ２Ｂを介してULデータを送信し、DLベアラ上でRAN-2 ２Ｂを介してDLデータを受信する。

上述したように、本実施形態では、UE１は、セル再選択を行った場合に、セル再選択前からUE１に設定されている（適用されている）通信アーキテクチャ・タイプを示す情報要素（e.g., Configured arc-type information）を、RAN-2 ２Ｂ又はCN３に送信する。したがって、UE１とセル変更後のネットワークとの間で通信アーキテクチャ・タイプ設定の不整合（不一致）が生じることを防止できる。

＜第２０の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。本実施形態では、上述した複数の通信アーキテクチャ・タイプのいずれかがUE１に適用される場合のコネクテッドモード・モビリティの例が説明される。

本実施形態では、UE１のハンドオーバの際に、ソースRANノード（e.g., CIoT BS、eNB）は、UE１に設定されている（UE１のために使用されている）通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素を含むハンドオーバ要求（Handover Request）をターゲットRANノード（e.g., CIoT BS、eNB）に送信する。

図２２及び図２３は、本実施形態に係る通信手順の一例を示すシーケンス図である。図２２は、UE１のために第１の通信アーキテクチャ・タイプが使用されるケースを示している。一方、図２３は、UE１のために第２の通信アーキテクチャ・タイプが使用されるケースを示している。図２２及び図２３の例では、RAN２は、RAN-1 ２Ａ及びRAN-2 ２Ｂを含む。RAN-1 ２Ａは、ソースRANノード（e.g., CIoT BS、eNB）に対応し、RAN-2 ２Ｂは、ターゲットRANノードに対応する。

図２２について説明する。ステップ２２０１では、第１〜第１７の実施形態で説明されたいずれかの手順に従って、UE１のために使用される通信アーキテクチャ・タイプが決定され、決定された通信アーキテクチャ・タイプに応じてUE１が設定される。図２０の例では、UE１は、第１の通信アーキテクチャ・タイプを使用する。ステップ２２０２では、UE１は、RRC-Connectedモードである。したがって、ステップ２２０２では、UE１は、NASメッセージを使用してULデータ送信若しくはDLデータ受信又は両方を行ってもよい。

ステップ２２０３では、UE１は、サービングセル及び周辺セルの測定結果を示す測定報告をソースRAN-1 ２Ａに送信する。ステップ２００４では、ソースRAN-1 ２Ａは、ターゲットRAN-2 ２ＢへのUE１のハンドオーバを決定する。ステップ２００５では、ソースRAN-1 ２Ａは、ハンドオーバ要求をターゲットRAN-2 ２Ｂに送信する。当該ハンドオーバ要求は、ソースRAN-1 ２ＡにおいてUE１のために使用されている通信アーキテクチャ・タイプ（ここでは第１の通信アーキテクチャ・タイプ）を示す情報要素（e.g., arc-type information）を含む。

ステップ２２０６では、ハンドオーバ要求の受信に応答して、ターゲットRAN-2 ２Ｂは、ハンドオーバ要求に対する応答メッセージ（e.g., Handover Request Acknowledgeメッセージ）をソースRAN-1 ２Ａに送信する。いくつかの実装において、当該応答メッセージは、ソースRAN-1 ２Ａから通知された通信アーキテクチャ・タイプにターゲットRAN-2 ２Ｂが対応できるか否かを示す。あるいは、当該応答メッセージは、ターゲットRAN-2 ２ＢにおいてUE１のために使用される（変更された）通信アーキテクチャ・タイプを明示的又は暗示的に示す。

ステップ２２０７では、ソースRAN-1 ２Ａは、ハンドオーバ後にも現在の通信アーキテクチャ・タイプが継続されることを示す、又はハンドオーバ後にUE１に適用される（変更された）通信アーキテクチャ・タイプを示す情報要素（e.g., arc-type information）を含むハンドオーバ指示をUE１に送信する。ハンドオーバ指示は、例えば、mobilityControlInfo IEを含むRRC Connection Reconfigurationメッセージであってもよい。図２２の例では、ターゲットRAN-2 ２ＢにおいてもUE１のために第１の通信アーキテクチャ・タイプが使用される。

ステップ２２０８では、UE１は、ターゲットセル（ターゲットRAN-2 ２Ｂ）に同期するためにランダム・アクセス手順を実行する。ステップ２２０９では、UE１は、ハンドオーバ確認（Handover Confirm）を含むRRC Connection Reconfiguration CompleteメッセージをターゲットRAN-2 ２Ｂに送信する。ステップ２２１０では、UE１は、ステップ２２０７でソースRAN-1 ２Ａから指示された通信アーキテクチャ・タイプに従って、UL送信若しくはDL送信又は両方を行う。図２２の例では、ターゲットRAN-2 ２ＢにおいてもUE１のために第１の通信アーキテクチャ・タイプが使用される。したがって、ステップ２２１０では、UE１は、NASメッセージを使用してULデータ送信若しくはDLデータ受信又は両方を行ってもよい。

図２２の手順は、以下のように変更されてもよい。ステップ２２０５では、ハンドオーバ要求は、第１の通信アーキテクチャ・タイプの使用がUE１に承認されていること（authorized）を示してもよい。

続いて図２３を説明する。ステップ２３０１では、第１〜第１７の実施形態で説明されたいずれかの手順に従って、UE１のために使用される通信アーキテクチャ・タイプが決定され、決定された通信アーキテクチャ・タイプに応じてUE１が設定される。図２３の例では、UE１は、第２の通信アーキテクチャ・タイプを使用する。ステップ２３０２では、UE１のためのベアラ確立手順が実行される。ステップ２３０３では、UE１は、ULベアラ上でRAN-1 ２Ａを介してULデータを送信し、DLベアラ上でRAN-1 ２Ａを介してDLデータを受信する。

ステップ２３０４〜２３１０は、図２２のステップ２２０３〜２２０９と同様である。ただし、図２３の例では、ターゲットRAN-2 ２Ｂは、UE１のために第２の通信アーキテクチャ・タイプを使用する。ステップ２３１１では、ターゲットRAN-2 ２Ｂは、通常のハンドオーバ手順と同様に、UE１のためのS1ベアラの経路を変更するためにCN３と通信する。例えば、ターゲットRAN-2 ２Ｂは、S1AP: Path Switch RequestメッセージをCN３に送信し、S1AP: Path Switch Request AckメッセージをCN３から受信する。

ステップ２３１２では、UE１は、ULベアラ上でターゲットRAN-2 ２Ｂを介してULデータを送信し、DLベアラ上でターゲットRAN-2 ２Ｂを介してDLデータを受信する。

ステップ２３１３では、UE１、ターゲットRAN-2 ２Ｂ、及びCN３は、RRCコネクションの一時中止（suspension）を行う。

図２２の手順と図２３の手順は適宜組み合わされてもよい。すなわち、既に説明したように、ターゲットRAN-2 ２Ｂは、ソースRAN-1 ２ＡでUE１に適用されていたのとは異なる通信アーキテクチャ・タイプをUE１に適用してもよい。したがって、図２２において、ハンドオーバ応答メッセージ（ステップ２２０６）が、第２の通信アーキテクチャ・タイプがターゲットRAN-2 ２ＢにおいてUE１に使用されることを示す場合、ステップ２２１０の代わりに図２３のステップ２３１１〜２３１３が行われてもよい。これと反対の場合も同様である。

上述したように、本実施形態では、ソースRAN-1 ２Ａは、UE１に設定されている（UE１のために使用されている）通信アーキテクチャ・タイプを示す情報要素を含むハンドオーバ要求（Handover Request）をターゲットRAN-2 ２Ｂに送信する。したがって、UE１とターゲットRAN-2 ２Ｂとの間で通信アーキテクチャ・タイプ設定の不整合（不一致）が生じることを防止できる。

また、本実施形態では、ターゲットRAN-2 ２Ｂは、ソースRAN-1 ２Ａから通知された通信アーキテクチャ・タイプにターゲットRAN-2 ２Ｂが対応できるか否かを示す情報要素、又はターゲットRAN-2 ２ＢにおいてUE１のために使用される（変更された）通信アーキテクチャ・タイプを示す情報要素を含むハンドオーバ応答メッセージをソースRAN-1 ２Ａに送る。さらに、ソースRAN-1 ２Ａは、ターゲットRAN-2 ２ＢにおいてUE１のために使用される通信アーキテクチャ・タイプを示す情報要素を含むハンドオーバ指示をUE１に送信する。したがって、ソースRAN-1 ２Ａでのそれとは異なる通信アーキテクチャ・タイプをターゲットRAN-2 ２ＢにおいてUE１のために使用することができる。

＜第２１の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。本実施形態では、上述した複数の通信アーキテクチャ・タイプのいずれかがUE１に適用される場合のコネクテッドモード・モビリティの例が説明される。

本実施形態では、コネクテッドモードでのフォワード・ハンドオーバ手順の際に、UE１は、ソースRAN-1 ２ＡにおいてUE１に設定されている（適用されている）通信アーキテクチャ・タイプを明示的又は暗示的に示す情報要素をターゲットRAN-2 ２Ｂに送信する。具体的には、UE１は、ターゲットRAN-2 ２ＢへのRRCコネクション再確立メッセージ（RRC Connection Re-establishmentメッセージ）を用いて当該情報要素を送信してもよい。フォワード・ハンドオーバ手順は、リダイレクションを伴うRRC解放メッセージをソースRAN-1 ２ＡがUE１に送信することで開始されてもよい。これに代えて、フォワード・ハンドオーバ手順は、Radio Link Failure（RLF）タイマの満了に応じて、UE１により自発的に開示されてもよい。

図２４並びに図２５Ａ及び２５Ｂは、本実施形態に係る通信手順の一例を示すシーケンス図である。図２４は、UE１のために第１の通信アーキテクチャ・タイプが使用されるケースを示している。一方、図２５Ａ及び２５Ｂは、UE１のために第２の通信アーキテクチャ・タイプが使用されるケースを示している。図２４並びに図２５Ａ及び２５Ｂの例では、RAN２は、RAN-1 ２Ａ及びRAN-2 ２Ｂを含む。RAN-1 ２Ａは、ソースRANノード（e.g., CIoT BS、eNB）に対応し、RAN-2 ２Ｂは、ターゲットRANノードに対応する。

図２４について説明する。ステップ２４０１〜２４０３は、図２２のステップ２２０１〜２２０３と同様である。ステップ２４０４では、ソースRAN-1 ２Ａは、ターゲットRAN-2 ２Ｂへのリダイレクションを示すRRC解放メッセージをUE１に送信する。この場合、当該RRC解放メッセージの受信に応答して、UE１は、セル再選択を行う（ステップ２４０５）。なお、ステップ２４０４は行われなくてよい。具体的には、UE１は、RLFタイマの満了に応じて自発的にセル（再）選択（ステップ２４０５）を行ってもよい。

ステップ２４０６では、UE１は、RRCコネクション再確立要求メッセージをターゲットRAN-2 ２Ｂに送信する。当該RRCコネクション再確立要求メッセージは、ソースRAN-1 ２ＡにおいてUE１に設定されている（適用されている）通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関する情報要素（e.g., Configured arc-type information）を含む。

ステップ２４０７では、ターゲットRAN-2 ２Ｂは、RRCコネクション再確立メッセージ（RRC Connection Re-establishmentメッセージ）をUE１に送信する。当該メッセージは、現在の通信アーキテクチャ・タイプが継続されることを示す、又はターゲットRAN-2 ２ＢにおいてUE１に適用される（変更された）通信アーキテクチャ・タイプを明示的または暗示的に示す、当該通信アーキテクチャ・タイプに関する情報要素（e.g., arc-type information）を含んでもよい。

図２４の例では、ターゲットRAN-2 ２Ｂは、UE１のために第１の通信アーキテクチャ・タイプを使用する。したがって、ステップ２４０８は、図２２のステップ２２１０と同様である。

続いて図２５Ａ及び２５Ｂを説明する。ステップ２５０１〜２５０４は、図２３のステップ２３０１〜２３０４と同様である。

ステップ２５０５〜２５０８は、図２４のステップ２４０４〜２４０７と同様である。図２５Ａ及び２５Ｂの例では、ターゲットRAN-2 ２Ｂは、UE１のために第２の通信アーキテクチャ・タイプを使用する。したがって、ステップ２５０９〜２５１４は、図２１のステップ２１０７〜２１１２と同様である。

ステップ２５１５は、図２３のステップ２３１３と同様である。

図２５Ａ及び２５Ｂの手順は、以下のように変更されてもよい。ステップ２５０５のRRCコネクション解放メッセージは、Resume IDを示してもよい。Resume IDは、RRCサスペンジョンのためにRAN２がUE１に割り当てる識別子である。RAN２は、以前に格納されたUEコンテキストとUE１とを関連付けるためにResume IDを使用する。いくつかの実装において、ソースRAN-1 ２Ａが当該Resume IDを決定し、これをUE１及びターゲットRAN-2 ２Ｂに送信してもよい。これに代えて、ターゲットRAN-2 ２Ｂが当該Resume IDを決定し、これをソースRAN-1 ２Ａを介してUE１に送信してもよい。

上述したように、本実施形態では、UE１は、フォワード・ハンドオーバ関してセル再選択を行った場合に、ソースRAN-1 ２ＡにおいてUE１に設定されている（適用されている）通信アーキテクチャ・タイプを示す情報要素（e.g., Configured arc-type information）を、ターゲットRAN-2 ２Ｂに送信する。したがって、UE１とターゲットRAN-2 ２Ｂとの間で通信アーキテクチャ・タイプ設定の不整合（不一致）が生じることを防止できる。

＜第２２の実施形態＞
3GPPは、2020年移行の導入に向けた5Gの標準化作業を3GPP Release 14として2016年に開始する予定である。5Gは、LTE及びLTE-Advancedの継続的発展（enhancement/evolution）と新たな5Gエア・インタフェース（新たなRadio Access Technology（RAT））の導入による革新的な発展の組合せで実現されると想定されている。新たなRAT（New 5G RAT）は、例えば、LTE/LTE-Advancedの継続的発展が対象とする周波数帯（e.g., 6 GHz以下）よりも高い周波数帯、例えば10 GHz以上のセンチメートル波帯及び30 GHz以上のミリ波帯をサポートする。

高い周波数帯は、高レート通信を提供できる。しかしながら、高い周波数帯のカバレッジは、その周波数特性のために、より局所的である。したがって、高い周波数帯が特定のエリアでの容量及びデータレートを向上するために使用される一方で、広いカバレッジが既存の低い周波数帯によって提供される。すなわち、高い周波数帯でのNew 5G RAT通信の安定性を確保するためには、低い周波数帯と高い周波数帯、つまりLTE/LTE-AdvancedとNew 5G RAT、の密接な(tight) 統合（integration）又は密接なインターワーキングが必要とされる。5Gをサポートする無線端末（5G User Equipment（UE））は、Carrier Aggregation（CA）若しくはDual Connectivity（DC）又はこれらを改良した技術を用いて、低い周波数帯および高い周波数帯（つまり、LTE/LTE-Advancedセル及びNew 5G セル）の両方に接続する。

本明細書で使用される“LTE”との用語は、特に断らない限り、New 5G RATとの密接なインターワーキングを可能とする5GのためのLTE及びLTE-Advancedの発展を含む。このようなLTE及びLTE-Advancedの発展は、LTE-Advanced Pro、LTE+、又はenhanced LTE（eLTE）とも呼ばれる。また、本明細書における“5G”又は“New 5G”との用語は、第5世代移動通信システム（5G）のために新たに導入されるエア・インタフェース（RAT）及びこれに関するノード、セル、及びプロトコルレイヤ等を示すために便宜的に使用される。新たに導入されるエア・インタフェース（RAT）及びこれに関するノード、セル、及びプロトコルレイヤの正式な名称は、標準化作業が進む過程で将来的に決定されるであろう。例えば、LTE RATは、Primary RAT (P-RAT, pRAT)又はMaster RATと呼ばれ、New 5G RATは、Secondary RAT (S-RAT, sRAT)と呼ばれるかもしれない。

上述した第１〜第２１の実施形態は、LTE RATとNew 5G RATの密接なインターワーキングを提供する5G無線通信ネットワークに適用されてもよい。いくつかの実装において、UE１、RAN２、及びCN３は、第１〜第８の実施形態で説明されたいずれかのアタッチ手順をLTE RATにおいて実行し、 当該アタッチ手順において決定（選択）された通信アーキテクチャ・タイプに従うデータ送信をNew 5G RATにおいて行ってもよい。

例えば、第１の通信アーキテクチャ・タイプがUE１のために使用される場合、UE１は、LTEセルでのRRC Connection Setup Completeメッセージの代わりに、5GセルでのUL Informatin Transferメッセージを用いてデータを送信してもよいし、5GセルでのDL Information Transferメッセージを用いてデータを受信してもよい。例えば、第２の通信アーキテクチャ・タイプがUE１のために使用される場合、UE１、RAN２、及びCN３は、RRCコネクションの一時中止（suspension）及び再開（resumption）を5Gセルで実行してもよい。このとき、UE１及びRAN2は、LTEセルにおける通信のために接続しているコアネットワーク・ノードに加えて、LTEセルとは別のコアネットワーク・ノードにも接続するようにしてもよい。

最後に、上述の複数の実施形態に係るUE１、RAN２内のノード（e.g., CIoT BS、eNB）、及びCN３内のノード（e.g., C-SGN、MME）の構成例について説明する。図２６は、UE１の構成例を示すブロック図である。Radio Frequency（RF）トランシーバ２６０１は、RAN２と通信するためにアナログRF信号処理を行う。RFトランシーバ２６０１により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ２６０１は、アンテナ２６０２及びベースバンドプロセッサ２６０３と結合される。すなわち、RFトランシーバ２６０１は、変調シンボルデータ（又はOFDMシンボルデータ）をベースバンドプロセッサ２６０３から受信し、送信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., アタッチ、モビリティ、及び通話管理に関するシグナリング）の通信管理を含む。

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

ベースバンドプロセッサ２６０３は、デジタルベースバンド信号処理を行うモデム・プロセッサ（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１の処理を行うよう構成されてもよい。

図２７は、上述の実施形態に係るRAN２内のノード（e.g., CIoT BS、eNB）の構成例を示すブロック図である。図２７を参照すると、当該ノードは、RFトランシーバ２７０１、ネットワークインターフェース２７０３、プロセッサ２７０４、及びメモリ２７０５を含む。RFトランシーバ２７０１は、無線端末１と通信するためにアナログRF信号処理を行う。RFトランシーバ２７０１は、複数のトランシーバを含んでもよい。RFトランシーバ２７０１は、アンテナ２７０２及びプロセッサ２７０４と結合される。RFトランシーバ２７０１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ２７０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ２７０２に供給する。また、RFトランシーバ２７０１は、アンテナ２７０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ２７０４に供給する。

ネットワークインターフェース２７０３は、ネットワークノード（e.g., MME、C-SGN、S-GW）と通信するために使用される。ネットワークインターフェース２７０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。

プロセッサ２７０４は、無線通信のためのデジタルベースバンド信号処理（データプレーン処理）とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ２７０４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、プロセッサ２７０４によるコントロールプレーン処理は、S1プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。

プロセッサ２７０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ２７０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）とコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。

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

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

図２８は、上述の実施形態に係るCN３内のノード（e.g., C-SGN、MME）の構成例を示すブロック図である。図２８を参照すると、当該ノードは、ネットワークインターフェース２８０１、プロセッサ２８０２、及びメモリ２８０３を含む。ネットワークインターフェース２８０１は、ネットワークノード（e.g., C-SGN、MME、HSS、S-GW、P-GW、CIoT BS、eNB）と通信するために使用される。ネットワークインターフェース２８０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。

プロセッサ２８０２は、メモリ２８０３から１又は複数のソフトウェアモジュール（コンピュータプログラム）２８０４を読み出して実行することで、上述の実施形態において説明されたCN３内のノード（e.g., C-SGN、MME）の処理を行う。プロセッサ２８０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ２８０２は、複数のプロセッサを含んでもよい。

メモリ２８０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ２８０３は、プロセッサ２８０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ２８０２は、図示されていないI/Oインタフェースを介してメモリ２８０３にアクセスしてもよい。

図２６〜図２８を用いて説明したように、上述の実施形態に係るUE１、RAN２内のノード、及びCN３内のノードが有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（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）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

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

上述の実施形態で説明されたRAN２は、Cloud Radio Access Network（C-RAN）であってもよい。C-RANは、Centralized RANと呼ばれることもある。したがって、上述の実施形態で説明されたRAN２又はRAN２内のCIoT BS若しくはeNBにより行われる処理及び動作は、C-RANアーキテクチャに含まれるDigital Unit（DU）又はDU及びRadio Unit（RU）の組み合せによって提供されてもよい。DUは、Baseband Unit（BBU）と呼ばれる。RUは、Remote Radio Head（RRH）又はRemote Radio Equipment（RRE）とも呼ばれる。すなわち、上述の実施形態で説明されたRAN２、CIoT BS、又はeNBによって行われる処理及び動作は、任意の１又は複数の無線局（RANノード）によって提供されてもよい。

上述の実施形態は、NB-IoTの通信、LTE eMTCの通信、又はこれら両方に適用されてもよい。さらに、上述の実施形態は、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEの通信に適用されてもよい。さらにまた、上述の実施形態は、LTE、LTE-Advanced 及びこれらの改良に限定されるものではなく、その他の無線通信ネットワークに適用されてもよい。

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

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

１ User Equipment（UE）
２ Radio Access Network（RAN）
３ Core Network（CN）
４ アプリケーションサーバ
５ Home Subscriber Server（HSS）
６ Serving Gateway（S-GW）
２６０３ ベースバンドプロセッサ
２６０４ アプリケーションプロセッサ
２６０６ メモリ
２７０４ プロセッサ
２７０５ メモリ
２８０２ プロセッサ
２８０３ メモリ

Claims (16)

1. 無線端末であって、
   メモリと、
   前記メモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、情報要素を包含するRadio Resource Control（RRC）コネクション・セットアップ完了メッセージを無線局に送信するよう構成され、
   前記情報要素は、Cellular Internet of Things（CIoT）に関するデータパケットがコントロールプレーンを介して送信される通信アーキテクチャ・タイプをサポートしている前記無線端末が、CIoTに関するデータパケットがユーザプレーンを介して送信される通信アーキテクチャ・タイプをサポートしているか否かを示し、
   前記RRCコネクション・セットアップ完了メッセージは、Packet Data Convergence Protocol (PDCP)を使用せずに送信され、
   前記情報要素は、Access Stratum (AS)レイヤRRC情報である、
   無線端末。
2. 前記情報要素は、Non-Access Stratum（NAS）メッセージに含まれておらず、前記無線端末ためのデータパケット送信に使用される通信アーキテクチャ・タイプを決定するためにRadio Access Network（RAN）によって使用される、
   請求項１に記載の無線端末。
3. 前記RRCコネクション・セットアップ完了メッセージは、NASアタッチ要求メッセージを包含せず、
   前記情報要素は、Non-Access Stratum（NAS）レイヤ情報ではない、
   請求項１又は２に記載の無線端末。
4. 前記少なくとも１つのプロセッサは、CIoTのためのユーザプレーン上でのユーザデータの転送がセルにおいてサポートされることを示す情報要素を包含するsystem information blockを前記無線局から受信するよう構成される、
   請求項１〜３のいずれか１項に記載の無線端末。
5. 無線端末における方法であって、
   情報要素を包含するRadio Resource Control (RRC)コネクション・セットアップ完了メッセージを無線局に送信することを備え、
   前記情報要素は、Cellular Internet of Things（CIoT）に関するデータパケットがコントロールプレーンを介して送信される通信アーキテクチャ・タイプをサポートしている前記無線端末が、CIoTに関するデータパケットがユーザプレーンを介して送信される通信アーキテクチャ・タイプをサポートしているか否かを示し、
   前記RRCコネクション・セットアップ完了メッセージは、Packet Data Convergence Protocol (PDCP)を使用せずに送信され、
   前記情報要素は、Access Stratum (AS)レイヤRRC情報である、
   方法。
6. 前記情報要素は、Non-Access Stratum（NAS）メッセージに含まれておらず、前記無線端末ためのデータパケット送信に使用される通信アーキテクチャ・タイプを決定するためにRadio Access Network（RAN）によって使用される、
   請求項５に記載の方法。
7. 前記RRCコネクション・セットアップ完了メッセージは、NASアタッチ要求メッセージを包含せず、
   前記情報要素は、Non-Access Stratum（NAS）レイヤ情報ではない、
   請求項５又は６に記載の方法。
8. CIoTのためのユーザプレーン上でのユーザデータの転送がセルにおいてサポートされることを示す情報要素を包含するsystem information blockを前記無線局から受信することをさらに備える、
   請求項５〜７のいずれか１項に記載の方法。
9. 無線局であって、
   メモリと、
   前記メモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、
   Radio Resource Control（RRC）コネクション・セットアップ完了メッセージを無線端末から受信し、
   前記RRCコネクション・セットアップ完了メッセージから第１の情報要素を取得するよう構成され、
   前記第１の情報要素は、Cellular Internet of Things（CIoT）に関するデータパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプをサポートしている前記無線端末が、CIoTに関するデータパケットがユーザプレーンを介して送信される第２の通信アーキテクチャ・タイプをサポートしているか否かを示し、
   前記RRCコネクション・セットアップ完了メッセージは、Packet Data Convergence Protocol (PDCP)を使用せずに前記無線端末によって送信され、
   前記第１の情報要素は、Access Stratum (AS)レイヤRRC情報である、
   無線局。
10. 前記第１の情報要素は、Non-Access Stratum（NAS）メッセージに含まれておらず、前記無線端末ためのデータパケット送信に使用される通信アーキテクチャ・タイプを決定するためにRadio Access Network（RAN）によって使用される、
    請求項９に記載の無線局。
11. 前記少なくとも１つのプロセッサは、前記無線端末ためのデータパケット送信に使用される通信アーキテクチャ・タイプを前記第１の情報要素に基づいて決定するよう構成される、請求項９又は１０に記載の無線局。
12. 前記少なくとも１つのプロセッサは、さらに、
    前記決定された通信アーキテクチャ・タイプに対応するコアネットワークを複数のコアネットワークの中から選択するよう構成され、
    前記RRCコネクション・セットアップ完了メッセージから取り出されたイニシャルNon-Access Stratum（NAS）メッセージを前記選択されたコアネットワークに送信するよう構成されている、
    請求項１１に記載の無線局。
13. 前記少なくとも１つのプロセッサは、前記イニシャルNASメッセージ及び前記決定された通信アーキテクチャ・タイプを示す第２の情報要素を包含するイニシャルUEメッセージを前記選択されたコアネットワークに送信するよう構成されている、
    請求項１２に記載の無線局。
14. 前記少なくとも１つのプロセッサは、前記第２の通信アーキテクチャ・タイプが前記無線端末のために使用される場合に、前記RRCコネクション・セットアップ完了メッセージの受信に応答して、前記第２の通信アーキテクチャ・タイプに必要な追加のPacket Data Convergence Protocol（PDCP）設定を含むRRCメッセージを前記無線端末に送信するよう構成されている、
    請求項９〜１３のいずれか１項に記載の無線局。
15. 前記RRCコネクション・セットアップ完了メッセージは、NASアタッチ要求メッセージを包含せず、
    前記第１の情報要素は、Non-Access Stratum（NAS）レイヤ情報ではない、
    請求項９〜１４のいずれか１項に記載の無線局。
16. 前記少なくとも１つのプロセッサは、CIoTのためのユーザプレーン上でのユーザデータの転送がセルにおいてサポートされることを示す情報要素を包含するsystem information blockを前記無線端末に送信するよう構成される、
    請求項９〜１５のいずれか１項に記載の無線局。

Images