(57)【要約】  基地局がコアネットワークノード（例えば、モビリティ管理エンティティ）から、基地局のセル内に位置する通信デバイスに関連する再開識別子を受信するシステムが開示される。基地局は、受信した再開識別子に基づいて、通信装置により中断された通信接続（例えば、無線リソース制御接続）の再開に使用される、通信装置に関連するユーザ装置（ＵＥ）コンテキストを検索する。【選択図】図１
2019512971.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワークのための基地局であって、前記基地局は、
前記基地局により運用される前記通信ネットワークのセル内の通信デバイスに関連する再開識別子をコアネットワークノードから受信するように構成されるトランシーバと、
前記受信された再開識別子に基づいて、前記基地局において、前記通信デバイスによる以前に中断された通信接続の再開に使用される、前記通信デバイスのためのユーザ装置（ＵＥ：user equipment）コンテキストを検索するように構成されるコントローラと、を備える基地局。
【請求項２】
前記トランシーバは、ローカルメモリ又は他の基地局からの前記ＵＥコンテキストを検索するように構成される、請求項１に記載の基地局。
【請求項３】
前記トランシーバは、前記ＵＥコンテキストを識別する情報（例えば、Resume ID）を含む少なくとも１つのシグナリングメッセージ（例えば、‘Retrieve UE Context Request’）を送信することにより、他の基地局からの前記ＵＥコンテキストを検索するように構成される、請求項２に記載の基地局。
【請求項４】
通信ネットワークのためのコアネットワーク装置であって、前記コアネットワーク装置は、
通信デバイスのための、以前に確立された通信接続に関連するユーザ装置（ＵＥ：user equipment）コンテキストを識別するように構成される再開識別子を取得するように構成されるコントローラと、
前記取得された再開識別子を基地局に送信するように構成されるトランシーバと、を備えるコアネットワーク装置。
【請求項５】
前記コントローラは、前記通信デバイス（例えば、前記通信デバイスにより送信されたtracking area update（ＴＡＵ）メッセージから）又は（例えば、前記再開識別子を検索するための適切なＳ１−ＡＰ手順を用いて）他の基地局からの前記再開識別子を取得するように構成される、請求項４に記載のコアネットワーク装置。
【請求項６】
前記コントローラは、（例えば、前記通信ネットワークの基地局間で）前記通信デバイスがネットワーク接続を変更したことを判定するように構成され、前記トランシーバは、前記通信デバイスがネットワーク接続を変更したことが判定された場合、前記取得された再開識別子を送信するように構成される、請求項４又は５に記載のコアネットワーク装置。
【請求項７】
通信ネットワークのための通信デバイスであって、前記通信デバイスは、
前記通信デバイスによる以前に中断された通信接続の再開に使用するために、前記通信デバイスのための再開識別子と共に、前記通信デバイスの現在位置を識別する情報をコアネットワーク装置に送信するように構成されるトランシーバを備える通信デバイス。
【請求項８】
前記トランシーバは、前記コアネットワーク装置に向けて送信されたtracking area update（ＴＡＵ）メッセージ内で、前記通信デバイスの現在位置を識別する前記情報を送信するように構成される、請求項７に記載の通信デバイス。
【請求項９】
モビリティ管理エンティティ（ＭＭＥ：mobility management entity）を含む、請求項４〜６のいずれか１項に記載のコアネットワーク装置。
【請求項１０】
前記通信デバイスは、３ＧＰＰ規格にかかるユーザ装置、ＩｏＴ（internet of things）デバイス、ＭＴＣ（machine-type communications）デバイス、Ｍ２Ｍ（machine-to-machine）通信デバイス、及び携帯電話のうちの少なくとも１つを含む、請求項７又は８に記載の通信デバイス。
【請求項１１】
請求項１〜３のいずれか１項に記載の基地局と、請求項４〜６及び９のいずれか１項に記載のコアネットワーク装置と、請求項７、８及び１０のいずれか１項に記載の通信デバイスと、を備えるシステム。
【請求項１２】
通信ネットワークの基地局により実行される方法であって、前記方法は、
前記基地局により運用される前記通信ネットワークのセル内の通信デバイスに関連する再開識別子をコアネットワーク装置から受信することと、
前記受信された再開識別子に基づいて、前記基地局において、前記通信デバイスによる以前に中断された通信接続の再開に使用するために、前記通信デバイスのためのユーザ装置（ＵＥ：user equipment）コンテキストを検索することと、を含む方法。
【請求項１３】
通信ネットワークのコアネットワーク装置により実行される方法であって、前記方法は、
通信デバイスのための、以前に確立された通信接続に関連するユーザ装置（ＵＥ：user equipment）コンテキストを識別するように構成される再開識別子を取得することと、
前記取得された再開識別子を基地局に送信することと、を含む方法。
【請求項１４】
通信デバイスにより実行される方法であって、前記方法は、
前記通信デバイスによる以前に中断された通信接続の再開に使用するために、前記通信デバイスのための再開識別子と共に、前記通信デバイスの現在位置を識別する情報をコアネットワーク装置に送信することと、を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムに関する。本発明は、第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）標準又はその等価物又はその派生に従って動作する無線通信システム及びその装置に特に関連するが、排他的ではない。本発明は、‘インターネットオブシングス（Internet of Things）’デバイス、及び／又は類似する（狭帯域）通信装置によるデータ送信に排他的ではないが特に関連する。
【背景技術】
【０００２】
３ＧＰＰ規格の最新の開発は、エボルブドパケットコア（ＥＰＣ：Evolved Packet Core）ネットワーク及びエボルブドＵＭＴＳ地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Evolved UMTS Terrestrial Radio Access Network）のロングタームエボリューション（ＬＴＥ：the Long Term Evolution）と呼ばれている。３ＧＰＰ規格の下では、ノードＢ（又はＬＴＥにおけるｅＮＢ）は、通信デバイスがコアネットワークに接続し、他の通信デバイス又は遠隔サーバとの通信を介する基地局である。簡略化のために、本出願は、このようないずれかの基地局を参照して基地局という用語を使用する。
【０００３】
通信デバイスは、例えば、携帯電話、スマートフォン、ユーザ装置、パーソナルデジタルアシスタント、ラップトップ／タブレットコンピュータ、ウェブブラウザブックリーダ、及び／又は同様のもの等のモバイル通信デバイスであってもよい。このようなモバイルデバイス（又は一般的に静止しているデバイス）は、典型的に、ユーザにより操作される。しかし、３ＧＰＰ規格は、いわゆる‘インターネットオブシングス’（ＩｏＴ）デバイス（例えば、狭帯域ＩｏＴにおいては（ＮＢ−ＩｏＴ）デバイス）をネットワークに接続させることを可能とする。ＩｏＴデバイスは、例えば、様々な測定装置、遠隔測定装置、監視システム、追跡装置、車両安全システム、車両維持システムにおける道路センサ、デジタルビルボード、ポイントオブセール（ＰＯＳ）端末、遠隔制御システム等の自動化装置を含む。いくつかのＩｏＴデバイスは、非静止装置（例えば、車両）に埋め込まれるか、又は監視される／追跡される動物又は人に取り付けられるが、ＩｏＴデバイスは、例えば、自動販売機、路側センサ、ＰＯＳ端末等の（一般的に）静止装置の一部として実装することが出来る。ＩｏＴデバイスは、時々、マシンタイプ通信（ＭＴＣ：Machine-Type Communication）通信デバイス、又はマシンツーマシン（Ｍ２Ｍ：Machine-to-Machine）通信デバイスとして呼ばれることがあることは理解されよう。しかしながら、ＩｏＴデバイスは、厳密な狭帯域要件、及び／又は、（例えば、バッテリを数年間交換しなくてもよい等の）省エネルギーニーズのために、ＭＴＣデバイスの特別なサブセットを形成する。
【０００４】
効果的には、インターネットオブシングスは、適切な電子機器、ソフトウェア、センサ、ネットワーク接続、及び／又は同様のものを備えたデバイス（又は”物”）のネットワークであり、これらのデバイスに互いに及び他の通信装置との間でデータを収集し、交換することを可能にする。簡略化のために、本出願は、説明中のＩｏＴデバイスを参照するが、説明された技術は、通信が人の入力により制御されるか、又はメモリに格納されたソフトウェア命令により制御されるかに関わらず、データを送受信するために通信ネットワークと接続することができる、（モバイル又は一般的に静止する）任意の通信デバイスに実装することができることは理解される。
【０００５】
ＩｏＴデバイスは、遠隔‘マシン’（例えば、サーバ）又はユーザからのデータを送受信するためにネットワークと接続する。ＩｏＴデバイスは、携帯電話又は類似するユーザ装置に最適化された通信プロトコル及び規格を使用する。しかし、ＩｏＴデバイスは、いったん配置されると、典型的に人の監督又は対話を必要とせずに動作し、内部メモリに格納されたソフトウェア命令に従う。また、ＩｏＴデバイスは長期間にわたって静止状態、及び／又は非アクティブ状態を維持する可能性がある。ＩｏＴデバイスをサポートするための特定のネットワーク要件は、3GPPテクニカルレポート（ＴＲ：technical report）23.720 V1.2.0で扱われており、その内容は参照により本明細書に取り込まれる。ＩｏＴデバイス（及び他のＭＴＣデバイス全般）に関連するさらなるネットワーク要件は、3GPP TS 22.368標準V13.1.0に開示されている。（ほとんどのＩｏＴデバイスは、移動、及び／又は移動頻度は低いが）シャドーイング、フェージング、及び／又は他の無線障害により、ＩｏＴデバイスは、それらのセル／ｅＮＢ接続ポイントを１つのセル／基地局から他のセル／基地局に切り替え得る。
【０００６】
ＩｏＴデバイスは、一般的に人の監督無しで出来るだけ長く動作するように設計されている。例えば、ＩｏＴデバイスは、イベントを報告するために、自律的に接続を設定し、その後、例えば、スリープモード、スタンバイモード等の低電力モードに戻るようにプログラムすることが出来る。
【０００７】
デバイスのバッテリ寿命を保証することは、ＮＢ−ＩｏＴワークの最大の考慮事項の１つである。ＩｏＴデバイスをよりシンプルにする一方で、データ記憶及び検索等の特定のタスクを最小限に抑えることにより、バッテリ寿命を延ばすことが可能となる。結果として、迅速なデータ送信及び関連するパワーセービングを達成することが出来る。
【０００８】
３ＧＰＰは、ＮＢ−ＩｏＴデバイスのための軽量なデータ送信を可能にするための多くの解決策を検討した。３ＧＰＰのショートリストの解決策の１つ（‘解決策１８（Solution 18）’と呼ばれる）は、必要なメッセージサイクル数を削減することによりユーザプレーンにおいて軽量データ送信を促進する。解決策１８のさらなる詳細は、3GPP R3-152686（“User plane based solution with AS information stored in RAN”と題されている）及びTR 23.720 (“Architecture enhancements for Cellular Internet of Things”)において見つけることができ、この文献の全内容は、参照により本明細書に組み込まれる。
【０００９】
解決策１８の１つの目標は、ＩｏＴ送信に関連するシグナリングオーバヘッドを低減し、ネットワークにおいて関連する処理負荷を低減することである。この目標を達成するために、関与するネットワークノード（例えば、ＵＥ／ＩｏＴデバイス、基地局（ｅＮＢ）、モビリティ管理エンティティ（ＭＭＥ）、及びサービングゲートウェイ等）のいくつかから新しい動作が期待される。具体的には、解決策１８は、以下を要求する：
−（特定のＩｏＴデバイスのために）無線リソース制御（ＲＲＣ：radio resource control）接続を動作させるために必要なアクセス層（ＡＳ：access stratum）レベルの情報をキャッシングし、ＩｏＴデバイス（ＵＥ）がRRC_IDLEモードにある間、Ｅ−ＵＴＲＡＮ及びＩｏＴデバイス（ＵＥ）の両方に、この情報を保持する；
−基地局（ｅＮＢ）単位で機能をサポートする；
−（特定のＩｏＴデバイスのための）Ｓ１  ＭＭＥ  ＵＥ関連シグナリング接続が、そのＩｏＴデバイス（ＵＥ）がRRC_IDLEモードである間、基地局（ｅＮＢ）とＭＭＥとの間で維持される；
−中断及び再開という２つの新しい手順が、ＲＲＣ及びＳ１ＡＰ上の大きな影響で導入される；
−（特定のＩｏＴデバイスのための）ベアラコンテキストデータが、そのＩｏＴデバイスに関連する基地局（ｅＮＢ）及びＭＭＥに維持される；及び
−中断及び再開手順はまた、ＭＭＥと、関連するＩｏＴデバイスに関連するサービングゲートウェイ（Ｓ−ＧＷ）との間の対話を必要とする。
【００１０】
さらに、接続が中断された基地局と異なる基地局（ｅＮＢ）を介した接続を再開する機能が提供されることも予想される。モバイル発信（ＭＯ：mobile originated）呼の場合、異なる基地局を介した接続を再開することは、3GPP R3-160462に開示されているＸ２ベースのコンテキストフェッチ手順を用いて実現され得る。図８（出典：3GPP R3-160462）に示されているように、Ｘ２ベースのコンテキストフェッチ手順は、ＩｏＴデバイス（ＵＥ）の新旧サービング基地局の間で実行され、本手順は、ＩｏＴデバイス（ＵＥ）が新しい基地局（ｅＮＢ）を介したＲＲＣ接続を再開するためにその基地局に要求を送信する場合、ＩｏＴデバイス（ＵＥ）によりトリガされる。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかし、（例えば、ＩｏＴデバイスは、新しい基地局を介した接続を再開しない場合等）このケースでは、ＩｏＴデバイス（ＵＥ）は、コンテキストフェッチを実行するために、いずれのトリガも提供しないので、このようなＸ２ベースのコンテキストフェッチは、モバイル着信（ＭＴ：mobile terminated）呼については不可能である。
【００１２】
（特定のＩｏＴデバイスのための）ページングメッセージは、（そのＩｏＴデバイスに対して）既に確立されたＵＥ関連シグナリング接続内で送信されることが可能であると予想される。（ページングされているＩｏＴデバイスのための）中断されたＵＥコンテキストを保持する基地局のセル内でページングが成功する場合、再開手順はトリガされる。しかし、（ＩｏＴデバイスが新しいセルに移動後に、ＩｏＴデバイスに到達することができなくなる可能性がある場合、）ＩｏＴデバイス（ＵＥ）が旧基地局を介してページングすることができず、ＩｏＴデバイス（ＵＥ）が新基地局を介してページングされない場合（関連するＵＥコンテキストが利用出来ない場合）、場合によりＩｏＴデバイスのための接続を再開することが出来ない可能性がある。
【００１３】
（例えば、ＩｏＴデバイスにより実行されるトラッキングエリアアップデート（ＴＡＵ：tracking area update）に基づく等）ＩｏＴデバイスが基地局を変更したことをＭＭＥが認識したとしても、サービングゲートウェイ及びＭＭＥは、（ＩｏＴデバイスをページングするために）新基地局が、旧基地局からＵＥコンテキストをフェッチし、そのＵＥコンテキストに対応するパスを旧基地局から新基地局に切り替えるまでの間、旧サービング基地局に向かう旧パスを使用するように構成され続ける。
【００１４】
新しいセルに移動し、それによりページングメッセージ／ＭＴ呼をＩｏＴデバイスに確実に送ることができるときはいつでも、（例えば、簡単に）接続を再開するようにＩｏＴデバイスを構成することが可能であり得るが、これは追加のシグナリングを必要とし、したがって、解決策１８の省電力効果を低減してしまう。さらに、ＩｏＴデバイスが送信するデータを有していなくても、接続を再開することは、３ＧＰＰにより設定された目標、つまり、ＩｏＴデバイスのための軽量データ送信ソリューションに反する。
【００１５】
さらに、いくつかのＵＥ及びＩｏＴデバイス（例えば、カテゴリ−Ｍ（category-M）  ＵＥ）は、複数のデータ無線ベアラ（ＤＲＢ：data radio bearers）（最大８ＤＲＢ）を有することを可能にするので、全てのＤＲＢが、新しい基地局により再開される（ただし、新しい基地局が十分なリソースを有していることを条件とする）。そうでなく、新しい基地局が十分なリソースを有していない場合、ＩｏＴデバイスが（例えば、ＭＴ呼に対して）全てのＤＲＢを再開することを要求しないとしても、その基地局を介してＩｏＴデバイスにサービスを提供することは出来ない。
【００１６】
本発明は、電力を節約する必要性を有し、狭い帯域スペクトルにわたって動作するように設計される（及び、実際の展開では数百万のオーダーの多数のデバイスである）ＩｏＴデバイスのための軽量なソリューション（lightweight solution）を提供するための要件を大幅に損なうことなく解決策１８に関するいくつかの問題（を少なくとも部分的）に対処することを目的とする。
【００１７】
したがって、本発明の好ましい例示的な実施形態は、上記ニーズに対処するか、又は少なくとも部分的に対処する方法及び装置を提供することを目的とする。
【００１８】
当業者の理解を容易にするために、本発明は３ＧＰＰシステム（ＵＭＴＳ、ＬＴＥ）の文脈で詳細に説明されるが、本発明の原理は、通信装置又はユーザ装置（ＵＥ）が無線アクセス技術を用いてコアネットワークに接続する他のシステムに適用することが出来る。
【課題を解決するための手段】
【００１９】
第１の態様では、本発明は、通信ネットワークのための基地局を提供し、前記基地局は、前記基地局により運用される前記通信ネットワークのセル内の通信デバイスに関連する再開識別子（resume identifier）をコアネットワークノードから受信するように構成されるトランシーバと、前記受信された再開識別子に基づいて、前記基地局において、前記通信デバイスによる以前に中断された通信接続の再開に使用される、前記通信デバイスのためのユーザ装置（ＵＥ：user equipment）コンテキストを検索するように構成されるコントローラと、を備える。
【００２０】
他の態様では、本発明は、通信ネットワークのためのコアネットワーク装置を提供し、前記コアネットワーク装置は、通信デバイスのための、以前に確立された通信接続に関連するユーザ装置（ＵＥ：user equipment）コンテキストを識別するように構成される再開識別子を取得するように構成されるコントローラと、前記取得された再開識別子を基地局に送信するように構成されるトランシーバと、を備える。
【００２１】
さらに別の態様では、本発明は、通信ネットワークのための通信デバイスを提供し、前記通信デバイスは、前記通信デバイスによる以前に中断された通信接続の再開に使用するために、前記通信デバイスのための再開識別子と共に、前記通信デバイスの現在位置を識別する情報をコアネットワーク装置に送信するように構成されるトランシーバを備える。
【００２２】
一態様では、本発明は、通信ネットワークのための基地局を提供し、前記基地局は、通信デバイスから、前記通信デバイスのための通信接続を再開する要求であって、前記再開される無線ベアラ数を識別する情報を含む前記通信接続を再開する要求を受信するように構成されるトランシーバと、前記通信デバイスのためのユーザ装置（ＵＥ）コンテキストを取得するように構成され、前記再開される前記無線ベアラの少なくとも１つを設定するように構成されるコントローラと、備える。
【００２３】
他の態様では、本発明は、通信ネットワークのためのコアネットワーク装置を提供し、前記コアネットワーク装置は、再開する無線ベアラ数を識別する情報を含むユーザ装置（ＵＥ）コンテキストを再開する要求を基地局から受信し、設定される少なくとも１つの無線ベアラ（例えば、少なくとも１つのＥ−ＲＡＢ）を識別する情報を含む前記要求に対する応答を前記基地局に送信するように構成されるトランシーバを備える。
【００２４】
さらに別の態様では、本発明は、通信ネットワークのための通信デバイスを提供し、前記通信デバイスは、前記通信ネットワークの基地局に、前記通信デバイスのための通信接続を再開する要求であって、再開される無線ベアラ数を識別する情報を含む前記通信接続を再開する前記要求を送信するように構成されるトランシーバを備える。
【００２５】
本発明の態様は、対応するシステム、方法、及び、上に記載された態様及び可能性、又は請求項に記載された方法を実行するようにプログラム可能なプロセッサをプログラムするように、及び／又は、請求項のいずれかに記載の装置を提供するように適切に適合されたコンピュータをプログラムすることが動作可能な命令が格納された、例えば、コンピュータ可読記憶媒体等のコンピュータプログラム製品に拡張される。
【００２６】
（特許請求項を含む用語である）本明細書に開示された、及び／又は図面に示された各特徴は、他の開示された、及び／又は図示された特徴のいずれかとは独立して（又は組み合わせて）本発明に組み込まれてもよい。特に限定されないが、特定の独立請求項に従属する請求項のいずれかの特徴は、その独立請求項と任意の組み合わせで、又は独立して導入されてもよい。
【００２７】
本発明の例示的な実施形態を、添付の図面を参照して例として以下に説明する。
【図面の簡単な説明】
【００２８】
【図１】図１は、本発明の例示的な実施形態に適用可能なセルラ電気通信システムを概略的に示す。
【図２】図２は、図１に示すシステムの一部を形成するＩｏＴデバイスのブロック図である。
【図３】図３は、図１に示すシステムの一部を形成する基地局のブロック図である。
【図４】図４は、図１に示すシステムの一部を形成するモバイル管理エンティティのブロック図である。
【図５】図５は、本発明の例示的な実施形態が図１のシステムにおいて実装することが可能な例示的な方法を示すタイミング図である。
【図６】図６は、本発明の例示的な実施形態が図１のシステムに実装することが可能な例示的な方法を示すタイミング図である。
【図７】図７は、本発明の例示的な実施形態が図１のシステムに実装することが出来る例示的な方法を示すタイミング図である。
【図８】図８は、Ｘ２ベースのコンテキストフェッチ手順を示すタイミング図である。
【発明を実施するための形態】
【００２９】
＜概要＞
図１は、ＩｏＴデバイス３、（‘ＵＥ’として示す）携帯電話、及び他の通信デバイス（不図示）が、Ｅ−ＵＴＲＡ無線アクセステクノロジ（ＲＡＴ：radio access technology）を用いて、Ｅ−ＵＴＲＡＮ基地局５及びコアネットワーク７を介して互いに通信することができる、電気通信ネットワーク１を概略的に示す。当業者には理解されるように、説明を目的として、図１には、１つのＩｏＴデバイス３、２つの携帯電話ＵＥ及び２つの基地局５−１、５−２が示されているが、実装する場合、システムは、典型的に、他の基地局及び通信デバイスを含む。
【００３０】
各基地局５は、１又は複数の関連するセルを運用する。この例では、第１の基地局５−１は、‘セル１’を運用し、第２の基地局５−２は、‘セル２’を運用する。通信デバイスは、（それらの位置、及び、例えば、信号状態、加入者データ、ケーパビリティ、及び／又は同様のもの等、可能性のある他の要因に応じて）セルを運用する適切な基地局５との無線リソース制御（ＲＲＣ：radio resource control）接続を確立することにより、いずれかのセルと接続し得る。図から分かるように、ＩｏＴデバイス３は、基地局５−１及び５−２によって運用されるセルが部分的に重なるエリアに位置する。したがって、（データの送受信しない）ＲＲＣアイドルモード（RRC idle mode）で動作する場合、ＩｏＴデバイス３は、最も良い信号品質を有するセルに遷移し（キャンプオンし（camp on））、ＲＲＣアクティブモード（RRC active mode）で動作する場合、ＩｏＴデバイス３は、そのセルを介してデータを通信する。
【００３１】
基地局５は、Ｓ１インタフェースを介してコアネットワーク７に接続し、（図示しないが）Ｘ２インタフェースを介して互いに接続する。コアネットワーク７は、モビリティ管理エンティティ（ＭＭＥ：mobility management entity）９、及び、基地局５と、（インターネット等の）他のネットワークとの間の接続、及び／又は基地局５とコアネットワーク７の外部でホストとなるサーバとの間の接続を提供するためのサービングゲートウェイ（Ｓ−ＧＷ：serving gateway）１０及びパケットデータネットワークゲートウェイ（Ｐ−ＧＷ：packet data network gateway）１１を含む。
【００３２】
ＭＭＥ９は、通信ネットワーク１内のモバイル通信デバイス（携帯電話及びＩｏＴデバイス３）の位置を追跡する（track）役割を果たすネットワークノードである。具体的には、ＭＭＥ９は、モバイル通信デバイスに着信（音声又はデータ）呼があるときに通知し、特定のモバイル通信デバイスに現在サービスを提供している基地局５を介して通信パスが設定されるように、モバイル通信デバイスの最後の既知セル（又はトラッキングエリア）の識別子を記憶する。
【００３３】
以下の例では、ＩｏＴデバイス３は、データを遠隔サーバ（又は他の通信デバイス）に送信するために、特定の間隔で（及び／又はアプリケーションの１つがネットワークと通信する必要があるときはいつでも）ネットワークに接続する。本例示的な実施形態のＩｏＴデバイス３の動作は自動化され、本質的に自律的に動作することが可能である。しかし、ＩｏＴデバイス３は、（例えば、測定基準（メジャメントクライテリア：measurement criteria）のリモート（再）設定、又は予定外の測定性能（メジャメント性能）及び報告（レポート）等の）ローカル又はリモートユーザから受信される入力に基づいて、特定のアクティビティを実行してもよいことは理解されるであろう。さらに、ＩｏＴデバイス３は、携帯電話と同様にユーザにより操作されてもよい。
【００３４】
破線の矢印で示す様に、ＩｏＴデバイス３は、（セル１を介して）第１の基地局５−１に以前接続したので、第１の基地局５−１は、関連するＵＥコンテキストを維持する。しかし、実線の矢印で示す様に、ＩｏＴデバイス３は、例えば、セル１の信号状態の変化、及び／又はＩｏＴデバイス３の移動により、（セル２を介して）第２の基地局５−２を介して現在到達可能である。
【００３５】
しかし、旧基地局５−１を介して、ＩｏＴデバイス３にもはや到達できなくなった後であっても、（例えば、ＩｏＴデバイス３はRRC_IDLEモードで動作している等）ＩｏＴデバイス３は、現在、ネットワークとのアクティブな接続を有していないので、新基地局５−２を介して、そのＲＲＣ接続を再開するように構成されていない。
【００３６】
その代わり、ＩｏＴデバイス３は、適切にフォーマットされたtracking area update（ＴＡＵ） request（及び／又は同様の適切なシグナリングメッセージ）を（新サービング基地局５−２を介して）ＭＭＥ９に送信することにより、ＭＭＥ９に自身を登録しようとする。
【００３７】
効果的に、ＩｏＴデバイス３からのTAU request（及び／又は同様のもの）は、ＩｏＴデバイス３が（この例ではセル１からセル２に）セルを変更したことをＭＭＥ９に示し、有益に、ＭＭＥ９が新サービング基地局５−２に、基地局５−２が旧サービング基地局５−１からＩｏＴデバイス３に関連するＵＥコンテキストをフェッチする必要があること（及びＳ−ＧＷ１０でパスを切り替える適切なパススイッチ手順を実行することが必要であること）を通知することが可能である。そのため、この例では、（例えば、ＩｏＴデバイス３がRRC_IDLEモードで動作することを継続する場合、）ＩｏＴデバイス３は、新サービング基地局５−２を介して接続を再開する要求を送信しなくても、新サービング基地局５−２を介してそのコンテキストを維持することができる。したがって、ＩｏＴデバイス３と、そのサービング基地局５との間の不必要なシグナリングを回避することができ、（例えばＭＴの場合）ＲＲＣアイドルモードの間に旧基地局５−１から新基地局５−２にセルを移動／変更した場合にＩｏＴデバイス３に到達できないリスクを低減する。
【００３８】
このように、例えば、モバイル着信呼の場合、ＩｏＴデバイス３が（基地局５−１又は５−２を介して）アクティブなＲＲＣ接続を有しているか否かにかかわらず、ＭＭＥは、ＩｏＴデバイス３をページングするために既に確立されたＵＥコンテキストを有益に使用することができる。
【００３９】
他の例では、ＩｏＴデバイス３がサービング基地局５を介して、その接続を再開する場合、例えば、ＭＴ呼に関連してＭＭＥ９からのページングメッセージに応答する場合、さらなるシグナリング及び／又はリソース最適化（及び、ＩｏＴデバイス３における関連するパワーセービング）が達成され得る。具体的には、ＩｏＴデバイス３が（RRC Connection Resume Request、及び／又は同様のもの等の）再開要求をサービング基地局５に送信する場合、この要求には、再開されるべき接続を識別する情報、及び、どれくらいの、及び／又はどのデータ無線ベアラ（ＤＲＢ）が、再開が必要であるかを識別する情報が含まれる。有益には、再開された接続のために、どれくらいの、及び／又はどのＤＲＢが再開する必要があるのかをネットワークに示すことにより、ＩｏＴデバイス３が再開された接続のために必要としないＤＲＢを再開することを回避し、（これによりＩｏＴデバイス及びサービング基地局５における通信リソースを解放し、）及び／又は、（例えば、基地局５が、ＩｏＴデバイス３に関連する全てのＤＲＢのいくつかを再開するための十分リソースを有するにもかかわらず、これら全てのＤＲＢを再開するための十分なリソースを有していない場合に、）基地局５において接続を再開することが失敗することを回避することができる。
【００４０】
ＩｏＴデバイス３が再開することを望むＤＲＢを識別する情報に基づいて、サービング基地局５は、適切なアドミッションコントロール、及び識別されたＤＲＢに関するＲＲＣ再設定（RRC re-configuration）を実行すること（及び、それに応じてＭＭＥに通知すること）ができる。しかし、この例では、サービング基地局５は、ＩｏＴデバイス３が再開することを明示的に示していない、（基地局５に保持されている関連するＵＥコンテキスト毎に）ＩｏＴデバイス３に関連する任意のＤＲＢを再開しないように構成される。
【００４１】
有益には、ＩｏＴデバイスが新サービング基地局に移動し、及び／又は新サービング基地局を介してその接続を再開する場合、ＩｏＴデバイス（ＵＥ）及びサービング基地局において、より良好なサービス継続性及びより効率的なリソース使用を提供することが可能である。
【００４２】
＜ＩｏＴデバイス＞
図２は、図１に示すＩｏＴデバイス３（又はＩｏＴデバイス３として動作するように構成される携帯電話）の主要なコンポーネントを示すブロック図である。図示するように、ＩｏＴデバイス３は、1又は複数のアンテナ３３を介して基地局５に信号を送信し、基地局５から信号を受信するように動作可能なトランシーバ回路３１を有する。ＩｏＴデバイス３は、ＩｏＴデバイス３の動作を制御するコントローラ３７を有する。コントローラ３７は、メモリ３９に関連し、トランシーバ回路３１に接続される。ＩｏＴデバイス３の動作には必ずしも必要ではないが、ＩｏＴデバイス３は、もちろん（ユーザインタフェース３５等の）従来の携帯電話３の全ての通常の機能を有してもよく、必要に応じて、ハードウェア、ソフトウェア及びファームウェアのいずれか１つ又は任意の組み合わせにより提供されてもよい。ソフトウェアは、メモリ３９に予めインストールされていてもよく、及び／又は、電気通信ネットワークを介して、又は、例えば、取り外し可能なデータストレージデバイス（ＲＭＤ：removable data storage device）からダウンロードされてもよい。
【００４３】
コントローラ３７は、この例では、メモリ３９内に格納されたプログラム命令又はソフトウェア命令によりＩｏＴデバイス３の全体的な動作を制御するように構成される。図示するように、これらのソフトウェア命令は、とりわけ、オペレーティングシステム４１、通信制御モジュール４３、ＵＥコンテキストモジュール４５、ＲＲＣモジュール４６及びＮＡＳモジュール４９を含む。
【００４４】
通信制御モジュール４３は、ＩｏＴデバイス３と、サービング基地局５（及び、さらなるＩｏＴデバイス、携帯電話、コアネットワークノード等のサービング基地局５に接続される他の通信デバイス）との間の通信を制御するように動作可能である。
【００４５】
ＵＥコンテキストモジュール４５は、サービング基地局５を介して通信する際に使用されるＩｏＴデバイス３に関連するＵＥコンテキストを処理する（取得、生成、修正、記憶（格納）及び／又は転送する）ことの役割を担う。
【００４６】
ＲＲＣモジュール４６は、ＲＲＣ規格に従ってフォーマットされたシグナリングメッセージを生成し、送信し、受信するように動作可能である。例えば、このようなメッセージは、ＩｏＴデバイス３と、サービング基地局５との間で交換される。ＲＲＣメッセージは、例えば、新サービング基地局５を介して以前のＲＲＣ接続（RRC connection）を再開することに関するメッセージを含んでもよい。
【００４７】
ＮＡＳモジュール４９は、ＮＡＳ規格に従ってフォーマットされたシグナリングメッセージを生成し、送信し、受信するように動作可能である。例えば、このようなメッセージは、ＩｏＴデバイス３と、（ＲＲＣモジュール４６を用いて、サービング基地局５を介して）ＭＭＥ９との間で交換される。ＮＡＳメッセージは、例えば、ＩｏＴデバイス３が現在位置するトラッキングエリア（又はセル）を登録、及び／又は更新することに関するメッセージを含んでもよい。
【００４８】
＜基地局＞
図３は、図１に示す基地局５の主要なコンポーネントを示すブロック図である。図示するように、基地局５は、１又は複数のアンテナ５３を介して（ＩｏＴデバイス３／携帯電話等の）通信デバイスに信号を送信し、通信デバイスから信号を受信するためのトランシーバ回路５１と、コアネットワーク７に信号を送信し、コアネットワーク７から信号を受信するためのコアネットワークインタフェース５５（例えば、Ｓ１インタフェース）と、及び隣接基地局に信号を送信し、隣接基地局から信号を受信するための基地局インタフェース５６（例えば、Ｘ２インタフェース）と、を有する。基地局５は、基地局５の動作を制御するコントローラ５７を有する。コントローラ５７は、メモリ５９に関連する。図３には必ずしも示されていないが、基地局５は、セルラ電話ネットワークの基地局の全ての通常の機能をもちろん有しており、必要に応じて、ハードウェア、ソフトウェア及びファームウェアのいずれか１つ又は任意の組み合わせにより提供されてもよい。ソフトウェアは、メモリ５９に予めインストールされてもよく、及び／又は通信ネットワーク１を介して、又は、例えば、取り外し可能なデータストレージデバイス（ＲＭＤ）からダウンロードされてもよい。コントローラ５７は、この例では、メモリ５９に格納されたプログラム命令又はソフトウェア命令により、基地局５の全体的な動作を制御するように構成される。図示するように、これらのソフトウェア命令は、とりわけ、オペレーティングシステム６１、通信制御モジュール６３、ＵＥコンテキストモジュール６５、ＲＲＣモジュール６６、Ｘ２モジュール６７及びＳ１ＡＰモジュール６８を含む。
【００４９】
通信制御モジュール６３は、基地局５と、ＩｏＴデバイス３、携帯電話及び基地局５に接続する他のネットワークエンティティとの間の通信を制御するように動作可能である。通信制御モジュール６３はまた、（関連するデータ無線ベアラを介して）ダウンリンクユーザトラフィック、及び、例えば、ＩｏＴデバイス３及び／又は携帯電話の動作を管理するための制御データを含む、基地局５に関連する通信デバイスに送信される制御データの別々のフローを制御する。
【００５０】
ＵＥコンテキストモジュール６５は、基地局５に接続するユーザ装置（例えば、ＩｏＴデバイス３）に関連するＵＥコンテキストを処理する（取得、生成、修正、格納（記憶）、及び／又は転送する）ことの役割を担う。
【００５１】
ＲＲＣモジュール６６は、ＲＲＣ規格に従ってフォーマットされたシグナリングメッセージを生成し、送信し、受信するように動作可能である。例えば、このようなメッセージは、基地局５と、ＩｏＴデバイス３（及び基地局５のセル内の他の通信デバイス）との間で交換される。ＲＲＣメッセージは、例えば、新サービング基地局として、基地局５を介してＩｏＴデバイス３のために、以前のＲＲＣ接続（例えば、データ無線ベアラのセット）を再開することに関連するメッセージを含んでもよい。
【００５２】
Ｘ２モジュール６７は、Ｘ２ＡＰ規格に従ってフォーマットされたシグナリングメッセージ（Ｘ２メッセージ）を生成し、送信し、受信するように動作可能である。Ｘ２メッセージは、例えば、隣接基地局間でＵＥコンテキストの転送／フェッチに関連するメッセージを含んでもよい。
【００５３】
Ｓ１ＡＰモジュール６８は、Ｓ１ＡＰ規格に従ってフォーマットされたシグナリングメッセージを生成し、送信し、受信するように動作可能である。例えば、このようなメッセージは、基地局５と、モビリティ管理エンティティ９との間で交換される。Ｓ１ＡＰメッセージは、例えば、基地局のセルにいるＩｏＴデバイス／ユーザ装置の位置を登録することに関連するメッセージ（例えば、ＩｏＴデバイス３からのＴＡＵメッセージ）、及び／又は関連する応答（response）を含んでもよい。
【００５４】
＜モビリティ管理エンティティ＞
図４は、図１に示したモバイル管理エンティティ９の主要なコンポーネントを示すブロック図である。図示するように、モビリティ管理エンティティ９は、基地局インタフェース７５（例えば、Ｓ１インタフェース）を介して、基地局５（及び／又は基地局５に接続された通信デバイス）に信号を送信し、基地局５（及び／又は基地局５に接続された通信デバイス）から信号を受信するためのトランシーバ回路７１を有する。モビリティ管理エンティティ９は、モビリティ管理エンティティ９の動作を制御するコントローラ７７を有する。コントローラ７７は、メモリ７９に関連する。図４に必ずしも図示していないが、モビリティ管理エンティティ９は、セルラ電話ネットワークのモビリティ管理エンティティの全ての通常の機能をもちろん有しており、必要に応じて、ハードウェア、ソフトウェア及びファームウェアのいずれか１つ又は任意の組み合わせにより提供されてもよい。ソフトウェアは、メモリ７９に予めインストールされてもよく、及び／又は通信ネットワーク１を介して、又は、例えば、取り外し可能なデータストレージデバイス（ＲＭＤ）からダウンロードされてもよい。コントローラ７７は、例えば、メモリ７９内に格納されたプログラム命令又はソフトウェア命令により、モビリティ管理エンティティ９の全体的な動作を制御するように構成される。図示するように、これらのソフトウェア命令は、とりわけ、オペレーティングシステム８１、通信制御モジュール８３、ＵＥ位置登録モジュール８５、Ｓ１ＡＰモジュール８８及びＮＡＳモジュール８９を含む。
【００５５】
通信制御モジュール８３は、モビリティ管理エンティティ９と、基地局５、ＩｏＴデバイス３、携帯電話及びモビリティ管理エンティティ９に接続される他のネットワークエンティティとの間の通信を制御するように動作可能である。
【００５６】
ＵＥ位置登録モジュール８５は、ＭＭＥ９に接続される（携帯電話、ＩｏＴデバイス、及び／又は同様のもの等の）ユーザ装置の現在の位置を追跡する役割を担う。
【００５７】
Ｓ１ＡＰモジュール８８は、Ｓ１ＡＰ規格に従ってフォーマットされたシグナリングメッセージを生成し、送信し、受信するように動作可能である。例えば、このようなメッセージは、モビリティ管理エンティティ９と、接続された基地局５と、の間で交換される。Ｓ１ＡＰメッセージは、例えば、ＵＥコンテキストをフェッチする（例えば、トリガする）こと、及び／又は基地局５を介してＩｏＴデバイス３のための１又は複数のデータ無線ベアラを再開することに関連するメッセージを含んでもよい。
【００５８】
ＮＡＳモジュール８９は、ＮＡＳ規格に従ってフォーマットされたシグナリングメッセージを生成し、送信し、受信するように動作可能である。例えば、このようなメッセージは、ＭＭＥ９と、（Ｓ１ＡＰモジュール８８を用いて、基地局５を介して）ＩｏＴデバイス３との間で交換される。ＮＡＳメッセージは、例えば、ＩｏＴデバイス３が現在位置するトラッキングエリア（又はセル）を登録、及び／又は更新することに関連するメッセージを含んでもよい。
【００５９】
上記の説明では、理解を容易にするために、ＩｏＴデバイス３、基地局５、及びモビリティ管理エンティティ９は、（通信制御モジュール及びＵＥコンテキストモジュール等の）多数のモジュールを有するとして説明した。例えば、当初から本発明の特徴を考慮して設計されたシステムで、他のアプリケーションにおいて、例えば、既存システムが本発明を実施するように修正された場合、これらのモジュールは、特定の用途に対して、このように提供され得るが、これらのモジュールは、全体的なオペレーティングシステム又はコードに組み込まれてもよく、したがって、これらのモジュールが別個のエンティティとして認識できない可能性がある。これらのモジュールはまた、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせで実装されてもよい。
【００６０】
ここで、ＩｏＴデバイスが新基地局に移動し、既存のＵＥコンテキストを用いてページングすることができ、ＩｏＴデバイスがネットワークとの接続を再開する（例えば、適切な数のデータ無線ベアラを再開する）ことができる、上述したシナリオのより詳細な説明を（図５〜７を参照して）行う。
【００６１】
＜動作−第１の例＞
図５は、ＩｏＴデバイス３（又はＵＥ）のためのコンテキストフェッチを実行する場合にシステム１のコンポーネントにより実行される例示的なプロセスを示すタイミング図（メッセージシーケンスチャート）である。
【００６２】
最初に、ＩｏＴデバイス３及び（図５において‘ｅＮＢ−１’として示す）旧基地局５−１は、ＵＥコンテキスト、及びＩｏＴデバイス３に関連する適切なResume ID（再開ＩＤ）を記憶する。このＵＥコンテキストは、（例えば、ＩｏＴデバイス３が基地局５−１のセル１を介して通信していた間に）ＩｏＴデバイス３及び旧基地局５−１との間の初期のＲＲＣ接続の間で生成されたことは理解されるであろう。ＩｏＴデバイス３は、現在、RRC_IDLEモードで動作する。
【００６３】
ＩｏＴデバイス３が、旧基地局５−１によりサービスされるエリア（セル１）を離れる（及び／又はセル１の信号状態が悪化する）場合、ＩｏＴデバイス３は、より良好な信号状態である新しいセルを選択し、遷移する。この例では、ＩｏＴデバイス３は、（図５の‘ｅＮＢ−２’で示す）第２の基地局により運用されるセル２を選択し、セル２に遷移する。
【００６４】
ステップＳ５０１において一般的に示すように、ＩｏＴデバイス３は、ＩｏＴデバイス３の新しい位置としてセル２を登録するために、適切にフォーマットされたシグナリングメッセージ（例えば、TAU request）を（ＮＡＳモジュール４９を用いて）生成し、ＭＭＥ９に送信する。ＩｏＴデバイス３は、ＩｏＴデバイス３に関連するResume IDを、このシグナリングメッセージに含める。
【００６５】
ステップＳ５０２において、受信された情報（例えば、Resume ID、新基地局５−２／セル２を識別する情報）に基づいて、ＭＭＥ９は、ＩｏＴデバイス３がネットワーク接続（network attachment）（例えば、セル／基地局）を変更したと判定し、それに応じて、ＵＥの位置登録モジュール８５に保持されているデータを更新する（例えば、ＭＭＥ９は、ＩｏＴデバイス３の現在位置とするセル１を削除し、ＩｏＴデバイス３の現在位置としてセル２を保存する）。
【００６６】
しかし、ステップＳ５０５において、ＭＭＥ９はまた、ＩｏＴデバイス３がネットワーク接続を変更したことを示し、旧基地局５−１からＩｏＴデバイス３のためのＵＥコンテキストをフェッチすることを新基地局５−２に要求する、適切にフォーマットされたシグナリングメッセージを（Ｓ１ＡＰモジュール８８を用いて）生成し、新基地局５−２に送信するように構成される。具体的には、この例では、ＭＭＥ９は、‘Context Fetch Trigger’Ｓ１ＡＰメッセージ（及び／又は同様のもの）を生成し、新基地局５−２に送信し、（オプション的に）（適切な‘eNB ID’により）旧基地局５−１を識別する情報、ＩｏＴデバイス３から受信されたResume ID、及びＭＭＥ９のためのＩｏＴデバイス３を識別する情報（例えば、新しい‘MME UE S1AP ID’）をこのメッセージに含める。
【００６７】
有益には、Resume IDを含む、ＭＭＥ９からのメッセージは、新基地局５−２が、ＩｏＴデバイス３に関連するＵＥコンテキストをフェッチするための適切な手順を開始するためのトリガとして働く。したがって、ステップＳ５０６及びＳ５０７において一般的に示す様に、新基地局５−２及び旧基地局５−１は、（例えば、3GPP R3-160550に示すような）適切なＸ２ベースのコンテキストフェッチ動作を行う。
【００６８】
より詳細には、基地局５−２は、ＩｏＴデバイス３／Resume IDに関連するＵＥコンテキストが、この基地局５−２で利用可能ではないと判定する場合、（ステップＳ５０５で送信されたとすると）Resume ID及び／又はeNB ID等の、ＭＭＥ９から受信された情報に基づいて、旧基地局５−１を識別しようと試みる。本プロセスの残りは、3GPP R3-160550に記載された手順に従う。
【００６９】
新基地局５−２が、ＭＭＥ９から受信した情報に基づいて、旧基地局５−１を識別することが出来る場合、ステップＳ５０６において、新基地局５−２は、ＩｏＴデバイス３に関連するＵＥコンテキストを取得するための、適切にフォーマットされたシグナリングメッセージを、（Ｘ２モジュール６７を用いて）生成し、旧基地局５−１に送信する。新基地局５−２は、ＩｏＴデバイス３に関連するResume ID（及び／又は他の適切な情報）をこのメッセージ（例えば、‘Retrieve UE Context Request’Ｘ２−ＡＰメッセージ）に含める。
【００７０】
旧基地局５−１がステップＳ５０６で受信したResume IDを（ＵＥコンテキストモジュール６５内の）ＵＥコンテキストと一致させることが出来る場合、旧基地局５−１は、ＵＥコンテキストモジュール６５から関連するＵＥコンテキストを検索し、ステップＳ５０７において、適切にフォーマットされたＸ２−ＡＰシグナリングメッセージ（例えば、‘Retrieve UE Context Response’メッセージ）に本ＵＥコンテキストを含めることにより、当該ＵＥコンテキストを新基地局５−２に送信する。
【００７１】
このフェッチ手順の最後に、新基地局５−２は、ＩｏＴデバイス３に関連するＵＥコンテキストを（ＵＥコンテキストモジュール６５に）保存する。
【００７２】
新基地局５−２はまた、フェッチされたＵＥコンテキストに関連するパスを（ＭＭＥ９及びＳ−ＧＷ１０において）旧基地局５−１から新基地局５−２に切り替えるようにＭＭＥ９に要求する。そのようにするために、ステップＳ５０８において、新基地局５−２は、適切なpath switch requestを（Ｓ１ＡＰモジュール６８を用いて）生成し、ＭＭＥ９に送信する。そして、ＭＭＥ９がパスを更新し（図５に不図示）、一旦パススイッチが完了すると、ＭＭＥ９は適切な肯定応答（acknowledgement）を生成し、新基地局５−２に送信する（ステップＳ５０９）。
【００７３】
効果的に、パススイッチ手順を実行することにより、新基地局５−２及びＳ−ＧＷ１０は、サービングＭＭＥ９へのＳ１  ＵＥ関連シグナリング接続を確立し、ＭＭＥ９は、ＵＥコンテキストと、コアネットワーク７における関連する任意のベアラコンテキストとを再開することができ、ＩｏＴデバイス３のためのダウンリンクパスを更新することができる。
【００７４】
必要に応じて、新基地局５−２はまた、（ステップＳ５１０において、適切にフォーマットされたＸ２−ＡＰ‘UE context release’メッセージを生成し、送信することにより）旧基地局５−１に、旧基地局５−１がＩｏＴデバイス３に関連するＵＥコンテキストを解放することができることを通知する。
【００７５】
この時点では、ＩｏＴデバイス３（又はＭＭＥ９）は、ＩｏＴデバイス３のための中断されたＲＲＣ接続を再開することを未だ要求していないので、新基地局５−２は、（ステップＳ５０５において）ＭＭＥ９から受信したResume IDに関連するＲＲＣ接続を再開することに進まないことは留意されたい。
【００７６】
しかしながら、現在、ＵＥコンテキストが新基地局５−２で利用可能であるので、ＭＭＥ９は、（ステップＳ５１１に示すように、例えば、ＭＴ呼の場合、）有益に、ＩｏＴデバイス３に、正しい基地局５−２を介してページングすることができ、新基地局５−２は、もはやコンテキストフェッチ手順を実行する必要がないので、（例えば、ＭＯ呼の場合、）ＩｏＴデバイス３は、遅延無く新基地局５−２を介してＲＲＣ接続を再開することができる。
【００７７】
＜動作−第２の例＞
図６は、ＩｏＴデバイス３（又はＵＥ）のコンテキストフェッチ動作を実行する場合に、システム１のコンポーネントにより実行される他の例示的なプロセスを示すタイミング図（メッセージシーケンスチャート）である。図５を参照して説明した例の変形例である、この例では、ＭＭＥ９は、ＩｏＴデバイス３に関連するResume IDを旧基地局５−１から取得する。換言すると、ＩｏＴデバイス３に関連するResume IDは、ＩｏＴデバイス３により提供されないが、ＭＭＥ９からの要求に応じて（例えば、図６に示すようにクラス１（class-1）手順を用いて）以前の（旧）サービング基地局５により提供される。
【００７８】
最初に、ＩｏＴデバイス３及び旧基地局５−１（図６の‘ｅＮＢ−１’）は、ＩｏＴデバイス３に関連するＵＥコンテキスト及び適切なResume IDを記憶する。ＩｏＴデバイス３は、現在RRC_IDLEモードで動作する。
【００７９】
ＩｏＴデバイス３が旧基地局５−１によりサービスされるエリア（セル１）から離れる（及び／又はセル１の信号状態が悪化する）場合、ＩｏＴデバイス３は、より好適な信号条件を有する新しいセルを選択し、遷移する。この例では、ＩｏＴデバイス３は、第２の基地局５−２（図６の‘ｅＮＢ−２’）により運用されるセル２を選択し、遷移する。
【００８０】
Ｓ６０１に一般的に示すように、ＩｏＴデバイス３は、ＩｏＴデバイス３の新しい位置としてセル２を登録するために適切にフォーマットされたメッセージ（例えば、TAU request）を（ＮＡＳモジュール４９を用いて）生成し、ＭＭＥ９に送信する。しかし、この例では、ＩｏＴデバイス３は、TAUメッセージに、いずれのResume IDも含まない。
【００８１】
ステップＳ６０２において、例えば、新基地局５−２／セル２を識別するための情報に基づいて、ＭＭＥ９は、ＩｏＴデバイス３がネットワーク接続（network attachment）（例えば、セル／基地局）を変更したと判定し、それに応じて、ＵＥ位置登録モジュール８５に保持されたデータを更新する（例えば、ＭＭＥ９は、ＩｏＴデバイス３の現在の位置とするセル１を削除し、ＩｏＴデバイス３の現在の位置としてセル２を保存する）。
【００８２】
しかし、この例では、ＭＭＥ９はまた、ステップＳ６０３において、旧基地局５−１からのＩｏＴデバイス３に関連するResume IDを要求する適切にフォーマットされたシグナリングメッセージを（Ｓ１ＡＰモジュール８８を用いて）生成し、旧基地局５−１に送信する。具体的には、この例では、ＭＭＥ９は、‘GetUEResumeIdRequest’Ｓ１ＡＰメッセージ（及び／又は同様のもの）を生成し、旧基地局５−１に送信し、（例えば、適切な‘eNB ID’により）旧基地局５−１を識別する情報、及びＩｏＴデバイス３を識別する情報（例えば、旧基地局５−１に知られている‘MME UE S1AP ID’及び／又は‘eNB UE S1AP ID’）をこのメッセージに含める。
【００８３】
旧基地局５−１がＩｏＴデバイス３を識別する情報（例えば、ステップＳ５０６において受信された‘MME UE S1AP ID’）をResume IDと一致させることが出来る場合、旧基地局５−１は、ステップＳ６０４において、適切にフォーマットされたシグナリングメッセージ（例えば、‘GetUEResumeIdResponse’Ｓ１ＡＰメッセージ及び／又は同様のもの）にResume IDを含めることにより、（Ｓ１ＡＰモジュール６８を用いて）Resume IDを生成し、ＭＭＥ９に送信する。
【００８４】
次に、ステップＳ５０５と実質的に対応するステップＳ６０５において、ＭＭＥ９は、ＩｏＴデバイス３がネットワーク接続（network attachment）を変更したことを示し、旧基地局５−１からのＩｏＴデバイス３のためのＵＥコンテキストをフェッチするために、新基地局５−２に要求する。ＭＭＥ９は、旧基地局５−１から取得したResume IDをこの要求に含める。
【００８５】
ステップＳ６０６からＳ６１１は一般的に、それぞれ、図５を参照して上述したステップＳ５０６からＳ５１１に対応する。それらの説明は、簡略化のため、ここでは省略する。
【００８６】
有益には、ＩｏＴデバイス３からの再開要求（resume request）が無い場合であっても、ＵＥコンテキストは、新基地局５−２がフェッチすることができるので、ＭＭＥ９は、（例えば、ＭＴ呼の場合、）正しい基地局５−２を介してＩｏＴデバイス３にページングすることができ、基地局５−２は、もはやコンテキストフェッチ手順を実行する必要がないので、ＩｏＴデバイス３は、（例えば、ＭＯ呼の場合、）遅延無く新基地局５−２を介してＲＲＣ接続を再開することができる。
【００８７】
＜動作−第３の例＞
図７は、基地局５を介してＩｏＴデバイス３のためのデータ接続の再開を実行する場合に、システム１のコンポーネントにより実行される他の例示的なプロセスを示すタイミング図（メッセージシーケンスチャート）である。この場合、ＩｏＴデバイス３は、複数の（中断された）無線データベアラを有し、データ接続を再開する場合、ＩｏＴデバイス３は、（新）基地局５に、どれくらいの、及び／又はどのベアラを基地局５が再開する必要があるかを通知する。
【００８８】
前の例と同様に、ＩｏＴデバイス３及び（旧）サービング基地局（例えば、図７に示す基地局５又は他の基地局）は、ＩｏＴデバイス３に関連する、（ＩｏＴデバイス３に関連するＤＲＢに関する情報を含む）ＵＥコンテキスト及び適切なResume IDを記憶する。ＩｏＴデバイス３は、現在RRC_IDLEモードで動作し、ネットワーク接続は中断されている。
【００８９】
ＩｏＴデバイス３がネットワーク（及び／又はネットワークを介して通信エンドポイント）と通信する必要がある（ネットワーク（及び／又はネットワークを介して通信エンドポイント）に送信するデータを有している）場合、ＩｏＴデバイス３は、ＩｏＴデバイス３のための中断されたネットワーク接続を再開することを基地局５に要求する、適切にフォーマットされたＲＲＣシグナリングメッセージを（ＲＲＣモジュール４６を用いて）生成し、ステップＳ７０１において、（例えば、ＩｏＴデバイスがセルを変更した場合、接続を中断した基地局、又は新基地局であり得る）基地局５に送信する。
【００９０】
有益には、この例では、ＩｏＴデバイス３は、どのくらいの、及び／又はどのベアラ（ＤＲＢ）を基地局５がＩｏＴデバイス３のために再開する必要があるかを示す情報をその要求（例えば、‘RRCConnectionResume’メッセージ及び／又は同様のもの）に含める。再開されるＤＲＢの数、及び／又はＤＲＢの選択は、通信する必要があるデータの量及び／又はタイプに基づいて、ＩｏＴデバイス３により決定されてもよいことは理解されるであろう。例えば、ＩｏＴデバイス３が、１又は複数のアップリンクＤＲＢと、（アップリンクＤＲＢと異なる）１又は複数のダウンリンクＤＲＢとを有してもよい。ＩｏＴデバイス３はまた、第１のアプリケーションに関連する１又は複数のアップリンク／ダウンリンクＤＲＢと、第２のアプリケーションに関連する１又は複数の（異なる）ＤＲＢと、を有してもよい。したがって、必要な接続のタイプ（アップリンク／ダウンリンク）、及び／又はアプリケーションに応じて、ＩｏＴデバイス３は、当該接続／アプリケーションに関連するＤＲＢを再開することを有益に要求することができる。
【００９１】
ＩｏＴデバイス３からの要求に応答して、基地局５は、ＩｏＴデバイス３のための要求されたネットワーク接続を許可／再開することをＭＭＥ９に要求する、適切にフォーマットされたＳ１シグナリングメッセージ（例えば、‘UE context resume request’及び／又は同様のもの）を（Ｓ１ＡＰモジュール６８を用いて）生成し、ステップＳ７０２において、ＭＭＥ９に送信する。基地局５はまた、どれくらいの、及び／又はどのベアラ（ＤＲＢ）を基地局５がＩｏＴデバイス３のために再開する必要があるかを示す情報をこのＳ１メッセージに含める。
【００９２】
ＭＭＥ９は、ＩｏＴデバイスの要求が受け入れ（accommodated）可能か否か（例えば、ＩｏＴデバイス３がその基地局５を介して通信することが許可されているか否か）を判定する。要求が受け入れ可能である場合、ＭＭＥ９は、ＩｏＴデバイス３のためのデータ接続を再開することが出来るかどうかを基地局５に通知する、適切にフォーマットされたＳ１シグナリングメッセージを（Ｓ１ＡＰモジュール８８を用いて）生成し、ステップＳ７０３において、基地局５に送信する。有益には、ＭＭＥ９はまた、ＩｏＴデバイス３のために再開すべきＤＲＢに対応する、基地局５により設定される、Ｅ−ＵＴＲＡＮ無線アクセスベアラ（Ｅ−ＲＡＢ：E-UTRAN Radio Access Bearer）を識別する情報（例えば、Ｅ−ＲＡＢのリスト）をこのメッセージ（例えば、‘UE context resume response’及び／又は同様のもの）に含める。ＩｏＴデバイス３からの要求が受け入れられない場合、ＭＭＥ９は、要求されたＤＲＢの再開の失敗をＩｏＴデバイス３に通知する、適切な拒否メッセージを基地局５に返す。ＩｏＴデバイス３からの要求は、（例えば、全ての要求されたＤＲＢではないが、要求されたＤＲＢのいくつかに関して）部分的にのみ受け入れられてもよい。その場合、ＭＭＥ９が、ＩｏＴデバイス３のために再開することができるＤＲＢのみに対応するＥ−ＲＡＢについて、基地局５に通知する（そして、ＭＭＥ９は、再開することができない任意のＤＲＢに対して、適切な拒否（rejection）を部分的に返してもよい）。
【００９３】
ステップＳ７０４に一般的に示すように、再開されるＤＲＢに対応する、ＩｏＴデバイス３のためのＥ−ＲＡＢを設定するために、基地局５は、適切なアドミッションコントロール及びＲＲＣ再設定（RRC reconfiguration）を実行する。ＲＲＣ再設定（RRC reconfiguration）が成功すると、基地局５は、適切なＳ１シグナリングメッセージ（例えば、‘UE context response complete’）を生成し、送信することにより、ＩｏＴデバイス３のために設定されるＥ−ＲＡＢ（例えば、Ｅ−ＲＡＢ設定リスト（E-RAB setup list）及び／又は同様のもの）について、ＭＭＥ９に通知する。いずれかの基地局５が、要求されたＥ−ＲＡＢのいずれかの設定を失敗した場合、その失敗したＥ−ＲＡＢを識別する情報（例えば、Ｅ−ＲＡＢ失敗リスト（E-RAB failure list）及び／又は同様のもの）を含んでもよい。
【００９４】
ステップＳ７１０において一般的に示されているように、アドミッションコントロール及びＲＲＣ再設定（RRC reconfiguration）に続いてＩｏＴデバイス３は、（基地局５及びＳ−ＧＷ１０を介して）他のノードとの設定されたＥ−ＲＡＢにおいてデータを通信することができる。ＭＭＥ９は、再開された接続に関連するトンネルエンドポイントＩＤ（ＴＥＩＤ：Tunnel Endpoint ID）を正確に識別し、通知することにより、基地局５と、Ｓ−ＧＷ１０との間の必要なパスのアクティベーションを調整することができる。
【００９５】
有益には、どのくらいの、及び／又はどのＤＲＢをＩｏＴデバイスが再開することが必要であるかをＭＭＥに示すことにより、ＩｏＴデバイスが再開された接続のために必要としないＤＲＢを再開することを回避することを可能にし、（そして、それにより、ＩｏＴデバイス及びサービング基地局において通信リソースを解放することができ、）及び／又は、（例えば、サービング基地局が要求されたＤＲＢのいくつかを再開する十分なリソースを有していたとしても、ＩｏＴデバイスに関連する全てのＤＲＢを再開するための十分なリソースを有していない場合等、）接続を再開することの失敗を回避することができる。
【００９６】
さらに、ＩｏＴデバイスが新サービング基地局に移動し、及び／又は新サービング基地局を介して接続を再開する場合、ＩｏＴデバイス及びサービング基地局において、より良好なサービス継続性、及び、より効率的なリソース使用を提供することができる。
【００９７】
＜変形及び代替＞
以上、詳細な実施形態を説明した。当業者であれば理解出来るように、上記の例示的な実施形態は、多くの変形及び代替がなされ得るが、それらには具体化される本発明の利益を受ける。説明のために、多くのこれらの変形及び代替を説明する。
【００９８】
図７のステップＳ７０１においてＩｏＴデバイスにより送信された再開要求（resume request）は、再開される接続の詳細を特定する完全なサービス要求（例えば、適切なＲＲＣ／ＮＡＳ要求）を含んでもよいことは理解されよう。このようなサービス要求は、ＭＭＥがＩｏＴデバイスのための確立されるベアラ（及び関連するＱｏＳ）について判定することを可能にする適切にフォーマットされたモバイル発信データ（ｍｏ−ｄａｔａ：mobile originated data）NAS Service Requestを含んでもよい（ＭＭＥの判定が、ポリシー及び課金ルール機能（ＰＣＲＦ：Policy and Charging Rules Function）、ホーム加入者サーバ（ＨＳＳ：Home Subscriber Server）等の）他のコアネットワークエンティティからの入力に基づいてもよい）ことは理解されよう。
【００９９】
あるいは、再開要求は、ＩｏＴデバイスが再開することを要求する各ＤＲＢ（１又は複数の特定のＤＲＢ）を識別する情報を含んでもよい。他の例では、再開要求は、ＩｏＴデバイスが再開することを要求するＤＲＢ数を識別する情報（つまり、どのＤＲＢを再開するかよりも、どれくらいのＤＲＢを再開するか）を含んでもよい。これは、例えば、（ＩｏＴデバイスと、基地局との間で）再開要求を運ぶシグナリング無線ベアラ＃０（ＳＲＢ０：Signalling Radio Bearer #0）のスペースが不十分であるために必要であってもよい。サービス要求及び／又は再開される正確なベアラを識別する情報（例えば、関連するベアラ識別子）が無い場合、ネットワークは、ＩｏＴデバイス（ＵＥ）と関連する任意の適切なベアラ、例えば、中断時にＩｏＴデバイス（ＵＥ）に割り当てられた最も高いＱｏＳを有するベアラ、を再開するように構成されてもよい。
【０１００】
ステップＳ７０４（アドミッションコントロール及びＲＲＣ再設定）は、（例えば、ステップＳ５０６及びＳ５０７を参照して説明したように）ＩｏＴデバイスの旧サービング基地局からの対応するＵＥコンテキストをフェッチすることを含んでもよい（又は、先にＩｏＴデバイスの旧サービング基地局からの対応するＵＥコンテキストをフェッチされてもよい）。
【０１０１】
上述した例示的な実施形態において、Ｘ２接続が基地局間において提供され、新サービング基地局は、（例えば、ステップＳ５０６〜Ｓ５０７、又はＳ６０６〜Ｓ６０７において）Ｘ２接続を介してＩｏＴデバイス（ＵＥ）に関連するＵＥコンテキストを検索するように説明される。しかしながら、新基地局と旧基地局との間においてＸ２接続が提供されていない場合、ＭＭＥが（例えば、ＭＭＥと旧基地局との間のＳ１接続を用いて）旧基地局からのＵＥコンテキストを検索するように構成されてもよく、（例えば、ＭＭＥと新基地局との間のＳ１接続を用いて）新基地局に検索されたＵＥコンテキストを提供するように構成されてもよいことは理解されよう。
【０１０２】
本発明の例示的な実施形態は、インターネットオブシングス（Internet of Things）（又はマシンタイプ：machine-type）データ送信（例えば、メジャメントイベントの間に取得されたデータの送信等）を説明したが、送信されたデータは、通信デバイスが使用されているアプリケーションに応じて、任意の形式のデータを含んでもよいことは理解されるであろう。例えば、上述した例示的な実施形態は、ユーザデータ、バックアップデータ、同期データ、診断データ、監視データ、使用統計、エラーデータ、及び／又は同様のもの等の他のデータを送信するために適用可能であってもよい。
【０１０３】
上述した例示的な実施形態では、ＩｏＴデバイスは、自動化されたデバイスである。上述した例示的な実施形態は、例えば、携帯電話（スマートフォン）、パーソナルデジタルアシスタント、ラップトップ／タブレットコンピュータ、ウェブブラウザ、電子書籍リーダ（e-book reader）、等の、自動化された装置以外の他のデバイスを用いて実装されてもよいことは理解されるであろう。
【０１０４】
上述した実施形態では、３ＧＰＰ無線通信（無線アクセス）技術が用いられる。しかしながら、他の無線通信技術（つまり、ＷＬＡＮ、Ｗｉ−Ｆｉ、ＷｉＭＡＸ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、等）は、上述した実施形態にかかるＩｏＴデバイスの送信を管理するために使用され得る。上述した例示的な実施形態はまた、‘非モバイル（non-mobile）’又は一般的に固定されたユーザ装置に提供することができる。
【０１０５】
ＩｏＴアプリケーションの例
インターネットオブシングス（Internet of Things）（又はＭＴＣ）アプリケーションのいくつかの例は、以下の表にリスト化される（ソース：3GPP TS 22.368 V13.1.0, Annex B）。このリストは、網羅的ではなく、インターネットオブシングス（Internet of Things）／マシンタイプ（machine-type）通信アプリケーションの範囲を示すことを目的とする。
【０１０６】
【表１】
2019512971.tif 000003
【表２】
2019512971.tif 000004
【０１０７】
上記説明では、ＩｏＴデバイス、基地局、及びＭＭＥは、説明を容易にするために、多数の個別の機能コンポーネント又はモジュールを有するとして説明した。これらのモジュールは、例えば、当初から本発明の特徴を考慮して設計されたシステム等の他のアプリケーションにおいて、例えば、既存システムが本発明を実施するように変更された特定のアプリケーションのためにこのように提供されてもよいが、これらのモジュールは、全体的なシステム又はコードに組み込まれてもよく、そして、これらのモジュールは、個別のエンティティとして認識されなくてもよい。
【０１０８】
上述した例示的な実施形態では、多数のソフトウェアモジュールが説明された。当業者であれば、ソフトウェアモジュールは、コンパイルされた形態、又はコンパイルされていない形態で提供されてもよく、ソフトウェアモジュールは、コンピュータネットワークを介した信号として、又は記録媒体上の信号として、基地局、モビリティ管理エンティティ、（ＩｏＴデバイス、又は（形態電話等の）他のユーザ装置に供給されてもよいことは理解されるであろう。さらに、ソフトウェアの一部又は全てにより実行される機能は、１又は複数の専用ハードウェア回路を用いて実行されてもよい。しかしながら、基地局、モビリティ管理エンティティ、又はＩｏＴデバイス（又は、例えばＭＴＣアプリケーション等のＩｏＴ機能を有する携帯電話）の機能を更新するために、それらの更新を容易にするので、ソフトウェアモジュールの使用が好ましい。
【０１０９】
基地局のトランシーバは、ローカルメモリ又は他の基地局からのＵＥコンテキストを検索するように構成されてもよい。例えば、トランシーバは、ＵＥコンテキスト（例えば、Resume ID）を識別する情報を含む少なくとも１つのシグナリングメッセージ（例えば、‘Retrieve UE Context Request’）を送信することにより、他の基地局からのコンテキストを検索するように構成されてもよい。
【０１１０】
コントローラは、（例えば、通信デバイスにより送信されたtracking area update（ＴＡＵ）メッセージから）通信デバイスからの再開識別子（resume identifier）、又は（例えば、再開識別子を検索するために適切なＳ１−ＡＰ手順を用いて）他の基地局からの再開識別子を取得するように構成されてもよい。
【０１１１】
コントローラは、通信デバイスが（例えば、通信ネットワークの基地局間で）ネットワーク接続（network attachment）を変更したことを判定するように構成されてもよく、通信デバイスがネットワーク接続を変更したことが判定される場合、トランシーバが、取得した再開識別子を送信するように構成されてもよい。
【０１１２】
通信デバイスのトランシーバは、コアネットワーク装置に向けて送信されたtracking area update（ＴＡＵ）メッセージ内で、通信デバイスの現在の位置を識別する情報を送信するように構成されてもよい。
【０１１３】
基地局のトランシーバは、再開される無線ベアラの数を識別する情報をコアネットワーク装置に提供するように構成してもよく、設定される少なくとも１つの無線ベアラ（例えば、少なくとも１つのＥ−ＲＡＢ）を識別する情報を含むメッセージをコアネットワーク装置から受信するように構成してもよく、基地局のコントローラは、そのように識別された少なくとも１つの無線ベアラを設定するように構成してもよい。
【０１１４】
通信接続を再開する要求は、無線リソース制御（ＲＲＣ）を確立するための要求、及びＲＲＣ接続を再開するための要求、の１つを含んでもよい。
【０１１５】
コアネットワーク装置は、モビリティ管理エンティティ（ＭＭＥ）を含んでもよい。通信デバイスは、３ＧＰＰ規格にかかるユーザ装置（ＵＥ）、‘インターネットオブシングス’（ＩｏＴ）デバイス、マシンタイプ通信（ＭＴＣ）デバイス、マシンツーマシン（Ｍ２Ｍ）通信デバイス、及び携帯電話のうちの少なくとも１つを含んでもよい。
【０１１６】
様々な他の変形は、当業者に明らかであり、ここではさらに詳細は記載しない。
【０１１７】
本発明の例示的な実施形態の全部又は一部が、これらの実施形態に限定されるものではない。当業者であれば、特許請求の範囲に規定された本発明の精神（sprit）及び範囲（scope）から逸脱することなく、形態及び詳細の様々な変更を行うことができるのは理解されよう。
【０１１８】
上述した例示的な実施形態の全部又は一部は、これに限られないが、以下の付記として説明することができる。
【０１１９】
（付記１）通信ネットワークのための基地局であって、前記基地局は、
前記基地局により運用される前記通信ネットワークのセル内の通信デバイスと関連する再開識別子をコアネットワークから受信するように構成されるトランシーバと、
前記受信された再開識別子に基づいて、前記基地局において、前記通信デバイスによる以前に中断された通信接続の再開に使用される、前記通信デバイスのためのユーザ装置（ＵＥ）コンテキストを検索するように構成されるコントローラと、を備える基地局。
【０１２０】
（付記２）前記トランシーバは、ローカルメモリ又は他の基地局からの前記ＵＥコンテキストを検索するように構成される、付記１に記載の基地局。
【０１２１】
（付記３）前記トランシーバは、前記ＵＥコンテキストを識別する情報（例えば、Resume ID）を含む少なくとも１つのシグナリングメッセージ（例えば、‘Retrieve UE Context Request’）を送信することにより、他の基地局からの前記ＵＥコンテキストを検索するように構成される、付記２に記載の基地局。
【０１２２】
（付記４）通信ネットワークのためのコアネットワーク装置であって、前記コアネットワーク装置は、
通信デバイスのための、以前に確立された通信接続に関連するユーザ装置（ＵＥ）コンテキストを識別するように構成される再開識別子を取得するように構成されるコントローラと、
前記取得された再開識別子を基地局に送信するように構成されるトランシーバと、を備えるコアネットワーク装置。
【０１２３】
（付記５）前記コントローラは、（例えば、前記通信デバイスにより送信されたtracking area update（ＴＡＵ）メッセージから）前記通信デバイスから、又は、（例えば、前記再開識別子を検索するための適切なＳ１−ＡＰ手順を用いて）他の基地局からの前記再開識別子を取得するように構成される、付記４に記載のコアネットワーク装置。
【０１２４】
（付記６）前記コントローラは、前記通信デバイスが（前記通信ネットワークの基地局間で）ネットワーク接続を変更したことを判定するように構成され、前記トランシーバは、前記通信デバイスがネットワーク接続を変更したことが決定される場合、前記取得された再開識別子を送信するように構成される、付記４又は５に記載のコアネットワーク装置。
【０１２５】
（付記７）通信ネットワークのための通信デバイスであって、前記通信デバイスは、
前記通信デバイスによる以前に中断された通信接続の再開に使用するために、前記通信デバイスのための再開識別子と共に、前記通信デバイスの現在位置を識別する情報をコアネットワーク装置に送信するように構成されるトランシーバを備える通信デバイス。
【０１２６】
（付記８）前記トランシーバは、前記コアネットワーク装置に向けて送信されたtracking area update（ＴＡＵ）メッセージ内で、前記通信デバイスの現在位置を識別する前記情報を送信するように構成される、付記７に記載の通信デバイス。
【０１２７】
（付記９）通信ネットワークのための基地局であって、前記基地局は、
通信デバイスから、前記通信デバイスのための通信接続を再開する要求であって、前記再開される無線ベアラ数を識別する情報を含む前記通信接続を再開する要求を受信するように構成されるトランシーバと、
前記通信デバイスのためのユーザ装置（ＵＥ）コンテキストを取得するように構成され、前記再開される前記無線ベアラの少なくとも１つを設定するように構成されるコントローラと、備える基地局。
【０１２８】
（付記１０）前記トランシーバは、再開される無線ベアラ数を識別する前記情報をコアネットワーク装置に提供するように構成され、設定される少なくとも１つの無線ベアラ（例えば、少なくとも１つのＥ−ＲＡＢ）を識別する情報を含むメッセージを前記コアネットワーク装置から受信するように構成され、前記コントローラは、識別された前記少なくとも１つの無線ベアラを設定するように構成される、付記９に記載の基地局。
【０１２９】
（付記１１）前記通信接続を再開する前記要求は、無線リソース制御（ＲＲＣ）接続を確立する要求、及びＲＲＣ接続を再開する要求のうちの１つを含む、付記９又は１０に記載の基地局。
【０１３０】
（付記１２）通信ネットワークのためのコアネットワーク装置であって、前記コアネットワーク装置は、
再開する無線ベアラ数を識別する情報を含むユーザ装置（ＵＥ）コンテキストを再開する要求を基地局から受信し、
設定される少なくとも１つの無線ベアラ（例えば、少なくとも１つのＥ−ＲＡＢ）を識別する情報を含む前記要求に対する応答を前記基地局に送信するように構成されるトランシーバを備えるコアネットワーク装置。
【０１３１】
（付記１３）モビリティ管理エンティティ（ＭＭＥ）を含む、付記４〜６のいずれか１項、又は付記１２のコアネットワーク装置。
【０１３２】
（付記１４）通信ネットワークのための通信デバイスであって、前記通信デバイスは、
前記通信ネットワークの基地局に、前記通信デバイスのための通信接続を再開する要求であって、再開される無線ベアラ数を識別する情報を含む前記通信接続を再開する前記要求を送信するように構成されるトランシーバを備える通信デバイス。
【０１３３】
（付記１５）前記通信デバイスは、３ＧＰＰ規格にかかるユーザ装置、ＩｏＴ（internet of things）デバイス、ＭＴＣ（machine-type communications）デバイス、Ｍ２Ｍ（machine-to-machine）通信デバイス、及び携帯電話のうちの少なくとも１つを含む、付記７又は８又は１４に記載の通信デバイス。
【０１３４】
（付記１６）付記１〜３及び９〜１１のうちのいずれか１項に記載の基地局と、付記４〜６、１２及び１３のうちのいずれか１項に記載のコアネットワーク装置と、付記７、８、１４及び１５のうちのいずれか１項に記載の通信デバイスと、を備えるシステム。
【０１３５】
（付記１７）通信ネットワークの基地局により実行される方法であって、前記方法は、
前記基地局により運用される前記通信ネットワークのセル内の通信デバイスに関連する再開識別子をコアネットワーク装置から受信することと、
前記受信された再開識別子に基づいて、前記基地局において、前記通信デバイスによる以前に中断された通信接続の再開に使用するために、前記通信デバイスのためのユーザ装置（ＵＥ）コンテキストを検索することと、を含む方法。
【０１３６】
（付記１８）通信ネットワークのコアネットワーク装置により実行される方法であって、前記方法は、
通信デバイスのための、以前に確立された通信接続に関連するユーザ装置（ＵＥ）コンテキストを識別するように構成される再開識別子を取得することと、
前記取得された再開識別子を基地局に送信することと、を含む方法。
【０１３７】
（付記１９）通信デバイスにより実行される方法であって、前記方法は、
前記通信デバイスによる以前に中断された通信接続の再開に使用するために、前記通信デバイスのための再開識別子と共に、前記通信デバイスの現在位置を識別する情報をコアネットワーク装置に送信することと、を含む方法。
【０１３８】
（付記２０）通信ネットワークの基地局により実行される方法であって、前記方法は、
通信デバイスから、前記通信デバイスのための通信接続を再開する要求であって、再開される無線ベアラ数を識別する情報を含む、前記通信接続を再開する前記要求を受信することと、
前記通信デバイスのためのユーザ装置（ＵＥ）コンテキストを取得し、再開される前記無線ベアラのうちの少なくとも１つを設定することと、を含む方法。
【０１３９】
（付記２１）通信ネットワークのコアネットワーク装置により実行される情報であって、前記方法は、
基地局から、再開される無線ベアラ数を識別する情報を含むユーザ装置（ＵＥ）コンテキストを再開する要求を受信することと、
前記基地局に、設定される少なくとも１つの無線ベアラ（例えば、少なくとも１つのＥ−ＲＡＢ）を識別する情報を含む前記要求に対する応答を送信することと、を含む方法。
【０１４０】
（付記２２）通信デバイスにより実行される方法であって、前記方法は、
通信ネットワークの基地局に、前記通信デバイスのための通信接続を再開する要求であって、再開される無線ベアラ数を識別する情報を含む、前記通信接続を再開する前記要求を送信することを含む方法。
【０１４１】
（付記２３）付記１７〜２２のいずれか１項に記載の前記方法をプログラム可能なコンピュータデバイスに実行させるためのコンピュータ実行可能命令を含むコンピュータプログラム製品。
【０１４２】
本出願は、２０１６年３月３１日に提出された英国特許出願第１６０５４６６．０号に基づく優先権を主張し、その開示はその全体が参照により本明細書に組み込まれる。
【図１】
2019512971.tif 000005
【図２】
2019512971.tif 000006
【図３】
2019512971.tif 000007
【図４】
2019512971.tif 000008
【図５】
2019512971.tif 000009
【図６】
2019512971.tif 000010
【図７】
2019512971.tif 000011
【図８】
2019512971.tif 000012
【手続補正書】
【提出日】平成30年9月20日(2018.9.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信ネットワークのための基地局であって、前記基地局は、
前記基地局により運用される前記通信ネットワークのセル内の通信デバイスに関連する再開識別子をコアネットワークノードから受信するように構成されるトランシーバと、
前記受信された再開識別子に基づいて、前記基地局において、前記通信デバイスによる以前に中断された通信接続の再開に使用される、前記通信デバイスのためのユーザ装置（ＵＥ：user equipment）コンテキストを検索するように構成されるコントローラと、を備える基地局。
【請求項２】
前記トランシーバは、ローカルメモリ又は他の基地局からの前記ＵＥコンテキストを検索するように構成される、請求項１に記載の基地局。
【請求項３】
前記トランシーバは、前記ＵＥコンテキストを識別する情報を含む少なくとも１つのシグナリングメッセージを送信することにより、他の基地局からの前記ＵＥコンテキストを検索するように構成される、請求項２に記載の基地局。
【請求項４】
通信ネットワークのためのコアネットワーク装置であって、前記コアネットワーク装置は、
通信デバイスのための、以前に確立された通信接続に関連するユーザ装置（ＵＥ：user equipment）コンテキストを識別するように構成される再開識別子を取得するように構成されるコントローラと、
前記取得された再開識別子を基地局に送信するように構成されるトランシーバと、を備えるコアネットワーク装置。
【請求項５】
前記コントローラは、前記通信デバイス又は他の基地局からの前記再開識別子を取得するように構成される、請求項４に記載のコアネットワーク装置。
【請求項６】
前記コントローラは、前記通信デバイスがネットワーク接続を変更したことを判定するように構成され、前記トランシーバは、前記通信デバイスがネットワーク接続を変更したことが判定された場合、前記取得された再開識別子を送信するように構成される、請求項４又は５に記載のコアネットワーク装置。
【請求項７】
通信ネットワークのための通信デバイスであって、前記通信デバイスは、
前記通信デバイスによる以前に中断された通信接続の再開に使用するために、前記通信デバイスのための再開識別子と共に、前記通信デバイスの現在位置を識別する情報をコアネットワーク装置に送信するように構成されるトランシーバを備える通信デバイス。
【請求項８】
前記トランシーバは、前記コアネットワーク装置に向けて送信されたtracking area update（ＴＡＵ）メッセージ内で、前記通信デバイスの現在位置を識別する前記情報を送信するように構成される、請求項７に記載の通信デバイス。
【請求項９】
モビリティ管理エンティティ（ＭＭＥ：mobility management entity）を含む、請求項４〜６のいずれか１項に記載のコアネットワーク装置。
【請求項１０】
前記通信デバイスは、３ＧＰＰ規格にかかるユーザ装置、ＩｏＴ（internet of things）デバイス、ＭＴＣ（machine-type communications）デバイス、Ｍ２Ｍ（machine-to-machine）通信デバイス、及び携帯電話のうちの少なくとも１つを含む、請求項７又は８に記載の通信デバイス。
【国際調査報告】
2019512971.tif 000013
2019512971.tif 000014
2019512971.tif 000015