JP2021103891A - アイドルモードと接続モードとの間の遷移のための進化型ノードｂ、ユーザ装置及び方法 - Google Patents

Abstract

【課題】アイドルモードと接続モードとの間の遷移のための進化型ノードＢ（ｅＮＢ）及び通信方法を提供する。【解決手段】通信方法において、ｅＮＢは、ｅＮＢとＵＥとの間のライトウェイト無線リソース制御（ＲＲＣ）を用いてＵＥからアップリンクデータパケットを受信する５１０。ｅＮＢは、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥの遷移を通知するため、ＲＲＣ接続リリースメッセージをＵＥに送信し５２５、ＲＲＣ接続リリースメッセージは、ＵＥがＲＲＣ接続のコンテキスト情報を格納するか否かのインジケータを含む。ｅＮＢは更に、ライトウェイトＲＲＣ接続を利用して格納されたコンテキスト情報に従って更なるアップリンクデータパケットを受信する５５０。【選択図】図５

Description

［優先権主張］
本出願は、各々が参照することによってその全体がここに援用される２０１５年２月９日に出願された米国仮特許出願第６２／１１３，９２５号に対する優先権の利益を主張する２０１５年１０月３０日に出願された米国特許出願第１４／９２７，９２８号に対する優先権の利益を主張する。
［技術分野］
実施例は、無線通信に関する。いくつかの実施例は、その範囲がこれに限定されるものでないが、３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ネットワーク、３ＧＰＰ ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ネットワーク及び３ＧＰＰ ＬＴＥ−Ａ（ＬＴＥ Ａｄｖａｎｃｅｄ）ネットワークを含むセルラ通信ネットワークに関する。いくつかの実施例は、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）処理に関する。いくつかの実施例は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）アイドルモード又はＲＲＣ接続モードなどのＲＲＣモードに関する。

セルラネットワークは、各種デバイスをサポートするよう構成される。一例として、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）処理のため構成されたデバイスは、比較的に頻繁でないレートで比較的小さなブロックの通信のためにネットワークによってサポートされる。ネットワークとサポートされるデバイスとの間の接続の管理は、ネットワークが多数のＭＴＣデバイス及び／又は他のデバイスをサポートするときなど、いくつかのシナリオにおいて困難なものとなりうる。従って、これら及び他のシナリオにおけるデバイス接続性の管理のための方法及びシステムが一般的に必要とされる。

図１は、いくつかの実施例による３ＧＰＰネットワークの機能図である。 図２は、いくつかの実施例によるユーザ装置（ＵＥ）の機能図である。 図３は、いくつかの実施例による進化型ノードＢ（ｅＮＢ）の機能図である。 図４は、いくつかの実施例によるＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）の機能図である。 図５は、いくつかの実施例による通信方法の処理を示す。 図６は、いくつかの実施例によるＲＲＣ接続リリースメッセージの例を示す。 図７は、いくつかの実施例による一例となるメッセージフロー図を示す。 図８は、いくつかの実施例によるＵＥコンテキストとＵＥ状態とに関する一例となる制御メッセージを示す。 図９は、いくつかの実施例による他の通信方法の処理を示す。 図１０は、いくつかの実施例によるＵＥコンテキストとＵＥ状態とに関する更なる一例となる制御メッセージを示す。 図１１は、いくつかの実施例による他の一例となるメッセージフロー図を示す。

以下の説明及び図面は、当業者がそれらを実施できるように特定の実施形態を十分に説明する。他の実施例は、構造的、論理的、電気的、プロセス的及び他の変更を組み込むことができる。いくつかの実施例の一部及び特徴は、他の実施例の一部及び特徴に含まれていてもよいし、あるいは、代用されてもよい。請求項に記載された実施例は、それらの請求項の全ての利用可能な均等物を包含する。

図１は、いくつかの実施例による３ＧＰＰネットワークの機能図である。ネットワークは、無線アクセスネットワーク（ＲＡＮ）１００（例えば、図示されるように、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）など）と、Ｓ１インタフェース１１５を介し一緒に結合されるコアネットワーク１２０（例えば、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）として示される）とを含む。簡略化及び簡略化のために、ＲＡＮ１００と共にコアネットワーク１２０の一部のみが示されている。

コアネットワーク１２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）１２２、サービングゲートウェイ（サービングＧＷ）１２４及びパケットデータネットワークゲートウェイ（ＰＤＮ ＧＷ）１２６を有する。ＲＡＮ１００は、ユーザ装置（１０２）１０２と通信するための進化型ノードＢ（ｅＮＢ）１０４（基地局として動作する）を有する。ｅＮＢ１０４は、マクロｅＮＢ及び低電力（ＬＰ）ｅＮＢを有してもよい。いくつかの実施例によると、ｅＮＢ１０４は、ｅＮＢ１０４とＵＥ１０２との間のＲＲＣ接続上でＵＥ１０２からアップリンクデータパケットを受信する。ｅＮＢ１０４は、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥ１０２の遷移を通知するため、ＲＲＣ接続リリースメッセージを送信する。ｅＮＢ１０４は更に、記憶されているコンテキスト情報に従って更なるアップリンクデータパケットを受信する。

ＭＭＥ１２２は、従来のＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）の制御プレーンと機能的に類似する。ＭＭＥ１２２は、ゲートウェイ選択及びトラッキングエリアリスト管理などのアクセスにおけるモビリティの側面を管理する。サービングＧＷ１２４は、ＲＡＮ１００に対するインタフェースを終端し、ＲＡＮ１００とコアネットワーク１２０との間でデータパケットをルーティングする。さらに、それはｅＮＢ間ハンドオーバのためのローカルなモビリティアンカーポイントであってもよく、また３ＧＰＰ間モビリティのためのアンカーを提供してもよい。他の役割は、合法的傍受、課金及びポリシー実施を含んでもよい。サービングＧＷ１２４及びＭＭＥ１２２は、１つの物理ノード又は別々の物理ノードにおいて実現されてもよい。ＰＤＮ ＧＷ１２６は、パケットデータネットワーク（ＰＤＮ）に対するＳＧｉインタフェースを終端する。ＰＤＮ ＧＷ１２６は、ＥＰＣ１２０と外部ＰＤＮとの間でデータパケットをルーティングし、ポリシー実施及び課金データ収集のためのキーノードとなりうる。それはまた、非ＬＴＥアクセスとのモビリティのためのアンカーポイントを提供しうる。外部ＰＤＮは、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）ドメインと共に何れかのタイプのＩＰネットワークとすることができる。ＰＤＮ ＧＷ１２６及びサービングＧＷ１２４は、１つの物理ノード又は別々の物理ノードにおいて実現されてもよい。さらに、ＭＭＥ１２２及びサービングＧＷ１２４は、１つの物理ノードにまとめられてもよく、この場合、メッセージは１つ少ないホップで転送される必要がある。

ｅＮＢ１０４（マクロ及びマイクロ）は、無線インタフェースプロトコルを終端し、ＵＥ１０２の最初の接触ポイントであってもよい。いくつかの実施例では、ｅＮＢ１０４は、ＲＮＣ（無線ネットワークコントローラ機能）に限定されず、無線ベアラ管理、アップリンク及びダウンリンク動的無線リソース制御及びデータパケットスケジューリング並びにモビリティ管理などを含むＲＡＮ１００のための各種論理関数を実現してもよい。実施例によると、ＵＥ１０２は、ＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）通信技術に従ってマルチキャリア通信チャネルを介しｅＮＢ１０４とＯＦＤＭ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｅｌｘｉｎｇ）通信信号を通信するよう構成される。ＯＦＤＭ信号は、複数の直交サブキャリアを有する。

Ｓ１インタフェース１１５は、ＲＡＮ１００とＥＰＣ１２０とを分離するインタフェースである。それは、ｅＮＢ１０４とサービングＧＷ１２４との間でトラフィックデータを搬送するＳ１−Ｕと、ｅＮＢ１０４とＭＭＥ１２２との間のシグナリングインタフェースであるＳ１−ＭＭＥとの２つのパーツに分割される。Ｘ２インタフェースは、ｅＮＢ１０４の間のインタフェースである。Ｘ２インタフェースは、Ｘ２−Ｃ及びＸ２−Ｕの２つのパーツを有する。Ｘ２−ＣはｅＮＢ１０４の間の制御プレーンインタフェースであり、Ｘ２−ＵはｅＮＢ１０４の間のユーザプレーンインタフェースである。

セルラネットワークによると、ＬＰセルは、典型的には、屋外信号が良好に届かない屋内エリアにカバレッジを拡張するため、又は列車の駅などのかなり密な電話利用のエリアにおけるネットワークキャパシティを追加するのに利用される。ここで用いられる低電力（ＬＰ）ｅＮＢという用語は、フェムトセル、ピコセル又はマイクロセルなどのより狭いセル（マイクロセルより狭い）を実現するのに適した何れかの比較的低い電力のｅＮＢを参照する。フェムトセルｅＮＢは、典型的には、モバイルネットワークオペレータによってそれの住居又は企業顧客に提供される。フェムトセルは、典型的には、典型的には、住居用ゲートウェイ又はより小さいサイズであり、一般にユーザのブロードバンド回線に接続する。プラグインされると、フェムトセルは、モバイルオペレータのモバイルネットワークに接続し、住居用フェムトセルについて、典型的には、３０〜５０メータの範囲で追加的なカバレッジを提供する。従って、ＬＰ ｅＮＢは、それがＰＤＮ ＧＷ１２６に結合されるため、フェムトセルｅＮＢであってもよい。同様に、ピコセルは、建物内（オフィス、ショッピングモール、列車の駅など）又はより最近では飛行機内などの小さなエリアを典型的にカバーする無線通信システムである。ピコセルｅＮＢは、一般にそれの基地局コントローラ（ＢＳＣ）機能を介しマイクロｅＮＢなどの他のｅＮＢにＸ２リンクを介し接続可能である。従って、ＬＰ ｅＮＢは、それがＸ２インタフェースを介しマクロｅＮＢに接続されるため、ピコセルｅＮＢにより実現されてもよい。ピコセルｅＮＢ又は他のＬＰ ｅＮＢは、マクロｅＮＢの一部又は全ての機能を搭載してもよい。いくつかのケースでは、これはアクセスポイント基地局又は企業フェムトセルとして参照されうる。

いくつかの実施例では、ダウンリンクリソースグリッドは、ｅＮＢ１０４からＵＥ１０２へのダウンリンク送信のために利用されてもよく、ＵＥ１０２からｅＮＢ１０４へのアップリンク送信は同様の技術を利用しうる。グリッドは、各スロットにおけるダウンリンクの物理リソースであるリソースグリッド又は時間周波数リソースグリッドと呼ばれる時間周波数グリッドであってもよい。このような時間周波数プレーンの表現は、無線リソース割当てについて直感的なものにするＯＦＤＭシステムの通常のプラクティスである。リソースグリッドの各カラム及び各ローは、それぞれ１つのＯＦＤＭシンボル及び１つのＯＦＤＭサブキャリアに対応する。時間領域におけるリソースグリッドの持続時間は無線フレームにおける１つのスロットに対応する。リソースグリッドにおける最小の時間周波数単位は、リソースエレメント（ＲＥ）として示される。各リソースグリッドは、特定の物理チャネルとリソースエレメントとの間のマッピングを記述する複数のリソースブロック（ＲＢ）を有する。各リソースブロックは、周波数領域におけるリソースエレメントの集まりを有し、現在割当て可能な最小のリソース量を表す。このようなリソースブロックを用いて伝えられる複数の異なる物理ダウンリンクチャネルがある。本開示との特定の関連によると、これら物理ダウンリンクチャネルの２つは、物理ダウンリンク共有チャネルと物理ダウンリンク制御チャネルである。

物理ダウンリンク共有チャネル（ＰＤＳＣＨ）は、ユーザデータ及び上位レイヤシグナリングをＵＥ１０２に搬送する（図１）。物理ダウンリンク制御チャネル（ＰＤＣＣＨ）は、特にＰＤＳＣＨに関するトランスポートフォーマット及びリソース割当てに関する情報を搬送する。それはまた、アップリンク共有チャネルに関するトランスポートフォーマット、リソース割当て及びＨＡＲＱ情報をＵＥ１０２に通知する。典型的には、ダウンリンクスケジューリング（セル内のＵＥ１０２に制御及び共有チャネルリソースブロックを割り当てる）は、ＵＥ１０２からｅＮＢ１０４にフィードバックされるチャネル品質情報に基づきｅＮＢ１０４において実行され、その後、ダウンリンクリソース割当て情報が、ＵＥ１０２のために用いられる（割り当てられた）制御チャネル（ＰＤＣＣＨ）上でＵＥ１０２に送信される。

ＰＤＣＣＨは、ＣＣＥ（制御チャネルエレメント）を用いて制御情報を伝送する。リソースエレメントにマッピングされる前、ＰＤＣＣＨの複素値シンボルはまずクワドラプルに編成され、その後、レートマッチングのためサブブロックインタリーバを用いてパーミュテートされる。各ＰＤＣＣＨは、これらの制御チャネルエレメント（ＣＣＥ）の１つ以上を用いて送信され、各ＣＣＥはリソースエレメントグループ（ＲＥＧ）として知られる４つの物理リソースエレメントの９個のセットに対応する。４つのＱＰＳＫシンボルは各ＲＥＧにマッピングされる。ＰＤＣＣＨは、ＤＣＩのサイズ及びチャネル状態に応じて１つ以上のＣＣＥを用いて送信可能である。異なる数のＣＣＥ（例えば、アグリゲーションレベルＬ＝１，２，４又は８）による４つ以上の異なるＰＤＣＣＨフォーマットがＬＴＥにおいて定義されうる。

