JP2020010379A - 無線端末 - Google Patents

Abstract

【課題】無線端末がＲＲＣコネクションの休止及び再開を伴う第２の通信アーキテクチャ・タイプを使用するようネットワークによって既に設定されているときに、コントロールプレーン上でのデータ送信を伴う第１の通信アーキテクチャ・タイプの通信を効果的に行うことを容易にする。【解決手段】無線端末（１）は、第２の通信アーキテクチャ・タイプのためのRRCコネクションの休止を実行しているときに、第１の通信アーキテクチャ・タイプに従う所定のデータ送信を行う場合、第２の通信アーキテクチャ・タイプに従うRRCコネクションの再開を実行する。【選択図】図３

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メッセージ（e.g., S1AP: UE Context Resume Request）を用いて、UE 状態変更（state change）をMMEに知らせる。MMEは、当該UEのEvolved Packet System（EPS）Connection Management（ECM）状態をECM-Connected 状態に戻し、Modify Bearer Requestメッセージを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。

上述のソリューション２及びソリューション１８はそれぞれ“Data over NAS （DoNAS）”及び“AS context caching”と呼ばれることもある。あるいは、ソリューション２及びソリューション１８はそれぞれ“Control Plane CIoT EPS optimisation”及び“User Plane CIoT EPS optimisation”と呼ばれることもある。

現時点では、ソリューション２は、Access Stratum（AS）セキュリティ及びPDCPを使用しないこと、並びにソリューション２及びソリューション１８が共にSRB 2を使用しないことが想定されている。

いくつかの実装において、UEに適用されるソリューションは、当該UEのアタッチ手順において、コアネットワーク（i.e., MME、C-SGN）によって選択されてもよい。あるいは、いくつかの実装において、UE自身がソリューションを選択してもよい。コアネットワーク又はUEが当該UEのためのソリューションの最初の選択を行った後に、コアネットワーク又は当該UEによって当該UEに適用されるソリューションが変更されてもよい。

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

非特許文献３は、UEがAttach Request、PDN Connection Request、及びTracking Area Update（TAU）Request等のNASメッセージに“Preferred Network Behaviour”indicatonを含めてもよいことを記載している。Preferred Network Behaviourは、UEがサポートできる又はUEが使用することを好むソリューションを示す。具体的には、Preferred Network Behaviourは、以下の情報を含んでもよい：
・Control Plane CIoT EPS optimisation がサポートされるか否か（Whether Control Plane CIoT EPS optimisation is supported）；
・User Plane CIoT EPS optimisation がサポートされるか否か（Whether User Plane CIoT EPS optimisation is supported）；
・Control Plane CIoT EPS optimisation が好ましいか否か、又はUser Plane CIoT EPS optimisation が好ましいか否か（Whether Control Plane CIoT EPS optimisation is preferred or whether User Plane Plane CIoT EPS optimisation is preferred）；
・S1-Uデータ転送がサポートされるか否か（Whether S1-U data transfer is supported）；
・Combined Attach 無しでのSMS転送が要求されるか否か（Whether SMS transfer without Combined Attach is requested）；
・PDN Connectivity 無しでのアタッチがサポートされるか否か（Whether Attach without PDN Connectivity is supported）。

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 3GPP S2-160448, Alcatel-lucent, Vodafone, Qualcomm, Nokia Networks, "Introduction of attach procedure changes for CIoT EPS optimization", 3GPP TSG SA WG2 Meeting #113, St. Kitts, January 25-29 2016

発明者等は、CIoTのための通信アーキテクチャ又は無線端末（UE）の省電力化ための通信アーキテクチャに関して検討を行い、以下に具体的に示される３つの課題を含む幾つかの課題を見出した。

第１に、上述の非特許文献１−３の教示によると、UEがソリューション１８を使用するようネットワーク（e.g., MME、C-SGN）によって既に設定されているときに、ソリューション２の通信（i.e., コントロールプレーン（NAS）上でのデータ送信）がどのようなケースで実行されるのか明確でない。

第２に、上述の非特許文献１−３の教示によると、UEがソリューション１８（i.e., RRCコネクションの休止及び再開を伴う通信）のためのRRCコネクションの休止（suspension）を実行している間にソリューション２に従うデータ送信（i.e., NAS上でのデータ送信）を上位レイヤから要求された場合に、当該UEに保持されているRRCコネクションに関する情報（コンテキスト）がどのように扱われるかが明確でない。上位レイヤは、例えば、service/application layer、IP Multimedia Subsystem（IMS）レイヤ、又はNASレイヤである。

第３に、上述の非特許文献１−３の教示によると、UEがソリューション１８のためのRRCコネクションの休止（suspension）を実行している間にソリューション２に従うデータ送信（i.e., コントロールプレーン（NAS）上でのデータ送信）を上位レイヤから要求された場合に、どのタイプのRRCメッセージを用いてソリューション２に従うデータ送信を行うのかが明確で無い。例えば、RRCコネクションの再開のために使用されるRRCコネクション再開メッセージがソリューション２に従うデータ送信のためにも使用されることを想定する。この場合、eNBは、当該RRCコネクション再開メッセージを受信するが、当該RRCコネクション再開メッセージがデータを運ぶNASメッセージを包含していることを認識できない可能性がある。

したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、無線端末がRRCコネクションの休止（suspension）及び再開（resumption）を伴う通信アーキテクチャ・タイプを使用するようネットワーク（e.g., MME、C-SGN）によって既に設定されているときに、コントロールプレーン（NAS）上でのデータ送信を伴う他の通信アーキテクチャ・タイプの通信を効果的に行うことを容易にする装置、方法、及びプログラムを提供することである。

なお、上述の目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

第１の態様では、無線端末は、メモリと、前記メモリに結合された少なくとも１つのプロセッサとを含む。前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成されている。前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含む。前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において保持することを含む。前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含む。前記少なくとも１つのプロセッサは、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第１の通信アーキテクチャ・タイプを使用してデータを送信するよう構成されている。

第２の態様では、無線端末における方法は、複数の通信アーキテクチャ・タイプのうち少なくとも１つをネットワークによって設定されることを含む。前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含む。前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において保持することを含む。前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含む。前記方法は、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第１の通信アーキテクチャ・タイプを使用してデータを送信することを含む。

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

上述の態様によれば、無線端末がRRCコネクションの休止（suspension）及び再開（resumption）を伴う通信アーキテクチャ・タイプを使用するようネットワーク（e.g., MME、C-SGN）によって既に設定されているときに、コントロールプレーン（NAS）上でのデータ送信を伴う他の通信アーキテクチャ・タイプの通信を効果的に行うことを容易にする装置、方法、及びプログラムを提供できる。

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

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

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

以下に説明される複数の実施形態は、LTE eMTC及びNB-IoTを含むCIoT端末のための無線通信ネットワークを主な対象として説明される。しかしながら、これらの実施形態は、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEの通信に適用されてもよい。つまり、これらの実施形態は、LTE、LTE-Advanced及びこれらの改良に係るその他のUEの通信のための無線ネットワークを対象としてもよい。さらにまた、上述の実施形態は、LTE、LTE-Advanced 及びこれらの改良に限定されるものではなく、その他の無線通信ネットワークに適用されてもよい。

＜第１の実施形態＞
図２は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワークの構成例を示している。図２の例では、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１は、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）、Service Capability Exposure Function（SCEF）、及びPolicy and Charging Rules Function（PCRF）等の他のネットワークエンティティを含んでもよい。

いくつかの実装において、複数の通信アーキテクチャ・タイプは、非特許文献１に示されたソリューション２及び１８にそれぞれ相当する第１及び第２の通信アーキテクチャ・タイプを含んでもよい。第１の通信アーキテクチャ・タイプは、Data over NAS （DoNAS）又はControl Plane CIoT EPS optimisationと呼ぶことができる。すなわち、第１の通信アーキテクチャ・タイプでは、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）によって暗号化及び復号化される。

一方、第２の通信アーキテクチャ・タイプは、AS context caching又はUser Plane CIoT EPS optimisationと呼ぶことができる。すなわち、第２の通信アーキテクチャ・タイプでは、UE１によって送信又は受信されるユーザデータパケットがユーザプレーン（e.g., DRB及びGeneral Packet Radio Service (GPRS) Tunneling Protocol（GTP）トンネルを包含するEPSベアラ）を介して送信され、且つRRCコネクションの休止（suspension）及び再開（resumption）を伴う。

RRCコネクションの休止は、UE１がRRCアイドル状態（具体的には、CIoTのための新たなRRC状態（CIoT RRC-Idle state））であるときに、以前の（previous）RRCコネクションの情報（コンテキスト）をUE１及びRAN２（e.g., eNB、CIoT-BS）において保持することを含む。既に説明したように、UE１及びRAN２において保持されるコンテキストは、例えば、Access Stratum Security Context, bearer related information (incl. RoHC state information) and L2/1 parameters when applicableを含む。なお、RAN２は、RRCメッセージ（e.g., RRC Connection Release）を使用して、UE１にRRCコネクションの休止を指示してもよい。さらに、RAN２は、RRCコネクションの再開に用いる端末識別情報（Resume ID）を当該RRCメッセージで送信してもよい。

さらに、RRCコネクションの休止は、UE１がRRCアイドル状態（且つECM-IDLE状態）であるときに、RAN２（e.g., eNB、CIoT-BS）とCN３（e.g., MME、C-SGN）との間のUE１に関するシグナリング関係（association）をRAN２及びCN３において保持することを含む。UE１に関するシグナリング関係は、S1AP関係（association）である。RAN２及びCN３は、S1AP関係（association）及びこれに関係するUE Contexts（e.g., eNB UE S1AP ID、MME UE S1AP ID）を保持する。さらに、RRCコネクションの休止は、UE１がRRCアイドル状態（且つECM-IDLE状態）であるときに、RAN２（e.g., eNB、CIoT-BS）とCN３（e.g., S-GW）との間のデータベアラに関するベアラ・コンテキストをRAN２及びCN３において保持することを含む。ここで、データベアラは、S1-Uベアラであり、ベアラ・コンテキストはS1-U tunnel addresses（i.e., S1 eNB Tunnel Endpoint Identifier（TEID）及びS1 S-GW TEID）を含む。

