JP2021036679A - 無線端末、無線端末の方法、及び基地局の方法 - Google Patents
無線端末、無線端末の方法、及び基地局の方法 Download PDFInfo
- Publication number
- JP2021036679A JP2021036679A JP2020175871A JP2020175871A JP2021036679A JP 2021036679 A JP2021036679 A JP 2021036679A JP 2020175871 A JP2020175871 A JP 2020175871A JP 2020175871 A JP2020175871 A JP 2020175871A JP 2021036679 A JP2021036679 A JP 2021036679A
- Authority
- JP
- Japan
- Prior art keywords
- rrc connection
- rrc
- message
- communication architecture
- wireless terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/18—Selecting a network or a communication service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
- H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
- H04W76/27—Transitions between radio resource control [RRC] states
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/08—Access point devices
- H04W88/10—Access point devices adapted for operation in multiple networks, e.g. multi-mode access points
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】無線端末がRRCコネクションの休止及び再開を伴うUser Plane CIoT EPS Optimisationを使用するようネットワークによって既に設定されているときに、コントロールプレーン上でのデータ送信を伴うControl Plane CIoT EPS Optimisationの通信を効果的に行うことを容易にする。【解決手段】無線端末(1)はUser Plane CIoT EPS OptimisationのためのRRCコネクションの休止を実行しているときにControl Plane CIoT EPS Optimisationに従う所定のデータ送信を行う場合、RRCコネクションの再開手順を開始し、当該再開手順に基づくRRCコネクションの再開後に又は当該再開手順の間に、所定のデータ送信のデータを運ぶNASメッセージを包含するRRCメッセージを送信する。【選択図】図3
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)であることが想定されている。
非特許文献1は、NB-IoTにおける頻繁でないスモールデータ送信(infrequent small data transmission)のための幾つかの通信アーキテクチャ・ソリューションを記載している。これらのソリューションは、コントロールプレーンでのデータ送信アーキテクチャ(ソリューション2)と、RRCコネクションの休止(suspension)及び再開(resumption)を伴う ユーザプレーンでのデータ送信アーキテクチャ(ソリューション18)を含む。非特許文献1では、ソリューション2のサポートがUE及びネットワークの両方に必須とされており、ソリューション18のサポートがUE及びネットワークの両方にオプションとされている。
ソリューション2は、CIoTのためのライトウェイト・コアネットワーク(CN)アーキテクチャに基づいている。ライトウェイトCNアーキテクチャでは、CIoTデバイスの典型的なユースケースを考慮して、コアネットワークは、既存のLTEのCNエンティティ(i.e., Mobility Management Entity(MME)、Serving Gateway(S-GW)、及びPacket Data Network Gateway(P-GW))と比べて限られた機能のみをサポートする。図1は、非ローミングのケースでの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セキュリティは省略されてもよい。
図1に示されたCIoT BSは、CIoT Radio Access Network(CIoT RAN)内の基地局である。図1のCIoT BSの代わりに、C-SGNと接続できるよう構成されたLTE eNBが使用されてもよい。このLTE eNBは、LTE eMTCをサポートするeNBであってもよい。
一方、ソリューション18に係るアーキテクチャは、頻繁でないスモールデータのユーザプレーン上での送信を提供する。ただし、UEのRadio Resource Control(RRC)状態遷移に伴うシグナリングを削減するために、ソリューション18に係るアーキテクチャは、以前の(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に向けたダウンリンクデータを送信できる状態となる。
ソリューション18では、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。
・RRC Connection Setup Complete;
・RRC Security Mode Command;
・RRC Security Mode Complete;
・RRC Connection Reconfiguration;及び
・RRC Connection Reconfiguration Complete。
上述のソリューション2及びソリューション18はそれぞれ“Data over NAS (DoNAS)”及び“AS context caching”と呼ばれることもある。あるいは、ソリューション2及びソリューション18はそれぞれ“Control Plane CIoT EPS optimisation”及び“User Plane CIoT EPS optimisation”と呼ばれることもある。
現時点では、ソリューション2は、Access Stratum(AS)セキュリティ及びPDCPを使用しないこと、並びにソリューション2及びソリューション18が共にSRB 2を使用しないことが想定されている。
いくつかの実装において、UEに適用されるソリューションは、当該UEのアタッチ手順において、コアネットワーク(i.e., MME、C-SGN)によって選択されてもよい。あるいは、いくつかの実装において、UE自身がソリューションを選択してもよい。コアネットワーク又はUEが当該UEのためのソリューションの最初の選択を行った後に、コアネットワーク又は当該UEによって当該UEに適用されるソリューションが変更されてもよい。
非特許文献2は、上述のソリューション2のアーキテクチャ及びソリューション18のアーキテクチャのうちどちらを使用したいかをUEがアタッチ手順において決定してもよいことを記載している。さらに、非特許文献2は、ソリューション2又はソリューション18をデータ送信のために選択することをネットワークに可能とするための情報をAS手順またはNAS手順が含んでもよいことを記載している。
非特許文献3は、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)。
・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)の省電力化ための通信アーキテクチャに関して検討を行い、以下に具体的に示される3つの課題を含む幾つかの課題を見出した。
第1に、上述の非特許文献1−3の教示によると、UEがソリューション18を使用するようネットワーク(e.g., MME、C-SGN)によって既に設定されているときに、ソリューション2の通信(i.e., コントロールプレーン(NAS)上でのデータ送信)がどのようなケースで実行されるのか明確でない。
第2に、上述の非特許文献1−3の教示によると、UEがソリューション18(i.e., RRCコネクションの休止及び再開を伴う通信)のためのRRCコネクションの休止(suspension)を実行している間にソリューション2に従うデータ送信(i.e., NAS上でのデータ送信)を上位レイヤから要求された場合に、当該UEに保持されているRRCコネクションに関する情報(コンテキスト)がどのように扱われるかが明確でない。上位レイヤは、例えば、service/application layer、IP Multimedia Subsystem(IMS)レイヤ、又はNASレイヤである。
第3に、上述の非特許文献1−3の教示によると、UEがソリューション18のためのRRCコネクションの休止(suspension)を実行している間にソリューション2に従うデータ送信(i.e., コントロールプレーン(NAS)上でのデータ送信)を上位レイヤから要求された場合に、どのタイプのRRCメッセージを用いてソリューション2に従うデータ送信を行うのかが明確で無い。例えば、RRCコネクションの再開のために使用されるRRCコネクション再開メッセージがソリューション2に従うデータ送信のためにも使用されることを想定する。この場合、eNBは、当該RRCコネクション再開メッセージを受信するが、当該RRCコネクション再開メッセージがデータを運ぶNASメッセージを包含していることを認識できない可能性がある。
したがって、本明細書に開示される実施形態が達成しようとする目的の1つは、無線端末がRRCコネクションの休止(suspension)及び再開(resumption)を伴う通信アーキテクチャ・タイプを使用するようネットワーク(e.g., MME、C-SGN)によって既に設定されているときに、コントロールプレーン(NAS)上でのデータ送信を伴う他の通信アーキテクチャ・タイプの通信を効果的に行うことを容易にする装置、方法、及びプログラムを提供することである。
なお、上述の目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の1つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
第1の態様では、無線端末は、メモリと、前記メモリに結合された少なくとも1つのプロセッサとを含む。前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成されている。前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含む。前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含む。前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含む。前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第1の通信アーキテクチャ・タイプを使用してデータを送信するよう構成されている。
第2の態様では、無線端末における方法は、複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを含む。前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含む。前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含む。前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含む。前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第1の通信アーキテクチャ・タイプを使用してデータを送信することを含む。
第3の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第2の態様に係る方法をコンピュータに行わせるための命令群(ソフトウェアコード)を含む。
上述の態様によれば、無線端末がRRCコネクションの休止(suspension)及び再開(resumption)を伴う通信アーキテクチャ・タイプを使用するようネットワーク(e.g., MME、C-SGN)によって既に設定されているときに、コントロールプレーン(NAS)上でのデータ送信を伴う他の通信アーキテクチャ・タイプの通信を効果的に行うことを容易にする装置、方法、及びプログラムを提供できる。
以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。
以下に説明される複数の実施形態は、LTE eMTC及びNB-IoTを含むCIoT端末のための無線通信ネットワークを主な対象として説明される。しかしながら、これらの実施形態は、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEの通信に適用されてもよい。つまり、これらの実施形態は、LTE、LTE-Advanced及びこれらの改良に係るその他のUEの通信のための無線ネットワークを対象としてもよい。さらにまた、上述の実施形態は、LTE、LTE-Advanced 及びこれらの改良に限定されるものではなく、その他の無線通信ネットワークに適用されてもよい。
<第1の実施形態>
図2は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワークの構成例を示している。図2の例では、CIoTデバイスとしてのUE1は、CIoT無線アクセスネットワーク(RAN)2及びコアネットワーク(CN)3を介してアプリケーションサーバ4と通信する。RAN2は、CIoTに関するデータパケット送信のための複数の通信アーキテクチャ・タイプをサポートする。RAN2は、RAN2によってサポートされている複数の通信アーキテクチャ・タイプを明示的に又は暗示的に示す情報を例えばMaster Information Block(MIB)又はSystem Information Block(SIB)を用いてセルで報知する。UE1は、これら複数の通信アーキテクチャ・タイプをサポートする。CN3は、これら複数の通信アーキテクチャ・タイプをサポートする。CN3は、これら複数の通信アーキテクチャ・タイプのうちの一部に向けられた個別dedicated CN(DCN)と、他の一部に向けられた別のDCNを含んでもよい。
図2は、本実施形態を含む幾つかの実施形態に係る無線通信ネットワークの構成例を示している。図2の例では、CIoTデバイスとしてのUE1は、CIoT無線アクセスネットワーク(RAN)2及びコアネットワーク(CN)3を介してアプリケーションサーバ4と通信する。RAN2は、CIoTに関するデータパケット送信のための複数の通信アーキテクチャ・タイプをサポートする。RAN2は、RAN2によってサポートされている複数の通信アーキテクチャ・タイプを明示的に又は暗示的に示す情報を例えばMaster Information Block(MIB)又はSystem Information Block(SIB)を用いてセルで報知する。UE1は、これら複数の通信アーキテクチャ・タイプをサポートする。CN3は、これら複数の通信アーキテクチャ・タイプをサポートする。CN3は、これら複数の通信アーキテクチャ・タイプのうちの一部に向けられた個別dedicated CN(DCN)と、他の一部に向けられた別のDCNを含んでもよい。
UE1は、LTE eMTC及びNB-IoTのいずれか又は両方をサポートしてもよい。言い換えると、UE1は、CIoT RAT(NB-IoT RAT)及びLTE RAT(eMTC)のいずれか又は両方をサポートしてもよい。RAN2は、CIoT RAT(NB-IoT RAT)をサポートするCIoT BS及びLTE RAT(eMTC)をサポートするeNBのいずれか又は両方を含んでもよい。CN3は、C-SGN、若しくはMME及びS-GW、又はこれら両方を含んでもよい。CN3は、さらに、P-GW、Home Subscriber Server(HSS)、Service Capability Exposure Function(SCEF)、及びPolicy and Charging Rules Function(PCRF)等の他のネットワークエンティティを含んでもよい。
いくつかの実装において、複数の通信アーキテクチャ・タイプは、非特許文献1に示されたソリューション2及び18にそれぞれ相当する第1及び第2の通信アーキテクチャ・タイプを含んでもよい。第1の通信アーキテクチャ・タイプは、Data over NAS (DoNAS)又はControl Plane CIoT EPS optimisationと呼ぶことができる。すなわち、第1の通信アーキテクチャ・タイプでは、UE1によって送信又は受信されるユーザデータパケットがコントロールプレーン(e.g., UEとMME/C-SGNの間のNASメッセージ)を介して送信される。第1の通信アーキテクチャ・タイプでは、UE1のデータパケット送信のためにRAN2によるDRBのセットアップは必要とされない。また、データパケット送信に使用されるSRBに関して、RAN2による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)レイヤの処理は省略されてもよい。この場合、UE1のデータパケットは、NAS security keysを用いてUE1及びCN3(e.g., MME、C-SGN)によって暗号化及び復号化される。
一方、第2の通信アーキテクチャ・タイプは、AS context caching又はUser Plane CIoT EPS optimisationと呼ぶことができる。すなわち、第2の通信アーキテクチャ・タイプでは、UE1によって送信又は受信されるユーザデータパケットがユーザプレーン(e.g., DRB及びGeneral Packet Radio Service (GPRS) Tunneling Protocol(GTP)トンネルを包含するEPSベアラ)を介して送信され、且つRRCコネクションの休止(suspension)及び再開(resumption)を伴う。
RRCコネクションの休止は、UE1がRRCアイドル状態(具体的には、CIoTのための新たなRRC状態(CIoT RRC-Idle state))であるときに、以前の(previous)RRCコネクションの情報(コンテキスト)をUE1及びRAN2(e.g., eNB、CIoT-BS)において保持することを含む。既に説明したように、UE1及びRAN2において保持されるコンテキストは、例えば、Access Stratum Security Context, bearer related information (incl. RoHC state information) and L2/1 parameters when applicableを含む。なお、RAN2は、RRCメッセージ(e.g., RRC Connection Release)を使用して、UE1にRRCコネクションの休止を指示してもよい。さらに、RAN2は、RRCコネクションの再開に用いる端末識別情報(Resume ID)を当該RRCメッセージで送信してもよい。
さらに、RRCコネクションの休止は、UE1がRRCアイドル状態(且つECM-IDLE状態)であるときに、RAN2(e.g., eNB、CIoT-BS)とCN3(e.g., MME、C-SGN)との間のUE1に関するシグナリング関係(association)をRAN2及びCN3において保持することを含む。UE1に関するシグナリング関係は、S1AP関係(association)である。RAN2及びCN3は、S1AP関係(association)及びこれに関係するUE Contexts(e.g., eNB UE S1AP ID、MME UE S1AP ID)を保持する。さらに、RRCコネクションの休止は、UE1がRRCアイドル状態(且つECM-IDLE状態)であるときに、RAN2(e.g., eNB、CIoT-BS)とCN3(e.g., S-GW)との間のデータベアラに関するベアラ・コンテキストをRAN2及びCN3において保持することを含む。ここで、データベアラは、S1-Uベアラであり、ベアラ・コンテキストはS1-U tunnel addresses(i.e., S1 eNB Tunnel Endpoint Identifier(TEID)及びS1 S-GW TEID)を含む。
RRCコネクションの再開は、UE1がRRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていたRRCコネクション・コンテキストをUE1及びRAN2(e.g., eNB、CIoT-BS)において再利用(reuse)することを含む。さらに、RRCコネクションの再開は、UE1がRRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップに伴って(付随して)、保持されていたS1APシグナリング関係及びベアラ・コンテキストを再利用(reuse)又は復元(restore)することを含む。
より具体的には、UE1がRRC-Connectedモードに戻るとき、UE1は、RRC Connection Resume RequestをRAN2(e.g., eNB)に送る。RAN2は、保持していたコンテキストに基づいて、DRB、セキュリティコンテキスト、S1APコネクション、S1-Uトンネルを復元する。さらに、RAN2は、新たなS1APメッセージ(e.g., S1AP: UE Context Resume Request)を用いて、UE 状態変更(state change)をCN3に知らせる。CN3内のコントロールプレーン・ノード(e.g., MME)は、当該UE1のECM状態をECM-Connected 状態に戻し、Modify Bearer Requestメッセージをユーザプレーン・ノード(e.g., S-GW)に送る。これにより、ユーザプレーン・ノードは、UE1が Connected状態にあると認識し、当該UE1に向けたダウンリンクデータを送信できる状態となる。なお、UE1が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であることを示してもよい。
本実施形態では、UE1は、第1及び第2の通信アーキテクチャ・タイプの両方を使用するようにネットワークによって設定されるよう構成されている。
図3は、本実施形態に係る通信手順の一例を示すシーケンス図である。図3の手順では、ステップ301において、UE1は、第1の通信アーキテクチャ・タイプ(ソリューション2)及び第2の通信アーキテクチャ・タイプ(ソリューション18)の両方を使用するようにCN3(e.g., MME、C-SGN)によって設定される。例えば、UE1は、Attach Request、PDN Connection Request、及びTracking Area Update(TAU)Request等のNASメッセージに“Preferred Network Behaviour”を含めてもよい。Preferred Network Behaviourは、UE1が第1及び第2の通信アーキテクチャ・タイプのどちらの使用を希望しているか(又はどちらをサポートしているか)をCN3(e.g., MME)に知らせる。CN3は、“Preferred Network Behaviour”を考慮して、UE1に使用する(又は許可する、設定する)通信アーキテクチャ・タイプを決定し、決定した1又は複数の通信アーキテクチャ・タイプをNASメッセージ(e.g., Attatch Accept、TAU Accept)を用いてUE1に知らせてもよい。
ステップ302では、UE1は、所定の条件(pre-configured criterion)の成立を判定する。言い換えると、ステップ302では、UE1は、所定のデータ送信の要求の発生を検出(判定)する。当該所定の条件又は所定のデータ送信の要求は、第1の通信アーキテクチャ・タイプに従うデータ送信(i.e., NAS上でのデータ送信)をUE1にトリガーする。一例において、所定のデータ送信の要求は、上位レイヤ(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)の場合)。例えば、UE1のNASレイヤは、所定のデータ送信の要求を上位レイヤ(e.g., service/application layer、IMSレイヤ)又はASレイヤから受信したかを判定してもよい。あるいは、UE1のASレイヤは、所定のデータ送信の要求をNASレイヤから受信したかを判定してもよい。
UE1は、UE1が第1及び第2の通信アーキテクチャ・タイプを使用することをCN3によって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、第1の通信アーキテクチャ・タイプを使用してデータを送信する。すなわち、ステップ303では、UE1のNASレイヤは、NASレイヤ上でデータ送信を行うためのDoNAS手順を開始する。ステップ304では、UE1は、スモールデータを運ぶNASメッセージを生成し、当該NASメッセージを包含するRRCメッセージ(e.g., RRC Connection Setup Complete、RRC Connection Resume Request、RRC Connection Resume Complete)をRAN2(e.g., CIoT-BS、eNB)に送信する。
ステップ305では、RAN2は、当該RRCメッセージを受信し、当該RRCメッセージから取り出されたNASメッセージをCN3(e.g., C-SGN、MME)にS1APメッセージ(e.g., Initial UE Message、UE Context Resume Request)を用いて送信する。NASメッセージは、S1APメッセージのNAS- Protocol Data Unit (PDU) IE(情報要素)に埋め込まれる。RAN2は、第1の通信アーキテクチャ・タイプに対応するDCNをCN3内から選択し、S1APメッセージを選択されたDCNに送信してもよい。
ステップ306では、CN3(e.g., C-SGN、MME)は、スモールデータを得るために、UE1からのアップリンクNASメッセージを復号化(decrypt)する。CN3は、スモールデータのデータタイプに依存して、スモールデータを他のノード、エンティティ、又はネットワークにフォワードする。
図3の例において、所定のデータ送信は、所定のタイプのスモールデータ送信であってもよい。例えば、所定のデータ送信は、非IP(non-IP)データ送信、SMSデータ送信、1パケットのみの(IP)データ送信、又は予め定められたサービスに関するデータ送信であってもよい。これらのデータは、データ量が小さいか又はIPデータでないために、ユーザプレーン上での転送されるよりもコントロールプレーン上で転送されることが好ましいかもしれない。
図3の例によれば、UE1は、第2の通信アーキテクチャ・タイプを使用するようCN3によって既に設定されているときに、コントロールプレーン上の転送が効果的と考えられるデータ種別の送信に関して第1の通信アーキテクチャ・タイプを使用するよう動作できる。したがって、UE1が第2の通信アーキテクチャ・タイプを使用するようCN3によって既に設定されているときに、第1の通信アーキテクチャ・タイプの通信を効果的に行うことができる。
具体的には、UE1は、第1及び第2の通信アーキテクチャ・タイプの両方を使用するようにCN3によって設定されいるときに、要求された通信が所定のデータ送信であるか否かに依存して、第1の通信アーキテクチャ・タイプ及び第2の通信アーキテクチャ・タイプのどちらを使用するかを決定する。これにより、2つ以上の通信アーキテクチャ・タイプがUE1に同時に設定される場合に、UE1が通信アーキテクチャ・タイプの選択を適切に行うことができる。
<第2の実施形態>
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
図4は、本実施形態に係る通信手順の一例を示すシーケンス図である。図4の手順では、図3の手順と同様に、ステップ401において、UE1は、第1の通信アーキテクチャ・タイプ(ソリューション2)及び第2の通信アーキテクチャ・タイプ(ソリューション18)の両方を使用するようにCN3(e.g., MME、C-SGN)によって設定される。さらに、ステップ401では、UE1は、第2の通信アーキテクチャ・タイプのための休止(suspension)動作を実行している。すなわち、UE1は、RRCアイドル状態(e.g., CIoT RRC idle状態)において、以前のRRCコネクションに関するコンテキストを保持している。
ステップ402では、第1の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに、第1の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出(判定)する。第1の実施形態で説明したように、データ送信の要求は、上位レイヤ(e.g., service/application layer、IMSレイヤ、NASレイヤ)から下位レイヤ(e.g., NASレイヤ、ASレイヤ)への要求、又は下位レイヤ(e.g., ASレイヤ)から上位レイヤ(e.g., NASレイヤ)への要求である。なお、図4の例では、UE1は、SMS送信をトリガーされる。なお、SMS送信は第1の通信アーキテクチャ・タイプに適した送信の一例である。第1の実施形態で説明されたように、ステップ402では、UE1は、非IP(non-IP)データ送信、1パケットのみの(IP)データ送信、又は予め定められたサービスに関するデータ送信をトリガーされてもよい。
ステップ403では、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに第1の通信アーキテクチャ・タイプに従うデータ送信(e.g., SMS送信)の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ送信)を開始する。図4に示された具体例では、UE1のNASレイヤは、RRCコネクションを再開するためのRRC Connection Resume手順を行う(ステップ404〜406)。
ステップ404〜406では、RRCコネクションが再開される。すなわち、ステップ404では、UE1は、RRC Connection Resume RequestメッセージをRAN2(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))の組合せである。なお、図4は、ランダム・アクセス手順の記載を省略している。ステップ404のRRC Connection Resume Requestメッセージは、ランダム・アクセス手順の第3メッセージ(Msg3)で送信されてもよい。
RAN2は、RRC Connection Resume Requestメッセージを受信し、RRC Connection Resume RequestメッセージからレジュームIDを取得し、当該レジュームIDに関連付けられている保持されていたコンテキストに基づいて、RRCコネクションを再開する。ステップ405では、RAN2は、RRC Connection ResumeメッセージをUE1に送信する。RRC Connection Resumeメッセージは、例えば、どのDRB(s)が再開されるかを示す。RRC Connection Resumeメッセージは、L2/L1 parametersを含んでもよい。UE1は、ステップ405のRRC Connection Resumeメッセージに従って、保持されていたAS security contextを再開する。ステップ406では、UE1は、RRC Connection Resume CompleteメッセージをRAN2に送信する。
なお、ステップ404〜406に示されたRRCコネクション再開手順は一例である。例えば、ステップ404〜406は、3つのステップ(3つのメッセージ)による再開手順を示しているが、RRCコネクション再開手順は、2つのステップ(2つのメッセージ)によって行われてもよい。この場合、ステップ406のUE1からRAN2への送信は省略されてもよい。また、ステップ405のRAN2からUE1へのメッセージが、RRC Connection Resume Completeメッセージと呼ばれてもよい。さらに、ステップ404〜406に示された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コネクション再開手順のために再利用されてもよい。
ステップ407〜409では、UE1のためのS1AP関係及びS1-Uベアラが再開される。ステップ407では、RAN2は、新たなS1APメッセージ(e.g., S1AP: UE Context Resume Request)を用いて、UE1の状態変更(state change)をCN3(e.g., MME、C-SGN)に知らせる。CN3は、当該UE1のECM状態をECM-Connected 状態に戻し、Modify Bearer RequestメッセージをS/P-GW6に送る(ステップ408)。これにより、S/P-GW6は、UE 1が Connected状態にあると認識し、当該UE1に向けたダウンリンクデータを送信できる状態となる。ステップ409では、CN3は、UE1のためのS1AP関係及びS1-Uベアラの再開の完了を示す応答メッセージ(e.g., S1AP: UE Context Resume Response)をRAN2に送る。
ステップ410では、UE1のNASレイヤは、NASレイヤ上でデータ送信を行うためのDoNAS手順を開始する。ステップ411では、UE1は、スモールデータ(e.g., SMSデータ)を運ぶNASメッセージを生成し、当該NASメッセージを包含するRRCメッセージ(e.g., UL Information Transfer)をRAN2(e.g., eNB、CIoT-BS)に送信する。なお、既に説明したように、現時点では、ソリューション2及びソリューション18が共にSRB 2を使用しないことが想定されている。したがって、ステップ411のRRCメッセージは、Dedicated Control Channel(DCCH)上のSRB 1を用いて送信されもよい。
ステップ412では、RAN2は、当該RRCメッセージを受信し、当該RRCメッセージから取り出されたNASメッセージをCN3(e.g., C-SGN、MME)にS1APメッセージ(e.g., Uplink NAS Transport)を用いて送信する。NASメッセージは、S1APメッセージのNAS- Protocol Data Unit (PDU) IE(情報要素)に埋め込まれる。RAN2は、第1の通信アーキテクチャ・タイプに対応するDCNをCN3内から選択し、S1APメッセージを選択されたDCNに送信してもよい。
ステップ413では、CN3(e.g., MME, C-SGN)は、スモールデータを得るために、UE1からのアップリンクNASメッセージを復号化(decrypt)する。CN3は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図4の例では、CN3は、取り出したSMSデータをSMSに関するエンティティ(e.g., SMS-GMSC、SMS-IWMSC、SMS router)に送る。
以上の説明から理解されるように、図4の例では、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに第1の通信アーキテクチャ・タイプに従うデータ送信(e.g., SMS送信)の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ送信)を開始する。したがって、UE1は、第2の通信アーキテクチャ・タイプに関する休止動作をしているときにNAS上でのデータ送信が発生しても、第2の通信アーキテクチャ・タイプに関する休止動作を継続できる。
なお、図4の例では、UE1は、第1の通信アーキテクチャ・タイプの通信を行うために、RRCコネクション再開手順(ステップ404〜406)において、RRCコネクションの再開に使用されるのと同じRRCメッセージ(e.g., RRC Connection Resume Request、RRC Connection Resume Complete)をRAN2に送信する。UE1は、これらのアップリンクRRCメッセージのいずれか又は全てにDoNAS送信であることを示す表示(indication)を含めてもよい。さらに又はこれに代えて、UE1は、スモールデータ(e.g., SMSデータ)を運ぶNASメッセージにDoNAS送信であることを示す表示(indication)を含めてもよい。
さらに又はこれに代えて、UE1は、これらのアップリンク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)が予め第1の通信アーキテクチャ・タイプと第2の通信アーキテクチャとで区別されてもよい。この場合、RAN2は、どちらの無線リソースを使用されたかによって、少なくともDoNAS送信が目的であることを認識できる。
これらの手法によれば、RAN2は、RRCコネクション再開手順がDoNASのためであることを認識できる。さらにRAN2は、CN3に、RRCコネクション再開手順がDoNAS送信のためであることを明示的に通知してもよい(e.g., Selected CIoT EPS optmization)。さらに又はこれに代えて、RAN2(又はUE1)は、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に含めること、を含んでもよい。これにより、CN3も、RRCコネクション再開手順がDoNASのためであることを認識できる。したがって、例えば、RAN2及びCN3は、DoNAS送信に必要とされないS1-Uベアラを再開するためのシグナリング(ステップ408及び409)を行わないように動作できる。
いくつかの実装において、UE1は、RRC Connection Resume Request(ステップ404)に、DoNASの確立要因(establishment cause)又はDoNASの再開要因(resume cause)を含めてもよい。UE1は、RRC Connection Resume Complete(ステップ406)に、DoNASの確立要因又はDoNASの再開要因を含めてもよい。当該確立要因又は再開要因は、“mo-Data-DoNAS”と定義されてもよい。これらに代えて、UE1は、通信が“DoNAS”にためであるか否かを示す情報(e.g., 1-bit flag)をレジュームIDに含めてもよい。これらによれば、RAN2は、RRCコネクション再開手順(ステップ404〜406)がDoNASのために行われることを認識できる。RAN2は、DoNASの確立要因(establishment cause)若しくは再開要因(resume cause)又はこれに対応する情報要素を、ステップ407のS1APメッセージに含めてもよい。これにより、RAN2は、S1-Uベアラの再開が必要とされないことをCN3に知らせることができる。
さらに述べると、図4の手順では、UE1内のNASレイヤとASレイヤ(RRCレイヤ)との間のインタラクションを容易にするために、UE1のNASレイヤは以下のように動作してもよい。なお、NASレイヤは、モビリティ管理及びセッション管理を提供する。ASレイヤは、無線リソース制御(RRC)を提供する。
図4の手順では、UE1のNASレイヤは、第1の通信アーキテクチャ・タイプ(DoNAS)の実行を指定(トリガ)しつつ、第2の通信アーキテクチャ・タイプ(AS Context Cashing)のRRC Connection Resume手順を開始するようASレイヤに要求する必要がある。これを実現するために、例えば、SMSデータがDoNAS送信される場合、UE1のNASレイヤは、SMSデータを運ぶNASメッセージを生成するとともに、モバイルからのSMS送信を示すコールタイプ(i.e., originating SMS)と、DoNASのための新たな確立要因(e.g., mo-Data-DoNAS)とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。
さらに、non-IPデータがDoNAS送信される場合、UE1のNASレイヤは、non-IPデータを運ぶNASメッセージを生成するとともに、モバイルからのnon-IPデータ送信を示す新たなコールタイプ(i.e., originating Non-IP call)と、DoNASのための新たな確立要因(e.g., mo-Data-DoNAS)とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。
これらの動作によれば、UE1のASレイヤは、コールタイプ及び確立要因の新たな組合せに基づいて、第2の通信アーキテクチャ・タイプ(AS Context Cashing)のRRC Connection Resume手順が第1の通信アーキテクチャ・タイプ(DoNAS)のために実行されることを認識できる。
<第3の実施形態>
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
図5は、本実施形態に係る通信手順の一例を示すシーケンス図である。図5のステップ501及び502は、図4のステップ401及び402と同様である。ステップ501において、UE1は、第1の通信アーキテクチャ・タイプ(ソリューション2)及び第2の通信アーキテクチャ・タイプ(ソリューション18)の両方を使用するようにCN3(e.g., MME、C-SGN)によって設定される。さらに、ステップ501では、UE1は、第2の通信アーキテクチャ・タイプのための休止(suspension)動作を実行している。
ステップ502では、第1の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに、第1の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出(判定)する。第1の実施形態で説明したように、データ送信の要求は、上位レイヤ(e.g., service/application layer、IMSレイヤ、NASレイヤ)から下位レイヤ(e.g., NASレイヤ、ASレイヤ)への要求、又は下位レイヤ(e.g., ASレイヤ)から上位レイヤ(e.g., NASレイヤ)への要求である。なお、図5の例では、UE1は、SMS送信をトリガーされる。ステップ402に関して説明したのと同様に、SMS送信は第1の通信アーキテクチャ・タイプに適した送信の一例である。
ステップ503では、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに第1の通信アーキテクチャ・タイプに従うデータ送信(e.g., SMS送信)の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ送信)を開始する。図5に示された具体例では、UE1のNASレイヤは、RRCコネクションを再開するためのRRC Connection Resume手順とDoNAS送信手順を行う(ステップ504〜506)。言い換えると、図5の例では、UE1は、RRC Connection Resume手順と統合された(結合された)DoNAS送信手順を実行する。
ステップ504〜506では、RRCコネクションが再開されると同時に、SMSデータを運ぶNASメッセージがUE1からRAN2に送信される。ステップ504では、UE1は、RRC Connection Resume RequestメッセージをRAN2(e.g., eNB、CIoT-BS)に送信する。なお、図5は、ランダム・アクセス手順の記載を省略している。ステップ504のRRC Connection Resume Requestメッセージは、ランダム・アクセス手順の第3メッセージ(Msg3)で送信されてもよい。ステップ505では、RAN2は、RRCコネクションを再開し、RRC Connection ResumeメッセージをUE1に送信する。ステップ506では、UE1は、RRC Connection Resume CompleteメッセージをRAN2に送信する。ステップ506のRRC Connection Resume Completeメッセージは、SMSデータを運ぶNASメッセージを包含する。
ステップ507〜510では、UE1のためのS1AP関係及びS1-Uベアラが再開されると同時に、SMSデータを運ぶNASメッセージがRAN2からCN3に送られる。ステップ507では、RAN2は、新たなS1APメッセージ(e.g., S1AP: UE Context Resume Request)を用いて、UE1の状態変更(state change)をCN3(e.g., MME、C-SGN)に知らせる。ステップ507のS1APメッセージ内のNAS-PDUは、SMSデータを運ぶNASメッセージを包含する。
ステップ508では、CN3(e.g., MME, C-SGN)は、スモールデータを得るために、UE1からのアップリンクNASメッセージを復号化(decrypt)する。CN3は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図5の例では、CN3は、取り出したSMSデータをSMSに関するエンティティ(e.g., SMS-GMSC、SMS-IWMSC、SMS router)に送る。
ステップ509及び510は、図4のステップ408及び409と同様である。CN3は、当該UE1のECM状態をECM-Connected 状態に戻し、Modify Bearer RequestメッセージをS/P-GW6に送る(ステップ509)。これにより、S/P-GW6は、UE 1が Connected状態にあると認識し、当該UE1に向けたダウンリンクデータを送信できる状態となる。ステップ510では、CN3は、UE1のためのS1AP関係及びS1-Uベアラの再開の完了を示す応答メッセージ(e.g., S1AP: UE Context Resume Response)をRAN2に送る。
以上の説明から理解されるように、図5の例では、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに第1の通信アーキテクチャ・タイプに従うデータ送信(e.g., SMS送信)の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ送信)を開始する。したがって、図4の例と同様に、UE1は、第2の通信アーキテクチャ・タイプに関する休止動作をしているときにNAS上でのデータ送信が発生しても、第2の通信アーキテクチャ・タイプに関する休止動作を継続できる。
さらに、図5の例では、UE1は、RRC Connection Resume手順と統合された(結合された)DoNAS送信手順を実行する。したがって、図5の例は、図4の例と比べて、DoNAS送信に必要なシグナリングの回数を削減できる。
なお、図4の例と同様に、ステップ504〜506に示されたRRCコネクション再開手順は一例である。例えば、ステップ506のUE1からRAN2への送信は省略されてもよい。この場合、UE1は、ステップ504の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)がステップ504〜506でのRRCコネクション再開手順のために再利用されてもよい。
さらに、図4の例と同様に図5の例においても、UE1は、アップリンクRRCメッセージ(ステップ504及び506)のいずれか又は全てにDoNAS送信であることを示す表示(indication)を含めてもよい。さらに又はこれに代えて、UE1は、スモールデータ(e.g., SMSデータ)を運ぶNASメッセージにDoNAS送信であることを示す表示(indication)を含めてもよい。さらに又はこれに代えて、UE1は、これらのアップリンクRRCメッセージのいずれか又は全てに、バッファ量に関する情報(buffer status)を含めてもよい。さらに又はこれに代えて、ランダムアクセスのプリアンブル送信に使用される無線リソース(e.g., time, frequency, preamble index pool)が予め第1の通信アーキテクチャ・タイプと第2の通信アーキテクチャとで区別されてもよい。これらの手法によれば、RAN2若しくはCN3又は両方は、RRCコネクション再開手順がDoNASのためであることを認識できる。したがって、例えば、RAN2及びCN3は、DoNAS送信に必要とされないS1-Uベアラを再開するためのシグナリング(ステップ509及び510)を行わないように動作できる。
さらに、図4の例と同様に図5の例においても、SMSデータがDoNAS送信される場合、UE1のNASレイヤは、SMSデータを運ぶNASメッセージを生成するとともに、モバイルからのSMS送信を示すコールタイプ(i.e., originating SMS)と、DoNASのための新たな確立要因(e.g., mo-Data-DoNAS)とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。さらに、non-IPデータがDoNAS送信される場合、UE1のNASレイヤは、non-IPデータを運ぶNASメッセージを生成するとともに、モバイルからのnon-IPデータ送信を示す新たなコールタイプ(i.e., originating Non-IP call)と、DoNASのための新たな確立要因(e.g., mo-Data-DoNAS)とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。
<第4の実施形態>
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
図6は、本実施形態に係る通信手順の一例を示すシーケンス図である。図6の手順は、上述の図5の手順と類似している。しかしながら、図6の手順では、DoNASデータ送信のためにRRCコネクション再開手順(図5のステップ504〜506)の代わりに、RRCコネクション確立手順(ステップ604〜606)が使用される。
図6のステップ601及び602は、図5のステップ501及び502と同様である。ステップ601において、UE1は、第1の通信アーキテクチャ・タイプ(ソリューション2)及び第2の通信アーキテクチャ・タイプ(ソリューション18)の両方を使用するようにCN3(e.g., MME、C-SGN)によって設定される。さらに、ステップ501では、UE1は、第2の通信アーキテクチャ・タイプのための休止(suspension)動作を実行している。
ステップ602では、第1の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに、第1の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出(判定)する。第1の実施形態で説明したように、データ送信の要求は、上位レイヤ(e.g., service/application layer、IMSレイヤ、NASレイヤ)から下位レイヤ(e.g., NASレイヤ、ASレイヤ)への要求、又は下位レイヤ(e.g., ASレイヤ)から上位レイヤ(e.g., NASレイヤ)への要求である。なお、図6の例では、UE1は、SMS送信をトリガーされる。ステップ402及び502に関して説明したのと同様に、SMS送信は第1の通信アーキテクチャ・タイプに適した送信の一例である。
ステップ603では、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに第1の通信アーキテクチャ・タイプに従うデータ送信(e.g., SMS送信)の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ送信)を開始する。図6に示された具体例では、UE1のNASレイヤは、RRCコネクション確立手順と統合された(結合された)DoNAS送信手順を実行する(ステップ604〜606)。
ステップ604〜606では、RRCコネクションが確立されると同時に、SMSデータを運ぶNASメッセージがUE1からRAN2に送信される。ステップ604では、UE1は、RRC Connection RequestメッセージをRAN2(e.g., eNB、CIoT-BS)に送信する。なお、図6は、ランダム・アクセス手順の記載を省略している。ステップ604のRRC Connection Requestメッセージは、ランダム・アクセス手順の第3メッセージ(Msg3)で送信されてもよい。ステップ605では、RAN2は、RRC Connection SetupメッセージをUE1に送信する。ステップ606では、UE1は、RRC Connection Setup CompleteメッセージをRAN2に送信する。ステップ506のRRC Connection Setup Completeメッセージは、SMSデータを運ぶNASメッセージを包含する。
ステップ607では、RAN2は、S1APメッセージ(e.g., Initial UE Message)を用いて、SMSデータを運ぶNASメッセージをCN3(e.g., MME、C-SGN)に送る。ステップ607のS1APメッセージ内のNAS-PDUは、SMSデータを運ぶNASメッセージを包含する。RAN2は、第1の通信アーキテクチャ・タイプに対応するDCNをCN3内から選択し、S1APメッセージを選択されたDCNに送信してもよい。
ステップ608では、CN3(e.g., MME, C-SGN)は、スモールデータを得るために、UE1からのアップリンクNASメッセージを復号化(decrypt)する。CN3は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図6の例では、CN3は、取り出したSMSデータをSMSに関するエンティティ(e.g., SMS-GMSC、SMS-IWMSC、SMS router)に送る。
以上の説明から理解されるように、図6の例では、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに第1の通信アーキテクチャ・タイプに従うデータ送信(e.g., SMS送信)の要求が発生したことに応答して、以前のRRCコネクション・コンテキストを保持したまま第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ送信)を開始する。したがって、図4及び図5の例と同様に、UE1は、第2の通信アーキテクチャ・タイプに関する休止動作をしているときにNAS上でのデータ送信が発生しても、第2の通信アーキテクチャ・タイプに関する休止動作を継続できる。
さらに、図6の例では、UE1は、RRC コネクション確立手順と統合された(結合された)DoNAS送信手順を実行する。したがって、図6の例は、図4の例と比べて、DoNAS送信に必要なシグナリングの回数を削減できる。
なお、図4の例と同様に図6の例においても、UE1は、アップリンクRRCメッセージ(ステップ604及び606)のいずれか又は全てにDoNAS送信であることを示す表示(indication)を含めてもよい。さらに又はこれに代えて、UE1は、スモールデータ(e.g., SMSデータ)を運ぶNASメッセージにDoNAS送信であることを示す表示(indication)を含めてもよい。さらに又はこれに代えて、UE1は、これらのアップリンクRRCメッセージのいずれか又は全てに、バッファ量に関する情報(buffer status)を含めてもよい。さらに又はこれに代えて、ランダムアクセスのプリアンブル送信に使用される無線リソース(e.g., time, frequency, preamble index pool)が予め第1の通信アーキテクチャ・タイプと第2の通信アーキテクチャとで区別されてもよい。これにより、RAN2若しくはCN3又は両方は、RRCコネクション再開手順がDoNASのためであることを認識できる。
さらに、図4の例と同様に図6の例においても、SMSデータがDoNAS送信される場合、UE1のNASレイヤは、SMSデータを運ぶNASメッセージを生成するとともに、モバイルからのSMS送信を示すコールタイプ(i.e., originating SMS)と、DoNASのための新たな確立要因(e.g., mo-Data-DoNAS)とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。さらに、non-IPデータがDoNAS送信される場合、UE1のNASレイヤは、non-IPデータを運ぶNASメッセージを生成するとともに、モバイルからのnon-IPデータ送信を示す新たなコールタイプ(i.e., originating Non-IP call)と、DoNASのための新たな確立要因(e.g., mo-Data-DoNAS)とを包含するRRCコネクション確立の要求をASレイヤに供給してもよい。
本実施形態では、UE1が、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに、以前のRRCコネクション・コンテキストを保持したまま第1の通信アーキテクチャ・タイプに従う通信を開始する例を示した。UE1は、第1の通信アーキテクチャ・タイプの通信を終了して再びRRC-Idleモードに遷移した後、第2の通信アーキテクチャ・タイプによるデータ送信を行うために当該RRCコネクション・コンテキストを用いてRRCコネクションを再開してもよい。
これに代えて、本実施形態において、UE1は、第1の通信アーキテクチャ・タイプに従うデータ送信を行うためにRRCコネクションを確立するときに以前のRRCコネクション・コンテキストを解放(破棄)してもよい。
<第5の実施形態>
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
図7は、本実施形態に係る通信手順の一例を示すシーケンス図である。図7の手順は、UE1が、第1及び第2の通信アーキテクチャ・タイプの両方を使用するようにCN3(e.g., MME、C-SGN)によって設定され、且つRRC_Connected状態であるときにDoNAS送信を行う例を示している。
ステップ701において、UE1は、第1の通信アーキテクチャ・タイプ(ソリューション2)及び第2の通信アーキテクチャ・タイプ(ソリューション18)の両方を使用するようにCN3(e.g., MME、C-SGN)によって設定される。ステップ702では、UE1がRRC_Connected状態であるときに、第1の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE1は、第2の通信アーキテクチャ・タイプに従い且つRRC_Connected状態であるときに、第1の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出(判定)する。第1の実施形態で説明したように、データ送信の要求は、上位レイヤ(e.g., service/application layer、IMSレイヤ、NASレイヤ)から下位レイヤ(e.g., NASレイヤ、ASレイヤ)への要求、又は下位レイヤ(e.g., ASレイヤ)から上位レイヤ(e.g., NASレイヤ)への要求である。
ステップ703では、UE1のNASレイヤは、第2の通信アーキテクチャ・タイプに従い且つRRC_Connected状態であるときに第1の通信アーキテクチャ・タイプに従うデータ送信(e.g., SMS送信)の要求が発生したことに応答して、第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ送信)を開始する。ステップ704では、UE1のASレイヤは、UE1のNASレイヤからの要求に応答して、ランダム・アクセス手順を実行し、当該ランダム・アクセス手順の第3メッセージ(Msg3)でDoNAS要求(DoNAS request)をRAN2(e.g., eNB、CIoT-BS)に送信する。
ステップ705では、RAN2は、DoNAS要求の受信に応答して、アップリンク(UL)グラント(UL grant)をUE1に送信する。当該UL グラントは、DoNASのためのNASメッセージの送信をUE1に可能とするためのアップリンク無線リソースの割り当てを示す。ステップ706では、UE1は、ULグラント(ステップ706)に従って、SMSデータを運ぶNASメッセージを包含するRRCメッセージ(e.g., UL Information Transfer)をRAN2に送信する。なお、既に説明したように、現時点では、ソリューション2及びソリューション18が共にSRB 2を使用しないことが想定されている。したがって、ステップ706のRRCメッセージは、Dedicated Control Channel(DCCH)上のSRB 1を用いて送信されもよい。
ステップ707では、RAN2は、ステップ706のRRCメッセージから取り出されたNASメッセージをCN3(e.g., C-SGN、MME)にS1APメッセージ(e.g., Uplink NAS Transport)を用いて送信する。NASメッセージは、S1APメッセージのNAS- Protocol Data Unit (PDU) IE(情報要素)に埋め込まれる。なお、RAN2は、第1の通信アーキテクチャ・タイプに対応するDCNをCN3内から選択し、S1APメッセージを選択されたDCNに送信してもよい。
ステップ708では、CN3(e.g., MME, C-SGN)は、スモールデータを得るために、UE1からのアップリンクNASメッセージを復号化(decrypt)する。CN3は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図7の例では、CN3は、取り出したSMSデータをSMSに関するエンティティ(e.g., SMS-GMSC、SMS-IWMSC、SMS router)に送る。
以上の説明から理解されるように、図7の例では、UE1は、第1及び第2の通信アーキテクチャ・タイプを使用できるようにCN3により設定されており、且つRRC_Connected状態であるときに、コントロールプレーン上の転送が効果的と考えられる所定のデータ送信に関して第1の通信アーキテクチャ・タイプを使用するよう動作できる。
いくつかの実装において、図7のステップ704で送信されるDoNAS要求は、Physical Uplink Control Channel(PUCCH)上で送信されてもよい。当該DONAS要求は、DoNAS要求のために新たに定義された又は修正されたUplink Control Information(UCI)フォーマットによって運ばれてもよい。UE1が使用可能なPUCCHリソースを有する場合、UE1は、ランダム・アクセス手順を行わずにPUCCHでDoNAS要求を送信してもよい。
いくつかの実装において、図7のステップ704で送信されるDoNAS要求は、RRCメッセージを用いて送信されてもよい。このRRCメッセージは、DoNASの確立要因(establishment cause)を示してもよい。同様に、ステップ706のRRCメッセージ(e.g., UL Information Transfer)は、、DoNASの確立要因(establishment cause)を示してもよい。
<第6の実施形態>
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
本実施形態では、UE1は、第1の通信アーキテクチャ・タイプ及び第2の通信アーキテクチャ・タイプのいずれか一方を使用するようにCN3によって設定され、第1及び第2の通信アーキテクチャ・タイプの両方を同時に使用するように設定されないよう構成されている。
図8は、本実施形態に係る通信手順の一例を示すシーケンス図である。図8の手順では、ステップ801において、UE1は、第2の通信アーキテクチャ・タイプ(ソリューション18)のみを使用するようにCN3(e.g., MME、C-SGN)によって設定される。CN3は、所定の条件(pre-configured criterion)が成立する場合に第1の通信アーキテクチャ・タイプ(ソリューション2)の使用をUE1に許可してもよい。
ステップ802では、UE1は、所定の条件(pre-configured criterion)の成立を判定する。言い換えると、ステップ802では、UE1のNASレイヤは、所定のデータ送信の要求を上位レイヤ(e.g., service/application layer、IMSレイヤ)から受信したかを判定する。当該所定の条件又は所定のデータ送信の要求は、第1の通信アーキテクチャ・タイプに従うデータ送信(i.e., NAS上でのデータ送信)をUE1にトリガーする。
UE1は、UE1が第2の通信アーキテクチャ・タイプを使用することをCN3によって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、第2の通信アーキテクチャ・タイプから第1の通信アーキテクチャ・タイプに切り替え、第1の通信アーキテクチャ・タイプを使用してデータを送信する。第1の通信アーキテクチャ・タイプに従うデータ送信は、非特許文献1に示されたソリューション2(DoNAS)のMobile Originated(MO)スモールデータ送信手順と同様であってもよい。
すなわち、ステップ803では、UE1のNASレイヤは、NASレイヤ上でデータ送信を行うためのDoNAS手順を開始する。ステップ804では、UE1は、スモールデータを運ぶNASメッセージを生成し、当該NASメッセージを包含するRRCメッセージ(e.g., RRC Connection Setup Complete、UL Information Transfer)をRAN2(e.g., CIoT-BS、eNB)に送信する。
ステップ805では、RAN2は、当該RRCメッセージを受信し、当該RRCメッセージから取り出されたNASメッセージをCN3(e.g., C-SGN、MME)にS1APメッセージ(e.g., Initial UE Message、Uplink NAS Transport)を用いて送信する。NASメッセージは、S1APメッセージのNAS- Protocol Data Unit (PDU) IE(情報要素)に埋め込まれる。RAN2は、第1の通信アーキテクチャ・タイプに対応するDCNをCN3内から選択し、S1APメッセージを選択されたDCNに送信してもよい。
ステップ806では、CN3(e.g., C-SGN、MME)は、スモールデータを得るために、UE1からのアップリンクNASメッセージを復号化(decrypt)する。CN3は、スモールデータのデータタイプに依存して、スモールデータを他のノード、エンティティ、又はネットワークにフォワードする。
図8の例において、所定のデータ送信は、第1の実施形態で説明された図3の例のそれと同様であってもよい。例えば、所定のデータ送信は、非IP(non-IP)データ送信、SMSデータ送信、1パケットのみの(IP)データ送信、又は予め定められたサービスに関するデータ送信であってもよい。
図8の例によれば、UE1は、第2の通信アーキテクチャ・タイプを使用するようCN3によって既に設定されているときに、コントロールプレーン上の転送が効果的と考えられるデータ種別の送信に関して第1の通信アーキテクチャ・タイプを使用するよう動作できる。したがって、UE1が第2の通信アーキテクチャ・タイプを使用するようCN3によって既に設定されているときに、第1の通信アーキテクチャ・タイプの通信を効果的に行うことができる。
具体的には、UE1は、第2の通信アーキテクチャ・タイプのみを使用するようにCN3によって設定されいるときに所定のデータ送信の要求が発生したことに応答して、第2の通信アーキテクチャ・タイプから第1の通信アーキテクチャ・タイプに切り替える。すなわち、UE1は、第1及び第2の通信アーキテクチャ・タイプのいずれか一方のみを設定され、2つのソリューションの同時設定をサポートする必要がない。したがって、UE1の構成を簡単にできる。このような構成は、コスト最適化及び低消費電力が要求されるNB-CIoTに特に有効である。
<第7の実施形態>
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
図9は、本実施形態に係る通信手順の一例を示すシーケンス図である。図9の手順では、図8の手順と同様に、ステップ901において、UE1は、第2の通信アーキテクチャ・タイプ(ソリューション18)のみを使用するようにCN3(e.g., MME、C-SGN)によって設定される。CN3は、所定の条件(pre-configured criterion)が成立する場合に第1の通信アーキテクチャ・タイプ(ソリューション2)の使用をUE1に許可してもよい。さらに、ステップ901では、UE1は、第2の通信アーキテクチャ・タイプのための休止(suspension)動作を実行している。すなわち、UE1は、RRCアイドル状態(e.g., CIoT RRC idle状態)において、以前のRRCコネクションに関するコンテキストを保持している。
ステップ902では、第1の通信アーキテクチャ・タイプに従うデータ送信がトリガーされる。すなわち、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに、第1の通信アーキテクチャ・タイプに従うデータ送信の要求の発生を検出(判定)する。第1の実施形態で説明したように、データ送信の要求は、上位レイヤ(e.g., service/application layer、IMSレイヤ、NASレイヤ)から下位レイヤ(e.g., NASレイヤ、ASレイヤ)への要求、又は下位レイヤ(e.g., ASレイヤ)から上位レイヤ(e.g., NASレイヤ)への要求である。なお、図9の例では、UE1は、SMS送信をトリガーされる。なお、SMS送信は第1の通信アーキテクチャ・タイプに適した送信の一例である。第1の実施形態で説明されたように、ステップ902では、UE1は、非IP(non-IP)データ送信、1パケットのみの(IP)データ送信、又は予め定められたサービスに関するデータ送信をトリガーされてもよい。
ステップ903では、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに第1の通信アーキテクチャ・タイプに従うデータ送信(e.g., SMS送信)の要求が発生したことに応答して、第2の通信アーキテクチャ・タイプから第1の通信アーキテクチャ・タイプに切り替え、第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ送信)を開始する。第1の通信アーキテクチャ・タイプに従うデータ送信は、非特許文献1に示されたソリューション2(DoNAS)のMobile Originated(MO)スモールデータ送信手順と同様であってもよい。
すなわち、ステップ904〜906では、UE1は、RRCコネクション確立手順を実行する。ステップ904〜906では、RRCコネクションが確立されると同時に、SMSデータを運ぶNASメッセージがUE1からRAN2に送信される。ステップ904では、UE1は、RRC Connection RequestメッセージをRAN2(e.g., eNB、CIoT-BS)に送信する。なお、図9は、ランダム・アクセス手順の記載を省略している。ステップ904のRRC Connection Requestメッセージは、ランダム・アクセス手順の第3メッセージ(Msg3)で送信されてもよい。ステップ905では、RAN2は、RRC Connection SetupメッセージをUE1に送信する。ステップ906では、UE1は、RRC Connection Setup CompleteメッセージをRAN2に送信する。ステップ906のRRC Connection Setup Completeメッセージは、SMSデータを運ぶNASメッセージを包含する。
ステップ907では、RAN2は、S1APメッセージ(e.g., Initial UE Message)を用いて、SMSデータを運ぶNASメッセージをCN3(e.g., MME、C-SGN)に送る。ステップ907のS1APメッセージ内のNAS-PDUは、SMSデータを運ぶNASメッセージを包含する。RAN2は、第1の通信アーキテクチャ・タイプに対応するDCNをCN3内から選択し、S1APメッセージを選択されたDCNに送信してもよい。
ステップ908では、CN3(e.g., MME, C-SGN)は、スモールデータを得るために、UE1からのアップリンクNASメッセージを復号化(decrypt)する。CN3は、スモールデータのデータタイプに依存して、スモールデータパケットを他のノード、エンティティ、又はネットワークにフォワードする。図9の例では、CN3は、取り出したSMSデータをSMSに関するエンティティ(e.g., SMS-GMSC、SMS-IWMSC、SMS router)に送る。
いくつかの実装において、UE1は、第1の通信アーキテクチャに従うデータ送信(ステップ903)を開始する場合に、第2の通信アーキテクチャ・タイプの休止動作のために保持されている以前のRRCコネクション・コンテキストを削除又は解放してもよい。当該RRCコネクション・コンテキストが格納されていたメモリ領域は、第1の通信アーキテクチャ・タイプに従う通信のRRCコネクション・コンテキストを格納するために再利用されてもよい。言い換えると、第2の通信アーキテクチャ・タイプの休止動作のたmねの以前のRRCコネクション・コンテキストは、第1の通信アーキテクチャ・タイプに従う通信の新たなRRCコネクション・コンテキストによって上書き(更新)されてもよい。このような構成及び動作によれば、UE1が持つべきメモリ容量を削減でき、コスト最適化及び低消費電力が要求されるNB-CIoTに特に有効である。
なお、第2の通信アーキテクチャ・タイプの休止動作のためにUE1に保持されている以前のRRCコネクション・コンテキストを削除又は解放される場合、UE1は、当該削除又は解放をRAN2若しくはCN3又は両方に通知してもよい。具体的には、UE1は、第1の通信アーキテクチャ・タイプに従う通信を開始するための制御手順(ステップ904〜907)において、RRCコネクション・コンテキストの破棄を示す表示(indication)をネットワーク(i.e., RAN2若しくはCN3又は両方)に送信してもよい。例えば、UE1は、RRCメッセージ(e.g., RRC Connection Request、RRC Connection Setup Complete)若しくはNASメッセージ又は両方に当該表示を含めてもよい。
RAN2は、UE1からの当該表示の受信に応答して、休止動作のためにRAN2内に保持されている情報(RRCコネクション・コンテキスト、S1AP関係、S1-Uベアラ・コンテキスト)の破棄又は解放が許容されることを認識してもよい。同様に、CN3は、UE1からの当該表示の受信に応答して、休止動作のためにCN3内に保持されている情報(S1AP関係、S1-Uベアラ・コンテキスト)の破棄又は解放が許容されることを認識してもよい。このような構成及び動作によれば、UE1とネットワークとの間で休止状態の不一致が発生することを回避できる。
これに代えて、UE1は、第1の通信アーキテクチャに従うデータ送信(ステップ903)を開始する場合に、第2の通信アーキテクチャ・タイプの休止動作のために保持されている以前のRRCコネクション・コンテキストを保持し続けてもよい。
図10は、本実施形態に係る通信手順の他の例を示すシーケンス図である。図10は、Mobile Terminated(MT)スモールデータ送信の例を示している。ステップ1001は、図9のステップ901と同様である。ステップ1002では、CN3(e.g., MME、C-SGN)は、UE1宛てのMobile-Terminated SMSデータの到着を示すページング・メッセージを受信する。なお、CN3は、ステップ1002において、SMSデータを受信してもよい。この場合、後述するステップ1008は省略されてもよい。
ステップ1003では、CN3は、ページング・メッセージをRAN2に送信する。具体的には、CN3は、UE1の1又は複数のトラキングエリアに属する1又は複数のセルに関連付けられた各eNB(又はCIoT-BS)にページング・メッセージを送信する。ステップ1004では、RAN2によってUE1が呼び出される(paged)。
ステップ1005では、UE1は、第2の通信アーキテクチャ・タイプのための休止動作を実行しているときに第1の通信アーキテクチャ・タイプに関するページングを受信したことに応答して、第2の通信アーキテクチャ・タイプから第1の通信アーキテクチャ・タイプに切り替え、第1の通信アーキテクチャ・タイプに従う通信(i.e., NAS上でのデータ受信)を開始する。ここで、第1の通信アーキテクチャ・タイプに関するページングは、例えば、第1の通信アーキテクチャ・タイプによるデータ送信が行われることを明示的に示す情報(e.g., 第1の通信アーキテクチャ・タイプか第2の通信アーキテクチャ・タイプかを示す情報、第1の通信アーキテクチャ・タイプであることを示す情報)、または暗示的(e.g., bearer ID)に示す情報を含んでもよい。これに代えて、UE1は、ページングを受けた場合には常に第1の通信アーキテクチャ・タイプを使用して応答するように構成されてもよい。
第1の通信アーキテクチャ・タイプに従うデータ送信は、非特許文献1に示されたソリューション2(DoNAS)のMobile Terminated(MO)スモールデータ送信手順と同様であってもよい。すなわち、ステップ1006では、UE1は、RRCコネクションを確立し、RRC Connection Setup Complete メッセージを用いてNASメッセージ(i.e., Service Request)をCN3に送信する(ステップ1007)。CN3は、SMSデータを受信し(ステップ1008)、当該SMSデータをNASメッセージ内にカプセル化し、当該NASメッセージをRAN2に送信する(ステップ1009)。RAN2は、SMSデータを運ぶNASメッセージをCN3から受信し、当該NASメッセージを包含するRRCメッセージ(e.g., DL Information Transfer)をUE1に送信する(ステップ1010)。既に説明したように、現時点では、ソリューション2及びソリューション18が共にSRB 2を使用しないことが想定されている。したがって、ステップ1010のRRCメッセージは、Dedicated Control Channel(DCCH)上のSRB 1を用いて送信されもよい。
なお、図9の例と同様に図10の例においても、第2の通信アーキテクチャ・タイプの休止動作のためにUE1に保持されている以前のRRCコネクション・コンテキストを削除又は解放される場合、UE1は、当該削除又は解放をRAN2若しくはCN3又は両方に通知してもよい。RAN2は、UE1からの当該表示の受信に応答して、休止動作のためにRAN2内に保持されている情報(RRCコネクション・コンテキスト、S1AP関係、S1-Uベアラ・コンテキスト)の破棄又は解放が許容されることを認識してもよい。同様に、CN3は、UE1からの当該表示の受信に応答して、休止動作のためにCN3内に保持されている情報(S1AP関係、S1-Uベアラ・コンテキスト)の破棄又は解放が許容されることを認識してもよい。このような構成及び動作によれば、UE1とネットワークとの間で休止状態の不一致が発生することを回避できる。
<第8の実施形態>
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
本実施形態に係る無線通信ネットワークの構成例は、図2と同様である。本実施形態に係るUE1は、CIoTデバイス(e.g., NB-IoT、LTE eMTC)であってもよいし、LTE、LTE-Advanced 及びこれらの改良に係るその他のUEであってもよい。
既に説明したように、現時点では、ソリューション2(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レイヤの幾つかの機能を提供しない。
上述のいくつかの実施形態では、第2の通信アーキテクチャ・タイプのための休止動作を実行している間に第1の通信アーキテクチャ・タイプに従うデータ送信を開始するために、UE1がRRC Connection Resume手順を実行する例を示した(e.g., 図4、図5)。第2の通信アーキテクチャ・タイプ(AS context caching、User Plane CIoT EPS optimisation)はASセキュリティを使用するため、RRC Connection Resume手順のいずれかの段階で、UE1及びRAN2はsecurity activation(confirmation)を実行する。したがって、UE1及びRAN2は、RRC Connection Resume手順において既にASセキュリティが有効化(activated)されている場合に、第1の通信アーキテクチャ・タイプ(DoNAS、Control Plane CIoT EPS optimisation)の通信にもASセキュリティ(integrity protection for SRB、chipering)を適用してもよい。
<第9の実施形態>
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以上のミリ波帯をサポートする。
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)と呼ばれるかもしれない。
上述した第1〜第8の実施形態は、LTE RATとNew 5G RATの密接なインターワーキングを提供する5G無線通信ネットワークに適用されてもよい。いくつかの実装において、UE1、RAN2、及びCN3は、第1〜第8の実施形態で説明されたいずれかのアタッチ手順をLTE RATにおいて実行し、 当該アタッチ手順において決定(選択)された通信アーキテクチャ・タイプに従うデータ送信をNew 5G RATにおいて行ってもよい。
例えば、第1の通信アーキテクチャ・タイプがUE1のために使用される場合、UE1は、LTEセルでのRRC Connection Setup Completeメッセージの代わりに、5GセルでのUL Informatin Transferメッセージを用いてデータを送信してもよいし、5GセルでのDL Information Transferメッセージを用いてデータを受信してもよい。例えば、第2の通信アーキテクチャ・タイプがUE1のために使用される場合、UE1、RAN2、及びCN3は、RRCコネクションの休止(suspension)及び再開(resumption)を5Gセルで実行してもよい。このとき、UE1及びRAN2は、LTEセルにおける通信のために接続しているコアネットワーク・ノードに加えて、LTEセルとは別のコアネットワーク・ノードにも接続するようにしてもよい。
最後に、上述の複数の実施形態に係るUE1、RAN2内のノード(e.g., CIoT BS、eNB)、及びCN3内のノード(e.g., C-SGN、MME)の構成例について説明する。図11は、UE1の構成例を示すブロック図である。Radio Frequency(RF)トランシーバ1101は、RAN2と通信するためにアナログRF信号処理を行う。RFトランシーバ1101により行われるアナログRF信号処理は、周波数アップコンバージョン、周波数ダウンコンバージョン、及び増幅を含む。RFトランシーバ1101は、アンテナ1102及びベースバンドプロセッサ1103と結合される。すなわち、RFトランシーバ1101は、変調シンボルデータ(又はOFDMシンボルデータ)をベースバンドプロセッサ1103から受信し、送信RF信号を生成し、送信RF信号をアンテナ1102に供給する。また、RFトランシーバ1101は、アンテナ1102によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをベースバンドプロセッサ1103に供給する。
ベースバンドプロセッサ1103は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。デジタルベースバンド信号処理は、(a) データ圧縮/復元、(b) データのセグメンテーション/コンカテネーション、(c) 伝送フォーマット(伝送フレーム)の生成/分解、(d) 伝送路符号化/復号化、(e) 変調(シンボルマッピング)/復調、及び(f) Inverse Fast Fourier Transform(IFFT)によるOFDMシンボルデータ(ベースバンドOFDM信号)の生成などを含む。一方、コントロールプレーン処理は、レイヤ1(e.g., 送信電力制御)、レイヤ2(e.g., 無線リソース管理、及びhybrid automatic repeat request(HARQ)処理)、及びレイヤ3(e.g., アタッチ、モビリティ、及び通話管理に関するシグナリング)の通信管理を含む。
例えば、LTEおよびLTE-Advancedの場合、ベースバンドプロセッサ1103によるデジタルベースバンド信号処理は、Packet Data Convergence Protocol(PDCP)レイヤ、Radio Link Control(RLC)レイヤ、Medium Access Control(MAC)レイヤ、およびPhysical(PHY)レイヤの信号処理を含んでもよい。また、ベースバンドプロセッサ1103によるコントロールプレーン処理は、Non-Access Stratum(NAS)プロトコル、RRCプロトコル、及びMAC Control Element(MAC CE)の処理を含んでもよい。
ベースバンドプロセッサ1103は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., Digital Signal Processor(DSP))とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., Central Processing Unit(CPU)、又はMicro Processing Unit(MPU))を含んでもよい。この場合、コントロールプレーン処理を行うプロトコルスタック・プロセッサは、後述するアプリケーションプロセッサ1104と共通化されてもよい。
アプリケーションプロセッサ1104は、CPU、MPU、マイクロプロセッサ、又はプロセッサコアとも呼ばれる。アプリケーションプロセッサ1104は、複数のプロセッサ(複数のプロセッサコア)を含んでもよい。アプリケーションプロセッサ1104は、メモリ1106又は図示されていないメモリから読み出されたシステムソフトウェアプログラム(Operating System(OS))及び様々なアプリケーションプログラム(例えば、通話アプリケーション、WEBブラウザ、メーラ、カメラ操作アプリケーション、音楽再生アプリケーション)を実行することによって、UE1の各種機能を実現する。
いくつかの実装において、図11に破線(1105)で示されているように、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのチップ上に集積されてもよい。言い換えると、ベースバンドプロセッサ1103及びアプリケーションプロセッサ1104は、1つのSystem on Chip(SoC)デバイス1105として実装されてもよい。SoCデバイスは、システムLarge Scale Integration(LSI)またはチップセットと呼ばれることもある。
メモリ1106は、揮発性メモリ若しくは不揮発性メモリ又はこれらの組合せである。メモリ1106は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory(SRAM)若しくはDynamic RAM(DRAM)又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory(MROM)、Electrically Erasable Programmable ROM(EEPROM)、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。例えば、メモリ1106は、ベースバンドプロセッサ1103、アプリケーションプロセッサ1104、及びSoC1105からアクセス可能な外部メモリデバイスを含んでもよい。メモリ1106は、ベースバンドプロセッサ1103内、アプリケーションプロセッサ1104内、又はSoC1105内に集積された内蔵メモリデバイスを含んでもよい。さらに、メモリ1106は、Universal Integrated Circuit Card(UICC)内のメモリを含んでもよい。
メモリ1106は、上述の複数の実施形態で説明されたUE1による処理を行うための命令群およびデータを含む1又は複数のソフトウェアモジュール(コンピュータプログラム)1107を格納してもよい。いくつかの実装において、ベースバンドプロセッサ1103又はアプリケーションプロセッサ1104は、当該1又は複数のソフトウェアモジュール1107をメモリ1106から読み出して実行することで、上述の実施形態で説明されたUE1の処理を行うよう構成されてもよい。
図12は、上述の実施形態に係るRAN2内のノード(e.g., CIoT BS、eNB)の構成例を示すブロック図である。図12を参照すると、当該ノードは、RFトランシーバ1201、ネットワークインターフェース1203、プロセッサ1204、及びメモリ1205を含む。RFトランシーバ1201は、無線端末1と通信するためにアナログRF信号処理を行う。RFトランシーバ1201は、複数のトランシーバを含んでもよい。RFトランシーバ1201は、アンテナ1202及びプロセッサ1204と結合される。RFトランシーバ1201は、変調シンボルデータ(又はOFDMシンボルデータ)をプロセッサ1204から受信し、送信RF信号を生成し、送信RF信号をアンテナ1202に供給する。また、RFトランシーバ1201は、アンテナ1202によって受信された受信RF信号に基づいてベースバンド受信信号を生成し、これをプロセッサ1204に供給する。
ネットワークインターフェース1203は、ネットワークノード(e.g., MME、C-SGN、S-GW)と通信するために使用される。ネットワークインターフェース1203は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード(NIC)を含んでもよい。
プロセッサ1204は、無線通信のためのデジタルベースバンド信号処理(データプレーン処理)とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ1204によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。また、プロセッサ1204によるコントロールプレーン処理は、S1プロトコル、RRCプロトコル、及びMAC CEの処理を含んでもよい。
プロセッサ1204は、複数のプロセッサを含んでもよい。例えば、プロセッサ1204は、デジタルベースバンド信号処理を行うモデム・プロセッサ(e.g., DSP)とコントロールプレーン処理を行うプロトコルスタック・プロセッサ(e.g., CPU又はMPU)を含んでもよい。
メモリ1205は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。メモリ1205は、プロセッサ1204から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1204は、ネットワークインターフェース1203又は図示されていないI/Oインタフェースを介してメモリ1205にアクセスしてもよい。
メモリ1205は、上述の複数の実施形態で説明されたRAN2内のノード(e.g., CIoT BS、eNB)による処理を行うための命令群およびデータを含む1又は複数のソフトウェアモジュール(コンピュータプログラム)1206を格納してもよい。いくつかの実装において、プロセッサ1204は、当該1又は複数のソフトウェアモジュール1206をメモリ1205から読み出して実行することで、上述の実施形態で説明されたRAN2内のノードの処理を行うよう構成されてもよい。
図13は、上述の実施形態に係るCN3内のノード(e.g., C-SGN、MME)の構成例を示すブロック図である。図13を参照すると、当該ノードは、ネットワークインターフェース1301、プロセッサ1302、及びメモリ1303を含む。ネットワークインターフェース1301は、ネットワークノード(e.g., C-SGN、MME、HSS、S-GW、P-GW、CIoT BS、eNB)と通信するために使用される。ネットワークインターフェース1301は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード(NIC)を含んでもよい。
プロセッサ1302は、メモリ1303から1又は複数のソフトウェアモジュール(コンピュータプログラム)1304を読み出して実行することで、上述の実施形態において説明されたCN3内のノード(e.g., C-SGN、MME)の処理を行う。プロセッサ1302は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ1302は、複数のプロセッサを含んでもよい。
メモリ1303は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ1303は、プロセッサ1302から離れて配置されたストレージを含んでもよい。この場合、プロセッサ1302は、図示されていないI/Oインタフェースを介してメモリ1303にアクセスしてもよい。
図11〜図13を用いて説明したように、上述の実施形態に係るUE1、RAN2内のノード、及びCN3内のノードが有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む1又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体(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)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
<その他の実施形態>
上述の実施形態は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。
上述の実施形態は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。
上述の実施形態では、UE1がRRC connection suspendしたセルから他のセルにサービングセルを変更する場合(e.g., cell reselection, detach後のattach)に、上述の実施形態で説明された機能を変更後のサービングセルにおいて利用できるか否かをUE1が判断できることが好ましいかもしれない。したがって、RAN2は、サービングセルにおいて当該機能がサポート(network support)されているか否か(又は許可されているか否か)を示す情報を報知してもよい。例えば、RAN2(e.g., eNB、CIoT-BS)は、RAN2内の各セルで当該情報を報知してもよい。当該情報は、その情報が報知されたセルが当該機能をサポートするか否かを示してもよい。更に当該情報は、隣接セルが当該機能をサポートしているか否かを示してもよい。
上述の実施形態で説明されたRAN2は、Cloud Radio Access Network(C-RAN)であってもよい。C-RANは、Centralized RANと呼ばれることもある。したがって、上述の実施形態で説明されたRAN2又はRAN2内の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)とも呼ばれる。すなわち、上述の実施形態で説明されたRAN2、CIoT BS、又はeNBによって行われる処理及び動作は、任意の1又は複数の無線局(RANノード)によって提供されてもよい。
さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。
例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
(付記A1)
無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第1の通信アーキテクチャ・タイプを使用してデータを送信するよう構成されている、
無線端末。
無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第1の通信アーキテクチャ・タイプを使用してデータを送信するよう構成されている、
無線端末。
(付記A2)
前記所定のデータ送信は、非Internet Protocol(non-IP)データ送信を含む、
付記A1に記載の無線端末。
前記所定のデータ送信は、非Internet Protocol(non-IP)データ送信を含む、
付記A1に記載の無線端末。
(付記A3)
前記所定のデータ送信は、Short Message Service(SMS)データ送信を含む、
付記A1又はA2に記載の無線端末。
前記所定のデータ送信は、Short Message Service(SMS)データ送信を含む、
付記A1又はA2に記載の無線端末。
(付記A4)
前記所定のデータ送信は、1パケットのみのデータ送信を含む、
付記A1〜3のいずれか1項に記載の無線端末。
前記所定のデータ送信は、1パケットのみのデータ送信を含む、
付記A1〜3のいずれか1項に記載の無線端末。
(付記A5)
前記所定のデータ送信は、予め定められたサービスに関するデータ送信を含む、
付記A1〜A4のいずれか1項に記載の無線端末。
前記所定のデータ送信は、予め定められたサービスに関するデータ送信を含む、
付記A1〜A4のいずれか1項に記載の無線端末。
(付記A6)
前記無線端末は、前記第1及び第2の通信アーキテクチャ・タイプの両方を使用するように前記ネットワークによって設定されるよう構成され、
前記少なくとも1つのプロセッサは、要求された通信が前記所定のデータ送信であるか否かに依存して、前記第1の通信アーキテクチャ・タイプ及び前記第2の通信アーキテクチャ・タイプのどちらを使用するかを決定するよう構成されている、
付記A1〜A5のいずれか1項に記載の無線端末。
前記無線端末は、前記第1及び第2の通信アーキテクチャ・タイプの両方を使用するように前記ネットワークによって設定されるよう構成され、
前記少なくとも1つのプロセッサは、要求された通信が前記所定のデータ送信であるか否かに依存して、前記第1の通信アーキテクチャ・タイプ及び前記第2の通信アーキテクチャ・タイプのどちらを使用するかを決定するよう構成されている、
付記A1〜A5のいずれか1項に記載の無線端末。
(付記A7)
前記無線端末は、前記第1の通信アーキテクチャ・タイプ及び前記第2の通信アーキテクチャ・タイプのいずれか一方を使用するように前記ネットワークによって設定され、前記第1及び第2の通信アーキテクチャ・タイプの両方を同時に使用するように設定されないよう構成され、
前記少なくとも1つのプロセッサは、前記所定のデータ送信の要求が発生したことに応答して、前記第2の通信アーキテクチャ・タイプから前記第1の通信アーキテクチャ・タイプに切り替えるよう構成されている、
付記A1〜A5のいずれか1項に記載の無線端末。
前記無線端末は、前記第1の通信アーキテクチャ・タイプ及び前記第2の通信アーキテクチャ・タイプのいずれか一方を使用するように前記ネットワークによって設定され、前記第1及び第2の通信アーキテクチャ・タイプの両方を同時に使用するように設定されないよう構成され、
前記少なくとも1つのプロセッサは、前記所定のデータ送信の要求が発生したことに応答して、前記第2の通信アーキテクチャ・タイプから前記第1の通信アーキテクチャ・タイプに切り替えるよう構成されている、
付記A1〜A5のいずれか1項に記載の無線端末。
(付記A8)
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第1の通信アーキテクチャ・タイプを使用してデータを送信することを備える、
方法。
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプを使用することをネットワークによって既に設定されているときに所定のデータ送信の要求が発生したことに応答して、前記第1の通信アーキテクチャ・タイプを使用してデータを送信することを備える、
方法。
(付記B1)
無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において、保持されていた保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを保持したまま前記1の通信アーキテクチャ・タイプに従う通信を開始するよう構成されている、
無線端末。
無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において、保持されていた保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを保持したまま前記1の通信アーキテクチャ・タイプに従う通信を開始するよう構成されている、
無線端末。
(付記B2)
前記少なくとも1つのプロセッサは、前記1の通信アーキテクチャ・タイプのデータを包含するNon-Access Stratum(NAS)メッセージを、前記RRCコネクションの前記再開のために使用されるRRCメッセージを用いて送信するよう構成され、
前記RRCメッセージは、Non-Access Stratum(NAS)上でのデータ送信を示す表示(indication)を含む、
付記B1に記載の無線端末。
前記少なくとも1つのプロセッサは、前記1の通信アーキテクチャ・タイプのデータを包含するNon-Access Stratum(NAS)メッセージを、前記RRCコネクションの前記再開のために使用されるRRCメッセージを用いて送信するよう構成され、
前記RRCメッセージは、Non-Access Stratum(NAS)上でのデータ送信を示す表示(indication)を含む、
付記B1に記載の無線端末。
(付記B3)
前記少なくとも1つのプロセッサは、前記1の通信アーキテクチャ・タイプのデータを包含するNon-Access Stratum(NAS)メッセージを、前記RRCコネクションの前記再開のために使用されるRRCメッセージを用いて送信するよう構成され、
前記NASメッセージは、Non-Access Stratum(NAS)上でのデータ送信を示す表示(indication)を含む、
付記B1又はB2に記載の無線端末。
前記少なくとも1つのプロセッサは、前記1の通信アーキテクチャ・タイプのデータを包含するNon-Access Stratum(NAS)メッセージを、前記RRCコネクションの前記再開のために使用されるRRCメッセージを用いて送信するよう構成され、
前記NASメッセージは、Non-Access Stratum(NAS)上でのデータ送信を示す表示(indication)を含む、
付記B1又はB2に記載の無線端末。
(付記B4)
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において、保持されていた保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを保持したまま前記1の通信アーキテクチャ・タイプに従う通信を開始することを備える、
方法。
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において、保持されていた保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを保持したまま前記1の通信アーキテクチャ・タイプに従う通信を開始することを備える、
方法。
(付記C1)
無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを破棄又は解放して前記1の通信アーキテクチャ・タイプに従う通信を開始するよう構成されている、
無線端末。
無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを破棄又は解放して前記1の通信アーキテクチャ・タイプに従う通信を開始するよう構成されている、
無線端末。
(付記C2)
前記少なくとも1つのプロセッサは、さらに、前記第1の通信アーキテクチャ・タイプに従う通信を開始するための制御手順において、前記コンテキストの破棄を示す表示(indication)をネットワークに送信するよう構成されている、
付記C1に記載の無線端末。
前記少なくとも1つのプロセッサは、さらに、前記第1の通信アーキテクチャ・タイプに従う通信を開始するための制御手順において、前記コンテキストの破棄を示す表示(indication)をネットワークに送信するよう構成されている、
付記C1に記載の無線端末。
(付記C3)
前記少なくとも1つのプロセッサは、前記制御手順において送信されるRRCメッセージ若しくはNon-Access Stratum(NAS)メッセージ又は両方に前記表示を含めるよう構成されている、
付記C2に記載の無線端末。
前記少なくとも1つのプロセッサは、前記制御手順において送信されるRRCメッセージ若しくはNon-Access Stratum(NAS)メッセージ又は両方に前記表示を含めるよう構成されている、
付記C2に記載の無線端末。
(付記C4)
無線アクセスネットワーク内の無線局であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションに関する第1のコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記第1のコンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信のためのRRCメッセージを前記無線端末から受信したことに応答して、前記第1のコンテキストの破棄又は解放が許容されることを認識するよう構成されている、
無線局。
無線アクセスネットワーク内の無線局であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションに関する第1のコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記第1のコンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信のためのRRCメッセージを前記無線端末から受信したことに応答して、前記第1のコンテキストの破棄又は解放が許容されることを認識するよう構成されている、
無線局。
(付記C5)
前記RRCメッセージは、前記休止のために前記無線端末で保持されていた第2のコンテキストの破棄又は解放を示す表示を含み、
前記少なくとも1つのプロセッサは、前記表示の受信に応答して前記第1のコンテキストの破棄又は解放が許容されることを認識するよう構成されている、
付記C4に記載の無線局。
前記RRCメッセージは、前記休止のために前記無線端末で保持されていた第2のコンテキストの破棄又は解放を示す表示を含み、
前記少なくとも1つのプロセッサは、前記表示の受信に応答して前記第1のコンテキストの破棄又は解放が許容されることを認識するよう構成されている、
付記C4に記載の無線局。
(付記C6)
コアネットワーク内のネットワーク装置であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、前記ネットワーク装置と無線局との間の前記無線端末のためのシグナリング関係(association)及び前記無線端末のためのベアラ・コンテキストを前記ネットワーク装置において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップに伴って、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストを再利用又は復元することを含み、
前記少なくとも1つのプロセッサは、さらに、前記ネットワーク装置が前記無線端末のための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信のための制御メッセージを前記無線端末又は前記無線局から受信したことに応答して、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識するよう構成されている、
ネットワーク装置。
コアネットワーク内のネットワーク装置であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、前記ネットワーク装置と無線局との間の前記無線端末のためのシグナリング関係(association)及び前記無線端末のためのベアラ・コンテキストを前記ネットワーク装置において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップに伴って、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストを再利用又は復元することを含み、
前記少なくとも1つのプロセッサは、さらに、前記ネットワーク装置が前記無線端末のための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信のための制御メッセージを前記無線端末又は前記無線局から受信したことに応答して、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識するよう構成されている、
ネットワーク装置。
(付記C7)
前記制御メッセージは、前記休止のために前記無線端末で保持されていたRRCコネクションに関する第2のコンテキストの破棄又は解放を示す表示を含み、
前記少なくとも1つのプロセッサは、前記表示の受信に応答して前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識するよう構成されている、
付記C6に記載のネットワーク装置。
前記制御メッセージは、前記休止のために前記無線端末で保持されていたRRCコネクションに関する第2のコンテキストの破棄又は解放を示す表示を含み、
前記少なくとも1つのプロセッサは、前記表示の受信に応答して前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識するよう構成されている、
付記C6に記載のネットワーク装置。
(付記C8)
前記制御メッセージは、Non-Access Stratum(NAS)メッセージ若しくはS1 Application Protocol(S1AP)メッセージ又は両方を含む、
付記C6又はC7に記載のネットワーク装置。
前記制御メッセージは、Non-Access Stratum(NAS)メッセージ若しくはS1 Application Protocol(S1AP)メッセージ又は両方を含む、
付記C6又はC7に記載のネットワーク装置。
(付記C9)
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを破棄又は解放して前記1の通信アーキテクチャ・タイプに従う通信を開始することを備える、
方法。
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信の要求が発生したことに応答して、前記コンテキストを破棄又は解放して前記1の通信アーキテクチャ・タイプに従う通信を開始することを備える、
方法。
(付記C10)
無線アクセスネットワーク内の無線局における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションに関する第1のコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記第1のコンテキストを再利用することを含み、
前記方法は、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信のためのRRCメッセージを前記無線端末から受信したことに応答して、前記第1のコンテキストの破棄又は解放が許容されることを認識することを備える、
方法。
無線アクセスネットワーク内の無線局における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションに関する第1のコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記第1のコンテキストを再利用することを含み、
前記方法は、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信のためのRRCメッセージを前記無線端末から受信したことに応答して、前記第1のコンテキストの破棄又は解放が許容されることを認識することを備える、
方法。
(付記C11)
コアネットワーク内のネットワーク装置における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、前記ネットワーク装置と無線局との間の前記無線端末のためのシグナリング関係(association)及び前記無線端末のためのベアラ・コンテキストを前記ネットワーク装置において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップに伴って、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストを再利用又は復元することを含み、
前記方法は、さらに、前記ネットワーク装置が前記無線端末のための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信のための制御メッセージを前記無線端末又は前記無線局から受信したことに応答して、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識することを備える、
方法。
コアネットワーク内のネットワーク装置における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、前記ネットワーク装置と無線局との間の前記無線端末のためのシグナリング関係(association)及び前記無線端末のためのベアラ・コンテキストを前記ネットワーク装置において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップに伴って、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストを再利用又は復元することを含み、
前記方法は、さらに、前記ネットワーク装置が前記無線端末のための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従うデータ送信のための制御メッセージを前記無線端末又は前記無線局から受信したことに応答して、保持されていた前記シグナリング関係及び前記ベアラ・コンテキストの破棄又は解放が許容されることを認識することを備える、
方法。
(付記D1)
無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従う所定のデータ送信の要求が発生したことに応答して、前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを送信するよう構成され、
前記RRCコネクション再開メッセージは、Non-Access Stratum(NAS)上でのデータ送信の確立要因(establishment cause)を示す、
無線端末。
無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従う所定のデータ送信の要求が発生したことに応答して、前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを送信するよう構成され、
前記RRCコネクション再開メッセージは、Non-Access Stratum(NAS)上でのデータ送信の確立要因(establishment cause)を示す、
無線端末。
(付記D2)
前記所定のデータ送信は、非Internet Protocol(non-IP)データ送信またはShort Message Service(SMS)送信であり、
前記少なくとも1つのプロセッサは、モビリティ管理及びセッション管理を提供するNASレイヤ及び無線リソース制御を提供するAccess Stratum (AS)レイヤとして動作するよう構成され、
前記NASレイヤは、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記所定のデータ送信の要求が発生したことに応答して、データを運ぶNASメッセージを生成するとともに、前記NAS上でのデータ送信の前記確立要因と前記所定の通信に関連付けられたコールタイプ(call type)とを包含するRRCコネクション確立の要求を前記ASレイヤに供給するよう構成されている、
付記D1に記載の無線端末。
前記所定のデータ送信は、非Internet Protocol(non-IP)データ送信またはShort Message Service(SMS)送信であり、
前記少なくとも1つのプロセッサは、モビリティ管理及びセッション管理を提供するNASレイヤ及び無線リソース制御を提供するAccess Stratum (AS)レイヤとして動作するよう構成され、
前記NASレイヤは、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記所定のデータ送信の要求が発生したことに応答して、データを運ぶNASメッセージを生成するとともに、前記NAS上でのデータ送信の前記確立要因と前記所定の通信に関連付けられたコールタイプ(call type)とを包含するRRCコネクション確立の要求を前記ASレイヤに供給するよう構成されている、
付記D1に記載の無線端末。
(付記D3)
無線アクセスネットワーク内の無線局であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションに関するコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを受信するよう構成され、
前記少なくとも1つのプロセッサは、さらに、前記RRCコネクション再開メッセージがNon-Access Stratum(NAS)上でのデータ送信の確立要因を示すことに応答して、前記第1の通信アーキテクチャ・タイプに従う通信であることを認識するよう構成されている、
無線局。
無線アクセスネットワーク内の無線局であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートするよう構成され、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションに関するコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを受信するよう構成され、
前記少なくとも1つのプロセッサは、さらに、前記RRCコネクション再開メッセージがNon-Access Stratum(NAS)上でのデータ送信の確立要因を示すことに応答して、前記第1の通信アーキテクチャ・タイプに従う通信であることを認識するよう構成されている、
無線局。
(付記D4)
前記RRCコネクションの前記休止は、前記無線端末が前記RRCアイドル状態であるときに、前記無線局とコアネットワークとの間の前記無線端末のためのベアラに関するベアラ・コンテキストを前記無線局及びコアネットワークにおいて保持することを更に含み、
前記RRCコネクションの前記再開は、前記その後の(subsequent)RRCコネクションのセットアップに伴って、前記ベアラ・コンテキストに基づいて前記ベアラを復元又は再利用することを更に含み、
前記少なくとも1つのプロセッサは、前記RRCコネクション再開メッセージがNon-Access Stratum(NAS)上でのデータ送信の確立要因を示す場合に、前記ベアラの復元又は再利用を前記コアネットワークに要求しないよう構成されている、
付記D3に記載の無線局。
前記RRCコネクションの前記休止は、前記無線端末が前記RRCアイドル状態であるときに、前記無線局とコアネットワークとの間の前記無線端末のためのベアラに関するベアラ・コンテキストを前記無線局及びコアネットワークにおいて保持することを更に含み、
前記RRCコネクションの前記再開は、前記その後の(subsequent)RRCコネクションのセットアップに伴って、前記ベアラ・コンテキストに基づいて前記ベアラを復元又は再利用することを更に含み、
前記少なくとも1つのプロセッサは、前記RRCコネクション再開メッセージがNon-Access Stratum(NAS)上でのデータ送信の確立要因を示す場合に、前記ベアラの復元又は再利用を前記コアネットワークに要求しないよう構成されている、
付記D3に記載の無線局。
(付記D5)
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従う所定のデータ送信の要求が発生したことに応答して、前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを送信することを備え、
前記RRCコネクション再開メッセージは、Non-Access Stratum(NAS)上でのデータ送信の確立要因(establishment cause)を示す、
方法。
無線端末における方法であって、
複数の通信アーキテクチャ・タイプのうち少なくとも1つをネットワークによって設定されることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの休止は、前記無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションのコンテキストを前記無線端末において保持することを含み、
前記RRCコネクションの再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記方法は、さらに、前記無線端末が前記第2の通信アーキテクチャ・タイプのための前記休止を実行しているときに前記第1の通信アーキテクチャ・タイプに従う所定のデータ送信の要求が発生したことに応答して、前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを送信することを備え、
前記RRCコネクション再開メッセージは、Non-Access Stratum(NAS)上でのデータ送信の確立要因(establishment cause)を示す、
方法。
(付記D6)
無線アクセスネットワーク内の無線局における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションに関するコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを受信するよう構成され、
前記方法は、さらに、前記RRCコネクション再開メッセージがNon-Access Stratum(NAS)上でのデータ送信の確立要因を示すことに応答して、前記第1の通信アーキテクチャ・タイプに従う通信であることを認識することを備える、
方法。
無線アクセスネットワーク内の無線局における方法であって、
複数の通信アーキテクチャ・タイプをサポートすることを備え、
前記複数の通信アーキテクチャ・タイプは、(a)データパケットがコントロールプレーンを介して送信される第1の通信アーキテクチャ・タイプ、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴う第2の通信アーキテクチャ・タイプを含み、
前記RRCコネクションの前記休止は、無線端末がRRCアイドル状態であるときに、以前の(previous)RRCコネクションに関するコンテキストを前記無線局において保持することを含み、
前記RRCコネクションの前記再開は、前記無線端末が前記RRCアイドル状態からRRCコネクテッド状態に遷移するためのその後の(subsequent)RRCコネクションのセットアップの際に、保持されていた前記コンテキストを再利用することを含み、
前記少なくとも1つのプロセッサは、さらに、前記無線局が前記無線端末のための前記休止を実行しているときに前記RRCコネクションの前記再開のために使用されるRRCコネクション再開メッセージを受信するよう構成され、
前記方法は、さらに、前記RRCコネクション再開メッセージがNon-Access Stratum(NAS)上でのデータ送信の確立要因を示すことに応答して、前記第1の通信アーキテクチャ・タイプに従う通信であることを認識することを備える、
方法。
この出願は、2016年2月4日に出願された日本出願特願2016−020291を基礎とする優先権を主張し、その開示の全てをここに取り込む。
1 User Equipment(UE)
2 Radio Access Network(RAN)
3 Core Network(CN)
4 アプリケーションサーバ
6 Serving Gateway(S-GW)/Packet Data Network Gateway(P-GW)
1103 ベースバンドプロセッサ
1104 アプリケーションプロセッサ
1106 メモリ
1204 プロセッサ
1205 メモリ
1302 プロセッサ
1303 メモリ
2 Radio Access Network(RAN)
3 Core Network(CN)
4 アプリケーションサーバ
6 Serving Gateway(S-GW)/Packet Data Network Gateway(P-GW)
1103 ベースバンドプロセッサ
1104 アプリケーションプロセッサ
1106 メモリ
1204 プロセッサ
1205 メモリ
1302 プロセッサ
1303 メモリ
Claims (9)
- 無線端末であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと、
を備え、
前記少なくとも1つのプロセッサは、複数の通信アーキテクチャ・タイプをサポートし、
前記複数の通信アーキテクチャ・タイプは、(a)Control Plane CIoT EPS Optimisation、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴うUser Plane CIoT EPS Optimisationを含み、
Access Stratum(AS)コンテキストを保持しつつRRCコネクションを解放することで前記RRCコネクションは休止され、
前記RRCコネクションの再開は、前記無線端末がRRCアイドル状態からRRCコネクテッド状態に遷移するときに前記保持されていたASコンテキストを用いて実行され、
前記少なくとも1つのプロセッサは、前記無線端末が前記User Plane CIoT EPS Optimisationのための前記休止を実行しているときに、前記Control Plane CIoT EPS Optimisationに従う所定のデータ送信を行う場合、前記RRCコネクションの再開手順を開始し、前記再開手順に基づく前記RRCコネクションの再開後に又は前記再開手順の間に、前記所定のデータ送信のデータを運ぶNon-Access Stratum(NAS)メッセージを包含するRRCメッセージを送信する、
無線端末。 - 前記少なくとも1つのプロセッサは、前記無線端末が前記User Plane CIoT EPS Optimisationのための前記RRCコネクションの休止を実行しているときに前記Control Plane CIoT EPS Optimisationに従う通信を開始する場合に、前記RRCコネクションの前記再開手順を実行してRRCコネクテッド状態に遷移した後に、前記RRCメッセージを送信する、
請求項1に記載の無線端末。 - 前記RRCメッセージは、前記再開手順の間に前記RRCコネクションの再開のために使用される、請求項1又は2に記載の無線端末。
- 前記RRCメッセージは、RRC Connection Resume Completeメッセージ、又はRRC Connection Resume Requestメッセージである、請求項3に記載の無線端末。
- 前記RRCメッセージは、前記再開手順の後に送信されるUL Information Transferメッセージである、
請求項1又は2に記載の無線端末。 - 前記少なくとも1つのプロセッサは、前記無線端末が前記User Plane CIoT EPS Optimisationための前記RRCコネクションの休止を実行しているときに前記Control Plane CIoT EPS Optimisationに従う通信を開始する場合に、前記再開手順においてRRCコネクション再開メッセージを送信するよう構成され、
前記RRCコネクション再開メッセージは、Non-Access Stratum(NAS)上での所定のデータ送信の確立要因(establishment cause)を示す情報要素を含む、
請求項5に記載の無線端末。 - 前記所定のデータ送信は、非Internet Protocol(non-IP)データ送信またはShort Message Service(SMS)送信であり、
前記少なくとも1つのプロセッサは、モビリティ管理及びセッション管理を提供するNASレイヤ及び無線リソース制御を提供するAccess Stratum (AS)レイヤとして動作するよう構成され、
前記NASレイヤは、前記無線端末が前記User Plane CIoT EPS Optimisationのための前記RRCコネクションの休止を実行しているときに前記所定のデータ送信の要求が発生したことに応答して、前記NASメッセージを生成するとともに、前記NAS上でのデータ送信の前記確立要因と前記所定の通信に関連付けられたコールタイプ(call type)とを包含するRRCコネクション確立の要求を前記ASレイヤに供給するよう構成されている、
請求項6に記載の無線端末。 - 複数の通信アーキテクチャ・タイプをサポートし、
前記複数の通信アーキテクチャ・タイプは、(a)Control Plane CIoT EPS Optimisation、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴うUser Plane CIoT EPS Optimisationを含み、
Access Stratum(AS)コンテキストを保持しつつRRCコネクションを解放することで前記RRCコネクションは休止され、
前記RRCコネクションの再開は、無線端末がRRCアイドル状態からRRCコネクテッド状態に遷移するときに前記保持されていたASコンテキストを用いて実行され、
前記無線端末が前記User Plane CIoT EPS Optimisationのための前記休止を実行しているときに、前記Control Plane CIoT EPS Optimisationに従う所定のデータ送信を行う場合、前記RRCコネクションの再開手順を開始し、前記再開手順に基づく前記RRCコネクションの再開後に又は前記再開手順の間に、前記所定のデータ送信のデータを運ぶNon-Access Stratum(NAS)メッセージを包含するRRCメッセージを送信する、
無線端末の方法。 - 複数の通信アーキテクチャ・タイプをサポートし、
前記複数の通信アーキテクチャ・タイプは、(a)Control Plane CIoT EPS Optimisation、及び(b)データパケットがユーザプレーンを介して送信され且つRadio Resource Control(RRC)コネクションの休止(suspension)及び再開(resumption)を伴うUser Plane CIoT EPS Optimisationを含み、
Access Stratum(AS)コンテキストを保持しつつRRCコネクションを解放することで前記RRCコネクションは休止され、
前記RRCコネクションの再開は、無線端末がRRCアイドル状態からRRCコネクテッド状態に遷移するときに前記保持されていたASコンテキストを用いて実行され、
前記無線端末が前記User Plane CIoT EPS Optimisationのための前記休止を実行しているときに、前記Control Plane CIoT EPS Optimisationに従う所定のデータ送信が行われる場合、前記RRCコネクションの再開手順を開始し、前記再開手順に基づく前記RRCコネクションの再開後に又は前記再開手順の間に、前記所定のデータ送信のデータを運ぶNon-Access Stratum(NAS)メッセージを包含するRRCメッセージを受信する、
基地局の方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021211784A JP7306444B2 (ja) | 2016-02-04 | 2021-12-27 | 無線端末及びその方法 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016020291 | 2016-02-04 | ||
JP2016020291 | 2016-02-04 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019165025A Division JP6787459B2 (ja) | 2016-02-04 | 2019-09-11 | 無線端末 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021211784A Division JP7306444B2 (ja) | 2016-02-04 | 2021-12-27 | 無線端末及びその方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2021036679A true JP2021036679A (ja) | 2021-03-04 |
JP7006752B2 JP7006752B2 (ja) | 2022-01-24 |
Family
ID=59499493
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017565424A Active JP6587001B2 (ja) | 2016-02-04 | 2016-12-15 | 無線端末及びその方法 |
JP2019165025A Active JP6787459B2 (ja) | 2016-02-04 | 2019-09-11 | 無線端末 |
JP2020175871A Active JP7006752B2 (ja) | 2016-02-04 | 2020-10-20 | 無線端末、無線端末の方法、及び基地局の方法 |
JP2021211784A Active JP7306444B2 (ja) | 2016-02-04 | 2021-12-27 | 無線端末及びその方法 |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017565424A Active JP6587001B2 (ja) | 2016-02-04 | 2016-12-15 | 無線端末及びその方法 |
JP2019165025A Active JP6787459B2 (ja) | 2016-02-04 | 2019-09-11 | 無線端末 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2021211784A Active JP7306444B2 (ja) | 2016-02-04 | 2021-12-27 | 無線端末及びその方法 |
Country Status (7)
Country | Link |
---|---|
US (3) | US10506389B2 (ja) |
EP (2) | EP3413681B1 (ja) |
JP (4) | JP6587001B2 (ja) |
KR (4) | KR102172126B1 (ja) |
CN (2) | CN108605376B (ja) |
ES (1) | ES2901117T3 (ja) |
WO (1) | WO2017134939A1 (ja) |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3413681B1 (en) * | 2016-02-04 | 2021-12-08 | Nec Corporation | Wireless terminal, method and program therefor |
EP3429262B1 (en) * | 2016-03-09 | 2020-08-12 | LG Electronics Inc. -1- | Method and device for configuring bearer for transmission of user data |
CN107426801A (zh) * | 2016-05-23 | 2017-12-01 | 中兴通讯股份有限公司 | 一种智能卡的控制方法、装置、终端设备及智能卡 |
US10659976B2 (en) | 2016-06-29 | 2020-05-19 | Nokia Technologies Oy | Paging enhancement for signaling optimization |
WO2018030259A1 (ja) * | 2016-08-10 | 2018-02-15 | 京セラ株式会社 | 無線端末及び基地局 |
EP3533255B1 (en) * | 2016-10-26 | 2020-03-25 | Telefonaktiebolaget LM Ericsson (PUBL) | Wireless device and method performed therein for handling neighbour relationships in a wireless network |
JP2020501410A (ja) * | 2016-11-04 | 2020-01-16 | 華為技術有限公司Huawei Technologies Co.,Ltd. | データパケット処理方法、制御プレーンネットワーク要素、及びユーザプレーンネットワーク要素 |
EP3639616A1 (en) * | 2017-06-16 | 2020-04-22 | Telefonaktiebolaget LM Ericsson (PUBL) | Resuming a connection in a wireless communication system |
CN109548109B (zh) | 2017-08-14 | 2021-03-09 | 电信科学技术研究院 | 一种ue和网络状态不匹配的处理方法及装置、存储介质 |
US10581495B2 (en) * | 2017-08-18 | 2020-03-03 | Nokia Technologies Oy | Physical layer configuration continuity during radio resource control restoration |
US10681593B2 (en) * | 2017-11-30 | 2020-06-09 | At&T Intellectual Property I, L.P. | Session transfer for packet data network connection |
EP3718319B1 (en) * | 2018-02-20 | 2023-01-11 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Method, system and computer programs for the transmission of infrequent small data in a telecommunication system |
CN110312296B (zh) * | 2018-03-27 | 2023-09-08 | 夏普株式会社 | 用户设备执行的方法、基站执行的方法、用户设备和基站 |
US10785821B2 (en) * | 2018-05-09 | 2020-09-22 | Htc Corporation | Device and method of handling a resume cause in a radio resource control message |
CN109246799A (zh) * | 2018-09-05 | 2019-01-18 | 江苏鑫软图无线技术股份有限公司 | NB-IoT系统下实现CIoT EPS优化转换的方法 |
US10856333B2 (en) * | 2018-09-25 | 2020-12-01 | Hughes Network Systems, Llc | Efficient transport of internet of things (IoT) traffic in terrestrial wireless and satellite networks |
WO2020164763A1 (en) * | 2019-02-13 | 2020-08-20 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and apparatuses for alternative data over non-access stratum, donas, data delivery in a roaming scenario |
WO2020168055A1 (en) * | 2019-02-14 | 2020-08-20 | Google Llc | Resuming radio connections in a communication network |
WO2020175490A1 (en) * | 2019-02-27 | 2020-09-03 | Sharp Kabushiki Kaisha | Radio access network and methods |
WO2020175658A1 (en) * | 2019-02-28 | 2020-09-03 | Sharp Kabushiki Kaisha | Radio access network and methods |
CN113825186B (zh) * | 2020-06-19 | 2023-08-01 | 维沃移动通信有限公司 | 离开网络的控制方法、装置和通信设备 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015142049A1 (ko) * | 2014-03-19 | 2015-09-24 | 엘지전자 주식회사 | 서비스 요청 절차 수행 방법 및 사용자 장치 |
Family Cites Families (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100253283B1 (ko) * | 1997-04-07 | 2000-04-15 | 김영환 | 메모리소자의소모전류감소회로 |
US7011153B2 (en) * | 2003-12-23 | 2006-03-14 | Schlumberger Technology Corporation | Hydraulically released inflation tool for permanent bridge plug |
CN101163026B (zh) * | 2006-10-13 | 2011-04-20 | 中兴通讯股份有限公司 | 一种无线网络控制器获取无线接入承载标识的实现方法 |
CN101257374B (zh) * | 2007-03-01 | 2010-05-19 | 鼎桥通信技术有限公司 | 实现广播/组播业务与专用业务并发的方法及其系统 |
US8331322B2 (en) * | 2009-01-22 | 2012-12-11 | Htc Corporation | Method of handling radio bearer resumption, wireless communication device and wireless communication system thereof |
CN102045713A (zh) * | 2009-10-15 | 2011-05-04 | 中兴通讯股份有限公司 | 业务连接重建的方法和实现系统 |
CN102291821A (zh) * | 2010-06-18 | 2011-12-21 | 电信科学技术研究院 | 一种恢复rrc连接的方法及中继设备rn |
CN102340886B (zh) * | 2010-07-22 | 2014-04-16 | 大唐移动通信设备有限公司 | 一种重建立rrc连接的方法、装置及系统 |
GB2493349A (en) * | 2011-07-29 | 2013-02-06 | Intellectual Ventures Holding 81 Llc | Mobile communications network with simplified handover |
EP2557890B1 (en) * | 2011-08-12 | 2019-07-17 | BlackBerry Limited | Simplified ue + enb messaging |
EP2742767B1 (en) * | 2011-08-12 | 2018-04-04 | BlackBerry Limited | Suspending a connection in a wireless communication system |
EP2557889B1 (en) * | 2011-08-12 | 2019-07-17 | BlackBerry Limited | Simplified ue + enb messaging |
US9155121B2 (en) * | 2012-03-27 | 2015-10-06 | Blackberry Limited | Re-establishment of suspended RRC connection at a different eNB |
EP2645804B1 (en) * | 2012-03-27 | 2017-12-20 | BlackBerry Limited | Re-establishment of suspended RRC connection at a different ENB |
US8923880B2 (en) * | 2012-09-28 | 2014-12-30 | Intel Corporation | Selective joinder of user equipment with wireless cell |
US8768305B1 (en) * | 2012-10-09 | 2014-07-01 | Sprint Communications Company L.P. | Reestablishing a mobile device radio resource control connection |
EP3020248B1 (en) * | 2013-07-09 | 2023-05-03 | Telefonaktiebolaget LM Ericsson (publ) | Method and apparatus in a telecommunication system |
US9265085B2 (en) * | 2013-12-31 | 2016-02-16 | Alcatel Lucent | Methods and systems for optimizing short data burst services over an LTE network |
CN104980980A (zh) * | 2014-04-10 | 2015-10-14 | 电信科学技术研究院 | 一种建立连接的方法、系统和设备 |
JP5691118B1 (ja) | 2014-07-15 | 2015-04-01 | 株式会社エム・イ−・ティ− | 活性炭製造装置及び活性炭製造方法 |
WO2016068776A1 (en) * | 2014-10-28 | 2016-05-06 | Telefonaktiebolaget L M Ericsson (Publ) | Establishing a connection between the user equipment and a wireless communications network |
US10667321B2 (en) * | 2015-02-09 | 2020-05-26 | Intel IP Corporation | Evolved Node-B, user equipment, and methods for transition between idle and connected modes |
JP6208296B1 (ja) * | 2015-11-05 | 2017-10-04 | 株式会社Nttドコモ | ユーザ装置、基地局、及び接続確立方法 |
US10616789B2 (en) * | 2015-12-29 | 2020-04-07 | Lg Electronics Inc. | Method and device for establishing bearer for transmission of user data |
WO2017117807A1 (en) * | 2016-01-08 | 2017-07-13 | Nokia Technologies Oy | User plane optimization for narrowband internet of things |
RU2019106527A (ru) * | 2016-01-08 | 2019-03-28 | Телефонактиеболагет Лм Эрикссон (Пабл) | Способ и устройство управления радиоресурсами |
WO2017118935A1 (en) * | 2016-01-08 | 2017-07-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Simplified wireless connectivity for a cellular communications system |
CN106961456B (zh) * | 2016-01-11 | 2022-01-18 | 北京三星通信技术研究有限公司 | 决定iot业务方法和设备、iot业务行为控制方法和设备 |
EP3403465A1 (en) * | 2016-01-12 | 2018-11-21 | Intel Corporation | CELLULAR INTERNET OF THINGS (CIoT) OPTIMIZATIONS FOR NARROWBAND (NB) AND NON-NB IoT NETWORKS |
CN114189815B (zh) * | 2016-01-18 | 2024-02-09 | 三星电子株式会社 | 移动通信系统中终端通信的方法和装置 |
JP2019050435A (ja) * | 2016-01-19 | 2019-03-28 | シャープ株式会社 | 端末装置、c−sgnおよび通信制御方法 |
JP2019050437A (ja) * | 2016-01-19 | 2019-03-28 | シャープ株式会社 | 端末装置、c−sgnおよび通信制御方法 |
WO2017135676A1 (en) * | 2016-02-02 | 2017-08-10 | Lg Electronics Inc. | Method and apparatus for paging with resume id for suspended user equipment in wireless communication system |
EP3413681B1 (en) * | 2016-02-04 | 2021-12-08 | Nec Corporation | Wireless terminal, method and program therefor |
-
2016
- 2016-12-15 EP EP16889422.8A patent/EP3413681B1/en active Active
- 2016-12-15 CN CN201680081095.1A patent/CN108605376B/zh active Active
- 2016-12-15 EP EP21205405.0A patent/EP3965526A1/en active Pending
- 2016-12-15 CN CN202210044446.9A patent/CN114374939B/zh active Active
- 2016-12-15 US US16/069,777 patent/US10506389B2/en active Active
- 2016-12-15 KR KR1020207021771A patent/KR102172126B1/ko active IP Right Grant
- 2016-12-15 KR KR1020207006932A patent/KR102140912B1/ko active IP Right Grant
- 2016-12-15 ES ES16889422T patent/ES2901117T3/es active Active
- 2016-12-15 KR KR1020207030464A patent/KR102226650B1/ko active IP Right Grant
- 2016-12-15 WO PCT/JP2016/087351 patent/WO2017134939A1/ja active Application Filing
- 2016-12-15 JP JP2017565424A patent/JP6587001B2/ja active Active
- 2016-12-15 KR KR1020187022298A patent/KR102092495B1/ko active IP Right Grant
-
2019
- 2019-09-11 JP JP2019165025A patent/JP6787459B2/ja active Active
- 2019-10-18 US US16/657,407 patent/US10880700B2/en active Active
-
2020
- 2020-10-20 JP JP2020175871A patent/JP7006752B2/ja active Active
- 2020-11-25 US US17/104,128 patent/US11388560B2/en active Active
-
2021
- 2021-12-27 JP JP2021211784A patent/JP7306444B2/ja active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2015142049A1 (ko) * | 2014-03-19 | 2015-09-24 | 엘지전자 주식회사 | 서비스 요청 절차 수행 방법 및 사용자 장치 |
JP2016529856A (ja) * | 2014-03-19 | 2016-09-23 | エルジー エレクトロニクス インコーポレイティド | サービス要求手順実行方法及びユーザ装置 |
Non-Patent Citations (2)
Title |
---|
MEDIATEK INC.: "NB-IOT-RRC Procedures", 3GPP TSG RAN WG2 ADHOC_2016_01_LTE_NB_IOT R2-160506, JPN6017007894, 13 January 2016 (2016-01-13), ISSN: 0004657465 * |
NEC: "Establishment cause value in Solution 2 and 18", 3GPP TSG RAN WG2 ADHOC_2016_01_LTE_NB_IOT R2-160511, JPN6019020809, 13 January 2016 (2016-01-13), ISSN: 0004657466 * |
Also Published As
Publication number | Publication date |
---|---|
US20210160665A1 (en) | 2021-05-27 |
CN108605376A (zh) | 2018-09-28 |
JP2022037204A (ja) | 2022-03-08 |
JPWO2017134939A1 (ja) | 2018-10-18 |
US11388560B2 (en) | 2022-07-12 |
KR20200092434A (ko) | 2020-08-03 |
JP6787459B2 (ja) | 2020-11-18 |
KR20200123290A (ko) | 2020-10-28 |
CN114374939A (zh) | 2022-04-19 |
CN114374939B (zh) | 2023-08-25 |
EP3965526A1 (en) | 2022-03-09 |
WO2017134939A1 (ja) | 2017-08-10 |
US20190028860A1 (en) | 2019-01-24 |
EP3413681A4 (en) | 2020-01-29 |
US10506389B2 (en) | 2019-12-10 |
EP3413681A1 (en) | 2018-12-12 |
US20200053520A1 (en) | 2020-02-13 |
CN108605376B (zh) | 2022-01-25 |
JP2020010379A (ja) | 2020-01-16 |
KR102172126B1 (ko) | 2020-10-30 |
EP3413681B1 (en) | 2021-12-08 |
JP7006752B2 (ja) | 2022-01-24 |
KR20180100381A (ko) | 2018-09-10 |
JP6587001B2 (ja) | 2019-10-09 |
KR102092495B1 (ko) | 2020-03-23 |
KR20200029617A (ko) | 2020-03-18 |
JP7306444B2 (ja) | 2023-07-11 |
KR102140912B1 (ko) | 2020-08-03 |
US10880700B2 (en) | 2020-12-29 |
ES2901117T3 (es) | 2022-03-21 |
KR102226650B1 (ko) | 2021-03-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7006752B2 (ja) | 無線端末、無線端末の方法、及び基地局の方法 | |
JP6969636B2 (ja) | 無線端末、無線端末における方法、及び無線局 | |
RU2728759C2 (ru) | Система радиостанций, терминал радиосвязи и способы их работы |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20201020 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20211207 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20211220 |