図２は、いくつかの実施例によるユーザ装置（ＵＥ）の機能図である。ＵＥ２００は、図１に示されるようなＵＥ１０２として利用するのに適したものであってもよい。いくつかの実施例では、ＵＥ２００は、図示されるように少なくとも一緒に結合されるアプリケーション回路２０２、ベースバンド回路２０４、無線周波数（ＲＦ）回路２０６、フロントエンドモジュール（ＦＥＭ）回路２０８及び１つ以上のアンテナ２１０を有する。いくつかの実施例では、他の回路又は構成は、アプリケーション回路２０２、ベースバンド回路２０４、ＲＦ回路２０６及び／又はＦＥＭ回路２０８の１つ以上の要素及び／又はコンポーネントを有し、またいくつかのケースでは他の要素及び／又はコンポーネントを有してもよい。一例として、“処理回路”は、１つ以上の要素及び／又はコンポーネントを有し、その一部又は全てがアプリケーション回路２０２及び／又はベースバンド回路２０４に含まれてもよい。他の例として、“送受信回路”は、１つ以上の要素及び／又はコンポーネントを有し、その一部又は全てがＲＦ回路２０６及び／又はＦＥＭ回路２０８に含まれてもよい。しかしながら、これらの例は、処理回路及び／又は送受信回路がまたいくつかのケースにおいて他の要素及び／又はコンポーネントを有してもよいため、限定的でない。

アプリケーション回路２０２は、１つ以上のアプリケーションプロセッサを有する。例えば、アプリケーション回路２０２は、限定されないが、１つ以上のシングルコア又はマルチコアプロセッサなどの回路を有してもよい。プロセッサは、汎用プロセッサ及び専用プロセッサ（例えば、グラフィックプロセッサ、アプリケーションプロセッサなど）の何れかの組み合わせを含んでもよい。プロセッサは、メモリ／ストレージと結合されてもよいし、及び／又は含んでもよく、様々なアプリケーション及び／又はオペレーティングシステムがシステム上で動作することを可能にするためにメモリ／ストレージに記憶された命令を実行するよう構成されてもよい。

ベースバンド回路２０４は、限定されないが、１つ以上のシングルコア又はマルチコアプロセッサなどの回路を有する。ベースバンド回路２０４は、ＲＦ回路２０６の受信信号経路から受信したベースバンド信号を処理し、ＲＦ回路２０６の送信信号経路用のベースバンド信号を生成するための１つ以上のベースバンドプロセッサ及び／又は制御ロジックを含んでもよい。ベースバンド処理回路は、ベースバンド信号の生成及び処理と、ＲＦ回路２０６の動作を制御するため、アプリケーション回路２０２とインタフェースをとってもよい。例えば、いくつかの実施例では、ベースバンド回路２０４は、第２世代（２Ｇ）ベースバンドプロセッサ２０４ａ、第３世代（３Ｇ）ベースバンドプロセッサ２０４ｂ、第４世代（４Ｇ）ベースバンドプロセッサ２０４ｃ及び／又は他の既存の生成物、開発中の生成物又は将来的に開発されるもの（例えば、第５世代（５Ｇ）、６Ｇなど）のための他のベースバンドプロセッサ２０４ｄを含んでもよい。ベースバンド回路２０４（例えば、１つ以上のベースバンドプロセッサ２０４ａ〜ｄ）は、ＲＦ回路２０６を介し１つ以上の無線ネットワークとの通信を可能にする様々な無線制御機能を処理しうる。無線制御機能は、限定されることなく、信号変調／復調、符号化／復号化、無線周波数シフト処理などを含みうる。いくつかの実施例では、ベースバンド回路２０４の変調／復調回路は、高速フーリエ変換（ＦＦＴ）、プリコーディング及び／又はコンステレーションマッピング／デマッピング機能を含みうる。いくつかの実施例では、ベースバンド回路２０４の符号化／復号化回路は、畳み込み、テールビッティングコンボリューション、ターボ、Ｖｉｔｅｒｂｉ及び／又は低密度パリティチェック（ＬＤＰＣ）エンコーダ／デコーダ機能を含んでもよい。変調／復調及びエンコーダ／デコーダの機能性の実施例は、これらの例に限定されず、他の実施例では他の適切な機能を含んでもよい。

いくつかの実施例では、ベースバンド回路２０４は、例えば、物理（ＰＨＹ）、媒体アクセス制御（ＭＡＣ）、無線リンク制御（ＲＬＣ）、パケットデータコンバージェンスプロトコル（ＰＤＣＰ）及び／又は無線リソース制御（ＲＲＣ）要素を含むＥＵＴＲＡＮ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）プロトコルの要素などのプロトコルスタックの要素を含んでもよい。ベースバンド回路２０４の中央処理ユニット（ＣＰＵ）２０４ｅは、ＰＨＹ、ＭＡＣ、ＲＬＣ、ＰＤＣＰ及び／又はＲＲＣレイヤのシグナリングのため、プロトコルスタックの要素を実行するよう構成されうる。いくつかの実施例では、ベースバンド回路は、１つ以上のオーディオデジタル信号プロセッサ（ＤＳＰ）２０４ｆを含んでもよい。オーディオＤＳＰ２０４ｆは、圧縮／解凍及びエコーキャンセレーション用の要素を含んでもよく、他の実施例では、他の適切な処理要素を含んでもよい。ベースバンド回路のコンポーネントは、いくつかの実施例では、単一のチップ、単一のチップセットに適切に組み合わされてもよいし、あるいは、同じ回路基板上に配置されてもよい。いくつかの実施例では、ベースバンド回路２０４及びアプリケーション回路２０２の構成要素の一部又は全部は、例えば、システムオンチップ（ＳＯＣ）などのように一緒に実装されてもよい。

いくつかの実施例では、ベースバンド回路２０４は、１つ以上の無線技術と互換性のある通信を提供しうる。例えば、いくつかの実施例では、ベースバンド回路２０４は、ＥＵＴＲＡＮ及び／又は他の無線メトロポリタンエリアネットワーク（ＷＭＡＮ）、無線ローカルエリアネットワーク（ＷＬＡＮ）、無線パーソナルエリアネットワーク（ＷＰＡＮ）との通信をサポートしてもよい。ベースバンド回路２０４が複数の無線プロトコルの無線通信をサポートするよう構成される実施例は、マルチモードベースバンド回路と参照されてもよい。

ＲＦ回路２０６は、非固体媒体を介し変調された電磁放射線を使用して無線ネットワークと通信することを可能にする。様々な実施例では、ＲＦ回路２０６は、無線ネットワークとの通信を実現するためのスイッチ、フィルタ、増幅器などを含みうる。ＲＦ回路２０６は、ＦＥＭ回路２０８から受信したＲＦ信号をダウンコンバートし、ベースバンド回路２０４にベースバンド信号を供給する回路を含みうる受信信号経路を含んでもよい。ＲＦ回路２０６はまた、ベースバンド回路２０４によって提供されるベースバンド信号をアップコンバートし、送信用にＦＥＭ回路２０８にＲＦ出力信号を提供する回路を含みうる送信信号経路を含んでもよい。

いくつかの実施例では、ＲＦ回路２０６は、受信信号経路及び送信信号経路を含んでもよい。ＲＦ回路２０６の受信信号経路は、ミキサ回路２０６ａ、増幅回路２０６ｂ及びフィルタ回路２０６ｃを含んでもよい。ＲＦ回路２０６の送信信号経路は、フィルタ回路２０６ｃ及びミキサ回路２０６ａを含んでもよい。ＲＦ回路２０６はまた、受信信号経路及び送信信号経路のミキサ回路２０６ａによって使用される周波数を合成する合成回路２０６ｄを含んでもよい。いくつかの実施例では、受信信号経路のミキサ回路２０６ａは、合成回路２０６ｄによって提供された合成周波数に基づきＦＥＭ回路２０８から受信されたＲＦ信号をダウンコンバートするよう構成されてもよい。増幅回路２０６ｂは、ダウンコンバートされた信号を増幅するよう構成され、フィルタ回路２０６ｃは、ダウンコンバートされた信号から不要な信号を除去して、出力ベースバンド信号を生成するよう構成されるローパスフィルタ（ＬＰＦ）又はバンドパスフィルタ（ＢＰＦ）であってもよい。出力ベースバンド信号は、さらなる処理のためにベースバンド回路２０４に供給されてもよい。いくつかの実施例では、出力ベースバンド信号は、ゼロ周波数のベースバンド信号であってもよいが、これは要件ではない。いくつかの実施例では、受信信号経路のミキサ回路２０６ａはパッシブミキサを含むことができるが、実施例の範囲はこれに限定されない。いくつかの実施例では、送信信号経路のミキサ回路２０６ａは、ＦＥＭ回路２０８のためのＲＦ出力信号を生成するため、合成回路２０６ｄによって提供される合成周波数に基づき入力ベースバンド信号をアップコンバートするよう構成されてもよい。ベースバンド信号は、ベースバンド回路２０４によって提供され、フィルタ回路２０６ｃによってフィルタリングされてもよい。実施例の範囲はこれに限定されないが、フィルタ回路２０６ｃはローパスフィルタ（ＬＰＦ）を含んでもよい。

いくつかの実施例では、受信信号経路のミキサ回路２０６ａ及び送信信号経路のミキサ回路２０６ａは、２つ以上のミキサを含み、それぞれ直交ダウンコンバージョン及び／又はアップコンバージョンのために配置されてもよい。いくつかの実施例では、受信信号経路のミキサ回路２０６ａ及び送信信号経路のミキサ回路２０６ａは、２つ以上のミキサを含み、画像拒絶（例えば、Ｈａｒｔｌｅｙ画像拒絶）のために配置されてもよい。いくつかの実施例では、受信信号経路のミキサ回路２０６ａ及び送信信号経路のミキサ回路２０６ａは、それぞれ直接的なダウンコンバージョン及び／又はダイレクトアップコンバージョンのために配置されてもよい。いくつかの実施例では、受信信号経路のミキサ回路２０６ａ及び送信信号経路のミキサ回路２０６ａは、スーパーヘテロダイン動作用に構成されてもよい。

いくつかの実施例では、出力ベースバンド信号及び入力ベースバンド信号は、アナログベースバンド信号であってもよいが、実施例の範囲はこれに限定されない。いくつかの代替的な実施例では、出力ベースバンド信号及び入力ベースバンド信号は、デジタルベースバンド信号であってもよい。これらの代替的な実施例では、ＲＦ回路２０６は、アナログ−デジタル変換器（ＡＤＣ）及びデジタル−アナログ変換器（ＤＡＣ）回路を含み、ベースバンド回路２０４は、ＲＦ回路２０６と通信するためのデジタルベースバンドインタフェースを含んでもよい。いくつかのデュアルモードの実施例では、実施例の範囲はこれに限定されないが、別個の無線ＩＣ回路が各スペクトルの信号を処理するために提供されてもよい。

いくつかの実施例では、合成回路２０６ｄは、他のタイプの周波数シンセサイザが適しているとき、フラクショナルＮシンセサイザ又はフラクショナルＮ／Ｎ＋１シンセサイザとすることができるが、実施形態の範囲はこれに限定されない。例えば、合成回路２０６ｄは、デルタシグマシンセサイザ、周波数倍数器又は分周器を備えた位相同期ループを含むシンセサイザであってもよい。合成回路２０６ｄは、周波数入力及び除算器制御入力に基づきＲＦ回路２０６のミキサ回路２０６ａによって使用される出力周波数を合成するよう構成されてもよい。いくつかの実施例では、合成回路２０６ｄは、フラクショナルＮ／Ｎ＋１シンセサイザであってもよい。いくつかの実施例では、周波数入力は電圧制御発振器（ＶＣＯ）によって提供されてもよいが、これは要件ではない。分周器制御入力は、所望の出力周波数に応じて、ベースバンド回路２０４又はアプリケーションプロセッサ２０２のいずれかによって提供されてもよい。いくつかの実施例では、除算器制御入力（例えば、Ｎ）は、アプリケーションプロセッサ２０２によって示されるチャネルに基づきルックアップテーブルから決定されてもよい。

ＲＦ回路２０６の合成回路２０６ｄは、分周器、遅延同期ループ（ＤＬＬ）、マルチプレクサ及び位相アキュムレータを含んでもよい。いくつかの実施例では、分周器は、デュアルモジュラスデバイダ（ＤＭＤ）であってもよく、位相アキュムレータは、デジタル位相アキュムレータ（ＤＰＡ）であってもよい。いくつかの実施例では、ＤＭＤは、フラクショナル分周比を提供するため、（例えば、キャリーアウトに基づき）Ｎ又はＮ＋１の何れかによって入力信号を分割するよう構成されてもよい。いくつかの実施例では、ＤＬＬは、カスケード、チューナブル、遅延要素、位相検出器、チャージポンプ及びＤ型フリップフロップのセットを含みうる。これらの実施例では、遅延要素は、ＶＣＯ期間をＮｄ個の等しい位相のパケットに分割するよう構成されてもよく、ここで、Ｎｄは遅延ラインの遅延要素の数である。このように、ＤＬＬは、遅延ラインを通る総遅延が１ＶＣＯサイクルになることを保証するのを支援するため、負のフィードバックを提供する。