RRCコネクションの再開は、UE１がRRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていたRRCコネクション・コンテキストをUE１及びRAN２（e.g., eNB、CIoT-BS）において再利用（reuse）することを含む。さらに、RRCコネクションの再開は、UE１がRRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップに伴って（付随して）、保持されていたS1APシグナリング関係及びベアラ・コンテキストを再利用（reuse）又は復元（restore）することを含む。

より具体的には、UE１がRRC-Connectedモードに戻るとき、UE１は、RRC Connection Resume RequestをRAN２（e.g., eNB）に送る。RAN２は、保持していたコンテキストに基づいて、DRB、セキュリティコンテキスト、S1APコネクション、S1-Uトンネルを復元する。さらに、RAN２は、新たなS1APメッセージ（e.g., S1AP: UE Context Resume Request）を用いて、UE 状態変更（state change）をCN３に知らせる。CN３内のコントロールプレーン・ノード（e.g., MME）は、当該UE１のECM状態をECM-Connected 状態に戻し、Modify Bearer Requestメッセージをユーザプレーン・ノード（e.g., S-GW）に送る。これにより、ユーザプレーン・ノードは、UE１が Connected状態にあると認識し、当該UE１に向けたダウンリンクデータを送信できる状態となる。なお、UE１がRRCコネクションの再開のために送信するRRCメッセージは、RRC Connection Resume Requestでもよいし、LTEで規定されているRRC Connection RequestまたはRRC Connection Reestablishment RequestがRRCコネクション再開手順のために再利用されてもよい。後者の場合、RRCコネクションの再開の要求であることを示す情報要素（IE）が新たに定義され、RRC Connection RequestまたはRRC Connection Reestablishment Requestが当該IEを含むことでRRC Connection Resume Requestであることを示してもよい。

本実施形態では、UE１は、第１及び第２の通信アーキテクチャ・タイプの両方を使用するようにネットワークによって設定されるよう構成されている。

図３は、本実施形態に係る通信手順の一例を示すシーケンス図である。図３の手順では、ステップ３０１において、UE１は、第１の通信アーキテクチャ・タイプ（ソリューション２）及び第２の通信アーキテクチャ・タイプ（ソリューション１８）の両方を使用するようにCN３（e.g., MME、C-SGN）によって設定される。例えば、UE１は、Attach Request、PDN Connection Request、及びTracking Area Update（TAU）Request等のNASメッセージに“Preferred Network Behaviour”を含めてもよい。Preferred Network Behaviourは、UE１が第１及び第２の通信アーキテクチャ・タイプのどちらの使用を希望しているか（又はどちらをサポートしているか）をCN３（e.g., MME）に知らせる。CN３は、“Preferred Network Behaviour”を考慮して、UE１に使用する（又は許可する、設定する）通信アーキテクチャ・タイプを決定し、決定した１又は複数の通信アーキテクチャ・タイプをNASメッセージ（e.g., Attatch Accept、TAU Accept）を用いてUE１に知らせてもよい。

ステップ３０２では、UE１は、所定の条件（pre-configured criterion）の成立を判定する。言い換えると、ステップ３０２では、UE１は、所定のデータ送信の要求の発生を検出（判定）する。当該所定の条件又は所定のデータ送信の要求は、第１の通信アーキテクチャ・タイプに従うデータ送信（i.e., NAS上でのデータ送信）をUE１にトリガーする。一例において、所定のデータ送信の要求は、上位レイヤ（e.g., service/application layer、IMSレイヤ、NASレイヤ）から下位レイヤ（e.g., NASレイヤ、ASレイヤ）への要求である（e.g.,（Mobile Originated (MO) Access）の場合）。一方、所定のデータ送信の要求は、下位レイヤ（e.g., ASレイヤ）から上位レイヤ（e.g., NASレイヤ）への要求であってもよい（e.g., ページング（Mobile Terminated (MT) Access）の場合）。例えば、UE１のNASレイヤは、所定のデータ送信の要求を上位レイヤ（e.g., service/application layer、IMSレイヤ）又はASレイヤから受信したかを判定してもよい。あるいは、UE１のASレイヤは、所定のデータ送信の要求をNASレイヤから受信したかを判定してもよい。

UE１は、UE１が第１及び第２の通信アーキテクチャ・タイプを使用することをCN３によって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、第１の通信アーキテクチャ・タイプを使用してデータを送信する。すなわち、ステップ３０３では、UE１のNASレイヤは、NASレイヤ上でデータ送信を行うためのDoNAS手順を開始する。ステップ３０４では、UE１は、スモールデータを運ぶNASメッセージを生成し、当該NASメッセージを包含するRRCメッセージ（e.g., RRC Connection Setup Complete、RRC Connection Resume Request、RRC Connection Resume Complete）をRAN２（e.g., CIoT-BS、eNB）に送信する。

ステップ３０５では、RAN２は、当該RRCメッセージを受信し、当該RRCメッセージから取り出されたNASメッセージをCN３（e.g., C-SGN、MME）にS1APメッセージ（e.g., Initial UE Message、UE Context Resume Request）を用いて送信する。NASメッセージは、S1APメッセージのNAS- Protocol Data Unit (PDU) IE（情報要素）に埋め込まれる。RAN２は、第１の通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、S1APメッセージを選択されたDCNに送信してもよい。

ステップ３０６では、CN３（e.g., C-SGN、MME）は、スモールデータを得るために、UE１からのアップリンクNASメッセージを復号化（decrypt）する。CN３は、スモールデータのデータタイプに依存して、スモールデータを他のノード、エンティティ、又はネットワークにフォワードする。

図３の例において、所定のデータ送信は、所定のタイプのスモールデータ送信であってもよい。例えば、所定のデータ送信は、非IP（non-IP）データ送信、SMSデータ送信、１パケットのみの（IP）データ送信、又は予め定められたサービスに関するデータ送信であってもよい。これらのデータは、データ量が小さいか又はIPデータでないために、ユーザプレーン上での転送されるよりもコントロールプレーン上で転送されることが好ましいかもしれない。

図３の例によれば、UE１は、第２の通信アーキテクチャ・タイプを使用するようCN３によって既に設定されているときに、コントロールプレーン上の転送が効果的と考えられるデータ種別の送信に関して第１の通信アーキテクチャ・タイプを使用するよう動作できる。したがって、UE１が第２の通信アーキテクチャ・タイプを使用するようCN３によって既に設定されているときに、第１の通信アーキテクチャ・タイプの通信を効果的に行うことができる。

具体的には、UE１は、第１及び第２の通信アーキテクチャ・タイプの両方を使用するようにCN３によって設定されいるときに、要求された通信が所定のデータ送信であるか否かに依存して、第１の通信アーキテクチャ・タイプ及び第２の通信アーキテクチャ・タイプのどちらを使用するかを決定する。これにより、２つ以上の通信アーキテクチャ・タイプがUE１に同時に設定される場合に、UE１が通信アーキテクチャ・タイプの選択を適切に行うことができる。

＜第２の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。

図４は、本実施形態に係る通信手順の一例を示すシーケンス図である。図４の手順では、図３の手順と同様に、ステップ４０１において、UE１は、第１の通信アーキテクチャ・タイプ（ソリューション２）及び第２の通信アーキテクチャ・タイプ（ソリューション１８）の両方を使用するようにCN３（e.g., MME、C-SGN）によって設定される。さらに、ステップ４０１では、UE１は、第２の通信アーキテクチャ・タイプのための休止（suspension）動作を実行している。すなわち、UE１は、RRCアイドル状態（e.g., CIoT RRC idle状態）において、以前のRRCコネクションに関するコンテキストを保持している。

ステップ４０２では、第１の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに、第１の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出（判定）する。第１の実施形態で説明したように、データ送信の要求は、上位レイヤ（e.g., service/application layer、IMSレイヤ、NASレイヤ）から下位レイヤ（e.g., NASレイヤ、ASレイヤ）への要求、又は下位レイヤ（e.g., ASレイヤ）から上位レイヤ（e.g., NASレイヤ）への要求である。なお、図４の例では、UE１は、SMS送信をトリガーされる。なお、SMS送信は第１の通信アーキテクチャ・タイプに適した送信の一例である。第１の実施形態で説明されたように、ステップ４０２では、UE１は、非IP（non-IP）データ送信、１パケットのみの（IP）データ送信、又は予め定められたサービスに関するデータ送信をトリガーされてもよい。

ステップ４０３では、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに第１の通信アーキテクチャ・タイプに従うデータ送信（e.g., SMS送信）の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ送信）を開始する。図４に示された具体例では、UE１のNASレイヤは、RRCコネクションを再開するためのRRC Connection Resume手順を行う（ステップ４０４〜４０６）。

ステップ４０４〜４０６では、RRCコネクションが再開される。すなわち、ステップ４０４では、UE１は、RRC Connection Resume RequestメッセージをRAN２（e.g., eNB、CIoT-BS）に送信する。RRC Connection Resume Requestメッセージは、レジュームIDを包含する。レジュームIDは、例えば、Cell-Radio Network Temporary Identifier（C-RNTI）及びセルID（e.g., Physical Cell ID（PCI））の組合せである。なお、図４は、ランダム・アクセス手順の記載を省略している。ステップ４０４のRRC Connection Resume Requestメッセージは、ランダム・アクセス手順の第３メッセージ（Msg3）で送信されてもよい。