いくつかの実施例では、合成回路２０６ｄは、出力周波数としてキャリア周波数を生成するよう構成されてもよく、他の実施例では、出力周波数は、キャリア周波数の倍数（例えば、キャリア周波数の２倍、キャリア周波数の４倍）であってもよく、互いに複数の異なる位相を有するキャリア周波数における複数の信号を生成するため、直交発生器及び除算器回路と共に使用される。いくつかの実施例では、出力周波数はＬＯ周波数（ｆ_ＬＯ）であってもよい。いくつかの実施例では、ＲＦ回路２０６はＩＱ／ポーラコンバータを含んでもよい。

ＦＥＭ回路２０８は、１つ以上のアンテナ２１０から受信したＲＦ信号で動作し、受信信号を増幅し、受信信号の増幅されたバージョンをＲＦ回路２０６に更なる処理のために提供するよう構成された回路を含む受信信号経路を含んでもよい。ＦＥＭ回路２０８はまた、１つ以上のアンテナ２１０のうちの１つ以上による送信用のＲＦ回路２０６によって提供される送信用の信号を増幅するよう構成された回路を含み得る送信信号経路を含んでもよい。

いくつかの実施例では、ＦＥＭ回路２０８は、送信モード動作と受信モード動作とを切り替えるためのＴＸ／ＲＸスイッチを含んでもよい。ＦＥＭ回路は、受信信号経路及び送信信号経路を含んでもよい。ＦＥＭ回路の受信信号経路は、受信したＲＦ信号を増幅し、（例えば、ＲＦ回路２０６に）出力として増幅された受信ＲＦ信号を提供するための低雑音増幅器（ＬＮＡ）を含んでもよい。ＦＥＭ回路２０８の送信信号経路は、（例えば、ＲＦ回路２０６によって提供された）入力されたＲＦ信号を増幅する電力増幅器（ＰＡ）と、以降の送信のためにＲＦ信号を生成する１つ以上のフィルタとを含んでもよい。いくつかの実施例では、ＵＥ２００は、例えば、メモリ／ストレージ、ディスプレイ、カメラ、センサ及び／又は入出力（Ｉ／Ｏ）インタフェースなどの追加的な要素を含んでもよい。

図３は、いくつかの実施例による進化型ノードＢ（ｅＮＢ）の機能図である。いくつかの実施例では、ｅＮＢ３００は静止した非モバイルデバイスであってもよいことが留意されるべきである。ｅＮＢ３００は、図１に示されるようなｅＮＢ１０４として使用するのに適したものであってもよい。ｅＮＢ３００は、物理レイヤ回路３０２及び送受信機３０５を有してもよく、その一方又は双方がＵＥ２００、他のｅＮＢ、他のＵＥ又は１つ以上のアンテナ３０１を利用する他のデバイスとの間の送受信を可能にする。一例として、物理レイヤ回路３０２は、受信信号の送信及び復号化のためのベースバンド信号の形成を含む各種符号化及び復号化機能を実行する。他の例として、送受信機３０５は、ベースバンド範囲と無線周波数（ＲＦ）範囲との間の信号の変換など、各種送受信機能を実行する。従って、物理レイヤ回路３０２及び送受信機３０５は、別々のコンポーネントであってもよいし、あるいは、合成されたコンポーネントの一部であってもよい。さらに、説明される機能の一部は、物理レイヤ回路３０２、送受信機３０５及び他のコンポーネント若しくはレイヤの１つ、何れか又は全てを含みうる合成によって実行されてもよい。ｅＮＢ３００はまた、無線媒体へのアクセスを制御するための媒体アクセス制御レイヤ（ＭＡＣ）回路３０４を有してもよい。ｅＮＢ３００はまた、ここに説明される処理を実行するよう構成される処理回路３０６及びメモリ３０８を有してもよい。ｅＮＢ３００はまた、他のｅＮＢ１０４（図１）、ＥＰＣ１２０（図１）におけるコンポーネント又は他のネットワークコンポーネントを含む他のコンポーネントとの通信を可能にする１つ以上のインタフェース３１０を有してもよい。さらに、インタフェース３１０は、ネットワークの外部のコンポーネントを含む、図１に示されない他のコンポーネントとの通信を可能にするものであってもよい。インタフェース３１０は、有線若しくは無線又はこれらの組み合わせであってもよい。

アンテナ２１０，３０１は、例えば、ダイポールアンテナ、モノポールアンテナ、パッチアンテナ、ループアンテナ、マイクロストリップアンテナ又は他のタイプのＲＦ信号の送信に適したアンテナを含む、１つ以上の指向性又は無指向性アンテナを含んでもよい。いくつかの多入力多出力（ＭＩＭＯ）の実施例では、アンテナ２１０，３０１は、効果的に分離され、結果として空間ダイバーシティ及び異なるチャネル特性を利用してもよい。

いくつかの実施例では、ＵＥ２００又はｅＮＢ３００は、モバイルデバイスであってもよく、パーソナルデジタルアシスタント（ＰＤＡ）などのポータブル無線通信デバイス、無線通信機能を備えたラップトップ若しくはポータブルコンピュータ、ウェブタブレット、無線電話、スマートフォン、無線ヘッドセット、ページャ、インスタントメッセージングデバイス、デジタルカメラ、アクセスポイント、テレビ、医療機器（例えば、心拍数モニタ、血圧モニタなど）、などのウェアラブルデバイス又は無線で情報を受信及び／又は送信することができる他のデバイスであってもよい。いくつかの実施例では、ＵＥ２００又はｅＮＢ３００は、３ＧＰＰ規格に従って動作するよう構成されてもよいが、実施例の範囲はこれに限定されない。いくつかの実施例におけるモバイルデバイス又は他のデバイスは、ＩＥＥＥ８０２．１１又は他のＩＥＥＥ規格を含む他のプロトコル又は規格に従って動作するよう構成されてもよい。いくつかの実施例では、ＵＥ２００、ｅＮＢ３００又は他のデバイスは、キーボード、ディスプレイ、不揮発性メモリポート、複数のアンテナ、グラフィックプロセッサ、アプリケーションプロセッサ、スピーカ及び他のモバイルデバイス要素の１つ以上を含むものであってもよい。ディスプレイは、タッチスクリーンを含むＬＣＤスクリーンであってもよい。

図４は、いくつかの実施例によるモビリティマネージメントエンティティ（ＭＭＥ）の機能図である。ＭＭＥ４００は、いくつかの実施例では、図１に示されるＭＭＥ１２２として使用するのに適したものであってもよい。ＭＭＥ４００は、ここで説明される動作を実行するように構成される処理回路４０６及びメモリ４０８を含んでもよい。ＭＭＥ４００はまた、ｅＮＢ１０４（図１）、Ｓ−ＧＷ１２２（図１）、ＥＰＣ１２０におけるコンポーネント（図１）又は他のネットワークコンポーネントを含む他のコンポーネントとの通信を可能にしうる１つ以上のインタフェース４１０を含みうる。さらに、インタフェース４１０は、ネットワークの外部のコンポーネントを含む、図１に示されていない他のコンポーネントとの通信を可能にしうる。インタフェース４１０は、有線若しくは無線又はそれらの組み合わせであってもよい。

ＵＥ２００、ｅＮＢ３００及びＭＭＥ４００はそれぞれ、いくつかの別々の機能要素を有するものとして示されているが、機能要素の１つ以上は組み合わされてもよく、デジタル信号プロセッサ（ＤＳＰ）を含む処理要素などのソフトウェアによって設定される要素及び／又は他のハードウェア要素の組み合わせによって実現されてもよい。例えば、いくつかの要素は、１つ以上のマイクロプロセッサ、ＤＳＰ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、無線周波数集積回路（ＲＦＩＣ）及び少なくともここに説明される機能を実行する各種ハードウェア及び論理回路の組み合わせを含むものであってもよい。いくつかの実施例では、機能要素は、１つ以上の処理要素上で動作する１つ以上のプロセスを参照してもよい。

実施例は、ハードウェア、ファームウェア及びソフトウェアの１つ又は組み合わせにより実現されてもよい。実施例はまた、ここに説明される処理を実行するために少なくとも１つのプロセッサによって読み取られ実行される、コンピュータ可読記憶装置に格納された命令として実現されてもよい。コンピュータ可読記憶装置は、機械（例えば、コンピュータ）によって読み取り可能な形態で情報を記憶するための何れかの非一時的メカニズムを含んでもよい。例えば、コンピュータ可読記憶装置は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置及び他の記憶装置及び媒体を含んでもよい。いくつかの実施例は、１つ以上のプロセッサを含み、コンピュータ可読記憶装置に格納された命令により構成されてもよい。

実施例によると、ｅＮＢ１０４は、ｅＮＢ１０４とＵＥ１０２との間のＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続でＵＥ１０２からアップリンクデータパケットを受信してもよい。ｅＮＢ１０４は、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥ１０２の遷移を指示するため、ＲＲＣ接続リリースメッセージをＵＥ１０２に送信する。ＲＲＣ接続リリースメッセージは、ＵＥ１０２のための非アクティビティタイマの経過に基づくものであってもよい。ＲＲＣ接続リリースメッセージは、ＵＥ１０２がＲＲＣ接続のコンテキスト情報を格納するかどうかの指標を含んでもよい。ｅＮＢ１０４はさらに、格納されたコンテキスト情報に従ってＲＲＣ接続上で追加のアップリンクデータパケットを受信してもよい。これらの実施例は、以下でより詳細に説明される。

図５は、いくつかの実施例による通信方法の処理を示す。方法５００の実施例は、図５に示されているものと比較して、追加的又はさらに少数の処理又はプロセスを含んでもよいことに留意することは重要である。さらに、方法５００の実施例は、必ずしも図５に示された時系列に限定されない。方法５００を説明する際、図１１〜４及び図６〜１１が参照されてもよいが、方法５００は、他の何れか適切なシステム、インタフェース及びコンポーネントを用いて実施されてもよいことが理解される。

さらに、ここで説明される方法５００及び他の方法は、３ＧＰＰ又は他の規格に従って動作するｅＮＢ１０４又はＵＥ１０２を参照してもよいが、これらの方法の実施例は、まさにそのｅＮＢ１０４又はＵＥ１０２に限定されず、Ｗｉ−Ｆｉアクセスポイント（ＡＰ）又はユーザステーション（ＳＴＡ）などの他のモバイルデバイスによって実施されてもよい。さらに、ここに記載される方法５００及び他の方法は、ＩＥＥＥ８０２．１１などの様々なＩＥＥＥ規格に従って動作するよう構成されるシステムを含む、他の適切なタイプの無線通信システムで動作するよう構成された無線デバイスによって実施されてもよい。ここに説明される方法５００及び他の方法はまた、ＵＥ１０２、ｅＮＢ１０４及び／又はＭＭＥ１２２若しくは上述された他のデバイスの装置に適用可能であり得る。

方法５００の処理５０５において、ｅＮＢ１０４は、ＭＭＥ１２２からｅＮＢ１０４とＵＥ１０２との間のＲＲＣ接続のための１つ以上の制御メッセージを受信する。いくつかの実施例では、ｅＮＢ１０４は、ＲＲＣ接続のための１つ以上の制御メッセージをＭＭＥ１２２に送信する。従って、ｅＮＢ１０４及びＭＭＥ１２２は、１つ以上のそのような制御メッセージを交換してもよい。いくつかの実施例では、制御メッセージは、ＲＲＣ接続の確立を可能にしうる。さらに、ＵＥ１０２に関する能力情報、コンフィギュレーション情報及び／又は他の情報が、これら及び／又は他の制御メッセージにおいてｅＮＢ１０４とＭＭＥ１２２との間で交換されてもよい。非限定的な例として、セットアップ制御メッセージが、ｅＮＢ１０４及びＭＭＥ１２２によって交換されてもよい。

いくつかの実施例では、ｅＮＢ１０４は、ＲＲＣ接続がライトウェイトＲＲＣ接続であるというインジケータをＭＭＥに送信してもよい。ｅＮＢ１０４は、ＭＭＥに対するライトウェイトＲＲＣ接続の解放の通知を遅延させることを許可されてもよい。非限定的な例として、ＲＲＣ接続がライトウェイトＲＲＣ接続であるというインジケータは、“ＵＥ Ｃｏｎｔｅｘｔｘ Ｒｅｔａｉｎｅｄ／ＵＥ Ｃｏｎｎｅｃｔｉｏｎ Ｓｕｓｐｅｎｄｅｄ”制御メッセージのような制御メッセージに含めてもよい。別の非限定的な例として、ＲＲＣ接続がライトウェイトＲＲＣ接続であるというインジケータは、“ＵＥ Ｃｏｎｔｅｘｔｘ Ｒｅｌｅａｓｅ／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ”制御メッセージのような制御メッセージに含まれてもよい。しかしながら、これらの例は、インジケータが３ＧＰＰ規格又は他の規格に必ずしも含まれていなくてもよいし、そうでなくてもよい他の適切な制御メッセージを使用して通信されてもよい。

処理５１０において、ｅＮＢ１０４は、ＲＲＣ接続上でＵＥ１０２から第１のアップリンクデータパケットを受信してもよい。いくつかの実施例では、第１のアップリンクデータパケットとおそらく他のアップリンクデータパケットは、ＵＥ１０２がＲＲＣ接続モードにあるとき、ＵＥ１０２によって送信され、及び／又はｅＮＢ１０４で受信される。すなわち、ＲＲＣアイドルモードに移行する前に、ＵＥ１０２は、ＲＲＣ接続上で１つ以上のアップリンクデータパケットを送信してもよい。いくつかのケースでは、ＵＥ１０はまた、ＵＥ１０２がＲＲＣ接続モードにある間に、ｅＮＢ１０４から送信された１つ以上のダウンリンクデータパケットを受信してもよい。

いくつかの実施例では、ＵＥ１０２は、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）又はＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）モード又はプロトコルに従って動作するよう構成されてもよい。そのような動作の一部として、ＵＥ１０２は、比較的頻繁でないレートで少量のデータをｅＮＢ１０４（又は他のデバイス）と交換してもよい。例えば、１００バイト以下を含むデータブロックは、１分当たり１回未満の頻度でｅＮＢ１０４に送信されてもよい。しかしながら、ブロックサイズは１００バイトに限定されず、いくつかのケースでは、２０、５０、２００、１０００又は他のバイト数などの他のブロックサイズが使用されてもよい。いくつかのケースでは、送信頻度は１分間に１回未満に限定されず、１秒、１０秒、２分間、１０分間、１時間、１日又は他の期間などに１回などの他の送信頻度が利用されてもよい。

いくつかの実施例では、アップリンクデータパケットは、スケジュール又は時間間隔に従ってＵＥ１０２によって送信されてもよい。一例として、ＵＥ１０２は、時間間隔ごとに少なくとも１回、アップリンクデータパケット（又は複数のパケット）を送信するよう構成されてもよい。別の例として、ＵＥ１０２は、規則的な間隔又はほぼ規則的な間隔でアップリンクデータパケットを送信するよう構成されてもよい。別の例として、アップリンクデータパケットの送信は、頻繁には実行されず、スケジュール又は間隔に必ずしも関連していなくてもよい方法で実行されてもよい。

いくつかの実施例では、ｅＮＢ１０４は、ＵＥ１０２によるアップリンクデータパケットの送信レートよりも低いレートでダウンリンクデータパケットをＵＥ１０２に送信するよう構成されてもよい。いくつかの非限定的な例示的なシナリオでは、ＵＥ１０２は、一定間隔でアップリンクデータを送信する一方、ｅＮＢ１０４は、ダウンリンクデータをＵＥ１０２に低い頻度で又は非規則的な間隔で送信してもよい。これらのシナリオのいくつかでは、データの交換は、ｅＮＢ１０４によるダウンリンクデータ送信がほとんど実行されないか、あるいは実行されないように、一般に一方向性であってもよい。それらのシナリオのいくつかにおいて、ダウンリンク制御メッセージが送信されてもよいことが指摘されるべきである。一例として、ＵＥ１０２は、処理のためにｅＮＢ１０４によって他のコンポーネントに転送されてもよいセンサ又は他のコンポーネントからの測定値を送信してもよい。

いくつかの実施例では、ｅＮＢ１０４は、多数のＭＴＣ ＵＥ１０２及び／又は他のＵＥ１０２をサポートしてもよく、いくつかのケースでは、ＵＥのためのＲＲＣ接続の管理は困難かもしれない。例えば、ＲＲＣ接続及びＲＲＣアイドルなどのモード間の頻繁な遷移が存在する可能性がある。ＭＭＥ１２２及びＳ−ＧＷ１２４などの他のコンポーネントへのそのような遷移の通信は、ネットワークリソースに過負荷又はストレスを与える可能性がある。さらに、ＵＥ１０２に対するＲＲＣ接続の確立及び／又は再確立はまた、かなりの量のネットワークリソースを利用しうる。従って、これらのシナリオ及び他のシナリオにおけるＲＲＣ接続の管理技術は有益であり得る。

処理５１５において、ｅＮＢ１０４はＵＥの非アクティブ状態を検出してもよい。いくつかの実施例では、ｅＮＢ１０４は、ＵＥ１０２が非アクティブ状態を判定するための非アクティビティタイマを維持及び／又は監視してもよい。非アクティブ状態は、ＵＥ１０２からのデータメッセージ又は他の通信のｅＮＢ１０４における受信などのイベントに関連してもよい。一例として、ＵＥ１０２は、そのようなイベントが非アクティビティタイマのモニタリング期間中に検出されなかったとき、非アクティブ状態とみなされうる。従って、非アクティビティタイマは満了してもよく、ＵＥ１０２は、ＲＲＣアイドルモードに移行するか、あるいは、移行するよう通知されてもよい。一例として、ＭＴＣモード又はプロトコルに従って動作するよう構成されたＵＥ１０２は、頻繁でないレートでアップリンク送信を実行し、アップリンク送信間の非アクティブ期間がｅＮＢ１０４において検出されてもよい。

処理５２０において、ｅＮＢ１０４は、ＲＲＣ接続のコンテキスト情報を保持する。いくつかの実施例では、コンテキスト情報は、ＲＲＣ接続、アクセス層（ＡＳ）セキュリティコンテキスト及び／又は他の情報若しくは他のパラメータに含まれるデータ無線ベアラ（ＤＲＢ）の識別子を含んでもよい。一例として、ＲＲＣ接続のセキュリティキーはコンテキスト情報に含まれてもよい。いくつかのケースでは、セキュリティキーは対応するＵＥ ＩＤ用であってもよいし、あるいは、対応するＵＥ ＩＤに関連していてもよいが、実施例はこれに限定されない。いくつかの実施例では、コンテキスト情報は、ＲＲＣ接続又は他の接続の確立又は再確立の一部として交換され得る情報を含んでもよい。

一例として、コンテキスト情報は、ＵＥ１０２の非アクティビティタイマが満了したときに保持されてもよい。別の例として、コンテキスト情報は、ＵＥ１０２がＲＲＣアイドルモードに移行したとき、及び／又はＲＲＣアイドルモードに移行するよう通知されたときに保持されてもよい。別の例として、コンテキスト情報は、ＲＲＣ接続に関連する無線ベアラが中断されたときに保持されてもよい。中断された無線ベアラは、確立されたままであるかもしれないが、非アクティブであるかもしれない。別の例として、ｅＮＢ１０４は、ＭＴＣモード又はプロトコルに従って動作するように構成されたＵＥ１０２によるアップリンク送信の間にコンテキスト情報を保持することができる。

従って、ＲＲＣ接続のコンテキスト情報がＵＥ１０２、ｅＮＢ１０４及び／又は他のコンポーネントによって保持されるとき、ＵＥ１０２は、セットアップ処理などのいくつかの処理の実行なしにＲＲＣ接続モードに戻ることが可能であってもよい。このように、セットアップ処理に使用されるネットワークリソースの量の点で利益が実現され得る。さらに、無線ベアラ（無線で）及び／又はＳ１ベアラで送信され得るシグナリングメッセージのサイズの点で利益が実現されてもよい。

処理５２５において、ｅＮＢ１０４は、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥ１０２の遷移を通知するため、ＲＲＣ接続リリースメッセージをＵＥ１０２に送信してもよい。上述されたように、当該遷移は、ｅＮＢ１０４におけるＵＥ１０２の非アクティビティタイマの満了に応答して通知されてもよい。上述されたように、実施例は図５に示される処理の時間順に限定されないことが留意されるべきである。例えば、いくつかの実施例では、処理５２５は、図５に示される順序で必ずしも行われる必要はない。そのような一例が以下に説明される。

いくつかの実施例では、ＲＲＣ接続リリースメッセージは、ＲＲＣ接続のコンテキスト情報のＵＥ１０２による記憶のためのインジケータを含んでもよい。すなわち、インジケータは、コンテキスト情報を格納及び／又は維持するようＵＥ１０２に通知してもよい。いくつかのケースでは、インジケータはまた、ｅＮＢ１０５及び／又は他のコンポーネントがコンテキスト情報を格納及び／又は維持するようＵＥ１０２に通知してもよい。いくつかのケースでは、ＲＲＣ接続リリースメッセージは、ＲＲＣ接続に関連する１つ以上のベアラを解放及び／又は中断するようＵＥ１０２に通知するのに役立つ。いくつかの実施例では、ＲＲＣ接続リリースメッセージは、１つ以上の規格に含まれてもよいが、実施例はそれに限定されない。

図６は、いくつかの実施例によるＲＲＣ接続リリースメッセージの一例を示す。実施例はこれに限定されないが、ＲＲＣ接続リリースメッセージ６００は、３ＧＰＰ規格又は他の規格に含まれ得る“ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅ”メッセージであってもよいし、類似していてもよい。いくつかの実施例は、例示的なメッセージ６００に示されるパラメータのいくつか、何れか又は全てを含んでもよく、いくつかの実施例は、例示的なメッセージ６００に示されていない追加のパラメータも含んでもよいことに留意されたい。さらに、例示的なメッセージ６００に示される順序及びフォーマットは、限定的でなく、説明のために提示される。パラメータ値は、何れか適切な形式で与えられてもよい。一例として、いくつかのパラメータは、イエス／ノー又は類似の値をとるブール値であってもよい。別の例として、いくつかのパラメータは、何れか適切なビット数又は他の桁数の値をとることができる。別の例として、いくつかのパラメータは、記述的な値をとってもよく、いくつかのケースでは、数にマッピングされてもよい。

メッセージ６００は、ＲＲＣ接続が解放されたとき、及び／又はＲＲＣ接続のベアラが中断されたとき、ＲＲＣコンテキスト情報が格納されるべきかどうかを示すコンテキスト記憶インジケータ６１０を含んでもよい。メッセージ６００は、コンテキスト又はＲＲＣ接続の記憶に関連してもよいし、あるいは、していなくてもよい他のパラメータ又は情報６２０を含んでもよい。例えば、メッセージ６００の制御情報が含まれてもよい。

図７は、いくつかの実施例による例示的なメッセージフロー図を示す。いくつかの実施例に関連する可能性のあるメッセージ、インタフェース及びイベントの説明のためにメッセージフロー図７００が参照されるが、図７００は限定的ではない。いくつかの実施例は、ＵＥ１０２、ｅＮＢ１０４、ＭＭＥ１２２及び／又はＳ−ＧＷ１２４において実行されうる処理を含むが、実施例はこれらのデバイスに限定されない。いくつかのケースでは、ここで説明される技術及び概念は、ＲＲＣ接続、ＲＲＣアイドルモード、ＲＲＣ接続モード、ＲＲＣ接続リリース、コンテキスト情報及び／又は他のものを含む、図７に示される処理及び／又はイベントに適用可能であってもよい。いくつかの実施例は、図７に示される１つ以上の処理を含んでもよく、いくつかの実施例はまた、ここに説明される他の処理を含んでもよい。さらに、実施例は、図７に示される処理の時系列に限定されない。

デバイスは、限定することなく、図７に示されたものを含むインタフェースを介し様々なメッセージ、パラメータ及び／又は情報を交換することができる。一例として、ＵＥ１０２及びｅＮＢ１０４は、ＬＴＥ−Ｕｕインタフェース７１０を介し通信してもよい。別の例として、ｅＮＢ１０４及びＭＭＥ１２２は、Ｓ１インタフェース７１５を介し通信してもよい。別の例として、ＭＭＥ１２２及びＳ−ＧＷ１２４は、Ｓ１１インタフェース７２０を介し通信してもよい。

図７を参照して、メッセージフロー図７００は、イベント７２５におけるＵＥ１０２の非アクティビティタイマの満了を示す。いくつかのケースでは、ｅＮＢ１０４は、ＵＥ１０２のコンテキスト情報を保持するかどうかを決定してもよい。処理７３０において、無線ベアラ及び／又はコンテキストが保持されてもよい。また、処理７６０において、ＲＲＣ接続リリースメッセージがｅＮＢ１０４によってＵＥ１０２に送信されてもよいことに留意されたい。上述されたように、いくつかの実施例における処理の順序付けは、図７に示されたものと異なりうる。すなわち、処理７６０は、いくつかのケースでは、示された他の処理の後に必ずしも実行されなくてもよい。

方法５００に戻って、処理５３０において、ｅＮＢ１０４は、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥ１０２の遷移のための１つ以上の制御メッセージのＭＭＥ１２２への送信を制限してもよい。処理５３５において、ｅＮＢ１０４は、ＲＲＣアイドルモードへのＵＥ１０２の遷移を示す１つ以上の制御メッセージをＭＭＥ１２２に送信してもよい。そのようなメッセージの非限定的な例として、“ＵＥ ｃｏｎｔｅｘｔ ｒｅｔａｉｎｅｄ／ＵＥ ｓｔａｔｅ ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ”メッセージが、図７のメッセージフロー図７００の処理７３５においてｅＮＢ１０４によってＭＭＥ１２２に送信されてもよい。このメッセージの一例が以下でより詳細に説明される。