RAN２は、RRC Connection Resume Requestメッセージを受信し、RRC Connection Resume RequestメッセージからレジュームIDを取得し、当該レジュームIDに関連付けられている保持されていたコンテキストに基づいて、RRCコネクションを再開する。ステップ４０５では、RAN２は、RRC Connection ResumeメッセージをUE１に送信する。RRC Connection Resumeメッセージは、例えば、どのDRB(s)が再開されるかを示す。RRC Connection Resumeメッセージは、L2/L1 parametersを含んでもよい。UE１は、ステップ４０５のRRC Connection Resumeメッセージに従って、保持されていたAS security contextを再開する。ステップ４０６では、UE１は、RRC Connection Resume CompleteメッセージをRAN２に送信する。

なお、ステップ４０４〜４０６に示されたRRCコネクション再開手順は一例である。例えば、ステップ４０４〜４０６は、３つのステップ（３つのメッセージ）による再開手順を示しているが、RRCコネクション再開手順は、２つのステップ（２つのメッセージ）によって行われてもよい。この場合、ステップ４０６のUE１からRAN２への送信は省略されてもよい。また、ステップ４０５のRAN２からUE１へのメッセージが、RRC Connection Resume Completeメッセージと呼ばれてもよい。さらに、ステップ４０４〜４０６に示されたRRC Connection Resume Request、RRC Connetion Resume、及びRRC Connection Resume Completeの代わりに、それぞれRRC Connection Request（又はRRC Connection Reestablishment Request）、RRC Connection Setup（又はRRC Connection Reestablishment）、及びRRC Connection Setup Complete（又はRRC Connection Reestablishment Complete）がRRCコネクション再開手順のために再利用されてもよい。

ステップ４０７〜４０９では、UE１のためのS1AP関係及びS1-Uベアラが再開される。ステップ４０７では、RAN２は、新たなS1APメッセージ（e.g., S1AP: UE Context Resume Request）を用いて、UE１の状態変更（state change）をCN３（e.g., MME、C-SGN）に知らせる。CN３は、当該UE１のECM状態をECM-Connected 状態に戻し、Modify Bearer RequestメッセージをS/P-GW６に送る（ステップ４０８）。これにより、S/P-GW６は、UE １が Connected状態にあると認識し、当該UE１に向けたダウンリンクデータを送信できる状態となる。ステップ４０９では、CN３は、UE１のためのS1AP関係及びS1-Uベアラの再開の完了を示す応答メッセージ（e.g., S1AP: UE Context Resume Response）をRAN２に送る。

ステップ４１０では、UE１のNASレイヤは、NASレイヤ上でデータ送信を行うためのDoNAS手順を開始する。ステップ４１１では、UE１は、スモールデータ（e.g., SMSデータ）を運ぶNASメッセージを生成し、当該NASメッセージを包含するRRCメッセージ（e.g., UL Information Transfer）をRAN２（e.g., eNB、CIoT-BS）に送信する。なお、既に説明したように、現時点では、ソリューション２及びソリューション１８が共にSRB 2を使用しないことが想定されている。したがって、ステップ４１１のRRCメッセージは、Dedicated Control Channel（DCCH）上のSRB 1を用いて送信されもよい。

ステップ４１２では、RAN２は、当該RRCメッセージを受信し、当該RRCメッセージから取り出されたNASメッセージをCN３（e.g., C-SGN、MME）にS1APメッセージ（e.g., Uplink NAS Transport）を用いて送信する。NASメッセージは、S1APメッセージのNAS- Protocol Data Unit (PDU) IE（情報要素）に埋め込まれる。RAN２は、第１の通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、S1APメッセージを選択されたDCNに送信してもよい。

ステップ４１３では、CN３（e.g., MME, C-SGN）は、スモールデータを得るために、UE１からのアップリンクNASメッセージを復号化（decrypt）する。CN３は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図４の例では、CN３は、取り出したSMSデータをSMSに関するエンティティ（e.g., SMS-GMSC、SMS-IWMSC、SMS router）に送る。

以上の説明から理解されるように、図４の例では、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに第１の通信アーキテクチャ・タイプに従うデータ送信（e.g., SMS送信）の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ送信）を開始する。したがって、UE１は、第２の通信アーキテクチャ・タイプに関する休止動作をしているときにNAS上でのデータ送信が発生しても、第２の通信アーキテクチャ・タイプに関する休止動作を継続できる。

なお、図４の例では、UE１は、第１の通信アーキテクチャ・タイプの通信を行うために、RRCコネクション再開手順（ステップ４０４〜４０６）において、RRCコネクションの再開に使用されるのと同じRRCメッセージ（e.g., RRC Connection Resume Request、RRC Connection Resume Complete）をRAN２に送信する。UE１は、これらのアップリンクRRCメッセージのいずれか又は全てにDoNAS送信であることを示す表示（indication）を含めてもよい。さらに又はこれに代えて、UE１は、スモールデータ（e.g., SMSデータ）を運ぶNASメッセージにDoNAS送信であることを示す表示（indication）を含めてもよい。

さらに又はこれに代えて、UE１は、これらのアップリンクRRCメッセージのいずれか又は全てに、バッファ量に関する情報（buffer status）を含めてもよい。ここで、当該バッファ量に関する情報は、DoNASによる通信のため、つまりコントロールプレーン（i.e., SRB）で情報を送信するために新たに規定される情報である。当該バッファ量に関する情報は、まだ確立されていないベアラに対するバッファ量を示し、且つSRBで送信されるデータに関するバッファ量を示す。すなわち、当該バッファ量に関する情報は、従来LTEで規定されている、MAC Control Element（MAC CE）で運ばれるBuffer Status Report (BSR)とは異なる。したがって、当該バッファ量に関する情報を包含するRRCメッセージは、DoNAS送信であることを示すことができる。

さらに又はこれに代えて、ランダムアクセスのプリアンブル送信に使用される無線リソース（e.g., time, frequency, preamble index pool）が予め第１の通信アーキテクチャ・タイプと第２の通信アーキテクチャとで区別されてもよい。この場合、RAN２は、どちらの無線リソースを使用されたかによって、少なくともDoNAS送信が目的であることを認識できる。

これらの手法によれば、RAN２は、RRCコネクション再開手順がDoNASのためであることを認識できる。さらにRAN２は、CN３に、RRCコネクション再開手順がDoNAS送信のためであることを明示的に通知してもよい（e.g., Selected CIoT EPS optmization）。さらに又はこれに代えて、RAN２（又はUE１）は、RRCコネクション再開手順がDoNASのためであることを明示的に示す情報（e.g., Preferred Network Behaviour）または暗示的に示す情報をNAS情報（e.g., NAS Control PDU）に含めてもよい。暗示的に示す方法は、例えば、再開されるベアラを示すE-RAB To Be Resumed List IE に含まれる全てのbearer IDs（e.g., E-RAB IDs）を無効値または0に設定すること、E-RAB To Be Resumed List IEをブランクにすること、又は、確立されていた（つまり、休止されていた）全てのベアラのE-RAB IDsをE-RAB Failed To Resume List IEに含めること、を含んでもよい。これにより、CN３も、RRCコネクション再開手順がDoNASのためであることを認識できる。したがって、例えば、RAN２及びCN３は、DoNAS送信に必要とされないS1-Uベアラを再開するためのシグナリング（ステップ４０８及び４０９）を行わないように動作できる。

いくつかの実装において、UE１は、RRC Connection Resume Request（ステップ４０４）に、DoNASの確立要因（establishment cause）又はDoNASの再開要因（resume cause）を含めてもよい。UE１は、RRC Connection Resume Complete（ステップ４０６）に、DoNASの確立要因又はDoNASの再開要因を含めてもよい。当該確立要因又は再開要因は、“mo-Data-DoNAS”と定義されてもよい。これらに代えて、UE１は、通信が“DoNAS”にためであるか否かを示す情報（e.g., 1-bit flag）をレジュームIDに含めてもよい。これらによれば、RAN２は、RRCコネクション再開手順（ステップ４０４〜４０６）がDoNASのために行われることを認識できる。RAN２は、DoNASの確立要因（establishment cause）若しくは再開要因（resume cause）又はこれに対応する情報要素を、ステップ４０７のS1APメッセージに含めてもよい。これにより、RAN２は、S1-Uベアラの再開が必要とされないことをCN３に知らせることができる。

さらに述べると、図４の手順では、UE１内のNASレイヤとASレイヤ（RRCレイヤ）との間のインタラクションを容易にするために、UE１のNASレイヤは以下のように動作してもよい。なお、NASレイヤは、モビリティ管理及びセッション管理を提供する。ASレイヤは、無線リソース制御（RRC）を提供する。

図４の手順では、UE１のNASレイヤは、第１の通信アーキテクチャ・タイプ（DoNAS）の実行を指定（トリガ）しつつ、第２の通信アーキテクチャ・タイプ（AS Context Cashing）のRRC Connection Resume手順を開始するようASレイヤに要求する必要がある。これを実現するために、例えば、SMSデータがDoNAS送信される場合、UE１のNASレイヤは、SMSデータを運ぶNASメッセージを生成するとともに、モバイルからのSMS送信を示すコールタイプ（i.e., originating SMS）と、DoNASのための新たな確立要因（e.g., mo-Data-DoNAS）とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。

さらに、non-IPデータがDoNAS送信される場合、UE１のNASレイヤは、non-IPデータを運ぶNASメッセージを生成するとともに、モバイルからのnon-IPデータ送信を示す新たなコールタイプ（i.e., originating Non-IP call）と、DoNASのための新たな確立要因（e.g., mo-Data-DoNAS）とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。