いくつかの実施例では、ｅＮＢ１０４は、制御メッセージを送信し、及び／又はＲＲＣアイドルモードへのＵＥ１０２の遷移をＭＭＥ１２２に通知することを控えるよう構成されてもよい。従って、処理５３５は、これらの実施例の一部から除外されてもよい。いくつかの実施例では、ｅＮＢ１０４は、遷移の通知を遅延させるよう構成されてもよい。例えば、ｅＮＢ１０４は、待機期間中にそのような制御メッセージの送信を制限してもよい。待機期間の後、ｅＮＢ１０４は、ＲＲＣアイドルモードへのＵＥ１０２の遷移を通知するため、１つ以上の制御メッセージをＭＭＥ１２２に送信してもよい。一例として、ｅＮＢ１０４は、リソース可用性、ネットワーク輻輳又は他の要因などの何れか適切な理由のために送信を遅延させてもよく、待機時間は遅延の持続時間を指してもよい。待機時間は、リソース可用性、ネットワーク輻輳及び他の要因がいくつかのケースでは動的であり得るので、固定時間期間に限定されないことに留意されたい。

いくつかの実施例では、待機期間は、所定の期間であってもよいが、これらの実施例は限定的ではない。一例として、待機時間は、ｅＮＢ１０４が遷移をＭＭＥ１２２に通知する時点と遷移との間の時間期間を指してもよい。そのような場合、ｅＮＢ１０４は、ネットワーク輻輳、サポートされるＵＥ１０２の数、送信を待機するｅＮＢ１０４でキューされたメッセージの数又は他の要因などの何れかの数の要因に基づき、ＭＭＥ１２２に通知すべき時点を決定してもよい。通知を遅延させるそのような能力は、システムスループットなどの利用可能なネットワークリソースの使用のためのスケジューリングのフレキシビリティをｅＮＢ１０４に提供しうる。いくつかの実施例は、制御メッセージの送信及び／又はＲＲＣアイドルモードへのＵＥ１０２の遷移の通知の送信のための待機期間を必ずしも含まなくてもよいことに留意されたい。すなわちｅＮＢ１０４は、いくつかのケースでは、待機時間なしに送信及び／又は通知を実行してもよい。

図８は、いくつかの実施例によるＵＥコンテキスト及びＵＥ状態に関する一例となる制御メッセージを示す。実施例はこれに限定されないが、メッセージ８００及び８５０は、３ＧＰＰ規格又は他の規格に含まれうる“ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ”及び／又は“ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ”メッセージであってもよいし、あるいは、同様のものであってもよい。いくつかの実施例は、一例となるメッセージ８００，８５０に示されるパラメータの一部、何れか又は全てを含むものであってもよく、いくつかの実施例はまた一例となるメッセージ８００，８５０に示されない追加的なパラメータを含んでもよいことに留意すべきである。さらに、一例となるメッセージ８００，８５０に示される順序及びフォーマットは限定的でなく、説明のために提示される。パラメータ値は何れか適切なフォーマットで与えられてもよい。一例として、いくつかのパラメータはイエス／ノー又は同様のものなどの値をとるブール値であってもよい。他の例として、いくつかのパラメータは、何れか適切なビット数又は他の桁数の値をとってもよい。他の例として、いくつかのパラメータは、いくつかのケースにおいて数にマッピングされうる記述的な値をとってもよい。

ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ８００は、ｅＮＢ１０４によってＭＭＥ１２２に送信されてもよい。メッセージ８００は、“アイドル、コンテキスト格納”又は“アイドル、コンテキスト中断”などの値をとりうるＵＥ状態通知パラメータ８１０を有してもよい。メッセージ８００は、コンテキストの格納又はＲＲＣ接続に関するものであってもよいし、あるいはそうでなくてもよい他のパラメータ又は情報８２０を有してもよい。例えば、メッセージ８００の制御情報が含まれてもよい。

ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ Ｒｅｓｐｏｎｓｅ／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ８５０は、ＭＭＥ１２２によってｅＮＢ１０４に送信される。非限定的な例として、メッセージ８５０は、ＭＭＥ１２２におけるメッセージ８００の受信に応答して送信される。レスポンスメッセージ８５０は、“受領”、“失敗”又は同様のものなどの値をとりうるＵＥ状態通知レスポンスパラメータ８６０を有してもよい。当該値は、いくつかのケースにおいてメッセージ８００に含まれる状態通知パラメータ８１０を参照してもよい。メッセージ８５０は、コンテキストの格納又はＲＲＣ接続に関するものであってもよいし、あるいはそうでなくてもよい他のパラメータ又は情報８７０を含んでもよい。例えば、メッセージ８５０の制御情報が含まれてもよい。

従って、メッセージ８００は、ｅＮＢ１０４がページングを介しダウンリンク通信を可能にするＵＥ１０２の状態変化をＭＭＥ１２２に通知することを可能にするものであってもよい。いくつかの実施例では、メッセージ８００はまた、ＵＥ１０４が同じｅＮＢ１０４に再接続した際、ｅＮＢ１０４がＵＥ１０２のページングをブロック、停止又は無効にすることを可能にするものであってもよい。メッセージ８００は、ｅＮＢ１０４がＵＥ１０２のコンテキスト情報を格納することを決定したとき、ｅＮＢ１０４によって送信されてもよく、メッセージ８００は、ＵＥ１０２がＲＲＣアイドル又はＲＲＣ接続モードにあるか、またはこれから入ることをＭＭＥ１２２に通知してもよい。メッセージ８００はまた、ＲＲＣアイドルモードへのＵＥの遷移を留意しながら、Ｓ１−Ｕコンテキストを保持し、Ｓ１ベアラを中断するようＳ−ＧＷ１２４に通知するため、ＭＭＥ１２２に対するリクエストとして機能する。

いくつかの実施例では、ｅＮＢ１０４は、ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ８５０又は他のメッセージなどのレスポンスを受信する。このようなメッセージは、ＭＭＥ１２２がＵＥ１０２のＲＲＣ接続のためのコンテキスト情報を維持するため、ｅＮＢ１０４からの決定及び／又はリクエストを受け入れるかどうかをｅＮＢ１０４に通知してもよい。一例として、ＭＭＥ１２２は、当該リクエストを拒絶し、メッセージ８５０又は他のメッセージに理由又は原因を含めてもよい。別の例として、ＭＭＥ１２２は、ＵＥ１０２がＲＲＣアイドルモードにある間、コンテキスト情報を保持し、Ｓ１−Ｕベアラを中断及び／又は保持するため、ＭＭＥ１２２からのリクエスト又は通知に応答して、Ｓ−ＧＷ１２４から拒絶レスポンスを受信する。別の例として、ＭＭＥ１２２は、メッセージ８５０を送信する前に、Ｓ−ＧＷ１２４からのレスポンスを待機してもよい。別の例として、メッセージ８５０は、非同期的に送信されてもよい。図７を参照して、処理７５５において、メッセージ８５０又は同様のメッセージがＭＭＥ１２２によってｅＮＢ１０４に送信されてもよい。

方法５００に戻って、処理５４０において、ｅＮＢ１０４は、Ｓ−ＧＷ１２４から、ＵＥ１０２に転送するためのダウンリンクデータパケットを受信する。ダウンリンクデータパケットは、処理５４５において、ＲＲＣ接続によってＵＥ１０２に転送されてもよい。いくつかの実施例では、当該転送は、ＲＲＣ接続のために保持されたコンテキスト情報に少なくとも部分的に基づくものであってもよい。すなわち、パケットは、ＵＥ１０２がＲＲＣアイドルモードにあるとき、ｅＮＢ１０４において受信され、ＵＥ１０２のために保持されたコンテキストに従って転送されてもよい。この場合、そうでなければ、ｅＮＢ１０４からＭＭＥ１２２及び／又はＳ−ＧＷ１２４（又は更にＭＭＥ１２２とＳ−ＧＷ１２４との間）に送信される１つ以上の制御メッセージは、回避されてもよいし、あるいは、送信される必要がなくてもよい。

いくつかのケースでは、ＲＲＣ接続リリースは、ｅＮＢ１０４におけるＳ−ＧＷ１２４からのパケットの受信に応答して送信されてもよい。すなわち、上述された処理５２５におけるＲＲＣ接続リリースの送信は、いくつかのケースでは、処理５４０に応答して又はその後に実行されてもよい。

例示的なシナリオでは、ｅＮＢ１０４は、ＭＴＣモード又はプロトコル及び／又は他のＵＥ１０２に従って動作するよう構成されたＵＥ１０２など、多数のＵＥ１０２をサポートしうる。ｅＮＢ１０４は、そのような多数のＵＥ１０２のためのＲＲＣ接続リリースメッセージの送信を控えることを所望してもよく、その一部はＲＲＣアイドルモードに頻繁に遷移しうる。ダウンリンクパケットがＵＥ１０２の１つに転送するためにｅＮＢ１０４に到着すると、ＵＥ１０２は、ＲＲＣ接続リリース及び／又はコンテキスト情報を保持するよう通知されていないかもしれない。従って、ｅＮＢ１０４はコンテキスト情報を保持するための指示と共に、ＲＲＣ接続リリースをＵＥ１０２に送信することが必要になる。

別の例のシナリオでは、ｅＮＢ１０４は、多数のＭＴＣ対応ＵＥ１０２及び／又は他のＵＥ１０２を再びサポートしてもよい。ｅＮＢ１０４は、ＲＲＣ接続リリースメッセージを送信するか否か、及び／又は送信する時点についてフレキシビリティを有しうる。そのような決定は、ｅＮＢ１０４によってサポートされるＵＥ１０２の数、ＵＥ１０２のタイプ、ＵＥ１０２の要件又は他の要因に基づくものであってもよい。

処理５５０において、ｅＮＢ１０４は、保持されたコンテキスト情報に従ってＲＲＣ接続上でＵＥ１０２から第２のアップリンクデータパケットを受信する。すなわち、ＵＥ１０２及びｅＮＢ１０４は両方ともコンテキスト情報を保持していてもよく、ＲＲＣ接続は第２のパケット及びおそらく他の後続のアップリンクデータパケットに対して再び使用されてもよい。一例として、第２のアップリンクデータパケットは、ＲＲＣ接続リリースメッセージの送信後にＲＲＣ接続上で受信されてもよく、第１のアップリンクデータパケットは、ＲＲＣ接続リリースメッセージの送信前にＲＲＣ接続上で受信されてもよい。

いくつかの実施例では、ｅＮＢ１０４は、ＲＲＣ接続のＲＲＣアイドルモードからＲＲＣ接続モードへのＵＥ１０２の遷移を示す制御メッセージをＭＭＥ１２２に送信してもよい。非限定的な例として、“ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ＵＥ Ｃｏｎｎｅｃｔｉｏｎ Ｓｕｓｐｅｎｄｅｄ”制御メッセージが利用されてもよい。別の非限定的な例として、“ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ（既存）／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ（新規）”制御メッセージが利用されてもよい。しかしながら、これらの例は、他の制御メッセージ又は他のメッセージが使用され得るので、限定的ではない。

いくつかの実施例では、ＲＲＣ接続モードへの遷移を示す制御メッセージが、ｅＮＢ１０４におけるＲＲＣ接続リクエストの受信に応答して送信されてもよい。すなわち、ｅＮＢ１０４は、ＵＥ１０２がアップリンクパケットの受信に基づきＲＲＣアイドルモードからＲＲＣ接続モードに移行したと判断して、ダウンリンク情報のために利用可能なアップリンクデータ又はページングによってトリガされるライトウェイトＲＲＣ接続確立を開始してもよい。

処理５５５において、ｅＮＢ１０４は、ｅＮＢ１０４と第２のＵＥ１０２との間の第２のＲＲＣ接続のための第２のＲＲＣ接続リリースメッセージを送信する。いくつかの実施例では、第２のＲＲＣ接続リリースメッセージは、コンテキスト情報の格納のためのインジケータを除外してもよい。一例として、第２のＵＥ１０２は、非ＭＴＣモード又は“ノーマル”モードで動作するよう構成されてもよい。この場合、ｅＮＢ１０４は、コンテキスト情報の格納を示すＭＴＣ ＵＥ１０２に対してＲＲＣ接続リリースを送信し、そのようなインジケータを除外する非ＭＴＣ ＵＥ１０２に対してＲＲＣ接続リリースを送信してもよい。従って、いくつかの実施例では、ｅＮＢ１０４は、いくつかのＵＥ１０２に対してコンテキスト情報を維持し、他のＵＥ１０２に対してコンテキスト情報を維持しないことを決定してもよい。

いくつかの実施例では、ｅＮＢ１０４は、ＲＲＣアイドルモードからＲＲＣ接続モードへのＵＥ１０２の遷移に関連する制御メッセージをＭＭＥ１２２と交換してもよい。これに限定されるものでないが、いくつかのケースでは、ＲＲＣアイドルモードへのＵＥ１０２の遷移のための制御メッセージの交換についてここで説明される技術及び／又は処理が利用されてもよい。一例として、ｅＮＢ１０４は、待機期間に従ってそのような制御メッセージのＭＭＥ１２２への送信を遅延してもよい。制御メッセージは、いくつかのケースでは、ＲＲＣ接続リリースメッセージ又は他のメッセージであってもよいし、あるいは、含んでもよい。例えば、ＲＲＣ接続リリースメッセージに含まれるインジケータは、ＲＲＣアイドルモード又はＲＲＣ接続モードへのＵＥ１０２の遷移を示すものであってもよい。

図９は、いくつかの実施例による他の通信方法の処理を示す。方法５００に関して上述されたように、方法９００の実施例は、図９に示されているものと比較して、追加的又はさらに少数の処理又はプロセスを含んでもよく、方法９００の実施例は、図９に示される時系列順に必ずしも限定されない。方法９００を説明する際、図１〜８，１１が参照されてもよいが、方法９００が他の何れか適切なシステム、インタフェース及びコンポーネントによって実施されてもよいことが理解される。さらに、ここで説明される技術及び概念は、いくつかのケースでは、ＲＲＣ接続、ＲＲＣアイドルモード、ＲＲＣ接続モード、ＲＲＣ接続リリース、コンテキスト情報及び／又は他のものを含む方法９００に適用可能でありうる。

方法９００はＭＭＥ１２２で実施されてもよく、ｅＮＢ１０４との信号又はメッセージの交換を含んでもよいことに留意すべきである。同様に、方法５００はｅＮＢ１０４において実施されてもよく、ＭＭＥ１２２との信号又はメッセージの交換を含んでもよい。いくつかのケースにおいて、方法５００の一部として説明される処理及び／又は技術は、方法９００に関連してもよい。例えば、方法５００の処理は、ｅＮＢ１０４によるメッセージの送信を含んでもよく、方法９００の処理は、ＭＭＥ１２２における同じメッセージ又は同様のメッセージの受信を含んでもよい。

方法９００の処理９０５において、ＭＭＥ１２２は、ＲＲＣ接続上でＵＥ１０２とデータパケットを交換するよう構成されたｅＮＢ１０４からＵＥ状態変更メッセージを受信する。いくつかの実施例では、当該メッセージは、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥ１０２の遷移を示すものであってもよい。いくつかのケースでは、当該遷移は、上述したように、ｅＮＢ１０４における非アクティビティタイマの満了の結果として行われてもよい。当該メッセージはまた、ＲＲＣ接続のコンテキスト情報を維持するためのｅＮＢ１０４によるリクエストを示すものであってもよい。いくつかのケースでは、Ｓ−ＧＷ１２は、ＲＲＣ接続上でＵＥ１０２に転送するため、ｅＮＢ１０４にダウンリンクデータパケットを送信するよう構成されてもよい。ＭＭＥ１２２において受信されたＵＥ状態変更メッセージは、Ｓ１ベアラのためのコンテキスト情報を維持するようＳ−ＧＷ１２４に暗黙的に要求するためのｅＮＢ１０４によるリクエストを示すものであってもよい。非限定的な例として、ＭＭＥ１２２において受信されたＵＥ状態変更メッセージは、ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ８００と類似するか、あるいは同じであってもよい。図７を参照して、ＵＥ状態変更メッセージは、処理７４０において、ｅＮＢ１０４によってＭＭＥ１２２に送信されてもよい。

方法９００の処理９１０において、ＭＭＥ１２２は、ＵＥ状態変更メッセージをＳ−ＧＷ１２４に転送してもよい。従って、ＭＭＥ１２２は、Ｓ−ＧＷ１２４に対して、Ｓ１ベアラについてコンテキスト情報が保持されることを要求してもよいし、あるいは、Ｓ−ＧＷ１２４がコンテキスト情報を保持することができるか否かを問い合わせてもよい。いくつかのケースでは、当該リクエストはｅＮＢ１０４の代わりに行われてもよいことに留意されたい。一例として、後述する“ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ ａｎｄ Ｓ１ Ｒｅｕｓｅ Ｒｅｑｕｅｓｔ”メッセージが使用されてもよいが、実施例はこのメッセージに限定されない。さらに、ＭＭＥ１２２からＳ−ＧＷ１２４への当該メッセージ又は同様のメッセージの送信が、図７の処理７４０に含まれてもよい。

処理９１５において、ＭＭＥ１２２は、Ｓ−ＧＷ１２４からのリクエストに関連するフィードバックを受信してもよい。従って、フィードバックは、コンテキスト情報がＳ１ベアラについて保持され得るかどうかを示すものであってもよい。いくつかのケースでは、フィードバックは、Ｓ１ベアラに対するコンテキスト情報の保持をサポートするかどうかのＳ−ＧＷ１２４による決定を示すものであってもよい。一例として、以下で説明する“Ｓ１ Ｒｅｕｓｅ Ｒｅｓｐｏｎｓｅ ａｎｄ ＵＥ Ｓｔａｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ”メッセージが利用されてもよいが、実施例は当該メッセージに限定されない。さらに、Ｓ−ＧＷ１２４からＭＭＥ１２２への当該メッセージ又は同様のメッセージの送信は、図７の処理７５０において含まれてもよい。

処理７４５において、Ｓ−ＧＷ１２４は、Ｓ１−ＵベアラがＲＲＣ接続のためＵＥ１０２に対して保持されるか否か判断することに留意すべきである。この決定は、処理９１０におけるＭＭＥ１２２からＳ−ＧＷ１２４に送信されるＵＥ状態変更メッセージに含まれる１つ以上のインジケータ又は他の情報に少なくとも部分的に基づくものであってもよい。当該決定はまた、ＵＥ１０２及び／又は他のＵＥ１０２のコンテキストを保持するＳ−ＧＷ１２４の能力に少なくとも部分的に基づくものであってもよい。いくつかのケースでは、Ｓ−ＧＷ１２４は、Ｓ１−Ｕベアラが利用の準備ができているか否か決定してもよい。その一例が以下に図１１において以下に提示される。

方法９００の処理９２０において、ＭＭＥ１２２は、ＲＲＣ接続のコンテキスト保持制御メッセージをｅＮＢ１０４に送信する。当該メッセージは、ＲＲＣ接続上のデータパケットの以降の交換のためのコンテキスト情報の保持のサポートを示すものであってもよい。いくつかの実施例では、コンテキスト情報の保持をサポートするかどうかの決定は、ＲＲＣ接続の確立の一部としてＭＭＥ１２２において受信されるＵＥ１０２の能力情報に少なくとも部分的に基づくものであってもよい。いくつかの実施例では、Ｓ−ＧＷ１２４がＳ１ベアラのコンテキスト情報の保持をサポートするか否かに少なくとも部分的に基づき決定されてもよい。

いくつかの実施例では、コンテキスト保持制御メッセージは、ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅメッセージ８５０と同様であってもよいし、あるいは、同じであってもよい。図７を参照して、コンテキスト保持制御メッセージ及び／又はメッセージ８５０が、処理７５５において、ＭＭＥ１２２によってｅＮＢ１０４に送信される。従って、コンテキスト保持制御メッセージは、ＭＭＥ１２２がＲＲＣ接続のコンテキスト情報を保持するためのリクエストをｅＮＢ１０４から受け付けるか示すものであってもよい。コンテキスト保持制御メッセージはまた、Ｓ−ＧＷ１２４がＳ１ベアラのコンテキスト情報を保持するリクエストを受け入れるか否かを示すものであってもよい。非限定的な例として、ＭＭＥ１２２において受信されたＵＥ状態変更メッセージは、ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎメッセージ８００と同様であってもよいし、あるいは、同じであってもよい。図７を参照すると、処理７４０において、ＵＥ状態変更メッセージが、ｅＮＢ１０４によってＭＭＥ１２２に送信される。

図１０は、いくつかの実施例によるＵＥコンテキスト及びＵＥ状態に関する更なる一例となる制御メッセージを示す。実施例はそれに限定されないが、メッセージ１０００，１０５０は、３ＧＰＰ規格又は他の規格に含まれる“ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ ａｎｄ Ｓ１ Ｒｅｕｓｅ Ｒｅｑｕｅｓｔ”及び／又は“Ｓ１ Ｒｅｕｓｅ Ｒｅｓｐｏｎｓｅ ａｎｄ ＵＥ Ｓｔａｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ”メッセージであってもよいし、あるいは、同様のものであってもよい。いくつかの実施例は、例示的なメッセージ１０００，１０５０に示されるパラメータのいくつか、何れか又は全てを含んでもよく、いくつかの実施例はまた、例示的なメッセージ１０００，１０５０に示されていない追加的パラメータも含んでもよいことに留意されたい。さらに、例示的なメッセージ１０００，１０５０に示される順序及びフォーマットは限定的なものでなく、説明のために提示される。パラメータ値は何れか適切な形式で与えられてもよい。一例として、いくつかのパラメータは、イエス／ノー又は同様の値をとるブール値であってもよい。別の例として、いくつかのパラメータは、何れか適切なビット数又は他の桁数の値をとることができる。別の例として、いくつかのパラメータは記述的な値を取ることがあり、いくつかのケースでは数値にマッピングされてもよい。

ＵＥ Ｓｔａｔｅ Ｃｈａｎｇｅ Ｎｏｔｉｆｉｃａｔｉｏｎ ａｎｄ Ｓ１ Ｒｅｕｓｅ Ｒｅｑｕｅｓｔメッセージ１０００は、ＭＭＥ１２２によってＳ−ＧＷ１２４に送信される。メッセージ１０００は、“ＵＥ ｓｔａｔｅ ｃｈａｎｇｅ ｔｏ Ｉｄｌｅ”又は“ＵＥ ｓｔａｔｅ ｃｈａｎｇｅ ｔｏ Ｃｏｎｎｅｃｔｅｄ”んまどの値をとりうる１つ以上のＵＥ状態インジケータ１０１０を含んでもよい。メッセージ１００は、コンテキストの格納又はＲＲＣ接続に関連するか、あるいは関連しない他のパラメータ又は情報１０２０を含んでもよい。例えば、メッセージ１０００の制御情報が含まれてもよい。

Ｓ１ Ｒｅｕｓｅ Ｒｅｓｐｏｎｓｅ ａｎｄ ＵＥ Ｓｔａｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ１０５０は、Ｓ−ＧＷ１２４によってＭＭＥ１２２に送信されてもよい。非限定的な例として、メッセージ１０５０は、Ｓ−ＧＷ１２４におけるメッセージ１０００の受信に応答して送信されてもよい。レスポンスメッセージ８５０は、ＵＥ１０２のコンテキスト情報の保持及び／又はＳ１ベアラの解放に関連するコンテキストストレージインジケータ１０６０を含んでもよい。一例として、コンテキストストレージインジケータ１０６０は、Ｓ１ベアラがリリースされること、及び／又はコンテキスト情報が保持されないことをＭＭＥ１２２に通知してもよい。例えば、Ｓ１リリースが差し迫っている場合、又はコンテキスト情報の保持が不可能である場合、インジケータ１０６０は“１”の値に設定されてもよい。メッセージ１０５０は、ＲＲＣ接続又はコンテキストの格納に関連するか、あるいは、関連しない他のパラメータ又は情報１０７０を含んでもよい。例えば、メッセージ１０５０の制御情報が含まれてもよい。

図１１は、いくつかの実施例による他の一例となるメッセージフロー図を示す。いくつかの実施例に関連するメッセージ、インタフェース及びイベントの説明のためにメッセージフロー図１１００が参照されてもよいが、図１１００は限定的ではない。いくつかの実施例は、ＵＥ１０２、ｅＮＢ１０４、ＭＭＥ１２２及び／又はＳ−ＧＷ１２４において実行される処理を含んでもよいが、実施例はこれらのデバイスに限定されない。いくつかの実施例では、ＵＥ１０２はリモートUＵＥ１０２であってもよいが、これらの実施例は限定的ではない。いくつかのケースにおいて、ここで説明される技術及び概念は、ＲＲＣ接続、ＲＲＣアイドルモード、ＲＲＣ接続モード、ＲＲＣ接続リリース、コンテキスト情報及び／又は他のものを含む、図１１に示される処理及び／又はイベントに適用可能であってもよい。いくつかの実施例は、図１１に示される１つ以上の処理を含んでもよく、いくつかの実施例はまた、ここに説明される他の処理を含んでもよい。さらに、実施例は、図１１に示される処理の時系列順に限定されない。

図１１を参照して、一例となるメッセージフロー図１１００は、リモートＵＥ１０２がネットワークカバレッジ内にあって、ｅＮＢ１０４とアイドルであり、“ライトウェイト”設定を利用してｅＮＢ１０４に再接続するケースに適用可能である。ｅＮＢ１０４は、リモートＵＥ１０２のコンテキスト情報を格納し、モビリティアンカーとして動作してもよい。リモートＵＥ１０２は、１１１５によって示されるように、ＲＲＣアイドルモードにあってもよい。アクセス手順１１３０は、リモートＵＥ１０２によるｅＮＢへのアクセスリクエストの送信を含んでもよく、それは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）プリアンブル及び／又は他のメッセージを含むことができる。アクセス手順１１３０はまた、ランダムアクセスレスポンス（ＲＡＲ）及び／又は他のメッセージを含むアクセスレスポンスのｅＮＢ１０４によるリモートＵＥ１０２への送信を含んでもよい。処理１１３２において、リモートＵＥ１０２は、リモートＵＥ１０２の識別子（ＵＥ ＩＤ）、確立原因及び／又は他のパラメータ若しくは情報などの情報を含むライトウェイトリクエストをｅＮＢ１０４に送信してもよい。ライトウェイトリクエストは、リモートＵＥ１０２からの接続リクエストであってもよいし、あるいは、含んでもよい。処理１１３５、１１４０、１１５０、１１５５及びその他を含むメッセージ交換は、リモートＵＥ１０２によるライトウェイト要求の送信及び／又はｅＮＢ１０４におけるライトウェイトリクエストの受信に応答して実行されてもよい。