これらの動作によれば、UE１のASレイヤは、コールタイプ及び確立要因の新たな組合せに基づいて、第２の通信アーキテクチャ・タイプ（AS Context Cashing）のRRC Connection Resume手順が第１の通信アーキテクチャ・タイプ（DoNAS）のために実行されることを認識できる。

＜第３の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。

図５は、本実施形態に係る通信手順の一例を示すシーケンス図である。図５のステップ５０１及び５０２は、図４のステップ４０１及び４０２と同様である。ステップ５０１において、UE１は、第１の通信アーキテクチャ・タイプ（ソリューション２）及び第２の通信アーキテクチャ・タイプ（ソリューション１８）の両方を使用するようにCN３（e.g., MME、C-SGN）によって設定される。さらに、ステップ５０１では、UE１は、第２の通信アーキテクチャ・タイプのための休止（suspension）動作を実行している。

ステップ５０２では、第１の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに、第１の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出（判定）する。第１の実施形態で説明したように、データ送信の要求は、上位レイヤ（e.g., service/application layer、IMSレイヤ、NASレイヤ）から下位レイヤ（e.g., NASレイヤ、ASレイヤ）への要求、又は下位レイヤ（e.g., ASレイヤ）から上位レイヤ（e.g., NASレイヤ）への要求である。なお、図５の例では、UE１は、SMS送信をトリガーされる。ステップ４０２に関して説明したのと同様に、SMS送信は第１の通信アーキテクチャ・タイプに適した送信の一例である。

ステップ５０３では、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに第１の通信アーキテクチャ・タイプに従うデータ送信（e.g., SMS送信）の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ送信）を開始する。図５に示された具体例では、UE１のNASレイヤは、RRCコネクションを再開するためのRRC Connection Resume手順とDoNAS送信手順を行う（ステップ５０４〜５０６）。言い換えると、図５の例では、UE１は、RRC Connection Resume手順と統合された（結合された）DoNAS送信手順を実行する。

ステップ５０４〜５０６では、RRCコネクションが再開されると同時に、SMSデータを運ぶNASメッセージがUE１からRAN２に送信される。ステップ５０４では、UE１は、RRC Connection Resume RequestメッセージをRAN２（e.g., eNB、CIoT-BS）に送信する。なお、図５は、ランダム・アクセス手順の記載を省略している。ステップ５０４のRRC Connection Resume Requestメッセージは、ランダム・アクセス手順の第３メッセージ（Msg3）で送信されてもよい。ステップ５０５では、RAN２は、RRCコネクションを再開し、RRC Connection ResumeメッセージをUE１に送信する。ステップ５０６では、UE１は、RRC Connection Resume CompleteメッセージをRAN２に送信する。ステップ５０６のRRC Connection Resume Completeメッセージは、SMSデータを運ぶNASメッセージを包含する。

ステップ５０７〜５１０では、UE１のためのS1AP関係及びS1-Uベアラが再開されると同時に、SMSデータを運ぶNASメッセージがRAN２からCN３に送られる。ステップ５０７では、RAN２は、新たなS1APメッセージ（e.g., S1AP: UE Context Resume Request）を用いて、UE１の状態変更（state change）をCN３（e.g., MME、C-SGN）に知らせる。ステップ５０７のS1APメッセージ内のNAS-PDUは、SMSデータを運ぶNASメッセージを包含する。

ステップ５０８では、CN３（e.g., MME, C-SGN）は、スモールデータを得るために、UE１からのアップリンクNASメッセージを復号化（decrypt）する。CN３は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図５の例では、CN３は、取り出したSMSデータをSMSに関するエンティティ（e.g., SMS-GMSC、SMS-IWMSC、SMS router）に送る。

ステップ５０９及び５１０は、図４のステップ４０８及び４０９と同様である。CN３は、当該UE１のECM状態をECM-Connected 状態に戻し、Modify Bearer RequestメッセージをS/P-GW６に送る（ステップ５０９）。これにより、S/P-GW６は、UE １が Connected状態にあると認識し、当該UE１に向けたダウンリンクデータを送信できる状態となる。ステップ５１０では、CN３は、UE１のためのS1AP関係及びS1-Uベアラの再開の完了を示す応答メッセージ（e.g., S1AP: UE Context Resume Response）をRAN２に送る。

以上の説明から理解されるように、図５の例では、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに第１の通信アーキテクチャ・タイプに従うデータ送信（e.g., SMS送信）の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ送信）を開始する。したがって、図４の例と同様に、UE１は、第２の通信アーキテクチャ・タイプに関する休止動作をしているときにNAS上でのデータ送信が発生しても、第２の通信アーキテクチャ・タイプに関する休止動作を継続できる。

さらに、図５の例では、UE１は、RRC Connection Resume手順と統合された（結合された）DoNAS送信手順を実行する。したがって、図５の例は、図４の例と比べて、DoNAS送信に必要なシグナリングの回数を削減できる。

なお、図４の例と同様に、ステップ５０４〜５０６に示されたRRCコネクション再開手順は一例である。例えば、ステップ５０６のUE１からRAN２への送信は省略されてもよい。この場合、UE１は、ステップ５０４のRRC Connection Resume RequestメッセージにSMSデータを運ぶNASメッセージを含めてもよい。例えば、RRC Connection Request（又はRRC Connection Reestablishment Request）、RRC Connection Setup（又はRRC Connection Reestablishment）、及びRRC Connection Setup Complete（又はRRC Connection Reestablishment Complete）がステップ５０４〜５０６でのRRCコネクション再開手順のために再利用されてもよい。

さらに、図４の例と同様に図５の例においても、UE１は、アップリンクRRCメッセージ（ステップ５０４及び５０６）のいずれか又は全てにDoNAS送信であることを示す表示（indication）を含めてもよい。さらに又はこれに代えて、UE１は、スモールデータ（e.g., SMSデータ）を運ぶNASメッセージにDoNAS送信であることを示す表示（indication）を含めてもよい。さらに又はこれに代えて、UE１は、これらのアップリンクRRCメッセージのいずれか又は全てに、バッファ量に関する情報（buffer status）を含めてもよい。さらに又はこれに代えて、ランダムアクセスのプリアンブル送信に使用される無線リソース（e.g., time, frequency, preamble index pool）が予め第１の通信アーキテクチャ・タイプと第２の通信アーキテクチャとで区別されてもよい。これらの手法によれば、RAN２若しくはCN３又は両方は、RRCコネクション再開手順がDoNASのためであることを認識できる。したがって、例えば、RAN２及びCN３は、DoNAS送信に必要とされないS1-Uベアラを再開するためのシグナリング（ステップ５０９及び５１０）を行わないように動作できる。

さらに、図４の例と同様に図５の例においても、SMSデータがDoNAS送信される場合、UE１のNASレイヤは、SMSデータを運ぶNASメッセージを生成するとともに、モバイルからのSMS送信を示すコールタイプ（i.e., originating SMS）と、DoNASのための新たな確立要因（e.g., mo-Data-DoNAS）とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。さらに、non-IPデータがDoNAS送信される場合、UE１のNASレイヤは、non-IPデータを運ぶNASメッセージを生成するとともに、モバイルからのnon-IPデータ送信を示す新たなコールタイプ（i.e., originating Non-IP call）と、DoNASのための新たな確立要因（e.g., mo-Data-DoNAS）とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。

＜第４の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。

図６は、本実施形態に係る通信手順の一例を示すシーケンス図である。図６の手順は、上述の図５の手順と類似している。しかしながら、図６の手順では、DoNASデータ送信のためにRRCコネクション再開手順（図５のステップ５０４〜５０６）の代わりに、RRCコネクション確立手順（ステップ６０４〜６０６）が使用される。

図６のステップ６０１及び６０２は、図５のステップ５０１及び５０２と同様である。ステップ６０１において、UE１は、第１の通信アーキテクチャ・タイプ（ソリューション２）及び第２の通信アーキテクチャ・タイプ（ソリューション１８）の両方を使用するようにCN３（e.g., MME、C-SGN）によって設定される。さらに、ステップ５０１では、UE１は、第２の通信アーキテクチャ・タイプのための休止（suspension）動作を実行している。

ステップ６０２では、第１の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに、第１の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出（判定）する。第１の実施形態で説明したように、データ送信の要求は、上位レイヤ（e.g., service/application layer、IMSレイヤ、NASレイヤ）から下位レイヤ（e.g., NASレイヤ、ASレイヤ）への要求、又は下位レイヤ（e.g., ASレイヤ）から上位レイヤ（e.g., NASレイヤ）への要求である。なお、図６の例では、UE１は、SMS送信をトリガーされる。ステップ４０２及び５０２に関して説明したのと同様に、SMS送信は第１の通信アーキテクチャ・タイプに適した送信の一例である。

ステップ６０３では、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに第１の通信アーキテクチャ・タイプに従うデータ送信（e.g., SMS送信）の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ送信）を開始する。図６に示された具体例では、UE１のNASレイヤは、RRCコネクション確立手順と統合された（結合された）DoNAS送信手順を実行する（ステップ６０４〜６０６）。

ステップ６０４〜６０６では、RRCコネクションが確立されると同時に、SMSデータを運ぶNASメッセージがUE１からRAN２に送信される。ステップ６０４では、UE１は、RRC Connection RequestメッセージをRAN２（e.g., eNB、CIoT-BS）に送信する。なお、図６は、ランダム・アクセス手順の記載を省略している。ステップ６０４のRRC Connection Requestメッセージは、ランダム・アクセス手順の第３メッセージ（Msg3）で送信されてもよい。ステップ６０５では、RAN２は、RRC Connection SetupメッセージをUE１に送信する。ステップ６０６では、UE１は、RRC Connection Setup CompleteメッセージをRAN２に送信する。ステップ５０６のRRC Connection Setup Completeメッセージは、SMSデータを運ぶNASメッセージを包含する。

ステップ６０７では、RAN２は、S1APメッセージ（e.g., Initial UE Message）を用いて、SMSデータを運ぶNASメッセージをCN３（e.g., MME、C-SGN）に送る。ステップ６０７のS1APメッセージ内のNAS-PDUは、SMSデータを運ぶNASメッセージを包含する。RAN２は、第１の通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、S1APメッセージを選択されたDCNに送信してもよい。

ステップ６０８では、CN３（e.g., MME, C-SGN）は、スモールデータを得るために、UE１からのアップリンクNASメッセージを復号化（decrypt）する。CN３は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図６の例では、CN３は、取り出したSMSデータをSMSに関するエンティティ（e.g., SMS-GMSC、SMS-IWMSC、SMS router）に送る。

以上の説明から理解されるように、図６の例では、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに第１の通信アーキテクチャ・タイプに従うデータ送信（e.g., SMS送信）の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ送信）を開始する。したがって、図４及び図５の例と同様に、UE１は、第２の通信アーキテクチャ・タイプに関する休止動作をしているときにNAS上でのデータ送信が発生しても、第２の通信アーキテクチャ・タイプに関する休止動作を継続できる。

さらに、図６の例では、UE１は、RRC コネクション確立手順と統合された（結合された）DoNAS送信手順を実行する。したがって、図６の例は、図４の例と比べて、DoNAS送信に必要なシグナリングの回数を削減できる。

なお、図４の例と同様に図６の例においても、UE１は、アップリンクRRCメッセージ（ステップ６０４及び６０６）のいずれか又は全てにDoNAS送信であることを示す表示（indication）を含めてもよい。さらに又はこれに代えて、UE１は、スモールデータ（e.g., SMSデータ）を運ぶNASメッセージにDoNAS送信であることを示す表示（indication）を含めてもよい。さらに又はこれに代えて、UE１は、これらのアップリンクRRCメッセージのいずれか又は全てに、バッファ量に関する情報（buffer status）を含めてもよい。さらに又はこれに代えて、ランダムアクセスのプリアンブル送信に使用される無線リソース（e.g., time, frequency, preamble index pool）が予め第１の通信アーキテクチャ・タイプと第２の通信アーキテクチャとで区別されてもよい。これにより、RAN２若しくはCN３又は両方は、RRCコネクション再開手順がDoNASのためであることを認識できる。

さらに、図４の例と同様に図６の例においても、SMSデータがDoNAS送信される場合、UE１のNASレイヤは、SMSデータを運ぶNASメッセージを生成するとともに、モバイルからのSMS送信を示すコールタイプ（i.e., originating SMS）と、DoNASのための新たな確立要因（e.g., mo-Data-DoNAS）とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。さらに、non-IPデータがDoNAS送信される場合、UE１のNASレイヤは、non-IPデータを運ぶNASメッセージを生成するとともに、モバイルからのnon-IPデータ送信を示す新たなコールタイプ（i.e., originating Non-IP call）と、DoNASのための新たな確立要因（e.g., mo-Data-DoNAS）とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。

本実施形態では、UE１が、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに、以前のRRCコネクション・コンテキストを保持したまま第１の通信アーキテクチャ・タイプに従う通信を開始する例を示した。UE１は、第１の通信アーキテクチャ・タイプの通信を終了して再びRRC-Idleモードに遷移した後、第２の通信アーキテクチャ・タイプによるデータ送信を行うために当該RRCコネクション・コンテキストを用いてRRCコネクションを再開してもよい。

これに代えて、本実施形態において、UE１は、第１の通信アーキテクチャ・タイプに従うデータ送信を行うためにRRCコネクションを確立するときに以前のRRCコネクション・コンテキストを解放（破棄）してもよい。

＜第５の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。

図７は、本実施形態に係る通信手順の一例を示すシーケンス図である。図７の手順は、UE１が、第１及び第２の通信アーキテクチャ・タイプの両方を使用するようにCN３（e.g., MME、C-SGN）によって設定され、且つRRC_Connected状態であるときにDoNAS送信を行う例を示している。

ステップ７０１において、UE１は、第１の通信アーキテクチャ・タイプ（ソリューション２）及び第２の通信アーキテクチャ・タイプ（ソリューション１８）の両方を使用するようにCN３（e.g., MME、C-SGN）によって設定される。ステップ７０２では、UE１がRRC_Connected状態であるときに、第１の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE１は、第２の通信アーキテクチャ・タイプに従い且つRRC_Connected状態であるときに、第１の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出（判定）する。第１の実施形態で説明したように、データ送信の要求は、上位レイヤ（e.g., service/application layer、IMSレイヤ、NASレイヤ）から下位レイヤ（e.g., NASレイヤ、ASレイヤ）への要求、又は下位レイヤ（e.g., ASレイヤ）から上位レイヤ（e.g., NASレイヤ）への要求である。

ステップ７０３では、UE１のNASレイヤは、第２の通信アーキテクチャ・タイプに従い且つRRC_Connected状態であるときに第１の通信アーキテクチャ・タイプに従うデータ送信（e.g., SMS送信）の要求が発生したことに応答して、第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ送信）を開始する。ステップ７０４では、UE１のASレイヤは、UE１のNASレイヤからの要求に応答して、ランダム・アクセス手順を実行し、当該ランダム・アクセス手順の第３メッセージ（Msg3）でDoNAS要求（DoNAS request）をRAN２（e.g., eNB、CIoT-BS）に送信する。

ステップ７０５では、RAN２は、DoNAS要求の受信に応答して、アップリンク（UL）グラント（UL grant）をUE１に送信する。当該UL グラントは、DoNASのためのNASメッセージの送信をUE１に可能とするためのアップリンク無線リソースの割り当てを示す。ステップ７０６では、UE１は、ULグラント（ステップ７０６）に従って、SMSデータを運ぶNASメッセージを包含するRRCメッセージ（e.g., UL Information Transfer）をRAN２に送信する。なお、既に説明したように、現時点では、ソリューション２及びソリューション１８が共にSRB 2を使用しないことが想定されている。したがって、ステップ７０６のRRCメッセージは、Dedicated Control Channel（DCCH）上のSRB 1を用いて送信されもよい。

ステップ７０７では、RAN２は、ステップ７０６のRRCメッセージから取り出されたNASメッセージをCN３（e.g., C-SGN、MME）にS1APメッセージ（e.g., Uplink NAS Transport）を用いて送信する。NASメッセージは、S1APメッセージのNAS- Protocol Data Unit (PDU) IE（情報要素）に埋め込まれる。なお、RAN２は、第１の通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、S1APメッセージを選択されたDCNに送信してもよい。

ステップ７０８では、CN３（e.g., MME, C-SGN）は、スモールデータを得るために、UE１からのアップリンクNASメッセージを復号化（decrypt）する。CN３は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図７の例では、CN３は、取り出したSMSデータをSMSに関するエンティティ（e.g., SMS-GMSC、SMS-IWMSC、SMS router）に送る。

以上の説明から理解されるように、図７の例では、UE１は、第１及び第２の通信アーキテクチャ・タイプを使用できるようにCN３により設定されており、且つRRC_Connected状態であるときに、コントロールプレーン上の転送が効果的と考えられる所定のデータ送信に関して第１の通信アーキテクチャ・タイプを使用するよう動作できる。

いくつかの実装において、図７のステップ７０４で送信されるDoNAS要求は、Physical Uplink Control Channel（PUCCH）上で送信されてもよい。当該DONAS要求は、DoNAS要求のために新たに定義された又は修正されたUplink Control Information（UCI）フォーマットによって運ばれてもよい。UE１が使用可能なPUCCHリソースを有する場合、UE１は、ランダム・アクセス手順を行わずにPUCCHでDoNAS要求を送信してもよい。

いくつかの実装において、図７のステップ７０４で送信されるDoNAS要求は、RRCメッセージを用いて送信されてもよい。このRRCメッセージは、DoNASの確立要因（establishment cause）を示してもよい。同様に、ステップ７０６のRRCメッセージ（e.g., UL Information Transfer）は、、DoNASの確立要因（establishment cause）を示してもよい。

＜第６の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。

本実施形態では、UE１は、第１の通信アーキテクチャ・タイプ及び第２の通信アーキテクチャ・タイプのいずれか一方を使用するようにCN３によって設定され、第１及び第２の通信アーキテクチャ・タイプの両方を同時に使用するように設定されないよう構成されている。

図８は、本実施形態に係る通信手順の一例を示すシーケンス図である。図８の手順では、ステップ８０１において、UE１は、第２の通信アーキテクチャ・タイプ（ソリューション１８）のみを使用するようにCN３（e.g., MME、C-SGN）によって設定される。CN３は、所定の条件（pre-configured criterion）が成立する場合に第１の通信アーキテクチャ・タイプ（ソリューション２）の使用をUE１に許可してもよい。

ステップ８０２では、UE１は、所定の条件（pre-configured criterion）の成立を判定する。言い換えると、ステップ８０２では、UE１のNASレイヤは、所定のデータ送信の要求を上位レイヤ（e.g., service/application layer、IMSレイヤ）から受信したかを判定する。当該所定の条件又は所定のデータ送信の要求は、第１の通信アーキテクチャ・タイプに従うデータ送信（i.e., NAS上でのデータ送信）をUE１にトリガーする。

UE１は、UE１が第２の通信アーキテクチャ・タイプを使用することをCN３によって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、第２の通信アーキテクチャ・タイプから第１の通信アーキテクチャ・タイプに切り替え、第１の通信アーキテクチャ・タイプを使用してデータを送信する。第１の通信アーキテクチャ・タイプに従うデータ送信は、非特許文献１に示されたソリューション２（DoNAS）のMobile Originated（MO）スモールデータ送信手順と同様であってもよい。