図１１に示されるように、いくつかの実施例では、処理１１３５、１１４０、１１５０及び１１５５の何れか又は全てが含まれてもよい。このような処理は、図７の例示的なメッセージフロー図７００に関して説明した処理と同様であってもよいが、実施例はこれに限定されない。処理１１３５、１１４０、１１５０、１１５５及びその他を含むメッセージ交換は、リモートＵＥ１０２によるライトウェイトリクエストの送信及び／又はｅＮＢ１０４におけるライトウェイトリクエストの受信に応答して実行されてもよい。

処理１１４５において、Ｓ−ＧＷ１２４は、Ｓ１−ＵベアラがＲＲＣ接続のためにＵＥ１０２に準備されているか否かを判断してもよいことに留意すべきである。さらに、１１６０によって示されるように、リモートＵＥ１０２はＥＣＭ接続状態に入ってもよい。処理１１６５において、ｅＮＢ１０４は、リモートＵＥ１０２が接続されていることを示すための“ｌｉｇｈｔｗｅｉｇｈｔ ａｎｄ ｒｅｓｏｕｒｃｅ ａｌｌｏｃａｔｉｏｎ ｒｅｓｐｏｎｓｅ”メッセージ又は他のメッセージ及び／又は他の情報をリモートＵＥ１０２に送信する。

ＵＥ１０２がイニシャルアタッチ／接続設定においてコアネットワークとネゴシエートし、ＭＭＥ１２２が光接続をサポートする（図１１など）ことに合意した場合、ＵＥ１０２の接続の解放に応答して、ｅＮＢ１０４がＭＭＥ１２２及び／又はＳ−ＧＷ１２４に即座に通知する必要はないことに留意すべきである。従って、シグナリングの節約は、ＵＥ１０２がダウンリンクデータを受信しないときなど、いくつかのケースに大手実現されてもよい。いくつかの実施例では、（ＭＭＥ１２２が光接続をサポートするため）上述したネゴシエーションは、ＭＭＥ１２２及び／又はＳ−ＧＷ１２４がＳ１−Ｕベアラコンテキストの格納をサポートするための持続時間を判断又は決定するため拡張されてもよいことに留意すべきである。一例として、タイマがこの目的のため利用されてもよい。

具体例１では、進化型ノードＢ（ｅＮＢ）のための装置は、ハードウェア処理回路と送受信回路とを有してもよい。ハードウェア処理回路は、ｅＮＢとユーザ装置（ＵＥ）との間の無線リソース制御（ＲＲＣ）接続上でＵＥからアップリンクデータパケットを受信するよう送受信回路を設定してもよい。ハードウェア処理回路は更に、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥの遷移を通知するため、ＲＲＣ接続リリースメッセージをＵＥに送信するよう送受信回路を設定してもよい。
を実行するよう前記送受信回路を設定し、ＲＲＣ接続リリースメッセージは、ＵＥがＲＲＣ接続のコンテキスト情報を格納するか否かのインジケータを含んでもよい。

具体例２では、具体例１の主題は、ＵＥがコンテキスト情報を格納するか否かのインジケータは、ＵＥがＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）又はＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）処理のため設定されているか否かに少なくとも部分的に基づくものであってもよい。

具体例３では、具体例１〜２の１つ又は何れかの組み合わせの主題は、ＲＲＣ接続リリースメッセージは、ｅＮＢにおけるＵＥの非アクティビティタイマの満了に応答して送信されてもよい。

具体例４では、具体例１〜３の１つ又は何れかの組み合わせの主題は、コンテキスト情報は、ＲＲＣ接続に含まれるデータラジオベアラ（ＤＲＢ）の識別子と、ＲＲＣ接続のセキュリティキーのインジケータとを含んでもよい。

具体例５では、具体例１〜４の１つ又は何れかの組み合わせの主題は、ＲＲＣ接続リリースメッセージは更に、ＲＲＣ接続に含まれるＤＲＢの中断を示すものであってもよい。

具体例６では、具体例１〜５の１つ又は何れかの組み合わせの主題は、ＲＲＣ接続リリースメッセージが、ＵＥがＲＲＣ接続のコンテキスト情報を格納することを示すとき、ハードウェア処理回路は、ＲＲＣ接続のコンテキスト情報を保持するよう構成されてもよい。

具体例７では、具体例１〜６の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、ＲＲＣ接続上でＵＥにダウンリンクデータパケットを転送するよう送受信回路を設定してもよい。当該転送は保持されるコンテキスト情報に少なくとも部分的に基づくものであってもよい。

具体例８では、具体例１〜７の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、ＲＲＣ接続は、ｅＮＢがライトウェイトＲＲＣ接続のリリースのモビリティマネージメントエンティティ（ＭＭＥ）への通知を遅延させることが許可されるライトウェイトＲＲＣ接続であるというインジケータをＭＭＥに送信するよう送受信回路を設定してもよい。ハードウェア処理回路は更に、保持されるコンテキスト情報に従ってライトウェイトＲＲＣ接続上で第２のアップリンクデータパケットをＵＥから受信するよう送受信回路に設定してもよい。

具体例９では、具体例１〜８の１つ又は何れかの組み合わせの主題は、ＲＲＣ接続がライトウェイトＲＲＣ接続であるというインジケータが、“ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｔａｉｎｅｄ／ＵＥ Ｃｏｎｎｅｃｔｉｏｎ Ｓｕｓｐｅｎｄｅｄ”ＲＲＣ制御メッセージに含まれてもよい。

具体例１０では、具体例１〜９の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、サービングゲートウェイ（Ｓ−ＧＷ）に転送するため、ＲＲＣ接続のＲＲＣアイドルモードからＲＲＣ接続モードへのＵＥの遷移を通知する制御メッセージをＭＭＥに送信するよう送受信回路を設定してもよい。当該制御メッセージは、ＵＥからの接続リクエストメッセージの受信に応答して送信されてもよい。

具体例１１では、具体例１〜１０の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、保持されるコンテキスト情報に従ってＲＲＣ接続上でＵＥから第２のアップリンクデータパケットを受信するよう送受信回路を設定してもよい。

具体例１２では、具体例１〜１１の１つ又は何れかの組み合わせの主題は、第２のアップリンクデータパケットは、ＲＲＣ接続リリースメッセージの送信後に受信されてもよい。アップリンクデータパケットは、ＲＲＣ接続リリースメッセージの送信前に受信されてもよい。

具体例１３では、具体例１〜１２の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、モビリティマネージメントエンティティ（ＭＭＥ）とＲＲＣ接続の１つ以上の設定制御メッセージを交換するよう送受信回路を設定してもよい。ハードウェア処理回路は更に、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥの遷移のための制御メッセージの送信をＭＭＥに制限するよう送受信回路を設定してもよい。

具体例１４では、具体例１〜１３の１つ又は何れかの組み合わせの主題は、送信の制限は、待機期間中に実行され、ハードウェア処理回路は更に、待機時間後に制御メッセージを送信するよう送受信回路を設定してもよい。

具体例１５では、具体例１〜１４の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、モビリティマネージメントエンティティ（ＭＭＥ）とＲＲＣ接続の１つ以上の設定制御メッセージを交換するよう送受信回路を設定してもよい。ハードウェア処理回路は更に、ＲＲＣアイドルモードからＲＲＣ接続モードへのＵＥの遷移を通知する制御メッセージをＭＭＥに送信するよう送受信回路を設定する。

具体例１６では、具体例１〜１５の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、モビリティマネージメントエンティティ（ＭＭＥ）とＲＲＣ接続の１つ以上の設定制御メッセージを交換するよう送受信回路を設定してもよい。ハードウェア処理回路は更に、ＲＲＣ接続のＲＲＣアイドルモードからＲＲＣ接続モードへのＵＥの遷移を通知する制御メッセージをＭＭＥに送信するよう送受信回路を設定してもよい。

具体例１７では、具体例１〜１６の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、ｅＮＢと第２のＵＥとの間の第２のＲＲＣ接続の第２のＲＲＣ接続リリースメッセージを送信するよう送受信回路を設定してもよい。第２のＲＲＣ接続リリースメッセージは、第２のＲＲＣ接続のコンテキスト情報の格納のためのインジケータを除外してもよい。ＵＥはＭＴＣ処理のため設定され、第２のＵＥは非ＭＴＣ処理のため設定されてもよい。

具体例１８では、具体例１〜１７の１つ又は何れかの組み合わせの主題は、装置は、アップリンクデータパケットの受信とＲＲＣ接続リリースメッセージの送信とのため、送受信回路に結合される１つ以上のアンテナを含んでもよい。

具体例１９では、非一時的なコンピュータ可読記憶媒体は、進化型ノードＢ（ｅＮＢ）による通信のための処理を実行する１つ以上のプロセッサによる実行用の命令を記憶してもよい。当該処理は、ｅＮＢとユーザ装置（ＵＥ）とがｅＮＢとＵＥとの間の無線リソース制御（ＲＲＣ）接続のためのコンテキスト情報を保持することを通知するＲＲＣ接続リリースメッセージを送信するよう１つ以上のプロセッサを設定してもよい。当該処理は更に、保持されるコンテキスト情報に従ってＲＲＣ接続上でＵＥからアップリンクデータパケットを受信するよう１つ以上のプロセッサを設定してもよい。

具体例２０では、具体例１９の主題は、ＲＲＣ接続リリースメッセージは更に、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥの遷移を通知してもよい。

具体例２１では、具体例１９〜２０の１つ又は何れかの組み合わせの主題は、アップリンクデータパケットは、ＲＲＣ接続リリースメッセージの送信後に受信されてもよい。

具体例２２では、具体例１９〜２１の１つ又は何れかの組み合わせの主題は、ＲＲＣ接続リリースメッセージは、ＵＥの非アクティビティタイマのｅＮＢにおける満了に応答して送信されてもよい。

具体例２３では、モビリティマネージメントエンティティ（ＭＭＥ）のための装置は、ハードウェア処理回路と送受信回路とを有してもよい。ハードウェア処理回路は、無線リソース制御（ＲＲＣ）接続上でユーザ装置（ＵＥ）とデータパケットを交換するよう構成される進化型ノードＢ（ｅＮＢ）から、ＲＲＣ接続のＲＲＣアイドルモードへのＵＥの遷移を通知するＵＥ状態変更メッセージを受信するよう送受信回路を設定してもよい。ハードウェア処理回路は更に、ＲＲＣ接続上のデータパケットの以降の交換のため、ＲＲＣ接続のコンテキスト情報のｅＮＢ及びＵＥによる保持のためのコンテキスト保持制御メッセージを送信するよう送受信回路を設定してもよい。

具体例２４では、具体例２３の主題は、ＵＥ状態変更メッセージは、ＲＲＣ接続のコンテキスト情報を保持するリクエストを通知してもよい。コンテキスト保持制御メッセージは、コンテキスト情報を保持するリクエストのＭＭＥによる受入レスポンスを通知してもよい。

具体例２５では、具体例２３〜２４の１つ又は何れかの組み合わせの主題は、ハードウェア処理回路は更に、ＵＥ状態変更メッセージをサービングゲートウェイ（Ｓ−ＧＷ）に転送するよう送受信回路を設定してもよい。Ｓ−ＧＷは、ＲＲＣ接続上でＵＥに転送するため、ｅＮＢにダウンリンクデータパケットを送信するよう構成されてもよい。コンテキスト情報を保持するリクエストの受入は、Ｓ−ＧＷからのフィードバックに基づくものであってもよい。

具体例２６では、具体例２３〜２５の１つ又は何れかの組み合わせの主題は、コンテキスト情報を保持するリクエストの受入は、ＲＲＣ接続の確立の一部としてＭＭＥにおいて受信されるＵＥの能力情報に少なくとも部分的に基づくものであってもよい。

具体例２７では、具体例２３〜２６の１つ又は何れかの組み合わせの主題は、コンテキスト情報を保持するリクエストの受入は、ＵＥがＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）処理又はＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）処理のために設定されているか否かに少なくとも部分的に基づくものであってもよい。

要約は、読者が技術的開示の性質及び概要を確認することを可能にする要約を要求する３７Ｃ．Ｆ．Ｒ．Ｓｅｃｔｉｏｎ １．７２（ｂ）に準拠するよう提供される。それは、請求項の範囲又は意味を限定又は解釈するのにそれが利用されないという理解により提出されている。以下の請求項は詳細な説明に含まれ、各請求項は別々の実施例としてそれぞれ成立する。

Claims (17)

1. セルラＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）処理のために構成される進化型ノードＢ（ｅＮＢ）の装置であって、
   メモリと、
   ＩｏＴユーザ装置（ＵＥ）のＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続中断手順を開始するよう前記ｅＮＢを設定する処理回路と、
   を有し、
   前記ＲＲＣ接続中断手順の一部として、前記処理回路は、
   Ｓ１インタフェースを介しＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）への送信のため、前記ＵＥのＲＲＣ接続の中断を示し、前記ＵＥのコンテキストを中断するためのＵＥコンテキスト中断リクエストメッセージを符号化し、
   前記Ｓ１インタフェースを介し前記ＭＭＥから受信したシグナリングから、前記ＵＥコンテキスト中断リクエストメッセージをアクノリッジするＵＥコンテキスト中断レスポンスメッセージを復号化し、
   前記ＵＥコンテキスト中断レスポンスメッセージを受信したことに応答して、前記ＵＥへの送信のため、前記ＵＥのＲＲＣ接続を中断するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを符号化するよう構成され、
   前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージは、前記ＵＥに前記ＲＲＣ接続を中断し、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）コンテキストを格納するよう通知するための１つ以上のインジケータを含み、前記ＲＲＣ接続の中断中、１つ以上の中断されたＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）が確立されて非アクティブなままであり、前記メモリは前記１つ以上のインジケータを格納するよう構成され、前記ＵＥコンテキスト中断レスポンスメッセージはセキュリティコンテキスト情報を含み、前記セキュリティコンテキスト情報は前記ＵＥの前記ＲＲＣ接続のためのセキュリティキーを含み、前記セキュリティコンテキスト情報は、セキュリティキーを導出するのに利用されるセキュリティ関連パラメータを前記ｅＮＢに提供する装置。
2. 前記１つ以上のインジケータは、前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージの原因を示す、請求項１記載の装置。
3. 前記１つ以上のインジケータは、前記ＲＲＣ接続の中断を含む原因を示す、請求項１又は２記載の装置。
4. ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ） ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）の装置であって、
   メモリと、
   ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続中断手順を実行するよう前記ＵＥを設定する処理回路と、
   を有し、
   前記ＲＲＣ接続中断手順の一部として、前記処理回路は、
   進化型ノードＢ（ｅＮＢ）から受信したシグナリングから、前記ＵＥのＲＲＣ接続を中断するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを復号化し、前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージは、前記ＵＥに前記ＲＲＣ接続を中断し、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）セキュリティコンテキストを格納するよう通知するための１つ以上のインジケータを含み、前記ＲＲＣ接続の中断中、１つ以上の中断されたＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）が確立されて非アクティブなままであり、
   前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを受信したことに応答して、前記メモリに前記ＡＳコンテキストを少なくとも格納し、前記ＲＲＣ接続のＤＲＢを中断し、ＲＲＣアイドルモードに入るよう構成され、前記ＵＥコンテキスト中断レスポンスメッセージはセキュリティコンテキスト情報を含み、前記セキュリティコンテキスト情報は前記ＵＥの前記ＲＲＣ接続のためのセキュリティキーを含み、前記セキュリティコンテキスト情報は、セキュリティキーを導出するのに利用されるセキュリティ関連パラメータを前記ｅＮＢに提供する装置。
5. 前記１つ以上のインジケータは、前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージの原因を示す、請求項４記載の装置。
6. 前記１つ以上のインジケータは、前記ＲＲＣ接続の中断を含む原因を示す、請求項４又は５記載の装置。
7. セルラＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）処理のために構成される進化型ノードＢ（ｅＮＢ）の１つ以上のプロセッサによる実行用の命令を格納するコンピュータ可読ハードウェア記憶装置であって、
   前記命令は、
   ＩｏＴユーザ装置（ＵＥ）のＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続中断手順を開始するよう前記１つ以上のプロセッサを設定し、
   前記ＲＲＣ接続中断手順の一部として、前記命令は、
   Ｓ１インタフェースを介しＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）への送信のため、前記ＵＥのＲＲＣ接続の中断を示し、前記ＵＥのコンテキストを中断するためのＵＥコンテキスト中断リクエストメッセージを符号化し、
   前記Ｓ１インタフェースを介し前記ＭＭＥから受信したシグナリングから、前記ＵＥコンテキスト中断リクエストメッセージをアクノリッジするＵＥコンテキスト中断レスポンスメッセージを復号化し、
   前記ＵＥコンテキスト中断レスポンスメッセージを受信したことに応答して、前記ＵＥへの送信のため、前記ＵＥのＲＲＣ接続を中断するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを符号化するよう前記１つ以上のプロセッサを設定し、
   前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージは、前記ＵＥに前記ＲＲＣ接続を中断し、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）コンテキストを格納するよう通知するための１つ以上のインジケータを含み、前記ＲＲＣ接続の中断中、１つ以上の中断されたＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）が確立されて非アクティブなままであり、前記ＵＥコンテキスト中断レスポンスメッセージはセキュリティコンテキスト情報を含み、前記セキュリティコンテキスト情報は前記ＵＥの前記ＲＲＣ接続のためのセキュリティキーを含み、前記セキュリティコンテキスト情報は、セキュリティキーを導出するのに利用されるセキュリティ関連パラメータを前記ｅＮＢに提供する記憶装置。
8. 前記１つ以上のインジケータは、前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージの原因を示す、請求項７記載の記憶装置。
9. 前記１つ以上のインジケータは、前記ＲＲＣ接続の中断を含む原因を示す、請求項７又は８記載の記憶装置。
10. ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ユーザ装置（ＵＥ）の１つ以上のプロセッサによる実行用の命令を格納するコンピュータ可読ハードウェア記憶装置であって、
    前記命令は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続中断手順を実行するよう前記ＵＥを設定するよう前記１つ以上のプロセッサを設定し、
    前記ＲＲＣ接続中断手順の一部として、前記命令は、
    進化型ノードＢ（ｅＮＢ）から受信したシグナリングから、前記ＵＥのＲＲＣ接続を中断するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを復号化し、前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージは、前記ＵＥに前記ＲＲＣ接続を中断し、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）セキュリティコンテキストを格納するよう通知するための１つ以上のインジケータを含み、前記ＲＲＣ接続の中断中、１つ以上の中断されたＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）が確立されて非アクティブなままであり、
    前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを受信したことに応答して、前記メモリに前記ＡＳコンテキストを少なくとも格納し、前記ＲＲＣ接続のＤＲＢを中断し、ＲＲＣアイドルモードに入るよう前記１つ以上のプロセッサを設定し、
    前記ＵＥコンテキスト中断レスポンスメッセージはセキュリティコンテキスト情報を含み、前記セキュリティコンテキスト情報は前記ＵＥの前記ＲＲＣ接続のためのセキュリティキーを含み、前記セキュリティコンテキスト情報は、セキュリティキーを導出するのに利用されるセキュリティ関連パラメータを前記ｅＮＢに提供する記憶装置。
11. 前記１つ以上のインジケータは、前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージの原因を示す、請求項１０記載の記憶装置。
12. 前記１つ以上のインジケータは、前記ＲＲＣ接続の中断を含む原因を示す、請求項１０又は１１記載の記憶装置。
13. ＩｏＴユーザ装置（ＵＥ）のＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続中断手順を開始するよう進化型ノードＢ（ｅＮＢ）を設定することを含む方法であって、
    前記ＲＲＣ接続中断手順は、
    Ｓ１インタフェースを介しＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）への送信のため、前記ＵＥのＲＲＣ接続の中断を示し、前記ＵＥのコンテキストを中断するためのＵＥコンテキスト中断リクエストメッセージを符号化し、
    前記Ｓ１インタフェースを介し前記ＭＭＥから受信したシグナリングから、前記ＵＥコンテキスト中断リクエストメッセージをアクノリッジするＵＥコンテキスト中断レスポンスメッセージを復号化し、
    前記ＵＥコンテキスト中断レスポンスメッセージを受信したことに応答して、前記ＵＥへの送信のため、前記ＵＥのＲＲＣ接続を中断するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを符号化することを含み、
    前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージは、前記ＵＥに前記ＲＲＣ接続を中断し、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）コンテキストを格納するよう通知するための１つ以上のインジケータを含み、前記ＲＲＣ接続の中断中、１つ以上の中断されたＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）が確立されて非アクティブなままであり、前記ＵＥコンテキスト中断レスポンスメッセージはセキュリティコンテキスト情報を含み、前記セキュリティコンテキスト情報は前記ＵＥの前記ＲＲＣ接続のためのセキュリティキーを含み、前記セキュリティコンテキスト情報は、セキュリティキーを導出するのに利用されるセキュリティ関連パラメータを前記ｅＮＢに提供する方法。
14. セルラＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）処理のために構成される進化型ノードＢ（ｅＮＢ）の装置であって、
    ＩｏＴユーザ装置（ＵＥ）のＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続中断手順を開始するよう前記ｅＮＢを設定する手段を有し、
    前記ＲＲＣ接続中断手順は、
    Ｓ１インタフェースを介しＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）への送信のため、前記ＵＥのＲＲＣ接続の中断を示し、前記ＵＥのコンテキストを中断するためのＵＥコンテキスト中断リクエストメッセージを符号化し、
    前記Ｓ１インタフェースを介し前記ＭＭＥから受信したシグナリングから、前記ＵＥコンテキスト中断リクエストメッセージをアクノリッジするＵＥコンテキスト中断レスポンスメッセージを復号化し、
    前記ＵＥコンテキスト中断レスポンスメッセージを受信したことに応答して、前記ＵＥへの送信のため、前記ＵＥのＲＲＣ接続を中断するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを符号化することを含み、
    前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージは、前記ＵＥに前記ＲＲＣ接続を中断し、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）コンテキストを格納するよう通知するための１つ以上のインジケータを含み、前記ＲＲＣ接続の中断中、１つ以上の中断されたＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）が確立されて非アクティブなままであり、
    前記１つ以上のインジケータを格納する手段を含み、
    前記ＵＥコンテキスト中断レスポンスメッセージはセキュリティコンテキスト情報を含み、前記セキュリティコンテキスト情報は前記ＵＥの前記ＲＲＣ接続のためのセキュリティキーを含み、前記セキュリティコンテキスト情報は、セキュリティキーを導出するのに利用されるセキュリティ関連パラメータを前記ｅＮＢに提供する装置。
15. ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ユーザ装置（ＵＥ）の装置であって、
    ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続中断手順を実行するよう前記ＵＥを設定する手段であって、
    前記ＲＲＣ接続中断手順は、
    進化型ノードＢ（ｅＮＢ）から受信したシグナリングから、前記ＵＥのＲＲＣ接続を中断するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを復号化する手段を含み、前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージは、前記ＵＥに前記ＲＲＣ接続を中断し、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）セキュリティコンテキストを格納するよう通知するための１つ以上のインジケータを含み、前記ＲＲＣ接続の中断中、１つ以上の中断されたＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）が確立されて非アクティブなままである、設定する手段と、
    前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを受信したことに応答して、メモリに前記ＡＳコンテキストを少なくとも格納する手段と、
    前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを受信したことに応答して、前記ＲＲＣ接続のＤＲＢを中断する手段と、
    前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを受信したことに応答して、ＲＲＣアイドルモードに入る手段と、
    を有し、
    前記ＵＥコンテキスト中断レスポンスメッセージはセキュリティコンテキスト情報を含み、前記セキュリティコンテキスト情報は前記ＵＥの前記ＲＲＣ接続のためのセキュリティキーを含み、前記セキュリティコンテキスト情報は、セキュリティキーを導出するのに利用されるセキュリティ関連パラメータを前記ｅＮＢに提供する装置。
16. 前記１つ以上のインジケータは、前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージの原因を示す、請求項１５記載の装置。
17. ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ユーザ装置（ＵＥ）と、
    ＩｏＴ処理のために構成される進化型ノードＢ（ｅＮＢ）と、
    を有するシステムであって、
    前記ｅＮＢは前記ＵＥのＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続中断手順を開始し、
    前記ＲＲＣ接続中断手順は、
    Ｓ１インタフェースを介しＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）への送信のため、前記ＵＥのＲＲＣ接続の中断を示し、前記ＵＥのコンテキストを中断するためのＵＥコンテキスト中断リクエストメッセージを符号化し、
    前記Ｓ１インタフェースを介し前記ＭＭＥから受信したシグナリングから、前記ＵＥコンテキスト中断リクエストメッセージをアクノリッジするＵＥコンテキスト中断レスポンスメッセージを復号化し、
    前記ＵＥコンテキスト中断レスポンスメッセージを受信したことに応答して、前記ＵＥへの送信のため、前記ＵＥのＲＲＣ接続を中断するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを符号化することを含み、
    前記ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージは、前記ＵＥに前記ＲＲＣ接続を中断し、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）コンテキストを格納するよう通知するための１つ以上のインジケータを含み、前記ＲＲＣ接続の中断中、１つ以上の中断されたＤＲＢ（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ）が確立されて非アクティブなままであり、前記ＵＥコンテキスト中断レスポンスメッセージはセキュリティコンテキスト情報を含み、前記セキュリティコンテキスト情報は前記ＵＥの前記ＲＲＣ接続のためのセキュリティキーを含み、前記セキュリティコンテキスト情報は、セキュリティキーを導出するのに利用されるセキュリティ関連パラメータを前記ｅＮＢに提供するシステム。

Images