すなわち、ステップ８０３では、UE１のNASレイヤは、NASレイヤ上でデータ送信を行うためのDoNAS手順を開始する。ステップ８０４では、UE１は、スモールデータを運ぶNASメッセージを生成し、当該NASメッセージを包含するRRCメッセージ（e.g., RRC Connection Setup Complete、UL Information Transfer）をRAN２（e.g., CIoT-BS、eNB）に送信する。

ステップ８０５では、RAN２は、当該RRCメッセージを受信し、当該RRCメッセージから取り出されたNASメッセージをCN３（e.g., C-SGN、MME）にS1APメッセージ（e.g., Initial UE Message、Uplink NAS Transport）を用いて送信する。NASメッセージは、S1APメッセージのNAS- Protocol Data Unit (PDU) IE（情報要素）に埋め込まれる。RAN２は、第１の通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、S1APメッセージを選択されたDCNに送信してもよい。

ステップ８０６では、CN３（e.g., C-SGN、MME）は、スモールデータを得るために、UE１からのアップリンクNASメッセージを復号化（decrypt）する。CN３は、スモールデータのデータタイプに依存して、スモールデータを他のノード、エンティティ、又はネットワークにフォワードする。

図８の例において、所定のデータ送信は、第１の実施形態で説明された図３の例のそれと同様であってもよい。例えば、所定のデータ送信は、非IP（non-IP）データ送信、SMSデータ送信、１パケットのみの（IP）データ送信、又は予め定められたサービスに関するデータ送信であってもよい。

図８の例によれば、UE１は、第２の通信アーキテクチャ・タイプを使用するようCN３によって既に設定されているときに、コントロールプレーン上の転送が効果的と考えられるデータ種別の送信に関して第１の通信アーキテクチャ・タイプを使用するよう動作できる。したがって、UE１が第２の通信アーキテクチャ・タイプを使用するようCN３によって既に設定されているときに、第１の通信アーキテクチャ・タイプの通信を効果的に行うことができる。

具体的には、UE１は、第２の通信アーキテクチャ・タイプのみを使用するようにCN３によって設定されいるときに所定のデータ送信の要求が発生したことに応答して、第２の通信アーキテクチャ・タイプから第１の通信アーキテクチャ・タイプに切り替える。すなわち、UE１は、第１及び第２の通信アーキテクチャ・タイプのいずれか一方のみを設定され、２つのソリューションの同時設定をサポートする必要がない。したがって、UE１の構成を簡単にできる。このような構成は、コスト最適化及び低消費電力が要求されるNB-CIoTに特に有効である。

＜第７の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。

図９は、本実施形態に係る通信手順の一例を示すシーケンス図である。図９の手順では、図８の手順と同様に、ステップ９０１において、UE１は、第２の通信アーキテクチャ・タイプ（ソリューション１８）のみを使用するようにCN３（e.g., MME、C-SGN）によって設定される。CN３は、所定の条件（pre-configured criterion）が成立する場合に第１の通信アーキテクチャ・タイプ（ソリューション２）の使用をUE１に許可してもよい。さらに、ステップ９０１では、UE１は、第２の通信アーキテクチャ・タイプのための休止（suspension）動作を実行している。すなわち、UE１は、RRCアイドル状態（e.g., CIoT RRC idle状態）において、以前のRRCコネクションに関するコンテキストを保持している。

ステップ９０２では、第１の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに、第１の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出（判定）する。第１の実施形態で説明したように、データ送信の要求は、上位レイヤ（e.g., service/application layer、IMSレイヤ、NASレイヤ）から下位レイヤ（e.g., NASレイヤ、ASレイヤ）への要求、又は下位レイヤ（e.g., ASレイヤ）から上位レイヤ（e.g., NASレイヤ）への要求である。なお、図９の例では、UE１は、SMS送信をトリガーされる。なお、SMS送信は第１の通信アーキテクチャ・タイプに適した送信の一例である。第１の実施形態で説明されたように、ステップ９０２では、UE１は、非IP（non-IP）データ送信、１パケットのみの（IP）データ送信、又は予め定められたサービスに関するデータ送信をトリガーされてもよい。

ステップ９０３では、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに第１の通信アーキテクチャ・タイプに従うデータ送信（e.g., SMS送信）の要求が発生したことに応答して、第２の通信アーキテクチャ・タイプから第１の通信アーキテクチャ・タイプに切り替え、第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ送信）を開始する。第１の通信アーキテクチャ・タイプに従うデータ送信は、非特許文献１に示されたソリューション２（DoNAS）のMobile Originated（MO）スモールデータ送信手順と同様であってもよい。

すなわち、ステップ９０４〜９０６では、UE１は、RRCコネクション確立手順を実行する。ステップ９０４〜９０６では、RRCコネクションが確立されると同時に、SMSデータを運ぶNASメッセージがUE１からRAN２に送信される。ステップ９０４では、UE１は、RRC Connection RequestメッセージをRAN２（e.g., eNB、CIoT-BS）に送信する。なお、図９は、ランダム・アクセス手順の記載を省略している。ステップ９０４のRRC Connection Requestメッセージは、ランダム・アクセス手順の第３メッセージ（Msg3）で送信されてもよい。ステップ９０５では、RAN２は、RRC Connection SetupメッセージをUE１に送信する。ステップ９０６では、UE１は、RRC Connection Setup CompleteメッセージをRAN２に送信する。ステップ９０６のRRC Connection Setup Completeメッセージは、SMSデータを運ぶNASメッセージを包含する。

ステップ９０７では、RAN２は、S1APメッセージ（e.g., Initial UE Message）を用いて、SMSデータを運ぶNASメッセージをCN３（e.g., MME、C-SGN）に送る。ステップ９０７のS1APメッセージ内のNAS-PDUは、SMSデータを運ぶNASメッセージを包含する。RAN２は、第１の通信アーキテクチャ・タイプに対応するDCNをCN３内から選択し、S1APメッセージを選択されたDCNに送信してもよい。

ステップ９０８では、CN３（e.g., MME, C-SGN）は、スモールデータを得るために、UE１からのアップリンクNASメッセージを復号化（decrypt）する。CN３は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図９の例では、CN３は、取り出したSMSデータをSMSに関するエンティティ（e.g., SMS-GMSC、SMS-IWMSC、SMS router）に送る。

いくつかの実装において、UE１は、第１の通信アーキテクチャに従うデータ送信（ステップ９０３）を開始する場合に、第２の通信アーキテクチャ・タイプの休止動作のために保持されている以前のRRCコネクション・コンテキストを削除又は解放してもよい。当該RRCコネクション・コンテキストが格納されていたメモリ領域は、第１の通信アーキテクチャ・タイプに従う通信のRRCコネクション・コンテキストを格納するために再利用されてもよい。言い換えると、第２の通信アーキテクチャ・タイプの休止動作のたｍねの以前のRRCコネクション・コンテキストは、第１の通信アーキテクチャ・タイプに従う通信の新たなRRCコネクション・コンテキストによって上書き（更新）されてもよい。このような構成及び動作によれば、UE１が持つべきメモリ容量を削減でき、コスト最適化及び低消費電力が要求されるNB-CIoTに特に有効である。

なお、第２の通信アーキテクチャ・タイプの休止動作のためにUE１に保持されている以前のRRCコネクション・コンテキストを削除又は解放される場合、UE１は、当該削除又は解放をRAN２若しくはCN３又は両方に通知してもよい。具体的には、UE１は、第１の通信アーキテクチャ・タイプに従う通信を開始するための制御手順（ステップ９０４〜９０７）において、RRCコネクション・コンテキストの破棄を示す表示（indication）をネットワーク（i.e., RAN２若しくはCN３又は両方）に送信してもよい。例えば、UE１は、RRCメッセージ（e.g., RRC Connection Request、RRC Connection Setup Complete）若しくはNASメッセージ又は両方に当該表示を含めてもよい。

RAN２は、UE１からの当該表示の受信に応答して、休止動作のためにRAN２内に保持されている情報（RRCコネクション・コンテキスト、S1AP関係、S1-Uベアラ・コンテキスト）の破棄又は解放が許容されることを認識してもよい。同様に、CN３は、UE１からの当該表示の受信に応答して、休止動作のためにCN３内に保持されている情報（S1AP関係、S1-Uベアラ・コンテキスト）の破棄又は解放が許容されることを認識してもよい。このような構成及び動作によれば、UE１とネットワークとの間で休止状態の不一致が発生することを回避できる。

これに代えて、UE１は、第１の通信アーキテクチャに従うデータ送信（ステップ９０３）を開始する場合に、第２の通信アーキテクチャ・タイプの休止動作のために保持されている以前のRRCコネクション・コンテキストを保持し続けてもよい。

図１０は、本実施形態に係る通信手順の他の例を示すシーケンス図である。図１０は、Mobile Terminated（MT）スモールデータ送信の例を示している。ステップ１００１は、図９のステップ９０１と同様である。ステップ１００２では、CN３（e.g., MME、C-SGN）は、UE１宛てのMobile-Terminated SMSデータの到着を示すページング・メッセージを受信する。なお、CN３は、ステップ１００２において、SMSデータを受信してもよい。この場合、後述するステップ１００８は省略されてもよい。

ステップ１００３では、CN３は、ページング・メッセージをRAN２に送信する。具体的には、CN３は、UE１の１又は複数のトラキングエリアに属する１又は複数のセルに関連付けられた各eNB（又はCIoT-BS）にページング・メッセージを送信する。ステップ１００４では、RAN２によってUE１が呼び出される（paged）。

ステップ１００５では、UE１は、第２の通信アーキテクチャ・タイプのための休止動作を実行しているときに第１の通信アーキテクチャ・タイプに関するページングを受信したことに応答して、第２の通信アーキテクチャ・タイプから第１の通信アーキテクチャ・タイプに切り替え、第１の通信アーキテクチャ・タイプに従う通信（i.e., NAS上でのデータ受信）を開始する。ここで、第１の通信アーキテクチャ・タイプに関するページングは、例えば、第１の通信アーキテクチャ・タイプによるデータ送信が行われることを明示的に示す情報（e.g., 第１の通信アーキテクチャ・タイプか第２の通信アーキテクチャ・タイプかを示す情報、第１の通信アーキテクチャ・タイプであることを示す情報）、または暗示的（e.g., bearer ID）に示す情報を含んでもよい。これに代えて、UE１は、ページングを受けた場合には常に第１の通信アーキテクチャ・タイプを使用して応答するように構成されてもよい。

第１の通信アーキテクチャ・タイプに従うデータ送信は、非特許文献１に示されたソリューション２（DoNAS）のMobile Terminated（MO）スモールデータ送信手順と同様であってもよい。すなわち、ステップ１００６では、UE１は、RRCコネクションを確立し、RRC Connection Setup Complete メッセージを用いてNASメッセージ（i.e., Service Request）をCN３に送信する（ステップ１００７）。CN３は、SMSデータを受信し（ステップ１００８）、当該SMSデータをNASメッセージ内にカプセル化し、当該NASメッセージをRAN２に送信する（ステップ１００９）。RAN２は、SMSデータを運ぶNASメッセージをCN３から受信し、当該NASメッセージを包含するRRCメッセージ（e.g., DL Information Transfer）をUE１に送信する（ステップ１０１０）。既に説明したように、現時点では、ソリューション２及びソリューション１８が共にSRB 2を使用しないことが想定されている。したがって、ステップ１０１０のRRCメッセージは、Dedicated Control Channel（DCCH）上のSRB 1を用いて送信されもよい。

なお、図９の例と同様に図１０の例においても、第２の通信アーキテクチャ・タイプの休止動作のためにUE１に保持されている以前のRRCコネクション・コンテキストを削除又は解放される場合、UE１は、当該削除又は解放をRAN２若しくはCN３又は両方に通知してもよい。RAN２は、UE１からの当該表示の受信に応答して、休止動作のためにRAN２内に保持されている情報（RRCコネクション・コンテキスト、S1AP関係、S1-Uベアラ・コンテキスト）の破棄又は解放が許容されることを認識してもよい。同様に、CN３は、UE１からの当該表示の受信に応答して、休止動作のためにCN３内に保持されている情報（S1AP関係、S1-Uベアラ・コンテキスト）の破棄又は解放が許容されることを認識してもよい。このような構成及び動作によれば、UE１とネットワークとの間で休止状態の不一致が発生することを回避できる。

＜第８の実施形態＞
本実施形態に係る無線通信ネットワークの構成例は、図２と同様である。本実施形態に係るUE１は、CIoTデバイス（e.g., NB-IoT、LTE eMTC）であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。

既に説明したように、現時点では、ソリューション２（DoNAS、Control Plane CIoT EPS optimisation）は、ASセキュリティ及びPDCPを使用しないことが想定されている。いくつかの実装において、PDCPを使用しないDoNAS通信は、単純に、PDCPレイヤを経由せずに行われてもよい。あるいは、PDCPを使用しないDoNAS通信のために、PDCPレイヤの新たな動作モード（e.g., PDCP Transparent Mode（PDCP-TM））が規定されてもよい。新たな動作モード（PDCP-TM）では、PDCPレイヤは、ASセキュリティ機能（integrity protection for SRB、chipering）を含むPDCPレイヤの幾つかの機能を提供しない。

上述のいくつかの実施形態では、第２の通信アーキテクチャ・タイプのための休止動作を実行している間に第１の通信アーキテクチャ・タイプに従うデータ送信を開始するために、UE１がRRC Connection Resume手順を実行する例を示した（e.g., 図４、図５）。第２の通信アーキテクチャ・タイプ（AS context caching、User Plane CIoT EPS optimisation）はASセキュリティを使用するため、RRC Connection Resume手順のいずれかの段階で、UE１及びRAN２はsecurity activation（confirmation）を実行する。したがって、UE１及びRAN２は、RRC Connection Resume手順において既にASセキュリティが有効化（activated）されている場合に、第１の通信アーキテクチャ・タイプ（DoNAS、Control Plane CIoT EPS optimisation）の通信にもASセキュリティ（integrity protection for SRB、chipering）を適用してもよい。

＜第９の実施形態＞
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）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

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

上述の実施形態では、UE１がRRC connection suspendしたセルから他のセルにサービングセルを変更する場合（e.g., cell reselection, detach後のattach）に、上述の実施形態で説明された機能を変更後のサービングセルにおいて利用できるか否かをUE１が判断できることが好ましいかもしれない。したがって、RAN２は、サービングセルにおいて当該機能がサポート（network support）されているか否か（又は許可されているか否か）を示す情報を報知してもよい。例えば、RAN２（e.g., eNB、CIoT-BS）は、RAN２内の各セルで当該情報を報知してもよい。当該情報は、その情報が報知されたセルが当該機能をサポートするか否かを示してもよい。更に当該情報は、隣接セルが当該機能をサポートしているか否かを示してもよい。

上述の実施形態で説明された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ノード）によって提供されてもよい。

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

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

（付記Ａ１）
無線端末であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも１つのプロセッサは、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第１の通信アーキテクチャ・タイプを使用してデータを送信するよう構成されている、
無線端末。

（付記Ａ２）
前記所定のデータ送信は、非Internet Protocol（non-IP）データ送信を含む、
付記Ａ１に記載の無線端末。

（付記Ａ３）
前記所定のデータ送信は、Short Message Service（SMS）データ送信を含む、
付記Ａ１又はＡ２に記載の無線端末。

（付記Ａ４）
前記所定のデータ送信は、１パケットのみのデータ送信を含む、
付記Ａ１〜３のいずれか１項に記載の無線端末。

（付記Ａ５）
前記所定のデータ送信は、予め定められたサービスに関するデータ送信を含む、
付記Ａ１〜Ａ４のいずれか１項に記載の無線端末。

（付記Ａ６）
前記無線端末は、前記第１及び第２の通信アーキテクチャ・タイプの両方を使用するように前記ネットワークによって設定されるよう構成され、
前記少なくとも１つのプロセッサは、要求された通信が前記所定のデータ送信であるか否かに依存して、前記第１の通信アーキテクチャ・タイプ及び前記第２の通信アーキテクチャ・タイプのどちらを使用するかを決定するよう構成されている、
付記Ａ１〜Ａ５のいずれか１項に記載の無線端末。

（付記Ａ７）
前記無線端末は、前記第１の通信アーキテクチャ・タイプ及び前記第２の通信アーキテクチャ・タイプのいずれか一方を使用するように前記ネットワークによって設定され、前記第１及び第２の通信アーキテクチャ・タイプの両方を同時に使用するように設定されないよう構成され、
前記少なくとも１つのプロセッサは、前記所定のデータ送信の要求が発生したことに応答して、前記第２の通信アーキテクチャ・タイプから前記第１の通信アーキテクチャ・タイプに切り替えるよう構成されている、
付記Ａ１〜Ａ５のいずれか１項に記載の無線端末。

（付記Ａ８）
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも１つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第１の通信アーキテクチャ・タイプを使用してデータを送信することを備える、
方法。

（付記Ｂ１）
無線端末であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において、保持されていた保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも１つのプロセッサは、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを保持したまま前記１の通信アーキテクチャ・タイプに従う通信を開始するよう構成されている、
無線端末。

（付記Ｂ２）
前記少なくとも１つのプロセッサは、前記１の通信アーキテクチャ・タイプのデータを包含するNon-Access Stratum（NAS）メッセージを、前記RRCコネクションの前記再開のために使用されるRRCメッセージを用いて送信するよう構成され、
前記RRCメッセージは、Non-Access Stratum（NAS）上でのデータ送信を示す表示（indication）を含む、
付記Ｂ１に記載の無線端末。

（付記Ｂ３）
前記少なくとも１つのプロセッサは、前記１の通信アーキテクチャ・タイプのデータを包含するNon-Access Stratum（NAS）メッセージを、前記RRCコネクションの前記再開のために使用されるRRCメッセージを用いて送信するよう構成され、
前記NASメッセージは、Non-Access Stratum（NAS）上でのデータ送信を示す表示（indication）を含む、
付記Ｂ１又はＢ２に記載の無線端末。

（付記Ｂ４）
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも１つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において、保持されていた保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを保持したまま前記１の通信アーキテクチャ・タイプに従う通信を開始することを備える、
方法。

（付記Ｃ１）
無線端末であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも１つのプロセッサは、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを破棄又は解放して前記１の通信アーキテクチャ・タイプに従う通信を開始するよう構成されている、
無線端末。

（付記Ｃ２）
前記少なくとも１つのプロセッサは、さらに、前記第１の通信アーキテクチャ・タイプに従う通信を開始するための制御手順において、前記コンテキストの破棄を示す表示（indication）をネットワークに送信するよう構成されている、
付記Ｃ１に記載の無線端末。

（付記Ｃ３）
前記少なくとも１つのプロセッサは、前記制御手順において送信されるRRCメッセージ若しくはNon-Access Stratum（NAS）メッセージ又は両方に前記表示を含めるよう構成されている、
付記Ｃ２に記載の無線端末。

（付記Ｃ４）
無線アクセスネットワーク内の無線局であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションに関する第１のコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記第１のコンテキストを再利用することを含み、
前記少なくとも１つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従うデータ送信のためのRRCメッセージを前記無線端末から受信したことに応答して、前記第１のコンテキストの破棄又は解放が許容されることを認識するよう構成されている、
無線局。

（付記Ｃ５）
前記RRCメッセージは、前記休止のために前記無線端末で保持されていた第２のコンテキストの破棄又は解放を示す表示を含み、
前記少なくとも１つのプロセッサは、前記表示の受信に応答して前記第１のコンテキストの破棄又は解放が許容されることを認識するよう構成されている、
付記Ｃ４に記載の無線局。

（付記Ｃ６）
コアネットワーク内のネットワーク装置であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、前記ネットワーク装置と無線局との間の前記無線端末のためのシグナリング関係（association）及び前記無線端末のためのベアラ・コンテキストを前記ネットワーク装置において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップに伴って、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストを再利用又は復元することを含み、
前記少なくとも１つのプロセッサは、さらに、前記ネットワーク装置が前記無線端末のための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従うデータ送信のための制御メッセージを前記無線端末又は前記無線局から受信したことに応答して、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識するよう構成されている、
ネットワーク装置。

（付記Ｃ７）
前記制御メッセージは、前記休止のために前記無線端末で保持されていたRRCコネクションに関する第２のコンテキストの破棄又は解放を示す表示を含み、
前記少なくとも１つのプロセッサは、前記表示の受信に応答して前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識するよう構成されている、
付記Ｃ６に記載のネットワーク装置。

（付記Ｃ８）
前記制御メッセージは、Non-Access Stratum（NAS）メッセージ若しくはS1 Application Protocol（S1AP）メッセージ又は両方を含む、
付記Ｃ６又はＣ７に記載のネットワーク装置。

（付記Ｃ９）
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも１つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを破棄又は解放して前記１の通信アーキテクチャ・タイプに従う通信を開始することを備える、
方法。

（付記Ｃ１０）
無線アクセスネットワーク内の無線局における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションに関する第１のコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記第１のコンテキストを再利用することを含み、
前記方法は、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従うデータ送信のためのRRCメッセージを前記無線端末から受信したことに応答して、前記第１のコンテキストの破棄又は解放が許容されることを認識することを備える、
方法。

（付記Ｃ１１）
コアネットワーク内のネットワーク装置における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、前記ネットワーク装置と無線局との間の前記無線端末のためのシグナリング関係（association）及び前記無線端末のためのベアラ・コンテキストを前記ネットワーク装置において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップに伴って、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストを再利用又は復元することを含み、
前記方法は、さらに、前記ネットワーク装置が前記無線端末のための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従うデータ送信のための制御メッセージを前記無線端末又は前記無線局から受信したことに応答して、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識することを備える、
方法。

（付記Ｄ１）
無線端末であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも１つのプロセッサは、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従う所定のデータ送信の要求が発生したことに応答して、前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを送信するよう構成され、
前記RRCコネクション再開メッセージは、Non-Access Stratum（NAS）上でのデータ送信の確立要因（establishment cause）を示す、
無線端末。

（付記Ｄ２）
前記所定のデータ送信は、非Internet Protocol（non-IP）データ送信またはShort Message Service（SMS）送信であり、
前記少なくとも１つのプロセッサは、モビリティ管理及びセッション管理を提供するNASレイヤ及び無線リソース制御を提供するAccess Stratum （AS）レイヤとして動作するよう構成され、
前記NASレイヤは、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記所定のデータ送信の要求が発生したことに応答して、データを運ぶNASメッセージを生成するとともに、前記NAS上でのデータ送信の前記確立要因と前記所定の通信に関連付けられたコールタイプ（call type）とを包含するRRCコネクション確立の要求を前記ASレイヤに供給するよう構成されている、
付記Ｄ１に記載の無線端末。

（付記Ｄ３）
無線アクセスネットワーク内の無線局であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションに関するコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも１つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを受信するよう構成され、
前記少なくとも１つのプロセッサは、さらに、前記RRCコネクション再開メッセージがNon-Access Stratum（NAS）上でのデータ送信の確立要因を示すことに応答して、前記第１の通信アーキテクチャ・タイプに従う通信であることを認識するよう構成されている、
無線局。

（付記Ｄ４）
前記RRCコネクションの前記休止は、前記無線端末が前記RRCアイドル状態であるときに、前記無線局とコアネットワークとの間の前記無線端末のためのベアラに関するベアラ・コンテキストを前記無線局及びコアネットワークにおいて保持することを更に含み、
前記RRCコネクションの前記再開は、前記その後の（subsequent）RRCコネクションのセットアップに伴って、前記ベアラ・コンテキストに基づいて前記ベアラを復元又は再利用することを更に含み、
前記少なくとも１つのプロセッサは、前記RRCコネクション再開メッセージがNon-Access Stratum（NAS）上でのデータ送信の確立要因を示す場合に、前記ベアラの復元又は再利用を前記コアネットワークに要求しないよう構成されている、
付記Ｄ３に記載の無線局。

（付記Ｄ５）
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも１つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従う所定のデータ送信の要求が発生したことに応答して、前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを送信することを備え、
前記RRCコネクション再開メッセージは、Non-Access Stratum（NAS）上でのデータ送信の確立要因（establishment cause）を示す、
方法。

（付記Ｄ６）
無線アクセスネットワーク内の無線局における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の（previous）RRCコネクションに関するコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の（subsequent）RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも１つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを受信するよう構成され、
前記方法は、さらに、前記RRCコネクション再開メッセージがNon-Access Stratum（NAS）上でのデータ送信の確立要因を示すことに応答して、前記第１の通信アーキテクチャ・タイプに従う通信であることを認識することを備える、
方法。

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

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

Claims (7)

1. 無線端末であって、
   メモリと、
   前記メモリに結合された少なくとも１つのプロセッサと、
   を備え、
   前記少なくとも１つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートし、
   前記複数の通信アーキテクチャ・タイプは、（ａ）データパケットがコントロールプレーンを介して送信される第１の通信アーキテクチャ・タイプ、及び（ｂ）データパケットがユーザプレーンを介して送信され且つRadio Resource Control（RRC）コネクションの休止（suspension）及び再開（resumption）を伴う第２の通信アーキテクチャ・タイプを含み、
   前記RRCコネクションの休止は、Access Stratum（AS）コンテキストを保持しつつRRCコネクションを解放することを含み、
   前記RRCコネクションの再開は、前記無線端末がRRCアイドル状態からRRCコネクテッド状態に遷移するときに実行され、
   前記少なくとも１つのプロセッサは、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記休止を実行しているときに、前記第１の通信アーキテクチャ・タイプに従う所定のデータ送信を行う場合、前記第２の通信アーキテクチャ・タイプに従う前記RRCコネクションの再開を実行する、
   無線端末。
2. 前記RRCコネクションの再開においては、前記保持されていたASコンテキストが用いられる、請求項１に記載の無線端末。
3. 前記少なくとも１つのプロセッサは、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記RRCコネクションの休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従う通信を開始する場合に、前記第２の通信アーキテクチャ・タイプに従う前記RRCコネクションの再開を実行してRRCコネクテッド状態に遷移した後に、前記第１の通信アーキテクチャ・タイプを使用してデータを送信する、
   請求項１または２に記載の無線端末。
4. 前記少なくとも１つのプロセッサは、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記RRCコネクションの休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従う通信を開始する場合に、前記第１の通信アーキテクチャ・タイプに従い送信されるデータを包含するNon-Access Stratum（NAS）メッセージを、前記RRCコネクションの再開のために使用されるRRCメッセージを用いて送信し、
   前記RRCメッセージは、Non-Access Stratum（NAS）上でのデータ送信を示す表示（indication）を含む、
   請求項１乃至３のいずれか一項に記載の無線端末。
5. 前記少なくとも１つのプロセッサは、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記RRCコネクションの休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従う通信を開始する場合に、前記第１の通信アーキテクチャ・タイプに従い送信されるデータを包含するNon-Access Stratum（NAS）メッセージを、前記RRCコネクションの前記再開のために使用されるRRCメッセージを用いて送信し、
   前記NASメッセージは、Non-Access Stratum（NAS）上でのデータ送信を示す表示（indication）を含む、
   請求項１乃至３のいずれか一項に記載の無線端末。
6. 前記少なくとも１つのプロセッサは、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記RRCコネクションの休止を実行しているときに前記第１の通信アーキテクチャ・タイプに従う通信を開始する場合に、前記RRCコネクションの再開のために使用されるRRCコネクション再開メッセージを送信するよう構成され、
   前記RRCコネクション再開メッセージは、Non-Access Stratum（NAS）上での所定のデータ送信の確立要因（establishment cause）を示す情報要素を含む、
   請求項１乃至３のいずれか一項に記載の無線端末。
7. 前記所定のデータ送信は、非Internet Protocol（non-IP）データ送信またはShort Message Service（SMS）送信であり、
   前記少なくとも１つのプロセッサは、モビリティ管理及びセッション管理を提供するNASレイヤ及び無線リソース制御を提供するAccess Stratum （AS）レイヤとして動作するよう構成され、
   前記NASレイヤは、前記無線端末が前記第２の通信アーキテクチャ・タイプのための前記RRCコネクションの休止を実行しているときに前記所定のデータ送信の要求が発生したことに応答して、データを運ぶNASメッセージを生成するとともに、前記NAS上でのデータ送信の前記確立要因と前記所定の通信に関連付けられたコールタイプ（call type）とを包含するRRCコネクション確立の要求を前記ASレイヤに供給するよう構成されている、
   請求項６に記載の無線端末。

Images